[mdlug] Systemd and all of it's nonsensical BS

[Aaron Kulkis]

Adam Tauno Williams wrote:
> On Mon, 2015-02-23 at 11:27 -0500, Aaron Kulkis wrote:
>> Jay Nugent wrote:
>>> Greetings Aaron (et al),
>>> On Sun, 22 Feb 2015, Aaron Kulkis wrote:
>>>> SysV Init has problems but systemd seems to cause more problems than what it fixes.
>
> Such as?  You have yet to enumerate these serious desperate problems.

I only posted several LISTS of problems, because my mind, unfortunately,
isn't sharp enough to remember all of the myriad problems with systemd.

> Because I have systemd systems... and they are working just fine.
>

Adam, have you ever tried to reconfigure a system with systemd?

Have you tried changing any of the config files?

>>> Agreed.  While teaching Unix/Linux SysAdmin at Washtenaw Community College it
>>> was EASY to teach SysVinit because it made sense.
>
> Or it was easy because you are extremely familiar with it.  Or was easy

Why would that make a difference to his students?
They are equally unfamiliar with SysV init and systemd.

> because SysV is simply a dumb pile of shell scripts incapable of dealing

A dump pile of shell scripts which call ALL of the appropriate administrative
commands to configure whatever needs configuring.  If the dumb pile of
shell scripts can't configure something, then that means that the sorts
of commands that are in section (8) of the man pages are missing some
critical commands.

In which case, the FIRST impulse should be to build more admin programs,
not replace the init system with something that looks like the demon
spawn of MS Windows and that other over-complicated abortion, MULTICS,
all in the most unweildly of all config style structures -- the stanza
format used on IBM mainframes.

[Ever administrate an AIX machine from the days when it was basically
SysV, but with IBM mainframe config files... NO administrative reconfig
tools (as in, use sed & awk to rewrite a config file in /etc) are portable
between standard AIX and any other platform.

Systemd creates the same problem... in addition to the MANY others
which I posted.

> with a myriad of complex issues.
>

The only thing SysV init didn't do properly for me was automount usb devices
when I put them in.

I can understand the argument that SysV init has other issues.

However, the idea that "a myriad of complex issues" needs to be solved
be A SINGLE EXECUTABLE which now does the job of mount, xinited, syslog

>>> I would then introduce systemd and the stoodies would react like, WTF!!!!????
>
> Right... you didn't convey any bias or attitude to your students?  Why
> do I find that hard to believe.
>
> And I don't believe for a hot second students were naturally enamored of
> SysVinit.  Nobody, and I mean nobody, expressed love and admiration for
> SysVinit until asked to learn an alternative, which they didn't want to
> do.

SysV init is clever in that it is simple -- have something you want
to configure? write the appropriate commands in a shell script.

Not working right?  Edit the shell script.

If you're administrating machines, and can't do shell scripting, then
you shouldn't be an admin in the first place.

EVERYTHING in a shell script called by sysV init is easily looked up
and understood by simply using   man /command-goes-here/ and seeing
what the flags and arguments do.

Such pages are usually 200 - 1000 lines. Very manageable to read.

Not only that, but these files frequently have comments call over
the place ... and if you want more comments you can put them in.


Try putting comments into systemd config files.
Doing so invites additional problems




>
>>> They then fully understood why I refered to these programmers as
>>> "Snot-nosed, Pimply-faced kids" - who were changing things not for the
>
> I think you may be deceived by what in my day we called "Brown Nosing".
> Aka, telling the teacher what you know he/she wants to hear.  Got me
> easily through many a college class.

I don't know about Jay, but I used to tutor kids fresh off the farms
from Indiana, whose only prior experience with a computer was seeing
the typical Hollywood misrepresentations in movies ("Difficult problem
makes the computer spin the tape drives until they catch on fire and
then the computer literally EXPLODES in a huge fireball that destroys
the entire room, leaves everyone with soot on their face and coughing")

>
>>> better, but just because they *could* and they had the POWER.
>
> Yes, the euphoric power trip of writing code.  No high like that one...
> and init code at that!  Wow!  The rush!

Your arrogance and deliberate non-understanding here is just becoming tedious.

>
>>> Early in the classes we taught the basis of Unix being, "do just one thing,
>>> but do it really really really really really really really really
>
> Pure urban legend.  I have been an UNIX admin for 25 years.  I've used

Strange.  I can show you documents from both AT&T and Berkeley which
say, verbatim

"The unix philosophy is:
* Do just one thing, but do it realy well.
* input and output should be character streams because that is the universal interface


> LINUX since kernel 0.99a.  That adage was never anything more than an
> ideal.  Take a look at the IOCTL call - how to do EVERYTHING and NOTHING
> well.  Right up there with "everything is a file"... except, no, it
> isn't.
>
>>> To the stoodies, it appeared that systemd was "hiding" something
>>> under the covers.
>
> Such as?  man journalctl
>
> Oh, and you can setup the logging any way you like.

And tell us, how do we get plaintext journals without running
an ADDITIONAL process because the systemd logger quite rudely
refuses to log in anything but binary data.

Hmmm, what happens if a block in your system log gets overwritten
due to either a bug, or a malicious attack -- with that binary,
with non-fixed-length records, how do you read ANY of the log
after the tampered-with block?

Answer -- you can't.


>
>>> Which led to NSA discussions and conspiracies.
>
> Yawn.
>
> BTW, it is trivial for them to diddle your text /var/log/messages -
> you'll never know.  Not so easy with cryptographically signed logs.  But
> clearly you know that.

Unlike you, I actually work in and around such agencies, and there's more credibility
to such than what you allow.



>
>>> It appeared that if systemd was 'supposed' to improve boot-up times,
>>> they had clearly overleached their goal by messing with logging, etc.
>
> Perhaps they messed with logging because logging in traditional UNIX
> *S*U*C*K*S. I don't know, just maybe.
>
> If you only option to search for data is "grep", then the solution
> sucks.
>
> How did you log structured, non-text, or even multi-line data without a
> journal?  Oh, you couldn't.  How did you cryptographically validate the
> integriy of a log?  Oh, you couldn't.  How did you secure and
> authenticate logging across a network?  Ah, yes, a bunch of rigged up
> hacks.  So, yes, I see the regression.... not.
>
>>> And some stoodies even thought that maybe some out-of-work
>>> programmers from Microsoft decided to try their hand at Linux, and
>>> managed to convert it to run more like Microsoft code than we had
>>> ever seen before.
>
> Yawn.

Your arrogance doesn't win you any friends, nor convince anybody that
you're anything other than an example of

>
>>> I am ready to go back to FreeBSD for my servers.
>
> Then do that, enjoy.
>
>>> Linux has drifted away from its origins and thus has lost my support.
>
> Ok.
>

And if that makes you happy, there's something seriously wrong with you.