4 ms·

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

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

AnIdiotOnTheNet 7y ago
> "magic" Magic is illusion. It's things appearing to work in a way that they don't actually work, and as such the illusion collapses when you attempt to do something not accounted for by the magician. Case in point: Haiku applications appear to be files, but if you try to move them then you get told you can't modify a read only file system. Even if you did manage it it sounds like they wouldn't work because you didn't really move the application, because it isn't really there and is part of a different file (hpkg) somewhere else that you should have moved instead. The only way to fix these inconsistencies is to employ even more magic to hide the way things actually work. That's magic. > 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. I have other criticisms of Haiku, but we seem to be stuck on this one so I haven't brought them up. Not that it matters, because as mentioned I'm just someone on the sidelines pointing out things I personally don't like while you and other Haiku developers are actually doing the work. I have a particular hatred for package managers, it's true, and it's because they only exist to manage dependencies which is something I don't think should have to be managed at all, and they do so by restriction. > 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?) Consider that both of these things are highly subjective, and who's choosing them? If it is developers, then, well, it's kind of a feedback loop isn't it? Keep going that way and if you're not careful you become Gnome. > 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 Why do you insist on making this appeals to the majority all the time? The end of that logic train is "everyone should just use Chromebooks". The fact that you're even bothering to work on Haiku suggests minority opinions should matter doesn't it? Besides, as I keep saying, I don't really care what the "majority" thinks. > 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. As I said, ideally /dev wouldn't exist. I assume Haiku has it because it wants to be more UNIX compatible. If I made my own system based on the Linux kernel I'd almost certainly have to expose it somewhere too simply because there's no other way to interact with devices in Linux. > 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. I can see how that could have been misconveyed, but that is what I meant. The "system" partition is the officially blessed one where applications are "installed" into the system. > 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). Fair enough, but why does it need to have applications installed on the same partition? You keep saying that this isn't a technical limitation, which I guess is true so long as one is somehow able to properly bless the appropriate partitions. Of course, right now that would mean recompiling Haiku if I wanted to run something off a thumb drive. > Which is a decision that is, as I noted already, open to change. There is no technical reason it has not been done. If what you're saying is true, then no, it's just a cultural one. That's almost worse. Linux doesn't need to do things the way it does either, but culturally it is impossible to do something else at this point.

AnIdiotOnTheNet 7y ago

> "magic" Magic is illusion. It's things appearing to work in a way that they don't actually work, and as such the illusion collapses when you attempt to do something not accounted for by the magician. Case in point: Haiku applications appear to be files, but if you try to move them then you get told you can't modify a read only file system. Even if you did manage it it sounds like they wouldn't work because you didn't really move the application, because it isn't really there and is part of a different file (hpkg) somewhere else that you should have moved instead. The only way to fix these inconsistencies is to employ even more magic to hide the way things actually work. That's magic. > 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. I have other criticisms of Haiku, but we seem to be stuck on this one so I haven't brought them up. Not that it matters, because as mentioned I'm just someone on the sidelines pointing out things I personally don't like while you and other Haiku developers are actually doing the work. I have a particular hatred for package managers, it's true, and it's because they only exist to manage dependencies which is something I don't think should have to be managed at all, and they do so by restriction. > 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?) Consider that both of these things are highly subjective, and who's choosing them? If it is developers, then, well, it's kind of a feedback loop isn't it? Keep going that way and if you're not careful you become Gnome. > 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 Why do you insist on making this appeals to the majority all the time? The end of that logic train is "everyone should just use Chromebooks". The fact that you're even bothering to work on Haiku suggests minority opinions should matter doesn't it? Besides, as I keep saying, I don't really care what the "majority" thinks. > 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. As I said, ideally /dev wouldn't exist. I assume Haiku has it because it wants to be more UNIX compatible. If I made my own system based on the Linux kernel I'd almost certainly have to expose it somewhere too simply because there's no other way to interact with devices in Linux. > 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. I can see how that could have been misconveyed, but that is what I meant. The "system" partition is the officially blessed one where applications are "installed" into the system. > 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). Fair enough, but why does it need to have applications installed on the same partition? You keep saying that this isn't a technical limitation, which I guess is true so long as one is somehow able to properly bless the appropriate partitions. Of course, right now that would mean recompiling Haiku if I wanted to run something off a thumb drive. > Which is a decision that is, as I noted already, open to change. There is no technical reason it has not been done. If what you're saying is true, then no, it's just a cultural one. That's almost worse. Linux doesn't need to do things the way it does either, but culturally it is impossible to do something else at this point.