Linux Migration Guide
the.unknown-universe.co.uk
Sick of Windows bloat and ads? Reclaim your desktop with this practical Linux migration guide. Covering distros, privacy, and gaming compatibility for 2026.

I’ve been using Linux for years, but as the proprietary alternatives get more aggressive with telemetry and adverts, I wanted to document the choices that actually keep my desktop predictable.

This isn’t a manual, but a practical overview of my setup. From why I’ve settled on CachyOS and KDE Plasma for my main rig, to the reality of dealing with proprietary software and app compatibility in 2026. It’s just an honest look at the transition and why I’m done with the corporate defaults.

  • dan@upvote.au
    72·
    7 days ago

    Do you have any actual problems with systemd, or do you just want SysV init scripts to stick around forever?

    Maybe systemd isn’t the best, but it’s way better than a bunch of mostly unstructured shell scripts, and more secure (it’s pretty easy to reduce privileges, sandbox the filesystem, restrict syscalls, etc per service just by editing the unit file)

    • spacetff@lemmy.mlEnglish
      1·
      12 hours ago

      Huh…? Unstructured…? Please explaln or are you just a troll or a lenfart puttering lover…?

      • dan@upvote.au
        1·
        1 hour ago

        Yes, unstructured. Every script is its own special snowflake that does things a bit differently.

        There’s no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I’m most familiar with Debian where some service (but not all) implemented it with start-stop-daemon, but other distros and OSes handled it differently.

        Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.

        When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.

        Systemd units were a logical progression from supervisord services.

    • forestbeasts@pawb.social
      5·
      7 days ago

      Personally, my problem with systemd is that it’s slowly trying to take over everything it possibly can, and be as hard to remove as possible.

      It’s not “so you just think it’s all a single binary!”. No, I’m 100% aware it’s multiple binaries. The problem is that it’s a single project, and that’s too much power to give to one single project.

      “oh but you can swap out the individual parts!” Sure. For SOME of them. Until you swap out the systemd init and suddenly have to relearn a shitton of completely random other stuff because systemd was doing a boatload of other things. Might as well get that out of the way early and use normal other projects for the other stuff, and also ditching the init system can’t hurt just to reduce their stranglehold.

      Also OpenRC might be worth looking into. “systemd or Old™ Nasty™ sysv scripts” is a false dichotomy, openrc’s init scripts are declarative like systemd units (and it also supports sysv scripts). There are also totally different init systems (but we don’t know much about them, we started with systemd and then jumped to openrc recently).

      – Frost