Comment by pxc | Hacker News Reader

Comment by pxc | Hacker News Reader

Parent Full thread

tl;dr: if you're not on a bleeding edge rolling release, this will probably be fixed before the affected versions hit you. If not, read below for a summary of what happened, a workaround, and a proper fix you can apply as a patch.

God that's annoying as hell. Apparently the Systemd dev who added this functionality intended it for a different use case than mine or yours. They revised their implementation to better serve their original purpose without realizing it broke our (mis)use of their feature.

For convenience for anyone running a sufficiently bleeding edge distro to have this very latest release already, here's a direct link to a comment with a configuration workaround which restores the old behavior: https://github.com/systemd/systemd/issues/25269#issuecomment...

And here's the PR for the formal fix, which combines the old behavior (new config value name, read carefully) with that new 5% emergency fallback behavior, for folks who want to patch it themselves:

https://github.com/systemd/systemd/pull/25374

It's not merged yet but maintainers have approved it for merging with a few comments on config value names, so it should be safe to add as a patch.

Man, reading systemd issue #25269 is like pulling teeth.

Person A reports that he wants to hibernate after being suspended for 30 minutes, and that it used to work and is now broken. Person B doesn’t understand why, so asks why 30 minutes and not 4 hours? Person A thinks Person B is judging them for their personal preferences, and says that they chose 30 minutes because they like it. Person B then deduces that Person A is an idiot who thinks that the systemd default behavior should be determined Person A’s personal preferences.

What Person A really wants is to pull their laptop out in the morning and have it still be at 90% charge instead of 5% (or 0%!) charge. Given no other configuration options, they chose to have it hibernate after 30 minutes. They would not choose to configure the delay to 4 hours because then the battery would be a lower the next morning.

Then Person C comes along and tries to correct the misunderstandings by suggesting that there’s no reason why it cannot do both at the same time. Person B is still focused on improving safety, and still sees the configurable time as unsafe (because someone might configure it for longer than their battery can last), and misunderstands Person C. Person C has to return and reexplain, with amplification from Person D, that the default behavior should be to hibernate when the battery is low for safety, but also to hibernate at the expiration of the timer, if the timer fires first. This would satisfy everyone, even the weirdos who want their battery to stay charged when they’re not using their laptop.

Person B finally understands and says that would be fine. Elapsed time? 6.5 excruciating days, plus two more days for Person E to push a patch.

Then Persons F, G, H, I and J chime in to add their own amplifying explanations, congratulations, thanks, etc. Even I wanted to re–explain it to Person B.

If I have a choice between fixing an issue locally vs interacting with a large upstream project - who tend to always have a Person B (someone who isn't equipped to handle the subject but will nontheless form a premature opinion and attack anyone who challenges it), then I ALWAYS fix it locally because it takes more effort to convince Person B. Sometimes they silently fix it in a couple of years later, other times another project comes in and renders their project (and my local fix) obsolete.

Perhaps projects should have policies and codes of conduct that protect them against this type of harmful behavior.

Lol, having a policy against miscommunication is not going to make it less common.

Edit: note also that there were _two_ harmful misunderstandings here: Person B misunderstood Person A, but Person A also misunderstood Person B’s question. A Code of Conduct is not going to help.

A code of conduct might be able to help, but not by banning rudeness or defensiveness. If a code of conduct succeeds as part of as an effort to develop or maintain a generous culture of patience, assuming good faith, thanking others for their work, and gentleness regarding mistakes, that could short-circuit some of these interactions.

Like when B highlights that this change in suspend behavior was not only documented but '6 months of work', it kinda seems like they were defensive or irritated because they felt like their hard work to implement a useful feature was being discounted. If they felt like that work was recognized, they might have been less defensive about defending the original idea for their future and more curious about why the bug reporter wanted the behavior they wanted.

Same thing for Person A; if they had been less inclined to read Person B's question as critical, they might have explained themselves more completely earlier on.

A code of conduct treated as a rulebook to cite against people would definitely not help, but a skilled moderator pointing to a policy that encourages people to slow down, listen, be curious, or to a shared statement of values that makes people feel relaxed and safe, or to something that evokes pride in their shared participation in the project... that could have gotten this resolved more quickly.

Some projects have maintainers/authors whose kindness, deliberateness, or thoughtfulness seems to flow downstream to later contributors as a norm. Something like a code of conduct could serve in part just to encode that explicitly as a community aspiration.

But yeah you can't just say that being confusing, confused, frustrated, or frustrating is g allowed lol

A code of conduct will only prevent certain language from being used but will not change B's perception of the bug report which I assume involves his own code.

How about a communication center of excellence producing weekly communication quality reports? You won’t be able to access the project page until you have read the latest report and answered three quick questions to verify that you have read the report.

it's that a real thing any org does?

I hope not. I would leave any that tried to implement such a thing.

Yeah that sounds like a nightmare lol

> Person B doesn’t understand why, so asks why 30 minutes and not 4 hours? Person A thinks Person B is judging them for their personal preferences, and says that they chose 30 minutes because they like it. Person B then deduces that Person A is an idiot who thinks that the systemd default behavior should be determined Person A’s personal preferences.

My experience is that something like 25% percent of the people who run open source projects are just "like this" and there's nothing you can do about it. If you end up forced to deal with them because there aren't other contributors who can step in, or because they're the BDFL of the project, your best bet is just to move on and/or fork it to do what you need. I have probably half a dozen soft forks I maintain myself because the project leads are impossible to work with for exactly this reason.

This isn't about open source explicitly, to be clear. It's just more obvious and visible when it's happening because there's often 1:1 contact on bug trackers. Likewise, it obviously doesn't excuse shitty entitled behavior from issue reporters, of which there is plenty. I'm only making a comment about what I've observed from developers.

This is mostly why I don’t bother trying to fix things is open source projects. IME, people are dramatically less professional (meaning communicating clearly, considering input, etc) then I see at work. The exceptions tend to be projects mostly run by people doing it as their day job for a big company.

It's a problem where they stare themselves blind on what the ideal rule or code or mechanism should be, not realizing the requirement is something entirely different like "a user should never lose their data".

These people have no idea how to build products and have never read anything on the subject.

I should reword part of this; it’s not like pulling teeth, it’s like _having my own teeth pulled_. I imagine pulling teeth could be pretty cathartic by comparison.

Reply on news.ycombinator.com