Switching back to FreeBSD


I’m switching back to running FreeBSD rather than TrueOS, after running TrueOS for about 1.5 years. The reasons I’m doing this might be helpful to the TrueOS developers so I thought I’d post it here.

I originally started using TrueOS because I wanted to be more bleeding edge in order to support my laptop. A few changes have made this less necessary:

  • I feel more comfortable running and managing 12-CURRENT myself. Although I was motivated to become more comfortable after becoming dissatisfied with TrueOS.
  • The graphics stack becoming stable and a package made it less annoying to run bleeding edge myself.

The primary reason I’m moving back to vanilla FreeBSD is because I feel that TrueOS has growing beyond its development resources and the quality is suffering.

Note, however, that I have been running UNSTABLE TrueOS, however I believe my points apply even regardless of that but someone may disagree.

So here is the list of things that, when combined, pushed me to switch back:

  • While openrc is faster for boot times, I found it less convenient for almost every other use case. For example, I wanted to use pf rather than ipfw, however TrueOS wants ipfw by default. I couldn’t turn it off via rc.conf, I had to hunt around until finally figuring out how to turn it off in openrc (tangentially, that TrueOS used ipfw and it was on by default was not even documented which made this even more challenging). Similarly, one argument for openrc was that networking could be separated out to the different interfaces rather than one service to cover all of them, allowing for more control. But even after over a year with openrc, restarting network.wlan0 sometimes worked, sometimes it didn’t. I often had to just resort to restarting all of networking anyways.
  • Over the last six months, updating the OS has been a significant pain point. Even in UNSTABLE, I would expect the update path to be rock solid. Instead, I multiple times had to revert to a previous BE in order to update to the latest OS version. This was usually annoying as I lost packages I had installed in that time. This happened multiple times.
  • The transition to ipfs for upgrades didn’t seem to solve any problem I was experiencing and it left me with an ipfs-go daemon running in the background consuming a non-trivial amount of CPU. Since I was running TrueOS on my laptop, this reduced my battery life. Even switching to traditional upgrade path didn’t stop running ipfs-go.
  • The GUI interfaces can be convenient but they are not polished and they haven’t really been getting better. It doesn’t feel to me that the TrueOS team has the resources to make polished, high-quality, GUI configuration tools.
  • In general, I believe TrueOS is growing too different from FreeBSD. Knowledge doesn’t transfer well, anything with an init script needs to have it modified for openrc. These things build up and take up time and resources. I cannot name one feature that I would consider done and rock-solid in the last year (but maybe I just missed it). Instead we grow features, lumina, openrc, syadm, updates via ipfs. I just don’t feel confident the team can sustain these things in the long run.
  • Less strongly, the one time I did try to contribute to TrueOS, my github issue (which boiled doing to “I want to make small change X, but I’m not sure where I should put Y, I’m willing to do all the coding”) went untouched for months. That’s only one example but so I don’t know if a pattern can be extrapolated, but first impressions do count. The slow feedback put me off from trying to contribute.

Take what one will from this, they are just my experiences and opinions, so I’m sure others have had different.

On the positive side, I would like to thank TrueOS. The state graphics was in when I decided to move to FreeBSD on my laptop was not user-friendly and I would probably have given up if TrueOS hadn’t just given me an OS with the graphics stack setup. Because of TrueOS, I am a happy FreeBSD user.


Thanks for Your information. I liked Your text.

As for me, I’m waiting for the next bigger update-step with Lumina 2.0. Till then, I’m using FreeBSD instead of TrueOS (among other OSs). I will certainly keep running TrueOS again, but not as my main or only OS.

The developers know what they are doing, but there is seemingly a lack of manpower, as You are mentioning here, too.

Happy BSD-ing!


I’m a former TrueOS user as well. I quitted a few months ago, when running drm-next-kmod was made available for FreeBSD 11.1-STABLE.
I really tried to stay but there was a point where I just couldn’t. Sadly, things were going backwards in terms of stability (at least for me).

Anyway, here are the main reasons why I left:

  1. Services were way too inconsistent: sometimes they started, sometimes they didn’t. Many services were mistakenly reported as ‘crashed’, while some others supposedly working actually weren’t.
  2. Updates were kind of a mess: when using the traditional CDN it happened far too often that I hit a ‘bad node’ and the system got broken. It’s a shame IPFS couldn’t make it.
  3. Slow development: Yes, I know the team is very small and you try your best to keep this alive. But the thing is sometimes you set unrealistic dates to achieve your goals. UNSTABLE updates are nowhere near ‘once per two weeks’ and Lumina 2.0 beta was never released in February, to name a few. But again, there’s nothing wrong about taking your time to get a better result. It’s not a complaint, just a little advice.
  4. Random kernel panics: this was the most annoying of them all. It never ever happened til TrueOS 17.12. Then it happened at least 3 times every single day. And the worst part: I couldn’t find kernel core dumps to at list have an idea what was going on.

It was hard for me because I was very optimistic about the project, but as @orbitz I found my way back to vanilla FreeBSD and all these problems disappeared. Fortunately I already had experience on setting up a FreeBSD desktop from scratch so it was actually smooth (installed openbox).

Still I wish the project the best and hope the future will be brighter :muscle:


I can confirm Your words. With the 17.12 version, things started to go a little bit downhill.

I’m not very picky and not inclined to angry criticism.

But - as You say - the booting mechanics and the OpenRC startup-scripts simply have to run flawlessly, and the flaws regarding them have to be fixed immediately.

Else, serious computing with TrueOS is impossible.

Another point: Browsers (Firefox) have to be uptodate. On production release FreeBSD, they are:

$ uname -sr ; firefox --version
FreeBSD 11.1-RELEASE-p10
Mozilla Firefox 60.0.1

Newest available presently:


I’m testing 18.03 Stable. A bit frustrated with old PCBSD experiences I was not very convinced … But I must admit 18.03 Stable runs very smoothly.

I replaced ipfw with pf. No problem here. OpenRC worked well here.
Sometimes some daemon didn’t start with the right flags, for example powerd++ (in my experience powerd++ gives better performance than powerd). I solved launching a custom script when machine boots.
My computer is a laptop (thinkpad), and every thing works as in 11.1.
Yes, firefox is not ultimate, but runs well.
No crashes at all. Only a couple of hangs when playing with a corrupted sd card trying to fix it from the command line (so it can be admitted).
Things like virtualbox, kody, mysql, nginx, encfs, wine (with nvidia patches), suspend/resume, display port, etc. work as expected. No problems at all.

I like the idea of OpenRC but I don’t understand Lumina Desktop. I’m running xfce while waiting for plasma5. Xfce as KDE, Mate, Gnome are much better (imho) than Lumina in terms of usability, appearance, auxiliary tools, etc. Why Lumina then? A mistery for me.

My main concern however is, as said above, the lack of manpower and that in the next upgrade things may come down. But I think there is a lot of effort and illusion in the team. So I’m with TrueOs for now, very pleased and grateful what TrueOs team has achieved (thanks team).



Would you mind sharing your powerd++ script and suggesting a fix of this issue on GitHub?

Many thanks!



I have in my rc.conf the following lines:

powerdxx_flags="-a adaptive -b adaptive -n adaptive -M 2501 -m 800 -i 75 -r 85 -p 500"

But what I’ve seen is that trueos starts powerdd++ without any flag. I suspect the openrc script to start has a bug but I couldn’t debug it. I use another script called /etc/acpi_ac to start powerd++ and configure other powersaving related things. In devd.conf by default we have.

notify 10 {
        match "system"          "ACPI";
        match "subsystem"       "ACAD";
        action                  "/etc/acpi_ac $notify";

so, when an acpi event ocurrs I can control some things like usb devices to powersave mode, or even modify the maximum cpu frequency when on battery or when in ac.

This /etc/acpi_ac scripts is executed as well when the machine starts:

ls -l /etc/local.d:
lrwxr-xr-x  1 root  wheel   12 May 12 21:52 10_acpi_ac.start -> /etc/acpi_ac

The scripts in deed doesn’t rely in what devd sends, it detects if AC is present or not with:

apm -a

If AC is present powerd++ is invoked with the following flags:

-a adaptive -b adaptive -n adaptive -M 2501 -m 800 -i 75 -r 85 -p 500

If AC is off then:

-a adaptive -b adaptive -n adaptive -M 1300 -m 800 -i 75 -r 85 -p 500

In this way, when in battery mode, my laptop can reach a lower cpu frequency saving battery than when in AC. And at the same time, I ensure powerd++ starts with the right flags when machine boots.

This web doesn’t permit to upload the script, but I can send you by email or another method.

In the other side, I read in a thread, I guess that in this same forum, that TrueOs people detected some load problem with powerd++. I use powerd++ since FreeBSD 10 and in my experience the laptop’s cpu frequency scales up and down better. With -hiadaptive it works better than powerd, more responsive when load goes . And with -adaptive the cpu is more time with low frequency than with powerd. In my tests, powerd tends to put my cpu much more hottest than powerd++. For me, in my laptop, this is very important, to avoid a hot cpu (70-80 ºC) and for battery saving.




As the person that sent in the openrc script for powerd++, I suspect I was going for the literal “drop-in” replacement and probably only too the arguments that originally in the powerd script. If that changed later, it probably never got updated in the openrc script.

Anyway, I would also be interested in the acpi script. You could perhaps just paste the script in a giant code block on the forum? Or just make it a gist on github if you have an account there?


So, here it goes. Please take into account the script is in continuous developing, and it should be cleaned. But it’s 100% functional in my system (thinkpad T420s with Nvidia Quadro).



AC=`/usr/sbin/apm -a`
if [ $AC -eq 1 ]
	#echo $state
	#exit 1

if [ $AC -eq 0 ]

echo $state > /tmp/ac

##POWERD_PID=`ps -x | grep powerd | cut -d\  -f1 | head -n 1`
#POWERD_PID=`ps -x -o pid,command | grep powerd | cut -d\/ -f 1 | head -n 1`
POWERD_PID=`ps -x -o pid,command | grep powerd++ | cut -d\/ -f 1 | head -n 1`
#echo ${POWERD_PID}

/etc/usb_powersave.sh $1

case ${state} in
0x01 | '')
        echo "AC: on" >> /tmp/ac

        #no wifi powersave
        ifconfig wlan0 -powersave
	kill -9 ${POWERD_PID}
	#$POWERD -a hiadaptive -b adaptive -n adaptive -M 2501 -m 800 -i 75 -r 85 -p 500 &
	$POWERD -a adaptive -b adaptive -n adaptive -M 2501 -m 800 -i 75 -r 85 -p 500 &
	sysctl hw.acpi.video.lcd0.brightness=80
	#webcam on
	#si estamos con nvidia no hacemos nada
	/etc/usb_powersave.sh 0x01
        /usr/sbin/usbconfig -d ugen0.3 power_on
	/usr/sbin/usbconfig -d ugen0.4 power_on
	service moused restart
        echo "AC: off" >> /tmp/ac

        #wifi powersave
        ifconfig wlan0 powersave
	kill -9 ${POWERD_PID}
	#$POWERD -a hiadaptive -b adaptive -n adaptive -M 1300 -m 800 -i 75 -r 85 -p 500 &
	$POWERD -a adaptive -b adaptive -n adaptive -M 1300 -m 800 -i 75 -r 85 -p 500 &	
	sysctl hw.acpi.video.lcd0.brightness=40
        /etc/usb_powersave.sh 0x00
	#webcam off
	/usr/sbin/usbconfig -d ugen0.3 power_off
        /usr/sbin/usbconfig -d ugen0.4 power_off
 	#poweroff Nvidia Optimus
	#si estamos con nvidia no hacemos nada
	service moused restart
        echo "Usage: $0 [0x00|0x01]"
        exit 1


And /etc/usb_powersave.sh:


#ugen1.1: <XHCI root HUB 0x1033> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
#ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
#ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
#ugen0.2: <product 0x0024 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
#ugen2.2: <product 0x0024 vendor 0x8087> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
#ugen0.3: <Integrated Camera Chicony Electronics Co., Ltd.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
#ugen2.3: <Wireless Receiver Telink> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (50mA)

echo $state > /tmp/ac

case ${state} in
0x00 | '')
	usbconfig -d 1.1 power_save
	usbconfig -d 0.1 power_save
	usbconfig -d 2.1 power_save
	usbconfig -d 0.2 power_save
	usbconfig -d 2.2 power_save
	usbconfig -d 0.3 power_save
	usbconfig -d 2.3 power_save

        usbconfig -d 1.1 power_on
        usbconfig -d 0.1 power_on
        usbconfig -d 2.1 power_on
        usbconfig -d 0.2 power_on
        usbconfig -d 2.2 power_on
        usbconfig -d 0.3 power_on
        usbconfig -d 2.3 power_on

        echo "Usage: $0 [0x00|0x01]"
        exit 1


Neat. Thank you. I also have a Thinkpad T420 with the same configuration, so I’ll have to give this a shot too when I get some free time.

Bookmarked for later!


Thanks a lot @Jes, I will also test it on my Thinkpad T520. Might be July by then…


I think the latest blog post really speaks to your concerns.