Slashdot reports on Sanos: “Sanos is a minimalistic 32-bit x86 OS kernel for jbox appliances. A jbox is a JavaOS server appliance running on standard PC hardware. This enables you to run Java server applications without the need to install a traditional host operating system like Windows or Linux.”
Nice idea. I thought something like this was allready out there. I think this could have been a good way for sun to make some money of Java. Have java be completely free but have something like this to license to vendors for making java powered devices.
Wonder if MS will have anything like this for .net or C# or whatever there java type thing is. I think people could do some fun stuff if they could take there C# or java app right from windows and put it directly into a device. Picture a webpad with one MS Office on it and nothing else. Could make for a nice cheap device for schools and students.
looks very interesting! They have some good info on their site.
’cause it was ideal for my Sun SparcStation 2.
This is something like the (non-existent) Java OS that was talked about back in the late 90s. A great idea to have a minimalistic OS to run Java applications.
Seems interesting when compared to a windows server, bloated by all the unused stuff always loaded in memory. But not compared to a minimal linux server. And, finally, even with windows, the unused stuff will be pushed on the swap partition (server) quickly.
With Linux or Windows, I have all administration tools and hardware support. I have also the (relative) maturity of those platforms. Nothing with Sanos.
I am not able to see any advantage of Sanos in server environment. Can someone enlighted me ?
There might be some .NET sanos-like system at some point, but as far as taking any MS Windows app and put it on the device, it would require most of the MS Windows libraries to be present, so you end up with pretty much what you started with.
Sch: in the embedded device world, being able to cut down on how much memory is required (including hdd/flash/*) can influence a lot the production cost of the device. One simple example is a subscription based wireless hub; prompting the user for id/pwd before enabling packet redirection to the outside world.
The device will always be shipped from the manufacturer pre-configured and thus saving the need to have the configuration tools installed on the box itself. Might use only a 32MB flash cartrige instead of a 64MB (or 128).
I’ve taken a simplistic Linux kernel, and then statically compiled my own init which makes several calls to setup the eth address and loopback devices, etc. The `problem’ is that one can’t statically compile the JVM which I thought would be just very sweet to exec() from my custom init. One of the problems is that though you need to install all the base C/GNU/Linux libraries, most all binaries have the dynamic library loader `statically’ inside the binary itself, thus it will ALWAYS look for /lib/ld-linux.so* which then exposes the /lib/ to the JVM processes which I thought was “not good.”
But no problem because one can place the /lib/ files anywhere, then just call the JVM by executing ld.so first which causes the named ld.so to be used instead of the one compiled into the binary. Then note that Unix JVMs use shell scripts to invoke the JVM, so then you have to statically compile a bourne shell (not too difficult). So here’s how you make this in Linux:
1) Compile custom super-limited Linux kernel, don’t include devfs or /dev/pts or anything of the like:
2) Statically (its the simplest) compile a bourne shell,
3) Create your own init, fork off init, parent sets up IP addresses via system calls and singal handles, child chroots and exec()s the ld.so argumented with the JVM. Compile statically.
4) Set -Xmx JVM arg to the maximum amount of memory,
5) Make command-line listener in Java to take start classes and then run them in their own stack/Thread and set system properties etc.
You can set the init location in a lilo parameter. Ciao,
—
3lixyqueue