Comment by Aqueous | Hacker News Reader

Comment by Aqueous | Hacker News Reader

Parent Full thread

What you think is easy is actually not easy. Any time you've added one, two, three more steps to a problem after clicking the link in the browser you've already lost. Adding repositories? Already too late. Touching the command line? Sorry, as much as we love it, for most users it's already too late. Going into Aptitude or Synaptic and pasting in the repository URL? Yep. Too late.

This is all compounded by the fact that there is no app bundle. Mac OS X has the bundle and a terrific way to install it: Drag and drop it into the Applications folder, just like we did in the days of the Mac Classic and MacPaint. It hasn't changed. (Well, it did for a while, but thankfully they went back.)

If you say, "Well, that means you end up installing 5 different versions of the same library on the same system" - Who cares? Disk space isn't a priority any more, and from a developer standpoint it makes a lot more sense to target a dependency whose version number I know, instead of a dependency whose version only the package maintainers know for sure. I don't want to be forced to target v1.3 of a library if it's only been tested (by me) on v1.2. It makes for much better application stability for the developer to be in control of dependencies and not these package maintainers.

I want to ship a self-contained bundle of awesomeness, not a dysfunctional shard among ten thousand other shards.

Some of the bloat could be dealt with by the file system. If you download a library you already have, then simply discard it - and make do with a reference.

What I'd like to see, is the possibility of having multiple versions of software and libraries residing on the OS with ease.

I think these problems are surmountable.

Maybe the experience is different on other systems, but on Fedora with KDE there already is no friction to installing random stuff. If I want to install, say, Google Chrome, which is not in the normal repositories, all I have to do is download the package and open it. A nice GUI program then takes care of the rest for me automatically; the main differences from installing a program on Windows is that it then updates automatically and I have to enter my password.

So really, there is less friction than on OS X--I don't have to drag anything anywhere! In fact, on Firefox, I just download the package and it figures out to open it with the right program automatically. And then it just works.

Of course, if a program is in the repositories it's even easier, but that's a different story...

> Adding repositories? Already too late. Touching the command line?

Nope. As simple as clicking a link with special URL scheme, like `apt+hXXp://archive.canonical.com?package=acroread?dist=feisty?section=commercial`

> This is all compounded by the fact that there is no app bundle.

I'm all for the bundles (which single-app repositories, actually, are!), but I want them to be non-monolithic (i.e. contain multiple separate packages).

I don't care about disk space — if I'm that constrainted with disk space that's probably another story that'll probably never happen to most ordinary users, having terabytes of storage. But I certainly care about bugs, and if libXYZ 1.2 has a critical one, I want my system to be free of that version ASAP.

And I don't care that you've never tested your awesome app with 1.3 — it's better to be possibly unstable than certainly unstable or, far worse, vulnerable.

What makes package maintainers uniquely qualified to patch dependencies and upgrade them? Either we say Canonical or Red Hat hires the best possible people to watch over their package repositories or we say that a qualified application developer could do just as well. Either way we end up having to trust somebody.

Both package maintainers and developers have an interest make sure their programs don't introduce vulnerabilities into the system. Therefore if there's a serious problem with one of their dependencies vulnerability patching will happen either way.

The distribution maintainers should be in charge of maintaining a core set of low-level dependencies that are needed by many applications. Beyond that they should leave the dependency management to the application developers. Seriously. That would free up so many millions of man-hours of work for say, Canonical, that they could actually make the core system usable to the average user.

"And I don't care that you've never tested your awesome app with 1.3 — it's better to be possibly unstable than certainly unstable or, far worse, vulnerable." Not all library bugs affect all programs though. If you change a library and break things, then the user usually has to wait for the maintainers to fix it, even if the programs would not have exposed the vulnerability. I am thinking of something like a program that uses libPNG to load included images that might break because libPNG has been changed because malicious images could cause a buffer overflow.

This is all compounded by the fact that there is no app bundle.

A "collection" type for installing multiple packages transparently would be nice, but I have to point out that nothing prevents you from doing the exact same thing that you do on Mac OS X, which is to distribute the .so libraries in the same package as the application, or even compile it statically.

Reply on news.ycombinator.com