4 ms·

I feel like this article is sort of attacking a straw man. > The promise: Sandboxing makes you immune to bad ISVs. The reality: It protects you from some thin

I feel like this article is sort of attacking a straw man. > The promise: Sandboxing makes you immune to bad ISVs. The reality: It protects you from some things and not others. Well yeah, but the same could be said of maintainers. Maintainers let things through all the time, and sometimes they cause problems (hello, Debian weak keys). The reality is a bit complicated, and it boils down to something boring like: if the maintainers are better than upstream, maintainers are good, and if they are worse than upstream, then they are bad. But that is both tautological and vacuous, so it is not especially useful insight. The real insight is this: there just aren't enough maintainers to go around. Debian has 1500 contributors and 57,000 packages, which is 38x as many packages as people. Now maintainers have a lot of tooling to make that more tractable, and upstream developers have their time split between multiple packages too, and some packages are important enough to get the attention of several maintainers fulltime. But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on? More likely, the maintainers do not even claim to be doing that, because they have not packaged the software at all. I use lots of unpackaged software; until recently nobody was packaging Chromium for example. Java packaging is really unreliable. And so on. Ultimately, Ubuntu Snap exists because there is a lot of unpackaged software, and a lot of software packaged poorly. It would be nice if we could wave a magic wand and get 38x more maintainers, but we cannot.

jsizz 10y ago
> sometimes they cause problems (hello, Debian weak keys). > until recently nobody was packaging Chromium for example. To name one example, SlackBuilds.org has had Chromium since 2010, although admittedly that's not so long ago as the Debian weak key cockup, which was 2006. Maybe your examples could use an upgrade to the latest stable version.
- drewcrawford 10y ago
  Chromium may have been packaged in 2010, but it was released three years before. The Debian weak keys "cockup" may have been created in 2006, but it was discovered two years later. Maintainers had long windows of time to add value. Did they? I don't mean anything personal by it. If I was maintaining 38 packages on my nights and weekends I'd do a bad job too. But examples don't go out of date unless you present some force that takes 30k unmaintainable packages and turns them into 50k maintainable packages. What specific advance in software maintenance do you believe improved the art of software maintenance by an OOM? But if you want to talk recent examples, we could talk about how nobody's packaging Swift.
  - ploxiln 10y ago
    Chromium only became compatible with linux in 2010. https://googleblog.blogspot.com/2009/12/google-chrome-for-holidays-mac-linux.html https://googleblog.blogspot.com/2009/12/google-chrome-for-ho... Arch Linux packaging files have source history going back to then as well. Chromium is also an example of a package that took a long time to appear in other distros, because it's really written with the app mindset. It copies and incompatibly customizes most of its dependencies. No one would consider that a great idea for ongoing maintenance and security patching for a typical project, but of course this is a google product-oriented thing with nearly a thousand well-above-average-skill developers assigned, so it's not a problem for them to manage surprisingly huge volumes of code and changes. Web browsers like Chromium are also a good example of the kind of modern software which doesn't work well with the debian release model, because it's "unsupported and practically broken" in like half a year. That's not true for the "make" utility, or for gimp or inkscape or libreoffice or audacious or countless other useful applications and tools which are not browsers. I really don't like the fact that modern browsers are a crazy-train and there's just no getting off it.
    - digi_owl 10y ago
      Yeah Chromium is a mess. To get and build the source you first have get the special tool set they use from their git repo.
pavanky 10y ago
> until recently nobody was packaging Chromium for example. How recent is "recently" ? Only Fedora and it's downstream distros do not ship Chromium. Everyone else has been packaging it for a few years now.
majewsky 10y ago
> But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on? It looks much worse than it is, because most packages are really boring from a maintainer perspective. For example, KDE releases a hundred or so applications. Some of them are probably very interesting to package, but for most packages, `cmake && make && make install` is just fine (maybe plus a certain KDE integration macro that your packaging tool already carries).
dredmorbius 10y ago
Package maintainers can, and do, fuck up. They also catch things. OpenBSD are particularly good at this, and Debian have a pretty good track record (exceptions noted) as well. The most critical aspect of the package maintainer is that they don't have a horse in the race -- they're not representing the interests of the software developer, but of the users (or at least the OS). It's an additional step for independent review, a fresh set of eyes, and a set which operates outside the disciplinary scope of the developers, at least in theory. As Celine's Second Law states: the truth can only emerge in a non-punishing situation (from Robert Anton Wilson), and that's the situation an independent maintainer has. Yes, shoving square pegs into round holes gets problematic, non-free software doesn't package well, and there may be delays. But independent software packaging done right adds tremendous value. It also avoids huge scope of costs, the annoyance, security, privacy, and surveillance deadweight losses of proprietary, ISV packaging. I remember seeing this in the Microsoft world in the early 2000s, and being simply staggered at how bad the situation was. And yet, it's precisely the same set of dynamics, and inevitable consequences, which are now infesting the mobile world. Android is all but unusable as a consequence, and Apple have announced that virtually all pre-loaded software will be removable from the next generation of iOS. It's the position of at least some Linux distros, most notably Debian (and many derivatives, at least in part) that the interests of the users come first, as expressed specifically in the Debian Social Contract, Debian Free Software Guidelines, and Debian Policy, and which are technically supported through packaging systems, bugtracking, and updates, which are the real secret sauce. That's a lesson the technology community seems not to have learnt. https://www.debian.org/social_contract https://www.debian.org/social_contract

jsizz 10y ago

> sometimes they cause problems (hello, Debian weak keys). > until recently nobody was packaging Chromium for example. To name one example, SlackBuilds.org has had Chromium since 2010, although admittedly that's not so long ago as the Debian weak key cockup, which was 2006. Maybe your examples could use an upgrade to the latest stable version.

drewcrawford 10y ago
Chromium may have been packaged in 2010, but it was released three years before. The Debian weak keys "cockup" may have been created in 2006, but it was discovered two years later. Maintainers had long windows of time to add value. Did they? I don't mean anything personal by it. If I was maintaining 38 packages on my nights and weekends I'd do a bad job too. But examples don't go out of date unless you present some force that takes 30k unmaintainable packages and turns them into 50k maintainable packages. What specific advance in software maintenance do you believe improved the art of software maintenance by an OOM? But if you want to talk recent examples, we could talk about how nobody's packaging Swift.
- ploxiln 10y ago
  Chromium only became compatible with linux in 2010. https://googleblog.blogspot.com/2009/12/google-chrome-for-holidays-mac-linux.html https://googleblog.blogspot.com/2009/12/google-chrome-for-ho... Arch Linux packaging files have source history going back to then as well. Chromium is also an example of a package that took a long time to appear in other distros, because it's really written with the app mindset. It copies and incompatibly customizes most of its dependencies. No one would consider that a great idea for ongoing maintenance and security patching for a typical project, but of course this is a google product-oriented thing with nearly a thousand well-above-average-skill developers assigned, so it's not a problem for them to manage surprisingly huge volumes of code and changes. Web browsers like Chromium are also a good example of the kind of modern software which doesn't work well with the debian release model, because it's "unsupported and practically broken" in like half a year. That's not true for the "make" utility, or for gimp or inkscape or libreoffice or audacious or countless other useful applications and tools which are not browsers. I really don't like the fact that modern browsers are a crazy-train and there's just no getting off it.
  - digi_owl 10y ago
    Yeah Chromium is a mess. To get and build the source you first have get the special tool set they use from their git repo.

pavanky 10y ago

> until recently nobody was packaging Chromium for example. How recent is "recently" ? Only Fedora and it's downstream distros do not ship Chromium. Everyone else has been packaging it for a few years now.

majewsky 10y ago

> But do we really believe 1/38th of a person is judiciously considering how to overrule upstream's decisions, attentively investigating user bug reports, and so on? It looks much worse than it is, because most packages are really boring from a maintainer perspective. For example, KDE releases a hundred or so applications. Some of them are probably very interesting to package, but for most packages, `cmake && make && make install` is just fine (maybe plus a certain KDE integration macro that your packaging tool already carries).

dredmorbius 10y ago

Package maintainers can, and do, fuck up. They also catch things. OpenBSD are particularly good at this, and Debian have a pretty good track record (exceptions noted) as well. The most critical aspect of the package maintainer is that they don't have a horse in the race -- they're not representing the interests of the software developer, but of the users (or at least the OS). It's an additional step for independent review, a fresh set of eyes, and a set which operates outside the disciplinary scope of the developers, at least in theory. As Celine's Second Law states: the truth can only emerge in a non-punishing situation (from Robert Anton Wilson), and that's the situation an independent maintainer has. Yes, shoving square pegs into round holes gets problematic, non-free software doesn't package well, and there may be delays. But independent software packaging done right adds tremendous value. It also avoids huge scope of costs, the annoyance, security, privacy, and surveillance deadweight losses of proprietary, ISV packaging. I remember seeing this in the Microsoft world in the early 2000s, and being simply staggered at how bad the situation was. And yet, it's precisely the same set of dynamics, and inevitable consequences, which are now infesting the mobile world. Android is all but unusable as a consequence, and Apple have announced that virtually all pre-loaded software will be removable from the next generation of iOS. It's the position of at least some Linux distros, most notably Debian (and many derivatives, at least in part) that the interests of the users come first, as expressed specifically in the Debian Social Contract, Debian Free Software Guidelines, and Debian Policy, and which are technically supported through packaging systems, bugtracking, and updates, which are the real secret sauce. That's a lesson the technology community seems not to have learnt. https://www.debian.org/social_contract https://www.debian.org/social_contract