\input{configpres}

\title{\lq Maintainance and Lifecycle Management\rq}
\maketitle

\subsection{QA / Selecting the correct versions}

\begin{frame}
\frametitle{Versioning of the Linux Kernel}
\begin{itemize}
\item 2.6.37
\item 2.6.38
\item 2.6.39
\item 3.0
\item ...
\item 3.19
\item 4.0
\item ...
\item 4.19
\item 5.0
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{The release cycle of the Linux Kernel}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/dev_cycle_kernel.jpg}
\end{figure}
\end{frame}

\begin{frame}
\frametitle{Stable releases of the Linux Kernel}
\begin{itemize}
\item Important bugfixes are being backported to older kernel versions
\item It's always recommended to use the latest stable release of your kernel version
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{QA in the Linux Kernel}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/linux_qa.png}
\end{figure}
\end{frame}

\begin{frame}
\frametitle{Longterm kernels}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/kernel_org.png}
\end{figure}
kernel.org
\end{frame}

\begin{frame}
\frametitle{Longterm kernels}
\begin{figure}[h]
\centering
\includegraphics[width=8cm]{images/longterm.png}
\end{figure}
https://www.kernel.org/category/releases.html
\end{frame}

\begin{frame}
\frametitle{Choosing a kernel version}
\begin{itemize}
\item Take the latest longterm release
\item When the release goes EOL update to the most recent longterm
\item Updating to the next longterm is less effort and less error
prone than backporting
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Grading the quality of Open-Source components}
\begin{itemize}
\item Is the project actively maintained?
\item How big is the community?
\item How diverge is the community?
\item Does it fullfil my technical requirements
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Quality assurance}
\begin{itemize}
\item QA from the projects is mostly based on Code Review
\item Be aware that you might need to test on your specific hardware
\item Since the variety of the use cases is so big, the community can't
cover testing for these cases
\item So, there's always a risk, that a specifig feature won't work
\item Calculate time for this risk in your projects!
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Other aspects of quality assurance}
\begin{itemize}
\item Is license compliance handled correctly?
\item For third-party deliveries: Are all needed documents
for license compliance delivered?
\item Does the supplier provide the results of a license scan?
\item Is the compliance process of the supplier certified in some way?
(e.g. OpenCHAIN)
\item You shoud run a license scan
\end{itemize}
\end{frame}

\subsection{Building your Linux system}
\begin{frame}
\frametitle{Different approaches of building your Linux distribution}
\begin{itemize}
\item Roll your own (have fun with that one... ;-))
\item Using a pre-existing free distribution
\item Vendor based Linux
\item Commercial Linux distribution
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Basic requirements for a build system}
Creating your custom distribution:
\begin{itemize}
	\item Linux Kernel
	\item GNU Tools
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Overview}
BUT: There are many addtional requirements:
\begin{itemize}
	\item Systemboot concept
	\item Update concept
	\item Security concept
	\item Application development
	\item Continious integration
	\item Release builds
	\item Versioning
	\item Lizence Management
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Most importantly: Security}
\begin{itemize}
	\item Monitoring security advisories
	\item Check if your product needs an update
	\item Generating updates
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{What is YOCTO?}
\begin{itemize}
	\item Ecosystem (not a single Open-Source project!)
	\item Collection of Embedded Linux projects and tools
	\item Framework for the industry to publish BSPs
	\item NOT a Linux Distribution
\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Just a few words on security}
	...and why you SHOULD think about it!!
\end{frame}

\begin{frame}
\frametitle{Reasons people tell why they don't care about security}
\begin{itemize}
\item ''My device is running in a secure network''
\item ''There's no interest in attacking my device''
\item ''My software doesn't have any bugs''
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''my device is running in a secure network''
\item answer: Just check the media for the successful attacks on ''secure'' networks which happened the past few weeks
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''there's no interest in attacking my device''
\item answer: If it has a network interface there is always a reason. At least your device can send SPAM.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Reasons why they SHOULD care!}
\begin{itemize}
\item ''my software doesn't have any bugs''
\item answer 1: Oh well....dream on...
\item answer 2: If your software doesn't, some library you are using might have critical issues
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{And if you are still not convinced}
\begin{itemize}
\item In future you might even be forced to care by law
\item If you don't follow ''state of the art'' security techniques, you might be responsible for the results caused by any attack
\end{itemize}
\end{frame}

\begin{frame}[fragile]
	\frametitle{OK, so back to Yocto...}
	\begin{verbatim}
	Since the Yocto Project is intended to be flexible
	and meet the needs of many applications,
	we leave policy-making decisions around security
	to our end users.
	\end{verbatim}
	Source: https://wiki.yoctoproject.org/wiki/Security
	\pause
	\begin{verbatim}
	Debian takes security very seriously.
	We handle all security problems brought to our attention [...]
	Many advisories [...] are published the same day
	a vulnerability is made public
	\end{verbatim}
	Source: https://www.debian.org/security/index.en.html
\end{frame}

\begin{frame}[fragile]
	\frametitle{Security}
	YOCTO does:
	\begin{itemize}
		\item Keep software versions up-to-date
		\item Fix critical software issues
	\end{itemize}
\end{frame}

\begin{frame}
	\includegraphics[width=\textwidth]{images/nvd.jpg}
\end{frame}

\begin{frame}
	\includegraphics[width=\textwidth]{images/debian-cve.jpg}
\end{frame}

\begin{frame}
	\includegraphics[width=\textwidth]{images/yocto-cve.jpg}
	\\
	This implies: Security tracking must be done by the Yocto user!
\end{frame}

\begin{frame}
	\frametitle{Debian: Using an existing distribution}
\end{frame}

\begin{frame}
	\frametitle{What is Debian?}
	\begin{itemize}
		\item A Linux Distribution (existing for more than 20 years)
		\item Available for many CPU architectures: x86, ARM, PowerPC, MIPS
		\item Debian is based on pre-compiled binary packages
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Debian package management}
	\begin{itemize}
		\item Simple licence management
		\item Can be used for updates
		\item Easy to be extended
		\item Simple generation of custom packages
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Advantages of debian}
	\begin{itemize}
		\item Longevity
		\item Packages (thousands of software packages are available and supported!)
		\item No cross compilation
		\item Security and Bugfixes!
		\item Buildsystems for customization available (e.g. ELBE http://elbe-rfs.org/)
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Debian based Buildsystems}
	\begin{itemize}
		\item ELBE: http://elbe-rfs.org
		\item ISAR: https://github.com/ilbers/isar
		\item meta-debian: Meta-layer for Poky to build Debian sources
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Conclusion}
	\begin{itemize}
		\item Yocto helped to standardize the distribution of Linux BSPS
		\item Yocto is NOT an Embedded Linux Distribution
		\item Yocto / Poky is usually combined with a manufacturer layer and additional components
		\item Debian is a pre-built disribution which can be used on embedded devices
		\item Debian is very powerful when it comes to bug and security tracking
	\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Lifecycle Management}
\begin{itemize}
\item Don't underestimate the efforts for security tracking
\item Re-use community efforts as much as possible
\item Only use well maintained components
\item Only maintain custom changes if it's really possible
\end{itemize}
\end{frame}

\subsection{Interesting projects}

\begin{frame}
\frametitle{Debian longterm stable}
\begin{itemize}
\item At least 5 years of maintenance
\item Handled by a group of volunteers and companies
\item https://wiki.debian.org/LTS
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Civil infrastructure platform}
\begin{itemize}
\item https://www.cip-project.org/
\end{itemize}
\end{frame}

\input{tailpres}