Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: proper place to discuss kernel 'bloatedness'? | Date | 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/
| |