In February I made a lecture on using the make utility to automate tests. Debugging can be made efficient by conducting tests on small units. It's hard to find a needle in a haystack, but not so if the pile of hay fits into your palms. Ideally the tests should be written in a makefile so a check can be conducted every time the source code is modified.
Like many other UNIX-derived utilities, make is a language. As a language it is tough to study. There are several reasons for this. For one thing GNU Make, the most widely used implementation, is rich in features. The intricate details make GNU Make textbooks such as the one from O'Reilly hard to digest: the reader is easily disoriented. In addition, and perhaps more importantly, there is an acute shortage of makefiles to use as study material. Makefiles describe the build processes of the Linux kernel, GCC, Glibc, GNU binutils, GNU coreutils, Bash and most other major OS components. However the packages seldom come with a ready-to-run makefile. Instead the makefile is produced by a configure script. Such machine-generated makefiles are difficult to analyze and are of little educational value. Major OS component packages with a ready-to-run makefile are extremely rare. In fact I can name only one package: bzip2. I would like fellow list subscribers here to take some time and contemplate why this has happened. GNU source packages are designed to work in diverse environments. The autoconf and automake tools which create the configure scripts and makefiles evolved to cope with this requirement. Many developers of packages outside GNU who want their programs to be widely portable also make use of autoconf and automake and provide the required files. Most people who have heard of a "Linux" OS aren't aware about this. They assume that "Linux" is a standard. Microsoft Windows and MacOS are standards and corporate PR campaigns stress this fact. People would naturally assume that if "Linux" is an "OS" it must be something similar. In reality there is no "standard Linux", only distributions which combine system components and popular applications selected in accordance to certain policies. When it comes to the actual components that go into distributions there is significant variation. For example, most distributions use Bash as the default shell and Gawk as the awk interpreter but Debian employs Dash and Mawk, respectively, in their places. The configure and make procedure makes this possible. I suspect that those who promote "Linux" for the name of the entire OS do not want people to find out that there is no such thing as a "standard Linux". Our efforts to promote the name "GNU/Linux" for the entire OS have not been totally successful. One reason behind this is persistent effort to prevent this name from getting established. Some people are adamant and go to extremes concerning this. We should think why there exists such strong opposition while examining how the myth of a "standard Linux" influenced efforts on both sides. There is another point I would like to raise here. We said "GNU/Linux" is the appropriate name for the operating system, but too often overlooked the fact that many people do not think much what an operating system is. This is because there are many people with little or no experience with the typical operations of the system. Some of them are highly influential in spite of their ignorance. For example the following is a typical install operation: tar xfz foo.1.1.1.tar.gz cd foo.1.1.1 ./configure make make install cd .. rm -rf foo.1.1.1 If successful this is all that the user needs to do. Often the above fails and some more steps, such as installing another package or modifying some code becomes necessary. These additional steps are also operations and they tend to follow a pattern. There are build experts who support the distributions. Their work fill in the gaps which autoconf and automake fail to cover. At the beginning of this article I discussed automated tests. Writing tests and putting them together in a makefile is a typical serial operation. Test data or test input files are often mechanically generated by operations which employ OS-level utilities. So I suggest that we, instead of merely attaching "GNU" to "Linux", send a message that "GNU" and "Linux" are separate, and that the engineers who are aware of the difference and treat it as something other than a political disagreement possess a set of valuable skills. Those who make the distinction and are aware of what the "GNU" part is capable of are adept with operations such as installation of software, backing up data, adding or replacing hardware, salvaging a damaged system and conducting tests before and after any major change. We should try to enlighten people to the fact that instead of a "standard Linux system" we have an "ecosystem with various GNU/Linux distributions". It may be difficult, given the existing prejudices, but people are aware that their lives are ever more reliant on computer systems and there are great benefits in truly understanding them while the risks associated to ignorance is growing steadily. Thank you for reading. Akira Urushibata _______________________________________________ libreplanet-discuss mailing list [email protected] https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss
