The TCP/IP stack is already taken from Linux, of course without copyright assignments.
The driver situation is a bit different as the Hurd runs in user space, so it does not care about device drivers. Those are all in the underlying microkernel (GNU Mach currently), which has not been written by the FSF in the first place and also uses Linux drivers (though very outdated ones). So Linux code is being used were it makes sense, maybe not taking it to extremes though.
I'm not sure what the "too late" comment means, but I think he takes a shot at some of the ximian folks later on when he suggests a maintainer for the SuSE kernel could be found from somewhere in the Ximian group.
Ouch. I mean, given the bloated (but usable) mess that is Evolution, would you want those guys maintaining your distribution's kernel?
Now imagine if Ubuntu had instead been a group of developers who decided to combine their efforts with the Debian group to improve Debian?
Working with the Debian people can involve more bureacracy and red tape than working with the federal government, and some developers can't stand that.
Note that the Canonical employees working on Ubuntu who are also Debian Developers are in key positions, and it is my belief that they could have changed Debian from within, if they so desired.
Canonical employees are at least (from the top of my head) leading members of the following Debian maintainer teams: dpkg, APT, apache, ssh, xfree86, postfix and GNOME. Having two ftp-masters, the account and keyring manager, a member of the security team and a release manager on the payroll helps as well.
Those people would be in a position to seriously change Debian from within even with some traction from other maintainers, I guess.
However, Ubuntu chose to fork Debian, which is of course their prerogative, and it works out well for them.
There's no indication that the people working on HURD would work on Linux if they couldn't work on HURD.
Actually, Roland McGrath, one of the two main architects of the GNU Hurd, is now working for RedHat and frequently posts patches to linux-kernel, presumingly due to his work on glibc/linux interaction...
Ulrich Drepper is a RedHat employee and only affiliated with the FSF as much as he happens to be the GNU C library maintainer. However, he is known to have quite an anti-FSF stance and accused RMS of trying to steer glibc development according to his agenda before (see the second half of this announcement).
So this is not really the FSF who are taking this stance, but a concerned developer.
You do know that every sub-directory has its own ChangeLog, right? The top-level one merely documents changes to the build system, which are not particularly exciting.
Could anybody explain why the previous implementation was limited to 2GB per file system? 2GB sounds like a limitation of the 32 bit address space.
Indeed, the old implementation jut mmap()'d the whole file system into memory, resulting in the 2GB limit. This would not be the case on 64-bit architectures; however, I am not aware that GNU Mach runs on AMD64 natively with 64 bits.
Actually, the GNU Hurd is no kernel. It rather builds upon a microkernel, which happens to be GNU Mach for the time being (work is underway to port it to the L4 microkernel)
Do you know if I can run any or even most of my regularly scheduled programming on Hurd? I mean: will Ruby, x.org's X11, GNOME, FireFox, apache, emacs, etc, compile and run as expected?
Of course, emacs runs fine. As to the other stuff, I believe Ruby is there as well, as is the current XFree86 Debian package from unstable (we have not tried building X.Org yet). Regarding GNOME, it mostly builds fine but there are some runtime issues which need to be sorted out first, it does not startup correctly right now.
It's all really a lack of manpower, only a couple of people are working on porting packages, at most. So if you want to help, install Debian GNU/Hurd and join the debian-hurd mailing list.
As to non-root users can effectively mount filesystems if they have all the permissions needed, how is that different than GNU/Linux, where I can use the/etc/fstab entries for a/dev/* devices or NFS exported filesystem to allow users to mount/unmount to predetermined mount points at will?
Ah, but how do non-root users modify/etc/fstab? On the Hurd, you can "mount" partitions you have the necessary permissions to at any place in the file system where you could create a directory or touch a file, no need to predetermine anything
Contrary to what I wrote in that post to debian-hurd which got cited for this article, we decided to not do all this patching to have two static ext2fs translators (one supporting big stores larger than 2GB, the default one not) next to each other.
Instead, after some more testing, we decided to fully apply Ognyan Kulev's patch so that every translated ext2 file system will use it. I committed the code to the Debian Hurd package svn repository yesterday and we will probably upload it by the end of this week.
consequently, GNUstep is an 'apt-get install gnustep*' away
No it isn't, because for some obscure reason the Debian GNUStep guys refuse to use gnustep-* as prefix for their applications. They started to package stuff which such specialized names like 'terminal' or 'cdplayer' and of course brought down the wrath of a lot of the other developers on them for polluting the general namespace.
These days, they tend to prefer '*.app' as naming scheme for their packages, which is at least consistent and different (but not very evident for the untrained eye).
There's also a mini-iso for debian-hurd
That's a whole different story (it is no Live-CD, for starters), though Gürkan plays a peripheral role in the Debian Hurd community as well (he has become known lately for seducing what few Hurd hackers are left to play nethack, which, uhm, didn't help productivity:) ). Those Debian Hurd CDs are produced by Philip Charles.
Michael
Re: microkernels the best approach
on
More From Tanenbaum
·
· Score: 2, Informative
If microkernels are the best approach why is gnu/HURD taking so long?
Dunno, what does the one have to do with the other? It's like saying 'If macrokernels are the best approeach, why does Windows suck do much?'
The Hurd is a set of user-space server running on top of a microkernel (currently Mach), together providing the old Unix experience besides other more interesting things.
Really, it's not taking so long because it was a microkernel (it is NOT!), it's just that there's nobody working on it.
What about the versions of packages it depends on?
Incidently, they are reported as well.
What about the version of the compiler used?
Build-Dependencies do not get logged, but if you really need the info, you can usually gather it. Debian uses the same gcc compiler for all packages by default, so you just have to look back when the package got uploaded and check what version of gcc was current back then.
I've done a lot of Debian packaging but never needed this kind of information though.
Eh, you can install Sarge Beta3 (Beta4 will be out in a couple of days) now. It's way better than the old boot-floppies, features hardware-detection and better partitioning, as well as a lot of other features like installing from an USB stick, via WLAN or using LVM. Try it out, it rocks.
GNU won't endorse Debian if the installer mentions the existence of non-free. Therefore, removing it was important for sarge.
GNU won't endore Debian anyway, as long as non-free is distributed via ftp.debian.org. Removing the question whether the non-free component of the archive should be added to the list of APT sources has been removed because the Debian Project Leader asked the base-config maintainer to do so. It has nothing to do with the relation between the Debian and the GNU project.
Keep in mind that those firmwares violate the GPL and not just the Debian Free Software Guidelines. Thus, they cannot even be distributed in non-free, unfortunately.
About 1000 people are part of the Debian project. Admission is based on skills and adherence to the Debian social contract alone, not based on personal preference. If you don't call that a community, I can't help you. I certainly do.
In other words, that binary data could very well be the PREFERRED form of the firmware for everyone but the manufacturer, regardless of one's religious adherence to the GPL.
If the firmware really is the preferred form of modification and is (along with the rest of driver) GPL'd, everything is fine. Of course, this is a bit hard to check, but talking to the vendor might help here.
But keep in mind that we are talking about the preferred form of modification here, from the POV of the vendor.
Slashdot Mirror
The driver situation is a bit different as the Hurd runs in user space, so it does not care about device drivers. Those are all in the underlying microkernel (GNU Mach currently), which has not been written by the FSF in the first place and also uses Linux drivers (though very outdated ones). So Linux code is being used were it makes sense, maybe not taking it to extremes though.
Michael
Ouch. I mean, given the bloated (but usable) mess that is Evolution, would you want those guys maintaining your distribution's kernel?
Maybe he is thinking about the Man instead?
Michael
Of course it is, Sarge has been released for all architectures in parallel. Only exception was amd64, which is not an official architecture (yet)
Michael
Working with the Debian people can involve more bureacracy and red tape than working with the federal government, and some developers can't stand that.
Note that the Canonical employees working on Ubuntu who are also Debian Developers are in key positions, and it is my belief that they could have changed Debian from within, if they so desired.
Canonical employees are at least (from the top of my head) leading members of the following Debian maintainer teams: dpkg, APT, apache, ssh, xfree86, postfix and GNOME. Having two ftp-masters, the account and keyring manager, a member of the security team and a release manager on the payroll helps as well.
Those people would be in a position to seriously change Debian from within even with some traction from other maintainers, I guess.
However, Ubuntu chose to fork Debian, which is of course their prerogative, and it works out well for them.
Michael
Actually, Roland McGrath, one of the two main architects of the GNU Hurd, is now working for RedHat and frequently posts patches to linux-kernel, presumingly due to his work on glibc/linux interaction...
Michael
Ulrich Drepper is a RedHat employee and only affiliated with the FSF as much as he happens to be the GNU C library maintainer. However, he is known to have quite an anti-FSF stance and accused RMS of trying to steer glibc development according to his agenda before (see the second half of this announcement).
So this is not really the FSF who are taking this stance, but a concerned developer.
Michael
It's dead, Jim.
You do know that every sub-directory has its own ChangeLog, right? The top-level one merely documents changes to the build system, which are not particularly exciting.
Michael
Indeed, the old implementation jut mmap()'d the whole file system into memory, resulting in the 2GB limit. This would not be the case on 64-bit architectures; however, I am not aware that GNU Mach runs on AMD64 natively with 64 bits.
Michael
Actually, the GNU Hurd is no kernel. It rather builds upon a microkernel, which happens to be GNU Mach for the time being (work is underway to port it to the L4 microkernel)
Michael
Of course, emacs runs fine. As to the other stuff, I believe Ruby is there as well, as is the current XFree86 Debian package from unstable (we have not tried building X.Org yet). Regarding GNOME, it mostly builds fine but there are some runtime issues which need to be sorted out first, it does not startup correctly right now.
It's all really a lack of manpower, only a couple of people are working on porting packages, at most. So if you want to help, install Debian GNU/Hurd and join the debian-hurd mailing list.
As to non-root users can effectively mount filesystems if they have all the permissions needed, how is that different than GNU/Linux, where I can use the /etc/fstab entries for a /dev/* devices or NFS exported filesystem to allow users to mount/unmount to predetermined mount points at will?
Ah, but how do non-root users modify /etc/fstab? On the Hurd, you can "mount" partitions you have the necessary permissions to at any place in the file system where you could create a directory or touch a file, no need to predetermine anything
Michael
I am called Michael Banck, actually.
but what else do you expect? =)
Michael
Instead, after some more testing, we decided to fully apply Ognyan Kulev's patch so that every translated ext2 file system will use it. I committed the code to the Debian Hurd package svn repository yesterday and we will probably upload it by the end of this week.
Michael
No it isn't, because for some obscure reason the Debian GNUStep guys refuse to use gnustep-* as prefix for their applications. They started to package stuff which such specialized names like 'terminal' or 'cdplayer' and of course brought down the wrath of a lot of the other developers on them for polluting the general namespace.
These days, they tend to prefer '*.app' as naming scheme for their packages, which is at least consistent and different (but not very evident for the untrained eye).
There's also a mini-iso for debian-hurd
That's a whole different story (it is no Live-CD, for starters), though Gürkan plays a peripheral role in the Debian Hurd community as well (he has become known lately for seducing what few Hurd hackers are left to play nethack, which, uhm, didn't help productivity :) ). Those Debian Hurd CDs are produced by Philip Charles.
Michael
Dunno, what does the one have to do with the other? It's like saying 'If macrokernels are the best approeach, why does Windows suck do much?'
The Hurd is a set of user-space server running on top of a microkernel (currently Mach), together providing the old Unix experience besides other more interesting things.
Really, it's not taking so long because it was a microkernel (it is NOT!), it's just that there's nobody working on it.
Michael
Well, nothing that isn't dying.
/me whispers "AMD64".
Michael
Incidently, they are reported as well.
What about the version of the compiler used?
Build-Dependencies do not get logged, but if you really need the info, you can usually gather it. Debian uses the same gcc compiler for all packages by default, so you just have to look back when the package got uploaded and check what version of gcc was current back then.
I've done a lot of Debian packaging but never needed this kind of information though.
Michael
So that means you are not talking about the new debian-installer but rather about the old boot-floppies. Everybody knows that they suck.
Michael
s/did/did not/
Michael
Michael
That's probably because Joey Hess managed to run a Debian GNU/Hurd image via Bochs. See his journals entries here and his installation report here.
Feel free to add support for BSD yourself, Joey is in no way a Hurd guy, he just did happen to have a BSD installation around or does not care.
Michael
Michael
GNU won't endore Debian anyway, as long as non-free is distributed via ftp.debian.org. Removing the question whether the non-free component of the archive should be added to the list of APT sources has been removed because the Debian Project Leader asked the base-config maintainer to do so. It has nothing to do with the relation between the Debian and the GNU project.
Michael
Michael
Michael
If the firmware really is the preferred form of modification and is (along with the rest of driver) GPL'd, everything is fine. Of course, this is a bit hard to check, but talking to the vendor might help here.
But keep in mind that we are talking about the preferred form of modification here, from the POV of the vendor.
Michael