If apple was to buy beos source from access would it affect HAIKU at all
Is the beos kernel alot more developed than haiku
If Iâm not wrong, the only thing Haiku needed permission of Access for was the distribution of the BeBook.
Code parts used if any remaining where distributed with an open licence.
Haiku kernel was the first thing developed, itâs pretty good and doesnât need to evolve a lot.
Interesting things are whatâs around it, like drivers and servers.
And Haiku already supports more hardware, so you could say it is more developed.
Haiku devs could give you more precise answer but globally if code was bought and open, it would be certainly interesting to look how few things are done but it wouldnât be a revolution.
1 Like
Some of the devs worked at Zeta and had access to more of the BeOS sourcecode there. I think the source was also leaked publicly at some point. I never looked at it, but from what Iâve heard of it, the code was not very clean, which is not surprising and seems not too unexpected, for the following reasons:
- Be had to ship the OS quite fast. So they had no time to write super clean code.
- They were using very old compilers, most of the OS was written before C++ was even standardized. So they had to hack around compiler bugs in some cases
- They were working without git (which didnât exist), they had some version control system but it was certainly less usable
and so on.
Also, donât forget that this code is 20 years old and unmaintained. BeOS doesnât boot on machines with more than 512MB of RAM, or CPUs with SSE support. It of course canât run on 64bit systems. The OS has no localization, itâs in english only. There is no layout system in the interface kit, so apps have to use hardcoded coordinates, and usually will have all kind of problems if you change the font or font size.
I donât see why Apple in particular would be interested in it. Haiku is much more advanced at this point, and our code is also a lot cleaner and easier to maintain.
We use some code that comes from Be but it was released under open source licenses. This includes the Tracker, as well as apps like Pulse, and some pieces of code extracted from Be Newsletters examples. Even if someone buys the sources of BeOS, they canât change the fact that these old versions are available under an open source license. And even for these parts, we have rewritten quite a lot of them anyway.
6 Likes
All this is true. Also - what would be the reason to buy the code now? Apple has a few of the devs working for it (APFS was written in part by Dominic Giampaolo for example.) And Google also has a load of the ex-Devs, which is why Androidâs API started to look quite Be-ish. These devs are more useful thean 20 year old source code for a âdeadâ platform. There isnât much of anyone else that might want/care. Given how old the code is now, ho unlikely it is to run on modern hardware and the issues there are with licensing the components Be used for some of the subsystems (and the alleged GPL violations) - the code is probably not something anyone with any sense would touch.
Apple could fork Haiku OS
Since Atari is supposedly coming out with a new âconsoleâ (which is, as most consoles, an AMD-based computer), Iâd rather they drop Linux and move to Haiku. Iâve tried to put it on their radar, but nobody listens to me.
Also, even if someone bought the BeOS source code they wouldnât be able to open it all, since some parts were actually licensed from other companies, typically the font engine from Adobe, so they wouldnât have the right to open that.
Apple has chosen NeXT over BeOS 20 years ago. I doubt they would change their mind now.
3 Likes
I have heard they have also hired some key Be engineers along the way, who have probably implemented some very interesting features on macOS that can be seen as an evolution on BeOS implementation (Spotlight comes to my mind). So maybe Apple got both NeXT and Be technologies in one and a half shotsâŚ
There are former Be engineers at google also⌠part of there reason Android has openbinder which originated at Be it probably would have been part of BeOS 6 IPC in Haiku and BeOS 5 is an ancestor of this and not identical but similar.
The story for how Binder ended up in Android is I think a bit more complicated than that.
As you know, in 2001 Be was acquired by Palm. There, was the âCobaltâ project which integrated some BeOS technology with a new version of PalmOS. It wasnât ever used on any device I think, but Binder was probably part of it.
And when Palm went out of the PDA business, a part of the team probably followed on with Android. Actually a lot of the design decisions in Android make a bit more sense if you look at them with knowledge of PalmOS. For example, the use of Java while it has an image of being heavy and bloated due to the virtual machine. If you know that PalmOS apps were mostly 68000 code, but later on the devices switched to ARM and just emulated the old CPU, you see that the people who later on ended up working on Android knew that this was perfectly possible and reasonable, and would allow switching CPUs much more easily when needed (they probably thought âwhenâ rather than âifâ at the time - it turns out ARM is here to stay probably for quite a while, but they wouldnât have known).
2 Likes
Whatâs the point of stating in that way⌠you are welcome to add details, but I certainly wasnât intending to detail the history of OpenBinder just state the fact that of where itâs orgin is⌠and that is BeOS and it is also likely that BeOS 6âs Binder probably would have looked more like OpenBinder than BeOS5/Haikuâs Binder.
That said OpenBinder is much refined over the years and it may be a good idea some point down the line to merge some of itâs improvements back in say⌠for R2. Especially as many of the design flaws have been hammered on by many over the years. You could probably even still stay that OpenBinder is superior to d-bus⌠just due to being far more mature and stable.
There is no Binder in BeOS R5 nor in HaikuâŚ
1 Like
Not called binder but it is basically the predecessor to binder⌠so what is your point exactly? Itâs even been seriousl discussed that binder could be used to replace Haikuâs IPC down the road with something more modern but in a compatible way⌠people unwilling to discuss such things are just sticks in the mud frankly and will eventually be left behind.
Regardless perhaps you should just get the info straight from Eugenia an Ex-Be engineer⌠https://www.osnews.com/story/13674/introduction-to-openbinder-and-interview-with-dianne-hackborn/
@cb88 yeah, I said that above. The whole messaging protocol in android also is very, very Be like, except instead of a BMessage you have an Intent.
1 Like
@cb88 Binder came from BeIA, where it was used extensively. It might have crept in to Dano, I donât remember. OpenBinder was Dianne Hackbornâs thing, and that is why it ended up in Android with her. OpenBinder actually vanished from the Net at one point and it was only resurfaced because a few people asked after it and she made it available again.
The Stuff in PalmOS was a C based IIRC, so that is why Binder changed a lot between BeIA and Android.
1 Like
No, there is nothing like that in BeOS R5 nor in Haiku. The Binder design was made to fix problems found in the way BeOS does thing. In our case we have âportsâ in the kernel, and MessageReceived in apps. MessageReceived is annoying for two reasons:
- It lacks discoverability: if you want to message another app you can only guess which messages and parameters it will accept. âscriptingâ somewhat helps, but is also far from perfect.
- The MessageReceived function is extremely boring to write and maintain, wouldnât it be great if it could be done automatically and messages would call functions directly?
These are the two main problems the Be engineers set to solve with the Binder. But it never was integrated into BeOS, it was done when the company had alreadt shifted to BeIA (and itâs indeed mentionned in that interview - of Dianne Hackborn, not Eugenia - that the target was a 200MHz ARM CPU and that most of the work was in fact done at Palm. Yes, exactly what I said in my post.
1 Like
WhateverâŚ
There is also a problem that BHandler has no reference counting and cleanup when client team is terminated. This is handled by system servers like app_server, but there are no generic solution for Application Kit.
Its only missing feature is declaring arguments for B_EXECUTE_PROPERTY, anything other seems fine.