Update

bootstrap.md

@@ -19,7 +19,7 @@ Bootstrapping has to start with some initial prerequisite machine dependent bina
 
 1. **Make a [simple](kiss.md) [programming language](programming_language.md) L**. You can choose e.g. the mentioned [Forth](forth.md) but you can even make your own, just remember to keep it extremely simple -- simplicity of the base language is the key feature here. If you also need a more complex language, write it in L. The language L will serve as tool for writing software for your platform, i.e. it will provide some comfort in programming (so that you don't have to write in assembly) but mainly it will be an **[abstraction](abstraction.md) layer** for the programs, it will allow them to run on any hardware/platform. The language therefore has to be **[portable](portability.md)**; it should probably abstracts things like [endianness](byte_sex.md), native integer size, control structures etc., so as to work nicely on all [CPUs](cpu.md), but it also mustn't have too much abstraction (such as [OOP](oop.md)) otherwise it will quickly get complicated. The language can compile e.g. to some kind of very simple [bytecode](bytecode.md) that will be easy to translate to any [assembly](assembly.md). Make the bytecode very simple (and document it well) as its complexity will later on determine the complexity of the bootstrap binary seed. At first you'll have to temporarily implement L in some already existing language, e.g. [C](c.md). NOTE: in theory you could just make bytecode, without making L, and just write your software in that bytecode, but the bytecode has to focus on being simple to translate, i.e. it will probably have few opcodes for example, which will be in conflict with making it at least somewhat comfortable to program on your platform. However one can try to make some compromise and it will save the complexity of translating language to bytecode, so it can be considered ([uxn](uxn.md) seems to be doing this).
 2. **Write L in itself, i.e. [self host](self_hosting.md) it**. This means you'll use L to write a [compiler](compiler.md) of L that outputs L's bytecode. Once you do this, you have a completely independent language and can start using it instead of the original compiler of L written in another language. Now compile L with itself -- you'll get the bytecode of L compiler. At this point you can bootstrap L on any platform as long as you can execute the L bytecode on it -- this is why it was crucial to make L and its bytecode very simple. In theory it's enough to just interpret the bytecode but it's better to translate it to the platform's native machine code so that you get maximum efficiency (the nature of bytecode should make it so that it isn't really more diffiult to translate it than to interpret it). If for example you want to bootstrap on an [x86](x86.md) CPU, you'll have to write a program (L compiler [backend](backend.md)) that translates the bytecode to x86 assembly; if we suppose that at the time of bootstrapping you will only have this x86 computer, you will have to write the translator in x86 assembly manually. If your bytecode really is simple and well made, it shouldn't be hard though (you will mostly be replacing your bytecode opcodes with given platform's machine code opcodes). Once you have the x86 backend, you can completely bootstrap L's compiler on any x86 computer.
-3. **Further help make L bootstrapable**. This means making it even easier to execute the L bytecode on any given platform -- you may for example write backends (the bytecode translators) for common platforms like x86, ARM, RISC-V, C, Lisp and so on. At this point you have L bootstrappable without any [work](work.md) on the platforms for which you provide backends and on others it will just take a tiny bit of work to write its own translator.
+3. **Further help make L bootstrapable**. This means making it even easier to execute the L bytecode on any given platform -- you may for example write backends (the bytecode translators) for common platforms like x86, ARM, RISC-V, C, Lisp and so on. You can also provide tests that will help check newly written backends for correctness. At this point you have L bootstrappable without any [work](work.md) on the platforms for which you provide backends and on others it will just take a tiny bit of work to write its own translator.
 4. **Write everything else in L**. This means writing the platform itself and software such as various tools and libraries. You can potentially even use L to write a higher level language (e.g. C) for yet more comfort in programming. Since everything here is written in L and L can be bootstrapped, everything here can be bootstrapped as well.
 
 ## Booting: Computer Starting Up

collision_detection.md

@@ -1,21 +1,27 @@
 # Collision Detection
 
-Collision detection is an essential problem e.g. of simulating physics of mechanical bodies in [physics engines](physics_engine.md) (but also elsewhere), it tries to detect whether (and also how) geometric shapes overlap. Here we'll be talking about the collision detection in physics engines, but the problem appears in other contexts too (e.g. [frustum culling](frustum_culling.md) in [computer graphics](graphics.md)). Collision detection potentially leads to so called *collision resolution*, a different stage that tries to deal with the detected collision (separate the bodies, update their velocities, make them "bounce off"). Physics engines are mostly divided into 2D and 3D ones so we also normally either talk about 2D or 3D collision detection (3D being, of course, a bit more complex).
+Geometric collision detection is a fundamental problem in certain types of programs, most notably those simulating physics of mechanical bodies ([physics engines](physics_engine.md)) -- collision detection means computing whether (and also how) geometric shapes (most typically either in a 2D or 3D space) overlap. This article will be considering collision detection in physics engines, but the problem (and its solutions) appears in other contexts as well (e.g. [frustum culling](frustum_culling.md) in [computer graphics](graphics.md), [raytracting](raytracting.md) and so on). Collision detection is but one phase of simulating physics, it may further lead to so called *collision resolution*, a different phase that tries to deal with the detected collision (i.e. separate the bodies, update their velocities, make them "bounce off" etc.). Again, here we'll just be talking about pure collision detection. A physics engine will most likely be either 2D or 3D, hence we'll mostly be examining predominantly one of these two cases -- it probably won't surprise anyone that the 3D case is generally more complex.
 
 There are two main types of collision detection:
 
-- **[discrete](discrete.md)**: Detecting collisions only at one point in time (each engine tick or "frame") -- this is easier but can result in detecting the collisions in wrong ways or missing them completely (imagine a fast flying object that in one moment is wholly in front of a wall and at the next instant wholly behind it). Nevertheless this is completely usable, one just has to be careful enough about the extreme cases.
+- **[discrete](discrete.md)**: Detecting collisions only at one point in time (each engine tick or "frame") -- this is easier but can result in detecting the collisions in wrong ways or missing them completely (imagine a fast flying object that in one moment is wholly in front of a wall and at the next instant wholly behind it -- collision won't be detected even though the object should have crashed into the wall). Nevertheless this is completely usable, one just has to be careful enough about the extreme cases.
-- **[continuous](continuous.md)**: Detecting collisions considering the continuous motion of the bodies (still done at discrete ticks but considering the whole motion since the last tick) -- this is more difficult to program and more costly to compute, but also correctly detects collisions even in extreme cases. Sometimes engines perform discrete detection by default and use continuous detection in special cases (e.g. when speeds become very high or in other error-prone situations). Continuous detection can be imagined as a collision detection of a higher dimensional bodies where the added dimension is time -- e.g. detecting collisions of 2D circles becomes detecting collisions of "tubes" in 3D space. If you don't want to go all the way to implementing continuous collisions, you may consider an in-between solution by detecting collisions in smaller steps (which may also be done only sometimes, e.g. only for high speed bodies or only when an actual discrete collision is detected).
+- **[continuous](continuous.md)**: Detecting collisions considering the continuous motion of the involved bodies (still done at discrete ticks but considering the whole motion since the last tick) -- this is more difficult to program and more costly to compute, but also correctly detects collisions even in extreme cases. Sometimes engines perform discrete detection by default and use continuous detection in special cases (e.g. when speeds become very high or in other error-prone situations). Continuous detection can be imagined as a collision detection of a higher dimensional bodies where the added dimension is time -- e.g. detecting collisions of 2D circles becomes detecting collisions of "tubes" in 3D space. If you don't want to go all the way to implementing continuous collisions, you may consider an in-between solution by detecting collisions in smaller steps (which may also be done only sometimes, e.g. only for high speed bodies or only when an actual discrete collision is detected).
 
-Collision detection is non-trivial and in many cases really hard because we need to detect NOT JUST the presence of the collision but also its parameters which are typically the exact **point of collision, collision depth and collision [normal](normal.md)** (but potentially also other ones, depending on what we're doing, e.g. volume of overlap etc.) -- these are needed for subsequently resolving the collision (typically the bodies will be shifted along the normal by the collision depth to become separated and [impulses](impulse.md) will be applied at the collision point to update their velocities). We also need to detect **general cases**, i.e. not just collisions of surfaces but of WHOLE VOLUMES (imagine e.g. a tiny cuboid inside an arbitrarily rotated bigger cone). This is very hard and/or expensive for some complex shapes such as general 3D triangle meshes (which is why we approximate them with simpler shapes), but even for relatively simple shapes like arbitrarily rotated 3D boxes the solution is not easy. We also want the detection algorithm to be at least reasonably **fast** -- for this reason collision detection mostly happens in two phases:
+Collision detection is non-trivial and usually quite difficult to implement for several reasons. For example we may need to detect NOT JUST the presence of the collision but also its additional parameters which are typically the exact **point of collision, collision depth and collision [normal](normal.md)** (and maybe even more, depending on what we're doing, e.g. volume of overlap etc.) -- this is because these parameters are normally needed for subsequently resolving the collision (the bodies will be shifted along the normal by the collision depth to become separated and [impulses](impulse.md) will be applied at the collision point to update their velocities). Here we may have to make some additional decisions, for example if we'll require the point of collision to lie on the surface of both bodies or if we'll just want the "averaged point of collision" (note that we'll practically never detect the bodies touching in exactly one point, normally we'll be detecting an overlapped volume); then we also want to define what exactly the depth of collision means (do we want the maximum or depth along the normal?), what to do if something doesn't make sense (like a collision normal in point-point collision) and so on. However that's not nearly all, collision detections are hard because we need to detect **general cases**, i.e. not just collisions of body surfaces but of WHOLE VOLUMES (imagine e.g. a tiny cuboid inside an arbitrarily rotated bigger cone -- the surfaces don't collide but the bodies do). This may be mathematically quite hard and even if we find the solution, it may just be slow -- for example precise collision detection of arbitrary 3D triangle meshes are just impractically difficult, which is why we approximate them with simpler shapes, but even for relatively simple shapes like arbitrarily rotated 3D boxes the solution is still not as easy as it may seem at first glance. And as if this wasn't enough of a hassle, we will typically have to write not one, but many detection algorithms, each one for every possible pair of bodies that may collide -- so for example if we have spheres, boxes and capsules, we have to write detection algorithms for sphere-sphere, sphere-box, sphere-capsule, box-box, box-capsule and capsule-capsule. For *N* shapes we'll need *(N^2 + N) / 2* algorithms.
+
+Wanting our algorithms to be at least somewhat **fast**, we perform an [optimization](optimization.md) by dividing this into two phases:
 
 - **broad phase**: Quickly estimates which bodies MAY collide, usually with [bounding volumes](bounding_volume.md) (such as spheres or [axis aligned bounding boxes](aabb.md)) or space indexing and algorithms such as *[sweep and prune](sweep_and_prune.md)*. This phase quickly opts-out of checking collision of objects that definitely CANNOT collide because they're e.g. too far away.
 - **narrow phase**: Applying the precise, expensive collision detection on the potentially colliding pairs of bodies determined in the broad phase. This yields the real collisions.
 
 In many cases it is also important to correctly detect the **order of collisions** in time -- it may well happen a body collides not with one but with multiple bodies at the time of collision detection and the computed behavior may vary widely depending on the order in which we consider them. Imagine that body *A* is colliding with body *B* and body *C* at the same time; in [real life](real_life.md) *A* may have first collided with *B* and be deflected so that it would have never hit *C*, or the other way around, or it might have collided with both. In continuous collision detection we know the order as we also have exact time coordinate of each collision (even though the detection itself is still computed at discrete time steps), i.e. we know which one happened first. With discrete collisions we may use [heuristics](heuristic.md) such as the direction in which the bodies are moving, but this may fail in certain cases (consider e.g. collisions due to rotations).
 
-**On shapes**: general rule is that **mathematically simpler shapes are better for collision detection**. Spheres (or circles in 2D) are the best, they are stupidly simple -- a collision of two spheres is simply decided by their [distance](distance.md) (i.e. whether the distance of their center points is less that the sum of the radia of the spheres), which also determines the collision depth, and the collision normal is always aligned with the vector pointing from one sphere center to the other. So **if you can, use spheres** -- it is even worth using multiple spheres to approximate more complex shapes if possible. [Capsules](capsule.md) ("extruded spheres"), infinite planes, half-planes, infinite cylinders (distance from a line) and axis-aligned boxes are also pretty simple. Cylinders and cuboids with arbitrary rotation are bit harder. Triangle meshes (the shape most commonly used for real-time 3D models) are very difficult but may be [approximated](approximation.md) e.g. by a [convex hull](convex_hull.md) which is manageable (a convex hull is an intersection of a number of half-spaces) -- if we really want to precisely collide full 3D meshes, we may split each one into several convex hulls (but we need to write the non-trivial splitting algorithm of course). Also note that you need to write a detection algorithm for any possible pair of shape types you want to support, so for *N* supported shapes you'll need *N * (N + 1) / 2* detection algorithms.
+**On shapes**: general rule is that **mathematically simpler shapes are better for collision detection**. **Spheres** (or **circles** in 2D) are the best, they are stupidly simple -- a collision of two spheres is simply decided by their [distance](distance.md) (i.e. whether the distance of their center points is less that the sum of the radii of the spheres), which also determines the collision depth, point and the collision normal is always aligned with the vector pointing from one sphere center to the other. So **if you can, use spheres** -- it is even worth using multiple spheres to approximate more complex shapes if possible. **Axis aligned** shapes (i.e. ones whose orientation will always be aligned with principal axes) are also good -- very often you'll see axis-aligned cubes, boxes, squares or rectangles because checking their collisions is quite easy -- it's enough to check distances of their centers along each principal axis (we can notice that rectangle/box is basically a circle/sphere if we consider consider Chebyshev [distance](distance.md) instead of Euclidean distance, so compared to circles/spheres we may even have a faster distance computation). [Capsules](capsule.md) ("extruded spheres"), infinite planes, half-planes, infinite cylinders (distance from a line) are also among the simpler shapes. Axis-aligned capsules are often used as a shape for game characters (including the player) as they're quite simple and work well e.g. for walking up stairs. Cylinders and cuboids with arbitrary rotation are a bit harder but still used a lot. Note this **nice trick**: when detecting collision between two arbitrarily rotated bodies, you can transform the problem so that you make one of the bodies axis-aligned; then the problem simplifies a lot and once you have the solution, transform it back to the original frame of reference. Triangle meshes (the shape most commonly used for graphical real-time 3D models) are very difficult but may be [approximated](approximation.md) e.g. by a [convex hull](convex_hull.md) which is manageable (a convex hull is an intersection of a number of half-spaces) -- if we really want to precisely collide full 3D meshes, we may split each one into several convex hulls (but we need to write the non-trivial splitting algorithm of course). Also note that more complex shapes max be created as a union of the simpler shapes, so a house shape may in fact be created just from one axis aligned box and another rotated box (for the roof) -- when detecting the collision with this house you'll simply detect the collision with both of the shapes it consists of. Shapes having fewer dimensions than your space may cause you trouble (e.g. line segments in 3D -- these will probably never collide with each other and if they do, what will the normal be? etc.), i.e. if possible in 3D you want to stick with shapes that have volume and in 2D with shapes that have area.
 
-{ In theory we may in some cases also think about using iterative/numerical methods to find collisions, i.e. starting at some point between the bodies and somehow stepping towards their intersection until we're close enough. Another idea I had was to use [signed distance functions](sdf.md) for representing static environments, I kind of implemented it in [tinyphysicsengine](tinyphysicsengine.md). ~drummyfish }
+Up until now we have considered **analytical collision detection**, i.e. the mathematically precise solution that we get by solving an equation (such as in the case of two spheres and comparing their distance with the sum of their radii) -- this is based on [analytic geometry](analytic_geometry.md) and the fact that geometry can be handled by algebraic methods. This method is a cool approach to solving collisions if you can manage it, it is precise and often even fast, however -- as mentioned -- in many cases too hard and tedious. Therefore we may also consider a [good enough](good_enough.md) approximate solutions using **[numerical](numerical.md) methods** instead, i.e. the "less elegant", more [bruteforce](bruteforce.md) kinds of methods that do things such as iterative checking of many points in space to see if there is a collision happening there or not. This will be less precise and may be slower for simpler shapes (though for very complex shapes it may be faster), however the algorithm will be simpler AND, very significantly, it can kind of work for general cases, i.e. you may just have one algorithm that will be able to check all kinds of shapes. Even numerical methods may be written well and optimizing them may result in a very good algorithm.
+
+Numerical algorithms can be made in many ways; consider for example the following: you can divide your whole space into a grid ("Minecraft" style) and then for every shape you have to simply write a function that checks if a single point lies in the shape or not (this is much simpler than checking collisions between complex shapes) -- now to check if a collision is happening you may just check all the grid points in space and if you find a grid square whose center point lies in two shapes at once, you detected a collision (which you may then even check with greater precision by subdividing the cell itself and checking all the subcells etc.). This can be optimized for example with things like [octrees](octree.md) that will allow you to skip big empty areas and not waste time on checking them. Or you don't have to have a global grid but you may just iterate over shapes and for each such shape check some *N* points that lie inside it (which you just somehow generate, e.g. by [interpolating](interpolation.md) between its vertices or something), again checking if any of these points lies in another shape. Or you may be trying something like iteratively stepping towards where an intersection of two shapes should lies (like e.g. [Newton's method](newtons_method.md)). There are many possibilities here.
+
+**[Signed distance functions](sdf.md)** can potentially be used to implement collision detection. { That's how I did it in [tinyphysicsengine](tinyphysicsengine.md). ~drummyfish }
 
 TODO: some actual algorithms

digital_signature.md

@@ -6,4 +6,8 @@ It works on the basis of [asymmetric cryptography](asymmetric_cryptography.md):
 
 Signatures can be computed e.g. with the [RSA](rsa.md) algorithm.
 
-The advantage here is that **[anonymity](anonymity.md) can be kept with digital signatures**; no private information such as the signer's real name is required to be revealed, only his public key. Someone may ask why we then even sign documents if we don't know by whom it is signed lol? But of course the answer is obvious: many times we don't need to know the identity of the signer, we just need to know that different messages have all been written by the same man, and this is what a digital signature can ensure. And of course, if we want, a public key can have a real identity assigned if desirable, it's just that it's not required. 
+The advantage here is that **[anonymity](anonymity.md) can be kept with digital signatures**; no private information such as the signer's real name is required to be revealed, only his public key. Someone may ask why we then even sign documents if we don't know by whom it is signed lol? But of course the answer is obvious: many times we don't need to know the identity of the signer, we just need to know that different messages have all been written by the same man, and this is what a digital signature can ensure. And of course, if we want, a public key can have a real identity assigned if desirable, it's just that it's not required.
+
+## See Also
+
+- [tripcode](tripcode.md)

fourier_transform.md

@@ -1,6 +1,6 @@
 # Fourier Transform
 
-Fourier Transform (FT) is one of the most important transformations/[algorithms](algorithm.md) in [signal](signal.md) processing (and really in [computer science](compsci.md) and [mathematics](math.md) in general), which enables us to express and manipulate a signal (such as a sound or picture) in terms of [frequencies](frequency.md) it is composed of (rather than in terms of individual [samples](samples.md)). It is so important because frequencies (basically [sine](sine.md) waves) are actually THE important thing in signals, they allow us to detect things (voices, visual objects, chemical elements, ...), [compress](compression.md) signals, modify them in useful ways (e.g. filter out [noise](noise.md) of specific frequency band, enhance specific frequency bands, ...). There also exists a related algorithm called **[Fast Fourier Transform](fft.md)** (FFT) which is able to compute one specific version of FT very quickly and so is often used in practice.
+Fourier Transform (FT) is one of the most important transformations/[algorithms](algorithm.md) in [signal](signal.md) processing (and really in [computer science](compsci.md) and [mathematics](math.md) in general), which enables us to express and manipulate a signal (such as a sound or picture) in terms of [frequencies](frequency.md) it is composed of (rather than in terms of individual [samples](samples.md)). It is so important because frequencies (basically [sine](sine.md) waves) are actually THE important thing in signals, they allow us to detect things (voices, visual objects, chemical elements, ...), [compress](compression.md) signals, modify them in useful ways (e.g. filter out [noise](noise.md) in specific frequency band, enhance specific frequency bands, change audio speed without changing its pitch, pitch-shift a song without changing its speed and so on). There also exists a related algorithm called **[Fast Fourier Transform](fft.md)** (FFT) which is able to compute one specific version of FT very quickly and so is often used in practice.
 
 For newcomers FT is typically not easy to understand, it takes time to wrap one's head around it. There is also a very confusing terminology; there exist slightly different kinds of the Fourier Transform that are called by similar names, or sometimes all simply just "Fourier Transform" -- what programmers usually mean by FT is DFT or FFT. There also exist Fourier Transforms in higher dimensions (2D, 3D, ...) -- the base case is called one dimensional (because our input signal has one coordinate). All this will be explained below.
 

kek.md

@@ -1,6 +1,6 @@
 # Kek
 
-Kek means [lol](lol.md). It comes from [World of Warcraft](wow.md) where the two opposing factions (Horde and Alliance) were made to speak mutually unintelligibile languages so as to prevent enemy players from communicating; when someone from Horde typed "lol", an Alliance player would see him say "kek". The other way around (i.e. Alliance speaking to Horde) would render "lol" as "bur", however kek became the popular one. On the Internet this further mutated to forms like *kik*, *kekw*, *topkek* etc. Nowadays in some places such as [4chan](4chan.md) kek seems to be used even more than lol, it's the newer, "cooler" way of saying lol.
+Kek means [lol](lol.md). It comes from [World of Warcraft](wow.md) where the two opposing factions (Horde and Alliance) were made to speak mutually unintelligibile languages so as to prevent enemy players from communicating; when someone from Horde typed "lol", an Alliance player would see him say "kek". The other way around (i.e. Alliance speaking to Horde) would render "lol" as "bur", however kek became the popular one. On the Internet this has further mutated into advanced forms like *kik*, *kekw*, *topkek*, *giga kek* etc. Nowadays in some places such as [4chan](4chan.md) kek seems to be used even more than lol, it's the newer, "cooler" way of saying lol.
 
 ## See Also
 

oop.md

@@ -2,7 +2,7 @@
 
 *"I invented the term 'object oriented' and [C++](cpp.md) was not what I had in mind"* --[Alan Kay](alan_kay.md), inventor of OOP
 
-Object-oriented programming (OOP, also object-obsessed programming, objectfuscated programming, capital-oriented programming or artificial inelegance) is a [programming paradigm](paradigm.md) that tries to model reality as a collection of abstract objects that communicate with each other and obey some specific rules. While the idea itself isn't bad and can be useful in certain cases and while pure OOP in very old languages like [Smalltalk](smalltalk.md) may have even been quite elegant, by later adoption by [capitalist businesses](capitalist_software.md) the concept has been extremely twisted and degenerated to unbelievable levels -- **OOP has become extremely overused, extremely badly implemented and downright forced in programming languages** that nowadays try to apply this [abstraction](abstraction.md) to every single program and concept, creating [anti-patterns](anti_pattern.md), unnecessary issues and of course greatly significant amounts of [bloat](bloat.md). [We](lrs.md) therefore see the OOP of today as a **[cancer](cancer.md) of programming**. OOP was basically a software development fashion wave that scarred the industry for decades, it has poisoned minds of several generations. Nowadays despite OOP still keeping many fans the critical stance towards it isn't even controversial anymore, many others have voiced the criticism over and over, usually the most competent programmers like [Richard Stallman](rms.md) and [Linus Torvalds](torvalds.md) and groups like [suckless](suckless.md) and [bitreich](bitreich.md). Ugly examples of OOP gone bad include [Java](java.md) and [C++](cpp.md) (which at least doesn't force it). Other languages such as [Python](python.md) and [Javascript](javascript.md) include OOP but have lightened it up a bit and at least allow you to avoid using it. You should probably learn OOP but only to see why it's bad (and to actually understand 99% of code written nowadays). Stop objectifying programs!
+Object-oriented programming (OOP, also object-obsessed programming, objectfuscated programming, capital-oriented programming or artificial inelegance) is a [programming paradigm](paradigm.md) that tries to model reality as a collection of abstract objects that communicate with each other and obey some specific rules. While the idea itself isn't bad and can be useful in certain cases and while pure OOP in very old languages like [Smalltalk](smalltalk.md) may have even been quite elegant, by later adoption by [capitalist businesses](capitalist_software.md) the concept has been extremely twisted and degenerated to unreal levels -- **OOP has become extremely overused, extremely badly implemented and downright forced in programming languages** that nowadays try to apply this [abstraction](abstraction.md) to every single program and concept, creating [anti-patterns](anti_pattern.md), unnecessary issues and of course greatly significant amounts of [bloat](bloat.md). [We](lrs.md) therefore see the OOP of today as a **[cancer](cancer.md) of programming**. OOP was basically a software development fashion wave that scarred the industry for decades, it has poisoned minds of several generations. Nowadays despite OOP still keeping many fans the critical stance towards it isn't even controversial anymore, many others have voiced the criticism over and over, usually the most competent programmers like [Richard Stallman](rms.md) and [Linus Torvalds](torvalds.md) and groups like [suckless](suckless.md) and [bitreich](bitreich.md). Ugly examples of OOP gone bad include [Java](java.md) and [C++](cpp.md) (which at least doesn't force it). Other languages such as [Python](python.md) and [Javascript](javascript.md) include OOP but have lightened it up a bit and at least allow you to avoid using it. You should probably learn OOP but only to see why it's bad (and to actually understand 99% of code written nowadays). Stop objectifying programs!
 
 **A [real life](irl.md) analogy** to give a bit of high level overview: the original [Smalltalk](smalltalk.md) style OOP was kind of like when society invented [democracy](democracy.md) -- a simple idea which everyone understands (we are 10 cavemen, let's just vote on stuff mkay?) that's many times useful and works well, e.g. on a scale of a village or a small city. Then cities grew bigger (just as software did), into states and empires and the idea kept getting more and more complicated -- people just wanted to keep the democracy, apply it to everything and scale it indefinitely, but for that they had to add more complexity, they implemented representatives, parliaments, senates, presidents, vicepresidents, ministers, judges, more and more bureaucracy, hybrid ideas (free market, controlled economy, ...), corruption and inefficiencies crept in, the system degenerated into what we have today -- a hugely expensive paperworking machine that's exploited and hacked, with laws so complicated no one really understands them, with [magic](magic.md), randomness and unpredictability, producing just waste and bullshit, crumbling under own weight. This is also the way OOP went -- they started inventing static classes/methods, abstract classes/methods, multiple inheritances, interfaces, design patterns, overriding, hybrid paradigms and so on until we ended up with ugly abominations on which today's technology stands. Now a few things have to be noted. Firstly these abominations are a disaster, they came from our mistake of taking the original simple idea (simple small scale voting democracy) and saying "let's make this the only thing in the world and let's scale it a million times!" Such idea is stupid from the start and there is no doubt about that. However another evil is that people are taught to do everything this way -- today's programmers will use the mainstream OOP everywhere, even in simple programs, they don't even think about if they should, they are simply taught "always use this". This is like in real life wanting to govern a family by having elections each year to vote for the head of the family, then having members of family vote for other members of the family to be their representatives that will talk for them (the same kind of craziness as wanting to strictly respect encapsulation even in trivial programs), then if someone wants to buy anything he has to ask for a budget several months in advance and have others vote on it while an elected anti corruption committee is watching etcetc. This kind of insanity is what's normal in software nowadays. Now the only sane discussion can be had only about the usefulness and scope of the original, simple idea (simple voting in small groups, simple pure OOP) and here we say that it may be good, but only applied to just some specific situations, i.e. we say simple OOP is good for some problems but not all, just like voting is a good solution to some problems (e.g. a group of friends deciding where to go party), but not all (e.g. passengers in a car voting on which way to steer and which pedals to press).
 

programming.md

@@ -27,7 +27,7 @@ OK, now the key thing to becoming a programmer is learning a [programming langua
 
 { I really started programming in [Pascal](pascal.md) at school, it was actually a good language as it worked very similarly to C and the transition later wasn't that hard, but nowadays learning Pascal doesn't make much sense anymore. ~drummyfish }
 
-**[Games](game.md) are an ideal start project** because they're [fun](fun.md) (having fun makes learning much faster and enjoyable), there are many noob tutorials all over the Internet etc. However keep in mind to **start EXTREMELY simple.** -- this can't be stressed enough, most people are very impatient and eager and start making an RPG game or networking library without really knowing a programming language -- this is a GUARANTEED spectacular failure. At the beginning think in terms of "snake" and "minesweeper". Your very first project shouldn't even use any [GUI](gui.md), it should be purely [command-line](cli.md) text program, so a text-only tiny interactive story in [Python](python.md) is possibly the absolutely best choice as a first project. Once you're more comfortable you may consider to start using graphics, e.g. Python + [Pygame](pygame.md), but still [KEEP IT SIMPLE](kiss.md), make a flappy bird clone or something. As you progress, consider perhaps buying a simple toy computer such as an [open console](open_console.md) -- these toys are closer to old computers that had no operating systems etc., they e.g. let you interact directly with hardware and teach you a LOT about good programming by teaching you how computers actually work under the hood. One day you will have to make the big step and **learn [C](c.md)**, the best and most important language as of yet, but be sure to only start learning it when you're at least intermediate in your start language (see our [C tutorial](c_tutorial.md)). To learn C we recommend our [SAF](saf.md) library which will save you all headaches of complex APIs and your games will be nice and compatible with you small toy computers.
+**[Games](game.md) are an ideal start [project](project.md)** because they're [fun](fun.md) (having fun makes learning much faster and enjoyable), there are many noob tutorials all over the Internet etc. However keep in mind to **start EXTREMELY simple.** -- this can't be stressed enough, most people are very impatient and eager and start making an RPG game or networking library without really knowing a programming language -- this is a GUARANTEED spectacular failure. At the beginning think in terms of "snake" and "minesweeper". Your very first project shouldn't even use any [GUI](gui.md), it should be purely [command-line](cli.md) text program, so a text-only tiny interactive story in [Python](python.md) is possibly the absolutely best choice as a first project. Once you're more comfortable you may consider to start using graphics, e.g. Python + [Pygame](pygame.md), but still [KEEP IT SIMPLE](kiss.md), make a flappy bird clone or something. As you progress, consider perhaps buying a simple toy computer such as an [open console](open_console.md) -- these toys are closer to old computers that had no operating systems etc., they e.g. let you interact directly with hardware and teach you a LOT about good programming by teaching you how computers actually work under the hood. One day you will have to make the big step and **learn [C](c.md)**, the best and most important language as of yet, but be sure to only start learning it when you're at least intermediate in your start language (see our [C tutorial](c_tutorial.md)). To learn C we recommend our [SAF](saf.md) library which will save you all headaches of complex APIs and your games will be nice and compatible with you small toy computers.
 
 As with everything, you learn by doing -- reading is extremely important and necessary, but to actually learn anything you have to spend thousands of hours practicing the art yourself. So **program, program and program**, live by programming, look for ways of using programming in what you're already doing, try to automatize anything you do, think about programming before sleep etc. If you can, **contribute to some project**, best if you can help your favorite [FOSS](foss.md) program -- try this at least once as being in the company of the experienced just teaches you like nothing else, a month spent contributing to a project may be worth a year of just reading books.
 

rationalwiki.md

@@ -1,10 +1,10 @@
 # "Rational"Wiki
 
-"Rational"Wiki (https://rationalwiki.org/) is a barely notable, [toxic](toxic.md) child [atheist](atheism.md) pseudorationalist/[pseudoskeptic](pseudoskepticism.md) [ultrafeminist](feminism.md) [ultragay](lgbt.md) [SJW](sjw.md) far [pseudoleft](pseudoleft.md) [wiki](wiki.md) website that specializes in mental gymnastics and creating hysteria over rational views on controversial topics on the [Internet](internet.md). The name of the wiki is intentionally misleading, one would think the word "rational" means that the wiki is somehow rational, but in fact it means the wiki specialized in discrediting rationality. It is recommended you delete this website from your bookmarks or it will give you brain [cancer](cancer.md). The author of the wiki was inbred with a pig (this is not ad hominem because ad hominem can only be used on humans, but he is still probably a [homo](gay.md) sexual). { My apoligies to pigs. ~drummyfish } Vandalizing this "wiki" is a great service to humanity and great [fun](fun.md).
+"Rational"Wiki (https://rationalwiki.org/) is a barely notable, [toxic](toxic.md) child [atheist](atheism.md) pseudorationalist/[pseudoskeptic](pseudoskepticism.md) [ultrafeminist](feminism.md) [ultragay](lgbt.md) [SJW](sjw.md) far [pseudoleft](pseudoleft.md) [wiki](wiki.md) website that specializes in mental gymnastics and creating hysteria over rational views on controversial topics on the [Internet](internet.md). The name of the wiki is intentionally misleading, one would think the word "rational" means that the wiki is somehow rational, but in fact it means the wiki specialized in discrediting rationality. It is recommended you delete this website from your bookmarks or it will give you brain [cancer](cancer.md) and your mother will die in her sleep. The author of the wiki was inbred with a pig (this is not ad hominem because ad hominem can only be used on humans, but he is still probably a [homo](gay.md) sexual). { My apoligies to pigs. ~drummyfish } Vandalizing this "wiki" is a great service to humanity and great [fun](fun.md).
 
 Typically for a [pseudoleftist](pseudoleft.md) fedora site, a tactic of using misleading names is widely used as one of the main means of operation, e.g. [racial realism](racial_realism.md) is called [racism](racism.md), politically inconvenient [science](science.md) is called [pseudoscience](pseudoscience.md) and, of course, [soyence](soyence.md) is promoted as the "only true unquestionable [science](science.md)". The name of the wiki itself seems to suggest it has something to do with [rationality](rationality.md), which is of course very misleading -- the purpose of the wiki seems to be solely promotion of [modern](modern.md) harmful religion and cults such as [capitalism](capitalism.md), [liberalism](liberalism.md) and [political correctness](political_correctness.md), while bashing anything slightly off the [mainstream](mainstream.md).
 
-STAHP! it's not even worth talking about this cancer anymore because it's too radioactive, better go read some other article. Be safe and shield yourself from this toxic waste. Vandalize it and move on.
+STAHP! it's not even worth talking about this cancer anymore because it's too radioactive and this has already been almost a lethal amount, better go read some other article. Be safe and shield yourself from this toxic waste. Vandalize it and move on.
 
 ## See Also
 

soydev.md

@@ -36,4 +36,5 @@ Here is a quick rough comparison of seydevs and actual good programmers (nowaday
 
 - [SJW](sjw.md)
 - [soyboy](soyboy.md)
-- [snowflake](snowflake.md)
+- [snowflake](snowflake.md)
+- [zoomer](zoomer.md)

wiki_stats.md

@@ -3,9 +3,9 @@
 This is an autogenerated article holding stats about this wiki.
 
 - number of articles: 587
-- number of commits: 852
+- number of commits: 853
-- total size of all texts in bytes: 4114582
+- total size of all texts in bytes: 4120218
-- total number of lines of article texts: 30945
+- total number of lines of article texts: 30968
 - number of script lines: 262
 - occurences of the word "person": 7
 - occurences of the word "nigger": 90
@@ -35,52 +35,52 @@ longest articles:
 
 top 50 5+ letter words:
 
-- which (2334)
+- which (2337)
-- there (1786)
+- there (1787)
-- people (1583)
+- people (1599)
-- example (1360)
+- example (1362)
-- other (1286)
+- other (1291)
 - number (1143)
 - software (1141)
-- about (1106)
+- about (1107)
 - program (922)
 - their (869)
 - because (863)
-- would (848)
+- would (849)
-- being (797)
+- being (799)
-- called (796)
+- called (797)
-- things (777)
+- things (778)
 - something (772)
 - language (768)
 - numbers (749)
 - computer (748)
 - simple (737)
-- without (698)
+- without (702)
 - programming (683)
 - function (674)
 - these (660)
 - different (651)
 - however (644)
-- system (611)
+- system (613)
 - world (600)
-- should (594)
+- should (595)
-- doesn (586)
+- doesn (589)
 - games (576)
+- society (571)
 - point (569)
-- society (568)
+- while (557)
-- while (555)
+- drummyfish (543)
-- drummyfish (542)
+- though (537)
-- though (536)
 - still (528)
 - using (525)
+- simply (524)
 - possible (522)
-- simply (520)
 - memory (508)
 - similar (507)
 - course (502)
-- https (498)
+- https (501)
 - technology (497)
-- always (474)
+- always (475)
 - really (468)
 - basically (458)
 - extremely (452)
@@ -89,6 +89,23 @@ top 50 5+ letter words:
 latest changes:
 
 ```
+Date:   Thu Jul 25 15:20:50 2024 +0200
+  censorship.md
+  dog.md
+  duke3d.md
+  faggot.md
+  hacking.md
+  main.md
+  pedophilia.md
+  political_correctness.md
+  race.md
+  random_page.md
+  recursion.md
+  trolling.md
+  whale.md
+  wiki_pages.md
+  wiki_stats.md
+  woman.md
 Date:   Wed Jul 24 15:49:35 2024 +0200
   charity_sex.md
   dramatica.md
@@ -105,17 +122,6 @@ Date:   Wed Jul 24 15:49:35 2024 +0200
   wiki_stats.md
   woman.md
 Date:   Mon Jul 22 21:26:59 2024 +0200
-  anal_bead.md
-  drummyfish.md
-  main.md
-  people.md
-  random_page.md
-  wiki_pages.md
-  wiki_stats.md
-  woman.md
-Date:   Mon Jul 22 14:02:59 2024 +0200
-  wiki_stats.md
-Date:   Mon Jul 22 14:02:40 2024 +0200
 ```
 
 most wanted pages:
@@ -143,8 +149,8 @@ most wanted pages:
 
 most popular and lonely pages:
 
-- [lrs](lrs.md) (291) 
+- [lrs](lrs.md) (293) 
-- [capitalism](capitalism.md) (233) 
+- [capitalism](capitalism.md) (234) 
 - [c](c.md) (216) 
 - [bloat](bloat.md) (208) 
 - [free_software](free_software.md) (176) 
@@ -161,8 +167,8 @@ most popular and lonely pages:
 - [fun](fun.md) (84) 
 - [censorship](censorship.md) (83) 
 - [free_culture](free_culture.md) (81) 
+- [less_retarded_society](less_retarded_society.md) (79) 
 - [fight_culture](fight_culture.md) (79) 
-- [less_retarded_society](less_retarded_society.md) (78) 
 - [math](math.md) (77) 
 - [hacking](hacking.md) (77) 
 - [public_domain](public_domain.md) (76) 
@@ -174,16 +180,16 @@ most popular and lonely pages:
 - [woman](woman.md) (69) 
 - [internet](internet.md) (69) 
 - ...
+- [adam_smith](adam_smith.md) (5) 
+- [aaron_swartz](aaron_swartz.md) (5) 
 - [zuckerberg](zuckerberg.md) (4) 
 - [wiki_pages](wiki_pages.md) (4) 
-- [whale](whale.md) (4) 
 - [trump](trump.md) (4) 
 - [tom_scott](tom_scott.md) (4) 
 - [speech_synthesis](speech_synthesis.md) (4) 
 - [see_through_clothes](see_through_clothes.md) (4) 
 - [README](README.md) (4) 
 - [primitive_3d](primitive_3d.md) (4) 
-- [paywall](paywall.md) (4) 
 - [openai](openai.md) (4) 
 - [nord_vpn](nord_vpn.md) (4) 
 - [myths](myths.md) (4) 

windows.md

@@ -39,6 +39,8 @@ Windows has these disadvantages (this is just a few things, we can't possibly as
 - It's inefficient, eats too much electricity, increases CO2, heat pollution, forces you to buy big harddrives, more expensive Internet connection etc.
 - ...
 
+Not that you should use bloated Windows programs but even if you WANT that you can do it with [Wine](wine.md) under GNU/Linux, sometimes the programs even run better under Wine than on winshit itself lol. By this there is zero (or maybe even fewer) reasons to ever use windows, it's literally just for [faggots](faggot.md).
+
 Some people still decide to use it.
 
 **Should we compile our programs for Window$?** [Free software](free_software.md) supporters regularly debate this question, some say we shouldn't make Window$ versions of free programs so as to not support the platform. Nevertheless even such purists as [GNU](gnu.md) make Window$ versions of their programs with the justification that providing Window$ useds with the taste of freedom may convince them to leave the system (though their critics may equally see it as mere populism, i.e. just making their program more popular). It is probably true that making some free tools available on Window$ makes a transition to a free system easier just by making the transition more gradual: the used first learns to use free tools, then switches the underlying system, as opposed to making one giant leap into a completely foreign environment. { This is how it worked for myself anyway. ~drummyfish } **Nevertheless** our [LRS](lrs.md) point of view is yet a bit different -- we oppose any kind of [censorship](censorship.md), artificial scarcity and so on, including actively breaking compatibility (which includes not making something compatible if it is trivial to do), we simply refuse to be overlords strategically dictating whether something should work or not, that would be the [evil](evil.md) way. For this our advice is: if it's easy to make your program work somewhere, make it work there. Never put extra effort into lowering compatibility or accessibility. If you just don't care about some platform or it would present too much trouble for you to make it compatible, it's fine to not do it, but at least make it easy for others to do for you. So yes, you can (and probably should) make a Window$ version of your program, but it is also OK to have a bit of [fun](fun.md) while doing so -- for example [Anarch](anarch.md) on Window$ warns the player that his operating system is [malware](malware.md) :) **How to compile shit for Window$ when you don't have Window$?** There are several ways: for [C](c.md) (or C++ etc.) programs you may comfortably use e.g. MinGW ([mingw](mingw.md)) (basically the GNU compilers + binary tools compiled and packaged for Window$) -- this you can either run natively under GNU/Linux (look for mingw packages) or you may run the Window$ versions of it under [wine](wine.md) or in some [VM](vm.md) such as [qemu](qemu.md) or virtualbox (where you may additionally also test the compiled program); you may also theoretically e.g. make a web browser version of your program (with stuff like emscripten) which will run on all OSes.

woman.md

@@ -8,7 +8,7 @@ The symbol for woman is a circle with cross at its bottom ([Unicode](unicode.md)
 
 **Even mainstream science acknowledges women are dumber than men**: even the extremely politically correct [Wikipedia](wikipedia.md) states TODAY in the article on human brain that male brain is on average larger in volume (even when corrected for the overall body size) AND that there is correlation between volume and intelligence: this undeniably implies women are dumber. Men also have faster reaction times. On average male brain weights 10% more than woman's and has 16% more brain cells. The Guinness book of 1987 states the average male brain weight being 1424 grams and that of a female being 1242 grams; the averages both grow with time quite quickly so nowadays the numbers will be higher in both sexes, though the average of men grows faster. The heaviest recorded brain belonged to a man (2049 grams), while the lightest belonged to a woman (1096 grams). Heaviest woman brain weighted 1565 grams, only a little more than men's average. [IQ](iq.md)/intelligence measured by various tests has been consistently significantly lower for women than for men, e.g. the paper named *Sex differences in intelligence and brain size: A paradox resolved* found a 4 point difference, noting that in some problems such as 3D spatial rotations males score even 11 points higher average.
 
-Historically women have been privileged over men, and they still are very much (for example they commit suicides much less often) -- while men had to [work](work.md) their asses off, go to [wars](war.md), explore and hunt for food, women often weren't even supposed to work, they could stay at home, chill while guarding the fire and playing with children -- this is becoming less and less so with [capitalism](capitalism.md) which aims to simply enslave everyone, nowadays mostly through the [feminist](feminism.md) cult that brainwashed women to desire the same slavery as men. Statistically **women live about 6 years longer lives than men** because they have easier and less stressful life, they don't have to work as hard and they can obtain privileges (such as free food and better healthcare) just with a flirty smile. While feminists are furious about wage gaps, none gives a single damn about this opposite kind of inequality gap which just confirms what everyone already knows: feminists don't care about equality, they care about women. Women also have the huge social privilege of being able to to have sex and/or get a partner at any time with no effort and/or **trade sex (or even just mere company) for things and services**. Being a woman means playing life on very low difficulty, you can have anything you want at any time. Man on the other hand won't get sex unless he's a billionaire or at least 2 meters tall, no matter how smart, nice of physically fit he is. For a woman to get sex it's enough to just ask while not weighting two tons, that's literally how easy it is.
+Historically women have been privileged over men, and they still are very much (for example they commit [suicides](suicide.md) much less often) -- while men had to [work](work.md) their asses off, go to [wars](war.md), explore and hunt for food, women often weren't even supposed to work, they could stay at home, chill while guarding the fire and playing with children -- this is becoming less and less so with [capitalism](capitalism.md) which aims to simply enslave everyone, nowadays mostly through the [feminist](feminism.md) cult that brainwashed women to desire the same slavery as men. In case of emergencies it's always been the rule to save women and children first, in wars women and children were oftentimes spared in mass executions. Statistically **women live about 6 years longer lives than men** because they have easier and less stressful life, they don't have to work as hard and they can obtain privileges (such as free food and better healthcare) just with a flirty smile. While feminists are furious about wage gaps, none gives a single damn about this opposite kind of inequality gap which just confirms what everyone already knows: feminists don't care about equality, they care about women. Women also have the huge social privilege of being able to to have sex and/or get a partner at any time with no effort and/or **trade sex (or even just mere company) for things and services**. Being a woman means playing life on very low difficulty, you can have anything you want at any time. Man on the other hand won't get sex unless he's a billionaire or at least 2 meters tall, no matter how smart, nice of physically fit he is. For a woman to get sex it's enough to just ask while not weighting two tons, that's literally how easy it is.
 
 Women also can't drive, operate machines, they can't compare even to the worst men in sports, both physical and mental such as [chess](chess.md). Women have to have separate leagues and more relaxed rules, e.g. the title Woman Grand Master (WGM) in chess has far lower requirements to obtain than regular Grand Master (GM). (According to [Elo](elo.md) rating the best woman chess player in history would have only 8% chance of winning against current best male who would have 48% chance of winning). On the International Mathematical Olympiad only 43 out of 1338 medals were obtained by females. There are too many funny cases and video compilations of women facing men in sports (watch them before they're censored lol), e.g. the infamous Vaevictis female "progaming" team or the [football](football.md) match between the US national women team (probably the best women team in the world) vs some random under 15 years old boy's team which of course the women team lost. LMAO there is even a video of 1 skinny boy beating 9 women in boxing. Of course there are arguments that worse performance of women in mental sports is caused culturally; women aren't led so much to playing chess, therefore there are fewer women in chess and so the probability of a good woman player appearing is lower. This may be partially true even though genetic factors seem at least equally important and it may equally be true that not so many women play chess simply because they're not naturally good at it; nevertheless the fact that women are generally worse at chess than men stands, regardless of its cause -- a randomly picked men will most likely be better at chess than a randomly picked woman, and that's what matters in the end. Also if women are displaced from chess by culture, then what is the area they are displaced to? If women are as capable as men, then for any area dominated by men there should be an area equally dominated by women, however we see that anywhere men face women men win big time, even in the woman activities such as cooking and fashion design. Feminists will say that men simply oppress women everywhere, but this just means that women are dominated by men everywhere, which means they are more skilled and capable at everything, there is no way out -- yes, antelope are oppressed by lions, but it's because lions are stronger than antelopes. Here we simply argue that women are weaker than men, not that oppressing women is okay -- it isn't. Furthermore if women were weaker but not by that much, we should statistically see at least occasional dominance by a woman, but we practically don't, it's really almost impossible to find a single such case in history, which indicates women are VERY SIGNIFICANTLY weaker, i.e. not something we negligible we could just ignore. Being a woman correlates to losing to a man almost perfectly, it is a great predictor, basically as strong as can appear in science. It makes sense from the evolutionary standpoint as well, women simply evolved to take care of children, guard fire and save resource consumption by being only as strong as necessarily required for this task, while men had to be stronger and smarter to do the hard job of providing food and protection.
 
@@ -132,6 +132,8 @@ This section will be dedicated to me fulfilling my promise. Please note that me
 
 I have found the website of **[Ashley Jones](ashley_jones.md)**: [https://icum.to](https://icum.to). She immediately caught my attention, I reckon she is truly based, for example for the following reasons (note that this is purely my interpretation of what I've seen/read on her website): She is a pretty, biological woman (i.e. NOT some kind of angry trans landwhale) BUT she shits on feminism and acknowledges plain facts about women such as that they usually need to be "put in line" (with love) by a man and that they are simply different. She makes a nice, ACTUALLY ENTERTAINING, well made politically incorrect stuff, her art is sincere, not trying to pretend anything or ride on some kind of fashion wave. She is VERY talented at comedy, hosts her OWN video website with a modest fan following and even though on [Jewtube](youtube.md) she could get hundred thousand times more followers and make a fortune, she doesn't do it -- she does ask for donations but refuses to monetize her content with ads, creating a nice, pure, oldschool free speech Internet place looks to truly be the one thing she's aiming for. She makes fun of herself (like that she has a crush on [Duke Nukem](duke3d.md) lol), masterfully plays along with jokes blatantly sexualizing her and does some cool stuff like post measurements of her asshole and finding her porn lookalikes for the fanbase. It looks like she possesses some skills with technology (at least [Luke Smith](luke_smith.md) level), she supports [free software](free_software.md). She acknowledges the insanity of [pedophile](pedophilia.md) hysteria and proposes lowering age of consent (despite saying she was NOT a pedophile herself). She wants to normalize nudity, and doesn't shave her legs. Her website is quite nice, 1.0 style, with high [LRS](lrs_wiki.md)/[4chan](4chan.md)/[Dramatica](dramatica.md) vibes, there are "offensive" jokes but she stresses she in fact doesn't encourage violence and that she's not an extremist -- in one video she says she dislikes transsexuals and wants to make fun of gays but that in fact she doesn't mind any individual being gay or whatever, basically just opposing the political movements, propaganda, brainwashing etcetc., i.e. showing the exact same kind of attitude as us. She also understands internet culture and things like [trolling](trolling.md) being part of it -- in one video she clearly separates Internet and [real life](irl.md) and says you "can't apply real life logic on the Internet", that's very mature. By this she for example supports consensual incest. She even freaking has her own imageboard that's by the way very good. She seems to see through propaganda and brainwashing, she says she does "not accept the reality" forced on her by this society, something we say and do as well, she shits on vaccines and likes cool "conspiracy theories". Yes, she seems SMART, she sees the power game of the elites, the propaganda, warns about it, shits on it. She seems to know how to write [English](english.md) without making 10 errors in every word. She advocates ETHICAL veganism, to spare animals of suffering. She hates [Elon Musk](elon_musk.md). She advocates not using cellphones and mainstream social networks. (I haven't noticed any tattoos on her either, but she'll stay even if it turned out she has one, she's still cool.) **Ashley Jones, I apologize to you, please stay awesome and inspire more women to be as based as you are <3 --drummyfish**. No, the words don't come out of my penis, they come out of my heart. Please stay cool.
 
+PLEASE PLEASE PLEASE Ashley don't fuck it up please, stay our Internet queen don't go to shit pretty please! (LRS note for those who are retarded: yes, this is a bit of a hyperbole, don't unironically make [cults of people](hero_culture.md). But Ashley is officially a mini queen of the Internetz now.)
+
 I also realized babushkas and old grandmas in general are often based, they just come from the better times.
 
 *Your name here? Let me if you come by another candidate for a based woman :)*