
Improving TrueOS: OpenRC - protomyth
https://www.trueos.org/blog/improving-trueos-openrc/
======
kev009
As a long time user of OpenRC, I was pretty sad when Debian jumped into
systemd by default instead of sticking to something like OpenRC as the
default. It's light weight, easy to use, embraces POSIX, and a good modular
building block for both server operating systems and not over reaching on the
plumbing desktop users want.

Cheers to TrueOS which is done by an astonishingly small dev team and part
time at that as they are FreeNAS devs. If you ignore the hit and miss graphics
story shared with FreeBSD for now, TrueOS has some of the best defaults and
out of the box experience I've seen.

~~~
jakeogh
Try Gentoo (again:).

~~~
digi_owl
Speaking of Gentoo. The current maintainer of OpenRC over there seems hell
bent on introducing all manner of systemd-isms to it.

To the point that certain members of the Gentoo community is contemplating a
fork of OpenRC.

~~~
jakeogh
uug. Links? Sounds like something the eudev people would be on the right side
of.

~~~
digi_owl
[https://forums.gentoo.org/viewtopic-t-1035064.html](https://forums.gentoo.org/viewtopic-t-1035064.html)

------
floatboth
"With OpenRC, TrueOS boot times have been reduced from generally over 1 minute
to around 10 seconds"

that's… odd. Pretty much all my FreeBSD machines spend more time before init,
enumerating devices and stuff. rc doesn't take much time. Unless it's doing
DHCP without a network connection :D

~~~
kev009
There are a lot of issues here that should eventually be lower hanging fruit,
but required some infrastructure. EARLY_AP_STARTUP which gets SMP in order a
lot sooner should allow for drivers to attach earlier. I vaguely recall some
idea on deciding what and when to initialize being the next big opportunity.

~~~
floatboth
EARLY_AP_STARTUP is enabled by default… Is anyone working on enumerating all
buses in parallel?

------
qwertyuiop924
I run openRC on Arch. If you want to escape from the horrors of systemd, it's
a good way to do so.

But I've ranted far too much about systemd here on HN to write another one
without explicit prompting.

The point is, I really like OpenRC: generally speaking, it's well-designed,
reasonably simple, easy to manage, and _actually does what it 's supposed to_.
What systemd-isms that have invaded haven't effected me yet.

~~~
imiric
I'm considering doing the same.

Have you had any issues migrating to OpenRC on Arch? Things to look out for?

~~~
qwertyuiop924
[http://systemd-free.org](http://systemd-free.org) provides a repo with all
the stuff you need, including openrc scripts, eudev, and patched versions of
other software that has fallen to the cancer, like the *kits. They provide
simple installation instructions, and it should Just Work.

Issues are rare, although the usual Arch caveats apply (anything can go wrong
depending on how your system's set up, when in doubt, check the blog/rss
associated with your repos, as there might be valuable information, etc).
However, I have noticed a few things:

-While the repo does provide pulseaudio, it doesn't provide the 32-bit pulseaudio packages. This means that 32-bit applications that try to use pulse won't play audio properly. However, these are rare. Do be sure to force SDL and openal to use alsa, though.

-Some software (like Samba) expects systemd to be there when you compile it, and wants systemd as a runtime dependancy. However, (again, as with Samba), these pieces of software sometimes provide config options to remove systemd integration. Consult the project documentation, or just run `./configure --help`.

-I have experienced some audio issues in 64-bit applications (namely, firefox). Although I suspect this is unrelated, it's worth mentioning.

------
drewg123
I run TrueOS for my desktop, and the transition to OpenRC was fairly rocky.
Eg, on the "stable" branch, the switch was made without openrc startup scripts
for many services (mostly 3rd party), so after the update, stuff just didn't
start.

The claim about startup time is a little disingenuous. The only time I ever
reboot my system is for upgrades, and that process now takes a LOT longer, due
to them doing the upgrade from a single-user sort of environment. For those
unfamiliar, TrueOS uses OpenSolaris Boot Environments + ZFS, and an upgrade
involves taking a zfs snapshot of the system, making a new fs based off the
snap, and then doing the upgrade in the new filesystem. That all used to be
done on-line. However, they ran into complaints from users that had, for
example, deleted accounts between the upgrade happening & rebooting into the
new bootenv. So they started doing the actual snapshot & upgrade in a single-
user environment as part of the reboot. This makes the reboot downtime for an
update take 10-15 minutes rather than 2, and greatly outweighs the small
savings in startup time.

~~~
X86BSD
I don't use TrueOS, I think I played with it once or twice over the years, but
what you're describing sounds... I can't find a polite word. Catering to the
lowest common denominator? This sounds windows like. Users deleting accounts
between upgrading and rebooting? Who does that? Why? It's not Unix job to stop
you shooting yourself in the foot.

~~~
drewg123
Well, if you have auto-updates configured, it would be an easy mistake to
make. I have, for example, installed packages and had them go missing due to
this. But I'd like an "i'm aware of the risks, let me update quickly" option.

The main reason I run TrueOS rather than just FreeBSD is for the boot
environments. I've been screwed too much by dependency issues on port/pkg
upgrades and left without something critical too many times, and the bootadm
thing is the perfect solution, as you always have a working fallback.

~~~
craftkiller
Doesn't FreeBSD also have beadm? Is there something wrong with FreeBSD's
beadm? Not trying to be accusatory, its an honest question because I haven't
looked much into beadm but I was planning on setting it up on my FreeBSD boxes
this year and knowledge of any shortcomings you've already hit would save me
the trouble.

~~~
zvol
FreeBSD's beadm implementation is really nice now too, especially with its
recent integration into the bootloader.

~~~
drewg123
Wow, cool! I missed this.. One of the things I dislike about TrueOS is how it
uses grub for beadm management.

I think I may just switch back to vanilla FreeBSD.

~~~
JdeBP
The last that I read, TrueOS was back to defaulting to the FreeBSD boot
loader.

------
shiftoutbox
Welcome openrc . The good question is what happened to launchd , runit and ,
and Nosh . All were in the running to replace rc'ng .

~~~
qwertyuiop924
What about s6?

~~~
skarnet
Still in active development too. :) And no, Jonathan, I haven't heard anything
from TrueOS people.

Which is a shame, because if a distribution is being built today, with no
existing legacy service script base to cater to (or if it has to be converted
anyway), going for anything else than s6 or nosh is staying in the past.

------
akjainaj
If someone from TrueOS reads this, you have some weird characters on your
front page: [http://i.imgur.com/GuOXYPJ.png](http://i.imgur.com/GuOXYPJ.png)

~~~
nagvx
It's - '' \- 'U+0003 : <control-0003> (END OF TEXT [ETX])', which is
(apparently) invisible on some browser setups.

