

And on the upside for them, no Gnome, since the devs are making systemd a hard dependency.
made you look
And on the upside for them, no Gnome, since the devs are making systemd a hard dependency.
I am entirely unsurprised that people who hate systemd also hate wayland.
Then there’s accessibility functions, which wayland breaks almost by design by denying apps access to each other. Even something as simple as an on screen keyboard becomes nearly impossible to implement.
That’s a side effect of just dumping everything into X11, once you switch from it you lose all the random kitchen sink warts it grew over the years.
Like an on-screen keyboard shouldn’t be fiddling with a display protocol to fake keyboard inputs, it should be using the actual OS input layer to emulate them (So then it’d work with devices that read input directly and not go via X11). Same with accessibility, there’s a reason other OSs use separate communication channels with their own protocol.
I mean, the point of the init process is to bring up the filesystem and disks, if the configuration is wrong that’ll be the process to complain about it.
“No, go away.”
That’s a perfectly valid way to deal with toxic contributors. There’s always people with better social skills and equal developer skills out there, you don’t have to accept and include toxic people just because they wrote some code.
I’d double check, if you haven’t picked an option specifically it might just default to the fallback (i.e. BOOTX64) It’ll be under the boot device order section.
(Not my picture, stole it from Reddit)
Here it’s listing all the possible boot options this mobo can find, but there’s a generic “UEFI OS” option which I’d bet is the fallback. And once a choice is made it’s kept unless something resets it, so if it just happened to be set to the fallback once it’ll stick with that until a change is forced.
When installing windows while there is a Linux install, windows will see the EFI partition already there and just decides to share it, and doesn’t create its own.
That’s what it’s supposed to do, it’s a plain FAT32 partition, the bootloaders are just files you put in there.
Part of the issue is that while a well-made motherboard will look for all bootloaders on the partition and present them as options in the firmware UI, bad ones will only look for a specific file (\EFI\BOOT\BOOTX64.EFI
) and use that. For an OS to have a chance of booting on those boards it has to overwrite that file, blowing away whatever other bootloader was there before.
It’s annoying, since Windows is mostly well behaved here (It puts the main copy of the bootloader at \EFI\Microsoft\Boot\bootmgfw.efi
and Linux bootloaders can see that and offer it, the reverse isn’t true) and can co-exist with Linux well (Well…), but manufacturers cutting corners causes more problems for everybody.
Good news, they’re making it easier to fix stuff like “spurious double clicks”.
https://who-t.blogspot.com/2025/05/libinput-and-lua-plugins.html
I can’t imagine the shame I’d feel if there was a legal finding stating that I was a fan of the minions.
e.g. Mastodon has been around for years, is actually really federated, not owned by a corporation, and a lot more features than BlueSky… but bluesky already has more users and i think largely because: marketing… how are people going to talk about “Mastodon” when they’ve probably never even heard the word before? (also named after a cool band, but not suitable for the masses).
Also fewer syllables, which apparently has a noticeable impact.
From a quick search it seems that the mobo uses a Realtek audio chip, which is probably the actual problem. My current system build uses one and it barely worked under Windows, it’d randomly remap the channels, sometimes it just wouldn’t come up properly (Showed as only a microphone, etc.), had lots of static noise, would constantly think I was unplugging and replugging headphones in, etc. Just a terrible experience compared to the Intel audio system the build before this used.
As much as “just buy another bit of hardware” is an awful bit of advice, I’d recommend getting a USB DAC/soundcard, I bought a cheap soundblaster one and it fixed all my problems. USB audio is a well-defined standardised protocol that’s supported by just about everything, does away with any driver issues or incompatibilities, can be moved between devices, etc. Mine’s a “gaming” model so it’s just a USB port on one side and a headset jack on the other, but you can also get ones with proper inbuilt amplifiers to run full speaker kits, etc.
It’s more like QEMU actually.
Yeah, I think Windows actually handles it quite well, the actual filesystem has no notion of what the filenames are outside of basic “It’s UTF-16”, it’s the OS filesystem layer that handles all the quirks.
Because that’s what people seem to dismiss, there’s no one standard notion of case folding. It depends on the locale you’re using, and that shouldn’t be built into the FS itself. The classic one was the German “long S”, where “SS” should be case folded with “ß”, except they changed it in 2024 so now they shouldn’t match (“ß” becomes “ẞ” now), good luck updating your FS to support rules like that.
Now your shell? That’s easy, you can just warn the user that a “matching” filename already exists and prompt them to change it, and you can vary those warnings based on the locale, and you can push out updates as easily as any other patch.
Yeah, the days of end users installing their own OS is in the past, PCs are appliances for most people now.
2011? That’s basically last week right?
Support for it (and UEFI ) came with their push into servers, they were forced to make the platform a lot less special and more general purpose like x86 traditionally has been.
End user facing hardware is a different matter though, like I know you can boot the Raspberry Pi via UEFI/ACPI (It builds the ACPI tables in the bootloader), but then Apple doesn’t use it at all for their ARM hardware and it uses something closer to a modern OpenFirmware.
I think x86 is basically the only platform that’s used ACPI, other hardware usually ships a fixed hardware list in firmware that the bootloader/kernel can read (Since it’s not like the motherboards are modular, e.g. the RTC is never going to randomly be connected to a different controller)
Historically ARM didn’t even do that, it was mostly used in tightly linked systems so you’d just build those assumptions into the software itself (e.g. a Gameboy always has a directional pad on specific pins, so you just read those pins directly) I remember the early days of the Raspberry Pi involved device dependent kernel images because they had to code the specific initialisation routines into the drivers, it took a while for them to gain “device tree” support so you could have a generic kernel.
For a while Google let you blacklist domains from search results, fantastic feature so of course they killed it off.
Now that is cool.