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. 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. 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. Despite what you say, Stefan, it is relevant because it shows how we got here, shows the progression of changes as the constraints changed, and how a few immensely powerful basic ideas, namely table representation and the use of an interpreter to apply those table entries, has been a constant feature though UNIX and Linux. And, personally speaking, I'm glad those unit files are not all one big XML file! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org