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?"
Maybe this is just an excuse by Big Blue^H^H^H^HIron companies to escape from the OS community somewhat and have their "own" kernel? I know how we all love to think that once these companies adopt Linux they undergo a significant "change of heart", but do corporations ever really change in this sort of way? I bet the real attitude is, "Let's 'adopt' Linux for now, and exploit the OS community until we can get a better grip on this thing and create our own version."
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!
As I understand it, upwards Scalability on Linux is a major problem - which is why Solaris et al are still more popular for true Enterprise class applications.
- --------
The more I think about it and the more Linux distributions I try, the more convinced I become that one size does not fit all.
Linux as a workstation is is big and clunky. Linux as a datacenter server isn't scaleable enough. Linux on handhelds and wireless devices isn't as efficient Operating Systems build specifically for that purpose.
As it stands, Linux is great for web, file and print serving - which is what its mostly used for.
X11 creates a massive overhead for desktop users and the kernal doesn't scale to so-called Big Iron.
As an aside, I've tried both BeOS and the 1.44MB floppy version of QNX and am convinced that those scale downwards to handheld and wireless devices.
I'm not so sure of Linux in this regard, especially Linux with X11 and at least 4 different graphic toolkits (GRK, QT, FTLK, Fox etc).
I think it's time that Linus et al accept patches which do fork the kernal for so-called Big Iron and also for handheld/wireless devices creating three kernal streams.
It has to happen eventually and at least if Linus takes the initiative, the community will contain and control the changes. It will still be Linux, the brand will be strengthend rather than weakened.
I think this is really necessary if Linux is to achieve the stated aim of "World Domination"
-------------------------------------------------
-------------------------------------------------
It's life Jim, but not as w
I see this as the same problem the guys that want to do RT-Linux or micro-Linux. Why not have someone step up to the plate and say "Here is BigIron Linux! We will manage it and maintain it. Send us your patches
- --------
I agree except that I think Linus and the Kernal team should manage different types of Kernal. That way, it's still Linux rather than SGIs or Suns or IBMs or whoevers flavour of Linux.
-------------------------------------------------
-------------------------------------------------
It's life Jim, but not as w
Note quite true, SunOS 5.x is based on a combination of SysV and BSD with Sun extras.
The Solaris name has been used for SunOS 4.x releases as well. Solaris 1.1 has SunOS 4.1.3 is its core OS component.
Solaris is the name used to refer to everything that gets installed from the OS CDs; this is more than SunOS 5.x + Openwin + CDE + X11Rx.
Solaris is a essentially a marketing name, SunOS is the value used in the utsname structure - ie what you get back from uname -s.
what was your command line to get that number?
.5 million and freaked out and I am not getting quite the same number as you. Wondering what you are using and if you have like 2 kernels worth of files or something.
I saw the
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.
I agree, but Linus and the kernal team should manage the forks. That way, it's not vendor specific.
- --------
-------------------------------------------------
-------------------------------------------------
It's life Jim, but not as w
I really can't forking being successful. Linux has grown because of the sacrifice of the individuals trying to run a powerful modern OS on limited hardware. Remember the price gap between a Unix workstation and a PC when the whole party started? It was rather significant.
Linux is still driven by ppl working in their spare time on their home computers. As far as I know, most ppl still have
Now, I haven't done any kernel hacking myself, but if I were working on the kernel I'd feel kinda taken advantage of if the IBMs and SGIs of the world were to fork the kernel, and focus all their efforts on scaling the system, without contributing to the areas that make a difference on affordable machines (ie sub-$100K)
Linux is the People's OS. Created by the people, for the people. Yes, it is free, but I don't see any reason to sacrifice the needs of the many to enable the few who can afford machines more expensive than my house.
In fact, if I see sacrifices being made in the kernel so that it runs effectively on big iron, I'd be all for a fork to keep things running on real hardware (in the sense that you would feel ok storing your pron collection on it).
I mean, if (thanks to SCO's free[beer] licencing of the old Unix(tm) sources) there can be an effort to get a usable 4.3BSD distro running for old VAXen, I'm sure you can find ppl willing to keep a fork of the Linux kernel that remains true to its roots and ideals...
my sig's at the bottom of the page.
Why would they need different interfaces, your still doing the same thing, just doing it in a different way.
It's called "modularity", and it's a Very Good Thing.
If introducing modularity requires re-writing code that uses the module that code is Broken to start with and should be fixed.
All the memory management stuff should be done in one place, and only exposed via necessary interfaces (such as malloc()), and kernel-internals should use those interaces instead of talking directly to the mm code.
Assuming, of course, well designed interfaces to start with.
- Aidan
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.
I don't see why it's significant if the big iron patches are a 'big deal'... It's not anybody putting together a system like that isn't already paying big $$$ to somebody for a service/support deal. If anybody is going to pay more than you make in a year on a computer, surely they can spend a little more time/money patching the kernel to take advantage of it.
my sig's at the bottom of the page.
Hey this was to win a bet. Cant blame me if i want to get some money off of a poor sap can ya?
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
At this point, you are a fork just renamed. Anything that is added to 'foo.c' would then have to be merged into 'foo-garbage.c' or 'foo-bigiron.c'. Soooo what have you gained? Nothing.
There is absolutely nothing wrong with a fork if whoever forks takes on the responsibility of forever merging the tip changes onto the fork.
On a personal note, it is nice to see you GPL boys now possibly having to code with real-world issues like forks and specials. I don't mean it as a slam, just an observation.
The last thing Linux needs is more installation and setup complexity.
That is not what I meant.
I thought I avoided that confusion by saying "platforms (or architectures)."
To be clear, there will next be an abstraction of platforms (architectures), not to be confused with an abstraction of platforms (OSes).
What I meant is that the next level is something like Transmeta's code morphing software which will "abstract out" (or "make transparent") the hardware
architecture. This will make it irrelevant to OSes (be it Windows 2006 or Linux 4.2.x) whether the system is a sub-palm with a scant 256 megs of
RAM, or a super computer with 1/4 T of RAM (or whatever.) This is the subtext, which you seem to have missed, which makes my post relevant to
the article, which is about Linux possibly having to fork to properly support the growing rift in supported architectures.
I'm not really sure why I am even replying, since your sig clearly demonstrates that you are going out of your way to mis-understand.
-Peter
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.
What about an optional switch during the install? Include support for both memory management methods an allow the user to choose. Of course the default would be standard and optional would be BigHonkinMem.
Yes ... after all, it's not as if people are looking to run Quake on big iron.
/me pauses to look at the Alpha thread
Never mind ...
=) [on a serious note, I agree ... so *what* if development forks, would it really impact the average user all that much?
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
According to the latest stable kernel's Release Notes, there are separate source trees for MIPS, ARM, 68k and S/390. Looks reasonable too, it's a wildly different architecture. Heck, IBM themselves could maintain it.
I'm surprised that RedHat or some other big dollar linux company hasn't already begun R&D on something like this. Perhaps no one believes the market would support the amount of money it would take to develop and support it?
I'm on a chair.
Where can i find this kernel patch for instant-on, I am definately interested
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
No, that's how Microsoft tries to cope with some truely abysmal hardware out there, something which Linux doesn't do. For example, any fool can throw together a sound card from one or two chips and some analogue glue these days - the results are sold NEW for $15-20. No-one in their right minds would try to use one, and the WHQL exists to speed up the process of finding out which are the turkeys.
I hope I'm not too rendundant: I don't agree. One of my issues with Microsoft is that MS is in bed with HW manufacturers, so that they can sell faster and better hardware that Windows requires.
I agree that we do need faster CPUs, but not just because the OS demands it. Linux is the best example and proof: you can add features to the OS; while still being able to install it on your 486.
I myself have two 486 running Slackware, and they do their job amazingly well, just as an Athlon 1 GHz would have done. But I don't want to be forced to buy an Athlon 1 GHz just because someone decided that I don't need my 486 PCs anymore.
Sigged!
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!
I can continue to run my favourite ZX Spectrum games under MAME under MS-DOS under DOSEMU under Linux under S/390 !
First fork!
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.
My 800MHz Athlon system has a 5.25" floppy drive "just in case"!
It's because:
a) I upgrade my systems rather than throw them out
b) I started with an old 486-33 system and this drive and the keyboard are the last remnant of it.
c) I write software for embedded systems and you'd be surprised how long some systems remain in operation.....
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
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...
I see the original poster already replied, but here's my answer: sure. I have 3 boxes at home with a fourth being built, and I wish I had more. Not because one can't do everything I need it to, but because I want to play around with a real network, not the typical linux server + windows workstation that seems to be fairly common. I now have freebsd, debian, beos, redhat, qnx, and soon, windows me all loaded on different partitions, but how am I supposed to learn about the different ways they interact if I only have 1 or 2 machines? That, and I always load one machine as my server to handle email and internet access, and then don't touch it anymore, other than updates. I can then load and explode everything else with impunity, and not have to worry about whether or not someone is trying to send me email whilst I'm frantically reloading my drive after a failed experiment with dd or fsck :-) Anyways, just thought I'd drop a line explaining why *some* of us have no problem "wasting" gobs of electricity on multiple computers. Pure hack value ;-)
Linus is probably rejecting this because:
- 2.4 is frozen and is not accepting any more major changes. If he doesn't stick to his guns here we wont see 2.4 for another year or so.
- The 2.5/2.6 list of kernel changes and additions is still being drawn up.
- The patch probably needs improving so not to cause slow downs and problems for 99% of users. Some more thought needs to go in here. Yes a extra feature might be really good but Linus wants to keep the kernel nice and not turn into one huge blob, he's already talking about structural changes to increase the modularity while maintaining the efficient monolithic core of Linux, this will take some work. Maybe Linux 3.0?
So lets not complain, but ask why? Linus is a logical guy, but sometimes we can't always see his reasoning.I do think however that Linux is getting so big that Linus will have to change the way patches are integrated and accepted, he's going to have to delegate more and become more concerned with Linux's overall direction and working with the big companies while also working in the interest of the community. I think the US government should pay for this even, why not, they pay for NASA and Linux is alot more use to citizens than a space shuttle.
There will be no kernal split - Linus has agreed to put it in -
Geesh...
There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
S/390s, Starfires, Wildfires, SP clusters. All scale to 1000 processors+, many gigabytes of RAM, pushing a petabyte of store (soon)
Itty-bitty palm-top, wear-on-your-wrist PDAs. One processor, 2Mb RAM, no permanent store.
Linux runs at both extremes. Inefficiently, but it runs.
Now, you want to manage this scalability with the preprocessor. Well, that's nice. Off you go.
One day, you may get to work on a large software project. Clearly, you haven't done so far.
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.
I think one reason that some stuff isn't going into the official standard kernel is that there's no way to put code into the official kernel such that people who don't want it don't have to download it. It would be really helpful if you could run a configuration pass, and then download only those files that you were actually going to use. That way the kernel sources could get really big, containing all the patches and versions of stuff that are probably good ideas, without making it impractical to get and unpack.
There's no real reason there can't be different official memory managers for low memory and high memory situations, since there are clearly different issues. Of course, at this point, lots of people testing a single one is important.
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.
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. It is not a matter of patches, it is a matter of designing the kernel. Have you seen what happens to the linux kernel above four processors? Nothing it flat lines, no improvement. What about other Unices? SCO and Solaris are both scalable. Even that dread OS from Redmond Windows NT can scale well up to 8 processors. Here comes my point. The current linux kernel run fine for my machines at home, and some servers here at work. But the BIG IRON, no way. What was the big iron two years ago. Pentium II/450 What is that average workstation at my workplaces Pentium 450. My point is the Big Iron of today is the workstation of tommorow. We need to get the kernal working now for these machines.
The posting above is just this
Right now, for example, if you want apache HTTPD threads at the kernel level, there is an option (in make menuconfig atleast) to include this support, it isn't included by default.
Couldn't it be worked out like that? Include the patch into the kernel, have it disabled by default, but have a accessiable method of readily adding support for it?
No I am not a kernel hacker or (real) programmer, that is why I am asking.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
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
All these talks about linux on big iron.. so when will I finally be able to run Apache on a tire iron ?
Imagine a beowulf cluster of tire irons. Now that would make a great stress reliever.
-Billco, Fnarg.com
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.
i've not tested it, but now that i've got a laptop ;)
and windows people to impress, i just might give it a go
-
sig sig sputnik
-
sig sig sputnik
Such changes as would necessitate a fork (e.g. Big Iron) are much more pervasive than just a driver/filesystem/workaround module load, or recompile. For example, kernel threads and locks will probably have to be added on many levels to keep concurrency levels high. The main reason that systems such as Solaris and Unixware display markedly lower performance on a uniprocessor than a simpler system such as Linux, but (near) linear scalability on multiprocessor systems (up to dozens of processors) is that they contain more abstraction layers and synchronization points. Enabling Linux to support massive multiprocessors/CCNUMA/Supercomputers while keeping performance high on simpler hardware will necessitate huge reams of code to be put under #ifdefs, which will render the code extremely hard to maintain reliably.
The result is that a kernel fork will probably be inevitable. I think the most productive direction for Linux on Big Iron will be by emulation/compatibility layers over OS's tailored to such high-end hardware. For example, UnixWare's Linux Kernel Personality. By running Linux applications on a kernel which is easily capable of scaling to dozens or hundreds of processors and many GB of memory, we get the best of both worlds: high performance, massive choice of applications, and Linux system behaviour. Once a compatibility layer is in place, all that remains is to arrange the Linux (sub)system management utilities to behave in a consistent manner, hence what will be needed is a Linux _distro_ tailored by the Big-Iron vendor who is pushing Linux on their boxen.
There is no reason to stick to a top-to-bottom "Linux Universe". Let the big boys do what they do best (big, expensive hardware and kernel tailored to that hardware); there is no need to replicate their work. Many sacrifices will have to be made (e.g. low-end performance and kernel code maintainability) if the Linux kernel goes the one-system-for-all way.
Why not make the large memory algorithms an option, that can be enabled by the user at will? That way, both algorithms can remain in place.
You could have something like these two kernel command lines:
linux mem=8M
linux mem=256G memalgo=large
Then, different users could pick the right one for their needs.
I sure hope the kernel doesn't fork. We do not need NetLinux, FreeLinux, OpenLinux...
Dr. Demento On The 'Net!
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.
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.
True, but "when your only tool is a hammer, all your problems start to look like nails." (Not sure where that's from, I read it on someone else's email sig)
...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?
Also, I'm assuming Big Iron has something to do with clusters, or huge ass servers, but would someone mind posting an explicit definition?
Thanks.
Those who don't know me, probably shouldn't trust me. Those that do know me, DEFINITELY shouldn't trust me.
A fork isn't all that bad an idea, but it should be more of a coup by people who are more interested in seeing Linux grow.
It is silly that every time a new kernel gets installed, I have to patch it with MOSIX before I compile. Why can't MOSIX code just be included and compiled in with a switch set in my Makefile?
Screw Micro$oft.
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.
I totally agree 'not an issue'. What puts the OSS kernels apart from all other kernels out there? The capability to start configuring before compiling and that the end consumer has this possibility. so use it. If that means several different schedulers fine, as long as they all have the same interface to other parts. #ifdef is not the only show in town.
a sig with any other name would be as witty
I'm afraid your information is out of date. A cursory glance at Kernel Traffic indicates that Linux's "scalability of the most common workloads is limited by hardware (ie. the kernel lets those workloads scale 'down to the metal')."
In said same conversation, they mention that "I would be surprised if we had any serious problem at 32 or 64 CPUs."
This issue of scalability of Linux has been put to rest, IMHO.
My 386 linux router had one, until I moved it into my PIII-450. How else could I load those old original 5 1/4" games.
Omega runs so nicely on a PIII.
Now go run along and be a good little slashbot.
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
The installer doesn't have the benefit of the swap partition, like you do after boot. There's also the overhead of having a ramdisk. It's the price you have to pay for getting a GUI-based installer. Slackware or Debian would both likely install and work well on a 4MB machine (I don't remember if RedHat still has a text-based installer or not). A basic Linux kernel, initrd, a minimal version of XF86 and the installer easily eats up 8MB.
I used up all my sick days, so I'm calling in dead.
Also, if a Big Iron fork does take place, will the public support a corporate driven project, or will we look to Linus, Alan, and the bunch to maintain that tree as well. How much access do those guys have to Big Iron anyway? Not much I guess. --- Hell I'll maintian the fork if IBM and company will give me the hardware
"<BR><BR>"Sig
I don't claim to be an expert on the subject, but SGI might as well create a new fork of the kernel. The advantage to the Open Source Model has always been the ability to create the right tool for the job.
Provided they aren't competing with the other kernel maintainers, then it doesn't seem like it would be much of a problem to let them do it their way provided they keep up with the new features in later kernel versions. Besides, the kernel that powers a Cray should have different / more / better options than that which supports a i3/4/586 simply because there are more complex and advanced features on the Cray.
As long as SGI keeps with the program and doesn't start adding all kinds of "closed source" mumbo jumbo in their version of the kernel, then all should be happy.
Anyway, thats my two cents..
-- 'knowledge is power. power corrupts. study hard, be evil.'
http://linuxcare.com.au/anton/e10000/maketime_24.s html
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.
This guy seems to have a clue.
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Second, this wouldn't be a bad thing. Who says that the Linux that boots from single-floppy rescue disks and runs in routers has to be the same basic kernel as all other Linuxs, on any hardware? There's bad forking, such as what we saw run Inix into the ground, and then there's specialization for different uses and hardware. Maybe we need to stop calling the later forking, since it's such a different thing, and has such different results.
Monolithic OS, OK, but the monolithic tarball is getting a bit large...
Wade.
I don't pay money to report bugs to the manufacturer, I report bugs for free software.
Lars -
Have you tried installing in text mode?? When you start the install there should be an option to bring up install options (Hitting when you see the first install screen I believe). This should install fine on older hardware (in fact I sometimes use it on newer harware, less video card problems with the GUI installer).
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
Yeah, I think my mistake was being right. Trolls hate that, especially when they've got mod points.
Quidquid latine dictum sit, altum viditur.
And this would be one hell of a lot easier if Linux was a microkernel. And telling me that monolothic kernels are better is like telling me cooperative multitasking is better; it's preaching what you practice, rather than practicing what you preach.
--------
"I already have all the latest software."
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
Where are the P2/P3/K7, SMP, IPMasq/ed -O3 optmized distributions?
Which I had time compile everything!
On with the Modern Iron! :)
I have an idea!
Lets do what Microsoft did with w2k.
Lets have have Linux-ce for pda's and appliances, Linux pro for standard workstations and low to mid range servers, and Linux enterprise for the new alpha machines and sun boxes with 256 gb of ram!
We can all do this after 2.4 is released and we can base all 3 kernels after 2.4. This is the only way I can think of that will satisify everyone.
It is rumoured that Linus is interested in real time computing after playing with qnx and beos and he wants to add it in 2.5. The problem is it will hurt scalability after a few processors and will be hard to do with lots of locks. The solution?
Put it in linux-ce and linuyx pro only and leave the scalability in Linux enterprise.
What do you guys think?
What you say is partly true. BUT, we still need Linux to run on older and smaller devices like cellphones and other embedded systems. Linus just wants the kernel to scale well across low-end and hi-end hardware. Also the 386 memory model is the foundation of the pentium range, not just 386s. Hope that helps you 'get it'.
But Hemos doesn't know a nine iron from big iron! Hehehehe. :)
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.
Why couldn't they implement both algorithms, and have users choose between them with "make menuconfig"?
--
Patrick Doyle
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Now I know what that one guy's .sig means "The wheel is turning but the hampster is dead."
Lars -
FWIW, grep and wc report more than half a million #ifdefs in the 2.2.16 kernel.
Wade.
-----------
"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.
There's a simple way to find out. Do you currently have moderator points? If so, you're probably smoking crack. If not, you're probably clean.
(Note to moderators: This post is meant as a joke, not a flame. It's not flamebait. I have nothing against you, and I'm sure you're all very nice people, when you're not high on crack.)
I am the real Anonymous Coward. Anyone else who claims to be me is an imposter.
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.
While a really really cool hack, I seriously doubt you could actually put memory management in a kernel module...how would you load it? How would you run modprobe? You kinda need memory memory managment for that.
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
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)
Agreed -- I currently use several 486's to provide services, but I'll be consolidating them onto my existing workstation when I upgrade, in order to minimize power usage.
:-) K6-2 @ 450 Mhz.
Of course, since I generally buy well behind the hardware curve my server will still be considered underpowered
"Nothing was broken, and it's been fixed." -- Jon Carroll
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.
Excellent! works great, including X and ethernet. I resume exactly where I left off. This helps my company alot, we are working on a linux based internet appliance and was looking for an instant on feature. This will work great!
Posted by polar_bear:
I don't think providing patches for memory managment on big iron really is any cause for concern. This isn't the same as the Unices forking and becoming almost wholly incompatible - this seems to be a patch or line of development for specific hardware that wouldn't really cause any disruption to the rest of kernel development, and no disruption whatsoever to the remainder of the tools that make up Linux distributions.
The danger would be if Red Hat or SuSE or someone like that started doing ugly things to make their distribution incompatible with the others in mainstream use. Since Big Iron servers are such a rarified environment, they're not very important to the average user.
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.
Oh oh, this is one of those "praise linux" and get a mod point posts?
:)
You talk like because Linus says its bad design it just HAS to be terrible. He is ONE person and he is NOT perfect.
Big Iron is easy, you download the patches at a distro level, have a few kernels with the patches applied and or, have pre compile dstuff (not that common)
Soo.. Bleh, I hate it when people talk about linux liek hes omnipotent.
Jeremy
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.
I would love to see how well big iron will perform running Linux. Linux's strongest point is stability and IO. Big Iron's strongest point is, well, Stability and IO.
:(
One concern that I have is that the GPL could deter changes from comming. Corperations don't like the idea of giving something for free (altho it looks like IBM, Compaq and SGI are pushing for support). Also it seams that because of the Open Source nature of Linux, the Military (at least where i'm stationed) will not touch it. which is a shame because i could have used it in my last project
Sanchi
P.S. I am having a problem with X. It crashes when i look at it wrong. I happened when I changed my Video card from my GeForce to my VooDoo3. (and it works fine with my GeForce) E-Mail if you can help please.
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
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
    A special tree would be made for the 'special directive' code, when you need it, you download it, hit the 'Special Directive' option in the kernel configuration program, it gives you a seperate dialog box for the extra-code (or optimally, it knows what options go with which configuration boxes and changes the config options intellegently), you compile, and everybody is happy:
  You are happy because your 80 terraflop supercomputer the size of a small state is running what you consider to be a well refined and sophisticated operating system,
  I'm happy because I didn't have to download kernel source for hardware I'll likely never get to see,
  J.Q. Hacker is happy because his system of configuring the extra code into the kernel (in an intellegent and automated manor) got picked up and works splendidly.
    Forking projects divides efforts and invariably duplicates efforts.
    Duplicated effort is waste.
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?
"Should the Linux kernel group be dictating to hardware manufacturers how to architect their systems? Of course not."
Ummm, isn't this exactly what Microsoft does with its Hardware compatibility list and bus/driver specifications?
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
What is preventing the Linux development gurus from compiling different memory algorithms or Big Iron neccessities into the kernel depending on what architecture #define's have been made?
;) ...
I can see how Linus and the crew don't want megs and megs of source code that is specific to certain architectures, and that as much of that code should be consolidated as possible, but is there *so* much code that has to be changed in so many aspects of the OS that it requires maintaining a completely separate tree?
Also, if a Big Iron fork does take place, will the public support a corporate driven project, or will we look to Linus, Alan, and the bunch to maintain that tree as well. How much access do those guys have to Big Iron anyway? Not much I guess.
This isn't a smug post, it's just a legit query. I'm not up to speed on many of the quirks involved in OS kernel development
"There is no knowledge that is not power"
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.