I think, as the maintainer of bebits and haikuware, that releases, such as the alphas, and eventually R1, should contain the BeOSCompatibility package. It doesn’t make sense to make it an optional package. Somewhere along the line, Haiku dropped the ‘binary compatibility’ with BeOS phrase that graced their homepage’s description of what Haiku was and was aiming to achieve.
Probably >80% of the software (that Haiku’s User Guide links to these websites), is BeOS software, so why make the BeOSCompatibility package optional? Most users probably won’t even know it exists. They’ll then download BeOS software which likely won’t work under Haiku.
The BeOSCompatibility package adds support for BeOS items, like linking /boot/var/tmp to its new, Haiku modified location. A good example of an application that wouldn’t work because of this move is Caya, or PackageBuilder
Devs may read BeOS docs (because of the lack of Haiku docs) and code apps to adhere to these coding guidelines, and then their apps won’t work.
What is the logic behind making the BeOSCompatibility package optional? Secondly, why isn’t it available at: www.haiku-files.org/files/optional-packages/
BeOSCompatibility is just adding lots of symlinks, no additional files are added. It works like a script that runs to add in links to folder names which were used in BeOS.
For instance, Haiku removed beos folder. It used to be /beos/system but now is named /system. So, a BeOS application may look for /beos/system and then error out (not work) if it could not find (root) folder “beos”.
The issue is caused by changing folder names and moving folders around, like the new location of var. It was done to either show Haiku is not from BeOS code (remove reference to “beos” from Haiku filesystem) or to better organize folder layout.
Someone can create a similar bash script to run from terminal and make it available on Haikuware.
To understand what and how BeOSCompatibility does look here:
PS They expect 3rd party BeOS software to get updated to support new Haiku folder layout but not everything will and so good to create these symlinks to ensure BeOS programs work.
Thanks for the info.
Like you say, ‘They expect 3rd party BeOS software to get updated to support new Haiku folder layout but not everything will and so good to create these symlinks to ensure BeOS programs work.’
I think most developers are aware that a good portion of the older software is abandonware (even though some of the software may have purpose and be useful). So my point is, why not just add a couple symlinked directories in by default to ensure compatibility? Make them hidden folders if they confuse the new layout.
It’s contradictory in a way, to point to BeBits as a resource for software, and then not include this package by default.
Good point. Perhaps there are certain downsides that are not that obvious? The devs don’t seem to follow the forums very much, so it may be better that you ask on one of the mailing lists instead.
Sure, I guess there may be downsides that I’m not aware of.
In any case, I think it should be considered, and if not, then at least made very clear in the user documents where to get this package, and what it does (even though 90% of people won’t read the docs, which is why it should probably just be included).
Not trying to be rude, but repeating yourself here will not help, since the devs do not frequent the forums so they will thus not take notice. For anything to be considered, you have to bring it up on the relevant mailing list.
I have to say I agree with keeping this optional. Haiku is not BeOS. Haiku will have to move in its own direction. And if we need to use a BeOS application, then an optional BeOS compatibility layer sounds fine to me. It could even be extended to support more old applications. Fpse for example does not work in Haiku, and while I would love to just say “Update it!”, this will take time, and being able to use the original port would be good for testing purposes.