Hacker News Reader

Comment by pifflesnort | Hacker News Reader

> It's possible I'm missing something fundamental, here, in which case please help me out. What is your ideal-world vision of how an OS should handle installing & managing binaries & dependencies?

Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day.

This doesn't work for software build/distributed via the UNIX model, but that's the whole point -- if you don't use the UNIX approach to distributing end-user software, you don't create a problem that requires a package manager to solve.

View on HN

> Drag (anywhere) to install. Drag to the trash remove. Add an optional App Store UI to purchase/download/update applications and call it a day.

So, that's obviously the approach Apple's taken, and it has numerous strengths. "Installing" & removing .app files is quite simple, but that's of course not the whole story. Both application support files as well as (IIRC) cache files linger around the OS until removed manually. This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps. It's worth noting that these 3rd party apps basically do what package managers do, except only at the uninstall stage.

More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries. While in a somewhat ideal world it's possible to envision a scenario where all necessary binaries for a given OS are neatly packaged in a preferred format, that seems unrealistic. If I'm still, in 2013, installing really standard tools with a Linux-style package manager on OSX, it's safe to say there's no way I could expect all my requisite applications to be available for a nascent OS with a fraction of its userbase like Haiku.

Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files). A package manager is a ultimately a tool of convenience, it's simply more convenient when dealing with a more classical *nix path / dependency model.

> This is typically NBD (well, no huge deal), but it deserves mention. Managing remnant traces of .app files requires either manually navigating the OS and deleting files, or using 3rd party apps.

Apple has moved to solve this problem in iOS (and the Mac App Store) by maintaining per-app metadata directories. I think this is ideal, and it's not necessary to attach it to the app store model.

> More importantly, when I use OSX, I most certainly am also variously using brew & make to install various pieces of software not packaged as .app binaries.

Yes, UNIX software.

> Lastly, even assuming all binaries that could possibly be executed on a given system are packaged as .app file (equivalents), I frankly wouldn't mind having a package manager available to install (copy), manage, organize & remove my binaries (including support files).

That's what the file system is on a system that manages applications sanely.

There is one good thing in UNIX shared library + package management model: security updates. You don't have to depend on some weird ISV to update his own copy of buggy openssl code in his own "app" in the Unix world. Good for sysadmins. Inconvenient for users. Doh.

The solution is to provide sufficiently broad set of tightly integrated base system libraries; there are few, if any, duplicate dependencies across most applications.

To use OpenSSL as an example, on OS X applications all make use of SecureTransport and CommonCrypto. This brings other advantages, such as automatic integration with keychain-managed certificates and certificate authorities.

> Drag (anywhere) to install. Drag to the trash remove.

Either not have shared libraries at all, and lose when someone finds a bug in something and you have to reinstall everything to get the fix in everything, or have shared libraries that you have to manage by hand because your system lacks dependency tracking. (Your libraries probably aren't versioned, either, so welcome to 1990s-era DLL Hell.)

A peer commentator already mentioned this. I already explained:

The solution is to provide sufficiently broad set of tightly integrated base system libraries; there are few, if any, duplicate dependencies across most applications.

-- https://news.ycombinator.com/item?id=5567754

The advantage is that you have broad, comprehensive, consistent libraries that integrate with the base system, rather than a mash-up of inconsistent library interfaces and shell scripts -- for example, see how Linux distributions manage OpenSSL and certificate authorities, versus how OS X and Windows both integrate their crypto libraries into the system certificate stores and UIs.

> The solution is to provide sufficiently broad set of tightly integrated base system libraries

So... when you find a bug in one, the only thing to do is an OS upgrade?

And what about new APIs that come along? Will third-party libraries exist at all, or will users have to wait for an OS upgrade to have applications that can take advantage of them?

> So... when you find a bug in one, the only thing to do is an OS upgrade?

Yes. Which, ideally, is cheap and easy to do.

> And what about new APIs that come along? Will third-party libraries exist at all, or will users have to wait for an OS upgrade to have applications that can take advantage of them?

We can see how this works today. Third-party libraries exist, application authors benefit from being able to version them at-will (and not be tied to the same version everybody else uses), and if anything grows sufficiently popular/necessary/duplicated, the functionality can be integrated into the OS (an occurrence of which there are numerous examples).

It might be true on a OS that lacks a good file notification API. Haiku on the other hand has a very good notification system, so the package manager will step in and take care of unpacking, mounting, managing and download dependencies. Same for uninstalling.

Here is a good description from the developers: http://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summary...

Guess what you don't need if you don't make a UNIX software mess?

Answer: unpacking, mounting, managing and downloading dependencies.

Package management will make OS upgrades easier. Dependencies as opposed to static linking will allow the CPU to run and cache used code better instead of reading and discarding the same code from different parts of memory. Compression will make the handling less IO bound and a bit more CPU intensive, but disks are slow and CPU's are faaaast! If you think it will be slow and complicated, I think you will be in for a pleasant surprise later on.

> Package management will make OS upgrades easier.

You don't need a UNIX package manager for this. See also: every modern OS, ever.

> Dependencies as opposed to static linking will allow the CPU to run and cache used code better instead of reading and discarding the same code from different parts of memory.

You achieve this by having comprehensive base system libraries. See also Android, Mac OS X, iOS.

> Compression will make the handling less IO bound and a bit more CPU intensive, but disks are slow and CPU's are faaaast!

This doesn't need to exist in the package manager. See also HFS+ compression. Bonus: it works without hauling in a huge packaging system.

> If you think it will be slow and complicated, I think you will be in for a pleasant surprise later on.

No, I'll be in for dealing with OSS dependency hell (except that now I can be assured that I'll never use Haiku, because they're actively working to throw away what made the Mac and BeOS designs of that era attractive to begin with, and what they spent 10 years trying to achieve).

It's actually embarrassing that Haiku came so far, only to lose sight of the BeOS R5 target, actively destroying what made BeOS interesting compared to Linux -- especially when modern examples of how to do it right (Android, iOS, Mac OS X) are right in front of them.

This is what happens when Linux kernel engineers wind up in charge of a consumer OS project.

Reply on news.ycombinator.com