Comments on: An old OS idea is new again: non-installation
Comments on: An old OS idea is new again: non-installation
As an OS designer who prefers well-thought-out simplicity over ever-deeper-layers of complexity, I've been annoyed for the last couple decades as I've watched most OS designs pack more and more files into their system and library (including DLL) directories. Eventually, the entire system becomes a mangled wreck of software components that require complex installers, tools, and conventions in order to manage. Take a look at any "modern" operating system as an example, Windows or Linux for instance. What a mess.
This concept of throwing shared libraries into OS global directories has long been thought of as a necessity to allow for greater sharing of common code and data. Back in the days when disks were small and RAM was only a few MB, that approach made a lot of sense. But, those days are long gone and every so many years you've got to re-examine your requirements relative to the advancements in hardware.
Non-installation
Since the late 1990's, I figured if I ever wrote another OS, I'd set it up differently. I never liked the concept of installation of anything (apps, devs, libs), with perhaps the OS kernel itself as the only exception.
While it's useful to perform some kind of unpacking or decompression step as part of app setup (unzip), the idea of scattering application files into all sorts of mysterious places just makes things harder for everyone, developers and users included. And then, there's also the system registry, but don't even get me started on that.
The nice thing about "non-installing" is that your entire app is in one place -- pretty much just a copy of the distribution itself sitting right there. And, wouldn't that be handy in itself, both in terms of backup and also for ease of app removal?
So, you ask, if an app isn't installed, how does the OS know about it, it's icon, file types, boot options, related tools, and other such things? Well, I'm glad you asked. That's the concept of binding, and there's no reason it needs to be done during installation. You could quite easily perform that step during boot by inspecting application header files (preferably written in REBOL) that define those relationships, located in each application directory, of course. I would claim that step would take less boot time than that required these days to sort through the tangled mess of files in the system directories.
In addition, you need a user-specific storage area for prefs and other special data. But, there are several ways to do that, even via user-specific symbolic links. Not a problem.
New or old idea?
Is this really a new concept? No, in fact it's a really old idea. You could setup apps this way on the Amiga back in 1985-86. You'd use an assign (essentially a symbolic link) to access the app's base dir. Pretty simple.
Is it possible on modern OSes? Aren't they just too complex for such a simple approach. Well, it's nice to see someone put together a Linux distro called GoboLinux that does just that. And, they even kept it compatible, so check it out.
Are there others? Quite possibly, and I know you'll post a list in the comment section.
Anyway, I point this out because I really like to see rebellious developers working to make computing systems cleaner and simpler, rather than the usual case of making them insanely complex. Good work, keep it up.
Now, if we can just get rid of the rest of the garbage that clutters up modern OSes, maybe I will find an OS (other than AmigaOS, of course) that I actually like using.
Wouldn't it be nice, Carl, if an entire *program* sort of operated out of a single archive-like file? :) You know how one can peer into a .ZIP file on Windows and see the contents--and some programs let you extract just a single file from that to somewhere? What if an entire program package was like that, and came self-contained? If something went wrong with it, you'd just reinstall that program. A single TOOL.
I get what you're saying about the shared libraries--these days, with capacities running at more-than-enough-room, and there being increased CPU speeds and more memory, the necessity of shared libraries is minimized. Or moot.
Back to the old? :)
Imagine the registry, if all programs and apps were self-contained packages. Wouldn't really need one. I think 'installation' has more to do with security and copyright these days, than anything else.
--EyeAm
http://www.myspace.com/foadiyops
Allen 21-Oct-2008 15:27:07
To keep the drm and software licensing guys happy, you'd have to have a way that copying wasn't too easy. I think that is the real reason MS moved to the central registry.
But it would be easy enough to make a compatible license method using public/private keys.
Ged Byrne 21-Oct-2008 15:41:14
Isn't this how OSX works? I install well behaved applications by opening up the archive and dragging the folder into Applications.
Thaddeus Quay 21-Oct-2008 16:25:58
NOTE TO CARL: I could not post the following, neither from my IP, nor from a proxy, because: "Blogger Error: Duplicate posting or abuse detected from [IP]." I then tried your private feedback, which gave me: "Spam links pollute and ruin the web for everyeone. This feedback system does not accept such links. Try removing the URL scheme and post it again." So, now I'm trying without the protocol on the URLs.
"What if an entire program package operated out of a single archive-like file, and came self-contained?"
"With binaries available for dozens of Windows, Macintosh, and Unix platforms, Tclkit is the easiest way to develop and run scripting code, and is the engine powering Starkits, an incredibly portable single file deployment solution for your applications."
equi4.com/tclkit
"A Starkit creates the illusion of a 'file system in a file' - on the outside, it's a single file, yet the application code continues to see a complete directory of scripts, extensions, packages, images, and whatever other files it needs. Starkits can be multi-platform."
equi4.com/starkit
Brian Tiffin 21-Oct-2008 19:13:40
Thaddeus Quay beat me to it. Starkits are awesome.
But a 16K TRS-80 Model I with a cassette tape loader was even better. One thing at a time, and twenty minutes between things. ;)
I don't know if I am tainted, but Debian is super complex yes, but package maintainers do all the fiddly bits.
$ apt-get app
has worked everytime for me. Even with Lenny. So smooth that I rarely have to think about it.
Cheers
Bill 21-Oct-2008 20:50:17
maybe http://0install.net/ by Dr Thomas Leonard,
thats "zero install"
pup 21-Oct-2008 23:53:33
its nice that you again bring up the "old is new again", and its seems your getting finally getting back to the original "Rebol as the [web!]OS" and wanting to push that again,Good.
but isnt this to late now the other OS is available that everyone hyping now is taking hold?
"this form of self contained scripting worked great for linking
shell/cli apps together once we had a good base to work from
shame no ones done something like this a a full working package
for rebol GUI front ends etc, perhaps one day, although iv been
waiting a very long time so far..............
its a shame the blog will mees up the formatting but heres a blast from the past, and still the best way to work your apps as self contained, the so call self contained zip/rar/LHA,etc with all your required files never did take off though as it want included as a standard app in itself, if you need to add it later it wont get used as much ,simple.
--------------------------------------------------
.key file
;$VER: SID_VIEW_GUIDE GUI
failat 9999
;- Setup Programs & paths
Set Read="Run SYS:Utilities/AmigaGuide"
Set HedEd="Run work:Editors/Heddley"
Set GoCed="work:editors/ceded"
;- End Setups
if exists env:edosguide
set req=$edosguide
skip skipreq
endif
Lab start
set req=`RequestChoice "SID_VIEW_Guide GUI" "Select type to read*N" "Exit" "Read"
"HEDDLEY" "Edit"`
if $req eq "1"
Skip Exit
Endif
lab skipreq
if $req eq "2"
$Read ""
endif
if $req eq "3"
$HedED ""
Endif
If $req eq "0"
$goced "" -s
endif
if exists env:edosguide
skip exit
endif
;optionally ask and store a variable so as not to keep asking
;set storeq=`RequestChoice "SID_Guide GUI" "Use as default for this session" "Yes" "No"`
;if $storeq eq "1"
; setenv edosguide=$req
; skip exit
;endif
;skip back start
Lab Exit
---------------------------------------------------------
--
Best regards,
david
"
EyeAm 22-Oct-2008 0:42:13
Thanks, Thaddeus. That seems to be like what I was thinking about. I wonder why such a thing hasn't caught on with third-party Windows programs.
So, I guess something like that would let a program (all wrapped up into an executable) be dragged or copied to a USB jump drive, and still run? No install, no calling anything from the OS? One of the pages on that site says it "runs out of the box".
I was thinking about programs and applications being the single file, and being able to be shared 'like a book' you'd loan a friend or something. Like what Carl says above, "a copy of the distribution itself". But, I suppose commercial considerations (copyright, etc.) would probably be taken care of in a header file. For permissions, etc. Maybe similar to how PDF files can be made to allow or disallow printing, copying, and so on. Hmm.
--EyeAm
http://www.myspace.com/foadiyops
Carl Read 22-Oct-2008 1:01:36
Well over a decade ago I wrote something somewhere called "I Hate Installing Programs!", or words to that effect. And I've not changed my mind.
I also think installation hassles are what's causing people to prefer web apps. Apart from the initial installation, there's the endless updates, many of which will take as long as the original one. Much easier to just visit a webpage.
Latest example of the move to the browser? Joost. Still has a plugin, (or did last week), but with the promise of it not being required in the future. Search google news for lots about this.
(Slightly off the topic of single-file installations, but note that most users wouldn't notice the difference - and they still hate installing programs!)
Luis 22-Oct-2008 4:04:05
I've been messing with PCBSD pcbsd.org, and it uses pbi files for installs.
They've an online directory of them pbidr.com
There's a pbi 'maker' to convert 'standard' installs methinks.
You can still do the source ports if you need/want to.
Cheers,
Luis.
Thaddeus Quay 22-Oct-2008 5:21:07
1-of-5) "Starkits are awesome. But a 16K TRS-80 Model I with a cassette tape loader was even better. One thing at a time, and twenty minutes between things."
I put those twenty minutes to good use, by improving my typing skills, because when I was young, my first computer was a 4k TRS-80 Model I, with no cassette. That's right: When I wanted to run a program, I first had to type it in, every time. Also, I walked to school without shoes, and my fanciest toy was a cardboard box.
2-of-5) "I guess something like that would let a program (all wrapped up into an executable) be dragged or copied to a USB jump drive, and still run?"
A Starkit is a single file containing your application, as well as all of the files your application will read and write, managed through an embedded virtual file system. A Starkit requires the target machine to have Tcl. If you want to distribute to a wider audience, such as to people who likely don't have Tcl already installed, then you need a Starpack, which is a Starkit plus an embedded, streamlined Tcl installation known as Tclkit. You must create a specific Starpack for every target platform, but a Starpack for any platform can be built on any platform. Theoretically, you could create a major application, on your own, on a single machine, using only the environment to which you are accustomed, and distribute it to every major platform, as Starpacks.
equi4.com/wikis/equi4/189
equi4.com/wikis/equi4/191
3-of-5) "I think 'installation' has more to do with security and copyright these days, than anything else."
a) I want to get paid for my work, but digital rights management is nonsense.
craphound.com/msftdrm.txt
b) I want to protect my work, but digital copyright is nonsense, because any computer file can be interpreted as a number, and numbers cannot be copyrighted. There is a detailed paper about this, but as I don't have it handy, I'll put forth the following example.
monolith.sourceforge.net
4-of-5) "I also think installation hassles are what's causing people to prefer web apps. Apart from the initial installation, there's the endless updates, many of which will take as long as the original one. Much easier to just visit a webpage."
I want the ability to simply sit down and work on my stuff, from any computer, but for a number of reasons, web-based apps just don't work well enough today, and they have minimum software requirements, which may not be met by every machine I am likely to use. Also, web-based apps imply cloud computing, which won't truly exist, until millions of machines, including yours and mine, are providing CPU time and/or storage, to anyone who needs these things, securely and anonymously, with some sort of micro-payment system in place. Google and Amazon cannot be trusted, partly due to their TOS, and partly due to the fact that corporations are effectively government agents, because they must conform to the wishes of those entities which grant them license to exist.
Thaddeus Quay 22-Oct-2008 5:26:02
5-of-5) REBOL has a chance to make a dent in these various problems, but that won't happen until v3.0 is out and is stable. Also required is a definitive book from Carl, on how to think in REBOL, similar to "Programming in Lua", by its chief architect, Roberto Ierusalimschy. Finally, there needs to be a plan in place, on how REBOL code can be written, reviewed, and distributed, with an eye towards creating an anonymous, distributed system of storage and computation, with anyone interested being able to easily join in. For example, this could start out as simply as using an online journaling system for a purpose for which it was not intended.
Create a community on LiveJournal, where every entry is a small piece of working REBOL code, and where the comments are people putting forth their observations, as well as their improvements. Every journal entry has an absolute, unique URL. An application could then simply be a list of such URLs, parsed by my REBOL installation. The URL list would come from a trusted source, possibly a journal entry from the personal LiveJournal account of someone I know. The resulting application installation, on my machine, could be as simple as the REBOL version of a Starkit, where security is assured through me knowing that the application will read and write to only the single file that the LiveJournal-based installation process created. I'm not saying that we should actually use LiveJournal for this purpose, but it's certainly a workable model, particularly given that it would merge the heretofore-separate processes of code creation, review and distribution.
The LiveJournal example is only a step away from realizing the real-time distribution and execution of code, as in the following example using Tcl and Starkits in a laboratory setting. Once this is achieved with REBOL, then secure, paid, anonymous distribution of storage and CPU time can't be far behind.
That is why I did not like View installing itself by default. But otoh, when you wnat to cover "normal users", without the installation, how would you do file associations for e.g.?
seb 22-Oct-2008 6:50:49
For Windows; consider VMWare Thinstall, I've been virtualising a whole bunch of applications onto my SD card since I have to hop from machine to machine all the time.
Application.app 22-Oct-2008 7:20:20
You have very elegantly described the design of the MacOS .app directory. To the user, it looks and acts like a single file. You can run the .app file from a USB, CD or drag it to any place on your hard drive. Double-click and it opens the application. Right-click and it gives you the option to "Show Contents". There you will find an entire directory structure with icons, resources, binaries, etc. To 'uninstall' the application from your drive, just drag it to the trash. There is no 'installer'. There is no 'uninstaller'.
Jeff Katz 22-Oct-2008 7:57:42
You've just described OSX.
GoHaiku 22-Oct-2008 8:20:51
Ever tried BeOS and/or Haiku?
Software installation goes like this: unzip the package. Tada!
(there is a fancier package management, but it doesn't really adds that much)
Ricky Nelson 22-Oct-2008 8:26:12
I smell a soon to be Mac convert :)
Jason 22-Oct-2008 8:36:38
I guess the author hasn't used OSX is many, many years...
EvilTeach 22-Oct-2008 8:48:14
another benefit of all files in one place.
you can back it up and restore it
after you reinstall windowz xp for the 99e99th time.
Conor 22-Oct-2008 9:08:54
This is how, for the most part, exactly how Mac OS X installations work.
Jim Oly 22-Oct-2008 9:11:47
This is also one of the ideas behind portable apps, though perhaps your idea goes further on issues like binding.
Pat Kushko 22-Oct-2008 9:25:01
Screw that, just bring back the Amiga OS 3.1.. I knew then, when shared libs starting getting out of hand when most shared nothing, all did the same thing and grew bigger daily that the OS was turning into a political ballgame of who's idea was better.
Looking at netbooks, there is opportunity for simplification and more sane values, let's not blow it.
Ken 22-Oct-2008 9:50:11
You should expand on this, because it sounds intriguing but I'm missing some things.
Does each app have all of its own libraries, too? That might not be too bad on disk, but it would still be a huge download, and take a lot of memory: shared libraries take less space in memory, not just on disk.
Or maybe libraries could have some kind of unique identification hash, so it contains a library but can tell your OS "use the system's existing copy of libfoo, if you already have it". (I think the Mac does something like this.)
pup 22-Oct-2008 10:08:08
the biggest problem with windows/linux is you dont have a RAD (recoverable Ram drive)that can keep its contents after a warm reset.
but saying that, SLAX linux gives you the ability to save your changes and run directly off a USB2 stick and carry that around with you, booting any PC your sat at and continue were you left off.
its app Module design is also easy, you just download what you want and put it in the modules dir or made your own module and share it online if you like, plus other useful IP options, check it out as see if it works for you
and you can simply make a Bootable USB stick from inside windows adn drag the two slax dirs over ,run the script and your done, with one required step you need a fre 3rd party windows app to format the stick in the right way first.
its not amiga style RAD rooting, and linux assign and set type commands are nothing close to as easy, but its better than your usual fixed PC,liveCD way booting way although you can do that too with a simle drag/drop OC.
http://www.slax.org/forum.php?
Scott 22-Oct-2008 10:32:19
I rather like how Eclipse just unzips to a directory and off you go.
atc 22-Oct-2008 10:49:44
I think you misunderstood the concept of "Operating System". The concept of an OS is an interface between the hardware and the user. What you're referring to is package/software management, which the different Linux distributions happen to do very well - apt, portage or yum - to name a few.
antichris 22-Oct-2008 11:09:17
Blizzard Entertainment has already adopted this principle. If you install World Of Warcraft, it settles into a directory and doesn't fiddle with registry or any other paths, it's all self-contained in the spot you install it.
NickM 22-Oct-2008 11:32:36
Mac OS X bundles work this way, to a degree. Both applications and frameworks are bundles consisting of code (executables, libraries) and resources (metadata, images, sounds, text strings) and bundles can be placed in a very flexible way. Still, some applications use installers and some genuinely need to be separated into different bundles (e.g. because one component is a driver or preference pane or something like that).
I'd like to see the Mac go farther in this direction, because right now there are lots of cases where bundles break down.
Tim 22-Oct-2008 12:01:14
An example application that works as described is Xplane. Everything is contained in one folder, and it works the same on mac, linux and windows.
So it is possible to create stand alone applications now.
I also think it's a good thing to store user preferences in a users home folder, so they're easy to backup and move between computers.
Acorn computers were good at this too, with RiscOS. Each application was a self contained directory (a bit like MacOSX application packages)
shane 22-Oct-2008 12:57:49
Citrix does this right now. It's called application streaming. We package windows programs into one file "stream" and publish the apps via terminal services. Office 2k7, custom programs, etc. Works great. Even runs from local laptops when disconnected from network.
Look up "Citrix Streaming".
At the OS level we use 100% virtualized terminal servers, which are just two files, with NO applications installed on them other than Server2k3 and Citrix.
Makes backups a breeeeeeeeeeeeze. Runs fast also.
BC 22-Oct-2008 12:57:54
Has anyone mentioned Mac OS X yet? Just want to be sure someone mentions this, because maybe no one knows about it.
Aleks 22-Oct-2008 13:04:19
Wouldn't it be nice, Carl, if an entire *program* sort of operated out of a single archive-like file? :) You know how one can peer into a .ZIP file on Windows and see the contents--and some programs let you extract just a single file from that to somewhere? What if an entire program package was like that, and came self-contained?
Have you heard of this brrrrand new *shiny* technology, called JAR?
In fact, almost *all* Java applications usually only require the 'installation' of one file. Pity that you will also have to place a shell-script wrapper in your /bin directory. But that's not really a mistake on Java's side.
Brian Tiffin 22-Oct-2008 14:13:18
Thaddeus;
Oops, gee, I hope you didn't think I was being sarcastic about the Starkits. I agree. These bundles are great.
The comment about the old Radio Shack machines was a joke harking back to the good old days of "too much" simplicity. But I'll admit your
Also, I walked to school without shoes, and my fanciest toy was a cardboard box. got me to laugh out loud.
Cheers
Brian Hawley 22-Oct-2008 22:11:47
Has anyone mentioned Mac OS X yet? Just want to be sure someone mentions this, because maybe no one knows about it.
This definitely made me laugh out loud, and not just because so many people had already mentioned it.
Mac OS X apps leave preferences and resources in all sorts of hidden system directories. The apps that need installers generally don't come with uninstallers, particularly the ones installed with Package Manager. It's also hard to tell what files an app can handle or associate (this one may just be my lack of knowledge).
App bundles don't necessarily make things any easier. I can't count the number of times that I had to open an app bundle and manually fix permissions in the underlying files, or even drop to the terminal to search for and edit files that are strewn all over the place.
Mac OS X sometimes pretends to be like this article, and when it does it is really nice, especially for major cross platform apps compared to their Windows counterparts, but it still has a long way to go and no clear path to get there.
Carl Sassenrath 23-Oct-2008 1:06:47
So many comments, who would guess? Looks like I'll need to write a follow-up blog.
I find it amusing how many folks pointed at OS X as the solution. As someone who designed OS kernels at Apple, owns several OS X boxes, and builds apps for OS X several times a month, it's closer... but, more on that, and others, in a reply.
And, someone thought I "missed the point" of libs too... sharing and all. Do you think I did? A hint: I brought DLLs to personal computers in 1984 as an integral part of the Amiga kernel.
EyeAm 23-Oct-2008 1:23:28
Why have such in the kernel, Carl? :) Don't need it there.
Put resource management where it belongs: user level!
Resource protection is the only thing needed in the kernel.
Oldes 23-Oct-2008 1:32:21
Aleks:
Have you heard of this brrrrand new *shiny* technology, called JAR?
Yes. It's just renamed ZIP file.
almost *all* Java applications usually only require the 'installation' of one file.
All Java applications require installed proper JRE.
Probably you don't know Rebol as with Rebol (encap) you can make a real one-file application as an exe file which contains everything (Rebol interpreter itself, code, data, images, whatever).
Oldes 23-Oct-2008 1:51:45
I guess that most Mac users just click and move icons and know a very little about it's internals. I'm sorry to the few who are exceptions.
Rakesh 23-Oct-2008 3:02:30
Totally agree... I think the trend is starting to create standalone apps.. uTorrent, portable apps..
That is why I also think that Altiris SVS is going to be a big hit...
Dan 23-Oct-2008 7:42:24
I haven't seen GoboLinux (and I'll be installing it in a moment here) but every OS gets installation very wrong in my opinion. And if they all get it wrong, I might as well use the one that has the features I like and the stability I need (Windows 2003). Now hear me out.
The solution given - to examine application meta-data at startup - is non-optimal. Basically we're factoring out the complexity of the operating system file clutter and forcing developers and package managers to include the same complexity inside each package in the form of meta data. I don't disagree with that idea but the way this guy wants to read it at startup isn't good. Here's how it should work.
The only thing the OS should install is a database (it's up to the user which DBMS is used). There should be a good data model that specifies all application features (icons, context menus, shared user data, the works). When an application "installs" it basically just runs an insert script on the database. When it "uninstalls" it basically just runs a delete on one table and that cascades and deletes all related records. Indexes on the database can be managed by the OS designer or by the user, and the data and is also user accessible (with appropriate user access management).
So now let's say I want to make a desktop widget that searches my applications for me (like Finder does). I just query the system database and make a find-as-you-type thing.
Let's say I want to migrate all my user data AND installed program data (something that isn't even close to possible on any modern OS). I just backup my system database and bring it up on another system. If I try to use an application that isn't installed, it gives me a friendly message telling me where I can download the application file, or at least which application is missing.
With a well thought out database at the center of the operating system's user, file and system management, we can really get serious about eliminating clutter.
If someone tries to optimize something, they better do it right, because anything halfway is a waste of my time. If something is not as close to perfect as possible, there are still exceptions and clutter and poop you have to keep track of, so it doesn't matter to me if I have to keep track of a ton of clutter or half a ton of clutter - same poop, different fan.
EyeAm 23-Oct-2008 12:18:15
Imagine the OS as a parking garage, and your applications are your cars. You've got the keys to your cars, and can take them anywhere you want. Each 'car' has everything it needs in the engine, tank or trunk. ;-)
pup 24-Oct-2008 0:20:50
did you RomWack that dave!
"And, someone thought I "missed the point" of libs too... sharing and all. Do you think I did? A hint: I brought ..."
www.scotek.demon.co.uk/guru.html
#81000002.48454C50
"When the ***** OS crashed, the programmer working with it would sit down cross-legged on the joyboard, trying to keep it in balance thus resembling an Indian guru." ;)
Though nobody who'll be commenting or reading here has probably heard of it, what you're looking for is something like what Acorn Computers' RISC OS did, which is similar to the approach taken in NeXTstep and MacOS X for applications.
Application directories were indicated by the fact that they started with '!', so '!Edit' would be the Edit application directory. This contained a number of files, such as '!Boot', which was executed once the application was seen by the file, '!Run', which was executed when the application directory was double-clicked, and '!Sprites', which contained icons to load into the common icon pool so that the application directory could have a distinct icon.
Internally, though it wasn't enforced, there was a standard layout, with '!RunImage' being the application's primary executable, 'Resources' contained any application resources such as window templates, icons used internally, message catalogues, &c. It was all quite simple and flexible.
Somebody mentioned ZeroInstall earlier. It and its companion, ROX, were both inspired by this aspect of RISC OS, so they're worth examining. RISC OS was and still is a brilliant, if highly flawed operating system and WIMP. There's plenty of information on it online.
Luke Guest 6-Dec-2008 8:09:49
I'm sure that others, like me, would like to know how you would go about designing a new os or what you would put into one? How about that as a follow up blog?
Terry A. Davis 6-Apr-2012 21:49:02
The LoseThos PC 64-bit OS is copied into place and you do InstallBoot(). It's really neat.
Me 7-Apr-2012 3:05:58
This is great if a new vulnerability is discovered in one of the libraries just about any app uses (zlib, the image processing libraries) and you have to update that library 40 times after which you're still vulnerable because 10 authors didn't provide an update.
