Messages in this thread | | | Date | Sun, 31 Jan 1999 21:35:21 +0100 (MET) | From | "Lars G. T. Joergensen" <> | Subject | Re: 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/
| |