6 ms·

Improving TrueOS: OpenRC

93 points by protomyth 10y ago

akjainaj 10y ago
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
- deleted 10y ago
  [deleted]
- nagvx 10y ago
  It's - '' - 'U+0003 : <control-0003> (END OF TEXT [ETX])', which is (apparently) invisible on some browser setups.
floatboth 10y ago
"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
- stefantalpalaru 10y ago
  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.
- kev009 10y ago
  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 10y ago
    EARLY_AP_STARTUP is enabled by default… Is anyone working on enumerating all buses in parallel?
- aduitsis 10y ago
  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.
  - floatboth 10y ago
    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`.)
kev009 10y ago
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.
- loeg 10y ago
  > 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).
- jakeogh 10y ago
  Try Gentoo (again:).
  - digi_owl 10y ago
    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 10y ago
      uug. Links? Sounds like something the eudev people would be on the right side of.
      - digi_owl 10y ago
        https://forums.gentoo.org/viewtopic-t-1035064.html https://forums.gentoo.org/viewtopic-t-1035064.html
  - 10y ago
shiftoutbox 10y ago
Welcome openrc . The good question is what happened to launchd , runit and , and Nosh . All were in the running to replace rc'ng .
- joseph 10y ago
  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.
- qwertyuiop924 10y ago
  What about s6?
  - skarnet 10y ago
    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.
- jbergstroem 10y ago
  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.html#The-nosh-Project 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 https://lists.debian.org/debian-user/2017/01/msg00519.html
- dsr_ 10y ago
  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.
deleted 10y ago
[deleted]
drewg123 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
qwertyuiop924 10y ago
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 10y ago
  I'm considering doing the same. Have you had any issues migrating to OpenRC on Arch? Things to look out for?
  - qwertyuiop924 10y ago
    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.

93 points by protomyth 10y ago

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

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

floatboth 10y ago

"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

stefantalpalaru 10y ago
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.
kev009 10y ago
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 10y ago
  EARLY_AP_STARTUP is enabled by default… Is anyone working on enumerating all buses in parallel?
aduitsis 10y ago
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.
- floatboth 10y ago
  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`.)

kev009 10y ago

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.

loeg 10y ago
> 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).
jakeogh 10y ago
Try Gentoo (again:).
- digi_owl 10y ago
  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 10y ago
    uug. Links? Sounds like something the eudev people would be on the right side of.
    - digi_owl 10y ago
      https://forums.gentoo.org/viewtopic-t-1035064.html https://forums.gentoo.org/viewtopic-t-1035064.html
- 10y ago

shiftoutbox 10y ago

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

joseph 10y ago
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.
qwertyuiop924 10y ago
What about s6?
- skarnet 10y ago
  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.
jbergstroem 10y ago
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.html#The-nosh-Project 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 https://lists.debian.org/debian-user/2017/01/msg00519.html
dsr_ 10y ago
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.

deleted 10y ago

[deleted]

drewg123 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.

qwertyuiop924 10y ago

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 10y ago
I'm considering doing the same. Have you had any issues migrating to OpenRC on Arch? Things to look out for?
- qwertyuiop924 10y ago
  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.