Ryzen 5000 cpus are extremely cheap right now. I bought a 5900xt (16 cores) to upgrade a server a few weeks ago for ~$250. If you already have DDR4 you could put together a system for pretty cheap if you need it soon.
The downside is that AM4 is basically EOL, so no upgrade path.
I can only hope RISC-V's displacement of ARM at the low end will force them into competing more at the high end in servers / high end consumer hardware.
Not defending the default behavior of zed, but it is possible to disable this. Setting `"lsp.<server>.binary.path": <some-path>` will stop zed from trying to install that server.
On my machines, the "languages"/"node" directories for zed are empty and owned by root and the lsp servers are provided by nix. But you could also pin known good versions with npm.
As far as I know Vscode has no equivalent way to do this.
This unhides the menu instead of hiding everything behind a burger. This should be the default. The defaults are awful in many ways and they've only gotten worse with the recent panel rearrangement.
The server is configured as a caching reverse proxy (just nginx with cache.nixos.org as upstream) which I think is similar to squid proxy.
Outside my LAN I do have the ability to tunnel home, but depending on the connection and the updates I just deal with the timeouts, or just wait until I get home.
I think technically you can override substituters using cli options but its not ideal. There are several proposals for configuring timeouts per substituter but none of them are merged yet.
I think this is a mostly fair criticism of nixos. Nixos has a lot of powerful tools, but if you don't need them, they can get in the way. Some assorted notes:
> the constant cycle of rebuild → fix → rebuild → fix → rebuild
I've found this useful to eliminate the rebuild loop:
https://kokada.dev/blog/quick-bits-realise-nix-symlinks/
It lets you make the config of the program you choose a regular mutable file instead of a symlink so you can quickly iterate and test changes.
> In contrast, Arch Linux simply downloads prebuilt binaries via pacman or an AUR helper
If a binary exists. A lot of AUR packages I used to rely on didn't have a binary package (or the binary package was out of date) and would have to build from source. On nixos my machines are set up to use distributed builds (https://wiki.nixos.org/wiki/Distributed_build). Packages that do need built from source get built on my server downstairs. The server also runs a reverse proxy cache so I only need to download packages once per version.
Distributed AUR builds are possible on arch, but they require a lot of setup and are still fragile like regular AUR builds, your only choice of dependencies are what's currently available in the repos.
> On my machine, regular maintenance updates without proper caching easily take 4–5+ hours
It sounds like the author may be running the unstable release channel and/or using some heavy unstable packages. Which might explain a lot of other problems the author is having too.
Back when I used arch, I found that as time went on, my system would sort of accumulate packages. I would install $package, then in the next version of $package a dependency would be added on $dep. When I updated, $dep would be installed, then eventually $package would drop the dependency on $dep, but $dep would remain installed. I would periodically have to run pacman -R $(pacman -Qtqd | tr '\n' ' ') to clear out packages that were no longer required.
Can you expand on how you use Zellij? I tried it and I understand you can use it for splits, and tabs similar to tmux. But I might revisit it if it allows an IDE like workflow with Helix.
I think it's because there are no grills on the outside. If the fans were sucking air out of the box, dust would build up on the outside, and bumping it would dislodge dust back into the environment.
With the fans blowing in, all the dust is on the inside of the box (and on the fans).
Something to note: Certain service providers (e.g. Twitch) will not allow you to sign up using an '@mailbox.org' email address. I do not know if this ban extends to custom domain addresses.
The downside is that AM4 is basically EOL, so no upgrade path.