Slashdot Mirror
Kernel Fork For Big Iron?
Boone^ writes: "ZDNet is running an article on the future of Linux when used on Big Iron. Just a bit ago we read about running Linux on a large scale Alpha box, and SGI wants NUMA support in Linux so it can support their hardware configuration. The article talks about how memory algorithms used with 256GB machines would hamper performance on 386s with 8MB ram. So far Linus et al have been rejecting kernel patches that provide solutions for Big Iron scaling problems. How soon before a Big Iron company forks the kernel?"
Just as importantly, forks are probably necessary when a significant part of the user/developer base disagrees with the direction of the project. This usually implies that the forked version and the original version are aiming at solving different problems within the same vein. If the original project wants to continue in the original direction and some people want to use the source to solve a slightly different project, then they pretty much have to fork in order for the project to achieve its maximal result of being most useful to the most people.
This isn't a bad thing if it's done right. It's just that most of the big forks you hear of are at least partially the result of bitter, angry wars (OpenBSD anyone?). You don't hear that much about the ones which are completely amicable.
Just because a system is running doesn't mean it is running to full capacity. With any OS the default kernel/device drivers will get the system running, but updates need to be applied to get optimal performance. A few hours spent after installation will save hours in the long run.
It amazing how many don't do this, though! I've seen whole networks of machines running IDE in PIO mode on hardware that could run UDMA/33. I also supported an OS with statically configured communications buffers and cache sizes, most customers again left these at their conservative defaults. And others.
Basically some administrators are lazy. They can't be bothered to tweak their system, or install critical updates. If I had my way, anyone who didn't bother to install current security updates should be fired for basic incompetance and not be hired again!
You forget that ancient machines are not the only places 386's and 486's appear. Embedded systems generally don't need a heap of processing power, so you can get things done cheaper (and cooler) with a 386- or 486-level chip.
To take your points one by one:
1. Earlier platforms generally had no CD-ROM. Most Linux distros . . . come on CD-ROMs.
1. You install at the factory onto ROM/flash/whatever. No need for a distribution's install CD.
2. Earlier machines usually had a 5 1/4" floppy disk . . .
2. See above.
3. Earlier machines had RAM limitations . . .
3. So what? Even without limiting oneself to embedded systems, there's no real need for huge amounts of RAM besides the RAM companies saying "BUY MORE RAM". I ran Linux on a 386 with 8MB at a summer job a few years back with little trouble, and that only in the setup. (On the other hand, it would be nice to see a libc that wasn't as bloated as glibc...)
4. Some earlier machines had fscked BIOSes, aside from Y2K-unfriendly BIOSes.
4. Repeat after me: Linux does not use the BIOS. The BIOS is only used at boot time (and by DOS). And as far as embedded systems go, you can use a modern BIOS that works, or just write something simple that starts up Linux on your box. After all, embedded systems don't need to worry about being general.
5. Earlier machines had ISA, EISA, etc.
5. Modern embedded systems probably use PCI if they need anything at all.
6. Earlier network cards are not all supported . . .
6. Modern embedded systems can use supported hardware.
You don't need to fork the whole kernel, just make it support ``big iron'' as a configurable feature.
If the same code cannot handle both kinds of machines, then you eventually need both pieces of code in the same codebase, not a fork.
Forking is essential for experimentation. That's why we have tools like CVS which encourage forking for making stable releases and for experimenting with new features.
Fork! Fork!
Maybe we can get changes to the VFS and VM system now!
___________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
What I would believe to happen for the big iron machines is that they would have a different directory for them and the memory management code will be under there. So now you have the memory management for big guys and the other memory management code under the same source tree. When you compile your kernel it looks for the proper managemnt code. I know not that simple there is more to it than that but is what will happen if they fork and come back together.
2. Earlier machines usually had a 5 1/4" floppy disk, until the late 486s started really using 3.5" floppies. Most people are not going to spend money and time ripping out an old floppy.
.. at least those I used.
;D
Its probably just me, but I've never seen a 5 1/4" floppydiskdrive on anything except 286's and below. Hmm.. or maybe once.. yes.. I did see it on a 386 once. But only once.
Most 286's had 3.5" too
So, THAT is not a problem, and besides, it untrue
--
"Rune Kristian Viken" - http://www.nwo.no - arca
whyn do we need one huge kernel anyway? Probably several kernels are needed. One for big-ass servers, one for tiny-ass routers, one for mainstream workstations, and one TBD. Having one all encompasing kernel makes building the kernel a pain in the ass. I've been using linux for four years, and I still have to build my kernels a couple times before I get it right. So many freakin options, i'm bound to get something wrong.
but that's just my opioion...
-earl
One of the issues that people seem to fail to realize is that Linus is not necessarily rejectiung the patches because of what they do, but how they are implemented. If patch code is submitted to Linus and the patch is going to make mataining that system difficult (read messy unmaintainable code) Linus will reject it. Linus also does not like large patches either. He likes bits and peices and clean fixes. Hey he started this whole thing, I think he has that right.
Another thing to think of is that ZDNet is a news network. Everyone has been saying that the kernel will fork and blah blah. There are already forks in the kernel but people just don't realize this.
Redhat kernels: Have you ever tried to apply a patch to a stock redhat kernel? I know that since RH5.2 they ship the Linux kernel with there own patches.
SuSE kernels: Last SuSSE I installed (5.3) had both a stock Linux kernel and a custom SUSE kernel with custom SuSE patches.
Corel: never tries them but they patched kde and made it hard to compile other kde software with there distro.
Point? There are already forks in the Linux community, yet it goes on. That is the whole thing about open source. There can be forks. If an idea is good it gets into the mainstream kernel. But these 'forks' need to be tried first and become tested and cleand up in such a maner that they can exist with the rest of the linux kernel.
If you think that everyone is running P200 or P500 or GigHz machines you are wrong. I am sure that there are lots of people out there that are running old 386 / 486 with Linux as routers firewalls, etc. After all you do not need a superfast machine for a firewall if all you are going to firewall is 3 or 4 other machines.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
Huh????
Solaris is based off SysV 4.x. SunOS was based off BSD, but the current BSD's are not based off it, they are based off the same code it is based off.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
You miss the central issue. The problem isn't the memory thing, but should developers at these companies fork the kernel to take advantage of their hardware. You can't decide this issue by issue, but should have a grand plan for it. Otherwise, the desicion processes slows down development of the kernel.
A deep unwavering belief is a sure sign you're missing something...
Are you saying that they are forking it (as the headline suggests) or simply guessing that some day they may for it? Just fear mongering?
If they produce stable patches, that can compile cleanly in with everythign else, especially after the new kernel revs are done in 2.3, and 2.4 is stable, I bet they WOULD make it into the mainstream.
They simply don't add everything just because it's just starting. Lots of great features started out as separate kernel patches and eventually made it into the main tree.
And if they want to fork, what's the big deal? Who cares? They are more than free to do so, and produce their own. It's not like it would be any less open.. and heck, a third party can always glue them back together and ship his 'complete linux' or whatever...
Sheesh. hard up for topics today?
If 486's weren't supported it probably wouldn't be that big a deal -- there's little lost in running a 2.0 kernel, and in the future that will probably remain true. (We should face it -- the kernel is really rather boring) But getting rid of 486 support wouldn't help much.
--
Ok, one of the threats of the open source is that it will for. We've all seen the forks in bsd, and it certainly hasnt killed that. Why not a fork for big iron machines. It doesn't even have to be maintained by Linus. We have crypto patches, and the AC patches, hows about a big ass computer patch.
"My head hurts, My feet stink, and I dont love Jesus." -Jimmy Buffett
I am constantly putting Linux onto old hardware. Need a quick, dirty, and cheap NAT box? Throw Linux on a DX2/66.
MP3 file server for the geeks in IT? Throw in a big drive, but a 486 will do.
Hell, my company's web server is running on a low end PII, and I think it's a horrendous waste! It could be doing *so* much more.
Linux is a UNIX for cheap Intel hardware first. That's where its roots are, and I don't see why it should sacrifice its roots for big iron that can quite happily run a UNIX designed for big iron.
Neither does Linus, apparently.
Is this post not nifty? Sluggy Freelance. Worshi
So many things are distributed as kernel patches that it doesnt really matter. Anyone with that kind of hardware will obviously have the expertise and the money to install an appropriate kernel patch. No box that big is going to run an out-of-the-box kernel anyway, if you're using that sort of hardware, you're going to want to tweak it. As long as there is not a division in the majority of users' needs, there is not likely to be a major fork.
It depends on how pervasive the code changes have to be. If it involves #ifdeffing every single file, then it's going to be very difficult to maintain that, and it's going to be very unlikely that the maintainers of the project are going to allow that feature to remain part of the major distribution.
That problem is a dual-edged sword. It also means that maintaining one big patch is a complete nightmare. Every version of the kernel that comes out has to be separately patched, with two important considerations:
- The code which needs to be inserted has to be reinserted. If this is all separate files, that's easy, but if it's not that's a complete nightmare. And the code to call into that separate file is then a nightmare.
- Any changes which have broken the patch have to be investigated and possibly changed. If you're working on filesystem patches, for example, someone working on the core fs work may have broken your patch without your knowing it, because they're not including your code in their coding/debugging process. So every time there's a change to the kernel, you have to figure out whether that change will potentially break your work.
The only way to resolve the second is to keep the patch inside the actual kernel, so that the authors of the rest of the system are aware of it, and will either try their best not to break it, or will do first-round of changing the new functionality to work with their changes.Basically, it comes down to how pervasive the work has to be. If it's a really pervasive change which touches on almost everything, then the only option from a software engineering perspective is a fork. Anything else is being done from a feel-good PR perspective, because it just doesn't make any sense from a technical perspective to try to maintain a huge patch that covers everything.
You are forgetting about possible embedded uses for Linux. There are a number of devices with 386 clones in them running Linux in the consumer market with only 2MB of RAM. Soon cellphones, PDA's, etc everywhere will be running Linux.
"Evil beware: I'm armed to the teeth and packing a hampster!"
Lex orandi, lex credendi.
If 'linux' wants to be a mainstream desktop os? 'it' shouldn't fork?
This is the problem, folks.. linux isn't an 'it'. It's a plural, it's an ideology, and relatively loosely defined codebase.
We have compatability between distributions right now by *fluke* because noone has seen a need to change that. There is no 'rule' that says it has to stay this way.
If the community wants linux to be on the desktop, then THAT IS WHERE IT WILL GO. Period. Regardless of who forks what. If we need a way to distinguish between our 'community' supported stuff that runs on 'true' linux, and the forks, we will do so. It's no big deal, really.
Solaris IS SunOS.
SunOS V4.x was based on BSD.
SunOS V5.x was based on SysV 4.x
Solaris is the name for SunOS 5 + OpenWin
Because now is not the time.
A great many features start out as independent kernel patches.
When thigns stabilize down the road, I'm sure they will gladly put 'Big Iron' flags in the compile stuff.
The point is, linus (et al) can't just stick everyting everyone submits, big OR small, into the main kernel, especially if it's not even developed yet!
Also... the feature set for current kernels is already listed... and this isn't one of htem.
You don't just add shit to a project partway through because someone wants you to.
I'm sure than by the time 2.5 kicks up, we'll see a 'big iron' flag in main kernel options.
This makes it sound like Linus has been rejecting them because they provide solutions for Big Iron scaling problems. Having read kernel traffic and the linux-kernel list enough, this statement looks immediately suspicious. I have never seen Linus ever purposely reject a patch that's an all-around good fix for a problem. Usually it's "Well, Linus rejected my patch even though it does all this cool stuff and fixes all these problems, so it's probably because he just doesn't like such-and-such feature/platform/interface" and then Linus replies, "no, I rejected them because you're a dumbass and your patch sucked."
The link to the SGI page somewhat confirms this:
I just kinda heavily doubt that Linus wouldn't want awesome NUMA support if the potential was there. My best bet is that the people pushing for it just aren't on exactly the same wavelength as Linus (is anyone?) and it's slowing down progress.
Another quote that points in this direction
I don't think Linus mean any solution, just the solutions presented to him.
...for servers with more then X gigs of ram to use this algorithm, and for servers with less then X gigs of ram use this algorithm, etc...?
Does the name Pavlov ring a bell?
Ifdef's are one of the hacks in C that are nice if used in moderation, but you can see where this might go....
Say Linux puts one BigIron patch in, then he won't have any reason for not putting the rest in, and when you do that, you get a nest of #ifdefs and #endifs ( because they are funtamentally different than PCs, there would be a lot of changes -- the style of the kernel might have to be changed in order for the patches to be applied and keep it in a useable state).
What this means is, that it is significantly harder for kernel hackers to read the code. That is a bad thing (tm). As I read in another post, Linus will put these things in, just not in the 2.4 kernel.
-- What doesn't kill you hasn't tried hard enough.
This issue of scalability of Linux has been put to rest, IMHO.
So... the scalability of Linux has been put to rest because of an opinion on how it might work out?
In my opinion, the scalability of Linux can be put to rest if someone proves it by running it on 32 or 64 processors, and get the same kind of scalability as other OSses that run on such number of processors.
-- Abigail
IBM sure is ambitious about their embeded Linux toys, aren't they? I just hope we don't see headlines when some idiot pokes an eye out: Linux fork's too sharp; downgrade to MS Spork.
That must have been a huge increase since 2.2.13 then.
$ find /usr/src/linux-2.2.13 -name '*.[ch]' | xargs grep '^# *if' | wc -l
22022
$
-- Abigail
This is probably true in the long-run, but expecting current Linux kernel maintainers to maintain code for machines they'll never see is unrealistic. These sort of changes are going to occur at first experimentally in-house at a large corporation. That will be a fork for at least a little while. Presumably they'll be GPL'd (they better be!) so the changes can always be brought in if people want them. And hopefully the unnamed corporation will want the good karma they'll achieve by later hiring someone to help with folding the resulting code back into the regular kernel.
With GPL'd code, I don't find a (possibly temporary) fork to do something extremely specialized all that threatening; if anything it sounds like a practical necessity at the moment.
Sun microsystems delivers a kernel that runs from Sparc Classics to E10ks, without forking off "older machines".
Which is great, as you can develop stuff on low end machines and run it on large production servers, without the need to have costly development servers around.
-- Abigail
The 2.2 series kernels will still be maintained for several years after the the release of 2.4. Linus has already said that he will stop supporting systems with less than 4MB of ram in the 2.2 series. Why not raise that cap with the 2.4 or 2.5/6. I see very little reason to run a more recent kernel on a 486. Is anyone going to have USB or AGP on a 486? What about a new netcard or raid controller? Old kernels are still being mantained, so security is not an issue. It will benifit more people by raising the standard than keeping it low.
Just to make things clear, IBM and SGI don't want to fork. It would be unfair to accuse IBM and SGI from taking advantage of you if they make the effort of writing non-trivial patches, offering those patches back to the community, but see those patches rejected.
IBM and SGI want Linux to succeed. On both the big iron and the simple workstations (programs for big iron machines have to be developped somewhere, and you don't think every developper for a big iron machine has 32 CPUs stacked under his/her desk, do you?), but to do the former, changes have to be made. They don't demand from anyone to make those changes - they made them themselves. But if the people in charge reject them, what can IBM and SGI do?
-- Abigail
However, if you are forking an OS, especially for the reasons mentioned (eg. mongo huge memory management) you wouldn't neccessarily have to change the API at all, rather the underlying implementation. If I use a malloc(sizeof(int)) somewhere withing my software, and proceed to compile it into a binary, when the malloc system call gets switched to, it would use the IBM developed access my 1 terabyte of ram algorithm and then return. When I compile this on my dinky little 386, when I run it, it uses the memory allocation routine which is currently written into the kernel. I doubt that there would be any addition in the number of system calls, so as to maintain POSIX compliance, just the bells and whistles which are hidden well under the hood. just my own os perspective. matt winkle_m.at.NOFRIGGINSPAM.denison.NOSPAMDAMNIT.edu
"<BR><BR>"Sig
It sounds inevitable that a Big Iron fork will occur, and as Linus says above, this is not necessarily a bad thing. The problem comes when you have competing factions trying to do the same thing and causing confusion (as in the UNIX wars of the past). But when you have different solutions for different problems, yet everyone is moving forward together overall, it should be manageable. Indeed, it should be helpful, for it maximizes the solution for each platform.
The biggest potential problem of forking an OS is binary and API incompatibility. The reason most people use computers is to run specific applications. I want to be able to walk into my local CompUSA/log on to Egghead and get a copy of application X and run it on my computer. I don't really care what the OS is, as long as it runs application X.
If I've got Linux on my system, I'd like all applications that run on Linux to run on my system. The more forks that introduce binary or API incompatibilites, the less chance I have of being able to run the apps I want, and the more reason I have for removing Linux from my computer.
If Linux wants to be a mainstream desktop OS, it needs to make sure it doesn't fork too much. That was a big part of the reason desktop UNIX failed to take off in the late 80's/early 90's.
Sailing over the event horizon
What is bothering me about the current distributions is that they are forgetting about old hardware. I can't install Mandrake on a system with 8 megs of ram, but the system will run.. How screwed it that - the installer needs more ram than the OS!
If this Linux bloat continues, I'll just keep moving more of my boxes to the BSD's (Free and Net are my personal fav's - gotta love the deamon!)
Just don't forget that linux has prided itself on excelling on hardware that most people would call "old". As we go forward, we can't forget the past.
Driven by 100% sarcasm - fueled by the need to be heard.
Why are you downloading the whole sourcetree?
.src.rpm keep the pristine source and the patches separately before compilation).
You download it once after installation. After that, just download the patches. 1 Mb should be pretty fast, even on a slow connection.
And if the distributions would just give us a kernel source that wasn't patched to heck, it would be even easier (although I think Redhat's
Je ne parle pas francais.
Joe Hacker writes a small application to solve a simple problem. Simple data structures are used. Unless Joe is a genius (and maybe not so productive) no thought is spent on interactions between components.
The thing proves useful. Other developers contribute pathes. Initially the patches merely fix things and fill gaps, so the overall quality of the software rises. The software becomes a "polished" package.
After some time, there is a significant amount of contributed functionality that was outside of the original scope of the package. The underlying data structures don't quite fit it. As there is no coherent model for the interactions between components, people tend to just add things where it seems most immediately convenient. Quality suffers. The project is in a crisis of architecture.
The way to get out of the crisis is to take a step back, look at the new scope of the project, look at the way the current components ought to interact, including forseeable extensions, and design a new architecture. This is not a case of throwing the code out and starting again, but a refactoring of how things hang together. There will be a period of instability, but it will be relatively short.
These architectural crises are normal and the only way to have a successful long-lived project. Some approaches that don't work are:
The ivory tower: Design the whole architecture in the beginning and never change it. X11 is the best example.
The clean slate: Throw out all or most of the project and rewrite the central framework from scratch. See Mozilla.
The ancient ship: Do nothing. Continue to add functionality in whatever way each developer sees fit. Eventually the software resembles a sci-fi starship that has been patched here, expanded there, re-plumbed somewhere else...
As for Linux, it appears to do this very well with the even/odd release pattern. Every odd kernel release affords the developers a planned architectural crisis, so they can accommodate a new set of sunctionality cleanly. I am confident that the developers will find whatever architectural tool is needed (#ifdefs, macros, templates, modules...) to maintain everything from embedded to high-end systems in one code base. It may be till 2.5 though...
Pavlos
Yes, it is nice that it will still run on a 386, but there are other factors to consider:
1. Earlier platforms generally had no CD-ROM. Most Linux distros (except for fringe distros) come on CD-ROMs. Most people do not want to buy a CD-ROM for their 386, 486s. There are places that offer small "floppy-disk-sized" Linux distros, but they are obviously chopped. 1400K on a 500MB HDD.
2. Earlier machines usually had a 5 1/4" floppy disk, until the late 486s started really using 3.5" floppies. Most people are not going to spend money and time ripping out an old floppy.
3. Earlier machines had RAM limitations, aside from the fact that no one wants to really waste the money on putting more EDO memory into an obsolete machine.
4. Some earlier machines had fscked BIOSes, aside from Y2K-unfriendly BIOSes; Most people will not research whether the particular BIOS is okay to determine whether or not to spend money on the first three items.
5. Earlier machines had ISA, EISA, etc. Oh, what, you want to run GNU/Linux in something other than CGA?
6. Earlier network cards are not all supported to get around many of these limitations... I tried to get around not having a CD or a 3.5" floppy in an old 486 by using some sort of older ISA-based network card.
Obviously, there are many issues to consider before nodding one's head to allow Linus to try to preserve performance in ancient boxen for nostalgic purposes.
Lucas
--
Spindletop Blackbird, the GNU/Linux Cube.
-----------
"You can't shake the Devil's hand and say you're only kidding."
Surely checking the amount of memory at runtime and using a different algorithm based on that value is not too hard.
The process of non-standard kernel patches is just fine with Torvalds. "On the whole we've actually tried to come up with compromises that most people can live with," he said. "It's fairly clear that at least early on you will see kernel patches for specific uses -- that's actually been going on forever, and it's just a sign of the fact that it takes a while to get to a solution that works for all the different cases." He continued:
"That's how things work in Open Source. If my taste ended up being the limiting factor for somebody, the whole point of Open Source would be gone."
It sounds inevitable that a Big Iron fork will occur, and as Linus says above, this is not necessarily a bad thing. The problem comes when you have competing factions trying to do the same thing and causing confusion (as in the UNIX wars of the past). But when you have different solutions for different problems, yet everyone is moving forward together overall, it should be manageable. Indeed, it should be helpful, for it maximizes the solution for each platform.
________________
________________
Private Essayist
Even in the cases where Linus has outright rejected BigIron patches, nothing stops a hardware vendor from patching the source after the fact - almost every major Linux distribution does this now for x86/ppc/sparc etc. (NFSv3 is a great example)
Quite true, our Solaris boxes here on campus report themselves as running both SunOS 5.7 and Solaris 7.
Here at ASU the Sun guys I know in IT refer to the SysV versions of SunOS as Solaris and the previous BSD based versions which came before as just SunOS. What the vernacular terms are where you are at I don't know.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
If they fork all it would cause is a temporary fork. It will be incorporated back into the kernel any how if it is any good. If it is not good people will not use it. If they want to fork let them.
No, you're missing the point. They would need to fork because the memory mangement techniques for "Big Iron" machines are fundamentally different from low end home machines. You need to use different techniques on machines that are so different, so they won't get incorporated back into a single kernel. You will get (for some reasonably long timeframe) two different kernels as a result of this.
Now, whether that's a bad thing or not is a different question.
Sailing over the event horizon
I had Windows 2000 Professional running on my computer, and I print alot of stuff on my printer.
I installed SP1NETWORK.EXE (service pack 1) like a good user, and now when I print, it takes over 2 minutes per black and white page of text, whereas before service pack 1 it was fast as usual. I was already running the latest printer drivers for my model of printer - I checked their website.
When I installed SP1 I chose to save automatically so I could uninstall it if I had to. When I went to uninstall it, I got the error message "Windows will uninstall the Service Pack 1 but will not uninstall the Service Pack 1." I wish I had a screenshot of it.
Now my only option is to save to disk and print somewhere else, or follow THE USUAL MICROSOFT SOLUTION - RRR = Reboot, Reformat, Reinstall.
And I can't beleive I paid fucking money for this peice of shit.
Lars -
It's not a question of older but of smaller, and if you've ever compiled a kernel from scratch, you know how insanely flexible the choices are. Kernel Traffic, as others have mentioned is a must-read if you want to understand the design decisions being made.
For systems with limited resources -- embeded systems, or those mini-distribututions with under 16MB of storage (flash) and RAM -- the decisions made for the kernel in general are the same as larger systems with a few gigs of RAM and multiple processors. Read a few comments on these in KT, and the reasons will become more obvious.
I agree with others who said that this is just Ziff-Davis making an issue out of nothing, and that nearly everything can be a patch or an ifdef -- no fork needed.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I wouldn't be shocked if the stretching of boundaries that comes from:
- "Big Iron" changes, as well as
- Embedded System changes
winds up turning into there being some clear demands for forking.The fundamental problem with a fork comes in the code that you'd ideally like to be able to share between the systems. Device drivers float particularly to mind.
After a 2-way fork, it becomes necessary to port device drivers to both forks, which adds further work.
And if a given driver is only ported to one fork, and not the other, can it correctly be said that
or do we need to be forever vague about that?If you're not part of the solution, you're part of the precipitate.
Read KT. Read KT often.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Of course then you would have to ensure that both offer a similar interface so that either can be used transparently. This *could* be a maintainence nightmare. I think there are a lot of ways that this *could* be done, but it depends greatly on the details involved whether it will be practical or not. I find it hard to believe that Linus would have looked over something as obvious as ifdefs or makefile tricks, so he's probably used his (undoubtedly god-like) judgement to decide that it would be a bad idea in the long run.
Forks are usually justified only if the original maintainer pollutes the source with hacks or changes the license.
Why are the patches being rejected? Couldn't they be conditionally compiled in?
There is a patch out there that stores the computer's state to disk before shutdown and then give you an instant boot. My home machine is used that much, and my UPS needs repair. This patch would be useful for me, but I'd have to patch it in by hand and then I'd be out of sync with the official Mandrake kernel. That means I'd have to patch in security update by hand.
The problem is, this patch is as useless to Big Iron as support for 256GB of memory is to me (right now). But why can't both Big Blue and I have our way with conditional compiles? All it would take are a couple of more menu selections in xconfig.
Do you have more that 2G of memory?
Would you like instant-on?
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
Perhaps the time has come to fork the older machines.. Few of us run Linux on anything less powerful than a Pentium, and even fewer on a 486.
I don't know, it depends on where the split of cost/benefit falls.. ZD doesn't say...
`Sides, having a Compaq/SGI/IBM 'approved' kernel patch doesn't hurt much..
.sig: Now legally binding!
I'm not claiming to be a kernel expert, but forking the kernel so that there would be kernels specialized for specific applications only seems logical. A builder doesn't go around hammering everything in site because the hammer obviously isn't the correct tool in every situation. It's great for pounding nails into 2x4s, but isn't so good when it comes to painting walls.
Specialized kernels are good, so long as the support behind all of these kernels remains great enough. I don't think I need to point out the possible pitfalls of forking the kernel and thus, effectively forking the developers behind the kernel into two or more camps. But at some point, the linux kernel that runs on a 386 should be different than the one that runs on the XYZ super computer, just because it can take full advantage of all the wonderful scaleability that the XYZ super computer offers.
Anyway, as I said I'm not an expert but this just seems logical.
There's kernel "forks" for hard (deterministic) real-time (RT-Linux, etc.). There's kernel "forks" for non-MMU machines (ELKS, uCLinux, etc...). So, why not a "fork" for big iron? If the fork for big iron doesn't hinder current modern machines or improves overall operation- it will become the main fork with the one that just supports the older machines becoming like the other "forks" we see today.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
You're points are valid, but unfortunatly don't apply here.
All the examples you've chosen are either processor architecture or device driver related. Most of the code that both of these classes use in the "core" of the OS are non-architecture dependant, and are coded for best general use.
Forking the kernel for "big iron" may be required because utilizing that many resources effectively requires different algorithms at the very core of the OS - scheduling, virtual memory, caching, etc.
The advantage to forking the kernel is the simpilicity in maintaining the code for either. However, the major disadvantage -- as seen with the BSD's -- is that features in either tree just end up getting implemented twice.
It's a tough question to answer, and both choices have major long term implications.
-Jeff
you dont really give too much info on your setup,
but arent you consuming a tremendous amount of
power by running 3 or 4 machines when one new
machine could do the whole thing?
Okay, first there were systems, and the were all different.
Then someone "abstracted" them with "BIOS"
Then there were lines of systems, and they were all different.
Then someone "abstracted" them with "C"
Then there were platforms, and they were all different.
Someone (Transmeta?) will come up with a way of abstracting platforms (or architectures) and
make them "seem" the same.
This relates directly with performance increases. When you find yourself wondering what is going to make a 10GHz system better than a 1GHz system I think the answer is the level of abstraction.
Any number of quibbles can be made with the above statements, but I am illustrating a point, not
being a historian.
-Peter
The Kernel DOES NOT need to fork over this. If someone did fork the kernel, it's only because they can't design the patch good enough.
If the patch is getting rejected by Linus, it's not because he favors 386's over 40k bogoMips. It's because it is bad design. Besides, if they want to make changes to the kernel that help some people (but hurt the majority), they need to design it in a way that it can be a compile-time feature. In the same way that 1GB or 2GB support is a compile-time option right now.
Of course, it's always easier said than done. Another solution would be to forever maintain a big-iron-patch.tgz. But the reason they want to fork the kernel is because it's probably too hard to maintain a patch like that.
Another solutions would be to start another branch (alpha, MIPS, intel, and BIG-IRON), but it includes more than cpu stuff so that would be an issue.
Daniel
This was bound to happen sooner or later. The Linux kernel's flexibility is being taken to the limit, and people are forgetting the easiest way to improve performance for their particular rig: Customize your kernel! You can add all the code in the universe, and then you pick and choose the particular things you need or don't need! Say I run a 486/25 with 16 MB RAM as an IP Masq router. The hard drive is an old IDE with 600 megs of space. I have two network cards, and that's about it. Do I need SCSI support? Do I need to support joysticks, X, Pentiums, AX.25, or anything else? No! I compile a kernel specifically to run the IP Masq, and run it well. My P100 laptop, on the other hands needs a bit more. I use it for packet, so I need AX.25. It uses PCMCIA, so PCMCIA support needs to go in. I use XWS to run Netscape and the GIMP, so I need graphics. But, my HD is not SCSI. I yank out SCSI. My CPU is subject to the 0xf00f bug, so that gets included. I brew a custom kernel, and boot time is a lot shorter. My big-rig is a C433. I need just about everything, as I have a 3dfx card for Quake3; XWS; a SCSI scanner; and a connection to my Packet base station. I optimize compilation for the higher-end computers. I plan on getting a Cube from Apple and putting SuSE on it. Again, by optimizing the options I optimize my system. Get the point? If you want a once-size-fits-all kernel, use Windows. If you want a kernel which can be adjusted for your particular and peculiar environment, use Linux and customize your kernel! Now, for my laptop.
I used to be someone else. Now I'm someone better.
Real life is underrated.