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.
Just because you have applications running with multiple versions of the same library from one desktop environment running under the other desktop environment with a window manager on top of X on top of an OS, what's the problem?
Gnucash has always been dependancy hell. Try gnofin, the less fat alternative. http://gnofin.sourceforge.net/
True dat. Frankly it's the first thing that occured to me when I learned about open source coding. The answer is having centralized and directed development, but that's not a GNU idea! I'd mod you up but registering is far too much care for a news recylcing site. --- Of course, I run OS9, Win95 and Win98SE so I don't really know anything about computers. I even run Internet Explorer. Even on my iMac!! I'm sure Guy Kawasaki and Linus will pee all over my grave. And I'm cool with that. I'll shut up now. Goodbye
I have noticed this too; there are just too many dll's to deal with. A possible solution, although a bit far out i would admit, would be to have all the dll's in updated for online, and when your computer needs them, it can access them in advance, and have them ready for the program to run. When they are no longer needed, they can be discarded, or saved, depending on how often they will be needed in the future, or user preferences.
Fools who ignore history are doomed to repeat it.
Actually, Amigas did it just fine. Libraries were simply backwards compatible. If a function (say stealmoney(srcAcc, dstAcc)) needed to be altered in a way that made it incompatible, then it would be renamed to something else (say stealMoneyExtended(srcAcc, dstAcc, coverTracks)), and the old function would be kept (probably as a wrapper to the new one).
Given this understanding, when you need to use a library, you simply require the lowest version that provides the features you need, and you get that version *or higher* (and thus, better) opened for you.
The same thing applied to device drivers, etc, which were basically object oriented too (if in a primitive way).
This was back in the early eighties, so come on - sort it out in Linux, guys.
self-contradictory? I read that as existentialist: "I am not (am I?)"
...to /etc/profile?
Why is statically linked libraries called "bad". What is the justification? Shared libraries are only needed where disk space and/or RAM is limited. This was the case with Windows when it introduced the ".DLL". Systems had *MB RAM and 120MB hard drives. Yes, dynamic makes sense here. But today? No. Static... is good.
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. --
Picky point, but let's chalk it up under "educating other developers..."
Starting a script with #!/bin/bash is the right thing to do, if you've (for whatever reason) used bash-specific constructs in your script. What's wrong is starting it with #!/bin/sh so that it fails halfway through running with a page of syntax errors.
Since autoconf puts in the #!/bin/sh line for you don't use bashisms in your configure.in. Please. Learn what's a bashism and what's not.
I might even go so far as to suggest that cross-platform developers install a lighter shell as /bin/sh (ash, for example). The key thing is that it's sh-compliant but not bash. Then see how many configure scripts break. In a build of GNOME 1.4, I think it's at least 4.
(I'd also -- happily! -- settle for all the commercial Unixes making bash their default. Total cost: $0. Value to advanced users: priceless. Sun, are you listening?)
--Patrick, also frustrated by how much babysitting building GNOME under Solaris requires
How about
/usr/local/gnucash/lib
/usr/local/gnucash/bin/gnucashinit.ksh
You could set your entire environment to point to an application specific lib directory and you're done.
Don't approach a UNIX problem in a m$ mindset.
But then again I use Opera v5.11 on Win98, and it doesn't go down in flames, so the OS remains stable.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
But, really, this breaks down under certain usage patterns. On a system like Debian, where package installation is trivial compared to Windows, there are a ton of packages. I currently have 694 packages installed, though a significant number of them are libraries.
Consider another pattern -- extended environments. Gnome is an instance, as is KDE. I have 12 Python packages installed, and Python by itself doesn't even do anything. I won't speculate on how large Gnome or KDE are.
I have 41 gnome packages installed (or, at least packages named gnome*). What would happen if I had 41 copies of the Gnome libraries for these applications? What if packages had even greater granularity? What if I get to choose which applets I want installed? What GTK engines I want? Hell, I don't even know how engines could work with 41 copies of the libraries.
Sym linking identicle libraries to save space wouldn't do any good, because that offers nothing better than what I have now (which works just fine, actually) -- where most libraries end up in /usr/lib. In a funny way, I suppose hard links would almost work right.
On Windows per-application DLLs kind of make sense. On Windows, people don't have that many applications installed. Each application tends to do a lot on its own. This is partially the influence of commercial tendencies (people don't want to pay for something too small), and partially it's because small applications quickly become unmanagable on Windows. But Debian doesn't have this problem, and RPM-based systems have, well, not too much of this problem. Why "fix" what isn't broken?
Next you'll have us putting application files in directories named after domain names or company names, to avoid naming conflicts. /usr/applications/org/gnu/gnucash. Uh huh.
I have two words for you: "Use Debian." Debian's package format is _so_ much better in terms of handling dependencies versus RPMs. I've never had to force install DEBs - at most, I might have to add a line to /etc/apt/sources.list, run 'apt-get update' to read the package list, then 'apt-get install <package>'. I've rarely had package installation problems, unlike friends I've known who used a RedHat-derived distro, who seem to frequently have problems with getting packages to install happily.
Really, if you are a RedHat user, and you're having packaging issues - get and install Debian. You just might like it.
_____
Sam: "That was needlessly cryptic."
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
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!"
...or barring that: just installing all of the packages related to a particular desktop. "The latest GNOME" satisfies most of the dependencies in question.
This is not what "DLL hell" is/was under WinDOS. This is actually the polar opposite: end user fright induced by being made aware of what exactly is going on and being the one managing it.
If the 5 required meta-packages have some conflicts with some older software, then this would be actual DLL-hell and cause for alarm.
A Pirate and a Puritan look the same on a balance sheet.
It can be thought of as one huge monster package that is organized as a single unit. It's not as if you have 60 completely independent subcomponents that could potentially all be competiting with each other.
What is under discussion here is not really a list of 60 components, but 5.
A Pirate and a Puritan look the same on a balance sheet.
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.
What is far more harder (and the true hell) is having avery application use bundled version of needed libraries - user can end up with system filled up with various instances (even same versions) of same library. Do the security updates in such situation!
Not mentioning the fact that such attitude completely misses the core point of SHARED libraries - being shared
Note: Of course there are some situations, where library bundling is good think - that's why we have also static linking.
hany
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.
This article claims that many libraries are re-used only if the same application is running twice. However, this probably happens more often than you would think. I can remember times when I've had 15 Internet Explorer windows open. If all of these were using completely independent portions of memory (with no shared libraries), I doubt if a 128 MB system could handle the load. Furthermore, consider the case of Linux, where nearly ALL applications are linked to the standard C library. To run a quick test, I compiled "Hello World" both statically and dynamically linked. The shared library version was just under 12K, while the statically-linked version was slighly under 1 megabyte! Imagine if every little utility in Linux - cp, ls, touch, chown, date, df, echo, more - were statically linked. Just this extremely minimal set of utilities would be larger than Netscape 4.76 statically linked with the Motif libraries! Furthermore, look at the difference between the statically and dynamically linked versions of Netscape. The static version is 7.69M, which is almost 33% larger than the dynamic version, weighing in at 5.8M. The author claims that dynamic libraries do not lead to significantly smaller executables, but I consider 33% in this case to be quite a significant difference.
I admit shared libraries can be a pain when not widely distributed. I recently wrote a simple GUI-based program in Visual C++ 6, which links against the latest VC runtime library. When I gave this to the person who had asked for it, they were unable to use it because they did not have the latest library. For the sake of simplicity, I made a statically-linked version and was amazed when my little 400K program started approaching 5MB in size. Transferring such a program over a dialup connection is not fun, and to do so more than once because of statically-linked libraries is both a waste of time and space.
I remember several years back when I first wanted to install the Enlightenment window manager and having to compile and install about 10 different programs and libraries just to get it to work. It was a pain, and I thought there should be an easier way. When a program uses a library speficically written for that program, and with only limited usefulness outside the realm of that program, I think static linking is acceptable. However, doing away with shared libraries altogether would be foolish and shortsighted.
Just my opinion. If my figures are horribly inaccurate, feel free to correct me.
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"
Unix (and hence Linux) also allows you to have multiple versions of libraries installed. Take a look at /lib and /usr/lib directories some time. You'll see things like:
libfoo.so.x.y
libfoo.so.x
libfoo.so
libfoo.so.x.y is the actual library, and x.y is the major/minor version (it might be x.y.z or whatever). Point is that you can have multiple versions of those installed at the same time. libfoo.so.x and libfoo.so are symbolic liks to the actual library. An application can use either the default library (libfoo.so) or it can specify the version.
DLL hell occurs in Windows precisely because multiple versions of libraries cannot be installed at the same time. So if app1 needs foo.dll version 1.2 and app2 needs version 1.3, one of these will not work. This situation generally does not occur on Unix as long as the library developers bump up the version when they change the API.
___
___
If you think big enough, you'll never have to do it.
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.
Dammit, I know that disk is cheap, but this makes me start wondering if the conspiracy theorists aren't bloody right! (Intel/Microsoft -- sell the OS and apps to sell new hardware, which of course comes with an OS... How many people would buy a bigger drive, vs just saying that their computer can't handle it and buy a new one?)
I mean, is this really the right answer? 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.
-30-
I'll be honest -- from a technical standpoint, it's the best way to make a broken system (Windows) work without fixing the technical problem -- that you don't link against a version of a shared library, you link against a filename.
Honestly, the concept of having to keep N copies of a given file just offends me on some level... it just seems inefficient and wrong.
Really, how is it that my uber-l33t 1.2Ghz Athlon feels slower than a 2.8 Mhz Apple II running a program with the same basic functionality -- a word processor? Just needed to get that off my chest. </rant>
-30-
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
If you're smart as use Debian:
apt-get install gnucash
done.
seth
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 fully agree. These guys have brought the software a long way since I started using back with 1.2.5 (thanks to a slashdot article abuot it :)
The "60 libraries" quote is actually just the output of `ldd gnucash | wc -l`! Guppi contributes 8 of them, ORBit contributes 4, etc... It really only requires 4 packages or so that aren't part of the standard Gnome distributions.
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)
Developers should take a bit more care to check which versions are absolutely needed to get their programs compiling and running, instead of forcing us to upgrade to every new library.
I don't believe for a second that Gnucash uses bleeding edge new functionality in every one of the 60 libraries it is dependent on.
- the Crazy Fraggle
Seem to me that you need a VERSIONINFO-like tag inside Unix modules (and perhaps static libraries, unless the library format can) so that unrelated facilities like the OS installer, package installers, and dependency-driven builders can all avoid stomping on the new versions of things.
I guese the essencce of problem with gnucash is that wants some .so's with are are at least planned to be compatible with existing versions, so in theory, if they were all working, nothing would break. But if they really are not ready, they've got to be put in a place that's private to gnucash for the time being...
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.
This is why systems like debian's apt-get that automagically satisfy dependencies are good. Granted, 60 is a lot!
Excellent idea! Now, how do I tell this to the non-configurable installation program which will install it in %SysDir%?
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.
Since ca. 1970, in fact. (Was Gates even born then? I wasn't.)
Err, yes. Unless he founded Microsoft when he was 5 years old.
Thank god with Linux you can actually DO something about bloat. Linux user skill (on average) has gone from mainly very compentent to mainly 'whiney-ass Windows lusers' in a suprisingly short time. Right now you can configure your particular setup as you see fit, removing programs and areas of the filesystem you don't use. WTF is wrong with that?
--
Delphis
Delphis
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)
--------------------------------
I don't really worry about library hell, cause I use Red Carpet from Ximian. It's free, it does security updates and such, and it resolves dependencies pretty well. I think linux really need more auto-updating software to make it less work to run. Red Carpet is just like Winders Update, cept there's a BUNCH of software available and I don't worry about anything breaking.
I like Ximian so much, I even bought a shirt from Think Geek. Hold me down...
-=nft=-
"We must be the change we wish to see in the world." -Gandhi
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.
haven't been able to successfully compile it, or install from RPM.
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!
A developer can't really win, though - if a statically linked version of gnucash was released, the story would be "damn, this free software is so bloated! etc.". Heads you win, tails I lose :)
Most of the Gnome 1.4 stuff is actually from Ximian (at least on my system), so you just have to wait for Ximian to pick up gnucash as a supported package, and then their installer will automagically set you up with it. You can either have the software right away and go through some configuration headaches, wait a little bit for it and avoid the configuration problems, or if you're really in a hurry you can pay a gnucash developer to build you a special staticly-linked version. Unfortunately, you can't get software with no configuration issues without waiting and for free.
Caution: contents may be quarrelsome and meticulous!
Your right to not believe: Americans United for Separation of Church and
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.
...but unwieldy (and of course buggy). However, I find that COM/DCOM neatly solve this issue with little hassle (from the users point of view).
Programming that cr@p is a whole other issue: one that makes me ill.
I am very small, utmostly microscopic.
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.
This story isn't about GnuCash, its about the problems that can arise with shared libraries. GnuCash was just an example.
...
.x upgrade. Generally, the only .x upgrades that get mentioned on /. are kernel and xfree updates. If every little version upgrade of every little program that someone thinks is important was announed on /., it would turn into Freshmeat.
how they've released a significant new version of a key Linux application
You want some cheese with that whine? Its only a
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 wish IBM and others hurry and get those PPC Linux boxes on the market.
photosMy Photostream
(I dabble, but I do ass-sucking VB in uncle-humping Windows to pay the bills)
You too, eh?
I hate windows, and I hate VB and VBScript even more.
I come home from work everyday rubbing my a$$ from getting bent over by IIS.
all your Recordsets are belong to us.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
I'm surprised more people don't use it ... it's really useful for managing multiple versions of libraries and different applications which depend on them. Unforuntately when you start hitting C++ class interdependencies or zillions of versions it starts being tricky ... which is where namespace managment and scoping rules become more important.
LL
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
Linux is already there.
I have discovered a truly remarkable proof which this margin is too small to contain.
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
Well, it means that the application _can_ bundle all the libraries it uses, but it doesn't _have_ to. I believe early betas of OS X, OmniWeb (really cool browser) used to make you install OmniFoundation.framework or something like that, which contained a bunch of code that was shared across Omni's apps.
However, it definitely makes things easier to install if the frameworks are included with the application. I'm not sure if the loader is smart enough to only load one copy of OmniFoundation if two of Omni's applications are running - I think it is, but I could be wrong.
Check out DRM-free movies at http://www.bside.com
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
For instance, Shane Nay and I implemented old-style Linux a.out shared libraries because of significant overhead in MIPS PIC code. There's no dynamic linking, but boy does it run faster. Some people are playing with dynamic-linking applications into a common base executable. And so on. Maybe these things seem silly on a desktop box, but this kind of embedded environment is clearly not a desktop box....
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 know if this is a myth or once was true but I heard that dll's can be shared, but exe's cannot.
No, it's not true. Modern OSen utilize a technique called memory-mapping of files that allow the code of an application to be shared among its running instances. Only its private data areas (data segment, stack, and heap) cannot be shared. So, much of an executable is still shareable in memory between instances of it.
Yea if linux only ran on one processor/chipset then installing a program could be that easy.
If OS X supported x86, PPC, Mips, Alpha... not to mention all the chipsets and other hardware the I think you might have an argument.
Sure if all linux boxes had the same video card (like your macs) then it might be easy.
But just like our founding fathers, I would rather have freedom than ease of use.
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.
Hmmm... increase loading time? Imperceptibly if you use Rebase and Bind to tidy up your DLL use.
Unnecessarily chunk up your program? Not if it's done on functional divisions; one big advantage this has is that you can in-situ replace DLLs that are faulty by ONLY replacing the DLL - not the entire file (which software designed to patch files might not necessarily be able to do).
Besides... who's worried? I've been told since 1998 by all KINDS of people that Linux has never and NEVER WOULD have ANY problems of this nature, because it's not fundamentally flawed like Windows. Surely they weren't all wrong?
Simon
Coming soon - pyrogyra
I don't see what the problem is.
I don't want knowledge. I want certainty. - Law, David Bowie
There is no actual place where the programs look for the libs. Dynamic linking is handled by the dynamic linker, which has a list of places where libraries are found (often /etc/ld.so.conf).You can edit this and run ldconfig -v to update your list.
If you wish to use a very specific version for a special application you can always set LD_LIBRARY_PATH before starting the application to ensure it gets the right libs.
a few systems have good solutions for dll/so madness ... though good design really reduces the problem. for example, nextstep and apple's os-x use resource maps/app packages so the shared objects are mapped properly in the application package, and can be stored there or in the system packages. tru64 uses a filesystm/kernal .so versioning scheme ... that allows multiple versions of libraries to exist and be served somewhat sensible. and i am sure there are others. luckily, linux has the potential to improve the library hell ...
mx
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
Just say apt-get install and there's no hassle.
amen to that!
but remember most people have no idea how actually powerfull that can be.
Elephant: a mouse built to government specs
-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
Windows has DLL hell. Well, so does Gnome. Gnome tries hard to emulate windows in all ways.
Look at the motif version of gnucash - how many dependencies does that have?
Me, I write software with minimal dependencies. Often just the C library, but sometimes libraries like GTK or SDL.
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.
Actually, building non shared code as DLLs is very useful for testing. It's also a good workaround for the 'lot's of developers need to work on the same files' problem that VC++ tends to have.
Also, building as DLLs contributes to code reusability within an organization.
Lastly, OCX's, VBX's (are they still around?) and ActiveX controls are great ways for closed source companies to distribute modules, since they avoid the link-time incompatibilities that plague Windows compilers. All of the above are of course just gussied up DLL's.
I won't argue that many Windows developers are downright clueless though.
-Loopy
It's very simple, you run a more minimalistit system, one based mostly off console apps, leave gnome and kde on the ftp sites because they are bloated unstable piece of crap. The key difference here is that you aren't forced into having all that crap on your box. Heck if you wanted you do an install that was less than 100MB and still be able to anything you needed to
"If you love someone, set them free. If they come home, set them on fire." - George Carlin
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...
> In some situations this might be a bad thing. But in a great many situations it is actually a good thing.
What?! Defending difficulty of installation because it makes being a sysadmin easier?! Why not just avoid giving your users root access, but make installation easy for the who can/should do it?
All opinions expressed herein are not my own; I haven't had free will since last year when aliens ate my brain.
You make some good points, if one assumes that DLL's are used as shared libraries - same code used by different programs. That's the intent, and it happens of course. But on the other hand, it also often happens that some software package uses a number of DLLs that were written specifically for that package. That wouldn't be a problem if they would be installed in the application's directory - but often they are installed in Common Files or System or System32 (a lot of Windows developers seem to think that's the easiest or only way to make sure the DLLs can be located at program start). Which is one of the reasons the system partition of a Windows system keeps growing and growing, and you can't do anything about it except format c: and reinstall.
This sig under construction. Please check back later.
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.
Real DLL hell is when applications start installing their own versions of shared libraries because they were linked against that particular version and are binary-incompatible with other versions. For an example, see practically any piece of commercial Windows crap you can find.
In the free software/open source world, this isn't really an issue. Sure, it's possible to link in such a way that your program will attempt to run against a binary-incompatible shared library, but half a clue about library versioning and a tenth of a clue about linking is all that's required to fix this.
And the best part is: if it doesn't work with the shared libs on your system, just rebuild it! Free/open-source software doesn't *need* to ship with its own version of any shared libs (.dll/.so/whatever) because it can be re-linked against the proper revision of the library if the binary API changes. You're still screwed if there's a major change in the headers and library interface (the source API, so to speak), but no technology is ever gonna fix having to rewrite programs when there are major changes to the publically-accessible/used functions and data structures of a library...
File this under "reasons why commercial software sucks"
</hat>
Mike Markley - *NIX Sysadmin and all-around geek - finger for PGP key
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
Static linking has a lot to recommend it.
Yes, it uses more disk space. Disk space is cheap nowadays. But it reduces the hassle factor enormously.
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.)
Don't even need the floppies, I put debian on my old sparc IPX with just the network (boot image fed into forth with tftp, NFS mount the root filesystem).
--------
--------
WWGD? (What Would Goku Do?)
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
You are right about the linker only loading one version, and more than that, it loads the newest revision of that version on a computer. For example if my system folder has lib Foo version B.0 and program blue has lib Foo version B.1 in its shared lib folder (in the .app package), when program green asks for routines out of Foo version B the linker will use B.1.
This allows for there to be both major versions (incompatible) and minor version (compatible) of any package on the system. There is a lot more to this new linker, and a lot of it is still in progress.
Apple has been going more and more with the regular libs because people are complaining that newer version of the library don't work, or that they want newer features. Apple is working at making this seamless, but at the moment it is in a bind, spend the resources to make everything compatible (slowing work down), or get a version that works out now, and then go back and make it better...
This is actually the only real solution. Static linking solves the problem, nothing else does.
Thats it end of story.
The previous post should have a few more mod points.
and why does an app (such as Eurora) crashing bring down the whole system, or require a reboot to get things working correctly again.
Any app that doesn't directly access hardware should not be able to do that.
Seems like crappy memory management to me, but I'm not a windows programmer so I dunno.
I'm not trying to disagree with you, I'm just curious why this is the case with windows.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
The introduction of MSI (Microsoft Installer, aka Darwin) eliminates DLL hell on Windows with applications that use it. It is a system-level, centralized installer, and as long as applications use that to install themselves, then the system can keep proper records on installed components and their versions.
/etc. Linux needs the same concept of standardization and centralization that Windows brought to the MS-DOS PC with mechanisms such as DirectX and the registry.
Before MSI, every application had to use its own installer, and each installer might or might not be so smart about checking for versioning / existance of DLLs before forcibly overwriting newer versions with older versions of the same library or blowing away a more recent registry key.
In Linux, you don't run into as many installation nightmares because you don't HAVE installers to take care of installing shared libs for you--you're expected to be smart enough to install those yourself along with the app, and you're expected to handle versioning of libs appropriately via symlinks and so forth. But Linux, like Windows before MSI, lacks any centralized database of versioning information, so if you're not a dilligent & careful system admin type, you can get into the same scenario due to human error.
GNU/Linux desperately needs some central, standard repositories of data and methods of acting upon them within the system, accessible to all applications, and application authors should be motivated to go through those central repositories/methods rather than bypass them and write their own ways. GNU/Linux is currently just as disorganized as the old MS-DOS era, when every application author wrote their own video and sound driver code from scratch only for certain supported hardware, or relied on such libraries as VESA for some lame level of standardized support. Those MS-DOS apps each had their own config files, sometimes in human readable form, sometimes in binary form, sometimes in script form, just as linux apps today all have to dump differently formatted config files into
- "It's just a matter of opinion!" - PRIMUS
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
That's a succinct way of wording it. :-)
/me is just downloading Mozilla/0.9.9.9.9.1. They haven't yet pushed the version number over to /1.0 yet because there are a few bits to go.
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.
What about loading with GUIDs, like COM, instead? Then you can still patch and bugfix libraries like j7953 said.
... then no one is actually *computing* the checksum. So it's no different than an arbitrary number. .... and What if two different DLLs have identical checksums??
Besides, if the checksum is the filename, and hard-coded into the app
-------------
The following sentence is true.
The following sentence is true. The preceding sentence was false.
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?
when you can use Yahoo!Finance and it's expense manager. granted, i'm not sure i like the fact of a "company" having access to my expenses. but it is the most convenient thing in the world. =)
and enter apt-get/dpkg heaven!
The current Slashdot moderation system is made by gay communists!
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.
I miss the Amiga's centralized library directory... But I've stopped cracking RC5 keys for their team.
Someone set us up the bomb, so shine we are!
Image the bloat hell we would be in if everyone linked their projects statically to libraries.
Not that I know diddly squat about Linux (I dabble, but I do ass-sucking VB in uncle-humping Windows to pay the bills) but how about a master virtual directory thing. Some kind of central master file locator. A layer of abstraction with some intelligence for browsing or whatever. Obvious? Been done?
Why must everything in Linux be installed as root? Why can't RPMs and other packages be installed in my home directory and 'just work'? When you're root you can really screw things up for other users. I use Linux in a university environment where there is professional support staff. Thus, end users are strong discouraged from installing things as root. Trying to install new Linux software in my local user directory is almost impossible with some packages.
NEXTSTEP (now Apple's OS X) does a much better job with this. They have the concept of an application bundle (which is just a folder) that you can install in a system wide area (/LocalApps/) or in your user space (~/Apps/) and the application works the same either way.
Seems to me that apt-get install works quite well, even when the dependencies are hairy. Assuming of course that the packager knows what's really necessary...
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.
That's not DLL hell because you don't risk an application overwriting the new version with an old version, breaking other applications in the process. And when they are not being actively used (i.e. most of the time), the libraries only take up disk space, which is dirt cheap. They don't slow down the whole system, like they seem to do in Windows.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
It stops when hardware capacity and speed doesn't anymore increase exponentially. As long as it does, it's simply cheaper to make bloated software, because coding efficiently takes more time, and time is money.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Trust me, if you didn't use any shared libraries at all, you'd very quickly bump against the limits of the 4 Gig of memory that a 32bit machine can physically address. Besides, why buy more meory if there's a simple way of making do with less?
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
uh, i appologise if someone has mentioned this before but i havent had enough time to read all the posts. what has been buggin me for the last few days is the complexity of package management. i mean, in my very innocent pov as an apprentice, when we look at the tasks we have to perform there are like 2 main ones:
/usr/bin/gnome as a symlink, same for docs etc.
/usr/package/gnome/app_name/ (this is where all the stuff really is); this folder contains symlinks to all the libs the app needs
1) make sure all the dependencies are met
2) make sure we keep track of all the files we've installed.
what i fail to understand is why can we not solve 2) in the same simple way we've done the init scripts... why can we not have:
-/usr/lib/gnome/lib_name/ as the location of a gnome shared libs; the different versions of the lib go on the same folder
- every gnome binary under
- all programs are installed in something like
so that when we install a new app, we have some dependency checking, but when we want to uninstall, its just a case of running a script that 1) deletes the symlinks 2) gets the number of symlinks referring to a lib, and if a lib has no symlinks, deletes the lib as well. this way, we could have our src tgz's with dependency checks and we can easily uninstall them as well... what am i missing here?
soup, the dragon.
soup, the dragon.
dna.h:include "std_disclaimer.h"
If users don't understand what they're doing, then why do they have root access? If they don't have root access, then they can't screw with system files.
... with a little better installation interface... but check out Progeny Linux, they're working on that.. RPM sucks :-)
I can't tell if they were in 7.0 (I'd guess so).
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".
Video = graphics. Otherwise he'd have said "video capture" or something.
The streets shall flow with the blood of the Guberminky.
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?
Well you've brought up a good point about a lot of development that's going on under linux right now. IMHO the best way to ensure that we don't damn ourselves to dll hell is by setting up a set of requirements that all library authors have to follow.
First of all, the interface to all functions and classes in a shared library MUST be backwards compatible with previous versions.
Secondly, some sort of package manager, that could connect to an online repository containing every major shared library (something like CPAN) in order to ensure that libraries can be acquired, upgraded, and repaired easily without reinstalling a product.
A third solution to the DLL problem would be for an application to store all the libraries it uses within its own tree. Although this is redundant since several programs may use the same shared library, it ensures that an application's libraries will never be affected by the installation or removal of other applications on the same system.
Basically, to all you developpers, if you're going to use shared libraries in your products, be responsible with them and never assume your app is the only one on the system. -Mike
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]
.. to use so many libraries?
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.
It has it's own DLL HELL which has nothign to do with Microsoft. There are just many people who are too stupid to understand something similar isn't always the same.
Then call it something else.
This way people are reacting like:"Oh look, Linux made the same mistake MS made x years ago, and which they already fixed by the way. Linux is so stupid, and Windows is so much more advanced."
using 60 libraries (which get installed by default anyway) is not so terribly bad in my book. But if you thisnk this is an wrong and an error, then it's a GnuCash-error, not a Linux-error.
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.
Or YooHoo and FooBar are now royally hosed because the clowns who wrote them had it hard coded in for a specific library so anything outside of that library version won't work unless you enter symlink hell and set up links to the NEW library just so the retarded old program will work properly.
Just went through this myself with a SNES emulator. Needed a new SDL libary. Once the library it need was installed, several other programs were hosed up due to them not looking for versions >=
---
Hehe, I can just hear the discussion in a conference room in Redmond... "Screw the Netscape users!"
"Rub her feet." -- L.L.
I ran cdEX for over a year w/o problems.
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.
I double-click on it to uncompress it.
This shows a Gnucash folder.
It's installed!
You can.
Archive, System and several other applications install like this. You just need a filer that supports it.
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
WTF is wrong with statically linked binaries? The authors get to play with dependancies, and the user gets a binary that works. If you wanna fuck about with your own library combos, compile from source, since you're obviously an expert.
Just wait till all the shitty windows developers
start developing for linux. Then we'll talk.
Anonymous posts are filtered.
I think from the start GNU Cash is a broken design. The last point I checked there was Perl, C, Python, and all kinds of strange combinations for the application.
Very few apps on Linux have such weird requirements. What GNU Cash needs is a total rewrite in Java, and make it a servlet design so it can be web based, far more portable and built with a object design that eliminates a lot of really bad code that is in there.
What I don't get is why people insist on using Administration or poorly built scripting languages to build applications for Linux.
As I see it, if you want to build a app now days, for the web, its server side java and XML.
If you want to build a game or Office Suite I would stick with c++. (i.e. Desktop Apps).
I wouldn't build it like Gnu Cash with umpteen different programming languages, many of them never designed to do what they are doing in GNUCash.
I mean, GOD, how can you track the bugs in something like this?! You would need 5 different debuggers running at the same time!
-hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
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).
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. Sure you can! just put the dll in the same dir as the app, when looking for libs, windows always look in the dir of the app first, then in the path
if (!signature) { throw std::runtime_error("No sig!"); }
well, then you move it by hand after installation... oh, and you better have some backup of those older/newer versions of the dlls that the installation program, so you can restore them after the install.exe done it's mayhem ;-). bit of tinkering, but it works....
:-D
Not claiming that this is the optimal way of doing things, mind you...
Hey, looks like Mr Bush JR created some sparks back home in Sweden!!
if (!signature) { throw std::runtime_error("No sig!"); }
First off... this isn't DLL hell, it's update hell. It's not DLL hell because Linux doesn't have that problem, since it keeps all "in use" versions of every "DLL" that ever existed. So, you'll never have the problem of apps that want differing special dll versions and not be able to get them working....
/usr/local/lib. If you're feeling promiscuis put it in /usr/lib. It's a security thing. Any program that doesn't find a library in one of those two places (given a non trashed distribution) doesn't deserve to run successfully.
As for where to put libraries... it's one of two places. If you're feeling prude, put it in
Next, there is a problem here. It's the fact that the makers of GnuCash (if they want a production/useable version of their product) should make a distro that includes all needed libraries, or at least an update on their site with all the needed libraries. This would make life easy for all of us in luser land out here who might actually want to, gasp, *use* their program.
This is one reason I use Debian, once a package is on their list, it will grab everything you need with it automagically. Assuming of course you can get through their half assed effort at an interface called dselect... no update hell there, of course the latest gnucash available from debian's site is 1.3.4-3. You could try something newer off the GnuCash site if you want... but uh... good luck.
Now, to aleviate the last problem that of cluelessness on the web in general as well as here on Slashdot, maybe we should require a course called "denewbie" as an addendum to the GPL. That way people would know this stuff or they'd be running Linux illegally!
Oh, wait a second, I almost forgot. LINUX DOCUMENTATION SUCKS!! The closest thing to it is a bunch of MAN pages and HowTos that quite frankly require an expert to even BEGIN using!!!! (note: If anyone has some docs they think are readable... please tell me about them, and I'll be happy to *review* them. I'm talking about whole system install and use from the ground up docs here.)
(JoeNewbie_Rant)
Um... I've been a professional C/C++/x86 Assembly programmer on dos/windows for 5 years. I just bought this new CD that says "Red Hat" on it cause I heard it was neat.
What's this super user account thingie the install wants me to make... and uh... why should I need another account anyways?
And uh... Now I"m running enlightenment and I want to install the latest version of this neat app I found called GnuCash, but I need 60 libraries that I have to download one at a time cause I don't know any better way to get them. By the way, what does "unstable" mean?
Since I didn't understand what windows DLL hell was in the first place, maybe this is shared library hell?
Also, once I get the libraries where the heck do I put them. I've heard the directory is called "lib", but which one?
/lib
/usr/lib
/usr/local/lib
/var/lib
This must be a problem in the Linux directory structure. It should just have one folder like windows has. Hey, we could even call it "System"!!
(/JoeNewbie_Rant)
For any interested parties... in all intents and purposes I *am* (or was) Joe Newbie in this case. I was a programmer for 3 years professionally before I started using GNU/Linux/Unix/BSD. It's been a year and a half since then, and I'm still learning a lot of things. Now, I haven't had time to devote to *work* on linux, I've just tried to use it in a useful way, so that eventually it'll save me enough time that I have some to *work* on it. I figure that's a fair tradeoff. But so far, documentation has always been on the lacking side of the fence, quite close to his brother standardization actually. (Currently I only use Linux on internet appliances... you know, file/web servers, firewalls and the like, I've done no more than *play* with workstations)
I've seen tons of crashes caused by IIS, J++, and Microsoft Message Queue. All written by Microsoft.
Of course, today, that programming seems like it was in another age. I think the only one of those still around is IIS.
and its the only reason I stopped using it.
.tgz's had some compilation error.
.isos, everything is out of synch, and installing any given package is more likely to fail than succeed. Ok It was probably based on my choice of distro, and it might even be better today than it was, but I'll still wait a year after someone thinks its smoothed out.
Find that most packages for mandrake would not urpmi correctly, and had failed dependencies. Most
Basically, except for the
Some of you will now promise that Debian's package database is always in sync, and mistakes in it never occur. So does apt-get really always work?
Ok, take a step back and look at the big picture... eventually Linux is going to be as simplified as Win*. When that day comes, do you want people to bitch because the only way they can keep their system clean is to install from source?
On the flip side of that, MS actually seems to have gotten their shit together as of Win2K, why not just rip off their innovation and implement a similar system for libs in Linux? I'm sure if Linux had done it first MS would have no problem borrowing the idea for their own OS.
---
Hammer of Truth
>I can't get Mozilla 0.9.1 because it wants
>Glibc2.2 - which I can't install without putting >at risk my system.
Uhh? Mozilla 0.9.1 works fine with glibc 2.1.
>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.
There's no good solution that I know of. Upgrading
from libc5 to glibc2 was a major pain. The easiest
way is to install a new distribution.
Glibc 'upgrades' happen very infrequently just
because of this reason (libc5->glibc2 was the
only one I went through and I've been using Linux
since 1.2.13) The main reason for that upgrade
was localization and threads support. If you
didn't need either of those, libc5 is still fine.
AFAIK there is nothing that needs a glibc2.2 right now.
--
GCP
Which do you want? I'd rather take the former. Reducing the amount of redundancy in programs and advocating the concept of reuse is a GoodThing(tm).
Use apt.
the idea of "STANDARD" libraries on a linux system, although needed, are against the ideals of the slashdot community, because linux is "freedom" and a standard set of libraries would mean "conformity".
bitter about what may I ask?
I would love to see a stable, standardized, version of linux, unlike the countless shitty distributions I have gone through within the last week.
BTW. Kylex dev edtion is only $199. With this compiler becoming more popular, you will start to see ALL BINARY versions of linux (because people are no longer forced to use the GNU license)
I learned some time ago that the "easy to upgrade" line so often attributed to Linux was not quite true. This RPM won't install until you get two more, each of which also have a couple requiremnet, and so on, until your practically upgrading the whole system (and spending all week combing the internet for the files) -- and its usually not long until something is required that just doesn't work or can't be found.
So, I went to compiling from source so my binaries and libraries would be generally compatible -- that way I only needed four other packages to upgrade one....
Putting code in libraries for re-use sounds really good until you realize just how interdependent everything has gotten.
Speaking from experience, I can tell you that Perl will install under your home directory, and still play nice with others...
For a while, I had copies of 4.036, 5.005_5, and 5.6 (gawd, I love the new Linux-like versioning) all running under my home directory, for testing purposes...It made the quota police very unhappy, but it worked just fine. =)
I just want to take over the world...Why does that automatically make me EVIL?
I think that this project might be the solution to the above-mentionned 'shared libraries hell' problem. http://www.gnupdate.org/
This is a good push in the right direction...BUT!, there is one thing missing...and its always missing from these conversations! Could we please make up our minds where libs belong. It seems like every new version of some programs, look for the libs in different places, every new version of the libs put them in different places, and every new distrobution puts them in a different place. I can't remember the number of times I have gone to upgrade a program that someone wrote to the lastest version, but the programmer wrote it to use /usr/lib for the libs that he also wrote, but the distrobution I am using decided they liked them better in /usr/local/lib. So now when I compile the program despite compiling the new libs for it as well, it keeps finding the old ones. Even windows is fairly good about this keeping most dlls in system32. Even worse is when the lib has been symlinked all over creation.
I lind this often with the gdk libs.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Microsoft makes plenty of buggy, crash-inducing software all on their own. But your protests regarding the stability of a clean and pristine Windows NT are pointless. The real issue is the stability of systems configured to do real day-to-day work. When that is considered, Windows is much less stable than several alternatives. Period. The truth will out.
I've been asking this question for years and that's the part that frustrates me the most about Linux. Solving this would be a huge step forward for the OS.
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.
--Mike
"Not an actor, but he plays one on TV."
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)
some sort of quasi non Apple-lawyer-bait version of the plugin system used in OS(insertnumberhereorromannumeralhere) should be devised for linux. I think that would solve this problem
"It's not stealing if you don't get caught!"
"It's not stealing if you don't get caught!"
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
When you create a package of the software, the
library dependancies are gotten for you by the
packaging tools. It's just a matter of installing
everything it needs and building it. After the
packager does that, everyone else out there who
wants to use the software can just run "apt-get"
and Everything Just Works.
It is better to use libraries than "reinvent the
wheel" and thus have a lot of programs with
unshared mostly identical code in them taking up
RAM. At least on a decent Linux distribution
with good package management and up to date
development libraries available, you can get
a very high level of code sharing going on.
This is in contrast to the Windows environment
where every vendor has their own proprietary DLL
and very little code sharing can happen between
vendor's softwares. That plus there is not any
central package management system in place, afaik.
I've been talking about this for years. It really just a name space problem. There is no reason not to have all major version of sahred library available. If a program needs a library version so-1.2 then there it is. If another progam needs so-1.0, well thats there too. Over time you can purge very old libraries if they are no longer required. NOW IF WE CAN JUSYT WORK TOGETHER TO MAKE THIS HAPPEN! (P.S. Windows XP has this feature. --No more .dll hell.)
:T:R:A:N:S:
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...
How would I uninstall something in Debian?
apt-get remove foobar
If you're selling a product on a CD-ROM, despite the fact that the DLL will be thrown into a compressed cabinet, you would have a strong incentive to keep your binary reduced in size.
Hard drive space may be cheap, but CD-ROM space is somewhat more costly. But then, you may not have this problem if your program isn't that large to begin with.
Furthermore, occasionally you must reduce the size of your executable to allow it to transfer across a network more quickly. For some of the work I do, the binary is usually executed from a networked sharepoint. Bandwidth, therefore, is a strong motivator for me to reduce filesize.
That said, I agree with the bit about the Black Box. I sorta suggested that in my original comment, but you nail the point more clearly than I did.
As for VB... in my dev environment, we're doing everything we can to forget VB. It's a nightmare... evil, right down to its rotten core. Can't localize it easily, can't debug it without putting your legs behind your neck, makes it easy to create truly screwy controls with ugly looking dialogs, and you have to bind to it using COM if you're working with C++ (an ugly problem if you want to work across a network on a machine that hasn't "installed" the VB dll). Just say 'no' to VB. I'm sure there's a 12-step program somewhere <chuckle> .
And now, after having written all this stuff about shared libraries, I just happened to notice my signature, and got to wondering about Mr. Franklin's prescience. Or my own, for that matter, to already be using such a sig.
And so it goes.
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.
> 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.
Granted, bad things can happen in unstable. I still consider it more stable than any of the commercial distros.
Moreover, there is testing now, have you tried it? I've yet to see a better trade-off between freshmeat and stability.
> 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).
Feel free to link everything you have statically. Remember, only the really used stuff is linked in then.
Let me know if that uses more or less resources...
--
--
Free Software enthusiast; Debian GNU/Linux (powerpc) developer
Of course, application developers can't really assume that people are running Win2K, so it's not a particularly useful solution quite yet. (Boy do I wish we could assume 2k, that'd make writing windows apps two or three times easier)
Kinda scary. DLL Hell has _long_ been a regular part of dealing with windows, going back to at least 3.1 (my first experience with it). Today it doesn't seem like as big a deal, I'd guess primarily because available file space and general system resources are so much higher than in those days. Still, the number of random dll files in windows is shocking.
I hope some sort of solution is worked out for linux. One of the things I've always liked about linux has been how you have the option of running a very streamlined system W/O tons of junk files laying around.
My experience with newer versions of RedHat (and stuff like Gnome in particular) don't really follow that so much anymore. It seems like just about every app beyond the certain core set requires like a million dependencies now.
Maybe there is a better way of keeping track of, and storing all these libraries?
Scott
I wouldn't worry. I built my own distro around Glibc 2.1. When I upgraded to glibc 2.2 I had literally *no* problems at all. The fact that it didn't come with libdb threw me for a loop, but you can download and install that that seperately.
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.
Yes, there is a very easy solution. Static linking. Take a look here for a discussion of why DLL's (and the analogous Shared Libraries) might be a promise that simply hasn't panned out.
Onorio Catenacci
--
"And that's the world in a nutshell -- an appropriate receptacle."
--
"And that's the world in a nutshell -- an appropriate receptacle."
-- Stan Dunn
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.
Yes, you can. At least with Win2k you can have multiple version of the same DLL loading simultaneously. Try doing a little research.
It's embarassing how you Microsofties try to show Linux' disadvatages just to reveal even more advantages.
You mean as embarrassing how you 'Linux zealots' need to lie to promote your agenda. Get real, look in the mirror, and lose the inflammatory rhetoric. Those with their own agendas tend to see opposition in everyone else's.
While shared libraries are evolving, there is greater likelyhood that folks will mix versions. True for Linux, true for Windows. There is no idiot proof fix.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
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)
Great so you have localized storage of different versions and possibly localized loading of different versions.
.net becomes .not
"your binary has to ask for a particular, or minimum, version of the dll"
So with XP M$ will finally "try" (its not out yet) to fix their F**K UP versioning. How long before the majority of apps are "AWARE" of this "innovative feature"? (hint proper version control has been taught in software engineering for over 10 years).
Do you know why XP has to have this?
otherwise
Server has one version and the clients have other versions.
This sig space tolet, reasonable rate.
Just my little rant for the day...
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
Would it be easier if there were some sort of central authority keeping track of libs (keeping track, checking for conflict and overlap). I am also led to believe that all of this code does not need to be linked. I prefer to have one big binary, over a small one with 12 libs.
This sig intentionally left blank.
Try comparing the size of glibc without debugging and full optimizations, you'd be surprised how much it shrinks. Backwards compatibility is nice in the short term, but in the long term in order to embrace the future we have to let go of the past... sorry to break it to you like this.
Download glibc-2.2.2.tar.bz2, run configure with your preferred settings, make and then install. BOOM! After that you got glibc 2.1.x and glibc 2.2.x installed at the same time, and the applications that need one will use it, and the ones that need another will use it. Also, you could always just install mozilla from source.
The evil empire is our enemy, or atleast mine ;D
But whats the use of war, just use what you like and feel happy with, thats the most important thing if you ask me.
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....
A possible solution is a ports system similar to the one used by *BSD. The software that you want to install could come with a list of required libs. The ports system could download and install the necesary libs, and Bang!, you're done. When you no longer need the program, use the same list to uninstall the libs that were installed for the program.
Yeah you. Stop writing programs that require 60 libraries, please!
The GeekNights podcast is going strong. Listen!
i your using the ports colection and you do cvsup once in awhile. cd /usr
cvsup cvsup-file
cd ports/security/dnsiff
make install
make distclean
all my dependencies are check for newest versions and re-installed if nessisary.
Chris Lee
lee@mediawaveonline.com
How can everyone agree to make libs compatible, backwards compatible, and standard? Isn't there some way to accomplish this?
samrolken
This thread reminded me of an interesting anecdote.
Once, I installed ADOM (Ancient Domains of Mystery, a Roguelike) on a Linux (RH 6.2), Win98SE, DOS 6.22, and a Win3.11 machine (triple boot). The machine was an old 486 80mhz with 32 megs of memory.
As a normal user (not root) ADOM crashed so bad that it destroyed linux's ext2 partition, forcing a wipe and reinstall of linux. Of course it didn't do it right away, but after a random period of time after the game started.
Under win98 it also had the habit of crashing after awhile, but didn't destroy the file system.
Under DOS, it would crash, but the file system was okay upon reboot.
With win3.11 running on top of the DOS installation, it ran perfectly, without a problem.
Now the same binary was used for win3.11/DOS/win98SE. Win3.11 was installed in the same partition as DOS 6.22. Linux (of course) had its own binary.
To add to the confusion, it runs stable on two other win98SE computers (both K6-2's).
Anyways, it gave me an interesting perspective on "stability" of certain OSes.
why not implement the gnutella protocol so that all machines connected to the net can grab libraries defined as sharable on other machines around it? it'd reduce overall traffic and frustration.
--- it's pelvis to be cube
Some time ago there was a question about what IBM could do to help the Linux community, since they are aggressively promoting Linux these days. As a systems programmer for an OS/390 mainframe, I've used their System Maintenance Program/Extended for many years. This is a program that coordinates installation of software and fixes. One of the things it does is prevent installation if co-requisite requirements are not met. Of course, to do that it also maintains records of everything that is installed. This makes my life much much easier, believe me, so it occurred to me that maybe IBM could help the Linux community quite a bit by applying their experts in this area to the problem of managing software installation and maintenance on Linux.
I'm not so sure about the "difficult". I have an RPM based Linux disto running as a combo "server" and "desktop" (need another box). There are currently just three library glitches I am forced to resolve by installing multiple versions; it's due to drop to two "real soon now". Two of these were solved by running
- rpm -Ivh xxx.rpm
on the newer package having installed the older version first. The other was a simple- make install
after a successful compilation.I suppose if that is classed as "difficult" that says positive things about Linux usability though. ;)
UNIX? They're not even circumcised! Savages!
are you guys saying that it is possible to install programs that aren't in a red carpet channel? Well that's where your problems are coming from. As long as I stay safely in my little redcarpet room everything is find - plus I get apple sauce twice a week.
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.
 _
The whole idea of external libraries was so that programs could share code or minimalise system load. This is as true whether you think of DOS overlays, OS/2 DLLs, or whatever. The notion is already present in C (with header files). For example, under DOS, there is no reason, why say XTREE and NC could not be merged to provide different file management interfaces, and shared file viewers. This could be extended to a generic command line utility that simply views the named file.
When you set up an API for third party use, you are inviting other people to use your routines. Since they will call your library and use it with certian expectations, then it is up to you to meet your end of your deal.
You do not need to update the dll every time you update the product - look at VBRUN?00.DLL for proof of this. But if you have a DLL like, say, MFC42.DLL, where some programs use vers 4, and others use vers 6, then there is a course for concern.
This is probably a bigger concern for the open source vendors than the closed source vendors, purely because the former have a much faster release rate. For example, the EMX package for OS/2 is at 0.9e or something. Some programs have a minimal requirement, like 0.9c. But it is not beyond some future version to become incompatable with an earlier program. And then one has to run either the earlier or later version.
An alternate version would be to design some interfaces which users could put together different files. This sort of thing is used by File Commander/2, ZTBold, Object Desktop, which load external utilities seamlessly. So you do not need separate libraries to open ZIP or RAR or CAB files in these utilities. What you do is to have a dedicated ZIP or RAR or CAB utility, which programs can open, display and use seamlessly. Adding a new archive should be as easy as entering the name of an INI header to the ARCHIVES list.
One can use libraries intelligently, to minimise the amount of loaded and stored code. The power of the unix pipe is due to its ability to thread together divers peices into a meaningful thread. The open software market has the room available to create intelligent libraries that may be used by diverse programs. Exploit this window of opportunity.
OS/2 - because choice is a terrible thing to waste.
Things have gotten so large maybe developer should consider not only posting the obscure and hard to find libs on their site, but all of the dependent libs breaking up the apps into sub-modules that can be downloaded in chunks and unpacked into the directories. ( or at least links to them)
What developers need to do is occasionaly download the app and compile on a clean machine, one that has an out-of the box version of LINUX and see if its still do-able with their tarball and links before declairing it stable.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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:[.]
In most cases, unless you are using software noone else uses, you can sort things out by using urpmi. If urpmi knows about software you newly downloaded rpm is dependant on, it will take care of it, and ask you when it doen't know for sure.
...STATIC LINKING!!!!
Disk space is cheap and computers are powerful. Why bother with libraries except in some extreme cases where the benefits are suitably huge?
I'd prefer 30% less free disk space and RAM for greater ease of install/uninstall and greater reliability any day.
-- Mike
That's great, we'll inovate until nothing works together. Part of inovation is interoperability. Can you imagine if the IETF decided on many incompatible implementations of TCP-IP? Standards, when well thought out and implemented through peer review are a wonderful way to insure that your app works with everyone else. The problem is not standards, but the lack of peer review and approval. -ted
Amen brother!
Just use debian! All the libraries are taken care of for you! apt-get install gnucash done!
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?
Actually, I am pretty sure that starting in win95 the app first goes to its local directory then to the windows/system directory when loading dlls. Any local version you needed just had to be in the same dir as the app and that would be the one it used. Otherwise it would go to the system directory.
Don't like glibc? Run FreeBSD. Compare the size of glibc to the size of the BSD libc. Not even in the same ballpark.
For a FreeBSD developer to introduce non-backwards compatible changes is a cardinal sin. I doubt you would find more than a handful -- if any -- of instances where you needed both the old and new C libraries for any reason other than old apps linked against the old lib.
This is the kind of thinking you get when the kernel, libs, and userland tools are all reviewed by the same people. With FSF, each project is doing their own thing and breaking each other's software. NOT GOOD.
I think you miss the point. BSD includes new optimizations, functionality and everything else. All of that without breaking compatability. And as for the size, I was referring to the size of the source, not the compiled library (although the two are related).
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
What's really important is that the libraries' (in win or lin) functionality is well defined. When you have no idea what it's supposed to do, that's when you can't keep your set up clean. Libraries, used right, free up memory and ease development. Done wrong, they cause a big mess. There should never be anything on your system that you don't know what it does.
evanchik.net
As long as a decent versioning system is used, things should be okay. I'm not a Microsoft fan, but the idea they have with the automatic versioning of the .Net libraries they intend to distribute, seems the way to go.
You can have this huge (it always will be huge ;-) tray of libraries. Multiple versions living next to each other, and an applicatie just request a certain library. Minor updates are backward compatible, major are not. You can have a "last used" setup to decide if any library might be flushed. Of course every library that ever existed on your system should be remembered and be available over the internet, so it can be restored when required.
If you're not into huge trays, then don't use share libs at all, but have each app take their own copy. But that will be huge also, and also troublessome to manage.
I vote for the 1st option.
Tbee (or not?)
spaces and multiple uses of periods, couldn't developers copy all DLLs for their apps,
rename them as something else like <name>_V5.DLL and install them all into a Vendor
folder off of the SYSTEM folder? If the original reason for overwriting DLLs was based of
HD space, look at the HD sizes we have now a days. Most people have 20 GB and many more have 40, 60 and even 80 GBs. There's no reason not to give DLLs a type of version naming schema.
Of course I'm probably way off on my assessment of the situation...
----
Capt' Trips
grep >= ! == $your
The problem here is library management. Library management is currently handled by ldconfig, ldd, etc. Since ldconfig handles shared library dependences, only one particular version of a library (e.g. libGLU.so.1.3) is available to *any* program that links with libGLU.so, or libGLU.so.1. The problem you run into here is that different programs may require mutually incompatible versions of a particular libary -- but ldd resolves them all to a particular instance of the library. What we need is a version of ldconfig that allows for specific exceptions -- e.g., if ld.so.conf can specify "GnuCash uses /usr/local/lib/gnucash/libc.so.5", then the problems are easy to fix.
Caveat: I haven't looked closely enough at ldconfig to determine if it already does this or not. If it does, good for the developers! If not, adding this functionality would solve some potential problems.
However, I should add that if every linux program installs its own version of shared libraries, then we're no better off than the windows DLL situation....
You ARE the Missing Link. Goodbye!
On stereophonic equipment, the monaural sound obtained through multiple channels will enhance your listening pleasure.
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).
--
It's called Delphi.
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?
No, UNIX has been around longer. Since ca. 1970, in fact. (Was Gates even born then? I wasn't.)
You do know Linux is basically UNIX, don't you?
UNIX was about as near to open source as possible when it first came out. You bought the source code on tape and figured out how to port it to your hardware yourself.
Secession is the right of all sentient beings.
Now, when you say, "sell," do you mean I get the intellectual property rights?
Oh, yeah, this is software. Never mind. Selling means the seller still owns it and the buyer gets a warranty for the physical media.
Secession is the right of all sentient beings.
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.
just put the 'shared' libraries which cause conflict in another directory.
I was wondering about this when working with the ximian packages and evolution on my debian box.
Say I have package x, which needs libfoo-1.0.4-2, installed. I would like to install package y, but that needs libfoo-1.0.4-5.
Of course I could force the installation and hope it works out. But I can't be sure that libfoo-1.0.4-2 supplies the same functions that libfoo-1.0.4-5 does.
The problem here is that differences are made solely by the version numbers - and these can be arbitrary. What we really need is an intelligent package management system where packages query each other on function level, making sure the proper functions with proper signatures are available.
That way it wouldn't matter if I have libfoo in the version 1.0.4-2, 1.0.4, or 1.0.4-7-ximian.
-- sigs are like parking spaces - all the good ones are occupied
Who is "Quicken". Perhaps you meant Intuit ??
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.
If some application is upgraded, then the OS will detect a change in the file an d remove that particular instance from the shared data block. This technique ca n be applied both to memory, as well as to disk storage therefore completely sol ving the problem, efficiently and with zero configuration (because it is done dy namically).