there's some confusion about what this will be on the technical site:

• an os written in javascript?
• an os written in c?
• an "os" that you launch on top of a host os?

I'm quite sure we need to be able to run C applications, so just javascript / browser is not an option.

An entire os would allow for most flexibility but is a huge amount of work and slows down adoption times.

If we can make it so that you can run anarchyos on top of your host os - which needs to be *nix based - we'd have the best of both worlds and can still level up to a whole os later.

Hey,

I put a little thought into our package manager.

Name

I'm bad at names so there's none.

Paths

Tricky part is how to support "legacy" applications. This means that we have to provide at least:

• binaries at /usr/local/bin and /usr/local/sbin
• libraries at /usr/local/lib
• includes at /usr/local/include

A generic solution to that would be to make a package list its own links, relative to prefix (let's stay with /usr/local?).

So I thought up this packet.json format:

{
  "links": {
    "bin/me": "bin/me",
    "sbin/me-admin": "bin/me-admin",
    "lib/libme.so": "libme.so",
    "include/me.h": "include/me.h"
  }
}

This would create links at specified locations, pointing to the installed version.
User would be able to change them with <p-m> select <packet>@<version> (this'd relink) or drop into the right subshell with <p-m> use <packet>@<version>.

Dependencies

To ensure that dependencies are satisfied during the compilation, we'll simply be able to execute the compilation in a subshell started with <p-m> use <dep>@<version>.

I think this frees us from handling recursive dependency trees. Imagine this kind of dependency tree:

• a depends on [email protected] and [email protected]
• b depends on [email protected]
• c depends on [email protected]

So, we'd compile b after dropping to a subshell with [email protected] and then c, after dropping it to a subshell with [email protected]. Disclaimer: I have no idea if this won't cause some weird linking conflicts.

Database

The database could live anywhere. Format could be similar to:

me
| - 1.0.0
             | - packet.json
             | - bin/me
             | - ...
| - 1.0.1
             | - packet.json
             | - bin/me
             | - ...

What do you think?

I think it would be good to casually list other projects that are in a similar vein, describe their relation and how this is different / more awesome.

We need something like nvm/nave for EVERY command and library. Some prior art:
http://modules.sourceforge.net/

With the modules package you do module load NAME@VERSION and it creates a subshell with the module or library NAME at the requested VERSION and the LD_LIBRARY_PATH and PATH are updated to point to the vendored lib/ and bin/ directories for NAME.

I know this is very early on in its inception, but it's important to understand how this can succeed given the current ecosystem of technology. With merits & downsides.

The main options as I see it:

• another operating system distro (based on Linux, SmartOS etc...)
  • + run-time efficiency / potential for optimisation
  • + graphical capabilities
  • + people might want to use for reasons other than anarchy
  • - slow distribution (initially at least - of course, anything is possible with a 'killer app')
• pure web application
  • + very fast distribution
  • - will need some form of centralisation / client-server architecture given typical browser capabilities (e.g. STUN server)
  • - browser tyranny
• node + use-of-standard-browser (bundled or not)
  • + easily tiered distribution
  • - browser tyranny
• node + custom-browser (bundled)
  • + potentially tiered distribution
  • - would such a custom browser really be it's own thing or would it just evolve into the custom-node-browser anyway
• custom-node-browser
  • + overall ease-of-development
  • + potentially tiered distribution