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.
Http://www.linuxbase.org is trying to acomplish this. They have good backing and if all goes well we should have a bit more of a standard library group.
- Perform proper versioning on your shared libraries. The simplest rule is: If your new version breaks binary compatibility (on any platform!) change the soname. Normally you would bump the major version number. The versioning abstraction layer provided by GNU libtool is far from being perfect, but it does it's job.
- Make your shared libraries fully self contained. Many platforms (if not more) provide everything to accomplish this. At runtime (and at compile time for executables or shared libraries that your library is linked to) the system must be able to resolve all needs of your library. The executable and linking (or linkable?) format provides the dynamic tags NEEDED and RPATH for this. Most prominent example for ingnoring this rule is libpng: You think you need to say -lpng -lz for linking against libpng? You are dead wrong! If libpng would be self contained, the linker does not only know, that libpng needs libz, but where it should look for libz (for the case it's not in
/usr). So no need to say -lz as long as you don't use libz in your code.
But there are problems. First of all the GNU ld needs to be fixed. It fails use the RPATH of shared libraries, when looking for NEEDED libraries at link time. I sent patches, but nobody seemed interested.So long, happy linking.
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.
Good point, except that I'm happily running gnome 1.4 under debian unstable and selecting gnucash caused 15 extra packages to be installed:
libguppi11
libwrapguile
libwww-perl
slib
scm
guile1.4
guide1.4-slb
libgwrapguile0
libnet-perl
liburi-perl
libhtml-parse-perl
guile-common
libnet-telnet-perl
libhtml-tagset-perl
This is on a system with a fairly extensive set of apps used normally. I can see where if you use perl for a bunch of your stuff, and guile, there really is no choice but to install the full development files and libs on a system that has no guile stuff on it.
However, it's 40ish mb of archives that I have to download (Thank $DEITY for fast adsl!).
That is pretty cool.
Question.
Is it like this?
\SomeAppDir\!Application
\SomeAppDir\!Application\!Sprites
etc.
Or is it like this?
\SomeAppDir\!Application
\SomeAppDir\!Sprites
etc.
Just curious... RISC OS sounds fun.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.
So what would you _like_ programmers to do, then? People talk about reusing existing code, but then complain when you require more shared libs, due to the fact that you're using someone else's code for some particular functionality instead of writing your own (to redo the exact same thing - why solve the same problem AGAIN?).
People really need to make up their minds. I know I for one would prefer to reuse someone else's code for common functionality, rather than having to rewrite it myself every time I need it (or static link it, making unnecessarily bloated binaries).
_____
Sam: "That was needlessly cryptic."
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
According to the gnucash site, the requirement is for GNOME 1.4 plus 4 other libraries. This is hardly as complicated as the situtation is being made out to be in the editorial.
A Pirate and a Puritan look the same on a balance sheet.
...Another fine example of slashdot respondents not bothering to inform themselves on the issue before spouting off.
Most of the GNUcash dependencies are satisfied merely by "obtaining latest version of associated desktop". That hardly rates as "including every single doo-dad" or "spans 10 DVD's".
This is more a matter of a developer using "bleeding edge" libraries rather than creating some perverse octopus.
A Pirate and a Puritan look the same on a balance sheet.
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
hence the vast market for Ghosting and Imaging software.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
You're wrong. Even the regular XF86_SVGA server must directly access the IO space, and it does so through the kernel. On my Alpha, when I still ran Linux on it, I had nothing but problems with X. A perverse combination of user operations (e.g. a fill or scroll) would completely lock up the machine.
Yes, there are times when some poorly-written X app kills the server, and there are times when the X server bugs out without killing the OS. But your statement "X and the Kernel are clearly different" is a gross oversimplification, ignoring, iovec(), memory-mapped IO, and the like. Even the most lowly frame buffer drivers must directly access the hardware.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
I'm proud of my Northern Tibetian Heritage
I found it a little bit ironic that I read the lwn.net article about Gnucash yesterday afternoon and this morning my daily 'apt-get update ; apt-get -dy dist-upgrade' of Debian unstable put a copy of gnucash-1.6.0 on my desktop. Also included in Debian unstable is Evolution 0.10, Mozilla 0.9.1, and Nautilus 1.0.3 they all seem to work together fairly well. It seems that a version of Netscape is also available, but I wouldn't know, I haven't used Netscape in some time.
Shared libraries are good. And shared libraries are especially good in Linux where it is a trivial thing to have different applications use different versions of the same dynamic libraries. With the next generation of Linux distributions all of these libraries will be included (probably by default), and so installing will be a piece of cake.
The difference is that in Linux you can use LD_LIBRARY_PATH so that you can guarantee that your application loads the dynamic libraries that you need. Couple that with a library versioning system that has major and minor revision numbers and that allows you to have several different versions of a library and you have a system that is basically DLL-Hell-proof.
The author of the original lwn.net article apparently simply doesn't know what the heck he is talking about. If the Linux system that you are using does not make adding new libraries a trivial undertaking then this needs to be filed as a bug. Gnucash 1.6.0 is a new release, and to run new releases you either have to know how to build and install software, or you have to wait until someone else does it for you.
To illustrate this, I spent a small portion of time this morning playing with Debian unstable's version of gnucash-1.6.0. I installed it with a simple 'apt-get install gnucash' and it painlessly downloaded gnucash and all of the required libs (that I didn't already have). After nearly an hour of playing things seem to be just fine (and gnucash is much improved over the 1.4 series).
Dynamic libraries are good. They are even good on Windows now that Windows 2000 has finally got their act together and allows multiple versions of the same DLL to be in memory at the same time. They have been useful on Linux for quite some time.
The my entire /etc/apt/sources.list consists of two lines:
deb http://http.us.debian.org/debian unstable main contrib
deb http://non-us.debian.org/debian-non-US unstable non-US/main
Notice that I am not using Ximian's packages. I have used them in the past, but unstable has generally had the software I needed without the extra hassle of dealing with Ximian and their sometimes not quite Debian compliant packages. I ended up removing all of the ximian packages some time ago.
RedHat is a fine choice for a distribution, and Debian isn't for everyone. It seems to me that RedHat probably would be the way to go if you were primarily interested in Ximian's Gnome packages. At least with RedHat those packages are likely to be well tested.
Either way, there certainly is no evidence of DLL Hell. It is just a case of a program that has a lot of required libraries. To my mind this is the best sort of code reuse, and is definitely a good thing.
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.
The developers ALWAYS use the latest and greatest odd little library. The program has not worked on SuSE forever.
I am not surprised that they chose gnome-1.4 which has been available for 6 weeks as a base for a finance app, that would happily work as a gtk app (like gimp).
--
Moritz
Thanks
Bruce
Bruce Perens.
I think this idea has been suggested several times here, and is a good one. However it does mean the "application bundles all the libraries it uses". What you are saying is that the application does not necessarily use those libraries if the same version can be found in a more central place. Personally I feel this could be done with some kind of hash codeing of all the read-only pages swapped into memory, thus merging any matches without any version or file matching at all, but what do I know...
Why the hell is there anything more complicated than this. I really want to be able to test the software without "installing" it.
Just put the libraries in there and fix the system so it is trivial for a program to turn argv[0] into it's execution location and it looks in that lokcation for shared libraries first. Yea, it's different, but it will be far better.
Or put the source code in there and when the user double-clicks it pops up a window that says "please wait, compiling gnucash" and then it works and is perfectly adapted to your system. This would be a huge win, and is something closed-source providers just cannot do! Don't worry about the time it takes, people are apparently willing to waste hours running "install" and the compile is nothing compared to that.
I am just making normal DLL's (whatever you get when you "link /DLL" all your .obj files). It does appear it searches $PATH when it needs a DLL (I always must remember to delete my optimized copy, which is an earlier directory, before running if I want debugging to work). In this case it works exactly like LD_LIBRARY_PATH (which reminds me, I am just as confused by Linux as Windows. Why isn't this variable *always* needed, why is there some other mechanism to locate shared libraries?)
However one nasty screw up I have seen several times (but I can't reproduce at will, that's NT for you!) is that sometimes the other library will get "locked into memory", so that it refuses to load my new copy. I swear that I have exited, and even deleted, all the executables that are using that shared library, but it is still there! It appears that logout/in fixes it. Also deleting the library itself works (though that crashes running apps using it, why aren't the files locked like NT locks the executables?)
Another annoyance not mentioned here about NT is that you must use a DLL if you want to support "plugins" because all functions the plugins call must be in the DLL. Linux also has this but you can link your program with "-shared" and it then works like the Unix systems I am more familiar with (though I don't do this here as the software has to port to NT and repliating the difficulties of NT helps to keep things portable). For this reason I have to produce a DLL for no good reason at all, only my program uses it, and it is likely only one copy of my program is running at any time. I have heard there is some way to make a "DLL executable" but I can't locate it, just building a DLL out of all the source does not make a runnable program.
Another huge Windows annoyance is "__declspec__(dllexport)". That crap is going to pollute header files in code for ages after NT is dead and buried. What a waste.
This can be demonstrated easily by removing those links, programs still work, but you cannot compile programs (or they find the static versions of the libraries).
You can use symbolic links to get DLL hell, as I will sheepishly admit I have to get downloaded programs to work. Link the version name of the library the program complained about to whatever version you have and often the program will work! However newer things like libc seem to have version information in the file that is checked so you can't outwit it that way.
PS: MFC is also as big a lock-in for MicroSoft as Word is. A huge stumbling block for getting programs ported to Linux is that they are written with MFC or VB systems. The MFC source code is totally useless for the port as it calls Win32 stuff (like structured file parsers) that nobody would ever use in any real code but MFC does so they can hide the implementation.
Would this work, or am I just clueless? Is anybody trying this? Never saw anything about it in all the file system discussion.
Too many posters here seem to have no concept of a program that you can "run" without "installing" it first, and go on about how great apt-get is at "installing".
Listen to the orignal poster. The steps desired to run a new program are:
1. Download the file
2. Double click it.
3. It's running! No, it is not "installing", it is RUNNING!!!! Get that through your thick heads.
Also not mentioned is what the user does if they decide the program is crap and don't want it:
1. They drag the downloaded file to the trash (and empty it, I guess).
2. THAT'S IT! We are exactly in the same state as they were before they downloaded it. It does not "deinstall", it's one file!
What is being talked about has nothing to do with "installation".
If you want "installation" here is how it should work:
1. The user runs the program
2. The program somehow shows a question like "do you like this program and want it to appear in your Gnome/KDE startup, and in everybody else's (or for services, do you want to run it for real versus the simulation that is running now). The user clicks "yes".
3. It pops up a panel and asks for the root password.
4. It churns and it is "installed".
To "deinstall" you do this:
1. Somewhere in the system directories is a file with exactly the same name. You (as root) take this and put it in the trash. It's GONE!!!!
2. Somewhat later KDE/Gnome may notice that the menu items don't point at anything and hide or delete them.
as root, I can hose a Linux system, not matter how stable it is supposed to be).
Hell, as a regular user you can hang X and the console badly enough that you can't use it or reset it. I did it yesterday with RH7.1 and Konqueror (sp?). The X server should not be able to crash based on requests from it's clients, but it does.
--
the telephone rings / problem between screen and chair / thoughts of homocide
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
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.
Um, you don't run a multiuser system, do you... the problem is that if this program is statically linked against 60 libraries, it's probably going to use up a fuck of a lot of memory. And, if you have 10 users running statically linked programs, you hurt. Badly. Especially since it's usually not just one program -- imagine Gnome statically linked. There are several resident programs, all linked against X and libc at a minimum (call it an extremely -- almost psychotically -- optimistic 5 megs each for library code, plus the app.) That's a lot of memory for 10 people running a desktop... and they might want to do work too. Shared libraries exist for a reason.
-30-
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-
Its a bad use of a word/phrase that already has a meaning, that will in the end only confuse young and budding developers. I hate Java's "Design Patterns" (in this case, the naming scheme for JavaBean accessors and event methods) for the same reason -- "Design Patterns" already had a well used, and mostly well understood meaning.
--
You know, you gotta get up real early if you want to get outta bed... (Groucho Marx)
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
The problem is a particular instance of the general "continuous maintenance problem", which is now reasonably well understood (i.e., it's not academically interesting any more). This has been solved in particular cases as far back as Multics and, more topically, in the relational database world.
I have one of Paul Stachour's papers on the subject, although it needs to be OCR'd...
What's a suitable place/list to discuss this?
dave (formerly DRBrown.TSDC@Hi-Multics./ARPA) c-b
davecb@spamcop.net
well, if you want a slimmed down version of Linux, try: /usr/share
/home /usr /var
rm -rf
hell, even better, try this:
rm -rf
now you're down to a bare-bones, 10 MB linux install with all the cool commands left (ls, cp, sort, etc.). Pretty cool eh?
I pointed out some of them on the bug-glibc mailing list:
-
if glibc (or really any shared library, bug glibc is fundemaental for all apps) is updated (even from, say, 2.1.1 to 2.1.2), the
n all applications (including things like X-windows) on the system need to be recompiled for guaranteed correct behaviour.
-
If a user has glibc 2.2.2, downloads an application which was compiled with glibc 2.2.1, but uses some shared already on the user's computer compiled under glibc 2.2.2, correct behaviour is not guaranteed.
I havn't had time to propose a solution, but there should be one if you think hard enough...The current situation is not acceptable.
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.
- If you're the package maintainer, release source code and statically linked binaries, so that people can use your program without hassle
- If you're a distribution maintainer, figure out the dependencies and only release problematic versions once all the necessary libraries are available in your distribution
I would also recommend that projects that need so many libraries do not depend on the latest version of all of these (usually, there's no real reason to hard-code such dependencies into configure scripts etc., it's just the lack of information about incompatibilities between libary versions). If you can't ascertain that your code will work with older library versions, or if you're just too lazy to check, stick to these older versions while developing - it's what your users will have!(why do open source software authors pay so little attention to their users' needs?)
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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.
Assuming we remember the fuss. You're giving our collective attention spans way too much credit.
--
Liberty uber alles.
Indeed. In fact, the development of GnuCash helped push a couple of those packages to have new features [there was a lot of back-and-forth with respect to Guppi, for instance, that benefits both projects]. Guile got a few things GnuCash was including itself into the guile distro, IIRC.
The deps for GnuCash are at the forefront of the state of the art for the GNU desktop, but c'mon: this ain't no half-hour hack; it's one of the more serious desktop applications for Linux, and thus requires some recent libraries. Or, you could just dual-boot and run Micros~1 Money or Quicken...
...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.
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)
--------------------------------
As I look through the System Folder on my Powerbook I notice there aren't a large number of platform specific tools in there. The drivers are Apple drivers comforming to driver rules and everything is compiled for PPC. Oh yeah, Mac OS 8 worked on just about every piece of Mac hardware after the introduction of the 603. Linux is pretty much the same way. I've installed binary packages on lots of different computers and never had a hardware related problem before. If you DO have problems thats your own fucking fault for using shitty hardware that doesn't comform to specs like everyone else does. You don't install different C libraries because you've got an Athlon on a Via chipset. The dude had a valid point, installation procedures on linux are pretty retarded sometimes and turn people off to using it. Not only that but it is fairly daunting to have a thousand little apps that do the exact same thing a different way. Do I really need Yet Another (insert function name here)? Saying OS X is inferior because it doesn't work on Y platform is retarded. Linux doesn't "support" any more chipsets than x86. All the other platforms are worked on by third parties besides Cox and Torvalds. And lastly, Linux != X (as in windows).
I'm a loner Dottie, a Rebel.
Since it's only two programs, I've modified the Mozilla startup script and created a startup script for Opera to set LD_LIBRARY_PATH to find libjpeg.so.6.2, instead of 6.1. I've tried upgrading ImageMagick, but both non-SuSE rpms and the source break, and the SuSE rpm essentially requires upgrading all of SuSE. oh well - DLL Hell is warm in the winter...
I don't want a lot, I just want it all!
Flame away, I have a hose!
Only 'flamers' flame!
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
I don't think so. I'm pretty sure that Linux merely memorymaps the libraries when they get linked in. Only the parts that are actually accessed are loaded into memory where they are cached for later use. It's very fast.
-- Remember: Wherever you go, there you are!
Not all Linux distributions are like that at all. I use Debian GNU/Linux and when I want to install package foo I just type "apt-get install foo" at a prompt. Done. apt will resolve all dependancy issues, download all required packages install them and configure them without you having to lift a finger. Just about any piece of software you can think of is available as a package in the Debian system.
Debian also has guidelines about how packages are built so that software is installed in predictable places. All packages have a dedicated maintainer (and changelogs) and are generally of higher quality, ie. they work on the first try.
Yes, the Debian installer is a real piece of crap but the Progeny installer is Slicker 'n Snot(tm). Yes, there is a bit less handholding, but it is also less required as stuff Just Works(tm) out of the box. If you want all the benefits of apt but don't want Debian, however, you can always use the new Mandrake or Connectiva which have moved to apt.
-- Remember: Wherever you go, there you are!
The filesystem does read-ahead cacheing, as well as using all available memory (save 1-2MB) for filesystem cache. I think it would be inefficient to have free memory sitting around not doing anything for the system. Any performance problems would only occur on the first load of a shared library and shouldn't be a problem unless you are randomly access a lot of libraries (see the LD_BIND_NOW=true trick that KDE uses on how to work around this).
Unix style systems are generally optimized to start lots of small processes very quickly and small processes are often used where threads are used on other OS's. For example, on Linux process creation time is comparable (if not faster) then thread creation on NT and threads aren't scheduled any differently than processes. Sorry, tangent alert.
I think that in the common case, libraries for whatever you are using will usually be loaded into memory already.
-- Remember: Wherever you go, there you are!
What would be really neat is to have the compiler
autogenerate a test suite for your app. Say you
are a coder and you just made this nifty app Foo.
Your compiler figures out what interfaces you need
from shared libraries, then builds a test suite
to find these interfaces. On user machine, the test
suite would automatically launch on install, query
all installed dlls for required interfaces, figure
out if these interface lead to expected implementation
(kinda like OS fingerprinting), then install your
app against stuff that will work. If some interfaces
were missing, then tell the user which versions of
libraries are preferred for the stuff to work.
The search bot could even be smart and try to
consolidate interfaces, i.e. find and use libraries
which would have the most interfaces, so as to reduce
memory footprint. It amazes me that computers can
do complicated logic yet much of the install
process requires the user to implement their logic
by hand.
The application does not need to bundle all the libraries it uses. The framework is, in most cases, separate to the application though there is nothing stopping a framework from being included as part of the application's bundle. For more information see Framework Versioning. The is probably more docs on the issue, but this should get you started.
Jumpstart the tartan drive.
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
I agree with this problem, which is why I suggest that static linking be used primarily for the bleeding edge libraries - especially any library that is more recent than the most up to date included in the majority of current distributions.
Once the library used by the program is less bleeding edge and has a more stable API, then dynamic linking would be more appropriate.
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.
You're right that most applications can't be uninstalled that way. That's *another* symptom of the problem. As to the shared dlls in common folders, note I said most of the good developers aren't writing their apps that way. Granted, you may have file associations that need tending. I personally feel Windows ought to handle that by itself, and to a small degree it does with the "Open With" dialog. Other info stashed in the registry generally amounts to exactly squat; it's no more harmful than having an unused config file on a unix box.
You're absolutely right it shouldn't. But the real cause there is most likely the sound driver or the mp3 player's use of it. That's exactly what I was talking about :)
The bit about Netscape taking down Windows... Once again I'd wager the coders did something bad with privileged code. The equivalent portion in Linux may not be privileged. Are you talking even about the same kind of crash?
Was all that hardware on the HCL? Or was it generic crap that you had lying around? Would you complain if OpenBSD didn't work with your NIC correctly if it weren't on the supported hardware list?
I completely understand; I had the same problem with 3.1, 3.5, and 3.51. When I made sure it was all HCL, though, the problems went away. I also run NTx on generic stuff. I have also had better luck with Linux and hardware in that if it runs at all, it runs solidly. I think we both suffer from wishful thinking that "standard" hardware means "standard" hardware. But apparently it doesn't and some vendor may leave certain features unimplemented, badly implemented, or what-have-you. Also, MS may handle certain thing incorrectly in their code, and thus don't HCL something that brings out that mishandling.
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.
The article is misleading. It requires around 60 .so files, which are available in 5 different packages. The author of the article omitted this fact, and it's just plain poor journalism.
Need Free Juniper/NetScreen Support? JuniperForum
UNinstalling apps in Windows is a serious PITA. I'd say that roughly 50% of the uninstallers that I've used don't work. And no, I won't go buy a commercial 'uninstaller helper'. They think a browser is an important and integral part of the OS. I think a working uninstaller is a bit more important.
/usr/local/src/PACKAGE && make uninstall
/usr/local/bin/PACKAGE-BINARY && rm /etc/PACKAGE-CONFIG
In Linux, I can usually do:
1) cd
OR
2) rm
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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
Truly. Not only is it nothing new, but also
.|` Clouds cross the black moonlight,
a) the concept of `standard distributions' is totally bogus; there is no reason why software should be constrained to the contents of RH CD1 for compatibility;
b) the whole GNU/Linux scene has not evolved this far by sticking to distributions;
c) developers seem to be able to keep track of what version of what file they have installed where, including multiple versions for debugging etc, with fair amount of ease (I envy the blighters! I tend to fall back on a package manager for that, and heaven help me when I'm writing anything like code);
d) If you have a decent distribution where software is indeed correctly regarded as a big pool with ever-flowing version numbers, tracking this sort of thing is not exactly a problem.
In short, somehow, before you label me a Debian freak for suggesting `man apt-get` is a useful thing, remember that the whole point of this comment is to draw attention to the existence of apt as *FREE SOFTWARE* for whaever distro/platform you choose, not as a `Debian thing'. Use the source, Luke. Source is all; categorizing things into versions is like the Matrix compared to reality.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
I don't see what the problem is.
I don't want knowledge. I want certainty. - Law, David Bowie
If you prefer having to reformat and reinstall your OS every time something goes wrong, because it's all happening "behind the scenes" and you can't fix anything, stick with Windows. Or a system administrator has to do this because something went wrong. Possibly the clueless enduser trying to install something.
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.
It seems to me that dll's are both a blessing and a curse for windows. I've always found that installing software on windows tends to be much, much simpler than on linux. For example, say you want to install program x on a windows machine. Typically what is required is running some type of setup.exe file, and the rest is taken care of. On the other hand, in Linux (Redhat for this example) one may download the rpm, only to find that many other rpm's are required. Upon trying to install those rpms, one finds out that each new rpm requires others... It gets freakin annoying as hell. Is the doze approach better? Probably not. I mean, I hate having my win\system folder filled with crap that I no longer need after uninstalling a program. But at the same time, I know that installing a new program isn't going to take more than 5 mins or so. Keep in mind that I'm a redhat/mandrake kinda guy, so apt-get isn't too helpfull for me. Surely there must be a more elegant solution?
S.t.e.v.e.
Contrast this to linux 'dynamically linked' libraries that are generally developed at a leasurely rate - or even at an excelerated rate. However, the difference is, these libraries are not rushed out 'into the wild' - they're kept in development or even CVS until they're deemed stable enough for the rabid, er, using public. :)
As far as the stability of Windows iself is concerned (from my perspective): it can be anywhere from pretty darn good (5+ days uptime on a win98 gaming/programming/multimedia box w/o any glitches) to really freaking bad (4 or so reboots a day). All in all, I'd say the main determinant I've seen in saying to which extreme a system will go is the quality of the hardware and drivers for that hardware (as well as the presense (or lack there of) of shizzy VB programs and their inbred next-of-kin). My Duron 700 system with a GeForce 2 MX and 256 megs of PC133 Micron memory (to name a few of the components) has some quite surprising uptimes - all I do is use the latest Detonator, 4-in-1, and various other drivers (or older ones that run well/stable). On the other hand, I've had systems in my possession with fairly 'generic' components in them, and their performance is really bad. The video card (being that Windows video functions are in the kernel) and the quality of the system memory seem to have the most to do with Windows stability, overall.
Whoa, quite a bit. :)
-------
Caimlas
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
- then you have a Linux distro that spans 10 DVDs just so you can include every single doo-dad program (and its libraries) on the planet. Next thing you know, MS starts advertising themselves as the quick and easy OS that needs only one CD to install. That, my friends, is hell.
The Windows linker works pretty much the same way - an application always loads the DLL that it was originally bound against. If you change the interface you should change the version (ie filename) of the lib.
The real problem with Windows comes from the two simple facts:
(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.
Despite what other developers may lead you to believe, all versions of Windows NT (and I believe Windows 9x is the same) will load DLLs from the application directory first, regardless of whether there is another DLL of the same name already loaded. For a DLL to be "reused" in memory the following conditions have to be satisfied:
(i) The DLL must have the same full path name.
(ii) The DLL must be able to be loaded at the same logical address.
If the logical address is already used (probably by another DLL) then NT will simply dynamically load a new copy of the DLL at a new address. For those who don't understand why it has to be a new copy, look in any OS book about Dynamic Loading and "fixups".
Remember that: You can load two DLLs of the same name on any version of Win32. Many people still live in Win16 land where you couldn't do this, but it is definitely possible (try it and see).
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.
Fear: When you see B8 00 4C CD 21 and know what it means
-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
Multiple versions of the same library aren't that problematic, because libraries are versionned (xxx.so.version) . The real problem is that developpment headers (you know that include / .h files) aren't versionned. So when you upgrade a library, the new headers overwrite the old ones. And if backward-compatibilty isn't provided (#ifdef everywhere), some older software depending on older versions of the library won't compile any more.
/usr/local or /usr. For instance, configure with ./configure --prefix=/usr/local/libalsa0.9 .
/usr/local/libalsa0.9/include, and libraries in /usr/local/libalsa0.9/lib .
/usr/local/libalsa0.9/lib in /etc/ld.so.conf if you found that most existing programs are compiling and working with that version.
/usr/local/libalsa/lib" and CFLAGS="-I /usr/local/libalsa-/include" in your environement variables.
- Compile with that.
- For pre-compiled binaries, use LD_LIBRARY_PATH. This environment variable can specify alternative paths to search for libraries. It isn't a global setting like /etc/ld.so.conf. It just affects programs launched when LD_LIBRARY_PATH contains a path.
You can easily write little shell script wrappers that will set LD_LIBRARY_PATH before launching an application.
When installing a new library that might conflict with what is already installed on your system, use a different prefix than
Include files will be in
No, add
And if some programs are incompatibles : - Set LDFLAGS="-L
{{.sig}}
The way classic mac os does shared libraries is it looks in several different places for them. I know off the top of my head of 2 different places. First, it looks in the directory that contains the application. If it doesn't find it there, it looks in the extensions folder. That way, older apps can have their own version of the shared library. This was necessary for older MS apps. I know my friend used this technique when he couldn't get his X-Files games to work correctly with the new Mac OS.
The answer is quite easy. Simply stop making so many shared libraries! On Linux, there are at least a dozen different libraries that do the same thing the same way, and progams use all of them. If GTK+ and Qt weren't equally used by different programs, there would be a dozen libraries you could remove right off the bat. If people didn't keep releasing toolkits and wrappers as fast as they could code them, the total library bloat would greatly decrease. Say what you will about closed-source OSes, they do have one advantage. A closed source OS is usually managed as a whole (rather than having seperate projects for the kernel, GUI, etc.) Thus they are able to impose standards on developers (yes, imposing standards is a good thing, just like imposing law) who, while free to not follow the standards, do so at the risk of pissing off consumers who have grown used to uniformity.
A deep unwavering belief is a sure sign you're missing something...
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
Shared library versioning can be made to work, so it's only annoying to have to have multiple versions of a library installed. Some other OS's still haven't figured that out.
Another usefull feature is that shared libraries don't have to be system wide. The system doesn't share libraries based on the name, it's really based on the inode and mount point. So two different libraries can be named libfoo.so.4.2 as long they're in different directories. The user may get confused, but the system won't.
As long as everything has a reasonable license, we our allowed to fix it ourselves.
I assume the Debian package is already done, or will be done shortly. Type apt-get install gnu-cash and let it sort it out.
that if an application that loaded a DLL crashes or is forced to terminate the DLL may remain in memory. COM DLLs do have use counts but it's up to the application to decrement the count when it's done with it. A good operating system should clean up after bad apps automatically, IMO.
Another problem has to do with security. DLLs and COMs advertise their data types through the use of variants so that a spying program can easily figure out why being transfered between various apps and DLLs.
That's because Debian has pretty tight policies about library versioning intended to prevent just this sort of problem. Library packages must be built with a proper SONAME, and the "shlibs" functionality allows a library package to tell the system what versions of the package are binary-compatible with that package's libraries. This information is used during the build of other Debian packages to ensure that a package's Depends reflect exactly what versions of a library it'll work with (assuming the library's maintainer didn't screw up, in which case the BTS will quickly let him/her know of the error :).
Mike Markley - *NIX Sysadmin and all-around geek - finger for PGP key
Oh, definetly. Shared libraries that are 100% application-specific should be kept in the application's space.
/usr/lib. Netscape is there, and a whole bunch of others :)
In fact, this is what happens on Linux too. Check the subdirectories in
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
This shouldn't happen on Linux. At least not if things are installed properly. Let's look at an example. FooBar and YooHoo both require Wingbat; here's what /usr/lib might look like:
libwingbar.so.1.0.2 (file)
libwingbat.so.1 -> libfoobar.so.1.0.2 (link)
Both YooHoo and FooBar are linked against libwingbat.so.1. A new, *compatible* version(usually a bugfux release, or in some cases a version which adds another function, but doesn't touch existing functions) is released. It will then become libwingbat.so.1.0.3 or somsuch; libwingbat.so.1 will then by symbolically linked to the new library.
If a wholly new and incompatible libwingbat is released, then its so-version would be bumped; so you'd have:
libwingbat.so.1.0.3 (file)
libwingbat.so.1 -> libwingbat.so.1.0.3 (link)
libwingbat.so.2.0.0 (file)
libwingbat.so.2 -> libwingbat.so.2.0.0 (link)
Then, FooBar(which needs the new library), would be compiled against libwingbat.so.2. Now, library authors are *very* careful about stuff like this. If you've had problems, I would guess that they'd be package-management related.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
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
Dont be such an imp :)
/usr/local/ beef? heh Wuss.
If cdparanoia is bitching about the wrong libc.so.6.... WELL FSCKING COMPILE IT YOURSELF!!!
That's the beauty of Free Software. And by the way, cdparanoia is PAINLESS to compile and install... What, scared of a little
It's not a Hell, but at least with the Glibc libraries it's quite an annoyance.
I can't get Mozilla 0.9.1 because it wants Glibc2.2 - which I can't install without putting at risk my system. Same thing apply for the latest version of emacs.
The Glibc Heck has proven to be quite a pain in the hard drive. If anyone has a solution that doesn't involve rebuilding the whole packages (I already thought about that, thx), I'd be glad to hear.
Thomas Miconi
You would compute the checksum when loading the library, and check it against the filename given in the executable.
Identical checksums are very unlikely if you use long enough checksums (64 bits would allow 16 billion billion unique DLLs).
--
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.
Not that there's anything wrong with either group of people, but both have radically different needs and radically different definitions of what failure truly is. For a geek, failure is something not running optimally, or some cool feature getting disabled, or something that comprimises security. For an end user, the definition of failure is not bloat. Nor is it crashing. The greatest failure for a desktop, end-user is something not working. The cost of something not working far exceeds any other cost, whether that cost be the cost of more RAM, disk space, performance, or really anything else. End users want their programs to "simply just work". And they have the constant, gnawing fear that virtually anything they do will screw up their computer so badly that it won't be able to do the valuable work they need it to do. For the end user, a dynamically linked AbiWord or Gnumeric going tits up two hours before they have to hand a report to the boss is far, far worse than statically linked AbiWord or Gnumeric using lots of RAM in an unefficient manner.
Comparing dynamic linking to static linking is like comparing a Ferrari to an M1 tank. They both have their advantages, but guess which one you want on the battlefield of the desktop?
Speaking of package manager hell, there's been a lot of griping on various mailing lists lately about RPM database corruption. Apparently something breaks if you switch from db1 to db3, and it's VERY easy for your RPM database to be corrupted. Try doing any upgrades on an RPM based system when the database is corrupted.
The DLL hell thing's been around for a long time, too. Anyone who's ever made the mistake of trying to mix and match package managed software (Try compiling some gnome app that doesn't have RPMs sometime and you'll see what I mean.) You have to go all or none with package managed systems. Or try burning the Ximian branded gnome off your hard drive sometime. That's good for a few hours worth of fun.
So yeah, the whole set-up could probably be a lot more robust. Ideally it could be done without bundling all the requsite libraries in with the package as I understand they used to do with the NeXT.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
A rather nebulous assertion, since you don't give any specific examples. When the api changes the library should go to a new version number.
I'm not saying it's never happened, it's quite conceivable. There are two reasons why this could happen - either the library coders changed an api and didn't rev the version number appropriately (unlikely for any of the major libraries which tend to be maintained in a very professional manner) or an application coder circumvented the normal api (MUCH more likely.) Sometimes inexperienced coders will do this and think they are really clever for it, but it's actually very stupid. Either way, the problem is not in the system design, it's in someone doing something very stupid in their code. In either case it would be instantly clear who screwed up, and thus who should be on the receiving end of a stiff LART. This is probably why it's so rare.
This isn't an issue with GNU cash, and even if it was, it STILL wouldn't be anything like .dll hell, which is a design problem, not a problem with individual coders doing something stupid occasionally.
"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.
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.
Image the bloat hell we would be in if everyone linked their projects statically to libraries.
Do I need 20 copies of the same damned .NET DLL on my disk, one for each application? I think not. I do not consider this an intelligent move at all.
When's the last time you saw a "disk full" error?
Personally, I'm in danger of forgetting what that means. When I retire a machine these days, there's always at least a few hundred MB, more likely a gig or two, of disk space left.
Along with the inevitable rise of COM, keeping DLLs out of c:\windows\system has gone a long way toward remedying Windows' version of DLL hell. "Intelligent" or not, there are some very good, real-world-type reasons why each app should maintain its own DLLs locally. Everything just works better that way.
Dahlmann tightly grips the knife, which he may have no idea how to use, and steps out into the plain.
Check out http://www.gnu.org/software/libc/FAQ.html#s-1.17, and try objdump -T sometime.
Worse, when you bring in a shared library, you bring in the whole thing, not just what you need. With static linking, only the referenced stuff (ignoring the C++ vtable problem) comes in. Yes, some of it may get paged out later, but you pay for the I/O during program startup.
Now if you're using shared libraries which have shared state, that's something else. And it's something else that ought to be done via an object broker, like CORBA, not by abusing the shared library or DLL concept.
Sometimes running separate executables in subprocesses would be more appropriate. Things like file import filters ought to be run in separate processes, for example. That, after all, is the "UNIX way".
"I am not an IANAI" is what I think he means.
So, the world's first self-contradictory, palindromic, recursive, self-referential acronym, which is also potentially existentialist.
--
Put another way, if you have an error in a shared DLL, fixing that DLL will cause all other executables using that DLL to suddenly work properly
Except for programs that use undocumented behavior in a DLL. Changing undocumented behavior is a large part of why programs that work on one version of an OS crash on the next.
(provided, of course, that you didn't change any APIs).
Which, incidentally, is Microsoft's specialty. Programs compiled with Visual C++ make calls to undocumented parts of Windows that change from release to release, forcing proprietary windows software developers to license and install the new version of the compiler and recompile everything.
Will I retire or break 10K?
the RedHat 7.0 release illustrates this well. I have not seen such a shoddy OS release since Sun Solaris 2.2 (or was it 2.1? doesn't actually matter, because Solaris wasn't much to cheer about until several major releases later) or the first IRIX 5.x releases that shipped with the first INDYs.
RedHat 7 was the reason I changed to Debian, and having used Debian since then I have not wanted to go back to RedHat and their hellish world of RPMs, stupid incompabilities, package management that is able to self-destruct if you are not aware of the "right" way to upgrade things and the constant hassle of Alpha-quality software that requires Alpha-quality libraries and *staying* on the bleeding edge if you want to upgrade them.
I used RedHat for many years, so the psychological threshold for moving to Debian was rather high. the Debian crowd comes across as less pragmatic and more idealistic, but in reality I'd say the Debian crowd are more competent AND more pragmatic in the sense that they strive to deliver something that will work -- while RedHat will ship any assortment of crap that, although not breaking right away, certainly will result in a messy system once you start to upgrade things.
I am immensely grateful for the decent job the Debian people have put into their distribution. they seem to do things properly or not at all. thanks guys, you make my days so much easier because I haven't needed to clean up any of the boxes where I have run Debian for several months now. that something just works and keeps on working without me having to unfuckify things every N weeks is sort of a novelty for me with Linux distributions.
as for RedHat, I have talked to a few people there and the only thing I can say is that nobody is interested in your excuses or promises to fix things. what is required is a change of attitude. you need to become more aware of quality, you desperately need more personel that have used other UNIXen. whenever you invent new things you are prone to do the job badly or at best half-way. people want release quality work from an OS distribution.
as for developers, I think that the question is one of tradeoffs. it is good practice to re-use components rather than designing and writing your own. but, when the components on which you depend have not yet reached a stable release state or they are otherwise low quality or prone to conflicts or installation problems, you should avoid them. the reason so much of the software for Linux is in practive unusable is because the developers don't give two shits about the users. they are used to installing bleeding edge libraries every two days and they expect their users to do the same for the privilege of using their code.
I have made it a general rule never to rely on anything that isn't considered stable enough for inclusion in reasonable OS distributions. usually, FreeBSD STABLE and the stable releases of Debian. RedHat and derived distributions seem to lack the maturity for me to trust them implicitly. sure, things might work well for a while, but in my experience a RedHat installation detoriates over time to the point where suddenly the system is so broken you need to re-install (sound familiar?). and yes, I have used RedHat for about as long as they have been around, so this is not your ordinary Debian-zealotry.
since I require things to install easily on a virgin system and without having to muck about with bleeding edge libraries a lot of "cool" things are never installed on my machines. for instance some "cool" file managers and browser never make it to my machines because the developers are unable to produce something that can be installed pleasantly.
To sum it up: the reason a lot of shared libraries under Linux are such a hell is because there are too many morons who develop software out there in a fashion where you have to upgrade and/or install all sorts of crappy, unfinished buggy libraries on a weekly basis.
this can be avoided if you want to. by being conservative and by not using things before they reach an acceptable level of stability.
I recommend people use stable releases of Debian and install all their software with apt. if you absolutely need something not avilable, make sure you install it in /usr/local along with all the other stuff it depends on but which doesn't come with the OS.
but the best thing is to be disciplined and just use a clean Debian system. I have YET to have any problems with Debian (about 10 machines which have seen much use for 6 months. with RedHat the machines should be ripe for re-install about now)
This article make several fallacies. First, it assumes that because Windows application sizes have not decreased since they became more dependent on dynamic libraries, dynamic libraries must not decrease the size of the binary. The fact is, if those already large binaries were staticly linked, they would increase greatly in size.
The second is the "there is plenty of drive space and memory to go around" argument. The author complains that Word has large binaries with neadless junk in them. If he had many large binaries, each with their own version of the same functions staticly linked, those large applications would take even more space. Sure space is cheap, memory is cheap. But not everyone wants to have to buy a large hard disk and 256MB of RAM just to run some personal finance and office applications.
What it really comes down to is a tradeoff. Windows DLL's are broken because of installer bugs, backwards compatibility bugs and uninstaller bugs. But if things are done properly, and you use several applications at once (I'm sure many of the libraries for GNUCash are not used by anything else on most systems) you have reduced memory usage, storage space and the ability to optimize functionality of several applications without (assuming good coding) breaking the applications or needing to upgrade the applications themselves. Best of all, if it is a common library, dial-up users can spend much less time downloading the binaries if they don't want to compile their own. With open source, you are more likely to avoid "embrace and extend" mentallity, so good code and optimizations without breaking everything are common. With rpm or apt you can easily manage packages of libraries, usually much better than a half-assed InstallShield uninstall script in Windows.
Often when I write a program (or library!) that is linked with other libs, these other libs don't specify well what they depend on.
;-)
So for instance if I write an application that uses some minor GNOME conversion function which happens to be in libgnomeui, I'll often find myself ending up specifically linking my program with gtk, gdk, esound, etc. just to resolve some of the symbols found in libgnomeui.
Then again, I might not understand the linking process completely here. (I once wrote a ten-liner program and gave the wrong ld command, which resulted - after quite a while - in an executable of over 30 Mb; it probably included all libs completely...
Could someone tell me how one commonly links with shared libraries using ld? (I know there are better, platform independent tools such as libtool, but I just don't seem to understand how to link "manually" using ld.)
Concerning the "dll crisis": well, linking takes time, so that's a problem. But shared libs allow for the reuse of modules, so please don't consider it "bad by nature" if a program depends on other libs.
Very often programmers pride themselves of having written stuff "from scratch". That's not really something to be proud of, you know. Remember, good programmers are lazy! So what if your app depends on the GTK+ libraries, most people have these anyway, they instantly make your apps portable to any platform GTK+ is ported to -- no problemo! Or, you could write yet another redundant 'libmytoolkit', forcing more redundant and badly desktop-integrated bloat on people's computers when they want to run your program.
Still leaves the question open, though, how it can be that there's so much to link to in this example.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Besides the obvious, yet important arguments of RAM and disk usage, there's yet another thing.
Admitted, it's a silly thing.
Have you ever seen those older Windows or MacOS apps running on your bright new machine and making your machine look like it's at least ten years aged? That's because they statically link with GUI libraries. These libs beautify in time, but your app stays ugly. Your app stays, well, static, while the system dynamically changes in time.
OK, so that's beauty. I guess that's a minor thing.
How 'bout bugfixes? With shared libs, you get the bugfixes when you get a new libversion.
Some things should just be kept out of an executable IMHO. If you make a little GNOME text editor, and statically link it, the executable itself is suddenly loading themes, drawing lines, etc. Rather, I see shared libs as separate programs that do these things for you.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
You know, things are much simpler than they seem to be. There are so many dependencies because programmers are lazy/unexperienced. It is not difficult to:
A) Use the oldest possible versions of (only basic) libraries. In turn actually writing your own program, instead of trying to use much of other people's code. This also results in much more portable and effecient programs.
OR
B) Include the actual code from a specific library into your distribution. This should be trivial considering the OpenSource nature of the Linux world.
---=-=-=-=-=-=---
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
This is the first time I encounter FUD in a Slashdot article, and honestly, I expected that many readers would.ve already pointed out what I'm about to.
Unix and Linux don't have a DLL Hell like MS had. Unices have a quite simple and elegant solution for this problem.
Have you ever looked in your /usr/lib/ directory? The you'll see that most (if not all) .so-files are appended with a version number. In contrast with windows this allows you to have two different API's for the same dll. The linker will decide at run-time wich version is the right one, and hop ... you're happily on your way.
One more time: Linux doesn't have a DLL HELL.
Now stop whining. Unix has its flaws. This isn't one of them. You're making people nervous for no good reason whatsoever. Thank you.
Hehe, I can just hear the discussion in a conference room in Redmond... "Screw the Netscape users!"
"Rub her feet." -- L.L.
This is really nothing new, nor is it exclusive to Linux. You find the problem on Unix and Solaris systems as well. Some packages come pretty well self-contained with their own libraries meanwhile many open source systems take advantage of open source libraries. One reason is plain old programmer laziness. Why reinvent the wheel when some guy a couple of years ago made a really great wheel and put it on CPAN? One one hand it's a royal pain to keep track of libraries, but on the other programmers are churning out a lot of great applications at a pretty good clip.
But you'll still have the problem of new versions not being backward compatible. MFC42.DLL exists as a 4.2 as well as 6.0 version. MSVCRT.DLL ver 6.0 tigthened up memory management, but that uncovered bugs in existing programs, rendering them unusable. This problem wasn't fixed until SP3 of Visual Studio.
Note that all of these problems are related to new versions of a DLL without changing it's name.
Being backward compatible also means keeping the old bugs. At which point it just becomes riduculous.
M.
Each library must be versioned and each package must call explicitly a version of each library. If the desired version is not available, the installer should deploy it.
Now that would be worthy of an advanced OS. Anything else is simply an open source implementation of a good but outdated OS (aka Unix).
First, remember that unicies can have as many versions of the same library installed at once, each having the possibility of just being a symlink, or being symlink-ed to.
I think that if it is too complicated for you to figure out the shared libraries, then you should stick with the standard distro packages.
I.e., wait for gnucash 1.6 rpm (or deb) comes out for your distro. That way you are leaving the problem in the hands of the distro engineers.
Another solution is to lookup all missing libraries on rpmfind.net and install them as they are needed (yes, that's not the whole problem, but...).
IMHO.
Daniel
That's the thing -- I do think there's such a thing as hardware bloat. My current PC is a P2/333, and I don't think I'm going to be upgrading it for a while (unless I get that PC-tech job I'm looking at...). I have a PowerMac 6500/250 whose only faults are having one too few PCI slots and lobotomized Open Firmware -- if it wasn't for that, it would do MacOS X just fine. And on top of that I have a PowerBook 5300 -- doesn't even run Cardbus, but apart from that it's as good a portable machine for what I do with it as a TiBook (though admittedly I don't much feel the need to watch DVDs on airplanes...).
My name is Brian, and I'm a technovulture.
The upside of being a technical neophile is that computer equipment rarely costs as much as high-end audio equipment (f'rinstance; granted there must be a couple of people out there with an IBM S/390 or zSeries in their basements). But that still means that unless you're running games or supercomputing clusters where you can see the difference, you don't need the latest and greatest -- the bottleneck is never the processor anymore anyway.
I mentioned hardware bloat -- that's the ugly dark side of Moore's Law, a special case of Parkinson's Law IMHO where features increase to fill processing power and/or storage space available. I don't think there's a good excuse for that when we've got things like QNX-on-a-floppy or Midori Linux. Sometimes it's used to good end -- Apple, for example, putting the level of polish that they did on OS X, is to some people a good thing. The flip side is the MS effect -- massive, unnecessary software bloat, or in the case of most current Linux distributions (most egregiously SuSE and RedHat), not so much bloat as a state of muscleboundness where the package fills up with well-written shovelware.
I maintain that the core of any OS written for current hardware should be usable on platforms equal to the following:
-Pentium-90 or PowerPC 603/100
-16MB RAM
-120MB hard drive
-PCI slots
And that, in my opinion, is being quite generous, particularly with regard to memory.
Why is this so hard? Why can't Apple get MacOS X supported on my 6500 when all they have to do is write a working MacOS Classic bootloader package the size of two floppy disks (half of which already exists on a standard Disk Tools floppy)? Why can't I wedge a workable SuSE package onto a gig of hard drive space? Why in the world does Windows need a P2?
The fact is that it's good that we have the capabilities we have now. But there's no reason that the system requirements of the OS should have to grow to keep pace with it. The same argument applies to apps; why is OpenOffice such a monstrosity to download when a copy of VisiCalc will almost fit in a boot block (well, not really, but...)? There's no good reason for this.
Alright, I've ranted. But I don't apologize for it...
/Brian
I've had very good luck with the drivers for my various standalone PCI video capture cards on my PCs. It's been the graphics card drivers that have given me nothing but trouble (especially early Matrox and NVIDIA drivers).
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.
DLL is wrong name for one thing, here made to spite
*NIX jocks. Shared library is proper term.
Anyhow, those who make libraries, know there
are api freezes on major version numbers, and
only internal bugs are fixed on particular
versions. Functionality may be added but not
documented.
Linux has some sort of mechanism of recognising
between different lib*.so.* files, by linker.
I am not expert on the issue, but libc2 and libc1
apps happily coexist on my system.
Now those who do not follow *featureset* freezes
and should be LARTed at that. This means that
GNUCash will suffer some degradation in size of
its userbase, not linux.
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.
The slashdot community, as far as I know it, is exactly for "good, working, simple and well thought standards". This is mostly is reflected in HTML-non-compliance-bashing, the well known Microsoft-Kerberos-Incompatibilites, or Office Document formats.
The non-conformity of the slashdotters in general is more "alternative OS" and "very themed desktops". I think most people working with linux have encountered shared libs incompatibilities and cursed hard (I know, I did, and I'm a fairly new Linux user).
Now there remain two big problems with standards:
- Standards are evolutive, often a new idea is buildt upon an old existing infrastructure (Think email + attachments + HTML)
- Many people think different things: for one person a standard may be perfect but for another it may be complete and utter crap. They just think differently.
So, yes, I think there must be a way to handle this shared-library-hell, but if I come up with a solution hundreds op people will tell its crappy. Just think of apt vs. tarball vs. rpm.Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Image the bloat hell we would be in if everyone linked their projects statically to libraries.
Oh, like I'm really going to notice that 1500 or so binaries have an extra meg or two tacked onto them, if even that. I don't know if you've looked around recently, but even 40-gig drives are going for just $100 or so these days. There's a point up to which optimization is good, and beyond which it's not worth it--think diminishing returns. Guess where this lies? (Yes, I'm well aware there are things like embedded systems where a few kilobytes mean a lot--in fact, I just spent a year working on one. But such systems have plenty of other special requirements as well, so I'm not considering them here.)
On the other hand, a good reason for keeping shared libraries is that if a bug is found and fixed in a library, you only have to upgrade the library (one item) instead of every program that uses it (in the case of libc, basically everything). Even that's starting to become moot with broadband connections, but there's always the security aspect: "oops, I thought I upgraded everything but I forgot about that one contrib daemon and someone cracked me through it..."
--
BACKNEXTFINISHCANCEL
Please pardon a minor rant...
First of all, the interface to all functions and classes in a shared library MUST be backwards compatible with previous versions.
<rant>
And while you're at it, get rid of that stupid symbol versioning system whoever it was invented and stuck into glibc. It makes it impossible to use newer binaries with older (but the same major version) libraries, or even with the same version if it's compiled without symbol versioning. Even simple things like cat don't work. I'm almost tempted to say the GNU people are trying to sneakily force new versions of their libraries on everyone.
</rant>
We now return you to your regularly scheduled Slashdot programming.
--
BACKNEXTFINISHCANCEL
I'm not sure to what extent it can solve the various dll problems, but for newbies who are used to the windows style of installations and have been talked into using linux because they saw Koffice and Konqueror and decided it was similar enough that they could get by, programs like this are *very* nice.
microsoftword.mp3 - it doesn't care that they're not words...
I'm probably responding to the phrase 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.
DLLs have several decent uses, but I'd have to agree that a lot of folks probably just frivolously create them without much thought.
In my own work, I use dynamically linked libraries to provide the following solutions:
By dynamically loading shared libraries that the executable won't be using that often, I reduce the amount of time it takes to load the binary in question, without having to call a separate executable or something. It's a very nice technique, made easier with Visual C++ 6.0's /delayload:[my.dll] parameter.
If you have several executables using the same set of routines, putting those same routines in a shared library that's dynamically loaded can reduce the extra bloat for the individual executables. There's a limit, of course.. your results may vary. If you're trying to dynamically share code that's rather tiny, you'll actually waste space instead.
Put another way, if you have an error in a shared DLL, fixing that DLL will cause all other executables using that DLL to suddenly work properly (provided, of course, that you didn't change any APIs).
If you're working with a truly large executable, it's handy to be able to break things down into separate little binaries. You may create small test programs for those little binaries to aid in testing. This can also help pin-point problems with large works.
I'm sure some folks have other reasons, but these are the most important ones I consider when deciding whether to go with a DLL or a LIB.
And so it goes.
I tested QNX this weekend and found a bug in the glib configuration sccript. Yes, I have already reported it.
But I spend hours trying (in vain) to make QNX work with my network card. Finally I gave up and had to reboot every time when I needed some sources.
Not to mention that it doesn't read ReiserFS, so I had to use a FAT partition to tranfer the files.
I could have made 5 patches in that time. Not to say that I regret this experience, but the "regular" QNX users would be more effective in discovering the problems, while I could concentrate on fixing them without having to fight with my hardware.
After years of listening to obnoxious and deluded Microsoft bashers bitching smugly about this very issue, it's great to see that some of them are finally beginning to learn the hard truth.
There's no perfect solution to DLL Hell - not in Windows, not in Linux, not anywhere. Why? Because it's the human DLL developer who decides whether to issue a minor revision or a major one. As long as he believes that he hasn't broken compatibility, he'll be compelled to issue minor revisions. But unless he tests each and every app that uses his DLL, he can only make guesses about compatibility. As any programmer worth a damn will tell you, any change can break compatibility, even something that seems perfectly innocuous, like a minor bug fix or even a purely cosmetic change. Hell, an app may be relying on a library bug, and it's not necessarily the app developer's fault.Many people think that the problem has to do with Windows-specific things like bad installation software, the lack of symbolic link support, dynamic loading limitations, etc. They're wrong. The real problem is that when libraries are allowed to evolve independently from the apps that use them, users often end up combining software components at runtime that were never lab-tested in combination.
And don't start with me about LD_LIBRARY_PATH or any other after-the-crash solution strategies. Windows has them too. The problem is that they're out of Joe Blow's reach, and always will be.
Some folks have even mentioned static linking. Well ya, that works, but it's not exactly a painless solution. For one thing, you give up the app's ability to inherit library bug fixes in the field. More importantly, you lose the big advantage of shared libraries, which isn't the code sharing, but the late binding. Yes, I'm talking about binary plug-ins, component-oriented development, etc.
Your comment is complete and utter BULL.
.NET runtime. In that system, Application programmers are encouraged to store all their own custom code in their own directories. Of course registration of COM components is gone, since each carries with it an XML manifest describing the component and everything the OS and program need to know about it.
:)
The DLL system was created back when 16MB of memory was expensive and hard drives didn't generally top 500mb. At that time, space and memory was at a premium, and DLLs provided a way to share common code across applications, as well as with the system.
Fast forward to a time when 256MB of memory will cost you pocket change, and we're topping 100GB hard drives. Suddenly, the benefits that made the version conflicts worth it become worthless in and of themselves. Thus, DLLs became a drawback, rather than a feature.
Microsoft is changing all that; first of all, in Windows 2000, no install program can replace a critical system DLL. Windows File Protection will see to that. Unless you are installing a b0rked driver, you will never fail to boot after installing an application. Secondly, Windows 2000 has the ability to load different versions of DLLs in memory at the same time, for different applications. It can also load DLLs out of an Application's own directory rather than the SYSTEM32 folder.
The big changes are coming with VisualStudio.NET and the
Collectively, the XML manifest, supporting resource files, and all the DLL files that makeup a certain library are now called an "assembly." (aka a package).
If a library does need to be installed for sharing, the program hands it over to the assembly store. No application or installer can directly write to the store... The store looks at the version... if two versions are deemed compatible (1.0.x.x), then the shared assembly is updated. If they are deemed incompatible (x.x.1.1), then the new copy is stored alongside the old one. When the application runs, and the OS goes looking for the shared assembly, the store recalls what version the application installed, and hands it that version. Viola, problem solved.
Microsoft was simply solving a problem, and the solution later turned into a problem in and of itself. This time they are being a bit more forward-looking in their approach.
Lastly, just because you are too lazy to read the SDK and other docs, don't say Microsoft is trying to hide things in the OS from you. There is nothing that Microsoft programs, like Office, can do which I cannot do. You would be quite surprised how much information that is really available if you just looked. Spend a week or two at msdn.microsoft.com and then try and come back and tell us that you still don't know how something works; then we'll know you are illiterate
-- russ
Natural != (nontoxic || beneficial)
Thanks for your reply. Your comment is the first seriously pro-Microsoft information I've ever read on Slashdot. I think that's good. I'm not anti-Microsoft. I think I'm more pro-Microsoft than Bill Gates.
Right now Slashdot readers have a general sense that something is wrong with Microsoft; I think that readers would benefit from a more complete understanding.
Notice that you don't refute what I said; in a way you strengthen it. You say that, after 5 years of sheer hell for its customers, Microsoft is fixing DLL hell in Windows 2000.
The people at Microsoft are not dumb. They knew about the problems. As you and other readers point out, there was always a way to solve the problem of DLL hell.
Looking at the SDK, as you suggested, does not solve the DLL hell problem because it is a social problem, not a technical one.
There has always been a way for each Microsoft Windows user to solve the problem of DLL hell, as you point out: It takes a week of work after you have spent many months attaining the knowledge necessary to understand what you read during that week.
My comments are just my opinions. My opinion is that, in the transition from Windows 3.11 to Windows 95, Microsoft achieved something the company wanted. In Windows 3, the files for each program were largely segregated. That made it possible for a user to copy a program by copying its files.
In Windows 95, the registry and the mixing of DLLs created copy protection. It was still possible to copy a program by copying its files, but now it took serious understanding.
My opinion is that the problems with Microsoft Windows 95, 95B, 98, 98SE, and ME have been deliberate, on some level. There is a deliberate 64k or 2 megabyte memory limitation on what Microsoft calls GDI resources and USER resources; this is what causes most of the crashes, even when the user has 256 megabytes of memory.
My opinion is that DLL hell is deliberate in the sense that Microsoft knew about the problems, and waited 5 years to solve them. During that 5 years many users upgraded 5 times, providing a huge amount of money to Microsoft. If Microsoft had delivered a good operating system in the beginning, many users would not have upgraded.
There is a conflict of interest for a commercial company in the business of making operating systems. A company with a monopoly will make more money if there are more bugs. The bugs have to be carefully managed; they must not be too discouraging; they must be discouraging enough to make people enthusiastic about upgrading.
That's why Linux is a brilliant social innovation. The GNU GPL removes the social conflict. Linux is solely an attempt to make a good operating system; the conflict of interest is gone.
We have Richard Stallman and others to thank for that social innovation. Soon we will have an operating system that the whole world can use, and that has none of the problems created by conflict of interest.
Linux is a gift from programmers and writers to all people. We have a way to go in achieving the ultimate goal, but it looks like it won't be many years before Independence Linux, RedHat, Mandrake, and others solve the problems of making Linux easy to use. Then there can be just one mainstream operating system, available to all and usable by all, without the problems caused by hidden adversarial behavior.
Bush's education improvements were
Interesting.
Certainly, if you and I understood this, Microsoft did also. The problem may have originated from sloppiness (suckyness), but not fixing it was deliberate.
Bush's education improvements were
Hidden Microsoft Windows Subscription System
Comment #467 about installers gives a clear explanation about why users would upgrade: If they upgraded, they would get a base of good DLLs. If they still had problems with an application, they could report the problems to the manufacturer, and the manufacturer would be obligated to fix it.
So, by allowing this problem to occur, Microsoft put users in the position of having to upgrade their operating system every year, or face difficulties that would be very expensive to cure any other way.
Microsoft Windows has thus been a subscription system, but it was a hidden subscription.
Note that this problem occurred only for people who installed new applications. People who didn't try new things would not have this particular trouble.
In this particular conflict of interest, this is the kind of effect desired by a monopoly, because people who never installed new software would probably be the kind of people who would not pay more anyway.
Bush's education improvements were
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
I compile all my libs my self, update them my self, and yes i know this costs loads of time, but it has one advantage over the windows dll's that is that i know what i am doing and if something goes wrong then i know what i have done.
I also run a couple of windows systems, and hench i install a program with my admin rights and it just overwrite's a dll else the software wont work, loads of software developers edit and add things to common dll's, which get overwritten, trojans overwrite dll's everyone does it under your windows system, and there is no easy way to check if what you are installing is a correct thing to install or not, you just hope for the best.
With *nix you make your own choice of what lib to install or not, and truelly you can find out what it does if you want, and thats what its all about that you have a choice....and yes i understand if you want to run GNUCash you have to install all those 60 libs =( but if you think it is worth it then its again your choice....and you can do it in a save way i think....
How can everyone agree to make libs compatible, backwards compatible, and standard?
/lib on my slackware-current box, it looks like many libraries already incorporate version numbers into the name, so this is already much better than the dll hell of windows. In windows, I may have 5 different programs looking for 5 different versions of mscvrt.dll, for example, but in Linux I might have several programs using different versions of libutils, but one can use libutil-2.2.3.so, another can use libutil-2.2.0.so, etc.
/dev/null.
There are various reasons this may not work well, but I was thinking... why not simply add the version number into the name of the library file, and have the program coded to look for that library. This would undoubtedly cause a bit of extra overhead, but then every program would always be able to find the library version it was looking for. different versions of the same library could all be kept within the same directory to make the file structure easy to figure out. From looking at
Note that I just picked library names out of my head, and I have no idea if there are actually any kinds of version conflicts with these libs. If you have flames about some anal little thing, send them to
I double-click on it to uncompress it.
/. /    |\/| |\/| |\/| / Run, Bill!
It's installed!
Binary packages like Redhat RPM and Debian DEB does that, but I know what you mean is automatically compiling tar package.
Really, it could be done. Double click the tar file, then system then run Configure and if there isn't any error make all. That's a thought.
It's as easy as writing a TCL/TK front end and do some exception handling from Configure and make. I'm sure it'd be much useful to incorporate this capability in Gnome or KDE desktop. Also, it'd be better to have security check in the process.
Good idea, let me think about it.
 _
Man you hit it RIGHT on. I could care less about dependencies in Linux since the package managers are getting very advanced. However, the thing that drives me nuts about Windows is when new DLLs are munged just enough to break older apps. IN Linux, the developers SEEM to care much more about backward compatability - I cannot recall having older apps break which upgrading a package - I'm sure its happened to others, but from where I stand, I'll take GNUCash 1.6 with 60 libs anyday over MS Money on Windoze which is so network bloated you can't even use it with a remote money file over a wireless link! Unreal!
Top Most Bizarre/Disturbing Error Messages
We also have desktop machines that are much more powerful than the mainframes on which Unix was first driven. Some of the space-saving strategies that seemed like a Good Idea (tm) then now seem like really Bad Ideas (tm) now. Kinda like what happened to a certain closed-source software company we could mention.
I would also mention that an associate of mine who gets front-updates on what That Closed Source Software Company (tm) is doing has told me that their .NET strategy includes a number of actual intelligent moves. One is the removal of the Variant type from the Visual Studio suite. And if that doesn't seem like a good enough idea to you, 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.
Sounds like a good idea to me. Maybe youse linux guys should like thinka implementing something like this before the Redmond Juggernaut gets up another head o' steam.
Brackets contain world's first nanosig, highly magnified:[.]
And you would change your mind when you try to open several instances of the binary and find out that you've run out of RAM.
--
Two witches watch two watches.
--
Two witches watched two watches.
Which witch watched which watch?
Some versions break backward compatability, which is the reason for the DLL Hell in the first place.
This is unlikely to change.
--
Two witches watch two watches.
--
Two witches watched two watches.
Which witch watched which watch?
Well, NIS to US-Dollars is roughly 4 to 1 (4.15 to be exact)
:-)
So you've about 1 dollar (0.96, to be exact)
I like being exact
--
Two witches watch two watches.
--
Two witches watched two watches.
Which witch watched which watch?
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'.
sound of fanfareu recomp.asp.
/sound of fanfare
Look at this page: http://www.microsoft.com/windowsxp/pro/guide/feat
Under 'Side-by-Side DLL Support' you will see that this is been fixed in Microsofts latest state-of-the-art Operating Systems already.
Effectively nuking the whole idea behind DLL's of course, but then again, they started of with putting the least used functions in DLLs and not the common stuff in the first place. So who cares...
The from the complex-software-causes-complex-problems dept. makes me choke though. Pulease...
- Download the latest package of Gnucash-1.6*.rpm.
- Do a test install to see what else is needed.
- Search for the packages that have the required libraries.
- Download those packages and do a test install to see what dependencies are missing for them.
- Perform a few more iterations of the download and test process until all the dependencies of the dependencies are satisfied
- Try to see if the existing libraries can be updated.
- End up force installing everything after doing my best to make sure nothing will break.
- Keep my fingers crossed.
There is nothing wrong with having lots of shared libraries in Linux. The more, the better. Disc Space is cheap. The only thing that gets me cranked is when the latest, bleeding edge application has a dependency on an older library. So, when I upgrade to Gnucash-1.6, I have to "downgrade" to python-2.0 because gnucash wants libpython2.0.so.0.0; libpython2.1.so.0.0 just won't do the trick. Well if upgrading apps on Linux ever became simple, I would have to switch to another OS to satisfy my craving for high risk sports. At least I can have multiple versions of a shared library co-existing more or less peacefully. I can remember the version conflicts and DLL hell that I dealt with before I learned about Linux and I wouldn't ever want to go back to that.But OK, let's compare DLL-Hell to shared library hell:
Windows: No easy solution available, you can't have two versions of DLLs at the same time. If the new version breaks something, too bad.
Linux: Both difficult solution (install both library versions) and easy solution (just wait for the distributions) available.
With Windows there is no distributor who will help you out of the hell, with Linux... well that's exactly what distributions are all about!
So please stop whining. It's embarassing how you Microsofties try to show Linux' disadvatages just to reveal even more advantages.
Roland
apt-get, dselect, et al will cheerfully rape your system when you ask for unstable software, replacing all your nice stable shared libraries and even your nice stable software with broken development versions. Never mind the security issues with running a black-box install that fetches software from the internet.
There is a "Yes, but...", however, it is fully as complicated as just managing the packages by hand.
Nothing should ever need to be "installed" to be run. Much less should it require dozens or even hundreds of files for the run-time alone, unless they can be kept neatly segregated into a single exclusive directory which can be "uninstalled" neatly with an rm -r .
I think the very idea of shared libraries is a bad one. It encourages promiscuous linking and immense run-time bloat. My view is that it is an attempt to treat the symptom (static linked executables would be too big) rather than the disease (they're too big because they're full of whatever garbage you could shoehorn in).
--
When did I say anything happens behind the scenes?
The point of my proposal is nothing happens behind the scenes. It just works
I can install apps like this in Mac OS and Mac OS X.
Also, in the Mac OS a "clean install" involves just replacing my system folder. You should have seen the look on my face when I found out what a "clean install" on Windows involved.
One thing I forget to mention in my post
The uninstall process
I grab that folder put it in trash can and delete it
It's uninstalled!
Many having been talked about Debian's apt=get. I am actually planning to try Debian soon.
How would I uninstall something in Debian?
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.
This is a serious problem that should be addressed. An answer has existed for quite some time but requires some compiler re-tooling. Nicholas Wirth's Modula-2 addressed just this issue. Once the interface of a module was defined the implementation could be changed without the clients be recompiled or even aware of the change itself. I am not advocating switching from C/C++ to Modula-2 or it's derivatives. I am suggesting that someone create a hybrid that melds the terseness of C with the separation of Interface/Implementation of Modula, Modula-2, Oberon so that we can ascend out of hell.