3 ms·

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

> 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
> 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. It took years to make the package manager. You honestly believe it was worth it for this? > Well, there are chroots and su, but that is probably not what you had in mind. su definitely isn't. But depending on support for bind mounting, in particular read-only bind mounting, chroots might be. > we are tolerating [...] ported applications to close the gaps. Which is fair. Though personally I'd have just put them in a compatibility environment, like WINE but translating from Linux to Haiku. A lot of things wouldn't need to port then, and those that did require some changes would still probably be easier than a straight-up port. Of course, I'd have built on top of the Linux kernel anyway and got that compat for free by just creating a new namespace. > 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... Then why not just include QT in the base system? You seem resigned to relying on QT applications, may as well make it official. How is spending years to develop a package manager better? > They push "install" and the dependencies are installed, and that's that. Unless, and I realize there are a whole lot of people out there simply unable to grasp the concept of this, they don't have an internet connection.
- waddlesplash 7y ago
  > It took years to make the package manager. You honestly believe it was worth it for this? It took about two years. The rest was largely getting HaikuPorts into shape and making it behave the way people expected. Few (if any?) major changes to the package manager itself occurred after the initial development and then merge. So the main time was actually getting stuff ported for the most part. > But depending on support for bind mounting, in particular read-only bind mounting, chroots might be. Bind mounting is supported. It does not appear to support read-only binding, but I only looked at it for about 10 seconds just now. > Though personally I'd have just put them in a compatibility environment, like WINE but translating from Linux to Haiku. If we are going to have to tolerate ported apps, we want that to be on our terms, not theirs. Part of that is having them be actually integrated with the system as much as we can do -- i.e. clipboard, native file dialogs, icons, look and feel, etc. Otherwise, people will just feel like they're using a shoddy recreation of Linux (which is what it would be) and not an OS in its own right. > Of course, I'd have built on top of the Linux kernel anyway and got that compat for free by just creating a new namespace. One of Haiku's main goals is the holistic integration of the complete system, which would be seriously compromised if we used the Linux kernel. There are a good number of instances where we made changes to the entire stack that would simply have never been possible on the Linux or even a BSD kernel. > Then why not just include QT in the base system? Why not just admit defeat and surrender to Windows? They have 90% of the market-share, anyway. Adding Qt to the base system wouldn't just be a compromise on our principles, it would essentially be a complete abandonment of them. > How is spending years to develop a package manager better? For all the reasons I already iterated... > Unless, and I realize there are a whole lot of people out there simply unable to grasp the concept of this, they don't have an internet connection. Yes, probono remarked about this, and (quite literally today) there has been discussion about how to better facilitate this. It seems we have more or less reached a concensus on starting with "pkgman export": collect a package and its dependencies inside a .tar, and then support reading these in "pkgman install" (and eventually in the GUI by some mechanism.) So, support for this should be merged before too long.

AnIdiotOnTheNet 7y ago

> 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. It took years to make the package manager. You honestly believe it was worth it for this? > Well, there are chroots and su, but that is probably not what you had in mind. su definitely isn't. But depending on support for bind mounting, in particular read-only bind mounting, chroots might be. > we are tolerating [...] ported applications to close the gaps. Which is fair. Though personally I'd have just put them in a compatibility environment, like WINE but translating from Linux to Haiku. A lot of things wouldn't need to port then, and those that did require some changes would still probably be easier than a straight-up port. Of course, I'd have built on top of the Linux kernel anyway and got that compat for free by just creating a new namespace. > 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... Then why not just include QT in the base system? You seem resigned to relying on QT applications, may as well make it official. How is spending years to develop a package manager better? > They push "install" and the dependencies are installed, and that's that. Unless, and I realize there are a whole lot of people out there simply unable to grasp the concept of this, they don't have an internet connection.

waddlesplash 7y ago
> It took years to make the package manager. You honestly believe it was worth it for this? It took about two years. The rest was largely getting HaikuPorts into shape and making it behave the way people expected. Few (if any?) major changes to the package manager itself occurred after the initial development and then merge. So the main time was actually getting stuff ported for the most part. > But depending on support for bind mounting, in particular read-only bind mounting, chroots might be. Bind mounting is supported. It does not appear to support read-only binding, but I only looked at it for about 10 seconds just now. > Though personally I'd have just put them in a compatibility environment, like WINE but translating from Linux to Haiku. If we are going to have to tolerate ported apps, we want that to be on our terms, not theirs. Part of that is having them be actually integrated with the system as much as we can do -- i.e. clipboard, native file dialogs, icons, look and feel, etc. Otherwise, people will just feel like they're using a shoddy recreation of Linux (which is what it would be) and not an OS in its own right. > Of course, I'd have built on top of the Linux kernel anyway and got that compat for free by just creating a new namespace. One of Haiku's main goals is the holistic integration of the complete system, which would be seriously compromised if we used the Linux kernel. There are a good number of instances where we made changes to the entire stack that would simply have never been possible on the Linux or even a BSD kernel. > Then why not just include QT in the base system? Why not just admit defeat and surrender to Windows? They have 90% of the market-share, anyway. Adding Qt to the base system wouldn't just be a compromise on our principles, it would essentially be a complete abandonment of them. > How is spending years to develop a package manager better? For all the reasons I already iterated... > Unless, and I realize there are a whole lot of people out there simply unable to grasp the concept of this, they don't have an internet connection. Yes, probono remarked about this, and (quite literally today) there has been discussion about how to better facilitate this. It seems we have more or less reached a concensus on starting with "pkgman export": collect a package and its dependencies inside a .tar, and then support reading these in "pkgman install" (and eventually in the GUI by some mechanism.) So, support for this should be merged before too long.