I think you didn´t understand what I meant. Of course “bloat” is measurable when you are referring to specific things and provide data to support it. That was exactly my point. But in almost all cases of discussions here on this forum the word “bloat” is used without providing further detailed information.
Also I don´t really understand why you keep going on about old Linux distros. This is forum is about Haiku, as we all know, so why not keep focused on that.
So, let my try again: If you have gripes with Haiku´s performance, by all means report it, provide the developers with performance data, etc. We could all benefit from that.
1 Like
That because it wasn’t a rule, it was only me stating that a rule needs to be stated and what it should be about.
@PulkoMandy: No need to be childish.
Honestly, what are we discussing here? I can still remember the times when people asked about applications. If this works, that works, why no office environment, etc. Now, thanks to some developers, we have environments like QT, KDE … and therefore more applications. But these are all from origin OS, larger and more user designed than Haiku applications. So if you want Haiku to be lean, you should try to write Haiku applications instead of asking for ports.
I haven’t used and installed Linux in a long time, so I’m behind the times here. Back then it was always the case that if you do a standard installation, you get a bunch of programs, half of which were uninteresting to me. that was bloated for me.
In addition, today’s computers have so much memory that hardly any attention is paid to size when programming modern applications and especially games (including websites). everything is huge these days.
But you can make a Linux very clien if you have enough knowledge and the same applies to haiku.
I don’t think haiku is bloated, it’s a long way from Klickie Buntie (a lot of clicking, a lot of colorful and gigantic, pretty stuff), as we say in Germany.
1 Like
I don’t think I am?
You are asking for Haiku to be judged by comparison to 20 year old systems. Why 20 years, why not 50?
What’s more childish about one than the other? What makes 2005 Linux a better point of reference than an Apple I (or some other computer from the 80s)?
Imagine yourself back in 2003. Would you be there asking why BeOS doesn’t run on hardware from 1983 and instead chose to need megabytes of RAM, require a 32-bit CPU (and even two of them, why not?) and an MMU?
That is exactly the same timescale. In 1983 we had Kilobytes of RAM, in 2003 we had Megabytes, now we have Gigabytes. I don’t think Haiku is to blame for that. So you have two choices: try to make the best use of current hardware, or live in the past. Or do something in between. I think we are doing reasonably well here, as using Haiku on 20 year old machines is still a viable option. Something that few other operating systems can claim.
10 Likes
I think that we generally tend to use hardware (HW) and software (SW) without fully thinking why we do so. If we look closely we see why the HW and SW is better.
In other words: All the HW and SW improvements justify the bigger OS size. Be it new HW standards, OS features that evolved from BeOS until now, cool applications or whatever.
So why we don’t use old Linux, BeOS, CP/M etc., is exactly the explanation why Haiku is bigger.
Bloat is relative to “luxury” as something “not needed” or “not necessary” - like adware, overlapping software and/or features, or drivers for computer hardware no longer used by the majority of your direct customers/users. Usage of bloat usually is to enhance something - like fresh coats and colors of paint, providing extra screensavers/themes/demos/languages/emojis, or documenting software code. Software games, as an example, are considered bloat when distributed with certain OS releases (and/or game consoles and computers).
Ref: https://discuss.haiku-os.org/t/beos-haiku-historic-timeline-of-oss-ram-use
This was the discussion about memory requirements to run a Haiku installation versus installing Haiku (versus BeOS and other operating systems).
A few people posted running Haiku installations with 128MB RAM or less. Another person installed Haiku using 84MB RAM.
Now, let us go back to talking about 4MB RAM installations with Windows 95 or BeOS with 4MB RAM installations. BeOS utilized a 48MB swap file (or let us say virtual memory). There was a point when computer users knew that 4MB RAM was not enough for modern high-end multimedia workflows by Y2000. Therefore, PC users got Windows XP with a 64MB minimal memory requirement (i.e. that is a 16x RAM increase requirement within six years of Windows 95). So logically, after 20 years of computing since Windows XP, why are users complaining about Haiku installing within 64MB RAM?!? Did anyone mention that macOS Sonoma requires at least 8GB RAM for installation?!?
Modern content creation workflows, HTML5/CSS3, and storage requirements dwarf the default capabilities of those earlier operating systems.
Basically, "logic clearly dictates that the needs of the many outweigh the needs of the few… or the one.”
1 Like
Bloat is something that can be measured: it is boot time in seconds, RAM usage in MiBs, time to complete a given task in seconds. As we add features these numbers tend to go up, and that’s bloat. The numbers don’t have to go up though as there is work we can do to minimize these numbers: make the boot time faster, use less RAM, complete a given task faster. One way to do this is to split tasks into multiple threads (or processes, technical difference aside) so that single core tasks turn into multi-core tasks using the abundance of cores to make the whole task go faster. Another thing we can do is to load as much as we can lazily so that the feature e.g. localization isn’t loaded until it’s actually needed. While this might not make the whole process any faster, it gets you to the Desktop faster, which makes it feel faster. Another thing we can do is to figure out things that aren’t needed and take them out, doing less means it goes faster. Another thing we can do is use faster more efficient decompression algorithms to maximize speed. Of course all of these things mean weighing trade offs and the task is far from trivial.
While not as easy to measure another perhaps more important aspect of bloat is responsiveness. Be decided not to include a wait cursor BeOS because any task that a wait cursor would be needed in single-threaded legacy OS’s for should be split into threads so that the UI part can continue to respond quickly even while threads work in the background to complete the task. I can see this kind of responsiveness bloat in Tracker bringing up a directory on a slow USB stick for example. Thumbnail generation hasn’t made this problem any better but the underlying design flaw is deeper. There should be some feedback in Tracker that work is happening and during that time you should be able to bring up menus and perform other UI tasks in Tracker without perceptible delay. Another example is in HaikuDepot when it is syncing repositories the UI slows down, this should not happen. Now I know that HaikuDepot is already using multiple threads to do work in the background but there is still room for improvement here.m, more threads, update priority.
I acknowledge that there is bloat in Haiku, that it is a problem, and the solution is to split tasks into yet more threads, or baring that being a viable option, provide feedback that a task is taking a long time (e.g. a progress bar) and adjust the priority so that the UI stays responsive to user input.
It may seem contradictory but sometimes it is better for a task to take longer as measured by a wall clock, while remaining responsive to the user, that makes the task “feel” less bloated, even if the measured clock time to complete the task is longer.
If there is ever a perceptible delay of a menu opening or other UI element not updating, that is a design flaw, and it can and should be rectified, it’s a bug.
All that said, these are really hard problems to solve, and the nature of asynchronous programming makes this all harder so there is a good reason that these problems have not yet been addressed.
I’m still struggling to get some tasks to work in the first place, and so I’m prioritizing that over making things work more responsively, but if somebody is interested in this work, I can help to point them in the right direction.
3 Likes
Yes I’m talking about video decoding, which can be handled by the GPU often using hardware dedicated to the task. I’m thinking about on x86, and I’m thinking about on other systems like Windows and macOS, so please excuse me if Haiku already has a different way of handling this. I’ll trust you that it’s possible to make YouTube video playback work better in WebPositive without having to implement 3d hardware acceleration first.
I disagree, time to desktop does not matter at all if you can not start using the OS immidiently. Lazy loading components that are required is not the answer.
Your paragraph to me is a perfect example of why bloat is an imprecise term and does not add much value, first you say it is measureable, and later on it isn’t.
UI lag is a bug, yes! But a bug isn’t bloat at all. Inefficient ressource use is not bloat either on it’s own. Nobody went into Haiku to make our ressource usage less efficient, that would be the only way bloat could accumulate under that definition of the term. It would also mean that the older and more buggy Haiku is the more bloated it is.
Everything you bring up is valid, but defining it in terms of bloat makes no sense, it’s basically a boogeyman word for “bad”.
UI responsiveness is the most important aspect of the perception of bloat, and that’s where we should focus on improving first where possible,l. After that, the measurable aspects like task duration, RAM usage, lazy loading, splitting tasks into multiple thread slots or processes, thread priority, better algorithms come into play. This is an area where Haiku can excel because we can prioritize UI responsiveness over getting tasks done faster, something server operating systems like Linux can’t or won’t do.
I’ve given a few concrete examples of bloat. While we can’t make a slow USB stick go faster, we can make the UI more responsive while you wait. Boot time is another example, it should be made as short as possible, even shorter than it is now, but this is a hard problem. I disagree that time to Desktop is not important, we can delay things so that the Desktop comes up faster, maybe not locale because we need that before we can display the first boot prompt, but loading other components can be pushed off until later to get you to the Desktop faster. HaikuDepot’s responsiveness while refreshing repositories can be made better.
To me this is what bloat means even if it is a bit of a pseudoscience.
1 Like
Maybe that is the problem. Bloat is a subjective measurement.
All your points are valid but, as nephele said, maybe not in respect to defining what would be bloat. The UI responsiveness comes much from the splitting of tasks in threads. For Haiku apps, not creating the necessary threads would be a bug. But for the ported apps ( Qt ones, etc ) , they do not have this thread-division, so they would still be heavy/slow.
As for time-to-desktop, at the point the Desktop is shown, what one needs from it must be ready to work. Or you get something like Windows10 : you see the desktop, try to open Explorer, and has to wait for many seconds ( minutes ? ) until the OS finishes loading other things, resident software, etc. From what I understand, loading the locale later would lead to showing things in one language first, then suddenly start to show them in the correct one ?
Well, that’s not how I understand it. To me, “bloat” is the degradation of these metrics for an equivalent task.
If we support more hardware drivers, the boot time goes up. But we do a lot more things during boot, scanning for all the new hardware. Likewise, the addition of localization resulted in several megabytes of extra data on the filesystem. This is a cost for new features, but, in general, I think it is justified by the extra functionality. Haiku wouldn’t be as popular if it did not support any new hardware, nor if it removed support for older hardware, nor if it was usable only in English.
So, yes, we can talk about these metrics, they are valid and useful, and we should optimize them. Now that’s something actionable. But if the approach to speed things up is to remove some features (at some point it will come to that), the discussion is completely different. We are, however, certainly not yet at that point, there is a number of things that can be improved without removing anything.
The next question is a matter of priorities: we can’t work on all things at once because there are only so many developers working on Haiku. So, what is the priority? Is it fixing bugs and releasing R1? Or is it investigating optimizations in RAM use, boot time, and user interface latency? Which one do we worry about first?
I appreciate that everyone holds us to very high standards, expecting that we make fast progress on both fronts. But, given the relatively small team (of volunteers, mainly, in case someone has forgotten about that) participating in Haiku, we can’t deliver things at the same speed as some other larger projects.
Personally I think we are doing good enough on the performance side (even if far from perfect). And we should work on fixing bugs and improving hardware support. So that’s the main things I try to work on. If someone has different priorities, they can work on the performance problems they find, I’m very happy about it too. See? That’s what’s nice about having no central leadership deciding what’s important to work on!
9 Likes
Hello, everyone. Been lurking for a while, but didn’t have a reason to join the forum until reading this thread.
I use Haiku on an ASUS EeePC 701. That’s a single-core 900MHz Atom with 512MB of RAM and 4GB of storage, on which Haiku fits with room to spare and runs plenty fast. I challenge anyone to find a modern, maintained Linux distribution that can make the same claim while being half as beautiful and friendly. (I can handle Alpine Linux or NetBSD, but people who haven’t done this for 23 years? Not so sure.)
Point is, if Haiku can be called “bloated”, then I’m not sure what counts as lightweight. DOS?
10 Likes
Just as an addendum: Thismeasurement is only the initial half of the story. Just stating that system uses x amount of some resource is not enough. It might be an indication that optimization could be possible. The second part is that one needs to identify what exactly is using those resources for what purpose. Only then you can identify parts that can be considered “bloat” and find ways to reduce it.
Another similar thing is that optimizing for one resource, e.g. reducing memory use, might increase use of other resources, e.g. disk access or CPU. Like the multi threading example to improve responsiveness, but doing things in parallel can increase RAM. Or if you hold data in RAM to avoid disk reads and increase performance and responsiveness.
Ported apps can have threads as well. And the general idea for a GUI app to run expensive tasks in threads and keep the GUI thread for GUI updates is the same everywhere, that’s not Haiku specific.
But of course the Haiku project should focus on its own apps, that’s what is under the project’s control. Just saying that issues of UI unresponsiveness can be reported to the developers of ported apps as well.
Well, sure, this is possible with other GUI frameworks as well. But in Haiku, the API is designed with this in mind, and makes working with multiple threads the path of least resistance. For example:
- Opening a window always starts a thread. There is no way to avoid that. Once the thread is there, you may as well use it properly and move big processing tasks to the main application thread.
- Creating threads using HAiku APIs forces you to select a priority, and gives you a set of reference for what the priority numbers mean (“display”, “background”, “realtime”, etc). In Linux, creating a thread just gets a default priority, and setting a specific one is optional, if at all possible. So, Haiku’s scheduler usually has more useful info for native apps to make the best decisions on scheduling (run the realtime threads first, then the “display” ones, and only then the background ones). This is very noticeable: on Linux, quite often when I run a heavy compiler job, my mouse pointer will stop moving, my music player will stutter, and so on, while the compilation job hogs all the CPU and RAM. On Haiku I never get into such situations, I can have a WebKit build running in the background for hours, and the system will still run just fine.
So, yes, it is absolutely possible to do this with other toolkits. But it has to be a very intentional decision there, whereas in Haiku, the APIs naturally push developers into that path.
5 Likes
Please quote where I state this.
You are accusing me of stating something that I have not, and are then using that made up statement to formulate an attack against me. Unfortunately you have a habit of doing exactly this and I have called you out on it multiple times. Yet you continue to do it. You are a dishonest individual. Shame on you.
@jscipione: You describe bloat pretty accurately. What Haiku needs is to start measure the system in terms of bloat and try to improve the situation.
Just because most major operating systems are more bloated than Haiku does not mean that Haiku is not bloated. It just means Haiku is less bloated.
My point was that time to desktop does not matter if it is not completely useable once you get there.
Currently in Haiku once you are on the desktop you can do whatever you want straight away, it feels very snappy.
I’ve seen other OS prioritize getting to the desktop so much that yes, the initial boot was measureably faster, but felt infinitely slower, since now after arriving at the desktop I now had to wait an indeterminate time before things actually started to work, applications start slow, windows pop up later that should have been there at the start etc.
I don’t think time to desktop on it’s own is a good optimization. Cutting boot time by not doing irrelevant stuff or ordering it differently or parralizing is nice, but the desktop must always work 100% once you are booted into it.
Is see two goals for the Haiku project:
- Re-create BeOS in open source form
- Make sure it continues to live on by continuing its development
Target 1 was necessary as a stepping stone for target 2, but it’s pretty pointless if it stands for itself. If we want to use BeOS on a system from 1999 we can just use BeOS now as it’s now abandonware and unlikely to be a licensing issue like it used to be right after Be’s demise. There is no modern web browser of course, but at the same time there also isn’t enough RAM for a modern website to fit.
For target 2, all the additions that have come are indisputably sensible and justified and have helped the system stay relevant and allow us to enjoy the spirit of BeOS on our modern hardware. Imagine the complaints if Haiku didn’t support USB for example. Or if it was called Haiku and didn’t even have Japanese IME. Or how much behind we would be on ports and stability without the package management system.
Of course a lot of people view it primarily as a lightweight OS to keep older hardware running, but the size increase has not been so much as to limit that type of use in a significant way. Besides, you’re still free to run older versions if you have something really ancient.
Bloat is not adding support for modern technology, bloat is rewriting half your user interface in Flash or running a node.js server and 5 other processes in the background even if your software isn’t even open (hello Adobe). Or installing and running an entire browser to implement a messenging app (hello Signal Desktop). Or linking with 20 libraries and connecting to 3 different cloud tracking servers on the internet just to display a hello world message on screen (hello YouTube mobile app programming tutorials). Or using Microsoft Word as a rendering engine to display HTML e-mails (hello Microsoft Outlook).
If someone wants to invest resources to optimize boot times, check for potential memory optimizations in the package kit or add a feature to the installer that unpacks packages for a non-packaged low-memory install of an English-only system with only essential drivers, they are welcome to do so, but in the current state, I would consider other parts of the system to be more deserving of developer attention.
4 Likes