Slashdot Mirror
Bundled Applications for GNU/Linux?
munehiro asks: "As an addicted GNU/Linux and Mac OS X user I recently tried to install binaries and libraries on a Linux box using an approximation of the elegant and clean approach known as the Mac OS X bundle (everything about each app or lib under a different directory) as opposed to the Linux standard approach 'everything under a common prefix' (normally /usr or /usr/local) with applications and libraries mixed in the standard subdirs bin, lib, share and so on, and found administration life much easier. What do other, more experienced readers think about the problems and improvements related to dropping the current Linux approach for a 'bundle-like' one in Linux distributions?"
I think DarwinPorts is working on something like this. Unless I'm mistaken of course...
must... stay... awake...
...but to me it seems that the approach is the way to go. Install/uninstall by cp/rm or drag/drop, whatever you prefer. Ressource waste definitely is no reason for today's machines, at least on the desktop.
Who is General Failure and why is he reading my hard disk?
It's great to work with...simple as hell. But, I wonder...what if a lib needs to be replaced (updated), will all the bundles get the new version?
I have a Linux Fileserver with system on a 2.5 gigs HDD + 4-5 large hdds.
With the present organisation, if two programs must use a lib, they both access only this lib, wich is present once only.
with the bundle system, I have as many times the same lib as I have softs using it. Okay you can get a 400 gigs hdd easily nowadays, but my system only has this poor 2.5 gigs for system... some use even smaller hdds/flash drives.
+ when upgrading my debian box (easy apt-get) I have to upload on library once, not everytimes for every soft...
=> more hdd space, more files, more bandwith and time to upgrade in the minus vs convenience in the plus.
Choose your tradeoff.
It takes 40+ muscles to frown, but only four to extend your arm and bitchslap the motherfucker
Hi there,
GNUstep (http://www.gnustep.org) applications use application bundles as well. This tends to piss off a lot of anal-retentive folk, especially in the anal-retentive Debian Developer reality, but we do it because it ACTUALLY MAKES SENSE. It doesn't make sense to have stuff for one app in ten different non-parentally-unified folders.
I strongly suggest you check it out, if you've not previously. I'd personally like to see a unified AppBundle Freedesktop standard. Rox also uses AppBundles, as far as I know, and it would be nice to have a unified and mutually agreed upon format for them. Maybe you'd be up to the task of coordinating it. If so, subscribe to the gnustep-discuss mailing list (see the website for a link) and let's see what we can work out.
This is the way I would like all programs. No more
chasing around the disk to remove stray bits.
Same idea as having all user data under one branch so we can back it all up.
rcb
We create our society every time we interact with each other. What kind of society did you create today?
Gobolinux: http://gobolinux.org/
...
Stow: http://www.gnu.org/software/stow/stow.html
I think you will find that you are not alone
10b||~10b -- aah, what a question!
If someone would make USE of the Library versioning system, and -then- make SANE use of LIBRARIES, then this would be an absolute no-brainer.
You put your LIBRARIES in a common directory. Everything else that relates to a piece of software is in it's own directory.
LIBRARIES ARE THINGS THAT ARE MEANT TO BE SHARED BY MULTIPLE SOFTWARES.
When I go to install some program, and find I have to install 8,000 different libraries, that are mostly only used by that ONE piece of software.. that really farking pisses me off.
Any software that requires anything beyond (a) it's executeable (b) a configuration file, should have it's own directory where all of it's stuff goes.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
I'm sure many will correct me if I'm not hearing you right, but it should be noted that there is a widely-accepted and fully GNU/Linuxy way to have an application housed with its own directory tree (organised however the application wants) in /opt.
/usr/local in cases where the UNIX filesystem hierarchy is adhered to (with /usr or even /. used if the software is included in the default disto/UNIX version).
The filesystem hierarchy standard also provides
To what extreme does this go? For example, where is the standard C library?
/lib, and at worst we get a warning that something some program is doing with that library is depricated and will be removed. But this gives the individual program maintainers more time to update, because they don't have to rush things out the door to make the security patch. They have until the next library release to get with the program.
Suppose there's a major security flaw in a reasonably popular library. If each package must keep everything inside its own folders, then the library update only goes to apps which are maintained actively -- and which noticed that the library was updated.
If, on the other hand, we use traditional UNIX, then one file is replaced in
And, resource management DOES matter. There is no good reason that my dad, a commodity/stock broker, needs 512 megs of RAM on his machine -- except for the use of this kind of design. It's not just how much memory it takes up on disk, if you have to load glibc fifty times into RAM, you've got problems.
Don't thank God, thank a doctor!
I've worked on OSes that used both methods, as well as others. Either of the two mentioned here is fine. You just spend a few minutes learning how your system does it, and deal with it.
There are, IMO, much better uses of good engeineers' and programmers' time, than fighting this battle.
Any logical approach, that's my preferred approach. And both of these are logical enough.
How much harder is it to do "emerge -C program" as opposed to "rm -rf /usr/share/program"?
/lib. But installing/uninstalling MIGHT be slightly slower, and WILL be just as easy.
And yes, we do like all user data under one branch, so we can back it up. Personally, I also like all config data under one branch, even if it isn't anywhere near the programs that use it, so that it can be backed up.
Plus, how often do you install/uninstall programs? How often do you use them? You use less RAM when you don't have to cache two copies of the same library because there's no more
Don't thank God, thank a doctor!
For each application I would have to add an entry to /usr hierarchy, I don't think there is any advantage in moving each library/application to /usr should be maintained entirely by the package manager; locally compiled software belongs under /usr/local.
PATH and possibly LD_LIBRARY_PATH, either globally or (even worse) in each user's profile file.
With package management systems such as dpkg and rpm maintaining the
a different directory. There is even software available that will track where files are placed when locally compiled
packages are installed. So, where's the advantage? I see lots of
drawbacks and no real benefits.
I generally follow the rule that software installed under
It's sad that it takes Apple to get the obvious going.
/bin /lib /sbin /etc /man.
/usr/bin /usr/lib, etc.
/apps/gcc/bin /apps/gcc/lib...
/apps/commonlibs/) and soft linked into the lib directory of the mini hierarchy.
/usr/share.
A good system would work as follows:
Base system (everything needed to get the system up into a usuable at all state, but no serious apps beyond vi) in
The secondary set of basic apps (like grep, find, cut, and so on) in
Add on apps (like gcc, emacs, Quake3, etc) in mini hierarchies:
Common libraries anywhere convenient (probably
The same goes for stuff normally in
If the package can't work without it, it should be softlinked into the mini hierarchy.
The result is that it's extremely obvious what stuff an application needs without having to use special tools and look up possibly outdated docs.
This also means that it's obvious how to do version management. You would have a tool called addpath that would allow you to add an app to your path (or to the system path) and otherwise manage things so that you only had the apps your wanted there, but it'd be very easy to find out what you were missing.
If you installed a new version of something, it would overwrite the old one. It'd just remind you to remove the old path, and put in the new one. That way testing new programs becomes easier.
All the technology in the world won't hide your lack of vision, talent, or understanding.
App bundles are okay for some people, but they are not the holy grail most seem to be touting them as here.
Sure, library updates are a problem. But that isn't why app bundles are a bad idea.
App bundles are a bad idea because they solve more problems than exist, and cause more problems than they solve.
For every definciency in the way UNIX traditionally works there is a workaround. The problems with the system are well known. The system has a very few flaws... but one of those flaws is really glaring to desktop users, especially Mac heads.
Because they see only what is broken and not what isn't they propose a Mac-like system. The app bundle idea isn't new and it isn't bad, but it does not solve the right problems. It solves one, perhaps two, problems, mostly for one class of users. And, while those problems are being solved, it creates dozens of difficult problems for several classes of users.
The people who have the new problems tend to be the uber-admins, the developers, and the people who create distros. Those people do not adopt app bundles because the "sense" that they make is non, from thei point of view. In a admin-centric cost-benefit analysis app bundles nearly always lose to the *nix way.
If someone could figure out a way to solve the problem that app bundles solve for desktop users without screwing over the admins and developers, distros would convert in droves. Since the existing solution is to "Screw different people, screw more people, just unscrew ME!" no one really feels obliged to comply.
I want my Cowboyneal
Also, executable content in arbitrary locations is a security nightmare...
"Flyin' in just a sweet place,
Never been known to fail..."
This is a little like windows system. It will make system administration more convenient.
Probably the arrangement I've seen the most often is to have a directory tree under
This is much more practical to maintain, on modern Linux systems, as many important systems packages (such as xinetd and ld.so) have directories containing a configuration file for each application, rather than one file for everything. This can be a symlink to the version of the application you want to use, allowing you to change any aspect of your configuration on-the-fly.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Advantages:
All these goals can be easily achieved using any reasonable package menegement system. Now let's see disadvantages:
So, what we gain? Nothing. There are some advantages which can be easily achieved another way, but there are very serious disadvantages.
When managing system, stop thinking in terms of files. Think in terms of software packages. Consider
What do other, more experienced readers think about the problems and improvements related to dropping the current Linux approach for a 'bundle-like' one in Linux distributions?
OK.. this question is really 1st year CS material, so hopefully this will set all y'all newbie young'ns straight. "Bundling applications," as defined as giving every app it's own copies of used libraries, is just plain stupid if at all avoidable. Here's why:
1.) What happens when a bug or security flaw is found in a library? Without a shared copy, you must figure out which apps are using it (which may be thousands) and then upgrade every application "bundle" instead of one library for the whole system. And what if some apps are using an older version of the library which nobody bothered to patch?
2.) Disk caching. Today's hard disks may be really large, but they're still really slow (compared to the rest of the system). If you have to load separate copies of a library for each app, you lose all the benefit of disk caching.
3.) Memory usage. Shared libraries allow a single copy of the library in memory to be used by multiple applications. This also reduces load time if the library is already in memory. (ie. this is why it makes sense efficiency-wise to use either KDE or GNOME and not a mixture of apps from both) It's also partly why OpenOffice and Firefox take so long to load on Windows compared to Office and IE. (they don't use all the standard windows libraries.)
4.) Shared libraries are a major driving force in pushing application developers to stay on their toes and keep up with the progress of the library developers.
5.) You shouldn't be compiling your own apps unless you're their developer or have very specific security or optimization needs. It's a waste of time unless you're learning something in the process. Leave that job to distro package maintainers and do something useful with your time like becoming a better programmer and/or contributing to your favorite app. Once Linux ceases to be a toy for you, you'll avoid compiling everyday software like the plague.
I could go on for several points, but that should be enough to convince ya. (:
I'm feeling pretty ignorant right now, but can someone please explain what problems are arising from shared libraries under linux? Is this the same as program x needs library y which needs library z but that will screw up program w? Or is this I want to distribute program x that has 20 other dependencies so I'll just put them all together?
"Since the existing solution is to "Screw different people, screw more people, just unscrew ME!" no one really feels obliged to comply."
Ding! Ding! Ding! Got it in one (that and one other guy). That's the problem with all the "suggestions" that developers get. The "suggestor" doesn't understand the domain space, and aren't interested in understanding it. But oh boy do they want YOU to solve it. Sometimes they will have good suggestions, but they should understand that there may be good reasons why they aren't adopted.
I stumbled across this a couple of years ago - Zero-Install (and the Rox Desktop) at Sourceforge.net. Zero-Install is similar in effect to Bundles, but have the added effect of being installed on demand and shared by all system users - think of it as an Application Cache that you control the "expiration".
http://zero-install.fs.net
http://rox.sf.net
Personally, I see this like going back to the DOS days. Linux/BSD have been dealing with shared libs in pretty sane ways. Although rpm is sometimes a pain in the butt, Debian's package system and Gentoo's Portage prove that dealing with dependencies automatically is feasible and confortable.
And, anyhow, for special cases, you can always drop apps into /opt and get the equivalent of a bundle. Oracle does this, vmware does this, as there are countless other cases.
If at first you don't succeed, skydiving is not for you
pkgsrc us a source-based packaging system that works on MacOS X, Linux and many other operating systems (even Windows, with SFU).
. pdf
More information:
http://www.pkgsrc.org/
http://www.feyrer.de/Texts/Own/21c3-pkgsrc-slides
Under such a scheme usually the vendor gets to install in /usr/{bin,lib,...}
and third party packages tend to install in /usr/local/{usr,lib,...}.
For build-for-source it's often good to go your way, often installing in /opt/package-version/{bin,lib,...} and symlink to (say) /opt/bin for $PATH
convenience to users.
One often unstated advantage of the per-package tree approach, aside form having everything in one spot, is that you can install multiple versions of a package at a time (or multiple different builds of the same package). This can be used for testing bleeding edge releases without breaking stuff, and of course for legacy support for other stuff that needs only an older version of something.
Of course the system has pitfalls. I run most of our "add on" software in the "per package dir in /opt"
fashion at my workplace, thus:
syncopt,
which scales mostly nicely for many workstations wanting this stuff.
Cheers,
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
Several comments have mentioned concerns like "What if there's a security problem in a commonly used library? You'll have to update all your apps instead of a shared lib!" or "All those extra copies of things will eat up too much RAM and drive space!"
o nceptual/SystemOverview/Bundles/chapter_4_section_ 1.html
Please take a few minutes and look at Apple's documentation about how bundles work before rehashing those topics.
http://developer.apple.com/documentation/MacOSX/C
-Ster
You don't have to chase around the disk to remove stray bits. That's what package managers are for. Assuming you have an intelligent packaging system, it can track all the files that come in a software package and install/remove/update them as necessary. The only thing Gentoo's Portage system can't clean up after (that I've seen) is a kernel tree with leftover object files in it. But the only thing you have to do to fix that is "make distclean" before you "emerge -C =your-kernel-source-x.y.z-a".
Sorry, my karma just ran over your dogma.
apt-get install package
NZ Electronics Enthusiasts: Check out my Trade Me Listings
Plan9's soft file systems would really help for this kind of system
/bin and then one binds in any directories with executable in that one would like to be in the path.
/bin
/bin
:
/net looks local to any child processes but remotely looks like it's coming from remotefbsdsystem - like an advanced ssh tunnel or VPN. The link between me and remotefreebsdsystem doesn't even need to be over TCP/IP, it could be serial or datakit)
In Plan9 the file tree isn't bound to the disks, it is made up from a series of bind commands (kind of like mount). Where the server for each bind can be anything, from a disk server to an ftp client to a pipe, all it takes is a file descriptor. This file tree is set per process, with children able to inherit their parent's tree or start of with a blank one and bind in devices as necessary (a separate # namespace is used as the seed for devices).
Although there is a PATH variable it is usually just set to
One has a login script that takes care of the binds for one's user shell
# bind in my shell scripts
bind -a $home/bin/rc
# bind in the compiled binaries for the CPU I happen to be running on
bind -a $home/bin/$cputype
This last one is particularly interesting as you may notice that CPU type is involved, thus the same login script works across architectutes. My profile is stored centrally and builds the environment when I log in to any client. Personally I have an x86 terminal and an IPAQ, when I log in I have roughly the same environment.
When you think that the binds can include *remote* file systems and programs, even the network stack
# use the network stack of my freebsd box for all network activity for this process
srvssh remotefbsdsystem
(now any activity on
Plan9 users get hooked on to this feature pretty easily and it is one of the main attractions once you get used to it and it is *very* high up on the wishlist when one tries to work on other systems "oh bugger, I cant do that here, gah why doesn't anyone else have soft file systems!!"
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
ROX (RiscOS On X) which has a filer, window manager and a session manager uses Application Directories taken from Risc OS. This sounds very similar to Apple Application Bundles.
Installation is done by copying the directory, and the first time you run it, it will be compiled. You do have to run it from ROX-Filer for this to be supported (just double-click on the application directory), otherwise you have to run a script inside the directory.
Recently ROX has combined AppDirs with the Zero Install installation method, which uses a caching-remote filesystem. You can run things direct from the server they are distributed on using a virtual filesystem which will locally cache the files.
There are already a lot of applications written for this.
RMS proposed such a model for GNU/Hurd packaging.- devel/2002-1 2/msg00004.html
http://lists.gnu.org/archive/html/aps
-- Anand Babu
Are nasty as they look like one file, and are actually directories that don't open when you dbl click.
Linux Package Management takes all the pain away from having everything in / and on a well implemented system (which prob doesn't exist yet) you can have the rpm as an icon for the app, double click, a scrollbar goes across the screen and its done, could not be simpler. Of course apt-get makes this even easier.
How the application is stored in the filesystem has no impact what so ever on usiblity either, coz a user should be either oblivious to it, or be aware of it, but the ui just works so don't look.
When I installed archlinux (www.archlinux.org), it installed a 2.4x kernel(2.6x also available), a bash shell (no gui), and an incredible package manager called pacman. From the bash shell and root account, one can pick and choose what they would like from archlinux database of open source software, everything from basic windowing (x.org, XFree86), desktops (gnome, kde), networking (xinetd), gnu tools (bintools), etc... all by typeing bash> pacman {package name} pacman does the rest (loads proper libraries, set config options, etc). This allows the user to customize their linux system with only the apps they need and like. The only downside is that for large packages, a broadband connection is perferable. Check it out! www.archlinux.org
Wouldn't it be handy to use union/overlay mounts to unify the namespaces? That way you could give a package its own directory + subdirectories without having to bother with PATH settings. You could simply mount its package directory so the standard locations would be overlayed and the contents of the package directory transparently added to the system-wide directories.
You are correct.
/opt/local or /usr/local).
Unfortunately this is because you are mistaken.
Darwinports does work on the BSDs, and Solaris as well as on darwin. The new default installation structure is to install files under private directory spaces, but these are not intended to be used from those locations and must be activated by linking the files into canonical paths for use (e.g.
While I can see the advantages of having every app isolated in it's own directory, I feel that one of the things I really like in Linux is to have all configuration in one, relatively small, pure text hierarchy: /etc.
I can grep it easily when I look for something, and easily edit the relevant file, which is usually well commented. I cannot grep the entire / tree. Well, I suppose I could, but I certainly don't want to.
For the rest, grouping all an applications's files together sounds attractive, but I would be happy enough if every app just clearly documented what it did at install time so it's easy to undo. (I don't believe much in "uninstall" programs/scripts, seeing how they (don't quite) work on Windows).
i have quanta gold from theKompany. (good on linux, sucks on os x. oh well.) anyways, they bundle all the Qt libs in a single directory. it is theoretically possible, yes, but screws other things up. for example, i had several X clients in my old classroom, and ran them off a P3 933 512MB system. ran fine. but, if i ran 6 copies of mozilla, each with its own libraries, it'd come to a grinding halt. the problem is windowsy really, as with free software it's not usually too hard to update a library. bundled libs are a commercial, not free, way of doing things. technical versus profitable, i guess. os x apps access a set of frameworks, and all specialized frameworks are .app bundle specific, unless yo drag them to /Library/Frameworks. but that's not always possible. it's like those damn activeX controls.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
One existing user of bundled applications on GNU/Linux is klik which was originally designed for installing additional programs on Knoppix by simply installing the klik client and clicking on links on the klik site. Klik has evolved since it's inception so that now it builds compressed images as bundles, supports 4 distributions (Knoppix 3.7, Kanotix BHZ, Simply MEPIS 2004.04 and Linspire 5.0), can work with dialog|Xdialog aswell as kdialog and firefox|elinks aswell as konqueror and finally offers the entire debian sid archive by klik (and many other changes). This is "next generation" klik, and while it is still evolving it is a very useful tool especially for debian based systems and livecds in particular.
A lot of the posts in this thread seem to repeat the same arguments against bundles (the duplication and security issues of having shared libraries in bundles) but nobody mentions the prime advantage I see in them. They can be summarised with this present from probono, a cmg of OpenOffice.org 1.9.65 which can run on many distributions (it uses a Linux transparent compressed iso for it's image rather then the normal cramfs to extend compatibility). So you can try out a preview release of ooo2 without having to upgrade any of your system, no need to have a test setup to try it out or wonder what risks you are taking that you might break something trying out experimental software.
Another aspect which klik deals with in it's own way that hasn't been discussed much here is that klik assumes a base system, the set of all packages installed in all it's supported systems with the minimum expected version being the lowest version in any of the supported distributions. This means that everything in the base system of your distribution is still handled everywhere by it (so updating your base system updates the common packages), everything outside of this will be bundled in any applications which need it.
Just remember to look at the klik docs and the klik forum if you have any problems.
Never underestimate the dark side of the Source
Unsupported Operating System
If you were visiting this site with Linux, you could install thousands of applications simply with a klik. You can download a free copy of Linux here. Please come back with a standards compliant operating system and browser.
This site is optimized for Konqueror and Firefox.
How narrowminded to not let me scope it out from Windows/IE.
500GB of disk, 5TB of transfer, $5.95/mo
For each application I would have to add an entry to PATH and possibly LD_LIBRARY_PATH
Let's think outside the box =).
Since there are applications I want to run, but can't trust (such as p2p, or anything proprietry), it would be great to partition my little secutiry island (I mean my user account) for each application that I run.
Thus, when I double click on the App I want to run (think OS X application bundles), a script takes care of a chroot jail, setting up resource auditing etc. Nothing need happen to the PATH or LD_LIBRARY_PATH, and all of a sudden I could make in impossible for individual applications to access the network.
It could be simple and intuitive to the end user. You could delete an application by just... deleting it. All configuration information etc. can we neatly stored in the app bundle.
OS X also privdes a 'Library' directory where applications can store per-user information and anything that should logically persist outside of the app bundle.... with such a design, you're not burning any bridges.
Resource usage may be a problem... if something isn't done to manage duplicate copies of the same library in a sensible manor. If I'm not mistaken, UNIX systems load instances of libraries into memory for each process that uses the library... so your main concern is disk space usage.
Libraries _could_ still be centrally stored, with soft links in the app bundles. All of this could automatically be handled when you run the application. For example, your run script (open on OS X) might identify and keep a hash table of libraries. If it identifies two libraries that are the same (exact binary duplicates) it could move them to a common directory, and provide soft links back to the app bundle. When a bundle is deleted... just hink counting semaphores.
With next generation file systems, it may be possible to automatically identify all libraries of a certain ilk in one foul swoop and do this automatically, when you copy files... kinda like a copy-on-write smart pointer. This would make it possible to upgrade all app bundles.
It's all possible, and I think this would be preferrable for end user applications (such as the future Photoshop-Linux), since it's so intuitive to the end user, and gives the application distributor so much flexiblity, since they won't have to consider each different distribution
Package management systems like rpm, urpmi, yast, apt-get, are very cool, but if I want to compile and install my own program, or run the lastest Firefox (with the latest dependent libraries), I can end up with a mess that can be time consuming to clean up. It requires too much Unix savvy for windoze users.
If you've ever used OS X (or Mac Classic), and "installed" a program by copying it from a disk onto your hard disk (anywhere), and then later "uninstalled" it by dragging it into the trash... that's simplicity.
Like all pain, suffering is a signal that something isn't right
Just like about every other distro which has an option to not install all the kitchen sinks ...
(of course, you left out the libraries that bash requires, like glibc, ncurses or termcap, and I'm guessing you needed at least some tool which is capable of retrieving files from the internet, so you probably needed at least something like wget or curl).
The only difference is what you type before the package name (ie s/pacman/urpmi/g, or s/pacman/yum install/g, s/pacman/apt-get install/g).
Yes, you are correct. Most distros can do a lean install, but archlinux' lean install is about 170M you then use pacman for everything else, and it really is the best package manager I have used. You are also correct that it is more than than kernel and bash - glib, ncurses, binutils, filesystem utils, etc basically everything pacman would need to retrive other packages (it has ftplib embedded into it).
Slackware has always had this in /var/log/packages.
In there each package has a text file with a list of files installed for this package.
The standard way of installing is called "installpkg" and "removepkg".
sure I'll have a sig.
I think that the MacOS X approach (which is similar to Windows, only cleaner) partly differs from the Linux/Unix approach because of a different software development philosophy.
Most Linux apps are open source (ok I run Debian so I'm biased). There's a strong emphasis on making things modular. Libraries are generally bundled separately from applications, because as soon as one app has a nifty feature it gets yoinked out and made into a general purpose library/API/framework (think GTK the "Gimp Toolkit").
Keeping libraries and apps separate fits in with the Linux goal of modularity which I believe is in a feedback loop with the open source philosophy.
OTOH, MacOS and Windows have a lot of proprietary closed apps. If Microsoft comes up with a new-fangled widget for Media Player, or Apple for iTunes, they don't need or want to make it particularly modular. They keep the support libraries close to the apps. A competing software company, say, MusicMatch, may reinvent the same widget and make their own library.
I think the Linux approach to program file organization fits better with open source. I do think that keeping all files for an app in one place has some advantages, for example making it easier to keep track of online help. Example: I hate when a gnome app can't find its own help files; these don't need to be used by multiple programs, and they can be replaced with every new version, so they should stay "close to the app" in my opinion.
My bicyles