The purpose of this page is to demonstrate that hurd-i386 meets the archive criteria.
Requirements for architectures
Is port cursed?
Are machines available to general public?
The architecture is publicly available without NDAs via:
Is full source available?
Source of the whole port is available. Almost all of the packages use the same sources as the official Debian ports. A few packages that need to be patched are in a separate repository called unreleased until Debian maintainer merge the patch. Sources of those packages are also available.
Is this architecture related to other architectures already in the archive, or that also should be considered, either now or in the future? Can the related architectures be supported in a single architecture (eg, with a biarch arrangement)?
Are there 3 or more developers (or n-ms) actively maintaining the port? Who are they?
The port is maintained by the following developers, who are familiar with arch-specific issues for this port:
MichaelBanck (Debian Developer)
SamuelThibault (Debian Developer)
?EmilioPozueloMonfort (Debian Developer)
PinoToscano (Debian Developer)
What sort of architecture is this? Desktop/workstation? Mainframe/supercomputer? Embedded? Something else?
General purpose, though targetted at desktop/workstation users for the time being.
Concerns have been raised in the past that the port doesn't support basic security features such as kernel level firewalling. Please address. -- firstname.lastname@example.org
There is indeed no kernel level firewalling at this time. -- email@example.com
Access to different hardware could be restricted via a translator which would act as a permission validator (imagine a "no USB sticks" policy in an industrial environment) -- firstname.lastname@example.org.
Update: There is now firewalling support, through stateless BFD input/output rules.
Does it have any users? If a desktop system, are there Debian admins who run Debian systems on the arch? If an embedded system are there real systems shipping that a Debian port will be useful for? If a mainframe system are there real systems with many users that a Debian port will be useful for? Who are they?
As of 2005/01/10:
The port is being actively used at the following sites:
The following lists of users are available:
buildd.net numbers are anonymous and not independently verifiable -- email@example.com
oh, come on! you haven't contacted me to get the user list! Instead you're complaining that buildd.net is non-free. I think what's good enough for the ReleaseTeam should also be valid for the archqualifacation... Maybe you want database access to buildd.net soon? anyway, email with hurd-i386 users sent to firstname.lastname@example.org -- email@example.com
Is there kernel and toolchain support? At what level? Are the latest versions supported, or are legacy releases required for compatability with some hardware? as the ABI stabalised, or are there major ABI changes coming up? Is the ABI stable enough to ensure users will be able just apt-get dist-upgrade from one version to the next?
The GNU Mach microkernel is supported in upstream by the GNU/Hurd maintainers.
The GNU Hurd is supported upstream by the GNU/Hurd maintainers.
The GNU libc is maintained upstream by Roland ?McGrath and others.
GCC is supported out of the box in upstream for the i386 part. We are maintaining the GNU/Hurd part, it only consists of a few files in the gcc/config/ directory.
binutils is supported out of the box in upstream for the i386 part. We are maintaining the GNU/Hurd part, it only consists of a few cases in the various scripts.
Libtool supported out of the box in upstream.
Bug#46709 was a critical security flaw in the kernel that took years to fix; why is it unreasonable to expect similar problems, and similar timeframes for fixes in future? -- ajt@.d.o
It just took years before someone actually took the time to work on a patch. A bug is not a security risk until the software is used where that matters -- firstname.lastname@example.org
One point is that hurd and gnumach package maintenance has moved to not wait for upstream to commit fixes for bugs, but rather include available patches when they seem fine (as has been the case for #46709, once a patch got submitted, the bug was fixed in a couple of days while upstream has not reviewed or otherwise commented on it yet) -- email@example.com
Several new people have been given CVS commit access to gnumach recently, which should improve the maintenance and timeliness of fixes for it quite a bit. -- firstname.lastname@example.org
It did. I fixed bugs in gnumach and the Hurd, buildds are very stable now -- email@example.com
How do you install a system? (URL to a HOWTO)
Has a buildd been setup? How much of the archive has been built (count by source package, builds of old versions are fine for this case)?
One buildd (beethoven.theo.chemie.tu-muenchen.de) was running since August 2005, now off. Two more buildds (bach/mozart, Xen instances on callisto.debian.net) are running since March 2008. One more buildd (rossini, Xen instance on hurd.ethz.ch) was running from Sept 2008 to Feb 2013, now off. One more buildd (ironforge, KVM instance on shattrath.sceen.net) is running since Oct 2011.
Currently 78% of the source package have been built.
What hardware is potentially available as a fast buildd?
General i386 hardware, not all is supported by GNU Mach though.
What isn't supported? -- firstname.lastname@example.org
Mostly newer device hardware, GNU Mach's driver support is not on par with Linux'. However, this should not be a practical problem for buildds, as working hardware can be picked, this is rather a problem for end users. The biggest issue is probably that amd64 systems are known to make trouble even in 32bit on GNU Mach. -- email@example.com
Driver support via DDE is also now available. Linux 2.6.32 network drivers are already working, disk drivers are on their way -- firstname.lastname@example.org
AHCI driver for SATA support -- email@example.com
Is there any corporate support of this arch, and the Debian port in particular?
The following companies are providing corporate support for this architecture:
Currently no companies provide corporate support for GNU/Hurd.
Is there an example box developers can login to to see if it works?
Two porting boxes are available: exodar.debian.net and strauss.debian.net. Otherwise, access to a box can easily be arranged for interested developers. More information is available here.
Further requirements for OSes
Are there existing comprehensive free distributions of this OS? If so, why is a Debian distribution useful?
No, this is the only usable GNU/Hurd distribution. Some other distributions exist in planning stage though, Gentoo GNU/Hurd, Bee GNU/Hurd (both are inactive for many months now) and lately the GNU project has resumed work on the GNU system itself, but this has been dormant again for many months now as well. An Arch GNU/Hurd port has seen some activity lately but went dormant too.
What demonstrable benefits does this OS have over existing Debian OSes?
The GNU Hurd was started as a new approach at operating system design and is the GNU project's replacement of a traditional Unix kernel. It follows the GNU philosophy of giving as much power to the user as possible. This is achieved by a multi server design on top of a microkernel, which makes it possible to put a lot of what traditionally resides in the Unix kernel (file systems, network stack, authentication) into user space and thus make them replaceable and extendable by the user. Through various support libraries (libdiskfs, libnetfs, libps, etc.) the development of new system components (translators) is greatly facilitated. Unlike on Unix, UIDs are not an inherent part of a process but instead separate first class objects. They can be obtained from the password server, passed between processes and destroyed. This can be used to support privilege separation and sub-Hurds (similar to User Mode Linux) without assistance from the system administrator.
Does this system have a standard Unix API?
Yes, POSIX is implemented via glibc. Its API differs from the GNU/Linux one in some occasions, e.g. networking is rather modelled around the BSDs, and some system limit macros (PATH_MAX, MAXHOSTNAMELN, MAXPATHLEN) are not defined as no such limits exist.
Of the 55% of build failures, how many are caused by this? Why is it better to leave these undefined and have the programs not even build, than to have compatability definitions? -- firstname.lastname@example.org
The buildd has not been running long enough to have solid data, but a lot of failures are due to missing Build-Depends as well, of course. From the recorded failures, around 15 out of 75 (20%) seem to be due to these macros. Up till now, the policy of the Debian GNU/Hurd port was to rather fix the programs than to deviate from upstream here, this might need reevaluation based on how many packages would be buildable. Also note that "fixing" programs can mean two things, (i) just #defining the macros if they are not or (ii) actually fix the program to not rely on hard system limits, e.g. by allocating memory for path names dynamically. If done right, the latter will result in overall better code, we believe. -- email@example.com
Does the OS support modern glibc and gcc?
What is the license on the kernel and libraries? Is it free? Is it GPL compatible? (Note that if it's not free, building software for it violates the Social Contract; and if it's not GPL compatible, GPL software such as dpkg can't be linked to it)
GPL license for the GNU Hurd and GNU Mach, LGPL license for glibc.
Does the OS build largely without source changes? If so, what proportion of the archive has built?
Yes, see above (around 78%)
Note that implies a majority of the archive does ''not'' build from unmodified sources. -- firstname.lastname@example.org
The above remark by aj is no longer true, more than 50% of the archive are now built. -- email@example.com
A sizeable part of those packages might build fine if their Build-Depends were in place, though this is not quantifiable. -- firstname.lastname@example.org
Once the oss-libsalsa compatibility library gets installed, the number will probably be quite higher, as making the libasound2? dependency optional in all packages is a tedious work that nobody wanted to complete :) . -- email@example.com
Also note that quite a lot of build failures are due to pure linuxisms (e.g. the dvb video interface) which hinder any non-Linux port anyway. -- firstname.lastname@example.org
Also, the GNU/Hurd OS has never really been exposed largely to upstream as Linux and *BSD have been. It is little wonder that upstream uses linuxisms and BSDisms and don't know about Hurdish ways. -- email@example.com