News for hackers. Stuff that matters.
Re:Systemd, 10 years later: a historical and technical retro... by cyberax on Tuesday August 06, 2024 @06:58PM (#41176375)
Systemd itself is a fine idea, but its maintainers and governance are not.

They screwed up the libsystemd first by bringing tons of dependencies (including libxz), and then inventing a braindead delayed loading mechanism. That required adding custom ELF sections. It's funny that they used "macOS does this!" as an argument for the delayed loading, when in reality macOS removed that functionality about a decade ago (for being braindead).

While all they needed to do was simply split libsystemd into two libraries.

Re:Systemd, 10 years later: a historical and technical retro... by NekkoDroid on Tuesday August 06, 2024 @08:00PM (#41176853)
> and then inventing a braindead delayed loading mechanism. That required adding custom ELF sections.

What are you talking about???

dlopen is hardly a new "delayed loading mechanism" and having a custom ELF section where the dlopen'd libraries are listed is just a positive thing for package managers, so that it can be automatically detected during build just like used SO files (for writing the build metadata files).

Re:Systemd, 10 years later: a historical and technical retro... by cyberax on Tuesday August 06, 2024 @11:55PM (#41178111)
> What are you talking about???

This: https://github.com/systemd/systemd/blob/main/docs/ELF_DLOPEN...

> dlopen is hardly a new "delayed loading mechanism"

Yes, it's a well-known anti-pattern that libraries like glibc are trying to minimize.

When your fuckup requires a change in the basic system architecture, you are probably doing it wrong.

_All_ they needed to do was split libsystemd into libcoresystemd and libjournald. Only the latter requires libxz and other compressors.