guix-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

03/03: reppar: Arrange VM pros and cons in columns.


From: Ricardo Wurmus
Subject: 03/03: reppar: Arrange VM pros and cons in columns.
Date: Fri, 21 Aug 2015 13:33:41 +0000

rekado pushed a commit to branch master
in repository maintenance.

commit 474cbff56ac2a314579cb3f92f401a2a10663a05
Author: Ricardo Wurmus <address@hidden>
Date:   Fri Aug 21 15:33:08 2015 +0200

    reppar: Arrange VM pros and cons in columns.
---
 talks/reppar-2015/talk.tex |   94 +++++++++++++++++++++++---------------------
 1 files changed, 49 insertions(+), 45 deletions(-)

diff --git a/talks/reppar-2015/talk.tex b/talks/reppar-2015/talk.tex
index 83d4c78..294f367 100644
--- a/talks/reppar-2015/talk.tex
+++ b/talks/reppar-2015/talk.tex
@@ -230,51 +230,55 @@
   % how a base image is to be modified to reach the desired state.
 
   \Large{
-    Pros:
-    \begin{itemize}
-      % It's bit-reproducible in the sense that you essentially
-      % publish the bits.
-    \item ``bit-reproducible''
-
-      % Virtualization is wide-spread and is "proven technology" with
-      % few surprises, making it simple for anyone to reuse an image.
-    \item reproducible anywhere by anyone
-    \end{itemize}
-  }
-
-  \Large{
-    Problems:
-    \begin{itemize}
-      % VMs are heavyweight, which means they are unsuited for HPC.
-      % * hardware support + KVM + in-kernel page deduplication help, but still
-    \item VMs are heavyweight
-
-      % VM images are completely opaque, binary artifacts: how can I
-      % reproduce them?
-      % Likewise, Dockerfiles describe steps to modify an opaque base
-      % image.  How was the base image produced?  Do the binary
-      % packages of the base system really correspond
-      % to the source they claim to come from?
-
-      % In both cases, inspection is difficult: we're given a pizza,
-      % but not its recipe.
-      % * {image of frozen pizza}
-      % * {image of a very detailed recipe}
-    \item binary images are opaque
-
-      % The full system image is standalone by definition.  There is
-      % no way to use the software embedded in the image *alongside*
-      % other software packages I may need.
-
-      % For example, there is no way to use, say, the library that's
-      % inside the system image as-is in my own software system.
-
-      % This encourages bad habits: modifying the image
-      % state by building additional software in an ad-hoc
-      % manner---we're giving up on isolation and good system
-      % administration techniques.
-    \item not composable
-    \end{itemize}
+  \begin{columns}
+    \begin{column}[t]<2->{0.5\textwidth}
+      Pros:
+      \begin{itemize}
+        % It's bit-reproducible in the sense that you essentially
+        % publish the bits.
+      \item ``bit-reproducible''
+
+        % Virtualization is wide-spread and is "proven technology" with
+        % few surprises, making it simple for anyone to reuse an image.
+      \item reproducible anywhere by anyone
+      \end{itemize}
+    \end{column}
+
+    \begin{column}[t]<3->{0.5\textwidth}
+      Problems:
+      \begin{itemize}
+        % VMs are heavyweight, which means they are unsuited for HPC.
+        % * hardware support + KVM + in-kernel page deduplication help, but 
still
+      \item VMs are heavyweight
+
+        % VM images are completely opaque, binary artifacts: how can I
+        % reproduce them?
+        % Likewise, Dockerfiles describe steps to modify an opaque base
+        % image.  How was the base image produced?  Do the binary
+        % packages of the base system really correspond
+        % to the source they claim to come from?
+
+        % In both cases, inspection is difficult: we're given a pizza,
+        % but not its recipe.
+        % * {image of frozen pizza}
+        % * {image of a very detailed recipe}
+      \item binary images are opaque
+
+        % The full system image is standalone by definition.  There is
+        % no way to use the software embedded in the image *alongside*
+        % other software packages I may need.
+
+        % For example, there is no way to use, say, the library that's
+        % inside the system image as-is in my own software system.
+
+        % This encourages bad habits: modifying the image
+        % state by building additional software in an ad-hoc
+        % manner---we're giving up on isolation and good system
+        % administration techniques.
+      \item not composable
+      \end{itemize}
+    \end{column}
+  \end{columns}
   }
 \end{frame}
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]