4 ms·

> Conveniently you left off the important part: the thing I'm trying to do is a thing that appears to be possible with the presented metaphor Again, it is tech

> Conveniently you left off the important part: the thing I'm trying to do is a thing that appears to be possible with the presented metaphor Again, it is technically possible, we just did not put it in the GUI. So you are correct here. > so therefore should be simple, but since the metaphor is illusion it is not simple. I once again dispute your claim that the "metaphor is illusion" for all the aforementioned reasons... > Consider that such things exist because despite every OS having a dependency manager to "solve" the problem, it is still less of a headache to just bundle dependencies! Every OS? No, only Linux does. (I don't think the Windows and Mac App Stores count as "dependency managing" because, well, they don't check dependencies at all.) Obviously Haiku does not stop programmers from bundling their dependencies, they are still perfectly free to do so. But developers don't make applications for Haiku themselves for the most part (yet.)

AnIdiotOnTheNet 7y ago
> I once again dispute your claim that the "metaphor is illusion" for all the aforementioned reasons... The metaphor is that the application is a file. If you look at /system/Applications/ that's what you see, right? Is the application a file? No, the file is a part of the hpkg, itself part of a dependency chain of hpkgs that are the application. > Every OS? No, only Linux does. Windows has a package manager too believe it or not, but it mostly just applies to Microsoft's own junk, .NET stuff, and C runtimes. I wouldn't be surprised if MacOS had one too, but I also wouldn't be surprised if it didn't since it got Application Bundles right the first time when they inherited it from NeXT. > Obviously Haiku does not stop programmers from bundling their dependencies, they are still perfectly free to do so. Nothing stops Linux developers from doing it either, but culture forces mean it doesn't happen enough to rely on.
- waddlesplash 7y ago
  > If you look at /system/Applications/ that's what you see, right? Is the application a file? No, the file is a part of the hpkg As I said in my previous comment, that really is a file. So how is this an illusion?
  - AnIdiotOnTheNet 7y ago
    The illusion is that that file is the application. Correct me if I'm wrong, because I'm working off of screenshots here, but the entries in /system/Applications are not presented as shortcuts, nor are they strictly menu entries, they're presented as a single file. But the application is not a single file.
    - waddlesplash 7y ago
      The application is whatever the developer made it to be. The majority of applications in `/system/apps` either (1) self-contained (this is the case for the ones in that directory plainly, e.g. Vision) or (2) are a folder (e.g. `/system/apps/BePDF`.) In either case it should be pretty clear to the user what to copy (the single file, or the whole directory) in the case they really want to do that. The only things that put stuff outside of `apps` are, uh, non-applications (e.g. CLI tools with a command in `bin` and data in, well, `data`, libraries with headers in `develop` for GCC to find, etc.) Which the user should not know or care about. Applications with binaries in `/system/apps` and data elsewhere are rare. Most ported applications with no headers or the like get put into `/system/apps` along with all of the libraries they ship and the like. (Of course Qt apps will need the Qt package, etc.; but native apps at least can just get copied out of /system/apps and will still work.)
      - AnIdiotOnTheNet 7y ago
        > The application is whatever the developer made it to be. The majority of applications in `/system/apps` either (1) self-contained (this is the case for the ones in that directory plainly, e.g. Vision) or (2) are a folder (e.g. `/system/apps/BePDF`.) In either case it should be pretty clear to the user what to copy (the single file, or the whole directory) in the case they really want to do that. Alright, so that's a result of me misinterpreting what I was seeing. Dependency problem still considered legit. > The only things that put stuff outside of `apps` are, uh, non-applications (e.g. CLI tools with a command in `bin` and data in, well, `data`, libraries with headers in `develop` for GCC to find, etc.) Which the user should not know or care about. This is another of those things I disagree with. A commandline environment should be just another application. Like, a "UNIX" or "GNU" environment would just be an application that opens a terminal interface to a self-contained little world with the common expected commandline tools. Of course, without any form of application sandboxing or namespaces in Haiku that isn't really possible. I just really don't like the idea of global state that isn't part of the base system. It's an especially bad idea with build environments. There's a reason people put build environments in docker containers. > Of course Qt apps will need the Qt package, etc.; So here's another thing I don't get. One of the big problems with the Linux Desktop that we can both agree on is how everything is so disjointed and fragmented right? Haiku has a native UI, yet you encourage straight up porting of applications using other toolkits anyway. I get that an OS needs applications because people have shit to do, but why not just make them bundle QT with the application? At least then Haiku users would never have to worry about the dependency at all, and you wouldn't have needed to build a package manager to manage it.

AnIdiotOnTheNet 7y ago

> I once again dispute your claim that the "metaphor is illusion" for all the aforementioned reasons... The metaphor is that the application is a file. If you look at /system/Applications/ that's what you see, right? Is the application a file? No, the file is a part of the hpkg, itself part of a dependency chain of hpkgs that are the application. > Every OS? No, only Linux does. Windows has a package manager too believe it or not, but it mostly just applies to Microsoft's own junk, .NET stuff, and C runtimes. I wouldn't be surprised if MacOS had one too, but I also wouldn't be surprised if it didn't since it got Application Bundles right the first time when they inherited it from NeXT. > Obviously Haiku does not stop programmers from bundling their dependencies, they are still perfectly free to do so. Nothing stops Linux developers from doing it either, but culture forces mean it doesn't happen enough to rely on.

waddlesplash 7y ago
> If you look at /system/Applications/ that's what you see, right? Is the application a file? No, the file is a part of the hpkg As I said in my previous comment, that really is a file. So how is this an illusion?
- AnIdiotOnTheNet 7y ago
  The illusion is that that file is the application. Correct me if I'm wrong, because I'm working off of screenshots here, but the entries in /system/Applications are not presented as shortcuts, nor are they strictly menu entries, they're presented as a single file. But the application is not a single file.
  - waddlesplash 7y ago
    The application is whatever the developer made it to be. The majority of applications in `/system/apps` either (1) self-contained (this is the case for the ones in that directory plainly, e.g. Vision) or (2) are a folder (e.g. `/system/apps/BePDF`.) In either case it should be pretty clear to the user what to copy (the single file, or the whole directory) in the case they really want to do that. The only things that put stuff outside of `apps` are, uh, non-applications (e.g. CLI tools with a command in `bin` and data in, well, `data`, libraries with headers in `develop` for GCC to find, etc.) Which the user should not know or care about. Applications with binaries in `/system/apps` and data elsewhere are rare. Most ported applications with no headers or the like get put into `/system/apps` along with all of the libraries they ship and the like. (Of course Qt apps will need the Qt package, etc.; but native apps at least can just get copied out of /system/apps and will still work.)
    - AnIdiotOnTheNet 7y ago
      > The application is whatever the developer made it to be. The majority of applications in `/system/apps` either (1) self-contained (this is the case for the ones in that directory plainly, e.g. Vision) or (2) are a folder (e.g. `/system/apps/BePDF`.) In either case it should be pretty clear to the user what to copy (the single file, or the whole directory) in the case they really want to do that. Alright, so that's a result of me misinterpreting what I was seeing. Dependency problem still considered legit. > The only things that put stuff outside of `apps` are, uh, non-applications (e.g. CLI tools with a command in `bin` and data in, well, `data`, libraries with headers in `develop` for GCC to find, etc.) Which the user should not know or care about. This is another of those things I disagree with. A commandline environment should be just another application. Like, a "UNIX" or "GNU" environment would just be an application that opens a terminal interface to a self-contained little world with the common expected commandline tools. Of course, without any form of application sandboxing or namespaces in Haiku that isn't really possible. I just really don't like the idea of global state that isn't part of the base system. It's an especially bad idea with build environments. There's a reason people put build environments in docker containers. > Of course Qt apps will need the Qt package, etc.; So here's another thing I don't get. One of the big problems with the Linux Desktop that we can both agree on is how everything is so disjointed and fragmented right? Haiku has a native UI, yet you encourage straight up porting of applications using other toolkits anyway. I get that an OS needs applications because people have shit to do, but why not just make them bundle QT with the application? At least then Haiku users would never have to worry about the dependency at all, and you wouldn't have needed to build a package manager to manage it.