News for hackers. Stuff that matters.
Re:Systemd, ten years later: a historical and technical retr... by epistasis on Monday May 04, 2020 @12:13AM (#23064485)
You use the word "just" as if this were a simple thing to understand and know. Is this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

I ask not rhetorically, just out of curiosity. It's not a typical type of suggestion for other packages I've encountered with open source, and it feels far more difficult to discover than typical decisions at compile time.

Re:Systemd, ten years later: a historical and technical retr... by oefrha on Monday May 04, 2020 @01:50AM (#23064948)
> this magic incantation communicates in a way that the usual people who compile this package can understand to use it without being intimately familiar with the code?

Define “usual people who compile this package”. In my books those are distro maintainers who indeed should be familiar with options provided by the init system they choose. If you decide to include oddballs who compile everything themselves (Linux from scratch?) then again, yes, they are expected to know a thing or two or dig into options or even code from time to time.

Re:Systemd, ten years later: a historical and technical retr... by Spivak on Monday May 04, 2020 @08:59AM (#23067451)
I mean the parent was talking about the source code being a ball of mud and it being difficult to determine what components can be removed without breaking things.

In this case it should be assumed we’re talking about someone who’s compiling systemd and familiar with the source. And yes, these are flags that anyone who builds systemd from source would be familiar with and know how to set.

It’s the same as when you run a configure script and pass —-disable-feature.

Re:Systemd, ten years later: a historical and technical retr... by JoeAltmaier on Monday May 04, 2020 @09:05AM (#23067509)
So common with open source - flags that once worked are now tangled up with subsequent code/flags and won't even compile if not part of some common configuration. Because its not fun to exhaustively test all combinations, it doesn't get done.
Re:Systemd, ten years later: a historical and technical retr... by pas on Monday May 04, 2020 @07:09AM (#23066598)
It seems exactly as difficult as with any other stuff written in C. Let's say uWSGI. systemd uses meson, and there's a file listing all the options, and the first match for "resolve" seems to be that flat: https://github.com/systemd/systemd/blob/master/meson_options...

Furthermore, even if you compile it, you don't have to use it. Even if you install it, you don't have to use it. (After all it has 2-3 APIs, one of them is the /etc/resolve.conf symlink, if you instead just put 1.1.1.1 in that file, libc will not go through resolved. And similarly for the other entry points.)

It's possible to accidentally compile, install and have systemd-resolved set up on your computer, but it still seems rare that someone can compile and install systemd, yet not know what they're doing.

Re:Systemd, ten years later: a historical and technical retr... by yrro on Monday May 04, 2020 @04:00AM (#23065561)
Yes it is.