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 2024-03-25 22:26:49 +01:00
parent c0e7392173
commit dbf627285d
12 changed files with 1802 additions and 1751 deletions
Download patch file Download diff file Expand all files Collapse all files

35
bloat.md
View file

@ -14,6 +14,41 @@ 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 200 times despite computers being generally slower and less responsive.
| 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 |
| ----- | ---------------------- | --------------------------------- | ------------------------ | ---------------------------------- | -------------------- | --------- |
| 1993 | 4 | 3, 25, 9 | 4, 20 | 4, 30, 24 (Doom) | 100 (extrap.) | 100 |
| 1994 | 8 | 3, 25, 9 | 4, 20 | 4, 33, 15 (Heretic) | 172 | 114 |
| 1995 | 14 | 12, 25, 90 | 4, 20 | 4, 33, 16 (Descent) | 307 | 263 |
| 1996 | 23 | 16, 33, 128 | 4, 80 | 8, 66, 25 (Duke Nukem 3D) | 442 | 412 |
| 1997 | 34 | 16, 33, 128 | 4, 90 | 16, 90, 25 (Quake II) | 577 | 486 |
| 1998 | 44 | 16, 33, 128 | 4, 90 | 24, 133, 400 (Half Life) | 712 | 715 |
| 1999 | 53 | 32, 133, 1000 | 5, 100 | 64, 233, 70, 8M GPU (Quake III) | 849 | 1817 |
| 2000 | 63 | 32, 133, 1000 | 5, 100 | 32, 233, 200, 4M GPU (Daikatana) | 1170 | 1848 |
| 2001 | 74 | 64, 233, 1500 | 5, 100 | 64, 300, 600, OGL GPU (Serious Sam)| 1323 | 2863 |
| 2002 | 83 | 64, 233, 1500 | 12, 110 | 256, 500, 2000, 32M GPU (UT 2003) | 1501 | 4055 |
| 2003 | 93 | 64, 233, 1500 | 12, 120 | 128, 600, 1400, 32M GPU (COD) | 1704 | 3569 |
| 2004 | 115 | 64, 233, 1500 | 12, 150 | 256, 1200, 6000, DX7 GPU (HL2) | 4399 | 6345 |
| 2005 | 189 | 64, 233, 1500 | 24, 450 | 512, 1700, 5000, 64M GPU (FEAR) | 6353 | 7296 |
| 2006 | 212 | 384, 800, 15000 | 24, 450 | 512, 2000, 2000, 64M GPU (Prey) | 7277 | 22589 |
| 2007 | 260 | 384, 800, 15000 | 64, 1000 | 1024, 2000, 12000, 64M GPU (Crysis)| 8639 | 28667 |
| 2008 | 312 | 384, 800, 15000 | 64, 1000 | 1024, 2600, 12000, 256M GPU (FC2) | 12778 | 29411 |
| 2009 | 443 | 1024, 1000, 16000 | 64, 1000 | 2048, 2400, 13000, 128M GPU (LFD2) | 13683 | 36063 |
| 2010 | 481 | 1024, 1000, 16000 | 64, 1000 | 2048, 2400, 11000, 256M GPU (BS2) | 25059 | 36462 |
| 2011 | 657 | 1024, 1000, 16000 | 64, 1000 |2048, 3000, 8000, 128M GPU (Portal2)| 32398 | 36586 |
| 2012 | 831 | 1024, 1000, 16000 | 64, 1000 | 2048, 2600, 15000, 512M GPU (FC3) | 45786 | 41143 |
| 2013 | 1102 | 1024, 1000, 16000 | 64, 1000 |3000, 2400, 17000, 1G GPU (Crysis 3)| 67787 | 47168 |
| 2014 | 1249 | 1024, 1000, 16000 | 64, 1000 | 4096, 2600, 30000, 1G GPU (FC4) | 81676 | 57147 |
| 2015 | 1466 | 1024, 1000, 32000 | 128, 2000 | 6000, 2900, 60000, 1G GPU (CODBO3) | 104139 | 95734 |
| 2016 | 1502 | 4096, 1000, 64000 | 128, 2000 |8192, 3100, 45000, 2G GPU (Doom2016)| 107840 | 141286 |
| 2017 | 1681 | 4096, 1000, 64000 | 128, 2000 | 8192, 3300, 90000, 2G GPU (CODWW2) | 116121 | 161379 |
| 2018 | 1848 | 4096, 1000, 64000 | 128, 2000 | 8192, 3100, 40000, 2G GPU (FC5) | 113915 | 140675 |
| 2019 | 1980 | 4096, 1000, 64000 | 550, 850 | 6000, 3400, 75000, 2G GPU (BL3) | 153290 | 154626 |
| 2020 | 2042 | 4096, 1000, 64000 | 550, 850 |8192, 3100, 50000, 4G GPU (Doom: E) | 197632 | 154179 |
| 2021 | 2173 | 4096, 1000, 64000 | 780, 920 |8192, 3100, 60000, 4G GPU (FC6) | 221865 | 161706 |
| 2022 | 2280 | 4096, 1000, 64000 | 780, 920 |8192, 3300, 125000, 2G GPU (CODMWF2)| 248477 | 191785 |
One of a very frequent questions you may hear a noob ask is **"How can bloat limit software freedom if such software has a [free](free_software.md) (or "[FOSS](foss.md)") [license](license.md)?"** Bloat [de-facto](de_facto.md) 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 [freedom](freedom.md)** 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 [LOC](loc.md) program). 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. [HyperbolaBSD](hyperbolabsd.md) policies on accepting packages which rejects a lot of popular "legally free" software on grounds of being bloat ([systemd](systemd.md), dbus, zstd, protobuf, [mono](mono.md), 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 [proprietary](proprietary.md). 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: