Bundled Applications for GNU/Linux? 148
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?"
darwinports (Score:3, Informative)
re: darwinports. (Score:2)
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.
Correct me... (Score:4, Insightful)
I couldn't care less! (Score:3, Insightful)
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.
Re:Correct me... (Score:1)
Don't "path" bundle components! (Score:3, Interesting)
Also, executable content in arbitrary locations is a security nightmare...
Re:Don't "path" bundle components! (Score:1)
Why do you say "arbitrary"?
Re:Don't "path" bundle components! (Score:2)
As in, not:
Re:Correct me... (Score:2)
Re:Correct me... (Score:2)
Yeah, users/groups work fine, but any additional layer of security helps, and it's not so much of a performance hit unless you're in big business. We have a handful of FreeBSD servers containing lotsa jails for users, and they work great. No performance hassles expect when
Mostly great (Score:2)
Re:Mostly great (Score:2)
If (for example) zlib needed updating, you would need to get a new version of the entire package, for every package that used zlib. Or at least a diff between packages. Much more inefficient, but at least this way you're guaranteed the package got tested with the new zlib.
Re:Mostly great (Score:1)
Re:Mostly great (Score:2)
People whining about a central approach should learn a package manager (rpm/deb/whatever), which works fine.
Re:Mostly great (Score:1)
Re:Mostly great (Score:2)
The things that are included in an app "bundle" are things like the correct version of Qt. As far as I know there has never been a "security bug fix" of these. Instead all updates are "the new version" which requires the program to be recompiled.
In any case, if they remain shared libraries, the knowledgable user can delete the instance from the bundle and it will use the main shared one.
Dupes in system...=space tradeoff (Score:2)
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 ev
Re:Dupes in system...=space tradeoff (Score:2, Interesting)
Re:Dupes in system...=space tradeoff (Score:2, Informative)
Re:Dupes in system...=space tradeoff (Score:2)
Re:Dupes in system...=space tradeoff (Score:2)
You want to install a new piece of software. You insert the CD and it's window opens up in Finder (like Windows Explorer). You open up your hard drive and browse to where you want the program to go (in OS X I think it's "Applications"). You then drag the program from the CD to that folder. But you don't drag the program, plus it's data files, plus this, plus that, you drag just the program. One fil
Re:Dupes in system...=space tradeoff (Score:2)
Every mac file has two points. one for data and a resource. if the pointer to the data doesn't match the pointer in the resource for the data location it gets automatically updated. So if you move a file an alias which uses the resource to find the file, starts looking for it.
Now OS X doesn't use a lot of shared installed libraries from what I can tell, it appears most of them are installed to begin with. So install
Re:Dupes in system...=space tradeoff (Score:2)
A
This comes from the NeXTSTEP era, when a single '.app' would run on multiple architectures.
I also believe RiscOS did something similar... a file with a ! at the start (ie. !Draw, !Paint, !Browser) would be treated as an application, and would really be a folder with a set of files inside, including a loader, icon, et
Re:Dupes in system...=space tradeoff (Score:2)
Secondly data is also shared a lot (for example icons). If I update my theme, I want to update automatically all my programs the same theme. Etc.
I really fail to see the advantage of the 'bundled' approach. It is just creates a dependency hell of symlinks..
I do see why the semi-bundled appraoch on windows is a mess, but please do not take this to linux.
My idea: a package manager. Double clicking on mypro
Re:Dupes in system...=space tradeoff (Score:2)
CSH is one file.
BASH is one file.
LS is one.
MKDIR is one file.
I am not sure what the complaining is about!
Re:Dupes in system...=space tradeoff (Score:4, Interesting)
Re:Dupes in system...=space tradeoff (Score:2)
Have one directory called "links" or something like that. Each application can create a symbolic link to the main executables in that directory. Then, other than the obvious links to
On my sun workstation, one tools tell me "absurdly long path truncated" or something like that. But I have to keep the path long in order to get access to all of the tools that I use on a daily basis. Nice.
GNUstep has, and always will, do this (Score:2, Insightful)
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
Re:GNUstep has, and always will, do this (Score:2, Informative)
Re:GNUstep has, and always will, do this (Score:2)
Re:GNUstep has, and always will, do this (Score:1)
Re:GNUstep has, and always will, do this (Score:2)
Re:GNUstep has, and always will, do this (Score:2)
In fact, most of the time, starting a program undet the NeXT/Open/GNUstep/OSX environments, you're doing the clicky-da-purty-picture thing, not running the app from the command line. On the NeXTstep 3.3 machine here next to me, the unix programs are unix programs that you run directly, and the NeXT programs are the ones wtih app containers. I
Re:GNUstep has, and always will, do this (Score:2)
GnuStep is based off of Next Step which was bought by Apple and was used as a basis for OS X.
next step was also founded by Steve Jobs. The similar idea of everything intergrated for the application staying around isn't surprising.
Like ROX desktop ?? (Score:1)
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
Hardlinks and package managers (Score:2)
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
Re:Like ROX desktop ?? (Score:2)
Try Gobolinux, or GNU Stow (Score:4, Informative)
Stow: http://www.gnu.org/software/stow/stow.html
I think you will find that you are not alone
Absolute common sense (Score:2)
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
Re:Absolute common sense (Score:1)
Re:Absolute common sense (Score:1)
Re:Absolute common sense (Score:2)
Well, if no one shares it, that's fine. It's still a library, and libraries belong in one place. (although groups of libraries that belong together should be in their own directory from there)
And instead of having libgtk1.2-62 or whatever the heck i have, and having libgtk2.0-2.6.1-121 or whatever it is i currently have, shouldn't i just have
libgtk1
libgtk2
? At least until interfaces become broken, then oh my god, i might
It's called /opt (Score:5, Insightful)
The filesystem hierarchy standard also provides
Re:It's called /opt (Score:3, Insightful)
And then symlink anything that it would have installed in
Then there is only one copy of programs, libraries, and everything else but its all symlinked so that the packages can be all contained within their own dir.
Re:It's called /opt (Score:2)
Re:It's called /opt (Score:2)
Worked rather well.
Re:It's called /opt (Score:2)
On OSX, on the other hand, you're actually bundling up functionality in a self-contained wrapper: applications go in .app directories, libraries go in .framework directories, installers go in .pkg directories, etc. These bundles can, in turn, contain other bu
Global updates (Score:4, Insightful)
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.
Re:Global updates (Score:2)
Re:Global updates (Score:2)
On Mac OS X the C library is in the System Framework. Frameworks are bundles that contain shared libraries and support files. Frameworks can be either in /System/Library/Frameworks/, /Library/Frameworks/, /Network/Library/Frameworks/ ~/Library/Frameworks/ or inside the application.
Doesn't scale well (Score:2, Informative)
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 bene
Wild leap (Score:2)
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 happe
A great Idea (Score:2)
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
Re:A great Idea (Score:2)
Also, the apps in
And frankly, I'd actually put emacs into the
I would put some sort of stripped
Re:A great Idea (Score:2)
Some makes sense, like bin and lib.
Then there's man. Okay, it stands for manual. Fine. But the man program shouldn't be called "man", it should be "help".
Then there's etc. Grrr. This should be conf, or config. The only things typically in
Solve the right problem (Score:3, Insightful)
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.
Re:Solve the right problem (Score:2)
2) What's wrong with giving the *users* of the system the easiest way of doing things and letting the Administrators or Developers, the people who KNOW computers, doing the troubleshooting? The users can't troubleshoot; Administrators and Developers can.
Re:Solve the right problem (Score:2)
Re:Solve the right problem (Score:2)
Re:Solve the right problem (Score:2)
Re:Solve the right problem (Score:2)
The most glaringly obvious example is that the current structure is made so that as many files as possible can be 1)mounted on read-only drives 2)shared across machines.
If you read the fhs, it makes these points very clear.
Re:Solve the right problem (Score:2)
Sure, you could have seperate distributions for seperate user bases. If you think that's a good idea, go help with GoboLinux. In the mean time, stop trying to insist
Re:Solve the right problem (Score:2)
Re:Solve the right problem (Score:2)
But this is precisely how OSX solves the problem!
In the Finder, which is how novices and people uniterested in system internals will spend most or all of their time, you only see the application (etc) bundles, and the other functionality is hidden from view. Moreover, key system directories (such as /etc, /var, and /usr) are hidden f
Re:Solve the right problem (Score:2)
Re:Solve the right problem (Score:2)
The $PATH variable works in the usual sense on the command line -- it typically looks for commands in places like /bin, /usr/bin, /usr/local/bin, ~/bin, etc -- but it doesn't appear to be relevant to the GUI, or to the open command which can be used to open files in the GUI (e.g. open -a Safari ~/Sites/index.html).
As near as I can tell, /Applications is the GUI analogue to */bin directories, and the Finder is just transpar
Re:Solve the right problem (Score:2)
Are you a GNOMEite? At a fundamental level computers are different for different levels of users. The thing which improves usabilty is a smooth transition from level to level.
Don't think that having an "Expert mode" UI is inherently bad, it just happened to be a bad idea for a certain file manager.
make linux more popular to beginners (Score:1)
I've known plenty of places that do that. (Score:2)
Probably the arrangement I've seen the most often is to have a directory tree under /opt, or in /usr/local. The top-most directory is the application name. The directories under that contain the version numbers. Inside of that, you have the usual bin, lib, libexec, share, etc.
This is much more practical to maintain, on modern Linux systems, as many important
This scheme has no advantages. (Score:5, Insightful)
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
Re:This scheme has no advantages. (Score:5, Interesting)
1) PATH variable only applies to CLI applications. Apple solves this problem by putting CLI applications in the standard UNIX places.
2)
3) Shared libraries cause as many problems as they solve. Modern computers aren't short on RAM or disk space and there's no need to use them.
4)
5) I have no clue what you're talking about on this one.
6) Bundles should be as self-sufficient as possible. The only external applications they should be calling are those that are *guaranteed* to be there.
Re:This scheme has no advantages. (Score:3)
Sadly, libraries aren't similarly short of security problems. This is what happens [gzip.org] when a library that is commonly statically linked is found to have a security vulnerability. [gzip.org]
Re:This scheme has no advantages. (Score:2)
* More diskspace usage (we have settled on that).
* More RAM usage (I can settle on fact disks being cheap, RAM is not cheap IMHO and it is never too much of it for me, I don't waste my RAM on crap).
* More disk
Re:This scheme has no advantages. (Score:2)
> software packages
Well that was handled already. Just dont put everything to system like "make install" but add another layer to this proces and use package management system. F.e. RPM (I know there are others and do the same, I'll focus RPM only) - if you want to know which files came with package do: rpm -ql foo, if you have a file in FS and want to know which package it belongs to do rpm -qf
Re:This scheme has no advantages. (Score:2)
However - I love
What would be nice is a standard way of installing something from a tarball which puts something, lets say
That way, removal becomes something as simple as rm `cat
Re:This scheme has no advantages. (Score:2)
For one thing, it's a lesser known software package, which means that after you get your Ph.D. the slackers left administering your old research lab may be forced to learn new tools.
Keeping files in FHS locations has a few other benefits: most of your files can be static and shared between computers, and if your applications are FHS compliant then it's not too complex to make most of the
Not even worth discussion. (Score:4, Insightful)
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. (:
Re:Not even worth discussion. (Score:2)
On the other hand, I may have originally misread what you were getting at. So, if that's not what you meant, I'm afraid my answer is different..
Bundling apps / libraries in the sense of giving them their own directory and then symlinking back to some common path like
Re:Not even worth discussion. (Score:2)
1) A security flaw in an application is the responsibility of the company who created that distributed that application and it's their job to inform users and fix it.
2) Users don't give a crap about this, as long as their applications run. 95% of users don't know how much disk space an application takes up.
3) Again, users don't give a crap about this.
Re:Not even worth discussion. (Score:2)
What if the company has gone out of business? Not to mention that users don't want to have to update everything when a bug is found in something like glibc.
3) Users don't want to deal with dependencies. If you tell your computer to download and install, say, a video game, the user doesn't want to see your computer downloading funky-happy-m
Re:Not even worth discussion. (Score:2)
Most users don't know how to check memory usage and/or disk usage.
But most users DO notice when the hard drive starts making noise and the system slows down (paging).
And most users DO notice when they have to go deletin
Re:Not even worth discussion. (Score:2)
This is the problem with (most) Mac users. Proprietary thinking, not Open Source thinking. so... You've obviously never used a modern Linux distro based on your comments. Besides the ones about not caring about performance, every single one of your points assumes that we're talking about proprietary software from a vendor. In the world of Linux and Op
Re:Not even worth discussion. (Score:2, Insightful)
App Bundles can be configured to search installed system libraries first. This also solves the security update issue. The bundled libs are only used as a last resort.
Regarding config files and
Can someone explain the problem a little better? (Score:2)
It's a step backward (Score:3, Informative)
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.
pkgsrc (Score:2)
More information:
http://www.pkgsrc.org/ [pkgsrc.org]
http://www.feyrer.de/Texts/Own/21c3-pkgsrc-slides
Please RTFDocuments before commenting! (Score:2)
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 o nceptual/SystemOverview/Bundles/chapter_4_section_ 1.html [apple.com]
-Ster
For local packages, stow, for other stuff just deb (Score:2)
apt-get install package
A proper soft file system would be a boon for this (Score:2)
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 dev
ROX (Score:2, Informative)
ROX [sourceforge.net] (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 [0install.net] insta
App Bundles (Score:2)
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, c
Re:App Bundles (Score:2)
Package Management does "just work" the problem is a major implementation issue, IE your app isn't compiled for your distro, Or RPM has dependencies of libblah.so.4 when you have libblah.so.5.
Apt works, and it works perfectly, but like all things its implementation dependant, your reliant on getting a packag
/etc is great (Score:3, Insightful)
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).
Re:/etc is great (Score:2)
OSX has an answer to this as well. By widely accepted convention:
Re:/etc is great (Score:2)
For values of "shitload" where "shitload" equals "three", yeah.
possible but not consistent (Score:2)
klik (Score:2)
One existing user of bundled applications on GNU/Linux is klik [atekon.de] 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 ent
Web site won't give me any info from Windows? (Score:2)
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.
Philosophical differences? (Score:2)
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").
consider using the package manager for your distro (Score:2)
(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).