Hacker News Reader

Comment by NotATroll | Hacker News Reader

> 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.

View on HN

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.

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.

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.

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?

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.

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.

The problem is the Java generaton that never learned how to do it.

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.

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

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.

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.

I use Emacs, but at my last few jobs I was just about the only one.

Hypothesis: Rust is a religion. The only times I've seen this amount of proselytization have been Rust and church.

Java or any other garbage collected language is memory safe by design.

Reply on news.ycombinator.com