Linux fat/bloated

[Sy Ali]

On 4/6/06, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> Memory is usually the problem; that's what gets excessively consumed...

Aah, too true.  With lots of choice and lots of dependancies a user
might be tempted to use a widely varied collection of applications..
each one of those applications takes memory, and each of their
dependancies also does.  This does slow things down a noticible
amount.


> 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.

I think that older hardware is a very interesting concern for
hobbyists.  I know I was very interested when I was running older
hardware.  I found it quite fascinating to find alternate software
which was smaller and with lighter dependancies.

I was *very* pleased to see what Linux could do.


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

I guess the sacrifice is that power users who really do like being on
the edge are now forced to build their own applications from source. 
This used to be quite annoying, but it's gotten quite a lot easier.  I
think that the balance a distro like debian has is quite good.

But then again, there are all kinds.. and so all kinds of
distributions exist, and will always exist to promote the varying
choices.

I guess the argument is that reducing choices won't make the remaining
pool of applications/libraries/distributions/programmers more
productive.. it'll just reduce choices.


> > 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?

> 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.

I'd generally agree that there is a very plain "it just barely works"
solution for most package managers.. but.. the package manager's
metadata should be thought on at length.. just like the website is. 
It really should describe things better.  Finding a typo is one thing,
but not having a clue why an application is different than any other
application is really annoying.

Of course, at that point I install it.. and its dependancies.. and try
it out.  Then I uninstall it.. and.. am left with all the dependancies
to clean up myself.  =)


> This actually points to the curious question of how a successor
> compiled language can emerge.

I think that hobbyist developers have become vastly more intelligent
and organized over time.  If something peeks its head up and it could
posture enough to get noticed and demonstrate that it could be useful,
it'll spread like wildfire.

I'd like to think this would happen.. but I've seen some spectacular
things in my wandering, and these things have not taken off at all. 
It's really odd.

However many developers could be agile enough to change gears and try
something new, there are least that many developers who are in love
with their tools too much to play with another tool which might be
better down the road.


> > 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.

*shudder* unify them?  Why ever would one want that?  The philosophies
seem very different.. I use applications from either (because I have a
summer home in dependancy hell) and they do look, feel and work quite
different.

I happen to like KDE and could care less of Gnome vanishes, but hey..
people like Gnome and I don't dislike most people so they can have
their Gnome.  =)
--
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