6 ms·

> 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

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

doktrin 14y ago
> 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.
- pifflesnort 14y ago
  > 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.
abbot2 14y ago
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.
- pifflesnort 14y ago
  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.
derleth 14y ago
> 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.)
- pifflesnort 14y ago
  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 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.
  - derleth 14y ago
    > 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?
    - pifflesnort 14y ago
      > 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).

doktrin 14y ago

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

pifflesnort 14y ago
> 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.

abbot2 14y ago

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.

pifflesnort 14y ago
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.

derleth 14y ago

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

pifflesnort 14y ago
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 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.
- derleth 14y ago
  > 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?
  - pifflesnort 14y ago
    > 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).