“Simplifying software installation is a popular pastime for Linux developers. It has given us useful tools like Synaptic, YUM, checkinstall, and autopackage. A new kid on the block, Klik, approaches the problem differently, by avoiding the installation altogether.”
I’ve been waiting for something like this since I met linux! say … Redhat 5 days!
This could be put to good use, say if someone made an organized software database of the apps with a description, screenshot, reviews, a list of alternative apps to choose from; however, their site right now doesn’t provide a convenient way to find the right software yet. IMO it does open up the window for something really cool, but at the moment it’s less convenient than most distribution’s package tools.
This would be very nice if a site along the lines of icewalkers was designed with this software.
It’s actually an old story – and second time I see it here this year on OSnews. But still worth to check out, though it doesn’t hold any extra value (for me) compared with a zipped folder. Basically the same approach with a different name
The thing that puzzles me the most about the design of klik is that it requires its own protocol handler, even though AFAICT it just uses HTTP.
Why not use a MIME type handler instead? That would make it easier to use with any http client. Also, using full URLs would make it possible to server klik apps from any server.
This is a security measure – klik does not run stuff from random servers.
It would be easy to have a whitelist of servers klik is allowed to download stuff from. Even better, require files to be cryptographically signed and check them against accepted keys.
There are two parts to klik. One is handling of preassembled compressed disk images containing programs. They are mounted and the program inside run when a user double clicks the .cmg file. The other part is the building of the .cmg file from a recipe. When a user clicks a klik link a short recipe is downloaded and processed. This recipe tells the client what packages are needed for the .cmg and how to put it together.
I guess the main reason this second part needs a special protocol is to avoid leaving the recipe on the users computer. A file that would only confuse the user. Instead the recipe is processed automagicaly and the only thing left when the client program is done is a .cmg file the user can click to run.
Huh? Normally, when browsers launch an external viewer, they will save the file in /tmp and then unlink it when you exit the browser. How many users would be confused by one more file in /tmp; a file which gets deleted when they close their browser?
The special protocol has nothing to do with “hiding” the recipe. Realistically (for now anyway) the options are to do what klik does OR let the user download and save recipies normally and then execute them manually OR configure recipes from any server to be run automatically. It is a security issue to ensure that klik only pulls recipies from the official klik server.
This is a kind of vendor lock-in.
The main problem is that it doesn’t allow any kind of mirrors unless the server is mirroring transparently.
It is quite fragile, when they changes DNS address, it took the service off the web for a while.
This still looks like an overcomplicated version of Apple’s AppDir. Why must you run a server to serve Klick files? What about if I want to put a klik app I wrote myself on my blog? Why a protocol handler? Why must it run off of a repositry that I have no control over…
easy , just provide the .cmg and all klick capable linux will load them once downloaded to your computer. i’ts more steps but it works
easy , just provide the .cmg and all klick capable linux will load them once downloaded to your computer. i’ts more steps but it works
Excuse me, but isn’t this a HUGE security risk if it works like this?
As in: ‘*oops* I clicked that malware klik-link’?
As in: ‘*oops* I clicked that malware klik-link’?
Exactly. But not in the way you described. One could provide apt-get or yum repository for spyware also.
I’m just opposed against installers like that on Linux as on OSX.
Wouldn’t mind against them if one single adequacy would be improved.
Blocked locations where that package runs.
For example. I put package on desktop and try to run it. All I get is a simple message that says I have to copy this to Applications, opt, whatever in order to be able to start it. But when I do that (as current user) I should be asked for password and copying should be done by service afterwards. Installing this way would be simple and secure and nothing unwanted would happen.
Excuse me, but isn’t this a HUGE security risk if it works like this?
—
Indeed it is. The HUGENESS is about the same sizes as if you download and install any Debian package from any arbitrary web server. Only that the Debian package installation runs with root privileges….
Oooops then! No it isn’t. Not to the same degree. klik runs with user privileges only, not root. However, the risk remains. A user’s home directory deleted is probably a considerable damage done.
So if you don’t trust a klik .cmg package from an arbitrary source, don’t download and run it. If you don’t trust a Debian .deb package from an arbitrary: don’t download and install it.
Simple as that.
You can’t install mal-ware through official debian repositories. Of course it could happen from a non-trusted server, but that would require some work on user side
However, it doesn’t matter in regard to usability of the Klik-system, even though I don’t see the need for it. You could just use a zipped folder instead, like bygfoot football manager does (a static build, in a folder, in a tar.gz archive – only drawback: You have to unpack archive, open folder, doubleclick on the binary to execute it – more clicks than with Klik but still easy)
> You can’t install mal-ware through official debian
> repositories.
Don’t you know that some Debian servers had been cracked some time ago? There’s always a risk. But most people do trust the Debian systems *and* the Debian package maintainers.
The situation with klik is not all that different: There’s one system that provides the recipes and then there are the Debian servers that provide the necessary binaries (or a different provider of the binaries, e.g. the developer of the app himself). You have to trust both. But that’s not that much of a difference to me.
OTOH, I’m all for support of digital signatures of the recipes.
Yes, I can support digitally signing the packages, too. It’s a wise step and pretty logical if you ask me.
You can create a cmg-file, put it on your blog for download and systems with klik installed can run it. If you want people to open your klik package with klik:// you should send a request to the klik server maintainers. This is a security measurement, to avoid malicious content.
All we need to do is to develop the apt protocol, sort of a cross between klik and zero-install.
I dont understand why people are looking for this “one click install” for Linux, (it’s not in windows anyway). Open up Synaptic in ubuntu, YaST in SuSE and you can install software much faster and easier. Klik is a good idea but dont always work and has limited software.
Why dont people think installing a rpm or deb is easy since it’s usally just a few clicks anyway, in SuSE you can install rpm directly from inside Konqueror. Also Windows maybe easier to install software but only by one at a time, no software management at all, So if you want to install ten programs, it’s one by one. Apt, YaST and Synaptic are the better ways of installing and removing software all in one go.
> has limited software
That’s the whole point of Klik, it doesn’t need to provide every damn piece of Software ever written, it’s not a substitute for apt, but designed to complement the available means of software installation.
You miss the point of klik. It is not a replacement for deb or rpm – it is a way to provide early access to non-techie folks (usability people, artists) to software. This was the primary reason the KDE project wrote klik – to enable non-programmers working with the upcoming KDE4 technology. It is an extremely convenient tool for programmers as well to create klik-versions of pre-alpha software. It is self contained, and doesn’t care what is or is not installed on your system (unlike the package management you mention).
KDE project did NOT write klik.
Klik was not developed to provide early access to binaries (though it is a role it is extremely well suited to imho). Klik was originally created to allow you to run extra applications on live cd distros like knoppix/kanotix.
There are certainly KDE devs on the maintainer lists. But I might have mistakenly believed that it was developed by KDE, for that’s where I first read about it (planetkde) and the explicit aim to help non-programmer contributors to the project test software. http://dot.kde.org/1126867980/
Sorry for my mistake.
Open up Synaptic and try and install the latest version of Opera. What sources do you use? Are they unconflictable? Have you never faced an issue of a missing dependency or where you are faced with a choice of losing software to install new software, doing without or compiling from source? You cannot compare installing a deb/rpm with running a cmg (if nothing else that deb/rpm you install can thrash your system at will as it is installed as root). As is continuously stressed though, klik does not aim to replace package managers but simply to assist them, in fact it depends on them to automatically determine dependencies (for debian based recipies anyway).
“Open up Synaptic in ubuntu, YaST in SuSE and you can install software much faster and easier.”
—-
True. I’m doing it all the time. But I’m also using klik in parallel. klik is an ideal complement to the package manager.
The system package manager and klik do fill completely different roles and requirements. klik doesn’t interfere with the package manager at all and doesn’t touch the base installation.
I use klik for bleeding edge packages, such as
klik://amarok-svn-nightly
and to have different versions of the same software available for testing, quickly and without danger to the base system (I only need to protect my dot files).
“Klik is a good idea but don’t always work and has limited software.”
—-
Doesn’t always work — right. I consider it in “alpha” stadium, overall, But once a particular package works, it works. If it doesn’t the fix very often is extremely easy: edit the recipe. But it needs manpower to do all this. Which is lacking currently.
Limited — sometimes yes, sometimes no. For running amarok nightly builds from SVN on all my systems, klik currently is the only option. And there are a few more examples.
So which is better and why:
Autopackage or Clit, I mean Klik?
The klik idea is a nice one provided that
– you have fast and no-limits net connection,
– you don’t mind your linux tree will become even more junky than it is now – unless you use a distro like gobolinux which builds itself around the 1app-1dir idea.
For average users, it doesn’t matter, they just see that it will work, so they’ll love it [I sicnerely hope it won’t become ubiquitous just because of this reason]. But then again, apt (ok, let’s say Synaptic since most of them think GUI is everything) does it all the same. For trying out software without junking the whole system is a pretty nice way, the only one I ever intend to use klik.
That makes me wonder how Linspire users get software if their internet connection is very slow or they don’t have one. Every Linspire CD I’ve gotten my hands on didn’t have much more software than one would expecte with a clean Windows installation, that’s not a usual limitation one sees with Linux.
I dont understand why people are looking for this “one click install” for Linux, (it’s not in windows anyway). Open up Synaptic in ubuntu, YaST in SuSE and you can install software much faster and easier. Klik is a good idea but dont always work and has limited software.
Ya if you download a file can you use Yast to install it, as far as I know you can’t. I would love to get the new mozilla and click and install. Not a .rpm not a bleepen source file. Why is it so hard for you “smarter” then “windows” linux users to get such a simple request? I want to download a .whatever file & click, setup & install.
“Ya if you download a file can you use Yast to install it, as far as I know you can’t. I would love to get the new mozilla and click and install. Not a .rpm not a bleepen source file. Why is it so hard for you “smarter” then “windows” linux users to get such a simple request? I want to download a .whatever file & click, setup & install.”
Ever heard of the Loki installers? usually they are .run files, and yes you can generally click on them and they’ll bring up a pretty gui installer, just like in Windows.
The Thing is, generally most Distros will package the latest version of a program that is available when they do a feature freeze and it’s not necessarily NEEDED to have to do it the ‘windows way’. Think of all the spyware/adware stuff that is in all those programs for windows that you can just ‘download a .whatever file & click, setup & install’
Read the article.
I dont understand why people are looking for this “one click install” for Linux, (it’s not in windows anyway).
I don’t understand why people look at windows as holy grail of usability.
“I don’t understand why people look at windows as holy grail of usability.”
Only because it has MILLIONS of users. And for the most part they can goto a site, or store, and just install the software and it just works.
With LSB 3.0 it will be much easyer to do packages like this, the package will already know what should alrady be installed on the computer.
For the most part I think package managment systems are needed with distros, but there are alot of programs that you shouldnt need to use a package managment system to install the software.
There should be a global user Application folder that DOES NOT need root permissions to install stuff into.
Like the new FireFox, you can now update it via web, but you have to be root to do it, what the hell?
I mean come one guys, lets make it easyer for venders and programmers to install software on a Linux system.
Easier?, well that comes at at cost called security, whenever you compile from source you dont need to install just run from that direcory. I dont want my applications installed in my /home/user directory because it’s protected under root. For to long Windows users have paid the price of easy “one click install” with SP2 it’s not one click anymore.
I’d rather have a layer of security than what your saying, Lets live in the real world were people need to learn about there OS, and not let the computer control you, since Linux lets you do this.
I for one am happy you have to have root access to install most programs on a Linux system. It beats running around to Windows boxes all day at work removing Pretty Good Solitare and Webshots for those users that have access to installing programs.
I think Klik is a great idea. Just imagine: It’s not important which distro you are running and what package manager, you olny install a klik app and it runs in his own space. if this could be ported to other OSes, then it would no matter which OS you are running. In a future the OS will not be as important as now, but the apps, and IMHO klik is one step forward.
I agree that some libs will be duplicated, and perhaps it must be designed in some other way (something like DLLs, but stored in a database and by version as needed on demand: lib1-1.2, lib1-1.5, etc), but by now is a cost in storage space that is not that high as storage capability and network bandwith are getting cheaper
This could do great things for proprietary software (I’m thinking video games here). The one thing that keeps me from switching to Linux is how insainly difficult it is to run anything that isn’t in what distro I’m running’s package management system (which means things like UT2004, and other proprietary apps – yes mostly games). This could solve that problem, if companies start using it at least.
That’s exactly what I like about it. Installing, maintaining, and removing a package not native to your distro is a real pain, especially when installing those packages drops files in multiple locations across your system. the klik idea means a much cleaner, easier, and trouble-free solution to this common problem.
It has its use cases, just like the base system’s package system.
It is great for
– applications you only need for short period of time
– applications you always want the latest and greatest version of
– applications you want to testdrive
You’ll get fast and easy access to applications without depending on your distributor and you also have less security implications than using klik for long term software
Just wondering if anyone has had experience with both Klik and Zero Install. If so, which do you prefer?
Here is an interesting comparison chart from Zero Install:
http://0install.net/matrix.html
It looks like one big difference is that libraries can be shared in Zero Install. However, I have never been able to locate very many Zero Install packages — Klik seems to have a lot.
Here is an informative article on Zero Install:
http://freshmeat.net/articles/view/1049/
Yeah, Zero Install is interesting, but, as you say, where`s the packages.
Klik took some ideas from the Damn Small Linux http://damnsmalllinux.org/wiki/index.php/About_Damn_Small_Linux#The… .
I don’t understand why such complication it’s needed when there is already a good application system like AppDir (which works like Apple/NeXT’s bundles) thath is already implemented in rox, and could be easily ported into nautilus and konqueror.
Much more polished and clean than this hack
The thing with klik is that you have a single file for each program instead of a single directory. It is easier to move a file across the network than a directory. I know you could always package the directory in a archive of some kind, but then what you have is basically a cmg file.
yes but if you ever used a Mac you should know that image files .dmg are used to distribute the AppDir, but usually you won’t work with the application launching it from the mounted imaged file…..this is what klik does….and to me seems very stupid
Instead with macos you mount the image file, drag the application where you like and the umount the image file and remove it or save it somewhere, seems more easy and more elegant to me than klik idea.
Also klik files are basicly packages (deb rpm etc) expanded into a dummy filesystem, very different than the concept of appdir….see rox site to learn about appdir capabilities
You are wrong. Unpack a klik cmg and you have a ROX appdir.
But with klik, you don’t ever have to unpack! The concept “1 app = 1 file” is the real beauty of the concept.
The problem is that klik packages won’t work everywhere. They work on supported distros, ie, they are based on packages provided by the distro.
I tried to install Lsongs on debian sid and some functions didn’t work because some deps where not satisfied. And there was not way to tell since LSong expects to run on a Linspire distro and thus doesn’t report this sort of problems…
A klik package doesn’t come with all the required libs, only the ones it thinks are necessary. It probably works with livecd distros but not with hd distros that might have been installed with a minimum of packages for example.
Another way of not addressing the problem of separation of the system and applications….
If it made sense to bundle every single dependecy with in a klik cmg klik could, but it doesn’t and instead it has it’s own idea of the expected base packages for different distributions. Klik assumes you have the standard desktop of your distro fully installed which is a price to pay for wanting to install a minimal system. http://klik.atekon.de/blog/?p=16
“The problem is that klik packages won’t work everywhere. They work on supported distros, ie, they are based on packages provided by the distro.”
—–
This is the situation now. Very often, this is just due to klik recipes (you know what they are, right?) being not yet close to perfection. Most klik recipes are auto-created through the klik server’s builtin “server-side apt” intelligence. And as such, they do by default only know about Debian.
However, with the recent introduction of klik “recipe maintainers”, over time, this can be fixed.
Sometimes, the recipe may be buggy. Very often, such a bug may be fixed with 1-5 lines of simple shell code.
Also, the number of supported distros can be extended very easily. It just takes more people who do the work, and know the respective distro.
The coming of FUSE and LSB-3.0 can be of good value to improve klik too.
Nice, innovative, convenient, but…
1. Security! Whenever a user can run arbitrary code from a website with one click on a pop-up dialog, disaster is imminent. Example: IE and ActiveX. Software installation/execution should be visible and obvious to even the dumbest user.
2. Central repository. As mentioned here earlier, things grind to a halt when the website goes down.
3. Upgrades (security). No automatic upgrade notification system (yet).
4. CPU architecture. TBH I haven’t found documentation on this but I doubt the .cmg files written for i386 will proceed to automatically fetch ppc binaries on a mac box. Also, being able to right-click and hit “download source” would be nice.
IMHO OS X’s software managment system is so far the best in theroy. If only they had added a standard update mechanism and strongly emphasized that every binary work from any directory… I especially like how they handle libraries.
Also, I think digital signatures should be used more in software distribution. Vendors, testers, distributors etc. could each have their own signatures that they can give to any package they like. The user could choose which ones to trust, note down which ones tend to work and which ones don’t. Perhaps like this a collective statistics database on the quality of certain vendor’s packages could be built, although such an effort would be difficult to secure against vandalism.
Ever heard of Portage?
It handles dependencies, you have bleeding edge packages, optimised for your system installed only what you need. For example If you don’t listen mp3s Why to have support for it.
So many areas of Linux needs more urgent attention.
Most Linux users including recent newcomers are perfectly happy with whatever package management system offered: Yast, Apt-Get, Yum, urpmi.
All of those providing online search and installation 100x easier than Windows.
I’ve never come across a famous package hard to install unless they are exceedingly obscure and unmaintained.
Obscure Drivers (but necessary for some). So its not as if they will go over the trouble making that “Klikable” now.
Sure go ahead play and expand with the LOCAL-INSTALL concept. No harm in experimenting.
ELF + Static Library does the same. But I won’t argue, experimenting researching is good.
HOWEVER, I often feel people are trying to please non-Linux users with such issues.
Many companies took heed and released their drivers source code, but that is not attracting that much developer attention.
Many exotic Printers. Scanners. Webcam could have been made seriously plug and play by now.
BUT
The first obstacle – connecting to the internet via WIRELESS or those crappy winmodem ADSL or not .. that seriously should take the GREATEST PRIORITY.
Because those are the things that will make the non-Linux users go running back to their “whatever” OS. More than anything else.
Edited 2005-11-07 20:49
I found this resource to be invaluable in understanding how klik works and how to hack it:
http://www.kdedevelopers.org/blog/418/
The guy has lots and lots and lots of stuff about klik. Surprises me again, each time he writes a new entery. Best to start reading here:
http://dot.kde.org/1126867980/
The very existance of klik is yet another proof that Linux is not a software platform. A given distribution might be a plateform, but have you ever tried using packages destined for another version of that very distro?
Somebody mentioned LSB in the previous comments. LSB aims to turn Linux into a software platform. However, in my opinion it goes against the very chaostic nature of open source. Some users might wish to set up a web server and don’t want to include any software that is related to Desktop computing. Other, might want to tweak it to use it on an embeded device. They are not going to have the same system libraries advailable.
Distro specific package managers take care of dependencies and enable you to use software intended for Desktop computing on your web server if you are willing to install the missing libs/packages. However, they require root (or some form of admin) rights, it is also necessary to have a package advailable for the app you want to install. This limits their usability from the user point of view, lengthen the time required to get new bleeding-edge software, and for software developpers, it means that they must invest some extra effort to make their software advailable on distro XYZ.
I happend to work for a government agency that would like to release a software package to it’s users and to the cummunity in general. I poked around the internet quite a bit, to try to find the best way of distributing our software to non-technical users that will probably not have root access. The best thing I had seen was self-installing archives (Like NVidia *.run). klik provides similar capabilities. I don’t belive it will make it any easyer to build the packages for distribution. It might make installation easyer for users.
In other words, if I could ask the klik developpers one question, it would be : What are the features of klik that make it more interresting for me to use than self-executing archives?
So which is better and why:
Autopackage or Clit, I mean Klik?
PREVIOUS SCORE: -3 because people FEAR honest comparisons
I am truly amazed how well some of the klik packages work. I’m a klik user ever since Kurt Pfeifle started to regularly blog about klik
http://www.kdedevelopers.org/blog/418/
2 months ago. My current favorite is
klik://amarok-svn-nightly
It bundles a Xine sound engine with it, and it is based on the current amaroK development code, re-built each night from the Subversion repository. Only 9 MByte for the complete bundle — that is not more than the SUSE RPM package for amaroK (Is that the effect of the compression that is applied to the .cmg? Whatever…). My other favourite kliks are:
klik://scribus-latest
klik://kimdaba-latest
klik://wesnoth-latest
klik://kdissert
klik://kflickr
klik://kitty
klik://klamav
klik://xara
klik://luma
klik://opera9
klik://skype
klik://smb4k
klik://yakuake
klik://ooo2
klik://nvu
Special protocol handler? Servers? Recipes? WTF?
When I read the blurb, I thought that Linux finally had something like OS X’s application bundles — but I guess not. Forever in pursuit of the most convoluted solution, the Linux crowd is!
I moved my girlfriend over to a Mac Mini on the weekend, and she asked me to explain how to install programs. We downloaded Adium, I showed her the .DMG file, I asked her to double-click it, then I asked her to drag “Adium” onto her desktop. That was it. She was like “It’s installed?”, to which I replied “If you want to call it that.” She was amazed at how simple it was, and how little effort was required.
Why is it so hard to do the same thing on Linux? The entire infrastructure is already there, for God’s sake.
First, the Unicies DO have something like App bundles. In fact, they have 2 independant implimentations: Rox AppDirs (based on RiscOS implimentation) and GNUStep AppBundles (pretty much the same as OSX Bundles because they are both taken from NextStep).
Second, Klik files are very much like AppBundles. The klik protocol, servers, recipies and whatnot are part of the klik distribution method. AFAIK .cmgs can be run without any of that.
Amen!
If Klik wants make it so you can have network application transparency, that’s great.
But I think it should offfer a second mode just like what the OP is asking about so you can move the application locally on your HDD, plonk it down and be done with it.
I think the idea of run-time decompressing and running the application is a waste for desktop systems where you have the space to leave it extracted.
Klik has no network transparency … when you follow a klik link passing it to the klik client it downloads files and creates a cmg file LOCALLY in the users home dir (actually on their Desktop). So BY DEFAULT it moves the application LOCALLY.
And btw, please go and test the overhead of the “run-time decompressing” as you call it, actually it is mounting a transparently compressed filesystem, across a full range of software. You will most probably not discover any noticable overhead and in fact you may discover that some programs actually run quicker as it effectively optimises hard disc access (hard disc space may be ample but it’s speed is still finite) at the expense of cpu-time to decompress.
Just wondering, do you have any benchmarks to show that it is faster or under what conditions it is?
Your explanation is plausible but I would suspect there is more CPU cache thrasing in decompressing an image than in running it locally.
> If Klik wants make it so you can have network
> application transparency, that’s great.
>
> But I think it should offfer a second mode just
> like what the OP is asking about so you can move
> the application locally on your HDD, plonk it down
> and be done with it.
That’s *exactly* what klik offers. BTW: You’re answering to a well-known troll.
The klik protocol handler and the recipes that have been talked about are a convenient way of creating such application files from resources transparently loaded *once* from the net (convenient to the point where an end user can do it). The created file *is* plonked to your HDD and you can move it wherever you want or just leave it on your desktop. Click it in konqueror or on the desktop and the app is started.
In addition, nothing is keeping you from downloading a pre-created .cmg file from a source you trust. E.g. a translator of an Open Source app may want to download a .cmg file offered by the developer in order to run the most recent version. And said developer only needs to offer one image, and it may run on several distros. In the future support of the LSB desktop spec may improve this to the point where a .cmg can run on any LSB-compliant distro.
“Why is it so hard to do the same thing on Linux? The entire infrastructure is already there, for God’s sake.”
——
klik is doing exactly that.
No. Not true. klik is even *simpler*. Simpler for the user.
Browse the klik repository and click on any klik://something link you find interesting. Or just create one or some klik://somethingelse links in a simple HTML file, and send it to your girlie. She only needs to click on the link and, woosh!, the app is downloaded and started up.
But if you want, you can make it as complicated as it is made on the Mac. Here it goes:
Download Thunderbird from
http://opensuse.linux.co.nz/klik/10.0/thunderbird_1.5b1.cmg
Show her the .cmg file, ask her to simple-click on the thunderbird_1.5b1.cmg file. Don’t ask her to drag it anywhere. That’s it. She’ll be like “It’s installed??”, to which you reply “If you want to call it that.” She’ll be amazed at how simple it was, and how little effort was required, and kiss you all night long. Yes, klik can improve your relationship too!
The problem here in this forum is: they are all geeks or half-geeks (and trolls). That’s why they’ll talk about “special protocol handlers”, “servers” and “recipes”… (BTW, the same would happen in any Mac forum where they discuss the engineering of the .CMG files) 😉
I find the greatest convenience of klik to lie in its simple design principle
—> 1 application == 1 file
And seening how this is achieved (file system image, cramfs or zisofs compressed), I can not help but applaud its developers. From what I can see, the overhead for transparently decompressing the image once it is loopmounted (note: it is not decompressed into a temporary harddisk directory! — similarly as a compressed Knoppix ISO image isn’t) is minimal, and klik app performance is not distinguishable from traditionally used applications.
Didn’t the Damn Small Linux folks create this? Cause I thought that’s what their design was, when they created the UCI packages for DSL, which does the same thing only better
The concept of repositories is bad.
– A repository will never contain all the available applications.
– One distro (or family) : one repository is stupid.
As a end user, I want distro agnostic applications.
Meanwhile…
> The concept of repositories is bad.
What concept of repositories?
[…]
> As a end user, I want distro agnostic applications.
And that’s what you already get very close with klik. As soon as the LSB desktop spec is widely supported it should be possible to create recipes against that spec.
And that’s what you already get very close with klik. As soon as the LSB desktop spec is widely supported it should be possible to create recipes against that spec.
I agree on the concept. What is always embarassing me in the “Linux” world, are the words “as soon as”. The “as soon as” is already here for my w2k platform.
Well, i think Autopackage (http://autopackage.org) has got it better.
I mean, it is more well designed, doesn’t bundle every library ‘statically’, and estimulates developers to write libraries with binary compatibility in mind; and to write apps with distro-independence and the end-user in mind.
Well, i think Communism has got it better.
I mean, it is more well designed, doesn’t bother with all that market stuff, and stimulates peple to live with peacefullness im mind, and to act without discrimination and the comunity in mind.
Sure….
[For everybody here that does not get it: The point is that hoping for binary compatibility and distro-independent apps, is quite the same as hoping that communism works as intended…not as implemented]
i tested it in mandrake (9 or 10) ones so i can only comment about that distro. but what basicly happend was that rpmdrake was fired up, root password requested, and then the rpm package was managed by rpmdrake. this complete with checking dependencies and grabbing them of a ftp if you have a net connection and rpmdrake set up with addresses of contrib and official servers.
[For everybody here that does not get it: The point is that hoping for binary compatibility and distro-independent apps, is quite the same as hoping that communism works as intended…not as implemented]
Woah, you’ve got your hopes pretty low, huh?
Well, binary compatibility works on Windows. Woops.
Sorry, we’re not talking here about philosophy, or futuristic technology; we’re just talking about bits and bytes, and technologies other systems already use. Don’t call it impossible just because you can’t do it.
this complete with checking dependencies and grabbing them of a ftp if you have a net connection and rpmdrake set up with addresses of contrib and official servers.
Or eventually asks for the install CD containing the relevant RPMs, depending on your setup. And the doubleclick part are only caused by mandrake defaulting to it, works just as good with single click:-)
The people complaining about that aspects of linux are either trolls or have never run a “modern” linux distribution.