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.
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.
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
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.
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.
OP said they were not looking for Ubuntu or Arch derivatives, and that they were not afraid to get their hands dirty to figure things out. Slackware + Flatpaks can give a stable base while giving you up-to-date applications when SBo doesnt have the build files. This would give OP a system that just works OOTB. Tho it is KDE OOTB, one can put gnome or cinnamon on it.
“Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd “cloud of daemons” is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn’t manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn’t want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.
And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy.”
err, why would a forum post single-handed prove that the entire linux enterprise world are being stupid, and how you can prove that he is even correct?, he is alone, against the entire world, red hat sell that shit, if it wasn’t secure companies wouldn’t buy it
I am not saying this proves single-handedly that systemd has vulnerabilities but it is one of probably many out there. I am not saying enterprise is stupid but I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.
I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.
I’m not sure how much time do you think anyone spends setting up systemd utilities… but as a home admin systemd has saved me a ton of time over the ragtag collection of shell scripts we had in the past. And a lot of that is because of its vastly improved logging.
I suppose if you consider logs to be “bloat” you won’t understand though. I consider them to be essential services.
I was saying that you do spend less time cause it is already there. Also you can have logs on other init systems, what I said on the post is that if later I wanted logs I could just setup instead of being already there (and the other utilities, not just the logs of course).
s6/66 simplifies dependency of running/starting, automatically enables an s6-log for each service/daemon/bundle it is much faster and smaller than systemd (by a factor of 10 maybe), and once it is up and running it is virtually impossible to bring down without its own routine. Servers have run consistenly for a decade with s6, including skarnet.org
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.