[DrCatbox]

But what is the alternative to a non-distributions based gnu linux operating system?

How do you manage the 1000 packages and their libraries and dependencies? Many of them have separate runtimes which may or may not depend on the other packages runtime. How would you design an application sandbox to cover them all?

What you're saying basically is that linux is failed. At least for me, since I cant see another way to distribute and manage the massive amount of packages that sit on gnu.org.

I agree with you, and It is my opinion that the one who solves these problem is in for a lot of business-opportunities.

[muuh-gnu]

> But what is the alternative to a non-distributions based gnu linux operating system?

A small core set of libraries that change _very_ slowly and arent intentionally obsoleted every few months. Think of Windows like slow, stable and supported for a decade. Distribution of apps decoupled from the distribution of the base. Never make an app update trigger a lib update.

> How do you manage the 1000 packages and their libraries and dependencies?

You dont do that at all. Developers to that themselves like they do on Windows and OSX. Every dev packages his own app and puts it either into the App store or distributes it himself. You manage only the libs and dont allow them to change fast or in an uncoordinated, chaotic way.

> What you're saying basically is that linux is failed.

From the point of a normal user, yes. For a normal user, it is not an option. Everybody I personally know who tried it, went back. The main reason for most of them was the insanity of application management. (And lack of hardware drivers and games, but thats not Linux' fault.)

> since I cant see another way to distribute and manage the massive amount of packages that sit on gnu.org.

Decouple libs and apps. Dont change APIs and lib versions every few months. Make the base a very reliable and slow moving target. Dont force anybody to change everything every few damn months.

> It is my opinion that the one who solves these problem is in for a lot of business-opportunities.

The problem is already solved, at least under Windows and OSX. Thats why Windows and OSX get all the desktop business and Linux gets none.

[dvogel]

> A small core set of libraries that change _very_ slowly and arent intentionally obsoleted every few months. Think of Windows like slow, stable and supported for a decade. Distribution of apps decoupled from the distribution of the base. Never make an app update trigger a lib update.

This is the idea of the linux standard base. The concept was developed over a decade ago and it has failed to show real fruit.

> You dont do that at all. Developers to that themselves like they do on Windows and OSX. Every dev packages his own app and puts it either into the App store or distributes it himself. You manage only the libs and dont allow them to change fast or in an uncoordinated, chaotic way.

You can already do this with the package management systems. For example, each game in the humble indie bundle installs into it's own /opt directory, with it's own private copies of it's dependencies. It uses the package management system to hook into desktop menu updates, etc. As a user, it's been a nightmare for me. Half of the games don't run at all and I'm at a loss for how to fix them or get replacement libraries.

[maxerickson]

I was always surprised that no one made something like "The Linux Binary Platform 2003" and then kept it up to date, maybe releasing another one later.

At the very least, developers used to Windows would understand the dynamics of it (which is probably a good idea if attracting commercial development is a goal).

I would say it is quite a bit less ambitious than something like the linux standard base.

[flomo]

It's been proposed at various times in various ways. It's largely a competitive issue - the for-profit mechanism boils down to selling "certified" enterprise configurations, so there's little intrest in making the platform even more commodified than it already is.

[sandGorgon]

0-install (http://0install.net/) or even better - Nix packaging system (http://nixos.org/nix/ - they claim to be a purely functional package manager)

[nona]

Damn straight! I don't understand why so few people know about Nix.

I'm hoping Nix(OS) will take off eventually. I try to play with it from time to time, but I haven't made the investment yet to really contribute.

[sandGorgon]

maybe if someone would build a tool that pulls from Ubuntu repository and recreates an equivalent nix package.

come to think of it, there is nothing in aptitude that prevents this kind of an approach (including the unique hash paths). It will get you to 75% of Nix functionality, which IMHO is good enough.

I dont think Redhat.or Ubuntu will want to do that though. Their business model revolves around the walles garden.

[andrewflnr]

Dang... I'm going to go download the NixOS live image, now.

[zmmz]

Is there a linux equivalent of PC-BSD[1]?:

_Programs under PC-BSD are completely self-contained and self-installing, in a graphical format. A PBI file also ships with all the files and libraries necessary for the installed program to function, eliminating much of the hardship of dealing with broken dependencies and system incompatibilities. _

[1]:http://www.pcbsd.org/index.php?option=com_zoo&view=item&...

[mgkimsal]

but but but....

"you'd have duplication of files!" or "you'd have to update multiple libraries when there's a security patch!"

I didn't know about pcbsd, but I've espoused similar ideas to my linux friends years ago, and was generally met with the one of the two objections listed above. I think they're both bad arguments, but it's what I encountered the most.

[icebraining]

The problem isn't that you have to update multiple libraries - it's that you have to rely on each application developer to release an update when there's a patch for one of its libraries. That simply won't happen in many cases.

[mgkimsal]

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library.

Given that all this discussion largely revolves around open source projects anyway, if a developer didn't update for a new security patch in a library, someone would likely step up to the plate if it was a commonly used app. If it's a niche/minor app, and there's, say, a new version of libssl, if the author isn't making updates, there's no guarantee the app will work with an updated version of an upgraded shared library anyway.

[icebraining]

for static compilation, true. if required libraries were bundled with an app, you could replace that one in that location specific to that app and be done, assuming that the app didn't need any extra work done to it to support the new library.

But it'd still be up to the developer to update the library, no? Otherwise, how is that better than the current situation?

If it's a niche/minor app, and there's, say, a new version of libssl, if the author isn't making updates, there's no guarantee the app will work with an updated version of an upgraded shared library anyway.

But you don't have to upgrade the version of the library to release security updates: the Security team of Debian backports all security fixes to the library versions in Stable even if the upstream didn't, in order to prevent such breakage.

[DennisP]

The library developer updates the library, and if the app doesn't need changes to work with the new library version, he doesn't have to do anything. You could even automate finding all copies of the library and updating them...and keep prior versions around if something breaks.

To avoid relying on app developers at all, put apps in sandboxes where it appears that the libraries are where they've always been.