The_Decryptor

SpaceX wrote in its July permit application — under the header Specific Testing Requirements — Table 2 for Outfall: 001 — that its mercury concentration at one outfall location was 113 micrograms per liter. Water quality criteria in the state calls for levels no higher than 2.1 micrograms per liter for acute aquatic toxicity and much lower levels for human health

Cool, you can drink the mercury water, but I’ll pass thanks.

I’ve got some numbers, took longer than I’d have liked because of ISP issues. Each period is about a day, give or take.

With the default TTL, my unbound server saw 54,087 total requests, 17,022 got a cache hit, 37,065 a cache miss. So a 31.5% cache hit rate.

With clamping it saw 56,258 requests, 30,761 were hits, 25,497 misses. A 54.7% cache hit rate.

And the important thing, and the most “unscientific”, I didn’t encounter any issues with stale DNS results. In that everything still seemed to work and I didn’t get random error pages while browsing or such.

I’m kinda surprised the total query counts were so close, I would have assumed a longer TTL would also cause clients to cache results for longer, making less requests (Though e.g. Firefox actually caps TTL to 600 seconds or so). My working idea is that for things like e.g. YouTube video, instead of using static hostnames and rotating out IPs, they’re doing the opposite and keeping the addresses fixed but changing the domain names, effectively cache-busting DNS.

SpaceX like to dump their waste in the closest river.

Set that minimum TTL to something between 40 minutes (2400 seconds) and 1 hour; this is a perfectly reasonable range.

Sounds good, let’s give that a try and see what breaks.

What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed.

Other way around, you can convert a “web safe” JPEG file into a JXL one (and back again), but you can’t turn any random JXL file into a JPEG file.

But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss.

I’ve seen zero RISC devices in the wild

Ever seen an Nvidia GPU? They’ve been using them for years. One estimate is they shipped 1 billion cores in 2024.

Not as end user programmable chips of course, but the “end user devices” market is only a small part of the total industry.

Rust has no stable inter-module ABI, so everything has to be statically linked together. And because of how “viral” the GPL/LGPL are a single dependency with that license turns the entire project into a GPL licenced one.

So the community mostly picks permissive licenses that don’t do that, and that inertia ends up applying to the binaries as well for no real good reason. Especially when there’s options like e.g. MPL.

Ehh, I’d pass on Ladybird. I’ve been donating to Servo myself.

Microsoft did.

I just checked my phone, it was on by default for me.

Well no you can translate, but it just seems that nobody has actually made a product to do so.

e.g. those M.2 SSD to USB adapters, those aren’t speaking NVMe to the host device. They either talk the traditional USB “bulk transfer” protocol, or potentially SCSI, translating that to NVMe for the SSD itself.

Man, it sure would be helpful for my argument if I could.

I went back and checked the ones I was looking at, very helpful fine print stating “not for NVEM ssds”, so they all only work with mSATA M.2 SSDs, hell of a let down.

Especially since you can get M.2 to SATA adapters, so people stuck with SATA only motherboards can still upgrade their storage.

Literally the same deal when companies stopped making IDE drives, people just used SATA to IDE adapters instead.

Git itself (Or any other VCS for that matter) really should treat symlinks as special, similar as to how btrfs stores everything as “reflinks” internally. They be stored as special references to other tracked objects (so it’d be impossible to commit a symlink that pointed at anything other than a checked-in file, and ensure they always match), and git can materialise them as needed.

We’ve got shovels and we are in a big hole … which way are we going to dig?

This behavior is actually in line with what I’d expect, as Unicode support in Windows predates UTF-16, so Windows generally does not handle surrogate pairs and instead operates almost exclusively on WTF-16 code units directly.

So it’s just straight UCS-2, and the software does enforce that, pretty much the opposite of “WTF-16”.

Edit: Pretty sure “modern” (XP+ I think) Windows actually does enforce UTF-16 validity in the system, but there’s always legacy stuff from the NT4/2K era that might turn up.

That’d at least make sense, this is a (literal) black box. Seriously, my monitor takes long enough to wake that it’s at the boot loader screen by the time it’s ready.

I found a post on Reddit claiming it’s a RAM thing, and I should enable XMP to avoid it. But I’ve already got XMP enabled so I need to poke around it again.

And also disable the 5 second delay in the bootloader, not like I’m ever using that fallback option.

❯ systemd-analyze
Startup finished in 14.565s (firmware) + 5.778s (loader) + 2.920s (kernel) + 3.307s (initrd) + 3.972s (userspace) = 30.544s
graphical.target reached after 3.926s in userspace.

You’re letting me down firmware!

Yeah, the Python equivalent would be something like this.

try:
    config = get_config()
catch:
    sys.exit(1)

It’s possible to handle these things, but if you explicitly don’t then you’ll discover them at runtime.

I’m still annoyed that “OPAQUE” never seemed to catch on. Uses a username/password combo as normal, but never actually sends the password to the server, only a proof of knowledge. Even if the server is hacked and the DB leaked the attackers can’t actually recover anything resembling a password from it, since the server simply never possesses it.

Passkeys are superior (No password at all), if only the UX around them was better.