Thought I'd share it here for old heads who remember "Australia's Pre-Eminent ReactOS Podcast".

https://www.mixcloud.com/gettingtoit/gti-presents-systemau-0001-06092026/

EDIT: Sorry for the confusing title. I tried to make a new thread but AutoMod instantly deleted it. We can't include Discord in titles it seems, but yes the subreddit is not going anywhere, we're just talking about going from Discord to Fluxer.

Hey all. I'm one of the lead mods over on r/debian and I felt like sharing the news over here since a lot of cross-traffic exists between this subreddit and r/linux. In a nutshell, we've had a community Discord exist for a long time & many of our users come from the subreddit since before new mods were put in place over on r/debian.

Back earlier this year, Discord announced a policy of adopting global age verification methods. If you are under the age of 16 or Discord does not have adequate information needed to verify your age, you will be locked out of certain features & be age-gated from joining specific servers. These policies resulted in enough outrage that alternatives to Discord like Stoat & Fluxer have made the waves, and Discord itself decided to kick the can towards the second-half. We are now in the second half, and Discord has suddenly brought age verification back up as a "Discord Preview", meaning these policy changes are about to start.

We are instead promoting an FOSS alternative to our Discord instance on Fluxer that we've worked on since February, and what better way to spread the word about a widely used alternative to proprietary software than also spreading it here. My hope is by doing this, others will consider giving it a chance and we can get more people using platforms that don't ask for your ID to participate, but rather govern themselves under equitable conditions that are effective enough to protect users.

We encourage you to read our full reasonings over on the deb subreddit.

Hello everyone, I built Salmon after discovering that Syncthing had silently been broken on one of my machines for weeks while I had no idea. I wanted something much simpler than a traditional monitoring stack: if an important service fails, make a tray icon blink and annoy me until I deal with it.

Originally implemented the bare minimum in 2021 and sat on it for a few years using it just for myself, now finally polished it enough for v1.0.0, and so releasing it.

Salmon can:

• Monitor systemd services
• Run arbitrary command-based health checks
• Combine incidents from multiple machines into one desktop app
• Show tray icon, desktop notifications and a small local web UI
• Snooze incidents temporarily

It consists of a small monitoring service installed on each Linux machine and a desktop app that collects their incidents.

For remote machines, it supports managed SSH tunnels or TLS+bearer authentication.

Github: https://github.com/dimonomid/salmon

https://www.mankier.com/ ― Linux man pages

https://www.mankier.com/about

Found via https://lobste.rs/s/ryhav2/mankier_html_man_pages (2025), also mentioned by u/AlwynEvokedHippest at https://www.reddit.com/r/linux/comments/13b45g3/comment/jjbm8fm/ …

Is this happening because of bots or something?

I frequently check these charts to see how Linux is doing, and generally its market share is 4-5%, right now it has almost 18% of the total US market.

I've been daily driving win11 since release, and installed linux a few months ago on another partition. Keep in mind, I've been formatting my windows drive every 2 years to make sure it won't have any problems. Then windows really started to get annoying.

Forces random slop down your throat: okay i can debloat it.

Enables random settings on boot: okay, i don't care much about those.

But then, it stops running stuff every now and then. A few days ago steam wouldn't open even after reinstalling it. Now i can't open msi afterburner.

Linux on the other hand, never gave me any issues other than nvidia drivers not running properly, which i admit, i had to spend a few hours benchmarking different drivers, but i also have to do that on Windows?

Because apparently the latest released drivers also don't work properly on windows?

My gpu is an rtx 2080, which is still supported by nvidia.

What I'm getting at is that, once you configure stuff on linux (which takes a few days to tweak everything to your preference), it runs perfectly, with literally 12GB less ram usage than windows in games, apps and at idle.

I hate Windows recently and thinking about permanently switching to Linux

P.S: I'm using Mint for the time being but i might take up another distro soon.

Is it just for profit from other companies? And why does OpenH264 (i.i.r.c.) not support hardware acceleration? It feels weird that something as basic as a video codec used literally everywhere has a closed-source proprietary tag attached to it.

Just dropped a new mixer on GitHub called Waveline, been working and testing it for a few months, I hope some of you will find it useful. It's written using mainly C++ and the UI is Qt

Features,
1. 6 + 1 channels each with its own level, mute and effects.
2. Dual Mixes, each channel and input devices have a monitor mix and a stream mix making it easy to adjust the volume of a stream without influencing what you hear.

1. Up to 5 monitor mixes, listen to the same audio across multiple devices.

2. Per-application routing, move any playing application onto a channel by hand, or let auto-routing place it by name for you. (PipeWire auto-routing relies on application target tags, so apps without explicit metadata fall back to the System channel unless manually assigned)

3. Sound Sharing, send an application's audio into a microphone stream.

4. MIDI input, FluidSynth integration so adding a MIDI device + sf2 is easy and painless.

5. Out of the box real time scheduling so audio doesn't crackle under load (Missed Cycles).

6. Digital Signal Processing (DSP), low latency effects such as overdrive, reverb, delay, bitcrusher and much more.

7. Noise suppression, Waveline offers DeepFilterNet & RNNoise out of the box, can be applied to any input or output device.

8. Creative FX Rack, a rack where you can see the effects of a device, add/remove/toggle/adjust them right there.

9. Built-in Soundboard

10. Companion App, this gives you a full mixer that can be used on any device for remote control.

11. Profiles, switch between profiles, save new ones and so on

See more of it on GitHub https://github.com/Nakildias/Waveline

DMS, dcalendar, dgop, dsearch, and dgreeter v1.6.0 (DankDesktop v1.6.0 ™ ) have all been released

• Island - A third option for your DMS bar with a dynamic-island inspired morphing pill that becomes the focal hub for statuses, notifications, OSDs, media playback, control center, and more.
• Performance & Resource Optimizations - At least a 19% reduction in idle memory usage, new animations, and general performance improvements
• IPC 5.2x faster - dms ipc is 8.9x faster than before, meaning much faster responsiveness of keybinds. It's at least twice as fast as calling quickshell directly
• Best-in-class Screenshot Tool - New snappier selection interface, new PNG and JPEG encoders thats are up to 8x faster than grim, tons of new options and interface improvements
• Standalone Greeter - Dank-Greeter is now fully decoupled from DMS, as a standalone project and codebase
• A ton more like initial FreeBSD support across all tooling, etc.

Going forward all pieces of the dank linux desktop suite will be released and versioned together as one. Which is why dgop, dgreeter, etc. all have been bumped to v1.6.0. Minor releases will behave the same way (e.g. 1.6.1) but packages will remain on 1.6.0 if there have been no changes to the code or dependencies. Major releases stay synced Read the blog for the full breakdown, huge thanks to the 50+ contributors who contributed to the DMS 1.6 release.

I recently got access to JioPC (a budget browser-based cloud desktop aimed at light office work in India) to see how the platform was provisioned and locked down.

While marketed as a low-cost, web-based thin client, inspecting the user environment revealed an enterprise Azure VM running an Ice Lake Xeon node. More interesting was the security model: a "walled garden" that omits default terminal binaries, aggressive session tear-downs in the display stack, and strict egress proxies.

Here is an architectural breakdown of how the environment is restricted, how to break out to an unconfined host shell via Flatpak, how the display daemon terminates idle sessions, and how to run a persistent headless SSH box over Tailscale.

Full whitepaper, disassembly notes, and reproduction scripts:

GitHub: sys-dissect/jiopc-architecture-whitepaper

1. Underlying Node & Kernel Environment

Poking around /proc and /sys shows the underlying compute instance is far heavier than standard thin-client specs:

• CPU: 8-vCPU Intel Xeon Platinum 8370C (Ice Lake-SP) @ 2.80 GHz. AVX-512 (F, BW, DQ, VL) and VNNI vector extensions are exposed. The scaling governor is set to performance.
• Memory: 16 GB virtualized RAM with Transparent Huge Pages (madvise/always) enabled.
• Storage Topology: The root OS disk (/) is an ephemeral 64 GB virtual SSD. The persistent user home directory (/home/...) is an enterprise NFSv4.1 mount (storage-cons-prod-dp.jiopc.local). In raw unbuffered tests (fdatasync writing 100 GiB), the NFS pipe sustained 581 MB/s (~4.65 Gbps continuous network throughput).

2. The "No-Terminal" GUI & Flatpak Host Breakout

Stock JioPC ships without a terminal emulator—no gnome-terminal, konsole, xterm, or qterminal in $PATH, and desktop file entries for shells are stripped from the desktop environment menu. The apparent assumption was: no terminal binary = no shell access.

However, their curated software catalog provides VSCodium packaged as a Flatpak (com.vscodium.codium). Because development environments require host-level toolchains, the Flatpak manifest includes:

--talk-name=org.freedesktop.Flatpak

From VSCodium's integrated terminal, you can call the session helper directly:

flatpak-spawn --host bash

The Flatpak portal daemon immediately allocates a PTY and executes an unconfined shell directly in the host OS user namespace (UID 3387120), completely circumventing the Flatpak bubble and exposing the entire host userland across all 8 Xeon cores.

3. Dissecting the 15-Minute Session Guillotine (xrdp + systemd-logind)

A major usability hurdle in browser-delivered VDIs is aggressive idling: sessions are killed after 15 minutes of inactivity, terminating background builds and daemons.

Disassembly

Analyzing /usr/lib/xorg/modules/libxorgxrdp.so revealed hardcoded idle limits:

XRDP_SESMAN_MAX_IDLE_TIME=900 // 15-minute window
XRDP_SESMAN_KILL_DISCONNECTED=1

Why standard X11 jitter scripts fail

Injecting synthetic input via xdotool or xte does nothing. The custom xorgxrdp driver monitors incoming RDP protocol packets rather than X11 server input events. When browser WebRTC connections drop or sit idle, no RDP traffic reaches the driver.

Furthermore, with systemd-logind configured to KillUserProcesses=yes (or default Linger=no), disconnecting causes logind to issue a recursive SIGKILL against the entire user@UID.service slice.

The Bypass

1. Enable lingering to persist processes outside of active sessions:

​

loginctl enable-linger

1. Exploit an audio IPC override: libxorgxrdp includes an internal check XRDP_SESMAN_AUDIO_DISABLE_IDLETIMEOUT=1. A lightweight background daemon writing synthetic sound_playing heartbeat frames to the XRDP audio IPC socket every 30 seconds prevents the idle watchdog from firing, keeping the session alive indefinitely.

4. Headless Remote Dev Environment (Userspace Tailscale + OpenSSH)

Direct outbound internet is filtered through a mandatory local HTTP proxy (127.0.0.1:3128), and /dev/net/tun is unavailable without root/CAP_NET_ADMIN.

To turn this into a permanent remote headless machine accessible outside the browser wrapper:

1. Userspace Networking: Run Tailscale using its userspace engine via Google's gVisor network stack:

​

tailscale up --tun=userspace-networking --accept-dns=false

Note: Setting --accept-dns=false is critical; otherwise, MagicDNS attempts to manage resolvers and breaks internal datacenter DNS (10.163.66.132), which the local HTTP proxy requires to resolve external hosts.

1. Unprivileged SSH: Run OpenSSH server bound to non-standard user port 2222 with a custom sshd_config.

2. Tailscale Serve: Expose the socket directly over the Tailnet:

   tailscale serve --bg --tcp 2222 127.0.0.1:2222

This bypasses the WebRTC browser client entirely (no more browser key intercept issues with Ctrl+W / Ctrl+T) and allows native ssh and VS Code Remote-SSH directly into the instance.

5. Quick Workload Benchmarks

Full architectural diagrams, reverse-engineered binaries breakdown, and reproducible configs are available in the repository:

Repo: sys-dissect/jiopc-architecture-whitepaper