What's happening to FreeBSD?

[hruodr]

We need to have a parallel service framework. And people need to be able to use the old decades-proven script system.

Who is "we" and who is "the people". You speak like a politician from the elite ("we") that care for "the people".

I indeed do not need "a parallel service framework", do not even know for what can it be good,
but politicians like to tell others what they need.

If I see any necessity to touch rc, then, to make it simpler, not more inflated. rc is run at a critical moment and is hence
a very critical program.

This discussions about rc are of the level of the ones about "desktop".

 

[T-Aoki]

Who is "we" and who is "the people". You speak like a politician from the elite ("we") that care for "the people".

I indeed do not need "a parallel service framework", do not even know for what can it be good,
but politicians like to tell others what they need.

If I see any necessity to touch rc, then, to make it simpler, not more inflated. rc is run at a critical moment and is hence
a very critical program.

This discussions about rc are of the level of the ones about "desktop".

Putting pararrel service aside, rc.d framework would need to be extended.

Not myself, but there had been question and answers here the forums or any of MLs that need to let behavior of rc.d scripts depending on specific rc.d script exists in /usr/local/etc/rc.d/ and enabled or not.

If I recall correctly, the person asked finally added dummy rc.d script.
But if there's a mechanism to "require only when it exisis and enabled", the port affected can blindly use the mechanism without making users (admins) in panic.

Current rc.d mechanism is good, but not yet perfect.

 

[hruodr]

Current rc.d mechanism is good, but not yet perfect.

rc.d mechanism in OpenBSD is much simpler, and people live with it. Features attract features ad infinitum.

The beginning is: init is first run, it calls rc. The boot process much be comprehensible, reliable,
and that is why simplicity is necessary.

After boot, when the system is running, you can do any non sense as user you want.
Put lua everywhere you want, calculate in parallel what you want, start processes as you want.

All these things seems to come from SVR4. Solaris has also a strange thing like Systemd.

 

[T-Aoki]

rc.d mechanism in OpenBSD is much simpler, and people live with it. Features attract features ad infinitum.

The beginning is: init is first run, it calls rc. The boot process much be comprehensible, reliable,
and that is why simplicity is necessary.

After boot, when the system is running, you can do any non sense as user you want.
Put lua everywhere you want, calculate in parallel what you want, start processes as you want.

All these things seems to come from SVR4. Solaris has also a strange thing like Systemd.

You seem to be missing my point.
"Perfect" does NOT mean "feature rich".

But when ports are allowed to install rc.d script (in separate place, not in /etc/rc.d/ but /usr/local/etc/rc.d/) at the first time (if I recall correctly, it was almost at the same time rc.d mechanism is introduced in addition to /etc/rc.firewall and so on), the assumption that "all possible rc.d scripts are always available without exception" is broken, which (I think) you'd been assuming. rc.d scripts from ports are installed only when the specific port is installed. Not always.

FreeBSD project had chance to allow rc.d mechanism to be base only and introduce different mechanism for anything from ports, but FreeBSD project didn't do so, maybe because to avoid excessive complexities.

So mechanism to take effect only specific rc.d script exists and enabled, but ignored sanely when not enabled nor even nonexistend, without error, is needed feature, but not yet implemented.

Note that I myself didn't noticed such a situation until the question arose.

 

[Zare]

Who is "we" and who is "the people". You speak like a politician from the elite ("we") that care for "the people".

Why are you so negative?
What is meant by "we" is FreeBSD project, the OS needs to have a parallel service framework if it wants to keep being competitive in other than server areas.

"The people" is indeed a general audience using FreeBSD. So me, and you. You use it, I use it, we need to be able to keep on using it unless it is broken, and it isn't. What is meant by this, do not drop current system for new one but have it as an option.

 

[Beastie7]

Who is "we" and who is "the people". You speak like a politician from the elite ("we") that care for "the people".

I indeed do not need "a parallel service framework", do not even know for what can it be good,
but politicians like to tell others what they need.

If I see any necessity to touch rc, then, to make it simpler, not more inflated. rc is run at a critical moment and is hence
a very critical program.

This discussions about rc are of the level of the ones about "desktop".

So you reject something you don't fully understand while being oblivious to the benefits it provides. Mind you, rcd benefits all use cases, not just the desktop.

rc.d is archaic and slow. Managing a bunch of shell scripts as daemons is incredibly tedious and it's lack of fault tolerance is annoying as hell. It's actually one of the few things I'm irritated by in FreeBSD. Troubleshooting confirmative unit files is far easier and less of a headache than trying to traverse someones fscked up rc script.

rcd can't come soon enough. Using this with something like Xmonad will be a breeze.

 

[ralphbsz]

the OS needs to have a parallel service framework

Explain why please.

How much faster does it make boot?

 

[Emrion]

Why are you so negative?
What is meant by "we" is FreeBSD project, the OS needs to have a parallel service framework if it wants to keep being competitive in other than server areas.

"The people" is indeed a general audience using FreeBSD. So me, and you. You use it, I use it, we need to be able to keep on using it unless it is broken, and it isn't. What is meant by this, do not drop current system for new one but have it as an option.

Honestly, and with all the respect, hruodr is right.
You'd better avoid "we" because it implies your point is shared by everyone. You know, it's false.
"I" is more suited in all cases.

 

[hruodr]

So you reject something you don't fully understand

Yes!

If someone tells me that something is necessary, but cannot explain what that something is and justify why it is necessary, I reject it. I do not buy it, be it something edible from the supermarket or a new rc system for FreeBSD. Definitively.

T-Aoki gave a comprehensible justification of why improvements are necessary, and sure improvements are necessary, everything can be improved.

But those arguing like new rc system is necessary never give comprehensive justification of their point. The discussions about rc are at the level of the infinite always recurrent Desktop threads.

 

[CShell]

I'm running on a ZFS system so I should create a new BE before I do anything?

My answer is yes ! BE's and ZFS snapshots have saved my systems more times that I can count.

But the reality is - that's why ZFS is amazing and I why I use ZFS as well.

If an upgrade goes south I can just switch to a known working BE or ZFS snapshot, boot up and then just pretend the bad upgrade never happened. I now have plenty of time to boot up again (in a known working BE or snapshot), figure out what got broke, figure out a fix and go back and apply the fix whenever I have time. This takes away the "down time" and "time pressure" of needing a "FIX NOW !" to fix something.

 

[MG]

Yes!

If someone tells me that something is necessary, but cannot explain what that something is and justify why it is necessary, I reject it. I do not buy it, be it something edible from the supermarket or a new rc system for FreeBSD. Definitively.

T-Aoki gave a comprehensible justification of why improvements are necessary, and sure improvements are necessary, everything can be improved.

But those arguing like new rc system is necessary never give comprehensive justification of their point. The discussions about rc are at the level of the infinite always recurrent Desktop threads.

rc.d and systemd are glorified autoexec.bat+config.sys re-implementations that both seem to not like actual user-independency and add a lot of complexity for no reason. "Learn our documented zoo." Not using it for years. We have 1 script that starts everything after the kernel and proceeds with CLI-login. Nothing except the wanted services themselves stays resident. /etc/rc is the only rc-related thing on the system.
I think all online debates about it are caused by lack of common system-administative knowledge. The sequence to start a list of prefered background services isn't that important. You can start everything manually too. What's the deal? Not having to type so much?

 

[hruodr]

I think all online debates about it are caused by lack of common system-administative knowledge. The sequence to start a list of prefered background services isn't that important. You can start everything manually too. What's the deal? Not having to type so much?

The sequence is important, some services need a previous running, but you know,
in sh there is a difference between ";" and "&&".

In another thread I made a theme about the inflation of tools for managing user and groups. The old way was mainly to
edit files /etc/passwd (/etc/master.passwd) and /etc/group, then appeared the many commands.

BSD has two levels in the booting, System 7 seven, and then came systemd. Also Solaris, System V version 4,
has something similar to systemd.

All this inflation, making things less transparent, seems to point to System V trying to put structure in procedures.

I want to bring another example of BSD vs Linux (System 5). I just configured two oracle free tier VMS,
one with Ubuntu and one with FreeBSD. The first thing I did was to install apache2. Did you see how Debian (Ubuntu)
prepared the configuration files for the apache2 package? The same story, very structured, a lot of commands
meant to take away editing work. Perhaps for big deployments serving many domains an advantage. The price is
the lost of transparency.

 

[MG]

The sequence is important, some services need a previous running, but you know,
in sh there is a difference between ";" and "&&".

It may be important because things rely on eachother or can be up late. it doesn't require a post-kernel startup framework that manages services with dedicated commands. It can be a single script and 1 thread. All system services are backgrounded anyway.

I'm at 500 lines /etc/rc now. It's generated by a build configuration script and universal for amd64 PC.

 

[Zare]

Explain why please.

Of course, glad you asked.

The boot time is a very important factor for service/application servers.
Consider a Linux Kubernetes stack. You really don't care how long does it take for your nodes to start. Runtime nodes, network, storage, whatever. They're supposed to run 99.% uptime yearly anyway.

However if your system topology is based on some decoupled architecture like very popular microservices, load balanced, orchestrated, you need to be able to bring nodes up and down fast to be efficient.

How fast depends on what you need to do. Few seconds is quite OK for "business application" purposes. Imagine egov site which has traffic patterns that depend on what happens in the real world that day. It can have 0 traffic for weeks and then literally be assaulted. It is OK, to hang a few seconds on the first request for a first customer that goes over the line and the system brings up additional resources. The DNS has already sent him to the good node, or the proxy will, whatever, his connection won't break, and the browser or the app probably wont die in few secs.

For stuff that needs to experience high troughput all the time there is a concept of lambda instance where OS boots so fast the service can respond in order of 10s of milliseconds.

When the FreeBSD kernel boots in Firecracker (1 CPU, 128 MB RAM), it now spends 7% of its time running a bubblesort on its SYSINITs.O(N^2) can bite hard when you're sorting over a thousand items. Time to replace the bubblesort with something faster.

This is from Colin Percival 3 years ago, this tweet had 150K likes. I think this was measured in a scenario of evaluating such uses on FreeBSD.

So after the kernel comes the init and this is where the time is also spent. Consider a microservice can "boot" in a second but it needs to wait a minute for OS to come up.

In order to stay competitive with Linux in the enterprise/cloud/whatever FreeBSD has to hunt some performance improvements in boot time although regular users might not have direct impact from it. Things have changed, this is not the 00s, server means something bit different today.

I can also tell you that this is the exact reason why I cannot push for FreeBSD in my organization. Because of its "batteries included" approach of whole OS, FreeBSD pods are a joy to work with, and with pkgbase we could also make thin pods that don't have compilers etc. but still have all the FreeBSD networking tools in. But - I can't, because FreeBSD is not as fast as Linux to boot.

Also in my experience when talking about boot time measurement is always on something "normal" but in most cases organizations conserve resources and run pods with minimal available CPU/mem and stuff - comes out as "fast" Linux booting in OK time, and "OK" FreeBSD taking too long.

Honestly, and with all the respect, hruodr is right.
You'd better avoid "we" because it implies your point is shared by everyone. You know, it's false.
"I" is more suited in all cases.

With all due respect, you are syntatically parsing my sentences and cherrypicking non-issues.

I have explained what I meant. And I have elaborated my standpoint to Ralph above.

 

[Emrion]

What is meant by "we" is FreeBSD project, the OS needs to have a parallel service framework

No, sorry. You are not the FreeBSD project. You are not "the people". You have a technical point besides and I'm not forcely disagree with it.

I read too many guys explaining me what FreeBSD people want, don't want. And finally, found out that a large part of users want the opposite. So, it's a huge issue, but a non-technical one.

 

[Zare]

Emrion, I don't care for this 'problem' of yours.

 

[Emrion]

Emrion, I don't care for this 'problem' of yours.

Not mine, yours.

 

[mer]

Almost sounds like we're turning into a Linux forum....

 

[bvdw78]

Zare you seem to be contradicting yourself somewhat, or I am misreading what you're trying to say. Something like a serivce jail is tiny. It doesn't orchestrate the startup of a whole amusement park full of background services, or it defeats its own purpose. Let's take an Nginx jail for example. It boots, has nginx_enable="YES" in its /etc/rc.conf. That's the only thing it fires up at boot. Whatever takes a long time about this is on Nginx from that point on. Sure it could be made to start even faster, but what would the actual tangible return on that investment be here? It's already sub-second fast. If it matters that much to you, you wire your own startup into your jail. FreeBSD allows you to do that fairly cleanly.

An underlying jail host machine could have a much more expansive /etc/rc.conf and that could indeed take long, but those shouldn't be in the line of fire anyway. Host goes down, the others keep the business up and running. Standard maintenance work, you know the drill. Watching a ProLiant go through hardware POST is painful anyway.

So while it sure would look slick if my FreeBSD desktop could boot fast, that's mostly aesthetics. My Windows 11 work laptop from last year boots up slower than the FreeBSD desktop from 2018 that sits right next to it. And that desktop has a bunch of local jails and whatnot that it runs for my geek interests, quite comparable to what the laptop is doing in terms of background stuff. Sure Arch Linux gets up and running a lot faster, but honestly.. I don't see the appeal in absorbing the cost of achieving that.

 

[baaz]

We need to have a parallel service framework. And people need to be able to use the old decades-proven script system.

I think it is proven by the patch I posted above, these two are not mutually exclusive.
All that is needed is basically 2~ extra for loops in /etc/rc and that's it.

I'm currently posting this from a "parallely booted" system with a fixed version of the same patch.
The boot speed gains from a "parallel boot" are severely overblown in this thread, yes it does shave off a few seconds in some configurations, but it doesn't magically achieve millisecond boot times or anything like that.

Much more can be gained by just pruning the start-up services to the ones you actually need, a custom trimmed down kernel for your hardware, lower SCSI_DELAY and ...