Hacker News new | comments | show | ask | jobs | submit login
Improving TrueOS: OpenRC (trueos.org)
93 points by protomyth 301 days ago | hide | past | web | 38 comments | favorite



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.


> If you ignore the hit and miss graphics story shared with FreeBSD for now.

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).


Try Gentoo (again:).


I'm on vanilla FreeBSD now. Ports is about equally as cool as Portage, but Poudriere and quarterly branches edges out for commercial use IMO. And I get a neat kernel and community that are both approachable and fun to work with.


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.


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



"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


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.


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


If you have to start several jails upon init, each running its own rc.d start sequence, it can easily take more than a minute. Heaven forbid if you have something like tomcat that takes ages to start, you might be looking at much more.


Don't do that on a desktop maybe?

(Also for apps on servers, I use runit to start services in jails directly like `exec jail -c ... command=/path/to/app/command`.)


OpenRC can parallelise the service start - I use it on Gentoo ~amd64 and despite warnings it can "potentially lock the boot process" I never had any problems. The speed gain is significant.


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.


I'm considering doing the same.

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


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.


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.


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.


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.


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.


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


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.


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


That I get. That's always usually been the FreeBSD way(tm). Set a knob, sysctl, something that allows you to have that behavior if you need it.

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.


This is kind of how I felt when I tried TrueOS. I had heard about all the interesting things they had been doing, like integrating boot environments into their update process - but when I actually went and tried it, it was as though it was an unfinished product. It had multiple things that felt incomplete or didn't work, like the app cafe not working, saying it was installing something but then doing nothing. Maybe this was because they were making the transition from openrc since it was right after their TrueOS name switch from PCBSD, and I think that was when they made the init change.

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.


> Maybe this was because they were making the transition from openrc since it was right after their TrueOS name switch from PCBSD, and I think that was when they made the init change.

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.


I was actively following PC-BSD throughout the change as I've wanted to use BSD over Linux, but a few issues held me back. I believe a lot of the decision to move to a rolling release was users like myself that were grabbing the monthly betas, needing some new hardware support that's years away in FreeBSD.

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.


True, but thats the role TrueOS is attempting to fill. They're like the early days of Ubuntu where the whole goal is to create the most user friendly experience for the operating system, making it a great gateway-distro to the rest of the eco system. The more tinkering-focused users can go upstream to FreeBSD.

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 agree. Truth be told the older I get the tinkering has lost its luster. I just want to get Sh%5 done. I don't have time to keep reading mailing lists and commit logs the first half of my day anymore to keep up on all the hacks, tricks, knobs, comments on HW etc. I just need to get things done.

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.


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


I also wonder that. I've read good things about OpenRC, but I always thought of the lack of runlevels as a defining feature of BSD, so color me a little sad to see this go into a BSD operating system.


Nosh seems to progress nicely - it just doesn't get a lot of public attention. If you follow the FreeBSD or debian mailing-lists you will find a new email announcement about releases every 3-4 weeks.

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


Version 1.32 of nosh is on its way. Version 1.31 went out a week or so ago.

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.

* http://www.mail-archive.com/supervision@list.skarnet.org/msg...

I've had zero response from the TrueOS people so far. I don't know whether Laurent Bercot has heard anything.


Nosh is still in active development; I see release announcements to the Debian Users list every month or two. It looks like the core is good and lots of conversion infrastructure is being put into place around it.


What about s6?


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.


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: