The question was not, what you see as advantage, but what makes success in the desktop market. The reality with central repositories is that you have to wait months for (feature) upgrades. Or tinker around. Yes, a central repository is fine for the enterprise market, but not for the desktop end-user.

BTW: I don't trust hundreds of "package maintainers" fiddling around with OpenSSL, breaking the PRNG and leaving half of the world with 16 bit SSH keys for years. I use Slackware (which does vanilla packages) for a reason and compile everything else myself.

Without background knowledge one can confuse app stores with distribution repositories. But the approaches are completely different.

1 members found this post helpful.

Yes I had, but I have since returned and read the entire article twice more. But I still come away with much the same feeling that it is more market-speak and not so much to do with package management, at least in any sense that fits my notions of package management (which I admit may differ from others'...).

For myself, this summarizing paragraph is simply stupid, but it still is a fair summary of the article...

In other words - Linux stupidly followed closed source 10-15 years ago, so hey! Let's all do it again!

It seems to me that this is yet another turn of the "one package for all distros" delusion which, if ever reaalized would only benefit the commercial vendors of bad software.

The fact that different distros have opted for different variations of the packages they distribute, and how they are managed, is the source of my own freedom, not a negative thing!

I have made the free choice to use Slackware based in no small part on the superior approach to package management taken by Patrick Volkerding and extended by SBo and others.

If that negatively affects someone's app store visions, then that is just too bad! We don't need no stinkin' app store!

(All in good humor, but that is my take on the arguments...)

3 members found this post helpful.

Just found this but, you might be interested in it for easier package maintaining:

There's always Slapt-Get here: http://software.jaos.org/

And these which act like a version of Gentoo Portage for Slackware:

Emerde - http://emerde.freaknet.org/

PortPkg - http://portpkg.berlios.de/

Be advised that Emerde is Beta software and should only be installed on a minimal system to avoid package conflicts with installed packages.

Portpkg however uses SlackBuild like install scripts.

Remember Slackware is what you make of it.

Has anyone here used emerde? I couldn't go to the emerde webpage listed above, but this worked: http://freaknet.org/alpt/Emerde/

BTW, to you french speaking folks, doesn't "emerde" sound kinda... funny/funky?

It does. Sounds like "Eh... S..t"

Well, this user wants source thrown at him. In my opinion when you have free software and can program a little bit the source is part of the user interface. Then the issue is how complex is this user interface (including the source, the dependency graph and the build scripts). I'm getting obsessed with the idea, but my holy grail is that the original source tree be usable relatively simply as is and that anything on top of that beyond a basic packaging to bootstrap the OS and build environment is an extraneous artifact sweeping complexity that got away from us under the rug.

OOh, do you use Windows? I can't seem to get out of the Microsoft Shop development environment to make my money and do. I can't say my experience makes the program installation anything to envy, particularly with software originating on Unix. So I have tora, Strawberry Perl, emacs, firefox, cygwin and a couple other stray things on my work computer. First, Windows is a second class citizen for FOSS stuff (except firefox), so you're lucky if things work right at all. Second these programs have been compiled by at least three different versions of gcc. Fine, if I never want to hack on any of it, who cares. But when you come to that point, there's a bump to get over not present in Linux or the BSDs. First, installing ming32 isn't really pleasant, certainly not as easy as with a package manager. Then since you have a mix of compilers and libraries that used them, once you pick a version of Ming to compile something with, to keep running the stuff compiled with an older ming or the cygwin compiler, you've got to play PATH tricks or be sure all DLLs are bundled in the .exe's directory. So you have this monstrous long PATH in windows to get things pointed right and have to mess with it when you change what you're working on (kind of like if you've ever had to mess with LD_LIBRARY_PATH). Then I found with versions of Oracle, that used Perl, I had to set PERLLIB every time I ran the version of perl I wanted (as opposed to the one oracle bundled and needed) and had to run perl with its full path specified cause I had three different perls floating around in various places. I've just never gotten to the point of looking at bugs because it's too much hassle getting a proper build environment when there's no concept of a system compiler and no order or convention ready for you. You have to create your own order (not my strong point).

Even if you're not compiling things, the Windows approach is a sweep complexity under the rug approach even worse than the most complex Linux distributions. They get you installing whatever you want by a combination of bundling all dependencies in the same folder as the .exe and by having every version of any dll anything's ever used installed in so called side by side directories under the WINDOWS directory. Then don't get me started on their whole world view split between the Raymond Chen/C/C++/COM camp and the MSDN magazine/.NET camp. Well, except to point out the annoyance of using cryptography to enforce exact version matching between .NET assemblies. Boy what a headache that is, for a developer at least. If you consider bundling all dependencies anew for every program, you should consider the ATL security bug from a few years ago. Because the bug was in a C++ template function, not only did having every system free of it mean replacing every single ATL dll (it didn't at all cause there's hardly anything in the ATL dll, it being all template code), but every single .exe and dll compiled against that version of the ATL. This will never happen. The only thing saving people is that the ATL function at fault isn't one that's all that heavily used. I point this out because it analogous to the situation of every program being bundled with its dependencies. When I object to that approach people tell me I have too much disk space, but that's not the serious problem with it. There are tradeoffs between relying on a common core and being independent by copying the same stuff everywhere.

No, if you're going to use Windows as an example, realize whatever good user experience people are getting is coming because a) the projects that do target Windows properly have one or more people putting a lot of good effort into it (think Eli Zaretskii of emacs or the guy who maintains strawberry Perl for FOSS projects and megalithic corporations elsewhere) and b) they're don't care at all how their system is structured beyond the most outward layer of the UI and they don't care to ever hack on anything.

The average desktop user doesn't want that. You don't really except programming skills from the average desktop user, do you?

Occasionally I do. For whatever purpose I use what gets the job done. I'm not part of the "avoid MS at all cost" movement.

This is wishful thinking. Most well-known FOSS products like Mozilla Firefox, Thunderbird, Seamonkey, OpenOffice, LibreOffice, VLC, XBMC, GNUcash etc. are mostly used on Windows and their developers know that. That's why they are easy to install there and hard to install on most Linux distributions. Because even the FOSS application developers think: "Yeah, these 2 percent users know how to help themself."

Firefox: static Binaries available
Thunderbird: static Binaries available
Seamonkey: static Binaries available
OpenOffice: RPMs and DEBs available
LibreOffice: RPMs and DEBs available, they even have binaries for PowerPC Macs
VLC: Instructions how to get binaries for your specific distro on their site
XBMC: Instructions how to get binaries for your specific distro on their site
GNUcash, I wouldn't consider this widely used on Windows: Instructions how to get binaries for your specific distro on their site

Seems that reality does not really support your claims.

I already mentioned it as exemplary: Download, untar, run.

"RPMs and DEBs available" is exactly the issue, that needs to be solved. Nobody needs RPMs and DEBs outside of the scope of his distribution maintainer.

And that is the worst. It says: "Go get your binaries from someone else!" And if you unlucky, these builds are years old.

http://sourceforge.net/projects/gnuc...table)/2.4.13/ shows different numbers.

Of course it is mostly used on Windows. And it's a PITA to build on Linux. Which is exactly the problem.

Maybe I don't understand your problem. Actually it is the same to install those on most distributions like any user would do it on an Android or iOS device, go to the package manager/app store, search for it, press on the install button. Those Android/iOS devices are nowadays far more widespread that desktop computers, so consumers are already used to this approach.
Most consumers don't care at all about new versions (actually many of them are annoyed by applications that constantly want to update to a newer version, I am looking at you, Adobe), in my environment I have never seen a Windows user stating "I want to have that latest Firefox to test these new features!", mostly they are annoyed by change in their habits. Those people use computers as appliance, they don't care about the OS or the version numbers as long as they can get the applications they want (in the form of "I need a browser and a mediaplayer, maybe an office suite") and they want to have that easy. You can't have it easier than with the repository/app store approach. Those people that always want the latest version are not the typical customers and usually the ones knowledgeable enough how to get things working. Hell, they even jailbreak their phones to get newer OS versions.

What really is holding back Linux is not the way how software is installed, but the unavailability of programs like Photoshop, Dreamweaver (hm, again looking at Adobe) and AAA games.

Well I'm only interested in programming users or users who at least aim to learn a little shell scripting and like to tinker. The mythical normal user, I don't care about, except in the theoretical sense that if more of the mainstream turn to GNU/Linux (in the traditional sense, not in the Android sense) maybe I have some greater chance of making the jump from "Windows C++/C#/Perl developer" to "Unix C/C++/Perl/Python" programmer. But a doubling of Linux desktop users takes us from, what, 1 or 2% to 3 or 4%, right? So though I wish the Ubuntu and Gnome type people well, I consider my real stake in their success modest.


These are the large projects, only one of which I've used on Windows, only two of which I use at all (I didn't know Gnucash even ran on Windows -- that's cool), so I can't judge how well they work. I guess it depends on what kind of user we're talking about. At work our experience is more with development tools and it's an impoverished experience compared to Linux or BSD. The worst is the lack of the concept of a default system compiler and set of good universally available interpreters for scripting (unless you like DOS batch, PowerShell, or VBScript). But also little single developer projects like xerces-c matter to us greatly. We've found them a little tricky on Windows, where you're pretty much on your own, in a way I don't think is at all true for GNU/Linux. There may be large projects that purposely put lots of effort into the mass of users on Windows, but there are lots of other projects, particularly GNU projects, that don't give a damn about Windows or supported it in the past thinking it strategic then but no longer put much effort there, figuring it's no longer so strategic, better not to improve the Windows experience.

Perhaps I'm talking past you here cause you're talking about Linux winning large chunks of market share and getting average users while I have trouble taking that perspective since it's not something I care much about (besides, there are still a lot of technical users to win too). Well, the nice thing is we can have distros or whole OSes that target one or the other of our interests. If you get your ideal system, I can read with pleasure in h-online or whereever has good stories (where is that -- every FOSS slanted news site I see failed to notice Slackware's 20th, which makes me think I should stop wasting my time with them) that Linux gains market share and maybe have to know less about Windows. And if my ideal happens and plan 9 becomes something you can browse the web and write C++ programs in, then maybe you can try the live iso sometime and see what you think.