3 ms·
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
by WalterBright 2y ago
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.
- endgame 2y agoSounds like it's also halfway to a version of Nix designed specifically for D toolchains, too, using GUIDs instead of hashing inputs.
- WalterBright 2y agoIt wasn't designed specifically for D toolchains, that was just an example of what it could do.
- pmarreck 2y agoyeah, 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 https://edolstra.github.io/pubs/nspfssd-lisa2004-final.pdf Another possibly related idea is the language Unison: https://www.unison-lang.org/ https://www.unison-lang.org/
- WalterBright 2y agoThank you. Looks like my idea precedes Nix by 2 years!
- pmarreck 2y agoNixOS may end up being "the last OS I ever use" (especially now that gaming is viable on it): https://nixos.org/ 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 2y agoThe 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.
- tymscar 2y agoI dont think thats true. How would you compile a program that has conflicting dependencies with a linux namespace?
- remexre 2y agoNix(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.
- Seattle3503 2y agoInteresting. I thought calling a program an "app" came with the smartphone era much later.
- acheron 2y agoPeople 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=onepage&q&f=false https://books.google.com/books?id=CbsaONN5y1IC&pg=PP75#v=one...
- mgarciaisaia 2y agoUsing a hash (content-addressable) instead of a GUID (random ID for each version) is a big difference, though