From @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.
