Slashdot Mirror
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.
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.
But, really, this breaks down under certain usage patterns. On a system like Debian, where package installation is trivial compared to Windows, there are a ton of packages. I currently have 694 packages installed, though a significant number of them are libraries.
Consider another pattern -- extended environments. Gnome is an instance, as is KDE. I have 12 Python packages installed, and Python by itself doesn't even do anything. I won't speculate on how large Gnome or KDE are.
I have 41 gnome packages installed (or, at least packages named gnome*). What would happen if I had 41 copies of the Gnome libraries for these applications? What if packages had even greater granularity? What if I get to choose which applets I want installed? What GTK engines I want? Hell, I don't even know how engines could work with 41 copies of the libraries.
Sym linking identicle libraries to save space wouldn't do any good, because that offers nothing better than what I have now (which works just fine, actually) -- where most libraries end up in /usr/lib. In a funny way, I suppose hard links would almost work right.
On Windows per-application DLLs kind of make sense. On Windows, people don't have that many applications installed. Each application tends to do a lot on its own. This is partially the influence of commercial tendencies (people don't want to pay for something too small), and partially it's because small applications quickly become unmanagable on Windows. But Debian doesn't have this problem, and RPM-based systems have, well, not too much of this problem. Why "fix" what isn't broken?
Next you'll have us putting application files in directories named after domain names or company names, to avoid naming conflicts. /usr/applications/org/gnu/gnucash. Uh huh.
I agree that code reuse causes bloated software in that libraries often are required to deal with a very general case of the problem, which requires much more time than just coding an example by yourself.
However, I can prove that code reuse isn't always bloat: the ANSI C library on your system. If the ANSI C library was statically linked, there wouldn't be any shared memory redgarding it between your processes. When you run 'top' and a process says it takes up a few more megabytes than you thought it would, be sure to check the shared column.
Saying that code reuse causes bloat is not the whole story. Code reuse serves both sides of the bloat war.
\\\ 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
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.
I now virtually nothing about MS Windows and MS's plans for it, but I do remember the commotion here on /. a year or so ago when MS patented "a new OS feature", basically automatic links. You can have as many copies of same file on disk as you want, without using more space than one file. When an application wants to change a file, the link is substituted with a real file.
Managing DLL:s was the purpose of this "invention".
Lars
__
Reality or nothing.
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.)
-30-
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
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.
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.
If tits were wings it'd be flying around.
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.
Ok that's fine and dandy, but the gnucash developers refuse to release statically built binaries so that the 90% of the world that would try to use it can. I was grinning from ear to ear when ximian came out and I was able to help several windows only friends make the crossover to linux.. Now I have to tell them NOT to upgrade their most used software (like gnucash) because the developers would rather them not have it, or I have to start a linux babysitting group and build everything for everyone... Sorry, it's crap like this that makes the job really hard for us advocates out on the front line getting linux in the faces and on the desks of normal users.
If you release a version that uses all kinds of new libraries, take 3 more seconds and release a statically linked version so you don't undo every success the advocates have achieved...
I ran into this gnucash problem 3 days ago, and now I need to tell my small group of new linux users that the newest version is not for them and will probably never be for them. (getting linux there was hard enough, asking them to re-install to redhat 8.0-8.1-8.2-etc to satisfy the whims of programmers? no way.)
my suggestion? go ahead and use 925 libraries for your program, but if you expect people other than programmers anf gu-ru's to use it make a package that is 100% compatable with a current distribution -1 (I.E. subtract a decimal from the distribution release). Sorry to pick on gnucash directly but it is one of those apps that was able to switch windows users over, so they have more riding on their backs than they really know.
Do not look at laser with remaining good eye.
The Problem is actually differant in linux the simple dll incompatabilities, it's the lack of a aggreed standard.
For those just tuning in, linux has the concept of package managment, which doesn't really exist in windows, and intheory should solve the library problem.
In practice there are two competing standards, AKA debian DEB/APT (which works pretty well), and red hat RPM (which is a mess, and not trully automatic).
There are solutions that try to solve the probelms with RPM (mostly the lack of centralized QA on indevidual packages), like the distributions them selves (many, many, many distributions), but couse other problems with diferant distribution packages, (suse RPMs with red system are likly to have problems, etc).
Some other solution are surfacing, like Aduva's manager, which uses a central database as well as a client which analizes the usrs dependancies/interalations on his machine. But that solution is not Free software/gpl/OSS.
Another problam with these solution is that the typical Linux users are reluctant to use automatic systems on thier systems.
(I'm feeling genorous today)
--------------------------------
Tools like apt, Red Carpet, and the Apache Toolbox are doing a good job of handling this problem for me. I constantly run the newest versions of applications without any extra legwork.
Since the majority of Linux software comes in packages we'll never enter the DLL Hell in the way Windows has because you can always see where each file comes from and how they relate just by bothering to do some legwork.
Upgrading is no big hassle for the most part. Use something like one of the above mentioned tools to stay updated or if you must resort to a program that is none-standard try something like wget (or in many cases just plain old ftp) to suck all the needed files in.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
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!
Your right to not believe: Americans United for Separation of Church and
grab them here
Incidentally I think it's very worthwhile to upgrade to GnuCash 1.6.0. It's slick Play around with the reports for a few minutes and read the excellent documentation. The documentation gives an excellent summary of the principles behind handling your finances and covers the new features in 1.6.0.
Celebrate the finer things in life
The way around it is for people to use the lowest version number of GLIBC/libSVGA etc. rather than the latest we-are-the-dogs-bollox version shipping on Freshmeat. It never ceases to amaze me how the compilers of distros seem to go out of their way to make the latest version of the code incompatible with the stable version. Take RH6.x for example, when you were hard pushed to find any new software because it was all in V4.0 RPMs whether it needed the V4.0 features to be installed or not! That was only fixed by RH eventually releasing a V4 compatible RH6.x RPM.
:v)
Vik
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.
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.
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.
.framework suffix, like OpenGL.framework.
/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.
Most shared libraries on NeXT/Mac OS X are installed as frameworks. These frameworks are basically directories with
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
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.
Check out DRM-free movies at http://www.bside.com
But installing apps on Linux more difficult then Windows.
In some situations this might be a bad thing. But in a great many situations it is actually a good thing. Indeed there is a whole industry providing tools to make it difficult to install programs under Windows. On the vast majority of corporate systems you explicitally don't want end users installing apps any more than you want they customising their company cars or taking woodworking tools to their desks.
You can (mostly) under linux, if you're using the right distribution.
apt-get -y install gnucash; gnucash
Type that into any command prompt or whoknowswhat run dialog, and gnucash will automatically be installed and run. Oh, you have to be 'root' to do it, I'm sorry. Linux has this nice thing called 'permissions', so that you can't break anything unless you've logged in as root.
No need to show folders, or double-click anything, etc... Debian's Advanced Package Tool will automagically put an icon in Start->Programs->Applications->GNUCash, so it's even easier than what you're describing.
I'd love to spend some time wiring up a few scripts to "apt-cache search", "apt-cache show", and "apt-get install", with a nice GUI interface, so that it *would* be as easy as double-clicking. Ahhh... a project for another day.
--Robert
Not really. Windows programmers get paid to write code, and laziness in this sense means getting the project done quickly and out to market. We in the Linux community write software in our free time because we love it, and do not release things until they kick ass.
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.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
I'll bet the MS developers are rubbing their handing, and giggling gleefully right now. "Oh yes, now they understand, now they UNDERSTAND!"
Feed the need: Digitaladdiction.net
A better alternative is to load libraries by checksum instead of version number - the library's filename would be its checksum, which would be verified by the loader. If two apps were compiled against exactly the same version of a library they would share the same copy in memory, but if one was compiled against 0.8.1 and the other against (supposedly compatible) 0.8.2 they would each load their own version into memory. This approach would waste memory in some cases, but you would never see your apps behaving unexpectedly because of changes to the underlying libraries. I think the memory tradeoff would be worthwhile for the increased stability and, of course, the smug sense of superiority. ("DLL hell? Oh please. Don't tell me you're still loading shared libraries by filename on your OS!?")
--
Never happen.
I just installed a Debian GNU/Linux system with 3 floppies (not CDs, not DVDs, but 3 1.44 FLOPPIES) and a network connection.
Once the system is up, I have access to, what is it now, over 6000 packages?
I hate to say this, but the network really *is* the computer, if you take advantage of it.
Tyler's words coming out of my mouth.
RAM usage.
If you use shared libraries, each gets loaded into memory ONCE. This is particularly good for something like the GNOME or KDE desktop. Do you really want 13 copies of the KDE libraries loaded into RAM because you used staticly linked binaries ??
Anyway, I wouldn't sweat it. This will not become Windows. Open source apps do not install new versions of existing libraries, and libraries increment version numbers when they break compatibility.
I haven't even thought about this in a long time since apt began taking care of it for me.
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."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Check out http://www.gnu.org/software/libc/FAQ.html#s-1.17, and try objdump -T sometime.
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.
Linux is NOT descending into DLL hell for the simple reason that it has a logical way of maintaining the separation between major versions of DLLs. As developers are being good on Linux, DLL hell won't exist the way it does on Windows.
That's the way it is now, but it's only going to get worse as Linux gains popularity. For the reason why, let me quote another portion of your post:
(i) Windows developers got lazy and didn't put versions in their filenames. (ii) Windows developers got lazy and put all their application DLLs on the path (ie system directory) instead of in the application directory.
The application developers got lazy. And if/when Linux picks up mass market speed, you can expect the exact same thing to happen.
NO CARRIER
Open source apps do not install new versions of existing libraries, and libraries increment version numbers when they break compatibility.
then how come cdparanoia (or any of a dozen other applications) insists on a different version of libc.so.6 than the one I have installed? Silly me, in twenty years of Unix experience I had naively expected that "requires libc.so.6" meant just (and only) that.
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.
There seems to be a HUGE misunderstanding. Yes, there is a problem with shared libraries. But the problem with shared libraries is minor compared to DLL hell. Shared libraries are a sunburn. DLL hell is hell.
Microsoft DLL hell is largely caused by a deliberate attempt to create copy protection by obscuring how the operating system works. You can't fix the problem because you have no reasonable way of getting the information you need.
This class of problem just doesn't exist with Open Source software. Yes there may be difficulties, but all the information necessary is available. The people who write Open Source software are smart and are solely motivated by the desire to do a good job. You can be sure that they will find ways of solving the problems. See comments #56, #165, #59, and #17 above for ways of solving the problems.
On the other hand, to a commercial monopoly like Microsoft, DLL hell is an advantage. It gets people to upgrade quickly in the hope of having fewer problems.
See #53: "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."
Bush's education improvements were
As a Windows coder myself, I know a fair bit about DLL, and I know it's not the way they work that's causing the so-called Windows 'DLL-hell'. It is the fact that Microsoft allowed programmers to include core windows libraries with their programs to ensure compatibility (and those programs could replace the windows ones too). Sure, its cool to keep your exe size down by using a few system libraries dyn-linked, but most people think its better to shove all these libs into their installer than static-linking (i personally like to build one or two-file apps). DLLs have their use (e.g when you want your program to be easily upgradeable, or as plug-ins), but people you don't have to use them. It's not cool, its confusing and it serves little purpose.
.NET programming is that you can use the .net dlls to access a huge number of cool .net functions for RAD programming.We shall wait and see though...
And all this DLL hell stuff...I haven't met with a single DLL problem since Win95(i havent met any problems on linux either)...And WinXP will have even better core DLL protection and stuff...
By the way, one really (seemingly)cool thing about
There is no such thing as 'world peace'.
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?
if incompatible libraries are found, the installation process should wrap its binaries in scripts which set LD_LIBRARY_PATH to the necessary compatibility libraries (/usr/lib/compat) -- and they should be linked to _specifically by version_, so that different versions of compability libraries don't fight with each other.
Excellent plan. Just so everyone knows, though, LD_LIBRARY_PATH is rarely needed. In this case, it is only needed because the binaries are precompiled. If you ever have to set LD_LIBRARY_PATH, the software should be recompiled correctly!
Neat eye-opening information about LD_LIBRARY_PATH can be found at Why LD_LIBRARY_PATH is Bad
I don't think we're going to see anything analogous to the DLL problem because most shared libraries use explicit versions. But I would love to get rid of the madness of being told to set LD_LIBRARY_PATH to run software I just compiled! All you have to do is set LD_RUN_PATH during compilation. (See that link!) One notes that Perl's MakeMaker system always sets LD_RUN_PATH appropriately when compiling an extension module.
Secession is the right of all sentient beings.
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.