Linux fat/bloated

Thu Apr 6 04:47:12 UTC 2006

On 4/5/06, Sy Ali <sy1234-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> On 4/5/06, Walter Dnes <waltdnes-SLHPyeZ9y/tg9hUCZPvPmw at public.gmane.org> wrote:
> >   See article at http://news.zdnet.com/2100-9590-6057456.html where
> > Nicholas Negroponte (a fan of linux, if there ever was one) admits the
> > obvious; linux needs to be slimmed down.
>
> I disagree.  Disk space is cheap and users don't care.

*Almost* true.  Yes, disk space is cheap.  And yes, libraries do get
shared, particularly if you run multiple apps using the same "desktop
environment."

However, the DE guys have had a habit of squandering every hardware
improvement by adding fancier display rendering every time there's an
improvement.  There's the notion of widget "engines" where you can
pretty much have every menu bar and window edge do Purty Things that
chew up memory and CPU power.

Memory is usually the problem; that's what gets excessively consumed...

> It's more important to have nice tools which fit the varying kinds of
> developers so that better software can be created.  Dependancies
> aren't a problem.. let the package manager handle it.  If things get
> out of hand, it'll get fixed..

- The problems are probably most visible with the likes of Gentoo,
where the recursiveness of the build process is the most "in your
face."
- With the lack of "meta-tools" for RPM-based systems, the people
building packages suffer greatly.
- With Debian, it probably mostly "just works" because they had
"distribution building tools" on their todo list earlier than
others...

> All a user cares about is *make it go*.  A serious distribution has
> already balanced things quite nicely and a linux distro still won't
> take an intimidating amount of drive space to run.

Yeah.  320GB disks are now getting cheap...

> Low-end systems are a niche and not a large concern.  There are some
> very good specialized-distributions for them anyways.

There can be fine-grained exceptions to this, but I think you're
basically right.

When any vendor gets into involvement with Linux, they are NOT
interested in deploying it on 3-year-old hardware; that's a business
area that is looking for headaches.  Vendors are interested in
involvement with reasonably "late-breaking" hardware, and anything
recently built will have at least 32MB of video RAM, if not 128MB, and
256MB of RAM, if not 512MB, etcetera, etcetera...

It's well and good to talk about retasking old servers, but there's
not Real Money to be made there, so that's more a hobbyist thing than
anything vendors of any sort will care about.

> Servers are more of a concern for various reasons.  I still don't
> worry too much though.
>
> Desktop users don't care.. they just want to see their apps work and work well.
>
> Dependancy hell is avoidable by breaking packages into smaller bits..
> but at a very serious cost for maintainance.  So what if I need to
> download less bloated dependancies to install my app.. when everything
> is several steps behind the latest version because the packagers
> haven't had the time to keep everything up to date.

This points essentially at something like Debian...  Not "bleeding
edge" to the point of cutting yourself...

> Packaging tools do need improvement.  I actually sat down and
> experimented with building RPMs.  Ugh.  That sucks.  Package
> management is iffy.. heck, I just want proper descriptions for all the
> software in my repository.  Hasn't anyone thought to have a
> website-style package manager that acts as a gateway to screenshots,
> explanations, documentation and the like?  It'd be nice to know what
> an application is without having to google around for a better
> description, or go to the thing's site (if I can find it) for info.

Pretty much any packaging system has at least that much metadata lying
around, so this seems a "solved problem" as far as data collection
goes.

For sure, RPM, Debian packages, and BSD Ports provide coherent places
to assemble, for each package:
 a) Brief descriptions
 b) URL to source

There are conventions, in Debian and BSD, for where to stow
documentation, as well as in LSB.

> It is unfortunate that these new languages like Perl came out .. that
> we can't all use one single good old language like Ruby.  But that'll
> never happen.  All that choice nonsense people keep going on about.
> Everyone wants to do their own half-assed thing so the world is full
> of 85% quality stuff.

That's another discussion :-).  It's looking to me like the choices
added since Common Lisp and Tcl were mostly steps backward, but
apparently "to each his own" is a vital enough principle that we have
to support way too many scripting languages.

This actually points to the curious question of how a successor
compiled language can emerge.  Today, probably 95% of things get
compiled from one of {C|C++|Java} (with token amounts of FORTRAN still
around).

The fragmentation of scripting languages (which do way more than
scripting) makes it quite the puzzle as to what the shape of a
successor to Java would be.  I don't imagine it's C#, which looks
plenty like Java anyways.

I'm not sure what else...

> If there were a real concern, then projects like heretix would take
> off.  This project will be rewriting all the scripts, the package
> management, making a custom software distribution application.. it
> breaks away from insane legacy choices, etc etc.
>
> But choice.. the developers want their choice.  So all those libraries
> and dependancies (and their dependancies) exist.  I wouldn't force a
> developer to use specific tools.. many would stop contributing to the
> application pool.

The latter is the forcible argument *against* trying to forcibly unify
GNOME and KDE and such.  People don't recognize that managing open
source projects is a matter more like "herding cats," where, when
participants are volunteers, you can't force them to do anything.
--
http://www3.sympatico.ca/cbbrowne/linux.html
"The true  measure of a  man is how he treats  someone who can  do him
absolutely no good." -- Samuel Johnson, lexicographer (1709-1784)
--
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