Live data from Hacker News

A timesyncd failure and systemd's lack of debugability

utcc.utoronto.ca

11–20 of 126 posts

Re: A timesyncd failure and systemd's lack of debugability

#11

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

It's disappointing to see the top comment here condoning ad hominem attacks.

But if you do believe that the identity of a speaker is more important than the arguments they make, note that the author of this blog post has a history of praising systemd (e.g. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight) There is no anti-systemd bias motivating this post.

Re: A timesyncd failure and systemd's lack of debugability

#12

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

> I like systemd, it's a pity some vocal people aren't enthusiastic about it.

To give some context as to why, for non-C++ developers systemd makes things very difficult to debug and understand in general.

Moreover the biggest issue /I/ personally have is the fact it was essentially forced on me by the mainstream distro maintainers.

When you discuss the merits and fallbacks of systemd it’s common for people to either try to discuss its merits only against sysvinit. Or they imply that issues that have affected me personally are not such a big deal and I should be quiet because: progress.

It’s a frustrating and exhausting position to be in. It’s like everyone shoving Windows registry on Linux down your throat, with all the opaque, obtuse and stifling qualities that would come with such a solution and telling you and your ilk to be quiet and suck it up.

Edit: I’m getting pounded by downvotes. But I guess offering any kind of other opinion about systemd for any reason isn’t met with kindness. However I can say this: neither google nor amazon use systemd to host AWS or GCP. At least consider why that is before you bury your head in the sand.

Re: A timesyncd failure and systemd's lack of debugability

#13
post #12

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

> I like systemd, it's a pity some vocal people aren't enthusiastic about it. To give some context as to why, for non-C++ developers systemd makes things very difficult to debug and understand in general. Moreover the biggest issue /I/ personally have is the fact it was essentially forced on me by the mainstream distro maintainers. When you discuss the merits and fallbacks of systemd it’s common for people to either…

Systemd is straight C, not C++.

Re: A timesyncd failure and systemd's lack of debugability

#14
post #11

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

It's disappointing to see the top comment here condoning ad hominem attacks. But if you do believe that the identity of a speaker is more important than the arguments they make, note that the author of this blog post has a history of praising systemd (e.g. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight ) There is no anti-systemd bias motivating this post.

>>condoning ad hominem attacks

I'm not condoning ad-hominem attacks. In fact I am pointing out that often it is systemd itself that it the victim of ad-hominem attacks, which is to say that often people attack systemd, not its behaviors.

Re: A timesyncd failure and systemd's lack of debugability

#15

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

The author has gone into a lot of details on the issue so your question about whether 'this is a general issue' is answered quite clearly in the article and the follow up itself, including a link to Poettering's rationale and write up for dynamic users.

Characterizing a bug report with a detailed write up and follow up solution as 'attacks' and 'bias' is inexplicable.

Re: A timesyncd failure and systemd's lack of debugability

#16
post #13
post #12

Earlier quoted context omitted.

> I like systemd, it's a pity some vocal people aren't enthusiastic about it. To give some context as to why, for non-C++ developers systemd makes things very difficult to debug and understand in general. Moreover the biggest issue /I/ personally have is the fact it was essentially forced on me by the mainstream distro maintainers. When you discuss the merits and fallbacks of systemd it’s common for people to either…

Systemd is straight C, not C++.

spins finger in the air the difference is immaterial and irrelevant in this context.

Re: A timesyncd failure and systemd's lack of debugability

#17
post #11

Earlier quoted context omitted.

It's disappointing to see the top comment here condoning ad hominem attacks. But if you do believe that the identity of a speaker is more important than the arguments they make, note that the author of this blog post has a history of praising systemd (e.g. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight ) There is no anti-systemd bias motivating this post.

>>condoning ad hominem attacks I'm not condoning ad-hominem attacks. In fact I am pointing out that often it is systemd itself that it the victim of ad-hominem attacks, which is to say that often people attack systemd, not its behaviors.

But you wrote:

> I think "who is saying this, doing they have an underlying bias against this thing they are attacking"?

Re: A timesyncd failure and systemd's lack of debugability

#18

Given things like this: "The default configuration is defined during compilation" [1] and the fact that you'd think 'timedatectl status' would tell you the NTP server you're supposedly trying to sync to (spoiler alert: it doesn't), I'm unsurprised of any further atrocities committed by systemd. [1]: https://www.freedesktop.org/software/systemd/man/timesyncd.c...

> Given things like this: "The default configuration is defined during compilation [so a configuration file is only needed when it is necessary to deviate from those defaults....]" I don't get it. What's so bad about that?

It means that a configuration file on two similar machines could have radically different behaviors.

Re: A timesyncd failure and systemd's lack of debugability

#19
post #17

Earlier quoted context omitted.

>>condoning ad hominem attacks I'm not condoning ad-hominem attacks. In fact I am pointing out that often it is systemd itself that it the victim of ad-hominem attacks, which is to say that often people attack systemd, not its behaviors.

But you wrote: > I think "who is saying this, doing they have an underlying bias against this thing they are attacking"?

There is nothing wrong with examining the motive behind someone's argument. That's very different than an ad hominem attack.

Re: A timesyncd failure and systemd's lack of debugability

#20

Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…

The author has gone into a lot of details on the issue so your question about whether 'this is a general issue' is answered quite clearly in the article and the follow up itself, including a link to Poettering's rationale and write up for dynamic users. Characterizing a bug report with a detailed write up and follow up solution as 'attacks' and 'bias' is inexplicable.

Yeah, it's more like "Any time someone presents a problem with systemd, someone else will claim politics."

It's kind of fascinating to watch software become so polarizing. Like, it's technology. It doesn't inherently have feelings or bias. But we make it so.

Post reply on HN