What forms can this take?

[refset]

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

[juliangruber]

it should def. be your os or the only thing you use, having your os be merely a runtime for anarchy os.

So pure web application e.g. is out because you can't start server tcp sockets or run c code.

[heapwolf]

/cc @jacobgroundwater

[rvdende]

Intrigued where this is going. I agree basing off linux/bsd would make the most sense. Just starting off with a distro with node/npm and toolchain setup by default will already be an improvement, something that will allow me to tell a friend just install this OS, and then npm install _____ and be sure not to run into compiler not being there, or some other issue will already help a lot.

Being able to run a piece of .js code by double clicking it, and allowing it to run like a native app. Would we be able to build native like software from js alone?

I realise I'm very js orientated, but it obviously wont be limited to that. Pushing npm further into all apps/distro version control is very interesting.

[juliangruber]

opening js apps by double clicking them will be responsibility of a gui module, not anarchy itself.

with chrome apps and node you can aleady build "native" apps in pure js!

[jwerle]

I'm sure everyone has seen https://github.com/rogerwang/node-webkit right?

[heapwolf]

@jwerle that's getting pretty far from the objective. To refocus, the objective is not simply about apps and GUIs. Its about assembling an entire operating system with specific principles.

[jwerle]

@hij1nx You're right! I guess I just got excited when the talk of gui came in.

[refset]

This all depends on what an acceptable definition of operating system is. My favourite definition from this thread is "the only thing you use". I think the question is whether we want the "you" in that sentence to mean us, the technological elite, or the general public. If it's the general public (which it should be), then ability-to-distribute is fundamental to success. Perhaps the answer is two levels of operating system and we need the first to exist initially so that we can build the other - but I argue we already have it.

[groundwater]

Thanks @hij1nx for linking me in here.

Not sure if this is useful to you guys or what you're looking for, but I'm working on NodeOS right now. It's progressing slowly but surely, and definitely falls into your first category.

NodeOS is designed to run on top of the linux kernel, or possibly any kernel in the future. My primary motivation was to see what would happen if I used NPM as the entire systems package manager. I am building just enough to let the package manager take over and then let people do what they want.

If you're into docker, you can try sudo docker run -t -i groundwater/nodeos and see a very raw but working version. I'm mostly concentrating on two modules right now, a node init-daemon, and a wrapper for NPM to serve as a higher-level package manager.

If there is any similarity here, I'm definitely up for collaborating.

[dominictarr]

So when @substack and I where first discussing this, we used "OS" in a fairly loose sense, it mainly be a cross platform p2p package manager (compatible with npm), that could run on the server or the browser, and maybe have a minimal linux distro designed just for node.

Since then, a lot of people have gotten interested in this idea, and it's especially exciting to see things like NodeOS.

@jacobgroundwater I'm also keen to see npm as the system package manager. I think the key benefit of npm is that it can handle what would be version conflicts on other systems.

@mmalecki and I have been discussing how to do that over here: https://github.com/mmalecki/apm/issues/1#issuecomment-26071524

I'm working on something that will be secure and precise enough to make a p2p package manager over here: https://github.com/dominictarr/cyphernet

[dominictarr]

oh, also https://github.com/juliangruber/anarchyos/issues/5

[rvagg]

maybe we should use bower instead of npm, apm, etc.!

[groundwater]

@dominictarr I'm also using OS in a very loose sense, much to the anger of hacker news. I could definitely see using the package manager you're talking about for NodeOS.

I started npkg which is my first pass. It calls the equivalent of npm -g programmatically, but sets things up so that packages appear in $HOME/lib/node_modules and links binaries to $HOME/bin.

Everything other than /bin/node resides in $HOME/bin so installed packages are unique to each user. You don't need to be root to install packages.

The second thing npkg provides is starting system daemons with npkg start <pkg>. This piece is intimately connected to the init daemon however. Starting a package via npkg is just like calling npm start, but lets init daemonize the process.

I could always separate out the second piece and utilize a standardized cross-platform PM.

[dominictarr]

@jacobgroundwater what about installing necessary build tools like gcc and make? and managing multiple versions of node? and of course, occasionally, you need to install some C build dep for some node modules, which is normally accomplished through the OS package manager.

It's gonna be quite a while before you can just assume that whatever version of node is current is right, like you might with awk.

I think the solution here is to have these tools set up in a way that you can have multiple versions of each dependency, as you can with npm modules.

[groundwater]

@dominictarr it's clear to me that AnarchyOS and NodeOS are approaching the problem from different ends. I'm much less concerned right now with providing a full tool suite, and more interested in seeing how far we can get on just npm/node.

I realize that out of the gate, there is pretty much no good solution for compiled modules. I'm actually hoping that either NPM starts supporting pre-compiled modules, or AnarchyOS solves the problem :grin:. Right now the few compiled dependencies I have are pre-compiled, so NodeOS will only work on docker/linux. This is not a long-term solution, but it works for now.

I definitely think that C dependencies should be isolated to the given module, and perhaps even available via npm. I liked @substack's idea to place .cc modules into npm. As long as @isaacs is cool with that, I think it's a great idea.

As far as versioning node goes, I'm not sure that's something I want to get into. There will be plenty of room for extension, but NodeOS out of the gate will expect you to use the latest version of node always. There are many many directions this could go, which is kind of why it's so fun.

[dominictarr]

Aha, okay -- well it is still very good to be approaching the same problem from different ends, especially if we do so in communication.