What is all this about and why isn't this guy getting more support?
klick
I just think this would be a very nice way to bring new users to Linux.
GJ
Printable View
What is all this about and why isn't this guy getting more support?
klick
I just think this would be a very nice way to bring new users to Linux.
GJ
Hi raid517,
as the developer of klik, I hope I can make things a bit clearer:
klik enables the user to install and run software by simply using a klik:// link. This even works from the live CD because all files that are needed to run a specific application are installed inside one single directory inside your $HOME.
The goal is to make all debian applications klik-able, that means that one day the whole debian repository, the largest distribution in the world with thousands of applications, would be instantly usable without the need for complicated installations, and, what is even better, without the need to be root and without the possibility to mess up the rest of the system.
If you don't like an app (or it doesn't run), simply delete the application directory and it is gone.
How can you help?
- klik needs a hosting sponsor since berlios and SourceForge have drastically cut their service level. A ssh account with 100 MB web space, Apache with PHP, running on a debian server should do it. (Must be debian because of serverside-apt, which runs on the server). The bandwidth requirement is relatively moderate because the actual software packages are NOT stored on the klik server.
- You can vote for http://bugs.kde.org/show_bug.cgi?id=81772 - if you do and if the KDE developers hear us, we will get better AppDir support in KDE, which would make klik and the concept of application directories more usable (Apple and ROX already have it).
- If you have further ideas or want to help, please drop me a line: probono at myrealbox dot com or on IRC #klik #knoppix or #kanotix.
Thanks and greetings,
probono
But can you use klik to build a local databse of the repository that include package headers, dependency information and such? dpkg's and rpm's create a local database with all that info. So far, klik installs the software in a directory and creates a "wrapper" file to run the application with the relevant paths set to directories inside the installaition tree (from what I saw). I can't seem to do that with more sophisticated packages like Tex/LaTex which require lots of shared libraries as deps. (WHY DID THEY REMOVE IT FROM THE KNOPPIX CD????? WAAAH!). Are you currently working on resolving all of these issues?
"Next generation" klik (http://klik.atekon.de) addresses these questions:
Yes, some of the more sophisticated packages with many dependencies can already be kliked (such as koffice).
klik does not aim to handle the dependency database client-wise, instead it uses apt on the server ("serverside-apt"). Dependency handling can be done very elegantly that way. A bigger concern (and the reason why LyX can't be kliked yet) is that some apps rely on hardcoded paths such as /usr, or even worse, need to have hundreds of configuration subfolders in place (gconf, which is used by evolution).
klik is not designed for installing a complete distro, but rather as a way to add applications on-the fly in an easy and convenient way without needing root privileges or changing the existing base system.
Greetings,
probono
Quote:
Originally Posted by probono
Please forgive my ignorance of jargon, as I'm not a developer. Just a poor guy who doesn't like Windows much...
Are you saying that you keep all the dependency information on a centralised "klik" server, and the guest client activates some program(s) on that server upon "kliking" that handle the dependencies as a remote request?
So the database of packages in your "klik" server (for want of a better term) is not mirrorred in the client's machine as is done with apt-dpkg/ipkg & rpm-yum/urpmi/YaST but queried by the client to the server every time?
If that is the case, then what about bandwidth problems? won't you have a lot of clients doing it at once? What about people with slow network connections?
So you will have to change 'em all manually in the source code. That doesn't seem practically doable by one person or one small team as some of those source codes are *HUGE* and took years to build. That does sound like a bit of a snag there.Quote:
Dependency handling can be done very elegantly that way. A bigger concern (and the reason why LyX can't be kliked yet) is that some apps rely on hardcoded paths such as /usr, or even worse, need to have hundreds of configuration subfolders in place (gconf, which is used by evolution).
Anyways, so how many people are working on this "klik" thingie besides you?
What's the group dynamic like, or is it just one chap? How rapid is the development/updating/bugfixing process? How is the whole process organised?
Yes, but the dependencies are handled relative to some predefined distros such as "Knoppix 3.3" or "Kanotix BH 8" at the moment (rather than individually calculated). The klik client tries to recognize the version by looking at /etc/knoppix-version and sends that to the server, and the server then already knows what packages are contained in that distro by default.Quote:
Originally Posted by daneel101
Right, which is a big advantage for dialup users who don't have to download many MBs of package information. The client just says "I'm Distro X", and the server says, "great, you need to download the following packages: ...". The server does this by using apt, just as the client normally would.Quote:
So the database of packages in your "klik" server (for want of a better term) is not mirrorred in the client's machine as is done with apt-dpkg/ipkg & rpm-yum/urpmi/YaST but queried by the client to the server every time?
They are greatly reduced. :)Quote:
If that is the case, then what about bandwidth problems?
They especially benefit from the klik way of doing it.Quote:
What about people with slow network connections?
No, in fact I don't want to recompile anything but just use procompiled .deb packages.Quote:
(hardcoded paths) So you will have to change 'em all manually in the source code.
Until recently, it was mainly myself, but nowadays there number of contributors in #klik on irc.freenode.net is growing. I want to thank especially Kano, fabianx, bfree, and alextreme for their ideas and contributions.Quote:
Anyways, so how many people are working on this "klik" thingie besides you?
The main idea is to draw heavily from what already exists rather than doubling efforts. My ideal with klik is to add just some "glue" and a different approach to what already exists.Quote:
What's the group dynamic like, or is it just one chap? How rapid is the development/updating/bugfixing process? How is the whole process organised?
Greetings,
probono
Hello...I just want to say KLIK is very nice and I am glad to read that it will soon be offering alot more programs. I for one prefer an easy way to download and install programs. I dont mind the occasional tarball but most of the time I run into some kind of stupid problem and I cannot complete the install. KLIK solves these problems and more. The thing I would like to know is, why cant they INCLUDE with tarballs or any other zipped file, the NEEDED FILES to actually make the program work! Why cant they include the 'dependency' needed. Dont get me wrong, I love Linux and have been a faithful KNOPPIX user for almost a year now. But Installing programs is usually a hassle and with the technology that programmers have, installing programs in linux should be as easy as WINBLOWs. I guess since I am not a programmer or computer scientist, its easy to complain about this. I dont know the reason why this 'dependency' issue cant be made simpler. But I do respect the time and effort that goes into everything you guys do. Especially KLIK because it is a gem and will soon be even better...bob58 :o
Hi - Just want to add my two pence worth - I've just come across KLIK in the last couple of days (having switched to SuSE Slick (it's on the cover of a mag in England at the moment) - and I think this concept is fantastic - it could revolutionise the acceptance of Linux at the desktop - keep up the good work!
Can you think of any way that an incentive to developers can be given to start to adopt this mechanism as the de-facto standard?
I primarily develop in Php/Mysql/Apache - is there a way I can contribute such a program as a KLIK package?
Many thanks
Carl.