I’m talking about the text in the “The problem with async” section in the article you linked in the OP.

Unless you specifically want ebuilds, take a look at nixpkgs dockerTools. It does everything you list here.

https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-dockerTools

IPFS maybe

Can we stop referring to the “what color is your function” post for languages it doesn’t apply for? Contrary to Javascript (where it does apply), Rust with tokio has adapters for both async -> sync (Runtime::spawn_blocking) and sync -> async (Runtime::block_on). It probably isn’t a good idea to overuse spawn_blocking but calling an async function from a sync one is literally no problem.

It was added in v256, maybe you don’t have that yet

official knife post

Another tip: take a look at systemd-networkd for managing your network connections! It has builtin support for creating wireguard tunnels and it’s very nice.

It would be interesting to make a Lemmy fork that doesn’t require login and registers all posts as anonymous@(instance). Would probably get insta defederated by every other instance though lol

Take something with KDE Plasma. I have mine set up to work as close to Mac as possible (command key as the main modifier, all the Mac shortcuts for the window manager and KDE applications, top menu bar, dock, probably more). Took a bit to set up but now it doesn’t nearly throw me off as much anymore when switching between the two.

unofficial Discord

Join the support room on Matrix, really helpful people in there. (And it’s official and not Discord)

I’m going to write (at least part of) the script first anyway, and then I can just use chmod +x after the file is saved which is shorter.

install -m755 /dev/null target was the first thing I thought of. I would never use this but it is a single command.

Yeah, but it isn’t noticeably “less stable” if at all anymore* unless you mean stable as in “essentially in maintenance mode”, and clearly good enough for SLES to make it the default. Stop spreading outdated FUD and make backups regularly if you care about your documents (ext4 won’t save you from disk failure either which is probably the more likely scenario).

* not talking about the RAID 5/6 modes, but those are explicitly marked unstable

We’re not in 2014 anymore.

It’s definitely on my Linux bucket list. I’ve been kinda thinking about making a distro myself (specifically because I want to try some unusual and niche things in terms of system layout and package management), and that would be a good starting point.

It’s not the default fwiw. From journald.conf(5):

By default, only forwarding to wall is enabled.

Set ForwardToSyslog=yes in journald.conf and install a syslog daemon. Also optionally Storage=volatile (I wouldn’t set Storage=none unless you want systemd to no longer show you any logs anywhere including in systemctl status because I assume it will do that)

That’s a pretty outrageous claim. Any proof for that?

The same argument can be made for any OS. Same packages, same hardware, same configuration, and probably it would be the same.

Only if we’re talking about 1:1 disk image clones or installing stuff on a fresh system.

https://nixos.org/

That is clearly talking about build-time dependencies and the build process given the context (maybe the word “work” here is misleading though, also because some packages don’t even have parts that can “work” or “not work” like wallpaper packages). It is impossible to automatically ensure all runtime dependencies are met, because that would require analyzing what the program actually does. I can write you any number of Nix packages that will only run on my computer (simplest case is because they load a file from a path from my user directory or something), but the thing that Nix ensures is that you can reproduce the package contents on your system as well.

That said, in a lot of cases, nixpkgs does actually (manually) patch runtime dependencies to use store paths which sets up that dependency relation, but with KDE PIM stuff this would lead to dependency cycles if done the typical way, for example KMail depends on Akonadi to build, but Akonadi loads plugin files from KMail when it is installed. This is not something you can do, so to resolve that cycle, you need another package which depends on both and links them together so they can see each other at runtime. Right now the entire NixOS configuration (or rather, whatever the environment.systemPackages option affects) assumes the role of this third package, but it would be nice if was done in in a more self-contained way, so that you could also reasonably use this stuff outside of NixOS.

Not at all, given we’re running probably significantly different configurations. With the same configuration we’d get the same results, and NixOS never claimed to eliminate what is essentially packaging bugs related to runtime dependencies. KDE stuff (and especially anything Akonadi-related) right now needs a lot of plugin path environment variable mess to work with NixOS’s file structure because it loads a bunch of stuff at runtime from other packages, which can break in strange ways like this if you don’t add a specific package to your system packages for example, it’s definitely not ideal the way it is right now but it’s also pretty hard to get right.