OSDev.org

I think application installation creates an unnecessary step for most users. Installation can be time consuming and take up disk space, especially when you want to test a program or use it once or twice (for example, you receive an email with an obscure file type attached). Some systems like Zero Install, Microsoft ClickOnce, Java Webstart exist and are close to what I mean, but they're not integrated in to the OS, just sit on top.

Imagine a desktop operating system running on a computer with an Internet connection. There are online software repositories that any individual/company can host online and they can be browsed through the shell just like directories (as well as a directory of common repositories that the OS's vendor manages). Launching an application is as simple as double clicking it (GUI) or typing it's name (CLI) while in the directory. The closest you can get to 'installing' an application is creating a shortcut to it in your start/launch menu. If you want to improve loading times or you know you're going to be without Internet access, you can drag/copy the application to your computer.

As for the implementation, repositories would operate over HTTP/FTP/perhaps even BitTorrent. Applications would have a local directory in which user settings can be saved to (some programs may store this temporarily which gets deleted when shut down, others on the disk and there would be a manager for this, so how much space an application takes up wouldn't be hidden for those wanting to find out), as well as a cache (20% of disk space for example) in which commonly used files are stored to speed up programs significant. The API could also expose functions to precache data before it is required, such as a game precaching upcoming level data in a background thread, so there aren't any significant loading times.

Applications wouldn't be 'single files' as it may have been implied above - that is purely for browsing. In fact the program could actually be a directory with a file with meta-data inside describing the application it contains (similar to how autorun.ini on Windows specifies an icon and executable to run when a disc/k is opened in Explorer). But what I'm getting at, is for the majority of users application will appear (and are) self contained. If you try to delete this directory off the hard drive within the GUI, it could ask if you also wish to delete the user-specific settings also, so you know there won't be any side-effects of using software that you may be unaware of.

MessiahAndrw wrote:There are online software repositories that any individual/company can host online and they can be browsed through the shell just like directories

Sorry, mistake 1 there. If there's one ubiquitous concept ordinary users do not understand it's directories. And users must be able to understand some concept of "installing", as otherwise they'll be wondering where the apps are gone once they are offline, or why there's all these apps on their PC that they just tried out when online. I'm not saying it should be called "installing" though. Also, the gigantic amount of diskspace a modern application takes makes "try via internet" an impossibility for everyone without a fiber connection.


JAL

jal wrote:

MessiahAndrw wrote:There are online software repositories that any individual/company can host online and they can be browsed through the shell just like directories

Sorry, mistake 1 there. If there's one ubiquitous concept ordinary users do not understand it's directories.

That's only one way to do it. The overall concept is removing installation.

jal wrote: And users must be able to understand some concept of "installing", as otherwise they'll be wondering where the apps are gone once they are offline, or why there's all these apps on their PC that they just tried out when online. I'm not saying it should be called "installing" though. Also, the gigantic amount of diskspace a modern application takes makes "try via internet" an impossibility for everyone without a fiber connection.

I agree with what you're saying. The first issue, I was targeting this towards desktop users with 'always-on' DSL connections and the like. You can copy the application to your computer if you know you're going to be without Internet access.

The second issue can be solved through the use of caches (the system would be unbearable slow otherwise). For example, Chief Architect is a fairly large program (1.35GB). Of that, there are around 80MB of executable code in the form of .exe and .dll files (they included the run times for basically every library, the main executable is only 22MB). The rest are resources, the majority (virtually all except for interface graphics I'm assuming) would only be loaded as they are used in the project.

So lets say the user has a 1.5Mbit DSL line and can access the download server at around 150kB/s, if the user doesn't have all the shared libraries in the cache, it may take just over 9 minutes to download 80MB, if they do then it'll take less than 3 minutes to download the 22MB executable. After the first run, this would already be in the cache. I stated in my first post that the cache would have to be percentage of disk space that would run into the tens of gigabytes, and be based around a priority system (frequently used and most newest executables would have the highest priority, while minor resources would be the first to be flushed).

I guess you could call this delay significant enough to constitute 'installation', which is a flaw of the system and the thing I was hoping to avoid. It isn't unreasonable to tell the user to expect some loading time the first time an application is ran (they would have had to download the entire thing under a conventional installation anyway), and the issue is virtually non-existent for a lot of small programs that are less than several megabytes. The worst issue is the cache making a mistake, and deleting a program that you need, requiring you to wait for it to re-download.

The later can also be resolved easily. For example if there is a large program you like, without risking having to wait again, you could 'install' it as such by copying it across (this process could be sped up by using already cached files). But having to do this effectively removes the whole 'no installation' I was going for, but if it works for the majority of applications (I was thinking file viewers for exotic formats) then it will still have its purpose.

In my opinion any software that doesn't reside on my hard drive is utterly useless to me, and very, very confusing to Joe Average who has been expecting to find his apps "installed" since the 80ies.

Not having the app installed locally puts me at the mercy of the app provider. If the provider decides to put a newer version online and no longer serves the old one, I have no choice but to "update". If the newer version no longer offers a certain functionality ("Kate" project management, anyone?), or significantly changes the workflow, my productivity might take a severe hit. Worse, the provider might suddenly decide to charge (more) for using the app. And what happens to my .XYZ files if the app processing that format is suddenly gone for whatever reason? It is not always possible to use "open" document formats.

The trend is towards laptops and mobile users. Not everyone who can afford a laptop can also afford an UMTS linkup (or lives in an area where such a linkup is at all available). Not everyone having such a linkup wants to use it all the times (airport security, power consumption concerns etc.).

Not having to upgrade every now and then can be a requirement, too; in security-relevant environments, or where Service Level Agreements come into play, you will want a specific collection of app versions to be installed, because that's what you tested, what you calculated your risks for, and what you signed the SLA contract for.

Bottom line, I don't see where benefit might outweigh shortcomings here.

The auto-updating feature is both a curse and a gift. You no longer have to worry about keeping up to date, but you are bound by the application provider. If for some reason there company dies along with their server, you can no longer access your favorite old application.

It's kinda a cool method.. but It definitely needs more things calculated in.

Would it be possible to host local mirrors? Would it even be legal?

What if you don't have access to the internet for a week. Are you suppose to let your laptop lay dead? There should definitely be a way to copy the entire app to your computer to be freestanding.

I think the best method of removing the installation process is one step back from what you're thinking. Just have each application self-contained within a folder. The application folders can be stored anywhere in the filesystem. This leaves room for executing over a network, but does not require or suggest it.

Mac OS X does the best job of this I've seen - most small applications can just be dragged and dropped to any folder and run immediately - but there's definitely room for improvement. One issue is that there is no CLI support, because it is impossible to index all the applications without a common location or installation process. Another is that it is hard to install static/dynamic libraries, because that would require some sort of central registration done by an installer - a similar problem to executing from a CLI.

Unless, of course, you make it so applications will only run from some kind of standardized location(s) (think /bin, /lib, and friends under a *nix-style system). Then you just have to make it clear to the user that these things can only be used in the proper locations (but don't beat them over the head with it every time they do something).

Hi,

It would be possible to combine this idea with "traditionally installed" applications, and maximise the advantages while minimising the disadvantages.

For example, you could support "auto-install during application startup" (where the user starts the application, and the OS downloads files in the order they're needed and then downloads the remaining files that weren't needed); so that the user doesn't have to wait until it's all downloaded before using any of it. You'd also be able to cancel it - for e.g. the user could try an application and if they don't like it or don't want it, they can remove it before the entire thing is downloaded.

You'd also be able to use it for software upgrades - e.g. have a file list for each application, and check which files have been changed during application startup and only download the new/changed files.

Of course you'd still be able to install and remove applications the traditional way - some people just don't have internet access, or the internet access they do have is unreliable. You'd also want to make it configurable, so the user can disable the "auto-install during application startup" feature (and do something like "install <application_name>" to install it and "remove <application_name>" to remove it; or just unzip and delete the application's directory); and enable/disable the "check for upgrades" and have a "check for updates now" button they can use; or tell the OS to automatically check for updates (e.g. once every n days).

You'd also be able to have a "delete application's files that haven't been used for ages to save disk space" feature, where the user can enable this feature for some applications and disable the feature for other applications; and set the default behaviour.

Mostly what I'm saying is that it wouldn't need to be "one way or the other way" - you could combine both ways.


Cheers,

Brendan

I'd be fine with something like Brendan's "auto install on startup" idea, under the condition that it doesn't get in my way. That means installing to my hard drive so I can run it in the future without an internet connection, allowing me to install things manually, and not abusing it for ridiculous anti-piracy measures. The last one is what every company seems to have problems with, and I'd definitely stay very far away from a SteamOS.

I'm not sure if this was already covered in the thread, but maybe a concept like this:

You have a dir, (/) being the logical separator in this case:

/alias/alias.info containing logical links that your kernel uses to understand file types. Say for example, you have: etc, and the kernel checks if the extension to the binary is ".myos", if then, it launches the binary from "apploader." Inside of the custom app,you might have something like this (just an example) Just a really small quick example that I made up. Could be like, .mysource, just as an example. You could have something that compiles it to a binary as (*.myos). It creates a new application that can be populated with windows, and adds a button and label to the main window, then adds the main window to the app. I think that's a good concept for managing windows, as you can create loads of windows that are a child to the main app, and you can make a method from any window to close the entire app. If the above was for any actual language, but it follows a PHP syntax.

Anyway, going back to the original point of your post, you could make the /bin/apploader load the application binary, and the app can only access information from /TEMP/%RAND%/appid or something, (%rand% being random if two instances of the app binary are present). If the application needs permanent storing of files, it can store them in /app/appName, typically a more major program. A smaller program would probably want to use the TEMP storage.

Hopefully that helped out a little bit, and was probably much more then needed, but hopefully it was useful even though I went off from the original topic a little bit.

You seem to be confusing a GUI and a method of loading applications with the method used to install them. (Also: why generate random numbers? PIDs exist for a reason.)

scgtrp wrote:You seem to be confusing a GUI and a method of loading applications with the method used to install them. (Also: why generate random numbers? PIDs exist for a reason.)

Ah that's true, I was trying to use the concept of a GUI to hopefully better understand what I meant. I meant for the application to be able to access a local directory to read / write files, storing app settings, etc to prevent application installation?

isn't this what google are trying to do with google apps? It could work, companies LOVE this kind of thing. Sure, it takes control away from the user on the PC but companies love this too! If you are going to implement this allow for some sort of enterprise control centre, where you can lock an organisations versions of specific apps at a given version. For example, lets say you have two apps, remotespreadsheet and remotewordprocessor. These have two versions 1.0 and 2.0 each. Company A could specify that all users within their domain are to use remotespreadsheet 1.0 and remotewordprocessor 2.0, when the user navigates to the app, this version is all they see. Company B could specify that there is no restriction, and that the latest version is always retrieved.

Just some things to think about, i know that the company i work for would definitely be interested in such a system if it was reliable, well-engineered and well supported.

Reliability cannot be overstated. Remember that if your application repositories are down, every user of your os CANNOT do anything until it comes back online! Maybe caching would also be of benefit for this. I'm sure youve already thought of that

Good luck!