Hi, 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 system. 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. Simon [1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html
Attachment:
signature.asc
Description: OpenPGP digital signature