For those using a 32 bit computer with more than 4 gigabytes of RAM, would not a PAE haiku build be appropriate? I would like to see a 64 bit version of Haiku for those with a 64 bit processor! And maybe, a port of Haiku to ARM, and PowerPC! Also when you click on the “Haiku” icon the pane opens showing the files in the file system. When you click a folder, another pane opens. Why not just redraw the pane to show the contents of the directory instead of opening a new pane?
Perhaps at the beginning of the beta cycle, more attention should be focused at developing more end-user programs as well as renaming some of the ones that already exist. Looking at the apps available, many of the names give no clue as to what the app does. Apps like “Pe”, “People”, “Poorman”, and “Vision” in my view give no clue to it’s function! Yes, there are icons to the left of the name, but for people like me who can’t see small icons like that the only option is to run them all to discover their purpose. Please accept these “complaints” as constructive criticism! I offer my opinions and views in the hope that Haiku gains from them and becomes even more usable!
I am happy to see all the improvements that have gone into Haiku R1 Alpha 3! The system “feels” smoother and looks more polished. I can’t put my finger on exactly what has changed, but it looks much better than Alpha 1! I have been a Linux user for almost 6 years, and it still amazes me how the community can create such awesome and powerful systems! As far as Linux goes, it’s greatest strength may also be it’s greatest foe, endless choices! I like the idea that every part and parcel of the Haiku system is developed by the same community and is guided by the same goals and passion!
Haiku has PAE built in so anyone with 4 GB or more will get access to their full RAM.
X64 (or 64-bit) is not a goal for R1. It likely will happen with R2. ARM & PowerPC also are not R1 goals. They may also happen with R2. Though PowerPC is on decline and by that time fewer people will be using those systems. ARM is just taking off now though mostly in smartphones and tablets it is also starting to make its way into desktops and laptops. Doing these now would make things more complex and delay final R1 release. Getting R1 out quicker is more important and may attract more developers to help out with this stuff.
Check your tracker preferences to switch to single pane view. Well, names are not really supposed to be descriptive anyways. Like, Firefox, Chrome, Safari, Skype, Arora, Synaptic, etc. Would you know what these were for by their names and had you not used or heard about them? A name should stand out and easy to recall for users. As people use the programs they memorize and recall what type of application each is.
There is an option to make the icons bigger size.
Lots has changed. Bug fixes, new features and additions, improvements to current code, etc.
No, it’s 2GiB. Haiku, like many systems from the 1990s, uses a 2:2 split so only half of the address space is available for userspace applications, all of the rest is reserved for the OS kernel exclusively.
Exactly. Furthermore, unlike Windows, Haiku does not offer a PAE API for userland applications, meaning there is no way for a 32-bit application to address more than 2 GB.
The only OS that I know that does not use a 1:1 split of the address space on x86 is a special Windows server version that targets databases.
It’s not really a special version, large memory enabled Windows – including NT4 EE, later service packs of Windows XP Professional and most newer Windows Server editions offer a boot-time configuration switch called /3GB which enables a 3:1 split. Only IMAGE_FILE_LARGE_ADDRESS_AWARE flagged programs are actually allocated memory from the additional address range because Microsoft found that it was not unusual for Windows programs to have embedded assumptions about valid addresses (e.g. using the top bit as an internal flag). Setting this flag at build time asserts that the developer hasn’t made such assumptions in their program. This is separate from AWE (the Windows-specific large memory APIs)
By far the biggest need for the /3GB switch in practice was Microsoft’s Exchange platform. Exchange didn’t scale very well, large systems required huge contiguous memory allocations and the constant churn of allocate/free resulted in address space fragmentation. An Exchange server using 1.5GB of RAM might need restarting once per day just to prevent allocation failures. Expanding the address range available to userspace bought Exchange users some breathing space, which Microsoft hoped would mean they didn’t migrate off Exchange and onto a competitor’s systems.
As to other operating systems, Linux distributions targeted at PAE often chose a 3:1 split, while the Linux kernel supported more esoteric choices like 3.5:0.5 split during the period when PAE was popular but x86-64 wasn’t widely available. Obviously the more extreme splits are potentially dangerous, because all internal structures, page tables, and other book-keeping information must be in that range. Address space fragmentation becomes a potentially fatal problem for the kernel too. (This is also the reason why the /3GB switch limits available RAM to 16GB in Windows).
So 32-bit Linux also latterly offered what was termed a 4:4 split, in which both address spaces are full-size. This means more overhead for copying data between a userspace process and the kernel, and obviously you have to be scrupulously careful to track which type of addresses you deal with, but it works, and it bridged a gap for some users until 64-bit hardware was cheap and widespread.