Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday November 10 2015, @05:22AM   Printer-friendly
from the love-it-or-hate-it dept.

Phoronix reports the systemd developers are having their first conference. Here is a direct link to the YouTube video channel.

Whether you love systemd or hate it, it looks like it's not going away. If you dislike it maybe one of these videos might change your mind.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by Anonymous Coward on Tuesday November 10 2015, @05:48AM

    by Anonymous Coward on Tuesday November 10 2015, @05:48AM (#261101)
    (Yeah, that's right, I said it.)

    The core is very competent and robust, and it actually runs pretty fast, but the interface is ghastly, and the software engineers and project managers are some of the most divisive pricks in the industry. It's only normal for them to surround themselves with complete sycophants at their dog-and-pony show.

    One of the key differences is that while Windows 10 is surrounded by a fortress of proprietarity to guard its incompetence, there's more influence able to shape systemd into something remotely sanely manageable. It's true that Red Hat is Pöttering's employer, and they, along with Canonical and Debian, are the major distro forces circling their wagons around the systemd camp, but it doesn't mean that us Linux users and coders are supposed to "accept things the way they are, because this is the world we live in." Save that talk for Microsoft's Windows 10 Defense Force (while the project manager of Windows 10 "spends more time with his family" [infoworld.com], similar to (but not exactly like the departures of) his predecessors Steven Sinofsky, Bill Veghte, and Jim Allchin. (Anyone noticing a pattern here?)

    Personally, I prefer distros that run rsyslogd alongside journalctl, and I sigh at how byzantine the whole dot-file hierarchy is. The last time we had an object-oriented programmer create a shell, we got PowerShell (complete with gratuitously hyphenated commands, complete with an asinine moniker of "commandlets"; someone doesn't understand how nauseating Java's smarm-fest lingo had become in the early-2000's, let alone the late-2000's).

    I can't wait to see the intersection of systemd and a half-decade of practical application, complete with a heaping helping of utter contempt for any of the freedesktop.org BS.

    Starting Score:    0  points
    Moderation   +5  
       Insightful=5, Total=5
    Extra 'Insightful' Modifier   0  

    Total Score:   5  
  • (Score: 2, Insightful) by Anonymous Coward on Tuesday November 10 2015, @06:05AM

    by Anonymous Coward on Tuesday November 10 2015, @06:05AM (#261109)

    Not that you're old, but being able to comment about early 2000's Java means your at least older than LP. We need more insight from the older coders, because the kids nowadays are growing up with shiny tools that make them spoiled and want to build systems that do the work for them. Nothing inherently wrong with that attitude, but caution is needed because they may just run everything into the ground. Older coders generally have a better understanding of efficiency and how easily an elaborate tower can be infiltrated...

    • (Score: 0) by Anonymous Coward on Thursday November 12 2015, @06:21AM

      by Anonymous Coward on Thursday November 12 2015, @06:21AM (#262060)

      There are those that are his age that also question his actions.

      The difference perhaps, is that some learned early on the difference between "can do it" and "should do it".

  • (Score: 5, Insightful) by Whoever on Tuesday November 10 2015, @07:19AM

    by Whoever (4524) on Tuesday November 10 2015, @07:19AM (#261124) Journal

    I suspect that there are some real advantages in using Systemd, but only a very small number of people actually want or need those features. The problem is that it is being shovelled down the throats of all Linux users.

    I have had arguments (mostly on the other site) about the usefulness of systemd and, I don't think anyone has been able to show an advantage of systemd that can withstand my criticisms. But I accept that there are use models that I don't consider, where there are possible advantages.

    Supporters will say things like "It manages and automatically restarts services", my answer: "services don't die and if they do, there is probably something more serious wrong and re-starting the service is likely to make things worse", etc.. For me, Systemd fixes a bunch of non-issues. It fixes problems that simply don't exist. People point to its speed starting up network interfaces, but gloss over the fact that the delay in traditional init systems is usually due to performing checks not done by systemd: checking that the same MAC address or the same IP address do not exist on the network (and, like systemd, these checks can be bypassed in traditional init systems also).

    • (Score: 1, Interesting) by Anonymous Coward on Tuesday November 10 2015, @08:18AM

      by Anonymous Coward on Tuesday November 10 2015, @08:18AM (#261134)

      I suspect that there are some real advantages in using Systemd, but only a very small number of people actually want or need those features. The problem is that it is being shovelled down the throats of all Linux users.

      Oh, there are many. Just as many as there are real advantages in using IOS.

      But for whom those advantages outweigh the disadvantages, Apple and Microsoft already offer everything you could want.

      Where as for those of us that want the flexibility of a system where you can replace any piece, consisting of small tools coupled together with shell scripts, the choice until now was only Linux or *BSD. And of RedHat and Pottering get their way, soon only *BSD.

    • (Score: 3, Interesting) by Alias on Wednesday November 11 2015, @02:41AM

      by Alias (2825) on Wednesday November 11 2015, @02:41AM (#261544)

      I have, in the past, made the argument that systemd doesn't do anything that couldn't be done before. In fact, I know that many of the things it does, (dependency-based setup, sequential logging, etc..) have in fact been done before. There are numerous other ways to start and maintain processes on Linux. All of them are less monolithic and less risky than systemd. One of the biggest technical problems with systemd is the amount of functionality it tries to cram into PID1, which is a special process that really needs to be protected from complex interactions with other code for reliability and security reasons. PID1 is about as close as you can get to the kernel on the OS side without being part of the kernel. There are even kernel modules that are more well-sandboxed away from being able to break the system than PID1.

      Many things now have Mono and systemd dependencies, and are therefore possibly subject to patent suits and definitely subject to lock-in problems. The way the open source community typically deals with contentious changes is to fork and let the results of the two forks speak for themselves. The fact that this has been very strongly discouraged and that project leaders have been pressured into accepting Mono and systemd into the mainstream distros is strong evidence, in my opinion, that whomever is responsible for that pressure is up to no good and should be dealt with in a prejudiced manner. Note that I didn't even mention the technical pros and cons of systemd and Mono. Those pros and cons are irrelevant if their presence in mainstream distros enables the torpedoing of the Linux community and related OSS communities. To project leaders who are being faced with pressure to break compatibility with non-Mono or non-systemd systems: a better answer to those pressuring you is: "Go make your own fork."

      Realistically, the biggest problem here is that the Linux community has allowed commercial distributions to be the most mainstream ones. This was bound to happen eventually. Luckily, this has left a big opportunity for someone.

    • (Score: 0) by Anonymous Coward on Saturday November 14 2015, @09:38AM

      by Anonymous Coward on Saturday November 14 2015, @09:38AM (#263143)

      More and more it seems the main benefits are not to end users, but to upstream devs and distro maintainers.

      To upstream devs systemd offers a unified user space to target.

      To distro maintainers it offloads the burden of setting up various things.

      All in all, it appeals directly to the laziness of both groups.

  • (Score: 4, Interesting) by zocalo on Tuesday November 10 2015, @07:55AM

    by zocalo (302) on Tuesday November 10 2015, @07:55AM (#261131)
    We're mostly BSD for our *NIX boxes now, but we still have quite a few Linux systems around running stuff that we can't get to work on BSD. I actually don't mind systemd at all when it works, but hate it with a passion when it goes wrong; it's often quicker just to re-install from a backup image or wind back the VM to an earlier snapshot (we completely segregate OS and data, so this is trivial for us) rather than try and debug the more complex issues, which says a lot. Since it's also hard to tell in advance what the outcome of a debug session will be for all but the most obvious of problems "nuke and reimage" is slowly becoming our default problem solving stance for Linux boxes, which is a horrible, horrible state of affairs and a poor direction to be headed in, no matter how time efficient it is.

    Worst of all for me though is the massive missed opportunity for a fully modular version of systemd as a standalone system init process accompanied by a collection of tightly integrated and individually optional core system daemons that only deliver the 20% of features that are all 80% of the users will need. "systemd-whateverd" doesn't have all the features you need, is particuarly buggy, or has some other issue? Fine! Turn it off via a config file and install a full-fat replacement daemon that does. We could have had the best of both worlds in a single package (or, better yet, a set of packages); a closely integrated set of daemons for those that like the systemd approach, and the full modularity and ability to pick and mix daemons that most of systemd's detractors want, and almost everyone would have been happy. That's what happens when you don't think things through properly before you start hammering out the code, I guess...
    --
    UNIX? They're not even circumcised! Savages!
    • (Score: 5, Insightful) by LoRdTAW on Tuesday November 10 2015, @01:55PM

      by LoRdTAW (3755) on Tuesday November 10 2015, @01:55PM (#261235) Journal

      Since it's also hard to tell in advance what the outcome of a debug session will be for all but the most obvious of problems "nuke and reimage" is slowly becoming our default problem solving stance for Linux boxes, which is a horrible, horrible state of affairs and a poor direction to be headed in, no matter how time efficient it is.

      Hmmmmm. Now where have I had to use that method before?

    • (Score: 1) by Alias on Wednesday November 11 2015, @02:53AM

      by Alias (2825) on Wednesday November 11 2015, @02:53AM (#261548)

      "That's what happens when you don't think things through properly before you start hammering out the code, I guess..."

      I would love to agree with you, but I believe they did think of this and decided against giving users the freedom to do that easily. Anyone who understands enough about how Linux works to write systemd knows enough about the Unix way and the principles behind it that this *must* have crossed their mind. Systemd's current design doesn't seem to have internal interfaces that allow easy use of individual modules. There are lots of executables, but the whole thing is basically a huge POSIX noncompliance. It is almost like they thought that making a bunch of executables would make it look enough like the Unix way that it might pass muster while still allowing them to prevent people from making derivative works that are actually useful without integrating systemd source code directly into another code base. Perhaps they think they are going to be able to passively torpedo a million other projects by making them legally related to systemd code?

      Yes, I think the design was very deliberately poisonous.

      • (Score: 2) by zocalo on Wednesday November 11 2015, @09:07AM

        by zocalo (302) on Wednesday November 11 2015, @09:07AM (#261666)

        Yes, I think the design was very deliberately poisonous.

        I'm kind of divided on that point. Hanlon's Razor says that you should never attribute to malice that which is adequately explained by stupidity, and the clusterfuck of bad design and implementation that is PulseAudio certainly supports that view. On the otherhand, there is more than a whiff of "embrace, extend and extinguish" about the whole architecture of systemd, how it's not possible to entirely shutdown some parts of it even when you have a fully functional alternative running alongside and how various other unrelated projects, many of which are also heavily backed by Red Hat, all but require systemd to work themselves. What I'm not seeing in that though is the end game; is there *really* that much benefit from getting a given piece of code so entrenched into the Linux ecosystem that it's all but impossible to switch it out for an alternative?

        --
        UNIX? They're not even circumcised! Savages!
        • (Score: 0) by Anonymous Coward on Thursday November 12 2015, @06:24AM

          by Anonymous Coward on Thursday November 12 2015, @06:24AM (#262061)

          There have long been a refrain from Gnome/Freedesktop that if only Linux had a unified userland, everything would be so much easier and shinier...

        • (Score: 1) by Alias on Friday November 13 2015, @10:09PM

          by Alias (2825) on Friday November 13 2015, @10:09PM (#262854)

          "Is there *really* that much benefit from getting a given piece of code so entrenched into the Linux ecosystem that it's all but impossible to switch it out for an alternative?"

          Good question. I'm not completely sure. It would depend on exactly which piece of code. What is scaring me is that they have already managed to get lots of people on lots of projects to make changes for systemd. I know some of those changes are trivial. They are more like supporting systemd as an option. This looks like a hard dependency to people who aren't looking at the code because the package will require systemd to be present as a dependency, even though one could just comment out 3 lines and recompile to make the systemd dependency go away. I have heard, (though not personally verified,) that some of them are quite a bit worse, including at least something in the kernel.

          If the community is willing to trust the systemd people to not have an alterior motive, I can see how the systemd people might end up effectively controlling the architecture of other projects. All I am really saying here is that people need to look out for the "extend into left-handed coordinate system" takeover attempt.