Most are inherited from BeOS era. Design shows the age of some, for sure. Apart some problems with DockBert lately, I guess that most are working fine.
What? I’m not aware of any need for 3D acceleration for Youtube support in WebPositive. What it needs is better buffering and someone who knows how to use the media kit, to replace my terrible code to display video without doing proper media nodes because I don’t know how to do it.
There is no reason WebKit can’t render videos with the same performance as MediaPlayer, especially in fullscreen mode. Just needs someone to write that code…
3 Likes
I may have misspoken, 3d accelerated video playback is not required but may be utilized if available for example in Chrome, well at least as far as I can tell that’s the case. YouTube video playback can work without 3d acceleration at least for the VP9 and h.264 codecs YouTube uses, but the video plays more smoothly at higher frame rates when GPU 3d acceleration support is available in the browser.
Let me revise my statement, Haiku could use better browser support (or perhaps better Media Kit integration), and hardware acceleration separately, while “bloat” is less of a problem.
Are you talking about video decoding acceleration? That’s also provided by graphics chipset on PC hardware, but not on most ARM boards where it’s done by a separate unit. And the software stack is quite different (you will not need Mesa, but you will need vdpau which is handled by ffmpeg usually).
Anyway, the point I made is the same: if it works now in MediaPlayer, there is no reason it can’t work just as well in a web browser.
Maybe 3D acceleration can be useful in simulating overlays, where the vid o hardware can do the colorspace conversion and scaling to put the video in a window. We used to have support for overlays, but it’s another thing that modern video drivers didn’t bother or didn’t manage to implement
2 Likes
So you are gaslighting in favor of bloat??? Bloat IS measurable… you take a Linux distro from 2005, compile some test code see how much ram it uses, rinse and repeat over every year since then and you’ll get an increasing plot… for most programs (the same programs even).
Dunno by the same token why do you bother posting negatively in response to criticism every time rather than evaluating it and taking it to heart.
Sorry @cb88 but WHY do you USE a new Haiku if old Linux is so much better? And you fail to provide measurement. You just keep comparing with old Linux.
2 Likes
Bloat is a big issue in todays software world for both operating systems and applications. Haiku should strive to be as slimmed (install media size, installed size, memory usage, cpu usage) as possible by default. Let the user add whatever additional functionality they desire.
First step is to simply state a project rule that Haiku should not be bloated to be used when developing the OS.
That is a rather vague and possibly unenforceable rule. What is “bloat” in exact terms? How would people even know if a developer’s Haiku install is supposedly bloated? Heck, should it even be known what is on a developer’s system beyond just whatever’s essential for development and debugging?
2 Likes
Let’s delete all the code then. We’ll let you enter anything you want to run in hexadecimal, and you have to provide your own drivers. And in fact you should build your own computer to run it.
Everything else is just bloat. Computers should not have moved past the Apple I.
I hope you can see this gets us nowhere interesting. So next you will tell me the element of comparison is BeOS. To which I have already replied, if what you want is BeOS, you can continue using BeOS.
Now, if anyone has specific criticism (not vague accusations of “bloat”) about specific components, we can discuss it, and decide if the extra cost in CPU, RAM, etc of toe feature is worth it.
PackageFS? Definitely worth it to me
locale Kit? Definitely worth it to me
Qt, GTK? I just don’t install them on my machines
Anything else?
5 Likes
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