To support this transition, DINUM's Interministerial Products Operator (OPI) department is developing Sécurix, a highly secure, reproducible operating system base built on NixOS. Published on GitHub under an MIT License, Sécurix is designed to meet the strict security recommendations of the ANSSI, incorporating features like TPM2 management, YubiKey-based encryption (LUKS FIDO2), and centralized enrollment for Secure Boot. Alongside it, Bureautix serves as a demonstrator and practical implementation of Sécurix tailored for administrative office use, managing configurations declaratively as code via Git rather than relying on traditional centralized directories like Active Directory.
No matter what, I did not explain myself very well, so I try to elaborate.
What I said in the linked post:
Precisely at work we're spending significantly more effort in "basic" stuff we'd get for free. For example, running validations on GitHub Actions is more involved than your typical project- caching, parallelization, etc. are really important to get robust and performant builds.
That was in the context about the "death" of Garnix, that provided some of those. I also had to find hosting providers, and I wasn't able to find any well-known hoster providing explicit support for NixOS.
I wouldn't call that "enterprise features for corporate environments". "Maturity" is also inadequate- perhaps I should have said "a mature ecosystem".
I also expect that LTS offerings of NixOS will become popular (or a Nix-like system with those will appear). That is frequently associated with enterprise environments, but I don't think LTS is exclusively for enterprises. (Personally, I keep as much as my infrastructure on RHEL derivatives because it's hugely convenient. I set things to patch automatically and this reduces my maintenance burden with little risk. And I think for personal stuff, reduciing maintenance burden might be even more important than for enterprises with deep pockets!)
Although most importantly: some of the maturity I want is better documentation and less "basic features" under unstable warnings. I know lately most people do not appreciate this, but the other perk why I use RHEL derivatives is that I am quite certain that the RHEL documentation will be accurate and that I'll be able to find how to do a lot of things there without having to dig random Internet posts. (For example, in my work Linux adventures, even some seasoned NixOS user struggled with finding the proper way to do things.)
I'll stress it again: the idea behind NixOS is amazing. When I refer to it as "alien", I not only mean "strange". I also mean "technology that is years more advanced than anything else". I hope the Nix approach will "win" over the more common approaches based in container images.
It's just I feel there are lots of opportunities to advance the approaches that Nix pioneers.
As the author of Sécurix, I see where Corbin is coming from, and I appreciate the perspective. I just want to gently share that I don't think LTS offerings, or what Sécurix currently is, represent projects that are directly useful for the community at large. That said, I do want to acknowledge that an NixOS LTS already exists, offered by https://www.cyberus-technology.de/.
I set things to patch automatically and this reduces my maintenance burden with little risk. And I think for personal stuff, reducing maintenance burden might be even more important than for enterprises with deep pockets!
That's a fair point, and I completely understand the appeal. If what you’re using aligns exactly with what paying companies are using and funding for LTS, then it works nicely. But NixOS has over 100k packages, and full LTS coverage for all of them is unfortunately physically impossible. Even maintainers of traditional commercial LTS distros struggle to keep up with their much smaller package sets. When you think about patching a 10- or 15-year-old codebase in an ecosystem that moves very fast, the cost becomes prohibitive.
I hope this doesn't come across too strongly, but in my view, LTS can be an antipattern for a community Linux distribution and for sustainable development. Regularly updating, even when it’s a bit painful, and using features to validate those updates remains the most reliable path to a secure system. The longer you wait to do a major upgrade, the harder it inevitably becomes.
That being said, I think maturity means so many things for vast different set of people. I'm glad you are finding what you call maturity in all of this.
I just want to gently share that I don't think LTS offerings, or what Sécurix currently is, represent projects that are directly useful for the community at large. That said, I do want to acknowledge that an NixOS LTS already exists, offered by https://www.cyberus-technology.de/.
Oh, I'm not even sure Sécurix is an LTS? Is it?
What I might not be getting across very well is that all the resources spent on Nix/NixOS are likely to help the community at large, even if indirectly.
I know about Cyberus, but I believe they are still in closed beta and I'm not entirely sure what they are doing- they talk a lot about embedded so I'm not 100% what they'll release.
But NixOS has over 100k packages, and full LTS coverage for all of them is unfortunately physically impossible.
Oh, yes, you are absolutely right, of course. RHEL is very limited in scope and for many things you have to go to EPEL, which has a very different set of guarantees.
However, nixpkgs itself can help there! Or distrobox. Or backports for some stuff.
I use Debian stable a lot, and I have researched using upstream binaries, nixpkgs, etc. It can still be advantage to have an LTS core and add some more modern bits on top.
And for servers, well, what is included in RHEL covers a lot. For quite a few things you can get by with RHEL alone with no EPEL. (Also for some kinds of specialized workstations. Think single-purpose machines for running specific hardware or commercial software.)
LTS can be an antipattern for a community Linux distribution and for sustainable development. Regularly updating, even when it’s a bit painful, and using features to validate those updates remains the most reliable path to a secure system.
That's the eternal question, right? I don't think the answer is in either of the extremes. It depends. A 6-month upgrade cycle can work better than doing alternate RHEL or Debian releases (so every 4 years), or all updates (2 years). It really depends on what you're doing. I've been updating my personal infra since CentOS 6, IIRC, and updates were not so painful (anecdote, of course!), and in some cases, some stuff I just decommissioned... in a few years you maybe discover the service was not so useful, you want something else... and then it works out that you held on a stable release.
For many other things, I agree with what you say! I have suffered things like stuff stopping to support the runtimes in RHEL, and many others.
The world is large and varied. Maybe in a few years LTS will be dead. Maybe Cyberus will make a lot of money if they are one of the few NixOS LTS providers.
Again: I expect the ideas of NixOS take over the world. And maybe world dominance might not come through LTS availability. Heck, LTS may die as far as I know! I just wish people continue working on NixOS to evolve its ideas and that running services becomes better with time.
edit: sorry, one big thing I missed in your post, you mentioned "community distro". Yeah, that invalidates some of what I'm saying.
and I wasn't able to find any well-known hoster providing explicit support for NixOS.
Just in case anyone's struggling with this - you don't actually need explicit support. Have a look at how these install scripts are implemented https://github.com/nix-community/nixos-install-scripts/tree/master/hosters and potentially write your own version if you need another environment. You can install any minimal distro and then install nixos over it. Once you have one machine with nixos, you can usually snapshot it and clone in the future. Hosters don't really care what you run on their machines, they just provide a simple starting template.
Or you can use nixos-infect, nixos-anywhere, etc. Even though your hoster might not care what you run, it's best if your hoster has explicit support.
It just makes things easier and nicer. Also, being able to select generations from the hosting control panel would be pretty nice (on virtual machines). For physical machines the desire for having some hoster support is a bit more important; if you have RAID hardware or stuff like that, it's always preferrable to have a well-tested setup. You can do it yourself, of course- but for supported platforms that's some effort you save.
[OP] koala | a day ago
While researching for a response in another thread about Linux accessibility I started reading about the French government efforts on digital sovereignty, and came across this in the digital sovereignty and Linux migration section of the DINUM Wikipedia article:
Which might also address some other concerns I've had lately about the maturity of NixOS.
Corbin | a day ago
I appreciate that you explained what you mean by maturity. I think that you've conflated maturity with enterprise features for corporate environments.
[OP] koala | a day ago
No matter what, I did not explain myself very well, so I try to elaborate.
What I said in the linked post:
That was in the context about the "death" of Garnix, that provided some of those. I also had to find hosting providers, and I wasn't able to find any well-known hoster providing explicit support for NixOS.
I wouldn't call that "enterprise features for corporate environments". "Maturity" is also inadequate- perhaps I should have said "a mature ecosystem".
I also expect that LTS offerings of NixOS will become popular (or a Nix-like system with those will appear). That is frequently associated with enterprise environments, but I don't think LTS is exclusively for enterprises. (Personally, I keep as much as my infrastructure on RHEL derivatives because it's hugely convenient. I set things to patch automatically and this reduces my maintenance burden with little risk. And I think for personal stuff, reduciing maintenance burden might be even more important than for enterprises with deep pockets!)
Although most importantly: some of the maturity I want is better documentation and less "basic features" under unstable warnings. I know lately most people do not appreciate this, but the other perk why I use RHEL derivatives is that I am quite certain that the RHEL documentation will be accurate and that I'll be able to find how to do a lot of things there without having to dig random Internet posts. (For example, in my work Linux adventures, even some seasoned NixOS user struggled with finding the proper way to do things.)
I'll stress it again: the idea behind NixOS is amazing. When I refer to it as "alien", I not only mean "strange". I also mean "technology that is years more advanced than anything else". I hope the Nix approach will "win" over the more common approaches based in container images.
It's just I feel there are lots of opportunities to advance the approaches that Nix pioneers.
raito | 21 hours ago
As the author of Sécurix, I see where Corbin is coming from, and I appreciate the perspective. I just want to gently share that I don't think LTS offerings, or what Sécurix currently is, represent projects that are directly useful for the community at large. That said, I do want to acknowledge that an NixOS LTS already exists, offered by https://www.cyberus-technology.de/.
That's a fair point, and I completely understand the appeal. If what you’re using aligns exactly with what paying companies are using and funding for LTS, then it works nicely. But NixOS has over 100k packages, and full LTS coverage for all of them is unfortunately physically impossible. Even maintainers of traditional commercial LTS distros struggle to keep up with their much smaller package sets. When you think about patching a 10- or 15-year-old codebase in an ecosystem that moves very fast, the cost becomes prohibitive.
I hope this doesn't come across too strongly, but in my view, LTS can be an antipattern for a community Linux distribution and for sustainable development. Regularly updating, even when it’s a bit painful, and using features to validate those updates remains the most reliable path to a secure system. The longer you wait to do a major upgrade, the harder it inevitably becomes.
That being said, I think maturity means so many things for vast different set of people. I'm glad you are finding what you call maturity in all of this.
[OP] koala | 20 hours ago
Oh, I'm not even sure Sécurix is an LTS? Is it?
What I might not be getting across very well is that all the resources spent on Nix/NixOS are likely to help the community at large, even if indirectly.
I know about Cyberus, but I believe they are still in closed beta and I'm not entirely sure what they are doing- they talk a lot about embedded so I'm not 100% what they'll release.
Oh, yes, you are absolutely right, of course. RHEL is very limited in scope and for many things you have to go to EPEL, which has a very different set of guarantees.
However, nixpkgs itself can help there! Or distrobox. Or backports for some stuff.
I use Debian stable a lot, and I have researched using upstream binaries, nixpkgs, etc. It can still be advantage to have an LTS core and add some more modern bits on top.
And for servers, well, what is included in RHEL covers a lot. For quite a few things you can get by with RHEL alone with no EPEL. (Also for some kinds of specialized workstations. Think single-purpose machines for running specific hardware or commercial software.)
That's the eternal question, right? I don't think the answer is in either of the extremes. It depends. A 6-month upgrade cycle can work better than doing alternate RHEL or Debian releases (so every 4 years), or all updates (2 years). It really depends on what you're doing. I've been updating my personal infra since CentOS 6, IIRC, and updates were not so painful (anecdote, of course!), and in some cases, some stuff I just decommissioned... in a few years you maybe discover the service was not so useful, you want something else... and then it works out that you held on a stable release.
For many other things, I agree with what you say! I have suffered things like stuff stopping to support the runtimes in RHEL, and many others.
The world is large and varied. Maybe in a few years LTS will be dead. Maybe Cyberus will make a lot of money if they are one of the few NixOS LTS providers.
Again: I expect the ideas of NixOS take over the world. And maybe world dominance might not come through LTS availability. Heck, LTS may die as far as I know! I just wish people continue working on NixOS to evolve its ideas and that running services becomes better with time.
edit: sorry, one big thing I missed in your post, you mentioned "community distro". Yeah, that invalidates some of what I'm saying.
viraptor | 8 hours ago
Just in case anyone's struggling with this - you don't actually need explicit support. Have a look at how these install scripts are implemented https://github.com/nix-community/nixos-install-scripts/tree/master/hosters and potentially write your own version if you need another environment. You can install any minimal distro and then install nixos over it. Once you have one machine with nixos, you can usually snapshot it and clone in the future. Hosters don't really care what you run on their machines, they just provide a simple starting template.
[OP] koala | 7 hours ago
Or you can use nixos-infect, nixos-anywhere, etc. Even though your hoster might not care what you run, it's best if your hoster has explicit support.
It just makes things easier and nicer. Also, being able to select generations from the hosting control panel would be pretty nice (on virtual machines). For physical machines the desire for having some hoster support is a bit more important; if you have RAID hardware or stuff like that, it's always preferrable to have a well-tested setup. You can do it yourself, of course- but for supported platforms that's some effort you save.