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-06-03 21:20:36 +02:00
parent 1ff8f3a311
commit 57e55a4737
11 changed files with 1763 additions and 1761 deletions
Download patch file Download diff file Expand all files Collapse all files

4
bloat.md
View file

@ -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.
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.
| 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 |
| ----- | ---------------------- | --------------------------------- | ------------------------ | ---------------------------------- | -------------------- | --------- |
@ -79,7 +79,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 note there may arise some disagreement among minimalist group 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 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 [heuristic](heuristic.md) 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 [suckless](suckless.md) programs are often judged):