Weekly Edition
Return to the Distributions page
| |||||||||||||
Signs of life from GNU HurdIf all goes well, Debian might be adding another port for 7.0 ("Wheezy"): GNU/Hurd. According to the most recent Hurd news, there's now "a real plan to release a Hurd variant" of Debian with Wheezy. It's not a definite, but the Hurd team is buckling down and trying to get Hurd into shape. Samuel Thibault has created Debian GNU/Hurd CDs with a GUI installer for those who are interested. There's also work going on in the form of a Google Summer of Code (GSoC) project by Jérémie Koenig to improve Java on Hurd by porting OpenJDK, and create low-level Java bindings, which is also helping to improve Hurd for other applications that are being ported to it. One might wonder why there's a renewed interest in Hurd. Linux has now been around for nearly 20 years — an impressive run in terms of longevity, especially considering all of the success that Linux has enjoyed. But Linux might not have happened at all if GNU Hurd had been ready when Linus Torvalds started working on Linux. Despite the fact that Hurd predates Linux, the official kernel for GNU has never really been widely used or enjoyed more than a small fraction of the developer interest of Linux. But in a world where even Duke Nukem Forever is finally completed, it makes sense to keep trying with Hurd, too — if for radically different reasons. Why are people still working on Hurd? I emailed Koenig and the Hurd maintainers list to find out what their motivation is. In a response from the maintainers (Thibault, Arne Babenhauserheide, and Thomas Schwinge), the first reason given is that Hurd provides better support for GNU's Freedom 0 (The freedom to run the program for any purpose) "by giving users and programs as much control over their computing environment as possible." According to the maintainers, Hurd gives users more control over their system thanks to the translator architecture. Understanding GNU Hurd and translatorsGNU Hurd is a set of servers (translators) that run on top of the Mach microkernel. Mach handles fewer things than the Linux kernel — it mostly deals with memory management, inter-process communication, and task switching. In short, say the maintainers, "GNU Mach implements what is necessary to delegate all the rest to specialized and separated user-space translators." Mach also includes device drivers taken from Linux, but most are from the Linux 2.0 series. The maintainers say that a new driver framework is being developed that will allow embedding current drivers from Linux into user-space processes. Once complete, they say that this will reduce GNU Mach to providing only "basic hardware access abstractions, like forwarding IRQ events to the corresponding user-space processes." Why are they called translators? Because they "translate" from one representation of data into another — such as blocks stored on a hard disk into a directory and file hierarchy. The maintainers say that Hurd translators are similar to Linux's FUSE (filesystem in user space), but they do not go through the kernel and have broader applications: It thus looks more like gvfs, except that it's transparent for *all* applications in the system that are using the glibc/POSIX interfaces, including mere shells of course. And this not only applies to file access, the same basic architecture also allows for setting up a VPN connection, for example, and make user-space applications use it without the need for administration rights (for altering the system's routing table, for example), or things like libsocks, since it's already meant to be pluggable from the glibc itself. For some users the modularity of GNU Hurd may be a major advantage. The maintainers say that Hurd's translators provide more powerful features "that users have actually always wanted but never dared ask their administrator." The concepts of Hurd translators are interesting, but right now the list of translators is fairly small and there's little functionality that one wouldn't be able to get on Linux. But functionality isn't everything. There's also the appeal of the challenge of Hurd and learning in the process. The maintainers say that learning and solving problems to get Hurd up and running "are indeed a big part of the current maintainers' motivation." For example, they say it has required getting involved with glibc "which proved to be useful to them in other contexts." Schwinge says that working on Hurd and "exposure and investigation of glibc," helped him to be accepted into CodeSourcery's apprentice program and to land a part-time job with the company while finishing his university studies. Thibault says that work with Hurd helped with his research and to land a position with XenSource. The maintainers say that it's also fun to hack Hurd. "Debugging the TCP/IP stack can be done simply by running GDB on the pfinet translator (which handles the standard socket interface, and translates it to/from Ethernet frames)." They say it's easier to work on a translator for GNU Hurd than working inside the Linux kernel. "A translator can actually contain a complete TCP/IP stack implementation, and just be used as a container to debug and profile it." Finally, for developers who want to have a direct impact, Hurd offers opportunities that Linux doesn't. "There are still some interesting tasks to achieve in the GNU Hurd, while contributing anything but drivers to the Linux kernel has become extremely challenging." Missing piecesPotential aside, GNU/Hurd is still not quite ready for widespread deployment. However, the maintainers say that it's reached the point of being "stable enough to be used day-to-day." Now they say it's time to improve application availability and support, and to provide Hurd to more users and developers by making it a full port of Debian. There's still much to be done before Hurd is even up to par with the Debian GNU/kFreeBSD port, much less Linux. So far, more than half of the packages in the Debian archive (68%) have compiled successfully on Hurd, but many do not. Java, as already noted, is a problem. However, Hurd also fails to build or has problems with git, GNU Emacs, Screen, Wine, PulseAudio, and many others. Koenig's work, if successful, will not only provide Hurd with a Java implementation, but also some system interfaces that are required by OpenJDK but not available yet in Hurd. Koenig says that he's working on bringing Hurd's signal delivery code (in glibc) up to par with respect to POSIX threads. He also says that he's adding features needed for Unix sockets and other features needed by OpenJDK that are not present in Hurd. "OpenJDK is not very friendly from a porter's point of view; there are many places where the code assumes we're either on Solaris, Linux or Windows." There's plenty of room for contributors, too. Koenig says that the Hurd team consists of "about a dozen people with various degrees of involvement," and the maintainers say that they're happy to see new developers. Instructions on getting started are included on the Hurd wiki, and there is even an option of getting shell access to a system running GNU/Hurd already. Note that installing and running Debian GNU/Hurd at this time is for those who are not only adventurous, but also with a great deal of time to kill. Thibault has provided an image with the Debian GUI installer that will install a Debian GNU/Hurd distribution, but it's very slow and is unlikely to work on a large swath of real hardware. The image still uses Linux 2.0-era network drivers, so it's not likely to work on many newer machines. That is being worked on, however. The Hurd folks are working on using Device Driver Environment (DDE) work to reuse current Linux drivers on Hurd. DDE is a universal interface for drivers that is meant to allow using drivers for other systems (like Linux) on systems without a lot of native drivers. Instructions are provided for booting it under KVM, but running the install under KVM takes hours even on a relatively fast system. It took about five hours to run through the installation once, with a minimal package set, on a Core i7 system with 1GB of RAM given over to the virtual machine running Hurd. According to Koenig, this is due to a KVM bug that causes a performance issue for Hurd on recent kernels. Thibault says that he's building an image that will have DMA enabled to work around this KVM PIO performance issue. Once installed, it can be fairly slow — and users may run into problems, though some are possibly due to the distribution being based on Debian Sid than being caused by Hurd. For example, I ran into a number of problems trying to install packages, but it was unclear whether the problems lie with Hurd or with Sid. Is GNU/Hurd going to challenge Linux anytime soon? It doesn't seem likely. But the effort to provide a full-blown port for Debian 7.0 seems to be going well so far. In the process, the folks working on Hurd may continue to uncover bugs and improve software that's common to both systems, and provide an interesting alternative for developers who want to dig deeper into system development. (Log in to post comments)
Signs of life from GNU Hurd Posted Jul 21, 2011 10:32 UTC (Thu) by sthibaul (subscriber, #54477) [Link]
I have updated the image to enable DMA. This is a bit slower than PIO with 2.6.32 host kernels, but avoids the 2.6.39 severe PIO performance regression. The base system installs in less than an hour on my Core2 U7700 with 400MiB memory.
Nice article... but light on technical details Posted Jul 21, 2011 17:10 UTC (Thu) by civodul (subscriber, #58311) [Link]
I find the article light on technical justifications and examples.
For example, the phrase "by giving users and programs as much control over their computing environment as possible" deserves to backed. It can be noted that users can develop and run their own file system, networking stack, and whatnot without (1) requiring root privileges, and (2) compromising or otherwise interfering with the system. Sadly, the conclusion of the article (that GNU/Hurd is for "for developers who want to dig deeper into system development") dismisses this aspect.
Likewise, an illustration of features "that users have actually always wanted but never dared ask their administrator" would have been welcome. It could be mentioned, as an example, that mounting an NFS, FTP, or ISO 9660 file system (or anything else) does not require root privileges.
Overall, I recommend looking at the rationale and examples available at http://hurd.gnu.org/ and in particular http://www.gnu.org/software/hurd/hurd/documentation/trans... and http://www.gnu.org/software/hurd/hurd-paper.html .
Nice article... but light on technical details Posted Jul 21, 2011 18:37 UTC (Thu) by alfille (subscriber, #1631) [Link]
Your references are helpful, but seem very dated. VAX, ftp, Xerox NS are the examples given. One worries that the design hasn't evolved.
The "translators" seem similar to FUSE in allowing user space filesystems. Could you describe the differences?
Nice article... but light on technical details Posted Jul 21, 2011 19:09 UTC (Thu) by sthibaul (subscriber, #54477) [Link]
Translators are not only about files, but also network, user authentication, sound stream, etc. Everything in the system actually.
For instance, on a Linux system, to use a VPN, you need to set up a tap, which is a privileged thing. With translators, since the TCP/IP stack itself is not hardwired in the kernel but translated, you can start your own stack as a translator, using a UDP stream via the main TCP/IP stack to send packets to some remote place, and then you can make your application use that translator, thus getting the VPN feature without needing privileges.
Not really a good point... Posted Jul 21, 2011 18:40 UTC (Thu) by khim (subscriber, #9252) [Link] It can be noted that users can develop and run their own file system, networking stack, and whatnot without (1) requiring root privileges, and (2) compromising or otherwise interfering with the system. Practically speaking this is true for Linux as well. Since HURD is pretty much useless as a desktop you need to run it in some kind of VM. If you run Linux in VM you can develop your own filesystem, networking stack or whateever without affecting host system. Sure, this is huge theoretical advantage... and it remains theoretical for the last 20 years. Rule of thumb says it'll become practical advanatage in another 20 years... well, maybe. If anyone will still care by then. Overall, I recommend looking at the rationale and examples available at http://hurd.gnu.org/ and in particular http://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html and http://www.gnu.org/software/hurd/hurd-paper.html . This talks mostly about state of your desktop in year 2030. This article about situation here and now...
Not really a good point... Posted Jul 21, 2011 19:38 UTC (Thu) by civodul (subscriber, #58311) [Link]
Well, "here and now", GNU/Hurd allows users to extend the system at run-time, without root privileges. "Extending" means users can launch their own instance of any subsystem, be it a file system, networking stack, console, authentication service, or a complete sub-Hurd.
Not really a good point... Posted Jul 21, 2011 19:45 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
and there's no security risk with any user setting up a new network stack for the OS
sure.
there are reasons that the administrators on systems don't let everyone on a system do all these things.
but if you want to do those things, don't argue with the administrators, just run your own machine (and if your response is that your company won't let you, then you probably shouldn't be doing it anyway, it's the companies network, not yours)
Not really a good point... Posted Jul 21, 2011 19:59 UTC (Thu) by sthibaul (subscriber, #54477) [Link]
One important point was completely missed: it's not centralized like on usual systems. The user can't impose the use of his own TCP/IP stack to all the other users. It's when you start a process that you decide which stack your process should use.
Also, even if you have your own machine, using translators permits to run the VPN client as non-root.
You can do the same with Linux Posted Jul 21, 2011 20:28 UTC (Thu) by khim (subscriber, #9252) [Link] One important point was completely missed: it's not centralized like on usual systems.KVM does not require any root privileges so you can do that too: just run VM with your particular fancy feature and only programs in that VM will be able to use this stack. Also, even if you have your own machine, using translators permits to run the VPN client as non-root. And this is more important then the ability to use USB or Bluetooth handset because... ? Face it: all HURD goodies are only icing on the cake. And currently you don't have a cake. I mean: you don't have a system which can actually be used by real users on real (=buyable as new) hardware. May be eventually HARD will reach this state, who knows. But I, for one, don't hold my breath.
You can do the same with Linux Posted Jul 21, 2011 20:47 UTC (Thu) by sthibaul (subscriber, #54477) [Link]
Sure, you can kill a flee with a hammer, but beware of the damage on the desk.
Using KVM will imply having to set up ways to move data between the host and the guest, because it's an all or nothing virtualization layer. Citrix made a good job at providing such things over their remote desktop layers to get e.g. seamless copy/paste, but it becomes more and more complex.
While with translators you can choose to virtualize only the network, and not files, or vice-versa, etc.
Hardware support outside disk/network is quite a bit left behind, yes, because it's important to have something interesting to do with it before supporting it, and support can be handled through driver glue layer.
Now, yes, there is utopia in the Hurd project. So what? As mentioned in the article, working on it helped us quite a bit with other, non-utopia things. Working on a utopia project can thus still be a win. And if the utopia can actually get true, all the best.
You can do the same with Linux Posted Jul 22, 2011 4:28 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
What is the performance impact of using Mach instead of L4 ? Why the project "Hurd on L4" was cancelled ?
Once again: icing is pointless without the cake... Posted Jul 23, 2011 13:19 UTC (Sat) by khim (subscriber, #9252) [Link] While with translators you can choose to virtualize only the network, and not files, or vice-versa, etc. Once again. Sure, you have great icing for your cake. But you don't have a cake! For example: Also, even if you have your own machine, using translators permits to run the VPN client as non-root. This supergreat! Why just why will I want to run the VPN client as non-root? Just "to be cool"? Nope, I will probably want to run some kind of program. In my case it's Ekiga and P4. Both of them work with Linux and don't work with HURD (even if Ekiga can be compiled under HURD it's useless since HURD does not support my webcam). Also note that in my case VPN uses TPM encription which is not supported on HURD. Hardware support outside disk/network is quite a bit left behind, yes, because it's important to have something interesting to do with it before supporting it, and support can be handled through driver glue layer. So even if theoretically I can easily use all these fancy translators practically they only exist to do fancy experiments. In some virtualized system. KVM or something like this... And since I need to install KVM to do play with system development anyway... why not play with Linux instead?
Once again: icing is pointless without the cake... Posted Jul 29, 2011 5:32 UTC (Fri) by Kissaki (subscriber, #61848) [Link]
It sounds to me like you're comparing this apple to an orange. Hurd has some architectural differences that have little practical impact in the current implementation, but bode well for the future.
If you want to use Hurd as a system from which to video chat with your friends tomorrow, well, that might be a challenge. Maybe you should use Linux instead. If you are interested in seeing what the Hurd concepts are about or might bring down the road, you might want to play in this sandbox.
As for why you would want to run a VPN client as other than root, I hope you're kidding. Two trivial answers occur off the top of my head. The first one is that a non-root VPN client means VPN client bugs don't automatically threaten system-compromise. The other is that as a normal user I can take advantage of VPN technology without having to bug the sysadmin and get him or her involved in the key exchange.
For me, the security implications and practical benefits of the differences are exciting. In my mind Hurd is a nice step towards capability based security (instead of ACL based). I hope my theory bears out, but even if it doesn't the modularity is much closer to the unix philosophy as I learned it (small tools that do one thing well) than the monolithic kernel could ever be.
Once again: icing is pointless without the cake... Posted Aug 1, 2011 14:10 UTC (Mon) by nix (subscriber, #2304) [Link]
The third reason is that different people on the same machine can then run *different VPNs*. There's no hope of doing that on Linux as it stands, even with the global routing table, because the per-user iptables rules run in POSTROUTING so cannot affect packet destinations. But having to change the global routing table for something completely per-user and not security-related is a kludge anyway. A userspace TCP stack is definitely the right way here. (Sure, it may not be so high performance, but if you're using a VPN performance isn't going to be at the top of your list anyway.)
Fine-grain virtualization Posted Jul 22, 2011 13:15 UTC (Fri) by civodul (subscriber, #58311) [Link]
You are right that a full virtualization technique like KVM makes it possible to run a customized networking stack, file system, etc. without being root.
Virtualization is the key, but the main difference is granularity.
Each Hurd subsystem is virtualized, meaning that as long as you implement the subsystem's interface, you can replace the default subsystem instance. Compare this with running a complete GNU/Linux system in QEMU/KVM with its own file system image, etc.
The Hurd's approach allows for selected sharing. Just because process A uses a different networking stack than process B doesn't prevent it from accessing the very same files, communicating with B over a pipe, mapping pages from B's address space into its own, etc. Conversely, sharing among full-blown GNU/Linux VMs is much harder.
Fine-grain virtualization Posted Jul 23, 2011 13:31 UTC (Sat) by khim (subscriber, #9252) [Link] Each Hurd subsystem is virtualized, meaning that as long as you implement the subsystem's interface, you can replace the default subsystem instance. This is the sales pitch I've first hard about 20 years ago - before I've heard about Linux, in fact. Compare this with running a complete GNU/Linux system in QEMU/KVM with its own file system image, etc. Huh? You mean HURD does not need it's own "QEMU/KVM with its own file system image, etc"? News to me. Last time I've checked the only way to use it was to run it in QEMU/KVM because support for contemporary hardware was nonexistent and support for real world programs was abysmal. Conversely, sharing among full-blown GNU/Linux VMs is much harder. Sure, but sharing between Linux/MacOS/Windows and HURD is even harder - and this is the only actually available mode today. If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have: 1 is hard requirement for desktop, 2 is hard requirement for server (a lot of hostings nowadays use KVM anyway so hardware support is not as important but since you need to pay for the privilege each month... you need some substantial benefits to even contemplate the switch).
Fine-grain virtualization Posted Jul 23, 2011 14:02 UTC (Sat) by jrn (subscriber, #64214) [Link]
> If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have:
Who mentioned wanting that? (Note that there are other ways than programming to help develop, of course, like contributing documentation or reporting bugs.)
This is what started the whole discussion... Posted Jul 24, 2011 8:14 UTC (Sun) by khim (subscriber, #9252) [Link] > If you want to push anything to someone other then "developers who want to dig deeper into system development" you must have: Huh? Are you joking? This is what started the whole discussion: Sadly, the conclusion of the article (that GNU/Hurd is for "for developers who want to dig deeper into system development") dismisses this aspect. IMNSHO conclusion is quite correct: HURD is not ready for "normal geeks" (let alone "normal users"). Right now it's only useful for someone who believes in it and wants to help development.
This is what started the whole discussion... Posted Jul 25, 2011 0:05 UTC (Mon) by jrn (subscriber, #64214) [Link]
>> Who mentioned wanting that?
> Huh? Are you joking? This is what started the whole discussion:
No, I wasn't joking. Thanks for explaining.
If you had said "Though that might be its goal, I don't believe the hurd gives users and programs even close to as much control over their computing environment as possible today", I don't think anyone would have disagreed.
Fine-grain virtualization Posted Jul 23, 2011 22:59 UTC (Sat) by sthibaul (subscriber, #54477) [Link]
It seems like you just refuse to admit anything.
Making a point about "baah you need to run in KVM anyway" does not make sense.
*Obviously*, hardware support, right now, is a concern. But really it's a detail, and using it as an argument does not make sense. Yes, a big detail. but it's mostly about plugging existing drivers, is already being worked on, is already working for network boards, is now being integrated, and will probably continue with disks.
You have to start with something. Writing drivers doesn't provide any interesting to code on and talk about. Writing translators does. Writing both at the same time is really not reasonable. Throwing a model just because the implementation lacks some driver does not make sense.
Why it does not make sense? Posted Jul 24, 2011 9:12 UTC (Sun) by khim (subscriber, #9252) [Link] Making a point about "baah you need to run in KVM anyway" does not make sense. Of course is does! Remember the context. You are trying to "sell" HURD to someone other then "developers who want to dig deeper into system development". This means they are not interested in the virtual possibilities. They want to use HURD here and now. And here and now KVM is just as much part of HURD development as it is part of Linux kernel development. Yes, a big detail. But it's mostly about plugging existing drivers, is already being worked on, is already working for network boards, is now being integrated, and will probably continue with disks. It's nice to know it's "already being worked on". When you'll finish it you'll need to fix the programs (because few developers will want to install HURD to do so), then you'll have a case for someone other then "developers who want to dig deeper into system development". Lot's of work - and looks like too few people to do it. Throwing a model just because the implementation lacks some driver does not make sense. Throwing model? Of course not. Throwing the implementation? This makes perfect sense. I think HURD developers forget the main principle of IT: Good Enough (sometimes formulated as Worse is Better). Linux is used everywhere because it's Decide for yourself: do you want to push HURD as real OS (then it competes with FreeBSD, Linux, and Windows - and you need to concentrate on drivers and real applications) or do you want to push it as toy/learning OS (then it competes with Minix, Plan9 - you need to concentrate on documentation and learning courses). HURD enthusiasts often looks as Esperanto enthusiasts: they preach the "bright future" where everyone will use HURD (or Esperanto) and positively refuse to talk about reality (which does not give you real reasons to believe said "bright future" will ever materialize).
Why it does not make sense? Posted Jul 24, 2011 13:15 UTC (Sun) by civodul (subscriber, #58311) [Link]
Hey, funnily I happen to be an Esperanto enthusiast too! :-)
(BTW, sorry I wasn't clear in my initial comment: I didn't mean to say that GNU/Hurd is Ready for the Desktop, obviously, but rather that it's *designed* with user freedom in mind as opposed to being merely a toy for "developers who want to dig deeper into system development".)
Why it does not make sense? Posted Jul 27, 2011 18:03 UTC (Wed) by kingdon (subscriber, #4526) [Link] Mi vidas ke la esperanta vikipedio havas artikolon pri Hurd, ĉe http://eo.wikipedia.org/wiki/Hurd And since google translate doesn't (yet :-)) have esperanto: I see that the esperanto wikipedia has an article on Hurd, at http://eo.wikipedia.org/wiki/Hurd
Why it does not make sense? Posted Jul 24, 2011 16:39 UTC (Sun) by sthibaul (subscriber, #54477) [Link]
> You are trying to "sell" HURD to someone other then "developers who want to dig deeper into system development".
Ooops, no, as civodul explained, there's a misunderstanding here. We are not targeting end users yet. We target at providing more power to end users. And now that Debian GNU/Hurd is quite easy to install, we welcome developers who want to help in that direction.
Also, we don't really aim at replacing Linux. Linux is "good enough", indeed, and does it well. The Hurd simply wants to try to be yet better in some aspects, which we have already explained.
Nice article... but light on technical details Posted Jul 29, 2011 5:23 UTC (Fri) by kevinm (guest, #69913) [Link] Likewise, an illustration of features "that users have actually always wanted but never dared ask their administrator" would have been welcome. It could be mentioned, as an example, that mounting an NFS, FTP, or ISO 9660 file system (or anything else) does not require root privileges. This is great - but unfortunately, it's about 10 years too late. The idea of users having a distinct administrator - large multiuser machines for general purpose computing - is an anachronism. It would have been awesome when I was at university in the 90s if I could have mounted an NFS share under my home directory without root permission. Today, with my own desktop Linux system - it's simply an elegant solution to a problem that I no longer have. It's also worth pointing out that you can get a 99% solution for most of these use cases on todays UNIX-like systems, using system call interposing. Sure, it's a bit crufty - but it works well enough for the few occasions when it's necessary to do something like run your own TCP/IP stack.
Linux is not the only competititor of GNU/Hurd! Posted Jul 28, 2011 9:39 UTC (Thu) by renox (subscriber, #23785) [Link]
I wonder why GNU/Hurd is always only compared to Linux: there are other kernels such as L4, MINIX 3 which are also competitors..
A comparison with these other micro-kernel would be more interesting!
License Posted Jul 28, 2011 21:18 UTC (Thu) by runciter (guest, #75370) [Link]
An important point that has not been mentioned so far is that Hurd is under GPL3+, whereas Linux is stuck with GPL2. While it doesn't make a difference to users, that point alone can be a significant advantage to potential contributors.
License Posted Jul 28, 2011 22:02 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I think most people would agree with you on that statement.
I think that you would find many people disagreeing on which of the two has the advantage however.
License Posted Jul 31, 2011 5:29 UTC (Sun) by slashdot (guest, #22014) [Link]
I doubt that there are many who care whether a project they contribute to (or even less, that they use) is GPL2 or GPL3.
I expect that most people contribute to a project because they find it enjoyable to contribute to that specific project, and their interest in the license is most likely limited to checking that it is a free software and/or open source license.
License Posted Aug 1, 2011 13:08 UTC (Mon) by runciter (guest, #75370) [Link]
I, for one, would never make a significant contribution to a non-copyleft project. And while I don't mind GPL2 that much, when a developer contributes to Linux, he has to bear in mind that he is also contributing to TiVo and other companies like TiVo, which will use his code against the spirit of the license under which it was released by exploiting loopholes in the license. Everything else being equal, I would definitely choose to contribute to a GPL3+ project over a GPL2 project.
Signs of life from GNU Hurd Posted Jul 30, 2011 8:32 UTC (Sat) by bersl2 (subscriber, #34928) [Link]
Wow, somebody in here has some strong feelings against the HURD.
Signs of life from GNU Hurd Posted Jul 31, 2011 5:18 UTC (Sun) by slashdot (guest, #22014) [Link]
There is simply no way the Hurd project as it is now can succeed, because:
1. A lot of work that went into Linux (such as hardware support) would need to be duplicated, and that would require a massive amount of time/funding which just won't be available (because Hurd isn't popular, chicken and egg issue)
2. A monolithic kernel like Linux will always be better for the common use cases due to superior performance (and currently much more features), while Hurd's advantages would perhaps be for use cases that very little people care about (for example, nowadays computers are usually personal, so running something as root is a non-issue)
3. While a microkernel might be easier to develop, or might be easier to make reliable, Linux is already extremely mature and rock-solid, completely negating that advantage
4. You can just ignore the subsystems that Linux provides and plug in your own worse performing but customized ones (e.g. alternative TCP/IP stack in an LD_PRELOAD library), sometimes even in a very clean and standard way (e.g. filesystems using FUSE, block devices with nbd, network with tun/tap)
5. You can use virtualization, containers and several other mechanisms which provide similar "system in a process" features while continuing to use an existing popular and full-featured OS
Overall, the only way the Hurd could turn into something useful is to change it to use (unmodified) Linux instead of Mach/L4/whatever as a "supporting microkernel" and turn the Hurd into a set of Linux system daemons providing ad-hoc IPC interfaces (like the existing dbus, systemd, PolicyKit, ConsoleKit, etc.) and into FUSE filesystems, assuming that there actually are any useful parts that can be salvaged that way.
Should Linux have any shortcomings (like maybe too slow IPC/message passing, or inability to easily implement some things in userspace), those could be addressed in a generic way and then merged upstream as overall kernel improvements (like FUSE).
Signs of life from GNU Hurd Posted Aug 1, 2011 23:37 UTC (Mon) by sthibaul (subscriber, #54477) [Link]
Such a conclusion shall not be unanswered.
1. The plan is precisely to inherit the Linux hardware support through the DDE layer...
"change it to use (unmodified) Linux instead of Mach/L4/whatever as a "supporting microkernel""
I guess here too you missed the DDE layer plan. That plan being considered, Linux has not much to bring compared to Mach: the IPC interface would have to be completely rewritten. The FUSE part is already in the plan, there is some embryon of code.
"assuming that there actually are any useful parts that can be salvaged that way."
Of course, if you just take Linux, then you have a Linux system and there's no use in doing that :)
Our plan is rather to take bits from Linux, such as drivers & FS implementations, and integrate them in the Hurd landscape.
I'd like to repeat again: we don't plan to replace Linux. I guess there might be some difference in what one can mean by "succeed".
Signs of life from GNU Hurd Posted Aug 2, 2011 4:37 UTC (Tue) by viro (subscriber, #7872) [Link]
Umm... You'd better be damn careful about the licensing - taking Linux fs code and putting it under GPLv3+ would be a license violation. Additional restrictions and all such... There is some code in there that happens to be v2+, but default license is v2-only and *that* is not convertible to v3+. Moreover, any changes done to v2+ code converted into v3+ one will be yours to maintain. Indefinitely. They simply can't be folded back into mainline, not without creating a kernel impossible to distribute...
Signs of life from GNU Hurd Posted Aug 9, 2011 18:56 UTC (Tue) by sthibaul (subscriber, #54477) [Link]
Oops, I missed that comment.
Yes, there are licence concerns with taking existing code. And that's exactly where the Hurd architecture helps: it doesn't make a kernel of it. It runs it in separate processes in userland. Thus no licence issue at all, you can even have processes running proprietary code.
Signs of life from GNU Hurd Posted Aug 10, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link]
So where exactly in the GPLv2 does it say that it's ok to take GPL licensed code and mix it with incompatibly licensed code if the GPLed code is run as a separate process? I can't find such an exception anywhere. It's a fallacy to think that you can just wash away copyright derivation and license issues by inserting purely technical shims, like IPC (hallo Android and BlueZ), or processes and some custom message passing syscalls.
If you're thinking of the Linux exception that clarifies that the normal Linux syscall interface is generally a boundary for GPL derivation, so that it's 100% clear that userspace processes running on the Linux kernel aren't bound the kernel's licence: that clearly does not apply to the kernel's own code.
Signs of life from GNU Hurd Posted Aug 10, 2011 7:29 UTC (Wed) by viro (subscriber, #7872) [Link]
That depends... One could, e.g. take fs code and write a userland implementation of the same fs derived from it, speaking 9P or e.g. FUSE. Derived as in "uses block allocator functions copied verbatim from the original". Leaving it under GPLv2, of course. Now, 9P is network-transparent. You've got yourself a server for a network filesystem, Linux boxen can connect to it and mount the sucker. *Can* we use the license to prohibit e.g. Plan 9 clients from connecting to such server? I seriously suspect that it would qualify as additional restriction (not to mention being utterly obnoxious).
Depends on the nature of API they are exposing... Hell, nevermind 9P; suppose somebody implements userland nfsd using block device and using something like libe2fs for fs access. Put that sucker under GPL; are you seriously claiming that mounting from such server makes your nfs client a derivative? Or that one is not allowed to use any kind of GPLed code in such a project?
Signs of life from GNU Hurd Posted Aug 10, 2011 9:00 UTC (Wed) by paulj (subscriber, #341) [Link]
To be clear, I'm making the point that technical tricks, like moving code to separate processes, does not of itself change the licensing situation. I'm replying to the implication in sthibaul's comment (an implication he may not have intended) that the Hurd's micro-kernel + user-space server architecture inherently provides some kind of license-washing function.
What exactly the licensing implications are of taking Linux fses, wrapping them in user-space daemon code and having them talk to some general FS-namespace muxing daemon in a micro-kernel, such that it effectively depended on that Linux fs code, I couldn't quite say. Your word would carry some weight on that issue though.
Signs of life from GNU Hurd Posted Aug 10, 2011 10:59 UTC (Wed) by nix (subscriber, #2304) [Link]
It is plain that in such a situation, the client code could *not* be considered a derived work: it might not have changed while the GPL serverside code was written. (Also, GPL NFS servers and non-GPL clients talk to each other every day without legal issue.)
Since the server and client code are not even necessarily running on the same machine, you probably couldn't use the reasoning that the combinaton of both linked together is a derived work of the GPLed part, because there *is* no such version.
(but IANAL and even if I were an L I'd be a UK L in any case. So my blatherings are doubly irrelevant.)
Signs of life from GNU Hurd Posted Aug 2, 2011 11:51 UTC (Tue) by slashdot (guest, #22014) [Link]
It seems to me it would be MUCH simpler and better to either implement the Mach IPC interface in userspace in terms of POSIX, or as a Linux kernel module, rather than somehow attempting to run Linux drivers in Mach or some other microkernel.
Fundamentally, the Linux driver interface is enornomous, constantly changing, and partially documented, while I guess the Mach or L4 IPCs API are much smaller and well-defined.
Also, the "DDE" layer page only mentions block, network, USB and sound drivers, while of course a useful system needs at least 3D acceleration as well, plus a lot of miscellaneous stuff.
Not to mention that non-driver parts of Linux like the scheduler, MM subsystem, etc. have been extensively worked upon to be fast, reliable and scalable to SMP systems, and I don't see how anything else could possibly compare to that.
If the plan is to do MM and scheduler in userspace, then that's probably not going to be of any real use other than as a toy, and anyone using whatever new feature the Hurd provides will want to do that in conjunction with at least the Linux kernel-mode scheduler and MM so that things will work at decent performance and scale properly to SMP systems.
And of course, that way Linux users would be able to just run the Hurd easily along with existing other software.
Again, this assumes that once you get rid of everything that Linux already does (and where there's no chance at all that an userspace solution with much less developers can compete), there will be something left in the Hurd, which I'm not sure whether it's the case.
Oh, and for the record, a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system, while having the same isolation and better security (no buffer overflows, ever!) than the latter, so the whole concept of a C-based microkernel-based system might be in fact totally obsolete.
(yeah, this is kind of a trollish comment, but I believe it reflects reality)
Signs of life from GNU Hurd Posted Aug 3, 2011 7:19 UTC (Wed) by sthibaul (subscriber, #54477) [Link]
Let's answer to the troll then.
"I don't see how anything else could possibly compare to that."
"work at decent performance and scale properly to SMP systems."
Again, we don't want to replace Linux. And yes, you can have decent performance and scale properly on SMP systems without comparing to Linux, i.e. not on 1000-core machines & such. BSD kernels achieve it well for their use for instance, and there are much less companies etc. than on Linux.
"there's no chance at all that an userspace solution with much less developers can compete"
Again, we don't want to replace Linux. There's no way we can achieve the same speed etc. So what? That's not the point. The fact is that even with much less developers, we actually got to the point that the Hurd works, has 68% Debian coverage with its nice installer and the nice translator feature.
"a monolithic kernel using a managed but compiled language like Java/C# is probably much faster than a multiprocess userspace microkernel system while having the same isolation and better security (no buffer overflows, ever!)"
No buffer overflows, right. That alone does not bring full security. Yes, there are other ways to do it. Now, please bring us the code. GNU/Hurd _has_ working code _now_.
|
|||||||||||||