Recent searches
Search options
@bookwar@fosstodon.orgFrom @zbyszek on Discussion forum:
https://discussion.fedoraproject.org/t/containerfiles-considered-harmful/146812
I haven't used mkosi tool, but I do share a sentiment on Containerfiles being unmanageable.
@bookwar @zbyszek
> We want a declarative configuration
Yes! Yes!
> with key-value settings
No-o-o!! No, no, no! Just spend a week with #NixOS already before reinventing the wheel, I beg you. There's no key-value schema that'd get you an rsyslog compiled and running against a patched gnutls, let alone any actually complicated system setup.
There's simply no building a configurable scriptlets-free system without a powerful, flexible system composition mechanism like NixOS module system. That thing that composes loose packages into a configured image according to a spec *is* the distro. 20th century distros could skimp on that by showing those into scriptlets of random packages, extracting it into runtime configuration ugliness like crypto-policies and forcing users to hammer their systems into shape by imperative scripts like bash or Ansible. A 21th century immutable image-based distros is configuration system at heart. The flexibility of image composition is the flexibility of the result. Unless you're designing a bespoke dumb appliance with a dozen of parameters, there's no handwaving the centerpiece of its design as a bash script, Containerfile or an ini file.
It hurts so much to read such texts. NixOS is 21 years old. Declarative configuration, true composable cacheable immutability, seamless overriding 100% of the package building where needed, building dozens of image formats, declarative VM management, impermanence, factory resets, rebootless change application — those few of the above that weren't solved back in 2003 were solved last decade. Wanna know where do can-do attitude of "I'll willingfully ignore all those lessons and hammer Fedora into shape in order to emulate the fraction of the desired NixOS properties" leads? One smart engineer did just that, very recently. Now we have bootc, Containerfiles for a configuration mechanism and systems where we can' t even securely distrust a root CA in a way that survives an update.
> We want a declarative configuration
Yes! Yes!
> with key-value settings
No-o-o!! No, no, no! Just spend a week with #NixOS already before reinventing the wheel, I beg you. There's no key-value schema that'd get you an rsyslog compiled and running against a patched gnutls, let alone any actually complicated system setup.
There's simply no building a configurable scriptlets-free system without a powerful, flexible system composition mechanism like NixOS module system. That thing that composes loose packages into a configured image according to a spec *is* the distro. 20th century distros could skimp on that by showing those into scriptlets of random packages, extracting it into runtime configuration ugliness like crypto-policies and forcing users to hammer their systems into shape by imperative scripts like bash or Ansible. A 21th century immutable image-based distros is configuration system at heart. The flexibility of image composition is the flexibility of the result. Unless you're designing a bespoke dumb appliance with a dozen of parameters, there's no handwaving the centerpiece of its design as a bash script, Containerfile or an ini file.
It hurts so much to read such texts. NixOS is 21 years old. Declarative configuration, true composable cacheable immutability, seamless overriding 100% of the package building where needed, building dozens of image formats, declarative VM management, impermanence, factory resets, rebootless change application — those few of the above that weren't solved back in 2003 were solved last decade. Wanna know where do can-do attitude of "I'll willingfully ignore all those lessons and hammer Fedora into shape in order to emulate the fraction of the desired NixOS properties" leads? One smart engineer did just that, very recently. Now we have bootc, Containerfiles for a configuration mechanism and systems where we can' t even securely distrust a root CA in a way that survives an update.
@SrEstegosaurio @bookwar @zbyszek This one is this but second-order: complaining about what already is a bold new NixOS-but-worse, insightfully highlighting it's totally predictable flaws to then envision a better NixOS-but-worse, casually stopping for an unprompted tangent that proceeds to describe most of the cool Nix properties down to such minutiae like zero-copy installation... But no, a key-value store in lieu of a configuration system is the new 640KB, ought to be enough for everyone.
Maybe Greenspun's tenth rule needs a lemma about sufficiently configurable systems (whether operating systems or other).
en.wikipedia.orgGreenspun's tenth rule - Wikipedia
@bookwar @zbyszek
The package building segment really grinds my shattered heart debris into the asphalt. Like, wouldn’t it be nice if, upon finding out your chrony is compiled without a feature you need, you could just quickly take a custom one compiled --with-missing-feature for a spin? Take a dive from the system configuration language and right into the intricacies of its autotools-driven compilation process? Guess what, that’s a long-solved problem as well, and all you need is something like:
systemd.services.chrony.Exec = "${pkgs.chrony.overrideAttrs (old: { configureFlags = old.configureFlags ++ [ "--with-missing-feature" ];})}/bin/chrony";
Imagine that once you wrote such an override, you can put it into different places of your configuration and beyond, and the scope will change accordingly. It can become a dependency of a customized revdep. It can go into the package set and all the revdeps will be recompiled and re-tested against it. Or just to the unit, no rebuilding needed. Or it can go into a separate unit without affecting the main chrony. A development environment. A throwaway shell definition. Your .bashrc. A set of packages available for a specific user only. Or, IDK, if you could place that systemd unit into a lightweight diskless VM by cutting and pasting the line into a VM.
Now imagine having all of that at your disposal for years and then seeing a post that from a person who’s apparently naturally so great at designing distros that he goes on a short tangent in a post about configuration systems and independently arrives at a vision of hermetic, reproducible, declaratively-built, autogenerated from upstream package building recipes… just to stop right there and deny them external customizability?
That’s exactly how flummoxed I am at the idea that key-value settings are somehow enough to design an OS configuration system around. I mean, yes, yes you can overhaul the entire philosophy of how an OS gets configured, effectively designing a new distro around a brand-new configuration system, yet stop just an inch away of making it customizable for real. Not that I could stop you. Just… why.
The package building segment really grinds my shattered heart debris into the asphalt. Like, wouldn’t it be nice if, upon finding out your chrony is compiled without a feature you need, you could just quickly take a custom one compiled --with-missing-feature for a spin? Take a dive from the system configuration language and right into the intricacies of its autotools-driven compilation process? Guess what, that’s a long-solved problem as well, and all you need is something like:
systemd.services.chrony.Exec = "${pkgs.chrony.overrideAttrs (old: { configureFlags = old.configureFlags ++ [ "--with-missing-feature" ];})}/bin/chrony";
Imagine that once you wrote such an override, you can put it into different places of your configuration and beyond, and the scope will change accordingly. It can become a dependency of a customized revdep. It can go into the package set and all the revdeps will be recompiled and re-tested against it. Or just to the unit, no rebuilding needed. Or it can go into a separate unit without affecting the main chrony. A development environment. A throwaway shell definition. Your .bashrc. A set of packages available for a specific user only. Or, IDK, if you could place that systemd unit into a lightweight diskless VM by cutting and pasting the line into a VM.
Now imagine having all of that at your disposal for years and then seeing a post that from a person who’s apparently naturally so great at designing distros that he goes on a short tangent in a post about configuration systems and independently arrives at a vision of hermetic, reproducible, declaratively-built, autogenerated from upstream package building recipes… just to stop right there and deny them external customizability?
That’s exactly how flummoxed I am at the idea that key-value settings are somehow enough to design an OS configuration system around. I mean, yes, yes you can overhaul the entire philosophy of how an OS gets configured, effectively designing a new distro around a brand-new configuration system, yet stop just an inch away of making it customizable for real. Not that I could stop you. Just… why.
@flashfox @bookwar @zbyszek I'm gonna toot that horn as loud as I want to. For delayed updates on nixos stable due to your unwillingness to track stable-staging or -minimal instead are nothing compared to a permanently weakened system due to a purelu architectural decision of no longer running scriptlets that used to do dynamic configuration generation and offering no replacement.
@chocolateloverraj @bookwar @zbyszek https://edolstra.github.io/pubs/phd-thesis.pdf explains why even Haskell isn't lazy enough for that. Rust is so unfit for purpose I can't even.
@monk @bookwar @zbyszek wow I didn't know someone wrote a giant thesis on Nix. I can see how lazy evaluation is very important for the way that nixpkgs works.
I was thinking more like instead of `configuration.nix` having a Rust config file for that. What if the Rust config file just generated Nix data to be evaluated? It wouldn't be possible to enforce that the Rust function though.