1. 26
  1.  

  2. 30

    This article contains one of my pet peeves, in which it says “Leading kernel developers like Linus Torvalds and Greg Kroah-Hartman both enthusiastically praise systemd”, and then links to a talk in which Linus says only that he doesn’t hate it, but that it has quirks. It would be very hard to construe the comments made in the linked video as “enthusiastic praise”, but most people will assume it does, given the link.

    Interesting article none-the-less.

    1. 9

      Conversely, given what Torvalds usually says about stuff he dislikes…. That’s probably about as close to “Enthusiastic Praise” as you’re gonna get. :-D

      1. 5
      2. 2

        Linus says only that he doesn’t hate it, but that it has quirks

        Yeah, “has quirks”, eh? I figured he just wanted to avoid getting involved in the fight. But how could someone so serious about good software engineering practices not dislike systemd?

        I’m convinced systemd represents some sort of malignant takeover of the Linux ecosystem.

        1. 1

          One might hope that something as objective as tech and code would bring more objective journalism, but this does not seem to be the case.

        2. 27

          But others are quite critical of systemd, criticizing the software’s design for not sticking to the Unix philosophy, in which ‘everything’ is a file.

          This is a classic straw man argument and a mischaracterisation of the problem that people have with systemd. Yes, systemd is a departure from the UNIX philosophy. Yes, part of the UNIX philosophy has to do with files. But no, that’s nothing to do with the part that has people worried.

          What worries people about systemd is that it’s a departure from the UNIX philosophy of building the system from small, composable parts. Instead it creates a single monolithic “over-manager” with everything from startup to daemon management to cron to DNS to IPC all bundled up in the one massive opaque system. These are all provided as a fait accompli and the user has relatively little flexibility to alter it. This is the way in which it departs from the UNIX philosophy.

          1. 4

            Instead it creates a single monolithic “over-manager” with everything from startup to daemon management to cron to DNS to IPC all bundled up in the one massive opaque system.

            At least DNS (systemd-resolved) and IPC (dbus-daemon) run as separate processes.

            But this highlights another problem with systemd: It’s never quite clear whether “systemd” refers to the whole project or just systemd(1). This leads to a lot of confusion when discussing the “systemd is monolithic” issue.

            1. 2

              Sounds like Linux. Is Linux just the kernel, or is it the entire installation?

          2. 21

            not one mention of the terrible security practices and needlessly extensive privileges systemd has? no? just BSD users hate it because files??

            oi vey

            1. 15

              He’s not exactly renowned for his self-reflection.

            2. 20

              I’m pretty sure that putting the file as the most basic concept is complete nonsense because the file is way too specific; it’s way too different from a printer, from a sound card. I definitely have big issues ‘everything-is-a-file’ concept and I think it’s misdesigned.

              Seriously? But both have been supported, well, as files. This is bullshit.

              1. 19

                Just because we’ve always done it that way doesn’t mean it’s the best way.

                Think about it, what is a device file really abstracting? It’s essentially just a socket to some driver. Across that socket you send some sort of thing, usually a binary or text protocol… it sounds an awful lot like an RPC system to me. So why not put the RPC system on dedicated message bus?

                Oh look, d-bus.

                I make no claims about the quality of d-bus either in design or implementation, however the idea of abandoning magic files for a dedicated message bus makes perfect sense to me.

                1. 34

                  How much more complicated is it to support in a language-agnostic way D-bus than files? How much fiddlier are permissions for RPC? How many programs have worked longer with files instead of some system messaging facility and more portably?

                  Oh, and why not just expose the message facility as files anyway?

                  If you want to play the concept-is-great-just-not-this-implementation, I’ll point out that Plan9 showed that, no really, all you need is files and it works damned well.

                  1. 33

                    How much fiddlier are permissions for RPC?

                    This is a good point, UNIX permissions are already straightforward and well understood.

                    How many programs have worked longer with files instead of some system messaging facility and more portably?

                    More portably? What a fucking joke. Device files on different systems are all totally different. All you can rely on is raw block devices acting like raw block devices, but they don’t even have the same names across systems! Nor are they deterministic, what does /dev/sda mean? It means the Linux kernel chose “a” for that one particular drive. Would FreeBSD /dev/ad0 be the same? What about OpenBSD /dev/sd0? Who knows?

                    And disk devices are easy. What if you need to configure the device? How do you do that? I’ll tell you how, you use ioctl. Maybe you don’t know about ioctl, and in that case forgive my aggressive tone, but if you think ioctl is simple, portable, and language-agnostic you’re absolutely delusional.

                    Lets talk about ioctl.

                    • there are a bajillion flags that you set on a device file with stupid names like SIOCGIWNWID
                    • man 2 ioctl_list for Linux literally says “This list is very incomplete.”
                    • the syscall function signature is int ioctl(int fd, unsigned long request, ...);
                      • if any type signature could say “go fuck yourself” it would be this one
                      • not language-agnostic at all, unless you consider a driver module written in C “language-agnostic”, or use the language’s C FFI and hope your language has excellent FFI support for variadic functions
                    • every *nix has different ioctls
                      • some are the same
                      • many are completely different
                      • if they are the same they probably have subtle differences
                      • the subtle differences are subtly different between each *nix
                    • only exists because the everything-is-a-file abstraction is complete bullshit and doesn’t work

                    Lets think about a sound device as a file. Seems simple right? Just write the audio stream to the device and it plays! A wonderful beautiful abstraction yes? No. What frequency does the sound card take? What if it supports multiple frequencies? Which one is it set to? Is it 16-bit or 24-bit? How do you know? How should you set it up? Music usually comes at 44.1 kHz but DVDs come at 48 kHz, how does your audio device file handle that?

                    So we need some configuration. Here, you can use these ioctls, which may or may not be supported by your sound card. You will only really know once you call ioctl and see if it fails. But it might return success and silently do nothing, depends on the ioctl. Also, this probably isn’t all of them, however you can read the kernel source to find out if what you need is supported. Files as devices are awesome! Good luck!

                    SNDCTL_SEQ_SYNC
                    SNDCTL_SYNTH_INFO
                    SNDCTL_SEQ_CTRLRATE
                    SNDCTL_SEQ_GETOUTCOUNT
                    SNDCTL_SEQ_GETINCOUNT
                    SNDCTL_SEQ_PERCMODE
                    SNDCTL_FM_LOAD_INSTR
                    SNDCTL_SEQ_TESTMIDI
                    SNDCTL_SEQ_RESETSAMPLES
                    SNDCTL_SEQ_NRSYNTHS
                    SNDCTL_SEQ_NRMIDIS
                    SNDCTL_MIDI_INFO
                    SNDCTL_SEQ_THRESHOLD
                    SNDCTL_SYNTH_MEMAVL
                    SNDCTL_FM_4OP_ENABLE
                    SNDCTL_PMGR_ACCESS
                    SNDCTL_SEQ_PANIC
                    SNDCTL_SEQ_OUTOFBAND
                    SNDCTL_TMR_TIMEBASE
                    SNDCTL_TMR_START
                    SNDCTL_TMR_STOP
                    SNDCTL_TMR_CONTINUE
                    SNDCTL_TMR_TEMPO
                    SNDCTL_TMR_SOURCE
                    SNDCTL_TMR_METRONOME
                    SNDCTL_TMR_SELECT
                    SNDCTL_PMGR_IFACE
                    SNDCTL_MIDI_PRETIME
                    SNDCTL_MIDI_MPUMODE
                    SNDCTL_MIDI_MPUCMD
                    SNDCTL_DSP_RESET
                    SNDCTL_DSP_SYNC
                    SNDCTL_DSP_SPEED
                    SNDCTL_DSP_STEREO
                    SNDCTL_DSP_GETBLKSIZE
                    SOUND_PCM_WRITE_CHANNELS
                    SOUND_PCM_WRITE_FILTER
                    SNDCTL_DSP_POST
                    SNDCTL_DSP_SUBDIVIDE
                    SNDCTL_DSP_SETFRAGMENT
                    SNDCTL_DSP_GETFMTS
                    SNDCTL_DSP_SETFMT
                    SNDCTL_DSP_GETOSPACE
                    SNDCTL_DSP_GETISPACE
                    SNDCTL_DSP_NONBLOCK
                    SOUND_PCM_READ_RATE
                    SOUND_PCM_READ_CHANNELS
                    SOUND_PCM_READ_BITS
                    SOUND_PCM_READ_FILTER
                    SNDCTL_COPR_RESET
                    SNDCTL_COPR_LOAD
                    SNDCTL_COPR_RDATA
                    SNDCTL_COPR_RCODE
                    SNDCTL_COPR_WDATA
                    SNDCTL_COPR_WCODE
                    SNDCTL_COPR_RUN
                    SNDCTL_COPR_HALT
                    SNDCTL_COPR_SENDMSG
                    SNDCTL_COPR_RCVMSG
                    SOUND_MIXER_READ_VOLUME
                    SOUND_MIXER_READ_BASS
                    SOUND_MIXER_READ_TREBLE
                    SOUND_MIXER_READ_SYNTH
                    SOUND_MIXER_READ_PCM
                    SOUND_MIXER_READ_SPEAKER
                    SOUND_MIXER_READ_LINE
                    SOUND_MIXER_READ_MIC
                    SOUND_MIXER_READ_CD
                    SOUND_MIXER_READ_IMIX
                    SOUND_MIXER_READ_ALTPCM
                    SOUND_MIXER_READ_RECLEV
                    SOUND_MIXER_READ_IGAIN
                    SOUND_MIXER_READ_OGAIN
                    SOUND_MIXER_READ_LINE1
                    SOUND_MIXER_READ_LINE2
                    SOUND_MIXER_READ_LINE3
                    SOUND_MIXER_READ_MUTE
                    SOUND_MIXER_READ_ENHANCE
                    SOUND_MIXER_READ_LOUD
                    SOUND_MIXER_READ_RECSRC
                    SOUND_MIXER_READ_DEVMASK
                    SOUND_MIXER_READ_RECMASK
                    SOUND_MIXER_READ_STEREODEVS
                    SOUND_MIXER_READ_CAPS
                    SOUND_MIXER_WRITE_VOLUME
                    SOUND_MIXER_WRITE_BASS
                    SOUND_MIXER_WRITE_TREBLE
                    SOUND_MIXER_WRITE_SYNTH
                    SOUND_MIXER_WRITE_PCM
                    SOUND_MIXER_WRITE_SPEAKER
                    SOUND_MIXER_WRITE_LINE
                    SOUND_MIXER_WRITE_MIC
                    SOUND_MIXER_WRITE_CD
                    SOUND_MIXER_WRITE_IMIX
                    SOUND_MIXER_WRITE_ALTPCM
                    SOUND_MIXER_WRITE_RECLEV
                    SOUND_MIXER_WRITE_IGAIN
                    SOUND_MIXER_WRITE_OGAIN
                    SOUND_MIXER_WRITE_LINE1
                    SOUND_MIXER_WRITE_LINE2
                    SOUND_MIXER_WRITE_LINE3
                    SOUND_MIXER_WRITE_MUTE
                    SOUND_MIXER_WRITE_ENHANCE
                    SOUND_MIXER_WRITE_LOUD
                    SOUND_MIXER_WRITE_RECSRC
                    
                    1. 17

                      Sure, ioctl is a bit of a deranged joke–but again, you’re haggling over one particularly stupid and inbred family of solutions. I’d be similarly silly for saying “messaging is totally stupid” by pointing at SOAP or CORBA.

                      Again, please, go look at the way Plan 9 handles device options and things as files.

                      EDIT: And yes, I’m familiar with the problems devices like audio cards and graphics cards present. That said, that makes it even more interesting to have a clean file-based way of introspecting on device state.

                      1. 5

                        I’m not haggling over one particularly stupid solution, I’m describing the current, in use solution that is actually the problem at hand.

                        Besides, devices are only one example of how the files abstraction breaks down, as kel pointed out. What about other forms of IPC? Or dynamic things such as local service discovery? Are you going to do that all with files? All IPC shalt be done exclusively through named pipes with custom binary protocols, or dead drops on the filesystem?

                        1. 15

                          Are you going to do that all with files?

                          …yes?

                          EDIT:

                          Search Wikipedia for the plan 9 plumber program. Lobsters seems to be allergic to the link. :(

                          1. 5

                            Is Plan9 actually the likely alternative here? I mean, there is some alternate universe in which it became the standard Unix, and it has some elegance. But despite years of people vaguely admiring it, I don’t see any real move in either the BSD or Linux world towards actually moving the core OS to a Plan9 model. The real debate in Linux-land, especially, seems to be more over Linux old-world vs. Linux new-world, i.e. do you think replacing sysvinit with systemd’s init, and replacing ioctls with dbus, is a step forwards or backwards? If systemd and dbus both went away, I still don’t see Linux adopting a Plan9 model as the alternative.

                            1. 15

                              I still don’t see Linux adopting a Plan9 model as the alternative.

                              Well, /proc is kinda a low-budget ripoff, and one that frankly wasn’t implemented as well as it could’ve been.

                              There’s waaaaay too much software and momenturm built up in the Linux ecosystem (and, for that matter, in the BSD ecosystem) to expect any sort of graceful transition to a better model.

                              Nothing is stopping it, mind you–CADT means that in a decade or so some clever youth with more arrogance than sense could certainly come along and strongarm the ecosystem into doing the right thing; unfortunately, the sort of system we get with 9P is more built on engineering restraint and clarity of purpose, things which don’t usually conincide with the other factors I mentioned.

                              As for the current debate, well, the linux folks are bikeshedding when a new monorail is sitting, unused, next door.

                              1. 12

                                Plan 9 is explicitly not Unix, said with vehemence by the same people who created both. ‘Adopting a Plan9 model’ would mean that Linux would be a Plan 9, not a Unix. Plan 9 is its own philosophy and family of OS at this point, and while devs have borrowed ideas from it, individual pieces are not necessarily viable or secure without the other parts. See OpenBSD’s justified rejection of /proc.

                                This discussion mostly kicked off from Poettering’s throwaway argument that “you can’t do sane hardware control through files!”, and there’s been enough documentation presented here that “yes you can, as long as your abstractions are decently thought out”. Much like many other of computing’s “universal” truths, it depends on how you’re looking at it. I gravitate more towards the namespace approach because I’ve been on too many projects where This Time It’s Different™, and “complexity is natural”.

                                My feelings on the article itself are much like zik’s : service management is a tricky problem, and it’s no sin to move away from strict SysV if you want to(see Apple’s launchd), but systemd and its inventor seem inclined to force it on Linux(as a concept) without understanding the real point of the Unix philosophy.

                                Again, if that’s the direction the majority want to take, that’s their right. But it is a direct consequence of those views(along with containers) which has had me moving gradually away from Linux towards the BSD and Plan 9 families in the past year.

                                1. 2

                                  But despite years of people vaguely admiring it, I don’t see any real move in either the BSD or Linux world towards actually moving the core OS to a Plan9 model.

                                  In some ways yes, in other ways no. For example, ‘mount -t 9p’ works fine on my Ubuntu, out of the box. Namespaces are dead in the water, as well as a lot of the other things that make plan 9 awesome, but there’s nothing preventing people from using the 9p rpc system today, in real systems.

                                  1. 3

                                    You can use it in userspace yes, but is there any prospect of the kernel using it as the basis of its abstractions and public interfaces? I don’t see any critical mass behind dbus being dropped in favor of a Plan9-esque interface. Instead it seems the debate is between something like dbus, and something that looks more like pre-dbus Linux. Or, alternatively, the “Plan B” is to use the BSD abstractions, either by deciding this is a good time to leave Linux for a BSD, or by importing some of the BSD abstractions to Linux. But either way, not the Plan9 abstractions.

                                    1. 1

                                      That’s because userspace seems to have decided it wants dbus, at least for now. And that’s kind of what people here are complaining about.

                                      1. 3

                                        ‘userspace has decided’? We’re the users. This is our space. The people who have decided are, let’s be honest and clear, Red Hat.

                                        1. 2

                                          What is this supposed to mean, other than “everyone other than Red Hat hates systemd?” I like systemd (to the extent that I think it is better than the alternatives) and am not employed by Red Hat. A lot of people feel the same way, but have better things to do than join the latest Poettering flamewar. This forum in particular has a high concentration of BSD users, who are more likely to dislike systemd. I wouldn’t use the mood in here to gauge the overall opinion of systemd.

                                2. 6

                                  So you want to extend the filesystem idea so heavily that it’s essentially d-bus? Now you’ve got an RPC system that only supports the signature (string -> string) but is more convenient to use on the command line. I guess if you love string parsing and manual type validation, then sure, why not?

                                  1. 7

                                    Go read the good links somebody else put up.

                                    Like, I get that you don’t agree with me, but good word you seem hellbent on making the least charitable view of my position you can. There is so much cool stuff that we can get, for free, without resorting to bloated bad reimplementations of ideas a decade after the problem had already been solved and solved well.

                                    D-bus solves it’s problem in a heavy-handed way that makes sense if you’ve never seen a better solution. I’m saying that there was a better alternative out there, even though the ‘nix ecosystem is too brain-damaged to be able to make use of it.

                                    Also, don’t be afraid of simple string messages. They’re not impossible to parse or vailidate…millions of sites get by on that fact every day. :)

                                    1. 8

                                      As I said, I don’t necessarily think d-bus is a perfectly designed system. But I completely understand why the systemd and freedesktop folks prefer it over a Plan 9 style file system. Instead of heavily modifying the kernel to support an entirely different paradigm of interacting with devices and processes, they made a userspace daemon that translates the existing crap into an interface that’s easier for them to consume in a structured way.

                                      What I’m hellbent on doing is rejecting your statement “Seriously? But both have been supported, well, as files. This is bullshit.” Because no, it’s not bullshit. It’s a rational response to an existing system that can’t just be ripped apart and rebuilt in a totally different way overnight. Sure Poettering may be wrong to criticize filesystems as an interface, but he’s making software for Linux, not Plan 9.

                                      So to address this directly:

                                      There is so much cool stuff that we can get, for free, without resorting to bloated bad reimplementations of ideas a decade after the problem had already been solved and solved well.

                                      No, we can’t get it for free. You can’t put the Plan 9 filesystem into Linux for free. That’s absurd. It doesn’t matter how cool or nice it would be, it’s not happening. Being realistic isn’t bullshit, Poettering is making real improvements to Linux by working with what’s available.

                                      Also, don’t be afraid of simple string messages. They’re not impossible to parse or vailidate

                                      Being “not impossible” to use is a pretty low bar.

                                      1. 6

                                        In what way is dbus a rational response to anything? It’s a desktop bus. It’s in the name. It starts out life in 8-bit ASCII mode and literally on the same socket moves to binary mode. Why is this as a concept the one true IPC interface, and a filesystem is not? At least the filesystem can be made regular and separate its concerns orthogonally.

                                  2. 2

                                    You need to escape the parens. https://en.wikipedia.org/wiki/Plumber_(Plan_9)

                              2. 1

                                Everything is a file could be a good abstraction if you could write method calls to the file:

                                echo 'set_volume(0.9)' > /dev/sound
                                
                              3. 6

                                Oh, and why not just expose the message facility as files anyway?

                                Hey, guess what I just did for work.

                                 ls /mnt/peripheral/devices/
                                 echo command > /mnt/peripheral/devices/ctl
                                

                                /mnt/peripheral is serving 9p over USB to an stm32f4 microcontroller. There’s a small adapter right now to tunnel USB to a socket, and the Linux kernel knows how to mount it.

                                My testing is done via some shell scripts, although I could do it with any language.

                                1. 3

                                  Are sockets represented as files really “file"s at that point? Makes you think…

                                  1. 18

                                    Indeed.

                                    “In Plan 9, it’s not "everything is a file”, it’s “everything has the same interface”. And that interface is “file system”."

                                    The pithy “everything is a file” statement also tends to miss the other part that Plan 9 / Inferno emphasize, that of creating custom namespaces(“file systems”) and synthetic items(‘files’) on demand. The kernel shields processes from each other, so process 1’s ‘socket’ ‘file’ is not the same as process 2’s, even though they got their resource(‘file handle’) from open()‘ing the object pointed to by the string “/net/tcp/clone”.

                                    Charles Forsyth goes over this in his talk, and the The Use of Name Spaces in Plan 9 opens with this idea. From a programming language perspective, you might note technomancy’s post on Lua sandboxing by using setfenv() and a table of functions to construct an environment for a chunk of code to run in.

                                    Of course, as noted in Styx on a brick, or The Styx Architecture for Distributed Systems (the PathStar’s hardware interface), this does not remove the need for out-of-band documentation, convention, or forethought. What this does do, is take the complexity and discoverability out of the privileged layers like the kernel, and give them back to the user, where they should be. That’s it.

                                    (Archive.org links provided, as disturbingly cat-v.org seems to be down right now)

                                    1. 3

                                      Doing the good work with those links. :)

                                      (Archive.org links provided, as disturbingly cat-v.org seems to be down right now)

                                      Yeah, ran across that earlier in this conversation, which was mightily frustrating. I hope they’re okay. :( :(

                                      1. 1

                                        As of 01/28, cat-v.org is up again.

                                        1. 1

                                          Morbid thought: 9front finally trolled too hard for somebody.

                                          Less morbid: someone probably forgot to pay the hosting bill. (I hope)

                                    2. 2

                                      You certainly can do everything as files, but as far as I can tell, the movement towards these “messaging bus” type abstractions for RPC is broader than just dbus. Stuff like ZeroMQ, RabbitMQ, even Amazon SQS has gained popularity roughly contemporaneously, in various niches. I am not the person to tell you why people like it though.

                                      1. 6

                                        You know, that would actually be a cute use of FUSE…creating a /dev/SQS folder where you can just open and write messages or read them.

                                    3. 11

                                      If files and d-bus are functionally equivalent for this purpose, what is gained by the multiplication of entities? There are decades of tools to work with files and now all those wheels need to be reinvented for d-bus.

                                      1. 2

                                        Horse-drawn carriages and cars are functionally equivalent, what is gained by the multiplication of entities? There are decades of tools to work with horses and now all those tools need to be reinvented for cars.

                                        1. 7

                                          It sounds like you believe that there is a convincing answer to my earlier question (“what is gained?”). I’d love to hear it.

                                          1. 2

                                            See my comment here.

                                            1. 8

                                              Your comment there does nothing whatsoever to make the case that dbus is an improvement. You argue that POSIX underspecifies paths and that ioctl is messy. You mentioned dbus precisely zero times.

                                              1. 4

                                                I thought it was obvious why I consider a message bus an improvement over ioctl, just by virtue of how crappy ioctl is. However, here you go:

                                                • typed RPCs, both arguments and return values
                                                • different kinds of IPC, like broadcast, pub/sub
                                                  • subscribe to device changes / hotplugging
                                                  • change to AC power or battery
                                                • local service discovery more sophisticated than ls
                                                • client / server /etc libraries that make it convenient to write services according to a universally agreed upon pattern

                                                A message bus adds structure. I personally think structure is good. There’s a reason we have protocols like HTTP, rather than just opening sockets to remote servers and barfing text however we please, inventing something new for every application.

                                                1. 3

                                                  You mean like everyone did REST the same way, sometimes using PUT to mean PATCH and almost no one using the same representation for the exact same concept?

                                                  1. 5

                                                    Sure people do things differently, but within the REST camp at least people mostly agree on HTTP+JSON. That’s a step up from a raw socket.

                                                    1. 2

                                                      My point was more that if you’re comparing HTTP to dbus, it looks more like a socket with barfy text. Sure, there’s REST, and most people do json. Some also have xml. There’s an infinite amount of content types, and none of them are binding on the content of the response. There’s convenience in Web services. HTTP doesn’t even guarantee discoverability. Unless you have links in the content? What if you’re a stupid crawler and you land on a javascript-only site? Discoverability just went out the window. The only real guarantee is that you’re gonna have textual headers and then a blob of maybe text or maybe raw bytes.

                                  2. 10

                                    He said that most people who are programmers will eventually learn about object-oriented programming, hopefully at university or another school. They will find that the most abstract concept that object-oriented programming has, how it sees the world, is generally the object. On Unix it’s the file. “I’m pretty sure that putting the file as the most basic concept is complete nonsense because the file is way too specific; it’s way too different from a printer, from a sound card. I definitely have big issues ‘everything-is-a-file’ concept and I think it’s misdesigned.”

                                    Block devices and character devices have been a very successful model for unix. His patronizing tone comes across as infuriatingly arrogant.

                                    1. 2

                                      His works highly affects the UNIX community, but he keeps trolling it a lot.