Anton Aylward wrote:
On 04/16/2014 04:45 AM, Dirk Gently wrote:
Anton Aylward wrote:
On 04/15/2014 07:42 PM, Dirk Gently wrote:
Cristian Rodríguez wrote:
El 08/10/13 23:49, Dirk Gently escribió:
SystemD relinquishes the cupsd port because now cupsd is listening.
nope, it is doing exactly what it should, as designed and intented. otherwise it could not monitor, stop, perform any kind of operation if the socket fails.. or provide any kind of support for ordering other components after the socket goes down/up etc..
If that's the case, then SystemD is violating FUNDAMENTAL Unix design principles.
Please explain that assertion.
Please tale into account how things like inetd and xinetd work. Or, for that matter, how apache works.
inet and xinet listen to a port, and when traffic comes in, start up the corresponding service, and hand-off the traffic to that service.
SystemD tries to *BE* every freaking service....
That is so clearly not so I can't understand why you are so asserting it.
Like XinetD, systemd has single control files that say what service is to be dispatched and and associated with that port, monitors the service for when it exits. The 'out of the box' set of services for XinetD are straight forward in that they don't have pre- or post-conditional actions, but I've seen some specialized, custom uses of XinetD which, for example, ensure services are always available, restarting them when they die or time-out.
Everything that systemd does requires a descriptor, a control file, a
Extremely poorly documented. I've used Unix since 1983 and administrated it since 1993... and I don't know a single person who can make heads or tails of how to SysV init was simple --- it forks off scripts. So simple, in fact, that if init were to fail, you could actually replicate what init does BY HAND with a simple For F in /etc/init.d/rc5.d/K* do $F stop done For F in /etc/init.d/rc3.d/S* do $F start done or whatever. and, of course, run a few commands found in /etc/inittab What SystemD actually DOES and how it does it... I haven't the foggiest fucking clue, and that's not for a lack of reading of the documentation. If you can't even understand how your system boots up, then you don't really have control of your system in the slightest.
'unit' file [systemd.unit(5)], though they are more sophisticated than those of XinetD. You don't see many of the unit files because, as the documentation says, they are generated automatically by axillary programs which, for example, read /etc/fstab and produce a unit file for each entry. Such generators are documented and there's no reason you can't write your own, custom ones, as well as your own basic unit files. I've done the latter.
To assert that system tries to be the service is demonstrably false: the example of cusp makes that quite clear. Systemd starts cups, it isn't cups.
To assert that this "isn't the UNIX way" is also demonstrably false. Table driven controls have a long history in UNIX What makes UNIX/Linux different from other operating systems is that those table are text files and can be changed with a text editor.
SysV is simple enough that it could be implemented in a short shellscript, and most of all, it's OBVIOUS what it does, and HOW it does it. Not so for SystemD. And worst of all, it has ill-defined, and constantly moving boundaries. Least of all, when people try to ask the SystemD team simple questions, such as "what is SystemD supposed to do and how is it supposed to do it," rather than just answering the damned question, there's all sorts of handwaving and other gyrations, RTFM, and "you're too stupid to understand" When people act like that -- it indicates to me that they're either trying to hide something... or... they're trying to hide something.
As for the scanning and transformation, that too has precedence in UNIX from before the days of Linux. The original 'termcap' files were text based but later were scanned and transformed to a binary format - 'terminfo'. We see similar scanning and transformation for language files and for timezone. The only thing that makes systemd different here is that it invokes the auxiliary programs itself on demand rather than relies on the sysadmin to do so from the command line.
Unix philosophy -- each program does one thing, and does that one thing VERY WELL.
Yes, and systemd meets that in the same way that other pre- and post Linux utilities do.
If you want to complain about things that violate Pike's Dictum then I suggest you look elsewhere. Certainly modern GUI based tools such as email handlers and web browsers violate that precept.
I might even go so far as to say that compared to the original Bourne Shell the Korn Shell and the shell we have today grossly violate that rule, but I don't see you complaining about them!
In contrast, SystemD tries to do EVERYTHING, and does NONE of it well -- which is straight out of the Microsoft/Windows way of doing things.
You assert that although its patently false. Systemd is a dispatcher. Just as XinetD also has internal functions (for example logging, rate limiting, killing and restarting services) so too does systemd.
You quote the example of cups. The old man page for CUPS (available via googling) says quite explicitly
<quote> cups-lpd does not act as a standalone network daemon but instead operates using the Internet "super-server" inetd(8) or xinetd(8) </quote>
It goes on to give the xinetd "unit" descriptor needed.
Although the details differ when we look at how systemd handles cups, the basics are the same: systemd is a dispatcher; there is a control file that specifies the 'what', the program and the parameters.
Systemd dispatches and monitors cups. It doesn't try to do what cups does. Your assertions are unfounded and demonstrably false.
If systemd had any failing it was that, as has been the UNIX/Linux tradition, it was released before it was complete and fully functional. The Open Source movement, as we see with the Heartbleed/SSL problem, is not as funded as the commercial operations and cannot complete development and testing in house to ensure that when a product is released it is as polished as we see from the likes of HP and IBM. (Yes you are right to criticise Microsoft, they do seem to do their beta testing on the public.)
Yes, compared to XinetD, systemd is very sophisticated. My point here is to show that systemd is not the violation of any basic UNIX principles but an evolution of them. If you want to be reductionist, then all of networking, all of job control, all of virtual memory, all of the journalled file systems are a violation of the KISS principles of UNIX V6/V7 as embodied on the 9-track takes that came with the "Love, Dennis" note.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org