Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Debian Open Source Linux

Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team 550

An anonymous reader writes Debian developer Tollef Fog Heen submitted his resignation to the Debian Systemd package maintainers team mailing list today (Sun. Nov. 16th, 2014). In his brief post, he praises the team, but claims that he cannot continue to contribute due to the "load of continued attacks...becoming just too much." Presumably, he is referring to the heated and, at times, even vitriolic criticism of Debian's adoption of Systemd as the default init system for its upcoming Jessie release from commenters inside and outside of the Debian community. Currently, it is not known if Tollef will cease contributing to Debian altogether. A message from his twitter feed indicates that he may blog about his departure in the near future.
This discussion has been archived. No new comments can be posted.

Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team

Comments Filter:
  • by tfheen ( 128718 ) on Sunday November 16, 2014 @04:59PM (#48398455) Homepage

    I am not resigning from Debian, just from the systemd maintainer team.

    • by skaag ( 206358 ) on Sunday November 16, 2014 @05:09PM (#48398505) Homepage Journal

      Glad to hear. And for what it's worth, I think it's a shame some elements in the community behaved like they did. I chalk it off to them being immature twats, but mostly it's that people are people, and a good chunk of humanity are just idiots.

      • by Anonymous Coward

        Yet both sides believe the other side is the idiots.

        • by mysidia ( 191772 ) on Sunday November 16, 2014 @05:55PM (#48398825)

          Exactly. Using ridiculous namecalling for folks challenging systemd such as "immature twats" is taking sides. It's not possible to have a reasonable collaboration so long as systemd has activist fans who do not take the time and care to understand the criticisms.

          • by Anonymous Coward

            And the criticism [boycottsystemd.org] from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.

            Systemd is inherently contrary to many of the core philosophies that underlie the Debian project, and that underlie UNIX and UNIX-like systems in general. Many of the criticisms of it just cannot be refuted. Bad ideas will be bad ideas, and systemd is objectively full of t

            • by gmack ( 197796 ) <gmackNO@SPAMinnerfire.net> on Monday November 17, 2014 @01:09AM (#48400339) Homepage Journal

              And the criticism [boycottsystemd.org] from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.

              I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety [freedesktop.org] and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.

              At any rate, I find it very telling that they don't actually mention any of their supporters.

        • by tfheen ( 128718 ) on Sunday November 16, 2014 @06:05PM (#48398881) Homepage

          Yet both sides believe the other side is the idiots.

          If you make that "some people on both sides", I agree with you.

          There are certainly good people on the anti-systemd side (and I'm sure there are poisonous people on the pro-systemd side too). People being skeptical and saying that we should be careful adopting everything it provides. I don't agree with them (at least not fully), but my resignation from the maintainer team is not about people being skeptical, it's about personal attacks, it's about death wishes from project members and it's about people escalating conflicts instead of trying to resolve them.

          (I do agree with them in that we should think about what technologies we adopt by default and which we don't. As an example, systemd-resolved is not enabled by default. As the recent CVE shows, that wasn't a bad decision. We might change it in the future, but we should absolutely think about the maturity of the components we enable, in particular those enabled by default.)

          • by slimjim8094 ( 941042 ) <{slashdot3} {at} {justconnected.net}> on Sunday November 16, 2014 @07:19PM (#48399169)

            Death wishes are never cool.

            But what do you think people should do instead of escalate? I think at this point it's pretty clear that there are fundamental (some might say philosophical) disagreements at play here that haven't been resolved yet - and may be unresolvable (people are talking seriously about forking Debian over this). Escalation seems like exactly the appropriate step. When I'm at work, if I don't agree with a decision I talk about it with my boss - but if we can't reach an agreement and I feel strongly that it's the wrong decision, I take it to his boss, and so on if necessary. I would be remiss if I didn't!

            Honestly, many systemd proponents seem annoyed that people aren't accepting their decision without question, when what they propose is a pretty serious departure from a pretty fundamental system design philosophy. I don't know what to make of that.

            • by tfheen ( 128718 )

              By escalate, I mean escalating the conflict rather than appealing to some judicial body. (A trivial example would be for you to say "Implement feature X or I'll resign", or if it's an unarmed robbery, pulling out a gun.)

              Asking for help resolving the conflict (which is another use of the word escalate) is of course ok. (English has many words, but does that help, when half of them have multiple meanings?)

            • by PvtVoid ( 1252388 ) on Sunday November 16, 2014 @09:19PM (#48399733)

              Death wishes are never cool.

              But what do you think people should do instead of escalate?

              Maybe accept that the larger group of people you're a part of has come to a decision you disagree with, and move on? People who can't let go of their personal hobby horse can be utterly poisonous to an organization, no matter how righteous they view their cause to be.

              • by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Monday November 17, 2014 @12:29AM (#48400257) Homepage Journal

                Maybe accept that the larger group of people you're a part of has come to a decision you disagree with, and move on?

                That's not what happened, however. A very small group of people, divided in itself, reluctantly came to a decision that affects others — and these others do not clearly support that decision in the majority either.

                People who can't let go of their personal hobby horse can be utterly poisonous to an organization, no matter how righteous they view their cause to be.

                So you're saying that systemd is a mistake?

          • by hairyfeet ( 841228 ) <bassbeast1968@gm ... minus herbivore> on Monday November 17, 2014 @06:33AM (#48400975) Journal

            I have a question, which I hope won't be ignored simply because I'm the "token Windows guy" here, because this one has been puzzling me when it comes to Debian..

            Since Debian is known as the "super stable" distro and from what we've seen systemd obviously still has some issues to be worked out why not simply have systemd in testing and have stable without? Correct me if I'm wrong but as I understand it Debian has stable and testing yes? So why the rush to put systemd in stable when it appears to make more sense to have it in testing until all the bugs are ironed out, or at least not make it the default until the thing is ready?

            I mean I could understand this if it were Ubuntu, whose motto might as well be "so bleeding edge the ISOs have stigmata" but that has never the kind of image that Debian has projected. While I'm not the conspiracy nut type having every distro push this including the ones known for being conservative? It DOES smell hinky as well as give off the whiff of a bit of "good old boys club", especially since its from the same guy that gave the world Pulse way way WAY before it was ready.

            So I just don't get it, why not diffuse the whole thing, leave it in testing until the bugs are ironed out and once its features are all ironed out THEN put it in stable? I don't know all the backstage politics so maybe there is political considerations but from a strictly logical standpoint that sounds like the best way to go...so what am I missing?

            • by ruir ( 2709173 ) on Monday November 17, 2014 @06:48AM (#48401017)
              Yep, I have just asked myself that too many times. It goes without saying that the deeper you dig, the systemd decision is political one and not a technical one. Furthermore, it is rather stupid that forcibly all the installations or upgrades are made to systemd without your decision or consent.
              • Oh good so its not just me then? Because I thought I surely had to have missed something because Debian has the image of stability yet here we are with another "masterpiece" by the same guy that shoved Pulse out when it wasn't even alpha quality yet Debian is suddenly jumping on with this ultra bleeding edge? Why? Why would they risk their rep by shoving out the door something this uncooked?
        • by Ol Olsoc ( 1175323 ) on Monday November 17, 2014 @09:36AM (#48401655)

          Yet both sides believe the other side is the idiots.

          And they are both 100 percent correct.

      • by Anonymous Coward

        ... it's a shame some elements in the community behaved like they did. I chalk it off to them being immature twats ...

        If the Debian team never shove that unneeded thing down the throats to the users none of the heated exchange would have happened in the first place

        And to call others "immature twats" you are showcasing yourself to the world how "mature" you really are!

        • by Anonymous Coward on Sunday November 16, 2014 @05:56PM (#48398833)

          If the Debian team never shove that unneeded thing down the throats to the users

          Serious question here: how avoidable is systemd currently?
          It seems the number of holdouts among the distributions is shrinking ever more quickly.

          systemd seems to be incorporating ever more functionality in itself. That in itself should be a problem, but it seems that the equivalent functionality outside of systemd is being lost at the same time.

          • udev has been moved into the project
          • consolekit has become orphaned

          Not sure what the status is with the other stuff systemd is preparing to replace.

          Add to that the increasing hard dependencies, like with window managers that expect systemd to offload session management and login onto and I'm not sure how feasable holding out on systemd is anymore.

          Sure, if a sufficiently large group of developers were bothered enough with the presence of systemd they could set out to provide the functionality the traditonal way and form a whole bunch of projects, including some sort of desktop environment.
          But it seems systemd managed to assimilate responsibilities more quickly than resistance could form and forking of projects to non-systemd dependent versions could occur.

          • by stoborrobots ( 577882 ) on Monday November 17, 2014 @01:08AM (#48400333)

            Serious question here: how avoidable is systemd currently?

            For what it's worth, I managed to purge everything systemd-related from my debian testing system the other day. I had to replace NetworkManager with WICD, which is a pretty good straightforward replacement (although you need to re-create your configuration). Also, I run KDE, so that made things easier.

            As I understand it (if I correctly noted the packages which got removed), you can't run a gnome system without systemd; however, you can still run debian jessie with kde without systemd.

            The only packages which are coming from the systemd source package on my system any more are udev and libsystemd0 - however, given that systemd-sysv and systemd-logind are no longer installed, I consider that basically a win.

            libsystemd0 is only still there because cups-daemon and kde-runtime require it; but given that it only defines the interfaces, it seems benign.

            udev [debian.org] and libudev1 [debian.org], despite being packaged as part of the systemd source, do not depend on it according to the package info...

    • by Aethedor ( 973725 ) on Sunday November 16, 2014 @05:09PM (#48398507) Homepage
      RemainAfterExit=yes
    • by vivaoporto ( 1064484 ) on Sunday November 16, 2014 @05:10PM (#48398525)
      Taking advantage of your presence in here and, trying to keep as much away from the merits of the criticism (or lack thereof), can you shed some light on the process that led to the adoption of systemd as the default init system for Debian?
      • by tfheen ( 128718 ) on Sunday November 16, 2014 @05:35PM (#48398675) Homepage

        It's a pretty long story. If you want to read all of it, you probably need to read the entire debian-devel and debian-ctte archives from approximately a year and a half ago until February/March this year.

        A shorter summary is something like (from my memory, coloured by my views, etc, but I believe it's largely correct). User names are generally @debian.org, finger $user@db.debian.org for full names and such. It's a bit rambling and written in one go, but it's what you get this time:

        - I upload systemd to Debian about a month after its initial release, get it into a ok-ish shape for wheezy, but not anywhere near suitable for being the default.
        - Other distros start switching to systemd as default, various people in Debian start discussing if we should switch to systemd. Some people say yes, some no, some want to switch to upstart. Bickering and discussions in equal measure spread out across all media (IRC, blogs/planet, mailing lists, in-person discussions). Most of it reasonably civil.
        - At some point, paultag files https://bugs.debian.org/cgi-bi... [debian.org] (_massive_ bug report, you don't want to read it all) , asking the Debian technical committee to default on what the default should be.
        - Lots of discussions happen, we use a bit of liw's and rra's Essay Debate System (https://wiki.debian.org/Debate, https://wiki.debian.org/Debate... [debian.org]) to structure the debate. It's Debian, it has to be A System.
        - vorlon (Steve Langasek) sets up VMs using the various init systems for the Technical Committee members to play with. They do so and write up their findings and arguments. rra's writeup is at https://lists.debian.org/debia... [debian.org] and is possibly the best comparison I've ever read of init systems. Lots more discussions happen. I contribute a fair bit with my systemd maintainer hat on (though we're at this point a team maintaining systemd in Debian) and is very happy this happens while I'm holidaying in Spain so I don't have to deal with a day job at the same time.
        - A lot of arguing internally to the CTTE whether to couple the question of what the default init system should be with whether it's ok for packages to require a given init system. bdale resolves the knot by calling for votes on a proposal very quickly after proposing a ballot. iwj sees this as backstabbing and is still very, very angry about this to this day.

        The vote ends with systemd being the winner, after bdale's casting vote as the CTTE chair.

        After this, there is an attempted General Resolution in March, which fails to get enough seconds, this is restarted by iwj on late October this year. The goal of this GR appears to be to forbid packages to depend on a specific init system.

        • by the_B0fh ( 208483 ) on Sunday November 16, 2014 @06:03PM (#48398863) Homepage

          iwj's rebuttal to rra's write up:

          https://lists.debian.org/debia... [debian.org]

        • by whoever57 ( 658626 ) on Sunday November 16, 2014 @06:59PM (#48399077) Journal
          What I see reading that is that the OpenRC was not seriously considered. There are a bunch of claimed requirements that appear to rule out OpenRC, but I don't see those requirements tracked back to any benefits. Perhaps the justification for those requirements is obvious to those who made the decision, but it isn't obvious to me.

          Taking the requirements in turn:

          * Lack of integration with kernel-level events to properly order startup.

          So what? OpenRC has dependency built in and the added improvement of integration with kernel-level events would bring only a very minor improvement.

          * No mechanism for process monitoring and restarting beyond inittab.

          In my experience, this is solving a non-problem. I don't experience processes dying and needing an immediate re-start without any other action.

          * Heavy reliance on shell scripting rather than declarative syntax.

          So what?

          * A fork and exit with PID file model for daemon startup.

          Not sure what advantage this brings.

          • by thegarbz ( 1787294 ) on Sunday November 16, 2014 @10:14PM (#48399911)

            * No mechanism for process monitoring and restarting beyond inittab.

            In my experience, this is solving a non-problem. I don't experience processes dying and needing an immediate re-start without any other action.

            Just because you don't doesn't mean no-one does. There have been enough users as vocal supporters of this feature that it clearly is an issue to be considered, and not just a non-problem. I've once had sshd randomly crash. Very randomly. Nothing appeared to cause it and it has worked ever since. A headless server with no management console. I wonder to this day if I had another option than simply hitting the reset button on the front.

            * Heavy reliance on shell scripting rather than declarative syntax.

            So what?

            Not all of us are programmers who want to churn out lines of shell script to get simple software started. 200+ lines of scripting to start sshd on my system is a design flaw not a feature imo. By comparison the upstart file for sshd is 13 lines and achieves more i.e. process monitoring, event based startup and re-starting.

            • Re: (Score:3, Interesting)

              by Nikademus ( 631739 ) *

              I've once had sshd randomly crash. Very randomly. Nothing appeared to cause it and it has worked ever since. A headless server with no management console. I wonder to this day if I had another option than simply hitting the reset button on the front.

              What if it was someone attacking your sshd and making it crash when it failed?
              By automatically restarting it, you just allow the attacker to continue trying to exploit it.
              By automatically restarting it, you don't solve the issue that makes it crashing.
              By automatically restarting it, you, most of the time, don't even see it restarted, so really not giving you any way to solve the real problem.

              It's not that I don't find process monitoring interesting, it's just tha

              • What if it was someone attacking your sshd and making it crash when it failed?

                By automatically restarting it, you just allow the attacker to continue trying to exploit it.

                By automatically restarting it, you don't solve the issue that makes it crashing.

                By automatically restarting it, you, most of the time, don't even see it restarted, so really not giving you any way to solve the real problem.

                It's not that I don't find process monitoring interesting, it's just that automatically restarting can bring more problems than it solves.

                As with any service, the "correct" action upon a crash is probably dependent on what the machine is actually supposed to be doing. Take for example, a dedicated web server - having Apache do down when under attack and not attempt to recover would be bad since the attacker will have successfully caused a denial of service with very little effort. Compare to a private telephone exchange, for example, which is running a web server purely for management purposes - a crashed web server is not a disaster, the w

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      I'd just like to take the opportunity to thank you for your work. I have used Debian for many years now and feel I seldom get the opportunity to say how much I appreciate it. So, a big thank you to you and the many other hard-working individuals creating Debian! Don't let this argument stick to you. I hope you continue with other Debian stuff! You are truly doing a magnificent job!

    • What do you think is the greatest misconception people not liking systemd have about it?

      • by tfheen ( 128718 ) on Sunday November 16, 2014 @05:48PM (#48398779) Homepage

        What do you think is the greatest misconception people not liking systemd have about it?

        It's a new system, so some things work differently. Many people seem to fail to see the line between bugs and intentional behaviour. If something doesn't work as before, it might not be because we're evil bastards who are out to steal your logs. It might just be that there's a bug in some package which means your logs aren't correctly forwarded from the journal.

        Sometimes it might be that systemd makes other assumptions about what something means and we're just failing to catch that in an upgrade check that should warn you about this. An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.

        Assumptions, as so often before, are the mother of all fuckups. Asking (preferably in a civilized manner) will get you a long way: "Hey, I'm not seeing my logs appear in syslog, is this supposed to be that way, and if not, can you help debug?"

        This might not be the greatest misconception, but I think it's the most common one. The greatest is possibly the conspiracy theory that this is all a takeover attempt from RH to kill other Linux distributions and that people pushing systemd are either shills or just unwittingly working against the distro they're pushing systemd into. I'm not sure how adopting a free software component (which sure, happens to be largely maintained by RH engineers, like many other free software components we use to build a distro) will turn us all into corporate-loving robots giving up freedom to be near the source of systemd.

        • by 0123456 ( 636235 ) on Sunday November 16, 2014 @05:53PM (#48398809)

          An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.

          And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.

          • Re: (Score:3, Informative)

            by Peter H.S. ( 38077 )

            And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.

            Well, systemd behaves according to classic "Unix Philosophy", see here under "Rule of repair":
            http://en.wikipedia.org/wiki/U... [wikipedia.org]

            A system shouldn't be allowed to boot if important disks are missing since this can lead to "silent" data corruption".

            systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can the

          • by tfheen ( 128718 ) on Sunday November 16, 2014 @06:13PM (#48398915) Homepage

            An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.

            And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.

            Yes, this is a bug (sorry, I don't have the bug # handy) and there's work in progress on preventing you from shooting your foot off (by requiring you to fix your fstab before the installation completes). It's still possible to boot up using sysvinit by booting with init=/lib/sysvinit/init as long as you've not uninstalled the sysvinit package. I'm sorry about people hitting this, but on the other hand, there's a reason why Jessie isn't released yet, we have some bugs to fix first. :-)

            • by DMJC ( 682799 ) on Monday November 17, 2014 @12:17AM (#48400229)
              I had this problem recently when I upgraded my Mac OSX installation to 10.10. It completely broke the /media/OSX mountpoint when the hfsplus filesystem was upgraded to CoreStorage and the hfsplus Linux support broke. The last thing I needed was my Debian installation to crap itself when I was just trying to boot into Linux for the first time since replacing/fixing the bootloader which OSX broke. A lot of people dual/triple booting are going to be affected by these changes. I honestly don't know if systemd is a good thing or a bad thing, but I'd have liked there be a lot more information about this change before it appeared in Debian. As was mentioned just before, I am also concerned that this change is potentially going to break cross platform compatibility with BSD/Solaris/Other Unixes. I develop software which was gtk based and it sounds as if gnome is going to require a lot of dependancies which are not available on other platforms.
        • by beaverdownunder ( 1822050 ) on Sunday November 16, 2014 @08:35PM (#48399539)

          It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.

          It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.

          Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.

          At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.

          Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.

          At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.

          Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.

          I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.

          It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.

        • Systemd to me seems overly complicated to the point where I can't work out how to fix things and more importantly (I might be thick), other people don't seem to be able to to offer assistance. I asked the questions properly, but the discussion ended with "dunno" as the result.

          In the olden days, the sleep button on a laptop caused an acpi event. That was passed to a shell script in /etc/acpi which could then do stuff. Two sane options were to send the laptop top sleep or generate a fake keypress for XK_XF86S

    • A bit of background (Score:5, Informative)

      by tfheen ( 128718 ) on Sunday November 16, 2014 @07:08PM (#48399125) Homepage

      Just posted on my blog with a bit more background: http://err.no/personal/blog/te... [err.no]

  • the trolls win, and by that everyone else loses :P

    • Re: (Score:2, Insightful)

      by gweihir ( 88907 )

      There is a difference between "attacks" and valid criticism. Calling everybody that criticizes systemd and its adoption into Debian a "troll" or an "attacker" is unfounded and represents an extreme form of trolling itself. One could get the rather strong impression that the systemd advocates do not want any dialog or have sufficient valid arguments to deal with the criticism voiced. Instead they revert to this form of primitive emotional manipulation.

  • by Peter H.S. ( 38077 ) on Sunday November 16, 2014 @05:52PM (#48398801) Homepage

    Debian have many good sides. It also suffers from fractions; the problem isn't so much that people disagree about some time petty technical things, but that they abuse the Debian bug tracker and governmental system in order to feud their petty wars on usually innocent package maintainers. By filling "political" bugs together with a lot of whining and twisted representation of facts, and then run and complain to higher ups in the hierarchy, they can force the package maintainer into endless, repeated explanations why things are like they. You can basically force the package maintainers to always be in defensive position. Not fun at all.

    In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.

    The "anti-systemd" faction probably just think they are fighting with their backs against the wall, trying to claw out a place in Debian with any means necessary before it is "too late".

    But if they keep on attacking Debian developers like they do now, I think their strategy will backfire. Before the bitter systemd debacles started, most Debian developers where probably quite keen to support non-systemd inits too. But this rather poisonous war just never seems to end, so some Debian developers are starting to think, that the only way forward is an outright banishment of official SysVinit support after Jessie is released.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.

      Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?

      • Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?

        There is firm backing behind systemd as default init system in Debian. There probably also is a lot of willingness to support more than one init system.

        The problem with the eternal war by "committee weasels" and "paper warriors" is that it simply shows that continuing supporting SysVinit is the wrong thing to do for Debian, since it will be used as a permanent excuse to feud an eternal war and "retaliate" as you describe it.

        At some point Debian will have to make a decision between kicking out SysVinit for

  • by Anonymous Coward

    Mail a bomb, presume the bombing will succeed without error, don't monitor if the bomb actually had gone off and don't send another bomb if the first bomb fails. Any other deviation from this terrorism process is not the proper UNIX way!

    • If the first bomb fails, you don't keep mailing bombs hoping one succeeds, you have to figure out why the bomb failed and fix that problem before you try a second time or some other method of achieving the same goal.

Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off.

Working...