# How to install nosh init system on FreeBSD?



## zoujiaqing (Jul 24, 2020)

I looked Nosh is a special software for BSD and Linux, support FreeBSD / OpenBSD and Debian.
The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging. 

```
https://jdebp.eu/Softwares/nosh/
```


----------



## kpedersen (Jul 24, 2020)

zoujiaqing said:


> I looked Nosh is a special software for BSD



The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives


----------



## zoujiaqing (Jul 25, 2020)

Thanks, I used FreeBSD version is 13-CURRENT, I will to try it.


----------



## zoujiaqing (Jul 25, 2020)

kpedersen said:


> The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives


Nosh same to systemd, there are many advantages.


----------



## jmos (Jul 25, 2020)

zoujiaqing said:


> Nosh same to systemd, there are many advantages.


Haven't seen one, only the opposite quite often… anyway: There's plenty documentation on the website posted by you - even as txz package; So how to install txz archives: Download all relevant packages, and then just execute for every package: "pkg install /path/to/filename". Then nosh and its documentation is installed.

But if that's really the question I would recommend not to install such a software.


----------



## kpedersen (Jul 25, 2020)

zoujiaqing said:


> Nosh same to systemd, there are many advantages.



Too many disadvantages.


----------



## Mjölnir (Jul 25, 2020)

kpedersen said:


> The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives


Well, I'd rather say _it works_ than call it _solid_.  FreeBSD is great, but that doesn't mean each & every part of it is great, too.  The SysVinit we have is really old-fashioned, to put it politely.

no parallel service startup
vulnerable to mistakes in the service scripts; these are very common as it's shell script syntax, and often they are subtle errors (notably, the depency handling is commonly called _dependency hack_)
missing features that nowadays can be considered standard on most alternative solutions: service supervision, automatic restart
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.

zoujiaqing, you might want to have a look at these alternatives, as they are either already available as package/port, or in case of _OpenRC_, were already in use on a FreeBSD derivative (TrueOS).  You'll be able to find details in the old sources of TrueOS.


----------



## zirias@ (Jul 25, 2020)

mjollnir said:


> The SysVinit we have


There's no SysV init in FreeBSD. It's a BSD init with mewburn rc. You might want to read this old paper: http://target0.be/madchat/sysadm/bsd/netbsd.pdf

Service supervision should not be the concern of init. If you need supervised services, there are separate tools for that.


----------



## Mjölnir (Jul 25, 2020)

Zirias said:


> Service supervision should not be the concern of init. If you need supervised services, there are separate tools for that.


IMHO it should be.  It's the same realm.  Of course the _init_ process itself should be as simple as possible, but the alternatives mentioned above and others do include such functionality in their related tools for good reason.
EDIT From my understanding it can be named _SysV-style init_.  I may be wrong here...  the name does not matter.  The functionality does.


----------



## zirias@ (Jul 25, 2020)

mjollnir said:


> IMHO it should be.  It's the same realm.  Of course the _init_ process itself should be as simple as possible, but the alternatives mentioned above and others do include such functionality in their related tools for good reason.


I don't think there's _any_ good reason to have such functionality in the same software package. If init doesn't have that feature itself (which it clearly shouldn't), your supervisor will run as a child of init anyways.


----------



## Mjölnir (Jul 25, 2020)

Zirias said:


> I don't think there's _any_ good reason to have such functionality in the same software package. If init doesn't have that feature itself (which it clearly shouldn't), your supervisor will run as a child of init anyways.


Then there would be many configuration doubled (redundant), e.g. flags to start/restart a service.  These topics overlap, they are very closely related, and that's a clear indication that it's the same realm.  In fact, that _is_ a good reason, indeed.


----------



## zirias@ (Jul 25, 2020)

No, it isn't. I don't see any reason for any doubled configuration -- if I want a "supervised" service, I only configure it in the tool used for that, not in the system's init.

This wording (configuration) brings me to the next criticism: shell scripts. With mewburn rc, there's a large and useful library, so your init script for a "normal" service needs only a few lines. Dependencies also work rock solid. Still, with these scripts, I can do _anything_ unforeseen by the designers of the init system. I personally wouldn't ever want to use a system that replaces scripts by some "configuration".

The only thing FreeBSD's init system can't do at the moment that _might_ make some sense to me is parallelization. Of course, this would just gain faster startup times. If I have the choice between shell scripts and faster startup, I choose the scripts. Sure, would be nice to have both.


----------



## Mjölnir (Jul 25, 2020)

Zirias said:


> No, it isn't. I don't see any reason for any doubled configuration -- if I want a "supervised" service, I only configure it in the tool used for that, not in the system's init.


E.g.: maybe the flags to restart a service slightly differ from the flags applied to start it.  In standard BSD style, this could be solved by `xy_flags="-a -b -c"` & `xy_restart_flags="$xy_flags -x"` in rc.conf(5).  But it could also be  `xy_restart_flags="-a -b -x"`. It should be clear that these overlap because their common topic is the service in question.


> This wording (configuration) brings me to the next criticism: shell scripts. With mewburn rc, there's a large and useful library, so your init script for a "normal" service needs only a few lines. Dependencies also work rock solid.


Experience shows that it's too easy to get it wrong?  At least it is error-prone, since it's shell syntax.
EDIT And it's not easy for newbies & non-nerds.  You & me can write/fix/change those scripts, they can not.


> Still, with these scripts, I can do _anything_ unforeseen by the designers of the init system. I personally wouldn't ever want to use a system that replaces scripts by some "configuration".


With the same argument you could ban ports & packages and instead use old-fashioned _tar balls_ with ./configure scripts, like in the old days.  To use a more modern approach does not neccessarily mean there can not be room for pre/post/alternative scripts.  IIRC even the overly complex Solaris SMF does allow you to completely bypass the pre-defined standard methods and provide your custom start/stop script, if you think it's reasonable.


----------



## hruodr (Jul 25, 2020)

I never understood the suposed need to inflate `init`. Since starting the system is critical, I like `init` as simple as possible, hence also without paralelisation.


----------



## kpedersen (Jul 25, 2020)

mjollnir said:


> no parallel service startup



That is good. More deterministic behavior. Less bugs.

Servers don't shutdown and Laptops / workstations sleep. Fast "reboot" time is an old-fashioned concept. Even Windows doesn't shutdown by default these days.



mjollnir said:


> vulnerable to mistakes in the service scripts; these are very common as it's shell script syntax, and often they are subtle errors



I would rather mistakes in plain-text scripts than binary Win32/systemd units. Either way, bugs happen in all approaches. BSD's are just easier to debug.



mjollnir said:


> (notably, the depency handling is commonly called _dependency hack_)




```
ExecStart=
ExecStart=/path/to/program
```

This hack doesn't have a name yet because systemd is too young. I call it ".ini files are crap for handling services". Catchy huh? 



mjollnir said:


> missing features that nowadays can be considered standard on most alternative solutions: service supervision, automatic restart



These have different use-cases. For example Windows, macOS and systemd all target consumer desktop environments.


----------



## jmos (Jul 25, 2020)

mjollnir said:


> IMHO it should be.  It's the same realm.


Thought over the last 13 years of server crashes. In none of it it would be a good idea of something restarted automatically; Instead there has something to be done before the restart (!).

And if I wanted f.e. an Apache to restart automatically, I would simply check by a cronjob if it's running, and if not: start it. But really: Never ever I wanted that a init tool to be done for me. (Side note: Someone remembering just setting X up 20 years ago? That was fun reaching a terminal and getting a single char typed in while X always tried to restart…)

Also I wouldn't want any init system to decide "if daemon X starts, than we need daemon Y also" - won't be fun debugging something when trouble is around. Starting f.e. Apache and MySQL separate isn't that much work that it legals its price. If I would want two to be started in dependency I would write a 3 line shellscript which starts both and use that instead of getting a more complex init configuration.

…and my yesterdays adventure was getting to know who else can overwrite my resolv.conf on a systemd machine (and where its sources are spread over the system)… 99% you don't have to bother about this little file, but when automatic things fail you spent hours to fix it - instead of writing one simple line in a config file.

And yes, such things could be done configurable, so that it behaves as I want. But even then: The price is getting things much more complicated.

…so: In which cases would such a init thing be usefull? I've heard many times that this would be great to have, but I've never heard of an example or usecase with a real benefit.


----------



## Mjölnir (Jul 25, 2020)

kpedersen said:


> That is good. More deterministic behavior. Less bugs.  Servers don't shutdown and Laptops / workstations sleep. Fast "reboot" time is an old-fashioned concept. Even Windows doesn't shutdown by default these days.


Parallel service startup works reliable on other OS.  It's principle handling is known for decades.
Tell me one laptop where _hibernation_ works on FreeBSD.  I managed to get _suspend-to-disk_ to a special IRST partition (after a timeout fires in suspend mode); that's UEFI/BIOS not FreeBSD, a workaround, and one of very few exceptions.  The partition can't be used for anything else yet.  Plus it requires careful setup e.g. USB, modem, etc.  I can do it, a newbie/non-nerd, s/o who just wants to use a solid system build of and providing sound & proven modules & methods, can not (easily enough, e.g. here).  To make FreeBSD more user-friendly is a key to widen it's user base, which will result in more skilled developers after some years.  Currently, young IT people leaving university employ Linux for their 1st professional projects, because that is what their're used to.


> I would rather mistakes in plain-text scripts than binary Win32/systemd units. Either way, bugs happen in all approaches. BSD's are just easier to debug.


100% _d'accord_.


> This hack doesn't have a name yet because systemd is too young. I call it ".ini files are crap for handling services". Catchy huh?


I did not promote _systemd_.  Instead, I posted a link with the comment: _"a nice article on how not to do it"_


> These have different use-cases. For example Windows, macOS and systemd all target consumer desktop environments.


So why do you think FreeBSD should not be targeting desktop use-case?  Same argument as above: people like to use the same system they already know for any new use-case.  Are you one of those who's attitude is: _"It was hard to write, it should be hard to use"_?  I can't find any "_For Nerds Only"_-sign on any FreeBSD website. 



jmos said:


> …and my yesterdays adventure was getting to know who else can overwrite my resolv.conf on a systemd machine (and where its sources are spread over the system)… 99% you don't have to bother about this little file, but when automatic things fail you spent hours to fix it - instead of writing one simple line in a config file.


Again here too, I'm not promoting _systemd_.  Just because there's a very bad example doesn't mean others are equally bad, right?  I explicitely noted _runit & OpenRC_.

FreeBSD has resolvconf.conf(5) and it can easily bite you the same way.  In fact, it bites me because by default dhclient(8) does not seem to use resolvconf(8) (or there's a bug).


> And yes, such things could be done configurable, so that it behaves as I want. But even then: The price is getting things much more complicated.


That is to be verified.  I do not know if _runit & OpenRC_ are leightweight or blown up.


> …so: In which cases would such a init thing be usefull? I've heard many times that this would be great to have, but I've never heard of an example or usecase with a real benefit.


Desktop.  Despite I'm one of few who can hibernate, my setup of devices is not 100% perfect, thus I prefer to reboot.
Embedded devices.


----------



## zirias@ (Jul 25, 2020)

Again, all that's to be gained here is a quicker startup. If you really want this, it could probably be implemented without abandoning scripts. I don't see why it matters that much, I personally don't care to wait 30 secs _once_ before using my desktop. I would care a lot if I couldn't have init scripts any more. And I still didn't see a single argument, why "supervision" and automatic restarts of services should ever be part of an init system. It's questionable whether you want that _at all_, as already mentioned -- I personally never had a need. But if you want that, it makes much more sense completely separated from the system init.


----------



## Mjölnir (Jul 25, 2020)

There are numerous service monitoring & supervision tools in the ports tree, from small utilities to full-blown solutions for large-scale server plants.  So there seems to be a need for such functionality.  I do agree that automatic restart of a service is not reasonable in most cases, as there must have been a reason to be inspected why the service died.

So the two topics that I'm concerned about the most, are parallel startup & ease of use for newbies.


----------



## jmos (Jul 25, 2020)

Zirias said:


> Again, all that's to be gained here is a quicker startup.


That benefit was mostly gone since SSDs became standard. Today I get a old Debian 7 VM in 7 seconds till login, a Debian 10 VM in 5 seconds. So it is faster, but whether a boot takes 5 or 7 seconds isn't really interesting anymore.


----------



## bjs (Jul 25, 2020)

The BSD way, KISS, do ONE thing and do it well... If you want more than the standard init does, then install a program from ports... No need to make things more complicated in the base system!!! Just my two cents...


----------



## kpedersen (Jul 25, 2020)

mjollnir said:


> So why do you think FreeBSD should not be targeting desktop use-case?



Because then it makes it defective for any other use-case. As it stands FreeBSD is generic enough for everything. Desktop should never take priority above others so a desktop-centric init system would be an incorrect choice.



mjollnir said:


> Parallel service startup works reliable on other OS.  It's principle handling is known for decades.



No it doesn't. It is a mess on Linux. For example this classic bit of systemd when trying to shut down 


```
A stop job is running for Session c2 of user ... (1min 30s)
```

Because of the broken design of systemd, this bug where the user has to wait over a minute to shutdown their computer creeps up time and time again. Many distros even use the monolithic dhcpcd system to get around the fact that systemd-networkd is too fragile in bootup order.



mjollnir said:


> Tell me one laptop where _hibernation_ works on FreeBSD.



Thinkpad x61, HP z400, Thinkpad x230 are three that I use currently. They suspend fine. Why hibernate? If you are interested in speed, suspend is faster than hibernate on all platforms.



mjollnir said:


> Are you one of those who's attitude is: _"It was hard to write, it should be hard to use"_?  I can't find any "_For Nerds Only"_-sign on any FreeBSD website.


Why do you think waiting for worse init systems like systemd to boot up is easier? Surely you just sit there 

FreeBSD is a simple tool. Just like a hammer, it is impossible to make it more user-friendly without replacing it with something else entirely. If people want a "fun" experience and to play, they don't use a hammer and they use Microsoft Windows instead.


----------



## Mjölnir (Jul 26, 2020)

kpedersen said:


> Because then it makes it defective for any other use-case. As it stands FreeBSD is generic enough for everything. Desktop should never take priority above others so a desktop-centric init system would be an incorrect choice.


An init system like runit(8) or OpenRC does not make the OS desktop-centric.  E.g. for shure Solaris' SMF did not make it desktop-centric, right?  Instead, many of it's features were demanded by server use-case.  And before you come up with SMF's deficiencies: I'm not proposing this either.


> No it doesn't. It is a mess on Linux. For example this classic bit of systemd when trying to shut down


Again, you're refering to _systemd_, which I explicitely noted as defective...  Please do me a favour and stop using this as an example why my suggestion is invalid.  I am 100% _d'accord_ with you that we do not want this b*t on FreeBSD.
Please come up with arguments against _runit_ & _OpenRC_ instead.


> ```
> A stop job is running for Session c2 of user ... (1min 30s)
> ```
> Because of the broken design of systemd, [...]


[again, _systemd_...] I'm having the exactly same behaviour with the current init system: squid(8) takes ~ half a minute (? did not measure) to shut down, delaying every shutdown.


> Thinkpad x61, HP z400, Thinkpad x230 are three that I use currently. They suspend fine. Why hibernate? If you are interested in speed, suspend is faster than hibernate on all platforms.


Because for a mobile system, power consumption counts.  Suspend still uses power, while hibernation uses nearly zero (only the ME runs).  Beside that, I still did not measure startup times from hibernation vs. power-off.  Resuming from disk might even be slower than normal (even non-parallel) startup, because it blindly reads the whole hibernation partition instead of only the size of RAM _in-use._  Plus, as noted above, resuming correctly requires careful setup, which can be hard even for experienced users, and s/t it's impossible to do right because of bad devices.  A "clean" startup is usually much safer.


> FreeBSD is a simple tool. Just like a hammer, it is impossible to make it more user-friendly without replacing it with something else entirely. If people want a "fun" experience and to play, they don't use a hammer and they use Microsoft Windows instead.


I doubt the 1st & 2nd sentence ("replace entirely").  FreeBSD is a good base for desktop & server.  I know many ordinary, non-nerd people who switched from Windows to Linux for various reasons.  If they see FreeBSD starting up, they call it _computer-stone age_. It's much easier to write a user-friendly input mask for some configuration values than fishing those values from scripts.  IMHO if an alternative init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it.


----------



## zirias@ (Jul 26, 2020)

mjollnir said:


> IMHO if an alternative init system is done right, it would neither hurt nor restrict you,


Well, it would restrict _me_ if it doesn't allow init-scripts any more. Therefore, I'm fundamentally opposed against such ideas. It would definitely add complexity in any case, and that's something I'm at least very sceptical about.


----------



## mark_j (Jul 26, 2020)

Zirias said:


> [...]
> 
> The only thing FreeBSD's init system can't do at the moment that _might_ make some sense to me is parallelization. Of course, this would just gain faster startup times. If I have the choice between shell scripts and faster startup, I choose the scripts. Sure, would be nice to have both.



Meh, parallel startup? I'm not attacking your 'nice to have' opinion but it's overrated. In linux it might make sense with hundreds of processes at startup, it's really only ever going to add complexity & huge chance of race conditions


----------



## zirias@ (Jul 26, 2020)

mark_j said:


> Meh, parallel startup? I'm not attacking your 'nice to have' opinion but it's overrated.


JFTR, I didn't say I want or need that  Only thing I was saying is that this is the only thing I could think of which *might* be improved in an init-system.


----------



## mark_j (Jul 26, 2020)

mjollnir said:


> [...]
> IMHO if an alternative init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it.



With respect that's phooey.
Your average user & even most kernel developers don't even touch their init system. On NetBSD we've had this same argument and it's (always) under misapprehension. If any one is impacted it's the porters, & believe me they don''t want to supports n-amount init systems.

Ibm/linux pushed this because there's hundreds of distributions that have disparate init systems that require greater work by distro developers and packagers; systemd init was born (and an ugly bastard it is!).

Contrarily, bsd has no such issue, thus rendering your argument moot.


----------



## mark_j (Jul 26, 2020)

Zirias said:


> JFTR, I didn't say I want or need that  Only thing I was saying is that this is the only thing I could think of which *might* be improved in an init-system.


Yes I understand that.


----------



## Mjölnir (Jul 26, 2020)

mark_j said:


> Your average user & even most kernel developers don't even touch their init system. On NetBSD we've had this same argument and it's (always) under misapprehension. If any one is impacted it's the porters, & believe me they don''t want to supports n-amount init systems.


By _n-amount_ do you mean parallel startup or disparate init systems?  The latter would not happen since there's one FreeBSD.  At least one FBSD-based distribution (TrueOS) used _OpenRC_ IIRC, but TrueOS is history now.


> Ibm/linux pushed this because there's hundreds of distributions that have disparate init systems that require greater work by distro developers and packagers; systemd init was born (and an ugly bastard it is!).


See above: I'm not promoting _systemd_...  In contrast, my concern is: it's reasonable to evalute _runit_ vs. _OpenRC_ as a replacement for the current _BSD init_, like e.g. is done here for Linux.  Both allow for parallel services start, and they might be easier to manage for newbies (that's to be evaluated).  Additionally, they supply service monitoring/supervision, which seems to be a demand of professional server plants.  _It should easily be possible to switch off parallel startup, I you want that_.  Likewise, it should be possible to not monitor a service.  Both are reported to be fairly slim & KISS.  Thus, you'll loose _nothing_, while others could benefit.


> Contrarily, bsd has no such issue, thus rendering your argument moot.


It does not, because the current _BSD init_ does not have a feature that is demanded by many desktop users: parallel service startup.  The only arguments against this so far were 1. added complexity, which I doubt; at least the added complexity will not be overly much IMHO; and 2. race conditions, i.o.w.: in most cases, it works well.  There are race conditions in _any_ system beyond a certain complexity, e.g. currently my wpa_supplicant(8) does not start automagically, but it does start w/o errors & warnings manually.  If I want parallel startup, I would probably run into many issues right now.  If it comes by default, I'd be happy.

Again: please stop complaining about _systemd_ and using it's deficencies as contra argument.  We are 100% d'accord that this mess is broken by design.  Come up with arguments against _runit_ (sysutils/runit) and/or _OpenRC_ instead.


----------



## zirias@ (Jul 26, 2020)

Well, OpenRC seems to work fine with a BSD init and still use init scripts, so this might be acceptable (while a solution trying to replace scripts with configuration files will never be acceptable to me). Still, why change something that isn't broken? So OpenRC can do parallel startups? Really, I don't need that. Everything I need is already present with mewburn rc and works reliably and proven for many years.


----------



## hruodr (Jul 26, 2020)

kpedersen said:


> FreeBSD is a simple tool. Just like a hammer, it is impossible to make it without replacing it with something else entirely. If people want a "fun" experience and to play, they don't use a hammer and they use Microsoft Windows instead.



Some people insist on making an operating system "user friendly". They care a lot on "less skilled users". Every operating system is getting such an operating system, and there is always fewer "simple tools" as you call FreeBSD. What will be at the end the alternative for the "more skilled users"?

I consider myself not a skilled user, that is why I have great problems with operating systems for less skilled users: you can use them, but when there are troubles, you cannot do anything, because they are too complicated, difficult to understand and to deal with, and troubles come always, because they are complicated.

If I wanted a OS for "less skilled users", I would use Ubuntu or Windows instead of FreeBSD and OpenBSD. I do not criticise Ubuntu or Windows, they have they user basis, they have a function, but please, do not take me my OS away!


----------



## Mjölnir (Jul 26, 2020)

mark_j said:


> Meh, parallel startup? [...], it's really only ever going to add complexity & huge chance of race conditions


All (?) the information needed for parallel startup is already present in the _dependency hacks_ in the service scripts.  Thus, it would very likely add very little complexity, maybe even none at all.


hruodr said:


> [...], but please, do not take me my OS away!


There's a good chance that both runit & OpenRC are KISS enough that you won't have to worry about this.  In fact, IMHO FreeBSD is MUCH simpler than Windows & Ubuntu, if you're a little bit curious & courageous.


----------



## Mjölnir (Jul 26, 2020)

Zirias said:


> This wording (configuration) brings me to the next criticism: shell scripts. With mewburn rc, there's a large and useful library, so your init script for a "normal" service needs only a few lines. Dependencies also work rock solid. Still, with these scripts, I can do _anything_ unforeseen by the designers of the init system. I personally wouldn't ever want to use a system that replaces scripts by some "configuration".


If the contents of the configuration is _"use the default script"_, that would satisfy both, yours & my concerns, right?


----------



## hruodr (Jul 26, 2020)

mjollnir said:


> There's a good chance that both runit & OpenRC are KISS enough



They are not an alternative for me, because they introduce parallelisation.


----------



## kpedersen (Jul 26, 2020)

mjollnir said:


> I know many ordinary, non-nerd people who switched from Windows to Linux for various reasons.  If they see FreeBSD starting up, they call it _computer-stone age_.



True but these same people say that C is "old" compared to Java and have been for years. They would be wrong. Tools such as FreeBSD (and hammers) don't need pretty startup screens.

Non-nerd people honestly don't need real computers anymore. They need a telephone or a games console. It is impossible to cater for them without replacing FreeBSD with a different project entirely.

I would even consider myself a "non-nerd" user. I am not an OS developer. Heck, I am a slow tech learner which is probably why I think Linux is defective. I just use FreeBSD to provide a platform to develop software and teach on. Windows and Linux have so much breakage daily that they no longer provide a solution to my needs. How is that user-friendly?



mjollnir said:


> Please come up with arguments against _runit_ & _OpenRC_ instead.



The sad truth is that these haven't seen much uptake because they don't offer more than systemd or existing standard init systems. There are a number of arguments why they are not popular, just do a search for the "systemd vs openrc" threads. In terms of FreeBSD they do not offer enough to justify the breakage they would cause.


----------



## Mjölnir (Jul 26, 2020)

hruodr said:


> They are not an alternative for me, because they introduce parallelisation.


In OpenRC it is switched off by default.  In runit it should be easily possible to switch it off; it's the same like with make(1): you _can_ have parallel jobs, optionally. All parallel execution can easily be serialized.


----------



## zirias@ (Jul 26, 2020)

mjollnir said:


> If the contents of the configuration is _"use the default script"_, that would satisfy both, yours & my concerns, right?


This might be the case indeed, but I'm still not convinced such a central part of the base system needs any change at all. Mewburn rc has (IMHO) a very elegant design and I personally don't miss anything. Changes are never free of risk (and FreeBSD tends to be much more aware of that than Linux), so to change something, you need good reasons. I see we just disagree about these "good reasons"


----------



## hotaronohanako (Jul 26, 2020)

kpedersen said:


> The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives



you are just angry dude!  so this just a meaningless quote !


----------



## kpedersen (Jul 26, 2020)

All the above said, It would be great to see nosh (and all other init systems) in ports for those that really do have a use-case that can benefit from their features.

I expect zoujiaqing  has a lot of work ahead of him


----------



## Mjölnir (Jul 26, 2020)

kpedersen said:


> Non-nerd people honestly don't need real computers anymore. They need a telephone or a games console. It is impossible to cater for them without replacing FreeBSD with a different project entirely.


They can decide for themselves... Ordinary people want a desktop computer system to write e-mail, chat, browse the internet, etc.pp.  Note the act of writing.  Other devices like tablets & smartphones, smart TV & game consoles do not have a keyboard and/or the display is too small.  That's two of the reasons why laptops and mini computer desktop systems are still very popular.  My assumption/assertion are:

adding parallel service startup will not hurt you, but add benefit for desktop users
adding _optional_ service supervision & monitoring will not hurt you, - " - for server use-case
It will not fundamentally change FreeBSD
I do not want to replace FreeBSD.  I propose to enhance it.


> I would even consider myself a "non-nerd" user. I am not an OS developer. Heck, I am a slow tech learner which is probably why I think Linux is defective. I just use FreeBSD to provide a platform to develop software and teach on. Windows and Linux have so much breakage daily that they no longer provide a solution to my needs. How is that user-friendly?


Your implication that I want FreeBSD to become like Windows or Linux is not right.


> The sad truth is that these haven't seen much uptake because they don't offer more than systemd or existing standard init systems. There are a number of arguments why they are not popular, just do a search for the "systemd vs openrc" threads. In terms of FreeBSD they do not offer enough to justify the breakage they would cause.


OK now I will suspend with automagic hibernation after 15 minutes, then reboot, and measure the times to startup the base system, and until the X11 login screen.  I have to set up another boot env anyways, I'll try to replace it's init with runit(8).  Anyone who's curious and open-minded to check such tool unbiased, can decide to do so as well.


kpedersen said:


> I expect zoujiaqing  has a lot of work ahead of him


That's why I came up with my suggestion.  Iff - and only if - such replacement does not break reliable & proven BSD policies, this work would be done once in the _base_ for those who want it, and not hurt you & the others.


----------



## Alain De Vos (Jul 26, 2020)

I like runit. But paralising init system will not speed up boot times, when hardware detection, e.g. USB, is the issue. Or an ntpdate which takes a few seconds.
I ask myself can you combine runit/daemontools/rc ?


----------



## Mjölnir (Jul 26, 2020)

Alain De Vos said:


> I like runit. But paralising init system will not speed up boot times, when hardware detection, e.g. USB, is the issue. Or an ntpdate which takes a few seconds.


At least ntpdate(8) can run in the background while other services are started.


----------



## hruodr (Jul 26, 2020)

mjollnir said:


> They can decide for themselves... Ordinary people want a desktop computer system to write e-mail, chat, browse the internet, etc.pp. Note the act of writing.



If for these "ordinary people" FreeBSD is not good for that purposes, if they are unhappy with FreeBSD, then they should use Windows or Ubuntu that are made for them and are perfect
for their act of writing.

What about ordinary people that want stay conscious of what the system does and eventually
alter it? That want to write and run small programs, for example for technical, scientific,
commercial or other purposes? People that see in a classical computer a computer and not an
application box?

Why are you zealously defining "ordinary people", insistingly speaking in their name, and ignoring
the existence and needs of other "ordinary people"?

As I wrote in other thread, OpenBSD is more coherent. Its rc is in my opinion much
simpler as also the whole system. If you were in the OpenBSD mailing list, you would get 
the answer you deserve.


----------



## Mjölnir (Jul 26, 2020)

hruodr said:


> If for these "ordinary people" FreeBSD is not good for that purposes, if they are unhappy with FreeBSD, then they should use Windows or Ubuntu that are made for them and are perfect
> for their act of writing.


I already answered this above.  Because if FreeBSD was more widely deployed & known as a stable, reliable (in our opinion: superior) alternative to Windows & Linux, this would result in more developers & maintainers after a few years.


> What about ordinary people that want stay conscious of what the system does and eventually
> alter it? That want to write and run small programs, for example for technical, scientific,
> commercial or other purposes? People that see in a classical computer a computer and not an
> application box?


I do care as well.  I am one of these.


> Why are you zealously defining "ordinary people", insistingly speaking in their name, and ignoring
> the existence and needs of other "ordinary people"?


Why are you suspecting (accusing) me that I want to _"take away my OS"_? Please let's stay unemotional, factually. Provide me an argument why parallel service startup (off by default) would take away any of the beloved simplicity & rubustness of FreeBSD.


----------



## hruodr (Jul 26, 2020)

mjollnir said:


> rovide me an argument why parallel service startup (off by default) would take away any of the beloved simplicity & rubustness of FreeBSD.



Many people told it: non deterministic behaviour, chance of race conditions, complexity, no need
to make startup faster and not at this price, system startup is a critical moment and should be
kept as simple as possible.



mjollnir said:


> Because if FreeBSD was more widely deployed & known as a stable, reliable (in our opinion: superior) alternative to Windows & Linux, this would result in more developers & maintainers after a few years.



That is a very primitive, one dimensional way of thinking: more deployed and known, then 
superior, then more mantainers and developers. The more, the better. For people that think
that way there are more intelligent, and hence better operating systems that think for 
them: for example Windows and Ubuntu.


----------



## kpedersen (Jul 26, 2020)

mjollnir said:


> Why are you suspecting (accusing) me that I want to _"take away my OS"_?



I guess it is more the worry of feature creep. As in once we have parallel jobs (off by default), what happens if someone decides to make it on by default and breaks some niche legacy software you need to run?

But you are correct, improving it doesn't need to break anything. I.e if it was first implemented as a drop in replacement with many compatibility modes so that none of the existing subsystems or ports break and then slowly update them one by one to the new (i.e parallel) functionality until none of the legacy stuff remains.

This is the only responsible way to replace large systems. Something that often gets overlooked in Linux in the name of "blind" progress. But this blind progress is so annoyingly damaging when it does occur. Us FreeBSD guys like to stay out of all that when possible.


----------



## Mjölnir (Jul 26, 2020)

I ran away from Linux & Solaris to FreeBSD for exactly these reasons.


hruodr said:


> Many people told it: non deterministic behaviour, chance of race conditions, complexity, no need
> to make startup faster and not at this price, system startup is a critical moment and should be
> kept as simple as possible.



non-deterministic behaviour is no problem if the dependencies are correct
race conditions do appear in the current system as well; parallel/serial execution can be switched easily
dependencies are already encoded in the _dependency hacks_, thus complexity will very likely not expand too much
many desktop users are asking for parallel service startup
the two existing systems I mentioned are reported to be fairly KISS



> That is a very primitive, one dimensional way of thinking: more deployed and known, then
> superior, then more mantainers and developers. The more, the better. For people that think
> that way there are more intelligent, and hence better operating systems that think for
> them: for example Windows and Ubuntu.


You are going emotional?


----------



## hruodr (Jul 26, 2020)

Why to expand complexity if it could also be reduced? And for you is non-deterministic behaviour
not a problem, for others is even that execution time cannot be determined a big problem. But 
let us take technical considerations away for a while:



mjollnir said:


> many desktop users are asking for parallel service startup



How many desktop users you mean? From where you know them? Do they asked you for that?
And what services do these desktop users start at boot time? Or they asked for a feature without
knowing for what they need the feature?


----------



## Mjölnir (Jul 26, 2020)

hruodr said:


> How many desktop users you mean? From where you know them? Do they asked you for that?
> And what services do these desktop users start at boot time? Or they asked for a feature without
> knowing for what they need the feature?


Naturally, the number of whom I personally know is much lower of those I pretend to speak for.  Friends & family.  Collegues.  Myself.   People I do not really know well, but I see them using a Linux desktop.  Observations on various forums.  Yes, they do ask when I suggest FreeBSD as a superior alternative to Linux to them; either they want to move away from Windows or Mac to Linux, or they are not satisfied with their current Linux distro.  Then two issues come up over and over again:

suspend & resume: this has greatly improved on FreeBSD and modern hardware became more conformal to standards
parallel service startup, i.e. time from power-on to GUI login screen; even with a SSD, FreeBSD is factors slower than it could be; Linux is much faster
Most of them start XfCE, Gnome, or KDE desktop environment with no bells & whistles.


----------



## hruodr (Jul 26, 2020)

Do you know, *mjollnir*, I do not believe you one word. And if I have to believe what you say, then you should be happier using Windows or Linux.


----------



## Jose (Jul 26, 2020)

mjollnir said:


> vulnerable to mistakes in the service scripts; these are very common as it's shell script syntax, and often they are subtle errors (notably, the depency handling is commonly called _dependency hack_)


Please. I would much rather deal with crappy POSIX sh(1) syntax than with the systemd unit file nightmare. Quick quiz, what's the difference between `Requires`, `Requisite`, and `After`?



mjollnir said:


> ...
> Please come up with arguments against _runit_ & _OpenRC_ instead.
> ...


_Hard_ pass on Openrc. It's one of the reasons why I'm a Gentoo refugee. The current maintainer is a systemd fanboi and keeps introducing "improvements" to make it more like his preferred init system. Look into the tmpfiles fiasco if you want to see awe-inspiringly over-engineered crapware. I wound up maintaining my own ebuild of an old version of Openrc to work around the current maintainer.

I gotta admit that the Void Linux (uses runit) startup is insanely fast. I think there's a use case there for embedded systems, but I disagree with the whole premise that faster boot times are some kind of killer desktop feature. There are far bigger fish to fry first before that becomes a pressing issue for Freebsd.



mjollnir said:


> In OpenRC it is switched off by default.


Did you ever wonder why this is the default? Because parallel initialization introduced too many problems that were hard to debug.


----------



## Jose (Jul 26, 2020)

mjollnir said:


> At least ntpdate(8) can run in the background while other services are started.


And all services are robust to the system clock going backwards, of course.


----------



## Alain De Vos (Jul 26, 2020)

A rather general question. Take for instance the dbus port or the sndiod port.
Do these ports work out of the box correctly with runit or deamontools-encore ?
Or does the maintainer need to patch the ports ?
How do I know which ports work and which one don't work out of the box with runit or deamontools-encore ?


----------



## mark_j (Jul 26, 2020)

Jose said:


> And all services are robust to the system clock going backwards, of course.


Years ago on Solaris when they first introduced their current init management, one of my admin guys on a test server went mad with svccfg and auto restart of services. Solaris had a buggy ntpd service that kept crashing because of a mangled config, and it spewed so much information out into the logs it locked the system up; disk full. Lesson learned.


----------



## mark_j (Jul 27, 2020)

mjollnir said:


> By _n-amount_ do you mean parallel startup or disparate init systems?  The latter would not happen since there's one FreeBSD.  At least one FBSD-based distribution (TrueOS) used _OpenRC_ IIRC, but TrueOS is history now.


GhostBSD uses OpenRC.

Your point was "if an *alternative *init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it ", to which I replied as I did. My reply was the history behind GNU/Linux changing their init system was because of diversity of systems, maintainability and the NIH syndrome they suffer from.




mjollnir said:


> See above: I'm not promoting _systemd_...  In contrast, my concern is: it's reasonable to evalute _runit_ vs. _OpenRC_ as a *replacement *for the



Ok, so there's a language issue here. There's *alternative*, proposing FreeBSD have more than one choice for an init system or *replacement*, proposing FreeBSD has a new init system.

This is obviously where the confusion comes in. Ok, so replacement it is.



mjollnir said:


> current _BSD init_, like e.g. is done here for Linux.  Both allow for parallel services start, and they might be easier to manage for newbies (that's to be evaluated).  Additionally, they supply service monitoring/supervision, which seems to be a demand of professional server plants.  _It should easily be possible to switch off parallel startup, I you want that_.  Likewise, it should be possible to not monitor a service.  Both are reported to be fairly slim & KISS.  Thus, you'll loose _nothing_, while others could benefit.


As I wrote in another message, I have anecdotes galore of the failure of service monitoring OSs like Solaris's. Only a lazy administrator would trust them. If, for example, postgres crashes, we DO NOT want it to restart and possibly hide the issue.
Now, for sure, there's probably a service that can be restarted automatically, however, that's not a new phenomena, and shell scripts monitoring services have been around since the first UNIX rolled out.



mjollnir said:


> It does not, because the current _BSD init_ does not have a feature that is demanded by many desktop users: parallel service startup.  The only arguments against this so far were 1. added complexity, which I doubt; at least the added complexity will not be overly much IMHO; and 2. race conditions, i.o.w.: in most cases, it works well.  There are race conditions in _any_ system beyond a certain complexity, e.g. currently my wpa_supplicant(8) does not start automagically, but it does start w/o errors & warnings manually.  If I want parallel startup, I would probably run into many issues right now.  If it comes by default, I'd be happy.



There's a lot of supposition in there.

First, let's address you major issue: parallelism.

What makes you think this is something demanded of desktop users? Was it not you who said FreeBSD does not hibernate, so, by implication, it must be shut down and started up again, rendering an init system that has parallelisation, a must?
My reply is to fix the problem of non-hibernation, not adjust the init system to fix this one use-case. Should it be fixed? Yes, of course.
Is there a workaround?


Second, the issues of another, replacement init system:

1. Legacy change of all ports to the new init system, where those ports use daemons.
2. Scope creep. As changes to the init system require parallel processes to run, these need to be "aware" of other processes and interact accordingly. If we take systemd as a model (eek!) then the use of sockets for parallel start ups means a significant change to ALL daemons.
3. Parallelizations cause race conditions. Race conditions are bad, more so in a program that between programs. Mitigating them takes work. It's not a real problem with separate processes of course, compared to one process, but it's nonetheless a potential issue. In the case of an init it requires a strict adherence to rules about what can run before/after/required/desired etc.
In the case of something like runit, I tinkered around with this a while back on (ahem) NetBSD. It's parallel, sort of. It just starts as many as possible and keeps retrying until they stick. Not what I call a great system. 





mjollnir said:


> Again: please stop complaining about _systemd_ and using it's deficencies as contra argument.  We are 100% d'accord that this mess is broken by design.  Come up with arguments against _runit_ (sysutils/runit) and/or _OpenRC_ instead.



Why? It's pertinent because the fast startup that systemd apparently gives you was driven by the points you raised. It's extrememly germane because to have a "proper" parallel start up init service you need something like systemd's init or launchd or even svc.


Yes, it is possible to employ an alternative init system for FreeBSD, but then you will lose compatibility with (almost 100%) NetBSD and to a lesser degree OpenBSD. I think that should be a consideration as well. (At the risk of mentioning systemd again, this is the contrarian view held by systemd - ignore compatibility, we're going it alone).


----------



## unitrunker (Jul 27, 2020)

I like rcorder because it is easy to understand and write RC scripts that can be run in the correct order.

When things break, sequential logs are easier to read.

It would be a great experiment to augment rcorder to support a thin layer of parallelism. This could be done without disrupting existing RC scripts.


----------



## Deleted member 63539 (Jul 27, 2020)

Hi. Desktop user here. Some of you assumed desktop users must have a bunch of services to start on startup. It's not true. I only have dbus enabled.

If you want to improve the startup time of FreeBSD, I think it's wrong to look into the init system. With my own observation, the major slowness come from DHCP. It's the slowest part. I have to wait to my link state up, then down, then it's up again, and the output of `ifconfig` printed to be able get into actual start of the services. The startup of these services is pretty fast, though. So I have no complains about it.

I used both Linux (Sparky) and FreeBSD, I would say FreeBSD startup time is only 2x slower than Linux. I don't know where you got your value from. But from my experience I found FreeBSD startup time to not that slower to Linux. Sparky is a rolling release system, it always uses the latest and greatest systemd.

I used GhostBSD before go with vanilla FreeBSD. As I know that time they already switched to OpenRC. I would say the startup is a bit faster indeed but the shutdown time of it is much worse than vanilla FreeBSD. Sometimes the shutdown stuck for no reasons. I have to use the reset button to get out of it. My conclusion is OpenRC is not that stable as the vanilla FreeBSD's RC. The vanilla RC has never got me stuck at shutdown. You could say it's because OpenRC is not matured enough, though.


----------



## aragats (Jul 27, 2020)

mjollnir said:


> suspend & resume
> parallel service startup


Aren't they kind of mutually exclusive in the context of the discussion? If suspend/resume is perfectly working why should I worry about start-up time? Besides several servers, I use FreeBSD in a laptop and a desktop with GUI for everyday activities. Suspend works fine in my ThinkPad, and I never shut it down.
Another aspect is the servers. In other forums' threads there were discussions (with real-life arguments) on the need of quick start-up as a really essential thing for many servers when down time is very critical.


----------



## Mjölnir (Jul 27, 2020)

I appreciate all of your pertinent and factual responses.  In contrast, hruodr, obviously I can only guess about your level of emotional involvement, so I can only kindly ask you to check that for yourself.  If you think I do lie to you intentionally, well, here's the truth: I work for the chinese government & they hired me to have an eye especially on you...  Our ultimate goal is to obfuscate all BSDs & their users.  Alternatively, you can review my threads & posts and reflect your decision.  You'll find both useful & not-so-useful ones, please pick only my bad quick-shots and report them on the forum's blacklist.


mark_j said:


> As I wrote in another message, I have anecdotes galore of the failure of service monitoring OSs like Solaris's. Only a lazy administrator would trust them. If, for example, postgres crashes, we DO NOT want it to restart and possibly hide the issue.  Now, for sure, there's probably a service that can be restarted automatically, however, that's not a new phenomena, and shell scripts monitoring services have been around since the first UNIX rolled out.


I had similar experience on Solaris, too.  For one there's the principle issue that service supervision is a very hairy topic, and 2nd SMF was very new & premature then.  Don't know the current state of such issues, though.
Nevertheless, there seems to be a demand.  I'm not focusing it, we are 100% _d'accord_ that in many cases it's a bad idea to blindly restart a service that died, for there must have been a reason that needs to be fixed 1st.  _Minix 3_ aims to be _self-healing_, and they have a long way to go.


> What makes you think this is something demanded of desktop users? Was it not you who said FreeBSD does not hibernate, so, by implication, it must be shut down and started up again, rendering an init system that has parallelisation, a must?  My reply is to fix the problem of non-hibernation, not adjust the init system to fix this one use-case. Should it be fixed? Yes, of course.  Is there a workaround?


Yes, I hibernate to a special IRST partition.  But as I stated already, to correctly resume requires careful setup, and some devices have issues e.g. they do not 100% conform to standards.  2nd issue: the environment changes between standby & resume, e.g. network.  Tools exist to handle this via _profiles_.  Unless you have sufficient time & experience to correctly configure your system & "good" hardware, it's much safer to reboot than to suspend/resume.  The issue is not parallel startup itself, but startup speed.  Many answer to this: "I'm not concerned about", which is perfectly ok, but the unspoken implication to deny such demand of others, is not.


> Second, the issues of another, replacement init system: [...many issues...]


Shure.  I did not propose to do such a change at the same hastiness this (and other vital changes) has been done on some Linux distributions.  As kpedersen pointed out, such change would require careful thinking and slowly dripple down from -CURRENT.  After all, that's why I started this discussion: to collect pro & contra.  I found some of it already happened here.


> Why? It's pertinent because the fast startup that systemd apparently gives you was driven by the points you raised. It's extrememly germane because to have a "proper" parallel start up init service you need something like systemd's init or launchd or even svc.


Let's wait for a report on _runit_.  I asked s/o who actually has some experience with it.  Again, I explicitely did not suggest to switch to one of these, instead I noted all of these as defective (excl. _launchd & upstart,_ which is in history's trash bin).


> Yes, it is possible to employ an alternative init system for FreeBSD, but then you will lose compatibility with (almost 100%) NetBSD and to a lesser degree OpenBSD. I think that should be a consideration as well. [...]


This is a reasonable argument.


gh_origin said:


> [...] If you want to improve the startup time of FreeBSD, I think it's wrong to look into the init system. With my own observation, the major slowness come from DHCP. It's the slowest part. [...]


If `sysrc -v background_dhclient` tells NO, try `sysrc background_dhclient=YES`


> I used both Linux (Sparky) and FreeBSD, I would say FreeBSD startup time is only 2x slower than Linux. [...]


That's a _factor_ and often expressed as such, instead of "100% slower" or "50% faster".  some would even call that a _magnitude_.


aragats said:


> Aren't they kind of mutually exclusive in the context of the discussion? If suspend/resume is perfectly working why should I worry about start-up time? Besides several servers, I use FreeBSD in a laptop and a desktop with GUI for everyday activities. Suspend works fine in my ThinkPad, and I never shut it down.
> Another aspect is the servers. In other forums' threads there were discussions (with real-life arguments) on the need of quick start-up as a really essential thing for many servers when down time is very critical.


I see no reason why these should be mutually exclusive.  We have ThinkPads, which are known to be very conformant to FreeBSD.  Many other brands do not behave that well on FreeBSD.  Of course, many vendors have improved in this regard in the last few years.  Still there is old and/or non-conformal hardware in use, and Linux comes with more _quirks_ to support them.  Which amplifies my argument that a wider user-base is advantageous.  The developers simply would gain access to more system's data & hardware to test on.


----------



## Deleted member 63539 (Jul 27, 2020)

mjollnir `sysrc background_dhclient=YES` has no effect. The startup time is pretty much the same regardless of this setting is on or off.


----------



## Mjölnir (Jul 27, 2020)

gh_origin said:


> mjollnir `sysrc background_dhclient=YES` has no effect. The startup time is pretty much the same regardless of this setting is on or off.


There are some other sysrc(8) variables you can set, e.g. _defaultroute_delay_ & _defaultroute_carrier_delay._  Have a look into /etc/defaults/rc.conf if it's important enough to you.  Of course do not change them there, but via `sysrc xyz=10`.


----------



## ralphbsz (Jul 28, 2020)

This is a very interesting thread. The OP asked a question: How to do X. Within a few hours, there was an answer (from gpb), explaining that its not so easy, but how to do it.

Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.

Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions? Or have done another interestingly complex task that involves other init systems compared to FreeBSD (and not just set up a system).


----------



## unitrunker (Jul 28, 2020)

I looked at nosh not long ago.









						Nosh anyone?
					

Is anyone using nosh as their init system?  https://jdebp.eu/Softwares/nosh/index.html  If so, how and why?




					forums.freebsd.org
				




I tried to verify nosh claims that the service command was hopelessly broken.









						C - Sample daemon in C
					

The handbook has so much good information. After a few minutes of reading, I understood enough to create a bare bones do-nothing daemon. Enough to install it and either start / stop it using the service command and a ridiculously short rc.d script.  First, the rc.d script that goes under...




					forums.freebsd.org
				




It seems the original complaints were fixed. I could not reproduce them. There's always room for improvement but the sky isn't falling for RC


----------



## mark_j (Jul 28, 2020)

ralphbsz said:


> This is a very interesting thread. The OP asked a question: How to do X. Within a few hours, there was an answer (from gpb), explaining that its not so easy, but how to do it.
> 
> Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.
> 
> Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions? Or have done another interestingly complex task that involves other init systems compared to FreeBSD (and not just set up a system).


Well as I qualify for this, then I apparently meet your demands for posting to this thread.

Thanks for allowing me to participate.


----------



## zirias@ (Jul 28, 2020)

ralphbsz said:


> Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.


So, you think my arguments are not technical? I think I made it perfectly clear what I expect from an init system and that I'm not against change in general, but just want to see good (technical) reasons for it, especially when touching such a central component.



ralphbsz said:


> If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions?


Having done exactly that not too long ago (here's the source, I didn't even attempt to add any "init integration" to the repository, but it runs for me between a FreeBSD and a Linux machine), do you still think I'm not qualified to an opinion here?


----------



## zirias@ (Jul 28, 2020)

unitrunker said:


> I tried to verify nosh claims that the service command was hopelessly broken. [...]
> It seems the original complaints were fixed.


Well, there are a few things you can't "fix" without some sort of "service manager", like e.g. inherited file descriptors. The workaround you see from time to time (a service closing all file descriptors from 3 to 1024 on startup) is of course badly flawed and should be avoided.

But then, the usecase of `service` always was to control services from a "normal" root shell. Such a shell is not expected to carry / pass on any opened file descriptors except for the stdio streams. The example given (launching a service from a script executed by a web-server in response to a request) seems pretty strange to me, it's definitely a mis-use of `service`.

Therefore, sure, there is sometimes a need for some "service management" with more features than traditional init. I'm just saying this can be implemented without ever touching init itself. My argument that it shouldn't go in init is: Most of the time, you won't need it, so init should stay as simple as possible.

IMHO, a well-behaved *nix daemon nowadays needs two modes of operation: One (arguably the default) mode where it "self-daemonizes" on startup, and sets up some logging, e.g. to a file or using syslog(3). This is the mode for manually launching the service from a root shell with `service`, or from RC scripts called by /etc/rc. And then, a second mode bypassing all that and just using the stdio streams for logging, which is the mode for using the service with some "service manager".


----------



## hruodr (Jul 28, 2020)

ralphbsz said:


> Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions?



But the lots of desktop users mjollnir speaks for and not even use FreeBSD also have 
strong opinions about FreeBSD init system and want other one. Did they all create a 
service from scratch?!


----------



## unitrunker (Jul 28, 2020)

Zirias said:


> Well, there are a few things you can't "fix" without some sort of "service manager", like e.g. inherited file descriptors. The workaround you see from time to time (a service closing all file descriptors from 3 to 1024 on startup) is of course badly flawed and should be avoided.


I think the flaw is in fork-and-then-exec. I did not see this with a call to daemon(3). The service manager idea is a bit scary. What happens to the child services when the service manager dies?



> The example given (launching a service from a script executed by a web-server in response to a request) seems pretty strange to me, it's definitely a mis-use of service.


If you run something like salt this is not so strange though the specific implementation above sounds buggy.


----------



## zirias@ (Jul 28, 2020)

unitrunker said:


> I think the flaw is in fork-and-then-exec. I did not see this with a call to daemon(3).


No, the "flaw" is fork(2), as all open file descriptors are inherited in the child process. Of course, that's not really a flaw cause many usecases (e.g. pipes) will need exactly this behavior of fork(2). As a side-note: daemon(3) is just a convenience function you probably shouldn't use in portable code; doing the correct steps of fork, setsid, chdir, etc manually will have the same effect. What you would need after fork is something like "close all fds > 2", which doesn't exist. But then, again, the assumption is to start services from a shell that doesn't have any open file descriptors.
With an exec after fork, there's less of a problem if the parent correctly uses the `FD_CLOEXEC` flag, so an automatic close happens on exec. In fact, *if* a shell has open file descriptors for its internal use, it should use exactly that flag, so these descriptors are gone before the started service even tries to "daemonize". The same is probably true for a webserver launching some external process...



unitrunker said:


> The service manager idea is a bit scary. What happens to the child services when the service manager dies?


Well, the same that happens to all processes when init dies, of course. This is also an often cited reason to not add too much complexity to init. Still, if you need more features, you can run a service manager offering them -- and of course, you have to trust its quality as the stability of all services managed by it directly depends on the stability of the manager itself.


----------



## unitrunker (Jul 28, 2020)

I'd prefer a new function where the caller explicitly specifies ...

uid
gid
env
list of file descriptors

... to pass on to the child process. No, that's not POSIX but I'm not aiming for compatibility. If proven successful, the rest of the world would mimic it.


----------



## zirias@ (Jul 28, 2020)

Zirias said:


> Well, the same that happens to all processes when init dies, of course.


I have to add that this is simplified and not really correct, my bad... If a service manager is run separately (not as the init process), what would happen is that init would inherit all its child processes in case it dies. So, in theory, those processes could keep working. But as a service that doesn't daemonize typically uses the stdio streams and the service manager would handle the logging, there would be broken pipes in practice and the result would be that these processes die as well.


----------



## Mjölnir (Jul 28, 2020)

It might be useful to clarify some topics.  runit(8)'s /sbin/init is _very_ simple.  Man page: runit-init(8).  Service supervision is not done by it's /sbin/init itself, but delegated to one of it's companions.  There's a recipe how to replace the standard init system.  Quote:_ "[...] The migration can be done smoothly. By default runit runs the /etc/rc scripts in stage 1 as a one time task, so the services are started automatically: [...]"_  Migrated scripts are already available for many commonly used services.

I'd like to repeat that I started this proposal solely because I see the demand for a faster startup, and naturally it comes to one's mind that parallel service startup can be beneficial in this regard.  Since the current init system does not offer this, it's normal to look for existing, mature solutions instead of patching this into the current one.  But maybe that's possible, as unitrunker suggested.


hruodr said:


> But the lots of desktop users mjollnir speaks for and not even use FreeBSD also have strong opinions about FreeBSD init system and want other one. Did they all create a service from scratch?!


I agree 100% to the 2nd (implication).  You don't have to be a developer to express a wish for some added functionality or other improvement.  On the 1st, no, most of them do not have strong opinions about technical topics.  An ordinary user does not care about which init system is used and about it's internals.  S/he cares about robustness, ease of use, functionality, and performance.  FreeBSD is obviously lagging behind other OSs in the latter regarding startup speed.


----------



## hruodr (Jul 28, 2020)

mjollnir said:


> FreeBSD is obviously lagging behind other OSs in the latter regarding startup speed.



If that is the case, it is clearly not a problem of the init system. I have in my desktops
rc.local:



> local_unbound_enable="YES"
> nfs_server_enable="YES"
> inetd_enable="YES"



With other init system you will sure not boot faster: most time is consumed by device probing.
I start manually `wpa_supplicant`, `dhclient` and `xinit` with
`twm` in .xinitrc  as normal user, they take their time and with other
init system you will not get faster a system with internet and desktop. I do not have 
the fastest computer, but startup speed is not a problem.

Your desktop users are an imaginary construct to support your argumentation.


----------



## Deleted member 63539 (Jul 28, 2020)

hruodr said:


> most time is consumed by device probing.


From my observation, I'm 100% agree with you.


----------



## Mjölnir (Jul 28, 2020)

Many of those technical topics are covered in http://smarden.org/runit/benefits.html.  Obviously these may be biased by the author's opinion, but it shows he was aware of such issues when he wrote _runit_.  I'm not saying each & every solution he implemented is right.  I suggested to explore & verify, as well as OpenRC, where the latter seems to have already been rejected on FreeBSD's review site.
gh_origin, you wrote your Linux starts about twice as fast as FreeBSD.  So you say it's device detection is so much faster to account for the difference?


hruodr said:


> Your desktop users are an imaginary construct to support your argumentation.


Please stop this kind of argumentation, it's getting ridiculous.  When I suggest FreeBSD to Linux users (ordinary, non-nerds), usually they come up with three topics:

many of my friends & buddies have Linux, it's widely deployed and in case I run into a problem, I can ask them & search many forums.  And some do not have good english skills, so they prefer information provided in their native tongue.
startup speed (until GUI login)
suspend/resume/hibernate


----------



## Deleted member 63539 (Jul 28, 2020)

mjollnir Linux does many tricks to help it boot time. FreeBSD is still more like a traditional server oriented OS. It detect and bring the network interface up during boot. Linux detect but do not bring the interface up until the user logged in, NetworkManager only now started to bring the interface up and network accessible. As I said, the major slowness is DHCP, without it, FreeBSD is not much slower than Linux. Another thing to mention, Linux loaded the video driver very early in the boot process and that saved much time for it. FreeBSD on the other hand loaded the drm-kmod module very latter in the boot process, just before DHCP. Yet another thing to consider is most Linux install to Ext4, it native FS. FreeBSD have to use a shim to be able to use ZFS. The kernel module opensolaris.ko and zfs.ko must be loaded. As I know, Linux doesn't have to load a kernel module for Ext4. Yes, it has to check the FS each boot but the fact it doesn't. Only when the FS is marked as dirty, the check would happen, if it's not, it's automatically skipped. After all we are comparing apple with orange here. It only fair to compare a FreeBSD Root On ZFS installation with a Linux Root On ZOL installation. But as I said, most Linux is installed on Ext4.

Please keep in mind, desktop Linux is heavily invested in. FreeBSD desktop, on the other hand, doesn't. Linux is now an advanced desktop system indeed, it could comparable to Windows and MacOS. FreeBSD desktop is just a server with a graphical user interface! And it will not change soon.

Please also keep in mind, each OS has very different boot procedure. The way FreeBSD probing it device now, it will always slower than Linux regardless of init system. If you think a parallel init system could make FreeBSD on par with Linux, please try GhostBSD and have your own conclusion if it's really on par with OpenRC based Linux or not. Don't compare GhostBSD with systemd based Linux, because it's not fair.


----------



## Jose (Jul 28, 2020)

mjollnir said:


> When I suggest FreeBSD to Linux users (ordinary, non-nerds), usually they come up with three topics...


So your purely anecdotal "many people believe this" is fine, but my purely anecdotal "no they don't" is clearly wrong?


----------



## Jose (Jul 28, 2020)

mark_j said:


> Well as I qualify for this, then I apparently meet your demands for posting to this thread.
> 
> Thanks for allowing me to participate.


So do I. What a relief!

It was in figuring out how to write a unit file for my service that I discovered the documentation is spread across 5-10 huge man pages.


----------



## unitrunker (Jul 28, 2020)

gh_origin said:


> Another thing to mention, Linux loaded the video driver very early in the boot process and that saved much time for it. FreeBSD on the other hand loaded the drm-kmod module very latter in the boot process, just before DHCP.


This is relatively recent change in FreeBSD. Before it was loaded from loader.conf but now in rc.conf and I don't know why.


----------



## Mjölnir (Jul 28, 2020)

Jose said:


> So your purely anecdotal "many people believe this" is fine, but my purely anecdotal "no they don't" is clearly wrong?


Where did I write this?  I can only speak of my experience & observations, and I do not deny your's.  Neither of us did a representative survey among Linux desktop users.  Please calm down & continue like e.g. gh_origin who supplied factual arguments.  Unfortunately, it seems our comrade from Luxembourg is on vacation, or he's not interested to share his experience with _runit_.  Also please keep in mind: I never wrote _runit_ or _OpenRC_ is better than the current _BSD init_, but I suggested to _evaluate_ if either of them is good enough to be considered an enhancement.


----------



## Jose (Jul 28, 2020)

gh_origin said:


> From my observation, I'm 100% agree with you.


Agreed as well. You should be looking into Coreboot if you're worried about boot speeds. Chromeos, which is easily the most successful Linux desktop distro, uses Coreboot and Upstart.


----------



## Mjölnir (Jul 28, 2020)

Jose said:


> [...] You should be looking into Coreboot if you're worried about boot speeds. [...]


Well, you might agree that this bears some risks.  In the worst case I can throw my laptop into the trash bin.  I find _race conditions_ numerous times as an argument throughout this discussion...  Even if my model is supported by coreboot, maybe some of it's internal devices is not (e.g. G3 modem, although I'd assume that's very unlikely).  Still then, what is under FreeBSD's control wouldn't be faster.  Maybe the reasons gh_origin listed do account for most of that.


----------



## kpedersen (Jul 28, 2020)

ralphbsz said:


> Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions? Or have done another interestingly complex task that involves other init systems compared to FreeBSD (and not just set up a system).



I think that is the problem. So many users today don't understand why systemd (or things like Wayland) have issues because they have not developed for them. They only see it from the users point of view of "Yeah, it works and is *NEW* so I like it". I suspect this is damaging Linux because casual users don't know what is correct.

And I don't believe anyone on these forums is a casual user. Most of this community is technical so has their views which sometimes conflict and that is great. But we do perhaps need to distance ourselves from ideas coming from communities where the majority aren't technical (Linux) and their technologies which again aren't based on technical merit but come from people that only know what color a background wallpaper should be.

Basically I am appalled that the most popular platforms like Windows and Gnome 3 has turned out so impossibly unusable and think we need to be much more careful in future haha!


----------



## hruodr (Jul 28, 2020)

kpedersen said:


> And I don't believe anyone on these forums is a casual user. Most of this community is technical so has their views which sometimes conflict and that is great. But we do perhaps need to distance ourselves from ideas coming from communities where the majority aren't technical (Linux) and their technologies which again aren't based on technical merit but come from people that only know what color a background wallpaper should be.



I have the impression in the OpenBSD mailing list that people there think everyone there is 
a kernel developer. Well, I am a user. I like the computer technology, but I use a computer
as an instrument. People using computers have different levels of consciousness about how
a computer works. Some have ideas of hardware, other of dealing with operating system, 
other of operating system design, other of programming, at machine level, other know how 
a compiler works, other know more physical parts of the hardware, etc. I remember my 
first encounter with computers: just as a FORTRAN programmable machine for doing some
calculations, little knowledge of hardware or operating systems. A low level of consciousness. 
I dealt with many computers with different OS in that way. It had a positive side: no distraction
with computer technology. The Linux or Microsoft users you mention have also a low level of consciousness, and that is not necessarily bad. Microsoft must care for them, Linux developers,
as *mjollnir* for his desktop users . But my experience is, that life is easier if one takes a 
little of time to learn something more and get conscious of how the computer works.


----------



## a6h (Jul 28, 2020)

After mjollnir was successfully portrayed as a systemd advocate, we've established that _Desktop User_ is a code, referring to toothless wander on the street.


----------



## Jose (Jul 28, 2020)

mjollnir said:


> Well, you might agree that this bears some risks.


Yes, and I'll admit I'm being selfish. You're the only one who suffers if you brick your laptop in an ill-advised attempt to reduce your boot times. We all suffer if you manage to get Freebsd to adopt some screwy init system through your advocacy. Note that the latter is not a hypothetical, most Linuxes adopted systemd because of the advocacy of a few well connected members of the community, and not because it offered any significant tangible benefits.


----------



## zirias@ (Jul 29, 2020)

vigole said:


> After mjollnir was successfully portrayed as a systemd advocate, we've established that _Desktop User_ is a code, referring to toothless wander on the street.


Yes, this is really getting out of hands -- I start to see the motivation behind ralphbsz's post earlier in that thread.


----------



## hruodr (Jul 29, 2020)

Zirias said:


> I start to see the motivation behind ralphbsz's post earlier in that thread.



This thread began with the question how to install nosh init and some answers to it.
Then it was told that nosh init has advantages like systemd, and it was commented
that systemd has no advantages. And then began the critics to FreeBSD init, it was even
called SysVinit, what is clearly not:



mjollnir said:


> Well, I'd rather say _it works_ than call it _solid_. FreeBSD is great, but that doesn't mean each & every part of it is great, too. The SysVinit we have is really old-fashioned, to put it politely.



Then the tema was a confusion between replacement or alternative to FreeBSD init, but
in any case insistent that FreeBSD init is deficient. I would take joses words seriously:



Jose said:


> Note that the latter is not a hypothetical, most Linuxes adopted systemd because of the advocacy of a few well connected members of the community, and not because it offered any significant tangible benefits.



We have now Lua in the boot loader and it got problematic. Was the bootloader instable,
deficient? Did a lot of users need lua there? And yes, not each & every part of FreeBSD is
great, but was necessary to touch the boot loader and is necessary to touch the init?!

What is getting out of hands, *Zirias*? That few/one person insist that FreeBSD init is deficient,
insist seeing the cause of slow booting on it, that portray themselves as supported by
desktop users on their claims?

And by the way, I find interesting that FreeBSD init was called SysVinit: the classical BSD 
critics to SysVinit is that it is unnecessarily complicated.


----------



## kpedersen (Jul 29, 2020)

Zirias said:


> Yes, this is really getting out of hands.


True, but for anyone who wants more of this, I invite them to check out some of the OPs other posts. Most of them involve questioning why Wayland or other Linux technology is not yet in FreeBSD. Some are valid questions but the discussion often tends to be rather long.


----------



## Lamia (Jul 29, 2020)

unitrunker said:


> This is relatively recent change in FreeBSD. Before it was loaded from loader.conf but now in rc.conf and I don't know why.


You can choose how you want drivers to load and that is powerful - load them as system boots up or after boot. Servers load faster when you load after boot. Desktop PCs too. Seriously, there is no room for arguments here. 
Linux SystemD is borrowing leaf from SysVInit and others. An attack on SystemD internals has severly broken various Linux distros here several times And we needed to restore/reinstall them.We can now sleep well with distros without it. 

There is not so much contributions to make to this debate. Choose what works for you.


----------



## Mjölnir (Jul 29, 2020)

Jose said:


> [...] We all suffer if you manage to get Freebsd to adopt some screwy init system through your advocacy. Note that the latter is not a hypothetical, most Linuxes adopted systemd because of the advocacy of a few well connected members of the community, and not because it offered any significant tangible benefits.


I'm neither a well-connected FreeBSD community member, nor did I advocated _systemd_...  My objective was to evaluate _runit_ & _OpenRC_, and IMHO a quick glance into http://smarden.org/runit/benefits.html let me assume it is not a "screwy" init system.  I explicitely added: "O_bviously these may be biased by the author's opinion,..."_
Why do you keep blaming me that I want to destroy FreeBSD while all I did was to point at some topic where FreeBSD could/should be improved & make a proposal how that could be done (aka: constructive critics)?


hruodr said:


> [...] And then began the critics to FreeBSD init, it was even
> called SysVinit, what is clearly not:


I did an incomplete, quick lookup about_ init_ systems and that's why I had this term in mind.  I corrected that afterwards.  Does this minor flaw invalidate substantial points of my critics?  I rather interpret this as an attempt to cast a shadow on me, and I consider this as bad style.


> Then the thema was a confusion between replacement or alternative to FreeBSD init, but
> in any case insistent that FreeBSD init is deficient. [...]


Some technical issues were discussed above, some but not all related to service supervision & monitoring (_optional_ in _runit_), and the author of _runit_ claims to provide sound solutions (e.g. reliable PID handling and logging).  Again, I do not say that this is all done in the right way, but it's worth looking at, right?  Isn't it right to look for existing solutions before trying to re-invent the wheel?

hruodr, you wrote about your rather slow/old hardware & minimalistic system.  So if you're using UFS, you may benefit by inserting an I/O scheduler with my geom_sched service script & stop suspecting me as your enemy.  If you find a bug, drop me a note or fix it yourself and post it as reply.  I'll update the script or link your fix in my post.  Then you could see one deficiency of the current _BSD rc/init_ yourself: if you want to make it user-friendly (e.g. support `service geom_sched rcvar`), it's getting ugly.  Shell script syntax is commonly considered error-prone.  And ~ 50% (?) of all service scripts are basically very similar, i.e. IMHO it would be better (less error-prone) to parameterize a default script and feed the service's configuration into it (No, I do not propose to allow or switch to LUA here).  Of course, this is an issue of the current implementation or how it is used, respectively, and not a fundamental problem of _BSD init_ itself.

Long story short: simply denying existent problems is cheap, and repeatedly offending s/o who critizises is bad style.


----------



## Mjölnir (Jul 29, 2020)

PS: I measured boot times: from hibernate state back to GUI: ~30 sec., from FreeBSD boot screen to GUI login: ~30 sec., too.  From power-off to boot screen would add ~10 sec., starting the GUI ~10 sec.?
I have 12GB RAM, that is the size of the hibernation partition on a SSD, too, and a 12/15W TDP CPU (dual core i7-5600U@2.6GHz).  So yes, suspend/resume/hibernate is significantly faster than booting, but now & then the 3G modem does not initialize (it hangs, only reboot get's it back), and some network monitoring utilities get confused that the interface went down (I'm dialing in via WWAN, WLAN would have the same issue, I guess, i.e. if the access point closed the connection).  The latter is not important to me, and obviously is a bug of these utilities.  Nevertheless these are normal problems in an imperfect world, and a good reason to prefer a clean boot to suspend/resume/hibernate.


----------



## zirias@ (Jul 29, 2020)

mjollnir said:


> Long story short: simply denying existent problems is cheap, and repeatedly offending s/o who critizises is bad style.


Although I still don't think there are "existent problems", I agree with your criticism how this "discussion" is conducted. Everyone has different preferences, and one of mine is that I want an init system with a classic /etc/rc, so I can do anything with shell scripting. And also, I think mewburn rc is (one of) the best in existence. It is far from the mess SysV-init with its runlevels and symlinks is. Still I see your points, but I think they might be better addressed with optional packages that don't replace init.


----------



## hruodr (Jul 29, 2020)

mjollnir said:


> I did an incomplete, quick lookup about_ init_ systems and that's why I had this term [SysVinit] in mind. I corrected that afterwards. Does this minor flaw invalidate substantial points of my critics?



Yes! 

Yes, because init is one of the well known differences between BSD and SysV. One could say
essential difference. This is a very old and known issue. BSD people kept aware that there 
is nothing to win, more to lose by inflating init. SysV inflated init with a lot of non sense 
"run levels", while BSD init has in principle only two: the normal one and single user mode 
for the case when rc fails. But SysV inflation was not enough to them, linux came with 
systemd. And by the way, I do not like the inflated rc scripts structure of FreeBSD.

You did not know that? Perhaps because you are not originally a BSD user, perhaps a Linux
user. Why should every unix like system become linux like?! And inflating init means without
doubt going away from unix. If you like linux or Solaris (SysV), then use Linux or Solaris!
You want to expand the user basis of FreeBSD with linux configurated people? No thanks!

I do not consider you an enemy. And thanks for your offer, but I am happy with FreeBSD as 
I use it. Exactly because I use it as desktop I do not start X11 or internet at boot time, but 
manually when I need a GUI or internet connection.


----------



## zirias@ (Jul 29, 2020)

hruodr said:


> You did not know that? Perhaps because you are not originally a BSD user, perhaps a Linux
> user.


In other news, the POTUS just complained that nobody liked him...


hruodr said:


> Exactly because I use it as desktop I do not start X11 or internet at boot time


Cause that's what desktops definitely shouldn't have by default nowadays -- a GUI or internet. Thanks for clarifying that.


----------



## teo (Jul 29, 2020)

Zirias said:


> In other news, the POTUS just complained that nobody liked him...
> 
> Cause that's what desktops definitely shouldn't have by default nowadays -- a GUI or internet. Thanks for clarifying that.



What you have to read, nowadays everybody uses the desktop graphic interface whether it's a mobile phone or a computer, the only ones that don't need the desktop graphic interface are the servers that few users use, and that's why the BSD debility is about to disappear.


----------



## zirias@ (Jul 29, 2020)

Remind me to never forget adding sarcasm tags again


----------



## Jose (Jul 29, 2020)

mjollnir said:


> I'm neither a well-connected FreeBSD community member, nor did I advocated _systemd_...


The Freebsd community is much smaller, and therefore potentially easier to influence. I stayed out of the systemd thing because I was a Gentoo user and I didn't get wanna get involved. I'm not making that mistake again.



mjollnir said:


> My objective was to evaluate _runit_ & _OpenRC_, and IMHO a quick glance into http://smarden.org/runit/benefits.html let me assume it is not a "screwy" init system.  I explicitely added: "O_bviously these may be biased by the author's opinion,..."_


And I already explained to you why my lengthy experience with Openrc makes it a non-starter for me. I haven't really used runit enough to have an informed opinion. My limited exposure to it as an init system was positive, but I still wonder if the same race conditions that effectively killed parallel startup in Openrc won't arise if I were to use runit in anger.



mjollnir said:


> Why do you keep blaming me that I want to destroy FreeBSD while all I did was to point at some topic where FreeBSD could/should be improved & make a proposal how that could be done (aka: constructive critics)?


I don't think you're trying to destroy Freebsd, and I'm not blaming you for anything. I heartily agree with you on Poudriere vs Portmaster and I hope that further separation of the build system from the deploy system will come to Freebsd. However, I am going to strongly disagree with you and anyone else who thinks 30 seconds of boot time are worth royally screwing up system startup for everyone.


----------



## kpedersen (Jul 29, 2020)

teo said:


> everybody uses the desktop graphic interface whether it's a mobile phone or a computer



Don't be so sure about that. A large proportion of technical users (i.e most Linux / BSD userbase) use nothing else apart from a bunch of maximized terminal windows (i.e residing in dwm, sway, etc). Your view of a WIMP interface being what users want is considered old fashioned and stems from the old haydays of Windows 95.

Even consumer Windows is becoming "modern" with a proper terminal.


----------



## mark_j (Jul 29, 2020)

mjollnir said:


> PS: I measured boot times: from hibernate state back to GUI: ~30 sec., from FreeBSD boot screen to GUI login: ~30 sec., too.  From power-off to boot screen would add ~10 sec., starting the GUI ~10 sec.?
> I have 12GB RAM, that is the size of the hibernation partition on a SSD, too, and a 12/15W TDP CPU (dual core i7-5600U@2.6GHz).  So yes, suspend/resume/hibernate is significantly faster than booting, but now & then the 3G modem does not initialize (it hangs, only reboot get's it back), and some network monitoring utilities get confused that the interface went down (I'm dialing in via WWAN, WLAN would have the same issue, I guess, i.e. if the access point closed the connection).  The latter is not important to me, and obviously is a bug of these utilities.  Nevertheless these are normal problems in an imperfect world, and a good reason to prefer a clean boot to suspend/resume/hibernate.


You can install runit from ports. Maybe give that a try and compare your suspend/restart times?
With the modem, does `usbconfig reset` help?

I think it's self evident that FreeBSD has a way to go with support for suspend on all devices. The thing is, I also find that FreeBSD's boot time is mainly spent enumerating devices and, if you have them, IO cards like SCSI/SAS etc.

I also think it's obvious that some things could benefit by starting simultaneously, such as syslog/cron/sendmail etc. Why these are not started in "the background" has always been contentious if you ask me. For example, the old UFS system always did "background checks" of the file system.

So could some services be backgrounded so you hit the login prompt quicker? For sure, so I suggest you join the freebsd-arch mailing list and pose the question (I think that's the right group?) and see what comes of it. I'm pretty sure no core people even browse these forums.

In summary, I'm not unsympathetic to your plight. I don't believe you're an advocate for that evil systemd  and I don't think a change *of *the init system is warranted, but then my vote counts for nought also.


----------



## Jose (Jul 30, 2020)

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.


----------



## Mjölnir (Jul 30, 2020)

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.


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.


----------



## Mjölnir (Jul 30, 2020)

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


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.


----------



## Holger (Jul 30, 2020)

gh_origin said:


> Linux does many tricks to help it boot time.


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


----------



## zoujiaqing (Aug 2, 2020)

OpenRC for FreeBSD work has be stoped:


			https://reviews.freebsd.org/D18578


----------



## Deleted member 63539 (Aug 2, 2020)

zoujiaqing said:


> OpenRC for FreeBSD work has be stoped:
> 
> 
> https://reviews.freebsd.org/D18578


They are right to stop it. Because it brings no actual benefits to FreeBSD at all.


----------



## kpedersen (Aug 2, 2020)

I think the OP just linked to an obsolete page.

This ends with:



> Close, I will reopen it with a larger update.



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


----------



## Jose (Aug 2, 2020)

Gawd, no!


			Gentoo Forums :: View topic - Lennart Poettering on opentmpfiles: it's just baaaad


----------



## Deleted member 63539 (Aug 3, 2020)

kpedersen said:


> I think the OP just linked to an obsolete page.
> 
> This ends with:
> 
> ...


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.


----------



## mark_j (Aug 3, 2020)

kpedersen said:


> I think the OP just linked to an obsolete page.
> 
> This ends with:
> 
> ...


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?


----------



## Deleted member 63539 (Aug 3, 2020)

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


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.


----------



## Mjölnir (Aug 3, 2020)

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.


----------



## Sebulon (Aug 3, 2020)

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!


----------



## Deleted member 63539 (Aug 3, 2020)

mjollnir said:


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


May be _runit_'s friend, permissive license, too (ISC): https://skarnet.org/software/s6/


----------



## 20-100-2fe (Aug 4, 2020)

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.


----------



## mark_j (Aug 4, 2020)

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.



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! 

Did Sun actually open source SMF?


----------



## Deleted member 63539 (Aug 4, 2020)

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!




So _runit_ or _s6_ is the way to go 



mark_j said:


> Did Sun actually open source SMF?












						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


----------



## Hakaba (Aug 4, 2020)

/!\ 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.


----------



## Deleted member 63539 (Aug 4, 2020)

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 ?


You are right. I think I should quit this discussion.


----------



## Mjölnir (Aug 4, 2020)

Hakaba said:


> /!\ Ironie on this post !
> 
> Runit have 500 LoC ?
> It is a fat init !
> ...


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_?


----------



## 20-100-2fe (Aug 4, 2020)

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.


----------



## a6h (Aug 4, 2020)

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.


----------



## kpedersen (Aug 4, 2020)

20-100-2fe said:


> However, using another init system would immediately obsolete tons of good documentation



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.


----------



## 20-100-2fe (Aug 4, 2020)

kpedersen said:


> It is starting to suggest that few people use Linux compared to simply talking about using Linux....



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.


----------



## kpedersen (Aug 4, 2020)

20-100-2fe said:


> It looks like Linux has become a standard tool managed more often by other tools than by human beings.



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.


----------



## Phishfry (Aug 4, 2020)

kpedersen said:


> and less flexible


How about binary system logs.
That one always baffled me. Our log rotation method works wonderful.
All my logs are human readable and old logs are archived.


----------



## ralphbsz (Aug 4, 2020)

You are describing a trend that has been going on for decades, and is both natural and necessary.

30 years ago, human beings administered computers. Each computer was administered individually, and things were typically customized. Part of the reasons was that computers were big, expensive, and shared for multiple users (where user doesn't necessarily mean a human who logs in, but more often a workload, such as billing / logistics / analytics / web serving). This was workload intensive, and error prone, but it was economically efficient, because computers were expensive, and humans relatively cheap. A typical calculation from the late 1990s was that for every $1 that is spent on hardware (computers, storage, networking), the lifetime cost of operating that hardware is about $10 (including software, power, cooling, security, floor space, ...), and the lifetime cost of administering that hardware into a useful system (including human admins and consulting services) was $100. And while having to pay for electricity or cooling is necessary but can be optimized), having to pay another factor of x10 for humans to administer them is inefficient. As an example, in the early 2000s the average number of system and database administrators for a typical-size SAP installation was 34. That's 34 humans to keep a small cluster of computers and storage running, measured industry-wide!

For clusters, beginning in the early 90s, there were ad-hoc systems built to be able to take configuration files and replicate them over many computers. But for a long time, these systems were mostly used in supercomputer clusters, not in commercial computing, where the model was still that every server has a specific purpose, and therefore is managed individually.

Clearly, this is not sustainable. In particular with the explosive growth of the number of computers. I have no idea how many servers there are in the world today, but if you look at the FAANG and the large cloud providers, they each have dozens or hundreds of millions of physical machines (way more VMs), and there is no way to edit shell scripts to configure them, or read human-readable logs.

So what has happened is that the concept of "system administrator" has gone away. Today, most systems are no longer administered; they are mass-produced, their configuration is stamped out on the software equivalent of assembly lines, and they are monitored by automated systems. The job title of "system administrator" has been replaced by "system reliability engineer"; those are a specialized type of software engineers, who create automated deployment and monitoring systems. The decision which computers to deploy where is also made by automated systems, typically combinatorial optimizers that look at the known workloads and requirements, and spit out (re-)deployment orders. I think today the traditional model of "system administration" only exists for amateurs and very small shops.

Having said that: I enjoy administering my little home server (it is literally the size of a shoe box), and the 3 or 4 other computers that are in use at home (some of those are Raspberry Pi). Tasks like looking at log files and editing /etc/rc.conf give me joy (channeling Marie Kondo here). But a project like FreeBSD or a commercial project like {RedHat,Suse,...}-Linux should probably not be organized around providing a toy for hobbyists who are mentally stuck in the 80s and 90s, if 99.9% of all computers are used in giant data centers using automated systems.


----------



## kpedersen (Aug 4, 2020)

Phishfry said:


> How about binary system logs.
> That one always baffled me. Our log rotation method works wonderful.



Agreed. Needing a tool to parse a binary file just seems daft. In some ways I can't even see this being particularly "machine friendly" either. A specific API would be needed to process it compared to splitting a string line by line for example :/

(I have cleared up my post a bit to mention less flexible *compared to* shell scripts)



ralphbsz said:


> if 99.9% of all computers are used in giant data centers using automated systems.



Interestingly I no longer believe these big data centers govern the direction of operating systems. A relatively small number of highly skilled and passionate developers do. And these kinds of developers don't really like the additional indirection of large automation systems. It takes their fun out of computing. So really, the guys with their shoebox home servers are ultimately the guys that make the choices.

Only commercial companies seem to love these heavy orchestration systems. And the majority never last particularly long.

I also feel the reason why Microsoft (and Windows) has really stagnated compared to Linux since ~2003 is the introduction of DRM which has stripped the passion from the developers. For example they know that any of their efforts they spend on the platform can (and will) be taken away from them by Microsoft. This observation might just be me self-reflecting however haha!


----------



## Beastie7 (Aug 5, 2020)

mark_j said:


> Launchd is, in my mind, an awful system



I’m curious. Care to explain why it’s such an awful system? And do you have any empirical evidence to support such claims?



mark_j said:


> Launchd is particularly nasty as if it fails its error messages are about as useful as stating "? error ?".



Again, I’d like to see some citations supporting such claims; other than anecdotal speculation.

A plus for launchd is that it’s been vetted, tested, and used in millions of devices in many different real world scenarios. I’d wager the work involved in adopting such a proven system is far less involved and time consuming than re-creating a similar environment, or adopting a newer re-implementation of said subsystem. Mind you, launchd was released in 2005 and heavily relies on Mach IPC; which from what I’ve read provides far more benefits than sysv IPC and UNIX domain sockets. I openly welcome those additions.


----------



## mark_j (Aug 5, 2020)

Beastie7 said:


> I’m curious. Care to explain why it’s such an awful system? And do you have any empirical evidence to support such claims?



Empirical evidence? Seriously? You want me to produce a study of its horridness?

We have to use that gunk in my work environment and it's just rubbish. It's obtuse, anachronistic and truly bloated for what it's supposed to achieve. But, if you like it, feel free to port it to FreeBSD. Maybe second time around someone will give it some love.

You'd get a better system with SMF, at least svcbundle is useful. What's Apple got again?




Beastie7 said:


> Again, I’d like to see some citations supporting such claims; other than anecdotal speculation.



LOL.


----------



## 20-100-2fe (Aug 5, 2020)

ralphbsz said:


> Today, most systems are no longer administered; they are mass-produced, their configuration is stamped out on the software equivalent of assembly lines, and they are monitored by automated systems.



And that's fine.

However, when things go wrong, human "resources" have to solve the issue. This is why I find it quite stupid to create tools that make the job of humans more difficult in an already difficult situation, whereas automation software can work equally well with user-friendly tools. But it is not surprising: in all areas (not just IT), structuring decisions are always made by people who will not have to deal with their consequences.


----------



## Mjölnir (Aug 5, 2020)

20-100-2fe said:


> However, when things go wrong, human "resources" have to solve the issue. This is why I find it quite stupid to create tools that make the job of humans more difficult in an already difficult situation, whereas automation software can work equally well with user-friendly tools. But it is not surprising: in all areas (not just IT), structuring decisions are always made by people who will not have to deal with their consequences.


Let's see an OS as a basic tool to do IT.  These _"structuring decisions"_ were made by Linux owners (IBM/RedHat, Oracle etc.pp.) to sell their manpower...  Once your customers have deployed your tool/solution widely, they are forced to follow any change under the hood, because they can not switch the tool so easily.  It's not uncommon that a company has even lost control about their own data and rely on external consultants to access it...  Naturally, all big & small IT consulting companies support such change & praise it to their customers to _"ease IT management & save resources"_.  Haha...


----------



## kpedersen (Aug 5, 2020)

Beastie7 said:


> many different real world scenarios.


Launchd is an Apple thing right? So it surely has only been tested on the consumer desktop by a bunch of non-professionals or students putting music on their ipods.

Apple pulled out of the server world years ago. Presumably their technology wasn't up to scratch.

My experience with it is purely based on cracking Adobe Photoshop for my partner. It was almost a completely obfuscated black box. Presumably so it makes it easier for Apples partners to hide DRM in there. There is no denying that patching a shell script to remove a license check would have been a lot easier than faffing about with Radare2 and patching a binary.


----------



## Hakaba (Aug 5, 2020)

mjollnir said:


> 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_?


The «fat» argue is the ironic part of my post (I hope it was obvious ...)
Nothing wrong with exploring/evaluating runit, sunit or systemd... My previous post is not clear about this point ?


----------



## 20-100-2fe (Aug 5, 2020)

mjollnir said:


> Naturally, all big & small IT consulting companies support such change & praise it to their customers to _"ease IT management & save resources"_.



Managers on both sides are happy with this situation and it would be absolutely perfect if at some point, they didn't require those dirty techies at the very bottom of the hierarchy to deliver working applications, or keep them working... :/


----------



## AngryChris (Aug 6, 2020)

Beastie7 said:


> I’m curious. Care to explain why it’s such an awful system? And do you have any empirical evidence to support such claims?
> 
> 
> Again, I’d like to see some citations supporting such claims; other than anecdotal speculation.


Its configuration is done via XML files. That alone makes it awful. And that's not speculation. That's my lived experience managing a fleet of nearly 15,000 Macs. launchd is awful. Give me systemd any day over launchd. systemd's configuration files are at least logically organized and make sense.


----------



## mark_j (Aug 6, 2020)

AngryChris said:


> Its configuration is done via XML files. That alone makes it awful. And that's not speculation. That's my lived experience managing a fleet of nearly 15,000 Macs. launchd is awful. Give me systemd any day over launchd. systemd's configuration files are at least logically organized and make sense.


Apple has a plist editor; it's a wonderful tool to help you. Trouble is it's in Xcode - another bloated piece of </sarcasm>
        or
you could use `defaults`and spend days understanding the guff it produces.


----------



## Deleted member 63539 (Aug 6, 2020)

mjollnir Just found out antiX has a _runit_ brand: https://mirrors.evowise.com/mxlinux-iso/ANTIX/Final/antiX-19/


----------



## hruodr (Aug 6, 2020)

gpb said:


> but Linux is UNIX-like, just like Minix.



Minix yes, Linux no, it is only a kernel. It would be nice to have a Linux distribution that is
so Unix-Like as a BSD system, including its simple init/rc system.


----------



## 20-100-2fe (Aug 6, 2020)

gh_origin said:


> mjollnir Just found out antiX has a _runit_ brand: https://mirrors.evowise.com/mxlinux-iso/ANTIX/Final/antiX-19/



I've just given Antix a try.
OMG!
It's a good remedy for even the strongest urge to adopt Linux...


----------



## kpedersen (Aug 6, 2020)

gpb said:


> Hate to burst your bubble, but Linux is UNIX-like, just like Minix.



Perhaps true a few years back. Certainly not any more.

I think Linux is even heading away from POSIX. For example the have already replaced vi with nano as the default editor. I think that is a requirement for POSIX for vi to be $(EDITOR).

I don't mean this as a bad thing either. I think it is time for Linux to stand on its own two feet and see if it's ideas are good enough in its own right rather than begrudging the fact that it is just a clone of an "ancient" OS.



gpb said:


> And because their ancestor isn't a PDP-7, doesn't make them not UNIX-like.



As for UNIX-*based* operating systems. I think it will be liberating for them to no longer have to see Linux trying to pull them in strange directions.


----------



## Mjölnir (Aug 6, 2020)

20-100-2fe said:


> I've just given Antix a try. OMG! It's a good remedy for even the strongest urge to adopt Linux...


Remedy - The Black Crowes
This thread is drifting off-topic... Would someone like to collect a summary of the issues of BSD init, mentioned around the middle of this thread?


----------



## 20-100-2fe (Aug 7, 2020)

It looks like Devuan 3.1 is going to offer a runit choice at installation.
And for those who can't wait, it is already possible to make the switch on 3.0.

https://dev1galaxy.org/viewtopic.php?id=3628


----------



## zoujiaqing (Aug 18, 2020)

kpedersen said:


> Too many disadvantages.


launchd on macOS very cool.
systemd on Linux very cool.
nosh on FreeBSD very cool.


----------



## shkhln (Aug 18, 2020)

zoujiaqing said:


> nosh on FreeBSD very cool.



Why don't you put your money where your mouth is? Make a port for nosh and submit it. You can look at sysutils/runit and sysutils/runit-faster for inspiration. Or STFU, that works too.


----------



## a6h (Aug 18, 2020)

zoujiaqing said:


> nosh on FreeBSD very cool.


Not having Reddit posts on FreeBSD Forums [is] very hot.


----------



## kpedersen (Aug 18, 2020)

zoujiaqing on macOS forums very cool.
zoujiaqing on Linux forums very cool.
zoujiaqing on FreeBSD forums confusing.


----------



## 20-100-2fe (Aug 18, 2020)

So you have ported it, already?



zoujiaqing said:


> nosh on FreeBSD very cool.


----------



## Deleted member 63539 (Aug 19, 2020)

zoujiaqing said:


> launchd on macOS very cool.
> systemd on Linux very cool.
> nosh on FreeBSD very cool.


Are you a troll?


----------



## mark_j (Aug 19, 2020)

gh_origin said:


> Are you a troll?


LOL.  He might very well be, but one thing's for certain, he does like complex init systems...


----------



## Mjölnir (Aug 19, 2020)

admin, feel free to move the remainder of this thread to _Off-Topic - It's all about jokes & funny pics_


----------



## mark_j (Aug 19, 2020)

The funny thing with nosh is in my neck of the woods it's quite a naughty word (or abbreviation of one):





						Urban Dictionary: nosh
					

to snack on




					www.urbandictionary.com


----------



## Jose (Aug 19, 2020)

We're doing jokes now? Vigole's post made me think of Paris Hilton for president. Maybe our goal should be to make Freebsd hot for the first time?


----------



## zoujiaqing (Aug 19, 2020)

20-100-2fe said:


> So you have ported it, already?


I'm a new FreeBSD player. 
You are masters. 
So I'm going to ask you more.
I'll try to use it.


----------



## ono (Oct 21, 2020)

mjollnir said:


> Naturally, the number of whom I personally know is much lower of those I pretend to speak for.  Friends & family.  Collegues.  Myself. (...) Most of them start XfCE, Gnome, or KDE desktop environment with no bells & whistles.


Hi there, I have just created an account to respond to this thread. I was never FreeBSD user, however I regularly use Linux, Mac and Windows. I was recently playing with FreeBSD and the first thing that I have noticed was that it takes pretty long to boot it into working console in vanilla system. I was curious if this is normal, then I found this thread. Therefore I'd like to defend mjollnir arguments, that it does matter how long it takes to boot or reboot the OS, at least this is the first thing you notice when you try FreeBSD.


----------



## drhowarddrfine (Oct 22, 2020)

ono I find that boot time is most important among redditors, hobbyists, and other amateurs to the point of distraction. It's as if their world will come crashing down and they will choose their "distro" based on boot time and pretty colors. They seek out such things on Google in order to correct the internet when they have nothing else to do which is often.

In the meantime, the rest of us are trying to make the most technically proficient system on the planet and we succeed at it using FreeBSD. Then we go home to our families and enjoy the fruits of our labor.


----------



## ekvz (Oct 22, 2020)

ono said:


> Hi there, I have just created an account to respond to this thread. I was never FreeBSD user, however I regularly use Linux, Mac and Windows. I was recently playing with FreeBSD and the first thing that I have noticed was that it takes pretty long to boot it into working console in vanilla system. I was curious if this is normal, then I found this thread. Therefore I'd like to defend mjollnir arguments, that it does matter how long it takes to boot or reboot the OS, at least this is the first thing you notice when you try FreeBSD.



I guess the importance kind of depends on how often you are actually booting the systems in question so on a server boot times are mostly an unimportant detail by default and if you are constantly booting your desktop machine you'd likely be better off looking into setting up suspend (which admittedly is not without it's own set of problems on FreeBSD) anyways.

In theory it would probably be nice to have different init options (a simple reliable one that might be a bit slower and a fast just-execute-stuff-asap one that might save some time at the expense of risking to end up in some weird state due to being non deterministic) but such dual approach is easier said than done as a lot of development and even more importantly testing/debugging is practically doubled. Unless some third party wanted to invest a massive amount of manpower into making this happen and keeping it supported it's just not feasible at the moment in my opinion so the reliable approach is obviously the way to go for now.


----------



## shkhln (Oct 22, 2020)

ono said:


> I was recently playing with FreeBSD and the first thing that I have noticed was that it takes pretty long to boot it into working console in vanilla system.



How long exactly? It shouldn't take more than 10-20 seconds.


----------



## drhowarddrfine (Oct 22, 2020)

shkhln said:


> How long exactly? It shouldn't take more than 10-20 seconds.


I read on reddit last year, I think, where someone said that and cried 10 seconds was an eternity. It's an example of why I never go to reddit.


----------



## Sevendogsbsd (Oct 22, 2020)

This is funny - some people care about boot times and I have always not cared about them. Sure, I have nvme systems that boot in a couple of seconds, but for my uses cases, it really doesn't matter. Hell, my work laptop, which is an i7 with 16GB ram and Windows 10 enterprise, takes 15 minutes before it is even useable...10 seconds, I wish...


----------



## mark_j (Oct 22, 2020)

ono said:


> Hi there, I have just created an account to respond to this thread. I was never FreeBSD user, however I regularly use Linux, Mac and Windows. I was recently playing with FreeBSD and the first thing that I have noticed was that it takes pretty long to boot it into working console in vanilla system. I was curious if this is normal, then I found this thread. Therefore I'd like to defend mjollnir arguments, that it does matter how long it takes to boot or reboot the OS, at least this is the first thing you notice when you try FreeBSD.


Really? How long is "pretty long"?
What's your hardware?
The slowest part (in my many years of using this OS) is the probing of hardware, especially with exotic setups such as some RAID cards. This could be an area of performance tuning. I find the scanning of the USB bus(es) is very slow.

Oh, and they could ditch sendmail to the ports system, that would give you 10 seconds...

You have to remember, for better or for worse, FreeBSD is a small project that has to carefully pick its focus points. It doesn't have the huge corporate control of other OS. Spending time on reducing the start time of a desktop environment while being predominantly server focused is just a hurdle too high to jump, I would expect.

PS. I think I agreed with Mr mjollnir that FreeBSD could do with a focus on suspend/sleep/wake if only to allow more laptop usage. (Then again this is another example of every manufacturer following their "standards').


----------



## a6h (Oct 23, 2020)

When you start a typical well-customised Windows 10 (~ 57 % market share), it's take about 2-4 minutes, till HDD stop making zoo noises. But everybody is happy over there!

What's a typical well-customised Windows 10:

HDD: Spinning disk (HDD implies no SSD!)
Defender: disabled.
Fast Startup: disabled (why? because it's a hack similar to the Hybrid Sleep)
Optimise drives service (defragsvc): disabled.
No 3rd party task in the Task Scheduler (taskschd).
DEP aka Data Execution Prevention: turned off.
`bcdedit.exe /set {current} nx alwaysoff`
Processor Scheduling: background aka service:
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl` is set to `2` (DWORD)
Page File: disabled:
`powercfg -h off`
IP: static.
PS. There was a discussion between George Neville-Neil and Bryan Lunduke on the youtube. In the middle of conversion George said something which I enjoyed very much. I paraphrase it: "_those nice people at FreeBSD_".
Linux and Windows users constantly come here, and start off-topic conversions, but we tolerate/answer them civilly. Because we are nice people.


----------



## mickey (Oct 23, 2020)

For what it's worth, last time I checked the time it takes my machine to fully boot to desktop (HDD, fastboot cheat disabled) the result was:

Windows 10: 02:09
FreeBSD/KDE: 01:25

Works for me.


----------



## drhowarddrfine (Oct 23, 2020)

Sevendogsbsd said:


> my work laptop, which is an i7 with 16GB ram and Windows 10 enterprise, takes 15 minutes before it is even useable.


My wife uses Windows for QuickBooks. In the morning she often complains it isn't connected to the internet. I tell her to wait a minute and, sure enough, it eventually connects. 

She usually leaves it on all the time. If I ever have to fix something for her, rebooting takes ages as you describe.


----------



## a6h (Oct 23, 2020)

drhowarddrfine said:


> rebooting takes ages as you describe.


Using Windows implies a lot of rebooting and reinstalling. RAM decays in windows! WinRamRot?


----------



## Sevendogsbsd (Oct 23, 2020)

I think it's just that Windows is really a terrible product. It's overly complex, the UI is inconsistently designed and yes, it works, but not very well in my opinion, at least for normal desktop tasks. I use it to host my World of Warcraft icon and that's it


----------



## ono (Oct 23, 2020)

shkhln said:


> How long exactly? It shouldn't take more than 10-20 seconds.





mark_j said:


> Really? How long is "pretty long"?
> What's your hardware?


FreeBSD 12.1 takes 10 seconds to boot to text mode login prompt after I have put my hostname into _/etc/hosts_ otherwise _sendmail_submit_ and _sendmail_msp_queue_ start take additional 30 sec, but this is different subject -> https://forums.freebsd.org/threads/s-why-do-hostname-and-sendmail-steps-at-boot-take-so-long.44801/

10 sec may be not that much, but same machine Arch Linux 5.9 takes 6 seconds to Xorg SDDM graphical login prompt. My machine is i7-8700 with NVME disk.



mark_j said:


> The slowest part (in my many years of using this OS) is the probing of hardware, especially with exotic setups such as some RAID cards. This could be an area of performance tuning. I find the scanning of the USB bus(es) is very slow.


It seems in my case scanning hardware up to USB takes 6 seconds, then USB enumeration takes additional 2 sec, DHCP 1 sec and then starting services just 1 sec. So that hardware enumeration is kind of slow comparing to Linux. Of course one may argue that booting faster is not a top priority, but on other hand if you need to upgrade kernel it is nice to have shortest possible reboot downtime.



Sevendogsbsd said:


> I think it's just that Windows is really a terrible product. It's overly complex, the UI is inconsistently designed and yes, it works, but not very well in my opinion, at least for normal desktop tasks.


I agree, especially there on overall complexity, or rather bloat. Still takes just 10-12 sec to boot into desktop and run hundreds of weird services on my slightly older i7-6700 with SATA SSD


----------



## aht0 (Oct 24, 2020)

Boot is plenty fast on SATA SSD and even faster on NVME SSD's.  Main time is spent on hw detection,  not on service execution


----------



## kpedersen (Oct 24, 2020)

Doesn't Linux run many startup tasks in the background now? So even though you may be looking at a pretty login screen, many of the services are still loading.
Just like Windows you can see this in services.msc. They call it "Delayed Start". I find both a little pointless. Even on consumer devices like phones because you tend to not restart that much anyway.

Now that you have fixed your misconfiguration with hosts and sendmail, it is surely quite an acceptable boot time now?

10 seconds vs 6 seconds is barely enough time for me to take a sip of coffee. Sure, you can cut the Linux boot time down even more by using Wayland rather than Xorg but then you would lose even more functionality.


----------



## ekvz (Oct 24, 2020)

kpedersen said:


> Doesn't Linux run many startup tasks in the background now? So even though you may be looking at a pretty login screen, many of the services are still loading.



Well, define Linux  My installations certainly don't do that but then this means a whole lot of nothing on a broader scale.


----------



## a6h (Oct 24, 2020)

Dutch have a fantastic word to describe this situation: "_Mieren***"_.


----------



## unitrunker (Oct 24, 2020)

The rc init system takes 8 seconds on my Core 2 Duo. Total boot time is longer. Swapping rc for nosh can only improve on the 8 seconds. The rest of the boot time is device discovery, device initialization, and waiting on external services like DHCP. Nosh can do nothing for these other parts of the boot time.


----------



## kpedersen (Oct 24, 2020)

ekvz said:


> Well, define Linux



Hmm, good point. I cannot. Linux is undefined!


----------



## chrcol (Oct 24, 2020)

systemd, is not an example to follow, its a bloated rubbish, on any linux system's I have I put the old system back.

In my view FreeBSD should stick with its simple init system, a faster bootup, is not important, I dont reboot my servers more than once or twice a year usually.


----------



## hruodr (Oct 24, 2020)

How long takes android in a smartphone to boot?


----------



## drhowarddrfine (Oct 24, 2020)

ono said:


> but this is different subject


Really bad example to use from six years ago about one person's problem that no one else could understand.


ono said:


> 10 sec may be not that much, but same machine Arch Linux 5.9 takes 6 seconds to Xorg SDDM graphical login prompt.


You aren't comparing apples to apples. Is Arch doing the same things FreeBSD is doing? Don't know.


ono said:


> Of course one may argue that booting faster is not a top priority, but on other hand if you need to upgrade kernel it is nice to have shortest possible reboot downtime.


How many times a day do you upgrade your kernel? Maybe there is a far different issue going on with this user than being let on? Your priorities seem to be wildly misplaced.


----------



## ralphbsz (Oct 24, 2020)

The answer is: It depends. For many users (in particular single-user computers that are running a GUI), the init (rc, systemd, ...) part of boot is irrelevant. For many server applications it is irrelevant. For some applications it is highly relevant. Examples: kernel developers who reboot every few minutes. Large server farms, where uptime costs money, in particular where servers need to be regularly rebooted (for safety, upgrade, regulatory reasons). Systems that are sort of real-time, where reliable re-booting in 10 or 30 seconds removes the requirement for a hot standby machine. Simply globally saying "I don't care about faster boot, therefore FreeBSD doesn't need to work on it" is wrong. But saying "I greatly care about faster boot, therefore FreeBSD needs to work on it" is just as wrong. This is not a question of absolutes, not black and white.


----------



## ono (Oct 24, 2020)

drhowarddrfine said:


> ono said:
> 
> 
> > but this is different subject
> ...


That was not an example and was not intended to be used as argument. I simply had the same problem with freshly installed FreeBSD spending 30 sec on boot on preparing sendmail and someone in this thread mentioned sendmail as a potential culprit of slow boot.



drhowarddrfine said:


> You aren't comparing apples to apples. Is Arch doing the same things FreeBSD is doing? Don't know.


I know. This is different operating system, different kernel. Nevertheless I was just giving my first impression.



drhowarddrfine said:


> How many times a day do you upgrade your kernel? Maybe there is a far different issue going on with this user than being let on? Your priorities seem to be wildly misplaced.


Boot time is not my top priority, but care that things work as quick as possible/feasible. I was simply browsing FreeBSD forums looking for answer why sendmail start is stuck for 30 sec and came across this thread and another one from six years ago.

I have read through this thread (that went unfortunately bit off topic at the end). Nevertheless the reason I posted here was that I wanted to defend mjollnir's arguments that some computer users (myself) care if operating system boots quickly as there was lot of opposition saying that operating system startup speed is not relevant.

I know that original proposed idea was to use _nosh_ for faster daemon startup. But except the problem of sendmail hostname lookup problem, I did not experience problem with daemon startup speed. My impression was that initial hardware and USB enumeration is what take bit long on FreeBSD.

Again, this is not criticism of FreeBSD, it is just sharing an impression of regular Linux/macOS/Windows user. NOTE: macOS is neither booting very fast.


----------



## drhowarddrfine (Oct 24, 2020)

ralphbsz said:


> saying "I greatly care about faster boot, therefore FreeBSD needs to work on it" is just as wrong


Exactly my point.


ralphbsz said:


> For many server applications it is irrelevant. For some applications it is highly relevant.


What do elephants have to do with this?


----------



## Jose (Oct 24, 2020)

hruodr said:


> How long takes android in a smartphone to boot?


Right? Especially when there's an update. I should time my phone the next time this happens. I betcha it's more than 10 seconds.


----------



## Jose (Oct 24, 2020)

anonymous9 said:


> If nothing evolves, you'll have an AMC Gremlin when the rest of the world has a Jaguar XJ 50 luxury sedan.


Change doesn't always bring progress.


----------



## kpedersen (Oct 25, 2020)

anonymous9 said:


> I'm indifferent to systemd because I have used AIX and Solaris which have had essentially what systemd is, before there was systemd.



Didn't AIX move to SysV-like init system with release 4?

I do find it quite amusing that the Linux community was always jeering at Solaris's SMF since 2005. You could probably even backtrack through some forums and see some of their typical arrogant "why not use..." threads even then.
But yes, I believe Systemd is modelled after it. However one of the reasons I chose BSD rather than Solaris is because I always found SMF heavy, inflexible and over engineered. And even that had much less responsibility than systemd does now.


----------



## drhowarddrfine (Oct 25, 2020)

kpedersen said:


> I do find it quite amusing that the Linux community was always jeering at Solaris's SMF since 2005.


It must be noted that 80% of all Linux users are those who only use it as a Windows replacement and a large percentage of those on most Linux forums are the young and inexperienced.


----------



## getopt (Oct 25, 2020)

drhowarddrfine said:


> It must be noted that 80% of all Linux users are those who only use it as a Windows replacement and a large percentage of those on most Linux forums are the young and inexperienced.


I do find it quite amusing how an retired elderly is trying to lash out on young people who try to escape the Microsoft eco-system.

It also must also be noted that the present youth is much more experienced regarding the digital technologies than some old trolling men ever will be.

"There is no law against hypocrisy." (Ruth Bader Ginsburg)


----------



## hruodr (Oct 25, 2020)

ralphbsz said:


> Simply globally saying "I don't care about faster boot, therefore FreeBSD doesn't need to work on it" is wrong. But saying "I greatly care about faster boot, therefore FreeBSD needs to work on it" is just as wrong.



Systemd does not reduce the boot time, only dissimulates it. Something different would be to
make the device probing faster. But everything has a price. Programming means always to make
a compromise between very different things like speed, footprint of executable, readability of
source, easiness of making changes in source, easiness to use, functionality, etc. You cannot
have all.


----------



## drhowarddrfine (Oct 25, 2020)

getopt said:


> I do find it quite amusing how an retired elderly is trying to lash out on young people who try to escape the Microsoft eco-system.


Calling me retired and elderly shows how you know nothing about me. Now I'm wanting to question your age and maturity.


getopt said:


> It also must also be noted that the present youth is much more experienced regarding the digital technologies than some old trolling men ever will be.


And the Nielson Norman Group would educate you otherwise. I'll try and find a link to one of their many articles that show just the opposite.

But if your intention is to put me down and insult me, as you seem to do a lot on this forum lately, I might just ignore you.

And for that reason, I'm only going to post the first one I found, but there are more about users older than this:
Designing for Teens


> *Summary:* Teens are (over)confident in their web abilities, but they perform worse than adults. Lower reading levels, impatience, and undeveloped research skills reduce teens’ task success and require simple, relatable sites.


----------



## drhowarddrfine (Oct 25, 2020)

ono said:


> I was simply browsing FreeBSD forums looking for answer why sendmail start is stuck for 30 sec


I forgot to reply to this earlier. My sendmail is not stuck for 30 seconds so I don't understand the problem. We used sendmail on all our servers (about ten) back when I ran a small web dev company.


----------



## getopt (Oct 25, 2020)

drhowarddrfine said:


> Calling me retired and elderly shows how you know nothing about me.


I had no other choice from that what you wrote here in the past. But please, feel free to give us an upgrade on that one.


drhowarddrfine said:


> And the Nielson Norman Group would educate you otherwise.


You may share your source of education here. But please do not expect that what may fit you, is sufficient for "education" to others.


drhowarddrfine said:


> But if your intention is to put me down, as you seem to do a lot on this forum lately, I might just ignore you.


I'm not at all interested in you personally. I only react to sentences readable here.


----------



## hruodr (Oct 25, 2020)

drhowarddrfine said:


> My sendmail is not stuck for 30 seconds so I don't understand the problem.



I think the OP mentioned it. Sendmail starts very fast. Perhaps it is an incorrect configuration,
perhaps it tries to get info from DNS and times out after a while.


----------



## getopt (Oct 25, 2020)

drhowarddrfine said:


> Designing for Teens


You lashed out on the young using "Linux" and you called those on Linux forums "inexperienced".

Now after being criticized you want to justify your opinion with a study on 100 users between the ages of 13 and 17 which were called "wired teens" there. The study is about website usability and on how to improve Webdesign for a better commercial targeting on this group.

Now how comes that you apply these findings for young Linux forum users?
Don't you see the difference?


----------



## zoujiaqing (Oct 26, 2020)

unitrunker said:


> The rc init system takes 8 seconds on my Core 2 Duo. Total boot time is longer. Swapping rc for nosh can only improve on the 8 seconds. The rest of the boot time is device discovery, device initialization, and waiting on external services like DHCP. Nosh can do nothing for these other parts of the boot time.


 Is it feasible to use parallel computing to find the device?


----------



## hruodr (Oct 26, 2020)

zoujiaqing said:


> Is it feasible to use parallel computing to find the device?



Yes. You can also use a supercomputer to find the devices of your desktop.


----------



## mark_j (Oct 26, 2020)

zoujiaqing said:


> Is it feasible to use parallel computing to find the device?


You mean parallel process? Sure, but then usage of those devices would still need to be delayed until discovery. Eg, you can't mount a USB device not yet found. Very feasible but unduly complex, IMO.


----------



## unitrunker (Oct 28, 2020)

zoujiaqing said:


> Is it feasible to use parallel computing to find the device?


Build your own kernel with only the drivers you actually need.


----------



## grahamperrin@ (Jan 21, 2022)

ono said:


> Hi there, I have just created an account to respond to this thread. I was never FreeBSD user, however I regularly use Linux, Mac and Windows. I was recently playing with FreeBSD and the first thing that I have noticed was that it takes pretty long to boot it into working console in vanilla system. I was curious if this is normal, then I found this thread. Therefore I'd like to defend mjollnir arguments, that it does matter how long it takes to boot or reboot the OS, at least this is the first thing you notice when you try FreeBSD.



From <https://www.freebsd.org/status/report-2021-07-2021-09/#_boot_performance_improvements>:



> Boot Performance Improvements​…
> Colin Percival is coordinating an effort to speed up the FreeBSD boot process. …



TSLOG boot profiling​
flame graphs
a little advice from Colin Percival


----------

