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
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
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
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 "failu
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
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 start
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
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. Hav
e
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
b
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 bui
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 synta
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"
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 stan
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
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 t
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_C6xv0CIWsfyumh9o
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
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 man
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/
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 wer
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
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 li
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
>> ini
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. "Be
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
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
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 cap
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 oriente
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 Lin
ientific 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
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
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) i
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
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 de
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 gen
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.
> 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
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_btX
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, e
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 nothin
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 almos
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
42 matches
Mail list logo
