Funny, you claimed the same about
ralphbsz systems. There's nothing extraordinary about the systems I maintain.
I'm not making any judgements, we all are free to tune our FreeBSD systems to our liking. But I still want to point out that FreeBSD devs do pick defaults for pre-compiled systems. Those defaults do lend themselves well to the automation that freebsd-update (and pkg-update) provides. But if I want to change those defaults, and tune the system to my liking, that does break the whole automation enchilada, sometimes at very inconvenient points.
From that it follows that I
have to be extremely careful when tuning my system. I would have to consider the likelihood of something breaking and what it takes to resolve that breakage, and thoroughly test it before I commit to a given change. I don't always have the time/energy/inclination/skill to be that thorough. Sometimes, the only real way to find out if the automation is broken is to put a system through the paces. Make a change, and then test it to see if freebsd-update (and later, pkg-update) is OK with that change, or will it start the recursive incompatibility/dependency resolution that only leads to a train wreck?
And I suspect most rank-and-file FreeBSD users are like that. The details between users may differ, but they add up to the same thing.
Maybe that's the problem here, you run it at "random times". Why? I only use it when there's a patch update available (those are never going to break anything), or when the currently running system is quickly approaching its EoL date. That's not random, that's planned, in advance. Because I planned in advance I'm also keenly aware of any potential pitfalls.
For me, 'random times' really means 'a more up-to-date port finally came out, that will really solve the problems I've been having with it'. But installing an up-to-date port really sets off dependency hell of recursively resolving incompatibilities. Because of that, I end up just wating until Firefox says 'no more, I'm done'. I tried upgrading Firefox before, but pre-compiled versions depended on hard-coded library versions (and sent me into the recursive dependency hell), and compiling a later version meant hours of researching how to edit the Makefile. Eventually, my system was such a mess that I decided it's easier to do a clean reinstall with all the up-to-date stuff than to finish digging through a train wreck.
So do I, by way of my own repositories, created with
poudriere(8) so I get consistent results, and I tested beforehand.
A few years ago, I tried setting up Poudriere myself, because I wanted to be able to upgrade KDE without touching anything else. I did deviate from defaults quite a bit, at least in part because I wanted to turn on security-related options every step of the way. Not an impossible task, just very time-consuming. Not everybody has the same great ideas that I do. I did have to drop that project because other things IRL demanded my attention. Not every rank-and-file user has the skill, interest, time, hardware, and energy to do a Poudriere setup that does the job right. The option to do it is there, and I like that about FreeBSD.
I do realize that there's no such thing as a perfect system. But if a system lends itself well to automation, there IS something special and different about it. I do have to ask myself if I want a system tuned to my preferences or a system that lends itself well to automation. That's kind of the price I pay for having my own preferences. And that's OK, I just think that the very existence of this proverbial '
Yin and Yang' needs to be acknowledged.
