User-managed packages separated from system packages
This actually sounds a lot like NixOS (plus home-manager, for the third item). Haiku seems to have had way more work put into user-friendliness and approachability, though.
I was thinking exactly the same - Nix is such an incredible pain to manage. I wonder if Haiku’s packaging can be programmatically leveraged like Nix, so you can create workspaces with pinned packages for your projects (i.e. have programs installed in the project workspace that are either not present in the global system or at different version combinations).
There isn’t currently, there’s a little bit of logic that uses predefined locations. The haikuporter tool does use chroots to achieve a local package environment though…
The user-friendliness & approachability took multiple years to fully get right. I discussed that a bit in longer reply below, but the full history of that era in Haiku’s history (2012-2016) has yet to be written…
A little off-tangent, but I really find the Haiku desktop and GUI theme lovely whenever I see screenshots. It’s not flat! It has shading! Icons have color!
Couldn’t agree more. I can’t stand “flat design”, soulless grey, white space and monochrome icons everywhere. Haiku is a refuge from all that, and is just plain fun to use.
Sadly, the hardware support and power management in particular just isn’t quite there last time I checked. I’ve tried a few times to get Haiku running on laptop hardware of various generations, and each time there was always something that didn’t quite work. When you have fully supported hardware (like my Lenovo SFF PC) it’s great, but laptops are quite another story.
I’ve tried a few times to get Haiku running on laptop hardware of various generations, and each time there was always something that didn’t quite work.
If you pick hardware carefully, you can find ones that do work. I have a ThinkPad E550 from ca. 2015 that works great; the only thing missing is the webcam (though, admittedly, it was missing some drivers when I first acquired it and had to spend time on that over the years!)
Power management does need more work. We still don’t support sleep states in any fashion, and doing so will likely require a refactor of the kernel device manager (which kind of needs it anyway.) One of these days…
I have a couple of older MacBook Pros (including a Core 2 one that can’t really run a vaguely modern macOS) that might be a reasonable fit. I’ll maybe see if it can work with Haiku. Its WiFi is so old that it might be supported…
I think the way that Haiku does package management is really clever; I love it when they actually have interesting ideas of their own instead of trying to be some kind of nostalgia thing. It’s not about being BeOS or whatever, it’s carrying on its spirit.
Well, I’m a big fan of BeOS and ran it for quite a few years after jumping ship from the Amiga (maybe I should revisit my decision making skills!) so I’m glad they are continuing on with some of the original design principles. BeOS and Haiku just “click” with me in a way that feels right which I never got with e.g. desktop Linux.
But you’re right, they’ve had some really interesting ideas above and beyond their BeOS roots like the whole package management thing and their own HVIF vector icon format. It’s that stuff I find the most interesting - I guess ideas like that can flourish in the Haiku / alt-OS scene because they don’t have to contend with the sheer inertia of e.g. trying to drag all the Linux distros along with them.
There have been a few interesting experiments in the Linux world like GoboLinux etc. But it’s nigh on impossible to get everyone to agree on anything there (c.f. systemd) and there’s little appetite for big breaking changes to the Way Things Have Always Been Done.
and there’s little appetite for big breaking changes to the Way Things Have Always Been Done.
What’s really strange about the Linux ecosystem (and to a lesser extent other OSes, too, but Linux seems especially prone to it) is that if you want to change “the way things are done”, you face a massive uphill battle that will probably never be resolved, but if you want to introduce the N+1’th way of doing them, that’s totally fine and there’s no problem with that, we’ll merge your code into our trees if there’s enough people that are using it.
I’m not entirely sure where that attitude comes from, to be honest. Maybe it’s something along the lines of, preferring “to each their own” over attempting to find commonality and an optimal solution, which might require you to change, too? Or is it thinking that such commonality and more optimal solutions are not possible in the first place and it’s a waste of time trying to find them? Or something else altogether, perhaps…
If someone shows up in the Haiku community with a suggestion or a request for a UI/UX or API change, we spend a bunch of time first in discussion about whether that change would really be valuable, or not, whether to that one suggester or to everyone. Sometimes (or at least for newcomers suggesting changes, often) it isn’t, and so we figure out how the suggester can accomplish what they wanted by some other means (this sometimes requires that they adjust their own muscle memory.) Sometimes it is, though, and it’s not just a new addition but a change to how things behave; and then everyone else has to un-learn/re-learn something, but if it’s really an improvement, they hopefully won’t mind.
That principle has served us well, even if it sometimes causes strife. When the package manager was first merged from a feature branch into the mainline development tree, it was rather unpolished and the ecosystem wasn’t ready to handle it, so there was a lot of strife and a number of unhappy users, as the “growing pains” of the package manager (which were temporary, and have since been worked out) got confused with the actual and inherent downsides that come with a package-managed system (which are real, and required adaptation but ultimately outweighed by the advantages.)
The complaints, arguments, and strife from a significant segment of the community were not small, though. Some previously major members of the community basically ragequit during this period, some of whom took websites that were pretty significant down along with them (if you remember BeBits and Haikuware, well, they were casualties here.) Recovering from this, by fixing the rough parts of the new model, replacing parts of the ecosystem wholesale, and rebuilding trust and acceptance among the community that was damaged by this process, took multiple years. It didn’t help that all this disruption caused the development cycle from R1/alpha4 (2012) to R1/beta1 (2018) to be 6 years long, which gave all sorts of impressions both to the community and to outsiders that Haiku was stagnating. (It also didn’t help that it was during this period that a lot of the “old guard” of Haiku developers were settling down in ways that meant they had less time to spend on Haiku development, further contributing to the development slowdown!)
The fact that Haiku has come out the other side of this triumphant, and that some of the people who complained most loudly about the package manager are still around in the community and have changed their tune is really a testament to how much people believe in the mission, and also that the long-term benefits of the package manager that were claimed from the beginning (like the massive new selection of software ports) really did pay off and outweigh the short-term pain.
Maybe, having typed this out, it’s not so strange after all that Linux introduces “N+1th” ways of doing things all the time: it’s a way to do huge breaking changes without having hard-forks occur whenever they’re done. But I can tell you, that while there are certainly ways the Haiku package management history could have been smoother and we certainly learned some lessons along the way, I still prefer Haiku’s model; even if it can mean dealing with flamewars once a month for multiple years during the “growing pains” phase of a paradigm shift.
We obviously both prefer to take the “road less traveled by” when it comes to tech! Good to see another WebOS acolyte here, too. Interesting also that Palm acquired the BeOS IP - again, makes you wondered what would have happened if WebOS had decent hardware (I loved the OS, the Pre hardware less-so) and was given a chance - HP cocked that one up, but I remember when the HP TouchPad went on fire-sale and briefly became the best-selling non-Apple tablet for a few months.
I worked at HP when webOS got started and acquired (though in a completely different part of the company) so there was that. It wasn’t a bad gig, all things considered.
I do miss phones with physical keyboards. Ah well.
The package manager and HVIF are the two most visible “interesting ideas of our own”, but there’s others here and there, too. Some of the implementation details, for instance (e.g. StackOrHeapArray<>, to avoid excessive stack usage but avoid the heap for small data sizes; the aggressive use of Lockers to manage lock states from the display server/window manager all the way down to the lowest-level parts of the kernel; etc.) and some of the more visible features, too (e.g. HiDPI, which unlike most other UI toolkits does not have anything like “device pixels” vs. “logical pixels”; instead, all metrics are ultimately computed based on the system font size.)
We certainly haven’t stopped innovating, even if we do less of it due to person-power constraints.
(e.g. HiDPI, which unlike most other UI toolkits does not have anything like “device pixels” vs. “logical pixels”; instead, all metrics are ultimately computed based on the system font size.)
I think that’s how HiDPI in ancient (XP and older) Windows actually worked, before switching it to the modern approach.
Huh, interesting! I guess they probably dropped it because they realized a lot of applications were never going to fix their hardcoded pixel metrics, and it was just easier to do the logical/device pixels thing instead.
Yep the relevant term is “dialog unit” or DLU and strictly speaking it is based on the font of the dialog. Of course nothing in windows goes away anyway so you have the DLU scaling to the logical pixels to the physical pixels depending on which variant of “hidpi aware” (or not) the process declares itself as.
This is an excellent write-up! It was especially neat to see you came across (and apparently read, or at least skimmed!) the internals documentation, and utilized knowledge from that in the write-up. Kudos!
This actually sounds a lot like NixOS (plus home-manager, for the third item). Haiku seems to have had way more work put into user-friendliness and approachability, though.
I was thinking exactly the same - Nix is such an incredible pain to manage. I wonder if Haiku’s packaging can be programmatically leveraged like Nix, so you can create workspaces with pinned packages for your projects (i.e. have programs installed in the project workspace that are either not present in the global system or at different version combinations).
There isn’t currently, there’s a little bit of logic that uses predefined locations. The haikuporter tool does use chroots to achieve a local package environment though…
The user-friendliness & approachability took multiple years to fully get right. I discussed that a bit in longer reply below, but the full history of that era in Haiku’s history (2012-2016) has yet to be written…
A little off-tangent, but I really find the Haiku desktop and GUI theme lovely whenever I see screenshots. It’s not flat! It has shading! Icons have color!
Couldn’t agree more. I can’t stand “flat design”, soulless grey, white space and monochrome icons everywhere. Haiku is a refuge from all that, and is just plain fun to use.
I agree - it looks amazing and has a bit of an 8bit aesthetic, without relying on pixelation to achieve that feeling.
Things like this really make me wonder why I’m not using Haiku on my laptop.
Sadly, the hardware support and power management in particular just isn’t quite there last time I checked. I’ve tried a few times to get Haiku running on laptop hardware of various generations, and each time there was always something that didn’t quite work. When you have fully supported hardware (like my Lenovo SFF PC) it’s great, but laptops are quite another story.
If you pick hardware carefully, you can find ones that do work. I have a ThinkPad E550 from ca. 2015 that works great; the only thing missing is the webcam (though, admittedly, it was missing some drivers when I first acquired it and had to spend time on that over the years!)
Power management does need more work. We still don’t support sleep states in any fashion, and doing so will likely require a refactor of the kernel device manager (which kind of needs it anyway.) One of these days…
I have a couple of older MacBook Pros (including a Core 2 one that can’t really run a vaguely modern macOS) that might be a reasonable fit. I’ll maybe see if it can work with Haiku. Its WiFi is so old that it might be supported…
I think the way that Haiku does package management is really clever; I love it when they actually have interesting ideas of their own instead of trying to be some kind of nostalgia thing. It’s not about being BeOS or whatever, it’s carrying on its spirit.
Well, I’m a big fan of BeOS and ran it for quite a few years after jumping ship from the Amiga (maybe I should revisit my decision making skills!) so I’m glad they are continuing on with some of the original design principles. BeOS and Haiku just “click” with me in a way that feels right which I never got with e.g. desktop Linux.
But you’re right, they’ve had some really interesting ideas above and beyond their BeOS roots like the whole package management thing and their own HVIF vector icon format. It’s that stuff I find the most interesting - I guess ideas like that can flourish in the Haiku / alt-OS scene because they don’t have to contend with the sheer inertia of e.g. trying to drag all the Linux distros along with them.
There have been a few interesting experiments in the Linux world like GoboLinux etc. But it’s nigh on impossible to get everyone to agree on anything there (c.f. systemd) and there’s little appetite for big breaking changes to the Way Things Have Always Been Done.
What’s really strange about the Linux ecosystem (and to a lesser extent other OSes, too, but Linux seems especially prone to it) is that if you want to change “the way things are done”, you face a massive uphill battle that will probably never be resolved, but if you want to introduce the N+1’th way of doing them, that’s totally fine and there’s no problem with that, we’ll merge your code into our trees if there’s enough people that are using it.
I’m not entirely sure where that attitude comes from, to be honest. Maybe it’s something along the lines of, preferring “to each their own” over attempting to find commonality and an optimal solution, which might require you to change, too? Or is it thinking that such commonality and more optimal solutions are not possible in the first place and it’s a waste of time trying to find them? Or something else altogether, perhaps…
If someone shows up in the Haiku community with a suggestion or a request for a UI/UX or API change, we spend a bunch of time first in discussion about whether that change would really be valuable, or not, whether to that one suggester or to everyone. Sometimes (or at least for newcomers suggesting changes, often) it isn’t, and so we figure out how the suggester can accomplish what they wanted by some other means (this sometimes requires that they adjust their own muscle memory.) Sometimes it is, though, and it’s not just a new addition but a change to how things behave; and then everyone else has to un-learn/re-learn something, but if it’s really an improvement, they hopefully won’t mind.
That principle has served us well, even if it sometimes causes strife. When the package manager was first merged from a feature branch into the mainline development tree, it was rather unpolished and the ecosystem wasn’t ready to handle it, so there was a lot of strife and a number of unhappy users, as the “growing pains” of the package manager (which were temporary, and have since been worked out) got confused with the actual and inherent downsides that come with a package-managed system (which are real, and required adaptation but ultimately outweighed by the advantages.)
The complaints, arguments, and strife from a significant segment of the community were not small, though. Some previously major members of the community basically ragequit during this period, some of whom took websites that were pretty significant down along with them (if you remember BeBits and Haikuware, well, they were casualties here.) Recovering from this, by fixing the rough parts of the new model, replacing parts of the ecosystem wholesale, and rebuilding trust and acceptance among the community that was damaged by this process, took multiple years. It didn’t help that all this disruption caused the development cycle from R1/alpha4 (2012) to R1/beta1 (2018) to be 6 years long, which gave all sorts of impressions both to the community and to outsiders that Haiku was stagnating. (It also didn’t help that it was during this period that a lot of the “old guard” of Haiku developers were settling down in ways that meant they had less time to spend on Haiku development, further contributing to the development slowdown!)
The fact that Haiku has come out the other side of this triumphant, and that some of the people who complained most loudly about the package manager are still around in the community and have changed their tune is really a testament to how much people believe in the mission, and also that the long-term benefits of the package manager that were claimed from the beginning (like the massive new selection of software ports) really did pay off and outweigh the short-term pain.
Maybe, having typed this out, it’s not so strange after all that Linux introduces “N+1th” ways of doing things all the time: it’s a way to do huge breaking changes without having hard-forks occur whenever they’re done. But I can tell you, that while there are certainly ways the Haiku package management history could have been smoother and we certainly learned some lessons along the way, I still prefer Haiku’s model; even if it can mean dealing with flamewars once a month for multiple years during the “growing pains” phase of a paradigm shift.
I don’t know if it’s due to a “Linux mindset” or just the consequences of having multiple distributions and not a single, cohesive Linux OS.
Haiku being a smaller community also helps.I had no idea the package manager was such a controversial topic, with people ragequitting.
But for what it’s worth, I like the Haiku approach better :)
I don’t want to alarm you but we might be the same person.
If you also were an early adopter of Palm WebOS, then I’ll start to get worried ;)
Oh, and AMIGAAAAAAAAA!
…I was.
:O
We obviously both prefer to take the “road less traveled by” when it comes to tech! Good to see another WebOS acolyte here, too. Interesting also that Palm acquired the BeOS IP - again, makes you wondered what would have happened if WebOS had decent hardware (I loved the OS, the Pre hardware less-so) and was given a chance - HP cocked that one up, but I remember when the HP TouchPad went on fire-sale and briefly became the best-selling non-Apple tablet for a few months.
I worked at HP when webOS got started and acquired (though in a completely different part of the company) so there was that. It wasn’t a bad gig, all things considered.
I do miss phones with physical keyboards. Ah well.
:)
The package manager and HVIF are the two most visible “interesting ideas of our own”, but there’s others here and there, too. Some of the implementation details, for instance (e.g.
StackOrHeapArray<>, to avoid excessive stack usage but avoid the heap for small data sizes; the aggressive use ofLockers to manage lock states from the display server/window manager all the way down to the lowest-level parts of the kernel; etc.) and some of the more visible features, too (e.g. HiDPI, which unlike most other UI toolkits does not have anything like “device pixels” vs. “logical pixels”; instead, all metrics are ultimately computed based on the system font size.)We certainly haven’t stopped innovating, even if we do less of it due to person-power constraints.
I think that’s how HiDPI in ancient (XP and older) Windows actually worked, before switching it to the modern approach.
Huh, interesting! I guess they probably dropped it because they realized a lot of applications were never going to fix their hardcoded pixel metrics, and it was just easier to do the logical/device pixels thing instead.
Yep the relevant term is “dialog unit” or DLU and strictly speaking it is based on the font of the dialog. Of course nothing in windows goes away anyway so you have the DLU scaling to the logical pixels to the physical pixels depending on which variant of “hidpi aware” (or not) the process declares itself as.
This is an excellent write-up! It was especially neat to see you came across (and apparently read, or at least skimmed!) the internals documentation, and utilized knowledge from that in the write-up. Kudos!
Oh, this sounds quite delightful. A little like MacOS’s image-based installation, except more sleek and modern.