Bloat
Bloat is a very wide term that in the context of [1]software and
[2]technology means overcomplication, unnecessary complexity and/or
extreme growth in terms of source code size, overall complexity, number of
[3]dependencies, [4]redundancy, unnecessary and/or useless features (e.g.
[5]feature creep) and resource usage, all of which lead to inefficient,
badly designed technology with [6]bugs (crashes, unusable features, memory
leaks, [7]security vulnerabilities, ...), as well as great [8]obscurity,
ugliness, loss of [9]freedom and waste of human effort. Simply put bloat
is burdening [10]bullshit. Bloat is extremely bad and one of the greatest
technological issues of today. Creating bloat is bad engineering at its
worst and unfortunately it is what's absolutely taking over all technology
nowadays, mostly due to [11]capitalism causing commercialization,
[12]consumerism, rushed "[13]just works" products, creating demand for
newer hardware and so on, also allowing incompetent people ("let's push
more women/minorities into programming") trying to take on jobs they are
in no way qualified to do.
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 etc.
Further on we'll rather focus on bloat as defined before.
TODO: history of bloat?
[14]LRS, [15]suckless and some others rather small groups are trying to
address the issue and write software that is good, [16]minimal, reliable,
efficient and well functioning. Nevertheless our numbers are very small
and in this endeavor we are basically standing against the whole world and
the most powerful tech [17]corporations. The issue lies not only in
capitalism pushing bloat but also in common people not seeing the issue
(partly due to the capitalist propaganda promoting [18]maximalism), no one
is supporting the few people who are genuinely trying to create good
tools, on the contrary such people often face hostility from the
mainstream.
The issue of bloat may of course appear outside of the strict boundaries
of computer technology, nowadays we may already observe e.g. [19]science
bloat -- science is becoming so overcomplicated (many times on purpose,
e.g. by means of [20]bullshit 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 [21]soyence and large scale brainwashing and spread
of "science approved" propaganda.
Some metrics traditionally used to measure bloat include [22]lines of
source code, [23]cyclomatic complexity (kind of "number of ways the code
may take"), [24]programming language used (some languages are bloated
themselves and inherently incapable of producing non-bloat, also choice of
language indicates the developer's priorities, skills etc.), number of
[25]dependencies (packages, libraries, hardware, ...), binary size (size
of the compiled program), compile time, resource usage ([26]RAM, CPU,
network usage, ...), performance ([27]FPS, responsiveness, ...), anti
features ([28]GUI, [29]DRM, auto updates, file formats such as [30]XML,
...), [31]portability, number of implementations, size of specification,
number of developers and others. Some have attempted to measure bloat in
more sophisticated ways, 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. [32]YouTube 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 [33]Wirth's law;
this follows from [34]Moore's law (speed of hardware doubles every 24
months) being weaker than [35]Gate's law (speed of software halves every
18 months); or in other words: the stupidity of [36]soydevs 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 [37]lines of code 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 [38]de facto 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. [39]GPU or 8GB of [40]RAM) 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.
avg. Windows min Debian FPS game min RAM Blender (win % of
year webpage RAM MB/CPU min RAM MB/CPU MHz/HDD MB zip KB) base
size (KB) MHz/HDD MB MB/HDD MB
1993 4 3, 25, 9 4, 20 4, 30, 24 (Doom) 100 100
(extrap.)
1994 8 3, 25, 9 4, 20 4, 33, 15 172 114
(Heretic)
1995 14 12, 25, 90 4, 20 4, 33, 16 307 263
(Descent)
1996 23 16, 33, 128 4, 80 8, 66, 25 (Duke 442 412
Nukem 3D)
1997 34 16, 33, 128 4, 90 16, 90, 25 (Quake 577 486
II)
1998 44 16, 33, 128 4, 90 24, 133, 400 712 715
(Half Life)
1999 53 32, 133, 5, 100 64, 233, 70, 8M 849 1817
1000 GPU (Quake III)
2000 63 32, 133, 5, 100 32, 233, 200, 4M 1170 1848
1000 GPU (Daikatana)
2001 74 64, 233, 5, 100 64, 300, 600, OGL 1323 2863
1500 GPU (Serious Sam)
2002 83 64, 233, 12, 110 256, 500, 2000, 1501 4055
1500 32M GPU (UT 2003)
2003 93 64, 233, 12, 120 128, 600, 1400, 1704 3569
1500 32M GPU (COD)
2004 115 64, 233, 12, 150 256, 1200, 6000, 4399 6345
1500 DX7 GPU (HL2)
2005 189 64, 233, 24, 450 512, 1700, 5000, 6353 7296
1500 64M GPU (FEAR)
2006 212 384, 800, 24, 450 512, 2000, 2000, 7277 22589
15000 64M GPU (Prey)
384, 800, 1024, 2000,
2007 260 15000 64, 1000 12000, 64M GPU 8639 28667
(Crysis)
384, 800, 1024, 2600,
2008 312 15000 64, 1000 12000, 256M GPU 12778 29411
(FC2)
1024, 1000, 2048, 2400,
2009 443 16000 64, 1000 13000, 128M GPU 13683 36063
(LFD2)
1024, 1000, 2048, 2400,
2010 481 16000 64, 1000 11000, 256M GPU 25059 36462
(BS2)
1024, 1000, 2048, 3000, 8000,
2011 657 16000 64, 1000 128M GPU 32398 36586
(Portal2)
1024, 1000, 2048, 2600,
2012 831 16000 64, 1000 15000, 512M GPU 45786 41143
(FC3)
1024, 1000, 3000, 2400,
2013 1102 16000 64, 1000 17000, 1G GPU 67787 47168
(Crysis 3)
1024, 1000, 4096, 2600,
2014 1249 16000 64, 1000 30000, 1G GPU 81676 57147
(FC4)
1024, 1000, 6000, 2900,
2015 1466 32000 128, 2000 60000, 1G GPU 104139 95734
(CODBO3)
4096, 1000, 8192, 3100,
2016 1502 64000 128, 2000 45000, 2G GPU 107840 141286
(Doom2016)
4096, 1000, 8192, 3300,
2017 1681 64000 128, 2000 90000, 2G GPU 116121 161379
(CODWW2)
4096, 1000, 8192, 3100,
2018 1848 64000 128, 2000 40000, 2G GPU 113915 140675
(FC5)
4096, 1000, 6000, 3400,
2019 1980 64000 550, 850 75000, 2G GPU 153290 154626
(BL3)
4096, 1000, 8192, 3100,
2020 2042 64000 550, 850 50000, 4G GPU 197632 154179
(Doom: E)
4096, 1000, 8192, 3100,
2021 2173 64000 780, 920 60000, 4G GPU 221865 161706
(FC6)
4096, 1000, 8192, 3300,
2022 2280 64000 780, 920 125000, 2G GPU 248477 191785
(CODMWF2)
One of a very frequent questions you may hear a noob ask is "How can bloat
limit software freedom if such software has a [41]free (or "[42]FOSS")
[43]license?" Bloat [44]de-facto limits some of the four essential
freedoms (to use, study, modify and share) required for a software to be
free. A free license grants these freedoms legally, but if some of those
freedoms are subsequently limited by other circumstances, the software
becomes effectively less free. It is important to realize that complexity
itself goes against [45]freedom because a more complex system will
inevitably reduce the number of people being able to execute freedoms such
as modifying the software (the number of programmers being able to
understand and modify a trivial program is much greater than the number of
programmers being able to understand and modify a highly complex million
[46]LOC program -- see [47]freedom distance). This is not any made up
reason, it is actually happening and many from the free software community
try to address the issue, see e.g. [48]HyperbolaBSD policies on accepting
packages which rejects a lot of popular "legally free" software on grounds
of being bloat ([49]systemd, dbus, zstd, protobuf, [50]mono,
https://wiki.hyperbola.info/doku.php?id=en:philosophy:incompatible_packages).
As the number of people being able to execute the basic freedom drops,
we're approaching the scenario in which the software is de-facto
controlled by a small number of people who can (e.g. due to the cost)
effectively study, modify and maintain the program -- and a program that
is controlled by a small group of people (e.g. a corporation) is by
definition [51]proprietary. If there is a web browser that has a free
license but you, a lone programmer, can't afford to study it, modify it
significantly and maintain it, and your friends aren't able to do that
either, when the only one who can practically do this is the developer of
the browser himself and perhaps a few other rich corporations that can pay
dozens of full time programmers, then such browser cannot be considered
free as it won't be shaped to benefit you, the user, but rather the
developer, a corporation.
How much bloat can we tolerate? We are basically trying to get the most
for the least price. The following diagram attempts to give an answer:
external
"richness"
A
shiny | : :
bullshit | NO : YES : NO
| : : ____... .
luxury | : : ___________/
| : : ________/
| : __:___/ \__________
very | : ____/ : \______
useful | : ___/ : \_..
| : __/ : path of degeneracy
| :_/ :
useful | _: :
| | : :
| / : :
does || : :
nothing +-----------------------------------------------------> internal complexity
trivial simple solo big huge gigantic
manageable
The path of [52]degeneracy 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 [53]soydevs, i.e. most
today's projects. { Thanks to a friend for pointing out this idea.
~drummyfish }
Please note there may arise some disagreement 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.
As a quick [54]heuristic for judging programs you can really take a look
at the lines of code (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 [55]suckless programs are
often judged):
* < 10: Extremely small but may be useful, may be also too trivial for
such small size to be justifiable, can aim to be completely bug-free.
Example could be the [56]cat program.
* 11 to 100: Very small, can be debugged to a great level, many greatly
useful utilities, e.g. [57]compression 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 [58]comun 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 [59]LRS programs like [60]SAF, [61]small3dlib and [62]comun 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
[63]BS. [64]Anarch 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 [65]tcc, the C compiler that
has a little over 20000 LOC. Also many "good old" mainstream programs
like [66]Doom fall here.
* more: Basically just [67]bloat, 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.
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 [68]bullshit
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 [69]Python,
[70]JavaScript, [71]C++, [72]Java, [73]OpenGL, [74]Vulkan, [75]GPU, [76]VR
sets, gigabytes of [77]RAM 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 [78]paper straws. 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 [79]version control systems, 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).
{ Fucking hell this shit has gone too far with the newest supershit gayme
called Cities Skyline II, I literally can't anymore, apparently the game
won't run smoothly even on Earth's most advanced supercomputer because, as
someone analyzed, the retarddevs use billion poly models for pedestrians
without any [80]LOD, I bet they don't even know what it is, they probably
don't even know what a computer is, these must be some extra retarded soy
idiots making these games now. Though I knew it would come to this and
that it will be getting yet much worse, I am always still surprised, my
brain refuses to believe anyone would let such a piece or monstrous shit
to happen. This just can't be real anymore. ~drummyfish }
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 [81]vim can be seen as a minimalist suckless editor when compared
to mainstream software ([82]IDEs), but at the same time it's pretty
bloated when compared to strictly [83]suckless programs.
* [84]Web since the onset of "web 2.0" has been steadily becoming more
and more bloated with things such as Adobe Flash and [85]JavaScript
(and billions of its web frameworks). By today the situation about web
bloat is reaching almost unbearable levels, especially in [86]modern
sites such as [87]YouTube. For a great read see [88]The Website
Obesity Crisis.
* Ads, [89]spyware, [90]DRM, anti-cheats, anti-viruses, anti-sharing,
anti-repair and other anti-user "features" are bloat.
* Desktop environments such as [91]KDE and [92]GNOME. The concept of a
[93]desktop environment itself is often considered bloat.
* [94]Windows: one of the best examples of how software should NOT be
done.
* [95]Blender: quite useful [96]FOSS 3D editor which however integrates
things like a whole video editor, game engine, several renderers,
scripting language with text editor and so on.
* [97]CMake: gigantic [98]build system that currently sits on top of a
sky-high sandwich of other build systems, its number of dependencies
is bigger than the number of retards in observable universe (known as
[99]drummyfish's number).
* [100]D-Bus
* [101]Docker
* [102]Electron: [103]GUI [104]framework infamous for its huge resource
consumption.
* [105]flatpak: Absolutely horrible "application distribution/execution
platform???" with pakcage management, [106]sandboxes and all that kind
of shit.
* [107]Systemd: Huge anti-[108]unix do-it-all system taking over
[109]GNU/[110]Linux.
* [111]Virtual machines/environments/sandboxes, big abstraction
sandwiches (e.g. program running in an interpreter running in a
sandbox inside web browser that's running in a virtual machine that's
running on an operating system).
* [112]Firefox, [113]Chromium and other mainstream web browsers.
* [114]Java, [115]Python and similar languages.
* [116]IDEs such as [117]VSCode or [118]NetBeans.
* Big [119]game engines such as [120]Unreal, [121]Unity or [122]Godot.
* Practically all commercial [123]games made in the [124]21st century
such as [125]World of Warcraft, Call of Duty etc.
* [126]pulse audio
* office programs (e.g. M$ Office and [127]LibreOffice) and a lot of
[128]rich text
* [129]Neural networks aka "AI" that is forced into everything nowadays.
* ...
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 [130]Ted, [131]Godot with
[132]Irrlicht, Firefox with [133]badwolf etc., however many times the
spectacular pompous results these programs produce just cannot essentially
be reproduced by anything minimal, wanting to achieve this is really a
beginner mistake, the same as wanting to achieve the "Windows experience"
on a GNU system. 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 indoctrination that "bigger results are better", 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 many people don't see as such but which
is nevertheless considered unnecessarily complex by some experts and/or
idealists and/or hardcore minimalists, including [134]us.
Small bloat is a subject of popular [135]jokes such as "OMG he uses a
unicode font -- BLOAT!!!". These are good jokes, it's nice 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. When we identify something as small bloat, we don't
necessarily have to completely avoid and reject that concept, we may just
try to for example make it optional. In context of today's PCs using a
Unicode font is not really an issue for performance, memory consumption or
anything else, but we should keep in mind it may not be so on much weaker
computers or for example post-[136]collapse computers, so we should try to
design systems that don't [137]depend on Unicode.
Also remember that relatively small libraries for things that are easily
done without a library, such as [138]fixed point arithmetic, are also
bloat.
Small/medium bloat includes for example:
* [139]floating point (complex standard with design issues, requires
special hardware for acceleration, [140]fixed point is better)
* config files (and other unnecessary file I/O that requires a file I/O
library, not all computers have file systems, configs should be part
of source code)
* [141]directories (just have all files on the same level and prefix
their file names to organize them)
* library [142]linking ([143]header only libraries are better)
* any [144]GPU, [145]OpenGL (complex hardware and specifications, not
all computers have complex GPUs, [146]software rendering is better)
* [147]Unicode (big specification requiring special libraries and big
fonts, [148]ASCII is better)
* [149]antialiasing (just ignore [150]aliasing, use low resolution
textures etc.)
* 64 bit architectures (they only exist to allow ungodly amounts of RAM,
32 bits completely suffice for any computation, many times even 16 or
8 bits are enough)
* [151]proportional font (fixed width font is better)
* [152]linking, build systems/scripts, [153]makefiles, directories and
multiple source code files (just using a compiler or a few-line
building shell script, single file source code, [154]header only
libraries and [155]single compilation unit programs are better)
* [156]infix notation ([157]postfix notation is better)
* any [158]GUI, [159]window managers (pure text mode is better)
* [160]operating system ([161]bare metal is better)
* [162]multithreading, [163]parallelism, [164]virtual memory, ...
* [165]encryption, [166]security, [167]memory safety (just don't care
and/or don't handle sensitive data with computers connected to the
internet, don't live in a shitty society)
* [168]X11 (just pure screen drawing is better)
* [169]database software (plain files are better, see [170]flatfile)
* [171]C (something in between C and [172]brainfuck would is likely
ideal, e.g. [173]comun or [174]Forth)
* [175]glibc, [176]gcc, [177]clang etc. (better alternatives are
[178]tcc, [179]musl, [180]uclibc etc.)
* letter accents/diacritics (can normally be ignored in most languages
that use them)
* [181]jpg, [182]png, [183]svg and similar formats (e.g. [184]ppm or
[185]farbfeld is better)
* [186]syntax highlight, text formatting, [187]rich text and just
[188]colors anywhere they aren't absolutely necessary
* [189]html, [190]markdown ([191]plain text is better)
* [192]x86 instruction set (TODO: what's better? probably some
[193]RISC)
* any non-[194]public-domain license (any legal burden introduced by a
license is unnecessary bloat)
* dynamic [195]linking/libraries (static linking is better, see
[196]Stali)
* [197]web 1.0, [198]gemini ([199]gopher or [200]FTP is better)
* [201]mouse (keyboard is better)
* [202]TCP ([203]UDP is probably better)
* [204]vim (things like [205]ed are probably better?)
* sound (picture is usually enough)
* high resolution (640x480 is probably the maximum you'll ever need,
lower resolution takes less RAM and makes rendering faster)
* [206]true color (256 colors, e.g. [207]332 palette, is better, even 1
bit displays suffice for most things), high [208]FPS (25 is more than
enough), high resolution ([209]320 x 240 is more than enough) etc.
* [210]GNU Unix utils (things like [211]busybox or [212]sbase are
probably better)
* [213]data types (untyped or single type is better, everything can be
just a [214]number)
* [215]package managers (just don't use them, install just a few
programs manually, or at least make package managers as simple as
possible)
* [216]electricity ([217]mechanical computers may be just fine)
* [218]computers (pen and paper or counting with [219]rocks is better)
* anything [220]wireless ([221]wifi, mice, ...)
* ...
Non-Computer Bloat
The concept of bloat can be applied even outside the computing world, e.g.
to non-computer technology, [222]art, [223]culture, [224]law etc. Here it
becomes kind of synonymous with [225]bullshit, but using the word bloat
says we're seeing the issue from the point of view of someone acquainted
with computer bloat. Examples include:
* [226]clothes
* decorations (body, house, ...)
* [227]cars
* using languages other than [228]English or [229]Esperanto
* luxury (big house, yacht with a swimming pool, ...)
* having electricity at home
* ...
See Also
* [230]harmful
* [231]maximalism
* [232]shitware
* [233]obscurity
* [234]shit
* [235]cyclomatic complexity
* [236]freedom distance
Links:
1. software.md
2. tech.md
3. dependency.md
4. redundancy.md
5. feature_creep.md
6. bug.md
7. security.md
8. obscurity.md
9. free_software.md
10. bullshit.md
11. capitalism.md
12. consumerism.md
13. just_werks.md
14. lrs.md
15. suckless.md
16. minimalism.md
17. corporation.md
18. maximalism.md
19. science_bloat.md
20. bullshit.md
21. soyence.md
22. loc.md
23. cyclomatic_complexity.md
24. programming_language.md
25. dependency.md
26. ram.md
27. fps.md
28. gui.md
29. drm.md
30. xml.md
31. portability.md
32. youtube.md
33. wirths_law.md
34. moores_law.md
35. bill_gates.law
36. soydev.md
37. loc.md
38. de_facto.md
39. gpu.md
40. ram.md
41. free_software.md
42. foss.md
43. license.md
44. de_facto.md
45. freedom.md
46. loc.md
47. freedom_distance.md
48. hyperbolabsd.md
49. systemd.md
50. mono.md
51. proprietary.md
52. degenerate_software.md
53. soydev.md
54. heuristic.md
55. suckless.md
56. cat.md
57. compression.md
58. comun.md
59. lrs.md
60. saf.md
61. small3dlib.md
62. comun.md
63. bullshit.md
64. anarch.md
65. tcc.md
66. doom.md
67. bloat.md
68. bullshit.md
69. python.md
70. js.md
71. cpp.md
72. java.md
73. opengl.md
74. vulkan.md
75. gpu.md
76. vr.md
77. ram.md
78. greenwashing.md
79. vcs.md
80. lod.md
81. vim.md
82. ide.md
83. suckless.md
84. web.md
85. javascript.md
86. modern.md
87. youtube.md
88. https://idlewords.com/talks/website_obesity.htm
89. spyware.md
90. drm.md
91. kde.md
92. gnome.md
93. de.md
94. windows.md
95. blender.md
96. foss.md
97. cmake.md
98. build_system.md
99. drummyfish.md
100. dbus.md
101. docker.md
102. electron.md
103. gui.md
104. framework.md
105. flatpak.md
106. sandbox.md
107. systemd.md
108. unix_philosophy.md
109. gnu.md
110. linux.md
111. vm.md
112. firefox.md
113. chromium.md
114. java.md
115. python.md
116. ide.md
117. vscode.md
118. netbeans.md
119. game_engine.md
120. unreal_engine.md
121. unity.md
122. godot.md
123. games.md
124. 21st_century.md
125. wow.md
126. pulse.md
127. libreoffice.md
128. rich_text.md
129. neural_network.md
130. ted.md
131. godot.md
132. irrlicht.md
133. badwolf.md
134. lrs.md
135. joke.md
136. collapse.md
137. dependency.md
138. fixed_point.md
139. float.md
140. fixed_point.md
141. directory.md
142. linking.md
143. header_only.md
144. gpu.md
145. opengl.md
146. software_rendering.md
147. unicode.md
148. ascii.md
149. antialiasing.md
150. aliasing.md
151. proportional_font.md
152. linking.md
153. make.md
154. header_only.md
155. single_compilation_unit.md
156. infix_notation.md
157. postfix_notation.md
158. gui.md
159. wm.md
160. os.md
161. bare_metal.md
162. multithreading.md
163. parallelism.md
164. virtual_memory.md
165. encryption.md
166. security.md
167. memory_safety.md
168. x11.md
169. database.md
170. flatfile.md
171. c.md
172. brainfuck.md
173. comun.md
174. forth.md
175. glibc.md
176. gcc.md
177. clang.md
178. tcc.md
179. musl.md
180. uclibc.md
181. jpg.md
182. png.md
183. svg.md
184. ppm.md
185. farbfeld.md
186. syntax_highlight.md
187. rich_text.md
188. color.md
189. html.md
190. md.md
191. plaintext.md
192. x86.md
193. risc.md
194. public_domain.md
195. linking.md
196. stali.md
197. web.md
198. gemini.md
199. gopher.md
200. ftp.md
201. mouse.md
202. tcp.md
203. udp.md
204. vim.md
205. ed.md
206. true_color.md
207. 332.md
208. fps.md
209. 320_240.md
210. gnu.md
211. busybox.md
212. sbase.md
213. data_type.md
214. number.md
215. package_manager.md
216. electricity.md
217. mechanical.md
218. computer.md
219. rock.md
220. wireless.md
221. wifi.md
222. art.md
223. culture.md
224. law.md
225. bullshit.md
226. clothes.md
227. car.md
228. english.md
229. esperanto.md
230. harmful.md
231. maximalism.md
232. shitware.md
233. obscurity.md
234. shit.md
235. cyclomatic_complexity.md
236. freedom_ditance.md