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.