In article <v06t9m$fni$4@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/21/24 21:37, Dan Cross wrote:
>> Sendmail.cf was hardly typical of most Unix configuration files,
>
>I'll argue that sendmail.cf or sendmail.mc aren't as much configuration
>files as they are source code for a domain specific language used to
>impart configuration on the sendmail binary. In some ways it's closer
>to modifying a Makefile / header file for a program than a more typical
>configuration file.

That seems like a distinction with little difference. Most
configuration files are in some format that can be considered a
DSL.

Regardless, I wouldn't consider sendmail's config stuff anywhere
analogous to a Makefile or header; more like APL source code
perhaps.

>> You may have a point, but to suggest that anyone who objects to systemd
>> doesn't "have an argument" or is reactionarily change averse is going
>> too far. There are valid arguments against systemd, in particular.
>
>Agreed.
>
>> I'll concede that modern Unix systems (including Linux systems), that
>> work in terms of services, need a robust service management subsystem.
>
>For the sake of discussion, please explain why traditional SysV init
>scripts aren't a service management subsystem / facility / etc.

Among other things, there's no ongoing monitoring of the state
of a service. Init scripts start a program, and maybe know how
to stop it, but that's about it. If it faults? You're kind of
on your own. There's limited support for restarting things that
fail with `init` and `inittab`, but that's not really the same
thing.

>> If one takes a step back and thinks about what such a service
>> management framework actually has to do, a few things pop out: managing
>> the processes that implement the service, including possibly running
>> commands both before the "main" process starts and possibly after
>> it ends. It must manage dependencies between services; arguably it
>> should manage the resources assigned to services.
>
>I feel like the pre / post commands should not be part of the system
>management ${PICK_YOUR_TERM}. Instead there should be a command (script
>or binary) that can be called to start / stop / restart / etc. a service
>and that it is the responsibility of that command (...) to run the pre
>and / or post commands related to the actual primary program executable.
>
>I feel like the traditional SysV / /etc/init.d scripts did the pre and /
>or post commands fairly well.
>
>What the SysV init system didn't do is manage dependencies. Instead
>that dependency management was offloaded to the system administrator.

What, lexiographical sorting of filenames isn't good enough for
you or something? :-)

>> So this suggests that it should expose some way to express
>> inter-service dependencies, presumably with some sort of
>> human-maintainable representation; it must support some sort of
>> inter-service scheduling to satisfy those dependencies; and it
>> must work with the operating system to enforce resource management
>> constraints.
>
>I'm okay with that in spirit. But I'm not okay with what I've witnessed
>execution of this. I've seen a service restart, when a HUP would
>suffice, cause multiple other things stop and restart because of the
>dependency configuration.
>
>Yes, things like a web server and an email server probably really do
>need networking. But that doesn't mean that they need the primary
>Ethernet interface to be up/up. The loopback / localhost and other
>Ethernet interfaces are probably more than sufficient to keep the
>servers happy while I re-configure the primary Ethernet interface.

That's an implementation detail, suggesting that the system was
either insufficiently rich to capture that sort of dependency,
or improperly configured so as to be too strict.

>> But what else should it do? Does it necessarily need to handle
>> logging, or network interface management, or provide name or time
>> services? Probably not.
>
>I think almost certainly not. Or more specifically I think that -- what
>I colloquially call -- an init system should keep it's bits off name
>resolution and network interface management.
>
>> SMF didn't do all of that (it did sort of support logging, but not
>> the rest), and that was fine.
>
>The only bits of logging that I've seen in association with SMF was
>logging of SMF's processing of starting / stopping / etc. services. The
>rest of the logging was handled by the standard system logging daemon.

It depends on the service. Most only log that the service was
started/stopped, but some have more verbose logging. By default
a method's standard output and error are connected to the
per-instance log file. See svc.startd(8) for details.

>> And is it enough? I would argue not really, and this is really the
>> issue with the big monolithic approach that something like systemd
>> takes. What does it mean for each and every service to be "up"?
>> Is systemd able to express that sufficiently richly in all cases?
>> How does one express the sorts of probes that would be used to test,
>> anyway?
>
>I would argue that this is a status / ping operation that a venerable
>init script should provide and manage.
>
>If the system management framework wants to periodically call the init
>script to check the status of the process, fine. Let the service's init
>script manage what tests are done and how to do them. The service's
>init script almost certainly knows more about the service than a generic
>init / service lifecycle manager thing.

Delegation to some service-specific component seems like the
most general approach. Notably, this is something where systemd
doesn't do a great job.

>I feel like there are many layering violations in the pursuit of service
>lifecycle manager.
>
>Here's a thought, have a separate system that does monitoring / health
>checks of things and have it report it's findings and possibly try to
>restart the unhealthy service using the init / SMF / etc. system in the
>event that is necessary.
>
>Multiple sub-systems should work in concert with each other. No single
>subsystem should try to do multiple subsystems jobs.

An issue here is the implementation of Unix (which, given that
this is a VMS newsgroup, I do feel compelled to say may not be
the light and the way that some people think that it is). You
have things like process exit status reporting that works with
process hierarchies, but less so across those. E.g., you can't
`waitpid` for a process that isn't your own descendent. Which
in turn implies that for maintaining state of whether a thing
is running or not, a separate service presents other
complications. There have been some patches to do this in Linux
but it's not clear that they made it into the kernel, and they
are not portable regardless. One can play games with ptrace,
but it's all a bit hacky.

>> The counter that things like NTP can drag in big dependencies that
>> aren't needed (for something that's arguably table stakes, like
>> time) feels valid, but that's more of an indictment of the upstream
>> NTP projects, rather than justification for building it all into
>> a monolith.
>
>+10
>
>> Anyway. I can get behind the idea that modern service management
>> is essential for server operation. But it doesn't follow that the
>> expression of that concept in systemd is a great example of how to
>> do it.
>
>+1

- Dan C.

In article <v07268$hqd$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>>
>>I hear people say that systemd and smf are service management things and
>>that traditional SysV style init scripts aren't. But they never explain
>>why the former is and the latter isn't.
>
>The one thing that smf and systemd have is the ability to watch a process
>and restart it if it crashes. Many people find this very important, although
>personally I suspect that if your service is crashing a lot that you should
>fix it rather than rely on something else to restart it.

The thing is, when you're working at scale, managing services
across tens of thousands of machines, you quickly discover that
shit happens. Things sometimes crash randomly; often this is
due to a bug, but sometimes it's just because the OOM killer got
greedy due to the delayed effects of a poor scheduling decision,
or there was a dip on one of the voltage rails and a DIMM lost a
bit, or a job landed on a machine that's got some latent
hardware fault and it just happened to wiggle things in just the
right way so that a 1 turned into a 0 (or vice versa), or any
number of other things that may or may not have anything to do
with the service itself.

Again, at scale, this can happen thousands of times a day. You
can't reasonably track them all down. Often, the only thing you
can do is just restart the service and log it; eventually, some
poor SRE may notice a pattern in the failures and get it fixed.
Or not.

>Something else that they do provide is automated management of dependencies
>to start everything in order without the admin having to manually set the
>order of execution up. This can be a benefit and if done well can also speed
>boot times, but I am not sure that this is necessary to call a startup
>mechanism a service manager.
>
>>I was genuinely trying to learn something.
>
>This is not likely to be a thread in which anyone will learn much, I am sorry
>to say.

That's a shame.

- Dan C.

In article <v071bo$j0l$3@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/22/24 19:15, motk wrote:
>> I dunno, I'm not unintelligent but have you seen how much stress a
>> browser engine has to endure? Thousands of people with phds smash these
>> things to bits on the regular. Hundreds of thousands of people use
>> electron/react/whatever apps every day and never notice. Grousing about
>> this isn't a good look anymore.
>
>How much more productive work is done with a contemporary web browser in
>2024 than in 2004 or even in 1998 (save for encryption)?

Oh wow, many many orders of magnitude more. It's not even
close.

>How much more productive work are computers doing in general in 2024
>than in 1994?

Same. People who work on the technology itself often don't see
it because they're already immersed in it, but things have been
revolutionized since 1994. Compare GarageBand _now_ to top end
ProTools setups on ridiculously expensive SGIs back in the 90s.

>Have the frameworks and fancy things that are done in 2024 actually
>improved things?

Oh my goodness yes.

>I feel like there is massively disproportionately more computation power
>/ resources consumed for very questionable things with not much to show
>for it. Think what could have been done in the mid '90s with today's
>computing resources.
>
>As such, I believe that there is some room for grousing about many
>questionable practices today.

The glut of computing resources available today has undoubtedly
made programmers less aware of efficiency issues. But the sorts
of things we do today were science fiction 30 years ago.

- Dan C.

On Mon, 22 Apr 2024 18:53:26 -0500, Grant Taylor wrote:

> On 4/21/24 21:37, Dan Cross wrote:
>
>> I'll concede that modern Unix systems (including Linux systems), that
>> work in terms of services, need a robust service management subsystem.
>
> For the sake of discussion, please explain why traditional SysV init
> scripts aren't a service management subsystem / facility / etc.

You forgot the key word: “robust”.

> What the SysV init system didn't do is manage dependencies.

They also cannot manage service shutdown reliably. systemd can manage that
because it tracks the service processes by using “cgroups” to group them.

On 4/22/24 20:16, Scott Dorsey wrote:
> The one thing that smf and systemd have is the ability to watch a
> process and restart it if it crashes.

That's nothing new.

init has been watching processes and restarting them if they crash for
the 25 years that I've been messing with Linux.

Perhaps SysV / BSD init scripts didn't utilize that capability.

I did via /etc/inittab.

> Many people find this very important, although personally I suspect
> that if your service is crashing a lot that you should fix it rather
> than rely on something else to restart it.

Agreed.

> Something else that they do provide is automated management of
> dependencies to start everything in order without the admin having
> to manually set the order of execution up. This can be a benefit
> and if done well can also speed boot times, but I am not sure that
> this is necessary to call a startup mechanism a service manager.

:-)

I sort of suspect that people are wanting something to differentiate
systemd / SMF from predecessors and using a different name to indicate
different capabilities.

> This is not likely to be a thread in which anyone will learn much,
> I am sorry to say.

Maybe.

--
Grant. . . .

On Mon, 22 Apr 2024 22:11:28 -0500, Grant Taylor wrote:

> init has been watching processes and restarting them if they crash for
> the 25 years that I've been messing with Linux.

It still does.

Another thing that Linux adds is for some other process to nominate itself
as a “buck stops here” process. So if any of its indirect-descendant
processes get orphaned (due to termination of their immediate parent),
instead of the parent role going straight to PID 1, it goes to this
ancestor.

Remember, systemd isn’t just a service manager for systemwide services, it
also works for managing services in per-user desktop GUI sessions. And
yes, those can get quite complex these days.

On 23/4/24 10:56, Grant Taylor wrote:
> On 4/22/24 19:13, motk wrote:
>> Can the greybeards please stop sooking about it not being 1999 anymore
>> please. Once upon a time, knowing inscrutable regex and gluing stuff
>> together with sed and awk make you a sage superhero. Now people look
>> at you funny for gluing in tech debt, and they are right to do so.
>
> That's a non-answer.
>
> I was hoping to see a ${SERVICE_MANAGEMENT_THING} provides:
>
>  - this
>  - this
>  - that
>  - and this
>  - don't forget about that

Five seconds of googling would find you a systemd unit file, and I
actually pasted one into this thread. Five minutes of googling would
bring you to the systemd documentation which exhaustively describes this.

> I was genuinely trying to learn something.

Then perhaps be a little more open minded and do some inquiry of your
own as well.

--
motk

On 23/4/24 11:02, Grant Taylor wrote:

> As such, I believe that there is some room for grousing about many
> questionable practices today.

Of course, I do it all the time, and people shift away from me on the
hus. It doesn't help much.

--
motk

On Tue, 23 Apr 2024 15:07:32 +1000, motk wrote:

> Then perhaps be a little more open minded and do some inquiry of your
> own as well.

systemd-haters are like the anti-fluoridationists of the Open Source
world.

Discuss.

Just a quick thought on [all of this]

I didn't expect a quick question regarding termtypes and modern cli
systems to evolve into this, and I'm not happy about it. I certainly
wasn't expecting the vituperic resistance (apparently for its own sake)
of any attempt to interoperate with sofware and systems that people,
corporate and hobbyist alike, might actually use in 2024.

I like OpenVMS! I want to muck about with it and regain a lot of the
skillset I lost, and none of this is helping anybody! systemd exists and
is in use on millions and millions of systems worldwide. windows
terminal exists; serial connections, as handy as they are, are what you
bring up a router with and never use again. Combing our whiskers won't
make 1999 come back.

The vscode integration is commendable, but there's a lot of low-hanging
fruit remaining.

--
motk

On 23/4/24 15:18, Lawrence D'Oliveiro wrote:

> systemd-haters are like the anti-fluoridationists of the Open Source
> world.

Well, I think that's unfair, but you certainly do come across people
that performativly dislike systemd or wayland or windows or rust or
whatever in place of a personality. Meanwhile, the sails are
disappearing below the horizon and you're cursing in your dinghy.

--
motk

On Tue, 23 Apr 2024 16:57:40 +1000, motk wrote:

> On 23/4/24 15:18, Lawrence D'Oliveiro wrote:
>
>> systemd-haters are like the anti-fluoridationists of the Open Source
>> world.
>
> Well, I think that's unfair ...

Continually spouting the same old debunked nonsense, like you yourself
have been on the receiving end of? And don’t forget the conspiracy
theories, about how Red Hat is somehow strongarming the entire Linux
community into using this technology.

I wonder how the business model for that conspiracy is supposed to
work ...

On Mon, 22 Apr 2024 19:06:44 -0500, Grant Taylor wrote:

> On 4/22/24 19:05, Grant Taylor wrote:
>> I've found that X11 is one of the fatter remote GUI protocols.  RDP and
>> VNC tend to be lighter.
>>
>> But, RDP and VNC tend to imply a full desktop whereas X easily has
>> programs from different hosts display as windows on a single X server.
>>
>> There are some hacks to emulate this with RDP and VNC, but they are not
>> native and not reliable.
>
> I believe that X11 has something going for it that RDP and VNC can't
> touch. That's the ability to do X11 over protocols other than IP, e.g.
> DECnet. Something that some in this newsgroup may have an affinity for.
> }:-)

And over LAT as well :-)

Oswald

On 2024-04-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
> Eh, JSON has its own problems; since the representation of
> numbers is specified to be compatible with floats, it's possible
> to lose data by translating it through JSON (I've seen people
> put e.g. machine addresses in JSON and then be surprised when
> the low bits disappear: floating point representations are not
> exact over the range of 64-bit integers!).
>

I would consider that to be strictly a programmer error. That's the
kind of thing that should be stored as a string value unless you are
using a JSON library that preserves integer values unless decimal data
is present in the input data (and hence silently converts it to a float).

I don't expect people to write their own JSON library (although I hope
they can given how relatively simple JSON is to parse), but I do expect
them to know what values they can use in libraries in general without
experiencing data loss.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <v088m8$1juj9$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>> Eh, JSON has its own problems; since the representation of
>> numbers is specified to be compatible with floats, it's possible
>> to lose data by translating it through JSON (I've seen people
>> put e.g. machine addresses in JSON and then be surprised when
>> the low bits disappear: floating point representations are not
>> exact over the range of 64-bit integers!).
>
>I would consider that to be strictly a programmer error. That's the
>kind of thing that should be stored as a string value unless you are
>using a JSON library that preserves integer values unless decimal data
>is present in the input data (and hence silently converts it to a float).
>
>I don't expect people to write their own JSON library (although I hope
>they can given how relatively simple JSON is to parse), but I do expect
>them to know what values they can use in libraries in general without
>experiencing data loss.

In modern languages, one can often derive JSON serialization and
deserialization methods from the source data type, transparent
to the programmer. Those may decide to use the JSON numeric
type for numeric data; this has surprised a few people I know
(who are extraordinarily competent programmers). Sure, the fix
is generally easy (there's often a way to annotate a datum to
say "serialize this as a string"), but that doesn't mean that
even very senior people don't get caught out at times.

But the problem is even more insideous than that; popular tools
like `jq` can take properly serialized source data and silently
make lossy conversions. So you might have properly written,
value preserving libraries at both ends and still suffer loss
due to some intermediate tool.

JSON is dangerous. Caveat emptor.

- Dan C.

On 4/21/2024 6:45 PM, motk wrote:
> It's just cringe.
>

So is using "cringe" as a noun.

Hunter

On 2024-04-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>
> In modern languages, one can often derive JSON serialization and
> deserialization methods from the source data type, transparent
> to the programmer. Those may decide to use the JSON numeric
> type for numeric data; this has surprised a few people I know
> (who are extraordinarily competent programmers). Sure, the fix
> is generally easy (there's often a way to annotate a datum to
> say "serialize this as a string"), but that doesn't mean that
> even very senior people don't get caught out at times.
>
> But the problem is even more insideous than that; popular tools
> like `jq` can take properly serialized source data and silently
> make lossy conversions. So you might have properly written,
> value preserving libraries at both ends and still suffer loss
> due to some intermediate tool.
>
> JSON is dangerous. Caveat emptor.
>

JSON is fine. What _is_ dangerous are the incredibly arrogant people
who think they can design the above libraries in a way that silently
alter someone's data in that way.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <v08q86$1o3rh$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2024-04-23, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>>
>> In modern languages, one can often derive JSON serialization and
>> deserialization methods from the source data type, transparent
>> to the programmer. Those may decide to use the JSON numeric
>> type for numeric data; this has surprised a few people I know
>> (who are extraordinarily competent programmers). Sure, the fix
>> is generally easy (there's often a way to annotate a datum to
>> say "serialize this as a string"), but that doesn't mean that
>> even very senior people don't get caught out at times.
>>
>> But the problem is even more insideous than that; popular tools
>> like `jq` can take properly serialized source data and silently
>> make lossy conversions. So you might have properly written,
>> value preserving libraries at both ends and still suffer loss
>> due to some intermediate tool.
>>
>> JSON is dangerous. Caveat emptor.
>
>JSON is fine. What _is_ dangerous are the incredibly arrogant people
>who think they can design the above libraries in a way that silently
>alter someone's data in that way.

*shrug* The encoding doesn't say that you can't.

- Dan C.

On Tue, 23 Apr 2024 09:49:06 -0400, Hunter Goatley wrote:

> On 4/21/2024 6:45 PM, motk wrote:
>
>> It's just cringe.
>>
> So is using "cringe" as a noun.

<https://en.wiktionary.org/wiki/cringe>:

Noun

cringe (countable and uncountable, plural cringes)

(countable) A gesture or posture of cringing (recoiling or shrinking).

He glanced with a cringe at the mess on his desk.

(countable, figuratively) An act or disposition of servile obeisance.
(countable, British, dialectal) A crick (“painful muscular cramp or spasm of some part of the body”).
(uncountable, slang, derogatory) Things, particularly online content, which would cause an onlooker to cringe from secondhand embarrassment.

Bro... you just posted cringe
There was so much cringe in that episode!

Also available as an adjective.

On 23/4/24 23:49, Hunter Goatley wrote:
> On 4/21/2024 6:45 PM, motk wrote:
>> It's just cringe.
>>
>
> So is using "cringe" as a noun.

I shall never recover from this burn.

> Hunter

--
motk

On Wed, 24 Apr 2024 09:11:55 +1000, motk wrote:

> I shall never recover from this burn.

Heh, you used “burn” as a noun, too. ;)

On 24/4/24 10:23, Lawrence D'Oliveiro wrote:

> Heh, you used “burn” as a noun, too. ;)

It's what all the cool kids do now, verbing nouns and nounifying verbs.

--
motk

On Wed, 24 Apr 2024 10:47:25 +1000, motk wrote:

> On 24/4/24 10:23, Lawrence D'Oliveiro wrote:
>
>> Heh, you used “burn” as a noun, too. ;)
>
> It's what all the cool kids do now, verbing nouns and nounifying verbs.

It’s a tradition in the English language going back centuries. Back to
Shakespeare even, I believe.

Makes you wonder how old these geezers are, that are objecting to it ...

On 4/23/2024 5:50 PM, Lawrence D'Oliveiro wrote:
> On Tue, 23 Apr 2024 09:49:06 -0400, Hunter Goatley wrote:
>
>> On 4/21/2024 6:45 PM, motk wrote:
>>
>>> It's just cringe.
>>>
>> So is using "cringe" as a noun.
>
> <https://en.wiktionary.org/wiki/cringe>:

Not the source I would refer to. While it has recently been used in
slang as a noun, it's still only a verb or an adjective to me. And I'm
sure someone will tell me it's an example of English being a living
language that's growing, etc. Whatever. I'm old, and I cringe at people
using it as a noun.

Hunter

On 24/4/24 11:50, Hunter Goatley wrote:

> Not the source I would refer to. While it has recently been used in
> slang as a noun, it's still only a verb or an adjective to me. And I'm
> sure someone will tell me it's an example of English being a living
> language that's growing, etc. Whatever. I'm old, and I cringe at people
> using it as a noun.

That's so cringe.

[I'm only the downhill run to 60]
> Hunter

--
motk