6 ms·

> It's possible I'm misunderstanding here, but aren't hpkgs mounted in an overlay fashion? That's not how AppImages work. They can be mounted either way. The /

> It's possible I'm misunderstanding here, but aren't hpkgs mounted in an overlay fashion? That's not how AppImages work. They can be mounted either way. The /system/ packagefs mountpoint is a kind of "overlay" in the loose sense, but it does not use the standard "overlayfs" but rather packagefs manages the "overlay" itself for a variety of reasons (both technical and practical.) But I don't know what difference that really makes vs. AppImages. > If the functionality isn't exposed to the user it may as well not exist. Okay, so it "doesn't exist," but it still could be implemented without too much effort. > And if it is as straight forward as you claim (which I doubt), why hasn't it been done? Because, like I already said, we have precious little time and far more important things to work on, and very few people seem to have wanted this. And some of the ones that (at one point) did were third-party application developers who could have written a tool to do it, but they didn't either, so it seems in the end they also found it unnecessary. > You seem to be motivated to shut me the hell up enough that you've probably spent the requisite amount time arguing on the internet about it already. If all you were saying was "I want X feature but you are never going to do that / it is impossible", I am going to spend my time arguing against the "but". Then once it gets down to "I want X feature", I would to convince you to file a ticket or ask about it on the forums to collect feedback so we could actually consider it and prototype something, and eventually implement it if there is enough demand and we have the time. But you seem to have no interest in actually using Haiku probably ever, so spending time implementing a feature that one person currently wanting it may never use does not sound like a good investment to me. > but you can't even determine the order of magnitude of your current user base (is it hundreds or thousands?), We (intentionally) don't collect metrics of how many actually running systems there are; we can only estimate from the number of downloads of the nightly images and package updates. Which are consistent with "hundreds to low thousands." Hopefully our disdain for pervasive user tracking will not incur a demerit in that we do not know certain things trackers would tell us... > I'm saying I don't like the way it is done. That's all. Appealing to your rationale for why you don't do it my way isn't going to convince me otherwise. Again, your disputes are "I don't like the way it is done because X", when in fact X is not true, and that is my dispute. > Holy shit. I have to actually recompile? That's some Linux-grade badness there. Uh. You have to recompile code in order to add features. If someone added support to get this from a configuration file, then you wouldn't. Not sure why you are so surprised. > I don't think blessed paths are a good solution in the first place (see: magic). Next you are going to tell me that /dev and /proc, being "blessed paths" are "magic". If you are not going to say that, what is the actual difference between that and this, that makes these paths "not magic"? > and structure should be entirely up to the user. If you are really saying entirely, without any limits, then you are right, we are going to hit some disagreements. If you do admit some limits (really, any at all), then we may still agree. macOS is an "opinionated" system, and Haiku is too; not nearly as much, that's for sure, but we are not the "wide open west" of Linux.

AnIdiotOnTheNet 7y ago
> They can be mounted either way. The /system/ packagefs mountpoint is a kind of "overlay" in the loose sense, but it does not use the standard "overlayfs" but rather packagefs manages the "overlay" itself for a variety of reasons (both technical and practical.) Right, magic. > But I don't know what difference that really makes vs. AppImages. AppImages don't pretend to be somewhere they're not. The mounting just gives the application a way to see its files. hpkgs are mounted as part of an installation step, AppImages are mounted as part of a launch step. It isn't ideal, but like I said it has to work within the limitations of Linux. > But you seem to have no interest in actually using Haiku probably ever This is true. I have to say, having my only interaction with the community be arguing with you has notably soured me on it, unfair to the project as that obviously is. But more than that, there's just too much magic in it for all the limitations it still has. In the far future when it has VMs, application sandboxing, and reasonable hardware acceleration it will be easier for me to accept the things I don't like about the design, but that's a long way off. A simpler system would appeal to me a lot more and make it easier to sacrifice those other things. > a feature that one person currently wanting it Probono also wants it, he said as much in this very article, and he is an enthusiastic user of Haiku right now. > We (intentionally) don't collect metrics of how many actually running systems there are; I'm not saying you should, I'm just saying you're being a bit presumptuous when you claim to speak for 95% of users, whom you've not only never polled but also can't even measure. Not to mention that such claims sound a lot like the "99% of users just want Chrome" excuses of Linux Desktop evangelists. This is why I keep saying that what you really mean is 95% of Haiku developers, the parts of the community you have frequent contact with. > Again, your disputes are "I don't like the way it is done because X", when in fact X is not true, and that is my dispute. X is true. hpkgs are not simple and employ "magic", they are not bundled with their dependencies, they cannot (today) work from arbitrary locations without jumping through hoops and recompiling. These are true statements. The only disagreement seems to be how much this matters. > Uh. You have to recompile code in order to add features. If someone added support to get this from a configuration file, then you wouldn't. Not sure why you are so surprised. I'm surprised no one thought to make it a configuration option already. It seems like such a simple thing to look at a hardcoded path and say "maybe I shouldn't hardcode this path". > Next you are going to tell me that /dev and /proc, being "blessed paths" are "magic". Yes and no, because you can mount devtmpfs and procfs in arbitrary paths, but also yes because too many developers hardcode their location. I'm going to go with "yes", and in an ideal system they wouldn't even exist as part of the "file" hierarchy, per-se. UNIX baggage, etc. > If you are really saying entirely, without any limits, then you are right, we are going to hit some disagreements. Ideally, yes. I don't see any reason that any kind of file structure need be imposed on the user. Ideally there is no "system" partition, no "/boot" as I understand it to be called in Haiku, there's just whatever volumes exist and whatever files are on them. The system was booted into ram from a single file, its interfaces are not exposed as a file hierarchy. Applications and documents go wherever the user wants them, on permanent media, removable media, network shares, whatever. There's no such thing as having to "install" anything. The system is a file, the applications are files (or folders). Boot a new version off a thumbdrive and all your applications are available because hey, they're just files and folders out there on volumes. Because the world isn't perfect, yeah, it is unlikely to be this perfect. For one, the location of the system file will be subject to the whims of the boot mechanism. But really, that's still a far cry from "all applications must be installed on the same volume as the system or otherwise in a list of blessed paths".

AnIdiotOnTheNet 7y ago

> They can be mounted either way. The /system/ packagefs mountpoint is a kind of "overlay" in the loose sense, but it does not use the standard "overlayfs" but rather packagefs manages the "overlay" itself for a variety of reasons (both technical and practical.) Right, magic. > But I don't know what difference that really makes vs. AppImages. AppImages don't pretend to be somewhere they're not. The mounting just gives the application a way to see its files. hpkgs are mounted as part of an installation step, AppImages are mounted as part of a launch step. It isn't ideal, but like I said it has to work within the limitations of Linux. > But you seem to have no interest in actually using Haiku probably ever This is true. I have to say, having my only interaction with the community be arguing with you has notably soured me on it, unfair to the project as that obviously is. But more than that, there's just too much magic in it for all the limitations it still has. In the far future when it has VMs, application sandboxing, and reasonable hardware acceleration it will be easier for me to accept the things I don't like about the design, but that's a long way off. A simpler system would appeal to me a lot more and make it easier to sacrifice those other things. > a feature that one person currently wanting it Probono also wants it, he said as much in this very article, and he is an enthusiastic user of Haiku right now. > We (intentionally) don't collect metrics of how many actually running systems there are; I'm not saying you should, I'm just saying you're being a bit presumptuous when you claim to speak for 95% of users, whom you've not only never polled but also can't even measure. Not to mention that such claims sound a lot like the "99% of users just want Chrome" excuses of Linux Desktop evangelists. This is why I keep saying that what you really mean is 95% of Haiku developers, the parts of the community you have frequent contact with. > Again, your disputes are "I don't like the way it is done because X", when in fact X is not true, and that is my dispute. X is true. hpkgs are not simple and employ "magic", they are not bundled with their dependencies, they cannot (today) work from arbitrary locations without jumping through hoops and recompiling. These are true statements. The only disagreement seems to be how much this matters. > Uh. You have to recompile code in order to add features. If someone added support to get this from a configuration file, then you wouldn't. Not sure why you are so surprised. I'm surprised no one thought to make it a configuration option already. It seems like such a simple thing to look at a hardcoded path and say "maybe I shouldn't hardcode this path". > Next you are going to tell me that /dev and /proc, being "blessed paths" are "magic". Yes and no, because you can mount devtmpfs and procfs in arbitrary paths, but also yes because too many developers hardcode their location. I'm going to go with "yes", and in an ideal system they wouldn't even exist as part of the "file" hierarchy, per-se. UNIX baggage, etc. > If you are really saying entirely, without any limits, then you are right, we are going to hit some disagreements. Ideally, yes. I don't see any reason that any kind of file structure need be imposed on the user. Ideally there is no "system" partition, no "/boot" as I understand it to be called in Haiku, there's just whatever volumes exist and whatever files are on them. The system was booted into ram from a single file, its interfaces are not exposed as a file hierarchy. Applications and documents go wherever the user wants them, on permanent media, removable media, network shares, whatever. There's no such thing as having to "install" anything. The system is a file, the applications are files (or folders). Boot a new version off a thumbdrive and all your applications are available because hey, they're just files and folders out there on volumes. Because the world isn't perfect, yeah, it is unlikely to be this perfect. For one, the location of the system file will be subject to the whims of the boot mechanism. But really, that's still a far cry from "all applications must be installed on the same volume as the system or otherwise in a list of blessed paths".