Forgot your password?
typodupeerror
Operating Systems Windows Linux

You Got Your Windows In My Linux 613

Posted by Soulskill
from the entirely-uncontroversial-opinions dept.
snydeq writes: Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD, writes Deep End's Paul Venezia. "Although there are those who think the systemd debate has been decided in favor of systemd, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise. I've seen many declarations of victory for systemd, now that Red Hat has forced it into the enterprise with the release of RHEL 7. I don't think it's that easy. ... Go ahead, kids, spackle over all of that unsightly runlevel stuff. Paint over init and cron, pam and login. Put all of that into PID1 along with dbus. Make it all pretty and whisper sweet nothings about how it's all taken care of and you won't have to read a manual or learn any silly command-line stuff. Tune your distribution for desktop workloads. Go reinvent Windows."
This discussion has been archived. No new comments can be posted.

You Got Your Windows In My Linux

Comments Filter:
  • by recoiledsnake (879048) on Tuesday September 02, 2014 @06:20PM (#47811597)

    What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?

    • by Virtucon (127420) on Tuesday September 02, 2014 @06:24PM (#47811641)

      Nothing really. It's just different. All of this sounds remotely familiar to the System V wars aka UNIX wars of the late 80s and early 90s. [wikipedia.org]
      That didn't solve much either except it allowed a company from Washington dominate servers and high-end desktops for awhile because it wasn't caught up in all of the holy war shit.

    • Re: (Score:3, Insightful)

      by machineghost (622031)

      Ummmm ... it's closed source. I'm sure there are lots of other good reasons, but do you really need anything more than that?

      • by Zeio (325157) on Tuesday September 02, 2014 @10:48PM (#47813621)

        Closed source isnt even the bar anymore. GPL lunatics crib about CDDL and a whole host of other licenses. I'd rather have closed source that works than open half-bake.

        systemd is breaking UNIX tradition - which is things may suck, but they suck simply. Now its a horrible mess. We now have (1) scripts, (2) openrc, (3) upstart and (4) systemd. What a sick joke.

        And the best thing I've seen so far to replace startup scripts is Sun's SMF... NIH alert! We couldnt have copied that - something that actually worked - no we need to have yet another method of starting things.

        Worse thing is eth0 is now en0p1FuK0001, drivers are modprobbed in random order, stuff gets renamed and moved around, and NetworkMangler aka NetworkManager is shoved down our throats.

        Its horrible. And its very desktop-ish.

        What do you expect from a guy whose magnum opus was a sound framework for linux. Yeah, thats the guy you want re-writing how everything starts and stops. Dont copy the guys who invented NFS or ZFS or stuff like that, copy the junk the sound guy comes up with.

        • by lister king of smeg (2481612) on Wednesday September 03, 2014 @12:52AM (#47814169)

          Closed source isnt even the bar anymore. GPL lunatics crib about CDDL and a whole host of other licenses. I'd rather have closed source that works than open half-bake.

          systemd is breaking UNIX tradition - which is things may suck, but they suck simply. Now its a horrible mess. We now have (1) scripts, (2) openrc, (3) upstart and (4) systemd. What a sick joke.

          And the best thing I've seen so far to replace startup scripts is Sun's SMF... NIH alert! We couldnt have copied that - something that actually worked - no we need to have yet another method of starting things.

          Worse thing is eth0 is now en0p1FuK0001, drivers are modprobbed in random order, stuff gets renamed and moved around, and NetworkMangler aka NetworkManager is shoved down our throats.

          Its horrible. And its very desktop-ish.

          What do you expect from a guy whose magnum opus was a sound framework for linux. Yeah, thats the guy you want re-writing how everything starts and stops. Dont copy the guys who invented NFS or ZFS or stuff like that, copy the junk the sound guy comes up with.

          Not just the sound guy, the sound guy that wrote the broken sound framework. Pulseadio is a horrible horrible system. I have taken to just purging it and using alsa and I then have audio system that doesn’t shit itself and become a zombie process when I unplug my headphones or try to run a program in w.i.n.e.. As for his other endevors network manager, has had major issues on several network cards have used so I ususaly scrap it and use wicd. From what I have seen SystemD does not look like anything I want on my systems either so when the time comes I will be considering my alternitives.It may just be the motivation I need to try out openBSD on my server, my desktop though I may go so far as to try out something like Gentoo or slackware.

        • by squiggleslash (241428) on Wednesday September 03, 2014 @07:24AM (#47815351) Homepage Journal

          We have four attempts to solve the same problem because we keep doing things badly. Script based services management, in my view, isn't a good thing, and it's also not a good thing to have multiple different clusters of service managers, init, inetd, etc.

          Let's look at the status quo that many systemd rioters want to keep: service management scripts generally have to track at least one process, and frequently clusters of them, and usually as the process gets more and more complex, have to be shored up with additional supporting code in the binaries themselves (think Apache's apachectl and BIND's rndc) obliterating any advantage you might have had in having a "user readable" shell script in the first place. Meta data is stored in the most unlikely places - anywhere from /etc configuration files to "comments" in the init script itself (think runlevels.) The kernel itself keeps advancing, with the wonderful cgroups system providing new and better ways to improve security, but we're stuck with chrooting and setuiding daemons because we leave the security decisions to our cross platform binaries.

          I'm not suggesting systemd is perfect (XML FFS?), but I think it's a rational response to what is actually a massive kludge and arguably one of the very few serious mistakes in *ix. Are there proprietary alternatives that are better? Maybe. Their proprietary nature means we haven't been exposed to their potential good points, if any, which is a great argument against proprietary software if you want to influence the world for the better.

          Were I to design systemd, it'd probably look slightly different. At the same time, I can't argue:

          1. With the need for systemd and the feature set it implements.
          2. That the status quo is worth keeping. It isn't.
          3. Superficial "This isn't the Unix way" arguments. Kludges are not the Unix way either. This is one area we need a change in.

          Finally, you didn't mention it, so not addressing your comment but addressing the other major criticism of systemd: Yes, the developers have social interaction problems. So does Linus, and half a dozen other major "personalities" we've always worked with. Hell, one key developer whose work was on the verge of being adopted by the FOSS world (and was adopted by at least one major distro) even killed his wife. I'll slam FOSS developers for their poor social skills if I think it's deserved, and even suggest in extreme cases that a fork might be desirable, but the code they write is there for the using, and if it's a good idea we use it, we should use it.

          In the mean time, let's not let the perfect be the enemy of the good enough. Is something that implements the featureset systemd implements necessary? Yes. Are there any non-proprietary alternative projects that implement the same necessary features? No. Does systemd do anything genuinely terrible that makes it impractical to use or worse than the status quo? No. It's good enough, let's adopt it, and let's make it better.

      • Considering the post is about design and usability, being closed source is not what the GP was looking for in terms of an answer.

        So yes, we're going to need more than that. Specifically, Linux seems to be moving more towards the design of Windows, at least according to this retarded article. Is that bad, and if so explain yourself.

        Otherwise, you're just not helping here.

    • by taustin (171655)

      The only legitimate complaint is that Windows requires beefier hardware to do the same job. Other than that, it's a matter of preference, and advantages for specific tasks.

      • by gandhi_2 (1108023) on Tuesday September 02, 2014 @06:34PM (#47811749) Homepage

        Not having to manage licensing... is a gift all its own. I'm not talking about not buying licenses, I mean not having to deal with ANY of that shit for servers... a blessing.

        • by Anonymous Coward on Tuesday September 02, 2014 @06:43PM (#47811837)

          Not having to manage licensing... is a gift all its own. I'm not talking about not buying licenses, I mean not having to deal with ANY of that shit for servers... a blessing.

          THIS is the reason I build so many linux servers. When you compare costs of a typical Windows based small business server vs a linux server, linux wins hands down. Unless there is a very specific reason to run a windows based server, I always run linux servers. No licenses to keep track of, no extra up front software expenses.

      • by squiggleslash (241428) on Wednesday September 03, 2014 @07:35AM (#47815403) Homepage Journal

        I completely disagree with the notion systemd is "How Windows does things", but still, let's suppose that's true: is it really true Windows requires beefier hardware to "do the same job"?

        services.exe has been around since Windows NT 3.x. On my Windows 7 64 machine right now it's occupying four megabytes of memory. init, running on a 12.04LTS box, is using six.

        I'm going to say I think both are within the same ballpark, which is what you'd expect, both are simply tracking processes (kinda, in the case of init) and stopping/starting them. You really don't need huge amounts of memory or CPU to do that, and it would take a pretty weird algorithm/feature set for any init/services equivalent to start gobbling serious amounts of memory.

    • by Brian Beaudoin (2848525) on Tuesday September 02, 2014 @06:30PM (#47811701)
      My experiences with systemd have been good and I can see how it can eliminate some of the kludges I've relied on in the past. Rather than have an /etc/init.d/myservice restart all related services to ensure a "clean" environment, I can list dependencies and triggers and rely on the system to do what is appropriate. It doesn't eliminate the ability to create or use System V init scripts, it just provides administrators with an alternative. Given the distribution creators have put a lot of effort into converting their scripts we have a lot of examples to work from. I've been working with UNIX since the 80's and rather than adopt a "get off my lawn" mentality I'm looking forward to embracing solutions to modern problems and see this as a positive step forward.
      • Holy fuck a Linux/Unix guy I'd shake hands with. This is the correct answer, folks :P The minute you get into a "get off my lawn" approach to technology is the day you sign your career's death warrant.
      • by whoever57 (658626) on Tuesday September 02, 2014 @06:53PM (#47811941) Journal

        Rather than have an /etc/init.d/myservice restart all related services to ensure a "clean" environment, I can list dependencies and triggers and rely on the system to do what is appropriate.

        So it solves a problem that Gentoo solved years ago in its script-driven init system?

      • Re: (Score:3, Interesting)

        by rahvin112 (446269)

        Almost everyone I've asked that has expressed hatred of SystemD hasn't actually used it. The vast majority either hate the creator or read some blog post, all but one had never used it or tried to understand it. I attribute much of the hatred to a "I hate change" attitude that is unfortunately common in the *Nix sphere.

        • by nabsltd (1313397) on Tuesday September 02, 2014 @07:34PM (#47812331)

          Almost everyone I've asked that has expressed hatred of SystemD hasn't actually used it.

          I've used it. I hate it.

          Ignoring the very real problem that putting so damn much in PID 1 is dangerous for system stability and security, systemd is generally OK for all distribution-supplied packages. But, if you have anything at all that the packagers didn't think of, it's a pain in the ass. For example, getting sendmail to not start until the clamd server is ready to accept connections isn't easy using systemd, but trivial using a standard init script.

          Also, despite the fact that dependencies are baked-in to systemd, it's not at all uncommon for a service that depends on an something else (service, NFS mount, etc.) to still start up before the dependency is fully ready, simply because the default systemd is to assume the dependency is fulfilled as soon as whatever "starts" it returns.

          Next, there is no easy way to copy existing dependencies to another service (which would be the best way to start creating your own), mostly because the systemd docs and examples simply suck.

          Last, the dependency system absolutely screams for a GUI interface to be able to follow and configure it, but when one finally is created (if it hasn't been already), it'll be useless on servers, because nobody with brains installs a GUI on the server.

          • by Grishnakh (216268)

            >Ignoring the very real problem that putting so damn much in PID 1 is dangerous for system stability and security,

            From what I've read, this isn't true, but I don't have an authoritative source for it. But, here's the really dumb part of your response:

            >Last, the dependency system absolutely screams for a GUI interface to be able to follow and configure it, but when one finally is created (if it hasn't been already), it'll be useless on servers, because nobody with brains installs a GUI on the server.

            M

            • by sjames (1099)

              That still requires a metric assload of libraries to be installed on the server. The bandwidth and latency requirements work OK enough for routine operation, but it really sucks when the problem you're trying to solve involves poor connectivity.

              And it absolutely won't work over a serial console.

          • nobody with brains installs a GUI on the server.

            And will someone PLEASE tell IBM and Oracle that?

            I like Systemd in concept. It potentially allows setting up dependencies from the outside, much as Inversion of Control does in software. Meaning that the systems don't need to know as much about other systems because it's wired into the overall system configuration. And, unlike init scripts, you can make the management of subsystems dependent on the actual state of other subsystems, not simply assume that because one was scheduled to come up before another t

        • by jedidiah (1196)

          Simply being the "new shiny shiny" means that it is untested and unproven. That's not something you just can casually gloss gloss over.

          This adversity to change is common to ALL professionally managed systems. It has nothing to do with Unix in particular.

          If it is anything like Upstart then it is a bunch of added complexity for no real gain.

        • by Aboroth (1841308) on Tuesday September 02, 2014 @07:43PM (#47812419)
          I'm really sick of reading that excuse. Whenever somebody doesn't like something new on computers, the people who do like the new thing immediately jump to "well it's just because you don't like changing."

          This was easily the loudest, most repeated response to somebody hating the Metro interface on their desktop, and it should be clear by now that sometimes, avoiding change isn't the primary reason why craploads of people hate something new. Sometimes the new thing just... sucks.
        • by ArhcAngel (247594) on Tuesday September 02, 2014 @09:46PM (#47813267)
          I haven't used it and I love it!
          Watching the VI EMACS holy war has grown long in the tooth and we really needed a new holy war to spice up the community!

          LONG LIVE SystemD!
        • I've used it and could list SystemD's various technical issues, but that isn't and never has been the point.

          The complaints we have about SystemD - and the Poettering cabal in geneal - is not about any technical issues. Bugs can be fixed; bad design, antisocial not-invented-here attitudes, and disregard/blindness to any use case outside their experience are what we have been complaining about. After about 2 years of arguing the topic, we've had to add rudeness, blatant propaganda, and attempts to bully opposing views to the list of complaints.

          Typically, SystemD defenders - such as yourself - spend a lot of time and effort disrupting forums and discussion threads by posting strawmen, non-sequiters, or simply praising SystemD as it applies to very narrow use-cases. Recently, the tactic has bene what you are doing right now: accuse the opposition of being "old" or "luddite" or "hating change". It is quite telling, actually: a big complaint against SystemD's development style (as mentioned in this article if you bothered to RTFA) is that they don't bother to understand how people outside their immediate group actually use their computers, or what their needs are. Comments like this are exactly what we're talking about.

          Nobody has been saying systemd should be banned or that you wanting to use it is bad. Nobody has said OpenRC or sysvinit should be the only option. If some tool solves problems for you or make your life easier - or even if you just like the tool's style/asthetics - then use it. What we're complaining about, more than anything else, is the tight coupling that SystemD has been doing, as it prevents everbody else from having that same freedom of choice.

          Once, a very long time ago (internet years) when an image of a certain borg-ified CEO was common, there was a phrase that was commonly used to describe Microsoft's monopolistic actions against competing technologies: embrace, extend and extinguish [wikipedia.org]. Many discussions on slashdot warned about how Microsoft was trying to "embrace and extend" various standards such as Kerberos [drdobbs.com].

          So instult us if you like - it makes our arguments against SystemD's attitude for us. You can even sit in ignorance, if you desire, while Poettering embraces and extends linux so he can remove all the useful parts form it. The rest of us that have watched this happen before will continue using Free Software that preserves freedoms such as the freedom to choose your init system. We have been marginalized and a social outcast in the past and are used to crap like this. Just remember that it was that same freedom of choice that provided a place for SystemD to be developed in the first place.

        • by sjames (1099) on Wednesday September 03, 2014 @03:16AM (#47814567) Homepage

          The damned thing insists on being PID 1. The more crap it kitchen sinks into itself, the more often and likely it will need a security update. That's a reboot. If I wanted to reboot every day, I'd run Windows 95.

          The dsame services runninmg seperately and not as pid 1 can easily be updated/upgraded at will and restarted without messing with the whole system.

          The 'old' init is a very simple program. It does what it must do and no more. It doesn't see a lot of change at all. As a result, it doesn't cause any problems It just stays out of the way quietly listening for a command to change runlevels, respawning the occasional getty and dealing with child processes that lose their parent.

          Systemd COULD have been implemented as pid2, spawned from init. Of course that wouldn't have supported the hidden agenda to take over everything. Surely you don't think it's a coincidence that the gnome desktop suddenly developed a hard dependency on systemd when it has been running without it for years.

      • by Korgan (101803) on Tuesday September 02, 2014 @07:11PM (#47812147) Homepage

        If it was just replacing the /etc/init.d mess, that'd be fine.

        My main problem with SystemD is that it is turning into this massive black hole that's trying to replace many different systems in one. And not very well at that.

        Why replace pam.d, crond, init, and add complexities like dbus in a single package that runs at PID1 when it doesn't need to? So now a single flaw in its crond could allow a vector that lets dbus provide a way to trick pam.d into letting users escalate their privileges? Sure, it hasn't happened yet, but when you start intertwining these apps into a single super app....

        Worse, the logging it provides is next to useless. If I have a headless server with no GUI, how the hell am I supposed to read binary logs? It doesn't even give me useful information during the boot process. At least my old init scripts could do that much.

        It completely goes against the core principles of UNIX in general. Do one thing, and do it damn well. Make it interoperable with other processes. Log to text. Configure with text.

        I don't want this massive beast of a process that replaces my options. And I especially don't want one that isn't even very good at performing the original single task its supposed to be replacing, let alone all the franken-tasks its taken on.

        If this were just about replacing init, I doubt I'd be anywhere near as bothered. But as an active admin, this bothers me significantly more than just having to redo my startup scripts.

        • by Zeromous (668365)

          Now this is it. Do it once and do it well every Unix prof i know used to say. Damn kids. Im selfish though I just want portable scripts.

        • Why replace pam.d, crond, init, and add complexities like dbus in a single package that runs at PID1 when it doesn't need to?

          Because confident young men in a hurry to make their own mark on the world have little time for learning the tools or the lessons of the past.

      • by SumDog (466607) on Tuesday September 02, 2014 @07:19PM (#47812217) Homepage Journal

        But OpenRC (Gentoo) does dependency management without having to replace init.

        Now systemd does give you a lot of advantages when it comes to fully managing processes, respawing and dbus/alerting. But that's also part of the problem. It connects to EVERYTHING. And if one of those things breaks or has a security flaw, you could pass messages around and compromise systems.

        Not to mention the command line tools SUCK.

        Sys V: /etc/init.d/ (stat|stop|restart)

        Upstart: (start|stop|restart)

        Systemd: systemctl restart .service

        And you get ZERO output. You have to run journalctl -n or systemctl status right after it. Who the fuck thought that was a good idea?! A widows developer?

        • by r_naked (150044) on Tuesday September 02, 2014 @07:35PM (#47812339) Homepage

          I hate posting a "me too" post, but you nailed it. Who the FUCK thought that having to run a separate command to find out if your service started was a good idea?!?

          I work in a shop that has ~2000 Red Hat servers / VMs, and my advice will be to switch to something else unless Red Hat gets their heads out of their asses, and gets rid of systemd. Unfortunately we don't really have the option of moving to FreeBSD (tooooo much code to port), but I am sure their will be a distro that fills the void. At least we have a few years to worry about it since 6.x is supported for a few more years -- hell I might fork the final 6.x release.

    • by DoomSprinkles (1933266) on Tuesday September 02, 2014 @06:36PM (#47811755)
      What us geeks dislike about it is much the same reason we dislike systemd: its an abstract layer between you and the configuration of your services/daemons. We like init.d in that we can script those daemons and even add on to those init scripts if we choose. Where as windows services puts this wall between you and that sweetness. And systemd is pushing us in that direction and OP's last comment in the summary is ringing more and more true.
    • What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?

      In windows nothing because it fits the windows way of doing thing but it is horrible when you have a OS based on the UNIX philosophy, well not so much. The Unix design philosophy as described by Doug McIlroy (the hacker that wrote the unix pipes)

      (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
      (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. (later he summarized this as "Write programs to handle text streams, because that is a universal interface")
      (iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

      SystemD violates every single tenet of Unix system design, for no benefit.

      Instead of doing one thing start a system like System V init, SystemD takes the kitchen sink approach and does many things badly.
      instead of using interoperable text streams for output log and

  • by jerpyro (926071) on Tuesday September 02, 2014 @06:24PM (#47811635)

    Some of us stopped using Red Hat when the NetworkManager mess came out with RHEL 6.
    Why would we expect RHEL 7 to be any better?

    You RedHat fans have fun with your "RedHat Vista" release. :P

    • by Zocalo (252965) on Tuesday September 02, 2014 @07:18PM (#47812197) Homepage
      Likewise. In the process of migrating a considerable proportion of a large RHEL estate over to BSD here. A general lack of satisfaction with RHEL6 started our look at alternatives - including other Linux distros - but SystemD was our deciding factor in the making the slightly more drastic leap from Linux to BSD. Despite the dream of Linux on the Desktop, most of us are actually running Linux on servers with (hopefully) competent personnel, so we don't really need some cuddly desktop OS that needs to pander to the lowest level of luser or the additional cruft and abstraction layers that brings, let alone the mess of package dependencies that seems to be afflicting Linux at present. In some cases we're seeing significant perfomance gains for what, in theory, should be the same basic set of code so for us it's more performance for less cost, and possibly an interesting call with our RHEL rep when the first tranche of RHEL licenses come up a renewal we are not going to need...

      The King is dead, long live the King!
  • The Future! (Score:5, Insightful)

    by elysiuan (762931) on Tuesday September 02, 2014 @06:28PM (#47811681) Homepage

    Oh day of days! Now it needs to statically link in gconf and we'll all have a registry too!

    Is anyone really concerned about this? Let me put on my prophetic wizard hat and predict how this is going to go from here:

    1. Systemd isn't going anywhere. The distros that use it will largely continue to use it.
    2. Enough people hate Systemd enough the motivation to create some distros that absolutely do not use it will be very high.
    3. Such distros will be created (Maybe use nixos/nix/guix as the base for extra change-it-up-ability.).
    4. Much like Mate/Cinnamon vs Gnome 3: people will use both the systemd distros and the systemd-less distros.
    5. Much gnashing of teeth will ensue for years to come. A la emacs vs vim, kde vs gnome, gnome 3 vs gnome 2, etc ad nausem

    I'm really not trying to be flip but this is just the FOSS process at work here. It's messy sometimes but so is anything that involves people. Embrace the ecosystem that makes this whole argument possible! If Apple or Microsoft decided they want some polorizing system like Systemd to be the new hotness in their OS offerings there's literally fuck all we could do about it. At least with the FOSS environment we have the freedom to make our own decisions

    • Re:The Future! (Score:5, Insightful)

      by Lotana (842533) on Tuesday September 02, 2014 @06:43PM (#47811843)

      Great! That is all we need. More fragmentation in the community! As if choosing a distro wasn't confusing enough as it is for newcomers!

      THIS is the reason why Linux will never be a mainstream desktop.

      • Re: (Score:3, Insightful)

        by Skarjak (3492305)

        The fragmentation argument is a terrible one, and always was. User's who aren't too technically literate don't know about any linux distro but the one they're using. Hell, how many people out there know what ubuntu is but have no idea what linux is? How would these people even know that a new distro came out which doesn't use systemd, if they're not already a huge nerd? As for newcomers who are more technically literate, just pick ubuntu. It works. Or one of the other big ones if you really want to tr

        • by dpilot (134227)

          I run Gentoo, one of the less-used distributions. I chose it exactly because it was a geeky, nuts-and-bolts distribution. After all, at the time Linux was a hobby, and if you're in it for that kind of fun, go for it.

          At the same time, I generally advise against using Gentoo. Unless you know why you want to use it, don't. New users should use something like Ubuntu, which I've installed for several people, or more recently Mint, which I've also done. We use RedHat at work because it's "Enterprise" and has

        • Re:The Future! (Score:5, Insightful)

          by Lotana (842533) on Tuesday September 02, 2014 @11:08PM (#47813731)

          I respectfully disagree. Fragmentation impacts both developers and the end users.

          Developers:
          There are a finite pool of people that have the knowledge to improve/write software. That group is further divided down into those that have the time and motivation to contribute to the open-source software. From there they are further divided among the competing projects that are doing the same thing. Example: GNOME 3 vs Cinnamon vs MATE vs KDE vs Trinity. Debian vs Red Hat vs Arch vs Suse vs Slackware. Therefore this fragmentation needlessly reduces the pool of available contributors.

          Also, any software package needs to be maintained for so many different configurations. A very good example is the package management: Debian, Red Hat, Gentoo, Slackware each have their own package format. This fragmentation adds more boring workload on the maintainers. Now that we will have distributions with or without systemd, it means that if the software deals with the area affected, TWO versions need to be developed! Doing something twice is again wasted effort.

          End User:
          Fragmentation adversely affects the user because the software he/she needs may not be available for the configuration that it being used. It is hard to come up with example for systemd since it is such a system-level system. Much easier to use an example of window-manager fragmentation: A certain package may look terrible on the one that the user chose.

          Even if the software is available, documentation may be only written for another distribution.

          Finally, the user needs to choose a distribution to start with. The choice is literally overwhelming. Have a look at this timeline: Distribution Timeline [wikimedia.org]. Now imagine it exploding even further into systemd using/rejecting versions. That much amount of choice is paralyzing.

          In the end, fragmentation just wastes resources on doing the same things more than once. It is necessary if the constrain is quite severe, but right now in the community forks happen over something as trivial as library versions or the visual look!

        • by Endymion (12816)

          The fact that systemd is causing fragmentation - arguably worse fragmentation than any previous disagreement in the Linux community - is a valid (though not particualrly interesting) argument, because a primary design goal of systemd is conformity. Poettering has stated many times that his goal is to force distirbutions to use his one-true-way, and he often uses the supposed complexity of having to write portable code as an argument for why systemd and nobody else should be the software that manages the "co

      • THIS is the reason why Linux will never be a mainstream desktop.

        No I think it's a strength. When MS forced Me, vista, Win8 on it, we recoiled and puked, but some people were forced to use it because they lacked options.

        When Ubuntu forced Unity on us, we all just dropped Ubuntu and carried on. There has definitely been a loss to the community, Ubuntu was a solid distro for a while, but it's gone, and we still have options.

        For Mom and the unwashed mashes, the iPad does what they need it to do (i.e. very littl

    • ecosystem, but for working tools. Democratic messiness is great when it results in working tools. But as an end in itself, in software development? Meh.

    • Re:The Future! (Score:5, Insightful)

      by Kjella (173770) on Tuesday September 02, 2014 @07:16PM (#47812183) Homepage

      If Apple or Microsoft decided they want some polorizing system like Systemd to be the new hotness in their OS offerings there's literally fuck all we could do about it.

      Would that be "fuck all" as in "buy something else", "don't buy at all" or "insist on the old version"? Tanking sales tend to have a very correcting effect on for-profit companies, assuming there's competition to speak of. Sure, I can't decide what that company will do but I can't decide what that OSS project will do either and while I can theoretically fork and maintain my own version it's not really a practical possibility 99.9% of the time. If there happens to be enough people dissatisfied with the direction it's taking to make a fork that's fortunate for me but really outside my control too.

      I've been watching Gnome/KDE trying to battle Windows now for the last 15 years or so and making so little progress YotLD has become the running joke around here ever since Duke Nuke'm Forever shipped. Then I look at Android which is more cathedral than bazaar and it's gone from nothing to 85% world wide market share in 6 years. And the absolutely greatest success the Linux kernel is run like anything but a bazaar, lieutenants are from military hierarchy and it has one general on top - or benevolent dictator for life if that sounds better. Sometimes picking one direction - even if it's not the absolutely best one - beats taking no direction or pulling in ten different directions. Heresy, I know.

  • Dun matter (Score:3, Insightful)

    by Conceptualizing (3785843) on Tuesday September 02, 2014 @06:32PM (#47811725)
    "[...] the exceedingly loud protests on message boards, forums" - and all other places that don't matter
  • by Anonymous Coward on Tuesday September 02, 2014 @07:04PM (#47812065)

    My main problem is that the old init system was dead simple to administer. You only needed to know basic shell scripting as well as grep and you could figure out most things you ever encountered. Systemd again is a horribly complicated program that probably no one except the developers understand inside out.

    It seems to me like this whole systemd/upstart etc. nonsense started when someone wanted to make machines boot up faster. The problem is that in today's world how fast a machine boots is completely irrelevant. On VM's you can clone a running machine, so how the OS starts is unimportant. A classic server is always on and rarely gets booted. Laptops, which seemed like the obvious target, are typically just suspended to disk, so they rarely run through the whole boot process. Desktops are typically sleeping too when not in use.

    In other words, I still haven't figured out why anyone would need systemd. I've never had a reason to need it. I've only had reasons to hate it when something that used to be very simple is now hidden behind some complicated shell commands.

    • by guacamole (24270)

      You bring up a very good point when you say that the boot time is irrelevant, even on most desktops and laptops. All of my personal desktops and laptops, regardless of OS, reboot only when system updates or software have to be installed. Otherwise, the machine goes to sleep or suspend to disk, often going weeks without a reboot.

      "Fast boot" is now often being used as an excuse to push otherwise unpalatable technology. Not just in Linux. I have heard many times from Windows 8 apologists "but it boots faster",

  • Edit much? (Score:5, Funny)

    by Yaztromo (655250) <yaztromo@ma3.14159c.com minus pi> on Tuesday September 02, 2014 @07:05PM (#47812079) Homepage Journal

    "Although there are those who think the systems debate has been decided in favour of systems, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise.

    "Although there are those who think bacon is tasty, a loud protests I've posted recently on message boards, forums, and here on /. over the past two weeks would indicate otherwise."

    (Yeah, I've been here long enough to know that nobody at /. does any actual editing. Still, can I make fun of the submitter for making it sound like (s)he's the one who is going around and posting all the loud protests, and then trying to make it seem like some sort of movement?)

    Yaz

  • by Art3x (973401) on Tuesday September 02, 2014 @07:38PM (#47812373)

    I would be interested in the anyone's response to Lennart Poetterings rebuttal [0pointer.de] to the common complaints about systemd.

    I'm too n00b to know who's right.

    • by Anonymous Coward on Tuesday September 02, 2014 @08:37PM (#47812921)

      Overall a good read for people who are against systemd, in case they are against it for the wrong reasons. However for me it rings hollow:

      monolithic:
      " we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.". The design of all of them is inexorably linked. The component that lives as pid 1 is more complicated than what formerly lived as pid 1.

      speed:
      whether intended or side effect is a moot point. This should in no way be held as a point against systemd. I presume he's trying to address how dismissive some people are about systemd. He's right, it isn't about speed, it's about more complex issues.

      boot speed is needless for servers:
      Yes, there are some use cases where boot speed can be good in a server context. There are many more cases where it does not matter. It's silly to tell someone that boot time isn't a big deal to them that it really is. A sysadmin knows damn well which case his falls under.

      systemd and init scripts:
      "We just don't use them for the boot process, because we believe they aren't the best tool for that specific purpose" Here he misses the point. The complaint is not that people cannot use their own shell scripts, it's that they are now repsonsible for supporting third-party non-scripts by others more than they already have to.

      systemd is difficult:
        This is a point where it's nearly impossible to retain perspective. as the archtect of systemd of *course* it all makes sense to him. The issue is that other people who are not in that position take issue with it. His rebuttal basically boils down to 'nuh uh, I understand it fine!'

      systemd is not modular:
      " At compile time you .." I think that speaks voulmes right there... Compile time modularity is not the worrisome demonstrative facet, runtime modularity is.

      systemd is only desktops:
      true, their intent covers servers and in fact some features that only really appeal in a server. Much of the sysadmin base disagrees, but this is a subjective matter.

      Myth: systemd was created as result of the NIH syndrome
      They tried somehting else first before thoring up their hands and going NIH. Again, a moot point, the results matter more than the beginnings.

      systemd is a fdo project:
      Who the hell cares whether it is or isn't?

      systemd is not unix:
      strictly the myth is true, but linux is not unix either. The statement being addressed is that systemd is a departure form the unix-like ways. This is undeniably true, just differnt audiences have different opinions on the value of that.

      systemd is complex:
      He made it, so he understands it better than the stuff he did not make.

      systremd is bloated:
      What moist people mean here is feature creep, not resource consumption

      not nice to BSDs:
      the complaint is really not nice to people who administer both platforms, not that BSDs are themselves maligned,

      there are a lot of oversimplifications about porting it to other places, but I think people don't WANT it ported, so that's a lot of evangelizing to a group that does not exist.

      not debuggable:
      it is debuggable... if you are a developer.. again failure to keep perspective of many sysadmins.

    • by psyclone (187154)
      Interesting, it's nice to know that you can still use syslog along side systemd's journald. From the limited remarks, it appears you still get full syslog output.
    • by grcumb (781340) on Tuesday September 02, 2014 @11:33PM (#47813853) Homepage Journal

      I would be interested in the anyone's response to Lennart Poetterings rebuttal [0pointer.de] to the common complaints about systemd.

      I'm too n00b to know who's right.

      Full disclosure: I do not like systemd, although that judgment is based on its merits as I see them relative to my needs.

      There seemed to be a pretty concerted determination not to get the point in Lennart's long spiel defending the system. As someone who has been using Unices in anger since the early '90s, I've pretty much seen Linux grow from its infancy. I've seen this kind of attitude before in technology — in Windows, Linux and elsewhere. The article is clearly written (and written clearly) by someone who's clever, articulate and... far too concerned with being right. It's not a healthy perspective.

      Being technically correct is not generally optional. It's just not ever nearly as conclusive as some people think it is.

      Having the humility to accept an imperfect universe — and to admit that it's imperfect in a particular way for a large number of particular reasons — is a virtue that fewer and fewer people seem to possess these days.

      (It's the lack of this virtue that makes people say, for example, 'less and less' where I used 'fewer and fewer' and when someone corrects them, they trot out the grammar nazi epithet and say, 'Everybody knows what I mean. Deal with it.' And the lack of this virtue as well that will make people pick on the triviality of this example to discard my entire post. The temerity of such an approach cannot be explained to those who suffer from it.)

      Systemd is clearly not change for change's sake. Lennart and the dozen and a half others who have commit rights are clearly scratching an itch. But regardless of the technical merits of the system, it is horribly, horribly wrong to impose this new system —any new system— on Linux wholesale without a significant maturing process. And by significant, I mean years.

      And this is where Lennart's most completely mistaken. He thinks that the technical arguments are the decisive ones, in spite of the fact that technical merit is not why systemd is going to become prevalent. He therefore tries to write a technical opus in defence of the indefensible, which requires more than a few straw men (binary config files? shyeah....), several big ommissions (binary log files) and a clearly unwilled but nonetheless unforgivable ignorance of the fact that he's winning because he's RedHat, not because he's better. (Yeah yeah yeah, it's not all RH; it's others too, you're technically awesome - I read that part and remain utterly unconvinced by the argument.)

      Paul Venezia's screed, on the other hand, is just plain substance-free. He's not arguing either technical merit or political power. He's simply looking at a looming mess and saying, well, that it's going to be messy. And to that extent, he's right. Systemd is going to make a mess, and that's precisely because its proponents think that they're perfectly within their rights to claim, 'Well, nobody's forcing anything on anyone.'

      What they don't realise is that that is not how cooperation works. And believing you're better or righter than others is an absolutely shit way of improving your own software.

    • by sjames (1099) on Wednesday September 03, 2014 @04:55AM (#47814901) Homepage

      Here we go:

      1: If it *ISN'T* monolithic, why won't Gnome work wiothout it and why aren't the pieces available seperately?

      2: If it isn't about speed, why is that all people talk about? What is so 'right' about the way systemd does things?

      3: Servers start fast enough without systemd. In the cases where they need to start faster than is typical, they also tend to run ONLY the critical sevrice (ans so already start fast) OR they start the critical service first (and so it's also not a problem). The argument about VMs is entirely specious. The same services must be started either way, so the same I/O and CPU load has to happen one way or another.

      And as for 'socket activated containers', it's called (x)inetd and we've had it for decades now.

      4: The problem is that often server admins just need to make a small change to the standard shell script that starts a daemon in init.d. Except with systemd, there may not be one unless the distro was smart enough to effectively sidestep systemd by making it start rcS only and sticks with the scripts.

      5: Are you freaking kidding me? Where's the howto? Where's the overview? Where's the freaking manual? Most of it is of the nature of 'absolutely true thing isn't REALLY true because OHH look, a bunny! (run away)".

      6: I'd rather not recompile every time I want to re-configure my system, thank you very much. The modularity we're after happens at runtime, not compile time. Kinda like in the kernel, I don't have to load the modules I don't want.

      7: It all kinda falls apart once 1-6 are dispelled. It adds unwanted complexity and dependencies to the server. A perfect recipe for disaster when things are going badly and the server is hours away by car.

      8: Nothing systemd does couldn't have been done using a few helper apps. Had it been done that way, nobody would have a single objection to it. So why wasn't it done that way? That's right, NIH.

      9:Well, let's see. It's hosted there, it's developers talk the same talk, and it's all been snarled together into a single dependency ball......

      10: Only someone who never grasped that Unix is about small parts that do one thing well tied together through scripts and file-like objects could have written that.

      11: A few big honking packages is certainly not simpler than a series of small and largely independent packages. It's a question of how much you have to know in order to do a simple thing. Small packages always win that question.

      12: How big is init? Because in Unix, that's the part that has to be loaded. All the rc scripts do their thing they go away. They don't stick around after they do their job. In systemd, most of it insists on staying for some reason.

      13: The problem is that it creates a moral hazard. It invites other unrelated things to become dependent on it (like gnome of all things) and so, not compatible with BSD. And BTW, a lot of us Linux folks don't want it either and don't appreciate the dependency trap being used in an attempt to cram it down our throats.

      14: You're ACTUALLY arguing that since they worked so hard, what's a bit more? REALLY?!?

      15: So there's so many dependencies it's even trapped itself? That doesn't sound like a feature to me... I thought you said it was modular, not complex and not difficult!And didn't you claim it was Unix? BSD is Unix and you're telling me it is intrinsically incompatible? You say there are far too many dependencies and it is all too complex to port? Do YOU even believe what you write?

      16-17, no comment

      18: So in other words, it IS feature creep!

      19:Heh Heh. It's not like you HAVE to breath or anything. You could always hold your breath forever if you don't like my farts. I'm sure it is pure coincidence that other freedesktop projects have developed a hard dependency on systemd when they clearly never needed it befiore.

      21: Yeah, it's all perfectly compatible as long as you do it our way rather than the way you did it before.

      24: Compared to init, that IS buggy and unstable

  • by Culture20 (968837) on Tuesday September 02, 2014 @09:10PM (#47813085)
    I'll use a "server" distro on my laptop before I'll ever use systemd.
  • by dbIII (701233) on Tuesday September 02, 2014 @09:54PM (#47813313)
    Currently ZFS on FreeBSD is rock solid with high performance, while on linux it's not up to that point as of mid-2014. In the space of file servers that's a good reason to change for now.
  • by silfen (3720385) on Tuesday September 02, 2014 @11:25PM (#47813805)

    The problem with Windows isn't what it is trying to do but how it is trying to do it: the highly interdependent object-oriented libraries, the widespread use of C++ for basic services, bloated functionality in everything from the file system to the mouse. Even if every single daemon and server in Windows were superior to Linux individually, the entire system would still be crap because of that.

  • by stoploss (2842505) on Wednesday September 03, 2014 @12:31AM (#47814129)

    Init was simple, but it left me pining for proper dependencies among daemons. I mean, more than simply trying to stipulate a runlevel loading order by numbering symlinks.

    For example, I don't want samba to start unless iscsi is successfully up, etc, etc, and I don't want to code a bunch of one-off scripting in various daemon script files. There are many more instances just like this, and init doesn't handle the use case.

    Services are one thing (dependencies, monitoring service status, etc) thar Windows got right. I didn't like the glue / bootstrap code and installation for services, but it's far closer to what I want than init. Solaris' approach also seemed nice, at least upon cursory examination.

    Anyhow, systemd gives me what I have always wanted, at the cost of me having to learn a new approach. That's a fair trade.

    I hate Gnome 3, Unity, Metro, the last 3 years of "improvements" to Google services UX, etc. Conversely, systemd honestly feels like an upgrade in practically every way.

    Seriously, can someone tell me what horrors caused by systemd that I have overlooked?

As long as we're going to reinvent the wheel again, we might as well try making it round this time. - Mike Dennison

Working...