On Fri, 18 Dec 2020 10:51:28 +0000, you wrote:
>Yes I know SysVInit has it's problems. But for most people it does the job just fine.
>And there are alternatives that deal with those problems without applying a scorched earth policy.
>And which are both simpler and proven.
>
>
>Stephen Worthington <stephen_agent@jsw.gen.nz> wrote:
>
>> When you had to write an init script, that was a mini-project on its own
>
>It doesn't have to be
>
>> getting it to do everything needed - it took ages. Using systemd to start a program is usually easy - just
>> add the options you want and it often works first time.
>
>Sorry, you lost me with "usually" and "often". That's not good enough.
>With an init script it will always work for the simple reason that you have complete control over what it does. What systemd has done is abstract a lot of what normally ends up in init scripts into it's internal code - meaning that if what they offer doesn't do exactly what you want, then it's "somewhat harder" to tweak things.
>Just to be clear what I'm pointing out here - systemd doesn't actually remove any of that complexity (especially when it comes to service startup sequencing), it tucks it away where you cannot get at it when that level of control is actually what you need.
You completely missed my point. When I said "usually" and "often" I
meant the that the very first time you try the .service file you have
just written, it works. That never happens with init scripts, except
when you get to copy an existing one. Init scripts are too complex.
And systemd does indeed reduce the complexity of service startup
sequencing - it does that by allowing you to specify the relationships
you want and let it do the actual sequencing. If I need some special
control, that is usually easy to do by writing a separate .service
file and having things start only after that .service has started
successfully.
Have you actually tried using systemd and had a situation where you
needed to do something that was simple in an init script and could not
be done in systemd? I certainly have not. The init scripts I have
worked on generally did only fairly standard things, and took a lot of
code to do it. Mode code generally equals more bugs, even if they are
just simple typos. If you are complaining that systemd is hiding
things because you have seen other people complain about that, then
please just try systemd for yourself and you will likely find that it
is not actually a problem.
>But apart from that, a major objection I have is the way it's being forced on people regardless - and hence needing whole new distributions (e.g. Devuan) in order to keep other choices available. The "we don't care if SysVInit works for you, we aren't going to support it - because systemd" mentality - backed up by a policy of changing stuff in such a way that makes life harder for devs who do want to keep that choice.
Yes, I can see your point about it being forced on people. But the
people making that choice to put it into the distros they control have
actually evaluated systemd and think it is better than what they had
before.
>And not to mention, the downright arrogance of a lead developer who has a clear policy of break whatever suits him, whenever it suits him, and leave others to work around whatever it is he's broken this week.
I am afraid I have not been following the politics of systemd, just
working with it in Ubuntu and a little Debian. I have not had any
instances of things being broken and my having to fix them after they
were previously working. I have had it the other way around where
things did not actually work as documented, so I had to do a
workaround, and then in a new version the problem was fixed. I once
had that happen where I found a problem one day and the next day when
I sat down to fix it, there was a new version of systemd out that had
just fixed it. I was scratching my head for a while about that, until
I remembered that I had seen new systemd packages installing.
>lastly, do you really want to trust your system, your PID1 which **WILL** bring down your whole system in a very messy way if/when it goes wrong, to coders with such good skills that Linus told at least one of them to "f-off and stop putting sh*t in the kernel" ?
Again, I can only say from my experience that I have not had PID 1
die. Systemd has been solid for me. I have never looked at the code
of systemd or any of the older PID 1 systems when I was running them.
I had no need to, they just worked. But until systemd, I always hated
having to do anything to do with getting a service working - it was
always trouble. With systemd, now that I have learnt enough about it,
I am quite happy to write or modify unit files. It does not take long
and then works nicely.
I am guessing that because my normal use of systemd is in Ubuntu and
the Ubuntu developers do quality assurance on their core packages, if
there were nasty new problems in new systemd updates, they never got
to me as Ubuntu never released that version, or patched it themselves.
>If I wanted a system where things changed "because we wanted to change them" for no good reason, where users are alpha testers for buggy code, where large parts of the system had been morphed into a hairball of interdependent code, where user input isn't welcome, well I'd be running Windows. But I don't, which is why I run Devuan (or pre-systemd Debian for those that still need major upgrades) on my servers.
That is fine, you can make your own choices. But I do think you
actually should really try a systemd based distro for a bit, before
making that choice. It really does work quite well. For me, init
scripts were just a bad experience. Systemd is, of course, completely
different to init scripts. Its philosophy is utterly different - it
is a paradigm shift from init scripts. And it does have a learning
curve. But once you get going, you do not want to ever go back to
init scripts.
Having your init script skills obsoleted is a bit of a pain, but that
is life. I did at one point early in my career have to write a couple
of COBOL programs for a mainframe. And some FORTRAN, for a mainframe
and a minicomputer. Then I wrote a lot of different sorts of
assembler for many years before C became available and viable for
embedded processors. I am very happy to have better programming
languages to work with than COBOL and FORTRAN. My considerable
assembler skills have not been used for quite a few years now, but
that is generally a good thing. I am much more productive writing C
and C++ for embedded processors. Systemd versus init scripts is much
the same thing. I can be tremendously more productive writing a
systemd unit in half an hour versus messing around all day getting an
init script working properly.
>
>Dan Ritter <dsr-myth@randomstring.org> wrote:
>
>> Except -- and this is actually really big -- using daemontools /
>> runit / supervisor / similar init systems are also much better
>> than both sysvinit and systemd. And all of those
>> daemontools-style systems offer smooth integration with the
>> PID=1 portion of sysvinit, and let you move over services one at
>> a time.
>>
>> The objection is not "systemd isn't better than sysvinit". The
>> objection is "systemd isn't enough better than sysvinit to put
>> up with the crap that goes along with it". And, also: "systemd
>> wants to take over everything, making things worse along the
>> way".
>
>Well that's a lot better put than mine.
Actually, I would have to say that systemd is so much better than init
scripts that for me it easily justifies having to live with the
journals hiding the logging away.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette MythTV Forums:
https://forum.mythtv.org