I've mentioned this a few times but never publicly announced it, so consider this the announcement.
I've also ported Owl, my Cocoa Wayland compositor, from OS X to the Hurd using GNUstep.
Here's a screenshot of weston-terminal and weston-flower, running on Owl on GNUstep on Hurd, with X forwarded from a QEMU VM via SSH.
Previous threads about Owl: https://mastodon.technology/@bugaevc/101603518023241841 & https://mastodon.technology/@bugaevc/102021874783142628
@codesections hah, this is the question I always get whenever I post about the Hurd :D
It is pretty usable as a (server, command-line) Unix system. Modulo a few bugs and hangs, things work much as they do on GNU/Linux (and you can do all sorts of fun stuff with translators).
It can kind of run X.Org, Xfce/LXDE, and even simple web browsers (you can toot using the Hurd!). But it's very unstable and lacking drivers for any serious/modern hardware, so you wouldn't use it as your daily driver.
> hah, this is the question I always get whenever I post about the Hurd :D
Sorry for not being more original :D
Thanks for the info, though. Sounds like it's getting really close!
@bugaevc I wonder, which quirks and issues have you found when developing for Hurd?
@espectalll well, the big one was that there was no epoll or anything similar (kqueue would suffice), only select and poll. So I had to write my very own epoll server & client implementation with the same API as Linux implements.
Of course, there's no PATH_MAX and no limitation on the length of file paths (number 1 problem with trying to port any software to the Hurd); I had to workaround this in the wl-clipboard port, and since it's my project I'll actually upstream the changes, so that's nice.
Then of course I had to port Owl from OS X Cocoa to GNUstep Cocoa (so these few following quirks are due to GNUstep, not Hurd). There are a bunch of differences: there was no libdispatch and block support, so I had to rewrite all those dispatch_once calls (Owl is otherwise single-threaded, so that wasn't too hard). GNUstep's NSRunLoop works differently compared to Apple's (which wraps CFRunLoop), so I had to rewrite OwlRunLoopSource to use GNUstep's API extension instead of a CFSocket.
@espectalll And GNUstep doesn't really have CoreGraphics (there is Opal, but GNUstep is usually built without it), so I had to rewrite the actual OwlShmBuffer rendering code to use the old Cocoa drawing APIs (and do some manual pixel format conversions — that was fun to debug!).
And since the Hurd doesn't use a bootstrap server nor has IOSurface's, I dropped zowl_mach_ipc_v1 and zowl_iosurface_v1 protocols & their implementations, so there's no shared GPU buffer OpenGL rendering, just CPU & shm.
@bugaevc that's honestly so amazing, great job!
@bugaevc That's awesome! Are you planning to publish the Wayland patches and possibly the Owl source? I think that could prove to be useful, or at least very interesting for a number of people.
@YaLTeR no need to pretend we haven't talked about this 😉 Yes, I plan to eventually publish Owl & the patches, but I haven't done so yet (gotta release wl-clipboard 2.0 first :D)
I've already sent several people (including you!) the sources dump; if anyone else is interested, ask me & I'll PM you the sources.
@bugaevc That 482% CPU usage!
@jiminycricket yeah, Hurd might have be reporting that wrong :D
@ELR I haven't publicly released the source code yet; when I do, it'll be GNU GPL version 3 or later.
If you're interested, PM me and I'll send you the source dump.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either! We adhere to an adapted version of the TootCat Code of Conduct and have documented a list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators. Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!