RHEL 8

[Fait, James F.]

I have been using RH and derivatives for over 20 years, and i have seen the 
evolution of system startup/process management systems over that time frame.  I 
admit that I "prefer" the script-based methods of upstart and related animals, 
as it made it possible to predict when something would try to start, and the 
scripts were something that was easy for anyone with shell programming 
experience to fix or change.  However, those days seem to be gone, at least for 
most distributions.

Recently, I have been forced to learn the intricacies of SystemD, as I had 
local programs that needed to start reliably on boot on either SL7 or Ubuntu.  
I have evaluated RHEL 8 and said no, based on the licensing and the fact that I 
do not trust IBM to "Do the RIGHT thing" going forward.  I know that the 
packages I need will work on Debian /Ubuntu, as one of our developers uses 
Debian as his main platform and has for many years.  However, even he did not 
provide SystemD configuration files, but insisted on the system 5 type script 
for startup of his programs.

I understand the frustration with SystemD.  I spent the better part of 3 weeks 
to get something that sort of works, and even then, I had to hand edit the 
SystemD files to tweak paths, etc.  This was done with environment variables 
and shell variable replacement in the older scripts, which works for some 
things in SystemD, but not for others.   I finally punted and wrote a program 
to write the SystemD files with the full paths and ignored the broken 
implementation of environment entirely.  Even then, I have issues with 
sequencing of related programs, and I am still not sure that timers and the 
system of "wants/requires" work correctly.

I have had to write unit files for several packages now, such as redis and 
others, and none of them inspire confidence in SystemD.  However, SystemD is 
the only game in town now, at least for EL.  I wonder how it will handle Docker 
containers.  I am just starting to use them for some specialized tasks, and 
hand starting them is OK for now, but it will become necessary for boot time 
initialization eventually.  Perhaps there will be a way to have a deterministic 
method that can be predicted easily in the future, but it is not there now.

I got a taste of this type of thing recently , when the motion controller 
company that we have used for the past 20 years was purchased from private 
ownership by a large corporation, and the platform that we had used was 
immediately declared as obsolete and unsupported, even though we had just 
purchased a fairly large amount of the hardware as new and current a few months 
earlier.  Since we were forced to change anyway, we went with another company 
entirely, as it was evident that the large company was not interested in the 
small research community that was using the hardware to solve problems that 
they were never going to make any money on.  I see the same thing happening 
with RHEL, and I doubt seriously that there will be a RHEL 9, as IBM will not 
see it as in their interest to develop it.  Time to move on.

~J.


James Fait, Ph.D.

Senior Beamline Scientist

SER-CAT, APS, Argonne National Laboratory

Building 436B-020, 9700 S. Cass Ave., Argonne, IL  60439

f...@anl.gov<mailto:f...@anl.gov>

f...@uga.edu<mailto:f...@uga.edu>

Cell: 815-302-2467 Fax: 630-252-0652

Light When You Need It

Re: Rhel 8

[~Stack~]

On 1/25/21 5:50 PM, Konstantin Olchanski wrote:

On Mon, Jan 25, 2021 at 11:31:08PM +, Miles ONeal wrote:


| For me, the issues are not policital, but technical:

Agreed. One of mine is that the surety of being able to drop a lower runlevel 
and back up is gone. ...




If you ask me, systemd was designed and built to solve one and only one problem,
boot it's author's personal 1 core 300 MHz laptop as fast as possible. Today,
with 4 core 3000 MHz laptops and 16 core 4000 MHz "servers", many features
of systemd look quaint. ("waiting for USB devices to settle", really?).

Benchmarks that report "old" and "slow" SysV initscripts boot as fast as systemd
tend to support this viewpoint.

Each time I look at the systemd boot sequence trace, I see things like
"waiting 10 sec for disks that are not needed for booting" and
"waiting 10 sec for network not needed for booting". If unlucky, also see
"waiting forever for disk that failed and was removed" (hello, booting from 
degraded btrfs raid array).

How this stuff got into "E" linux and why paying customers put up with this,
is a mystery to me. Perhaps said paying customers "never reboot" and never
see systemd shortcomings (and get no benefit from "systemd fast booting").



As I mentioned before, there's a lot more to systemd then what the user 
sees or cares about. Most people don't care about fast boot and I rarely 
boot my servers. Yet, I do rely on a lot of things in systemd (see 
previous email about dealing with stuck NVidia GPU's).


It's not that I don't see systemd shortcomings. It has some. But so did 
SysV and the old init.


Again, it's just a tool. How it is used and if it is used well is up to 
the one who needs to use it. :-)


~Stack~

Re: Rhel 8

[Konstantin Olchanski]

On Mon, Jan 25, 2021 at 11:31:08PM +, Miles ONeal wrote:
> 
> | For me, the issues are not policital, but technical:
> 
> Agreed. One of mine is that the surety of being able to drop a lower runlevel 
> and back up is gone. ...
>


If you ask me, systemd was designed and built to solve one and only one problem,
boot it's author's personal 1 core 300 MHz laptop as fast as possible. Today,
with 4 core 3000 MHz laptops and 16 core 4000 MHz "servers", many features
of systemd look quaint. ("waiting for USB devices to settle", really?).

Benchmarks that report "old" and "slow" SysV initscripts boot as fast as systemd
tend to support this viewpoint.

Each time I look at the systemd boot sequence trace, I see things like
"waiting 10 sec for disks that are not needed for booting" and
"waiting 10 sec for network not needed for booting". If unlucky, also see
"waiting forever for disk that failed and was removed" (hello, booting from 
degraded btrfs raid array).

How this stuff got into "E" linux and why paying customers put up with this,
is a mystery to me. Perhaps said paying customers "never reboot" and never
see systemd shortcomings (and get no benefit from "systemd fast booting").


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Rhel 8

[Yasha Karant]

Without adding too much additional traffic, the ability to go down 
levels with things such as NFS "off" but otherwise maintain the running 
image (and other state variable values), one could isolate and possibly 
identify problems -- without throwing an exception except from any 
additional "failures".  The generated logs, and sometimes a snapshot 
dump, allowed one to track down obscure failures (such as a firmware 
timing defect, in one such issue at one time in the past I had to solve 
-- and a software change in the kernel driver got around the firmware 
issue).


On 1/25/21 3:31 PM, Miles ONeal wrote:




*FKonstantin said:*
...

| For me, the issues are not policital, but technical:

Agreed. One of mine is that the surety of being able to drop a lower 
runlevel and back up is gone. I have always managed my systems the way I 
learned in the early days (probably from SunOS) where level 2 was 
multi-user no NFS, level 3 added NFS (and possibly more), and level 5 
was a GUI.
Sometimes it is *very handy*​ to be able to go down one or more levels 
to make changes or solve problems, then come back up. And it's much 
faster than rebooting beefy modern servers with their extensive hardware 
checks (or even Fedora on an older home computer).
For whatever faults it had, SysVInit handled this as well for me over 
the years as whatever had been in BSD. systemd does not- at least within 
Fedora and RHEL and its rebuilds.


-Miles

Re: Rhel 8

[Miles ONeal]

FKonstantin said:
...

| For me, the issues are not policital, but technical:

Agreed. One of mine is that the surety of being able to drop a lower runlevel 
and back up is gone. I have always managed my systems the way I learned in the 
early days (probably from SunOS) where level 2 was multi-user no NFS, level 3 
added NFS (and possibly more), and level 5 was a GUI.
Sometimes it is very handy​ to be able to go down one or more levels to make 
changes or solve problems, then come back up. And it's much faster than 
rebooting beefy modern servers with their extensive hardware checks (or even 
Fedora on an older home computer).
For whatever faults it had, SysVInit handled this as well for me over the years 
as whatever had been in BSD. systemd does not- at least within Fedora and RHEL 
and its rebuilds.

-Miles

Re: Rhel 8

[Konstantin Olchanski]

On Sat, Jan 23, 2021 at 06:41:39PM -0600, ~Stack~ wrote:
> 
> TL;DR synopsis.
>

Mr. Stack, Sir! Thank you for writing up this historical overview,
I read it with great enjoyment. Of course I have a few comments.

> It's just a tool.

I feel blindsided by this systemd business. I cut my teeth starting
with SGI IRIX circa 1992, and I am well aware of the shortcomings
of SysV init scripts. I am also well aware and I celebrate it's main
feature. Any and all problems I ran into could be fixed in a couple
of hours using "vi". (hack the bad script until it works).

So years later, "upstart", etc start showing up and I thought "whatever...",
it cannot be worse than SysV scripts. And sure enough. (SL4, SL5, SL6 era).

Then I read in the news this whole "systemd kerfuffle", and I think,
"whatever...", it cannot be that bad, if it is good enough for
Red Hat *Enterprise* Linux, should be good enough for me. Must be a tempest
in a tea pot, another vi/emacs holy war, for sure they will fix all
the bugs by the time I see it.

Then it shows up in all it's glory in SL7, and? With my eyes I see
that, yes, it is as bad as the worst naysayers have proclaimed.

For me, the issues are not policital, but technical:

- cannot ask "what order will you start things on boot?"
- does not start things on boot in the order I specified in the service files
- designed-in chicken-and-egg problem with systemd and dbus each starting first
  and registering with each other
- documentation is for latest version, but my computer has version N-5, half
  of advertised functions are absent
- the infamous bug report about systemd rejecting valid user names (in the 
nutshell,
  systemd author decreed "I decide what usernames are valid" and closed the bug)
- broken-out-of-the-box, "shutdown -r now" does not shutdown "NOW!!!". Tries
  to logout interactive users, unmount NFS filesystems (after shutting down
  the network), waits until programs users run in background terminate).

By this list, clearly, basic debugging and basic system operational needs
are not important to the systemd designers and developers.

And I guess it is all my fault, I should have rooted for the right team
back in 2002 (or whenever) on the Fedora and Debian mailing lists.
Instead, I was asleep at the switch, being a happy user of SL4/5/6.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

Re: Rhel 8

[Yasha Karant]

David,

I appreciate your candor and suggestion; please do not take in any way 
my remarks below as directed against you, nor to discount your suggestion.


If I thought that what you suggest would have any meaningful impact, I 
might consider it.  I am at a university that has changed to the 
university administration current mantra of retention and graduation of 
vocational training for workforce development with customer 
satisfaction, and for which Faculty joint decision making almost is 
defunct.  I have no research staff nor useful research students at the 
present time, and have no spare time in which even to do a design, let 
alone development, implementation, and deployment of alternatives to or 
meaningful modifications of any systems level software.  My own research 
area is quantum computing, but for that too I have no resources and 
significant direct instructional responsibilities. Thus, simple 
discussions and what amount to theoretical ramblings are easy to dismiss 
(data anyone?  how many vulnerabilities does SystemD and its "tentacles" 
have?  how many exploits?  how much "damage" done by such exploits?  as 
pointed out by a nominal proponent of SystemD on this list).


Unlike the Ubuntu lists that have very few if any actual Canonical 
internals persons (e.g., Canonical engineers) present, and furthermore 
have many who do not seem to understand the meaning of much CSE 
terminology (equivalent in the popular press and "blogs" to misusing the 
term "exponential" for a plot that clearly is not exponential), SL is a 
list in which there are "professionals".


RH is owned by IBM. As a USA for-profit corporation, IBM practices 
avarice and rapacity, typically with disingenuity and mendacity in so 
far as that increases the only thing of real interest to a USA 
for-profit (this is not an EU, etc., entity): improved financial 
position.  The EL8 debacle is illustrative (that evidently has drawn 
Fermilab/CERN into it because CentOS 8 -- the planned replacement for SL 
that stopped with SL 7 -- has been discontinued -- a decision that I 
suspect was approved by IBM "management").


Thus, I doubt that anything I could do or say would have any influence.

As there are others who do subscribe to this list who may have more 
influence on distros, it is possible that the discussion here may have 
some broader impact.  I am not holding my breath.


On 1/25/21 1:39 PM, David Sommerseth wrote:
[Sorry again, resending it via the proper mail gateway - hopefully 
correctly configured now]


I have not done real internals development since the days of DEC-based BSD, and 


Yasha, your involvement is impressive, your fearless attitude of stating 
clearly what you dislike.  That's all good.


But, are you doing it in the right channels?  What do you try to solve 
by ranting over systemd and CentOS/RHEL 8, here on this list? Even SL7 
and RHEL 7 has been hit by your arguments.  How can we get going forward 
from here?  SL does not define the real path forward for how SL evolved 
as a distribution (it's building on CentOS/RHEL). CentOS neither (it's 
building on RHEL/Fedora).  You're basically preaching to a choir behind 
a gas station along a busy and noisy highway, where it's only you and a 
few of you with the same opinion.  But it mostly stops here.


I've checked the complete Fedora devel [1] and users list [2]. I don't 
see you posting anything there.  That's where the direction of 
RHEL/CentOS and SL has been decided, years before it hits RHEL.  I've 
checked the systemd mailing list [3] going back to to January 2017. Same 
result, I did not find your input there either.


You've also talked about jumping the ship in favour of Ubuntu. What is 
holding you back here?


I understand passion.  I understand wanting to improve things.  But just 
ranting over and over for years, in the wrong places, does not give any 
results at all.


All of Fedora, systemd ... it's all open source.  It's all open and 
public discussions.  It would be highly appreciated if you spent your 
energy trying to make a difference - not just complaints about what is 
wrong everywhere else.


[1] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_devel-40lists.fedoraproject.org_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=_M3A82CK-BARwIGgGLEr7kgjoMFUWlJppj1NQtNoFbM&s=HOcR9UDWBgMhf_O4fqsTZ-pi8Vephe7vrw-HqBH6j_A&e= > 

[2] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_users-40lists.fedoraproject.org_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=_M3A82CK-BARwIGgGLEr7kgjoMFUWlJppj1NQtNoFbM&s=uzvvtXN7gfd9tLyibCc7F0oyIMLJ_MuxEnMYFO3NVRI&am

Re: Rhel 8

[~Stack~]

On 1/25/21 2:01 PM, Andrew C Aitchison wrote:
I'm somewhat old school (I am still using twm as my window manager* over 
a decade later) so I don't know why anyone would want this new-fangled DBus
thing that, as you say, lets a chat program addon cause a music player 
to crash the kernel.


Eh. Have to remember the time frame. From the late 90's to late 00's 
chat applications were almost an essential way of life for most of us 
computer nerds. Pidgin let me tie into IRC, ICQ, AIM, ect ect ect. Sure, 
having silly things like my status being updated with what music I was 
playing was all for that nerd-life-cred. But there was a lot of things 
that I depended on in those days. Nearly all of my system monitoring and 
alerting reached out to me via those chat applications. Whether it was a 
long running compile-then-run script chomping one of my cores on the 
local system or my webserver at work, that's how I was notified.


Today, all those integrations for monitoring are a combination of Zabbix 
+ Mattermost. But back then, dbus was a fantastic new way of getting 
active status from applications. Dbus is so much more and most users 
don't even know it's running.




For release after release we had to hack/patch an init script.
IIRC this was Red Hat 4 and 5, and I don't remember all the details, so 
what follows may be a little off: We had to make ypbind run on
a fixed port so that nfsd didn't fail because something else had grabbed 
the port first (or was it the other way around ?)


With that experience I wont believe you if you tell me that a complex
C program handling lots of signals and processes is safer than a shell 
script. I know which one I can hack sucessfully and have enough smarts

to consider whether what I did was secure.

From what yo say, systemd might have been the right answer to my 
original problem, but if Red Hat couldn't get around to fixing the 
nfsd/ypbind conflict, could I expect them to make code 10 times

(or maybe a 100) more complex any more reliable ?


Systemd would help with a lot of that pain and I don't think it would 
make it more complex. Yellowpages had a ton of issues. I'm personally 
glad I've not had to touch that in years! :-D



By the sound of it Larry Linder, who started this discussion, finds
that chat programs and music players don't help the productivity
  of his machine-tool shop either. If D-Bus is a problem why would
he want a complex system that appears to exist to allow it ?


I don't run chat programs nor music players on my production cluster 
nodes either. Those were just examples of use. But dbus is still there 
on the cluster nodes. Why? Because the company standardized on AD for 
authentication talks to services over dbus. We have bluetooth sensors 
that pull data. Bluetooth talks to hardware and software services with 
dbus. When I have a drive die and I pull it out to slide a new one in so 
that the RAID can rebuild itself, that communication is dbus! The 
security team makes me run full SELinux with extra rules which involves 
polkit which is...drum-roll...dbus!

:-D

Dbus means "Desktop bus" but these days it's much more then desktop. 
Why? Because all dbus does is act as a platform for communication.


Without dbus, my application would have to talk directly to _every_ 
other application. That's messy and nasty. It certainly doesn't scale. 
Dbus is just one thing that my application has to talk to.


Can one use dbus without systemd? Absolutely. Most of the distro's that 
don't use systemd still have dbus. It's more of a different level then 
systemd. Systemd just provides a whole lot of niceties to make it easier 
to communicate and manage the services that talk to each other.




* No, I do not want a "desktop environment". My windows were either
firefox or xterm's sshd into other machines - sometimes a hundred,
fired up in batches of twenty.


I get it. I personally miss EvilWM. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.6809.org.uk_evilwm_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=YrwMA54vsOmAKha6cxK4r26yqFpWhMRgKm7xk5p_Y2o&s=toG-ahqqKwQQ9VWD94amXog6la2u6RS7o-r-HOwiLvM&e= 
It was all keyboard controlled. No mouse. I loved it. But it hasn't been 
maintained in a long time and problems weren't being fixed. :-(
I settled on LXDE because it was simple but provided a few more 
niceties. I've reluctantly switched to LXQT and I don't like it nearly 
as much as LXDE, but LXQT is the supported path forward. I loath most 
all of the other desktop GUI's. My laptop and primary desktop are the 
only ones with a GUI. Everything else is minimal head-less servers.


xterm bothers me. It's fine for a shell, but I want more flexibility out 
of my terminal since I practically live on the terminal. Personally a 
huge fan of terminator.


I don't want to count the number of shell currently open nor the number 
of systems I'm connected to...it might scare me... I use multiple 
desktops to 

Re: Rhel 8

[David Sommerseth]

[Sorry again, resending it via the proper mail gateway - hopefully 
correctly configured now]



Yasha, your involvement is impressive, your fearless attitude of stating 
clearly what you dislike.  That's all good.


But, are you doing it in the right channels?  What do you try to solve 
by ranting over systemd and CentOS/RHEL 8, here on this list? Even SL7 
and RHEL 7 has been hit by your arguments.  How can we get going forward 
from here?  SL does not define the real path forward for how SL evolved 
as a distribution (it's building on CentOS/RHEL). CentOS neither (it's 
building on RHEL/Fedora).  You're basically preaching to a choir behind 
a gas station along a busy and noisy highway, where it's only you and a 
few of you with the same opinion.  But it mostly stops here.


I've checked the complete Fedora devel [1] and users list [2]. I don't 
see you posting anything there.  That's where the direction of 
RHEL/CentOS and SL has been decided, years before it hits RHEL.  I've 
checked the systemd mailing list [3] going back to to January 2017. Same 
result, I did not find your input there either.


You've also talked about jumping the ship in favour of Ubuntu. What is 
holding you back here?


I understand passion.  I understand wanting to improve things.  But just 
ranting over and over for years, in the wrong places, does not give any 
results at all.


All of Fedora, systemd ... it's all open source.  It's all open and 
public discussions.  It would be highly appreciated if you spent your 
energy trying to make a difference - not just complaints about what is 
wrong everywhere else.


[1] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_devel-40lists.fedoraproject.org_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=MbLPubu3xro3KY42MbNHRi2JVUXoSxzgR3HV4SPKVbQ&s=Yy74zKpM9UOmCpcfjGKNPoEicgesfTJn31uHAV8Pzko&e= >
[2] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_users-40lists.fedoraproject.org_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=MbLPubu3xro3KY42MbNHRi2JVUXoSxzgR3HV4SPKVbQ&s=rnS83qRzcyAnYRwrcaW2Kylf6gPhv_n_XnpLmxItSa4&e= >

[3] 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_systemd-2Ddevel_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=MbLPubu3xro3KY42MbNHRi2JVUXoSxzgR3HV4SPKVbQ&s=ZN9yYZPguqBDVcyjg_GL6Ifll7Q1F4QBMngSVnhjFEY&e=
 >


On 25/01/2021 18:04, Yasha Karant wrote:

SystemD as it currently stands is too delicate and too
vulnerable to compromise, either within itself or in terms of the
processes/subsystems it "controls", despite the large scale deployment
of SystemD.


This is your opinion.  These arguments has been discussed plenty of 
times in several distributions before they embraced systemd.  It's 
beating a dead horse.  And still, the majority of Linux distributions 
chosen to move forward with systemd.


And Debian, with all it's own delicious political discussion model, is 
even discussing dropping init systems NOT being systemd.

Source: 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_804254_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=MbLPubu3xro3KY42MbNHRi2JVUXoSxzgR3HV4SPKVbQ&s=u8TGGYvH6fnIBJMhus5mA7XR5hIC7jnjW1f84c28WAk&e=
 >

It's about time to accept that systemd has become the preferred system 
management solution for the biggest and most popular Linux distributions.


If there are things you dislike about systemd.  Talk to the systemd 
developers, get involved, bring good and strong arguments how to make 
systemd better.  Contribute with solutions how to improve.



The reason behind this is in part driven by the monolithic
design (and implementation) of the Linux kernel, and the symptom is
continued SystemD intrusiveness and bloat throughout much (all?) of the
Linux distros that have deployment at scale.


This FUD should be put down once and for all now.  It has been debated 
over and over again.  And it is rooted in a great misunderstanding of 
the source code repository systemd uses.


Do you consider FreeBSD bloated?  All the source code of FreeBSD is in a 
single git repostory: <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_freebsd_freebsd-2Dsrc&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=MbLPubu3xro3KY42MbNHRi2JVUXoSxzgR3HV4SPKVbQ&s=dg40LOVV-G73iqiqNTnsHfWVp5jm-BtTkV8MLx-kbQQ&e= >  It even 
includes the full source code of OpenSSL, OpenSSH, FreeBSD kern

Re: Rhel 8

[Andrew C Aitchison]

My reminisces and tuppence-worth:

On Sat, 23 Jan 2021, ~Stack~ wrote:

One thing people tend to overlook in these conversations is that systemd was 
clearly not meant to help SysAdmins - the fact that does is a by product. The 
point was to help system builders and integrators. EG: the people building 
the distro that others use; the ones who try to make all of the sub-services 
play nice with each other so that the end user can just click around on a 
mouse.


You can think of SystemD as the the low level communication of services that 
not a whole lot of people (developers nor users) want to do but everyone who 
uses a desktop or server depends on to work- it's at the integrator level 
where SystemD starts to shine. It helps a lot of the underpinning 
communications where most users don't ever dare to tread. Those dark tunnels 
where experienced SysAdmins have their eyes gloss over at the dread they 
encountered upon their last traversal.

Those places.


Because getting all the services to talk to one another is incredibly 
difficult. Speaking as someone who used to do a bunch of dbus level 
programming to get services to talk to each other, the old InitV methods 
sucked. It was painful. And every time there was a new service that did 
things differently, it made my work harder. I particularly recall in ~2008 
tracing out an issue with a kernel notification to a network card that caused 
Pidgin to flip out and spam the dbus to the point of crashing other 
completely unrelated services because of a custom plugin...gah...I was down 
reading hex code off the kernel processes to figure that out...and it still 
gives me wake-up-screaming-nightmares...But all the users knew was that their 
music player would cause a kernel panic - they had no idea it was even a 
plugin on Pidgin that was doing it because why would Pidgin (a chat program ) 
care if a music file was played? And what did that have to do with crashing 
the kernel?


I wish I had read something like this at the time.
It would have given me a better idea of what systemd was about.

I'm somewhat old school (I am still using twm as my window manager* over a 
decade later) so I don't know why anyone would want this new-fangled DBus
thing that, as you say, lets a chat program addon cause a music player to 
crash the kernel.


For release after release we had to hack/patch an init script.
IIRC this was Red Hat 4 and 5, and I don't remember all the details, 
so what follows may be a little off: We had to make ypbind run on
a fixed port so that nfsd didn't fail because something else had 
grabbed the port first (or was it the other way around ?)


With that experience I wont believe you if you tell me that a complex
C program handling lots of signals and processes is safer than a shell 
script. I know which one I can hack sucessfully and have enough smarts

to consider whether what I did was secure.

From what yo say, systemd might have been the right answer to my 
original problem, but if Red Hat couldn't get around to fixing the 
nfsd/ypbind conflict, could I expect them to make code 10 times

(or maybe a 100) more complex any more reliable ?

By the sound of it Larry Linder, who started this discussion, finds
that chat programs and music players don't help the productivity
 of his machine-tool shop either. If D-Bus is a problem why would
he want a complex system that appears to exist to allow it ?

* No, I do not want a "desktop environment". My windows were either
firefox or xterm's sshd into other machines - sometimes a hundred,
fired up in batches of twenty.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

Re: Rhel 8

[Lamar Owen]

On 1/25/21 1:34 PM, Yasha Karant wrote:

...
I fully agree that a full security audit would be valuable, an audit 
that needs to be kept current.  Nonetheless, "lines of code" is a well 
established empirical metric, given the approximate number of 
execution ("run time") software defects in syntactically correct 
source code based on the lines of code in the source.  I am not 
defending "lines of code", merely repeating what is a standard "rule 
of thumb".


While I have not counted to see, the number of distributed lines of code 
in the initscripts pulled in by individual packages should also be 
counted, along with the LoC of bash itself.  LoC has been used as a 
rough rule of thumb in the past, but a formal audit is more accurate.  I 
would imagine Red Hat audits the systemd code internally, but I don't 
have any direct evidence of that.


My bigger concern is that SystemD is no longer used on an isolated 
system in a segregated environment (NB: that term has nothing to do 
with socio-political contexts -- please do not misinterpret it as have 
some non-CSE colleagues when hearing of that, "race conditions", and 
other CSE specific terminology).  ...


Understood; as I come from a hardware engineering background I 
understand the potential impacts of 'synchronous asynchrony' and how 
conditions can develop that are very timing-sensitive and 
nondeterministic in behavior; the overall label of 'race condition' is 
used; the most easily explained example I know of is of a four-way stop, 
and all four cars arrive at the intersection simultaneously (within 
human-perceived tolerances, at least).  Which of the four has the right 
of way?


This was sometimes a significant issue with old initscripts.

Were the init systems more resilient?  These were never designed for 
the current wide area network platforms and environments such as 
"cloud computing" -- thus it is very unlikely that these perform 
better.  The issue comes back to the bloat in SystemD overseeing, in 
some sense, "everything".  As such, it is a possible single point of 
failure, or exploit.


It's a common misconception that systemd is one monolithic binary trying 
to do all the things it does; this is not the case.  It IS a large set 
of programs, but each of those is relatively self-contained; see 
https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Systemd&d=DwIFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=pmFyZxsNsGEEYJrcr1FAHWhR-i0LgsbLzEnn12ie7Ag&s=8X0vrNtKYURepsfpHmXakirpVwIFY6biFz6zMzgfzes&e=  for the overview.


But systemd is the name of both the collection of these programs and the 
executable running as PID 1; more than a bit confusing.  Make no 
mistake: it is quite a bit larger than Upstart's init (from EL6) or 
EL5's actual SysV Init, but it's not fair to compare just the code size 
of the init process; the init runs all these scripts that are 
interpreted by the system shell; if that's bash, then the code size 
difference is not nearly as large.  With bash running the initscripts as 
root under the direct control of PID 1, bash must be considered part of 
the init system and thus becomes a link in the vulnerability chain.  The 
chain is only as strong as its weakest link; in sysvinit the collection 
of interrelated initscripts that execute as root is easily the weakest 
link; in systemd it's the relatively large PID 1.

Re: Rhel 8

[Yasha Karant]

Part of the issues about the ATT or BSD init systems had to do with 
"local control" and with captive markets -- the latter a deliberate 
choice by the profit-controllers to the engineers and implementers. 
This is the old interplay between proprietary (often controlled by 
"intellectual property" because the entity has sufficient patent 
attorneys to gain such "property" that can then be used to prohibit the 
development of an innovation to maintain revenue generation) and open 
standards.  The same reason that most threaded fasteners on vehicle 
manufacturer A and B are readily available and interchangeable if the 
same choice of thread, grade, form, etc., were used, whereas engines are 
proprietary.


I fully agree that a full security audit would be valuable, an audit 
that needs to be kept current.  Nonetheless, "lines of code" is a well 
established empirical metric, given the approximate number of execution 
("run time") software defects in syntactically correct source code based 
on the lines of code in the source.  I am not defending "lines of code", 
merely repeating what is a standard "rule of thumb".


My bigger concern is that SystemD is no longer used on an isolated 
system in a segregated environment (NB: that term has nothing to do with 
socio-political contexts -- please do not misinterpret it as have some 
non-CSE colleagues when hearing of that, "race conditions", and other 
CSE specific terminology).  The larger the distributed (and integrated 
or inter-dependent) the environment is, particularly over the public 
Internet (even with VPNs or the like), the greater the risk of 
compromise through vulnerabilities.  Hardening systems is not easy, and 
there are as yet no definite algorithms (let alone implementations) to 
detect vulnerabilities pre-exploit.  Obviously, methods to control 
memory leaks in certain programming languages, etc., help -- but unless 
source code is available, and verification of correctness of the 
compiler (binary or "byte-code") output, there is no guarantee that such 
have been implement.  SystemD is open -- so in principle the coding 
issue could be addressed, but such is not the case for closed systems, 
no source code available.


Were the init systems more resilient?  These were never designed for the 
current wide area network platforms and environments such as "cloud 
computing" -- thus it is very unlikely that these perform better.  The 
issue comes back to the bloat in SystemD overseeing, in some sense, 
"everything".  As such, it is a possible single point of failure, or 
exploit.


However, lacking data and the person power to both accumulate and 
understand such data, this discussion is more speculative than empirical 
-- "philosophy", not "science".  If a major vulnerability is exploited 
through SystemD (as recently was revealed for a proprietary distributed 
update environment, not SystemD), the consequences will affect more than 
just the community of SL.


On 1/25/21 10:05 AM, Lamar Owen wrote:

On 1/25/21 12:04 PM, Yasha Karant wrote:
The question is:  what mechanism?  The reality today for Linux systems 
as deployed at scale mostly is SystemD.  The question -- a question 
that goes well beyond what started as an exchange about EL 8 -- is 
what goes forward?  SystemD as it currently stands is too delicate and 
too vulnerable to compromise, either within itself or in terms of the 
processes/subsystems it "controls", despite the large scale deployment 
of SystemD.  ...


This statement begs some proof (preferably a formal code audit) of the 
stated opinion that systemd is too 'delicate' and vulnerable to 
compromise.  Anecdotal evidence or counting LoC and saying 'more LoC = 
automatically more vulnerable' need not apply.  Of course, all code is 
vulnerable, but the implication is that systemd is by nature more 
vulnerable because $reason where $reason is something other than a 
formal audit.


I asked a question to which I have not seen an answer:  does a SystemD 
configuration (plain text files in the SystemD design) from two 
similar hardware platforms but different Linux distros (say, EL and 
LTS) interoperate, or require significant rewriting to produce the 
"same results"?  In other words, are the valuable concepts of 
portability and re-usability (do not reinvent the wheel, another 
engineering turn of phrase) met in practice with SystemD? 


The systemd unit files are more portable than old initscripts, in my 
experience.  The determining factors will be whether the distributions' 
engineers pick the same names for the services started by the unit file 
and if the paths to executables are the same or not.  The main 
differences here are the same as the differences in the locations of 
files between the major branches of the Linux filesystem hierarchy; 
Debian and derivatives will be different from Red Hat and derivatives, 
to pick the two top examples.


Old initscripts were and are highly dependent upon the functions sourced 
from the di

Re: Rhel 8

[Lamar Owen]

On 1/25/21 12:04 PM, Yasha Karant wrote:
The question is:  what mechanism?  The reality today for Linux systems 
as deployed at scale mostly is SystemD.  The question -- a question 
that goes well beyond what started as an exchange about EL 8 -- is 
what goes forward?  SystemD as it currently stands is too delicate and 
too vulnerable to compromise, either within itself or in terms of the 
processes/subsystems it "controls", despite the large scale deployment 
of SystemD.  ...


This statement begs some proof (preferably a formal code audit) of the 
stated opinion that systemd is too 'delicate' and vulnerable to 
compromise.  Anecdotal evidence or counting LoC and saying 'more LoC = 
automatically more vulnerable' need not apply.  Of course, all code is 
vulnerable, but the implication is that systemd is by nature more 
vulnerable because $reason where $reason is something other than a 
formal audit.


I asked a question to which I have not seen an answer:  does a SystemD 
configuration (plain text files in the SystemD design) from two 
similar hardware platforms but different Linux distros (say, EL and 
LTS) interoperate, or require significant rewriting to produce the 
"same results"?  In other words, are the valuable concepts of 
portability and re-usability (do not reinvent the wheel, another 
engineering turn of phrase) met in practice with SystemD? 


The systemd unit files are more portable than old initscripts, in my 
experience.  The determining factors will be whether the distributions' 
engineers pick the same names for the services started by the unit file 
and if the paths to executables are the same or not.  The main 
differences here are the same as the differences in the locations of 
files between the major branches of the Linux filesystem hierarchy; 
Debian and derivatives will be different from Red Hat and derivatives, 
to pick the two top examples.


Old initscripts were and are highly dependent upon the functions sourced 
from the distribution's function library for initscripts, as well as 
paths and daemon/service name; chkconfig metadata differences; and, of 
course, they are executing as root in the system shell, and shell 
quoting and escaping syntax becomes critical (the initscript for an 
autossh instance, for instance, with say a half dozen reverse tunnels; I 
have a few of those around here).  I wrote a few for PostgreSQL for use 
on several different RPM-based systems; there was quite a variety, and 
SuSE did things differently from Red Hat which did things differently 
from TurboLinux (one of the targets of my packaging), and others did 
things yet more differently.  It's possible to write initscripts to be 
very portable, but it is harder than writing a unit file that can be 
portable, as far as I can see.  But I do always reserve the right to be 
wrong.


In practice a unit file from an upstream project, especially if the 
project uses /opt/$progname or /usr/local/{bin|lib}, will be very 
portable across distributions.  This I have experienced; a single unit 
file can pretty easily be written to work across all systemd 
distributions unless it needs some distribution-specific daemon/service 
or feature.

Re: Rhel 8

[Yasha Karant]

Everything stated below is "correct", historically as well as for the 
immediate for-profit concerns of the vendors (such as IBM RH or 
Canonical).  The issues with both the (old,"deceased", pre-RBOC) ATT or 
the BSD boot, startup, etc., mechanisms are primarily that these were 
designed for a very different epoch, long before Gage coined "the 
network is the computer" became the reality (not just a slogan) at a 
scale considered science fiction at the time of the original Unix/BSD 
mechanisms, and long before large scale type 1 hypervisor deployment 
resulting in "cloud" computing.  Overwhelmingly, there is agreement that 
new mechanisms, and in some sense, algorithms, were/are needed beyond 
the original Unix or BSD mechanisms.


The question is:  what mechanism?  The reality today for Linux systems 
as deployed at scale mostly is SystemD.  The question -- a question that 
goes well beyond what started as an exchange about EL 8 -- is what goes 
forward?  SystemD as it currently stands is too delicate and too 
vulnerable to compromise, either within itself or in terms of the 
processes/subsystems it "controls", despite the large scale deployment 
of SystemD.  The reason behind this is in part driven by the monolithic 
design (and implementation) of the Linux kernel, and the symptom is 
continued SystemD intrusiveness and bloat throughout much (all?) of the 
Linux distros that have deployment at scale.  This scale is from laptops 
and workstations to large network distributed systems, even if such 
large systems are in fact deployment controlled by a non-Linux type 1 
hypervisor that instantiates Linux systems -- each such Linux system at 
some point uses SystemD.


I asked a question to which I have not seen an answer:  does a SystemD 
configuration (plain text files in the SystemD design) from two similar 
hardware platforms but different Linux distros (say, EL and LTS) 
interoperate, or require significant rewriting to produce the "same 
results"?  In other words, are the valuable concepts of portability and 
re-usability (do not reinvent the wheel, another engineering turn of 
phrase) met in practice with SystemD?




On 1/25/21 6:57 AM, Lamar Owen wrote:

On 1/24/21 10:59 AM, Mark Rousell wrote:


This is undoubtedly the case but of course it doesn't necessarily 
follow that SystemD is the correct solution. And that's where the 
controversy arises.


What is 'correct?'  (THAT is where the controversy actually lies.) The 
old engineering mantra is that 'the better is the enemy of the good 
enough;' any piece of software can always be made 'better' for various 
definitions of 'better.'  There comes a time you have to accept the 
'good enough' and get on with life; the Linux kernel is not the 
be-all-end-all but at the moment it IS 'good enough' for what it does; 
it's not going away no matter how badly kernel purists wish it would. 
There are many init systems distributions can choose from; the Wikipedia 
article on init lists them and I won't repeat the list here.


The definition of 'correct' is fluid and dynamic, changing with the 
needs of the users of the system on which the init must run, and 
subsumes far more than technical items, as things like license 
compatibility must be considered, too.  For a long time root-executable 
shell scripts were 'good enough' for 'correct' behavior; that time has 
passed.  Sun scrapped the whole mess in Solaris 10 with SMF; Canonical 
wrote Upstart for Ubuntu because old-style SysV Init was no longer 
'correct' for their use cases; Red Hat paid for the development of 
systemd because nothing was 'correct' for their desired use cases, and, 
well, Red Hat wanted their own solution.  Other distributions followed 
suit because systemd is now 'good enough' for today's 'correct' and got 
to that place before its competitors.




Difficult? That is the understatement of the decade.  I prefer to 
honestly evaluate new technologies with a bit more pragmatism; do I 
like having to learn a different way of doing things?  Not really; 
but after Debian adopted systemd I took more notice.


The thing is, one cannot wisely evaluate something on *purely* 
technical grounds because its function in reality may not be entirely 
or purely technical. Issues of politics and control of industry and/or 
mindshare are relevant too.


I never evaluate something on purely technical grounds; Debian adopting 
systemd is not a technical but a political criterion.  I do weigh 
technical merit highly, but the political fact that systemd is the 
current init system for all of the top 5 server distributions has to be 
taken into consideration.


Are there technically better init systems?  Sure; daemontools is the 
first that comes to my mind (as Nico correctly pointed out), but there 
are others.  Had djb made his license more palatable then we might all 
be griping about daemontools instead of systemd.  But that ship has sailed.


What you say in your message, especially the parts I didn't quote

Re: Rhel 8

[Lamar Owen]

On 1/24/21 10:59 AM, Mark Rousell wrote:


This is undoubtedly the case but of course it doesn't necessarily 
follow that SystemD is the correct solution. And that's where the 
controversy arises.


What is 'correct?'  (THAT is where the controversy actually lies.) The 
old engineering mantra is that 'the better is the enemy of the good 
enough;' any piece of software can always be made 'better' for various 
definitions of 'better.'  There comes a time you have to accept the 
'good enough' and get on with life; the Linux kernel is not the 
be-all-end-all but at the moment it IS 'good enough' for what it does; 
it's not going away no matter how badly kernel purists wish it would.  
There are many init systems distributions can choose from; the Wikipedia 
article on init lists them and I won't repeat the list here.


The definition of 'correct' is fluid and dynamic, changing with the 
needs of the users of the system on which the init must run, and 
subsumes far more than technical items, as things like license 
compatibility must be considered, too.  For a long time root-executable 
shell scripts were 'good enough' for 'correct' behavior; that time has 
passed.  Sun scrapped the whole mess in Solaris 10 with SMF; Canonical 
wrote Upstart for Ubuntu because old-style SysV Init was no longer 
'correct' for their use cases; Red Hat paid for the development of 
systemd because nothing was 'correct' for their desired use cases, and, 
well, Red Hat wanted their own solution.  Other distributions followed 
suit because systemd is now 'good enough' for today's 'correct' and got 
to that place before its competitors.




Difficult? That is the understatement of the decade.  I prefer to 
honestly evaluate new technologies with a bit more pragmatism; do I 
like having to learn a different way of doing things?  Not really; 
but after Debian adopted systemd I took more notice.


The thing is, one cannot wisely evaluate something on *purely* 
technical grounds because its function in reality may not be entirely 
or purely technical. Issues of politics and control of industry and/or 
mindshare are relevant too.


I never evaluate something on purely technical grounds; Debian adopting 
systemd is not a technical but a political criterion.  I do weigh 
technical merit highly, but the political fact that systemd is the 
current init system for all of the top 5 server distributions has to be 
taken into consideration.


Are there technically better init systems?  Sure; daemontools is the 
first that comes to my mind (as Nico correctly pointed out), but there 
are others.  Had djb made his license more palatable then we might all 
be griping about daemontools instead of systemd.  But that ship has sailed.


What you say in your message, especially the parts I didn't quote, is 
quite true all around; but it's unfortunately irrelevant, since systemd 
achieved critical mass once Debian adopted it and Ubuntu followed suit.  
As much as I'm not really fond of it, systemd is the current winner of 
the init war, unless something far better, with a good license, and with 
a critical mass to support it, comes along OR systemd becomes so 
obnoxious that Debian drops it (again, I use Debian as a bellwether 
simply because it's a fully openly developed system with no single 
company behind it, so no 'corporate agenda' to interfere with open 
decision-making).


One thing can be said that I'm sure everyone will agree on: systemd is 
definitely the most polarizing component of the typical Linux distribution.

Re: Rhel 8

[Yasha Karant]

Two items of possible interest on OpenRC, with a relevant excerpt therefrom:

https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_OpenRC&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=v1LZ0AOmrEFqAsVSE3_C6xv0CIWsfyumh9o1u4_GiSE&s=q44E0Ul4MkCa8w5AH0Q6bwCteiyOcbSvcqwH_J3hKW4&e= 

OpenRC is made up of several modular components, the main ones being an 
init(optional), the core dependency management system and a daemon 
supervisor(optional). It is written in C and POSIX compliant shell 
making it usable on BSD and Linux systems.


The core part of OpenRC handles dependency management and init script 
parsing. OpenRC works by scanning the runlevels, building a dependency 
graph, then starting the needed service scripts. It exits once the 
scripts have been started. By default, OpenRC uses a modified version of 
start-stop-daemon for daemon management.[10]


Init scripts share similarities with scripts used in sysvinit, but offer 
several features to simplify their creation. Scripts are assumed to have 
start(), stop() and status() and the system uses variables already 
declared to create the default functions.[11] The depend function is 
used to declare dependencies to other services that would be done with 
LSB headers in sysvinit. Configuration and mechanism are separated with 
configuration files in the conf.d directory and init files in the init.d 
directory.


Features

Portable between Linux, FreeBSD, and NetBSD
Parallel service startup (Off by default)
Dependency based boot-up
Process segregation through cgroups[15]
Per-service resource limits (ulimit)
Separation of code and configuration (init.d / conf.d)
Extensible startup scripts
Stateful init scripts (is it started already?)
Complex init scripts to start multiple components (Samba (smbd and 
nmbd), NFS (nfsd, portmap, etc.))

Automatic dependency calculation and service ordering
Modular architecture and separation of optional components (Cron, 
syslog)

Expressive and flexible network handling (including VPN, bridges, etc.)
Verbose debug mode

https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.gentoo.org_wiki_Project-3AOpenRC&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=v1LZ0AOmrEFqAsVSE3_C6xv0CIWsfyumh9o1u4_GiSE&s=BvoXUmXW55PjvDZsL8AqsEees9iYiaV5b8F8qVzyIF8&e= 

OpenRC, however, is not exclusively used by Gentoo Linux, so the goal is 
to be platform-agnostic.


On 1/24/21 10:17 PM, Nico Kadel-Garcia wrote:

On Mon, Jan 25, 2021 at 12:14 AM Benson Muite
 wrote:


On 1/24/21 9:37 PM, Nico Kadel-Garcia wrote:

On Sun, Jan 24, 2021 at 11:26 AM Serguei Mokhov  wrote:


On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  wrote:





BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
itself to support SystemD.
There may have been and, in many people's opinion, there were and are better 
init systems
to replace SysVInit than SystemD. "Better" being both a technical and a 
political/social/industrial construct.


Mark, please name the better ones. And possibly why have they not been
widely adopted?


daemontools. I publish RPM wrappers for it at


OpenRC is used in Alpine Linux, which has widespread adoption for
containers. Any thoughts on it? Busybox/Toybox also have their own init
systems.


I never had occasion to touch it.

Re: Rhel 8

[Nico Kadel-Garcia]

On Mon, Jan 25, 2021 at 12:14 AM Benson Muite
 wrote:
>
> On 1/24/21 9:37 PM, Nico Kadel-Garcia wrote:
> > On Sun, Jan 24, 2021 at 11:26 AM Serguei Mokhov  wrote:
> >>
> >> On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  
> >> wrote:
> >>>
> >>
> >>> BUT... the fact that SysVInit is seen as outdated is NOT a reason in and 
> >>> of itself to support SystemD.
> >>> There may have been and, in many people's opinion, there were and are 
> >>> better init systems
> >>> to replace SysVInit than SystemD. "Better" being both a technical and a 
> >>> political/social/industrial construct.
> >>
> >> Mark, please name the better ones. And possibly why have they not been
> >> widely adopted?
> >
> > daemontools. I publish RPM wrappers for it at
>
> OpenRC is used in Alpine Linux, which has widespread adoption for
> containers. Any thoughts on it? Busybox/Toybox also have their own init
> systems.

I never had occasion to touch it.

Re: Rhel 8

[Benson Muite]

On 1/24/21 9:37 PM, Nico Kadel-Garcia wrote:

On Sun, Jan 24, 2021 at 11:26 AM Serguei Mokhov  wrote:


On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  wrote:





BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
itself to support SystemD.
There may have been and, in many people's opinion, there were and are better 
init systems
to replace SysVInit than SystemD. "Better" being both a technical and a 
political/social/industrial construct.


Mark, please name the better ones. And possibly why have they not been
widely adopted?


daemontools. I publish RPM wrappers for it at


OpenRC is used in Alpine Linux, which has widespread adoption for 
containers. Any thoughts on it? Busybox/Toybox also have their own init 
systems.

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 18:07, Mark Rousell wrote:
> As for why less bloated (as many would see it) or over-expanded (as
> many would see it) init systems have not been more widely adopted


s/or over-expanded/or not-over-expanded/

Re: Rhel 8

[Nico Kadel-Garcia]

On Sun, Jan 24, 2021 at 11:26 AM Serguei Mokhov  wrote:
>
> On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  
> wrote:
> >
>
> > BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
> > itself to support SystemD.
> > There may have been and, in many people's opinion, there were and are 
> > better init systems
> > to replace SysVInit than SystemD. "Better" being both a technical and a 
> > political/social/industrial construct.
>
> Mark, please name the better ones. And possibly why have they not been
> widely adopted?

daemontools. I publish RPM wrappers for it at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_daemontools-2D0.76-2Dsrpm&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=LsDDsj7QA7CY_26nwxgDLTsF_n97lwVxm7knYej_yXQ&s=Rw5Lk6l-WDwuvdgWv1ul97hEkjV4y-evQ3Kbw1nbigU&e=
 : RPM . It still worked
well the lat time I tested it last year, and the author gave up on the
funky licenses and put it in the public domain some years ago. The
funky licenses were also why his djbdns and qmail software were never
very widely adopted: not everyone has the leisure to hand-compile
patches on top of source code to make our own system-compatible
versions of his software, especially because (just like systemd!) he
added new top-level directories at the top of "/" and violated the
File System Hierarchy. the FSH has since been updated to accommodate
systemd's architectural demands.

Re: Rhel 8

[Nico Kadel-Garcia]

On Fri, Jan 22, 2021 at 9:20 PM Yasha Karant  wrote:
>
> I had not heard the history of SystemD in any detail.  What, if any,
> were the software engineering and design justifications for SystemD?  I

The unreliability of SysV init scripts, especially for dependent
services, and the lack of logging for extremely low level operations
such as booting up. There have been many attempts to resolve the init
script issue: i rather liked "deamontools" by Dan J. Bernstein, but he
unfortunately had an insane licensing model that prevented anyone from
including it for years. (You could not publish binaries built from
modified code, if you wanted patches they had to be compiled by the
user, not the vendor, even if the vendor carefully published the
patches alongside the original source code.)

It's since gotten way, way out of hand, replacing the DHCP and DNS and
killing user processes when you log out, which broke "nohup" and "tux"
for interrupted SSH sessions, and killing the process without any log
or notification whatsoever "because no one would want that, they can
just edit tux if they need to. *That* one led to screaming. The
replacement of /etc/resolv.conf with a symlink pointing elsewhere led
to fracturing a lot of network configuration tools for servers. It
really is quite dangerous.

Re: Rhel 8

[Yasha Karant]

Mark Rousell's commentary is accurate and to the point.  As for "better 
ones" and the lack of competitor systems being "widely adopted" is far 
more a for-profit business decision than a decision based upon the 
abstract software engineering and performance merits of the situation. 
Despite the limitations thereof, IEEE committees and the resulting 
standards, and likewise IETF or W3C, have numerous inputs, compromises, 
and, in the case of IETF or W3C, "adopters" so that an idea can be 
implemented by the community (public funded government laboratories such 
as CERN, non-profit universities, for-profit entities, and public 
interest groups) and tested "in the crucible of experience".


The problems and issues that justify the existence of "new" approaches 
such as SystemD, are very real in terms of scaling, deployability, 
security (this is not the Arpanet of old, but rather a battleground with 
both profit and government edicts -- including "cyberwarfare" -- at 
play), and non-locality (e.g., "cloud" resources and use).  The 
solutions of either the old ATT/Unix or BSD simply were engineered for a 
very different "world" than what we face today.  However, the question 
of whether or not SystemD is a good approach is a separate one, and in 
some measure, tied into the monolithic Linux kernel.


As for competitor systems and the existence thereof, the current Linux 
situation is such than a few students taking the pedagogical Minix 
system cannot in practice develop an operational test bed for a major 
systems internals project, let alone deploy what we now know as Linux. 
Can "small" efforts develop a new programming language or a new end-user 
application?  Probably.  Simply having an "idea", even an engineered 
idea, for a systems internals utility (let alone a "boot" system) does 
not result in a production test bed -- and typically requires more 
experienced person-time than a small effort has available.


The issues mentioned about the continued bloat in SystemD are real  The 
possibility (high probability) of vulnerabilities are also real. These 
vulnerabilities particularly emerge in "cloud" deployment for which 
control of the physical hardware is subject to laws and actions of 
nation-states and entities that may not be in the interests of or 
agreement with those who use such resource (e.g., provisioning a new 
instance of a distributed supervisor set under a type 1 hypervisor using 
hardware resources in some nation).


In practice, does the community really need something "better" than 
SystemD?  Probably.  Will this be achievable in practice?  Even FSF/GNU 
could not in practice achieve wide scale deployment of Hurd -- or this 
discussion would be rather different.  Thus, without some concerted 
resources (read:  equipment, experienced knowledgeable personnel, and 
real world test beds), SystemD will be with us.  Hopefully, it can be 
modified (evolve) to address the issues that have been raised in this 
exchange, but I for one am not holding my breath.


On 1/24/21 8:26 AM, Serguei Mokhov wrote:

On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  wrote:





BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
itself to support SystemD.
There may have been and, in many people's opinion, there were and are better 
init systems
to replace SysVInit than SystemD. "Better" being both a technical and a 
political/social/industrial construct.


Mark, please name the better ones. And possibly why have they not been
widely adopted?

(PS: Lamar, appreciate as always your PostgreSQL contributions and its
package management.)

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 16:26, Serguei Mokhov wrote:
> On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  
> wrote:
>> BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
>> itself to support SystemD.
>> There may have been and, in many people's opinion, there were and are better 
>> init systems
>> to replace SysVInit than SystemD. "Better" being both a technical and a 
>> political/social/industrial construct.
> Mark, please name the better ones. And possibly why have they not been
> widely adopted?

Hehe, as I said before, I claim nothing and merely report common views.

On that basis, I will note that many people take the view that there are
numerous init systems available that have the key benefit, in their
view, of *not* trying to be vastly more than an init system really needs
to be.

As for why less bloated (as many would see it) or over-expanded (as many
would see it) init systems have not been more widely adopted, one can
only observe that there are many possible reasons for this and technical
ones, whilst certainly amongst them, are not necessarily the only ones.
As I say, one must evaluate contentious systems not only in a purely
technical light but in a political, social and industrial context too.

Re: Rhel 8

[Serguei Mokhov]

On Sun, Jan 24, 2021 at 11:00 AM Mark Rousell  wrote:
>

> BUT... the fact that SysVInit is seen as outdated is NOT a reason in and of 
> itself to support SystemD.
> There may have been and, in many people's opinion, there were and are better 
> init systems
> to replace SysVInit than SystemD. "Better" being both a technical and a 
> political/social/industrial construct.

Mark, please name the better ones. And possibly why have they not been
widely adopted?

(PS: Lamar, appreciate as always your PostgreSQL contributions and its
package management.)

-- 
Serguei Mokhov

Re: Rhel 8

[Mark Rousell]

On 24/01/2021 02:52, Lamar Owen wrote:
> Straight SysV init does not meet the needs of many server setups,
> especially server setups that need to dynamically change the daemon
> mix that is currently running.  Virtualization hosts, software-defined
> networking setups, and what is typically called 'cloud' services are
> use cases for things systemd does well.  The antiquated concept of
> runlevels works fine for relatively static workloads; not so much for
> more dynamic workloads on the server side.

This is undoubtedly the case but of course it doesn't necessarily follow
that SystemD is the correct solution. And that's where the controversy
arises.

> Difficult?  That is the understatement of the decade.  I prefer to
> honestly evaluate new technologies with a bit more pragmatism; do I
> like having to learn a different way of doing things?  Not really; but
> after Debian adopted systemd I took more notice.

The thing is, one cannot wisely evaluate something on *purely* technical
grounds because its function in reality may not be entirely or purely
technical. Issues of politics and control of industry and/or mindshare
are relevant too.

And, even on purely technical grounds, one of the key criticism of
SystemD is *NOT* the need to learn something new; the criticism is about
how SystemD is structured and its ongoing bloat and growth. Learning new
stuff is part and parcel of working in any capacity with computers and I
have seen no one seriously complain about learning anything new in
relation to SystemD. It is what they have learned that has concerned
them and led them to be critical.

> but the potential vulnerability footprint is much smaller

To say the least: This is a view that is not necessarily globally
shared. ;-)

It's different, sure. But not necessarily smaller and not necessarily
more visible, more manageable, more identifiable, or more fixable.

> But even then virtually every systemd installation will happily run a
> SysVInit-style initscript (and will log to /var/messages in plain
> text), just like Upstart before did in EL 6 (well enough that people
> forget that EL 6 didn't run a straight SysV Init anymore).

As ever, the fact that SystemD can run SysV scripts is not the problem
and does not solve its problems as many people see it.

It is the structure and overall design of SystemD (and, in many people's
views, its political/social/industrial context) that are the problems
that many people see with SystemD.

Very few people mind a new init system. That's why people seem to have
forgotten about Upstart. What people clearly do mind is how a certain
init system is designed and implemented and how it seems to be growing
beyond being an init system.

In other words, SystemD specifically is the problem as many people see
it, *not* new init systems in general.

> SysV Init was a substantial upgrade from what came before (I remember
> those days, running Xenix V7 and System III), but in today's
> containerized, virtualized, dynamic server world it simply isn't
> sufficient for a large enough percentage of real-world server workloads.

Sure. I think it safe to say that the majority of those who are critical
of SystemD would not disagree with you on this.

BUT... the fact that SysVInit is seen as outdated is NOT a reason in and
of itself to support SystemD. There may have been and, in many people's
opinion, there were and are better init systems to replace SysVInit than
SystemD. "Better" being both a technical and a
political/social/industrial construct.

Re: Rhel 8

[Lamar Owen]

On 1/23/21 8:27 AM, Mark Rousell wrote:


As I understand it the initial impetus for SystemD (as with all the 
other competing init systems) was the perception that SysVInit was/is 
obsolete or not suitable for modern life. One of SystemD's claimed 
advantages over SysV was faster booting. However, in my experience 
similarly specced SysV machines seem to boot faster!


The systemd init system didn't directly replace real SysVInit; in RHEL 6 
Upstart was used as the init.  I've used systems from before SysVInit, 
where the init system was rc.local (and not much more than just rc.local).


Straight SysV init does not meet the needs of many server setups, 
especially server setups that need to dynamically change the daemon mix 
that is currently running.  Virtualization hosts, software-defined 
networking setups, and what is typically called 'cloud' services are use 
cases for things systemd does well.  The antiquated concept of runlevels 
works fine for relatively static workloads; not so much for more dynamic 
workloads on the server side.


It's difficult to say anything about SystemD without it becoming 
political/religious but my impression is that the bloat and mission 
creep that SystemD seems in many people's views to suffer from (i.e. 
it is no longer just an init system) is perhaps less about "software 
engineering and design justifications" and perhaps more about 
mindshare grab and ecosystem control. I claim nothing; I merely report 
common views. ;-)




Difficult?  That is the understatement of the decade.  I prefer to 
honestly evaluate new technologies with a bit more pragmatism; do I like 
having to learn a different way of doing things?  Not really; but after 
Debian adopted systemd I took more notice.


In my opinion, the single greatest advantage of systemd is that the 
files that define how the system starts up are no longer executable 
shell scripts that typically run as root.  I maintained some of those 
shell scripts for a major open source database's RPM package several 
years ago, and the fact that the scripts I wrote that very few admins 
ever looked at and checked up on were running as root on thousands upon 
thousands of machines well, there are better security models in the 
world.  Oh, the database was PostgreSQL, by the way.  The systemd init 
itself is larger than the Upstart init (for EL 6.x) or SysV Init (EL 5 
and previous), but the potential vulnerability footprint is much 
smaller; instead of having to audit thousands of initscripts that ALL 
get to run as root you audit one package or set of packages.


But even then virtually every systemd installation will happily run a 
SysVInit-style initscript (and will log to /var/messages in plain text), 
just like Upstart before did in EL 6 (well enough that people forget 
that EL 6 didn't run a straight SysV Init anymore).


SysV Init was a substantial upgrade from what came before (I remember 
those days, running Xenix V7 and System III), but in today's 
containerized, virtualized, dynamic server world it simply isn't 
sufficient for a large enough percentage of real-world server workloads.

Re: Rhel 8

[~Stack~]

On 1/23/21 6:59 PM, Yasha Karant wrote:
Does in fact SystemD provide for encapsulation and isolation, as in a 
proper OO design and implementation?  Could not a "proper" sysadmin 
interface be constructed to configure SystemD, rather than the 
"hodgepodge" of what seem to many as arbitrary and capricious 
incantations?  These questions are not posed as divisive or derisive, 
but instead requesting information.


Hrm. That's an interesting question. I may need to think about that more.

My initial response is that it could be tweaked to allow that to a 
point. I can configure $application1 to be set into a kernel cgroup such 
that I can constrain it and isolate it in terms of both resources and 
things it can talk to. However, there are still some level of kernel, 
cpu, memory, disk, logging requirements that will require $application1 
to interact with the low level services.


However, when I think about how various services work then there needs 
to be a lot of communication between applications. For instance, I've 
got a bunch of machines at work that use the big Nvidia GPU's. One of 
our researchers has code he's developing that sometimes will dead-lock 
the GPU's. The only way we've been able to get it unstuck is a reboot. 
And because we have had issues with the bleeding-edge development NVidia 
drivers, we've found that it's best to purge the drivers on shutdown, 
then reinstall fresh. Well, I don't want to do that manually. So when I 
tell a system to reboot, I wrote systemd code to ensure that the driver 
is purged before shutdown.


When the server starts, my systemd code checks for nvidia. If it is 
there (a power or hard reset didn't run the code on shutdown), then it 
yanks the driver and reboots. When it starts up and it isn't there, it 
waits on network. Then it waits for DNS services. Then it fetches the 
latest driver in our repo. Then it builds the driver and installs it. 
Then it verifies the driver is successful in loading the GPU. Only then 
does it finish the boot process.


In that one systemd script alone, I'm talking to a half dozen services, 
the kernel, and hardware. Could I shove all of that into hard isolation 
and encapsulation? Um...I'm not sure. There has to be a communication 
layer that breaks that isolation somewhere.


Could I do that without systemd? Absolutely. I did similar stuff like 
that long before systemd with scripts that were WAY longer and WAY 
gnarlier because I had to write all the test cases for failure and 
waiting myself instead of just telling systemd "Hey, let me know when 
this service is working."


And that's just not even talking about Desktop... When you get into the 
fancy notifications that you've received an email, or the music changed 
to a new track, or that there was a security alert, or that you have 
packages to be updated, or yadda yadda yadda the list goes on when you 
talk about Desktop level notifications. Everything that the UI has to do 
for all those fancy shiny integrations... I don't think it really could 
be isolated. Although if you allow for systemd to handle all 
communication then isolate the rest then yeah...that's kinda the point. :-)


Maybe someone who still gets down into the internals regularly might be 
able to answer better and more clearly then I did. Hopefully I didn't 
ramble too much! :-D


Oh, also. To your point about a better language choice potentially 
solving some of these issues (I snipped it). I will say it's been ~15 
years since I last did anything with language theory. I'm not someone 
who can really argue for or against these things. However, I do know 
that part of the drive for people to write more Rust code in the Linux 
kernel itself is to use Rusts type safety / memory clean up / ect as a 
measure against some of the issues that have occurred because of the C 
foundation. I'm not arguing for or against, just saying that this 
conversation is on going. Similar for Go, but ohh...I've got some love 
and hate for Go and will spare you that rambling rant! :-D


~Stack~

Re: Rhel 8

[Yasha Karant]

Your commentary -- from a direct participant, not just an observer -- is 
very informative.  It also illustrates fundamental flaws in software 
engineering and design from a monolithic system that did not even obey 
structured language software design, let alone anything akin to the 
object oriented paradigm.  Had there been proper isolation and 
encapsulation, possibly difficult in a monolith as contrasted with a 
micro-kernel design, most (all?) of the internals developers and 
implementors difficulties you describe could have been avoided.  I am 
aware of the issues of "ravioli" design and implementation within OO, 
much the same as "spaghetti" within structured non-OO, and even worse 
within unstructured "go to", so simply using OO is not a panacea per se. 
 All of this assumes an imperative language base (such as C++) that is 
for a classical (not quantum) platform, including a classical concurrent 
platform of any concurrent architecture.


Does in fact SystemD provide for encapsulation and isolation, as in a 
proper OO design and implementation?  Could not a "proper" sysadmin 
interface be constructed to configure SystemD, rather than the 
"hodgepodge" of what seem to many as arbitrary and capricious 
incantations?  These questions are not posed as divisive or derisive, 
but instead requesting information.


On 1/23/21 4:41 PM, ~Stack~ wrote:

On 1/22/21 8:20 PM, Yasha Karant wrote:
I had not heard the history of SystemD in any detail.  What, if any, 
were the software engineering and design justifications for SystemD?


TL;DR synopsis. It's just a tool. A tool that solves a very common and 
VERY painful problem for people who build Linux based OS's. And those 
developers made the decision. Not the users who, honestly, most of the 
time don't have a clue about the pain the developers face. It isn't 
perfect, and it causes problems sometimes in the user space. But it 
isn't a tool for the users.



I was incredibly active in the Debian community for a number of years 
leading up to the SystemD fiasco. You can still find my posts going back 
as far as 2002 on the Debian mailing list. The vast majority of my posts 
are still publicly accessible (so if you really doubt what I say below, 
you can go find my emails on the Debian archives). :-)


Most of my issues regarding SystemD are political, not technical. Though 
I've had a number of technical problems over the years and I've filed 
bug reports to get most of them fixed - technical is usually the easiest 
to fix.


One thing people tend to overlook in these conversations is that systemd 
was clearly not meant to help SysAdmins - the fact that does is a by 
product. The point was to help system builders and integrators. EG: the 
people building the distro that others use; the ones who try to make all 
of the sub-services play nice with each other so that the end user can 
just click around on a mouse.


You can think of SystemD as the the low level communication of services 
that not a whole lot of people (developers nor users) want to do but 
everyone who uses a desktop or server depends on to work- it's at the 
integrator level where SystemD starts to shine. It helps a lot of the 
underpinning communications where most users don't ever dare to tread. 
Those dark tunnels where experienced SysAdmins have their eyes gloss 
over at the dread they encountered upon their last traversal.

Those places.

By the time you get up to the level where SysAdmins work or even higher 
where the users work, most of the time SystemD is just a tool to use. 
How you use it and how much you invest in learning it is up to you. But 
if you are using a spanner as a hammer because you don't want to learn 
how to use a hammer, well...good luck, but you are going to have problems.


"So it's just another tool for services to communicate?"
Essentially, yes.

"Why all the hate?"
Two reasons:

1) Technical:
Because getting all the services to talk to one another is incredibly 
difficult. Speaking as someone who used to do a bunch of dbus level 
programming to get services to talk to each other, the old InitV methods 
sucked. It was painful. And every time there was a new service that did 
things differently, it made my work harder. I particularly recall in 
~2008 tracing out an issue with a kernel notification to a network card 
that caused Pidgin to flip out and spam the dbus to the point of 
crashing other completely unrelated services because of a custom 
plugin...gah...I was down reading hex code off the kernel processes to 
figure that out...and it still gives me 
wake-up-screaming-nightmares...But all the users knew was that their 
music player would cause a kernel panic - they had no idea it was even a 
plugin on Pidgin that was doing it because why would Pidgin (a chat 
program ) care if a music file was played? And what did that have to do 
with crashing the kernel?


THAT'S the low level communication I'm talking about here. The stuff so 
far behind the scenes that the 

Re: Rhel 8

[~Stack~]

On 1/22/21 8:20 PM, Yasha Karant wrote:
I had not heard the history of SystemD in any detail.  What, if any, 
were the software engineering and design justifications for SystemD?


TL;DR synopsis. It's just a tool. A tool that solves a very common and 
VERY painful problem for people who build Linux based OS's. And those 
developers made the decision. Not the users who, honestly, most of the 
time don't have a clue about the pain the developers face. It isn't 
perfect, and it causes problems sometimes in the user space. But it 
isn't a tool for the users.



I was incredibly active in the Debian community for a number of years 
leading up to the SystemD fiasco. You can still find my posts going back 
as far as 2002 on the Debian mailing list. The vast majority of my posts 
are still publicly accessible (so if you really doubt what I say below, 
you can go find my emails on the Debian archives). :-)


Most of my issues regarding SystemD are political, not technical. Though 
I've had a number of technical problems over the years and I've filed 
bug reports to get most of them fixed - technical is usually the easiest 
to fix.


One thing people tend to overlook in these conversations is that systemd 
was clearly not meant to help SysAdmins - the fact that does is a by 
product. The point was to help system builders and integrators. EG: the 
people building the distro that others use; the ones who try to make all 
of the sub-services play nice with each other so that the end user can 
just click around on a mouse.


You can think of SystemD as the the low level communication of services 
that not a whole lot of people (developers nor users) want to do but 
everyone who uses a desktop or server depends on to work- it's at the 
integrator level where SystemD starts to shine. It helps a lot of the 
underpinning communications where most users don't ever dare to tread. 
Those dark tunnels where experienced SysAdmins have their eyes gloss 
over at the dread they encountered upon their last traversal.

Those places.

By the time you get up to the level where SysAdmins work or even higher 
where the users work, most of the time SystemD is just a tool to use. 
How you use it and how much you invest in learning it is up to you. But 
if you are using a spanner as a hammer because you don't want to learn 
how to use a hammer, well...good luck, but you are going to have problems.


"So it's just another tool for services to communicate?"
Essentially, yes.

"Why all the hate?"
Two reasons:

1) Technical:
Because getting all the services to talk to one another is incredibly 
difficult. Speaking as someone who used to do a bunch of dbus level 
programming to get services to talk to each other, the old InitV methods 
sucked. It was painful. And every time there was a new service that did 
things differently, it made my work harder. I particularly recall in 
~2008 tracing out an issue with a kernel notification to a network card 
that caused Pidgin to flip out and spam the dbus to the point of 
crashing other completely unrelated services because of a custom 
plugin...gah...I was down reading hex code off the kernel processes to 
figure that out...and it still gives me 
wake-up-screaming-nightmares...But all the users knew was that their 
music player would cause a kernel panic - they had no idea it was even a 
plugin on Pidgin that was doing it because why would Pidgin (a chat 
program ) care if a music file was played? And what did that have to do 
with crashing the kernel?


THAT'S the low level communication I'm talking about here. The stuff so 
far behind the scenes that the users don't even know nor care it happens.


This is simplifying it quite a bit, but if you think about SystemD as a 
single API every program can use to communicate you get the gist of it. 
But that API is MONSTER and its growing. So some of us old-school *nix 
guys who have a hard time breaking the mentality of "One simple program 
to do one simple task" struggle with something like SystemD.


The analogy I used is that for me trying to get these services to talk 
to each other before was like herding cats. They don't want to listen, 
they want to do their own thing, and by the end of the day I'm tired, 
cut, and bloody. However, the alternative is the Marshmallow man from 
Ghostbusters - one incredibly large and growing gooie monster...


MANY MANY developers who work on the underpinnings that I know prefer to 
fight the one monster they can sort-of-deal-with vs herding cats.


2) Political:
The fiasco was handled badly. Distro developers made the choice, not the 
users. Distro developers failed regularly to explain why they made the 
choice and often either attempted some detailed technical drivel the 
users didn't understand or told them to "shut up or leave".


The reason why I left the Debian community was because of the vitriol 
aimed at those of us caught in the middle. Then when it started to get 
crazy, they got ban-hammer-happy. I got ban

Re: Rhel 8

[Miles ONeal]

The concurrency argument was always absurd. It could easily gave been added to 
SysVInit.

Get Outlook for 
iOS<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_o0ukef&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=oepUUNcyXR2cVbSTpfryfDdkTrmRQswTFIL8nV5kiSY&s=3-J96CJzkgWx4q1oPlrYGAQSahQXJeIrofaOls-VAeY&e=
 >

From: owner-scientific-linux-us...@listserv.fnal.gov 
 on behalf of Yasha Karant 

Sent: Saturday, January 23, 2021 5:06:43 PM
To: Mailing list for Scientific Linux users worldwide 

Subject: Re: Rhel 8

Caution:  EXTERNAL email

 From what I recall of the discussions leading up to SystemD in the
general deployment that seems to be the current reality, one reason was
to not only use "concurrency" at boot, but to standardise across distros
and thus simplify use in "operating systems as a service" in "cloud
computing".  If I have the time, I will attempt to find the reference to
that point; I do recall the argument being made in an in-person
professional CSE seminar (not general public nor IT) at my institution.
Given the current complexity of SystemD, it is not clear that the
argument of "simplicity" (or even "uniformity" amongst distros) has been
realised.  As a direct question to this point:  are the SystemD
configuration files and effects thereof the same between, say, SL
current and Ubuntu LTS current?  That is, are the configuration files
for the same utilities and capabilities the same between these two
distros?

 From the Wikipedia item:

https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Systemd&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=-owMAqaRiHssZ2E8bRQ52jY6jO3f6qT3hQIGJQgcS00&s=0alOePGrgE5HP3suK_pMxiUvrdZyI2V4UTg5k4CC20g&e=

The design of systemd has ignited controversy within the free-software
community. Critics regard systemd as overly complex and suffering from
continued feature creep, arguing that its architecture violates the Unix
philosophy. There is also concern that it forms a system of interlocked
dependencies, thereby giving distribution maintainers little choice but
to adopt systemd as more user-space software comes to depend on its
components.[91]Vaughan-Nichols, Steven (19 September 2014). "Linus
Torvalds and others on Linux's systemd". ZDNet. CBS Interactive.

On 1/23/21 2:47 PM, Patrick J. LoPresti wrote:
> On Sat, Jan 23, 2021 at 5:28 AM Mark Rousell  <mailto:markrlon...@hotmail.co.uk>> wrote:
>  >
>  >
>  > It's difficult to say anything about SystemD without it becoming
> political/religious but my impression is that the bloat and mission
> creep that SystemD seems in many people's views to suffer from (i.e. it
> is no longer just an init system) is perhaps less about "software
> engineering and design justifications" and perhaps more about mindshare
> grab and ecosystem control. I claim nothing; I merely report common
> views. ;-)
>
> This is missing the point. There is precisely nothing any system with
> systemd does that they could not do before systemd existed. Maybe they
> boot a few seconds faster, every year or two when they do reboot? Ha ha.
>
> systemd is the purest example ever of "change for the sake of change".
> It solves literally zero problems while introducing several. All cost +
> no benefit = idiotic.

Re: Rhel 8

[Yasha Karant]

From what I recall of the discussions leading up to SystemD in the 
general deployment that seems to be the current reality, one reason was 
to not only use "concurrency" at boot, but to standardise across distros 
and thus simplify use in "operating systems as a service" in "cloud 
computing".  If I have the time, I will attempt to find the reference to 
that point; I do recall the argument being made in an in-person 
professional CSE seminar (not general public nor IT) at my institution. 
Given the current complexity of SystemD, it is not clear that the 
argument of "simplicity" (or even "uniformity" amongst distros) has been 
realised.  As a direct question to this point:  are the SystemD 
configuration files and effects thereof the same between, say, SL 
current and Ubuntu LTS current?  That is, are the configuration files 
for the same utilities and capabilities the same between these two 
distros?


From the Wikipedia item:

https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Systemd&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=-owMAqaRiHssZ2E8bRQ52jY6jO3f6qT3hQIGJQgcS00&s=0alOePGrgE5HP3suK_pMxiUvrdZyI2V4UTg5k4CC20g&e= 

The design of systemd has ignited controversy within the free-software 
community. Critics regard systemd as overly complex and suffering from 
continued feature creep, arguing that its architecture violates the Unix 
philosophy. There is also concern that it forms a system of interlocked 
dependencies, thereby giving distribution maintainers little choice but 
to adopt systemd as more user-space software comes to depend on its 
components.[91]Vaughan-Nichols, Steven (19 September 2014). "Linus 
Torvalds and others on Linux's systemd". ZDNet. CBS Interactive.


On 1/23/21 2:47 PM, Patrick J. LoPresti wrote:
On Sat, Jan 23, 2021 at 5:28 AM Mark Rousell > wrote:

 >
 >
 > It's difficult to say anything about SystemD without it becoming 
political/religious but my impression is that the bloat and mission 
creep that SystemD seems in many people's views to suffer from (i.e. it 
is no longer just an init system) is perhaps less about "software 
engineering and design justifications" and perhaps more about mindshare 
grab and ecosystem control. I claim nothing; I merely report common 
views. ;-)


This is missing the point. There is precisely nothing any system with 
systemd does that they could not do before systemd existed. Maybe they 
boot a few seconds faster, every year or two when they do reboot? Ha ha.


systemd is the purest example ever of "change for the sake of change". 
It solves literally zero problems while introducing several. All cost + 
no benefit = idiotic.

Re: Rhel 8

[Patrick J. LoPresti]

On Sat, Jan 23, 2021 at 5:28 AM Mark Rousell 
wrote:
>
>
> It's difficult to say anything about SystemD without it becoming
political/religious but my impression is that the bloat and mission creep
that SystemD seems in many people's views to suffer from (i.e. it is no
longer just an init system) is perhaps less about "software engineering and
design justifications" and perhaps more about mindshare grab and ecosystem
control. I claim nothing; I merely report common views. ;-)

This is missing the point. There is precisely nothing any system with
systemd does that they could not do before systemd existed. Maybe they boot
a few seconds faster, every year or two when they do reboot? Ha ha.

systemd is the purest example ever of "change for the sake of change". It
solves literally zero problems while introducing several. All cost + no
benefit = idiotic.

Re: Rhel 8

[Mark Rousell]

On 23/01/2021 02:20, Yasha Karant wrote:
> I had not heard the history of SystemD in any detail.  What, if any,
> were the software engineering and design justifications for SystemD? 
> I recall some vague mentions of "designs for the future"

Have a look at the SystemD Wikipedia entry which links to the SystemD
home page.

As I understand it the initial impetus for SystemD (as with all the
other competing init systems) was the perception that SysVInit was/is
obsolete or not suitable for modern life. One of SystemD's claimed
advantages over SysV was faster booting. However, in my experience
similarly specced SysV machines seem to boot faster!

It's difficult to say anything about SystemD without it becoming
political/religious but my impression is that the bloat and mission
creep that SystemD seems in many people's views to suffer from (i.e. it
is no longer just an init system) is perhaps less about "software
engineering and design justifications" and perhaps more about mindshare
grab and ecosystem control. I claim nothing; I merely report common
views. ;-)

Re: Rhel 8

[Orion Poplawski]

I'm sure there are plenty of documents on the web to explain the design 
goals and motivations of SystemD.  I for one very much appreciate many 
aspects of it - it vastly improves the control and introspection 
possible of a system.  But I try to avoid religious arguments on either 
side of this debate.


On 1/22/21 7:20 PM, Yasha Karant wrote:
I had not heard the history of SystemD in any detail.  What, if any, 
were the software engineering and design justifications for SystemD?  I 
recall some vague mentions of "designs for the future" (evidently 
including deployment under distributed wide area network type 1 
hypervisors, and the general issues of distributed wide area network 
"cloud computing" as a "service") or some such, but in practical terms, 
I did not understand the need for the massive changes and 
reconfigurations necessitated by the continued SystemD intrusive 
deployment.  By comparison, to me this is not the same as the Tomasulo 
algorithm and reservation stations that are now commonplace on many 
general purpose CPU architectures and that met (and meets) a real need.


On 1/22/21 5:20 PM, Patrick J. LoPresti wrote:
On Fri, Jan 22, 2021 at 4:01 PM Yasha Karant > wrote:

 >
 > Was Torvalds behind SystemD, etc.?  Just curious.

Are you joking?

systemd is the creation of Red Hat employee (and professional idiot) 
Lennart Poettering. Worst thing that ever happened to Linux.






--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Rhel 8

[Yasha Karant]

I had not heard the history of SystemD in any detail.  What, if any, 
were the software engineering and design justifications for SystemD?  I 
recall some vague mentions of "designs for the future" (evidently 
including deployment under distributed wide area network type 1 
hypervisors, and the general issues of distributed wide area network 
"cloud computing" as a "service") or some such, but in practical terms, 
I did not understand the need for the massive changes and 
reconfigurations necessitated by the continued SystemD intrusive 
deployment.  By comparison, to me this is not the same as the Tomasulo 
algorithm and reservation stations that are now commonplace on many 
general purpose CPU architectures and that met (and meets) a real need.


On 1/22/21 5:20 PM, Patrick J. LoPresti wrote:
On Fri, Jan 22, 2021 at 4:01 PM Yasha Karant > wrote:

 >
 > Was Torvalds behind SystemD, etc.?  Just curious.

Are you joking?

systemd is the creation of Red Hat employee (and professional idiot) 
Lennart Poettering. Worst thing that ever happened to Linux.

Re: Rhel 8

[Patrick J. LoPresti]

On Fri, Jan 22, 2021 at 4:01 PM Yasha Karant  wrote:
>
> Was Torvalds behind SystemD, etc.?  Just curious.

Are you joking?

systemd is the creation of Red Hat employee (and professional idiot)
Lennart Poettering. Worst thing that ever happened to Linux.

Re: [SCIENTIFIC-LINUX-USERS] Rhel 8

[Jose Marques]

> On 22 Jan 2021, at 16:30, Larry Linder 
> <0dea520dd180-dmarc-requ...@listserv.fnal.gov> wrote:
> 
> So that leaves the Mac, Win 10, and maybe BSD which is under the hood of a 
> Mac.

As a Mac user (managing Linux) I would say that you really don't want to be 
considering macOS if long term stability is your goal. The OS is on a yearly 
release cycle with major breaking changes each year (10.14 to 10.15 dropped 
32-bit support for example). This year the hardware architecture changed from 
Intel to Apple Silicon (ARM). Intel Macs will probably stop being made in one 
or two years. Intel software runs in translation but that will probably be 
removed a few years later. Under the hood macOS uses Mach and the user land was 
based on BSD. It's still unix(TM) but Apple prefers developers to use its APIs 
and its programming language (Swift) for GUI apps. The way Macs are managed has 
changed completely to a mobile device model with MDM servers and enrolment 
programs. Apple expects developers and admins to keep up. Old style developers 
that take half a year to "certify" an OS release before they support it are 
going to have real problems. As a user I love the new hardware, as an admin I'm 
happy to let somebody else manage the Macs at work.

Centos8 does exactly what RedHat and IBM want it to do, i.e. providing hybrid 
cloud tools and a Linux distribution IBM can use in its cloud offerings, and a 
platform for running Linux workloads on mainframes. That's where IBM sees its 
future.

My own opinions and not that of my employer etc.

The University of St Andrews is a charity registered in Scotland, No. SC013532.

Re: Rhel 8

[Mark Rousell]

For what it's worth, Debian (with SystemD) has a LTS version:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.debian.org_lts_&d=DwIDaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=i5ehAuGzumUursAzQvltYnLOsvm3z8pbqtb3U8UKd9Q&s=Ga1isLA9_dB_btXvMDqKyniiS3Karm8DKd1M5SCVRCc&e=
 . And there is Oracle Linux as well, of
course, which is definitely intended for enterprise use (yes, I know
it's a rebuild of RHEL, with optional additions, but I include here it
for completeness).

But this begs the question of "what *really* is an 'enterprise' distro?".

To my mind it's less about about having "enterprise" in the name or in
the marketing and more about whether or not you feel you can trust it in
your particular enterprise. As such, Debian and Devuan (even though the
Devuan team is very small) definitely qualify for "enterprise" use  in
my opinion. They are reliable, trustworthy distros that many people run
their businesses on.

If they move more quickly in terms of kernel, libraries, etc. than the
likes of RHEL and its rebuilds then that is not necessarily a bad thing.
The software world as a whole is moving much more quickly than it used
to and RHEL's long term stability is not necessarily the advantage that
it might once have been. It really does depend on your specific use case
and enterprise, technical or business needs. I state the obvious when I
say, for example, that a HPC cluster's longer term stability needs are
probably very different to a web server's long term stability needs. And
yet both use cases need a good distro that one can rely on. It doesn't
necessarily have to have "enterprise" in the name, though.

> Was Torvalds behind SystemD, etc.?  Just curious.

No, he was not! He has been critical of it in the past, as I recall.

SystemD is a Red Hat project and the original author was the
controversial figure of Lennart Poettering.

SystemD's continued seeming mission creep causes a great many people to
be very suspicious of it. (Which is just about the understatement of the
Century so far. ;-) ).



On 23/01/2021 00:01, Yasha Karant wrote:
> My understanding is that only SuSE, Red Hat, and Ubuntu produce open
> systems ("free to port" with attribution and removal of copyrighted
> logo intellectual property) "enterprise" distros -- and all of these
> in current production release use SystemD, etc., baggage.  Was
> Torvalds behind SystemD, etc.?  Just curious.
>
> On 1/22/21 3:55 PM, Mark Rousell wrote:
>> On 22/01/2021 16:30, Larry Linder wrote:
>>> My only wish is that the SL community start a New Linux based on SL 6.9
>>> and erase all the needless junk added to SL 7.5.   Mainly dump the
>>> systemctl crap.   If only expands the number of characters I need to
>>> type to get it done and contributes nothing to operational efficiency -
>>> more bloat ware.
>>
>> This is in Debian too.
>>
>> If you want a Debian without SystemD then check out Devuan.
>>
> .

Re: Rhel 8

[Yasha Karant]

My understanding is that only SuSE, Red Hat, and Ubuntu produce open 
systems ("free to port" with attribution and removal of copyrighted logo 
intellectual property) "enterprise" distros -- and all of these in 
current production release use SystemD, etc., baggage.  Was Torvalds 
behind SystemD, etc.?  Just curious.


On 1/22/21 3:55 PM, Mark Rousell wrote:

On 22/01/2021 16:30, Larry Linder wrote:

My only wish is that the SL community start a New Linux based on SL 6.9
and erase all the needless junk added to SL 7.5.   Mainly dump the
systemctl crap.   If only expands the number of characters I need to
type to get it done and contributes nothing to operational efficiency -
more bloat ware.


This is in Debian too.

If you want a Debian without SystemD then check out Devuan.

Re: Rhel 8

[Mark Rousell]

On 22/01/2021 16:30, Larry Linder wrote:
> My only wish is that the SL community start a New Linux based on SL 6.9
> and erase all the needless junk added to SL 7.5.   Mainly dump the
> systemctl crap.   If only expands the number of characters I need to
> type to get it done and contributes nothing to operational efficiency -
> more bloat ware.

This is in Debian too.

If you want a Debian without SystemD then check out Devuan.

Re: Rhel 8

[~Stack~]

On 1/22/21 10:30 AM, Larry Linder wrote:

We are evaluating Debian at the moment   Since it is a RH derivative we
shall see.


I don't know if this is a typo or not...But Debian is not and never has 
been a derivative of Red Hat. If memory serves correct Debian officially 
kicked off in 1993 almost a year before Red Hat's first 1994 Halloween 
release. While there is and has been overlap in open source packages and 
tools, they are firmly two very distinct Linux sub-families.


Maybe you meant you were evaluating Rocky as a derivative of Red Hat or 
evaluating Debian as an alternative to Red Hat


~Stack~

Rhel 8

[Larry Linder]

After evaluating Cent 8 for a few months - 
The bottom line is that we could not run our linux based cad programs
and it did not have the C shell that a lot of our utilities were written
in.

We decided to can it.  Computer words - low level format the disk.

So why would I even consider downloading a free RHEL 8 that is more of
the same rubish. ? different label.

Face it RH laid a big Egg and it is very evident that the management
never tried to use it and evaluate it or it would never have been
released.

We upgraded our SL 7.6 to SL 7.9 and our internet connection died.  You
unplug the cable and plug it back in and you see the two lights flicker
for a second and they are turned OFF.  The connection icon says its ON.
but it is not.  Back dated our systems to SL 7.6.   RH also changed EthO
to more jiberish that is difficult to remember.

So effectively SL 7.6 is the end of the road.

We are evaluating Debian at the moment   Since it is a RH derivative we
shall see.

Appreciate the communications - both good and bad.
Sometimes I like to toss a rock into the pond and observe the ripples.

My only wish is that the SL community start a New Linux based on SL 6.9
and erase all the needless junk added to SL 7.5.   Mainly dump the
systemctl crap.   If only expands the number of characters I need to
type to get it done and contributes nothing to operational efficiency -
more bloat ware.

I use VariCad 2D and 3D for drawing to run our 3D printer and CNC
desktop mill to make real parts.  The new version of VariCAD has a Clib
problem and can't find 12 and 17.  The real sad part of it is that the
Clib 23 does not contain all the previous lib versions.  So we had to
forgo our latest update we paid for and can't use.
Makes one want to sign up for Windows 10 another prize piece of
work. :=(  

With RH effectively out of the picture we can not expect developers to
invest in and support Linux applications with out a prime time OS
supporter for stability.   The labs provided the long term stability.

So that leaves the Mac, Win 10, and maybe BSD which is under the hood of
a Mac.

A dark day in the OS world.

Larry Linder