[moonchrome]

>they are mostly consumables which perish in few days or months (I exclude some utitities).

This is simply false, there are plenty of complex apps with varying degrees of usefulness but they certanly don't reduce to 80's game clones and few screen apps. And even if it was true it's not a result of anything intrinsic to the app model. Also "tight control a la Apple" indicates that you missed his point.

How many times did you do make and sudo installed shit on your system to get basic app that should for all intents and purposes be walled of in a sandbox ? Even without sudo why should install script have access to my personal files without explicit permissions ? Did you run in to a situation where you wanted to install the latest version of an app for your system but it wasn't in your distro repo so you decided to build it only to find out that your repo GTK+ library was out of date and your options were rebuild all GTK+ packages or update the OS to alpha ? Even I gave up at that point - imagine the average user wanting to get the latest feature advertised on his favorite app site.

I use Linux desktop daily but it can be a hell and you need to know how to wrestle with the system, it's certainly not idiot proof - and it needs to be for mass adoption. But then again "mass adoption" (IMO) shouldn't even be considered a realistic goal, being useful to techies/developers and available on servers is a good objective too.

[diminish]

> This is simply false, there are plenty of complex apps with varying degrees of usefulness but they certanly don't reduce to 80's game clones and few screen apps. And even if it was true it's not a result of anything intrinsic to the app model.

If I am writing "mostly", I mean "mostly" and if you refute "mostly" with "there are plenty of" you are missing even the basic tenure of a sane discussion. Check the top 100 apps in app stores/markets, and you will see how wonderful those sandboxed apps, you and ingo show us as examples of success. They are "mostly" my-web-page-as-an-app-now hype.

You miss Ingo's point, if you don't read his paragraphs, and carefully read that he compares Android/iOS core and apps to 20+ years of Linux kernel /desktop and software from various architectures, programming languages and technologies. He even claims their core is stable missing the point how young they are. The proud iOS core cannot go for more than few devices and the number of deficiencies/issues people had there are also interestingly high.

Finally, and if you really are doing all those compilations to get the latest version of a software, you might consider better considering your options of distro and package manager. Clearly you are doing something wrong there; and if you please mention what you compile on which distro and version Someone may able to understand what you are trying to achieve, and tell you what you should do instead.

[icebraining]

I agree that having to make and sudo install is essentially impossible for a common PC user, but how does the sandboxing have any impact in user adoption?

[barrkel]

State is the big evil in software. Minimize shared state, and many, many problems go away.

Centralized package management with a web of specific versioned dependencies is a huge hairball of state as it is. And when installed applications poke around inside your system, it only takes one or two oversights here and there to mess up this state.

Sandboxing, where feasible, minimizes shared state; usually at the cost of other things, but with modern software and modern resource constraints, our ability to deal with complexity is usually the tightest constraint. Sandboxing reduces the probability that things will break horribly (e.g. installing one app, and finding you need to install a new version of a library, which in turn means you need to reinstall 100+ more apps, which may bring in a new desktop or some other abomination).

[icebraining]

That has nothing to do with sandboxing: it's a matter of distributing the libraries with the package itself, either as .so files or as a big statically compiled binary, and using those instead. Nothing forces the developer to use the distro provided libraries.

And frankly, I think this is one of the things where you can't please everyone; personally, I rather have dependencies and know that a security fix in a library will fix all applications that use it than having to hope each developer releases an updated version, like on Windows.

[barrkel]

That's true to the degree that the implementation of those libraries does not require other things from the rest of the system. If they are just libraries of code, attached to nothing, sure.

But when they need integration with things beyond that? That's when it breaks down. That's when you need interfacing libraries that adapt one version of a library's interface to the next version, and very careful API and ABI design. I see that there's very little reason to take that approach for open source everywhere, but that kind of environment is essential for the stability commercial development needs.

Static libraries aren't the answer. A careful API and ABI interface to the core system, with managed compatibility from release to release, is needed. This is hard work; incredible amounts of effort went into making Windows 95 work as smoothly as it does, and some of the best war stories from Raymond Chen's blog date from this effort.

Things like preserving bugs in the moral equivalent of malloc to accommodate software that used memory after freeing it. This very concept - bug compatibility - is something that I see OSS community in general as being fairly hostile to, thinking that the software with the bug should be fixed, rather than making things work for the user. Of course the buggy software should be fixed; but making things work for the user is more important still.

[bryanlarsen]

Actually, your post is making me optimistic.

On Linux, the 4 most common API layers encountered by an application are:

1) system calls 2) standard (and not-so-standard) libraries 3) X11 4) d-bus

#1 is notoriously stable. Linus often posts quite a vehement response to anybody who proposes breaking #1.

#3 was for a long time, TOO stable, it wasn't taking advantage of new developments in hardware and design. The breakup of XFree86 freed that up.

#4 is relatively stable because it's a cross-distribution partnership. They're designed to be the same across multiple distributions which by necessity makes them stable.

The problem are for Linux is #2. Most standard libraries are actually very stable on the micro level. The problem is the vast area they expose: if a single backwards-incompatible change can break your app, it's a problem if there are a million things that can potentially change.

Windows & OS X applications "solve" this problem by shipping their libraries with their applications.

I think Linux has a potentially even better solution: simply allow multiple versions of applications and libraries to be installed simultaneously, a la rubygems & bundler. You'll get all the disk space savings of shared libraries at the point of initial install, which will slowly erode as users install new apps, upgrade some apps but not others. But who cares? Disk space is cheap, but more importantly, if the user cares he can do something about it, only upgrading applications when the whole application upgrades.

[eli_gottlieb]

Yes, but then we all have to use Plan 9.

[cgoddard]

On any of the modern distros there should be no scenario in which a common user should have to run 'make' directly. Even for distros which don't use precompiled binaries the install process is simpler than that.