[Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Lightner, Jeff]

According to the RedHat folks M$ has become a kinder, gentler behemoth since Balmer left.

Personally I’m more concerned about all the people that use proprietary Apple hardware and software that don’t seem to notice the incongruity of championing them over M$ while still lauding OSS.

Back before M$ created NT with the stated intention of replacing UNIX I was always more a fan of M$ over Apple because at least with M$ OS you got a choice of hardware. Funny thing is they never did kill UNIX but did kill Netware. (Linux oddly enough seems to be doing more to kill UNIX but that’s more of an evolution than a replacement to me.)

These days I have Windows laptops and servers, Linux desktops and servers, an Apple iPad (a gift – I don’t pay Apple for anything because to me their proprietary nature is still an evil) and an Android phone. One good thing about competition is they all keep innovating to try to stay ahead of the game.



From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Jim Kinney
Sent: Friday, August 07, 2015 10:24 AM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] [Fwd: Advertising on ale.org]


I don't like the idea of dues for ALE.

Corp sponsorship will have a corp message. If EFF wants to buy a round of drinks, I'm ok with that. Ditto for Redhat, Suse, Cannonical, and some others. If Microsoft wanted to buy a round of drinks and talk about opening up closed software, that would be interesting and a bit awkward.
On Aug 7, 2015 8:51 AM, "Beddingfield, Allen" <***@ua.edu<mailto:***@ua.edu>> wrote:
Since recruiting membership is getting harder for Linux user groups, I think charging dues may be counter-productive. I can’t really think of any Linux group (that I have been associated with) doing this.
As for corporate sponsors, Red Hat (and SUSE) would want to skew everything toward their distro for sure

Just my $0.02 worth


[Bob Toxen]

NO M$ advertising under pain of being drawn and quartered!

Post by Lightner, Jeff
According to the RedHat folks M$ has become a kinder, gentler behemoth since Balmer left.
Personally I???m more concerned about all the people that use proprietary Apple hardware and software that don???t seem to notice the incongruity of championing them over M$ while still lauding OSS.
Back before M$ created NT with the stated intention of replacing UNIX I was always more a fan of M$ over Apple because at least with M$ OS you got a choice of hardware. Funny thing is they never did kill UNIX but did kill Netware. (Linux oddly enough seems to be doing more to kill UNIX but that???s more of an evolution than a replacement to me.)
These days I have Windows laptops and servers, Linux desktops and servers, an Apple iPad (a gift ??? I don???t pay Apple for anything because to me their proprietary nature is still an evil) and an Android phone. One good thing about competition is they all keep innovating to try to stay ahead of the game.
Sent: Friday, August 07, 2015 10:24 AM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] [Fwd: Advertising on ale.org]
I don't like the idea of dues for ALE.
Corp sponsorship will have a corp message. If EFF wants to buy a round of drinks, I'm ok with that. Ditto for Redhat, Suse, Cannonical, and some others. If Microsoft wanted to buy a round of drinks and talk about opening up closed software, that would be interesting and a bit awkward.
Since recruiting membership is getting harder for Linux user groups, I think charging dues may be counter-productive. I can???t really think of any Linux group (that I have been associated with) doing this.
As for corporate sponsors, Red Hat (and SUSE) would want to skew everything toward their distro for sure???
Just my $0.02 worth???
--
Allen Beddingfield
Systems Engineer
The University of Alabama
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

It's got to be better than having systemd foistered on us by RedHat.

Post by Bob Toxen
NO M$ advertising under pain of being drawn and quartered!

Post by Lightner, Jeff
According to the RedHat folks M$ has become a kinder, gentler

behemoth since Balmer left.

Post by Lightner, Jeff
Personally I???m more concerned about all the people that use

proprietary Apple hardware and software that don???t seem to notice the
incongruity of championing them over M$ while still lauding OSS.

Post by Lightner, Jeff
Back before M$ created NT with the stated intention of replacing UNIX

I was always more a fan of M$ over Apple because at least with M$ OS
you got a choice of hardware. Funny thing is they never did kill UNIX
but did kill Netware. (Linux oddly enough seems to be doing more to
kill UNIX but that???s more of an evolution than a replacement to me.)

Post by Lightner, Jeff
These days I have Windows laptops and servers, Linux desktops and

servers, an Apple iPad (a gift ??? I don???t pay Apple for anything
because to me their proprietary nature is still an evil) and an Android
phone. One good thing about competition is they all keep innovating
to try to stay ahead of the game.
Jim Kinney

Post by Lightner, Jeff
Sent: Friday, August 07, 2015 10:24 AM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] [Fwd: Advertising on ale.org]
I don't like the idea of dues for ALE.
Corp sponsorship will have a corp message. If EFF wants to buy a

round of drinks, I'm ok with that. Ditto for Redhat, Suse, Cannonical,
and some others. If Microsoft wanted to buy a round of drinks and talk
about opening up closed software, that would be interesting and a bit
awkward.

Post by Lightner, Jeff
On Aug 7, 2015 8:51 AM, "Beddingfield, Allen"
Since recruiting membership is getting harder for Linux user groups,

I think charging dues may be counter-productive. I can???t really
think of any Linux group (that I have been associated with) doing this.

Post by Lightner, Jeff
As for corporate sponsors, Red Hat (and SUSE) would want to skew

everything toward their distro for sure???

Post by Lightner, Jeff
Just my $0.02 worth???
--
Allen Beddingfield
Systems Engineer
The University of Alabama
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Lightner, Jeff]

Systemd is not just on RedHat style distributions – in fact RHEL itself is rather late in doing it. (You can still do RHEL6 if it bothers you that much – it’s only on RHEL7 you see it.)

You can rail against systemd but you’re unlikely to avoid using it over time because most of the popular and commercial distros have adopted it:
https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception

Personally I don’t find systemd as horrible as some would seem to suggest.

One of the first things I learned in Management class in college is “People are resistant to change”. Most of the complaints I’ve seen about systemd boil down to “Why change, init worked for years?”. Despite the fact there are many reasons given for the “Why change” many who complain simply disregard them.

From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Jim Kinney
Sent: Tuesday, September 08, 2015 2:38 PM
To: ***@VerySecureLinux.com; Atlanta Linux Enthusiasts
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

It's got to be better than having systemd foistered on us by RedHat.

[Pete Hardie]

Much of what I've seen against systemd were was either a) it was
established by fiat instead of consensus, or b) monolithic and creeping
absorption of functionality

Post by Lightner, Jeff
Systemd is not just on RedHat style distributions – in fact RHEL itself is
rather late in doing it. (You can still do RHEL6 if it bothers you that
much – it’s only on RHEL7 you see it.)
You can rail against systemd but you’re unlikely to avoid using it over
https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception
Personally I don’t find systemd as horrible as some would seem to suggest.
One of the first things I learned in Management class in college is
“People are resistant to change”. Most of the complaints I’ve seen about
systemd boil down to “Why change, init worked for years?”. Despite the
fact there are many reasons given for the “Why change” many who complain
simply disregard them.
Kinney
*Sent:* Tuesday, September 08, 2015 2:38 PM
*Subject:* Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs
Linux/UNIX
It's got to be better than having systemd foistered on us by RedHat.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael Trausch]

Agreed. I've been testing it heavily for embedded use. Barebones system using systemd appears to use three to five MB less RAM than when using busybox's sysvinit style things. Have not compared to sysvinit.

The systemd setup I am using uses networkd instead of network manager, whereas the busybox's setup uses busybox for shell, and Debian scripts for network management with the dhcpcd and ip utils.

Check it out for yourself using the buildroot tool. While my tests were done on rpi2, similar results should be easily discoverable on x86 families.

The only reason it's not in my standard base image right now is a lack of time. Newest offspring arrived on the 21st and I have had little to no time since! Hoping to change that back to working status again soon.

Sent from my iPhone

Personally I don’t find systemd as horrible as some would seem to suggest.

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman

[Steve Litt]

On Tue, 8 Sep 2015 19:00:54 +0000

Systemd is not just on RedHat style distributions – in fact RHEL
itself is rather late in doing it. (You can still do RHEL6 if it
bothers you that much – it’s only on RHEL7 you see it.)
You can rail against systemd but you’re unlikely to avoid using it
over time because most of the popular and commercial distros have
https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception

PROPAGANDA ALERT: The systemd industry says they've won the battle and
you have no alternative but to use systemd.

* Devuan and Funtoo have committed to never using systemd
* Manjaro-OpenRC has very little systemd detrius, and its systemd
vestiges are harmless
* PC-BSD has no systemd
* All the preceding can easily be set up to do the work of a Linux box.
* Devuan has created its own udev, which is the flagship of systemd
vendor lock-in. So have Gentoo/Funtoo.

Personally I don’t find systemd as horrible as some would seem to
suggest.
One of the first things I learned in Management class in college is
“People are resistant to change”. Most of the complaints I’ve seen
about systemd boil down to “Why change, init worked for years?”.
Despite the fact there are many reasons given for the “Why change”
many who complain simply disregard them.

PROPAGANDA ALERT: The old "newer is better" argument. ISIS is new, but
not necessarily better. Ebola in cities is a new thing, but perhaps not
an improvement.

Now let's talk about change, complaints and reasons.

Name me one other change in the Linux world that generated even 1/10 of
the complaints of systemd. Yeah, I can't think of one either. If you
don't like Emacs, you use Vim, or Eclipse, or Bluefish, or whatever.
You can switch editors as easily as you can change clothes.

Don't like Gnome? No problem: use KDE, or Xfce, or LXDE, or OpenBox, or
any one of ten or twenty others. You can switch WM/DE as fast as
rearrange chairs in your living room.

Until very recently, if you didn't like sysvinit, you could have
effortlessly replaced it with s6, runit, or several others.

Now comes systemd, built from the ground up to prevent its own
replacement, because it promiscously interacts with as much as it can.
Replacing systemd requires not only the usual replacement of PID1 and
process manager, but also initramfs, udev, and now su, for gosh sakes.
Every month, systemd subsumes more of what was once the toolkit Linux
users used every day.

People didn't complain because it was new: They complained because it
was "my way or the highway."

And for what? 90% of use cases are for practical purposes init
agnostic. For this 90%, there is no "reason": They didn't ask for a
better init in the first place.

I could go on about systemd's architecture, but this response is
already long enough.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://ma

[Lightner, Jeff]

Well when major distros like the ones you've listed commit to not use it this is clearly the death knell for systemd. :p

Seriously - learn to love systemd - it is NOT the great evil people that haven't tried it suggest it is.

-----Original Message-----
From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Steve Litt
Sent: Thursday, September 10, 2015 12:38 PM
To: ***@ale.org
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

On Tue, 8 Sep 2015 19:00:54 +0000

Systemd is not just on RedHat style distributions – in fact RHEL
itself is rather late in doing it. (You can still do RHEL6 if it
bothers you that much – it’s only on RHEL7 you see it.)
You can rail against systemd but you’re unlikely to avoid using it
over time because most of the popular and commercial distros have
https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception

PROPAGANDA ALERT: The systemd industry says they've won the battle and you have no alternative but to use systemd.

* Devuan and Funtoo have committed to never using systemd
* Manjaro-OpenRC has very little systemd detrius, and its systemd
vestiges are harmless
* PC-BSD has no systemd
* All the preceding can easily be set up to do the work of a Linux box.
* Devuan has created its own udev, which is the flagship of systemd
vendor lock-in. So have Gentoo/Funtoo.

Personally I don’t find systemd as horrible as some would seem to
suggest.
One of the first things I learned in Management class in college is
“People are resistant to change”. Most of the complaints I’ve seen
about systemd boil down to “Why change, init worked for years?”.
Despite the fact there are many reasons given for the “Why change”
many who complain simply disregard them.

PROPAGANDA ALERT: The old "newer is better" argument. ISIS is new, but not necessarily better. Ebola in cities is a new thing, but perhaps not an improvement.

Now let's talk about change, complaints and reasons.

Name me one other change in the Linux world that generated even 1/10 of the complaints of systemd. Yeah, I can't think of one either. If you don't like Emacs, you use Vim, or Eclipse, or Bluefish, or whatever.
You can switch editors as easily as you can change clothes.

Don't like Gnome? No problem: use KDE, or Xfce, or LXDE, or OpenBox, or any one of ten or twenty others. You can switch WM/DE as fast as rearrange chairs in your living room.

Until very recently, if you didn't like sysvinit, you could have effortlessly replaced it with s6, runit, or several others.

Now comes systemd, built from the ground up to prevent its own replacement, because it promiscously interacts with as much as it can.
Replacing systemd requires not only the usual replacement of PID1 and process manager, but also initramfs, udev, and now su, for gosh sakes.
Every month, systemd subsumes more of what was once the toolkit Linux users used every day.

People didn't complain because it was new: They complained because it was "my way or the highway."

And for what? 90% of use cases are for practical purposes init agnostic. For this 90%, there is no "reason": They didn't ask for a better init in the first place.

I could go on about systemd's architecture, but this response is already long enough.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org

[Jim Kinney]

Post by Lightner, Jeff
Well when major distros like the ones you've listed commit to not use it

this is clearly the death knell for systemd. :p

Post by Lightner, Jeff
Seriously - learn to love systemd - it is NOT the great evil people that

haven't tried it suggest it is.

+1

I find systemd to be far easier that the hodgepodge collection of kludges
accumulated over the years of sysV on rhel/fedora. I want my stuff to run
they way _I_ want it to run. Once the simple basics of systemd are
understood, it's easier to manage my application startup environments. Each
application has an environment config file. Systemd is used to define
prerequisite services so crap like nfs starting before network is up no
longer happens.

It seems that once I dig past the issues of the personalities of the devs,
the complaints are rather thin. It would be highly impractical to have the
same command set used for two different outputs from two different inits.
It's not like systemd suddenly appeared 6 months ago. It's been around more
than 4 years. There's a global array of people with a good track record of
picking new technologies to work into Linux distros. From my perspective,
there's very little that's hit the big "FAIL" button and a tool as central
and vital as the init process will have been beat up on operational
theories before being accepted into use by the top 95+% of installed Linux
distros. So, time to learn new tricks.

Post by Lightner, Jeff
-----Original Message-----
Sent: Thursday, September 10, 2015 12:38 PM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
On Tue, 8 Sep 2015 19:00:54 +0000

Post by Lightner, Jeff
Systemd is not just on RedHat style distributions – in fact RHEL
itself is rather late in doing it. (You can still do RHEL6 if it
bothers you that much – it’s only on RHEL7 you see it.)
You can rail against systemd but you’re unlikely to avoid using it
over time because most of the popular and commercial distros have
https://en.wikipedia.org/wiki/Systemd#Adoption_and_reception

PROPAGANDA ALERT: The systemd industry says they've won the battle and

you have no alternative but to use systemd.

Post by Lightner, Jeff
* Devuan and Funtoo have committed to never using systemd
* Manjaro-OpenRC has very little systemd detrius, and its systemd
vestiges are harmless
* PC-BSD has no systemd
* All the preceding can easily be set up to do the work of a Linux box.
* Devuan has created its own udev, which is the flagship of systemd
vendor lock-in. So have Gentoo/Funtoo.

Post by Lightner, Jeff
Personally I don’t find systemd as horrible as some would seem to suggest.
One of the first things I learned in Management class in college is
“People are resistant to change”. Most of the complaints I’ve seen
about systemd boil down to “Why change, init worked for years?”.
Despite the fact there are many reasons given for the “Why change”
many who complain simply disregard them.

PROPAGANDA ALERT: The old "newer is better" argument. ISIS is new, but

not necessarily better. Ebola in cities is a new thing, but perhaps not an
improvement.

Post by Lightner, Jeff
Now let's talk about change, complaints and reasons.
Name me one other change in the Linux world that generated even 1/10 of

the complaints of systemd. Yeah, I can't think of one either. If you don't
like Emacs, you use Vim, or Eclipse, or Bluefish, or whatever.

Post by Lightner, Jeff
You can switch editors as easily as you can change clothes.
Don't like Gnome? No problem: use KDE, or Xfce, or LXDE, or OpenBox, or

any one of ten or twenty others. You can switch WM/DE as fast as rearrange
chairs in your living room.

Post by Lightner, Jeff
Until very recently, if you didn't like sysvinit, you could have

effortlessly replaced it with s6, runit, or several others.

Post by Lightner, Jeff
Now comes systemd, built from the ground up to prevent its own

replacement, because it promiscously interacts with as much as it can.

Post by Lightner, Jeff
Replacing systemd requires not only the usual replacement of PID1 and

process manager, but also initramfs, udev, and now su, for gosh sakes.

Post by Lightner, Jeff
Every month, systemd subsumes more of what was once the toolkit Linux users used every day.
People didn't complain because it was new: They complained because it was

"my way or the highway."

Post by Lightner, Jeff
And for what? 90% of use cases are for practical purposes init agnostic.

For this 90%, there is no "reason": They didn't ask for a better init in
the first place.

Post by Lightner, Jeff
I could go on about systemd's architecture, but this response is already long enough.
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts

http://www.troubleshooters.com/tjust

Post by Lightner, Jeff
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Jim Kinney
It seems that once I dig past the issues of the personalities of the
devs, the complaints are rather thin. It would be highly impractical
to have the same command set used for two different outputs from two
different inits. It's not like systemd suddenly appeared 6 months
ago. It's been around more than 4 years. There's a global array of
people with a good track record of picking new technologies to work
into Linux distros. From my perspective, there's very little that's
hit the big "FAIL" button and a tool as central and vital as the init
process will have been beat up on operational theories before being
accepted into use by the top 95+% of installed Linux distros. So,
time to learn new tricks.

Agreed.
As I mentioned previously, systemd (with its networkd, journald, and
udev) use less memory post-boot than busybox (with its mdev, no syslog,
and the Debian network management scripts). By itself, that's very
valuable on an SBC if you need every last page of RAM.
The binary key-value store which the journal provides allows
applications to use a universal interface to create rich log output.
No longer do you even have to serialize your output for the system
logger: you save a bunch of RAM by just putting your binary data in the
log files, verbatim. Move the expense of stringifying to the
developer's or operator's workstation, and not the embedded appliance
that wants to be very power efficient and just get its work done.

[Steve Litt]

On Thu, 10 Sep 2015 17:19:33 +0000

Post by Lightner, Jeff
Well when major distros like the ones you've listed commit to not use
it this is clearly the death knell for systemd. :p
Seriously - learn to love systemd - it is NOT the great evil people
that haven't tried it suggest it is.

This response is *precisely* what I was talking about. With any other
software, those who don't like it are told "fine, if you don't like
Vim, use Emacs". But here, we're told "learn to love it", as if
systemd's world domination is inevitable, and refusal to accept that
conclusion is a personal deficit.

If no architectural reason existed to shun systemd, the preceding
attitude would be more than enough.

When a salesman implies that I have no choice, I walk away. It's the
only prudent way to handle the situation, to prevent the salesman's
words from becoming a self-fulfilling prophecy.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Solomon Peachy]

Post by Steve Litt
If no architectural reason existed to shun systemd, the preceding
attitude would be more than enough.

The problem with this statement, is that in general, those
"architechural reasons" apply even more strongly to the
duct-tape-and-bailing-wire stuff that systemd replaces.

Post by Steve Litt
When a salesman implies that I have no choice, I walk away. It's the
only prudent way to handle the situation, to prevent the salesman's
words from becoming a self-fulfilling prophecy.

I also find this attitude particularly hilarious, because, in general,
the "alternatives" (eg BSDs) are even worse by the same criteria that
makes systemd supposedly so awful.

- Solomon [let popcorm commence!]

[Jim Kinney]

Well said.

Post by Solomon Peachy

Post by Steve Litt
If no architectural reason existed to shun systemd, the preceding
attitude would be more than enough.

The problem with this statement, is that in general, those
"architechural reasons" apply even more strongly to the
duct-tape-and-bailing-wire stuff that systemd replaces.

Post by Steve Litt
When a salesman implies that I have no choice, I walk away. It's the
only prudent way to handle the situation, to prevent the salesman's
words from becoming a self-fulfilling prophecy.

I also find this attitude particularly hilarious, because, in general,
the "alternatives" (eg BSDs) are even worse by the same criteria that
makes systemd supposedly so awful.
- Solomon [let popcorm commence!]
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Steve Litt]

On Sat, 12 Sep 2015 07:42:48 -0400

Post by Solomon Peachy

Post by Steve Litt
If no architectural reason existed to shun systemd, the preceding
attitude would be more than enough.

The problem with this statement, is that in general, those
"architechural reasons" apply even more strongly to the
duct-tape-and-bailing-wire stuff that systemd replaces.

Trying to find a definition of "duct-tape-and-bailing-wire" in order to
understand your assertion (by the way, it's spelled "baling"), the
closest definition I could find was
https://en.wikipedia.org/wiki/Big_ball_of_mud , which Wikipedia says is
a "haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-wire, spaghetti-code jungle."

The word "sprawling" sticks out. I'd hardly call sysvinit "sprawling",
especially when compared to systemd. And inits like runit, Epoch and s6
are miniscule compared to systemd.

Here are some other snippets from this Wikipedia article:

"Information is shared promiscuously among distant elements of the
system, often to the point where nearly all the important information
becomes global"

This is a description of systemd, not sysvinit or any of the smaller
inits. systemd is the one that shoots everything through dbus so
everyone knows (and needs to know) everyone else's business. Systemd is
the one that subsumes udev, libpam, and now comically su. By contrast,
sysvinit just acts as PID1 reaping zombies, and runs a process manager
that activates init scripts. Most of the rest of them are simpler and
more effective than sysvinit.

Another quote from the Wikipedia article:

"Foote and Yoder do not universally condemn \"big ball of mud\"
programming, pointing out that this pattern is most prevalent because
it works, at least at the moment it is developed. However, such
programs can become very difficult to maintain."

Focus on the sentence ending in "can become very difficult to maintain".

s6, runit, and Epoch, all of which can init a computer just fine, were
each created by one person and pretty much maintained by one person. If
one of those person stops maintenance it's no problem: People switch to
an alternative, or take over the code, which is code perfectly
understandable by one person. If one of these inits jumps the shark and
does something somebody doesn't like, that somebody can take over the
code and get it to work as desired.

Contrast those tight inits with systemd, which has required Redhat to
pay what, six programmer salaries since 2010 to get where it's gotten?
What happens if Redhat abandons it? Or more to the point, what do *you*
do if one day you stop liking where Redhat is taking your computer? How
do you back out of the systemd that's taken a million development
dollars to get where it's gotten?

I think by bringing up duct-tape-and-baling-wire, you've brought into
sharp focus exactly what's wrong with systemd architecturally.


SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Steve Litt
Trying to find a definition of "duct-tape-and-bailing-wire" in order to
understand your assertion (by the way, it's spelled "baling"), the
closest definition I could find was
https://en.wikipedia.org/wiki/Big_ball_of_mud ;, which Wikipedia says
is
a "haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-wire, spaghetti-code jungle."

And just how would you describe an init system which as a fundamental
requirement for its own operation requires the invocation of a
serialized set of unstructured scripts?
I don't have time to take this to a full conclusion, as life is life,
but:
* Fact: A pure barebones systemd-based system with all core services uses less RAM than sysvinit.
* Fact: Systemd is the application of the Makefile algorithm to the boot up process.  Tell the thing WHAT needs done.  It determines the HOW. We've been doing this for years in our build trees, it makes perfect sense to apply it to system initialization and runtime maintenance.
* Fact: Systemd provides rich tools for managing the "system", as a whole. It was never intended to be "just" an init.  It was intended to take the kludges that we've been applying year after year and consolidating them into the lightest possible implementations.  Why use ISC DHCPd when you have something that be in the idle process list and consume less memory?
* Fact: Systemd is intended to allow system administrators to have the same power and flexibility in system management that some other operating systems have provided for a long time now. The Makefile-style algorithm eliminates a lot of ad-hoc ordering code that was previously necessary.  I get that you like the old way, but we've all been doing it the old way for years, and for my part: I'm *glad* I don't have to order crap myself. There's a reason that very few serious build systems use the shell-scripting approach vs. the Makefile approach. Humans are great at saying what needs done, while machines are much better at the ordering and dependency resolution aspects of it.
* Fact: Systemd allows use of cgroups (inbuilt kernel functionality) to contain daemons. Standard init does not do so. Daemons can escape the control of standard init. They cannot escape the control of systemd.
* Fact: udev provides a much more convenient method of handling things than standard scripting. If you need to load a userspace driver to handle a particular USB device (e.g., a generic HID sensor not handled by the kernel, or something similar), then you plug the rule in and systemd/udevd make it happen. (Of course, you do not need systemd for udevd, but since systemd and udevd play very well together, it'd be silly to not use it.)
* Fact: systemd allows for rich reporting. "systemctl status" will tell you if all services are working or not, in the very second line of its output.
* Fact: systemd allows developers to push rich metadata to the journal, allowing system administrators to more clearly see "under the hood" for troubleshooting purposes. Systemd allows developers to do the same for themselves, during the development process. What changes? The implementation of your process specific tools gets easier because you're no longer forced to deal with (potentially ambiguously) serialized data.
At the end of the day, it saves time and resources for those of us who
make our living managing systems. For my part, I manage things ranging
from smaller than the Rπ to larger than a 1U. And systemd saves me time
and resources across the board.
Hold on to The Old Ways if you want, but when there are so many
objective reasons to not do so, it simply becomes stubbornness. We
humans like serialized, hand-managed things because we have a
sentimental attachment to micromanagement. Thing is, computers do much
better when the micromanagement logic is all in the same place and is
purely consistent. No longer do I have to worry about the
customizations made to the boot process or its ordering when I approach
a systemd system, because it will tell me with perfect consistency and
reproduction. And in this industry, perfect consistency and
reproduction saves time, saves money, and increases security.
Therefore, it's one of the few points in our field that matters with
very high significance over nearly everything else.

[Michael B. Trausch]

Post by Michael B. Trausch
At the end of the day, it saves time and resources for those of us
who make our living managing systems. For my part, I manage things
ranging from smaller than the Rπ to larger than a 1U. And systemd
saves me time and resources across the board.

And just to clarify here: While some of my real small systems are only
using systemd in testing, as I mentioned several emails back, this is
just lack of time to move it to production on my part. I've done
enough work to see for myself the benefits of moving.

Post by Michael B. Trausch
udev provides a much more convenient method of handling things than
standard scripting. If you need to load a userspace driver to handle
a particular USB device (e.g., a generic HID sensor not handled by
the kernel, or something similar), then you plug the rule in and
systemd/udevd make it happen. (Of course, you do not need systemd for
udevd, but since systemd and udevd play very well together, it'd be
silly to not use it.)

Not only is this a benefit all by itself, but it means userspace
drivers no longer have to internally reproduce the logic required to
find their devices. Udev tells you your device node for the userspace
driver. This allows me to cut out the probe logic which traverses
sysfs or devtmpfs directly, which is error prone and can screw up other
similar-looking devices. In other words, it's more robust by design
than The Old Ways. And that's kinda the whole gist of
systemd/networkd/journald/etc.: small, robust tools.
"systemd" refers to more than PID 1, but it also contains more than
/sbin/init. It's true to its name, otherwise it'd have been called
sysinitd, and not systemd.

[Steve Litt]

On Sat, 12 Sep 2015 11:08:26 -0700

Ok, so serious questions, then, that no one ever seems to answer
1. If a feature of systemd is not needed at all, does it still load?
Case in point, according to the docs PulseAudio is a core module of
PID 1. If I have no audio hardware, is that still going to be in the
memory footprint? It appears from some reading that the packaged
versions that would come with any major distro would have every
single module built in which case the only way to turn things off is
to compile systemd from scratch. I can't find anything about turning
features off if the compile-time switch was turned on.

I think you can turn off PulseAudio or any other service with systemctl
commands, no need to reboot. In that regard systemd is just like any
other init system.

I don't know the answers to your other questions.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Ok, so serious questions, then, that no one ever seems to answer
online
1. If a feature of systemd is not needed at all, does it still load?
Case in point, according to the docs PulseAudio is a core module of
PID
1. If I have no audio hardware, is that still going to be in the
memory
footprint? It appears from some reading that the packaged versions
that
would come with any major distro would have every single module built
in
which case the only way to turn things off is to compile systemd from
scratch. I can't find anything about turning features off if the
compile-time switch was turned on.

Pulseaudio is its own dÊmon. I do not have it on any of my embedded
systems (even the testing ones). You can still communicate directly
with ALSA just fine.
Offer of proof: Fedora 22 is a systemd-based system. Pulseaudio is
started as part of the X11 startup process or the user session. The PA
daemon runs as user gdm or user $UID, and is not started by the system.
PulseAudio can make use of the udev library to simplify the process of
finding hardware sound interfaces. One of the points of udev and
dynamic device management is that nothing is loaded if there isn't a
reason for it (or rather, that capability exists: it is possible to run
legacy code that is unaware of udev, which may or may not work in
modern systems anyway.)
Additional offer of proof: The PulseAudio package is a set of packages,
none of which are part of systemd. PulseAudio can be killed with the
only ramification being that your software will either need to manually
or automatically fall back to using ALSA's interface, which may or may
not support simultaenous playback of multiple streams (again depending
on the ALSA configuration and the hardware which backs it).
Final proof: The PulseAudio package depends on systemd as built in
Fedora 22 (not the other way around). Attempting to remove PA from the
system will succeed (but due to the way that the Fedora packagers built
the system, this removes a lot of useful functionality, such as GNOME).

Dependencies resolved.
====================================================================================================================================
Package Arch Version Repository Size
====================================================================================================================================
Transaction Summary
====================================================================================================================================
Remove 19 Packages

As you can see, systemd fares just fine and no attempt is made to
remove it.

2. Can I patch a piece of systemd without forcing a reboot? Right now
most things except the kernel can get restarted individually without
bringing down the whole system. There's no indication that systemd can
be patched piecemeal. At the moment it appears that if a flaw is found
in any portion of systemd, the whole thing would have to be patched and
then rebooted.The answer is, as always: "it depends". On a great deal.

Method 1: Memory hot patch. Sure, you can. It's about the only way to
update PID 1 ***WHILE IT IS RUNNING***. This is the same regardless of
the PID 1 implementation used.
Method 2: Package update and re-exec. Systemd supports this
('systemctl daemon-reexec). This allows you to upgrade systemd and
restart PID 1 without a reboot.
Method 3: The Old Way. Update the thing and reboot.
Note also that systemd comprises more than just PID 1. As with any
dÊmon, you must restart the dÊmon for the update to take effect. If
you're doing a system update wherein you've updated a substantial
number of dÊmons, it is often faster to reboot than restart them all at
runtime. However, systemd allows both options, giving you the choice
in how you want to manage your update application procedures.
The upside is the time saved: If you start dÊmon X, which depends on Y
and Z, where Y and Z were only started for X, then they'll get
restarted too. Automatically.
The additonal upside is that if your service is socket activated, NO
ACTION IS NECESSARY AT ALL. The service update will apply after the
next time the process recycles itself, which you can force to happen at
any time with standard POSIX signals.

3. For some of the more unusual inclusions in systemd (e.g. DHCPd) is
it possible to turn that feature off, remove its memory footprint, and
replace it with another? I use DNSMasq as my DHCP daemon because of a
lot of flexibility in the way it hands out leases. From the
systemd-networkd learnt minimal DHCPv4 server support in addition to the
existing DHCPv4 client support. It also learnt DHCPv6 client and IPv6
Router Solicitation client support. The DHCPv4 client gained support for
static routes passed in from the server. Note that the [DHCPv4] section
known in older systemd-networkd versions has been renamed to [DHCP] and
is now also used by the DHCPv6 client. Existing
.network files using settings of this section should be updated, though
compatibility is maintained. Optionally, the client hostname may now be
sent to the DHCP server.
So it's a "minimal DHCPv4 server". If I want something more than
minimal, can I turn it off completely and put in a replacement?Sure. Nothing forces you to use the components of systemd in a systemd

based system. You can refuse to use networkd or journald if you wish.
Systemd allows you to hard-mask any unit it knows about by using the
SA-override directory /etc/systemd, and symlinking the unit to
/dev/null. See also systemctl disable and systemctl enable. Want to
use ISC DHCPd? Go for it. Want to take IPv6 configuration away from
the kernel and move it to ISC DHCPd? Sure, can do that too. Want to
use MySpecialNetworkD to handle everything for you, pulling rules from
https://example.org/system_$UUID? Well, you can do that, too.
Your options are exactly as constrained as they've been in the past.
Which is to say, they're not.

Maybe some of the angst would calm down a bit if the developers and
documenters would actually explain these things instead of just saying
"look what new feature we added". That's mostly what I see on that
-devel list, a lot of excitement about pulling in yet another feature
but no real documentation about what to do when it doesn't fit a need.I've found no real lacking in the documentation for systemd; however,

as with any system, you need to read all of the documentation at some
point to make sense of it. That said, systemd provides a simple and
straightforward interface, which itself is inspired in parts by the
major bolt-on additions to the init system which Debian and Red Hat
maintained in their own distributions for years. (Just why do you think
that they were both willing to adopt systemd in the first place?
Unified infrastructure and Don't Repeat Yourself are concepts which we
all benefit from.) See Debian's public voting system for more
information, but they've both adopted the use of systemd, and
subsequently adopted a resolution stating that no specific resolution
was required to address init system coupling between packages.

I can't afford to "just try it", I have to know many of these things
ahead of time. But the very act of asking these questions sends a lynch
mob after me with the "just use it and shut up" mantra. I did dig
through a lot of documentation and ask some questions elsewhere prior to
creating my opinions. I was trying to give it the benefit of the doubt
but the documentation I can find is so poor or inapplicable to the use
case (meaning supplied as a distro package rather than built from
source) and the responses to questions terrible that I gave up and just
couldn't support the change to systemd.

Good thing is that you don't have to. It just works.
Also, please show me some of this "horrible documentation" that you're
talking about. I've used only the documentation. I've never needed to
ask the Giant Asshole or any of his minions for help or assistance in
any aspect of using or managing systemd. The man pages are very well
-written (and aren't giant rambling tomes as can be found in GNU
documentation). There are a lot of man pages, sure, but that's because
systemd takes the approach of breaking down the entire world into
small, manageable problems. There are many different unit types,
specifically because of the fact that system maintenance and management
is a messy thing to do.
Systemd gives the system administrator a SINGLE interface for managing
"the system". If you still want to do your piecemeal management, you
sure can. It's up to you. Nothing is forced on you. You can mask the
entire new world if you want, and only run your old systems if you'd
like. Personally, I find it much easier to update my software for the
new world: I get to drop several kilobytes of code from hardware
drivers and daemons, and get a more robust system as well. How that's
not win/win, I don't know.

[Damon L. Chesser]

The suspense is killing me, so I will just cut to the chase:

Hitler! Hitler! Hitler!

Now I feel better and I don't need to wait any more.

Ok, so serious questions, then, that no one ever seems to answer online

SNIP
--
***@damtek.com
404-271-8699

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Damon L. Chesser
Hitler! Hitler! Hitler!
Now I feel better and I don't need to wait any more.

Huh?

[d***@damtek.com]

Godwin's law.
--

Post by Lightner, Jeff

Hitler!  Hitler!  Hitler!
Now I feel better and I don't need to wait any more.

Huh?
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Damon L. Chesser
Hitler! Hitler! Hitler!

I can only assume that you did that in response to my message either as
an insult to my last name, or because you failed to recognize the fact
that I hate the author of systemd, but that does not inform my decision
to use the system due to the fact that it is prima facie better (in
every measurable way I have) than the old methods.
Either way your callous injection of such hostile and inappropriate
bullshit in an otherwise serious thread shows just what you are.
Enjoy the killfile, douche.

[Solomon Peachy]

1. If a feature of systemd is not needed at all, does it still load?

Generally speaking, no. Most of systemd exists of independent binaries
that are enabled at runtime based on userspace-level configuration; the
only exception to this that I can think of is the journal.

Case in point, according to the docs PulseAudio is a core module of PID
1.

I'm not sure where you read that, as PulseAudio has nothing to do with
systemd.

2. Can I patch a piece of systemd without forcing a reboot?

Yes, including the component that runs as PID1.

3. For some of the more unusual inclusions in systemd (e.g. DHCPd) is
it possible to turn that feature off, remove its memory footprint, and
replace it with another?

systemd's dhcp client and server are entirely optional, both at compile
time and runtime. If not actually invoked/executed, they don't do
anything but take up space on disk.

Maybe some of the angst would calm down a bit if the developers and
documenters would actually explain these things instead of just saying
"look what new feature we added". That's mostly what I see on that
-devel list, a lot of excitement about pulling in yet another feature
but no real documentation about what to do when it doesn't fit a need.

You're probably best off looking at the user-facing documentation, which
necessarily does lag a bit behind posts on the -devel list. :)

I was trying to give it the benefit of the doubt but the documentation
I can find is so poor or inapplicable to the use case (meaning
supplied as a distro package rather than built from source)

systemd-the-project can be seen as a big box of tools that can be used
to build a distribution. Exactly which parts the distro enables and
utilizes are up to the distro, so it's hard to write meaningingful
documentation when nearly every component is optional.

For example, going back to your earlier questions about the dhcp stuff:

It's a completely optional component from systemd's perspective, so
strictly speaking using it or not would be a matter of running
'systemctl stop systemd-networkd' and that's about it. However, if your
distro was built to utilize that feature, then you'd have to come up
with an alternative way to bring up your network devices.

I hope that makes sense.

- Solomon

[Solomon Peachy]

It's a bit confusing and probably not well written but when trying to
find any information on something very new and unfamiliar it's hard to
separate out any mistakes.

Fair enough. there's no shortage of bad or confusing documentation out
there. I'm personally responsible for far more than I care to admit. :)

But in this case, they were using PulseAudio as common system service
that could be started up via systemd.

Ok, no one ever describes *how* nor do they ever really mention it.
It's not even in the FAQ on the project page.

From the systemd man page:

SIGTERM:
Upon receiving this signal the systemd system manager serializes
its state, reexecutes itself and deserializes the saved state
again. This is mostly equivalent to systemctl daemon-reexec.

The recommended way is using the systemctl invocation, which is also in
the systemctl man page:

daemon-reexec
Reexecute the systemd manager. This will serialize the manager
state, reexecute the process and deserialize the state again. This
command is of little use except for debugging and package upgrades.
[ .. and some more stuff .. ]

FWIW your distro upgrade scripts should automatically invoke this.

That's what I was trying to do, but even the project page seems to be
slim on documentation beyond how to use the feature (missing would be
maintenance, lower level control, etc.)

All of the latter is covered by the generic service handling
documentation -- to systemd, there's no real difference between, say,
bringing up your network, and bringing up a daemon. Each is just a
"service" with its own set of dependencies.

Bringing up a network interface (which almost always are static in my
case) and bringing up a DHCP server are two different things. I used
this as an example only and not really intending to be specific to DHCP
but more to identify a situation where a systemd module has more than
one responsibility (in this case networkd has network interface, DHCP
client and DHCP server). I was not really understanding how to have one
feature without the others. Back with the DHCP example it's not obvious
or intuitive how to allow a static interface to be brought up, not
invoke a DHCP client on that interface (since a static IP doesn't need
it) and also prevent the systemd DHCP daemon from starting which would
interfere with a preferred daemon even though all three of those
features are within the networkd portion of systemd.

In the most basic sense, to bring up your own network you'd create a
systemd 'network.service' definition that includes the details on how
you want your network to be brought up -- eg a set of command
invocations, or invoking a dhcp client.

To run a dhcp server, you'd just create a 'dhcpd.service' definition
that includes details on how to get your preferred dhcp server running.
You'd probably want it to depend on network.service' since it's rather
useless without the network being up (and can be made to automatically
restart should the network itself be restarted)

How you make these things interact is actually up to you. They provide
recommendations for best practices, but you're free to ignore all of
that.

- Solomon

[Solomon Peachy]

So, in theory, I could tell systemd it can start up services that I
create and define using only the tools/software that I want even if it's
available with a built-in module and then never touch them again no
matter what unless and until I invoke a stop/start manually?

Absolutely. Though you may want to configure your services to
auto-restart upon a crash or something like that. Or not. It's your
call. :)

On a personal note, systemd allowed me to get rid of several highly
brittle hand-written init scripts and some rc.local stuff, plus a nasty
manually-invoked-via-a-screen-session mess that was necessary because
the PHP-based service didn't have access to the necessary POSIX APIs to
properly daemonize itself.

- Solomon

[Michael Trausch]

man systemd.network

man systemd.unit

man systemd.service

Sent from my iPad

Back with the DHCP example it's not obvious
or intuitive how to allow a static interface to be brought up, not
invoke a DHCP client on that interface (since a static IP doesn't need
it) and also prevent the systemd DHCP daemon from starting which would
interfere with a preferred daemon even though all three of those
features are within the networkd portion of systemd.

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Steve Litt]

On Sat, 12 Sep 2015 13:26:30 -0400

Post by Michael B. Trausch

Post by Steve Litt
Trying to find a definition of "duct-tape-and-bailing-wire" in order to
understand your assertion (by the way, it's spelled "baling"), the
closest definition I could find was
https://en.wikipedia.org/wiki/Big_ball_of_mud ;, which Wikipedia
says is
a "haphazardly structured, sprawling, sloppy,
duct-tape-and-baling-wire, spaghetti-code jungle."

And just how would you describe an init system which as a fundamental
requirement for its own operation requires the invocation of a
serialized set of unstructured scripts?

If it weren't for the fact that the init scripts require a certain
comment, I'd describe it as a perfectly logical way to do things. The
other problem I have with sysvinit is the length and complexity of its
init scripts.

Post by Michael B. Trausch
I don't have time to take this to a full conclusion, as life is life,
* Fact: A pure barebones systemd-based system with all core services
uses less RAM than sysvinit.

Well, maybe. Until you provide the proper output on two systems
identical except for their init, I can't comment one way or another.

But it's a moot point. None of the inits is especially RAM expensive
for most use cases.

The operant question, which I asked and nobody has yet answered, is
"what do the systemd industry and systemd enthusiasts have against
choice?"

Post by Michael B. Trausch
* Fact: Systemd is the application of the Makefile algorithm to the
boot up process.  Tell the thing WHAT needs done.  It determines the
HOW. We've been doing this for years in our build trees, it makes
perfect sense to apply it to system initialization and runtime
maintenance.

I can see value of that in certain use cases. I don't need it, but
maybe some might. So we get the (to some) benefit of makefile-like
init, and pay the price of monolithic entanglement.

Some might see the value proposition, some might not. Which again
brings up the question, "what do the systemd industry and systemd
enthusiasts have against choice?"

Post by Michael B. Trausch
* Fact: Systemd provides rich tools for managing the "system", as a
whole. It was never intended to be "just" an init.  It was intended
to take the kludges that we've been applying year after year and
consolidating them into the lightest possible implementations.  Why
use ISC DHCPd when you have something that be in the idle process
list and consume less memory?

Linux has always had a rich set of tools for managing the system,
although possibly not "as a whole": whose role as a benefit could be
debated. Systemd has cemented its layer of rich tools over Linux's set
of rich tools, making the latter very difficult to use. Some folks
prefer tools that don't adjust the system "as a whole". What does the
systemd crew have against letting them to continue using those things
with systemd running?

Post by Michael B. Trausch
* Fact: Systemd is intended to allow system administrators to have
the same power and flexibility in system management that some other
operating systems have provided for a long time now. The
Makefile-style algorithm eliminates a lot of ad-hoc ordering code
that was previously necessary.  I get that you like the old way, but
we've all been doing it the old way for years, and for my part: I'm
*glad* I don't have to order crap myself. There's a reason that very
few serious build systems use the shell-scripting approach vs. the
Makefile approach. Humans are great at saying what needs done, while
machines are much better at the ordering and dependency resolution
aspects of it.

You're not the only one glad you don't have to order the crap yourself.
But what do you have against letting those who want to order things
themselves do so?

Post by Michael B. Trausch
* Fact: Systemd allows use of cgroups (inbuilt kernel functionality)
to contain daemons. Standard init does not do so. Daemons can escape
the control of standard init. They cannot escape the control of
systemd.

There are different use cases in the world. That's why we have
different (and competing) software in the Free Software world. My use
case has no escaped daemons. Any daemontools-inspired process manager
holds on to those daemons for dear life.

Again, what does the systemd industry have against letting people
choose a different init system, without setting up stumbling blocks
throughout the system?

Post by Michael B. Trausch
* Fact: udev provides a much more convenient method of handling
things than standard scripting. If you need to load a userspace
driver to handle a particular USB device (e.g., a generic HID sensor
not handled by the kernel, or something similar), then you plug the
rule in and systemd/udevd make it happen. (Of course, you do not need
systemd for udevd, but since systemd and udevd play very well
together, it'd be silly to not use it.)

Udev existed long before systemd, and performed what you mention above.
Systemd co-opted udev and bound it tightly to the systemd monolith. Now
people are writing eudev and vdev so they can use udev without bringing
the whole systemd universe onto their computer.

Post by Michael B. Trausch
* Fact: systemd allows for rich reporting. "systemctl status" will
tell you if all services are working or not, in the very second line
of its output.

svstat /service/*

And if you insist on a summary on the first or second line, a tiny AWK
script can do that for you.

Use cases. Some of us can use AWK.

Post by Michael B. Trausch
* Fact: systemd allows developers to push rich metadata to the
journal, allowing system administrators to more clearly see "under
the hood" for troubleshooting purposes.

Which becomes quite necessary with systemd, because its "everything
depends on everything else" architecture eliminates the logical
junctions into which one can peer with diagnostic tests. The tools you
mention are like a check-engine light reader on a car: They give
certain codes, but if you get a situation not predictable by the codes,
you're in trouble.

Post by Michael B. Trausch
Systemd allows developers to
do the same for themselves, during the development process. What
changes? The implementation of your process specific tools gets
easier because you're no longer forced to deal with (potentially
ambiguously) serialized data. At the end of the day, it saves time
and resources for those of us who make our living managing systems.
For my part, I manage things ranging from smaller than the Rπ to
larger than a 1U. And systemd saves me time and resources across the
board. Hold on to The Old Ways if you want,

Fine. That's all I ever asked. Construct systemd in such a way that you
can replace the parts of it you want to replace, and I'll shut up.

Post by Michael B. Trausch
but when there are so
many objective reasons to not do so, it simply becomes stubbornness.

Fine. Stubbornness. Remove all the stumbling blocks, quit using Redhat
funding to make well working software require systemd, and I'll revel
in my stubbornness. But until you do that, I have to ask: What do you
have against choice?

And everybody, really, seriously, quit acting like sysvinit and Upstart
are the only alternatives. Everyone sees throught that.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Solomon Peachy]

Post by Steve Litt

Post by Michael B. Trausch
* Fact: A pure barebones systemd-based system with all core services
uses less RAM than sysvinit.

Well, maybe. Until you provide the proper output on two systems
identical except for their init, I can't comment one way or another.
But it's a moot point. None of the inits is especially RAM expensive
for most use cases.

You have to compare apples to apples -- by the time you add up all the
memory that the various shells and processes invoked by these init
scripts, you'll find that systemd comes in considerably less.

(And yes, I've built distros and sets of init scripts from scratch,
having to carefully count the number of nested stuff. I would have
[metaphorically] killed for something like systemd ten years ago..)

Post by Steve Litt
The operant question, which I asked and nobody has yet answered, is
"what do the systemd industry and systemd enthusiasts have against
choice?"

Oh, they have absolutely nothing against choice. You're
completely free to use a linux distribution that doesn't use
systemd -- or build your own should you not find any options to your
liking.

Or by "choice" are you really saying "my chosing to demand other people
do things the way I want?"

Post by Steve Litt
I can see value of that in certain use cases. I don't need it, but
maybe some might. So we get the (to some) benefit of makefile-like
init, and pay the price of monolithic entanglement.

If by "entanglement" you mean "a proveably-correct list of all
dependencies and interdependencies computed at runtime", you are unique
in that definition.

But you should also consider that traditional SysVInit "model" cannot be
considered anything other than an "entanglement" of a whole lot of
interdependent stuff smashed together until it mostly works. Except
when it doesn't.

Post by Steve Litt
Linux has always had a rich set of tools for managing the system,
although possibly not "as a whole": whose role as a benefit could be
debated.

You said it yourself -- "not as a whole", which means that "Linux" has
always had a rich set of tools for managing different parts of a system.

Post by Steve Litt
Systemd has cemented its layer of rich tools over Linux's set
of rich tools, making the latter very difficult to use.

Oh? Please elaborate on which tools were made "very difficult" to use.

Post by Steve Litt
Some folks prefer tools that don't adjust the system "as a whole".
What does the systemd crew have against letting them to continue using
those things with systemd running?

See my answer to above, except you should realize that the "systemd
crew" didn't force anyone to do anything. Instaead, your wrath should
be directed at the multitude of Linux distributions who freely chose to
adopt systemd.

Post by Steve Litt
There are different use cases in the world. That's why we have
different (and competing) software in the Free Software world. My use
case has no escaped daemons. Any daemontools-inspired process manager
holds on to those daemons for dear life.

Incidentally, one of the outcomes of competition is that inferior
options end up losing.

Post by Steve Litt
Again, what does the systemd industry have against letting people
choose a different init system, without setting up stumbling blocks
throughout the system?

Please elaborate on what these new "roadblocks" are, and how systemd set
them up.

Post by Steve Litt
Udev existed long before systemd, and performed what you mention above.
Systemd co-opted udev and bound it tightly to the systemd monolith. Now
people are writing eudev and vdev so they can use udev without bringing
the whole systemd universe onto their computer.

You're entitled to your own opinions, but not your own facts.

udev operates completely independently from systemd, and any example to
the contrary will be treated as a bug report and dealt with as such.

Post by Steve Litt

Post by Michael B. Trausch
* Fact: systemd allows for rich reporting. "systemctl status" will
tell you if all services are working or not, in the very second line
of its output.

svstat /service/*

So how will this handle a stale pidfile left over from your system
crashing hard, with another process using the pid? How will this
handle dangling child processes, preventing a new master from starting
up? (I could go on, but the failings are leigon)

Post by Steve Litt
And if you insist on a summary on the first or second line, a tiny AWK
script can do that for you.

So you're basically saying that you have to work around deficiencies in
your chosen tools....

Post by Steve Litt
Use cases. Some of us can use AWK.

Congratulations, do you want a cookie or something? (Seriously, in this
case that's like saying you know how to adjust the ignition points on
your car. That's all well and good, but there's a reason nobody builds
new cars with points any more..)

Post by Steve Litt
Which becomes quite necessary with systemd, because its "everything
depends on everything else" architecture eliminates the logical
junctions into which one can peer with diagnostic tests. The tools you
mention are like a check-engine light reader on a car: They give
certain codes, but if you get a situation not predictable by the codes,
you're in trouble.

Except (and I say this as someone who knows quite a bit about working on
cars too) the code readers save a vast amount of time and effort, and at
worst, you end up with the same situation you'd have without the code
readers -- ie having to take everything apart and follow
vehicle-specific diagnostic procedures.

Post by Steve Litt
Fine. That's all I ever asked. Construct systemd in such a way that you
can replace the parts of it you want to replace, and I'll shut up.

Okay, what parts are you looking to replace? Seriously. What
functionality would you be gaining, to balance against additional
complexity?

Post by Steve Litt
Fine. Stubbornness. Remove all the stumbling blocks, quit using Redhat
funding to make well working software require systemd, and I'll revel
in my stubbornness. But until you do that, I have to ask: What do you
have against choice?

Nothing, except when the word "choice" is used in a way that actually
translates to "do work for me, for free"

- Solomon

[Michael B. Trausch]

My reply to this message, I think, is the one that got eaten. It
should mosey on through later, but here's a link to it for anyone who
actually *wants* to read it.

http://www.fortifiedtechsystems.com/ale/resp-20150912.html

[Steve Litt]

On Sat, 12 Sep 2015 07:42:48 -0400

Post by Solomon Peachy

Post by Steve Litt
When a salesman implies that I have no choice, I walk away. It's the
only prudent way to handle the situation, to prevent the salesman's
words from becoming a self-fulfilling prophecy.

I also find this attitude particularly hilarious, because, in
general, the "alternatives" (eg BSDs) are even worse by the same
criteria that makes systemd supposedly so awful.
- Solomon [let popcorm commence!]

Find me one "alternative", except for Upstart, that does anything more
than act as PID1 and run a process manager. The criteria that makes
systemd supposedly so awful is that it subsumes huge portions of the
operating system (udev, su, initramfs, and who knows what else).

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Solomon Peachy]

Post by Steve Litt
Find me one "alternative", except for Upstart, that does anything more
than act as PID1 and run a process manager. The criteria that makes
systemd supposedly so awful is that it subsumes huge portions of the
operating system (udev, su, initramfs, and who knows what else).

0) So, you're saying that there's nothing that can act as an
"alternative" to systemd -- implying that it genuinely does more, but
that's actually a bad thing.
1) udev is independent. Use of it does not require use of systemd, and
if you can show the udev developers otherwise, they will treat it as
a bug report and correct it.
2) systemd does not replace interactive use of 'su', although
executing daemons as different users does necessarily require
equivalent functionality.
3) What does systemd have to do with intramfs, other than systemd
often being physically present on one?
4) I'm still waiting for "what", not "what else"

- Solomon

[Steve Litt]

On Sat, 12 Sep 2015 15:51:43 -0400

Post by Solomon Peachy

Post by Steve Litt
Find me one "alternative", except for Upstart, that does anything
more than act as PID1 and run a process manager. The criteria that
makes systemd supposedly so awful is that it subsumes huge portions
of the operating system (udev, su, initramfs, and who knows what
else).

0) So, you're saying that there's nothing that can act as an
"alternative" to systemd -- implying that it genuinely does more,
but that's actually a bad thing.

That is exactly, 100% precisely what I'm saying, Soloman. Every piece
of software should keep to its problem domain scope, and not subsume
the functionality of wide-ranging other software that already do it
well.

What I described in the preceding paragraph has always been the belief
of Linux (and Unix before it). Perhaps the new breed thinks otherwise.
That's fine, just don't make your software almost impossible to
replace, for those of us who do believe in small tools that do a
specific task.

Post by Solomon Peachy
1) udev is independent. Use of it does not require use of systemd,
and if you can show the udev developers otherwise, they will treat it
as a bug report and correct it.

OK, I'll do just that, the next time I alt-init anything. Of course,
because installing udev on a systemd distro pulls in systemd, I'll also
have to hand compile it. If I have problems, I'll submit a bug report.

Post by Solomon Peachy
2) systemd does not replace interactive use of 'su', although
executing daemons as different users does necessarily require
equivalent functionality.
3) What does systemd have to do with intramfs, other than systemd
often being physically present on one?

You really don't know?

Systemd doesn't just let the initramf' /init script run and fire
off the hard disk's /sbin/init. It gets in with the initramfs and does
stuff. Other people can describe it exactly, but it messes with
initramfs.

Systemd likewise uses /initramfs for shutdown.

Post by Solomon Peachy
4) I'm still waiting for "what", not "what else"

What are you asking?

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Solomon Peachy]

Post by Steve Litt
That is exactly, 100% precisely what I'm saying, Soloman. Every piece
of software should keep to its problem domain scope, and not subsume
the functionality of wide-ranging other software that already do it
well.

I think you and I have rather different defintions of "already doing it
well" -- "I'm used to it" is not the same thing.

In this particular case, systemd has precisely two required components,
systemd-pid1 and systemd-journald. From systemd's persepective,
absolutely everything else is optional and can be replaced.

Now specific linux distributions may or may not make it easy to replace
its use of specific systemd components, but that's always been the case
(distribution "differentiation" and all that) and isn't really systemd's
fault.

Post by Steve Litt
What I described in the preceding paragraph has always been the belief
of Linux (and Unix before it). Perhaps the new breed thinks otherwise.
That's fine, just don't make your software almost impossible to
replace, for those of us who do believe in small tools that do a
specific task.

Post-systemd, that task is as difficult as it was pre-systemd. (Yes,
I've done this before in the process of building embedded distros meant
for Wifi access points -- and believe me if systemd was an option ten
years ago I'd have chosen it in a heartbeat. It would have saved
literally months of effort!)

Post by Steve Litt

Post by Solomon Peachy
1) udev is independent. Use of it does not require use of systemd,
and if you can show the udev developers otherwise, they will treat it
as a bug report and correct it.

OK, I'll do just that, the next time I alt-init anything. Of course,
because installing udev on a systemd distro pulls in systemd, I'll also
have to hand compile it. If I have problems, I'll submit a bug report.

That's the distro's fault, not systemd's. Then again, udev has been a
core package for mainstream distros for far longer than systemd has been
around, so I'm not sure why you'd even be manually installing it.

Post by Steve Litt

Post by Solomon Peachy
3) What does systemd have to do with intramfs, other than systemd
often being physically present on one?

You really don't know?
Systemd doesn't just let the initramf' /init script run and fire
off the hard disk's /sbin/init. It gets in with the initramfs and does
stuff. Other people can describe it exactly, but it messes with
initramfs.

You're going to have to be more descriptive than "does stuff", beause
from systemd's own documentation, it won't touch intramfs unless
explicitly told to do so.

http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

So, blame your distribution for choosing to use systemd's features to
simplify their bootup and restart processes..

Post by Steve Litt
Systemd likewise uses /initramfs for shutdown.

Again, only if requested, but even then... so what? A whole lot of
other stuff is utilized upon a (clean) system shutdown.

- Solomon

[Chris Fowler]

Sent: Friday, September 11, 2015 11:11:13 PM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
On Thu, 10 Sep 2015 17:19:33 +0000

Post by Lightner, Jeff
Well when major distros like the ones you've listed commit to not use
it this is clearly the death knell for systemd. :p
Seriously - learn to love systemd - it is NOT the great evil people
that haven't tried it suggest it is.

This response is *precisely* what I was talking about. With any other
software, those who don't like it are told "fine, if you don't like
Vim, use Emacs". But here, we're told "learn to love it", as if
systemd's world domination is inevitable, and refusal to accept that
conclusion is a personal deficit.
If no architectural reason existed to shun systemd, the preceding
attitude would be more than enough.
When a salesman implies that I have no choice, I walk away. It's the
only prudent way to handle the situation, to prevent the salesman's
words from becoming a self-fulfilling prophecy.

One why I deal with user issues is to provide functionality that a user knows while increasing their options.

rc.local is an example where I would have maintained support for a script that is executed at the end of every other script.
Even if there is a way to do this in systemd after writing a script with certain options I would have created this for the user and put it in the distro as /etc/rc.local or /etc/rc.local is a symlink to the systemd script. This eases the transistion of the user into something knew with familiarity.

[Lightner, Jeff]

The post I was replying shows you do have a choice. Use another distro.

I was pointing out that most of the major distros are not in the list posted which to me is rather telling.

How many different kernel choices do you have for your distro?


-----Original Message-----
From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Steve Litt
Sent: Friday, September 11, 2015 11:11 PM
To: ***@ale.org
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

On Thu, 10 Sep 2015 17:19:33 +0000

Post by Lightner, Jeff
Well when major distros like the ones you've listed commit to not use
it this is clearly the death knell for systemd. :p
Seriously - learn to love systemd - it is NOT the great evil people
that haven't tried it suggest it is.

This response is *precisely* what I was talking about. With any other software, those who don't like it are told "fine, if you don't like Vim, use Emacs". But here, we're told "learn to love it", as if systemd's world domination is inevitable, and refusal to accept that conclusion is a personal deficit.

If no architectural reason existed to shun systemd, the preceding attitude would be more than enough.

When a salesman implies that I have no choice, I walk away. It's the only prudent way to handle the situation, to prevent the salesman's words from becoming a self-fulfilling prophecy.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Derek Atkins]

Post by Jim Kinney
It's got to be better than having systemd foistered on us by RedHat.

This just bit me yesterday; updated a system from F21 to F22 which
REMOVED syslogd!! OOPS. And I was wondering why I didn't get any
logwatch email!!! Well, duh, there are no logs anymore! Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?

-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
***@MIT.EDU PGP key available
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Lightner, Jeff]

With RHEL7 you still have /var/log/messages (along with Journald) but they may turn it off later.

I believe you CAN setup syslog manually on Fedora if you still want it but Journald can also be set to allow for saving logs (by default it gets cleared on boot) and you can likely tell logwatch to use journalctl to scan for what you want.

If you're using Fedora vs RHEL/CentOS you're doing bleeding edge anyway so complaining that it changes things on you seems a bit disingenuous.

Sith-temd Lord says come to the dark side...

-----Original Message-----
From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Derek Atkins
Sent: Thursday, September 10, 2015 10:52 AM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

Post by Jim Kinney
It's got to be better than having systemd foistered on us by RedHat.

This just bit me yesterday; updated a system from F21 to F22 which REMOVED syslogd!! OOPS. And I was wondering why I didn't get any logwatch email!!! Well, duh, there are no logs anymore! Stupid systemd journal. WTF are they thinking???? How is this "BETTER"?

-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
***@MIT.EDU PGP key available
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Derek Atkins]

Post by Lightner, Jeff
With RHEL7 you still have /var/log/messages (along with Journald) but
they may turn it off later.
I believe you CAN setup syslog manually on Fedora if you still want it
but Journald can also be set to allow for saving logs (by default it
gets cleared on boot) and you can likely tell logwatch to use
journalctl to scan for what you want.

logwatch certainly does not look at journald by default.. So it's not
that they changed things, but that things broke as part of the change.

Also, fail2ban stopped working, too, for similar reasons.

Post by Lightner, Jeff
If you're using Fedora vs RHEL/CentOS you're doing bleeding edge
anyway so complaining that it changes things on you seems a bit
disingenuous.
Sith-temd Lord says come to the dark side...

-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
***@MIT.EDU PGP key available
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[DJ-Pfulio]

Post by Derek Atkins
Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?

You aren't supposed to ask questions like that.

Now shut up and get used to the "new way." Trust us, it is better (for
certain values of better that 0.000001% like).
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

Finally! I'm in a 1% I like!

Post by DJ-Pfulio

Post by Derek Atkins
Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?

You aren't supposed to ask questions like that.
Now shut up and get used to the "new way." Trust us, it is better (for
certain values of better that 0.000001% like).
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Pete Hardie]

Occupy systemd?

Post by Jim Kinney
Finally! I'm in a 1% I like!
Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?
You aren't supposed to ask questions like that.
Now shut up and get used to the "new way." Trust us, it is better (for
certain values of better that 0.000001% like).
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

Post by Pete Hardie
Occupy systemd?

BWAHAHAHA!!! LOL!!!

Post by Pete Hardie

Post by Jim Kinney
Finally! I'm in a 1% I like!

Post by DJ-Pfulio

Post by Derek Atkins
Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?

You aren't supposed to ask questions like that.
Now shut up and get used to the "new way." Trust us, it is better (for
certain values of better that 0.000001% like).
_______________________________________________
Ale mailing list

***@ale.org> > >
http://mail.ale.org/mailman/listinfo/ale

Post by Pete Hardie

Post by Jim Kinney

Post by DJ-Pfulio
See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo> > >

Post by Pete Hardie

Post by Jim Kinney
--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/> >

Post by Pete Hardie

Post by Jim Kinney
_______________________________________________
Ale mailing list

***@ale.org
http://mail.ale.org/mailman/listinfo/ale

Post by Pete Hardie

Post by Jim Kinney
See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo

Post by Pete Hardie
_______________________________________________
Ale mailing list

***@ale.org>
http://mail.ale.org/mailman/listinfo/ale

Post by Pete Hardie
See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo>

[Chris Fowler]

Sent: Thursday, September 10, 2015 11:26:02 AM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
Occupy systemd?

Nope, just fork() CentOS. :)

[DJ-Pfulio]

Post by Chris Fowler

Sent: Thursday, September 10, 2015 11:26:02 AM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
Occupy systemd?

Nope, just fork() CentOS. :)

I think you mean fork - fedora.

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Chris Fowler]

Sent: Thursday, September 10, 2015 12:23:52 PM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

Post by Chris Fowler
Nope, just fork() CentOS. :)

I think you mean fork - fedora.

Both! Go back to normal.

[Jim Kinney]

Actually, the logging details are greater than the old syslog version.
You can turn back on sysloging and have both running. logwatch doesn't
yet support the new formatting of the systemd log process so that's a
part that will need updating. Not sure if there's a replacement in the
works or not.

Post by Derek Atkins

Post by Jim Kinney
It's got to be better than having systemd foistered on us by
RedHat.

This just bit me yesterday; updated a system from F21 to F22 which
REMOVED syslogd!! OOPS. And I was wondering why I didn't get any
logwatch email!!! Well, duh, there are no logs anymore! Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?
-derek

[Jerald Sheets]

http://sourceforge.net/p/logwatch/patches/34/ <http://sourceforge.net/p/logwatch/patches/34/>
Jerald Sheets RHCSA/RHCE/PCP
Sr. Puppet & Solutions Architect
***@shadow-soft.com
(d) 404.620.3607
(m) 404.293.8762




Open Source System Integration Experts
To learn more, go to http://www.shadow-soft.com <http://www.shadow-soft.com/>

To see how Shadow-Soft can help your organization Live Open and Save Hard, watch this video

The information contained in this message and any attachments is confidential and proprietary. It is intended only for the named recipient(s). If you received this message in error, please notify us immediately and be aware that any disclosure, copying, distribution, or use of the contents of this information is strictly prohibited.

logwatch doesn't yet support the new formatting of the systemd log process so that's a part that will need updating

[Jim Kinney]

Sweet!! Logwatch rocks.

Post by Jerald Sheets
http://sourceforge.net/p/logwatch/patches/34/
Jerald Sheets RHCSA/RHCE/PCP
Sr. Puppet & Solutions Architect
(d) 404.620.3607
(m) 404.293.8762
Open Source System Integration Experts
To learn more, go to http://www.shadow-soft.com
To see how Shadow-Soft can help your organization Live Open and Save Hard, watch this video
The information contained in this message and any attachments is
confidential and proprietary. It is intended only for the named
recipient(s). If you received this message in error, please notify
us immediately and be aware that any disclosure, copying,
distribution, or use of the contents of this information is strictly
prohibited.

logwatch doesn't yet support the new formatting of the systemd log
process so that's a part that will need updating

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael Trausch]

The journal is actually one of the most excellent things, coming from am embedded perspective where the SBC replaces the MCU and dedicated host board. Crashes go straight to the journal if you want them to. It is excellent for both debugging and production, and can hold arbitrary binary key/value data. It effectively replaces my own custom solution for the same thing with a universal interface.

Sent from my iPhone

Post by Derek Atkins

Post by Jim Kinney
It's got to be better than having systemd foistered on us by RedHat.

This just bit me yesterday; updated a system from F21 to F22 which
REMOVED syslogd!! OOPS. And I was wondering why I didn't get any
logwatch email!!! Well, duh, there are no logs anymore! Stupid systemd
journal. WTF are they thinking???? How is this "BETTER"?

This is not going to be good for embedded systems. Apparently the
journal is a take-it-or-else proposition because the journal consumes
the output of all services. Disabling the journal means cutting off
logging for services. The only things I've been able to find are the
storage options and those are awful. You either have it store to disk
and other programs read and parse the journal logs but not in real time
(this is not good for a small, flash based device like the Raspberry Pi,
that's just harming the flash storage) or you store the logs in memory
and have the other programs parse the memory (again not good for limited
RAM embedded systems). The only option left is a setting called "none"
which apparently disables the journal entirely but that cuts you off
from all the output from services since the journald is still running
and sucking up the output but it's just dropping it on the floor.
The format of the logs is also different so standard log parsing isn't
going to work either unless you have something pull in the journal and
rewrite it to standard log format.
Third, standard logging programs have no access to the boot logs if you
disable the journal. Those logs are lost unless you log to an external
logging daemon over the network.
This is all an interpretation of what I read from the journald man page.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Not if it's an all or none proposition.
Example, right now I can set up filters to have rsyslogd take syslog
input and either drop it to a file or, for things that are noisy,
shuttle them off over the network to something that actually has a
reasonable amount of storage (something many of my embedded systems
don't have). For the documents that I can find, *everything* goes to
the journal with no option to filter and you must choose to have all
of
it go to disk and/or duplicate it over the network. You can't have a
mix. If I'm wrong about this I want to see the documentation about
how
to filter what gets written to the journal and what doesn't.

I'd be a bad one to try to find that, because it's not functionality
I've ever used. I've rather preferred the approach of fixing the
squeaky wheel. See, to me, logs are useless if one needs tools like
HP's OpenView to grok them. Instead, the signal-to-noise ratio should
be correct: there should be very little noise in the first place.
My motivation for attacking the problem like that is simple: there's
very little reason to apply filtering between the syslog/journal's
entrypoint, when you can avoid the whole invocation in the first place
(saving several context switches in the process). Adding filtration
adds context switches. More context switches are bad. I therefore
consider noisy processes to be misbehaving, and either repair or
replace them. Thank goodness for having source code.
Call my view tainted: I've been doing an awful lot that requires very
precise timing lately, and even an extra context switch at a bad time
can throw my timing off. On the flip side of the coin, I don't want my
process to be of higher execution priority than the kernel, because
then I can miss things which are *coming at me* from the physical
hardware. A noisy process is therefore absolutely intolerable, and the
additional overhead of filtration even more so. Cut the problem off
where it starts, and nothing downstream has to compensate.

[Derek Atkins]

It seems I'm getting one for the price of two. To have what I need now
I just run one syslogd. To hvae the same thing under systemd I must run
journald and then run a syslogd on top of it because journald is not
capable of filtering inbound.

In my case I just installed rsyslog manually. Apparently logwatch was
not updated to look at journald!! OOPS!

-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
***@MIT.EDU PGP key available
_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

Post by Derek Atkins

It seems I'm getting one for the price of two. To have what I need now
I just run one syslogd. To hvae the same thing under systemd I must run
journald and then run a syslogd on top of it because journald is not
capable of filtering inbound.

In my case I just installed rsyslog manually. Apparently logwatch was
not updated to look at journald!! OOPS!

Yeah, big oops. My remote systems run rsyslogd with basic filtering to
send busy logs to a remote machine and the less busy logs go to local
storage. The remote system uses syslog-ng to filter into multiple log
files based on source machine, daemon and keywords. But if I had
systemd running then it would insist on having journald running, too,
yet I'd still need rsyslogd and syslog-ng to do all the filtering. So
I'm just running an extra daemon for nothing.

At that point, you would have done the research on the new process and have
known that you would need to use remote journald for networked logging or
install the latest, patched upstream logwatch.

Really people. Crap changes with every release. Apache 2.2 to 2.4 was a
total clusterfsck. Learning SELinux was a total clusterfsck so much so that
Debian spawned app-armour to lighten the impact. If your stuff depends on
old code, better get use to being the full support for it as devs like
working on new hotness. Really. Who wants to patch NFS when there's gluster
and lustre and orangefs and others to code on.

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Lightner, Jeff]

You miss the point. People don’t want to have to work with new things. It is so much easier to complain about them than to continue learning.



From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Jim Kinney
Sent: Friday, September 11, 2015 12:29 PM
To: Atlanta Linux Enthusiasts - Yes! We run Linux!
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

Post by Derek Atkins

It seems I'm getting one for the price of two. To have what I need now
I just run one syslogd. To hvae the same thing under systemd I must run
journald and then run a syslogd on top of it because journald is not
capable of filtering inbound.

In my case I just installed rsyslog manually. Apparently logwatch was
not updated to look at journald!! OOPS!

Yeah, big oops. My remote systems run rsyslogd with basic filtering to
send busy logs to a remote machine and the less busy logs go to local
storage. The remote system uses syslog-ng to filter into multiple log
files based on source machine, daemon and keywords. But if I had
systemd running then it would insist on having journald running, too,
yet I'd still need rsyslogd and syslog-ng to do all the filtering. So
I'm just running an extra daemon for nothing.

At that point, you would have done the research on the new process and have known that you would need to use remote journald for networked logging or install the latest, patched upstream logwatch.

Really people. Crap changes with every release. Apache 2.2 to 2.4 was a total clusterfsck. Learning SELinux was a total clusterfsck so much so that Debian spawned app-armour to lighten the impact. If your stuff depends on old code, better get use to being the full support for it as devs like working on new hotness. Really. Who wants to patch NFS when there's gluster and lustre and orangefs and others to code on.

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Chris Fowler]

Sent: Friday, September 11, 2015 12:39:28 PM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
1. Keep nothing locally (Storage=none) and run a second daemon
(rsyslogd, syslog-ng) alongside journald to process everything as I do

I think syslog-ng is one of the best logging solutions. On my device I've used rsylogd and the syslog in Busybox. For the past 5 years I've been using syslong-ng.

Once I really learned how to configure it I modified my daemons that were logging to their own files to then log to syslog-ng. I then used regex in the config to duplicate those syslog messages to specific files for each daemon. This allows me to quickly see what is going on in the software while maintaining syslog compatibility.

syslog-ng also routes inbound messages (from remote devices) by source ip. Those are stored in their own files as well. Software watches those messages and can look for 100s of regex matches on that stream. Any match creates a trouble ticket and deploys a technician to the location.

[d***@damtek.com]

Ahhh. No
It is in response to the long thread and the strong opinions in the thread and in fact was not directed at you or anybody else specifically.  And IAW Godwin's law, I have now lost the debate.  Seriously, it was merely meant in jest.
Don't like systemd, don't use it. Like systemd, use it. I prefer for the OS to get out of my way, what ever the under pinning are.
I mostly switch between init and systemd at home and work. I can run any distribution at home I desire. I just don't care about the init system, only caring about how I need to interact with it.
As for your last name, it's just a name holding no significance to me at all? I don't know if you are implying you are German or perhaps Jewish? Never crossed my mind and is not relevant to invoking Godwin's law.
I think you did a good job in supporting your views in light of the strength of emotional opinion in the other camp.  Sorry you are not familiar with Godwin's law and did not find it at least slightly humorus and in fact took it as a personal attack, which I have never taken part in in my nearly decade long association with ALE.
--

Hitler!  Hitler!  Hitler!

I can only assume that you did that in response to my message either as an insult to my last name, or because you failed to recognize the fact that I hate the author of systemd, but that does not inform my decision to use the system due to the fact that it is prima facie better (in every measurable way I have) than the old methods.
Either way your callous injection of such hostile and inappropriate bullshit in an otherwise serious thread shows just what you are.
Enjoy the killfile, douche.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Steve Litt]

On Sat, 12 Sep 2015 22:17:46 +0300

Post by d***@damtek.com
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically.  And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.

Post by d***@damtek.com
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.

If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.

The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.

For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.

Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.

Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.

I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

[Michael B. Trausch]

Post by Steve Litt
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide
alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

Wow.
Just, wow.
I'm not sure which of my responses hit the moderator queue, but I'm
sure you won't bother to read it anyway.
"Juggernaut"? Something that weighs in less than busybox *hardly*
qualifies. Something that can be replaced by busybox hardly qualifies!
Monopoly? You DO know RH didn't write systemd, yeah?
What. The. $*@).
I'm not even going to bother to read you anymore, since you clearly hav
en't bothered to read me.

[Damon L. Chesser]

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300

Post by d***@damtek.com
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.

Post by d***@damtek.com
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just don't
care, but to claim the evil empire of Red Hat is behind this? Seems a
bit bombastic? We all know the freedom haters of Debian remove choice
at every turn, and that is why they are backing the init choice of
systemd. Once Red Hat controls everything, then Debian can finally
close down. Who needs those pesky Debian dev meetings anyway? Always
yammering about some social contract this and social contract that.

Gento wanted to give it's users only one choice, most like due to Red
Hat financial interests, but the user base needed to be appeased, so
they gave you a "choice" of which system to use when you installed it.
Some choice. Systemd or the old system! Ha! Only two choices! Proof
they are in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
***@damtek.com
404-271-8699

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Charles Shapiro]

I chalk it all up to the Moon Landing Conspiracy. The moon landings were
all faked, in a studio ON THE MOON.

-- CHS

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No

Post by d***@damtek.com
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like systemd, don't use

Post by d***@damtek.com
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just don't care,
but to claim the evil empire of Red Hat is behind this? Seems a bit
bombastic? We all know the freedom haters of Debian remove choice at every
turn, and that is why they are backing the init choice of systemd. Once
Red Hat controls everything, then Debian can finally close down. Who needs
those pesky Debian dev meetings anyway? Always yammering about some social
contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to Red Hat
financial interests, but the user base needed to be appeased, so they gave
you a "choice" of which system to use when you installed it. Some choice.
Systemd or the old system! Ha! Only two choices! Proof they are in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by d***@damtek.com
I think you did a good job in supporting your views in light of the
strength of emotional opinion in the other camp. Sorry you are not
familiar with Godwin's law and did not find it at least slightly
humorus and in fact took it as a personal attack, which I have never
taken part in in my nearly decade long association with ALE.

It so happens that my kids distracted me so I didn't add you in yet,
and that appears to be a good thing. I had no idea of Godwin's law,
sorry.
Yes, German name. Not something I even think about often. Just the
odd combo of you replying, cutting 100% of my reply, and throwing that
at the top (which is OBVIOUSLY a German reference!) and I couldn't see
the relevance.
I'm a little hot-headed recently anyway. My bad.
Thanks for the clarification, and I apologize for my intentional
hostility to what I perceived to be the same.
— Mike

[Damon L. Chesser]

Post by Michael B. Trausch

Post by d***@damtek.com
I think you did a good job in supporting your views in light of the
strength of emotional opinion in the other camp. Sorry you are not
familiar with Godwin's law and did not find it at least slightly
humorus and in fact took it as a personal attack, which I have never
taken part in in my nearly decade long association with ALE.

It so happens that my kids distracted me so I didn't add you in yet,
and that appears to be a good thing. I had no idea of Godwin's law,
sorry.
Yes, German name. Not something I even think about often. Just the
odd combo of you replying, cutting 100% of my reply, and throwing that
at the top (which is OBVIOUSLY a German reference!) and I couldn't see
the relevance.

I blame my tablet mail app. Hard to get the "reply to" correct and keep
the thread lined up correctly. Also, a fact I am reminded of again and
again, sarcastic or dry wit do not transmit via email well.

Post by Michael B. Trausch
I'm a little hot-headed recently anyway. My bad.
Thanks for the clarification, and I apologize for my intentional
hostility to what I perceived to be the same.
— Mike
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Scott Plante]

Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot enough to melt the steel girders in the towers, I'd ask, "but what about those tanks of chemicals they use to make the chemtrails? Who knows how hot that stuff burns?"


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

----- Original Message -----

From: "Charles Shapiro" <***@gmail.com>
To: "Atlanta Linux Enthusiasts" <***@ale.org>
Sent: Tuesday, September 15, 2015 9:31:15 AM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX



I chalk it all up to the Moon Landing Conspiracy. The moon landings were all faked, in a studio ON THE MOON.

-- CHS



On Mon, Sep 14, 2015 at 4:58 PM, Damon L. Chesser < ***@damtek.com > wrote:






On 09/12/2015 04:21 PM, Steve Litt wrote:

<blockquote>
On Sat, 12 Sep 2015 22:17:46 +0300
***@damtek.com wrote:


<blockquote>
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.


Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.


<blockquote>
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.

</blockquote>
The preceding two sentences encapsulate the entire issue.

If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.

The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.

For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.

Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.

Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.

I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

</blockquote>

I am with Michael on this point. I am init agnostic and just don't care, but to claim the evil empire of Red Hat is behind this? Seems a bit bombastic? We all know the freedom haters of Debian remove choice at every turn, and that is why they are backing the init choice of systemd. Once Red Hat controls everything, then Debian can finally close down. Who needs those pesky Debian dev meetings anyway? Always yammering about some social contract this and social contract that.

Gento wanted to give it's users only one choice, most like due to Red Hat financial interests, but the user base needed to be appeased, so they gave you a "choice" of which system to use when you installed it. Some choice. Systemd or the old system! Ha! Only two choices! Proof they are in league!

<blockquote>

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

</blockquote>
--
***@damtek.com
404-271-8699



_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

</blockquote>


_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Pete Hardie]

+1 for that.

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot enough
to melt the steel girders in the towers, I'd ask, "but what about those
tanks of chemicals they use to make the chemtrails? Who knows how hot that
stuff burns?"
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
------------------------------
*Sent: *Tuesday, September 15, 2015 9:31:15 AM
*Subject: *Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings were
all faked, in a studio ON THE MOON.
-- CHS

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No

Post by d***@damtek.com
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like systemd, don't use

Post by d***@damtek.com
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just don't care,
but to claim the evil empire of Red Hat is behind this? Seems a bit
bombastic? We all know the freedom haters of Debian remove choice at every
turn, and that is why they are backing the init choice of systemd. Once
Red Hat controls everything, then Debian can finally close down. Who needs
those pesky Debian dev meetings anyway? Always yammering about some social
contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to Red Hat
financial interests, but the user base needed to be appeased, so they gave
you a "choice" of which system to use when you installed it. Some choice.
Systemd or the old system! Ha! Only two choices! Proof they are in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jerald Sheets]

WTC7 won't go away, folks. 😈

---
Jerald M. Sheets jr.

Post by Pete Hardie
+1 for that.

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot enough
to melt the steel girders in the towers, I'd ask, "but what about those
tanks of chemicals they use to make the chemtrails? Who knows how hot that
stuff burns?"
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
------------------------------
*Sent: *Tuesday, September 15, 2015 9:31:15 AM
*Subject: *Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings were
all faked, in a studio ON THE MOON.
-- CHS

Post by Damon L. Chesser

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No

Post by d***@damtek.com
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like systemd, don't use

Post by d***@damtek.com
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just don't
care, but to claim the evil empire of Red Hat is behind this? Seems a bit
bombastic? We all know the freedom haters of Debian remove choice at every
turn, and that is why they are backing the init choice of systemd. Once
Red Hat controls everything, then Debian can finally close down. Who needs
those pesky Debian dev meetings anyway? Always yammering about some social
contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to Red
Hat financial interests, but the user base needed to be appeased, so they
gave you a "choice" of which system to use when you installed it. Some
choice. Systemd or the old system! Ha! Only two choices! Proof they are
in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
Pete Hardie
--------
Better Living Through Bitmaps
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Damon L. Chesser]

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot
enough to melt the steel girders in the towers, I'd ask, "but what
about those tanks of chemicals they use to make the chemtrails? Who
knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't
Halliburton get the contract for waste disposal? It all ties together now.

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
------------------------------------------------------------------------
*Sent: *Tuesday, September 15, 2015 9:31:15 AM
*Subject: *Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings
were all faked, in a studio ON THE MOON.
-- CHS
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the
debate.
Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like
systemd, don't use
it. Like systemd, use it.
The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service
manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.
I am with Michael on this point. I am init agnostic and just
don't care, but to claim the evil empire of Red Hat is behind
this? Seems a bit bombastic? We all know the freedom haters of
Debian remove choice at every turn, and that is why they are
backing the init choice of systemd. Once Red Hat controls
everything, then Debian can finally close down. Who needs those
pesky Debian dev meetings anyway? Always yammering about some
social contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to
Red Hat financial interests, but the user base needed to be
appeased, so they gave you a "choice" of which system to use when
you installed it. Some choice. Systemd or the old system! Ha!
Only two choices! Proof they are in league!
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
404-271-8699 <tel:[phone]>
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

Oh man. There is _so_ much wrong with that. Halliburton subbed the
waste disposal to a Saudi partner firm as they got the gold disposal
from the north building basement. They already had the commando team in
place placing the charges so it made sense they would extract the rail
car filled with gold before the fire got to that lower level.
Sheesh. At least get your conspiracies correct
:-)

Post by Damon L. Chesser

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot
enough to melt the steel girders in the towers, I'd ask, "but what
about those tanks of chemicals they use to make the chemtrails? Who
knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn so
well with the jet fuel. Thanks for clearing that up for me. Didn't
Halliburton get the contract for waste disposal? It all ties
together now.

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
Sent: Tuesday, September 15, 2015 9:31:15 AM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings
were all faked, in a studio ON THE MOON.
-- CHS

Post by Damon L. Chesser

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300

Post by d***@damtek.com
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the
debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.

Post by d***@damtek.com
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init,
everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on
-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt
-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever
succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just
don't care, but to claim the evil empire of Red Hat is behind
this? Seems a bit bombastic? We all know the freedom haters of
Debian remove choice at every turn, and that is why they are
backing the init choice of systemd. Once Red Hat controls
everything, then Debian can finally close down. Who needs those
pesky Debian dev meetings anyway? Always yammering about some
social contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to
Red Hat financial interests, but the user base needed to be
appeased, so they gave you a "choice" of which system to use when
you installed it. Some choice. Systemd or the old system! Ha!
Only two choices! Proof they are in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Charles Shapiro]

I love it when a Troll comes together.

-- CHS

Oh man. There is _so_ much wrong with that. Halliburton subbed the waste
disposal to a Saudi partner firm as they got the gold disposal from the
north building basement. They already had the commando team in place
placing the charges so it made sense they would extract the rail car filled
with gold before the fire got to that lower level.
Sheesh. At least get your conspiracies correct
:-)
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot enough
to melt the steel girders in the towers, I'd ask, "but what about those
tanks of chemicals they use to make the chemtrails? Who knows how hot that
stuff burns?"
I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't Halliburton
get the contract for waste disposal? It all ties together now.
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
------------------------------
*Sent: *Tuesday, September 15, 2015 9:31:15 AM
*Subject: *Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings were
all faked, in a studio ON THE MOON.
-- CHS
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.
Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.
The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.
I am with Michael on this point. I am init agnostic and just don't care,
but to claim the evil empire of Red Hat is behind this? Seems a bit
bombastic? We all know the freedom haters of Debian remove choice at every
turn, and that is why they are backing the init choice of systemd. Once
Red Hat controls everything, then Debian can finally close down. Who needs
those pesky Debian dev meetings anyway? Always yammering about some social
contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to Red Hat
financial interests, but the user base needed to be appeased, so they gave
you a "choice" of which system to use when you installed it. Some choice.
Systemd or the old system! Ha! Only two choices! Proof they are in league!
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Lightner, Jeff]

While Elvis and I were on the flying saucer piloted by Big Foot he told me you’re too close for comfort on your theories.


From: ale-***@ale.org [mailto:ale-***@ale.org] On Behalf Of Charles Shapiro
Sent: Tuesday, September 15, 2015 1:12 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

I love it when a Troll comes together.
-- CHS

On Tue, Sep 15, 2015 at 12:08 PM, Jim Kinney <***@gmail.com<mailto:***@gmail.com>> wrote:
Oh man. There is _so_ much wrong with that. Halliburton subbed the waste disposal to a Saudi partner firm as they got the gold disposal from the north building basement. They already had the commando team in place placing the charges so it made sense they would extract the rail car filled with gold before the fire got to that lower level.

Sheesh. At least get your conspiracies correct

:-)

[Jim Kinney]

You let BigFoot fly?!?! You know he was grounded by the FAA after his
heart attack. When he found DB Coopers stash on the grassy knoll he
totally flipped his shit and nearly flatlined. Lucky for him Hitler,
who has just re-upped his Red Cross CPR certification was walking by.

Post by Lightner, Jeff
While Elvis and I were on the flying saucer piloted by Big Foot he
told me you’re too close for comfort on your theories.
Sent: Tuesday, September 15, 2015 1:12 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX
I love it when a Troll comes together.
-- CHS
Oh man. There is _so_ much wrong with that. Halliburton subbed the
waste disposal to a Saudi partner firm as they got the gold disposal
from the north building basement. They already had the commando team
in place placing the charges so it made sense they would extract the
rail car filled with gold before the fire got to that lower level.
Sheesh. At least get your conspiracies correct
:-)
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jim Kinney]

Heh, heh :-)
My fav part of conspiracy theories is the part where in order to
believe the theory, one must also believe that an organization that
buys $900 hammers could actually get several hundred people that live
in modern society to coordinate an effort to do ANYTHING and keep it
completely secret. The Manhattan Project was leaking info daily. The
atomic bombs were known to exist prior to the first explosion and that
group of people was sequestered in the middle of the desert behind
barbed wire and armed guards.

Post by Charles Shapiro
I love it when a Troll comes together.
-- CHS

Post by Jim Kinney
Oh man. There is _so_ much wrong with that. Halliburton subbed the
waste disposal to a Saudi partner firm as they got the gold
disposal from the north building basement. They already had the
commando team in place placing the charges so it made sense they
would extract the rail car filled with gold before the fire got to
that lower level.
Sheesh. At least get your conspiracies correct
:-)

Post by Damon L. Chesser

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn
hot enough to melt the steel girders in the towers, I'd ask,
"but what about those tanks of chemicals they use to make the
chemtrails? Who knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn
so well with the jet fuel. Thanks for clearing that up for me.
Didn't Halliburton get the contract for waste disposal? It all
ties together now.

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
Sent: Tuesday, September 15, 2015 9:31:15 AM
Subject: Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs
Apple vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon
landings were all faked, in a studio ON THE MOON.
-- CHS
On Mon, Sep 14, 2015 at 4:58 PM, Damon L. Chesser <

Post by Damon L. Chesser

Post by Steve Litt
On Sat, 12 Sep 2015 22:17:46 +0300

Post by d***@damtek.com
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.

Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.

Post by d***@damtek.com
Seriously, it was merely meant in jest. Don't like
systemd, don't use
it. Like systemd, use it.

The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason
processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically
entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a
monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.

I am with Michael on this point. I am init agnostic and just
don't care, but to claim the evil empire of Red Hat is behind
this? Seems a bit bombastic? We all know the freedom haters
of Debian remove choice at every turn, and that is why they
are backing the init choice of systemd. Once Red Hat
controls everything, then Debian can finally close down. Who
needs those pesky Debian dev meetings anyway? Always
yammering about some social contract this and social contract
that.
Gento wanted to give it's users only one choice, most like
due to Red Hat financial interests, but the user base needed
to be appeased, so they gave you a "choice" of which system
to use when you installed it. Some choice. Systemd or the
old system! Ha! Only two choices! Proof they are in league!

Post by Steve Litt
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Jerald Sheets]

That was one of the things that was funny about working at Apple. The
things people were ascribing to a company whose Linux admins couldn't rub
two vim plugins together.... the very idea anyone actually knew how an MTA
worked, much less was "in yer inbox, readin' yer mailz" is just ridiculous.

---
Jerald M. Sheets jr.

Post by Jim Kinney
Heh, heh :-)
My fav part of conspiracy theories is the part where in order to believe
the theory, one must also believe that an organization that buys $900
hammers could actually get several hundred people that live in modern
society to coordinate an effort to do ANYTHING and keep it completely
secret. The Manhattan Project was leaking info daily. The atomic bombs were
known to exist prior to the first explosion and that group of people was
sequestered in the middle of the desert behind barbed wire and armed guards.
I love it when a Troll comes together.
-- CHS
Oh man. There is _so_ much wrong with that. Halliburton subbed the waste
disposal to a Saudi partner firm as they got the gold disposal from the
north building basement. They already had the commando team in place
placing the charges so it made sense they would extract the rail car filled
with gold before the fire got to that lower level.
Sheesh. At least get your conspiracies correct
:-)
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot enough
to melt the steel girders in the towers, I'd ask, "but what about those
tanks of chemicals they use to make the chemtrails? Who knows how hot that
stuff burns?"
I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't Halliburton
get the contract for waste disposal? It all ties together now.
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory
------------------------------
*Sent: *Tuesday, September 15, 2015 9:31:15 AM
*Subject: *Re: [ale] [Fwd: Advertising on ale.org] - OT MS vs Apple
vs Linux/UNIX
I chalk it all up to the Moon Landing Conspiracy. The moon landings were
all faked, in a studio ON THE MOON.
-- CHS
On Sat, 12 Sep 2015 22:17:46 +0300
Ahhh. No
It is in response to the long thread and the strong opinions in the
thread and in fact was not directed at you or anybody else
specifically. And IAW Godwin's law, I have now lost the debate.
Yes, you have. Godwin's law doesn't work anymore, and it was always in
bad taste.
Seriously, it was merely meant in jest. Don't like systemd, don't use
it. Like systemd, use it.
The preceding two sentences encapsulate the entire issue.
If systemd were just another modular, replaceable init, everyone you
hear cursing it would be dancing in the streets. And truth be told, a
lot of us might then choose to use systemd in certain use cases.
The problem is, systemd has been engineered from the ground up to
exchange dependencies with every part of the Linux system. The
motivations for doing this are up for debate, but most folks who have
every alt-initted a system will vouch for this: Once you're using a
distro that has incorporated systemd as PID1, replacing systemd or any
part of it is very, very difficult.
For instance, if you currently have sysvinit, OpenRC, runit, s6 or
Epoch, switching to runit, s6 or Epoch involves installing the new
init, making a new run script (runit or s6) or config section (Epoch)
for each *real* process (not the tens of no-reason processes and
one-shots run by systemd). Not trivial, but not difficult for a Linux
knowledgeable person. You also have to make a shutdown script, and you
can find a lot of boilerplate for that on the Internet. It's also
possible that you'll need to make minor alterations to your initramfs,
but that's actually doubtful.
Same thing with a systemd computer: Replace it with runit, s6 or Epoch.
Now you need to find a udev equivalent, compile it, get it working. Or
else you need to do a lot of workarounds with systemd's udev. You need
to take dracut, and use it to create an initramfs that does *nothing
but* mount the root partition, and then hand control to the on-disk
init. As you do this, contemplate the trouble you'll be in if the
systemd industry ever conquers dracut, the way it conquered udev. If
so, you'll be back to hand-creating initramfs. And of course you'll
need to do all the same things I mentioned when describing alt-initting
a non-systemd box.
Consider that if sysvinit had been as monolithically entangled with the
user portion of the OS (and the kernel if they get their way with
kdbus) as systemd is, Red Hat would have had to spend triple what they
did to create a replacement init. But like all the other inits except
systemd, sysvinit is an encapsulated PID1 plus service manager, so it
was easy to replace. The systemd industry climbed the ladder of
modularity, and then pulled the ladder up after them.
I understand you're probably init agnostic, and that's fine. But you
need to be thankful for the people working hard to provide alternatives
to the Redhat funded juggernaut, because if Redhat ever succeeds in
eliminating alternatives to systemd, they'll have a monopoly on Linux.
Most entities who gain a monopoly do not behave well, and the user pays
the price.
I am with Michael on this point. I am init agnostic and just don't care,
but to claim the evil empire of Red Hat is behind this? Seems a bit
bombastic? We all know the freedom haters of Debian remove choice at every
turn, and that is why they are backing the init choice of systemd. Once
Red Hat controls everything, then Debian can finally close down. Who needs
those pesky Debian dev meetings anyway? Always yammering about some social
contract this and social contract that.
Gento wanted to give it's users only one choice, most like due to Red Hat
financial interests, but the user base needed to be appeased, so they gave
you a "choice" of which system to use when you installed it. Some choice.
Systemd or the old system! Ha! Only two choices! Proof they are in league!
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
404-271-8699
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
--
James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Jim Kinney
My fav part of conspiracy theories is the part where in order to
believe the theory, one must also believe that an organization that
buys $900 hammers could actually get several hundred people that live
in modern society to coordinate an effort to do ANYTHING and keep it
completely secret. The Manhattan Project was leaking info daily. The
atomic bombs were known to exist prior to the first explosion and
that group of people was sequestered in the middle of the desert
behind barbed wire and armed guards.

Right?
I have a knee-jerk to such things. Probably caused by the fact that I
have a conspiracy theorist in the family.

[Jim Kinney]

Post by Michael B. Trausch

Post by Jim Kinney
My fav part of conspiracy theories is the part where in order to
believe the theory, one must also believe that an organization that
buys $900 hammers could actually get several hundred people that
live in modern society to coordinate an effort to do ANYTHING and
keep it completely secret. The Manhattan Project was leaking info
daily. The atomic bombs were known to exist prior to the first
explosion and that group of people was sequestered in the middle of
the desert behind barbed wire and armed guards.

Right?
I have a knee-jerk to such things. Probably caused by the fact that
I have a conspiracy theorist in the family.

BWAHAHA!! They are so much fun to get riled up at Thanksgiving! If the
turkey get's a bit burned, tell 'em is because of the flouridated water
interacting with the nano bots from the turkey farming the USDA
mandated as part of the vaccine program to halt the spread of bird
flue. They should turn purple in about 10 minutes :-}

Post by Michael B. Trausch
_______________________________________________
Ale mailing list

***@ale.org>
http://mail.ale.org/mailman/listinfo/ale

Post by Michael B. Trausch
See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo>

[Michael B. Trausch]

Post by Jim Kinney

Post by Michael B. Trausch
Right?
I have a knee-jerk to such things. Probably caused by the fact
that I have a conspiracy theorist in the family.

BWAHAHA!! They are so much fun to get riled up at Thanksgiving! If
the turkey get's a bit burned, tell 'em is because of the flouridated
water interacting with the nano bots from the turkey farming the USDA
mandated as part of the vaccine program to halt the spread of bird
flue. They should turn purple in about 10 minutes :-}

lol... wrong brand of theories. This one is all about the arrest of
the American president by aliens and... well, tons of other crap. :-P

[Pete Hardie]

"arrest of the American President by aliens" ???

like, Greys and Reptilians, or like Miguel and Abdul?

Post by Michael B. Trausch
Right?
I have a knee-jerk to such things. Probably caused by the fact that I
have a conspiracy theorist in the family.
BWAHAHA!! They are so much fun to get riled up at Thanksgiving! If the
turkey get's a bit burned, tell 'em is because of the flouridated water
interacting with the nano bots from the turkey farming the USDA mandated as
part of the vaccine program to halt the spread of bird flue. They should
turn purple in about 10 minutes :-}
lol... wrong brand of theories. This one is all about the arrest of the
American president by aliens and... well, tons of other crap. :-P
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Michael B. Trausch]

Post by Pete Hardie
"arrest of the American President by aliens" ???
like, Greys and Reptilians, or like Miguel and Abdul?

More like a warped marriage between the Bible and an odd belief that
aliens are the agents of the deity who will restore order before the
end of days, or something like that. I tune out after a minute or two
of that crap. It's the only way I can manage to avoid causing a
catastropic disaster at gatherings.

[Jim Kinney]

Cause it! That way you won't have to listen to ever again as you won't
get invited back.

Post by Michael B. Trausch

Post by Pete Hardie
"arrest of the American President by aliens" ???
like, Greys and Reptilians, or like Miguel and Abdul?

More like a warped marriage between the Bible and an odd belief that
aliens are the agents of the deity who will restore order before the
end of days, or something like that. I tune out after a minute or
two of that crap. It's the only way I can manage to avoid causing a
catastropic disaster at gatherings.
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[DJ-Pfulio]

explains most world events
for the last 100 yrs.

claims to analyze it.

As far as secrecy goes - I don't have any problem believing that secrets
can, and are, maintained. If you are threatened with the harm for your
family, secrets are kept.

Post by Damon L. Chesser

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot
enough to melt the steel girders in the towers, I'd ask, "but what
about those tanks of chemicals they use to make the chemtrails? Who
knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't
Halliburton get the contract for waste disposal? It all ties together now.

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[Pete Hardie]

It's not so much the intent to keep secrets, but the ability - look at how
many hacks are due to bad OpSec by auxiliary personnel/contractors/temps.

Post by DJ-Pfulio
http://youtu.be/U1Qt6a-vaNM explains most world events
for the last 100 yrs.
http://youtu.be/Dbrdudxnisg claims to analyze it.
As far as secrecy goes - I don't have any problem believing that secrets
can, and are, maintained. If you are threatened with the harm for your
family, secrets are kept.

Post by Damon L. Chesser

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot
enough to melt the steel girders in the towers, I'd ask, "but what
about those tanks of chemicals they use to make the chemtrails? Who
knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't
Halliburton get the contract for waste disposal? It all ties together

now.

Post by Damon L. Chesser

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory

_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

[DJ-Pfulio]

I have a few stories about OpsSec, but not for email or a listsrv.

Post by Pete Hardie
It's not so much the intent to keep secrets, but the ability - look at how
many hacks are due to bad OpSec by auxiliary personnel/contractors/temps.

Post by DJ-Pfulio
http://youtu.be/U1Qt6a-vaNM explains most world events
for the last 100 yrs.
http://youtu.be/Dbrdudxnisg claims to analyze it.
As far as secrecy goes - I don't have any problem believing that secrets
can, and are, maintained. If you are threatened with the harm for your
family, secrets are kept.

Post by Damon L. Chesser

Post by Scott Plante
Or when "9/11 Truthers" would argue that jet fuel doesn't burn hot
enough to melt the steel girders in the towers, I'd ask, "but what
about those tanks of chemicals they use to make the chemtrails? Who
knows how hot that stuff burns?"

I wondered how the false flag commandos got the building to burn so well
with the jet fuel. Thanks for clearing that up for me. Didn't
Halliburton get the contract for waste disposal? It all ties together

now.

Post by Damon L. Chesser

Post by Scott Plante
https://en.wikipedia.org/wiki/Chemtrail_conspiracy_theory

_______________________________________________
Ale mailing list
***@ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo