Slashdot Mirror
Hurd/L4 Developer Marcus Brinkmann Interviewed
wikinerd writes "A few years ago when the GNU OS was almost complete, the kernel was the last missing piece, and most distributors combined GNU with the Linux kernel. But the GNU developers continued their efforts and unveiled the Hurd in 1990s, which is currently a functioning prototype. After the Mach microkernel was considered insufficient, some developers decided to start a new project porting the Hurd on the more advanced L4 microkernel using cutting-edge operating system design, thus creating the Hurd/L4. Last February one of the main developers, Marcus Brinkmann, completed the process initialization code and showed a screenshot of the first program executed on Hurd/L4 saying 'The dinner is prepared!' Now he has granted an interview about Hurd/L4, explaining the advantages of microkernels, the Hurd/L4 architecture, the project's goals and how he started the Debian port to Hurd."
Now they can begin porting Duke Nukem: Forever!
Send email from the afterlife! Write your e-will at Dead Man's Switch.
That's the difference between OSS and proprietary companies. They can focus like a laser on what they want to develop and leave a lot of the infrastructural heavy lifting to those hippy anarchists in the open source scene.
It's win-win for them, because they get the benefit of a lot of what these groups produce, and often can improve upon it (BSD --> OSX). It's like having an unpaid R&D dept. working for you 24/7.
Hi Marcus,
How many people do you think will submit questions thinking that this is a Slashdot interview?
I'm sorry, but I find this funny.
1. "the GNU OS was almost complete, the kernel was the last missing piece" -- what?! The operating system is almost complete, oh, apart from the whole thing that does the operating of your computer of course.
2. "unveiled the Hurd in 1990s, which is currently a functioning prototype" -- so, ~15 years (fifteen years!) later, it's still a "functioning" prototype!?
I really hope that they have the last laugh.
http://www.mirrordot.org/stories/ab33baa0ec2390357 863935709927f7e/index.html
Get a free iPod Nano 4GB!
GNU made most of the core programs that Linux normally uses, and they are universally considered excellent. So why is it so hard for them to make a kernel?
Is it just loss of interest after Linux became popular?
# cat
Damn, my RAM is full of llamas.
This was in 1991...
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
The kernel is the last missing piece? What's the first piece, an integrated browser?
http://dilse.net/hurd.html
Zot. Buh-bye Hurd.
On the other hand, I guess I'm not the only one of this mind, as it obviously wouldn't have taken 20 years to get to the point where a program can finally run on it if everybody else with development skills didn't also believe it a total waste of their time.
Software piracy is victimless theft.
A project started in 1983 and only now starting to show any signs of deliverables! Just let it go. It might be a cool idea but it should be pretty obvious by now there is little or no intrest in it if 20 years of development have only gotten this far.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
It's the device drivers, stupid!*
*The Hurd will go the way of other exotic and unused operating systems if these people continue to sit in their little dream castles and plan for world domination. It's like trying to row a Viking longboat without oars, trying to grill meat without a fork, or more to the taste of our slashdot crowd, trying to masturbate with one's hands tied behind one's back.
http://mirrordot.org/stories/ab33baa0ec23903578639 35709927f7e/index.html
I have no idea why Linux became more popular in the first place, considering that there was already BSD and the HURD, but it's current popularity has pretty much killed any chance HURD had. BSD still has enough adherants that it can be continuously developed, but HURD never did. All the programmers who a) have the expertise required and b) are willing to work for free, are working on either Linux or BSD. I think HURD offers interesting possibilities, but I don't think a stable HURD will ever see the light of day. The fact is, Linux is a free kernel, it works well, has reasonable driver support, and is here now. That will be a big obstacle for HURD to overcome.
Actually, the free developers are the one who focus like a laser on what they want to develop. At a Big Dumb Company(tm) the developers may not focus as sharply as the "decision makers". Here, the decisions are made by the developers and hence there is better focus on the goals. If it were universally agreed what the goal should be, everyone would focus. Since it's not a given, people will latch onto things others may think are unnecessary. My own experience shows that most people will not be convinced that an alternative is better until you show them. That means those interested in the Hurd must build it and show the rest of you. Only then should we decide.
Does anyone else think its funny that every time he mentions linux he says "GNU/Linux", but he never once says "GNU/Hurd"?
You can't get 'too many' open source kernels. All right, the HURD is old, and development is slow. But at least it is another choice.
Consider the alternative if GNU project wasn't started by RMS... even Linux wouldn't have been around...
Oh well, some people are born to lose.
Ruby Neural Evolution of Augmenting Topologies
"My own experience shows that most people will not be convinced that an alternative is better until you show them."
And hence academic research. Like Xerox Parc.
If you don't want to RTFA, you could at least read the Slashdot intro.
There's a link on the L4Ka site to a port of the linux kernel to the L4Ka architecture, with a pleasingly higher ratio of the frequency of the words "cvs" to "advanced".
(and what's with "now he has granted an interview..."? is he the pope?)
"Consider the alternative if GNU project wasn't started by RMS... even Linux wouldn't have been around..."
His parents will be surprised to hear that.
> This was in 1991...
> > Hurd will be out in a year
Yes, but they didn't specify what kind of years.
Here on Uranus, one year is 17.9 earth years, so HURD should be out Real Soon Now on earth.
Of course, if they counted in dog years on Uranus, you'd have to wait a bit longer....
2. "unveiled the Hurd in 1990s, which is currently a functioning prototype" -- so, ~15 years (fifteen years!) later, it's still a "functioning" prototype!?
Operating systems develop slowly in their core design and philosophy, and that's no bad thing.
Linux literally exploded into existence, but its design is 80% identical to that of original Unixes so it enjoyed the immense benefits of inherent architectural stability. Linux knows where it's going, but the horizons surrounding the Hurd are very fuzzy indeed. It will take time.
While we're on the topic of microkernels, wouldn't it be a good idea to gradually make the linux kernel less monolithic, finally turning it into a nifty microkernel based OS? Is there anything going on in this direction?
Could you please stop interviewing him and let Marcus get back to work? If you keep interviewing him, we're never going to see Hurd in a usable state.
It's not offtopic, dumbass. It's orthogonal.
Ahh... The sounds of trolls grumbling from deep in their caves.
Hurd is not DOA.
This can be said definitively for two reasons:
First, after whatever interminably long length of time, it's still under development and still being discussed. The project has not flat-lined yet. There's still tremendous interest in it; evidenced by two stories about it here, on Slashdot, in the past two months.
Second, everyone saying it's dead on arrival miss the point entirely. Universally, they scream, "Why bother, Linux is here and it works!" They talk of it, casting it as another David & Goliath fight, pitting Hurd against Linux. People, that's not the point of it at all.
The current interest in it is as a _research_ project. The FSF goal of implementing a free alternative to licensed software has been proven possible. Has it all been done under the banner of GNU? No, but it has been done under the banner of Debian, Red Hat, Mandrake, Gentoo, etc, etc, etc. Stallman's dream is alive and well; to say that his gift has to live and operate under three specific letters in the name is a restrictive triviality. The point is his dream lives and operates under a license colloquially known by three specific letters: GPL.
--jlm
Been there, done that.
i see many opst here and i wonder if y'all know that HURD has a key feature, namely:
>>it should become possible to replace a running kernel
in other words NEVER REBOOT AGAIN!
in practise this is still hard to accomplish: but at least people are working on it. and yes, to implement this takes time.
GNU/Hurd is still developed, because it has interesting capabilities, capabilities Linux will never have. IMHO, Hurd is the kernel of the future.
Btw, Hurd will be compatible with a lot of linux' device drivers (i heard all linux 2.0 device drivers were ported, but I could be mistaken) , and imho, device drivers aren't the main job of kernel developers, but of hardware makers. That is a bit unrealistic at this time, though, but it should be.
Many of the posts above say Hurd is a waste of time. I suspect the Hurd team just enjoys hacking. I really don't think they care if its a "waste" of time. They just love what they do. I think it's awesome to be so dedicated to your craft. Even if the Hurd never works... I bet they will still look back on the whole experience as something pretty cool.
My own personal experience: I worked on an 8 month student project that in many ways failed in the end. But I would never consider that a waste of time. I learned so much and had a blast doing it.
-bdb
HA! remember when they were wondering if 2.6 should have been called 3.0...
What if they turn linux microkernal...then I think jumping from 2.7(or 2.whatever) to 3.0.0 would make sense
There's no infighting where you work?
Who do you work for and where can I send my resume?
I rarely criticize things I don't care about.
A microkernel design (while exceedingly elegant) was usually dismissed as being too slow (since the kernel was usually stuck sending tons of messages between these different services). However, we've proven time and time again that at a certain point ... performance becomes a secondary concern to maintainability and security/stability. Microkernels make that tradeoff and there are quite a few areas where this makes a lot of sense. Please read the original discussion between Linus and Tannenbaum circa '91 where they hash out WHY these things are different (it's a great read)
From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
"I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design"
To Linus Torvalds.
Don't any of those folks get the concept of R & D?
Think of the Hurd as a testing ground for cutting-edge OS ideas. Someday, it may result in an extremely scalable, secure and flexible operating system for servers that leapfrogs Linux, BSD, Solaris, OS X etc. Or it may languish as a mere experiment, providing valuable ideas and experience that trickle into existing operatings systems. Either way, everyone benefits.
Except that GNU was started for software freedom years before the open source movement existed. GNU was not about pushing anything "open source". Making a fork of GNU into a proprietary OS would definately not be considered any kind of advantage because such a program would deny software freedom to its users. Nor is the focus of the free software movement an issue of perfecting a development model aimed at rallying unpaid labor to work on one's program.
I suggest learning more about the difference between software freedom and what the open source movement is pitching.
Digital Citizen
Linux is slowly moving that direction, in a natural-selection sort of way. Initramfs and klibc ("early userspace") will allow things like root-on-nfs and in-kernel DHCP (which arguably shouldn't have been in the kernel in the first place) to move to userspace, but developers are already beginning to talk about using it to put things like partition table parsing and console terminal support into userspace as well. I'd guess that more people will start to see applications for early userspace once it's "complete" and distributions start using it (initramfs is already in the kernel; it's the anomalous rootfs that shows up in /proc/mounts).
Filesystems and the network stack are never going to move to userspace, though; Linus is dead-set against it, for the same reasons he always has been. If you were completely batshit, you could probably convince FUSE to run from initramfs, and get wholly userspace filesystems that way, but FUSE doesn't support any non-network filesystems, AFAIK.
"That's all I have to say about that" --Forrest Gump
GNU utilities are widely hated. They are frequently bloated, full of incompatabilities, and just plain broken. The only people who I've met that like GNU utilities are people who have:
a) never used anything but linux and windows, so assume this is how things have to be
b) are used to completely useless userland utilities from something terrible like HP-UX
Its not coding style, its code. GNU utils are constantly full of bugs, and they do not mimic the original tools well at all. They are full of incompatable and non-standard extensions. GNU tar can't even handle making correct tar archives for fuck's sake. GNU's not unix, its an inferior work-alike that serves no purpose.
You can try Hurd/L4 right now by burning a bootable CD (iso) using the Gnuppix.
You can read the interview through its Coral cache or its MirrorDot cache . There is also a Google cache.
There is also a MirrorDot-cached PDF version of the interview that can be downloaded by clicking here.
Thanks
having adminned variously HP-UX, AIX, Irix, and Solaris boxes, one of the first things I did on a machine was install the gnu toolset. The proprietary stuff was years behind (Solaris was probably the worst) and getting almost anything modern to compile with them was a real bitch.
VM is really a hypervisor, or "virtual machine monitor". The abstraction it offers to the application looks like the bare machine. So you have to run another OS under VM to get useful services.
The PC analog of VM is VMware. VMware is much bigger and uglier than VM because x86 hardware doesn't virtualize properly, and horrible hacks, including code scanning and patching, have to be employed to make VMware work at all. IBM mainframe hardware has "channels", which support protected-mode I/O. So drivers in user space work quite well.
QNX is a widely used embedded operating system. It's most commonly run on small machines like the ARM, but it works quite nicely on x86. You can run QNX on a desktop; it runs Firefox and all the GNU command-line tools.
QNX got interprocess communication right. Most academic microkernels, including Mach and L4, get it wrong. The key concept can be summed up in one phrase - "What you want is a subroutine call. What the OS usually gives you is an I/O operation". QNX has an interprocess communication primitive, "MsgSend", which works like a subroutine call - you pass a structure in, wait for the other process to respond, and you get another structure back. This makes interprocess communication not only convenient, but fast.
The performance advantage comes because a single call does the necessary send, block, and call other process operations. But the issue isn't overhead. It's CPU scheduling. If the receiving process is waiting (blocked at a "MsgReceive"), control transfers immediately to the receiving process. There's no ambiguity over whether the message is complete, as there is with pipe/socket type IPC. There's no trip through the scheduler looking for a process to run. And, most important, there's no loss of scheduling quantum.
This last is subtle, but crucial. It's why interprocess communication on UNIX, Linux, etc. loses responsiveness on heavily loaded systems. The basic trouble with one-way IPC mechanisms, which include those of System V and Mach, is that sending creates an ambiguity about who runs next.
When you send a System V type IPC message (which is what Linux offers), the sender keeps on running and the receiving process is unblocked. Shortly thereafter, the sending process usually does an IPC receive to get a reply back, and finally blocks. This seems reasonable enough. But it kills performance, because it leads to bad scheduling decisions.
The problem is that the sending process keeps going after the send, and runs until it blocks. At this point, the kernel has to take a trip through the scheduler to find which thread to run next. If you're in a compute-bound situation, and there are several ready threads, one of them starts up. Probably not the one that just received a message, because it's just become ready to run and isn't at the head of the queue yet. So each IPC causes the process to lose its turn and go to the back of the queue. So each interprocess operation carries a big latency penalty.
This is the source of the usual observation that "IPC under Linux is slow". It's not that the implementation is slow, it's that the ill-chosen primitives have terrible scheduling properties. This is an absolutely crucial decision in the design of a microkernel. If it's botched, the design never recovers. Mach botched it, and was never able to fix it. L4 isn't that great in this department, either.
Sockets and pipes are even worse, because you not only have the scheduling problem, you have the problem of determining when a message is complete and it's time to transfer control. The best the kernel can do is guess.
QNX is a good system technically. The main problem with QNX, from the small user perspective, is the company's marketing operation, which is dominated by inside sales people who want to cut big
I'm a little irritated with all the naysayers.
Linux hit a point of diminishing returns about 2 years ago. While it is a decent kernel, there is definitely an increasing need for something like HURD.
It is not a waste of time if it means I never have to press a power button because kswapd crashed again.
It makes me smile that the next big step for the hurd seems will be a move away from a (technically inferior) GPL'ed microkernel (GNU Mach) to a BSD Licenced one (L4Ka Pistachio), but to see the 2 greatest visions of free (BSD freedom and GPL freedom); which have occasionally been perceived as 2 completely seperate camps software feeding one another in this way is quite a lovely thing to behold. Don't know how RMS takes the the hurd's steps away from GNU Mach or GPLed OSKit Mach though - it might mean that the final brick of GNU performs significantly better when running on a BSD Licenced brick than on the equivalent GPL'ed brick :-)
Try NetBSD... safe,straightforward,useful.
As things stand now, even if Hurd were magically ready to go today, I would not write software for it because I would be restricted to the GPL. I don't mind the GPL, but I do mind the restriction.
Hurd, huh? Hey, how's that project going, anyway?
#DeleteChrome
There's a spectrum of issues in the computing world, that range from computer science, which involves doing things where you don't know what the algorithms are to do what you want and have to invent them, to software engineering, which is building something which is extremely well known and understood.
Open source projects are on the whole better, or at least achieve success more quickly on software engineering problems than computer science problems. Writing a word processor is a software engineering problem. It's not like the concepts are not well understood and well documented all over the place, the trick is just building a solid and reliable instance of it. Because it's such a simple and well known problem you can bring in dozens to hundreds of programmers to work on it and there are few debates about how to do things, it's usually more an issue of prioritizing feature lists and bug fixes.
Linux is a software engineering project in the classic sense. Linus and others have been rebuilding Unix, which is extremely well understood. Everyone more or less understood and agreed on how Unix systems work. It's not a question of how to build a memory management algorithm with acceptable performance, but rather which existing algorithm has the best peformance. In general, Linux tends to spend more time debating between existing solutions than trying to find a solution to a problem. The reason that Linux has come so far so fast is that it's treading on extremely familiar ground and isn't really trying to do anything new from a computer science level.
Hurd is more in the area of computer science. They don't have thirty years of precedence going in their favor. While there has been plenty of work in microkernels, there's far less of work there than for Unix. The Hurd people are trying to make something new, rather than reinvent something that's familiar, which is a much easier task by far. So the fact that the Hurd people are moving more slowly is more an indication of the difficulty of the task.
Now the question is, why work on Hurd at all? Well, the answer to that is the answer to the question of whether or not there are things with a microkernel that you cannot do with a regular kernel, and whether these things are worth doing. It is entirely possible on a security level for Linux to hit a dead end, running into the limits of a monolithic kernel architecture. That if there is to be any progress past a certain point, that a rearchitecture is needed to switch to a microkernel architecture. I'm not saying this is the case, but I am saying that it is not an impossibility.
If that is the case, then Linus and others will need to do a major rearchitecture in a new release, or they need to switch over to an existing microkernel project that they feel is acceptable to them. Even if the Linux people decide to do their own microkernel architecture from scratch in that case, they will almost certainly be going over the entire history and the results of the GNU/Hurd project with a fine tooth comb for data on how to build a viable microkernel operating system.
To say that microkernels are slower than monolithic kernels is on some level unimportant. CPU speeds have slowed down somewhat but we're still improving the speed of systems. The question becomes are you willing to trade a performance hit for security. Would you rather have a fast system that is more vulnerable to nasty software or would you rather have a slower but more secure system? So the Hurd people are focusing on security since that is potentially the greatest strength of microkernels over monolithic kernels.
So look at the Hurd project, like a bunch of other projects as a research project. And yes, it's taking them a heck of a long time to get results but they're not in any particular hurry. It's like Linux versus Windows, Linux doesn't need to "win" next year. It just keeps on chugging and eventually grinds away at the opposition. Hurd just keeps getting better every year and maybe someday it will clearly surpass Linux in a few areas. Probably not anytime soon, but this isn't a race.
So no, Hurd isn't a waste of time. It's a research project and one that may be of significant importance to Linux down the road.
Without device drivers and network code swiped
from Linux, the Hurd would be nothing.
Plus, who do you think does most of the glibc and
gcc development? It's people using and supporting
Linux, generally caring little for the Hurd. The
so-called "GNU" project is built on the back of
Linux, and has been for well over a decade. (and
let's not forget the scraps of BSD code either)
If credit belongs in the name of the OS, then it's
time that GNU stuff be called Linux/Hurd. Better
yet, use "GNU/Linux" to mean that Hurd thing full
of Linux code.
Many of the posts above say Hurd is a waste of time. I suspect the Hurd team just enjoys hacking. I really don't think they care if its a "waste" of time. They just love what they do. I think it's awesome to be so dedicated to your craft. Even if the Hurd never works... I bet they will still look back on the whole experience as something pretty cool.
I agree it's cool, but I think Hurd deservs more credit. I sincerely think that Hurd has a better design, which is why it will eventually be successfull in the real world. Yes I know that there have been lots of better designs out there that never made it beond the lab or a small nitche - but this phenomina is a side effect of proprietary technology, not a natural occurence of design and progression. In the free (not as in beer) world, the technology that is better actually wins out.
I know of no show-stoppers that would prevent anything from working on Hurd that *IS* working on Linux now - even many of the modules. Hurd would simply make it easier to deal with the driver/interface space. Either Hurds main features will eventually make it into Linux (most likely), or the Linux base will eventually come to use Hurd more and more.
Surely the first running programme must have been the screenshot programme?
Atheism is a non-prophet organisation
Hurd/L4 probably won't be ready for release before L4 is considered too old, and so it has to be ported, again, to whatever's current then.
Was the port really more important that actually releasing a finished kernel? How much did that set things back?
Remember then Netscape pissed away their lead over IE by rewriting the project from the ground up?
We apologize for the inconvenience.
In the Hurd, the operating system is implemented as a set of servers, and each runs in its own address space. Of course there are some essential system services which better not crash, or the system will reboot immediately as a last attempt to salvage the situation. But for many other services, a crash is not fatal. If a filesystem server crashes (except for the root filesystem), you can just restart it (or it is restarted automatically by the system). Dead-locks require manual interaction, and you will have to kill the hanging server to remove it from the system and release associated resources.
Unfortunately, Hurd won't save us from hangs. Drivers can hang your machine, period. A good example of that is X.org. It runs in userspace, but touching the wrong register on the graphics card will block your PCI bus. Hurd won't be different - be it in userspace or not, if you touch the wrong register you machine will hang. With no oportunity of doing anything.
We already have userspace filesystems in linux - just check FUSE in the -mm tree, or the userspace drivers infrastructure someone posted a couple of weeks ago in the lkml. If "having everything in userspace" starts having sense (which won't have, at least with today's hardware) I'd rather work in porting linux drivers to userspace (like they already did in 2.6 with libusb) than using a OS like hurd, where developers have started doing something so wrong like letting apps to do their own mm.
Brush up on your Windows architecture--everything is an object to the NT kernel. When you're bored, play with WinObj or the "NT Obj" tab in ReactOS Explorer to see how Windows really looks before the awful Win32 API comes and messes everything up.
RMS had a reason, like it or not, and it got the name out there. Others don't have a reason so I suggest the age old tradition of those who are in control of a project getting to name it continues.
Call it gnu/linux if you want, but for a very long time gnu has had an OS, and they call it hurd. Linux is a seperate project and not run by gnu.
This is a classic logic fallacy in that you pick and choose the factors that support your argument. The PC didn't win because it was more "open." It won because it was cheaper than the $2000+ priced Macintosh, fueled by commodity PC-clones (remember the phrase "PC-compatible"?) that competed with each other and brought prices down each year.
Yeah, my Mach-running OS X desktop is sooooo "incredibly slow." *rolling eyes*
Well, the Hurd contains lots of Linux kernel code. (it is also used with the X11 and BSD stuff that Linus likes to use) Therefore, by RMS's own logic, the Hurd stuff should be called Linux/Hurd.
RMS of course refuses. It's a one-way street with him. He don't mind gaining at the expense of Linux, but won't return the favor.
The Hurd group doesn't seem to have gotten the message on this. They seem to be going more in the direction of building a platform for OS hacking than getting the primitives right and rock-solid. The latter is the key to microkernel work. If the design is botched, it never recovers.
Once you get a microkernel right, it changes very little. Neither QNX nor VM has changed much at the kernel level in years. They don't need to; everything complicated is outside the kernel. New file systems, drivers, graphic systems, and GUIs are all user programs. This is how you get stability.
Why is it so hard for [GNU] to make a kernel?
Perhaps you don't realize the GNU is a project, not a team or person. Some of the most prominent projects were lead and significantly developed by Richard Stallman, but many other projects were developed by others then adopted by the GNU project, which was mutually beneficial to GNU (helps build the complete GNU system) and the project (increases visibility and contributions).
Here's some of the primary authors of projects (as I understand them): GNU Emacs Richard Stallman GNU C Compiler Richard Matthew Stallman GNU C++ Compiler Michael Tiemann/Cygnus Software GNU C Library Cygnus Software/Red Hat Software GNU Less Mark Nudelman GNU Bash Chet Ramey GNU Grub Erich Stefan BoleynThere is not a great deal of overlap between people and projects. People work on a project because they have skills in that area. They are seldom employed or commissioned by the Free Software Foundation or the GNU Project to do so.
You should also note that many "GNU" projects aren't even first-class GNU citizens. They use external infrastructure such as mailing lists and source repositories, and aren't always developed in the open.
As I see it, GNU is a project that provides an enviroment to encourage free software development, not an entity that produces a lot of software itself.
In any case, no matter the ancient history, the past decade of glibc development has been driven by Linux. Ulrich Drepper is even a Red Hat employee. Since the bulk of glibc development is for Linux, this so-called "GNU" or "Hurd" system ought to credit Linux in its name -- assuming you believe "GNU/Linux" is an appropriate name to saddle Linux with.
Mach RPC is built on top of Mach ports, but an RPC call is not a single kernel-level operation. So you have the scheduling problem.
Interestingly, although it's very obscure, the kernel call level below mach_msg_send actually does support a combined send/block/receive operation. As the MIT document points out, this "enables certain internal optimizations".
But when you read the GNU HURD tutorial on Mach IPC, you see the suggestion that a program intended to send an integer to another program and wait for a reply should do two separate operations. Somebody doesn't get this.
Also, for no particularly good reason, Mach usually uses the same buffer for both send and receive, so if you use the combined send/receive form, whatever you send gets clobbered by the reply. So using this tends to involve an extra copy.
Mach IPC is incredibly complicated, You have to fill in many data structures just to send something. The implementation is complicated, too. QNX has a nice, simple primitive:
You can probably figure out how to use that just from the definition. Even the reply value is what you think it should be: the receive count if it worked, -1 if it failed, with an error code in errno.
The name of the game here is getting the primitives right.
I worked at a firm that made payroll and accounting software to various Unix flavours. When I got there, none of our machines even had a network adapter. IIRC we had DEC Ultrix, HPUX8, Solaris, AIX, SCO Xenix, and others. The code was sometimes out of sync from one machine to another, and the fixes and upgrades were rolled from machine to machine via removable storage.
Well, I networked the whole bunch, unified the source in NFS, and started to unify the build toolchain to gcc, autoconf, and others. Why? Because we had a lot of different tools, different makefiles, it was a living hell.
In the end of this project, we had one source tree, with 100x less #ifdefs, and even if our systems got bigger in some archs, they were at least 10x cheaper to maintain. Thanks to GNU.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
And I quote: "This is a classic logic fallacy in that you pick and choose the factors that support your argument."
How is the IPC scheme under L4? Why isn't it comparable to QNXs?
Aren't the problems you mentioned just fixable in the scheduler?
Isn't it enough to boost the priority in the queue for recently-activated threads and to un-boost the prio for threads that recently activated other threads? The former are likely to receive CPU time soon, and the latter are likely to relinquish CPU soon, anyway?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
But practically speaking, monolithic kernels are still the best choice because performance is valued more than elegance.
Some of us think Linux is already pretty far along the path to microkernel-hood.
i will certainly concede that various vendors have, at various times, left their own OSs in a pretty poor state. i've been particularly frustrated with HP-UX and AIX, but specifics aside, your point stands.
this does not, however, mean the GNU stuff is scientifically interesting. the fact that they've managed to copy the better portions of existing Unix tools, rather than the more archaic portions, does not make them innovative. and having admin'd more Unix flavors and derivatives than i care to list or anyone cares to read, the most consistently frustrating parts of getting things to work in a portable fashion is the hackish approach to portability popularized by GNU (witness autoconf/configure), non-standard extensions to existing languages and utilities (gmake, gawk, gcc's C extensions), and errors in gcc, particularly in the optimizations.
i speak for myself and those who like what i say.
> The variety of different groups of
> people here is enough that you should
> be able to find some element that you
> like.
But vast numbers of people don't tend to distinguish themselves. They tend to homogenise, and then ATTEMPT to distinguish themselves (largely unsuccessfully). While every Linux user group is, indeed, different... they all LOOK the same from the outside. This makes it very difficult to figure out which one is going to have the smart and friendly people who can help you with your problems, and which one is the local chapter of the open source thumb-up-ass brigade.
> it's impossible to generalize
> about the entire group
It's impossible NOT to generalise. How can you productively discuss the community of Linux users without generalities? There are too many of us, as you've just pointed out yourself.
Microsoft cheerleader, blue flag waving, you got a problem with that?
Just because you don't understand what anothy said doesn't give you a reason to mod Flamebait. I metamod you unfair.