There is still no easy way to install HAIKU alongside Windows or LINUX!
BeOs had the option to install and run on a Windows install!
There are tools to make UEFI entries and bootable devices.
It should be very easy to get HAIKU installed, booting and running!
Automatic install and UVC-Webcam are missing.
My two cents, as a humble user and a programmer (but with zero experience on designing operating systems, and I’m only at the beginning of - slowly - learning Haiku’s API):
I voted for 2 for the following reasons:
People saying “Haiku is awfully close to be a daily-driver OS” are right. Of course, that depends on how you define a “daily driver”. Sure, it’s not ready for that if you are a gamer. Sure it’s lacking things some people will find important. But guess what, whatever you do, people will complain. No matter how you emphasize the current status of the OS is “beta”, people will test if for everything, and if they find the slightest flaw, they will complain about this and and that. Reviewers will “test” it according to their needs (usually video editing, video playing and maybe Office apps, raster graphics editors). This is far from being a fair test, but that’s what they’ ll do. No matter how much you emphasize this is beta they will try… Minecrap and other games, then they will complain just because their expensive rig (with a monster GPU that needs proprietary drivers to perform correctly) can play games better. You cannot and you will not make everybody happy.
I’m not quite sure what’s the intended “target audience” for Haiku (but I’m sure it’s not just BeOS enthusiasts). That’s up to the developers, who spend a lot of time and efforts to make this happen. As a humble user, I am just saying, fix whatever it’s already there but needs fixing (that alone will probably take a few betas more). Then it’s time to call it R1.
As this topic is about “how to reach R1” and not a “feature wishlist”, this is my opinion:
Focus on bugfixes and throughout testing to smooth the rough edges off it. New additions only if it’s absolutely necessary to the user experience, or else, new device drivers.
Make quarterly beta releases, even if they do not contain a lot of changes, so the stairs don’t contain few but too tall steps, and instead it has a lot of short but easier to walk up steps. And create a manual/whatever to make the users with less knowledge help with finding bugs and reporting them easier.
Make the promotion team active again so it can spread the word of Haiku. And to have more contact with the wider open source developer communities so in some aspects there could be shared collaboration (such as with device drivers).
Increase the donation target to not only cover the basic expenses (infrastructure) and the only paid contractor, but to also add a second paid developer to advance even further and faster.
Convert the UEFI thing into a proper haiku boot manager, is a great idea i think, i suppose some developers thinks too, and the uefi boot working from CD/DVD (which i think is not working).
Wait, wait, wait… I thought we were using a fork of NewOS, the microkernel written by Travis Geiselbrecht, who also wrote the BeOS kernel. Did I miss something?
Yes, you missed a few things:
If you want microkernels, you have to look at QNX, not any BeOS related thing.
Ha ha, that’s the first I heard about “modular monolithic”.
Maybe part of the “microkernel” perception is that when you look at what’s running, there’s all these servers - app_server, input_server etc. - which is diagrammatically reminiscent of the microkernel architecture.
Those servers have little to do with the kernel architecture and there is a similar setup on Linux: app_server is equivalent to the X11 server plus a window manager, etc.
Or open source Managarm for example: GitHub - managarm/managarm: Pragmatic microkernel-based OS with fully asynchronous I/O.
Yes, that was a bit unclear, sorry: if you want to look at microkernels from the 1990s, you can go to QNX. At the time they had a single-floppy distribution with a GUI that made people somewhat interested about it. This is what Be (and Microsoft) marketing were reacting to with the “monolithic modular” thing.
There are a lot more microkernels around, of course, some newer, some older than that. This also includes for example lk (little kernel) and Googne Fuchsia, both also designed by geist after his work on NewOS. He said (in discussions on Haiku IRC channel) that these are fixing Be’s mistakes of not doing a microkernel, whereas his work on NewOS was just reproducing Be ideas (the exact quote is “I was drinking the BeOS Kool-Aid”).
On our side, we’re still doing it like BeOS did, for the most part.
In general what is old Be APIs being used, when 64-bit Haiku is not binary compatible anyway. Why being scared of change
Most of the OS runs on APIs that come from Be? The basic IPC primitives (ports, semaphores, etc.), all the Kits (the Interface Kit GUI), etc. We’ve extended these where we can, but in many cases adding more security would require breaking changes to the API. And the 64-bit version isn’t ABI compatible, but it is API compatible for the most part, and diverging the 32-bit from the 64-bit here would mostly just create more work.
Is not ABI compatible but if you have the sources for any old beos application maybe easily portable.
I think that hard breaking API is not needed to implement secure IPC. Some programs may break, but most programs that don’t do strange things should be still possible to keep working after extending API for security (port_id permissions etc.).
Havig two differnet API v1 and v2 could extend 64-bit without issue, huh?
If you change the API, the new API will need to live along side the old one because that is just how this type of stuff plays out. 32bit would need the old API for compatibility. If you remove the API in 64bit (or even just use it there even if the older API still exists) you immediately make 2 code paths for the same functionality. Depreciation needs to be handled well and deleting an API is never the answer.
Im not a sofware engineer but in webdev you can use API on like this /v1/getInstance("","","") /v2/getInstance("","") , Im sorry but more work will likely Be needed.
That’s really not comparable in any way at all.
You will end up with a lot of cruft and duplication doing it that way.
The best way would be to create a while new library eco system around a Haiku namespace. But that would be a massive undertaking. You might then actually be able to get some backwards compatibility in. You really want 32bit and 64bit to be in parity. But 32bit needs to maintain backwards compatibility by design.
I second this, back in the last days of Be I remember they offered BeOS as an application that could be launched from Windows to convince people to try it in a non destructive way (Unlike Linux). Today we have live USB’s which are a really great way to give a sneak peak but it might not be a good representation of speed that could thwart away users.
My two cents regarding R1 are this, I know they are way easier to say than do and probably won’t happen:
The installer should be able to defrag (mechanical drives) resize and move partitions to make room for Haiku-os, also save a backup of the boot information that can be used to restore the system if something fails.
Also it needs to install rEFind by itself, the process right now is not friendly.
I have tried Haiku in all my hardware and the network and trackpad always has issues (I know it depends in many cases of the manufacturer support)
When I moved from Windows to Mac in the 2000’s virtualization helped a lot, many tools were not available and virtualization allowed me to fall back to Windows and keep my productivity.
Haiku has no multiuser which I honestly believe is underused this days but we need a way to secure certain things inside the system like having a password manager, securing the browser history and cache and maybe having password protected and encrypted folders if protecting the whole system is beyond the current capabilities and time.
Critical software like E-Mail Browsers Password Manager and anything that deals with personal information should be included and marked as part of the system to provide some peace of mind. Security by obscurity is dangerous this days and Haiku-os despite being a “hobbyist” “obscure” OS could be also targeted by criminals.
This is lacking even in Windows and MacOs. Beside drivers for both wired and wireless gamepads the system should include a panel to keep track configure remap buttons adjust sensitivity of gamepads and Joysticks. I’m not sure about licensing but it could be based on SDL since the last version seems to have everything needed.
As much as I would like to have games on Haiku this is not going to happen anytime soon. Video Card drivers and 3D acceleration are a huge undertaken. Currently Linux has advanced a lot yet people are not moving in droves away from Windows particularly due kernel–level anti-cheat software that’s not going to be available anytime soon on Haiku. I think in this regard R1 could do certain things like defining API’s and system panels ready for someone to continue that development separately. This reminded of how BeOS didn’t have a network stack and years later it was a problem getting it to connect to internet after Be shut down.