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

Intel: HEVC, ANV Vulkan Driver, Linux 5.7 and New Security Hole

  • Intel Adds VA-API Acceleration For HEVC REXT To FFmpeg

    Intel open-source developers have contributed support for VA-API acceleration of HEVC REXT "Range Extensions" content with the widely-used FFmpeg library. HEVC Range Extensions are extensions to H.265 geared for areas of content distribution, medical imaging, still imaging, and more. Among the changes with HEVC REXT are supporting 4:2:2 and 4:4:4 chroma sampling formats. HEVC Range Extensions are laid out in much more detail in this IEEE.org paper.

  • Intel Boosts Gen7 GPU Vulkan Compute Performance By ~330% For Geekbench

    Intel's open-source "ANV" Vulkan driver for Linux doesn't see much attention for pre-Broadwell hardware but today it saw a big improvement for Vulkan compute on aging Gen7 Ivybridge/Haswell era hardware. Jason Ekstrand, the lead developer of the Intel ANV Vulkan driver, discovered that in their driver's pipeline code the data cache functionality would end up being disabled when a shader was pulled out of the pipeline cache. For Broadwell/Gen8+ the data cache bit was being ignored but this oversight ended up having huge implications for Gen7 Intel graphics hardware (Ivybridge/Haswell) as the oldest supported by Intel's Vulkan driver.

  • Intel Has Accumulated 400+ Graphics Driver Patches So Far For Linux 5.7

    Intel just sent out their initial pull request of new feature changes/improvements to DRM-Next that in turn is for landing in about one month's time when the Linux 5.7 merge window kicks off. With taking longer than usual to send in their first round of feature updates, this first of several pull requests already amounts to over 400 patches. While it is a big pull request given the extra time for patches to accumulate, there aren't too many user-facing changes. Though there is a lot of enablement work for Tiger Lake as well as continuing Gen11 Ice Lake and Elkhart Lake work. For Ice Lake / Elkhart Lake there are a number of driver workarounds added. For Gen12 / Tiger Lake there are workarounds, display fixes, RPS is re-enabled, and other work.

  • Intel KVM Virtualization Hit By Vulnerability Over Unfinished Code

    At least not another hardware vulnerability, but CVE-2020-2732 appears to stem from unfinished code within the Intel VMX code for the Linux kernel's Kernel-based Virtual Machine (KVM) support. CVE-2020-2732 as of writing isn't yet public but we've been closely monitoring it since seeing a peculiar patch series earlier today and not finding much information on it.

Hardware and Devices for GNU/Linux

Screenshots/Audiocasts/Shows: Netrunner 20.01, Linux Headlines, This Week in Linux and Pandas

  • Netrunner 20.01 – Twenty Run Through

    In this video, we are looking at Netrunner 20.01 – Twenty.

  • 2020-02-25 | Linux Headlines

    Manjaro hits version 19, Firefox starts rolling out DNS over HTTPS by default in the US, Puppet releases version 2 of Bolt, and Mirantis commits to the future of Docker Swarm.

  • This Week in Linux 94: Mesa 20, PipeWire, Linux Be Scary, MyPaint, GTK, Microsoft Defender

    On this episode of This Week in Linux, we got some new releases from core projects like Mesa & PipeWire and we also got some App News from MyPaint, GTK and a new convergent apps project called Maui. Then we’ll check out some distro news regarding the Untangle Firewall and some Red Hat news about CoreOS Container Linux. Later in the show, we’ll cover some really interesting news from Nvidia about Ray Tracing to Vulkan. Someone in the UK Police thought it was a good idea to warn parents their kids may become hackers and Microsoft announced their Microsoft Defender is coming to Linux. Then we’ll round out the show with some great deals for Games, Books and Comics from Humble Bundle. All that and much more on Your Weekly Source for Linux GNews!

  • Data School: How to merge DataFrames in pandas (video)

    In my new pandas video, you're going to learn how to use the "merge" function so that you can combine multiple datasets into a single DataFrame. Merging (also known as "joining") can be tricky to do correctly, which is why I'll walk you through the process in great detail. By the end of the video, you'll be fully prepared to merge your own DataFrames!

Events: LibOCon, CHAOSScon, SUSE in Paris, Open Networking & Edge Summit North America 2020

  • LibreOffice Conference 2021 Call for Locations

    Once a year, the LibreOffice Community gathers for a global community event: the LibreOffice Conference, or LibOCon. After a series of successful events – Paris, October 2011; Berlin, October 2012; Milan, September 2013; Bern, September 2014; Aarhus, September 2015; Brno, September 2016; Rome, October 2017; Tirana, September 2018 and Almeria, September 2019 – the venue for 2020 is Nuremberg, Germany. To ease the organization, TDF Board of Directors has decided to open the call for location for 2021 earlier this year, to give the 2021 event organizers the opportunity of attending the conference in Nurembers in October 2020. The LibreOffice Conference takes place between September and November, with a preference for September. The deadline for sending in proposals is June 30, 2019. After receiving the applications, we will evaluate if all pre-conditions have been met and the overall content of the proposal, and give all applicants a chance to answer questions and clarify details if needed.

  • CHAOSScon EU 2020: play by play

    This is my second time attending CHAOSScon. I attended on behalf of RIT LibreCorps to represent our engagement with the UNICEF Office of Innovation and the Innovation Fund. For CHAOSScon EU 2020, I arrived hoping to learn more about effective metric collection strategies for open source communities and also get a deeper understanding of the technology behind GrimoireLab.

  • When in Paris, learn how SUSE empowers DevOps teams with HPE

    We will be there (Booth #21) to meet with Presales Consultants and Solution Architects from both HPE and Partners and chat about how we are working with HPE to deliver software-defined infrastructure with an open approach.

  • Keynote Speakers Announced For Open Networking & Edge Summit North America 2020

    The open networking event has now been expanded to cover Edge Computing, Edge Cloud and IoT. The event focuses on collaborative development and innovation across enterprises, service providers/telcos and cloud providers to shape the future of networking and edge computing with a deep focus on technical, architectural and business discussions in the areas of Open Networking & AI/ML-enabled use cases.