Linux fat/bloated

[Peter]

On Wed, 5 Apr 2006, D. Hugh Redelmeier wrote:

...
> that are not at the top of my mind.  It basically boils down to
> complexity.

Uhuh. And since complexity is here to stay the point is to shift it onto 
someone who can handle it. The aggregator for example.

> It is very hard to simplify anything.  The only generally successful
> technique is to start over.

And the costliest ?

> Examples from within the Linux world: Knoppix, Tom's Root Boot,
> hand-held distros, LTSP.

But none of these are *less* complex. They are *more* complex, however, 
the complexity is better hidden from the user.

> Good design is slow and careful.  The growth of software is often pell
> mell.

Yes. And, worse, nobody can pay for/wait for good design. The only way 
to live with contemporary c**p software is to run it on systems that can 
take almost any abuse gracefully (by virtue of them having been abused 
and improved to resist the abuse for 30 years). Like *nix.

> Complexity is very cheap in computer software.  Much cheaper than any
> other medium that I can think of (other than the written word).  We
> therefore get way too much.

Complexity is way too cheap imho. Few people realize what can of worms 
lies hidden in a 100-line 'flawless' VB or Tcl (or Javascript) program 
that relies on a million lines of library code to run. They will find 
out, at the latest, when the (one of) the library(es) is updated, thus 
triggering bug #878655c.bis . Then it will turn out that the bug 
requires a complete rewrite of a module that has been unmaintained since 
1989. Then someone writes a workaround in the high level code. Then the 
100-line clean code becomes a 180-line unclean code. Three episodes 
later, you have what your web browser loads as Javascript when you 
browse the average media website nowadays. And you (the user) *trust* it 
to be relatively safe and mostly work. Hey, there are people who believe 
in Santa, and there is no way to prove them wrong. Not that it's bad to 
believe in Santa or anything.

> Modularity is the main tool to fight complexity.  Complaints about
> dependencies may relate to bad modularity.

Yes, but please see above about who is to handle the unavoidable 
complexity.

> - XML config files.

XML is a pet peeve of mine. First there were config files, and they were 
hard to maintain and coordinate. Then there were SQL datbases where one 
had to also maintain the schema besides using the correct drivers and 
front end scripts. Then there was HTML which did markup at terrible cost 
in bandwidth and readability. And then they 'improved' it by 
generalizing the part that consumed the bandwidth and decided to use 
*that* to replace configs and SQL. So now it is no longer possible to 
edit it by hand without putting in about a bug per line edited. Great 
stuff. Not really. And then your (the developer's) code depends on 
someone else's implementation of an XML editor and a XML library done by 
yet another guy.

> - packaging that isn't portable

That is not so true. Packages can be converted with minimum effort. For 
example using mc you can 'navigate' inside a package and get what you 
need or export it etc.

> - enormous libraries (glibc, gtk, qt, ...)

This is unavoidable. But it is better if someone else than the average 
user takes care of their cohesiveness, as a working set.

> - overgrown scripting languages (bash, for example)

Agreed, there should be a fallback simple language, like sh. There is 
(e.g. ash etc).

> - boot time

? it's not so bad. A normal system comes up well under a minute. Oh, you 
mean KDE boot time ;-) Ok, I understand. ;-)

> - unfathomable interconnections (e.g. whatever it is that mounts USB
>  devices when I plug them into my Fedora Core 5 system)

cat /proc/sys/kernel/hotplug

Peter
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml