Seriously. I want a personal HUD for navigation and reminders that also corrects my vision (like normal glasses), not to become a walking surveillance device / info mine.

This is about Linux kernel driver maintainership… It’s all open source.

Yes. It has basically the same issue that any compatibility layer is going to have. It will either faithfully reproduce X11 so well it will bring all of the nonsense Wayland was meant to do a way with (everything not directly related to displaying graphics, like font and geometry rendering from the '80s, network transparency, insecure event handling) OR it will attempt to get a reasonable subset working for modern X apps and it won’t be compatible with dusty old binaries and X forwarding etc.

Right now it looks like a shim for Xwayland so it’s the first one, but as it matures we’ll see.

I couldn’t find the specific reasoning for this change, but I feel like QEMU is probably just too holistic to be appropriate for this kind of project.

QEMU needs to be able to emulate all the ARM hardware with enough fidelity to boot a naive operating system. For the purposes of running userspace applications almost all of that is not required, you really just need to convert one ABI to the other and translate the instructions. No need to handle firmware, the MMU, interrupts, disks etc.

Yes! It used to be so hit or miss with Wine, but I played WoW in it around the same time and it was crazy that it worked (at least most of the time).

There’s just no reason to do this work. Even if you ignore the fork’s controversial maintainer, and just favor the fact that it’s maintained at all (which is what the proposal’s author is suggesting) just… Why?

X11 is basically over at this point, why throw a last minute wrench into the existing, working Xorg infrastructure?

When we dropped XFree86 back in the day there were license issues, packaging issues and a real alternative didn’t exist - all justifying the effort to switch. None of these are a problem today.

I used mutt back in the day, opening vim for message editing.

I wouldn’t do a mailing list these days, but as someone who spent the early part of my career interacting with devs that preferred this method, it’s actually pretty ergonomic by a 2005 standard. A message thread aware, text based email client that can turn messages into patches in a keystroke makes it actually pretty comparable to modern code review…

I think it’s hard for younger devs to get this because they’re used to email being stuck in a crappy, unthreaded browser interface or Outlook etc. (which are terrible for mailing lists) and most collaboration taking place in code review and chat platforms like Teams/Slack but for decades before these were feasible, email was the way…

I have a couple of very minor commits in Linux and, in the 3.0 era, had my name at the top of a source file for a platform that never saw the light of day and was later removed wholesale.

Still feel that invisible feather in my cap.

So you’re right that this is a bit arbitrary because the line between the standard lib and the language is blurry, but someone writing Rust is going to expect Vec to work, it doesn’t even require an extra “use” to get it.

Perhaps a better core example would be operator overloading (or really any place using traits). When looking at “a + b” in Rust you have to be aware that, depending on the types involved, that could mean anything.

Anyway, I love Rust, it just doesn’t have the 1:1 relationship with the assembly output that C basically still has.

Huh weird, these pull requests just magically accepted themselves

Rust can create native binaries but I wouldn’t call it close to the metal like C. It’s certainly possible to bootstrap from assembly to Rust but, unlike C, every operation doesn’t have a direct analog to an assembly operation. For example Rust needs to be able to dynamically allocate memory for all of its syntax to be intact.