search

NiXium-org / NiXium

Open-Source Infrastructure as Code Management Solution for Multiple Systems designed to be reliable in mission-critical tasks on paranoid and high-security environment.
European Union Public License 1.2
16 stars 3 forks source link

Next-Gen NiXium #131

Open Kreyren opened 3 weeks ago

Kreyren commented 3 weeks ago

This issue is work in progres..

This issue ignores the https://github.com/Kreyren/kreyren/issues/111 -relevant content as that is still on-going and currently can't be used for an objective review.

The idea behind this meta-issue is to permanently address the unfixable issues in both GNU Guix and NixOS by implementing a nix-based distribution that addresses the observed issues:

GNU Guix GNU/Linux:

NixOS

Nix language is terrible implementation for it's designed workflow, it's constantly encountering infinite recursion issues when the code gets more complex that takes unreasonable amount of human resources to be managed e.g. https://discourse.nixos.org/t/how-to-correctly-implement-release-flexible-nixos-modules/49869 encountered at https://github.com/NiXium-org/NiXium/pull/124#issuecomment-2258539202 and as a result the current source code is still affected by it https://github.com/NiXium-org/NiXium/blob/35dc1a258134234f1601c6124bd4881ef1ba7567/src/nixos/machines/tupac/config/disks.nix#L29-L30.

Additionally the Nix Language is no where near the flexibility and functionality of scheme-based languages resulting in a code that is more complex than it has to be and that is often very difficult to make work for the desired workload e.g. trying to get a different package version often requires making a custom package definition as the derivation providing the package is inherently not compatible with different versions of the package or having to pin a nixpkgs commit that provides the version.

Their community management forces cultures that hate each other in a collaborative work without being the required impartial judge to try to manage it which is prone to constantly cause conflicts and that is managed insufficiently as evident by the Anduril crisis with the current NixOS management refusing to learn from these mistakes and causing an exodus of maintainers and developers.

That said there are things done right which this issue aims to learn and inspire from namely:

GNU Guile deep integration with the GNU Guix

The use of proper frameworking language enables the distribution to function as the de-factor borg that can be infinitely expanded with built-in functionality instead of trying to make two components from two different worlds work with each other.

Namely the integration of the Init/service manager of GNU Shepherd on guix and SystemD on NixOS:

As observed the GNU Shepherd can integrate without having to make a duplicate function and in a way that can directly use the features from either guix or shepherd seamlessly resulting in a significantly smaller footprint and more functional integration that doesn't limit innovation like e.g. https://github.com/NixOS/nixpkgs/pull/324911#issuecomment-2274487337.

In comparison to the SystemD used in NixOS which is binded through an API and is very overcomplicated with features that NixOS will likely never use that only poses an increased risk of security vulnerability and difficulty of adaptation for the workload.

The guix's implementation also expands to 3rd party services such as gitile which is a gitea-inspired forge de-facto turning the package manager into having a built-in git forge or even an authoritative DNS server.

NixOS has a better management

NixOS is funded by the community through an open-collective which is done in a transparent way and thus does not have major issues with funding and resources like guix.

Nix also has CI/CD to capture common issues and is overall in an another league in terms of reliability to be an acceptable solution for production and mission-critical environment thus objectively better solution despite doing a worse design decisions in comparison to guix.

Considered lisp implementations

Common-Lisp ("CL")

Which was already attempted as implemented by a community member infinisil: https://github.com/infinisil/nixlisp, but CL is not a good fit for a functional language as it's expressions are more aimed to be an object oriented and have to be integrated in a very complex way in comparison to scheme.

GNU Guile

Overall not a bad option, but it's lacking on the integration with the IDE and emacs in terms of documentation making the language painfully difficult to learn and use correctly. Additionally it lacks a needed functionality for this task as well as e.g. it's not possible to attach a docstring with a default value to a variable and upstream devs do not seem to be interested in trying to make the documentation better either.

So for our usecase it would have to be forked and it would be a lot of work to re-integrate the documentation to be at least on elisp-levels.

Steel

TBD https://github.com/mattwparas/steel/issues/259

Tvix is a Nix rewrite in rust - https://github.com/tvlfyi/tvix

State an usability of the project is unknown

Current major problem is that they use GPLv3 license, which might limit our use.

Kreyren commented 3 weeks ago

Hey @flokli, can you please elaborate on the state of tvix? Thanks! <3

flokli commented 3 weeks ago

Hey @Kreyren, you're welcome to follow the state of Tvix on the various blog posts, changes in the repository, and other public information - I assume you understand I cannot provide individual status updates in various issues elsewhere. Thanks!

Kreyren commented 3 weeks ago

@flokli will read through them, thanks for info!