From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Boycott Systemd
Date: Mon, 22 Sep 2014 06:00:20 +0000 (UTC) [thread overview]
Message-ID: <pan$19083$b1ba20b5$19edd77b$312105c9@cox.net> (raw)
In-Reply-To: CAGfcS_n=YbfQjLqJNq7pda9ptSty-CYskS68xGCpb-O0zaq9_Q@mail.gmail.com
Rich Freeman posted on Sun, 21 Sep 2014 22:34:23 -0400 as excerpted:
> On Sun, Sep 21, 2014 at 10:02 PM, Frank Peters
> <frank.peters@comcast.net> wrote:
>> There are things which are not system calls that could easily be
>> changed. It is not too far fetched to consider a time if and when
>> systemd became so popular and entrenched that the kernel would be
>> hard-coded to pass control only to systemd and nothing else.
>
> That seems extremely unlikely. How many people ran anything other than
> sysvinit as their init for the 15 years or so before upstart came along?
> Making the kernel dependent on systemd would defeat the whole purpose
> of having a separation between userspace and kernelspace.
Agreed. There's far too many and too broad usages of the Linux kernel
for that sort of hard-coding, at least without at least a kconfig option
for it.
Is android suddenly going to switch to systemd? Unlikely, and it's
generally acknowledged to be the biggest usage of the Linux kernel out
there these days, so hard-coding android breakage isn't going to happen.
Plus even if it did, we're dealing with open source here and Google would
simply patch that out and their own solution in as they do with a bunch
of other stuff. And if google could do that, so could anyone else.
Then there's the tivos and the embedded medical devices and the multiple
automotive systems likely running their own little embedded Linux
kernels. Hard-coding systemd for all of that? Not going to happen.
As for the loss of the usb static device nodes, did you (Frank) file a
bug about it breaking your userspace? That's one of Linus' most firm
kernel rules -- you do *NOT* change the userspace/kernelspace API/ABI and
break userspace. However, there's a known exception. Rather like the
old philosophical question as to whether if a tree falls in the forest
and nobody hears/sees it, did it actually fall at all, if nobody notices
the userspace/kernelspace ABI breaking, did it really break at all?
Unfortunately, for support for stuff like the big databases, etc, the big
users all tend to be on enterprise distros with years-old kernels and
sometimes the changes that break that don't get noticed for years simply
because nobody running those apps is running anything close to current
kernels, or if they do, they aren't reporting the problem. Bu the time
the breakage is actually noticed and reported two years later, other
userspace may depend on the new behavior and it can become a choice of
which userspace to break, the newer stuff depending on the new behavior
or the older stuff that was broken but that nobody noticed or reported
for years. That can cause problems, particularly when those old and now
broken userspace programs are big-dollar enterprise users, but sometimes
it happens.
And Linus and the other kernel devs are constantly pointing out that if
they break userspace, report it as soon as possible so it can be fixed.
Those who fail to do so, unfortunately very occasionally have to live
with the resulting breakage, at least to some extent, tho they still go
to rather extreme lengths to finesse things if and when they can.
So if your userspace breaks due to a kernel change, report it as soon as
you detect it and ask that it be fixed. Linus is very likely to make
sure it happens. If you didn't do that, well...
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-09-22 6:00 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-21 17:25 [gentoo-amd64] Boycott Systemd Frank Peters
2014-09-21 17:37 ` Canek Peláez Valdés
2014-09-21 18:30 ` Frank Peters
2014-09-21 19:15 ` Canek Peláez Valdés
2014-09-21 19:20 ` Barry Schwartz
2014-09-21 19:22 ` Canek Peláez Valdés
2014-09-21 19:33 ` Barry Schwartz
2014-09-21 19:45 ` Canek Peláez Valdés
2014-09-21 19:48 ` Canek Peláez Valdés
2014-09-21 21:13 ` Frank Peters
2014-09-21 22:04 ` Canek Peláez Valdés
2014-09-21 22:15 ` Harry Holt
2014-09-21 22:28 ` Canek Peláez Valdés
2014-09-22 5:27 ` [gentoo-amd64] " Duncan
2014-09-22 0:26 ` [gentoo-amd64] " Frank Peters
2014-09-22 0:45 ` Rich Freeman
2014-09-22 2:02 ` Frank Peters
2014-09-22 2:34 ` Rich Freeman
2014-09-22 6:00 ` Duncan [this message]
2014-09-22 12:47 ` [gentoo-amd64] " Harry Holt
2014-09-22 12:53 ` Rich Freeman
2014-09-22 16:14 ` Duncan
2014-09-23 14:55 ` Frank Peters
2014-09-24 11:25 ` Duncan
2014-09-24 16:58 ` Frank Peters
2014-09-25 4:12 ` Duncan
2014-09-25 11:34 ` Harry Holt
2014-10-07 14:18 ` Harry Holt
2014-10-07 14:55 ` Barry Schwartz
2014-10-07 17:04 ` Rich Freeman
2014-10-07 20:43 ` Barry Schwartz
2014-10-07 20:54 ` Damien Levac
2014-10-07 21:19 ` Barry Schwartz
2014-10-07 21:45 ` Rich Freeman
2014-10-08 1:15 ` Frank Peters
2014-10-08 2:28 ` Rich Freeman
2014-10-08 3:19 ` Harry Holt
2014-10-08 12:34 ` Phil Turmel
2014-10-08 18:02 ` Frank Peters
2014-10-08 21:42 ` Barry Schwartz
2014-10-08 3:23 ` Frank Peters
2014-09-22 13:23 ` Barry Schwartz
2014-09-22 17:00 ` Frank Peters
2014-09-22 16:21 ` Frank Peters
2014-09-22 19:46 ` Duncan
2014-09-22 17:04 ` [gentoo-amd64] " Lie Ryan
2014-09-22 17:58 ` Barry Schwartz
2014-09-22 18:22 ` Canek Peláez Valdés
2014-09-22 19:08 ` Barry Schwartz
2014-09-22 19:18 ` Canek Peláez Valdés
2014-09-22 19:46 ` Barry Schwartz
2014-09-22 19:30 ` Frank Peters
2014-09-22 19:37 ` Rich Freeman
2014-09-22 19:39 ` Canek Peláez Valdés
2014-09-22 19:54 ` Barry Schwartz
2014-09-22 20:08 ` Harry Holt
2014-09-22 20:22 ` Canek Peláez Valdés
2014-09-23 4:00 ` Canek Peláez Valdés
2014-09-23 3:51 ` Antoine Martin
2014-09-23 4:07 ` Barry Schwartz
2014-09-23 5:17 ` [gentoo-amd64] grub2 upgrade fail (was Boycott Systemd) Antoine Martin
2014-09-23 5:42 ` Barry Schwartz
2014-09-23 5:50 ` Barry Schwartz
2014-09-24 12:29 ` [gentoo-amd64] " Duncan
2014-09-23 4:09 ` [gentoo-amd64] Boycott Systemd Canek Peláez Valdés
2014-09-23 4:32 ` Barry Schwartz
2014-09-23 4:48 ` Canek Peláez Valdés
2014-09-23 5:49 ` Frank Peters
2014-09-23 6:05 ` Barry Schwartz
2014-09-23 6:31 ` Canek Peláez Valdés
2014-09-23 5:28 ` Barry Schwartz
2014-09-23 17:11 ` Paul Jewell
2014-09-23 23:31 ` Systemd is really beside the point, anyway (was Re: [gentoo-amd64] Boycott Systemd) Barry Schwartz
2014-09-24 12:45 ` [gentoo-amd64] Re: Boycott Systemd Duncan
2014-09-22 18:41 ` [gentoo-amd64] " Frank Peters
2014-09-22 18:44 ` Canek Peláez Valdés
2014-09-22 19:24 ` Barry Schwartz
2014-09-22 20:07 ` Frank Peters
2014-09-22 20:24 ` Barry Schwartz
2014-09-22 20:24 ` [gentoo-amd64] " Duncan
2014-09-22 18:07 ` [gentoo-amd64] " Frank Peters
2014-09-22 16:11 ` Lie Ryan
2014-09-22 16:35 ` Barry Schwartz
2014-09-22 17:55 ` Frank Peters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$19083$b1ba20b5$19edd77b$312105c9@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox