My personal state of the hurd
I've been a developer for Arch Hurd for over 6 months now and I like to think that I'm finally getting the hang of things. In these last few months I've seen a few new articles on the Hurd here and there, however, all of them focus on historical developments and RMS. Not that the history of the Hurd isn't an interesting one but I feel like there is very little information out there about the actual current state of affairs. Ok, thats not quite right, there are great sources of information like the Hurd open issues page and the bug-hurd ML (especially this recent thread). But today, for the first time in my life, I felt like blogging so I'm going to share my perspective.Real World Usability
The big points are all nicely discussed in the aforementioned bug-hurd thread.
A quick summary of the major things missing:
- SATA
- USB
- Sound (Not really that serious but many people, me included, really want to be able to play music :D )
These are the things I consider the worst problems. Not only are they somewhat important, they will also require a lot of work to implement. Many other issues are, at least imho, fixable with some time devoted to them. This includes things like modern browsers and many of the open issues. The long lasting problem of bad NIC support is starting to look brighter too, I don't dare say the issue is solved but current progress is looking great.
I feel like I should explain in more detail why I find the points listed above to be such serious problems. Of course you can still use IDE,PS/2 and maybe you can even live without music. I think we can all agree on the fact that IDE and PS/2 are slowly dying, accordingly it becomes rarer for people to have Hurd-ready hardware at home. Please don't misunderstand this, I'm not seeing the normal home-user as a future Hurder but I am of the opinion that many interested people, who want to contribute, have a hard time doing so because they simply can't get it to run on the hardware they have.
That said, I did recently build myself a hurd box from old parts I had and everything works fine so I guess things don't look too dim yet.
A short word on my experiences with my hardware install, which is pictured somewhere in this post. I've been running it for a little over a week now and things actually work pretty well. I mainly use it for developing and package building. Occasionally the whole machine just freezes, sadly I haven't had any success in debugging this yet but I'll keep trying. X worked effortless for me(others are reporting problems though), we haven't got a lot of X programs in our package repos yet, so I don't really want to say too much about it, maybe some other time. All in all I have to say that the Hurd certainly isn't as unusable as many make it out to be. However, the system of course isn't flawless yet, it does have stability issues and individual programs don't work quite right.tl;dr In my opionion the Hurd is pretty much usable for motivated enthusiasts.
The Mess
Now that we got the usability covered I can go to things that suit me better, like ranting. In my opinion maintaining packages for a Hurd system is a terrible mess. I may be alone with this opinion and it may just be a lack of skill on my side, anyway this is how I see it:
Building the same software that builds perfectly on Linux may cause you terrible suffering on Hurd. Sometimes the configure scripts need a little sed magic, sometimes you'll have to find patches hidden in the deepest depths of the internet (or if you're lucky the Debian patch-tracker), sometimes you'll have to patch things yourself and sometimes everything works fine. And this is after the situation has already gotten a lot better thanks to Debian/Hurd.
The best example I can think of is glibc. It starts with the fact that upstream releases will only build after severe patching. There is a
hurd glibc repository that builds correctly but there are a lot(~20) of additional patches that should be applied to make glibc as complete as possible. So in the end, to have a decent glibc, you have to get the source from a non-upstream repository, apply a large amount of patches and maybe even fiddle with the configure flags a little. And it's not as straight-forward as it sounds either.
For me, having such a central part of the system such a state, seems like a very bad situation. I have to admit though, I don't know anything about the reasons for upstream glibc being like this.
Luckily no other packages are as bad as glibc in this respect. However, in the end package maintaining requires a lot more time than it would on a Linux based system, which in turn leaves us with a lot less time that we could use for development and/or fixing real issues.In retrospect I remember why I don't blog. It looks like a lot of stupid rambling now.
But I guess (and hope) that the internet has seen worse.
