Linux Descending into DLL Hell?

meldroc writes "Or should I call it "Shared Library Hell"? The top story of LWN.net this week states that the newest version of GnuCash requires sixty libraries(!), many of which are new versions that aren't available out of the box with most Linux distributions. Managing shared libraries, with all their interdependencies and compatibility problems, is a major hassle. How should we go about dealing with the multitudes of shared libraries without driving ourselves mad or descending into the DLL Hell that makes Windows machines so unreliable?" Well, GnuCash 1.4.1 works fine for me, and I feel no immediate need to update to 1.6, the version that needs 60 libraries. But still a good point here.

Comments

Re:Difference from Windows...

[Anonymous Coward]

Wrong - you're talking about COM interfaces. Look up "COM" and "DLL" to see what is being discussed here. If MS had in general followed the versioning requirements of COM, perhaps there wouldn't have been a DLL hell. As someone else pointed out, MS merrily changed the entry points of DLL's (note: not the same as a COM interface), which was simply stupid. It caused unimaginable pain for users and installations. Nothing to do with COM and GUID's.

Relax.

[Sludge]

The software requirements require "60 libraries" because "The majority of the GNUCash 1.6.0 dependancies are satisfied by Gnome 1.4".

If major distros don't yet support the libraries of recent software releases, that's fine with me. The push for newer versions should come from bleeding edge software.

Aside from that, I personally commend the code reuse of GNUCash. Functionality needs to be reused as much as possible: We're working alongside giants. Let's stand on each other's shoulders.

\\\ SLUDGE

Re:Relax.

[MROD]

The problem here is that you're looking at things from a purely Linux-centric viewpoint.

The other week I had a go at building and installing GNOME under Solaris so as to get a certain piece of scientific software running on our Sun Solaris systems (which range from versions 2.6 to 8).

I first went to the GNOME site and downloaded the libraries the web pages told me I needed.. plus everything else fromt he stable directory. I thought that as I'd read the instructions and downloaded all of the stable source I would be home and dry, it'd just need a lot of configure, build and install cycles.

Little did I know that most of the libraries in the "stable" branch required a multitude of libraries fromt eh unstable one, many of which didn't play well in the configure scripts (they assumed that /bin/sh == bash and a few other Linux-centric assumptions).

Basically, after a week of trying to build things, finding I needed yet another library or utility from an unstable branch or from an obscure web site somewhere I managed to build enough of the core libraries to build the application.

And before anyone says "Why didn't you download a binary version?" I did look into this but the version on SunFreeware was disgned as a single machine installation, not a network wide one. The recently released Sun beta release version of GNOME 1.4 is only for Soalris 8 AND half the libraries needed by the scientific application were newer than in the GNOME 1.4 "release."

If the library API's aren't standardised soon and kept stable then people will shun such things as GNOME. For someone tinkering on their own system it may be fine to play for weeks getting things working, but in the "real world" this is just untenable.

Re:Relax.

[BlowCat]

Don't just complain on Slashdot. Send patches to the developers. Many developers don't have Solaris or other commercial UNIX to test their software. What is obvious to you is not always obvious to them. Help yourself. Educate developers. Next time they will think before starting a script with #!/bin/bash. An hour spent by you on bugreports will save an hour to thousands users of your OS.

Don't Confuse DLL Hell with the Linux Situation

[Mihg]

Linux isn't experiencing anything remotely similar to DLL Hell.

DLL Hell is when Foo DLL 1.0 and Foo DLL 6.0 both stored in the file foo.dll (unlike libfoo.so.1.0 and libfoo.so.6.0) and brain damaged installer programs blindly replace foo.dll version 6.0 with foo.dll version 1.0, thus breaking every single program that depends on the newer version of foo.dll

Because so many of these crappy programs exist, Microsoft has made an attempt at fixing the problem by introducing the Critical Files Protection mechanism, in which the operating system itself monitors file creations and modifications, looking for these stupid installers as they attempt to replace the new versions with the old versions of the libraries. Attempts at change silently fail, and the installer runs along its merry course without breaking things too badly.

Difference from Windows...

[buysse]

The major reason we refer to it as dll hell on Windows is very simple -- there's no concept of a version. App A uses v6 of foo.dll, app B uses v8. It's still named foo.dll. Oops -- the API changed. Hell.

Unix systems have the concept of a version -- you change the API, you rev the major version of the library. The old one's still there if you need it, but apps will get (dynamically) linked against the version of the library they were originally linked against.

Yeah, it's a bitch (and a half) to compile all that shit -- I've compiled Gnome (and all dependencies of it) on a Solaris box from sources. It's a pain in the ass. But, as Bruce Perens said in another post, that's the job of the packager -- Ximian, RedHat, the Debian volunteers (thanks.)

Re:Difference from Windows...

[rpk]

I've got some experience with this issue, having had to make different versions of DLL from the same vender coexist, and perhaps some of you Linux whippersnappers will learn something. Windows DLLs can be used in a upward compatible manner; it's just that it's hard for most people to understand the issues of DLL compatibility.

When we're talking about DLL hell, the first thing to keep in mind is that usually we are talking about incompatible changes in behavior or interface in libraries that are *meant* to be shared. Once a software designer decides to expose an interface, he becomes hostage to his installed base. Effectively, as others have pointed out, the name of the DLL becomes its interface identifier. So by convention you should encode the lowest compatible revision number of the interface in the DLL name. You can keep the name the same as long as you are binary-compatible, not matter how much the implementation changes. For example, MFC didn't change much from version 4.2, so when Microsoft came out with MFC 5.0, the names of the DLLs didn't change from MFC42*.DLL because they were still binary compatible.

If you need to share some state even between different versions of the same facility (like a list of file handles for different versions of libc), you are going to have to factor the internal state into yet another interface -- and that one that better be evolvable for a very long time.

The sad fact of the matter is that maintaining binary compatibility is hard, because there are technical details to master, and because of the discipline required to keep all potential clients working without have to rebuild and relink. You can't change the names or signatures of functions, you can't change the layouts or sizes of structures or classes, and older bugs that clients rely on as features will become features that have to be supported. If it's a C++ interface, you can't add virtual functions to base classes, although you can add new nonvirtual class functions. Of course, you can add new functions. It is also possible to "version" structures for expandibility, but this is tricky.

By the way, while static linking is a way around some DLL problems, one of the cases in which it can't work is when a DLL implements in interface to functionality that requires shared state in the same address space. You can have multiple clients of a DLL in the same address space when both and application and its extension libraries refer to that DLL. This happens a lot with ActiveX controls on Windows (and in-process COM servers in general), and I suspect that this also happens in Apache on Unix as well.

Both Windows XP and Mac OS X have mechanisms for allow shared libraries to be hived off so that you can have private version for yourself, but I don't know much about how they work.

Note that shared Java classes are much easier to deal with, but isn't like there are no interface changes have binary compatibility implications.

The other way around this problem is to expose the interfaces(s) in a language-neutral object model that supports interface evolvability, such as [XP]COM or CORBA. Unfortunately, it's not always easy to use these kinds of interfaces, and most of these kinds of systems don't offer implementation inheritance (with the notable exception of .NET, which is Windows-only currently and also requires language extensions), which is a handy feature of a C++ class exposed in a DLL.

Re:Difference from Windows...

[CharlieG]

Doesn't work in windows, and I've been telling developers this for years.

First, some background - I'm a windows developer, and have been since Windows 3.0 (programming for a living since 82), and I even played around with development before that

Windows, when looking for a NON OLE DLL, first looks in MEMORY, then in the local application directory, then the Windir, Then Winsysdir, then apppath. When loading an OLE type DLL (as most are today), it looks where the REGISTERED version is, and ignores all other copies on your system

Putting the NON OLE DLL in your applications directory works fine, IF you ONLY run that one app at a time. What happens if you run the app the uses the OLD version of the DLL FIRST, then load the second app at the same time - RIGHT the dll is already in memory

What is supposed to be done, and I've spent years yelling at some of my co workers is this

YOU NEVER BREAK BACKWARDS COMPATABILITY WITHOUT RENAMING the DLL. It will bite you in the ass. Your install program should NEVER overwrite a newer version of a DLL with an older version.

The BIG problems are the following
1)Developers writing non backwards compatible DLLS - Crystal Reports is famous for this. CTRL3D32 is also a example
2)MANY companies thing that running install programs is too much work, because their in house developers come out with "The Version Of The Day", so they use batch files to overwrite DLLs/programs without checking versions or what is in the registry

Folks, MSFT has said "Don't Do That" for years. Unfortunately, they don't prevent you from doing this. That is why XP is supposed to (last I heard) load a different copy of the DLL for each application - then the idea of "DLL in the application directory" works great - The .NET project is also supposed to fix this - we'll see.

Shared libs will cause this same descent into hell if we're not careful to prevent this problem. The answer is NOT "Make sure you install the latest RPMs (debs)" assuming that they will be backwards compatible - this WILL fail. It's the same answer Microsoft took - "If you do it right, it works". The problem is, when you become the OS that sits everywhere, people WILL do it work, and then complain

Why doesn't Linux adopt a Mac OS X type scheme?

[VanL]

One of the most interesting features I read about in Mac OS X was the way in which they distributed binaries. They have a "package" that appears as one binary object, but it acts (for the loader and linker, I presume) like a directory. Inside are stored versioned libraries.

Couldn't something like this be done to reduce the clutter? Have "gnome-libs.pkg" which is actually a tar or tgz file. When an application needed to use a library, it would involve an extra step -- extracting it from the tarfile -- but that would only be on first load (after that it would be cached in swap) and the cost to retrieve the file would be minimal.

On the other hand, the possible gains would be enormous. Packaging would become simple. For most applications, install/uninstall could simply be putting the binary in bin and the libpkg in /usr/lib.

I guess what I'm thinking of is like GNU stow, just taken further. Why not make those directories into tarfiles?

Want to make $$$$ really quick? It's easy:
1. Hold down the Shift key.

Re:Welcome to Windows?

[PD]

You forget the other part of the equation.

On Windows, the libs are called Dynamic Linked Libraries. On UNIX, they are called SHARED libraries. Of course, we all know they are the same thing, but apparently on Windows many people don't understand their purpose.

Part of the DLL hell is the vast amount of them that are unnecessarily created by people who don't understand when static linking will work just fine. I still hear people claim that DLL's magically keep the executable size small. DUH! All it does is unnecessarily chunk up your program, increase file count, and increase loading time.

So far under Linux I have hardly seen any abuses of this. Shared libraries are generally reserved for geniunely sharable code, and the rest is statically linked the way it should be.

It sounds like GNU Cash is using shared libs correctly and once the distros catch up we'll wonder what the fuss was about.

Helping the community?

[jsled]

Hmmm... 2 or 3 GnuCash developers independently post story submissions to /. about how they've released a significant new version of a key Linux application ... one which has the potential to replace some people's last hurdle for switching away from Micros~1 completely...

And /. decides to reject all those, and instead posts a poor LWN piece which overstates a problem that is valid, but has nothing to do with GnuCash, and more about the poor state of Linux software installation, package management and impatience of users regarding the package system they're using.

Thanks Slashdot story selectors! The GnuCash folks did their part and wrote a bunch of code that works really well... ignore it if you must, but don't piss on their efforts.

Re:Is it really necessary..

[ethereal]

It's never necessary, unless of course you want one of the cool new features in that library. It doesn't take too many active developers before you're pulling in a lot of new technology and thus a lot of new library dependencies.

For most people this won't be a problem since their distro will figure it out, and for everybody else that's trying to install RPMs or build from source, take a look at the mailing list archives on gnucash.org. If gnucash didn't use brand-new tools like Guppi and Gnome 1.4 libs, much of the cool new stuff in gnucash 1.6 wouldn't be there.

It's not really DLL hell, since you can have multiple copies of the same library installed for use by different apps. DLL hell would be if gnucash blew away the libs that gnumeric needs, and then reinstalling gnumeric screwed up the libs that nautilus wants, etc.

Caution: contents may be quarrelsome and meticulous!

Solution: Mix Dynamic and Static

[GroundBounce]

One of the original reasons behind DLLs in the first place was to save redundant disk space and memory. This is still true, but when DLLs were first popularized on PCs by Windows 2.x (or whatever it was), most machines had a 20-30Mb hard drive and 1Mb of RAM.

Things have changed. While the larger, most common libraries (GTK, QT, glibc, X libs, gnome and kde libs) should remain dynamic, it would be helpful for binary packagers to statically link the smaller and more obscure libraries, especially if they are using a bleeding edge version that is not even in the most current distributions.

With a combination of static and dynamic linking, you'll achieve the majority of the benefit of shared libs because your largest and most common libs will be dynamic, but you'll be able to avoid much of the DLL hell and upgrade hell that accompanies packages that use bleeding edge libraries.

It's not DLL hell that makes Windows unreliable

[Katravax]

How should we go about dealing with the multitudes of shared libraries without driving ourselves mad or descending into the DLL Hell that makes Windows machines so unreliable?

DLL hell is a small part of the problems Windows faces, but most of the better programmers started putting their libraries either in their app directory or static linking... Most every app on my Windows machine can be uninstalled by deleting a directory. But don't blame Windows instability on DLL hell. DLL hell is just another symptom of the same thing that causes the instability.

What makes Windows boxes unstable, plain and simple, is faulty drivers and applications. Out of the box, the NT series has been rock-solid even since 1.0 (version 3.1). The Windox 9x series has also been way more reliable than it has the reputation for. Drivers provided directly by Microsoft have traditionally been very stable, even if not very feature-rich. The drivers provided by third-parties, however, tend to suck overall. I would estimated 50% of instability problems I see are related to VIDEO drivers.

The big thing people forget when they compare stability of Windows and other OSes is that in monolithic kernels, the drivers are provided by the guys that know the kernel, thus are typically more stable. I cannot say the same for many Windows drivers. In addition, something like a FreeBSD web server is hardly comparable to an end-user Windows machine, yet this is always the example held up by the anti-Windows crowd. Add MP3 software, graphics apps, kids' games, a crappy sound and video card, and all the other stuff people put on user machines and then see how stable the other OS is.

I'm not blind. I know that on the whole Windows boxes are not so stable. I'm a professional Windows developer. I can say from first-hand knowlege that the bulk of problems with Windows is due to lazy, unknowledgeable, or sometimes hurried and overtaxed programmers. It's a real problem. I also keep a FreeBSD boot around and I'm very pro-GNU/Linux and especially pro FreeBSD. But I program Windows as my work, and know that the instability blamed on Windows itself rarely has anything to do with code written by Microsoft.

Re:It's not DLL hell that makes Windows unreliable

[Katravax]

...There has never been a MDAC released by Microsoft that didn't crash windows? IE never crashed windows? MS-Office never crashed windows? Give me a break.

I was referring to a clean box, and said so clearly in my original post. There are plenty of sloppy coders working in the apps division of MS. The MDAC installs are among the most awful installs of anything available. No argument from me there.

If you can't expect Microsoft themselves to be able to write software that doesn't crash windows how do you expect your average VB programmer to?

I don't :). The average VB programmer is a beginner and doesn't know much more than drag-and-drop window building and basic event-handling. I'd guesstimate that fewer than 5% of VB programmers understand how Windows actually works. I'll also say that most VB apps can't crash Windows, either, because they don't have access to anything privileged.

The fact of the matter is that it's awfully difficult to write an app for windows that won't take down the system occationally. If for no other reason then you are using DLLs and you have no idea what's in them. How many apps depend on wininet.dll or the vb runtime or MSVCxxx Dlls?

Bullshit. I write system services and plenty of system-privilege apps that don't crash Windows. The *app* may crash until I get it finished, but that's not what you said. Anyone writing code that depends on wininet or the MSVC runtime and MFC dlls, frankly, is asking for what they get. But if you use the interfaces correctly, these don't crash Windows either. There are bugs in the common libraries to be sure, but that can be said for common Linux libraries as well, can't it? Of course the massive advantage with most Linux libraries is that the source is available. But my original post wasn't focused on the availablility of source.

You know I went to install the MS soap toolkit the other day and it insisted that I install IE5.5 and some service pack or another, then the rope.dll wouldn't register properly so I had to go download a later version and register it by hand. Just to be able to work with XML I had to download over thirty megabytes of stuff. So If I write an app using this toolkit is it my fault if the app crashes or is it possible that somewhere along that 30 megabytes of crap I installed on my machine something was broken?

Yep, it is your fault. All that shit is not necessary to work with XML. There are some reasonably good third-party libs that don't require all that crap. You apparently know as well as I do that developers using all that crap (besides the existence of that crap itself) are the cause of the problem. The most useful frame of mind I've found for writing Windows apps is "think small". Write with the fewest dependencies and libs possible. That pretty much leaves out developing in VB or using MFC, and avoiding the C runtime if possible. ATL is an excellent library, though, and there are some outstanding compilers out there if you prefer BASIC (check out http://www.powerbasic.com".

Re:It's not DLL hell that makes Windows unreliable

[imipak]

>(IE, as root, I can hose a Linux system, not
>matter how stable it is supposed to be).

(/me waving goodbye to the karma..)

Unless the admin has been paranoid / smart / had enough copious spare time to implement quotas, a generic user on a Red Hat Linux (and AFAIK, other distros) can crash the whole thing with a one-liner fork bomb. I know, I did it to a co-worker who was relentlessly (and ignorantly) trolling me about how flakey NT is vs the never-crashes, 200 day uptime, uber-secure Linux machine he was using as his w/s. A Rude thing to do, admittedly, but he doesn't go on about it quite so much now. And he couldn't find a way to do that to my NT machine... running BIND, dial-on-demand IP gateway & NAT, Apache w./ mod_proxy and mod-perl, local mail server, plus my generic workstation apps (mail, mozilla, emacs, cygwin apps etc) and currently has nearly 60 days' uptime. Nothing special there, I agree, but really NT isn't as bad as some of the zealots would like to believe...

Incidentally I'm only still on NT whilst I get an OpenBSD config working to provide the network services and get round to Bastillifying my Linux machine. And I'm lazy. And there aren't enough hours in the day...

Back on topic: I moved frrom RH6.1 to Mandrake 7 and lost Gnuchess & Xboard along the way. The grilf complained (she's (50%) Russian, so she really needs her chess practice ;) - "no problem" I chortled, "I'll just grab the source, config, make, make install..." HA! chess is > 20Mb as src. OK, I'll take an RPM. And then lib hell began... three days later I gave up and told her I couldn't do it. Perhaps I should give Debian another go... wtvr, RPM sucks.
--
"I'm not downloaded, I'm just loaded and down"

Re:You wanna talk hell... (not NeXT style)

[gutter]

Actually, NeXT didn't necessarily bundle all the packages inside the app, although some applications did. I never owned a NeXT box, but most of this works the same way in Mac OS X, which I do use.

Most shared libraries on NeXT/Mac OS X are installed as frameworks. These frameworks are basically directories with .framework suffix, like OpenGL.framework.

Each framework contains a folder called Versions - this folder contains all the installed versions of a framework, which includes shared libraries, the headers necessary to use them, and any other necessary resources. They are versioned with a major/minor numbering system - minor versions get bumped for compatible upgrades, and major versions get bumped for API changes and the like. Programs know what version they were linked against, so if you install a new, incompatible version, the program can still use the old version. This pretty much eliminates DLL hell - you can install new versions without breaking old stuff.

Apple's frameworks go in /System/Library/Frameworks, local frameworks go in /Library/Frameworks/, user-installed frameworks go in ~/Library/Frameworks, and application frameworks can go in the application bundle. I'm not really sure of the precedence though.

It's a really cool system, and makes a lot of sense. Unfortunately, there seems to be a trend in Apple to install many unix shared libraries the regular way instead of as frameworks, to increase compatibility - makes many more things 'just compile'. I'd be much happier if more unix systems went to frameworks instead.

Re:Libraries: Harken to the Bad Old Days

[dbarclay10]

then the next will really floor you -- applications will keep their own .DLL's in their own application directories. Just like in the DOS days, you will be able to blow an app completely off your machine by deleting its directory, and version differences will become irrelevant.

Well, no a bad idea totally. It'd help for DLL-hell type problems, but let's raise a few points:

1) Firstly, decent packaging makes DLL-hell much less likely. I use the experimental variant of Debian, and even then, there are rarely library dependancy problems. The problems that do arise are usually easily fixable, as opposed to most of the DLL-hell problems that Windows has(ie: two applications requiring incompatible versions of the same library).
2) Secondly, Linux(as a *nix variant) allows one to have multiple library versions installed at the same time, without trouble. That was one of the design considerations.
3) Security. The main reason for shared libraries isn't space-saving(as you imply), but rather security and stability. The FooBar application relies on library Wingbat. So does app YooHoo. Now, the Wingbat library has a security hole that was just found. Oops! Well, a patch is released, packages are made and sent out. You upgrade(or your computer does it automatically), and poof - all of a sudden, YooHoo, FooBar, and all the other apps that use the Wingbat library are more secure. Ditto with stability. The Wingbat library has a nasty bug which causes crashes. Okay, a fix is made, packages are installed, and now neither the YooHoo nor the FooBar apps are susceptible to that particular bug.

Anyways, I just wanted to say that the main reasons for shared libraries isn't really the space issue. Nor is it a performance thing. It's a quality thing.

Barclay family motto:
Aut agere aut mori.
(Either action or death.)

Hehe

[Jailbrekr]

I'll bet the MS developers are rubbing their handing, and giggling gleefully right now. "Oh yes, now they understand, now they UNDERSTAND!"

The solution is old news

[Arker]

Unix solved the problems that constitute true ".dll hell" ages ago, and linux uses the solution. It's not the systems fault that some writer doesn't understand what he's talking about.

If you want to use the new gnucash, you need the libraries it relies on (or a statically compiled version, which may be a workable alternative for a short time but is really an inferior solution in the long run.) This does not constitute .dll hell at all. Dll hell is when two applications on a windows machine require different versions of a shared library. Only one will work, and that is a problem. But on a *nix machine, there is a little something called library versioning that eliminates that problem entirely. Installing the newer libraries gnucash needs will not cause other applications to quit functioning. No .dll hell. Just another misleading slashdot headline.

"That old saw about the early bird just goes to show that the worm should have stayed in bed."

This is why 'Stable' distributions exist

[big.ears]

From what I understand, one of the primary reasons for having two or three levels of distribution is to avoid this dependency hell. In debian, e.g., everything in Stable (should) play nice together, but the newer stuff is more likely to break other stuff. This means that a lot of the stable stuff is a year or more old, and because of Linux's nascent status, this means that if you want to get something that is usable, you have to deal with conflicts.

I think this is one of the primary hurdles facing Linux's wider adoption. Nobody wants to mess with upgrading/downgrading libraries, and you rarely have to do that stuff in Windows. For example, I have never been able to get the newest versions of galeon, mozilla, and nautilus installed and working at the same time. And, perhaps unrelated, gnumeric and netscape 4.7 no longer work. Of course, its not impossible to fix, and I'm not trying to sound like I'm whining, but I don't know to many of my friends who are Windows power users & programmers who would put up this stuff.

Hopefully things will improve when libraries become more stable, and apps move into versions 1, 2, 3, and higher. Then, release cycles should get longer and less drastic, and everything should be easier to use together.

Responsability is the key

[alriddoch]

Using libraries to add functionality to applications is essential. There can be little doubt here. It is easier, more robust, and better practice to use the standard implementation library for a piece of functionality than to attempt to re-write that functionality for yourself. However there are some important basic principles that must be understood when writing application to use, and more particularly developing shared libs.

In development of any code project, there will be times when the codes design is undergoing rapid change. In the case of a library this means that the API will be constantly changing. In a closed source environment this does not cause too many problems because noone ever sees this code. In a cooperative Free Software project, the source to a library is always available, so there is a temptation for the application developer to use a development version of a library to get a certain feature. This is the beginning of the road to hell. It is essential that applications never have stable releases that depend on development libraries. I remember some years ago when gtk+ 1.1 was being developed towards 1.2, and many application developers were chasing the development branch because they wanted the features it had. The result was chaos. It became nearly impossible to install many combinations of gtk+ applications because they all required different versions.

On the library development side there is a need for a great deal of responsibility. Library developers need to learn about, and really understand library interface versioning. The interface version of a library is completely different from the release version number, and it is used by the runtime linker to ensure that it is safe to link a binary to library at runtime. With properlly managed interface versions it is quite possible to have many different incompatable versions of a library installed and available for runtime linking. GNU libtool has some excellent support for library interface versioning, and the libtool documentation contains some excellent documentation on how to correctly assign interface version numbers to a release.

Large numbers of libraries can be managed effectively, and cleanly as long as these principles are understood by both library and application developers, and good practice is followed.

Installing Free Software

[Tachys]

It always seems to me that Free Software could get an edge with ease of installation.

Installing propertary software requires putting in a serial number and then install some updates.

But with Free Software I can always get the latest version, and no need for serial numbers.

But installing apps on Linux more difficult then Windows.

When I want to install something what shoud happen is

I download it tar file.

I double-click on it to uncompress it.

This shows a Gnucash folder.

It's installed!

I can go in the folder and open Gnucash.

I can then move that folder where I want it.

Why can't Linux do this?

Windows and Linux Hell

[Bastard0]

When I think of Linux applications I think of lean mean server side programs with no fluff. No paperclips popping up to tell me what to do just a few text based config files and raw power. That's how I like it. When I think of Windows I think of powerful feature rich desktop applications (Quicken, Word, Cubase). The interesting thing is that as Linux is beginning to tread into the desktop arena its starting to face some of the same problems that Windows has gotten a lot of flack for. As you add features you add complexity and increase the size of the code and increase risk of some kind of flaw or failure. Windows is more bloated/unstable/convoluted because it has so many features. Just look a GNOME. That thing is a true monster which looks like its just going to continue to grow. Frankly I haven't seen one desktop application / user enviornment (including GNOME) on Linux that isn't 10 years behind a comparable application on Windows. Don't get me wrong I love linux I just don't see a point putting it on my desktop.