7 ms·

> Unfortunately he has so far only confirmed my belief that adding a package manager to Haiku just made things more complicated. You keep saying this. I do not

> Unfortunately he has so far only confirmed my belief that adding a package manager to Haiku just made things more complicated. You keep saying this. I do not think it means what you think it means. Package managers add a certain kind of complexity to parts of the system that, without it, would indeed be "simpler." But it is an extremely powerful lever that allows removing far, far more complexity than it adds, especially when it comes to porting software. We were very thoughtful about this tradeoff and tried very hard to get it right. Let me ask you this, then: You have repeatedly made this claim. How much have you actually used Haiku, both before and then after the package manager? Because the entire point of the package manager was to pull the complexity away from the users and to us (the developers and maintainers), where we can manage it and automate it away, which is what we have done. If you as a user are seeing some issue, we would greatly like to know about it so we can solve it. > Sure, he recommends some behind-the-scenes magic that can make it a little better, but that's never going to be as good as just being simple in the first place. If it were truly about simplicity, don't you think Apple would have done it already? Or some other company -- that is, being simpler means spending less time and money; and any company that could save money and turn more or the same profit without losing customers would do it in a heartbeat. > That's my problem with "magic", it only appears to work the way you expect until your usecase falls outside of the expected, then the illusion is destroyed. You are using ""magic"" in scare-quotes. Why? You do know this is all code, written by us, and which can be modified by us, or someone else, right? There is not some file called "package_manager.cpp" which was written by someone in a basement 30 years ago that is incomprehensible to human eyes. These are well-thought-out systems that are designed to fit in with the rest of the system in a coherent way. It is also the case that "we optimized for the most usual usecases" is how 99% of software is written. So why are you singling out package managers, or at least our package manager, as a problem here? I also note it sounds like you are going a lot from theory (i.e. "I read the package manager works this way") and not practice ("I used the package manager and found X".) Is that right? At least probono seems more than happy with Haiku and its model: [15:52:55] <nepugia_q> if you are serious about wanting to make a better linux desktop linux distro sign me up :P (have been trying to bootstrap a distro for some time now, with much less gnu tools than we have now (and putting / on a tmpfs and so)) [16:02:58] <probono> nepugia_q now that i have found Haiku i think we should invest here

AnIdiotOnTheNet 7y ago
> Package managers add a certain kind of complexity to parts of the system that, without it, would indeed be "simpler." But it is an extremely powerful lever that allows removing far, far more complexity than it adds, especially when it comes to porting software. We were very thoughtful about this tradeoff and tried very hard to get it right. I disagree, so do others[0], but there's no need to rehash this argument[1]. > If it were truly about simplicity, don't you think Apple would have done it already? Apple did. Twice. > You are using ""magic"" in scare-quotes. Why? Because I have come to distrust software that pretends work one way when it really is doing something different. In Haiku, this means presenting files to the user as though there are in one place when they're really in another, with the results that trying to manipulate them leads to errors that require you to peel back the abstraction, the "magic", to understand. > it is also the case that "we optimized for the most usual usecases" is how 99% of software is written. The most usual usecases for who? Haiku devs I imagine. And you know what? That's perfectly fair since you're the ones doing all the work and I'm just here griping. But that doesn't change the fact that I don't agree with your choices. > So why are you singling out package managers Because I'd be hard-pressed to think of something that has brought more complexity for less benefit than package managers. I remember a time when it was common and simple to carry applications around on floppy disks and just copy them to a new computer and they'd work. Package managers, even Haiku's, don't allow this because they "optimize for the 99% usecase", or rather, the 99% of the developers' use cases. > At least probono seems more than happy with Haiku and its model: Good for him, but I'm still not convinced. But it's ok. Really. Calm down. I'm just an old curmudgeonly bastard anyway, you don't need to win me over. [0] https://www.reddit.com/r/haikuOS/comments/7659fa/where_is_haiku_r1/ https://www.reddit.com/r/haikuOS/comments/7659fa/where_is_ha... [1] https://news.ycombinator.com/item?id=17441773 https://news.ycombinator.com/item?id=17441773
- waddlesplash 7y ago
  > I disagree, so do others[0] The comments agreeing with your opinion there have very few upvotes; mine have much more. Not that this has any bearing on the technical merits or demerits of the actual positions; the best solution is not necessarily the most popular one. I do note that most of the users who complained about the package manager at the time it was merged have since changed their tune after we polished it off; and the users on the linked Reddit thread are probably just wondering why the package manager had to be added at all, since it was the main cause of the release being delayed. > Apple did. Twice. Okay. So why are you unsatisfied with macOS, and see the need to build your own system, then? > In Haiku, this means presenting files to the user as though there are in one place when they're really in another Huh? So you are saying you do not like the feature of Windows Explorer that you can look inside .zips? Or the feature of most Linux desktops that you can mount ISOs or other disk image files and modify them without, you know, actually having them on physical partitions? Because the Haiku package manager is no different than either of these in terms of "showing the user something that 'isn't there'." > with the results that trying to manipulate them leads to errors that require you to peel back the abstraction, the "magic", to understand. The files are on a volume that is (mounted as) read-only. You will get equivalent errors from trying to modify read-only volumes on Linux, macOS, Windows, or any other OS. So what is really "magical" about this? There is no "abstraction" here, the files really are on a read-only volume. > The most usual usecases for who? Haiku devs I imagine. And users. There are only a dozen or two developers; there are hundreds (maybe thousands? nobody has done real counts) of users. > But that doesn't change the fact that I don't agree with your choices. Again, you are disagreeing from a theoretical standpoint here, not a practical one, of "I used this system and it is not viable for X, Y, Z reasons", only "this seems like magic to me and I don't like it." > Because I'd be hard-pressed to think of something that has brought more complexity for less benefit than package managers. Correction: Linux package managers. Haiku is one of the first major examples of a dependency-solving package manager that does not follow the Linux philosophy on a large number of points. I really do believe that the major problems you cite about the Linux package managers are design flaws in the Linux philosophy, not package managers themselves, and that Haiku has sidestepped nearly all of them. > Package managers, even Haiku's, don't allow this because they "optimize for the 99% usecase", or rather, the 99% of the developers' use cases. This just shows you have not used (or at least read the documentation on) Haiku's package manager, because it does allow this, though the feature is not exposed to the GUI because it is, as noted before, very rarely used (if ever?). You can mount a package file from anywhere, to anywhere, with the `mount` command as with any other disk image. HaikuPorter uses this very functionality to create chroots, in fact. > or rather, the 99% of the developers' use cases. Once again you are implying that Haiku is somehow an elitist system that only the developers have any say in. This is just not true, and I don't know why you continue to imply it. > I'm just an old curmudgeonly bastard anyway, you don't need to win me over. If you want to be opposed to package managers "just because," then no, I don't. But if you are going to state your opposition to them on technical grounds that Haiku's package manager is not subject to, then yes, I am going to dispute your claims.

AnIdiotOnTheNet 7y ago

> Package managers add a certain kind of complexity to parts of the system that, without it, would indeed be "simpler." But it is an extremely powerful lever that allows removing far, far more complexity than it adds, especially when it comes to porting software. We were very thoughtful about this tradeoff and tried very hard to get it right. I disagree, so do others[0], but there's no need to rehash this argument[1]. > If it were truly about simplicity, don't you think Apple would have done it already? Apple did. Twice. > You are using ""magic"" in scare-quotes. Why? Because I have come to distrust software that pretends work one way when it really is doing something different. In Haiku, this means presenting files to the user as though there are in one place when they're really in another, with the results that trying to manipulate them leads to errors that require you to peel back the abstraction, the "magic", to understand. > it is also the case that "we optimized for the most usual usecases" is how 99% of software is written. The most usual usecases for who? Haiku devs I imagine. And you know what? That's perfectly fair since you're the ones doing all the work and I'm just here griping. But that doesn't change the fact that I don't agree with your choices. > So why are you singling out package managers Because I'd be hard-pressed to think of something that has brought more complexity for less benefit than package managers. I remember a time when it was common and simple to carry applications around on floppy disks and just copy them to a new computer and they'd work. Package managers, even Haiku's, don't allow this because they "optimize for the 99% usecase", or rather, the 99% of the developers' use cases. > At least probono seems more than happy with Haiku and its model: Good for him, but I'm still not convinced. But it's ok. Really. Calm down. I'm just an old curmudgeonly bastard anyway, you don't need to win me over. [0] https://www.reddit.com/r/haikuOS/comments/7659fa/where_is_haiku_r1/ https://www.reddit.com/r/haikuOS/comments/7659fa/where_is_ha... [1] https://news.ycombinator.com/item?id=17441773 https://news.ycombinator.com/item?id=17441773

waddlesplash 7y ago
> I disagree, so do others[0] The comments agreeing with your opinion there have very few upvotes; mine have much more. Not that this has any bearing on the technical merits or demerits of the actual positions; the best solution is not necessarily the most popular one. I do note that most of the users who complained about the package manager at the time it was merged have since changed their tune after we polished it off; and the users on the linked Reddit thread are probably just wondering why the package manager had to be added at all, since it was the main cause of the release being delayed. > Apple did. Twice. Okay. So why are you unsatisfied with macOS, and see the need to build your own system, then? > In Haiku, this means presenting files to the user as though there are in one place when they're really in another Huh? So you are saying you do not like the feature of Windows Explorer that you can look inside .zips? Or the feature of most Linux desktops that you can mount ISOs or other disk image files and modify them without, you know, actually having them on physical partitions? Because the Haiku package manager is no different than either of these in terms of "showing the user something that 'isn't there'." > with the results that trying to manipulate them leads to errors that require you to peel back the abstraction, the "magic", to understand. The files are on a volume that is (mounted as) read-only. You will get equivalent errors from trying to modify read-only volumes on Linux, macOS, Windows, or any other OS. So what is really "magical" about this? There is no "abstraction" here, the files really are on a read-only volume. > The most usual usecases for who? Haiku devs I imagine. And users. There are only a dozen or two developers; there are hundreds (maybe thousands? nobody has done real counts) of users. > But that doesn't change the fact that I don't agree with your choices. Again, you are disagreeing from a theoretical standpoint here, not a practical one, of "I used this system and it is not viable for X, Y, Z reasons", only "this seems like magic to me and I don't like it." > Because I'd be hard-pressed to think of something that has brought more complexity for less benefit than package managers. Correction: Linux package managers. Haiku is one of the first major examples of a dependency-solving package manager that does not follow the Linux philosophy on a large number of points. I really do believe that the major problems you cite about the Linux package managers are design flaws in the Linux philosophy, not package managers themselves, and that Haiku has sidestepped nearly all of them. > Package managers, even Haiku's, don't allow this because they "optimize for the 99% usecase", or rather, the 99% of the developers' use cases. This just shows you have not used (or at least read the documentation on) Haiku's package manager, because it does allow this, though the feature is not exposed to the GUI because it is, as noted before, very rarely used (if ever?). You can mount a package file from anywhere, to anywhere, with the `mount` command as with any other disk image. HaikuPorter uses this very functionality to create chroots, in fact. > or rather, the 99% of the developers' use cases. Once again you are implying that Haiku is somehow an elitist system that only the developers have any say in. This is just not true, and I don't know why you continue to imply it. > I'm just an old curmudgeonly bastard anyway, you don't need to win me over. If you want to be opposed to package managers "just because," then no, I don't. But if you are going to state your opposition to them on technical grounds that Haiku's package manager is not subject to, then yes, I am going to dispute your claims.