mrcarrot

Yeah, you definitely don't want to hang things off the wrong seams, or you'll end up with quite the blast radius

I've started using Linux recently after not touching a desktop distro for 20-odd years, and I was surprised how good both Gnome and KDE look these days.

It certainly doesn't feel like there's a trillion-dollar-company difference between those two and Tahoe.

It's available on Prime Video (at least on amazon.de). For a long while they would only sell access to season 1, but I've just checked now and all 4 seasons are available at the moment.

In a similar space, I'm pretty sure the recent remake & remaster of the two System Shock games were really well received, so that's hardly a given.

Yeah, I've been trying it recently and I'm not entirely convinced I want to keep using it.

My biggest annoyance at the moment (and this may be me missing something), is that I have two directories: "thing" and "thing-api". I'm doing work in "thing" much more often than in the "thing-api", but whenever I run "z thing", it takes me to "thing-api" first, and I have to "z thing" again to get to where I wanted to go. It ends up being more effort than if I'd just tab-completed or history searched a plain cd command.

yes

The "Optimized Tarball Extraction" confuses me a bit. It begins by illustrating how other package managers have to repeatedly copy the received, compressed data into larger and larger buffers (not mentioning anything about the buffer where the decompressed data goes), and then says that:

> Bun takes a different approach by buffering the entire tarball before decompressing.

But seems to sidestep _how_ it does this any differently than the "bad" snippet the section opened with (presumably it checks the Content-Length header when it's fetching the tarball or something, and can assume the size it gets from there is correct). All it says about this is:

> Once Bun has the complete tarball in memory it can read the last 4 bytes of the gzip format.

Then it explains how it can pre-allocate a buffer for the decompressed data, but we never saw how this buffer allocation happens in the "bad" example!

> These bytes are special since store the uncompressed size of the file! Instead of having to guess how large the uncompressed file will be, Bun can pre-allocate memory to eliminate buffer resizing entirely

Presumably the saving is in the slow package managers having to expand _both_ of the buffers involved, while bun preallocates at least one of them?

Also not available in Austria

Or alternatively (assuming that's true) he fired the people who thought about what they commit and kept those whose commit logs look like: "push feature WiP", "fix", "more fixes", "push", "maybe this works?"...

I think the parent was agreeing with you. If the “local” SSDs _weren’t_ actually local, then presumably they wouldn’t need to be ephemeral since they could be connected over the network to whichever host your instance was launched on.

“And management’s priority for Q4 is feature Y, so we’re just going to leave feature X like it is for now”