It seems a lot of criticisms against TrueOS are based on old PCBSD or very early TrueOS experiences. I also remember having some rough times with PCBSD when I tried it.
Today I'm using TrueOS as my desktop OS on 3 desktops and my laptop. My main workstation is running TrueOS since sept. 6th 2016 according to the root dataset creation timestamp (it was installed after one of the HDDs began dying and debian/devuan linux silently corrupted a lot of data on the md-raid1 before finally dying...). The laptop was set up with TrueOS a bit earlier (dual-booting)
Yes, early on with TrueOS there were sometimes issues with updates (most I had were related to drm-next drivers for the integrated intel GPUs) - thanks to boot environments that are automatically created you are back up and running in no time.
Apart from a small glitch with the last update on one (out of currently 9) systems with TrueOS (STABLE) I manage, I didn't have any issues with updates since around spring this year (and never since the transition to STABLE/UNSTABLE branches).
On the one hand, TrueOS profits from that reputation of FreeBSD, but on the other hand there is the potential problem that things like the permanent update problems (which do not originate from FreeBSD) damage FreeBSD's reputation as a reliable OS.
As said: didn't have any issues for quite some time now. The STABLE branch has worked without a problem on my 4 machines (3 desktop + 1 laptop) and all 5 clients of our TrueOS test-deployment here in the company which is about to be extended to most (if not all) clients early next year.
Could you provide a bit more detail, what actually makes the difference between old and new pc-updatemanager?
pc-updatemanager is basically just a wrapper for pkg, beadm, zfs and some other standard tools to automate the update process in a safely manner. It's a shell script - so you could easily recreate the steps manually or modify/rip out everything you don't like/need/want...
Bad thing is that GUI based config tools often do not behave, clobbering config files, so you cannot edit manually anymore.
As far as I can tell, all the GUI tools used to modify system settings usually directly use the config files, not some own special magic in the background like e.g. pfSense does for all of their configuration. I couldn't detect any clobbering or strange behaviour if the files were also modified not using the tools. Also everything TrueOS/Lumina-specific I needed to configure was found in config files that could be edited directly (although sometimes not recommended).
Our clients get configured via ansible, which directly deals with the config files either modifying or replacing them, and I haven't found any issues with that yet. The only problem I've encountered so far, is that the graphical user manager uses either pw and/or directly modifies /etc/passwd and /etc/group, which breaks NIS configurations because e.g. if a user changes his password, the entry will be written to /etc/passwd instead of relayed to the NIS server e.g. via yppasswd. To prevent this, /etc/passwd and /etc/group are set to immutable for now to prevent accidents and users have to set their password (amongst other things) during an initial config script that is fired at first login.
I still have to incorporate sysadm into the whole configuration, which should make some tasks easier and safer. Currently I'm using sysadm only via GUI for remote manual changes to single clients.
If only the Lumina desktop the project touts so much wouldn't be one of the ugliest pieces of software I have ever seen... Its UX is just terrible. Is that because they don't have any designers worth their salt or because it's an engineer-run company?
As always: Beauty is in the eye of the beholder.
I like that Lumina is delivering a full DE without being utterly bloated and pulling tons of dependencies (most of which are owed to linux-cruft that gets dragged in on other DEs). Configuration to suit my workflow is relatively minimal (mostly keyboard shortcuts) and easily accessible and shareable between systems. That being said - a DE for me is 80% for managing my open terminal windows and 20% for some browser windows, mail client and very few other programs or tools. I can't stand a desktop that gets in my way when working, especially if its only for the sake of "being pretty" or "user friendly".
Yes, one could also configure fluxbox manually to get some similar result, but not everyone wants to spend hours for this task and then constantly try to find yet another tool/hack for every new task or use case to finally end up with a working DE after weeks/months of "fine-tuning". For someone who actually WANTS to set up the whole system from scratch, TrueOS or Lumina of course isn't the right choice, but so is ubuntu, GhostBSD, Gnome or KDE. This would be like someone complaining about a station wagon being too big if he wants to buy a motorbike anyways...
Also - talking of the typical desktop user in a work environment - not everyone is mentally capable of putting together a DE manually. As said: we're about to roll out TrueOS over most/all our clients that currently still run Windows. For these scenarios you just need a DE that is relatively minimal and already has all loose ends knotted together or your archetypal Windows-users will die of dehydration from constant whining and crying. The fact that everything in Lumina is still easily configurable through text files makes adaption to user habits even at scale not only feasible but only possible (especially compared to windows where you're stuck with whatever crap Redmond is forcing on you/your users).
Finally regarding OpenRC: Yes, there were some rough edges during the transition, but because the approach was more of a slow transition with fallback/compatibility in mind and parallel support for rc (it still reads rc.conf!), there was never a point where a system wouldn't boot or shutdown properly and the few glitches were relatively easy to find and fix. In fact the few problems I encountered with services not properly starting (esp. on DHCP-configured systems) were all fixed with the adaption of the "net-online" service and setting the service dependencies accordingly.
To sum it up: My experiences with TrueOS have been very positive and I can only recommend that everyone who had bad experiences with PCBSD should try out a recent TrueOS release - its a whole new OS now.