Bsdinit is a more human approach to init because it simplifies the process of knowing what to load and when.

Take Slackware's init which is a BSD style init system. It uses instance checks to detect for execution ability of scripts and then loads them as needed in sequence. It really simplifies the process significantly by eliminating needless repetitive symlinks with numerical listings.

Technically BSD style is easier to maintain but sysvinit is the core standard for GNU/Linux, but in reality, neither method is superior to the other, just like every init system out there is not truly superior to the next.

Unless the initialisation process is a criterion one uses to choose the best distribution. "I do not like this (whatever), but it comes with or is part of the system" does not make sense. If one does not like a particular part or aspect of the system, it makes more sense to not use that system and use a different system that fits one's needs/preferences better.

1 members found this post helpful.

That's exactly what I meant. A user can't change how a particular distro is built, unless he builds it himself. He can choose which distro to use, though.

Sorry as I'm deterring this old thread, but this is to bring some sort of synthesis here ;-)

The SystemIII/V init process has been already be described in details higher in this thread (Though if my memory isn't too bad, SystemIII originally had rcN scripts specified by /etc/inittab that launched rcN.d hosted scripts).

actually, today, a lot of GNU/Linux systems leave original SystemIII/SystemV init process in favor of upstart, systemd or others.
Some GNU/Linux distros are resisting, as Slackware, Arch, Gentoo do.
There is a controversy around thes new init systems, notably concerning systemd. This one seems to willing to do all including what is not of the init resort. Lot of sysadmins shouts thet it breaks UNIX philosophy (and rightminded philosophy) of "one simple program do its own job and well ; several collaboring little/simple programs do a complex task together". Plus, lot of sysadmin points the binary architecture of systemd as an opaque one compared to scripted programs of the old legacy architectures (SysV and BSD).
One of the idea of these switch off the legacy init processes was a faster boot machanism with paralelization in mind. But IMHO, boot process is an infinitesimal part of the operational state of our systems. Our systems have to be performant, but not as they boot, but as they are servicing multiuser and networking operations ...
Lets have some deeper meditation before switching !

If we look at BSD systems, it originally have choosen simplicity with central config variable-based files and rc.* scripts, although this had lead to a rather monolithic init process (Though some UNIX systems used rcN.d style with BSD central config file, as HPUX/9000 did).

NetBSD (since 1.5 if my memory is alive) has polished this original old BSD init process with the introduction of rc.d-based systemV style init directory BUT with BSD philosophy in mind : no symlinks pointing to facilities (services/daemons for the most part) management scripts. Instead, all these management script include, as comments, some provide/require directives and a rcorder program is delegated by /etc/rc to order the execution of these management scripts. All these are yet controled by the central config files /etc/rc.conf (including "defaults" and "local" ones).

IMHO, this is the best of the two worlds : we keep the old architecture with clean and central conf files, but we polished it, giving the possibility to start/stop facility by facility (this was what BSD lacks from SysV).
FreeBSD as adopted it, not sure concerning OpenBSD.
MacOSX as a counterpart has choosen launchd, but don't know how it is architectured.
Solaris switched also to SMF ; don't know about (since I left from Solaris when it had be acquired by Larry Ellison :-( ).

So, to conclude, IMHO, it is too early to say if all these switches from legacy init processes would give a worthy advantage to systems. Will stick to NetBSD "rc-NGish" one and continue to observe all the other evolutions ...