Is there an overview somewhere of which version of BeOS and HaikuOS uses how much RAM?
BeOS definitely because HaikuOS doesnât exists.
You donât say WindowsOS, do you? Itâs simply Haiku.
Back on topic, you canât really compare both even if look and feel seems the same at first glance. Haiku has more functionalities, one of them being packages management. The cost is that virtual directories are certainly eating a bit more RAM.
Computers changed also a lot.
You can do comparison by yourself. Download a 32 bit beta1 or beta2 when it will be available (nightlies have more debug things activated) and compare with a DevEd or BeOSMax distribution on same computer.
BeOS could be booted with 32 mb RAM. Haiku needs 4x more (128) - hardware changed but I think its the installer that needs more?
You may check tycom systemsâs site for their BeOS 5 minimal requirements for RAM; they were a dealer for BeOS 5, and the info is still there. Iâve checked - itâs 32 MB; that is the minimum BeOS 5 required to work. Besides, there are VM images floating on the Internet with various versions of BeOS preinstalled; I saw at least 3, 4.5 and 5. They can be attempted to boot in VM with RAM limited in settings.
Besides, I remember I needed to patch the BeOS kernel in order to prevent it from recognizing more than 1 GB (or was it 768 MB?) memory, otherwise the system wonât boot. Therefore there was an upper limit on BeOS memory usage.
With 32 GB of memory in my current Haiku box, and vast changes in software approach, I donât see itâs a good idea to compare lower limits. Itâs like comparing kiwi and oranges: just when you think youâre at least in fruits kingdom you learn that kiwi is a birdâŚ
I think Haiku prior to package management could boot with 128MB RAM just fine. Iâve just checked recent nightly with qemu haiku-master-hrev54185-x86_64-anyboot.iso -m 256M
in raw mode (where it loads the Desktop instead of starting only the Installer) and even though Deskbar and Tracker started I couldnât start AboutSystem to see how much memory is used.
So we are doing worth than Windows XP which can boot with 64MB but having a lot more services enabled by default.
Early versions of BeOS (DR5-6) consumed 4,5 Mb of RAM (âThe developer releases of BeOS occupied 4.5MB of memory. From release to release the kernel size varies from 200 to 300 kb. Currently I think mine is 257 kb. The cumulated size of the different binaries for the system (including the browser) is in the 2 megs. The remaining 2-3 megs seem to be for resource tracking, database support and various system tables.â). Be Engineers and early 3rd party developers used 8 Mb in their BeBoxes. Still, Be recommended to install 16 Mb of RAM in BeBox.
Itâs kinda funny: Back in the BeOS days, we were concerning ourselves how to make machines working that had âtoo muchâ RAM. Now people make a point of using the least amount of RAM possibleâŚ
I tried the same nightly in CD mode with qemu -cdrom haiku-master-hrev54185-x86_64-anyboot.iso -m 256M
and it locked up at the blue screen. It needs more RAM when booting off CD as it uses overlay filesystems (attribute_overlay, log_overlay, write_overlay). Bumping RAM to 266M made it boot to the FirstBootPrompt from where I could start the Installer.
Beta2 will likely need even more RAM as there are extra packages installed by default (so packagefs will require more RAM) Still itâs much more than what Windows XP needed.
Update: 7 minutes later with 256M in CD mode it actually managed to start FirstBootPrompt and the Installer, however it was extremely slow at doing it. Iâm not sure 256M will be enough for Installer to complete the installation.
I managed to run BeOS on this, but it was slow. Compiling simple project take more than minute. Also I canât get color display output. I still have this PC and can try again if needed.
I tried to boot this PC, but 1GB HDD wonât start. It repeatedly produce sound and then stop. Newer 120GB HDD makes BIOS to freeze. HDD interface is mini-IDE.
I managed to run BeOS on SHARP PC-A365 (120 MHz CPU, 16 MB RAM) by using 120 GB HDD, native 1 GB HDD seems dead:
Wow, thatâs pretty cool. Would be great to cut down memory usage in Haiku to not need 266 MB to start.
It almost looks like there is a bug in memory handling as with 1GB RAM AboutSystem shows right after a fresh boot that only 190MB RAM is used and some more is used by cache. So it seems that the cache is never released since it canât start AboutSystem with 256M RAM.
High memory usage is seems to be caused by packagefs.
I think the RAM usage report can be a bit confusing in this case, because there are multiple levels of cache (file and block cache) and one of them (donât remember which) is not reported because it is designed to just use all the free RAM. So if we added it to these numbers, your RAM usage would be 100% all the time, which is technically true, but also not really helpful. Packagefs relies a lot on the caches (it stores uncompressed data there) and shows the limitation of the design. There is an âunify filesystem cachesâ ticket. There was a GSoC idea about it but now no one in the team knows the design of the caches well enough to mentor it. It would probably help with this and be an opportunity to reconsider other things in the cache design.
Ticket number? Search âunify filesystem cachesâ give 0 results.
The cache unification would be good for performance, but is unnecessary for solving the memory usage problems @X512 is talking about. Both the file cache and the block cache watch the âlow resource handlerâ and should evict pages or blocks from the cache when the system is low on memory.
Packagefsâ internal cache, on the other hand, may not; I donât know. This is worth looking into.
I also remember that Haiku memory usage was significantly increased when Unicode ICU libraries were introduced.
The library is big but itâs mostly data and shared between apps. So, yes, you have this several megabytes lib loaded in RAM. We do need most of that data, but we could investigate configuring ICU differently to load it more on-demand maybe.