The_Decryptor

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.

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.

the drivers and communications to talk to printers are all closed source

That hasn’t stopped CUPS

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

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.

So one of the problems is the size of a “physical page”, on a stock x86 system that’s only 4KiB. If you allocate just 1MiB of RAM you need to back that with 256 “page table entries”, and to then load a virtual address within that allocation you need to walk that list of 256 entries to find the physical address in RAM that the CPU needs to request.

Of course these days an app is more likely to use 1 GiB of RAM, that’s a mere 262,144 page table entries to scan through, on each memory load.

Oh but then we’re also not running a single process, there’s multiple processes on the system, so there will be several million of these entries, each one indexed by address (Which can be duplicated, each process has its own private view of the address space), and then by process ID to disambiguate which entry belongs to each process.

That’s where the TLB comes in handy, to avoid the million or so indexing operations on each and every memory load.

But caching alone can’t solve everything, you need a smarter way to perform bookkeeping than simply using a flat list for when you don’t have a cached result. So the OS breaks down those mappings into smaller chunks and then provides a table that maps address ranges to those chunks. An OS might cap a list of PTEs at 4096 and have another table index that, so to resolve an address the CPU checks which block of PTEs to load from the first table and then only has to scan the list it points to.

Like this, this is a 2 level scheme that Intel CPUs used before the Pentium Pro (iirc), the top 10 bits of an address selected an entry in the “page directory”, the CPU loads that and uses the next 10 bits to select the group of PTEs from that list, following that link that it finds the actual PTEs that describe the mappings and then it can scan that list to find the specific matching entry that describes the physical address to load (And it then promptly caches the result to avoid doing that again)

So yes, for a given page size and CPU you have a fixed number of walks regardless of where the address lives in memory, but we also have more memory now. And much like a hoarder, the more space we have to store things, the more things we do store, and the more disorganised it gets. And even if you do clear a spot, the next thing you want to store might not fit there and you end up storing it someplace else. If you end up bouncing around looking for things you end up thrashing the TLB, throwing out cached entries you still need so now need to perform the entire table walk again (Just to invariably throw that result away soon after).

Basically, you need to defrag your RAM periodically so that the mappings don’t get too complex and slow things down (Same is true for SSDs btw, you still need to defrag them to clean up the filesystem metadata itself, just less often than HDDs). Meta have been working on improvements to how Linux handles all this stuff (page table layout and memory compaction) for a while because they were seeing some of their long-lived servers ending up spending about 20% of CPU time simply wasted on doing repetitive walks due to a highly fragmented address space.

The RA in RAM stands for random access; there is no seeking necessary.

Well there is, CPUs need to map virtual addresses to physical ones. And the more RAM you have the more management of that memory you need to do (e.g. modern Intel and AMD CPUs have 5 levels of indirection between a virtual and physical address)

But it also caches those address mappings, as long as your TLB is happy, you’re happy. An alternative is to use larger page sizes (A page being the smallest amount of RAM you can address), the larger the page the less you need recurse into the page tables to actually find said page, but you also can end up wasting RAM if you’re not careful.

TypeScript is actually pretty nice, it’d be JScript instead.

Yeah, the days of end users installing their own OS is in the past, PCs are appliances for most people now.

That’s “Extended ASCII”, basic ASCII only has upper and lowercase latin characters and things like <, =, >, and ?

And probably half of the control codes are still used, mostly in their original form too, teletype systems. They’re just virtual these days.

A place I worked at did it by duplicating and modifying a function, then commenting out the existing one. The dev would leave their name and date each time, because they never deleted the old commented out functions of course, history is important.

They’d also copy the source tree around on burnt CDs, so good luck finding out who had the latest copy at any one point (Hint: It was always the lead dev, because they wouldn’t share their code, so “merging to main” involved giving them a copy of your source tree on a burnt disk)

How about a 6.4TB sqlite database?

https://boyter.org/posts/searchcode-bigger-sqlite-than-you/

Qt is overkill if all you’re using it for is to create a window you render into, something like SDL would be better.

They were a bit too public with “Dual_EC_DRBG”, to the point where everybody just assumed it had a backdoor and avoided it, the NSA ended up having to pay people to use it.

Which replaced Google Play Music, which was actually good.

Then don’t get me started about how the www subdomain itself no longer makes sense. I get that the system was designed long before HTTP and the WWW took over the internet as basically the default, but if we had known that in advance it would’ve made sense to not try to push www in front of all website domains throughout the 90"s and early 2000’s.

I have never understood why you can delegate a subdomain but not the root domain, I doubt it was a technical issue because they added support for it recently via SVCB records (But maybe technical concerns were actually fixed in the decades since)

Chromium had it behind a flag for a while, but if there were security or serious enough performance concerns then it would make sense to remove it and wait for the jpeg-xl encoder/decoder situation to change.

Adobe announced they were supporting it (in Camera Raw), that’s when the Chrome team announced they were removing it (due to a “lack of industry interest”)

They’re “file like” in the sense that they’re exposed as an fd, but they’re not exposed via the filesystem at all (Unlike e.g. unix sockets), and the existing API is just mapped over the sockets one (i.e. write() instead of send(), read() instead of recv()). There’s also a difference in how you create them, you open() a file, but connect() a socket, etc.

(As an aside, it turns out Bash has its own virtual file-based wrapper around sockets, so you can do things like cat a remote port with Bash, something you can do natively in Plan 9)

Really it just shows that “everything is a file” didn’t stand up in practice, there’s more stuff that needs special treatment than doesn’t (e.g. Interacting with TTYs also has special APIs). It makes more sense to have a better dedicated API than a generic catch-all one.