From f15a12bc4e60bcbf694d815d4eb037063ab23476 Mon Sep 17 00:00:00 2001
From: Vincent Ambo <tazjin@gmail.com>
Date: Wed, 20 Jan 2016 17:52:42 +0100
Subject: Add slides about classical init, systemd history

---
 slides.pdfpc | 26 +++++++++++++++++++++++++-
 slides.tex   | 34 ++++++++++++++++++++++++++++------
 2 files changed, 53 insertions(+), 7 deletions(-)

diff --git a/slides.pdfpc b/slides.pdfpc
index 2f6ac472edb5..c4b4bf5e9fc7 100644
--- a/slides.pdfpc
+++ b/slides.pdfpc
@@ -9,4 +9,28 @@ system processes that are started include for example FS mounts, network setting
 system services are long-running processes such as daemons, e.g. SSH, database or web servers, session managers, udev ...
 
 orphans: Process whose parent has finished somehow, gets adopted by init system
--> when a process terminates its parent must call wait() to get its exit() code, if there is no init system adopting orphans the process would become a zombie
\ No newline at end of file
+-> when a process terminates its parent must call wait() to get its exit() code, if there is no init system adopting orphans the process would become a zombie
+### 4
+Before systemd there were simple init systems that just did the tasks listed on the previous slide.
+Init scripts -> increased greatly in complexity over time, look at incomprehensible skeleton for Debian service init scripts
+Runlevels -> things such as single-user mode, full multiuser mode, reboot, halt
+
+Init will run all the scripts, but it will not do much more than print information on success/failure of started scripts
+
+Init scripts run strictly sequential
+
+Init is unaware of inter-service dependencies, expressed through prefixing scripts with numbers etc.
+
+Init will not watch processes after system is booted -> crashing daemons will not automatically restart
+### 5
+### 6
+How systemd came to be
+
+Considering the lack of process monitoring, problematic things about init scripts -> legacy init systems have drawbacks
+
+Apple had already built launchd, a more featured init system that monitored running processes, could automatically restart them and allowed for certain advanced features -> however it is awful to use and wrap your head around
+
+Lennart Poettering of Pulseaudio fame and Kay Sievers decided to implement a new init system to address these problems, while taking certain clues from Apple's design
+### 7
+Systemd's design goals
+### 8
diff --git a/slides.tex b/slides.tex
index 5140c96dec13..8a5302726033 100644
--- a/slides.tex
+++ b/slides.tex
@@ -15,17 +15,39 @@
   An init system is the first process (PID 1) started in a Unix like system. It handles:
 
   \begin{itemize}
-    \item Starting system processes and services
-    \item Adopting and ``reaping'' orphaned processes
+  \item Starting system processes and services to prepare environment
+  \item Adopting and ``reaping'' orphaned processes
   \end{itemize}
 \end{frame}
 
-\begin{frame}{What is systemd?}
-  Bar baz
+\begin{frame}{Classical init systems}
+  Init systems before systemd - such as SysVinit - were very simple.
+
+  \begin{itemize}
+  \item Services and processes to run are organised into ``init scripts''
+  \item Scripts are linked to specific runlevels
+  \item Init system is configured to boot into a runlevel
+  \end{itemize}
+
 \end{frame}
 
-\begin{frame}{Systemd units}
-  Foo bar
+\section{systemd}
+
+\begin{frame}{Can we do better?}
+  \begin{itemize}
+  \item ``legacy'' init systems have a lot of drawbacks
+  \item Apple is taking a different approach on OS X
+  \item Systemd project was founded to address these issues
+  \end{itemize}
+\end{frame}
+
+\begin{frame}{Systemd design goals}
+  \begin{itemize}
+  \item Expressing service dependencies
+  \item Monitoring service status
+  \item Enable parallel service startups
+  \item Ease of use
+  \end{itemize}
 \end{frame}
 
 \section{Demo}
-- 
cgit 1.4.1