[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] news/2023-q4.mdwn: new qoth for q4 of 2023.

From: Sergey Bugaev
Subject: Re: [PATCH] news/2023-q4.mdwn: new qoth for q4 of 2023.
Date: Sat, 6 Jan 2024 23:20:35 +0300

On Sat, Jan 6, 2024 at 10:47 PM jbranso@dismail.de <jbranso@dismail.de> wrote:
> +Luca Dariz worked on adding [[some simple GNUMach user-space tests

I've never seen gnumach spelled like that (GNUMach), only GNU Mach or
gnumach. Is that intentional?
> +Flavio Cruz [[improved GNUMach's
> +IPC|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00033.html]]
> +by reordering `mach_msg_type_t` fields to byte align `msgt_name` and
> +`msgt_size`.  He also created a patch series to [[avoid message
> +resizing for
> +x86_64|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00028.html]].
> +He also [[removed untyped mach RPC
> +code|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00026.html]],
> +since the Hurd always uses typed Mach RPC.

It's not that much that *the Hurd* uses typed IPC, it's that gnumach
does. The Hurd could easily support either, and in fact this support
was present (though likely bitrotten), and this is what Flavio has
removed. This is because going forward, we don't see the Hurd running
on any other flavor of Mach; but it was originally the goal for it to
run on non-GNU Machs, IIRC.

> +Sergey Bugaev added [[GNUMach entry re-coalescing
> +support|https://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_map_entry_forward_merging/]].
> +Essentially, Mach is not always able to merge two vm entries that are
> +made next to each other, which slows down ext2 and bash.  Sergey
> +allowed GNUMach to merge entries in the common cases, which greatly
> +helps ext2fs.

Is that actually true though — did it speed anything up?

> +Sergey is also working on [[porting the LadyBird web
> +browser|https://lists.gnu.org/archive/html/bug-hurd/2023-11/msg00013.html]]

We spell Ladybird with a lowercase b. You could also link to
https://ladybird.dev/ here.

> +to the Hurd.  The author of this post uses the [[netsurf web
> +browser|https://www.netsurf-browser.org/]] on the Hurd, which works on
> +simple websites like wikipedia, but it badly renders javascript heavy
> +websites, which makes many websites un-useable.  If Sergey is
> +successful in porting LadyBird, then Hurd users could start using
> +sites like Github!

Let me show you something (see the attachment :)

See also [0] for a recent update on Ladybird development; there are
live demos in the second half of the video.

[0]: https://youtu.be/jagkQMbfqJY

> +Sergey also started [[porting the Hurd to
> +AArch64!|https://lists.gnu.org/archive/html/bug-hurd/2023-12/msg00110.html]]
> +While a port to RISC-V might be more exciting,

What I meant there is that RISC-V itself is more exciting, because
it's an open architecture and so on. As far as Hurd ports go, both
ports would be equally exciting to me. In fact, aarch64-gnu might be a
little bit more exciting exactly because I do have the hardware to run
it, today.

> it is worth mentioning
> +that AArch64 is more established. What is interesting is that Sergey
> +is already able to build Hurd servers for AArch64! Normally, in order
> +to run the binaries, one would port GNUMach to AArch64. Luckily for
> +us, Sergey is a genius.

I wish :D

> He was able to run a 'Hello World' Hurd
> +AArch64 binary on Linux in GDB!  This helped him fix some bugs along
> +the way.  We still need to define the ABI and complete the GNUMach
> +port, but this is exciting news!
> +
> +Tobias Platen started [[porting GNUMach to
> +Power9|https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00021.html]].

Wait, how did I miss this? And I see that discussion even referenced
Darling!? (and no one cc'd me *despite* talking about Darling?) If
that is going somewhere (though it seems stalled?), should I be
hacking on PPC userland?


Attachment: Ladybird on GNU Hurd.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]