We can always just close the thread. But I’d rather see people acting mature. It may also help in not escalating a situation the next time around…
4 Likes
All the sought after apps are only supported on the 32bit version of Haiku, like SoundPlay for example, which is arguably the most popular app for BeOS and Haiku.
I concur; it would be better if stuff like this can be deescalated more organically instead of having to use more heavy-handed methods. That being said, you never know when it’s time to exercise the more consequential powers of being a mod until it arrives…
Back to the topic.
It would still be nice if Haiku will continue to have a 32-bit version in the future. Considering how efficient Haiku is, it would be a shame if old computers wouldn’t be able to run it. Not to mention, some older 64-bit computers (netbooks probably) have shipped with 32-bit EFI; last I checked, only 32-bit versions of Linux can boot on these Frankenstein systems (besides Windows).
Other side of looking: tunetracker is the only commercial User of haiku for there Radio Studio solution. This is the point we need to look who need 32bit after r1 anymore. I does not know if the programs of tunetracker are recompiled for 64Bit.
32-bit Haiku has a simple 2G split like most 32-bit 1990s operating systems. Microsoft’s server and professional lines offered a 3GB split option, which trades reduced virtual address space in the kernel for more in each application if that’s what you want. So, compared to 32bit Windows, Haiku is more limited.
Haiku is trying to develop 32-bit compatibility for the first time at a point where other vendors are ceasing to support it (current macOS will warn you that your 32-bit apps won’t work in future OS versions for example), I suspect this is an illustration of where Haiku fits on a technology curve. “Check this out, a car phone!”.
32bit windows doesn’t have PAE unless you hack around it or run a server OS try again.
There is also the possibility that Haiku could implement a different memory split configuration Intel bug security
This line of reasoning seems like it should work, but, not so much. I would not recommend a 32-bit OS if you have 1GB or more RAM because the virtual address space is too tight. A lot of unfortunate shenanigans can be avoided by just having many times more address space than RAM, as a 64-bit OS does.
On Intel the difference is even greater. Long Mode is how you do 64-bit on x86-64 and it comes with more general purpose registers, guarantee of a more normal FPU and other benefits. So giving up Long Mode (to run a conventional 32-bit OS like the 32-bit Haiku) is a high price to pay even if you only have 512MB of RAM.
Linux has an ABI to try to salvage the benefits you’re talking about while keeping Long Mode, the x32 API. But x32 is generally felt to “not live up to the hype”. It makes programs a bit smaller, but not by as much as you’d hope and so they don’t end up much faster.
As long as they are still compatible…
One good question is if 64 bit Haiku (future) needs to provide both compatibilities with gcc2 and gcc7 as the 32bit do now. I guess that … yes, to keep the old aps running where needed.
PAE was a supported feature of 32-bit Windows XP, Windows Vista and Windows 7.
What’s the point if it isn’t enabled or is actually set below the limit as in many versions of Windows. Even windows 10 still sets it at 4GB artificially gimping their 32bit OS.
XP sets it at 4GB… install 8GB and it is not seen unless you go mucking about to try and enable it.
Both gcc2 and gcc7 support planned for 64 bit.
1 Like
Well gcc 2.95 + GCC N, Clang/LLVM also … it will probably keep incrementing until R1.
Good to know, compatibility wise.
AS cb88 says, maybe Clang/LLVM bring something good to the table. I am not experienced on them to think about that yet.
Well even Mozilla actually compiles Firefox with Clang by default now… its a mature toolchain.
That’s probably related to its rustifying process with Servo and the approach to Clang/LLVM of rust.
I guess i will try them in Haiku to have some fun.
Actually the main reason they switched is LTO and renabling PGO on Linux reliably (there have always been issues with PGO on GCC). But yes probably helps with Rust also.
Go as technical as you want, but when your browser sucks your RAM dry, you’ll want as much free RAM as possible. So unless the users stick to maximum 2-3 tabs in the browser, they will benefit from using 32-bit software on a 2GB RAM PC. The PC becomes much slower from using swap, so the tight virtual address space is not their biggest problem.
When you run out of RAM, merely things are a little slower than they might be as you use swap, or de-allocate other things to make room.
But any time you can’t get virtual addresses that’s it, game over. A lot of software will just crash, the rest may limp along, crippled as critical features don’t work.
Take a 1000x1000 colour image, even though it may be compressed to a few hundred kilobytes on the network, when displaying it you’re going to make it into an RGBA buffer. That’s 4 million contiguous bytes of address space. No problem at all in 64-bit, but in 32-bit that’s about a thousand contiguous previously unused pages you need to find. Can’t find such a broad swathe of empty space? You fail.
It’s theoretically possible to allocate up to 50% of the space reliably, hence (with 2GB process size) my cut-off of 1GB. Beyond 50% you’re basically on blind luck, it might work, it might not, even with the best possible allocator unless it’s somehow prescient it just can’t be sure to avoid fragmentation above 50%.
1 Like
Um, do you understand how “running 32-bit apps on 64-bit OS” works? That’s what all the “ifdef_32/typedef _32” is for, to support syscalls from 32-bit apps to the kernel. It is actually more work to support that than it is to keep the 32-bit kernel running, as is evidenced by that patch.
Also, Linux, FreeBSD, et al. still support 32-bit (though most Linux distributions have dropped it, I guess, but they retain lib32 support.)
+100.
2 Likes
True, but then why would you torture a low-RAM PC with stuff it can’t handle? You have a limited PC, you find out its limitations and use it accordingly. Even on a light Linux distro when you use Chrome with facebook, YouTube and some mail service (3 tabs), the RAM usage will grow quite fast and it’s not the limitation of the virtual address space of the 32-bit architecture that “bites” the user first, but the low quantity of RAM. And using 64-bit software only makes it easier to use up all the available RAM in such ordinary cases.
The average usage of PCs won’t get people in trouble simply for having the “wrong” software architecture running, but having 1-2GB RAM is a problem that can be alleviated a little bit by using 32-bit software.
1 Like