On Sat, 20 Apr 2024 20:46:54 -0400, Arne Vajhøj wrote:

But my impression is that [systemd] missed on the main criteria: keeping things simple.

But it does. Service definitions (and “unit” definitions in general) are written in config files following the classic text-based .INI format. If
you remember, Microsoft created this format back in the 1980s for Windows config files, then abandoned it in favour of that horror known as the
Registry. Well, it lives on in the open-source world.

A service file consists of a series of directives, each of which is there
for a purpose. Compare creating sysvinit scripts (I have done both), where
you end up copying and pasting a whole lot of boilerplate from some
existing script into the new one, maybe not really understanding why it’s needed.

To illustrate the point and somewhat move back to VMS let me confess something: I really like SYS$MANAGER:SYSTARTUP_VMS.COM to manage what
get started on VMS.

That’s the equivalent of the old /etc/rc.local, that some distros (and I think also BSDs) still support. OK for a small handful of services, but it doesn’t scale.

A simple text file that after a little cleanup typical will be only
20-50 lines. Easy to understand. Easy to edit.

Not so easy to selectively add/remove, enable/disable or start/stop
individual services.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/20/2024 10:04 PM, Lawrence D'Oliveiro wrote:

On Sat, 20 Apr 2024 20:46:54 -0400, Arne Vajhøj wrote:

To illustrate the point and somewhat move back to VMS let me confess
something: I really like SYS$MANAGER:SYSTARTUP_VMS.COM to manage what
get started on VMS.

That’s the equivalent of the old /etc/rc.local, that some distros (and I think also BSDs) still support. OK for a small handful of services, but it doesn’t scale.

It does not scale.

But it should not need to scale.

You should not run that many services on a single system.

A simple text file that after a little cleanup typical will be only
20-50 lines. Easy to understand. Easy to edit.

Not so easy to selectively add/remove, enable/disable or start/stop individual services.

add/enable : put $ @sys$startup:something$startup in that file
remove/disable : change to $! @...
start : @sys$startup:something$startup
stop : @sys$startup:something$shutdown

Simple!

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 20 Apr 2024 22:26:00 -0400, Arne Vajhøj wrote:

You should not run that many services on a single system.

I call that a “Windows Server” mentality. I think it has to do with proprietary apps, each one assuming it owns the system. So if you try
running more than one, and they interfere, the vendors will simply point
the finger at each other.

It has been traditional, going back decades, for *nix servers to be multi- role.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On So 21 Apr 2024 at 02:04, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 20 Apr 2024 20:46:54 -0400, Arne Vajhøj wrote:

But my impression is that [systemd] missed on the main criteria: keeping
things simple.

But it does. Service definitions (and “unit” definitions in general) are written in config files following the classic text-based .INI format. If
you remember, Microsoft created this format back in the 1980s for Windows config files, then abandoned it in favour of that horror known as the Registry. Well, it lives on in the open-source world.

But .INI format is not a classic unix file format and not as easy to
parse as the real, classic unix file formats. I think of it as an
abomination.

To illustrate the point and somewhat move back to VMS let me confess
something: I really like SYS$MANAGER:SYSTARTUP_VMS.COM to manage what
get started on VMS.

That’s the equivalent of the old /etc/rc.local, that some distros (and I think also BSDs) still support. OK for a small handful of services, but it doesn’t scale.

A simple text file that after a little cleanup typical will be only
20-50 lines. Easy to understand. Easy to edit.

Not so easy to selectively add/remove, enable/disable or start/stop individual services.

In fact it is easy to do all that if you know how to edit text filesm
either by hand or with tools like awk or sed.

'Andreas
--
ceterum censeo redmondinem esse delendam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 21 Apr 2024 11:41:06 +0200, Andreas Eder wrote:

But .INI format is not a classic unix file format and not as easy to
parse as the real, classic unix file formats. I think of it as an abomination.

It’s very easy to deal with, and very popular among open-source
developers. It’s so popular, there’s even a module in the standard Python library for parsing it. That’s why systemd adopted it.

I think it is Windows programmers who were conditioned to hate it, by
Microsoft marketing.

Not so easy to selectively add/remove, enable/disable or start/stop
individual services.

In fact it is easy to do all that if you know how to edit text filesm
either by hand or with tools like awk or sed.

Not really the best idea, when you can separate out the definitions into individual files. Less chance of accidentally altering something you
didn’t mean to.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/21/2024 7:06 PM, Lawrence D'Oliveiro wrote:

On Sun, 21 Apr 2024 11:41:06 +0200, Andreas Eder wrote:

But .INI format is not a classic unix file format and not as easy to
parse as the real, classic unix file formats. I think of it as an
abomination.

It’s very easy to deal with, and very popular among open-source
developers. It’s so popular, there’s even a module in the standard Python library for parsing it. That’s why systemd adopted it.

People may have different opinions on what is "very popular".

The 3 most widely formats for config files today are XML, JSON
and YAML.

But INI and Java properties may be the next 2 in usage.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2024 7:41 pm, Andreas Eder wrote:

But .INI format is not a classic unix file format and not as easy to
parse as the real, classic unix file formats. I think of it as an abomination.

What? Like sendmail.cf? What are these classic unix file formats? The
weird not-quite-xml of apache.conf? The weird globbing in crontab? Using ALLCAPS=something in some file in sysconfig?

It's good to know where we came from but imagining a perfect past isn't
a good idea.

In fact it is easy to do all that if you know how to edit text filesm
either by hand or with tools like awk or sed.

You have a problem with config over a fleet of files; you edit it with
regex. Now you have many problems.

'Andreas

--
motk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 22 Apr 2024 09:26:50 +1000, motk wrote:

Those are entirely optional, but very handy for embedded/cloud image/iot stuff, where you don't want to pull in an entire distros worth of stuff.

Just an example of the many modular parts of systemd:

I encountered systemd-networkd for the first time the other day, while
setting up a BigBlueButton server for a customer. The install script
recommends you start with a fresh Ubuntu Server install. But there
seems to be something buggy about the Ubuntu Server installer: I kept
trying to put in manual parameters for a network interface (address,
router, DNS), but they wouldn’t stick.

Finally I gave up on manual network configuration, and left it to
default to DHCP for the installation, figuring I’d fix it up later.

So I went in afterwards, looking for the traditional Debian /etc/network/interfaces file, only to discover it didn’t exist.
Instead, you created .network files, one for each interface. So I read
the man page on how to do that. I discovered the autogenerated one in /run/systemd/network that was using DHCP, and the docs said that if I
created a file with the same name in /etc/systemd/network, it would
override the former.

So I did, and it worked.

Another nice thing I found is, I could manually try different
temporary network settings without updating those config files, and it
would leave my fiddling alone. In order to (re)apply the configuration
settings and wipe out my temporary changes, I had to explicitly say “systemctl restart systemd-networkd.service”. Compare this with NetworkManager, where if you try manually fiddling things, it will at
some point automatically, and unpredictably, decide to override your
changes with its configured settings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/2024 6:33 PM, Lawrence D'Oliveiro wrote:

On Sun, 21 Apr 2024 19:18:19 -0400, Arne Vajhøj wrote:

The 3 most widely formats for config files today are XML, JSON and YAML.

No, those are mainly used for data interchange, not so much for config
files (apart from XML).

JSON is used for data exchange, but also for config.

Examples:
* .NET Core/5+ and its app config replacement
* PHP composer and its composer.json

YAML is the preferred config file format in the container/devops world.

But INI and Java properties may be the next 2 in usage.

“Java properties” isn’t a file format.

Of course it is.

foobar.ini with:

[a]
a1 = 123
a2 = ABC
[b]
b1 = 456
b2 = DEF

can be done as foobar.properties:

a.a1 = 123
a.a2 = ABC
b.b1 = 456
b.b2 = DEF

There is also TOML.

Ah. I forgot about that one.

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 21 Apr 2024 19:18:19 -0400, Arne Vajhøj wrote:

The 3 most widely formats for config files today are XML, JSON and YAML.

No, those are mainly used for data interchange, not so much for config
files (apart from XML).

But INI and Java properties may be the next 2 in usage.

“Java properties” isn’t a file format.

There is also TOML.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sun, 21 Apr 2024 19:18:19 -0400, Arne Vajhøj wrote:

The 3 most widely formats for config files today are XML, JSON and YAML.

No, those are mainly used for data interchange, not so much for config
files (apart from XML).

JSON and YAML are incredibly common for config files for newer software.
I've not really seen YAML used as a data interchange format, in my
experience it exists almost entirely to be a more human-friendly
alternative to JSON for configuration.

But INI and Java properties may be the next 2 in usage.

“Java properties” isn’t a file format.

https://en.wikipedia.org/wiki/.properties

https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)

The Java properties file format is well-defined and, not surprisingly,
used heavily by Java applications. I've been out of the Java world for a
while, but in the 2000s, properties files were definitely in use for configuration files for many applications I ran and worked on.

-Matthew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/2024 11:03 PM, Matthew R. Wilson wrote:

On 2024-04-25, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sun, 21 Apr 2024 19:18:19 -0400, Arne Vajhøj wrote:

The 3 most widely formats for config files today are XML, JSON and YAML.

No, those are mainly used for data interchange, not so much for config
files (apart from XML).

JSON and YAML are incredibly common for config files for newer software.
I've not really seen YAML used as a data interchange format, in my
experience it exists almost entirely to be a more human-friendly
alternative to JSON for configuration.

Yep.

Some like it. Some don't like it. But a huge part of new stuff use
YAML for config.

But INI and Java properties may be the next 2 in usage.

“Java properties” isn’t a file format.

https://en.wikipedia.org/wiki/.properties

https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)

The Java properties file format is well-defined and, not surprisingly,
used heavily by Java applications. I've been out of the Java world for a while, but in the 2000s, properties files were definitely in use for configuration files for many applications I ran and worked on.

It is still used.

Java added the preferences API back in 1.4 (2002), but few
likes that - too complex, too weird.

So most use either a properties file or a XML file (and with
class binding XML file requires very little code).

Arne

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)