thesis doc. WIP

src/docs/thesis.md

@@ -3,56 +3,111 @@
 * From Declarative Source-Package Management to Application Container deployment
 * Container Build System using Source-Package Management
 
-# Introduction
-This project represents my thesis for achieving the title "Master of Science" and is part of my studies of Information Technology at the University of Applied sciences in Constance, Germany.
+# Introduction and problem derivation 
+This work represents my thesis for achieving the title "Master of Science" and is part of my studies of Information Technology at the University of Applied sciences in Constance, Germany.
 The main concern of this thesis is to find a viable method for creating application containers with the help of a package manager for source-based packages by specifying their content in a declarative manner.
 The choice for this topic is due to my personal experience with currently available methods for creating application containers, which doesn't include a single one that I felt completely comfortable with and that could provide all the features that I have expected.
 
-My personal experience has been collected in different areas which allowed me to create a very broad view of use-cases and their respective requirements, in which containers can be used to improve the overall situation.
+## Basic Terms and Relations
+Before solving the underlying problem, I want to give a brief summary of what I'm referring to as packages, containers, application and their source. Further enlarging upon the definitions will follow in succeeding chapters when more detailed knowledge will be required.
+
+In the context of computers and their operating systems, an application consists of a unique set of files that are required to execute that specific application on the running operating system.
+The operating system understands how to execute the application's files, which are binary translations from the application source code.
+For reasons I don't want to discuss at this point, almost every application is written to depend on library functions that are not part of the application itself, but need to be properly installed on the operating system for the applications to find and use it.
+In order to install an run application and library files on different systems, their set of files are packed into single files.
+These are called packages, and can be transferred to other computers and installed there via the operating systems package manager.
+If an application and all it's needed library function files are instead packed together into one file it can be called an application container image.
+
+## Ideology 
+In the ideal case it would be possible to install an application and its required shared library files in every possible combination on the same computer, which as an example could mean to install many different applications, multiple versions of the same application and libraries and of course a combination.
+It would also not cause a conflict or side effects if the shared libraries, that are required by different applications, have to be installed in multiple different versions.
+
+Unsurprisingly the reality is not ideal, at least not for many popular operating systems and their included package management systems.
+
+## Classical (Non Container) Attempts
+Developers of operating systems and package managers have been trying to achieve this ideal situation for a long time.
+From my point of view, it looks like the classical but still widely spread solutions seem to improve slower than the multiplication in variety of applications.
+
+* TODO
+    * bare-metal OS installations
+    * packages installed and run in the top OS layer
+    * Application and dependency deployment
+    * Pick up on explain package conflict. 
+    * Application lifecycle management
+    * explain how application containers provide an interface between the system and the application
+    * container lifecycle management
+
+* TODO: the thesis does not cover isolation requirements for improved security
+
+## Human Roles and Interaction
+* TODO: operating system developer
+* TODO: system administrator
+* TODO: system architect
+* TODO: application developer
+* TODO: application packager
+* TODO: interfaces and interactions
+    * OS configuration -> application agnostic?
+    * Network topology management -> isolation of networking?
+
+* TODO rewrite:
+    Typically the system administrator doesn't necessarily think about the work-flow of an application developer and vise versa.
+    The system architect unfortunately isn't oftentimes involved in the decision making of the administrator and application developer. 
+    This circumstance can and eventually will lead to applications running on systems that have undergone severe workarounds to make it work at all.
+    The DevOps movement, which is a modern term and attempt to combine the three aforementioned three roles, has been trying to solve the described problem with tools for automatic system configuration.
+
+## Personal Role Experiences
+I've been able to collect first-hand experience in multiple of the aforementioned roles, which allowed me to create a very broad view of use-cases and their respective requirements in which containers can be used to improve the overall situation.
+
 The most recent project that I want to name is called [embEDUx][embEDUx], and it aims to provide a flexible solution for creating and deploying a customized Linux distribution for embedded systems in an educational context.
 My main part within that project was to design the overall architecture of the build system and to develop the specification for the system archive and the method of processing it to a complete system archive. 
 Additional experience in this area comes from my work on projects for customers that consulted me to advise and administer their IT small-business infrastructure.
 
-I've had the chance to gather requirements and form certain expectations from the perspective of three major IT roles: the system administrator, the system architect and the application developer.
-* TODO: What is a system administrator?
-* TODO: What is an application developer?
-* TODO: What do they focus on?
-
-Typically the system administrator doesn't necessarily think about work-flow of an application developer and vise versa.
-The system architect unfortunately isn't oftentimes involved in the decision making of the administrator and application developer. 
-This circumstance can and eventually will lead to applications running on systems that have undergone severe workarounds to make it work at all.
-The DevOps movement, which is a modern term and attempt to combine the three aforementioned three roles, has been trying to solve the described problem with tools for automatic system configuration.
-
-* TODO: describe interfaces of these roles
-    * OS configuration
-    * Network topology management
-    * Application and dependency deployment
-    * Application lifecycle management
-
-* Intention: evaluate the existing build systems, their design choices and resulting features and methodologies. 
+## Intention
+* TODO: evaluate the existing build systems, their design choices and resulting features and methodologies. 
 The intention for customizing and adapting each one of them to make them suitable for two types of users, system administrators and application developers.
 
+# Design Specification
 ## Scope
-### NOT Scope
-* Distributing
-* Discovering
-* Running
-
-### Scope
+* Package format
 * Creating
 * Package selection
 * Post-Install commands
 
-# Evaluation
 
+# Pre-Evaluation
 * TODO: explain and mention 12-factor apps
-* TODO: compare to puppet
 
 ## Criteria
-* Usability: TODO: what is this?
-* Corectness: TODO: what is this?
+* Usability 
+* Corectness
 
+## Automated System Administration
+* puppet
+* chef
+* ansible
 
+## Build Systems
+* Package Mangers
+    * Porage
+    * Nix (and NixOS)
+* Embedded Targetted
+    * embEDUx' buildrootfs routine
+    * baserock
+    * yocto
+    * openembedded
+    * buildroot
+* Distro Release tools
+    * ChromeOS/CoreOS SDK
+    * Gentoo Catalyst
+* Docker related
+    * docker build (Dockerfile)
+* ACI related
+    * acbuild
+
+# Discussion
+* Distributing
+* Discovering
+* Running
 
 # Terminology