In the Free and Open Source communities we are proud of our 'bazaar' model, where anyone can join in by setting up a project and publishing their programs. Users are free to pick and choose whatever software they want... provided they're happy to compile from source, resolve dependencies manually and give up automatic security and feature updates. In this essay, I introduce 'decentralised' installation systems, such as Autopackage and Zero Install, which aim to provide these missing features.
Post a Comment
Member since:
2006-12-06
I say this all the time on digg and only get dugg down. Sadly the greater linux community doesn't like the idea of not having to install software. Installation of software is a pathetic idea which Windoze and Linux seem to embrace. Luckily for MacOS and AmigaOS, it isn't usually a necessity to run an installer of any type - thank god these two OSs exist.
Member since:2006-01-02
Hiding what it's doing means it's not installed? The files it saves its settings to don't count for installation, nor in some cases the virtual mounting thingie (yeah, I forgot the term)? It's nice packaging (I think still better than Klick), but is no more not installed than any other OS--the interface is just really simple, right down the file level.
For ports and things not available in such nice packages, it's generally more difficult. Of course the idea of using many directories off the root at the same time for a piece of software, rather than those being within it, is partly to blame (but it can save space).
IMO, since a Linux distro has finite software available in the repository, you should have all of it available through the GUIs, with some indicator that it is not installed, ten installing it upon first run. This would make things easy as a user, and still not annoyingly hide things if you want to do it some other way; or look inside.
Then, for third-party, just have scripts to support use of RPM and/or similar from the file managers (as in, you click, and it installs, and if the info is in there, even runs--I'm not sure of all the metadata in them).
Member since:2005-07-08
Huh? The only alternative to installing software is SaaS (software as a service). Even dragging and dropping a compressed archive falls under the category of software installation.
No, I don't think I'm being pedantic here. The first time I had to install software on a Mac, it took me a little while to figure out how to get it to install the software permanently rather than run it out of the disk image. Even then it didn't add the program to the Dock automatically. It made me feel stupid that I had mastered Gentoo yet had problems with the "intuitive" MacOS X. I'm not saying it's harder to install software on a Mac than on other systems, but it's not 100% intuitive for everybody. Very few things are.
Further, how do I keep my system up to date? Is there a single command or button? What if the upstream distributor moves to a different web address? Why should I trust a third party to deliver software that integrates nicely with the rest of my system?
I think that searching the web and downloading some compressed archive is a pathetic idea from "Windoze" and MacOS X. Package management takes the guess work out of finding, installing, and updating software, while providing some protection against malicious packages, I might add.
To each his own... but I personally feel that the most challenging aspect of package management for newbies is that it's different.
I see why you get "dugg down" a lot. Notice how you make a strong assertion and then back it up with nothing? You could be right, but you're not going to change anyone's mind like this.
Edited 2007-01-16 04:19
Member since:
2005-12-15
This is a good article and a great attempt to explain the problems, cases, resolutions and summaries of what I feel is a common problem in the FOSS environment.
I guess there is the arguement that this system just adds yet another installation choice adding another layer of complication, especially for less technical users. This is true, but only if a common installation method isn't adopted by the majority of Linux vendors.
Frankly, I think it's very much time to start settling on a single common installation method / package manager. It's certainly a hurdle that I feel is impacting to a degree adoption of Linux.
Installation and compilation via source should always be there. It exists on other platforms and offers a degree of freedom that developers and more technically savvy users want, however for the rest a common solution needs to be used across all distributions.
Fingers crossed.
Edited 2007-01-16 01:46
Member since:2005-07-08
Frankly, I think it's very much time to start settling on a single common installation method / package manager. It's certainly a hurdle that I feel is impacting to a degree adoption of Linux.
My stock argument here is that, like everything in FOSS, standardization will follow consensus. While competing package formats are certainly not a desirable feature, neither is standardizing on a substandard packaging system. Last I checked, still no consensus on the best package manager.
However, one this is for sure: Linux users are being served far better by RPM and APT than Klik, Autopackage, Zero Install, et al. Show me a distro that successfully uses one of these self-contained package formats by default, and I'll certainly reconsider.
Member since:2005-10-31
While I agree that the centralized approach is better, I think somehow encouraging original developers to make applications available in one of those packaging systems can help streamline the packaging and delivery of new versions in repositories to users. Which is one of the points I think he was trying to make. I don't know how familiar the author is with Conary/rPath[1] but I seem to recall it functions based around a similar concept.
While I don't think it needs to be the case that distros abandon their current packaging systems, for things like backwards compatibility, wider ISV adoption and maybe even the reclamation of effort packagers, it would be a good thing for them to look into adapting their processes along these lines. Maybe modifying build tools to import those universal formats.
The idea of making cross distro collaboration easier is not new. Various[2] other[3] efforts[4] seem to attempt addressing interoperability amongst distros without having to give up individuality and focus. I think it is critical at this point to help continue to foster growth and development especially in areas such as polish and refinement.
[1] http://wiki.rpath.com/wiki/Conary
[2] https://launchpad.net/distros
[3] http://freedesktop.org/wiki/Home
[4] http://www.pathname.com/fhs/
Edited 2007-01-16 04:53
Member since:2005-07-08
Definitely a nod for Conary, thanks for bringing that up. Simply put, Conary is like a hybrid revision control system and packaging system. Very promising, because it does what the other distributed packaging systems don't: it actually attempts to make the upstream developer's and packager's jobs easier instead of focusing solely on the end user.
Less so for Launchpad... While it's great that Canonical wants to help OSS projects coordinate and work together, this does not seem like an appropriate opportunity for Canonical to go proprietary. This is not a matter of "proprietary == bad." If Canonical came out with a proprietary remote system administration console, for example, that would be great for the Linux community. But a collaboration tool targeted at free software projects? They had to know this was not going to be acceptable for many projects.
If you want to try and lock-in your corporate customers, go right ahead. If you want to sell premium add-ons to end users, I have no problem with that. But please don't insult the development community by peddling proprietary development tools. That is sooo not in the spirit of free software.
Member since:2006-07-28
However, one this is for sure: Linux users are being served far better by RPM and APT than Klik, Autopackage, Zero Install, et al. Show me a distro that successfully uses one of these self-contained package formats by default, and I'll certainly reconsider.
Nonsense. Linux users aren't being served better just because something just happens to exist in its current form.
Member since:
2005-07-02
...a thread where discussion of software installation will be on-topic. :-)
Kudos to the author for the excellent presentation. these are very interesting project, very much in the spirit of FOSS. Still, I don't think that such an approach should replace traditional package management altogether. I think the author indicates this in the last paragraph:
Finally, we saw that it is often possible to convert between these different formats, with varying degrees of success. Even if most users don't start using decentralised packaging right now, but continue with their existing centralised distributions, these techniques are useful to help the process of getting packages into the distributions in the first place.
This is a very good approach, IMO. Package managers fill a need right now, and remain very good for system software. This allows for a smooth transition where it makes sense.
That said, I still think that this is not currently a barrier to Linux adoption. None of the people who have asked me about Linux have ever mentioned ease of installation of applications as a factor, or asked if software versions were up-to-date. So while I think this is a laudable effort to unify and simplify software installation, as well as improve the communication between users, developers and distros, I would place false hopes that such a system would necessarily attract more users.
That said, I hope solutions such as these become more prevalent, especially for "standalone" apps.
Edited 2007-01-16 02:18
Member since:2006-07-28
That said, I hope solutions such as these become more prevalent, especially for "standalone" apps.
One of the problems is that the independent developer has to be accepted into some repository universe. That's problematic.
I'll add that "system" software would probably best be served by a centralized mechanism, as it is on Windows and OSX, even though the need on Unix tends to be less because of more decentralized (or modular) components than windows.
Edited 2007-01-16 16:47
Member since:
2006-11-14
..for this to "work", all distro must use the same compiler( or only versions that are compatible with one another), the same libraries( or only those that are compatible with one another ), the same kernel ( or only those that dont break anything btw releases), all maintainers must agree on the same patches( or all distro must run the same vanilla kernel) ..all distro must sit and agree on the "right" direction before start moving or have the big players dictates what they want on others ..and the list goes on ..
the dynamics of FOSS development more or less demands this kind of "craziness" ..having everybody lining up and have only the front person start moving before the one behind him/her will slow everything down ..
"Do we need this many people working on essentially the same task?" it looks that way, some task will have to be repeated while others work on different paths advancing everything forward ..
Member since:
2005-07-06
I remember trying to kickstart a discussion to solve this some time ago[1], didn't end that well[2] 
[1]http://groups.google.com/group/linux.gentoo.dev/msg/28441f08ac1cc20...
[2]http://groups.google.com/group/linux.gentoo.dev/msg/02ea221ca44f705...
Member since:
2005-11-11
sounds like a lovely way to destroy your system. and are there really that many package management systems in use? from what i can tell, 80% of linux users are likely using a rpm or deb derived package platform. those who aren't really only have one valid counterargument - the desire to build all code locally a la gentoo.
these "generic" packaging projects were and are non-starters, even if they could create a system that makes sense, utilizes your hardware properly (not one size fits all) and does not destroy your install, no one is using them anyway
Browser: ELinks/0.11.1-1.2-debian (textmode; Linux 2.6.18-3-686 i686; 91x34-3)
Member since:2006-11-24
YES, there are.
http://en.wikipedia.org/wiki/Package_management_system#Examples
Furthermore, as in the case with Ubuntu and Debian, a distribution with the exact same PMS as the next distro can still be incompatible with that other distro.
Member since:2005-08-15
Ubuntu and Debian are the perfect examples showing why decentralised packaging is a BAD idea. If two systems that are so closely related to each other as they are, using the same packaging and installing system, succeed in creating incompatible binary packages, how should a decentralised packaging system solve binary incompatabilities between let's say Red Hat and Debian.
The problem this article about decentralised installation tries to solve is a closed-source problem. If an open-source programmer can't get his open source program into the main tree of distributions, he can provide .deb and .rpm packages. The user can install them quite easily (richt click: install package (in kubuntu and ubuntu that is)), and i.e. apt-get will search for dependencies on the centralised system. It's more work for the maintainer in the beginning (and a lot of work for closed-source programmers to provide .debs and .rpms for all distro's, Opera seems to like this way of working though), but afterwards when distributions start packaging his program he'll get more peer review by actual programmers who compile and support his packages.
This week seems to be about porting problems from the windows world to the FOSS world. First backward compatibility and now binary compatibility. They are only problems to people who want the latest and greatest.
Member since:2005-07-12
Ubuntu and Debian are the perfect examples showing why decentralised packaging is a BAD idea. If two systems that are so closely related to each other as they are, using the same packaging and installing system, succeed in creating incompatible binary packages, how should a decentralised packaging system solve binary incompatabilities between let's say Red Hat and Debian.
This is exactly why you need a decentralised system: your example is a centralised system failing to cope with packages from two different distributions! It's quite possible to create a system that would handle this situation fine.
Member since:2005-08-15
The reason it fails is not because it's a centralised system, it's because you're trying to install a package created for one distribution on another distribution. If that distribution differs too much from the distribution it was created for it might not work. It's perfectly possible to distribute .debs in a decentralised way (opera does it like this). It's a bit more work for opera, but well it's quite easy to install opera on an ubuntu/xandros/mepis/debian/suse... system.
I'd rather see more .deb, or .rpm packages on website than .autopackage packages, for those who insist on installing a program by searching the net and downloading it from a website.
Member since:2006-08-02
This week seems to be about porting problems from the windows world to the FOSS world. First backward compatibility and now binary compatibility. They are only problems to people who want the latest and greatest.
Maybe that's because on Windows backward compatibility and binary compatibility are solved problems, on Linux they're not.
Write and compile a program on Windows Vista using only functions available in Windows 95, then take it to a Windows 95 box, and it will work.
Now compile on glibc 2.4 using only ANSI C functions, take your program to a box with glibc 2.3 and it will fail to start, even though all the functions you use are available. And that's not even going to horrors like thread-local locales, where it won't even work on another libc of the same version compiled without that option, and Fedora Core 6's GCC's DT_GNU_HASH, where unless you compile with special flags, AFAIK your program doesn't even run on any other distro.
It's not that people want the latest and greatest - currently the only reliable way to get unpackaged software installed is to compile it, and ISVs want to write software once and have it work on every distro for all time.
If you know something I don't, please elaborate.
Member since:2005-08-15
Well I know for one that backward compatibility is not solved in the windows world. For example Navision (a MS product), can not run on windows Vista.
Backward compatibility has also it's drawbacks in speed: as in being forced to keep all drivers ever created to be supported, i.e. USB-drivers in windows vs the fasted drivers for USB in linux.
Compatability on binary level is disease that has more drawbacks than it is good for and is something that the open source world circumvents quite well: on source level.It should not be introduced in the open source world.
Member since:2006-07-28
No, just the opposite. Ubuntu and Debian incompatibilites are perfect examples of a subpar packaging system. Scroll (depending your threaded view) up to find links on the Conary packaging system. Fine-grained versioning would seem to solve these incompatibility problems.
Member since:2005-07-08
Like the other poster said, there is a difference between package format and package compatibility. You might not realize how similar .rpm and .deb files are to one another. In fact, most of the spec is identical.
The differences lie in package management and package compatibility. For example, we see that rpm has lots of different management systems: yum, urpmi, and yast come to mind. The APT equivalent of rpm is dpkg, but people simply refer to the Debian-derived system as APT because it is more-or-less the de-facto management system for dpkg.
Further, distributions often change the dependencies, add/remove patches, and even change the names of packages they port from other distros to play well on their systems. The name of the Xorg server package, for example, is different on many distributions, and each distro uses different distro-specific patches.
Could this be made simpler? Yes... but the distros hide this complexity from the user. It is mainly more complex for the distributor and its packagers instead of for the end users.
Speaking of which, this whole distributed vs. centralized package management debate represents a tradeoff--shifting work between upstream and the distributor. With distributed packages, the burden is on the upstream developer to get their package working on as many distros as possible. With centralized packaging, the burden is on the distributor to get as many upstream packages to work on their distro.
Guess what? Developers hate packaging! They want their job to be done as soon as their source tree builds and runs properly. Distributors, on the other hand, are essentially packaging machines. Packaging is what they do best. Why not leave things as they are? Let the developers code, and let the distributors package.
Member since:2005-10-31
Because the Distributors sometimes take long to package. What it should is as simple for developers to package that properly running source tree as taring the folder. Notice that what is described in the article simply generates instructions as to what is provided/needed in terms of files and actions.
Member since:2005-07-02
Because the Distributors sometimes take long to package. What it should is as simple for developers to package that properly running source tree as taring the folder. Notice that what is described in the article simply generates instructions as to what is provided/needed in terms of files and actions.
There's nothing preventing developers to package their applications using statically-linked binaries *and* having the same apps be packaged by distros at the same time. That way those who want the latest and greatest can download them directly from the developer's web site, and those who prefer to wait for the packages to be available in the repos can do that as well.
You shouldn't have to choose between the two, you should be able to use both as you wish. The only thing I can see being a bit harder is managing system menus, but with freedesktop.org that's not much of an issue anymore.
Member since:2006-11-24
Yeah, but can you install that app from the developer's site with a GUI front-end if you wanted to?
Anybody with command-line prowess can pick either solution if they wanted to, while those who don't, but still want the latest and greatest just as much as the next person, will only have one solution available to them.
And unfortunately, that's the majority of the folks who use desktop distros such as Ubuntu....or at least the target audience that those distros are gunning for.
Member since:2006-08-02
Guess what? Developers hate packaging!
Yes, mostly because they have to build 1 package per version of each distro. On Windows, they build one package alltogether.
Distributors, on the other hand, are essentially packaging machines. Packaging is what they do best.
Not by a long shot. A frightening amount of packaging is done by people who don't know what they're doing. Wine, for example, comes with wineserver, a per-user server that handles things like inter-process synchronization, which is started on-demand by wine and exits when wine itself exits. A while back, some distro put wineserver in an initscript (it's a server, right?) and tried to run it on startup, as root!
Like autopackage put it, it makes no more sense for a distro to do packaging than for them to do artwork and GUI design for the app.
Why not leave things as they are? Let the developers code, and let the distributors package.
Developers need feedback from users, and getting feedback from a version you released 6-12 months ago is worse than useless.
Distributors produce one package for one version of one distro - an absolute vendor lock-in.
Distributors have to put in extra work packaging, testing, dealing with bug reports - and that's for each distro. Tonnes of wasted effort being the middle man.
Making a DEB or RPM is an absolute waste of your time - it works today but not tomorrow, it works on this box but not on that one.
The sad thing is, solutions existed for years now, and end users love them (autopackage website gets 500-1000 hits per day), but distros would rather die than implement them.
Member since:2005-07-06
Another approach is to work on a protopackage-format. A standard which sole purpose is to do as much distroindipendent work as possible upstream.
There are a few of those today. We have the autotools, ./configure; make; make install routinte, but it's arguably not very maintainable in the longrun, and not that userfriendly.
Debian is turning into a protodistro.
Gentoo was a "meta"-distribution from the start.
So instead of focusing all effort on how to desing packagesystems to bypass distroefforts (autopackage, klick, zero install, what have you) the effort should be spent on protopackagesystems that makes the lives easier for the user/developer (prosumer) AND distributer.
Member since:2007-01-16
> Guess what? Developers hate packaging! They want their
> job to be done as soon as their source tree builds and
> runs properly. Distributors, on the other hand, are
> essentially packaging machines. Packaging is what they do best.
Often the problem is the packagers. They pack the stuff
without any feedback to the developers. First time you
know there is a package for distro $foo is when sombody
sends you a mail about a bug in the package.
Another thing is the delay. When I release something
i want my users to have the new version ASP. Not when
they buy the next CD or hurd is ready.
Member since:
2006-01-16
These installers do the same thing as the centralized systems, but with all the voodoo contained within the file itself instead of comming from a centralized system.
There are two distince disadvantages to this approach:
1) the files are "distro neutral" which just screams "staticly linked"
2) since they are self contained, there is no centralize means to update them if bugs are found, or upstream dependencies change.
Re-inventing the whell is great, but the wheel has to be significantly better in order to convince people to use it. A distro specific solution offers all kinds of advantages that "distro neutral" solutions just can't compete with.
Member since:2005-09-17
1) the files are "distro neutral" which just screams "staticly linked"
Not necessarily. The article has a whole section on handling shared libraries:
http://osnews.com/story.php/16956/Decentralised-Installation-System...
since they are self contained, there is no centralize means to update them if bugs are found, or upstream dependencies change.
That doesn't follow at all. Zero Install, for example, lets you specify any number of 'feeds' for a single program. One might be 'upstream', another might be your distribution's security team.
Member since:
2006-03-23
What Linux really needs at this point is package generation built into the big IDEs. For instance MonoDevelop and Eclipse needs a plugin each that will let the program select a number of code projects in the workspace. Then, when you build this "packaging project" in the IDE it will generate .rpm, source.rpm, .deb and .tar.gz packages automatically.
If it's THAT easy to generate all the different types of packages then the devs will actually generate all packages. Instead of what we have today, were the big projects (mono etc) typically provides their stuff in all the major packaging formats, while the smaller devs choose their favorite format (and ignore the rest).
Once all projects publish their stuff in (more of less) all the major packaing formats, distros (or users themselves) can stop by at the project website and pickup the package for testing or install/usage.
This "auto packaging" plugin should also generate .msi files for Windows (and whatever Mac uses). Atleast this should be an *option* for Mono and Eclipse which typically generate cross-platform programs. Then if someone creates a Linux-only program with Mono (or hates Windows) he will just not check the "Generate .MSI package" checkbox.
The key is: make it ridiculously easy for the devs to generate top-notch packages.
Member since:
2006-11-20
Member since:
2006-04-10
Member since:
2005-07-07
While the article's example of Alice and Bob having different GIMP versions installed is quite cool, I am wondering how this works when a new user account is created afterwards.
Say an account for user Diane is created after Alice installed GIMP 2.2 and Bob installed GIMP 2.4
Will Diane get 2.4?
What if Bob upgrades to 2.6? Will Diane keep 2.4 or be upgraded with Bob?
Assuming she will be upgraded as this would seem to be usually expected: how can she tell to remain on 2.4? Does she have to explicitly install 2.4 herself, even if it is already installed?
Member since:2005-07-12
While the article's example of Alice and Bob having different GIMP versions installed is quite cool, I am wondering how this works when a new user account is created afterwards.
Say an account for user Diane is created after Alice installed GIMP 2.2 and Bob installed GIMP 2.4
Will Diane get 2.4?
Assuming the sys admin hasn't set up anything, Diane doesn't get any version:
diane $ gimp
command not found: gimp
If she wants it, she goes to gimp.org and tells the computer "Run that program, Gimp 2.4". At that point, the system notices it is already present and runs the version Bob's added directly without downloading another copy.
Member since:2005-07-07
If she wants it, she goes to gimp.org and tells the computer "Run that program, Gimp 2.4". At that point, the system notices it is already present and runs the version Bob's added directly without downloading another copy.
I see, makes sense since both installed Gimp versions have been installed by individual users.
Can a person with elevated rights, e.g. the administrator, install system wide software, i.e. something all users see as installed?
I mean using zero install, obviously they can still use the system's package manager
Member since:2005-07-12
Can a person with elevated rights, e.g. the administrator, install system wide software, i.e. something all users see as installed?
I mean using zero install, obviously they can still use the system's package manager
Sure, the admin just creates a launcher as /usr/local/bin/gimp (man 0alias shows how to create such a short-cut).
Or, the admin can add it to the system-wide defaults the Applications menu (how is desktop specific).
Member since:2005-07-07
Sure, the admin just creates a launcher as /usr/local/bin/gimp (man 0alias shows how to create such a short-cut).
Ah, very good.
Or, the admin can add it to the system-wide defaults the Applications menu (how is desktop specific).
Well, no. Any current desktop implements the freedesktop.org menu specification.
One can use xdg-desktop-menu to handle the installation of the .desktop file to make sure it is installed correctly (even for intentionally incompatible distributions like Mandriva)
Assuming one has, as with the application launcher, a cross-desktop specification for things like MIME type registration, icon sets, etc., can 0install handled this automatically (provided there are available tools the xdg-utils) or is this always a manual step?
Member since:
2005-07-06
This article was really well thought-out and delivered--it's not just some publicity piece. It's clear that the developer/author has taken a lot of time to think about installation and use cases, and is making the next generation of Linux installation technologies a reality. I especially like the idea that different versions of libraries should be matched to different versions of programs, albeit without the needlessly inefficient app-folder method. I wish the author the best of luck, and hope that Zero Install catches on!
However, one flaw I see in your implementation is the cryptographically-derived naming of folders. In the beginning of the article, you point out that non-hash-derived identifyers are much more easily user-readable, yet later on you claim that end-user "Alice" will be willing to go to the Gimp homepage, look up the appropriate hash and compare it to hash-name of the folder that "Bob" installed on the hard drive. Yeah, right! Not only does that sound like the exact opposite of the user-friendly goals you set out with, but it's also incredibly insecure to assume user vigilance as a means of security! All the hash-naming of folders would serve to do is make the end user more confused.
Likewise, the certificate verification dialogue box doesn't seem too user-comprehensible or foolproof--especially considering that the user is told the database is "Unreliable"! A whiteboarding system (either independent or distro-specific) would be much more reliable, but of course then the sytem is practically as centralized as was supposed to be avoided!
It seems as though achieving ease-of-use, decentralization, and security all at once really is an elusive goal...
Member since:2005-07-12
However, one flaw I see in your implementation is the cryptographically-derived naming of folders. In the beginning of the article, you point out that non-hash-derived identifyers are much more easily user-readable, yet later on you claim that end-user "Alice" will be willing to go to the Gimp homepage, look up the appropriate hash and compare it to hash-name of the folder that "Bob" installed on the hard drive. Yeah, right!
I should have been clearer: the installation system does this on behalf of Alice. It gets the hash from the XML file describing the Gimp; all Alice has to do is find the link to the XML file.
Likewise, the certificate verification dialogue box doesn't seem too user-comprehensible or foolproof--especially considering that the user is told the database is "Unreliable"!
Right. Ideally, there should be multiple feeds for this information. Currently, there's only mine, which is "unreliable" because I don't have the resources to check out people's keys or offer any compensation if I'm wrong.
This is certainly an area where a commercial company could add value, but without having to start their own distribution (as they'd have to do now).
Member since:2005-07-06
I should have been clearer: the installation system does this on behalf of Alice. It gets the hash from the XML file describing the Gimp; all Alice has to do is find the link to the XML file.
Aha ok. Although I still feel like having some sort of real-name identifier there would help the administrator find the folder in case of a problem. Why can't the directory name be the program name (as opposed to the URL)--i.e. gimp-2.3-- so it can be installed off of CD? I don't understand what about making the folder a hash makes it more secure than, say, storing the hash information in a separate protected file within the program's folder.
Right. Ideally, there should be multiple feeds for this information. Currently, there's only mine, which is "unreliable" because I don't have the resources to check out people's keys or offer any compensation if I'm wrong.
Aha. Cleared up, although as it is now it's clearly not a long-term solution. My only gripe with the model is that in an office setting, users might not be able to install any software they wanted, since they would be probably be locked into a list of software on a predefined whiteboard server. However, I suppose that the problem of "missing software" would probably be much scarcer than in today's repository model, since hosting such a whiteboard server that certifies URLs rather than individual versions of programs is undoubtedly much easier than having to package and test every new iteration of software by hand.
Member since:2005-09-17
Why can't the directory name be the program name (as opposed to the URL)--i.e. gimp-2.3-- so it can be installed off of CD? I don't understand what about making the folder a hash makes it more secure than, say, storing the hash information in a separate protected file within the program's folder.
OK, so Alice puts a CD in the drive with 'gimp-2.3.tgz' on it. How can the system know that it's genuine? Anyone could make such a CD. The system can't tell, so it can't share it with Bob.
But, if the CD contains an archive called 'sha256=XYZ.tgz', then it can be put in the shared directory. The system can see that it's correct just by comparing the archive's contents to its name.
Member since:2005-07-06
Hmm... while your solution does sound perhaps a bit more elegant, I still don't see why the system couldn't extract an identifier text file from the archive and then compare it to the archive's contents. Also, just to be clear: comparing the hash to the contents wouldn't do a thing to ensure security all by itself; it would also need to be compared to the hash at the project's website, right? Otherwise anyone could create malware and provide a hash to match it, but make it look like normal software. Furthermore, don't the archive contents have to be re-analyzed every time you want to verify their authenticity? So given that the website needs to be accessed and the hash needs to be recalculated in any case, couldn't we just skip the step with the local copy of the hash?
To rephrase: The hash being stored in the local filesystem does very little to ensure integrity of the program. Only by checking the folder's contents against an online hash of its contents can ensure the program's security, which effectively renders the local copy of the hash useless.
Or am I missing something?
Member since:
2006-01-09
Many years ago my first Linux was FT-Linux (and I regret
losing the CD). It installed a base system and whatever packages it was instructed to. HOWEVER it also ran all the other stuff on the CD from the CD with some cacheing.
FT was great to live with, right from the install. Having just installed Ubuntu this week, I am forever going back to Synaptic to pull in one tool or another.
Saying it is a BAD idea because it is difficult makes no sense to me. Humans apply ingenuity to difficult problems to invent solutions - thats what we do!
Let's see it in practice and then decide!
Member since:
2006-04-21
I couldn't agree more. These days I laugh when people say such-and-such software is "intuitive" or "unintuitive", especially if such software is Windows- or Mac-based. To add to your examples, what's "intuitive" about dragging a disc icon to a trashcan to eject it (it should delete all files/quick format/fully format the disc) or dragging an icon to an /Apps folder to install it? (To a Unix user, if the "app" (binary) is dragged to /Apps, then the libraries should be dragged to /Libraries, etc). As a Gentoo user - you're right, as a Gentoo user the "intuitive" way of installing foo is to emerge foo.
Member since:2005-12-31
> These days I laugh when people say such-and-such software is
> "intuitive" or "unintuitive", especially if such software is Windows- or
> Mac-based. To add to your examples, what's "intuitive" about dragging
> a disc icon to a trashcan to eject it (it should delete all files/quick
> format/fully format the disc)
I agree with that, but let me add that next to each ejectable drive icon in Finder there is an eject button (labeled with the same symbol as the eject button on VCRs). I always use this button because I'd call it intuitive (and thus easy to remember), while the trashcan gesture is non-intuitive (I didn't even remember it until now). What is still non-intuitive about the eject button is that it is located in Finder (or rather, that disks appear at several points in the UI at all).
> or dragging an icon to an /Apps folder to install it?
Why, that sounds very reasonable to me.
> (To a Unix user, if the "app" (binary) is dragged to /Apps, then the
> libraries should be dragged to /Libraries, etc).
I didn't have to install additional libraries on my Mac yet, but that's exactly what I had thought I'd had to do. At least that sounds most reasonable to me.
> As a Gentoo user - you're right, as a Gentoo user the "intuitive" way
> of installing foo is to emerge foo.
In "my dream OS", the package manager is no magic piece of voodoo, but simply a front-end to organize /Applications and /Libraries (to manage the vast amount of stuff you'd find there), and to access online repositories easily, to download and verify packages and move them to those folders. In other words: a tool, and not a wizard.