On Tue, Feb 25, 2020 at 06:48:21PM +0100, Sam wrote: > Thanks for your points of view! I agree that Stable comes at a cost, and of > course if I ever were to set up a server Debian would probably be my choice. > > Regarding derivatives, I know about Ubuntu, Mint, etc., but I don't exactly > like distributions tied to or ultimately dependant on commercial entities (I > want a change of air after going through Ubuntu, openSUSE...) > > I have also seen independent Debian derivatives (MX Linux comes to mind), but > they either used backports or the Testing distribution. > There are literally dozens (hundreds?) of Debian derivatives out there. You might find that one or another suits your needs better than the rest: https://wiki.debian.org/Derivatives/Census
> I would happily consider using Debian Testing for example, but wherever I see > someone asking about it I always find someone discouraging from using it due > to the possibility of having broken or unsecure packages for a long time due > to it being automated. Is it actually usable for a Workstation? The same > would > apply to Sid, I can no longer allow myself to fix big breakages after broken > updates (I don't know if that really happens often in Sid) > On strategy would be to run testing and not update too frequently. The important thing there would be to monitor the -user and -devel mailing lists to ensure that when you do update it isn't in the middle of a known "trouble spot". The trade there is that you must invest the effort in keeping up with what is going on at a fairly low level and you won't be getting timely security support. The approach that I take is to run stable on my workstations/laptops and then use chroots, containers, and/or VMs for when I need a "newer" environment. For instance, I need to run the lintian utility on my packages before I upload them to the Debian archive. For this to be a useful check it must be performed with the latest lintian from unstable. I have an unstable chroot environment which has (among other things) lintian installed in it at the latest available version so that I have it always available when I need it. If the environment breaks because of a bad update or bug in a package or whatever, I have others that I can use instead. For containers and VMs, taking a snapshot before upgrading to allow roll-back is trivially easy. Something similar may work for you. Regards, -Roberto -- Roberto C. Sánchez
