[WalterBright]

I had actually done a writeup on it, and thought I had lost it. I found it, dated 2/15/2002:

---

Consider that any D app is completely specified by a list of .module files and the tools necessary to compile them. Assign a unique GUID to each unique .module file. Then, an app is specified by a list of .module GUIDs. Each app is also assigned a GUID.

On the client's machine is stored a pool of already downloaded .module files. When a new app is downloaded, what is actually downloaded is just a GUID. The client sees if that GUID is an already built app in the pool, then he's done. If not, the client requests the manifest for the GUID, a manifest being a list of .module GUIDs. Each GUID in the manifest is checked against the client pool, any that are not found are downloaded and added to the pool.

Once the client has all the .module files for the GUIDs that make up an app, they can all be compiled, linked, and the result cached in the pool.

Thus, if an app is updated, only the changed .module files ever need to get downloaded. This can be taken a step further and a changed .module file can be represented as a diff from a previous .module.

Since .module files are tokenized source, two source files that differ only in comments and whitespace will have identical .module files.

There will be a master pool of .module files on WT's server. When an app is ready to release, it is "checked in" to the master pool by assigning GUIDs to its .module files. This master pool is what is consulted by the client when requesting .module files by GUID.

The D "VM" compiler, linker, engine, etc., can also be identified by GUIDs. This way, if an app is developed with a particular combination of tools, it can specify the GUIDs for them in the manifest. Hence the client will automatically download "VM" updates to get the exact tools needed to duplicate the app exactly.

[pmarreck]

yeah, allow me to introduce you to the Nix whitepaper, which is essentially this, and thus worth a read for you:

https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf

Another possibly related idea is the language Unison:

https://www.unison-lang.org/

[WalterBright]

Thank you. Looks like my idea precedes Nix by 2 years!

[pmarreck]

NixOS may end up being "the last OS I ever use" (especially now that gaming is viable on it):

https://nixos.org/

Check it out. The whitepaper's a fairly digestible read, too, and may get you excited about the whole concept (which is VERY different from how things are normally done, but ends up giving you guarantees)

[XorNot]

The problem with NoxOS is all the effort to capture software closures is rendered moot by Linux namespaces, which are a more complete solution to the same problem.

Of course we didn't have them when the white paper was written, so that's fair but technology has moved on.

[remexre]

Nix(OS) is aware of namespaces, and can use them (in fact, the aforementioned gaming support relies on them), but versioning packages still works better than versioning the system in most cases.

Consider three packages, A, B, and C. B has two versions, A and C have one.

- A-1.0.0 depends on B-2.0.0 and C-1.0.0. - C-1.0.0 depends on B-1.0.0.

If A gets a path to a file in B-2.0.0 and wants to share it with C (for example, C might provide binaries it can run on files, or C might be a daemon), it needs C to be in a mount namespace with B-2.0.0. However, without Nix-store-like directory structure, mounting B-2.0.0's files will overwrite B-1.0.0's, so C may fail to start or misbehave.

[tymscar]

I dont think thats true. How would you compile a program that has conflicting dependencies with a linux namespace?

[pmarreck]

Linux namespaces and Nix closures solve different problems at different stages of the software lifecycle. Namespaces isolate running processes; Nix closures guarantee build-time determinism and reproducibility across systems.

Namespaces don’t track transitive dependencies, guarantee reproducible builds, enable rollback, or let you deploy an exact closure elsewhere. They’re sandboxing tools—not package management or infra-as-code.

If anything, the two are complementary. You can use Nix to build a system with a precise closure, and namespaces to sandbox it further. But calling namespaces a "more complete solution" is like calling syscall filtering a replacement for source control.

Also, minor historical nit: most namespaces existed by the late 2000s; Nix’s whitepaper was written after that. So the premise isn’t even chronologically correct.

[endgame]

Sounds like it's also halfway to a version of Nix designed specifically for D toolchains, too, using GUIDs instead of hashing inputs.

[WalterBright]

It wasn't designed specifically for D toolchains, that was just an example of what it could do.

[mgarciaisaia]

Using a hash (content-addressable) instead of a GUID (random ID for each version) is a big difference, though

[Seattle3503]

Interesting. I thought calling a program an "app" came with the smartphone era much later.

[acheron]

People called things like Lotus 1-2-3 “killer apps” in the 1980s.

A reference from 1989:

https://books.google.com/books?id=CbsaONN5y1IC&pg=PP75#v=one...