Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday November 19 2014, @11:25AM   Printer-friendly
from the I-hope-we-don't-regret-this dept.

Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.

The vote results can be found here

The winners are:

Option 4 "General Resolution is not required"

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by opinionated_science on Wednesday November 19 2014, @03:07PM

    by opinionated_science (4031) on Wednesday November 19 2014, @03:07PM (#117698)

    I wondered about the voting options too. Opensuse has had systemd wrapped in init-scripts for a few years now. I don't have a problem with systemd, with the exception I don't like the binary blob logs. They should use zip like everyone else!!

    Anyway, we should remember the enemy is the non-FOSS proprietary industry that exists solely to lock-in consumers.

    I would hope well all remember this.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by mechanicjay on Wednesday November 19 2014, @05:53PM

    by mechanicjay (7) <{mechanicjay} {at} {soylentnews.org}> on Wednesday November 19 2014, @05:53PM (#117761) Homepage Journal

    Opensuse has had systemd wrapped in init-scripts for a few years now.

    Yes, 12.3 was okay, but 13.1 was basically broken because of it. With 13.2 they seem to have completed the transition to systemd, which is good as the init system is actually controllable now.

    I'm still torn on the whole thing, honestly. systemd is maturing and working better, which is good. I don't really have a good technical argument for or against it. It just breaks with the historic philosophy of doing one small thing well, and chaining together the tools, which is why I'm upset about it.

    A technical argument cannot overcome a philosophical divide, which I think is what this whole thing boils down to: People who have a philosophical objection to a tool like this, and those who don't. Unfortunately, this ends up with straw-man argument flame-wars, rather than keeping everyone happy and staying init system agnostic -- which baffles me.

    --
    My VMS box beat up your Windows box.
    • (Score: 2) by opinionated_science on Wednesday November 19 2014, @05:59PM

      by opinionated_science (4031) on Wednesday November 19 2014, @05:59PM (#117763)

      exactly - so long as it works i am not bothered. My only technical complaint about systemd it the opaque logs - maybe it is buried in a manual somewhere, but any log i cannot open with less/vi is broken.

      Logs are for humans - databases are for machines.

    • (Score: 2) by Arik on Wednesday November 19 2014, @08:05PM

      by Arik (4543) on Wednesday November 19 2014, @08:05PM (#117826) Journal
      "I'm still torn on the whole thing, honestly. systemd is maturing and working better, which is good. I don't really have a good technical argument for or against it. It just breaks with the historic philosophy of doing one small thing well, and chaining together the tools, which is why I'm upset about it."

      You need to think on this more clearly. That historical philosophy is either important and should be followed for technical reasons (which I believe to be correct) or else it's not relevant at all here.

      You do one thing and do it well, because it's possible to verify a simple tool with a clearly defined role actually does what it's supposed to do, and not more, and doing that is the key to keeping a sane system that works as it should.

      You avoid designing monsters like systemd not for some disconnected 'philosophical' reason but because decades of experience show that monsters like that are impossible to do right. They are far too complicated to verify - too much code and too many code-paths. Too many pieces of it that will rarely be executed, where bugs can sit for years without being noticed.

      If systemd is still in use in 10 years, they will just be beginning to find the bugs they are writing today.
      --
      If laughter is the best medicine, who are the best doctors?
      • (Score: 2) by cafebabe on Thursday November 20 2014, @03:57AM

        by cafebabe (894) on Thursday November 20 2014, @03:57AM (#117985) Journal

        You do one thing and do it well, because it's possible to verify a simple tool with a clearly defined role actually does what it's supposed to do, and not more, and doing that is the key to keeping a sane system that works as it should.

        As fairly well defined and protocol specific examples, some of problems in bind and Apache httpd have occurred due to the conflated role of serving authoritative data and caching data from other servers. Neither of these implementations are doing one thing well.

        --
        1702845791×2