What init system was used in early Linux distributions?











up vote
11
down vote

favorite












Nowadays there is quite some debate and controversy over whether Linux distributions should use systemd, sysvinit, GNU Shepherd etc. But all these systems are relatively new - for these examples dating back to 2010, 2008 and 2003 respectively.



Since the whole point of the term "GNU/Linux" is that GNU was (at that time) a complete operating system without a kernel, what init system was used in early distributions, for example in the 90s? It seems that init (or equivalent) is a pretty fundamental thing to have in any UNIX-based system. Also, what was wrong with the systems used at that time that led to the creation of systemd et al?










share|improve this question







New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Are you sure that sysvinit was introduced as late as 2008?
    – Jonathon Reinhart
    19 hours ago










  • systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
    – pipe
    7 hours ago















up vote
11
down vote

favorite












Nowadays there is quite some debate and controversy over whether Linux distributions should use systemd, sysvinit, GNU Shepherd etc. But all these systems are relatively new - for these examples dating back to 2010, 2008 and 2003 respectively.



Since the whole point of the term "GNU/Linux" is that GNU was (at that time) a complete operating system without a kernel, what init system was used in early distributions, for example in the 90s? It seems that init (or equivalent) is a pretty fundamental thing to have in any UNIX-based system. Also, what was wrong with the systems used at that time that led to the creation of systemd et al?










share|improve this question







New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Are you sure that sysvinit was introduced as late as 2008?
    – Jonathon Reinhart
    19 hours ago










  • systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
    – pipe
    7 hours ago













up vote
11
down vote

favorite









up vote
11
down vote

favorite











Nowadays there is quite some debate and controversy over whether Linux distributions should use systemd, sysvinit, GNU Shepherd etc. But all these systems are relatively new - for these examples dating back to 2010, 2008 and 2003 respectively.



Since the whole point of the term "GNU/Linux" is that GNU was (at that time) a complete operating system without a kernel, what init system was used in early distributions, for example in the 90s? It seems that init (or equivalent) is a pretty fundamental thing to have in any UNIX-based system. Also, what was wrong with the systems used at that time that led to the creation of systemd et al?










share|improve this question







New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











Nowadays there is quite some debate and controversy over whether Linux distributions should use systemd, sysvinit, GNU Shepherd etc. But all these systems are relatively new - for these examples dating back to 2010, 2008 and 2003 respectively.



Since the whole point of the term "GNU/Linux" is that GNU was (at that time) a complete operating system without a kernel, what init system was used in early distributions, for example in the 90s? It seems that init (or equivalent) is a pretty fundamental thing to have in any UNIX-based system. Also, what was wrong with the systems used at that time that led to the creation of systemd et al?







history boot linux






share|improve this question







New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked yesterday









Kidburla

1564




1564




New contributor




Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Kidburla is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1




    Are you sure that sysvinit was introduced as late as 2008?
    – Jonathon Reinhart
    19 hours ago










  • systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
    – pipe
    7 hours ago














  • 1




    Are you sure that sysvinit was introduced as late as 2008?
    – Jonathon Reinhart
    19 hours ago










  • systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
    – pipe
    7 hours ago








1




1




Are you sure that sysvinit was introduced as late as 2008?
– Jonathon Reinhart
19 hours ago




Are you sure that sysvinit was introduced as late as 2008?
– Jonathon Reinhart
19 hours ago












systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
– pipe
7 hours ago




systemd is hardly "retro" so design questions about it is a question for a different stack exchange (or none, it has been answered and debated ad nauseam elsewhere)
– pipe
7 hours ago










3 Answers
3






active

oldest

votes

















up vote
18
down vote













Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.



This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.




Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.






share|improve this answer























  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
    – Kidburla
    yesterday






  • 3




    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
    – Stephen Kitt
    yesterday










  • Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
    – Ross Ridge
    22 hours ago






  • 1




    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
    – JdeBP
    15 hours ago










  • There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    15 hours ago


















up vote
2
down vote













System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.



Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.



Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.



This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.



This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.






share|improve this answer










New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
    – JdeBP
    15 hours ago










  • Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
    – Gunter Ohrner
    7 hours ago


















up vote
1
down vote














Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:




  • Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...

  • There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).

  • Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.

  • As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...


At the end of the day, it was just natural progression to look for more capable systems.






share|improve this answer

















  • 1




    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
    – Stephen Kitt
    19 hours ago






  • 1




    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
    – Jörg W Mittag
    19 hours ago













Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});






Kidburla is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8289%2fwhat-init-system-was-used-in-early-linux-distributions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
18
down vote













Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.



This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.




Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.






share|improve this answer























  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
    – Kidburla
    yesterday






  • 3




    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
    – Stephen Kitt
    yesterday










  • Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
    – Ross Ridge
    22 hours ago






  • 1




    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
    – JdeBP
    15 hours ago










  • There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    15 hours ago















up vote
18
down vote













Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.



This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.




Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.






share|improve this answer























  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
    – Kidburla
    yesterday






  • 3




    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
    – Stephen Kitt
    yesterday










  • Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
    – Ross Ridge
    22 hours ago






  • 1




    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
    – JdeBP
    15 hours ago










  • There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    15 hours ago













up vote
18
down vote










up vote
18
down vote









Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.



This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.




Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.






share|improve this answer














Early Linux distributions, including MCC and TAMU, used Miquel van Smoorenburg’s sysvinit package (which was originally written for Minix in February 1992 and ported to Linux in July 1992; it is now maintained on Savannah). This came with built-in examples for two styles of init setup, both based on /etc/inittab and runlevels: “simple” RC, with a few monolithic rc scripts taking care of the various runlevel transitions, and System V-style init.d scripts.



This continued in Slackware and Debian, the oldest surviving distributions: Slackware used an RC-style setup on top of sysvinit, Debian an init.d-style setup also on top of sysvinit.




Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




That’s a rather contentious topic, opinion-based, so I won’t answer it here. JdeBP has written an FGA on the topic which provides some insight.







share|improve this answer














share|improve this answer



share|improve this answer








edited 23 hours ago

























answered yesterday









Stephen Kitt

33.6k4138155




33.6k4138155












  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
    – Kidburla
    yesterday






  • 3




    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
    – Stephen Kitt
    yesterday










  • Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
    – Ross Ridge
    22 hours ago






  • 1




    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
    – JdeBP
    15 hours ago










  • There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    15 hours ago


















  • Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
    – Kidburla
    yesterday






  • 3




    The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
    – Stephen Kitt
    yesterday










  • Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
    – Ross Ridge
    22 hours ago






  • 1




    That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
    – JdeBP
    15 hours ago










  • There is more history in A history of modern init systems (1992–2015).
    – JdeBP
    15 hours ago
















Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
– Kidburla
yesterday




Interesting, I can't find any reference to sysvinit dating back to before 2008, hence my question... Is there a homepage for sysvinit?
– Kidburla
yesterday




3




3




The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
– Stephen Kitt
yesterday




The current “homepage” is here. In the nineties it was distributed on TSX-11 and SunSITE; see for example this 1996 copy. Current versions still have a changelog going back to 1992.
– Stephen Kitt
yesterday












Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
– Ross Ridge
22 hours ago




Strangely the "FGA" you linked ignores the biggest problem with System V style init systems and the most compelling reason to use systemd instead: the old scripts were slow, and systemd can boot systems much faster.
– Ross Ridge
22 hours ago




1




1




That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
– JdeBP
15 hours ago




That's because boot times of great justice is a fallacy, for reasons that M. Kitt has already explained on this page, and because changing /bin/sh to the Debian Almquist shell in the middle-to-late 2000s had (as contemporary doco and commentary records) more impact on boot speed than changing init systems.
– JdeBP
15 hours ago












There is more history in A history of modern init systems (1992–2015).
– JdeBP
15 hours ago




There is more history in A history of modern init systems (1992–2015).
– JdeBP
15 hours ago










up vote
2
down vote













System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.



Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.



Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.



This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.



This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.






share|improve this answer










New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
    – JdeBP
    15 hours ago










  • Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
    – Gunter Ohrner
    7 hours ago















up vote
2
down vote













System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.



Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.



Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.



This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.



This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.






share|improve this answer










New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


















  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
    – JdeBP
    15 hours ago










  • Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
    – Gunter Ohrner
    7 hours ago













up vote
2
down vote










up vote
2
down vote









System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.



Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.



Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.



This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.



This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.






share|improve this answer










New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









System V was released in 1983 and thus the concept of "System V init" is at least as old. A similar predecessor was already found in System III as early as 1981.



Linux early used an init system developed by Miquel van Smoorenburg which was inspired by the init from System V.



Besides the problems already mentioned in the other answers, one big problem with System V init is that it's rather "static" - it was invented in a time when most Unix computers were comaratively "big" (by those days standards) continuously running multi-user machines with a static hardware configuration. The machines and peripherals were initialized during boot up and stayed operative until shutdown.



This doesn't scale well to todays battery-equipped portable machines where stuff like USB and Thunderbolt devices are continuously plugged and detached, systems are put to standby at random times and wake up again with totally different peripherals attached.



This calls for a more dynamic and possibly event-driven init system and lead to the design of eg. upstart and ultimately systemd, which is somewhat inspired by MacOS' launchd.







share|improve this answer










New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer








edited 7 hours ago





















New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 17 hours ago









Gunter Ohrner

312




312




New contributor




Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Gunter Ohrner is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
    – JdeBP
    15 hours ago










  • Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
    – Gunter Ohrner
    7 hours ago


















  • There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
    – JdeBP
    15 hours ago










  • Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
    – Gunter Ohrner
    7 hours ago
















There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
– JdeBP
15 hours ago




There are several things wrong with this answer. Linux never used AT&T init+rc. It used a clone developed a decade later by Miquel van Smoorenburg. And the revised AT&T init+rc system, introducing inittab and so forth, that people generally refer to was introduced with System 3 not System 5.
– JdeBP
15 hours ago












Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
– Gunter Ohrner
7 hours ago




Thanks for the feedback. I edited my answer. I didn't intend to say that Linux used the original init from System V, but this really wasn't clear from my answer. I didn't know about System V init's predecessor from System III, but also added information about that, and added some references for the information I added.
– Gunter Ohrner
7 hours ago










up vote
1
down vote














Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:




  • Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...

  • There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).

  • Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.

  • As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...


At the end of the day, it was just natural progression to look for more capable systems.






share|improve this answer

















  • 1




    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
    – Stephen Kitt
    19 hours ago






  • 1




    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
    – Jörg W Mittag
    19 hours ago

















up vote
1
down vote














Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:




  • Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...

  • There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).

  • Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.

  • As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...


At the end of the day, it was just natural progression to look for more capable systems.






share|improve this answer

















  • 1




    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
    – Stephen Kitt
    19 hours ago






  • 1




    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
    – Jörg W Mittag
    19 hours ago















up vote
1
down vote










up vote
1
down vote










Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:




  • Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...

  • There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).

  • Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.

  • As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...


At the end of the day, it was just natural progression to look for more capable systems.






share|improve this answer













Also, what was wrong with the systems used at that time that led to the creation of systemd et al?




It was too simplistic. At that time, basically, the RC scripts would be run sequentially, only sorted alphabetically/numerically, everything managed manually. This meant:




  • Order was somewhat arbitrary, not intrinsically enforceable by the scripts itself. The admin needed to to take care. Better not start that service before the NFS script has run...

  • There was no explicit connection between the thing started by a script, and the script itself. The script starting an Oracle database system might just be called /etc/init.d/db. The script starting httpd might be called apache. Worse, you might have apache and apache2. And so on. Have fun finding it (and good luck being sure you got the correct one).

  • Every script was free to bring its own subcommands (start, restart, reload, graceful...) with sometimes arbitrary semantics.

  • As far as I can recall, one of the largest drawbacks at the time was the sequential initialization. It took ages to boot up the system. Good riddance if a script had to wait on some external piece of hardware...


At the end of the day, it was just natural progression to look for more capable systems.







share|improve this answer












share|improve this answer



share|improve this answer










answered 19 hours ago









AnoE

68417




68417








  • 1




    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
    – Stephen Kitt
    19 hours ago






  • 1




    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
    – Jörg W Mittag
    19 hours ago
















  • 1




    Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
    – Stephen Kitt
    19 hours ago






  • 1




    I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
    – Jörg W Mittag
    19 hours ago










1




1




Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
– Stephen Kitt
19 hours ago




Regarding point 1, insserv and LSB headers have been available since at least 2005 to take care of dependencies (declared in the scripts), long before systemd was designed. Regarding point 4, startpar was available around the same time to allow parallel initialisation. They weren’t perfect but things weren’t as bad as you suggest.
– Stephen Kitt
19 hours ago




1




1




I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
– Jörg W Mittag
19 hours ago






I believe parallelization, asynchrony, and concurrency were the main drivers, all three in the name of reducing startup time. Automatic dependency management was just the mechanism to make that work (a mechanism already well-known from make -j and friends to work well for that goal).
– Jörg W Mittag
19 hours ago












Kidburla is a new contributor. Be nice, and check out our Code of Conduct.










 

draft saved


draft discarded


















Kidburla is a new contributor. Be nice, and check out our Code of Conduct.













Kidburla is a new contributor. Be nice, and check out our Code of Conduct.












Kidburla is a new contributor. Be nice, and check out our Code of Conduct.















 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8289%2fwhat-init-system-was-used-in-early-linux-distributions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

 ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕