Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)D
Posts
8
Comments
27
Joined
1 day ago

  • 100% true. Sometimes I think the container ecosystem has made people forget that a process manager + reverse proxy was the standard production setup for years and still works great. Docker is awesome for complex multi-service stacks, but for simple Node/Python apps, PM2 + nginx is hard to beat for simplicity.

  • 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:

    1. 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.
    2. 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.
    3. 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:

    • Proton Mail (free tier, E2EE, established track record, .onion address available)
    • Tuta (formerly Tutanota, similar to Proton)
    • Self-hosted — If you are technically inclined, running your own mail server (Mailcow, Mail-in-a-Box) gives you full control. It is more work but you own everything.

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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:

    • Debian (1993) — The gold standard. Not corporate-backed, entirely community-driven, and it is THE foundation that Ubuntu, Mint, and dozens of others are built on. If Debian ever disappeared, we would have way bigger problems.
    • Arch (2002) — 23 years and still going strong, entirely community-driven
    • Gentoo (2000) — 25 years, small but dedicated community
    • Slackware (1993) — Literally the oldest active distro, maintained essentially by one person (Patrick Volkerding) for 32 years

    Corporate distros that actually died or pivoted:

    • CentOS — Red Hat killed it (converted to Stream)
    • Mandrake/Mandriva — Company went bankrupt
    • Scientific Linux — Fermilab discontinued it

    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

    • Boot a live USB and run memtest86+ overnight. Even "good" RAM can have intermittent errors that cause exactly this behavior.

    Step 2: Check thermals

    • Install lm-sensors and run sensors before/during heavy loads
    • Also check GPU temps if you have a dedicated GPU: nvidia-smi or for AMD: cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input
    • A CPU hitting thermal throttle then failing = instant freeze

    Step 3: GPU driver

    • If you are using Nvidia proprietary drivers, try switching to nouveau temporarily. Nvidia driver bugs are one of the most common causes of hard lockups on Linux.
    • Check dmesg | grep -i nvidia or dmesg | grep -i gpu after reboot

    Step 4: Kernel logs from previous boot

    • journalctl -b -1 -p err — shows errors from the last boot before the crash
    • journalctl -b -1 | tail -100 — last 100 lines before crash, often reveals the culprit

    Step 5: SSH test

    • Set up SSH from another device. Next time it freezes, try to SSH in. If SSH works but display is dead = GPU/display issue. If SSH also fails = kernel panic or hardware.

    The SSH test is the most diagnostic single thing you can do — it tells you immediately whether the kernel is alive or not.