OSNews

I don't see how is it in the style of OSX though.

As in drag & drop style installing. The application is statically linked, all the libraries it depends on are compiled within the application, it doesn't depend on system installed libraries. This is to cure the so called 'dependancy hell'.

The downside is statically compiled applications are much bigger in file size, but nowadays this shouldn't be a problem but it also makes updating more cumbersome. Instead of updating a dynamic library, zlib for for example used in all c apps, you have to download updates for every application. If you want to keep up with security updates that is.

I use OSX and really like the drag & drop but i still prefer the debian way.

Not only are their bigger on disk (no-one cares), on the network (some might care + compression helps), statically linked apps are bigger in RAM as well and that still hurts.

I too prefer using a system, which know which files to download, to searching and downloading the files one-by-one.

On the other hand, some of the proposed uses are good - install without having root, easy to install for non-technical types (translators, UI designers). For these reasons, I wish the luck and success with this project, though I probably won't use it.

Not only are their bigger on disk (no-one cares), on the network (some might care + compression helps), statically linked apps are bigger in RAM as well and that still hurts.

This isn't very relevant if you include commonly used libraries in the base system. Non-commonly used libraries would be rarely needed, and thus wouldn't be much of a disk-space waster.

-bytecoder

First, I'm not talking about disk-space waste.

Second, how do you define "commonly used"? Do for example both Gnome and KDE libraries belong there? What about a distro like Ubuntu, where they only care about Gnome? KDE libs would not be included in the "core", hence statically linked to each KDE app - I hope you can see how much that would suck. OK, so you include KDE libs in the "core". What else do you include? What do you exclude? Who decides that? Based on which information?

Too many question for something, that has been already solved by package managers, dependencies and dynamic linking.

IMHO, static linking would be not one, but five steps backwards.

First, I'm not talking about disk-space waste.

size in general

Second, how do you define "commonly used"? Do for example both Gnome and KDE libraries belong there? What about a distro like Ubuntu, where they only care about Gnome? KDE libs would not be included in the "core", hence statically linked to each KDE app - I hope you can see how much that would suck. OK, so you include KDE libs in the "core". What else do you include? What do you exclude? Who decides that? Based on which information?

I've seen this thinking a lot, lately. I'm talking abstractly; if the current linux model doesn't fit, then it's not very good. Doing anything else would just plaster over the real problem.


Too many question for something, that has been already solved by package managers, dependencies and dynamic linking.

You keep thinking that...

-bytecoder

I've seen this thinking a lot, lately. I'm talking abstractly; if the current linux model doesn't fit, then it's not very good. Doing anything else would just plaster over the real problem.

I'm used to the Linux model. I used it for a long time. Maybe that makes me biased, but I believe it works rather well for me. Better than the Windows model I have experienced before.

I'm curious about your model.

You keep thinking that...

Nice to see some arguments

I'm used to the Linux model. I used it for a long time. Maybe that makes me biased, but I believe it works rather well for me. Better than the Windows model I have experienced before.

I'm curious about your model.

Again, I'm talking abstractly For example, the use of application menus is basically a band-aid that covers up the lack of a decent fs layout.

Nice to see some arguments

Heh. You're a funny guy, that actually made me laugh a bit.

-bytecoder

You're not thinking about this the right way. Only small, infrequently used, libraries should also come in the appdir. Things like QT or GTK should be optional add-on components to the base system.

The "Base" system would contain a subset of packages that are common to pretty much everything. On top of that you can add applications that depend only on the base system. Additional components, such as GTK, QT, SDL, CUPS, or PERL could be added if desired, and would allow you to run applications that depend on them. The idea would be to keep the number of installable components nessesary to support any given app small.

For instance, lets say I'm running on a distribution that is KDE-Centric. The components installed should be Base, QT, and KDE. So apps written for KDE should only depend on those components. If an app requires SomeUncommonLibFoo then it should be included in the appdir. And of course, if you want to have some GTK apps, like The GIMP, you can install the GTK component. Likewise, if you're using a GNOME desktop you could install the QT component to be able to run QT dependant apps.

At least, thats my idea of how it should work.

You're not thinking about this the right way. Only small, infrequently used, libraries should also come in the appdir. Things like QT or GTK should be optional add-on components to the base system.

The "Base" system would contain a subset of packages that are common to pretty much everything. On top of that you can add applications that depend only on the base system. Additional components, such as GTK, QT, SDL, CUPS, or PERL could be added if desired, and would allow you to run applications that depend on them. The idea would be to keep the number of installable components nessesary to support any given app small.

For instance, lets say I'm running on a distribution that is KDE-Centric. The components installed should be Base, QT, and KDE. So apps written for KDE should only depend on those components. If an app requires SomeUncommonLibFoo then it should be included in the appdir. And of course, if you want to have some GTK apps, like The GIMP, you can install the GTK component. Likewise, if you're using a GNOME desktop you could install the QT component to be able to run QT dependant apps.

At least, thats my idea of how it should work.

Well, the problem with that is you introduce the dependency problem again. The simplest solution, by far, would be to just include the dependencies with the application. Including commonly used libraries with the base system would cut down 99% of the cases that would require outside dependencies.

-bytecoder

apt-get install foo
yum install foo
emerge foo

installing programs on linux is neither hard or complex, its different, which is hardly the same thing.

> apt-get install foo
> yum install foo
> emerge foo

> installing programs on linux is neither hard or complex


$ apt-get install foo-snapshot2005-09-17

Reading package lists... Done
Building dependency tree... Done
E: Couldn't find package foo-snapshot2005-09-17


Or:

$ apt-get install cool-commercial-third-party-app

Reading package lists... Done
Building dependency tree... Done
E: Couldn't find package cool-commercial-third-party-app

And now?



(But you missed the point (and so did the original poster). The suggested main use of klik is providing packages for multiple distros *before* they enter the respective distros' repositories or general availability, especially during development. And all this without the software developers having to cope with each distro's peculiarities. This is *not* not supposed to replace the distro's package manager.)

> I'll take this as you haven't heard of synaptic nor of SmartPM.

How does any of this software help you if the package does not exist at all?


> Why make it easy to install an application which clearly is a development version? You're not supposed
> to install such software, unless you know exactly what you're doing.

I *really* suggest you read the article before commenting. It states very clearly that there are many non-software-developers involved in the making of a program. Artist, translators, usability people, bug reporters ("can you you try the current SVN version to verify your problem is fixed?"). Many of them had a hard time installing the CVS or SVN versions of the software they were contributing to.

Interesting page. It's nice to see that people really are establishing working theories to get packages that install flawlessly on Linux. I look forward to seing this more widespread.

However I think one of the biggest problems with linux (unix) is the file structure. It's way too complex. Once an app has been installed you can pray so that your installation log/db doesn't get corrupted or you'll never be allowed to roll back. How about a simple folder called "applications" where you could drag your end-user apps and they will work? No, it has to be a package that puts the binary app in a folder, the doc elsewhere, some additional libs in another place, the icons in /usr/share/icons/cryptic2lettername and of course the title image in /usr/share/pixmaps/what/is/this/already.

Yes, I know, shared libraries, shared icons. Every app can access everything. But the problem is that this is not everything.. it's just 'anything'. From an end-user perspective the correct term is 'a mess'. It's all organized in a way that suits perfectly computers and people who think they think like them.

The OSX approach may have "serious drawbacks" but it just happens to work. I never had to care about "installing" OSX apps. On Linux this has always represented a good amount of the time I spend when I want to try a new app. Just trying to get it installed. Finding the right package, converting from one of the dozen package formats out there. And then crying because you also have to convert the associated libs but it will fail and so on...

On either Windows, OSX, BeOS, Amiga OS, or whatever OS I've tried if you wish to test something quick and fast you just download it, uncompress and run it and that's it.

Linux... half the time configuring drivers, the other half trying to get simple applications to just freaking get installed. I remember trying to find the best IM client on linux... nightmare is a small world to describe what it requires to test 6 programs that to the same thing (that was on a mandrake 8).

Again it's fine if you stick to what's available to you. If you run Debian stable, you know what you can get, and when you see an app mentionned somewhere that looks nice, you just wait patiently 20 years for it to make it to the stable tree.

(end of rant)

On either Windows, OSX, BeOS, Amiga OS, or whatever OS I've tried if you wish to test something quick and fast you just download it, uncompress and run it and that's it.

Linux... half the time configuring drivers, the other half trying to get simple applications to just freaking get installed. I remember trying to find the best IM client on linux... nightmare is a small world to describe what it requires to test 6 programs that to the same thing (that was on a mandrake 8).



I find this comparison deceivingly misrepresentative (perhaps unintentionaly). This is a comparison of installing software that is repeated so often but is in essense false in that it represent (again, perhaps unintentionally) a universal statement of installing software on the various operating systems. In fact, on Windows for example, not ALL software is installed by "just download it, uncompress and run it and that's it". Maybe most, but not all. Similarly on Linux, not ALL software is installed by "half the time configuring drivers, the other half trying to get simple applications to just freaking get installed". In fact, on most Linux distributions this is by far an exception to the installation process. Most software is installed using a package manager program and most software ends up being installed "flawlessly". Even downloading for example an RPM of Adobe Acrobat or Opera simply requires "just download it, uncompress and run it and that's it" on Mandriva and I suspect it is likely similar on many other distributions.

This is not to suggest that there is no difference in the installation of software on Linux compared to other operating systems, just that it is so often repeatedly stated that in Linux on has to executed so many steps to install software. As a general statement, that simply in not true.

However I think one of the biggest problems with linux (unix) is the file structure. It's way too complex. Once an app has been installed you can pray so that your installation log/db doesn't get corrupted or you'll never be allowed to roll back. How about a simple folder called "applications" where you could drag your end-user apps and they will work? No, it has to be a package that puts the binary app in a folder, the doc elsewhere, some additional libs in another place, the icons in /usr/share/icons/cryptic2lettername and of course the title image in /usr/share/pixmaps/what/is/this/already.

You are right about praying for the install DB to stay correct. That's, what backups are for. In the 4 years I'm running debian (currently on 4 machines), I never had the package DB go FUBAR.

Let me offer you some other perspective on the Unix file structure.

* short search path for executables
* short search path for libraries
* short search path for manual pages (yes, people still use them)

* easy separation of what needs to be backed up and what not (/etc, /var, /home) - other stuff can be re-installed. If apps kept their settings in their subdirectories, backing up configuration files

* similar for setting to read-only. You can have (and it was done often in the past, when disks were expensive) the whole /usr tree mounted read-only from a NFS server.

* For me, the technical reasons are more important than having a "nice" /apps/ directory. I don't need to know from the top of my head, which files belong to which application. The application itself knows it and the package DB. I rarely need this information and when I do need it, I ask the package DB


The OSX approach may have "serious drawbacks" but it just happens to work. I never had to care about "installing" OSX apps. On Linux this has always represented a good amount of the time I spend when I want to try a new app. Just trying to get it installed. Finding the right package, converting from one of the dozen package formats out there. And then crying because you also have to convert the associated libs but it will fail and so on...

I prefer typing "aptitude install mozilla-firefox mozilla-thunderbird gaim xvncviewer gvim ssh" to "go to mozilla site, download firefox.exe, save somewhere, run it, click through 5 screens of installer, download thunderbird.exe, ....". Drag&drop on Mac only saves part of these mundane tasks - you still have to save the bundle somewhere and drag&drop it. One by one (at least the finding on web and saving).

Even if compiling from source - if you read the documentation, it usually lists what libs you require. My rule of the thumb is to install as much libs a possible from my distribution's package repository, compile only the bare minimum.


Linux... half the time configuring drivers, the other half trying to get simple applications to just freaking get installed. I remember trying to find the best IM client on linux... nightmare is a small world to describe what it requires to test 6 programs that to the same thing (that was on a mandrake 8).

Not true. I only do things with drivers, when I get new hardware. And mostly, if I use a distribution kernel, there's nothing to do but use the HW.

What difference is there in trying out 6 programs on Windows and on Linux? From my experience (limited) with Windows, at least one of the programs would leave stuff around even after uninstallation.


If you run Debian stable, you know what you can get, and when you see an app mentionned somewhere that looks nice, you just wait patiently 20 years for it to make it to the stable tree.

You still can use distributions that have more up-to-date packages (Debian/Sid, Ubuntu, Mandriva, Fedora Core,...). OTOH, I would not put an "ever-changing" distro on a server or a desktop I do not wish to take care of much.

* easy separation of what needs to be backed up and what not (/etc, /var, /home) - other stuff can be re-installed. If apps kept their settings in their subdirectories, backing up configuration files

* similar for setting to read-only. You can have (and it was done often in the past, when disks were expensive) the whole /usr tree mounted read-only from a NFS server.

* For me, the technical reasons are more important than having a "nice" /apps/ directory. I don't need to know from the top of my head, which files belong to which application. The application itself knows it and the package DB. I rarely need this information and when I do need it, I ask the package DB

http://www.gobolinux.org/index.php?lang=en_US&page=doc/articles/clu...
Read the "There is a reason why things are the way they are" section. Basically, everything you listed as a technical superiority is moot, and quite a bit of a hack, as well.


I prefer typing "aptitude install mozilla-firefox mozilla-thunderbird gaim xvncviewer gvim ssh" to "go to mozilla site, download firefox.exe, save somewhere, run it, click through 5 screens of installer, download thunderbird.exe, ....". Drag&drop on Mac only saves part of these mundane tasks - you still have to save the bundle somewhere and drag&drop it. One by one (at least the finding on web and saving).

Installing applications isn't something that usually occurs frequently. Most of the time, when someone wants to install something, they also want to know more information about it, which means the trip to the website is necessary, anyway. Upgrading applications is usually only performed when the user actually cares about the new features, otherwise there's no point in doing it; I'd say most people don't care about 90% of the apps on their harddrive, maybe more.


What difference is there in trying out 6 programs on Windows and on Linux? From my experience (limited) with Windows, at least one of the programs would leave stuff around even after uninstallation.

I don't see how this is pertinant to the discussion at all.

-bytecoder

Installing applications isn't something that usually occurs frequently. Most of the time, when someone wants to install something, they also want to know more information about it, which means the trip to the website is necessary, anyway. Upgrading applications is usually only performed when the user actually cares about the new features, otherwise there's no point in doing it;

I might be installing a second or third computer. Or my friends computer. Sure I do NOT need to read about Firefox the third time. I upgrade either for new features or security updates. The latter happens
quite often, unfortunately.

The point I tried to make is that typing "aptitude install app1 app2 ... app10" scales better with number of apps to be installed then "download 1, save, install, download 2, save, install, .... download 10, save install". With upgrading, it is even better - "aptitude update ; aptitude upgrade" is constant with any number of apps to be upgraded.

Why should I rememer where the Firefox installer lives on the web, when my computer can do it?


I'd say most people don't care about 90% of the apps on their harddrive, maybe more.

Well, then I'm in the 10%. Maybe I use my computer differently than 90% of the people you had in mind. How _I_ use it forms my opinions on what is good and what is bad.

I might be installing a second or third computer. Or my friends computer. Sure I do NOT need to read about Firefox the third time. I upgrade either for new features or security updates. The latter happens
quite often, unfortunately.

Well, most people like to read about what they're installing/upgrading before they do it. Even if you don't want to, it's still only a two-step process: retrieve app and drag to app folder. Sure, you need to repeat it for every package you install, but it doesn't usually matter, because different apps usually have different release schedules.


The point I tried to make is that typing "aptitude install app1 app2 ... app10" scales better with number of apps to be installed then "download 1, save, install, download 2, save, install, .... download 10, save install". With upgrading, it is even better - "aptitude update ; aptitude upgrade" is constant with any number of apps to be upgraded.

I can't disagree, it does scale much better. For the very few instances when this is actually needed, it wouldn't be too hard to write a simple script to update the programs that you want. This is another advantage of doing it manually: you know how everything works and, if something breaks, you know exactly what to do. This type of system presents a much more familiar, and thus easier and more powerful to use, abstraction to the user compared to programs that "automate" the process.

Well, then I'm in the 10%. Maybe I use my computer differently than 90% of the people you had in mind. How _I_ use it forms my opinions on what is good and what is bad.

That's unlikely. When was the last time you cared about the version of cat? How about zip, or bison? The applications that people would want to upgrade are almost always the ones that they use and care about, which isn't very many when you think about it.

-bytecoder

Besides that, klik and the mac osX system is hampered by serious drawbacks. What those are can be read here: http://autopackage.org/ui-vision.html

Regarding that link's objections, all are either fixed or wrong IMHO. Let's look at them:

You can drag the appfolder from removable media to your system and vice-versa, but you cannot drag the appfolder into an email or IM conversation due to the way the system is implemented.

The only one I concede. However, I digress that not being able to drag an app to an IM conversation is a *serious* flaw.

[…]The end result is that clicking a link in a web page can silently place software on your desktop, sometimes with no notification that this has occurred.

No longer the case in Safari 2. The fact is that you cannot even turn off the alert that you are downloading something that might contain an app. The rest of the folders are free to allow silently downloading to the user's home folder. Should the OS prevent that? Or should other web browsers just be well thought?

Many applications make assumptions about being able to write to their appfolder. This means you sometimes have to move the appfolder to the hard disk before it will run - but this is not always intuitive nor obvious.

You do NOT have to support bad-writing practices. Applications should NEVER request that the user has w access to their enclosing folder. I do not want any of those apps in my system, and I appreciate Apple does not support that either.

Little attempt is made to manage multi-user setups. With a large library of software, the "menu" (normally the file manager is used) can become cluttered with programs irrelevant to the user.

Pardon? Users are free to create a folder in THEIR Home, drag an alias of the only apps THEY use (wether they installed them or not) and drag that folder to THEIR dock, for a nice, easy and fast to access CUSTOM menu. And in the meantime, all apps reside the same place (except for those that were installed by the user in THEIR home folder), with some fixed permissions (ie, NON-w access for non-admin users unless you are nuts or have lots of free time). Much a better and flexible alternative to what is proposed there.

If all users can install/uninstall software, you have to manually track what people are using so you don't accidentally remove something another user wants to keep.

And in what admin's right mind would all users be able to install/uninstall software? OS X does not allow that by default in the general /Applications folder. Non-admin are free to screw their Home folders if they enjoy that, but that's about it.

The rest of the folders are free to allow silently downloading to the user's home folder. Should the OS prevent that?

Oops. That was me and I mean "The rest of the browsers…"

"Another package manager!

Honestly, I don't know whether to open a bottle of wine...or a bottle of tylenol.

Really. This sounds interesting, but there are so many package management systems out there. Can't we just agree on *something* that will seemlessly work for *most* systems. I'm tired of distrohopping."


Synaptic works on all rpm based distro's, but of course people seem to think there is non. Besides different package managers do work the same, just click the rpm and it take care of the rest, synaptic just sorts the deps out better.

Isn't synaptic only a frontend to apt or the likes?

It doesn't sort out anything, it parses the output of apt...if it exists for rpm distros it's because of apt for rpm...

Because of the ability to simply download and run the program without the need for installation of any kind. The application is entirely self contained.

The similarity is that on MAC OSX the standard way of distributing an application is by using an application bundle that is compressed into a disk image (osx uses HFS+ to preserve all file system attributes). Kilk takes the application directory and compresses it into a cramfs or similar file system disk image - also preserving the file system attributes. Some could argue that tgz is just as valid (and you can actually distribute runnable applications for osx that way).

The neat thing about OSX-style applications (which klik misses I think, unfortunately) is not the one-file distribution (tgz, zip, and even msi do that) but rather the standardization of the application file hierarchy within the file (that Apple calls an Application Bundle). With OSX, an application that you click on in the Finder is really only a specially-crafted directory with a .app extension (the Finder knows where to find the executables inside the directory). You can browse into it, look at the files inside, and all that. You can even add multiple executable files, resources, and all that. If you do it right, you can write the application prefs and settings back into the bundle, so that if the user moves it, the settings go with the bundle - even if they move it to another machine. ... neat.

It's a standard (you can look on the apple site to find the documentation) and it provides a really simple way to build really complex applications with many dependencies, resources, and executable files, and be able to manually alter applications as needed during development.

BTW, the bundle also holds a file (.plist) that contains a bunch of information about version number, associated file types, mime types, APPL codes, a description, etc so that an installer doesn't have to insert that information into a launch menu somewhere - it just goes with the bundle.

IMHO, of all the things that the linux community clones and tries to re-build, this is the one they should really focus on. Just download the Apple spec and implement it for linux - on every desktop. Keep the rpms, debs, and pkgs for system updates (and core system libraries), but I would strongly suggest that the linux community adopt something very similar to the application bundle for all client-side apps.

That's my 0.02

With OSX, an application that you click on in the Finder is really only a specially-crafted directory with a .app extension (the Finder knows where to find the executables inside the directory). You can browse into it, look at the files inside, and all that. You can even add multiple executable files, resources, and all that.

IMHO, of all the things that the linux community clones and tries to re-build, this is the one they should really focus on. Just download the Apple spec and implement it for linux - on every desktop.

Already done - GNUStep.

http://www.gnustep.org/

It is exactly the same as OSX since they're both derived from OpenStep. The only difference is a few Apple specific interfaces like CoreAudio. In fact, GNUStep points you to Apple documentation for how to get started programming in GNUStep.

Just an offtopic rant…

> If you do it right, you can write the application prefs and settings back into the bundle, so that if the user moves it, the settings go with the bundle - even if they move it to another machine. ... neat.

Might be "neat", but just DON'T do that, OK? Writing preferences into the application folder has been one of the main faults of Windows, because that requires everyone to have rw to the folder containing the app. A user might place his app into his own Home folder in OS X, but he might also not do that, and use /Applications instead which should never have rw permissions for all users, which would choke if the app expect it to have them.

However neat you think that is, I think it is still much nicer to have the original bundled app virgin on one side, and the user preferences in another, clear and obvious side, which you can take to another computer if you want (and what place more obvious than ~/Library/Preferences can it be?)

It is actually a folder with a name ending with .app . You can easily browse/modify the contents from the finder and you can double click them so the app inside launches.

This *folderlookslifeafile* technique is the reason why to install an app you just drag your folder onto Applications folder and to uninstall it you just drag the same unique file to the trash.

Very close.

OSX apps are a folder with sub-folders containing all the needed files.

( and on a slight tangent , the .download files that Safari creates from in-progress downloads are similarly folders containing the partial file and meta-data )

Is there even any need for a tight security regarding this? An executable can pretty much do whatever it wants once it's run... Or am I missing the point?

> An executable can pretty much do whatever it wants once it's run...

And that's exactly why you'll want to be picky about the sources for your klik files. Lists of trusted archives and digitally signed packages come to mind.

Does anyone know of a link discussing security considerations for klik or Zero Install or other application-bundle style install systems?

For the older version of Zero Install (the one that needed a kernel module): http://0install.net/security.html

For the new version of Zero Install (0launch): http://0install.net/injector-security.html

Some security features of Zero Install (0launch version):

- All interfaces are GPG-signed, and you must confirm that you trust the key before it will accept the program.

- Nothing is run as root when software is installed.

The design allows downloads to be shared safely between users: users independently download the (small) interface files, which give a cryptographic signature of each implementation. The implementations themselves can be shared, since they are named by their digest.

So, if one user puts a modified version into the shared cache it doesn't matter, because it will have a different signature and other users won't find it.

Here is an example interface file (for ROX-Filer):

http://rox.sourceforge.net/2005/interfaces/ROX-Filer

There's a walk-through showing how it works here:

http://0install.net/injector-using.html

There's no way to check for updates on installed applications on Windows or Mac either, unless they have that option.

To me this is exactly what is need on Linux for commercial apps. Synaptic and the GUI wrappers for it, is fine for the OSS stuff. There's no reason they can't co-exist.

Still, it would be nice if there was some standard way to run a Klik app (or something like it) that adds itself to a list (a la Windows's add/remove list), that has remove and update buttons for each item (and of course, if the app is deleted manually, it gets removed from the list manually). Something like that could co-exist perfectly with a Synaptic front end (except it would only list actual applications, like Firefox, or OpenOffice, and leave the libraries to another list program).

* There's no way to check for updates on installed applications on Windows or Mac either, unless that option is built into the application.

I agree with that "first run check" thing. It's funny that you are warned when downloading an app from the net only.

I think the first time ever you launch an app, wherever it comes from (cd-rom, whatever) the user should be warning with a message like: "Hey, it's the first time you launch this application, are you sure you want to allow running it". Ideally you could test drive the app in a safe temporary user-account, just like you can do with dashboard.

In Tiger, you do not get an alert the first time you run an app by double clicking it. I guess it is assumed that the user explicitely wanted to do that, although I understand how some apps might fake themselves under a folder or drive icon.

However Tiger does present an alert the first time you launch an app by double clicking a document associated with it, just in case a rogue app changed the defaut association. Which is neat IMHO.

As as mac user myself I happen to be smarter. But this dates back to well before I used my first mac :-)

More seriously I'd rather say things are so easy and intuitive on a mac that mac users would rather look pretty stupid when faced with another operating system (if all they knew was osx).

Apparently not you.

> I don't want to be a spoilsport but Rox had this for a long time.

How does that fact spoil anything? I guess you could install rox that way but nothing else?

> I guess you could install rox that way but nothing else?

I retract that statement.

But still, what does the fact that rox had AppDirs for a long time spoil about the ideas laid out in the article?

> But still, what does the fact that rox had AppDirs
> for a long time spoil about the ideas laid out in
> the article?

To the person who modded me down: Why don't you answer my question instead?

It's not a question of who had AppDirs first.

Not to mention you don't even have to drag the application anywhere.. installing it is just a matter of chosing where you want to have it. You could as well launch the app directly from the disk image.

And once you have copied it to your app folder (or elsewhere), if a friend tells you he'd like to try that (free) app you can just send the app to another machine using iChat or whatever.

The complete app is really in that .app file (folder).

Of course some apps need an installer, if they are drivers or modifiy the system in anyway.

I'll come back to linux as soon as I can quickly try the lastet alpha release of *any* program by just downloading and douclicking.

(meep. That was me as Anonmymous.)

Not to mention you don't even have to drag the application anywhere.. installing it is just a matter of chosing where you want to have it. You could as well launch the app directly from the disk image.

But the key is ... you know where the damn program is because you put it there.

What I don't like about the current Linux installer/package manager system is you don't know where the frelling program's going to end up. *Most* of the time (but not always) it ends up in /bin, but if there would just be a step forcing the user to choose a location for install, or a line saying "installed in /NameOfFolder" I would like Linux package managers so much more.

So to Klik, I say 'BOUT FRIGGIN TIME!

Actually, most apps are in /usr/bin, not /bin.

The big question, however, is why should you care where the app is? You don't need to know where it is to run it...package managers will put the app in your menu structures (on good distros they do, at least) and you don't need to specify the path if you want to start it from the command line if it's included in the $PATH environment variable (which it should be on a good, modern distro such as Mandriva or Kubuntu).

If you really want to find it, there is the powerful "locate" command.

That said, Klik is a good idea for commercial apps. Personally, I think package managers are fantastic for OSS software.

"What I don't like about the current Linux installer/package manager system is you don't know where the frelling program's going to end up. *Most* of the time (but not always) it ends up in /bin, but if there would just be a step forcing the user to choose a location for install, or a line saying "installed in /NameOfFolder" I would like Linux package managers so much more."

And that's because humans are lousy at tracking what's installed and what needs to go where. Computers are very good at this and good package managers do this for you automatically.

Additionally, if you took the time to understand rpm or deb format, you would understand that you can query the database and it will tell you where every single file associated with your rpm has been installed.

Don't let your ignorance of an issue keep you from screaming to the heavens above about it though.

Not completely true...some programs (including Firefox when i did this last time) run into a endless loop when run from the disk image itself

Maybe if Firefox wasn't such a garbage hack, this wouldn't be a problem.

==UBUNTU==

dkpg-i nameoffile
*nix gobblygook
ctrl+f2
"opera"
enter

EASY!

Gnome gives you a tab-completing run dialog when you press ctrl+f2, even if you don't see something in the menu, it'll work.

(KDE also offers such a run dialog, too bad Mac and Windows are far behind such a simple advancement)

Using menus to launch apps is so yesterday. It's good for browsing what's available, but that's about it.

well, you might be right except... that klik is NOT distro-indipendent at all! it states that it works on debians (and a single suse. maybe)

That's not necessary true, actually. You could create a CMG from a dir containing an autopackage. As the autopackage is distro-independent, the CMG will be also. See? Unfortunately this method hasn't been tried - yet -

give the ability to the user to download a .cmg file (for example firefox.cmg) mount it, and drag the AppDir on the desktop, and be able to run it by double clicking on the AppDir
Erm, you run it by clicking on the .cmg, I fail to see your problem. Actually it's doing exactly what you want it to do but using a file instead of a directory.

It's a little different, on OSX you download the dmg mount it, take the app bundle inside and move it where you want.
Here klik:// manages downloading the file and uncompressing it in /tmp that maybe it's not the best place to store apps, also konqueror doesn't understand what an AppDir is, so you cannot simply drag an AppDir and double click on it

Indeed. Yet we know Jobs founded Next and didn't exactly come there from MacDonalds. You could already drag'n'drop apps on a classic mac a long long time ago.

Of course at that time the application was really just one file, not a folder appearing as a file. But then again I am pretty sure someone can come up with a video from 1962 showing the same process.

Yes, but how many people ever had the opportunity to use a NeXT? I LOVED the ones that the university I attended had for us to use! When I purchased my Apple system it was deju-vu...except it was in color. 8-)

Dear anonymous.

You ought to come out with who you are - you're not going to be killed. And please use my nick instead. The other way looks so formal to me

I did read the article, and I also read the second one (thank you for that link). It doesn't change my point of view, and if you think it makes me ignorant, then fine.

I still consider it useless, because there are several other ways to do it (and they are superior in my mind).

But you have another opinion. And that's perfectly fine. I could say nasty stuff about you, but I'll leave the nasty stuff for you to play with.

Kind regards,

dylansmrjones
kristian AT herkild DOT dk

> I did read the article, and I also read the second
> one (thank you for that link). It doesn't change my
> point of view, and if you think it makes me
> ignorant, then fine.

Not only reading but also understanding ;-)

...the article and the suggested target audience (i.e. *not* end users).


> I still consider it useless, because there are
> several other ways to do it (and they are superior
> in my mind).


Would you please let us know these superior ways?

All your arguments up to now in this thread were about

a) stable, released software that
b) can be found in the distros' repositories

and about end users installing them using smart package managers. Which is fine for them, but you're completely off topic.

Not a single word on why klik is useless for the purpose the article and the blog entry is about (making life easier for non-coding contributors to OSS who have to see apps before they're released) or superior ways to achieve that goal other than that you think they exist.


Note: I'm not that anon person you were replying to.

Read the parent post for the mostly opposite argument. The OS envisioned by bytecoder seems to be much like that envisioned by KDE 4.0 (or maybe SymphonyOS) with Klik.

In the endgame, application management dominance should theoretically be determined by a basic formula:

P(t) = Po + So*t + E*t^2, where

P(t) is the number of packages available at a given time, t
Po is how many packages there are right now
So is the current size of the contributing community
E is the ease of package contribution

As t->infinity, the only term that matters is E. Just something to ponder...

Read the parent post for the mostly opposite argument. The OS envisioned by bytecoder seems to be much like that envisioned by KDE 4.0 (or maybe SymphonyOS) with Klik.

Far from it, actually. If anything, it's more similiar to a more suped up BeOS/Mac OS Classic hybrid in the sense that the overall feel will be the same (the interface will actually be quite different).

-bytecoder

1) Make real LSB-Desktop standard


Thats where your list falls apart. At the beginning. The only way a Desktop Linux standard will exist is if one desktop distro gets way more popular than the others and forces the others to comply.

2) Use APP Folders like OS X, compile all non-LSB stuff as static

Yes, because I want to have a copy of libfoo.so in my RAM for every application that uses it, instead of one copy. I also want to download it again and again with every application instead of downloading it only once.

Please wake up and smell the roses. It's 2005. It is not necessary to install applications "by hand" anymore. You can tell your computer "please go out, download firefox and thunderbird and install them for me". On my computer, in translates to "aptitude install mozilla-firefox mozilla-thunderbird".

Read above. Also, it's always a good idea to think before you speak.

-bytecoder

Read above what? Where? Which comment?

Also, it's always a good idea to think before you speak.

I hope you want to have a civilized discussion, I'm not in the mood for a flame. If you disagree with me, be specific and provide counter arguments. If you have written them in a different thread - sorry, I was responding to this one.

Read above what? Where? Which comment?

I was referring to my reply to the other post, which was very similiar to yours:

This isn't very relevant if you include commonly used libraries in the base system. Non-commonly used libraries would be rarely needed, and thus wouldn't be much of a disk-space waster.

-bytecoder


I hope you want to have a civilized discussion, I'm not in the mood for a flame. If you disagree with me, be specific and provide counter arguments. If you have written them in a different thread - sorry, I was responding to this one.

I'm always civilized. Whether other people think that or not is their problem, not mine

-bytecoder

I like your analyzes application vs system discovery vs repository very clever . But i do not think our ideals of freedom are at al compatible.

"The applications are made suppordinate to the idea of a cohesive system"
"on the principle that the community will work towards"
" leveraging the collaborative effort of the community"
"distribution that best embodies these ideals"

I think a application/discovery is clearly best for a heterogeneous free software community

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

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

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

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.

Probably misunderstood you on this one. Nevermind.


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.

Because it works? It works satisfyingly well for me (and probably for other Debian users as well). OK, it comes with a price - dependancy, single point of failure.

Dependancy is a moot point - you are always dependent on your OS vendor on some point.

Single point of failure - not completely true, there are mirrors. Though they will mirror any insecurity created in the original, they will provide the required data even when the original source experiences failure.

I gladly pay this price compared to manual downloading of each package, or going back to statically linked apps, or having a library installed numerous times for "self-contained" apps.

I do not claim that the packaging systems used by Linux distributions are the perfect way to distribute software. However, I have not experienced anything better, nor did I like anything presented in the discussion under this article. Everything seems less powerfull than what we already have.

Ok but don't you believe that this is the wrong thing to be managed, shouldn't klik (or konqueror) manage only AppDirs and let the user mount the .cmg images instead of playing with fstab?

But the end user is not allowed to mount the image unless root adapts /etc/fstab accordingly (*). The klik installation instructions just automate this modification.

(*) I think FUSE will remove this requirement in future Linux kernels if enabled.

I knew this, without FUSE or other it's a problem for the user to mount an image, but klik still focuses on the wrong bundle :-D because it's based on AppDir, but doesn't support it, it introduces the (good!) idea of .cmg files (simlar to Mac OS ones) but hides the position of the AppDir, which is for the system and the DE nothing more than a normal directory that contains every application files.
first the cmg remains mounted on /tmp and the app
second I cannot see and manipulate the AppDir like in macos where you get the AppDir out of the .dmg image and place it wherever you want
Third it's still distro dependant (I've seen .deb packages while downloading an app) while the pure AppDir implementation seen in ROX supports compilation, the application contained in the AppDir could be automagically compiled by double clicking on the AppDir for the first time.
I hope noone gets offended by my words, It's a feature that I like very much, but IMHO it's badly implemented because it hides the real technology behind the magic
for me AppDir must be directly supported from KDE and GNOME, ROX has born with it and there is also a patch for bash to support it :-)

> With Klik and HotNewStuff the KDE security has gone
> down to the drain,

- HotNewStuff is mostly used to download wallpapers and other non-executable content. Security is discussed, not ignored. GetHotNewStuff is comparable to firefox's central plugin download offer, only that that content is always of executable nature. Is firefox too insecure for you, too?

- Klik doesn't necessarily have anything to do with KDE. There are images for GNOME apps, too. It's not even part of KDE as of now.

But more importantly, if you had read the article before starting to troll you would have known that its suggested use is during development, not for software distribution to the end user.



> (It is already the most unsecure
> DE on Linux)

Care to back that up with facts, troll?



> there's minimun security on these
> improviced technologies, I smell ActiveX like
> problems on KDE in the next few years.

Your post smells of troll dung, as usual.

Security *is* important, but you're only on your typical anti-KDE trolling spree.

How do I use yum, apt-get an so on if I have no internet connection?

Use it with the distribution's CD's. That is why there are so many, because the cds are full of software that you can choose to install if you wish.


xxx-setup.exe, click, click and that's done.

Where did you get the xxx-setup.exe file from?


And please do not enter in the "dll hell or so" discussion, I never had a problem.

And I have never had a problem installing software on Linux properly. I could equally say [i]And please do not enter in the "The installation of the applications is the main reason why I am not using Linux. I never succeed to install things correctly" as I have never had a problem.

You cannot have it both ways.

How do I use yum, apt-get an so on if I have no internet connection?
Use it with the distribution's CD's. That is why there are so many, because the cds are full of software that you can choose to install if you wish.
xxx-setup.exe, click, click and that's done.
Where did you get the xxx-setup.exe file from?

Very simple. I buy a "pc-magazine" with a CD containing somethink like "the 100 best free applications". When I look at the "Linux" magazines, I only find things like FireFox for the distro a or app b for the distro c and so on. I conclude from that, every distro has its own applications. Maybe I am wrong?

My experience is that most software for linux distributions are available either from the distribution's cds or by downloading. So if magazine cds are your main source of software, you will likely not have as much software available to you with Linux as with Windows.

However, since you are posting here, it is clear that you do have internet access. I am perplexed why downloading software is a roadblock for you.

Very simple. I buy a "pc-magazine" with a CD containing somethink like "the 100 best free applications". When I look at the "Linux" magazines, I only find things like FireFox for the distro a or app b for the distro c and so on. I conclude from that, every distro has its own applications. Maybe I am wrong?

You are a little right, as you always should use the binaries of applications for the distribution you are using. So basically every distro has it own variant of the applications. Exactly the same way as you should use the windows 95 variant for 95, and the Xp variant for Xp. Some times it's only one version or it only works on some windows versions, but it's the same principle.

Where you are making the mistake, are with the number of applications on the magazine CD. If those applications had been included on the widows install CD, the point in including them on a magazine CD had been little. That is how it is in the Linux world, most likely the application is already included on your distribution install CD. Making it pointless to have on the mags CD, as the users already have it.

To be honnest, I will reply. That's true, I have now an ADSL connection. But, two months ago, with a dialup connection, it was a great pain. (There are still a lot of people with only this type of connection).

I should say, some "win CD magazines" are really jowels, e.g. the OpenCD. From the magazines, I discover Python, Ruby, Haskell...

It does not remain, I prefer to spend my limited spare time playing with the above languages, than trying to install them on a Linux platform. For the story and even on my win platform, I attemped to play with LUA. Infortunately, it is available only as source code, no prebuild binaries for windows, so I had to path my way.

I should say, some "win CD magazines" are really jowels, e.g. the OpenCD. From the magazines, I discover Python, Ruby, Haskell...


Similarly, this is what, for me, is great about many Linux distributions is that they come packed with so much software. With the cds, one can discouver so much softare just like the ones that you mention without have to download anything. Including many programming languages like Python (my favourite), Ruby, PHP, Perl and many many more.

> I my self won't lose my sleep about it , the time will tell and prove my points.

It may be news to you but it's up to you to back up your points in a discussion if you want anyone to take you seriously. Just making unfounded claims doesn't do.

And no, saying "my arguments are valid" doesn't cut it when in fact you don't have any. You are very funny.


I don't know what "propense" is supposed to mean but I'm only calling *you* a troll because you exhibit that trollish behaviour of jumping each and every remotely KDE-related thread and spreading FUD.

That's hardly "averyone [sic!] who disagree[s] with something related to KDE". There are many other posts in this forum I happen to disagree with or that disagree with something KDE-related but I haven't called anyone else here a troll. Not in months. It's just that you are so obnoxious.

Or would you rather like me to call you anti-KDE zealot? Would maybe be a better term... yes, I think so.

I bestow upon thee the title of "Chief anti-KDE zealot". How does that sound?

> And again, I will not lose my sleep about, I know
> what KDE developer you are and that makes it easier
> to not listen to you.

And again you refuse to address any of the arguments I brought up against your FUD.

But it's ok, I didn't expect anything else from you. Sleep on. Good night.


BTW: I'd be proud to be called a KDE developer but I don't claim to be one.

> This simple shows the uninformed you are, with
> HotNewStuff the data to download depends of the
> application who needs it, if Amarok needs scripts
> then it will ask for scripts

- You should really work on your reading comprehension. That's exactly the reason why I said "mostly".

- These scripts come from an amarok host, not from some arbitrary web site like ActiveX

- You haven't explained yet why this is different from downloading firefox extensions.