Live data from Hacker News

Maintainers Matter: The case against upstream packaging

kmkeen.com

91–96 of 96 posts

Re: Maintainers Matter: The case against upstream packaging

#91

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 th…

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

Re: Maintainers Matter: The case against upstream packaging

#92
post #61
post #6

Enough of this. People have the right to install last version of software easily without having to upgrade the whole server at once. ISV have the right to package their own software. If MongoDB is a commodity I can gladly stick to the distro version. If I'm developing something of more cutting edge I want and will install the latest version from the ISV repo.

Who said you have to upgrade a whole machine when updating a package? Literally every package manager worth its salt allows you to upgrade a single package. And you can usually specify what version you want too. Yes, ISVs have the right o package their software. But as someone who is both a maintainer of a free software project and packages software for a distribution, I can tell you that I definitely do _not_ want t…

> Who said you have to upgrade a whole machine when updating a package? Literally every package manager worth its salt allows you to upgrade a single package. And you can usually specify what version you want too.

Only by playing musical chairs with the package names to avoid collisions.

And that in turn complicates dependencies.

Re: Maintainers Matter: The case against upstream packaging

#93

Earlier quoted context omitted.

Which is exactly why I've given up on desktop Unix. With Windows, instead of having to wait for the maintainers to declare a package worthy of their distribution, I can just run the vendor's installer, without any fuss or hassle. FreeBSD, IMO, gets packaging the most correct with separating user packages from the core distribution, but there are still times when they'll have an old version as well. Relying on a singl…

It's about trade-offs. There's no magic bullet (surprise!). For example, some folks hate the Windows way because it has drawbacks like a different installation look/feel/process for each application, there's no automatic updates (unless the application has it built-in, which most don't), there's no automatic dependencies (so each app installer has to bundle its own versions of things, which also don't auto-update), t…

I still recall Microsoft finding some bug in their visual-c++ set of dlls. Problem was that just about nay software shipped with their own bundle of those dlls.

So All MS could do was to release a scanner to look for faulty versions, and beg people to pester ISVs about getting updates.

Re: Maintainers Matter: The case against upstream packaging

#94
post #10

Earlier quoted context omitted.

This type of attitude completely ignores regular desktop users who may one day want to use Linux over Windows.

A regular desktop user does not want bleeding-edge software; he will do just fine with last year's VLC. (A notable exception being the web browser.) The priority for a regular desktop user is a nicely integrated system, and that is something that ISVs cannot deliver because they don't know what to integrate with.

Except for the security stuff, i think many would be quite happy with last years Firefox, Chrome or even IE.

Re: Maintainers Matter: The case against upstream packaging

#95

Unless I'm misunderstanding, I think Chef has been doing this for years with omnibus packages. The reason we did this is that we had to support RHEL5/6 and old Solaris and AIX distros. We struggled for several years (and I personally struggled for at least a year) with supporting RHEL5 and it simply failed. That distro came with ruby-1.8.5 and upgrading it to even 1.8.7 was a major PITA. The ruby-1.9.2 in RHEL6 was a…

I maintain that the best of both worlds is a scheme like Nix or Gobolinux. It allows multiple versions of libs to exist, without having each program come packed with half a distro.
Post reply on HN