4 ms·

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

> 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.
    - waddlesplash 7y ago
      > Dependency problem still considered legit. I'm sorry to say that the dependency problem is really the fault of those applications, and we are really doing our best to support them while not consuming excessive disk space or too high of a maintenance burden. Native applications should ideally depend on Haiku itself and nothing more, and then we would not have this problem, and probably Apple feels the same way about macOS ones. But we can't all live in that world just yet... > 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. Okay... but at least in this case, users don't usually (ever?) use GUIs to copy around binaries of CLIs because Linux has specifically trained them not to. So we could invent a new paradigm here, but a lot of this stuff is unfortunately hard-coded into said CLI tools and it may be prohibitively difficult. > Of course, without any form of application sandboxing or namespaces in Haiku that isn't really possible. Well, there are chroots and su, but that is probably not what you had in mind. > I just really don't like the idea of global state that isn't part of the base system. Well, on Haiku, it is avoidable: never install anything in `/system` besides the base system, and instead install all your packages in ~. This at least is supported already (I don't know if HaikuDepot has an option exposed for it, but pkgman has the -H option which does exactly this.) > It's an especially bad idea with build environments. There's a reason people put build environments in docker containers. Indeed. HaikuPorter builds always run in chroots with only the declared dependent packages available to them. > Haiku has a native UI, yet you encourage straight up porting of applications using other toolkits anyway. Yes, because the manpower to make third party applications does not exist yet. There are about 2 (literally, two) third-party developers who do not also have commit access to Haiku itself. We would very, very much greatly prefer using Haiku-native applications; the ecosystem just does not exist, and until it does we are tolerating (and this is the word other developers would use, too) ported applications to close the gaps. > but why not just make them bundle QT with the application? Because then every Qt application would be 75-100MB larger, rather than having one 50-70MB Qt package and shipping each Qt app on its own? And on a system where a lot of apps are ported Qt ones, this will potentially be a 10x increase in space usage, as most Qt app packages are < 10MB (and the complete image of the base system is itself only 415MB or so, remember, and 60MB of that is the Noto fonts.) Not to mention that when there is a Qt update you then have hundreds of packages to rebuild instead of just one... > At least then Haiku users would never have to worry about the dependency at all Haiku users already do not "worry" about the dependency: They push "install" and the dependencies are installed, and that's that.

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.
  - waddlesplash 7y ago
    > Dependency problem still considered legit. I'm sorry to say that the dependency problem is really the fault of those applications, and we are really doing our best to support them while not consuming excessive disk space or too high of a maintenance burden. Native applications should ideally depend on Haiku itself and nothing more, and then we would not have this problem, and probably Apple feels the same way about macOS ones. But we can't all live in that world just yet... > 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. Okay... but at least in this case, users don't usually (ever?) use GUIs to copy around binaries of CLIs because Linux has specifically trained them not to. So we could invent a new paradigm here, but a lot of this stuff is unfortunately hard-coded into said CLI tools and it may be prohibitively difficult. > Of course, without any form of application sandboxing or namespaces in Haiku that isn't really possible. Well, there are chroots and su, but that is probably not what you had in mind. > I just really don't like the idea of global state that isn't part of the base system. Well, on Haiku, it is avoidable: never install anything in `/system` besides the base system, and instead install all your packages in ~. This at least is supported already (I don't know if HaikuDepot has an option exposed for it, but pkgman has the -H option which does exactly this.) > It's an especially bad idea with build environments. There's a reason people put build environments in docker containers. Indeed. HaikuPorter builds always run in chroots with only the declared dependent packages available to them. > Haiku has a native UI, yet you encourage straight up porting of applications using other toolkits anyway. Yes, because the manpower to make third party applications does not exist yet. There are about 2 (literally, two) third-party developers who do not also have commit access to Haiku itself. We would very, very much greatly prefer using Haiku-native applications; the ecosystem just does not exist, and until it does we are tolerating (and this is the word other developers would use, too) ported applications to close the gaps. > but why not just make them bundle QT with the application? Because then every Qt application would be 75-100MB larger, rather than having one 50-70MB Qt package and shipping each Qt app on its own? And on a system where a lot of apps are ported Qt ones, this will potentially be a 10x increase in space usage, as most Qt app packages are < 10MB (and the complete image of the base system is itself only 415MB or so, remember, and 60MB of that is the Noto fonts.) Not to mention that when there is a Qt update you then have hundreds of packages to rebuild instead of just one... > At least then Haiku users would never have to worry about the dependency at all Haiku users already do not "worry" about the dependency: They push "install" and the dependencies are installed, and that's that.