Why keep BeOS binary compatibility?

Hi,

I’m a computer science student who have been looking at Haiku for a very long time. I’m tinkered with it since the R1 alpha 1 in 2009.

I also had the pleasure to meet one guy of the Haiku project during the RMLL (Rencontres Mondiales du Logiciel Libre) in 2010.

Please forgive me if my question seems too naive, or if it’s a matter that you have to answer frequently, but as much as I am excited for any progress made by the Haiku project, I wonder why BeOS binary compatibility have to be preserved.

So far, it seems to me that this matter prevents the Haiku project of moving forward, since it has to rely on a mixture of GCC2 and other (usually GCC4, but apparently now it’s possible to use GCC7(?)), and makes porting Haiku on anything else than x86 32bit a curiosity because binary compatibility cannot be preserved when moving to a different architecture.

Reading the recent article “LibreOffice for Haiku, a not-so-short story” comforts me in my idea that BeOS binary compatibility gives little benefits to the project and holds a lot of things back.

Therefore I wonder: Since no one use BeOS any more, and since original BeOS software is both rare and architecture dependent, why keep BeOS binary compatibility?

Best regards,

Some of the actual Haiku devs may chime in, but I think that at this point in time, keeping BeOS compatibilty isn’t that much of a hassle. It’s been important at the beginning of Haiku and not so much anymore, but there is still gcc2 only software around.

For a user or 3rd party developer, it doesn’t matter at all. With a simple “setarch x86” you switch to gcc7.3 to compile your sources on 32bit Haiku. If you don’t care at all about BeOS software, just switch to 64bit Haiku and never spare another thought on it.

You may be right there, though I still prefer WonderBrush to any other graphics app on Haiku and love to play with SyncModular.
In a way it would be stupid, this close to the R1beta, to abandon a promise and technical achievement for little gain.

5 Likes

This is a good question, and I can’t speak for the project but the main reason I see to keep backwards compatibility is that it keeps us honest. Some people started this project a long time ago to create an operating system with the goal of maintaining binary backwards compatibility with BeOS and we are still continuing that goal today and we will continue along that path until we release Haiku R1.

Before LibreOffice was ported, the main Office Suite on Haiku was Gobe Productive: an old BeOS app. Only now are we starting to get to the point where these apps are being replaced with modern alternatives - and LibreOffice is a port, not even a native program. There have been several projects that have come and gone which have cut corners bring a next generation BeOS minus the backwards compatibility sooner such as BlueEyedOS, Cosmo, and to a certain extent Zeta. These have all fallen to the wayside while Haiku has kept going because of its commitment to authenticity, to doing the right thing even if that isn’t the easy thing to do. There are a bunch of old BeOS apps that have been brought forward and are quite usable on Haiku. Haiku really is the spiritual and practical successor to BeOS thanks to the binary compatibility.

8 Likes

For it is a clear thing. Haiku will be a open source rebuild of beos.

After r1 we can do what ever we want :slight_smile:

1 Like

It does not pose much problems (why do people keep assuming so?), and more importantly, it keeps us focused on a fixed target. If we didn’t have this, devs would always want to work on this or that new feature, rewrite a better interface kit, etc. But we already have a hard time stabilizing what we have.
If you don’t care about it, just install the 64 bit version of Haiku, which does not include any compatibility, and eojoy a modern system.

3 Likes

So now the question is: “When will R1 be ready?”. :stuck_out_tongue:

This question is so old like haiku. Take a look at older discussions in order to reduce this questions posts.

2 Likes