This is great news for the Glass Elevator side of Haiku. I’m still of the opinion that this should stay in the focus beyond R1. Glass Elevator is the long-time codename for all things Haiku scheduled for beyond R1. This has been true ever since Haiku was called OpenBeOS, which at the time only consisted of OpenTracker, OpenDeskbar, and OpenBFS was just being developed. Hardware acceleration has been slated for Glass Elevator since day one. Be patient. The Glass Elevator soon enough will be leaving the ground floor. 
1 Like
Good grief…
2 Likes
If that’s all you could get out of that, then good grief, indeed.
I figured it was best I left it at that… X.x
Frankly my concern is that developers get burned out bugfixing… that is a thing. Maybe not a big deal if R1 can get out in a year or two though. R1 “now with less bugs” is a little anti climactic even if it is the goal.
1 Like
I think that’s the current goal, hopefully with a second beta and possibly a release candidate or two along the way.
For those who have been following Haiku for over a decade and a half, R1 is very much a climactic milestone.
New features will be added in that time though… its just a fact… a lot of the things that have problems aren’t so much tied to were new features are going in.
True. This is nearly always the case. There still needs to be a balance between adding features and getting to R1 or it will be postponed ad infinitum.
Hardware acceleration has been a goal of Haiku since day one. It has also been scheduled for Glass Elevator since day one. It’s been a long enough road just getting to B1 milestone. I expect the Glass Elevator projects will get more attention after B2 or RC1. This expectation was also set early on since the early days of OpenBeOS.
Package management, as in HaikuDepot, was originally slated for Glass Elevator, iirc. Pushing it forward created a rift that took nearly 5 years to recover from. I for one am loathe to see that happen again. Im glad that Haiku did recover from that. I’m looking forward to R1 so that some of the bigger advancements can get much needed attention. That said, I’m a huge fan of how HaikuDepot turned out.
Still recovering from. Frankly package management didn’t have to be a rift… but it was none the less.
It was a rift because many of the devs and users are shy about focus shifts. I wonder why? This is less true now than it was then. We lost some good folks in those days. Perhaps a few will return in a release or two.
1 Like
Then there are various inelegancies to package management that it seems its too late to fix either because it’s in a release or nobody wants to bite that off. Mainly my nit pick with it is how the RW/RO layering works. Right now it’s all or nothing, and the filesystem normal paths are RO by default… which is a bit crazy. The RO paths should have been kept in packaged folders rather than the other way round.
I mean negation in the file path is not elegant. …/non-packaged/… the whole point of the design was flexiblity, and then we get that. Things like that are why people left. It cuts against the grain of good defaults, it’s something you have to explain about package mangement… because nobody does that.
1 Like
Which is exactly why it is important to not be overly hasty. Especially with the next big feature, such as hardware acceleration.
Hasty is the one thing it isn’t…
Generally though, getting hardware accel bits hooked up and finalizing how the API on Haiku works are separate also. Even if just offscreen mesa were hardware accelerated this would be a big step.
1 Like
My qualms with the package manager are the same as yours. Things like this are one of the big reasons that focus shifts have been shunned from the beginning. It is to avoid inelegance and incorrectness in the system.
Hasty is what moved it earlier in the timeline out of Glass Elevator, where it was originally slated. One step forward. Two steps back. There was a rush to implement it earlier than originally planned. Que sera, sera. The price has been paid. Let’s keep moving forward.
Yeah, but at the same time, I wouldn’t go back to not having package management… that would be much worse than the current state. I wouldn’t mind though if after having lived with things as they are for awhile some open ended conversion on if there are improvements that can be made. Across the board.
The same goes for many other features. Getting something imperfect out the door, is almost better than just sitting on ideas forever. More like SpaceX style development is better than conventional “it can’t fail” development… its toally OK if something sucks it gets fixed and or ripped out and improved as long as other things don’t depend on it.
1 Like
Wasn’t a similar notion applied to rationalize PM?
Probably but even 5, 6 years later it was probably the right call at that point… I have no nit pick with that or most of what was done, just some minor annoyances.
Also just noticed that Web+ now displays embedded fonts it seems!
2 Likes