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?"
...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?
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.
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.
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
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. (:
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).