mention cargo-script

diff --git a/personal/_posts/2024-04-14-bubblebox.md b/personal/_posts/2024-04-14-bubblebox.md
index 85dc684ebdcdbb6fb5d7b658e92ae7cf35eff037..cc8aa88e41636a003ffa886d55a61aca63104a63 100644 (file)
--- a/personal/_posts/2024-04-14-bubblebox.md
+++ b/personal/_posts/2024-04-14-bubblebox.md
@@ -38,7 +38,7 @@ org.freedesktop.secrets=none
 However, not all software exists as Flatpak.
 Also, sometimes I want software to run basically on my host system (i.e., to use the regular `/usr`), just without access to literally *everything* in my home directory.
 Examples of this are Factorio and VSCodium.
 However, not all software exists as Flatpak.
 Also, sometimes I want software to run basically on my host system (i.e., to use the regular `/usr`), just without access to literally *everything* in my home directory.
 Examples of this are Factorio and VSCodium.

-The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX on my host.
+The latter doesn't work in Flatpak as I want to use it with LaTeX, and realistically this means it needs to run the LaTeX installed via `apt`.

 The official recommendation is to effectively disable the Flatpak sandbox, but that entirely defeats the point, so I went looking for alternatives.
 
 [bubblewrap] provides a very convenient solution: it can start an application in its own private filesystem namespace with full control over which part of the host file system is accessible from inside the sandbox.
 The official recommendation is to effectively disable the Flatpak sandbox, but that entirely defeats the point, so I went looking for alternatives.
 
 [bubblewrap] provides a very convenient solution: it can start an application in its own private filesystem namespace with full control over which part of the host file system is accessible from inside the sandbox.


@@ -46,8 +46,9 @@ I wrote a small wrapper around bubblewrap to make this configuration a bit more
 this project is called [BubbleBox].
 This week-end I finally got around to adding support for [xdg-dbus-proxy] so that sandboxed applications can now access particular D-Bus functions without having access to the entire bus (which is in general not safe to expose to a sandboxed application).
 That means it's finally time to blog about this project, so here we go -- if you are interested, check out [BubbleBox];
 this project is called [BubbleBox].
 This week-end I finally got around to adding support for [xdg-dbus-proxy] so that sandboxed applications can now access particular D-Bus functions without having access to the entire bus (which is in general not safe to expose to a sandboxed application).
 That means it's finally time to blog about this project, so here we go -- if you are interested, check out [BubbleBox];

-the project page explains how you can use it to set up your own sandboxing.
-One day I should probably rewrite this in Rust...
+the project page explains how you can use it to set up your own sandboxing.[^1]
+
+[^1]: One day I should probably rewrite this in Rust... maybe this will be my test project for when [cargo-script](https://rust-lang.github.io/rfcs/3424-cargo-script.html) becomes available.

 
 I should also note that this is not the only bubblewrap-based sandboxing solution.
 [bubblejail] is fairly similar but provides a configuration GUI and a good set of default provides;
 
 I should also note that this is not the only bubblewrap-based sandboxing solution.
 [bubblejail] is fairly similar but provides a configuration GUI and a good set of default provides;