Exactly. We have an excellent development team that is charting our course. Life is too short to fixate on what might be.

Because it's a difficult problem to correctly and consistently handle asynchronous events in a multi-threaded/multi-core system.

If your system's configuration never changes after you start it, then, yeah, you find the order of initialization of "stuff" that works for that system and you're good until something changes (replace the drives with faster ones so the timing of events change and so on).

The upstart documentation talks about the pros and cons for various init systems.

1 members found this post helpful.

i'm guessing you are talking about an init
i'l also guess you are thinking about dependencies between services

it's not that hard, you just make a dependency tree like bout systemd and upstart do
you can even get events from the kernel to track processes
and even go so far as to pre-load whatever is coming up (that none do)
it should not be that hard

1 members found this post helpful.

I'd welcome some blend of Slackware with OpenBSD as best representatives of both worlds. I see no reason to count in only eudev, upstart & similar not-yet-mature alternatives to systemd. Find BSD init system still enough for current demands, even Slackware's way of SysV-init with BSD-like init scripts. Even CGroups won't require systemd to initialize. One of the most common logical delusions - limited options aka "false dilemma".

1 members found this post helpful.

Have you ever Google Patrick work on the init. Have you ever taken time to see his accomplishments And his contributions to the rc.sysvinit.
Look Pat has been maintaining the init for a long time. It is not about the init it is about if software developers like Gnome are going
to make it a dependency because they are to lazy to maintain there own work.

Linus Travolds has made it clear systemd is not about the kernel and leaves it up to the O/S developers and maintainers to do there own thing.
Pat has been very clear on this matter. His last words are I do not see happening to Slackware.

there are many programs that can use pulse audio and make it a dependency but do you see that in Slackware no.

In all truth if systemd would do what they would like it to do or their wish list or mission statement it would be nice.

Just remember the world is not flat. and it is not perfectly round. And far less stable then Slackware. So join the church and get your slack back.

2 members found this post helpful.

I'm guessing that you didn't bother to read the link.

i did...
first, "If your system's configuration never changes after you start it, then, yeah, you find the order of initialization of "stuff" that works for that system and you're good until something changes (replace the drives with faster ones so the timing of events change and so on)."

so you pointed for me to read
"However, consider how such a system would approach the problem of dealing with a user who plugs in an external monitor. Maybe we'd like our system to display some sort of configuration dialogue so the user can choose how they want to use their new monitor in combination with their existing laptop display. This can only be "hacked" with a dependency-based init system since you do not know when the new screen will be plugged."

that i already covered partially with
"you can even get events from the kernel to track processes"
s/processes/events/

anyway this has not much with init, unless you make init an arbitrator too instead of just being an init
even better arbitrator would be a daemon, like udev, that gets those events and runs whatever (like udev)
it can even track processes like daemons without being pid 1 (low overhead with ptrace over netlink, can even be mmaped afaik)

control over a running system should be, if you ask me, separated from starting that system
(starting being configuring a state machine(the kernel) and running a couple processes)
yet people think it has to be one and the same

1 members found this post helpful.

ConsoleKit and PolicyKit are still the default support on desktop environments and are the segregated stand-alones of their systemd counterparts. They were only deprecated by their maintainers who wanted to force the issue of systemd. That argument on their deprecation has never held water.

As far as BSDinit/SysVinit, yes there are some flaws, but to be honest, those flaws are POV only. Other than that sysvinit and bsdinit are foolproof except to people who are shell-scripting-challenged. Even Init systems like s6 and Runit use shell scripts with basic command structures equal to, similar, and derived from SysV and BSD init scripts. While the "hack" they mention to load daemons in parallel is crude, the fact of the matter is, it works, and if you script properly you can use dependency trees in parallel with linear loading per branch and have the same functionality. Runit, s6, and OpenRC do just that. That's technically not even a hack, but proper scripting methods that any knowledgable system administrator worth their salt learns in CompTIA Linux+ classes.

1 members found this post helpful.

I didn't feel like posting in another systemd thread, but I felt that something was warranted:

When I read about systemd, I feel that it has a particular target - Linux as an application. When I look at other new developments in its class, I see things like cgroups, btrfs, openstack support, xen and kvm, and a ton of other projects. When I look at them all together, they seem like they are heading towards massive virtualization, to the point that the operating system is, top to bottom, made to be run as an application. I'm not certain why traditional init would hamper that, exactly, but I can see why systemd and CoreOS would help.

This doesn't mean that we need to use software that insists on systemd. It doesn't make sense that software would depend on systemd at all, aside from some enterprise bits. Even if the entirety of the Linux community decided to jump on the CoreOS ship, the BSDs, Apple and Microsoft would still exist, and still hold market share.

I prefer the UNIX ways of small tools passing messages through pipes and scripts, so I prefer sysvinit. Then again, I don't regularly deploy thousands of Linux servers, so I've never dealt with the kind of problems I bet CoreOS is made to tackle. In any case, I trust Pat's judgement - it is far more experienced than mine.

Just my two cents.

PS. I just went to the CoreOS website, and the title of the page is "CoreOS is Linux for Massive Server Deployments". Boy, do I feel like a weenie now.

Did they learn how to easily have something "watchdog" their services in the same class? Why isn't that in the framework already if it *is* so easy?

Here's another quote on /. in reply to your "dweeb":
I think that pretty much sums up the issue, and does so quite nicely. Nothing more needs to be said on the issue, IMHO.

1 members found this post helpful.

A nice example of how to write an init system
Demystifying the init system

2 members found this post helpful.

Because they actually did, or at least tried

2 members found this post helpful.

biggest problem i had when writing a shell was learning ioctl (so backspace would work)
looking at rc.S/M, a basic shell is not far from a full init

setting environment variables is patching the environment variable (just a long string)

starting things is fork + exec + however you want to deal with the child (usually wait)
k first you have to tokenize the arguments you start it with (that is make argv and argc; environ pointer is also there somewhere, cant remember)

setting random seed is just write a file to /dev/urandom
storing it is reverse

/bin/mount is not even needed as there is mount() (unless you cba to parse fstab)
same for powering off and probably most other things

logic that glues it all is Boolean if-else
and so on

so its just basic parsing, playing with strings of text and some logic
parallel starting adds making a tree

you can even go the suckless init way and just spawn shell scripts to do the parsing for you http://git.suckless.org/sinit/tree/

could even be fun to do if it weren't that easy

PS idk about udev and not knowing makes it look a bit complicated, but i'm sure it's not something that needs a special kind of programmer

edit: forgot about modules; same thing, finit_module() or modprobe

What makes an init hard is getting things in the proper order.

With a shell script it is easy - the order is specified by the order of commands in the script.

With systemd, it is next to impossible. Systemd uses a random scheduling order, with a multi-level dependency network that has to be analyzed by systemd. If you miss some obscure dependency, the system may hang, or that particular service may not work (before, after, requires, ...).

The reason systemd has so much trouble is that it has to assume the service is ready when it starts it. This is NOT true. Before the service is ready it has to process its configuration file(s). In all other init systems (sysVinit, BSD, and slackware) the completion of this phase is when the service forks/becomes a daemon process, and the parent process exits. Systemd doesn't have that. To provide the equivalent each service must be modified to send systemd a message. In the case of networks, it becomes a two level thing - Systemd has to have NetworkManager send a message... but NetworkManager can't always know if the network is up either - specifically, in the case of DHCP. This can take up to around 30 seconds (depending on the dhcp server). Yet, NetworkManager has to assume it is ready when dhclient is started... Thus the message back to systemd indicating the network is ready is wrong.

This incorrect assumption allows other processes that may need the network to run... and fail.

The rest of the problem is assuming that one service can analyze all the dependencies. Here you get multiple dependencies - between services like apache, database servers, the network... To get those right requires each service to be modified to send back notifications to systemd...

And that makes the service incompatible with any other init because systemd just doesn't work well with other init systems, and is nonportable.

And worse, the developers don't care.

7 members found this post helpful.