<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: sleirsgoevy</title><link>https://news.ycombinator.com/user?id=sleirsgoevy</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 07 Sep 2026 12:52:40 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=sleirsgoevy" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>Looks like you know some internal details of the A53 cores, can you share the source?</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:55:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596743</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596743</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596743</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>x86_64 seems not to care much. I've had a UART mapped as normal memory, and it somehow still worked.</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:49:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596693</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596693</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596693</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>I don't even have a real heap there, only a primitive 1-page allocator for pagetables.</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:44:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596646</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596646</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596646</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>This just means that Apple is a big enough player for ARM to retroactively amend the standard. Does not mean that what Apple did was not a violation of then-standard tho.</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:31:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596550</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596550</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596550</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>No, that instruction does not read memory. That instruction is itself IN the inaccessible memory.<p>It does not really matter how execution ended up in the HV in the first place. The misprediction happens due to having a branch-to-register instruction.</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:23:39 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596498</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596498</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596498</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "The NX bit is not just about security"]]></title><description><![CDATA[
<p>Post author here. I wanted the code to be "as generic as possible", so I had to accept the possibility of some useful thing being at address 0.</p>
]]></description><pubDate>Mon, 07 Sep 2026 10:20:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=49596479</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=49596479</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49596479</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "A theoretical way to circumvent Android developer verification"]]></title><description><![CDATA[
<p>What about this idea? Make a movement among the devs who are <i>willing</i> to distribute "legitimately" (via Google Play or "authorized" sideload), to sign their apps with intentionally insecure private key. Then some community will just mine up these certificates in already published apps and publish them somewhere on GitHub.</p>
]]></description><pubDate>Sat, 01 Nov 2025 12:06:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=45781015</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=45781015</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45781015</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "A theoretical way to circumvent Android developer verification"]]></title><description><![CDATA[
<p>Making every user to "verify" themselves with a government ID is a no-go, because government IDs are no more trustworthy than a toilet paper.</p>
]]></description><pubDate>Sat, 01 Nov 2025 12:03:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=45780999</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=45780999</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45780999</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "A theoretical way to circumvent Android developer verification"]]></title><description><![CDATA[
<p>The issue with government IDs is that they are, for all we know, not trustworthy, but everyone treats them like they are. And you know, I am not going to "verify" myself with Google with this kind of toilet paperwork.<p>If Google decides to pull this off, then I guess reflashing to a custom ROM with this crap patched out will be a very first step I'll be recommending to anyone who cares.</p>
]]></description><pubDate>Sat, 01 Nov 2025 11:59:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=45780976</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=45780976</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45780976</guid></item><item><title><![CDATA[A theoretical way to circumvent Android developer verification]]></title><description><![CDATA[
<p>Article URL: <a href="https://enaix.github.io/2025/10/30/developer-verification.html">https://enaix.github.io/2025/10/30/developer-verification.html</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=45776269">https://news.ycombinator.com/item?id=45776269</a></p>
<p>Points: 196</p>
<p># Comments: 178</p>
]]></description><pubDate>Fri, 31 Oct 2025 20:20:42 +0000</pubDate><link>https://enaix.github.io/2025/10/30/developer-verification.html</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=45776269</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45776269</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "Detecting if an expression is constant in C"]]></title><description><![CDATA[
<p>The Linux kernel has even a way to determine whether the expression is compile-time, WITHOUT aborting compilation in either case.<p>The trick is this (copied vebratim from Linux):<p>#define __is_constexpr(x) (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))<p>Explanation: if x is a constant expression, then multiplying it by zero yields a constant 0, and casting a constant 0 to void* makes a null pointer constant. And the ternary expression, if one of its sides is a null pointer constant, collapses to the type of the other side (thus the type of the returned pointer will be int*, and the sizeof will match). And if x was not constant, then the lefthand side would not be considered a null pointer constant by type inference, the type of the ternary expression will be void*, and the sizeof check will not match.<p>With a few more clever tricks, it's even possible to implement a compile-time "type ternary expression", like this: TYPE_IF(2 * 2 == 4, int, long). This is left as an exercise for the reader.</p>
]]></description><pubDate>Tue, 13 May 2025 16:35:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=43974770</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=43974770</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=43974770</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "Adding Systemd to PostmarketOS"]]></title><description><![CDATA[
<p>Not really, it's garbage to the point that it only runs the X11 session, mutter can't even be compiled with Wayland support because it then tries to include some Linux-only header.</p>
]]></description><pubDate>Wed, 13 Mar 2024 07:49:51 +0000</pubDate><link>https://news.ycombinator.com/item?id=39689004</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=39689004</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39689004</guid></item><item><title><![CDATA[New comment by sleirsgoevy in "Yuzu emulator developers settle Nintendo lawsuit, pay $2.4M in damages"]]></title><description><![CDATA[
<p>```
git clone <a href="https://github.com/irfanhakim-as/yuzu-mainline">https://github.com/irfanhakim-as/yuzu-mainline</a>
git fetch origin 537296095ab24eddcb196b5ef98004f91de9c8c2
```<p>It seems that GitHub still serves the commit history through the existing forks of the repo. According to archive.org, this commit corresponds to the last release of yuzu-mainline before the repo takedown: <a href="http://web.archive.org/web/20240304185516/https://github.com/yuzu-emu/yuzu-mainline/releases/tag/mainline-0-1734" rel="nofollow">http://web.archive.org/web/20240304185516/https://github.com...</a></p>
]]></description><pubDate>Mon, 04 Mar 2024 20:49:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=39595856</link><dc:creator>sleirsgoevy</dc:creator><comments>https://news.ycombinator.com/item?id=39595856</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=39595856</guid></item></channel></rss>