IRC channel logs

<zamfofex>Note that (from what I’ve seen) a lot of Wayland programs are made very specifically for Linux, so it’s difficult to port them to other systems satisfyingly. See e.g. https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and

<jab>hey Hurd people! So I tried to boot me T400 with hurd-i386.

<jab>It failed to boot with trapno 6: Invalid opcode, error 00000000

<jab>panic ../i386/i386/trap.c:346: kernel_trap: trap

<jab>the hurd install CD that I'm using might be a bit dated...

<jab>I'll try booting with amd64 installer at some point too.

<jab>also dino-im stopped working for me too.

<jab>anyway...I hope ya'll are having a good weeking!

<jab`>hello hurd people! I am downloading the hurd-amd64 iso now. my internet is sooo slow here. I wonder if I'll be the first to try the installer on real hardware.

<azert>I’ve read the email from solid_black. I remembered how I hoped to help him with gnumach on arm64

<azert>Thing is that we made progress, but it felt a bit like finishing the job would have required a total higher lever of effort, let’s say an order of magnitude more

<azert>You could just compare what he did with netbsd arm support to realize what kind of work porting to arm requires

<azert>Since the kernel are very very similar. Just consider that to run on arm you need exceptions for bugs on many models

<azert>Then there was the driver framework issue, that bringing that to userspace would have been great but kind of another project

<azert>Considering that each arm have a different interrupt controller

<azert>Or at least there are a few of them or more then 5

<azert>In regards to rust

<azert>Last time I had the idiotic idea to rewrite MIG in Perl, I realized you would just reimplement it with little wins (and bootstrapping issues)

<azert>It is already a well done software, making it multibackend is in fact quite easy. Doing it sharing as much code as possible between backhands is perhaps the tricky and most interesting part

<azert>I don’t know about the Hurd libraries enough, but I guess it would be best to share as much as possible between C and rust also at that level, if rust needs his own frameworks

<azert>I understand that the API should be different and idiomatic, but I cannot believe that the parts closer to the hurd interfaces cannot be reused and shared between C and Rust

<azert>Going back to mig, just the user.c and the server.c would need to be rewritten. Most of it is boilerplate, for the rest, rust would probably use the same logic 99% of the time

<azert>There is absolutely zero need to rewrite the parser/lexer: even writing it in an higher level language wouldn’t buy you anything

<azert>However, Mach interfaces definitions are bad, really bad

IRC channel logs

2024-09-21.log