[PLUG] running a mixed Debian system

[Michael C. Robinson]

On Fri, 2003-10-31 at 00:16, Jeme A Brelin wrote:

>
> I've always said that the only real purpose of a distribution is the
> package management system.  I think that, in this respect, Debian has the
> others beat hands down.
> 
> If it's a system I'm going to use frequently and others do not depend on
> its availability, however, I'm just going to forego the whole
> "distribution" concept and get my source from the maintainers.
> 

The crux of the problem with saying distributions 
are just about package management is that 
unlocking a distribution and getting the most 
benefit out of it over say spending the extra 
time to build your own thing from source is 
one of the major reasons to use distributions.  

I think the rpm idea is fine, problem is the 
dependency database needs to be trainable so 
that if say I compile something on an rpm 
system I can find out what packages on that 
system need to be installed for it to work 
installing it as a package with those 
dependencies.  In the case of binaries, if 
I can find out that binary a works with 
library b, than I should be able to say 
that binary a or package a can use library 
b in the absence of library a.  Another 
problem is linking libraries, traditionally 
any upgade of a library should I believe 
be compatible with programs using the old 
version potentially fixing some bug or 
improving performance.  

For perl-5.6.0 and perl-5.6.1, why can't 
I install both of them side by side?  The 
obvious problem is the collision of the 
perl binary but that's about it.  I guess 
I ran into this because of statically 
compiled apache where I kludged by 
linking the 5.6.0 tree to 5.6.1 tree 
to satisfy an apache.pm dependency.  
I wonder if this was a good hack or 
a bad hack, that would require testing
which I'm not 100% certain how to do.

Maybe a smarter idea is to install a 
universal micro distribution with 
only the things anyone would install 
setting up Linux and then force the 
building of the other packages and 
their dependency information with 
nice menuconfig like menus showing 
what the default vendor settings 
are.  In cases where you want to
install packages default compiled, 
you can then install binaries 
direct.  I think it would be wise 
for every distro to go to a micro 
footprint to start out with 
including for X windows.  With 
twm and XFree86, that should be 
plenty even in standard vga mode 
to implement a package selection 
system like the Redhat and Mandrake 
installers.  Move to xml config files 
and maybe we can have config files 
that aren't broken by those of us 
who want to hand edit them when 
graphical tools are used.

For programmers, the better one 
can do at not requiring a recompile
to change the features, options, or 
configuration of a program the more 
sense binaries are going to make.  
If however paths have to be compiled 
in or leaving certain things compiled 
out like Japanese fonts is required so 
that you don't have to install the 
Japanese fonts stuff, that makes 
binaries less attractive.  I guess 
under X things have been done to 
try to fix the path problem, why 
are fonts so so screwed up under 
Redhat 7.3 out of the box though?  
Is there a HOWTO on fixing the 
fonts in a default Redhat system?  
I'm just guessing here, but in my 
experience it seems console fonts 
and X under Redhat are incompatible 
if one attempts to use both X and 
console fonts modification.  Maybe 
this is a case of ignoring what's
in the video card's cache or the 
ram side video cache when X is run.  
My biggest challenge if I stay a 
programmer is staying up to date 
on a continuous basis regarding
how to program properly, 
efficiently, securely...

In the case of files for packages 
that aren't installed, it would be 
cool if these files were hidden.  
It would also be cool if the password
file had a hidden portion for user 
accounts needed by programs or services 
that aren't installed.  I guess the 
other option is to just never add 
an account where a default vendor 
one may need to be, though simply 
keeping all vendor accounts is evidently 
dangerous and for reasons I don't fully 
understand certain accounts should be 
below 1023 even if they aren't default 
ones.

The problem of vendors changing electronics or code in 
the same numbered version of a product where the change 
isn't transparent concerns me.  How many problems are 
real bugs verses unexpected changes to hardware or 
violation of standards where the LG cdrom drives and
Mandrake comes to mind?  One solution to make Linux 
run better is to encourage or start a company that 
specifically makes hardware to work with Linux in a 
well understood well engineered manner.  If you can 
release the blueprints  with Linux hardware your 
doing exceptionally well at improving Linux system 
quality.  Is it possible to get any hardware or 
software that is completely compliant to standards?  
After reading some of the recommended documents on 
ATA, I daresay that I'm thinking the answer to the 
last question is no.

My greatest disgust is with optimizations.  They 
don't seem to be done very well in the PC world.  
One argument is that we should be able to compile 
programs the same way we did back in the 386 days 
where optimization should be put into libraries 
and chosen at runtime in a well defined manner.  
One thing that bothers me is how Intel is saying 
we should program with special instruction sets 
and in different ways to improve program speed 
claiming Itanium is the thing even over alpha, 
but at what cost I wonder?  Retooling hurts 
where the beauty of Unix is getting away from 
obscure concepts of blocks and records, 
shifting verses loading a new value into a 
register, add another one here...  Compilers 
should figure out some of this for us.

If man pages are compiled with the source, how many
on the list know how to test the outcome of the man
page against the options compiled into the software 
that's going to be installed?  If some option is left
out, the instructions for it shouldn't be in the man 
pages that will be installed.

In regard to understanding a distribution or Calculus
based physics for example, it helps to know how to
think when studying it in a way that will lead in
a helpful direction.  There need to be projects that
do nothing but work on making it easier to grasp
Linux in a broad sense and specific distributions
in a narrower sense.

    --  Michael Robinson