1. 46
  1.  

  2. 48

    This is the part of Systemd’s approach to the world that really keeps me up at night.

    So, anecdote: when Systemd decided it needed its own resolver (which already elicits the standard architectural “wat” from us old-fashioned UNIX folks), said to my fellow sysadmin at the time, “I’m calling it: it’ll be vulnerable to cache poisoning.” Here I am, a lowly sysadmin, aware that a baseline acceptable caching resolver must include the measures outlined in RFC 5452. Of course, I expect to be wrong, on some level: no one is that careless.

    Systemd comes along and bam, vulnerable. Even having predicted it, I was amazed.

    I think it’s indicative of a broader attitude on the part of the Systemd developers: the idea that they’re smart enough to “go it alone,” that they don’t need to look at prior art, and that whatever has come before has nothing in particular to teach them.

    It keeps me up at night as an operations person, because it’s like having to relive all of the great networked UNIX security failings in miniature, hoping against hope that one of them doesn’t make it to a stable distribution before being caught. I’m not particularly optimistic about it. And of course, it’s operations that Poettering keeps telling me he’s helping: no more init scripts, faster boots!

    And here I was more worried about outmoded concepts like “system integrity” and “existing knowledge.”

    1. 8

      This is the part of Systemd’s approach to the world that really keeps me up at night.

      Systemd is a Red Hat product, built by Red Hat employees, to Red Hat’s specifications. So it isn’t systemd’s approach, It is Red Hat’s approach that keeps you up at night.

      Operating system vendors do not make money by writing maintenance free software and giving it away. They make money by selling support contracts and training classes. There is nothing wrong with that, everyone has to make a living. Nor am I suggesting that OS vendors write maliciously bad software to sell support! One can’t support something that doesn’t work well enough to be deployed in the first place. Red Hat’s systemd project seems to be a good example of this.

      Red Hat is an operating system vendor, like Microsoft, Apple, IBM, Sun, and DEC, and they should be expected to behave as such with the projects that they sponsor.

      To expect otherwise is to deny their fundamental nature.

      1. 5

        This argument also includes that they want the product as stable as possible. Because if you sell support, you’d like to keep the number of incidents to a minimum, they are the thing that costs you. Having software under your control can be a fundamental part of that.

        Also, we shouldn’t forget that systemd wasn’t very welcome in Red Hat and was started by Lennard Poettering on his own time before being adopted when thinking about narratives to explain the whole thing.

        1. 1

          Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world. Not true. Currently, there are 16 hackers with commit powers to the systemd git tree. Of these 16 only six are employed by Red Hat. The 10 others are folks from ArchLinux, from Debian, from Intel, even from Canonical, Mandriva, Pantheon and a number of community folks with full commit rights.

          (Quoted from http://0pointer.de/blog/projects/the-biggest-myths.html)

          If systemd is merely a Red Hat tool to sell training, why have most other big distros (Debian, Ubuntu, Arch) adopted it? Ubuntu even had their own alternative they had worked on for years.

          Red Hat has worked on lots and lots of open source projects: http://community.redhat.com/software/ this apparently wasn’t an issue before but now they have employees on a project people don’t like and it’s a symbol of how they naturally have to be like this?

        2. 6

          systemd: implementing Basic Income for systems administrators, the hard way.

        3. 48
          • The process turns a request for binary DNS data into into XML, feeds it into the sytemd/dus ecosystem, which turns it into binary DNS to send it to the forwarder. The binary DNS answer then gets turned into XML goes through systemd/dbus, then is turned back into binary DNS to feed back into glibc.

          That’s certainly one way to do things.

          1. 27

            It’s things like that which make me question if people understand that software is entirely man made and doesn’t need to be complicated. The Standard Model isn’t forcing XML on us.

            1. 17

              “It was like this when I got here.”

              1. 1

                “It just works.”

              2. 5

                Apropos, one [of many] great Henry Baker’s Quotes

                Physicists, on the other hand, routinely decide deep questions about physical systems–e.g., they can talk intelligently about events that happened 15 billion years ago. Computer scientists retort that computer programs are more complex than physical systems. If this is true, then computer scientists should be embarrassed, considering the fact that computers and computer software are “cultural” objects–they are purely a product of man’s imagination, and may be changed as quickly as a man can change his mind. Could God be a better hacker than man?

              3. 19

                Where does XML supposedly come in? D-Bus does not use XML for serialization.

                Also the original announcement at https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html says resolved does not require D-Bus.

                1. 5

                  It’s on the internet, it must true. :)

                  1. 19

                    I’ve thought about this some more. (As a small matter, the choice of serialization format wasn’t really the big wtf for me.) But it does illustrate systemd has an image problem. I’m willing to believe just about anything. Its detractors have certainly been hard at work, and they haven’t been entirely fair. But then Lennart “haha, fuck BSD and tmux too for good measure” has been a rather poor defender of his choices. Everything I’ve read by him leads me to conclude he doesn’t believe software can be too complicated, only not complicated enough. So presented with a claim that systemd does something extraneously silly, my default response is not to reject it.

                    Asking for evidence is exactly what one should do.

                    1. 8

                      But then Lennart “haha, fuck BSD and tmux too for good measure” has been a rather poor defender of his choices.

                      He also has very poor attackers. Most of the criticism I read basically boils down to “everyone hates on systemd and believes it’s not POSIX”. (from our recent discussions, I’d happily exclude you there)

                      No one wants to engage with that crowd in a nuanced argument, lowering the quality of support and the quality of criticism at the same time.

                      This is also why I regularly call out non-complex arguments, because that is the road they lead down to.

                      We happily use systemd in a lot of deployments and like it in practice. It works and is approachable to newcomers. Software and new software have bugs (also critical ones), so it doesn’t help to call out “systemd implemented a base service” - that’s the way the project works, deal with it. All of the components systemd now replaces will be replaced at some point.

                      Criticism must be phrased in terms of whether the pace is healthy or different approaches would work better or in platform-wide solutions lost along the way.

                      You have to break an egg to make an omelette, but there’s always the question what kind of omelette it should be.

                      1. 4

                        Yeah, it’s been more heat than light all around.

                  2. 3

                    According to this post on lwn:

                    is really as easy as it gets

                    But looking at the source it is using lots of sd_bus_message* calls so for something doesn’t require D-bus it seems to have a dependency problem…

                    1. 2

                      I was wondering this myself.

                    2. 14

                      To be fair, turning things into an internal representation for processing before serializing back into the original format is not at all uncommon.

                      1. 1

                        This is true, and I expect this to be done especially when the original format is a binary blob. But there are better formats than XML! Especially if this is only used internally for processing, why not make it some kind of object? XML is rigid and prone to breakage, and is meant to be something barely amenable to both humans and machines. Seems extraneous here.

                        1. 1

                          “some kind of object” still has to be serialized which was the point of contention.

                      2. -4

                        *drops mic*

                      3. 11

                        I finally agree with Paul Vixie on something:

                        “it is unwise for dns outsiders to treat dns as something they can implement in passing and then forget about. far better that dns outsiders find a common library dependency and use it.”

                        and

                        “this NIH approach will doom us all.”

                        1. 4

                          That is what I was thinking. Systemd is adding a DNS resolver, ok, fine, I’m not a system infrastructure person, maybe they have a good reason. But rewriting a DNS resolver from scratch?
                          At this point in most languages' lifetimes, but especially C/C++ there should be very little you need to write, almost everything should essentially be glue code. Everything you write has to be tested, bug fixed, reviewed, maintained. Best make that as small as possible by calling out to battle hardened, bug fixed libraries wherever possible.

                        2. [Comment removed by author]

                          1. 5

                            I wouldn’t call this current thread free from disagreement. I can’t offhand think of any thread on lobste.rs that I would describe as whining; there’s generally a lot of substance even in acrimonious discussions. I don’t think anything is different here. :)

                            1. 2

                              Back in my day we just programmed everything in with switches on every boot. It took 3 days to program a twitterbot to say “Get off my porch!”

                              1. 1

                                Can you provide evidence that people whine in “every other thread about it except this one”?