One thing I didn't find is Guix on servers. I am all-in on NixOS for both my daily driver desktop and couple of servers, and adding more of either will be simple modifications to my flake repository. I really appreciate that simplicity and consistency. Does Guix offer that?
The other thing is package availability: it's amazing on Nix. Plus, they remain relatively fresh on the unstable channel. How's that on Guix?
The vast majority of what you’d want in a Guix server can be found in the services section and parts of the documentation that lay out how to build services. But it doesn’t have as many services available as nix.
I started a project with nixos-anywhere, deploy-rs, and compose2nix. However, I struggle a bit with secret management.
Alternatively, you can set up a secrets service (like a password manager/vault) and source from that. Difference is where the secrets live (encrypted store or networked service, with all the consequences of every approach), commonality is that they’re fetched at runtime, before your programs start.
I’m currently using deploy-rs, but if I’d redo my stuff (and the only reason I don’t is that I’m pretty much overwhelmed by life) I’d probably go with plain vanilla nixos-rebuild --target-host and skip any additional layers (that introduce extra complexity and fragility).
Just a crude and somewhat haphazard summary but hope it helps.
https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix...
I've embraced daily shallow clone/fetches and the burden is now mostly just the 2GB of disk space.
It's a bit annoying though that git doesn't make it easier. No one would shallow clone later screw up and download every commit anyway, I feel shallow clone repos should be set up with a different configuration that fully-embraces shallow history (not that the configuration options even exist today AFAIK).
git clone \
--single-branch \
--shallow-since '-2 hours' \
--origin 'upstream' \
gh:NixOS/nixpkgs
git fetch \
--shallow-since '-2 hours' \
upstream \
master nixos-unstableGuix potential target IMVHO should be desktop power users, not HPC, NixOS while mostly developed for embedded systems (Anduril) or servers in general still take care of desktops, Guix apparently not and that's a big issue... Nowadays outside academia I doubt there are many GNU/Linux users who deploy on plain ext4...
No one is going to write a blog post titled "Why I just used the default filesystem in the installer" but that is what most people do. Things like btrfs and zfs are useful, complicated technologies that are fun to write about, fun to read about, and fun to experiment with. I'd be careful about assuming that leads to more general use, though. Its a lot like Guix and NixOS, in fact. They get all the attention in a forum like this. Ubuntu is what gets all the people, though.
> - guix (additional patches are used locally for root on ZFS support)
i'm hopeful too, but think it may not be so simple (yet) >u< here's a more precise link
https://codeberg.org/guix/guix/pulls/1917#issuecomment-69760...
Modern NVIDIA drviers. Let me fix that for you.
Intel and AMD has their full stack in mainline already, and AMD made great effort to enable their cards fully under open source drivers, as their agreements and law allows. You can even use HDCP without exposing sensitive parts, if you want.
Intel also works completely fine.
However, NVIDIA's shenanigans and HDMI forum's v2.1 protectionism is something else completely.
- An open source kernel module which talks with the card.
- A set of closed source GLX libraries for acceleration support.
- A signed and encrypted firmware which only works with this closed source driver package to enable the card.
Nothing is OK about that.
Well, having a driver agnostic closed source firmware is pretty different from an end-to-end closed chain with a driver-authenticating firmware.
Also, while fglrx had some serious problems, they didn't wait two years to fix DVI DPMS issues like the green company.
Yes, neither are open hardware at the end of the day, but we have almost infinite number of colors and infinite shades of gray. Like everything else, this is a spectrum.
As I aforementioned, I'd love to have completely free hardware, but the world's reality works differently for many right and many wrong reasons. I'd prefer to use most open one I can get, in this case.
But at the same time (adding more shades of color), part of the reason why Nvidia remained closed source for longer was precisely because they were supporting all the same features on both windows and Linux, while amd's Linux was (is?) always lagging behind. For ML use cases basically the only choice was Nvidia.
(Nonetheless, I was very happy with my amd card, and now I'm very happy with a semi-modern Nvidia card)
That's something like what they're describing as "a nightmare," isn't it? "As agreements and law allows," is part of the nightmare. Under a modern OS, it should not be difficult to have the full capability of the hundreds or thousands of dollars worth of hardware you paid for.
Having a completely Free Software firmware would be great, but I'm not sure barrier to this is as low as Free Software since there's involvement of IP blocks, regulation, misuse of general purpose hardware (like radios) and whatnot.
I really support an end-to-end Free Software system, but we have some road to go, and not all problems are technical in that regard.
> With Nix, however, it was a matter of just describing a few packages in a shell and boom, Ruby in one folder, no Ruby (and thus no mess) everywhere else.
This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really).
> I started adding shell.nix files to all my little projects
I appreciate that NixOS brought good ideas to Linux here; having reliable snapshots is good. If a user has a problem, someone else might have solved it already, so you could "jump" from snapshot to snapshot. No more need for StackOverflow. The HiveMind took over.
But with all its pros, the thing I hate by far the most in NixOS is .. nix. I think the language is ugly beyond comparison; only shell scripts are uglier. I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead? Or simple config files? I am very used to simple yaml files; all my system description is stored in simple yaml files. Since +20 years. That approach works very well (ruby expands these to any target destination; for instance, I have aliases for e. g. bash, but these are stored in yaml files and from that ruby then generates any desired target format, such as also cmder on Windows and so forth).
> In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme.
I am glad to not be the only one to dislike nix, but boy ... scheme? Aka Lisp? Seriously???
Young people use lisp? I somehow doubt that.
(cons* (channel
(name 'nonguix)
(url "https://gitlab.com/nonguix/nonguix")
Why would users know what cons* does, anyway? That's stupid.
YAML files exist for a reason. Keep. Things. Simple. (I know, I know, many use YAML files in a complex manner with gazillion nested indentation. Well, they are using it in a wrong way, then they complain about how bad yaml is.)
> Since the code is pretty much just Scheme and the different mechanisms available are fairly well documented (see caveat below), the barrier to entry is much lower than with Nix in my opinion.
Can't evaluate this. To me it seems as if NixOS may have changed, but Nix was always a big barrier. I decided to not want to overcome it, since I did not want to be stuck with a horrible language I don't want to use.
Nix already existed in 2003. Besides that Nix store directories are more ingenious than versioned application directories (or hashed directories), the hash in the output path is the hash of the normalized derivation used to build the output path (well, in most cases, let's keep it simple). Derivations work similarly (also using hashes). Moreover, since a derivation can contain other derivations as an input, the Nix store represents hash/Merkle trees.
This makes it very powerful, because you can see which parts of the tree need to be rebuilt as a result of one derivation changing.
But with all its pros, the thing I hate by far the most in NixOS is .. nix.
I think it depends on your background. I did some Haskell at some point in my live and I like Nix. It is a very simple, clean, lazy, functional programming language. The primary thing I'm missing is static typing.
I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead?
Because what nixpkgs does is not easily expressible/doable in Ruby. First, the package set is one huge expression in the end. That might seem weird, but it allows for a lot of powerful things like overlays. However, for performance reasons this requires lazy evaluation. Also other powerful abstractions require lazy evaluations (e.g. because there are some infinite recursions in nixpkgs).
Second, the Nix packaging model requires a purity (though this gap was only properly closed with flakes). You have to be able to rely on the fact that evaluating an expression evaluates to the same result. Otherwise a lot of things would break (like substitution from binary caches).
Third, things like overlays rely on fixed points, which can be done easily in a lazy functional language.
---
Having used Nix for 8 years now, I have a long list of criticisms as well though :).