Sorry but Windows XP requirement is proch of 512 of Ram on a fresh install that I seem for be quiet, 1go is a luxe for XP users. If you disables somes services yes you can certainly go down…but here a fresh install of Haiku. 256 is not very a lot at this time for a complete desktop environment that work. Yes in Linux you have the choice to put the lightweight Windows Manager, session manager, etc…like open Box Fluxbox and tweak everything. I love these WM but that also the evil side of linux all the environment is chaotic comparing to MS Windows or Haiku. Here we have a complete system with something like synaptic, basic web browser, MIDI compatible (not the case in Linux go tweaking with Timidity++, Alsa, Jack for audio and coo…The hell). Firefox this magnifiant browser take a LOT of memory for himself…Yes you can install other web browser but in a lot of case they don’t really make a stable work. I love Haiku project for be unified compared to Linux and I think this topic can be take like a advice not bad but. Don’t tell Linux is the best when you must tweak all the system from command line for have a good desktop environment…That the case for it or go watch to the louder Ubuntu or other distro that take the same way of MS about memory usage like Windows 10.
Also I have a Rasberry Pi 3B+ and have tested some desktop environment on it, the default distrib Rasbyan is optimized for it and based on Linux…Yes. That doesn’t work more well that Haiku about memory usage that it seem.
Before package management was added in the way that it was to Haiku, Haiku used about 100MB at the desktop… and could run on machines with as little as 128MB reasonably… the core of Haiku itself has not changed that much and if anything has gotten slimmer, on the other hand there are some overheads that probably cannot be removed with packagefs still in place.
Take what I say with a slight grain of salt I am very opposed to the current package mangement implementation, and would prefer it was ditched for a simple package management system that isnt’ trying to reinvent the wheel and do too many things (badly I might add).
That’s SP3 after they bloated it up… XP up to around SP1 or so would fit in 64MB ram just fine with some minor swapping, but nothing that made it unusable, SP2 really needs more like 128-256, and SP3 yeah 512 is probalby a good sweet spot.
The main ram use would probably be from the locale kit and the ICU data (about 25MB .so for each architecture, loaded into each executable that uses the locale kit), before we start worrying about packagefs.
I hope so. But there are still two versions for gcc2 and gcc8 (for the 32bit version) so that’s 50MB of RAM gone already. On a 256MB system this really sounds like the first thing to investigate.
Yes I confirm the services pack and essentielly the third take a lot of ressources compare to the original XP version. But at this time work on Windows XP without theses pack became not possible to get the softwares updated. That’s hard today to have a web browser suffisely updated that can surf suffisaly “normaly” on this Windows platform, I have try it…Few one can be used. I notice Pale Moon browser, Firefox-ESR not last version…
But for work in standalone without internet XP is nice yes.
I don’t really know what do you talking about Package Management (HaikuDepot?) I know Haiku about few year but not at starting point.
Have you seen any actual BeOS sources? Because everybody who have seen tell the opposite.
That’s a great point. Taken.
To put this argument to bed: how hard would it be to do a benchmarking test between BeOS R5 and Haiku on the same hardware? I have a feeling that BeOS would be both faster and take less RAM, while Haiku wouldn’t offer an appreciably better end-user experience.
Like @cb88 I disagree with Haiku’s current package management philosophy, so don’t bring that up as a benefit of Haiku. What else? Vector icons? Don’t get me started…
BeOS (in the super crushed BeIA iteration) could even fit into 16MiB of HDD space!
BeOS can’t run on machines with more than 1GB of RAM. It also needs a CPU without SSE2 support (or a patched kernel). So yes, you could set up a machine with both systems, but it would be a system that’s unrealistic for both: too modern for BeOS, and too old for Haiku.
And we already know what will happen: your benchmarks will tell you Haiku is already faster than BeOS at the cost of using more RAM. Your experience using the OS will not match, because BeOS makes up for it by using 2D acceleration, which Haiku gave up on years ago, because for machines with AGP onwards it turns out to be slower for our use cases (and later on the only way to accelerate things is goingthrough the 3D pipeline instead).
Haiku will also spend more time in drawing UI elements because it antialiases everything, and that’s slower and harder to accelerate (it’s not just the icons, the whole UI is vector based, antialiased, and scales nicely to hight DPI displays).
That is complete BS… Haiku had ICU for way longer than packagefs and has booted in under 100MB and stead state ram use was well under that not that long ago. Now it could be some bad defaults selected that bloat the base install but ICU itself is DEFINITELY not the main culprit.
I’ve ran BeOS on a Sempron 1.8ghz with 512GM ram… which can run both Haiku and BeOS just fine… saying it isn’t possible to build a machine that cannot boot Haiku and BeOS is just completely untrue.
That’s the complete opposite of every post you ever posted about graphics acceleration since forever.
@cb88 I think we all know you are disappointed in the package system. I would appreciate it if you could be nicer in your posts to long time community members and contributors like PulkoMandy, humdinger and waddlesplash.
The core project is not going to abandon the package system. It has issues that we need to fix and I have looked at some of them, but it doesn’t need to be thrown away. I would suggest to look into helping on the HAKILO system which seems to kind of work and with enough polish maybe that could be better supported by the project?