> These days, the popular apps try to inhibit blanking by talking to "systemd". The design of the systemd method easily and trivially allows an app to inhibit the screen saver, crash, and then never un-inhibit it, so now your screen will never blank again.

> Furthermore, since the systemd method uses cookies to ensure that only the app that sent "inhibit" can send the matching "uninhibit", simply re-launching the crashed video player does not fix the problem.

This sounds like a terrible design. It also doesn't appear to actually match the documentation for systemd-logind's inhibitor locks API:

https://www.freedesktop.org/wiki/Software/systemd/inhibit/

The Inhibit method returns a file descriptor:

"As soon as the file descriptor is closed (and all its duplicates) the lock is automatically released. If the client dies while the lock is taken the kernel automatically closes the file descriptor so that the lock is automatically released."

Maybe I'm looking at the wrong documentation? Or maybe the quoted text is a tiresome, ignorant rant?

What happens if the client freezes?

It looks like the inhibitior lock stays active. But the design is safe against clients that crash or otherwize exit without uninhibiting.

A nice feature request for logind would be an extra optional parameter for the Inhibit call that makes logind require the inhibitor to periodically write to the returned fd to keep the lock from going 'stale'.

Favorite quote from the article - "Fail safe" is just the most basic of all basic engineering techniques. I shouldn't even have to say this out loud.

Worst part is "They need signal handlers. " Nothing guarantees that the signal handlers are run, the program may not be in a sane state when it is about to crash from a bug, made worse that it is already hard to write a signal handler correctly without running into any of its API limitations. Basically: signal handlers are not a solution to the problem.

If that state is handled by systemd then it needs a way to reset it once the program setting it terminates. If systemd does not have the functionality for that then people are using the wrong tool for the job.

Also

"Did IQs just drop sharply while I was away?" -- Ellen Ripley

I think Apple was wrong here not to have a human reviewing rejected content, as I can't see how the screenshots were objectionable.

However, I think renaming the file and then saying, "No iOS for you!" was bad form. My guess is that they legitimately automatically block re-submission with only file renames, because they are trying to also block other images they might not want to have to see/review again.

This is the first I heard of this guideline from Apple.

This continues to be ridiculous. Games are art. Can you imagine if books weren't allowed to address the single most pressing issue of our time?

(Or, I guess the books would exist, but you couldn't buy them on Amazon or read them while you were sitting on an Ikea chair.)

They were public about it back when they announced it, which was early in the pandemic.

This certainly ought to be approved, but they acted quickly and publicly to shut down disinformation in iOS apps.

> For decades, the traditional way for a video player to temporarily inhibit the screen saver was to have a heartbeat command that ran "xscreensaver-command -deactivate" once a minute while the video was playing,

...which was a great way to inhibit screensaver when you had its timeout configured to be <= 60 seconds.

gem of the additions is definitely COVID-19, the screen-saver.

https://www.youtube.com/watch?v=xJDxZXbO8mY

1) ~~Why is this an archive.org URL rather than a direct URL to the website, https://www.jw [[ EDIT: Don't click that. Turns out jwz redirects requests from HN to something funny but nsfw. Thanks posix_me_less. ]] z.org/blog/2020/12/xscreensaver-5-45/, when the content on each match each other?~~

2) The title seems editorialized. Correct title should probably be `XScreenSaver 5.45`. No way comes to mind to do a direct link to the content the original title (`Apple Censors XScreensaver`) references because it doesn't have an element ID.

Also (and this is my opinion), this doesn't really seem like malicious censorship. Apple's just trying to curb misinformation surrounding the pandemic, it makes sense to do manual reviews for apps referencing it. Almost being unable to release the app from an older version of macOS is stupid but this kind of stupidity is par for the course with Apple.

jwz.org blocks requests referred from HN.

Well, it doesn't so much block as it redirects to something most foul.

Warning: don't click the link to jwz.org if you have to worry about NSFW images unexpectedly appearing on your screen.

> Specifically, your entertainment or gaming app inappropriately references the COVID-19 pandemic in the metadata or binary. Entertainment or gaming apps that directly or indirectly reference the COVID-19 pandemic in any way are not appropriate for the App Store.

What does a screensaver have to do with COVID ?

Given the incredibly sensitive situation everyone is in with vaccines about to be rolled out I can understand why Apple would be wanting to prevent misinformation.

> What does a screensaver have to do with COVID ?

One of the modes ("hacks") it provides shows animated viruses bouncing around the screen:

https://www.youtube.com/watch?v=xJDxZXbO8mY

So, the message "Stay the #@$! home" with a shiny virus animation is somehow inappropriate in an app classified as "entertainment".

Idk, maybe they even have a point. Games are usually meant to distract from immediate problems in the physical world, not to remind.

First entry from changelog at the top of the article:

> New hacks, covid19, headroom, sphereeversion and beats