8 ms·

Yes, we've been taken over by "Linux Desktop" people so much, a majority of the team is still opposed to using the Linux kernel, dislikes ported software, and a

Yes, we've been taken over by "Linux Desktop" people so much, a majority of the team is still opposed to using the Linux kernel, dislikes ported software, and actively works to not use GPL code when we can! Joking aside, I know the package manager was somehow a sticking point for people when it was merged in a pretty unpolished state, but at this point I'm not sure what the complaints are. Even most of the regular errors or problem states people associate with package managers don't occur all that often on Haiku. And I also note the people who did the most work on the LibreOffice port say they would not even have attempted it without the package manager, so there's that.

AnIdiotOnTheNet 8y ago
> Joking aside, I know the package manager was somehow a sticking point for people when it was merged in a pretty unpolished state, but at this point I'm not sure what the complaints are. Package management is an awful paradigm for application management. I'm not familiar with Haiku's implementation, but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy. In other words, they're a UNIX system. Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way, often don't allow multiple concurrent instance of the same application to be install (different versions, for instance), are completely inflexible in regards to where applications are installed (so portability is right out), etc. Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one. It appears that the developers disregarded these concerns because they like package management in Linux. Fine, they're the one's working on it, they can do what they want, but I don't have to like or praise that decision. > And I also note the people who did the most work on the LibreOffice port say they would not even have attempted it without the package manager, so there's that. Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage.
- waddlesplash 8y ago
  > but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy. Well, guess what? LibreOffice has a complex web of dependencies, and getting all those couple dozen dependencies patched, built, and then properly installed so the build system & compiler can find and use them is not trivial. If you've got a Haiku install, try installing LibreOffice; you'll see it brings about 20-30 packages with it! > In other words, they're a UNIX system. Haiku is a POSIX system, yes. Why is that an issue? > Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way Well, Haiku packages can be installed without a repository. If all your package depends on are is base system itself, you can still ship it to users without a repository. Or you can run your own repository; it's quite easy to do, and multiple third-parties already are. Or you can submit recipes to HaikuPorts, which feeds the base "ports" repository, which multiple third-parties have also already done, in addition to our own proactive porting effort. > often don't allow multiple concurrent instance of the same application to be install (different versions, for instance) On Haiku, you can install packages in either `system` or in your local `home` directory, so you could have one version of the package in each of those. Or you could extract the package and run the app outside the package (if the app supports it; not all do.) > are completely inflexible in regards to where applications are installed (so portability is right out), etc. Indeed this is a common complaint, but as I noted above on Haiku you can install packages in `home`. Not sure what that has to do with portability, though? > It appears that the developers disregarded these concerns because they like package management in Linux We don't particularly like a number of aspects of package management in Linux, which is why we went with a very different solution than Linux did: packages are essentially filesystem images which are "mounted" into a pseudo-unionfs. That means installation/uninstallation time is virtually nothing, it's trivial to install packages in `home` as well as `system`, you can boot into old states, etc. > Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage. Windows has LibreOffice because everyone uses Windows, and so people are willing to put the time in to deal with having to patch and compile all LibreOffice's dependencies specially for Windows because there is no real "ports" tree for Windows. AppImages are just 'packages' with all the dependencies in the package. You could make those for Haiku, too, if you wanted. The system package manager isn't stopping you. You could also install software the "old way" of unzipping archives and then copying them somewhere, we also aren't stopping that. This is a new paradigm that hopefully will replace the old ones, but it doesn't necessarily, not if people continue to use the old ways. > Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one. And a good number of those users have come around on that as we've ironed out issues or made changes to accommodate their concerns.
- phkahler 8y ago
  >> ...are completely inflexible in regards to where applications are installed... Why users want to install programs willy-nilly in various random places is beyond me. Having standard installation locations makes inter-operability easier. This isn't so much a thing for applications as it is for libraries, but it does come up for apps too. With standard installations it should be possible to simply list the dependencies an application has, but then you'll still want a central repository to get them from to make it easy and keep compatible versions around. It's not great, but it works and I have yet to see a good alternative.
  - AnIdiotOnTheNet 8y ago
    > Why users want to install programs willy-nilly in various random places is beyond me. Maybe I want some applications on my SSD and others on slower media? Maybe I want to have it on a thumbdrive I can carry around with me and run on whatever computer is nearby (and obviously running the same OS)? Maybe I just want to organize my file tree in a way that makes more sense to me? Just because your imagination is limited doesn't mean there aren't reasons people might want to do other things.
    - probonopd 8y ago
      AnIdiotOnTheNet, I couldn't agree more. Which is why I've started the AppImage project roughly a decade ago. Would you like to join, even if only as an evangelist? Please get in touch with us via GitHub. It's important to spread the word.
      - AnIdiotOnTheNet 8y ago
        I'm a fan of AppImage, a lone island of sanity in the ocean of bad ideas on the Linux Desktop. You were involved with Klik before that right? So it has been more than a decade. And you're not the only one, there's also been efforts like GoboLinux and RoxOS, both of which have been more or less completely ignored by the community, which is why I think the Linux Desktop is unsalvageable. The Linux Desktop community is simply not culturally ever going to accept a desktop that actually works like a desktop. I can't put my finger on why. Is it dogma? Do they just prefer needless complexity? Do they simply lack the experience to know how awful the system is? I don't know. Point is, I think the only real way forward is to do what Google did with Android: take the kernel, which is actually pretty reasonable, and put a completely new userland on top of it. Forking some currently existing software may be acceptable in some cases, but the new system should separate itself as much as it possibly can from the currently existing Linux Desktop community. It won't be a Linux distribution, and I think it'd be best to not even mention Linux. I have done some preliminary work regarding the design of such a system, how its applications would work, completely re-imagining how the filesystem tree works and even what it is for, that sort of thing. But the more discussion I have about ideas in that vein the more I realize that nobody really wants that, they all just want their over-engineered web-kiosk with 1970s-era tooling and sensibilities.

AnIdiotOnTheNet 8y ago

> Joking aside, I know the package manager was somehow a sticking point for people when it was merged in a pretty unpolished state, but at this point I'm not sure what the complaints are. Package management is an awful paradigm for application management. I'm not familiar with Haiku's implementation, but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy. In other words, they're a UNIX system. Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way, often don't allow multiple concurrent instance of the same application to be install (different versions, for instance), are completely inflexible in regards to where applications are installed (so portability is right out), etc. Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one. It appears that the developers disregarded these concerns because they like package management in Linux. Fine, they're the one's working on it, they can do what they want, but I don't have to like or praise that decision. > And I also note the people who did the most work on the LibreOffice port say they would not even have attempted it without the package manager, so there's that. Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage.

waddlesplash 8y ago
> but the only reason anyone needs a package manager is if they intend on having a complex web of dependencies and spreading an application's files all over the hierarchy. Well, guess what? LibreOffice has a complex web of dependencies, and getting all those couple dozen dependencies patched, built, and then properly installed so the build system & compiler can find and use them is not trivial. If you've got a Haiku install, try installing LibreOffice; you'll see it brings about 20-30 packages with it! > In other words, they're a UNIX system. Haiku is a POSIX system, yes. Why is that an issue? > Implementations are almost always reliant on a centrally managed appstore-like repository that developers have to deal with to distribute software in the "official" way Well, Haiku packages can be installed without a repository. If all your package depends on are is base system itself, you can still ship it to users without a repository. Or you can run your own repository; it's quite easy to do, and multiple third-parties already are. Or you can submit recipes to HaikuPorts, which feeds the base "ports" repository, which multiple third-parties have also already done, in addition to our own proactive porting effort. > often don't allow multiple concurrent instance of the same application to be install (different versions, for instance) On Haiku, you can install packages in either `system` or in your local `home` directory, so you could have one version of the package in each of those. Or you could extract the package and run the app outside the package (if the app supports it; not all do.) > are completely inflexible in regards to where applications are installed (so portability is right out), etc. Indeed this is a common complaint, but as I noted above on Haiku you can install packages in `home`. Not sure what that has to do with portability, though? > It appears that the developers disregarded these concerns because they like package management in Linux We don't particularly like a number of aspects of package management in Linux, which is why we went with a very different solution than Linux did: packages are essentially filesystem images which are "mounted" into a pseudo-unionfs. That means installation/uninstallation time is virtually nothing, it's trivial to install packages in `home` as well as `system`, you can boot into old states, etc. > Says a lot about the system then doesn't it? Windows has a portable LibreOffice, even Linux has an AppImage. Windows has LibreOffice because everyone uses Windows, and so people are willing to put the time in to deal with having to patch and compile all LibreOffice's dependencies specially for Windows because there is no real "ports" tree for Windows. AppImages are just 'packages' with all the dependencies in the package. You could make those for Haiku, too, if you wanted. The system package manager isn't stopping you. You could also install software the "old way" of unzipping archives and then copying them somewhere, we also aren't stopping that. This is a new paradigm that hopefully will replace the old ones, but it doesn't necessarily, not if people continue to use the old ways. > Many of the problems I have with package managers were expressed by parts of the Haiku community when it introduced one. And a good number of those users have come around on that as we've ironed out issues or made changes to accommodate their concerns.
phkahler 8y ago
>> ...are completely inflexible in regards to where applications are installed... Why users want to install programs willy-nilly in various random places is beyond me. Having standard installation locations makes inter-operability easier. This isn't so much a thing for applications as it is for libraries, but it does come up for apps too. With standard installations it should be possible to simply list the dependencies an application has, but then you'll still want a central repository to get them from to make it easy and keep compatible versions around. It's not great, but it works and I have yet to see a good alternative.
- AnIdiotOnTheNet 8y ago
  > Why users want to install programs willy-nilly in various random places is beyond me. Maybe I want some applications on my SSD and others on slower media? Maybe I want to have it on a thumbdrive I can carry around with me and run on whatever computer is nearby (and obviously running the same OS)? Maybe I just want to organize my file tree in a way that makes more sense to me? Just because your imagination is limited doesn't mean there aren't reasons people might want to do other things.
  - probonopd 8y ago
    AnIdiotOnTheNet, I couldn't agree more. Which is why I've started the AppImage project roughly a decade ago. Would you like to join, even if only as an evangelist? Please get in touch with us via GitHub. It's important to spread the word.
    - AnIdiotOnTheNet 8y ago
      I'm a fan of AppImage, a lone island of sanity in the ocean of bad ideas on the Linux Desktop. You were involved with Klik before that right? So it has been more than a decade. And you're not the only one, there's also been efforts like GoboLinux and RoxOS, both of which have been more or less completely ignored by the community, which is why I think the Linux Desktop is unsalvageable. The Linux Desktop community is simply not culturally ever going to accept a desktop that actually works like a desktop. I can't put my finger on why. Is it dogma? Do they just prefer needless complexity? Do they simply lack the experience to know how awful the system is? I don't know. Point is, I think the only real way forward is to do what Google did with Android: take the kernel, which is actually pretty reasonable, and put a completely new userland on top of it. Forking some currently existing software may be acceptable in some cases, but the new system should separate itself as much as it possibly can from the currently existing Linux Desktop community. It won't be a Linux distribution, and I think it'd be best to not even mention Linux. I have done some preliminary work regarding the design of such a system, how its applications would work, completely re-imagining how the filesystem tree works and even what it is for, that sort of thing. But the more discussion I have about ideas in that vein the more I realize that nobody really wants that, they all just want their over-engineered web-kiosk with 1970s-era tooling and sensibilities.