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
I think you're misunderstanding my post. I did not write a Wayland backend for GNUstep; I kind of did the reverse, I wrote a GNUstep backend "for Wayland". Namely, Owl is a Wayland compositor/server and a Cocoa app; it renders its clients' windows that it receives over Wayland using Cocoa as its backend (a lot like XQuartz does for X11).
The Cocoa implementation (here, GNUstep) then of course uses a backend of its own to render; here it's X11.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!