Compare commits

...

4 Commits

Author SHA1 Message Date
c136db7222
Updated pdf 2025-04-15 19:36:57 +02:00
1a09bd99af
Updated info 2025-04-15 19:36:51 +02:00
7518b25a6d
Fixed typos 2025-04-15 19:36:42 +02:00
3267bfa32f
Added a package for strikethough text 2025-04-15 19:36:26 +02:00
4 changed files with 6 additions and 12 deletions

View File

@ -42,17 +42,9 @@ As for regular terminal programs, I see these possible solutions:
\section{Performance}
Performance of ICFS is terrible. Unfortunately, I was unable to make \verb|perf| work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck.
A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems.
But a lot can also be improved. For example,
\begin{itemize}
\item sqlite queries can be pre-``compiled''
\item (I think) more paralellism can be achieved.
\end{itemize}
Performance of ICFS is terrible. \sout{Unfortunately, I was unable to make perf work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck. A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems.}
I managed to get the \verb|perf| to work: it showed that almost all time was consumed by libfuse, not my program. My code used something like 0.0001\% of runtime on a pretty heavy test. I am not quite sure what to do, since libfuse is already optimised to smithereens. I guess I will just write how it is and not touch the performance ever again.
\section{Limitations}
\label{eval:limit}

Binary file not shown.

View File

@ -45,6 +45,8 @@
\usepackage[hidelinks,breaklinks]{hyperref}
%fancy references
\usepackage{cleveref}
%strikethorugh
\usepackage{ulem}
% -------------------
% --- REMOVE BEFORE PUBLISHING

View File

@ -23,7 +23,7 @@ Another problem of these solutions, is that their policies are granted forever a
\section{Containerisation}
Another solution to consider, is using containerised software distribution, like Flatpak\cite{FLATPAK}, Snapcraft\cite{SNAP} or AppImage\cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but, most importantly, file system objects.
Another solution to consider, is using containerised software distribution, like Flatpak \cite{FLATPAK}, Snapcraft \cite{SNAP} or AppImage \cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but, most importantly, file system objects.
However, because the developer of the distributed software is responsible for defining the permissions that his own program needs, it often leads to programs having excessive privileges after installation\footnote{It is important to mention, that although this flaw remains unmitigated, the analysis made by Dunlap et al. 2022 \cite{DunlapMAC} shows that most package maintainers actively attempt to define least-privilege application policies.} without any notification of the user.