> Right, magic.

overlayfs and iso9660 are not magic. So is mounting two ISOs in an overlayfs on Linux magic? Or on macOS? I guess I really do not understand how or why you quantify things "magic" at all.

> AppImages don't pretend to be somewhere they're not.

The entire concept of "filesystem mounts" means data pretends to be somewhere it is not. Haiku has used the concept in a slightly unorthodox way, but it is fully within the bounds of the concept, and we could do the same on Linux without modifying the kernel.

> I have to say, having my only interaction with the community be arguing with you has notably soured me on it

Once again, I am not trying to change your opinions; I am trying to understand and then correct your misinformed understandings of how this all works under the hood. If your objection to Haiku is "I don't want a package manager", point blank, then I can tell you why people like them and why we do, but obviously there is nothing for me to argue with there.

> there's just too much magic in it for all the limitations it still has

I would really, really appreciate it if you could explain to me your understanding of the word "magic", and how it applies so frequently to technology...

> Probono also wants it, he said as much in this very article, and he is an enthusiastic user of Haiku right now.

So then that is one. He has also only used Haiku for a week now. Maybe he'll change his mind; maybe he won't and the feature will get implemented. But either way, the stuff we are focused on right now impacts the whole userbase (system stability, optimizations, porting more apps), and so we are going to keep that as the focus.

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

I speak for and about the users who have spoken up. Perhaps I'm wrong; but if there are people with strong opinions, I would expect them to express them somewhere in some fashion. I haven't seen anyone do so on this topic for some time.

> Not to mention that such claims sound a lot like the "99% of users just want Chrome" excuses of Linux Desktop evangelists.

But are they right? 99% of people who tell me they want to use Haiku more but don't, say "if it had Firefox or Chrome..."

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

The Haiku forums and mailing lists are active enough that concerns and comments very often show up there. We have had more than one major feature or bugfix made because people chimed in there... In fact, one of the features probono noted as missing (word-wise-delete in text editors) was implemented last week as a result of that. We definitely do listen to the community.

> hpkgs are not simple and employ "magic"

What is "magic"?!? All of the major behavior of them is documented at various levels and depends on no "hacks" or undefined behavior.

> they are not bundled with their dependencies

If their dependencies are merely Haiku itself (i.e., as native apps should), they have nothing to be bundled with. If they are non-native apps that use Qt or the like, yes, they are not bundled, because a 100MB Qt package + 5 1MB apps is much smaller than 5x100MB bundled Qt apps, etc. But yes, you are correct here.

> they cannot (today) work from arbitrary locations without jumping through hoops

Yes, there is no GUI yet.

> and recompiling

That is only needed if you want the paths to be "blessed" with the dependency solver. But if you are only using native and not ported apps, you have no need for dependency solving...

> The only disagreement seems to be how much this matters.

And about the nature of "magic", it seems. But indeed we seem to have fewer points of misunderstanding by now..

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

Haiku's philosophy is "sane defaults and minimal configuration where necessary." We have a "pseudo-test" that we generally go through before adding new options to the GUI (1. Did you ever change this setting? 2. Did changing it make you happier?)

We do have the find_paths() API for applications to not hard-code paths, but, you know, somewhere there has to be a hard-coded path for find_paths to return.

> UNIX baggage, etc.

Well, I certainly am not the biggest fan of the "everything is a file" philosophy indeed; but I also think if you took a poll among Haiku users and developers about `/dev/` you would not get a majority concensus to hide it more (it already does not appear in the GUI), and most would either be neutral or opposed to removing it (in favor of handles.) So if you are opposed to even `/dev`, then I think your philosophy and Haiku's are much more irreconcilable than I realized.

> Ideally there is no "system" partition, no "/boot" as I understand it to be called in Haiku

You are misinformed. `/boot` just refers to the partition Haiku is currently booted from. So `/boot/home` is where the normal home directory is (unless one has moved it). So there is no "system partition" segmented from the "data partition" as such, no.

Essentially, `/` on Haiku is not existent in any real location; but is rather the root mount point for filesystems. So `/boot` is the boot partition, I might attach a thumb drive and it will appear as `/waddlesplash thumb` or whatever else its name is, etc. In the GUI, navigating to `/` shows the nominal names of the partitions (with /dev/ and other such dirs hidden, usually.)

> The system is a file

But this is what Haiku does; the system is `haiku.hpkg`, and we just also have those files appear in `/system/, too, because to us hiding them completely would be much more "magical" (or more properly, opaque).

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

Which is a decision that is, as I noted already, open to change. There is no technical reason it has not been done.