I’ve read the Lunduke thread and I wanted to say something, but I think replying in the Lunduke thread is unhealthy if you understand what I mean. (You are free to do as you like, but I suggest to not mention Lunduke’s weird accusations in this thread.)
In my opinion Haiku is not bloat! Off course “bloat” is relative and if you compare Haiku to xv6 or a small Assembler OS, then Haiku is bloat. But compare Haiku to the Linux kernel, KDE, X Window etc. and then I think Haiku is not bloated at all.
And it is in my opinion not correct to call it bloat even if you look a Xlibe, Wine etc. because those are solutions to emulate bloatware in a rather compact way.
I totally agree with you here.
I read the Lunduke thread as well,but didn’t listen to his podcast and didn’t care enough so I decided not to reply there.
I really wonder why he,as a Linux user,is saying that Haiku is bloated.
Some of the software we optionally have in the Depot,like the GTK stuff with its mess of dozens of libraries,is of course bloat.
But it’s bloat that we imported from Linux to allow running more software,and it’s not installed by default and you can still run Haiku just fine without it.
Operating systems and other software has grown a lot over the years.
DOS could still fit on a floppy disk in the 90s and today even a CD is too small for most OSes.
I guess that’s because software is getting more features,and a lot more internal syscalls,POSIX compatibility stuff and hardware drivers have been added to all OSes over the years.
So yes,if you compare Haiku to DOS,you may think that it’s bloated,but compared to other modern OSes it totally isn’t.
Linux and Windows are bloat,one worse than the other,with telemetry bullshit and freedom restriction “features” probably taking up most of the space nowadays lol
Haiku is already well over twice as bloated as Linux was circa 2005… when I started playing with it (Linux).
I booted an entire system in 192MB ram including the mozilla suite and even flash. I had a debian install that was fine with 128MB ram in 2009. And by 90s standards these are all obscene amounts of ram. So, objectively Haiku is bloated. And a fairly fat puppylinux system with icewm in 64MB around the same time.
Relatively speaking Haiku is similar to a lightweightish Linux distro these days, but then those same distros are using 10-20x more ram than they were a 15 years ago for no apparent reason or benefit.
Bloat, is a fact, its measurable, and it is something we must work to keep at bay.
This discussion about “bloat” seems pretty strange to me. This isn’t a technical term or measurement and completely based on certain feelings that people have. This is all OK by itself, but surely not the best way to address real or perceived shortcomings of an OS.
So, here’s the challenge. Why doesn’t everybody that complains about “bloat” tell us exactly what they mean, and if possible support their complaints with performance data.
You repeatedly compare Haiku with old OSs, which shows that bloat is relative. You could compare it with CP/M and it is definitely bloat then.
And I think there ARE benefits/improvements if I look at the trend since the 90s. Like USB which was introduced 1996 and which evolved a lot since then.
I personally would define bloat at either (1) source code level (unneccesary code) or (2) binary “behaviour” like speed, RAM usage, disk usage, amount of processes.
And you can define both
a) relative to other OSs
or b) in context wether it is neccesary
Sometimes I would like to use something like Debian 7, Ubuntu 16, Windows XP, Windows Server 2003, or even BeOS, but I cannot.
Companies force me to “move up”.
Not too long ago, Amazon decided for me that it was time to trade in my old first generation Kindle Fire for something “more modern”. I now have a piece of locked down hardware that works perfectly.
I do occasionally use AmigaOS and MorphOS, but web tech drives operating systems into oblivion. I do appreciate your efforts at trying to keep HaikuWebKit more compact than the Linux/GTK port on Haiku. In the end, we may be better off trying to figure out ways to avoid web tech without requiring its direct usage.
It would be interesting to see what changes (outside of package management) had a significant negative impact on RAM usage and if these can maybe easily remedied. Also it would be helpful to know what specifically the term “bloat” in that criticism refers to.
It might be something simple like users reporting high RAM usage when unused RAM is used for caching, which means the OS is making sure unused RAM doesn’t get wasted and will free it up when it is needed for anything.
Comparing 32 bit OSes from the 1990ies vs. our current 64 bit systems might also skew perceived resource consumption since pretty much everything is automatically twice the size on a 64 bit system.
Another “big” thing is localization support, which requires including ICU libraries with a few megabytes of data, as well as somewhat large fonts, for example for Japanese characters rendering. The string lookup system is also not super efficient and will slow down apps startup (looking for catalog files in several places, and then finding the strings inside the catalogs which requires computing a hash of the english string and then finding it in the catalog hashmap).
The inclusion of the userguide translated in several languages also makes the disk use quite a bit higher than it was when we had no userguide.
Besides that, we keep adding new translators (no one wants to be stuck with just GIF and JPEG, right?), new media formats with ffmpeg updates, …
Compared to BeOS, we also have antialiasing in all drawing operations, a lot more drivers, a modern POSIX compatible kernel and C library that allows running a lot more software without spending weeks patching it for BeOS quirks, a Wifi stack, complete USB support, and I think that’s just the tip of the iceberg?
I’ve run Haiku on modern laptops with 512MB RAM - compiling large projects on multiple cores. Several UNIX-related desktop OSes needed around 512MB-1GB RAM around 15 years ago for daily productivity-related work. Expect the hard disk thrashing otherwise.
There are a few legacy drivers, old doc material, and apps now long in the tooth. In time, those things will get updated or discarded by someone doing the maintenance to trim the fat.
Yet, I can almost fit either the 32-bit or 64-bit Haiku snapshot releases on a single mini-DVD (i.e. 1.4GB). Last time that I checked, the last few Windows OS releases required double-sided DVDs. Most modern Linux desktop-focused distro releases won’t fit on a CD. Puppy Linux is an exception - but it is not focused on full-featured multimedia-related tasks.
ISO Comparisons (Y2023):
BeOS 5.0.3 Pro distribution - 736.5M ISO
Haiku R1B4 32-bit/64-bit - 1.4GB ISO
Haiku nightly distribution (ex. hrev57332) - 533 MB (32-bit) / 539 MB (64-bit) ISO
Linux Mint 21.2 “Victoria” - 2.8GB ISO
Manjaro KDE Linux distribution - 3.8GB ISO
Windows 95 distribution - 566 MB ISO
Windows XP distribution - 733 MB ISO
Windows Vista distribution - 3.4GB ISO
Windows 8.1 distribution - 3.0GB (32-bit) / 4.0GB (64-bit) ISO
Windows 10 distribution - 5.7GB (64-bit)
Windows 11 distribution - 4.9GB (64-bit)
Note: Haiku snapshot releases are compiled in a code debug state, not a non-debug code optimized state, therefore highly optimized speed comparisons are inconclusive with other code optimized OS distro releases.
Nobody noticed that apps menu is quickly bloated; it seems that everyone has found an alternative that suits them.
Perhaps, we could remove it and spare some ram.
I just wanted to say the same thing.
I don’t know what alternatives some people use,but I primarily use the apps menu to launch apps (except for CLI apps,but then I have to launch the Terminal using the apps menu first)
I was not really serious, you know. There are various docks and launchers available. I use QuickLaunch and LnLauncher, they don’t take a lot of space on screen.
Haiku could do a better job of limiting the RAM requirements and speeding up boot time if we wanted to, but that simply has not been the priority of any devs, because IMHO it’s not a big deal. If you feel that bloat is a big deal, there is room for improvement here and we welcome these kinds of enhancements. That being said, I’m currently not losing any sleep over our “bloated” 512MB RAM recommendation.
What is a big deal IMHO is hardware 3d acceleration and a better web browser, both of which are currently being worked on. These go hand-in-hand because one of the things holding up our web browser is being able to connect to YouTube because it expects 3d support so it can do accelerated transparency effects and tap into video codex’s that utilize the GPU to render video.
