On 09/28/2014 06:29 PM, Ruben Safir wrote:
The point goes right over your head. Is it because your not bright enough, or that you are too young or what is it with you? init and shell don't fail because they a small applications that run and then go AWAY, until systemd which just runs and runs and runs.
So instead of a SYSTEM now, you have a single dameon that runs everything, and yes it can fail, and yes it does fail, and when it does forget about getting a shell since it also controls the getty process.
Its clear that you don't understand how either init or the shell work. In the MS-DOS world, derived from things like CP/M which in turn was derived from the DOS model of the PDP-8 and similar, the command executor worked in what was called the Transient Program Area, loaded the program in there, overwriting itself. In effect it 'ran and went away'. The shell is not like that. It parses the script. The script may be one line from the console or it may be a file. Its STDIN. DOS/MS-DOS differentiated between file input and console input. Shell builds the parse tree and walks it. It executes a subcommand such as test, which is now internal but was originally external. That it can branch and loop means that IT DOES NOT GO AWAY. Yes you can create subshell that have limited life, but the shell does not have the TPA model, it does not overlay itself with the programs it executes. It uses a fork+exec model rather than a simple execl model. The same applies to the init daemon. It really should be called 'initd'. Like systemd it does stuff and hangs around. It is the parent of many processes and also, please read the documentation, adopts orphaned processes and cleans up after them. If you look up the old man pages for 'init' http://unixhelp.ed.ac.uk/CGI/man-cgi?init+8 you will see that it has an alias 'telinit'. The man page makes it very clear that this is a daemon an is responsible for spawning gettys. The real problem with systemd as far as size and complexity goes is that it has to deal with backward compatibility with the old way of doing things. We've been though this kind of thing before. When inetd replaced all the individual network listeners that too was considered revolutionary, but at least its control table was in a familiar format, the comma separated list in a single file. In due course that was replaced by xinetd and the single line was replaced by the mode capable 'stanzas', which were familiar to people who had used Smail3 as an alternative to sendmail. Those of us who used AIX found that IBM was very much in favour of stanzas over single lines as they were a lot clearer and allowed for embedded documentation. Back to http://lists.freedesktop.org/archives/systemd-devel/2014-September/023294.ht... <quote> 2. Clarity is better than cleverness. </quote> The same code for parsing stanzas was folded into grep so that the people who got in a later over not being able to grep the single lines were ameliorated. That systemd might fail is beside the point. Init could fail. If you look at the old man page http://www.lehman.cuny.edu/cgi-bin/man-cgi?init+1 you will see <quote> init Failure If init exits for any reason other than system shutdown, it will be restarted with process-ID 1. </quote> The same applies to systemd. If you were using UNIX V7 on a PDP-11 I might grant you that the original Bourne shell was a very small piece of code, but the reality is that the shell has grown and grown and grown. Most of it is now to do with user interaction at the command line rather than its capability as a programming language. That user interaction has led to the increased complexity of what was, back in the V7 days, as documented in Bell System Journal of 1978, a very simple and straight forward piece of code. If you want something to meaningfully rant about based on the arguments against systemd of this thread, they they would be more reasonably applied to what has happened to the shell. While I can defend the init => systemd evolution I don't think I can defend the Bourne Shell => Bash evolution in the same way. You might also read the man page for systemd. It does document the ways that a failure can start a shell at a terminal, which is more than you'd find on the old init man page! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org