Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Future of Packaging Software in Linux

Zonk posted more than 7 years ago | from the come-together-right-now dept.

Software 595

michuk writes "There are currently at least five popular ways of installing software in GNU/Linux. None of them are widely accepted throughout the popular distributions. This situation is not a problem for experienced users — they can make decisions for themselves. However, for a newcomer in the GNU/Linux world, installing new software is always pretty confusing. The article tries to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux."

cancel ×

595 comments

The solution! (4, Insightful)

Stormie (708) | more than 7 years ago | (#18064606)

Why do I have a sneaking suspicion that the solution will be to create a sixth way of installing software, which will also not be widely accepted throughout the popular distributions?

Re:The solution! (3, Informative)

tigerflag (648615) | more than 7 years ago | (#18064630)

PCLinuxOS uses a combination of Synaptic with RPMs from the PCLOS repository. Easiest package management I've ever used.

Re:The solution! (5, Informative)

Max Littlemore (1001285) | more than 7 years ago | (#18064836)

Using multiple package formats is great idea, IMO. I use alien on Ubuntu for those situations where the software I want is only avaliable in RPM, but as it says in the summary, new users can be a bit confused by this and building from sources is often too much. I would like to see GUI tools get the smarts to automatically figure out dependencies across all formats, allowing all distros to become package agnostic. Perhaps Linspire's CNR interace would be a good candidate for this.

Also, the option to resolve dependencies and install as a statically linked blob would be awesome for legacy stuff. I've lost count of the number of times I've wanted to install an app, only to find that it relies on some obscure version of xyz.so and won't work, so I find the source for the old version of xyz, only to find it depends on some older version of abc.so. If I could get this xyz.so, etc without conflicting with that xyz.so, create a static binary and put it somewhere under /opt, I'd be happy. I know it's not elegant, and that it uses more storage, but as a work around for difficult to support stuff, it ain't so bad when storage is cheap. Some apps I always install as blobs anyway, such as blender.

BTW, from TFA: Network Access Message: The page cannot be displayed
Slashdotted :-(

Re:The solution! (4, Insightful)

M. Baranczak (726671) | more than 7 years ago | (#18065146)

I would like to see GUI tools get the smarts to automatically figure out dependencies across all formats, allowing all distros to become package agnostic.

The package formats are easy. The real bastard is that each distro has subtle differences in how the packages and the dependencies are organized. The only way that I can see to fix that is to design a universal package tree, and convince all the major distros to conform to it. Which is not impossible, but it aint easy, either. And it might cause other problems.

Re:The solution! (3, Funny)

SnowZero (92219) | more than 7 years ago | (#18064634)

Don't worry, a seventh way will come along to wrap those first six which don't solve the problem, and it will be the ultimate meta-universal generic packaging system.

Re:The solution! (1)

Anpheus (908711) | more than 7 years ago | (#18065088)

Ooh, no. Good guess though. It'll actually be version 7 of that seventh way. Unfortunately, each upgrade will not be backwards compatible with the previous one, and end up causing only more problems.

Re:The solution! (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18064636)

Fat binary; all dependencies complied into it.

How about we take the easy way out? (3, Interesting)

khasim (1285) | more than 7 years ago | (#18064692)

And that is ... define the requirements that the next generation package manager should have.

That way there is no need to worry about "replacing" the existing systems. You can instead focus on evolving them to meet the requirements. Even if each distribution/project takes its own path to get there.

#1. It must make installing new software as easy as it currently is with apt.

#2. The same for upgrading the software.

#3. The same for removing the software.

#4. The same for handling dependencies. Including the order in which dependencies must be installed.

#5. The same for validating the installed software against the original software (checksums or whatever).

#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.

#7. The ability to point the updater at your own repository or multiple repositories.

#8. The ability to recompile (automatically) any software that you install for your specific hardware.

Anything else? Yeah, I know most of this is already handled with apt. But that's what I'm most familiar with. I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation).

How about we take the easy way out?-Fallback. (0)

Anonymous Coward | more than 7 years ago | (#18064728)

I've noticed that no one does roll-backs.

"I keep seeing all the articles about "problems" but I don't seem to run into any problems on my server or workstations (and I'm running Feisty Fawn on my workstation)."

Kinky! I'm running the BBB* on mine.

Breasty Babe Beaver.

"Roll-backs" or "back-rev'ing" would be good. (3, Insightful)

khasim (1285) | more than 7 years ago | (#18064788)

#9. Good point. Being able to easily roll-back an "upgrade" that didn't work would be a very nice feature. So I've marked this as number nine.

In fact, Ubuntu might be switching to the Smart Package Manager http://labix.org/smart/faq [labix.org] which seems to support this functionality.

I also left out ...

#10. Mark packages so that they will NOT be upgraded. The same as I can do with apt.

#11. Fail gracefully. (1)

khasim (1285) | more than 7 years ago | (#18065142)

Assuming that you can find the source code with a partial configuration file for the new requirements, the system should identify what functionality has been included and what has not been included and offer to try to guess what acceptable entries would be (or allow you to enter your own).

Re:How about we take the easy way out?-Fallback. (2, Informative)

seifried (12921) | more than 7 years ago | (#18064992)

up2date (front end for RPM) includes the option ("5. enableRollbacks yes/no"). RPM supports rollbacks, config files would be saved as [filename].rpmsave or [filename].rpmnew depending on exactly what you are doing.

Re:How about we take the easy way out? (1)

kernelpanicked (882802) | more than 7 years ago | (#18064846)

Congratulations, you just reinvented rpm and yum.

Re:How about we take the easy way out? (1)

DoubleRing (908390) | more than 7 years ago | (#18064868)

Actually, rpm and yum are a reinvention of apt/deb and synaptic.

It doesn't matter. (1)

khasim (1285) | more than 7 years ago | (#18064958)

Who has the longest or most distinguished genealogy doesn't matter. We all borrow from each other now, anyway. :)

Once the requirements can be hammered down ... we can start looking at the MINIMUM lines of code that would have to be included with the source code to turn that source code into an application that can be installed and maintained (to some minimum degree) by the next generation of rpm or apt or dpkg or yum or whatever.

I believe that all these articles focus on the wrong issue. It isn't about which package manager is "best" or which method of installing software is "best". The "best" is different for each admin. What is "best" for someone managing 5,000 boxes at Google may not be the "best" for someone managing 100 boxes at some other company. Nor would either of those ways be "best" for someone running his/her own box at home. Nor would any of those ways be "best" for someone doing development work at IBM.

Instead, let's look at everything that could possibly be needed ... and then make it easiest for the most commonly encountered issues.

If one of the issues is getting unpackaged code onto your machines, what is the minimum information needed, in what format, which can be handled (safely) by the main package management systems?

Re:How about we take the easy way out? (4, Informative)

QuantumG (50515) | more than 7 years ago | (#18064986)

Apt rules, shame about dpkg. Even bigger shame that apt is built on dpkg, eh?

What pisses me off is the 32 step process to making a deb (that's what dpkg calls a package btw.. just incase you're playing acronym bingo out there). So if you want to install something you built from source, and be able to remove it later, you need some freakin' magician to have made it into a source package.. cause there's no way in hell you're doing it yourself.

What really depresses me is that debs, dpkg and apt, that's about the best anyone has done. Unless, of course, you actually like building everything from source.

You want "checkinstall". (4, Informative)

khasim (1285) | more than 7 years ago | (#18065054)

What pisses me off is the 32 step process to making a deb (that's what dpkg calls a package btw.. just incase you're playing acronym bingo out there). So if you want to install something you built from source, and be able to remove it later, you need some freakin' magician to have made it into a source package.. cause there's no way in hell you're doing it yourself.

Checkinstall http://www.debian-administration.org/articles/147 [debian-adm...ration.org]

It's not the answer to all issues regarding installing from source ... but it does handle some of them.

What really depresses me is that debs, dpkg and apt, that's about the best anyone has done.

Any suggestions on what would make them even better?

Re:How about we take the easy way out? (2, Informative)

seifried (12921) | more than 7 years ago | (#18065062)

#1. It must make installing new software as easy as it currently is with apt.

up2date -i [package name]

"This package will require the installation of these additional packages, accept?" Yes/No

#2. The same for upgrading the software.

up2date -u [package name]

"This package will require the installation of these additional packages, accept?" Yes/No

#3. The same for removing the software.

rpm -e [package name]

#4. The same for handling dependencies. Including the order in which dependencies must be installed.

Already done, see above. up2date will find dependancies, dependancies of dependancies, etc. until it is done, then present you the list and confirm to install all the packages, you hit "Y" and you're done.

If you just want to check what would be a dependancy you can:

up2date --solvedeps=[package name]

which accepts a comma deliminated list of packages as well as a single package name

#5. The same for validating the installed software against the original software (checksums or whatever).

To verify packages installed (or package files not yet installed) you use the verify option:

rpm --verify

Which can check the GPG sig of the package file, the MD5 sigs of the files, etc. allowing you to detect any tampering or changes.

#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.

up2date --force [package name]

rpm --force [package name]

#7. The ability to point the updater at your own repository or multiple repositories.

/etc/sysconfig/rhn/up2date

serverURL[comment]=Remote server URL serverURL=https://xmlrpc.rhn.redhat.com/XMLRPC serverURL[comment]=Remote server URL serverURL=https://www.centos.org/XMLRPC

#8. The ability to recompile (automatically) any software that you install for your specific hardware.

rpmbuild -ba

But in general major vendors provide optimized packages for various architectures that rely on heavy math/etc (kernel and OpenSSL being two of the important ones)

Re:How about we take the easy way out? (4, Insightful)

wizrd_nml (661928) | more than 7 years ago | (#18065064)

#1. It must make installing new software as easy as it currently is with apt.
#2. The same for upgrading the software.
#3. The same for removing the software.
#4. The same for handling dependencies. Including the order in which dependencies must be installed.
#5. The same for validating the installed software against the original software (checksums or whatever).
#6. The same for re-installing the software over the existing installation when you accidentally delete or over-write something.
#7. The ability to point the updater at your own repository or multiple repositories.
#8. The ability to recompile (automatically) any software that you install for your specific hardware.
...and it must do all of this without telling me what it's doing, because I don't care what it does as long as the software then works.

Re:How about we take the easy way out? (0)

Anonymous Coward | more than 7 years ago | (#18065080)

Sounds like Java Webstart to me. The only one I'm unsure it handles is #6 "re-installing the software over the existing installation".

Re:How about we take the easy way out? (2, Interesting)

srealm (157581) | more than 7 years ago | (#18065118)

One more thing.

Make it easy to install software that has DIFFERENT dependencies.

The classic example I always give is LDAP - you either want it or you don't. However why should I install LDAP because some application decided to link against LDAP? Or conversely, what if the application was NOT linked against LDAP and I want LDAP support in the app (which is available in the app itself).

Unfortunately, the only real solution to this is source based installs or having a compile for every combination of dependencies. But possibly something that will allow you to specify dependencies, and if you break from the 'blessed' dependencies, still has the ability to compile the base version (with no extra steps required by the user apart from saying 'yes, OK, do the compile'). Without requiring it to recompile ALL packages involved (ie. if the LDAP is coming from some library used by the app you requested to be installed, it should only recompile that library, not everything or the final app (since its using shared code and not using LDAP directly).

And as an addition to that, there should be a way to 'offshore' said building to a build server (or servers) - that will keep the package once built (with record of its dependencies) - so that if you are deploying on a large scale, you can use the SAME package manager that comes with the default distro on ALL your boxes, and install your package with custom dependencies (triggering a compile), and then when you install that package with the same dependencies later, it will just pick up the pre-built version, just as if it came from the official pipe.

These kind of problems are rarely solved at all by packaging systems, and usually installing from a source archive for a single package on a binary distribution is a pain in the neck - especially if you want to actually build from a source archive with ALTERED dependencies. Right now, only completely source-based distributions allow you to change dependencies, but then you need to pay the penalty of building EVERYTING (yes, Gentoo and such have their pre-built packages for large modules like Gnome or KDE, but you still end up building a lot).

Basically, I'm saying I could not really use a binary packaging system unless it had the ability to fall back to source altering its dependencies (which means the package needs to know HOW to compile disabling and enabling certain things (ie. configure flags), not just how to compile the same way the binary distro was made), and do so seamlessly and without forcing the user to go though 7000 additional steps or have intimate knowledge of how to compile an application. Remember, from the amdin's point of view, they just don't want to install LDAP unnecessarily, they don't specifically want to have to know how to recompile XYZ package to exclude LDAP support, or even if they know how to, want to have to do that for every package that is optionally supporting LDAP using manual procedures to disbale LDAP support.

This, and the fact that getting 0-day releases for certain packages when a new version comes out (sometimes a new release fixes a specific bug you have been waiting to be fixed) without having to recompile it all myself and break the packaging system or have to get more intimate with the packaging system than I want are the reasons I switched back off of Ubuntu and back to Gentoo. I tried Ubuntu because I wanted to see what life would be like without having to compile all the time - but in the end found I could suffer the compile (especially with things like distcc) to have a system the way I like it without extra crap installed because it happened to be compiled with support I don't need, want and will never use.

PreZ :)

Re:How about we take the easy way out? (3, Insightful)

LesFerg (452838) | more than 7 years ago | (#18065126)

You left out the parts that usually alienate new users;
- Link it into the menu/desktop system
- Also link in help or documentation, or at least a relevant URL

Even somebody who has used Linux for many years and feels comfortable with apt, rpm etc, can still occassionally be annoyed as all hell when an application is installed, then you have to go searching all over the web to find some basic configuration guide, let alone finding how to start the app.

In fact, maybe part of the packaging system could include linking in the wiki that everybody uses to tell others how they made the demmed thing work.

Re:The solution! (1)

black88 (559855) | more than 7 years ago | (#18064898)

Kind of. But kind of not.

You see, it really is simple, and of course, for the complete newbie (Grandma, etc), we would want to shield or obfuscate the process as it relates to compiling (at least until they feel comfortably competent).

All we need to do is provide documentation, and, I don't know if perhaps this would be something to include in the LSB or maybe have the major distros agree to document it with instructions on the desktop and in any packaging, since those most likely to be confused by the various package and install options might just be the ones to order a cd instead of downloading an .iso.

Honestly, five years ago, when I first discovered Linux, my introductory distro was Slackware! It was not pretty, and I did have to search high and low, but I eventually found documentation to help me with any particular problem I may have been searching for.

Now, running Ubuntu 6.06, I am perfectly comfrotable either compiling source, installing a .deb, or running Apt-get.

But it took me some time to get here, and, again, I beleve with the proper documentation, and minimal hand-holding of the newbie, most folks could get around the "problem" of choice by making an informed decision.

Re:The solution! (1)

Jessta (666101) | more than 7 years ago | (#18065036)

Portage is your solution.
That is all.

Applications Packages (5, Interesting)

SultanCemil (722533) | more than 7 years ago | (#18064612)

If only major linux distros would use Application Packages like OS X, the world would be a better place.

Seriously, drag-n-drop installation rocks.

Re:Applications Packages (1, Interesting)

Whiney Mac Fanboy (963289) | more than 7 years ago | (#18064672)

If only OS X users would stop whining about OS X in linux stories, the world would be a better place.

Seriously, being able to read a linux story without inevitable, (innaccurate & irrelevant) OS X comparisons would rock.

Re:Applications Packages (1)

SultanCemil (722533) | more than 7 years ago | (#18064828)

The trouble is, its *true*. I don't believe that this is inaccurate or irrelevant. The largest problem linux has is that there is no defined standard base. If I'm writing an application, I have no way to know that all target computers will have the correct libraries. Sure, dependencies exist and can be satisfied - if you want to go through dependency hell.

What I'm trying to say is that Linux needs a standard library base that is cross-distro. That way a distro can claim to be "Linux Standard 12 Compatible" - and the user knows that it will work. Linux Standard 12 would of course mean you have to include certain libraries. This means drag and drop installation WOULD work.

Re:Applications Packages (1)

Whiney Mac Fanboy (963289) | more than 7 years ago | (#18064890)

Waaaah! Waaah! Waaaah!

Linux apps could be D&D install already - all they have to do is statically compile.

Noone in the linux world wants OS X style bloat tho' (I mean, running FF, MS Office and Illustrator concurrently appears to require 4GB of ram unless you want an almost constant beach ball).

Re:Applications Packages (2, Insightful)

Overly Critical Guy (663429) | more than 7 years ago | (#18064990)

OS X style bloat? How about Linux style bloat. If you run Firefox, OpenOffice, GIMP, and KIllustrator, that's four entire windowing libraries and widget sets loaded into memory including libraries from two different desktop environments.

I love your evidence though. "Appears to require 4GB of ram." Right, dude. Right.

Re:Applications Packages (2, Funny)

jrockway (229604) | more than 7 years ago | (#18065076)

But wait, if you run Firefox, OpenOffice, GIMP, and KIllustrator on OS X, it requires *5* entire windowing libraries.

Re:Applications Packages (1)

croddy (659025) | more than 7 years ago | (#18064910)

Forgive me, but are you trolling, or did you simply not think to search for linux standard base [google.com] ?

Re:Applications Packages (1)

Overly Critical Guy (663429) | more than 7 years ago | (#18065014)

It's not inaccurate or irrelevant to point to a better package solution that happens to be implemented in another UNIX operating system called OS X (and NeXTStep before it). Why isn't someone allowed to bring up that Linux hasn't caught onto a package implementation that's been around for 20 fucking years?

Re:Applications Packages (1)

SnowZero (92219) | more than 7 years ago | (#18064674)

As does clicking on a checkbox [nongnu.org] . Seriously, I don't need it to be any easier.

What we do need now are better guides telling people what they need to install for a given problem, since the link from task to program/package name is not always obvious. I know I can use google for that, but a more centralized and guided way would be nice for less technical people. That's why I think that click-n-run [linspire.com] has its place.

Re:Applications Packages (5, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#18064790)

As does clicking on a checkbox. Seriously, I don't need it to be any easier.

Unless the software you want isn't in the Synaptic repository. Then it's hell on earth for the average user. The only response they get from support and developers is, "Why would you want to use software that isn't in the repository?"

Actually, that's not true. There are plenty of other fun responses:

"You should compile it from source."
"The vendor should spend his time getting his software added to our respository!"
"Use RPMFind. I'm a developer and I've never had a problem installing binary packages on the distro I work on." (Conveniently ignoring that when something breaks, the "developer" fixes it himself.)

Not that there's much point in harping on this again. I'll just get the same, "U R STUPID", "You need to try distro XYZ", and "Everything is in my distro's repository!" answers I've gotten before.

Blinders on, and full speed ahead cap'n!

Re:Applications Packages (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18064956)

like when I was trying to create a deb for personal use (and creating it the right way, not this checkinstall bs) I got hassled by ubuntu universe devs why do I want to create such a package and I should just be happy with the version they provide. I told them why (the version back then, and the one that still stands still doesnt support my HW, only the cvs version does, I understand why they dont include it, but I was merely asking for advice) and they ripped me apart telling me to sell my hardware or get my money back on it somehow or to just wait and stop bitching and be happy with what's in the repository.

In the end the debian folks were much kinder, and helped me out.

Re:Applications Packages (1)

DoubleRing (908390) | more than 7 years ago | (#18064980)

Well, I'd have to say that with most software projects, they provide a makefile. Yes, I know that it's a little bit steeper of a learning curve, but come on, it's not THAT much more work. Now, if the user is not savvy enough to go through the make process (which is usually only 2 commands long), then I don't think that they should be installing that stuff anyways. Just think, the stuff that's in the repositories are the packages least likely to cause problems with the installation. I've found most everything I've ever wanted in the repositories. The stuff that's not in there usually shouldn't be there. The amount of hassle that I have with make pre-installation (library problems, etc.) is usually indicative of the amount of trouble I'll have post-installation. Once the package is massaged enough by the repo managers to fit, then it is both more accessible and less likely to cough up errors. I'd say that it's not so much the vendor's job to get into a repository so much as to provide a suitable makefile from which a user could install their program, and thus a base from which a repo manager could work.

Personally, I think the repository system is brilliant. It sure beats running to the story to buy software, and being able to just randomly do a search for packages is great. I can do a search for "video editor," and it brings up Kino, Cinelerra, MPlayer, and a myriad of other things. That's how I found inkscape. One day, I needed a vector illustrator, and I did a search. You can't beat the convenience of that. It's a lot better that what you'd get if you went up to Wal Mart complaining they didn't have something. Their response would be, "Why would you want software that isn't in the store?" The thing is, most people don't even know software outside the store exists. They live in the Windows Bubble. But the Linuxen are different, which is what makes us harder to please. It's like when a doctor gets sick--it's hard for them to step back and become the patient again.

Applications Paperwork. (0)

Anonymous Coward | more than 7 years ago | (#18065042)

"Well, I'd have to say that with most software projects, they provide a makefile. Yes, I know that it's a little bit steeper of a learning curve, but come on, it's not THAT much more work. Now, if the user is not savvy enough to go through the make process (which is usually only 2 commands long), then I don't think that they should be installing that stuff anyways."

Interestingly enough this is similiar to the answer prospective computer geeks get. If you don't meet [insert requirements here] then you're not allowed to play in our sandbox. Go back to Windows and "doing it for money, not love".

Re:Applications Packages (1)

YGingras (605709) | more than 7 years ago | (#18065096)

What do you suggest? A distribution is nothing more than a set software repackaged so that they will work together. Most packages are nothing more than the compiled binaries and a machine parsable list of dependencies. But, many packages are hacked by the distro maintainers to ensure that they will work according to the distro guidelines. The job of the developper is to code, the job of the maintainer is to integrate and this is good.

Distros are different because they have different target markets and different priorities. There are distros made to fit on a floppy, distros made for desktops, distros for server and there are several niche markets well served by their own distros. If a developper want to ensure that his code works well on all those environment, he will have to run them all. He shouldn't. He may well try a few popular systems and you can be sure that on his target market the README in his tarball will be accurate. Yes, that's not easy for the average user, thats the price that we pay for the flexibility of being able to make all those distros.

I don't know how to solve the installation problem. So far, relying on distribution maintainers to do the integration is what works the best. There could be some sort of source package for a typical distro; in fact, there are a few of those. The problem, I think, is to define what is typical distro is.

Re:Applications Packages (1)

BW_Nuprin (633386) | more than 7 years ago | (#18064700)

Yes, I would love to see the OS X install methodology on more systems. I dunno what else to say, just that there are at least two people out there who think it's a good idea.

thirdsies (0)

Anonymous Coward | more than 7 years ago | (#18064810)

make that three people. Shared libraries had their day back when hard drives were measured in like single megabytes and if you had a full meg of RAM you were rich or at work, but today? With good broadband on top of it? And the speeds of CPUs? Who cares? Go to town, live a little, take a walk on the *wild* side and buy another stick of RAM. Put the dependencies inside the application and just be done with it, heck, run your serious major apps in their own virtual sandboxed off space with their own stripped and tweaked kernel for that matter.

Re:thirdsies (1)

Achromatic1978 (916097) | more than 7 years ago | (#18064894)

buy another stick of RAM

And yet when this seems a possibility for Vista, cue the "Who wants to pay hundreds of dollars for upgrades for functionality I have now?!?!"

Re:Applications Packages (5, Insightful)

croddy (659025) | more than 7 years ago | (#18064702)

The reason Linux distributions have not been trembling to adopt the OS X style of package management, if you can call it that, is that it would be a poor fit for the Linux software ecosystem.

The vast majority of software used on Linux systems is licensed under the GPL; what is not is almost always under another license permitting free redistribution. This gives Linux distributors great freedom in selecting and assembling a compatible collection of versions, tested and working with the same versions of dependent libraries. In a larger distribution (such as Gentoo, Debian, or Fedora), most of the software you will ever need is already a part of the OS -- you just need to use the built-in package management tools to summon it from the distributor's repository.

OS X-style package management is best suited for a software ecosystem in which users draw software from a large number of heterogenous third-party sources, while the core OS and iLife suite are maintained and updated by Apple. A third-party distributor who wishes to distribute something that must link against a particular version of a library can include it in the application bundle, knowing that the exact version needed will be available. This can lead to many copies of the same libraries being installed, facilitating compatibility with applications that require different versions, but consuming (small amounts of) disk space unnecessarily and increasing the attack surface when multiple copies of an exploitable library are installed on the system. A system such as APT does not need to provide a facility for private copies of libraries, since it does all of the dependency computation, and all software in the repository is built and linked against the libraries in the repository.

Certainly, once you have resigned yourself to visiting a third-party distributor's web page, manually downloading a binary package, and then manually installing the binary package, drag-and-drop installation is very convenient. But the Linux software ecosystem does not require this concession from the user -- the Linux distributor is free to provide a repository and tools for finding, installing, and updating software, without the need for manual installation.

Re:Applications Packages (2, Informative)

Ash-Fox (726320) | more than 7 years ago | (#18064738)

If only major linux distros would use Application Packages like OS X, the world would be a better place.
Because you can't install RPMs on DEB syste.. Oh wait, you can.

Most distributions let you convert&install/install other package formats, this article's problem is a non-issue in my opinion.

And no, I don't think drag and drop is easier. I just want to type the application name I was to install and that's it. Not having to worry about updates etc.

The OS X method:

Find website of program
Download program
Open disk image that contains program
Open applications folder
Drag and drop the application folder from the disk image
Create new icon in dock
Have to recheck the site periodically to check for a update for a specific program

Debian package system:
sudo apt-get install firefox thunderbird seamonkey

(you can choose multiple applications if you want even)

or graphically,

Open Adept
Type in program name
Click "request install" (you can choose multiple applications if you want even)
click install

Updates -- I wake up in the morning and see Adept telling me there are updates available for some of the software I use.

Re:Applications Packages (1)

Climate Shill (1039098) | more than 7 years ago | (#18064870)

That's all very well if I want a package that's in the repository, but if I want one that isn't ? Or a version that's newer than the one in my distribution ? Then unix installation is sheer hell.

Re:Applications Packages (1)

Trelane (16124) | more than 7 years ago | (#18064932)

That's all very well if I want a package that's in the repository, but if I want one that isn't ? Or a version that's newer than the one in my distribution ?
Then you do the same thing that you do on Mac or Windows. You download the package and build the package yourself. Often, there will be a package you can install on your system, but this need not be the case. Unless you're talking about proprietary software like Photoshop or something, in which case you do the same thing as in Windows--you run the installer. This is what InstallShield or Autopackage are for.

Then unix installation is sheer hell.
I don't see how it's unique to unix.

Re:Applications Packages (1)

Climate Shill (1039098) | more than 7 years ago | (#18065102)

You download the package and build the package yourself.
Building a package is almost exactly not what I mean by easy installation - and the fact that software authors so rarely provide packages on their websites suggests that they don't feel it's a trivial amount of work either.

Then you do the same thing that you do on Mac or Windows.
I don't think I've ever seen a Windows program that didn't run within a couple of mouse clicks.

A total load of bullshit, and here's why (5, Informative)

Overly Critical Guy (663429) | more than 7 years ago | (#18065068)

My favorite thing in package discussions is when someone with an agenda towards a particular implementation writes out a list of steps. The alternative is always padded with extra steps to make it more difficult-looking while their favored implementation is reduced to look squeaky clean and easy.

You padded the Mac list with the following:
  • "Open disk image that contains the program." - DMGs are auto-mounted by Safari.
  • "Open Applications folder." - There's already an Applications shortcut on the Finder, so you just drag to that when the disk image window automatically opens.
  • "Create new icon in dock." - The fuck? You don't have to do this
  • "Have to recheck the site periodically to check for a update for a specific program" - Bullshit. This doesn't even have to do with package management, and it's an OS X convention for apps to auto-check for updates when they're run. You don't have to recheck any websites.

Your Debian list conveniently leaves out having to click the KDE start menu, fire up a Terminal window, type in the root password, waiting while the package manager goes through dependencies, etc. What a phony comparison of steps. I could just have easily reduced OS X's step to one line of "Drag app icon to Applications shortcut" in the same the way you reduced Debian's steps.

Re:A total load of bullshit, and here's why (1)

blofeld42 (854237) | more than 7 years ago | (#18065104)

The basic problem is that Linux installs spew a zillion freakin' files across the filesystem, and keeping track of them and their interactions is a mess.

OS X has applications (drag & drop, self-contained) and system-level frameworks for shared stuff. All nicely compartmentalized. If you want auto-update you can just retrofit an rss feed to the system.

not really (2, Interesting)

ArbitraryConstant (763964) | more than 7 years ago | (#18064746)

The problem is not that everyone is willing to accept a solution that sucks, the problem is that the current solution of integrated package management rocks.

All I need to do is search for something in the package manager GUI, click the its checkbox, click "apply", and I'm done. It's even easier than downloading a dmg, because you've got to go out and find that dmg on the publisher's website, or versiontracker or whatever. I simply express a desire for that program to be available, and then downloads, installations, updates, etc are all handled by the package manager. This even works for proprietary software (eg I have Nvidia's binary drivers, Adobe's Flash and PDF reader, VMWare Player, etc installed through my distro's package manager).

The best solution is for the vendor to supply whatever they're going to supply in a tarball, and then let the maintainers figure out what the dependencies and so forth are.

Re:Applications Packages (1)

KayosIII (655272) | more than 7 years ago | (#18065074)

One Word klik http://klik.atekon.de/ [atekon.de] you have to install and set it up initially but after that it is easier than an OSX install

The five ways (3, Informative)

Harmonious Botch (921977) | more than 7 years ago | (#18064616)

For those who don't TFA: There are currently at least 5 popular ways of doing it:
1) Installing directly from source code,
2) Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
3) Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
4) Installing from distribution-independent binaries (most proprietary software is delivered this way),
5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.

Re:The five ways (1)

rm999 (775449) | more than 7 years ago | (#18064798)

It seems to me that this way is the best method for 90% of people (I'm a Linux n00b):
4) Installing from distribution-independent binaries (most proprietary software is delivered this way),

I apologize if the answer to this is obvious, but why isn't everything packaged that way?

Re:The five ways (1)

CaptnMArk (9003) | more than 7 years ago | (#18065012)

Installation must NOT involve any execution of the code from the package.

If it does it is likely that uninstalls and upgrades will not work reliably.

Re:The five ways (1)

Nasarius (593729) | more than 7 years ago | (#18064842)

5) Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.
There are very good reasons why autopackage hasn't been accepted. It's hopelessly broken [gentoo.org] . Anyway, asking for one unified package format is like asking for exactly one Linux distro; it betrays a fundamental misunderstanding of the OSS community.

simple (1)

jjeffries (17675) | more than 7 years ago | (#18064618)

I prefer a discreet brown paper bag...

Nonissue (1, Insightful)

eklitzke (873155) | more than 7 years ago | (#18064624)

The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code. Any software that is even moderately popular will be packaged by volunteers. If I need some software that isn't already packaged for me, I grab the source code and compile it. If it's something I plan on sharing with other people, I'll write a spec file and distribute the RPM I build.

I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen. Debian based distros have an enormous time investment in the .deb format, RPM distros have a huge investment in the .rpm format. Likewise for Gentoo, Arch, Slack, and all the other distros with their own formats. There are legitimate reasons for sticking to native formats because of distributions' build infrastructures and installation backends. As long as the source code is available, everyone will be able to install your software, and everyone will be able to use the format of their preference.

Re:Nonissue (4, Insightful)

rsmith-mac (639075) | more than 7 years ago | (#18064696)

I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen

Then realize you're basically accepting that Linux will never make a significant dent in the Microsoft+Apple consumer desktop market. You may be able to compile the source code, the rest of us either don't know or don't care. Either Linux is going to be a OS for users, or a OS for geeks. It can't be both because geeks will try to escape a OS too user-centric, and users will escape a OS that resembles the inconsistency caused by groups of splintered geeks.

Re:Nonissue (1)

spitzak (4019) | more than 7 years ago | (#18064732)

Though I don't agree with him, he quite clearly said he believed people who know how to compile the code would compile any popular program for each package format. He did not say that everybody would compile from source. Read a little more carefully next time.

Nonissue-One HELL of an issue. (0)

Anonymous Coward | more than 7 years ago | (#18064908)

There's two problems I ran into with the source code package method. One it consumes CPU resources which can be significent (try doing KDE for an example). It also eats up hard-drive like no one's business. The main package, and a whole host of packages that have even the remotest connection with it, and their connections, and so forth and so on. And heaven help you if you can find the particular version the maintainer used. Maybe on the net, maybe in CVS somewhere (and that brings it's own problems). It'll drive you crazy.

Re:Nonissue (1, Interesting)

croddy (659025) | more than 7 years ago | (#18064782)

You may want to read this excellent essay, entitled Linux is not Windows [oneandoneis2.org] . I think it will offer you some valuable perspective on the issues you're addressing.

Re:Nonissue (1)

melikamp (631205) | more than 7 years ago | (#18064982)

Who rated this insightful? What does this have to do with "making a dent in the market"? Nothing prevents a hardware vendor from choosing a distro and sticking with it. Who cares if there are 12 other distros out there? The customer wants Firefox and OO to run, and they will run. GNU/Linux already has the best packaging system ever for an inexperienced user (deb), and any vendor is free to support it, or to relegate the support to a specialist company.

Re:Nonissue (2, Insightful)

Lord Kano (13027) | more than 7 years ago | (#18065030)

Either Linux is going to be a OS for users, or a OS for geeks.

Exactamundo!

Maybe this makes me a heretic, but I don't think that Linux should ever try to become a mainstream user OS. A part of the allure of linux is that it is hard. The learning curve makes users feel like they've achieved something by becoming proficient.

If you made a distro, how would you prefer to spend your time? Would you rather deal with "XYZ_lib_devel is out of date, we need a package for the new version." or "How do I get AIM, ICQ and Yahoo messenger to work?", "WTF is this GIMP thing? Is it like pulp fiction?" and "How do I install MS Office on this"?

LK

Re:Nonissue (2, Insightful)

oberondarksoul (723118) | more than 7 years ago | (#18064718)

The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code... If I need some software that isn't already packaged for me, I grab the source code and compile it.

Most users don't know what compiling software is, let alone how to do it. While having the source available is absolutely a good thing, there needs to be an easier way for new Linux users to install software. With so many different formats, some specific to some distributions, some to others, and so on, it's almost impossible to keep track - if Linux is to gain more share on the desktop it needs to be more accommodating to new users, and the current situation frankly isn't.

Re:Nonissue (1)

dotgain (630123) | more than 7 years ago | (#18064720)

The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code.

...for open-source software, yes. Say I want Adobe Acrobat Reader (OK, I most certainly do not, but just say..).
Most of the time I can find an RPM, and rpm2tgz hasn't let me down yet.

Re:Nonissue (1)

bigstrat2003 (1058574) | more than 7 years ago | (#18064760)

It's not a non-issue, because it keeps anyone who's new, or isn't sure what they're doing (like my parents, although they don't use Linux so this doesn't apply to them), won't know what to do. Are you seriously suggesting that people without technical knowledge go and compile the source themselves? Or that they should be able to figure out which version they need? I hate to be the one to point this out, but it won't matter if you explicitly label it according to which distro a format goes to, because to the uninitiated, Linux is Linux is Linux. Yes, Linux isn't an OS for the faint of heart, but if we truly believe in its superiority, we need to make it as accessible as possible to those without any technical knowledge.

Re:Nonissue (1)

TheDugong (701481) | more than 7 years ago | (#18064856)

"if we truly believe in its superiority, we need to make it as accessible as possible to those without any technical knowledge."

So for something to be superior it has to pander to the LCD?

Re:Nonissue (1)

bigstrat2003 (1058574) | more than 7 years ago | (#18064966)

Not at all, but if it's superior we should want to spread it as much as possible (well, unless you hate other people and wish an inferior product upon them... and that's fair, some of those other humans are jerks ;)). To spread it as far as possible, we need to make it accessible. That doesn't necessarily mean dumbing it down... it means ensuring that basic functionality is easily understood by all, while still retaining advanced functionality for those who choose to take advantage of it.

Commercialism (1)

JPMaximilian (948958) | more than 7 years ago | (#18064654)

CNR seems very...business oriented. I don't see a lot of hardcore linux users adopting it.

Re:Commercialism (0)

Anonymous Coward | more than 7 years ago | (#18065070)

True, but CnR isn't aimed at us. Its aimed at your grandmother.

Here is a real life story about a friend of mine (with 0 computer skill beyond word/excel/IE)
It started with her machine crashing constantly. She called me to fix it. What ended up happening was the motherboard was dying (chipset actually) anyways, So she had to buy a new machine, and i talked her out of the Dell route and for me to build one for 1/2 the cost and have it running the same day.

So i tried to install WinXP that came with her orginal dell (should work right? same drive, same type of processor) only issue was the CD key on her case was invalid. (Well, it IS a dell...) She didn't want Win2k because "it looked ugly". She opted for going with Ubuntu (with beryl as she had seen on my machine, lots of ooos and aaahhs from various non-tech people)

So i installed, updated to 6.10, nvidia's video card drivers, beryl installed, secured, all the goodies easily accessable, etc etc.

Then she asked me how to install something. So I opened up Synaptic for her. After 4 hours of showing how to use this, and how to install/find programs/remove them (i explained it very throughly ;) She still has trouble to this day 4 months later using synaptic and adept. No way shes going to use a command line. (Yeah 6.06 first, i updated last week :P)

A few days ago, I had a Lindows system running, and showed her CnR. She knew exactly how to use it. It was well, non-tech proof. CnR has its place, to allow those of us with no tech skills (whom out number us btw by quite alot..) to easily install/run programs they want/need. Using a command line, or a description only package manager just won't work. People want to see it first. They want screenshots. They want, well, Click once, and be able to run it. (Aptly named program CnR ;)

I see this as a good sign, and a great move towards the adoption of Linux to the masses. With vista costing money, lots of it.. People will be more likely to spend nothing or $29.99 for an off the shelf distro than $299 for vista if it has all the same abilities as Windows offers, namely installing programs. We already have the basics that 99% of normal people use, (Gamers excluded, bussiness first, home second, THEN games... we can do this the microsoft way ;) So all we need is the ease of use, which CnR does perfectly.

Though.. the subscription thing needs to be dropped... that sucks...

I always liked (1)

iminplaya (723125) | more than 7 years ago | (#18064688)

I always liked those big, fat books that came with the CDs.

I have a feeling (2, Funny)

true_hacker (969330) | more than 7 years ago | (#18064694)

I bet RMS would be jumping around with joy reading this article, the author uses "GNU/Linux".

RPM gets a nod but.... (3, Insightful)

westyvw (653833) | more than 7 years ago | (#18064706)

Debian and Ubuntu don't even get a mention on what they DO use? This article makes it sound like RPM is THE package management system. Give me a break, at least a mention that a similar package approach (and more successful IMHO) is used by the Debian etc.

Re:RPM gets a nod but.... (1)

bendodge (998616) | more than 7 years ago | (#18065110)

I started tinkering with Windows 95 at ~8 years of age, and have been a computer junky ever since. About a month ago I installed Kubuntu on a blank machine while I waited for parts, and loved it.

But I almost gave up when I was trying to install nForce drivers, and it kept failing after I restarted. After hours of trying and Googling for information, I finally found a list of required "packages". I thought, "Aha! This must be the problem!"

So I diligently searched the internet for these "packages". Many hours later, I was on the verge of giving up, when I noticed a "Package Manager" utility. Shazam! It all worked.

Just think how much time I could have saved if every website I found had not assumed I knew what a package was! Another assumption was that I knew how to use makefile and install. People who write Linux software manuals shouldn't assume the user knows what terms mean! (Esp. since many of them are very similar to Windows terms, and people just assume they are the same thing.) Basically, all the instructions for the free distros assume you know the jargon. Fix that, and Linux will suddenly be more much more "user-friendly".

Hasn't explored other packaging methods (5, Informative)

shermozle (126249) | more than 7 years ago | (#18064708)

(while discussing RPM)

Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it.
What that means is he hasn't used any other packaging formats. Common mistake that people think RPM is somehow "best" because it's used by a few distros. Do some searches for "circular dependency RPM" to see why that's just not true.

Re:Hasn't explored other packaging methods (5, Informative)

DoubleRing (908390) | more than 7 years ago | (#18064852)

Hear hear! I have mod points, but I'd rather post.

Circular dependencies, aka RPM hell, is what actually prompted me to make the switch from the Red Hat family to the Debian family. I used to be a pretty die hard Red Hat user. It used to be that Fedora was the cutting edge, back in the core 2 and 3 days. I would have those days when I would wrestle with the packages, but I just took my hits and moved on. Then Ubuntu came along, and I realized how much time I was wasting with that stuff. It "just works." APT is great (it's a pity POSIX decided to go for RPM). Gentoo's portage is really cool too, but IALAB (I'm a lazy bum--if you can't reconcile the acronym, then you probably shouldn't know what the missing word is).

Re:Hasn't explored other packaging methods (1)

TheDugong (701481) | more than 7 years ago | (#18064906)

"APT is great" Grrr!! Sorry, but my pet hate! apt ~= yum i.e. go and find the packages I need dpkg ~= rpm i.e. install or remove the package All the package managers do is copy, move and delete files, keep a list of what files/packages are installed and keep a list of where packages can be obtained. The reason why Ubuntu "just works" is because: 1) The Ubuntu team keep a tight(er) reign on the repositories, so there is very little need (if any "need") to use 3rd party repos. 2) More stuff that people need it in the repositories so you do not get A. Newbie trying to install an ancient RPM on a modern system and having it screw wverything up.

Re:Hasn't explored other packaging methods (1)

DoubleRing (908390) | more than 7 years ago | (#18065034)

All the package managers do is copy, move and delete files, keep a list of what files/packages are installed and keep a list of where packages can be obtained. The reason why Ubuntu "just works" is because: 1) The Ubuntu team keep a tight(er) reign on the repositories, so there is very little need (if any "need") to use 3rd party repos. 2) More stuff that people need it in the repositories so you do not get A. Newbie trying to install an ancient RPM on a modern system and having it screw wverything up.
Um, I missed the part where this is a bad thing. Is this not a good thing?

Re:Hasn't explored other packaging methods (1)

Soko (17987) | more than 7 years ago | (#18064862)

What that means is he hasn't used any other packaging formats. Common mistake that people think RPM is somehow "best" because it's used by a few distros. Do some searches for "circular dependency RPM" to see why that's just not true.

The vast majority of people who aren't Linux geeks, or rely on a commercially supported distro get RedHat or Suse. Guess what package format they use?

I agree that RPM isn't the best, but in an enterprise setting it's what you get. I'm hoping Canonical can make inroads to that market with Ubuntu supplemented by Click'n'run, myself. If that proves commercially strong, the others just might follow suit and use the .DEB format in order to access C'n'R.

Soko

goddammit (4, Insightful)

scenestar (828656) | more than 7 years ago | (#18064712)

We have apt and *.debs

I'm not in the mood for a holy war right now, but for fucks sake, Debian perfected package management a decade ago.

Re:goddammit (1)

croddy (659025) | more than 7 years ago | (#18064752)

Don't forget about Debconf! The ability of the OS to centrally manage configuration for a variety of applications is one of the most important advantages of the Debian style of package management.

Hell Yeah! (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18064824)

Absolutely right, never mind the inconsistencies as they don't affect the normal user.

For example, all my wife needs to know is: open Synaptic when she needs some software. Or even (gosh, how difficult) look for software on the Internet, open Synaptic and type the name in.

I believe the article is missing/trying to say that regardless of the package method used CNR will provide a wrapper for all of them. So the solution is not to create yet another method (that will never work), but embrace all the existing ones in an easy-to-use interface.

That interface will be provided in both Freespire and Ubuntu Feisty. It should be good for newbies, hardcore Linux people will hate it (although that doesn't matter: it's not aimed at them).

The hard part... (3, Interesting)

PornMaster (749461) | more than 7 years ago | (#18064726)

The hard part, as I see it, is dependency management for upgrading software.

Eventually, with RPMs, for example, I end up getting to the point that I have to force something, which shouldn't ever really have to happen... but it does.

The hard part...the bits. (0)

Anonymous Coward | more than 7 years ago | (#18064816)

I like the way squeak handles it. Point to a repository. Pick what you want, and it downloads*, compiles, and integrates into a running system without any noticable effect(1), say having additional functionality. Even handles dependencies.

*Usually the code isn't very big, compared to some binaries.

(1) Save your image first, because bad code can cause issues. That's why some only run code that's ready.

They don't care about the file ext., fix the list (2)

BillX (307153) | more than 7 years ago | (#18064808)

Well, they all involve a long list of available programs you could choose to install (plus dependencies, etc.) Granted, some have meta-package choices, e.g. "workstation collection", but past that, it comes down to a dumfounding-to-newbies long list of packages whose developers tried really hard to come up with a clever acronym, name it after their favorite band/old Norse god/tropical fish's Latin name, etc., rather than something that gives some clue as to what the program actually does. Personally, probably the most off-putting thing my first time installing a Linux distro (besides hardware configuration, which has gotten much better since then) was a package selection dialog with thousands of entries like:

GRAPPLE - GNU Remote Authenticated Potato Peeler Library for Emacs

If the chosen package manager cleans that up, or at least moves it from Big Long List to the more fine-grained categories a la download.com, the first-time user isn't going to care whether the package is a tarball, .deb, or what-have-you (provided the installation doesn't barf)

argggg.... (1)

zx-15 (926808) | more than 7 years ago | (#18064814)

. Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it

Oh God, not again. The article provides one sided view on rpm vs. deb war. In fact this article sucks, whoever wrote it never did the homework on the matter and just thrown in some info on few packaging systems picked at random. If this was a decent article it would talk about the most current packaging formats like gentoo/bsd ports, would talk a lot about difference between deb/rpm, get some overview about most popular packaging systems: apt-get, rpm, urpmi, yast, emerge, pacman for Christ sake, but Nooo... it basically says that rpm is the only working format and whoever is not using it is gay.

Now this thing get linked here. Way to go, Slashdot!

Re:argggg.... (1)

leozh (106368) | more than 7 years ago | (#18064872)

To me it seems like the best solution is a combination of both. If you use apt-get on top of RPM, the solution is a system that works great with dependency resolution and management, while making package building far simpler than with Debian Packaging.

This issue MUST be solved (0, Flamebait)

bogaboga (793279) | more than 7 years ago | (#18064830)

There are many ways software is packaged in the Linux world, I agree 100% on this issue. But I also know that until software becomes portable *across* distributions, chances of Linux gaining a foothold in Joe User's mind and on hid desktop will be continue to be illusive at best. This is not good enough.

I have always wondered why bright minds, working for "free" and able to produce an OS that is giving corporations with big budgets a run for their money, cannot agree on how best to package software. To many users, we in the Linux world are still a bunch of jokes.

Sadly, it appears that because of bigotry, selfishness and ego, it will be a few more years before those that command authority in the Linux world wake up. I hope we'll still be relevant by then.

This reminds me to digress a bit...Joe User asks for an improvement in GNOME's file dialog, which is still very wanting and is instead met with the poisonous "I know it all" attitude.

Re:This issue MUST be solved (2, Insightful)

pandrijeczko (588093) | more than 7 years ago | (#18065082)

There are many ways software is packaged in the Linux world, I agree 100% on this issue. But I also know that until software becomes portable *across* distributions, chances of Linux gaining a foothold in Joe User's mind and on hid desktop will be continue to be illusive at best. This is not good enough.

You're making the somewhat dangerous assumption that a general policy of "one sizs fits all" is what the Linux user base both wants and needs - this is entirely incorrect.

For example, as an experienced Linux user, the last thing that I want is a single, binary-packaged method of distribution of software. I use a source-code based distro called Gentoo which means that I get to compile the stuff I run my way on the basis that, if something goes wrong with compilation (as it does sometimes) then it's up to me to try to work out why. But the advantage is that I get to optimize all my applications the way I want to, all of them (hopefully) linked nicely to system libraries as they should be.

Sure, this isn't the way Joe Public wants it but then if he wants something simpler then, great, good luck to him - use something simpler. I've used Ubuntu a couple of times and this seems to heve a pretty good package management mechanism which I guess is based on the Debian system. (Please don't flame me if I'm wrong here, BTW, but Gentoo is the only Linux I really use these days so I fully admit to not being up to speed on other package management methods.)

I have always wondered why bright minds, working for "free" and able to produce an OS that is giving corporations with big budgets a run for their money, cannot agree on how best to package software. To many users, we in the Linux world are still a bunch of jokes.

This has absolutely *NOTHING* to do with "agreeing" to anything and you have totally missed the point of Open Source. Open Source is about a single or bunch of programmers thinking that they have a neat way of doing something with software and then making that software available for others to improve. Ultimately, if you're looking for Open Source software to achieve a specific task, then you probably have a number of different applications to choose from which will achieve at least some of what you want. This view of the world is typified by Vi and Emacs, for example, both of which at their heart are text editors but can be extended in certain ways to do a whole lot more. Consequently, some people prefer Vi, others prefer Emacs, that's just what happens when people get choices.

Unfortunately, as things stand currently, you cannot come into the OSS world with a "Windows mindset". In the OSS world, you do not hand over some money and have a piece of shrinkwrapped software fall into your lap. Instead, you have to take some responsibility for your computer and what you run on it and there's an expectation that you take the time to research what's out there and decide what you're going to use and how you're going to use it. Nobody's forcing you to use Open Source - it's there if you want it but if you don't, then stick with Windows and enjoy it.

Linux and OSS is *NOT* a fashion statement - it's not about being "cool" or different. If you use either, then be an adult and accept the ramifications of that decision. OSS will not come to you, you need to go to it.

Sadly, it appears that because of bigotry, selfishness and ego, it will be a few more years before those that command authority in the Linux world wake up. I hope we'll still be relevant by then.

Sorry, but now it is quite clear you've lost it - you're now sounding like a bitter little man who's frustrated with Linux and/or OSS but is not prepared to put in some effort to helping himself.

"Bigotry"? Where? If you mean that certain people have rejected the Windows way of doing things and have decided to do things a different way, then surely that's their choice, isn't it? I really can't see how it's impacted Windows users in any way - apart from in a good way where OSS surely acts as a benchmark to those people making commercial software who have to now put a lot of effort into making quality commercial software in order to stop people just using the free alternatives.

"Selfishness"? You mean the people that give up their time *freely* to write source code that, in effect, is thrown into the public domain?

"Command authority"? Sorry, but who has this single authority? Linus exercises some controls over what goes into the kernel purely because he believes that's the best way of not letting things get out of hand. But nothing stops you writing whatever drivers you want to patch into the kernel and using it that way yourself.

And any application beyond the kernel might not necessarily be used in a Linux system anyway - because it depends on what you want to use that system for.

his reminds me to digress a bit...Joe User asks for an improvement in GNOME's file dialog, which is still very wanting and is instead met with the poisonous "I know it all" attitude.

If you mean to tell me that you (or someone you know) has approached the Gnome coders asking for this feature and been rudely rebuffed, then that is most definitely wrong. But I suspect it's probably more the case that person was told by the Gnome team that the feature is not on the development map for Gnome in the near future - and that to me is perfectly fine. If thousands of people wanted that feature then the developers would probably see a strong case for making that change - but if it's only a few, why should they change their plans simply for a handful of people? Do you really see Microsoft adding a feature to MS Office purely because half-a-dozen users want it? Do you not understand what a chaotic mess would be created if programming teams (in either the closed or open source worlds) had to completely change what they were doing every time somebody asked for something?

I would strongly suggest here that if you're having problems using Linux then get off your backside and start helping yourself. There are myriads of Linux books, web sites and chat forums where you can go and politely ask a whole heap of willing people for help - provided you do so in an intelligent and polite fashion.

And if you're not prepared to make that commitment to helping yourself, then don't use Linux because it really isn't for you.

Even Bigger Issue (1)

SlantyBard (1040070) | more than 7 years ago | (#18064838)

I find that this is really a moot point because of the even bigger issue of trying to get on-line access via your network. Network access is very simple given Windows or OS X but for some reason, always seems to be a hassle with Linux. Just look at the Linux forums for various packages for evidence.

Re:Even Bigger Issue (1)

pandrijeczko (588093) | more than 7 years ago | (#18065132)

And if you look in those forums deeply enough, I'm sure you'll find an answer to whatever networking problems you have.

Sure, it can be tricky (and sometimes impossible) to set up some wireless stuff on Linux - but then the solution is to carefully choose your hardware and do some research into what is and isn't supported by Linux before you make the commitment to use it.

And as for wired networking, pretty much every distro in the past five years has supported DHCP out of the box such that by the time you've booted it the first time, the network connectivity is there.

Beyond that, it's a case of understanding the network characteristics which you would have to configure into your OS whether you were using Linux or Windows.

The future to my past.... (1)

Nitroadict (1005509) | more than 7 years ago | (#18064928)

...experiences with Linux:

The assortment of such being the usual numerous live cd's tried and the numerous excersions into linux forums, bombarded by "advice", I can safely say (IMO) the future looks questionable in terms of linux becoming popular (mainstream), let alone the way linux packages software. Linux just isn't lazy enough; and yet no one wants to admit it when most who use it are programmers/non-lazy people/engineers/whatever that most average users are not, and may never be. Admitelly, when Im very hyped on coffee on the odd ocassion, getting onto Knoppix can be fun/rewarding, but as soon as I'm sober and/or I begin messing around with the CMD, I sigh and boot back into Xp, knowing I can get stuff done more efficiently since it's easier to navigate.

Of course, thats until I get the umpteenth BSOD because my fucking wireless adapter somehow messes shit up or i get the damn IRQL's again. Luckily, due to my perseverance in saving money, I'll be riding myself of this problem by purchasing a 20 inch IMAC around the time Leopard comes out. IF XP sucks balls then Id imagine Vista more or less swallowing; despite the usefulness in gaming vista might be, id rather stick with XP, buy a PS3 when the price goes down, and even wait around for gaming on the mac to pickup.

For now, Linux remains an odd curiosity; to me, it will remain the high school japanese class that stresses learning vocabulary and getting you the grade instead of the SVO and punctuation structure until a new teacher and/or class appears, finally showing the light to those who just don't seem to get it.

I do have hopes for Linux though, but honestly, I think the Google OS, er, Haiku [wikipedia.org] looks interesting ;D.

Jar files (0)

Anonymous Coward | more than 7 years ago | (#18064936)

Just use Java and avoid all the distro differences.

Article for lazies... (0)

Anonymous Coward | more than 7 years ago | (#18064946)

GNU/Linux is known for its diversity and freedom of choice. There are multiple window managers and desktop environments, many competing systems for handling sound, graphics and hardware autodetection. This diversity is the power and weakness of free software. Exactly the same problem concerns installing software in GNU/Linux. There are currently at least 5 popular ways of doing it:

        * Installing directly from source code,
        * Ports-based installation (where the source packages are held in a repository and can be automatically downloaded, compiled and installed), like BSDs ports of Gentoo's portage,
        * Installing from distribution-specific packages like different versions of RPM, DEB, TGZ, and other packaging formats,
        * Installing from distribution-independent binaries (most proprietary software is delivered this way),
        * Using another distribution-independent system like autopackage, zero-install or klik -- none of them gained a significant market share so far.

This situation is not a problem for experienced users -- they can make decisions about choosing the best way of installing software themselves. However, for a newcomer in the GNU/Linux world, this situation is pretty confusing. In this article I am going to sum up some of the recent efforts to fix this problem and examine the possible future of packaging software in GNU/Linux.
Package formats wars

The war of packaging formats in the GNU/Linux world is reaching its peak. The developers of competing formats are doing their best to convert as many distributions as possible to their products. Here is a short summary of the latest activities in this area.
RPM unites

Red Hat Magazine has published an article called The Story of RPM about the history of RPM package manager. It used to be a very strange product. Its ancestors: RPP, PMS and PM were separate projects with similar goals. When RPM arrived, replacing the former standards, it was first being developed under the same name by many GNU/Linux distributors independently, causing a lot of confusion and interoperability problems. Recently, this situation has changed and the major distros (those basing on Red Hat and using RPM) decided to unite and work together on the development of RPM. It's great news for the distributions like Fedora, PCLinuxOS, Mandriva or openSUSE. Still, a lot of other systems like Ubuntu, Debian, Slackware, Gentoo or Linspire do not use the RPM format and do not plan to incorporate it.
Autopackage slowly vanishes

Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful. Despite a promising debut and even providing a stable 1.0 release (the most recent version is 1.2.1, Autopackage is dying. The programmers (actually only one is actively working on the project) believe that the lack of success of the project is caused by the reluctance of Linux vendors who are well accustomed to the current status of distro-dependent package systems and don't want any change.

It may also be that Mike Hearn -- the project founder, now a Google employee -- is right. He claims that the project did not gain enough popularity (and none of the distribution-independent packaging efforts did, actually) because of the dominating doctrine which states that it's the distributor who should be responsible for the whole operating system. It is kind of similar to another popular opinion: that the administrator (root) should be responsible for the whole machine, and all the administrative operations should be preformed from a separate root account. These kinds of centralized management systems fit to the server market, but they don't really reflect the desktop reality that well. On desktops, the administration is only one of the roles the user plays and waiting for half a year for a new version of an application is often unacceptable. It is often a decade in the free software world!

"I eventually concluded that Linux was never going to make the big improvements to desktop computing that I wanted to see, and, therefore, that it'd never get non-trivial market share. That's one reason why these days I work on servers for Google instead of client-side stuff for a Linux company." -- Hearn concluded.
Conary approach

Another interesting approach to packaging is presented by the Conary team. Conary is a mixture of a package manager and a version control system. This tool has gained the acceptance of a few vendors and it is feasible that it will be adopted in those systems in one form or another. It is however no revolution since it does not resolve the biggest problem -- the incompatibility of the current solutions.
Where does the future of packaging lie?

As far as freeing the packaging from the distributor is concerned, there are at least two directions possible. The first is the wide acceptance of the refreshed CNR (Click-And-Run) system, which is going to support all the major GNU/Linux distributions in the near future (and in time, even more platforms). The plans to make the development of CNR more open creates a chance to gain the community and finally -- the vendors. Currently only Linspire and Ubuntu (from version 7.04) support the system, but if few other major distros accept it, it may be enough to spread the new de-facto standard in the Linux world, since most of the distributions are Debian, Fedora, Ubuntu, Mandriva or SUSE-based anyway.

Another option is the fast evolution of LSB's Linux Standard Desktop Project. Linux Standard Base may help to standardize at least the versions of the core libraries used in the major distros making it much easier to produce general packages in the future. It seems to be a serious option since LSB is already widely adopted in most distributions and the fact that the LSB guys chose to cooperate with the vendors instead of creating the new standard on their own works for the benefit of the standard.

Whatever the future if packaging will be, it is good to see that the Linux vendors (seem to) have finally agreed that the current situation is not satisfactory and the future of GNU/Linux acceptance depends on standards, also the packaging ones. Hopefully, one will be formed in one way or another, soon.

Ubuntu (1)

burntsigil (898978) | more than 7 years ago | (#18064960)

From TFA:

...since most of the distributions are Debian, Fedora, Ubuntu, Mandriva or SUSE-based anyway.
Why is Ubuntu in that list? I may be misinformed, but it was my understanding that Ubuntu was based off of Debian.

sigh... (2, Insightful)

element-o.p. (939033) | more than 7 years ago | (#18065038)

Why, oh why does everyone always have to gripe that "distro x doesn't do things the same way as distro y?"

Linux, unlike proprietary, closed source software is about choice. That's what I LIKE about Linux--I can choose the way that I prefer, be that how to install packages, which desktop environment to use, which CLI shell to use, if Linux boots into a CLI shell or if it goes straight to X-Windows, etc.

*BIG sigh* Why not ask the mainstream users? (2, Insightful)

NeuroManson (214835) | more than 7 years ago | (#18065046)

Look. If you want mainstream acceptance, then appeal to the mainstream. THAT is what will determine the best distro.

One of the previous episodes of Drawn Together put it best:
Spanky (to the TV Reviewer): No wonder you hate the show so much. You're everything we make fun of! You're a Jewish, conservative, pro-life, born again, overweight, Asian, homophobic lesbian broad who cuts herself!
Reviewer: So?
Spanky: So, maybe someone who doesn't happen to be a Jewish, conservative, pro-life, born again, overweight, Indian, homophobic lesbian broad who cuts herself might not be offended by our show.
Reviewer: I have every right to tell people what I think of your show.
Spanky: Yes! But people should know you're not our audience, asshole!

You aren't making an OS to appeal to the guy in the cubibicle next to you in the CS class in college. You're making an OS, by your own claims basically, to overthrow the evil overlords (AKA Microsoft, if you ain't got it yet). So why is this STILL a debate today?

Keerhist, I'm a furry artist, and even I recognize the concept of a limited market margin, but I don't spend my time in debates and having epileptic fits or Tourettes outbreaks in order to try forcing non furry fans to accept what I draw. Jeeze.

Re:*BIG sigh* Why not ask the mainstream users? (1)

pandrijeczko (588093) | more than 7 years ago | (#18065100)

Look. If you want mainstream acceptance, then appeal to the mainstream. THAT is what will determine the best distro.

Who's looking for "acceptance"??? I'm just looking for neat ways of doing stuff with computers...

That crap in Suse 10.1 sucks monkey nuts (0)

pair-a-noyd (594371) | more than 7 years ago | (#18065112)

I upgraded from Suse 10.0 to 10.1 and I was PISSED at the total piece of shit, I think it was called "Smart" or something like that. What a pile of monkey shit that was. I found it to be so broken and so unusable that I wiped my disk clean and reinstalled Suse 10.0.

I have no intentions of even looking into 10.2 because I'm in the process of backing up everything so I can wipe Suse (for their sins) from my system and replace it with Gentoo. 2007.0 should be out soon but I'm going to go ahead and load up with 2006.1 for now.

There are only 3 methods (1)

bug1 (96678) | more than 7 years ago | (#18065128)


1) using your distro's tools and packages.
If this doesnt work change distro's

2) from source code.
This should be fine as long as the user knows what hes doing and doesnt overwrite distro's files.

3) using 3rd party tools or packages.
Dont expect it to work, its a totally flawed concept, this method is for people who dont understand what a distro is, if it did there would be only 1 distribution. This is why LSB packages are doomed.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...