I still have HP with 32bit CPU form 2005 
And its still usable, and can play youtube (not HQ ofc). While its not my main machine, I`m still using it and often take with me.
did you try a 64Bit Haiku?
Is that question to me? No, always 32bit. But I dont think, that 64bit OS boot on 32bit CPU (at least Linux and Windows dont).
Yes General!
I tried it and was surprised it worked! Read my former post!
You can just try to use a 64Bit maybe it will work… as for myself!
What’s your CPU model? It clearly supports 64-bit instructions, or the 64-bit software wouldn’t work with it.
P.S. Both AMD and Intel made 64-bit CPUs before 2007. 
I’m ok with hi-speed hardware evolution. R&D is never bad, expecially in technology and btw all those electric engineers have mortages to pay, u know. So it’s fine to me.
The real shame is that the software is not evolving at the same pace. At the end of the day, you’re going to have software and OSs based on design choices and paradigms made 20 years ago or even earlier, but with some more bells and whistles and a couple of almost useful new features. And you basically waste all your nice powerful, tech layers feeding these.
No optimizations (but I guess that software optimization is sub-optimal to get in terms of costs), but also no fresh ideas.
sure you have some point here @kneekoo 32bit users are for small point… and please take a while and think too… i want to get into bank to make a transfer of money… but the ban page itselft need a “moder browser” but the “modern browser” also need more RAM, but more ram and CPU need more newer hardware that only are now in 64 bit… i mean in essence there’s no need of 64bit… the environment are in complot to constant evolution… due bussiness…
Some notes about that you said:
-> "big video games… " … for a while… fourth month playing and then to the trash… my son play FFXII for 6 month, and then said “puff i’m tyred i need one new” as amny others childs and gamers only its a fashion!
-> "video editing software, graphic editors… " … common 32bit users dont edit video neither in HD, and i can nicely edit videos at 4096p in my 32bit of course with LFS linux hard tuned!
-> “3D desing software” CUAUCAUCAU PLEASE MEN; ARE YOU TAKING THAT UNIX RELATED ARE USED FOR THIS! for sure you thing there’s no a complete autodesk world there out!
ok i mean, beetween haiku , linux, whatever and MAC/Win?, please, 32bit user will not use a personal pc to play at work! for those there’s 64bit special MAC computers… and of course with ehte stupid windo
Bonjour, Fnux.
This alone is not an argument for (nor an argument against) 32-bit vs 64-bit computing. The supposition seems to be “64-bit is common, and was created after 32-bit, therefore it must be better”. However, the primary benefits of 64-bit are access to more RAM and ability to have a computer clock which counts higher. If we mention MS Windows, notice that Microsoft does not recommend 64-bit versions of Excel, except for specific usage scenarios:
Haiku’s goals for Release 1 (R1) include:
- Be a continuation of BeOS.
- Allow running old BeOS software for which no source code is available.
- Allow continued performant use of old or slow computers without the performance penalty associated with some popular modern OSes.
It is intended that Haiku Release 2 (R2) will exist only in 64-bit form, but may include a compatibility layer for 32-bit.
Transition from 16-bit to 32-bit is mostly not relevant to the transition from 32-bit to 64-bit. Also, the difficulties of maintaining 16-bit code in combination with 32-bit code are not relevant; 16-bit code was largely written with different hardware paradigms than 32-bit code (typically without even the concept of protected memory, or the ability to use an MMU).
Please check again the “LTS” (long-term support) versions of popular Linux-based OSes. However, you are correct that a trend exists to stop 32-bit support.
This is not yet desirable because:
- It would eliminate some (admittedly, dwindling) software that has not yet been replaced.
- It would eliminate some people’s ability to receive updates for computers that they cannot yet replace.
- The cost of maintaining 32-bit and 64-bit simultaneously is currently low.
Again, the year is not an argument about validity of 32-bit or 64-bit design. However, your mention of it implies an assumption about the utility of 32-bit. If we accept that your assumption is valid, we must invalidate some of the current utility of Haiku.
Haiku and BeOS never existed for 16-bit or 8-bit machines. It never ran on top of DOS or CP/M. Programs written for these systems were never the intended audience of Haiku or BeOS. However, I believe you can currently run them on Haiku via an emulator if you so desire.
Haiku is already an alternative to those systems, and much more capable than any of them. Removing 32-bit support from Haiku actually reduces its usefulness, whereas keeping 32-bit and 64-bit currently increases Haiku’s utility.
In reference to 32-bit BeOS apps, you wrote:
Many of them run natively on Haiku, as this was an original goal of the Haiku project. Sometimes they can be modified and compiled for 64-bit, if:
- The source code is available.
- The author/owner has granted permission to do so.
I think… Being able to use all of the following is not a limitation:
- BeOS software.
- Haiku software.
- Any software converted (ported) from another operating system.
Rather, it seems to be an advantage.
Thank you for your diligence.
Operating systems which use the Linux kernel are several examples. There are also other examples. However, I do not understand them to be examples of 32-bit vs 64-bit.
It is no disturbance at all. You have only induced a lively conversation.
Even my Asus tablet has a 32-bit Intel CPU, despite many 64-bit tablets being sold at the same time. (-:
Nice. I mainly use Windows or Android. My newest Macs all run OS 9 or older. OS X is too “not like a Mac” to me, but it’s nice for Photoshop and InDesign and such, at university.
Thank you for your interest. Mercí et regards.
4 Likes
You may be thinking well, surely addresses don’t need to be contiguous, I can fix that up with virtual addresses. The address space we’re talking about that needs to be contiguous is the virtual addresses.
That 2GB virtual address space for a Haiku process consists of about half a million 4096 byte pages. If I want an array for that 1000x1000 RGBA image from earlier, that’s say 4 million bytes so it’s about 1000 of those half a million pages, but not just any thousand, they must be contiguous otherwise that’s not an array it’s just a bunch of data smeared around at random and you’ll never find it again. Even if there are tens of thousands of unused pages, unless at least 1000 of them are contiguous I cannot allocate the array.
Eye roll… the whole point of TLB lookasside buffers in most processors since the late 80-90’s to translate non contiguous allocations in physical memory to their contiguous virtual mappings…really anything with an MMU note this is usually done per page, so each page can be anywhere. TLB is a limited/somewhat expensive resource of course so you get stuff more recently like huge pages, which can be like 4k, 16k, 256Mb etc… see here for actual possible hugepage sizes https://wiki.debian.org/Hugepages#Huge_pages_sizes
I repeat pages do NOT have to be contiguous AT ALL.
Requiring contiguous memory for allocation has been impractical for nearly 30 years…
Again these already are the virtual addresses.
It’s not about running out of contiguous physical memory, it’s about running out of contiguous virtual addresses as I have kept explaining over and over. 32-bit Haiku has only 4GB of virtual address space, and allocation need contiguous address space.
The virtual mappings can’t help you fix this. They’re the problem, not a possible solution.
You may think to yourself, well, this is crazy, why didn’t anybody do anything about this? They did - decades ago they invented 64-bit architectures so that there would be more virtual addresses. The solution is 64-bit.
32bit Haiku has PAE… a separate virtual address space per process.
Each application gets a linear 2GB virtual address space all by itself… period. And as has been menitoned before it should be possible to just make it 4GB by getting rid of the kernel split.
There are very few x86 processors since the Pentium Pro that do not support this extension.
In fact the main PC I run Haiku 32bit on has 8GB ram and it sees that just fine… and in any case I’ve rarely seen memory use of the whole system exceed 2GB… perhaps when compiling etc… all this griping about 32bit is choking on a gnat.
The Wikipedia page on PAE even says:
“Haiku added initial support for PAE sometime after the R1 Alpha 2 release. With the release of R1 Alpha 3 PAE is now officially supported.” … so since 2011.
That’s not what PAE is. Physical Address Extension changes the page table layout to allow for more physical addresses (ie more RAM) without changing the size of the virtual address space. The separate virtual address space per process is just an operating system design decision that’s been usual for decades.
But “Well, another process could allocate the array” is not what you’re looking for in a program, you want to be able to allocate the array in this process.
Way to move the goalposts… Others have already explained why more than 4GB of address space isn’t needed for most programs so I won’t bother.
This is completely unrelated to 64-bit addresses. You could change 2 lines and recompile Haiku today and solve the Y2038 problem on GCC2. That would break BeOS ABI though, so we haven’t done it yet. (64-bit Haiku already uses 64-bit time_t.)
It’s still used in the kernel for direct-memory transfers to hardware, which requires physical addresses and does not touch the MMU, usually.
This has nothing to do with PAE; every application has its own virtual address space with or without PAE. PAE means the kernel has access to more than 32-bits to set up address spaces in.
Err. How would you get rid of the kernel split?
That’s possible for free and open source software, but not for unmaintained closed-source software.
The split assumes we should like both mappings to co-exist, even though at any particular moment in time we either are, or are not, in the kernel in “ring 0”. But you can instead unmap the kernel’s addresses altogether whenever you’re in userspace, giving them almost 4GB of space, now you don’t have a split. This approach also means the kernel needs to do some acrobatics to do a copy to or from userspace and so of course everything is markedly slower.
Enterprise Linux systems offered this (sometimes called a 4:4 split in constrast to 2:2 or 3:1 splits more commonly seen) for systems where the workload needed the maximum possible address space and yet for whatever reason the obvious answer of going to 64-bit addressing was not taken (often a vendor refuses to certify 64-bit, or there’s an unwarranted price differential).
A 4G/4G split is possible but less performant… But if software needs more than 2 or 3 gb on 32bit it may be worth it. 3/1 split is far more common and probably a better compromise.
The 4:4 split also fixes meltdown/spectre attacks, since effectively none of the kernel is mapped at all to userland processes (in 2:2 or 3:1 split it’s supposed to not be reachable by userland but sidechannels allow to glance at the data).
No one is probably going to bother doing it, as 32bit is on the way out, still.
2 Likes
I’m late to the party and I just want to chime in on the original question why 32 bit…
-
As a normal user, the benefits of 64bits are that of commercial software that forces it, largely by doing unnecessary tasks as part of a much simpler process. Remember, it was a 32 bit computer that handled the effects that still hold up pretty well today for Terminator 2. I think effective computing is more important than throwing bells and whistles at things that don’t need it. I personally (and I know I’m a minority in the world) think 64 bit computing is a bit like having bluetooth on a toaster.
-
Haiku’s best asset is it’s speed. Many of us have old laptops and computers we kind of stopped using because commercial software stopped supporting it. However, Haiku’s speed can revive those old machines and make them feel new and usable again, assuming that feature creep and bells and whistles don’t put the cart before the horse. What’s the point of 64bits if we’re just going to carelessly waste them on things only tech fettishisers actually want…as well,
-
Adding to number 2, there’s the aspect of many lesser developed countries are using the ‘garbage’ of the western world for computing; that is 32 bit computers with older hardware. They’re not playing games, they’re doing small programs and kind of using computers what they were intended for; solving real problems with the aid of a ‘numbe crunching machine’. 64 bits isn’t necessary for those things. Hell, 64 bits in actual objective sense is just what was settled on. Some classic computers that filled full rooms were 15 bits, 24 bits, etc. long before the commercial industry was introduced so bit-wise-speaking, it’s not especially critical unless you’re asking the most burning question of all: Can it run Crysis?
So that’s just my weirdo non-commercial but still a lover of tech answer. I think 8 bit computers are actually more than adequate for general tasks, but that’s not viable option in 2018. I think 32 bit computers are still reletively important enough today both from a ‘cheap personal computer that’s probably already sitting in your closet’ point of view (think college kids that snag a 30$ dell from the local pawn shop to type up papers) and from a global perspective, Haiku on 32 bit is more than necessary if it wants to gain any kind of audience as a low-end computing choice. And I don’t believe it would be terrible for it to become mature on a system that is maybe not fettishized by the commercial industry before moving on to the literally-it-can’t-do-this-linux-has-tried task of keeping up with the Jones’ computer (i.e. supporting the latest and greatest stuff) because it Open Source and commercial companies simply don’t have the interest in such things.
Now I will go back and read all of the comments, I just added this to answer to the original question to hopefully add to the ‘rational discourse’ on the subject. This is a free project (as of right now until Microsoft buys it’s way into this project as well…a little joke, there) and so I don’t really think any arguments or criticisms about the platforms the project chooses to operate on are of any concern. Would I personally like to be able to use 64bits? Oh hell yah. Does it matter enough for it to be a big issue? Oh hell no.
3 Likes