3 ms·

What I like most about this idea is that system administration via init scripts, et al, can just go away -- presumably one will have APIs for interacting with t

What I like most about this idea is that system administration via init scripts, et al, can just go away -- presumably one will have APIs for interacting with the available hardware, necessary 'OS' services, etc. It'd make automated deployment of systems even more manageable -- turtles all the way down.

jrockway 17y ago
Good observation. I have to say that I find Java generally distasteful, but I feel the same way about UNIX. An "OS" for my applications that is just some OO code I interact with would be much better than random shell scripts that talk to other random shell scripts via unstructured one-way text pipes. Turtles all the way down, indeed. Of course, UNIX is trying to fix that too... so it will be interesting to see how this evolves.
tezza 17y ago
I'm all for this JVM re-implementation project, but the sysadmin aspect is just going to be pushed one level up the the Xen image host. You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ssh to xen master upload new xen image adjust xen master rc scripts to load new image on startup Hardly turtles-all-the-way down
- antonovka 17y ago
  You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ... Why wouldn't the virtual machine bootstrap itself from network loaded code -- then it wouldn't be necessary to update the root Xen image. Why couldn't I write a network service (also on the VM) that runs on other Xen instances and serves up the netboot code? Why would updating the root VM require SSH? Couldn't I have a nice web management UI that I can just upload a new bootstrap JVM image to (on the rare occasions that I need to?). Perhaps systems could directly self-update the root Xen image on reboot? I don't know why I'd have turtles-all-the-way down and then require some ugly update system that involves editing RC scripts.
viraptor 17y ago
You can achieve that now. Just by running java as the main process. Erlang can do that (more or less). People run dedicated machines where erlang vm is the init script. With the ability to distribute code in a cluster and update a live code it's a perfect environment to manage :) Running different services is already implemented through the standard "supervisor" processes.
- antonovka 17y ago
  Java (or Erlang) as the main process can't (easily) configure the network adapter, add routes to the routing table, access/configure the IPMI module, modify firewall/IP forwarding rules, etc, etc. There's still a lot of shell-script automation that has to be done via tools like chef/puppet/cfengine.

jrockway 17y ago

Good observation. I have to say that I find Java generally distasteful, but I feel the same way about UNIX. An "OS" for my applications that is just some OO code I interact with would be much better than random shell scripts that talk to other random shell scripts via unstructured one-way text pipes. Turtles all the way down, indeed. Of course, UNIX is trying to fix that too... so it will be interesting to see how this evolves.

tezza 17y ago

I'm all for this JVM re-implementation project, but the sysadmin aspect is just going to be pushed one level up the the Xen image host. You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ssh to xen master upload new xen image adjust xen master rc scripts to load new image on startup Hardly turtles-all-the-way down

antonovka 17y ago
You'll need some mechanism to re-deploy major updates that cannot be accomplished via custom mechanisms, and that's most likely to still be ... Why wouldn't the virtual machine bootstrap itself from network loaded code -- then it wouldn't be necessary to update the root Xen image. Why couldn't I write a network service (also on the VM) that runs on other Xen instances and serves up the netboot code? Why would updating the root VM require SSH? Couldn't I have a nice web management UI that I can just upload a new bootstrap JVM image to (on the rare occasions that I need to?). Perhaps systems could directly self-update the root Xen image on reboot? I don't know why I'd have turtles-all-the-way down and then require some ugly update system that involves editing RC scripts.

viraptor 17y ago

You can achieve that now. Just by running java as the main process. Erlang can do that (more or less). People run dedicated machines where erlang vm is the init script. With the ability to distribute code in a cluster and update a live code it's a perfect environment to manage :) Running different services is already implemented through the standard "supervisor" processes.

antonovka 17y ago
Java (or Erlang) as the main process can't (easily) configure the network adapter, add routes to the routing table, access/configure the IPMI module, modify firewall/IP forwarding rules, etc, etc. There's still a lot of shell-script automation that has to be done via tools like chef/puppet/cfengine.