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 '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. 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.
-- helicopter (n): 30,000 parts in tight orbit around a hydraulic fluid leak, waiting for metal fatigue to set in. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org