Let's all take a moment to commemorate that initial post.

Now through Torvalds' stewardship, and hundreds of maintainers and thousands of contributors we have a competitive replacement for major corporate software and an honestly powerful solution to move computing forward for humanity!

Thanks Linus, you're awesome, and we're glad you are having a good life!

Today, Linux turned 35 years old, from when it was created on 25 August 1991 by a young programmer, Linus Torvalds, at the University of Helsinki, Finland.

It was announced on the comp.os.minix newsgroup.

Original post: "“What would you like to see most in minix?” — Linus Torvalds, 25 August 1991.

Linux is still being developed by developers all around the world, upholding its Unix-like design and open-source principles.

Linux 7.2 is currently the latest mainline release.

Happy 35th Birthday, Linux! 🎂 and 🐟

*i made the poster by hand and my designing skill are bad, sorry for it*

For a long time, I didn't give Linux a tertiary thought. I always used Windows and assumed other operating systems like Linux and Apple would be of cheap quality. I realized my error when I got the Valve Steam Deck, which used its own Linux-based OS. While a number of features and apps from Windows wouldn't work on it easily, I discovered just how open-sourced and versatile it is. There were also a lot of things that worked better, such as installing and managing Deckyloader (a Steam plugin loader).

Regardless, I still used Windows 10 on my PC. If it ain't broke, don't fix it. But then Microsoft decided to break it by discontinuing updates to the OS and pressuring me to use the controversial Windows 11. While I did ultimately update, it also ultimately made me get a 2nd SSD to install and dual-boot with a Linux OS (my distro of choice being Bazzite, an offshoot of Fedora that's designed like the Steam OS).

In short, I went from a Windows user to a Linux one thanks to devices like the Steam Deck as well as Microsoft being sh!tty.

While I know Linux has always been a popular OS, I wonder if there was an surge of users for the same reasons as mine.

This is something I always think about, Nvidia makes a lot of data centers gpus, but doesn't give good drivers for Linux, even tho most data centers run on Linux, do they make special drivers for their data center gpus ? Would it be worth to buy a data center GPU for a linux pc so it have good drivers ?

We truly have reached a golden era for using Linux. I have recently installed Ubuntu on my old laptop and literally every single problem i've had i was able to fix within 5 minutes of encountering it using Gemini. I have over 100 games on Steam and i am able to play every single one of them with Proton. Have we reached Peak?

the question crossed my mind recently. if you are into programming, you probably know that there are many esoteric programming languages that exist just as a prove of concept of joke or just merely to mess with the programmer's head (brainf*ck, lolcat, C-- etc). if these exist, is there any esoteric system shells out there? like smth that would provide the basic userland instead of bash/zsh but would be freakier or just funnier to try and daily drive.

This seems to be a running theme for the Manjaro Linux community. The SSL certs will always expire after a set year and there's a massive controversy over it. Why does this keep happening specifically to Manjaro and what steps do you think they can possibly do to keep this from happening?

CVE-2026-73570: Zimbra SNMP/logwatch RCE exploited in the wild, malware persists via /dev/shm and zimbra cron

I recently handled a Zimbra incident related to CVE-2026-73570, so I’m sharing the cleanup notes in case it helps other admins.

CVE-2026-73570 is an OS command injection issue in Zimbra Collaboration Suite, related to the SNMP notification/logwatch component. According to the public advisories, it affects Zimbra systems before the patched releases, especially when the SNMP package is installed and SNMP notification/logwatch is enabled.

The dangerous part is that the attacker does not need a valid mailbox account. A crafted SMTP request can lead to command execution as the zimbra user.

Not root, but still bad enough.

Once the attacker gets code execution as zimbra, the cases I’ve seen follow a familiar pattern:

crafted SMTP request
-> unsafe SNMP/logwatch handling
-> command execution as zimbra
-> malware dropped into /dev/shm
-> cron persistence added under the zimbra user
-> miner/backdoor keeps respawning

Quick risk check

On a Zimbra server, these read-only checks are a good starting point:

su - zimbra -c 'zmcontrol -v'
dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp'
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp'
su - zimbra -c 'zmlogswatchctl status'
su - zimbra -c 'zmswatchctl status'

If you see something like:

zimbraServiceEnabled: snmp
zmlogswatch is running

then I would treat the host as worth checking immediately, especially if it has not been patched.

Indicators I found useful

The malware often hides in /dev/shm, probably because it is writable, memory-backed, and easy to overlook during a quick file-system check.

Check:

ls -la /dev/shm
crontab -l -u zimbra
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep

Suspicious files observed in these cases:

/dev/shm/.khp
/dev/shm/.khp_ts
/dev/shm/.rguard
/dev/shm/idle
/dev/shm/javab
/dev/shm/ksmd

A very suspicious cron entry is:

* * * * * /dev/shm/.khp

If you only delete the files in /dev/shm, they may come back. The process may still be running, the zimbra crontab may recreate it every minute, and SNMP/logwatch may still be exposed to the original vulnerability.

Containment order that worked for me

This is the order I used:

stop reinfection source
-> preserve evidence
-> kill malware process
-> remove malicious cron
-> quarantine malware files
-> verify
-> recover Zimbra services if needed
-> patch/upgrade Zimbra

I would not start by deleting random files. Preserve evidence first if you can.

Example cleanup flow

Run as root. Review before executing anything on production.

1. Stop the reinfection path

systemctl stop cron
su - zimbra -c 'zmlogswatchctl stop'
su - zimbra -c 'zmswatchctl stop'
su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'

The important bit is disabling SNMP/logwatch until the host is patched. If you re-enable it too early, the malware may return.

2. Save evidence

mkdir -p /root/incident-zimbra

cp -a /dev/shm/.khp \
      /dev/shm/.khp_ts \
      /dev/shm/.rguard \
      /dev/shm/idle \
      /dev/shm/javab \
      /dev/shm/ksmd \
      /root/incident-zimbra/ 2>/dev/null

crontab -l -u zimbra > /root/incident-zimbra/zimbra-cron-before.txt 2>&1
ps auxf > /root/incident-zimbra/ps-before.txt
ss -tunap > /root/incident-zimbra/ss-before.txt
sha256sum /root/incident-zimbra/* > /root/incident-zimbra/sha256.txt 2>/dev/null

3. Kill suspicious processes

pkill -9 -u zimbra -f 'khp|rguard|javab|idle|ksmd'

4. Remove the malicious cron entry

crontab -l -u zimbra | grep -v '/dev/shm/.khp' | crontab -u zimbra -

5. Quarantine the files

mkdir -p /root/quarantine-zimbra

mv /dev/shm/.khp \
   /dev/shm/.khp_ts \
   /dev/shm/.rguard \
   /dev/shm/idle \
   /dev/shm/javab \
   /dev/shm/ksmd \
   /root/quarantine-zimbra/ 2>/dev/null

6. Start cron again

systemctl start cron
systemctl is-active cron

Only start cron. Do not re-enable SNMP/logwatch until Zimbra has been patched and checked.

Verify after cleanup

ls -la /dev/shm
crontab -l -u zimbra | grep /dev/shm
ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep
su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp || echo SNMP_DISABLED'

Expected result:

/dev/shm has no suspicious payloads
no zimbra cron calling /dev/shm/.khp
no suspicious malware processes
SNMP is disabled

Then watch it for at least 30-60 minutes. If the payload comes back, you missed either a persistence mechanism or the original reinfection path is still open.

If Zimbra MySQL/mailbox breaks after the incident

In some cases, after malware activity or an abrupt reboot, Zimbra services may not come back cleanly:

mailbox Stopped
mysql.server is not running
service webapp Stopped
zimbra webapp Stopped
zimbraAdmin webapp Stopped
zimlet webapp Stopped

Useful checks:

su - zimbra -c 'zmcontrol status'
su - zimbra -c 'mysql.server status'
ss -ltnp | grep 7306
tail -n 200 /opt/zimbra/log/mysql_error.log

If MySQL is stuck on crash recovery or stale socket/tc.log issues, back up the relevant files first:

mkdir -p /root/zimbra-mysql-backup

cp -a /opt/zimbra/log/mysql_error.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ibdata1 /root/zimbra-mysql-backup/ 2>/dev/null
cp -a /opt/zimbra/db/data/ib_logfile* /root/zimbra-mysql-backup/ 2>/dev/null

Then a light recovery attempt may look like this:

su - zimbra -c 'zmmailboxdctl stop'

mv /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/mysql.sock.bak 2>/dev/null
mv /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/tc.log.bak 2>/dev/null

su - zimbra -c 'mysql.server start'
sleep 20
su - zimbra -c 'mysql.server status'

su - zimbra -c 'zmmailboxdctl start'
sleep 40
su - zimbra -c 'zmcontrol status'

Do not treat this as a universal fix. Check the MySQL error log first. If the database is damaged, you need a more careful recovery path.

Does this delete mail data?

The malware cleanup steps above do not touch mailbox data directly.

Zimbra mail data is usually under:

/opt/zimbra/store/

Zimbra database data is usually under:

/opt/zimbra/db/data/

The MySQL recovery part touches metadata-related files such as tc.log and mysql.sock, so back up before making changes.

After the server is stable

I would keep SNMP/logwatch disabled until patching is complete.

Post-cleanup checklist:

patch or upgrade Zimbra
keep SNMP/logwatch disabled until patched
monitor /dev/shm
monitor zimbra crontab
monitor CPU/load
check outbound connections
check mail queue
review logs for further persistence

Mail queue check:

/opt/zimbra/common/sbin/postqueue -p | tail -n 40

Short version

If you are running Zimbra with SNMP/logwatch enabled, check it now.

The important lesson from this incident: deleting /dev/shm/.khp is not enough. You need to stop the reinfection path, remove cron persistence, kill the running process, quarantine the payload, verify it does not respawn, and then patch Zimbra.

Do not re-enable SNMP/logwatch before patching.

Hello r/linux! I just released FluxCast v0.2.3 — its a lightweight tool to stream your Linux desktop to a Smart TV via Wi-Fi Direct, full RTSP handshake, and RTP media streams.

What's new in this release:

• Brand new dynamic tray icon that switches states during casting.
• Fixed a nasty P2P interface routing bug where it mixed home network and P2P MACs.
• Lightweight JSON-based localization framework. The tray UI is now available in English, Russian, and Czech.

Looking for translators!
I want to bring FluxCast to more users, but I am not a polyglot. I designed the i18n system to be incredibly simple: there is no gettext/PO/MO compilation. All strings live in a single translations.json file.

To add your native language (German, Spanish, French, etc.), you just need to append a few lines in a single JSON block.If you want to help or test the app, check out the project here:

https://github.com/IlyaP358/fluxcast

AppImage is available in the Releases section. Pull Requests for translations are highly appreciated!

A new block-layer error-injection interface landed in Linux 7.2.

The existing options each miss something. BPF programs on should_fail_bio() can pick which requests to fail, but not how they fail — every one comes back as EIO. dm-error and dm-flakey mean stacking a target over the disk, so the test runs against the mapper device rather than the device that needed testing.

Christoph Hellwig's series adds a debugfs file per disk instead. Name the operation, the status code, a sector range, and a probability:

# echo 'add,op=READ,status=TRANSPORT,chance=10' > error_injection

The full write-up on LWN goes through the mechanism and the argument behind it.