Update

bloat.md

@@ -78,7 +78,7 @@ One of a very frequent questions you may hear a noob ask is **"How can bloat lim
 
 The **path of [degeneracy](degenerate_software.md)** drawn in the graph shows how from a certain breaking point (which may actually appear at different places, the diagram is simplified) many software projects actually start getting less powerful and useful as they get more complex -- not all, some project really do stay on the path of increasing their "richness", but this requires great skills, experience, expertise and also a bit of lucky circumstances; in the zone of huge complexity projects start to get extremely difficult to manage -- non-primary tasks such as organization, maintenance and documentation start taking up so many resources that the primary task of actually programming the software suffers, the project crumbles under its own weight and the developers just try to make it fall slower. This happens mostly in projects made by incompetent [soydevs](soydev.md), i.e. most today's projects. { Thanks to a friend for pointing out this idea. ~drummyfish }
 
-Please do note there may arise disagreements among minimalist groups about where the band is drawn exactly, especially old Unix hackers could be heard arguing for allowing (or even requiring) even trivial programs, maybe as long as the source code isn't shorter than the utility name, but then the discussion might even shift to questions like "what even is a program vs what's just a 10 characters long line" and so on.
+Please do note there may arise disagreements among minimalist groups about where the line is drawn exactly, especially old Unix hackers could be heard arguing for allowing (or even requiring) even trivial programs, maybe as long as the source code isn't shorter than the utility name, but then the discussion might even shift to questions like "what even is a program vs what's just a 10 characters long line" and so on.
 
 As a quick [heuristic](heuristic.md) for judging programs you can really take a look at the [lines of code](loc.md) (as long as you know it's a simplification that ignores dependencies, formatting style, language used etc.) and use the following classes (basically derived from how [suckless](suckless.md) programs are often judged):
 
@@ -86,9 +86,9 @@ As a quick [heuristic](heuristic.md) for judging programs you can really take a
 - 11 to 100: Very small, can be debugged to a great level, many greatly useful utilities, e.g. [compression](compression.md) programs, may fit this class.
 - 101 to 1000: Small "bigger" kinds of programs, often very minimalist implementations of programs that are usually not minimalist in nature like window managers, interactive text editors, web browsers and so on. Simplified version of [comun](comun.md) language, called *minicomun*, fits here.
 - 1001 to 5000: Still considered small, a bit more "feature rich" kind of previous class, you may find minimalist 3D games here, quite powerful programming languages, libraries handling complex file formats (that weren't designed to be minimalist) etc. Currently a lot of [LRS](lrs.md) programs like [SAF](saf.md), [small3dlib](small3dlib.md) and [comun](comun.md) would fall here.
-- 5001 to 10000: Often imposed upper limit on suckless programs, these programs aren't the smallest possible but may still be called minimalist, they are easily manageable by a single man without much hassle, anyone can modify them and there is a comfortable margin for implementing many "comfort" and fancy features that aren't complete [BS](bullshit.md). [Anarch](anarch.md) might be given as an example (if we subtract lines of code taken by game data and count only pure engine code).
-- 10001 to 100000: Here things start to be called real bloat but may still be accepted as a compromise, not an "insanely bloated" program, we have to judge on a case by case basis as the transition towards bloat is gradual, but generally projects here must focus on not growing bigger, priority should be on minimizing. We have to consider anything here bloat unless proven otherwise. Minimalist projects end up here when trying to combine minimalism with some mainstream concept, e.g. implementing a complete operating system with all the standard features, trying to reimplement some mainstream, non-minimalist program etc. Example is [tcc](tcc.md), the C compiler that has a little over 20000 LOC. Also many "good old" mainstream programs like [Doom](doom.md) fall here.
-- more: Basically just [bloat](bloat.md), some operating systems can perhaps argue they are comparatively small even within this category, but as a matter of fact very few people can manage a codebase this big, issues of bloat start to play a very significant role here, the project should most likely be split or rewritten from scratch in much more simplified way.
+- 5001 to 10000: Often imposed upper limit on suckless programs. These guys aren't the most minimal under the Sun but may still be called minimalist, they are easily manageable by a single man without any significant pain, anybody can fork and modify the code and there is a comfortable margin for patching up additional "quality of life" features that aren't absolute [BS](bullshit.md). [Anarch](anarch.md) may be provided as an example here (if we subtract lines of code taken by game data and count only pure engine code).
+- 10001 to 100000: Here code starts to smell and things may start ringing the bloat alarm but still this stuff may be accepted as a compromise, not an "insanely bloated" program, we have to judge on a case by case basis as the transition towards bloat is gradual, but generally projects here must focus on not growing bigger, priority should be on minimizing and bullshit pruning. We have to consider anything here bloat unless proven otherwise. Minimalist projects end up here when trying to combine minimalism with some mainstream concept, e.g. implementing a complete operating system with all the standard features, trying to reimplement some mainstream, non-minimalist program etc. Example is [tcc](tcc.md), the C compiler that has a little over 20000 LOC, or [Licar](licar.md). Also many "good old" mainstream programs like [Doom](doom.md) fall here.
+- more: 99.99% pure [bloat](bloat.md), some operating systems can perhaps argue they are comparatively small even in this weight category, but as a matter of fact very few can manage a codebase this big without becoming slaves, bloat is likely the most severe problem of the [project](project.md), the devs should seriously consider splitting it or rewritting from scratch in much more simplified way.
 
 Yes, **bloat is also unecological** and no, it cannot be fixed by replacing fossil fuel cars with cars that run on grass and plastic computers by computers made from recycled cardboards mixed with composted horse shit. It is the immense volume of human ACTIVITY that's required by the bloated technology all around the globe that's inherently unecological by wasting so much effort, keeping focus on maximalism, growth and preventing us from frugality and minimizing resource waste. Just as any other [bullshit](bullshit.md) that requires immense resources to just keep maintaining -- great complexity is just absolutely incompatible with ecology and as much as you dislike it, to achieve truly eco-friendly society we'll have to give up what we have now in favor of something orders of magnitude more simple and if you think otherwise, you are just yet too unexperienced (or remained purposefully ignorant) to have seen the big picture already. Consider that your program having bullshit dependencies such as [Python](python.md), [JavaScript](js.md), [C++](cpp.md), [Java](java.md), [OpenGL](opengl.md), [Vulkan](vulkan.md), [GPU](gpu.md), [VR](vr.md) sets, gigabytes of [RAM](ram.md) etcetc. requires having the inherently unecological system up, it needs millions of people doing bullshit jobs that are inherently wasting resources, increasing CO2 and making them not focus on things that have to be done -- yes, even if we replace plastic straws with [paper straws](greenwashing.md). All those people that make the thousand pages standards that are updated every year, reviews of those standards, writing tons and tons of tests for implementations of those standards, electing other people to make those standards, testing their tests, implementing the standards themselves, optimizing them, all of that collectively needing many billions of lines of code and millions of hours of non-programming activities, it all requires complex bureaucracy, organization and management (complex [version control systems](vcs.md), wikis, buildings, meeting spaces, ...) and communication tools and tons of other bullshit recursively spawning more and more waste -- all of these people require cars to go to work every day (even if some work from home, ultimately only a few can work from home 100% of the time and even so millions others need to physically go to factories to make all those computers, electricity, chair, food and other things those people need), they require keeping a high bandwidth 100% uptime global Internet network maintained, all of this requiring extra buildings, offices, factories, roads, buildings for governments overseeing the building of those buildings, maintenance of those roads etcetc. A newbie programmer (99.99999% programmers in the field nowadays) just don't see all this because they lack the big picture, a woman forced into programming has hard time comprehending an if statement, how do you expect her to see the deep interconnections between technology and society -- she may know that OpenGL is "something with graphics" and it's just there on every computer by default, she can't even picture the complexity that's behind what she sees on the screen. Hence the overall retardation. You just cannot have people living ecologically and at the same time have what we have now. So yes, by supporting and/or creating bloat you are killing the planet, whether you agree with it or not. No, you can't find excuses out of this, no, paper straws won't help, just admit you love point and click "programming without math" of your own shitty Minecraft clones in Godot even for the price of eliminating all life on Earth, that's fine (no it's not but it's better to just not bullshit oneself).
 
@@ -96,7 +96,7 @@ Yes, **bloat is also unecological** and no, it cannot be fixed by replacing foss
 
 ## Typical Bloat
 
-The following is a list of software usually considered a good, typical example of bloat. However keep in mind that bloat is a relative term, for example [vim](vim.md) can be seen as a minimalist suckless editor when compared to mainstream software ([IDEs](ide.md)), but at the same time it's pretty bloated when compared to strictly [suckless](suckless.md) programs.
+The list in this section shows examples of software usually considered a well illustrative example of bloat. However keep in mind that bloat is a relative term, for example [vim](vim.md) can be seen as a minimalist suckless editor when compared to mainstream software ([IDEs](ide.md)), but at the same time it's pretty bloated when compared to strictly [suckless](suckless.md) programs.
 
 - [Web](web.md) since the onset of "web 2.0" has been steadily becoming more and more bloated with things such as Adobe Flash and [JavaScript](javascript.md) (and billions of its web frameworks). By today the situation about web bloat is reaching almost unbearable levels, especially in [modern](modern.md) sites such as [YouTube](youtube.md). For a great read see [The Website Obesity Crisis](https://idlewords.com/talks/website_obesity.htm).
 - Ads, [spyware](spyware.md), [DRM](drm.md), anti-cheats, anti-viruses, anti-sharing, anti-repair and other anti-user "features" are bloat.
@@ -117,16 +117,17 @@ The following is a list of software usually considered a good, typical example o
 - Practically all commercial [games](games.md) made in the [21st century](21st_century.md) such as [World of Warcraft](wow.md), Call of Duty etc.
 - [pulse audio](pulse.md)
 - office programs (e.g. M$ Office and [LibreOffice](libreoffice.md)) and a lot of [rich text](rich_text.md)
-- [Neural networks](neural_network.md) aka "AI" that is forced into everything nowadays.
+- [Neural networks](neural_network.md) AKA "AI" that is forced into everything nowadays.
+- [PBR](pbr.md) (physically based rendering) 3D engines
 - ...
 
-Some of these programs may be replaced with smaller bloat that basically does the same thing (e.g. produces the same output) just with less bullshit around, for example Libreoffice with [Ted](ted.md), [Godot](godot.md) with [Irrlicht](irrlicht.md), Firefox with [badwolf](badwolf.md) etc., however many times the spectacular pompous results these programs produce just cannot essentially be reproduced by anything minimal, wanting to achieve such a result is then a mistake in itself, committed usually by beginners and minimalist newcomers, the same as wanting to achieve the "Windows experience" on a [GNU](gnu.md) system for example. You will never be able to make an Unreal Engine style graphics with a minimalist game engine, just like you won't be able to shoot up your school with well written poetry (in both cases the former is something bad that however most Americans want to do, the latter is something truly good they should want instead). To truly get rid of bloat one has to become able to use truly minimal programs; this means unlearning the doctrine that preaches "bigger results = better results", one has to understand that minimal results themselves are superior AND in addition allow using superior programs (i.e. minimal ones).
+Some of said programs may be replaced with smaller bloat that does practically the same job (e.g. in terms of output) just with less bullshit around (e.g. with simpler GUI, or no GUI at all), for example Libreoffice with [Ted](ted.md), [Godot](godot.md) with [Irrlicht](irrlicht.md), Firefox with [badwolf](badwolf.md) etc., however many times the spectacular pompous results these programs produce just cannot essentially be reproduced by anything minimal, wanting to achieve such a result is then a mistake in itself, committed usually by beginners and minimalist newcomers, the same as wanting to achieve the "Windows experience" on a [GNU](gnu.md) system for example. You will never be able to make an Unreal Engine style graphics with a minimalist game engine, just like you won't be able to shoot up your school with well written poetry (in both cases the former is something bad that however most Americans want to do, the latter is something truly good they should want instead). To truly do away with bloat one must learn to live only with minimalist programs and need only results they can produce; that means unlearning the "bigger = better" doctrine, one has to understand that minimal results themselves are superior AND in addition allow using superior programs (i.e. minimal ones).
 
 ## Medium And Small Bloat
 
 Besides the typical big programs that even normies admit are bloated there exists also a smaller bloat which most humanoids probably don't identify as such but that is nonetheless still considered unnecessarily complex by experts and/or idealists and/or hardcore minimalists, including [us](lrs.md).
 
-Small bloat is a subject of popular [jokes](joke.md) such as "OMG he uses a [Unicode](unicode.md) font -- BLOAT!!!". These are good jokes, it's healthy to make fun out of one's own idealism. But watch out, this doesn't mean small bloat is only a joke concept at all, it plays an important role in designing good technology. Having categorized something as *small bloat* doesn't necessarily imply us having to completely avoid and reject the thing or concept, we may just try to mitigate the impact, for example by making it an optional choice. In context of today's PCs using a Unicode font is not really an issue for performance, memory consumption or anything in these terms, but we should keep in mind it may not be so on much weaker computers or for example post-[collapse](collapse.md) computers, and using Unicode implies someone has to make and maintain the Unicode standard, which IS a tedious, difficult and resource hungry task for humans, so we should try to design systems that don't [depend](dependency.md) on Unicode if at all possible.
+Small bloat has traditionally been a subject of popular [jokes](joke.md) such as "OMG he uses a [Unicode](unicode.md) font -- BLOAT!!!". These are good jokes, it's healthy to make [fun](fun.md) out of one's own idealism. But watch out, this doesn't mean small bloat is only a joke concept at all, it plays an important role in designing good technology. Having categorized something as *small bloat* doesn't necessarily imply us having to completely avoid and reject the thing or concept, we may just try to mitigate the impact, for example by making it an optional choice. In context of today's PCs using a Unicode font is not really an issue for performance, memory consumption or anything in these terms, but we should keep in mind it may not be so on much weaker computers or for example post-[collapse](collapse.md) computers, and using Unicode implies someone has to make and maintain the Unicode standard, which IS a tedious, difficult and resource hungry task for humans, so we should try to design systems that don't [depend](dependency.md) on Unicode if at all possible.
 
 Also please remember that relatively small libraries for things that are easily done without a library, such as [fixed point](fixed_point.md) arithmetic, are also bloat. This is a case of [pseudominimalism](pseudominimalism.md).