Slashdot Mirror


Debian's Systemd Adoption Inspires Threat of Fork

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."

555 comments

  1. And this is why Linux will never win the desktop by NotDrWho · · Score: 0, Troll

    Choose your OS, average user:

    1) Windows
    2) Apple
    3) From hundreds of confusing distros and rage-forks of distros of "Linux"

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
  2. Finally ... by Anonymous Coward · · Score: 5, Interesting

    ... 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.

    1. Re:Finally ... by armanox · · Score: 3, Interesting

      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.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    2. Re:Finally ... by Anonymous Coward · · Score: 1, Interesting

      Well FreeBSD is a dependency hell to say at least. Once you install it from the netinstall (the 200mb) pulling in more packages requires a shitload of stuff.

      pkg install xorg
      pkg install xfce
      pkg install mc
      pkg install vim ... and you end up with nearly 2gb of wasted hd space (after removing /var/cache/pkg/*)

    3. Re:Finally ... by TWX · · Score: 2

      I wonder which half will end up over at Ubuntu...

      --
      Do not look into laser with remaining eye.
    4. Re:Finally ... by TWX · · Score: 4, Insightful

      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.

      --
      Do not look into laser with remaining eye.
    5. Re:Finally ... by armanox · · Score: 1

      I'm not concerned over 2GB of space unless I'm running an embedded system, in which case I'm probably not installing X or XFCE. (I'd bet XFCE is where your space is being gobbled up).

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    6. Re:Finally ... by Anonymous Coward · · Score: 0

      No it wasn't XFCE that took the space. It was the overall packaging that caused this (xorg, xfce and even vim and or mc). But I believe the more people will jump to BSD the better the packaging will become. It's just a matter of ressources. Overall I like FreeBSD. It's dead simple to install and deal with. /etc/defaults/rc.config is quite easy to deal with.

    7. Re:Finally ... by hairyfeet · · Score: 2, Interesting

      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 like Windows users did when they refused to take Win 8, it will be quite fascinating to see whether Linux users without the power of the wallet can change things simply by protest.

      I personally wish them nothing but luck, as it sucks to see an OS you have serious time and money invested in get a big old shit taken on it by the suits...good luck Debian users, may you tell the suits where they can stick their system'd crap.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    8. Re:Finally ... by unixisc · · Score: 1

      I have PC-BSD, which is FreeBSD made easy, and none of my installs have ever evoked a dependency issue, unlike w/ Linux - namely RedHat. I'll grant that distros that use apt-get are better than those that use yum - no idea about Pacman or other choices. But now, FreeBSD, PC-BSD and TrueOS all come in the same DVD, so one could install FreeBSD just as easily as the rest. With the packages.

    9. Re:Finally ... by Anonymous Coward · · Score: 0

      Unfortunately, we are witnessing the fact that the Debian Project doesn't have a serious policy against actual or potential conflicts of interests. It's a shame for such a wonderful community, probably the most relevant in the open source world together with GNU.

      Just read their mailing list: those who are against systemd are accused of being "conspiracy theorists". That's the only thing that pro-systemd people seem to be able to say. No answers to the objection that systemd violates the fundamental UNIX principle "Do one thing and do it well".

      I hope they find a decent compromise, for example allowing only packages that support at least two different init systems. If they find some silly excuses not to do that, I'm afraid we' ll have to conclude that the "red hat conspiracy theory" is actually true.

    10. Re:Finally ... by Anonymous Coward · · Score: 1

      For us users, it won't be easy to switch to something different. Debian is a unique solution in the open source world: it gives you a straightforward update system, a massive open source software library, everything is carefully mantained, every discovered bug is rapidly fixed. Its stability and security are way beyond anything else in the commercial and free software world, and that's also why so many linux distributions are Debian-based.

      I still hope that they can reach a decent compromise, for example allowing only packages that support at least two different init systems. If they find some silly excuses not to do that, I'm afraid we'll have to conclude that the "red hat conspiracy theory" is actually true. And we'll have to dump our favorite operative system and switch to something else. But it would be really sad.

    11. Re:Finally ... by Anonymous Coward · · Score: 0

      Please mod this funny, someone :)

    12. Re:Finally ... by Anonymous Coward · · Score: 0

      I am the initial commenter: Well There was no dependency issue. pkg install only pulled in plenty of packages that e.g. wouldn't be necessary with debian or fedora. But then, maybe I was quick with my initial comment. Debian as well as Fedora already installs Xorg and some small desktop component (in case it was selected through the debian installer.). Maybe I would have the same result if I'd installed from a console installation towards an xorg installation using debian. For example pkg install mc wanted plenty of Xorg libraries - that normally wasn't necessary because it's just a console app (Xorg libs only for X compatiblilty). Same applies for pkg install vim. I am quite sure that once getting used to FreeBSD that I would be able to strip it the same way down like a Debian or Fedora installation.

    13. Re:Finally ... by Anonymous Coward · · Score: 0

      This compromise won't happen. The only thing I can tell the people is this:

      Lay down all further work for debian, boycott it and seek for an alternative. I wonder who will be able to fill this gap.

    14. Re:Finally ... by jwhitener · · Score: 1

      If you have a home desktop system (playing games, etc..) why is systemd even a big deal to you?

  3. freedesktop.org by mr_mischief · · Score: 5, Insightful

    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.

    1. Re:freedesktop.org by Peter+H.S. · · Score: 1

      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.

      Dude, freedesktop.org is just a code repo like github, so they also host e.g. an OpenCL compiler. Sure, the site is also used for inter distro discussions and informal work groups, but implying that systemd is a desktop thing only since it hosted on freedesktop.org is just laughable.

      When you got the time, please read up on the systemd project to see what it is all about:
      This is an excellent starting point: http://www.freedesktop.org/wik...

    2. Re:freedesktop.org by mr_mischief · · Score: 1

      I work on servers with systemd as the init system. Yes, it's quite possible to run a server with it. It does things that in fact make much more sense for a desktop. It's not terrible, but it's moving away from the simplicity and modularity we've come to expect.

    3. Re:freedesktop.org by Peter+H.S. · · Score: 1

      I work on servers with systemd as the init system. Yes, it's quite possible to run a server with it. It does things that in fact make much more sense for a desktop. It's not terrible, but it's moving away from the simplicity and modularity we've come to expect.

      I would say that out-of-the-box cgroups and kernel capabilities are making extremely much sense on servers. Being able to put hard limits on a service's CPU/IO/networking can only be a good thing, same with having defense in depth, by eg. preventing a service process /or any of its children/ from ever getting any privilege escalation (NoNewPrivileges). Combine it it with PrivateTmp=, and white-listing of what dir's it can read or write and you get some real hardening of the system in a very easy way.

      Same with reliable killing processes, having a total supervision chain, including PID1 itself, being able to restart crashed processes, not by simplistic means, but using rate limiting, and perhaps based on exit signals too (only restart on unclean exit signals etc).

      Regarding simplicity, then I am the opinion that the old legacy script based init systems where more "crude" and "primitive" rather than simple, and their total lack of features isn't so much a virtue, than a real downside to their use; even basic features had to be hacked and bolted on top of SysVinit.

      I do agree though, that systemd is a rather hefty piece of software to understand, doing things in new ways, and lots of documentation to read. It also sucks to discard knowledge about e.g. boot sequences, and relearning everything again. But looking back, there was a lot of new tech that seemed extremely complex to begin with, that these days seem trivial, so I guess some of the seeming complexity of systemd will disappear once people "get it".

      Regarding modularity; people may argue all day long that systemd isn't "really modular". But the point is in many ways moot; there is no real substitute for systemd's udev or logind or journald (syslog doesn't do all what journald does and vice versa), so what did it matter if systemd increased its internal complexity by supporting other modules than these; there simply haven't materialized any alternative despite years of warning from upstream projects.

      Another thing I like about systemd and its wide acceptance in all major distros, is that it is a long needed reduction in needless fragmentation, being able to share knowledge about doing certain things on so many different distros is a boon.

  4. It's a bluff by Anonymous Coward · · Score: 1, Insightful

    They assert on one hand that they don't have time to participate in Debian, and on the other that they have time to manage a fork. Not buying it.

    1. Re:It's a bluff by Anonymous Coward · · Score: 0

      Have you ever tried getting into Debian? The whole process is like long.

    2. Re:It's a bluff by thaylin · · Score: 2, Informative

      They dont have time to get into the politics, not the contribution.

      --
      When you cant win, ad hominem.
  5. Fedora fork too by kthreadd · · Score: 3, Interesting

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

    1. Re:Fedora fork too by Anonymous Coward · · Score: 0

      I find it telling that they resorted to sendmail for their examples.

      Seriously, who uses sendmail anymore? Postfix, baby!

    2. Re:Fedora fork too by Anonymous Coward · · Score: 0

      Sort of makes it all the more interesting that Red Hat bought out CentOS before all the SystemD announcements.

      Think it looks even more like a Microsoft 3E move after additional facts in? More coming?

    3. Re:Fedora fork too by Anonymous Coward · · Score: 0

      Sort of makes it all the more interesting that Red Hat bought out CentOS before all the SystemD announcements.

      Cheer up, there's always Oracle Linux.

      Oh, wait...

    4. Re:Fedora fork too by Anonymous Coward · · Score: 0

      LOL. This is a great example of using satire to succinctly make a really good point.

    5. Re:Fedora fork too by thue · · Score: 1

      postfix.server from https://github.com/vonSchlotzk... :

      [Unit]
      Description=Postfix Mail Daemon
      After=network.target

      [Service]
      Type=forking
      ExecStart=/usr/sbin/postfix start
      ExecStop=/usr/sbin/postfix stop
      Restart=always

      [Install]
      WantedBy=multi-user.target /etc/init.d/postfix :

      266 lines, too long to print here, and just as ugly as sendmail.

      So the postfix sysv init script is 113 lines LONGER while the .service file is 4 lines SHORTER than the sendmail example.

    6. Re:Fedora fork too by quantaman · · Score: 2

      http://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.

      --
      I stole this Sig
    7. Re:Fedora fork too by Anonymous Coward · · Score: 0

      The problem with sendmail wasn't its init script...

    8. Re:Fedora fork too by Anonymous Coward · · Score: 0

      On fedora the postfix unit file is a little longer than that:

      [Unit]
      Description=Postfix Mail Transport Agent
      After=syslog.target network.target
      Conflicts=sendmail.service exim.service

      [Service]
      Type=forking
      PIDFile=/var/spool/postfix/pid/master.pid
      EnvironmentFile=-/etc/sysconfig/network
      ExecStartPre=-/usr/libexec/postfix/aliasesdb
      ExecStartPre=-/usr/libexec/postfix/chroot-update
      ExecStart=/usr/sbin/postfix start
      ExecReload=/usr/sbin/postfix reload
      ExecStop=/usr/sbin/postfix stop

      [Install]
      WantedBy=multi-user.target

      Still nothing crazy.

    9. Re:Fedora fork too by unixisc · · Score: 1

      And Mageia, Mandriva, Scientific Linux and other RedHat variants, not to mention Arch, Gentoo & Slackware based distros. Incidentally, wondering what RMS' own pet distro - gNewSense, does, since it's a Ubuntu i.e. Debian derivative?

    10. Re: Fedora fork too by Anonymous Coward · · Score: 0

      From the guy that brought us pulseaudio? Dream on...

    11. Re:Fedora fork too by linuxrocks123 · · Score: 4, Informative

      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

      --
      vi ~/.emacs # I'm probably going to Hell for this.
    12. Re:Fedora fork too by geroy · · Score: 1

      runit script is even more simple than systemd ... by your example everybody should use runit/daemontools and not systemd. :)

    13. Re:Fedora fork too by Anonymous Coward · · Score: 0

      Red Hat had already announced that RHEL7 was going to use systemd well before they bought CentOS--and it should have come at no surprise, given the use of systemd already in Fedora, which is RHEL's upstream. Besides, even if they never bought CentOS, it wouldn't have changed anything, CentOS 7 would still have been a recompile of RHEL7 with all the software, including systemd, that comes with it.

      Try harder.

    14. Re:Fedora fork too by Anonymous Coward · · Score: 0

      And here's Debians default MTA init script (please remember that this "simple" script is what some people actually want to preserve! Short and easy, right? Please note that external helpers not included here.):

    15. Re:Fedora fork too by Anonymous Coward · · Score: 0

      # Stop sendmail:
      sendmail_stop() {
              killall sendmail
      }

      Holy crap. That will kill not only the sendmail daemon, but any script using sendmail to fire off an e-mail (e.g. a status or diagnostics email) will have those sendmail processes killed too. That includes the "fatal error, manual intervention required immidiately" mail to root from e.g. the backup script.

      So, the morons who wrote this are the ones advocating for systemd... No surprise really, and maybe they are right, that for morons like that, systemd really is simpler. But personally, I don't give much value to recommendations from morons.

    16. Re:Fedora fork too by juanfgs · · Score: 0

      Either you're an idiot or you misread parent poster, that's the script from slackware, the one of fedora is here http://forkfedora.org/

    17. Re:Fedora fork too by hobarrera · · Score: 1

      Indeed, these scripts suck, while systemd's service unit files are very easy to edit and maintain. I wish we could have a an old-school init system that allowed configuration in that syntax: The best of both worlds.

    18. Re:Fedora fork too by linuxrocks123 · · Score: 1

      As sibling said, this was Slackware's script, so you're actually criticizing its implementation of the BSD rc.d system.

      And they are valid criticisms -- unrelated processes called sendmail would also get killed -- but my response would be, "yes, but, well, I've never run into that." If you stop sendmail, I think you should expect that some email might be dropped. You could easily create a sendmail.pid file in the script if you wanted, but I think keeping the script simple has greater value than catching those corner cases.

      --
      vi ~/.emacs # I'm probably going to Hell for this.
    19. Re:Fedora fork too by Kiwikwi · · Score: 1

      It seems whenever people want to show how simple a SysV init script can be, they pull out examples that don't do half of what the (still much shorter) SystemD unit file does.

      In this example from Slackware:

      - 'sendmail' is a globally reserved name for a binary; only the system-wide sendmail daemon may use it.
      - you cannot query the service status.
      - there's no automatic preprocesing of sendmail config files (rehashing etc.)
      - there's no dependency information

      And that's just what's missing compared to the Fedora SysV init script.

      The Fedora SystemD unit file adds at least the following features:

      - the ability to reliably stop or restart the service
      - automatic restart if the service dies

    20. Re:Fedora fork too by linuxrocks123 · · Score: 1

      If you want to query the service status, use ps aux | grep sendmail

      And if sendmail dies, well, I would want it to stay dead so I would notice and look into why it died, but if you really wanted auto-restart, you have a number of options:

      - Put "while true; do if ps aux | grep -v grep | grep -q sendmail; then /etc/rc.d/rc.sendmail start; done" somewhere.
      - (The right way): put the command to start sendmail (not the startup script, sendmail itself) in inittab with the :respawn: option. You'll have to make sure to use the "foreground" option if you choose this route.

      --
      vi ~/.emacs # I'm probably going to Hell for this.
    21. Re:Fedora fork too by linuxrocks123 · · Score: 1

      Oopsy, minor mistake:

      Correct auto-restart command follows:
      while true; do if ps aux | grep -v grep | grep -q sendmail; then /etc/rc.d/rc.sendmail start; fi; done

      --
      vi ~/.emacs # I'm probably going to Hell for this.
    22. Re:Fedora fork too by whoever57 · · Score: 1

      That just means that functionality has moved elsewhere. For example, the services that must be started before Postfix, the reload function, etc.

      --
      The real "Libtards" are the Libertarians!
    23. Re:Fedora fork too by jtnix · · Score: 1

      That short init config sure looks nice, but right away I notice something wrong about it. wtf is it doing in /usr/lib? Configurations for system software belong in /etc.

      This is the problem with systemd, on the surface it looks great, but underneath its ugly as hell. Not what I am accustomed to when dealing with unix systems. Nor something I can adapt to when I have hundreds to look after.

      --
      She blinded me with science, she tricked me with technology. ~ Thomas Dolby
  6. Re:And this is why Linux will never win the deskto by MouseR · · Score: 2

    Oh come on! There are only 6 hundred distributions.

  7. That's all we need ... by BarbaraHudson · · Score: 2, Interesting

    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.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    1. Re:That's all we need ... by Anonymous Coward · · Score: 5, Funny

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

    2. Re:That's all we need ... by bersl2 · · Score: 5, Insightful

      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.

    3. Re:That's all we need ... by epiphani · · Score: 1

      Good point - that makes a huge amount of sense.

      Which is probably why they're doing exactly that.

      --
      .
    4. Re:That's all we need ... by Anonymous Coward · · Score: 0

      We have had several init systems in different Unices for years now, Linux itself having several. I fail to see the problem with supporting such choice. You will never be able just drop support for older init systems anyhow, due to old systems still running software and requiring basic updates, or newer ones experimenting with superior solutions, so it's far better to just drop the pretense and make it official. A "one size fits all" solution simply doesn't work in an ecosystem like Linux's userland or even just Debian. Forcing people to use one standard isn't kosher. It either happens naturally, like with sysvinit's reign, or it doesn't. All the blowback to systemd is just evidence of that. Things will fork one way or the other, pretending they won't is foolishness.

    5. Re:That's all we need ... by Anonymous Coward · · Score: 0, Troll

      However, it is undesired by a vocal minority of users and sysadmins

      FTFY.

    6. Re:That's all we need ... by Anonymous Coward · · Score: 0

      First, can you please cite where you have determined that it is "ndesired by a significantly large portion of users and sysadmins"?

      Second, can you please name some *SPECIFIC* problems other than how the source tree is organized because that is, quite frankly, a dumb complaint. The FreeBSD project manages their entire kernel and most of userspace in a single repository and yet for some reason we don't have people running around like chickens with their heads cut off over it.

    7. Re:That's all we need ... by ThePhilips · · Score: 2

      However, it is undesired by a vocal minority of users and sysadmins

      FTFY.

      It is not a minority. It would become a overwhelming majority when the systemd would actually be installed on the majority of the systems. But it would be too late then, of course.

      I probably shouldn't care at all. Systemd would never appear on the systems I work with. For the simple virtue that it is, with the dozens of other "supervision" frameworks, is simply redundant, primitive junk, which is only capable of starting and restarting the Apache server (a.k.a. "hello world" type of service, with no real (distributed networked) dependencies and one bit of state (running/not running)).

      --
      All hope abandon ye who enter here.
    8. Re:That's all we need ... by devent · · Score: 0

      Large portion of users? Lets see. Ubuntu, Debian, Redhat, Suse all use systemd. Where is this large portion of users, please?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    9. Re:That's all we need ... by sjames · · Score: 4, Insightful

      Even in the Debian TC that voted in the first place it ended in a 4 to 4 split with the chairman breaking the tie. That's not a minority, that's half.

    10. Re:That's all we need ... by fgodfrey · · Score: 5, Insightful

      Yeah: Inability to debug what is wrong with the init system when you aren't doing exactly the use case that "normal" people use. I have a number of problems with it, but here's one:
      I've been trying for the last two weeks to end up in a place where my root filesystem was served up by NFS and /var was on a local partition. I had that working under OpenSuSE and need to switch (for unrelated reasons) to Fedora. First, my filesystem didn't get mounted read/write. Easy fix, once you know what's wrong except that journald swallowed all the output (even though I turned on journal+console) and I had no log because of the read only filesystem. The only indication of what was ewrong was systemd saying journald had timed out. On a hunch (after seeing posts on the Arch Linux boards) I added "rw" to the kernel command line and finally got a login prompt. Now, I can't get the /var filesystem to mount before dbus starts because udev depends on dbus and the mount is a systemd special that depends on the device being present which it is, but it requires udev and dbus just to check to be sure. I've also got some weird issue with dependencies not being satisfied so the console getty never starts (on a serial console - the correct unit file seems to be there), but I'm ignoring that since I have network access. Oh, and the system won't shut down cleanly because it shuts down the network before unmounting the root filesystem which is mounted over NFS. But again, I don't even care about that anymore - I just hard reset it with the BMC. I'm sure you'll tell me that I'm a moron and have the thing horrible misconfigured. I *do* have it horribly misconfigured. What I'd like to know is how to *fix* it and systemd is getting in the way of that.

      In SysV init, I would've seen stuff whining about permission denied errors on the console (instead of all the output being eaten, despite turning on debug mode and journal+console mode) and realized I probably didn't have the filesystem mounted right. For the /var stuff, I'd just put it in /etc/fstab and be done. On the off chance that that was not early enough in boot, I'd add a shell script (or hack it into the earliest script) to do the mount. With systemd, I've tried creating unit files several different ways. Telling them they have to run before the stuff that is breaking. No dice. I have no idea why. I thought "ok, I'll just test-run this in a chroot environment". Nope. Systemd won't run there, even to just tell you what it *would* do. In the end, I've wasted weeks on this, learned little about systemd (despite trying - it's the future whether I like it or not. And I don't), and if I ever get it working, systemd won't have gotten me *anything* that I didn't have before. I'd *vastly* prefer an architecture where normal /etc/init handled

      I don't think that the former poster is complaining that the source trees happen to be managed the same way. He's complaining that dependencies are being created between different pieces of software that don't need it. If systemd were set up to where there was a standard /sbin/init and SysV (or similar) init scripts and in a desktop Linux, there was only one script: start systemd, I'd be happy. I suspect most other sysadmin/developer people who hate systemd would be happy. I don't care if it exists, and I don't even care if it exists by default. What I *want* is to easily get rid of it when it's not appropriate for the task I am trying to accomplish and there isn't currently a way of doing that because systemd, journald, dbus, and udev are all tied into one big knot.

      --
      Go Badgers! -- #include "std/disclaimer.h"
    11. Re:That's all we need ... by Anonymous Coward · · Score: 2, Funny

      It is undesired by anyone with an intelligence quotient over 4.

      There now, I fixed that for you, and I typed it real slow like since I know you don't read very well.

    12. Re:That's all we need ... by Anonymous Coward · · Score: 1

      Have you seen the adoption rates for RH after systemd was added? *bomb falling whistling sound*

      There's a reason for that, and it's called systemd. Let it be loaded if you wanna, but not as a default, and never as the only option. web server in the init process? c'mon now, seriously?

    13. Re:That's all we need ... by Anonymous Coward · · Score: 0

      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.

      The udev argument is probably the best I have seen yet for why systemd is ... not good for some Linux deployments, specifically server deployments. I have a follow up though and that is, if the udev components remain unconstrained, would just not installing or removing systemd--for something better or more agreeable anyway--be an option?

    14. Re:That's all we need ... by Wookact · · Score: 2

      A large portion of distributions does not equal a large number of users. You should have realized that though.

    15. Re:That's all we need ... by Anonymous Coward · · Score: 1

      Comparing the entire ecosystem to eight people, a few of which worked for Ubuntu, is idiotic. Even the Upstart creator admitted systemd was far superior.

    16. Re:That's all we need ... by Bengie · · Score: 0

      FreeBSD is written and used by Sysadmins. Maybe the Linux people will learn to appreciate good design from the get-go instead of "Lets fork it!". A well designed system should work within the 80/20 rule. A single distro should be used by 80% of the user base, if it not, something is wrong.

    17. Re:That's all we need ... by nabsltd · · Score: 2

      If I didn't know otherwise, I'd say you were tinkering with my Fedora system.

      I decided switching to a different distribution would be easier than getting systemd to do what I want.

    18. Re:That's all we need ... by caseih · · Score: 4, Interesting

      So you know the majority of system administrators? That's an awful lot of people.

      I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

      This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.

      If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.

      It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.

    19. Re:That's all we need ... by Anonymous Coward · · Score: 0

      Grumpy sysadmins brought down Windows 8, they can do the same by just dragging their feet on upgrading to RHEL 7.

    20. Re:That's all we need ... by Aighearach · · Score: 1

      A reason for what, your lies and propaganda? I doubt it. The reason for the factoid you mention is that you made it up. Make up another one, it will have the same source, the same cause.

    21. Re:That's all we need ... by Aighearach · · Score: 1

      No, the "blowback" is just like #gamergate, a bunch of angry neckbeards who didn't even research the problem, and don't even know if their specific complaints are real things that happened, or hater propaganda they're repeating.

      You'd almost think from the propaganda that systemd doesn't still allow the legacy SysV init scripts to run. But it turns out, they still work fine, and most of the distros with systemd haven't even ported many startup scripts, and even on a computer running systemd most of the startup is still done by the legacy initscripts.

      I support systemd wholeheartedly, but I'm not going to port my old startup scripts. New software, sure, I'll learn the new stuff and integrate the way that is normal in the year that I'm writing the software. But backwards compatibility is a thing.

    22. Re:That's all we need ... by s.petry · · Score: 1

      We have had several init systems in different Unices for years now, Linux itself having several.

      So in Solaris 10 we could choose to remove SMF and use Init? No, we couldn't. You are trying to pretend that an Init system can cohabit with another Init system, and that does not work. Just like there is only 1 running Kernel on a *nix system (VMs don't count), there is only 1 running Init system.

      Different Flavors of Linux have been experimenting with replacing init, but this is not something you change out easily and supporting multiples would be a massive undertaking.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    23. Re:That's all we need ... by linuxrocks123 · · Score: 1

      it's the future whether I like it or not. And I don't

      SystemD clearly has enough adoption that it won't be going away any time soon. Some people, for whatever reason, want an init system that works like that. But other people clearly don't like it. Many of those people are programmers and now want to fork Debian. Even if that fizzles, there's still Slackware and at least Funtoo which are not using SystemD. Funtoo in its FAQ is committed not to using SystemD. Slackware isn't committed, but I think mainly because Volkerding knows to "never say never". But Slackware got rid of GNOME with its annoying PAM dependency long, long ago, so GNOME won't be forcing anything on Slackware, and Slackware uses BSD-style init rather than SystemV, so it was already an init outlier before all of this started. The point is, people who don't like SystemD will coalesce around the distributions not using it, or set up their own, and do the work necessary to keep them not using it.

      Just like with the shutdown of FreeCrypt, there are enough people around who think this is important that they will be able to coalesce and do something about it.

      --
      vi ~/.emacs # I'm probably going to Hell for this.
    24. Re:That's all we need ... by Anonymous Coward · · Score: 1

      Yours is the typical non-argumentation of the SystemD thugs:

      "I know a lot of smart people who like systemd". Well, duh. This ain't about you not using systemd. Use it all you like it. But acknowledge that there are other valid opinions, dammit! No more, no less.

      I'm by now convinced that much of the flack Lennart got is about the attitude of systemd thugs, which has been (unjustly) attributed to him.

    25. Re:That's all we need ... by Anonymous Coward · · Score: 1

      I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list....

      No smart sysadmin would pick up the RHEL. QED.

    26. Re:That's all we need ... by Anonymous Coward · · Score: 2, Interesting

      So you know the majority of system administrators? That's an awful lot of people.

      I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

      That is because they pay for RHEL support, so they will get help in migrating servers if they fail. Also, they don't really have any choice in that regard, they will have to use what the RH gives them to use.

      Well, fuck, i got "autism" captcha. :(

    27. Re:That's all we need ... by Barsteward · · Score: 1

      Minority is probably more accurate, the main objectors seems to be sysadmins with loads of investment in their scripting. There are more desktop users than sysadmins and they won;t care one little bit about systemd, just as long as the desktop works faster.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    28. Re:That's all we need ... by geroy · · Score: 1

      Ok, use it but don't force me to use it without having a choice. What is the problem with that?

    29. Re:That's all we need ... by ThePhilips · · Score: 1

      I had an installation of vanilla Fedora 20 for couple of weeks. The release where it was said that systemd is properly and fully integrated.

      On the same hardware, it did NOT boot or work faster compared to the vanilla Ubuntu.

      On average, Fedora was 50-100% slower. Which was kind of surprising, because I thought nothing can beat the Unity desktop in poor interactivity. And that shell-scripted boot can't be faster than the systemd' C boot sequence. And yet...

      --
      All hope abandon ye who enter here.
    30. Re:That's all we need ... by timbo234 · · Score: 1

      Ubuntu doesn't use sysvinit, it uses upstart which is written in C. So you were comparing two 'C' boot sequences.

      --
      Pre-canned Evolution Links for all those Slashdot holy wars.
    31. Re:That's all we need ... by ThePhilips · · Score: 1

      Yes and no. Mostly no.

      Ubuntu uses upstart only to manage the early boot sequence. Majority of everything is still started by the traditional /etc/init.d scripts, with runlevels and whatnot. There are some services which have upstart jobs - but out-of-box they are minority.

      --
      All hope abandon ye who enter here.
    32. Re:That's all we need ... by Barsteward · · Score: 1

      My "desktop works faster" is not just about systemd, it can be any bit of software/config that makes it faster (as long as it doesn't break)

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    33. Re:That's all we need ... by ThePhilips · · Score: 1

      That has nothing to do with the init system. That performance largely depends on the performance of the applications, and to some extent on the performance of the DE. The init system, after start-up, is mostly idle. The "biggest" job it has then is the reaping of the zombie processes.

      --
      All hope abandon ye who enter here.
    34. Re: That's all we need ... by Anonymous Coward · · Score: 0

      let's fork systemd then.

    35. Re:That's all we need ... by drinkypoo · · Score: 1

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

      Congratulations on one of your typically ignorant comments. The current situation is to support many init systems, but Debian intends to destroy the current state. This project simply maintains the current state of affairs, rather than throwing up one's hands, saying "fuck it", and just adopting systemd.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    36. Re:That's all we need ... by drinkypoo · · Score: 3, Insightful

      I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

      Yes, for the kind of people who run Redhat, which is a turnkey "lick and stick", "Call support", "it's someone else's problem" kind of Linux. Great. I would expect redhat users to fully embrace systemd. That's not a shock.

      For the kind of people who run Debian, it's a big deal. At least, half of us. Half of us are apparently there only for ease of use. They should fuck off to Ubuntu and leave the rest of us alone, since there's already a Debian-fork for them.

      It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well,

      Sure, Solaris has, but AIX hasn't. So what? That was a post-acquisition move, right? And Oracle has a serious NIH mentality. It's not done until it requires Oracle RDBMS. Just wait.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    37. Re:That's all we need ... by Anonymous Coward · · Score: 0

      > The point is, people who don't like SystemD will coalesce around the distributions not using it, or set up their own, .....

      Didn't you forget something here about blackjack and hookers?

    38. Re:That's all we need ... by visualight · · Score: 1

      Well said! Competent people with the authority to make their own choices DON'T CHOOSE RHEL.

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    39. Re:That's all we need ... by BarbaraHudson · · Score: 2

      And that's the problem - adding support for systemd is like the camel's nose.

      Debian's proposal is not workable over the long term, because the long-term goal of systemd is incompatible with non-systemd init systems, and it's not like we don't have enough maintenance headaches already with every distro seeming to have their own scripts, etc.

      So what do you do,
      drinkypoo?
      When it all sucks,
      just go boo-hoo?
      support systemd
      e'en if it's a mistake?
      of course not,
      but that's just my take.
      Burma Shave

      In the end, it doesn't matter what any of us think. What will happen will happen, and we'll deal with it when it happens, not before :-)

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    40. Re:That's all we need ... by Anonymous Coward · · Score: 0

      That's a good idea: don't fork Debian. Fork systemd instead, and release a version that just replaces init with all the other stuff removed and sabotaged. This seething divisive hatred wasn't the general reaction reaction to Solaris's SMF even though it's similar to systemd: just as drastic, replaces init. SMF doesn't infect the rest of the system, though. It just replaces init.

    41. Re:That's all we need ... by Anonymous Coward · · Score: 0

      I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list,

      [snort].

      I'm sure there are, but there are also a lot of toolios paying RedHat for support because they don't know what they're doing. RedHat has a specific RedHat-certified way of doing everything, and if you make any serious changes to the system they won't support you. Editing an init script would certainly qualify as killing support.

      Some of these RedHat sysadmins are just smart hands / telephone monkeys. For the smarter ones, RHEL shops are depressing places to work. Your skill is not respected because the owner finds the option of deferring to RedHat support more valuable and reliable than you. It's a way of making sysadmins interchangeable, so the least common denominator is the most you are allowed to put forth.

      and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.

      In short, we all know it's not an issue for "many" people. However, it *is* an issue for many people, too. What are you saying? You're saying nothing, really nothing at all. Your post is very understated so I think most people won't recognize it as such, but it's the definition of flame-bait: amping up an already-existing conflict without actually contributing anything.

    42. Re:That's all we need ... by Anonymous Coward · · Score: 0

      That was a post-acquisition move, right?

      Incorrect. SMF was part of the last gasp of good work from the old Sun. SMF was released at the same time as dtrace, ZFS, UltraSPARC T1, free compilers, image packaging system, and full source code. After acquisition nothing was released, and all the smart people quit.

    43. Re:That's all we need ... by marcello_dl · · Score: 1

      Debian goals are incompatible with a systemd-only system, that's the reason.
      Removing mandatory systemd dependencies is what debian has to do. The technical committee can choose systemd as default init system, but from there to only init system means they can all go home and install redhat.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    44. Re:That's all we need ... by Anonymous Coward · · Score: 0

      Sure, Solaris has, but AIX hasn't. So what? That was a post-acquisition move, right?

      Solaris' SysV init replacement, SMF, was introduced in Solaris 10, which was released in 2005 - 4-5 years before Oracle bought Sun.

    45. Re:That's all we need ... by jwhitener · · Score: 1

      Yes, for the kind of people who run Redhat, which is a turnkey "lick and stick", "Call support", "it's someone else's problem" kind of Linux. Great. I would expect redhat users to fully embrace systemd. That's not a shock.

      So in other words, the vast majority of all system admins. I've never heard of an enterprise level company running servers without full 24/7 vendor or contracted outside support for both the hardware and the OS.

    46. Re:That's all we need ... by jwhitener · · Score: 1

      Curious, why do you want the root files coming from NFS and not stored locally?

  8. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 1, Redundant

    And that is still the point. Linux, BSD etc are all good for a purpose.

    Linus is NOT good for the desktop or average user. Most people just want something that works out of the box, even if there are a lot of tradeoffs.

  9. This could be really good for Debian by Bruce+Perens · · Score: 5, Interesting

    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.

    1. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      Not sure if you're talking about the systemd people or not.

    2. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      Care to elaborate? "Certain contigent?"

    3. Re:This could be really good for Debian by Bruce+Perens · · Score: 5, Insightful

      I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.

    4. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      So not for any technological reasons, then? Sheesh, Bruce. Pundit much?

    5. Re:This could be really good for Debian by ThePhilips · · Score: 5, Insightful

      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.

      --
      All hope abandon ye who enter here.
    6. Re:This could be really good for Debian by Anonymous Coward · · Score: 1

      Meh, it's easy to find people with skill. With values, OTOH...

      Anyway, this is what happens when half the Linux community are just frustrated OS X fanboys who think they'd've got that developer job at Apple if only there had been one more opening...

      If this helps identify the subset of Linux developers who yearn for the lean, mean, install-anything rather than install-everything-or-nothing Unix operating system that once was, I'm all for it. And shall be installing whatever they have to offer.

    7. Re:This could be really good for Debian by lgw · · Score: 2

      Is there any current distro focused on easy desktop use that has resisted the system wave? I'd hate to see the world divided into "server distros (know what's you're doing or don't even try)" and "easy desktop distros, system required".

      --
      Socialism: a lie told by totalitarians and believed by fools.
    8. Re:This could be really good for Debian by ThePhilips · · Score: 2, Insightful

      I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.

      The Ubuntu LTS releases, are pretty much what I always expected from the Debian.

      The difference is that Ubuntu isn't afraid to put time of developers into the release.

      While Debian insists on simple repackaging.

      I'm sorry to say it, but Debian has already been a "whore" to lots and lots of other distros, even before Ubuntu hit it big. For the fact of having no distinctive technology of their own.

      Recall the time when the APT was ruling. Back then, the Debian ruled. APT had set the bar for other package management systems. People followed the Debian. Now? Not so much. Debian is following and has been following for many many years now. They are not distro per se - they are the distro factory, other distros build up on. I gather that makes it a "whore" distro.

      Blaming Ubuntu misses the point. Because Ubuntu does much more than just repackage the Debian. The bigger question is: why Debian hasn't evolved into something like Ubuntu is? Where's Debian's launchpad with the PPAs? where anybody can develop new things? where from users can easily access the new things?

      --
      All hope abandon ye who enter here.
    9. Re:This could be really good for Debian by Peter+H.S. · · Score: 2

      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 has to be real tangible code and some track record for such a project to have a realistic change of being the new Debian init system however.

    10. Re:This could be really good for Debian by jbolden · · Score: 1

      The weird thing about this is that Ubuntu threw in the towel on systemd themselves. They realized they are behind and Upstart can't catch up.

    11. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      Debian was always repackager, that was the thing APT did packaging better than any distro. When the Linux Standard Base was formulated, it arguably lost clout, momentum, and validity for choosing RPM over APT, because that is what Debian did. Sick of downloading rpm, tgz, and or source packages of the net just to get lost in dependencies, well have I got a distro for you!

    12. Re:This could be really good for Debian by ThePhilips · · Score: 1

      Compare that to the Fedora. The immaturity of systemd hasn't prevented them from actually giving the users a chance to try the new init system. It actually helped to step up its development. And Red Hat isn't even the top contributor to systemd.

      The Debian does lots of good things - but it fails at letting people to help them.

      New things are always going to lack "tangible code and some track record". And the Debian is the wrong place for a project to try to get one. And that is the biggest problem of the project, IMO.

      --
      All hope abandon ye who enter here.
    13. Re:This could be really good for Debian by sjames · · Score: 1

      They already had a working init system. Not all new and shiny, but perfectly functional. They had the option to stick with it while advocating for a better choice to be created. Or pick just about anything that discourages the growing hairball.

    14. Re: This could be really good for Debian by Anonymous Coward · · Score: 0

      A whore to Ubuntu? They bent over and took it from Valve the moment free shit was being waved their way too.

    15. Re:This could be really good for Debian by Bruce+Perens · · Score: 1

      It's sort of a chicken-and-egg issue. Debian doesn't get the help because Debian doesn't make itself worthy of getting the help. There have previously been paid developers working on Debian, they simply weren't paid by Debian.

    16. Re:This could be really good for Debian by Bruce+Perens · · Score: 1

      Meh, it's easy to find people with skill. With values, OTOH...

      You have a point.

    17. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      This is were I see things going for the future of Linux. Just a few distros targeting a specific area (server, desktop, and embedded).

    18. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      Except it's not that: RHEL, the king of server distros has been pushing systemd (I think because their devs are now incapable of doing anything except using (currentFedora minus four versions) as any new RHEL, and this means systemd since Fedora is always bleeding edge.

    19. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      Fedora doesn't allow for sysvinit at all.

      Back with Fedora 15, sysvinit was available as an option... But it didn't work. The systemd packages all conflicted with it. So it got dropped.

      When problems with service startup happened, instead of fixing the bug, they changed the service - adding a dependency on systemd.

      With each problem, they just added more crap.

    20. Re: This could be really good for Debian by Anonymous Coward · · Score: 0

      Key systemd developers are emplyed by Red Hat. At this rate i except them to relocate RH HQ to Berlin within a year...

    21. Re:This could be really good for Debian by steelfood · · Score: 2

      I've found one major distro that still avoids systemd (for now anyway): PCLinuxOS.

      It's listed on DistroWatch among the top 20 Linux distros, for whatever that's worth.

      Otherwise, every other major Linux distro uses systemd.

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
    22. Re:This could be really good for Debian by mvdwege · · Score: 1

      Not all new and shiny, but perfectly functional.

      Tell that to my girlfriend. She can do most maintenance on her workstation, but she had to have me look at boot deadlocks about twice a month, all because /etc/init.d/rpcbind and /etc/init.d/networking were in a race, and the NFS mounts lost.

      SysV rc is not 'perfectly functional' by a long shot. Both at home and at work I keep running into limitations that systemd solves. Systemd comes with other bugs, and I've been hit with one or two of them, but they were, for me, easier to solve than SysV rc race conditions and deadlocks.

      The growing hairball is SysV rc. Systemd is an attempt to solve it. You may disagree with the solution, fine. But stop denying that it is at least an attempt at solving existing problems.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    23. Re:This could be really good for Debian by drinkypoo · · Score: 1

      Tell that to my girlfriend. She can do most maintenance on her workstation, but she had to have me look at boot deadlocks about twice a month, all because /etc/init.d/rpcbind and /etc/init.d/networking were in a race, and the NFS mounts lost.

      Linux NFS needs help. We all know it. The solution is not to hide the problems with another daemon.

      SysV rc is not 'perfectly functional' by a long shot. Both at home and at work I keep running into limitations that systemd solves.

      Let's hear about them. Still haven't heard about any, just seen hand-waving.

      Systemd comes with other bugs, and I've been hit with one or two of them, but they were, for me, easier to solve than SysV rc race conditions and deadlocks.

      you mean failures of the linux NFS daemons.

      If you're depending on NFS to boot, then you're a sucker. Because NFS hasn't got the love it needs, especially on Linux.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    24. Re:This could be really good for Debian by mvdwege · · Score: 1

      I just gave you an example, and you ask for examples? What are you, stupid?

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    25. Re:This could be really good for Debian by drinkypoo · · Score: 1

      I just gave you an example, and you ask for examples? What are you, stupid?

      Your problem was not a problem with init. Systemd will not solve the problem where you need NFS to boot, and NFS shits itself because it is shit.

      Give us an actual example where init itself caused you a problem, or admit that you're just making shit up so that you can justify new and shiny. You're calling me stupid for insisting that you provide an actual example of a failure of init when what you provided was an example of a failure of the networking setup which could have also occurred with systemd if you misconfigured it. Now, provide an actual example of a failure of init, or if this was somehow init's fault (did it really start two init scripts at once all on its lonesome, or did the first script exit before it was done?) then explain that, and don't just describe a problem with scripts (which could also happen by misconfiguring a unit file) or with a daemon. From your description, it sounds a lot more to me like a problem with your distribution's network setup system, whatever that looks like.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    26. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      So because your cunt has a problem we should feel bad?

      I don't use either of those things you mentioned.

    27. Re:This could be really good for Debian by Alioth · · Score: 1

      That's a feature, not a defect. I run Debian on a bunch of servers. I like that it changes slowly. I like that it's not trying to be the bleeding edge. I like that migrating from one major version of Debian to the next is reasonably painless. For running a bunch of servers, I want something that follows the tried and trusted, not something that rides on the bleeding edge and something that has an absolutely rock solid packaging system. This is Debian, and it's why Debian is the right tool for this job.

      If you want a distro that develops, there's always Ubuntu or Fedora.

    28. Re:This could be really good for Debian by ThePhilips · · Score: 1

      That's a feature, not a defect.

      If you want a distro that develops, there's always Ubuntu or Fedora.

      My point wasn't that Debian is being developed too slow. QA has never been fast.

      My point is that Debian nearly always distances itself from the development and the developer community.

      In other comment I also mentioned the APT. If Debian was today debating a packaging system, they would never ever opt to *develop* the APT like they did in the past, but they would take the RPM and try to live with it.

      Otherwise, just look at two good examples of distros evolving: SUSE Studio and Ubuntu Launchpad. Lots of things which happen there rarely see the daylight - but they allow distro to play proactive role in bringing together the developers and users. (But of course, SUSE Studio and Launchpad are targeted at two different kinds of "developers" - first is for developers of distros and second is for the developers of the software.) That might seem superficial, but it allows distro to actually learn about the new trends and things people are doing with the software. They need much less guessing what/how to do in the next release. OTOH Debian, beside the heavily unreliable popcon, is very very much closed and unto itself.

      That distance also plays role in how Debian's decisions are made. You can't roll-out something new and experimental in Debian and expect later it being adopted in Debian main. No. Because Debian wants to have a project with proven track record. And you can't get the "proven track record" *in* Debian - because the project will not be accepted without "proven track record". That is why the development happens in the Fedora, Ubuntu and SUSE. Rarely in Debian.

      And why is this on-topic? Because Debian with migration to systemd would in some aspects become Red Hat, which is not something I'm particularly happy about. Because, though RH doesn't develop much of the systemd itself, it does quite a lot of work on systemd integration. Because they played role in its development. They gave the project fighting chance. And all it took for them was to say the developers: OK. At the same time, if you check history of attempts to bring upstart into Debian (which is much longer than the vs systemd discussion), Debian wasted literally years discussing, and mostly dismissing upstart because it was used by only one distribution, despite Canonical's pledge. Result? Red Hat has nurtured the systemd - and Debian has strangled the upstart.

      --
      All hope abandon ye who enter here.
    29. Re:This could be really good for Debian by Anonymous Coward · · Score: 0

      NFS cause problems in Systemd as well.

      There are multiple examples across the net were people find Systemd deadlocking on shutdown.

      And the cause is invariably that Systemd shutdown networking before NFS had gotten cleared out.

    30. Re:This could be really good for Debian by sjames · · Score: 1

      Was it really that hard to change the symlink name to enforce rpcbind coming after networking?

    31. Re:This could be really good for Debian by mvdwege · · Score: 1

      I just told you that systemd handles the dependency between rpcbind and the network coming up in a sane and reliable way, whereas the init scripts don't. What more do you fucking want?

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    32. Re:This could be really good for Debian by mvdwege · · Score: 1

      Yes, it was. Because the networking script tries to start nfs. There is a circular dependency in the scripts that is hard to debug.

      And before you say that I should just edit those scripts: every next update may overwrite them, whereas systemd handles this dependency sanely. Why should I muck about with scripts then?

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    33. Re:This could be really good for Debian by drinkypoo · · Score: 1

      What more do you fucking want?

      I want you to stop blaming shitty init scripts on init. Only an idiot would do that.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    34. Re:This could be really good for Debian by sjames · · Score: 1

      Funny how I'be never had a modified init script overwritten by an update. Did you consider sending a bug report and patch to the package maintainer?

    35. Re:This could be really good for Debian by mvdwege · · Score: 1

      Sigh. Why do you have to turn this into another dick size war? I was trying to be reasonable by pointing out that SysV had some failure modes that systemd tries to address, and that one could at least accept that as a common ground upon which to debate the merits of both systems, but apparently you don't want to give even that much.

      And then people complain that Lennart is occasionally a bit crabby online. Frankly, I'm starting to understand the guy.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    36. Re:This could be really good for Debian by sjames · · Score: 1

      It has nothing to do with genitalia. It has to do with naming an actual problem that people actually have that requires systemd as a solution. Claiming that systemd can't give you cold sores isn't much of a supporting statement when no software can give you cold sores.

      I still haven't seen a single problem that requires a hairball of dependencies staked down into PID 1 to solve. I genuinely want to understand why the systemd camp doesn't solve the problems in a more flexible and reasonable manner which would, incidentally, put to rest all of the controversy. Why can't systemd be started from the old init instead of (or along with) rc.S for example (at lest as an optional configuration)?

      Evidently, logind was modified such that it doesn't need systemd to operate so it could go into Ubuntu to support Gnome. So then, why did it ever need systemd and why can't it stay in modified form upstream? For that matter, why isn't it a standalone project or a part of Gnome (the only thing that cares about it)?

      But more specifically here, the discussion turned to why can't a Debian fork stick with sysvinit for another release cycle. You arguie it is way too buggy for that because of a situation you admit you already solved but apparently didn't send along with a bug report.

      In the end, I'm not the one trying to jam my fingers into your pie. Half the systemd camp claims they are absolutely positively not trying to cram systemd down my throat but as soon as I discuss not going to systemd the other half wants to tell me how impossible that is. Some even gleefully prattle on about how they will get more and more software to depend on systemd so I won't be able to patch it out fast enough to keep going. Really nice, huh?

      Look in the mirror.

    37. Re:This could be really good for Debian by mvdwege · · Score: 1

      Well then call me an idiot and have done.

      Shitty scripts are part and parcel in SysV rc. The whole system is an attractive nuisance for badly hacked together shell scripts, and it's a wonder it's held out as long as it did.

      All this IMO, of course.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    38. Re:This could be really good for Debian by mvdwege · · Score: 1

      NO. My argument was not that sysvinit was way too buggy. Your argument was that it was perfect, and I was disputing that by giving a single example of one of the possible ways it can break.

      It's in fact this kind of dishonest arguing that is making those of us that want to look objectively at the various init systems move away even faster from SysV. Be proud of it. Now fuck off.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
  10. Re:And this is why Linux will never win the deskto by jedidiah · · Score: 3, Insightful

    That list glosses over a couple of major problems.

    1) You avoid the current version because it's such a usability disaster that no one wants to touch it. It's so bad that people would rather run an ancient and completely unsupported version.

    2) Your current hardware is suddenly obsolete because it's last years model and it's not supported anymore.

    Modular design makes "rage-forks" a lot less of a problem than some people try to make them out to be.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  11. Threatening with a fork is never appropriate. by Anonymous Coward · · Score: 1

    Threatening with a fork is never appropriate. With its multiple sharp points, a fork can be quite dangerous if used incorrectly!

    1. Re:Threatening with a fork is never appropriate. by Anonymous Coward · · Score: 0

      Then again, if the fork is plastic, is to not too bad, as the points will break off. If it a foam one made as a toy, bring it on I say!

    2. Re:Threatening with a fork is never appropriate. by __aaclcg7560 · · Score: 1

      Use the spork, Luke!

    3. Re:Threatening with a fork is never appropriate. by sjames · · Score: 1

      Always threaten with a spoon.

    4. Re:Threatening with a fork is never appropriate. by Drgnkght · · Score: 1

      Especially if it's dull.

  12. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 5, Interesting

    Whoever installs your OS chooses for you. Might be your hardware vendor, maybe your nerdy cousin.
    My wife read about Vista when it was coming out, and she asked me to install "Linux" for her so she could get used it to it before Vista happened.
    I didn't ask her which distro; I chose one.
    Anybody who can install an OS can choose one.

  13. Re:And this is why Linux will never win the deskto by 0123456 · · Score: 1

    Choose your OS, average user:

    1) Windows

    Which Windows, out of the dozens of confusing versions and three or four different UIs?

  14. Re:And this is why Linux will never win the deskto by 0123456 · · Score: 4, Funny

    Linus is NOT good for the desktop or average user.

    Is Linus the Linux version of Microsoft Bob? I'd agree, then, that the average user wouldn't want him swearing at them every time they do something stupid.

    Most people just want something that works out of the box, even if there are a lot of tradeoffs.

    So why would they want Window 8?

  15. Does not sound serious by Anonymous Coward · · Score: 0

    This debianfork website does not really make the impression as if it has been done by a group of sys admins.
    They claim that they have 950 supporters! (German).

    I do not think that so many people would gather anonymously.
    It's probably 1 or 2 guys who bought a domain and wants to force his opinion onto the debian developers.

  16. Re:And this is why Linux will never win the deskto by MikeBabcock · · Score: 1

    Wait, there's only one Windows? I could've sworn there were at least a half dozen active versions out there with features that aren't all inter-compatible ... just like Linux. They don't even look alike, and it causes fragmentation.

    Why is Windows on the desktop? Applications and vendor support (bribed or otherwise) which boils down to "because it has been around longer."

    The difference with Linux is you get a choice, and you get to argue, and it makes a difference. There are far more on-line posts about people who do or don't like Windows 8's interface than about systemd, but that isn't the cause of Window's sudden failure on the desktop now is it?

    --
    - Michael T. Babcock (Yes, I blog)
  17. its not a claim, its a fact of life. by nimbius · · Score: 5, Insightful

    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)

    --
    Good people go to bed earlier.
    1. Re:its not a claim, its a fact of life. by kthreadd · · Score: 4, Informative

      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.

    2. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 1

      These are three daemons in an IPC architecture. Together they make up an application.

      Unless you feel that a multi-tiered web application is somehow three programs: JavaScript, CGI, and database...

    3. Re:its not a claim, its a fact of life. by Zarjazz · · Score: 1

      What's the problem with that? Linux still has a serious weakness making itself an option for normal Desktop users. It'll never be a Windows replacement in it's current state. So replacing a simple text based boot system that sysadmin have been using for 20 years with a complex & monolithic control system that is amalgamating several tried and tested services into borg-like hive system with binary logging makes perfect sense. Just look at Microsoft with the Windows registry and how well that works.

      please note, I may be using some sarcasm in this post.

    4. Re:its not a claim, its a fact of life. by devent · · Score: 0

      How many times is this lie going to be repeated. Systemd does not put everything "into one application". Systemd consists of many separate applications and daemons, many of them not even link against systemd. The developers of systemd have all of those separate apps and daemons in one code repository, but you can pull each of them out and compile each of them separatly.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    5. Re:its not a claim, its a fact of life. by gehrehmee · · Score: 1

      These are three daemons in an IPC architecture. Together they make up an application.

      Unless you feel that a multi-tiered web application is somehow three programs: JavaScript, CGI, and database...

      Then sysvinit is a bunch of service configuration files disguised as bash scripts knitted together with an init to make up an application. Hell, they use an API in the form of passed arguments, which you might call even more application-like than IPC!

      And yes, javascript in your web browser, an httpd, and your database are certainly 3 different programs that happen to interoperate. You can even drop one out and replace it with a different company's implementation of it. That's something I'd love to see more of in systemd, but it's theoretically possible, if somebody really felt the need to.

      --
      "You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
    6. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 0

      If it's so good for us, why are you trying to force it upon those of us who don't want it? Won't we see the light eventually and convert?

      Also, why is it a dependency for GIMP?

    7. Re:its not a claim, its a fact of life. by sjames · · Score: 1

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

      And those are all entirely independent of systemd?

    8. Re:its not a claim, its a fact of life. by JesseMcDonald · · Score: 1

      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.

      Exactly. It's not a single application, it's a brand. Separate applications developed in a common repository and intended to work well together. One might as well complain about all the basic utilities under the GNU project umbrella. Or consider the various BSDs, where the entire userspace (including the init system) is developed in the same repository as the kernel.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    9. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 0

      application != program(executable).

      The tightly coupled C APIs within and going into systemd are part of the problem.

    10. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 0

      so what the fuck is wrong with the rest of anything to do with linux / unix, none of its software does one thing well, it just does it half assed enough to not make you want to vomit

    11. Re:its not a claim, its a fact of life. by thaylin · · Score: 1

      Except separately they still work with no interdependence. If you want to use syslog you cannot remove journal, the best you can do is mask it by having it send the data to syslog.

      --
      When you cant win, ad hominem.
    12. Re:its not a claim, its a fact of life. by nabsltd · · Score: 5, Informative

      One might as well complain about all the basic utilities under the GNU project umbrella.

      I can use ls without having to use info, but I can't use systemd-networkd without using systemd. Conversely, there is no logging system other than systemd-journald that works with systemd.

      In other words, each individual program that makes up the "systemd brand" must all be installed and running or else none of them work. This is completely different from the current init system, which doesn't care which system logger (for example) you use, and doesn't even require you to use one at all.

      So, even though the "systemd brand" is many separate applications, the net result is no different from one monolithic application with many shared libraries.

    13. Re:its not a claim, its a fact of life. by nabsltd · · Score: 0

      The developers of systemd have all of those separate apps and daemons in one code repository, but you can pull each of them out and compile each of them separatly.

      But you can't run them separately.

    14. Re:its not a claim, its a fact of life. by thaylin · · Score: 1

      So I can completely pull journald out and not use it, and just use syslog? I dont think you know what you are talking about.

      --
      When you cant win, ad hominem.
    15. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 0

      I believe they all link to dbus.

      And they won't work without the other "separate applications and daemons". They all exchange messages with systemd over dbus.

      And that ties them together into a single unit.

    16. Re:its not a claim, its a fact of life. by Anonymous Coward · · Score: 0

      This clearly and thoroughly explains why your points are wrong:
      http://bsd.slashdot.org/comments.pl?sid=5663319&cid=47859991

    17. Re:its not a claim, its a fact of life. by JesseMcDonald · · Score: 1

      I can use ls without having to use info, but I can't use systemd-networkd without using systemd. Conversely, there is no logging system other than systemd-journald that works with systemd. ... In other words, each individual program that makes up the "systemd brand" must all be installed and running or else none of them work.

      Having looked over the source for systemd-networkd, I see no particular reason why it couldn't be used outside of systemd provided dbus was up and running. I'll grant that systemd depends on systemd-journald, or at least something implementing the same interface. That's one of the few "hard" dependencies; most of the remaining services (like networkd, hostnamed, localed, and timedated) are optional. I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
    18. Re:its not a claim, its a fact of life. by Barsteward · · Score: 1

      if it is then complain to the GIMP developers to make it optional

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    19. Re:its not a claim, its a fact of life. by devent · · Score: 1

      systemd uses journald for its own internal logging. You just asked, can I pull the network stack of the Linux kernel and use my own.
      But you can use syslog in systemd for your own stuff.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    20. Re:its not a claim, its a fact of life. by devent · · Score: 1

      Sure you can. systemd-ask-password is not even linking systemd.

      % ldd /usr/bin/systemd-ask-password
                      linux-vdso.so.1 => (0x00007fffb5daa000)
                      libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f07acb03000)
                      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f07ac8ed000)
                      libc.so.6 => /lib64/libc.so.6 (0x00007f07ac52e000) /lib64/ld-linux-x86-64.so.2 (0x00000033b9800000)
                      libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f07ac2c8000)
                      liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f07ac0a3000)
                      libdl.so.2 => /lib64/libdl.so.2 (0x00007f07abe9e000)
                      libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f07abc81000)

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    21. Re:its not a claim, its a fact of life. by thaylin · · Score: 1

      So your answer is no, and the poster above me is completely wrong....

      --
      When you cant win, ad hominem.
    22. Re:its not a claim, its a fact of life. by nabsltd · · Score: 1

      I assume you were exaggerating, but just to be clear: it is not necessary to run all of the programs which make up the systemd "brand". With the exception of a few core dependencies like journald, you are free to pick the components you wish to run.

      So, you've tried this? Either by compiling one of the "extras" and running it on a system where systemd isn't installed, or by completely removing the extras and running alternatives that give the same functionality?

      Didn't think so.

    23. Re:its not a claim, its a fact of life. by nabsltd · · Score: 1

      Sure you can. systemd-ask-password is not even linking systemd.

      Which isn't important when all communications between the two is via IPC.

    24. Re:its not a claim, its a fact of life. by devent · · Score: 1

      My answer is that you are an idiot, and I explained with my previous post why.
      systemd uses journald for its own internal logging. You could hack systemd to use something else.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    25. Re:its not a claim, its a fact of life. by devent · · Score: 1

      PS: and it's not an ad hominem to call you an idiot, if I can demonstrate that you are an idiot. Which I did.
      systemd uses journald for its own internal logging. It's like in my applications that I write I use logback (Java logging) and you are asking if you could replace logback with your own logging framework. You could, if you hack my application. But what is the point of it.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    26. Re:its not a claim, its a fact of life. by devent · · Score: 1

      You can write your own application that communicates with systemd-ask-password. What is your point?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    27. Re:its not a claim, its a fact of life. by JesseMcDonald · · Score: 1

      So, you've tried this? ... by compiling one of the "extras" and running it on a system where systemd isn't installed ...?

      That isn't what I said. You can run systemd without running all of the other components. I use systemd for init but networkd or firewalld, for example. The reverse may or may not be possible for any particular component within the systemd "brand", and I don't see any problem with that. These programs are add-ons designed to work with systemd. If they happen to work without it as standalone daemons, that's a nice coincidence, but by no means essential. Anyone using sysvinit already had their own cobbled-together shell scripts for managing these things.

      Anyway, why would I want to? Systemd works just fine for me as it is. I have no need nor desire to split up the package. Don't fix what isn't broken. (And yes, sysvinit was well and truly broken. Linux was one of the last Unix-based operating systems to cling to it; everyone else had already moved on.)

      --
      "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
  18. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I am an experienced WIndows user and ihave tried several time to install Linux. Each time I look for the "magic" "download and install" button, I see endless disucssion and text and technical nonsense that developers should not incldue in the realses.

    It alwasy ends the same... delete Linux downloads... be thankful Windows works well.

  19. Re:And this is why Linux will never win the deskto by jedidiah · · Score: 4, Insightful

    Linux works out of the box in the same way that MacOS or Windows does.

    If your average Windows user had to install their own OS they would be even more lost than if they tried dealing with Linux.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  20. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Choose your OS, average user:

    1) Windows

    Which Windows, out of the dozens of confusing versions and three or four different UIs?

    You seem to live in the past, the multiple-SKU Windows people liked to joke about is reduced to two these days, with difference being functionality like ability to join domains, not app compatibility - like you do experience between Linux distros. But dozen it never was, but I do understand you need to exaggerate this. And 3-4 UIs? Really? There is one for touch and one for desktop.

  21. What? by s.petry · · Score: 5, Insightful

    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*)

    --

    -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    1. Re:What? by mlts · · Score: 5, Insightful

      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.

    2. Re:What? by profplump · · Score: 1

      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?

    3. Re:What? by Anonymous Coward · · Score: 0

      >IBM still obtains boku bucks

      The word you're looking for is "beaucoup." You seem super-high.
      http://www.merriam-webster.com...

    4. Re:What? by jbolden · · Score: 2

      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.

    5. Re:What? by s.petry · · Score: 2

      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 how it's implemented. In a market that dictates minimum manpower, we don't have the headcount to do this.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    6. Re:What? by sjames · · Score: 2

      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?

    7. Re:What? by Anonymous Coward · · Score: 0

      bullshit bullshit bullshit

    8. Re:What? by s.petry · · Score: 1

      First, the majority of the market is not PaaS vendors. The Majority of the market is everyone but PaaS vendors. Lastly, your generalization is probably false. I'm sure you can find a few anecdotal samples of companies that do, but there is no market study that polls all vendors to gather their opinions. I know of some that don't want it, and I know a couple that don't care one way or another.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    9. Re:What? by sjames · · Score: 4, Insightful

      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.

    10. Re:What? by jbolden · · Score: 1

      First, the majority of the market is not PaaS vendors.

      True. But the claim was, "Systemd may be fine for a desktop, but not fine for a server". Obviously the PaaS vendors are doing server.

      I know of some that don't want it

      Which PaaS vendor has come out against systemd?

    11. Re:What? by ChunderDownunder · · Score: 1

      bo-ku is a perfectly cromulent word.

      http://www.urbandictionary.com...

    12. Re:What? by s.petry · · Score: 1

      First, the majority of the market is not PaaS vendors.

      True. But the claim was, "Systemd may be fine for a desktop, but not fine for a server". Obviously the PaaS vendors are doing server.

      I know of some that don't want it

      Which PaaS vendor has come out against systemd?

      You failed to see the flaws in your logic even after they were called out. No thanks, I don't feel like playing this game today.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    13. Re:What? by Culture20 · · Score: 1

      >IBM still obtains boku bucks

      The word you're looking for is "beaucoup." You seem super-high.

      Might have been trying to say "goku". That would make GP super-saiyan.

    14. Re:What? by Culture20 · · Score: 2

      Ego.

    15. Re:What? by Anonymous Coward · · Score: 0

      mod this asshole down. Systemd needs to die.

    16. Re: What? by Anonymous Coward · · Score: 0

      What if we "hack things often@ because the current system is broken ?

    17. Re:What? by The+Technomancer · · Score: 2

      Yeah, that user tried the same thing with me as well a few day back.

      While linking me to Red Hat's PaaS offering.

      I've got the same complaints about systemd, namely that I either have to find engineering man-hours to convert all of the existing supporting infrastructure I have to a systemd world, or find engineering man-hours to maintain an in-house distro. Even if systemd is a clear upgrade over every single component it has its tentacles in (for the sake of argument), it isn't enough to justify refactoring a working infrastructure on a DevOps team that's already understaffed as it is.

      I'm sure Red Hat has a Solutions Architect that's happy to have me pay tens-to-hundreds of thousands just to get my infrastructure back up to where it was prior to systemd, though!

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    18. Re:What? by pjbgravely · · Score: 1

      I presently run Ubuntu server for my home server becouse it was quick to build a headless system with no GUI. It seems the new Ubuntu server has a GUI now and is bult for being a cloud base. Now it looks like I will have to find a new distro in 3 years.

      I left Ubuntu on the desktop years ago becouse it became unusable. I went to Debian sid and let it upgrade to systemd, and so far it makes boots longer and kills the network most of the time.

      --
      Star Trek, there maybe hope.
    19. Re:What? by Anonymous Coward · · Score: 2, Insightful

      Someone mod this up. This gets right to the root of why "Windowizing" *nix is a really, really bad idea.

      Maybe Microsoft will hire Poettering and put this nightmare behind us.

    20. Re:What? by Anonymous Coward · · Score: 0

      The primary problem is reliability...

      Since systemd had this assumption that a service is ready for use when the process forks.... it causes problems because it can take a bit of time before it actually IS ready.

      This assumption means that processes that do depend on it might not be able to run... I say "might not" because things run in parallel - so what works once may not work the next time.

      The next problem is that network analysis (that dependency thing) is an NP hard problem. The more things a server has to do, the more complex the analysis has to be.

      Then there is the security issues.... handling sockets allows systemd to delay the startup of some services until a connection is made... So databases may not actually get started... until the dependent service tries to access it. But then there are timeouts that can occur.

      Shutdown is also not reliable (that parallel thing again) dependencies have a nasty out-of-order sequencing happen - like having mounts removed out from under them (which hangs the shutdown).

    21. Re:What? by Aighearach · · Score: 1

      No, a cromulent word has to be a made-up word that appears authoritative but isn't. (yet) "[B]oku" isn't cromulent at all, it is just a misspelling. I recommend you embiggen your vocabulary.

    22. Re:What? by Aighearach · · Score: 1

      Well, if that is all it is, then it is just a dishonest myth.

      Of course, as a sysadmin I already knew that most sysadmins love systemd because it solves a whole basket of real problems.

    23. Re:What? by Aighearach · · Score: 0

      Your point seems to be, "new stuff requires new debugging methods on failure, avoid new stuff."

      Like most sysadmins I generally agree. But also like most, I'd been waiting decades for SysV init to get replaced. It is worth learning something new every couple decades.

      As an aside, most competent admins wouldn't be "resorting" to the kludge you describe, and will probably just stare and you and blink rapidly when told doing so is supposed to be a good thing.

    24. Re: What? by s.petry · · Score: 2

      We normally don't hack things because Init is broken, we hack things because a driver or application requires some tweaking. What if I'm on a server where the brocade takes longer than the driver expects to respond? What if I'm starting up 200-400 Apache sites on the same host and I need to make sure I have numerous DBs available, bind each site to a unique IP (and I only want the interface up if the site is up)?

      There are numerous examples like this which have nothing to do with Init being broken, and Systemd does not make them any better. In fact a parallel Apache process is going to be a pain in the ass to write for systemd (or we keep that in legacy mode and hope that a package/update does not add it back into systemd. One of the primary principles of Unix has been "if it ain't broke don't fix it", and there is nothing broken about init.

      In the case of a Desktop, most things work fine out of the box. Servers are not, and never have been, the same thing as a Desktop.

      The main selling point for Systemd is like Sun's SMF, and it can restart process that die. They want Apache to restart if it crashes for example. From an old timer perspective, if Apache crashed then there was a reason. I don't want a service restarting Apache when this happens, I want to investigate and fix the problem. Central monitoring does more for this than SMF, and I have worked with SMF since it was released. Systemd is no better than SMF in any regard.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    25. Re:What? by Aighearach · · Score: 1

      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.

      Or, it is an important update and solves problems that are not related to the "desktop" or "server" roles of the box.

    26. Re:What? by s.petry · · Score: 1

      SMF is like SystemD, and I remember spending about 3-4 months rewriting all of our tools to work with SMF when Sun released it. It was not the magic bullet Sun thought it would be, processes would stick and have to manually be cleared all the time and I don't ever recall it restarting a service like they promised.

      At least SMF uses XML scripts, so you can hack away just like a boot script with minimal knowledge, just hack between XML tags. This is where I don't look forward to using systemd or it's competitor. They both believe that booting should be out of DB that you can't hack without importing and exporting objects. That is where my biggest frustration is, if I can't see it I don't trust it.

      --

      -The wise argue that there are few absolutes, the fool argues that there are no probabilities.

    27. Re:What? by sjames · · Score: 2

      Your point seems to be, "new stuff requires new debugging methods on failure, avoid new stuff."

      My point is new things should HAVE an effective debugging technique.

      I am fine with replacing or greatly updating SysV. I simply don't see systemd as an improvement on the balance. Its wrongs outweigh its rights.

      As an aside, most competent admins wouldn't be "resorting" to the kludge you describe, and will probably just stare and you and blink rapidly when told doing so is supposed to be a good thing.

      I guess they think the answer is to stay down while they do a total re-install without understanding what was wrong then?

    28. Re:What? by Anonymous Coward · · Score: 0

      NSA approved funding for the inevitable backdoors or un-loggable root exploits? If its almost impossible to audit the huge mess it means the holes won't get found.

    29. Re:What? by jbolden · · Score: 1

      Well yes. The claim these guys keep throwing around is it is "desktop only". When in reality the most complex server installation are finding it solving their problems. They are just peddling a myth because the earliest success were for desktop.

    30. Re:What? by jbolden · · Score: 1

      Even if systemd is a clear upgrade over every single component it has its tentacles in (for the sake of argument), it isn't enough to justify refactoring a working infrastructure on a DevOps team that's already understaffed as it is.

      So don't use it. But that's very different than claiming it is only for desktop and not for server. Which both of you tried and which is provably false given that the most complex server installations are pushing systemd. Devops BTW being one of the its best use cases.

    31. Re:What? by Skylinux · · Score: 1

      "new stuff requires new debugging methods on failure, avoid new stuff."

      Not an issue with new stuff but I do have an issue with new features that makes things harder to use/debug.
      I don't care about this on my laptop but I will switch to a server focused distro when I rebuild my cluster in a year.

      This is why I really like Linux. Once you know Linux you can select a distribution based on features, not because it is hip.

      --
      Everyone who buys Wild Hunt will receive 16 specially prepared DLCs absolutely for free, regardless of platform.
    32. Re:What? by drinkypoo · · Score: 1

      On a desktop, systemd and firewalld make sense, [...] For a server, one wants reliability and security above all.

      Sigh. On my desktop, I want reliability and security above all. People who don't want that are part of the problem. I chose a server-class OS as a desktop OS specifically because that's what I wanted! Now a bunch of wankers who can't figure out shell scripting want to replace that simplicity and durability with something fragile and complicated, and then they want to claim that I am the one with the problem when I complain.

      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 is that really what you want for your desktop PC? Me, I want it to work, and I want that work to be secure. That's why I maintain a Linux system even though I spend a lot of time in Windows. I sure don't do my banking there, and I don't even trust it to boot when I need it. I've got too much experience with the opposite happening. I don't want Linux turned into Windows, or MacOS. We have Windows and MacOS for that. If my boot time has to be a couple of seconds slower (and that is what we're talking about here, folks) then so be it. It's a fair tradeoff for useful logging of the boot process.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    33. Re:What? by drinkypoo · · Score: 1

      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.

      Who has to imagine? You can experience this right now with MacOS, which also has a unified system-starting daemon. And if it shits itself, you have to take all the steps manually. In early OSX you had a handful of commands to issue to get the system to boot past single-user mode, now there's just one, and god help you.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    34. Re:What? by Anonymous Coward · · Score: 1

      With systemd you are really left alone in dark if the system refuses to boot. On my Debian jessie the machine just refused to boot one day. After 90s of delay, it said that it is unable to mount one partition and it jumped into emergency shell. Of course, manual "mount -a" did work on the shell, but my system was not suddenly systemd compatible. Luckily after a lot of googling I found out, that the systemd has started to require CONFIG_FHANDLE as a kernel config option. Of course, the change was introduced into my system via a random system update and the systemd was not interested in telling that the mount failed due to missing kernel configuration option. This issue is even acknowledged by the main systemd developer, but he could not care enough to fix it.

    35. Re:What? by Anonymous Coward · · Score: 0

      The thing about systemd is that it have the kind of circular contradictionary goal that always leeds to trouble.

      It's not necessarily the pid1 component that is the problem it's the non standard based integration of everything not classified as an application into one sytem that creates issues simply not handled in practice.

      And because systemd is someone else project where as init scripts belong to the application vendor, you get a ton of little conflicts where systemd will overwrite someones crafted script for instance setting the hostname on opensuse13 pr the manual will not work correctly with systemd enabled because systemd default to networkmanager and network manager when evoked from systemd ignores /etc/ entirely if networkmanager comes up toe soon etc. and there is a ton of little things like that happening all over the place. In short a lot of the little problem they were solving just got a little bit more complex to fix and troubleshoot.

      The only gain systemd offers is true parallelism which you do not want in a cluster environment where things have complex dependencies and often need to poll a monitoring service running somewhere else or secure a "locklun" before starting. Here having things happen in parallel can easily lead to a failure cascade where cyclic dependencies are never met because two services keep restarting waiting on each other etc. So you essentially need to turn of all of the systemd benefits and revert to a system looking a lot like a upstart or sysv init script.

      Journald is a similar issue on a desktop where the troubleshooter is sitting on the machine running journald querying some binary format is fine and you want a simple fast query api, but as nobody sane ever do any troubleshooting as root on a running production server, it's simply not going to be used like that on servers. And journald uses a binary format with no good protection against corruption doing journald crashes that we cant even read with standard tools(i dont even think it's correctly standardized and accessible from a perl/python module yet). SyslogNG have issues but integrating it with init and creating a non-ACID unstandardized binary format is not a real fix.

      This bundle of tools masquerading as a simple fix to a sysV system nobody even uses anymore is the real problem with systemd. As it takes alot of power away from a cluster integrator.

      On desktops all anyone ever cares about is to have autoconfiguring of drivers and auto discovery of network setting and that systemd does with fewer additional tools(as it is not just an init replacement but a kind of port of windows svchost to linux) but this is not a benefit where you have a competent system admin tuning the system.

      Mobile/embedded is irrelevant here as afaik they dont use any of the services systemd is bundling and probably wont be deploying systemd anyway. as things are customized anyway.

    36. Re:What? by visualight · · Score: 1

      The perspective that thought NetworkManager / Avahi should be a default 'on' in a server install is so completely fucked up that it shouldn't be trusted on any topic.

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    37. Re:What? by visualight · · Score: 1

      Bullshit.

      Everyone I know that is either (1)uninterested in the systemd debate, or (2) actually in favor of systemd is (3) a completely incompetent hack in most areas that (4) have mostly bad ideas generally.

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    38. Re:What? by The+Technomancer · · Score: 1

      If you think platform setups are the most complex server installations out there, I've got some oceanfront property in Denver I'd like to sell you.

      I still haven't seen anything that makes me want to use it on a server. There's a clear use case on desktop. Nothing you've posted changes that, or even bothers to make a case for it. It's all buzzword salad from you.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    39. Re:What? by jbolden · · Score: 1

      Google, IBM, Facebook, Netflix, Random House, GE... Those are complex server installations. Your side hasn't said much of anything. Mainframes, minis, bigbox Unix have had monolithic systems for decades. I'm presenting evidence you aren't presenting any well known vendor who disagrees.

    40. Re:What? by Anonymous Coward · · Score: 0

      +1, Systemd leads down a slippery slope, Desktop environments do have different needs, and my discussions with Debian developers seems that a fork is the only logical conclusion, and maybe it is time. Server edition does NOT ship with systemd by default, while the desktop edition does. This will also help to ensure that future developments are forced to be compatible with both methods.

    41. Re:What? by sjames · · Score: 1

      That is no surprise. The systemd project has repeatedly demonstrated that they have no discipline at all when dealing with dependencies.

    42. Re:What? by Aighearach · · Score: 1

      Bullshit.

      Everyone I know that is either (1)uninterested in the systemd debate, or (2) actually in favor of systemd is (3) a completely incompetent hack in most areas that (4) have mostly bad ideas generally.

      So rather than "Bullshit," your claim actually supports mine. The only ones who don't support it are the ones who don't care, or are idiots who already aren't listened to by their peers.

    43. Re:What? by hobarrera · · Score: 1

      But Linux is for desktops. For servers, you're always better off using BSD, which actually was born for servers.

    44. Re:What? by Anonymous Coward · · Score: 0

      Because systemd isn't simply some magical drop-in replacement for init. Even with the power that cgroups provides, it's still _cleaner_ to integrate the service using systemd APIs. And rather than tweaking OpenNTPd (OpenBSD's SNTP client), they decided to write everything from scratch--typical for the systemd project.

      Which is why I personally don't like the direction that systemd will be taking Linux. I highly value portability, particularly to the BSDs and OS X. But it's likely that in the near future the benchmark for a clean and well-behaved daemon in Linux will be how well it integrates with systemd, and specifically whether it uses the systemd C library for process lifetime management and run-time configuration events. (E.g. no more listening for SIGTERM or SIGHUP--even though with signalfd on Linux and kqueue on BSDs handling signals is now trivial and safe--but using a systemd library to tell you when to shutdown.)

    45. Re:What? by sjames · · Score: 1

      That doesn't sound like a very good reason. It also sounds like they have no idea what requirements users have for ntpd (many applications WILL not use a new ntpd at all until it has been exhaustively tested). And they wonder why so many object so strenuously.

      If they were at all cleaver, they would have systemd issue the needed SIGUSR/SIGHUP. After all, the old init scripts manage to do that.

    46. Re:What? by visualight · · Score: 1

      lol

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    47. Re:What? by The+Technomancer · · Score: 1

      You are so full of it.

      Facebook most definitely does not use a single distro in production that uses systemd.

      Neither does Netflix.

      You don't work out here. I do. It's not that big of an industry when it comes to systems administration and DevOps out here. Don't make claims that anyone with a LinkedIn worth a damn can debunk with a few messages.

      What's my side? Argue against what I've said, thanks. Where have I said anything about monolithic being a problem? I've been very clear about the gripes I have about it.

      You don't administer systems. You don't design the internals of system architecture. I can't even tell from your LinkedIn (we're third degree contacts) that you've touched a Linux system in your life. You've been management for over a decade. You seriously don't think the same infrastructure that some shops you namedrop are -the- solution for every use case, especially out here, do you? Especially when they don't even use what you're advocating for?

      You're not an engineer. You're an integrator. I'm sure you're great at it. But stick to your expertise and don't try to lecture engineers when you're out of your depth there. Thanks.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    48. Re:What? by The+Technomancer · · Score: 1

      I fail at reply.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    49. Re:What? by jbolden · · Score: 1

      Facebook most definitely does not use a single distro in production that uses systemd.

      Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.

      You don't work out here. I do. It's not that big of an industry when it comes to systems administration and DevOps out here.

      I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly

      Don't make claims that anyone with a LinkedIn worth a damn can debunk with a few messages.

      Maybe time to use your real name if you are going to play that game.

      I've been very clear about the gripes I have about it.

      No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.

      You don't administer systems. You don't design the internals of system architecture

      I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.

      I can't even tell from your LinkedIn (we're third degree contacts) that you've touched a Linux system in your life.

      I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the years. I'm certainly not a Linux specialist. I rely on Linux specialists.

      You've been management for over a decade.

      Yep. What do you think management does?

      You seriously don't think the same infrastructure that some shops you namedrop are -the- solution for every use case, especially out here, do you? Especially when they don't even use what you're advocating for?

      I don't use PaaS? Really? You tell me what am I using for the clients we are deploying too?

      I don't know about every client out there. I do know that the claim that you were making that systemd was for desktop and didn't have support for server is BS. I talk to far too many vendors who sell server solutions to believe that. I talk to far too many people system admin cloud or colos admins who see hundreds of clients to not know if systemd were causing problems to any significant fraction. I work with one of the research groups that publishes studies on this collecting the data.

      So sure you are an admin in the valley. So what? You aren't the only place doing DevOps, though you guys do invent many of the best ideas.. Its gone mainstream. And believe it or not, people on opposite coast do talk to one another.

    50. Re:What? by The+Technomancer · · Score: 1

      Facebook had been on a CentOS variant running on hardware certified by RedHat Labs for years. RHEL is systemd. Whether they have switched yet or not I don't know, but by 2018 or earlier they will be on systemd. If it isn't in production, it isn't in production yet.

      RHEL 6 (and its CentOS variants) are upstart, not systemd. Just admit you were wrong about them using it. You forget to mention that it's in testing alongside other, non-systemd Linux variants.

      Also, Facebook's been rolling its own hardware for quite a while now, dude.

      I don't work out there. Absolutely not. But PaaS is much bigger than the Valley. The ideas and technologies developed for DevOps are being deployed much more broadly

      The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.

      Maybe time to use your real name if you are going to play that game.

      Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.

      No you haven't. You've said that you have to change stuff you do for an existing infrastructure. That's about it. Lots of hyperbole and nonsense claims about desktop.

      Well, we've already established that you've been lax about doing your research before making claims.

      I don't administer systems. I most certainly do design the internals of system architectures. What do you think happens when you sell a solution that you put together random parts without thinking about how they work? I've done the specialist job when you knew every little detail of a system, and I went through large scale changes before as an engineer. I remember when I was an engineer people like you gripping about the change over from DECnet to IP and how the sky would fall. I was intimately involved in the migration of working systems from Metacode to Postscript and AFP. The systems are far better today for progress.

      From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.

      When was the last time you actually acted as an implementor on one of your plans?

      If you're one of the rare good ones out there, then please accept my most heartfelt apologies. But thus far, I don't see it. Your argument is "It must be fine because vendors use it and my consulting firm deploys it!" and that size of installation equals complexity of installation. You haven't provided a technical argument in favor of systemd on the server in the slightest.

      As far as progress is concerned, systems are better than before because of it. However, just because something is new and shiny doesn't mean it's progress. There was rapid adoption of Puppet and Chef because those tools massively increased productivity and added flexibility to cluster design. Docker has taken off because the cost in system performance is outweighed by the man-hours savings in testing on/for multiple platforms, and because they successfully implemented a Linux equivalent to Solaris zones and/or BSD jails.

      I have, Unix since 1988, Linux since 1995. I've also touched a wide range of the big box Unixes, zSeries, iSeries and VMS. Which gives some perspective on having seen styles of solutions for process management over the year

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    51. Re:What? by jbolden · · Score: 1

      RHEL 6 (and its CentOS variants) are upstart, not systemd.

      RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.

      Just admit you were wrong about them using it.

      I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.

      "on hardware certified by RedHat Labs "
      Also, Facebook's been rolling its own hardware for quite a while now, dude.

      I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.

      The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.

      Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating. You picked Facebook from my list:

      a) They run CentOS. Cent OS is switching
      b) They get their hardware certified by RedHat who is the single largest proponent of systemd.

      I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.

      Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.

      Fair enough. Change.org DevOps architect is legit experience.

      Well, we've already established that you've been lax about doing your research before making claims.

      I think that's unfair and untrue. We just disagree about what constitutes a reliable source. I'm mainly interested in vendors because they have breadth you are mainly interested in engineers because they see things up close. The way you are phrasing it is unnecessarily harsh.

      From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.

      That's not about systemd but just to defend our guys:

      a) I'd love to do accurate cost assessments where IT companies use a sane rate of interest and depreciate their IT infrastructure over 10-20 years. We aren't the ones who force companies to do ROI accounting as if their depreciation / cost of borrowing / interest rate were 400%. That's not the engineers either (they are mainly on our side about that one). Blame your finance guys not us. But ultimately if the customer is mainly focused on the 1 year or 3 year cost, then we build a solution to keep the 1 or 3 year cost low and often by letting it explode in the out years.

      b) In terms of staff churn often the point of an integrated solution is to prompt

    52. Re:What? by The+Technomancer · · Score: 1

      RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.

      If they stick with CentOS, sure. That's not a given at this point, and it's definitely not likely to happen until systemd is more ready for primetime. It's why I took issue with your 2018 time frame: systemd is going to be the way forward, whether people like it or not. The issue is that it's -not- ready for primetime, or to be the default init system for 95% of the market. Because of this, the OS upgrade road, which is always difficult to begin with, is going to be slower than usual, because no sane VP of Engineering or CIO is going to risk their ass on being the first one to do a wide deployment without a compelling reason to do so, and there's not a compelling reason to do so.

      I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.

      I'm pretty confident that the production engineers over there know what they're working with.

      I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.

      Fair enough, but the hardware certification is a marketing point Red Hat sells, not anything useful for day to day configs. Incompatible hardware very quickly becomes compatible when you have Facebook money to throw at the problem. I'll be happy to tell you stories of vendor chats I had when working at Apple, and how the threat of losing seven-and-eight figure contracts quickly turns unsupported use cases into supported use cases, including the backporting of kernel patches for a kernel that wasn't the vendor's preferred one.

      Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating.

      My explanation is why it's unsuitable for servers. Just because you can run servers with it doesn't mean it's anywhere near the best tool for the job, and it introduces more headaches than it solves. Can that change? Of course. Given that the vendors are shoving it down our throats and I'll probably have to upgrade to it within the next few years, I'm not just advocating against it for now, I'm doing what I can to make sure that it gets shored up.

      You picked Facebook from my list:

      a) They run CentOS. Cent OS is switching b) They get their hardware certified by RedHat who is the single largest proponent of systemd.

      I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.

      Hey, it'd be nice if I could do less infrastructure. But when we've tried to switch over to platforms, it hasn't gone well. Our Chef setup was handled by Opscode until it became unreliable and their suggestion was to run our own. We've tried a few vendors for platforms, and they can't handle our traffic patterns when a petition goes viral.

      I'm not comfortable going into more detail about our infrastructure on a public forum (unsurprisingly, we get targeted a lot by parties getting sunlight shone on them), but you're welcome to email me at jpierce at change dot org and I can go into the troubles we've had relating to vendors and external platforms.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

  22. re SystemD by Anonymous Coward · · Score: 0

    I have Centos 7 installed on a vm running SystemD. I personally do not like it. I don't see the benefits for a server.
    I do remote sysadmin and the existing sysv init works fine and is very straightforward.
    Come on Debian get off the bleeding edge bandwagon and stand up for stability and standards!

  23. good for the ecosystem? by noldrin · · Score: 1

    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?

  24. UNIX Philosophy by Art3x · · Score: 4, Interesting

    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.

    1. Re:UNIX Philosophy by armanox · · Score: 5, Informative

      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.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    2. Re:UNIX Philosophy by jedidiah · · Score: 1

      > 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.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    3. Re:UNIX Philosophy by kthreadd · · Score: 1

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

    4. Re:UNIX Philosophy by thegarbz · · Score: 1

      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.

    5. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      do these programs follow the do-one-thing-and-do-it-well principle:

      Apache: Does everything and does them decently, which is why some people who don't need "everything" choose nginx or lighttpd to get one thing done fairly well.

      PostgreSQL: does the database thing and does it pretty good.

      X: Does a ton of things and does some OK, some not. This is why some people are making Weyland, which does fewer things better, but is being resisted by people who wanted the other things X did.

      GIMP: Does one thing halfassed (CMYK, 16bit color precision when?)

      OpenOffice: I tried so hard, and got so far, but in the end Microsoft releases an incompatible version

    6. Re:UNIX Philosophy by profplump · · Score: 1

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

    7. Re:UNIX Philosophy by thegarbz · · Score: 1

      Ignore me. I wrote this before coffee.

    8. Re:UNIX Philosophy by phantomfive · · Score: 4, Interesting

      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.

      --
      "First they came for the slanderers and i said nothing."
    9. Re:UNIX Philosophy by devent · · Score: 1

      Linux have binary log files for years, and nobody complained about it.
      See /var/log/wtmp http://linux.die.net/man/5/wtm...
      And it wasn't "railroaded". Debian had a vote in the TC and Ubuntu choose to use systemd instead of their own. How is that in any way "railroaded"?

      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.

      Just like systemd service files?

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    10. Re:UNIX Philosophy by thegarbz · · Score: 2

      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 it does things well.

      The GP is correct. None of these programs follow the Unix Philosophy which is more targeted at tools like grep, sed, and awk.

    11. Re:UNIX Philosophy by Tenebrousedge · · Score: 1

      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.

      Apache is monolithic in the same way that systemd is. It does not do "one thing". Nginx exists because Apache does way too much. X.org is also absurdly complicated, but at least they stripped out the print server. Wayland is the attempt to make it more pared-down. An init system is either complicated or bad at what it does, or both. I would perhaps debate about including Postgres as a piece of monolithic software, perhaps in comparison to simple data stores, but it doesn't stray too far outside of the definition of "relational database".

      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.

      Your system is not well thought out and would not handle dependencies / parallel startup very well. However, generally speaking shell scripts should definitely be the exception: executable configuration files are a bad design. If you must use arbitrary scripts, then you should abstract the common elements and reduce the part that must be expressed as executable code to the bare minimum. Have sane defaults, and an easily-reviewed common subset of functionality, make the simple things easy, and stay out of the way of anyone who really really needs a programming language and shell in order to start a program.

      Maybe instead of systemd we could come up with a start-up standard, sort of like the POSIX standard.

      The important part of systemd is actually managing processes and services, startup is where most of that happens, but it's not the driving force of systemd. The reason why systemd exists, and the reason why it isn't portable, is because of cgroups, which are a feature specific to the Linux kernel allowing for real process management. In non-systemd Linux, daemons must carefully communicate through special files what they are doing, or the OS is not able to determine anything about the service. There is a complicated process which every process that wants to daemonize must follow, and the only thing that makes this remotely sane is longevity. Solaris and OSX have both separately replaced SysV init.

      I have read that FreeBSD has taken the strategy of using essentially a library of common things that init scripts might want to do, but for the general case having this library be written in an interpreted language gains little.

      --
      Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
    12. Re:UNIX Philosophy by fgodfrey · · Score: 2

      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.

      --
      Go Badgers! -- #include "std/disclaimer.h"
    13. Re:UNIX Philosophy by Peter+H.S. · · Score: 5, Insightful

      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.

    14. Re:UNIX Philosophy by Culture20 · · Score: 2

      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 by a number for the order they should be executed in, followed by the script name (for readability's sake; it doesn't need anything beyond the S/K##). When starting or ending a run-level (booting/shutting-down), init goes through the simlinks in order and runs the init scripts they point to with either "start" or "stop" as parameters. The scripts handle the peculiarities of the various daemons, and act as an easily configurable startup mechanism that allows the sysadmin to fine-tune things. For example, if a server's system clock fails, ntpd will refuse to update because the clock-skew is too great ("2014!? But it's currently 2002 according to the system clock."). So, a sysadmin can write a little hack for ntpdate at the beginning of the "start" function in ntpd's init script. Mind you, this is a poor example, but easier to explain than any I could come up with quickly.

      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.

      Editing init scripts is the exception, but because it happens enough times, the scripts should exist as a rule. Scripts allow for high-configurability while keeping some level of separation. The things ntpd does on startup could be parameters, and even the above ntpdate functionality (which is considered bad form in the ntp world: trusting the network time too greatly) could be compiled into the ntp daemon. But who wants to include every hack every sysadmin comes up with for their own environments in the main codebase for ntpd? And who amongst all the sysadmins wants to recompile ntpd for every change and essentially maintain their own fork? Not to mention the differences between distributions for configuration file locations, log files, etc. It's much easier to use scripts as that happy medium where sysadmins can edit without need for constant recompiles.

      Why not one big super-script then...

      Seems like configuration should be a single file that lists the programs to start from top to bottom

      ...this violates the separation principle. And would be slightly annoying too. It's easier to handle the individual scripts for their respective daemons than it is to isolate the section that is needed, and as pointed out before, a mere list of executable paths isn't enough, even with parameters; not configurable enough. Let's say you make a change on server 1's init script for ntpd. Now you want to copy that configuration to all 10,000 servers you have. Easy-peasy for a specialized init-script (assuming they're all the same distro and version): just copy the file to every machine and restart ntpd. But with a monolithic script, if you copy it to every machine, you'll be copying entries for daemons that the other servers might not have, or worse: removing entries for vital daemons on the target servers. Keeping them separate is best. Just as keeping them highly configurable is best.

    15. Re:UNIX Philosophy by sjames · · Score: 1

      SysV init (known as init for the rest of this post) is quite simple. It has just a few things that it is instructed to restart if it exit (the gettys for the system console and optionally serial console), and a display manager such as GDM. Then there's a line that makes it call rc.S with the runlevel whenever that changes. Beyond that, init just reaps any child processes that end up parented to it.

      rc.S is a script that just looks at /etc/tc?.d where ? is the selected runlevel and runs the scripts that start with S in the order natural order (fixed by adding two digits so that S80foo starts before S81bar. It passes 'start' as the parameter to the script.

      In addition, rc scripts starting with K are called with 'stop' as the parameter.

      Done.

      Should you want/need a parallel startup, modify rc.S (Debian Wheezy does that).

    16. Re:UNIX Philosophy by complete+loony · · Score: 1

      And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.

      The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    17. Re:UNIX Philosophy by phantomfive · · Score: 2

      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.

      --
      "First they came for the slanderers and i said nothing."
    18. Re:UNIX Philosophy by nabsltd · · Score: 1

      in fact, since systemd can log from before root-filesystem is even mounted, you get better logging.

      The current init system has always done this, buffering up log entries until the logfiles are available. How else do you think dmesg has entries from milliseconds after the kernel starts?

    19. Re:UNIX Philosophy by thaylin · · Score: 1

      Wait, we have been told all this time that it is a systemv replacement first and for most, now you are telling us something different? Now it is a supervisord replacement mostly?

      --
      When you cant win, ad hominem.
    20. Re:UNIX Philosophy by Art3x · · Score: 1

      Thank you! That was very helpful, especially why you might want a script for each daemon instead of a single config file.

    21. Re:UNIX Philosophy by suutar · · Score: 1

      Nobody said it was a small thing.

    22. Re:UNIX Philosophy by Art3x · · Score: 1

      And then there's the launchd / inetd way of launching services that systemd also copies. The service config file can list a set of sockets that the service binds in order to service requests. For example Apache binds to port 80 and 443. So long as all services (including mounting filesystems...) describe *all* of their external interfaces, dependencies no longer matter at all.

      The init system can bind all of the sockets that every service needs all at once, and either start the real service the first time the socket is used, or start them all at once. If one service connects to another, the first request will block until the other service is ready to handle it. Then all you have to worry about is the potential for deadlocking, which you'd have to consider anyway.

      Thank you for the explanation. That sounds much more elegant.

    23. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      Holy dogshit, that's some fantastic ignorance of what Apache does.

    24. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      It also doesn't work well.

      When something happens - it either hangs, or looses log messages and hangs...

      It can even make the log file unreadable.

    25. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      wtmp isn't the central log facility. It only records current users.

      And no - systemd service files are stupid. They barely do enough to start simple services. For anything more complex you STILL have to use a shell script to start them.

    26. Re:UNIX Philosophy by Barsteward · · Score: 1

      "mainly because of the binary log files" - i believe there is a config option to forward log message to rsyslog - here's a cut from an Arch discussion

      "This changelog says that:
      * journald will no longer forward all local data to another running syslog daemon. This change has been made because rsyslog (which appears to be the most commonly used syslog implementation these days) no longer makes use of this, and instead pulls the data out of the journal on its own. Since forwarding the messages to a non-existent syslog server is more expensive than we assumed we have now turned this off. If you run a syslog server that is not a recent rsyslog version, you have to turn this option on again (ForwardToSyslog= in journald.conf)."

      Does this help with your problem with the binary log issue?

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    27. Re:UNIX Philosophy by drinkypoo · · Score: 3, Insightful

      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?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    28. Re:UNIX Philosophy by Tenebrousedge · · Score: 1

      It's a matter of perspective. Being able to accurately track processes (via cgroups) is systemd's raison d'etre, and a natural part of this is to be able to start and stop services. In order to do that well, you're going to need to have some sort of idea about service dependencies and system resources. As long as you're going to do all the hard parts of init anyway, you may as well be an init system. Even so, it's not entirely necessary that systemd run as PID1, but it seems to have been coded that way. However, it's not the only service manager that does this: runit, daemontools, and the service managers for OSX and Solaris also handle init.

      The other thing that is enabled by accurate process management is tracking user sessions. It's not strictly part of the mission statement, but it's not too much of a stretch, and no other project (besides the moribund ConsoleKit) is providing it. That would be why the major Desktop Environments are dependent on systemd, not because they want to, but because there's no alternative. So, it's not going to be enough to mandate that Debian be init-neutral, someone needs to sit down and either fix ConsoleKit (which was abandoned for a reason), or write something equivalent. I believe Canonical has made some steps forward there.

      If you're going to argue against systemd, you should consider learning something about it. There is far more heat than light on the side of the detractors, and it does not help their cause.

      --
      Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
    29. Re:UNIX Philosophy by Peter+H.S. · · Score: 0

      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.

      As I said, Unix wasn't even born with piping, it was a later development. And of course, Unix wasn't born fully fledged with all features and made according to some pre-existing Unix philosophy. They were pioneers in much what they did after all.

      My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.

      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.

      Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.

      Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.

      Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping. It is a very Unix way of dealing with such "problems".
      Anyway, "grep" can learn to understand the journal file structure, so you can have a "jgrep" just like there is a "zipgrep" for dealing with zipped syslog files. I am sure that grep have been modified before to deal with new things like UTF-8 etc.

      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.

      Not having the right tools in the box is simply a shameful thing for a paid SysAdmin. How do you expect to read a LVM volume or a new filesystem by using random, perhaps outdated tools?
      It is such a basic requisite to have a working boot media. And yes, some old rescue discs doesn't support reading journal files yet, but it was the same situation with LVM and btrfs etc. If you didn't have an up to date boot media or similar, you couldn't mount or read the content of the LVM/btrfs disc.

      It is so trivial to read and analyze journal log files on other computers or through a boot media. Since the journal has both a stable API and language bindings, several non-systemd journal readers will pop up over time too.

    30. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      A lot of bullshit is being spewed and the systemd devs are not entirely consistant in how they describe systemd either which is a big part of the problem.

      At the low level all init is doing is issuing start, stop, reload and restart to some application. The shellscipts are simply stand in for those applications as they might need more complex parameters then a simple one word command(aplications does not need to be singular binaries).

      This is the basic and systemd does not as a pure init system fundamentally change that, but systemd is not a pure init system in it's real world implementation.

      Now the complexity is that an service might depend on an other service being started fist, this was partly controled by the placeholder shellscript and partly by having the init system do thinks in a certain order, for sysV this was purely linear causing a long startup as everything had to wait on the previus service dependency or not.
      With upstart a lot of that wait was reduced by simply telling upstart which services were depending on what though a set of conf files. This is the solution most anti systemd folks thinks can and should be tuned and not replaced.
      systemd wants to go to a binary conf database(and afaik not even using a standard format) and add as many dependencies as possible directly inside systemd as "special services" again with a binary conf and api. On some days they claim that because it's just special services it have nothing to do with systemd as init but nobody have actually seen systemd run with any alternative services without a lot of kludging around the default hooks.

      With both sysV, upstart and openRC you dont have the "special services" ie all services are "born equal", this causes a huge mess for some distributions as people opt to exercise their freedom and do weird thing, and screw up their conf files etc. and it is extremely confusing for wintel refugees used to the mmc console, regedit and srvhost.exe.

    31. Re:UNIX Philosophy by Peter+H.S. · · Score: 1

      That the kernel buffers some kernel log files during boot really is independent of what init system there is. But as you can see when studying dmesg output, it only have "internal" kernel messages. It really doesn't know anything of mount points etc., so that leaves a gap between the kernel dmesg output and when syslog finally is ready. systemd plug that gap by being able to log events while in initramfs.

    32. Re:UNIX Philosophy by Peter+H.S. · · Score: 1

      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?

      Good questions. The reasons are complicated, but I will try as best as I can.
      When journald was made it was constrained by several design parameters: it should have total backward compatibility for those needing this, it couldn't require that any userspace program should be rewritten in order to work with it, including syslog implementations like rsyslog. It should simply be a drop in replacement, giving people the opportunity to use its enhanced features if they wanted to, or just use the usual rsyslog setup they always had used. It should also be as simple and fast as possible. In fact, the journal more or less an append text file with other newline delimiters and an added index.

      And because journald worked with syslog, people could use rsyslog for all their advanced database logging needs. In short, journald makes it flexible for those who have advanced needs, instead of tying them down to a particular solution. Unlike rsyslog, journald isn't a log sink (and hopefully never will be).

      All in all, making sweeping and complex changes like using a real RDBMS as a logging back end wasn't an option. Also, such RDBMS solutions already exist in a mature state in e.g. rsyslog, so there was no need either.

      There are other design constrains concerning logging on Linux. At the moment everything goes into /dev/log, and only one program can read it a time. AFAIK, you have to rework both the way the kernel does logging and user space loggers in order to have more than one program reading log info from the source. The solution seems to requires using kernel namespaces and other low level systems, and are likely to require that both kernel version and user space loggers are synced to a certain version in order to work.
      So AFAIK, it isn't easy to make a early-boot-log helper that hands over logging to syslog when it is done, at least not in a lossless way and certainly not if the helper logs are meant to be incorporated into the syslog flat text files (which is why eg. dmesg is a separate log file).

      As for logging being "married" to init, the main argument was, that in order to have first class service and process management, you need a matching first class logging system. In order to have early and late boot log messages, the init system have to be aware of a lot of low level system stuff, and cooperate extensively with the logging system. They could have used rsyslog and changed it so it worked like the journald works, but that would have tied all systemd Linux distros to a particular syslog implementation.

      Having them working together also makes it trivial to attach log messages to a service check.

      Are binary log files a necessity of the systemd design? Absolute not. But then again, people who prefer flat text files for logs can just use rsyslog/syslog-ng as they always have. The binary log files are optional. But the binary, structured and indexed journal log do solve so many limitations of flat text files that I am glad it exist as an option. The systemd journal really is a joy to use.

    33. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      But with a monolithic script, if you copy it to every machine, you'll be copying entries for daemons that the other servers might not have, or worse: removing entries for vital daemons on the target servers.

      That is silly, as if that was the only solution. You could also specify what servers specific services run on (or not) in the configuration file format. Or put the whole thing in LDAP/DNS/NIS/whatever. Or serve it up from DHCP or over TFTP or whatever.

      Diskless systems (or at least root FS is read-only and networked mount in some manner) are VERY nice when you have
      LOTS of servers or the luxury of controlling all the machines on your network. One place to configure things. One place to set permissions. One set of users and groups, etc. The downside is "one place to screw things up" but you can mitigate that somewhat by abstracting a bit, and having a "preprocess step" that "outputs" a root FS for a specific machine. Then, you still have it all living in a single place, but if you screw up, you just rebuild that one machine from the "master" working configuration.

      Similar to VMs somewhat. Some OSes (e.g. BSDs) this is quite simple to setup since compiling the whole system is just a "make world" away, you can track different releases/branches/architectures if need be, but have the "root FS" for all your machines live on a single server/servers.

      For clients, all the OS data is read-only (perhaps a memory filesystem union-mounted on top of e.g. /etc if something for some reason requires a writable /etc) ... and when the machine is rebooted, any changes that were not planned disappear.

      Now, making such a setup redundant and sufficiently secured is another story, but it is MUCH nicer having a single place to configure things that servers have in common IMO.

      Nowadays,, many people like "puppet" and "chef" and similar, but with networked filesystems and a sane OS *** I think they
      are vastly overrated. Not that they are not useful, just I don't see why they should be the first or only choice for managing
      systems.

      *** not all distros really accomodate such things. /home on NFS at least is fairly common/supported (or apps are none-the-wiser). Some apps break too if you have heterogenerous machines e.g. app "foo" might make ~/.foo and store binary data in there, but when you run "foo" on another architecture it might not notice that existing data is for a different architecture. IMO /home at least ideally should be consistent across all your machines, and apps that e.g. write binary data should attempt to do so in a portable manner, but that is not reality. Why *should* you have to have a separate home directory for each different type of machine you login to?

      One reason NOT to do such a setup is network performance might kill things, if your servers are not all in the same location, etc.

      I just don't think "but then you have to copy the config. file all over" is really a big deal -- there are LOTS of ways around that.

      There may be criticisms of a giant "list all services in a single file" init system, but I don't think that is a valid criticism.

    34. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      It was railroaded. The TC doesn't even have the authority to make architectural change decisions: only to decide bug conflicts.

    35. Re:UNIX Philosophy by Anonymous Coward · · Score: 0

      The log corruption happens by design of systemd, so you should not complain for that. Ref: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64116

    36. Re:UNIX Philosophy by drinkypoo · · Score: 1

      My point was simply to stress, that what the early Unix developers did was a reflection of the challenges they faced at the time, and that the lessons they learned reflects that. There are no dogmatic and universal Unix rules with a permanent truth value forever and in all ways of doing computing.

      Nobody said there were, but you were completely misguided. Piping is a key feature of Unix, and nobody would suggest removing it today. The key principles of Unix are not "to be obeyed" simply because they are rules that you are meant to follow. They are principles that emerged from development (like piping) which became a "way" that people follow because they make sense.

      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.

      Of course not. Just because a daemon died before finishing its log entry doesn't mean the log file can't be read. journalctl is quite good at dealing with such corruptions.

      If moving the goalposts is the best that you can accomplish, then surely we cannot progress this conversation past this point. There are many things which can happen to a log file besides truncation.

      Also, binary logs are just plain wrongheaded, period, end of story, if they are not in a format which common tools can already read.

      Not a problem; all the standard Linux text tools like "grep" and "tee" work great together with journalctl through the basic concept of piping.

      They don't work without journalctl. And this is relevant because text logging (which does work without journalctl) is a second-class citizen to the binary logging. This is the part of the binary logging which is completely unacceptable. If only one of the logs is going to be accurate, it must be the log which I can read without special tools. Indeed, with a filesystem debugger or even a filesystem editor, if necessary.

      It is a very Unix way of dealing with such "problems".

      False. You only say that because you do not understand the Unix Way, which includes preference for flat and human-readable files. You are praising one particular tree while cutting down the forest.

      Not having the right tools in the box is simply a shameful thing for a paid SysAdmin.

      In the real world, where things sometimes do not go according to plan, it does not make sense to tie myself to proprietary tools. This point has been proven time and again, again, in the real world. Your coulda woulda shoulda nonsense is just that; journald coulda woulda shoulda made text logging as important as binary logging, and then the chief objection to it would not even exist. But arrogance has led its development otherwise. Presumably this will be fixed and eventually, with some snarky bullshit comments about how it's for the fogeys thrown in as a means of avoiding any personal responsibility for the bad decision in the first place.

      It is so trivial to read and analyze journal log files on other computers or through a boot media.

      I find your lack of imagination typical, but disturbing. It is, of course, the mindset which led to systemd, so I am anything but surprised to see it here.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  25. Re:And this is why Linux will never win the deskto by sjames · · Score: 3, Interesting

    When my mom needed something for email and web I gave her a machine I had with Linux on it. It has worked just fine even though she had very little experience using a computer.

  26. Re:And this is why Linux will never win the deskto by 0123456 · · Score: 4, Insightful

    I am an experienced Linux user, and I have tried several times to install Windows. Each time I look on a retail site, I see aabout a dozen different versions of Windows for sale, and I find endless discussion about which version I should install and UI changes that developers should not include in the releases, and how I should download some third-party apps to make the UI not suck.

    It always ends the same, with me putting my credit card away... be thankful Linux works well.

  27. Re:And this is why Linux will never win the deskto by jedidiah · · Score: 4, Insightful

    Are you kidding. Linux doesn't even need to be installed. You can just run it straight from the install media.

    This is handy when you have a Windows install that can't even run it's own wired network interface and it can't tell you what driver it needs because it's too dumb to do that.

    Linux liveCD to the rescue!

    Boot up.
    Interrogate hardware.
    Proceed with beating the bushes to find Windows drivers.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  28. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Good. I don't want Linux to sell out and win the desktop. I just want it to remain an operating system for intelligent people, as it is now (at least with KDE. Gnome and Unity are almost as dumb as their commercial counterparts).

  29. Too late by Anonymous Coward · · Score: 1

    That horse has left the barn. Aside from Gentoo and Slackware, systemd is the new Linux init system. Between Redhat/Centos and Debian/Ubuntu et al. you have 95% of the Linux market, and they've all committed to it.

    The main technical argument against systemd seems to be that it fails to adhere to Unix "philosophy" of composing small, focused tools. While true, I'm not sure it matters. Systemd is deployed in real systems and these aren't crashing or suffering chronic problems. "But I need shell scripts to do what I need." Systemd isn't incompatible with shell scripts.

    The main political argument against systemd is that the people behind it are difficult to work with and unresponsive to the problems they create. That seems to be true, but ultimately it won't matter; forks have sent assholes to pasture in the past (I'm thinking of XFree86, gcc before egcs, cdrecord and others,) and if the systemd people continue to offend they too will be shed.

    The big Linux vendors/distros have nothing to gain by backing up on systemd now and a great deal to lose in terms of customer frustration. The only way I see systemd being overcome is if some marvelous new system appears that a.) solves all the problems systemd solves b.) does so in neck-beard approved ways and c.) is written by someone that doesn't have an army of haters.

    Good luck with that.

    1. Re:Too late by jedidiah · · Score: 1, Informative

      > Systemd is deployed in real systems and these aren't crashing or suffering chronic problems.

      Some people seem to be reporting this very thing. The cult of mindless progress just seems intent on ignoring everyone that isn't drinking the Kool-Aid.

      --
      A Pirate and a Puritan look the same on a balance sheet.
    2. Re: Too late by Anonymous Coward · · Score: 0

      If their systems are working fine (like mine is) and you can't adequately explain the nature of the problem...maybe you're the one with the comprehension issues.

    3. Re: Too late by thaylin · · Score: 1

      Except they are not working fine, and some are even explained very thoroughly in these posts, above and before your post, leading me to the conclusion that you ARE just ignoring everyone who isnt drinking the kool-aid.

      --
      When you cant win, ad hominem.
    4. Re:Too late by Barsteward · · Score: 1

      not sure about that. most of the crap seems to be due with political issues with the developers. anyway most software has bugs at some point or another, its a fact of software life.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
  30. Re:And this is why Linux will never win the deskto by 0123456 · · Score: 4, Funny

    There's Window 8, and Window 8.1. There's 32-bit or 64-bit. There's Windows 7. There's about half a dozen different versions of Windows 7, and I've no idea how many of Window 8.

    There's the XP interface. There's the Windows 7 interface. There's the Window 8 desktop interface. There's the Window 8.1 desktop interface. There's the Metro interface.

    How can anyone expect someone to pick Windows for their desktop when there's so much fragmentation?

  31. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Version 8.1, the only one you're going to find at the store or on any new pre-built computer (unless you special order it with Win7). Apple is a no-brainier too. Buy an Apple computer, get the current version of the OS. Easy peasy. The only thing even remotely confusing is that Windows 8.1 (if you buy it standalone) comes with both 32-bit and 64-bit installation discs.

    And whichever you choose (Windows or Apple), you can be almost 100% sure that all your old Windows and Apple software will work just fine in the new version.

    Now, compare that to the poor non-techie bastard who has to choose a distro, when he's not even sure exactly what Linux is. He has to do a ton of research to even get started. And he finally settles on a distro, only to find out that the Steam game that he wants only works with Ubuntu. So he says, "Okay, I guess I'm going to have to start over and install Ubuntu." But even then, he has to decide WHICH Ubuntu. Which desktop? Does he want to go Unity? Gnome? KDE? And WTF is a gnome?!?!? And WTF is the difference??? And, and.....fuck it, I'm going back to Windows.

  32. In Soviet Russia .... by PPH · · Score: 5, Funny

    ... systemd forks you!

    Come to think of it ....

    --
    Have gnu, will travel.
    1. Re:In Soviet Russia .... by carnivore302 · · Score: 1

      Imagine a beowulf cluster with systemd!

      --
      Please login to access my lawn
  33. Re:And this is why Linux will never win the deskto by NotDrWho · · Score: 1

    Linux works out of the box in the same way that MacOS or Windows does.

    Which distro and desktop?

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
  34. What exactly are they proposing? by Anonymous Coward · · Score: 0

    On a bad internet connection here, so can't do the homework.

    They want to put yet another boot system to work?
    Why can't they just remove the fucking abortion systemd is and fork it like it never existed?

  35. Never bring a fork to a gun fight by BenSchuarmer · · Score: 1

    unless you're not participating and you're a canabal

  36. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I would gladly hand over my credit card to buy WIndows any day than deal with pages and pages and pages of silly technical text.

  37. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 1

    When I walk into Best Buy, I only see Windows 8.1 on the shelf. Where are you shopping where they have a dozen different versions for sale? Even Amazon doesn't have that many versions of Windows for sale (unless you count OEM versions).

  38. The 70s called - it wants it "do one thing" back by Anonymous Coward · · Score: 0

    Something about, you got too much memory to know what to do with. Hardy-har-har-har!

  39. Re:And this is why Linux will never win the deskto by myrdos2 · · Score: 5, Funny

    My Linus just worked right out of the box. You have to get past the F--- You! if you have NVidia graphics, and the prickly user interface that periodically tells you you're a moron.

    At least it's better than my Stallman. That thing ate something off the bottom of it's foot while I was giving a presentation. Yechh.

  40. Re:And this is why Linux will never win the deskto by znrt · · Score: 0

    Choose your OS, average user:

    1) Windows
    2) Apple
    3) From hundreds of confusing distros and rage-forks of distros of "Linux"

    good for me that i don't give a shit about what OS the average user chooses.

    the average consumer eats processed shit, wears slave produced shit, regularly buys useless crap, uses closed software from locked gardens, gives away his privacy with a smile, votes every 4 years to maintain a soft fascist status quo, swallows shitloads of propaganda daily and in general has no fucking idea about how the world he lives in works. nor does he give a shit.

    feel identified? ok, you might as well use Microsoft Apple (c) products, let's not make a drama out of this. move on.

  41. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    OSX hasn't changed it's hardware compatibility since Mountain Lion. iOS is a bit more restrictive - but then again, we're talking about desktop environments, whereas iOS is designed mainly for consumption anyway and thus outside the scope of the argument.

  42. Concerns about systemd by Anonymous Coward · · Score: 1

    While many good issues have been brought against systemd, I am surprised that the two most important ones (for me) never made it to these lists:

    1. Without checking the code there is no way to figure out the startup sequence of services. I don't understand which f***ed up idiot came up with "Require" and "After" concepts. It should have been just a simple directed acyclic graph, with topologically sorted services starting.

    2. The idea of generators is beyond idiotic. Letting obscure binary file parse my fstab to generate another config file to be run later?! Seriously?

    (I mean this fails even in my (very simplistic) config on home router.)

    Source: I am a faculty in EECS@MIT.

    1. Re:Concerns about systemd by Anonymous Coward · · Score: 0

      That's exactly my problem with systemd design: over-engineering for rare edge cases all over the place.

    2. Re:Concerns about systemd by Anonymous Coward · · Score: 0

      This! It is Lennart being unequal to the tasks he takes on and RedHat being dumb enough to give him direct upload rights. If DJB or somebody with undisputed skills had dropped a new shiny init system that didn't have obvious lossage in every dark corner I seriously doubt there would be 10% of the yelling.

    3. Re:Concerns about systemd by Electricity+Likes+Me · · Score: 1

      What people call "rare" edge cases in it's detractors seems to include, amongst other things, hot pluggable storage, localization, power management, service monitoring, cgroup isolation, network connectivity for enterprise configuration...

    4. Re:Concerns about systemd by Anonymous Coward · · Score: 0

      I like cgroups and maybe even service monitoring. But how is any of this a domain of *init* system?
        hot pluggable storage, localization, power management, network connectivity for enterprise configuration.

    5. Re:Concerns about systemd by Electricity+Likes+Me · · Score: 1

      Storage needs to be detected on boot before the init system can do anything with it. That's going to effect when you can bring up other daemons, including network ones. Which in turn may require bringing up network connectivity so you can mount network filesystems that you may be booting from in the first place.

      All of which needs to be done in accordance with the idea that we might not be booting, but instead coming out of hibernation or sleep mode, and we need to check that the world wasn't exploded around us while we were doing that (i.e. the network is still there, is still the same network, and the storage is still reachable or hasn't been hot plugged).

      If you don't think cgroups are the responsibility of the init system though I don't even know what to say to that. That the process which launches all other processes shouldn't be able to request they be isolated, and monitor them to check they're still running?

      Frankly, I don't know why people think these things aren't the domain of the init system. They are all absolutely fundamental activities of a modern computer system, which need to functional at the various levels of boot time when nothing else may be running.

  43. A rather empty threat by Peter+H.S. · · Score: 4, Informative

    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.

    1. Re:A rather empty threat by phantomfive · · Score: 2

      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.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:A rather empty threat by IamTheRealMike · · Score: 1

      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.

      It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.

      The "UNIX philosophy" is an empty slogan that switches people's brains off. It sounds great, until you try and build a real system with the features modern users demand, and then it turns in to an exploding nightmare of combinatorial complexity as every program tries to abstract itself from every other program in the name of political correctness. As already noted elsewhere, the programs people use serverside Linux to actually run barely resemble the UNIX command line tools and that's for good reasons ...

    3. Re:A rather empty threat by Peter+H.S. · · Score: 1, Insightful

      It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against. So this kind of thing is not surprising to hear.

      Yes, they are split among those who think SysVinit should be used the next 40 years too, and those who recognize something else is needed for modern computing needs. Even the latter group is sub-divided into factions about one should make an improved systemd clone for compatibility reasons, or use OpenRC for BSD reasons, or making something new etc.

      So instead of focusing on making a developer community to counter systemd with new code, they focused on a negative campaign against systemd instead. It is so much easier to rant on the net than organizing and making stuff happening. But that negative strategy is also the single most important reason why systemd-opponents have been routed whole-sale from every major distro; they attacked open source developers and projects, while failing to provide an alternative.

      Agree about the Unix thing. "Unix philosophy" It has become a cartoonish mockery of all the great things the Unix developers did back in 60's and 70's. Totally without content and with no connection to reality.

    4. Re:A rather empty threat by Anonymous Coward · · Score: 0

      Everyone brings up SysV init. Noone brings up OpenRC. SysV init is old and busted; it should only be used in very small systems. There are other alternatives!

    5. Re:A rather empty threat by Peter+H.S. · · Score: 1

      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.

      You seem to misunderstand the sorry state of SysVinit; all the bugfixes are upstreams in SUSE/RH packages, not in any official release of GNU SysVinit. The SysVinit developers doesn't even have a proper test framework, so the only way to test a patch is by installing it and reboot, hoping the system will come up.

      When SUSE/RH drops their engagement in SysVinit, it will decay even more.

      Not having a official release of SysVinit for so many years, or even a "beta/developer" release, isn't a sign of maturity, but lack of developers.

    6. Re:A rather empty threat by phantomfive · · Score: 1

      Yes, bugs are a problem, but that's not what you said. You said it is bad because they haven't had a release in five years.

      That shows a huge problem in your understanding of system design, which you should fix now or continue making poor systems. Stability in a core system component is a good thing, not a bad thing. Don't forget it and your code will be better.

      --
      "First they came for the slanderers and i said nothing."
    7. Re:A rather empty threat by Anonymous Coward · · Score: 0

      > It sounds a lot like the non-systemd camp have no idea what they are actually for, they only know what they are against.

      They are for the status quo.

    8. Re:A rather empty threat by Peter+H.S. · · Score: 1

      Yes, bugs are a problem, but that's not what you said. You said it is bad because they haven't had a release in five years.

      That shows a huge problem in your understanding of system design, which you should fix now or continue making poor systems. Stability in a core system component is a good thing, not a bad thing. Don't forget it and your code will be better.

      Yeah, it is bad that there are outstanding bugs and they aren't being fixed. That is the case with SysVinit. These days SysVinit bugs are being fixed in distro repos, meaning that every sysvinit distro potentially got different releases, and the bug fixes aren't being mainlined with the GNU SysVinit. Not having a release in so many years is a sign of trouble, not stability.

    9. Re:A rather empty threat by sjames · · Score: 1

      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.

      So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?

      Why in the world would Xorg need systemd? It doesn't need it now.

    10. Re:A rather empty threat by Anonymous Coward · · Score: 0

      Of course we think UNIX should continue to evolve. But we think it should improve. Taking ideas from OSX and Windows is not making things better. If you want a polestar to navigate by, look at Plan 9.

    11. Re:A rather empty threat by Peter+H.S. · · Score: 2

      So it hasn't actually needed a change in years (meaning it is fully matured) but you're worried that there isn't enough manpower to churn the code (that needs no churning)?!?

      I am not worried since I use systemd and will never run a SysVinit distro again in my life. My point was that those who doesn't want to run systemd need to realize that a lot of work is needed in the future, and that the non-systemd camp is entirely responsible for making and maintaining the necessary code in order to e.g. run SysVinit in the future.

      Trying to making a virtue out the fact that SysVinit is understaffed (and this is going to get worse when the paid developers from SUSE/RH stops making bugfixes that other distros can leach), seems to be a common reaction among non-systemd users.

      There seems to be a lot of reality denying going on among non-systemd users; denial that work is needed to even maintain status quo, that only they are responsible for making it so, and that sitting under the palms waiting for a magical appearance of a non-systemd alternative simply will disappoint.

      The failure to realize these future challenges and the lack of coordination and development to face such challenges, will simply doom all general purpose non-systemd distros in the future.

      Why in the world would Xorg need systemd? It doesn't need it now.

      In order to run X.org without root rights in a safe manner on Linux, you need something to deal with user sessions. Only systemd provides that. Here is a fosdem talk about it:
      https://archive.fosdem.org/201...

    12. Re:A rather empty threat by sjames · · Score: 1

      The way you talk, it seems you are not only pleased to have systemd but deliriously happy that the people who don't want it may get stuck with it. Who pissed in your corn flakes?

      As for the rest, TFA suggests that people are preparing to do the needed thing.

    13. Re:A rather empty threat by Peter+H.S. · · Score: 1

      Of course we think UNIX should continue to evolve. But we think it should improve. Taking ideas from OSX and Windows is not making things better. If you want a polestar to navigate by, look at Plan 9.

      A dead OS that haven't had a release in over a decade can hardly be a "polestar" for future Linux development.

      I prefer "Linux philosophy" over "Unix philosophy" any day, because Linus Torvalds opinions are, that Linux is all about solving real world problems in the best manner possible, not adhering to any current fashion-of-today among OS designers. This is why he choose a monolithic kernel design, even though micro kernels where all the rage and the "right thing to do" at the time.
      Plan 9 is probably a beautiful implementation of "everything is a file", is just happened to forget its users in the pursuit of that inflexible dogma, so it withered and died.
      The same will happen to every OS that stand still and refuses to develop to solve contemporary problems.

      These days certified Unix's are practically dead except Oracle Solaris and Mac OSX, and they both have an init system that resembles systemd. No wonder since the systemd developers studied launchd and SMF extensively before making systemd. taking what they liked, and dropping other things like XML config files.

      systemd is simply an improvement overall in all areas in it deals with, compared to the old style legacy init systems with their executable config files.

    14. Re:A rather empty threat by thaylin · · Score: 1

      No, we are for actual separation of duties. We dont like the system where nothing is interdependent, and we dont want a windows clone.

      --
      When you cant win, ad hominem.
    15. Re:A rather empty threat by thaylin · · Score: 1

      You are only fooling yourself. Apparently you are a desktop person who is not willing to put in the work yourself, but for the server systemd is no where near needed for anything. It is a nightmarish system that is going to cause a lot of head aches when you want to do virtually anything advanced, IE outside of what the developers planned for.

      --
      When you cant win, ad hominem.
    16. Re:A rather empty threat by Electricity+Likes+Me · · Score: 1

      Such as?

      Seriously, people keep saying this and I am genuinely curious what these needs are, and how they're presently met with init scripts.

      Because "advanced" uses server side tend to be "monitoring and surveillance" - two things systemd is actually really good at. Binary logs? Literally no one cares, because your logging is going over the network and into a database of some type anyway and sending a few bytes less is actually kind of a big deal.

    17. Re:A rather empty threat by Rakarra · · Score: 1

      Such as?

      Dude, it's going to suuuuck. It's going to SUUUUUCCCKK!!

      Haven't you been listening? It's going to SUUUUUCCCKKK!!!!

      If you need more convincing, look at point 1 and 2 above.

    18. Re:A rather empty threat by Anonymous Coward · · Score: 0

      Son, I am disappoint.

    19. Re:A rather empty threat by Barsteward · · Score: 1

      No one group has a monopoly on good/great ideas. Same goes for political parties

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    20. Re:A rather empty threat by Anonymous Coward · · Score: 0

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

      I'm still trying to figure out this mentality... sounds a lot like the "gotta have the latest iPhone!" mentality...

      I bought a chainsaw 20 years ago, it still works fine (other than the chain needs sharpening after lots of cutting to get wood for the winter) - I don't need a "new version" every few years because it just works - as did SysVinit. If something isn't broken (or some serious security hole found), why would you need a "new release"?

    21. Re:A rather empty threat by Barsteward · · Score: 1

      Status quo is not always a good place to be, if it was there would be no progress

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    22. Re:A rather empty threat by Barsteward · · Score: 1

      that means, as explained previously, that all bugs in SysVinit components are fixed in different distributions so there is no longer one definitive SysVinit version. I can't see that as being a good idea or acceptable.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    23. Re:A rather empty threat by sjames · · Score: 1

      Or that there are no known bugs to fix and haven't been in ages.

      That's what happens when you follow the KISS principle.

    24. Re:A rather empty threat by Barsteward · · Score: 1

      "Or that there are no known bugs to fix and haven't been in ages" - is that a hope? try google "bugs in sysvinit"

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    25. Re:A rather empty threat by drinkypoo · · Score: 1

      and the bug fixes aren't being mainlined with the GNU SysVinit

      So much for GNU/Linux.

      However, this still isn't a reason to force systemd, since we have around a dozen init systems out there, most of which are directly compatible with sysvinit.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    26. Re:A rather empty threat by Peter+H.S. · · Score: 1

      So much for GNU/Linux.

      However, this still isn't a reason to force systemd, since we have around a dozen init systems out there, most of which are directly compatible with sysvinit.

      Nobody is forcing systemd on anybody. That all the major distros have chosen systemd, is because it is so technical superior in every way to any alternative out there, and because it makes life easier for distro maintainers and developers, and actually help upstream projects by providing them with needed features and some sort of cross distro compatibility layer.

      As you say there are lots of other init systems out there. However, in order to be a viable alternative to systemd, the non-systemd camp have to take control and start developing _all_ the necessary infrastructure code necessary, like ConsoleKit, cgroups, kdbus, udev, etc.

    27. Re:A rather empty threat by Peter+H.S. · · Score: 0

      You got to be joking, systemd is much more flexible than anything else on non-systemd distros. And it is trivial to extend for third party developers since it has lots of libraries, stable API's and language bindings, something no other alternative have.

      If you really think systemd isn't needed for servers, you simply haven't done a serious study of it. I have no problem with people not wanting to use systemd, but please don't reject it out of ignorance.

      Yes, a lot of SA's have to relearn a lot of things, including how do debug problems, boot sequences, how to use cgroups and use the systemd kernel security features etc. Experience helps, but is no substitute for learning. These things happens once in a while in tech.

    28. Re:A rather empty threat by thaylin · · Score: 1

      You have the inability to scroll up and see, I dont know, threads like http://linux.slashdot.org/comm...?

      --
      When you cant win, ad hominem.
    29. Re:A rather empty threat by thaylin · · Score: 1

      Please tell me why it is needed for servers. What does it replace that was broken in servers? It has nothing to do with relearning things, it has to do with a solution looking for a break, when there is not one. And you are still ignoring the blatant examples of it NOT WORKING

      --
      When you cant win, ad hominem.
    30. Re:A rather empty threat by Peter+H.S. · · Score: 1

      Anybody who has a free choice in which distro to run can always choose e.g. Slackware. Nobody is stuck with systemd on their home server against their will.

      I really like systemd, but I applaud any serious attempt to make a distro with alternative ways of doing things. Competition is good.

      As argued, I think there is a pressing need for the non-systemd camp that they make a long term distro a focal point for the needed development of non-systemd infrastructure (cgroups, udev, ConsoleKit, etc). It will be much better for the non-systemd camp to fork Debian, than to continue with it since it will become a full systemd distro in the end.

      As it is now, the non-systemd camp is entirely scattered and un-organised. It is every distro for it self. Cooperation and making a developer community is crucial if non-systemd distro are going to survive this decade.

    31. Re:A rather empty threat by Peter+H.S. · · Score: 0

      Please tell me why it is needed for servers. What does it replace that was broken in servers? It has nothing to do with relearning things, it has to do with a solution looking for a break, when there is not one. And you are still ignoring the blatant examples of it NOT WORKING

      It has a total process and service supervision chain, including systemd as PID1. It simply does everything better that SysVinit does, including when all the hack tools are bolted on. It can also deal with OS containers, which will becomes just as important as VM's are now. It exposes powerful kernel features like cgroups, kernel capabilities and namespaces in an easy to use fashion, providing strong security and useful features out of the box. Want to limit a service to only 50% CPU resources on a certain CPU? Just add a simple keyword to structured text config file and restart the service. Since systemd have total supervision of all processes, it will track all the sub-processes that the service spawns too, and place them under the 50% limit.

      I could go on, but it really seems to me that you haven't done a serious study of systemd with an open mind. Considering that all the commercial distros are switching to systemd, it is a worthwhile thing to do for anybody with professional interest in Linux.

    32. Re:A rather empty threat by Peter+H.S. · · Score: 1

      Or that there are no known bugs to fix and haven't been in ages.

      That's what happens when you follow the KISS principle.

      Just look at the Debian SysVinit bug tracker. Of course there are bugs. I don't claim that there are serious showstopper bugs, but they are there, and sometimes they are even fixed. Feeding such bug fixes back to the upstream project is normal Linux practice, but for the last several years, such bugfixes haven't been mainlined with upstream SysVinit, making SUSE/RH the de facto Upstream now, and both those distros are about to outphase SysVinit.

      I don't say that eg. GNU/SysVinit is understaffed is a unsolvable problem. But what I do say is, that those who will continue to use SysVinit have the responsibility to make and maintain all the necessary code themselves for being able to do so, including helping out SysVinit.

      The non-systemd camp can no longer rely on paid developers from commercial distros solving all their problems. There is a long list of stuff that needs to be done, right now and in the near future in order to run a SysVinit distro without it degrading slowly and falling hopelessly behind in features.

    33. Re:A rather empty threat by sjames · · Score: 1

      You seem a bit confused. Those bugs are not something upstream can or should be looking in to. That would be like blaming the bash team for a bug in your script. Naturally each distro has their own different sysVinit package, each wants to boot a little differently.

      As for the rest, Gentoo and Slackware are existing systemd-less distros. Currently, Jessie has it as optional, so creating a fork would be a matter or removing a few packages from the repo. If the GR doesn't pass, it might not stay that way, but that isn't a problem for the next 3 years.

    34. Re:A rather empty threat by sjames · · Score: 1

      Don't confuse bugs in an individual distro's scripts for bugs in the underlying init maintained upstream.

    35. Re:A rather empty threat by Peter+H.S. · · Score: 1

      I am not talking about bugs in SysVinit scripts used by daemons, but bugs in SysVinit itself. As you can see both Debian, RHEL, SUSE etc. all carry bug patches against the 2.88 release of SysVinit, none of them have made it back to upstream SysVinit. Notice how all development on SysVinit and releases stopped when upstream distros like SUSE, Ubuntu and Red Hat changed their init to Upstart.

      And lets forget RFE's (request for enhancments) bugs; there simply aren't any work being done in that regard either, so they will languish away in the bug trackers too.

      Again, sweep those problems under the carpet if they offend your eyes, but be assured that the reality of things will become apparent as time goes by.

      Yes, there are alternative non-systemd distros out there, but if people don't start fixing the backlog of problems facing non-systemd distros, it is a question on how long they will survive. Being in denial of all the problems non-systemd distros are facing will only accelerate this.

      Thinking that everything can go on as before without development and coordination is a failure in analyzing the situation.

    36. Re:A rather empty threat by sjames · · Score: 1

      You ARE confused. Please do apt-get source sysvinit and point me to a patch that addresses a bug in the upstream code (hint, there isn't one).

      An RFE is in no sense a bug.

      What the patches DO show is startpar being added in. That is, the ability for the init to happen in parallel.

      But note, I don't advocate staying with the old unimproved sysvinit forever, just until a truly superior solution that doesn't try to own the world is ready to go.

    37. Re:A rather empty threat by Peter+H.S. · · Score: 0

      You ARE confused. Please do apt-get source sysvinit and point me to a patch that addresses a bug in the upstream code (hint, there isn't one).

      An RFE is in no sense a bug.

      What the patches DO show is startpar being added in. That is, the ability for the init to happen in parallel.

      But note, I don't advocate staying with the old unimproved sysvinit forever, just until a truly superior solution that doesn't try to own the world is ready to go.

      Have a look at the SysVinit changelog. There have been 53 commits since 2.88 was released years ago. Sure some of them are Debian specific, some are startpar, but others are not.
      http://metadata.ftp-master.deb...

      Dismissing RFE's as "not bugs" may mean dismissing request for making SysVinit work with other programs or take advantage of important new features. Thinking that init can live in its own little time bubble while the rest of the system evolves is wrong.

    38. Re:A rather empty threat by sjames · · Score: 1

      So it should be a piece of cake to show me the patch, but you failed. Perhaps you have no idea what is what.

    39. Re:A rather empty threat by Peter+H.S. · · Score: 1

      So it should be a piece of cake to show me the patch, but you failed. Perhaps you have no idea what is what.

      Look at the changelog numbers. Each number after the release number points to a specific patch. "2.88dsf-53.4" decodes as upstreams version 2.88. "53.4" the fourth patch set to the version 53 (usually one patch per version). So "2.88dsf-42" or "2.88dsf-53.4" refers to specific patches.

    40. Re:A rather empty threat by sjames · · Score: 1

      But it doesn't. The patches are named like 11_man_halt8.patch

      So no, I don't care to search your haystack for a needle. If you know so much about it, show me the needle you claim is there.

    41. Re:A rather empty threat by Barsteward · · Score: 1

      but its not maintained upstream....

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    42. Re:A rather empty threat by sjames · · Score: 1

      Because the bugs are in the distro customizations, nothing for upstream to maintain.

  44. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    >
    > Linus is NOT good for the desktop ...
    >

    Says who? This is entirely your personal and subjective OPINION and does not apply to all.

    I have been employing Linux as my main desktop ssytem since 1997 and my productivity has neve been higher.

  45. Re:And this is why Linux will never win the deskto by NotDrWho · · Score: 0

    1) You avoid the current version because it's such a usability disaster that no one wants to touch it.

    I actually recently installed 8.1 on my main gaming rig and found it quite fast and easy to use, actually.

    2) Your current hardware is suddenly obsolete because it's last years model and it's not supported anymore.

    Windows 8.1 has the exact same hardware requirements as Vista and Win7. In fact, it's even more lightweight and less demanding than Win7. If your hardware is so old it can't run Vista, then yes, that could be a problem But I'm pretty sure a 10+ year old computer hardware would choke on the latest version of most modern Linux distros too.

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
  46. Re:And this is why Linux will never win the deskto by ericloewe · · Score: 5, Funny

    I disagree. Having Linus yelling expletives at your average PC user would go along way towards educating them or scaring them away from computers.
    The end result is the same in either case.

  47. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    For the consumer, there is only Windows 8.1. It comes in a nice little box (with 32-bit and 64-bit discs inside). To buy any version of Windows 7, you would have to special order it online (since no real-world brick-and-mortar retailer has stocked it for some time).

  48. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Have you ever installed Windows?

  49. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    If you're not sure what exactly Linux is, you're ipso facto not going to be installing it. Show me a counterexample, and I will show you someone dumb enough to wipe their computer without knowing why.

    If such a species exists, it deserves all the Windows it gets.

  50. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Steam runs great on my Gentoo box... so I'd *assume* it would work on most Linux distros. I would never recommend Ubuntu to anyone I cared about anyways.

  51. Re:And this is why Linux will never win the deskto by NotDrWho · · Score: 0

    Have you ever installed Windows?

    Many times, every version going back to 3.1.

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
  52. Re:And this is why Linux will never win the deskto by aztracker1 · · Score: 1

    I think that really depends on the age of hardware... just this morning, a coworker has installed a new hard drive, and windows 8.1 on a roughly 3yo desktop. Windows installed and within a few minutes had updated all the drivers... very straight forward... my last desktop install, I had installed to one drive, and after updates in ubuntu (grub did something goofy to another drive), and it wouldn't boot anymore.

    OSX is a little quirky for installs, but not that bad either... in general they are all okay... Linux is the only OS (depending on distro) in the bunch where clicking the "update all" button will often break something that worked before.

    --
    Michael J. Ryan - tracker1.info
  53. Re:And this is why Linux will never win the deskto by jbolden · · Score: 0

    Linux works out of the box in the same way that MacOS or Windows does.

    Not really. It is has gotten worse at this in the last decade. 10 years ago I'd say Linux is likely easer to install on random hardware. Today the relentless desire to hack up drivers has dried up (understandably a ton of work that never stops). The better desktop distributions went broke. Mandrake is gone. Caldera (pre SCO) is gone. RedHat makes a server but not an OS. YellowDog (PPC) gone.... Xandros gone. It is getting harder and harder to get Linux to install and work on the desktop.

  54. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Did you just step out of your time machine from the year 2000?

  55. An opportunity for Debian? by FridayBob · · Score: 3, Interesting

    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.

    1. Re:An opportunity for Debian? by kosmosik · · Score: 1

      > 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

      You are joking, right? The reason people use RHEL not Debian is primary because tons of commercial software built on SAP, Oracle and similar are *supported* on RHEL. That has little to do with RHEL or Debian being technically superior from each other. After all Debian and RHEL are just Linux distributions not so much different from technical standpoint you have similar technical limitations using these as both use Linux as kernel. People use RHEL because they need to have support for the apps they are running. Not because it uses this init system or other - none of RHEL admins really care about it as long as it is supported by the business apps they need to operate.

      And also I don't quite get the shitstorm going on about systemd. I think compared to sysvinit it is a great step forward. And I'm a professional sysadmin administering just few Linux systems - couple of RHEL boxes (Oracle related stuff), some CentOS (for Zimbra and MariaDB which we use internally) and CoreOS with Docker and all of systemd glory mostly for my own amusement at our own webapps. All of these are systemd powered right now and I don't see any problem with that. Just works as an OS.

      Oh and on home laptop, home nettop and few raspis automating stuff I use Arch Linux with systemd of course.

    2. Re:An opportunity for Debian? by FridayBob · · Score: 1

      You are joking, right?

      Nope.

      The reason people use RHEL not Debian is primary because tons of commercial software built on SAP, Oracle and similar are *supported* on RHEL.

      Interesting. That would explain part of its appeal. I'm a long-time Debian user who happens to have obtained an RHCE recently. RHEL left me with many positive impressions, but there's much that I have yet to learn about it.

      ... People use RHEL because they need to have support for the apps they are running. Not because it uses this init system or other - none of RHEL admins really care about it as long as it is supported by the business apps they need to operate.

      Well, I've seen comments from RHEL admins who would disagree with that statement (I believe here on Slashdot).

      And also I don't quite get the shitstorm going on about systemd. I think compared to sysvinit it is a great step forward. ...

      For me, Linux is about control. That's the great thing about Linux, and the Unix philosophy in general: it's resulted in an incredibly stable system that at the same time is possible to tune in a very fine-grained manner. That's why I like Debian. The systems that I've been building and maintaining with it over the years just keep getting more complex. My favorite ones are usually the cheapest ones: built on a shoe-string budget, but running everything including the kitchen sink. Importantly, I've managed to get it all to boot up and behave just the way I want precisely because of the extent to which I can control sysvinit, cron, rsyslog, udev, fstab, networking, and so on. I've accomplished much that way and so it's worth a lot to me.

      Apparently, systemd replaces all that and more with a single monolithic structure, which seems more akin to the Windows way of doing things. It's main selling point appears to be boot-up speed, and while I can understand how laptop users (Ubuntu, Linux Mint, etc.) would appreciate to that, IMO the cost that we must all pay for that extra speed is just too high. Don't get me wrong: I'm all for improving the Linux boot process, but not at any cost. I can appreciate the idea that sometimes it's necessary to take the bull by the horns, but in this case I think an incremental approach is still the better way.

    3. Re:An opportunity for Debian? by kosmosik · · Score: 1

      > For me, Linux is about control.

      And exactly what aspect of control is taken from you by systemd?

      > Apparently, systemd replaces all that and more with a single monolithic
      > structure, which seems more akin to the Windows way of doing things.

      No it isn't. Lots of commercial unix like operating systems had moved on to some form of init system not based on shell scripts f.e. Solaris, Mac OS X etc.

      > It's main selling point appears to be boot-up speed

      No it isn't.

      > IMO the cost that we must all pay for that extra speed is just too high

      And what is the cost exactly? What exactly do you have against systemd? Only thing you stated is that it is monolithic and non unix way. I don't rally care about it. What practical limitation does it cause? Only valid complains about systemd I've read so far is that is not standard as it is an implementation and in theory this shouldn't be done like that. And I agree but still it exist, it works and it is not going anywhere. The second complaint is that it uses binary log file. It does in fact but I also don't care about that. I can config it to forward to syslog so it is no problem. Actually by using such architecture it can start logging earlier than sysvinit system which is better. These two flaws do exist but they do not rule against systemd in general. It is still a step forward in right dimension.

      Look at CoreOS and its components like fleet - this is what systemd was designed for and it is strictly server operating system.

  56. Re:And this is why Linux will never win the deskto by davydagger · · Score: 1

    thats a bit unfair, because there are only a few real distros that account for the majority of linux users, and Only two real parent distros, of RedHat and Debian, which account for over 95% of linux installs, and just about all "production" machines.

    Many of the distros are the exact same as the parent, but are specialized for a specific task or piece of hardware, which gives linux the legendary flexability.(like raspian), and lets it work on anything.

    One of the big incompatibility between these two worlds was initsystems, which is now rectified by universal adoption of system.

    Oh, and for the most part, they use the same libraries, same system software, same kernel, so most software targeted for one, compiles against them all, except in rare corner cases of version mismatch, but even still, its not unreasonable to expect a competant guru to do some minor port work to get them running.

    This is very much unlike the world of the x86 BSDs.

  57. Re:And this is why Linux will never win the deskto by aztracker1 · · Score: 0

    Well, in the same vein which of the dozens of versions of linux do you install? Beyond this, take a typical 32-bit windows application, and it runs in all of them without a recompile... Want to run a program in linux, is it in your distro's install system, yes, but an older version, you need the latest, but that also means updating a bunch of other stuff to an unstable release, crap, now your sound no longer works right... there goes three hours tracking that problem down.

    --
    Michael J. Ryan - tracker1.info
  58. Ugh... how the hell do I post? by Anonymous Coward · · Score: 0

    I'd be happy to vote... if I could figure out how. Do I join the list, wait for a reply, then finally reply to that? WTF?

    I think this is probably the biggest reason there's no activity from the public (or very little) on that issue. You have to vote via a mailing list. Seriously-- get a better system for input, get more input. Mailing lists are easy, sure, by they're a crapshoot for readability and interaction.

    I'm no fan of SystemD but if I can't vote then I guess I'm heading to Slackware... FWIW-- if I wanted my servers to have a desktop configuration by default, I'd use motherf**kin' Windows. As well, most of us NEVER reboot-- so faster boot times are marginally useful at best.

    Furthermore, "if it ain't broke, don't fix it."

  59. Re:And this is why Linux will never win the deskto by bspus · · Score: 1

    A dozen versions for sale? Are you counting server editions too? For home use there is only one version to consider. Plain 8.1. For Businesses There is 8.1 Pro but depending on your needs and business size, you might even get away ignoring that Older versions and server versions are not even considered for ordinary users. The (free) UI add on is optional of course. I too use it but its not a must and is trivial to find and install Mind you all this is still less variation than a single distro of linux in some cases. Lets see, there's mint but which version? 16, or is it 17 these days, they seem to change every few months. And what is this? They are all supposed to be the same version but why do they look so different? KDE, Cinnamon, Mate, XFCE. And why does it say ubuntu there? is that not another distro? Oh its a spin off. But there is also a debian version too... with no version numbers. Oh god my head hurts I can't make heads or tails of it...

  60. Mint Debian Edition by wiredlogic · · Score: 1

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

    --
    I am becoming gerund, destroyer of verbs.
    1. Re:Mint Debian Edition by Anonymous Coward · · Score: 0

      Oh look, "haters," a term used simply to bundle together people who disagree with the position one has taken without even considering that they may not have the same interests, needs, or desires as one's self.

    2. Re:Mint Debian Edition by Anonymous Coward · · Score: 0

      I agree with the sibling AC, this "hater" label for dissenting opinions (which outta be a healthy thing) is getting old.

      But answering your question: LMDE is basically Debian Testing with a bunch of packages overlaid to add the "Mint" user experience. So no, it's not a fork.

  61. Re:And this is why Linux will never win the deskto by znrt · · Score: 1

    Gnome and Unity are almost as dumb as their commercial counterparts).

    the good thing about gnome3/unity is that it provides an excellent oportunity to realize you don't need it. nor gnome. nor kde.

    get yourself a pure window manager (dozens to choose from, most of them totally customizable) and be done with the "desktop" mentality once and for all. it will work with any linux.

    you'll have to learn a few basic things: how to split windows and switch between them, how to launch programs, errr ... not much more. oh, and forget about leaving your crap on any "desktop". get used to keep it organized, already. after 30-60 minutes of exploration you should look back at windows, macos, kde or gnome as bizarre aberrations from a infantile and baroque past. so much for user experience.

    compared to awesome or i3, the whole

  62. Re:And this is why Linux will never win the deskto by MouseR · · Score: 0

    Actually I can relate. Got my fiancee off Windows and into Ubuntu (latest stable at the time). Initial install was a nightmare to get a bootable installer but once the hurdle gone, installed just fine. Then it was the carrousel of packages, getting het what she needed. Mandarin music player, OpenOffice (the easiest one to get IMO) and other things so she could enjoy a virus-free setup. It just meant days of screwing with a system she just wanted to USE. Not build.

    She eventually got a Mac Mini because of house influence. She's been quite happy with it so far. Her last gripe is her Android phone not satisfying. I'm trying not to push her but... this is also an iOS house...

  63. Boot/init is a critical stage by Todd+Knarr · · Score: 4, Interesting

    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).

    1. Re:Boot/init is a critical stage by Electricity+Likes+Me · · Score: 3, Insightful

      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.

    2. Re:Boot/init is a critical stage by haploc · · Score: 1

      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.

      This.

      I have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles.
      Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.

      A good thing is that a wishlist item has already been opened for logstash, so they're working around this issue already.

    3. Re:Boot/init is a critical stage by Anonymous Coward · · Score: 0

      You still depend on one tool. Right now I can mail the logs and read them on a windows/bsd/non systemd linux, if some utility is missing I can use another, I can dd the god damn file to the serial port if I want to and you still are fucked if for example something corupted your precious journalctl.

    4. Re:Boot/init is a critical stage by Peter+H.S. · · Score: 1

      have nothing against binary log files per sé, but they should not be the primary and only option. Instead of hanging rsyslog after journald, I'd rather see it reversed, first plain-text logging to syslog and eventually piped to binary logging afterwards (or parallel to both, whatever). That way, all the info is still available in case the binary log files get corrupted for one reason or another, and people still have their easily searchable binary logfiles.
      Also it'd make it easier for other remote-logging tools to hook in with the already existing syslog infrastructure than hook on to journald.

      It doesn't make sense to go from text to binary format as default. Remember that a key point in having a structured and indexed binary log file is that you can keep all kinds of rich meta data info in each log entry, like monotonic timestamps, high precision time markers, system UUID's, etc.. If you put all those meta data fields directly into the flat text file, every log entry line will become insanely long and complex, making it much less human readable.

      The present solution with systemd making all the local log entries in binary form, and then use rsyslog for converting it to legacy flat file format, or placing it a database while preserving the rich meta-data is a really good solution with few drawbacks and many great advantages. In this way, systemd is actually enhancing rsyslog's capabilities. Using either journald-gateway or rsyslog to remote logging can now preserve the rich meta data too.

    5. Re:Boot/init is a critical stage by Anonymous Coward · · Score: 0

      Boohoo. You do realise we're talking abouny fucking UNIX right? Not windows

    6. Re:Boot/init is a critical stage by kosmosik · · Score: 1

      > The init process is a critical stage: failure tends to leave you with no access to
      > the system to diagnose the failure.

      Nowdays not really a problem. If this is a desktop system then just hook up a LiveCD with your choosen distro or an USB stick and go on from the live system. With live system images you have all the tools you need and as far as the system's storageis not damaged you can do whatever you wish. As for servers - well remote lights out, management cards, flash addons, consoles etc. you can do whatever to rescue the system. Or if you cant afford it just use serial console to the bootloader and add a failsafe recovery system partition with an image containing all the needed tools and you are ready to go. Mind that these means were used like long time ago even before systemd happened. ;) If you are thinking about disaster then get ready for it when your systems work.

      > 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

      Look above - complex stuff to run is not as complex as you see it. You can easly run even an graphical desktop system to recover your system even if you wish for doing so (most live cds do so). You just need to plan it ahead.

      > mainly they just require that basic binaries be available in the path

      Systemd does not depend on these tiny binaries. In my opinion it is an advantage. It still needs to get unit information from somewhere (like local filesystem or fleet).

      > Until I've got at least a basic system up and running enough to log in and work

      This is probably the old or wrong way of doing stuff. Just boot from something else and chroot to the system and then check the problem.

      > text-based tools will probably run to decipher binary logfiles

      You reall don't need to decipher anything as the log files are not ciphered. You just need to open them with specialised tool (avaiable on your rescue media from which you have booted). You don't quite get why people have problem with binary log files do you? The problem is not about tools for accessing them - the main problem is if they get corrupt they are much harder to recover than plain text files.

      > and modify configurations

      With systemd you do not need any special binary tool to modify configuration.

      > The only change I'd make is to make systemd use syslogd like everything else

      But it does.

      > SysV init scripts may be clunky and primitive, but they've been around a long time.

      So?

      > 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.

      It does. But I get what you're getting at - writing a startup script yourself. So maybe try writing systemd unit for your need yourself and then compare it to sysv. IMVHO systemd units are easier (as more simple) to write than shell scipts for sysvinit. But YMMV.

    7. Re:Boot/init is a critical stage by Anonymous Coward · · Score: 0

      Here's a real-life example. My server crashes during boot, and I can't figure out why. I have a Macbook running OS X, or I could borrow my coworker's Thinkpad with Windows 7. Using these tools, how can I read the log files to figure out what went wrong?

  64. Re:And this is why Linux will never win the deskto by skids · · Score: 1

    But I'm pretty sure a 10+ year old computer hardware would choke on the latest version of most modern Linux distros too.

    The big problem there is graphics drivers for old cards, for which the vendors have discontinued their binary blobs and the opensource drivers never had good thermals and bus timing configurations for lack of documentation. In general, though, old machines can carry most of the newest distros while breaking a moderate sweat.

  65. Re:And this is why Linux will never win the deskto by kick6 · · Score: 1

    That's not out of the box. Buy a machine with Linux pre-installed (yes, I realize there aren't many options) like you do a windows machine, and viola...it works out of the box.

    THAT'S the point he was trying to make.

  66. Re:And this is why Linux will never win the deskto by aaaaaaargh! · · Score: 5, Funny

    The average user also has about one tit, one ball and half a penis. Just wanted to mention that.

  67. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Sorry, I'm not posting this under my own username. Not a chance.

    I'd mod you up if I had points, but Slashdot seems to be especially stingy with them these days. Good point.

    Plus, the level of straw man and unwarranted troll mods has skyrocketed. Guess I pissed in someone's Cheerios.

  68. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Really? You looked at what versions? Because I know for a fact they only have one version with at most 2 sku's in the brick and mortar stores. And on their site? it's not like they are pushing you too the enterprise versions. No you see home and professional when it was windows 7 and now you see windows 8 and windows 8 pro. (ok 8.1).

    I am sorry but trying to complain about the multiple sku's of windows to the numerous flavors of linux is ridiculous. And name me software you need that requires any specific SKU of windows.

  69. I Trust Debain by enter+to+exit · · Score: 3, Insightful

    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.

    1. Re:I Trust Debain by Anonymous Coward · · Score: 0

      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.

      You're equating website design skills with technical knowledge.

      You fail.

      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.

      Now you've admitted that you have very limited technical expertise.

      Epic fail.

    2. Re:I Trust Debain by enter+to+exit · · Score: 2, Insightful

      I have no interest in trading barbs with you. I don't care enough.

      You're wrong to suggest i don't have technical skill. I've done a fair bit of C programming against the Linux API. It might not be the bash scripting that you get excited about, but it's something.

      Perhaps you've inadvertently stumbled on an interesting point though, could it perhaps be that what worries you most is the erosion of your exclusive club of arcane knowledge? I'd suggest to you that arcana is not a necessary component of technology.

      I'd like to note also, that you haven't addressed my underlying point that technical committees of multiple distros have adopted systemd.

    3. Re:I Trust Debain by Anonymous Coward · · Score: 0

      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.

      8 votes doesn't sound like a large group of people. And that was 4 for and 4 against. Does that sound like a collective decision to you? The only reason systemd was adopted was because the chair's vote gets counted twice in the event of a tie.

    4. Re:I Trust Debain by Anonymous Coward · · Score: 0

      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 trust the US government - as a collective - to make the best choice. The government has a large group of people with diverse interests and the majority of them voted to go to invade Iraq in 2003 because of it's "WMDs and ties to AlQaeda", and to fund spying on US citizens via the NSA. The government isn't exactly known to be a flippant one.

    5. Re:I Trust Debain by Barsteward · · Score: 1

      i wouldn't bother responding to 12 year old AC trolls. they are too scared to even register with a nickname

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    6. Re:I Trust Debain by Anonymous Coward · · Score: 0

      Yep, 8 people is a large and diverse group.

      With 1 person casting the deciding vote.
      On a committee created for cut and dry bug-fixing of conflicting packages, not architectural change decisions.

      Yep. Yep. Yep. Yep.
      Trust your masters. Trust. Trust. Yep. Yep.

    7. Re:I Trust Debain by kenshin33 · · Score: 1

      it's not about who has the longest proverbial dick. it's not about, it just worked for you, or a bunch of other people. Where it works, well, it works there's nothing more. The big hairy problem is when it doesn't, in the case of sysv init (or openRC) the places to look for troubles are few an easy to read and modify.
      Take for For example the *KIT set, theses are very nice additions that simplified the life of a lot of people (including me), but only when everything was working, it stops working and hello 3/4 hours wasted to find out WHY exactly it wasn't working, b/c of the lack of documentation (a problem that was corrected lately) and cryptic messages if any at all. Source code is documentation you say? yeah sure, if you're home with nothing to do it's good, but a sysadmin with an already understaffed department doesn't have that luxury. You, me at home is one story, we have time, and are dealing with ONE system that is ours, managing hundreds of desktops, users and servers is an other beast all together!
      the fact that technical committees of multiple distributions adopted systemd doesn't mean anything unless the reasoning behind it is bullet proof (I don't know as I wasn't there and didn't bother looking for it, did you?).

    8. Re:I Trust Debain by mattventura · · Score: 1

      But no amount of technical knowledge or intelligence will matter if the people in question are biased to begin with.

      Besides, at this point, the discussion isn't even "should we use systemd?", it's "should we force all of our users to use systemd?" Whether or not you use systemd (disclaimer: I use it on my laptop and a desktop, but use sysvinit on servers), it's pretty hard to deny that there are plenty of perfectly legitimate complaints against systemd, to the point where forcing systemd instead of allowing people to choose their own init system is clearly not a great idea.

    9. Re:I Trust Debain by tkotz · · Score: 1

      This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

      The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

      The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

      The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

      Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

    10. Re:I Trust Debain by tkotz · · Score: 1

      This fork is dubious. It is being proposed by people who admit to not having time to support Debian. So I doubt they will have time for a running a whole new distro.

      The need for it is non-existent as Debian policy 9.3, 9.4 and 9.11 still call for the inclusion of scripts in /etc/init.d/ in all packages that provide a daemon. And LSB compliance on those scripts was a Lenny release goal. As long as they try to maintain LSB compliance as a goal and don't change the policy they will continue to support all compliant init systems. There is currently no policy for mandating that a systemd unit file be provided.

      The real decision of the technical committee was that systemd is the best choice of things to call those scripts. The standardization of these files is what allowed them to make this decision at all. It would be a very strange move for Debian to suddenly start to abandon the cross init system portability it been pushing for for years. Debian has always been good at working with non default options. I know this as a KDE, ratpoison, and pre-default systemd user. And I'm currently looking at giving OpenRC a try.

      The resolution just stands to tie their hands in cases that don't make sense. If a upstream wants to make their software require a certain init system, And a DD wants to package it fine. It will hurt that packages usage among people who don't use that init system. The only thing the resolution buys is political appearance.

      Debian changes defaults all the time, look at the XFCE/Gnome back and forth lately. If systemd upstream starts to be too much of a problem the default will change. Probably to something that supports LSB init scripts. Systemd is on a razors edge, it barely won the vote.  Maintainers know this and won't remove a perfectly good file from their package just for the chance of getting RC bugs when the init system changes again.

  70. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I disagree. Having Linus yelling expletives at your average PC user would go along way towards educating them or scaring them away from computers.
    The end result is the same in either case.

    I'm sorry, but you are either flame bait or a complete retard.

    Linus, the person, does not interact with your average PC user. He does not interact with your average programmer either. Linus maintains Linux, the kernel.

  71. How by jbolden · · Score: 1

    Let's ignore the issue of whether the fork is a good idea. How are they going to accomplish this? Debian has thousands of packages. Upstream developers mostly like systemd. At least a few dozen packages are becoming hard dependent on systemd. Assume this number doubles every year (not unlikely). What is the Debian fork going to do? Assume that about 200 or so already have reduced functionality without systemd, again let that go up 50% per year for the next few years. How are they going to fix this?

    This sounds like hundreds or not many thousands of man years of work per year every year trying to keep up. How is the Debian fork possibly going to make it? The best they can do is release a traditionalist subdistribution which uses init. OK that's easy, but that's not a fork. And frankly if they start patching a few things, why not just roll those patches either upstream or into Debian?

    How is this fork going to work and what are they going to do?

    1. Re:How by Anonymous Coward · · Score: 1

      > Upstream developers mostly like systemd.

      I'm an upstream developer and I think it's total crap.

      What pisses me off is that I can see the hundreds of hours of wasted effort ahead, and screw that.

    2. Re:How by wytcld · · Score: 1

      As far as the init system goes, the vast majority of packages are not daemons. Only daemons require init support. Writing sysv init files is an art, but it's well-refined. It won't give you the fastest possible laptop boot. Laptop users who don't just hibernate or suspend, but do fresh boots frequently, should definitely go systemd. Of course systemd D is a Borg, assimilating far more than init scripts. But the task of maintaining a couple hundred init scripts wouldn't be hard for a small committee of volunteers. For init stuff outside that, if you can't start a daemon from rc.local you shouldn't be a sysadmin. For the non-init stuff, the trick is to convince upstream developers to support diversity, which can be done by continuing to embrace open standards and APIs.

      --
      "with their freedom lost all virtue lose" - Milton
    3. Re:How by jbolden · · Score: 1

      As far as the init system goes, the vast majority of packages are not daemons. Only daemons require init support.

      I agree. Most packages aren't a problem. But many packages depend directly on indirectly on daemons. Which is how chains of dependencies form.

      But the task of maintaining a couple hundred init scripts wouldn't be hard for a small committee of volunteers.

      That's easy. But that's not the task. systemd does process monitoring. Systemd has ties to PaaS. Systemd handles power management and alerting applications to be responsible regarding their power usage... All that code needs to be maintained. This is where it gets to be serious programming.

      For the non-init stuff, the trick is to convince upstream developers to support diversity, which can be done by continuing to embrace open standards and APIs.

      How? The fact that upstream developers liked the features of systemd and kept wanting to use them is what drove Debian to feel that they had to make the switch in the first place. Sure if the world were different Debian would have made other choices. But how do you convince developers to embrace "open standards". Especially since FreeDesktop has put out a systemd spec, there exists a systembsd which is implementing this spec so systemd is arguably an open standard.

    4. Re:How by Barsteward · · Score: 1

      you don't have to do any if you don't want but you might to do something to remain relevant

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
  72. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Old video cards are 100% worthless. Modern CPUs have built-in GPUs that outperform every video card made more than 7 years ago. Just throw your old video card in the trash if it's more than 7 years old, or if it's a "midrange" card from 3 years ago.

  73. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Fair enough. If you're taking that route then let's discuss one distro of Linux: Ubuntu.

  74. Re:And this is why Linux will never win the deskto by Holi · · Score: 1

    So let me guess, You grow your own cotton which you then turn into thread, that you then weave into clothes, with which you then make your own clothes? No? then shut the fuck up you self entitled prick. Your computer was built by the same small asian people as mine.

    And it's funny to hear you clamoring on about propaganda when that's all your little speech was.

    And I guess you don't vote, which in my mind means you don't get to complain since you instead let the "mindless masses" control your life for you.

    --
    Sorry, teleporters just kill you and then make a copy. A perfect, soul-less copy.
  75. Re:And this is why Linux will never win the deskto by davydagger · · Score: 5, Interesting

    Linux could work for the average user, at the end of the day there is no technical reason why not. After all Linux(in the form of android), dominates on the cell phone market, where the user base demands greater user friendlyness, has less patience, and wants even more bells and whistles, and is far less compitent with a computer. Linux has been shown to work marvelously with light meters, accellerometers, USB, touch screens(multi-touch even).

    The big issue is how consumers by technology. They don't care about specs really, they don't care about merit. They care about branding and imagine. They want their Apple(tm), search with google(tm). Advertising and public relations gurus over the last few decades have build reality distortion bubbles, where people actively identify with brand names. GNU/Linux has no such brand name. They really don't care about "just works". Face it, windows does *not just work*, but people do whatever it takes, because they think windows is what they are supposed to be using. Microsoft presents the image of normalicy and conformity that most people identify with.

    Apple on the other hand, presents an elitest artisan, fine craftsman, and intellectually supperior image, that marks the owner as part of an elite group.

    Linux cleans up serverside, because it rode the wave of start up culture of the 1990s. If you had a great idea for a new website, but didn't have much capital, you could run a proffesional website with Linux, Apache, Mysql, and PHP out of an old desktop for a fraction of the cost of what constituted a proffesional server, of the day

    As these companies grew, they continuted to use linux, and helped it transform into a proffesional class OS, that couldn't help but take notice.

    Linux will eventually take over the desktop, and the reason is because microsoft has no real friends, and they have an ever growing list of enemies. Many of those pimpleface teenage nerds they stepped on back in the 1990s are now grown developers and sys admins. Their day dreams are now multi-million dollar products. Linux has a lot of corporate backers, many of which are household names, and some of the largest most powerful corporations in the world.

    Whats eventually going to happen is that MS is going to piss off another giant like Google or Samsung to the point they want blood. You'll see a few large companies pour money, time, resouces, advertising into a distro with enough MS haters to accept them, and then use a Free as in beer product into the desktop market, to crush microsoft to prevent them from competing in other markets, by destroying their cash cow.

    There will not be a year of the desktop. It will be a decade of pure hell, and microsoft is going to fight tooth and nail, and use every dirty trick in the book to keep the desktop market. They will eventually loose, because the nature of FOSS allows many companies to quietly pool resources behind a single banner, especially a not-for-profit, and allows more to join later without any real effort or diplomacy. Eventually it will be taken from them, and from that point its another 10 years before they go out of business.

  76. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Ubuntu LTS as distributed on pre-installed systems such as those from System76 or Penguin Computing. If you have never had a pre-installed, chain designed for Linux system go out today and buy one today. It's like night and day.

  77. Re:And this is why Linux will never win the deskto by leenks · · Score: 1

    I suppose turning a Mac on with Command+Option+R pressed down is a little quirky. Not sure of many other machines that will let you reinstall the the OS completely from the Internet even after a hard drive replacement so easily though. And 'update all' on a Linux distro typically updates far more than the operating system - stuff breaks all the time when updating applications on any platform.

  78. Re:And this is why Linux will never win the deskto by FatdogHaiku · · Score: 1

    And that is still the point. Linux, BSD etc are all good for a purpose.

    Linus is NOT good for the desktop or average user. Most people just want something that works out of the box, even if there are a lot of tradeoffs.

    I've gotten several older users moved to Zorin 8 (and now 9) after XP died. For the most part they can do what they want, shop, Skype, play most browser based games, bank, email, etc. I find they get less infections, almost zero. Once in a while they misplace an icon or play with the system setting and I have to look at it for them, but that too is rare. It saved them from buying a new system so they are willing to learn a little...

    --
    You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
  79. Not a hypothetical issue. by Zarjazz · · Score: 1

    I'm currently the senior sysadmin for several thousand Redhat/CentOS servers and everything about systemd is giving me a headache. Myself and every other person on my team dislike it to varying degrees and none of us want to use it. This is now a blocker to us upgrading from RHEL6 to RHE7. There are lots of nice new features in the updated release we want or need to use but we are refusing to upgrade. This isn't a philosophical argument. I've tested it in various scenarios and it's almost not fit for purpose and throws out countless decades of experience in the team.

    Frankly I'm shocked that RedHat have steam-rollered this into version 7, they are normally a very conservative distro (a very good thing in an enterprise environment!) Though I guess I shouldn't be that surprised since the lead developer works for them. I'd be looking at other distributions but they all seem to be switching too. I'd say RedHat have lost some business but I'm not sure what options I have to switch to?

    However I have noticed a marked increase in the backlash against systemd in the last few months, probably from the fact that now people are having to use it and all these discussions are definitely a good thing, if slightly too late.

    1. Re:Not a hypothetical issue. by Anonymous Coward · · Score: 0

      Confused..

      You wrote:
      "I've tested it in various scenarios and it's almost not fit for purpose and throws out countless decades of experience in the team."

      " I'd be looking at other distributions but they all seem to be switching too."

      Maybe it is time to learn something new?
      More then one distro is moving to systemd but you are right and it is not suitable and everyone else is wrong for moving in that direction?

  80. Fucking luddites by Anonymous Coward · · Score: 0

    Go take your ball and go home. Your fork will die in a year due to infighting because you anti systemd folks are simply a bunch of whiny malcontents who are incapable of contributing anything positive to a project and then you'll be crawling back.

    1. Re:Fucking luddites by gnupun · · Score: 1

      But who decided systemd is right, and init/upstart is wrong? The decision seems very arbitrary, fascist and non-community oriented.

    2. Re:Fucking luddites by Anonymous Coward · · Score: 1

      The US Government, who by proxy (RedHat, Google, Amazon) contributes more code to Linux than any other single entity, because they use it to power their space station and cryptoclouds and defense systems.

      You want community-oriented, the *BSDs and Haiku are the way to go. The "community" part of Linux is a fallacy, and has been since the early Bush administration. RedHat gave up the desktop market ten years ago and is now a billion dollar company.

    3. Re:Fucking luddites by Anonymous Coward · · Score: 0

      Well, everyone agrees that sysvinit is wrong, and the creator of upstart already said that systemd was a superior choice, so... yea...

  81. This one is different by Jodka · · Score: 5, Insightful

    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 ison 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 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.

    --
    Ceci n'est pas une signature.
    1. Re:This one is different by JustShootMe · · Score: 2

      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.

      --
      For linux tips: http://www.linuxtipsblog.com
    2. Re:This one is different by Electricity+Likes+Me · · Score: 0

      The fact you feel the need to engage in character assassination rather then technical discussion speaks volumes about you yourself.

    3. Re:This one is different by JustShootMe · · Score: 1

      No real need to assassinate that which is already dead.

      I'm sure he's a just fine person, who has no intention of ever listening to anyone who might know a better way.

      --
      For linux tips: http://www.linuxtipsblog.com
    4. Re:This one is different by Electricity+Likes+Me · · Score: 1

      Those people who know a better way also seem to have no intention to ever write any of the code themselves. It's open source: nothing's stopping them. Much as ultimately Linus did the hard work and Tennenbaum did not, such as it will be for whatever init system people want: the code which gets written gets run. Or in this case, the distro which is maintained gets used.

      Frankly, you also cut back to my original point: character assassination and not technical discussion is not "a better way".

    5. Re:This one is different by JustShootMe · · Score: 1

      And this would not be an issue if he wasn't an arrogant person who treats systemd like his own personal playground.

      Back to my point. His Google+ nick says everything that needs to be said about his management style.

      --
      For linux tips: http://www.linuxtipsblog.com
    6. Re:This one is different by drinkypoo · · Score: 1

      The fact you feel the need to engage in character assassination rather then technical discussion speaks volumes about you yourself.

      The fact that you cannot distinguish between "then" and "than" and then have the gall to use the words "technical discussion" speaks volumes blah blah blah.

      The character of a developer is not irrelevant, and your attempts to paint it as such are likely motivated by your own social failings, which you would like the rest of us to ignore.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:This one is different by badkarmadayaccount · · Score: 1

      How does it differ from Linus?

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  82. A completely empty threat by Tenebrousedge · · Score: 2

    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.

    --
    Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
  83. Re:And this is why Linux will never win the deskto by Rinikusu · · Score: 1

    Erm, no? When I was having wireless issues on a new (to me) Thinkpad, I couldn't even get online to search for the problem. Installing a completely different distro ended up fixing those wireless issues. The Windows installation Linux replaced had no such issues. In fact, I can't think of a time when I *had* wireless issues with Windows, but I can recount many, many issues with wireless under Linux, from having to compile the kernel with things like PCMCIA support to support my old Orinoco Gold PCMCIA cards, etc etc etc. You're probably right: Had I had these same issues under Windows or MacOS, I'd be equally as lost, if not moreso. However, in 15 years of computing, that particular issue has not come up under Windows (although there have been many, many others). Hell, on some of my hardware, I can't even get Linux to install anymore (something about APIC (not APCI), etc) whereas the Windows XP install it came with is perfectly fine. And so on.

    I love Linux, use it all the time, but when it's fucked it's good and fucked and my solution these days is just to keep all my data on a different mount just in case I just have to reinstall vs actually troubleshoot an issue.

    --
    If you were me, you'd be good lookin'. - six string samurai
  84. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Ha. Those system76 computers suck. They are simply Taiwanese Clevo and Sager laptops rebadged with a absurdly huge markup that is not justified for something that is intended to be sold as a no name generic laptop in asia. Good luck finding replacement parts when you need a new AC adapter or keyboard.

  85. Re:And this is why Linux will never win the deskto by Wookact · · Score: 1

    People use video cards from seven years ago? The only reason I can think of for that is if your PC is seven years old, in that case they need more then a new video card.

  86. Re:And this is why Linux will never win the deskto by Rinikusu · · Score: 1

    *15-20 years, actually. Didn't start messing with Linux until around 1998, and then it still took a back seat to BeOS...

    --
    If you were me, you'd be good lookin'. - six string samurai
  87. Seems Doubtful by Luthair · · Score: 1

    The fact that the claimed developers are anonymous is a pretty good indicator that this a sham in a misguided attempt to pressure Debian's vote.

    Unfortunately in open source we always have a group of assholes who don't contribute but somehow feel they know best. Oftentimes their opinion will involve a lot more work, but hey they won't be the ones responsible, so who gives a shit

  88. Where's the Hosts Guy? by Anonymous Coward · · Score: 1

    I'm surprised he's not posted and posited that with a hosts file, even systemd could be blocked...

  89. Concerns about systemd by ceztko · · Score: 0

    I will reply only on 1) cause I'm more confident on that matter:
    systemd doesn't recommends "Require" nor "After" concepts. Required concept to express dependency between services is using socket-based activation or other kind of activation that offers similar means of syncronization. That said, the classical Lennart's example, Avahi daemon can start when D-Bus IPC sockets are available. Other ways to start services in a deterministic order often hide race conditions or serious limitations in the way the system answer to dynamic events. For example: until not much time ago Samba server had to be fully restarted when Cups printers were available to expose them to SMB clients. Cups failures or delays in launching prior Samba would lead the latter to be unable to serve printers until a full restart of the service. The same was needed when printers list was updated. This of course was a sign of poor integration between the two services but it should give the idea: IPC is the only mean to synchronize between different services start-up and to express a true dependency. Also it: 1) allows to be intrinsically more efficient cause it doesn't require user-space polling. 2) it allows for circular dependencies to be properly resolved. That is: Samba depends on Cups for local printers but Cups may want to be aware of remote SMB printers. Acyclic graph to express services dependency, as you say, is a too strict condition for complex systems and it's not really needed to ensure proper system start-up.

  90. Re:And this is why Linux will never win the deskto by hansbogert · · Score: 3, Informative

    Wait.. so you went to the websites of the software you wanted to have installed? Do you realize that most distro's have had a unified app-store way before OSX did? Talking about building.. I've had to build more software on my macbook then on my linux machines because OSX lacks a good package manager. Though macports & brew fill that gap somewhat, but the build times - the agony.

  91. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Linux works out of the box in the same way that MacOS or Windows does.

    If your average Windows user had to install their own OS they would be even more lost than if they tried dealing with Linux.

    You were being sarcastic, right? Give an average human being a clean computer with a blank HDD and ask them to install Windows on it and with the exception of any vendor specific drivers they're running in less than an hour. If they have to go find the drivers on the vendor's website(s) then maybe add 30 minutes depending on their Internet speed. Give an average human being the same hardware and a Linux distro and they'll be calling one of us to fix or finish the install after trying to get it running the day before. Sorry, that's just the way Linux (still) is. It's not for the non-technical and why it has less than 1% of the market and why there aren't too many major computer vendors selling Linux desktop computers. The support level is just too damn high! It's not just that MS is contractually obligating these vendors; it's that they cannot afford the Linux support.

  92. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Holding the mouse wrong ?

  93. Has this site lost all credibility? by Anonymous Coward · · Score: 0

    The parent post (about givign up on Linux for Windows) is a 0, but the child post (worded the same but in favor of Linux), is a "4, Insightful".

  94. Re:And this is why Linux will never win the deskto by TheSunborn · · Score: 1

    Why not? Both Postgresql and Openoffice does that.

  95. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I'm firmly reminded of having to edit the Windows Registry and delete some keys to make the system even see the optical drive.

    There are many other problems like this - Microsoft's fdisk not properly supporting partitioning, so if you're erasing an Ubuntu drive you need to delete the partition with the Ubuntu fdisk because Windows can't do it.

    Once Microsoft deal with these stupidities, Windows will truly be ready for the desktop.

  96. Re:And this is why Linux will never win the deskto by Hognoxious · · Score: 1

    Mint Maya with Mate. Backtrack with Gnome[2]. Kali.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  97. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Go back and reread the thread, this just went over your head.

  98. apt-get remove by Anonymous Coward · · Score: 0

    On any Debian system, you could perform apt-get remove to take out a program you don't want. It works for GNOME, and KDE, so why should it not work on systemd? I should be able to install another init system in Debian and remove systemd, like all the other applications. If that is not the case, then Debian has serious problems.

    1. Re:apt-get remove by Teresita · · Score: 1

      You can't do apt-get -f remove systemd because apt-get is a child process of systemd and doesn't have permission, and even if you could do it, your system would hang because systemd is the absolute root process.

    2. Re:apt-get remove by Eunuchswear · · Score: 1

      Balls.

      You certainly can remove systemd and install whatever init system you want.

      Be careful if you're using gnome as it depends on systemd. You can work around this by using systemd-shim.

      See http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html

      --
      Watch this Heartland Institute video
  99. Hey Debian Developers by FudRucker · · Score: 1

    why not do this, build Jessie in such a way that during the install of Debian Jessie put an option so the user can select either init system so there is a tick option to either select systemD or old traditional init system that debian has used for years, can Debian Jessie be built in such a way that during install the user has a choice to go with either system???
    i been using debian & slackware exclusively for the last few years because they are the last two remaining old school distros and if Jessie goes full tilt towards systemD i will be forced to abandon Debian

    --
    Politics is Treachery, Religion is Brainwashing
  100. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Installing Windows is simple. It was easier than installing linux for the longest time. With the current latest releases, both mainstream linux desktop OSes and Windows are equally easy to install. I'm talking about the actual installation process, not picking a version or doing upgrades and support.

    As an experienced Linux user, you already know which distro you want. A new user switching from Windows to Linux is completely lost. There are way, way more Linux choices than Windows choices and that user is probably less technically inclined and thus is even more confused: What's a window manager? Why do I want to manage windows? I thought I was using Linux not Windows??

    You could argue that the user should pick one of the most popular distro, but then you can say exactly the same thing when switching to Windows.

    If you're willing to pay Microsoft to try Windows, how much have you paid to your distro for providing such a well working operating system for free? Take that credit card back out.

  101. Re:And this is why Linux will never win the deskto by jeremyp · · Score: 1

    Wooosh!

    --
    All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
  102. Re:And this is why Linux will never win the deskto by ahodgson · · Score: 2

    Sure you can. You just can't do it with a sourceless binary.

  103. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Come over and tell that to my 16, 15 and 13 year old kids.

    At first they were very hesitant to move off windows to ubuntu or mint (two are ubuntu, one is mint). Now they will not want to go back to windows.

    Reasons:

    They find linux easy to use and can do things like scan documents, etc without any assistance.
    To many problems with windows, they were not admins, but managed to break their windows installs every few months.
    No need to download hundreds of MBs in updates and restart your computer every two or three days.

    "The support level is just too damn high"
    From my personal experience it was when they ran windows and constantly broke things. Now they run linux they have far less issues.

  104. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    You are living proof that nobody should be so anal retentive that their assholes actually suck the humor out of the air.

  105. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I would gladly hand over my credit card to get a version of windows that doesn't halt causing me to lose my work while it displays silly technical text in a fancy blue screen.

  106. Re:And this is why Linux will never win the deskto by Darinbob · · Score: 1

    My Stallman periodically gives me patient lectures about how I could be a better human being if I followed his advice.

  107. Re:And this is why Linux will never win the deskto by Le+Marteau · · Score: 1

    Not Debian stable.

    --
    Mod down people who tell people how to mod in their sigs
  108. Re:And this is why Linux will never win the deskto by postbigbang · · Score: 1

    More of a problem is finding 32-bit distros with updated apps that don't trigger CVE issues. Dusty Linux distros are almost as dangerous, as, dare I say it, old Windows releases.

    --
    ---- Teach Peace. It's Cheaper Than War.
  109. Re:And this is why Linux will never win the deskto by dk20 · · Score: 2

    " problem that made your desktop look like Windows 95"

    I don't get the reference, are you saying windows 95 is a bad thing in your pro-windows rant?

    Fortunately there are slightly more then 654685787684 different websites telling you how to remove windows infections.

  110. Don't forget you still have to update Windows by rHBa · · Score: 3, Informative

    Don't forget that once Windows is installed and you've installed all your drivers you then have to update it!

    If I install a Linux distro that came out, let's say, 5 months ago I'd expect that to take about 30 mins on a slow ADSL connection.

    If I install a version of Windows that's 5 months old I'd expect it to take most of the day if not some of the next day!

    Having said that I'd never install a version of Windows that's 5 months old, instead I would install a version of Win7 with the latest service pack streamlined in and it would STILL TAKE A WHOLE FU**ING DAY.

    1. Re:Don't forget you still have to update Windows by Anonymous Coward · · Score: 0

      What drivers? I installed Windows 8 on a 4 year old computer. After which the only driver I installed was the latest Nvidia driver for my GTX 650. Everything else worked, including my Qualcomm Atheros AR5005G Wi-Fi adaptor, which is about 3 years old.

    2. Re:Don't forget you still have to update Windows by Anonymous Coward · · Score: 0

      bullshit

  111. Re:And this is why Linux will never win the deskto by Le+Marteau · · Score: 1

    That's why Linus uses Gnome, I suppose.

    --
    Mod down people who tell people how to mod in their sigs
  112. Re:And this is why Linux will never win the deskto by complete+loony · · Score: 1

    ... and less than two arms, legs, eyes, etc.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  113. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Congratulations, you have cleverly determined the point the parent was attempting to make, which is that Linux may have many versions but this doesn't make it that much more complex than it does for Windows!

    Have a cookie.

  114. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Are you sure about that?

    I still run MainActor 5.5, that's 11 years old, on a modern Kubuntu.

    You might want to stop talking now, you've made a big enough dick of yourself.

  115. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Huh. Guess you don't love your kids enough to buy them a Mac.

  116. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 1

    Geforce 9800GT 512 from 2008, so close to 7 years old.

    I did a quick comparison with a modern low-range card on Tom's Hardware (I forget which particular card, but it was an nVidia one). Mine outperformed it in the bulk of their tests, the only one it didn't was in memory capacity.

    I have a new (last year new) mainboard with onboard video. Doesn't even come close to my 9800GT.

    You, sir, are full of shit.

  117. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Aw, angry internet nerd can't grasp that other people's needs don't match his.

    Go on, post some more angries about how we're fools and nobody cares about us, while demonstrating that you actually do care that we don't use what you think we should.

    You remind me of my ex-, who kept insisting that I should start using Windows because it does everything she wants.

  118. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    They don't care about specs really, they don't care about merit. They care about branding and imagine.

    WRONG. They care about *tasks* and *activities*. You see, a computer for MOST people is a TOOL, with which the purchaser hopes to accomplish certain THINGS. Things like:

    - Edit that spreadsheet from work;
    - Send an email to their kid in college 500 miles away;
    - Listen to some music or watch a movie (or both);
    - Edit some photos then upload them to Facebook;
    - Browse the web;
    - Write a paper;

    Notice that there's no mention of "Process random data at 50 gigaflops of megabuttz over a DDR3 EEPROM Ivy Bridge SSD, with WiMax Bluetooth EDR 4.0?"

    Specs don't matter to the average computer user. They care about "Is this fast enough / big enough / new enough / networked enough to do X, Y, and Z?" There's a reason that Apple's advertising works so well: it's because they get this point.

    Linux evangelists are often completely oblivious to this point, which is why we're still waiting for that vaunted Year of the Linux Desktop. You're right: there is very little *technical* reason why Linux couldn't work for the average user - however there is nobody who understands how the general public buys and views computers marketing and selling Linux to the masses today. The sellers inevitably focus on specs-specs-specs, or they focus on philosophical issues which the average buyer doesn't care about. Neither of which connect to those average buyers.

  119. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Have you ever tried living on a low income?
    I have 3 desktop pc's ( 1 toy for testing, 1 backup for main machine and 1 main desktop )
    and 3 laptops all well old p3's 2 with 512mb and 1 with 1gb
    1 rasp_pi ( not presently used )
    1 olimex a20 sbc with a 320gb disk which everything else backs up to ( and yes its a bit sluggish over nfs )
    My NEWIST machine that i use for everything is 7 years old dmidecode gives the bios date as 05/08/2007
    cpu is an athlon AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
    And that is due to a friend donating cpu and motherboard.
    Disks in all 3 desktops are salvaged from sky+ boxes picked up cheap at boot sales ranging from 120gb 20 320gb
    nvidia gforce 6150 ( unsure of age but also a handme down ) with 2 19 inch 1280x1024 monitors hanging of it.
    I love debian have only ever used debian or slackware since 1st getting it kernel 0.9.something...
    I will not have ANY machine with binary log fles like systemD ( pronounced system-borg )
    Why did it have ANY need to pull in gnome kde dbuss etc it is just forced in via dependancys....
    What complete git decided to make systemd be the ntp system and and controled via timedatectl
    binary log files and matching tools - okay if you want them, BUT AFTER syslog in TEXT mode
    What come next safe boot with trusted binaries and can only use xyz service if unmodified ?
    Not in this lifetime ( i can use recent kde / gnome desktops on my main machine but far prefer gnome2 OR xfce )
    span100

  120. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    What a load of nonsense. It's apparent that you haven't tried a distro in 10+ years, as everything you've said is crap.

  121. Compromise or the lack thereof by Anonymous Coward · · Score: 3, Insightful

    A split decision that created flames of epic heat, even for Debian, even for Free Software in general. Flames that burned far hotter than even Vi vs Emacs. Flames that just won't die out. And the systemd side makes it worse with the attitude of STFU they project. The problem is a TC can't make this decision because it isn't technical, it is cultural and social.

    This is a culture clash, between the UNIX folks who want UNIX developed in the open Linux model (as opposed to BSD) locked in a battle with people who want Windows that doesn't suck. And worse the systemd side has made it clear they are going to intentionally design out any possibility of co-existence or compatibility so it is a binary decision, take systemd and keeping any other set of low level plumbing viable is going to get very painful, very quickly.

    Compromise is therefore not going to be possible since one camp is dead set against it and the UNIX camp will not accept systemd. So a fork is going to happen, but probably not just Debian. The whole Linux world will soon be the GNU/Linux camp vs the Freedesktop.org/GNOME/Linux camp.

    The real root of the problem is Pottering and Co. hate UNIX and want to use the kernel as a device driver to build a new platform upon. They should have simply joined ReactOS but it isn't sexy enough for their egos and besides, RedHat won't pay their salary to work on that project.

    1. Re:Compromise or the lack thereof by visualight · · Score: 2

      I prefer to call it Poettering Operating System/Linux

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
    2. Re:Compromise or the lack thereof by Anonymous Coward · · Score: 1

      Lennux.

  122. Attention all fifteen year old Slashdot kiddies .. by lippydude · · Score: 1

    @BeardedGNUFreak: "You would think even the 15 year old Slashdot kiddies that make up 'teh Linux community' would have had the foresight to never let another Miguel de Icaza type clown trash their precious little OS." post447641

    Interesting quote, but I wonder what are the actual number of front-line developers that are involved in this 'movement' calling for a Debian fork. I would have thought it would be damaging mainly by producing incompatible versions and diluting the developer base.

  123. Re:And this is why Linux will never win the deskto by Aighearach · · Score: 3, Interesting

    I'm still running the same timeseal binary for internet chess that I was running in the 90s. I'll bet the old *bsd builds still work, too.

    It is over 15 years old.

    I still sometimes run programs I wrote in 2001. I don't make any changes or upgrade anything, it all just still works.

  124. systemd is an OS by Anonymous Coward · · Score: 1

    You are sorta right, systemd is not an application, it isn't just PID1. It intends to be nothing less than an operating system that sits atop the Linux kernel and uses it for low level device and filesystem drivers because at this point no sane person would try to reinvent that wheel.

    And it is an OS that UNIX people do. not. want.

    1. Re:systemd is an OS by Anonymous Coward · · Score: 0

      Talk for yourself. I'm UNIX people and I want it.

    2. Re:systemd is an OS by Anonymous Coward · · Score: 0

      Talk for yourself. I'm UNIX people and I want it.

      No, you're a "Linux people" and you want it.

      I'm a "Unix people" (Solaris, HPUX, Irix, *BSD, as well as Linux) and I don't "want" it.

  125. Re:And this is why Linux will never win the deskto by khellendros1984 · · Score: 1

    you can *not* do that with even two versions of the same linux distro a year apart from eachother.

    Hyperbole. Of course you can, if you design the software to handle that. One of my employer's pieces of software is compiled on SLES10 (from 2006) and runs on current Linux distros without a hitch. Code from 5 years ago compiled with gcc 2.95, and I'm sure that I could have that running both on a Linux release from 2000 and one from 2014.

    Now, if you've got a programmer that doesn't have that as their specific goal in how they compile and package the software, then there will be a problem. With non-commercial software that's distributed by the developer as source anyhow, what's the reason for them to take enough care in packaging it to support forward-compatibility? If their software is popular enough, they know it'll be recompiled for inclusion in every new distro's repository anyhow, so they won't focus on supporting the goal of wide compatibility of the binary.

    --
    It is pitch black. You are likely to be eaten by a grue.
  126. Re:And this is why Linux will never win the deskto by budgenator · · Score: 1

    Tell me about it, the last update made my 486SX a brick; bastards!

    --
    Apocalypse Cancelled, Sorry, No Ticket Refunds
  127. troll the troll by znrt · · Score: 1

    see, it's easy to tell what the average user does. it's also easy to make a fool of oneself trying to guess what a particular stranger on the net does, like you just did.

    but anyway your conclusion seems to be that since we both use cotton and microelectronics in some way we both should use windows? or that voting one mafia over the other will bring us ... wait a minute, this is gorgeous ... "control over our lives"? and, hey! we get to complain as a bonus! no shit!

    hehe, hilarious. too bad you didn't like my propaganda. yours was spot on.

  128. Honestly, I prefer the one on the left by Kludge · · Score: 1

    The systemd version is significantly shorter than bash script. Yay. However,
    (1) I would have to read many pages of documentation to figure out what the systemd version actually does, whereas I can just read the bash script and see what it does. What if I don't know sh? Then, I am not a real sys admin. The shell is used in many places in administering a UNIX system, not just the init system.
    (2) Most importantly, I can hack that bash script to do whatever I damn well please. Have I hacked init scripts before? You bet your booty I have.

    1. Re:Honestly, I prefer the one on the left by nabsltd · · Score: 1

      (2) Most importantly, I can hack that bash script to do whatever I damn well please.

      And, although you can hack the "sendmail.service" file shown in that link, your hack will be overwritten the next time sendmail is updated, since the file is in /usr/lib/systemd/system. Also, /usr could be a read-only filesystem.

      Instead, to make your hack effective, you'll need to create a file somewhere under /etc/systemd (your guess is as good as mine...the documentation sucks) that will do what you want. Since there is also no documentation about what, exactly, must be in the file (do you need every entry that was in the original, or can you just override what you want to change?), you'll have to play around for a while to see what works.

      The right thing to do is for the sendmail package maintainer to place an example user file in the right place, and comment out everything so it doesn't actually overwrite the default, but the comments will let a sysadmin know what to change if they need to. But this is yet another major problem with systemd...it has so damn many config files, that if every package maintainer did this, you'd have hundreds of files in the override directory, even though you only need a few for the changes you want to make.

      So, the really right thing to do is to not keep config files of any sort in /usr/lib, but instead put them only in /etc, and then any changes the user makes there are applied as the should be. This is not the systemd way, though, as the systemd maintainers know much better how your system should be run than you do.

    2. Re: Honestly, I prefer the one on the left by Anonymous Coward · · Score: 0

      And here their cloud centric thinking shines though once more.

      Their focus is on having a minimal / inside VMs, with a massive /usr sitting on the SAN to be shared between said VMs.

      If something breaks you kill and reboot the service, or the VM the service is running on. It is uptime by reboot machinegun...

    3. Re:Honestly, I prefer the one on the left by YoungManKlaus · · Score: 1

      and you totally didn't ever have to read any man-pages to get what the bash script does ... jeah right ... on the premise of having to learn what both scripts do starting from zero, I am pretty sure the systemd version would win by a huge margin. Its just people being lazy and pissed off that they have to actually educate themselves about new stuff.

    4. Re:Honestly, I prefer the one on the left by visualight · · Score: 1

      No you're wrong. We *already* know shell scripting, and if you want to be a sysadmin or work in ops you *must* know shell scripting. Using systemd doesn't make the 'must know shell scripting' requirement go away.

      *Everyone* I know in this industry is anti-systemd.

      --
      Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
  129. Re:And this is why Linux will never win the deskto by khellendros1984 · · Score: 1

    OK, cool. Keep that attitude, and maybe we can stop "usability" from getting in the way of actually getting things done. Lots of simple things are easier on Windows than on Linux. Problem is, when you want to do the unusual things, that's when it gets impossible. Linux? Of course it's possible. Spend enough time, and you can swap any part out for something you like more. There are a dozen ways to do most things, and you get to research and choose which one you like. I like that. Now, if I'm going to play a game...reboot into Windows. Lowest common denominator OS for a lowest common denominator activity, and it works beautifully for that (unless the dev used a 32-bit number to represent the RAM in your machine, and the game refuses to start with your -{big_number} amount of RAM).

    --
    It is pitch black. You are likely to be eaten by a grue.
  130. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Bullshit, Jedidiah. Installing old-ass Windows XP? Sure. Installing Windows 8? Very simple and with 8 different installs not a single driver needed. You're FUD and trolling are way out of date.

  131. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Option-D to boot a hardware test over the internet is nice too.

  132. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Go is great. I have binaries surviving android, macosX, and linux os upgrades.

  133. My Opinion by dayton967 · · Score: 1

    First off many things betray the "Unix Philosophy", Bash, ZSH, Busybox, Apache, sendmail, exim, postfix, it could go on from there, because most of these programs do more then one function, such as bash, zsh, and busybox all include their own versions of system applications or once were. The mail servers, do not do a single function, they send and receive, filter, authenticate and many other mixed services, if they were to the "Unix Philosophy" then it should be more like qmail. Apache version 2.0 allows for a great deal more function, including proxy support, other protocol support, and many other things. SystemD though not perfect, makes changes, and encourages the discussion to make changes. Without some of the past changes, that go against the "Unix Philosophy" we wouldn't be here today, but with an abacus, and someone singing the news of the decade as they walked into the village this week.

    1. Re:My Opinion by daffmeister · · Score: 2

      Bash, ZSH, Busybox, Apache, sendmail, exim, postfix...

      All of which can be replaced by other applications (in fact, many are replacements for each other, which is exactly the original point).

      That's the issue with systemd. Once you make it a dependency then you have it and all it's attendent subsystems and you can't replace any of the parts with something else.

    2. Re:My Opinion by dayton967 · · Score: 1

      But the thing isn't systemd or the other programs. It's having a meaningful conversation, about changes of the ecosystem.

  134. Re:And this is why Linux will never win the deskto by chmod+a+x+mojo · · Score: 1

    Though macports & brew fill that gap somewhat, but the build times - the agony.

    Don't forget, if you only want a .5 megabyte terminal application you also have to install ~5+GB of xcode....

    I'd love to run macports (and have in the past), but that huge chunk of space the xcode install takes up kills the SSD space I have.

    --
    To err is human; effective mayhem requires the root password!
  135. Sendmail/Postfix by unixisc · · Score: 0

    Do either Sendmail or Postfix have the ability to recall emails, like Exchange Server?

  136. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Except no, it doesn't. I switched from Win8 to Ubuntu (as a former long time Linux user) recently and whilst my OS X box (and this same box running Windows 8) sees my network shares reliably and runs Borderlands the Pre Sequel reliably, Ubuntu drops my network shares at random, my Wifi adapter doesn't work, and the game crashes the OS - hard reboot required (doesn't crash on the same hardware in Windows).

  137. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Except it can - go into device manager and check the PCI identifier for the missing device. "I don't know how to do it" does not equal "Windows is too dumb to do it"

  138. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Could have sworn it is only a few months since MS had to canvle a patch tuesday because one of patches was causing spontaneous reboots.

  139. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Lol, days? You have a 4-digit UID and figuring out a simple bootable installer was a "nightmare" to you? What's the tech world coming to, a bunch of point-and-clickers?

    From bare metal, 1 hour tops with all apps selected from Software Center and downloaded over broadband. There's stuff about Ubuntu to bitch about. But install-to-productivity time ain't one of them.

  140. Re:Attention all fifteen year old Slashdot kiddies by Electricity+Likes+Me · · Score: 1

    A tiny minority. People who apparently are going to maintain a fork, but "don't have time to deal with Debian".

    What do they think maintaining a distro involves, other then a lot of time working on procedure, process and politics?

  141. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    10 years ago, you think it was easier to install Linux on a desktop? Looooool!! Looooool!! OMG, you must not have done a whole lot with Linux or something, because it's super easy these days, and using it has only gotten easier. And let us not forget that Android and Chrome OS are both Linux distributions, whether people admit to that or not, and I don't think they're hard to use.

    If you want to install Linux on your desktop, may I please point you to any *buntu or even the Mint series. Boom. Done.

  142. Re:And this is why Linux will never win the deskto by steelfood · · Score: 1

    How can anyone expect someone to pick Windows for their desktop when there's so much fragmentation?

    I know you're being tongue in cheek, but most people don't pick Windows; it's picked for them.

    --
    "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
  143. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    You need to hand that credit card over to Dell or somebody else who will sell you a PC that actually works, then. You have a hardware problem.

  144. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I always suspected my users were pretty fucked up and this confirms that.

  145. Feel the power of the threat by Tablizer · · Score: 1

    "Luke, use the Fork"

  146. systemd is the "New Coke" for the FOSS community by Taco+Cowboy · · Score: 1

    If you are 29 years or older you may remember what Coca Cola did back in 1985, with its "New Coke" campaign

    http://en.wikipedia.org/wiki/N...

    Well ... systemd is the "New Coke" equivalent in the FOSS community

    It is touted to be a better than ever but unfortunately, like "New Coke" of yore, it gonna flopped

    --
    Muchas Gracias, Señor Edward Snowden !
  147. Re:And this is why Linux will never win the deskto by carnivore302 · · Score: 1

    Linus OS is the choice of scuba divers.

    --
    Please login to access my lawn
  148. Who wants linux desktop? by Anonymous Coward · · Score: 0

    Surtainly not the average user. Linux is a system for the tinkerer. Systemd is clearly a move to monetise linux. Yeah, call me a troll if you like, but linux is not for your god damn grand parents!

  149. Re:And this is why Linux will never win the deskto by carnivore302 · · Score: 1

    My ESR wants me to go to a cathedral. Or a bazaar. But I have to choose.

    --
    Please login to access my lawn
  150. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Good post. I agree with you although I'd say it depends on the specific Linux distribution.

    That said though, I don't know why so many people have a problem with Linux being sometimes difficult. I've been using Linux since 1999 and I LIKE the fact that it is sometimes difficult. I couldn't care less about converting Windows users to Linux, or making Linux easier to use.

    And I don't care either for the "year of the linux desktop" thing. I've been happily using Linux on the desktop since 2002. My wife uses one of my laptops in bed and I have it running Openbox with everything she needs on it. She just right clicks and there is her web browser, her manga reader, xpdf for reading books, gmplayer for music, xmahjong games, etc. How fricken hard is it to right click on a desktop and click a program? KDE and Gnome are even easier.

    I think bringing your average computer user into the linux world is actually going to cause more problems down the line if it isn't already. They don't understand unix philosophy, history, or the best direction for things. When they start wanting to contribute code we will get even worse crap than systemd.

  151. Re:And this is why Linux will never win the deskto by carnivore302 · · Score: 1

    That's odd. The stuff I wrote in 2001 doesn't even compile nowadays.

    --
    Please login to access my lawn
  152. Trademark infringement? by Anonymous Coward · · Score: 0

    I wonder if debianfork.org infringes the Debian trademark.
    "You cannot use Debian trademarks in a domain name, with or without commercial intent" (https://www.debian.org/trademark)

  153. Don't want systemd by allfieldsrequired · · Score: 1

    I stopped reading he list of "benefits" when I got to binary logging. Looking at the list of major server distro's it looks like all of them are going to be adopting, or already have adopted, this monstrosity. what are viable alternatives? currently using Ubuntu, because, you know, it's Debian, but up to date.

  154. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    You now have Linux Mint (Mate or Cinnamon DE) which is pretty user friendly...

  155. systemd is nice by sandGorgons · · Score: 0

    systemd is a genuine leap of innovation in Linux. Here's my attempt to clear some of the FUD around it - http://www.lambdacurry.com/sys...

  156. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    You seem to live in the past,

    There's Window 8, and Window 8.1. There's 32-bit or 64-bit. There's Windows 7. There's about half a dozen different versions of Windows 7, and I've no idea how many of Window 8.

    There's the XP interface. There's the Windows 7 interface. There's the Window 8 desktop interface. There's the Window 8.1 desktop interface. There's the Metro interface.

    You forgot Windows 95 and Windows 3.11 for Workgroups..

    All the things you mention except one OS version (Win 8.1) and two GUI versions (desktop+metro) are irrelevant for what you replied to -- "Choose your OS, average user". User who choose Windows today get Windows 8.1.

  157. Crowdfunding by Anonymous Coward · · Score: 0

    how come no one starts a crowd funding project for a fork yet?

  158. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Your scenario is like an expert PC user group. :)

    Subtract yourself and two siblings, add a decade or two, a mortgage and sundry worries to the remaining one, and now you have a typical PC user tossing up between operating systems.

  159. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    What distro has dropped 32-bit x86 support?

  160. Re:Attention all fifteen year old Slashdot kiddies by ruir · · Score: 1

    I will probably go FreeBSD...

  161. Re:And this is why Linux will never win the deskto by juanfgs · · Score: 0

    Oh and if you do manage to get it installed, you are left to search for drivers and utilities and to edit conf files for even the most basic functions like say multi-monitor support whereas with windows this is maybe 3 mouse clicks away.

    YMMV In my experience is on windows which I have to hunt down for drivers, reboot after installing each one, install all the necessary programmes. On Fedora I only have to install the Nvidia driver which is 3 clicks away @ RPMFusion. If I try to play an mp3 the system prompts me to install the appropiate codecs, which takes 2 more clicks.

  162. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Yeah total nonsense. If anything linux is easier to install. A recent case proved this for me. My wife's mother's laptop (Toshiba...something) had been 'fixed' by an unscrupulous fella for £80. The guy had just found a vista disk somewhere and formatted and re-installed. I knew this as it was a 'dell' branded vista install. Anyway, apart from losing all her photographs, nothing worked - no wireless, no ethernet - no sound!! It was insane. I spent ages trying to track down drivers for all this in an attempt to get it working and after several hours of transferring installs via USB, I gave up and just tried XUbuntu booting from USB. Everything. Worked. First. Time. Everything, wirelss, ethernet, sound - it even managed to suspend properly! (something that has always seemed a bit flakey on linux). Anyway, I installed and a few weeks later she is as happy as larry.

    So, I'm sorry to say that linux is simpler to install than windows...at least from my experience.

    Oh, I left 'vista' on there too...just in case.

  163. Re:Attention all fifteen year old Slashdot kiddies by juanfgs · · Score: 0

    do it already.

  164. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Finding Windows drivers? Typical Linux zealot, your mind is forever frozen in the area of Windows XP. I installed Windows 8 on a 4 year old computer. Everything worked, including the Wi-Fi adaptor. The only driver I needed to install was for my Nvidia GTX 650, just so I could also have the Nvidia control panel and such. On the rare instance you need a Windows driver, they are easy to find unless you're completley incompitent.

  165. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Different AC here, but I'll help you out. He's referencing the fact that most Linux DEs look like shit rehashed from the Windows 95 era. About the only exception is KDE, but it's slow as a snail on ice on even the beefiest hardware. As for infections, for myself and many other users, they aren't even an issue. A little common sense, some basic computer literacy goes a long way. A small price to pay when you use the most widly used OS with the largest selection of commercial and free software.

  166. Re:And this is why Linux will never win the deskto by MikeBabcock · · Score: 1

    Compile any Linux binary as static and it will include everything it needs to run -- although 64-bit binaries won't load on a 32-bit system of course.

    In fact just the other day I was on an older system and I couldn't find iperf in its distro so I downloaded the pre-compiled 32-bit binary to do some quick bandwidth testing.

    As a company that deals with industrial customers, we have dealt with plenty of Windows software that will not run on anything newer than XP, or sometimes 7, or 98 or 3.1 before those.

    The Windows API is not a static target.

    --
    - Michael T. Babcock (Yes, I blog)
  167. Re:And this is why Linux will never win the deskto by Blaskowicz · · Score: 1

    Please, when you want to get a new version of your graphics driver or update something too big (say KDE, Mate) you end up replacing the whole OS. You can change window manager, terminal emulator or shell (ksh, zsh) etc. any time, but some fine grained stuff like choosing the version of a program you prefer to run is only possible on Windows as well as e.g. setting targets for fan control, looking for voltage drops - linux never allowed me to read ANY of the half dozen or so voltage sensors built in any PC, it doesn't even acknowledge their presence.

    It would be good to have a low footprint Windows clone to do the low level tasks that are just impossible on linux.

  168. Not that awful/scary by IwantToKeepAnon · · Score: 1

    Good. Forks are a good way for those who disagree to still get along. Debian and Forked-ian and still share patches (outside of the init process) and stay in sync easily ... if that is what they choose to do. So we will wind up with the choice of Debian-classic or Debian-with-sprinkles. Cool.

    This reminds me of GNU Emacs and XEmacs, they disagree (or lack legal rights to make code free) on the basics but a lot of the elisp is kept in sync. Choice is G(NU)ood.

    --
    "Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy
  169. Avoiding systemd isn't hard by Anonymous Coward · · Score: 0

    In Debian one can already choose between sysvinit, systemd, or upstart. See this http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html

  170. Re:And this is why Linux will never win the deskto by skids · · Score: 1

    This is not an option when you are talking about a 7 year old laptop. You cannot upgrade to either a modern cpu nor a modern graphics card.

  171. Re:And this is why Linux will never win the deskto by RavenLrD20k · · Score: 1

    They don't care about specs really, they don't care about merit. They care about branding and imagine (sic).

    WRONG. They care about *tasks* and *activities*.

    ...

    Notice that there's no mention of "Process random data at 50 gigaflops of megabuttz over a DDR3 EEPROM Ivy Bridge SSD, with WiMax Bluetooth EDR 4.0?"

    Specs don't matter to the average computer user...

    Um...you apparently missed the context of the parent completely. You even quoted the parent, called him wrong, then made the focus of your statement a point that agreed specifically with the part of the parent that you quoted; and all through that you completely did not show how the statement you quoted was in any way wrong.

    The main focus of the parent that he showed examples of is on the sentence "They care about branding and image." Your rebuttal included the list of things that people use a computer to accomplish:

    - Edit that spreadsheet from work;
    - Send an email to their kid in college 500 miles away;
    - Listen to some music or watch a movie (or both);
    - Edit some photos then upload them to Facebook;
    - Browse the web;
    - Write a paper;

    All of those things can be done on Windows, Linux, or Mac OS X. Which one a person uses is based completely on branding or image. The parent went into what most users would use based on their perceptions of specific brands. Most users would use MS Windows because that is "Normal" and "Conforms" to what they believe they should be using based on the requirements on the side of the box of the software they want to use for whatever they want to do. The ones who would use Mac OS tend to be the "hipster" type that want to appear different and call themselves superior to those who use Windows, even though they need to do all about the same things as their Windows brethren. The Linux/BSD crowd tend to be more independent thinkers than the above two, though they very well fall into conforming with themselves (for example, those who say "I use Debian. Yes it's Linux, but you'd never catch me dead using Gentoo." and vice versa.) These too will also get the tools to do all of the above functions from their package manager of choice, and have the heart and fearlessness to perhaps tinker with software under the hood

    Your post did not make any claim that refutes any of these points that the parent made and I have outlined... therefore you did not prove how you thought he was wrong in his statement that you quoted.

  172. Binary log files? Really? by nbritton · · Score: 1

    I don't like the ideal of binary log files, but I can get behind everything else.

    1. Re:Binary log files? Really? by Peter+H.S. · · Score: 1

      I don't like the ideal of binary log files, but I can get behind everything else.

      Well, just use rsyslog/syslog-ng like you always have. That way you have the usual flat file text logs while having all the other benefits of using systemd.

      Anybody having working with computers for a long time tends to be vary of binary formats. I have had a lot of bad experiences with binary formats over the decades. But using systemd's journal made me realize that what I really want is config files that are text based, and having binary data isn't such a big deal as long as it is an open standard and the tools are both standard and of high quality. systemd provides me with exactly that.

      All the standard Linux text tools like "grep" and "wc" etc. works perfectly together with systemd's binary journal, by using the standard Linux concept of piping, so nothing is lost, but many new features like having monotonic timestamps are gained.

  173. Re:And this is why Linux will never win the deskto by beefoot · · Score: 1

    I think you got a point. The "free" in open source means "freedom" to me. I'm free to choose what works for me. When comes to support, company could choose to support windows or redhat but it is almost impossible to support *my* linux.

  174. One question... by hitmark · · Score: 1

    Can Systemd be used to start one script that do all the actual starting etc, and just sit back and shut up?

    Right now Sysv init can be used to do just that. Get started by the kernel, then fire up whatever process is listed at the requested runlevel (said process will handle the rest). Then sit back and wait for the shutdown to the called.

    If Systemd can be used in this manner, it is a full drop-in replacement for Sysv init.

    --
    comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
  175. Re:And this is why Linux will never win the deskto by fluffynuts · · Score: 1

    Funny you should put it that way.

    I just installed a laptop for a 3-year-old who likes to play games out of my Steam library. It's running Kubuntu and he has no problems with it. It boots fast, plays his games well and generally gets out of the way whilst he enjoys himself. I'd hazard a guess that he's below the average user, he's running it as a desktop and he's made ZERO tradeoffs. And neither did I.

  176. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    ARE YOU KIDDING???

    I use my compiter for these tasks:
    1) Email
    2) Organize photos
    3) Web browsing
    4) Document writing

    I don't care about GPUs, LPUs, CPUs, or R2D2s... I just need it to WORK!

    For me, a 15-year old video card would meet all of my needs!

    Saying that a 7 year old video card is not useful is exactly the type of comments that I don't undersatdn about Linux cultists.

  177. nVidia - FreeBSD by trigggl · · Score: 1

    If nVidia would wake up and support FreeBSD properly, I would probably be switching a few machines to it. I want opencl first, though.

    Until then, I'm sticking with Gentoo. It doesn't matter to me if it's too difficult for others to install. Works just fine on my desktops (and anything else I want to put it on).

    --
    Ops, I shuld have usd the prevuwe but in.
  178. Re:And this is why Linux will never win the deskto by khellendros1984 · · Score: 1

    Please, when you want to get a new version of your graphics driver or update something too big (say KDE, Mate) you end up replacing the whole OS.

    Graphics drivers tend to have minimum requirements, same as in Windows. Minimum kernel version, libc, etc? Minimum Windows release, DirectX version, etc. Using an open-source driver, my package manager grabs the new module, usually along with the current version of the kernel. With a closed-source driver, the installer compiles the interface module and copies the files to the right places. It's hardly replacing the whole OS, just the kernel in the worst case.

    In replacing something large like the desktop environment, I haven't tried doing something like trying to get KDE 1.x running under a modern Linux, so I can't address it directly. I know two things though: it's more possible than getting the Windows 98 desktop working on a modern Windows.

    setting targets for fan control, looking for voltage drops - linux never allowed me to read ANY of the half dozen or so voltage sensors built in any PC, it doesn't even acknowledge their presence.

    YMMV, based on hardware support in the kernel, but lm-sensors supports a large list of drivers, including temperature, voltage, and fan speed sensors. I get readings on my machine, but I can't speak for yours, of course.

    It would be good to have a low footprint Windows clone to do the low level tasks that are just impossible on linux.

    More choice and more ways to do things is always good. I won't say that an actually-working Windows clone would be a bad thing. ReactOS didn't impress me, last time I tried to run it.

    --
    It is pitch black. You are likely to be eaten by a grue.
  179. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    What, no snarky retort after he mentioned a distro for you? Idiot.

  180. The problem isn't that it replaces init by Anonymous Coward · · Score: 1

    Most people don't even care that systemd replaces init. The binary logging is stupid, and the difficulties systemd adds for debugging broken systems suck. But fine, it replaces init.

    But systemd doesn't just replace init. Oh no, it wants to replace udev, dbus, and cron, and terminal handling, and file system mounting, and any number of other things that PID 1 should have nothing ever to do with. It's completely out of control. Gnome now needs it to login. How the hell can a window manager need to do anything with PID 1? It's horribly horribly broken.

  181. Good! by crhylove · · Score: 1

    I'll use it happily instead. The binary log files alone makes systemd a dead idea. The lack of being modular and doing one thing well would also make it a done deal, but I'd say that's secondary, though still high up!

    --
    I hold very few opinions. I hold information based on observation and fact. If you wish to disagree, please use facts.
  182. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    yeah, maybe if you'd installed one released AFTER that you wouldn't be talking such crap?

  183. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    but will it run office? (regardless of than answer businesses are scared of anything they didnt overpay for)

  184. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    Don't forget Windows 10, the tech preview is free - works fine in a virtualbox container...

  185. What about Debian Hurd & kFreeBSD? by aNonnyMouseCowered · · Score: 1

    If systemd is going to be the default init system on steroids, where will that leave the non-Linux ports of Debian, which prides itself in being THE "universal operating sytem" (go ahead Google for the phrase, first hit is Debian)? Insisting on hard dependency on systemd is going to creat problems for Debian Hurd and kFreeBSD, unless systemd has already been ported to those systems? https://www.debian.org/ports/h... http://www.debian.org/ports/kf...

  186. Re:And this is why Linux will never win the deskto by Alioth · · Score: 1

    If you're using an old machine, chances are you're not going to care much about 3D performance so toss the old graphics card and use the (very well supported) Intel integrated video that most machines have come with for a while.

  187. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    It's not odd. He's good and you're shit.

  188. Re:And this is why Linux will never win the deskto by carnivore302 · · Score: 1

    Max, is this you?

    --
    Please login to access my lawn
  189. Re:And this is why Linux will never win the deskto by Hognoxious · · Score: 1

    When I was having wireless issues on a new (to me) Thinkpad, I couldn't even get online to search for the problem.

    Does it not have an ethernet port?

    And don't you know better than to do any kind of major work on the *only* computer you have to hand?

    Installing a completely different distro ended up fixing those wireless issues. The Windows installation Linux replaced had no such issues.

    My Thinkpad was the other way round. No drivers available for WiFi (and sound) on Win7 - which ran like a three legged donkey anyway. Mint worked fine, likewise Backtrack. It's now happily running Kali.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  190. Re:And this is why Linux will never win the deskto by lsatenstein · · Score: 1

    Linux could work for the average user, at the end of the day there is no technical reason why not. After all Linux(in the form of android), dominates on the cell phone market, where the user base demands greater user friendlyness, has less patience, and wants even more bells and whistles, and is far less compitent with a computer. Linux has been shown to work marvelously with light meters, accellerometers, USB, touch screens(multi-touch even).

    The big issue is how consumers by technology. They don't care about specs really, they don't care about merit. They care about branding and imagine. They want their Apple(tm), search with google(tm). Advertising and public relations gurus over the last few decades have build reality distortion bubbles, where people actively identify with brand names. GNU/Linux has no such brand name. They really don't care about "just works". Face it, windows does *not just work*, but people do whatever it takes, because they think windows is what they are supposed to be using. Microsoft presents the image of normalicy and conformity that most people identify with.

    Apple on the other hand, presents an elitest artisan, fine craftsman, and intellectually supperior image, that marks the owner as part of an elite group.

    Linux cleans up serverside, because it rode the wave of start up culture of the 1990s. If you had a great idea for a new website, but didn't have much capital, you could run a proffesional website with Linux, Apache, Mysql, and PHP out of an old desktop for a fraction of the cost of what constituted a proffesional server, of the day

    As these companies grew, they continuted to use linux, and helped it transform into a proffesional class OS, that couldn't help but take notice.

    Linux will eventually take over the desktop, and the reason is because microsoft has no real friends, and they have an ever growing list of enemies. Many of those pimpleface teenage nerds they stepped on back in the 1990s are now grown developers and sys admins. Their day dreams are now multi-million dollar products. Linux has a lot of corporate backers, many of which are household names, and some of the largest most powerful corporations in the world.

    Whats eventually going to happen is that MS is going to piss off another giant like Google or Samsung to the point they want blood. You'll see a few large companies pour money, time, resouces, advertising into a distro with enough MS haters to accept them, and then use a Free as in beer product into the desktop market, to crush microsoft to prevent them from competing in other markets, by destroying their cash cow.

    There will not be a year of the desktop. It will be a decade of pure hell, and microsoft is going to fight tooth and nail, and use every dirty trick in the book to keep the desktop market. They will eventually loose, because the nature of FOSS allows many companies to quietly pool resources behind a single banner, especially a not-for-profit, and allows more to join later without any real effort or diplomacy. Eventually it will be taken from them, and from that point its another 10 years before they go out of business.

    The reason why MS will lose the desktop is closed source and closed mentality.
    Our universities want to teach operating systems, their use, design, and tweaking. In addition, to do so at zero cost for software. This is where Linux came in.
    We have students who have started in College/University with LFS (Linux from Scratch). They get to study internals, networking, security, end-user computing, servers and more. Included of course are the language courses in C, C++, Python, Perl, Bash scripting, etc. etc. And the students had the software and course material on their laptops.

    MS had restrictions on what information was available.

    --
    Leslie Satenstein Montreal Quebec Canada
  191. Re:And this is why Linux will never win the deskto by juanfgs · · Score: 0

    My ESR wants me to go to a cathedral.Or a bazaar. But I have to choose.

    Does he at least fetch your mail?

  192. XD by MiPen · · Score: 1

    "Debian's Systemd Adoption Inspires Threat of Fork" Wouldn't a Knife be more effective? XD

  193. Interesting by Anonymous Coward · · Score: 0

    Nobody complained about e.g. net interfaces being renamed? I would have guessed it would mess up a lot of firewall rules or routes...

  194. Re:And this is why Linux will never win the deskto by Anonymous Coward · · Score: 0

    I agree. I will point out one thing real quick though. WMIC is a GREAT tool on windows (included since xp or 2000). I quickly foudn the answer for my networking stuff by running wmic /? from command line. It listed my options and I saw one called NIC. Followed up with a "wmic nic get /format:list" and BOOM I saw each adapter and all the properties (specifically under ServiceName) about it that I would need to find a driver and place to USB drive. Now I know in the future that I can run "wmic nic servicename /format:list" and see that little RTL8167 or whatever that I need. :D

  195. Re:And this is why Linux will never win the deskto by cout · · Score: 1

    s/Windows/Ubuntu/

  196. Re:And this is why Linux will never win the deskto by vilanye · · Score: 1

    You forgot to add the 3 hours of the always enjoyable update/reboot cycle.

    And the running around to 80 websites to download software to make it usable.

    I can go from blank HDD to fully installed and patched opensuse 13.1 in 30 minutes.

  197. Re:And this is why Linux will never win the deskto by vilanye · · Score: 1

    Using generic drivers that come with the install results in hardware that can not be used to its full potential.

  198. Re:And this is why Linux will never win the deskto by davydagger · · Score: 1

    haha, you completely missed the point of my post, and went straight to the stereotypical tropes about overly technical linux users. Its like you didn't read my post, but just responded to what you wanted me to say.

    RavenLrD20k did a nice job tearing you apart below.

  199. Re: And this is why Linux will never win the deskt by Anonymous Coward · · Score: 0

    Actually those 600 are just flavors of the same distro. Not a real valid argument but eye candy differentiation. Start from giving proper name to things as they are. There is a handful of real separate distribution NOT debian cousins. Look for free gnu linux, one is based on Ubuntu some are on debian but with a purposine others from scratch (a real distro at that) and one from arch. But all are using your freedom os in mind. Paying no royalties to no king. Jeycoff