6 ms·

Compare the sizes of community within Chromium/Linux/PostgreSQL. See how much more accent they put on security. Have you seen any fuzzing attempts started aroun

by d33 10y ago

Compare the sizes of community within Chromium/Linux/PostgreSQL. See how much more accent they put on security. Have you seen any fuzzing attempts started around SystemD, for example?

scrollaway 10y ago
You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that. Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...
- d33 10y ago
  You just resorted to ad personam for the second time. This is my last post in this discussion because of that. Here's why I believe it obfuscates the init process - it clearly is less transparent now. Consider logging, consider a new DSL (in terms of keywords, not necessarily syntax) needed to describe services, consider lack of determinism it brings. Yes, it's faster, but definitely more opaque. As for development process - they clearly have no time to refactor, which makes the code have way too little modularity. It's a huge blob linked against libsystemd and fuzzing the components would really be a mess. The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects. It interferes with desktop environments, GNOME being an example.
  - scrollaway 10y ago
    > You just resorted to ad personam for the second time. ...? I realized my first post was unnecessarily sarcastic and edited that part out. It's hard to comment about your opinions without talking about your opinions. But okay, you've offered a list, let's go through it: > Consider logging Logging is in a binary format, but is more consistently accessible. > consider a new DSL In terms of keywords? Do you mean like, which value does what in .service files? That's all extremely well documented. Consider the corresponding init shell scripts, how are they "more transparent" if you have to know shell pretty damn well in order to understand them? > consider lack of determinism it brings Now I completely lost you. sysvinit brings far less determinism to the table. If I found that paragraph in the wild without context I would assume it's about sysvinit.
    - bandrami 10y ago
      sysvinit brings far less determinism to the table Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth to get a deterministic service initiation order. For all their flaws, the good thing about init.d scripts was that you knew exactly what order things came up and down in, because it was spelled out in a shell script you could view and edit. This was great for administrators, but absolute hell for distribution maintainers; I totally get why the distros went to systemd. But since it solves their problems, rather than mine, it's not particularly useful to me (I use GNU PIES in production, which is kind of a middle ground: it can run inittab and rc.d scripts, but it also has a declarative native format)
      - scrollaway 10y ago
        That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue with this?
        bandrami 10y ago
        I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditions to work for everyone.
        scrollaway 10y ago
        Sorry, I read your post the wrong way around. I think you're conflating "transparent" and "deterministic". Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system. Similarly, docker is also more opaque but far more deterministic than a provisioning script.
  - bkor 10y ago
    > The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects. That makes on sense. Systemd provides some basic building blocks. Splitting systemd across multiple projects only provides drawbacks, no benefits. systemd does NOT interfere with GNOME. It provides logind and some other bits which GNOME makes use of. Talking about "ad personam" is a bit weird if there's so much misinformation.
    - digi_owl 10y ago
      Ah, hello Gnome's roving PR guy...
  - bandrami 10y ago
    I still don't see how this is even a question. Of course it's more opaque; declarative systems are by nature (that's generally a selling point). The fact that most distros seem to package a brittle spaghetti mess of unit files symlinked into about 7 different places isn't particularly systemd's fault, of course, but even when they're done more sanely just by nature declarative is always more opaque than imperative.

by d33 10y ago

Compare the sizes of community within Chromium/Linux/PostgreSQL. See how much more accent they put on security. Have you seen any fuzzing attempts started around SystemD, for example?

scrollaway 10y ago

You are making a comment about "The development process [being] too fast and erratic" (it is not). I'm not defending the systemd process, I'm making a point about that. Then again, if you think "obfuscating the init process" is a valid description of what systemd does per your other comment, I'm having a hard time seeing this as anything other than armchair security expertise...

d33 10y ago
You just resorted to ad personam for the second time. This is my last post in this discussion because of that. Here's why I believe it obfuscates the init process - it clearly is less transparent now. Consider logging, consider a new DSL (in terms of keywords, not necessarily syntax) needed to describe services, consider lack of determinism it brings. Yes, it's faster, but definitely more opaque. As for development process - they clearly have no time to refactor, which makes the code have way too little modularity. It's a huge blob linked against libsystemd and fuzzing the components would really be a mess. The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects. It interferes with desktop environments, GNOME being an example.
- scrollaway 10y ago
  > You just resorted to ad personam for the second time. ...? I realized my first post was unnecessarily sarcastic and edited that part out. It's hard to comment about your opinions without talking about your opinions. But okay, you've offered a list, let's go through it: > Consider logging Logging is in a binary format, but is more consistently accessible. > consider a new DSL In terms of keywords? Do you mean like, which value does what in .service files? That's all extremely well documented. Consider the corresponding init shell scripts, how are they "more transparent" if you have to know shell pretty damn well in order to understand them? > consider lack of determinism it brings Now I completely lost you. sysvinit brings far less determinism to the table. If I found that paragraph in the wild without context I would assume it's about sysvinit.
  - bandrami 10y ago
    sysvinit brings far less determinism to the table Hm. I was with you until that. The reason I don't have systemd in production is that it's like pulling teeth to get a deterministic service initiation order. For all their flaws, the good thing about init.d scripts was that you knew exactly what order things came up and down in, because it was spelled out in a shell script you could view and edit. This was great for administrators, but absolute hell for distribution maintainers; I totally get why the distros went to systemd. But since it solves their problems, rather than mine, it's not particularly useful to me (I use GNU PIES in production, which is kind of a middle ground: it can run inittab and rc.d scripts, but it also has a declarative native format)
    - scrollaway 10y ago
      That's because systemd by default is asynchronous, whereas init by default is linear. It's the main feature of systemd: Execution order is usually not important, it only leads to slower boot. For when it is important, systemd can guarantee execution order by using its dependency system. Are you a distro maintainer? I've never heard that it was "hell for distribution maintainers", quite the opposite. What's the issue with this?
      - bandrami 10y ago
        I "maintain" a toy "distribution", that isn't a "distribution" in the sense that I think nobody has ever downloaded it. What I meant was that the systemd opaque declarative model makes the distribution maintainer's life a lot easier; if systemd manages state based on declarative statements, you just have to make the declarative statements. Under init, you had to make imperative commands that met broad enough conditions to work for everyone.
        scrollaway 10y ago
        Sorry, I read your post the wrong way around. I think you're conflating "transparent" and "deterministic". Init is more transparent in that there are less layers to it. But systemd is more deterministic because it is able to make more guarantees about the state of the system. Similarly, docker is also more opaque but far more deterministic than a provisioning script.
- bkor 10y ago
  > The project has much too much responsibility, handling parts of system that could easily be delegated to separate projects. That makes on sense. Systemd provides some basic building blocks. Splitting systemd across multiple projects only provides drawbacks, no benefits. systemd does NOT interfere with GNOME. It provides logind and some other bits which GNOME makes use of. Talking about "ad personam" is a bit weird if there's so much misinformation.
  - digi_owl 10y ago
    Ah, hello Gnome's roving PR guy...
- bandrami 10y ago
  I still don't see how this is even a question. Of course it's more opaque; declarative systems are by nature (that's generally a selling point). The fact that most distros seem to package a brittle spaghetti mess of unit files symlinked into about 7 different places isn't particularly systemd's fault, of course, but even when they're done more sanely just by nature declarative is always more opaque than imperative.