<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ipc on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/ipc/</link><description>Recent content in Ipc on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 25 Aug 2026 06:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/ipc/index.xml" rel="self" type="application/rss+xml"/><item><title>Postcard over a Unix socket: a tiny RPC for system monitoring</title><link>https://www.visorcraft.com/news/2026/08/postcard-over-a-unix-socket-tiny-rpc/</link><pubDate>Tue, 25 Aug 2026 06:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/postcard-over-a-unix-socket-tiny-rpc/</guid><description>&lt;p&gt;Somewhere along the way, &amp;ldquo;two processes on the same machine need to talk&amp;rdquo; started defaulting to an HTTP server on a loopback port, and the habit is so deep that most engineers never stop to ask what the TCP handshake, the header block, and the JSON parser are actually buying when the client and the server share a kernel and a filesystem. LinSight&amp;rsquo;s daemon answers that question by not paying any of it: the GUI, the CLI, and every third-party tool that wants live sensor data all speak postcard-framed messages over a plain Unix socket at &lt;code&gt;$XDG_RUNTIME_DIR/linsight.sock&lt;/code&gt;, and the whole wire protocol is one crate with a &lt;code&gt;FrameReader&lt;/code&gt;, a &lt;code&gt;FrameWriter&lt;/code&gt;, and a version handshake.&lt;/p&gt;</description></item></channel></rss>