Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Posted Sep 11, 2014 23:12 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: Poettering: Revisiting how we put together Linux systems by ksandstr
Parent article: Poettering: Revisiting how we put together Linux systems
SystemD has an actual ABI compatibility promise: http://www.freedesktop.org/wiki/Software/systemd/Interfac...
That can't be said about SysV scripts.
Posted Sep 12, 2014 1:53 UTC (Fri)
by mgb (guest, #3226)
[Link] (18 responses)
http://www.freedesktop.org/wiki/Software/systemd/Interfac...
However systemd's ABIs are a relatively minor problem, as are systemd's bugs. The serious problem with systemd is the endless churning of the plumbing layer every time RH decides that all systemd distros must downgrade yet another feature to match Fedora.
"One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions."
Posted Sep 12, 2014 2:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
>The serious problem with systemd is the endless churning of the plumbing layer every time RH decides that all systemd distros must downgrade yet another feature to match Fedora.
Posted Sep 12, 2014 2:23 UTC (Fri)
by mgb (guest, #3226)
[Link] (15 responses)
But people who value Debian Stable shouldn't have to suffer endless churn as systemd drags it down to Fedora's level.
Posted Sep 12, 2014 2:30 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Posted Sep 12, 2014 3:54 UTC (Fri)
by mgb (guest, #3226)
[Link] (13 responses)
For a better perspective you'll have to read a few months of debian-user and debian-devel.
Or you can save some time by deducing the scope of the churn from RH's admission that "One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions." RH can't do that without throwing away great features and millions of person hours in every non-RH systemd distro.
Posted Sep 12, 2014 4:29 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
>For a better perspective you'll have to read a few months of debian-user and debian-devel.
>Or you can save some time by deducing the scope of the churn from RH's admission that "One of the main goals of systemd is to unify basic Linux configurations and service behaviors across all distributions." RH can't do that without throwing away great features and millions of person hours in every non-RH systemd distro.
Posted Sep 12, 2014 4:54 UTC (Fri)
by mgb (guest, #3226)
[Link] (11 responses)
Posted Sep 12, 2014 6:07 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
A good solution requires a bit of rethinking of how services are organized, resulting in a more robust and system: https://lists.debian.org/debian-devel/2014/09/msg00403.html which is accepted by the author https://lists.debian.org/debian-devel/2014/09/msg00434.html And it really is better, because it's possible to introspect the running system with the usual tools, without knowing the magic OpenVPN-specific init.d arguments.
Posted Sep 12, 2014 13:52 UTC (Fri)
by mgb (guest, #3226)
[Link] (8 responses)
If DDs want to spend their time making things work with systemd they are of course at liberty to choose how they spend their time.
But using unnecessary dependencies to force Debian users to switch to systemd is a serious violation of Debian's Social Contract and very very wrong.
Posted Sep 12, 2014 14:26 UTC (Fri)
by johannbg (guest, #65743)
[Link] (7 responses)
Please provide the reference to the information that shows maintenance within Fedora is less functional and reliable than it is in Debian as you are indicating with this remark
Thanks
Posted Sep 12, 2014 14:42 UTC (Fri)
by mgb (guest, #3226)
[Link] (6 responses)
Fedora is bleeding edge which is appropriate for some use cases.
Debian Stable is magnificently reliable and upgrades smoothly from one release to the next without reinstalling.
Posted Sep 12, 2014 15:00 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
What gives you the idea that this will no longer be the case once systemd is Debian's default init system? If there are snags with the upgrade from wheezy to jessie then bugs will be filed and the problems will be fixed, like Debian has worked for the last 20 years. That's what the pre-release freeze is for, after all.
Posted Sep 12, 2014 15:14 UTC (Fri)
by mgb (guest, #3226)
[Link] (3 responses)
Forcing systemd on unwilling Debian users is an egregious violation of Debian's Social Contract.
Leaving servers inaccessible or even unbootable after an upgrade is distinctly below the standard achieved by previous Debian upgrades.
Posted Sep 12, 2014 16:55 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Inittab isn't exactly rocket science. If there was sufficient demand it would certainly be possible to come up with a program that looks at a system's /etc/inittab and generates a corresponding set of systemd configuration files, at least for the common use cases. This already works for other legacy configuration files like /etc/fstab.
Note that, even before systemd, Debian never guaranteed you a “seamless upgrade” if you'd tweaked the hell out of your /etc/inittab file, or for that matter any configuration file. Debian does make an honest effort not to break things but we are not, and never were, in the business of promising miracles.
So far the only change is that Debian has (for a variety of reasonable reasons) decided that new installs of the distribution will use systemd unless otherwise specified. SysV init still exists as a Debian package. Package maintainers are still free to include SysV init support in their packages, and users who would rather use SysV init are still free to contribute SysV init scripts for packages that don't come with them (while maintainers are encouraged to include these). So far nothing is being “forced” on anybody.
As far as the Social Contract is concerned, nothing in it says that Debian shouldn't use systemd. If anything, it stipulates that, in the interest of its users, the software in Debian – especially the software that is installed by default – should embody the appropriate state of the art. In 2014, the state-of-the-art solution for basic Linux plumbing seems to be systemd, and this is further corroborated by the fact that all other mainstream Linux distributions seem to concur with this.
You may have noticed that so far no stable Debian release actually involved systemd in an upgrade. Therefore there is no evidence whatsoever that upgrading Debian from one stable version to the next will, in fact, leave “servers inaccessible or even unbootable“ on account of systemd. On the contrary, it is safe to say that the upgrade from wheezy to jessie will be extensively tested by Debian maintainers, and showstopping problems will hopefully be corrected before jessie is actually released.
Posted Sep 13, 2014 1:20 UTC (Sat)
by mchapman (subscriber, #66589)
[Link] (1 responses)
Why is this such a problem? Upstart ignores all service definitions in inittab too, and yet I don't remember much complaint about that.
Different init systems are different, just as different windows managers are different and different text editors are different. There is no reason they should be "compatible" with one another in any sense. Where they *are* compatible is simply a bonus.
Posted Sep 13, 2014 1:23 UTC (Sat)
by mchapman (subscriber, #66589)
[Link]
To clarify, I too think claims of "drop-in compatibility" are meaningless. But that's OK, since I don't consider "drop-in compatibility" to be a necessary feature anyway.
Posted Sep 12, 2014 15:33 UTC (Fri)
by johannbg (guest, #65743)
[Link]
Fedora is not "bleeding edge" ( rawhide is which is comparable to Debian Unstable I suppose ) or "First" for that matter even if it claims to be ( Arch took that title long time ago ) and people have been ( proudly ) upgrading Fedora from FC1 and boast about doing so in the process with every new release of Fedora.
On one hand Fedora releases with newer release of an component containing bugfixes and enhancements more often than Debian does given it has shorter <-- release cycles then Debian, while Debian chooses to backport those fixes into the release due to it having longer <--- release cycle then Fedora.
You are claiming that the maintainership and quality assurance community in Fedora is of lesser quality than it is in Debian yet both of those distribution work closely with their upstream to the best of their ability as far as I know so please by all means enlighten me and elaborate how Debian manages to maintain their component "better" than maintainers within the Fedora and help the maintainers within Fedora as well as it's quality assurance community understand what they need to improve to be on par with Debians maintainership.
Posted Sep 12, 2014 8:44 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
So? As far as I can tell that thread came up with a few sensible suggestions on how to make OpenVPN work with systemd, and the Debian OpenVPN maintainer seemed to like them.
As far as »systemd makes every distribution into Fedora« is concerned: The systemd developers seem to be looking for good solutions, not necessarily Fedora solutions. In point of fact some of systemd's approaches had been patterned on Debian (rather than Fedora) long before Debian declared that systemd would be the new default init system. If some distribution finds that whatever systemd does is too limited they can (a) lobby the systemd developers to adapt, which if there are good technical reasons they probably will, or (b) replace that particular bit of systemd (which, you know, is pretty modular as these things go) with one that is closer to their requirements.
Posted Sep 12, 2014 10:50 UTC (Fri)
by johannbg (guest, #65743)
[Link]
I have to ask why are you under the impression that Red Hat decides anything that happens in the systemd community?
Where does that thought originate from?
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Forcing everyone (including Fedora!) to reimplement broken features is a nice side of systemd's adoption.
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Care to point out this problem?
I'm browsing debian-devel, I don't see anything worse than the usual bugfixing cycle.
These 'great features' being? Fragmentation for the sake of fragmentation? Buggy init scripts?
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Debian Stable is magnificently reliable and upgrades smoothly from one release to the next without reinstalling.
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
systemd ignores inittab and therefore any claims of "drop-in compatibility" are meaningless.
Forcing systemd on unwilling Debian users is an egregious violation of Debian's Social Contract.
Leaving servers inaccessible or even unbootable after an upgrade is distinctly below the standard achieved by previous Debian upgrades.
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems
Poettering: Revisiting how we put together Linux systems