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(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org