Live data from Hacker News

A timesyncd failure and systemd's lack of debugability

utcc.utoronto.ca

21–30 of 126 posts

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

#21
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"?

As kemitche says, you have incorrectly said that I attacked the blog post author.

There are so many systemd haters out there that I immediately wonder about the motives when I read a new attack on systemd. Pointing this out is not attacking the author.

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

#22

systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about speed than determinism on a laptop). But there's no reason to choose a uid and mkdir dynamically. You want these errors at install time, not at the box's next (probably unattended) restart.

Everything that would have been "a weird problem with Foo Daemon's init script" we now call "a weird problem with systemd".

So you think that systemd-timesyncd's service file shouldn't choose the uid at service-start time.

That's not really the issue though. The issue is that for service isolation reasons (related to choosing the uid at service-start time), the service file wants to run systemd-timesyncd in a private mount namespace, but it is failing to properly set up that namespace. That's a more general issue, as there are a number of things that could trigger running the service in a private mount namespace; not just DynamicUser.

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

#23
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…

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

So pretty much the same as any other decision distro maintainers make, if you disagree with it then.

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

#24

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…

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"?

Why would someone speak-ill (attack) something they didn't have a bias against and were neutral on?

The question is not does a bias exist, it's if a bias is illegitimate. Many people who have issues with systemd have them because of their own experience, which they document. And often the very act of documenting their issues brands them as biased. When people say systemd is a regression and list their reasons, they are labeled as not having enough experience with systemd, and if they'd only give it a try, they'd see it's better. But that's the exact thing that's occurring, someone tried to do something that used to be obtainable, and their experience with systemd has been things being difficult, obscured, badly documented, undiscoverable.

If we're going to merely ask if attackers have a bias and use that as a reason to downplay or ignore their contrarian arguments, we should be asking if proponents have a bias and also use that to downplay and ignore their supportive arguments. "Are systemd developers in favor of systemd because Red Hat signs their paychecks?" is just as much an invalid assertion of bias, assuming the developers have made meaningful supportive cases that are independent of the bank account that funds them.

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

#25
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…

Distro maintainers didn't force you to do anything. They made a decision about how to allocate their limited resources. And we're past the days of Linux being a primarily volunteer OS, but a fair proportion of distro maintainers are still volunteers. They are not at your beck and call. If you want to have a Linux distro without systemd, there's several. If none of them meet your needs, pitch in with time or money to improve them. The purpose of free-as-in-libre software is that you can do the work yourself, not that you can expect others to do the work for you.

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

#26
post #25
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…

Distro maintainers didn't force you to do anything. They made a decision about how to allocate their limited resources. And we're past the days of Linux being a primarily volunteer OS, but a fair proportion of distro maintainers are still volunteers. They are not at your beck and call. If you want to have a Linux distro without systemd, there's several. If none of them meet your needs, pitch in with time or money to…

False dichotomy. I pay redhat a lot of money, short of paying people full time to maintain a mirror distro of redhat without systemd, which would be impossible given how embedded it has become into everything.

Some decisions cannot be unmade. Short of starting from scratch with gentoo (which is a Herculean effort at scale) I’m not sure what you’re saying. I cannot be disgruntled at choices because distro maintainers time is worth more than mine? Fair. But how many people have to be in my shoes for it not to be fair.

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

#27
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…

> Moreover the biggest issue /I/ personally have is the fact it was essentially forced on me by the mainstream distro maintainers. So pretty much the same as any other decision distro maintainers make, if you disagree with it then.

Most things can be replaced. Not systemd.

Prefer postfix or exim over sendmail? Sure, completely replaceable. Prefer another cron system, Logging system. Prefer another /anything/ and it used to be possible to swap.

Not any longer.

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

#28
TL;DR: systemd has bugs.

Mountain out of a mole hill.

Lack of debuggability? It's not like this is some threaded golang program you'll lose your mind attempting to make sense of in strace. systemd is a single-threaded C program, if you consider this as not debuggable it's your failing not systemd's.

There are valid complaints to be made about systemd, but from what I've seen the crux of the problem is generally the haste with which its features are conceived and developed. For the most part it's a relatively conservative codebase, in a simple and easy to understand language without much of a runtime interfering with relating the code to the underlying system calls performed.

This project doesn't have very many core contributors. It's somewhat incredible how much has been achieved with so little. But as a result, it's not perfect.

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

#29
post #26
post #25

Earlier quoted context omitted.

Distro maintainers didn't force you to do anything. They made a decision about how to allocate their limited resources. And we're past the days of Linux being a primarily volunteer OS, but a fair proportion of distro maintainers are still volunteers. They are not at your beck and call. If you want to have a Linux distro without systemd, there's several. If none of them meet your needs, pitch in with time or money to…

False dichotomy. I pay redhat a lot of money, short of paying people full time to maintain a mirror distro of redhat without systemd, which would be impossible given how embedded it has become into everything. Some decisions cannot be unmade. Short of starting from scratch with gentoo (which is a Herculean effort at scale) I’m not sure what you’re saying. I cannot be disgruntled at choices because distro maintainers…

The company I work for runs Gentoo at a global scale...

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

#30
post #26

Earlier quoted context omitted.

False dichotomy. I pay redhat a lot of money, short of paying people full time to maintain a mirror distro of redhat without systemd, which would be impossible given how embedded it has become into everything. Some decisions cannot be unmade. Short of starting from scratch with gentoo (which is a Herculean effort at scale) I’m not sure what you’re saying. I cannot be disgruntled at choices because distro maintainers…

The company I work for runs Gentoo at a global scale...

Then you either make significantly more money than we do or are able to allocate resources to that project as it is key to your business strategy. The main focus of my company is to make Video games. Not maintain operating system distributions. That’s why we pay redhat so much.
Post reply on HN