# Your thoughts about init system



## boombim (Mar 28, 2021)

Hello. What do you think about current initialisation system in freebsd? Should it be changed or it's decent?
How about modern faster init system as runit or whatever?


----------



## zirias@ (Mar 28, 2021)

It works well, it avoids (in contrast to sysv-init) unnecessary complexity, and the mewburn rc is a great framework for short and reliable init scripts. Don't change things without an actual need.


----------



## drhowarddrfine (Mar 28, 2021)

And don't change for the sake of change.


----------



## kpedersen (Mar 28, 2021)

boombim said:


> How about modern faster init system as runit or whatever?


Can you explain the use of the word modern? Is it written using a modern language? It doesn't look like any of the ideas presented by it are particularly recent. In any case, of course we have it in ports for you to use.

https://svnweb.freebsd.org/ports/head/sysutils/runit/
https://svnweb.freebsd.org/ports/head/sysutils/runit-faster/

Why do you need faster? How often do you boot?! Possibly your use-case is not well aligned to FreeBSD.

Also, perhaps look around too, there are FreeBSD based projects like GhostBSD that use alternatives i.e OpenRC (https://wiki.ghostbsd.org/index.php/OpenRC).


----------



## SirDice (Mar 28, 2021)

boombim said:


> Should it be changed or it's decent?


Why do you think it _needs_ to change?

I'm going to gently nudge you towards: https://forums.freebsd.org/threads/why-is-freebsd-not-more-like.66591/


----------



## ct85711 (Mar 28, 2021)

From what I have seen, the current init for FreeBsd does what it should be doing and doesn't have any significant issues.  From this view, there isn't a need to change something that is working properly for an unknown system.  Even when I was on Gentoo, runit was proposed, and yet it was even asked there why change something that's been working for several years for a new program that hasn't even been around all that long.  The other part to keep in mind, the init isn't something you should change without a very serious thought and numerous testing; as it is one of the key processes.  So it isn't something like some graphics or office program that you change out when ever you feel like it without any issues.


----------



## hruodr (Mar 28, 2021)

Why always these questions?! Sure there is a lot of things to improve, but why always the same targets,
parts of the system that work and always worked since they are in (Free)BSD?


----------



## Crivens (Mar 28, 2021)

Oh, and I will leave this little thing here for when the argumemts to adapt you-know-what crop up.
We had that ad-nauseam.
 *puts Stormbreaker next to the thread*


----------



## Deleted member 66267 (Mar 29, 2021)

Perhaps all of these guys need something like SystemBSD, BSD licensed clone of SystemD so they don't have to learn the new thing when switching from Linux to FreeBSD. They only want to carry their culture on with them but don't want to learn to do the native platform's ways.


----------



## Crivens (Mar 29, 2021)

Well, that didn't take long for the thing that shall not be mentioned to be mentioned...


----------



## Deleted member 30996 (Mar 29, 2021)

Works great. Don't change a thing.

/home/jitte/.xinitrc

```
gkrellm &
urxvt &
xfe &
fluxbox start
```

What could be more simple? That's all I worry about needing to get to the desktop.


----------



## mark_j (Mar 29, 2021)

boombim said:


> Hello. What do you think about current initialisation system in freebsd? Should it be changed or it's decent?
> How about modern faster init system as runit or whatever?


Because of FreeBSD's design, it is "relatively" easy to port another init system to be used instead of the standard rc. (Hopefully it's POSIX etc)
GhostBSD has done it, for example. There are others available in ports, such as runit. Go for it, try it and let us know.


----------



## Deleted member 66267 (Mar 29, 2021)

mark_j said:


> Because of FreeBSD's design, it is "relatively" easy to port another init system to be used instead of the standard rc. (Hopefully it's POSIX etc)
> GhostBSD has done it, for example. There are others available in ports, such as runit. Go for it, try it and let us know.


I hope there is a port of SysV-init used by Devuan so I could reuse init scripts from Devuan. I tried to use Devuan's init scripts with our RC, it will not work. The syntax is incompatible.


----------



## Deleted member 66267 (Mar 29, 2021)

Crivens said:


> Well, that didn't take long for the thing that shall not be mentioned to be mentioned...


So "SystemD" is the forbidden word? Perhaps SirDice's "Why FreeBSD not more like..." is sufficient to answer, I don't need to write too explicit like this.


----------



## Crivens (Mar 29, 2021)

Google the propper Life Of Brian scene for yourself please 

And obnoxious, Linux has bash for such things, we use sh.


----------



## zirias@ (Mar 29, 2021)

Crivens said:


> And _*[FONT=monospace]obnoxious[/FONT]*_, Linux has bash for such things, we use sh.


But that's not the reason, SysVinit works fine with any POSIX shell as long as the actual init-scripts don't have bashisms. Debian has used dash for /bin/sh for a long time.

But SysVinit IMHO has unnecessary complexity (especially with these run-levels) and still doesn't solve important things like a _sane_ rc framework and things like rcorder(8). LSB init scripts added that somehow…

If you need an init script on FreeBSD, just write one. Chances are it will be very short and readable, if you use the mewburn rc framework correctly.


----------



## tuaris (Mar 29, 2021)

It depends on the use case.

I love the current system for it's simplicity, but it does lack in some areas such as parallelism, on-demand start/stop, recovery options, and more complex dependency management. It doesn't make sense to compare rc.d() with systemd, the two solve different problems.

The idea behind systemd (even for all the negativity around it) is actually very good.  I think the hate around it was due to the way it was "sold" as an init system, but instead delivered a lot more.  It's something completely new that had never existed before (at least in Unix/Linux).  I like the concept of a "system layer" that sits between kernel and userland.  Such a design works very well for "modern" desktop/laptop platforms.  I personally wouldn't mind seeing such a system layer appear in FreeBSD, maybe even something that cooperates with rc.d() instead of replacing it.  In a way, devd() is kind of like this.

For servers I wouldn't change a thing, rc.d() works perfectly.  Servers already take several minutes to just run through the POST process.  An extra delay with booting up the OS and starting all the services in sequence doesn't add much to an already long wait.  Additionally, you don't really need all that extra fancy stuff systemd brings running on a server.


----------



## drhowarddrfine (Mar 29, 2021)

tuaris said:


> It depends on the use case.


Why is that the current "buzz phrase" for so many answers to so many questions?




tuaris said:


> it does lack in some areas such as parallelism, on-demand start/stop, recovery options, and more complex dependency management.


You could be more vague but those sound like applications, not operating system  issues.


----------



## mark_j (Mar 29, 2021)

tuaris said:


> It depends on the use case.
> 
> I love the current system for it's simplicity, but it does lack in some areas such as parallelism, on-demand start/stop, recovery options, and more complex dependency management. It doesn't make sense to compare rc.d() with systemd, the two solve different problems.



These can all be achieved with ports. Ports allow you to tailor your system beyond the bare basics. Nothing new here. (In fact some parallelism is able to be obtained with rc anyway).




tuaris said:


> The idea behind systemd (even for all the negativity around it) is actually very good.  I think the hate around it was due to the way it was "sold" as an init system, but instead delivered a lot more.  It's something completely new that had never existed before (at least in Unix/Linux).  I like the concept of a "system layer" that sits between kernel and userland.  Such a design works very well for "modern" desktop/laptop platforms.  I personally wouldn't mind seeing such a system layer appear in FreeBSD, maybe even something that cooperates with rc.d() instead of replacing it.  In a way, devd() is kind of like this.


We've been here before. This is a road well travelled.
Systemd (just the init system) is not required in FreeBSD (or any BSD) because of one BASIC thing. Linux is a KERNEL, not an OS. Everyone takes Linux the kernel and drops some userland on it, let's say GNU, and then throws their preferred other bits into it.
In contradiction to this *BSDs are an entire OS, with a kernel and userland and ports/packages.

systemd is someone's attempt to unify the linux world and turn it into something like *BSDs. I wish them luck, we've been lucky to have that since BSD was invented.

systemd as the gigantic, over-bloated userland replacement is just grotesque, however.


tuaris said:


> For servers I wouldn't change a thing, rc.d() works perfectly.  Servers already take several minutes to just run through the POST process.  An extra delay with booting up the OS and starting all the services in sequence doesn't add much to an already long wait.  Additionally, you don't really need all that extra fancy stuff systemd brings running on a server.



systemd re-invents the wheel and calls it wheeld...


----------



## wolffnx (Mar 29, 2021)

why dont adapt your current setup to your needs?
for a desktop system is easy, run the init scripts in parallel for example
the init system wont be changed for shure and for luck for all of us
so..my advice is, start "hacking" your setup


----------



## a6h (Mar 29, 2021)

I think user _"obnoxious"_ == user _"failure"_,
and few more deleted/merged accounts for at least last two years.
Am I right?


----------



## Deleted member 66267 (Mar 29, 2021)

vigole said:


> I think user _"obnoxious"_ == user _"failure"_,
> and few more deleted/merged accounts for at least last two years.
> Am I right?


Yes. I lost failure's password. I have bad luck with Windows 10 so I'm here again, only to struggle with compiling IUP on FreeBSD. My writing style never changed and I have no need to hide it.

p/s: I need IUP to power up this FreeBASIC IDE: https://www.freebasic.net/forum/viewtopic.php?f=8&t=26030&start=90


----------



## decuser (Mar 29, 2021)

OMG . Change the init system? I came to FreeBSD because it was a calm oasis of rational thought. The systemd debacle, or kerfuffle, or whatever you wanna call that madness over in Linuxland, was nuts (I heart Linux, too, so don’t flame me). The init system in FreeBSD is super straightforward, has supported every use-case I’ve ever had, and is quite elegant as well. Don’t fix what ain’t broke, puhlease!


----------



## kpedersen (Mar 29, 2021)

vigole said:


> I think user _"obnoxious"_ == user _"failure"_,
> and few more deleted/merged accounts for at least last two years.
> Am I right?


I had a feeling. The timing did fit. To be fair I also had a suspicion that the OP could have also been a reincarnation of the gh_*.


----------



## shkhln (Mar 29, 2021)

As for the topic, I usually don't think about init systems.



kpedersen said:


> Oh you reckon boombim == obnoxious == failure == gh_*?


Nah, OP doesn't match the style. Let me rephrase: obnoxious == gh_origin.


----------



## Jose (Mar 29, 2021)

tuaris said:


> The idea behind systemd (even for all the negativity around it) is actually very good.


Systemd is both good and new. Unfortunately what is new is not good, and what is good is not new.





						Your Manuscript Is Good and Original, But What is Original Is Not Good; What Is Good Is Not Original – Quote Investigator
					






					quoteinvestigator.com


----------



## drhowarddrfine (Mar 29, 2021)

I've had the same username since before the original FreeBSD forum 17 years ago. I created it some number of years before that on the Hutch's MASM assembly language forum. It was originally the complete drhowarddrfinedrhoward (if you're a Stooges fan) but it got truncated by a forum software upgrade. Hence the current version today.


----------



## Beastie7 (Mar 29, 2021)

The direction of this thread is hilarious. Failure is now waldo in the forums.


----------



## Mjölnir (Mar 29, 2021)

Thank you VERY much for your invaluable fruitation of my never ending pondering about the future of the _almighty BeaSD_; may I mention this thread in the next week's BMW?


----------



## Beastie7 (Mar 29, 2021)

As a lover of BMWs, I can't subscribe to today's BMWs.


----------



## Mjölnir (Mar 29, 2021)

Beastie7 said:


> As a lover of BMWs, I can't subscribe to today's BMWs.


You can.  I was a little bit late, but I updated it in the afternoon IIRC.  P.S. Don't forget to click _Like_ @least 3 times in a row, until Trihexagonal's _Demonica_ pops up & dances on your X11 desktop background image.


----------



## drhowarddrfine (Mar 30, 2021)

I have no clue what's going on with all that and prefer not to have a clue.


----------



## Berserker79 (Apr 4, 2021)

FreeBSDs' init system is one of the reasons I switched from linux!


----------



## Alain De Vos (Apr 4, 2021)

The init system is easy.
It's easy to edit /etc/rc.subr ; /etc/rc.d/* ; /usr/local/etc/rc.d/*
I wonder however if "sh" the best language. I think you could use lua or another language which is more readable.


----------



## eternal_noob (Apr 4, 2021)

Berserker79 said:


> FreeBSDs' init system is one of the reasons I switched from linux!


Not every Linux init system is bad. `systemd` is pretty bad but for example Void Linux uses runit which is pretty decent.


----------



## Alain De Vos (Apr 4, 2021)

The other distro is devuan, which uses openrc.
You don't care about the init system unless you want to tune it according to your own needs.
And there is where systemd can become a pain.


----------



## kpedersen (Apr 4, 2021)

Weirdly Linux could really benefit from just one init system. It will reduce the burden on packagers and reduce fragmentation. However that init system also needs to be competent and UNIX-like.

I actually don't mind systemd. (Windows 3.1 style .ini files are easy to use after all). However I prefer working with UNIX technologies. It is the UNIX design that has stood the test of time, not necessarily individual operating systems. Linux is popular enough that systemd won't kill it now. However if systemd was introduced when Linux was much younger, it would have been much less successful.


----------



## zirias@ (Apr 4, 2021)

Alain De Vos said:


> You don't care about the init system unless you want to tune it according to your own needs.
> And there is where systemd can become a pain.


Or, if something misbehaves and you want to have a look to fix it 

But, especially about the "tune to your needs" part, I had my share of "fun" with systemd. E.g. when I needed to run multiple instances of the same service. It felt like black magic how to make this work with systemd.

With FreeBSD's mewburn rc, although it isn't directly supported, init scripts for services where this makes sense implement a very simple workaround using just symlinks…


----------



## Matlib (Apr 4, 2021)

The rc scripts do what they are supposed to and I guess there is hardly any pressure to replace them with anything in the default install.

systemd is an integrated init, inetd, dbusd and udevd, user login support, plus some network and container management stuff in one blackboxed piece. It's as anti-UNIX as it can only be. (Ok, it doesn't have a built-in MP3 player... yet). It was created on the wave of mimicking some commercially available operating systems based on false perception that if something sells for a lot of money then it must be better somehow.

When it was being introduced, the official explanation was that laptops would boot faster. While I can't personally see any difference (maybe systemd is a second faster compared to sysvinit), the main thing is that total reboot of a Linux-based laptop is not a typical everyday user experience. So it solved a non-existing problem in a rarely executed scenario.

Second explanation was that it could automatically restart services. Apart from the fact that init and most of its alternatives can do that, that's usually not something you want to do. For example if a database crashes with SIGSEGV, an uncotrolled restart is not very much desireable.


----------



## decuser (Apr 4, 2021)

Matlib said:


> (Ok, it doesn't have a built-in MP3 player... yet).


Well, it's not for lack of interest:
systemd+mp3 google results

Nuts!


----------



## Berserker79 (Apr 4, 2021)

Alain De Vos said:


> The other distro is devuan, which uses openrc.
> You don't care about the init system unless you want to tune it according to your own needs.
> And there is where systemd can become a pain.


I have tried Devaun (which is derived from debian)with openrc, as well as Artix (which is derived from arch) with openrc. Both are good but they all have the drawbacks of being linux making them obviously not FreeBSD. If you've used FreeBSD you most likely will not return to linux.


----------



## zirias@ (Apr 4, 2021)

Well, uhm, LOL.

(please add an "amused" reaction to the forums, hehe)


----------



## vometia (Apr 4, 2021)

Matlib said:


> Ok, it doesn't have a built-in MP3 player... yet


Careful now, someone might just think to themselves, "what the Unix world really needs is for systemd to be integrated with PulseAudio"...


----------



## zirias@ (Apr 4, 2021)

`s/fire/poetterware/`



> I'll just put this over here, with the rest … of the fire







_View: https://youtu.be/1EBfxjSFAxQ_


----------



## Beastie7 (Apr 4, 2021)

vometia said:


> Careful now, someone might just think to themselves, "what the Unix world really needs is for systemd to be integrated with PulseAudio"...



Just one more thing..

I present you... PoetterOS

**round of applause**

I think you're going to hate it.


----------



## Menelkir (Apr 4, 2021)

Matlib said:


> Second explanation was that it could automatically restart services. Apart from the fact that init and most of its alternatives can do that, that's usually not something you want to do. For example if a database crashes with SIGSEGV, an uncotrolled restart is not very much desireable.


Because Poettering didn´t know the difference between an init system and a supervisor. At this point, since systemd is an octopus supposed to do everything, it doesn´t really matter anymore.


----------



## ct85711 (Apr 4, 2021)

I think anymore, systemd is already well on the way to being an octopus encompassing everything; they already pushed out the part that now systemd controls your user home directory and does it's own encryption stuff.  Eventually, they'll just include their own kernel and lock in everything even more.


----------



## Menelkir (Apr 4, 2021)

ct85711 said:


> I think anymore, systemd is already well on the way to being an octopus encompassing everything; they already pushed out the part that now systemd controls your user home directory and does it's own encryption stuff.  Eventually, they'll just include their own kernel and lock in everything even more.


As part of the big plan, since you have more things outside of the systemd that copes with them, such as gnome and everything also entangled with gnome. If you look outside the box, there´s more to come.


----------



## vometia (Apr 4, 2021)

Zirias said:


> Well, uhm, LOL.
> 
> (please add an "amused" [snip])


Ah yes, amused, the new systemd add-on daemon which will control the flow of humour and entertainment that is permitted on one's system.


----------



## Menelkir (Apr 4, 2021)

vometia said:


> Ah yes, amused, the new systemd add-on daemon which will control the flow of humour and entertainment that is permitted on one's system.


They´ll probably create a systemd-nocomplaind so you can´t blame systemd for trashing your system. Also, with a nocomplaind-list.service with a list of words that you can´t use against systemd.


----------



## Hakaba (Apr 4, 2021)

FreeBSD need a better init as 'sinit'. Less lines of code is a very modern feature. Only do init job in init is the more modern way to think.
And of course I can argue this point.

But the FreeBSD has a very decent and robust init and if you have bad feeling with RC, share your experimentation with other init system.

For me, RC is the good choice inside FreeBSD regarding others tools and global philosophy (Unix way, "do one things ..." and so on).


----------



## Alain De Vos (Apr 4, 2021)

There is one in thing and that is that "sh" scripts can easily have syntax errors.
Whereas for instance a C compiler informs you on the error.


----------



## zirias@ (Apr 4, 2021)

Alain De Vos said:


> Whereas for instance a C compiler informs you on the error.


That's the worst take possible, see "undefined behavior".


----------



## Mjölnir (Apr 5, 2021)

Zirias said:


> That's the worst take possible, see "undefined behavior".


There are ways to mitigate C's shortcomings.  E.g. IIRC vigole posted some links to the CEI SEI CERT guidelines, & IIRC some notable organisations have commited to follow these: restrict to a subset of C features, and comply to certain algorithmically provable policies.


----------



## a6h (Apr 5, 2021)

Mjölnir said:


> There are ways to mitigate C's shortcomings. E.g. IIRC _*vigole*_ posted some links to the CEI CERT guidelines








						SEI CERT C Coding Standard - SEI CERT C Coding Standard - Confluence
					






					wiki.sei.cmu.edu


----------



## zirias@ (Apr 5, 2021)

I don't consider undefined behavior a "shortcoming". It's a deliberate design decision in the language, one that is of course "dangerous" because it requires the programmer to know _exactly_ what they do, but it enables two valuable things:

Aggressive optimizations during compilation
Close to _no_ runtime overhead
Instead of restricting yourself to a subset, I prefer really studying the standard, so you will spot UB and avoid it. Admittedly, a steep learning curve, and an unfamiliar experience for those who only know "fully defined" languages that will catch errors at least at runtime. Not knowing what you do in C can have fatal consequences.

All I said is, it's a very wrong assumption that a C compiler would always complain about programming errors, relying on that is begging for disaster.

edit:


vigole said:


> SEI CERT C Coding Standard - SEI CERT C Coding Standard - Confluence
> 
> 
> 
> ...


I'm surprised. At least at a first glance, this doesn't contain any bullshit as many of these coding guidelines do. Also, it doesn't seem to restrict the programmer to a "subset" (at least not, if you don't consider undefined or implementation-defined behavior a part of the "full set").


----------



## a6h (Apr 5, 2021)

Zirias said:


> I'm surprised. At least at a first glance, this doesn't contain any bullshit as many of these coding guidelines do.


AFAIK it's focused on security guideline, than optimisation. IIRC I've read about SEI CERT guideline in Deitel C book -- many years ago, thus I could be wrong.

[EDIT]:
Such guidelines, such as _SEI CERT_, will prevent neophytes from developing bad habits.
For example `gets` is officially being deprecated in C++11, and was removed in C++14.
But there're many old and/or unedited online tutorials on the web with `gets` examples.

SEI CERT Guideline for C++





						SEI CERT C++ Coding Standard - SEI CERT C++ Coding Standard - Confluence
					






					wiki.sei.cmu.edu


----------



## kpedersen (Apr 5, 2021)

Alain De Vos said:


> There is one in thing and that is that "sh" scripts can easily have syntax errors.
> Whereas for instance a C compiler informs you on the error.


I would also say it is very easy to make mistakes in the systemd .ini files that go unnoticed.

Especially when they add hacks like:


```
InitFlags=
InitFlags=-a
```

The first entry clears the flags, the second appends flags. You need both.


----------



## Jose (Apr 5, 2021)

Alain De Vos said:


> There is one in thing and that is that "sh" scripts can easily have syntax errors.


This is true of any interpreted language. I liked to find problems on a large PHP project I worked on simply by opening files in an IDE that did static analysis.


----------



## Mjölnir (Apr 6, 2021)

OK now you gave an example with the 2nd worse programming language...  it is well known & commonly accepted _nerd_ folk wisdom that sh(1)ell scripts are more error prone than other languages.


----------

