If the problem is nitrites, then the problem is not processed meats, it’s nitrites. Therefore, the headline is wrong. Kinda like the problem with making hats was not making hats, but mercury exposure.

They needed an inquiry?

If the rates have been rising, wouldn’t that prove it’s not processed meats like these? It would be something that’s being introduced at a steady rate lately, not something that’s been around for centuries.

Refuse? Why do you think processed meat is animal refuse?

Considering humans have been eating processed meats like these for centuries, I think I’ll take my chances.

It’s their machine. It’s a front door.

That’s not a vulnerability. That’s intended and desired behavior. It was really useful in this case too.

I should mention that the WebDAV share is password protected, so only he has access to do that.

Something really fun I found out recently, when my friend lost all access to his system except for a single WebDAV share by accidentally turning off all his remote admin access:

If you write “b” to /proc/sysrq-trigger, it will immediately reboot the system (like holding down the reset button, so inherently a bit dangerous).

He was running Nephele with / mounted as the share, so luckily he just uploaded that file with a single “b” in it, and all his remote admin stuff came back up after the reboot.

This absolutely can happen to stable projects. This has happened with Mastodon many times, and Mastodon has been stable for years.

It also has happened with Nextcloud many times, and again, Nextcloud has been stable for years.

It’s not a stability thing, it’s an automation thing. We as devs can only automate so much. At a certain point, it becomes up to you, as the administrator, to manually change things. Things like infrastructure changes, and database migrations, where the potential downtime if we automate it is something we need to consider.

This is very cool, but also very dangerous. Many projects release versions that need some sort of manual intervention to be updated, and automatically updating to new versions on docker can lead to data loss in those situations.

Here’s a recent example from Immich:

https://github.com/immich-app/immich/releases/tag/v1.133.0

It is my humble opinion that teaching newbies to do automatic updates will cause them to lose data and break things, which will probably sour them from ever self hosting again.

Automatic OS updates are fine, and docker update notifications are fine, but automatic docker updates are just too dangerous.