Language Selection

English French German Italian Portuguese Spanish

Ian Jackson on Debian Vote Regarding SystemD

Filed under
Debian

  • Debian GR on init systems - Ballot paper format

    You are allowed to reorder the choices on your ballot paper, and this is effective.

    That is, you can take the ballot paper in the CFV and edit the lines in it into your preferred order with cut and paste. You can look at the letters, or the Secretary's summary lines, when you do that.

    It's important to use a proper text editor and not linewrap things while you do this.

    After, that you can simply write numbers 1 to 8 into the boxes down the left hand side.

    Rank all the options. That way when you get your vote ack back, any parse failure will show up as a blank space in the ack.

  • Debian init systems GR - voting guide

    If you don't know what's going on, you may wish to read my summary and briefing blog post from a few weeks ago. There are 7 options on the ballot, plus Further Discussion (FD). With this posting I'm trying to help voting Debian Members (Debian Developers) cast their votes.

    I am going to be neutral about the technical merits of systemd. My advice does not depend on your opinion about that.

    So my advice here is addressed to people who like systemd and want to keep running it, and developing with it, as well as, of course, people who prefer not to use systemd. I'm even addressing readers who think systemd has useful features which they would like Debian packages to be able to use.

    However, I am going to be opinionated about one key question: My baseline is that Debian must welcome code contributions to support running without systemd, just as it welcomes code contributions for other non-default setups. If you agree with that principle, then this posting is for you. Unfortunately this principle is controversial. Several of the options on the current GR mean rejecting contributions of non-systemd support. So in that sense I am not neutral.

Philipp Kern: Voting for systemd

  • Philipp Kern: Voting for systemd

    I have voted putting Proposal F first, Proposal B second and everything else after Further Discussion. I think if something truly better than systemd comes around, people in Debian will not stand in the way of people making it work - even despite this GR passing. That's how systemd started out after all. But the fact that we also want to support inferior old ways holds us back.

    At the point where Debian decided on the question of upstart vs. systemd, to me upstart was not a valid contender anymore. I had to deal professionally with it and no-one really know how to hold it in the right way so that modifications to upstart jobs did not break the boot. For systemd - despite the complexity everyone mentions as the problem - I only recall one major one where a certain machine type did not boot anymore and that was actually due to a regression in udev. If we would be discussing this as we debate the next serious contender to systemd, I would vote differently.

Gunnar Wolf: GR vote: init systems

  • Gunnar Wolf: GR vote: init systems

    For Debian followers, it should not be a surprise: a new General Resolution regarding the init systems is underway, trying to finally settle the set of issues that stem from the way our project works, following the 2014-003 vote, init system coupling.
    Back in 2014, I find it quite understandable the project was not in a collective mental state that would have allowed for closure after the infamously long and flamey bug #727708.

    As others have shared theirs, and given this is a non-secret vote (choices will be spelt out once the vote is done), I am doing so as well.

Lucas Nussbaum's vote

  • Lucas Nussbaum: init systems GR vote

    At this point, I don’t think that it is useful anymore for Debian to spend energy on supporting several init systems. I believe that experimentation is useful, that Debian should support it, but that it does not need to happen inside Debian. Interested people can work on derivative distributions, or even just maintain a small set of packages installable on top of Debian that will add support for alternative init systems where needed.

Wouter Verhelst: GR 2019 002

  • Wouter Verhelst: GR 2019 002

    Just sent in my vote. After carefully considering what I consider to be important, and reading all the options, I ended up with 84312756.

    There are two options that rule out any compromise position; choice 1, "Focus on systemd", essentially says that anything not systemd is unimportant and we should just drop it. At the same time, choice 6, "support for multiple init systems is required", essentially says that you have to keep supporting other systems no matter what the rest of the world is doing lalala I'm not listening mom he's stealing my candy again.

    Debian has always been a very diverse community; as a result, historically, we've provided a wide range of valid choices to our users. The result of that is that some of our derivatives have chosen Debian to base their very non-standard distribution on. It is therefore, to me, no surprise that Devuan, the very strongly no-systemd distribution, was based on Debian and not Fedora or openSUSE.

Ian Jackson: Debian GR - vote without thinking?

  • Ian Jackson: Debian GR - vote without thinking?

    Since you can change your vote up to the deadline of 23:59:59 UTC on Friday 2019-12-27, you could run a rune like that now and then change your vote later if you get time to think about it properly.

    Obviously it would be best for you to read something like my voting guide and make up your own mind. But maybe it would be better to run my rune than not vote at all? Up to you I guess.

Ian Jackson: Debian GR on init systems - Ballot paper format

  • Ian Jackson: Debian GR on init systems - Ballot paper format

    This can get a bit confusing. The ballot options have letters (eg, "E"). They also have numbers, which show up on the vote page as "Choice 6" or whatever. Separately, there are the ranks you have to assign when voting, where 1 is your first preference, etc.
    On the ballot paper, the choices are numbered from 1 to 8. The letters appear too along with the Secretary's summaries. Your preferences also have to be numbered. It is important not to get confused.

    Reorder the ballot paper!

    You are allowed to reorder the choices on your ballot paper, and this is effective.
    That is, you can take the ballot paper in the CFV and edit the lines in it into your preferred order with cut and paste. You can look at the letters, or the Secretary's summary lines, when you do that.

    It's important to use a proper text editor and not linewrap things while you do this.

    After, that you can simply write numbers 1 to 8 into the boxes down the left hand side.

    Rank all the options. That way when you get your vote ack back, any parse failure will show up as a blank space in the ack.

Jonathan Dowland's Take on the Debian General Resolution

  • Jonathan Dowland: Debian's init system GR

    Debian is currently conducting a vote on a General Resolution entitled Init systems and systemd. I had a few brief thoughts about the circumstances around this that I wanted to share.

    I like systemd and I use it on all of my systems. That said, I have some concerns about it, in particular the way it's gradually eating up so much other systems software. The opportunity for alternatives to exist and get feedback from interested users seems important to me as a check and balance and to avoid a monoculture. Such an environment should even help to ensure systemd remains a compelling piece of software. The question that this GR poses is really whether Debian should be a place where alternatives can exist. In answering that question I am reminded of the mantra of Extinction Rebellion. I appreciate that is about a far more impotant topic, but it still seems pertinent: If not us, who? If not now, when?

    What is Debian for, anyway? Once upon a time, from a certain perspective, it was all counter-cultural software. Should that change? Perhaps it already has. When I was more actively involved in the project, I watched some factions strive to compete with alternative distributions like Fedora. Fedora achieves a great deal, partly by having a narrow and well-defined focus. With the best will in the world, Debian can't compete at that game. And why should it? If Fedora is what you want, then Fedora is right there, go use it!

Ian Jackson: Debian GR on init systems - Ballot paper format

  • Ian Jackson: Debian GR on init systems - Ballot paper format

    You are allowed to reorder the choices on your ballot paper, and this is effective.
    That is, you can take the ballot paper in the CFV and edit the lines in it into your preferred order with cut and paste. You can look at the letters, or the Secretary's summary lines, when you do that.

    It's important to use a proper text editor and not linewrap things while you do this.

    After, that you can simply write numbers 1 to 8 into the boxes down the left hand side.

    Rank all the options. That way when you get your vote ack back, any parse failure will show up as a blank space in the ack.

Jonathan McDowell on how he voted regarding systemd in Debian

  • Jonathan McDowell: This Week I Voted

    I made use of Ian Jackson’s voting guide (and should disclose that he and I have had conversations about this matter where he kindly took time to explain to me his position and rationale). However I’m more pro-systemd than he is, and also lazier, so hopefully this post is useful in some fashion rather than a simple rehash of anyone else’s logic.

    I ranked Further Discussion last. I want this to go away. I feel it’s still sucking too much of the project’s time.

    E was easy to rank as second last. While I want to support people who want to run non-systemd setups I don’t want to force us as a project to have to shoehorn that support in where it’s not easily done.

    I put F third last. While I welcome the improvements brought by systemd I’m wary of buying into any ecosystem completely, and it has a lot of tentacles which will make any future move much more difficult if we buy in wholesale (and make life unnecessarily difficult for people who want to avoid systemd, and I’ve no desire to do that).

    On the flip side I think those who want to avoid systemd should be able to do so within Debian. I don’t buy the argument that you can just fork and drop systemd there, it’s an invasive change that makes it much, much harder to produce a derivative system. So it’s one of those things we should care about as a project. (If you hate systemd so much you don’t want even its libraries on your system I can’t help you.)

Giovanni Mascellani: Debian init systems GR

  • Giovanni Mascellani: Debian init systems GR

    I don't think that nowadays the choice of the init system can neutral: like the choice of a kernel, a libc and some other core components, you cannot just pretend that everything can be transparently swapped with anything else, therefore Debian rightly has to choose a default thing (Linux, glibc, the GNU userland, and now systemd) which is the standard proposal to the casual user. Systemd has clearly become the mainstream thing for a lot of good reasons, and it is the choice the most Debian users and developers should adopt (this is not to say that systemd, its development mode or its goals are perfect; but we have to choose between alternatives that exist, not between ideal ones). This is the reason why imposing that any init system should be supported at the same level is silly to me, and therefore why option E is the last one, and the only one below Further Discussion; in much the same way as it would be silly to impose that kFreeBSD, Mach and musl should be supported at the same level of their default counterparts (although I would be pretty excited to see that happening!). We cannot expect any Debian contributor to have the resources to contribute scripts/units for any init system randomly appearing.

Debian votes on init systems

  • Debian votes on init systems

    In November, the topic of init systems and, in particular, support for systems other than systemd reappeared on the Debian mailing lists. After one month of sometimes fraught discussion, this issue has been brought to the project's developers to decide in the form of a general resolution (GR) — the first such since the project voted on the status of debian-private discussions in 2016. The issues under discussion are complex, so the result is one of the most complex ballots seen for some time in Debian, with seven options to choose from.

    Debian being what it is, the actual voting period for a contentious issue can be rather anticlimactic; the real debate happens during the framing of the ballot to be voted on. This time around was no exception, with extensive discussions on how to best represent various proposed policies, and even a debate over the use of the word "diversity" to describe the issue at hand (it was eventually taken out). Debian practice dictates that ballots work best if each option is written by its proponents, so there are many hands involved in creating the final product.

    That process also takes some time. Debian project leader Sam Hartman has seemed somewhat impatient throughout, trying to keep the discussion period to the minimum required by the Debian constitution. By his count, the minimum period ended on November 30; he issued his call for votes three days later. That, however, was too soon for Ian Jackson, who posted a proposal to override Hartman's call for votes so that further work could be done on the framing of the issues on the ballot. While some participants agreed with this idea, the project as a whole appears to be somewhat tired of this discussion and ready to make a decision.

Gregor Herrmann: init system GR

  • Gregor Herrmann: init system GR

    finally – the third call for vote has already gone out – I took the time to cast my vote in the debian init system GR (General Resolution), the vote of debian members about the project's further course with regard to init systems.

Yet Another Init decision

  • Yet Another Init decision

    I’m trying to use this to capture some of my thoughts on the current GR, and to document my approach to this vote. If nothing else, I hope to use this to convince myself that I’ve read and understood the various options in the GR.

    From my perspective, two of the choices on this ballot are easy to deal with, in that they have very clear meaning and the ramifications are easy to understand. We’re either all in on systemd and we don’t care about compatibility with other init systems, or we’re only loosely integrated with systemd and require that it be possible to replace it. It’s pretty easy to rank these two options relative to each other, depending on how you feel about systemd in general. The other options are the hardest to rank. They basically all come down to variants of “further discussion”, or of the status quo, with slight biases in one direction or another. The significance of them is the lens through which we want to view the situation, or how we want to frame the discussion.

    There are a few considerations for me when weighing the options against each other. First, I don’t want to have another discussion about init systems in Debian ever again. Second, I really like systemd the init system and am happy to use it just about everywhere. Third, while I like systemd the init system, I don’t care much for systemd the NTP client, systemd the DNS resolver, systemd the DHCP client, etc. Unfortunately, I think this leaves me somewhat conflicted about choosing any of the stronger options. I’m tempted to prefer “Focus on systemd”, but I worry about where that leads in the long run. In particular, the GR option doesn’t discuss this at all, except to say that “[i]ntegrating systemd more deeply into Debian will lead to a more integrated and tested system…“, which may well be true, but I’d like to stop the integration somewhat short of the point where we start considering whether to rename the project Debian GNU/systemd.

Jonathan Dowland: Debian's init system GR

  • Jonathan Dowland: Debian's init system GR

    Debian is currently conducting a vote on a General Resolution entitled Init systems and systemd. I had a few brief thoughts about the circumstances around this that I wanted to share.

    I like systemd and I use it on all of my systems. That said, I have some concerns about it, in particular the way it's gradually eating up so much other systems software. The opportunity for alternatives to exist and get feedback from interested users seems important to me as a check and balance and to avoid a monoculture. Such an environment should even help to ensure systemd remains a compelling piece of software. The question that this GR poses is really whether Debian should be a place where alternatives can exist. In answering that question I am reminded of the mantra of Extinction Rebellion. I appreciate that is about a far more important topic, but it still seems pertinent: If not us, who? If not now, when?

    What is Debian for, anyway? Once upon a time, from a certain perspective, it was all counter-cultural software. Should that change? Perhaps it already has. When I was more actively involved in the project, I watched some factions strive to compete with alternative distributions like Fedora. Fedora achieves a great deal, partly by having a narrow and well-defined focus. With the best will in the world, Debian can't compete at that game. And why should it? If Fedora is what you want, then Fedora is right there, go use it!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

XFS - Online Filesystem Checking

Since Linux 4.17, I have been working on an online filesystem checking feature for XFS. As I mentioned in the previous update, the online fsck tool (named xfs_scrub) walks all internal filesystem metadata records. Each record is checked for obvious corruptions before being cross-referenced with all other metadata in the filesystem. If problems are found, they are reported to the system administrator through both xfs_scrub and the health reporting system. As of Linux 5.3 and xfsprogs 5.3, online checking is feature complete and has entered the stabilization and performance optimization stage. For the moment it remains tagged experimental, though it should be stable. We seek early adopters to try out this new functionality and give us feedback. Read more

Linux 5.5 RC7

  • Linux 5.5-rc7
    Well, things picked up at the end of the week, with half of my merges
    happening in the last two days.
    
    Whether that is the usual "send the weeks work to Linus on Friday", or
    a sign that things are just picking up in general after the holidays,
    I don't know.  If the former, I'll probably just release the final 5.5
    next week. But if it looks like there's pent-up fixes pending next
    week, I'll make another rc.
    
    Nothing in here looks particularly odd. Drivers is about half of the
    patch (networking, sound, gpio, gpu, scsi, usb, you name it), with the
    rest being the usual mix - arch, networking, filesystems, core
    kernel..  The diffstat looks mostly fairly nice and flat, with a
    couple of exceptions that look harmless (a few device tree file
    updates, some pure code movemment, and a couple of driver fixes that
    ended up changing calling conventions to get done and as a result got
    to be more lines than the bug otherwise would have merited).
    
    Please do test, there should be nothing scary going on.
    
                  Linus
    
  • Kernel prepatch 5.5-rc7

    The 5.5-rc7 kernel prepatch is out. Linus is still unsure whether the final 5.5 release will come out next week or not: "if it looks like there's pent-up fixes pending next week, I'll make another rc".

  • Linux 5.5-rc7 Kernel Released

    The seventh weekly release candidate to Linux 5.5 is now available for testing. Linus noted with Linux 5.5-rc7 there was a large uptick in patch volume at week's end. "Well, things picked up at the end of the week, with half of my merges happening in the last two days." Due to the recent holidays in large part, it's possible an eighth release candidate may be needed for Linux 5.5 before then releasing the kernel as stable on 2 February. However, in today's 5.5-rc7 announcement, Torvalds noted he may just end up releasing 5.5 stable next week. In any case, the release of Linux 5.5 is right on the horizon and this should be the kernel powering Ubuntu 20.04 LTS and other upcoming distribution releases.

GNU Make 4.3 Released!

The next stable version of GNU make, version 4.3, has been released and is available for download from https://ftp.gnu.org/gnu/make/ Please see the NEWS file that comes with the GNU make distribution for details on user-visible changes. Read more Also: GNU Make 4.3 Released With Performance Improvements, Newer GNU libc + Musl Support

Kernel: Zhaoxin, Arch Linux's Zen and WireGuard in Linux 5.6

  • Zhaoxin 7-Series x86 CPUs Mitigated For Spectre V2 + SWAPGS

    When it comes to the Zhaoxin x86-compatible processors coming out of VIA's joint venture in Shanghai, their forthcoming 7-series (KX-7000) has hardware mitigations in place for some CPU vulnerabilities. We haven't heard much about these Chinese x86 CPUs with regards to speculative execution vulnerabilities but it appears the pre-7-Series is vulnerable to Spectre Variant Two and at least SWAPGS. But with their 7-series, hardware mitigations appear to be in place.

  • Benchmarks Of Arch Linux's Zen Kernel Flavor

    Following the recent Linux kernel tests of Liquorix and other scheduler discussions (and more), some requests from premium supporters rolled in for seeing the performance of Arch Linux's Zen kernel package against the generic kernel. Here are those benchmark results. These are some benchmarks I recently did on the AMD Ryzen Threadripper 3970X while running EndeavourOS. Tests were done with its default Linux 5.4.8-arch1 kernel compared to the same kernel revision but using Arch's Zen kernel flavor. That is Arch's spin of the Zen-kernel patches (not to be confused with AMD Zen).

  • Intel's ConnMan Is Ready With WireGuard Support

    In addition to NetworkManager having good WireGuard support in advance of this secure VPN tunnel tech landing with the Linux 5.6 kernel, Intel's ConnMan software is also ready with supporting WireGuard. Intel's ConnMan hasn't seen a new tagged release in nearly one year but over the past two months in the Git development code WireGuard support has materialized. ConnMan, as a reminder, is the Intel-led effort for providing an Internet connection manager on Linux designed for embedded/mobile use-cases that dates back to their Moblin days.