Re: proper place to discuss kernel 'bloatedness'?

Michael H. Warfield (mhw@wittsend.com)
Sun, 31 Jan 1999 15:10:56 -0500 (EST)


Aaron Sethman enscribed thusly:
> On Sun, 31 Jan 1999, Lars G. T. Joergensen wrote:
> > On Sun, 31 Jan 1999, Michael H. Warfield wrote:
> >
> > > Lars G. T. Joergensen enscribed thusly:
> > > > On Sat, 30 Jan 1999, Richard Gooch wrote:
> > > >
> > > > > Michael Loftis writes:
> > > > >
> > > > > Did you read the FAQ which is referenced at the bottom of each and
> > > > > every message from linux-kernel? It discusses the issue and why things
> > > > > won't change.
> > > > >
> > > > > > Perhaps I need to re-iterate the problem...
> > > > > >
> > > > > > I'm not concerned about speed issues nor other issues... Simple the huge
> > > > > > footprint the kernel has. Many people (like myself) run Linux on small
> > > > > > systems where popping open a 40MB tarball would overfill the disks. And
> > > > > > even if you 'clean out' stuff manually you'll probably not have enough
> > > > > > space to compile it and you run the risk of messing up the kernel...
> > > > > [...]
> > > > > > As you can see there's no way Linux could be compiled. This system will be
> > > > > > effectively stuck at 2.0.35 forever.
> > > > >
> > > > > No, you compile your kernel on a decent machine. Or get a bigger
> > > > > disc. Or download a precompiled kernel from one of the popular
> > > > > distributions. People compiling kernels are expected to have plenty of
> > > > > disc space. Think of it as an entry requirement. Don't expect it to
> > > > > change.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Richard....
> > >
> > >
> > > > Couldn't the kernel be split up into a server kernel and workstation
> > > > kernel?
> > >
> > > Define what part of the kernel is a server kernel and what part of
> > > the kernel is a workstation kernel. I don't find those distinctions anywhere
> > > in the kernel.

> > No sound, no radio, no video for linux, no strange exotic devices...
> > I don't know exactly I just know that 2.0.36 was ~7Mb and 2.2.0 is ~12Mb
> > Theres got to be something in there or else the docs just when out the
> > roof....:)

No sound, no radio, no video in what? The workstation? That's where
they're most likely to get used. The server? That's where you are least
likely to be skimpy on space. I don't see the benefit from this trade off
at all...

> I figured that most of the extra code is for new archtectures....if nobody
> else volunteers to do it I could use rm and put together an i386 only
> kernel tarball....should chop it down a bit...

That and new protocols like IPv6, and irda. A lot of people aren't
going to be using IPv6 RIGHT NOW, but a year down the road could be real
different. There are new features like the kernel nfsd in there as well.
There's lots of stuff like "appletalk" and "rose" that the majority of
users don't use (please - no flames from the people that do - no insult
intended). How about all of that ancient non-atapi CDROM stuff, can we
dump that?

I guess it boils down to the same old story. If you don't want the
features, then you complain about the bloat. If you want the features, you
complain until they are added. We're at the point now that very few
users are going to be taking advantage of the majority of the features
in the kernel. I'm personally not too sympathetic to whiners who think
that their features are important and what everybody else is using is
just bloat.

As long as we have a reasonable balance of bitching between those
who want new features and facilities and those who are complaining because
of the addition of the features and facilities that are there, we're
probably doing the best than anyone can expect.

It's useful to note that a common complaint against Linux is still
in the area of hardware support and configurations. There is still a lot
out there that needs doing. If all we wanted to support were these dinky
little configurations which couldn't support newer hardware or protocols
or features, then I guess we could all just stop right now. As long as
we want to stay on the edge of technology, things are going to get bigger.
The fact that this stuff will still run on older, smaller, configurations
is sometimes down right amazing. But we can't be held slave to those
undersized configurations either. They are still supported and still run,
but they are not going to be the easiest to support and it's going to get
tougher. Quite frankly, if they can't be bothered or can't afford the
expense of upgrading then they are just going to have to put up with a
little inconvenience. I'm sorry but that's just the trade off they are
are going to have to deal with. It's grossly unfair to hold back the
advancement of the kernel just for their convenience.

No matter what "package of features" you choose for your stripped
down kernel, you are going to end up leaving out features that some people
will whine about as important and leave in other features that some people
will whine about as bloat. I wonder if it's really going to be worth
the agravation of being put in a "can't win" situation and adding the
additional configuration and build complexity to boot...

It may be worth while to consider modularizing the source bundles.
Have a kernel "core" bundle, required for everything. Then have i386,
sparc, alpha, etc, add-on bundles for the archetecture specific stuff.
Make separate bundles for IPv6, appletalk, non-atapi CDROM stuff, mulimedia,
etc. Then you just download and unpack what you want. If you configure
something you didn't unpack, it blows up and it's a self inflicted injury.
Configuration and Makefiles will probably get a lot more complicated just
from error recovery and conditional builds alone.

The whiners probably won't like this either because it will be yet
another inconvenience to them. "Gee look at the bloat. Now we have to
unpack three packages when we could do it with one tar command before. What's
wrong with all you people. Can't you keep it simple for us?" No... Grow
with the times. Linux is continuing to advance and grow. So grow with
it. Linux still supports the older platforms but it's not going to be held
back or held captive by them either.

> Aaron

> --

> The following is a Python RSA implementation. According to the US Government
> posting these four lines makes me an international arms trafficker! Join me
> in civil disobedience; add these lines of code to your .sig block to help
> get this stupid and unconstitutional law changed.
> ============================================================================
> from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
> '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
> while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
> lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))

Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/