<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Plugins on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/plugins/</link><description>Recent content in Plugins on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 20 Aug 2026 10:05:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/plugins/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a plugin host without recompiling the daemon</title><link>https://www.visorcraft.com/news/2026/08/building-a-plugin-host-without-recompiling-the-daemon/</link><pubDate>Thu, 20 Aug 2026 10:05:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/building-a-plugin-host-without-recompiling-the-daemon/</guid><description>&lt;p&gt;Every sensor you compile into a monitoring daemon is a sensor you have to ship, support, and restart the daemon to fix, and once your users start asking for hardware you do not own, the math stops working, because the bottleneck is no longer writing the sensor but cutting a release every time someone wants one. The obvious answer is runtime plugins, and the less obvious part is everything that comes after you say yes to &lt;code&gt;dlopen&lt;/code&gt;, because a plugin host is not a feature you add but a contract you sign, and the contract is what decides whether the host survives its own first three releases.&lt;/p&gt;</description></item></channel></rss>