Roy needn't go far for reasons to delete Debian, he only needs to read Techrights. I mean, look at all this.
"I've also read (from a source Roy should consider reliable) that Stallman is aware of the problems created by Microsoft systemd, which Debian has used to undermine and divide against its community and developers for years."I had fewer reasons than this when I migrated from Debian nearly six years ago; none of us get to choose what Roy uses at home, though I often wonder why he persists in relying on such an incredibly toxic distribution.
Then again, migration is often far from simple -- and if you count activism, Roy has several full-time jobs.
The goal then isn't to put pressure on Roy which he can just shrug off as simply as he would not having wings or extra limbs, but to try to make it a bit easier for him to imagine his world without the horrors of Debian. "Better the Devil you know," sure, but Roy knows that's really not true.
Surely one of the reasons Roy wouldn't change his distro is that he would have to change his workflow; this is like gambling with both spare time and extra trouble. A migration that's smooth as possible would minimise the gamble and instability likely to result from changing distros.
Another thing to consider would be how much control the change is either giving or taking away from Microsoft.
While I could write an article about the long-term advantages of moving to a more modular distro like Tiny Core, as I did before moving to BSD, this article will instead focus on seeking short-term benefits and minimising workflow disruption; if we want to tempt Roy away from Debian, I doubt Tiny Core is the best place to start. I simply went to more trouble to make it suit my own needs than I want to subject Roy to if he even seriously considered doing this soon.
"In better days, Ubuntu was a nice gateway to Debian, but today it is increasingly monopolistic..."I do however, note that Techrights itself has migrated to something more minimalist; perhaps Roy would benefit from using Alpine at home, perhaps not. It should be considered, even though it's not a choice I would likely make as I believe Alpine has a GitHub-based init system. Although it is a step up from systemd, in terms of being GitHub-based this would make Alpine a lateral move from what he uses now. Though as I said, there are lots of reasons to leave Debian.
I think it is best to let Roy worry about which distro he would move to IF he decided to move, and I would also recommend the following criteria towards that decision:
* A distro that is not itself developed on GitHub, obviously. This counts Void out.
* A distro that does not use systemd.
* A distro that is as close to Debian as possible, but is not Ubuntu or Devuan.
Obviously my first choice for Roy would be OpenBSD, but even for me I decided to switch distros before switching operating systems -- for Roy this step would help even more.
Devuan was considered before the Alpine migration I think, and for whatever reason it was dismissed, Roy knows I have others. Besides, I think Devuan has most of the problems that Debian has except for a couple well-known exceptions.
Roy has a setup consisting of several machines and even more screens. He most likely manages those screens with either xrandr or a tool that uses xrandr. Even if Roy were to switch to BSD, this would not likely change. Probably the most trouble I've had with more than one screen is from Tiny Core -- you need to install the "graphics" package to get a window system and xrandr that can handle more than one screen.
Roy likes Falkon and I confess, I do not keep track of which distros support KDE. I've had nothing but complaints about KDE since 4.x (props to Trinity) and their recent cancel-fest was not inspiring. I don't blame Roy at all for liking Falkon relative to other choices though; web browsers suck.
"I had fewer reasons than this when I migrated from Debian nearly six years ago..."I think Roy makes heavy use of tmux and it is incredibly standard; even OpenBSD comes with tmux included (though I've deleted it because it's developed on GitHub).
You can migrate piecemeal without a plan, but for Roy I recommend a plan (which he can tweak as it suits him) since it will increase both the ease and likelihood of an actual move. The plan is also piecemeal.
As far as I can tell, there are two sane ways to begin this process: one is with a quick and simple assessment of his workflow, and the other is with a plodding, methodical and tedious assessment. If Roy wasn't always spread among lots of other projects, I would suggest the plodding and tedious assessment; for that, you boot Debian from live and list the installed packages using apt list, then compare this to a list from Roy's installation(s).
"Obviously my first choice for Roy would be OpenBSD, but even for me I decided to switch distros before switching operating systems -- for Roy this step would help even more."But possibly even before that, I would suggest Roy start by figuring out which of his machines has the "simplest" job in terms of his regular workflow, as I believe he uses each machine a bit differently. The whole process is actually easier if he uses all of the machines for the same things, but I doubt he does. If he uses them all the same way, then he can simply remove one machine from the "RAIL" (redundant array of inexpensive laptops) and redistribute the workflow manually over the other machines.
We are going to assume Roy has a slightly different workflow on each machine, though either way it should be reasonable to assume that one machine has the smallest or simplest workflow. I recommend he target that one for migration.
The priority is to make a reasonably complete list (even if only pen and paper are used) of purposes that machine serves. For the purpose of choosing a distro to switch to, a similar list for each machine would probably be beneficial as well -- but we at least need a list for the target machine.
Depending how important that machine is, a full backup with tar or rsync to one of the other machines is obviously recommended; if it is very important, a second backup to standalone media may also be worthwhile.
The machine can then have the new distro installed to it -- I'm not certain dual booting is worth the trouble, but Roy knows best. I would lean away from it for this purpose because it simply makes getting used to the new system take more time (and in some ways, more trouble).
"Depending how important that machine is, a full backup with tar or rsync to one of the other machines is obviously recommended; if it is very important, a second backup to standalone media may also be worthwhile."A reasonable goal is to retain as many of the tools already used on that machine as possible. Some minor workflow goals may change or even improve. The backup of the system should be moved (or copied) back to the target machine, so that it is trivial to access old files. Only the most valuable, high-priority cruft from the old installation should make its way into the new installation as needed, but a repository of all old files can sit under a folder in /root, /home or /opt.
Soon the new machine will be up to capacity in terms of its purpose on the RAIL, and Roy can consider repeating the process with the second-least used machine.
As the migration moves forward, Roy will likely learn some new tools or at least new tricks with existing tools. Even when his migration from Debian is complete, it could be years before his wife wants to migrate; but then this is just about Roy. What distro his S/O uses is really no concern of mine.
"What we probably don't want to do is continue to support Debian or systemd, if we can help it."We can't force Roy to do anything, but perhaps this will offer him a friendly nudge for future consideration. In this short run, this is workflow-disruptive; in the long run, it would inspire new innovations or shortcuts -- not entirely unlike the ones that have happened at Techrights lately. What we probably don't want to do is continue to support Debian or systemd, if we can help it.
Long live rms, and Happy Hacking. ⬆
Licence: Creative Commons CC0 1.0 (public domain)