<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: fastandfearless</title><link>https://news.ycombinator.com/user?id=fastandfearless</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 09 Sep 2026 16:40:26 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=fastandfearless" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by fastandfearless in "Systemd-Networkd as a Router"]]></title><description><![CDATA[
<p>Hi,<p>I had almost the same question - and went in some other direction:<p><a href="https://github.com/mabels/ovn-fabric" rel="nofollow">https://github.com/mabels/ovn-fabric</a> --- there are some docs about why 
I got to that. And OVS should also utilize the hardware offloading of your
mono router.<p>The current main is in a state between a works-for-me proof of concept deployed in production on two instances --- and the more generalized version.<p>If you want to try it -- I'm happy to help.</p>
]]></description><pubDate>Sat, 15 Aug 2026 05:06:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=49307815</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49307815</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49307815</guid></item><item><title><![CDATA[The IPv6 Private Network Trap: Why Fd00:/8 Is Not 192.168.x.x]]></title><description><![CDATA[
<p>Article URL: <a href="https://mabels.github.io/mseg-tester/blog/fd00-is-not-your-192-168-short.html">https://mabels.github.io/mseg-tester/blog/fd00-is-not-your-192-168-short.html</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=49171489">https://news.ycombinator.com/item?id=49171489</a></p>
<p>Points: 5</p>
<p># Comments: 0</p>
]]></description><pubDate>Tue, 04 Aug 2026 16:50:02 +0000</pubDate><link>https://mabels.github.io/mseg-tester/blog/fd00-is-not-your-192-168-short.html</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49171489</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49171489</guid></item><item><title><![CDATA[New comment by fastandfearless in "Show HN: Isolade, a local-first coding agent workbench with secretless microVMs"]]></title><description><![CDATA[
<p>I can only say the same: "Most people run their coding agents directly on the host system."
And the problem between the host system and the microVM approach is the same, only that the host system is not isolated. But in both cases, I want the secrets to be undiscoverable by the AI. 
I use YubiKeys for SSH auth, so the AI could not use SSH without my consent. But for all other credentials like .files I almost saw the AI figure out how to use them without my consent. So your idea is good, but let's think about a bearer token for an API: how could an API use that without seeing the content of the token?
I thought of building a universal token-injector API proxy, but that is very limited; REST might work, WebSocket connections won't work with this, and most API implementations do not allow setting alternative endpoints. And I don't want to think about Mutual TLS.
So I decided to build something that tries to get consent for access to .files or passwords from password stores. There is a very early implementation only for SSH agents in github.com/mabels/project-43.</p>
]]></description><pubDate>Tue, 04 Aug 2026 15:47:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=49170604</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49170604</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49170604</guid></item><item><title><![CDATA[New comment by fastandfearless in "Parasitic computing with ICMP: making routers do arithmetic"]]></title><description><![CDATA[
<p>That's a cool idea and implementation. I like your efforts regardless of their usefulness!</p>
]]></description><pubDate>Sat, 01 Aug 2026 07:56:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=49132148</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49132148</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49132148</guid></item><item><title><![CDATA[I got tired of router appliance limitations, so I moved my home network to OVN]]></title><description><![CDATA[
<p>Article URL: <a href="https://mabels.github.io/ovn-fabric/blog/ovn-fabric-writeup.html">https://mabels.github.io/ovn-fabric/blog/ovn-fabric-writeup.html</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=49083187">https://news.ycombinator.com/item?id=49083187</a></p>
<p>Points: 3</p>
<p># Comments: 0</p>
]]></description><pubDate>Tue, 28 Jul 2026 13:03:33 +0000</pubDate><link>https://mabels.github.io/ovn-fabric/blog/ovn-fabric-writeup.html</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49083187</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49083187</guid></item><item><title><![CDATA[New comment by fastandfearless in "Authoritative Dnsmasq in a MikroTik Container"]]></title><description><![CDATA[
<p>Nice work! I ran into that exact same MikroTik limitation when trying to set up segment-based DNS resolvers and forwarders for per-region routing.<p>After a lot of procrastination, I ended up taking a different path to solve it: <a href="https://github.com/mabels/unified-dns-dhcp-chart" rel="nofollow">https://github.com/mabels/unified-dns-dhcp-chart</a><p>It runs Technitium per segment inside Kubernetes via Multus CNI (though K8s isn't strictly required and could be stripped out).<p>I'm currently planning to join it with another project of mine, ovn-fabric (<a href="https://github.com/mabels/ovn-fabric" rel="nofollow">https://github.com/mabels/ovn-fabric</a>), which handles declarative OVN/OVS topology and uses transit networks/namespaces to treat things like WireGuard or ZeroTier as virtual uplinks—DN42 is next on the list for that as well.</p>
]]></description><pubDate>Mon, 27 Jul 2026 04:08:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=49065108</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=49065108</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49065108</guid></item><item><title><![CDATA[New comment by fastandfearless in "Show HN: Fireproof – local-first database with Git-like encrypted sync"]]></title><description><![CDATA[
<p>I'm happy working on fireproof. The people are very  nice. In terms of technology it's a new kind on block. Yes a bit of database and a bit of Blockchain with git rebase.That's why we moving from naming it database to ledger lately.</p>
]]></description><pubDate>Wed, 20 Nov 2024 08:37:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=42191879</link><dc:creator>fastandfearless</dc:creator><comments>https://news.ycombinator.com/item?id=42191879</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42191879</guid></item></channel></rss>