Recent searches
Search options
Administered by:
Polished up my GHurdFileMonitor implementation for glib some more & made a draft MR out of it
And then, I went and finally pushed my epoll reworking over the finish line — there was not that much work left, but it had to be done. Once it was, everything fell into place, and now long polls work, short polls work, polls with no interests (basically using epoll as a sleep) work, signals work (including pwait and pwait2 atomically changing the signal mask), and everything seems to just work.
Also apparently my epoll is going into the Hurd upstream soon? Exciting! 
Next, I took my "portable" Wayland patchset and rebased it onto latest upstream main. It's both better and worse; the upstream have done some BSD portability work, so equivalents of some of my changes have effectively been upstreamed, but also they added eventfd usage, so, yay, more things to patch out.
Anyway, so I got Wayland building on the Hurd once again. The tests don't yet pass, I'll need to look into that tomorrow.
After that: Owl, and gtk with its Wayland backend.
There we go! 
This is Weston's demo clients again — being built with a lot less hacks this time.
@bugaevc watching the Hurd become more functional is nice
@bugaevc I would help but I have my own wild OS projects
@bugaevc if I knew more about LLVM internals I might attempt to do Rust to it but that sounds scary tbh
@alilly hm, but Rust has already been ported as this year's GSoC project?
Also this has nothing to do with LLVM internals (LLVM/Clang has already been ported too), and everything with the libc crate & kernel-specific parts of std. Like, you have to mirror 'struct stat' layout, which differs between systems, and so on.
@bugaevc oh fun
see, I'm not really up to date on any of this stuff so
my main reason not to fiddle with Hurd was that I'm not very comfortable with C, if Rust is a working option I may take a look at how translators work and do something silly like sqlitefs
@alilly to manage expectations, it's said to be working somewhat for someone, but it's not like you can 'curl rustup | bash` and have it just work yet.
That being said: it would be *super* interesting to explore what building translators would look like in Rust. I don't think bindings to the existing C translator frameworks would work well, since it's the typical C-ish sea of pointers. We should probably go for a new Rust-native framework, perhaps based on async/await.
@alilly if this sounds exciting and you'd like to join in, I could help you figure out what a file is or whatever
@bugaevc I mostly just need to be pointed to a current programmer's manual, assuming it exists and is decent.
@alilly there is https://www.gnu.org/software/hurd/hurd/reference_manual.html, but I wouldn't say it's clear, unless you already know what it's talking about.
@bugaevc Well that build of the manual appears to be from 2007; which repository has the texinfo source?
@bugaevc alright, I had to clone the entire repository and create an empty doc/version.texi but now I have a current HTML manual
@alilly ...but I really don't think the manual will help you much. If I were you, I'd start by skimming hurd/io.defs and hurd/fs.defs, installing / updating Debian GNU/Hurd in a VM, and playing with simple libtrivfs-based translators (take that trans/hello.c code, try to modify things somewhat, make sure you can build it, make sure you know how to run it). Then I'd look at libnetfs and existing netfs-based translators.
@bugaevc yeah I read the manual cover to cover, it's um, not very good to be honest