It is an operating system and while it does not have its own kernel at the moment (even then it's not necessarily tied to any either), it does have a lot of tools developed and being developed for it.
Eltanin is the name of the operating system, glacies is a distribution of it (using a third-party kernel). The distinction exists to let its identity clear, for it has no attachment to any kernel, other distributions could appear and our own solution mighty appear sooner than later (join the communities to receive news sooner).
You can read about the project goals in the main page, while there are other projects with similar goals the differences are too significant to consider uniting with another project of the same niche.
For instance all the project tools uses the libC tertium instead of the standard libC (see comparison) and redo instead of make, which (following the principle of interoperability) is used to build arbor and venus.
It also uses third-party tools that are aligned with the project's goals: execline for scripting, s6 and s6-rc as init-system, arcan as display server.
#!/bin/execlineb -P
# a random example of execline interoperability (create a hash for each file)
find . -type f -exec
define file "{}"
redirfd -w 1 "${file}.hash"
cksum $fileSo it's more sensical to benefit tools aligned with the project's goals (with the testing and extra attention) instead of "uniting" with project of different views.
Simia is a POSIX compatibility layer (akin to glibc or musl) for tertium, while not currently in use it will take place as default POSIX libC for all the Eltanin distributions (until then it's likely that a merged version will be put to use). It exists for portability reasons and to interoperate with the non-posix libC tertium.
The package management is done by arbor and venus, the first one is a reproducible build system that will populate the repository; the second one is a functional package manager that uses the repository to atomically install/update/downgrade packages.
When you install a package, the system files start to be gradually overwritten. During this period the application will not work, and if the operation fails, the system is left in an unfinished state, with the modified parts inoperative. In an atomic model, on the other hand, operations are indivisible, that is, the operation either succeeds completely or fails completely. Thus, if the operation succeeds, the system is instantly updated to the new state, otherwise it remains as it was, ensuring that the system is responsive at all times.
The packages are created with a unique crypto hash, so you have a way to be sure that the package you are receiving is the same you expected. In this way you can know when to stop trusting a repo. The package manager also uses this fact to use mirrors without needing you to trust them (as it download the hashes from your trusted repo).
