The default build of Haiku is dual-GCC, you can switch to GCC5 by typing "setarch x86" in any shell.
And the security model can't be helped if we want to maintain binary compatibility with BeOS - once we (mostly) drop that, we'll switch to something more sane in that department.
you can switch to GCC5 by typing "setarch x86" in any shell
Awesome, that worked. Thanks!
It's also great to hear that Haiku will eventually improve the security model. That is its biggest weakness IMO, and removing it will open a lot of new doors.
How long do you expect to maintain BeOS binary compatibility? I see in the trac roadmap that R2 is slated to be the deprecation point; is that still likely to be multiple years away? Has there been talk of an abi compatibility layer that would allow the kernel to move forward independently from the legacy platform?
Sorry if these are repetitive questions btw. I'm just curious.
Exactly how long is unclear; however, post-R1, we intend to stop prioritizing it, and if it does stay around, it'll be secondary to continued development. There's been serious talk of actually branching R1beta1 on January 31, so, hopefully soon.
The kernel already has moved pretty far forward. BeOS audio drivers, for instance, don't really work anymore in favor of our new multi-audio API (I don't think anyone had any use for BeOS audio drivers; we merged all the open-source ones, I think), the VFS layer has gotten major upgrades, we rewrote the thread scheduler and removed the 8-core limit we inherited from BeOS, and already have added ASLR and DEP support, among lots of other improvements. I think the only thing at this point which actually is still compatible kernel-wise are FS drivers (sorta) and graphics drivers (although of these, we have more in-tree than BeOS ever did, so I don't know if anyone even uses old BeOS ones anymore).
Comments
The default build of Haiku is dual-GCC, you can switch to GCC5 by typing "setarch x86" in any shell.
And the security model can't be helped if we want to maintain binary compatibility with BeOS - once we (mostly) drop that, we'll switch to something more sane in that department.
Awesome, that worked. Thanks!
It's also great to hear that Haiku will eventually improve the security model. That is its biggest weakness IMO, and removing it will open a lot of new doors.
How long do you expect to maintain BeOS binary compatibility? I see in the trac roadmap that R2 is slated to be the deprecation point; is that still likely to be multiple years away? Has there been talk of an abi compatibility layer that would allow the kernel to move forward independently from the legacy platform?
Sorry if these are repetitive questions btw. I'm just curious.
Exactly how long is unclear; however, post-R1, we intend to stop prioritizing it, and if it does stay around, it'll be secondary to continued development. There's been serious talk of actually branching R1beta1 on January 31, so, hopefully soon.
The kernel already has moved pretty far forward. BeOS audio drivers, for instance, don't really work anymore in favor of our new multi-audio API (I don't think anyone had any use for BeOS audio drivers; we merged all the open-source ones, I think), the VFS layer has gotten major upgrades, we rewrote the thread scheduler and removed the 8-core limit we inherited from BeOS, and already have added ASLR and DEP support, among lots of other improvements. I think the only thing at this point which actually is still compatible kernel-wise are FS drivers (sorta) and graphics drivers (although of these, we have more in-tree than BeOS ever did, so I don't know if anyone even uses old BeOS ones anymore).
64-bit Haiku would maybe be a good opportunity to fix the security model, but I've no idea how feasible that would be.
Not sure why you say that. It already exists, anyway: https://download.haiku-os.org/nightly-images/x86_64/
I say it as I wouldn't expect it to be compatible with 32-bit BeOS.