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

Ubuntu’s Installer Slideshow Gets a Focal Refresh

Ubuntu’s installer slideshow isn’t something most of us spend an awful time looking at but for new users it serves an important educational goal. The Ubiquity desktop installer plays a slideshow during the main part of the install process. Each slide highlights a key feature or important function available in Ubuntu (or whichever Ubuntu flavour is being installed). The slideshow has been a staple part of Ubuntu (and many flavours) since it was introduced back in Ubuntu 10.10. For the upcoming release of Ubuntu 20.04 the look of the slideshow will better match the look of Yaru, Ubuntu’s default GTK theme (which recently got a big update of its own). Read more

Linux Mint with Windows 7 Theme

This article explains step by step to change GNU/Linux Mint operating system user interface to mimic W7 especially after its official support ended in this January 2020. You can practice this tutorial in Cinnamon Edition and you will install 2 types of theme plus 1 original wallpaper here. By this tutorial, I want to help people who find it's easier to migrate to Free Software if their desktop looks like their previous OS. I believe helping them are good and useful. And I hope by publishing this more people will come to help B00merang Project and others alike to develop these themes. I hope your switch from W7 to GNU/Linux goes easier, smoother, and perfect. Enjoy! Read more

Kernel/Graphics: AMD, Intel and Mesa

  • AMD vs. Intel Contributions To The Linux Kernel Over The Past Decade

    Driven by curiosity sake, here is a look at how the total number of AMD and Intel developers contributed to the upstream Linux kernel during the 2010s as well as the total number of commits each year from the respective hardware vendors.  These numbers were obtained by looking at the Linux kernel commits in Git from AMD.com and Intel.com addresses. Granted, sometimes developers from both companies will use their personal email addresses rather than the corporate ones, but for this comparison is looking solely at the Git commits from the respective corporate domains.

  • Linux k10temp Driver For AMD CPUs Updated To Better Handle Power/Temp Analysis

    As we have been eagerly talking about for the past week, the Linux kernel's k10temp driver was updated for better AMD CPU CCD temperatures and voltage/current reporting. Those improvements have been quickly evolving thanks to the work of the open-source community with AMD still sadly holding the datasheets concerning the power/temperature registers close to their vest. A new version of k10temp was sent out on Wednesday.  As reported earlier this week, these k10temp improvements could land for the upcoming Linux 5.6 but additional testing is needed. While Zen 2 CPUs have been shipping for months, these k10temp improvements are only coming now thanks to HWMON maintainer Guenter Roeck who continues working on this driver in cooperation with the community as AMD currently isn't releasing documentation/datasheets concerning the power/thermal registers or any reference code for that matter... Many Linux desktop users dream of seeing something someday like AMD Ryzen Master coming to Linux. 

  • Gutting Out Intel MPX Support To Be Finished Up In The Linux 5.6 Kernel

    The Linux support for Intel MPX has already been pretty much dead since the GCC 9 compiler dropped support for MPX. Kernel developers following that began working to remove MPX from the kernel over not having the compiler support, MPX not being widely used, and also not much code movement on the kernel side. Memory Protection Extensions (MPX) was talked up years ago by Intel for allowing the checking of pointer references at run-time to avoid buffer overflows and other potential related vulnerabilities. But in reality it didn't become too popular with developers while AddressSanitizer and other compiler sanitizer infrastructure has become more used and without the need for special bits in the CPU. Intel themselves meanwhile have deprecated MPX and say the support won't be available on future CPUs, hence not being concerned much about the Linux support departing.

  • Mesa 20.0 branchpoint planned for 2020/01/29, Milestone opened
    Hi list, due to some last minute changes in plan I'll be managing the 20.0
    release. The release calendar has been updated, but the gitlab milestone wasn't
    opened. That has been corrected, and is here
    https://gitlab.freedesktop.org/mesa/mesa/-/milestones/9, please add any issues
    or MRs you would like to land before the branchpoint to the milestone.
    
    Thanks,
    Dylan
    
  • Mesa 20.0 Feature Development Is Ending Next Week

    Mesa developers are planning to end feature work on Mesa 20.0 next week as this first quarter update to the Mesa 3D graphics stack. There has been a heck of lot building up for Mesa 20.0 including many ACO optimizations, many RadeonSI and RADV improvements around GFX10/Navi, Intel Gallium3D improvements, OpenGL 4.6 with NIR by default for RadeonSI, NIR support for LLVMpipe, Vulkan 1.2 for Intel ANV and Radeon RADV, and a whole lot more... My usual feature overview will be out after the code has been branched.

SUSE/OpenSUSE: Conferences, Fonts and SUSE CaaS Platform

  • 7 tips to survive booth duty at a conference-events

    If you contribute to an open-source community, there will be an "opportunity" that you will represent the community to a conference. You're expected to staff the booth and talk to people about the software. For some people, it looks like you are traveling and having fun. I have news for you. It's not like that. We are going to see some tips on how to survive the booth duty.

  • https://fontinfo.opensuse.org/ updated

    The information below might fall into the "unsung heroes of openSUSE" category - we think it is clearly worth to be mentioned and getting some applause (not saying that every user should owe the author a beer at the next conference ;-).

  • Introducing… Stratos for SUSE CaaS Platform

    Would you like to make your SUSE CaaS Platform clusters simpler and more intuitive to manage? Do you want to be able to manage multiple clusters from a single pane of glass, whether on premise or in public clouds? Would you like to be able to deploy applications to your clusters, no matter whether they are in a SUSE repository, other public repositories, or your organization’s private repositories? SUSE CaaS Platform is introducing a tech preview of Stratos Console, a powerful browser-based graphical interface that delivers multi-cluster, multi-cloud management. You can assess the status and health of all of your managed clusters at a glance with multi-cluster overview dashboards, then drill down into any cluster for fine grained management of its workloads and resources.