Slashdot Mirror
Petreley On Simplifying Software Installation for Linux
markcappel writes "RAM, bandwidth, and disk space are cheap while system administrator time is expensive. That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro." The summary paragraph gives some hint as to why this isn't likely to happen anytime soon.
"That's the basis for Nicholas Petreley's 3,250-word outline for making Linux software installation painless and cross-distro."
Was it necessary to include the word count? It's hard enough to get slashdotters to read a small article and post intelligently, this cant help...
Yes it should be automated to install software, especially in the case of Java. Anybody wanting to run LimeWire has to download a 20MB file, then mess around in a terminal. Not good. Though Synaptic is close to full automation....
If you're happy and you know it read my blog
Autopackage comes to mind.
from the site:
* Build packages that will install on many different distros
* Packages can be interactive
* Multiple front ends: best is automatically chosen so GUI users get a graphical front end, and command line users get a text based interface
* Multiple language support (both in tools and for your own packages)
* Automatically verifies and resolves dependancies no matter how the software was installed. This means you don't have to use autopackage for all your software, or even any of it, for packages to succesfully install.
I just don't trust anything that bleeds for five days and doesn't die.
Static linking might be useful as a workaround for the more esoteric distros, but it has its problems. For one, if you statically link your application then anytime there's a security fix or change to the linked library you'll need to recompile the application, not just upgrade the library. This would probably cost more in administration time than upgrading a single library since multiple applications may be dependent on the one library.
emerge
Doesn't get any simpler than that. Come back in a minute to 12 hours (Depending on the package), and *poof* new software. Ditto BSD ports.
TODO: Something witty here...
Place user applications in their own directories
This single rule alone would eliminate most of the problems. It enables fallback to manual package management, it resolves library conflicts, it avoids stale files after uninstallation and it prevents damaging the system which can be caused by overwriting files during installation and subsequently removing files during uninstallation.
I have noticed that installation complexity is directly propotional to the reliability of the software.
:)
If a software is extremely complex to install, one can safely assume it is reliable
If a software is easy to install, it is not reliable. for e.g. MS products.
But seriously I dont think applications are complex to install, it is just that a learning curve is involved in doing anything.
Consensus is good, but informed dictatorship is better
The first obstacle to overcome is the bad attitude many linux users have that if something is easy to install, or easy to use, it is therefore bad.
./configure
As I see it, many would like to keep the learning curve very, very steep and high to maintain their exclusivity and "leetness" if you will.
For instance, the post above mine displays the ignorant attitude that "easy to install" by definition equals "unstable software" and has only a jab at MS to cite as a reference.
That's truly sad (though that may just be a symptom of being a slashdot reader.)
As I see it, not everyone finds:
make
make install
to be intuitive, much less easy, never mind what happens if you get compiler errors, or your build environment isn't the one the package wants *cough*mplayer*cough*, or if you even have said development environment.
Nor does it mean the software is any more stable. Could be just as shitty. _That_ is a matter of the developer of the program, not the install process.
Thats the reason windows servers are more vulnerable to attacks, because they give you the idea that its easy to mantain them... Its the same thing saying that you dont need any pilot on an airplane (and that you can put there anyone) if you make a good autopilot engine... We need more knowledge in system administration, not more automatisms.
WARNING: Stupid Matrix reloaded spoiler in parent, in the middle of the 4th paragraph
Site slashdotted? Look here for mirrors, or even better: o
One of the drawbacks of being so open is politics. In open source, a lot of times a dictatorship is the most efficient way to get things done. Not everyone deserves a say... only the people who are actually doing the coding! (Great job Mozilla in trying to be less democratic. Some of the "bug battles" were getting out of hand.)
Did some of the suggestions remind anyone of the OpenStep frameworks idea?
Frameworks (very roughly) are self contained libraries containing different versions, headers, and documentation. Java jar libraries are somewhat similar.
The problem is that using frameworks requires major changes to the tool chain - autoconf et al, cc, ld etc.
Apple shipped zlib as a framework in OS X 10.0 (IIRC) but getting unix apps to use it was very difficult. Apple now only seem to use frameworks for things above the unix layer.
I suspect there are lessons to be learned from this. As another poster said, evolution rather than revolution is more likely to succeed.
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
But installing gentoo is still hard.
/mnt/gentoo/ /mnt/gentoo
Insert cd.
login in from the command line
net-setup ethx
cfdisk
mkrieserfs
wget ftp.gentoo-mirror.net/pub/gentoo/stage1.tar
tar xzjdocmnaf stage1.tar
mkdir
chroot
scripts/bootstrap.sh
(10 hours later)
emerge ufed
edit use flags
emerge system
emerge gentoo-sources
configure kernel, having do lspci and googling obscure serial numbers to find out what modules to compile
install kernel
muck around with it's non standard bootloader
install cron and sysloggers
umount
reboot
spend two days sorting out the kernel panics
wait all week for kde to emerge.
processor dies of over work
huge nasty electricty bill arrives after running emerge for over a week 24/7
in other words, no
I agree with this logic completely. The
fundamental problem with most things (i.e., walking and chewing gum at the
same time, taking out the trash
masturbating) is that they're so easy to do that most any old jomoke can do them
without any "learning curve" being needed.
The rest of the world would be a much
better place if it aspired to the
standards of the free software community:
make things as difficult as possible
for the average person to learn. And if
they can't ever manage to get it figured out, well, (heheheh) too bad for them.
No woman, cry. Woman, cry.
I'd agree that installing Linux software isn't typically that hard once you've done it a while. Red Carpet makes updating/installing RPM files really easy. Apt-get makes the same process almost as easy in Debian based systems. Anything not available as a package just download and compile (which has gotten much easier in recent years).
What needs to be made easier is making good third party packages. It needs to be as easy as making a tarball or using WinZip. Obviously, the distros can't keep up with providing packages for every program that exists. They need to make it so your average sysadmin or developer can package the software he is trying to compile and install so that it works well across all his systems. Sure they can do learn to do it the hard way but obviously most of them are busy. The low number of third party packages is a good example as to the need for such tools.
As for every dick distro having trouble running standard packages it's been my experience they cause these problems by changing things pointlessly. Good packages play nice in any sane distro and distros should be smart enough to leave themselves compatible with those packages. Debian based distros should maintain compatibility with Debian, RedHat based distros with RedHat, etc. Pretty simple.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Use Debian and apt-get. No, seriously, could it be much easier?
--sdem
The complaints are, almost entirely, about libraries. But there's already a robust mechanism for determining that a library dependency is satisfied - the SONAME defines its binary compatibility. So if stuff is breaking, it's because library authors are changing binary compatibility without changing the SONAME. How about we just get library authors to stop breaking stuff?
First of all, RAM and disk space are NOT cheap. I spent 60 euros for 256 MB RAM, that's is not cheap (it's more than 120 Dutch guilders for goodness's sake!). A 60 GB harddisk still costs more than 200 euros. Again: not cheap. Until I can buy 256 MB RAM for 10 euros or less, and 60 GB harddisks for less than 90 euros, I call them everything but cheap.
What's even less cheap is bandwidth. Not everybody has broadband. Heck, many people can't get broadband. I have many friends who are still using 56k. It's just wrong to alienate them under the philosophy "bandwidth is cheap".
And just look at how expensive broadband is (at least here): 1 mbit downstream and 128 kbit upstream (cable), for 52 euros per month (more than 110 Dutch guilders!), that's just insane. And I even have a data limit.
There is no excuse for wasting resources. Resources are NOT cheap dispite what everbody claims.
He's got time, motivation, money and computer. Sounds like the right guy for the job!
Etc...
Who are you? The new #2 Who is #1? You are #617565. I am not a number, I am a free man! Muhahaha.
I'm glad it isn't easy. I like a challenge, even if it takes longer, even at work.
I'm glad it isn't brainless. I'm glad it's different across distros. Then I can pick and choose what I like.
The less each distro is like any other, the happier I am.
This is why I enjoy Linux.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
I was just talking with my brother about this. My take is since a linux install comes with just about anything you need to use a computer (networking and comminucation software, office software, media players, etc), it really doesn't matter if there's tons of old software you can install. Especially since your probably not paying too much (if anything) for your licenses. Backwards compatiblity was a lot more important when your wordprocessor costs $500 and you don't want to buy the new version :).
Not that it wouldn't be nice to find a 5 year old config tool somebody wrote that'll make my job easier and be able to run it.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
In descending order of (my) preference:
Your post came too late for me :( Looks like the moderators are listening as it is falling down the page. I guess that's what I get for reading new stories...
As I see it, the following things need to happen to really make application installation be very clean under any Unix like operating system:
Too damn many times I've tried to install FOO, only to be told by the packaging system "FOO needs BAR". But FOO doesn't *need* BAR, it just works "better" if BAR is present (e.g. the XFree packages from RedHat requiring kernel-drm to install, but working just fine (minus accelerated OpenGL) without it).
Were venders to do this, then a program install could be handled by a simple shell script - untar to
The system could provide a means to access the HTML (a simple, stupid server bound to a local port, maybe?) so that you could browse all installed apps' help files online.
As a final fanciness, you could have an automatic process to symlink apps into a
ls
and see them.
www.eFax.com are spammers
I don't install that often once I pick a distro/version combination that meets my needs. However, the real problem lies in keeping control of installed packages during upgrades and doing routine systems administration. Unfortunately, this is the place where most fracturing of linux distributions have occurred. I really wish that there was some tool that the distributions would support and standardize on (e.g. linuxconf, although any good tool would do). We use redhat 7.3 in my lab (mainly because of its popularity) but the admin tools leave a bit to be desired.
Nicholas Petreley writes:
Linking libthingy statically into application foo does not preclude the sharing. Each of the instances of application foo will still share all the code of that executable. So if libthingy takes up 5K, and you launch 10 instances, that does not mean the other 9 will take up separate memory. Even statically linked, as long as the executable is in a shared linking format like ELF, which generally will be the case, each process VM will be mapped from the same file. So we're still looking at around 5K of real memory occupancy for even 1000 instances of application foo. The exact details will depend on how many pages get hit by the run-time linker when it has to make some address relocations. With static linking there is less of that, anyway. Of course if libthingy has its own static buffers space it modified (bad programming practice in the best case, a disaster waiting to happen in multithreading) then the affected pages will be copied-on-write and no longer be shared (so don't do that when developing any library code).
Where a shared library gives an advantage is when there are many different applications all using the same library. So the "shared" part of "shared library" means sharing between completely different executable files. Sharing between multiple instances of the same executable file is already done by the virtual memory system (less any CoW).
The author's next point about sharing between other applications is where the size of libthingy becomes relevant. His point being that if libthingy is only 5K, you're only saving 45K by making it a shared (between different executables) library. So that's 45K more disk space used up and 45K more RAM used up when loading those 10 different applications in memory. The idea is the hassle savings trumps the disk and memory savings. The situation favors the author's position to use static linking for smaller less universal libraries even more than he realized (or at least wrote about).
For a desktop computer, you're going to see more applications, and fewer instances of each, loaded. So here, the issue really is sharing between applications. But the point remains valid regarding small specialty libraries that get used by only a few (such as 10) applications. However, on a server computer, there may well be hundreds of instances of the same application, and perhaps very few applications. It might be a mail server running 1000 instances of the SMTP daemon trying to sift through a spam attack. Even if the SMTP code is built statically, those 1000 instances still share unmodified memory mapped from the executable file.
now we need to go OSS in diesel cars
One of the greatest strengths of the UNIX platform is its diversity..
Package installation is a simple prospect on the Windows platform for the simple reason that the platform has little diversity.
Windows supports a very limited set of processors.. So there's one factor that windows packaging doesn't have to worry about.
Windows doesn't generally provide seperately compiled binaries for slightly different processors ("Fat binaries" are used instead, wasting space).. So the packaging system doesn't have to worry about that. On linux, on the other hand, you can get separate packages for an athlon-tbird version and an original athlon version.
On an MS system, the installers contain all the libraries the package needs that have the potential to not be on the system already. This could make the packages rather large, but ensures the user doesn't have to deal with dependencies. Personally, I'd rather deal with dependencies myself than super-size every installer that relies on a shared object..
Furthermore, on windows there arn't several different distributions to worry about, so the installers don't have to deal with that either.
All of these point confer more flexibility to the unix system but have the inevitable consequence that package management can get to be rather a complex art. We could simplify package management a great deal, but it'd mean giving up the above advantages.
If a bunch of Linux geeks want to have a hard to install Linux system in order to raise the leetness level, they can always put together their own "LeetLinux" distribution. We can't (and shouldn't) stop them. There shouldn't be a requirement that all distributions be "easy". This even applies to the BSD's. I personally find the command line install of OpenBSD more flexible (and even easier anyway) than the menu driven install of FreeBSD. But as I use Linux mostly, my preferred leetness distro is Slackware. Many will also find Gentoo and Linux From Scratch suits their desires.
now we need to go OSS in diesel cars
"""
I think evolution is better than revolution.
"""
Where possible, yes. One thing that stuck out in the article as much as your use of "revolution" above was the following:
"""
The software-installation process should be distribution-agnostic
"""
i.e. All distributions must understand the new installation process.
i.e. all distributions must change what they currently do to conform to the new one true installation mechanism.
i.e. Get rid of incompatabilities by making everyone change.
That ranks alongside Stroustrup's naming of C++ header files with no extension, so that all of the ".h", ".H", ".hpp", ".hh", ".hxx",
".h++" camps were left in an equal state of needing to change.
However, on the whole it looks like most of what he says could be slowly adopted on a piecemeal basis, and perhaps that means only partially, so that even teh distributions that dont want to conform, can still minimise their differences.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
This same problem occurs in the windows world as well, dll hell as it is often called. Here's how it works for windows. Say your program needs vbrun32.dll. You have a choice. You can put the dll in the same folder as the executable, in which case your program will find it and load the right dll. Or you can put it in the system or system32 dll in which case your program and others can find it and load it. However, if vbrun32.dll is already loaded into memory, your program will use that one. I remember we used to have problems with apps only working if loaded in the right order so the right dll would load.
As with Linux, if there's a bug in the library you have to update either one file or search through the computer and update all instances. But, as with linux, the update can mess up some programs, others might be poorly coded and not run with newer versions of the dll. I've seen this last problem in both windows and linux; it looks like the programmer did if version != 3.001 then fail instead of if version 3.001 then fail.
If everyone is forced to use the same library, you get these problems and benefits:
--1 easy point of update
--1 easy point of failure
--older software may not run with newer versions
--programmers may insist on a specific version number
--updates to the libraries can benefit all programs; if kde or windows gets a new file open dialog box, then all programs that link to the common library can have the newer look and feel by updating just one library.
On the other hand, if you let each program have its own, you get these problems and benefits:
--difficult to update libraries when bugs are found
--can run into problems if a different version of the library is already loaded into memory (does this happen with linux?)
--guarantee that libraries are compatible with your app
--compartmentalization; everything you need for an app is in it's directory. Want to uninstall? Just delete the directory. No need to worry that deleting the app will affect anything else.
--no weird dependencies. Why does app X need me to install app Y when they clearly aren't related at all. The answer is shared libraries. Which is why many people like Gentoo and building from source.
Microsoft has waffled back and forth on the issue. Under dos, everything just went into one directory and that was it. Windows brought in the system directory for shared dll's. Now the latest versions of windows are back to having each app and all of its dlls in one directory.
Personally, I think compartmentalization is the key, provided we get some intelligent updaters. If libthingy needs to be updated, the install procedure should do a search and find all instances of the library, back up existing versions and then update all of them. This wouldn't be that hard to do.
Yes if you start the same app twice, they will share memory. But that isn't the problem.
If your entire GNOME desktop is statically linked to GTK+, and you launch panel, nautilus and metacity, then you're loading 3 seperate copies of GTK+ into memory that don't share any memory at all!
Basically your suggestion amounts to building a binary package from a source package as a stage to having it actually installed. While that is something I actually do (using Slackware package.tgz format), and even recommend it to many people, it's not necessarily suitable for everyone or every purpose. I still run an experimental machine where everything I install beyond the distribution is installed from source. That's good for quickly checking out some new package to see if it really does what the blurbs imply (quite often this is not the case).
Building your own binary packages in whatever is your preferred package format is definitely a plus when managing lots of computers. And this way you have the plus that the MD5 checksum of all the binary files will be the same across multiple computers, making it easy to check for trojans.
As for making the recipe or spec file, I've actually figured out a way to do that when I build source packages into binary packages. It's slow but it works. I first construct a subdirectory consisting of a copy (never a hard link or bind mount) of the system root tree (or just enough to accompish the building). Then I scan that directory modifying every file object to some weird date way in the past. For symlinks which cannot have their date changed, I just note the current time as all new symlinks will have a timestamp after this. Then the installation is executed under chroot and thus will be installed within the subdirectory (as long as the package author didn't slip in some program to crack out of the chroot, which can be done easily). A rescan compares everything against the previous scan. Every file and every symlink changed or created will be detected. It's not perfect in theory (if the source package elects to not install something because it already exists in your root template, then you'll miss it), but so far I've been totally successful with it.
now we need to go OSS in diesel cars
But he doesn't. Dumass!
GTK+ is probably not a good example because of it's general usability. And GLIB is probably even more so because its usability goes even further. And we wouldn't suggest statically linking libc (or at least I wouldn't). The point is more of concern to library writers (besides those who do libc, GLIB, etc) who do libraries that are either smaller, or are used in fewer applications, or both. How likely are you to have several different applications loaded at the same time that need the 84K of, say, libext2? More likely only a small few tools will need it, and you'll probably be using only one of them at a time. Statically linking to that library would be a plus for those few applications (while still dynamically linking to libc, etc).
now we need to go OSS in diesel cars
For well-behaved packages, your method shouldn't be needed: you can just tell them 'make install DESTDIR=/tmp/aaa' and then look at what is in that directory.
-- Ed Avis ed@membled.com
Important features of the way AmigaOS libraries worked:
* All libraries were versioned, but not on the file system level. Each library contained a version number in it's header.
* Versions of the same library were always backwards compatible. This was Law. Software using an old version of a library must continue to work on future versions. This also meant that developers had to think out thier library API beforehand (because you would have to maintain that API). Libraries could be extended though with extra functions.
* Application programs had to 'open' libraries before using them. When opening a library an application would specify the minimum version that it required of the library. (If no matching or later version was found then the program would have to exit gracefully).
* There tended to be few (compared to Linux anyway) libraries. Libraries tended to be biggish. A few big libraries instead of many tiny libraries. This made them manageable.
* The backwards compatibility rule/law for libraries meant that software could bring it's own version of a library and update the existing version of that library, but *only* if it was a more up-to-date version.
As a previous poster pointed out, a lot of the problem would disappear if people (library writers) maintained compatible interfaces for the same library soname. I'm pretty sure that this is the way it was designed to work.
anyway, a FYI.
--
Simon
And, sorry, but your post is an example of "more leet than thou"! This isn't meant to flame you, but you make the common mistake of assuming that "easy for a newbie to use" MUST EQUAL "dumbed down", and that's absolutely not the case.
Look at the apps that have options to use either basic or advanced interface. Selecting the basic interface doesn't mean that the app somehow no longer knows any of its more 1337 functions; it just means they aren't in the user's face, baffling the newbie with a million options he can't make head nor tail of. And as a rule, the default is the advanced interface, but the "make it simpler" option is easy to find right off.
This really isn't much different from "custom" and "standard" options for installers. Yeah, it requires more thought on the part of the developer. Is that a *bad* thing??
~REZ~ #43301. Who'd fake being me anyway?
Autopackage seems to does it pretty well and least aim at it, not to mention tasty screenshots that make me forget what this whole discussion is all about. http://autopackage.org/gallery.html
Some very good points and ideas, but also IMHO some misguided assumptions and directions.
/usr/bin, /usr/lib, etc. ) Also the idea of having configuration files that resolve dependancies forces the application to use such configurations, which is also undesireable.
/opt or into /usr/bin or /usr/local if you don't want it there.
1) RAM & Disk space is not always cheap, or even readily available. There are many legacy systems where users would benefit from these advantages but the users are unable or unwilling to upgrade the system. What happens to old 486 and 586 systems where the motherboard doesn't support drives larger than X - there are work arounds, but the people who need easier install processes aren't going to tackle the complex system configuration issues to implement these. What happens when you can no longer obtain RAM in your community for your old machine, or it no longer has spare slots, etc. What happens if you have a second hand computer and simply don't have the available $$ to spend on upgrades, no matter how cheap they are. I don't like the idea of designing an easier-to-use system that excludes such people, no matter how small a portion of the market they may be. Hence redundant copies of libraries and staticly linked libraries are a very inelegant solution for these people.
2) We musn't impose requirements on application developers to use a given installer library, or code their apps to conform with particular standards that the installer requires - it is again unfeasible and undesireable in many circumstances. Developers have more than enough to worry about as it is without having to reimplement the way their app behaves to be installer friendly. The installer must exist at a level independant of the way the application has been coded, to a reasonable degree. I think that much of the problem that exists currently is that too much of the "packager" issues of making apps compatible to a hundred and one different unices has been getting dumped on developers and this both reduces their time for actual development and means that we have a hodge-podge of apps that are compatible to an unpredictable degree, because essentially developers don't want to be burdened with this.
3) Diversity is the spice of life, and it is the spice of unix. The community of unices is robust because it has adapted systems which are generally stable and reliable across a vast array of hardware and software. We want to capitalize on this tradition and expand and enhance it, not force anyone to use a particular layout for their apps & installations. This being said, I find the idea of local copies of libraries in the application directory unappealing, because it forces one to have a local directory ( rather than using
5) Aside from all these criticisms, there are many things I do agree with. Particularly that dependencies should be file specific, not package specific, that an integration of installer & linker is key to the organization of such a tool. I also agree that the installer should make use of auto-generated scripts wherever possible, and should provide detailed, useful messages to the end user that will help them to either resolve the conflicts in as friendly a way as possible, or to report the conflicts to their distribution. Also the installer should have advanced modes that allow for applications to be installed in accordance with a user or administrator prefered file system. That is one shouldn't be forced to install into
Given all this, is there any possible way to solve all of this in one consistent system? I think so - but it may require something that many will immediately wretch over. A registry. That's write, I used the foul windoze word registry. I propose a per-file database for libraries & applications that would record where given versions of given libraries are installed, under what names, in what directories, of what versions, providing what
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
The articles point was it's easier to staticly link the small obscure libraries. I don't know why a developer packaging a binary for general distribution can't statically link certain libraries.
I'm a bit rusty at static linking, but can't they just do a gcc -s -lgtk -ljpeg -o executable /usr/lib/libobscure.a foo.o bar.o widget.o to generate the binary? Then I wouldn't have to hunt down and attempt to install libobscure--sometimes a very frustrating process.
They should do that to statically link certain libraries. But judgement needs to be made as to which ones. Certainly libc is a bad choice for static linking (except for certain system tools that need to work while libraries are under maintenance). I'd say libm, gtk+, glib, and a few others that are big and commonly used are bad choices for static linking since you'll really have to have them around, anyway. But at the other extreme, specialty libraries just for one or two applications are more hassle than they are worth. Those should be statically linked in most cases (there are a few certain scenarios where doing run time dynamic linking is still a good thing, such as run time modularity).
now we need to go OSS in diesel cars
[Clarification: I am not pro-Microsoft, in fact, I paid extra to get a computer without Microsoft Windows pre-installed.]
I would have to disagree on the example, at least since Windows 2000 came out. Most, but not all, of it is pretty stable.
I defenitely do not like the trend, but the whole world seems to be becoming more and more enslaved to Microsoft rather than moving away from it --especially considering all the noise about their monopolistic practices and reports of lack of stability of Win95/98/ME/NT4.x.
I have talked with many many people who would rather install Microsoft Windows because they think it is the best. This is because it is stable enough to stay put based on its ease of installation and use!
Thank you for understanding.
GrimReality
2003-05-04 15:53:46 UTC (2003-05-04 11:53:46 EDT)
True. For well behaved packages it isn't needed. But I've encountered enough that are not (usually lacking support for DESTDIR= or INSTALLPREFIX= or such) that make it necessary to have this tool. So now that I have it, just using it universally anyway reduces the convolution level of my work.
now we need to go OSS in diesel cars
There exist (at least) two versions of the "links" browser; one that is only a text-based browser (now at version 0.98) and one that is a text-based and a graphical browser (now at version 2.1pre1, see http://atrey.karlin.mff.cuni.cz/~clock/twibright/l inks/download.html). And the latter is probably the one that was installed...
1-why are people even worrying about directories?
As has been discussed previously. A DB would make system managment (for user and computer) easier.
2-Instead of changes at the library level, how about at the symbol level? Instead of sending a big library with only a small portion changed. Just send the small change. Managment and resource friendly.
why only simplify installation? How about simplifying software maintenance?
If only GNU's dynamic linker implementation were not so unfortunately entangled with the glibc distribution, we could more easily experiment with how dynamic linking is done.
Free ld.so!
A good rule to follow is to never dynamically link to something that's substantially smaller than your program.
Dynamic linking tends to pull in too much. If you use "cos", dynamic linking hauls in the whole math library. Yes, the paging system will eventually figure out what the working set is. Every time the program runs.
Maybe we shouldn't have "shared libraries" at all. We should use static libraries for things that are really libraries (math, I/O), and "big objects" (CORBA, .NET, etc.) for things that have lots of internal state (GUIs, databases). The big object systems already have machinery for version management and interface incompatibilities.
For those who haven't tried it:
"The Zero Install system removes the need to install software or libraries by running all programs from a network filesystem. The filesystem in question is the Internet as a whole, with an aggressive caching system to make it as fast as (or faster than) traditional systems such as Debian's APT repository, and to allow for offline use. It doesn't require any central authority to maintain it, and allows users to run software without needing the root password."
Why does everyone feel the need to insert 'infidels' into those oh-so-funny Information Minister quotations? I don't think he ever spoke in those terms, any more than Rumsfeld would.
-- Ed Avis ed@membled.com
So, if I follow your logic correctly, my system will become almost perfectly reliable, if I install all the software using punch cards, one byte per card, or, alternatively, scribing it on the hard drive by hand using miniature magnets :P
Hell is not other people; it is yourself. - Ludwig Wittgenstein
... the worse-off the open source community will become. We. Need. Standards. Especially when it comes to something as important to adoption as package management. It's fine to have lots of little experimental systems flying around that you can pick and choose from, but something that works, and works WELL, must become dominant. I hate to tell you, but your attitude is selfish and ultimately detrimental to the goal of spreading Open Source Software.
+++ATH0
Linux is better than Windows because it's so complex and difficult to use?
/. can be. One day they are making out a bug in IE that crashes the browser to be a HUGE deal. Something that just about has to be purposely coded and would take 2 seconds out of your day to relaunch the window if you did run across a site with the code.
/. start focusing on their own hurdles instead of beating to death every little issue that pops up with Windows. Alternately I would like to see more than the handful of truly devoted Linux users admit, or even just realize, that Linux is far from perfect.
/., those vocal zealots have become the voice of the Linux community.
It's funny how hypocritical the crowd here on
Two seconds was a huge amount of time in the average Linux user's day yesterday, but today, hours and hours spent installing software is but a small price to pay.
I know I am oversimplifying this, I'm doing it on purpose to make a point. When the slightest problem is found with Windows, Linux users will type for hours telling how damaging it is and how it is just another reason not to use Windows. However, when a HUGE flaw in the very foundation of Linux is brought into discussion, it is trivialized to the point that the common concensus is that there is no problem at all.
Blind loyalty does no good for anyone but a dictator. Windows isn't the perfect OS, X isn't the perfect OS, and niether is Linux the perfect OS. Each has advantages and disadvantages. However, if you only focus on the advantages and do nothing to improve the disadvantages, or even admit they exist, they will always exist.
I'm gonna be honest here, I couldn't care less how long it takes to install something in Linux. I'm not posting this in hopes that the Linux Community will come together and work on solving the biggest problems facing Linux. I don't use Linux, probably never will, but I have tried it a couple times in the past. To me, Linux isn't even close to an alternative to XP and X (both of which I use daily). I feel Linux has years of catching up to do before I would even consider using it for anything but a web server.
I'm posting this for two reasons. Primarily, because I would like to see Linux users on
This might sound like flames to many slashdotters here, but that's only because I'm not slamming Windows as a creation of satan while singing the praises of Linux as a gift from the gods. If you really take the time to read what I've said with an open mind you will see I have said nothing defamatory about Linux, and in fact everything I have said would benefit Linux if people would take it to heart. Too many Linux users have become zealots and, at least here on
As proof, I offer this entire thread into evidence. The complexity of installing apps on Linux is quite probably the very largest single problem holding Linux back as a mainstream OS. As a computer user that started on the Commodore 64 and used UNIX in college as a CS major, I can testify that the main reason I wiped the Linux partition mere hours after installing both of the times that I tried it was the complexity of installing even the most basic of apps. However, if you read through this entire thread you will see that the majority of replies deny this problem even exists.
"disambiguation" is a perfectly cromulent word.
+++ATH0
As a happy Debian user, it seems to me like Petreley is mostly solving a non-problem. Debian has its problems, but "software is hard to install correctly" is rarely one of them. I think that Petreley's suggestions are actually way more germane to simplifying Windows software installation. "DLL hell" got its name there for a reason.
Petreley seems to not understand the model that has evolved for shared resources (libraries, data, etc.) in Linux. He is correct that nobody cares about the disk space anymore: what they care about is that they can now upgrade functionality without reinstalling packages, as long as they preserve interfaces. I can install a new libc, xine back-end, Mozilla icon, etc., and if I'm careful every app on my box will see the new version without further action. That's a big feature, as long as I'm careful to re-install all the apps if the interface to the newly-installed thing changes. Fortunately, apt gets this case mostly right. I wish they had a better scheme than putting major version numbers in package names, but I guess I can live with it.
I used to run Red Hat everywhere. I now think Debian-based distros such as Knoppix will win in the long run. They're getting to be no harder to install, and you only have to do it once per box: when you want to upgrade to current or install new bits you just push a button and it happens. What could be easier?
can I just make the point that nicholas petreley does no favours to the community as his points are ususaly based on very little fact and a lot of stupid simplifications, in short nick is dumb and all his articles should be taken with a grain of salt
The documentation on USE variables:
http://www.gentoo.org/dyn/use-index.xml
To "wing" the system online it's simply a matter of running either one of:
net-setup eth0 (if you're on a LAN)
adsl-setup
adsl-start (if you're using PPPoE)
For links, simply doing a USE="-X" emerge links would've emerged it without X support. The whole point of Gentoo is that you choose exactly what kind of support goes into each package, unlike in Debian where some maintainer makes that choice for you.
Of course you don't know these tricks, because you didn't stick around log enough to learn them or didn't read the docs.
- Bandwidth. No-one wants to have to take 2-4x as long to download programs.
- Hard-drive space. Even if we all had 40GB hard-drives, no-one wants to waste it reproducing the same information a hundred times. People buy hard-drives to store data, not twenty copies of the same library.
- RAM.Loading two copies of the same library wastes RAM.
- Load-time.Having to load all of the libraries will increase load-time compared to cases where some were already opened (by other apps) and you don't have to load them.
- Consistency.Part of the benefit of having shared libraries is shared behavior. Destroyed if app X uses Qt 2.0 and app Y uses Qt 3.0.
- The Big 3S: Security, Stability, and Speed.Who knwos what insecure, unstable, and poorly performing version of a library each app comes with. And who knows what crappy options it was compiled with. Resolving these issues at one central point can be counted out. You want to deal with any of these issues, you'd have to do it for every application's version of a library. That means doing it many times separately.
The solution to dependency-hell is to design better dependency management. Reverse-dependency management -- so as to remove useless libraries when no-longern needed and avoid bloat -- would also be good. Gentoo is doing pretty well in these categories.On making install process' simple. I think that a graphical installation does not necessarily make things any easier. Anyone here played Descent 2? That installed by a good old-fashioned DOS-installation. And it was not particularly hard to install, even though it was not a GUI-install.
It is also not necessarily a good idea to abstract into oblivion the technical details behind an install. Part of the philosophy behind Gentoo, for example, is to take newbies and turn them into advanced users. I think that a clear well thought-out install guide is a useful thing. Gentoo's install guide is thorough and has virtually no noise. Compare that to the install-guides for Debian, which are affirmative nightmares, filled with irrelevant stuff. Furthermore, a helpful and friendly user-community is always a good way to help new users orient themselves. New users are going to ask questions on forums that advanced users find obvious. That should not be an invitation to say, "RTFM bitch" at the top of your lungs. All of us were newbies at one point, and just because we may have had to learn things the hard way doesn't mean that others should too.
social sciences can never use experience to verify their statemen
Windows XP copies system DLLs that are of differing versions. "DLL Hell" has been solved since 2001.
"Sufferin' succotash."
If you're looking for a super-easy install, why not just use FreeBSD?
You can install it from two floppies, and installing new software is easy as:
cd
make install
Or for those who don't have "compile time" you can grab binaries off the net:
pkg_add -r new_package
I recently converted my P133 fileserver to FreeBSD and it'll never run Linux again. Whole install took 15 minutes, then about another hour getting stuff setup.
My specialty is software installation. I've written dozens of installers on a multitude of platforms. On the windoze platform, DLL happens for two reasons:
1. No backwards compatibility. All too often, new versions are released that break older programs. Even Microsoft has done this with major DLLs.
2. Stupid installer writers. You're supposed to check the version number of a file before overwriting it. All too often the file is overwritten without regard to the version numbers.
So to overcome these two problems, the smart installer coder would put all the DLLs in a private directory of the application (not in system/system32).
Of course, Microsoft came up with a new system that broke this simple fix. Registered libraries. Instead of using a specified path to get a DLL, you would ask the system to load the DLL (using registry information). The path was no longer considered. One, and only one, version of the DLL was allowed on the system, and there was no feasible way to get around this limitation. Someone came up with a fix. It would have been a major pain to implement and would require cooperation amongst the DLL coders, which isn't about to happen since the lack of cooperation was one of the core problems in the first place.
For a commercial level installer, missing libraries was absolutely unacceptable. My personal rule was to ALWAYS include dependencies in the installer package. This meant the installer was bigger and more complicated, but it guaranteed the application could be successfully installed without the user having to run off to find a missing library. Or did it? No - Microsoft decided that some libraries could not be independently distributed. The only legal means of getting the library was through the official Microsoft installer. And no suprise here, half the time the only official installer for a library was the latest version of Internet Explorer.
Requiring an upgrade to IE is a major problem for large companies. They standardize on specific software and don't allow the users to change it. Requiring a site-wide upgrade of something like IE (or the MDAC package) was not to be taken lightly. Especially when it was dicovered that the required upgrade would break other applications (back to DLL hell).
FYI, when a major customer pays your mid-sized company a couple of million dollars a year in license fees, they can definately tell you they won't upgrade IE. It's our job to come up with a work around. Too bad a measly few million paid to Microsoft wasn't enough to get them to change their ridiculous library polices.
-- Will program for bandwidth
That reeks of corporatespeak. Is WordNet an actual compilation of REAL dictionary entries?
+++ATH0
Just to elaborate on the dynamic linking issue a little more, when a program that needs the "cos" function ends up being linked to libm, then at the time that program is executed, the libm.so file has to be memory mapped. At first that does not read any pages. But it does add another bunch of map entries to the VM structure. Then the dynamic linker has to resolve for "cos" and other symbols. That forces it to read the symbol table parts of the libm.so file. So now those do get read in. It's not as bad as reading in the whole file, but it's not a zero effort, either. And when "cos" is called, at least one page of code is loaded, maybe 2 or more. For small functions, a whole page is loaded for each function when dynamically linked if those functions are scattered around. Had it been statically linked, "cos" would be sharing a page with some other functions, and less VM working set would result, in addition to less I/O work to get loaded.
I'm not opposed to having shared libraries. Sharing the code is valuable when the sharing factor is high. But the judgement needs to be made on that basis. We know it will be high for libc. The question is what other libraries qualify.
Now I do consider libm to be a borderline case. I'm satisfied to leave it be dynamically linked since many programs do use it. Same for the core libraries of graphical systems like GTK+ and Qt. But lesser libraries really should be considered for static linking by packagers. And source developers should make their configure files to understand options to control whether to link statically or dynamically (with static being the default for perhaps all but libc). Even better would be to further include options for explicit control per library (including libc). That doesn't mean to not include the dynamic libraries, but it will help end users avoid problems if they, due to not being experts about what libraries every program needs, end up with certain libraries not installed that a dynamic program needs.
now we need to go OSS in diesel cars
My issue with Linux is that every time a new version of a library comes out, it breaks all prior apps. (usually)
The response is that compatibility slows progress by locking down the api. This is so short sighted that it is not even funny.
If programmers thought out how their libraries would be used it would be simple to add another call in a newer version. Instead they make short sighted decisions and ruin the use of a shared library.
IMHO any newer version of a library should work better than the previous version and be a 100% replacement.
This would fix a huge chunk of DLL hell and installer issues.
If tyranny and oppression come to this land, it will be in the guise of fighting a foreign enemy. - James Madison
The problems plagueing X11 right now - namely an API that is being used with graphics primitives that are, well...TOO primitive for normal use.
The code is huge, the programs that use it are huge, and it runs very slowly.
All to support backward compatibility.
Mod me down and I will become more powerful than you can possibly imagine!
While I think the debate over static vs dynamic libraries, DLL Hell, and registry vs central vs distributed storage of program parameters and settings is all worthwhile, he didn't cover what I think is *the* most important issue in the Linux installation process, and that is device detection.
MOST of the problems I've had with installing Windows, Linux or OS X involve the fact that when I am all done, not all the components of my machine are working the way I expected them to. I end up with no sound, or bad sound, or video that isn't right, or a mouse that doesn't work, or in the really bad cases, disk drives that work well enough to boot the system but then fail after I'm in the middle of something important.
Once I get past the initial installation I feel I am home free. If the devices all work the way they are supposed to, then I can avoid most other problems by just sticking with the distro that I started with. If it was Debian Stable I stay with that, and if I need to install something that isn't part of that system I install it as a user (new version of Mozilla, Evolution, Real*, Java for example).
It would definitely be nice if developers who used shared libraries didn't seem to live in a fantasy land where they are the only users of those libraries. But I *don't* think that this is Linux's biggest problem with acceptance. What Linux needs is an agreement by all the distros to use something like the Knoppix device detection process... and then to cooperatively improve on it. A run-from-CD version of every distro would be great. Why blow away whatever you are running now just to find out if another version of Linux might suit you better?
I'd like a system that does a pre-install phase where every component of my system can be detected and tested before I commit to doing the install. The results of that could be saved somewhere so that when I commit to the install I don't have to answer any questions a second time (and possibly get it wrong).
There is nothing that can guarantee that what appears to be a good install doesn't go bad a week later, but I personally haven't had this happen. I usually know I have a bad install within a few minutes of booting up the first time, and by then, its too late to easily go back to the system that was "good enough".
there is nice use flags editor - ufed
it used older kerberos probably because newest wasnt marked stable.
some ebuilds are broken, you should have reported a bug about shh building without kerberos.
obviously your "text mode" browser used those libraries. you should have used USE flags here.
yes it takes a while to compile and install, and its not for faint at heart. but the whole idea of installing from source is right, source code is great vehicle to deliver programs. think of it as something like java. instead java bytecode you have source code. instead of java interpreter/jit you have gcc. write once run everywhere.
requires less effort to install Knoppix? SuSe8/8.2? Libranet?
Sure as heck ain't Win98SukbuttEdition/ME/3.11/3.1/2.0. Or even MSDos/anyflavor DrDos/anyflavor XP/2000
Wut u b smokn Petreley? I b installd em all.
Next thing, Bob Metcalfe will be complaining about obsolete networking interfaces like Ethernet.
This posting is just dumb.
Has the dependency bullshit been fixed?
We have:
real time linux
embedded linux
enterprise linux
secure linux
64 bit linux
crossdresser linux
floppy linux
cd linux
start a fire by rubbing two sticks together linux
linux for transmeta's drm
business card linux
lindows
multimedia linux
Jack Valenti linux
think of something else linux
What we don't have is a linux that a non-geek can use on a desktop, and install a different/updated application that she needs, without a dependency failure.
My guess is that we'll have:
mars lunar lander linux
explore the milky way linux
explore the hershey highway linux
automatic ass wiping linux
256 bit linux
quantum linux
before one of the distro companies gets their ass in gear and deals with a fundamental problem with linux.
Linux ready for the desktop?
Huh!
Got to get around the stupid "Your comment has too few characters per line (currently 12.2)" lame ass filter, so I'm going to have to ramble on for a while in this paragraph and start experimenting with different tags in future posts so I can format my comments in a way that looks good but doesn't run into the lame ass filters at the non-w3c compliant slashdot site. Is slashdot still blocking the checking of the slashdot site at the w3c site? Let me check if there are enough characters now per line, so that I can post. Hold on. Yeah, that did the trick. Nice to see this filter for bulleted lists though. A real genius must have thought of this one.
What's the difference between encap and GNU Stow? Quickly glancing at encap's web page they seem very similar.
Regardless, you might find the following bash alias useful:
alias ./configure='./configure --prefix=/usr/local/stow/$( echo `pwd` | sed -e s#.*/##g)'
:)
(just replace "stow" with "encap", I guess
What if apps were dynamically linked only with essential shared libraries (e.g. libc.so) and used dlopen() for non-essential libraries?
I thought of this when I tried to run the Lynx browser, and it failed because libssh.so wasn't present. Why does it crash so ungracefully? Why wasn't it written so it would still run if libssh.so was missing, but without support for secure web pages?
The article mentioned dlopen and libtool, but I wasn't sure what exactly he was talking about -- maybe the same idea.
This is the reason for all the dll hell, ok shared object hell in Linux.
It comes hand in hand with the BOFH attitude from some linuxers towards the regular users of the software.
And this is a more important issue to be resolved in Linux instead of just picking on the "sintoms" like the article does.
We are Turing O-Machines. The Oracle is out there.
>> 1. Upgrade your freakin' memory dude!!
Yes, I agree with you. In fact, I'm so 100% with you that I really got loads of RAM at home. But we're talking here about *thousands* of machines... an upgrade in this magnitude would be a costly operation and maintenance alone would justify buying new machines (that TCO thing, mind you).
>> 2. Try Knoppix.
A few of these machines don't have a CD player. Many have, but won't boot from CD (old BIOS etc.). And, on top of that, the company wants everything removed: floppy, CDs etc.
But thanks for the suggestions. If the machine was mine, I'd install a CD at the very minimum.
RedHat 7 came with Pan (the newsreader) v0.11.4. I wanted to upgrade it to v0.13.x. But it was RPM dependency hell, even following various FAQs. Compiling from source didn't work either. I finally ended up upgrading to RedHat 8 to get it. Even then, I couldn't see any text in GTK 2-based apps because, while trying to get Pan to work on RH7, I'd installed an incompatible version of Pango, and upgrading to RH8 hadn't fixed it! I never could find anything that told me which version of Pango went with which version of GTK.
I'm no Linux expert, obviously - but one shouldn't have to mess with components of lower-level graphics and font-rendering subsystems in order to upgrade an application. The install program should take care of that.
Also, check out installing Pan for Windows. (Yes, there is such a thing.) You run the installer, it's installed, GTK's installed, and it works. You run the uninstall routine, and it's all deleted. Simple, unlike Linux, where you're lucky to get an install routine ("It's best to compile from source!" they say), much less an uninstall routine.
IMO, one of the biggest reasons people will shell out money for Windows licenses is that most Windows programs adhere to basic standards, like including installation and uninstallation routines, quite unlike Linux.
You can flame me if you wish, but it's true.
What's racist?
India has a favorable exchange rate with the US
India is pushing programming for its people to dig out of the unfavorable economic conditions in its country, and bring in hard currency from other nations, specifically the US and Europe
the exchange rate in India, and the increased purchasing power of US corporations because of it, is enabling US corporations to lay off US programmers, and send their programming jobs to India
the number of US programmers laid off or currently being laid off is near an all time high, requests for hb1 visas are still high instead of dropping during a slow growth economy, and programming jobs shifting to India are increasing, not decreasing, during a slow growth economy
US corporations are either saving big money by hiring the same number of Indian programmers at a reduced wage/exchange rate, or they are hiring more Indian programmers for the same money they would have spent in the US
The savings are so great that it pays to establish offices, schools, and ship management personnel overseas temporarily to get the projects off the ground
The disparity is so great that the borg have shifted their assimilation from the US to India because of it
Take your head out of your sharpton and face reality.
Time to start the syrian part of operation pre-emption so that dwillyson can go back to picketing.
If autopackage ends up coming into fruition, I think it will be a dream come true. But it can't do it by itself, there needs to be standards setup and developers need to adhere to them. People adhere to such standards on windows (even with Free Software), for example, The GIMP uses an install shield installer on windows (provided by a third party, not the GIMP developers themselves).
I think fine grained dependency checking is incredibly important. For example, to use Galeon, a package manager like urpmi will also install Mozilla (instead of just the libraries it needs). If you want to remove Galeon, it will try to remove Mozilla!!
Another thing that is annoying, is that if you are running say KDE 3.0, and you want to upgrade KMail, but it requires KDE 3.1, you need to do a 100MB upgrade of something as intrusive as a desktop environment! The package manager should just get what libraries it needs. Also, big projects like KDE tend to have 6 monthly monolithic releases which break forwards compatibility (e.g. the example mentioned above). The core of a package such as KDE should be slow changing, and updates should be small. But the applications that run on top of such a platform, should be fast changing. Or perhaps, if the 3.1 libraries are 100% backwards compatible, then on installation of a 3.1 application, the libraries are updated, but nothing else (i.e. still running KDE 3.0, but on 3.1 libraries) until you decide to upgrade various components (e.g., kicker has a bug, I feel like updating it, 10MB download...).
One of the things that could make cross-distro compatibility a reality is if the various projects released their own distro-independent binaries. For example, an autopackage packaged KDE, that will install on anything. Same with glibc, XFree86, etc... And even Kernel.org kernels! That would make driver distribution a lot easier as you only would need to choose a driver for your official kernel version, not for "Red Hat 8.0 Kernel-2.4.18-8.0 or SuSE kernel-blah or Mandrake-blah etc". Official binaries would force people to cooperate and maintain compatibility (e.g. KDE people would be pissed if GNU broke glibc compatibility without providing compat libraries).
Whenever a library breaks backwards compatibility (e.g. glibc), it should provide compatibility libraries such as those found on BSD. People can run FreeBSD 2.x binaries on 5.x ! If there was an official GNU/Linux system, such a thing could work. People would synchronise their new versions against official GNU binaries, etc.
Also, autopackage (or some other distro-independent package system) needs to provide information for where things are installed. So if something wants to install in the KDE directory, it knows that it's in "/opt/de/KDE" or wherever the _user_ decided where to put it.
This is a mammoth problem that needs to be tackled by everybody. Such a move could finally unite GNU/Linux systems and put an end to Microsofts "1000 incompatible versions" FUD. If distros still provided their own binaries, they would be forced to make sure they are binary compatibile with official versions, or face the wrath of their users and Independent Software Vendors who no longer recommend their distro.
I've been poking at this to do something similar for my company, and I have to say that PXES offers much more flexibility than a locally installed OS on the HDD.
If the box doesn't support PXE, you can probably create an etherboot floppy that will work similar to PXES and get you up and running even with low hardware - processor and RAM.....
http://pxes.sourceforge.net/
But Herr Heisenberg, how does the electron know when I'm looking?
Or consider when regular users want to install software onto their account, a package is not an option. Windows has this kind of right with the All Users concept, although many packages break when trying to install them as a regular user. In the case of multiple users with the same package installed locally, some drive space optimization can likely be done with symlinks. I think Stow does something similar.
This isn't a problem with linux distributions per se, its a reflection of the unix mentality of one administrator and all users presented with the same environment. I'd like to see a packaging system that lets you install packages to your home directory if you wish, or become root if you want to make the package available to everyone. I really think this is possible to do, although it would mean breaking the FHS, and has the added benefit of reducing the time a user has to spend as root.
Any thoughts?
MicroSoft and Apple already have these things? Why cant the Linux community just settle on a set of standards? I mean we could try but we would spend years arguing over them. So what we are left with iws a front runner distro in the form of Red Hat and RPM. Both of which arent bad standards. Linux ahs great promise but we have to solve these things. When I left the Linux industry in 2001 it was because we couldnt find the time to get serious about standards. Let alone a basic agreement on what we should ue as an install tool. Developing standards would have solved a lot of the problems we were facing back then but no one wanted to do that. All Nick is saying is that we need standards. You need to code to a distrobution instead of coding for a generic Linux system. Because there is no such thing as a standard Linux distrobution with the possible exceptin of Red Hat. Trying to make a generic, bullet proof installer would be a neat hack, but you would quickly burry yourself in solving whacky depenancies and everything would be a constant moving target For better or worse, I'm kind of a Windows worker now and I kind of like the fact that when I code for WinXP I dont have to worry about what libraries are there. If I code for Red Hat 9 I know whatlibraries are there and I dont have to push any more magic into the system. Just my 2 cents worth, and I think thats about all its worth Mr. Petrelley's areticle looks pretty good. But I think red hat's already done thsi and we should just code to that.