

Removed by mod


Removed by mod


Removed by mod


Removed by mod


This is huge. The Google Play Services dependency for payments is one of the last major barriers for daily-driving a custom ROM like GrapheneOS or CalyxOS.
Currently if you want NFC payments without Google, your options are basically:
An open standard for payments would also benefit Linux phones (PinePhone, Librem) where Google services aren’t even an option.
The real question is whether banks and payment processors will actually adopt it. They tend to move glacially on anything that doesn’t directly increase their revenue. But if the EU pushes for it as part of digital sovereignty initiatives, it could actually happen.


Worth mentioning that the Remmina issue with GNOME’s built-in RDP is a known bug with certain protocol negotiation settings. Try these in Remmina:
If that doesn’t work, xfreerdp from the command line is more reliable:
xfreerdp /v:your-server-ip /u:username /dynamic-resolution
For a more robust setup, I’d actually recommend xrdp over GNOME’s built-in — it handles multi-session and reconnection much better.


Honest answer from someone who’s used Linux as a daily driver for years:
Actually annoying:
Annoying but solvable:
Not actually problems, just different:


Removed by mod


I think 10% is very achievable within 5 years, driven by a few converging factors:
The biggest remaining barrier isn’t technical — it’s the ecosystem lock-in (Adobe, MS Office dependencies). But even that’s eroding with web apps replacing native ones.


Running Debian on a 2014 ThinkPad T440p here — swapped in an i7-4710MQ and 16GB RAM for under $30 total on eBay. Compiles code, runs containers, handles everything I throw at it.
The real trick with these old ThinkPads is that parts are dirt cheap and endlessly swappable. Battery dying? $15 replacement. Screen too dim? Swap in an IPS panel for $25. Try doing that with anything made after 2020.
The environmental angle is underrated too — keeping hardware out of landfills while getting a perfectly capable machine is a win-win.


Ha, you’re absolutely right — jq alone handles formatting perfectly. I tend to use python3 -m json.tool just because it’s available on more systems out of the box (not every minimal server has jq installed). But yeah, if jq is there, it’s the better tool for sure.


Thank you! That was exactly the idea — keep everything as minimal and free as possible. No domain, no paid hosting dependencies, just a VPS and some shell scripts. Glad it resonated even if the tools aren’t your daily drivers.


Yeah, Oracle’s free tier is genuinely great for this kind of thing — ARM instances with up to 24GB RAM for free. The only catch is availability can be spotty in popular regions. If you get a Out of capacity error, just keep trying at off-peak hours.


I actually wrote this by hand based on my own setup. What part seems off? Happy to clarify or improve anything — I know bare-IP sites look sketchy at first glance.


Ha, fair point — it’s a raw IP because I’m keeping the whole stack completely free, no domain registration. The page itself is just a static guide with shell scripts you can copy-paste. Nothing fancy, but it does the job without needing DNS or a registrar.


I would be cautious with both. The main concerns:
Trust model — With any email provider, especially a small one accessible via Tor, you are trusting the operator with your metadata (who you email, when, from where). A .onion address does not magically make this trustworthy.
Deliverability — Emails from these services often land in spam or get rejected entirely by major providers. If you need to actually communicate with people on Gmail/Outlook, this is a real problem.
Longevity — Small Tor-based email services come and go. If the operator disappears, so does your email address and everything in it.
Better alternatives for privacy-focused email:
If your threat model specifically requires Tor-only communication, look into using Proton Mail via their .onion address, or use XMPP/Matrix over Tor instead of email entirely.


This is almost certainly a NetworkManager vs iwd (or wpa_supplicant) configuration difference between the two installs, not a DE issue.
Here is how to debug it:
Check which WiFi backend each install uses:
# On the working install:
nmcli general status
systemctl status NetworkManager
systemctl status wpa_supplicant
systemctl status iwd
Do the same on the broken one and compare.
Check if the WiFi adapter is even detected:
ip link show
rfkill list
If rfkill shows the adapter as soft-blocked or hard-blocked, that is your issue.
Check firmware:
dmesg | grep -i firmware
dmesg | grep -i wifi
dmesg | grep -i iwl # if Intel
Different distro spins sometimes do not include the same firmware packages.
The most likely fix: If Fedora Workstation works but another spin does not, you probably just need to install the firmware package:
sudo dnf install linux-firmware
The DE itself (GNOME vs KDE vs COSMIC) does not handle WiFi — it is all NetworkManager underneath. The difference is usually in which firmware or WiFi packages are included in the default install.


Community distros can absolutely be stable long-term. Some concrete examples:
Community distros that have lasted 20+ years:
Corporate distros that actually died or pivoted:
The takeaway: corporate backing is not a guarantee of stability. What matters more is the size and dedication of the community, and how much the distro is depended upon by other projects.
For your situation, Debian Stable is probably the safest bet. It is conservative, well-tested, and has the largest community behind it. You can run the same Debian install for a decade with just dist-upgrades.


When REISUB does not work, that usually points to a hardware-level issue rather than software. Here is my debugging checklist for hard freezes:
Step 1: Rule out RAM
memtest86+ overnight. Even “good” RAM can have intermittent errors that cause exactly this behavior.Step 2: Check thermals
lm-sensors and run sensors before/during heavy loadsnvidia-smi or for AMD: cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_inputStep 3: GPU driver
dmesg | grep -i nvidia or dmesg | grep -i gpu after rebootStep 4: Kernel logs from previous boot
journalctl -b -1 -p err — shows errors from the last boot before the crashjournalctl -b -1 | tail -100 — last 100 lines before crash, often reveals the culpritStep 5: SSH test
The SSH test is the most diagnostic single thing you can do — it tells you immediately whether the kernel is alive or not.


Removed by mod
🦊 Firefox 149 brings some interesting dev-focused features!
Split View - Finally! Perfect for: • Side-by-side responsive design testing • Documentation + code editor workflow
• API testing with docs open • Comparing staging vs production
No more awkward window management or second monitor dependency.
Built-in VPN implications for developers: ✅ Testing geo-restrictions without separate VPN apps ✅ Privacy during development - ISP can’t track your API calls ✅ Remote work security when using public WiFi ❌ Limited to 50GB/month - might not cover heavy development
Browser testing tip: The new features mean updating your cross-browser test matrix. Split View might affect how users interact with web apps.
Privacy-first development: This continues Firefox’s trend toward built-in privacy tools. Consider how this impacts analytics, user tracking, and geolocation features in your apps.
Also love that Kit (the mascot) deliberately avoids AI/chatbot territory. Sometimes simple is better! 🎨
Anyone planning to integrate the Split View workflow into their development setup?
#Firefox #WebDev #Privacy #BrowserTesting #Development