I know less about the new Linux ones, but a brief summary of the two big "traditional" ones:
Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then it enters multi-user mode, then it initializes network services, then (optionally) it enters full application mode. These are supposed to be discrete, semantically meaningful boot levels that you could purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to runlevel 1. Dependencies are handled by a mixture of those runlevels, and scripts that are run in alphabetical order within run levels. That ordering (unlike runlevels) is not supposed to be meaningful to the sysop, but just necessity-based: some stuff depends on other services already being started, even if conceptually you want them all "at once". The convention is to prefix startup-script filenames with numbers that effectively serve as priorities within a runlevel.
BSD systems traditionally use their own "BSD init". There are no runlevels, though there is still a separate "single-user mode" for maintenance. In classic BSD startup was just one very large shell script in /etc/rc. In later versions it was augmented by an /etc/rc.local script that allowed local modifications to be made without mucking with the main script. Modern BSDs (starting with NetBSD, later adopted by the others) modularized it, with an /etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports). This differs from SysV init in that it still has no run levels, and rather than explicit ordering via filename sorting, has dependency-resolution ordering via semantic comments at the top of each script that are parsed and resolved by rcorder(8) (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8). Afaik this system, originating in NetBSD, was the first dependency-based startup system on a free Unix (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
Many Linux vendors have decided that SysV Init is not such a nice system nowadays, because it involves maintaining fairly complex scripts with edge cases that have to be handled in every script through error-prone boilerplate, and an explicit global startup ordering: all programs that can be installed on Debian and need startup must be assigned an integer that fully specifies their position in the startup sequence relative to all other programs that might also be installed. Runlevels as a mechanism also seem pretty unhelpful for most uses people have nowadays. Instead there is a hope for some kind of dependency-based startup. But the big disagreement is over what to replace it with. It is also complicated by other changes that are happening in parallel and which are caught up in it. For example, Linux's 'cgroups' resource-control mechanism has long been in the kernel, but not widely used by userspace tools, and there are moves to sort out this situation by essentially letting the init system also own resource assignments, which would more tightly couple those components. This is probably where the big philosophical differences come in.
Services are defined in XML files called manifests, which specify dependencies (including filesystems and network connectivity), the user and group to run as, timeouts for start/stop, and a bunch of other stuff.
The cool part is that, while the manifest files are static, SMF doesn't actually use them directly. The service definitions get slurped into a DB, and you can change properties (such as the whether or not the service is enabled, the user to run as, and pretty much anything else the manifest author thought of) on the fly, without editing a manifest or mucking with symlinks.
SMF also starts services in parallel (Solaris/OpenSolaris boot really, really quickly), and services that die are automatically restarted (so long as they're dying again too quickly).
Debian already has dependency based boot based on magic comments at the top for their syvinit scripts. The program used is called insserv and is something they got from Suse.
Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then it enters multi-user mode, then it initializes network services, then (optionally) it enters full application mode. These are supposed to be discrete, semantically meaningful boot levels that you could purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to runlevel 1. Dependencies are handled by a mixture of those runlevels, and scripts that are run in alphabetical order within run levels. That ordering (unlike runlevels) is not supposed to be meaningful to the sysop, but just necessity-based: some stuff depends on other services already being started, even if conceptually you want them all "at once". The convention is to prefix startup-script filenames with numbers that effectively serve as priorities within a runlevel.
BSD systems traditionally use their own "BSD init". There are no runlevels, though there is still a separate "single-user mode" for maintenance. In classic BSD startup was just one very large shell script in /etc/rc. In later versions it was augmented by an /etc/rc.local script that allowed local modifications to be made without mucking with the main script. Modern BSDs (starting with NetBSD, later adopted by the others) modularized it, with an /etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports). This differs from SysV init in that it still has no run levels, and rather than explicit ordering via filename sorting, has dependency-resolution ordering via semantic comments at the top of each script that are parsed and resolved by rcorder(8) (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8). Afaik this system, originating in NetBSD, was the first dependency-based startup system on a free Unix (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
Many Linux vendors have decided that SysV Init is not such a nice system nowadays, because it involves maintaining fairly complex scripts with edge cases that have to be handled in every script through error-prone boilerplate, and an explicit global startup ordering: all programs that can be installed on Debian and need startup must be assigned an integer that fully specifies their position in the startup sequence relative to all other programs that might also be installed. Runlevels as a mechanism also seem pretty unhelpful for most uses people have nowadays. Instead there is a hope for some kind of dependency-based startup. But the big disagreement is over what to replace it with. It is also complicated by other changes that are happening in parallel and which are caught up in it. For example, Linux's 'cgroups' resource-control mechanism has long been in the kernel, but not widely used by userspace tools, and there are moves to sort out this situation by essentially letting the init system also own resource assignments, which would more tightly couple those components. This is probably where the big philosophical differences come in.