3 ms·

> is at least in part because of the reliance on package management. If Linux had a stable base set of shared libraries developers could depend on Except in sa

> is at least in part because of the reliance on package management. If Linux had a stable base set of shared libraries developers could depend on Except in saying that, you're completely ignoring the fact that X11 by itself requires how many different projects, all of which have different teams, goals, etc.? Just attempting to even get that would wind up in bikesheds at so many levels that it'd be impossible to do. But this has been Linux's problem since the 90s, it's not new at all. And Linux has always been "just a kernel." Even FreeBSD still has disagreements about what to put in the base system, and they did get along without a true package manager for a while, but not anymore. > Sure, as long as you only ever want to work within the confines of what is provided by the package manager. A few weeks ago I needed something the package manager didn't have. So I ported and made another package for it. I also ran into a BeOS app that still used the "appdir" model because nobody updated it, and it still worked. The package manager isn't "old magic" which must be "appeased" and "worked around." If it doesn't work, or it's missing something, we fix it. > "Easy" requires the system to try and understand what I want, and we know how well that works for youtube, netflix, and amazon recommendations. I've reiterated multiple times that you can forego the package manager and use the still-existing "easy" route if you'd like. Why does the package manager's mere existence cause a problem? > Can you put an application on a USB drive, take it to another Haiku system, and run it from the USB drive without installation? ... Yes. The executable bit still exists outside of packages, you know ;) You will need to manually extract said packages, and then set up the `lib` folder properly (just as app developers did for appdirs); and then this relies on the application using relative paths for loading data (which all should, because they can be installed in `~` as well, but I'm not sure we check for conformance on this point just yet.) You of course loose all the benefits of the package manager -- updates, etc. -- by doing this. But I guess that's what you want.

AnIdiotOnTheNet 8y ago
I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals. > I've reiterated multiple times that you can forego the package manager and use the still-existing "easy" route if you'd like. Why does the package manager's mere existence cause a problem? Because when it is the official "way things are done", that will be relied upon and anyone not doing things "the way things are done" will be ignored and told to do things "the way things are done". See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary. Example: Try installing Visual Studio Build Tools to somewhere other than Program Files. It can't be done. It will install a few things to wherever you pointed it, but because "Program Files is where the programs go" someone at Microsoft hardcoded paths so it just dumps the majority of it in Program Files anyway. Another example: Try to get apt to download a package you already have installed, and all its dependencies, onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer. > Yes. The executable bit still exists outside of packages, you know ;) It isn't about the executable bit, it's about expectations. Someone hardcodes a path to something because that's where the package manager puts it and I'm SOL. > You will need to manually extract said packages, and then set up the `lib` folder properly (just as app developers did for appdirs); The difference of course being that the developers do it for an appdir, whereas now that is something I have to do as the user. > and then this relies on the application using relative paths for loading data (which all should, because they can be installed in `~` as well, but I'm not sure we check for conformance on this point just yet.) Precisely. It isn't the way things are done, so no one cares. It sounds like the hoops I'd have to jump through to make appdirs on Haiku might be less than what I'd have to do on Linux, which is nice, but isn't going to make Haiku any more attractive to me. After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support.
- waddlesplash 8y ago
  > I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals. Indeed we agree on that. > See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary. That is a community problem, not a technical problem then. We should fix those, too. > onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer. Haiku's `pkgman` doesn't have this feature built-in yet, but it would be easy enough to add. Already you can just copy `hpkg` files out of /system/packages to anywhere you want, and then run `pkgman install <files>` to install those HPKGs elsewhere (assuming you grabbed all the right ones.) Actually, since you can already dump package info (including dependencies) using `pkgman`, writing a script to do this would be pretty easy. It looks like there's a way to do this in apt, anyway: https://stackoverflow.com/a/27469489 https://stackoverflow.com/a/27469489 > After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support. If that's all you want, then sure, go ahead. Again, this wasn't some integral part of Haiku's identity in our minds.
  - AnIdiotOnTheNet 8y ago
    I'm aware of the script for apt, actually, precisely because I needed to do this once. That's a hack though, apt clearly wasn't built with the idea that anyone might ever want to do something with packages other than install them on their local system. It's fine that Haiku's goals and mine don't align, really it is. I'm just not going to go out of my way to use it because I don't feel it offers advantages that outweigh the disadvantages.
    - waddlesplash 8y ago
      "It wasn't built with the idea", but yet you can do that, because of the UNIX philosophy of chaining commands together. So I think if you're calling it a "hack", then you fundamentally disagree with the UNIX philosophy. I mean, I have my issues with it, but I wouldn't go so far as to say that kind of command chaining is a "hack".

AnIdiotOnTheNet 8y ago

I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals. > I've reiterated multiple times that you can forego the package manager and use the still-existing "easy" route if you'd like. Why does the package manager's mere existence cause a problem? Because when it is the official "way things are done", that will be relied upon and anyone not doing things "the way things are done" will be ignored and told to do things "the way things are done". See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary. Example: Try installing Visual Studio Build Tools to somewhere other than Program Files. It can't be done. It will install a few things to wherever you pointed it, but because "Program Files is where the programs go" someone at Microsoft hardcoded paths so it just dumps the majority of it in Program Files anyway. Another example: Try to get apt to download a package you already have installed, and all its dependencies, onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer. > Yes. The executable bit still exists outside of packages, you know ;) It isn't about the executable bit, it's about expectations. Someone hardcodes a path to something because that's where the package manager puts it and I'm SOL. > You will need to manually extract said packages, and then set up the `lib` folder properly (just as app developers did for appdirs); The difference of course being that the developers do it for an appdir, whereas now that is something I have to do as the user. > and then this relies on the application using relative paths for loading data (which all should, because they can be installed in `~` as well, but I'm not sure we check for conformance on this point just yet.) Precisely. It isn't the way things are done, so no one cares. It sounds like the hoops I'd have to jump through to make appdirs on Haiku might be less than what I'd have to do on Linux, which is nice, but isn't going to make Haiku any more attractive to me. After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support.

waddlesplash 8y ago
> I don't think we're disagreeing on the problem with Linux Desktop here. The whole system is a patchwork of projects by different groups with disparate goals. Indeed we agree on that. > See: any question on a Linux Desktop forum where the user wanted to do something out of the ordinary. That is a community problem, not a technical problem then. We should fix those, too. > onto a USB drive so you can install them on a computer that doesn't have the internet. The developers never considered the possibility that someone would want to download software for a different computer. Haiku's `pkgman` doesn't have this feature built-in yet, but it would be easy enough to add. Already you can just copy `hpkg` files out of /system/packages to anywhere you want, and then run `pkgman install <files>` to install those HPKGs elsewhere (assuming you grabbed all the right ones.) Actually, since you can already dump package info (including dependencies) using `pkgman`, writing a script to do this would be pretty easy. It looks like there's a way to do this in apt, anyway: https://stackoverflow.com/a/27469489 https://stackoverflow.com/a/27469489 > After all, if I'm going to jump through those hoops I may as well do it on an OS with better hardware and software support. If that's all you want, then sure, go ahead. Again, this wasn't some integral part of Haiku's identity in our minds.
- AnIdiotOnTheNet 8y ago
  I'm aware of the script for apt, actually, precisely because I needed to do this once. That's a hack though, apt clearly wasn't built with the idea that anyone might ever want to do something with packages other than install them on their local system. It's fine that Haiku's goals and mine don't align, really it is. I'm just not going to go out of my way to use it because I don't feel it offers advantages that outweigh the disadvantages.
  - waddlesplash 8y ago
    "It wasn't built with the idea", but yet you can do that, because of the UNIX philosophy of chaining commands together. So I think if you're calling it a "hack", then you fundamentally disagree with the UNIX philosophy. I mean, I have my issues with it, but I wouldn't go so far as to say that kind of command chaining is a "hack".