6 ms·

> 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. It's not an ill

> 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. It's not an illusion, though. They really are files on a read-only file-system. The message is entirely correct. AppImages would do the same. > I have other criticisms of Haiku, but we seem to be stuck on this one so I haven't brought them up. Well, I am interested in those, too, of course. And despite how antagonistic this apparently is to you (sorry), I really am taking notes here. > Why do you insist on making this appeals to the majority all the time? Because the general case is the one that should be optimized for first, and other ones come later. > 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. If you are trying to protect software from the developers making it, you are going to have a bad time. > Besides, as I keep saying, I don't really care what the "majority" thinks. That's fine if you are just you. Obviously people creating products have to think about it. > Fair enough, but why does it need to have applications installed on the same partition? Nothing "needs" that, this is just how it is set up; the current default as it were. > Of course, right now that would mean recompiling Haiku if I wanted to run something off a thumb drive. Because there is no GUI, yes. Or you know, like I've said before, the executable bit still exists and you can use it, too. > Linux doesn't need to do things the way it does either, but culturally it is impossible to do something else at this point. Yes, indeed... > If what you're saying is true, then no, it's just a cultural one. That's almost worse. No, it is not. Linux has created in everyone the fear of the culture above all else, to the point where elaborate technical solutions are crafted to cultural problems. Haiku has, and will continue to, change its "culture" when it becomes clear the time has come for that.

AnIdiotOnTheNet 7y ago
> AppImages would do the same. The user is never exposed to the mounted filesystem of an AppImage, which is only mounted while the application is running. Unless I'm mistaken, which is entirely possible, hpkgs don't work like that. The hpkg is mounted and the filesystem is exposed to the user who launches the application through it. With AppImage, no expectation exists that the mounted fs is a real fs because the user never interacts with it. Let me put it another way: Suppose Haiku already had all the changes it would need to use hpkgs in arbitrary locations. So I plug in a thumbdrive containing an application hpkg and all its dependency hpkgs. The hpkgs get mounted, then I launch the application, then I close the application. Now I remove the thumbdrive. What happens? With an AppImage in this scenario, what happens is exactly what you'd expect: nothing. The AppImage fs was mounted at launch, and unmounted at close, and never seen by the user.
- waddlesplash 7y ago
  > The hpkg is mounted and the filesystem is exposed to the user who launches the application through it. > With AppImage, no expectation exists that the mounted fs is a real fs because the user never interacts with it. When is the last time you browsed through /usr or C:\Program Files\ in a file manager? The same is true in Haiku. It's there for the power users; normal users should not need to go into it and poke around. The user should interact with it via the Deskbar, desktop symlinks, etc. Not by browsing /system/. > The hpkgs get mounted, then I launch the application, then I close the application. Now I remove the thumbdrive. What happens? The filesystem the thumbdrive contained gets unmounted, and in the process all child vnodes and file descriptors are closed, and so the packages on the thumbdrive are consequently unmounted also. > With an AppImage in this scenario, what happens is exactly what you'd expect: nothing. The AppImage fs was mounted at launch, and unmounted at close, and never seen by the user. HPKGs would be mounted for as long as possible so that the applications contained could be, say, launched to handle a file. But as I noted above, this should indeed work just fine on Haiku with nearly the same paradigm as AppImages do.
  - AnIdiotOnTheNet 7y ago
    > When is the last time you browsed through /usr or C:\Program Files\ in a file manager? Literally every day. > It's there for the power users; normal users should not need to go into it and poke around. See right here is a red flag for me in terms of culture: I do not consider there to be a difference between "power Users" and "users". This distinction only exists as an excuse for why things have to suck. Why does this thing suck? Oh, it's because normal users won't understand X or only want Y, unlike special snowflake power users. I think users should be treated with some respect instead of condescension. Again, one of my big problems with Linux Desktop culture, and maybe you can see why I've previously painted Haiku with that same brush. You're excusing an incongruity in the metaphor presented by the system and how the system actually works with the Linux Desktop Evangelism approved mantra "well normal users don't care". > The filesystem the thumbdrive contained gets unmounted, and in the process all child vnodes and file descriptors are closed, and so the packages on the thumbdrive are consequently unmounted also. Well that's good, at least it doesn't hang around as a ghost until the user attempts to interact with it and it throws an error. It still seems odd that one would have to perform the extra step of "installing" (mounting) the hpkg before finding the application and running it, which is an advantage of AppImage: you just run it.

AnIdiotOnTheNet 7y ago

> AppImages would do the same. The user is never exposed to the mounted filesystem of an AppImage, which is only mounted while the application is running. Unless I'm mistaken, which is entirely possible, hpkgs don't work like that. The hpkg is mounted and the filesystem is exposed to the user who launches the application through it. With AppImage, no expectation exists that the mounted fs is a real fs because the user never interacts with it. Let me put it another way: Suppose Haiku already had all the changes it would need to use hpkgs in arbitrary locations. So I plug in a thumbdrive containing an application hpkg and all its dependency hpkgs. The hpkgs get mounted, then I launch the application, then I close the application. Now I remove the thumbdrive. What happens? With an AppImage in this scenario, what happens is exactly what you'd expect: nothing. The AppImage fs was mounted at launch, and unmounted at close, and never seen by the user.

waddlesplash 7y ago
> The hpkg is mounted and the filesystem is exposed to the user who launches the application through it. > With AppImage, no expectation exists that the mounted fs is a real fs because the user never interacts with it. When is the last time you browsed through /usr or C:\Program Files\ in a file manager? The same is true in Haiku. It's there for the power users; normal users should not need to go into it and poke around. The user should interact with it via the Deskbar, desktop symlinks, etc. Not by browsing /system/. > The hpkgs get mounted, then I launch the application, then I close the application. Now I remove the thumbdrive. What happens? The filesystem the thumbdrive contained gets unmounted, and in the process all child vnodes and file descriptors are closed, and so the packages on the thumbdrive are consequently unmounted also. > With an AppImage in this scenario, what happens is exactly what you'd expect: nothing. The AppImage fs was mounted at launch, and unmounted at close, and never seen by the user. HPKGs would be mounted for as long as possible so that the applications contained could be, say, launched to handle a file. But as I noted above, this should indeed work just fine on Haiku with nearly the same paradigm as AppImages do.
- AnIdiotOnTheNet 7y ago
  > When is the last time you browsed through /usr or C:\Program Files\ in a file manager? Literally every day. > It's there for the power users; normal users should not need to go into it and poke around. See right here is a red flag for me in terms of culture: I do not consider there to be a difference between "power Users" and "users". This distinction only exists as an excuse for why things have to suck. Why does this thing suck? Oh, it's because normal users won't understand X or only want Y, unlike special snowflake power users. I think users should be treated with some respect instead of condescension. Again, one of my big problems with Linux Desktop culture, and maybe you can see why I've previously painted Haiku with that same brush. You're excusing an incongruity in the metaphor presented by the system and how the system actually works with the Linux Desktop Evangelism approved mantra "well normal users don't care". > The filesystem the thumbdrive contained gets unmounted, and in the process all child vnodes and file descriptors are closed, and so the packages on the thumbdrive are consequently unmounted also. Well that's good, at least it doesn't hang around as a ghost until the user attempts to interact with it and it throws an error. It still seems odd that one would have to perform the extra step of "installing" (mounting) the hpkg before finding the application and running it, which is an advantage of AppImage: you just run it.