how about “take all similar topic into one”?
guess it : so many people are thinking about the future of Haiku.
not a bad thing.
and we only need one topic of the subject.
does we really need to drop 32-bite-platform in R1b4 stage for speeding?
Nobody who is actually working on Haiku has said anything about dropping 32bit support, as far as I know. So it´s a non-issue really.
5 Likes
Correct! 
My main reason for considering Haiku is primarily the taking over of Linux by the big corporations, turning it into another Windows/MAC type system, removing our freedom of choice. 
5 Likes
This is mostly true. There is a little bit of work and some extra problems caused by keeping compatibility, but, in return, we get a lot of experience on handling such problerms, what can and can’t be done. And this will be useful knowledge when we want to make sure Haiku R2 can still run Haiku R1 apps, and we don’t ask everyone to recompile all of their apps to run on R2.
Just that makes it worth the extra effort, I think.
7 Likes
Someone could sustain 32-bit support (i.e. BeOS PPC/x86) and /Haiku x86) within a Haiku x64 host.
Users still retain 32-bit x86-compatible computers. Why? They still work. Also, great 32-bit legacy apps and hardware are still in use. Users can install BeOS Pro (or PE)/Haiku x86 on 32-bitr computers.
Also, users still build and sell/buy/maintain 32-bit computers.
The industry still retains 32- computers. Marketing fluff says otherwise, but that is not true. Migrating to a perfect 64-bit computing infrastructure can become very costly for certain businesses.
As for Haiku, retaining a 32-bit OS is a smart move for now. Emulating and sustaining a true BeOS Pro 5.x environment on Haiku is a feather in the hat.
3 Likes
the question of 32bit, it is worth to write into FAQ.
because it is a hot question in the next five years.
“why Haiku still insist on having 32bit mode?”
2 Likes
Warning: Personal Opinion
While software ports are nice and all they don’t exactly, how can I say it… integrate with Haiku. They feel somewhat alien (well aslo legacy Be apps look alien too, point taken.) and don’t really take direct advantage of some of haiku’s unique features like atributes or the be_messages to comunicate with other native apps, at most they rely on dbus to talk between them.
That’s not really the point of having compatibility. If one wants to port the BeOS applications and Haiku-fy them, I’m sure BeOS enthusiasts will be happy about that. But I would
Be sorely disappointed if someone decided we didn’t need compatibility or relation to BeOS.
Might as well drop BFS/BeFS, Tracker, or the Haiku desktop. Just port slow and bloated KDE, use extended file system. Make it like everyone else’s. Or, even better…
Be different.
1 Like
To add to that, someone said something about Be wanting to be a modern OS, and Haiku could do just that. Having a modern OS doesn’t mean you need to break what already works. What’s the rush to change so fast? I imagine most people are sick of Windows and Apple changing for changes sake. Aside from things that were broken by change, there isn’t really anything I can do on Windows 11 that I can’t do on XP, or do on Sonoma that I can’t do on Snow Leopard. Meanwhile they both p— people off by changing how things work, where things are, and adding a whole bunch of stupid bugs on the way.
The point about Be having a modern OS was more relevant then, since technology was advancing and changing really quickly. Now much has changed lately though.
I see no good reason why Haiku R5.03 shouldn’t run BeOS applications, or Haiku beta4 applications.
3 Likes
I might be mistaken here, but think that the existence of a 32bit “binary compatible with BeOS” version is actually reason to allow the 64but version to be more free to break compatibility with its apps. Whereas I don’t think there is a lot of software for 64bit Haiku that could not be recompiled after a breaking change. So how about this for an idea:
The 32 bit version is released now as “R1”. We will have made it: Open BeOS at last, and there will be much rejoicing!
Meanwhile the 64 bit version can be rebranded as “R2 Beta” where it is permitted to make breaking changes for a little longer. These might take the form of innovative additions to the core of the OS that would be even more inconvenient to retrofit when we have more users.
Not yet, anyway. As bytecodes develop runtimes based on content common to most operating systems, we may be able to shove off excess baggage by making a Haiku-native runtime. No more Xlibe nor Qt nor Gnome/GTK. By redirecting the function calls to what’s already there, the pain points will be shifted from runtime to compiler and linker toolchains.
The sad part of it is it’ll take another 20 years to get here due to standardization processes and stonewalling by the establishment technology companies. When I see Wasmer developing Wasix as a superset of the glacial developments of the WASI standard, it looks like not much to look forward to.
While I can see why graphical toolkits in general have its days counted we can maybe look towards other options rather that letting the Web-Borg assimilate absolutely everyting. I remember those days were web browsers weren’t basically virtual machines with a few steps.
(I don’t want to throw shade towards your work on webassembly in haiku, from an user standpoint I find it absolutely liberating being able to run free software directly on the browser, especially on certain extremely locked down platforms, aslo there a few wasm projects that I look foward to)
We don’t need ideas
The roadmap to R1 is quite clear and there are a lot of bugs to fix (more than 600). So it won’t happen “now”. Unless you have solid arguments for moving each and every one of these bugs out of the R1 milestone. Most of them are not there because of BeOS compatibility: some parts of the OS are completely broken (for example, the Media Kit and the ffmpeg plugin are completely unable to encode anything). Some hardware is not working and, for example, you get a black screen where you should instead at least get a failsafe video mode driver. Some partos of the user interface are known to be confusing and can be very frustrating for users, in particular, in the install process, and that prevents people from making use of Haiku. And so on. This is what currently prevents releasing R1. It has nothing to do with 32bit support neither with new experimental APIs and features (which we can easily add side-by-side with the old ones if we want to).
We are trying to get out of beta, not to make it last “a little longer”.
9 Likes