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.
TrueOS actually ships a newer graphics stack than FreeBSD for now, so if you want recent Intel GPU support (in i915kms), it's there (at least through Skylake).
To the point that certain members of the Gentoo community is contemplating a fork of OpenRC.
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
(Also for apps on servers, I use runit to start services in jails directly like `exec jail -c ... command=/path/to/app/command`.)
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.
Have you had any issues migrating to OpenRC on Arch? Things to look out for?
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.
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.
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.
I think I may just switch back to vanilla FreeBSD.
It's kind of odd that is not the case here.
Also FreeBSD supports boot environments now, as well as selecting them from the loader menu if you haven't used it in a while. But reading the TrueOS website makes me think I should give it another go soon, it has some nice features. Even the Pico version seems interesting.
It kind of felt like they are building a product for no one in my opinion. It is almost as if they are using it as a breeding grounds for new technology in FreeBSD instead of building a stable operating system. If they're trying to use FreeBSD to make something for the average user, do they really care about all these features? I kind of feel like they have been trying to integrate too many new things all at once and it is left things very fragile. I think they should focus on stability instead of trying to integrate so many new things at once. Hopefully this is all just due to them switching to a rolling release model and things will stabilize. I ended up switching to vanilla FreeBSD, maybe I'll give TrueOS another shot once things have settled down.
It's not just openrc transition, PC-BSD was based on FreeBSD stable, TrueOS is based on current. I also hope things will stabilize for them as I want to see a viable alternative to Linux. Also Lumina is their in house desktop environment which is kinda cool.
Some of the problems come from a lack of easily obtained details of the switch. They had PC-BSD 11 release candidates, but had hinted at TrueOS, and as someone who was willing to bug test I had no idea what to test.
I thought they'd still do an 11 release and provide minimal updates, as there were so many things they knew were broken. That never appeared and I was left downloading the image once a month to see if AMD cards worked. And so many things seemed wrong on those tests, it was impossible to tell what needed testing without reading every bug report.
I think things will improve when the team isn't also working on a FreeBSD and FreeNAS release, but it was a bumpy start.
I actually prefer to start with a blank slate and tinker but the TrueOS people keep coming out with these awesome features that are making it hard not to switch.
I think Ill kick the tires on TrueOS this weekend. As you said it seems to have some awesome features that would make my network/deployment life easier than stock FreeBSD.
Init still seems to be undecided in FreeBSD land; my hope is that FreeBSD 11 or 12 at least makes a decision about considering to switch (or not).
Latest freebsd quarterly update: https://www.freebsd.org/news/status/report-2015-10-2015-12.h...
Latest release notes (jan 14th, 2017): https://lists.debian.org/debian-user/2017/01/msg00519.html
I have pointed out to Ken Moore that they can marry s6 with OpenRC. I've also offered my experience with things like getting PCDM running under proper service mangement, which is one of the many things that I have already done. I've also already been through all of the fun with the interdependencies between devd and the Mewburn rc system, and can offer experience of that, too. I have had per-user service managers running on TrueOS/PC-BSD for over a year, as well, and already have the per-user Desktop Bus stuff that is coming down the pipeline from the Desktop Bus people.
I've had zero response from the TrueOS people so far. I don't know whether Laurent Bercot has heard anything.
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.