Slashdot Mirror
GNU Hurd 0.7 and GNU Mach 1.6 Released
jones_supa writes: Halloween brought us GNU Hurd 0.7, GNU Mach 1.6, and GNU MIG 1.6. The new Hurd comes with filesystem driver improvements, provides a new rpcscan utility, and the Hurd code has been ported to work with newer versions of GCC and GNU C Library. The Mach microkernel has updates for compiler compatibility, improvements to the lock debugging infrastructure, the kernel now lets non-privileged users write to a small amount of memory, timestamps are now kept relative to boot time, and there are various bugfixes. MIG 1.6 is a small update which improves compatibility with newer dialects of C programming language. Specific details on all of the updates can be found in the full release announcement.
jrepin adds some more details: The GNU Hurd 0.7 improves the node cache for the EXT2 file-system code (ext2fs), improves the native fakeroot tool, provides a new rpcscan utility, and fixes a long-standing synchronization issue with the file-system translators and other components. The GNU Mach 1.6 microkernel also has updates for compiler compatibility, improvements to the lock debugging infrastructure, the kernel now lets non-privileged users write to a small amount of memory, timestamps are now kept relative to boot time, and there are various bug-fixes.
Systemd is ported
Not a troll here.. really.. I followed Hurd in the beginning when i was really interested in the guts of OSs ( even wrote a couple toy ones ), but lost interest when it was moving at sub-snail pace.
Other than pure research, why is the project still going at all? Is there a practical value to the rest of us? Couldn't the efforts be focused somewhere that has a tangible benefit ?
To cause you angst.
Does 0.7 include support for VESA bus?
It provides an alternative to the traditional monolithic UNIX kernel architecture by replacing it with a multiserver microkernel. Hurd is actually pretty interesting and useful project in my opinion. They just need much more developers if they want to actually go to the moon.
Why does the HURD exist?
To prove that the clean design of a micro kernel architecture enables the development of more features than can be achieved with an old-fashioned monolithic kernel, and that these features can be delivered on a faster schedule.
Too late, the desktop doesn't exist anymore.
Achille Talon
Hop!
Don't worry. At the rate they're going, they'll be up to 1.0 by 2030.
I've not tried it for ages, but it was able to run XFree86 back when that was a thing that people cared about. I'd presume that it can run X.org now. Debian/HURD made a release in April, so you can probably just download it and run it (though hardware support is likely to be worse than pretty much any other open source *NIX).
I am TheRaven on Soylent News
A couple of decades too late, but still sort of welcome.
As far as I know, the goals of Hurd are more than just to be a teaching tool, like MINIX is.
That well may be the full answer, but is licensing minutiae a really good reason to develop an entirely parallel kernel?
My Other Computer Is A Data General Nova III.
Don't worry. At the rate they're going, they'll be up to 1.0 by 2030.
Or maybe 2059? Obligatory XKCD.
If it weren't for deadlines, nothing would be late.
Catching up? They are still making improvements to ext2 as their primary filesystem. For most modern use cases XFS or ext4 is being used. For high scalability, btrfs or ZFS is, basically, required.
If I were them I'd push btrfs hard.
My Other Computer Is A Data General Nova III.
Yeah, if you use the pre/installed image it pretty much just works. The window manager is icewm.
Posted from my Hurd VM.
And here's the link for that: https://www.gnu.org/software/h...
>Too late, the desktop doesn't exist anymore.
This may be a joke, but everyone I know that actually does - you know - "work" - uses a desktop or laptop. Not a tablet in sight,
From the release notes:
>> The code has been updated to work with newer versions of the compiler
So.... GNU broke their compiler to the point that it wouldn't compile existing code; and then their other projects need to change their sources to work? Doesn't that seem horribly backwards?
Hurd is billed as being written in "assembly and C", but evidently it wasn't any sort of standardized assembly or C, it was some private variant that only GNU understood, and only GNU could compile. Now that GCC doesn't accept their non-standard code, they had to spend months rewriting everything in standardized form..... bizarre. Great use of the limited resources available.
So a complete failure then? Reminds me of my first job out of college, at a company developing embedded hardware and software for the process industry. For the networking software, they decided to implement OSI network model literally as 6 software layers (counting the application) on top of the physical hardware layer. It performed like total shit. My not-so-humble opinion is that when you try to literally separate an OS into pure micro kernel and services, you are destined to get the same result.
I too wonder if there is any use case where it's a good fit? On the desktop Linux obviously has better hardware and software compatibility, but there's a use case for BSD, a use case (or two) for QNX, etc - is their one for Mach or Hurd? Is it super ultra reliable, or extremely fast because it's so small or ...?
If you're building a firewall machine, you don't care if it can run Gnome or not, and you don't care about video card support . Is there any type of build in which this kernel makes sense?
Yeah, and Linux runs only on 60% of its replacement!
Religion is what happens when nature strikes and groupthink goes wrong.
Won't boot in my Virtualbox VM, not as an image, or the installer. Not on IDE, or SATA (got a hint in one of the newsgroups). Never got past the bootloader.
Religion is what happens when nature strikes and groupthink goes wrong.
According to the release:
This is not a typo. Wiring memory means pinning it in memory so it cannot be paged out. This is potentially important both for security and real-time applications. On the security front, memory containing keys and passwords should be wired to prevent it going to disk. On the real-time front, if you can fit your working set in wired memory, you can be guaranteed you won't suffer a paging fault while you stay within that working set.
In Linux / POSIX systems, this is what mlock accomplishes.
Being able to write to memory, in contrast, isn't particularly noteworthy. You've been able to do that since pretty much the beginning...
Program Intellivision!
I can't tell if you're trying to be humorous.
The rationale given is: "The kernel now keeps timestamps relative to the system boot time. Among other things this fixes bogus uptime readings if the system time is altered."
Presumably, this means the internal timestamps Hurd uses are now all monotonically increasing, regardless of any changes to the system time. Obviously, there's a relationship between the internal timestamp and what POSIX calls time_t (and related such datatypes). As I read it, they've decoupled the notion of system time (ie. something that resembles what you'd read from a clock, representing time and date as humans understand it, and subject to humans or network time daemons messing with that setting) from the internal timestamps it uses for computing the relative passage of time, such as 'uptime', network timeouts, etc.
Program Intellivision!
> uses a desktop or laptop. Not a tablet in sight,
Except when maybe the desktop and/or laptop -is- a tablet. And vice-versa all three ways.
Now I'm all confusaled!...
-> I dislike sigs...
HURD versus Linux is pretty clear; HURD's a microkernel and Linux is not. What makes HURD interesting compared to Genode's L4 kernel? At a glance, they seem to be doing more similar things.
The most impressive seL4 guys already made a proven unhackable drone for the DARPA, with a separate sandboxed insecure application board and all.
Just wait a bit and applicability domain will grow exponentially until we finally get a proven Linux replacement.
They based their system on a microkernel design because it made the proof manageable, but of course as long as it's proven safe anything could be hooked into the kernel, so performance bottlenecks have a road for improvements too.
It's expensive to prove but they say since there's no bug overall development cost was less.
This looks too good to be true, and indeed I find it worrying that I've not heard Google & Co were massively investing?
Well, if not soon, then later
Why would you want to work? Mobile devices are designed for consumption, not creation. Once all devices are mobile, will there be any content to consume?
Here's wikipedia link:
https://en.wikipedia.org/wiki/L4_microkernel_family
In theory, theory and practice are the same; in practice they're different. (Yogi Berra & A. Einstein)
From the article: "Given the lack of modern hardware support for Hurd. the most sane way to try it right now is using Debian GNU/Hurd within a QEMU guest" -- So I would say no.
Because Linus won't use gpl 3, and stallmens dieing dream is for everything to be under the thumb of gpl3
Last time I checked (admittedly, years ago), the problem was that no one works on HURD. I don't know why. I think they had four people working on it sporadically when they did the 0.4 release.
It's not as if the basic concepts won't work, especially with fast machines like we have today. It's not even as if HURD is trying some new, revolutionary design - microkernel architectures have been implemented before (MINIX is a good example here). But for some reason, HURD just doesn't draw in the developers. And while a lot of code from Linux drivers would work in HURD drivers, there would still have to be significant work on each one - and that's assuming the basic infrastructure for what the driver does even exists.
It might be different now. I certainly hope so.
Those who can't do, teach. Those who can't teach either, do tech support.
Yes. Look here. The README file gives instructions for converting the qemu/kvm images to virtualbox images.
It's not updated to the latest, though. Last update was in March of this year.
Those who can't do, teach. Those who can't teach either, do tech support.
The mobile devices all, pretty much, have cameras today. So, yes... There will still be cat videos. Eventually, they'll run on archaic hardware with software that nobody understands any longer, but they'll still host cat videos just fine until they all break, one by one, and nobody has the tools or the knowledge to repair or rebuild them.
Hmm... There's a novel in there, somewhere.
"So long and thanks for all the fish."
They already got DDEkit (basically a "glue" library that allows to build a linux driver for another kernel or user space) from GenodeOS (l4 kernels) and NetBSD rump kernel (also portable drivers) is being ported atm.
Nonsense - it will be here "real soon now"!
I believe that HURD is now GPLv3. GPLv3 is not GPLv2-compatible (it imposes conditions not present in GPLv2) and so you can not link GPLv2 code into a GPLv3 project. Most GPL'd projects include the 'or later versions' clause, but Linux is GPLv2 only, so none of its code can ever end up in GPLv3 projects.
I am TheRaven on Soylent News
it will ship with perl 6