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.