In article <v0fbd5$3g795$1@dont-email.me>, ldo@nz.invalid says...
>
> On Fri, 26 Apr 2024 16:36:41 +1200, David Goodwin wrote:
>
> > Why go to all the effort reimplementing the whole
> > Linux syscall interface and keeping it up-to-date when you could just
> > run the Linux kernel in a VM.
>
> Because that was what the whole ?personality? system was supposed to be
> for. In practice, it didn?t work.

Calling it a personality system perhaps makes it sound more complex than
it really is.

The NT kernel speaks its own low-level Native API. The Kernel doesn't
know or care about Win32 or POSIX or any of that stuff. Thats all the
responsibility of a collection of subsystems running in usermode.

Its not a microkernel like Minix, but its also not quite a monolithic
kernel like Linux.

> > Are you trying to argue that moving code out of the kernel into
> > userspace is a bad idea?
>
> It would have been great if they could have implemented the Linux API that
> way, wouldn?t it? But they couldn?t do it.

They could and they did. WSLv1 exists and it does work surprisingly
well. WSLv2 works better though, and it is no doubt far easier to
maintain.

Still not sure what your'e arguing here though. Are you suggesting
Windows NT should have used a monolithic kernel for some reason? Or that
a flexible design was a bad idea because it didn't work out perfectly in
one scenario over 30 years later?

On Fri, 26 Apr 2024 17:05:21 +1200, David Goodwin wrote:

> WSLv1 exists and it does work surprisingly well.

But never quite good enough. And it is now abandoned.

> WSLv2 works better though, and it is no doubt far easier to
> maintain.
>
> Still not sure what your'e arguing here though. Are you suggesting
> Windows NT should have used a monolithic kernel for some reason?

You tell me: are two monolithic kernels better than one?

> Or that a flexible design was a bad idea because it didn't work out
> perfectly in one scenario over 30 years later?

In the one scenario where it could have achieved something genuinely
useful, implementing an API which is amply documented and even comes with
a full open-source reference implementation, it completely failed to
deliver the goods.

In article <v0fel2$3grqf$1@dont-email.me>, ldo@nz.invalid says...
>
> On Fri, 26 Apr 2024 17:05:21 +1200, David Goodwin wrote:
>
> > WSLv1 exists and it does work surprisingly well.
>
> But never quite good enough. And it is now abandoned.

Its still there and still works. And importantly its still supported.

> > WSLv2 works better though, and it is no doubt far easier to
> > maintain.
> >
> > Still not sure what your'e arguing here though. Are you suggesting
> > Windows NT should have used a monolithic kernel for some reason?
>
> You tell me: are two monolithic kernels better than one?

NT isn't generally considered to have a monolithic kernel.

> > Or that a flexible design was a bad idea because it didn't work out
> > perfectly in one scenario over 30 years later?
>
> In the one scenario where it could have achieved something genuinely
> useful, implementing an API which is amply documented and even comes with
> a full open-source reference implementation, it completely failed to
> deliver the goods.

I take it you are not aware of the operating systems origin then.

Windows NT started life as a next-generation portable high-end 32-bit
OS/2 implementation known as NT-OS/2. It wasn't until the breakdown of
the joint development agreement with IBM at the end of 1990 that it
pivoted to being a next-generation Windows. A year later at Comdex 1991
they were handing out a preview release of Windows NT with its new Win32
personality firmly in place.

If converting the entire userspace personality from one OS to another in
a year without any significant architectural changes doesn't validate
the design I don't know what would.

I'm also not sure why you think WSL is a failure. Have you not used it?

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

On 4/26/2024 12:43 AM, Lawrence D'Oliveiro wrote:
> On Fri, 26 Apr 2024 16:36:41 +1200, David Goodwin wrote:
>> Why go to all the effort reimplementing the whole
>> Linux syscall interface and keeping it up-to-date when you could just
>> run the Linux kernel in a VM.
>
> Because that was what the whole “personality” system was supposed to be
> for. In practice, it didn’t work.

When the subsystem concept was invented virtualization technology
was not where it is today.

No matter how one would rate the subsystem, then a VM requires
less code and provide better compatibility than a subsystem.

But NT 3.1 did not have Hyper-V. :-)

Arne

On 4/26/2024 3:53 AM, David Goodwin wrote:
> I'm also not sure why you think WSL is a failure. Have you not used it?

I strongly suspect that he has not.

:-)

WSL is used and it works.

One of the more public use cases are DHH:

https://world.hey.com/dhh/vscode-wsl-makes-windows-awesome-for-web-development-9bc4d528

https://world.hey.com/dhh/committing-to-windows-2d6388fd

Arne

On 2024-04-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> When the subsystem concept was invented virtualization technology
> was not where it is today.
>

Are you sure ?

https://en.wikipedia.org/wiki/VM_(operating_system)

Simon.

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

On 4/26/2024 1:25 PM, Simon Clubley wrote:
> On 2024-04-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> When the subsystem concept was invented virtualization technology
>> was not where it is today.
>
> Are you sure ?
>
> https://en.wikipedia.org/wiki/VM_(operating_system)

Yes - IBM mainframe was actually quite far way back.

Let me rephrase: virtualization technology was not where it is today
on the platforms NT was running on.

Arne

On Fri, 26 Apr 2024 08:34:01 -0400, Arne Vajhøj wrote:

> On 4/26/2024 12:43 AM, Lawrence D'Oliveiro wrote:
>>
>> On Fri, 26 Apr 2024 16:36:41 +1200, David Goodwin wrote:
>>>
>>> Why go to all the effort reimplementing the whole Linux syscall
>>> interface and keeping it up-to-date when you could just run the Linux
>>> kernel in a VM.
>>
>> Because that was what the whole “personality” system was supposed to be
>> for. In practice, it didn’t work.
>
> When the subsystem concept was invented virtualization technology was
> not where it is today.

Excuses, excuses. Why did Microsoft waste their time trying to create
WSL1, then?

On Fri, 26 Apr 2024 19:53:31 +1200, David Goodwin wrote:

> In article <v0fel2$3grqf$1@dont-email.me>, ldo@nz.invalid says...
>>
>> On Fri, 26 Apr 2024 17:05:21 +1200, David Goodwin wrote:
>>
>> > WSLv1 exists and it does work surprisingly well.
>>
>> But never quite good enough. And it is now abandoned.
>
> Its still there and still works. And importantly its still supported.

You know how they like to use marketing-speak to avoid coming out and
saying something is EOL?

From
<https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-in-the-microsoft-store-is-now-generally-available-on-windows-10-and-11/>:

Additionally, the in-Windows version of WSL will still receive
critical bug fixes, but the Store version of WSL is where new
features and functionality will be added.

So it’s quite clear: no more “new features and functionality”. And
when was the last time you saw a “critical bug fix” for WSL1, by the
way?

>> You tell me: are two monolithic kernels better than one?
>
> NT isn't generally considered to have a monolithic kernel.

It has the GUI inextricably entwined into it. It doesn’t have a
virtual filesystem layer--most filesystem features seem to be
specifically tied into NTFS. It doesn’t have pluggable security
modules. Does it even have loadable modules at all?

And its “personality” system seems a lot more unwieldy and clumsy than
Linux’s pluggable “binfmt” system.

> Windows NT started life as a next-generation portable high-end 32-bit
> OS/2 implementation known as NT-OS/2.

I know. Note that “32-bit”: it was never designed to make a transition
to 64-bit easy. Also note that “portable” nonsense--that was another
abject failure.

As for “next-generation” ... drive letters, that’s all I need to say.

> If converting the entire userspace personality from one OS to another in
> a year without any significant architectural changes doesn't validate
> the design I don't know what would.

Has anybody demonstrated OS/2 software actually running under NT? Just
curious.

> I'm also not sure why you think WSL is a failure.

WSL1 certainly is. Else there would not have been WSL2, would there?

In article <v0hdf0$3v35b$3@dont-email.me>, ldo@nz.invalid says...
>
> On Fri, 26 Apr 2024 19:53:31 +1200, David Goodwin wrote:
>
> > In article <v0fel2$3grqf$1@dont-email.me>, ldo@nz.invalid says...
> >>
> >> On Fri, 26 Apr 2024 17:05:21 +1200, David Goodwin wrote:
> >>
> >> > WSLv1 exists and it does work surprisingly well.
> >>
> >> But never quite good enough. And it is now abandoned.
> >
> > Its still there and still works. And importantly its still supported.
>
> You know how they like to use marketing-speak to avoid coming out and
> saying something is EOL?
>
> From
> <https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-in-the-microsoft-store-is-now-generally-available-on-windows-10-and-11/>:
>
> Additionally, the in-Windows version of WSL will still receive
> critical bug fixes, but the Store version of WSL is where new
> features and functionality will be added.
>
> So it?s quite clear: no more ?new features and functionality?. And
> when was the last time you saw a ?critical bug fix? for WSL1, by the
> way?

What makes you say they aren't fixing critical bugs? I'm sure if you
report a security issue in WSLv1 they'll fix it same as any other
windows component.

> >> You tell me: are two monolithic kernels better than one?
> >
> > NT isn't generally considered to have a monolithic kernel.
>
> It has the GUI inextricably entwined into it.

The GUI actually lives in the Win32 Environment Subsystem. Until NT 4.0
it was all implemented entirely in userspace. For performance reasons
window management and a few other bits were moved into a kernel driver
service (win32k.sys) in NT 4.0. This driver is loaded by the Win32
Environment Subsystem (csrss.exe) when its loaded.

So the kernel itself knows nothing about GUIs and until the Session
Manager Subsystem launches the Win32 Environment Subsystem, Windows NT
is an entirely text-mode operating system. This is why on-boot
filesystem checks aren't graphical: the check disk tool is implemented
using the Native API and run before the Win32 subsystem has started
meaning there is no GUI for it to use.

> It doesn?t have a
> virtual filesystem layer--most filesystem features seem to be
> specifically tied into NTFS.

Microsoft has shipped a bunch of filesystem drivers including the well
known ntfs, fastfat, cdfs and in the past hpfs. Various 3rd parties have
shipped drivers too. Here is a btrfs filesystem driver for Windows:
https://github.com/maharmstone/btrfs

I'm not sure what you mean by filesystem features being tied into NTFS,
or what features you imagine NTFS is missing that would limit what other
filesystem drivers could provide.

> It doesn?t have pluggable security
> modules. Does it even have loadable modules at all?

It does have pluggable security modules. These are managed by the Local
Security Authority Subsystem Service. Kerberos, SSL and NTLM modules are
provided out of the box along side local accounts. If you want you can
write your own authentication packages too - the details are all on
MSDN.

You can also completely replace the login screen if you like by
reimplementing the GINA interface - this is what the Novell NetWare
client did.

> And its ?personality? system seems a lot more unwieldy and clumsy than
> Linux?s pluggable ?binfmt? system.

Given you don't appear to know anything about it I'm not sure how you're
able to say it seems more unwieldy or clumsy. It also goes beyond what
binfmt does.

> > Windows NT started life as a next-generation portable high-end 32-bit
> > OS/2 implementation known as NT-OS/2.
>
> I know. Note that ?32-bit?: it was never designed to make a transition
> to 64-bit easy.

I ported C-Kermit for Windows in about a day IIRC. Most of the code that
needed changing was stuff that deviated from the recommended way of
building Windows applications. The transition in this case was quite
easy.

> Also note that ?portable? nonsense--that was another
> abject failure.

Windows NT has been publicly released for: MIPS R4000, x86, Alpha,
PowerPC, Itanium, x86-64, ARM, ARM64

It has been ported to, but not released on: i860XR, MIPS R3000, Clipper,
PA-RISC, 64bit Alpha. And work was started on a SPARC port it doesn't
appear to have got far.

Not seeing the failure here.

> As for ?next-generation? ... drive letters, that?s all I need to say.

Drive letters are a feature of the Win32 environment subsystem - the
Win32 namespace. This is implemented on top of the NT namespace which is
provided by the Object Manager.

Wikipedia has a whole bunch of pages describing its architecture which
may be of interest:
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT

> > If converting the entire userspace personality from one OS to another in
> > a year without any significant architectural changes doesn't validate
> > the design I don't know what would.
>
> Has anybody demonstrated OS/2 software actually running under NT? Just
> curious.

Presentation Manager for NT:
https://virtuallyfun.com/2021/05/19/presentation-manager-for-windows-nt/

Though I think the OS/2 subsystem was primarily there for running server
software in the early days of NT. Until the release of NT 3.1, all of
microsofts server software (SQL Server, LAN Manager, etc) ran on OS/2
which meant that Microsoft was still shipping OS/2 1.3 after they'd cut
their ties with IBM.

Additionally it only ever supported OS/2 1.x applications. While
Microsoft was involved in the early work on the 32bit OS/2 2.0, they had
no involvement with the final released product so NT never supported
IBMs 32bit OS/2 API.

> > I'm also not sure why you think WSL is a failure.
>
> WSL1 certainly is. Else there would not have been WSL2, would there?

WSLv2 mostly improves filesystem performance and gives you support for
linux kernel modules. The downside is accessing files outside of the
linux filesystem requires using the 9P protocol and the same is true for
accessing linux files from Windows.

WSLv1 runs on top of the regular Windows filesystem storing all its
files in NTFS so there is no performance penalty for accessing stuff
outside the "linux area" beyond the general filesystem performance
penalty WSLv1 itself imposes.

I believe the original design goal for WSLv1 was actually for running
Android apps on Windows 10 Mobile. A more limited variety of
applications on hardware that would not necessarily be appropriate for
running a hypervisor and linux kernel. This code was later repurposed as
WSLv1. Perhaps if general linux binary compatibility for desktop PCs was
the initial goal WSLv1 would have been designed differently.

On 4/26/2024 9:52 PM, David Goodwin wrote:
> In article <v0hdf0$3v35b$3@dont-email.me>, ldo@nz.invalid says...
>> On Fri, 26 Apr 2024 19:53:31 +1200, David Goodwin wrote:
>>> NT isn't generally considered to have a monolithic kernel.
>>
>> It has the GUI inextricably entwined into it.
>
> The GUI actually lives in the Win32 Environment Subsystem. Until NT 4.0
> it was all implemented entirely in userspace. For performance reasons
> window management and a few other bits were moved into a kernel driver
> service (win32k.sys) in NT 4.0. This driver is loaded by the Win32
> Environment Subsystem (csrss.exe) when its loaded.
>
> So the kernel itself knows nothing about GUIs and until the Session
> Manager Subsystem launches the Win32 Environment Subsystem, Windows NT
> is an entirely text-mode operating system. This is why on-boot
> filesystem checks aren't graphical: the check disk tool is implemented
> using the Native API and run before the Win32 subsystem has started
> meaning there is no GUI for it to use.

And why the Core/Nano editions are possible.

>>> I'm also not sure why you think WSL is a failure.
>>
>> WSL1 certainly is. Else there would not have been WSL2, would there?
>
> WSLv2 mostly improves filesystem performance and gives you support for
> linux kernel modules. The downside is accessing files outside of the
> linux filesystem requires using the 9P protocol and the same is true for
> accessing linux files from Windows.
>
> WSLv1 runs on top of the regular Windows filesystem storing all its
> files in NTFS so there is no performance penalty for accessing stuff
> outside the "linux area" beyond the general filesystem performance
> penalty WSLv1 itself imposes.
>
> I believe the original design goal for WSLv1 was actually for running
> Android apps on Windows 10 Mobile. A more limited variety of
> applications on hardware that would not necessarily be appropriate for
> running a hypervisor and linux kernel. This code was later repurposed as
> WSLv1. Perhaps if general linux binary compatibility for desktop PCs was
> the initial goal WSLv1 would have been designed differently.

It is not particular unusual that a version 1 of a product
get released with a simple set of requirements and then usage
increase and new requirements show up - and now it makes sense
to change design in version 2.

MS own explanation is:

<quote>
WSL 2 is a major overhaul of the underlying architecture and uses
virtualization technology and a Linux kernel to enable new features. The
primary goals of this update are to increase file system performance and
add full system call compatibility.
</quote>

https://learn.microsoft.com/en-us/windows/wsl/compare-versions

I have always believed the second one was the key - emulating an OS
95% or 99% or 99.9% is doable - emulating an OS 100% is difficult.

The above link elaborate a bit:

<quote>
Linux binaries use system calls to perform functions such as accessing
files, requesting memory, creating processes, and more. Whereas WSL 1
used a translation layer that was built by the WSL team, WSL 2 includes
its own Linux kernel with full system call compatibility. Benefits include:

A whole new set of apps that you can run inside of WSL, such as
Docker and more.

Any updates to the Linux kernel are immediately ready for use. (You
don't have to wait for the WSL team to implement updates and add the
changes).
</quote>

I suspect docker is a good example of something that require a real
Linux kernel.

Arne

On 4/27/2024 9:10 AM, Arne Vajhøj wrote:
> MS own explanation is:
>
> <quote>
> WSL 2 is a major overhaul of the underlying architecture and uses
> virtualization technology and a Linux kernel to enable new features. The
> primary goals of this update are to increase file system performance and
> add full system call compatibility.
> </quote>
>
> https://learn.microsoft.com/en-us/windows/wsl/compare-versions
>
> I have always believed the second one was the key - emulating an OS
> 95% or 99% or 99.9% is doable - emulating an OS 100% is difficult.

If we instead of looking at Linux emulation under Windows go to
the opposite direction Windows emulation under Linux, then we
have Wine and https://appdb.winehq.org/ that lists what works
and what does not work. A lot works just fine. But for some
"a lot" is not good enough.

Arne

On Di 23 Apr 2024 at 02:07, cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> In article <v06t9m$fni$4@tncsrv09.home.tnetconsulting.net>,
> Grant Taylor <gtaylor@tnetconsulting.net> wrote:

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

And what is so bad about APL?

'Andreas

--
ceterum censeo redmondinem esse delendam

On 4/27/2024 9:15 AM, Andreas Eder wrote:
> On Di 23 Apr 2024 at 02:07, cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <v06t9m$fni$4@tncsrv09.home.tnetconsulting.net>,
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
>> Regardless, I wouldn't consider sendmail's config stuff anywhere
>> analogous to a Makefile or header; more like APL source code
>> perhaps.
>
> And what is so bad about APL?
>

Glad to see I am not the only one to take umbrage at that statement.
But then, I never had a problem with sendmail.cf either and I ran
sendmail based mailservers for many years.

bill

In article <87r0erc5fr.fsf@eder.anydns.info>,
Andreas Eder <a_eder_muc@web.de> wrote:
>On Di 23 Apr 2024 at 02:07, cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> In article <v06t9m$fni$4@tncsrv09.home.tnetconsulting.net>,
>> Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>
>> Regardless, I wouldn't consider sendmail's config stuff anywhere
>> analogous to a Makefile or header; more like APL source code
>> perhaps.
>
>And what is so bad about APL?

First, I didn't say it was bad. What I said was that it shared
characteristics with the sendmail config file syntax: both are
perfectly readable to those well-versed in their arcana; from
outside, both can seem illegible. I think that's fair.

- Dan C.

On 4/23/24 06:18, Lawrence D'Oliveiro wrote:
> 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.

Perhaps some really can't see a need for it, despite it having fingers
into every aspect of the system, and being complex and opaque.

A cynic might say that the whole idea of systemd is to deskill
system management, so that the half brain dead can be employed, rather
than people who actually understand how systems work.

Painting by numbers for sysadmin, when there really is no substitute
for in depth knowledge...

On 4/22/24 01:11, motk wrote:
> On 22/04/2024 10:03 am, chrisq wrote:
>
>> One could argue that if you are chasing races in scripts, there's
>> something else wrong in the basic system design :-).
>
> Sure, but it's not always my job to fix that. Sometimes you have to deal
> with what you get.
>
>> Having used Solaris for decades, their svcadm and other service
>> management tools seemed quite lightweight, in that all the config
>> scripts were in the usual places. Still in plain text format, as were
>> the log files, which could be manually edited with no ill effect. In
>> essence, a layer on top of what was already there. The FreeBSD service
>> framework seems to work in the same way, a lightweight layer on top of
>> what was already there. Limited experience, but the AIX smit etc tools
>> also seem to work the same way, layered software design.
>>
>> Now compare such an approach with that of systemd, and tell us why
>> such opaque complexity is a good thing...
>
> What? Where is the opaqueness, where is the complexity? I'm absolutely
> baffled here. What plain text files are you needed to edit? What are the
> usual places? I use this stuff daily, and it manifestly makes my working
> life easier. At no point does it replace any of the tradition unix stuff
> like bind or whatever *unless you specifically ask it to*. None of the
> major distributions build it that way, except perhaps for people using
> zfs root, or iot/cloud builds where they *want* a monolithic init.

If you had ever worked on serious system design, you would realise
that reliable system design depends on strict partitioning and
encapsulation. Layered functionality, with defined interfaces.
Strangely enough, but "elegance" really does apply in many such
cases, and is what many software engineers strive for.

>
> It really sounds like you just need to sit down, read the documentation
> from the systemd and distro side, and work out what works for you.
> Sitting around carping at what is now an established industry standard
> because 'elegance' isn't how I choose to spend my time.
>

No, I don't need to sit down and spend hours reading docs on
something I don't need for my work and that is wrong by design,
though I guess design elegance does depend on personal opinion.

Quite enough camels in the world already...

On Sat, 27 Apr 2024 10:18:41 -0400, bill wrote:

> But then, I never had a problem with sendmail.cf either and I ran
> sendmail based mailservers for many years.

Even with the Sendmail book in hand, I was still never entirely sure what
I was doing. A later version brought in configuration with m4 macros, but
trying to move to that seemed to cause more problems than it solved.

Then, by mutual agreement with the client, we moved to Postfix. And that
made so much more sense, I never looked back.

On Sat, 27 Apr 2024 17:13:05 +0100, chrisq wrote:

> If you had ever worked on serious system design, you would realise that
> reliable system design depends on strict partitioning and encapsulation.
> Layered functionality, with defined interfaces.

All of which applies to systemd, its config definition system and its
APIs. It is very much modular. The irreducible core is the systemd init
process, journald and udevd. That’s it. There are 69 individual binaries
if you choose to build everything, but all except that core are optional.

And the fact they are separate binaries should tell you how modular
everything is.

> No, I don't need to sit down and spend hours reading docs on
> something I don't need for my work and that is wrong by design .,..

<http://0pointer.de/blog/projects/the-biggest-myths.html>

(Posted here not for the person I’m replying to, but for the sake of those
willing to learn.)

On Sat, 27 Apr 2024 16:50:06 +0100, chrisq wrote:

> Perhaps some really can't see a need for [systemd] ...

That’s entirely fair. That’s why we have so many Linux distros that don’t
use it. Open Source is all about choice.

What is inexplicable is the hostility from those who simply seem to hate
the fact that systemd exists, and that it is quite popular. The noise they
make is entirely out of proportion to their numbers. Kind of like anti-
fluoridationists.

On 4/27/24 23:48, Lawrence D'Oliveiro wrote:
> On Sat, 27 Apr 2024 10:18:41 -0400, bill wrote:
>
>> But then, I never had a problem with sendmail.cf either and I ran
>> sendmail based mailservers for many years.
>
> Even with the Sendmail book in hand, I was still never entirely sure what
> I was doing. A later version brought in configuration with m4 macros, but
> trying to move to that seemed to cause more problems than it solved.
>
> Then, by mutual agreement with the client, we moved to Postfix. And that
> made so much more sense, I never looked back.

To be fair though, sendmail is about the most obtuse example you could
find, and it is only an application program, not part of the kernel.

Those who need to, will learn how to drive it and there are probably
dozens of sites online demystifying the process. Computing is a complex
subject, not for those who can't be bothered making the effort..

On 4/27/24 23:55, Lawrence D'Oliveiro wrote:
> On Sat, 27 Apr 2024 16:50:06 +0100, chrisq wrote:
>
>> Perhaps some really can't see a need for [systemd] ...
>
> That’s entirely fair. That’s why we have so many Linux distros that don’t
> use it. Open Source is all about choice.

Perhaps, but even Devuan still has traces of it, which suggests that
it's very difficult to get rid of.

>
> What is inexplicable is the hostility from those who simply seem to hate
> the fact that systemd exists, and that it is quite popular. The noise they
> make is entirely out of proportion to their numbers. Kind of like anti-
> fluoridationists.

Ok mea culpa, I guess it could just be viewed as a different way of
doing things, but, for example, why are log files in binary ?...

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>What is inexplicable is the hostility from those who simply seem to hate
>the fact that systemd exists, and that it is quite popular. The noise they
>make is entirely out of proportion to their numbers. Kind of like anti-
>fluoridationists.

A lot of it comes from the fact that due to corporate standards or due to
support of commercial applications, many Linux users are forced into running
RH or an RH-alike and they don't actually have choice.

Which isn't really systemd's fault, or really even RH's fault, but it is a
definite failing of the linux community in some ways.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 4/27/24 23:53, Lawrence D'Oliveiro wrote:
> On Sat, 27 Apr 2024 17:13:05 +0100, chrisq wrote:
>
>> If you had ever worked on serious system design, you would realise that
>> reliable system design depends on strict partitioning and encapsulation.
>> Layered functionality, with defined interfaces.
>
> All of which applies to systemd, its config definition system and its
> APIs. It is very much modular. The irreducible core is the systemd init
> process, journald and udevd. That’s it. There are 69 individual binaries
> if you choose to build everything, but all except that core are optional.

I read the article linked to elsewhere. Something like >60 separate
binaries for all the functionality. It's entrails into every aspect of
the system, far more than that needed for init.

One ring to rule them all too many, imho.

>
> And the fact they are separate binaries should tell you how modular
> everything is.
>
>> No, I don't need to sit down and spend hours reading docs on
>> something I don't need for my work and that is wrong by design .,..
>
> <http://0pointer.de/blog/projects/the-biggest-myths.html>
>
> (Posted here not for the person I’m replying to, but for the sake of those
> willing to learn.)