"con's" on their homepage, all which are fighting for an increasingly miniscule userbase, heightening a war which never should have existed in the first place. We see this now manifest in 100 different application distribution formats, all of which have giant tables of "pro's" vs. Flatpak is an attempt at a technical band-aid for a social and cultural problem, but that culture only makes the problem worse, and the solution ineffective. and deprecating everything before them (though I note this is not strictly a Linux problem, we've seen it in npm/pypi/rubygems and we're even now seeing it from even big vendors like Microsoft, Apple, and Google, but it tends to be more associated with FOSS/Linux communities). Immutability is good, splitting the OS from the applications is good, but what that should imply is a commitment to not break anything, and that's not something you can really wrangle from open-source contributors, who are more interested in writing v7, v8, v9, etc. It's often easier for them to script something completely from scratch in python then figure out how to stitch coreutils together.Īs a former member of the Red Hat desktop team who helped kickstart several of these initiatives (I did a huge chunk of Wayland, before I passed the reins off to Jonas Adahl), I believe in the vision, but like many other things in the Linux space, it's fighting a very uphill battle for a vision that I personally believe is good, but I can't ever imagine coming true, and when it does, one that's far too late. I've been doing this for 20 years now, so I've very comfortable with Linux/Unix tooling. It is not unreasonable for the uniq to have a count tool, or for sort to have uniq. But there are natural boundaries for things to exist. Having one tool do literally everything is also unreasonable. You then need to learn a completely different thing to do another basic operation. The problem with "do one thing and do it well" is that very often you need to do more than one thing. The "unix philosophy" isn't very true on Linux, and hasn't been since GNU. So nix does one thing and does it very well. This enables NixOS and nixpkgs to exist, and they have much longer manuals: The properties of Nix allow for everything else. You can see that manual for Nix is actually fairly short: That one thing is building packages in sandboxes and adding them to the nix store. Nix is actually a very simple tool, that in fact only does one thing and does it well. Wikipedia claims that NixOS's initial release was in 2003. One thing NixOS has going for it though is currently having many more users than Silverblue has if comments on HN are any indication (and they probably are) which is probably an effect of its having been around a lot longer. (I know enough to know that it is unlikely that I would need to learn the aforementioned Nix-specific functional programming language to do the translation, but there are many other pieces of Nixos I would need to master.) I ran NixOS as my daily driver for 2.5 months earlier this year, and I got nowhere close to learning enough about it so that I had a decent chance of being able to translate a solution published on the web that works on most other Linux distros into something that works on NixOS. If you search the web for a solution to a Linux problem, translating the instructions (and an example of what I mean by an "instruction" would be, "add to this config file these lines of text") into instructions that work on NixOS is impossible unless you know a lot about Nixos. "The same exact tool" as you refer to it has a very high learning curve and includes for just one example its own functional programming language.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |