Linda Walsh said the following on 05/09/2013 10:02 AM:
Anton Aylward wrote:
In that, it holds with a good and long standing UNIX tradition, making things table driven.
---- Where do you get that? Table driven is for machines.
Unix gave us bash, perl, python ruby, et all... all different tools that are script driven. Oracle gives you table driven. Windows with it's many tables and registries is table driven.
SystemD is a large-corporation set on total control tool, unix is a division of power with multiple ways to do one thing.
Systemd is not unix or linux.
UNIX has a long tradition of tables-as-text-files They usually come in two forms. The first is files the the password file. Each record is one line and the fields are delimited by, for example in the case of the password file, colons. you can find examples of this going back in UNIX to the early 70s. By the time of V7 it was well established and has continued. The second involves more complex records. These are either one-record-per file or delimited 'stanzas'. A good illustration of this is the shift from the one-record-per-line format of INETD to the one-record-per-file format of XINETD. In some cases the same kind of record that XINETD uses has been condensed to a single file. IBM did a lot of that with early AIX. Perhaps the classic example of this is the xorg.conf files, the all-in-one and now the one-file-per-item in org.conf.d/ The simplistic key-value style of 'database' we can see in various dedicated config files, most notably do do with the X project. There have been many variations on how the 'stanzas' are delimited. XINETD and xorg.conf use curly brackets in the C tradition. SSH uses a similar label/indent form but without the brackets. The current direction is to use XML style labelling and delimiting with the idea that this carries additional semantics. Yes, systemd is not UNIX. The developers made that quite clear; it is clearly stated that it is to address the needs of the Linux architecture, not the AIX or Solaris architecture. This is not odd. Solaris and AIX, as well as HPUX and who knows what else, have very specific 'value added' features some of which relate back to the hardware. I'm surprised that you assert that the interpreters are not table driven. All of then convert source to a byte steam and use that byte stream to look yp in the interpreters dispatch tables what to do. That the table might be folded into the code in various ways rather than an explicit SQL database doens't make them any the less tables. That the tables might, as in the style of FORTH, be dynamic or contain code or pointers to code is also beside the point. Some interpreters that don't need huge key-word lists and the kitchen sink of built-ins (Perl and PHP and to a large degree Ruby are examples of the 'kitchen sink') are very lean and fast. The original shell from the 'original' UNIX V7, courtesy of Stephen Bourne, was tiny. It was a very straight forward stack oriented parser and dispatcher. Systemd is like that too; it is small and is essentially a dispatcher. Just as the shell, in V7 days, was encompassing because, due to space limitations, scripts were preferred over compiled code. There were a LOT of scripts and the functionality of V7 UNIX was easy to learn from reading them. Systemd has a huge amount of internal table space, nearly twice as much as bash. $ size /bin/systemd text data bss dec hex filename 818235 34736 2320 855291 d0cfb /bin/systemd That's in addition to the external tables. Even when we subtract the tables for error dispatching we still have a huge amount of stuff for dynamically generating tables - that is the tables are internal. You don't need to access the source: running 'strings' on the binary will not only show you the error and dispatch and function name=>dispatch tables but will also show you the tables that are expressed as XML. All in all systemd ends up being about the same size as current bash. By comparison with perl and ruby: -rwxr-xr-x 1 root root 607484 Mar 25 08:10 /bin/bash -rwxr-xr-x 1 root root 860092 Jan 4 06:52 /bin/systemd -rwxr-xr-x 2 root root 1493388 Mar 11 07:06 /usr/bin/perl -rwxr-xr-x 1 root root 2109312 Mar 26 07:06 /usr/lib/libruby1.9.so.1.9.1 text data bss dec hex filename 596709 8256 26096 631061 9a115 /bin/bash 818235 34736 2320 855291 d0cfb /bin/systemd 1479378 9452 252 1489082 16b8ba /usr/bin/perl 2090923 15456 64644 2171023 21208f /usr/lib/libruby1.9.so.1.9.1 If your argument is that systemd is taking much under its wing, then I agree and I think that is a good thing because its simplifying and rationalizing (as in decreasing the entropy) for the many different and ad-hoc ways of doing things. The utilities are still out there; systemd is just managing them in a more regular fashion. And that's the point. What really makes the difference between *NIX and Windows is that *NIX has a few basic patterns that are used over and over. The various control tables and config files I mentioned above are examples of that. They are all plain text, easy to comment (unlike the Windows registry), follow the 'each thing does one thing' principle of Pike: the interpreter just interprets them and each one takes case of just one thing. Clean, simple and regular. Much more so than an ad-hoc collection of scripts that are written in different ways. I can give more examples of *NIX rationalising ad-hoc code to a table driven format if you like; its a long standing tradition that has always led to more power and more functionality and encouraged developers to new things. Take for example the kernel's vfs mechanism. Instead of drivers being hard coded one at a time into the kernel there is now a dispatch table that the drivers plug into. It has led to the development of many new file systems. -- I suspect that, over time, all bureaucratic processes decay into cargo cults unless regularly challenged by a hostile reality. - Alan Rocker, 23-Nov-2011 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org