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.
Thread beginning with comment 32569
To view parent comment, click here.
To read all comments associated with this story, please click here.
MysterMask
Member since:
2005-07-12

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

jziegler Member since:
2005-07-14

* 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.

That makes sens for OS X or Windows maybe. On Linux distros a set of basic _packages_ make the OS. So in order to have an basic OS, you already make use of packages.


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?

There are repositories for .deb packages maintained by the Debian project and repositories maintained by other organizations and individuals. Users can utilize both of them. Same for .rpm repositories for Mandriva or Fedora Core. Hence I deduce it would be technically possible to create 3rd party package repositories for Windows as well. No freedom lost.

Reply Parent Score: 1

MysterMask Member since:
2005-07-12

On Linux distros a set of basic _packages_ make the OS.

The discussion is not about OS installation but application management. And it's not forbidden for Linux to install additional libraries as part of the OS core, if the library is widely used.
BTW: An OSX system installation consists of a set of packages, too (e. g. the base system, the BSD subsystem, the X11 package, etc.).


Hence I deduce it would be technically possible to create 3rd party package repositories for Windows as well. No freedom lost.

Yes. But that contradicts the repository paradigm. How does your software management system knows where to get software if not from a central repository? You have to configure your management app to get software from elsewhere. And that means "discover" it first - and voilą: your back at the good old discovery paradigm.

The MS example was only to illustrate that people probably would not accept such a thing from a commercial OS vendor, so I fail to see why this would be a positive goal for free software. Centralization might make software management easier but that has a price: Not only does it create dependency, it creates also centralized points of failures and insecurity (e. g. if your repository get's hacked).

Reply Parent Score: 1