<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rust on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/rust/</link><description>Recent content in Rust on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 21 Jul 2026 10:30:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/rust/index.xml" rel="self" type="application/rss+xml"/><item><title>MongrelDB-Kit: One Schema, Three Languages, One Rust Core</title><link>https://www.visorcraft.com/news/2026/07/mongreldb-kit-one-schema-three-languages/</link><pubDate>Tue, 21 Jul 2026 10:30:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/mongreldb-kit-one-schema-three-languages/</guid><description>&lt;p&gt;The hard part of shipping a database client in three languages is not writing three query builders, it is keeping them honest against each other over years of changes, because the moment one language&amp;rsquo;s surface drifts on a nullable column, or on how a cascade delete behaves, or on what a migration rollback actually does, you have three databases pretending to be one, and every bug report becomes an archaeology project about which SDK the user was touching when the assumption broke.&lt;/p&gt;</description></item><item><title>LinSync: Sandboxing 200 Plugins with Landlock, seccomp, and bubblewrap</title><link>https://www.visorcraft.com/news/2026/07/linsync-sandboxing-200-plugins-with-landlock-seccomp-and-bubblewrap/</link><pubDate>Sat, 18 Jul 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/linsync-sandboxing-200-plugins-with-landlock-seccomp-and-bubblewrap/</guid><description>&lt;p&gt;Running third-party extractors on user files is the kind of feature that looks safe until you read the CVE list for any single one of them, and LinSync&amp;rsquo;s plugin host does exactly that, all day, on documents and images that came from email attachments, cloud drives, and the web, which means the safety of the whole application depends on the safety of binaries we did not write and cannot fully audit.&lt;/p&gt;</description></item><item><title>LinSight: The Hot Path Has No Async Runtime</title><link>https://www.visorcraft.com/news/2026/07/linsight-the-hot-path-has-no-async-runtime/</link><pubDate>Thu, 16 Jul 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/linsight-the-hot-path-has-no-async-runtime/</guid><description>&lt;p&gt;The reflexive choice in modern Rust services is &lt;code&gt;#[tokio::main]&lt;/code&gt;, and the reflexive architecture is &amp;ldquo;every I/O call is async, every handler is a future, every blocking call is wrapped in &lt;code&gt;spawn_blocking&lt;/code&gt; and apologized for&amp;rdquo;; on a system monitoring daemon that polls &lt;code&gt;/proc&lt;/code&gt; and &lt;code&gt;/sys&lt;/code&gt; and pushes a number to clients over a loopback socket, every one of those reflex choices is overhead you do not need, and the result is a hot path that does the same work in roughly a ninth of the time with a tenth of the resident footprint, because the runtime was never the right tool for the job in the first place.&lt;/p&gt;</description></item><item><title>IcefallDB: Time Travel on Plain Parquet Files</title><link>https://www.visorcraft.com/news/2026/07/icefalldb-time-travel-parquet/</link><pubDate>Tue, 14 Jul 2026 10:04:25 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/icefalldb-time-travel-parquet/</guid><description>&lt;p&gt;Parquet is the columnar format that ate the data lake, and for good reason: it compresses well, it reads fast, every analytics engine from DuckDB to Spark to DataFusion speaks it natively, and the files are just sitting there on disk waiting to be queried by anything that can open them, which is the same property that made SQLite appealing for a different class of problem. The catch, and it is a significant catch, is that Parquet is immutable by design, the format spec has no concept of updating a row in place, deleting a tuple, or merging two versions of a record, and the moment you need any of those operations you are in the business of rewriting files or building a layer on top that pretends mutability exists; IcefallDB is that layer, and the interesting work was making the pretension convincing enough that you stop noticing it.&lt;/p&gt;</description></item><item><title>grexa-db: a database where joins are directories of symlinks</title><link>https://www.visorcraft.com/news/2026/07/grexa-db-filesystem-joins/</link><pubDate>Sat, 11 Jul 2026 10:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/grexa-db-filesystem-joins/</guid><description>&lt;p&gt;Every database project starts with the same question: where does the data live? The conventional answers are a server process, a binary format, a set of memory-mapped pages, or a cloud endpoint. grexa-db answers differently: the data lives wherever your filesystem puts it, which means it lives everywhere your filesystem already goes, and the consequences of that choice are the interesting part.&lt;/p&gt;
&lt;p&gt;The short version is that grexa-db is a flat-file database engine where records are individual files and join relationships are directories full of symlinks, and the reason that matters is that every tool already written to read files from disk becomes, without modification, a query interface for your data: &lt;code&gt;rg&lt;/code&gt; searches records, &lt;code&gt;find&lt;/code&gt; traverses relationships, editors open rows, and your file-manager navigation habits become your database navigation habits, all without anyone involved having to know a database is present, though you do need &lt;code&gt;rg --follow&lt;/code&gt; or &lt;code&gt;find -L&lt;/code&gt; to traverse the join symlinks since most tools skip symlinks by default.&lt;/p&gt;</description></item><item><title>Arte-Ogre: Why We Test Image Editors with Byte-Identical Round-Trips</title><link>https://www.visorcraft.com/news/2026/07/arte-ogre-byte-identical-round-trips/</link><pubDate>Thu, 09 Jul 2026 10:19:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/arte-ogre-byte-identical-round-trips/</guid><description>&lt;p&gt;Cut a region of a transparent layer in Photoshop, switch layers, and paste, and the paste lands at &lt;code&gt;(0, 0)&lt;/code&gt;, while in GIMP it lands at the cursor and in Krita at the layer origin, and none of them land where you cut from, because the position is recoverable in some editors, lost in others, and never consistently tested; the position isn&amp;rsquo;t part of the data, and it&amp;rsquo;s a side effect of whichever application happens to be in front of you when you hit paste.&lt;/p&gt;</description></item><item><title>Building in the Open: Why VisorCraft Maintains Multiple Open Source Projects</title><link>https://www.visorcraft.com/news/2026/07/building-in-the-open/</link><pubDate>Wed, 08 Jul 2026 00:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/07/building-in-the-open/</guid><description>&lt;p&gt;We keep over 50 public repositories under the &lt;code&gt;visorcraft&lt;/code&gt; GitHub organization, under a mix of GPL-3.0, Apache-2.0, and MIT. The five featured below are the bigger product-grade ones: Arte Ogre, Kanoprii, Grexa, Roamarr, and Grex. MongrelDB, our open source database, is &lt;a href="https://github.com/visorcraft/MongrelDB"&gt;its own thing&lt;/a&gt; and is not part of this count. The rest of the repos are smaller things we built for ourselves along the way.&lt;/p&gt;
&lt;p&gt;The one thing we don&amp;rsquo;t open source is Mongrel, the commercial product. Mongrel is closed source and it pays the people who build the rest of this.&lt;/p&gt;</description></item></channel></rss>