I recently took a look at the TrueOS operating system. It’s what was once known as PCBSD. While I’ve been using FreeBSD as my main operating system for about fifteen years, I’d never used PCBSD or (up till now) TrueOS.
It’s nice to have a desktop installation that let’s you slip a disk into the drive, walk into the kitchen, have a cup or two of coffee, and then come back to the desk and run applications. This differs from what I’ve done for the better part of two decades (which is to install the entire desktop and OS from the command line). It feels lazy, but nice.
After it (TrueOS) launched the first session, I set out to find what it did that my other setups did not. The (somewhat) unique Qt5 driven Lumina desktop is certainly an item that stood out in regard to things that are different (than my regular-old-regular-old desktop environment). Since it seemed smallish (relative to KDE or Gnome) – I thought it to be a good target for customization. But before I could customize it, I needed to have all the debug libraries for both Qt and for the Lumina desktop itself.
I recalled the last time I had to build the “debug” version of Qt. I didn’t have enough memory to link it, and actually had to go out and buy more RAM in order to proceed. I wondered, “Had things changed?” Then I decided to triage the problem. I certainly didn’t need qtwebkit for the Lumina desktop (it is not a dependency), and that’s (IIRC) where the linker problem was. So, when I hit the git repo for the code, I subtracted some stuff:
git clone git://code.qt.io/qt/qt5.git cd qt5 git checkout 5.9 perl init-repository --module-subset=default,-qtwebkit,-qtwebkit-examples,-qtwebengine ./configure --developer-build -opensource -nomake examples -nomake tests -no-gtk-style --confirm-license make -j2
Then I went on to build the debug version of the Lumina desktop. This turned out to be a snap:
git clone git://github.com/trueos/lumina.git cd lumina ./mkport.sh /usr/ports /usr/ports/distfiles
What the mkport script does is create a port in /usr/ports/x11/lumina, and then it fetches the source into /usr/ports/distfiles (which must exist). It is then a simple matter to build the port, as usual. In my case, the port had to be configured to build the debug version of course.
I built the port, and installed it. While it was successful, I don’t recommend this sort of pieces/parts update. Those wanting the standard, safe, seat belts buckled method should let the system updater do it for them. The system update creates a separate boot environment (nicety of ZFS, which I haven’t gotten to yet), that can be rolled back if the new desktop fails.
I ran sockstat to determine what servers were running, and which ports opened. I noticed the ntpd and cupsd daemons running. I usually don’t run either of those servers on my desktop as a matter of routine, but instead I manually run them as/when needed. So, I clicked on the service manager icon, and deselected both of them, for the current session and for all sessions. This was another little nicety that of course I didn’t have on my manually constructed desktop, running FreeBSD. That nicety is the click-a-button service manager, which is tied into the OpenRC run script and service structure adopted by TrueOS.
Natch – this service style of management is available at the command line, as well. OpenRC (I’d never before used a system that utilized it) reminded me a lot of Solaris. One uses syntax like rc-service and rc-status (imparting a bit of the feel of svcadm and svcs from SunOS)
So, what kind of browser did it have, out-of-the-box? Clicking the browser icon, off of the start menu launched the most recent version of Firefox (52.0 as of this writing). Not having to manually install a browser allowed for another half cup of morning brew, and less fuss.
What about system updates? We all like to update our systems, and it’s nice when it’s automajick. But, I found that on TrueOS it was more automajick than I wanted. The default is to check for new available updates, and automatically just do them. I’d rather set the update to run when I want, rather than when the system finds another one is available. So, in the preferences tab (off of the start menu), I clicked on the “system updates” icon, and deselected the “automatically update” checkbox in the dialog’s “settings” tab. Much better (for me, others may argue).
TrueOS has a firewall already setup, and an associated start menu item to control/monitor it. I made a couple modifications to the default setup. By default, it allows all outgoing connections. I modified the script to allow *no* outgoing connections by default, and added a rule to specifically allow only https (443) per user jake (one of my favorite aliases). In the /etc/ipfw.rules config file, I ditched the “allow all outgoing packets” section.
Note that I don’t give firewall advice. I’m just describing what I usually do. It probably ain’t perfect. After blocking all outgoing packets (or not unblocking them), I added an explicit rule to allow only the jake-man to use port 443 (and nothing else). If all outgoing packets are disallowed in the main script, then the following custom rule adds a “poor man’s” HTTPS EVERYWHERE implementation:
ipfw add 10001 allow tcp from me to any dst-port 443 setup out via rl0 uid jake
Note that this kind of setup may kabosh my auto-updates. But then again, I never liked those to start with!
Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.
Note: This author and site is not affiliated with TrueOS in any way. For information about that project visit http://www.trueos.org “TrueOS” is a trademark of iXsystems, Inc.