Linked by Thom Holwerda on Fri 16th Sep 2005 21:02 UTC, submitted by Josh
Linux Klik is a system which creates self-contained packages of programmes installable over the web with a single click. In this article Kurt Pfeifle discusses the potential uses of this technology for helping the non-coding contributors to KDE. He also looks at how the system works and the obvious security issues involved.
Permalink for comment 32569
To read all comments associated with this story, please click here.
Member since:

Neat theory roundup but you drew the wrong conclusions.

Now consider the system paradigm. The applications are made suppordinate to the idea of a cohesive system.

A quick look at a linux/unix filesystem (as an example of the system paradigm species) easily proofs that a cohesive system only exists as an idea. Reality looks different, because to get a 'cohesive system', you need at least a fixed standard. However, OSes are "work in progress" and constantly changing: New ideas make old assumtions of the cohesive system obsolete. Undisciplined or uninformed developers will do things in non-standard ways, etc. Therefore, you end up with a mess.

With the application paradigm, this can only be accomplished if each application specifically makes sure to update the user PATHs and add the binary link to an appropriate menu.

You assume that a system needs a "PATH" to find the binary. However, the "PATH" is a concept which applys only to certain systems. E. g. OSX is aware of (new) apps and memorizes the place where an app is located (likewise, the system knows when you move the app to another location or make a copy). No need for user interaction or special treatment within the app if the OS is "clever enough" (Mac OS did that long before OSX)

As for the menu: in the application paradigma, you don't need a menu, since you can locate apps like documents with the filesystem browser. A menu holding links to apps is handy as a shortcut, but it is not a must. For example "viewer" apps (apps that do not create documents themselfes) can be started by the system as part of opening a document of the type associated with the viewer app, hence no need to have a menu entry for it - just open the document..

The application paradigm creates dependency redundency and puts more burden on the package maintainer.

* dependency: The contrary is true. Since the distribution of an app does not depend on the availability of other apps, libs, etc.
* redundancy: Yes, some code might be redundant on your system (e. g. libs). However, if certain code get's very commen, it will normaly find the way into the OS over time.
* more burden on the package maintainer: Hardly, since he can distribute a single piece of software with all dependency the way it was developed, knowing that it will run as expected because the user runs exactly the same code (e. g. installers like InstallAnyware will bundle everything into a package including the JavaVM and will run the java code with the bundled VM, no matter if there is already a VM on the target system. This way, the app maintainer can exclude bugs stemming from using a different VM).

As somebody else pointed out, the system paradigm adds additional burden to the user, since he needs a special app for software management. He becomes dependent on the software management, has to know how to handle it and get's a single point of failure. What if you're software management system insists to install the app under /bin but there is not enough space on the drive. Ever had to clean the Windows registry by hand or had to do similar "emergancy routines" on Unix/Linux if an installation went wrong? Horrible!
With the application paradigm, the user can handle apps like any other document on the system. Easy, predictable and in a controlled manner.
Not enough space on the main hard drive? Copy it to the external drive instead and move it back later, when enough space is available.

The discovery system makes finding and updating applications more burdensome for the user.

Yeah, but adds additional freedom. The repository system works only if you can make sure that software find the way into centralized repositories. However, centralized repositories create new dependencies. E. g. if Microsoft would adopt a single repository system: How would you think an MS user would feel having to get all applications through Microsoft?

Low let's apply this framework in the context of free software. The goal of free software is to provide the vast majority of users with a usable, productive, and enjoyable computing experience.

But is there a unified opinion how a "usable, productive, and enjoyable computing experience" looks like? Sharing a common goal does not include that everybody agrees on the way how to accomplish it. There is no such thing as the "one true way" for problem solving hence you end up with different solutions: different software distribution mechanisms, different repository formats, different UIs, etc. Furthermore, your idea of "software darwinism" and centralized software repositories contradicts the idea of free software (as in "freedom"). Your ideas somehow reminds me of communism ..

Reply Parent Score: 2