This commit is contained in:
Miloslav Ciz 2023-02-26 13:08:10 +01:00
parent 1ccdf27364
commit b4302b5734
6 changed files with 37 additions and 3 deletions

View file

@ -6,4 +6,6 @@ Feminism is a [fascist](fascism.md) [terrorist](terrorism.md) [pseudoleftist](ps
If anything's clear, then that feminism doesn't care about gender equality. Firstly it is not called *gender equality movement* but *feminism*, i.e. for-female, and as we know, [name plays a huge role](name_is_important.md). Indeed, women have historically been oppressed and needed support, but once that support reaches equality -- which has basically already happened a long time ago now -- feminist movement will, if only by [social inertia](social_inertia.md), keep pursuing more advantages for women (what else should a movement called *feminism* do?), i.e. at this point the new goal has already become female superiority. Another proof is that feminists care about things such as wage gap but of course absolutely don't give a damn about opposite direction inequality, such as men dying on average much younger than women etc. And of course, when men establish "men rights" movements to address this, suddenly feminists see those as "fascist", "toxic" and "violent" and try to destroy such movements.
Part of the success of feminism is also [capitalism](capitalism.md) -- women with priviledges, e.g. those of not having to work as much as men, are not accepted under capitalism; everyone has to be exploited as much as possible, everyone has to be a work slave. Therefore capitalist propaganda promotes ideas such as "women not having to work is oppression by men and something a woman should be ashamed of", which is of course laughable, but with enough brainwashing anything can be established, even the most ridiculous and obvious bullshit.
Apparently in Korea feminists already practice segregation, they separate parking spots for men and women so as to prevent women bumping into men or meeting a man late at night because allegedly men are more aggressive and dangerous. Now this is pretty ridiculous, this is exactly the same as if they separated e.g. parking lots for black and white people because black people are statistically more aggressive and involved in crime, you wouldn't want to meet them at night. So, do we still want to pretend feminists are not fascist?

View file

@ -52,7 +52,8 @@ A great many commonly used tricks in programming could be regarded as hacks even
- **[bit hacks](bit_hack.md)**: Clever manipulations of [bits](bit.md) -- for example it is possible to swap two variable without a temporary variables by using the [xor](xor.md) function. Another simplest example is implementing division by 2 as binary shift by 1 (this hack is used in real life by people for quickly dividing by 10, we just remove the last digit).
- **[copyleft](copyleft.md)**: A legal hack by [Richard Stallman](rms.md), connected to [free software](free_software.md), working on the basis of the following idea: "If [copyright](copyright.md) lets me put any conditions on my work, I may impose a condition on my work that says that any modified version must not impose any restrictive conditions".
- **[fast inverse square root](fast_inverse_sqrt.md)**: Famous hack that was used in the [game](game.md) Quake, it [approxmates](approximation.md) a [square root](sqrt.md) of a [floating point](float.md) number by treating it as an integer and bashing it with a [magic constant](magic_constant.md), which is about four times faster than computing the value with the obvious floating point division.
- **Memory [rape](rape.md) in [C](c.md)**: E.g. instead of doing proper memory allocation with potentially inefficient and bloated `malloc` one may try to do a custom memory allocation without any libraries by abusing allocation on stack -- allocate a variable size array in main, set some global pointer to it and then manage this chunk of memory with your own allocation functions.
- **memory [rape](rape.md) in [C](c.md)**: E.g. instead of doing proper memory allocation with potentially inefficient and bloated `malloc` one may try to do a custom memory allocation without any libraries by abusing allocation on stack -- allocate a variable size array in main, set some global pointer to it and then manage this chunk of memory with your own allocation functions.
- **actually portable executable** (https://justine.lol/ape.html): Justine Tunney found a way to create an executable format that passes as a valid NATIVE executable on all major systems including [Linux](linux.md), [Windows](windows.md) and [Mac](mac.md), i.e. it is possible to compile a native program (e.g. with [C](c.md)) and then have it natively run on any major OS.
- **[game of life](game_of_life.md) patterns**: Stable patterns such as glider or even programming game of life in game of life is a nice example of game hacking -- in fact exactly game of life hacking stood at the beginning of hacker culture.
- **[bytebeat](bytebeat.md)**: A [demoscene](demoscene.md) hack that utilizes integer [overflows](overflow.md) to create rhythm and produce music.
- Computer [graphics](graphics.md) uses many clever tricks that could possibly be called hacks, e.g. in times when 3D graphics was primitive and didn't allow achieving such effects as mirror reflections easily, some [games](game.md) faked mirrors simply with a hole in the wall behind which the whole mirrored room was placed -- this achieved the same effect as a mirror and didn't require any extra rendering passes or shaders.

View file

@ -16,14 +16,14 @@ For start let's see which kinds of allocation (and their associated parts of mem
- **global variables** (variables declared outside any function, i.e. even outside `main`)
- **static variables** (variables inside functions declared with `static` keyword)
- **constants/literals** (i.e. concrete numbers/strings in the source code such as `123` or `"abc"`)
- **automatic allocation (stack memory)**: For local variables (variables inside functions) the memory is allocated in a special part of memory known as **call [stack](stack.md)** only at the time when the function is actually called and executed; i.e. this is similar to dynamic allocation (it happens at run time) but happens automatically, without needing any libraries or other explicit actions from the programmer. I.e. when a function is called at run time, a new *call frame* is created on stack which includes space for local variables of that function (along with e.g. return address from the function etc.). This is necessary e.g. to allow [recursion](recursion.md) (during which several instances of the same functions may be active, each of which may have different values of its variables), and it also helps consume less RAM. This allows for creating variable sized arrays inside functions (e.g. `int array[x];` where `x` is variable) which is not possible to do with a global array (however variable size arrays aren't supported in old ANSI C!). The disadvantage over dynamic allocation is that stack memory is relatively small and overusing it may easily cause stack [overflow](overflow.md) (running out of memory). Still this kind of allocation is better than dynamic allocation as it doesn't need any libraries, it doesn't generate complex code and the only danger is that of stack overflow -- memory leaks can't happen (deallocation happens automatically when function is exited). Automatic allocation applies to:
- **automatic allocation (stack memory)**: For local variables (variables inside functions) the memory is allocated in a special part of memory known as **call [stack](stack.md)** only at the time when the function is actually called and executed; i.e. this is similar to dynamic allocation (it happens at run time) but happens automatically, without needing any libraries or other explicit actions from the programmer. I.e. when a function is called at run time, a new *call frame* is created on stack which includes space for local variables of that function (along with e.g. return address from the function etc.). This is necessary e.g. to allow [recursion](recursion.md) (during which several instances of the same function may be active, each of which may have different values of its variables), and it also helps consume less RAM. This allows for creating variable sized arrays inside functions (e.g. `int array[x];` where `x` is variable) which is not possible to do with a global array (however variable size arrays aren't supported in old ANSI C!). The disadvantage over dynamic allocation is that stack memory is relatively small and overusing it may easily cause stack [overflow](overflow.md) (running out of memory). Still this kind of allocation is better than dynamic allocation as it doesn't need any libraries, it doesn't generate complex code and the only danger is that of stack overflow -- memory leaks can't happen (deallocation happens automatically when function is exited). Automatic allocation applies to:
- **local variables** (including function arguments and local **variable size arrays**)
- **dynamic allocation (heap memory)**: A kind of more complex manual allocation that happens at run time and is initiated by the programmer calling special functions such as `malloc` from the `stdlib` standard library, which return [pointers](pointer.md) to the allocated memory. This memory is taken from a special part of memory known as **[heap](heap.md)**. This allows to allocate, resize and deallocate potentially very big parts of memory, but requires caution as working with pointers is involved and there is a danger of **memory leaks** -- it is the responsibility of the programmer to free allocated memory with the `free` function once it is no longer needed, otherwise that memory will simply remain allocated and unusable by others (if this happens for example in a loop, the program may just start eating up more and more RAM and eventually run out of memory). Dynamic allocation is also pretty complex (it usually involves communicating with operating system and also keeping track of the structure of memory) and creates a [dependency](dependency.md) on the `stdlib` library. Some implementations of the allocation functions are also infamously slow (up to the point of some programmers resorting to program their own dynamic allocation systems). Therefore only use dynamic allocation when absolutely necessary! Dynamic allocation applies to:
- **memory allocated with special functions** (`malloc`, `calloc`, `realloc`)
Rule of the thumb: use the simplest thing possible, i.e. static allocation if you can, if not then automatic and only as the last option resort to dynamic allocation. The good news is that **you mostly won't need dynamic allocation** -- you basically only need it when working with data whose size can potentially be VERY big and is unknown at compile time (e.g. you need to load a WHOLE file AT ONCE which may potentially be VERY big). In other cases you can get away with static allocation (just reserving some reasonable amount of memory in advance and hope the data fits, e.g. a global array such as `int myData[DATA_MAX_SIZE]`) or automatic allocation if the data is reasonably small (i.e. you just create a variable sized array inside some function that processes the data). If you end up doing dynamic allocation, be careful, but it's not THAT hard to do it right (just pay more attention) and there are tools (e.g. [valgrind](valgrind.md)) to help you find memory leaks. However by the principles of [good design](lrs.md) **you should avoid dynamic allocation** if you can, not only because of the potential for errors and worse performance, but most importantly to avoid dependencies and complexity.
For [pros](pro.md): you can also create your own kind of pseudo dynamic allocation in pure C if you really want to avoid using stdlib or can't use it for some reason. The idea is to allocate a big chunk of memory statically (e.g. global `unsigned char myHeap[MY_HEAP_SIZE];`) and then create functions for allocating and freeing blocks of this static memory (e.g. `myAlloc` and `myFree` with same signatures as `malloc` and `free`). This allows you to use memory more efficiently than if you just dumbly (is it a word?) preallocate everything statically, i.e. you may need less total memory; this may be useful e.g. on [embedded](embedded.md). Yet another uber [hack](hacking.md) to "improve" this may be to allocate the "personal heap" on the stack instead of statically, i.e. you create something like a global pointer `unsigned char *myHeapPointer;`, then somewhere at the beginning of `main` you compute the size `myHeapSize` and then create a local array `myHeap[myHeapSize]`, then finally set the global pointer to it as `myHeapPointer = myHeap`; the rest remains the same (your allocation function will access the heap via the global pointer). Just watch out for reinventing wheels, bugs and that you actually don't end up with a worse mess that if you took a more simple approach. Hell, you might even try to write your own garbage collection and array bound checking and whatnot, but then why just not fuck it and use an already existing abomination like [Java](java.md)? :)
For [pros](pro.md): you can also create your own kind of pseudo dynamic allocation in pure C if you really want to avoid using stdlib or can't use it for some reason. The idea is to allocate a big chunk of memory statically (e.g. global `unsigned char myHeap[MY_HEAP_SIZE];`) and then create functions for allocating and freeing blocks of this static memory (e.g. `myAlloc` and `myFree` with same signatures as `malloc` and `free`). This allows you to use memory more efficiently than if you just dumbly (is it a word?) preallocate everything statically, i.e. you may need less total memory; this may be useful e.g. on [embedded](embedded.md). Yet another uber [hack](hacking.md) to "improve" this may be to allocate the "personal heap" on the stack instead of statically, i.e. you create something like a global pointer `unsigned char *myHeapPointer;` and a global variable `unsigned int myHeapSize;`, then somewhere at the beginning of `main` you compute the size `myHeapSize` and then create a local array `myHeap[myHeapSize]`, then finally set the global pointer to it as `myHeapPointer = myHeap`; the rest remains the same (your allocation function will access the heap via the global pointer). Just watch out for reinventing wheels, bugs and that you actually don't end up with a worse mess that if you took a more simple approach. Hell, you might even try to write your own garbage collection and array bound checking and whatnot, but then why just not fuck it and use an already existing abomination like [Java](java.md)? :)

View file

@ -1,7 +1,11 @@
# Modern
*"Everything that modern culture hates is good, and everything that modern culture loves is bad."* --fschmidt from [reactionary software](reactionary_software.md)
So called *modern* [software](software.md)/[hardware](hardware.md) and other [technology](technology.md) might as well be synonymous with [shitty](shit.md) abusive technology. In a [capitalist](capitalism.md) [age](21st_century.md) when everything is getting progressively worse in terms of design, quality, ethicality, efficiency, etc., newer means worse, therefore modern (*newest*) means *the worst*. In other words *modern* is a term that stands for "as of yet best optimized for exploiting users". At [LRS](lrs.md) we see the term *modern* as negative -- for example whenever someone says "we work with modern technology", he is really saying "we are working with worst technology we know of".
The word *modern* was similarly addressed e.g. by [reactionary software](reactionary_software.md) -- it correctly identifies the word as being connected to a programming orthodoxy of [current times](21st_century.md), the one that's obsessed with creating bad technology and rejecting good technology. { I only found reactionary software after this article has been written. ~drummyfish }
## Modern Vs Old Technology
It's sad and dangerous that newer generation won't even remember technology used to be better, people will soon think that the current disgusting state of technology is the best we can do. That is of course wrong, technology used to be relatively good. It is important we leave here a note on at least a few ways in which old was much, much better.

26
reactionary_software.md Normal file
View file

@ -0,0 +1,26 @@
# Reactionary Software
{ The "founder", fschmidt, sent me a link to his website on saidit after I posted about LRS. Here is how I interpret his take on technology -- as always I may misinterpret or distort something, for safety refer to the original website. ~drummyfish }
Reactionary software (reactionary meaning *opposing the [modern](modern.md), favoring the old*) is a kind of [software](software.md)/[technology](tech.md) philosophy opposing [modern](modern.md) technology and advocating [simplicity](kiss.md) as a basis of good technology (and possibly whole society); it is similar e.g. to [suckless](suckless.md) and our own [less retarded software](lrs.md), though it's not as "hardcore" [minimalist](minimalism.md) (e.g. it's okay with old versions of [Java](java.md) which we still consider kind of [bloated](bloated.md) and therefore [bad](bad.md)). Just as suckless and LRS, reactionary software notices the unbelievably degenerated state of "[modern](modern.md)" technology (reflecting the degenerate state of whole society) manifested in [bloat](bloat.md), overengineering, overcomplicating, user abuse, ugliness, [DRM](drm.md), [bullshit](bullshit.md) features, planned obsolescence, fragility etc., and advocates for rejecting it, for taking a step back to when technology was still sane (before 2000s). The website of reactionary software is at http://www.reactionary.software (on top it reads *Make software great again!*). There is also a nice forum at http://www.mikraite.org/Reactionary-Software-f1999.html (tho requires JS to register? WTF).
The founder of reactionary software is fschmidt and he still seems to be the one who mostly defines it (just like [drummyfish](drummyfish.md) is at the moment basically solo controlling [LRS](lrs.md)), though there is a forum of people who follow him. The philosophy can potentially be extended beyond just software, to other fields of endeavor and potentially whole society -- the discussion of reactionary software revolves around wide context, e.g. things like philosophy, religion and [collapse](collapse.md) of society (fschmidt made a post where he applies Old Testament ideas to programming).
fschmidt seems to be a lot into religion and also has some related side projects with wider scope, e.g. [Arkians](arkians.md) which deals with society and [eugenics](eugenics.md). It seems to be trying to establish a community of "chosen people" (those who pass certain tests) who selective breed to renew good genes in society. { **PLEASE DON'T JUMP TO CONCLUSIONS**, I just quickly skimmed through it -- people will probably freak out and start calling that guy a [Nazi](nazi.md) -- please don't, read his site first. I can't really say more about it as I didn't research it well, but he doesn't seem to be proposing violent solutions. Peace. ~drummyfish }
**What do [we](lrs.md) think about reactionary software?** The vibes are good, it basically seems like "lightweight suckless" -- we agree with what they identify as causes of decline of modern technology, we like that they discuss wide context and the big picture and our solutions are aligned, in the same direction -- theirs are just not as radical, or maybe we just disagree on minor points. We may e.g. disagree on specific cases of software, for example they approve of old [Python](python.md), [Java](java.md) and lightweight [JavaScript](js.md) used on the [web](www.md) -- we see such software as unacceptable, it's too complex, unnecessary and from ground up designed badly. Nevertheless we definitely see it as good this philosophy exists, it contributes to improving technology and it may provide an alternative to people who suffer from modern tech but suckless or LRS is too difficult for them to get into. The fact that more and more smaller communities with ideas similar to LRS come to life indicates the ideas themselves are alive and start to flourish, in a decentralized way -- this is good.
Examples of reactionary software include (examples from the site itself):
- **[bash](bash.md)**: Possibly the most popular [Unix](unix.md) shell. In hardocore minimalist circles bash is still considered bloated and/or [harmful](harmful.dm) due to its extensions over standard [Posix](posix.md) shell, but indeed compared to mainstream software bash is pretty KISS.
- **old versions of languages such as [Java](java.md) and [Python](python.md)**: TBH these are seriously [bloated](bloat.md) -- the older versions maybe not THAT much but still. Even if these language may appear minimal to the programmer (e.g. by syntax or concepts), they are necessarily extremely complicated on the inside (see [pseudominimalism](pseudominimalism.md)), even if just for their HUGE standard libraries.
- **[Mercurial](mercurial.md)**: OK, here the guy just bashes and shits on [git](git.md) for being extremely bloated and unusable -- of course, git is a bit bloated, but definitely not more than Java or Python. Not sure Mercurial is really so much better. { I have literally never touched Mercurial so I don't know, I just know that Git is a bit complex but still usable (just commit, push and pull) AND it doesn't even matter that much as my project do not depend on git, git is basically just a way for me to put my code on the internet and sync in between my machines. If git stops existing I can literally just use FTP or something. ~drummyfish }
- **[Luan](luan.md)**: Their own programming language. TODO: research it :)
- ...
## See Also
- [suckless](suckless.md)
- [KISS](kiss.md)

View file

@ -37,5 +37,6 @@ Notable projects developed by the suckless group include:
- [dmenu](dmenu.md)
- [surf](surf.md)
- [stali](stali.md)
- [reactionary software](reactionary_software.md)
However there are many more, check out their website.