Update

unix.md

@@ -2,24 +2,24 @@
 
 *"Those who don't know Unix are [doomed](doom.md) to reinvent it, poorly."* --obligatory quote by Henry Spencer
 
-Unix (plurar *Unixes* or *Unices*) is an [old](old.md) [operating system](operating_system.md) developed since 1960s as a research project of [Bell Labs](bell_labs.md), which has become one of the most influential pieces of software in history and whose principles (e.g. the [Unix philosophy](unix_philosophy.md), [everything is a file](everything_is_a_file.md), ...) live on in many so called  Unix-like operating systems such as [Linux](linux.md) and [BSD](bsd.md) (at least to some degree). The original system itself is no longer in use (it was later followed by a new project, [plan9](plan9.md), which itself is now pretty old), the name UNIX is nowadays a [trademark](trademark.md) and a certification. However, as someone once said, *Unix is not so much an operating system as a way of thinking*.
+Unix (plurar *Unixes* or *Unices*) is an [old](old.md) [operating system](operating_system.md) developed since 1960s as a research project of [Bell Labs](bell_labs.md), which has become one of the most influential pieces of software in [history](history.md) and whose principles (e.g. the [Unix philosophy](unix_philosophy.md), [everything is a file](everything_is_a_file.md), ...) live on in many so called  Unix-like operating systems such as [GNU](gnu.md)/[Linux](linux.md) and [BSD](bsd.md) (at least to some degree). The original system itself is no longer in wide use (it was later followed by [plan9](plan9.md), a [project](projects.md) which by now is itself also pretty old), the name UNIX is currently a [trademark](trademark.md) and a certification. Nonetheless Unix is not significant for being a fossil operating system in a museum but rather as a concept, for as someone once said: *Unix is not so much an operating system as a way of thinking*.
 
-In one aspect Unix has reached the highest level a software can strive for: it has transcended its implementation and became a [de facto standard](de_facto_standard.md). This means it has become a set of interface conventions, "paradigms", [cultural](culture.md) and philosophical ideas rather than being a single system, it lives on as a concept that has many implementations. This is extremely important as we don't depend on any single Unix implementation but we have a great variety of choice between which we can switch without greater issues. This is very important for [freedom](freedom.md) -- it prevents monopolization -- and its one of the important reasons to use unix-like systems.
+In one aspect Unix has achieved the highest status a piece of software can strive for: it has transcended its implementation and became a [de facto standard](de_facto_standard.md). That is to say it became a set of interface conventions, programming principles, "[paradigms](paradigm.md)", [cultural](culture.md) and philosophical ideas rather than being a single system, a blob of 1s and 0s, it lives on as a concept that's being reimplemented, imitated and adopted to various degrees. This is remarkably important and puts Unix among the most significant terms in technological world, as we now don't depend on any single Unix implementation but instead have a choice of great variety of Unix systems which we can switch between without too much trouble, just like for example the [C](c.md) language (which was developed as part of Unix) is nowadays an abstract language enjoying many different implementations. This is invaluable as prerequisite for true technological [freedom](freedom.md), as freedom of choice prevents monopolization, and as a consequence stands as yet another argument for using Unix systems more.
 
 The main highlights of Unix are possibly these:
 
-- **[Unix philosophy](unix_philosophy.md)**: a kind of general mindset of software development, usually summed up as **"do one things well"** (rather than ["do everything but poorly"](windows_philosophy.md)) and "make programs work in collaboration with other programs", advising on using universal text interfaces for communication etc. This often comes with the idea of **[pipes](pipe.md)**, a way of chaining programs (typically using the pipe `|` operator, hence the name) by sending one program's output to other program's input.
-- **[everything is a file](everything_is_a_file.md)**: Unix chose to use the [file](file.md) abstraction to enable universal communication of programs with hardware and among themselves, i.e. on unices most things such as printing, reading keyboard, networking etc. will be likely implemented as reading or writing to/from some special (sometimes just virtual) file. This has the advantage of being able to just use some file reading library or syscall, not having to access physical memory bits in memory, which may be difficult, unsafe etc.
-- Text centrism (great [command line](cli.md) preference), value on [portability](portability.md) (even over performance), sharing of source code, freedom of information and openness, connection to [hacker culture](hacking.md), valuing human time over machine time, ...
+- **[Unix philosophy](unix_philosophy.md)**: a kind of general mindset of software development, based on [minimalism](minimalism.md), frequently summed up as **"do one things well"** (rather than ["do everything but poorly"](windows_philosophy.md)) and "make programs work in collaboration with other programs", advising on using universal text interfaces for communication etc. In practice this manifests as so called **[pipelines](pipe.md)**, a way of chaining programs (typically using the pipe `|` operator, hence the name) by sending one program's output to other program's input. This philosophy is in contrast with so called "[Windows](windows.md) philosophy": that of creating big, [bloated](bloat.md) "monolithic" programs.
+- **[everything is a file](everything_is_a_file.md)**: Unix chose to use the [file](file.md) [abstraction](abstraction.md) to enable universal communication of programs with hardware and among themselves, i.e. on unices most things such as printing, reading keyboard, networking etc. will be likely implemented as reading or writing to/from some special (sometimes just virtual) file. This has the advantage of being able to just use some file reading library or syscall, not having to access physical memory bits in memory, which may be difficult, unsafe etc.
+- Text centrism, preference of working with the [command line](cli.md) (avoiding [GUI](gui.md)), preference of text formats, value on [portability](portability.md) (even before performance), sharing of source code, freedom of [information](information.md) and openness, connection to [hacker culture](hacking.md), valuing human time over machine time, ...
 - ...
 
-Unix is greatly connected to software [minimalism](minimalism.md), however most unices are still not minimalist to absolute extreme and many unix forks (e.g. [GNU](gnu.md)/[Linux](linux.md)) just abandon minimalism as a priority. So the question stands: **is Unix [LRS](lrs.md) or is it too [bloated](bloat.md)?** The answer to this will be similar to our stance towards the [C](c.md) language (which itself was developed alongside Unix); from our point of view Unix -- i.e. its concepts and some of their existing implementations -- is relatively good, there is a lot of wisdom to take away (e.g. "do one thing well", modularity, "use text interfaces", ...), however these are intermixed with things which under more strict minimalism we may want to abandon (e.g. multiple users, file permissions and ownership, also "everything is a file" requires we buy into the file [abstraction](abstraction.md) and will often also imply existence of a file system etc., which may be unnecessary, even multitasking could be dropped), so in some ways we see Unix as a temporary "[least evil](least_evil.md)" tool on our way to truly good, extremely minimalist technology. [DuskOS](duskos.md) is an example of operating system more close to the final idea of LRS. But for now Unix is very cool, some Unix-like systems are definitely a good choice nowadays.
+Unix is significantly connected to software [minimalism](minimalism.md), however most unices are still not minimalist to absolute extreme and many unix forks (e.g. [GNU](gnu.md)/[Linux](linux.md)) just abandon minimalism as a top priority. So the question stands: **is Unix [LRS](lrs.md) or is it too [bloated](bloat.md)?** The answer to this will be similar to our stance towards the [C](c.md) language (which itself was developed alongside Unix); from our point of view Unix -- i.e. its concepts and some of their existing implementations -- is relatively [good](good.md), there is a lot of wisdom to take away (e.g. "do one thing well", modularity, "use text interfaces", ...), however these are intermixed with things which under more strict minimalism we may want to abandon (e.g. multiple users, file permissions and ownership, also "everything is a file" requires we buy into the file [abstraction](abstraction.md) and will often also imply existence of a file system etc., which may be unnecessary, even multitasking could be dropped), so in some ways we see Unix as a temporary "[least evil](least_evil.md)" tool on our way to truly good, extremely minimalist technology. [DuskOS](duskos.md) is an example of operating system more close to the final idea of LRS. But for now Unix is very cool, some Unix-like systems are definitely a good choice nowadays.
 
 There is a semi humorous group called the *UNIX HATERS* that has a mailing list and a whole book that criticizes Unix, arguing that the systems that came before it were much better -- though it's mostly just [joking](jokes.md), they give some good points sometimes. It's like they are the biggest boomers for whom the Unix is what [Windows](windows.md) is to the Unix people.
 
 ## History
 
-In the 1960s, Bell Labs along with other groups were developing [Multics](multics.md), a kind of [operating system](os.md) -- however the project failed and was abandoned for its complexity and expensiveness of development. In 1969 two Multics developers, [Ken Thompson](key_thompson.md) and [Dennis Ritchie](dennis_ritchie.md), then started to create their own system, this time with a different philosophy; that of [simplicity](minimalism.md) (see [Unix philosophy](unix_philosophy.md)). They weren't alone in developing the system, a number of other hackers helped program such things as a file system, [shell](shell.md) and simple utility programs. At VCF East 2019 Thompson said that they developed Unix as a working system in three weeks. At this point Unix was written in [assembly](assembly.md).
+In the 1960s, Bell Labs along with other groups were developing [Multics](multics.md), a kind of [operating system](os.md) -- however the project failed and was abandoned for its complexity and expensive development. In 1969 two Multics developers, [Ken Thompson](key_thompson.md) and [Dennis Ritchie](dennis_ritchie.md), then started to create their own system, this time with a different approach; that of [simplicity](minimalism.md) (see [Unix philosophy](unix_philosophy.md)). They weren't alone in developing the system, a number of other hackers helped program certain parts such as a file system, [shell](shell.md) and simple utility programs. At VCF East 2019 Thompson said that they developed Unix as a working system in three weeks. At this point Unix was written in [assembly](assembly.md).
 
 In the early 1970s the system got funding as well as its name Unix (a pun on Multix). By now Thompson and Richie were developing a new language for Unix which would eventually become the [C](c.md) language. In version 4 (1973) Unix was rewritten in C.
 
@@ -43,9 +43,9 @@ Learning to use Unix in practical terms firstly means **learning the [command li
 
 PRO TIP: convenient features are often implemented, most useful ones include going through the history of previously typed commands with UP/DOWN keys and completing commands with the TAB key, which you'll find yourself using very frequently. Try it. It's enough to type just first few letters and then press tab, the command will be completed (at least as much as can be guessed).
 
-You run a utility simply by writing its name, for example typing `ls` will show you a list of files in your current directory. Very important is the `man` command that shows you a **manual page** for another command, e.g. typing `man ls` should display a page explaining the `ls` utility in detail. Short help for a utility can also usually be obtained by writing `-h` after it, for example `grep -h`.
+You run a utility simply by typing its name, for example writing `ls` will show you a list of files in your current directory. Very important is the `man` command that shows you a **manual page** for another command, e.g. typing `man ls` should display a page explaining the `ls` utility in detail. Short help for a utility can also usually be obtained by writing `-h` after it, for example `grep -h`.
 
-Unix utilities (and other programs) can also be invoked with **arguments** that specify more detail about what should be done. Arguments are written after the utility name and are separated by spaces (if the argument itself should contain space, it must be enclosed between double quotes, e.g.: `"abc def"` is a single arguments containing space, but `abc def` are two arguments). For example the `cd` (change directory) utility must be given the name of a directory to go to, e.g. `cd mydirectory`.
+Unix utilities (and other programs) can also be invoked with **arguments** that specify more detail about what should be done. Arguments go after the utility name and are separated by spaces (if the argument itself should contain a space, it must be enclosed between double quotes, e.g.: `"abc def"` is a single arguments containing space, but `abc def` are two arguments). For example the `cd` (change directory) utility must be given the name of a directory to go to, e.g. `cd mydirectory`.
 
 Some arguments start with one or two minus characters (`-`), for example `-h` or `--help`. These are usually called **flags** and serve either to turn something on/off or to name other parameters. For example many utilities accept a `-s` flag which means "silent" and tells the utility to shut up and not write anything out. A flag oftentimes has a short and long form (the long one starting with two minus characters), so `-s` and `--silent` are the same thing. The other type of flag says what kind of argument the following argument is going to be -- for example a common one is `--output` (or `-o`)  with which we specify the name of the output file, so for instance running a C compiler may look like `c99 mysourcecode.c --output myprogram` (we tell the compiler to name the final program "myprogram"). Short flags can usually be combined like so: instead of `-a -b -c` we can write just `-abc`. Flags accepted by utilities along with their meaning are documented in the manual pages (see above).