which ran a complete open source software stack. </p>
<p> The success of Linux, or <em>GNU/Linux</em> as some prefer to
-call it for reasons that should now be clear, has only increased
-over time, to the point where commercial Unix systems are mostly
-irrelevant. Today Linux runs on a wide variety of machines ranging
-from supercomputers to workstations, smart phones and IOT (internet
-of things) devices with very limited resources. </p>
-
-<p> The same companies which almost killed Unix by commercializing it
-in order to maximize their profit make money with Linux today. However,
-they had to adjust their business model in order to comply with the
-GPL. Rather than selling proprietary software, they bundle open source
-software and sell support to paying customers. Some companies also
-sell hardware with Linux pre-installed. </p>
+call it for reasons that should now be clear, steadily increased over
+time. In 2003 the SCO group, a company which sold a proprietary Unix
+system, was unhappy about this progress and sued IBM, which offered
+various Linux products. SCO claimed to be the owner of Unix, and that
+Linux contained "millions of lines" of code copied from Unix. SCO's
+lawyers argued that the success of Linux originated from this theft
+of intellectual property and asked for $5 billion as compensation
+for the resulting losses. The company also tried to collect taxes
+from other Linux users. Microsoft funded SCO in these efforts. </p>
+
+<p> In the end SCO lost the lawsuit since it was evident that all that
+copied code never existed. In fact, the court ruled that SCO did not
+even own the Unix copyrights to begin with. Another fun fact is that
+the large number of bugs in the early Linux code actually helped to
+prove that Linux was original work. The long term effects of this
+lawsuit, an improved position of Linux and its ecosystem, last until
+the presence. Commercial Unix systems have become irrelevant as Linux
+runs on a wide variety of machines ranging from supercomputers to
+workstations, smart phones and IOT (internet of things) devices with
+very limited resources. </p>
+
+<p> While SCO went bankrupt eventually, some of the companies which
+almost killed Unix by maximizing their own profit still exist, and
+make money with Linux today. However, they had to adjust their
+business model in order to comply with the GPL. Rather than selling
+proprietary software, they bundle open source software and sell
+support to paying customers. Some companies also sell hardware with
+Linux pre-installed. </p>
SUBSECTION(«Linux Distributions»)
<code>..</code> which refer to the directory itself and its parent
directory, respectively. </p>
+<p> One consequence of the special meaning of the path components
+<code>.</code> and <code>..</code> is that there are infinitely
+many paths which refer to the same file. Indeed, given the path
+<code>/foo/bar</code>, one may construct different paths which
+refer to the same file by inserting any number of <code>/.</code>
+or <code>../foo</code> after the first component. For example,
+<code>/foo/./bar</code> and <code>/foo/../foo/bar</code> both refer
+to the same file. If relative paths have to be taken into account as
+well, even more paths can be constructed. </p>
+
+<p> This illustrates the fundamental difference between a path and a
+file. Paths can be mapped to files, but not the other way around. In
+particular, there is no such thing like "the list of paths which
+have changed since yesterday". Also, it is incorrect to assume
+that two files are different just because their paths are different.
+The concept of hard- and soft links discussed below further complicates
+the relationship between paths and files. </p>
+
SUBSECTION(«Globbing»)
<p> Globbing, also known as <em>pathname expansion</em>, is a pattern
globbing available to other applications. These are implemented as
part of libc. </p>
-
<p> There are a few quirks related to globbing which are worth to
point out. First, if no valid path matches the given pattern, the
expansion of the pattern is, by definition according to POSIX, the
for large filesystems, and the result is unreliable anyway unless
the filesystems are mounted read-only. </p>
+<p> It is possible to choose among all possible paths which refer
+to the same file a <em>canonical</em> path, that is, a shortest
+(counting characters) absolute path which does not contain any soft
+links. In fact, the POSIX standard requires each Unix system library
+to provide the <code>realpath()</code> library function which performs
+the following substitutions on the given path: First, the path to
+the current working directory is prepended if the given path is
+relative (does not begin with a slash). Second, symbolic links are
+replaced by their targets. Third, any occurrences of <code>/.</code>
+and <code>foo/..</code> are removed. The thusly transformed path is
+returned by the function as the canonical path. </p>
+
+<p> Each path can be canonicalized in this way, but not all paths
+which refer to the same file give rise to the same canonical path. For
+example, <code>/tmp/foo</code> and <code>/tmp/bar</code> could refer
+to regular files which are hard links of each other. In this case the
+paths refer to the same file, yet the paths are different and already
+canonicalized. The same can happen when a file system (or a subtree
+of it) is <em>bind mounted</em>. That is, the file system tree is
+visible at two or more locations in the global directory tree. </p>
+
EXERCISES()
<ul>
file type for hard links? </li>
</ul>
-HOMEWORK(«
-How many paths are there that refer to the same file?
-», «
-Given the path <code>/foo/bar</code>, one may construct different paths
-which refer to the same file by inserting any number of <code>/.</code>
-or <code>../foo</code> after the first component. For example,
-<code>/foo/./bar</code> and <code>/foo/../foo/bar</code> both refer
-to the same file. If relative paths have to be taken into account as
-well, even more paths can be constructed easily. Hence the answer is:
-arbitrary many.
-
-This illustrates the fundamental difference between a path and a
-file. Paths can be mapped to files, but not the other way around. In
-particular, there is no such thing like "the list of paths which have
-changed since yesterday".
-
-The concept of hard- and soft links complicates the situation further.
-»)
-
HOMEWORK(«
Given two paths, how can one tell if they refer to the same file?
», «
»)
-HOMEWORK(«
-
-Is it possible to choose among all possible paths which refer to the
-same file a <em>canonical</em> path? That is, a shortest (counting
-characters) absolute path which does not contain any soft links?
-
-», «
-
-<p> The POSIX standard requires each Unix system library to provide
-the <code>realpath()</code> function which performs the following
-substitutions on the given path: First, the path to the current
-working directory is prepended if the given path is relative
-(does not begin with a slash). Second, symbolic links are replaced
-by their targets. Third, any occurrences of <code>/.</code> and
-<code>foo/..</code> are removed. The thusly transformed path is
-returned by the function as the canonical path. </p>
-
-<p> Although each path can be canonicalized in this way, not all paths
-which refer to the same file give rise to the same canonical path. For
-example, <code>/tmp/foo</code> and <code>/tmp/bar</code> could refer
-to regular files which are hard links of each other. In this case the
-paths refer to the same file, yet the paths are different and already
-canonicalized. The same can happen when a file system (or a subtree
-of it) is <em>bind mounted</em>. That is, the file system tree is
-visible at two or more locations in the global directory tree. </p>
-
-The message of this exercise is to convince the reader that it is
-incorrect to assume that two files are different because their paths
-are different.
-
-»)
-
SECTION(«Processes»)
<p> A <em>program</em> consists of instructions and data stored in
<p> The <code>pipe(2)</code> system call takes no arguments and
creates two file descriptors for the calling process which are tied
-together as a unidirectional first in, first out data channel that
-works just like a fifo, but without any files being involved. One
+together as a unidirectional first in, first out data channel. One
file descriptor is the <em>read end</em> of the pipe, the other is
the <em>write end</em>. Data written to the write end is buffered by
the kernel and can be obtained by reading from the read end. </p>
communicate with the child by writing a message to the write end of
the pipe for the child to read. </p>
+<p> This approach depends on file descriptor inheritance across
+<code>fork(2)</code>, so it does not work in the situation
+where neither process is an ancestor of the other. Files of
+type <em>fifo</em> (named pipes) overcome this restriction. To
+establish a connection between two <em>unrelated</em> processes,
+both processes call <code>open(2)</code> to obtain a file
+descriptor which is associated with the fifo. One process passes
+the <code>O_WRONLY</code> flag to open the file for writing while
+the other passes <code>O_RDONLY</code> to open it for reading. The
+two processes may then communicate in the same way as with the
+<code>pipe(2)/fork(2)</code> approach. </p>
+
<p> The POSIX <code>dup(2)</code> and <code>dup2(2)</code> system
calls allow a process to manipulate the entries of its file descriptor
array. In particular the standard file descriptors 0, 1, and 2 can be
and <code>wc(1)</code> reads from stdin, <code>wc(1)</code> processes
the output of <code>ls(1)</code>. </p>
-<p> Note that this trick does not work to establish a connection
-between two <em>existing</em> processes because it depends on file
-descriptor inheritance across <code>fork(2)</code>. In the general
-case one has to fall back to sockets or fifos to create the data
-channel. </p>
-
SUBSECTION(«Stdio»)
<p> The POSIX standard requires a compliant Unix system to provide
href="https://www.newyorker.com/business/currency/the-gnu-manifesto-turns-thirty">
The GNU Manifesto Turns Thirty</a>, by Maria Bustillos. </li>
+ <li> <a href="https://lwn.net/Articles/924577/">The SCO lawsuit,
+ 20 years later</a> </li>
+
<li> <a
href="http://www.catb.org/~esr/writings/unix-koans/end-user.html">
The Koan of Master Foo and the End User</a>. </li>
projects / aple.git / blobdiff