It’s not that far-fetched, PDFs in my opinion are closer to vector graphics than to document formats like odt and docx. They have no understanding of format if not using advanced features, like a table in a PDF is just spaced text with lines between them, and text is just independently placed letters. In fact the space symbol doesn’t exist in most PDFs, it’s just that two letters were spaced further apart. So they basically are multiple canvases that are being painted on with letters, lines, fill areas and even bitmap graphics.

Modern PDF actually does further in the direction of a document format by providing the content in a structured way, mostly for accessibility, but also for making the format suitable for automatic processing the contained data.

Then those containers or virtual machines should add this or create the home as needed.

systemd has its own containers, so this is the implementation of that requirement; “virtual machines” might use this exact binary to create home, among other directories like srv and what not. Someone at one point probably said “we always need to create these when spinning up systems, maybe systems can provide a mechanism to do that for us?” and then it was implemented.

Having/home listed as a tmp file on regular systems is problematic by the nature of what tmpfiles claims it does.

systemd-tmpfiles claims the following:

systemd-tmpfiles creates, deletes, and cleans up files and directories, using the configuration file format and location specified in tmpfiles.d(5). Historically, it was designed to manage volatile and temporary files, as the name suggests, but it provides generic file management functionality and can be used to manage any kind of files.

I rather think having a purge command was the issue here, at the very least it should print a big fat warning at what it does, better even list all affected files and directories. There’s no reason a normal user needs this and with the name of the binary, it’s totally misleading, which is an issue in these situations.

E.g. for quick provisioning of containers or virtual machines, this is also to make sure the required directories always exist. In a normal distribution, /home already exists, so systemd-tmpfiles does nothing, but there are cases where you want to setup a standard directory structure and this is a declarative alternative to scripts with a lot of mkdir, chmod and chown.

The name systemd-tmpfiles is kind of historic at this point, but wasn’t changed due to backwards compatibility and all.

Which he can borrow cash against

less comes with all distributions I know

What are you using right now?

https://peanuts.fandom.com/wiki/Football_gag

Mostly holding Nano, used Monero quite often - should probably spend some Nano at one point… But vendors accepting it here are rare

Omg we’re cryptocurrency twins. I hold exactly these two for the same reasons

I know you’re joking anyways, but I always cringe when I see that. There’s no need to invoke su there. If you want a root shell, use sudo -s or sudo -i depending on what kind of shell you want.

There’s a keepassxc-full package that comes with all the functionality. Anyhow, Debian does not have the concept of USE flags, these don’t make sense in a binary-based distribution.

NixOS: (1, 2) - You can define specific package versions but with the large repos I doubt there is much QA going on

It depends on the nixpkgs channel you use (I’m also using the term for flakes here, though technically these are then called inputs). The main channels, those being NixOS-stable whatever the current version is at the time and NixOS-unstable have a rather big set of packages that must be built successfully before users get updates, including the tests defined in the build system plus sometimes distribution-specific tests, though these are often rather simple, like start program and see if its port is open. Even more, when a library gets updated, all programs and other libraries depending on it get rebuilt as well, including all tests.

Now what if a package outside of that scope breaks? Most likely, your new configuration won’t build, so you’re stuck on an older but working configuration, or it does build, but something doesn’t work. But I’m the latter case, you can still choose to start the older working configuration.

Also the more complicated packages have very dedicated and capable maintainers from my experience, sure the smaller stuff is often updated mostly automatically with merge request created by bots and just the final merge approved by the maintainer, but the big infrastructure is usually tested quite well.

As a downside, this can sometimes lead to longer periods without updates when a lot of stuff has to get rebuilt and something doesn’t work (multiple days, but not weeks). You can then switch to another set in case the problematic packages don’t affect you, or just wait. However, saying there’s little QA is unfair, in fact from my experience there’s more QA in nixpkgs than in most distributions.

I don’t recommend NixOS to new users because it abstracts a lot of stuff away and makes use of mechanics that are helpful to understand first. But if you’re comfortable with Linux, NixOS is a great distribution that even on unstable works very well. Then again, it allows specific packages to depend on very specific versions of other packages, which is partially the reason you’d use a stable distribution.

I can’t tell if this is actual advice or irony

This is a fork or other form of replacement for nix as in the package manager. It does not replace NixOS, but can be used on NixOS and Darwin.

Yeah weird in that regard that a car wash can render it non-functional if you forget to put it into car wash mode

I initially thought it was a joke

Yes! Apologies, didn’t proofread what my phone produced from swiping

NixOS has the best concept and even pioneered it, but whether its implementation and documentation is perfect is a topic for debate.

However, it’s been quite long since I had to fiddle with my config and as such, the downsides don’t really affect one on a daily basis. In fact, I recently reinstalled my machine to change the root filesystem and it was an absolute breeze. If not for secure boot, it would have been absolutely trivial, and with secure boot it was easy and convenient.

As such, I consider the pains an investment into system that runs much better down the road. Though I’d love it if these pains were reduced.

nixpkgs is holding out with it because it’s part of the current GNOME 46 draft pull request: https://github.com/NixOS/nixpkgs/issues/282102

Though I agree it’d have made more sense to migrate to freerdp 3 earlier and have two versions available, like with pipewire.

There’s also a nix file in that discussion with a more recent version.

NixOS, did a ldd (which zstd) and then ldd on the reported libzstd file.

Not using a POSIX shell before people complain about syntax

Edit: if you look at https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/compression/zstd/default.nix, you’ll see that buildInputs is not being set, which means it can’t link to anything except the standard libraries.

Maybe Debian’s goal is to make liblzma a dependency of everything possible? It wasn’t a standard dependency of OpenSSH either, but rather something they patched in. ;)