even applying a version number to a project is silly inherent
you do not trust that version number your self thats why you use for dev git 🙂
so why should a user depend on your package name and version convention that makes zero sense in a simple world
you as the creator does not use that so why should your user use that
it is inherent fundamental wrong doomed from the start
git tags if you want to produce something reference able by reference
thats why that exists
🙂
all existing projects can get incremental upgraded via replacing all the structures with pointers to the real structure
that keeps the outer api the same while the core gets view able
then you can expose the new core as additional entrypoint and call it a day
old existing version numbers of legacy projects do represent always a api version
they have nothing to do with the core if you did isolate the core and exposed that it will mostly not change and so it makes only sense to apply patches to the api and only increment the old version number to the one where api changes got done
security patches and that are not expected as you did not touch the data that can not be in your domain at all
you do not even hold the data so how should you be the issue 🙂
the only possible security violation can get done after linking a peer and loading stuff it exposes so using it with your data imperativ
if you trust the peers so the data source as you do when you visit websites all is secure out of the core design

The Fastest FFI is no FFI Your engine works with so sayed context / world objects they get put into a stack machine and eventually linked via a context.securityId that is always needed to access and decrypt the context.

so we have a pattern where we throw a context via a template that what rust calls generics into a function on build so that it uses when we map its pointer into memory the context as argument. so it works not on sharedArrayBuffer it works on a new sharedContext that is a special kind of program able arrayBuffer

Binary asset versioning

is done via content versioning of a content that references the file via a URI so protocol and other references needed to get the content this way you can link up the content it self the uri to the content needs to contain a content hash of the binary.

Content versioning

B8G is using git a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as ECMAScripts stripped down Stealify Syntax — they are built by functions that don’t have side-effects, and they never change after they have been built. git stores modules in the .git store, usually the directory /.git/objects, where each module has its own unique subdirectory such as

/.git/object/blob/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z
where b6gvzjyb2pg0… is a unique identifier for the package or module that captures all its dependencies (it’s a cryptographic hash of the modules components reference graph). This enables many powerful features.

Multiple versions
You can have multiple versions or variants of a module loaded at the same time. This is especially important when different applications have dependencies on different versions of the same module or content that it provides — it prevents the “DLL hell”. Because of the hashing scheme, different versions of a module end up in different paths in the git store, so they don’t interfere with each other. Additional they get signed with a integrity hash by the commit message and the content.

An important consequence is that operations like upgrading or uninstalling an application cannot break other applications, since these operations never “destructively” update or delete files that are used by other packages.

Complete dependencies
When you’re making a package for a package management system, like RPM, you are supposed to declare its dependencies, but you can't easily guarantee that your dependency declaration is complete. If you forget a dependency, that you have separately installed on your machine, then the component may build and work correctly on your machine, but failing on the end user's machine.

git ensures that package dependency specifications are complete.

Under git, a build process will only find resources that have been declared explicitly as dependencies. There's no way it can build until everything it needs has been correctly declared. If it builds, you will know you've provided a complete declaration.

Once a build is complete, ongoing runtime dependencies are detected automatically.

Multi-user support
This means that non-privileged users can securely install software upgrade patch run. Each user can have a different profile, a set of modules in the git store that appear in the user’s PATH. If a user installs a package that another user has already installed previously, the package won’t be built or downloaded a second time. At the same time, it is not possible for one user to inject a Trojan horse into a package that might be used by another user.

Below parts need upgrading

Below parts need upgrading

Below parts need upgrading

Below parts need upgrading

Below parts need upgrading

Atomic upgrades and rollbacks
Since package management operations never overwrite packages in the Nix store but just add new versions in different paths, they are atomic. So during a package upgrade, there is no time window in which the package has some files from the old version and some files from the new version — which would be bad because a program might well crash if it’s started during that period.

And since packages aren’t overwritten, the old versions are still there after an upgrade. This means that you can roll back to the old version:

$ nix-env --upgrade some-packages
$ nix-env --rollback
Garbage collection
When you uninstall a package like this…

$ nix-env --uninstall firefox
the package isn’t deleted from the system right away (after all, you might want to do a rollback, or it might be in the profiles of other users). Instead, unused packages can be deleted safely by running the garbage collector:

$ nix-collect-garbage
This deletes all packages that aren’t in use by any user profile or by a currently running program.

Functional package language
Packages are built from Nix expressions, which is a simple functional language. A Nix expression describes everything that goes into a package build action (a “derivation”): other packages, sources, the build script, environment variables for the build script, etc. Nix tries very hard to ensure that Nix expressions are deterministic: building a Nix expression twice should yield the same result.

Because it’s a functional language, it’s easy to support building variants of a package: turn the Nix expression into a function and call it any number of times with the appropriate arguments. Due to the hashing scheme, variants don’t conflict with each other in the Nix store.

Transparent source/binary deployment
Nix expressions generally describe how to build a package from source, so an installation action like

$ nix-env --install firefox
could cause quite a bit of build activity, as not only Firefox but also all its dependencies (all the way up to the C library and the compiler) would have to built, at least if they are not already in the Nix store. This is a source deployment model. For most users, building from source is not very pleasant as it takes far too long. However, Nix can automatically skip building from source and instead use a binary cache, a web server that provides pre-built binaries. For instance, when asked to build /nix/store/b6gvzjyb2pg0…-firefox-33.1 from source, Nix would first check if the file http://cache.nixos.org/b6gvzjyb2pg0….narinfo exists, and if so, fetch the pre-built binary referenced from there; otherwise, it would fall back to building from source.

Nix Packages collection
We provide a large set of Nix expressions containing thousands of existing Unix packages, the Nix Packages collection (Nixpkgs).

Portability
Nix runs on Linux and macOS.

How NixOS works?
NixOS is based on Nix, a purely functional package management system. Nix stores all packages in isolation from each other under paths such as

/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/
The string 5rnf... is a cryptographic hash of all input used to build the package. Packages are never overwritten after they have been built; instead, if you change the build description of a package (its ‘Nix expression’), it’s rebuilt and installed in a different path in /nix/store so it doesn’t interfere with the old version. NixOS extends this by using Nix not only to build packages, but also things like configuration files. For instance, the configuration of the SSH daemon is also built from a Nix expression and stored under a path like

/nix/store/s2sjbl85xnrc18rl4fhn56irkxqxyk4p-sshd_config
By building entire system configurations from a Nix expression, NixOS ensures that such configurations don’t overwrite each other, can be rolled back, and so on.

A big implication of the way that Nix/NixOS stores packages is that there is no /bin, /sbin, /lib, /usr, and so on. Instead all packages are kept in /nix/store. (The only exception is a symlink /bin/sh to Bash in the Nix store.) Not using ‘global’ directories such as /bin is what allows multiple versions of a package to coexist. Nix does have a /etc to keep system-wide configuration files, but most files in that directory are symlinks to generated files in /nix/store.

Declarative system configuration model
In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this.

You configure a NixOS system by writing a specification of the functionality that you want on your machine in /etc/nixos/configuration.nix. For instance, here is a minimal configuration of a machine running an SSH daemon:

{
boot.loader.grub.device = "/dev/sda";

fileSystems."/".device = "/dev/sda1";

services.sshd.enable = true;

}
After changing /etc/nixos/configuration.nix, you realise the configuration by running this command:

$ nixos-rebuild switch
This command does everything necessary to make the configuration happen, including downloading and compiling OpenSSH, generating the configuration files for the SSH server, and so on.

Reliable upgrades
Another advantage of purely functional package management is that nixos-rebuild switch will always produce the same result, regardless of what packages or configuration files you already had on your system. Thus, upgrading a system is as reliable as reinstalling from scratch.

Atomic upgrades
NixOS has a transactional approach to configuration management: configuration changes such as upgrades are atomic. This means that if the upgrade to a new configuration is interrupted — say, the power fails half-way through — the system will still be in a consistent state: it will either boot in the old or the new configuration. In most other systems, you’ll end up in an inconsistent state, and your machine may not even boot anymore.

Rollbacks
Because the files of a new configuration don’t overwrite old ones, you can (atomically) roll back to a previous configuration. For instance, if after a nixos-rebuild switch you discover that you don’t like the new configuration, you can just go back:

$ nixos-rebuild switch --rollback
Grub boot menu
In fact, all old system configurations automatically show up in the Grub boot menu. So if the new configuration crashes or doesn’t boot properly, you can just roll back by selecting an older configuration in the Grub boot menu. Rollbacks are very fast: it doesn’t involve lots of files having to be restored from copies.

Reproducible system configurations
NixOS’ declarative configuration model makes it easy to reproduce a system configuration on another machine (for instance, to test a change in a test environment before doing it on the production server). You just copy the configuration.nix file to the target NixOS machine and run nixos-rebuild switch. This will give you the same configuration (kernel, applications, system services, and so on) except for ‘mutable state’ (such as the stuff that lives in /var).

Safe to test changes
NixOS makes it safe to test potentially dangerous changes to the system, because you can always roll back. (Unless you screw up the boot loader, that is…) For instance, whether the change is as simple as enabling a system service, or as large as rebuilding the entire system with a new version of Glibc, you can test it by doing:

$ nixos-rebuild test
This builds and activates the new configuration, but doesn’t make it the boot default. Thus, rebooting the system will take you back to the previous, known-good configuration.

An even nicer way to test changes is the following:

$ nixos-rebuild build-vm
$ ./result/bin/run-*-vm
This builds and starts a virtual machine that contains the new system configuration (i.e. a clone of the configuration of the host machine, with any changes that you made to configuration.nix). The VM doesn’t share any data with the host, so you can safely experiment inside the VM. The build-vm command is very efficient (it doesn’t require a disk image for the VM to be created), so it’s a very effective way to test changes.

Expand on why it is bad give examples.