text:
assignmentutor™您的专属作业导师

assignmentutor-lab™ 为您的留学生涯保驾护航 在代写概率与统计Probability and Statistics方面已经树立了自己的口碑, 保证靠谱, 高质且原创的统计Statistics代写服务。我们的专家在代写概率与统计Probability and Statistics方面经验极为丰富，各种代写概率与统计Probability and Statistics相关的作业也就用不着说。

• Statistical Inference 统计推断
• Statistical Computing 统计计算
• (Generalized) Linear Models 广义线性模型
• Statistical Machine Learning 统计机器学习
• Longitudinal Data Analysis 纵向数据分析
• Foundations of Data Science 数据科学基础

## 统计代写|概率与统计作业代写Probability and Statistics代考|Sampling Plans and Estimates

In the previous chapter we computed descriptive statistics for the dataset on faces. The results showed that the average rating was $58.37$ and that men rated the faces higher than women on average. If we are only interested in the participants in the study and we are willing to believe that the results are fully deterministic, ${ }^1$ we could claim that the group of men rates higher than the group of women on average. However, if we believe that the ratings are not constant for one person for the same set of faces ${ }^2$ or if we would like to know whether our statements would also hold for a larger group of people (who did not participate in our experiment), we must understand what other results could have been observed in our study if we had conducted the experiment at another time with the same group of participants or with another group of participants.

To be able to extend your conclusions beyond the observed data, which is called more technically statistical inference, you should wonder where the dataset came from, how participants were collected, and how the results were obtained. For example, if the women who participated in the study of rating faces all came from one small village in the Netherlands, while the men came from many different villages and cities in the Netherlands, you would probably agree that the comparison between the average ratings from men and women becomes less meaningful. In this situation the dataset is considered selective towards women in the small village. Selective means here that not all women from the villages and cities included in the study are represented by the women in the study, but only a specific subgroup of women have been included. To overcome these types of issues, we need to know about the concepts of population, sample, sampling procedures, and estimation of population characteristics, and also how these concepts are related to each other to be able to do proper statistical inference.

Figure $2.1$ visualizes the relation between these concepts. On the left side we have a population of units (e.g., all men and women from the Netherlands) and on the right side we have a subset of units (the sample). Sampling procedures are formal probabilistic approaches to help collect units from the population for the sample. For the sample we like to use $x_1, x_2, \ldots, x_n$ for the observations of a certain variable (e.g., ratings on faces from pictures). The calculations on the sample data, which we have learned in Chap. 1, are ways of describing the sample. For the population the same notation $x_1, x_2, \ldots, x_N$ for all $N$ units is used. Here we have used the same indices for the sample and the population, but this does not mean that the sample $x_1$, $x_2, \ldots, x_n$ is just the first $n$ units from the population $x_1, x_2, \ldots, x_N$. Mathematically. we should have written $x_{i_1}, x_{i_2}, \ldots, x_{i_n}$ for the sample data, with $i_h \in{1,2, \ldots, N}$ and $i_h \neq i_l$ when $h \neq l$, since any set of units $i_1, i_2, \ldots, i_n$ from the population could have ended up in the sample. The values in the sample are referred to as a realization from the population.

## 统计代写|概率与统计作业代写Probability and Statistics代考|Definitions and Standard Terminology

In this section we briefly introduce some definitions and standard terminology. Frequently, we wish to say something about a group of units other than just the ones we have measured. A unit is usually a concrete or physical thing for which we would like to measure its characteristics. In medical research and the social sciences units are mostly human beings, while in industry units are often products, but units can essentially be anything: text messages, financial transitions, sales, etc. The complete set of units that we would like to say something about is called the (target) population. The set of units for which we have obtained data is referred to as the sample. The sample is typically a subset of the population, although in theory the sample can form the whole population or the sample can contain units that are not from the target population. If we are interested in individuals in the age range of 25 years to 65 years, it could happen that a person with an age outside this range is accidently included in the sample.

Statistics is concerned with how we can say things, and what we can say, about a population given that we have only observed our sample data. As we mentioned before, we call this statistical inference: “Statistical inference is the process of deducing properties of an underlying population by analysis of the sample data. Statistical inference includes testing hypotheses for the population and deriving population estimates.”, see e.g., Casella and Berger (2002).

In many situations it is unnecessary to specify the unit explicitly since it will be clear from the context, but it is not always easy to determine the unit. For instance,a circuit board contains many different components. Testing the quality of a circuit board after it has been produced requires the testing of all or a subset of the components. In this case it is not immediately clear whether the circuit board itself or whether the components are the units. In this setting the circuit board is sometimes referred to as the sample unit, since it is the unit that is physically taken from the production process. The components on the circuit board are referred to as observation units, since it is the unit that is measured. If the components were to be tested before being placed on the circuit board, however, the component would represent both the sample and observation unit. ${ }^4$

# 概率与统计作业代考

.

.

## 有限元方法代写

assignmentutor™作为专业的留学生服务机构，多年来已为美国、英国、加拿大、澳洲等留学热门地的学生提供专业的学术服务，包括但不限于Essay代写，Assignment代写，Dissertation代写，Report代写，小组作业代写，Proposal代写，Paper代写，Presentation代写，计算机作业代写，论文修改和润色，网课代做，exam代考等等。写作范围涵盖高中，本科，研究生等海外留学全阶段，辐射金融，经济学，会计学，审计学，管理学等全球99%专业科目。写作团队既有专业英语母语作者，也有海外名校硕博留学生，每位写作老师都拥有过硬的语言能力，专业的学科背景和学术写作经验。我们承诺100%原创，100%专业，100%准时，100%满意。

## MATLAB代写

MATLAB 是一种用于技术计算的高性能语言。它将计算、可视化和编程集成在一个易于使用的环境中，其中问题和解决方案以熟悉的数学符号表示。典型用途包括：数学和计算算法开发建模、仿真和原型制作数据分析、探索和可视化科学和工程图形应用程序开发，包括图形用户界面构建MATLAB 是一个交互式系统，其基本数据元素是一个不需要维度的数组。这使您可以解决许多技术计算问题，尤其是那些具有矩阵和向量公式的问题，而只需用 C 或 Fortran 等标量非交互式语言编写程序所需的时间的一小部分。MATLAB 名称代表矩阵实验室。MATLAB 最初的编写目的是提供对由 LINPACK 和 EISPACK 项目开发的矩阵软件的轻松访问，这两个项目共同代表了矩阵计算软件的最新技术。MATLAB 经过多年的发展，得到了许多用户的投入。在大学环境中，它是数学、工程和科学入门和高级课程的标准教学工具。在工业领域，MATLAB 是高效研究、开发和分析的首选工具。MATLAB 具有一系列称为工具箱的特定于应用程序的解决方案。对于大多数 MATLAB 用户来说非常重要，工具箱允许您学习应用专业技术。工具箱是 MATLAB 函数（M 文件）的综合集合，可扩展 MATLAB 环境以解决特定类别的问题。可用工具箱的领域包括信号处理、控制系统、神经网络、模糊逻辑、小波、仿真等。

assignmentutor™您的专属作业导师
assignmentutor™您的专属作业导师


text:
# function

## Several ways to apply a (multivalued) multiargument function to a family of filters ★★★

Author(s): Porton

Problem   Let be an indexed family of filters on sets. Which of the below items are always pairwise equal?

1. The funcoid corresponding to this function (considered as a single argument function on indexed families) applied to the reloidal product of filters .

2. The funcoid corresponding to this function (considered as a single argument function on indexed families) applied to the starred reloidal product of filters .

3. .

Keywords: funcoid; function; multifuncoid; staroid

format: plain


text:
Time: Saturday, 9:00-10:00

Title: Repetitions in labeled trees

Abstract:

Repetitions in strings are one of fundamental notions of algorithmics and combinatorics of strings. A basic type of repetitions are string powers, in particular, squares and cubes. In this talk I consider string powers in edge-labeled trees, that is, paths such that the sequence of symbols on a path forms a string power of a given exponent.

A classical bound related to squares in a string is that a string of length n contains at most 2n different squares. Moreover, all different squares in a string can be computed in linear time. It turns out that in trees the number of squares behaves totally differently. Denote by $$\text{powers}_p(n)$$ the maximum number of different string powers of exponent p in a tree of n nodes. Then $$\text{powers}_2(n)$$ is exactly of the order $$n^{4/3}$$, and both the lower and the upper bound is obtained using a special family of trees called combs. The number of different squares for a tree of n nodes, together with an O(n)-sized representation of all the different squares in a tree, can be computed in $$O(n\log^2 n)$$ time. This algorithm uses efficient versions of multiple classical string algorithms in the context of trees.

For any smaller fractional exponent p<2, already in the case of strings we have $$\text{powers}_p(n) = \Omega(n^2).$$ For trees, the second phase transition of this function takes place for cubes: for any fractional $2 < p < 3$, $\text{powers}_p(n) = \Omega(n^{4/3})$, whereas $\text{powers}_3(n) = O(n \log n)$. We also present some results on powers with higher exponent. Some results from this talk have been published at CPM 2012 and ISAAC 2012 conferences and also in the Theoretical Computer Science journal in 2014.


text:
### File testfile.tex of Package latex2html

\documentclass[a4paper]{article}
%\usepackage{graphicx}
%\usepackage{subfigure}
\usepackage[utf8]{inputenc}
\usepackage{url}
%\usepackage{times}

\usepackage[pdftex,
pdfauthor={Andreas Gruenbacher and Seth Arnold},
pdftitle={AppArmor Technical Documentation},%
\ifx\fixedpdfdate\@empty\else
pdfcreationdate={\fixedpdfdate},
pdfmoddate={\fixedpdfdate},
\fi
pdfsubject={AppArmor},
pdfkeywords={AppArmor}
]{hyperref}

\hyphenation{App-Armor}
\hyphenation{name-space}

\renewcommand{\H}{\hspace{0pt}}

\title{AppArmor Technical Documentation}
\author{Andreas Gruenbacher and Seth Arnold \\
\url{{agruen,seth.arnold}@suse.de} \\
SUSE Labs / Novell}
% don't include the (build!) date
\date{}

\begin{document}

\maketitle

\tableofcontents

\newpage

%\begin{abstract}
%\end{abstract}

\section{Introduction}

In this paper we describe AppArmor from a technical point of view,
introduce its concepts, and explain the design decisions taken.  This
text is intended for people interested in understanding why AppArmor
works the way it does.  You may be looking for less detailed, low-level,
or kernel centric documentation; in that case, please refer to the
AppArmor documentation web site~\cite{apparmor}.

Sections~\ref{sec:overview} and ~\ref{sec:model} discuss the AppArmor
security model, while Section~\ref{sec:walk-through} shows how to use it
from a low-level point of view.  Please be aware that lots of details
are discussed here which the higher-level tools hide from the average
user.

\section{Overview}
\label{sec:overview}

AppArmor protects systems from insecure or untrusted processes by
running them in confinement, still allowing them to share files with
other parts of the system, exercising privilege, and communicating with
other processes, but with some restrictions.  These restrictions are
mandatory; they are not bound to identity, group membership, or object
ownership.  In particular, the restrictions also apply to processes
running with superuser privileges.  AppArmor achieves this by plugging
into the Linux Security Module (LSM) framework.  The protections
provided are in addition to the kernel's regular access control
mechanisms.

The AppArmor kernel module and accompanying user-space tools are
available under the GPL license. (The exception is the libapparmor
library, available under the LGPL license, which allows change\_hat(2)
to be used by non-GPL binaries.)

At the moment, AppArmor knows about two types of resources: files, and
resources, AppArmor can effectively prevent confined processes from
accessing files in unwanted ways, from executing binaries which they are
not meant to execute, and from exercising privileges such as acting on
behalf of another user (which are traditionally restricted to the
superuser).

One use case for this kind of protection is a network daemon: even if
the daemon is broken into, the additional restrictions imposed by
AppArmor will prevent the attacker from attaining additional privileges
beyond what the daemon is normally allowed to do.  Because AppArmor
controls which files a process can access in which ways down to the
individual file level, the potential damage is much limited.

like ulimits, and interprocess and network communication, but at this
time, these resource types are not covered.  This is less severe than it
might initially seem: in order to attack another process from a
broken-into process like a network daemon, that other process has to
actively listen.  The set of actively listening processes is relatively
small, and this sort of interprocess communication is a natural security
boundary, so listening processes should be validating all their input
already.  For protection against bugs in the input validation of those
processes, they should also be confined by AppArmor though, thus further
limiting the potential damage.

AppArmor protection is selective: it only confines processes for which
policies (referred to as profiles) have been defined.  All other
processes will continue to run unrestricted by AppArmor.

To confine a process, all it takes is to write a profile for it, take an
existing profile, or automatically generate a profile: for the latter,
the process can be run in \textit{learning} or \textit{complain} mode in
which AppArmor allows all accesses, and logs all accesses that are not
allowed by the current profile already. This log can then be used to
automatically generate a suitable new profile, or refine an existing
one.  The application does not need to be modified.

An example profile together with a complete low-level walk-through of
AppArmor can be found in Section~\ref{sec:walk-through}.  The
apparmor.d(5) manual page contains further details.

AppArmor is not based on labeling or label-based access and transition
rules, so it does not stick a label on each each file in the file system
(or more generally, on each object).  It identifies files by name rather
replaces it with a copy (that may have an additional user in it, for

\section{The AppArmor Security Model}
\label{sec:model}

When a file is accessed by name with open(2), mkdir(2), etc., the kernel
looks up the location of the object associated with the specified
pathname in the file system hierarchy. The lookup is relative to the
root directory for pathnames starting with a slash, and to the current
working directory otherwise. Different processes can have have different
working directories as well as different root directories. See
path\_resolution(2) for a detailed discussion of how pathname resolution
works.

Either way, the result of the lookup is a pair of (dentry, vfsmount)
kernel-internal objects that uniquely identify the location of the file
in the file system hierarchy. The dentry points to the object if the
object already exists, and is a placeholder for the object to be created
otherwise.

AppArmor uses the (dentry, vfsmount) pair to compute the pathname of the
file within a process's filesystem namespace. The resulting pathname
contains no relative pathname components (.'' or ..''), or symlinks.

AppArmor checks if the current profile contains rules that match this
pathname, and if those rules allow the requested access.  Accesses
that are not explicitly allowed are denied.

When looking up the (dentry, vfsmount) pair of a file, the kernel
resolution is inappropriate).

The pathname that AppArmor computes from a (dentry, vfsmount) pair never
directories for paths like /tmp, profiles need to be adjusted
accordingly.  A future version of AppArmor may have built-in support
for this kind of pathname rewriting.

\subsection{Namespaces}

Linux allows different processes to live in separate namespaces, each of
which forms an independent file system hierarchy.  A recent paper by Al
Viro and Ram Pai~\cite{ols06-pai} discusses all the intricate things
possible with namespaces in recent 2.6 kernels.

From the point of view of a process, an absolute path is a path that
goes all the way up to the root directory of that process.  This is
ambiguous if processes have different root directories.  Therefore,
instead of paths relative to process root directories, AppArmor uses
paths relative to the namespace root.

Pathnames are meaningful only within a namespace.  Each namespace has a
root where all the files, directories, and mount points are hanging off
from.

The privilege of creating new namespaces is bound to the
CAP\_{\H}SYS\_{\H}ADMIN capability, which grants a multitude of other
things that would allow a process to break out of AppArmor confinement,
so confined processes are not supposed to have this privilege, and
processes with this capability need to be considered trusted.

In this setup, privileged processes can still create separate namespaces
and start processes in those namespaces; processes confinement will be
relative to whatever namespace a process ends up in.  It is unclear
at this point how AppArmor should support separate namespaces --- either
by computing all pathnames relative to one particular namespace
considered global (assuming that such a globally meaningful namespace
will exist in all setups in which AppArmor is relevant), or by allowing
different sets of profiles to be associated with different namespaces.

\subsection{Disconnected Files and Pseudo File Systems}

In some situations, a process can end up with a file descriptor or
working directory that was looked up by name at some point, but is not
connected to the process's namespace anymore (and hasn't been deleted,
either).  This can happen when file descriptors are passed between
processes that do not share the same namespace, or when a file system
has been lazily unmounted (see the MNT\_DETACH flag of umount2(2)).  Such
files may still be visible to other processes, and they may become
reconnected.  AppArmor cannot compute the pathnames of such files.
Granting unrestricted access would be insecure, and so AppArmor denies

As a special case, the kernel supports a number of file systems that
users can have file descriptors open for, but that can never be mounted.
Those files are by definition disconnected.  Anonymous pipes, futexes,
inotify, and epoll are all examples of that.  Accesses to those files
is always allowed.

Future versions of AppArmor will have better control over disconnected
files by controlling file descriptor passing between processes.

\subsection{Mount}

Mounting can change a process's namespace in almost arbitrary ways.
This is a problem because AppArmor's file access control is pathname
based, and granting a process the right to arbitrarily change its
namespace would subvert this protection mechanism.  AppArmor therefore
umount2(2) system calls.

Future versions of AppArmor may offer fine-grained control over mount,
and may grant confined processes specific mount operations.

\subsection{The Kernel NFS Daemon}

The security model of the various versions of NFS is that files are
looked up by name as usual, but after that lookup, each file is only
identified by a file handle in successive acesses.  The file handle at a
minimum includes some sort of filesystem identifier and the file's inode
number.  In Linux, the file handles used by most filesystems also
include the inode number of the parent directory; this may change in the
future.  File handles are persistent across server restarts.

This means that when the NFS daemon is presented with a file handle,
clients must get access without having specified a pathname.  A pathname
can be computed from a (parent, child) inode pair that identifies the
file down to the directory level if the dentry is properly connected to
the dcache, but multiple hardlinks to the same file within the same
directory cannot be distinguished, and properly connecting dentries
comes at a cost in the NFS daemon.  Because of this overhead and the
questionable benefit, most setups do not guarantee that dentries will be
connected, and so pathnames cannot always be computed.  (See the
no\_subtree\_check option in exports(5).)

In addition, the NFS daemon is implemented in the kernel rather than as
a user space process.  There is no memory separation or other protection
between the daemon and the rest of the kernel.  This means that at best,
the NFS daemon could cooperate with an additional access control
mechanism like AppArmor --- but there would be no enforcement.

Because of all of this, it makes little sense to put the kernel NFS
profiles to the kernel nfsd daemons.

\subsection{Why are the computed pathnames meaningful?}

Whenever a process performs a name-based file access, the pathname or
pathname component always refers to a specific path to that file: the
path is either relative to the chroot if an absolute path is used, or
else relative to the current working directory.  The chroot or current
working directory always has a unique pathname up to the namespace root
(even if the process itself has no direct access above the chroot).
This means that each name-based file access maps to a unique, canonical,
absolute pathname.  There may be additional paths pointing to the same
file, but a particular name-based access still always refers to only one
of them.  These are the pathnames that AppArmor uses for permission
checks.

If directories along the path get renamed after a process changes into
them (either with chroot(2) or with chdir(2)), the resulting pathname
will differ from the pathnames that the process used.  Consider the
following sequence of operations for example:

\begin{tabbing}
\begin{tabular}{ll}
\textbf{Process 1}		& \textbf{Process 2} \\
chdir("/var/tmp/foo"); & \\
& rename("/var/tmp/foo", "/var/tmp/bar"); \\
creat("baz", 0666); 	& \\
\end{tabular}
\end{tabbing}

The creat operation will check against the path
/var/tmp/\textit{bar}/baz, even though Process~1 never used
\textit{bar.}  This is the expected behavior; we are interested in the
names of the objects along the path at the time of the access, not in
their previous names.

As already mentioned, a path lookup results in a pair of (dentry,
vfsmount) kernel-internal objects.  The pathname that AppArmor checks
against is computed from these two objects after these objects have been
looked up. The lookup and the pathname computation are not atomic, which
means that pathname components could even be renamed after the lookup
but before the pathname has been computed.

It matters that the AppArmor access check is performed between the lookup and
the actual access, but atomicity between the lookup and that access
check is not necessary: there is no difference between a rename before
the lookup and a rename after the lookup from AppArmor's point of view;
all we care about is the current pathname at some point between the
lookup and the access.

A special case occurs when the lookup succeeds, but the file is deleted
before the AppArmor access check. In this case the access is denied and
errno is set to ENOENT, the same behavior as if the lookup had failed.

\subsection{Path Permission Checking}

On UNIX systems, when files are looked up by name, the lookup starts
either at the root or the current working directory of a process.  From
there, each directory reached is checked for search permission (x).  The
permissions on the directories leading to the current working directory
are not checked.  When a file is being created or deleted, the parent
directory of that file is checked for write and search access (wx).
When a file is being accessed, the permissions of that file are checked
for r, w, or x access, or a combination thereof.  Each check can result
in a failure with errno set to EACCES (Permission denied).

In contrast, AppArmor first computes the pathname to a file.  If a file
is being created, the name being looked up is the name of the new file
and not the name of the parent directory.

If the file being looked up is a directory, AppArmor appends a slash to
the pathname so that directory pathnames always end in a slash;
otherwise the pathname will not end in a slash.

It then checks for file access rules in the process's profile that match
that pathname, and decides based on that.  With some exceptions for
execute modes as described in Section~\ref{sec:merging}, the permissions
granted are the union of permissions of all matching rules.

\subsection{Profile Permissions}
\label{sec:permissions}

AppArmor differentiates between slightly more permissions than UNIX
does, as shown in Table~\ref{tab:permissions}: file access rules in
AppArmor support the read (r), write (w), execute (x), memory map as
executable (m), and link (l) permissions.  The execute permission
requires a modifier that further specifies which kind of execution is
being granted: inherit the current profile (ix), use the profile defined
for that executable (px), or execute unconfined without a profile (ux).
In addition, the px and ux permissions have Px and Ux forms that will
trigger Secure Execution (see Section~\ref{sec:secure-exec} below).
The different permissions are used as follows:

\begin{table}[tb]
\center
\begin{tabular}{|l|l|}
\hline
w	& Write.						\\
ix	& Execute and inherit the current profile.		\\
px	& Execute under a specific profile.			\\
Px	& Execute secure and under a specific profile.		\\
ux	& Execute unconfined.					\\
Ux	& Execute secure and unconfined.			\\
m	& Memory map as executable.				\\
\hline
\end{tabular}
\caption{File Access Permissions in Profiles}
\label{tab:permissions}
\end{table}

\begin{description}

The profile read permission is required by all system calls that
require the UNIX read permission. This includes open with
O\_RDONLY, getdents (i.e., readdir), listxattr, getxattr, and

\item[Write.]
The profile write permission is required by all system calls
that require the UNIX write permission, except for operations
the parent directory, AppArmor requires write access on the new
file in this case (which does not exist at the time of the
permission check for file creates).  Operations that create
files include open with O\_CREAT, creat, mkdir, symlink, and
mknod.  Operations that remove files include rename, unlink and
rmdir.

Operations that require write access in UNIX as well as AppArmor
include open with O\_WRONLY (O\_RDWR requires read and write),
setxattr, removexattr, and mmap with PROT\_WRITE.

Other system calls such as chmod, chown, utime, and utimes are
bound to file ownership or the respective capabilities in UNIX.
AppArmor also requires profile write access for those operations.

\item[Execute.]
As mentioned above, AppArmor distinguishes a few different ways
how files may be executed as described above.

For directories, the UNIX execute permission maps to search
access.  AppArmor does not control directory search access.
Traversing directories is always granted.

\item[Memory map as executable.]
to memory map them for execution with the PROT\_EXEC flag.
AppArmor makes a distinction here, and requires the m profile
permission in order for files to be mapped as executable.  That way,
it is more obvious in profiles what applications are allowed to do even
if from a security point of view, the m permission provides a similar
level of protection as the ix permission --- execute under the current
profile.

Creating a hardlink requires the profile link permission (l) on the new
path.  In addition, the new path must have a subset of the r, w, x, and
m permissions of the old path, and if the new path has the x permission,
the execute flags (i, u, U, p, and P) of the old and the new path must
be equal.

\item[Rename.]
A rename requires profile read and write access for the source
file, and profile write access for the target file.

\item[Stat.]
Retrieving information about files is always allowed. We believe
that providing policy for file information retrieval is more
troublesome than the benefit it would provide.

\end{description}

\subsection{System Calls Taking File Handles, At System Calls}

A number of system calls take file descriptors instead of pathnames as
their parameters (ftruncate, fchmod, etc.), or take directory file
descriptors, and resolve pathnames relative to those directories
(openat, mkdirat, etc.).  These system calls are treated like their
non-f and non-at equivalents, and the same access checks are performed.
At the point where AppArmor is asked to validate those file accesses, it
is passed a (dentry, vfsmount) pair no matter which system call variant
is used.

\subsection{File Descriptor Passing and Revalidation}

After a file descriptor has been obtained, the permitted accesses (read
and/or write) are encoded in the file descriptor, and reads and writes
are not revalidated against the profile for each access.  This is
consistent with how access checks are done in UNIX; such access checks
would have a severe performance impact.

The picture changes when a file descriptor is passed between processes
and the other process is running under a different profile, or when a
process switches profiles: in that case, read and write accesses are
revalidated under the new profile.  If the new profile does not allow
them, the access is denied and errno is set to EACCES (Permission
denied).

File descriptors opened by unconfined processes are exempt from this
rule.  This is so that processes will still have access to their stdin,
stdout, and stderr without having to list all possible sources of input
and output in all profiles.

\subsection{Deleted Files}

Revalidation is problematic for deleted files for which a process still
has an open file descriptor --- after all, the idea of the pathname of a
deleted file is somewhat peculiar: the file is no longer reachable by
any pathname, and it also cannot become re-attached to the filesystem
namespace again.

The traditional UNIX behavior is to determine access upon file access,
and to never check again. Applications depend on this, particularly for
temporary files.  In addition to temporary files, deleted files can be
used as an interprocess communication mechanism if the file descriptor
is shared among multiple processes.

files opened by unconfined processes.  It may control interprocess
communication, including file descriptor passing, in a future version.

\subsection{The access System Call}

This system call determines whether a process has a given mode of access
to a file in terms of the read, write, and execute permissions.  This is
not a sufficient replacement for performing the access check at the time
of access even under traditional UNIX, because the access system call
and the subsequent access are not atomic, and the permissions might
change between the two operations. Applications are not supposed to rely
on access(2).

AppArmor introduces additional restrictions, some of which cannot be
modeled in terms of read, write, and execute: for example, an AppArmor
profile may allow a process to create files /tmp/foo-*, but not any
other files in /tmp.

There is no way to express this with access(2); in traditional UNIX, all
that is required for creating files is write access to the parent
directory.  Access(2) will indicate that some accesses are allowed even
when AppArmor will eventually deny them.

\subsection{The ptrace System Call}

The ability to ptrace allows a process to look up information about
another process, read and write the memory of that process, and attach
to (or trace) that process in order to debug it, or analyze its
behavior.  This gives total control over the process being traced, and
so the kernel employs some restrictions over which processes may ptrace
with other processes.

In addition to these restrictions, AppArmor requires that if the tracing
task is confined, it must either have the CAP\_{\H}SYS\_{\H}PTRACE capability,
or be confined by the same profile and sub-profile as the process being
traced.  Attempts to switch to another profile or sub-profile by a
process being traced is denied.

\subsection{Secure Execution}
\label{sec:secure-exec}

In this mode, the kernel passes a flag to user space.  When glibc finds
this flag set, it unsets environment variables that are considered
controlled by the environment.  With non-secure exec, the
LD\_LIBRARY\_PATH environment variable can be used to switch to a
different set of libraries, for example.  The secure exec mechanism is
not specific to AppArmor: set-user-id and set-group-id executables also
use it, as well as SELinux, which introduced this glibc feature.

\subsection{Exec Mode Merging in Profiles, Exact Matches}
\label{sec:merging}

When more than one rule in a profile matches a given path, all the
permissions accumulate except for ix, px, Px, ux, and Ux: those
permissions would conflict with each other; it would be unclear how to
execute the new binary if more than one of these flags was set.  To deal
with this situation, AppArmor differentiates between rules that define
exact matches and wildcard rules (see Table~\ref{tab:globbing} on
page~\pageref{tab:globbing}).  Execute flags in exact matches override
execute flags in wildcard matches.

If the execute flags of multiple rules still disagree, the profile is

\subsection{Capabilities}

AppArmor uses the standard Linux capability mechanism.  When the kernel
checks if a certain capability can be exercised, AppArmor additionally
checks if the current profile allows the requested capability, and
rejects the use of the capability otherwise.

\subsection{The sysctl System Call and /proc/sys}

The sysctl system call and files below /proc/sys
can be used to read and modify various kernel parameters.  Root processes
can easily bring the system down by setting kernel parameters to invalid
values.  To prevent against that, AppArmor denies confined processes
parameters.

\subsection{Subprofiles aka. Hats}

Profiles can contain subprofiles that processes may switch to from the
main profile.  Switching from a subprofile into a sibling subprofile or
back to the parent profile is allowed depending on how the subprofile
was entered, and provided that the child knows a magic cookie.\footnote{
\textbf{A word of warning about change\_hat(2):} When used with a
non-zero magic cookie for changing into a subprofile, that magic
cookie can be used to change back out of the subprofile; in this
mode, change\_hat(2) is not a strong confinement mechanism. If the
code running in the subprofile can guess the magic cookie, it can
break out of the subprofile.  Likewise, if that code can manipulate
the processes' behavior beyond the point where the process returns
from the subprofile, it can influence what is done under the parent
profile. Therefore, change\_hat(2) with a non-zero magic cookie is
only safe in combination with restricted code environments, such as
when the subprofile is used for executing Safe Perl (see Safe(3pm)),
etc.
} See the change\_hat(2) manual page for details.

Each process may consist of multiple tasks.  Each task may only change
its own subprofile.  The superuser cannot put a task into a different
hat, but he can replace the entire profile and its subprofiles, or he
can put a process in a different top-level profile (see
Section~\ref{sec:association}).

Internally, change\_hat(2) is implemented by writing to a special
kernel-provided file.  This is equivalent to a command like:

\begin{small}
\begin{verbatim}
$echo "changehat 123^hat_name" > /proc/$PID/attr/current
\end{verbatim}
\end{small}

Here, the number is the magic cookie value, and hat\_name obviously is
the name of the hat; either may be replaced by the empty string (but not
both).

\subsection{Association of Profiles with Processes}
\label{sec:association}

Profiles are associated with kernel tasks, which roughly correspond to
threads in user space (see clone(2) for details).  Currently there are
two ways how a profile can be associated with a task: when an executable
is started and a profile is defined for that executable, or when the

In addition to that, once a task is confined by a profile, that profile
determines which other executables may be executed, and under which
profile they may run (under the profile defined for that executable, the
same profile as the current task, or unconfined; see
Section~\ref{sec:permissions}).

A process will consist of a single task after an exec, so in the exec
case, the entire process will be confined.  New tasks (threads as well
as processes) inherit the same profile and subprofile as their parent

Unconfined processes with the CAP\_{\H}SYS\_{\H}ADMIN privilege may assign a
profile to a task with a command like this:

\begin{small}
\begin{verbatim}
$echo "setprofile /name/of/profile" > \ /proc/$PID/attr/current
\end{verbatim}
\end{small}

After that, the task will be in the new top-level profile, even if the
process was in a subprofile before.

Processes with the CAP\_{\H}SYS\_{\H}ADMIN privilege as well as the process itself
can query the profile a process is in by reading from that file:

\begin{small}
\begin{verbatim}
$cat /proc/$PID/attr/current
unconfined

$cat /proc/$PID/attr/current
/name/of/profile (complain)

$cat /proc/$PID/attr/current
/name/of/profile^hat_name (enforce)
\end{verbatim}
\end{small}

The output includes the name of the profile and subprofile as well as
the mode the active profile is in.  (When a task is in a subprofile,
the subprofile is the active profile.)

Before the kernel can use any profiles, they must be loaded.  The
profile sources consist of plain text.  This text representation is
converted into in a binary representation that the kernel can more
easily deal with by the user-space profile loader.

Profiles contain potentially long lists of file access rules that may
include wildcards.  In order to make the lookup efficient, the AppArmor
kernel module does not actually go through all the file access rules
and compiles them into transition tables.  Pathnames are then looked up
in those tables with a simple and efficient algorithm, the theory behind
which is explained in the Lexical Analysis section of the Dragon
Book~\cite{dragon86}.

An init script loads all the known profiles into the kernel at an early
boot stage.  This happens automatically and the system administrator
they manipulate them, so end users will not usually notice this step.

Profiles can be replaced at any time during runtime, and all processes
running under old profiles will transparently be switched to the updated
versions.  Profiles can also be removed.  All processes running under a
profile that is removed will become unconfined.

Profiles are always replaced together with all their subprofiles.  It
may be that an updated profile no longer contains a specific subprofile.
If that happens while processes are using that subprofile, those
processes will be put in a profile that denies all accesses.  Such
processes may still change to sibling subprofiles or back to the parent
profile subject to the change\_hat(2) semantics.

\section{AppArmor Walk-Through}
\label{sec:walk-through}

AppArmor consists of a set of kernel patches and accompanying
user-space tools, both of which are available at
\url{http://developer.novell.com/wiki/index.php/Apparmor}.

\subsection{Kernel Patches and Configuration}

The AppArmor kernel patches are provided in a format convenient for use
with quilt,\footnote{
\url{http://savannah.nongnu.org/projects/quilt}
} however, other tools for applying the patches can be used, too. The
patches are supposed to apply against recent kernel.org git kernels. A
copy of the current git tree can be obtained from
\url{git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git}
with \textit{git clone} (see the \hbox{git-clone(1)} manual page).  In
case the the differences between the latest git tree and the tree the
AppArmor patches are based on is too big, the patches won't apply
cleanly.  In this case, trying an older git tree may work better.

After obtaining the AppArmor patches tarball and the git tree which will
end up in the linux-2.6 directory by default, the AppArmor patches can
be applied to the git tree as follows:

\begin{small}
\begin{verbatim}
$tar zxvf apparmor.tar.gz$ cd linux-2.6/
$ln -s ../apparmor patches$ quilt push -a
\end{verbatim}
\end{small}

When configuring the kernel, make sure that AppArmor is built in or as a
module (CONFIG\_{\H}SECURITY\_{\H}APPARMOR must be 'y' or 'm'). AppArmor
cannot be used together with other Linux Security Modules, so if
CONFIG\_{\H}SECURITY\_{\H}CAPABILITIES or CONFIG\_{\H}SECURITY\_{\H}SELINUX is
set to 'y', they must be disabled by adding \texttt{selinux=0} and/or
\texttt{capability.disable=1} to the kernel command line (grub, lilo,
yaboot, etc.).  It is not sufficient to put SELinux into permissive
mode ---  at this time, AppArmor cannot be combined with other LSMs.

\subsection{The securityfs file system}

AppArmor uses securityfs for configuration and to report information.
The usual mountpoint for securityfs is /sys/{\H}kernel/{\H}security.
Unless your distribution automatically does so, you can mount securityfs
with:

\begin{small}
\begin{verbatim}
$mount securityfs -t securityfs /sys/kernel/security \end{verbatim} \end{small} Once securityfs has been mounted and the apparmor module loaded, /sys/{\H}kernel/{\H}security/{\H}apparmor/{\H}profiles will show the profiles loaded into the kernel, as well as mark if the profiles are in enforcement mode or in learning mode: \begin{small} \begin{verbatim}$ cat /sys/kernel/security/apparmor/profiles
/usr/bin/opera (complain)
/usr/lib/firefox/firefox.sh (complain)
/sbin/lspci (enforce)
...
\end{verbatim}
\end{small}

AppArmor is also done via securityfs.

%/sys/kernel/security/apparmor/control/ control seldom-used features of AppArmor:
%  audit    if '1', audit all actions by confined processes
%  complain if '1', allow all actions by confined processes, report
%           accesses not granted by policy
%  debug    if '1', emit copius debugging
%  logsyscall  if '1', use audit framework's syscall debugging, if audit
%           has been instructed to create per-task contexts.[2]

apparmor\_parser utility from the apparmor-parser package. The
package can easily be built by running make in the package's top-level
directory.  Once that is done and the AppArmor module loaded, you may
use the parser to load profiles with:

\begin{small}
\begin{verbatim}
$echo "/tmp/ls { /tmp/ls rm, }" | apparmor_parser \end{verbatim} \end{small} Once a profile for a program has been loaded into the kernel, you must use the --replace option for replacing the existing profile with a new one (this option may be used even if no profile by that name exists): \begin{small} \begin{verbatim}$ echo "/tmp/ls { /tmp/ls rm, }" | apparmor_parser --replace
\end{verbatim}
\end{small}

\subsection{Anatomy of a Profile}

AppArmor profiles use a simple declaritive language, fully described in
the apparmor.d(5) manual page. By convention, profiles are stored in
/etc/{\H}apparmor.d/. The AppArmor parser supports a simple cpp-style
include mechanism to allow sharing pieces of policy.  A simple profile
looks like this:

\begin{small}
\begin{verbatim}
/bin/ls flags=(complain) {
/bin/ls rm,
/lib/ld-2.5.so rmix,
/etc/ld.so.cache rm,
/lib/lib*.so* rm,

/dev/pts/* w,

/proc/meminfo r,
/var/run/nscd/socket w,
/var/run/nscd/passwd r,
/var/run/nscd/group  r,

/tmp/ r,
}
\end{verbatim}
\end{small}

Here, the first /bin/ls is the name of the profile. This profile will be
automatically used whenever an unconfined process executes /bin/ls.  The
flags instruct AppArmor to put the profile in complain (aka. learning)
mode: in this mode, all operations are allowed, and any events that
would have been denied are logged.  This helps users to incrementally
deploy AppArmor in production environments.  The default if no flags are
specified is enforcement mode, in which all operations not allowed by
the profile are logged and denied.

Complain mode can be enabled individually for profiles as shown above
in complain mode with:

\begin{small}
\begin{verbatim}
$echo 1 > /sys/kernel/security/apparmor/control/complain \end{verbatim} \end{small} The user-space tools also include two small utilities, enforce and complain, which will put profiles into enforce or complain mode: \begin{small} \begin{verbatim}$ enforce firefox
Setting /usr/lib/firefox/firefox.sh to enforce mode.
\end{verbatim}
\end{small}

Inside the body of the profile are any number of rules consisting of a
pathname expression that may include globbing, and a set of permissions.
Table~\ref{tab:globbing} shows the supported shell-inspired globbing
constructs; Section~\ref{sec:permissions} on
page~\pageref{sec:permissions} describes the permissions.

\begin{table}[tb]
\center
\begin{tabular}{|l|l|}
\hline
{?}		&	Any single character except /''.		\\
{*}		&	Any number of characters except /''.		\\
{**}		&	Any number of characters including /''.	\\
{[ab]}		&	One of a'' or b''.				\\
{[a-c]}		&	One of a'', b'', or c''.			\\
\{ab,cd\}	&	Alternation: either ab'' or cd''.		\\
\hline
\end{tabular}
\caption{Globbing in File Access Rules. Alternation counts as an exact
match in file access rules; all others count as wildcards (see
Section~\ref{sec:merging}).}
\label{tab:globbing}
\end{table}

When AppArmor looks up a directory the pathname being looked up will end
with a slash (e.g., /var/tmp/), otherwise it will not.  Only rules
that match that trailing slash will match directories.  Some examples,
none matching the /tmp directory itself, are:

\begin{tabbing}
\begin{tabular}{ll}
{/tmp/*}	& Files directly in /tmp.				\\
{/tmp/*/}	& Directories directly in /tmp.				\\
{/tmp/**}	& Files and directories anywhere underneath /tmp.	\\
{/tmp/**/}	& Directories anywhere underneath /tmp.			\\
\end{tabular}
\end{tabbing}

As explained in Section~\ref{sec:model}, AppArmor does not require
directory to create or rename files inside the directory. Instead, write
access is required on the specific files that a confined process
attempts to create, remove, rename, etc.  Read access is required for
reading the contents of a directory.

AppArmor also mediates the use of POSIX 1003.1e draft capabilities;
capabilities that a process is allowed to use are listed in the
profile by their name in lower-case (with CAP\_'' stripped off), e.g.,

\begin{small}
\begin{verbatim}
#include <tunables/global>

/sbin/lspci {
#include <abstractions/base>
#include <abstractions/consoles>

/sbin/lspci mr,
/sys/bus/pci/ r,
/sys/bus/pci/devices/ r,
/sys/devices/** r,
/usr/share/pci.ids r,
}
\end{verbatim}
\end{small}

This profile uses predefined include files which are part of the
apparmor-profiles package.

\subsection{Logging}

AppArmor uses the kernel standard audit facility for reporting.  When a
profile is in complain mode, the log messages look like this:

\begin{small}
\begin{verbatim}
type=APPARMOR msg=audit(1174506429.573:1789): PERMITTING r access
to /home/sarnold/ (ls(16504) profile /tmp/ls active /tmp/ls)
\end{verbatim}
\end{small}

When a profile is in enforcement mode, the log messages look like this:

\begin{small}
\begin{verbatim}
type=APPARMOR msg=audit(1174508205.298:1791): REJECTING r access
to /bin/ (ls(16552) profile /tmp/ls active /tmp/ls)
\end{verbatim}
\end{small}

These log messages are sent to the kernel auditing facility; if auditd
is not running, the kernel will forward these messages to printk for
collection by klogd. Auditd must be configured with --with-apparmor to
enable the \#defines to handle AppArmor's message type correctly.

AppArmor also logs some important events in the process lifecycle,
such as when processes in learning mode fork and change domain via
exec. These other events, while not strictly related to permissions
requested by the process, help the genprof profile generation tool
reconstruct when specific accesses are required by processes --- this
allows the tool to make more relevant and meaningful policy suggestions.

\subsection{Generating Profiles By Hand}

While the majority of our users are expected to generate profiles with
the help of our profile tools, it is possible to write policy by hand.
This final section gives a very quick walkthrough generating a simple
profile for firefox.

Since the kernel resolves symlinks to their final destinations'' before
presenting AppArmor with policy questions, we first must see if
/usr/{\H}bin/{\H}firefox is a symlink or the shell script that starts firefox;
on our system, it is a symlink:

\begin{small}
\begin{verbatim}
$ls -l /usr/bin/firefox lrwxrwxrwx 1 root root 25 Mar 21 13:36 /usr/bin/firefox -> ../lib/firefox/firefox.sh \end{verbatim} \end{small} So we will start a profile for /usr/{\H}lib/{\H}firefox/{\H}firefox.sh. This shell script will execute firefox-bin, as we will see later; when it does so, we will tell AppArmor to inherit this profile. Thus, firefox-bin will be executing under the profile for /usr/{\H}lib/{\H}firefox/{\H}firefox.sh. To get started, we can make some assumptions about the privileges that firefox will need (both as a shell script and as a fairly complex GUI application): \begin{small} \begin{verbatim}$ cat /etc/apparmor.d/usr.lib.firefox.firefox.sh
/usr/lib/firefox/firefox.sh flags=(complain) {
/usr/lib/firefox/firefox.sh r,
/bin/bash rmix,
/lib/ld-2.5.so rmix,
/etc/ld.so.cache rm,
/lib/lib*.so* rm,
/usr/lib/lib*.so* rm,
}
/etc/apparmor.d/usr.lib.firefox.firefox.sh
Replacement succeeded for "/usr/lib/firefox/firefox.sh".
\end{verbatim}
\end{small}

The easiest way to see what accesses AppArmor allows, start a tail -F
/var/{\H}log/{\H}audit/{\H}audit.log (or /var/{\H}log/{\H}messages, or wherever your audit
messages are being sent).  In another terminal, start firefox. tail will
show a few hundred PERMITTING audit events like these:

\begin{small}
\begin{verbatim}
type=APPARMOR msg=audit(1174512269.026:1804): PERMITTING rw access
to /dev/tty (firefox(16950) profile /usr/lib/firefox/firefox.sh
active /usr/lib/firefox/firefox.sh)

type=APPARMOR msg=audit(1174512269.026:1805): PERMITTING r access
to /usr/share/locale/locale.alias (firefox(16950) profile
/usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)

type=APPARMOR msg=audit(1174512269.026:1806): PERMITTING r access
to /usr/lib/locale/en_US.utf8/LC_IDENTIFICATION (firefox(16950)
profile /usr/lib/firefox/firefox.sh active
/usr/lib/firefox/firefox.sh)
\end{verbatim}
\end{small}

Because we want this profile to be fairly simple we'll be fairly

\begin{small}
\begin{verbatim}
/dev/tty rw,
/usr/share/locale/** r,
/usr/lib/locale/** r,
\end{verbatim}
\end{small}

Now re-run firefox. There is no need to handle all log entries at once.
In complain mode, AppArmor will only report accesses that are not in the
profile. This makes it fairly easy to add a few rules and re-run the
application to determine what privileges are still necessary.  We get a
few more messages:

\begin{small}
\begin{verbatim}
type=APPARMOR msg=audit(1174512791.236:5356): PERMITTING r access
to /usr/lib/gconv/gconv-modules.cache (firefox(17031) profile
/usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)

type=APPARMOR msg=audit(1174512791.236:5357): PERMITTING r access
to /proc/meminfo (firefox(17031) profile
/usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)

type=APPARMOR msg=audit(1174512791.240:5358): PERMITTING x access
to /bin/basename (firefox(17032) profile
/usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)

type=APPARMOR msg=audit(1174512791.240:5359): LOGPROF-HINT
changing_profile pid=17032

type=APPARMOR msg=audit(1174512791.240:5360): PERMITTING r access
to /bin/basename (firefox(17032) profile
null-complain-profile active null-complain-profile)

...

type=APPARMOR msg=audit(1174512791.240:5364): PERMITTING mr access
to /bin/basename (basename(17032) profile
null-complain-profile active null-complain-profile)
\end{verbatim}
\end{small}

So now, we add a few more rules:

\begin{small}
\begin{verbatim}
/usr/lib/gconv/** r,
/proc/meminfo r,
/bin/basename rmix,
\end{verbatim}
\end{small}

We selected rmix'' for /bin/basename --- most small shell utilities
should not have a profile for themselves.  There's nothing wrong with
giving basename a profile, but the value of such a profile would be very
limited. Giving other shell utilities their own profiles would be worse:
scripts to function reliably. In our case, basename simply inherits
privileges from another profile, then it has no more and no fewer
privileges than the calling program --- which is often a fine tradeoff.

to execute basename in the same profile. The kernel logs only reported
r, m and x access; we have to choose the execute mode ourselves.  Again,
the standard user tools would prompt users for this decision and give
consequences of decisions.

We continue in this fashion, iteratively adding and changing rules as
needed by the logs. Some of the logs report attribute modifications,
such as:

\begin{small}
\begin{verbatim}
type=APPARMOR msg=audit(1174519157.851:10357): PERMITTING
attribute (mode,ctime,) change to
/home/sarnold/.gnome2_private/ (firefox-bin(17338) profile
/usr/lib/firefox/firefox.sh active /usr/lib/firefox/firefox.sh)
\end{verbatim}
\end{small}

These need to be represented in the profile with simple w access.

\begin{small}
\begin{verbatim}
/home/*/.gnome2_private/ w,
\end{verbatim}
\end{small}

After nine iterations, the profile looks like this --- we have inserted
blank lines between each iteration:

\begin{small}
\begin{verbatim}
/usr/lib/firefox/firefox.sh flags=(complain) {
/usr/lib/firefox/firefox.sh r,
/bin/bash rmix,
/lib/ld-2.5.so rmix,
/etc/ld.so.cache rm,
/lib/lib*.so* rm,
/usr/lib/lib*.so* rm,

/dev/tty rw,
/usr/share/locale/** r,
/usr/lib/locale/** r,

/usr/lib/gconv/** r,
/proc/meminfo r,
/bin/basename rmix,

/usr/bin/file rmix,
/etc/magic r,
/usr/share/misc/magic.mgc r,
/bin/gawk rmix,
/usr/lib/firefox/firefox-bin rmix,

/usr/lib/firefox/lib*so rm,
/opt/gnome/lib/lib*so* rm,
/usr/share/X11/locale/* r,
/var/run/nscd/socket w,
/var/run/nscd/passwd r,

/usr/share/X11/locale/** r,
/home/*/.Xauthority r,
/usr/lib/gconv/*so m,
/home/*/.mozilla/** rw,
/etc/resolv.conf r,
/usr/lib/firefox/**.so rm,
/usr/lib/firefox/** r,

/etc/opt/gnome/** r,
/var/run/dbus/system_bus_socket w,
/etc/localtime r,
/opt/gnome/lib/**.so rm,
/var/cache/libx11/compose/* r,
/tmp/orbit-*/ w,
/dev/urandom r,
/tmp/ r,
/dev/null rw,
/opt/gnome/lib/GConf/2/gconfd-2 rmix,

/dev/log w,
/tmp/orbit-*/* w,
/tmp/gconfd-*/ r,
/tmp/gconfd-*/** rwl,
/home/*/.gconf/ r,
/home/*/.gconf/* rw,
/etc/fonts/** r,
/var/cache/fontconfig/* r,
/home/*/.fontconfig/** r,
/usr/share/ghostscript/fonts/** r,
/etc/passwd r,
/var/tmp/ r,
/bin/netstat rmix,

/home/*/.gnome2_private/ w,
/home/*/.gconfd/* rw,
/proc/net/ r,
/proc/net/* r,
/usr/share/fonts/** r,
/usr/lib/browser-plugins/ r,
/usr/lib/browser-plugins/** rm,
}
\end{verbatim}
\end{small}

Sorting the entries in the profile can help show areas that can be
collapsed with even more generic rules.  After doing that and making a
few rules slightly more generic, we end up with:

\begin{small}
\begin{verbatim}
/usr/lib/firefox/firefox.sh {
/bin/basename rmix,
/bin/bash rmix,
/bin/gawk rmix,
/bin/netstat rmix,
/dev/log w,
/dev/null rw,
/dev/tty rw,
/dev/urandom r,
/etc/fonts/** r,
/etc/ld.so.cache rm,
/etc/localtime r,
/etc/magic r,
/etc/opt/gnome/** r,
/etc/passwd r,
/etc/resolv.conf r,
/home/*/.fontconfig/** r,
/home/*/.gconfd/* rw,
/home/*/.gconf/ r,
/home/*/.gconf/* rw,
/home/*/.gnome2_private/ w,
/home/*/.mozilla/** rw,
/home/*/.Xauthority r,
/lib/ld-2.5.so rmix,
/lib/lib*.so* rm,
/opt/gnome/lib/GConf/2/gconfd-2 rmix,
/opt/gnome/lib/**.so* rm,
/proc/meminfo r,
/proc/net/ r,
/proc/net/* r,
/tmp/gconfd-*/ r,
/tmp/gconfd-*/** rwl,
/tmp/orbit-*/ w,
/tmp/orbit-*/* w,
/tmp/ r,
/usr/bin/file rmix,
/usr/lib/browser-plugins/ r,
/usr/lib/browser-plugins/** rm,
/usr/lib/firefox/firefox-bin rmix,
/usr/lib/firefox/firefox.sh r,
/usr/lib/firefox/** r,
/usr/lib/firefox/**.so rm,
/usr/lib/gconv/** r,
/usr/lib/gconv/*so m,
/usr/lib/lib*.so* rm,
/usr/lib/locale/** r,
/usr/share/** r,
/var/cache/fontconfig/* r,
/var/cache/libx11/compose/* r,
/var/run/dbus/system_bus_socket w,
/var/run/nscd/passwd r,
/var/run/nscd/socket w,
/var/tmp/ r,
}
\end{verbatim}
\end{small}

\begin{thebibliography}{XX}

\bibitem{apparmor}
AppArmor documentation,
\url{http://www.novell.com/documentation/apparmor/}

\bibitem{ols06-pai}
Al Viro and Ram Pai:
{\em Shared-Subtree Concept, Implementation and Applications in Linux,}
Ottawa Linux Symposium, July 19-22, 2006,
\url{http://www.linuxsymposium.org/2006/}

\bibitem{dragon86}
Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman:
{\em Compilers: Principles, Techniques, and Tools}
(The Dragon Book''), Addison-Wesley, 1986, ISBN 0-201-10088-6.

A second edition of this classic is available since August 2006 as
ISBN 0-321-48681-1.

\end{thebibliography}

\end{document}
% vim:textwidth=72
openSUSE Build Service is sponsored by


text:
A box containing $10$ identical components has $6$ red balls and $2$ blue balls. If each compartment can hold only one ball, then the number of different possible arrangements are

1. $1026$
2. $1062$
3. $1260$
4. $1620$


text:
# Statistics and Statistical Programming (Winter 2017)/Problem Set: Week 7

## Programming Challenges

PC1. Download this dataset in Stata DTA format which contains an anonymized and reduced version of the data visualized in the Buechley and Hill paper on Lilypad. Once you have it
(a) Reproduce both Table 1 and Table 2 (just US users) using the dataset (as closely as possible).
(b) Run a ${\displaystyle \chi ^{2}}$-test on both tables. Compare to the paper (for Table 1, there doesn't seem to be a ${\displaystyle \chi ^{2}}$ test for Table 2). Did you reproduce it?
(c) Install the package "gmodels" and try to display the table using the function CrossTable(). This will give you output very similar to SPSS.
(d) It's important to be able to import tables directly into your word processor without cutting and pasting individual cells. Can you export the output of your table? There are a bunch of functions you can use to do this. I used the "xtable" package but I think that write.table() and Excel would do the job just as well.
PC2. At the Community Data Science Workshops we had two parallel afternoon sessions on Day 1. In my session, there were 42 participants. In Tommy Guy's session, there were only 19. The next week (Day 2), we asked folks to raise their hands if they had been in Tommy's session (14 did ) and how many had been in mine (31 did). There was clearly attrition in both groups! Was there more attrition in one group than another? Try answering this both with a test of proportions (prop.test()) and with a ${\displaystyle \chi ^{2}}$. Compare your answers. Is there convincing evidence that there is a dependence between instructor and attrition?
PC3. Download this dataset that was just published on "The Effect of Images of Michelle Obama’s Face on Trick-or-Treaters’ Dietary Choices: A Randomized Control Trial." The paper doesn't seem to have even been published yet so I think the abstract is all we have. We'll come back to it again next week.
(a) Download and import the data into R. I needed to install the "readstata13" package to do so.
(b) Take a look at the codebook if necessary. Recode the data on being presented with Michelle Obama's face and the data on whether or not kids picked up fruit. we'll leave it at that for now.
(c) Do a simple test on whether or not the two groups are dependent. Be ready to report those tests. The results in the paper will use linear regression. Do you have a sense, from your reading, why your results using the coding material we've learned might be different?

## Statistical Questions from OpenIntro §6

Q0. Any questions or clarifications from the OpenIntro text or lecture notes?
Q1. Exercise 7.6 using some census data from the UK
Q2. Exercise 7.40 using date from rate my professor
Q3. Exercise 8.4 on school absenteeism
Q4. Exercise 8.10 on school absenteeism again (no sub-parts)
Q5. Exercise 8.14 on evaluating regression residuals (no sub-parts)

## Empirical Paper Questions

These questions are about the Lampe and Resnick paper which is a very highly cited paper in my area of research. For this week, we'll focus on the correlation table (Table 3) and the regression table in Table 5. We'll come back to the logistic regression next week.

Q6. Be ready to explain Table 3. In particular, be ready to talk about the bivariate relationships between Final score all of the other variables in the model. Be ready to talk about the correlation both in quantitative and in substantive terms.
Q7. Do you think that the assumptions that underly the linear regression model reported in Table 5 hold? If you can't decide, what information might you like to have seen provided to help you?
Q8. Be ready to explain what Table 5 means in both statistical and substantive terms. In particular, be ready to interpret the coefficients in substantive terms and be ready to explain what the t-statistics, ${\displaystyle R^{2}}$, and p-values mean. Be ready to provide an sentence for each that interprets each number in the table in substantive terms. This will mean understanding what every variable actually measures.


text:
6 edited tags
5 deleted 23 characters in body

Consider $X=\operatorname{Hom}(\pi,SL(2,\mathbb C))/\!/SL(2,\mathbb C)$ and $Y=\operatorname{Hom}(\pi,SU(2))/\!/SU(2)$, where $\pi$ is a surface group. Note that if we use the right coordinates, then $Y$ is exactly the real valued points of $X$ (for the purposes of this question, though, this is irrelevant).

For those reading the comments below, I used to use $X_{\mathbb R}$ instead of $Y$.

Since $\pi$ is a surface group, the cup product (intersection pairing) gives rise to a symplectic form $\omega$ on $Y$ (which can also be naturally viewed as a holomorphic symplectic form on $X$). Now for $f,g\in\Gamma(X,\mathcal f\in\Gamma(X,\mathcal O_X)$, we have a natural bilinear pairinglinear map:

$$f\otimes g\mapsto f\mapsto \int_{Y}f\cdot g\cdot\wedge^{\operatorname{top}}\omega$$int_{Y}f\cdot\wedge^{\operatorname{top}}\omega$$(I believe it is more or less correct to call this the Yang-Mills measure, e.g. see this paper by Bullock, Frohman, and Kania-Bartoszynska) Question: Is there a completely algebraic description of this pairingintegral? i.e. one that just works with input \pi and the algebraic group SL(2), and avoids the notion of real and complex points? Note: there is certainly a simple algebraic description of \omega, so perhaps we just need to algebraically define the homology class of Y in X . . . A paper of Witten's is perhaps related (and great to read even if it isn't). 4 deleted 39 characters in body Consider X=\operatorname{Hom}(\pi,SL(2,\mathbb C))/\!/SL(2,\mathbb C) and X_{\mathbb R}=\operatorname{Hom}(\pi,SU(2))/\!/SU(2), Y=\operatorname{Hom}(\pi,SU(2))/\!/SU(2), where \pi is a surface group. Note that if we use the right coordinates, then X_{\mathbb R} Y is exactly the real valued points of X (see for the purposes of this question, though, this is irrelevant). For those reading the comments below; anyway, it isn't crucial for this question that I used to use X_{\mathbb R} is the \mathbb R-valued points instead of X).Y. Since \pi is a surface group, the cup product (intersection pairing) gives rise to a symplectic form \omega on X_{\mathbb R} Y (which can also be naturally viewed as a holomorphic symplectic form on X). Now for f,g\in\Gamma(X,\mathcal O_X), we have a natural bilinear pairing:$$f\otimes g\mapsto \int_{X_{\mathbb R}}f\cdot int_{Y}f\cdot g\cdot\wedge^{\operatorname{top}}\omega

(I believe it is more or less correct to call this the Yang-Mills measure, e.g. see this paper by Bullock, Frohman, and Kania-Bartoszynska)

Question: Is there a completely algebraic description of this pairing? i.e. one that just works with input $\pi$ and the algebraic group $SL(2)$, and avoids the notion of real and complex points?

Note: there is certainly a simple algebraic description of $\omega$, so perhaps we just need to algebraically define the homology class of $X_{\mathbb R}$ Y$in$X\$ . . .

A paper of Witten's is perhaps related (and great to read even if it isn't).

3 added 130 characters in body
2 added 191 characters in body; edited title
1


text:
Accelerating the pace of engineering and science

# Documentation Center

• Trial Software

# questdlg

Create and open question dialog box

## Syntax

button = questdlg('qstring')
button = questdlg('qstring','title')
button = questdlg('qstring','title',default)
button = questdlg('qstring','title','str1','str2',default)
button = questdlg('qstring','title','str1','str2','str3',default)
button = questdlg('qstring','title', ..., options)

## Description

button = questdlg('qstring') displays a modal dialog box presenting the question 'qstring'. The dialog has three default buttons, Yes, No, and Cancel. If the user presses one of these three buttons, button is set to the name of the button pressed. If the user presses the close button on the dialog without making a choice, button is set to the empty string. If the user presses the Return key, button is set to 'Yes'. 'qstring' is a cell array or a string that automatically wraps to fit within the dialog box.

 Note   A modal dialog box prevents the user from interacting with other windows before responding. For more information, see WindowStyle in the MATLAB® Figure Properties.

button = questdlg('qstring','title') displays a question dialog with 'title' displayed in the dialog's title bar.

button = questdlg('qstring','title',default) specifies which push button is the default in the event that the Return key is pressed. 'default' must be 'Yes', 'No', or 'Cancel'.

button = questdlg('qstring','title','str1','str2',default) creates a question dialog box with two push buttons labeled 'str1' and 'str2'. default specifies the default button selection and must be 'str1' or 'str2'.

button = questdlg('qstring','title','str1','str2','str3',default) creates a question dialog box with three push buttons labeled 'str1', 'str2', and 'str3'. default specifies the default button selection and must be 'str1', 'str2', or 'str3'.

When default is specified, but is not set to one of the button names, pressing the Enter key displays a warning and the dialog remains open.

button = questdlg('qstring','title', ..., options) replaces the string default with a structure, options. The structure specifies which button string is the default answer, and whether to use TeX to interpret the question string, qstring. Button strings and dialog titles cannot use TeX interpretation. The options structure must include the fields Default and Interpreter, both strings. It can include other fields, but questdlg does not use them. You can set Interpreter to 'none' or 'tex'. If the Default field does not contain a valid button name, a command window warning is issued and the dialog box does not respond to pressing the Enter key.

## Examples

### Example 1

Create a dialog that requests a dessert preference and encode the resulting choice as an integer.

% Construct a questdlg with three options
choice = questdlg('Would you like a dessert?', ...
'Ice cream','Cake','No thank you','No thank you');
% Handle response
switch choice
case 'Ice cream'
disp([choice ' coming right up.'])
dessert = 1;
case 'Cake'
disp([choice ' coming right up.'])
dessert = 2;
case 'No thank you'
dessert = 0;
end

To access the return value assigned to dessert, save the example as a function, for example choosedessert, by inserting this line on top:

function dessert = choosedessert

You can generalize the function by providing the cases as string or cell array calling arguments.

As the example shows, case statements can contain white space (but are case-sensitive).

### Example 2

Specify an options structure to use the TeX interpreter to format a question.

options.Interpreter = 'tex';
% Include the desired Default answer
options.Default = 'Don''t know';
% Create a TeX string for the question
qstring = 'Is \Sigma(\alpha - \beta) < 0?';
choice = questdlg(qstring,'Boundary Condition',...
'Yes','No','Don''t know',options)


text:
Ad

# kramdown - Online in the Cloud

This is the command kramdown that can be run in the OnWorks free hosting provider using one of our multiple free online workstations such as Ubuntu Online, Fedora Online, Windows online emulator or MAC OS online emulator

### PROGRAM:

#### NAME

kramdown - a fast, pure-Ruby Markdown-superset converter

#### SYNOPSIS

kramdown [options] [FILE ...]

#### DESCRIPTION

kramdown is primarily used for parsing a superset of Markdown and converting it to
different output formats. It supports standard Markdown (with some minor modifications)
and various extensions like tables and definition lists. Due to its modular architecture
it also allows other input formats than Markdown, for example, HTML or Github Flavored
Markdown.

If FILE is not specified, kramdown reads from the standard input. The result is written to
the standard output.

There are two sets of options that kramdown accepts: The first one includes the options
that are used directly by the kramdown binary. The second set of options controls how
kramdown parses and converts its input.

#### OPTIONS

-i, --input ARG
Specify the input format. Available input formats: kramdown (this is the default),
markdown, GFM or html.

-o, --output ARG
Specify one or more output formats separated by commas: html (default), kramdown,
latex, pdf or remove_html_tags.

-v, --version
Show the version of kramdown.

-h, --help
Show the help.

#### KRAMDOWNOPTIONS

--auto-id-prefix ARG

Prefix used for automatically generated header IDs

This option can be used to set a prefix for the automatically generated header IDs
so that there is no conflict when rendering multiple kramdown documents into one
output file separately. The prefix should only contain characters that are valid in
an ID!

Default: '' Used by: HTML/Latex converter

--[no-]auto-id-stripping

Strip all formatting from header text for automatic ID generation

If this option is true, only the text elements of a header are used for
generating the ID later (in contrast to just using the raw header text line).

This option will be removed in version 2.0 because this will be the default then.

Default: false Used by: kramdown parser

--[no-]auto-ids

Use automatic header ID generation

If this option is true, ID values for all headers are automatically generated if
no ID is explicitly specified.

Default: true Used by: HTML/Latex converter

--coderay-bold-every ARG

Defines how often a line number should be made bold

Can either be an integer or false (to turn off bold line numbers completely).

Default: 10 Used by: HTML converter

--coderay-css ARG

Defines how the highlighted code gets styled

Possible values are :class (CSS classes are applied to the code elements, one must
supply the needed CSS file) or :style (default CSS styles are directly applied to
the code elements).

Default: style Used by: HTML converter

--coderay-default-lang ARG

Sets the default language for highlighting code blocks

If no language is set for a code block, the default language is used instead. The
value has to be one of the languages supported by coderay or nil if no default
language should be used.

Default: nil Used by: HTML converter

--coderay-line-number-start ARG

The start value for the line numbers

Default: 1 Used by: HTML converter

--coderay-line-numbers ARG

Defines how and if line numbers should be shown

The possible values are :table, :inline or nil. If this option is nil, no line
numbers are shown.

Default: :inline Used by: HTML converter

--coderay-tab-width ARG

The tab width used in highlighted code

Used by: HTML converter

--coderay-wrap ARG

Defines how the highlighted code should be wrapped

The possible values are :span, :div or nil.

Default: :div Used by: HTML converter

--[no-]enable-coderay

Use coderay for syntax highlighting

If this option is true, coderay is used by the HTML converter for syntax
highlighting the content of code spans and code blocks.

Default: true Used by: HTML converter

--entity-output ARG

Defines how entities are output

The possible values are :as_input (entities are output in the same form as found in
the input), :numeric (entities are output in numeric form), :symbolic (entities are
output in symbolic form if possible) or :as_char (entities are output as characters
if possible, only available on Ruby 1.9).

Default: :as_char Used by: HTML converter, kramdown converter

--footnote-backlink ARG

Defines the text that should be used for the footnote backlinks

The footnote backlink is just text, so any special HTML characters will be escaped.

If the footnote backlint text is an empty string, no footnote backlinks will be
generated.

Default: '&8617;' Used by: HTML converter

--footnote-nr ARG

The number of the first footnote

This option can be used to specify the number that is used for the first footnote.

Default: 1 Used by: HTML converter

--[no-]hard-wrap

Interprets line breaks literally

Insert HTML
 tags inside paragraphs where the original Markdown document
had newlines (by default, Markdown ignores these newlines).

Default: true Used by: GFM parser

--header-offset ARG

Sets the output offset for headers

If this option is c (may also be negative) then a header with level n will be
output as a header with level c+n. If c+n is lower than 1, level 1 will be used. If
c+n is greater than 6, level 6 will be used.

Default: 0 Used by: HTML converter, Kramdown converter, Latex converter

--[no-]html-to-native

Convert HTML elements to native elements

If this option is true, the parser converts HTML elements to native elements. For
example, when parsing hallo the emphasis tag would normally be converted
to an :html element with tag type :em. If html_to_native is true, then the
emphasis would be converted to a native :em element.

This is useful for converters that cannot deal with HTML elements.

Default: false Used by: kramdown parser

--latex-headers ARG

Defines the LaTeX commands for different header levels

The commands for the header levels one to six can be specified by separating them
with commas.

Default: section,subsection,subsubsection,paragraph,subparagraph,subparagraph Used
by: Latex converter

--line-width ARG

Defines the line width to be used when outputting a document

Default: 72 Used by: kramdown converter

--link-defs ARG

Pre-defines link definitions

This option can be used to pre-define link definitions. The value needs to be a
Hash where the keys are the link identifiers and the values are two element Arrays
with the link URL and the link title.

If the value is a String, it has to contain a valid YAML hash and the hash has to
follow the above guidelines.

Default: {} Used by: kramdown parser

--math-engine ARG

Set the math engine

Specifies the math engine that should be used for converting math blocks/spans. If
this option is set to +nil+, no math engine is used and the math blocks/spans are
output as is.

Options for the selected math engine can be set with the math_engine_opts
configuration option.

Default: mathjax Used by: HTML converter

--math-engine-opts ARG

Set the math engine options

Specifies options for the math engine set via the math_engine configuration option.

The value needs to be a hash with key-value pairs that are understood by the used
math engine.

Default: {} Used by: HTML converter

--[no-]parse-block-html

Process kramdown syntax in block HTML tags

If this option is true, the kramdown parser processes the content of block HTML
tags as text containing block-level elements. Since this is not wanted normally,
the default is false. It is normally better to selectively enable kramdown
processing via the markdown attribute.

Default: false Used by: kramdown parser

--[no-]parse-span-html

Process kramdown syntax in span HTML tags

If this option is true, the kramdown parser processes the content of span HTML
tags as text containing span-level elements.

Default: true Used by: kramdown parser

--[no-]remove-block-html-tags

Remove block HTML tags

If this option is true, the RemoveHtmlTags converter removes block HTML tags.

Default: true Used by: RemoveHtmlTags converter

--[no-]remove-span-html-tags

Remove span HTML tags

If this option is true, the RemoveHtmlTags converter removes span HTML tags.

Default: false Used by: RemoveHtmlTags converter

--smart-quotes ARG

Defines the HTML entity names or code points for smart quote output

The entities identified by entity name or code point that should be used for, in
order, a left single quote, a right single quote, a left double and a right double
quote are specified by separating them with commas.

Default: lsquo,rsquo,ldquo,rdquo Used by: HTML/Latex converter

--syntax-highlighter ARG

Set the syntax highlighter

Specifies the syntax highlighter that should be used for highlighting code blocks
and spans. If this option is set to +nil+, no syntax highlighting is done.

Options for the syntax highlighter can be set with the syntax_highlighter_opts
configuration option.

Default: coderay Used by: HTML/Latex converter

--syntax-highlighter-opts ARG

Set the syntax highlighter options

Specifies options for the syntax highlighter set via the syntax_highlighter
configuration option.

The value needs to be a hash with key-value pairs that are understood by the used
syntax highlighter.

Default: {} Used by: HTML/Latex converter

--template ARG

The name of an ERB template file that should be used to wrap the output or the ERB
template itself.

This is used to wrap the output in an environment so that the output can be used as
a stand-alone document. For example, an HTML template would provide the needed
header and body tags so that the whole output is a valid HTML file. If no template
is specified, the output will be just the converted text.

When resolving the template file, the given template name is used first. If such a
file is not found, the converter extension (the same as the converter name) is
appended. If the file still cannot be found, the templates name is interpreted as a
template name that is provided by kramdown (without the converter extension). If
the file is still not found, the template name is checked if it starts with
'string://' and if it does, this prefix is removed and the rest is used as template
content.

kramdown provides a default template named 'document' for each converter.

Default: '' Used by: all converters

--toc-levels ARG

Defines the levels that are used for the table of contents

The individual levels can be specified by separating them with commas (e.g. 1,2,3)
or by using the range syntax (e.g. 1..3). Only the specified levels are used for
the table of contents.

Default: 1..6 Used by: HTML/Latex converter

--[no-]transliterated-header-ids

Transliterate the header text before generating the ID

Only ASCII characters are used in headers IDs. This is not good for languages with
many non-ASCII characters. By enabling this option the header text is
transliterated to ASCII as good as possible so that the resulting header ID is more
useful.

The stringex library needs to be installed for this feature to work!

Default: false Used by: HTML/Latex converter

#### EXITSTATUS

The exit status is 0 if no error happened. Otherwise it is 1.

Use kramdown online using onworks.net services

Free Servers & Workstations

Download Windows & Linux apps

Linux commands

• 1
abidiff
abidiff - compare ABIs of ELF files
abidiff compares the Application Binary
Interfaces (ABI) of two shared libraries
in ELF format. It emits a meaningful
repor...
Run abidiff
• 2
abidw
abidw - serialize the ABI of an ELF
file abidw reads a shared library in ELF
format and emits an XML representation
of its ABI to standard output. The
emitted ...
Run abidw
• 3
cppo
cppo - lightweight cpp-like
preprocessor for OCaml ...
Run cppo
• 4
cppunit-config
cppunit-config - script to get
information about the installed version
of cppunit ...
Run cppunit-config
• 5
fwb_iosacl
fwb_ipt - Policy compiler for Cisco IOS
ACL ...
Run fwb_iosacl
• 6
fwb_ipf
fwb_ipf - Policy compiler for ipfilter ...
Run fwb_ipf
• More »

Ad


text:
# Gaussian Beam Propagation with ABCD Matrices

Table of Contents:

FORMULATION

Because of the paraxial/Fresnel approximation, a Gaussian beam maintains its profile as it propagates in space, with the only parameter parameter changing being its wavefront radius R(z). We know from paraxial geometrical optics that the effect of the optical elements on the wavefront radius can be described by the ABCD law of ray transfer matrices. We can therefore use this formulation to describe how the wavefront radius can be modified by optical elements.

Recall that the wavefront curvature R(z) and the radius $\omega(z)$ are not independent but are connected by the q-parameter as:

$$\frac{1}{q(z)} = \frac{1}{R(z)}-\frac{i\lambda}{\pi\omega^2(z)}$$

or

$$q(z) = z + iz_R$$

Case 1: For propagation in free space over a distance d, then clearly if $q(z_1)=q_1$, then $q(z_2)=q_2=q_1+d$. We can see this because the effect of the propagation in the distance term would just be to add a distance d. This can be written as:

$$q_2 = \frac{Aq_1 + B}{Cq_1 + D}$$

where

$$\begin{pmatrix} A & B \\ C & D \end{pmatrix} = \begin{pmatrix} 1 & d \\ 0 & 1 \end{pmatrix}$$

Case 2: With propagation through a thin lens, the lens will transform the wavefront radius R without changing the beam radius $\omega$ since the propagation distance is negligible. Since then $\omega_2 = \omega_1$, the q-parameter change is:

$$\frac{1}{q_2} – \frac{1}{q_1} = \frac{1}{R_2} – \frac{1}{R_1}$$

We know from geometrical optics that the thin lens changes R as:

$$R_2 = \frac{AR_1+B}{CR_1+D}$$

where

$$\begin{pmatrix} A & B \\ C & D \end{pmatrix} = \begin{pmatrix} r & 0 \\ -1/f & 1 \end{pmatrix}$$

Conclusion: Looking at the above two cases, we can see that with a given change of the ABCD matrix, we can have the relation for the complex radius of curvature q:

$$q_2 = \frac{Aq_1 +B}{Cq_1+D}$$

which is known as the ABCD law. This ABCD Law relates the complex radius of curvature at the front and back reference planes of a system through a ray matrix. We can interpret the ABCD law as stating that the complex q parameter transforms in the same way as R in geometrical optics. This turns out to be a generally true statement for paraxial system and not just the two presented above. Since Gaussian beams are paraxial waves with spherical wavefronts, they then transform in the same way as wavefronts defined as normals to paraxial rays.

FOCUSING A GAUSSIAN BEAM

We can now consider the case of a well-collimated Gaussian beam incident on a thin lens. This in practice means that the incident beam has a waist at the lens with the Rayleigh range $z_R >> f$. The q-parameter of the incident beam at the lens is then:

$$\frac{1}{q_1} = \frac{1}{\infty}-i\frac{\lambda}{\pi\omega_i^2}$$

so then:

$$q_1 = i\frac{\pi\omega_i^2}{\lambda}$$

where

$$z_R_i = \frac{\pi\omega_z^2}{\lambda}$$

The ABCD matrix propagating the beam through the lens to the focus is then:

$$\begin{bmatrix} A & B \\ C & D \end{bmatrix} = \begin{bmatrix} 1 & d \\ 0 & 1 \end{bmatrix} \begin{bmatrix} 1 & 0 \\ -1/f & 1 \end{bmatrix} = \begin{bmatrix} 1 – \frac{d}{f} & d \\ -\frac{1}{f} & 1 \end{bmatrix}$$

so that the ABCD law with substitution of $q_i$ yields:

\begin{align} q_2 & = \frac{(1-d/f)(i\frac{\pi\omega_i^2}{\lambda})+d}{(-\frac{1}{f})(i\frac{\pi\omega_i^2}{\lambda})+1} \\ & = [\frac{1}{R_2}-i\frac{\lambda}{\pi\omega_2^2}]^{-1} \end{align}

where the second definition came from the definition of $q_2$. Equating the real and imaginary parts of both sides:

$$R_2(d) = \frac{(\frac{d}{zR_i})^2+(1-\frac{d}{f})^2}{(\frac{d}{zR_i})^2+\frac{1}{f}(1-\frac{d}{f})}$$

$$\omega_2^2(d) = \omega_i^2(1-\frac{d}{f})^2+\omega_i^2(\frac{d}{zR_i})^2$$

The waist of the focused beam occurs when $R_2(d) = \infty$, so:

$$\frac{d}{z_R_i^2}-\frac{1}{f}(1-\frac{d}{f}) = 0 \rightarrow d(\frac{1}{z_R_i^2}+\frac{1}{f^2}) = \frac{1}{f}$$

so the focused beam occurs at distance d:

$$d = \frac{f}{1+\frac{f^2}{z_R_i^2}}$$

Note here that when the incident beam is well-collimated, i.e. its beam diameter is large so that $z_{R_i} >> f$, then we get the simple geometrical optics result for the ray picture that d = f. In the case of a slightly diverging beam, the actual focal length is then a little bit shorter than the focal length.

We can then find the focused beam waist by substituting in the expression for d into the equation for $\omega_2^2(d)$:

$$\omega_f = \frac{\lambda{f}}{\pi\omega_i}\frac{1}{\sqrt{1+f^2/z_R^2}}$$

In the typical case where $z_R_i >> f$:

$$\omega_f = \frac{\lambda{f}}{\pi\omega_i}$$

Then, if we define the beam diameter parameters $D_i = 2\omega_i$, $D_f = 2\omega_f$, then we have:

$$D_f = \frac{4}{\pi}\lambda(\frac{f}{D_i})$$

We previously defined the f-number of a lens as the focal length divided by the diameter of the aperture stop.


text:
• Popular Now

• 13
• 18
• 19
• 27
• 10

Archived

This topic is now archived and is closed to further replies.

CreateVertexBuffer question

This topic is 5692 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Let's say I have something like this:

struct MyVertex
{
float x, y, z;
D3DXCOLOR diffuse;
float u, v;
}

// Init D3D and all that jazz

nVerts       = 1000;
MyVertex*  pMyModel;
pMyModel   = new MyVertex[ nVerts ];

// Assign something to pMyModel

Can I then create my vertex buffer by saying something like this: pD3DDevice->CreateVertexBuffer( sizeof(pMyModel), ... ); All of the books, tutorials, etc seem to define the size of the buffer more like this: pD3DDevice->CreateVertexBuffer( sizeof(MyVertex) * nVerts, ... ); Is that just to spell out what you need to give it, or is there some potential difference in the two? -John [edited by - Teknofreek on August 18, 2002 4:16:18 PM]


text:
## Building OBS Studio (Windows 10, 64-bit)

• Extract the contents of the zip file to C:\obs-deps
• Download Qt version >= 5.9, and install in C:\Qt
• Follow the official OBS Studio Windows install instructions here: https://github.com/obsproject/obs-studio/wiki/Install-Instructions#windows-build-directions.
• Open up cmake-gui.
• Where is the source code: /path/to/obs-studio
• Where to build the binaries: /path/to/newly/created/build/directory
• Click + Add Entry. Add the following entries:
• DepsPath, PATH, C:\obs-deps\win64\include
• QTDIR64, PATH, C:\Qt\5.x\msvc2017_64
• (Optional) FFmpegPath, PATH, C:\obs-deps\win64\include
• (Optional) x264Path, PATH, C:\obs-deps\win64\include
• (Optional) curlPath, PATH, C:\obs-deps\win64\include
• Press Configure. IMPORTANT Select the generator corresponding to both Visual Studio 2017 and Win64, Visual Studio 15 2017 Win64. If you don’t select the Win64 version, the build won’t work properly because you’ll be targeting a 32-bit architecture.
• Press Generate.
• Go to the build directory that you specified. Open up ALL_BUILD.vcxproj.
• In the Solution Explorer, right click the Solution called obs-studio. Click Build Solution.
• Once the Output window indicates that the Build: 41 succeeded, 0 failed, 0 up-to-date, 0 skipped, go to /path/to/build/rundir/Debug/bin/64bit/. Inside, you’ll find obs64. Open that executable file to run OBS Studio. Congrats!

## Building OBS Studio (macOS)

cd obs-studio
mkdir build
cd build
cmake .. && make

If this doesn’t work, you might need to set CMAKE_PREFIX_PATH. See link.

## Video Subsystem

Question

I’m using 1fps, zerolatency, and 1 second key frames. When streaming a dummy video directly to my server with ffmpeg using the same x264 settings, the delay is almost non-existent. Can someone point me to the parts of OBS source code so I can maybe recompile and make OBS work for my (weird) use case?

From Jim, creator of OBS

not sure, the audio latency is already as minimal as can be, although you may gain up to a second of audio latency depending on what you do. the audio latency is designed to dynamically increase, but only as needed kind of a complex system I wrote to ensure minimal audio latency

what’s probably getting you there is the video subsystem. running OBS at 1fps means that you’re going to see an effect there, because it waits a frame between certain video subsystem actions(edited)

first it renders the backbuffer, then waits a frame. then it converts the backbuffer to YUV, which may require another frame or two to process in full

basically, it’s solely the fact that you’re running at 1fps that’s causing the problem, and due to the fact that there’s always a minimum of 2-4 frames buffering

unless you performed every one of the video subsystem actions all at once (which would stall the graphics pipeline), you’re not going to be able to do anything about it

rendering, conversion, queueing

unless you’re educated with graphics programming it’s probably not going to be something that you’re going to be able to fix easily on your own for FFmpeg, it does not need to do any of those things. it can just decode whatever you’re doing and convert on the spot, typically via CPU there is no waiting for the GPU

so you’re going to naturally get a more instant result there that 1fps thing is just what’s getting you

oh, and it waits a frame for frame download from the GPU so it’s 1FPS in conjunction with the compositor’s graphics render/conversion/download actions

at least 3-4 frames are going to be buffered so at 1fps, always going to have 3-4 seconds of latency

you could get it all done in one frame on-the-spot, just would require graphics knowledge and some tinkering with the backend.

obs.c, obs-video.c and obs-internal.h I would be willing to point you to the variables and lines, but after that I’d have to let you take it from there

Question:

does that mean if I use like 5fps i’ll get better latency?

Jim:

https://github.com/obsproject/obs-studio/blob/master/libobs/obs-internal.h#L230-L237 these are the key variables. Yes, higher FPS would give you lower latency just due to that nature

search for those variables in this file: https://github.com/obsproject/obs-studio/blob/master/libobs/obs-video.c the file is only 700 lines, so the video backend isn’t too terribly complicated. you’ll note lines like this: https://github.com/obsproject/obs-studio/blob/master/libobs/obs-video.c#L218

this is how it waits initially: prev_texture and cur_texture. Each buffer has two textures.

frame 1 for example would render the backbuffer to obs_core_video::render_textures[0], then it would stop action.

frame 2 would render the backbuffer to obs_core_video::render_textures[1], then would convert obs_core_video::render_textures[0] to YUV to obs_core_video::convert_textures[0].

frame 3 would render the backbuffer again in to obs_core_video::render_textures[0], then would convert obs_core_video::render_textures[1] to YUV to obs_core_video::convert_textures[1], and then would download obs_core_video::convert_textures[0] to obs_core_video::output_textures[0].

frame 4 would render the backbuffer again in to obs_core_video::render_textures[1], then would convert obs_core_video::render_textures[0] to YUV to obs_core_video::convert_textures[0], then would download obs_core_video::convert_textures[1] to obs_core_video::output_textures[1], and finally queue obs_core_video::output_textures[0] in the encoder thread to be sent to the video encoder and then output so you can see how it alternates

you could change #define NUM_TEXTURES 2 to #define NUM_TEXTURES 1 at the top of obs-internal.h, and then modify the back-end to do everything all at once in obs-video.c

without waiting a frame each time for the previous action to complete

although just be warned – it will stall the graphics pipeline. but for 1fps output, I suppose it wouldn’t be a huge deal for you. might even just be able to set NUM_TEXTURES to 1 and have it function like that automatically. although I don’t think it’s really programmed to handle values less than 2, aka 1

everything that’s done in the graphics thread is done to minimize any potential GPU stalling, and maximize performance at the cost of that latency people don’t normally run the program below 30 FPS, so that latency is typically no more than 133 milliseconds

Question:

In this 4-frame process, wouldn’t at any given moment starting on the 4th frame, the GPU is doing all 4 steps at once anyways?

Jim:

you mean is it doing all four steps after the fourth? yea. because it’s reached full cycle of alternation

Question:

yeah, so then why won’t the GPU stall at the 4th frame?

Jim:

because the frames for each buffer have been filled the previous frame at step one, it can only render the backbuffer, but it cannot perform the next step without stalling the GPU or rather, without risking a stall each step requires at least one frame of breathing room, so to speak one it’s reached the fourth frame, it can just alternate between the frames for each step to have that breathing room. no matter what, the last step will always work on frame data that is essentially four frames old

when you call graphics functions, internally they are put in a queue on the graphics card. when you do all four steps at once, it requires it to execute all actions that have been queued up until that point. the program itself will have to sit there and wait for the GPU to execute those actions causing the program to stall for your case it’ll probably be fine, but at higher framerates, it would basically ruin performance because the program will be sitting there waiting for the graphics card, and the graphics card will have a lot of inefficient idle time a better way to make an analogy may be to think of a factory: let’s say you have a conveyer belt to build items

and now let’s say the product requires multiple steps to complete. like let’s say you need to build the product, and that requires four steps a factory normally has it to where each step is performed separate on the conveyer belt that way it can perform each step on a different item at the same time rather than have it stop the entire conveyer belt and force it to wait while it does all four steps on a single item at a time it improves the efficiency of the line same thing for rendering

## Glossary

• Solution - A solution is a structure for organizing projects in Visual Studio. Suffix is .sln. https://msdn.microsoft.com/en-us/library/bb165951.aspx
• Project - a project contains of all the source code files, icons, images, data files and anything else that will be compiled into an executable program or web site. Suffix is .vxproj. https://msdn.microsoft.com/en-us/library/b142f8e7.aspx


text:
# I General question about math required to do david morins book

1. Jul 16, 2016

### RubinLicht

So i dont have issues with most of his problems, but once in a while a question that requires a ridiculous math trick that i had no way of knowing comes up and i just wonder if this is something you pick up from various places, or can attain through a focused study of mathematics. the question that prompted me to post this was this:
and solution:

I get completely lost once i get to "In taking the derivative, the former dependence requires finding the value of theintegrand at the x0 limit...". and then i can follow the solution again once you get to "the solution to this is -> exponential"

The problem i had with this is that i immediately knew that the solution would be an exponential with some dependance on l in the exponent, however, there was simply no way for me to reach the solution because i had to use what ever math tricks he used here.

background: i can comfortably do approximations with taylor series and binomial theorem, so I'm not completely new to the world of approximations.

tldr i would like to know where to gain the math knowledge for these kind of tricks

2. Jul 17, 2016

### wrobel

this is not a trick this is a solution to the differential equation $\rho'=-\rho$. There is a mathematical subject called "Ordinary Differential Equations"

3. Jul 17, 2016

### RubinLicht

"I get completely lost once i get to "In taking the derivative, the former dependence requires finding the value of theintegrand at the x0 limit...". and then i can follow thesolution again once you get to "the solution to this is -> exponential" "

Tldr I knew how to do that part, and you would know this is if you read my post again

4. Jul 17, 2016

### wrobel

Last edited: Jul 17, 2016
5. Jul 17, 2016

### RubinLicht

Yes but my understanding of it is very poor because we seemed to just skip over it in class. My friend also said to read about the fundamental theorem of calculus, so I'll do that when i get time and come back to this problem. Thanks!


text:
# What can be the best dropout value and the FC layer for good accurate predictions?

I am retraining the pre-trained model VGG16 in the last FC layers. I used the below function .

what can be the best combination of FC layers and dropout values for the best predictions. ?

In the area of Neural Networks there isn't one right value that works for all kinds of situations. You just need to repeat experiments, till you reach a satisfactory value. Ideally Dropout values range from 0 to 0.5 . I would use a dropout value of .3 or .2 in my neural networks. Also, the number of neurons in FC layer, impact the degree of fit in your network. Too small numbers, result in underfit. Too large values, result in overfit. Keep on increasing the complexity of the model and evaluate it against a validation loss, that will inform you about increasing or decreasing the number of FC layers.

In addition to rithwik kukunuri, this thing is called hyperparameter optimization or hyperparameter tuning. As the name suggests, there are a bunch of variables comes out of nowhere. We just decide intuitively (or based on some educated guess).

Assuming you have a "good model" (I don't know what exactly this mean), at some point, you need to try various different parameters that are likely to improve the performance of your network.

Some of them are how many layers you need to use?, size of conv layer, dropout, learning rate, activation, kernel size, number of epoch etc. After trying many different combinations of these and multiple iterations for the same set of variables, you can end up with significantly higher accuracy.