Anton Aylward wrote:
On 04/16/2014 04:45 AM, Dirk Gently wrote:
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.
There could be a perfectly good explanation why the design follows MS's serviced and why even the config files look like microsoft setup file (besides under the table payments). At the very least, linux is moving toward a locked-down appleian walled garden -- just as Windows is. Windows 8 *almost* required secureboot on any PC shipping windows. They did on everything BUT the PC platform. PC platform is in the near future. The idea is to be able to lock down people's PC's so corporations can sell you computer based services rather than sell you products. The economy is moving toward 'service based' rather than product based, because, as Adobe has found out, having to develop a product in order to get income is hard work. As PC's have become more complex, keeping programs working while releasing new features is becoming impossible. Many large companies are releasing SW as perpetual beta products while they see how they can sell related services. MS has been converting most of the business customers to contract support -- not sales of licenses. The newest version of office she has requires her computer be online in order to activate and requires running a full-time license and security daemon in the background. Stop the daemon (I mean stop, not disable), and office stops functioning. None of the components will start. The idea is to use the TPM to hold keys to verify the SW at boot time and maintain a trusted (by the corporations) software base. Users won't be able to run programs on their computers unless they are approved. They MIGHT be able to boot in an 'insecure' mode, but that will get old really fast.... basically think of the PC as becoming an expensive game and media playback console -- that you'll have to shell out for. Anton Aylward wrote:
On 04/15/2014 07:42 PM, Dirk Gently wrote:
Cristian Rodríguez wrote:
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.
Apache is a web server -- of course it wouldn't get out of the way. xinetd can apply controls to each TCP connection it manages. The problem comes in that there have always been some daemons/utilities that couldn't deal with that paradigm and need to do their own listening. Examples: apache -- does it relinquish it's ports to systemd? Samba, nfs, sendmail and many others. Cups *likely* doesn't need continuous connection to it's listening CPU port, but try that for samba or a busy webserver, and you are going to see performance degradation. Another problem with the monolith model -- in Win 7 MS moved all the large I/O's into their System(Daemon), where they cannot be monitored, limited or controlled. In fact, if you try to control regulate MS's systemd, by adjusting it's priority -- it will blue screen your system "for your protection" (what it says on the blue screen). Wonder how long it will be before the linux systemd does something similar. On a regular basis, MS's systemd will noticeably cause system performance problems -- and they justify it by having it linked into and controlling other needed services, leading to the next point:
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.
right -- are you saying systemd continue to sit in the middle and passes the traffic through itself? or does it spawn the child and hand off STDIN/OUT/ERR linked to the network socket and the child daemon then talks direct. If it is doing the latter, that's pretty much the way inetd and xinetd work. If it is going the former, that's an impending nightmare.
SystemD tries to *BE* every freaking service....
That is so clearly not so I can't understand why you are so asserting it.
Well, first there was "sysVinit", then "syslog", then went "udevd", then went "powerd"., um... now it's taking out "xinetd/inetd". Also, only last week there as an exchange of systemd proponents asking for samba to "toe-the-line", as it seems to do things systemd doesn't expect (yet another daemon is now 'bad and wrong' because of systemd?) A few months back there was a lively exchange between RedHat and Linus as they pressured him to accept their trusted code into the kernel so they can boot Redndoes. While linus told them to use existing means, they'll likely try again in other ways to get better control of the kernel under systemd. All of these actions bespeak of systemd being on an acquisition course. So if you can't understand why someone might assert that it's trying to become everything, you haven't been paying attention.
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.
Open and simple? Using text files for config rather than binary? Um... going for small pieces that do single things so other competing products can be dropped in to replace functionality (like mlocate being dropped in for locate -- as an example, or the hopping between boot loaders). If there is only 1 large systemd that does all of the funcions that previously had "competition", then we no longer have modularity or the ability to choose the better implementations. Monolithic tools have not been been considered good players in the unix environment. So what does systemd do? Does it stay in the middle for each byte, or does it hand over the connections 1 at a time? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org