How to install nosh init system on FreeBSD?

Jose said:
Good point. Back to the origin of the this thread. The Nosh init system was written for the precise reason of bringing a "modern" init to Freebsd. It provides a package repository and has thorough documentation. Please use it if the current Freebsd init system is clearly obsolete and unacceptable for your purposes.
Click to expand...
I wouldn't call my concerns a plight. Thx for the links. These pages do not contain a date except a copyright note from 2017. So one must check every item for topicality... I would not install from an unknown source, but honestly I do not read all the source code neither when I build from ports, who does? BSD init is neither obsolete nor unacceptable, I was just brainstorming about where it has flaws & how to improve therein.
 
IMHO it is EoL and I hope in 2-5 years we'll switch to sysutils/runit (sysutils/daemontools or sysutils/daemontools-encore?) or OpenRC. There's a nice article on how not to do it in ewontfix.org (and the follow-up). Maybe we do not need to worry about alternatives, but IMHO the time is ripe to widely test & explore these two.
Click to expand...
So ok EoL one can interpret as beeing obsolete. That's not so important. What counts is robustness, foremost. There are issues concerning this, e.g. PID handling.
 
gh_origin said:
Linux does many tricks to help it boot time.
Click to expand...
At work, I have to use Ubuntu (version 16.04, for what's worth). Sometimes (one out of five times) the GUI (login manager) doesn't start and I'm stuck with the console, unable to do `startx` or something, only reboot helps. Sometimes the Network Manager doesn't come up. It's ridiculous. And they claim to be a "user friendly desktop operating system". I'd rather accept longer boot times if it increases stability (i.e.: deterministic, functional behavior that works).
 
I think the OP just linked to an obsolete page.

This ends with:

Close, I will reopen it with a larger update.
Click to expand...

So I am assuming by reading the comments, they want to split the project into smaller tasks rather than break FreeBSD in one go.

So unfortunately this will probably continue. I notice that their only reason for doing so is "was successful on TrueOS".
 
kpedersen said:
I think the OP just linked to an obsolete page.

This ends with:



So I am assuming by reading the comments, they want to split the project into smaller tasks rather than break FreeBSD in one go.

So unfortunately this will probably continue. I notice that their only reason for doing so is "was successful on TrueOS".
Click to expand...
So it seemed they will not stop pursuing it. OpenRC is the worse init system I have ever used (via GhostBSD). Because it's the only one that block me from shutdown and keep me stuck there for eternity at Saving dependencies... Even systemd not doing so. Yes, I usually have systemd prevent me from shutdown. But it's from application they still running on the session and need to stop. At least they have a time threshold for it to stop, about 1m30s. After that the application is force quit and the system could shutdown. OpenRC on the other hand has no such time threshold, since that Saving dependencies... stuff is of OpenRC itself.

I have never considered OpenRC as "was successful on TrueOS". It didn't offer anything really superior to the traditional RC that worth enough for a migration.

p/s: I have never actually used TrueOS, though. I stopped using PC-BSD when they renamed themselves to TrueOS and as soon as when GhostBSD started, I switched over to it. But it's nothing different. GhostBSD is TrueOS under the hood, and the developer of it is iXSystems' employee, too. BTW, I don't know if iXSystems' influent on FreeBSD is powerful enough for them to impose OpenRC on top of FreeBSD or not. But if it's so, I hope they could improve OpenRC to at least the same reliable as the traditional RC. I have no problem with systemd on Linux so I have no problem with an OpenRC-ed FreeBSD, too. But I think FreeBSD would better stick with the traditional RC.
 
kpedersen said:
I think the OP just linked to an obsolete page.

This ends with:



So I am assuming by reading the comments, they want to split the project into smaller tasks rather than break FreeBSD in one go.

So unfortunately this will probably continue. I notice that their only reason for doing so is "was successful on TrueOS".
Click to expand...
I think you assume correctly.

Incidentally, having the option at boot time to choose is just nonsense. What's the decision for the default? FreeBSD init wars!!!

Also, reading openrc on github, something stands out: "OpenRC requires GNU make. "
So if it goes into the core OS does that mean re-integrating gnu make? Or does FreeBSD still use gmake for some software? It certainly isn't in the base. Would seem rather odd being as the goal of the project is expunging GPL from base.
Anyone able to enlighten me?
 
mark_j said:
I think you assume correctly.

Incidentally, having the option at boot time to choose is just nonsense. What's the decision for the default? FreeBSD init wars!!!

Also, reading openrc on github, something stands out: "OpenRC requires GNU make. "
So if it goes into the core OS does that mean re-integrating gnu make? Or does FreeBSD still use gmake for some software? It certainly isn't in the base. Would seem rather odd being as the goal of the project is expunging GPL from base.
Anyone able to enlighten me?
Click to expand...
If it's insane why don't go with a crazier idea? The porting of LaunchD seemed to be dead. What about porting Solaris/Illumos' SMF to FreeBSD? Better than that OpenRC, of course. The CDDL seemed to be not a problem for FreeBSD (ZFS, DTrace all CDDL-ed). And it's nothing surprise for me for a software developed by a Linux distro (Gentoo) to require a GNU software.

BTW, I still prefer the current RC over all of them.
 
Have a look at the links I supplied on runit throughout this thread. IMHO it looks very promising. Doesn't mean it has no issues, though. That's to be expected on a software that is not so widely used.
 
FWIW, I have read the thread from start to finish and although mostly off topic (how to install nosh), I think that this discussion is definitely worth having, as all other possible enhancements to our favorite operating system!

But the discussion on replacing or adding a new service manager may, first of all, better be had in it's own thread with a more appropriate title, to attract a wider audience?

Second is that very few core devs are active forum members. So the outcome can only be seen as something from the general user's standpoint, which is also good, but worthless for changing anything. To actually change something, the devs are over at the mailing lists, where you can point to a thread like this as a basis for continued discussion. Of course, they have a different perspective of pros and cons, so who knows how that discussion will end, but nevertheless, a discussion well worth having!
 
My interest in the init system question started when I began enduring the consequences of the switch of Linux to systemd and, after using Devuan for some time, I ended up using Void Linux.

Void uses runit, which is very simple (< 500 LOC vs. 2.5+ MLOC for systemd), yet very efficient as an init and supervision system.
Its author(s?) have brilliantly demonstrated their command of the KISS principle! :)

I've also tried Devuan 3.0, which now offers the choice between SysV init and OpenRC. OpenRC is admittedly smaller than systemd and strictly focused on system initialization, but it internally relies on SysV init. Devuan with OpenRC appears to be noticeably slower than Void at boot (less noticeably after boot). I haven't compared with a pure SysV init Devuan 3.0, but I have used Devuan 1.0 and 2.0 (both SysV init only) previously and don't remember they were so slow to boot.

Last year, I have tested GhostBSD and besides its high memory usage, I have been impressed by its slowness. It also uses OpenRC instead of BSD RC, but GhostBSD is slow even after boot, so I hadn't put the blame on OpenRC at that time.

I've recently tested Artix Linux, an Arch-derivative offered in 3 init flavors, OpenRC, runit and s6. I tried them all and came to the same conclusion as with Devuan: OpenRC is noticeably slow - and much slower than runit. s6 didn't demonstrate any blatant superiority over the others, so I didn't investigate any further.

What I like with simple pieces of software such as runit is that the less lines of code, the less bugs/security holes and the quicker the fixes. And the easier the learning for admins and contributors, of course.

Like other participants, I think FreeBSD doesn't need to change its init system, it is simple enough and does its job well. If some more improvements can be brought (parallel start has been cited), that's fine, but for now, development resources would be much better employed in other areas.
 
gh_origin said:
If it's insane why don't go with a crazier idea? The porting of LaunchD seemed to be dead. What about porting Solaris/Illumos' SMF to FreeBSD? Better than that OpenRC, of course. The CDDL seemed to be not a problem for FreeBSD (ZFS, DTrace all CDDL-ed). And it's nothing surprise for me for a software developed by a Linux distro (Gentoo) to require a GNU software.

BTW, I still prefer the current RC over all of them.
Click to expand...

Actually I said nonsense not insane, but you could probably substitute those words and not lose context. ;)

Launchd is, in my mind, an awful system. Likewise Solaris SMF. Granted there are some good points to both systems but I just detest that XML/DTD stuff. Launchd is particularly nasty as if it fails its error messages are about as useful as stating "? error ?". Sometimes it's not even that verbose! o_O

Did Sun actually open source SMF?
 
mark_j said:
Actually I said nonsense not insane, but you could probably substitute those words and not lose context. ;)

Launchd is, in my mind, an awful system. Likewise Solaris SMF. Granted there are some good points to both systems but I just detest that XML/DTD stuff. Launchd is particularly nasty as if it fails its error messages are about as useful as stating "? error ?". Sometimes it's not even that verbose! o_O
Click to expand...


So runit or s6 is the way to go ;)

mark_j said:
Did Sun actually open source SMF?
Click to expand...


github.com

GitHub - illumos/illumos-gate: An open-source Unix operating system

An open-source Unix operating system. Contribute to illumos/illumos-gate development by creating an account on GitHub.
github.com github.com
 
/!\ Ironie on this post !

Runit have 500 LoC ?
It is a fat init !
See : https://gist.github.com/rofl0r/6168719
Systemd has only 2.5M LoC ?
May we add a custom database (no sql as this is cool) into it that handle users password ?

Frankly, it appear that FreeBSD find a good compromise when we read this topic.
The initial question is not about changing the FreeBSD init for all user to save the project, but how to test, experiment an another init system.
So why the debate about what is a good init ?
For my opinion, an init with 80 LoC (sinit) is enough because task like supervision have to be separated (KISS).
A good modern boot process has more chance to emerge if init is simple, rc is simple and so on.
 
Hakaba said:
Frankly, it appear that FreeBSD find a good compromise when we read this topic.
The initial question is not about changing the FreeBSD init for all user to save the project, but how to test, experiment an another init system.
So why the debate about what is a good init ?
Click to expand...
You are right. I think I should quit this discussion.
 
Hakaba said:
/!\ Ironie on this post !

Runit have 500 LoC ?
It is a fat init !
See : https://gist.github.com/rofl0r/6168719
Systemd has only 2.5M LoC ?
May we add a custom database (no sql as this is cool) into it that handle users password ?

Frankly, it appear that FreeBSD find a good compromise when we read this topic.
The initial question is not about changing the FreeBSD init for all user to save the project, but how to test, experiment an another init system.
So why the debate about what is a good init ?
For my opinion, an init with 80 LoC (sinit) is enough because task like supervision have to be separated (KISS).
A good modern boot process has more chance to emerge if init is simple, rc is simple and so on.
Click to expand...
Well, FreeBSD's init.c has ~2k LOC... Would you call that fat, too? Some issues were discussed above (previous pages). What's wrong with exploring & evaluating runit?
 
Using runit would IMO not be difficult. Also, I find both runit and FreeBSD's init scripts share the same important quality: if you don't know how it works, you can simply read the scripts, and there aren't so many. The complexity of these init systems stays at a human scale and that's a damn good thing!

However, using another init system would immediately obsolete tons of good documentation and zillions of forum/mailing list posts available through a simple web search.

This is exactly what systemd did to Linux: any piece of software under systemd's control stops behaving as documented, so whenever you run into trouble, you have to find out how systemd twisted it and learn how to live with it. And unfortunately, documentation is not the most prominent feature of systemd...

However, whatever the cost incurred, it may be worth paying it if the advantages you get in return significantly outweigh that cost.

The industry likes systemd because they mainly use Linux in the form of VM or containers to create web applications. For them, systemd brings uniformity and there is no associated cost: systemd is only a plague to humans (end users/admins/developers), not to JavaScript HTTP clients.

Nowadays, technology is never a limitation, we could spend our whole life evaluating great solutions, yet being unable to choose one for all have their own strengths and weaknesses. Only human needs can drive technology choices.

Thus, before experimenting with another init system, we should be clear about what we expect as benefits and why.
 
There's an easy way out. Right now I'm looking at freebsd/freebsd in the github. Apparently its source is open, even the licence has Stallman's blessing. There are 2^8-2 contributors, and for some strange reason 2K Forks. Here the solution:
Find a group of people interested in this particular subject and establish a group. Fork a minimal subset of the project. Hold and announce a competition and run a shared youtube channel and ask for donation (collecting for award/prize). As far as I know there's going to be 2-3 idea around init system, therefore 2-3 forks from the fork. Set a deadline. Run a poll & benchmark, declare the winner and give them the prize, collected in youtube channel.
 
20-100-2fe said:
However, using another init system would immediately obsolete tons of good documentation
Click to expand...

This is so true. Linux has never had to worry about this because the best they have is a scrappy Arch Wiki haha.

I find it a little appauling that there are no de-facto Linux books with indepth coverage of systemd yet. It is starting to suggest that few people use Linux compared to simply talking about using Linux.... :/

Unlike dealing with consumer crap like Windows or iPhones, documentation is often more important than the software itself. Linux communities are trying to mask their severe weakness with (broken) GUI systems.
 
kpedersen said:
It is starting to suggest that few people use Linux compared to simply talking about using Linux....
Click to expand...

Here in Luxembourg, the economy is dominated by the financial sector and European or international institutions. Both were running Solaris and AIX on their servers a few years ago and are now running Linux. However, several orders of magnitude separate the number of Linux kernels running in VM from those running on bare metal. It looks like Linux has become a standard tool managed more often by other tools than by human beings.
 
20-100-2fe said:
It looks like Linux has become a standard tool managed more often by other tools than by human beings.
Click to expand...

Yeah, I can certainly see this. The config is becoming more and more machine readable/writable (systemd .ini files) and less flexible (compared to shell scripts). Likewise the tools are becoming less and less powerful in their own right (i.e ip vs ifconfig) and instead are intended for automation via NetworkManager and bloat like that.

Thats fine. Linux can do what it wants. I am only interested in UNIX-like operating systems anyway.
 
You must log in or register to reply here.
Back
Top