Slashdot Mirror
Point-and-klik Linux Software Installation?
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.
Can Klik install Gentoo Linux?
Powered by caffeine and sugar; BSD
What's wrong with that?
Sure you can be opposed that's fine but nobody's telling you to go for it or nobody's telling the guys at gentoo "ok, follow the klik's way!"
It's simply more choices and the ones who will prefer this are the migrating users who come from windows. They have to point & click the most possible to get confortable with an o/s environment.
"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...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
I am morally opposed to Gentoo users
Well, I don't get that with Firefox on Windows XP, though if I set the user agent to IE 6, I can see the message you describe. If I set the user agent to Opera, I still don't get the message. Is your user agent set to IE right now?
In 5, 4, 3...
Oh, wait. This isn't related to KDE.
Indeed, using Opera on Debian Sid, I get the 'unsupported operating system' error only when the user agent is set to IE. Opera users: press F12 to change it to Mozilla, for this site.
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.
Powered by caffeine and sugar; BSD
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?
Linux is not Windows
Loads fine with Safari on OSX, despite the fact that I probably can't "install thousands of applications simply with a klik.".
Heh. Go Figure.
I think I need a new sig here.
You can use Google's cache if you don't want to mess with your user agent string to see the site:: klik.atekon.de/+&hl=en
http://64.233.161.104/search?q=cache:DcXkKzGdgk8J
In Opera, even on *nix, the site will refuse to display unless you set your agent string to Mozilla. Opera or MSIE user agent strings (which is usually default in Opera) will make the site think you are using Windows/MSIE.
Powered by caffeine and sugar; BSD
Actually, as an actual Gentoo user, it sounds pretty good. It'd be nice to have a variety of gentoo compatable binaries on the net, and easily installeable/removeable ones at that.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
It sais: "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."
Two wrongs still won't make it right.
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
Unfortunately I don't think klik, as nice as it is, is quite the solution to this. I would suggest, instead, that Autopackage is a far better solution for providing a means for installing third party packages. The people writing autopackage have spent much time carefully considering the difficulties involved, and have some very cunning solutions to some of the problems.
What does Autopackage do well? For starters it does the basic things that you'd expect well - it's got a nice GUI installer, it can fall back to a console installer, and it nicely wraps up a binary package in a "download and run it to install it" system. It has other bonuses that are more subtle, but for third party packages, suprisingly necessary. For starters it is distribution neutral, but at the same time does dependency checking and resolution. That's not so easy if you actually think about what it requires.
Autopackage is, of course, still in development. The really nice features (integrating in with rpm and dpkg databases etc.) aren't coming for a very long time yet. For now though it does work, and can install packages. If you're writing software it may be worth your while to look at what Autopackage asks of developers (you do need to do a little work to make code autopackageable) and keep it in mind as you go.
Jedidiah.
Craft Beer Programming T-shirts
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!
Need help treating your acne? Come here!
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 am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
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.
What do you want to do in a debian repositore using windows? Just slashdot it?
Rethinking email
Er, read it while I happen to be using Windows?
Duh...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
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
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?
Indeed, I use linux and XP on this machine, and I just happened to be on XP when I read that story, enough to put me off ever trying their software.
Being a Windows user and being interested in Linux are not mutually exclusive things.
I first tried Linux back in high school after hearing about it from friends and even bought a copy of Red Hat Linux 6.2. I've installed Slackware after seeing it mentioned a lot on the Internet, and Gentoo I discovered one day probably through Slashdot, and after reading their installation guide I thought "cool, I'll give it a try." In fact, I'm downloading GoboLinux right now after being reminded of it through the last link in this story.
Exposure is a good thing. You can't gain supporters if you deny potential supporters the chance of learning about you. And yeah, I'm a Windows user.
If Linix is ever going to be a real force on the desktop in general, and not just the corporate desktop, it needs to do some serious work on how programs are installed.
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
Indeed, I can see such a system actually working better on Linux than it does on OS X due to the ability for the package to contain executables for multiple OS's. A single package could contain executable code for Linux on x86, x86-64, PPC, S390, Alpha, MIPS, and all other Linux architectures (along with Mac OS X if one wanted to). Have a buddy running a different architecture you want to share an application with? Just copy it to their system as-is: the loader selects the correct executable and libraries within the package to use, with all the architectures sharing common application resources.
Installing applications on Linux is one of the major hurdles for Linux to 100% pass the "Mom test" here (my mothers system is running Fedora Core 3, because it's vastly easier for me to manage and maintain for her remotely than Windows ever could be, and I don't have to worry about her accidentially deleting system files or otherwise munging up the system somehow, besides being stable and damn good looking!). Mom recently wanted me to find and install a bunch of card games and little arcade games for her, and besides having a hard time finding many such games that suit her tastes on Linux (she doesn't want online multi-player, and doesn't need 800 different solitaire games), the ones I was able to find were a PITA to install (as most of them were source-only, build-it-youself, and then go in and manually create the necessary data files to add them to the Gnome menu, the latter of which I continue to believe there is no excuse for anyone to have to do).
On top of this, IMO the Open Source community needs more package maintainers, especially for smaller projects. It's hard enough for a moderately popular project to keep up with development, user requests, bug reports, end-user support, web site maintanence, and documentation as it is, nevermind trying to ensure your project gets packaged for the myriad of different packaging formats out there (and not just for Linux either if your project is portable to other OS's).
Okay, rant mode off. I neeeded to get tthat off my chest :). Linux program install has a long way to go before it's going to be friendly enough for the average non-sys-admin user.
Yaz.
A fellow Gentoo user, I don't see this fitting into the Gentoo paradigm. Gentoo, from its very beginning, is the opposite of packaged binary software. The initial geek factor with Gentoo was that you could throw in all the wacky compiler optimizations you wanted and build your Linux system from scratch -- very attractive to a small percentage of humans.
/opt -- an obvious attempt at some modicum of castigation. I suspect that there will be little impetus at the developer level to move Gentoo in the direction of more precompiled binary applications and away from the "compile everything from source with your own optimizations" model.
What I'm seeing now is that Portage has a couple really cool advantages over other packaging systems, and with those features come a horde of less wacky enthusiasts. Those features are, namely, ease of removal and upgrade and dependancy bliss. Nothing like issuing an "emerge world" and coming back 10 hours later with no hitches.
Even the binary packages you can install through the portage tree are relegated to
It just seems to break the foundational philosophy of the distribution to me.
-Ant Slayer-
Thats all fine and dandy but they have all of eight "packages" to install.
Is there a seperate package repoisitory somewhere?
They have so few packages because they are still in development on the packaging system. As I said, an application (or library) developer does need to make some changes to the code to make it autopackage ready. The changes are small, and are very little work, but they do need to be made.
As to other repositories - anyone can set up their own autopackage repositiory, so a third party software developer can simply set one up when they package their software. The end result is meant to be akin to the Windows way of downloading and running a package, but with the added bonus that it resolves dependencies too.
For now Autopackage is something for developers, not users - anybody writing code that they want to package up themselves for people to download ought to be looking at autopackage and using that for their packaging needs instead of RPM, or DEB. Once that starts happening you'll find a lot more applications available as autopackages, and it will start being very useful for users too.
Jedidiah.
Craft Beer Programming T-shirts
The optimizations are not important for lots of gentoo users. What is important is the freedom of choice regarding optional dependencies. With Gentoo you can e.g. remove mysql-support from all packages and ignore (not install) mysql. Since mysql is a popular package most binary distros come with mysql support compiled in their binaries so you have to install it even though you don't use it.
Linux is not Windows
You see it from the user's perspective. Thats fine but to create a new way of installing software you have to see the problems with the existing ways. The major problem with OS X Style program installation (and windows installers most of the time) is that they all contain every library they use. This leads to duplicated (in memory, where this is important) libraries and more important to outdated versions of libraries that might contain old security holes. Linux dependency tracking software installation approach is superior to these two forms but it clearly is much more difficult to do dependency resolution without a central repository (basically the lack of a common way of naming things makes decentralized dependencies difficult). The Installation System on Linux needs work but it shouldn't go in the direction of Windows and/or Mac from the Developer Perspective even though the result might feel similar from the Point of View of a User.
Linux is not Windows
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
I think I've already written on tract about different systems for handling installation, and the pros and cons thereof, but that was in comparison to Windows. It looks as if it is time to discuss MacOS X.
Yes the OS X system is beguilingly simple in its ease of use. Drag and drop, multiple architectures in one package, no files strewn across the file system for each package, clean and simple. This does have its drawbacks though. One drawaback is shared libraries. MacOS X largely gets around this issue by having a huge monoloithic, heavily standardised base set of libraries to do, well, most everything. That core set of libraries is religiously controlled by Apple, and no one tinkers or changes it unless they buy the latest upgrade from Apple. That means application developers have a nice fixed set of shared libraries they can link to without having to worry about dependencies. Of course, anything outside that base set of libraries either has to reinvent the wheel each time, or have multiple copies of the same library not being shared between apps. Multiple copies of the same library has a few problems, the biggest being that it tends to hog more RAM than needed, and for security purposes there's no central place to upgrade/fix the library. Still the end result still works pretty well, and as you say, it's a ncie system to use. It is worth noting, however, that Apple themselves are moving away from App Folders and tend to have installer programs for even their own applications now.
So why can't Linux just do like Apple? There is no core set of libraries that everyone can be fully expected to have. Contrary to popular opinion this is less to do with the "Desktop War" between GNOME and KDE, and more to do with the release early, release often philosophy of open source. New versions of widget toolkits, CD backend libraries, and who knows what come out with startling regularity: Core libraries are a moving target. This is, of course, good in that open source software is continuing to advance and improve at a very impressive rate, and everyone can develop against the very latest if they want to. It's bad for installers though, because you don't have a 100% locked down "This Is How It Shall Be" set of shared libraries. This will not change. Open source is always going to be release early, release often, and developers of open source apps are always going to try and develop against the cutting edge of code. At the same time, because there is so much code out there, freely redistributable, there is a lot more shared code, and hence a lot more shared libraries that cover all manner of obscure things. Again, that's good, but again, its an issue for installation. That won't change either though - this is open source, so everything will be open and code reuse will be rampant (that's part of the point really!).
At it's core open source simply has philosophic issues that make App Folders something that just won't fit in with the open source world. Don't despair though, there's no reason a drag and drop front end that makes RPMs or DEBs look like App Folders can't be written - it simply interacts with the package database instead of directly with the filesystem. The visible results for users can be made to look identical.
As to how to actually handle software installation
Craft Beer Programming T-shirts
I'd like to see a version of the package directory (or tarball, or filesystem image, or whatever you end up with) that included the sources and instructions for building them so that it might work on architectures the initial package does not provide for. It would be pretty well trivial to implement the basic underpinnings of all this stuff if it weren't for dependencies...
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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).
You have not given any reason why autopackage is better than klik. I think klik is better. Firstly, klik has *no* installer. Packages just work the instant you download them. That beats an installer any day of the week. Klik does lots of dependency checking and resolution also, but it works behind the scenes before the package is downloaded, completely invisible to the end user. Furthermore, klik is useful today, with lots of packages that are autogenerated from Debian packages. Autopackage might have a couple of packages now, but nothing near the selection klik has.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
besides being stable and damn good looking!
Please, tell us more about your mother.
It's nice to see that Linspire customers can use a free alternative to Click n Run, and get out of paying yearly for such a service. The only down fall is the lack of OS updates. But at least its another choice.
completely missed the point.
Then we're talking around each other, because you seem to have missed my point.
Debian's "easy" system isn't easy because of its size (as the autopackage faq suggests) but rather because of their strict adherence to policy standards.
We're talking about installing some software. It is "easy" to install software on Debian if it is in the Debian package repository. If it is not, then how exactly are you planning on installing it? Compile from source? Not "easy". Download a third party provided DEB package? That ought to work, but that's hardly easy for the developer who has to provide a DEB package, a Fedora RPM, a SuSE RPM, a mandrake RPM etc., and then there's the issue that maybe the DEB was for Ubuntu and linked against some libraries in Ubuntu that aren't in Debian stable yet. In short, installing software that is not in Debian's repositories is hard. This mostly doesn't matter because Debian's repositories are BIG so the odds of wanting to install something that isn't there are rather small.
You can discuss policy standards all you like, but in the end if the software isn't in Debian, it isn't likely to be following those standards.
Let's be clear anyway: Autopackage is not a replacement for dpkg, apt, and all the usual Debian goodness. It is complementary to all of that, and is meant to provide an easy way for those "not in the Debian repository" packages to still be easy to install (and at the same time allow developers to package once, instead of "once for each distribution").
And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators.
Autopackage is about empowering users not just administrators. A user can go to the homepage for [insert random application here], download the autopackage file provided there by the developers, then just double click to run it and up comes a little installer that checks and resolves dependencies. One of the key points of Autopackage is for binaries to be relocatable. That means a non-root user can still install an autopackaged file - it just gets installed to their home directory instead of systemwide. Autopackage is not meant to manage a distribution - Debian and Redhat and SuSE already do that pretty well. It is about providing a way for extra third party application not already in the distribution to be easily installed by users.
Jedidiah.
Craft Beer Programming T-shirts
Let's be clear then: Klik is fantastic if you are installing a package from Debian. Klik is completely useless to you if you are running SuSE, Fedora, Mandrake, Gentoo, or any other non Debian based distribution. Klik makes installing Debian packages easy, but so does apt and Synaptic (in a different way). It does not solve what is the real difficulty with installing Linux software: Installing something that has been prepackaged for you by your distribution. Installing new software on Debian is trivial, and Klik adds a convenient new layer to that by making it accessible to users who don't have root access. It doesn't address the problem that is always brought up when people claim about hard to install software on Linux. Read some of the complaints about Linux from Windows and Mac users. Once your want something not prepacked by your distribution for you, you're pretty much back to compiling it yourself. It is this that Autopackage hopes to solve, while at the same time making user installs of software easy.
Jedidiah.
Craft Beer Programming T-shirts
I have been using Knoppix 3.7 from the CD for a couple weeks, and klik is a great way to get software that is not normally availble. However, I would hate to run this on a writable system.
.cmg files directly and just run something like AppRun appname.cmg and be done with it. then if i were to save the file to a diskette or another computer, I would not have to worry if the site was down.
For one thing, as far as I know, you have to run klik in a webbrowser. It is a protocol (klik://). I do not think there is a way to run it from a command line yet, and that would just makes it easier sometimes.
Also, the way it is set up right now, it is very dependant on the central klik site, which was down for a couple days, so I could not run the klik software during that time.
I would like to beable to easily download the
But, it does serve its purpose. I can usually run nearly anything from my livecd, which is great.
Sorry, typo:
It does not solve what is the real difficulty with installing Linux software: Installing something that has not been prepackaged for you by your distribution.
Craft Beer Programming T-shirts
It's a good start.
Jesus was a compassionate social conservative who called individuals to sin no more.
Overall, good comment. Some things I'd like to respond to:
I'm sure you know this, but just for those who may not (and interpret your message incorrectly), Mac OS X does indeed have a shared library mechanism.
With that out of the way, as you've noted yourself, in those cases where an application does need to make use of shared libraries you can have something closer to a traditional installer to install Mac OS X applications. In many cases, however, this installer can be much simpler than what one usually sees in the Windows world, as you can just copy in the shared libraries you need into the correct locations, and then copy the rest of the application package to its target folder.
Let's not all forget, however, how having a central library repository can wreak havoc on ones system. Anyone who has ever used Windows can tell you about "DLL Hell". Remember what it was like back in the days of Windows 3.1? Every application shared common libraries under the same name, and if you installed a new application it might decide to "upgrade" that library to a newer version, causing all sorts of problems with other applications also relying on that library (due to changes in functionality, new bugs, or whatever).
Now granted the Linux way of handling libraries is significantly better than the Windows way of doing things. However, allowing applications to have their own versions of common libraries does have its benefits. If developer A writes "Widget Set 2005" using "doodadlib v4.0 rev B", it isn't going to start to exhibit oddities just because you installed developer B's "Widget-O-Rama 2004" which uses "doodadlib v4.0 rev A". Library versioning issues disappear in this scenario.
And there are ways to mitigate the extra RAM usage. I don't know OS X's innards well enough to know whether they use a system like this, but there have been operating systems which keep an internal lookup table based on the library name/version (and perhaps even some form of signature) to identify libraries. When a call to an unloaded library is made, the OS typically catches an exception, forcing a lookup against the loaded-library table. If the library requested by its name/version/signature is present, a new copy isn't loaded, even if the application has its own copy in a different location on disk. Later versions of IBM'S OS/2 operating system have a system something like this (which can be disabled using the LIBPATHSTRICT option IIRC). Again, I don't know enough about OS X's internals (yet) to know how it handles library loading, but if this is indeed the case RAM wouuldn't be an issue (you merely wind up wasting more disk space keeping multiple copies of the library around). And if OS X isn't doing this -- well, it should :).
Indeed, I've been using Linux in one form or another since 1994, long before there was a Gnome or a KDE. This issue pre-dates both of them. However, it has been particularily within the last 5 years that there has been an explosion of Open Source runtime environments and libraries that accomplish the same goals, causing all sorts of duplication. This in and of itself results in far more wasted memory
It's a joke, Sarcasm- [don't] get it?
Is there anything better than clicking through Microsoft ads on Slashdot?
I've seen enough gentoo users make comments on this topic and piss people off, so I'll be brief.
I've done this by ssh'ing into a computer from many miles away, emerging the app, waiting for it to compile, and it will appear in the gnome or kde menu. This is why command line package systems are nice, you can easily use them using ssh without having to worry about X forwarding. And portage will put the little icons in the menu which is very nice.
You misunderstand. It does not require a debian-based distribution. The current implementation assumes that some software (mainly KDE) is preinstalled on a user's machine, but it doesn't necessarily need to have been installed from debian packages.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
The why are all the "supported distributions" Debian based ones, and the documentation page on "Using with Other Distributions" only lists SuSE as non Debian based, says it is "harder to support" and then has a long set of instructions for what you need to do to make it work? That does not sound like easy installation to me... it sounds like rather painfully difficult installation for any non Debian based distributions.
Klik is a very nice system, and it works admirably for Debian based systems, but ostensibly its just providing Debian packages the same as the Debian repository. Any packages it provides that aren't already in the Debian repository have been packaged for Debian. Therefore it isn't really a solution to third party packaging issues (which was the original point I was replying to).
Jedidiah.
Craft Beer Programming T-shirts
The Mac OS X application packages can also be "installed" via the command line by mounting the disk image (if any), cd'ing over to it, and then using "cp" to copy the application to its destination directory.
Where Linux systems currently have a benefit is that they often have package retreival systems atop the packaging system itself. Apple's packaging system is akin to RPM -- it's a package format. This wouks fine if you have the package in the first place. Where systems like yum or apt-get or emerge are benefitial is in being able to get packages in the first place, and to ensure that all pre-reqs are met (and if not, to retreive and install them as well). Still, these tools typically don't specify the package format themselves, but are designed to work with another (usually specific) packaging format. As such, they aren't directly comparable.
I do see how these package management/download systems are of benefit to systems administrators and power users -- they are powerful -- but they are also beyond what most end-users would tolerate for software installation. And AFAIK, most of them are directed towards retreiving code from networked repositories, and don't really do you much good if you're buying software on CD-ROM as your typical consumer is apt to do (no pun intended ;) ).
Yaz.
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.
This comment does not represent the views or opinions of the user.
Hey, in their day they were really innovative.
One of the first simi-live cds with a truly GUI install. I even bought a copy back then. ( doing my part to support OSSish development )
They were a bit wierd thou.. explains why they dissapeared.
---- Booth was a patriot ----
Actually, ther real way to install things is probably the Mac OS X way...
Click. Drag. Drop. Done.
Moof.
As a rule I only download a new version when security issues appear.
You must spend a lot of time keeping track of security vulernabilities if you plan on keeping all your software up to date manually. How do you even keep track of the updates? Do you visit the web page of every software package installed on your windows system every week? Between security updates and software updates, you must spend 1/2 the week browsing websites.
This is a huge advantage of Linux packaging systems, with distributions like debian and gentoo, I can keep my whole system secure and up to date with a single command.
Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro. Then when you install the klik client it can check to make sure you have that software and install it if you don't (using a simple script that runs your distro's package manager or simply downloads the necessary files from klik itself). After that klik would work the same way it does on Debian. It's much simpler and more straightforward than developing an alternate meta-packaging system that does on-the-fly dependency resolution using any of 10 different package management systems; and therefore much more likely to work correctly and much less work to implement and maintain. That's why it's better than Autopackage. Less complexity = better software.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Moof.
The autopackage stuff also will know nothing of Debian policy. Hence, it will suffer from exactly the same problems. The policies define the packaging environment, not the files or the tools. Third-party installation on Debian is also simple. Just use epkg, stow, whatever in /usr/local. No, it won't know about Debian dependency policies. Neither does autopackage.
So the easy way of installing third party packages on Debian is to compile it from source? That being what stow (which I use), and from the look of it epkg, require you to do. You my as well use checkinstall instead, it'll provide more useful results (it adds a source compiled program into the dpkg database). No, that oesn't sound like the easy solution to let Grandma install third party packages that the original poster I replied to was looking for.
Let me quote the original again:
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
The issue is when the program is not provided by the distribution: right now that's not easy, or so the OP claimed. Your solution is: compile it from source and use stow or epkg to put it somewhere nice. That's not a solution, that's what we've had for the past 5 or more years on any distribution. If that was a solution why do you think people keep raising the issue as a problem?
To be honest I have no idea quite what you're ranting about any more. The question was: "Will this make installing non-distro provided packages easy at last?", my answer was "no, as good as klik is, it only really works with Debian based distros, so is just more Debian packaging really. Try autopackage if you want to install 3rd party apps."
You seem to have taken great offense, but I'm not sure to what.
Jedidiah.
Craft Beer Programming T-shirts
Sorry, I really expected the comment to be funny. Bad choice.
Rethinking email
Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro.
Welcome to "The Problem". How do you know what's installed, and which version it is? If it's Debian it's easy because it's all standardised, if its any distribution then it gets very hard very fast (particularly on version of library etc). You have to figure out whether the library is there even though the location, name, and version may all be different. Drawing up a huge table for every distribution out there is going to be very tedious indeed. Especially when you need a seperate table for each library dependency. The instructions for making klik work on SuSE get around this by literally making you copy over the libraries from a working Debian distribution. It's quite a list to copy over to make everything work.
So you're down to 2 choices - have an unbelievably complex bunch of logic to check what distribution it is, what version of the distribution that is, determine what the corresponding locations and names of the required libraries are, checking if they're installed and what version they are etc. or simply packaging up all the required shared libraries into the package - which is to say, ignoring dependencies entirely... which raises all sorts of other issues like RAM use, and security.
Making this portable across distributions is incredibly hard. It's not the easy last step. If you want portable across distributions try Zero Install or something. I doubt it'll happen all that soon with klik.
Jedidiah.
Craft Beer Programming T-shirts
The script goes through the list of base libraries (which is much much smaller than the entire list of possible packages for each distro). For each library it has a location to check and a location to obtain the file if it is not there. It simply downloads the files you are missing and that's it. Very simple. If you want to be fancy it can use the distro's package manager to install the files if possible, but that is not even necessary. In fact, if you don't use a specific distro package manager, this script could probably be portable across several distros. After this simple script finishes you are ready to run any klik package.
There are of course tradeoffs with the klik approach. However I think that it is the most sensible packaging solution to come along yet. It provides a middle ground between "huge self-contained packages with everything included" and "completely modular packages, but you need to download 10 dependencies to install any software". I'll list some of the potential problems I see:
I believe a sensible base library set can be found such that most applications will be a reasonably-sized download, yet the base library set is still manageable. Yes some libraries will be downloaded twice, but it's not the end of the world.
If a particular program requires an updated version it can be included in the klik package. I think the longer-term solution, however, is to provide a new version of the base library set every few months. Since it hopefully is kept small, this is still doable.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
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 they are going to get upgraded and whether the different pieces that are installed are going to be compatible. That is not progress.
Please let's not dumb down the Linux package system to the level of Windows or Macintosh: that would be bad for all users, expert and novice alike.
Oh, no worries then :)
You know, some people own more than one computer, and some people also use computers at work where they might not have control over what software is run. I happen to be on an XP box at the moment, but I have 3 machines in this same room running Linux. Somehow, I think this software could potentially be useful for me, even if the machine I'm on at this exact moment couldn't run it.
In short, while the webmaster may have thought they were being cute, this is just plain stupid. W3C standards are good, use them. Don't fall for this "Well, if I can't see your site, you can't see mine" crap. It's exactly the reason why the web was so broken in the NS4/IE4 era.
What's wrong with getting a new, non-critical application running this way? I don't want to have to write an ebuild to try out a little game or something trivial like that.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
It's not a matter of a non-Linux operating system being used to view the site. It's this text "Please come back with a standards compliant operating system and browser." Who's standards? What standards? There are no 'standards'. If it said "Please come back with a Linux based operating system and browser" it would be another thing entirely. I get the feeling that the person(s) that put the page together are the same type of person(s) that berate people for asking a question about how to do 'X' in Linux using mixed case lettering and telling them they are n00bz.
It certainly won't bring more people to Linux.
Steve's Computer Service, Hobbs, NM
-]Phreak Out[-
The right way to solve this is by providing binary relocatability support in core libraries and small utilility files that can be statically linked. This is what binreloc is, you can find out more at the autopackage homepage, and it's designed to be trivial to drop into pre-existing software. It requires patching the code, but it takes all of half an hour to do even complex apps like Gaim and Inkscape. The fact that it requires patching isn't a problem, as autopackage is designed to be used by upstream developers with their full knowledge and consent.
It is best described as a hybrid between NSIS/Loki Setup type installers, and package managers such as dpkg and RPM. Autopackages are programs that understand the quirks of various distributions, and which contain binaries compiled in such a manner that they are binary-portable across a wide range of Linux systems. When run they will integrate that software with the users system in the tightest way possible. They understand dependencies and dependency checking, and can resolve missing dependencies. They understand 4 or 5 different menu systems and can place items in the menus for all of them. It allows you to install that software to your home directory. It provides both GTK and Qt based uninstallation tools. It has been designed with end-user usability in mind from the ground up.
It is a real, useful piece of software that exists today and is not a theoretical program that works perfectly in a theoretical world. It does not require you to use it for all your software. It does not require special setup. It does not require distributions to support it. It does not need you to be using the "right" Linux system to work. Naturally, it is not a magic pill that works 100% of the time either, but that was a conscious design tradeoff we made at the time.
In other words, it's a program designed specifically for the situation the Linux community currently finds itself in. Please show me another program that meets these design criteria. The closest I'm aware of is ZeroInstall which is nonetheless very different.
Also in future we want autopackage to know how to use apt to install things it needs, as well as being able to resolve dependencies from other autopackages.
Autopackage is not a magic pill that makes everything better. It is a tool that combined with changes to software and new methods of community development can significantly ease the pain of installing unsupported software into a distribution.
it also allows them to utalize features that every other browser except IE (and perhaps lynx) has like transparant PNGs.
Unfortunately you don't know what you're talking about. Mac OSX installation is very nifty but you can't do it with Linux, just try.
I'm both a daily Mac OS X and Linux user. I've been using Linux in various forms since 1994 -- long before 99% of the people posting here even heard of it. So forgive me if your words carry no weight with me.
I'm not claiming that Linux has the same install system as Mac OS X -- I'm saying it should strive towards a similar system as what OS X uses. It would obviously need to have some tweaks and modifications to fit better with some of the assumptions built into the core OS, and would require modifications to the program loader(s), but other than that there is little reason why it couldn't be done. It merely requires someone to develop the necessary code to do it.
Yaz.
Heh,heh, you must be new here - there ARE NO funny remarks on
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
I didn't run anything. I went to the site to see what it was about.
Duh...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Look, moron...
I run Linux AND Windows. What part of that don't you comprehend?
I'm NOT trying to RUN anything. I'm visiting a fucking Web site, okay? I don't like it when I use Opera and some fucktard tells me his site won't even be SHOWN to me because I don't use IE, and I equally don't like it when some Linux fucktard tells me I can't even VIEW his site because I "don't run Linux" when IN FACT I DO run Linux.
Get the picture now?
I download TONS of software from Linux sites for Linux using Opera running on Windows 2000. I even store it on a FAT32 partition under Windows 2000 until I can get around to booting Red Hat and moving it over to the Linux ext3 side of the machine.
This asshole is somehow different that I have to be using Linux to even view his site?
Bullshit. His site should be viewable in any half-way modern browser, period.
He's a moron - and if you can't grasp that, you're a moron, too.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Some people use Windows machines at work and have faster internet connections there, or CD-burners, or more spare time (:-). Why not allow downloads from there?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
But seriously, this is a highly specific site, designed primarily for Knoppix/LiveCD users. Complaining about it is like Windows update not working for BeOS... DUH!
Turrents syndrome for 100, Trebek.
For use with Knoppix 3.7, Simply MEPIS 2004.04, Linspire 5.0 (need to install client first), and Kanotix BH X (client preinstalled).
Here, to appease you I'm going to leak some of the content for you:
klik://ada-mode
klik://ed
klik://ee
klik://ee
Use these links in any way you wish.
Whoops, "turrets"... used to typing "torrents" since we are on /....
Also one of those links should be 'klik://e3'.
Yeah, you just gotta love these /. highly educated technical nerd-boys...
Can't even respond to the right post...:-)
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Why? I absolutely HATE the OS X system. urpmi was one of the most pleasant surprises I had when installing Mandrake.
catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }