If 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 translators
GNU 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 pieces
Potential 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.
Comments (41 posted)
Brief items
There is no precedent for requiring Debian packages to avoid trademark
infringement as a condition of inclusion in the archive. I am very much
opposed to anything that would require Debian to remove potentially
trademark infringing logos from packages "until we have agreement with the
trademark owners". This is entirely the wrong way around - we should always
assume that our use is permitted wrt trademark law unless either a) a court
ruling determines otherwise, or b) we decide it's not in our interest to
fight a lawsuit over the matter and as a project decide to stop using the
mark. In no event should the ftpmasters be preemptively deciding that such
works should be excluded from the archive pending an agreement unless so
directed by Debian's counsel in the course of litigation.
--
Steve Langasek
Well, while we're putting stakes in the ground, I suppose I'll hammer mine
in there as well. I completely disagree to the point that I would take
that to a GR.
--
Russ Allbery (on systemd in Debian)
If we lag behind in features that are good for GNU/Linux users (who are
the vast majority of our users) just because users of some ports can't
have them, we might force users to choose other distros, renouncing to
some of the unique features that Debian has to offer (freedom, quality,
open development, etc.). This of course goes both way: we should not
hold back non-Linux features on non-Linux kernels because the Linux
kernel lack them. Adopting that as a general principle would mean
offering, overall, the intersection of features available in all our
ports, something which is doomed to reduce with the growth of the number
of ports.
--
Stefano Zacchiroli
I'm not denying that change has no cost. But upkeep has a cost as
well. Just because my father-in-law can keep his 40+ year old snow
blower operationally tweaking it doesn't mean its the most valuable
use of his time compared to buying a newer one and learning how to
maintain the newer design. Then again his stated mission in life
isn't to innovate snow blower design and be on the cutting edge of
snow removal.
--
Jeff Spaleta (on systemd in Fedora)
Comments (3 posted)
The next Ubuntu Developer Summit (UDS) will be held October 31-November 4,
2011 in Orlando, Florida.
UDS is
where Ubuntu developers share ideas and plans for the next version of
Ubuntu (in this case v12.04). There are a limited number of sponsorships
available, and applications are open until August 24.
Full Story (comments: none)
The
LTIB project is an RPM based build
system that can be used to develop and deploy BSPs (Board Support Packages)
for a number of embedded target platforms including PowerPC, ARM,
Coldfire. The project is
hosted at
savannah.org. (Thanks to Rick Foos)
Comments (none posted)
Remember
Plan 9, the distributed
research operating system developed at Bell Labs?
9Front is a community driven fork of
Plan 9. The project has a
home page at Google code.
Some
new
features include a newer (more reliable) boot loader, an improved cwfs
as the default file system, support for the Go programming language, and
much more. (Thanks to Stein Gjoen)
Comments (none posted)
Distribution News
Mandriva Linux
The Mandriva board has
decided
to extend full support for Mandriva 2010.1 and Mandriva 2010.2
distributions for additional 6 months.
Comments (none posted)
Other distributions
The
Mageia community has been
discussing
the project's release cycle. "
The outcome of our discussions: the
release cycle for Mageia will be 9 months. We think it's a well-balanced
choice, providing an up-to-date distribution that's also stable. It should
also give us enough time to build the specifications, develop, package,
innovate and finalize it. Each Mageia release will be supported for 18
months." The project is also thinking about a Long Term Support
release every 18 months that will be supported for 3 years.
Comments (none posted)
Newsletters and articles of interest
Comments (none posted)
The
ninth
installment in the "systemd for administrators" series is actually a
lengthy discussion on why Lennart thinks that distributions should get rid
of the
/etc/sysconfig or
/etc/default directories.
"
They are inherently distribution-specific. With systemd we hope to
encourage standardization between distributions. Part of this is that we
want that unit files are supplied with upstream, and not just added by the
packager -- how it has usually been done in the SysV world. Since the
location of the directory and the available variables in the files is very
different on each distribution, supporting /etc/sysconfig files in upstream
unit files is not feasible. Configuration stored in these files works
against de-balkanization of the Linux platform."
Comments (34 posted)
Michael Reed
takes a
look at aptosid with KDE4. "
[aptosid] works well, and
subjectively, it feels a bit faster than Kubuntu 11.04. Thanks to extensive
documentation on the website, the low level customizations and the freaky
artwork, this is more than a mere respin of Debian. The adherence to
Debian's take on what constitutes truly free software will be either an
attractive feature or something that has to be worked around, depending on your belief system."
Comments (none posted)
Page editor: Rebecca Sobol
Next page: Development>>