5 ms·

> just like PulseAudio does. I think part of it actually stems from people that had problems early on with PulseAudio, and have developed a vendetta against Po

> just like PulseAudio does. I think part of it actually stems from people that had problems early on with PulseAudio, and have developed a vendetta against Poettering. Whether that vendetta is justified or not, I don't know. Personally systemd hasn't been a pain point. It's been far less of a headache than everyone at the office thought it would be.

amluto 7y ago
I’ve found it to be an improvement. Writing pre-systemd init scripts was never at all enjoyable. Systemd units aren’t exactly works of art, but they’re much, much better.
dijit 7y ago
Interestingly; Pulseaudio was a shit show until the distro maintainers got a good hold of it, now it mostly just works without much fiddling (or, any, in basic cases). SystemD is much the same way, I'm coloured by my impressions from Fedora21-22, where it.. didn't work great. The issue is with poetterware, it's _incredibly_ difficult to discover /why/ it's not working properly, which is dangerous for an init system (or, an "everything between your application and kernel"-system), a failure rate of 0.0001% is still an unfathomably enormous number of systems; and due to how it works it lends itself to an incredible host of threading issues.
kevin_thibedeau 7y ago
Poettering used alloca() as a poor man's garbage collector. Proper manual memory management is just "too hard". Other lingering code quality issues surely remain when the primary author is taking these sort of shortcuts and not considering how to write robust C.
- bitwize 7y ago
  Nobody can write robust C. The correct answer is Poettering should've switched to Rust. With few exceptions, any code base that has not yet done so should be considered brittle and bug-prone.
  - kevin_thibedeau 7y ago
    The problem is the Java generaton that never learned how to do it.
    - bitwize 7y ago
      Somehow members of the JavaScript and Ruby generations pick up Rust rather easily, while those who pride themselves on having learned to write robust C (or C++) are flummoxed by it. Hypothesis: C is so pathologically bad that it breaks brains.
      - geggam 7y ago
        I think C requires more of people. Granted I am no C expert but having worked in the industry a couple decades I have made conclusions based on observations. As a sysadmin I wrote a small kernel module to trigger a panic on a certain condition hoping to capture some info in a dump several years ago. Today I cant find sysadmins who can use a CLI properly. The goalposts have moved inwards IMO Not sure its bad thing either but it makes for interesting comparisons
        bitwize 7y ago
        It's kind of like back in the day Emacs was considered a programmer's tool. Yet secretaries not only used it, they learned how to configure it to their liking in Lisp! (If you tell a normie they are "customizing" the editor rather than "programming" it, they won't even realize it's hard!) These days, people calling themselves professional developers with years of experience won't even touch Emacs.
        NotATroll 7y ago
        Plenty of people still use Emacs. I picked it up several months ago after using Jetbrains IDE's for quite a long time, and honestly haven't felt the need for any of what Jetbrains brought to the table. Mostly thanks to LSP. If you're not a Java developer, Emacs is perfectly fine as a configurable extensible editor. With the additional caveat that its lack of multithreading can get in the way sometimes.
- slrz 7y ago
  As long as the allocation size is bounded (due to alloca/VLAs lacking any mechanism to signal allocation failure), what's the problem with that?
  - kevin_thibedeau 7y ago
    The problem is that 1) you can't assume what the available stack space is and 2) you don't let tainted user input determine allocation sizes which is what Systemd did in the CVE disclosed earlier this year.

amluto 7y ago

I’ve found it to be an improvement. Writing pre-systemd init scripts was never at all enjoyable. Systemd units aren’t exactly works of art, but they’re much, much better.

dijit 7y ago

Interestingly; Pulseaudio was a shit show until the distro maintainers got a good hold of it, now it mostly just works without much fiddling (or, any, in basic cases). SystemD is much the same way, I'm coloured by my impressions from Fedora21-22, where it.. didn't work great. The issue is with poetterware, it's _incredibly_ difficult to discover /why/ it's not working properly, which is dangerous for an init system (or, an "everything between your application and kernel"-system), a failure rate of 0.0001% is still an unfathomably enormous number of systems; and due to how it works it lends itself to an incredible host of threading issues.

kevin_thibedeau 7y ago

Poettering used alloca() as a poor man's garbage collector. Proper manual memory management is just "too hard". Other lingering code quality issues surely remain when the primary author is taking these sort of shortcuts and not considering how to write robust C.

bitwize 7y ago
Nobody can write robust C. The correct answer is Poettering should've switched to Rust. With few exceptions, any code base that has not yet done so should be considered brittle and bug-prone.
- kevin_thibedeau 7y ago
  The problem is the Java generaton that never learned how to do it.
  - bitwize 7y ago
    Somehow members of the JavaScript and Ruby generations pick up Rust rather easily, while those who pride themselves on having learned to write robust C (or C++) are flummoxed by it. Hypothesis: C is so pathologically bad that it breaks brains.
    - geggam 7y ago
      I think C requires more of people. Granted I am no C expert but having worked in the industry a couple decades I have made conclusions based on observations. As a sysadmin I wrote a small kernel module to trigger a panic on a certain condition hoping to capture some info in a dump several years ago. Today I cant find sysadmins who can use a CLI properly. The goalposts have moved inwards IMO Not sure its bad thing either but it makes for interesting comparisons
      - bitwize 7y ago
        It's kind of like back in the day Emacs was considered a programmer's tool. Yet secretaries not only used it, they learned how to configure it to their liking in Lisp! (If you tell a normie they are "customizing" the editor rather than "programming" it, they won't even realize it's hard!) These days, people calling themselves professional developers with years of experience won't even touch Emacs.
        NotATroll 7y ago
        Plenty of people still use Emacs. I picked it up several months ago after using Jetbrains IDE's for quite a long time, and honestly haven't felt the need for any of what Jetbrains brought to the table. Mostly thanks to LSP. If you're not a Java developer, Emacs is perfectly fine as a configurable extensible editor. With the additional caveat that its lack of multithreading can get in the way sometimes.
slrz 7y ago
As long as the allocation size is bounded (due to alloca/VLAs lacking any mechanism to signal allocation failure), what's the problem with that?
- kevin_thibedeau 7y ago
  The problem is that 1) you can't assume what the available stack space is and 2) you don't let tainted user input determine allocation sizes which is what Systemd did in the CVE disclosed earlier this year.