Update

antialiasing.md

@@ -1,6 +1,6 @@
 # Antialiasing
 
-Antialiasing (AA) means preventing [aliasing](aliasing.mg), i.e. distortion of signal (images, audio, video, ...) caused by discrete sampling. Most people think antialiasing stands for "smooth edges in video game graphics", however that's a completely inaccurate understanding of antialiasing: yes, one of the most noticeable effects of 3D graphics antialiasing for a common human is that of having smooth edges, but smooth edges are not the primary goal, they are not the only effect and they are not even the most important effect of antialisng. Understanding antialiasing requires understanding what aliasing is, which is not a completely trivial thing to do (it's not the most difficult thing in the world either, but most people are just afraid of mathematics, so they prefer to stick with "antialiasing = smooth edges" simplification).
+Antialiasing (AA) means preventing [aliasing](aliasing.md), i.e. distortion of signal (images, audio, video, ...) caused by discrete sampling. Most people think antialiasing stands for "smooth edges in video game graphics", however that's a completely inaccurate understanding of antialiasing: yes, one of the most noticeable effects of 3D graphics antialiasing for a common human is that of having smooth edges, but smooth edges are not the primary goal, they are not the only effect and they are not even the most important effect of antialisng. Understanding antialiasing requires understanding what aliasing is, which is not a completely trivial thing to do (it's not the most difficult thing in the world either, but most people are just afraid of mathematics, so they prefer to stick with "antialiasing = smooth edges" simplification).
 
 The basic **sum up** is following: aliasing is a negative effect which may arise when we try to sample (capture) continuous signals potentially containing high frequencies (the kind of "infinitely complex" data we encounter in real world such as images or sounds) in discrete (non-continuous) ways by capturing the signal values at specific points in time (as opposed to capturing [integrals](integral.md) of intervals), i.e. in ways native and natural to [computers](computer.md). Note that the aliasing effect is mathematical and is kind of a "punishment" for our "[cheating](cheating.md)" which we do by trying to simplify capturing of very complex signals, i.e. aliasing has nothing to do with [noise](noise.md) or recording equipment imperfections, and it may occur not only when recording real world data but also when simulating real world, for example during 3D graphics rendering (which simulates capturing real world with a camera). A typical example of such aliasing effect is a video of car wheels rotating very fast (with high frequency) with a relatively low FPS camera, which then seem to be rotating very slowly and in opposite direction -- a high frequency signal (fast rotating wheels) caused a distortion (illusion of wheels rotating slowly in opposite direction) due to simplified discrete sampling (recording video as a series of photographs taken at specific points in time in relatively low FPS). Similar undesirable effects may appear e.g. on high resolution textures when they're scaled down on a computer screen (so called Moiré effect), but also in sound or any other data. Antialiasing exploits the mathematical Nyquist–Shannon sampling theorem that says that aliasing cannot occur when the sampling frequency is high enough relatively to the highest frequency in the sampled data, i.e. antialising tries to prevent aliasing effects typically by either preventing high frequency from appearing in the sampled data (e.g. blurring textures, see [MIP mapping](mipmap.md)) or by increasing the sampling frequency (e.g. [multisampling](multisampling.md)). As a side effect of better sampling we also get things such as smoothly rendered edges etc.
 

c.md

@@ -60,14 +60,14 @@ The standard library (libc) is a subject of live debate because while its interf
 Nothing is [perfect](perfect.md), not even C; it was one of the first relatively higher level languages and even though it has showed to have been designed extremely well, some things didn't age great, or were simply bad from the start. We still prefer this language as usually the best choice, but it's good to be aware of its downsides or smaller issues, if only for the sake of one day designing a better language. Keep in mind all here are just suggestions, they made of course be a subject to counter arguments and further discussion. So, let's go:
 
 - **C specification (the ISO standard) is [proprietary](proprietary.md)** :( The language itself probably can't be copyrighted, nevertheless this may change in the future, and a proprietary specs lowers C's accessibility and moddability (you can't make derivative versions of the spec).
-- **The specification is also long as fuck**, indicating some kind of [bloat](bloat.md). A good, free language should have a simple definition. It could be simplified a lot by simplifying the language itself as well as dropping some truly legacy considerations (like [BCD](bcd.md) systems?) and removing a lot of undefined behavior.
+- **The specification is also long as fuck**, indicating [bloat](bloat.md)/complexity/obscurity. A good, free language should have a simple definition. It could be simplified a lot by simplifying the language itself as well as dropping some truly legacy considerations (like [BCD](bcd.md) systems?) and removing a lot of undefined behavior.
 - **Some behavior is weird and has exceptions**, for example a function can return anything, including a `struct`, except for an array. This makes it awkward to e.g. implement vectors which would best be made as arrays but you want functions to return them, so you may do hacks like wrapping them instide a struct just for this.
 - **Some things could be made simpler**, e.g. using [reverse polish](reverse_polish.md) notation for expressions, rather than expressions with brackets and operator precedence, would make implementations much simpler, increasing sucklessness (of course readability is an argument).
 - **Some things could be dropped entirely** ([enums](enum.md), [bitfields](bitfield.md), possibly also unions etc.), they can be done and imitated in other ways without much hassle.
 - **The preprocessor isn't exactly elegant**, it has completely different syntax and rules from the main language, not very suckless -- ideally preprocessor uses the same language as the base language.
-- **The syntax is sucky**, e.g. data type names may consist of multiple tokens (`long long int` etc.), also it's pretty weird that the condition after `if` has to be in brackets, it could be designed better. Keywords also might be better being single chars, like `?` instead of `if` etc. A shorter, natural-language-neutral source code would be probably better. Both line and block comments could be implemented with a single character (e.g. `#` for line comment, ending with a newline or another `#`, `##` for block comment ending with another `##`?).
+- **The syntax is sucky sometimes**, e.g. data type names may consist of multiple tokens (`long long int` etc.), multiplication uses the same symbol as pointer dereference (`*`), also it's pretty weird that the condition after `if` has to be in brackets etc., it could be designed better. Keywords also might be better being single chars, like `?` instead of `if` etc. A shorter, natural-language-neutral source code would be probably better. Both line and block comments could be implemented with a single character (e.g. `#` for line comment, ending with a newline or another `#`, `##` for block comment ending with another `##`?).
-- **Some basic things that are part of libraries or extensions**, like fixed with types and binary literals and possibly very basic I/O (putchar/readchar) could be part of the language itself.
+- **Some undefined/unspecified behavior would maybe be better defined/specified** -- undefined behavior isn't bad in general, it is what allows C to be so fast and efficient in the first place, but some of it has shown to be rather cumbersome; for example the unspecified representation of integers, their binary size and behavior of floats leads to a lot of trouble (unknown upper bounds, sizes, undefined behavior of many operators etc.) while practically all computers have settled on using 8 bit bytes, [two's complement](twos_complement.md) and IEEE754 for [floats](float.md) -- this could easily be made a mandatory assumption which would simplify great many things without doing basically any harm. New versions of C actually already settle on two's complement. This doesn't mean C should be shaped to reflect the degenerate "[modern](modern.md)" trends in programming though!
-- **Some undefined behavior might be better defined** -- undefined behavior isn't bad in general, it is what allows C to be so fast and efficient in the first place, but some of it has shown to be rather cumbersome; for example the unspecified representation of integers, their binary size and behavior of floats leads to a lot of trouble (unknown upper bounds, sizes, undefined behavior of many operators etc.) while practically all computers have settled on using 8 bit bytes and [two's complement](twos_complement.md) -- this could easily be made a mandatory assumption which would simplify great many things without doing basically any harm. New versions of C actually already settle on two's complement. This doesn't mean C should be shaped to reflect the degenerate "[modern](modern.md)" trends in programming though!
+- Some basic things that are part of libraries or extensions, like fixed width types and binary literals and possibly very basic I/O (putchar/readchar), could be part of the language itself rather than provided by libraries.
 - All that stuff with *.c* and *.h* files is unnecessary, there should just be one file type -- this isn't part of the language per se, but it's part of its culture.
 - TODO: moar
 

c_tutorial.md

@@ -759,6 +759,8 @@ int main(void)
 }
 ```
 
+NOTE: `"library.h"` here is between double quotes, unlike `<stdio.h>`. This just says we specify an absolute path to the file as it's not in the directory where installed libraries go.
+
 Now we will manually compile the library and the final program. First let's compile the library, in command line run:
 
 ```
@@ -801,7 +803,7 @@ As a bonus, let's see a few useful compiler flags:
 
 Until now we've encountered simple data types such as `int`, `char` or `float`. These identify values which can take single atomic values (e.g. numbers or text characters). Such data types are called **[primitive types](primitive_type.md)**.
 
-Above these there exist **[compound data types](compound_type.md)** (also *complex* or *structured*) which are composed of multiple primitive types. They are necessary any advanced program.
+Above these there exist **[compound data types](compound_type.md)** (also *complex* or *structured*) which are composed of multiple primitive types. They are necessary for any advanced program.
 
 The first compound type is a structure, or **[struct](struct.md)**. It is a collection of several values of potentially different data types (primitive or compound). The following code shows how a struc can be created and used.
 
@@ -1178,9 +1180,9 @@ But beware, there may be too much new information in the first read. Don't get s
 
 Pointers allow us to do certain advanced things such as allocate dynamic memory, return multiple values from functions, inspect content of memory or use functions in similar ways in which we use variables.
 
-A **[pointer](pointer.md)** is nothing complicated: it is a **data type that can hold a memory address** (plus the information of what data type should be stored at that address). An address is simply a number. Why can't we simply use an `int` for an address? Because the size of `int` and a pointer may differ, the size of pointer depends on each platform's address width. It is also good when the compiler knows a certain variable is supposed to point to a memory (and to which type) -- this can prevent bugs.
+A **[pointer](pointer.md)** is essentially nothing complicated: it is a **data type that can hold a memory address** (plus an information about what data type should be stored at that address). An address is simply a number. Why can't we just use an `int` to store a memory address? Because the size of `int` and a pointer may differ, the size of pointer depends on each platform's address width. Besides this, as said, a pointer actually holds not only an address but also the information about the type it points to, which is a safety mechanism that will become clear later. It is also good when the compiler knows a certain variable is supposed to point to a memory rather than to hold a generic number -- this can all prevent bugs. I.e. pointers and generic integers are distinguished for the same reason other data types are distinguished -- in theory they don't have to be distinguished, but it's safer.
 
-It's important to remember that a pointer is not a pure address but it also knows about the data type it is pointing to, so there are many kinds of pointers: a pointer to `int`, a pointer to `char`, a pointer to a specific struct type etc.
+It is important to stress again that a pointer is not a pure address but it also knows about the data type it is pointing to, so there are many kinds of pointers: a pointer to `int`, a pointer to `char`, a pointer to a specific struct type etc.
 
 A variable of pointer type is created similarly to a normal variable, we just add `*` after the data type, for example `int *x;` creates a variable named `x` that is a pointer to `int` (some people would write this as `int* x;`).
 

chess.md

@@ -19,7 +19,7 @@ Chess as a game is not and cannot be copyrighted, but **can chess games (moves p
 
 ## Chess In General
 
-Chess evolved from ancient board games in India in about 6th century. Nowadays the game is internationally governed by **FIDE** which has taken the on role of an authority that defines the official rules: FIDE rules are considered to be the standard chess rules. FIDE also organizes tournaments, promotes the game and keeps a list of registered players whose performance it rates with so called Elo system –⁠ based on the performance it also grants titles such as **Grandmaster** (GM, strongest), **Internation Master** (IM, second strongest) or **Candidate Master** (CM).
+Chess evolved from ancient board games in India in about 6th century. Nowadays the game is internationally governed by **FIDE** which has taken the on role of an authority that defines the official rules: FIDE rules are considered to be the standard chess rules. FIDE also organizes tournaments, promotes the game and keeps a list of registered players whose performance it rates with so called Elo system –⁠ based on the performance it also grants titles such as **Grandmaster** (GM, strongest), **Internation Master** (IM, second strongest) or **Candidate Master** (CM). A game of chess is so interesting in itself that chess is usually not played for money like many other games ([poker](poker.md), [backgammon](backgammon.md), ...).
 
 A single game of chess is seen as consisting of three stages: **opening** (starting, theoretical "book" moves, developing pieces), **middlegame** (seen as the pure core of the game) and **endgame** (ending in which only relatively few pieces remain on the board). There is no clear border between these stages and they are sometimes defined differently, however each stage plays a bit differently and may require different skills and strategies; for example in the endgame king becomes an active piece while in the opening and middlegame he tries to stay hidden and safe.
 
@@ -61,10 +61,12 @@ Playing strength is not the only possible measure of chess engine quality, of co
 
 { Nanochess is actually pretty strong, in my testing it easily beat [smallchesslib](smallchesslib.md) Q_Q ~drummyfish }
 
-## Stats
+## Stats And Records
 
 Chess stats are pretty [interesting](interesting.md).
 
+{ Some chess world records are here: https://timkr.home.xs4all.nl/records/records.htm. ~drummyfish }
+
 **Number of possible games** is not known exactly, Shannon estimated it at 10^120 (lower bound, known as *Shannon number*). Number of possible games by plies played is 20 after 1, 400 after 2, 8902 after 3, 197281 after 4, 4865609 after 5, and 2015099950053364471960 after 15.
 
 Similarly the number of possibly reachable positions (position for which so called *proof game* exists) is not known exactly, it is estimated to at least 10^40 and 10^50 at most. Numbers of possible positions by plies is 20 after 1, 400 after 2, 5362 after 3, 72078 after 4, 822518 after 5, and 726155461002 after 11.
@@ -77,10 +79,17 @@ White wins about 38% of games, black wins about 34%, the remaining 28% are draws
 
 What is the **longest possible game**? It depends on the exact rules and details we set, for example if a 50 move rule applies, a player MAY claim a draw but also doesn't have to -- but if neither player ever claims a draw, a game can be played infinitely -- so we have to address details such as this. Nevertheless the longest possible chess game upon certain rules has been computed by [Tom7](tom7.md) at 17697 half moves in a paper for [SIGBOVIK](sigbovik.md) 2020.
 
-What's the most typical game? We can try to construct such a game from a game database by always picking the most common move in given position. Using the lichess database at the time of writing, we get the following incomplete game (the remainder of the game is split between four games, 2 won by white, 1 by black, 1 drawn):
+The longest game played in practice is considered to be the one between Nikolic and Arsovic from 1989, a draw with 269 moves lasting over 20 hours. For a shortest game there have been ones with zero moves; serious decisive shortest game has occurred multiple times like this: `1.d4 Nf6 2.Bg5 c6 3.e3 Qa5+` (white resigned).
+
+What's **the most typical game**? We can try to construct such a game from a game database by always picking the most common move in given position. Using the lichess database at the time of writing, we get the following incomplete game (the remainder of the game is split between four games, 2 won by white, 1 by black, 1 drawn):
 
 ```
-1. e4 e5 2. Nf3 Nc6 3. Bc4 Bc5 4. c3 Nf6 5. d4 exd4 6. cxd4 Bb4+ 7. Nc3 Nxe4 8. O-O Bxc3 9. d5 Bf6 10. Re1 Ne7 11. Rxe4 d6 12. Bg5 Bxg5 13. Nxg5 h6 14. Qe2 hxg5 15. Re1 Be6 16. dxe6 f6 17. Re3 c6 18. Rh3 Rxh3 19. gxh3 g6 20. Qf3 Qa5 21. Rd1 Qf5 22. Qb3 O-O-O 23. Qa3 Qc5 24. Qb3 d5 25. Bf1
+1. e4 e5 2. Nf3 Nc6 3. Bc4 Bc5 4. c3 Nf6 5. d4 exd4
+6. cxd4 Bb4+ 7. Nc3 Nxe4 8. O-O Bxc3 9. d5 Bf6 10. Re1 Ne7
+11. Rxe4 d6 12. Bg5 Bxg5 13. Nxg5 h6 14. Qe2 hxg5
+15. Re1 Be6 16. dxe6 f6 17. Re3 c6 18. Rh3 Rxh3
+19. gxh3 g6 20. Qf3 Qa5 21. Rd1 Qf5 22. Qb3 O-O-O
+23. Qa3 Qc5 24. Qb3 d5 25. Bf1
 ```
 
 You can try to derive your own stats, there are huge free game databases such as the Lichess [CC0](cc0.md) database of billions of games from their server.
@@ -120,7 +129,7 @@ Many other aspects come into the AI design such as opening books (databases of b
 
 The exact rules of chess and their scope may depend on situation, this is just a sum up of rules generally used nowadays.
 
-The start setup of a chessboard is following (lowercase letters are for black pieces, uppercase for white pieces, on a board with colored squares A1 is black):
+The start setup of a chessboard is following (lowercase letters are for black pieces, uppercase for white pieces (though many dislike this, for simplicity let's call pawns "pieces" too), on a board with colored squares A1 is black):
 
 ```
         _______________
@@ -138,7 +147,7 @@ The start setup of a chessboard is following (lowercase letters are for black pi
              files
 ```
 
-Players take turns in making moves, white always starts. A move consists of moving one (or in special cases two) of own pieces from one square to another, possibly capturing (removing from the board) one opponent's piece -- except for a special en passant move capturing always happens by moving one piece to the square occupied by the opposite color piece (which gets removed). Of course no piece can move to a square occupied by another piece of the same color. A move can NOT be skipped. A player wins by giving a **checkmate** to the opponent (making his king unable to escape attack) or if the opponent resigns. If a player is to move but has no valid moves, the game is a draw, so called **stalemate**. If neither player has enough pieces to give a checkmate, the game is a draw, so called **dead position**. There are additional situation in which game can be drawn (threefold repetition of position, 50 move rule). Players can also agree to a draw. A player may also be declared a loser if he cheated, if he lost on time in a game with clock etc.
+Players take turns in making moves, white always starts. A move consists of moving one (or in special cases two) of own pieces from one square to another, possibly capturing (removing from the board) one opponent's piece -- except for a special *en passant* move capturing always happens by moving one piece to the square occupied by the opposite color piece (which gets removed). Of course no piece can move to a square occupied by another piece of the same color. A move can NOT be skipped. A player wins by giving a **checkmate** to the opponent (making his king unable to escape attack) or if the opponent resigns. If a player is to move but has no valid moves, the game is a draw, so called **stalemate**. If neither player has enough pieces to give a checkmate, the game is a draw, so called **dead position**. There are additional situation in which game can be drawn (threefold repetition of position, 50 move rule). Players can also agree to a draw. A player may also be declared a loser if he cheated, if he lost on time in a game with clock etc.
 
 The individual pieces and their movement rules are:
 

double_buffering.md

@@ -2,6 +2,18 @@
 
 In [computer graphics](graphics.md) double buffering is a technique of rendering in which we do not draw directly to [video RAM](vram.md), but instead to a second "back buffer", and only copy the rendered frame from back buffer to the video RAM ("front buffer") once the rendering has been completed; this prevents flickering and displaying of incompletely rendered frames on the display. Double buffering requires a significant amount of extra memory for the back buffer, however it is also necessary for how graphics is rendered today.
 
+```
+  here we are                        this is seen
+    drawing                           on display 
+      |                                   |
+      V                                   V
+  .--------.   when drawing is done   .--------.
+  |        |      we copy this        |        |
+  |  back  | -----------------------> | front  |
+  | buffer |                          | buffer |
+  |________|                          |________|
+```
+
 In most libraries and frameworks today you don't have to care about double buffering, it's done automatically. For this reason in many frameworks you often need to indicate the end of rendering with some special command such as `flip`, `endFrame` etc. If you're going lower level, you may need to implement double buffering yourself.
 
 Though we encounter the term mostly in computer graphics, the principle of using a second buffer in order to ensure the result is presented only when it's ready can be applied also elsewhere.

game.md

@@ -1,12 +1,12 @@
 # Game
 
-In computer context game (also gayme, video game or vidya) is [software](software.md) whose main purpose is to be played and entertain the user. Of course, we can additionally talk about real life games such as [marble racing](marble_race.md). *Game* is also a mathematical term in [game theory](game_theory.md). Sadly most computer games are [proprietary](proprietary.md) and [toxic](toxic.md).
+In computer context game (also gayme, video game or vidya) is [software](software.md) whose main purpose is to be played and interactively entertain the user. Of course, we can additionally talk about [real life](irl.md) games such as [marble racing](marble_race.md) or [football](football.md). *Game* is also a mathematical term in [game theory](game_theory.md). Sadly most computer games are [proprietary](proprietary.md) and [toxic](toxic.md).
 
-Among [suckless](kiss.md) software proponents there is a disagreement about whether games are legit software or just a [meme](meme.md) and harmful kind of entertainment. The proponents of the latter argue something along the lines that technology is only for getting work done, that games are for losers, that they hurt [productivity](productivity_cult.md), are an unhealthy addiction, wasted time and effort etc. Those who like games see them as a legitimate form of relaxation, a form of art and a way of advancing technology along the way. The truth is that developing games leads to improvement of other kinds of software, e.g. for rendering, physics simulation or virtual reality. **We, [LRS](lrs.md), fully accepts games as legitimate software**; of course as long as their purpose is to help all people, i.e. while we don't reject games as such, we reject most games the industry produces nowadays.
+Among [suckless](kiss.md) software proponents there is a disagreement about whether games are legit software or just a [meme](meme.md) and harmful kind of entertainment. The proponents of the latter argue something along the lines that technology is only for getting work done, that games are for losers, that they hurt MUH [PRODUCTIVITY](productivity_cult.md), are an unhealthy addiction, wasted time and effort etc. Those who like games see them as a legitimate form of relaxation, a form of art and a way of advancing technology along the way. The truth is that developing games leads to improvement of other kinds of software, e.g. for rendering, physics simulation or virtual reality. **We, [LRS](lrs.md), fully accept games as legitimate software**; of course as long as their purpose is to help all people, i.e. while we don't reject games as such, we reject most games the industry produces nowadays.
 
 Despite arguments about the usefulness of games, most people agree on one thing: that the mainstream AAA games produced by big corporations are harmful, [bloated](bloat.md), [toxic](toxic.md), badly made and designed to be highly malicious, consumerist products. They are one of the worst cases of [capitalist software](capitalis_software.md). Such games are never going to be considered good from our perspective (and even the mainstream is turning towards classifying modern games as [shit](shit.md)).
 
-PC games are mostly made for and played on [MS Windows](windows.md) which is still the "gaming OS", even though in recent years we've seen a boom of "[Linux](linux.md) gaming", possibly thanks to Windows getting shittier and shittier every year. However, most games, even when played on [GNU](gnu.md)/Linux, are still [proprietary](proprietary.md), [capitalist](capitalist_software.md) and [bloated](bloat.md) as hell.
+PC games are mostly made for and played on [MS Windows](windows.md) which is still the "gaming OS", even though in recent years we've seen a boom of "[Linux](linux.md) gaming", possibly thanks to Windows getting shittier and shittier every year. Many normies nowadays are practicing "mobile gayming" which may be even worse. However, most games, even when played on [GNU](gnu.md)/Linux, are still [proprietary](proprietary.md), [capitalist](capitalist_software.md) and [bloated](bloat.md) as hell.
 
 We might call this the **great tragedy of games**: the industry has become similar to the industry of **drug abuse**. Games feel great and can become very addictive, especially to people not aware of the dangers (children). Today not playing latest games makes you left out socially, out of the loop, a weirdo. Therefore contrary to the original purpose of a game -- that of making life better and bringing joy -- an individual "on games" from the capitalist industry will crave to constantly consume more and more "experiences" that get progressively more expensive to satisfy. This situation is purposefully engineered by the big game producers who exploit psychological and sociological phenomena to enslave *gamers* and make them addicted. Games become more and more predatory and abusive and of course, there are no moral limits for corporations of how far they can go: games with [microthefts](microtransaction.md) and lootboxes, for example, are similar to gambling, and are often targeted at very young children. The game industry cooperates with the hardware and software industry to together produce a consumerist hell in which one is required to constantly update his hardware and software and to keep spending money just to stay in. The gaming addiction is so strong that even the [FOSS](foss.md) people somehow create a **mental exception** for games and somehow do not mind e.g. [proprietary](proprietary.dm) games even though they otherwise reject proprietary software. Even most of the developers of free software games can't mentally separate themselves from the concepts set in place by capitalist games, they try to subconsciously mimic the toxic attributes of such games (bloat, unreasonably realistic graphics and hardware demands, content consumerism, [cheating](cheating.md) "protection", language filters, ...).
 
@@ -26,19 +26,19 @@ Another kind of cool games are computer implementations of pre-computer games, f
 
 Games can be [suckless](suckless.md) and just as any other software should try to adhere to the [Unix philosophy](unix_philosophy.md). A [LRS](lrs.md) game should follow all the principles that apply to any other kind of such software, for example being completely [public domain](public_domain.md) or aiming for high [portability](portability.md). This is important to mention because, sadly, many people see games as some kind of exception among software and think that different technological or moral rules apply -- this is wrong.
 
-If you want to make a simple LRS game, there is an official LRS [C](c.md) library for it: [SAF](saf.md).
+If you want to make a simple LRS game, there is an official LRS [C](c.md) library for this: [SAF](saf.md).
 
 Compared to mainstream games, a LRS game shouldn't be a consumerist product, it should be a tool to help people entertain themselves and relieve their stress. From the user perspective, the game should be focused on the fun and relaxation aspect rather than impressive visuals (i.e. photorealism etc.), i.e. it will likely utilize simple graphics and audio. Another aspect of an LRS game is that the technological part is just as important as how the game behaves on the outside (unlike mainstream games that have ugly, badly designed internals and mostly focus on rapid development and impressing the consumer with visuals).
 
 The paradigm of LRS gamedev differs from the mainstream gamedev just as the [Unix philosophy](unix_philosophy.md) differs from the [Window philosophy](windows_philosophy.md). While a mainstream game is a monolithic piece of software, designed to allow at best some simple, controlled and limited user modifications, a LRS game is designed with [forking](fork.md), wild [hacking](hacking.md), unpredictable abuse and code reuse in mind. 
 
-Let's take an example. A LRS game of a real-time 3D [RPG](rpg.md) genre may for example consist of several independent modules: the RPG library, the game code, the content and the [frontend](frontend.md). Yes, a mainstream game will consist of similar modules, however those modules will probably only exist for the internal organization of work and better testing, they won't be intended for real reuse or wild hacking. With the LRS RPG game it is implicitly assumed that someone else may take the 3D game and make it into a purely non-real-time [command line](cli.md) game just by replacing the frontend, in which case the rest of the code shouldn't be burdened by anything 3D-rendering related. The paradigm here should be similar to that existing in the world of computer [chess](chess.md) where there exist separate engines, graphical frontends, communication protocols, formats, software for running engine tournaments, analyzing games etc. [Roguelikes](roguelike.md) and the world of [quake](quake.md) engines show some of this modularity, though not in such a degree we would like to see -- LRS game modules may be completely separate projects and different processes communicating via text interfaces through [pipes](pipe.md), just as basic Unix tools do. We have to think about someone possibly taking our singleplayer RPG and make it into an MMORPG. Someone may even take the game and use it as a research tool for [machine learning](machine_learning.md) or as a VFX tool for making movies, and the game should be designed so as to make this as easy as possible -- the user interface should be very simple to be replaced by an [API](api.md) for computers. The game should allow easy creation of [tool assisted speedruns](tas.md), to record demos, to allow [scripting](script.md), modifying ingame variables, even creating [cheats](cheat.md) etc. And, importantly, **the game content is a module as well**, i.e. the whole RPG world, its lore and storyline is something that can be modified, forked, remixed, and the game creator should bear this in mind.
+Let's take an example. A LRS game of a real-time 3D [RPG](rpg.md) genre may for example consist of several independent modules: the RPG library, the game code, the content and the [frontend](frontend.md). Yes, a mainstream game will consist of similar modules, however those modules will probably only exist for the internal organization of work and better testing, they won't be intended for real reuse or wild hacking. With the LRS RPG game it is implicitly assumed that someone else may take the 3D game and make it into a purely non-real-time [command line](cli.md) game just by replacing the frontend, in which case the rest of the code shouldn't be burdened by anything 3D-rendering related. The paradigm here should be similar to that existing in the world of computer [chess](chess.md) where there exist separate engines, graphical frontends, communication protocols, formats, software for running engine tournaments, analyzing games etc. [Roguelikes](roguelike.md) and the world of [quake](quake.md) engines show some of this modularity, though not in such a degree we would like to see -- LRS game modules may be completely separate projects and different processes communicating via text interfaces through [pipes](pipe.md), just as basic Unix tools do. We have to think about someone possibly taking our singleplayer RPG and make it into an MMORPG. Someone may even take the game and use it as a research tool for [machine learning](machine_learning.md) or as a VFX tool for making movies, and the game should be designed so as to make this as easy as possible -- the user interface should be very simple to be replaced by an [API](api.md) for computers. The game should allow easy creation of [tool assisted speedruns](tas.md), to record demos, to allow [scripting](script.md), modifying ingame variables, even creating [cheats](cheat.md) etc. And, importantly, **the game content is a module as well**, i.e. the whole RPG world, its lore and storyline is something that can be modified, forked, remixed, and the game creator should bear this in mind (see also [free universe](free_universe.md)).
 
-Of course, LRS games must NOT contain such shit as "[anti-cheating](anti_cheat.md) technology". For our stance on cheating, see the article [about it](cheat.md).
+Of course, LRS games must NOT contain such shit as "[anti-cheating](anti_cheat.md) technology", [DRM](drm.md) etc. For our stance on cheating, see the article [about it](cheat.md).
 
 ## Types Of Games
 
-Besides dividing games as any other software ([free](free_software.md) vs [proprietary](proprietary.md), [suckless](suckless.md) vs [bloat](bloat.md), ...) we can further divide them by the following:
+Besides dividing games as any other software ([free](free_software.md) vs [proprietary](proprietary.md), [suckless](suckless.md) vs [bloat](bloat.md), ...) we may further divide them by the following:
 
 - by genre:
   - [minigames](minigame.md)
@@ -102,11 +102,15 @@ Thankfully gameplay mechanisms cannot (yet) be [copyrighted](copyright.md) (howe
 
 Trademarks have been known to cause problems in the realm of libre games, for example in the case of Nexuiz which had to rename to [Xonotic](xonotic.md) after its original creator trademarked the name and started to make trouble.
 
+**Advice on cloning games**: copy only the gameplay mechanics, otherwise make it original and very different from the cloned game or else you're threading the fine legal lines. See this as an opportunity to add something new, something that's yours, and potentially to apply and exploit [minimalism](minimalism.md), i.e. if you're going to clone Doom, do not make a game about shooting demons from hell that's called Gnoom -- just take the gameplay and do something new, e.g. why not try to make it a mix of sci-fi and fantasy with procedurally generated levels which will additionally save you a lot of time on level design?
+
 ## Some Nice Gaymes
 
 [Anarch](anarch.md) and [microTD](utd.md) are examples of games trying to strictly follow the [less retarded](lrs.md) principles. [SAF](saf.md) is a less retarded game library/fantasy console which comes with some less retarded games such as [microTD](utd.md).
 
-{ I recommend checking out [Xonotic](xonotic.md), it's completely libre and one of the best games I've ever played. ~drummyfish }
+[Chess](chess.md) is pretty nice, if we can count it as a computer game.
+
+{ I recommend checking out [Xonotic](xonotic.md), it's completely libre and one of the best games I've ever played, though it's [bloat](bloat.md). ~drummyfish }
 
 ## See Also
 

linear_algebra.md

@@ -2,7 +2,7 @@
 
 In [mathematics](math.md) linear algebra is an extension of the classical elemental algebra (which means the basic "operations with numbers/variables") to [vectors](vector.md) and [matrices](matrix.md) (kind of "operations with arrays of numbers"). It is a basic tool of advanced mathematics and [computer science](computer_science.md) (and many other sciences) and at least at the very basic level should be known by every [programmer](programmer.md).
 
-Why is it called *linear* algebra? Basically because it deals with [linear equations](linear.md) which is kind of about proportionality, function plots being lines etc. A mathematician will probably puke at this explanation but it gives some intuition :) See also [linearity](linearity.md).
+Why is it called *linear* algebra? It is related to the concept of [linearity](linearity.md) which kind of has to do with "dealing with straight lines" (NOT curved ones), i.e. the results we get in linear algebra are more abstract equivalents of "straight lines", e.g. planes and hyperplanes, though this may be hard too see due to all the abstraction and higher dimensionality. { The concept of linearity has several possibly incompatible definitions and is kinda confusing (for example in whether the lines always have to pass through the origin). I was actually looking up "why is it called LINEAR algebra" and the above explanation is how I understood the answers I found. ~drummyfish }
 
 ## Basics