JNode could make the concept of "installation" obsolete
Submitted by sanity on Mon, 08/16/2004 - 16:01.
Done right, JNode could be the first "zero install" operating system. This idea is tested by Zero-install, but an OS would really need to be built from the ground up to take full advantage of the concept.
Essentially it allows you to mount the web as a filesystem, and access files on the web as if they were on the local filesystem. These files are then cached locally, such that repeated accesses of the same file are pretty-much as fast as accessing them locally, becuase you *are* accessing them locally. For example, you might install and run a new app just by executing a binary at /www/www.mozilla.org/firebird/1.6/firebird.exe - Firebird is then downloaded and installed.
The benefit of this approach is that it allows you to eliminate the process of "installing" software - rather the user just runs a binary directly off a website, and any dependancies it has will automatically be downloaded to their computer. It is as if their operating system comes pre-installed with the latest versions of every piece of software they might want to install!
This approach could be implemented with a custom ClassLoader in Java, although implementing it as a filesystem may have advantages over that approach.
JNode has great potential to be a next-generation operating system, and I am conviced that one day the concept of software installation will be little more than a relic - JNode can be a pioneer here.
- Login to post comments
JDistro does it
It uses a specific classloader and a cache. It runs quite well and you don't need to install applications anymore (but installation is still available). Could be also used for plugins. There is actualy three modes: local, remote and once. The first one is an installation (so you can edit it), the second one is created at each session and the last one is available only during the current session. There is still room for improvements but it is already very usefull since it takes JNLP, Applet tag, JAR, JAD, InstallAnywhere LAX. MLet, WAR and EAR are under consideration. You can use any URL protocol to get the resources.
Problems
Hi, Im new here.
I have been monitoring your discussion about using the internet as a kind of filesystem, and it sounds intersting. But there are serious problems with trying to use code that you get from the internet.
You have to worry about security, dependencies, versions, moved files, and malicious alterations of good files, just to name a few. You do not at this time apear to be prepared to handel these problems.
But I am. I am the admin of the Juse Project which is a pure java platform that aims to do exactly what you want; Create a safe environment for users to access and run code that is from questionable sources on the internet.
I have been working alone, for almost a year on Juse and have not yet made much noise because I did not have even an alpha product to show. But now I do.
Juse is a full package, every thing that a user needs to run community build java applications safely and easily. Instead of me taking pages here to describe all that juse does I would ask that you take a look at the home page and also evaluate my product.
Use a cvs client to get the "jusedevel" and "demo" moduals from
pserver:anonymous@cvs.sourceforge.net:/cvsroot/juseproject
The devel modual has an ant build script, but you will need to compile
the (three) sources of the demo modual by hand.
Follow the instructions in the readme found in the demo modual and look over my code and docs.
I have been working alone so, my documentation isn't great but it should answere a lot of questions.
Please ask me any other questions you have about the product. I look forward to discussing this.
T.
Interesting
I agree with you that there is an inherent security risk in running anything you didn't write or audit yourself, but that problem is not made any worse by "zero-install", and in many ways it is made better since it makes sand-boxing easier (no root access is required for installation). If you haven't already, I suggest you read about capability-based security.
Why not URL's & caching
Hi,
I like this idea, but i'm a bit puzzled about the filesystem part. Why not use regular URL's. Then we don't need another filesystem for every protocol. Also URL support is widespread in java & in JNode, so that should work just fine.
Is there also some caching present in this idea?
I think it is unwise to just load an app every time it is used. Java webstart does this caching which is in my opinion wise.
Ewout
Re: Why not URL's & caching
I think it depends on how JNode plans to locate and execute software. From my understanding, the jar manifest file cannot specify dependencies on jars which reside on remote web or ftp servers, which would be essential for this to work, so I am not sure that Java's existing facilities are sufficiently powerful to achieve this.
Also, yes, caching is an essential part of this idea.
Jar Dependencies
The JAR manifest file can specify dependencies on jars that reside on the same URL as the JAR that contained the manifest. E.g. the manifest of the JAR http://somewhere.org/dir/iamthe.jar can contain an attribute listing 'theother.jar, thethird.jar' and they will be loaded from http://somewhere.org/dir/theother.jar and http://somewhere.org/dir/thethird.jar.
Sebastian
Ok
That is interesting, but it is insufficient for what we are talking about here.
security / availability
Maybe it would be better to be able to reference remote files (e.g. libraries) directly.
But I think this restriction was introduced explicitly so your application only relies on files you can directly control. E.g. otherwise the operator of the remote site would be able to replace the file your application refers to by an incompatible or even malicious version.
Additionally it supports higher availablility of files since less applications are impacted when the original file becomes unavailable.
Sebastian
I don't think its an issue
All Zero-Install does is automate a process that occurs manually anyway - the "oh, I need X to run Y, I should install it". While the zero-install approach does not solve the problem of whether you should trust X, or whether the web server on which X resides will be up, it doesn't make it any worse either, and can incorporate automatic safeguards against both problems (such as fallback mirrors, and signature checking).
Interesting idea !
It's an interesting idea and has some things common with java webstart.
But without automatic updates (need to be done manually).
I think it can (and should) be applied to JNode but maybe with some adjustements.
I agree with the idea of implementing it as a filesystem because it may allow user with no net connection to transparently load apps from a local filesystem (on a CDROM for example).
Fabien
Cool
Glad someone likes it
It's an interesting idea and has some things common with java webstart.
But without automatic updates (need to be done manually).
Automatic updates could be achieved with relative ease, the user could configure how ferquently it should check for updates, perhaps once a day or once a week.
I think it can (and should) be applied to JNode but maybe with some adjustements.
I agree, Zero-Install is designed to work with a pre-existing operating system, but with JNode we could design the operating system around this concept and thus implement it in a much more powerful way.
Having said that, I think Zero-Install should be a blueprint, their handling of authentication and security seems pretty interesting, as does their handling of versioning.
All of this could mean that all you need is enough of JNode to get a network interface up and running, and there rest of the operating system could download itself using this mechanism.
Need Control
Hi,
all this is good, but I think that JNode should have a Tool that manage that installations (and the DB of installed applications and dependencies, base URLs, updates, etc.), and the related Security.
I've read something about Zero-Install, it seems a good tool, but I don't like the idea to run whithout a sort of installation in the Pc ... but that installation in JNode could be that the "JNode Installer Manager" only check and validates the code, grants the given permission to the packages downloaded, and then executes it.
Wrong ? I'd like to run Applications in a secure way on my Pc ...
Then, in case of updates, how to handle for ex. the case of configuration files modified by the user ? Overwrite, rename old files and use the new, or use the new files (having the application un-configured) ?
For Desktop Applications this is a minor problem, but for ex. if you have a Server Application like Tomcat this starts to be a problem.
Ideas ?
Bye,
Sandro
Zero-install is potentially *more* secure
In many ways the Zero Install approach is actually more secure than conventional approaches, at least on Linux, because it effectively allows you to install applications without superuser privileges. Of course, using the term "install" here is a bit of a misnomer, since what it actually means is that the application is locally cached - there is no concept of installation per-se.
All-in-all I don't think anything is lost by moving away from a defined installation-stage, and plenty is gained in terms of user convenience, and potentially security too. I recommend that you take a closer look at the Zero Install website and read what they have to say about this - I suspect they might have answers for many of your questions already.