My system is configured that way (by me) and I regularly use sudo -s.

I just want to see if there’s a root shell and not rely on some hidden timeout 🙄

https://github.com/iptv-org/iptv ?

That’s a German beer bottle…

So they were aware of it needing repairs and let their president fly anyway? 🤔

Wait. That’s a real picture…?

Imho there’s a difference between “people abuse it” and “it is possible for programs to use software that they shouldn’t even find”. Anyway I noticed just now you weren’t the one to actually ask the initial question of whether it’s technically possible, so I apologize for not noticing this earlier. However I think it’s a meaningless endeavor to ponder whether or not it’s possible when that fact is irrelevant.

It’s not that it’s hard to do. It’s that it goes directly against the idea of NixOS since it breaks the separation. With NixOS I can start a shell in a different iteration of my system without switching over the whole system. If I had all my software installed into standard places, that shell might find things it’s not supposed to find.

Bottom line is: Most things work on NixOS out of the box. The PATH variable is adjusted accordingly to what a program is supposed to find, which in my opinion is perfectly reasonable and enough for software to find other software. The dynamic library paths are hardcoded as absolute paths, so software can find it’s libraries. There’s a special dynamic loader for binaries that don’t adhere to this. And if you really need an FHS compliant environment NixOS gives you the tools to create one in a sandbox.

You can either have the perks of NixOS or use an FHS compliant distro. That’s your choice.

Conflict resolution was not my point. Rather the question which the “most recent” between two almost identical installations…

Choosing the most recent one might be impossible if you have multiple installations of the same package with same version but different features enabled during the configure step.

Nix installs derivations into separate folders. A derivation can be a package, but can also be other things like configuration files, scripts or sources for packages. Nix doesn’t distinguish between these derivations by a name but rather by a hash created from their build instructions.

For example two instances of the same package with a different version are two different derivations and thus nix can have both package versions installed without them interfering with each other. But this goes beyond just a package version. It is e.g. possible to have the same package with the same version but different patches applied, or relying on different versions of dependencies. Since their build instructions differ both can be installed simultaneously.

This approach grants a variety of advantages. For example upgrading your NixOS system just installs new derivations of packages and configuration files that have changed, while keeping previous derivations until they’re garbage collected at a later time. This allows you to switch freely between both iterations of your system, for example if an update causes issues you can just revert back to before an update easily. Another advantage is that an unprivileged user can install packages they need without interfering with the rest of the system, for example an older python version or a newer one, or some software they want but the system does not provide.

The price of having this kind of isolation between packages is that nixos cannot install binaries and libraries into common locations. Effectively /usr/bin only contains the env binary. If you’re familiar with shell scripting you might have run into lines such as #!/usr/bin/env bash. This env util will essentially search bash in your PATH variable and start it. Lines like #!/bin/bash however will not work, because there’s no bash installed in that location.

Another case where a missing fhs is a problem is when using pre-compiled binaries. In contrast to binaries built through nix, which have their required libraries hardcoded as absolute paths, pre-compiled binaries you download usually only contain the name of the library they need, which works in a conventional fhs environment, because these libraries tend to be found in /libor /usr/lib. On NixOS neither of those are present. There two solutions to this. Either you create an fhs environment by listing the set of derivations to be symlinked into a chroot environment which mimics an FHS. Or you can install https://github.com/Mic92/nix-ld which automatically finds the required libraries the nix way if you start such a binary. There’s also steam-run which installs an fhs with most of the dependencies necessary to start Linux games from Steam.

Imho I wouldn’t bother with nix-env or nix profile. It just creates a secondary list of packages that needs to be maintained and it’s cumbersome to do so. There’s nix-shell or nix shell if you need a package temporarily and there’s your configuration.nix or flake for everything else.

Side note: nix profile at least has consistent commands: install/remove/upgrade

First of all: Did you do apt dist-upgrade as well? If I remember correctly that is a new required step when upgrading to a new Debian release.

If that doesn’t help, you could check if your nvidia-detect package version is the expected version, that comes with Debian 12.

If neither of these steps help you could disregard nvidia-detect and try the steps listed in the following link. It seems the firmware was moved to a separate repository compared to Debian 11. You might need to add that by hand. https://wiki.debian.org/NvidiaGraphicsDrivers#bookworm-525

Your i3 is too old. Perhaps your distro’s repository has a package called “i3-gaps” which was the former fork that implemented this feature. i3-gaps was merged back into i3 in the meantime.

Since i3 4.22, you can configure window gaps.

https://i3wm.org/docs/userguide.html#gaps

Convoluted name and a lot of null bytes? Sounds like a temporary file used during downloading.

Maybe they did, but now you can view that data too? It’s Facebook after all…

Thank you for proving my point.

Oops 😬

I doubt other init systems can make the screen bigger so that the vital part of the kernel log is still on screen, but be my guest to prove me wrong 🙄

None of what’s visible helps identifying the error. Try journalctl -xb as suggested it might show more relevant information

Edit: oops should’ve been joirnalctl instead of journal

author: has Master’s degree in engineering

also author: “Let’s write a blog post about how to enable a systemd service”