6 ms·

> Your strawman user just needs email, a webbrowser, etc. That's all perfectly well served by a Chromebook. Maybe it is in theory. In practice it turns out not

> Your strawman user just needs email, a webbrowser, etc. That's all perfectly well served by a Chromebook. Maybe it is in theory. In practice it turns out not to be; Microsoft Office or LibreOffice do exponentially more and faster than Google Docs, online image editing is really not on par with desktop editors either free or open source, conference calling is still mostly Skype or Zoom that have much better apps than websites, etc. Or maybe they need tighter integration than the web provides. My point is just that I have rarely come across users that really, truly could get by with a web browser, and only a web browser. I don't know why you claim that my theoretical user is a "strawman." It's most of the people I know that use computers, and survey shows that it's indeed most of the people who use computers in general. > Yeah, see, this is not-getting-it. Your comment was extremely vague, and I specifically asked what you meant, so it's not surprising I got it wrong... > It isn't about booting in to BASIC, it's about recognizing that the Computer is a tool to make the user's life better, and part of that role is making sense and guiding the user towards leveraging it better. Of course I agree with this. Haiku has some phrases very, very similar to this in our FAQ, user guide, and interface guidelines (https://www.haiku-os.org/docs/HIG/index.xml https://www.haiku-os.org/docs/HIG/index.xml). > There is an abrupt incongruity in the metaphor for how applications work. They appear to be files in some location (/system/Applications?) but are actually not. The user sees that /system/Applications/MyHaikuApp is a file and thinks "oh, I can just treat that as a file", but then discovers it isn't true. They were lied to. It's an illusion. But they are files mounted in that location. You can treat them as a file: copy them to another location, get info about them, search them, etc. You cannot modify them in that location; but are users really that unfamiliar with the concept of "read-only files / folders"? Can we really not trust them to understand that? We decided that we could, so that's what we did, instead of hiding all this behind more layers of abstractions. We aren't "lying" to them by showing them those files, it's just the same as if they plugged in a volume and chose to mount it read-only. > No disagreement here, but consider your solution to me wanting to use hpkgs from a different partition. Yes, and as stated many times above, your use-case is in the minority (i.e., the long tail) ... for now. When we get around to better enterprise support, then it will be less so (i.e. run packages off of network drives), but that is not a current priority at all. But as also already stated, we would be more than happy to accept a patch that added this.

AnIdiotOnTheNet 7y ago
> But they are files mounted in that location. You can treat them as a file: copy them to another location, get info about them, search them, etc. And if I copy that file out of /system/Applications, and put it on a fresh Haiku install somewhere else and try to run it, what happens? Granted it might actually work, but not if it depended on any other hpkgs not in base Haiku or things that were in its hpkg. If applications actually were just files (or even folders), then this would work as expected. > Yes, and as stated many times above, your use-case is in the minority And therefore irrelevant, yes, I get it. My point is it shouldn't matter that my usecase is in the minority, because my path towards such simple functionality [0], functionality suggested by the --unfortunately illusory-- metaphor presented to the user, shouldn't require me to break out a compiler. Instead it is complicated, because a complicated system was put in place to manage dependencies, a problem so desperately in need of solving that Electron, which bundles an entire web browser with every application, is popular and widely used. [0] DOS, the original MacOS, RiscOS, NeXT Step, the new MacOS, etc. all had this working.
- waddlesplash 7y ago
  > Granted it might actually work, but not if it depended on any other hpkgs not in base Haiku or things that were in its hpkg. If applications actually were just files (or even folders), then this would work as expected. But it would also mean the LibreOffice package would be 300-400MB instead of 100MB; etc. etc. We chose the dependency-solving model precisely because we care to save (consecutively) terabytes of data transfer, disk space, etc. in exchange for a moderate amount of added complexity. Re-packaging applications is not so difficult for the users who really need that. Most seem not to. > And therefore irrelevant, yes, I get it. Two comments ago, you agreed that use-cases in the long-tail were rightfully not optimized for or prioritized in the default install. Nowhere did I say (and I indeed said the opposite) that this meant they were "irrelevant." Do you now disagree with this? > My point is it shouldn't matter that my usecase is in the minority, because my path towards such simple functionality [0] So you are saying that all "simple" usecases, in the "minority" or not, should be implemented? I think you might be surprised at just how many there are. Then how we prioritize all of those? So I don't see why any use-case, simple or not, should get any priority besides the number of users that want or need it multiplied by how crucial the activity is for them. Especially given how starved for time we are at present. > a problem so desperately in need of solving that Electron, which bundles an entire web browser with every application, is popular and widely used. Considering that Qt has facilities to bundle applications together into a single binary, as do most other cross-platform toolkits, I don't think this is the reason most people chose Electron (especially seeing as most Electron apps install quite a lot more than a single binary.)

AnIdiotOnTheNet 7y ago

> But they are files mounted in that location. You can treat them as a file: copy them to another location, get info about them, search them, etc. And if I copy that file out of /system/Applications, and put it on a fresh Haiku install somewhere else and try to run it, what happens? Granted it might actually work, but not if it depended on any other hpkgs not in base Haiku or things that were in its hpkg. If applications actually were just files (or even folders), then this would work as expected. > Yes, and as stated many times above, your use-case is in the minority And therefore irrelevant, yes, I get it. My point is it shouldn't matter that my usecase is in the minority, because my path towards such simple functionality [0], functionality suggested by the --unfortunately illusory-- metaphor presented to the user, shouldn't require me to break out a compiler. Instead it is complicated, because a complicated system was put in place to manage dependencies, a problem so desperately in need of solving that Electron, which bundles an entire web browser with every application, is popular and widely used. [0] DOS, the original MacOS, RiscOS, NeXT Step, the new MacOS, etc. all had this working.

waddlesplash 7y ago
> Granted it might actually work, but not if it depended on any other hpkgs not in base Haiku or things that were in its hpkg. If applications actually were just files (or even folders), then this would work as expected. But it would also mean the LibreOffice package would be 300-400MB instead of 100MB; etc. etc. We chose the dependency-solving model precisely because we care to save (consecutively) terabytes of data transfer, disk space, etc. in exchange for a moderate amount of added complexity. Re-packaging applications is not so difficult for the users who really need that. Most seem not to. > And therefore irrelevant, yes, I get it. Two comments ago, you agreed that use-cases in the long-tail were rightfully not optimized for or prioritized in the default install. Nowhere did I say (and I indeed said the opposite) that this meant they were "irrelevant." Do you now disagree with this? > My point is it shouldn't matter that my usecase is in the minority, because my path towards such simple functionality [0] So you are saying that all "simple" usecases, in the "minority" or not, should be implemented? I think you might be surprised at just how many there are. Then how we prioritize all of those? So I don't see why any use-case, simple or not, should get any priority besides the number of users that want or need it multiplied by how crucial the activity is for them. Especially given how starved for time we are at present. > a problem so desperately in need of solving that Electron, which bundles an entire web browser with every application, is popular and widely used. Considering that Qt has facilities to bundle applications together into a single binary, as do most other cross-platform toolkits, I don't think this is the reason most people chose Electron (especially seeing as most Electron apps install quite a lot more than a single binary.)