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!
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?
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.
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.
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.
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.
I am not here to make attacks, but to try to turn an unmeasurable complaint into something that can be quantified and with a reachable goal.
Someone was comparing Haiku to Linux from 2005. Maybe it was not you, in that case, I’m sorry, it’s hard to keep track when the discussihn is now split into 3 threads because some admins try to close threads and some users reopen new threads to continue the discussion anyways…
So, what is the goal here? How much RAM are we allowed to use for users (well, the 2 of you that complain about it, but let’s assume it is a wider demand) to stop saying Haiku is bloated? The current 300MB is apparently too much. But, you say (and I agree) that 20 years old hardware is not a valid argument. In 2003 I bought a system with 512MB of RAM, that still runs Haiku just fine today. So, it should be less than 300MB but more than 512?
Regarding boot time, I get less than 10 seconds. The easiest way toreduce this is to reduce the amount of syslog logging, but that comes at the cost of much less useful bugreports.
And finally in terms of disk size, it would be nice to fit the install on a CD, but also that’s a bit silly, all reasonaple target machines for Haiku will boot from USB (where a 2GB image really isn’t a problem) or a DVD. And, if you take a nightly build, I think tou can still fit it on a CD anyway (releases are larger only because of the inclusion of GPL sourcecode to ease GPL compliance when distributing physical media).
So, what is the goal we should set? Without setting one, we can spend infinite time on optimizations,which is not interesting.
I have never stated fixed targets. I have stated that Haiku should measure its accumulated bloat over time and try to minimize it as much as possible. Because it is a fact that the install media size is increasing, as is boot time, ram usage and the systems is getting slower. If this is allowed to continue Haiku will soon lose one of its biggest selling points; that it is lightweight and responsive.
A simple tool that measures some benchmarks metrics such as storage requirements, ram usage and computation time for different tasks should be run on different revisions to identify when bloat is being introduced so that it can be examined and remedied.
This could be offloaded to a second install media that is optional to download. Keep the base system small and compact and let the users chose what extra functionalities they want to install.
This is the key and part of the problem of this whole discussion; Haiku do not have fixed goals. The goal Haiku had has changed. Haiku needs to set fixed goals and stick to them.
Haiku got its initial goals for free from BeOS since the task was to re-implement what Be designed and created. That goal is long since completed, but yet we have seen no release. Haiku lack leadership causing the project to derail. Haiku needs to focus on releasing R1 with a predefined set of goals.
Out of curiosity, how feasible would it be to have a minimal Haiku image? Only ships with the absolute bare minimum required (crucial system apps + HaikuDepot), then someone can just add the rest of the system post-install as needed. Alternately, a minimal image wherein only the bare essentials are shipped and the user can just pick what else to add during install; any additions that a user picks will be downloaded during install. That second one is prolly the closest to the current images.
The consideration here is not install media size, but bad network conditions. If a fast or reliable network is unavailable, then it is better to initially have a smaller base image which can be added to later. Of course, some discussion regarding what constitutes as a crucial system app would need to happen first.
Installation should not in any way be dependent on internet resources. The install media should perform a complete install to a usable desktop. From there the user can chose to install additional functionality that requires internet access, for example via HaikuDepot.
Disagree, as on slow or unreliable networks it is better to download a smaller base image at first. Afterwards, pick only the additions someone wants. Compare this to a larger base image that includes stuff that a user doesn’t personally need.
On (for example) mobile data or non-Starlink satellite internet, downloading a larger base image may either take a very long time or not succeed at all even after multiple attempts. Whereas with a smaller base image, the download would be faster and it succeeding would be more likely with fewer attempts. Downloading only the wanted additions during install or post-install allows for smaller downloads to happen whenever most convenient.
Not saying that minimal images should go as far as netinstall images, but just have a bare minimum desktop and the package manager.
We have seen several, actually. The fact that these have been called Betas may not have been ideal for public perception, but objectively speaking, these have been very good and very stable, and each one a lot better than the one before. No R1 is only a problem if we are debating PR or semantics.
The problem with this is that the gpl mandates source code by the same distribution method be made available.
If you release a second source cd we need to keep that supplied for years if we make physical disks to distribute. If it is on the same disk then there is no need for this at all.
There is a minimum (or minimal, can’t never remember) profile if you build Haiku images yourself. So, very feasible, to the point that it is already done. We could make it even smaller and even less usable, too. The bootstrap image has even less things.
Now that’s also not very nice to me, because my paid job is (partially) working on satellite internet
It does not have to be this bad, and there are several companies besides Starlink who can do it too (with much less satellites). One of our customers provides video-on-demand services to cruise and container ships, and it works much better than you say.
Please do not give Starlink more credit than they deserve. And remember that they currently run more than half of the entire float of satellites orbiting the earth, with plans to have even more, so, in terms of efficiency and bloat (to pretend I’m still on topic), that’s… not great.
First of all, this is not a fact until someone has measured it. Especially for boot time and “the system is getting slower”. The other two are easy to check by looking at the past release images, even if that’s not many datapoints.
Anyway, I don’t think we can go back to how Haiku was in 2008 (alpha1), for reasons I have explained already: we just added A LOT more things to the OS since then, which can’t be done for free. We are already not making very fast progress on reaching R1, and in addition to that, we should make sure that whenever we add something to the OS, we should optimize something else to keep the memory footprint and image size exactly the same? I don’t think that can work, or at least it conflict with the other complaint that the project is derailing and not making any progress.
So, let’s have a look at the disk image. The file is 1.5GB but there is empty space in there (so you can do some things while using it live), in reality there is just a bit less than 1GiB of files (I’m checking the 64bit version here, the 32bit will have more due to hybrid builds which need a lot of things to be duplicated), of which:
336MiB of sourcecode for GPL compliance
125 MiB of “welcome” package + userguides in various languages
117 MiB of Noto japanese font (needed for our Japanese users to be able to see any text)
84 MiB of gcc and binutils
56MiB of LLVM (needed by modern Mesa)
33MiB for HaikuWebKit
(these numbers were obtained by mounting the beta4 release image with “diskimge register” and then looking at the biggest files and directories using DiskUsage).
If we remove all these things, that’s a whole 751MiB that can be removed from the image. What remains is 270 MiB of a core system that will work just fine, but without fast 3D rendering (you could install TinyGL as a replacement for Mesa), without japanese language support, and without an usable web browser (but you can install NetSurf which is quite a bit smaller than WebKit), and without documentation.
Personally, I think under 300MB for the core system is not bad at all.
So, what is a realistic plan here? Do we make plans to remove japanese language support, replace webkit with netsurf, and stop using any GPL software so we can remove the “sources” directory? If that’s not acceptable, then, where in the 270MB that remains is the bloat that we should look for?
Next, there is RAM usage. Let’s look at the minimal requirements.
All alpha releases had a minimum requirement of 128MB.
The first two betas doubled this to 256MB.
Finally, beta3 and 4 made it to 384MB.
First of all, we have to note that this is rounded to the nearest multiple of 128. So, what looks like a 3x increase over the span of 15 years (already not that bad) is in fact a bit less than that. And also, who is still running Haiku on hardware with less than 512MB of RAM? Is that a thing we should worry about? Do we lose many users because they have less than 384MB of RAM in their system and can’t run Haiku? I don’t think so. Even on 20 year old hardware, you will find yourself with enough RAM already.
Now, if someone wants to investigate where all this extra RAM went, they are sure welcome to do so, and we’ll merge the patches, if it doesn’t cost too big of a regression in other aspects (removal of features, making the system slower in the process by chosing slower but less memory intensive algorithms, etc). But I don’t think, at this point, it is a problem worth spending time on. Apparently no one thinks it is worth spending their own time on, some people do think it’s worth someone else spending their time on it, but that won’t get us anywhere closer to a solution.
This leaves the “boot time” and “system is getting slower” arguments, for which I will wait for someone to provide actual measurements, because I have spent enough time writing this reply already.
