4 ms·
> What does that mean? > It absolutely does on NixOS, which is all I have looked at. files in /etc are still where you would expect them to be, files in /var ar
by licebmi__at__ 2y ago
> What does that mean?
> It absolutely does on NixOS, which is all I have looked at.
files in /etc are still where you would expect them to be, files in /var are still where you would expect them to be, files in /boot are where you expect them to be.
You won't find stuff on /lib, /usr, or /bin but even if you did, well it defeats the inmutability if you could just manipulate them, which is pretty much the purpose of nix.
This is my problem with your article, so you can map these files with nice names; now what? want to hack something with them?, then why use a declarative system? want to manually modify them? then why use an inmutable system? It totally defeats the purpose of nix. Thus my opinion, and not trying to be dismissive, that you don't understand what nix is trying to do.
> I suggest reading the comments on the article, which it seems to me are strongly in agreement with my points.
I just did on your suggestion, and I'm not impressed. The top comment is saying that if the OS get's borked they restore from backups, so not interested in software generated paths... which hey, it's a valid workflow if it works for that person, yet the whole point of a declarative system is that you can rebuild your system in mins without any backup.
That's my whole point, I don't care about where the packages are, they could even come from a magician hat, what I want is to be able to write a configuration of the exact packages that I want and that it actually works instead of some mess like ansible/salt/whatever. I don't particularly care about isolation, even if that's kinda the reason why the system works, if I were interested only in isolation or running multiple versions of software I would just use containers.
> In other words: it gives isolation and the concurrent versions, but it does so via more complex packaging tools that need users to learn a whole new programming language, and it eliminates the familiar FHS and replaces it with a new flat programmatically-defined one that is almost unreadable to humans.
I agree that the packaging tools (nix lang and underlying scripts) are complex, that might be something to fix, but I fail to see how knowing the path of packages works to do anything but to encourage the mess that people who love nix try to avoid.
- lproven 2y agoSeveral points to this. 1. It's "immutable" not "inmutable". 2. There are lots of immutable distros without Nix. Fedora CoreOS and Atomic. Ubuntu Core. EndlessOS. SUSE MicroOS. Immutability is irrelevant here. 3. You miss the point that the commenters were making: it's necessary to be able to fix computers when software goes wrong. This is the entire basis of a global trillions-of-dollars industry and most of my career for a third of a century. This is not a "nice to have", it is a 100% cast-iron REQUIREMENT. 4. If being declarative is so important, then explain WHY because most of OS design isn't, and yet somehow they have been working for 60 or 70 years now. It's like functional languages: none of the fans can be bothered to take the time to explain why they are so good, and as a result, nobody cares. http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-... 5. You may not care about isolation, but I am telling you: the rest of the IT world cares a LOT. I predicted the rise of containers in 2013, before Docker was founded: https://www.theregister.com/Print/2011/07/18/brief_history_of_virtualisation_part_3 https://www.theregister.com/Print/2011/07/18/brief_history_o... (I think it was this one.) Isolation is huge and vitally important and in the field of Linux it's worth billions. If Nix offers radically new and better methods then it needs radically new and better explanations because there are lots of existing methods and they work fine. You seem to be addressing side issues and niggles to me, and avoiding confronting the core thing. Being able to read, understand, navigate and maintain the filesystem hierarchy is a keystone of Unix. If you want to remove that keystone then you must have extraordinarily good reasons, and after reading tens of thousands of words of discussions of Nix, I am not convinced the reasons are good enough. I think a human-readable filesystem could be retained, and improved over existing designs, while also delivering declarative generation and management. I am trying to point this out, proposing examples and mechanisms, and you (and the wider Nix community) are not addressing it. Instead, the world is saying "we really want this and we will not give it up" and the Nix folk are not listening.