Please create an account to participate in the Slashdot moderation system

 



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

Debian's Systemd Adoption Inspires Threat of Fork 555

New submitter Tsolias writes It appears that systemd is still a hot topic in the Debian community. As seen earlier today, there is a new movement shaping up against the adoption of systemd for the upcoming stable release [of Debian], Jessie. They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle. Note that the linked Debian Fork page specifically says that the anonymous developers behind it support a proposal to preserve options in init systems, rather than demanding the removal of systemd, and are not opposed to change per se. They just don't want other parts of the system to be wholly dependent on systemd. "We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs."
This discussion has been archived. No new comments can be posted.

Debian's Systemd Adoption Inspires Threat of Fork

Comments Filter:
  • Finally ... (Score:5, Interesting)

    by Anonymous Coward on Monday October 20, 2014 @03:52PM (#48188761)

    ... I was already investigating into FreeBSD as option. I welcome a fork of debian. The developers are irreparable split anyways. Half of them are pro systemd, the other half are not. So why waste time into talks. There won't be an acceptable solution anyways. So better head off and fork the project. I want to see how debian will survive, once half of the develoeprs have rushed away to form a new project.

    • Re:Finally ... (Score:4, Interesting)

      by armanox ( 826486 ) <asherewindknight@yahoo.com> on Monday October 20, 2014 @04:05PM (#48188901) Homepage Journal

      I am entertaining FreeBSD and Slackware as viable options. The only thing in Slackware's favor is the games I play will run on it vs FreeBSD.

      • Re:Finally ... (Score:5, Insightful)

        by TWX ( 665546 ) on Monday October 20, 2014 @04:12PM (#48189025)
        I ended up on Debian because of Slackware's holdout with libc5 when everyone else had gone to glibc2. I then discovered that I liked the ability to use install packages with dependency checking to keep my systems up to date.

        then systemd came along and made me sad.
    • by TWX ( 665546 )
      I wonder which half will end up over at Ubuntu...
    • Re: (Score:3, Interesting)

      by hairyfeet ( 841228 )

      Well if the rumors are true then RH has been quietly stacking the deck by loading Debian with ex RH employees then a fork is the only possible chance of keeping from getting system'd.

      In case anybody wonders why they are trying to ram systemd so hard? Cloud computing, they want systemd to be a "one size fits all" for their cloud computing initiative. Great for RH, not so great for everybody else. In any case it will be interesting if the users can "take the OS back" from Red Hat and the corporate interests l

  • freedesktop.org (Score:5, Insightful)

    by mr_mischief ( 456295 ) on Monday October 20, 2014 @03:52PM (#48188767) Journal

    The distributions should be wary of putting all their eggs in the freedesktop.org basket. Not all systems are desktops, and they shouldn't rely on desktop features at the expense of their own roles.

  • Fedora fork too (Score:4, Interesting)

    by kthreadd ( 1558445 ) on Monday October 20, 2014 @03:53PM (#48188771)

    http://forkfedora.org/ [forkfedora.org]
    Not really, but well made.

    • http://forkfedora.org/ [forkfedora.org]
      Not really, but well made.

      That's a good point as to the the drawbacks of the "do one thing and do it well" principle.

      The individual tools get simpler, but some of the complexity pops up when you try to make them interact. So instead of complex programs we end up with complex and esoteric configurations that end users have to descipher.

      I'm not a fan of everything involving systemd, but the idea of shoving a bunch of complexity into a well designed and reliable blob doesn't strike me as an intrinsically bad idea.

    • Re:Fedora fork too (Score:5, Informative)

      by linuxrocks123 ( 905424 ) on Tuesday October 21, 2014 @01:36AM (#48192835) Homepage Journal

      All that proves is that Fedora's init scripts suck. I'll believe that.

      Here's Slackware's rc.sendmail script:

      #!/bin/sh
      # Start/stop/restart sendmail.

      # Start sendmail:
      sendmail_start() {
          if [ -x /usr/sbin/sendmail ]; then
              echo "Starting sendmail MTA daemon: /usr/sbin/sendmail -L sm-mta -bd -q25m" /usr/sbin/sendmail -L sm-mta -bd -q25m
              echo "Starting sendmail MSP queue runner: /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m" /usr/sbin/sendmail -L sm-msp-queue -Ac -q25m
          fi
      }

      # Stop sendmail:
      sendmail_stop() {
          killall sendmail
      }

      # Restart sendmail:
      sendmail_restart() {
          sendmail_stop
          sleep 1
          sendmail_start
      }

      case "$1" in
      'start')
          sendmail_start ;;
      'stop')
          sendmail_stop ;;
      'restart')
          sendmail_restart ;;
      *)
          echo "usage $0 start|stop|restart"
      esac

  • by BarbaraHudson ( 3785311 ) <barbarahudson@NOSPaM.gmail.com> on Monday October 20, 2014 @03:55PM (#48188789) Journal

    The solution to yet another init system is to support even more init systems?

    If systemd needs to die, then say so. Give the reasons why, then fork it if necessary. We've got enough problems supporting different not-invented-here stuff in too many distros already.

    • by Anonymous Coward on Monday October 20, 2014 @03:58PM (#48188827)

      There are too many competing standards. Clearly what we need is a new, unified standard. ;-)

    • by bersl2 ( 689221 ) on Monday October 20, 2014 @04:05PM (#48188907) Journal

      Systemd does not need to die. All the more power to those who wish to use it.

      However, it is undesired by a significantly large portion of users and sysadmins, and it is unsuitable for those who still actually want to run Linux as a Unix-like OS.

      For these reasons, in my opinion, it is not (yet) ready to become the init for a number of general-purpose distributions out there. Moreover, it is unacceptable for the udev subsystem to reside in the same source tree as systemd, and it is unacceptable for udev to integrate, except through the use of a stable and init-independent interface, into any particular init implementation or design.

    • Good point - that makes a huge amount of sense.

      Which is probably why they're doing exactly that.

    • What? (Score:5, Insightful)

      by s.petry ( 762400 ) on Monday October 20, 2014 @04:09PM (#48188965)

      Systemd may be fine for a desktop, but not fine for a server. I can say the same exact thing about NetworkManager, which I quickly remove from any server I touch because some Ditro's think that servers need this crap.

      I refuse to use Ubuntu for example because they can their software for desktops. I don't have anything against Linux desktops mind you, but I don't manage thousands of desktops. I manage thousands of Linux Servers.

      If Debian does not want to ship systemd I'm happy. It saves me from searching for a new Distro to replace our current all Debian environment.

      If someone does not like Debian for doing so, they can go Fork themselves all they want. Forking has been the primary reason for Linux growth. Yeah yeah, we have seen some orphaned and a few died on the tree, but the best continue and breed more... (*intentionally punned*)

      • Re:What? (Score:5, Insightful)

        by mlts ( 1038732 ) on Monday October 20, 2014 @04:25PM (#48189177)

        On a desktop, systemd and firewalld make sense, because one might have an Ethernet connection that is in a trusted zone, a Wi-Fi adapter that is on a public (untrusted) zone, and so on. Plus, the parallel startup of systemd makes booting a lot faster.

        For a server, one wants reliability and security above all. One reason why IBM still obtains boku bucks is because AIX 7.1 still runs applications written for 3.2.5. It might require some compatibility programs to be installed, but if one wanted to run FrameMaker or WordPerfect under Motif, they still can, assuming a graphics card present.

        Server-side, it doesn't matter if things start in series. Things need to work properly and be coded for maximum security and reliability.

        systemd is the iTunes of the Linux world. It does so much in userland, that a bug in that can mean disaster, or a series of disasters similar to the tons of sendmail holes found in the early to mid 1990s. While it does improve some things, having a large, monolithic package handle so much of userland can mean big trouble [1].

        My personal take: systemd is a leap forward. But, for something this crucial to infrastructure, with so many moving parts and so many different interactions between them, this really needs to run through a bug stomping session. Maybe Facebook would torture-test it like they are doing btrfs so that virtually all the major bugs get squashed sooner, rather than later. Even better might be a formal code audit on it (a la TrueCrypt) to find and squash anything that could cause the next Shellshock or RTM worm in coming years.

        The one thing that has kept the epic fails out of UNIX is the fact that the OS is made out of a lot of little subsystems. Replace bash with busybox, not that many programs would notice. Replace /bin/yes with busybox's yes... who cares. However, systemd breaks this philosophy. If something breaks, I can't just rename the binary, link in the busybox equivalent, and call it done. I'm dead in the water until a patch comes out, and since this is a subsystem that completely controls the userland environment, this is worrisome when it comes to production critical items.

        [1]: Ironic how this is similar to what Tanenbaum said about the Linux kernel.

        • by sjames ( 1099 )

          Debian can already do parallel starts without systemd. That could be improved upon, but I see no reason systemd's approach is required for that.

          Honest question, Can anyone out there name a single reason everything systemd does can't be done as well or better using a simple helper app to start the daemon (and optionally stick around to monitor/control it)?

          Any clue why systemd should even have an interest in replacing the well tested nntpd?

      • What is it about a server that makes systemd inappropriate? NetworkManager I see; servers rarely change their network configuration when they do they want to do it in a controlled way, not an automatic way.

        But I don't understand what similar distinction you're drawing for systemd. It doesn't take away the ability to carefully manage your configuration via text files, and doesn't do anything automatically unless you ask it to; what about running a server makes systemd undesirable?

        • by s.petry ( 762400 )

          The primary downer for systemd on servers is the lack of backward compatibility for boot scripts. We hack things often, and the last thing I want is to have a competing system which may decide that a systemd DB entry should override my #!/bin/sh legacy mode script for the same functionality. Further, we test things by interrogating boot script, and obviously with systemd those tests all need to change to new methods.

          I'm not claiming it's an impossible task mind you, but would add a ton of work no matter h

        • Re:What? (Score:5, Insightful)

          by sjames ( 1099 ) on Monday October 20, 2014 @05:54PM (#48190161) Homepage Journal

          In the past, I have resorted to booting with init=/bin/bash and then running the rc scripts by hand to see the problem. Systemd won't even try to work if it isn't pid1, and it can't be if I booted init=/bin/bash.

          In other cases, I have booted to shell, mounted up the filesystems and then did /etc/init/d/ssh start so I could get a second opinion. Try that with systemd.

          In any number of cases, I have had to set something up that the system scripts and configs didn't (and couldn't have) anticipated. It was a simple matter of editing a few init scripts...

          Imagine the 'fun' if you need to boot to a rescue disk, chroot into the server filesystem and bring up services while you fix a problem.

          These 'heroic' measures come up when a server is in a lights out environment hours away. Sometimes the best approach is to get it to limp along until regular hours.

      • by jbolden ( 176878 )

        Systemd may be fine for a desktop, but not fine for a server.

        The PaaS vendors are all excited about systemd. So that's just simply false. It is better for server.

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Monday October 20, 2014 @03:58PM (#48188823) Homepage Journal
    There is a certain contingent in Debian that is not good for the project, IMO. I would like to see which side of a fork they are on, and pick tthe other.
    • by ThePhilips ( 752041 ) on Monday October 20, 2014 @04:23PM (#48189135) Homepage Journal

      To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.

      After so many years, I have finally understood why Debian is constantly rises, hits the plateau, freezes for few years in shock and tumbles back down. They want to be just a distro. They do not lead - they follow. They do not create standards - they adopt them. They do not develop stuff - they just repackage someone else's stuff.

      That again was one of the driving factor in picking the systemd over the rest. With systemd, somebody else is doing all the work, while Debian just repackages it.

      Is fork a good idea? There is no fork, really. Debian is nothing but an organization, a community. One can clone the repo - but one can't clone the community.

      Take out from all of this? There are no reasons to worry. Nothing really changed. Debian is simply following the rest of the distros. I'm simply hopeful that they would manage to integrate the systemd nicely. If not... It's not like it would be the first time Debian released something broken and unusable. (Oh, yes, there might no RC bugs - but the (too old/too new) versions of the software, or their configuration, simply make it useless. And trying to change it - breaks it.) That's why we have the Ubuntu, after all: it's like Debian, but not striving for some committee set goal - instead striving to be just useful.

      • To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.

        Debian doesn't have a big pool of paid developers they channel into whatever project they wishes. The Debian technical committee is just doing the only sensible thing in choosing a working, well maintained init system for Jessie, instead of a not-quite-here/vapourware/unproven init system so close to the freezing of Jessie.

        That decision doesn't prevent anybody from actually making an init systems that is better than systemd and the Debian could adopt for Jessie+1 (the decision was strictly for Jessie).
        There

  • by nimbius ( 983462 ) on Monday October 20, 2014 @04:06PM (#48188917) Homepage

    They claim that "systemd betrays the UNIX philosophy"; it makes things more complex, thus breaking the "do one thing and do it well" principle.

    This isnt a thought or a prediction, this is something systemd actually does when it takes NTP, console, logging, and networking and forces them into one application. the fork threat is to be taken seriously because of the leaderships inability to actually recognize this as a massive security, scalability, and overall functionality problem that was steamrolled into debian largely at the behest of KDE and Gnome devs. The best solution to avoid a fork in my opinion is to give the user something thats also been forgotten about in the linux community: choice. Systemd or RC Init, or uselessd (a fork of systemd that tries to rehabilitate systemd)

    • by kthreadd ( 1558445 ) on Monday October 20, 2014 @04:18PM (#48189093)

      This isnt a thought or a prediction, this is something systemd actually does when it takes NTP, console, logging, and networking and forces them into one application.

      Except it's not. /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-timesyncd /usr/lib/systemd/systemd-networkd

      My system is too old so I don't have the consoled on it, but I imagine that will be a separate daemon as well.

      the fork threat is to be taken seriously because of the leaderships inability to actually recognize this as a massive security, scalability, and overall functionality problem that was steamrolled into debian largely at the behest of KDE and Gnome devs. The best solution to avoid a fork in my opinion is to give the user something thats also been forgotten about in the linux community: choice. Systemd or RC Init, or uselessd (a fork of systemd that tries to rehabilitate systemd)

      That would of course be nice. But someone has to do the work. It's not like it's just a matter of flipping a bit and everything just works. You actually need to go in and make sure that stuff works with all of them.

  • I think it could be potentially good for the free/open source software ecosystem for there to be multiple developed solutions to the init system being used out there. I think at this point, a fork could potentially be a lot of work, so I hope they are able to express a more complete vision of future goals, and perhaps differentiate itself For instance, will they try and become Free Software endorsed by the FSF?
  • UNIX Philosophy (Score:4, Interesting)

    by Art3x ( 973401 ) on Monday October 20, 2014 @04:10PM (#48188977)

    I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.

    I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.

    However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL, the X Window system, the GIMP, OpenOffice? Is an init system more like one of these or more like sed and awk? That's not a rhetorical question. I'm a web programmer who loves Linux, but the kernal and start-up are still black magic to me.

    Maybe an init system can be simple. I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.

    Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed? Can't programs be formalized to follow some init API? If the start, stop, and restart are not enough, maybe also an option, like --bg, that they'd all take, so the init system always calls $program --bg start, or $program --bg stop, or whatever; so that all we need is that simple config file. Those programs that don't yet follow the init API could keep using a shell script until they do.

    Please have mercy if this question is terribly naive. I've tried googling . . . a little. I was hoping a real live human being could either explain it all. Or feel free to reply with some links that explain why SysV init needs all those shell scripts and can't be just a simple list or somewhat-simple declarative configuration.

    • Re:UNIX Philosophy (Score:5, Informative)

      by armanox ( 826486 ) <asherewindknight@yahoo.com> on Monday October 20, 2014 @04:18PM (#48189095) Homepage Journal

      We've tried having standards in Linux before, and they were utterly ignored (Linux Standard Base). Basically, there is no reason for certain groups or developers (Red Hat (and to a lesser extent, Canonical) and developer-who-shall-not-be-named) to listen to everyone when they can do whatever they want and everyone else has to deal with it.

    • by jedidiah ( 1196 )

      > However, do these programs follow the do-one-thing-and-do-it-well principle: web servers like Apache, database servers like PostgreSQL,

      Yes they do actually.

      One serves web pages and the other enforces the relational model on data. They aren't one huge behemoth that includes both of these as well as some other application level features.

      • If you think httpd only does one thing you clearly have never even cracked the configuration file open, let alone compiled it.

      • One serves web pages.... and acts as a proxy, a cache, a load balancer, an SQL client, has its own authorisation system.... Apache is probably the single biggest and bloated web server currently available on Linux. It definitely does not do one thing, however it gets a tick for doing most things well.

        Likewise PostgreSQL has a feature list so incredibly long that is not related to the core of having a simple relational database model that it's own Wikipedia entry could be accused of being bloated. But again

    • Systemd even has a shutdownd. I'm pretty sure it does one thing and does it well.

      • It may only do one thing, but it most *certainly* does not do it well. I've yet to have a system with an NFS mounted root filesystem correctly shut down under systemd.

    • I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.

      Do you use X?

      I actually find the whole change hate thing funny in general. The public galleries attack systemd for lack of Unix philosophy and then give X a free pass calling Wayland change for change's sake.

    • Re:UNIX Philosophy (Score:5, Interesting)

      by phantomfive ( 622387 ) on Monday October 20, 2014 @05:06PM (#48189713) Journal

      Please have mercy if this question is terribly naive. I've tried googling . . . a little. I was hoping a real live human being could either explain it all. Or feel free to reply with some links that explain why SysV init needs all those shell scripts and can't be just a simple list or somewhat-simple declarative configuration.

      It's a political problem more than a programming problem. Someone has to get input from everyone involved, and come up with a solution that makes everyone reasonably happy (including BSD folks). Specifically, any solution has to have three things:

      1) Be easy for distro builders to work with
      2) Be easy for developers to implement
      3) Accommodate people who still want to do their own thing
      4) Be implemented in a diplomatic way, so people will be willing to compromise.

      SystemD tried to avoid the political problem by not caring what other people think.
      SystemD also made the mistake of making an implementation, NOT a standard (which is what you correctly suggested), so it is hard to replace with alternate implementations (competition is a good thing). Furthermore, it is not a stable interface, which makes replacing it even harder.

      • 1) Be easy for distro builders to work with
        2) Be easy for developers to implement
        3) Accommodate people who still want to do their own thing
        4) Be implemented in a diplomatic way, so people will be willing to compromise.

        I forgot one here:
        2.5) Be easy for system admins to work with.

    • Re:UNIX Philosophy (Score:5, Insightful)

      by Peter H.S. ( 38077 ) on Monday October 20, 2014 @05:47PM (#48190111) Homepage

      I like the UNIX philosophy and don't think it goes out of style just because it's a few decades old.

      Sure, the problem is "What is Unix Philosphy"? and is it meant as a dogmatic ex cathedra so that Unix can never deviate from whatever that philosophy is, no matter that computing changes every decade with new domain problems?

      Unix wasn't even born with the now basic concept of "piping", it was a development over time. So I think that the so called "Unix Philosophy" is much more about sound guidelines and how the Unix developers tackled the computing problems in their day, than any dogma that can't be deviated from.

      These days we have massive use of Linux OS containers and VM's, using petabyte of storage spread across continents and many other domain problems that was unheard of in the 1960's. I do think that the present development and use of Linux in so many ways, also require new ways for Linux to function. If Linux is put in a 1990's time freeze it will simply become irrelevant and wither away.

      I am against systemd, for now, mainly because of the binary log files and how it was railroaded through the community.

      You can still use the same old flat text files logs with systemd distros by using rsyslog like you always had. Nothing is taken away, and in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.

      I was really skeptical about binary log files before I tried it, but walked away convinced that binary logs like those used by systemd's journald, is the way forward.
      They really solve so many hard/impossible to fix problems with flat text file logs, and I have yet to find any real world problems with their actual implementation. All the usual Linux text tools like "grep" and "tee" works with the systemd journals through the basic Unix concept of piping.

      The systemd developers really did their homework well when designing the systemd log implementation, and it is worth a serious study by anybody working with Linux, instead of a upfront dismissal just because they are binary.

      I don't understand why even shell scripts are needed. Seems like they should be the exception, not the rule. Seems like configuration should be a single file that lists the programs to start from top to bottom. If you wanted add some parallel start-ups, it seems like you could just make the config file format a little fancier, maybe with some braces or indentation to express dependency.

      Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard. Most programs seem already to be callable with the same arguments: start to start it, stop to stop it, restart to restart it. So the simple config file would call one or the other depending on which cycle we're in. Why the need for shell scripts? I've looked at them, and they mostly seem to be doing this anyway: call start on the shell script, and it calls start on the program. I see some checking, some setting of environmental variables maybe, but is this really needed?...

      Using scripts (basically executable config files) to start daemons is probably a relic of the time when invented decades ago. The needs where much simpler in those days, and shell scripts was just a handy tool to have a quick and dirty solution to the problem. It haven't made sense for a decade at least to still using SysVinit and similar solutions, and all? certified Unix'es have switched long ago. In fact, launchd and Solaris SMF where major inspiration points for systemd.

      It is quite doable to make a init system that uses declarative statements in text config files, both systemd and SMF does it. But it wouldn't be SysVinit anymore, so which distro will actually use such a init system? Slackware has its own style of SysVinit and is extremely conservative, an unlikely distro to change from what is has. Gentoo has OpenRC, and is also highly unlikely to change from that too.

      So while possible to make, it is probably hard to find "buyers" for such a new init system, and therefore also developers to make it.

      • Re:UNIX Philosophy (Score:4, Insightful)

        by drinkypoo ( 153816 ) <martin.espinoza@gmail.com> on Tuesday October 21, 2014 @07:35AM (#48194003) Homepage Journal

        Unix wasn't even born with the now basic concept of "piping", it was a development over time.

        It was an extremely early development, introduced before Unix was introduced to the world at large. That's why it's described in the first edition of "The Unix Programming Environment". Describing piping as a johnny-come-lately feature of Unix is disingenuous.

        The systemd developers really did their homework well when designing the systemd log implementation

        No. Maybe the log file implementation, but they didn't even get that right. An error in the file means the whole thing is useless. Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read. If you don't agree, then we can't agree. You simply don't understand the problem of trying to deal with potentially corrupt binary logs on another computer entirely, which is a real scenario. On occasion I have to resort to pulling the disk and slapping it into something else for analysis, and I shouldn't need special tools for that. I should be able to use anything lying around.

        I'm not against also having binary logs, I can see the potential benefits. However, it makes no sense whatsoever to just chuck them into a bunch of loose files anyway. Doing that doesn't solve the organizational problem of having a bunch of files lying around. The same data that goes into the text logs should go into an RDBMS. Then I could really do something with the data. systemd's binary log files actually represent a failure in the form of a missed opportunity, and not a rational evolution.

        Further, there's no reason why the logging daemon should be tied to the init daemon at all. If this init daemon is so wonderful, reliable, and good at starting processes in order, then it should be able to kick off any logging daemon, wait until it is running and accepting log messages, and then continue booting, perhaps after delivering the boot time log messages to the logging daemon. Want to argue that we need a new syslogd with binary logging? Fine. But where's the argument that it should be married to init?

    • I'm a web programmer who loves Linux,

      Welcome.

      but the kernal and start-up are still black magic to me.

      SysV init is really quite simple. Just a few minutes playing around with it on a system and you'll get the hang of it. First off, there are several run-levels. Let's focus on just one run-level for now since most people only ever edit one (they'll use run-level 0: shutdown, and run-level 6: reboot, unknowingly). Within each runlevel directory (let's choose /etc/rc5.d/) are symlinks that point to the scripts in /etc/init.d/, and these symlinks are named with S for start or K for kill, followed b

  • by PPH ( 736903 ) on Monday October 20, 2014 @04:15PM (#48189061)

    ... systemd forks you!

    Come to think of it ....

  • unless you're not participating and you're a canabal
  • by Peter H.S. ( 38077 ) on Monday October 20, 2014 @04:28PM (#48189197) Homepage

    There are +150 Debian forks (derivates) already, so yet another one hardly matters. The main reason why its is an empty "threat" is that there basically isn't any real development of needed infrastructure in the non-systemd camp, and as time goes by, more and more alternative development will be need by non-systemd distros.

    The fork of systemd's "udev", "eudev", is basically just a shadow fork with patches, but soon eudev maintainers have to decide between having to support a kdbus manager, thereby become more developers instead of just patch maintainers, or their fork will deviate so much from the real udev, that they no longer just can leech new patches from it.

    Of course, ConsoleKit is still dead with nobody picking up development, the only alternative is a rather limited implementation of systemd-logind, and is basically maintained by a Canonical developer who are unlikely to maintain it after Canonical have switched to systemd.

    Stuff like root-less X.org can at the moment only be safely done by systemd. Some Wayland implementations will also depend on systemd simply because the upstream projects aren't getting any help at all in supporting non-systemd distros.

    Even SysVinit isn't in such a hot state, it haven't made a release in five years, and the defacto upstream maintainers have been SUSE/Reed Hat for years. At some point they will drop maintaining it anymore.

    I could go on, but the fact is that there is an increasing amount of work needed to be done, just in order to keep status quo somewhat, and that the non-systemd camp are severely lacking developers that could help maintaining such critical infrastructure.

    It would actually be quite good for the non-systemd camp if there was a proper Debian fork that solely was about non-systemd developemnt. They have been lacking a focal point for such development for a long term stable distro for years (Slackware, despite its merits, is ultra conservative and probably too limited in certain ways for this).

    The problem is that some factions in the non-systemd camp are pursuing systemd "emulation" by using shims and forks. That way you just get a second rate systemd, and it will remove any motivation from upstream projects to support anything else than system. Using Ubuntu's "logind" is a short term gain, but a strategic failure for the non-systemd camp. They need their own implementation of needed infrastructure, not just copying or emulating systemd.

    • Even SysVinit isn't in such a hot state, it haven't made a release in five years

      This kind of stability is a good thing.....once you get a tool right, it shouldn't need to change much.
      The fact that we are still arguing about how to do an init system 30 years into Unix is ridiculous.

    • Threatening a fork is like threatening legal action: if you think you're to that point, you need to just do it, and inform the relevant parties afterwards. Anyone can threaten to take action.

  • by FridayBob ( 619244 ) on Monday October 20, 2014 @04:43PM (#48189403) Homepage

    Having used it almost exclusively since 2001, I've always regarded Debian as a distro for more tech-savvy and conservative types -- system administrators, for example. However, their recent move towards systemd seems very unlike them and, as a professional sysadmin, this worries me. Perhaps it's what we can expect, every once in a while at least, from a bunch of people who are not system administrators.

    Luckily, they seems to be having second thoughts about the matter and this could be an opportunity for them. Their main competitor, which IMO is Red Hat, have already committed to systemd, which I'm not happy about either and find just as surprising. Therefore, since so many people have expressed their misgivings about it, if Debian were to reverse their earlier decision and go back to sysvinit (or at least make systemd optional), then I think we could see many sysadmins converting their RHEL systems to Debian jessie.

  • Isn't Mint Debian Edition effectively a defacto fork already? I would assume most Systemd haters are also Gnome3 haters.

  • by Todd Knarr ( 15451 ) on Monday October 20, 2014 @04:49PM (#48189487) Homepage

    The init process is a critical stage: failure tends to leave you with no access to the system to diagnose the failure. I tend to break it into two parts, the first part being what's necessary to allow at least a single-user login on the console, and the stuff that happens after that point to bring up the full multi-user system and server processes.

    I don't like systemd for the first part. It's overly complex, and the more parts and interdependencies there are the more things there are to fail. To quote an engineer, "The more they overthink the plumbing, the easier it is to stop up the works.". Shell scripts and plaintext log files may be primitive, but they have the advantage of being easy to read with minimal access and not requiring complex stuff to run (mainly they just require that basic binaries be available in the path). Until I've got at least a basic system up and running enough to log in and work, I want the init process to be as simple and straightforward as possible with as few points of failure in the init process itself (as opposed to the things it's starting) as possible. I want this stage to be as hard to break and easy to debug/fix as possible. I don't want to depend on complex tools at a point where I'm working in the most primitive environment.

    I don't particularly like systemd for the second part, but it isn't quite as much of a problem here as in the first part. By this point I've got a basic system up, I can log in and work, and most of the tools are available. Obviously nothing graphical will work, but text-based tools will probably run to decipher binary logfiles and modify configurations. I still prefer not depending on such tools, because they're one more point where things can fail to work and leave me scratching my head trying to figure out what broke without access to basic diagnostic information, but at this stage I can likely fix any tool-related problems and get back on track.

    The one part I think systemd works for is in the later stages of the second part. There's a lot of server processes with interdependencies that typically start after the multi-user system's up and running. I think systemd's a good thing for getting those running, it can do a better job of parallelizing that process than shell scripts can. The only change I'd make is to make systemd use syslogd like everything else, so log files end up in the expected place and are plain text so basic tools like more and tail and grep work on them as-is. Binary logfiles offer no great advantage over plaintext, and going through syslogd means not depending on two sets of tools and having to manage two configurations to get logging directed where it needs to go.

    One last bit has me twitchy about systemd: history. SysV init scripts may be clunky and primitive, but they've been around a long time. People know how to manage them, and they've had the kinks worked out of them and best practices established. systemd doesn't have that. I do not want to make my servers (that have to run for anything to work right) dependent on something until I've had time to work with it and get familiar with it and, more importantly, it's been out there in use long enough for people to find and fix the problems, work out the oddities and figure out the best ways to use it without shooting yourself in the foot. I'd prefer to stick with SysV init on my production systems and only enable systemd on testbed systems at the start, and then enable systemd on a server-by-server basis so unexpected failures don't completely kill me (eg. if systemd blows up on my primary mailserver, the backup still on SysV can keep things under control until I either fix the problem or revert and restart the primary).

    • by Electricity Likes Me ( 1098643 ) on Monday October 20, 2014 @11:30PM (#48192397)

      Binary log files are more compact. They can be better indexed. They lend themselves to localization more easily by abstracting the problem away from the executable that writes them. They can be strongly typed.

      Frankly, you listed a bunch of tools which process "text logs" as though they're not doing exactly the same thing a binary log file tool is doing. They are also not "basic tools". Regex parsing is anything but basic, it's just commonly included. Just as journalctl will be on *any* system which uses journald because it's a basic tool.

      There's also a huge strain of American-centrism here. Plain text sounds great so long as you assume it's English.

  • I Trust Debain (Score:4, Insightful)

    by enter to exit ( 1049190 ) on Monday October 20, 2014 @04:59PM (#48189633)
    I trust the Debian committee - as a collective - to make the best choice. The committee has a large group of people with diverse interests and the majority voted to adopt systemd. Debian isn't exactly known to be a flippant Distro.

    I suspect the technical people behind Debian/Fedora/Arch/OpenSuSE and other Distributions (some of which make money on their products and services) are a lot smarter and thoughtful than a bunch of people with a website that has a purple background and orange links.

    I've used systemd under Arch, and i could open up a systemd unit file and understand what every word in the file meant. I can't say the same thing about most SysV startup script.
  • by Jodka ( 520060 ) on Monday October 20, 2014 @05:27PM (#48189929)

    from the summary

    "They just don't want other parts of the system to be wholly dependent on systemd."

    That is really the crux of the issue and what distinguishes the systemd dispute from all the other FOSS food fights. The FOSS community never agrees on anything. That is why we have multiple everything: Multiple Kernels (BSD & Linux Kernels, multiple flavors of each) many distributions of each flavor, a host of programming and scripting languages, multiple package management tools (rpm, portage, dpkg) several GUI toolkits, GNOME and KDE desktop environments etc. Wayland is not enough, we must also have Mir. And the licenses. Egads! How many of those do we need?

    Despite all the passion and ego involved, disagreement between adherents of particular designs and implementations has never before risen to the level of open revolt that we see over systemd. Why? Because in all these disputes each person can choose what is best for him/herself. Like Python and despise Perl? Use Python. Vice versa? Use Perl. But the usual rule of the user getting to pick what he likes best does not apply with systemd. Lennart Poettering is working to restrict choice to only systemd. His tactic is to make systemd a dependency of major software packages. Here he is [gnome.org]on the Gnome dev list pushing a Gnome systemd dependency.

    Sometimes an unpopular item is replaced on the buffet; Good software wins out and variety shrinks a bit. That can be a good thing. But the fear is that systmd is going to win not because it is a popular choice but because Poettering has gamed the outcome using dependencies. Something is wrong if you are running systemd because you hate it and you love Gnome. Perhaps the fanatical hatred of Poettering [google.com] is driven by belief that systemd adoption is advanced in part by his cheating, instead of on the merits of systemd alone. The abusers are abusing not because he has written what they judge to be bad software but because he has violated an unspoken ethic of the FOSS community.

    • Just as an aside, have you noticed that his Google+ username is LennartPoetteringTheOneAndOnly?

      This says pretty much everything that needs to be said regarding his mindset. To your point.

Enzymes are things invented by biologists that explain things which otherwise require harder thinking. -- Jerome Lettvin

Working...