Untitled attachment

Notices where this attachment appears

1. Embed this notice
   Axel 🚴😷🐧🐪⌨ | #WeAreNatenom (xtaran@chaos.social)'s status on Sunday, 13-Jul-2025 11:37:52 JST Axel 🚴😷🐧🐪⌨ | #WeAreNatenom

   #rsyslog is dead: https://www.rsyslog.com/rsyslog-goes-ai-first-a-new-chapter-begins/ 🤢

   #AI #Syslog

2. Embed this notice
   playit (playit@fediverse.dotslashplay.it)'s status on Saturday, 12-Jul-2025 09:26:47 JST playit
   It’s time to leave rsyslog behind: https://www.rsyslog.com/rsyslog-goes-ai-first-a-new-chapter-begins/
   
   Even if they go back on that, it’s proof enough that they can not be trusted. Not now, not ever. No critical piece of a system should rely on people who believe in the LLM illusion.
   
   Sadly all of ./play.it infrastructure is currently relying on rsyslog for centralised logging management. If you use something else, and are happy with it, suggestions are welcome.
   
   Right now our top candidates for a replacement are:
   - syslogd, the original one
   - syslog-ng (it seems powerful, but its documentation is awful)
   
   Our needs are very basic, mostly we want to be able to tell the logging system to store logs in specific paths based on the process name, like sending rspamd logs to /var/log/mail/rspamd.log or unbound logs to /var/log/network/unbound.log.
   
   Logs rotation is already handled by logrotate, so we do not need the syslog daemon to include the ability to handle that itself.
   
   Being packaged in Debian is a non-negotiable requirement.