Also have an extremely common name in Portugal (just in my company there are 4 people with my name, including my previous manager), only slightly helped by the fact that we’re one of the few countries that inherits last names from both parents, which helps with differentiation. At least I did snag pedroalves.pt when I found it available!

EDIT: Username does better, but for some reason Kimi seems to think I do algorithmic competitions, and Llama 3.1 thinks I am a German football club (no longer just a player, a whole club now!)

Who would’ve thought that NVIDIA started upstreaming stuff once they realized how much money Linux is making them?

Also, supposedly on the second half of 2026 they were going to be moving even more stuff out of their Jetson-specific drivers as they already do for their slightly newer chips (so you could use the standard drivers, and standard CUDA builds). Let’s see how that turns out.

Last time I did astrophotography was a few years ago, before Starlink made the problem considerably worse, but satellite trails were relatively easy to remove with stacking. I'm sure it's harder now but definitely still possible, so I'm assuming in this case leaving them in was done on purpose to highlight the problem.

EDIT: Looking better at the picture, I belive this was taken with a star tracker and then composited with a shorter exposure of the foreground. Notice how the foreground, even far away, looks considerably blurrier than the stars, and how the tower in the background has some light streaks. This is exactly what you'll see if you use a star tracker. Rather than star trails, you'll have "foreground trails". This would explain why there are relatively few gaps in the satellite trails, since the exposures can be much longer.

Modern cars have tens of ECUs, so if you had to have all of them for testing, that would get unwieldy extremely quickly. Not to mention that cars are pretty resilient to having random parts failing, you don't want to lose the entire dashboard just because the ECU that provides camera data failed, or something.

Considering the vast majority of mods are just adding some items or creatures, they don’t need to worry. This won’t be more than the regular API changes in between versions that they’re already used to, unless it’s a more graphics heavy thing like a shader mod.

Also, even with shaders, it’s fairly straight forward to port a shader from OpenGL to Vulkan (for the most part Vulkan just gives more flexibility in that regard). The stuff around it is the hard part.

For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return:

- Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver

- The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver

- The Tyr GPU driver for Arm Mali GPUs - https://rust-for-linux.com/tyr-gpu-driver

I suspect the first one of those to be actually used in production will be the Tyr driver, especially since Google's part of it and they'll probably want to deploy it on Android, but for the desktop (and server!) Linux use-case, the Nova driver is likely to be the major one.

Then there’s the stupid BIOS warning that requires you to press ESC for the computer to boot if it’s not plugged in to the official charger, which means that if it ever reboots at night it’ll just keep you awake (because the power management hasn’t been initialized yet so it’s stuck at 100% CPU) until you go press ESC.

Oh and it thermal throttles all the time so the CPU performance is good for a few minutes and then it’s just awful.

I’d you’re interested in this, I know systemd has been working pretty hard on getting TPM-provisioned credentials usable on Linux though!

Nowadays, most distros are moving towards having /bin be a symlink to /usr/bin, so it's mattering less and less, but I see no reason not to just do /usr/bin/env which is supposed to be on the same place on every distro.