I remember running BeOS R4 on a Pentium I machine with 16 MiB of RAM and it ran well.
None of the things mentioned here in this thread justify the increased RAM requirement for Haiku. The reasons put forward, as I read them, are:
– Optimization is not a priority for Haiku right now (fair enough)
– It perhaps never will be (a shame)
– RAM is cheap, and most people have plenty (irrelevant to my argument)
– Super-efficient, clean, cruft-free code is no longer as important for us as it was for BeOS (this is the crux of the argument).
This is one of the several ideological differences between Haiku and BeOS that means the original will always have a special place in my heart, no matter how much Haiku develops. BeOS, as I choose to remember it, was not just an OS, but an software ideology.
Haiku has lost that, and perhaps doesn’t even care that it has.
What I remember hearing is that both BeOS and Haiku take advantage of memory and tend to use all of it. What is it about Haiku that people think is not lightweight? There is no crime in using all the memory. I think the real crime is running BeOS or Haiku on uniprocessor systems.
I used BeOS R4, R4.5 & R5 on a dual Pentium Pro 180 system with 192 MB ram. I could play Quake just as well as my friends running Linux and Win2k. Today, we are just lacking Hardware Acceleration. If we had that Haiku would seem more lightweight.
I’ve ran R5 on plenty of hardware, including Pentium 1’s, and it was not comfortable without at least 96MB or so, otherwise it was hitting the VRAM hard, that was before starting anything like a web browser which would consume even 128MB.
Debatable, compared to any of the *NIX operating systems and even windows Haiku is still efficient, clean, and garbage free. Just look at X11, a shit show of 30 year old hacked on spaghetti code that serves virtually no purpose now since any of the window managers today has a compositor that takes over all the tasks that X11 used to perform, but X11 is still there and still required, just complicating things.
I have to laugh, I looked at OpenIndiana just now, the min, install is 494 MB in size and the full install is 1.6 GB in size, yet there are people complaining about the size of Haiku!
Optimization takes development resources (i.e. programmer hours, which are a precious resource)
“Be, Inc” was a company founded by venture capital that could (I assume) hire full-time programmers to sit and optimize for the low-end hardware of the era. Haiku’s developers are probably mostly working in their “spare” time.
In general, if you want to make and finish good software, redirecting valuable limited programmer hours ‘this way or that’ on every little whim is ineffective strategy. Suddenly throwing programmer hours at optimizing for machines with less than 128MB RAM in a world where virtually none of the target market has so little RAM doesn’t seem like a sensible use of programmer hours to me … I’d rather see time spent getting to a ‘stable version 1’ that can do useful things.
If a programmer enjoys doing memory optimization, and that’s how they want to spend their spare time, well, fine, no harm.
But to expend development resources, the question is, is it more important than other features that would give ‘more bang for the buck’ toward making Haiku a usable, useful, stable operating system for most of the target users? I doubt it. My lowest-end device in the house has 4GB RAM. I threw 4GB at my Haiku VM as I have 88GB of RAM across my main dev machines. I would hate to see Haiku’s version 1 release date be pushed further back in order to have programmers save just a few tens of megabytes of RAM.
This thread, and some of the comments, feel a bit troll-y.
Short answer: Haiku is not BeOS. It does not based on the old Sources, it was rebuild and optimized. There are many differences between Be and Haiku today.
If you want it, start to port it. No one hold you back to do this. Haiku is open source and people need software. I prefere a web+ browser because it is more native. If you have not the expierience, start a haikuports source tree with parlemoon and of one have interest, can help you.
It’s easy to say this when it’s not you that has to spend ~3-12 months of your “spare time” (inbetween normal work and life priorities) to sit and optimize code … it’s easy to just be critical and yell at someone else’s project when you don’t know anything about coding and demand they use their time this way or that. (To be clear, I don’t work on Haiku but I have worked on both open source and commercial projects.)
I’ve been programming since 1992. My first computer had 1MB RAM and a 20MB hard disk. In 20MB we fit the OS, games, development environment, word processor, drawing program, source code, utilities, drivers and more - even a little pr0n. So I know what tight, efficient code means, and I also understand how bloated OSs like Win10 or smartphone OSs are. In those days, I had to write much of my code in assembly language in order to achieve good performance and tight memory usage, and even to do basic things like draw pixels to the display efficiently required painful, lengthy assembly language procedures … back then most of the applications and OSs had large portions written in assembly language. Almost certainly, the original BeOS had portions hand-optimized in assembly language. This is enormously expensive and draining in terms of programmer hours - it takes days or weeks or months to develop and optimize in assembly language what may take minutes to code using eg standard libraries (which may use more memory or be slower but on today’s hardware are mostly ‘efficient enough’). Companies like Be Inc likely had full-time experienced developers being paid full-time salaries to do this kind of coding. The Haiku developers are the ones who best understand how to prioritize their own time. It’s not a “difference in philosophy”; skilled programmers aren’t a dime a dozen.
he sais correct. you don’t. you are a linux “veteran” but I am an XP one. so I probably know better about XP. I used 32 bit XP a lot, then 64 bit XP. honestly, I stopped using it often only recently. Even if you go and sum up all the kernel memory and user mode OS components working sets, you will get numbers around less than 100MB of the OS consumed memory. I still remember this constant 11MB of nonpaged pool on a fresh start. plus ~30-50MB for paged ones. plus couple of megs for kernel images. components like lsass, csrss, winlogon, even on 7 take up 3-7MB each. and there are a half of a dozen of them. so where did you get 1GB from?
and don’t forget - Windows (and XP’s too) graphical subsystem is incomparably better, than the linux’s zoo. by efficiency (just compare CPU utilization on UI activity! I need to yet see a linux that would load CPU as negligibly as Windows on such tasks. this “lightweightness” is even more important for me).
1GB for install is another story. I faced with this behavior - intel graphics driver complains that it doesn’t have memory and starts to show 4 bit colors. but it’s in no way an “OS requirement”.
Haiku’s method of package management will use more memory. It still isn’t that bad and Haiku uses a lot less memory than the average Windows 10, macOS or Linux setup.
There may be things that can be improved, and I personally have interest in improving things like memory usage, but there is definitely a point of diminishing returns. Haiku is all volunteer based at the moment, and the volunteers have limited time and they must prioritize work based on value to themselves and the project in general. At the moment it makes more sense to improve Haiku than to minimize memory usage.
With all that said, there has been a lot of work by waddlesplash to improve kernel performance for things like compiling. That has more benefits than memory use reduction.
Lastly, I am confident Haiku is much more usable on older hardware than other systems, even without things like GPU acceleration.
Optimization is a priority. It is not the first one, but when we notice a problem, we do fix it. Using 250MB of RAM isn’t a big problem in the current world, and we already did some work to get there.
RAM is cheap, irrelevant to your argument maybe, but relevant to our users.
Clean code is valued a LOT more in Haiku than it was in BeOS.
Cruft-free, we do as well as we can with the constraints we set ourselves of being binary-compatible with BeOS. Of course BeOS is 20 years old now and that means it comes with some cruft.
Super-efficient often goes in opposition to clean code and architecture. I think C++ allows us to make a very good compromise between the two, as it’s possible to write the code in nicely separated modules and have the compiler optimize a lot of it into very efficient code. There are two drawbacks to this: C++ is not the perfect language to do this (in particular one has to use a lot of templates and avoid the typical object-oriented way, at the expense of losing some forward compatibility and ABI stability), and we are still using gcc2 for compatibility with BeOS (modern versions of gcc are a lot better at optimizing things - but at the expense of longer compile times, which I think is ok in the modern world and especially because it bothers only the developers and not the users).
If you read the project tagline that I put in my first reply here, “lightweight” is not there. But “fast” is. And being fast involves sometimes using more memory in order to be less CPU intensive. So, optimization is still there, but the goal is not the same.
You complain of memory used then you want Haiku devs to port a browser that is everything but lightweight. Not very logical. Obviously, in that matter, same features included, a native browser will always be more efficient.
Did you ask whoever is M$ CEO to drop Edge for Chromium anyway? Or did you ask to Google CEO to drop Chrome for Firefox? I’d like to see answers… Come on. Show them. We all need a good laugh.
Templates help optimization? I didn’t know that, but specifically when it comes to memory footprint I would have guessed there’s extra cut and paste code.
For me it’s kind of a good thing that the API is old school C++. The layout stuff being the obvious exception, and maybe the one place where it’s likely to ever be worth it.
I’m surprised that the memory footprint comes up as an issue here. If that’s what we have to complain about, I would think it means Haiku is nearing perfection.
Templates allow inlining of the generated code, which in some case is useful to optimizations. It’s noticeable because usually it’s useful in cases where doing the same thing in C requires a lot more work (with macros which tend to become unreadable even faster than templates).
The typical example is when you’re implementing a linked list. You do it by having a List class, that contains “objects”. There are two ways to do this: your list can be a template:
class List<T object>;
Or it can be that the list can only contain subclasses of some “Object” type.
Since the code to manage a linked list is very simple, the template version will usually be better. It inlines pretty much everything, and the compiler can then optimize it to be as fast as if you had written your code in C, shuffling pointers directly (or with macros). On the other hand, the version where elements must subclass some common type will have its code compiled only once, and everything using such a list will have to go through function call overhead and probably virtual methods, which can end up being quite a lot of overhead if, for example, iterating the list requires calling a function each time you want the “next” element.
This does not mean everything should be done with templates, however, in some cases, indeed the code duplication will use a lot of memory and there is no good reason for it. I think that’s the way C++ does things: it gives us a lot of tools, and lets us decide which one is appropriate in each case (which is not always an easy or obvious decision).
I think BeOS is an excellent example of software which works quite well, but is a mess internally. Haiku inherited the Tracker and Deskbar code and really, they are pretty bad. PoseView in Tracker will give any programmer nightmares, it is the god class of god classes, and extremely brittle. The Tracker code has some good parts and can probably be refactored into something decent but it is a lot of work, and several people have tried and I won’t say they failed, but they could not complete the work.
Deskbar is also pretty terrible and we just need to start over I think since it isn’t that complicated. Stippi has a great blog post which provides a good feature set for a new deskbar. I would love to work on that but my Haiku time is very limited and there are always more pressing things.
What a coincidence, since windows 2000 and XP are probably the operating systems I am most fluent in and still use, and in my time of years working as a system administrator for the school system all the machines were XP, and I got that ~1GB from years of personal experience setting up and maintaining hundreds of XP installs. 1GB was the comfortable zone, 512MB was the minimum I would go for a usable install.
what this “I got 1GB” does mean? I explained what memory usage by the OS I meant - non-paged pool + paged pool + working sets of user mode OS components + shell (explorer). plus some couple of megs for kernel images (kernel, drivers, registry hives). note, pools are allocated but not necessarily all used, also paged pools may be paged out, that is not necessarily all this amount resides in RAM.
this sums up to something muuuch closer than 100MB than 1GB you are talking about. what this number is taken from? and again “usable install” and “OS memory consumption” is as close as Mercury to Uranus.
