5 ms·

> 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

by 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).
tqh 14y ago
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_haikus_package_management http://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summary...
- pifflesnort 14y ago
  Guess what you don't need if you don't make a UNIX software mess? Answer: unpacking, mounting, managing and downloading dependencies.
  - tqh 14y ago
    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.
    - pifflesnort 14y ago
      > 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.

by derleth 14y ago

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

tqh 14y ago

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_haikus_package_management http://www.haiku-os.org/blog/mmadia/2012-08-20_brief_summary...

pifflesnort 14y ago
Guess what you don't need if you don't make a UNIX software mess? Answer: unpacking, mounting, managing and downloading dependencies.
- tqh 14y ago
  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.
  - pifflesnort 14y ago
    > 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.