16 files changed, 0 insertions, 346 deletions
diff --git a/presentations/systemd-2016/.gitignore b/presentations/systemd-2016/.gitignore
deleted file mode 100644
index 1a38620fe9cc..000000000000
--- a/presentations/systemd-2016/.gitignore
+++ /dev/null
@@ -1,6 +0,0 @@
-slides.aux
-slides.log
-slides.nav
-slides.out
-slides.snm
-slides.toc
diff --git a/presentations/systemd-2016/.skip-subtree b/presentations/systemd-2016/.skip-subtree
deleted file mode 100644
index 108b3507ddd1..000000000000
--- a/presentations/systemd-2016/.skip-subtree
+++ /dev/null
@@ -1 +0,0 @@
-No Nix files will ever be under this tree ...
diff --git a/presentations/systemd-2016/Makefile b/presentations/systemd-2016/Makefile
deleted file mode 100644
index ac5dde3cb32f..000000000000
--- a/presentations/systemd-2016/Makefile
+++ /dev/null
@@ -1,11 +0,0 @@
-all: slides.pdf
-
-slides.toc:
-	lualatex slides.tex
-
-slides.pdf: slides.toc
-	lualatex slides.tex
-
-clean:
-	rm -f slides.aux slides.log slides.nav \
-	slides.out slides.toc slides.snm
diff --git a/presentations/systemd-2016/README.md b/presentations/systemd-2016/README.md
deleted file mode 100644
index 7f004b7d14ca..000000000000
--- a/presentations/systemd-2016/README.md
+++ /dev/null
@@ -1,6 +0,0 @@
-This repository contains the slides for my systemd presentation at Hackeriet.
-
-Requires LaTeX, [beamer][] and the [metropolis][] theme.
-
-[beamer]: http://mirror.hmc.edu/ctan/macros/latex/contrib/beamer/
-[metropolis]: https://github.com/matze/mtheme
diff --git a/presentations/systemd-2016/demo/demo-error.service b/presentations/systemd-2016/demo/demo-error.service
deleted file mode 100644
index b2d4c9d34799..000000000000
--- a/presentations/systemd-2016/demo/demo-error.service
+++ /dev/null
@@ -1,7 +0,0 @@
-[Unit]
-Description=Demonstrate failing units
-OnFailure=demo-notify@%n.service
-
-[Service]
-Type=oneshot
-ExecStart=/usr/bin/false
diff --git a/presentations/systemd-2016/demo/demo-limits.slice b/presentations/systemd-2016/demo/demo-limits.slice
deleted file mode 100644
index 998185d26177..000000000000
--- a/presentations/systemd-2016/demo/demo-limits.slice
+++ /dev/null
@@ -1,7 +0,0 @@
-[Unit]
-Description=Limited resources demo
-DefaultDependencies=no
-Before=slices.target
-
-[Slice]
-CPUQuota=10%
diff --git a/presentations/systemd-2016/demo/demo-notify@.service b/presentations/systemd-2016/demo/demo-notify@.service
deleted file mode 100644
index e25524b4e230..000000000000
--- a/presentations/systemd-2016/demo/demo-notify@.service
+++ /dev/null
@@ -1,6 +0,0 @@
-[Unit]
-Description=Demonstrate systemd templating by sending a notification
-
-[Service]
-Type=oneshot
-ExecStart=/usr/bin/notify-send 'Systemd notification' '%i'
diff --git a/presentations/systemd-2016/demo/demo-path.path b/presentations/systemd-2016/demo/demo-path.path
deleted file mode 100644
index 87f1342da995..000000000000
--- a/presentations/systemd-2016/demo/demo-path.path
+++ /dev/null
@@ -1,6 +0,0 @@
-[Unit]
-Description=Demonstrate systemd path units
-
-[Path]
-DirectoryNotEmpty=/tmp/hackeriet
-Unit=demo.service
diff --git a/presentations/systemd-2016/demo/demo-stress.service b/presentations/systemd-2016/demo/demo-stress.service
deleted file mode 100644
index 7e14f13e29d9..000000000000
--- a/presentations/systemd-2016/demo/demo-stress.service
+++ /dev/null
@@ -1,6 +0,0 @@
-[Unit]
-Description=Stress test CPU
-
-[Service]
-Slice=demo.slice
-ExecStart=/usr/bin/stress -c 5
diff --git a/presentations/systemd-2016/demo/demo-timer.timer b/presentations/systemd-2016/demo/demo-timer.timer
deleted file mode 100644
index 34eccb98b02a..000000000000
--- a/presentations/systemd-2016/demo/demo-timer.timer
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=Demonstrate systemd timers
-
-[Timer]
-OnActiveSec=2
-OnUnitActiveSec=5
-AccuracySec=5
-Unit=demo.service
-# OnCalendar=Thu,Fri 2016-*-1,5 11:12:13
-
-[Install]
-WantedBy=multi-user.target
diff --git a/presentations/systemd-2016/demo/demo.service b/presentations/systemd-2016/demo/demo.service
deleted file mode 100644
index fcc710ad933f..000000000000
--- a/presentations/systemd-2016/demo/demo.service
+++ /dev/null
@@ -1,6 +0,0 @@
-[Unit]
-Description=Demo unit for systemd
-
-[Service]
-Type=oneshot
-ExecStart=/usr/bin/echo "Systemd unit activated. Hello Hackeriet."
diff --git a/presentations/systemd-2016/demo/notes.md b/presentations/systemd-2016/demo/notes.md
deleted file mode 100644
index b4866b1642bb..000000000000
--- a/presentations/systemd-2016/demo/notes.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# simple oneshot
-
-Run `demo-notify@hello.service`
-
-# simple timer
-
-Run `demo-timer.timer`, show both
-
-# enabling
-
-Enable `demo-timer.timer`, go to symlink folder, disable
-
-# OnError
-
-Show & run `demo-error.service`
-
-# cgroups demo
-
-Start `demo-stress.service` without, show in htop, stop
-Show slice unit, start slice unit
-Add Slice=demo-limits.slice
-daemon-reload
-Start stress again
-
-# Proper service
-
-Look at nginx unit
diff --git a/presentations/systemd-2016/slides.pdf b/presentations/systemd-2016/slides.pdf
deleted file mode 100644
index 384db2a6e0af..000000000000
--- a/presentations/systemd-2016/slides.pdf
+++ /dev/null
Binary files differdiff --git a/presentations/systemd-2016/slides.pdfpc b/presentations/systemd-2016/slides.pdfpc
deleted file mode 100644
index 99326bd8bf4e..000000000000
--- a/presentations/systemd-2016/slides.pdfpc
+++ /dev/null
@@ -1,85 +0,0 @@
-[file]
-slides.pdf
-[notes]
-### 1
-### 2
-Let's start off by looking at what an init system is, how they used to work and what systemd does different before we go into more systemd-specific details.
-### 3
-system processes that are started include for example FS mounts, network settings, powertop...
-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
-### 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
-No more init scripts with opaque effects -> services are clearly defined units
-Unit dependencies -> systemd can figure out what can be started in parallel
-Process supervision: Unit can be configured in many ways, e.g. always restart, only restart on success etc
-Service logs: We'll talk more about this later
-### 9
-Units are the core component of systemd that users deal with. They define services and everything else that systemd needs to start and manage.
-Note that all these are the names of the respective man page on a system with systemd installed
-Types:
-systemd.service - processes controlled by systemd
-systemd.target - equivalent to "runlevels", grouping of units for synchronisation
-systemd.timer - more powerful replacement of cron that starts other units
-systemd.path - systemd equvialent of inotify, watches files/folders -> launches units
-systemd.socket - expose local IPC or network sockets, launch units on connections
-systemd.device - trigger units when certain devices are connected
-systemd.mount - systemd equivalent of fstab entries
-systemd.swap - like mount
-systemd.slice - unit groups for resource management purposes
-... and a few more specialised ones
-### 10
-Linux cgroups are a new resource management feature added quite a long time ago, but not used much.
-Cgroups can be created manually and processes can be moved into them in order to control resource utilisation
-Few people used them before systemd, limits.conf was often much easier but not as fine-grained
-Systemd changed this
-### 11
-Systemd collects standard output and stderr from all processes into its journal system
-they provide a tool for querying the log, for example grouping service logs together with correct timestamps, querying,
-### 12
-Systemd tooling, most important one is systemctl for general service management
-journalctl is the query and management tool for journald
-systemd-analyze is used for figuring out performance issues, for example by analysing the boot process, can make cool graphs of dependencies
-systemd-cgtop is like top, but not on a process level - it's on a cgroup/slice level, shows combined usage of cgroups
-systemd-cgls lists contents of systemd's cgroups to see which services are in what group
-there also exist a bunch of others that we'll skip for now
-### 13
-### 14
-### 15
-Systemd criticism comes from many directions and usually focuses on a few points
-feature-creep: systemd is absorbing a lot of different services
-### 16
-explain diagram a bit
-### 17
-opaque: as a result, systemd has a lot more internal complexity that people can't easily wrap your mind around. However I argue that unless you're using something like suckless' sinit with your own scripts, you probably have no idea what your init does today anyways
-unstable: this was definitely true even in the first stable release, with the binary log format getting corrupted for example. I haven't personally experienced any trouble with it recently though.
-Another thing is that services start depending on systemd when they shouldn't, a problem for the BSD world (who cares (hey christoph!))
-### 18
-Despite criticism, systemd was adopted rapidly by large portions of the Linux
-Initially in RedHat, because Poettering and co work there and it was clear from the beginning that it would be there
-ArchLinux (which I'm using) and a few others followed suit quite quickly
-Eventually, the big Debian init system discussion - after a lot of flaming - led to Debian adopting it as well, which had a ripple effect for related distros such as Ubuntu which abandoned upstart for it.
\ No newline at end of file
diff --git a/presentations/systemd-2016/slides.tex b/presentations/systemd-2016/slides.tex
deleted file mode 100644
index c613cefd7ec4..000000000000
--- a/presentations/systemd-2016/slides.tex
+++ /dev/null
@@ -1,160 +0,0 @@
-\documentclass[12pt]{beamer}
-\usetheme{metropolis}
-
-\newenvironment{code}{\ttfamily}{\par}
-
-\title{systemd}
-\subtitle{The standard Linux init system}
-
-\begin{document}
-\metroset{titleformat frame=smallcaps}
-
-\maketitle
-
-\section{Introduction}
-
-\begin{frame}{What is an init system?}
-  An init system is the first userspace process (PID 1) started in a UNIX-like system. It handles:
-
-  \begin{itemize}
-  \item Starting system processes and services to prepare the environment
-  \item Adopting and ``reaping'' orphaned processes
-  \end{itemize}
-\end{frame}
-
-\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}
-
-\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}
-
-\begin{frame}{Systemd - the basics}
-  \begin{itemize}
-  \item No scripts are executed, only declarative units
-  \item Units have explicit dependencies
-  \item Processes are supervised
-  \item cgroups are utilised to apply resource limits
-  \item Service logs are managed and centrally queryable
-  \item Much more!
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{Systemd units}
-  Units specify how and what to start. Several types exist:
-  \begin{code}
-    \small
-    \begin{columns}[T,onlytextwidth]
-      \column{0.5\textwidth}
-      \begin{itemize}
-      \item systemd.service
-      \item systemd.target
-      \item systemd.timer
-      \item systemd.path
-      \item systemd.socket
-      \end{itemize}
-      \column{0.5\textwidth}
-      \begin{itemize}
-      \item systemd.device
-      \item systemd.mount
-      \item systemd.swap
-      \item systemd.slice
-      \end{itemize}
-    \end{columns}
-  \end{code}
-\end{frame}
-
-
-\begin{frame}{Resource management}
-  Systemd utilises Linux \texttt{cgroups} for resource management, specifically CPU, disk I/O and memory usage.
-
-  \begin{itemize}
-  \item Hierarchical setup of groups makes it easy to limit resources for a set of services
-  \item Units can be attached to a \texttt{systemd.slice} for controlling resources for a group of services
-  \item Resource limits can also be specified directly in the unit
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{journald}
-  Systemd comes with an integrated log management solution, replacing software such as \texttt{syslog-ng}.
-  \begin{itemize}
-  \item All process output is collected in the journal
-  \item \texttt{journalctl} tool provides many options for querying and tailing logs
-  \item Children of processes automatically log to the journal as well
-  \item \textbf{Caveat:} Hard to learn initially
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{Systemd tooling}
-  A variety of CLI-tools exist for managing systemd systems.
-  \begin{code}
-    \begin{itemize}
-    \item systemctl
-    \item journalctl
-    \item systemd-analyze
-    \item systemd-cgtop
-    \item systemd-cgls
-    \end{itemize}
-  \end{code}
-
-  Let's look at some of them.
-\end{frame}
-
-\section{Demo}
-
-\section{Controversies}
-
-\begin{frame}{Systemd criticism}
-  Systemd has been heavily criticised, usually focusing around a few points:
-  \begin{itemize}
-  \item Feature-creep: Systemd absorbs more and more other services
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{Systemd criticism}
-  \includegraphics[keepaspectratio=true,width=\textwidth]{systemdcomponents.png}
-\end{frame}
-
-\begin{frame}{Systemd criticism}
-  Systemd has been heavily criticised, usually focusing around a few points:
-  \begin{itemize}
-  \item Feature-creep: Systemd absorbs more and more other services
-  \item Opaque: systemd's inner workings are harder to understand than old \texttt{init}
-  \item Unstable: development is quick and breakage happens
-  \end{itemize}
-\end{frame}
-
-\begin{frame}{Systemd adoption}
-  Systemd was initially adopted by RedHat (and related distributions).
-
-  It spread quickly to others, for example ArchLinux.
-
-  Debian and Ubuntu were the last major players who decided to adopt it, but not without drama.
-\end{frame}
-
-\section{Questions?}
-
-\end{document}
diff --git a/presentations/systemd-2016/systemdcomponents.png b/presentations/systemd-2016/systemdcomponents.png
deleted file mode 100644
index a22c762f7e13..000000000000
--- a/presentations/systemd-2016/systemdcomponents.png
+++ /dev/null
Binary files differ