My understanding as a NixOS user is a lot of its fundamentals are very strongly coupled to systemd. It’s responsible for things like running system activation scripts and managing any services it exposes options to, so replacing it sounds like a tall order.
I’m not aware of any Nix-based alternatives, but I’d definitely welcome them! Oh and also, as others have pointed out, Guix might fit the bill depending on your needs.
What this guy/gal said. Linux user for 25 years here, 10ish of which have been exclusive. And I run Mint on my main PC.
Because when I can finally wind down after the kids are in bed and I can hear myself think, I just want shit that works, without having to dick around with manual kernel modules and other custom stuff to get basic things working … I get paid to do the latter at work, and I get enough of it there.
the init is just a binary, the others systemd features are different programs from different binary, and you are not forced to use them, you can use only the init and don’t use the others, it’s not gonna affect security, systemd init is the most tested one
and you can’t, a lot of technology that make NixOS and others immutable distros works exists only because of systemd
and if others init system worked as well, the entire of the linux community would not have changed voluntarily nor indenpendently to it
What do you think of some day seeing a fork of nixOS that uses other init systems and works well? Or is it just me that likes this idea?
doubt, is too much work just to make a systemd alternative, without the reliability and support that systemd have, but i think it could be a fun hack
Because the nix package manager places all system packages under /nix/store/uniquehash-packagename-version/
Where the unique hash is obtained via a Merkel tree of all the inputs. So in particular, binaries and libraries exist underneath those directories, not in the places you would expect from FHS.
In order to make the system actually work, environment variables are set up and executables are patched to refer to specific paths within the Nix Store.
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 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.
Now you’ll have a zillion users trying to install software in ways that violate all the assumptions that NixOS operates on, but which are still tightly coupled to your NixOS config. Now updates to your system, or even seemingly unrelated config changes (through some transitive dependency chain) can easily break that software.
So now we’ve basically removed half the advantages that motivate Nix/OS in the first place, and when stuff breaks it will look like it’s Nix’s fault, even if it isn’t.
On the other hand, nixpkgs is already the most comprehensive repository of system software out there, and for 99% of packages Nixifying it is pretty trivial. Hell, my NixOS config does that for 3 different GitHub repos right inline in my config.nix
If you put an FHS on the actual system you wouldn’t be able to install multiple versions of the same package, updates wouldn’t be atomic - you wouldn’t get the big selling points of Nix.
Bitwig was created by some of the people that built Abelton Live. Bitwig is considered by many to be the best of them all and easier to pick up by beginners. I plan to try it on Linux before I decide if I make the jump from Abelton.
You may be interested in reading this post about the process of packaging Steam.
tl;dr: It’s mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that’s the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.
I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).
The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe. In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
It’s just that most (if not all) build system in the source code package would assume some level of FHS compliance.
For example, they would install:
executables under /bin /usr/bin
libraries under /lib or /usr/lib
sysconfigs under /etc
manpages under /usr/share/man
and so on…
These build systems would include options to change these, but you’d then have to change all these values to adapt to nix structure. While it’s all been done by the nix package maintainers, you’d have to do all that if you’re to come up with a new package.
In the FHS compliant distros, the maintainers wouldn’t need to change anything since these values are already set to the values they want (there are actually minor details they’d change, but that’s another topic).
If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe.
It’s the same for Nixpkgs.
In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?
In well behaved build systems, it’s likely easier to package than most other distros. If it’s not as well behaved you will have to do some “exploration” and the complexity can get quite out of control if the build system is exceptionally terrible.
Here is the package for the GNU hello program which uses a well-behaved build system:
If you ignore the optional passthru.tests, this is very simple. You provide metadata, sources etc. to the generic mkDerivation function and that’s it. The most complex non-standard thing this derivation does is enable the build system’s tests.
You don’t even need to run the provided build instructions because Nixpkgs’ stdenv abstracts those away. If it finds a makefile, it’ll automatically run make and make install with the correct flags for instance. Same for other standard build systems; if you pass cmake into nativeBuildInputs, it’ll attempt to build, install, check etc. using cmake’s standardised interfaces.
If the build system is poorly behaved however (like for instance Anki’s), you will have to get into the weeds and do some rather advanced things:
unrelated but does Ableton work with Linux yet? I did a quick search and someone says it works “flawlessly” but the comments indicate this is not true.
Welcome, friend! Glad you decided to try out and stick with Mint. That’s the distro I used as my daily driver for at least 1.5 years. When you have a chance, do try out some of the other Linux distros, especially Arch!
+1 here for the arch recommendation as an ex ms sys op. Browsing their repos was outstanding for retooling, most of the config problems you hit are a great way into the ecosystem.
If you decide later to test other distros I would highly recommend using a virtual machine in virtualbox. Saves the hassle when it comes to testing distros 👍
KVM is indeed a much better hypervisor, but it does require some setup with the terminal.
Since he is a beginner I decided to recommend virtualbox since it just works after installing. But if he doesn’t mind setting up things via terminal then KVM is definitely the way.
@agr8lemon The other person mentioned virt-manager, but there’s a much more easier app: Gnome Boxes. It uses the same backend (libvirt/KVM) but it’s much more easier to use - in fact, I’d say that it’s even more easier to use than VirtualBox. For starters, Boxes automatically detects OS ISOs on your drive and allows you to just click on them directly to install it - or you can even choose to download and install a distro directly from within Boxes. Also, when you consider the post-setup phase: there’s no need to install any guest modules/drivers because it’s already built-into Linux distros.
I’ve worked extensively with both virtualbox and kvm/qemu. While I prefer kvm since it’s open source, I could never reproduce the video performance of virtualbox. I’m not even trying to game, just use regular applications that I cannot run under Linux.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.