Overspark

One of the main advantages of Optane doesn’t easily show in a benchmark: it doesn’t have to do any cleanup. Normal SSD’s cheat all the time by caching writes in DRAM and an SLC portion of the NAND. Usually that works fine and you won’t notice, but if you keep writing then at some point performance will plummet dramatically. Also, the SSD’s need a breather every now and then to rewrite that cached data to it’s final place, during which time performance is also worse.

Optane doesn’t need any of that. You can write to it at max speed 24/7 and it’ll just take it and keep going, at ridiculously low latency. Perfect for handling large non-stop data streams, or workloads that need a guaranteed low latency (both for reading and writing). It’s a real shame the concept failed, the tech was fantastic.

Hmmm, Fresh looks interesting, didn’t know about that one!

I use mergerfs (and snapraid because I do care about my data and want parity) on ext4 formatted disks. This is a much better way to use your disks if you’re mostly just storing media. RAID is for mitigation of downtime after drive failure, not for joining a bunch of (differently sized?) disks into one pool if downtime isn’t really a problem.

I think unattended-upgrades only runs once a day by default, and the repository index could have changed since then. Different results on different machines can be because unattended-upgrades didn’t run at the same time, or from the same mirror (and mirrors take a while to propagate changes). Generally speaking you should always run an apt update directly before installing new packages.

Arch in the front, Debian in the back(end). I run Arch on my laptop and Debian on my homeserver. I’ve ran Debian on laptops before and if stable is getting older hardware support can be a struggle, much better on a rolling distro like Arch. And having all the newest toys on your desktop is very very nice. While on my homeserver I mostly want stability, everything else runs in (podman) containers anyway.

Cachy is a distro I would consider, because it’ll theoretically give you slightly better battery life due to the optimised compiles, although I’m not sure you’ll ever really notice. Manjaro has a reputation of breaking far more often than Arch does, so that one’s a no for me.

dotfiles and system configuration are pretty different use-cases, usually when you do system-wide stuff you want to manage not just the configuration files but also what software is installed and a bunch of other things. Ansible or something else like it is definitely the right tool for the job. And Ansible isn’t so difficult to learn, you only need to know like 5% of what it can do to be very effective.

For dotfiles my personal preference is dotbot, but there are MANY many different tools that are all good and are just different ways to accomplish roughly the same thing.

You’re probably correct, although I have no experience with zram so can’t be sure. But you’re absolutely right that PostgreSQL depends heavily on the OS disk cache for optimal performance. Lowering the PostgreSQL setting like Blaster M suggests won’t improve performance much, since all that setting does is tell PostgreSQL’s algorithms how much memory is likely to be allocated to the OS disk cache. Of course it’s best if it’s accurate, so you’re best off seeing how much memory is actually allocated to disk cache under heavy use before setting it, but it shouldn’t massively reduce performance if you don’t get it right.

Check out carapace. It takes a bit of setup but basically tries to make all the completions work in almost any shell. For me that solved the big step backwards from fish’s completions that nu’s native completions have.

Yeah, it has. I think they started out as loving the concepts of PowerShell but hating the implementation, combined with the fact that PowerShell is clearly a Windows-first shell and doesn’t work so well on other OSes (it surprised me a lot to find out that PowerShell even has support for linux).

nu tries to implement these concepts in a way that’s more universal and can work equally well on Linux, macOS or Windows.

It’s arguably better as a scripting language than as an interactive shell. There are a lot of shell scripts out there that also dabble in light data processing, and it’s not the easiest thing to achieve well or without corner cases. So nu scripts are great if all you need is shell scripts with some data processing.

nu as an interactive shell is great for the use cases it shines at (like OP’s example), but a bit too non-POSIXy for a lot of people, especially since it’s not (yet) as well polished as something like fish is for example.

Edit to add that nu’s main drawback for scripting currently is that the language isn’t entirely stable yet, so you better be prepared to change your scripts as required to keep up with newer nu versions (they’re at 0.107 for a reason).

nu 's commands also work on JSON, so you don’t really need jq (or xq or yq) any more. It offers a unified set of commands that’ll work on almost any kind of structured data.