<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: segbrk</title><link>https://news.ycombinator.com/user?id=segbrk</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 25 May 2026 19:35:53 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=segbrk" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by segbrk in "Bytecode VMs in surprising places (2024)"]]></title><description><![CDATA[
<p>Since that page is a little dense, the higher-level version: PCI supports Option ROMs (OpRoms) - plug in device like a NIC or a GPU, your BIOS actually loads compiled code from it and executes it on the CPU. In many systems for example PXE booting (net booting) is actually a function of the NIC, executing code on the CPU to load an operating system. We're talking actual x86/x86_64 machine code here running in the privileged pre-boot environment. Not portable or secure in any way. OpRoms _may_ now be checked for SecureBoot signatures on systems where that's set up properly at least.<p>EFI ByteCode (EBC) is meant to help at least the portability side. I'm not sure if anybody is actually delivering devices with EBC OpRoms yet though. I'm also not sure if anybody is looking at using the EBC VM to sandbox untrusted OpRoms.</p>
]]></description><pubDate>Mon, 25 May 2026 17:48:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=48269629</link><dc:creator>segbrk</dc:creator><comments>https://news.ycombinator.com/item?id=48269629</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48269629</guid></item><item><title><![CDATA[New comment by segbrk in "RSoC 2026: A new CPU scheduler for Redox OS"]]></title><description><![CDATA[
<p>Here you go: <a href="https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_shared/start.rs" rel="nofollow">https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/sr...</a></p>
]]></description><pubDate>Tue, 07 Apr 2026 22:39:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=47682269</link><dc:creator>segbrk</dc:creator><comments>https://news.ycombinator.com/item?id=47682269</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47682269</guid></item><item><title><![CDATA[New comment by segbrk in "How to turn anything into a router"]]></title><description><![CDATA[
<p>That's a bigger can of worms than you might expect. Most consumer WiFi chips only barely support AP mode, and I'm not aware of any that can do multiple bands simultaneously. You'd probably need 4 adapters on the repeater for triband. One to connect upstream, one for each downstream band. Three instances of hostapd all configured with the same SSID and auth for each downstream interface.<p>Then there's the roaming issue. This is largely what the commercial "mesh" systems try to solve: deciding / helping inform when clients should switch APs. There are many solutions and none of them are without issues, including the commercial ones. Here's a starting point: <a href="https://openwrt.org/docs/guide-user/network/wifi/roaming" rel="nofollow">https://openwrt.org/docs/guide-user/network/wifi/roaming</a></p>
]]></description><pubDate>Mon, 30 Mar 2026 16:46:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=47576662</link><dc:creator>segbrk</dc:creator><comments>https://news.ycombinator.com/item?id=47576662</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47576662</guid></item></channel></rss>