HURD For 'Big Iron'? 151
Julian Stoev wrote in with this query: "Recently I've seen quite a lot of conversation about Linux on 'big iron' and talk about a possible fork due to the fact that the Powers That Be do not want to include the necessary features that are necessary. A guy from IBM in an interview sounds a little desperate. He sounds like IBM is not very
happy with Linux's direction to small devices. The guy is cautious not to make kernel people angry and does not speak directly about kernel fork. But why don't they (IBM, SGI, et al) grab HURD and add to it all the things they find important for 'big iron' support?"
"HURD is not good for smaller machines because it needs more memory, but for big machines/clusters it can be very promising design. Why don't these vendors who moan about the lack of 'big iron' features start a 'HURD foundation' to help uplift the sleepy project? They could add compatibility for Linux binaries for compatibility, even which would be great as there would then be a powerful kernel (HURD) for 'big iron' and Linux for smaller and embedded systems.
Yes, HURD needs quite a lot of work to become stable, but large vendors have the resources to give it a push. In this way they will prove that they really appreciate open source by helping a project which is going through some hard times right now."
Re:HURD has almost nothing (Score:1)
And HURD is? (Score:1)
Regards
Re:Not a Misconception (Score:1)
Re:Run BSD instead. (Score:1)
Not to rag on openbsd, I'm sure it's a great system, but be careful saying what's actually a supported platform. That's like saying netbsd runs on almost anything. Sure it does, but you may have to netboot the machine, run the file system off a better supported computer over NFS, and use a serial login. So basically you're using the CPU on your machine and the network card, while the Hard drive, video, keyboard, and mouse go to waste.
Also, 99% of the code within different Linux distributions is the same. Instead of just borrowing code between different distributions (or forks, in the *BSD case), the different distributions actually use exactly the same code, it's just the packaging which is different.
One Caveat, with the change of license of OpenBSD such that they can directly incorporate NetBSD code, I expect the code between these two forks to become more and more conserved.
The BEST description (mark up please) (Score:1)
Macka
Re:Linux Torvalds has been working on Crusoe linux (Score:2)
not interested in your random assertions.
I gave you some places to start looking for what the
thought process is on the kernel mailing lists.
If you really believe this, why don't you fork the
code and maintain a big iron kernel on your own?
It's your right under the GPL and there is nothing Linus could possibly do to stop you. _If_ this is Linus goal (which I don't believe for an instant... I think it's much more likely you have some kind of agenda), we can just say "So Long and Thanks for all the Code" to Linus and take Linux back. That is the beauty of Open Source code....
---
RobK
Re:because it's only available as unstable on i386 (Score:1)
No this isn't an issue.
Yes the IBM fixes will get in.
Yes the IBM people are being too impatient and not conforming to the development schedule.
DOES ANYONE REMEMBER 2.4 IS IN A CODE FREEEEEZE.
HELLO? PEOPLE?
Freak.
When 2.5 comes out, by the time it gets to 2.5.10 if the IBM people still havne't worked out the development speed for getting their stuff in, then it will be an issue.
But not until.
-Nathan
So modularise already: N-Kernel Monte, anyone? (Score:1)
This may smell too microkernel to please some people, but since some anwesome things have been done with kernel modules already, why not a few more? If somebody wants a new feature that speeds some things up enormously but requires (say) 8 megs of RAM to start up, why not do it as a kernel module?
That way, your distro could boot ``minimised'' and then load the module if appropriate (Hmm. This is a 2MB 386SX. Should I load ramgulper.o?).
One way of doing this with extremely core items would be to make the core item as a pre-loaded module; that is, the code is a module, but a copy of it is compiled into the kernel so it is present at boot (you might conceivably need some memory management, for example, to get to the point of being able to load your new ramgulper.o hyperfast memory management kernel subsystem module).
If Two-Kernel Monte can replace an entire more-or-less running kernel on the fly, surely it is not much more technically difficult to replace significant subsystems on the fly?
As to the idea of splashing out with the cash, the problem isn't the cash itself, but getting the companies to commit. Politics and memes are bigger blockers than dollars ever were. If this kind of thing is shown to work, no matter how shakily at first, you will get some joiners from false-floor territory.
If Bill Gates could sell an 8080 BASIC interpreter to MITS more than eight weeks before writing an alpha version of it (ie, it hadn't even been planned when he sold it), what's stopping ``us'' from ``selling'' advanced kernel features to IBM or Fujitsu a few weeks from now, by which time the bones of them actually exist?
Re:heh. Silly rabbit, don't you know HURD is for.. (Score:1)
Linux is in the pre-2.4 code freeze. The stupidity of people not connecting that with the fact that IBM can't dump 10MB of patches in to change the systme components in is the issue.
IBM knows what ifdef is. They just need to figure out how to work with Linus' kernel development system.
-Nathan
who? where? (Score:1)
Pointers? to the interview? or at least who was it with?
"[...] large vendors have the resources to give it a push."
umm... not really, resources are VERY tight in most companies - ask the architects who have in the last few months had their grand vision killed because we can't get enough skilled people to implement and support them? (remember that in manager speak YOU are a "resource", not the hardware, or the lab space, or the desk.)
What disadvantage of a linux major and minor? (Score:1)
Why would it be unreasonable then to have another division between a linux geared more toward embeded systems and one toward large scale systems?
There is much concern that compatiblity will be lost. Is there not a way to change the engine without changing the leather seats, so to speak?
I'm not clear about where exactly the resistance comes from.
Re:Run BSD instead. (Score:1)
But leeching is considered ok, because everyone who works on BSD can do it too. The Walnut Creek/BSDi employees who run FreeBSD will incorporate everything good into closed source BSD/OS. The closed source version will always have the most advanced features.
The model is sound, it's the model BSD has used for 20 years. It's helped commercial UNIX venders, and UNIX venders rewarded Berkeley with equipment donations, research grants, and jobs for BSD developers. BSD code became a shared resource, a skeleton which commercial closed source venders can use to make a finished product. The model just has nothing to do with promoting open source over closed source.
IBM's plan (Score:2)
Re:Linux Torvalds has been working on Crusoe linux (Score:2)
part of commercial distros anyway.
I can fully understand him not accepting patches that are going to end up being a _lot_ of work to satisfy less the 1% of his "customers." [either as a maintainance issue or initial reworking of the infrastructure.] In terms of effort spent, it may simply not be worth it when the people who make these machines can easily make their own kernel. People have (for example) been using the devfs patch for quite a while and it only just got into the kernel in 2.4. I don't remember any conspiracy theories about any of the thousands of other patches Linus turned down...
Also, it could just be that the thought it was too late in the 2.4 development cycle for such a big addition.......
---
RobK
Re:Because H[UI]RD ain't cool (Score:1)
Scared is not the issue with hurd vs. Linux on the desktop/server. HURD being what IBM is helping to make Linux for Big Iron is a scarry thought.
If I were IBM I would be scared of the amount of control RMS exercises over GNU/HURD. I mean think about it, he wants to be able to insist that people who use any of his code use the GNU/ extension to the product name.
It's not GNU/Linux dangit (unless you run Debian but I don't care what that is called, it just kicks ass.)
If I were IBM I would not want to lay hopes and development money on a system driven by a fanatic (granted a good intentioned one) who lets his ego govern the direction of the system.
-Nathan
Would they have any more control over Hurd? (Score:2)
If so is it not reasonable to believe that the vendors would find it just as restrictive (if not more so) working with the Hurd?
Re:Does anybody know what the HURD IS? (Score:1)
database access:
grep query
wget equiv:
cp -r
/EVERYTHING/ _IS_ a file/filesystem !
Back away Amiga/Linux zealots - the HURD Religion is coming !
(too bad i couldn't install-it on my machine due to hardware incompatibility
--
Re:because it's only available as unstable on i386 (Score:1)
I have more questions, but if you could answer these one's first I'd appreciate it.
A fork would be good; they should do it (Score:4)
It would be good for SGI, IBM, HP, and other big players to create an Advanced Linux Kernel Project. I would even host it (I'm a director at a hosting company) and contribute code (filesystem, device drivers, unicode functionality).
Even if the Linus-headed effort is the One True Way, it doesn't have to be the Only Way. They're not infallible. Let's get a second project going! It won't be a threat to Official Linux -- just a development track for enterprise situations!
Email me if you're interested!
________________________________________
Re:HURD has almost nothing (Score:3)
- massive momentum
- probable emerging standard
- huge (unpaid by them) developer community
- existing high-quality implementation
- existing widespread hardware support
- easy to find techies who know it
- non-techies are comfortable with it
- liberal licensing
Now which of these does HURD offer?The question should be: Now which of these does linux offer?
Are you really telling me that linux offers *any* of:
- probable emerging standard (don't make me laugh - linux is anarchy - BSD is more standard since it is committe based)
- existing high-quality implementation (have you ever looked at linux code? And it changes every two minutes)
- existing widespread hardware support (DVD? Hardware RAID even?
....)
- non-techies are comfortable with it (please
...) - Liberal licencing (GPL!!!)
And as for stuff like "massive momentum", you must remember that the momentum behind linux is its use as an application not as an OS. Linux boys use linux as their primary app, not as an OS to run another app. Their app *IS* linux. It *IS* spending the whole evening downloading the latest Hungarian font patches and recompiling the kernel just so their system is "complete". Ten minutes later they're downloading the next patch that is issued, for hardware they don't haveRe:And HURD is? (Score:1)
Since HURD is a mutually recursive acronym, it's quite hard to say the entire phrase. :)
It's the GNU kernel [gnu.org], which has been in development for well over a decade, based on the Mach microkernel. And yeah, it's still not ready for prime-time, although you can install Debian's unstable distribution for it. The Kernel Cousin project has a section for its Debian mailing list [linuxcare.com].
A serious reply... (Score:1)
A previous one is also accurate, in that all the big commercial vendors have their own proprietary Unix variants (AIX, HPUX, Solaris, plus whatever Compaq's calling DEC-Unix lately). These systems _all_ suffer from their previous, self-inflicted incompatibilities (the forked-Unix conundrum, complete with fragmented market shares and some evolutionary dead-ends).
Linux offers a way out of this dead-end for these very large commercial vendors, and IBM for one is adopting Linux for this reason (plus some others already mentioned). But their intent isn't for replacing their bulletproof, decades to perfect, commercial Operating Systems - instead, its only to expand their offerings to include recent technologies (like IBM held its nose about NT).
I'd like to see a good analysis of how well (or badly) each of the major commercial hardware and software systems vendors are adapting to Linux.
Re:HURD has almost nothing (Score:1)
I use FreeBSD, but OpenBSD would also be fine. As would BSDi. And NetBSD if I wasn't a PC user.
Regarding linux kernels and their so called high kwality implementations: I would not dream of using a linux kernel, since I need a reliable datastore. When linux gives me raw devices, I might consider using it.
Translation: The day I can tell when to remove a floppy from a drive by not looking at the light but looking at the command prompt returning, is the day I'll use it - since some programs *NEED* to know when data is on disk. Linux doesn't give me this.
And don't spout on about reiser fs etc. since that is a) not reliable and b) not in the linux kernel - for exactl;y the same reasons that the Big Iron patches aren't in the kernel - Linux Torvalds himself.
DVD is supported...just not every DVD device. Hardware RAID is largely a non-issue...that's why it's hardware RAID.
OK, I see one or two DVD device are supported. But we're still a year off having good support and having it mainstream. Not so for windows.
Drivers for hardware RAID, on say, Dell servers, are not supported. I know - I tried to find one recently. The only options for linux are software RAID (joke - there is no raw device!) and transparent hardware (very expensive).
KDE or Gnome, for two examples. Once given 'the computer', most people don't care or see any real difference; examples - two of my sisters.
Please don't compare KDE (and definately not GNOME!) to Windows. The day I can cut and paste and drap and drop OBJECTS (i.e. images, spreadsheet cells, text with font information, etc.) from one app to another, is the day you can compare the two. Until then, WINDOWS OWNS THE DESKTOP. You are dreaming if you think otherwise.
The GPL isn't entirely free, but it's damn close to it and largely misunderstood.
I understand the GPL. That's why I never submit bugs reports or fixes to GPL'd projects.
Re:How are people defining "big iron"? (Score:1)
Oooh, that hurt didn't it. I repeat: perhaps "Big Iron" means files greater than 2 gigabytes? Hardly an unreasonable request for a machine with that size main memory?
For all of you that are not aware of this: LINUX CANNOT HANDLE FILES BIGGER THAN 2 GIGABYTES.
Here's another one: Perhaps "Big Iron" means a single large swap file, instead of lots of 128 meg ones - Ha de ha :-)
Re:Why not? Because... (Score:1)
IBM is spending an incredible amount of money on the Linux issue, it's just going to take time for their managers and development people to understand how life works when the other 9/10 of your development team is outside the company and under no contract whatsoever.
-Nathan
Re:Run BSD instead. (Score:2)
Turned out that it had an IRQ conflict with my soundcard. Since this was on my firewall, I just took the soundcard out (who needs to listen to MP3s while they're routing packets?) -- But since then I've had zero problems with NE2000 cards.
Re: NetBSD (humor) (Score:1)
You blasphemer! The NetBSD kernel runs on ALL platforms, not just most!
This man must be taken out and shot for his heretical views!
-----
Re:Can one Linux fit all? (Score:1)
However, using the magic of ifdef and SOURCE (you remember the source that kernels get compiled from right?) you can have one source tree with multiple targets with multiple abilities.
It gives a central focused driving point for a movement. Yes the source is and will be huge with 30% of it actualy being for a users system, but as UNIX learned the hard way,
Splitting the development into different paths is not the way.
On a side thought, look at how RT/Linux is getting it's ass kicked PR wise now that another vendor is going to make the mainstream Linux Kernel RT. Time to backpeddle boys.
-Nathan
Re:IBM doesn not care which direction goes. (Score:1)
At first I was amused when I read this. "Resisting forking the kernel"? ANYONE can fork the kernel (and any piece of GPL'd software) as they see fit. If IBM wants a mainframe-optimized, heavily altered Linux kernel to run on they machines. they can do it NOW. It's them who are resisting, not Linus. But then I started to think, why?
Buzzword compliance. Linus can't stop a kernel fork, but he CAN stop people from calling such fork "Linux" -- it's a trademark. And IBM wants badly to shout to the media, "We run Linux!" It's a better PR move. That's why they're trying to coax Linus into cramming the mainframe changes into the main kernel tree. Linus won't do that, and rightly so IMHO.
On the other hand, IBM could do the fork and negotiate a "blessing" from Linus (read: buying the right to call the new kernel "Linux something" for an obscene amount of money). I'd guess that's what's going to happen eventually.
Re:HURD has almost nothing (Score:2)
Your objections are largely valid, so I'll not try and talk you out of them.
As for the horrors and defects of Linux; I generally agree. I know it and other *nix aren't perfect...far from it. A Hummer isn't a Porche, and a 747 isn't a turbo prop. Agreed?
heh. Silly rabbit, don't you know HURD is for... (Score:2)
But seriously, HURD is Richard Stallman's baby. If this guy is upset with the Linux kernal people, I would that RMS would not be an improvement...
Now, maybe an OS like BSD.. that seems to be the most "political neutral" operating system... not to mention that the licensing is the least restrictive.
Re:What's wrong with both the HURD and Linux. (Score:1)
If I'm right, that'd be the most appealing reason to use a micro-kernel in my opinion. If I'm wrong, please let me know.
Because H[UI]RD ain't cool (Score:2)
HIRD OTOH is unknown. It could be demonstrably better in every respect, but People Aren't Talking About It so it gets ignored.
Even techies suffer from this a bit. They don't know who else is using HURD, so they don't trust it. Added to this is the proprietry software mentality. Of course 99% of Linux Software can be recompiled for HIRD, but people remember the switch from Windows to Linux. All their software had to be replaced with equivilents. Of course they don't have to with this switch, but their subconcious is telling them that they do.
Re:But also..... (Score:1)
Like a cool name (which is why I originaly used it over BSD, thank God for luck granted that day.)
I think you nailed it, there are alot of reasons Linux flurished it did, neither BSD or ESPECIALY hurd have all the required ones to even make a dent in Linux's force.
-Nathan
why not HURD??? (Score:1)
Because no one buys an operating system named HURD. That's the short answer.
The longer answer is that they want linux because right now linux has a name which is infinitely marketable. Even my father has heard of linux. A better question is why don't they run AIX/IRIX/whatever on their big iron instead of linux (if linux won't develop in the way they want)? Which is what they are already doing. Why would someone suggest taking HURD and developing it? That's repeating a lot of hard work already done with linux on an operating system that no one outside of the slashdot community has heard of, tied to even more radical open source ideas than linux.
Run BSD instead. (Score:4)
Also, I would guess that the boys at IBM know about the '#ifdef IBM' statement.
Umm... (Score:1)
Although early Objective C runtimes had some inefficiencies, this has now been corrected and a method is almost as fast as a regular C function call. Even so, the reason NeXTSTEP was slow probably had more to do with Mach messaging and DPS than Objective C.
What HURD? (Score:1)
The HURD is really pushing the envelope for "piece of software least likely to ever do anything". It's been in development now for donkey's years and yet it is still only in a state where the only people that can actually set it up and program it are the half a dozen people who actually code for it.
Sorry, but the HURD is nothing more than another piece of Stallmann ego-stroking designed to get back at Linux for not being called GNU/Linux (or "Lignux" or other abominations Stalmann wanted). Just because it isn't ideologically sound enough he's pushing the idea of a new kernel, something which we really don't need.
Bah, who cares about the HURD? Nobody is the answer from what I've seen. Yet again, Stallmann has let his ego take precedence over rationality. What a suprise.
Re:HURD has almost nothing (Score:1)
Yes, and yes. As always, it depends on what you want to do. Can we play DVDs under linux? No (well, I can, but I've got a Creative Dxr2 board which has a driver), but can we read data? Damn straight.
Hardware raid? Lots of those are completely independent of the OS anyway. Raidtech, Falcon, etc.
I won't address the others right now, I'll leave it to other fortunate readers.
IBM doesn not care which direction goes. (Score:2)
Excerpts:
ON THE DIRECTION OF LINUX
Wladawsky-Berger:
Now the thing that I don't know is the priority that the Linux community puts in making Linux enterprise-ready. There is so much going on with linux in high volume applications: Linux in embedded client applications, Linux in desktop, Linux in appliances. This area is so full of possibilities that the community could say, "Irving, this is very nice, but this is our hightest priority right now. So, given that you have AIX already, this Linux compatibility in AIX is perfect, because then you have a totally complementary Linux strategy." Linux on Linux, and then Linux applications on AIX."
ON FORKING THE KERNEL
LM: There seems to be a sense that some of these enterprise features may detract from Linux on the low end.
Wladawsky-Berger: I know, and I know that Linus [Torvalds] and the team are resisting forking the kernel. That's always one possibility: to have multiple kernels, and I know so far nobody wants to do that. And if that is the wish of the community, we are cool with that because that's where AIX is complementary to Linux.
Answers from a linux for s390 developer. (Score:4)
Why hurd? (Score:1)
compatible OS with support for their hardware,
why not just add support for Linux binaries to
their existing OSes? The problem of course is
that Linux is what is being demanded, right or
wrongly.
Re:Not a Misconception (Score:2)
Linus did clearly refused the SGI patch to fix this situation.
Yes, he refused (as I said) top apply the patch to the 2.4.x kernel. Changing the size of key id numbers this late in the game is too much. There is after all a code/feature freeze on right now. That says nothing about what will be allowed into the 2.5 tree when it is opened. IIRC, he didn't say no, never, just not in 2.4.
Re: BSD (Score:1)
Check out http://www.rsbac.org/ for what Linux *already* has for B1 level security.
It seems to me that Linux has so much going for it now that it will be hard for other projects to catchup. They may be able to match or beat certain areas, but Linux as a whole will continue to be even more compelling.
Objective-C myths (Score:1)
Objective-C has a few problems inherited from pre-ANSI C, but those would be fixable. I think it would be a good language to write kernel components in. IMO, it would certainly beat the mess of dispatch tables and dynamic loading hacks currently found in the various operating system kernels based on C.
Hurd is based on the Mach microkernel, BSD license (Score:1)
You're missing the point (Score:2)
But the Hurd just doesn't have nearly the critical mass Linux does, and likely never will. It's still enshrowded, to some extent, in the early days of Hurd's totally closed development model, for one thing.
Like it or not, Linux is the premier free kernel, particularly in terms of mindshare, and mindshare means a LOT to a company like IBM.
A linux emulation layer sounds great, but it's a little risky; you never know when something will be added to the real linux, that would be a total PITA to emulate with your sorta-kinda-almost-similar kernel. If I were running a big business, I'd seriously frown on that kind of unnecessary risk.
I say if Linus doesn't want big iron patches in the mainline kernel, that's a shame, and oh well, let's fork it.
I'm guessing it really hurts a company like IBM to commit to linux like it has, and then be told, "sorry, you're s second class citizen in the linux world". I'd think twice being saying that to IBM, if we want to continue getting big-company support.
And yes, big-company support is very valuable for linux.
Re:Run BSD instead. (Score:1)
- Video card.
- Monitor (Got the shakes after about 30 minutes of being on)
- Hard drive (bad firmware)
- Mouse (Netrek damaged the left button
:))
- CD-ROM twice (Power died and loud operation)
- Motherboard and memory (DOD - fried)
- Memory again (thank you ECC)
Here is a link concerning PCI cards showing up twice: i386/10935 [freebsd.org]. Is this the problem you are referring to?Re:HURD has almost nothing (Score:1)
The reason they started useing linux rather than IRIX was that application vendors wanted them to fund ports of there software from other unixes to IRIX, and convincing some vendors to port to IRIX at all was imposible. Linux solves this problem because every company on the planet seems to be coming out with a linux port of their software.
You can't seriosly argue that linux is better than IRIX or AIX on big computers. Linux was made with single processor systems in mind, and when a design desision in the kernel will slow down every computer with less than a hundred processors but speed up an Origin 2000, guess what's gona happen? But it makes sence for SGI to give it's customers the option of running an OS that will run lots of unix software. If they don't, and the app they want is only certified on Solaris and linux.......
Re:Run BSD instead (Score:1)
SMP support has been in FreeBSD (RELEASE) for about two years now. This is according to the release notes for 3.0.
Are you thinking about the advanced SMP code that is coming from BSDi?
you said it... (Score:2)
Fact is Linux is already stable. It is usable, there are device drivers for it is is already quite mature for an OS that is almost 10 years old. Hey Mac and windows are both older than Linux (including win 3.1). Maybe in a few years hurd will be a contender. It has take these developers to port to the MF and get bigger hardware support less time then it would take to get hurd in stable shape.
I don't want a lot, I just want it all!
Flame away, I have a hose!
Re:Popularity rules? (Score:1)
In a democracy perhaps - but democracy sucks.
But by that token windows is better. Why not run NT on the BigIron machines then? I'd personally sooner see that than linux.
Re:And HURD is? (Score:1)
Re:Linux Torvalds has been working on Crusoe linux (Score:4)
The whole _POINT_ of Crusoe is that you _DON'T_ run native code. EVER. That ruins the whole beauty of the architecture. That would be like taking the eiffel tower and removing two of the legs...
The whole point of the code morphing stuff is that they can change the native instruction set when ever they want w/o having to worry about it affecting in production proggy's/OS's. Thus they can move to the latest, greatest ideas in microchip design w/o losing customers. This is clearly stated on their website and in numerous articles about transmeta.
Linus isn't working on this because the idea goes counter to everything Transmeta is working on.
According to one article I read... maybe it was on linuxtoday.com.... I disremember. These patches are not being accepted simply because the memory management patches to support these large machines doesn't scale back down to desktops, laptops or handhelds. In other words, making the ness. changes in the kernel to roll this stuff in would affect performance on your server, desktop, or PDA. Considering that 99%+ of Linux users are running on these platforms it doesn't make sense to apply these patches.
---
RobK
But also..... (Score:2)
Re:HURD has almost nothing (Score:1)
Yeah, but for some Hardware RAID you need drivers. The Highpoint 370 IDE controller on the Abit KT7-RAID specifically.
http://www.linux-ide.org/ [linux-ide.org] has the drivers for the Highpoint controller, and many other supplimentary IDE drivers.
--
Re:Linux Torvalds is intentionally boycotting it! (Score:1)
I swear to God their after me. Linus is trying to destroy his life's work for his own financial gain
by rewriting all of linux in Crusoe assembler....
Their goes the neighborhood....
Just because your paranoid doesn't mean I'm not out to get you!!!!
:)
HURD is older than Linux. (Score:1)
http://www.kde.org/food/linux_is_ obs olete.html [kde.org]
It gives a good outline of the status of Open Source and small *nix comunity in the early 90s. It also shows Linus didn't become a bastard overnight :)
Re:Can one Linux fit all? (Score:1)
You're right, of course it can't, it already doesn't. Take a look in the linux/arch directory of ther kernel source tree and you'll see the different linux kernels for all the different architectures. If I understand it correctly each different architecture has it's own core kernel (though most are probably strikingly familiar to the i386 one which they were all ported from). Each 'core' kernel provides the same interfaces as the other ones so the rest of linux can be shared among them, but at the very basic level they are all different kernels. I don't foresee it being a problem if we have an entire 'big iron' tree with a specialized kernel core and special modules which meet the requirements of 'big iron'.
The linux kernel can be the best solution on any hardware, you just have to pick the right one.
Re:Popularity rules? (Score:1)
Note that to some limited extent this has been tried and failed, namely NT for Alpha, PPC and ..er.. one other I can't recall. The problem is that the OS is in the hands of one group with one set of goals, which may not match the goals of the platform implementors, and these implementors cannot have the freedom they get from an Open OS to make whatever changes are necessary (by definition: to implement a non-Open software package on another platform you can bet there are licence agreements to be signed complete with a whole bunch of restrictions and lists of what can/can't be done. Likely including the requirement to pass back any innovations made to the original owner who now gets R&D done free by a 3rd party...)
Essentially the implementors will always be scrabbling behind the OS's owners, trying to keep up, instead of being part of the development process.
Also note that the definition of "popular" you're using may not match that of those who make these decisions. Certainly there is more public discussion of the benefits/shortcomings of the Linux environment at the moment since A) NT's been done to death over the last n years B) since we can all get at the code we've got more to talk about.
what features? (Score:1)
Re:Code Forks/What have the Romans ever done for u (Score:1)
Well, there is actually no such thing as L4KaLinux. There is L4Ka [l4ka.org] though, which is another implementation of the L4 -kernel, and which is able to host the L4Linux kernel (leaves you with one less code fork ;-).
Re:Code Forks/What have the Romans ever done for u (Score:1)
Re:Linux Torvalds has been working on Crusoe linux (Score:1)
> that are going to end up being a _lot_ of work
> to satisfy less the 1% of his "customers."
I agree completely.
I didn't mean it in the context of "Couldn't linus make it such that..." I meant more of the "I doubt he would reject it if the patch was submitted as an optional replacement"
It wouldn't have to be alot of work for him and others - just for the people wirtting maimframe code. Let them maintain the code that they submit.
Even if its completely broken - its their own problem. I don't mind the kernel source getting a tiny bit bigger for their conveienece.
certainly it already contains many many device drivers that I will never use - and thats true for most people. The only downside to including it - IF it is submitted as a proper OPTION so it wont degrade performance on "miniscule iron", then its only downside is making the code larger - adding a feature that most people will never use.
Really - only a few core kernel options can be said to be used by "most people". Take the NE2000 ethernet driver. I use it on a few machines. "Most people" don't. The same is true for every other ethernet card driver. There is no one single ethernet card that "most people use" (there may be one that is used more frequently than the rest - but I doubt its enough that more than 50% of linux users have it)
My point simply being - I would bet, from the discussion about how it would "effect small systems" that the patch was rejected because it replaced the original code - rather than simply being an optional drop-in. - a problem which the original authors should fix and resubmit rather than complaining.
> Also, it could just be that the thought it
> was too late in the 2.4 development cycle
While very true, its not something that most kernel hackers could test/work on anyway. Since it only effects the small subset of people who are on big iron - well it doesn't matter does it...
that would be a perfectly valid reason for rejection. However - the reason being talked about is the effect on smaller machines - which is a completely different issue and can be made insignifigant as I said above.
-Steve
Re:Does anybody know what the HURD IS? (Score:1)
>
> Microkernel is technically more "correct". Macrokernel WORKS.
Great. You read the original Andrew/Linus flame. Now, you may want to use your brain a bit.
First, with this kind of mentality, you should still run DOS. When linux started, DOS was the No1 of the Operating systems (Win was DOS-based), and actually worked. There was games, productivity applications, dev environments, etc, etc. Or you should still run MacOS. Anyone could have said (and many did, at this time)
preemptive-multitasking == mental masturabation
preemptive-multitasking is more correct, cooperative multitasking WORKS.
You may think that it is not comparable, but it unfortunately is.
A micro kernel enables you to run multiple OS at the same time. It enable user-space drivers. It enable personal OSes for each user at the same time. It enable hack and modifications beyond what is possible with Int21 (Ooops, I meant modules), without crashing the OS. It enable a much better network transparency too.
Maybe it'll work one day. May it won't. But having something that WORKS NOW, don't mean that it'll work forever.
Cheers,
--fred
Re:What about Plan9? (Score:2)
Re:What's wrong with both the HURD and Linux. (Score:1)
This is false as far as I've seen. I've been able to select additional modules, make dep, then make modules && make modules_install && depmod -a for some time now (all thru 2.4 at least, and probably for 2.2, though it's been awhile since I've built a 2.2 kernel).. There may be some static dependencies for classes of functionality which then allow for particular drivers/functions to be modularized, which would require a kernel rebuild and reboot, but I haven't come across them.
Your Working Boy,
Re:Two words: (Score:1)
Duplicate efforts are fine in Open Source because it means someone thinks something needs to be changed. Linux itself is a duplicate effort of other Unixs. Sorry by the Anonymous Coward above clearly has no idea what he/she is talking about.
Re:What HURD? (Score:4)
As it happens, I got Debian GNU/Hurd up and running just yesterday. It took about two hours, counting the time it took to install Debian GNU/Linux and the time it took to download the installation .DEB files over a 115K ISDN line.
Of course, I can't actually do anything with it because the kernel is only about 1/3 done and there are essentially no applications available for it. Perhaps if the FSF decided to put their efforts into the Hurd instead of yet another major version of GCC, GNU EMACS, and the GNU LIBC, they would be able to actually finish it to the point where Linux was at kernel V0.10, the version I first used. Some additional stability would be nice, too.
I think I'll reformat the disk and see if I can't get OpenBSD on it.
AC also wrote:
Ummm, that's not factually accurate. I don't know if the code for the Hurd (the name for the collection of services running under Mach) antedates the arrival of the Linux kernel or not, but the project as a whole has been going on since the early 80's and the overall design of the system has been frozen for at least that long. In other words, the Hurd was not created in response to the success of Linux. It couldn't possibly have been.
However, I do share your doubts as to whether or not they're ever going to finish. They definitely bit off more than they could chew with the Hurd.
Re: BSD (Score:2)
Take FreeBSD as an example. They have joined forces with BSDi and got fine grained SMP to their project. The SMP is developing in a fast pace and I think we can expect FreeBSD to become superior to Linux on computers with many CPU's during next year.
Trusted BSD is also a FreeBSD project that aims to be portable to the other xxxBSD distributions. As you perhaps know, Trusted BSD is aiming at 'B1' security (except for the validation part).
All in all, during next year FreeBSD will be a very interesting OS for computers with lot's of CPU's and where security matters.
There is really no reason to avoid using FreeBSD and it cousins for 'big iron' computers.
//Pingo
Why IBM doesn't fork the Kernel, or move to HURD (Score:3)
1) Public Opinion / Community perspective
Linux is built on popularity. It gets marketing's attention because it's a popular choice among Admins. Therefore, IBM has to jump on the bandwagon and support the thing in its many incarnations. IF IBM FORKED the Kernel, it would be a marketing nightmare as Slashdot and others would do a 180 from "IBM is doing Linux solely for PR" (untrue) to "IBM wants to take our baby and twist it for its own evil purposes!" (also untrue.)
Don't believe Slashdot would be this unkind? Just look in the archives for RedHat 7.0 and see how supportive the community was at that time.
2) IBM has a huge investment in Linux.
IBM has a Linux Dev Center newly established in India. IBM has a Linux Compatibility Org to test and ensure that every IBM application for Linux will work with the 8 standard NLS Languages and doesn't break with standard libraries, and will function on most all recent distibutions.
IBM has invested huge amounts of resources in the IBM Journaled File System for Linux. IBM took part in developing Linux for the S/390. It also runs on the AS/400, and there's work on the RS/6000 distribution as well.
The investment is too great to move to HURD.
The HURD community and installed user-base is tiny. Linux has name recognition.
Currently, most new IBM Web Application Server / WebSphere type products support NT/2000/AIX/Solaris/Linux.
Moving to BSD would be smarter, but BSD hasn't got name recognition, even if it is more widely installed as a serverOS.
Moving to HURD would be suicidal.
Yes, there's AIX for Big Iron, but AIX is a commercial server OS and doesn't get the community's collective hearts pumping.
There's mindshare, which is what we logically know. AIX exists for big iron, why do we need a linux for it?
and then there's *HEARTSHARE* which is the emotional based decision. We know in our hearts nothing makes us growl with manly pride at having Linux, the Free-Little-Operating-System-That-Could-TM, running on the biggest Iron made.
Heartshare will keep IBM focused on Linux as long as there's a community of people running Linux.
AFAIK, Debian is the only big-name that's bothered to propose a HURD distro. http://www.debian.org/ports/hurd/
I'll believe it when I can install it.
(Tho, it uses Mach and linux hung around it... if it was Mach and BSD, it'd be a relative of Darwin-x86! hmmmm....)
In Summary
IBM has 20 top-level links to Linux related dev sites on its Intranet. These snowball into deeper levels. IBM has a huge investment in Linux, and in having it run on their boxen, big iron or not.
And you want them to drop it all and move to HURD?
A host is a host from coast to coast, but no one uses a host that's close
How are people defining "big iron"? (Score:2)
Please tell me that it means SMP (something like 64 procs as I have 2 in my desktop). Please tell me that it means fiber channel (or whatever it's called) RAIDs. Please tell me it means GBs of memory. Please tell me it means multiple 1000BaseT connections. That's what I would imagine is meant by Big Iron.
Re:What's wrong with both the HURD and Linux. (Score:4)
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a lot of baggage from those days even though it's come a long way and been ported to many architectures.
That's simply not true. Take a look at the latest kernel. It can support up to 64 Gigabytes of memory, and it can scale quite well up to 4 and 8 way SMP boxes. People have booted Linux on 32-way ccNUMA machines. Yes, it's not optimized for ccNUMA yet, and it probably doesn't scale all that well for > 8 way SMP yet, at least for many workloads, but it's currently quite a very long way from "small i386 machines". A "small i386 machine" is orders of magnitude than the original i386 back in 1991, and a "small i386 machine" today is comporable with the vast quantity of Unix machines which are used as servers today.A lot of the "we scale to 64 nodes" is I think more machismo more than anything else. Sure, for system vendors they have better margins than the smaller machines. But you don't sell that many of them. One of the reasons why Cray was getting killed was that they only focused on the high-end, and they got their lunch eaten by the "low-end" machines moving upwards and killing off all of their market, so that they only had one or two customers. (Or should I say "One Agency". :-)
So personally, yes, people are interested in making Linux scale to the bigger machines, but some of this I susect is either (a) because of the technical challenge (for the Linux Kernel developers) or (b) as a marketing exercise (for the non-technical folks who are interested.)
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other architectures too.
That's simply not true. There is an awful lot of that "complexity" which is optimized out by the compiler. So you should take a look at the assembly language before you make these sorts of complaints. Secondly, on the UltraSparc particularly, all of the virtual memory translations have to be done in software, since the hardware basically only provides a TLB which is manually programmed by the OS. This may be the source of some of the complexity which you saw, and which is required by all operating systems for that platform. This is actually a good thing, though, since the OS can do a much better job of managing the TLB than a typical hardware platform, and there are hooks in Linux that are especially designed for the capabilities of the UltraSparc VM architecture. So to say that Linux is only optimized for the x86 architecture is very much overstating the case.
Just what the world needs is . . . (Score:2)
3 replies beneath my current contempt
A fundamental design example (Score:4)
For example, Linus is a big proponent of a non-preemptable kernel. A preemptable kernel is one that can allow tasks within the kernel to be preempted by other tasks. The Linux kernel does not allow tasks to be preempted by anything other than interrupts.
As an aside, interrupts in the Linux kernel typically run a small bit of code to set up some state information about the interrupt, flag a "bottom half" to run later, and then get the hell out of dodge. The bulk of the work is in the "bottom half," which is a bit of code which is enqueued to run when the kernel gets the time to get around to it. For example, the timer interrupt increments the jiffies (an internal measure of sub-second time), lost timer ticks (ticks that haven't been handled by the bottom half), and flags the bottom half for later execution. The bottom half will later update time-related statistics and service kernel timers.
Basically, though, once the "top half" of an interrupt is handled, the kernel must immediately go back to what it was doing. It is guaranteed that kernel code will not be preempted. This makes the kernel cleaner, easier to understand and maintain, and faster on uniprocessor systems or systems with few processors. However, there's a reason that the Solaris kernel is preemptable. Preemptability is a serious performance enhancer for massively parallel systems, but Linus is not budging on this. There are a number of alternative solutions that the Linux kernel is following, such as its system of "bottom halves," some of which can now be run on other processors in the 2.4 kernel (if I understand correctly). Essentially, a preemptable kernel requires that fine-grained kernel locks be scattered all over the kernel, and that more code in the kernel be considered "critical sections." This is somewhat of a hassle.
Solaris scales extremely well partially due to its kernel's preemptability and heavy use of threads. Solaris's kernel can be preempted by another task and can dispatch kernel threads to work on other processors. This keeps system call hungry processes on other processors happy and well fed. However, it does incur some overhead which isn't justifiable on desktop machines. I'm reminded of a funny quote from the 2.2 kernel mailing list I found once while looking for info on this once: "MVS spends a lot of time running OS algorithms to allow full preemption that Linux wastes on running user applications."
Basically, this is just one of a variety of wide-sweeping changes to the kernel that go many levels beyond a simple patch that "Big Iron" vendors are pushing for. Linus is against it happening in the first place. While Linus and Co. are coming up with a lot of innovative alternative solutions to the problems, "Big Iron" wants to go with proven solutions that they know will work for their systems. In addition, the changes would impact performance on desktop uniprocessor and SMP machines. In essence, these are political issues.
RTLinux has already forked the code to handle this. Basically, RTLinux runs a hard-RT capable microkernel that runs the Linux kernel as its idle process. Basically, when a RT process needs something at exactly a certain time, it will get it and all normal processes will be run under Linux when the system isn't busy doing more important things. There's also the uLinux fork to attempt to make something Linux-like on systems without hardware memory-management units, like the 286. Code forks already exist, often for good reasons.
There's a great article kernel design and impact on real-time systems here:
TradeSpeak.com - White Paper Library: Linux for Real-Time Systems: Strategies [tradespeak.com]
Why not Darwin? (Score:2)
The design of the Mach kernel also should make it easier for companies to put in their favorite pet "enterprise" features (LVM, JFS, whatever) without messing up the system for everybody else.
Microkernels (Score:2)
Code Forks/What have the Romans ever done for us? (Score:5)
"What about the Alan Cox series?"
Ok. Apart from the Alan Cox series, Linux has never had a Code Fork in all of it's long existance.
"There are the L4Linux, L4KALinux and MkLinux microkernels."
Ok, ok! Apart from the L4Linux, L4KALinux and MkLinux microkernels, and the Alan Cox series, Linux has never had a code fork in all if it's long existance.
"There are patches from SGI (XFS, kernel profiling), IBM (JFS), and various other developers (timing patches, nanosecond clock patches, reiserfs, ext3fs, gfs, the international patches, freeswan, etc)"
OK!! So, apart from the patches, the microkernels, the Alan Cox series, Linux has never had a code fork in all of it's long existance.
"What about the UserLand Kernel?"
SHUT UP!
(Apologies to the Monty Python crew for this horrible bastardization of their excellent Roman sketch in Life of Brian)
Grab a clue - linux adoption is all about PR (Score:2)
That being the case, why would they adopt a non-linux OS?? This wouldn't make any sense at all. If not for the PR value of adopting linux, they could simply stick with what they already have.
Re:Run BSD instead. (Score:2)
That's news to me, having run FreeBSD with an NE2000 for years . . .
Re:heh. Silly rabbit, don't you know HURD is for.. (Score:2)
They want Linux bandwagon though... (Score:2)
These guys already have their own Unix OSs with the high-end features that they want to see in Linux, and they aren't going to be dropping their current commercial Unix OSs quickly - that'd annoy a *lot* of their customers, many of which would then go straight to Sun, which is the last thing they want.
Though there will be many different reasons and objectives etc, I think the higher ups will want the mindshare particularly...
Re:This story is lame? (Score:2)
Re:heh. Silly rabbit, don't you know HURD is for.. (Score:2)
RMS (and the FSF) do not forbid making a profit. They encourage it. Check out this philosophy page [gnu.org] for more information.
Two other issues here: "pirate" is really the wrong word to use in almost every instance. Try "unauthorized sharing". And having source but only being allowed to write a patch for it severely stunts software development. That's why Minix didn't fly, but Linux (as a kernel) did.
One of the few things here that was almost correct: nobody has a right to make a profit by restricting others. In any way.
There's "funny 'cause it's true" but this post is only funny if you believe a (rather common) misconception.
What's wrong with both the HURD and Linux. (Score:3)
The HURD is based upon the MicroKernel technology which was in vogue in the Computer Science community about 10 years ago. Time has moved on, people have taken the ideas from this technology and incorporated the best bits into the semi-monolithic kernels of today, Microkernels are looked upon as a relic.
MicroKernels are theoretically so much cleaner and efficient. They are built on the idea that every part of the system has its own thread of execution and that the "kernel" contains nothing more than a facility to pass messages between the threads. In some extremes of the idea even the scheduler is just another thread. This design means that everything is compartmentalised, clean, organised.
The problem with this approach is that in the real worl this deisng has a massive performance hit. Every thread context switch, every message passed needs CPU and/or memory overhead. If a processor was designed with internal massively parallel instruction streams and internal message passing this wouldn't be a problem.. with current processors it is.
What's wrong with Linux
Linux grew from humble beginnings, small i386 machines with little memory and scant resources. unfortunately, it's kept a lot of baggage from those days even though it's come a long way and been ported to many architectures.
There are many things in the kernel which do things the x86 way and force the other architectures to munge the way the native system does things so that they look like the x86 way. When I last looked at the SPARC port, the memory management system had to jump through hoops to change the way the SPARC processors do VM so that it looked to the rest of the kernel like the way the x86 architecture does it.. it was very inefficient. No doubt these problems haunt the other architectures too.
There is also the problem of the "one size fits all" mentality.. it doesn't work!
Sure, you can have a family of kernels, each aimed at a different niche with what common code they can share shared, but don't try to force the same kernel onto everything otherwise everyone will loose out.
Before anyone tries to label me as a supporter of some other system saying that I'm only bashing their favourite because I have an axe to grind, I don't see any of the free or commercial operating systems today being able to be all things to all men.. and I don't see any being so in the future either.
Re:HURD has almost nothing (Score:2)
IBM seems to think so, according to recent articles [linux-mag.com] ("We think that Linux could do for applications what the Internet did for networking. That is, become the standard of choice for developing applications."). Why do you think all the Unix vendors are working on Linux binary compatibility? Sometimes a standard is just where everyone is, and everyone's going to Linux.
existing high-quality implementation (have you ever looked at linux code? And it changes every two minutes)
So some of it's not pretty, but in the end it works damn well for a lot of purposes. Remember, this is an industry that puts up with Windows NT.
existing widespread hardware support (DVD? Hardware RAID even? ....)
Hardware RAID is coming along ok. DVD is a special case. The important points are that Linux supports more hardware than anything but Windows now, and that support for new stuff will almost certainly get better.
non-techies are comfortable with it (please ...)
If you thought I meant comfortable using it, I was unclear. I meant comfortable about it being used in their organizations.
Liberal licencing (GPL!!!)
Look, BSD isn't in the picture here. If BSD advocates know what's good for them, they'll ride Linux's coattails. The alternatives to Linux in this context are Windows, Monterey, and other proprietary stuff.
Re:heh. Silly rabbit, don't you know HURD is for.. (Score:3)
Misconception (Score:2)
There seems to be a widespread mis-conception. Linus has NOT to my knowledge refused to consider appropriate additions/changes to the kernel to better support big iron. He DID refuse to make any radical changes late in the 2.4.x development cycle so that it can hopefully be released this year. He also refused approaches that make half the code conditional based on defines (which would be very messy).
The challenge is to find an elegant way to support big iron without sacrificing usability on small machines. Perhaps it can be managed by making the scheduler and VM more modular. That could also make the real time audio ('soft' real time) people happy.
The HURD has an interesting archetecture, and could be very interesting on clustered machines. Cray loads Unicos/mk (micro kernel) on T3E and probably other MPP machines already. Possably, HURD could solve the crash on heavy I/O problem.
Re:How are people defining "big iron"? (Score:2)
Big iron is six 9 uptime. Big iron is fault tolerance and redundancy. Big iron is support. It has nothing to do with how much RAM or how big the disk is, those are secondary concerns.
Really what mainframes provide is stability to the business, in areas where "tee hee, we need a reboot" isn't an option.
Calum
Re:heh. Silly rabbit, don't you know HURD is for.. (Score:5)
Vendor: "Hey Ricky darling! We're writing a killer App which will make everyone want to use Hurd.
RMS: "Are you going to let everyone copy it for free?"
Vendor: "No, but we're making the file format public domain. We're also explaining how the algorithm works in detail so that the GNU can make a free version if they want. We're supplying the source to anyone who wants to write a patch for it, or reverse engineer it. We just aren't allowing people to pirate copies of it."
RMS: "You're all evil scum. You have no right to make a profit from your work by restricting others from making a profit"
Vendor: "But they can make a profit. They just have to write their own version"
RMS: "You should give it away for free"
Vendor: "But we spent time and money developing this. We deserve a profit"
RMS: "You don't deserve anything"
Vendor: "Oh, sod this. We've changed our mind. We're going to make it secret closed source, with a restrictive license. Anyone who tries to compete we'll sue into oblivion"
Can one Linux fit all? (Score:3)
I guess you can please some of the people all of the time and all of the people some of the time, but no more - and frankly this makes sense.
Big Iron is bound to have requirements that differ greatly from handheld computing. I'm pretty sure that this will continue. My fear is that code forks will reduce the impact that the Linux community is having in attracting applications developers. You want to make it as easy as possible for people to write once and run anywhere.
And, fundamentally, isn't that really the point? After all the end user won't know/care whether there's a special patch on the kernel powering their system, as long as it's possible(hopefully easy) to run the apps they like. That's when you get real flexibility and power out of having a common denominator.
I think the stakeholders in this discussion (Linus, IBM etc) should be encouraged not to take their eyes off this goal.
Well (Score:2)
> But why don't they (IBM, SGI, et al) grab HURD and add to it all the things they find important for 'big iron' support?
Because they've already written their own operating systems for these systems! These aren't companies looking for an OS for their system because they don't have one, they're looking, I assume, for a unix[-like] OS for the large number of programs already written. A free OS like Linux is perfect because they aren't paying per license and have access to all of the source code.
What I don't understand is why IBM doesn't just take the Linux source code and adapt it to their computers. SGI already has their own Linux tree. Just because it isn't in the Linus' tree doesn't mean it's not worth doing. How many people actually have these huge computers to use the changes IBM would make, anyway? That's one of the nice things about open source, Linus can take the patches he likes from IBM's tree and apply it to his own.
There are already lots of kernel forks out there, however, everyone who HAS forked the kernel(SGI, embedded people, realtime people) are all following the GPL and make their changes available. Get used to it already, forks are here and now.
Forget technology (Score:4)
The closest big-iron manufacturer's management gets to appropriate technical decision-making is in counting headlines.
All these say "Linux good". *BSD is *possibly* just about on the bottom of their radar-screens, but probably not. You can guarantee that no-one in that chain has even heard of the HURD.
Sadly, this applies to the techies too, although to a lesser extent. Never underestimate the herding mentality, especially within corporate organisational structures.
The other side of this is that the technical decision makers - the architects if you will - have generally come up through the techie trenches but have left all that behind. They won't necessarily be current with the minutia of OS design or implementation, but will have a strong background and understand the basic facts.
Key to this thinking is that industrial-strength OSes require years of development. Linux has had years of development (though not as many as big-iron OSes, by a factor of 3 or more), and has only recently passed this magic threshold where it can be treated seriously because it's been under live-use development for X years.
These are all points in Linux's favour. HURD on the other hand, regardless of any architectural or technical merit, hasn't been discussed, hasn't been *in use* for X years, has a quiet/non-advocating user community (RMS notwithstanding), and is a break with everything these guys know about. HURD is therefore out of the running
Now, if this whole question had done s/HURD/*BSD/ (for some value of net|free|open), then it would be more appropriate. I still think the answer would be the same (rightly or wrongly, Linux is more popular and therefore better).
Never underestimate the impact of inertia...
because it's only available as unstable on i386 ye (Score:5)
Added to this, it's a microkernel system. Big Iron doesn't need microkernels. They're a little bit slower by nature, but you get the advance of a small, configurable "mostly user-space" kernel. That's pretty cool for palmtops and everyday PC's but not Big Iron, I'd say. That's why QNX doesn't run on mainframes.
If Linux can't do the "big iron" thing, I think BSD would be a more serious alternative for now. NetBSD runs on almost every platform, so its kernel should be portable. And I hear rumours that BSD can do some things that Linux can't as of yet. (And vice versa, of course; that's not the issue. The issue is, maybe BSD will just be able to do the trick.)
GNU's Not Unix: this sentence is more important than you may think.
The HURD microkernel can be set up to listen to POSIX if you wish, but it can also listen to other stories. So here's a possibility to move away from ugly ol' POSIX in a decent manner, without having to completely abandon the ship like e.g. BeOS does, providing only POSIX as a portability layer.
The HURD microkernel allows you to mount filesystems in a "new, radical" way which takes away the requirement of seperate "/usr" dirs, etc. (The mounted fs will be mapped on top of the current one, IIRC.) The HURD microkernel allows for user space device drivers and kernel modules, which I think can in the end make the "UNIX experience" a lot less harder.
So I think that when it's finished, the HURD will be there for the common people and will supply more ease of use and programming freedom than Linux or BSD do now, because it's very flexible and can be set up very friendly towards the user (in my imagination, anyway). It will slowly move to liberate us from the less nice UNIX inheritance, as well.
But I simply do not think that Big Iron is a target of the HURD.
But I'm not very afraid about Linux loosing Big Iron. All we need is an open source kernel (isn't Caldera opening UnixWare?) for it. I don't care if it's a fork, has a different name or implementation. That's what standards are good for. All the tools and gears are here already, so it would be "easy" for e.g. Debian to make a Big Iron port, just as they did a Hurd and FreeBSD port once.
It's... It's...
HURD has almost nothing (Score:5)
Now which of these does HURD offer?
Re:What's wrong with both the HURD and Linux. (Score:2)
Au contraire. Pretty much every new OS of the past ten years uses a microkernel. Look at BeOS, QNX, JavaOS (built on top of Chorus), Windows NT when it was still relatively stable (i.e. pre-version 4.0), Windows CE and Palm OS.
You're thinking of the microkernels of ten years ago which weren't very "micro" (e.g. Windows NT and Mach).
It's not nearly as massive as you might think, and you can win it back in other ways.
There are a lot of things in a modern OS which count as a "massive performance hit". Device drivers, for example, are there to abstract away hardware details. It would be faster if we didn't use device drivers at all and just talked to the raw hardware, because we'd eliminate a layer of glue code. But we think this is worth the price because the layers above it can be coded more simply and thus with fewer bugs. You lose in one place and win it back in another place.
Virtual memory incurs a massive performance hit, too. But you win it back because user programs are freed from the responsibility of managing what is in core and what isn't. Simpler algorithms, more efficient algorithms, fewer bugs. You win the performance hit back.
Incidentally, the same argument comes up occasionally about garbage collection, but that's another thread.
Absolutely. That's why modern microkernels work. You can mix and match different bits to make the OS that you want.
Re:Does anybody know what the HURD IS? (Score:2)
LaBola wrote:
perlmonky wrote:
If you calm down a bit, you'll see that these statements are entirely compatible. Linux technology is the present. I don't think anyone here seriously doubts that. I also don't think that anyone seriously doubts that the open source movement should be producing good quality software for the present, like Linux. But it's ridiculous to think that Linux in its present form will serve the industry forever, any more than the great OSes of the past did (e.g. VMS, which is finally being phased out as we speak).
We (and I mean both the computer industry and the open source movement) should be looking to the future as well as producing good code for the present. There is a more than twenty year gap between Unix and Linux. If we want to avoid the similar gap in the future, we need to be thinking about the future now, as well as we think about the present. That's why statements like "this technology is the future" need to be said.
Think of Linux as the Empire and Hurd as the Foundation, if that helps. :-)
massive performance hit? (Score:2)
This may be true in theory. But have you ever played with BeOS? It's the most ridiculously responsive, zippiest OS I've EVER worked with! I guess the theoretical performance hit can be worked around, given enough ingenuity.
--
Does anybody know what the HURD IS? (Score:2)
HURD is not another kernel like Linux nor BSD.
HURD is not the reaction of RMS to the Linux kernel.
HURD IS a microkernel based architecture, did you say 64 procs. machines? (I hope you all know what a microkernel is).
HURD IS GPLd, I'm not so idealist to be a BSD geek.
HURD IS older than Linux (ok, it's also harder at this moment, but if this is a problem you can always reinstall Windoze).
Moreover HURD is THE future, I mean that this tecnhology is the future, at some point Linux itself will be microkernelized or die in the "big-iron" scenery.
Re:Can one Linux fit all? (Score:2)
Of course not. Who cares what kernel is running on the system? It's the applications that matter. Applications depend on API's, not on kernel implementations. I don't expect my mobile phone to run the same kernel as a mainframe. If they do run the same kernel, one of them is running less than optimal because these two types of computers have very different, most likely conflicting requirements (think of real time vs. multiprocessing requirements for instance).
The linux community needs to learn to deal with this fact of life. X windows is not the best solution on all platforms. The linux kernel is not the best possible solution on all possible solutions.