add bibliography
This commit is contained in:
parent
4dda73b75f
commit
cd8c39d119
2 changed files with 150 additions and 0 deletions
101
src/docs/glossary.tex
Normal file
101
src/docs/glossary.tex
Normal file
|
|
@ -0,0 +1,101 @@
|
||||||
|
% // vim: set ft=tex:
|
||||||
|
|
||||||
|
\newglossaryentry{OS}{
|
||||||
|
name = Operating System,
|
||||||
|
description = {
|
||||||
|
TODO
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{virtualization}{
|
||||||
|
name = Virtualization,
|
||||||
|
description = {
|
||||||
|
TODO
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{OSS}{
|
||||||
|
name = Open-Source Software,
|
||||||
|
description = {
|
||||||
|
TODO
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{osvirt}{
|
||||||
|
name = Operating System-Level Virtualization,
|
||||||
|
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{app}{
|
||||||
|
name=Application Program,
|
||||||
|
description={
|
||||||
|
TODO
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\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}.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{appcorg}{
|
||||||
|
name=App Container Organisation,
|
||||||
|
description={
|
||||||
|
Organisation for the App Container specification, including the schema and associated tooling.
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
\newglossaryentry{appc}{
|
||||||
|
name=App Container,
|
||||||
|
description={
|
||||||
|
Specific variant of an \gls{apc} defined by the \gls{appcorg}.
|
||||||
|
}
|
||||||
|
}
|
||||||
49
src/docs/thesis.bib
Normal file
49
src/docs/thesis.bib
Normal file
|
|
@ -0,0 +1,49 @@
|
||||||
|
Automatically generated by Mendeley Desktop 1.16
|
||||||
|
Any changes to this file will be lost if it is regenerated by Mendeley.
|
||||||
|
|
||||||
|
BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
|
||||||
|
|
||||||
|
@inproceedings{Reshetova2014,
|
||||||
|
abstract = {The need for flexible, low-overhead virtualization is evident on many fronts ranging from high-density cloud servers to mobile devices. During the past decade OS-level virtualization has emerged as a new, efficient approach for virtualization, with implementations in multiple different Unix-based systems. Despite its popularity, there has been no systematic study of OS-level virtualization from the point of view of security. In this report, we conduct a comparative study of several OS-level virtualization systems, discuss their security and identify some gaps in current solutions.},
|
||||||
|
archivePrefix = {arXiv},
|
||||||
|
arxivId = {1407.4245},
|
||||||
|
author = {Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
|
||||||
|
booktitle = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},
|
||||||
|
doi = {10.1007/978-3-319-11599-3_5},
|
||||||
|
eprint = {1407.4245},
|
||||||
|
file = {:home/steveej/.local/share/data/Mendeley Ltd./Mendeley Desktop/Downloaded/Reshetova et al. - 2014 - Security of OS-level virtualization technologies(2).pdf:pdf},
|
||||||
|
isbn = {9783319115986},
|
||||||
|
issn = {16113349},
|
||||||
|
pages = {77--93},
|
||||||
|
title = {{Security of OS-level virtualization technologies}},
|
||||||
|
volume = {8788},
|
||||||
|
year = {2014}
|
||||||
|
}
|
||||||
|
@article{Fink2014,
|
||||||
|
abstract = {Docker is a relatively new method of virtualization available natively for 64-bit Linux. Compared to more traditional virtualization techniques, Docker is lighter on system resources, offers a git-like system of commits and tags, and can be scaled from your laptop to the cloud.},
|
||||||
|
author = {Fink, John},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/papers/Docker - a Software as a Service, Operating System-Level Virtualization Framework.pdf:pdf},
|
||||||
|
journal = {Code4Lib},
|
||||||
|
number = {25},
|
||||||
|
pages = {3--5},
|
||||||
|
title = {{Docker: a Software as a Service, Operating System-Level Virtualization Framework}},
|
||||||
|
url = {http://journal.code4lib.org/articles/9669},
|
||||||
|
volume = {1},
|
||||||
|
year = {2014}
|
||||||
|
}
|
||||||
|
@book{Utrecht2006,
|
||||||
|
abstract = {Software deployment is the set of activities related to getting$\backslash$r$\backslash$nsoftware components to work on the machines of end users. It includes$\backslash$r$\backslash$nactivities such as installation, upgrading, uninstallation, and so on.$\backslash$r$\backslash$nMany tools have been developed to support deployment, but they all$\backslash$r$\backslash$nhave serious limitations with respect to correctness. For instance,$\backslash$r$\backslash$nthe installation of a component can lead to the failure of previously$\backslash$r$\backslash$ninstalled components; a component might require other components that$\backslash$r$\backslash$nare not present; and it is generally difficult to undo deployment$\backslash$r$\backslash$nactions. The fundamental causes of these problems are a lack of$\backslash$r$\backslash$nisolation between components, the difficulty in identifying the$\backslash$r$\backslash$ndependencies between components, and incompatibilities between$\backslash$r$\backslash$nversions and variants of components.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis thesis describes a better approach based on a purely functional$\backslash$r$\backslash$ndeployment model, implemented in a deployment system called Nix.$\backslash$r$\backslash$nComponents are stored in isolation from each other in a Nix store.$\backslash$r$\backslash$nEach component has a name that contains a cryptographic hash of all$\backslash$r$\backslash$ninputs that contributed to its build process, and the content of a$\backslash$r$\backslash$ncomponent never changes after it has been built. Hence the model is$\backslash$r$\backslash$npurely functional.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis storage scheme provides several important advantages. First, it$\backslash$r$\backslash$nensures isolation between components: if two components differ in any$\backslash$r$\backslash$nway, they will be stored in different locations and will not overwrite$\backslash$r$\backslash$neach other. Second, it allows us to identify component dependencies.$\backslash$r$\backslash$nUndeclared build time dependencies are prevented due to the absence of$\backslash$r$\backslash$n"global" component directories used in other deployment systems.$\backslash$r$\backslash$nRuntime dependencies can be found by scanning for cryptographic hashes$\backslash$r$\backslash$nin the binary contents of components, a technique analogous to$\backslash$r$\backslash$nconservative garbage collection in programming language$\backslash$r$\backslash$nimplementation. Since dependency information is complete, complete$\backslash$r$\backslash$ndeployment can be performed by copying closures of components under$\backslash$r$\backslash$nthe dependency relation.$\backslash$r$\backslash$n $\backslash$r$\backslash$nDevelopers and users are not confronted with components' cryptographic$\backslash$r$\backslash$nhashes directly. Components are built automatically from Nix$\backslash$r$\backslash$nexpressions, which describe how to build and compose arbitrary$\backslash$r$\backslash$nsoftware components; hashes are computed as part of this process.$\backslash$r$\backslash$nComponents are automatically made available to users through "user$\backslash$r$\backslash$nenvironments", which are synthesised sets of activated components.$\backslash$r$\backslash$nUser environments enable atomic upgrades and rollbacks, as well as$\backslash$r$\backslash$ndifferent sets of activated components for different users.$\backslash$r$\backslash$n $\backslash$r$\backslash$nNix expressions provide a source-based deployment model. However,$\backslash$r$\backslash$nsource-based deployment can be transparently optimised into binary$\backslash$r$\backslash$ndeployment by making pre-built binaries (keyed on their cryptographic$\backslash$r$\backslash$nhashes) available in a shared location such as a network server. This$\backslash$r$\backslash$nis referred to as transparent source/binary deployment.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThe purely functional deployment model has been validated by applying$\backslash$r$\backslash$nit to the deployment of more than 278 existing Unix packages. In$\backslash$r$\backslash$naddition, this thesis shows that the model can be applied naturally to$\backslash$r$\backslash$nthe related activities of continuous integration using build farms,$\backslash$r$\backslash$nservice deployment and build management.},
|
||||||
|
author = {Utrecht, Universiteit and Magnificus, Rector},
|
||||||
|
booktitle = {Utrecht University},
|
||||||
|
doi = {10.1007/s12630-009-9179-6},
|
||||||
|
file = {:home/steveej/src/github/steveej/msc-thesis/papers/nix-phd-thesis.pdf:pdf},
|
||||||
|
isbn = {9039341303},
|
||||||
|
issn = {14968975},
|
||||||
|
number = {12},
|
||||||
|
pages = {0--281},
|
||||||
|
pmid = {19728000},
|
||||||
|
title = {{The Purely Functional Software Deployment Model}},
|
||||||
|
url = {http://www.st.ewi.tudelft.nl/{~}dolstra/pubs/phd-thesis.pdf},
|
||||||
|
volume = {56},
|
||||||
|
year = {2006}
|
||||||
|
}
|
||||||
Loading…
Add table
Add a link
Reference in a new issue