The GNU project was started in 1983 and in 2025 you can finally use a pure GNU operating system. Not that you’d want to but that is some serious perseverance.
Didn’t debian already offer a hurd image many years ago? I could be wrong but i thought i heard (or hurd hah) someone mention it in a video recently. I think it was on old guix video from dt (i decided to try and write a guix config so i was watching some guix content).
Minimal requirements for Linux: Linux Kernal (optional)
Technically it’s the minimal requirements for GNU/Linux.
Chimera Linux. Linux, no GNU.
Now someone’s gotta combine the two and make GNU/Linux without GNU or Linux
Redox OS. No Linux, no GNU.
BTW Guix+Hurd, a fully GNU OS, has been around for quite a while now: https://guix.gnu.org/en/blog/2020/a-hello-world-virtual-machine-running-the-hurd. You can even run it on real hardware: https://guix.gnu.org/blog/2024/hurd-on-thinkpad/
I learned about this via Guix but didn’t notice that. Nice!
Some time ago (one or two years, i am not sure) i had the Hurd running on an old Thinkpad and used it as a daily driver for a couple of months. It…worked. Most of the times.
The thing is: Its a really interesting system that - in a different timeline - would have made up a GREAT operating system if it would have come forward and evolved a lot faster. Even without the lack of a
browserthe bloated VM we nowadays call a browser (you can absolutely run Dillo on it) it just hurts a bit too much to use it for more than resarch / hobbyist / hacking purposes.Could you elaborate? What made it hurt? Was it just unstable? Hurd’s a microkernel, and while þat’s no guarantee of good design or code quality, I’d hope it would be more reliable. Wasn’t it?
In short: The stability is really a problem - at least it was at the time when i tried it out. I don’t know how often something that i worked with just, well, stopped working and the message ‘Computer bought the farm’ appeared. Sometimes a crashing X session dragged the whole system with it into the abyss freezing the whole system and requiering a reset… followed by a lengthy fsck session. And it was slow. I mean, granted, the Thinkpad R60 i used it on isn’t a supercomputer by todays standards, but compared to a Linux system or even OpenBSD it was really, really slow.
I have a high pain tolerance regarding software, i really have… but i had to give up on it after a while.
But now, with this new release… well, i think i will give it another go.
I just rediscovered that i indeed made a little writeup of my first days with the Hurd in my Gopherhole back then, perhaps it gives a bit of the taste what it was when i tried it. Beware, wall of text after the spoiler:
My Phlog post about the Hurd
Oh it HURDs…
I think i have some undiagnosed masochistic tendencies, because i am constantly drawn to ever more esorteric and fringe operating systems and software that will make my life a little bit harder.
The HURD is something that got my attention a long, long time ago, as being this “mysterious next-gen OS that will change everything”. Well, it was the late 90s / early 00s, the CD was still king and dialup was really expensive (at least here in germany). I was already messing around with linux and most of the time i compensated my utter lack of knowledge with determination and pure madness.
It was some holiday back in the very early 00s when i managed to get it installed on my (i think) pentium 133, after spending way too long on our very slow dialup line to download the necessary files from some GNU mirror (and learning later that i burned through a whole lot Deutsche Mark after my parents received the telephone bill)
Well, my adventure back then ended in an booting system but without any recognized keyboard, and without really knowing what i am doing (and in need of that PC for my apprenticeship at that time) i threw the towel after some really long nights without getting anywhere. Beaten and defeated i reinstalled Windows and (i think) Debian Linux again and went on to mess with other things. But somehow (like with some other failed projects) it left a scar that sometimes itches.
Now, fast forward about 20 years, its a very slow day at the office, i have nothing really pressing to do and… right out of the blue a GNU is sneaking into my thoughts. I fired up a browser, skimmed the web about news regarding my white whale and found out (somewhat to my surprise) that Hurd is still in active development (even if its going forward at an glacial pace). So, after having messed around with some fairly exotic systems and (thinking to have) much more experience than my teenage self i thought it is on time to take a ride on this bovine again.
Debian Hurd seemed to me the most viable option, so i went right on, downloaded three DVD images of 2021 vintage while absolutely missing the very-not-missable news about an 2023 version until after i had already downloaded the images and burned them to three disks. Well… one can always update later, right?
So, i grabbed my “spare” Thinkpad T60 out of the cabinet, looked at the HDD to make sure i had nothing there that i needed and started the installation… nothing too exotic there, its debian based after all…
After some time the installation was finished, i rebooted into the new system and… FOXTROTT UNIFORM CHARLY KILO!!! … the keyboard wasn’t working. WHY??? It did work in the installer???
After reading through some sites on the net (and yes, i understand the hardware support is slim, there are only a handfull of developers left etc, etc…) and not wanting to repeat my first encounter with the hurd i thought to myself:
Why not try it on the R60? So, i took the HD from the T60, put it into the R60, started the installation again, just to be sure, then the dreaded moment of the reboot came… AND I HAD A WORKING KEYBOARD. YESSS!
So, now i started exploring this system i had waited about 20 years to get running, the GNU and debian sites give a nice overview what does work in which ways, and after all, its not THAT different from your standard GNU/Linux system.
An interesting concept is that of the “translators”, just to give an short example:
If you run the following in your home directory
%<-----------------------------------------------------
settrans -ac ftp /hurd/ftpfs ftp.gnu.org
%<-----------------------------------------------------
It creates the folder “ftp” wherein you will find the content of ftp.gnu.org. Granted, for anyone who has worked with Plan 9 or has used FUSE this is not THAT of a revelation, but it is nice… making it possible to layer translators (e.g. for accessing an iso on the ftp server) makes it even a bit nicer.
Now i still had only the three DVDs as package sources, so, thinking that it would be the most safe-ish option to first upgrading everything to the 2023 release i followed an article on the debian pages and added the following to my sources.lst (after commenting out the DVDs):
%<-----------------------------------------------------
deb [check-valid-until=no trusted=yes] https://snapshot.debian.org/archive/debian-ports/20230606T000000Z/ sid main
deb [check-valid-until=no trusted=yes] https://snapshot.debian.org/archive/debian-ports/20230606T000000Z/ unreleased main
deb-src [check-valid-until=no trusted=yes] https://snapshot.debian.org/archive/debian/20230606T000000Z/ sid main
%<-----------------------------------------------------
After that i ran an apt update, installed the debian-archive-ports-keyring package, upgraded everything, initiated a reboot while praying to the mighty GNU that it will come up again.
It did. Everything worked fine.
So, now on the 2023 release, i thought that it would be nice not being stuck on this
%<-----------------------------------------------------
deb http://deb.debian.org/debian-ports unstable main
deb-src http://deb.debian.org/debian unstable main deb http://deb.debian.org/debian-ports unreleased main
%<-----------------------------------------------------
And, again, i initiated an update followed by an upgrade.
Aaaand it broke the install. “I am idiot. Shoot me” to quote an romanian friend of mine. Well, back to square one then… now, knowing that it is possible to get a working install, i downloaded the 2023 netinstall ISO and started all over again.
The install from the netinstall media did go as planned until i reached the point where it wanted me to select an debian mirror, started to scan its content… and froze.
Ok, its unstable software, something like that may happen. I rebooted, started the installation again and it did freeze again.
Well… at this point i reached my frustration zenit, it was already late so i somewhat rage-quitted for the day.
Ok, the next evening i was back at it again. THIS time the installer was able to scan the mirror and finish the installation. After the reboot it booted up normally… only to freeze during boot. Okay, its still unfinished software… hard-reset and another try. Just… something during this failed boot attempt seemed to have messed up the ext2 filesystem that bad that fsck could not repair it on its own.
That was the last buckling of that bovine that threw me off again. I needed a break, junior needed attention, and just-too-many things at home needed my attention as an handyman.
Addendum
Another day, new luck… lets try it again. I thought to myself: Well, you got a functional installed system out of the 2021 version, so try it again with this approach. And following my steps above up until after the upgrade to the 2023 version and… everything still works!
Now setting up X and an desktop environment was just a piece of cake after that. Is this GNU now tamed? I don’t think so, but at least i got the reins of the bovine and now its really time to explore this ecosystem.
I do not know how that article covered so much background on GNU hURD and the quest for a micro-kernel UNIX without mentioning Redox OS.
Redox is also micro-kernel based POSIX compatible operating system (UNIX compatible). So quite like the GNU project and HURD in that sense.
Redox is younger, 10 years old instead of 30, and more “modern” (eg. written in Rust). It can be seen as a GNU competitor as it does not rely on the GNU C library or utilities.
mit license though. ripe for getting the redis treatment
First, there has been massive amounts of MIT code in important parts of the Linux ecosystem for decades. Xorg, Wayland, and Mesa for starters. The sky has not fallen. I am not exactly panicking.
But let’s address your specific example.
Let start by pointing out that Redis was BSD, not MIT. But let’s assume your cautionary tale applies.
A truly gigantic corporation, Amazon, was making all the money off Redis without giving anything back to the company that actually wrote the code (Redis). So, Redis tried to change the license to make that more difficult. The license they chose is the strictest free software license the FSF offers—the AGPL.
Pop quiz: what part of the above are we “the community” outraged about? The clearly predatory Amazon stuff? Or the defensive action by the company writing all the code? That’s right, we are mad at the company that gave us all the code for free and that still licenses it AGPL.
But even beyond that, what was lost again? Because the implication is that BSD (or MIT) somehow allows companies to “take” free software from us. This is false.
What happened with Redis is that the original code remained 100% available. And it remained part of a 100% free software project. It remains 100% BSD licensed to this day. You can use it, you can study it, you can improve it, you can share it, and you can even sell it commercially! It offers you at least FIVE freedoms.
https://github.com/valkey-io/valkey
Not a single line of code was lost from the project. Yes, the project had to change its name (Redis owns the name Redis). Yes, Redis stopped contributing to the project. Is that not their right?
It is that last bit that seems to drive us mad. We yell about corporations taking our code. But all the examples of bad behaviour we give boil down to them choosing to give us less of theirs.
If “the community” is the one writing the code, nobody can take it from us. And even if big evil companies are writing the code, the only code that they can deny us is code they write in the future.
I find it hard to be either outraged or even particularly afraid of that.
Anyway, I do not want to talk you out of your license preferences. I have no beef with that. But I do wish there was less FUD slinging at projects that choose to license their hard work as MIT.
Except they didn’t relicence to AGPL initially, they switched to dual licensing under the RSALv2 (a proprietary licence) and SSPLv1 (a non open source, non-free licence). So essentially they made it proprietary, that’s what everyone was annoyed about. If they went straight to AGPL I’m sure there would’ve been some people who were annoyed, but most developers would understand why and I doubt there would have been the valkey fork.
I realize I oversimplified a complex set of moves and “shared source” is its own can of worms. My post was already too long.
But my core point is that the code (as Valkey) remained available and remains available under the same free software license that it has always been available under.
The only consequence of what Redis did was that they stopped giving away their “new” code to service providers like Amazon. Even Amazon can continue to use what was there before. And the community can continue to collaborate on the same code base that they were collaborating on before. The licence Redis chooses for its “new” code is largely irrelevant.
We talk about permissive licenses like they represent some massive risk. I just do not see it that way. And they have many advantages including often attracting more corporate participation (more free code for me).
I am a very happy user of Clang/LLVM. It is the product of collaboration between Google, Apple, Sony, Microsoft, academia, and other nerds. I am very happy we have licenses that encourage companies to create quality software for me to use.
I am sure Redis chose BSD to begin with in case they ever had to make a move like they did. If the only option was GPL, they may never have released it as Open Source to begin with. Again, I am glad they did.
The difference with llvm is that nobody is selling a hosted llvm as a service, nobody is making money off llvm without contributing back (directly, I know a bunch of companies use llvm to make a product that makes money).
Redis clearly thinks that using the BSD licence was a mistake. I agree with you, using BSD attracted more people/companies to use it than if they had chosen AGPL, that’s the trade-off you make when choosing a copyleft licence.
I think I agree with you on a lot of this, let me know if this is a fair summary of your argument:
Permissive and copyleft licences both have advantages and disadvantages, if a project chooses a permissive licence then that’s their choice, and if they later decide to re-license then the project will probably get forked and carry on under the original licence, so as a user you can just switch to the fork and the only thing that will is the name of the package you install.
That seems pretty reasonable to me, let me know if I made any mistakes summarising your point.
The caveat I would add to that is that the project shouldn’t complain about freeloaders if they choose a licence that explicitly allows freeloading. They chose a permissive licence for its advantages but they won’t accept the consequences that come with that decision.
Fun fact, there isnt even an “MIT license”, look:
Next level gaslighting. “Is the MIT license in the room with us right now?”
I took this in the spirit that there isn’t a single MIT license, so you’re correct, but more gooder would’ve been to mention the specific variant that was in use by the project
I mean that there is MIT and MIT-0 is already odd
testregex is an absolutely wild suffix
There are many variants. Also APL2.0 is just as permissive but protects against patent trolling
Did you even read the page you linked? It took less than 10 seconds to scroll down to the 'M’s.
Yes.
I’m super excited for Redox, but unless you’re a Rust developer it’s a bit limited. Few programming languages oþer þan Rust are available for it.
Eventually, I hope it’ll have tiling window managers and Go, V, and Zig ports; Helix (an editor written in Rust), tmux, and zsh. At þe moment, no-one of þese have been ported, and þat’s kind of a bare minimum.
How can I find out if it supports ext4? if it does I might install it tonight. I have been waiting for Hurd for over a decade.
Just FYI: Everything Hurd set out to do which Linux couldn’t has by now been implemented in Linux.
Such as?
Portability to different architectures, filesystem in userspace, and patching the kernel without rebooting are the major ones.
You can patch the kernel live? I know that Ubuntu does that
Red Hat does it, too.
But it’s a paid enterprise feature.
With systemd? AFAIK, it’s a hard dependency this days.
No it’s not. You can install sysvinit on Debian which removes systemd automatically. There are a couple other steps but it’s a 5 minute process.
