To read all comments associated with this story, please click here.
checkinstall
http://asic-linux.com.mx/~izto/checkinstall/
And if your app of choice is not available in your distribution's native format?
Then, for the novice user, it simply doesn't exist, and they've probably never heard of it anyway. On Windows, if there's an application that doesn't have an installer, then it's pretty inaccessible to all but the most experienced users. On Linux, if an application doesn't have a package for you distro, then there are usually instructions that allow moderately experienced users to install it manually.
More pertinent to the topic of TFA is that Linux systems have unified interfaces for installing software. The process of installing and updating software is the same no matter what package you're installing. While Windows installers are undoubtedly simple to use, there are as many flavors of installers as there are major Linux distros. The uninstallers often don't work correctly, and there is no simple way of receiving automatic updates to application software.
The issue of package availability gets raised here often (frequently by you, Thom), and I think the fundamental response is that this isn't a technical issue, but rather one of economics. It's far, far easier to package software for a Linux distribution than it is to package software for Windows, and the installation method is arguably far, far more convenient. From a technical standpoint, the Linux distributions are beating the pants off of Windows in software packaging, more or less out of necessity. The amount of software available for Linux distributions is staggering given the market share story. For a niche market, the Linux desktop early-adopter crowd has been remarkably well-served by the Linux distribution projects. If the burden was on the upstream developer to ensure platform binary compatibility and desktop integration, then we wouldn't be where we are today.
Then you have to go with FreeBSD, you will like the about 17.000 ports, ready to install and solving dependencies
Apart from that, look at Mac OS X, it hasn't got the vast variety of applications like in Windows world. Are Mac OS users doomed now?
>Here we are exposing one of the fundamental problems of Linux systems. It's all about ego.
Isn't this a very bewildering saying out of the mouth of a Mac user? omg
Apple sells dreams, dreams with no connection to reality - you have to have faith, faith in Jobs. So if you're professional you have to go with Windows or real Unices.
Screwdrivers vs. Couture
This is the real problem, the latter is Apple.
The problem is that the application managers DO NOT always look after them for you. Things break, and the graphical tools to manage them don't always do the right thing. And what about apps that you can't get via apt-get or yum, which you have to install manually? What then? Besides, the thrust is about keeping application files and config data organized better. Linux has some standard on where to keep the main binary and where to keep the main config file. But as for other application data, that is done haphazzardly. And of course, the config file thing is a MUCH bigger hassle than where the binaries are kept, because I have to agree that the package managers at least USUALLY handle the app binaries right.
I've never ever had a problem with applications not finding their associated data, which is usually installed in /usr/share or /usr/lib. The only problems I ever have with package managers are with superficial library conflicts. For example, an application is looking for libexif.so.10, but I have libexif.so.12. So I do ln -s libexif.so.12 libexif.so.10. Problem solved. I've thought about writing an enhancement to the Linux loader that attempts to make symlinks like this if an exec() fails on a missing shared library object. When I get the time, I might investigate this further.
> And as for this "application files should be in one place" thing, I have one question: Why?
> In Linux, the package manager will look after them for you.
I think package managers exist mainly because of this limitation, not as a feature. As an application developer, do you know how difficult it is to get your application packaged for every distro and OS? People and newcomers are encouraged so much to use packages, and then us, developers, have no control about which distro will provide packages,and need to rely on the help of others. It is also impossible to release beta software for testing, because a) If it isnt finished yet, it wont be packaged , b) If it's a beta/unstable version, the package will override the stable version (it's difficult as shit to install both an unstable but with more features and a stable but older version of the software at the same time).
So come on, packages are not really better than the windows/osx/beos approach.
klik
http://klik.atekon.de/
It might not be the be all end all solution to linux package management woes, but it's perfect for releasing beta versions and brand new stuff.
"Is this an excuse to scatter files over /usr, /usr/local, /usr/local/etc, /opt, /var/opt, /etc directories?"
To clarify, just read
% man hier
Installed applications that do not belong to the OS itself are installed in /usr/local. The directory /usr/X11R6 should be obsoleted, I heared some rumor about this dir getting obsoleted soon. Linux had /opt aditionally, nearly the same, but I think it's obsoleted, too.
/etc does hold configuration files for the system, /usr/local/etc does hold configuration files for installed programs. So you can easily see: While /usr/local/-foo- is -foo- for installed applications, -foo- outside /usr/local has the same purpose, but just for the system itself.
It's not that confusing as it might look to you.
Is this an excuse to scatter files over /usr, /usr/local, /usr/local/etc, /opt, /var/opt, /etc directories?
My system does not have a /usr/local/etc/ or /var/opt/ directory. Additionally my /usr/local/ is for distro specific stuff and there are no libraries in /usr/local/lib/. When I install something it generally goes into /usr/ unless it is a binary package in which case it gets installed into /opt/. My configurations files are stored in /etc/. That's not so hard or complicated now is it?
I think the article mentions quite a few times to drop your ego. Why not try to see what benefit linux can get from adopting other approaches than simply saying "well windows screws up this way or that way..." If anything, the article is talking about Apple's success.
No, Windows doesn't handle install/uninstall well. However, the basic idea of a central location for an application is a good intuitive one. That's where MS has been heading...but of course they're held back by compatibility issues. The same goes for program settings. Apple learned from Microsoft and Linux and took the most reasonable path. Standard, but separate files.
"In Linux, the package manager will look after them for you." Yes, and in windows the registry will look after your all your settings <sarcasm>. Sometimes things don't work. Sometimes you install stuff outside the package manager. Sometimes I like to just like explore settings and replacing files. Developers like intuition too.
Intuitive UIs are absolutely needed. It's not so much about consistency as it is about intuitiveness. For example, I recently installed Ubuntu on my laptop. I see the 'start menu' and I start to explore all the programs. Now I want to edit this menu. I right click an item to remove it...Nothing happens WTH. Why is this menu not responding to my right clicks. Oh, I have to go to a special program to edit the menu. Needless to stay, Kubuntu took over quite shortly.
Yes, all the Windows apps are rarely consistent, but they are largely intuitive. Consider MSN messenger. Everything is fairly intuitive with the exception of changing your display name (Why can't u click and edit it and you can with your personal message text? )
> In Linux, the package manager will look after them for you.
In most cases, you do not even need a package manager in Mac OS X (or earlier versions of Mac OS for that matter).
Now when you create a program, you are doing so to solve a problem. That problem may include anything from "how can I entertain people," to "how do I make system management easier." The fact that most Linux applications need an installer while most Macintosh applications don't need an installer implies that software installation is a problem on Linux, while it is not a problem on the Macintosh.
EDIT: reduced to one key point.
Edited 2007-03-30 22:42
"The fact that most Linux applications need an installer while most Macintosh applications don't need an installer implies that software installation is a problem on Linux"
Huh...most Linux apps do *not* require an installer, they are handled by the package manager.
If you want to use the OSX method on Linux, you can, it's called Klik.
I would say there is potential in applying uniformity beyond applications. Have you ever tried to compile something and configure tells you that you're missing a library or a header? Maybe you 'find -name' your drive first, or maybe you just go to the internet right away and google it; but then it turns out the library was already there, but not within your $PATH? Or, maybe you have two different versions of some software installed in different locations and configure does not recognize the newer version? Experienced users will know how problem, but newer users will probably be mystified.
On package managers - if you use the package manager for some things and compile others by source the manager is usually not aware of your various outside installations. Potentially, we could hope, a simplified tree might make it easier for managers to identify installed software and react accordingly.
You mentioned your path... Novice users of linux will not understand $PATH immediately, and thus theirs may not be as inclusive as your $PATH. A simplified structure could essentially end the need for a PATH variable as there would only be one place to look normally (except where you have a specialized set up that necessitates a modified directory structure).
Macs are pleasant because they simplified those things. The directory structure may not be perfectly POSIX compliant or what have you, but that structure is more readily comprehended. Furthermore, simplified structure might make things easier for both user and developer when there are predictable locations for essential files.
In Windows, you have to be able to get at them, because Windows totally fails at providing any sort of install/uninstall framework, so stuff gets left all through your system that you have to clean up yourself. Or something decides to save it's data under it's Program Files folder, so you need to find it to back it up.
Your comment is quite dated. Ever heard of Windows Installer?
A WI routine can be incredibly powerful, and can handle scenarios that neither Linux or MacOS have yet! For example: Install on Demand, Advanced patch management (with uninstall support), per-user or per-machine installations, Distribution to specific users/groups over Active Directory, Reliable and complete uninstallations, Advertised shortcuts etc. etc.






Member since:
2005-07-23
And as for this "application files should be in one place" thing, I have one question: Why?
In Linux, the package manager will look after them for you. I can't remember the last time I went trawling through /usr looking for some obscure app file - why would I need to?
In Windows, you have to be able to get at them, because Windows totally fails at providing any sort of install/uninstall framework, so stuff gets left all through your system that you have to clean up yourself. Or something decides to save it's data under it's Program Files folder, so you need to find it to back it up.
This also leaves apps to decide where they put things like executables. So when you get the "Open With" dialog, and the app you want isn't on the list, you have to go searching through Program Files. Wouldn't be so bad, but last time I did this I was trying to open a VS7 project in VS8. Where does VS8 keep it's main executable? Obviously it's under it's Program Files folder _somewhere_, but nowhere totally obvious. In the end I abandoned it and opened the file from inside VS, but there was still this niggling doubt saying "on my linux box I wouldn't have had to know, it would have been in the path. easy."