Slashdot Mirror
First Program Executed on L4 Port of GNU/HURD
wikinerd writes "The GNU Project was working on a new OS kernel called HURD from 1990, using the GNU Mach microkernel. However, when HURD-Mach was able to run a GUI and a browser, the developers decided to start from scratch and port the project to the high-performance L4 microkernel. As a result development was slowed by years, but now HURD developer Marcus Brinkmann made a historic step and finished the process initialization code, which enabled him to execute the first software on HURD-L4. He says: 'We can now easily explore and develop the system in any way we want. The dinner is prepared!'"
To me HURD is like, well, like a missed opportunity.
Except this one, of course.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
... if GNU/HURD comes out before Longhorn?
Just like a computer with nothing on it, it's a blank slate.
Perhaps a blank slate would be better because it's only a matter of hours to get a working Linux system on one.
Maybe the second program should be a better web server.
/* oops I accidentally made a comment, sorry */
that 1st program wasn't a web server by any chance, was it?
What are the relative benefits of L4 vs the Mach Microkernel? Better performance? As I understand it, MacOS X's microkernel is also based on the Mach microkernel... would it make any sense for Apple to look at L4?
return 0; }
Reminds me of the Dilbert comic strip where an old man waves a piece of paper around and says "At last, I have formed a strategy that is acceptable to all departments. Now if only there were a way to reproduce text from one piece of paper to many."
Mach was still an active CMU project when the Hurd glacier began its very slow creep from the peaks of lofty idealism towards the throng of onlookers waiting patiently for the free unix kernel they always craved to reach them. I understand there are actually a few brave souls still standing there waiting.....
The HURD kernel is often joked about, but I for one does hope that it will eventually become a viable alternative to the Linux kernel. Competition is seldom a bad thing, especially not among free software projects.
.: Max Romantschuk
BTW, Revolution OS is a great movie, even my non-nerd friends loved it. You can pick it up here: http://www.amazon.com/exec/obidos/ASIN/B0000A9GLO/ revolutionos-20/103-9235316-0475036
http://en.wikipedia.org/wiki/L4_microkernel_family
I might as well quote this too, which I think this story most likely refers to (posted on 27 jan~):
This uses a lot of advanced words I have no idea what they could mean though, but I don't mind as long as someone does and writes an article
Still a long way to go. Not much one can do except wait... or send in patches if you have kernel hacking experience!
would it make any sense for Apple to look at L4?
Given the fact that some features in OS X took Apple over 12 years to get into a shipping product (development on Copland started in 89), and given the fact that for years Apple had suffered with a horribly buggy, non standards compliant, limited system that was the Classic Mac OS, and given the fact that Darwin with the Mach kernel is an excellent open source unix system, and given the fact that huge amounts of time and money were spent getting OS 9 and Carbon libraries to run on it, and given the fact that OS X is now arguably the best OS out there and is earning heaps of praise from geeks, luddites, and just about every other type of user, and given the fact that OS X represents the most compelling reason to switch to Apple computers in years, and given the fact that in just a few years the OS has amassed a compartively huge following of developers and applications...
Given all those facts...
Whould it make sense for Apple to now completely rewrite it DOWN TO THE KERNEL LEVEL!!!
I really hope I don't have to answer that.
When I see X, KDE, & Postgres ported to Hurd then I'll believe it.
When the first programs run, it is just a matter of time before there is a functional L4 port of Debian GNU/Hurd (or just Debian GNU?). I really like the design of the Hurd, but what I'd like to see the most are not the "POSIX capabilities" but the real capabilities as described in the 1975 paper by Jerome Saltzer and Michael Schroeder, The Protection of Information in Computer Systems. (For those who don't know what am I talking about, I recommend starting from the excellent essay What is a Capability, Anyway? by Jonathan Shapiro, and then reading the capability theory essays by Norman Hardy. As a sidenone I might add that I find it amusing that people who say that there are other advantages than only Digital Restrictions Management of using TCPA/Palladium-like platforms usually quote security features, which have already been implemented in the 1970s, only better and with no strings attached. Those TCPA zealots are usually completely ignorant of the existance of such operating systems as KeyKOS or EROS with formal proofs of correctness without all of the silliness.) Are there any plans to have a real capability-based security model available in the Hurd?
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
How much time would it take to port it over ?
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
FIRST CODE! :D
(kudos to everybody working on this. think of how long mozilla took to "come out" - and the impact it had!)
I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows)
/. in 2006 doesn't have a new flame topic:
/. lips is, in regard to anything, when will HURD run Linux? ;-)
Courtesy of Gooooooogle
The thing is, GNU/HURD will still be... Linux. Don't shout, yes I know, the thing is, people call Linux, Linux.
Then people say, aaahaaaa Mr Bond... it is really GNU/Linux.
Well I am not so sure anymore. Debian think so, but why not call it GNU/Gimp/OOo/Java/Perl/apache/*all other installed apps*/Linux.
Is GNU software is great, and calling Linux+GNU 'Linux' is wrong, but calling any installation of the Linux kernel 'Linux' is correct regardless of other software.
If I call my OS Linux, I do so without reffering to the installed user space apps, however necessary they might be.
I think the person who is most keen to see HURD is Linus himself! After all, he has been waiting since 1990!
I do hope that
HURD v Linux (and HURD will never sell with that name - IMHO)
HURD running on top of the GNU Mach microkernel first booted in 1994 and became GNU's official kernel
The development of the GNU/Hurd has important emotional and practical value to GNU fans because in 1990s GNU had not completed any kernel and used the Linux kernel out of necessity. Thus, a number of GNU fans feel that they will have "pure GNU" only with the Hurd kernel.
I do think that some of the GNU ramblings are a bit ungrateful to Linux kernel. Without Linux it would be in 5 years that people would wake up to *nix OS's types, and in 5 years we would be where we were in 1994.
I see one thing, with the FUD over linux, will the same FUD establish itself over the huge sprawling software base of GNU?
Will GNUimp get sued by Adobe? How will this GNUism evolve?
And the final question on every
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
I, for one, welcome our new L4 overlords!
Get a free iPod Nano 4GB!
the GNU project want to provide a free OS, for this they build GCC and emacs to write a kernel(Hurd) i think that software, that can be compiled with GNU Gcc compiler would run on this kernel (on the contrary i must laught) so now we can a "Linux Software Gcc"-based O.S. with Gnu/Hurd-L4 kernel.. this sounds good..
GCS/T/O -d+ -p c++++(++) l+++ u++ e+ m+@ s+/+ n+(--) h* f++(+++) !g w(+) t r+(++) y?
How fast is GNU/HURD compared to GNU/Linux? How about non-GNU/Linux?
Microkernel systems are always slightly slower because of the message passing overhead but they can be much more secure and stable because all of the device drivers are run in user space. Contrast it with systems such as Windows and Linux where drivers are in kernel space and it is impossible to have a stable or secure system with poor drivers, and in fact most of the problems with Windows and Linux crashing is caused by buggy drivers running in kernel space. When the drivers are just user processes like in HURD then a faulty driver can't crash the system and if it goes berserk it'll just get terminated just like a buggy browser or text editor without affecting the stability of th entire system.
A commercial company might take old code, given it a new name, and shipped it as a brand new thing. But GNU starts a brand-new, hot project based on better microkernel architecture and they use for it a name that people already associate with failure.
The L4Ka-based kernel is a new project that sounds like it has a lot of promise and may address problems that both Linux and commercial kernels have with modularity and extensibility. This new kernel should get a snazzy new name to get that message across.
Reminds me of the Dilbert comic strip ...
I've been boycotting Dilbert since its authors became BSA propaganda whores.
The way I see it is:
;-)
1. Hurd enables the port for Linux kernel modules (it was the case in the Mach series as I believe but the port was quite old 2.0.xx modules or so)
2. Port Gentoo to Hurd
I really hope Hurd developers can create better kernel than the Linux one. With all the woooo for Linux it is still not a perfect solution - buffer overflows etc. Such things should not happen in a good designed kernel.
If you add kernel hotplug and scalability (native clusters) there would be NO competition for Hurd. I hope
best regards - Michal
Fankly, I think it's a great thing that BSD and HURD will be putting some pressure on Linux to be the best. Competition makes them strong, and the cross-fertilization of ideas makes them stronger still.
Besides, HURD may end up being superior to Linux in some domains, such as high-reliability systems (think banking servers), driver development, OS research, shared systems, and the like.
Neat concept, but what if your graphics driver goes out?? Will it respawn automagically? Whaty if the hard drive controller's driver dies? Sometimes a neat concept ends up not being very practical. I would rather have the OS die if the hard drive controller's driver kicks off as there's less of a probablility of hard drive corruption. If the driver code for the hard drive dies and the kernel keeps running, would you not have lost alot data?
Gorkman
http://marcus-brinkmann.org/banner.jpg
Look, congrats and all, but if I'm going to run a pointless operating system, it's going to be one that's actually impressive, like MenuetOS .
I may be out of date, but wasn't this Tannenbaum's contention: that microkernel was possibly superior to monolithic architecture because of the stability of the kernel space?
I'm a little excited by the possibility of a solid Open MK, but a little dismayed at the thought that I may have to re-read Tannenbaum and Wirth (Oberon Project) to figure out what's going on. Does anyone have a link to an overview/comparison of kernel architectures? If so, this old fart thanks you.
"The mind works quicker than you think!"
On the other hand, every so often, even the linux kernel devs get sort of rabid and out of control. I don't like proprietary software any more than the next guy, but if it's the best tool for the job then that's life, and it should run. I shudder to imagine what HURD will be like in this regard, we'll none of us be allowed to run anything at all if RMS has his way.
While there are many "dying" projects out there (remember the "Windows replacements OS" hype?), HURD has always had the most of critique, mainly because it embodied the very promise of a GNU system to many people in its days.
But putting the whole history aside, you could see HURD as an exercise in OS development following the route of the more progressive design theories. You might be able to imagine how this pulls the interest of a small group of developers over a longer time, despite of the fact that development is going slowly.
You know how Free Software has the ability to evolve and persist aside from political influences, well, here is your new schoolbook example.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Linux doesn't work that well. No, hear me out. The design isn't very good, and it's starting to show. The fact that you need to be root to mount things, and the trouble with reiser4, are showing the flaws in the VFS layer. The confusion over what belongs in the SCSI subsystem, with atapi cd drives being moved out of it because linus doesn't like them there but everything else being rapidly moved in there, betrays deeper problems - I have been told that the scsi subsystem should be used for everything, but since the IDE one was put together first for linus' cheap hardware, ide uses that. And yet some things are being moved into the ide subsystem, and the scsi one is not as nice as it could be if it was moved up a layer where it seems to belong. This is because linux wasn't properly designed. It was always meant to be a temporary kludge, something to work until a proper replacement came along. So some design decisions were badly made from a long term point of view, and some weren't made at all, just sort of emerged as an imperfect compromise. The problems are becoming more and more evident, and it's getting to the stage where we need a replacement.
I am trolling
Don't you mean, "FRIST CDOE!"?
ok lameness filter time for much lowercase stuff ok ok ok lameness filter dealt with time to post
Dude, if the driver dies then by definition the kernel cannot communicate with the hard drive. How will any data get corrupted?
If the system is able to stay up without further drive access, that could potentially allow you to copy data still in RAM. If the OS simply instantly failed when the HD controller went, then any data in RAM would absolutely be lost.
:)). But most drivers wouldn't be that hard to restart... video and network are two very good examples. I have seen many 2.4 kernel crashes from what appeared to be network-driver failures. Presumably, a microkernel might have survived whatever the problem was.
:-)
Software failure is more common than hardware. In many cases, drivers can be restarted. Your specific example is probably the toughest one I can think of offhand... you'd have to have a copy of the HD controller cached somewhere to be able to restart it. (since, obviously, you can't load it from HD
You also, of course, have the advantage of each driver/process running in its own address apace, which would probably make very complex code, like the 2.6 Linux kernel, more manageable.
Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now.
But they didn't go that way, and restarting Linux kernel development would be pretty stupid, IMO.
BRAINFUCK! Or something like that with one less command.
On BeOS, when the sound subsystem crashed you would get a message informing you of this, and it would automatically attempt a restart. On Windows or Linux when the sound subsystem crashes, the odds are you've got a kernel panic (since the drivers run in kernel space).
I am TheRaven on Soylent News
Oh, it has lots of advantages, particularly for "kernel" developers and system administrators. For developers, implementing e.g. new file systems is much, much easier than in a monolithic kernel (although FUSE has helped here it still feels kind of like a hack). For sysadmins there is much less privileged code to worry about. (There's lots more but those are the ones that spring to mind).
HAND.
To a computer scientist, HURD is far more interesting than Linux or even BSD. It is based on a solid theoretical work, and should prove more stable, maintainable and adaptable than monolithic kernel approaches. To a 13 year old running around shouting `Linux is teh r0x0rz,' it is of no interest at all.
I am TheRaven on Soylent News
Windows XP's kernel is a modified microkernel design. Most people are unaware of this, but it means that the vast majority of the code your applications call are also running in user space. For example, on Windows 64 machines, there's a Windows 64 environment, a Windows 32 (WoW64) environment, and so on. In the olden days, there were DOS VDMs, POSIX, and OS/2 sub-systems.
Not every Windows or Linux driver is kernel-space, but most are.
However, with adequate testing, crashes due to buggy drivers are rare. If you choose to run crap drivers, of course you'll see problems. Including on
Andrew van der Stock
"You must be GNU here"
"Yes, but does it run GNU/Linux?"
"In Soviet Russia the first program executes GNU/Hurd"
"Netcraft confirms it, GNU/Hurd is dying"
"In Korea, only old people use GNU/Hurd"
"GNU/Hurd isn't ready for the desktop"
"Imagine a beowulf cluster of these"
"I've got a greased up GNU shoved up my..."
And lastly, something about a herd of Natalie Portmans and hot grits....
Guess it's time to restart based on the brand spanking new L5 kernel then? :P
The funny thing is that back when Linux was started, it could been seen as a restart of the HURD kernel development. What goes around comes around. :-)
Mach was still an active CMU project when the Hurd glacier began its very slow creep from the peaks of lofty idealism towards the throng of onlookers waiting patiently for the free unix kernel they always craved to reach them.
Well, its pace is matched then by the very slow creep of systems like Linux (and OS X and Windows) towards some semblance of coherent design and implementation.
You see, when you implement a system, you have two choices: you can do a shoddy and cheap job initially and fix things up later (Linux, Macintosh, Windows) but grab lots of market share, or you can try to do it right and not get a lot of market share.
Of course things are not black and white: some quick and dirty jobs (Linux, NeXT) are not quite as shoddy as others (Macintosh OS 1-9, Windows 3.1). And some people just can't design a decent system even if you give them nearly infinite resources and time (like the Windows NT kernel).
I'm glad efforts like L4Ka exist. The Linux kernel is not infinitely extensible, and we will need something to replace it eventually. Whether it's this or something else, I don't know. But you shouldn't sneer at it.
It's at the same stage as Linux was in 1994?
Great. I'm 40 next month, so maybe I will still be alive when its ready for the desktop!
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Do you think the total time saved by all the processes which ever run on the L4-HURD on any machine anywhere will ever be larger than the time taken to switch from MACH to L4?
_O_
.|< The named which can be named is not the true named
Now where'd I put that 200MIPS SparcStation to run it on...
I am MR MBOTO SHAW, Testamentory Executor of the Will of joe_bruin by appointment and prior arrangements made by the Township of KWANZAA-TOBOGO. After further investigation of his Next of Kin proved fruitless, I come to you in utmost Confidentiality so that the fruits of this old man's labor will not get into the hands of corrupt Township officials.
Date: Unknown
Place: Slashdot
when me and richard m. stallman (the m stands for 'merryweather', did
you know that?) started GNU/hurd back in 1908, we were out to replace
the closed-internals of the international business machines (ibm)
automatic punch card tabulator, which was at use at the time in the
department of the census (where me and rich were summer interns).
those machines had a 2mm steel case sealed with canadian metric square
screws (wherever you call them, please don't correct me). since nobody
had any metric screwdrivers at the time, much less square ones, we had
no access to the internal cogs and wheels of the tabulator. we
definitely did not want to punch through the casing, because that
would void our warranty and service contract, and we would have to
contract ibm to build us a second tabulator (which cost nearly 200
american dollars, and took 7 months to assemble).
when it (frequently) broke down, we had to call an ibm machinist to
come open the case for us and oil the flywheel or unjam the transverse
flying arm on the card-feeder. as you can imagine, this seemed hardly
the ideal solution, because usually all it needed was a little bit of
work that me and rich could easily perform (even through we were not
trained calculating machine operators).
long story short, we starting working on the GNU/hurd tabulator. the
centerpiece to our system was the pipelined card loader, which could
load the next punchcard while the calculating engine was stilll
churning on the previous card. we had also designed the system so that
you could have dual loading mechanisms, so that one would always be
running if the other jammed. rich always insisted that we should
publish the blueprints for our machine, so that other people in our
tabulation club could also build similar machines, and help us with
the design. to me the whole idea sounded a bit bolshevik, but richard
seemed intent to follow through with it, and i didn't mind so much.
honestly, i didn't believe he would ever be able to publish anything,
given that his handwriting was quite terrible (although he was working
on a new type of typewriter, the electro-macs so that he would be
somewhat more legible).
5 years later, when i was conscripted to join the great war in europe,
we had a nearly complete tabulator in hand. we had solved nearly all
the problems of page clipping and bending that were present in our
earlier builds, and our machine could run at a rate of well over 70
cards per minute (compared to the ibm's 42). however, we never
completed the loader fully, and the latest model i saw could only hold
3 cards on the loading queue, making it much less than useful (however
promising).
i've lost contact with rich during the war years. i had always assumed
he's been killed in action. anyway, i'm glad to see he's still going
strong with our GNU/hurd tabulator, and wish him well on it. hopefully
it will be done before my great grandkids graduate college.
-- joe_bruin @ slashdot
You're describing the bootstrapping problem, which if I recall correctly is actually described on the GNU website, somewhere.
To answer your question, the GNU devs started out with proprietary operating systems -- primarily SunOS, I think -- and took advantage of the modularity of UNIX to replace one utility at a time. This is why the kernel was the last piece -- because most of what makes a UNIX system run actually resides in user space.
Attempts to create free versions of other OS types -- ReactOS comes to mind -- have a harder time following this example, because most other operating systems are not designed in such a modular way. So they start with the kernel.
When I read about projects like this I know it is being worked on by guys who are more interesting in writing code than finishing a project. That's great for them, kudos that they have spent over twenty years on the same basic idea, but what about the people who wanted to actually get some work done in that time frame. The hurd is interesting as an example of a micro-kernel - but I got MP3's to rip, video to encode, documents to write, emails to reply to and life to get on with. Let us all know in another 5 years when they have some useful code running on the hurd.
All those moments will be lost in time, like tears in rain.
Windows XP does not have a microkernel. Windows NT had a microkernel until version 4, when Microsoft decided that the performance penalty of a microkernel was too high, so they chucked all the driver stuff back into kernel space.
Don't you hate meta-sigs?
I'm sure RMS appreciates your nod to him, but he actually doesn't want you to just randomly put GNU/ in front of every instance of Linux. In this case, you should actually just say Linux (and RMS would agree with me), because you aren't talking about GNU/Linux the OS, but Linux the kernel (which Linus wrote, or at least began). Linus did not write GNU/Linux -- most of that OS was written by other people, with most of the userland tools and libraries that make it function coming from the GNU project (hence the GNU/ monicker).
The GNU/Linux / Linux distinction is actually useful, because the OS and the kernel are distinctly different things. I usually just say Linux when it's clear which one I mean, but even if you don't appreciate RMS's point of view, you should understand that a kernel and an operating system are not the same thing.
I thought so.
Now, what was it you wanted to say?
if u were in the middle of a write then it doesn't matter whether u were in kernel or user space. a BSOD or a dead driver, your disk doesn't care.
With Linux, drivers compiled as modules usually don't take the system with them when they crash. They provoke an Oops, which is taken care of properly by the kernel (contrary to drivers compiled statically, which do Panics when crashing).
When they corrupt memory, it's of course a different story.
blah
Check out this analysis. The whole book is pretty good; I never looked at Dilbert in the same way after reading this.
Why did Linus start writing Gnu/Linux, when there were already great operating systems like Windows/Dos, and Unix/Unix?
Linus did not believe that Windows/DOS was great.
And at the time the only UNIX like thing that worked on x86 hardware was Xenix (I believe) so he posted a USENET message and Linux was born.
I actually just included the Gnu/Linux for the comedic purpose of contrasting it with Windows/Dos (Windows 3.1 running on the DOS "kernel"), and Unix/Unix (Unix running on the Unix kernel).
It sure had jumped the shark, anyway. The last couple of weeks in particular have had some seriously lame strips. It's a shame. I'm going to miss it.
"The Milliard Gargantubrain? A mere abacus - mention it not."
The only module that was converged with the kernel was the graphics subsystem. The NT kernel still remains a microkernel design to this day.
guess nobody bothered to g**gle it: New kernel for Darwin:
Obviously, there are a few things that would require a backup driver.
If the graphics driver goes out, launch a basic VGA driver. It will look dead ugly, but it should allow you to save your open documents. Then reboot while your buddy next door, who is runnning Windows, is still cursing about his lost data.
I admit that the hard drive controller's driver is more difficult to get right. Maybe you could use a simplified driver as backup that is built for reliability and does without those features (DMA for instance?) that are hard to get right on that particular system.
For anything that is not immediately necessary to an ordered shutdown of the computer:
Display a warning message and stop that driver until next reboot.
C - the footgun of programming languages
Your point? The world now knows there are viable alternatives, and they can be had for historical lows on price.
The world's got practice. It's no longer in the same state it was in '91. Back at that time, very few people had unix machines on their desk or at home. Unix ran in the computer room at work or school and you connected to the system but did little in the way of administration. Millions have been introduced to "the unix-like way of life" (TULWOF), superuser status, and have developed desires to exploit the powers of their machines in an infinite number of ways. The world is primed to be wowed again.
I see our future selves laughing at our current fascination with Linux like we now look at time we spent with DOS. We'll see someday how horribly inflexible it was compared to what's coming in this next generation of operating systems. Your post shows you know very little about the Hurd and what possibilities it will allow. One cannot currently imagine all the fun things people are going to do with it (them?) X years from now.
Exactly not the case. There are *profound* advantages [to "the Hurd"].
If and when a usable system comes to fruition is the question. Developers. Developers. Developers. Get them excited and you'll soon be doing things with your machine you'll never even have considered possible. Maybe not yourself, but people will be doing things they never dreamt possible. There are fundamental differences that are difficult to comprehend having experienced only monolithics. Granted, most of the advantages are not so much at the user level, but from a system administration perspective. Guys working "in the computer room" will probably have much more to be excited about than somebody with a user account. If you know what "having root" is like, the possibilities coming with the Hurd's architecture will be much more meaningful than they would to a typical user. However "typical user accounts" will be much more powerful on a box running the Hurd. Even low level stuff like filesystems floats up into "userland" allowing you the ability to customize your environment to great extents without affecting other users on the same machine.
Maybe more people should work on the current telephone system instead of wasting their time with VoIP. Maybe you should have worked harder at your old job instead of trying to find a new, better job? The Hurd is to Linux users like Linux is to DOS users. If Linux (as currently implemented) lives in N-space, the Hurd lives in N+1.
Resources get split up; sure. Consider however how the body of developers grows every day as more and more are introduced to TULWOF. None of us get to justify or dictate how others spend their free time. Get excited about the underdog. Linux has enough developers, don't you think? Will developments made on a new system with completely different rules positively effect Mr. Torvalds pet project? Most certainly I presume. I see the relationship as symbiotic. The Hurd takes on the huge body of software that has been developed due to "the Linux revolution" of the last decade and Linux takes from the Hurd (besides the jealousy that I can only predict will develop eventually) new techniques and perhaps, somehow, some type of hybrid approach to the kernel. There's no telling really; I can only imagine good things coming to both camps. Your attitude of discouraging work on such projects, done freely by others, I see as sel
Coral Cache Link
That story has been told I don't know how many times. Multics went under for the same reason HURD never took off. It was aimed too high for the resources available. When it became evident that nothing was going to come out of it in a reasonable time frame, Bell Labs got out of the project and that was why Unix was born. Nearly the same thing happened in the HURD/Linux story, the main difference is that Multics/Unix were commercial projects done by big corporations.
Looking with the benefit of hindsight, I'm willing to predict that HURD may become a viable OS, but it will never be very popular. It has been in existence for so long that it seems unlikely that it will gather momentum now. It may have some advantages, but it doesn't seem to be solving any pressing problem. Its defenders claim it has more stability, security, and flexibility than other systems, but these do not seem to be big problems with either Linux or OSX, so why switch?
No, we are not all agreed.
You might prefer your entire system to crash'n'burn because of a dodgy webcam driver, for example (or a buggy game controller driver, or a faulty TWAIN idriver, or a bad soundcard driver, or...), but I'd be much happier for just the webcam toi cease operation but still have the rest of the system working, thank you very much.
People should not be afraid of their governments - Governments should be afraid of their people.
Well, this has always existed in Linux and any Unix-like OS running X-Window. When the graphics driver goes out, one can go to another machine in the net and use telnet or ssh to log in. Either that or use a dumb terminal or another computer with a terminal emulator, through an RS-232 cable in the COM1 port, which is the basic setup one often uses when developing device drivers.
All your GNU are belong to us
Your specific example is probably the toughest one I can think of offhand... you'd have to have a copy of the HD controller cached somewhere to be able to restart it. (since, obviously, you can't load it from HD :)).
Note that you have to be able to load it from _somewhere_ in order to be able to bootstrap the system. I don't know how L4 solves this problem, but the toy microkernel I've been playing with for the last few years solves it by having a simple rom filesystem driver built into the kernel, and loading the drivers needed to bootstrap the rest of the system (i.e., the hard disk driver, the primary filesystem driver and the vfs layer driver) from that. If that crashes, you'd have a kernel panic, but it's highly unlikely as the code is _very_ simple -- it would probably indicate a serious hardware failure, in fact.
My system doesn't support restarting drivers at the moment, but in theory it could restart the hard disk driver if it crashed.
Then usually when such a driver does oops rmmod driver; modprove driver doesn't usually get it for some reason. At least the system is still responding and I can safely restart the system. On the other hand such crashes seem to happen only with the nvidia driver and not very often. I don't think I've seen an from source driver panic before.
Understanding is a three-edged sword. -- Kosh Naranek
Oh, I definitely never intended to imply that the HURD is stupid, not at all.
:-) And they are, from what I can see, treading very new ground, and that's always slow.
I was speaking specifcally about stopping development on the current Linux and starting over, which I think would be very dumb. Usually, rewriting a big software project from the ground up kills it. Mozilla, for instance, ceased to be a viable commercial force because of its rewrite; Microsoft ate it alive. Firefox is doing pretty well now, but no commercial entity could have made that mistake and survived, if selling browsers was its major source of revenue.
There's a huge amount of embecded knowledge on how PC hardware works buried in the Linux code, and rewriting that whole thing from scratch would be a gargantuan project. They've been working on it for, what, 11 years now? A total rewrite would take at least 3 or 4, during which all forward progress would stop. Just not a very good idea.
But I think it's great that the HURD is finally moving, at least a little bit. I will admit, I was a bit shocked that after roughly 15 years, they're just now able to load a program. But, hey, it's not like I needed it done last week or anything.
Reiterating: the more OSes, the better. I just don't think they should start over on Linux itself.
Of course, that requires having another computer. As I understand the theory, HURD would be able to start a replacement driver on the same machine. Which would help the Joe Sixpack who has only a single machine.
C - the footgun of programming languages
Once you had that kind of restart working well enough to not corrupt your filesystems, (very hard!!, I would think the OS would become more resistant to things like partial memory failures. In theory, atleast, the OS might be able to detect that parts of the RAM were bad, and be able to restart services that had been loaded in the bad segments. Of course, if the kernel itself was loaded into bad RAM, you'd still be screwed. A memory failure in user space, however, should be a correctable problem.
Ideally, of course, you want working hardware, but it would be cool if the freeware OSes were resilient enough to handle at least some hardware failures.
What is the difference between a cluster of systems all running Linux.( because its a cluster you can "pretend" each node is a microkernel process of the overall O.S - grid ) and using HURD?
How would a network of HURD machines compare to the most modern mainframes and grids that we have now. I'm interested to be educated on this matter
Thanks for the kernel...
I think his point is that:
1. Yes - if your filesystem code crashes, you could end up with a dirty filesystem.
2. Yes - if your hard drive code crashes, you could end up with a dirty hard drive.
But:
3. No - if your webcam driver crashes, you won't end up with a dirty hard drive.
Right now with linux, if a kernel-level driver of any kind panics, the whole thing goes down the tubes.
Certainly a little compartmentalization can't possibly hurt. It won't fix every problem, but it does prevent a small problem in a non-essential driver from taking down the whole system.
As you point out, it will still be critical for some pieces of code to just work without bugs at all. However, the amount of that code can be reduced in a microkernel design.
Also - I don't think TWAIN is windows-specific. I seem to recall using TWAIN on a Mac many a year ago...
You are not paying them to develop it, so they can take 100 years to make it, if they want or like.
That 2Gb thing again.
It's not a product.
They don't sell it, you don't have to buy it.
It might even be usable, because you can join partitions.
HURD is a hacker exercise of the best type!
Everyday features means little to OS developers. They can define what everyday features are. When you quit complaining, and when and if you get to see the birth of some GNU/HURD/L4 1.0, you will get the most advanced kernel at the time it's released, because noone is working more seriously on an advanced design.
MirrorDot Cache Link
Yes, actually.
;)
Error 407 - No creative sig found
You know, being intolerant of tolerance is not a good thing. I like freedom in software, but I also like to smoke weed every now and then. I'm not perfect and there is no perfect licence or model out there. Heck ,I'll miss using Slackware if I go and start usin Solaris, but screw it, I might just do it.
Any chance of them being able to hack something together so linux driver modules can be loaded?
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Those who think it's evil to advocate the enforcement of copyrights on commercial software should bear in mind that it is this same copyright law which is at the center of IBM's defence against SCO, which, if you need a reminder, is not "Copyrights are evil, man, and SCO needs to like, chill out and let it be free," but "Linux was copyrighted according to the GPL, and SCO violated those terms."
You can't apply copyright law only to those things which you, personally, want copyrighted.
I am Sartre of the Borg. Existence is futile.
Can't Linux drivers be ported to the HURD?
Correct me if I'm wrong, but due to their shared GPLv2 license, the below-mentioned "huge amount of embecded knowledge on how PC hardware works buried in the Linux code" can be leveraged for use in the HURD. This could be a boon for HURD development, because unlike the other Free OS Linux compatibility modes, the HURD can lift such code straight from the Linux kernel, giving it a significant advantage in that matter over others.
Maybe with a little work even proprietary drivers like NVidia and ATI drivers could be made to work. That would give it the huge advantage of being one of 3 Free OSs that has accellerated modern 3D hardware
1 - noone complained about your bitching.
2 - noone said GNU/HURD is an alternative to GNU/Linux right now, I specifically pointed out that _if_ and when it's released, it will be the best OS design available, ages ahead of Linux in design, meaning among other things portability, ease of developement, driver writeability. It's much easier to adapt a microkernel to multiple cores, coprocessor usage, like cheap GPUs, clusters. It's a design for today and tomorrow needs. Linux is a nice kernel, because it's there, but it's not beautiful. If and when the GNU/Hurd is a reality, it will be a better reality.
3 - No, I don't care about being trolled, I enjoy just answering random bullshit.
Coral Cache
MirrorDot
Many hanks to the people who run these cache services.
if you enjoyed this story please keep the wikinerds.org on your bookmarks. Thanks
It has always been a mystery to me that so many difficult problems have been solved by so many brilliant GNU teams (gas, gcc, gdb, gld, bfd, glibc, emacs, m4, grub, bash ...) that developing a good kernel has eluded them. The people that have developed these packages are certainly skilled enough. They have also demonstrated tremendous drive. Any ideas?
an ill wind that blows no good
Incorrect. In Andrew Tanenbaum's words: "Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0." (http://www.linuxbusinessweek.com/story/44969.htm) .
This sig under construction. Please check back later.
That's got to be some kind of record.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
"I, for one, welcome our GNU/Hurd Overlords"
Even a stopped clock gives the right time twice a day.
Wouldn't the driver be on a read-only filesystem, maybe even ROM or a CompactFlash type device? I thought we were talking about writing data to the disc... so it's going to the data disc, not the system disc.
Maybe a paranoid designer of an experimental system would expect things to break often. Writing to disc A fails, buffer cache is flushed to disc B and verified, before trying to diagnose the problem with disc A.
Beef
Yeah this is a milestone. Or is that a millstone.
Congratulations. Yawn. Due to the staggering delay between project start and minimal system, I think there will be a stunning lack of emotion until we see something friggin spectacular!
Bitter and proud of it.
Since I have one of those proprietary 5.1 surrand sound cards that really aren't usuable without configuring ALSA, whenever the system boots up, it just crashes the sound subsystem, everything else runs perfectly fine.
I find myself wondering what this will mean for Linux. Will there actually be something of a community split (at least initially) with people going off and trying the HURD? Obviously the "ready for the desktop" lemmings won't be among that crowd, but I'm still guessing there'll be a fair number of adventurous souls wanting to try it out once it's a bit more workable.
The kernel is not implemented as true microkernel. There is seperation, but the message passing is limited to IO request packets that are sent to and from the HAL from (properly written) drivers. The drivers run in the same thread but in a different execution context / ring (IIRC through a "door").
But drivers that require "fast IO" are running in the same address space as the kernel.
So while the IORP-using drivers shouldn't be able to take the system down, I wouldn't call it a microkernel exactly.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
With IRIX, a T-1000 shoots you in the foot. Then a T-Rex bites it off.
With UNICOS, you shoot yourself in the foot with an MP-5.
Facts do not cease to exist because they are ignored. - Aldous Huxley
... and I was expecting "Hello world!"
new OS kernel called HURD ... using the GNU Mach microkernel.
HURD-Mach was able to run a GUI and a browser, the developers decided to start from scratch and port the project to the high-performance L4 microkernel.
Ok, I'm confused. HURD is a kernel. L4 is a kernel. How do you port a kernel to a kernel?
Coder's Stone: The programming language quick ref for iPad
ROM: Yes, CompactFlash: NO. CF modules pretend to be IDE harddisks, they are attached to the HD controller and accessed using the HD controller driver. What you mean would be onboard flash; one or more flash parts mapped into the CPU's address space (just like ROM) which can be "magically" written to. Reading/writing them needs "physical memory access" rights, and if you want a filesystem (as opposed to, say, a single bootimage) you'll need a filesystem driver too (preferably one that is flash-friendly, like JFFS)
Maybe a paranoid designer of an experimental system would expect things to break often. Writing to disc A fails, buffer cache is flushed to disc B and verified, before trying to diagnose the problem with disc A.
This would require completely separate paths from userspace down to disks A and B. And by separate, i mean hard- and software: assume that drives A and B are connected to two distinct instances of "HD controller card XYZ": if you can't trust the XYZ-Driver, the data on B is suspect, too.
Contrast it with systems such as Windows and Linux where drivers are in kernel space and it is impossible to have a stable or secure system with poor drivers, and in fact most of the problems with Windows and Linux crashing is caused by buggy drivers running in kernel space.
And that's also why drivers in Linux (at least in my experience) are far superior and "just work". Seriously, I don't want my GFX card/network card/printer/webcam/whatever driver to crap out at any time, only to get "just restart it". Yes, they're buggy to begin with, and they take the house down, so you fix them. If I understand it correctly, the HURD kernel would have a fixed driver interface (being in its own keyspace and all), and what would that get you? Buggy closed-source drivers. Exactly what Linus is against, and mostly for good reasons.
Kjella
Live today, because you never know what tomorrow brings
1. Release a kernel 10 years after the Linux boom started which will never be used by anyone besides a few RMS fanboys and Free purists.
2. ????
3. Profit!
Yes, the BSA is making sure copyrights are respected, and that indirectly helps the open source licenses. But the BSA has been hostile to open source, and the more open source catches on, the more power the BSA loses.
The Dilbert cartoon does make one wonder about Scott Adam's attitudes towards issues of copyrights and freedom, and that is a justifiable reason to criticize him if it is true. That he indirectly and accidentally may or may not have a short-term positive effect on open source licenses doesn't matter.
First DOOM3 and Halo2 come out. Then the Red Sox win the World Series. Now HURD is about to reach a major milestone. Has someone called Hell to see if they are snowed under?
Well, there's spam egg sausage and spam, that's not got much spam in it.
Does this mean GNU/HURD will be available before my powerbook G5? It's coming out next tuesday, you just wait!
I try not to laugh in death's face. I tend to make belittling comments and snicker behind death's back.
Ermms? I belive that the Hurd team might dislike closed source drivers quite a bit more then Linus.
[sarcasm]GNU Software: It works! Fuck, lets re-write it before people find some sort of use for it![/sarcasm]
I know HURD must be more of a research project than anything else - otherwise they'd be trying to get something at least usable to arouse some interest in the project.
I admire what HURD attempts to achieve, but at the moment its a bit of an incomplete solution to a non-problem (find an open-source kernel for the GNU operating environment)....
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Microkernels would be helped tremendously if 80x86 CPUs did not only have rings but also regions...because a faulty driver can write to anything inside its ring and lower-priviliged rings.
The ring protection should have been inside the page table. A page descriptor has enough room for that. It should have been like this:
Page Descriptor with Ring Protection:
bit 0: page present/missing
bits 1-3: other
bits 4-5: current ring
bits 6-7: Read ring
bits 8-9: Write ring
bits 10-11: eXecute ring
bits 12-31: page frame
So in order for some piece of code in a certain page A to read from another page B, it should be that A.page_ring = A.read_ring. The same goes for write and execute access.
This mechanism has many advantages over the current one:
a) ring protection is per page and not per segment. Segments become totally irrelevant for protection.
b) there is no need for ring gates. A process in ring 3 can execute code of ring 0 if the kernel page allows it. There is also no need for special instructions like 'syscall'.
c) higher-privileged code can have const data be read from lower-privileged code.
d) device drivers can easily be isolated from the kernel.
e) there is no need for special 'virus' protectiobn bit, since executable code can have write ring set to 0 and execute ring to 3 (which means an application can not execute data).
Can GLX fans expect to see a usuable GNU/Hurd distro before the next full release of Debian?
These microkernels running services make much more sense on a processor with multiple cores - the main problem on a traditional "single-threaded" processor is there is way too much OS overhead 25-30% with the microkernel strategy, compared to a monolithic kernel. So in 5 to 10 years, as the HURD moves forward galacially like the plot to Dr. Who, this will be a good foundation for the new generation of processors.
Wasn't it back in about 1991ish, when Linus still thought that Linux wasn't going to be anything special, that Linus said "maybe in the next year or so HURD will become useful", or something similar to those lines? implying that HURD would displace any usefulness of Linux.. hmm.. my my my how things have changed.
Aside from academics is there any reason whatsoever that anyone on earth would ever want to attempt to operate this?
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
How about a microkernel Linux?
Take the time to read their paper about performance and issues related to linux on L4 - interesting stats like a 5% penalty for L4, as compared to a 25% for Mach...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Yes and no.
HURD is interesting but so is Linux. Look at things like OpenMosix and the work Google is doing.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
What about QNX? it is microkernel based and seem to work very well in practice.
I tend to agree with you that the ideal system would by somewhere between a microkernel and a monolithic.
The comment that you can always rmmod usb-storage && modeprobe usb-storage is so geekish.
An ideal system would handle that for you.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
There is a interesting little book called "The trouble with Dilbert : how corporate culture gets the last laugh," by Norman Solomon that is an extended polemic on the ways in which Scott Adams has allegedly become a tool for the corporate overlords. The basic argument is that by making slightly-but-not-too subversive cracks at modern corporate life Dilbert defuses potentially revolutionary worker resentment. We all recognize our own feelings of helplessness, laugh a little, feel as if we are "sticking to the man" by posting our favorite PHB cartoon on the cubicle wall, and then go on with life without ever substantially challenging the structures of modern capitalism.
It's Dilbert meets Marx. Fun stuff.
And if you're really inclined to help the Hurd along, and have more money than hack time, you could always make adonation.
There's more people using these nowadays than there were people having a computer at home 22 years ago so there are more home hackers NOW.
Trolling using another account since 2005.
There's more than just device driver isolation. Think about all the virtualization techniques out there (Xen, User Mode Linux, VMware, QEmu, Plex86, Linux VServer, etc.) Now think about what it would be like if high levels of process isolation were available "Right-Out-of-the-Box". That's the whole idea behind a multi-server like the Hurd.
"...which enabled him to execute the first software on HURD-L4."
And in another fifteen years, they'll finish the code that allows them to stop that program.
"Mozilla" (Netscape) wasn't killed because of the rewrite. They were killed because version 4.7x sucked, and they couldn't compete with free as in beer.
The article isn't saying that they could only just now boot HURD, it is saying that they moved from the Mach microkernel to the L4 microkernel, and since the move they have just been able to run programs.
That doesn't help if your graphics driver has crashed the kernel.
Daniel
Hurry up and jump on the individualist bandwagon!
I keep re-reading your post, and I'm still no less confused.
Based on your words, you are saying:
1.) You don't want your drivers to be able to restart when they "crap out." This means you want the whole kernel to die instead?
2.) You say the drivers are buggy and take the whole house down, requiring fixing. You prefer the whole house to be taken down rather than just restarting the driver in userspace to stay running?
3.) You talk about buggy, closed-source drivers right after you've already said open source drivers are buggy and take the whole house down. So what's the difference?
4.) You argue against a fixed driver interface like every other modern operating system has, allowing for both open source and commercial driver development (that whole choice thing, right?). Your only supporting evidence appears to be that "Linus is against it." Linus is not a perfect developer whose words should always be followed.
What if we started taking development for 2.8 in the direction of microkernel functionality without making it a microkernel? Say we just coded in the difference, where modules are run in userspace instead of kernel space while keeping a "protected memory space" of the filesystem, hard drive, and other other driver modules (as an option of course). We can do this so that if hardware failure happens it can be restarted, we also can recover the hd/fs in case that goes and if a module decides to crash (as if a module has cognitive ability to do so) it won't take out the kernel.
I'm not a kernel programmer by any stretch of the imagination, but just how possible is this? Meaning, is it feasable to do this within the timeframe of any 2.8 or even 3.0 kernel development, and what would we have to do to make it this way?
I personally don't like any driver taking out my whole system, nor do I like having to reboot just because I upgraded or compiled and installed a newer driver/module. (sometimes it happens)
Help me out here fellas
Hurd will never be big and professional like Linux ;-)
LedgerSMB: Open source Accounting/ERP
Believe it then. Already done.
-Dan
to have a wide addoption of GNU/HURD as a Desktop OS? From what you say, it sounds like the dream OS - at least regarding security and stability - to me.
Before this, well it was just out of the radar, but now... I'm starting to think that maybe in some years, there could be a viable alternative to Windows AND Linux.
What do you think ppl?
I think it's really nice how Linux, by making the code accessible, allows smart people to improve it in ways that were not originally in the plan.
Well, I was intrigued enough to load it onto a floppy and give it a try.
It's pretty cool that you get a such a responsive and slick GUI running off a floppy.
I think all it needs to be of some minimal use is a half-decent web browser. They had some testing browser that can load the text of webpages (but no images), but I didn't see that even hyperlinks worked in it. I gave their telnet client a try too, but had no luck interacting through it, although it seemed to connect.
If they could get a nice browser running on it, it'd be great to use for cheap web kiosks.
I wonder how hard it would be to port something to it.
The Hurd website, wiki, etc. haven't been updated in years.
At a more fundamental level, there's a design disaster in the making here. L4 seems to make the same mistake Mach made with interprocess communication - unidirectional IPC. This design error is called "what you want is a subroutine call, but what the OS gives you is an I/O operation". This is a crucial design decision. Botch this and your microkernel performance will suck.
QNX gets it right - the basic message-passing primitive is MsgSend, which sends a message and blocks until a reply is received (or a timeout occurs). The implementation immediately transfers control to the destination process (assuming it's waiting for a message), without a trip through the scheduler. That's crucial to getting good performance on real work from a microkernel.
Mach botched this. Mach IPC is pipe-like, with one-way transmission. And that's a major reason Mach was a flop. (Note that the version of Mach used for the MacOS isn't the final "pure Mach", it's a Berkeley BSD UNIX kernel with Mach extensions.)
Why does this matter so much? Because if send doesn't block, when you send, control continues in the sending process. Later, presumably, the sending process blocks waiting for a reply. But who runs next? Whoever was ready to run next. If you're CPU-bound and there are processes ready to run, every time you do a message pass, you lose your turn and your quantum, and have to wait. So programs with extensive IPC activity grind to a crawl on a loaded system.
But if message passing is tightly integrated with scheduling, a message pass doesn't hurt your thread's CPU access. Control continues in the new process with the same quantum (and in QNX, the same priority by default, which avoids priority inversions in real time work). Now message passing is only slightly more expensive than a subroutine call, and can be used for everything.
There is a big literature about Mach, Minix and related underperforming academic microkernels, while the key architectural details of the commercial microkernels that work (basically QNX and IBM's VM) aren't well publicized. But you can dig the information out if you work at it.
BSA tactics: you pay them or we hurt you financially.
Yes, the BSA is enforcing legal licenses (albeit, IMHO, draconian, and legal only under our current business-subservient patent system), but otherwise it really is the same thing. The mafia provided a service; a group of thugs wouldn't drop by and ruin your business. The BSA prevents a group of lawyers from stopping by and ruining your business.
The cost of litigation, even when you are in the right, is a far more dangerous weapon, in this business climate, than a baseball bat. A lawyer can impoverish you for years, a baseball bat is likely just to involve some transient pain and medical expenses.
... grumble, grumble, grumble, mutter, mutter, Millenium... Hand... Shrimp, I tol' 'em, I tol' 'em.
Are there hooks to install modules for "trusted" device drivers to allow them to run in kernel space faster for devices which require high performance? (Such as network cards in servers, 3D graphics, low latency Audio drivers, etc...)
Maybe it would be good to have a hybrid kernel which allows only userspace drivers in general but vendors who wish to certify their drivers and have them crypo signed can get them installed in high performance kernel space?
Is this a viable idea (in the longer term obviously) or is it just completely off the wall?
Your ignorance is infinitely greater than you realize.
Can someone explain to me how to interpret the screenshot as a successful execution of anything?
It looks like a spew of debugging messages, with a few blobs of # symbols.
Are those blobs supposed to be part of the banner output? I don't get it.
From what I can tell, this Hurd port was using the L4Ka::Pistachio kernel, which is licensed as BSD and not GPL. I am surprised that GNU would go for that.
"Just as an offhand observation, I kind of wonder if the 2.6 Linux kernel isn't approaching the level of diminishing returns... it's gotten so complex that it's getting pretty tough to cleanly improve without blowing a lot of stuff up. A microkernel design would probably have made maintenance easier, and *probably* would have given us more stable systems now."
No. That's just the fact that they're doing active development on it. If they'd leave it alone for a few months it would stabalize.
I rarely criticize things I don't care about.
Because I'm right. Don't believe it just because I've said it, but look at my arguments. Look at the kerfuffle in the layers I've mentioned, and see if you think it's real. See if you think it matters. See if you think it's symptomatic of a problem with Linux. I think it is, and I think anyone who looks at it objectively will see that it is. But by all means don't just take my word for it.
I am trolling
All in due time....
Media that can be recorded and distributed can be recorded and distributed.
-kfg
Did anyone else take that last statement as being some sort of reference to The Rocky Horror Picture Show that I missed the meaning of?
Magenta sounding a gong
Magenta: "Master, dinner is prepared!"
Frankenfurter: "Excellent. Under the circumstances. Formal dress, is to be optional"
As I demonstrate that I've seen that movie may to many f'king times, AND IT KEEPS GETTING FUNNIER EVERY TIME I SEE IT"
Yes, "the world" as in anybody who would care to implement a computer to do some work for a multitude of users. Geek development community. Check. Businesses in search of a computing platform designed for stability and flexibility. Check. Operating system researchers. Check. Linux users. Obviously, check. Those in need of superior reliability. Check.
My mother? She's not part of the world to which I'm referring. But she does know there are viable alternatives to the desktop she's found herself sometimes tortured by on a daily basis.
The modern world has been introduced to Linux. They heard about it during the bubble. People now know there are other things out there besides what comes from Redmond, SCO, IBM, or HP. If they find that isn't suitable for them, or it has failed them in the past, they can search for alternatives. What's more valuable than choice when searching for alternatives? The argument can be made that choice quality is more valuable than choice volume. I'd counter with the fact that competition between choices typically raises quality across the board.
Unix has been around for a long time and in the meantime computing users have explored many of the alternatives. OS/2 and BeOS have not lived up to the task. BSD can certainly stand on it's own. NeXTStep's legacy can be seen in the wildly popular OSX from Apple. Who's to say something better than Linux can't come along?
Admittedly, referring to a bunch of geeks and business as "the world" is a stretch. Point taken. One must look however at growing market share in Asia, India and other places across the globe to understand why I chose the term. Growth in these places is booming. The world is waking up to life outside the intentional incompatibilities and blue screens currently sitting on their desks.
I refer the reader here.
HURD will never ever be where Linux is...
By that logic, no one should ever start a new software project that isn't already being met (however inadequately) by some other piece of software. Why did Linus start writing Gnu/Linux, when there were already great operating systems like Windows/Dos, and Unix/Unix?
Fankly, I think it's a great thing that BSD and HURD will be putting some pressure on Linux to be the best. Competition makes them strong, and the cross-fertilization of ideas makes them stronger still.
I couldn't agree more. I've been a fan and ardent user of Linux since the 0.49 days (1993), and I find FreeBSD and HURD developments exciting and, frankly, important. Not just because it puts a little friendly pressure on the Linux developers, but because diversity is good.
Take for example the licensing issues Linux could have if the developers find themselves needing to move to Version 3.0 of the GPL (this may not happen, and I certainly hope software patents and the like never force such a move, but you never know, and given the current climate, a migration to an updated license may well be required, at least in the US). If Linux were to ever become mired in a untenable license and unable to get unanimous agreement to update said license, we'll still have FreeBSD on one side and an FSF-compliantly GPLed HURD on the other.
This isn't likely (and I really hope it never happens and people can accuse me of wearing a ten-gallon tinfoil hat), but regardless, having a third viable kernel for running free software and all the GNU stuff will be a wonderful thing. As you say, at the very least it will be optimal for certain niches, and if it does turn out to be really superior to the existing monolithic kernels, it could well replace Linux as the defacto standard down the road. I'm not sure that's terribly likely either, but you never know, and having the option available to the community is a tremendously good thing, whether we choose to migrate because of litigation/licensing issues, technical issues, a combination of the two, or not at all (and it remains a niche product).
The Future of Human Evolution: Autonomy
Something to remember is that almost all of the technologies that we use today date back to the sixties. Object oriented programming dates back to the sixties, and yet it wasn't until C++ that it finally broke out into the mainstream. Likewise, it took how many years for the Internet to break out and become useful to people?
The fact is that most stuff that comes out of the Computer Science departments takes years before it can become a useful and practical in the real world. The people sneering at microkernels as an old CS idea that will never work probably were the same folks sneering at OOP when C++ first came out, discussing how broken the C++ implementation was. Or a bunch of other concepts.
The fact is that in time Linux may well shift over to a microkernel to provide advance functionality someday. It may be that microkernel technology is just a little ahead of its time and it's just going to take a few more years for the computer world to catch up to it.
Linux too is able to run on top of a version of L4 from the University of Dresden: L4Linux. There's more to L4 than we may think of at first glance!
cpghost at Cordula's Web.
most of the problems with Windows and Linux crashing is caused by buggy drivers running in kernel space
When was the last time you had your Windows or Linux system crash? Personally it's been years for me. Maybe this will make driver development easier, but other than that I don't really see the point in practical terms.
Sorry to be pessimistic but I don't see any interest to a new kernel.
Whatever design they choose, I have lots of doubts that it will bring any serious improvement.
Even if the linux kernel doesn't have any microkernel design, it did not prevent it to evolve in many directions.
And whatever the design is, they need to evolve... and the evolution is driven by advances in hardware mostly... I'm not sure if in the long run a microkernel has really any advantages.
Also something that I'm not sure Kernel developers have in mind are drivers... do they expect that driver developers will rewrite all existing drivers for their new kernel?
It is enough of a challenge to get drivers for the linux platform, I'm afraid that too many platform would slow down these developments.
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.
As far as I know, the HURD license has no such preamble, which means that you cannot run any non-GPL'ed programs on HURD. None, zero, zip. Why? Because clause 2b of the GPL states:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
The reason Linus put the preamble in is that this clause means that if you put two programs in memory at the same time, and they interact in any way, you have created a third derivative program. This is so that, I as an commercial software developer can't simply do some type of unothodox dynamic linking to get around the intent of the 2b. But since every user program must talk to the OS, under this interpretation, every user program must be GPL'ed. Hence Linus' preamble.
So while nobody cares today (and rightly so), somebody will make this an issue at some point, because it has already been made an issue with Linux. If/when it gets made an issue, I cannot foresee RMS putting in a preamble like Linus did.
In this case HURD will only run GPL software, and is therefore useless to general public. It even would be useless to me, and I've used *BSD and GNU/Linux since 1994.
Saudi Arabia is already a puppet, Nepal is too inconsequential to merit American's attention, and NKorea and China are too strong.
Even Amiga or Atari 400/800 has more users than HURD ever will!
ACHTUNG! Das computermachine ist nicht fuer gefingerpoken und mittengrabben. Ist nicht fuer gewerken bei das dumpkopfen.
(I'm not this post's grandparent, btw)
:P It does seem to be the best, most efficient way to do it, though. Things like CF/IDE/PCMCIA/USB interaction is all quite a bit kludged at the moment. The CF card -> USB -> cardbus/yenta_socket ordeal springs to mind in addition to your comment on SCSI IDE emulation...
What you say makes sense to me. I've not really thought about it much before, but after reading your post I started thinking about how devices are used and referred to, what you said is pretty clear.
I wouldn't necessarily agree that it's all that terribly "broken" but I do agree that some more thought should probably be put into redesigning the different device chains, based on my (limited) knowledge of how they work. Maybe simply have a universal chain which any device can use, and then have modularity to it so any bus type could use it.
But I digress, that's not very monolithic, now is it.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
What OS we we be using in 20 years, 50 years, 100 years time ? One answer is that it will be Microkernel based
In 100 years we will probably be using quantum computers and all of today's OS paradigms will be obsolete.
Microkernel Linux was already done, by Apple, as a prelude to MacOS X (I think they did it mostly to understand the Mach technology). It was an interesting idea, and at the time it was the only freeware OS that'll run on a NuBus Power Mac, but after it got off the ground it was superseded by LinuxPPC, which was ultimately backported to the NuBus machines. It exists now only as a curiosity, and it's so far behind the times that it's really only worth it as an academic exercise.
I really wonder how much it's worth to contribute and continue projects like this one (and even to Linux at larger scale). Both of them are SO old. Linux, for example, is so freaking outdated from modern OS point of view. Managed .Net and Java style VMs is the next evolution of moden OS but Linux hasn't even reached to a technology summit where Microsoft COM was 5 years ago. Yeah, I know all those security issues and blunders. But from pure OS sophistication point of view, that was the awesome way to let applications built by components. Look at even FireFox. Those poor guys have finally realised its importance and now has started duplicating MS COM as their own XPCOM. But to a person who looks at OS by their feature-richness, technology like XPCOM is an old news from last century. Sometime I don't know what these Linux guys so proud of? For carrieng burden of that '60s OS concepts still in 2000s? Look at the difference between MS and them. MS renews their OS, applies new technologies like COM and .Net and keep building ever more sophisticated dev tools every 5 years or so. It's not because they are not smart but it's because they have evolved so fast. Technically, Windows is far reacher OS than Linux any single day. I view Linux is stuck on Unix base and deprived of many modernizations that goes under the hood of Windows and Macs. Is it because most of these guys are from really old generation. Every now and then some geek of 80s comes around, builds a process loader and sends out news about new OS and others rejoices. Pathetic.
The BeOS sound subsystem, the Media Server as they call it, is a user-space daemon, not a driver. It is analogous to artsd, the KDE sound daemon (which can crash and restart successfully). The BeOS soundcard driver, similar to ALSA, if crashed would bring the OS down with it.
Does an instant segfault really count?
Mix the failings of Usenet with the shortcomings of the World Wide Web and the result is slashdot.
Interesting. Under BeOS 4.x my sound would sometimes drop out permanently and never recover. No message and no sound.
I have never had this problem on Linux save when I briefly flirted with commercial drivers for the Terratec 64. "Open Sound System" was always a joke.
-josh
But this is on L4, not Mach, runs on x86 (AFAIK only x86), and is up to date; 2.4.28, and 2.6.10 are available.
Linux on Mach (MkLinux) is as you describe, and even L4Linux was done mostly to understand the L4 technology. but the L4 port is definitely more that a curiosity...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Hurd Undergoes Repeated Delays
"OMG, d00dz, it runs a program now! What do we do?!"
"Oh, fuck, dude, I dunno! We should start over from scratch or something!"
"Hey, good idea!"
It's not an L4-based kernel. L4 is the kernel, the rest, while part of the OS, is not. Most of the rest will simply reuse the code from the Hurd on Mach, so it really isn't a different project. It only has a different structure underneath (which isn't visible to anyone but system programmers, except for performance and security).
It's not the kernel which will solve them, but we hope they are indeed solved by the project.
How about calling the kernel L4, as their makers named it? (Just like we all call a certain operating system GNU, as its makers named it ;-) ). That's a snazzy new name, compared to Mach, don't you think? ;-)
I recall an October 2004 article in which Mr. Torvalds suggested that ...HURD is dead. I could not help but wonder if this was an attempt to assure spectators like myself that the HURD project is *still alive*.
Make no mistake, I will definitely give HURD a shot when it becomes as usable as Linux was five years ago. Given the time delay taken to report execution of the first application, I suspect such usability is decades away. By that time, Linux itself may have been replaced by a more efficient kernel, Microsoft may have to compete with Apple for minuscle market share, and BSD-style forks may have happened to the HURD code.
The glacial pace of HURD development may explain why it took more than three months for them to take this action which may be seen as a response to Linus' comments.
Not a troll, just a thought.
In fact, the system should be called GNU even if the FSF didn't write a single line of code.
If I put something together out of blocks, none of which I made, I still get to choose the name for my creation. Then if someone exchanges one block for something he made himself, that doesn't change the name of the creation (unless it was significantly changing it, so the original is not recognisable).
This is very much what happened. The FSF put a system together and gave it a name. They even wrote a substatial amount of code to get the system working, but that doesn't really matter. Linus wrote a kernel and plugged it in (with quite some help from the FSF, btw, as it is not a trivial thing to do).
For historical reasons people call the whole system Linux, not GNU. RMS is quite right to say "I made the system, I get to choose the name". The name is GNU. Only for PR reasons or clarity could you consider calling it GNU/Linux, or "a Linux-based GNU system".
That is really great to hear. Now I have no doubts that Debian GNU/Hurd will be my future system of choice. Today I use Debian GNU/Linux and my main problems are drivers running in the kernel space causing security and stability issues and the lack of real capability system. I'm glad that there is going to be a perfect system for my needs hopefully in not too distant future.
I'm sure I will use it even for the price of nonportability because I have already hit the wall of user-based privilege control system's limitations too many times, which is quite frustrating as no one else seems to see any problem with them. I suppose that there will be some convenient way similar to chroot and ulimit to run programs with restricted privileges even if they are themselves not aware and dependent on capabilities. Also I hope that it will be possible to use capabilities where available from managed environments like Parrot or maybe even directly in places like Apache configuration to give specific and limited rights to individual scripts. The possibilities are very promising.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."