I'm still discovering what's going on with this OS. Apparently we can install VMWare tools. It's been over 15 years since I've touched anything to do with BeOS but in the words of Celine Dione.. It's all coming back to me now
Incredible progress, very cool! I used BeOS back in ‘99 and loved it. Applications were straightforward to build with C++ and the BMessage system. It had a great little community, even in Germany (“BeGeistert”!).
Does Haiku run on ARM nowadays?
The Application Server is in progress, but it builds. The problem is that on x86, you can fall back on the BIOS w/ VESA to display video; while ARM lacks that functionality. If you can find/build a video driver it should Just Work(tm).
Err ... no? The problem with the ARM port is the lack of device drivers, and the fact that there is no userland/syscalls ABI set up yet at all. So there's still a lot to be done here.
It was built with threading in mind throughout, which was unusual for the time. Remember, it took until C++11 until threads became part of the language.
Loving how they list Pentium II as a minimum requirement. I still have an old netbook with Intel Atom that I use when travelling to certain parts of the world and while it is clocked at 1.6 GHz and has 2 GB of RAM many of the modern Linux desktops are extremely sluggish.
Haiku would definitely bring it to life. I had a similar Atom based netbook and it was a perfect Haiku machine. I also have a PIII based laptop from 2000 with 512MB RAM that runs Haiku (and BeOS 5.0 Pro) extremely well.
Good news. I'm just about to try it on my Asus eeePC 701 4G, I've upgraded the RAM to 1Gb and have an 8Gb SD card for additional storage. Fingers crossed!
I have an eee 701 --- there are graphic driver problems but it works find in safe mode. (I think there's something weird about the eee's smaller-than-normal screen.)
Incidentally, I recall the early eees (like mine) having a faulty SD card slot and were unreliable writing to SD cards. Real MMC cards work fine. But that was years ago, so maybe there's a workaround now.
Thanks for the graphic driver tip. I've never had an issue with SD cards, but the 4G is (I think) the last iteration of the original 700 series, so presumably it was fixed by then.
This is a very faithful reimplementation if BeOS, which means it shares one unfortunate limitation with it: The lack of drivers.
Already back in '99, not leveraging 3D hardware was a problem for adoption. These days even more so, as not only 3D software but also 2D, audio and scientific software leverage GPUs.
There has been discussion [0] on porting FreeBSD's linuxkpi framework to get Linux drivers working on Haiku. So far I do not think anyone is actively working on it, but it would be a very similar solution as was used to get FreeBSD's networking drivers working on Haiku.
That would be wonderful. If I could get OpenGL support for current generation NVIDIA or AMD hardware, ideally with OpenCL or Vulkan too (CUDA is probably too much to ask for), I would even be able to use Haiku for my daily work.
I wonder if it would be worthwhile for small OS projects like this to pivot toward running on the Raspberry Pi instead of on generic PC hardware.
The downside for Haiku would be that they're giving up on the original goal of maintaining binary compatibility with original BeOS software. But that ship may have largely sailed, anyway, with the decision to go 64-bit.
The upside is that it would reduce the number of different hardware devices that they would need to support in order for people to perceive it as useful software by approximately 5,367 orders of magnitude.
(Well, that and a bunch of rework to get over to the different hardware, ofc.)
Back in the day, BeOS was smaller than the size of some modern web pages. I wonder if this could be leveraged with WebAssembly to have completely portable operating systems?
I know that even BeOS 4 came on CD, and I think the free PE version of BeOS 5 was about 50 Mb (although that might have been a virtual hard disk image? It's been a few years...)
From what I've read in the release notes, Haiku uses GCC version 2 for ABI compatibility reasons. Can anyone elaborate on whether this is the case, or whether modern GCC can be/has been modified for the OS to maintain binary compatibility. Also, what is lost in this case?
There are two versions of Haiku, the hybrid 32-bit version uses the older GCC for compatibility with software written for BeOS, plus GCC 7.3.0 for modern app support. The other is a 64-bit release with only the modern GCC and no backwards compatibility with BeOS apps.
First, to add to the parent comment, you can install later versions of GCC on the x86 gcc2 builds as well. There is also a port of LLVM.
Second, not directly related to what changed with the ABI, but it I think it would be more hassle than it is worth to try and make newer versions of GCC emit compatible binaries. There is work to run Haiku GCC 2.95 libraries alongside binaries built with a newer version. The runtime loader would be responsible for picking the correct so files. This also would work on the x64 builds as well, similar to how Linux (and others) can load x86 programs on x64 OS's. This feature is close to working but there were some last minute issues found, so it was left out of the Beta.
The GCC C++ ABI got a major overhaul in 3.4 so any C++ API won't be compatible. There may have been more platform-specific ABI changes too, I know mingw had one in the 4.x series.
It's a very lightweight single-user OS with an excellent GUI and a Posix command-line environment (i.e. bash, make, gcc etc).
It's not a server OS, and it's not particularly secure, so it's not a particularly good choice in any environment where it's faced with the outside world: it assumes that you own the machine, trust it, and control what software runs on it. Remember it came out of the DOS and Win95 era.
But it's really good at giving you a comfortable Unix-ish development environment on old Pentium-grade hardware which Linux struggles on.
Watching the 97 demos of multithreaded gui and decoupled subsystems (could change rendering parameters on the fly for each different screens) I was as sad as moved. Quite a peculiar bit of history.
Same dev team does whole stack, from kernel, kits, drivers, servers to user space. In theory, it is all integrated and has direct path from server to kernel, resulting in more efficient system.
BeOS core API was designed for multi core systems from day one, so the design is more modern than older systems.
The core API is C++, from kernel to user space.
Lots of things to like, it just needs more polish and devs to flourish.
> Same dev team does whole stack, from kernel, kits, drivers, servers to user space. In theory, it is all integrated and has direct path from server to kernel, resulting in more efficient system.
Except, while that's often what the blurb says, the implementation is typically paste in whatever somebody else wrote and call it a day.
For example years back Haiku announced it was going to have WiFi. Its own WiFi stack, far more integrated and reliable than things you were using on other systems. Very exciting.
And then as a "stop gap" it pasted in FreeBSD's PCI 802.11 driver subsystem, and the WPA Supplicant you've seen on all your Free Unix systems. And that's where they stopped. Last time I checked they had a version of WPA Supplicant vulnerable to KRACK but I'm sure they'd updated for the Beta.
How does their "integrated" solution handle your WiFi credentials? They use the powerful Haiku "KeyStore" password protection system. Here's how that works: You write the plaintext password into a file. Don't worry though, in KeyStore they wrote "TODO: Actually encrypt". Which I think you'll agree is almost as good as using encryption ?
> BeOS core API was designed for multi core systems from day one, so the design is more modern than older systems.
More modern is relative. "Older systems" in this context is stuff from the 1980s, because BeOS is roughly the same age as Linux, started in 1991.
However in Haiku you won't find anything like IO Completion ports, or futexes. You won't find any privilege separation because everything runs as "root". Everybody else moved on and Haiku is stuck being really quite good by 1990s standards.
That was 1991 Linux. Modern linux has moved much further than the original implementation, introducing all kinds of non-old-time-UNIX concepts (starting from Plan9 ones).
In general I don't know enough to disagree, but keep in mind the context here is comparing to Haiku, which is not great at security, particularly of the multi-user sort to which you refer.
You can, although the instructions published actually result in you still being root (and using password authentication, erk)
However, privilege separation doesn't really work, even if you go out of your way to become a genuinely non-root user, you can still read, modify and replace system files for example.
> You can, although the instructions published actually result in you still being root (and using password authentication, erk)
Huh? Maybe this was true on alpha4 (I have no idea), it certainly isn't true now.
> even if you go out of your way to become a genuinely non-root user, you can still read, modify and replace system files for example.
Root can't even replace system files anymore due to packagefs; but in general, there was a massive refactoring and cleanup of the VFS layer between alpha4 and beta1 which means filesystem permissions are actually enforced now.
Following these instructions resulted in me connecting to the Haiku machine as root (named "user" but with user ID zero and thus root rights). I was able to "kill" processes run by the desktop user and so on.
> Root can't even replace system files anymore due to packagefs
While packagefs prevents a naive user from being able to modify their system files, it actually makes it easier for an attacker because you can just add a package to modify things or remove one that's in your way.
Even after creating a separate non-root user and logging in to that rather than the root equivalent user, I was able to continue manipulating the system in this way without trouble, at first removing documentation in the desktop user's language and then gradually replacing software with my own.
> Following these instructions resulted in me connecting to the Haiku machine as root (named "user" but with user ID zero and thus root rights). I was able to "kill" processes run by the desktop user and so on.
Well ... yes, because you set the sshd to allow root login, and then logged in as the root user. This is the intended behavior, yes? You can leave that option off, `adduser`, and then log in as the new user instead.
> Even after creating a separate non-root user and logging in to that rather than the root equivalent user, I was able to continue manipulating the system in this way without trouble, at first removing documentation in the desktop user's language and then gradually replacing software with my own.
Hmm, well, that is a bug then; last I tried I thought this was impossible. Perhaps the directory permissions on /system/packages are incorrect.
I just had an idea to use KVM and PCIe passthrough to piggy back windows driver support for Vulkan into a PCIe device running in Haiku so Haiku could use the latest graphics cards w/o having to write their own video drivers. Bonus points for implementing mmap across to guest OSes. There should be a generic hardware description for a Vulkan based paravirt PCIe graphics card. Then the backend of the pvirt GPU could either pass it through to the driver, send it over the network or re-translate it on the fly to AVX, WebGL, etc.
Because the first question that popped into my head was, "How do they enable modern GPU support?"
I have never used VMWare to run Haiku, but it should run. I use VirtualBox and the one thing that I have to do is switch the network driver to the Intel Pro device to get networking working. So with VMWare you might need to do something similar.
Totally, but I've had the best experience using KVM over VMware or VirtualBox. They have built in a lot of support for virtio hardware so KVM works very well.
They tried buying BeOS, but the BeOS people absolutely refused to sell out to a company like Apple. NeXT was their second choice, and they succeeded in buying it (NeXTSTEP became Mac OS X).
IIRC, Jean-Louis Gassée named a price that Apple was unwilling to pay. I don't know his motivation for doing that - was it all about the money? Or was it to stick it to Apple and name a stratospheric price as a way of sending a message?
Jean-Louis Gassée is an ex-Apple executive. He's why Jobs left Apple. For him the point of Be Inc. was to show Apple they'd been wrong to subsequently get rid of him in 1990.
When Apple were looking at BeOS / NeXT what they were really trying to decide was whether to have Jobs or Gassée back. They picked Jobs.
After Be, Inc. sank JLG arranged to run Palm's software spin-off. This produced the version of PalmOS that's remarkable because instead of being used more palmtop devices than previous PalmOS versions it was used in none at all, even the Palm hardware company never used it.
IMO Gassée would be nobody you've heard of if not for the fact of his being in a position to force Jobs out of Apple. Everything else follows from that.
Loved a BeOS when it came out but is not the whole concept outdated now? C++ all over the place seems like a bad idea for enabling the usage of other languages as C++ is terrible at interoping with anything. Multi threading all over the place BeOS style does not seem like way concurrency is done today with higher order APIs.
