6 ms·

So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken? And Linux's software distribution mechanism is working for end users? > I'm sorry, but

So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken? And Linux's software distribution mechanism is working for end users? > I'm sorry, but I don't think BeOS was ever aimed at someone other than developers. It would be quite surprising if Haiku were aimed at a different public. The involvement of former Apple employees, targeting Macs, the attempted sale to Apple, the single-user OS, the UI riffing off MacOS, the focus on media, the simple UI -- those we're all flukes? It was actually meant to be a difficult to use Linux clone that focused on shipping packaged UNIX software, despite its particularly weak posix compatibility and complete non-standard directory layout? I was hacking on BeOS since DR2. I have friends who worked there. It was contemporary with my career, and I was following Apple's and Be's parallel efforts closely. It was, as far as my knowledge and experience goes, a user-focused operating system ala MacOS. > Maybe you should get some first hand experience and, dare I say, read the manual. If you experience a significantly larger number of disasters than your peers, the problem is most likely not the tooling. Many years ago, I wrote one one of the package managers in wide use today. Then I spent years shipping software for multiple platforms. I think I understand the trade-offs, and implementing package management only made the underlying failure of the Linux package manager model more clear. What kind of ridiculous system requires an army of volunteers to maintain a graph of dependencies in lockstep, making it nearly impossible for 3rd party developers to directly release simple binaries that work across their user's systems. Instead we have to add Chrome package repos to our Ubuntu installations that break across major releases. It's stupid. There are better ways, which are evidenced by the fact that they're working, today, and have been working for some 20 odd years, and are being further defined in the AppStore model. Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone.

rbanffy 13y ago
> So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken? No. I said they solve some problems and don't solve others. > And Linux's software distribution mechanism is working for end users? I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases. > Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone. I solve my problems, you solve yours. Deal with it.
- pifflesnort 13y ago
  > No. I said they solve some problems and don't solve others. Yes, they don't solve the problem of distributing messy UNIX software with complex and unstable dependency graphs, written for systems with anemic base libraries, that install a litter of files all over your system. That's a good thing. In fact, I'd say the world would be a better place if we'd never implemented package managers and instead UNIXes were finally forced to clean up their mess. The real world doesn't work that way, so instead the best we can do is create new systems that don't inherit the mistakes of the old. > I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases. Use cases like, say, trying a new piece of software that hasn't been packaged? Getting updates directly from the vendor? Being able to have their vendor-supplied applications continue to work across major OS releases? Or how about from the vendor perspective, where we have to deal with mistake-prone volunteers packaging up our software, inconsistent and incompatible libraries and an ever-shifting dependency graph. The only reason anything ever works at all is because there are hundreds/thousands of people whose sole contribution is to keep the entire dependency graph afloat. Just how many human hours do you think are spent on software packaging overhead? > I solve my problems, you solve yours. Deal with it. Thanks for elucidating exactly why Linux developed shouldn't be anywhere near the design process for consumer software like an OS.
  - ZenoArrow 13y ago
    You're projecting your view of Linux package management onto Haiku, when the situation with Haiku is going to be pretty different. For starters, let's start with libraries. To use a concrete example, let's say the Cairo vector graphics library. What happens when a program requires Cairo 1.12.14? The library package gets downloaded. What happens when a second program requires Cairo 1.12.13 (i.e. the previous version)? The library gets stored alongside the newer version, so both are available. What happens when a program has forked Cairo, and requires that version? Hopefully the answer is clear. So in this example we have three versions of Cairo. Seems inefficient right? In some ways it is, but efficiencies can emerge when programs do target the same version of Cairo on our system, as the library will already be ready for new programs to use. It's also important to realise in what ways having these three libraries is inefficient. The only real issue here is storage, as we'd probably be looking at three times the storage space for the Cairo functionality. However, as inefficient as this is, it's still more efficient (from a storage point of view) than each application bundling its own libraries, as with installing the libraries separately there's at least a chance of the libraries being shared. There is an alternative, which is to specify library versions that developers should use and bundle these with the system. This has advantages and disadvantages. The advantage is that the functionality available to you is easier to scope out. The disadvantages are that recommended libraries get updated less frequently, so if you wish to use a new version you're either forced to wait or bundle your own library, which brings you back to the inefficiencies you had before. Taking time to reflect, I see now that your issue isn't really with package managers per se, but rather that you dislike the 'rolling release' approach of many open-source projects. It's the shifting target that annoys you, how this gets managed is secondary. Would you say that's a fair appraisal?

rbanffy 13y ago

> So you're saying that Mac OS, Mac OS X, Android, and iOS are all broken? No. I said they solve some problems and don't solve others. > And Linux's software distribution mechanism is working for end users? I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases. > Maybe you should stop being so selfish by trying to force your inexperience and UNIX sysadmin use case on everyone. I solve my problems, you solve yours. Deal with it.

pifflesnort 13y ago
> No. I said they solve some problems and don't solve others. Yes, they don't solve the problem of distributing messy UNIX software with complex and unstable dependency graphs, written for systems with anemic base libraries, that install a litter of files all over your system. That's a good thing. In fact, I'd say the world would be a better place if we'd never implemented package managers and instead UNIXes were finally forced to clean up their mess. The real world doesn't work that way, so instead the best we can do is create new systems that don't inherit the mistakes of the old. > I am yet to meet a non-technical Linux user who has experienced what could be described as "package management disaster". Software management is mostly automated for their use cases. Use cases like, say, trying a new piece of software that hasn't been packaged? Getting updates directly from the vendor? Being able to have their vendor-supplied applications continue to work across major OS releases? Or how about from the vendor perspective, where we have to deal with mistake-prone volunteers packaging up our software, inconsistent and incompatible libraries and an ever-shifting dependency graph. The only reason anything ever works at all is because there are hundreds/thousands of people whose sole contribution is to keep the entire dependency graph afloat. Just how many human hours do you think are spent on software packaging overhead? > I solve my problems, you solve yours. Deal with it. Thanks for elucidating exactly why Linux developed shouldn't be anywhere near the design process for consumer software like an OS.
- ZenoArrow 13y ago
  You're projecting your view of Linux package management onto Haiku, when the situation with Haiku is going to be pretty different. For starters, let's start with libraries. To use a concrete example, let's say the Cairo vector graphics library. What happens when a program requires Cairo 1.12.14? The library package gets downloaded. What happens when a second program requires Cairo 1.12.13 (i.e. the previous version)? The library gets stored alongside the newer version, so both are available. What happens when a program has forked Cairo, and requires that version? Hopefully the answer is clear. So in this example we have three versions of Cairo. Seems inefficient right? In some ways it is, but efficiencies can emerge when programs do target the same version of Cairo on our system, as the library will already be ready for new programs to use. It's also important to realise in what ways having these three libraries is inefficient. The only real issue here is storage, as we'd probably be looking at three times the storage space for the Cairo functionality. However, as inefficient as this is, it's still more efficient (from a storage point of view) than each application bundling its own libraries, as with installing the libraries separately there's at least a chance of the libraries being shared. There is an alternative, which is to specify library versions that developers should use and bundle these with the system. This has advantages and disadvantages. The advantage is that the functionality available to you is easier to scope out. The disadvantages are that recommended libraries get updated less frequently, so if you wish to use a new version you're either forced to wait or bundle your own library, which brings you back to the inefficiencies you had before. Taking time to reflect, I see now that your issue isn't really with package managers per se, but rather that you dislike the 'rolling release' approach of many open-source projects. It's the shifting target that annoys you, how this gets managed is secondary. Would you say that's a fair appraisal?