Linked by Thom Holwerda on Mon 5th May 2008 21:00 UTC
Ever since I started using computers, I've been baffled by the relative clumsiness of installing applications. Whether we are talking the really old days (launching the Rambo game off a tape), the '90s (running Keen or using installers in Windows 95), or the modern days (still those installers, but now also package management and self-contained applications); it's all relatively cumbersome, and they all have their downsides. I decided to put my money where my mouth is, and come up with my idealistic, utopian method of installing, running, updating, and uninstalling applications.
Thread beginning with comment 312987
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Locking still necessary
by Thom_Holwerda on Tue 6th May 2008 10:05
in reply to "Locking still necessary"
Member since:2005-06-29
Somebody has to decide what goes on the server and what doesn't.
The server?
Who says people can't set up their own server for distributing program bundles? It wouldn't be too hard, as long as the file system on the server preserves the attributes.
I also envision a set of command line tools that allow you to compare/update program bundles. Something like:
$ compare "/Programs/Garden Designer.bundle" "ftp.stuff.org/pub/bundles/Garden Designer.bundle"
Output:
$ /Programs/Garden Designer.bundle:438
$ ftp.stuff.org/pub/bundles/Garden Designer.bundle:439
RE[2]: Locking still necessary
by RandomGuy on Tue 6th May 2008 16:54
in reply to "RE: Locking still necessary"
Member since:2006-07-30
Member since:
2006-07-30
Locking would still be necessary because while queries are fast, installing is not.
Let's say you use one query to install program P and start another query and uninstall library L (something P depends on) along with all older programs that need L.
There are two ways out of this:
a) Using a more fine grained locking along the lines of "install anything you like but make sure not to destroy L since P (currently being installed) will need it". What, however, if you said install P from vendor V and while it was installing told the computer to remove all programs of vendor V. I'm almost sure no matter how smart the algorithm is there'll still be situations where it has to say "Encountered Conflict C, do you want to do x or y?"
b) Making every program completely self contained.
This would have HUGE security implications.
A defect was found in a library that 100 of your applications use? Well, that's to bad, you have to reinstall them all.
You can of course draw the line at some arbitrary point and say this lib is used 'a lot', so it's shared.
In short, while your idea sounds good I believe it has tons of details, corner cases, and trade offs that still need to be sorted out.
Furthermore, it can only be realized embedded in a bigger ecosystem. To revisit the example with a defect in a lib, developers could tag their applications like "works with version x of this library" in a way that the program could automatically tell you "vulnerability found, switching to fixed version of lib L" or "vulnerability found, program not yet tested with safe version of L, do you want to upgrade and risk a crash or keep running this unsafe program".
In addition, your system is still centralized.
There needs to be someone or some server to say "No, malwareGuy, you cannot call this 'Paint 6', there's already 'Paint 5' and you didn't write it".
Somebody has to decide what goes on the server and what doesn't.
I could go on and on but I think you get the point:
The idea is good but the devil is in the details.