steveej/msc-thesis
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases 4 Packages Wiki Activity Actions

thesis: add content to and rename part introduction -> context

Browse source
This commit is contained in:
steveej 2016-09-07 17:05:54 +02:00
parent 4d7f29a783
commit af08b82088
3 changed files with 71 additions and 101 deletions
Download patch file Download diff file Expand all files Collapse all files

61
src/docs/parts/introduction/introduction.tex
View file

@ -6,33 +6,66 @@
% Use plenty of transitional words and sentences from one section to another, as well as subheadings, which allow the reader to follow the writer’s train of thought. Following is an outline of the content of the empirical argument of Chapter 1. Universities often arrange the content in a different order, but the subject matter is the same in all dissertations because it is an empirical “opening statement” as might be found in a court of law. (Note that a dissertation could also be five pages of text and 50 pages of pictures of dragonfly wings and qualify for a Doctor’s degree in entomology.)
%State the general field of interest in one or two paragraphs, and end with a sentence that states what study will accomplish. Do not keep the reader waiting to find out the precise subject of the dissertation.
This thesis is about building and packaging software applications specifically with the intention to distribute them in form of \glspl{apci} on systems running a \gls{Linux} based \gls{OS}.
The primary concern is to find a viable method for declaring and assembling \glspl{apci} deterministically and ideally being able to reproducible these builds on different computers and different points in time.
This thesis is about building and packaging \glspl{app} specifically with the intention to distribute them in form of \glspl{apci} on systems running a \gls{Linux} based \gls{OS}.
The term \gls{apc} is nuanced from \gls{appc} defined by the \gls{appcorg}.
The \gls{appcorg} is a community driven effort to create an open, standardized specification for developers and users of \gls{apc} technology.
Such independent standards are required to form interoperability between \gls{apc} implementations of independent parties.
Some of these implementations will be subject to more detailed examination in Part \ref{part:research}.
The term \gls{apc} want to explicitly not refer to the specifications that have been created within the \gls{appcorg}.
The primary concern is to find a viable method for declaring and assembling \glspl{apci} deterministically.
As a highly anticipated option, the solution should also be able to reproducible these builds on different computers and different points in time and yield the exact same results.
The secondary concern is to abstract enough of the method's complexity in order to make it attractive for application developers while still allowing them to specify the exact contents alongside their software within the resulting \gls{apci}.
The choice for this topic was made due to my personal dissatisfaction with currently available methods for building \glspl{apci}, and seeing both the need and the potential of a scientifically substantiated approach.
This chapter will cover the knowledge that is necessary to understand the problem and the development of technology and mindsets of technology users, leading to the current situation.
\section{Problems (attempted) to be solved with \glspl{apc}}
The technology that is currently available to form \glspl{apc} reuses different patterns and techniques to solve a combination of different problems all at once.
These problems are all related to software deployment and system operation and can be represented by the following questions.
Only a subset of these problems and attempted solutions will be subject to research for this thesis.
This chapter covers the knowledge that is necessary to understand the problem, starting with the development of the specific technology and the challenges and mindsets of its developers and users.
\begin{enumerate}
\item How do we maximize the utilization of our hardware systems without compromising security?
\item How do we guarantee that the application works on every target machine the same as on the developer machine?
\item How do we build multiple variants and/or versions of an application, install and run them simultaneously on the same target machine without exhibiting conflicts?
\item How do we verify that an application runs on the target system has not been altered maliciously at one point in the deployment chain?
\end{enumerate}
The first question is about isolating system resources and fine-grained resource control, which is not in the research scope of this thesis.
It is yet briefly explained under the section \ref{sect:apc-osvirt}, to form a complete view on the scope of \glspl{apc}.
\section{The Advent of \glspl{apc}}
The other questions are in the research scope of this thesis, while the concern of the last question is declared optional.
They are very important to the ideology of \glspl{apc}, and they have their origin in the conventional methods of software deployment.
Therefore they are examined further in section \ref{sect:sd-challenges} later in this chapter.
\section{\glspl{apc}: A facet of \gls{osvirt}}
\label{sect:apc-osvirt}
% Background of the Problem
% This section is critically important as it must contain some mention of all the subject matter in the following Chapter 2 Review of the Literature 2 and the methodology in Chapter 3. Key words should abound that will subsequently be used again in Chapter 2. The section is a brief two to four page summary of the major findings in the field of interest that cites the most current finding in the subject area. A minimum of two to three citations to the literature per paragraph is advisable. The paragraphs must be a summary of unresolved issues, conflicting findings, social concerns, or educational, national, or international issues, and lead to the next section, the statement of the problem. The problem is the gap in the knowledge. The focus of the Background of the Problem is where a gap in the knowledge is found in the current body of empirical (research) literature.
% TODO: refer and limit scope to the FOSS/Linux, maybe Jails? Explain why not closed-source kernels (community, collaboration)
based on \gls{osvirt}\cite{Reshetova2014}, which has been available on \gls{Linux} and under continuous development for many years.
% TODO: explain generically what APC is and compare to Hypervisors
% TODO: explain performance and resource allocation overhead/flexibility
% TODO: explain difference to hypervisors: effort, performance and resource allocation flexibility
% TODO: refer to Linux Namespaces and Cgroups
\gls{Docker}, since with its release in 2013 (TODO reference), has brought \glspl{apc} to the attention and hands of the masses in the \gls{FOSS} community.
From a psychological standpoint this is not surprising, as it has abstracted most of complexities of the technology, and has added ease of deployment with a platform for hosting the \gls{apci} in a Docker specific format, as well as a very convenient tool for building the like.
\section{The Challenges Of Software Development Deployment}
\label{sect:sd-challenges}
Software is typically developed on a workstation or laptop, brought to a format that is understood by the target machine to which it must be is transfered, and where it is configured and finally executed to serve its purpose.
In order to be executable on the target machine, the software needs to be translated into the target-platform specific format before it can be executed on to the target system.
If the software is updated, the cycle has to be repeated.
This introduces a very generic challenge: software updates, or deployments in general, are not supposed to be negatively influenced by any previous version or state that exists on the target machine.
Describing the process with technical terms, software developers write software source code, which is then translated to binary files in specific machine language dependent on the target platform with the help of a compiler toolchain.
These binary files are made available as software packages that can be installed in the target machines operating system, typically with the help of a software package manager which itself is a software that is included in most modern operating systems.
The location where the files of the package are installed on the target machine depends on how it is configured at packaging time, but in most popular software package approaches this location is agnostic of software application version changes.
Another challenge is to be able to verify that software hasn't been altered to differ from its intentional behavior at any point of the deployment process.
\subsection{Docker: The Advent of \gls{apc}}
Even though the underlying technology had been available for a relatively long time, \gls{Docker}\cite{Fink2014}, since its release in 2014\footnote{http://blog.docker.com/2014/06/its-here-docker-1-0}, has brought \glspl{apc} to the attention and hands of the masses in the \gls{OSS} community.
From a psychological standpoint this is not surprising, as it has abstracted most of complexities of the technology, adding ease of deployment, a platform for hosting the \gls{apci} in a Docker specific format, as well as a very convenient way for building the like using Dockerfiles(TODO reference).
Its popularity has come to a point where the term \textit{Docker} is being used interchangeably (TODO: do I need references for this?) with the \gls{apc} technology itself.
One major issue I'm seeing that I want to discuss here is that, according to my subjective impression, there is a deficiency in education.
What is referred to as \gls{apc} within the scope of this work has it's origins
The \gls{apc} technology that is openly available today, such as \gls{Docker},
\section{No proved methods to declare, reproduce, and trust the builds of \glspl{apci}}
% Statement of the Problem
% Arising from the background statement is this statement of the exact gap in the knowledge discussed in previous paragraphs that reviewed the most current literature found. A gap in the knowledge is the entire reason for the study, so state it specifically and exactly. Use the words “gap in the knowledge.” The problem statement will contain a definition of the general need for the study, and the specific problem that will be addressed.

3
src/docs/parts/research/research.tex
View file

@ -44,5 +44,8 @@ Spack (\url{https://github.com/LLNL/spack}) is a package manager written in Pyth
\section{Guile Scheme}
Guile implements Scheme and extends it with new features.
\chapter{Abstraction of \gls{apcr} and \gls{apci}}
\label{chap:research-abstract-acpr-apci}
UX: \url{https://logicgrimoire.wordpress.com/2012/08/25/a-first-guile-script}

108
src/docs/thesis.tex
View file

@ -95,108 +95,42 @@
{0.0001pt \plus 0.2ex}%
{\normalfont\normalsize\bfseries}}
\makeatother
\include{glossary}
\newglossaryentry{OS}{
name = Operating System,
description = {
TODO
},
}
\newglossaryentry{FOSS}{
name = Free and Open-Source Software,
description = {
TODO
},
}
\newglossaryentry{Linux}{
name = Linux,
description = {
is a generic term referring to the family of Unix-like
computer operating systems that use the Linux kernel
},
plural=Linuces
}
\newglossaryentry{computer}{
name = Computer,
description = {
is a programmable machine that receives input,
stores and manipulates data, and provides
output in a useful format
}
}
\newglossaryentry{apc}{
name=Application Program Container,
description={
The broad term for the technology used to build, package, distribute and run an application program in isolation from the underlying and co-existing systems, wherein the level or technique of isolation can be different depending on the \gls{apcr}.
}
}
\newglossaryentry{apci}{
name=Application Program Container Image,
description={
An archive file that contains all of the necessary binaries that are needed to execute an application and a manifest file that that contains metadata about the application. Alternatively to containing all the required binary files, the manifest file can declare dependencies to other application container images, which must then be available at runtime to execute the contained application.
}
}
\newglossaryentry{apcr}{
name=Application Program Container Runtime,
description={
An application program (suite) that understands how to run the software inside an \gls{apci}.
}
}
\newglossaryentry{LXC}{
name=LXC,
description={
TODO
}
}
\newglossaryentry{Docker}{
name=Docker,
description={
A very popular \gls{apc} platform and application suite, providing functionality to build and deploy Docker specific \glspl{apci}.
}
}
\overfullrule=2cm
\overfullrule=1cm
\begin{document}
\pagenumbering{roman}
\pagestyle{plain}
%TODO: \include{cover}
\include{title}
\include{abstract}
%TODO: \include{affidavit}
\cleardoublepage
%TODO: \include{cover}
\pagestyle{front}
\include{title}
\pagestyle{preamble}
\include{abstract}
%TODO: \include{affidavit}
\cleardoublepage
\newcounter{roman_pagenumbers} % save page number
\setcounter{roman_pagenumbers}{\value{page}}
\pagenumbering{arabic}
\pagestyle{fancy}
\fancyhf{}
\addtolength{\headwidth}{\marginparsep}
\headheight=15pt
\fancyfoot[R]{\thepage{}}
\fancyhead[L]{\small \authorOneInit}
\fancyhead[R]{\nouppercase{\rightmark}}
\pagenumbering{arabic}
\pagestyle{fancy}
\pagestyle{main}
%TODO \include{acknowledgments}
\chapter*{Preface}
This thesis is original, unpublished, independent work by the author, \authorOne.
I strongly believe in openness and collaboration in the development of new technology, therefore the development will be based solely on Open-Source software.
The results of this project will be freely available on my personal GitHub site\footnote{https://github.com/steveeJ/msc-thesis} once the academic process of this project is complete.
\tableofcontents
\chapter{Preface}
This dissertation is original, unpublished, independent work by the author, \authorOne.
\part{Introduction}
\part{Context}
\printnoidxglossary
\include{parts/introduction/introduction}
\part{Research}
\label{part:research}
\include{parts/research/research}
\part{Development}