Update

bloat.md

@@ -6,7 +6,7 @@ Bloat is a very wide term that in the context of [software](software.md) and [te
 
 The issue of bloat may of course appear outside of the strict boundaries of computer technology, nowadays we may already observe e.g. **[science bloat](science_bloat.md)** -- science is becoming so overcomplicated (many times on purpose, e.g. by means of [bullshit](bullshit.md) science) that 99% people can NOT understand it, they have to BELIEVE "scientific authorities", which does not at all differ from the dangerous blind religious behavior. Any time a new paper comes out, chances are that not even SCIENTISTS from the same field but with a different specialization will understand it in depth and have to simply trust its results. This combined with self-interest obsessed society gives rise to [soyence](soyence.md) and large scale brainwashing and spread of "science approved" propaganda.
 
-Some have attempted to measure bloat, e.g. the famous *web bloat score* (https://www.webbloatscore.com/) measures bloat of websites as its total size divided by the page screenshot size (e.g. [YouTube](youtube.md) at 18.5 vs suckless.org at 0.386). It has been observed that **software gets slower faster than hardware gets faster**, which is now known as [Wirth's law](wirths_law.md); this follows from [Moore's law](moores_law.md) (speed of hardware doubles every 24 months) being weaker than [Gate's](bill_gates.law) law (speed of software halves every 18 months); or in other words: the stupidity of soydevs outpaces the brilliancy of geniuses.
+Some have attempted to measure bloat, e.g. the famous *web bloat score* (https://www.webbloatscore.com/) measures bloat of websites as its total size divided by the page screenshot size (e.g. [YouTube](youtube.md) at 18.5 vs suckless.org at 0.386). It has been observed that **software gets slower faster than hardware gets faster**, which is now known as [Wirth's law](wirths_law.md); this follows from [Moore's law](moores_law.md) (speed of hardware doubles every 24 months) being weaker than [Gate's](bill_gates.law) law (speed of software halves every 18 months); or in other words: the stupidity of [soydevs](soydev.md) outpaces the brilliancy of geniuses.
 
 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.