
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html On Fri, 30.05.14 04:32, Michael Biebl (mbiebl at gmail.com) wrote:
2014-05-30 4:26 GMT+02:00 Greg KH <gregkh at linuxfoundation.org>:
You update systemd but you don't update the kernel? How does that make any sense?
There might be very valid reasons why you need to stick with the old kernel. As said, one example could be that the new one simply doesn't boot. Requiring lock-step upgrades makes the system less fault-tolerant. So where possible this should be avoided.
To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side. I am tempted to say that we should merge the firmware loader removal patch at the same time as the kdbus requirement is made. As that would be a clean cut anyway... Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call. Lennart Poettering, Red Hat --- According to that logic, Linux is Linux+udev+kdbus+systemd .. In tone it is pure bullying. "I have taken udev and it will not work without systemd and I don't care about anything else". I don't think it fits in a GNU/Linux community project like Debian. It is not collaborative at all. It is good for a company like Red Hat to have "our ecosystem everywhere" but not for the rest. Lock-step is good for attackers. If I update X I better update Y and update Z too. oh, I don't know. Maybe don't update. And I do not need Z's functionality but I better do it all.. It is not good for embedded systems if the dependencies are many, become circular and hard to understand. The NSA will love it. Linux will work as long as you use it the way Poettering and Red Hat wants you to use it. Well, I have as much interest in it as using Windows or Mac OS X;-) BTW: People are mangling init(8) and sysV init in the discussion. You can run init and then comes inittab, rc.conf, /etc/rc to change between run levels and than /etc/init.d/*. You can change all that and it does not hurt a bit;-) Regards Peter

G'day -
-----Original Message----- From: luv-talk-bounces@luv.asn.au [mailto:luv-talk-bounces@luv.asn.au] On Behalf Of Peter Ross
The NSA will love it.
I'd like to see logic behind this assertion please? This is just systemd, really.
Linux will work as long as you use it the way Poettering and Red Hat wants you to use it.
Or Shuttleworth and Canonical. Or Ellison and Oracle :) I honestly think your concerns are overblown. The NSA bit reminded me the old silly "NSA Key" panic (http://en.wikipedia.org/wiki/NSAKEY). Regards Slav This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.
participants (2)
-
Peter Ross
-
Pidgorny, Slav(GPM)