Chapter 19 touches again the topic of Open Source. This time digging deeper into it, covering licensing and best practices.

Open source has changed the world of computing.
Now I can release a software at night, sleep, and, after wake up, see it forked, used and improved by others.

(10-07-2021, 10:23 AM)venam Wrote: Some people have taken this religiously today. A lot of the new languages upgrade often, every months, sometimes breaking backward compatibility. Mort shared on IRC this zero ver, which is relevant.

The problem is when the early zero-ver releases are used on production. Releasing earlier can be really rewarding in the sense that others can start to contribute to a new project in its initial stages, which is easier than to starting to contribute to a solid, mostly-complete project.
I think that the “release early, release often” applies when we are releasing for other programmers, not for users. For users, we need to release later and release less often.

Chapter 20 concludes the history of Unix by previewing its future.

First the author says how Unix adapted to three new important technologies: the Internet, the GUI and cheap PCs.

Then comes the first mention to Plan9 in the book. Plan9 solves the problems of Unix (and even exposes design problems).
However, Plan9 fails because Unix hadn't. As the author says:

Quote:The most dangerous enemy of a better solution is an existing codebase that is just good enough.

Some problems in the design of UNIX are analyzed.

First, the “file is a stream of bytes” problem. Some operating system, such as Haiku/BeOS have a database-like file system, in which metadata are associated with each file.
A database file system is flawed on file operations and how should them preserve metadata, especially when files are transmitted over the network to different systems.

Second, the weak GUI problem. The WIMP drag-and-drop look-and-feel of Macintosh is not comparable to Unix's.
Now KDE is, in my opinion, what best emulates this traditional look-and-feel; while Gnome is trying to implement a novel one.

Then, irreversible file deletion.
We have a XDG specification on trash can. If you are interested, I have implemented it as a simple shell script
Plan9 also tries to solve this problem by implementing a file-versioning file system.

Quote:There is no standard, well-established way to ask the system to notify an application if and when a specified file or directory changes.

We have Linux inotify and BSD kqueue. But no standard, portable way.

Other problems in UNIX design enumerated by the author are botched job control, lack of exception handling in C, botched ioctl(2) and fcntl(2), and the superuser and the setuid.

The chapter ends with some flaws of the UNIX culture, in special the elitism that still exist in our community.