lkml.org 
[lkml]   [1999]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proper place to discuss kernel 'bloatedness'?
On Sun, 31 Jan 1999, Michael H. Warfield wrote:

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

You have a good point I can't deny that. But what I'm looking is logic
splitting of the tar-ball. The server/workstation thing was just a
suggestion. Here's another suggestion :)
The source tree has a logic build up right now couldn't one use
that? So you got the scsi src in one tar-ball the ide in one and network
in another?


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

/Lars
Student at Department of Computer Science
University of Copenhagen
http://www.diku.dk/students/larsj/


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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.051 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site