4 ms·

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

> 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
> Again, you are disagreeing from a theoretical standpoint here, not a practical one Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. I can do this with AppImage, MacOS App Bundles, and quite a lot of Windows programs and I can do it today, not some "maybe we'll implement it" future. Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies. Also, you want to talk practicality? In part 4 Probono had to install Haiku to a larger disk because he was outgrowing the one it was installed on. Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage? There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree. I really don't understand why you seem so intent on convincing me that my opinion is incorrect. This is a real limitation of your system that actually exists, the complexity behind it is real. You're of the opinion that those are not significant, and I am of the opinion that they are. Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. Frankly, they remind me far too much of Linux Desktop evangelists. > You can mount a package file from anywhere, to anywhere, with the `mount` command as with any other disk image. Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications.
- waddlesplash 7y ago
  > Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. You can already do all of that up until the "without having..."; and as I said in the article, someone could write a script for that in a matter of an hour; and of course a GUI in ... as long as it took to bikeshed ;) There is no technical limitation here. We have not implemented a GUI for it because, as I said, few users seem to want or need it. > Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. Why do you keep calling this "magic"? Packages in Haiku are file systems. This is in fact how AppImage also works, which you seem to like. Are you complaining about how AppImage is internally implemented? > My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies. No, it would not. It would indeed require magic on Linux because the tools that understand dependencies, where to get them, and interface with the user (e.g. apt) are separate from the tools that manage the actually installed packages (e.g. dpkg.) No such distinction exists on Haiku. In fact there is a screenshot in the linked article where probono dragging a package into the system packages directory, and the system automatically asked him if he wanted to install its dependencies. All that is missing from your usecase is a way to get these from a local folder instead of downloading them as is done right now. It would in no way be some "magic hack" that violates abstractions, good design, etc. like it would on Linux. > Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage? I already explained this: you can do it manually already by using the "mount" command. Support for it does not exist at the GUI level, and very few users requested it, so we (the development team, who are not paid to work on this, and have ~1-2 man-months total per month to spend on Haiku between the entire team) did not implement such a feature that less than 1% of people want. But once again, there is no technical barrier here and it is already possible if you don't mind CLIs. > There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree. So far, the "technical restrictions" you have referred to in this comment are actually incorrect, they are simply "there is no GUI" not "this is not possible with the present design." The one you referred to before ("can't modify packages") is also a restriction of AppImages, I believe? So I don't actually know what technical restrictions you are referring to at this point. > I really don't understand why you seem so intent on convincing me that my opinion is incorrect. You are perfectly welcome to dislike packages because you want to use .zips, or some other personal preference or the like. I am, however, intent as I said in the last comment on disagreeing with you when your opinion is "I don't like X because it can't do/does Y", when in fact X can or does not do Y, as is the case with most of your objections to the Haiku package management system thus far. > You're of the opinion that those are not significant, and I am of the opinion that they are. And which one of us has spent 5+ years both working inside said system as a developer, and on said system as a user, and in the community of said system with the other users who use said system on a daily basis, some even as a daily diver? > Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. No. That is not what my "in the minority" has (largely) meant. It has meant that "we did not implement X because few people seem to want/need X and we have very little time in the first place," i.e. if we had more time, we might have implemented X, and if someone sent us a patch that did X we would likely accept it; not "your usecase is not valid." > Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications. Correct. But you can add another hard-coded blessed path to the system with two lines of code and a recompile. We would almost certainly accept a patch that added blessed paths via a configuration file. (Again, this seems to be rarely needed or requested; this does not mean it is not a valid usecase, it means our precious little time will be spent first on more important things. Patches and/or sponsorships wanted.)

AnIdiotOnTheNet 7y ago

> Again, you are disagreeing from a theoretical standpoint here, not a practical one Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. I can do this with AppImage, MacOS App Bundles, and quite a lot of Windows programs and I can do it today, not some "maybe we'll implement it" future. Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies. Also, you want to talk practicality? In part 4 Probono had to install Haiku to a larger disk because he was outgrowing the one it was installed on. Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage? There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree. I really don't understand why you seem so intent on convincing me that my opinion is incorrect. This is a real limitation of your system that actually exists, the complexity behind it is real. You're of the opinion that those are not significant, and I am of the opinion that they are. Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. Frankly, they remind me far too much of Linux Desktop evangelists. > You can mount a package file from anywhere, to anywhere, with the `mount` command as with any other disk image. Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications.

waddlesplash 7y ago
> Call me when I can put an application on a thumbdrive and take it to another system and run it without having to worry about dependencies or being connected to the internet. You can already do all of that up until the "without having..."; and as I said in the article, someone could write a script for that in a matter of an hour; and of course a GUI in ... as long as it took to bikeshed ;) There is no technical limitation here. We have not implemented a GUI for it because, as I said, few users seem to want or need it. > Oh yeah, and there's no magic, they are single files or folders and can be manipulated as such without any special magic from the OS. Why do you keep calling this "magic"? Packages in Haiku are file systems. This is in fact how AppImage also works, which you seem to like. Are you complaining about how AppImage is internally implemented? > My understanding is that even if Haiku was modified to accommodate this kind of thing, it would require magic handling to do so because dependencies. No, it would not. It would indeed require magic on Linux because the tools that understand dependencies, where to get them, and interface with the user (e.g. apt) are separate from the tools that manage the actually installed packages (e.g. dpkg.) No such distinction exists on Haiku. In fact there is a screenshot in the linked article where probono dragging a package into the system packages directory, and the system automatically asked him if he wanted to install its dependencies. All that is missing from your usecase is a way to get these from a local folder instead of downloading them as is done right now. It would in no way be some "magic hack" that violates abstractions, good design, etc. like it would on Linux. > Here's a question: why could't he keep his install where it is and just put new applications on a different partition? Like you can do on a Mac, or on Windows (usually), or with AppImage? I already explained this: you can do it manually already by using the "mount" command. Support for it does not exist at the GUI level, and very few users requested it, so we (the development team, who are not paid to work on this, and have ~1-2 man-months total per month to spend on Haiku between the entire team) did not implement such a feature that less than 1% of people want. But once again, there is no technical barrier here and it is already possible if you don't mind CLIs. > There are practical limitations imposed by hpkg. You think they're reasonable trade-offs, I disagree. So far, the "technical restrictions" you have referred to in this comment are actually incorrect, they are simply "there is no GUI" not "this is not possible with the present design." The one you referred to before ("can't modify packages") is also a restriction of AppImages, I believe? So I don't actually know what technical restrictions you are referring to at this point. > I really don't understand why you seem so intent on convincing me that my opinion is incorrect. You are perfectly welcome to dislike packages because you want to use .zips, or some other personal preference or the like. I am, however, intent as I said in the last comment on disagreeing with you when your opinion is "I don't like X because it can't do/does Y", when in fact X can or does not do Y, as is the case with most of your objections to the Haiku package management system thus far. > You're of the opinion that those are not significant, and I am of the opinion that they are. And which one of us has spent 5+ years both working inside said system as a developer, and on said system as a user, and in the community of said system with the other users who use said system on a daily basis, some even as a daily diver? > Your constant attempts to convince me otherwise, mostly by telling me I'm in the minority, or my usecase is wrong and invalid, are not and never will be well received. No. That is not what my "in the minority" has (largely) meant. It has meant that "we did not implement X because few people seem to want/need X and we have very little time in the first place," i.e. if we had more time, we might have implemented X, and if someone sent us a patch that did X we would likely accept it; not "your usecase is not valid." > Which I can only assume means I must manually mount any dependencies not in a blessed path first before I mount the application that is also not in a blessed path, since the convention is not to package non-base system dependencies with applications. Correct. But you can add another hard-coded blessed path to the system with two lines of code and a recompile. We would almost certainly accept a patch that added blessed paths via a configuration file. (Again, this seems to be rarely needed or requested; this does not mean it is not a valid usecase, it means our precious little time will be spent first on more important things. Patches and/or sponsorships wanted.)