I am run on Fujitsu LifeBook A512. All hardware work fine…
I Have been running on VirtualBox for years, hoping for a usable release. Now that Beta 1 is out, I have managed to install it in my 2007 MacBook Pro and in my wife’s 2008 Macbook. There are still a few rought edges, but also some nice things to enjoy. I like the application launch speed. 
2 Likes
Always on hardware… never have aside from mame virtualised anything.
Currently running the nightlies on 2 apple laptops, c2d, and an i5 mbp… all work fine except for sound.
Main haiku box is a low power dual socket Opteron board with Audigy 2 PCI card. (Works perfect) with x850 xt and for anything that requires power I have a nforce 750i EVGA 775 board,Wolfie e8400 with 4 gigs of ram, and GTX 680.
I’ve probably got a few more boxes hanging around that I’ve booted haiku on, with mostly less success than the others, my 6 core daily 5,1MP for example, just blatantly refuses to boot Haiku.
At any rate, I am loving haiku64 ATM. Few issues here and there, mostly of my own doing no doubt, but just want to give a shout out to the guys and gals responsible for bringing this to us. AWESOME Job so far guys. Very proud of what you guys have done.
2 Likes
This is because you are using Framebuffer driver , not VESA
I currently have Haiku installed as a secondary OS on a Medion Akoya E7226. Everything except the “Wifi” and “Intel HD” works. It is running the development versions (nightlies). The notebook boots the 64bit Haiku builds trough EFI which needs a bit of a workaround on this machine.
I completely purged windows from the machine to boot a Linux system or Haiku, but the UEFI has been hardcoded to ignore EFI boot files unless it also finds a real or faked windows “.efi” file.
The user can take a Linux or Haiku “.efi” boot file, rename it to the windows “.efi” filename, and place that file in the windows folder structure for EFI booting:
/EFI/microsoft/boot/bootmgfw.efi
I can make it boot anything, in any order, for as long as secureboot is disabled and the UEFI can find the “windows” efi loader… which in this case is a renamed “.efi” file from another OS. It will literally autodetect any other efi loader and provide the option to change the boot order. Delete the fake or real windows efi file and it will completely ignore and block every other efi file. It’s a really weird and failed attempt at forcing windows upon the user.
Edit: Adding this to be more correct.
- Intel Extreme driver is broken on this Intel HD chip
- Webcam does not work
- SD card reader does not work
I run Haiku on bare metal, but not by choice, my ability to develop Haiku on a macOS host stopped working after High Sierra came out and was never fixed. Then Apple disabled the ability to build 32-bit apps on Mojave making Haiku development even harder, then Apple disabled even running 32-bit apps in Catalina making Haiku development nearly impossible. So now I develop Haiku on a Lenovo Thinkpad X220 and my MacBook Pro with much better specs and a vastly superior monitor sits there unused most of the time.
Building Haiku does not need running or building 32bit apps. The host tools will be 64bit if your host OS is 64bit.
The filesystems/case sensitivity problems still apply. But you could run Haiku natively on your Mac, too 
Only 64-bit Haiku and only if the build system was fixed… I tried fixing it but the solution is beyond me. The crossed compiled gcc on macOS absolutely refuses to #include <string.h> no matter what I do. It’s suspected that this has something to do with case-sensitivity but the problem is not at the file system level.
You think Haiku would boot on my 2019 MacBook Pro? From everything I’ve read that will not work. It’s too new and too Apple. Who wants to use Apple’s butterfly keyboard anyway when you can use the vastly superior IBM-designed one on the Lenovo Thinkpad X220. I did some research and the X220 is pretty much the best laptop you can get to run Haiku based on the keyboard layout. You could get an X230 and then hack the old keyboard in but that only buys you Ivy Bridge over Sandy Bridge which doesn’t get you a whole lot. My Lenovo X220 has the fastest i7 available soldered in and 8gb of RAM so there’s pretty much no reason to ever upgrade it. I’m not above buying a new machine to run Haiku though if one becomes available that works better.
I tried to run haiku on my AMD Phenom 2 rig but no matter what when its time to start the desktop interface it hangs, because of the radeon HD 5750, and no safe mode graphics options resolve it. Haiku runs mighty nicely on my dell precision workstation 530 though with a matrox millenium card and its dual ht xeons.
I have only been able to use a temporary workaround for the #include <string.h> issue just by actually forcing macOS to find it by replacing every instance of #include <String.h> with #include <../os/support/String.h> and keeping a patch file of this to undo it later.
For understanding why macOS cannot find the correct headers for String.h, I don’t know yet and this workaround should never been seen as the solution. But it can be used as a way to find out which part of the build system is broken under macOS.
Bugreports, please 
No, you can build a 32bit Haiku from a 64bit OS. You only need to generate 32bit executables, and you do this using our own compiler. All the host tools will be 64bit. But you are right, you will probably run into problems building gcc2 using clang or something like that.
Unlike some others, I don’t consider it to be a bug that Haiku doesn’t run on whatever computer you try to stick it on, we’re not Linux or Windows we don’t have to support every piece of hardware under the sun, we should focus our efforts on making a few key pieces of hardware work and then direct people purchase supported hardware. I’m not saying that we should restrict people from contributing drivers for hardware that they own so that Haiku will run on their machine, just that it’s not a realistic expectation that Haiku will run on a the wide variety of hardware that’s available given the limited resources we have to spend - especially when we’re talking about Macintosh computers where Apple has made it purposefully difficult to write drivers and to get any kind of documentation on the components used by pressuring the component suppliers to restrict that information.
Yes, I (used to be able to) build gcc with the system clang on macOS and then build Haiku from the gcc I built. Since I can’t build 32-bit gcc on macOS Mojave I also can’t build 32-bit Haiku. In general you can build a 32-bit Haiku from a 64-bit OS, just not on macOS Mojave or later at least not without cross-compiling your own custom clang binaries from High Sierra to run on Mojave because Apple made it difficult on purpose because they hate 32-bit (and are probably laying the groundwork to switch Macs to use their own custom Arm processors with dynamic recompilation software that doesn’t handle 32-bit x86 code.) It’s not impossible that Apple changed some library somewhere to be read header files in case-insensitively in order to try an mitigate bugs for applications build on case-insensitive HFS+ so that they’ll run on case-sensitive APFS but I haven’t actually found that to be the case.
Yes, but that does not prevent tracking the issues. It’s good to know where we stand in terms of hardware support. Also, I think restricting ourselves to few machines would make Haiku a lot less popular. Telling people that they have to buy a computer specifically for Haiku is not an affordable solution for everyone, and supporting several different configurations (laptops and desktops, lightweight or more powerful machines) is also a good thing. We can’t handle all the hardware out there, but we should track where we’re lacking and then see if someone wants to improve things, and also decide which hardware is popular and should be focused on first.
If we had focused only on the X220, for example, we’d still not have any USB3 support, and moving to a newer machine when the time comes would be significantly more difficult. So there is a balance to fine here.
I’m not telling people that they have to buy from a few machines, but that they’re on thier own for drivers when they deviate from the hardware that we support. My X220 does have USB3 support! I have 1 blue port and it works, I can even boot from it.
1 Like
Why not at least try? Haiku should boot on Apple hardware by using UEFI. Even if you consider running Haiku on this hardware not useful, another people may have same hardware and want to have Haiku on it.
1 Like
Ok I tried booting from a USB stick, it wouldn’t even recognize the USB stick as a boot-able device.
Actually there is a ticket about newer-model Mac hardware having random kernel panics after boot; and you need to use rEFInd/rEFIt to get it to boot in the first place.
yeah, Microsoft purposely forced that Medion Akoya Something to do that. that Akoya constitutes the biggest part of desktop computers and Microsoft is Evil(C), preventing the year of linux on desktop to materialize. 
think it’s easier - they, firmware providers, just made a crappy firmware because they didn’t care to bother. since vast majority of users use Windows, they didn’t care about all other OSes. that is not rare and not always related to Windows - the same way, SoC vendors for set top boxes, phones and tablets only care about android, when making their BSPs, the same way uboot is so linux oriented, that it barely makes it a normal firmware, rather a sh1tty loader.
On topic, I don’t like virtualization technologies, so interested in only real hardware testings. My machine, that could test Haiku (among other things) is Asrock G41C-GS R2.0 motherboard with G41/ICH7 chipset, with integrated Intel graphics, 2 GB of DDR2 RAM, and Core 2 Duo E8400 3.0GHz. but now it lacks power supply. 
And unfortunately, it’s not UEFI. since that would be very interesting to me, I am a UEFI “enthusiast”, could even try to do something in that direction. something means “os loaders”.
1 Like
MSI Wind U100 netbook