[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is missing SysV-init support a bug?


On 28.08.2016 14:29, Jonathan de Boyne Pollard wrote:

> especially in light of the fact
> that the systemd developers have had a list of "Oddball things that you
> can actually do with rc scripts that systemd isn't going to support."

The crux of the matter is that what the majority thinks of as an
"oddball" configuration is someone's production system.

When systemd "isn't going to support" an interface from sysvinit, that
is a technical decision their project makes, and usually for good
reasons (I've written a lengthy article[1] about this).

However, Debian is not the systemd project. What is good project
management for them is not necessarily what is best for our users.

I agree that to the vast majority of users, this is entirely
inconsequential, as they haven't modified their init scripts at all, and
probably do not know about their existence. These people were served
well with sysvinit as default before jessie, and even better now with
systemd as default.

But we still have other users, some of who disagree with the
architectural model of systemd, as the tight integration and ease of use
was bought with a reduction in flexibility.

The same debate comes up with build systems occasionally, and it leads
nowhere there either:

When you use make, you have to remember a lot of arcane syntax
(mandatory tab indentation, single-punctuation-character variable names)
and put together the command line for your compiler in a scripting language.

Then there is autoconf. You still write Makefiles, you get another layer
of arcane syntax on top, but you get a lot of support code that is
shared with other projects, so now it becomes easier to support cross
compiling and different compilers.

Then someone wrote automake, after realizing that most Makefiles look
the same anyway. You compile some code, track include file dependencies,
link the generated objects together and install the result somewhere, so
all that is different between project is the names of the source and
output files.

Then, cmake comes along. They bring this to another level, and even
allow you to generate project files for graphical IDEs.

However, with each improvement there was a trade-off involved:

 - autoconf added easy cross-compiling, but also the assumption that
only a single compiler would be used in one source tree, which was
annoying for embedded projects that would build firmware along with drivers.

 - automake dropped support for anything that wasn't a program or
library, telling people to use plain autoconf in a subdirectory then.

 - cmake dropped the option to fall back on scripted builds, and their
cross compiling support sucks.

If you look at a modern Linux system, you will find that the majority of
the software we have are programs and libraries, and that many of these
have switched to cmake as their build system in the last years.

Still, the kernel uses plain "make", not cmake.

I use cmake for most of my projects, but one of them has a program that
runs on the host CPU that talks to a kernel module that downloads a
bitstream into an FPGA that contains an embedded ARM CPU that runs a
statically linked program. That project uses a Makefile for the kernel
module, automake for the userspace drivers and autoconf for finding the
FPGA toolchain, and configures the ARM cross-compiler in a subdirectory.

This is my yardstick: If you propose to exclusively use a single,
easy-to-use build system with good integration into graphical IDEs, I
request that you show that it can also build both the Linux kernel and
my module from source on all currently supported architectures, and you
guarantee that my project won't break by any future updates of the build

Otherwise, your build system is useless for my project. I may still use
it for the majority of my other projects, because it may be convenient
to use, but I will laugh at you if you claim that I don't need any others.

The same goes for init systems, really. It is completely fine if you
prefer systemd. It is also true that my laptop runs systemd, because I
don't care as long as it works. Neither of these invalidates the use
cases I or other people have that are better served by sysvinit. It is
pretty clear that systemd cannot ever handle these use cases, nor should
it attempt to.

This entire debate is really about the scope of the Debian project, so
this is not a technical decision that has a "right" answer. Either
choice we make here is going to hurt -- either we have to invest extra
work to continue sysvinit support, or we cease to be the "universal"
operating system as we drop support for quite a lot of embedded systems
currently running Debian or derivatives.

I think it is important to realize that a simple majority vote will not
get a satisfactory result here either. The majority does not care. We
have two factions with strong opinions and good arguments from their
respective points of view, and we need to find common ground.

In my opinion, Debian's strength used to be that we've always been able
to integrate as many choices as possible and provide a reasonable default.


[1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: