As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.)
One of the quotes I’ve had queued up for a long time is this one from Jon Udell:
I have a confession to make. Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.
He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows.
Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes.
In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script.
Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable.
Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now.
Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev.
Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs?
At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.)
After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer).
Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.)
Oh, well. At least I didn’t have to check for viruses!
Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used.
Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things.
However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively.
Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…
So, the Java Studio Creator installer succs. How is this the fault of open source or Linux.
Its not hard to make a good installer that works regardless if you run windows or not.
What Sun should have done is to work with existing install systems. What sun should have done should have been to set up a repository of their software, that way it would have inteacted with the Linux package manager. If done right installation is usually just a mouse click away. Using repositories also makes it possible to distribute updates automagically.
It shouldn’t be hard to create such repositories, most Linux support the LSB standard so they would know what libraries to expect.
“The next Windows version will be called Windows-Sharia. The only Windows-authorised PC will be a sealed-off device with a screen and two holes. You will have to stick your hands into the holes to operate the PC. If you copy software illegally, then the Sharia will chop your right hand off.”
Ha-ha-ha. I like this one. This would probably prompt people to look for an alternative OS much faster :)
Another option is to use the packaging approach used in Mac OS X and also in GoboLinux. The binary and ALL the required libraries are packged typically into one directory.
This approach typically duplicates dependencie / libraries but on the other hand each application can use its own version of a dependency or library. The use of this approach in Mac OS X is one of the reasons why new installations of software in Mac OS X are more reliable without any dependency issues (like in Linux).
MacOS X could have used the packaging approach used for many years in Unix / Linux but did not. One should ask why? I think Apple though the Unix / Linux pacakging approach too cumbersome and prone to dependency issues.
With a good package manager (which Mac OS X does NOT have), a Linux distro using this approach would be awesome to most end users and more reliable than a typical Linux distro.
Check out GoboLinux which uses this approach.
RobK
One more addition: The Zero Install web site seems to be a little unfair to Klik concerning the root rights at their comparison page:
http://zero-install.sourceforge.net/matrix.html
To my knowledge you only need to be the root when you first install the Klik framework. You do not need to be the root afterwards, when you pull down the applications from the web. So the comparison table is a little incomplete or misleading, if not unfair.
But I am not an expert on either of these frameworks. I have found this information on the German Wikipedia entry about Klik. What do you think?
Regards- Martin Jasny
I’m a bit confused. Are you complaining that “Sun”, a competitor to RedHat, doesn’t release a Redhat installer package? Or are you complaining that Redhat did not create a Redhat installer package for one of it’s competitors products?
I just want to make sure that I have a handle on the issue. I’d create the RPM myself if the site would let me DL the utility. They appear to be having issues at the moment. Hopefully, the license won’t prevent me from creating an installer.
Frank
There’s a more fundamental aspect to this, which the subhead to Mr. Murdock’s blog, “the Linux business opportunity,” points to. In a nutshell:
Why should an unpaid, volunteer developer or maintainer of an open-source application care if there’s a common mechanism that spans the various distributions that makes it easier for users of closed-source, proprietary software to install it? Who’s this aimed at, the end-user, or the software vendor?
(To use Mr. Murdock’s example, Java Studio Creator may be “free” as in “free beer,” but a 3-year “premium service contract” will set you back $3000.)
If software vendors want a mechanism like this, it would seem to be up to them to come up with it.
obviously the problem is that yer a dumbass.
RPM/.deb/.tgz.. All have their advantages and disavantages, all have their infrastucture, proponents and developers. Too many egos in the way. Unless everybody or at least most can swallow their pride and agree that there should indeed only be one way to install software in Linux, it will never happen. Unfortunately that goes against human greed and the ways of modern humanity. Not pessimistic, realistic. Whatever solution will have to recognize and use all of them for it to happen.
Ah, Windows is being compared, is it? Well, okay, I download my .exe file and put it somewhere. Then I go to Control Settings, Add/Remove Programs, and I click on Add and I click on Browse, and I find my directory where I stored my file.
Oops! Where is it? Uh, oh! Guess what? The Add/Remove programs browser assumes you ONLY want to install .msi programs – official Windows installer programs. But your ISV used some other installer and it made an .exe program instead.
Now, if you KNOW Windows did this, you just click the drop-down box and select “All files” and you see your install program, then you click or double-click on it and then say Ok and Finish and away you go.
But if you’re clueless, like most Windows users, you’re stumped by the simple fact that your file doesn’t show in the browser window. Sad, but true. Another example of both poor usability design and Microsoft arrogance (why would ANYONE want to install something not installable by OUR installer? )
Another comment. I like the way Firefox is installed on Linux. Download, untar, run the script. No Registry crap, no stuff scattered all over your system (except for your profile information) that you can never find when you need to uninstall. When the distros get hold of Firefox, though, they try – or think they’re trying – to follow the File System Hierarchy recommendations, and they scatter Firefox to the four winds of your directory structure instead of putting it all in /opt where it belongs. More stupidity. If a program isn’t part of the system, if it is a program installed by the end user (even where the “end user” is actually his own “system administrator” on his own machine), install the thing in /opt. It’s NOT part of the system, no matter what it does (obvious system utility exceptions aside).
I agree that all Linux and OSS software should install as one single file put in one place which runs when clicked on in the file browser. Forget the system menu structure altogether – let ME organize MY OWN “menus” from my directory structure. OR have a standard that allows this single file when run the first time to tell the system WHAT KIND of file it is and WHAT KIND of APPLICATION it is so the system can figure out where to put it in the menu structure. So we can avoid the situation I have now on Kubuntu where Kate is under “Utilities” and a newly installed jEdit is under “Editors” in “Other Applications”…
The problem is ALL the distros have their own notions of menu structure, not to mention overall system structure. The “Not Invented Here” syndrome is paralyzing to the entire OSS industry. The Ubuntu “we’ll never let you run as root no matter what” attitude – contrary to every other Linux distro on the planet – is an exceptionally bad example. Not to mention the “we’ll never let you see the KDE Control Center unless you jump through hoops” attitude.
Ultimately we need to do away with “applications” altogether – an “application” should simply be something else the OS knows how to do.
Linux has come a long way. 10 years ago I hated it, couldn’t understand it and I’m a geek. Now it’s so good that I offer it as an operating system on pc’s I manufacture. The install issues will only force developers to make better installation packages. I for one appreciate all the hard work linux developers do for free.
In my opinion, Linux has to become better at playing video files on the web, playing dvd’s, playing online games, yet some of these issues are only because I’m basically a newbie to Linux. As I research some of these issues and become better at installation, both me and my customers will be happier campers.
Thanks for the hard work and issues of installation will become non-issues because developers will get better at it, most of them anyway…
What surprises me so much is that these rather obvious deficiences seem to have eluded the men behind the major distros. Only the other day I read an article where someone from Red Hat / Fedora were reaffirming their commitment to RPM, as if there was nothing wrong with it, and no way to improve on it. It looks to me like these people are in serious denial, and living in some kind of cloud cuckoo land divorced from reality.
I also never ceased to be amazed at how what seems on the surface to be a very simple issue – e.g. copying software from one medium to another, has to be so complex and error prone.
For example, why not simply install ALL the damn libraries ever written off the DVD onto the hard disk during installation of the distro. The HD’s are easily big enough to handle this. Then a utlity could be provided that could prune all files not yet referenced. You could run this after the system has been in use for a year and fully configured, and it could archive off all unused libraries.
I would much rather be faced with the problem of wasted disk space than applications that wont run. With 250 Gig hard disks selling here in Australia for A$125, who cares about wasted space?
Im still looking for the distro that installs a fully useable system up front, playing DVD’s, 3D drivers, firmware blobs, etc, all out of the box.
One day it will happen, the only question is will I still be alive to see it?
Pingback: osViews | osOpinion
Well you are using something from SUN.
If you use linux use 0 corporate software. SUN wants you to use solaris, not linux, in a clear conflict of interest. JAVA is the same way.
Use really free tools either gpl or bsd licensed, then you will not have paid engineers secretly fighting you.
JAVA studio creator LOL!!
Isn’t it his/her free choice to use Java Studio Creator ???
Sometimes it is really funny to hear these “freedom” talkers. But don’t you use something from Sun. Really LOL
Those of you who believe people are the problem because they’re not willing to change should stuff a sock in it. People want things to just work and will not change if they don’t want to. And they should not always be forced to. MS catered to this and I’ll give them props for it. Deny it if you will, but Windows IS the reason why pretty much anyone can and does own a computer today. Now it is time for desktop Linux to steal those people away and the only way to do that is to make it as easy to use as Windows is.
If you disagree with that, then you’re only hindering the efforts of those who agree. If I want to use a new application on Windows, I simply download it, double click the installer, perhaps a few personalized options, and a few short minutes later (if that in some cases) I’m running that application. Can I say the same with many distros I’ve tried? Absolutely not.
Then you sit here and chirp about how having to make a file executable by chmod’ing it is a “security” precaution. Give me a break. In a properly designed Linux system, a virus can’t hurt the system (maybe just the user-specific stuff) when you are running as a user as you should be. If you want to blame MS for anything, blame them for designing Windows wrong from the ground up where security it concerned, not for making it easy for people to use new apps on their operating system.
Like it or not, Linux is going to have to rip a few pages from commercial vendors’ books and start doing these things if it’s ever going to gain a significant foothold in the consumer market. Saying that people are the problem because they aren’t willing to change is the same as telling a paying customer that they have to change in order to do something. Customers don’t like that when they are shelling out the cash. Perhaps you should start considering the user community at large more like customers instead of saying they are the problem because they aren’t like you and as willing to change.
And as many FOSS advocates so poignantly remind people constantly, isn’t that their CHOICE?
@RobK
“Another option is to use the packaging approach used in Mac OS X and also in GoboLinux. The binary and ALL the required libraries are packged typically into one directory.”
Right, I agree. Except that this is not quite “another” approach from what above mentioned klik does. It is, in essence, the same — with an additional twist: instead of putting “everything in one single AppDir directory”, klik puts “everything into one single file”. [Where the single file typically is a cramfs-compressed archive of the mentioned AppDir…]
This approach gains several additional benefits over simple AppDirs:
Saves space. Typically you’d need 35 harddisk units instead of 100. (And doesn’t cost any noticeable CPU overhead to uncompress into RAM for running it…)
Makes relocation to different medium more easy, and faster. (Copy only a single file.)
Makes removal of the application more easy, and faster (Delete only a single file.)
Preserves compatibility to the AppDir. (Expand the klik cramfs and you get… a compliant AppDir.)
Pingback: Ian Murdock’s Weblog » Blog Archive » Software installation on Linux: Tomorrow, it’ll be better (with some cooperation) (part 2)
Pingback: /home/liquidat Ian Murdock about Software Installation on Linux «
I agree with the original article. This is a barrier to Windows users adopting Linux. Period.
That said, there are ways to make it better. If you want to see how smooth it SHOULD be for an end user to install software on Linux (commercial or open source), take a look at what My Game Company did with the Linux installer for their recent commercial game “Dirk Dashing: Secret Agent”. It uses Bitrock, along with some custom scripts for installing menu items into the System menu on LSB-compliant distros. You can install their game as root or as a regular user. There’s even an uninstaller. I’ve been able to successfully install this game on SUSE, Fedora, Ubuntu, Linspire, and Debian. From the Bitrock web site, Bitrock appears to be an ideal solution for both commercial and open source projects.
You can download the Dirk Dashing demo from http://www.dirkdashing.com – click on the Try It button, select the Linux version, and follow the install instructions. Beautiful!
A few years ago, when I built my first LFS system I wondered that how difficult to add a new “include prefix” to gnu c compiler (also started to compile a system into /linux… frefix). And I asked again and again that why are so many things are “hardwired”.
May I ask a stupid? question?
Why the linux kernel doesn’t contain a small string or variable about used prefixes (like path variable)? “/:/usr:/usr/local”
Paths would be searched on these prefixes; includes; locales; other data files…
We could add new prefixes to the list or remove one.
We could have more prefixes with any permissions for any purposes.
Martin,
The Zero Install web-site says for Klik:
Users can install software: Yes
Non-root install of system: No
This agrees with what you said, no?
Presumably fuse, plash and/or ROX application directories could remove this limitation of Klik.
However, Klik isn’t decentralised (there can’t be two different klik packages in the world both called ‘convert’ for example, and if the central server is down then nothing can be installed anywhere in the world).
@Thomas Leonard:
The klik web service (just like most web services) isn’t decentralized yet, but of course everyone can make his/her private cmg files available.
Also, a non-root user can unpack a cmg file, and hence can use klik without ever being root (no fstab entries or other tricks required for unpacking a cmg
Simon,
I’ve updated the page – thanks. I assumed it needed root because it asks for the root password when you run the installation script, but of course there’s no real reason why that should be necessary.
Pingback: MonkeyToast.net » Blog Archive » Ian Murdock’s Weblog » Blog Archive » Software installation on Linux: Today, it sucks (part 1)
Permafrost91 has got it backwards.
But first, let me say that I hate Microsoft as much as he seems to; really truly I do, for all their evil business practices and the narrow-mindedness of their ‘community’.
BUT….
The one thing they have one right is the concept of intallers. They have created both the expectation and the possibility that someone can install something without having to endlessly twiddle stuff, and it just works at that point.
Never mind that most of their products are mediocre. Bear in mind that the mediocrity is often related to too much complexity and dependencies, but still they have managed to promulgate and realize the idea that things can be installed without requiring deep knowledge of internals.
This is as it should be.
Those who apparently pride themselves on their ability to navigate the arcana of installing Linux and Linux apps completely miss the point. Btw, I have been programming for 40 years on everything from IBM 360 assebmler to Java and PHP and a lot inbetween, including Unix device drivers. But I don’t measure my self worth based on knowing some minutia that will change tomorrow.
Ian has the right attitude: the Linux community needs to get this right if it wants to see mainstread adoption.