The Future of Packaging Software in Linux

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."

The solution!

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!

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!

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!

packaging is the most major part of a distribution's job.

This is one of the places Linux gets it wrong. My operating system should not be responsible for all the software I might at some point want to install. Windows messes this up too at times (IE), but MS is much less of an offender than Linux is. It should be responsible for making it easy to install new software, among many other things, but it should not be responsible for every software program out on the web.

An operating system should be responsible for the kernel, file system, and the nuts and bolts of keeping the system running in general. The program creators should be responsible for packaging so that it can be installed (with the help of the operating system) and should also be responsible for dependencies. It should not be my job to spend three hours searching the web for some obscure package that the program creators just couldn't do without. If they see it as necessary, and they know its not readily available, they should package it with their own program (GPL and BSD licenses both support this and is one of the strengths of these licenses).

Re:The solution!

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.

Which is why, as it currently stands, this year will not be Year Of The Linux Desktop. Consumers won't just accept that they can't install software X because it's an RPM and alien doesn't work (this is of course after looking online for half an hour to figure out that alien is the tool to use). Manually compiling from source is simply not an option for standard users. Sure it's a dandy idea, and if you get a "fullproof" GUI that handles the compilation and installation then maybe, but I can't count the number of times make/make install has failed for some obscure reason. The first time grandma needs to go download dependencies means Linux has failed on the consumer desktop.

This is one place that Microsoft and Apple have it right. By having a standardized method of installing and storing program information they make getting new software many times easier than on Linux (excluding the "normal" packages. I'm thinking more along the lines of tools and apps you download from the web). This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.

Microsoft even released the WiX toolkit [sourceforge.net] that allows anyone to create MSI installer packages. MSIs are one of the best ideas for Windows in a while: No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs. Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.

I like apt, but downloading a gzipped file of source or a deb that complains about dependencies still can't compare to an MSI package. Even if a solution was developed that worked as well as or better than MSI, as you say, it would take significant effort (and maybe not even then) to get it supported by all the major distributions. Some people seem to think that the fact that Debian does things differently from Mandriva that does it different than Fedora is what makes the distribution "special". Be that as it may, I think it's only hurting Linux users as a whole.

Re:The solution!

Why do Linux fundamentalists believe that all users are idiots and they should go somewhere else? Until the majority of Linux users and developers get past this mentality we will never see Linux accepted into the main stream desktop market. Yes, most general users can find all the software they need in a single distro, but most users don't know Ubuntu from Fedora from SUSE. If they pick a distro that doesn't include a software package that they want it shouldn't require uninstalling the OS and installing a new one.

If a user picks Fedora or Ubuntu or SuSe, then they should be able to find just about anything they need in their distro's package manager. They all include alternative web browsers, chat clients, games, KDE/GNOME/XFCE, programming tools, image editing software (as best as it gets in Linux), wine, and even different file managers and shells and stuff that average users would never care about switching from the default. If a newbie picks Slackware or DSL or FreeBSD and figure out what to do or how to install programs, then yes, they should switch to a more mainstream and newbie-friendly distro. But there's not that much differences in what's in the repositories of the main distros, so they shouldn't need to switch from Fedora to Ubuntu because of what packages are available.

Distros shouldn't have to include every single piece of software that a user might want also. If they stopped doing this distros wouldn't require 5+ CDs or a DVD or two. Now, don't get me wrong, I appreciate having most of the programs I will need available on a set of five CDs, but this shouldn't be a requirement of distros.

It's not a requirement of distros. Ubuntu and other distros are available on single CDs, with all of the rest of their programs available in the repositories, so you only have to download multiple CD or DVDs if you're installing to a computer without internet or if you just like having all that stuff offline.

Re:The solution!

Last time I tried Ubuntu apt-get package_i_want failed to locate the program more than half the time.

When you use the command line you have to make sure you spell the package name exactly right, for example "sudo apt-get install flash" won't work, but "sudo apt-get install flash-nonfree" does. Synaptic has a really good search feature that I use when i don't know the exact name. If Ubuntu really doesn't have half the programs you want, then what programs do you use and how do you normally get them?

Relying on distros for your software has lead to the sad state we're in now. I don't rely on Microsoft to hand stamp and prepare every piece of software I used on Windows, and I certainly shouldn't have to do the same on my Linux machine. Until we get a method by which I download a file, click on it, and install a program (regardless of which distro I'm running or which version of GTK I'm running), Linux will lag behind. SEVERELY.

I personally like the package management system. I like having one place to look for software for my system, software that I know has been tested with the programs I likely have on my system, software that I know will update with the rest of my system, software I know isn't spyware. It sounds like it wouldn't work too well, but it really works rather well since there are so many programs in the repositories. Even for the programs that don't want/can't be in the repositories, there's ways for people to install those easily as well. There's java programs that install easily regardless of your Linux, there's autopackage, and some developers just put the program and all the files in a zip file that you can extract and then run where ever you want. There are solutions, they probably need better development, but they're not in terrible shape and that's not the most pressing issue for Linux. Much more important is getting the software people really want on Linux (or at least working really well and easy with wine) and making really good oss equivalents to proprietary software (we need something better than gimp to compare to photoshop) and we also need more device drivers, especially wireless. Those are much more important than package management.

Re:The solution!

Which is why, as it currently stands, this year will not be Year Of The Linux Desktop. Consumers won't just accept that they can't install software X because it's an RPM and alien doesn't work

Now my daughter just received a "game" on Windows- brand new (2007) game that insisted on running in some "compatability" mode in Windows, and in a resolution that her LCD display couldn't cope with. The fact is that Windows users have run into this problem attempting to install software that isn't for their particular operating system, and failed on the Internet for a few hours. They just assume that Linux users have run into the same problem.

They don't. Linux users install software out of their software catalog. Occasionally the brave ones go to the author's website, and download the software from there.

This is also one reason people are willing to pay for an operating system that has a standardized and dependable way of doing things.

Bzzt. Wrong. Nobody is willing to pay for Windows, that's why Microsoft doesn't let OEM's give you a choice. Duh, I'll use the Windows I already bought. And don't spread that Lie about how I don't have a License to.

Microsoft even released the WiX toolkit that allows anyone to create MSI installer packages.

But not the MSI format specification. That would allow me to cross-compiler into an installable package. As it stands, my users who run Windows have to deal with no installer.

MSIs are one of the best ideas for Windows in a while ... No more dealing with poorly-written homebrew installers or 10-year old, 16-bit InstallShield programs.

You're wrong, and you want proof? Look how many programs- nay, look how many programs come from Microsoft that are still distributed as exe files. That shiny new Zune's software comes in exe-form.

Once that 16-bit installshield program was written, it's forever supported. You can't put the setup.exe genie back in the bottle, and you have to live with that. With Free Software, we can take our software library with us, which is why Free Software always gets better, and non-Free software atrophies.

Instead you have a fully scriptable installer that's transaction-based and has near 100% support coverage.

You are wrong on all counts. Pull the power plug while installing and you'll see just how transactional it is. I don't even think you know what coverage means: Microsoft Support will tell you to reinstall your operating system if a broken/corrupt/poorly-written MSI breaks your system. Even if they make it.

I like apt, but downloading a gzipped file of source or a deb that complains about dependencies still can't compare to an MSI package.

No of course not, but that's why you used a straw man. MSI is an executable, and just made Microsoft's security problem worse: it introduced yet another executable file format. Nobody downloads "gzipped file of source or a deb that complains about dependencies" ever. They say "apt-get install xyz" and it goes and figures out the dependancies itself.

It doesn't have to- Linux users could waste disk space by including the dependencies with every program- and some Linux distributions even do this(!), but it makes upgrades very difficult. For example, when libz had a vulnerability discovered, only one copy needed to be upgraded on most Linux systems. On Windows, almost every program that dealt with gzip or deflate-compressed data (like png or zipfiles) needed to be upgraded. Worse still, that library or program can be anywhere on your hard drive, and you might never know it.

Re:The solution!

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.

How about we take the easy way out?

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).

Re:How about we take the easy way out?

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".

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?

#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?

Dear lord, no. Bad & outdated third-party documentation is the software world's biggest usability problem.

Software packages should *include* the upstream documentation. That way, the user gets correct documentation that matches the version of the software they installed. If the documentation is very large, it can go into a separate foo-doc package.

The other advantage is that people using the software offline can access its documentation. :)

Re:How about we take the easy way out?

Dude, until I can click on setup.exe, and it just works, and then there is an "Unistall Program" menu in the program folder on the program menu... I just don't have the time. I've used all 5 methods, and they are great for server management, but for general desktop use, people need click and run. Maybe CNR will take off.

"Roll-backs" or "back-rev'ing" would be good.

#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.

Applications Packages

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

There are substantial deficiencies with OS X-style packages, which would only be amplified in the Linux world. In general, OS X packages have to bundle libraries that are not included by default in the OS. This leads to anywhere from a little to a lot of wasted disk space and memory. The problem is limited in OS X, because there is a standard set of frameworks Apple ships with, but this is not true on Linux. As a result, app bundles would have to include things like GNOME as well.

Re:Applications Packages

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

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.

A total load of bullshit, and here's why

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.

The five ways

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.

simple

I prefer a discreet brown paper bag...

Nonissue

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

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

"...never make a significant dent in the Microsoft+Apple consumer desktop market."

Linux will never make a significant dent in the Microsoft+Apple market by doing the same things the same way as Microsoft and Apple.

Look at markets where Linux has succeeded, such as servers and embedded systems. Linux succeeds *because* it doesn't follow the Microsoft license model, the Microsoft development model, the Microsoft business model, and so on. You can't win if you play by Microsoft rules.

Linux can be, and is, an OS for users. It isn't an OS for third party closed source binary distribution. Don't read that as non-commercial; commercial software was distributed in source form before Microsoft and will be again. Distribution in binary form makes sense for games and art, but not for general purpose computing. The value of doing things in software rather than in hardware is that software is malleable. But you need the source to realize the full value; binary distribution removes value.

So yes, Linux will not make a significant dent in the Microsoft+Apple consumer desktop market, if that means the closed binary sales market. If Microsoft played in the NFL, they'd be the Super Bowl winning Colts. But the Colts will never win the World Cup, which is worth more. Don't complain about Linux not hiring a bigger front line when the game Linux is playing is soccer, and doing rather well at it.

Commercialism

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

I always liked

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

RPM gets a nod but....

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.

Hasn't explored other packaging methods

(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

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

Circular dependency hell?

So package foo depends on package bar, and package bar depends on foo.

All you do is:

rpm -Uvh foo.rpm bar.rpm

Circular dependency solved. The circular dependency 'problem' (it never actually really existed) was more of a problem of lack of good documentation than a problem with the actual 'rpm' program. However, this is a problem that was solved years ago - I haven't used a distro in the last 5 years that hasn't had a system like yum, up2date or apt which does all the dependency resolution for you.

goddammit

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.

The hard part...

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.

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

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....

. 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!

Even Bigger Issue

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.

The future to my past....

...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.

Ubuntu

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.

Re:Ubuntu

Why is Ubuntu in that list? I may be misinformed, but it was my understanding that Ubuntu was based off of Debian.

  You're not misinformed, although the author may still have a point of including it on the list of base distributions. There's a slew of Linux distributions based on Ubuntu. Still, you're right. The grandpappy of them all is Debian.

  Here's a fairly comprehensive list [debianadmin.com] of these distributions.

sigh...

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?

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.

That crap in Suse 10.1 sucks monkey nuts

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) 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.

No one really cares...

I'm only exaggerating a little here, but no one really cares about the packaging format per se. They care that the can find, download, install, and run a package without hassles. Most formats take care of the mechanics of that process, but still need a community of people to track down and fix issues - mostly inter-package issues. Rpm and deb both have that kind of community behind them (both with sub-groups). If there is any technology to be improved here, it should be making package repositories better and reducing the workload of the supporting communities.

Been thinking about this problem for a long time

A lot of the focus is on rpms, debs, epkgs, etc., but there's a large body software specific to certain development platforms - think CPAN, PyPI, Gems, ASDF, HackageDB, etc. Many dependencies exist in these repositories, so it's important that they be unified as well. This might not be as straightforward (or possible) as I hope; perhaps one must first think (much harder than I care to ATM) about how the modules across all these platforms should interface/bind to each other.

Furthermore, there would ideally be smooth integration with non-snapshot versions of software (e.g. from local source files or source repositories like CVS/SVN/Darcs). This would particularly be useful for developers to actually run/debug their work.

Until we can completely unify everything - which won't happen anytime soon - I feel the community should refrain from trying to come up with half-way solutions. IMO things like DJB's /package are hurting more than they're helping.

I don't know much about it aside from a quick glance many years ago, but I remember .NET's package system being pretty well thought-out. Strongly named, signed assemblies are critical to preventing versioning hell (just experienced this with the Twill + BeautifulSoup combo in Python). I think the concepts there are simple and should be learned from.

Anyway, until we have a unified software system, I highly recommend a little-known program named Toast [toastball.net] for managing software that lies outside your distro's native package management system. It's a complete hack, but it's damned effective.

We're all trying to be hero's

I think what is happening is that developers all want to be the one to come up with THE best method and they want it to be in THEIR distribution of choice. This leads to many people working on the same task all around the world, and coming to several different conclusions. It goes entirely against the original ideas of Linux. Linux was the result of many people from all over the world coming together to work with Linus's kernel code in order to create a stable and open source operating system. What ensued was marvelous, until the programmers decided to create more and more specialized distributions.

Don't get me wrong, each distribution has its own pro's and con's but ultimately, for the sake of the operating system as a whole, you want to standardize the important components. The most important, in my opinion, is software distribution and software installation. If you're trying to convince a standard user to switch from Windows to Linux, and they go ahead and give it a try, I promise you that when they ask you "OK, so how do I install AIM? or how do I install this..." they will stop listening or paying attention when you've gone through the first couple steps.

Linux by nature requires the end user to have extensive knowledge of the inner workings of the distribution itself. The original idea behind Linspire (formerly Lindows -- thanks for the lawsuit MS :( ) was to make Linux look and feel as much like Windows as possible, so that the end user is practically unaware that they aren't in Windows. This is why they are the creators of CNR and the driving force behind standardizing the distribution method.

Naturally they are a company that is trying to profit from Linux, but then again, capitalism is what this country was based on, and if thats what it takes to get Linux to compete against Windows Vista, than thats fine by me.

ok

Basically all we need is a script that checks what package manager you're using, and adds the 3rd party repository to it and then instructs the package manager to install the package. Someone could whip this up over a weekend. This is hardly worth worrying about.

Face it people, Microsoft has never come close to Linux on software installation.

Why is this rocket science?

What ideas other than the apt/rpm/portage ideas are there? They are all the same idea!

The requirements are pretty obvious.

1) A novice must be able to install any software, update it remove it etc.

2) Upgrading, downgrading or using multiple versions of the same software must be easy.

3) Finding where all files of an application is must be trivial. Unless absolutely necessary, nothing can be spread out, or arbitrarily placed! (/usr/local/bin anyone?)

I think that the port/apt "dependency tree" is making it more difficult than it needs to be. Why even bother with dependencies? If application A needs B 2.0 and C 3.0 then why not bundle those dependencies with the application? The result of course would be that you have a zillion copies of the same low-level dependency, and that you can't update that dependency centrally. Applications that are today 1mb in download size would grow to 100mb with dependencies that I already have. But I wouldn't mind that. I have plenty of disk space and bandwidth, and I'd rather update all my applications to make use of a new version of a dependency, than worry about how my applications whould handle a central update of the dependency.

So...

Is anyone actually working on some kind of universal package installer that wraps around everything else yet?
It would be nice to be able to use rpm, portage, apt, and so on under any other linux/bsd but with one single
package database and a common interface.

rpm, deb -- pick one

RPM and Debian package formats are pretty much "it" when it comes to software distribution on Linux. They are lightyears ahead of anything either Windows or OS X offer. They are consistent for each distribution--everything you need can be installed with a single format and interface--and they work extremely well for keeping everything up to date.

What is particularly evil is the "install on any distribution" or even worse "drag-and-drop" installations because they circumvent all the consistency checks and automated update features of the distributions and standard packaging systems. And "self-updating" distributions are evil because they bother the user with trivia ("Version 1.9.1.23.1 is available; may I waste your time now, or later?") and present a security hole.

Pick one of rpm and deb and stick with it. Both formats can be improved incrementally, and maybe even integrated eventually, but we don't need anything new.

Defective by design

The need for package managers in Linux is a consequence of a desgin defect. First, there's the "lol freedom" philosophy of not having one, two or even three different OS setups and layouts, but a gazillion of them, which causes trouble.

Second, there's the FHS, which is the worst idea to ever make it to Unix. You spread your application files like you deal cards in some card games, being completely unable to copy or relocate them, pack and unpack them effectively, or install several versions of the same program, besides being illogocal and semantically wrong in many parts.

Third, there's the defective LD_LIBRARY_PATH behaviour that makes "." mean the launch directory, not the application directory (holy retarded idea, Batman!). This means you can't rely on putting copies or hardlinks of the required libraries in the application executable directory to keep everything using the right libraries and versions and make them easy to distribute. This led Mozilla to find a workaround with a shell script. When you run Firefox or Thunderbird on Linux, what you're running is a shell script (requires an extra sh instance) that properly sets the environment for the software to be able to use its own libraries regardless of the crap you may have in your FHS "boxes of random crap". Consequently, software like Firefox and Thunderbird do not require a package manager (in fact, PMed versions of them are usually spoiled and crappy), and can be safely copied, relocated, or made to coexist with other versions.

There is a unified package format

There is a unified package format, and that is the source code tarball.

People need to be disabused of the notion that there is anything bad about compiling on your own machine. Gentoo and FreeBSD prove that is not the case.

apt isn't compatible with source builds

At least not as far as I've seen. I've been using Ubuntu and I'm in package hell.

apt works fine for the most part on its own - it just downloads and installs binaries. And it seems to keep its own internal dependency or tagging system. The problem is: these "dependencies" aren't compatible with anything I installed outside apt: source builds, rpm installation, even if I used debian apt packages they aren't compatible with Ubuntu apt packages.

The situation becomes a nightmare as soon as I install something from source - I can no longer use apt for anything that depends on it. Trying to set up a webserver was the biggest pain because for some reason php4 wasn't in the ubuntu apt packages, so I installed it separately, and then I couldn't install anything that required php4 because they all needed "php4-ubuntu".

This has to be fixed. Maybe I should just go to Gentoo and compile everything myself!

Its very simple

Installing things in Linux is confusing and hard to a new user (be they computer iliterate or not) Windows has an incredibly easy installation system that even complete novice's can understand, OS X has a simple way of installing that people can understand.

Linux has 5, none of them simple. Give me something simple that doesn't involve typing sudo something, something and I'll take to it. Why should I have to deal with the source code at all? I get open source products in windows I get an installer than installs the application and puts the source files into a folder for me. I like that.

you guys may love the various install methods but give me and average joe a simple way to install and get used to the OS first.

ease of installing software ..

I'm surprised there was no mention the Smart [susewiki.org] package manager or YaST [wikipedia.org]. I understand that Linspire has a Click 'N' Run [linspire.com] download service. Personally I don't find installing under Linux any more difficult than Windows.

Only I decide what shall be in my systems

in the GNU/Linux world, installing new software is always pretty confusing.

Since I am on Gentoo, I am accustomed to build my packages myself. However, I fail to find any confusion in doing this.

Question

Just to make it clear from the beginning: I'm not a Linux expert. Rather a person who stumbles upon it from time to time, so excuse me if I get anything wrong in the following. As far as I understand, a packet manager doesn't make anything more than checking the version of the packets registered at it, downloading updated versions if present and running the appropriate packet manager. The packet manager then places the files in absolute paths determined by the person who compiled and linked the binaries. My question is, why do they depend on absolute paths at all as they seem to differ on many distributions. Couldn't you just code the applications in a manner that uses adaptive paths, for example, instead of "use the kde libraries that are installed in folder opt/bin/whatever which might be a fully different path in a different distribution" the coder says something like "get the kde library path from some providing service and use that". Instead of having the coder anticipate how the distributions paths etc. look like, it's in the distribution's creator's duty to provide the binary all the information needed to correctly install it. Of course, it would take some standard that exactly describes how a service, that provides this information, would have to look like and which information to provide. A second question would be why the source releases, which have to be compiled by the user, are not additionally delivered in a pre-parsed manner. It would probably save a lot of time during compilation. Thanks in advance

Deltas

Everything that is needed to make a delta of a previous binary release is available on the box. Packages should be reconstructed if possible and a delta from the previous release should be made available. If that isn't possible the new full package should be downloaded. Drive space is dirt cheap and should be the only limiting factor.

Personally I think rpm/deb/etc own anything out there EXCEPT for the fact that I have to download the entire package everytime something gets updated. Even if it only amounts to a few Kb of a 100MB file.

Good Ideas

The USA was a great idea, but it has been slaughtered by morons. The same thing can be said about my OS of choice. So what if there are 5 different ways to install software. Do we really need to dumb it down anymore? You can think I'm being an elitist or whatever, but the truth of the matter is, we don't need to dumb the damn thing down any more than it already is. I mean whether I'm using Fedora or Debian, I can install just about anything by clicking like 2 buttons. Same goes for just about any modern distro there is. We don't need a unified package system. What we need is a unified community that accepts the fact that each distro is different.
In the US we've been slowly taking away our own liberties over the years and most of us don't even realize it. The same can be said with our Operating System. We let idiots come up with bright ideas they feel will make it easier for people to use and what happens is we loose our freedoms. If you want a unified package management system use Mac OS or Windows. Leave my OS alone. I like it just how it is. Thank You!

autopackage

Autopackage, one of the recent efforts of developers to standardize packaging in GNU/Linux has not been very successful

I always thought Autopackage was a neat idea and a good solution for software projects that wanted to distribute binaries, but didn't want to make 10 different versions for every major revision of every distribution. The major problem I had with Autopackage, though, was integration with the distribution packages. It wouldn't satisfy dependencies with what was already installed, and once a package was installed if it was, say, a library, it in turn couldn't satisfy the dependencies of a distribution package. I know integration with the distribution package management system was planned, but it didn't make it into 1.0, and I think that was a major barrier to its adoption.

CNR is interesting, but I'm not sure why it is considered better than, say, Synaptic, other than that it has a mechanism for paying for commercial software (and maybe it makes it a little easier to find some packages). From what I have read, it seems like it is just a nice frontend on the distributions package management system with a link to some commercial repositories. So I don't see how that can really "solve the problem" of package management on linux.

Don't forget about ROX Filer AppDirs.

Taking a note from RISC OS and using AppDirs, this is probably *the* most intuitive packaging system in existence--at least with the current prevalence of the desktop-metaphor user interface. The same concept is also used by Apple and all the NeXTstep derivatives to great effect.

But as usual, never let it be said that a proven and effective mechanism for user interaction would be adopted by the Linux community. :)

How would I do that

Let's name the new cool tool "unipkg". Its purpose is not to create the sixth packaging format, but to easily convert between existing formats, maintain a database of dependencies between other formats' databases of dependencies, ease the instalation from sources (I know, I know, emerge is kewl, etc).

How would I do that:

1. Get the source of rpm
2. Get the source of dpkg
3. Get the source of... $WHATEVER_IS_USED_TO_PACKAGE_THE_REMAINING_THREE_F ORMATS
4. Get the source of alien

5. Insert a mix of all this stuff into unipkg and add powerful commandline interface, so both rpm and dpkg could be virtually replaced with the new packager.

6. The resulting app should also automatically resolve any dependencies, like yast, aptitude, and many others do. Preferred type of packages should be chosen (rpm, deb, tgz...)

7. Also, there should be a simple compiling interface so you can just

$ unipkg source somestuff-2.13rc1.tar.bz2

and it shall bunzip2 and untar it to /tmp, do a default ./configure --prefix=/tmp/unipkg/$PACKAGENAME, make, make check and create a package from /tmp/unipkg/$PACKAGENAME directory. The package should be installed then. Possibly advanced users should be able to customize configure's arguments to fit their system.

8. In config file /etc/unipkg there should be default (preferred or native) package type (so debian and ubuntu users use debs, fedora, mandriva and suse users use rpm...). If a package is to be installed via unipkg, it would be first converted to system's native (or chosen) format (only if not already in that format) via alien part, and then installed. There should also be a list of mirrors, mirror selection system (like netselect-apt), maybe a list of unwanted formats (for example if we don't like the idea of using slackware's TGZs, since they carry no dependencies info), and some kind of system that would protect the innocent from using "testing" or "unstable" packages.

9. This way people could easily install debs on fedora and rpms on ubuntu, all dependencies are resolved, the database is always up-to-date, and everyone's happy =]

10. Now just create a bunch of GUI wrappers. I'm sure both KDE and GNOME teams will create at least a couple of these, and of course an easy CLI tool with ncurses gfx (like cmdline yast or aptitude) would also be kewl.

11. There's still a problem of ABI compatibility, but what would be Linux like without three hours each week spent on repairing stuff =] windows users have to spend even more time on solving other problems which aren't bothering us, so all in all we gain again.

12. There is also a bunch of stuff I don't like, and that (IMHO) should be fixed in some pkg managing systems. e.g. dpkg doesn't care about the dependencies at all, it just installs the package without a word of warning =( One thing I miss is easy and fast instalation of many separate local rpm packages, for example I have downloaded xine and other codecs stuff for suse 10.1, and I have to guess the correct precedence of installing these pkgs instead of doing something like

$ rpm -i libxine*.rpm

The main pro of this solution is that there would be no new package format, but just a common interface for working with existing formats.

The main con is that packages compiled for fedora might screw ubuntu, suse, slackware, etc. up, and vice versa. Maybe some sensitive stuff (like toolchain or some libs) should depend on a virtual package that conflicts with sensitive stuff from other systems.

PC-BSD

What about PC-BSDs .pbi files? They work exactly the same way windows .exe or .msi files work. You just double click,they install, and you later have the option of going into a menu and uninstalling. They also use the ports system and so you have the big repository still at your finger tips. It's the best of both worlds in my opinion.

Zero Install ..

Working with Zero Install [linux.com]

Use the source Luke

I just compile from source when my preferred package flavor isn't available. With GNU Stow you can cleanly install to /usr/local and keep everything playing nice with existing and future package installs.

dpkg vs rpm ... IMHO

Having been a big fan or RH and SUSE and been using RPM for a while now, I used to think that it was better than dpkg. I have used slackware, debian, suse, rh, since 5.0, and various other linux installs.
Recently I decided to try debian again. After installing sarge, I noticed that the software was old ( sorry guys it just is [2005]). So I decided to try something radical. I decided to point my sarge install at ubuntu repositories. First I pointed it at hoary. I ran apt-get update and then apt-get dist-upgrade, and viola. My debian install was now ubuntu. Then I did the same thing moving the system to dapper and then edgy. It is now running xubuntu.
When I had tried to upgrade my fc4 system to fc6 a few weeks ago, rpm couldn't not handle it. Packages did not get installed, the system was in a state of total flux. I had to reinstall FC6 from scratch. Luckily I had my home and important files on seperate filesystems and was able to install the system without loosing any important data. It was much more painful than the debian to ubuntu changes.

So IMHO either dpkg is better or the guys at ubuntu are doing a better job than fedora guys. BTW: Try upgrading a fc system to an equivalant rh system. Last time I tried, you could not.

Oh well. for now I will stick with my fc6 system and xubuntu on my 2 laptops and if in fc7 /fc8 I run into the same issues that I did with fc4-fc6 upgrade, I'll say bye bye fc and hello xubuntu!

Treat it like HD

I've seen two ways to handle the HD/blue war. a.To make a format that can be read both ways, and b. Make a reader for both. APT (dcpg/.deb) and URPMI (my favorite RPM manager) are both so similar, why doesn't somebody make a middleman manager like URPMI to manage between the two of them. Also, RPMs (I'm more familiar with them) are archives with a script, so somebody should make a package that is an executable, but can generate a primative DEB/RPM script? Two solutions.

From the trenches of an upgrader

Last year I installed OpenSUSE 10.1 on my new home pc with the intention of having a new linux workhorse.
All very fine and dandy. Except the updater that took several minutes of cpu time to figure out I was all up to date...

Downloaded the 10.2 upgrade and intended to use that.
First doh: You seem to be supposed to boot the dvd to do the upgrade.
Second doh: Going to the 64bit version threw me into dependency handling hell. I could _not_ get the installer to shut up or remember my choices about ignoring, deleting, or whatnot for the 300-odd packages it complained about. Abort mission.
Third doh: Boot the 32bit version. "Package so-and-so is locked" it said and showed a single name. Ok, I unlock. Then it repeats that 6-7 times (how about figuring them out all in one go?). Click next. Core dump. Repeatable.
Fourth doh (mostly my own): I forced an install (from Yast I think?). It warned me about not being compatible. It wasn't. After a _lot_ of mucking about with a second install and copying back and forth it booted and thinks it is 10.2. I hope it is.
Fifth doh: The install URLs from 10.1 are still in the list. It somehow let me install an older kernel than the 10.2 one. WTF?
Sixth doh (my own?): I don't get the partitioning limits with primary and extended partitions and MBRs on PCs. I use IDE drives in my Pegasos and "it simply works". OpenSUSE 10.2 really messed with the booting setup. MBR or not, GRUB or not, a gazillion entries in the boot selection, most of them the same.
Seventh doh: I tried upgrading from 32bit 10.2 to 64bit. The install did nothing at all. I guess it thinks that 10.2 is 10.2, no matter what cpu you have...
Eigth doh: The OpenSUSE upgrader now uses more than an hour to check my upgrades. In pure cpu time.
Nineth doh (I forgot this one): I looked for some backup utility to save my hide before I begun all this. What on earth are you supposed to use for a rescue install? Tar?

So this probably shows I'm a bit of a noob in linux handing. Next time someone tests a distro I hope they test it as an _upgrade_ too.

Oh, and to show the other side of the coin; I handle AIX systems at work.
I use TSM SysBack to do a network bootable system backup before upgrades (mksysb to local dvd or tape works just as well).
I transfer or just nfs mount the new filesets for all but the most major upgrades. I commit current filesets, install new ones as applied so I can roll back, do the install while running, and then just reboot.
Painless and _remote_install_ friendly (the servers are 270 kilometers away so that kinda helps).
IBM has even promised no-boot upgrades for the future. This is what I call enterprise class handling. Do not settle for less.

Damn shame...

It's a crying shame that AutoPackage is now going the way of the dodo. Heck, if I had the time to learn it I'd package my games in that format. Hearn is right - also, most developers, being techie-minded are still too attached to the .tar.gz method of distribution and leaving binary distribution as an afterthought, usually just chucking out the odd rpm or deb file which is pretty soon horribly outdated. I've not seen many AutoPackaged programs but I updated my aMSN yesterday with it and I just loved it - the way it explains what it's doing, its look, everything. There's nothing fundamentally wrong with rpm and deb. I can't speak for Slack's TGZ or Gentoo's Emerge because I've never used them, but as I understand it they are frustratingly difficult for beginners to use. RPM and DEB, when implemented well, are extremely easy to use - double click, enter root or sudo password, click install - done. Even easier than Windows. The problem is that people tend to tie RPMs and DEBs to rather exotic dependencies which means that they only tend to work on one version of one distro. There's other methods too - BitRock (which is free of charge for GPL projects) and Loki Installer (which seems to be the exclusive domain of games, although I see no reason why it can't be applied to serious apps too) are two excellent efforts which really deserve more attention.

Re:This issue MUST be solved

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 surel

GNU/*

the author uses "GNU/Linux"

And that's one symptom that indicates his views will never become a consensus in the Linux community. This mania of prepending "GNU/" on the Linux name is considered obnoxious by a majority of the people who use and contribute to Linux.

Yes, of course, having gcc and bash available helped the Linux expansion. But let's consider things from a balanced point of view. It's not so hard to write a compiler, linker, command interpreter, etc, which is what the GNU/ software does. Linux would still have existed without GNU/, but, without Linux, GNU/ would be where it was in 1991 and still is today, 16 years later: struggling to make their Operating System, the GNU/hurd, work. "Only a kernel" my ass!

This "GNU/Linux" thing downgrades the perceived value of both GNU and Linux. They make an effort to claim that Linux is a more or less insignificant "kernel", but at the same time it gives the impression that GNU cannot survive alone, it depends on Linux to exist. Let GNU be GNU and Linux be Linux, they are both great by themselves, they don't need to step on each other's toes|

Re:Jar files

Also avoid all that pesky OS integration! Who needs applications to integrade with their desktop anyway?