Re: fdm, paredit and systemd

D <nospam@example.net> writes:

On Tue, 25 Feb 2025, Salvador Mirzo wrote:
>

Oh, that might even make my python script redundant! This gets more
interesting by the minute!

>
It will surely do.  (It is also a powerful filter, so you can organize
your NNTP articles into various different Maildir, essentially being
your NNTP client from the downloading perspective.  For uploading, we
will need another program.)

>
Excellent! I wonder if it can replace mbsync nicely as well? Would be nice to
have fdm handle both my mbsync (so sync imap folders to local laptop) _and_ to
take care of news posts! I can easily see how the filters would take care of
sorting the posts from various newsgroups into their respective folders in my
mail client.

I'm not a user of mbsync, but if you use mbsync just to download mail
from an IMAP server, then certainly fdm can replace it.

As for posting, my mail client, alpine, has that covered! =)

You should be good then. :)

Never heard of. It was a bit too quick, so I'm still not quite sure what it
does. Some of that jumping around can be achieved in vim, but since I'm not
familiar with lisp nor with exactly what he was doing, it is difficult
to say.

>
I'd bet vim can do the same.
>
It's not important.  But the illustration there is that Lisp programmers
don't worry about parentheses; it's all managed by them by editors such
as the GNU EMACS (with its various packages for handling these
specialized operations).

>
Yes, that makes a lot more sense. Manually typing all of those parentheses would
be horrible! ;) It reminds me of an old xkcd comic... there were your father
parenthesis, a more civilized weapon for a more civilized age. ;)

Lol.  I remember that one.

One thing I liked about systemd is that regular users can have their own
daemons.  But it turns out that's the only thing about systemd that I
ever liked.  And even then I changed my opinion.  Daemons are not really
meant to be managed by regular users; if there's any user that should
have the right to run a daemon, then they should have sysadmin powers,
even if specifically just for the task at hand.  Bottom line: it's a
neat thing that it does, but it might not quite be a real need.

>
I agree! That's the problem, it tries to be too neat, and to do too much. In the
end you have this horrible monolithic kludge that will probably crash due to its
complexity, and take the system with it.
>
Another thing I intensely dislike with it is the long and convoluted syntax of
the commands. I mean just look at "ls"... it's beautiful! And "l" followed by an
"s"! =D
>
Now look at this horrible mess: "systemctl list-timers" Yuck!

Yeah---there's a fine line between incrementing language and sticking
with the previous, well-established vocabulary.  That's particularly
important for hackers because they have an imense amount of vocabulary
to manage and great fluency is essential to their day-to-day operations.

It's alright.  As long as there are systems that don't buy the Microsoft
way of things, we're good.  And there will always be because hackers
never buy into the nonsense.

>
That's good! After all, if I don't want systemd, there are distributions without
it. =) The only annoying thing is that since I teach linux I am forced to teach
the most common tools, and sadly that means systemd.

No intention to question you here, but I'm sure you know how
questionable this might be.  I would think it's not really important to
teach about systemd, specially if you don't find it beautiful.  The
principles and their concrete illustrations are much more interesting.
The ``everything is a file'' is an example, and you can illustrate with
countless examples.  Modularity is another relevant word and can be seen
at its prime in UNIX systems (and extremely in software such as qmail),
with opposite examples in sendmail and also in systemd.

On the other hand, I'm thinking here that you'd remark that your courses
are highly practical, involved with system administration per se.  I'm
aware of that.  But, still, I really don't see system administration
very different from software writing.  I would not find it too important
to discuss the operational details of a specific system or software.
Certainly a UNIX system has its own particularties in their rc scripts,
but I would spend more time looking at POSIX-sh semantics, style,
philosophy and history because it's primarily sh scripts that engineer
the start-up schemes of UNIX systems.  Because then every hacker can use
that kind of culture to investigate whatever system he's interested in.

In other words, I'd go for depth, not immediate working knowledge.
Every system administrator will have to grind through the manuals
anyway.  Knowing how to start or stop daemons, say, in a particular
system would not be terribly useful in a classroom.  Of course, we would
see how run the commands in whatever system we're using for the
illustrations at the black board or at the computer lab, but merely to
see things in motion.