3 ms·

I am running on linux desktop for already 5 years together with 50 friends, peers etc. It does not quite seem write to compare 90 cent mobile applications, whi

I am running on linux desktop for already 5 years together with 50 friends, peers etc. It does not quite seem write to compare 90 cent mobile applications, which are 'mostly' few bunch of screens interfaced to a service otherwise given by a web site or simple 80s area arcade games, to packages in a linux distro. the author is totally making a terrible mistake here. mobile apps lack in size, complexity and who said they are great? they are mostly consumables which perish in few days or months (I exclude some ). Ubuntu is already trying to be more flexible with software center and applications, however open source is not single walled garden which can adhere to tight monotonous architectures found in mobile. In an linux distro the apps are diverse, and programmed in multitude ways by all possible programming languages (from python to lisp to C) and environments. That is reality and life, and what must be done must be done by being aware of that fact. and No, no one can force the broad, diverse open source world to a tight control a la Apple.

moonchrome 15y ago
>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.
- icebraining 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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.

moonchrome 15y ago

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

icebraining 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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.