drummyfish/less_retarded_wiki
5
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update

Browse source
This commit is contained in:
Miloslav Ciz 2025-04-14 21:57:02 +02:00
parent 5604db85d2
commit d8f1711fa8
33 changed files with 2096 additions and 2036 deletions
Download patch file Download diff file Expand all files Collapse all files

6
bloat.md
View file

@ -1,8 +1,8 @@
# Bloat
Bloat is a very wide term that in the context of [software](software.md) and [technology](tech.md) means overcomplication, unnecessary complexity and/or extreme growth in terms of source code size, overall complexity, number of [dependencies](dependency.md), [redundant](redundancy.md) code, unnecessary and/or useless features (e.g. [feature creep](feature_creep.md)) and use of computational resources (memory, [CPU](cpu.md) time, electricity, ...), all of which lead to inefficient, badly designed, unstable, hard to [maintain](maintenance.md) and downright dangerous technology littered with [bugs](bug.md) (crashes, unusable features, memory leaks, [security](security.md) vulnerabilities, ...), [obscurity](obscurity.md), ugliness, further leading to **loss of [freedom](free_software.md)** and waste of human effort. In simpler words: bloat is burdening [bullshit](bullshit.md) so to speak. Bloat is immensely bad and one of the most prominent technological issues of [today](21st_century.md). For an individual, be it programmer or user, to deal with bloat is always a sickening descent into madness and for a programmer to participate in creation of bloat is not just shameful, but shows obnoxiously shitty engineering at its worst and complete lack of understanding of basic philosophy of technology. And yet bloat prospers and stains not just 100% of [mainstream](mainstream.md) programs (commercial or not), but also the better majority of non-mainstream projects seeking to be engineered well. Bloat is what has completely taken over all technology nowadays, it has now reached galactic proportions mostly due to [capitalism](capitalism.md) induced commercialization, [consumerism](consumerism.md), rushed "[just works](just_werks.md)" products, creating demand for newer hardware and so on, and also pushing incompetent people ([women](woman.md), minorities etc.) to do work they lack mental capacity for.
Bloat is a very broad term that in the context of [software](software.md) and [technology](tech.md) means overcomplication, unnecessary complexity and/or extreme growth in terms of source code size, overall complexity, number of [dependencies](dependency.md), [redundant](redundancy.md) code, unnecessary and/or useless features (e.g. [feature creep](feature_creep.md)) and use of computational resources (memory, [CPU](cpu.md) time, electricity, ...), all of which lead to inefficient, badly designed, unstable, hard to [maintain](maintenance.md) and downright dangerous technology littered with [bugs](bug.md) (crashes, unusable features, memory leaks, [security](security.md) vulnerabilities, ...), [obscurity](obscurity.md), ugliness, further leading to **loss of [freedom](free_software.md)** and waste of human effort. In simpler words: bloat is burdening [bullshit](bullshit.md) so to speak. Bloat is immensely bad and one of the most prominent technological issues of [today](21st_century.md). For an individual, be it programmer or user, to deal with bloat is always a sickening descent into madness and for a programmer to participate in creation of bloat is not just shameful, but shows obnoxiously shitty engineering at its worst and complete lack of understanding of basic philosophy of technology. And yet bloat prospers and stains not just 100% of [mainstream](mainstream.md) programs (commercial or not), but also the better majority of non-mainstream projects seeking to be engineered well. Bloat is what has completely taken over all technology nowadays, it has now reached galactic proportions mostly due to [capitalism](capitalism.md) induced commercialization, [consumerism](consumerism.md), rushed "[just works](just_werks.md)" products, creating demand for newer hardware and so on, and also pushing incompetent people ([women](woman.md), minorities etc.) to do work they lack mental capacity for.
A related but different term is **bloatware**; it's more commonly used among normie users and stands for undesirable programs that eat up computer resources, usually being preinstalled by the computer manufacturer (and often uninstallable) etc. Further on we'll rather focus on bloat as defined before.
A related but technically distinct term is **bloatware**; it's more commonly used among normie users and stands for undesirable programs that eat up computer resources, usually being preinstalled by the computer manufacturer (and often uninstallable) etc. Further on we'll rather focus on bloat as defined before.
A bit of [history](history.md): overcomplicated and obfuscated technology has always been known to suck, however it seems like only with the arrival of personal computers it started to become a world wide [cancer](cancer.md) and absolutely serious threat to society. Some dictionaries date the first use of the word *bloatware* to the beginning of [1990s](90s.md), around the time when mainstreamization of computers began ([web](web.md), [Doom](doom.md), [Windows](windows.md), ...), specifically 1991 by *Business Week*. [Goolag](google.md) trends for terms *bloatware* and *software bloat* show an increased search frequency since the year 2010 (which [we](lrs.md) see more or less as the year when the downfall of society started) and peak around 2015. As for the term *bloat* itself it's hard to find the exact moment at which it started to be used in today's sense, the word *bloat* is a normal word and has likely been used in computer speech since the dawn of computer era, though originally (judging by some 1989 [usenet](usenet.md) posts) more for "files getting big", "email box getting clogged" etc., however by 2007 the suckless website already talks about *bloated* software as in "overly complex source code with bullshit features".
@ -14,7 +14,7 @@ Some metrics traditionally used to measure bloat include **[lines of source code
Despite this there isn't any completely objective measure that would say "this software has exactly X % of bloat", bloat is something judged based on what we need/want, what tradeoffs we prefer etc. The answer to "how much bloat" there is depends on the answer to **"what really is bloat?"**. To answer this question most accurately we can't limit ourselves to simplifications such as [lines of code](loc.md) or number of package dependencies -- though these are very good estimates for most practical purposes, a more accurate insight is obtained by carefully asking what *burdens* and *difficulties* of ANY kind come with given technology, and also whether and how much of a necessary evil they are. Realize for example that if your software doesn't technically require package X to run or be compiled, package X may be [de facto](de_facto.md) required for your software to exist and work (e.g. a pure multiplayer game client won't have the server as a dependency, but it will be useless without a server, so de facto all bloat present in the server is now in a wider sense also the client's burden). So if you've found a program that's short and uses no libraries, you still have to check whether the language it is written in isn't bloated itself, whether the program relies on running on a complex platform that cannot be implemented without bloat, whether some highly complex piece of hardware (e.g. [GPU](gpu.md) or 8GB of [RAM](ram.md)) is required, whether it relies on some complex Internet service etc. You can probably best judge the amount of bloat most objectively by asking the following: if our current technology instantly disappeared, how hard would it be to make this piece of technology work again? This will inevitably lead you to investigating how hard it would be to implement all the dependencies etc.
For a quick overview let us average some data over time -- the table that follows shows growth of system requirements and sizes and averages them to give an estimate of bloat ratio with respect to the first row. Please note some data in the table may not be completely accurate, interpolation/extrapolation was used for missing values, we're only making an estimate after all, but still notice our computing resource usage already grew almost 2000 times despite computers being generally slower and less responsive from the user's perspective.
For a brief overview let us average some data over time -- the table that follows shows growth of system requirements and sizes and averages them to give an estimate of bloat ratio with respect to the first row. Please note some data in the table may not be completely accurate, interpolation/extrapolation was used for missing values, we're only making an estimate after all, but still notice our computing resource usage already grew almost 2000 times despite computers being generally slower and less responsive from the user's perspective.
| year | avg. webpage size (KB) | Windows min RAM MB/CPU MHz/HDD MB | Debian min RAM MB/HDD MB | FPS game min RAM MB/CPU MHz/HDD MB | Blender (win zip KB) | % of base |
| ----- | ---------------------- | --------------------------------- | ------------------------ | ---------------------------------- | -------------------- | --------- |