Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Debian Software Linux

Point-and-klik Linux Software Installation? 212

bfree writes "While you may have come across klik before, you might not be aware of some of the major changes which have been taking place over the last few months. If you visit the old klik site you will see a link to the Next Generation klik, which aims to provide a web interface to install the entire collection of Debian packages, letting you grab any package from sid (and its dependencies) and 'install' it into its own location, similar to the system outlined in this recent slashdot story." See below for more on klik.

bfree continues: This is not the only change in klik recently however, now applications are built into compressed image (cmg) files rather then stored as application directories. This means that you can store the application on any filesystem and move it around at will. Klik no longer totally depends on kde. Where previously klik could only be used with konqueror, now you can also use firefox and elinks, and where previously kdialog was required, now any of dialog|Xdialog|kdialog should work.

Klik now also supports more distributions fully. The officially supported list of distributions is now Knoppix (3.7), Kanotix (BHX), Linspire 5.0 and Simply Mepis (2004.04). Klik assumes that you will have installed at least the lowest version of any package which is present in all supported distributions and build the applications as such. If a package you want klik to install depends on a package in this base system it will not be included in the cmg so you must have it installed or add it to the cmg by hand afterwards. If you want to try using klik on another distribution, your results will primarily depend on whether or not your distribution has the packages the cmg depends on and assumes are present. So you will certainly fail to install kde applications on a distribution with no kde (as all the supported distributions have kde), but programs with simpler, or less common and therefore missing from some supported distributions, dependencies can work just fine.

One of the best ways to demonstrate the power of klik's techiniques is with the Christmas present from probono, an OpenOffice.org cmg for version 1.9.65. With this cmg (which runs on far more distributions then klik's supported list, especially as it uses Linux transparent iso compression rather then cramfs) you can download one 100M file to try out the preview release of Ooo, no need to upgrade any parts of your system and if the system has been setup by root to use cmg files there is also no need to even be root. I think this demonstrates the very best feature of bundled applications, you can try a potentially reckless preview release of software without having to upgrade your system.

This discussion has been archived. No new comments can be posted.

Point-and-klik Linux Software Installation?

Comments Filter:
  • by Krankheit ( 830769 ) on Saturday January 15, 2005 @04:05PM (#11375109)
    Can Klik install Gentoo Linux?
    • Re:Nice, but... (Score:3, Insightful)

      by Cid Highwind ( 9258 )
      Yeah, but you have to use the secret beta text-mode only klik client (codenamed "xterm"). Open xterm and type "emerge " (the trailing space is important!) Open the klik! web site and highlight the name of the app you want to install with your mouse pointer. Then middle-klik on xterm, and press enter. Presto!
  • by Master of Transhuman ( 597628 ) on Saturday January 15, 2005 @04:06PM (#11375116) Homepage
    "Unsupported Operating System

    If you were visiting this site with Linux, you could install thousands of applications simply with a klik. You can download a free copy of Linux here. Please come back with a standards compliant operating system and browser.

    This site is optimized for Konqueror and Firefox."

    I don't like this shit when it happens with IE and I don't like it when it happens with Linux.

    Fortunately I use Red Hat, so it doesn't matter...

  • by Anonymous Coward
    In 5, 4, 3...

    Oh, wait. This isn't related to KDE.
  • User Agent String (Score:2, Informative)

    by Krankheit ( 830769 )
    If you are running a browser under Win32 or MSIE in WINE without spoofing your user agent string, the site will bitch. Solution: Change your user agent string. In Opera this can be done from the Quick Preferences menu. They are most likely doing this to save bandwidth.
  • Is it me or do the k-folks have a totally kde-centric world-view? I mean who but them would develop a software installation system that has kde as a dependency and ensure that way that no distribution that doesn't want to lose all non-kde users (not only gnome, but users of all other window-managers and users that don't need X on their machine) can use their system?
    • For that matter, why would anyone make an installation system that had GTK as a dependency? Then, it would never look nice under KDE, so why even bother?

      Most likely, they just didn't bother to make it work with anything until it was good enough that this fact even mattered.
      • by Nasarius ( 593729 ) on Saturday January 15, 2005 @05:00PM (#11375419)
        For that matter, why would anyone make an installation system that had GTK as a dependency? Then, it would never look nice under KDE, so why even bother?

        Actually, the latest version of gtk-qt [freedesktop.org] is pretty damn good. I think it has the potential to become a "standard" for KDE users once all the little bugs are worked out.

    • Is it me or do the k-folks have a totally kde-centric world-view?

      Surely no Gnome-user would have a gnome-centric world-view ever.

      • I am neither Gnome nor KDE-User and both groups just get on my nerves with their "our program only runs with three dozen libraries that are bigger than the rest of your system together"-attitude. A recent example is K3b which is a nice CD-Burning App but it would be the only thing on my system needing the KDE-Libraries and doesn't really gain much from using them. The better way would be to make one using plain old GTK or QT and allowing non-kde users to use it too without loading all the libraries. I might
        • A recent example is K3b which is a nice CD-Burning App but it would be the only thing on my system needing the KDE-Libraries and doesn't really gain much from using them.

          It looks nice, but is among the most frustrating software I've ever tried to use. Gourmet garbage is what it is.
        • I for one am sick of these "oh but it requires libgnome/kdelibs". Just fucking install both desktop environments, that way you can run any app you want. Forget selecting libararies, you're doing yourself a disservice. You're likely spending more on toiletpaper any given day than what it costs in disk space to just install everything.

          Seriously, if takes a hundred megabytes, a gigabyte, whatever, so what. If it takes you even five minutes to troubleshoot an application you're never going to recuperate your e
          • time is expensive

            Yes, it is. Adding extra libraries not only increases resource usage (agreed, not particularly important) but also fragments the code and slows load and execute times. That is important.

            Both gnome and KDE take far more time than they should to do simple operations. It needs to be fixed.

            ---

            DRM - Democracy Restriction & Manipulation

            • "Premature optimisation is the root of all evil" as somebody once said.

              Both the desktops are putting more effort into optimisation now they have most of the functionality required.
              • "Premature optimisation is the root of all evil" as somebody once said.

                True for code/peephole optimisation but less true for functional/design optimisation.

                Too many software projects assume that any functional design will be fast enough. For instance, they often don't appear to understand the difference between an O(n^2) algorithm and an O(nlogn) algorithm, nor the major timing differences between a polled interface and a callback/callforward interface, nor the way many small delays accumulate into a

                • True enough. I think that there would be a huge benefit to the Free Software community if somebody wrote a simple text book descibing issues like that (big-O, unit testing, asserts, basic software design). The knowledge is out there, it's just spread between a lot of sources and harder to find than it could be.

                  I get the feeling that a lot of Free software developers are like me: people who can program well enough, but have little formal education in development techniques.

                  It's been a difficult learning cu
    • You don't have to run the KDE window manager to use most KDE apps such as KDevelop. You just need Qt and the KDE libs. There are no dependancies on the window manager itself.
    • by UnderScan ( 470605 ) <jjp6893.netscape@net> on Saturday January 15, 2005 @04:58PM (#11375408)
      1.) klik is about a year old & is not new software.
      2.) klik was first developed to install applications on in Knoppix (which uses KDE). Since Knoppix is on a read-only medium (CD-Rs) the dependecy on KDE was a real one.
      3.) klik on longer depends on KDE. Just RTFA for once please.
      4.) As far as I know, probono the developer of klik is not a official KDE developer.
      Try googling or reading instead of posting First forum post by probono about klik back in Jan of 2004 [knoppix.net]
  • by Com2Kid ( 142006 ) <com2kidSPAMLESS@gmail.com> on Saturday January 15, 2005 @04:41PM (#11375317) Homepage Journal
    Windows has had this for ages,

    we call them EXEs. ....

    Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!
    • Re: (Score:3, Insightful)

      Comment removed based on user account deletion
      • Just to bad you can't upgrade all your Windows applications with a command or two.
        • Crud. I should have used the preview button.

          Let's try that again.

          Just to bad you can't upgrade all your Windows applications with a command or two.

          I want to see a single klik way to transparantly upgrade my parent's WinME box to Linux. Not because they have lots of trouble with it, it's just because it's WinME.
    • Only very simple programs don't need an installer to copy over all the OTHER parts of the program that AREN'T in the .exe. I haven't used this, but it seems quite a bit different than you describe. It is more akin to being able to download a major program and it just running right out of the box without an installer at all, no matter the program nor the need to have "permission" to install software (either be root in a *nix or have admin privs in Windows).
      • I have tried it and it is more like you say. click the application you want and it downloads a folder to your home directory. I don't know if the executable was actually in there. Must have been. But what I clicked on to run the program wasn't actally the binary.

        It's pretty neat and for the most part worked. Sometimes (rarely) it asked me for permission to put something onto my system outside of the application's folder.

        So I think it's great, and something like this will probably be the future of applicat
    • In what alternate reality can you run a program without using the installer? Aside from a few tiny utilities (putty.exe), nearly all Windows programs require an installer. You can do the same thing in Linux too if your program doesn't have any external dependencies. The catch is that nearly all significantly-sized programs do.
    • Linux has had RPM's for ages. They don't always work perfectly, but neither do EXE's. And there are graphical interfaces to most common package managers; Debian has Synaptic that works with apt-get and dpkg quite nicely.
    • by Coryoth ( 254751 ) on Saturday January 15, 2005 @05:14PM (#11375497) Homepage Journal
      Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!

      This is actually a much harder problem that you might think. There are a few different solutions. The Windows solution has been a combination of trying to bolt down a core set of libraries that everyone can be expected to have, and generally completely ignoring dependencies/shared libraries and letting the installers either trample each other, or install multiple versions of the same thing in different places. It kind of works, but does have drawbacks.

      On Linux you could effectively do this by just having all packages statically linked, or have each package bundle up its own versions of all the libraries it will ever need. Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep). The problem is partly that open source has a release early, release often approach, which means the base set of libraries (which Microsoft simply bolts down) tends to be an ever moving target (Microsoft simply does everything in huge upgrade jumps every now and then instead... except for a few things like DirectX). The other half of the problem is that with all that source code out there being shared freely there's an awful lot more code reuse and a much broader range of shared libraries and hence dependencies. This is a good thing most of the time, but causes issues for installing software.

      Linux got around these dependency issues by having distributions which package up all the dependencies for you. This works very well, especially with apt, apt-rpm, yum, portage, and all the other fun dependency resolving tools, but has one drawback: If you aren't installing a distribution provided package the system has a lot more trouble tracking (and especially resolving) your dependencies. That means installing and maintaining a Linux system is easy, but adding new software from third parties can be a pain in the ass. Debian and Gentoo attempt to solve this dilemma by havign so many packages available from the distribution that you don't want for anything. As well as this works, it again isn't quite a complete solution.

      Which finally brings us around to the open source attempts to try and provide systems to allow third parties to package software. The principle now is: You let the distribution do the hard yards of installing and maintaining the syste with their packaging and dependency resolving systems, and simply provide some distribution neutral package format that can still slot in amongst all of this. There are several solutions, each taking a slightly different approach such as ZeroInstall [zero-install.org] and Autopackage [autopackage.org]. They are still in the works, but look to have some surprisingly good solutions. They are definitely worth a look.

      So, in summary, Windows manages to have their system by:
      (1) Locking you down on base libraries, and having a slow upgrade cycle on those.
      (2) Windows developers not sharing as much code, and not caring about actually sharing libraries even when they do.

      That is a perfectly valid solution, and it does work, but its never going to fit with open source, which has a pretty fast developing set of base libraries (which is a good thing), a lot more emphasis on code sharing, and an eye for efficiency. That doesn't mean open source can't have easy to install software (it already does for anything distribution packaged, and various solutions for third party software are well on the way), merely that, because of some fundamental philosophic tenets of open source, it is a harder problem than on Windows, and requires more cunning solutions.

      Jedidiah.
      • by Com2Kid ( 142006 ) <com2kidSPAMLESS@gmail.com> on Saturday January 15, 2005 @06:14PM (#11375796) Homepage Journal
        • (1) Locking you down on base libraries, and having a slow upgrade cycle on those.


        Actually it is more like a base API, the various libraries constantly go through upgrades and such, more of a feature lock.

        On one hand this is a bad thing, Windows did not even have a (decent!) built in dearchiver until Windows XP, but on the other hand it is also a good thing, as the free market allowed a number of competing (and ultimately superior) archival formats to come forth and not have to fight against any one single OS-supported format.

        • Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep).


        A key question becomes, on client workstations, are shared libraries REALLY all that much more efficient, a good trade off for the hassle that they cause?

        Honestly, a good HTML renderer, sure, Windows software has found a million and one ways to make use of that (A good portion of Visual Studio.NET's UI is basically a fancy IE window from what I can figure out, at least it behaves like one!), and other things like built in sound and video acceleration are (of course) handy to have around, but honestly, how often is some huge shared library really going to be used?

        Lets see, if I have a 3D modeling app open, Winamp playing tunes in the background, and my browser of choice (Firefox or IE which ever) up and running, what use are shared libraries to me?

        The UI, sure, but Windows has that, granted the options kind of blow, Win32 or .NET (suck up programmer time or suck up system resources), HTML renderer? Got that, my 3D program in the least is going to be using it for its help system and likely also for parts of its UI.

        A standard image manipulation library? If I install a new image manipulation program I want something revolutionary, something different, from it. Heck, $400+ painting programs sell specifically because the programmers have developed some kick'in libraries that are limited just to that program. Besides, I don't want a shared library that specializes in doing a Physics Simulation of paint on paper!

        Games? Sure, to some extent I guess, but how many games am I going to be having running at once? Honestly? 2 tops, even that is rare, most likely, just, well, 1.

        On server and application server environments, shared libraries are a blessing, but for a client environment, flexibility and the capability to rapidly deploy applications to the end user seems to be higher priority.
        • OK, any modern OS uses shared libraries and this is a good thing. Let's take that as axiomatic. There are a few people around who believe that shared libraries are inherantly evil and should go, but they apparently don't know anything about operating system engineering. Clearly if they did, they would not say that.

          So like any powerful tool, there is a tendency to overuse it, or use it where it's not appropriate. Without shared libraries we could not have systems like Windows XP, Linux or MacOS X because n

        • For me, definitely. I run a few GTK+ applications, a couple of Xlib apps so I definitely see large savings in memory use.

          Note that I don't use GNOME or KDE, so the actual savings are quite high. The top two memory hogs are Mozilla and X at the moment. My GTK+ apps are using about 4 Mb of RAM each, but 3 MB of that is shared memory, so the effective use is about 8 MB or so.
    • I've got a piece of software I release for Unix, Mac and Windows. When I originally created the Windows version I simply put all the files into one directory, zipped that up, and distributed it. To install, merely unzip to the location of your choice. Finished.

      I had complaints with this simple scheme. So I had to make the a self extracting archive. Sigh.
      • When I originally created the Windows version I simply put all the files into one directory, zipped that up [...] I had complaints with this simple scheme.

        No wonder, considering the fact that Windows did not ship with any kind of unzip until Windows XP. I too hated zip installs - mainly when I was reinstalling Windows or helping someone else install stuff - and most of all when the machine wasn't on the Internet. And WinZip is like 3MB, which takes a while on a 28.8 modem.

        It is really quite funny tha

    • That's what we like about generating Windoze executables with Delphi. It has a smart linker so it only links in the library routines it actually uses and produces one EXE file for the program. This EXE will run correctly on anything from '98 to XP without change. When the Linux community finally decides on ONE executable format that will run on just about any Linux installation, then they might have something.
  • It says If a package you want klik to install depends on a package in this base system it will not be included in the cmg so you must have it installed or add it to the cmg by hand afterwards.

    Somebody mentioned earlier this is like apt with web access. Well, reading that, it's more like brain-extracted rpm with web access. You want it, take it.

    • I don't think that dependencies are handled very well in apt-get, rpm, etc. All too often, by installing one 100K package, you wind up installing 1GB of dependencies. As far as I can tell, there's no alternative except for the override in rpm. I think the next generation installer is going to present a graphic dependency map showing you why the dependencies might be needed and let you determine which ones you are going to install.

      BTM
      • Dependencies are dependencies - they exist to say "I NEED these things to even work at all." If you find some package that lists something as a dependency but you have no problems using the package without it, you've just found a bug.
        • I'm talking about the scenario where package a uses icons from package b, so you go ahead and install package b but package b has a dependancy chain, etc. Yes, strickty speaking you would need all that to install the original package, but what if you had the opportunity to substitute the icons with something else?

          BTM
          • I'm talking about the scenario where package a uses icons from package b

            What package does that? If package b includes some files that are commonly used by other packages, those files should be packaged separately in, say b-common. Debian has lots of *-common packages.

            If it's just a few icons, another alternative would be to simply ask the person who packages a to include those icons in a (renamed or in another directory, so a doesn't conflict with b).

      • Uh. Why would you want to install a package without the other packages which DEPEND on it? Apt (at least) does install a conservative number of dependencies, and presents you with a list of recommended packages (if any are optional).
    • I was just trying to get across how dependencies are handled by klik. If you are on a supported distro they should not be a problem, if you are not on a supported distro then you may not have required libraries. As one of the major complaints in the previous slashdot story on bundled applications was about how many copies of libc or other common libraries may be around I wanted to get across that there is a slight solution to this in klik.
  • by imr ( 106517 ) on Saturday January 15, 2005 @04:46PM (#11375343)
    From that sentence One of the best ways to demonstrate the power of klik's techiniques is with the Christmas present from probono, an OpenOffice.org cmg for version 1.9.65..

    OpenOffice is one of those huge projects which come in preinstalled preconfigured and self sufficient package which have to be decompressed in one directory.
    So having a "klik" package is not a proof of technical achivement, as it would be trivial to have a, say, loki setup or even a script which untar the package and put the missing entry in PATH.
    No, give me a klik package of some kde or gnome program wich installs and works with every distro, aka fit nicely in every distro and rely on dynamic and present librairies. THAT would be a true demonstration.
  • by caseih ( 160668 ) on Saturday January 15, 2005 @05:01PM (#11375427)
    I have read through the docs, but I can't find any indication of how klik really works. Clearly the cmg file has to be mounted somewhere. I found references to the overlay file system (which linus refuses to integrate). Does the cmg file get mounted somehow (with a root helper) and overlayed on the root file system? cmg files seem to be created from binary deb files, so I don't imagine they are recompiled to look for their files elsewhere (say $HOME/etc or something).

    I believe this klik system could have real application across all kinds of distros, even RPM-based. However klik still doesn't truely offer (due to how linux works) apps that are dependency free. For example the galeon.cmg would still require mozilla and a few other things. I suppose they could make each cmg independent, but then we'd have tons of glibc's in memory, plus multiple copies of gtk, etc. How do they get around this issue?

    It appears the main target of klik is to allow the downloading and running of software in a liveCD environment. How will this work in a real environment?
    • Yes. Not only that, when installing, I am sure dependancy needs to be met and install scripts need to be run.

      You can break your system hard.

      Post inst script of rm -rf / will wipe yor system. So I really need some more explanation before I Klik from my Debian PC.

      Osamu

      • Nope, you are quite wrong. When installing the dependencies are calculated against a base set of assummed packages (from the supported distros) and no install scripts are run. Config files can be copied to /etc if you so wish and snap with files destined for /var (you are prompted to copy either if they are present). Besides, klik is run as a user, and needs no root privileges (except for the presence of suitable mount points in fstab).
  • by redmoss ( 108579 ) on Saturday January 15, 2005 @06:24PM (#11375845) Homepage
    Looking at the documentation, I'd say this is a step in the right direction for Linux to be appropriate for home users. For the typical user, it is important that they can find an "application link" somewhere on the internet and just click it to use it. Package management systems like apt/urpm/emerge work well and are still necessary for Linux, but klik-style installation will enable average users to be comfortable using software that hasn't already been installed by someone else. As a result, they will probably feel a lot more "at ease and in control" during their Linux experience.

    As a bonus, the linked application only runs with the user's privilege level. That means if it's a malicious app, it won't hose the whole system, and security/recovery becomes much easier.

    It almost makes me want to try out desktop Linux again (using OS X right now).
  • If you look at the architecture http://klik.atekon.de/architecture/ [atekon.de], you will see that it was heavily inspired by the .app structure from NeXTStep/OS X and mountable .DMG disk images from OS X.

    It's a good start.

  • To be a fully usable system for 'home' users it needs root access so it can install spyware etc. It also needs to be able to hide some file somewhere to implement those 30-day trial counters. Also if it could handle installing absolutely anything, from source, and fix all dependencies in a single click i'd be happy.
  • step backwards (Score:2, Insightful)

    by jeif1k ( 809151 )
    I think this is a step backwards. Linux installations are already "one click", with an excellent user interface: you go to the software directory ("package manager"), select what you want to have installed, and it just happens. That works in most modern distributions. After you have selected what you want installed, it gets maintained and updated automatically.

    Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when
    • This was modded as insightful?

      Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when they are going to get upgraded and whether the different pieces that are installed are going to be compatible. That is not progress.

      The .app packages that OS X use combine the dependencies within the .app directory so you don't have to worry about incompatibilities or causing problems with other apps in case the version of the d

      • The .app packages that OS X use combine the dependencies within the .app directory so you don't have to worry about incompatibilities or causing problems with other apps in case the version of the dependencies an app uses has bugs in it which might become exposed when used with a different app. Since the dependencies are included, they get updated when you upgrade the .app. Difficult huh?

        Not difficult at all, it just doesn't work.

        First of all, applications have dependencies on operating system libraries,

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)

Working...