Replacement of Init System

Personally my views on this matter are my opinions and some may not agree with my views, but I feel as tho the init system with FreeBSD is becoming a little dated, and a replacement would be a good idea.

While replacing something that isn't broken is generally a bad idea, I have had a lot of improvements replacing my init system on my FreeBSD install.

Currently, I have been testing and trying OpenRC on my FreeBSD install which is coded in a C and multi-platform init system, and also released under the BSD license.

While there is opinions over using an init system that relies on shell code, and one that is coded in C, I can say I have experienced a dramatic improvement using openRC and it is feature rich compared to the standard init system. The only problem I have, is that I have to write scripts for OpenRC to start some services as ports do not provide this.

A list of features that OpenRC supports that FreeBSD init doesn't includes:

* Parallel service startup
* Per-service resource limits (ulimit)
* Separation of code and configuration (init.d / conf.d )
* Stateful init scripts (is it started already?)
* Automatic dependency calculation and service ordering
* Proper integration into container/virtualization (Linux-VServer, OpenVZ, ...)
* Expressive and flexible network handling (including VPN, bridges, ...)

As well as this, I find it is also more visually appealing. ( Tho I have added color to my original FreeBSD init) The pros of a new, more updated init systems seems to be beneficial to a system, and greatly improves my desktop usage:

OpenRC in use on my FreeBSD machine:

EYPsh.png
 
Let me be the first to state that you are not running a pure FreeBSD system.

https://github.com/Amzo/ArchBSD

If you are not running a pure/clean only FreeBSD system, then why are you suggesting this?

Let's say that I am running DebianKFreeBSD and suggest to others that Gnome3 is better than KDE4. There's a problem in my statement because I am running a bastardized system.

Try your idea on a pure FreeBSD system and tell us what the results are.
 
That was a clean install. Currently to get my ArchBSD system up and running. I install the FreeBSD world into a destdir~/archbsd_world. from there I continue to work on my packages toolchains, but overall, that was a base FreeBSD with OpenRC.

As well as it not being a clean system, the standard base is FreeBSD and any third party applications are exclusively packaged to /usr/local as it should be. That git was just a test project I was working on, and no way reflects my views.
 
sossego said:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/


And where do you see "i686" on that page?


Sorry, but, I'm not believing it is a pure system.


Again, try a fresh install with no scripts of any sort. That means no package manager which is Linux influenced.

It is completely pure. the machine arch is available in hw.machine in the sysctl and also is available in /usr/src/sys/i386/i386/identcpu.c which then can proceed to compile with: make MACHINE=blah build kernel. Those apart from this little modification, it is as you put it; a pure FreeBSD except with the arch changed. I only changed this in the iso as I specifically compiled and optimized it for my i686 machine.


However this little project of mine, was to address issues I currently had with FreeBSD: One was the package manager and the other was the init system. Tho someone else also had the same views as me, but wanted to go with GNU userland while I don't like the cestpool franken OS known as kFreeBSD.

I originally did replace the package manager and used pacman, but not long after, pkgng was released. Then my package manager problem was solved, and instead of going the Linux way with a package manager here, there and everywhere, I abandoned it.

And still I experiment with OpenRC on FreeBSD, whether you call it a pure FreeBSD install or not because of my little kernel patches the fact was, it booted a lot quicker in a virtual machine, then my standard FreeBSD installed on my machine using the default init.

When testing the iso on my actual machine and booting from CD, it booted up extremely fast, in around 10 ~ 15 seconds, completely out performing the FreeBSD default.

Any how, I have a test iso which uses OpenRC for anyone to try in a virtual machine if they wish.
 
  • Thanks
Reactions: Kt
Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>
 
jnbek said:
if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd.
Because the question remains, even in the Linux community, about whether systemd is a 'bastardization' of "The Unix way". I'm leaning toward the idea that it is but I don't have the time to get a handle on it.
 
To comment on these:

Amzo said:
A list of features that OpenRC supports that FreeBSD init doesn't includes:
* Separation of code and configuration (init.d / conf.d )
* Stateful init scripts (is it started already?)
* Automatic dependency calculation and service ordering
* Expressive and flexible network handling (including VPN, bridges, ...)

1) Yes there is - rc.conf and an actual start-stop script (I can't be thankful enough FreeBSD didn't go with rcX.d nonsense)

2) I think /etc/rc.d/<service> status approach suffice

3) You have PROVIDE/REQUIRE for that

4) What's wrong with current setup?

I understand that's your opinion and feeling about it. I surely don't want to argue or start flame.. but .. if anything, I hope FreeBSD goes the Solaris way if it's decided to rewrite init scripts or lean towards newer (different) solution.
 
Amzo said:
A list of features that OpenRC supports that FreeBSD init doesn't includes:

* Parallel service startup

There's a couple of different proofs-of-concept for this out there for RCng already.

* Per-service resource limits (ulimit)

This can be done using the normal tools provided by FreeBSD (limits.conf, login.conf, etc).

* Separation of code and configuration (init.d / conf.d )

This exists in RCng: /etc/rc.conf vs /etc/rc.d/

* Stateful init scripts (is it started already?)

This is handled via the "status" option to every RC script.

* Automatic dependency calculation and service ordering

This is handled by rcorder(8) and the REQUIRES:, BEFORE:, and AFTER: lines in every RC script.

* Proper integration into container/virtualization (Linux-VServer, OpenVZ, ...)

Those are Linux features, so what's the point of supporting them in a FreeBSD RC setup? ;) And, we already have jail(8) which is integrated into the existing RC framework.

* Expressive and flexible network handling (including VPN, bridges, ...)

This is all supported by rc.conf. Anything you can do with ifconfig(8) at the command-line can be done in rc.conf.

As well as this, I find it is also more visually appealing. ( Tho I have added color to my original FreeBSD init)

There are a couple of projects out there that add colour to RCng on FreeBSD, although I don't know of any attempts to commit/integrate them.

So, not really seeing the overwhelming need for OpenRC.
 
jnbek said:
Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>

Systemd is full of linuxism and under the GPL and works closely with the Linux kernel, while OpenRC is multi-platform, and released under the BSDL, so it wouldn't taint the FreeBSD base.
 
UNIXgod said:
Betcha that puppy is full of bashisms!

OpenRC doesn't rely on scripts or shells, it's completely coded in C and has a small finger print.
 
Amzo said:
OpenRC doesn't rely on scripts or shells, it's completely coded in C and has a small finger print.

So I have Funtoo on my laptop which uses OpenRC. If I replace the current link from /bin/sh to dash instead of bash will I have no issues there? Just curious.

I wouldn't get your hopes up. There is nothing wrong with wanting something in base. There's more to it than "it's got BSD license". Also I can't see replacing a 30 year old rc(8) system is going to become a high priority for the devs.
 
jnbek said:
Why screw around with openrc? systemd is so much faster and far superior in pretty much every way... if the FreeBSD devs are going to go through all the BS involved with porting to another init system, they may as well just go with something that won't need to be replaced in 2 or 3 years when everyone is migrated to systemd. <my_two_cents> All this is likely a moot point anyways, since the FreeBSD devs will likely reject such ideas immediately. </my_two_cents>

The day FreeBSD switch to systemd I'll probably switch to windows. The total lines of code of systemd is at least more than the half of the total of FreeBSD kernel sources
 
kpedersen said:
Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!

Run for the hills!

Yeah, I don't know why people still want to use GNU user land over a FreeBSD kernel, that just sucks. There is no real reason to do that.
 
kpedersen said:
Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!

Run for the hills!

Incorrect. I started that project as something to do.. However, I have always used FreeBSD, that idea of that project was to optimize FreeBSD for a specific arch and offer latest binary updates as the original FreeBSD repos are always terribly outdated and not everyone has the power to compile constantly.

It was also to improve the terrible and outdated pkg_* and sluggish init system.

This is no longer the case since pkgng has arrive. I have discontinued the project.
 
kpedersen said:
Argh! It has begun. They have broken Linux so much, the distro kiddies are now coming to BSD!

Run for the hills!

By the way, this won't apply on FreeBSD because Linux is just a kernel thus there is a lot of distributions however since FreeBSD is a real OS with base, kernel and ports you will still be able to install a PURE FreeBSD OS, so we don't care if people create 100 FreeBSD derivates as you can still install the REAL FreeBSD :)
 
Markand said:
By the way, this won't apply on FreeBSD because Linux is just a kernel thus there is a lot of distributions however since FreeBSD is a real OS with base, kernel and ports you will still be able to install a PURE FreeBSD OS, so we don't care if people create 100 FreeBSD derivates as you can still install the REAL FreeBSD :)

This ^: FreeBSD allows people to change it as they please. Everyone has their different opinions. I was simply changing these to suit 'MY' needs. I found that a new init system and package manager suited me more than the current defaults.
 
Amzo said:
This ^: FreeBSD allows people to change it as they please. Everyone has their different opinions. I was simply changing these to suit 'MY' needs.
There is of course nothing wrong with that. Nor is there anything wrong with suggesting well thought out improvements or doing it yourself and sharing your work. However, one ought to keep in mind that things often are the way they are for good reasons and that FreeBSD tends to be on the conservative side when it comes to major changes. In fact, the tendency to resist the temptation of quickly adopting every new thing is part of what makes FreeBSD clean, stable and well-structured.

Anyhow, there are several projects working on changes to the init system. Feel free to check them out, report your findings and contribute code (if you can program). When something is sufficiently matured and an improvement over the current init system, it may find its way into base.

Regards,

Fonz

Note to add: I too wouldn't mind an init system with somewhat niftier and/or tidier output, but I am absolutely no fan of the SysV-style init as used by most Linux distros. That's just a mess.
 
If there's anything I'd like to be changed in the init system it's the customization of REQUIRE/PROVIDE for rcorder(8). Now you have to edit the files directly but i'd prefer a system where you could use for example /etc/rcorder.d/<service> to add or override REQUIRE/PROVIDE without touching the original files in /etc/rc.d or /usr/local/etc/rc.d.
 
kpa said:
If there's anything I'd like to be changed in the init system it's the customization of REQUIRE/PROVIDE for rcorder(8).
At first glance I'm inclined to say that this shouldn't be too difficult to achieve by tweaking /etc/rc.subr a bit.

Fonz
 
Back
Top