Heading towards Alpha 4
The project’s members are currently working towards Haiku R1/Alpha 4, with the next release currently a topic of discussion on the Haiku development mailing list. “We don't call our releases ‘beta’, since we don't consider them feature complete,” Aßmus says.
The “one big missing feature” is package management: “A lot of interesting and visionary work has been done for package management already, but it changes many fundamental aspects of Haiku. Like the system folder layout and some important things like the system folder itself becoming read-only.
“That's why it is not yet in the master branch. It needs a lot more work before it can be integrated. The people having worked on it most are currently too busy with their jobs, so the progress on that front has stalled for the time being.”
Heading towards Haiku 1.0
When Haiku hits 1.0 — or ‘R1’ — it will have “tons of new features” compared to BeOS R5, despite being a drop-in replacement for the older system, Aßmus says. “Internationalisation, cool new APIs like powerful layout management. End users see this as all apps being scalable and adopting to different strings when switching languages.
“Haiku has support for modern hardware, like wireless networking. BeOS R5 didn't even support USB 2.0 or mass storage devices out of the box. And actually, BeOS doesn't even run on most computers made in the last eight to 10 years. It would not even boot when your computer had more than one gigabyte of RAM installed.”
There’s no release date for R1 yet, but the project is making a lot of progress, particularly thanks to being part of Google Summer of Code (GSoC). However, a decision by the development team means the features being worked on by GSoC participants are not critical for R1’s release.
“There is an x86_64 port, NFSv4 module, BFS resizing support, power management and even an OpenJDK port — all progressing nicely,” Aßmus says. However, package management remains stalled, although this “may change at any time”.
“It may take at least another year, probably more, before package management is ready. Maybe if one or two of our capable GSoC students sticks around and dig into that field, it could go a lot faster.”
The team behind Haiku have tentative plans that look beyond R1, however: While R1 will replicate the functionality of BeOS R5 (albeit with modern hardware support and a stack of extra features) Haiku R2 is intended to take the BeOS philosophy even further.
“One big challenge [with R2] will be to extend and shape the features that are already there, and adopt them more towards the use cases of actual users,” Aßmus says.
“For example, Haiku does not realise the full potential of file system queries, which is mostly a matter of how search results are presented to the user, and how queries are integrated or used within applications. There is a lot of potential there.
“And of course there are features like hardware 3D acceleration, compositing on the desktop or multi-user that everyone would love to have.”
One challenge for the future will be “What happens when other frameworks are ported to Haiku?”
“What is the difference of running a Qt application on Haiku versus running it on Linux?” Aßmus says. “Qt is already available for Haiku. Maybe someone ports GTK. The OpenJDK port is very far along and can run big Swing based Java apps. This both benefits Haiku as a platform, but it also makes it less compelling to write native Haiku apps.
“And that basically defeats the desire to provide a redundancy free system where everything works only one way, completely integrated with everything else.”
Follow Rohan on Twitter: @rohan_p
Follow Techworld Australia on Twitter: @techworld_au