Has Haiku abandoned BeOS compatibility?


#21

Oh, and one more thing, the file attributes is completely broken in 4.1. That really topped it off for me. Add attributes, search and get nothing. It’s not the future, in my opinion. It’s too easily broken and hard to find the bugs in it. Who knows if it works? I would not trust it after the small amount of user testing I did. Perhaps, after all, the best place for file attributes is in each file, as is the case with more modern audio and video files formats. Calibre, the document manager application, has solved this nicely for PDF and similar documents by embedding them in the text after the cover image. At least then you know they are there and you havent lost them somewhere in “File System Space”. That’s real creative design, in my eyes.


#22

The “race” to R5-equiv. has already been met. What can BeOS R5 do that Haiku cannot do? If stability is an issue, is it because there is other stuff Haiku can do (beyond R5) that is causing the issue? The problem is, the goalpost keeps getting moved further down the road, people add this and do that and “things” keep popping up, to delay the progress to Beta, as more tickets needs to be closed, to reach Beta.

Needless to say, the fact you CANNOT boot/run BeOS R5 on the newer systems is indicative of how much better Haiku is than BeOS R5. The fact we have wireless (Wi-Fi) networking and SATA drive usability, and video cards and newer motherboards, etc. ad infinitum. However, I wonder… will Haiku actually still (it used to, waaaaaay back) boot/run on any of the old systems BeOS R5 DOES run on? Or, has it so far outgrown “old technology”, that the new stuff is all it WILL run on? I have an Athlon XP motherboard with 1Gb of RAM. Can’t boot R1A4.1 (yeah, THAT old version) on it. Is 1Gb no longer an acceptable amount of system memory?

I believe the “BeOS R5” goalpost has been so far blown past (or is 100% binary compatibility constantly being broken by progress?), that it is a mantra only followed in word, not deed. And it is because of that, the risk of never reaching R1 exists, because there will always be “one more thing” someone adds or changes that creates another dozen tickets to delay it that much longer.

If this is not the case, I’d like to be proven wrong. Really. I love Haiku, but I still can’t yet use it to replace Windows or MacOS X for every day usage and I so dearly would love to be able to.


#23

you can’t get a live feed from a camera into it yet. at least, not over usb. dunno if anybody’s tried ieee1394 or ethernet, but neither of those get used in streaming, anyway. there isn’t much support for capture cards yet, either. so, in a crucial area haiku’s still not caught up, but that’s not important – literally the only thing left to do before beta is getting the automated updates working, and that’s coming.


#24

Printing support is broken.
Media encoding is broken.
Webcams are broken, but BeOS didn’t support USB ones either, I think.

These are the few things I can remember, but by browsing the bug tracker you can see many pages of other problems. So there is still a lot of work to do before we reach R1.

This does not prevent working also on new hardware support, otherwise Haiku would not be useful to anyone.

And yes, the project has been in the works for 16 years. Our release cycle is different from Linux, which has a “release early, release often” policy. We prefer our releases to get a lot more testing, and more long-term support.


#25

it’s good policy.


#26

Can you explain what caused printing/media encoding to become “broken”? That implies it was working before. If you keep advancing the “technology peg”, it will never end, because technology never will. And, with a lot of those technology “increments”, it may break older/other things (more support tickets!), setting back progress towards Beta/R1. There must come a time when you say “Enough!” and freeze the technology “upgrades”. Stop the addition of “new stuff” and simply perfect what you have. I am more than certain that point was passed several years ago.

BeOS R5 never had package management. Never had automated updating. Never ran on SATA hard drives. Never ran on multi-core processors. Never had Wi-Fi networking. On and on. All this “new” stuff has NOTHING to do with “R5 binary compatibility”. But I bet you, it BREAKS a ton of it, in the process. Am I wrong? And for every break, more tickets are created to fix stuff. Which delays progress towards Beta/R1. And the beat goes on.

As long as the current “state” Haiku is in, keeps changing, you can’t reliably stabilize and perfect the current state, because it’s always changing. It’s like trying to drink a glass of water, just as it turns to vapor, then trying to condense the vapor back into water, and it turns to ice! You try to use the ice cubes and they turn back into water! It would drive you insane! You could never use the H2O, because it never stays in any one state long enough to actually use it!

“R5 binary compatibility” is about being able to run BeOS R5 apps in Haiku, am I right? If those apps expect certain hardware/code to be a certain way and the environment is not as they expect, they will NOT run, am I right? And, so, will they EVER run, if the programmer does not recompile them for the new OS/hardware environment? If the programmer has moved on or dropped support, then how can those apps EVER be expected to run, unless someone else takes the source code and recompiles it? If there is no source code, then the “R5 binary compatibility” goal post has been obliterated. How many R5 apps must run for the goal to have been met? If 100%, it’s a lost cause. 75%? 50%?

At some point (if not reached already), Haiku will have changed so much, almost nothing from R5 will run on it… and no one will probably care… because they will have moved onto what Haiku now IS, not what it once claimed it wanted to achieve.

My personal thought is that the whole “R5 binary compatibility” goal was a nice starting point to rally behind, but in the course of events (and over the years), it became more and more irrelevant. R5 compatibility is LEGACY. It’s “backwards compatibility”. It’s nostalgia. It’s… “cruft”. To keep chanting that mantra is only for the foolish. It’s time to stop fooling ourselves and move on with Haiku.

Haiku is so much more than it started out as… we need to stop following the “vapor ghost” of R5 compatibility and simply strive towards a finalized version of Haiku R1. But that will never happen if we keep endlessly changing the environment. Stop rearranging the walls and rooms and finish building the house! Remodel the house AFTER it’s been built, not WHILE it’s being built! :smiley:


#27

Haiku64 bit version no R5 should not require 32 bit compatibility. Apple and Linux many versions have dropped 32.


#28

AFAIK printing/media converting was a big, ugly hack, to clean things up some breaks expected here and there.

Right, they have nothing to do with R5 compatibility, and that’s why they cannot break it, as no BeOS program tries to use them magically. They breaks, but not the R5 compatibility but the whole Haiku ecosystem. It is also expected.

Ofc, Haiku shouldn’t integrate any new stuff, just stay on the BeOS level for R1.
Then there were no new stuff, to make hype, to generate interest and there were only angry peoples, who cannot install Haiku on 5 years old laptops, because you know what? BeOS had no support for them either.
There were bugreports and scandal, why to investing manpower in redeveloping and aged OS without any new and exciting and earth-stopping stuff like 1+ core and stuff!

And : it actually happened.

Check Gobe, it also runs just fine on gcc2h, it isn’t magic.
The goal already met.

Can you please point the broken BeOS apps?

Luposian, let us makes this clear: you are frustrated about the developing progress and direction. You don’t want to see any BeOS compatibility, right?
Then bite the bullet and install the 64 bit version, you won’t get any BeOS compatibility stuff, just the newest things.

What the devs doing with his free-time, isn’t our business. We can give tips and ideas, but that’s all. If you doesn’t like this, then start developing stuff, the guys at the IRC are really friendly :slight_smile:

You know, after something released, one supposed to support it…

Best regards,

–miqlas


#29

The goal of the project is recreate BeOS but with the needed improvements to works on new hardware, and being a viable desktop option. To get this, you need to improve the S.O. to the actual needs: WiFi, multi core CPU, SATA, etc.

Without this, we only could run Haiku on legacy hardware or only a few specific boards (like AmigaOS or Morphos, for example).

I started with the old BeOS 5 PE, and despite all the good things, It was far from perfect. Specially talking of hardware support. (do you remember the 1 GB RAM limit, or the old network stack? :slight_smile: ).

And finally, talking about R5 compatibility, I have some old software (GoBe, HotEdit, CLamp, SoundPlay, APlay, etc.) that runs perfectly on recent Haiku builds. And really, I didn’t remember too many regressions in this topic.


#30

There are many reasons for binary compatibility. Running R5 software is only one of them and at this point, clearly it is not the major one anymore (thanks to the great work of HaikuArchives for example).

So, why is binary compatibility still relevant?

  1. The technical challenge

Being able to do this is a cool technical achievement. Ignoring binary compatibility would have been a less ambitious goal. It is the way AtheOS, then Syllable, went. It is the way BlueEyedOS went. It is the way Cosmoe went. Of the BeOS legacy, only one project is still alive: the one that was exciting enough to attract the most skilled developers of the Be days (and no offence meant to the devs of these other projects).

  1. Cross-testing

When an application runs in BeOS and crashes in Haiku, it can be a bug in Haiku in most cases. Being able to check the expected behavior on BeOS is of invaluable help. For example, this is how Worms Armageddon or BePac Deluxe helped me identify and fix subtle problems in our game and media kits. If we had no binary compatibility, there would simply be no way to do that

  1. Preparing for the future

The plan is that each release of Haiku will be compatible with applications written for the previous one. This avoids rebooting the whole ecosystem at each release. It is hard enough to get applications running, what would devs say if R2 could not run R1 apps and they would have to rewrite (or even just recompile) everything? You guess it: they would say “f*ck off, this OS is lame” and go back to writing Windows apps, where you can write it once and it will run for the 30 years to come.

So yes, running BeOS R5 apps on Haiku R1 takes some effort (but not that much). And this effort is not wasted, it is invested in setting up things in a sane way so that when we want to make R2 run R1 apps, we are ready to do it. We have identified a lot of problems we could hit, and for most we have also found workarounds. For some we didn’t, but we at least planned so that they don’t happen again in the future. This is for example the reason for having the static “libshared” library and the BPrivate namespace, allowing for experimental APIs to be used safely by 3rd party applications.

  1. It comes for cheap and is optional

If you don’t care about it, just do not use it. Use the x86_64 version which is free of anything legacy. So, please do not pretend that legacy support gets in your way. You can run Haiku without it if you want (and in fact, a lot of our users and even developers do).

On the development side, it doesn’t even really get in the way of anything. The API in BeOS is quite well structured and has ample spaces for additions, and abstracts the hardware properly. This made it possible to add localization, wifi, complete USB support, SATA, automatic layouting of user interface, stack&tile, and probably dozens of other enhancements in Haiku. Yet, the BeOS compatibility is there and it does not get in the way. If you don’t believe me, you can check two things:

a) The ticket tagged “R2” in the bugtracker. These are things that cannot be done with the R1 API. It includes things like multi-user support, for example, or replacing BFS with another filesystem with more features, faster, etc.

b) There is also a dedicated wiki page, “API changes on compatibility drop”. This includes also tasks related to cleaning up parts of the API, such as the BOulineListView which is a nightmare to use. Other projects include a complete replacement of the media kit with a completely different API, for example.

If you look at these tasks, you will see that they are all major tasks leading to a rewrite of a complete “kit” or a large part of the API. This means lots of work for the devs doing it, lots of new bugs, old applications needing an update, etc. This is what we want to avoid by sticking to R5 compatible. Not the new hardware, but all the new and fancy additions to the API that would make it even harder to get things in a stable state, and in shape for a release. You can’t make a good release when people are always changing the APIs and the design and how everything works. So for now, having a stable reference, even if it is old, limits this. There are exceptions and derogations, but in general we try to stick to this.


#31

so much got lost when apple dropped 32-bit support. i would love for it to be here still.

re: linux: linux absolutely does still have 32-bit support, even if the libraries aren’t shipped with every distro by default.


#32

Adhere to the 32 bit is not too much, of course, haikugcc2 can continue to update, haiku64 bit does not need to be a bit of a layer of compatibility, the current warehouse in the 64 software package is less than the number of only 32.


#33

yeah so, with a 32 bit compatibility layer, there’d be more. stretching back over twenty years.


#34

35+ years if you counted classic 68k support which was also dropped on Mac OS X Tiger… many of those applications would still be perfectly usable for most people.

The simpler UIs of back then would be better for the young and older people as well.