ok, sorry, I misunderstood. I’d also think that that would be a good solution. Maybe that gcc2 becomes a secondary architecture which could then live in a subfolder. That would also make porting (in some instances) easier as some build systems look in the gcc2 library paths instead of the x86gcc11 one
Is there any chance that any GPU that would work on a 32-bit only machine, will get a 3D driver in the future? We’re talking about machines from the ISA/PCI/AGP era.
If someone writes a driver we’re happy to include it. For this you need someone who really wants to do it, and it will not support any modern 3D application because the hardware just can’t do it (3D tech has changed a lot over time). So, which apps would you even run on this?
There is a big gap between “constantly upgrade” and “keeping the same machine for 15+ years and expecting it to still be fully supported”.
For example, on 32bit machines, you can run Haiku, right. But you need SSE2 if you want to run WebPositive, for example. So in fact this only adds the Pentium 4 and some first generation Atom CPUs to the list of supported hardware. The Pentium 4 is old and inefficient, to the point that replacing it with a slightly newer 64bit capable computer, will probably be refunded rather quickly by the saving in electricity costs.
We will not drop 32bit right now or for the next few years, but at some point we will have to do it.
Albeit there isn’t a web browser for sub-P4/Athlon shipped in the build.
GCC 2 set of Haiku libraries can be forked and stored separately. Maybe it is possible to complete GCC 2 ABI in Clang, it already have some kind of support.
Making R1 a LTS release would be sufficient. Browsing the web with a 32-bit old computer would still be a less-than-mediocre (in other words, pointless) experience anyway. I’m sure someone will pop up and try to explain how they can do everything with their ancient machine though. Good for them.
Older non-internet connected machines would be better off with Windows 2000/XP/7, depending on the age of the machine.
As long as there is someone in this situation AND they are willing to put the time and effort to keep the OS working, it’s fine, the 32bit port will live on.
That tells a sad story about Haiku if it’s true
I will be happy to see 32-bit supported as much as it can.
Not necessarily. It’s mostly about available games and software, not the OS experience.
If I can say my opinion as a simple user: I DON’T AGREE,
Haiku is a free, open-source operating system, born to be compatible with BeOS.
It is a drop-in replacement for the old discontinued system, nowadays with many more features than the original.
Changing things like “let’s make it 64bit only” just changes the philosophy behind its creation.
People can surely do something like that, but at that point it won’t be anymore Haiku but something else. At least, I think so.
Actually, I’ve used Haiku on my old Pentium 4 (1.8 gHz, 1 Core, 32 Bit) and it ran pretty great for a 20 Year old machine and I was able to use the internet rather well. Granted it is not the best experience and compiling stuff can be a bit slow, but still I’d consider it usable, definetly more so than any Windows version and a bit better than debian with lxde. So I’d say that Haiku is a great operating system for old computers and one that brings modern technologies to those old machines
It would definitely run well, indeed much better than Linux, for development – unless you are targeting ancient Win32 SDKs. For the casual use and gaming however, Windows platform offers still much more.
This is a thought process. Haiku is a replacement for BeOS after all. I don’t know how many programs from back then run on 32-bit without any problems, but I think most of them do. Perhaps an R1 should be released now so that you can switch to 64-bit, but only if all 32-bit programs are running underneath it. You could then support a 32-bit version with security updates and a current browser so that old PCs can continue to be used. in a while these will also be replaced.
I think the best thing to do is get to a solid HAIKU R1, and then move on to a separation, so Haiku will proceed much faster. Make available the 32-bit version open to the correction of bugs and the import of new functions for those who want to dedicate development time to it, I think it’s the best thing to do, because 32-bit machines will be used less and less, and because of the obsolescence and limited performance, there will hardly be a need for a better design than what will come after HAIKU R1.
Maybe there will be enthusiasts who will continue the development at a more playful level, this is the beauty of open source, that the development will never really end, but it is good that HAIKU is separated in order to accelerate its development on platforms that are easier to find, I think it is the most natural thing to do.
This is the spirit of BeOS? To run on as many obsolete machines as possible? To me it seems, it was the opposite, trying to impress the world with novelty and performance on a restricted set of hardware.
For a small “commercial company” with ambitions this seems a logical path, but the current “haiku leaders” seem to have a completely different approach.
A lot of talk here, but is anyone willing to help with fixing the build of 32bit Haiku? At the moment it is broken and only two people (AGMS and me) seem interested in fixing it. Personally it’s only because my main machine is still running a 32bit OS but I don’t really have a reason to keep doing that anymore (the machine is perfectly 64bit capable). And I’m getting a new laptop soon so I may switch to 64bit for my main install, keeping a 32bit machine around only for when I need to test some BeOS app and compare behavior with BeOS (which happens less and less often these days, as the outcome is either that BeOS is more broken than we are, or the app is too complex to conclude anything from the test).
for now, dropping 32-bit would kill me, at first instance it will force me to trash 3 of mine pcs, and second, the most important one, it would prevent me writing my apps with python (as there’s no Haiku API modules for python 2/3 on 64 bit Haiku).
Ok, the second one can be (maybe easily) fixed by someone who knows how to port the API, and ok, the progress cannot be stopped.
But I hope that this will not happen anytime soon. That will give me less reasons to use Haiku, as recent computers performs better and fade out the lightness and speed of Haiku.
So far there was just one person (not part of the development team) suggesting that we should consider dropping 32bit Haiku. We don’t really need everyone to comment on how they still use it. We know, and no one is planning to drop 32bit Haiku in the near future.
What we need is, if people want Haiku to continue working on 32bit machines, make sure it is still building correctly there. At the moment this is not the case. See for example https://dev.haiku-os.org/ticket/17568
So, if you can help investigate and fix these problems, your help is welcome. If no one does it, well, 32bit Haiku will die, no matter if we think it’s a good idea or not. For this one occasion it takes some effort to keep it working (this usually don’t happen, it isn’t broken that often).
A call for helpers, at the moment there are not a lot of haikuports members involved (able) to check on open PR’s at haikuports, I can’t check them all (time is sparse) so having some help in the area would be much appreciated
This is an area of interest for me. However my ability to grok the necessary skills for porting and maintaining ports is still fledgling.
We are here to help out, just don’t have enough time to do all the checks myself, if you need any advice just call for it, I’m sure some (if I’m not around) will be glad to help you on the way