Notices by Sergey Bugaev (bugaevc@floss.social)

Reminder that GNU tar(1) has long options support, so instead of 'tar zxvf' or whatever line noise you can do

tar --extract < my-archive.tar.gz

@TheEvilSkeleton > attention to details

Also GitHub: let's loop endlessly instead of loading unless the browser has the clipboard API

@aral you mean JScript?

Java what now?

Remember: the latest/last Java release was Java 8, and even that has only half-happened. Java 7 is absolutely real though.

🙃

Anyways, it does all the stack magic and Hurd data block and TLS setup and malloc and tunables and symbols and whatnot, and finally calls user's main!

So I can be reasonably sure that once GNU Mach 'gets there', glibc will not crash *right away* — maybe a little bit later, when you try to do something more complex, such as (oh horror) actually start the signal thread.

vm_map is a bit harder, because we have to allocate actual memory from Linux. I break'd before the very 'syscall' instruction, set registers as for the Linux's mmap syscall, held my breath, and let it execute 'syscall'. It worked! — so now I just had to save the newly allocated address as Mach would, and make vm_map return KERN_SUCCESS.

The two interesting calls are setting fs_base (that very i386_fsgs_base_state thing) and allocating memory with vm_map.

The former is easy to do, recent GDB versions let me just read and write $fs_base like any other register. So there I go, emulating a syscall (technically an RPC) that does not exist in the real Mach yet!

🎉 x86_64-gnu glibc works 🎉

...kind of.

I was unable to make x86_64 GNU Mach run it (needs further investigation), and then even if I would, gnumach still doesn't implement i386_fsgs_base_state, so glibc would crash & burn very early at TLS setup.

So instead, I'm running it... on Linux. Yes, really 🙂

I'm of course no stranger to running Mach software under Linux, if you know what I mean — but no, I have not implemented the (in?)famous HELL (the Hurd Emulation Layer for Linux).

I'm using GDB!

Linux happily agreed to exec my statically linked ELF, even though the ELF says it's for the Hurd. I had to gaslight GDB into thinking it the executable is for Linux, but that was easy ('set os default').

Then I ran it, instruction by instruction (si, si, si, si...). When it attempts to make a syscall, I make it skip the syscall and model its effect in my head (you want __mach_task_self? here, say that returned a port name of 1).

futures::pin_mut!() was used like this:

let stream = make_stream();
pin_mut!(stream);
use(stream);

i.e. it worked on a variable (by shadowing it). The new core::pin::pin!() just works with expressions:

use(pin!(make_stream()));

Naturally, you can still save it to a variable if you want to:

let stream = pin!(make_stream());
use(stream);

#Rust 1.68 is out!

The coolest thing in there is the newly stabilized pin!() macro, which of course makes any value of type T into a Pin<&mut T>

This is like the old futures::pin_mut!() macro, but they've done some awesome magic (or: horrible hacks) to make it more ergonomic:

@tbernard can the shell scale them down auto-magically?

@tbernard realistically, they're not changing their icons upstream just because of GNOME.

It's not changing icons, it's just picking the best scale to display them? The shell already displays icons with different scales in different contexts, so it wouldn't be unprecedented.

Re pixel grid — aren't they supposed to be scalable svgs? If not, how do we know they really fit on the pixel grid now — have LO specifically optimized their icons for display in GNOME? (evidently no)

@tbernard either a hardcoded list or alpha hacks would work, and yes, both are terrible. I don't have any better ideas.

@tbernard maybe I'm misunderstanding how the pixel grid works though

Cool, apparently with the std::thread::scope() API in Rust 1.63.0, they managed to design it in a way that

- is still sound
- still lets you spawn more scoped threads from inside scoped threads
- does not require passing down that extra |s| argument to all the closures!

This is non-trivial, because the whole point of the scoped API is that...

// ...you can capture things from here
thread::scope(|s| {
// ..you *cannot* capture things from here
s.spawn(|| some_work());
});

And yet, they've made capturing s just work
¯\_(ツ)_/¯

dear game devs, please add this to all your code:

if (runningOnSteamDeck() && goingToLag()) dont();

thx

Argh, it's been firewalld that prevented my libvirt VMs from accessing the host

Spent a loooot of time trying to debug this, thinking it was a bug in my Terrible mDNS responder at first. Then when I saw that not only mDNS does not work, but pretty much nothing does, I realized it was something with libvirt networking setup.

This is further complicated by how the 'default' network is apparently defined by the system libvirt, while my VMs on the user libvirt are able to use it without explicitly referring to it, by connecting to the bridge interface.

"It just works", except when it doesn't, and you're on your own trying to make sense of the patchy docs and random forum questions scattered around the web.