Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future of Packaging Software in Linux

Posted by Zonk on from the come-together-right-now dept.

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

34 of 595 comments (clear)

  1. The solution! by Stormie · · Score: 4, Insightful

    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?

    1. Re:The solution! by tigerflag · · Score: 3, Informative

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

    2. Re:The solution! by SnowZero · · Score: 3, Funny

      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.

    3. Re:The solution! by Max+Littlemore · · Score: 5, Informative

      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 :-(

      --
      I don't therefore I'm not.
    4. Re:The solution! by M.+Baranczak · · Score: 4, Insightful

      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.

    5. Re:The solution! by Anonymous Coward · · Score: 3, Interesting

      A great idea??? Are you serious?

      Choice is good - until the point where it becomes totally overwhelming. On linux there are dozens of distros to chose from (different versions of the said distros too - running on different versions of the kernel), different window managers to chose from, different installers (apt get or whatever, applies to both the command line and the graphical installers), different package formats, different shells, too many different text editors (vi/emacs/...) and such.

      Most users appreciate SOME choice. Like when you go to the dealership, you pick the car model, the engine, color and such. The linux way, you'd be forced to hand pick things like the actual metal alloy used for the pistons' segments and such intricate things most people couldn't care less about. Yes, you could have a totally custom car, but it would take 6 months to pick all the parts by hand, and comparing the cars to another would be so complicated and overwhelming...

      Too many confusing choices to make, often over stuff one doesn't really understand. And when searching for information about them (to make the choice), often all one finds is heated debates (like kde/gnome or emacs/vi) without much real information.

      When I use my PC at home, at work, on the road, at friends or relatives' places, it's always the same interface (plain old WinXP), same way to do things, stuff located in the same places, most apps are the same, etc. Predictable, consistent and simple. Most people truly appreciate that.

      If we were all running linux, I'd be using say, KDE or gnome, work might be using fluxbox, a friend would use something like xfce... All on different distros that work differently and have different apps installed by default (likely not the ones you're used to). I'd be lost.

    6. Re:The solution! by nmb3000 · · Score: 5, Interesting

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

      --
      "What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
      /)
    7. Re:The solution! by trianglman · · Score: 3, Insightful

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

      --
      Clones are people two.
    8. Re:The solution! by mrsbrisby · · Score: 4, Insightful

      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.
    9. Re:The solution! by ElleyKitten · · Score: 3, Informative

      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.
      --
      "What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
    10. Re:The solution! by ElleyKitten · · Score: 4, Informative

      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.
      --
      "What is Internet Explorer 7? Are you saying we can't access the normal internet?" - I love tech support. Really.
  2. Applications Packages by SultanCemil · · Score: 5, Interesting
    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.

    --
    Cemil.
    1. Re:Applications Packages by croddy · · Score: 5, Insightful

      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.

    2. Re:Applications Packages by AKAImBatman · · Score: 5, Insightful

      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!
      --
      Javascript + Nintendo DSi = DSiCade
    3. Re:Applications Packages by be-fan · · Score: 3, Interesting

      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.

      --
      A deep unwavering belief is a sure sign you're missing something...
  3. The five ways by Harmonious+Botch · · Score: 3, Informative

    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.

  4. How about we take the easy way out? by khasim · · Score: 3, Interesting

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

    1. Re:How about we take the easy way out? by QuantumG · · Score: 4, Informative

      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.

      --
      How we know is more important than what we know.
    2. Re:How about we take the easy way out? by wizrd_nml · · Score: 4, Insightful

      #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.
    3. Re:How about we take the easy way out? by LesFerg · · Score: 3, Insightful

      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.

      --
      If I had a DeLorean... I would probably only drive it from time to time.
    4. Re:How about we take the easy way out? by wordisms · · Score: 4, Insightful

      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.

    5. Re:How about we take the easy way out? by cortana · · Score: 3, Insightful

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

  5. Re:Nonissue by rsmith-mac · · Score: 4, Insightful

    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.

  6. RPM gets a nod but.... by westyvw · · Score: 3, Insightful

    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.

  7. Hasn't explored other packaging methods by shermozle · · Score: 5, Informative
    (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.
    1. Re:Hasn't explored other packaging methods by DoubleRing · · Score: 5, Informative

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

      --
      Before you die, you see DoubleRing...
    2. Re:Hasn't explored other packaging methods by Alioth · · Score: 3, Informative

      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.

      --
      Oolite: Elite-like game. For Mac, Linux and Windows
  8. goddammit by scenestar · · Score: 4, Insightful

    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.

    --
    perpetually dwelling in the -1 pits
  9. The hard part... by PornMaster · · Score: 3, Interesting

    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.

    --
    500GB of disk, 5TB of transfer, $5.95/mo
  10. "Roll-backs" or "back-rev'ing" would be good. by khasim · · Score: 3, Insightful

    #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 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. You want "checkinstall". by khasim · · Score: 4, Informative

    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

    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?
  12. A total load of bullshit, and here's why by Overly+Critical+Guy · · Score: 5, Informative
    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.
    --
    "Sufferin' succotash."
  13. Re:Ubuntu by deek · · Score: 3, Informative

    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 of these distributions.
  14. Re:Nonissue by zzatz · · Score: 5, Insightful

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