I’ve moved all the EFI-related posts to a new topic.
6 Likes
Support for games is not that unachievable goal thanks to the various game streaming cloud services that allow you to play latest games from a web browser. Services like GeForce NOW, Amazon Luna, Xbox Cloud Gaming, Boosteroid.
Hardware for Haiku R1 just has to stay within reason for most home users. There was the testing on the Mac Mini and Intel NUCs so I had looked at the System76 offerings like these:
- MeerKat - Meerkat
- Lemur Pro 14" laptop - Lemur Pro
- Thelio workstation - Thelio Major Custom
These seem supportable for Haiku R1… 
Still, 34 tickets remain.
One critical issue and five high priority issues.
Review the remaining tickets for current resolutions…
Summer 2025
Who knows what’s in there. Touchpads, wifis, etc. - they aren’t really saying, and my impression of the industry is that they may want to be able to change the hardware if necessary for whatever reason. That’s fine for their Ubuntu users, because System76 will check to make sure it works before they start shipping the new rev. Vendor support. Linux has it; so far as I know, Haiku doesn’t.
What about Moonlight, the game streaming client, is that ported?
7 posts were split to a new topic: Memory leaks in Beta5?
Also, we could add something like a single-user login screen. Like let’s just keep the single-user thing (one and only account is root), but like let’s add a login screen. No one wants their computer to be spied on while they use the bathroom, etc.
2 Likes
This sounds more like you’re actually looking for the password-locked screensaver feature, which does exist already.
I guess that password-locked screensaver can be overcome by rebooting, so not a real replacement for the login screen. OTOH I don’t think it’s a must have for R1, unless someone is ready to spend their time implementing it.
2 Likes
It’s a bit annoying that this offtopic discussion is continuing, because:
- Someone already implemented it
- They did the right thing and announced it in a new topic: Screensaver lock at boot time
5 Likes
That implementation looks good. So security is solved, what next?
Get Beta 6 out now!
Then we will see if it works!
1 Like
I finally finished reading the whole thread, and here’s my humble opinion:
DISCLAIMER: everything I’m going to say is based on the MINIX 2 book I read when I was a teenager.
It seems that one of the most common problems that is hindering progress is compatibility and support for older software and hardware. And it seems that this affects both 32-bit and 64-bit versions regardless of the CPU architecture they run on.
If we keep in mind Haiku’s original mission, which is to create a direct replacement for BeOS 5, we could say that 32-bit Haiku has already reached its goal, and could be in R1 without any problem. Actually, Haiku x86 has surpassed BeOS x86. But Haiku x64 is something totally different.
A quick and dirty way to solve this would be to separate development into two different lines. The 32-bit version would be developed with a reimplementation of the original BeOS API, and the 64-bit version would be developed with a Haiku API. Instead of having a BWindow, we would have a HWindow. I think that would finally give us a Haiku Book.
To achieve compatibility with older software, we could take advantage of the microkernel and load a server similar to a virtual machine. That way, the 64-bit Haiku would only have clean 64-bit code, and all 32-bit compatibility would be loaded or not, depending on the needs of each user, keeping the system faster and lighter.
Another way to improve on all of the above would be to use a NetBSD-like approach, with the device tree, conditional compilations, etc. By doing that, a port to a new architecture could be made with relatively little effort.
Anything to add?
It’s compatibility with newer software and hardware that’s a problem. Older software and hardware has long been solved and is already working.
And instead of writing one OS, we will have to write two. That will be twice as much work and logicallt it will take twice as long.
The 64 bit version of Haiku has no 32 bit compatibility. Users who need 32 bit compatibility can install the 32 bit version. The code is clean. Supporting 32 bit does not make the code ugly.
Someone will still need to write the book. And having two versions of the class with different names and APIs means, now they have to write two books instead of one.
What microkernel? Haiku does not currently use a microkernel. Are you suggesting that we should replace the kernel, after 25 years of finetuning it?
This is already done. Look at all the “arch” directories in the sourcecode.
“relatively little effort” but still someone has to write the specific code for each architecture. And also we get to decide where things need to be architecture specific and where they should be common between architectures. This can only be done when you port Haiku to a new architecture and find yourself in either one of these two situations:
- This code is in an arch/ subdirectory, but I ended up copypasting another architecture code into mine and it worked without any change, should we move it to the common parts?
- This code is in the common parts but my architecture has to work completely differently, should we move this to an arch specific directory?
The RISC-V port (and previously the PowerPC port) already highlighted several of these. That should make this part easier for newer architectures. But there is still the work to actually support new CPUs, MMUs, and other devices after that.
6 Likes
We may need to turn our focus on specific firmware and ROM when porting to other ISA (preferably open-sourced firmware and hardware for RISCV and ARM/64), like QEMU or Beagleboard. Taking ARM/64 port as an example, letting developers to test on varieties of tablets, phones and SBCs doesn’t help. The current “x86/x86-64” we’re working on is just Standard PC which took the majority of x86 CPU usage. Non-PC compatible x86 devices like PC-98 or PS4 exists, but obviously that’s never our focus.
By focusing on specific platform, development process on specific platform can be accelerated with strengthened collaboration. When the port on 1st chosen platform on that ISA is completed, public impression can be boosted. After that, we create different versions for different hardware, just like how RISC OS got independent builds for hardware like Raspberry Pi, Beagleboard, Pinebook, etc.
Consensus should be made for “prioritized platforms” for each architecture, depending on availability and amount of developers currently owning that hardware. Sponsorship from Haiku Inc. for purchasing development hardware will be preferably used on purchasing those items. Well, developers can also try their luck on other hardware, but they may gain less community support.
Also, just wonder, are the community still working on PowerPC?
Who is that “we” who decides what contributors to Haiku (who all work on their free time and have their own interests) should or should not do?
Also, this is what we have been trying to do, except the first selected target was the OpenMoko phone. Remember that? Yeah, no one does. And then it was the BeagleBoard. And then the Raspberry Pi because that was cheaper and easier to obtain, but the early versions of it were ARMv6 instead of ARMv7 like pretty much everything else. Now it seems to be QEMU which has gotten better over the years.
Anyway, the current issues appear to be with the MMU on ARM64. That is a standard component that is not different from one board to another. Once someone finalizes that part, and the port starts running, it will be much easier to add support for more platforms, sure. But before that, it doesn’t really matter which platform people are working on, they will pretty likely all fail at the same point.
The next one person who decides to worn on ARM gets to pick their favorite hardware. They don’t need concensus for that, and no one should tell them “no, please don’t work on that nice new hardware you already own, someone else has decided that older, no longer manufactured board shall be the first ARM target for Haiku, it can’t be anything else”. That would be very demotivating, don’t you think?
And ARM hardware these days (especially QEMU) is so cheap that I’m not sure Haiku inc support is even needed anymore. In fact, previous attempts to do this did not go well. I have inherited some of that hardware from the late 2000s, after several developer just gave it to each other and never really wrote any drivers for it. It turns out writing drivers for a system you’re not interested in actually using isn’t that motivating. Maybe if people were getting paid for it, it would be different.
4 Likes
Well, if the community have to decide the “prioritized hardware”, the process should be made with active developers declaring the hardware they own, and when enough amount of developers own the same model, they can group together and decide to start working on it. When somebody knows that quite an amount of people is working on the same item with them, they’ll have more confidence that others will tackle difficulties and make breakthroughs with them together, attracting more people engaging in the development of the platform. The process of making decision is done by an amount of developers. No one him/herself can decide the selected hardware for everyone in the community.
We are neither discouraging nor prohibiting developers to work on less known platforms either, just like how there’s only 1 developer working on LoongArch for now due to lack of Chinese Haiku users. But before they start working on it, they know that support they may receive is rather less, compared to popular platforms.
This not only applies on ARM/64, but also on RISCV or other ISA, while I have no idea on compatibility between different RISCV devices.
From what I saw on the forum, more than 1 members owns VF2 RISCV board and X512 made great achievement on porting Haiku onto it, while some others is trying to build Haiku for VF2 from source code. Will it be a potential “prioritized hardware” ?
We don’t even have one developer actively working on this currently. So there is no one to group together. And even if there were, the interested developer can, you know, simply talk to each other?
It’s the opposite: the community cannot decide what one developer should do and what hardware they work on. Unless they are paying the developer so they can tell them what to do.
Not more or less than any other hardware. It is hardware owned by some developers, as long as they don’t change their mind and keep using and supporting it, there will be some patches. When these developers decide to upgrade to something else, maybe support will stop.
1 Like
So, how do we get to R1? Here’s a summary of the thread so far.
Why release R1?
There are three things that we can reasonably expect from releasing R1:
- We’ll get media attention. This could help grow the project.
- We don’t have to hold ourselves so strictly with being backwards compatible with BeOS. That is, if we want to make breaking changes in the first place.
- We have an accomplishment that we can be proud of!
When should we release R1?
Opinions tend to fall along a spectrum
Let’s go over all four categories in more detail.
1. We’re done!
I like how @michel put it.
2. Polish it first
We just need to do some bugfixes and polishing of what we already have. No need to add too many more fancy features – that can wait for later.
3. Make it daily-drivable
There are several features that we should add before we release R1. People tend to have differing opinions on what new features are important to meet this goal and what features aren’t.
4. Make it competitive with other OS’s
Release R1 once it’s competitive with Linux, or, even better, Windows!
Ok, ok, I don’t think anyone actually has this opinion. I just needed a release philosophy for the other extreme end of my spectrum.
Patience!
Several people mentioned that, in the end, Haiku will be ready when it is ready.
What’s your opinion?
I’m curious what the general sentiment here is. Let’s do a poll! The results are, as usual, non-binding on the project. 
- We’re done! Let’s release R1
- Let’s fix bugs and polish what we already have
- We should add some more features first
- Let’s make it on par with Linux before releasing it
0
voters
How certain are you that what you chose is the best route?
- I didn’t really know which one to choose, but the one I chose appealed to me slightly more than the rest.
- I’m pretty undecided, but I think the one I chose is better overall.
- The one I chose is probably better than the rest.
- I’m almost certain that the one I chose is the best option.
- The one I chose is definitely the best option, no questions asked.
0
voters
3 Likes