On Fri, 3 Mar 2017 15:55:28 -0500
Anton Aylward
On 03/03/17 11:29 AM, Stefan Seyfried wrote:
Oh, you mean like the very, very small original small and fast Bourne shell of the V7 era (about 24k binary on a PDP-11 IIR) ....
Whataboutism isnt going to help your alternative facts. o "alternative" about it. That's what is was.
But it has nothing to do with the issue at hand. Thus whataboutism.
Not. You people keep saying what UNIX and Linux is supposed to be, quoting old maxims. You forget that many of then grew out of context, as as I keep saying, Context is Everything
The context *WAS* the PDP-11. Small memory space, small disk space. As a result, the shell was important and it was a small binary because this was a small machine. And as such it was very simple. That was design decision that resulted from the constraints of using a PDP-11.
And along with that were the collection of other small programs. They each did one thing and one thing only because of the space limitation.
There is also a development paradigm called "divide and conquer". Even if your system resources allows for one 'sysd' that does everything from managing interrupts to editing your spreadsheet it is benefical to divide the problem of running a system into sub-problems that are easy to understand and solved in isolation.
On the PDP-11 of that era many system tools, many applications, were written in shell script. And small scripts at that, ones that could fit in a single or perhaps a small number of disk blocks. It was easier to do that than have binaries that took up more space (in core and on disk) and resulted in more swapping and degraded performance.
It is still useful that those scripts can be modified without installing a full development environment.
And so began a tradition that persisted even when those constraints no longer applied. Some of those 'maxims' were specific to the PDP-11 context. Perhaps they were good ones; certainly scripting is a powerful approach. But then again, scripting is based around the idea of using an interpreter.
In "The Mythical man Month" (page 102 of the original edition) Brooks points out the advantage of using an interpreter: <quote> I recall a young man undertaking to build a an elaborate console interpreter for an IBM 360. He ended up packing it into an incredibly small amount of space by building and interpreter for the interpreter, recognising that human interactions were slow and infrequent, but space was dear. </quote>
Interestingly, the section is titled "Representation is the Essence of Programming" and the paragraph before the above quotation has <quote> Show me your tables, and I won't usually need your flowcharts; they'll be obvious. </quote>
UNIX and Linux have *SO* many tables. Colon delimited one like /etc/passwd; space delimited one like /etc/fstab. It is important to noted that while inetd used a single file, space delimited configuration file, its replacement, Xinetd, used a single file per service format. https://en.wikipedia.org/wiki/Xinetd#Configuration This offered a lot more controllability and flexibility, as well as visibility and ability to document each service and its why and wherefores. If you want an example of the "each thing does only one thing" axiom, we have here 'each thing specifies only one thing'. The table, instead of being all in one file, is now, in effect, "one row in each file".
If you think about it, this is an ancestor, conceptually speaking, to the system unit files.
Except on sysvinit you still have one init script per service. And usually one configuration file per service as well. On the other hand, systemd units tend to encompass configuration and service definition in one file. Smaller than the init script but no longer do they separate the service and the configuration. So that is a step backwards. You can customize the configuration but only by customizing the service at the same time. That's not to say that split definition of systemd service and external configuration is not possible, at least in some cases. It may not be possible in others or I might just not know how to do it. Problem is package maintainers writing the systemd service definitions often do not know how to write one. So it ends up as configuration jumbled together with service definition in one file, often totally broken. So if we cannot educate package maintainers how to write service definitions that work or fix up the mess afterwards it is too early to adopt systemd. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org