Have you ever wondered why in other Operating Systems such as Windows, MacOS or even BeOS installing software is so easy compared to Linux? In such OSes you can simply download and decompress a file or run an installer process which will easily walk you through the process.
Post a Comment
It's pretty simple to do this anyway, any provider not writing using standard libraries can end up using "runme" style scripts, it's not a problem.
Using standard libraries, though, is always the best bet...what we need is a standard installer other than the "./configure && make && make install" way...users don't want to compile if they don't have to.
I say a installer that knows how each major distro is setup and copies the files to the right place based on that system.
Maybe...
Compilers in linux seem to be A MUST! if you are planning
to install software. _why_ do you need to compile it in the first place? Most people uses packages than the ones using compile-only distros (like gentoo or lfs). They shouldnt be
there unless you are a developer. Also remember that global
installs are very insecure compared to user installs, so this "promoting all global" tends to increase insecurity.
Also remember, there is a lot of people against this kind of ideas because they think they kill opensource.
First, the reason why everything is so easy to install and works on Windows is because no one really shares libraries (actually in Windows XP this is a feature?!?!? will keep multiple dlls for each app). Every application installs it's own dlls and uses it own dlls even when these libraries could be shared by every other app (example mfc). The exception to this rule is of course Microsoft dlls that ship with Windows. But Microsoft does the smart things and emulates old versions of the standard dll's behavior (usually you have to request a certain version).
Contrast this to Linux where many shared libraries (ddl equivalent) are used by many different apps and you run into dependency hell (dependency hell is just what the user sees. in reality its different apps wanting different versions of a library).
So, what needs to happen in Linux? Right now, we have every distribution shipping their own packages compiled against their own libraries. This works if you only install binaries from your distribution. To effectively allow linux users to download a single binary for any distribution we need the library programmers to provide versioning within the library. This of course is a big task.
Finally, the rest of the problems (where to put stuff, etc.) is relatively easy to solve.
if you don't also offer the source in .tbz2 format or some other form of distribution method.
I agree that not everyone should have to compile a binary. I don't believe that global installs are any less secure using binaries than compiling source. If the source is available, who cares?
Not everyone goes through the source, nor should they have to. Include it in the install package if you want...make a directory called 'src/' and allow people to compile it if they want.
The installer is possible because major distributions don't usually change their filesystem layout at all, that would confuse 3rd party developers more.
a frigen PERIOD!!!!
my god, that is so damn simple why doesn't the LSB define it!!!!
they a program can bundle the libs in its own dir that are not in the LSB....for god sake!!!!
and no, I do not se this as makeing more problems. as a desktop user, I don't care if I have 5 instances of a library open in memory. sure, if you have a server set up, then by all means, worry about it, but for a desktop set up, function before form holds true, as with any consumer product....if it does not work well, no matter how cool it looks, it sucks.
LSB....please please please FIX THIS
Nice to see a insight into Linux issues without whindgefest 2002 being lauched, and every Windows/Linux fruit cake come out and throw their uneducated rant into the ring.
As for the issue with packages and so forth. In a perfect world, everyone would simply base their distro on Debian 3.0r1, and life would be easier, however, this isn't a perfect world, and there are zealots in various distro camps claiming their way is the best way, and should be the only way.
Personally, I prefer the portage system that FreeBSD uses. Change to the director, type make then enter, sources are retreived and patched, once compiled, then make install, voila, no problems.
i agree, that's a simple fix for standard desktops, where computers are known for having at least 128M of memory and no services running (apache, dns, etc).
What are the security implications of doing it this way, though?
> First, the reason why everything is so easy to install and
> works on Windows is because no one really shares libraries.
Yeah, that's kinda it. Why sharing so many weird an rare libraries causing dependency mess? The core ones can
still be installed system wide and that's pretty much all
of it. My debian install has nearly 4 years and I seriously have an enormous amount of software installed, even with that, check this:
red@server:~$ du -ch /usr/lib/*.so* | grep total
226M total
That's not likely to bother my 80 gig hd if programs
ship these many times, assuming most of that space IS
taken by core libs.
That is what I said years ago that Windows should have done. If these vendors want to haul dll's around with then, sure, by all means, but don't ram them into /windows and then complain because you have broken the users system.
As for developers who use weird and wonderful libraries they KNOW won't/don't exist in a standard distro, then either include in the directory the library, or statically link against it. IIRC, that is what TheKompany does to get around this problem. All their applications are statically linked against qt.
I also think that the LSB doesn't cover enough. It needs to exactly specify where EVERY is located and what versions of what libraries should be in a certain place. For example, LSB Supreme could cover that gtk2, glib2, qt3 must be included and placed in the directory /usr/lib. Then state that the library directory /usr/local/lib is setup so that those who do compile and find their application is moved into the "/usr/local ZONE!" can run their applications with out the application moaning because a library doesn't exist.
Why? there are a hundred of VERY popular opensource
windows applications where the regular users just get binary and the developers work on the source, to name a few:
zsnes,virtualdub,dev-C++,putty or scummvm. As for the people using redhat, they mostly dont compile and that hasnt killed opensource.
This kind of things constantly make me wonder about easier ways to distribute the software for users.
How about static linking instead of dynamic. Have you considered that as an option? I haven't done much programming in Linux so I don't know if this is possible in Linux. It probably is. I am aware that static linking will make the executable slower then when linked dynamicly but I am running P4 2.0 with 256MB DDR and I don't see any difference in speed in my own programs when I static link them. Probably because I have a fast machine. Still however, perhaps if you distribute your files both ways one static linked so all the user needs to do is run the file and one non linked so the user must compile it. The last resort is, make a GUI install program :-) but there isn't such thing as "InstallShield" in Linux which just supports my theory I said once in my previous posts.
It's only opensource if I can get the source code and compile it myself. Proprietary software is when a user gets a binary and ONLY the developers get the source code.
If you want to release binaries, go ahead, but the GPL demands that if the end user gets the binary, he can also request the source code...if he doesn't get it, it's not GPL software.
If I want to distribute under BSD, then that might be different. But in order for it to be open source, the code still has to be available.
>i agree, that's a simple fix for standard desktops, where >computers are known for having at least 128M of memory and no >services running (apache, dns, etc).
>What are the security implications of doing it this way, >though?
Not many, a very old exploit was to make a fake lib that a suid root program needs, change the path and make the suid program link against it. But this was solved long ago (althought i really dont know how) if you try to do it, it will not work. Besides that, i cant see any security issues.
That's your opinion, and i respect it, and also agree in part.
But I guess the term opensource (and specially in the GPL)
is very well defined already, and it differs.
It's not an opinion...it's cold hard fact that OpenSource means that the source is open, available.
If the user wants it or not doesn't matter, it's wether it's available for those who want to improve it.
Many companies try to pass their software off as opensource, like Sun did with their solaris source code. While it was available, and open (yes you could use it to build solaris), it wasn't free software.
Opensource projects will allow their users access to the source code. While I don't run windows, and have no knowledge of zsnes and the other projects you listed, can I download the sourcecode to contribute? If not, then there's no fine line, it's closed source.
Linux is based on the GPL. If you want an easy to install version of a program that statically links against GPL libraries, then you have to provide the source.
It's not a war on licenses, if you want to provide a closed source package, go for it. Just don't call it opensource if it's not.
I can get the putty source code from their cvs server, it is GPL'd, and has been since day one.
I don't know about the others though, just because the package doesn't come with source code doesn't make it not opensource...they distribute it from their website.
You and I are on the same page, I just think we got mixed up a little...Sorry for that.
What's really funny is that the source to most BSD projects is much more readily available than a lot of linux projects 'protected' by the GPL.
Look at some of these new desktop linux distros, how easy is it to get the source for them? Oh yeah, the source is available -- but you're not going to get it in a terribly useful form. What good is source if it comes to you on 842 5.25" floppy disks? (yes this is a satiracle exageration).
umm..lets see:
open box....look for source CD.
hmm that was simple.
What distros are having problems getting source from? RedHat offers them all on cds when you buy it and from their ftp site, Suse does the same, debian, you can get those with apt-src, gentoo? well just run emerge 
The bsd source is distributed in tar archives just like linux...that's not the point though.
THe point is, the source is available.
If you develop a program and want to make it opensource, you can just put the source on your website, or make it available to order through the mail.
It doesn't have to go into the package. It just has to be available.
Zsnes and all the other packages that were mentioned are sourceforge projects, its usually not all that hard to get the sources to those eheh.
One of the few good ideas Mac OS X had was bundling. In essence, instead of installing applications, you drag a single icon to the appropriate folder. The icon was really a folder, but with metadata instructing the OS to treat it as a single file except when using special programs.
Linux should take a hint. Scrap RPM packages, and in their place use metadata-based bundles. To install an app, the user drags it into their /usr/bin folder (or /bin, because /usr shouldn't exist... go gnu hurd! 
). If an app requires library support, the user drags the appropriate library bundle into their /lib folder. If an application requires pre/post-install/deinstall scripts, then well, it shouldn't. Use Office-style "First Run" scripts if absolutely necessary, but there's no reason why a bundle shouldn't come preconfigured.
A very simple and elegant solution, with the added plus that there is no central database to maintain. And technically you don't even need metadata, but rather just a smart bash and/or filemanager.
I didn't say the source wasn't available. I said it wasn't available in a terribly useful form.
How many of you can ftp the entire source for your distro and build it from scratch? I'm running windows on this machine, now how easy is it going to be for me to get the source for Xandros and somehow magically turn this machine into a Xandros box?
I don't want to start a licensing war here but think about it. The GPL doesn't really protect any better than the BSDL. There are a million ways an evil company (like microsoft) could legally make acquring the source a huge pain in the ass. Where's your GPL protected freedom then?
> There are a million ways an evil company (like microsoft)
> could legally make acquring the source a huge pain in the
> ass. Where's your GPL protected freedom then?
It's true that the GPL will have little effect on an evil company in Seattle (or Cupertino for that matter) using GPLed code illegally. What the GPL does is promote a certain culture. Companies that use the product are more likely to be hacker-friendly companies. Apple and Microsoft both use BSD-licensed code, while RedHat uses GPL. Compare the culture at the companies. I know where I'd rather work, and it's on the East Coast...
Additionally, it can sometimes be used as a legal threat against companies that proclaim to be using the product. Take Lindows, for example. Obviously it is a Linux distro, but it initially did not release its modified source. Pressure and threats of a lawsuit forced it to do so. Had Linux been BSD-licensed, Lindows would have stayed closed source forever.
"1-Distribution by physical place"
This has always intrigued me... what's the difference between /usr/share, /usr/local/, and /usr/local/share? What are the rules for where programs go? It's pretty confusing, even for someone with some *UNIX/*BSD experience... it's always fun to play "where did the binary get installed" game :-)
"2-"Global installs", or "Dependency Hell vs Dll hell""
I think "install by dir" would work, as long as you separate the user's home directory from the user's installation directory. One of the nicest things about the UNIX .files is that they allow _very_ easy backups. In most cases, tar.gz up your home directory, backup, install/upgrade/move to new computer, and untar away and you're done (given that the config file format didn't change between versions, if applicable). Perhaps a /home/{username} and a /app/{username} would be a good idea, as it would allow both per directory installs _and_ simple backups of personal data. I really like the *NIX custom of separating user data and programs...
"3-Current DIR is not in PATH."
I believe the reason this is not done now is for security reasons. Case in point, say a rogue .tar.gz file you downloaded decided to install a new 'ls' in your path when you ran the program. This would not only affect you, but any user (including root) that happened to cd into your directory. Since root ran your 'ls', it's now operating at an elevated level... `rm -rf` anyone? Now, this shouldn't happen as long as you have the correct order in your path, but you can never be too careful.
However, to use the /app/{user}/ scheme above, if for each install you had, a shell script was placed in /app/{user} then all you would have to do is put /app/{user} in your path and you're done. Installation/removal would be as simple as removing the directory and shell launcher script, and simple GUI tools could very very easily be created. If your personal data is separate, there'd be the extra step of having to manually make sure to delete the appropriate .directory.
"4-No file metadata."
I wonder if a standard section could be added to the ELF binaries that all file managers, etc look at when looking for specific info (icons, etc). This might allow backwards compatibility, although my knowledge of the ELF format is almost nonexistant ;-)
Most of these problems could be handled by appropriate recommendations/standards set by LSB (or even Redhat). Something tells me that that won't happen, or if it does then nobody will follow it.
Why do people have to troll about this? It's getting pretty lame already. Why do you pick on Linux? If you dont like it, dont use it.
Mod me down, if you will, but Linux is great because of it's diversity. You can use it practically everywhere, there are no "standards" other than simple Posix ones and usually, each distro has it's own great packaging format.
As someone once said, Linux has been going for 12 years and it's a diverse place. Linux does not need to appeal to Windows/BeOS/MacOS users. If they wanna switch, they WILL do it no matter what and they WILL learn it no matter what. It's that simple.
So basically, dont be a troll about it - there are several operating systems for people like you...
License does not control the way that the source is distributed. If you want the source, you CAN get it no matter what license it uses. And GPL is more mainstream than BSD, so companies like Redhat, SuSE, etc use GPLed software. And they dont really want people changing much (it's a feature, not a bug, since who the hell recompiles their redhat system from source anyway?)
If you want it, it's always there. But RedHat, SuSE, Xandros, *insert major linux distro here* does not want you to recompile your entire OS nor does it expect you to do that. You've got Gentoo or LSF for that. I know, I use Gentoo mainly.
perhaps they can move of this horrid Linux package crap and implimnet a simple app install.
How about static linking instead of dynamic. Have you considered that as an option?
It could be a solution, but IMHO not the best one:
if you link statically, the running programs won't share the common code of the library in RAM, because it's "buried", so to say, in the application itself.
In this case the library size adds up on the disk AND in RAM.
But if you distribute the dynamic libraries with the application, the size adds up only on the disk, while the OS is able to share the memory for those libraries (given that they are the same version).
This, I think, is much preferable to the current approach
because applications WILL ALWAYS RUN no matter how old and non-stantard your distribution is (well, within limits :-))
.
But of course this requires a directory layout where it's easy to bundle applications with their own libraries, a layout that I would call "application-centric"
(AtheOS has a great example of the concept).
I am aware that static linking will make the executable slower then when linked dynamicly but I am running P4 2.0 with 256MB DDR and I don't see any difference in speed in my own programs when I static link them.
AFAIK, libraries linked statically are slightly faster,
but the difference is probably not noticeable in
real-world conditions.
So basically, dont be a troll about it - there are several operating systems for people like you...
Yeah, I can'y wait until eComStation gets released. That thing is good! You've got the ease and look of Windows and stability of Linux! hehe Ok come on, flame me....I know you will
Run-time, statically linked binaries are slightly faster, but perhaps not noticeably so (unless they use lots of libraries all over the place). However, loading times of statically linked binaries are much much smaller than those of dynamically linked binaries.
Why do people have to troll about this? It's getting pretty lame already. Why do you pick on Linux? If you dont like it, dont use it.
It's not that we don't like it we love it and want to make it better. Making a few standards to make installing binaries a painless thing won't kill linux or reduce your choice or freedom. Reasonable standards will only increase choice
So basically, dont be a troll about it - there are several operating systems for people like you...
Elver, "several" is opinionable.
Today, if you don't count really alternative OSes or OSes running on proprietary HW (sorry, I used to love MacOS but closed HW platforms are no more on my list),
the choice boils down to Linux and Windows.
And Incognito writes:
It's not that we don't like it we love it and want to make it better. Making a few standards to make installing binaries a painless thing won't kill linux or reduce your choice or freedom. Reasonable standards will only increase choice
Exactly!
And about improvements, do you think possible an overhaul
of the directory system towards a more "application-centric" one... something borrowing from the app-in-a-directory concept shown in AtheOS (I repeat myself today!) and ROX Desktop?
I think it's possible, and can be done while still keeping compatibility with Unix, but I would like to hear other opinions...
Also support for file metadata, or maybe even better, file attributes, would do great for a desktop OS:
I have seen the power of having arbitrary attributes on files, and I am a believer now :-)
Well, you could say that my views are influenced too much by BeOS, which I've used alot in the past, but in my mind it's still the reference model of an agile desktop,
and it would be great to see Linux [for the desktop]
evolve in that direction.
Ah, this reminds me that I haven't looked for my flame-suit...
mmm, let's see, I thought it was here :-)
Programs that come with the distro really ist a problem, its mostly writing a userfriendly frontend to the package managment system, apt or urpmi (or whaterver its called)
If the user wants to install say SuperShinyApp 3.0 that isnt in the distro, he should be able to download supershinyapp-3.0.bin from supershinyapp.org and just right click on it in konquerror and make it executable, then double click it. It should then install to /home/bni/supershinyapp or something like that.
Take a look att the installer for Quake 3, it does a lot of things right, it even has a GTK GUI!
There is really no reason why for example mozilla couldnt hand out a file like this, with obscure libs that it uses statically linked. So what if it takes more memory, it is only a temporary solution until it becomes part of the distro.
I realise that installing in users home dir opens up for viruses, becouse of writeable executables, but I think its less of a risk than Windows anyhow, partly becouse you explicity have to set a file as executable.
try that with . in your PATH:
as a user:
echo "rm -rf /*" > /tmp/ls
as root:
cd /tmp
ls
aaaargh !!!!
you also have to do chmod +x /tmp/ls as a normal user. Else it won't "work".
Don't try this at home kids. Just in case you didn't know, that can wipe out your hard drive :-)
What are you saying ?
I use Linux for lot's of thing but one of them is the easy installation of software compare to Windows.
Windows seems to bea easy : clic clic clic wait....done.
Now uninstall this software : clic clic clic
"Do you want to remove RE998R8E.dll ? It can be use by another program"... Uh ? Yes . BOOOOOMM !!! You lose. You just crash your windows after rebooting
Other stories : installing an image viewer need to reboot the system. If you don't reboot a BSOD will help you.
Now linux version :
rpm -U pipo.rpm
rpm -e pipo
What's difficult ? Just use package made for your distribution.
And now it is more and more easiest :
urpmi pipo
or
apt-get install pipo
Don't know has easiest in Windows or Mac World
Here's my proposition:
Developers bundle the binary and all the (uncommon) necessary libs in a tgz archive. The tgz file should contain a "bin" directory and a "lib" directory. This tgz archive should also contain a "meta.xml" file containing infos like the icon file, the entry in the menu etc...
The tgz file should be called, for example, myapp.pak.
Then, we create an installer that will handle those ".pak" archives. It should de-tar the archive in /tmp and look for the meta.xml file.
Then it should create a "myapp" folder in ~/, add an icon on the desktop, add an entry in the menu and (the most important part), add the path to the "bin" and to the "lib" directories in the user's path (in a permanent way).
The app would be installed for the user. It could then be de-installed by removing the ~/myapp folder.
When you re-start your GNOME/KDE/whatever session, it should look for broken links in the menu/desktop and remove them so that the removed apps totally disappear from the user's system.
Is it technically feasible without modifying UNIX bases ? If yes, I'd be glad to help in such a project.
All your 4 points were irrelevant regarding ease of installation and running installed applications.
Important things for end users are:
- know where to find precompiled binaries (including related binaries)
- know how to use rpm, deb, installation executables (this is easy)
- know how to launch them
Mono applications run anywhere you put them,
and you can use any version of a library cause
mono checks in the same folder as the .exe for them.
You only need to install mono, and all mono-based apps just run.
"First, the reason why everything is so easy to install and works on Windows is because no one really
shares libraries"
But they do on Amiga, where installation is even easier than on
Windows. One reason is that a program cannot specify a single version
of a shared library, but only the oldest acceptable version. So only
the newest version of each library has to be installed, not multiple
versions.
1. just putting "." in your LD_LIBRARY_PATH is not a good idea. That assumes that the current working directory is the binary's path, which is not the case when you start an app on the command line. Nor want you the app to change the cwd, because you may give a relative path as an argument to the app. The dynlinker needs to be enhanced so it can find libraries at a location relative to the binary
2. One problem with distributed packages that has to be solved is the PATH. Many old-school unix users want to start their apps on the command line, and people will not accept a solution that doesnt allow this.
3. The mac os bundles do have a few problems that make it more difficult to apply them to the linux world. Some programs *need* to run pre-install scripts. Basically all apps that need to install themselves as /etc/init.d scripts. Unless, of course, you want to change the whole boot process (which is certainly not a good idea for compatibility reasons, and the boot process as defined by LSB is nice& clean).
I install RPM files using my Redhat, and it's installs itself.
And using package handle, it is easy also to remove it from my operating system.
There is already a standard for menu entries, icons etc that is used by both KDE and Gnome: .desktop files.
1.I agree. Maybe the best way is to app each app's folder to the LD_LIBRARY_PATH but it may slow the system down, no ?
2.Here again, adding each app's folder to the PATH could make it but it might slow the system down if you install 1000 apps for example.
3.I think that apps that need to be installed in /etc/init.d scripts are not end-user apps. The problem is only with very end-user apps because people who want to install servers or non-GUI apps should be able to install them easily. More over, with such "dangerous" apps, they should always use the apps provided with their distro to avoid security problems.
Yas you're right, the meta.xml file should be dropped and replace by a myapp.desktop file. In fact, the only remaining problem is: how to add the app folder in the LD_LIBRARY_PATH and to PATH in a clean way.
"pkg_add -rv <packagefile>" will fetch the binary, md5 checksum it, and install it. what can be easier? if you want to compile from scratch "cd /usr/ports/...; make; make install" all dependencies are downloaded, compiled and installed. want to remove something? "pkg_delete" and "make uninstall".
just use FreeBSD.
Basically I want to look into what it takes to put this kind of metadata into the journaling filesystems like ext3 and reiser...
I fell in love with BeOS for one reason...the query system. If linux had that ability, it would be amazing and it would open up the system a lot for ways data is handled.
But that also opens up the ability to store metadata like MacOS does with icons, etc...
Anyone think it might be possible?
pkg_add -r prg
and 5 seconds later prg is installaed and working.
No problems with dependencies, where it dl'd from
or where it installed. "It just works."
But then, it's BSD.
apt-get install <name of package>
Boy, that's tough. Or for those who can't do that (maybe their machine doesn't have a keyboard??), use Synaptic, and click on the programs you want. I don't know, maybe you should have a CS degree before you attempt that.
I can't see how it can get much easier. It isn't a matter of difficulty, it is a matter of familiarity. It is really, really, simple to install Linux software if you get pointed in the right direction. Even my wife was astonished when I showed her how easy it was to download and install stuff from the Debian archives.
apt-get will only install software from the debian repositories which certainly won't help when you download some shiny beta sourcecode from a distant website.
The point here surely is that you can run into all sorts of problems when you want to wander off the beaten track. SuSE pacakge-manager and SuSE YOU will get me over 5000 pacakges, however what can I do if I want to install the lastest version of KDE? I have to compile it myself and that's when I run into dependency issues.
It would be nice to sort out such issues. Projects like autopackage (http://www.autopackage.org), which was recently discussed here at OSnews, seem like good solutions. They expand upon the dependency resolution features of apt-get but do not rely on a single repository.
IMO it would be sacrificing some of the good things about Linux if everything became statically linked or hundreds of redundent libraries scattered the filescape for the sake of brains-free installation. We should instead work on creating a decent method of dependency resolution so the user doesn't need to be concerned.
So as said, Linux is fine for dependency troubles as long as you stick with your distrobution's methods of software installation. If you want to move beyond that, for the time being at least you must have some patience -- a solution will emerge. Personally I just really hope it isn't of the "bundle a graphical installer variety" (I've nothing against graphical installers, providing they are part of the system, not bundled). As said, people without the patience should probably switch OS.
Yes, that's perfect for "normal" packages. I mean those who are on your debian CD. But if you want to install "foreign" packages, you also have to edit your "source" file. That's where it begins to be tough. Of course that's quite easy once you have understood the concept and made it once or twice before but for a newbie, that's yet another thing to learn. More over, apt-get isn't installed by default on every distribution and packages are still not compatible between apt for deb, apt for rpm for RedHat, apt for rpm for Suse etc...
So, yes, in theory your solution is ideal but that's just theory. The fact remains that if you want to make a package from your software, you have to create an RPM for Red Hat 8, one for RH 7.3, one for Mdk 8.x, one for 9.x, one for cooker, one for Suse 7.3, one for Suse 8.0, one for Debian, one for Slackware etc...
And, like most developers, you end up doing NO package at all and providing source only because it's such a mess to create packages. And users go to your web site, find a tgz file, maybe they even happen to install it, but, then, their whole packaging system is corrupted... Finally, they end up complaining to whoever they think is able to solve their problem and articles like this one appear on internet... and people think "waow, linux is so complicated"...
I was once looking for really alternative and tiny WMs for Xfree. I found ROX. It's a bit like BeOS, I like it a lot anyway. Try it!
http://rox.sourceforge.net/
Matthew,
While I use Debian and I think that it's package management is very nice... there are still other issues. I for one still like to use the occasional commerical app. JBuilder, to name one. Well, After tinkering a bit, I made a symlink from one libstdc++ lib to a newer one, and got it working... well, I installed a newer version of mozilla, which in turn installed a new libc, which in turn broke JBuilder. Library management on Linux is not nice. Same on Windows... I think the idea of distributing apps in their own folder is a whole lot easier... not package management needed. Just unarchive, and go. It should be that simple.
By Aleksandr (IP: ---.ne.client2.attbi.com) - Posted on 2002-12-16 05:47:44:
One of the few good ideas Mac OS X had was bundling. In essence, instead of installing applications, you drag a single icon to the appropriate folder. The icon was really a folder, but with metadata instructing the OS to treat it as a single file except when using special programs.
Scrap RPM packages, and in their place use metadata-based bundles.
A very simple and elegant solution, with the added plus that there is no central database to maintain.
I was going to propose this.
Really, the idea of an executable archive is too good. The key is the desktop hook. The desktop needs to understand how to work it, and the shell only needs editing tools.
A standard installation program can be used, such as Loki's setup.sh. Loki's setup allowed you to chose your installation target. The installation tool should be provided by the desktop environment, but one should be includable with the archive. Reasonable dependancies should be included for installation if they are not provided for.
The user should have the ability to "Install Globally" or keep the application itself sitting on his desktop if he desires.
I think dependancies should be defied by keywords. The metadata itself isn't all that important, as long as the installation programs are smart enough, consistent, and the metadata format is standard.
I also think the /opt heirarchy should be used, starting inside the /opt/ directory. A simple global install could drop the archive in the /opt/ directory, or extract it.
I think it's a reasonable idea. It has already been proven to kick ass on MacOS X.
Solutions for linking are:
- allow the ELF binaries to specify (relative) paths for libraries and let the dynlinker use them. Probably the cleanest solution, but requires many changes in the linker and binutils
- allow paths relative to the binary in ld.so.conf and LD_LIBRARY_PATH. This would either re-define how relative paths are evaluated (both the binary's path and the cwd) or require some special syntax. Both can have backward-compatibility problems
Solutions for PATH:
- whatever unpacks the package must create symlinks from the package's binaries to some common directory. This directory must be in PATH, and could either be /usr/bin or some new dir, like /Applications/bin
i used debian (Knoppix hd-install) and did "apt-get install licq", but nothing happened, no such package, something about obsolete and dependencies that aren't there. I don't know nothing about these stuff, but simple??? It didn't worked, for some reason. I guess, the solution would be simple, but you have to know. But i don't know, so NO is wasn't simple. NO LICQ!
The way i want to install a program, is by going to the product website, download, click and follow instructions and it works. How this is done, i don't really care, cause i'm not interested in programming, i just wanna install and use a nice (non programming, but chat, photo-editing, multimedia or whatever) program that i see somewhere on the internet or (when linux becomes more popular on the desktop) that comes on a cd (in a comp. magazine).
> whatever unpacks the package must create symlinks from the > package's binaries to some common directory. This directory > must be in PATH, and could either be /usr/bin or some new > dir, like /Applications/bin
The problem with linking to /usr/bin is that you need root access to write into it. I think that's the same problem for any directory that's in the PATH. A good solution might be to simply put the absolute path to the binary in the .desktop file. For example, if you install "LimeWire" in ~/Apps/LimeWire, the .desktop file should point to ~/Apps/Limewire/bin/limewire.
RPM works fine if you have the correct version built specifically for your system. Otherwise you end up having to install many libraries to cure a web of dependencies.
apt-get and BSD ports works fine to sort out this web of dependencies automatically, if you have a fast internet connection. But many people only have a phone line, or maybe not even a connection. So upgrading many Mb of libraries to cure a dependency problem is not necessarily convenient.
Compiling from source reduces many dependency problems, but means that the package manager does not know that you have the software installed. Uninstalling such software can be a nightmare, as it is difficult to know where all the resoutces were installed to.
The best solution I have encountered is the ROX application directory (app-dir) method (borrowed from RISC OS).
Similarly to the Mac OS X application bundle (borrowed from NeXT) it bundles required resources into one directory and the desktop visually renders the directory with an application icon rather than a folder. Double-clicking the directory runs the application inside, rather than opening the folder.
Installing the application is just copying the directory (i.e. the application icon) to the desired volume. Uninstalling it requires deleting the directory (ie the application icon). Relocating an application is just dragging the icon to another location.
Shared system libraries can be bundled in their own library app-dirs. If an application requires its own specific local version of a library, it can be included within the app-dir.
Calling these applications from the command line can be accomplished with a very simple BASH patch. The only requirement is that the application directories are stored somewhere within the system path (but note the path does not need to include the application directory).
Applications can be delivered as pre-compiled binaries or as source code. When the application is run, if a binary exists for the current OS and processor, it is run, else the application compiles (if you have access rights) and runs.
The installation of system wide or user local installations are supported easily by this method.
There is a project underway to build a Linux distro around ROX app-dirs. It is in the very early stages, but urgently needs contributors. It's (initial) web site is at
http://lemmit.kaplinski.com/home/green/Linux/
ROX is at
http://rox.sourceforge.net
The introduction of the article is way off. Installing can actually be, and most of the time is, easier than with any other OS (with great tools like apt-get). Linux does have trouble with install paths and the like, but that is not was the article suggested in the intro.
And second, suggesting ./ to your path is just plain evil.
in BeOS, the LD_LIBRARY_PATH includes %A/lib, where %A is mapped to the executable's location.
So /beos/my-app/my-app can have custom libraries stored in /beos/my-app/my-app/lib/my-app.so etc.
The LD_LIBRARY_PATH also includes the standard library directories as well as ~/config/lib (which is more or less /usr/local/lib, since BeOS was single user)
Also, look at GNUstep. I'm not entirely familiar with the directory layout, but applications are stored in directory bundles with resources, propert lists, images, and other goodies, rather than just being a binary file.
Is it possible to add %A to Linux' LD_LIBRARY_PATH or is it BeOS-specific ?
I doubt that Redhat and others will do this but...
Include apt and synaptic or even better tie the package management tool for Redhat 8 for example to trusted apt sources.
No command line!
You just get the latest list of applications packaged for your distribution.
In synaptic you click on the app (let's choose one with dependencies from hell) like totem or rhythmbox and click install.
It just happens. All the dependencies are worked out and everything is installed on your box. If you want the latest greatest bleeding edge garbage that you probably should not install yet anyway then include some other sources for your apt stuff (I include Nyquist's RH8 rpms for the latest XFT/GTk2 choose your opensource acronym here rpms).
What if I want to use such-and-such software that just went beta two seconds ago? Well, like any freeware/shareware/GPL software for any OS you find on the net you better be ready to compile it yourself.
Gosh, if no one has ever built a package for the software you end up using the source. Yeah, that is the case for BSD, Mac OS X, linux and Windows. I have grabbed beta software for Windows from this or that Opensource project and guess what I had to compile it myself because it was not ready to be packaged yet.
Honestly I think part of the problem are old-school guys on the mailing lists and boards who when asked how to install something either spout out rpm -Uvh or configure, make, make install impulsively.
Half the time if I see some tiny utility on the net in rpm format I want to install and there is no apt repository for I can still install by downloading the thing and double-clicking on it. I then ask the author nicely in a email to submit the rpm to freshrpms or something.
just thought I'd point out that microsoft does use gpl'd code. they use it in their unix compatibility tools or something. and yes the source is available.
One problem still remains even with your solution:
Sometimes (very often in my case), you just don't want/can't connect to internet. There should be a way to install a package like - for example - rhythmbox from a CD-ROM without needing to download additional packages.
I think the best way for that would to have a rhythmbox package providing gstreamer, monkey-media and whatelse in ONE package. Of course that's not clean but not everybody wants to be connected to internet in order to install software packages.
I don't know how it is elsewhere but in France, most people have a PPP connection and it's very hard to convince your girl-friend that you need the phone in order to install your favourite video game
Hi,
I you wanna see a really SIMPLE way of handling shared
libraries, have a look at AmigaOS !!
And the same goes for the icons system...
Regards,
Nogfx.
Hi, I'm the autopackage guy, and you'll find a lot of these arguments already discussed a few weeks ago. In short:
1) Appfolders/Bundles are not a good idea. They are not simple, or elegant IMHO, not even on MacOS. The idea that you should have to manually manage dependancies is flawed - OS X apps simply don't have dependancies which puts Apple in total control, as they dictate what apps can and cannot do, and how. Linux isn't like that (obviously).
ROX has AppFolder style GUI elements it's true, but those appfolders are usually just wrappers around the binaries. And the problem of dependancies has not been solved with that either.
AppFolders have other issues, for instance menu sharing (users may want access to apps but not have them in the app launcher ui), and corporate deployment scenarios.
Finally, considering that the heirarchical directory system itself is probably going to be dumped in favour of database style filing systems with live queries (see Storage+/Reiser5), appfolders tie software management to an obsolete concept.
2) There are a whole host of reasons why installing Linux software is difficult. File paths are one, but they are the easiest to fix. The biggest problems are at the binary level, for instance:
- C++ ABI breakage
- Hardcoded prefixes (with automake macros)
- Library symbol clashes.
The last one we discovered a few days ago at autopackage HQ and it look like the only real solution is to rewrite part of the dynamic linker 
Forgive me if somebody has already mentioned this. I think the easiest solution on Linux for shared library dependency problems is to do what Opera does with their Linux version. Offer the binary in a dynamic library version and a static library version. If you try to install the dynamic library version and it doesn't work because you have conflicting libraries, then install the static library version. Or, if you don't want to mess with it, install the static library version from the outset.
O.T: I just want to congratulate Matthew Gardiner on his adroit use of the word whinge. I love that word. It says it all.
There are great sides to everything: BeOS, Amiga OS, RISC OS, Mac OS, Linux, BSD and even Windows has it's good sides. For me personally, the best solution seems to be a Linux distro built on top of ROX desktop system.
ROX has full drag and drop right now. It would need to get this DnD support out to the world. Then the next thing, that's needed is a file system with live queries and built in mime-types. Something like BeFS would be nice. Probably built on top of ReiserFS or Ext3.
Once these two are down, the focus can shift back to getting more apps to work well with ROX. And to getting some prettier graphics on ROX.
Hmm. I'm gonna build a Gentoo-based ROX-only system on my spare partition tomorrow. Might be a nice adventure trying to get the thing user friendly and fully integrated with ROX.
That is why the caveat is there where I said for most things.
1. You are right it assumes you have an internet connection.
2. It also assumes Redhat and others get the clue that people will want to install packages not specifically created by them so they would either tie their own package management in or include synaptic and apt with distro. Ain't gonna happen even if they do link to freshrpms on their site.
I do not mind libraries that are going to be used by multiple packages being in their own package.
What I do mind is the fact that in linux most of these packages are bundled exactly as the original developers created them. What is the problem with that?
The deal is that with gtk+ package you do not get gtkmm, GtkPerl, gtkhtml and half a dozen other packages that eventually some gtk app will want.
Also, there is the gnome-libs that do not include say libgsf, libgnomecanvas, libgnomeprint, or libgnome<what the hell ever> that some gnome app will need.
I do not like the idea of bundling shared libs with app or you end in a Windows old school situation of one app over-writing dlls that another app needs (AOL use to do this all the time).
A better solution is to bundle all libs of certain categories together. If you are going to create a package based on some way newer version of a lib connected to these packages then you make a static library version of the package.
Opera does this as Iconoclast said above.
I think that the way distros package their base system libraries and the application libraries can seriously improve.
Still, applications like apt and synaptic help out a great deal for those who have a reliable internet connection that does not cost outrageous amounts of money to keep up.
If the current directory was placed before library directories in the path, this could allow a potential attack.
This type of attack could come in the form of malicious code with the name of a common library being placed in the current directory. This 'malicious library' could then be executed with the use of a trusted app or command.
This is a disgusting attempt to ride the "FUD Bandwagon" with respects to fragmentation that is being addressed by the LSB. This author is apparantley clueless about why *nix is so fundementally secure against virii when compared against the Windows environment. The entire article is voided by the following statement (which not only works on debian but also any rpm based distro thanks to apt4rpm)
apt-get update && apt-get install <package>
done. Get over it
Don,
Actually, on the Amiga, you can program your application to look for a specific version. Typically, this is not done, but it can be. Typically, libraries on the Amiga did not break old apps when a new library came out. If it was that different, it became a different library.
I guess I should answer this kind of question as my project has a similar design -
basically, there is no good way around the fact that sometimes to install a program you need to download a lot of stuff, other than perhaps buying SuSE which comes on a DVD
Bear in mind if apps start shipping libs within themselves (not a good idea!!) then you'd end up downloading more in the long run anyway, those libs have to get on your system somehow, best to only download what's needed.
This is a very interesting and well written article; there are parts of it that I don't understand, but it gives me greater insight into the matter (and makes clearer where I need to do some more reading.)
OS X is a Unix. What have the folks at Apple done that makes it so easy to install programs? What are the pros and cons of their choices?
When I install a program, when I want to tell it what folder to go live in, if I want my (computerphobic) husband to have access to it I install it in the main applications folder. If I do not want him to have access to it, I simply open up my personal folder and install it in the applications folder there; any body not logged in as me can't see it or use it. Fast and easy.
How has Apple done this? What are the pros and cons?
I also hear that I *should* be able to drag an application out of the main applications folder into my private directory's applications folder and that all the appropriate links & paths will auto update (and vice versa), but I haven't tried this yet.
If this is true, what has Apple done? Pros and cons?
(Finally, 12/25/02 will mark the start of my 2nd year as an OS X user. I have made a grand total of ZERO trips to the command line to get anything installed or configured.)
I can't see the point of this article...
I don't have dependency problems if i install my distro packages. They are easily installed under /usr.
If i install other kind of sotware it usually goes to /usr/local, with the binaries on /usr/local/bin, libraries on /usr/local/lib, etc...
If the program wants to ship with its own libraries it can do it statically linked, or it just installs on /opt with its own /opt/*/bin, /opt/*/lib, /opt/*/lib and then a symbolic link of the bin in /usr/bin or /usr/local/bin.
If you want a decent installation program, just go with Loki-installer. It's easy, GPLed, and runs on console and GTK.
I can't see any problem with linux. The problem is with people packaging the programs, and the kind of packagement they choose.
OS X is a Unix. What have the folks at Apple done that makes it so easy to install programs? What are the pros and cons of their choices?
You've run into problems right away with your first sentance. Is OS X a UNIX? It's arguable either way really. It may be (partially) based on UNIX, but then so is a Tivo, does that make a Tivo unix? I'd say - no, being based on a technology is not the same as actually being that technology. Something else to chew on is that for quite some time (dunno if it's still the case) Windows NT and up were more POSIX compliant than OS X - in that case, is Windows a UNIX?
Well, either way I don't really care. OS X uses a different software management method (in theory) to every other form of UNIX, which makes it different enough that we have to draw distinctions between them.
Pros of the OS X approach:
- Simple, both for developer and user
Cons:
- Limiting for the user/admin/developer
- Requires central control
- Makes updating the OS in chunks much harder
- Inefficient
Well, Apple don't really care about limiting the user - OS X already limits what users can do in many other ways (for instance, if you don't like the apple gui/theme, you can't change it). It does care about keeping things simple. Well, appfolders are an easy way to do that, but at the expense of many other things.
Requiring central control could be seen as a goal of appfolders if you're a conspiracy theorist. I'm not, but there's no denying that it means to get OS upgrades you must buy a whole new copy of the OS. For instance on Windows MS released separate installers for old versions of the OS, so DirectX was available separately before it became integrated, ditto for IE, ditto for MSI, ditto for many other smaller things that you will never have noticed.
Because there's no way for an installation to verify that you have the required pieces however, that's much harder on the Mac. Yes, you can put it off until the first run of the program, but that's not very helpful is it? The app doesn't get any chance to selectively install stuff without storing inside the app itself, in which case you're now just wasting space by having two copies of the same thing.
There are ways to hack around this, but what it basically means is Apple get another chance to dump all over their customers. Without dependancy tracking, apps will end up saying stuff like "OSX 10.3 minimum required", even if it's really just a few frameworks that have bumped up their version numbers. Hence you pay again to upgrade. Hence Apple get more money. Which is for them, the aim of the game.
Another problem is corporate deployment/menu virtualisation. If you have 10 apps, but only 6 are actually shared between all users, it makes sense to hide the other 4 from the users that don't need it to avoid cluttering the GUI. You still want a way for those users to run those apps though just in case. When I lived at home, we did this all the time, for instance my brother used a selection of useful audio apps which I occasionally would use too, but mostly I didn't so there was no need to put even more stuff in my already overloaded menus.
With appfolders, because the filing system enforces certain rules, it's harder to do stuff like that. I guess you could do it with link farms, but it's harder.
Appfolders are inefficient. This is less of a concern on an OS without dependancy management because apps will rarely, if ever, make use of functionality not provided as a part of the base OS. If they do, the frameworks will be bundled with every app, so you could end up with say 5 apps all having their own copies of the same lib. If a problem/bug/security flaw is discovered in that framework, you have to manually alter the contents of every app, or upgrade every app manually. With dependancy management, the weekly upgrade will deal with it automatically.
Folders are going the way of the dodo soon on both Windows and Linux (if storage+ and reiser5 pan out). Mac has no such plans as far as I'm aware, but it's a remote possibility.
Finally, you have to actually go onto the web and download appfolders. I find that more hassle than just typing the name.
In short, appfolders have (imo) several major disadvantages for users and developers with their only redeeming feature being that they take almost no effort to implement (important when you write an OS from scratch i guess).
Juan.
In case you are interested... With regards to points 1 and 3, the Linux distro which I am using (SuSE), makes heavy usage of '/opt/' and includes the current directory in the path.
I am actually very happy with the way that software is distributed under Linux. I find installation is generally simpler and uninstallation is 100 times better than in MS-Windows (I couldn't imagine going back to a system which has no equivalent to 'rpm -ql' or 'rpm -qf'). However, I feel it would be nice if RPM had some way of installing programs into your user area, to enable better security.
The truth is that linux development is MUCH faster than proprietary O.S.es. There are 2 or 3 versions of a linux distributions per year (and many software updates in one version), while there are one little upgrade (e.g. Win95 -> Win98 -> WinME) at each 3 years !
For dummies, there are simple tools to install and upgrade software (and even entire distribution) like synaptic, aptitude, apt-get, Red carpet, etc.
If you aren't a nerd or geek to compile from sources, use only the update/install tool odf your distribution.
The OpenOffice/StarOffice installer is an example of easy (a la Winblows) graphic installer and it is identical to the windows version. What is the problem with linux ?
I guess that the first thing to do is start with a dependency standard.
Even if you replicate libraries into application folders, I would imagine that you would want to get that application's dependencies for automation purposes.
What standard should be the standard.
Cool people use Debian and never have package troubles again. lUsers work with other distros.
Sorry to be so flame-inspiring but if you don't know about Debian and apt, it's time to learn.
I've heard people say that Portage is even superior to apt-get. Can someone explain why? Does Portage really prevent "dependency hell" or are there still problems? Can you use Portage for binaries? Do you lose the advantages of Portage by not compiling from source? Any information would be appreciated
actualy, that exploit was dealt with a LOOOOOOONG time ago. it is no longer an issue.
/usr/local and /usr/share come from the days when much more of the filesystem was spread across a network. /usr/share is for system/architecture independent things, often stuff like documentation etc. whereas /usr/local was binaries and the like since they were system/architecture dependent and installed locally.
Mounting the stuff anyone can use on a network share means that you save disk space on the local machines. Not such an issue these days but once upon a time people worried about these things.
One additional problem is that Unix/Linux does even not get the concept of folders! Nearly all apps get installed in things like /usr/bin. So even if you install an app you can't find it because you have to go through a list of hundreds of files. Which libs to which application belong is probably also unknown there are hundreds of libs in some other folders.
Thats even worse than the windows concept of windowssystem32 ! At least on Windows this directory is now secured in order no install app can overwrite the libs with older versions. And applications can use the same dll in their own version. Yes. We don't talk about Windows 95 anymore! We should compare current concepts which are implemented in Windows 2000 and XP. And if you compare the install of Linux software and Windows Software... I can't really find this "DLL-hell" any more in Windows! Tell me one application which still makes such problems on Windows. On Linux I could try nearly every application. Most apps I installed on Linux gave me a Linux library hell.
The real problem is that Linux fans really like this fact. They like it that no normal user can really use this OS. Because it is so "advanced" that only really experienced users can use it ;-) I am amused about this.
I think it is a good idea. Why do some of you guys act like Superman close to cryptanight when you hear linux needs to get more user friendly? It won't kill linux ok, it will be a new bigining for it. If you don't like easy stuff go hunt for your food, skin it, gut it, debone it, bleed it, then cook it over a fire outside. That is how the native americans did it.
the one BIG limiting factor to all tha is.....the end user can not go and get a new package he/she finds on the web. that is the problem here. sure apt is great until I download a binary package in deb format of a new app....does apt resolve the dependancies for me when I double click on the package...if anything happens at all....hell no......it throws up a bunch of errors about dependancies.
perhaps a GPLd netinstaller can be created that will make the creation of an installer simple for developers. then the dev team can point the user to the correct locations of the libs needed.
that is sort of what Mike is doing with autopackage, except ituses the dependancy resolution network rather than a predefined loactiuon like Mozilla or OO/SO use.
the only problem with the Mozilla instaler is that to run the install script you need to call it from the command line and it is named the same thing as the binary file.
just call the script setup.sh then allow for double clivk installs and meta data so that the icon can LOOK like an installer.
Putting "." into the PATH or LD_LIBRARY_PATH by default is less than entirely wise. As others have pointed out, this leads to security issues. Besides, it isn't hard to type "./somefile", and applications can always exec() themselves after modifying their environment, if necessary.
Many have railed against the Mac OS X style of app-folders. Personally, if there's no shortage of disk space, I think that this is a great idea. However, if you're running short of disk, then it's obviously not so great -- but then, why would you need icons bundled with the application if you're running short of disk?
The idea that app-folders require centralized control is, well, astonishing. I'm afraid the rants against app folders are, despite being well written, incomprehensible. If you want centralized control, you could do it that way, but you always have the option of "installing" an application locally without any centralization whatsoever.
The debian geeks going on about apt-get, well, yeah, you're very clever. But if the application in question has not been debianized, you're right back to where you started.
As for meta-data, well, I am a fan of the Amiga .info files. (Although I suppose the Info.plist approach isn't so bad.)
And, I suppose, I'm not convinced that Linux "needs" to "win the desktop war". It's not a race. It's not like Linux can lose -- unless it chases after new users so much that it becomes less appealing to experienced users. Personally, I want stability, maintainability, and sensibility -- change for the sake of change is NOT progress.
The key distinction is -- and that I haven't seen brought up yet -- between multi-tasking single-user systems and multi-tasking multi-user systems. Frequently, the objections to Linux (and UNIX) relate to how things are done on a multi-user system that seem inappropriate for a single-user (or single-owner) system.
A single-owner system only ever has one person logging in to the system -- perhaps "at a time" for family-owned systems -- and no concurrent users. There's no need to run a bunch of services on the machine, there's no need for an administrator to manage the users and resources. Applications may be installed willy-nilly, and removed just as quickly -- at the whim of the owner.
A multi-user system has to deal with multiple, concurrent, possibly hostile or incompetent users. Resources must be carefully managed [which is where the approach used (but not invented by) StarOffice is useful -- install centrally, and then store local data in the user's home directory] and not needlessly duplicated.
A single user can afford to waste tens of megabytes of disk. A multi-user system might not be able to afford to have each user waste tends of megabytes of disk.
It all comes down to how you're using your system.
First most web sites that have software available for linux for download list the dependencies especially if they provide rpms.
If you don't read the website before you download the app you are going to have trouble sure. Most places also link directly to their dependencies. They also include many times install instructions even. Can it be easier? Sure.
I download an rpm from a site and doubleclick the thing and it either installs or tells me the dependencies I am lacking -- RH8 BTW.
And it looks like an installer too.
I like the idea and think someone said that Mandrake is wired into urpmi which is another rpm like-apt sort of system so maybe they resolve the dependencies when you click on the rpm. That would be great. I like this idea alot.
Like I said before if RH got a clue and tied their package management into the apt system then a lot of these issues would go away. Like deb-man said, the package management system could follow the dependencies and download them for you.
It has become habit for me to check synaptic for any new software I am thinking of installing in order to avoid such issues. gnome-crontab may not give me dependency issues (download to desktop and double-click to install) but the latest gnumeric certainly would.
Good points deb-man.
The idea that app-folders require centralized control is, well, astonishing. I'm afraid the rants against app folders are, despite being well written, incomprehensible. If you want centralized control, you could do it that way, but you always have the option of "installing" an application locally without any centralization whatsoever.
The central control stems from the fact that you can only assume that stuff Apple ships with is present, as there is no dependancy management. That means that it's not possible to introduce competing frameworks of any complexity into the system without horribly bloating the app - unless you use installers of course.
Linux on the other hand, you cannot assume anything, because there is so much variety and it's decentralised. So you need dep management.
... as you risk being listened to. Unix has been around for a long time, and has seen many of the "improvements" suggested in the article fail. Mostly, developers need to unlearn poor habits learned on Windows. Libraries are not shared to save disk space, they never were; the are shared to reduce the complexity of the system and minimize runtime interactions and security risks. Consider the late zlib security flaw, fixing which proved highly cumbersome because a number of people thought it would be clever to include zlib code instead of linking (the kernel was the only sane exception). Others have noted that "." in the $PATH or even worse in the $LD_LIBRARY_PATH is inappropriate and I will not add to that; it's just that you have to unlearn the Windows "application" concept and learn the Unix "tool" concept - each program cooperates with the system and with many others it knows only by interface, meaning the developer has to learn said interface and follow it. If in doing so you have to give up some feature, rest assured it won't be missed. One Windows was enough, thank you.
There's an easy way to end that stupid problem with the shared libraries:
Use version numbers inside the library, and make newer version of a library backward compatible with the old ones, so the only thing to do for the user is to install always the latest version of the lib.
Yes I know it sounds stupid, just think about it.
-----8<-----
Anyway, this has no solution, nobody agrees about how to solve things like this in the Linux world, everybody is growing his ego looking at his belly button.
Look at the state of the desktop and the apps integration between diferent distributions...
Nah.
Cons:
- Requires central control
FUD! Define "central control". All an admin need do to install say Microsoft Office for all users is drag it to the /Applications folder. If I want to install it locally I drag it to the /Users/mynamehere/Applications folder. What is "central"?
- Makes updating the OS in chunks much harder
Total BS. The software update utility updates the OS in chunks. I installed 10.2 and have since updated to 10.2.1 and 10.2.2 and am expecting 10.2.3 shortly. If you mean that you can't updated a certain specific lib?... sure you can, just like any other Unix, you just take responsibility for fscking your system up. That's what releases are for. They are known to work rather than getting something that is partially incomplete.
- Inefficient
(I don't really agree with this line of thinking but...) Disk space is cheap and executable code is small. Content/data is what really eats up disk space.
Another problem is corporate deployment/menu virtualisation. If you have 10 apps, but only 6 are actually shared between all users, it makes sense to hide the other 4 from the users that don't need it to avoid cluttering the GUI.
So as the admin put the apps in separate folders and symlink them into the /User/mynamehere/Applications
use of functionality not provided as a part of the base OS. If they do, the frameworks will be bundled with every app, so you could end up with say 5 apps all having their own copies of the same lib.
An interesting feature of frameworks in .app bundles is that they export their version of the library to be used by everyone. However if that version is compatible (or missing because the app providing it was removed) then the app will revert to using it's own copy. You get all the benefits of using the latest version and none of the hassles. An app will always work.
If a problem/bug/security flaw is discovered in that framework, you have to manually alter the contents of every app, or upgrade every app manually. With dependancy management, the weekly upgrade will deal with it automatically.
Bzzzt! Wrong! See above.
Finally, you have to actually go onto the web and download appfolders. I find that more hassle than just typing the name.
You know not everything is available as an rpm or deb. It pisses me off that all Linux people seem to think it is. Some of us do use commercial packages.
How about this:
1) Application developers make it a point to statically link all but the absolutely most common libraries into their apps. Bandwidth is (usually) cheap and disk space is (very much so) cheap.
2) Enforce versioning across systems. Make it known that if you want your app to work, it had better identify to the loader what versions it can work with. Make promises to developers regarding major/minor library and compiler versions and ABI's/API's and keep those promises.
3) (and here's the magic part) Make the loader a hell of a lot smarter than it currently is. It should work like this:
if ( executable required libraries are installed system-wide and compatible)
{
Load process image from app + system SO's.
}
elsif (executables required libraries aren't installed, but it does have them statically linked internally)
{
Load process image from app + app's libs.
}
elsif ( executables required libraries aren't installed and the app doesn't have them either)
{
Bomb and tell the user to go get the proper libraries
}
1. Notice, that all this is a matter of a convention between developers of how to share libraries. If you don't share anything, you can install by simple "unzip -d app.zip" or "tar zxf app.tgz". If your style of sharing is much different from mine (as example) it will bring me many problems to use your software. It will be your program I erase at first appropriate case.
2. I think "one common proposed" solution is a bad thing,
so your new (installing) software should interfere with mine
in minimal. It should not be "the one big stone on road".
And it should be flexible to be customized for more integration.
3. The simplest way to achive proposals of pt.2 is to install application in separate subdirectory.
Advantages: 1) installation is "tar zxf app.tgz";
2) removal is "rm -rf /path/to/this/app";
3) "/I/hate/all/these/long/pathes/that/are/hard/to/type".
Drawbacks: 1) integration; 2) sharing libraries.
4. Solution. Men, you are happy ones, you have hard and symbolic links there in all your unices! I have none of them. (I emulate a kind of them with batch files under DOS.)
Exposing your main binaries to user and sharing libraries can be achieved with:
1) link with (BASE-APP-DIR)/lib/link-to-that-lib.so.X.X.XX;
2) link/load libraries listed in (BASE-APP-DIR)/usedlibs.lst;
3) third way (invent your own).
Advantages: 1) you don't need all additional binaries (that should be in $PATH) in "/bin", "/usr/bin" &al.;
2) all listed in p.3.
The only thing you need is a way application can get its base directory name ("where am I?").
But all this can be done with scripts! Men, you have long command lines there in your unices! Men, you have good shell there!
I don't know exactly, but you can create a separate environment there!
Almost all you "/usr/bin" can be the scripts, that set environment variables and go on.
Evil developers of course won't do such a thing as providing linking list and dependencies mapping, but you can use links, and if newly installed application refers used name for different meaning, then patch it, keep you hex/bin editor handy.
You're happy there in unices, your apps' code is hardly self-modifying.
There is no problem *at all* with Linux binaries and it's working fine. The problem is *how* you distrubte them. This is how I would fix it, this is terribly simple to do and the first distro that does this could win the Linux market easily. No, this is not a stupid post, read the full thing.
- Developpers release sources in tar.gz or tar.bz2 format and this file happens to be linked from freshmeat and sourceforge for example.
- Distro X make a little program that "grep" freshmeat and sourceforge for new package.
- When you buy Distro X, you get Y votes, that is, the serial number found in your Distro X box can be used Y times to vote. You pay for essential program of your distribution and the rest is used to pay the votes you will use.
- The result of the "grep" is put into the Distro X web page and users can vote on a certain package that he want to be built. Of course, voting take some of your Y votes that you got from the Distro X box.
- After there is Z vote on one package, someone at Distro X build the package and put it in whatever format they want (for example .rpm) for free download (they already got their money from the votes they "sold").
- Installing for exmaple a .rpm package example is a joke, click on the rpm file and if Distro X properly configured their stuff, it will automagically install the software, if you provide the root password (security first, always!).
- The user can buy more vote by sending to Distro X some money.
Wow, that was hard, isn't it? I bet this could take 1 month to set this up and you you want overkill and simplicity, write a client for this. With this system you've got:
- The full spirit of free software, you've got the sources if you want to mess with it.
- If you're cheap, built it yourself or what that people vote on the software you need.
- Unlimited flexibility, each distro can use their own package management and put files where they want.
- Even easier than Windows, every program install the same and no stupid "Where do you want I install this?" or "Please insert CD key" each time you want to install something.
- This will give Distro X a lot of money, if for example they wait that for example 1000$ in vote is spent on a package and it take at someone at Distro X 1h @ 20$ to build it, 980$ directly in, WOW!
If some good distribution doesn't put this stuff up, Lindows will put this stuff (they already have a similar system Click and Run, they can only implement the vote system and it's done!) and win the Linux market. This method is simply the best and is deadly easy to setup (a few perl script and maybe writting a client to be even more easier). Now, send this post to all commercial distro and watch the dog fight...
Distribution by physical place:
FALSE. The FHS defines the paths that way to be able to install programs in a single computer and share them among 250 more, which you can't do the Windows way (you need to install the same program in each computer).
X11R6 is an anomaly, stemming from people who thought like the article's author
Installs need to be global:
FALSE. I myself have several software packages installed only on my home dir. Any UNIX user will tell you that's the case. What I agree with is that RPM/DEB package installs are system-wide.
Several versions of a program cannot be installed:
FALSE. You can install several versions of the same program, using different libraries (you know, libraries have version numbers in their file names). Just name your programs differently.
What software release managers ought to be doing is testing their software packages with different distributions and providing links to the libraries required (or bundling them in a zip file and making an install script, which most big name software companies do).
Current dir is not in path:
Thank God. That's one of the reasons you don't have trojaned programs on your computer.
No file metadata:
FALSE. Linux binaries DO have metadata (in the crooked definition the author is using for the word). There is no icon defined in the binary, and that's another problem. Icons are installed in standard places (freedesktop.org).
Linux package systems take care of so much more than installation. They help in audit and deinstallation tasks.
This is a great article. When the Linux people realize that features have to be popular as well as useable then they might start to contend with Microsoft.
I heard a quote once but don't quote me on this"The best thing about Microsoft is they take other peoples products and make it their own." They take products, find out what is popular about those products and emphasize those qualities of those products and hey presto... you end up with the Killer Application.
The little things such as ./ in PATH count, they really do.
Davide, I agree with -everything- you said. Unfortunately, Linux is not Unix, as the LINUX acronym indicates. The development of UNIX (pretty much any UNIX) has been slow and careful. Development has been conservative, with an eye to code/version stability and the other to manageability.
In Linux, every dork thinks he needs to update a certain library or toolkit, because that would be so cool. The only thing dorkier than that is, there is a developer of an app that thinks it'd be so cool to utilize this cutting edge feature, available only in the newest library or toolkit, and to heck with backwards compatibility - or ANY compatibility, for that matter. The kernel development has been just like that, too.
Read the article better, I'm not saying all these are poblems in unixish OSs, they are not. All these suggestions are meant for desktop new users who dont really want to learn how to be sysadmins, not for the expert leet unix hax0r.
> Unix has been around for a long time, and has seen many of the
>"improvements" suggested in the article fail.
Like, when? i dont recall any major distro or unix vendor doing it. As they are not really meant for server usage.
>Libraries are not shared to save disk space, they never
>were; the are shared to reduce the complexity of the system
>and minimize runtime interactions and security risks.
>Consider the late zlib security flaw, fixing which proved
>highly cumbersome because a number of people thought it
>would be clever to include zlib code instead of linking
>(the kernel was the only sane exception).
So what? desktop users install programs all the time, that is way more insecure. The bundled libraries are meant to be the rarer ones, not the ones you can install system-wide (like zlib), I feel you are taking the argument to the opposite extreme.
> it's just that you have to unlearn the Windows
>"application" concept and learn the Unix "tool" concept
No, the UNIX tool concept works perfect for the developer,
or even the smart user, but it's definitively NO WAY something a regular or common windows user is willing to learn when switching to linux. They want applications, and a graphical interface (which can interact with the unix tools anyway) where they have everything at the reach of their hand, they dont want to RTFM or read through dozens of manpages to find out the command line switch that does its works.. and which is even harder to memorize. So get over it, unix tools are not for the regular user. Apple and Microsoft have shown this since long ago and it's stupid to ignore it and pretend that the users can "dewindoize" themselves and use a computer the way a sysadmin does.
This is fun, you say the article is full of inaccuracies and then you prove me right in every point!!
> FALSE. The FHS defines the paths that way to be able to
> install programs in a single computer and share them among
> 250 more, which you can't do the Windows way (you need to
> install the same program in each computer).
> X11R6 is an anomaly, stemming from people who thought like
> the article's author
We agree! now, since when do desktop users share the programs betweem 250 computers? Hard disks nowadays can install everything on them with lots of space left, so setting up a network, even for an office, with 250 computers can actually be slower, more hassle and more expensive!
>Installs need to be global:
>FALSE. I myself have several software packages installed
>only on my home dir. Any UNIX user will tell you that's the
>case. What I agree with is that RPM/DEB package installs
>are system-wide.
Uhm. download favorite.tar.gz
tar zxvf favorite.tar.gz
cd favorite
edit INSTALL -> it says do:
./configure
make
make install
where did everything go? probably to /usr/local. Local instal? where? you can hack it up if you want, even create
~/bin and ~/lib and throw stuff there, or just configure with --prefix=~ , but still you need to do some hack up to
what your distro comes with to achieve it, and it's definitively not standard. Not to mention you _still_ cant have different versions of a program installed.
>Several versions of a program cannot be installed:
>FALSE. You can install several versions of the same
>program, using different libraries (you know, libraries
>have version numbers in their file names). Just name your
>programs differently.
Yeah thats what I said! but libraries are not programs, you know. And how are you supposed to name your program different when stuff like gnome expects to do so much IPC (corba/bonobo) with known binaries? you really cant do that.
>What software release managers ought to be doing is testing
>their software packages with different distributions and
>providing links to the libraries required (or bundling them
>in a zip file and making an install script, which most big
>name software companies do).
Yeah but those methods dont work well, specially with closed software (where they need to proovide only binaries) and they only proovide support for ONE distro (usually redhat). Dont believe me? Check IBM DB2, Oracle or even Alias Maya! They only give you support if you isntall known redhat versions.
>Current dir is not in path:
>Thank God. That's one of the reasons you don't have
>trojaned programs on your computer.
Uhm.. if someone gets to put a trojan in your computer, or even get access to it from any of your users, installing a trojan is an easy task on a desktop computer. You cant really expect those users to be as security aware as a sysadmin, and besides, they are simply way more in risk
by doing the usual ./configure ; make ; make install anyway,
since you need to be root for that last step.
>No file metadata:
>FALSE. Linux binaries DO have metadata (in the crooked
>definition the author is using for the word). There is no
>icon defined in the binary, and that's another problem.
>Icons are installed in standard places (freedesktop.org
Read the frigging article!! Yes! you can place an icon in a .icon section if you want, so what? that's far from being a nice solution. What if you want to place more than icons in there, like a search criteria for programs or something else? Thats why a "standard way of metadata" would be nice!
And what you suggest is yet the usual, to install an icon in a "standard place" you need to be root, where's the security then? and what if you want to have different versions of the program with different icons? no more standard place there i guess!
Seriously, think for a moment as a windows user, we might dislike microsoft in a lot of aspects, but they really did things right in many others, so it's not bad to learn from then and that's what people like Miguel de Icaza see too. And what does Miguel get for it? a lot of bashing and "pro microsoft" adjetives. Grow up people!
If you look back to the formation of the POSIX standard and why it was done, you will see that a similar standard for the end user (EUPOSIX??) would solve all of the problems in this binary loving (why?) world we live in.
For example:
Core Binaries -> /usr/bin (grep, gcc, su, tar, vi)
Extended Binaries -> /usr/local/bin (pine, emacs, gmc)
X11 Binaries (GNOME, KDE, others...) -> /usr/X11R6/bin
no /var/.... B.S Core (base) Libraries -> /usr/lib (glibc, glib, gtk, qt)
Extended libraries -> /usr/local/lib
Core Docs -> /usr/local/doc
Core Config Files -> /etc
Resources -> /usr/share
Or something of the sort
The problem is that packagers of all kinds have their own ideas about where what should be kept. Clearly, this needs to be solved with a STANDARD along with some kind of versioning scheme. Or should we just recompile *BSD packages for you linux guys and be done with it along with some kind of gtk_pkgadd to keep the newbies happy.
There's a good reason why the current directory isn't in your path by default, and I wouldn't use any distribution that did that. All you that are whining about it, PLEASE take a moment and think of the security implications, if you have that capacity. It's people that try to dumb down good operating systems so they can be used by "average users" that's made most Linux distros the bloated, gui-oriented crap that they are today.
The author claims that Linux has got an advanced library versioning system. Some commentators, me included, say it hasn't. Having several incompatible libraries with their version number in the filename is not an advanced versioning system. It's a crude versioning system.
Look at AmigaOS. All libraries (save those which are private to a single program and aren't meant to be shared) are put in LIBS:, and they're backwards compatible. When a new version appears, you get a new entry point for the new version, while the old entry point still allows you to use the library with the older interface. And they have their version number integrated into the binary. Type "Version diskfont.library", and it will tell you its version. Thus, installers won't overwrite libraries, either, since they'll do a version check to see if the library is newer than the bundled one.
No need to have several version of the same library, a working versioning system and a uniform place to put them. Not bad for a stone-age system, or what?
NOTE: NOT A REPLY. DON'T GO LOOKING FOR "All you Linux code monkies"
-----------------
It is great that all you "Anthing against Linux is FUD" people are so happy with your OS, even thought the method you use to install programs and update your system software is CRAP. I can't believe that Linux lost it's edge when it came to software development. I remember the times when "If this works better, we'll do it" was the theme going on in the OSS comunity's head... not "We'll this sucks but we're stuck with it."
Give me a great, easy to use PROPRIETARY system any day instead of the hard to use, legacy oriented open source solutions we are stuck with.
This is the last time I'll deal with these issues. I've answered questions on appfolders time and time again, and the only responses I get are either agreement or people simply repeating how it works. I know how Appfolders work thanks, that doesn't make my points any less valid. To be honest, I can't be bothered anymore.
FUD! Define "central control". All an admin need do to install say Microsoft Office for all users is drag it to the /Applications folder. If I want to install it locally I drag it to the /Users/mynamehere/Applications folder. What is "central"?
Without dependancy management, Apple are the only people who can feasably update the OS and provide new features to it. See the $120 upgrade price to 10.2? There will be more of that in the future. See how PGP8 requires 10.2? Ditto.
Linux is a free market of components - it's quite feasible for an app to pick and choose multimedia frameworks for instance. That isn't the case on OS X, because it's controlled centrally - ie apple are the only ones who can change it. I'd have thought this was obvious.
Total BS. The software update utility updates the OS in chunks.<p>
Yes, and who runs software update? Oh, that'd be Apple.
(I don't really agree with this line of thinking but...) Disk space is cheap and executable code is small. Content/data is what really eats up disk space.
I find that attitude tiresome. Saying "well X is cheap, so it doesn't matter" is what poor engineers have said since the invention of the wheel. I don't have acres of disk space, and if I did I'd need it for more important things than 10 copies of the same framework.
An interesting feature of frameworks in .app bundles is that they export their version of the library to be used by everyone. However if that version is compatible (or missing because the app providing it was removed) then the app will revert to using it's own copy. You get all the benefits of using the latest version and none of the hassles. An app will always work.
No offence, but that's a dumb way of doing it. So now if there's a bug in a framework, you install a new app and it's magically fixed. Wizard. Now you get tired of that app and trash it, and all your apps silently break again. Or of course the user can start downloading and updating frameworks manually (or wait for Apple to ship them on software update). Great.
You know not everything is available as an rpm or deb. It pisses me off that all Linux people seem to think it is. Some of us do use commercial packages.
Yes and the reasons for that are well documented, and being fixed. I for one do not have time for an OS that requires Apple to be in charge as a design feature. I'll say it again - for the last time on these forums, considering we went through all this a few weeks ago - appfolders are nice in theory, but have so many practical disadvantages that when the last remaining issues with linux apt style software distribution are solved, it'll wipe the floor with them in convenience, ease of use, security and efficiency. It's more effort but so what? We don't have deadlines to meet.
In GNU/Hurd (http://hurd.gnu.org), "/usr" is a symlink to "/". As recently seen in its mailing lists, many Hurd developers think that "/sbin" should be a symlink to "/bin" as well. So the filesystem becomes cleaner.
And with the Hurd, the user has more privileges than with traditional Unix-like systems (as Linux of *BSD), so installation of third-part programs can be easier.
OTOH, for software not natively packaged (as in Debian GNU/Hurd), "GNU stow" is a practical tool for having a clean organized files. But this is an admin tool, not for the end user.
"Look at AmigaOS. All libraries (save those which are private to a single program and aren't meant to be
shared) are put in LIBS:, and they're backwards compatible. When a new version appears, you get a new
entry point for the new version, while the old entry point still allows you to use the library with the older
interface. And they have their version number integrated into the binary. Type "Version diskfont.library", and
it will tell you its version. Thus, installers won't overwrite libraries, either, since they'll do a version check to
see if the library is newer than the bundled one. "
Including the version number string in the binary would be an
essential first step for Linux programmers, and could be done without
breaking anything.
AmigaOS uses a string of the form "$VER:" as in "$VER:12.34"
This is easily searched for.
If everybody started to include that string in their shared libraries,
then in a year or two further improvements could be made, heading
toward the ease of installation found in AmigaOS.
(Of course even in AmigaOS there are sometimes bugs in install
scripts, but generally the system works well.)
Statically linked libraries are IMO part of the source code for the
program and as such are no concern of the user.
With a better better package mangement with auto compiling and autodownload of missing packages could solve the problem.
anyone who thinks software install on windows is easy needs to go work in a it support department
it is not
dll hell
visual basic hell
odbc driver hell
windows hell
The reason that PATH and LIBRARY_PATH don't point to . is for security reasons. And, there is a simple fix - add "." as an rpath to your binary!
By the way, static linking is not the horror people make it out to be. Static linking is a perfectly fine solution to the problem - one that many people use successfully. In fact, Mathematica runs on every version of Linux because it is statically linked.
I think the real problem is that we just need a good packaging tool in Linux for the package _creators_. One that autofinds dependencies through ldd (and perhaps even running the program), and adds all necessary libraries into the package, and then on depackaging figures out which ones it needs to install on a particular system. If you think that's overkill - that's precisely how Windows applications do it.
Alternatively, we can come up with a new file format that includes a virtual filesystem that overlays the current one for the process when executed, although the HURD would probably be a better OS for that than Linux.
It never ceases to amaze me how people fail to realize that something that is good for effectively single-user systems needn't be bad for multi-user systems.
Currently, you can share an installation across a network simply by sharing the /usr directory (or its subdirectories).
Now let's imagine a system where the files belonging to one package (or application) aren't scattered throughout the filesystem. Instead, all files belonging to an application/package reside within a single directory. Let's assume we've got a good implementation of file attributes and querying, so it doesn't matter where this directory is actually located. In other words, an application "foo" could be installed in directory /apps/foo/, /apps/scientific/foo/ or ~/apps/foo/ and it wouldn't matter (although in the last case the application would only be visible to a single user).
You basically said that sharing an installation across a network isn't possible in this system. But which part of this system prevents you from doing that? You could simply mount /apps as a remote share, just like you can mount /usr as a remote share.
In fact, the app-directory system would be more powerful than what we currently have. For example, you could get application exports from more than one server, resulting in e.g. /apps-server1/ and /apps-server2/. In addition to this, you can still have locally installed applications.
So tell me again - why is the app-directory system not suited for a multi-user network?
This isn't the first time I've had this discussion. Often, people wonder how configuration and volatile data (the stuff you find in /var) fits into this scheme.
Obviously, both configuration and volatile data needs to reside *outside* the application directory. The files in the app directory should never be modified at all (except for an update of the application, obviously). In fact, I'd also argue that installing an application should *not* install any configuration or volatile files.
If an application cannot find its configuration file, it should either continue using a default configuration or fail to start up, depending on the type of application: Basically all user-oriented/GUI apps should launch using a default configuration or bring up a configuration wizard. Security sensitive things like daemons should usually refuse to start up without prior configuration by the user.
Of course, all this doesn't solve the dependency problems, but it would result in a much more robust system - especially if the idea is extended to *all* packages including frameworks (every framework like Gtk or Qt is in its own directory like /usr/lib/qt/, /usr/lib/gtk/). For example, mixing binary packages with custom compiled packages would Just Work instead of being a major PITA. Additionally, it would actually be possible to update & uninstall applications manually, and so on.
It's people that try to dumb down good operating systems so they can be used by "average users" that's made most Linux distros the bloated, gui-oriented crap that they are today. >>>
I take the opposite view. OS X, a usable *nix with a learning curve that didn't have me howling in frustration in under 45 minutes is a smartened up OS. It's all waiting for me when I'm ready to dig in and live at the command line (if I decide I want to go there), but in the meantime, it's not getting in my damn way when I need to get something productive done.
Your comments remind me of my grandma's rant against the electronic fuel injection and automatic choke in my car. In her view it was "simpler and better" when all you did to warm up your car on a cold winter's morning was build a fire under the engine compartment.
And finally, any study of social history shows that it is the true elites in a society who realize that the society as a whole steps forward when the best things are packaged in a form that the masses can enjoy/use. Hmmn ... huge innovations in technology and a drastic drop in youth mortality right around the time that education becomes compulsary. Could there be a link?
An easy to use desktop linux with across the board standard packaging will lead to the wider adoption of *nixes which will very likely lead to some true innovation in software and break the stranglehold that Mordorsoft has on things.
Linux is a free market of components
Basically what you're saying is that you prefer the Linux solution because it's free (as in speech and/or beer) and you don't like one company controlling the future of the OS. Fine, that's understandable.
I use whatever works better for me. I have used Linux on the desktop for extended periods of time and run a server box or two. What you call proprietary I call polished. I used to have endless hassles with installs in Linux. I have had none in MacOS X. Copy the app over. Done. Appbundles work well for 99% of the people out there. The 1% that would use MacOSX Server might need something more industrial strength.
I find that attitude tiresome. Saying "well X is cheap, so it doesn't matter" is what poor engineers have said since the invention of the wheel.
Except that sometimes when you're engineering something you have to make tradeoffs. If the tradeoffs are small and the gains big... Think trading off memory footprint for runtime complexity or vice versa.
appfolders are nice in theory, but have so many practical disadvantages that when the last remaining issues with linux apt style software distribution are solved, it'll wipe the floor with them in convenience, ease of use, security and efficiency. It's more effort but so what? We don't have deadlines to meet.
And I'll be sure to look in on Linux on the desktop at that time, till then I'll use whats less of a hassle.
The article mentions, almost mentions good reason for /bin and /sbin. /sbin is secure directory while /bin is not.
But the reason for having /usr is that you can install a program once and run it on hundreds of machines.
If I ask administration to install e.g. Word for windows, he already did install it perhaps hundred times, yet he walks over to my machine, kicks me out of my unfinished work for 15 minutes and fiddles with my computer.
And you say, that Windows is easy? If it was installed once in a shared /usr/bin , it should be available to anyone.
/usr/X11/bin was meant for those with graphic terminal, but nowdays these programs are usually in /usr/bin, since graphic terminal is nearly an obvious thing.
Petrus
I have to stop reading articles on this site. Everytime I
follow a link from some other portal and end up here reading
a linux article from a "contributing editior" it turns out
to be an ignorant rant. Suggesting putting "." in your path
shows a complete lack of understanding about why linux is
by default generally mroe secure than other os's. And this
same old "its hard to install stuff on linux" thing over
and over again, this is a straw man. This is what package
managers are for, believe me, APT is smarter than you are.
I agree that day to day some aspects of windows are more
user friendly than linux but handling the installation/uninstallation of
software in a robust, secure, and reliable fashion is an area
that linux shines in. Whoever runs this site, please screen
the stories you are publishing, credibility is a key aspect
of journalism.
OSX is a desktop, consumer-oriented operating system. Linux and
UNIX derivatives are workstation/server OSes. I'm quite sick of
the increasing dependence on GUI tools and "user-friendly" hacks,
ignoring the wants and needs of competent system adminstrators.
The reason much of this has happened is because of the insistence
of a few that Linux try to be a friendly, desktop operating system.
This can't happen without things that comprimise compatibility,
ease of administration, and simplicity of UNIX. OSX is a fine
desktop OS. It's also nowhere near as stable or usable from the
command-line as a server OS(and please, don't bring up the halfassed
Xserve boxes).
People need to accept that there are different tools for different jobs,
instead of trying to mash Linux into something it's not, destroying it
in the process. You cannot make one size fit all.
Actually, the s in "sbin" originally stood for "static", not "secure"
or "superuser". Note /sbin/sh on Solaris, you'll see a statically
compiled shell (not so in Linux - /sbin/sh -> /bin/sh -> /bin/bash.
An abomination, yet another example of the dumbing down of that OS).
I'm sure we can have many other path wars, but just a bit of trivia.
Once I bought a software package I needed for $1,000, and
I had to throw it away 3 months later because I upgraded
the system and the binary would not run anymore even with
a compatibility library.
Binaries can be very quick to install. For this sole
reason I also distribute Open Source code in a binary
form. The program does not depend on anything but the
c library (strcpy, memcpy, printf) and a basic windowing
library. Because of this luck in simplicity, there is
only one exe file for Windows and it installs on
Windows95,Windows98,Windows2000,WindowsNT,WindowME,
WindowsXP. In case of Linux one version is not enough.
There should be a version for each vendor per release.
That would be more than about 50 different binaries.Still
that won't run on future versions without an extra
compatibility library.
In my case, this is caused by different version
of the c library, Note that I just use strcpy memcpy
and printf! So I stick to the binary I can make on
my system and redirect all help-seekers on an older/newer
different distro OS to the source code.
It is hard to imagine why there can not be a strong
major number c library with minor fixes and once a
while a c library with incompatibilities with a different
major number. This would reduce and compatibility library
installation hell (as opposed to dll hell in windows) a great deal.
So Linux does not like programs distributed in binary form.
Personally I see nothing wrong with having some companies
who want to make programs for Linux with a non-Open-Source licence.
I thinkg disabling binary distributions programmatically
is not the way Open Source should show its superiority.
A matching product that is better than the close source
binary distro should be created instead.
. is current directory which will not necessarily be the directory containing the libraries and changes over time.
Far better to put in a wrapper script:
#!/bin/sh
dir=$(dirname $0)
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$dir
exec actualprogram
This has the added advantage that you can put the libraries in a subdirectory such as:
$dir/lib
I think the only real problem with binary packages in Linux is just the fact that packages aren't compatible. They aren't compatible because they have dependencies with other packages whose names could be different from the ones you actually have installed. For example, maybe "gimp.rpm" needs "libgtk2.rpm" while you have "gtk2lib.rpm". That's as stupid as that.
That's why you should all go to http://autopackage.org and see what they are working on.
If they success, we should simply all use autopackage's packages and the installation nightmare will be over.
Just go to the site, read it well and come back here if you still have comments.
Yes the autopackage project is promising but until it produces a final solution you have to use the ones thats available now.
The ones today is debians apt package system and redhats rpm system.
Then you have the combination of them mandrakes urpmi system
which uses rpms managed by a version of debians apt system.
this means that you always have a database that keeps track of what you have installed and what you have available to install.
It also takes care of the dependency problem.
If you install a rpm simply by click on it in a gui browser it will automatically ask for the needed cds or download them from whatever.
This is also usable when you try to uninstall something it will tell you if there is other rpms depending on that one.
There is also the combination of apt and synaptic which gives you a gui version of apt.
/thac
Ok, so I'm a normal usr and I write a program called 'ls' and stick it in my home dir. root comes along and does a dir listing in my home dir for whatever reason. Because ./ is in root's path, he executes my ls program instead of /bin/ls. Mine is actually is a program that changes my usr acct uid to 0. Now my usr has root privledges.
Ok, you say that you just put /bin and /usr/bin in the path before ./, well then I simply change the name of my program from ls to sl and wait for root to make a typo.
Linux is still a multi-user os, not just a desktop wannabe.
Hum!
I belong to the group of people that think computers should be to make things easier for the user.
Now, some of the people here are "desktop users" and some seem to be "server administrators" and some are just "die hard 'lite konservative *NIX hackers".
We, need to understand the different need's of these different people.
I can understand that a (f.ex) webserver administrator don't think it's hard to install binaries/packages because he is happy just seeing the latest version's of apache, php, perl running, fiddle with emacs and don't care about graphical userinterfaces, sound and probably don't even have a mouse attached.
On the other hand we have "Joe the homecomputer fiddler" which always downloads the latest helper app's, game demos theme's and what not from the net, installing deinstalling an app 2-3 times a day.
On the third hand (and here is where i want Linux to grow) there is the "working person" who only uses a computer at work; emailing, working with the appropriate app for his company and maybe listen to some CD. He doesn't like 'puters much, but he needs one to get his work done. Here is where the challange of the word "userfriendly" lies.
I think every die hard *NIX hacker should be forced to make an app for this "working person" just to wipe the ego out of his soul.
Belive me, some people even find Windows and Mac OS way beyond comprehension.
Maybe Linux should be split into a server and a home/workstation version to not kompromise security for the server end, i don't know.
Why not make a "Linux expert group" that desides which lib's should always be shared by default and how the directory tree should look like. I'm for the version numbering in the binary though, this freakin softlinking is nut's, and some sort of reasonable backward's compability.
Don't bother listening to this article. I have extensive experience with many Unix systems, and NOT ONCE have I come across any problem that these measures could have had any effect on.
Here are the big problems in the Unix world:
Packages:
Different package managers.
Insuffecient capabilities in the package managers.
Package maker's varying ideas about where (in the filesystem) the files should go.
Source Compilation:
Dependance on libraries that change significantly.
Lack of documentation about which library version was used.
Non-portable operations/features (eg. OSS v. Alsa)
Nothing mentioned can solve any one of these problems.
In addition, this solution (to a problem that is easilly worked around) would always work in even the rare situation that the libs are in the same directory as the executable. That is not to mention that EVERY Unix program distributed with it's own libs (that I have seen) DOES NOT store them in the current directory.
So, not only would you have to include ".", but also "./lib", "./libs", and every other variation of "lib", or any other directory someone might use. All these extra directories being included only make the lib system less dependable, and all JUST to try to make it so that application developers don't need to launch the program with a shell-script (eg. Mozilla, OpenOffice)... of course, most programs that complex already need a shell script for other initial actions, so the benefits of including "." is absolutely nothing in most cases, and very, very little in the rest of the cases.
I thought of this after reading this article and came up with some ideas.
Here's a snippet of me talking to myself in #linux:
11:28 <Nos[afk]> Something interesting; the quandry that is installing software for the new user.
11:29 <Nos[afk]> Why is it that we don't have a graphical installer that can compile source for you?
11:29 <Nos[afk]> It wouldn't be terribly difficult.
11:29 <Nos[afk]> If it was standard, that is.
11:30 <Nos[afk]> Possible scenarios: the installer asks if you want a global or local install.
11:30 <Nos[afk]> If local, then install to ~/bin.
11:30 <Nos[afk]> Support for RPM's and .Deb's.
11:30 <Nos[afk]> Instead of bailing out on a stupid error, make the installer intelligent to download other packages for you
11:30 <Nos[afk]> So.
11:31 <Nos[afk]> If I'm not talking to myself -- and I am -- then the question becomes:
11:31 <Nos[afk]> If I'm not talking to myself -- and I am -- then the question becomes:
_Why not?_