<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: lifthrasiir</title><link>https://news.ycombinator.com/user?id=lifthrasiir</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 15 Jun 2026 18:49:20 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=lifthrasiir" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by lifthrasiir in "WASI 0.3"]]></title><description><![CDATA[
<p>Of course, but I'm talking about "annoyance". GC type system is especially annoying if you are not writing the full compiler.</p>
]]></description><pubDate>Sat, 13 Jun 2026 04:04:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=48512959</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48512959</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48512959</guid></item><item><title><![CDATA[New comment by lifthrasiir in "WASI 0.3"]]></title><description><![CDATA[
<p>I have seriously attempted to write my own WebAssembly 3.0 implementation recently, and while I did finish the whole thing [1] that left me a bitter taste about WasmGC which turned out to be very annoying to implement. In fact, I originally wanted to avoid GC but spectest assumed that GC is always available and I had no other option but implementing one in order to make use of spectest in the first place.<p>[1] <a href="https://github.com/lifthrasiir/wah/" rel="nofollow">https://github.com/lifthrasiir/wah/</a></p>
]]></description><pubDate>Fri, 12 Jun 2026 19:51:59 +0000</pubDate><link>https://news.ycombinator.com/item?id=48508705</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48508705</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48508705</guid></item><item><title><![CDATA[New comment by lifthrasiir in "The 29th International Obfuscated C Code Contest (IOCCC) 2025 Winners"]]></title><description><![CDATA[
<p>I think the "obfuscation" is actually two very different acts: the apparent obfuscation, that is concerned with randomly looking output, and the information-theoretic obfuscation, that takes computational effort to undo it. Commercial obfuscators are mostly the former, making undo much more annoying but easy to undo if you have a right tool. The obfuscation in IOCCC is much more the latter, requiring the heavy logic and deduction to see through that. In my experience LLMs have been capable of doing the former and undoing the latter but <i>not</i> doing the latter, presumably because any obfuscated program still has to run somehow. Given that this form of obfuscation is not common (and that LLMs tend to work well with established things), your initial statement was I believe quite far-fetched.</p>
]]></description><pubDate>Sun, 07 Jun 2026 11:19:03 +0000</pubDate><link>https://news.ycombinator.com/item?id=48433769</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48433769</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48433769</guid></item><item><title><![CDATA[New comment by lifthrasiir in "The 29th International Obfuscated C Code Contest (IOCCC) 2025 Winners"]]></title><description><![CDATA[
<p>While this has been downvoted to the death, it is fun to guess how many entries are submitted to each IOCCC. My best guess is around 10^2.5, i.e. 3--400. Rationales:<p>- The number of winning entries and losing entries that get revealed later in public suggests that this number should be at least 50.<p>- The number of judging rounds, as the FAQ says, is at least 3 and possibly more. If each judging round eliminates about a half of entries, we should expect at least 10 submissions per each winning entries. I personally think the actual elimination rate can be as low as 1--20% at the end, but at least first few rounds should be easy so I think this is a good minimum guess: 1--200.<p>- The current number of individual judges is just enough for the three-digit number of submissions. It has a striking resemblance with typical academic conferences with typical acceptance rate, by the way! If there were thousands of submissions (like today's AI conferences...) there ought to be much more judges, and more importantly, more <i>levels</i> of judges so that each judge can do just enough work throughout the entire process. So this establishes the maximum guess: 1,000.<p>- My best guess is simply a geometric mean of two extrema.</p>
]]></description><pubDate>Sun, 07 Jun 2026 10:28:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=48433482</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48433482</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48433482</guid></item><item><title><![CDATA[New comment by lifthrasiir in "The 29th International Obfuscated C Code Contest (IOCCC) 2025 Winners"]]></title><description><![CDATA[
<p>Just two months ago I tried to write a short K code with Claude Opus 4.6, only to find that while it had sufficient knowledge about K vocabularies it didn't try to make good use of them. K is, while <i>slightly</i> obscure and obfuscated, a real programming language and certainly better known than obfuscated programming. I don't have high hope for IOCCC-grade obfuscation.</p>
]]></description><pubDate>Sun, 07 Jun 2026 10:07:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=48433390</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48433390</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48433390</guid></item><item><title><![CDATA[New comment by lifthrasiir in "The 29th International Obfuscated C Code Contest (IOCCC) 2025 Winners"]]></title><description><![CDATA[
<p>IOCCC disallows such entries for the obvious reason ;-)</p>
]]></description><pubDate>Sun, 07 Jun 2026 09:09:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=48433145</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48433145</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48433145</guid></item><item><title><![CDATA[New comment by lifthrasiir in "The 29th International Obfuscated C Code Contest (IOCCC) 2025 Winners"]]></title><description><![CDATA[
<p>In my experience LLMs were pretty good at deobfuscating many entries (including mine) but very awful at generating any significantly obfuscated code. So obfuscation can be regarded as a truly humane art---at least for now.</p>
]]></description><pubDate>Sun, 07 Jun 2026 07:01:02 +0000</pubDate><link>https://news.ycombinator.com/item?id=48432554</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48432554</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48432554</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Ask HN: Why is the HN crowd so anti-AI?"]]></title><description><![CDATA[
<p>Mainly because noisy people are most visible. Both pro-AI and anti-AI (so to speak) crowds have them.</p>
]]></description><pubDate>Sat, 06 Jun 2026 03:35:47 +0000</pubDate><link>https://news.ycombinator.com/item?id=48421142</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48421142</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48421142</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>While I agree that Han Unification is not optimal (and fixing them is a welcoming development), it is already too late to reverse it. Even counter-proposals like TRON didn't work at all so far. IVD is the best compromise we can have in this situation.<p>> cultural division and xenophobia perpetuate in East Asia<p>By the way, I recently have seen multiple claims from Japanese Twitter users that Korea would have been better keeping Chinese characters (Hanja) in use. If this <i>is</i> a cultural division and xenophobia we are talking about, I will gladly take it---why on earth do they have any saying in Korea's choice of scripts? The "sinosphere" is an illusion, the fact that CJKV countries have or had shared the same set of characters is just a fun fact and not a cultural mandate or anything else like that.</p>
]]></description><pubDate>Wed, 27 May 2026 18:33:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=48298478</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48298478</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48298478</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>Your argument is absurd because people don't see code---they see glyphs, and using the same code for slightly different glyphs is a non-issue when they are not interchanged. (And when they are interchanged, both would see glyphs "correct" to them anyway.) Japaneses are sensitive to Han unification only because they recognize more glyph variations (Z-variants) than what Unicode originally could, and IVS is exactly a tool for ensuring exact glyphs assuming cooperative vendors. Not to mention that Han unification was already quite weakened by source separation principles in the first place.</p>
]]></description><pubDate>Wed, 27 May 2026 13:04:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=48293680</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48293680</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48293680</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>IVD works, theoretically and practically (recent versions of OpenType have an explicit support for them). It's not their fault that Japanese vendors have been not very quick to adopt them.</p>
]]></description><pubDate>Wed, 27 May 2026 12:08:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=48293012</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48293012</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48293012</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>For now, follow UCSUR: <a href="https://sona.pona.la/wiki/Under-ConScript_Unicode_Registry" rel="nofollow">https://sona.pona.la/wiki/Under-ConScript_Unicode_Registry</a></p>
]]></description><pubDate>Wed, 27 May 2026 10:08:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=48292034</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48292034</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48292034</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>Vendors-have-no-capacity-to-handle-more-than-handful-number-of-emojis-per-each-release thing.<p>To elaborate: it should be plain obvious that not every Emoji proposal can be accepted even though all of them are correctly filed, as there would be too many Emojis there then. So there has to be some threshold, and that threshold is mostly stipulated by vendors' willingness to process new Emoji characters for designing fonts and updating softwares in time.</p>
]]></description><pubDate>Wed, 27 May 2026 10:01:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=48291989</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48291989</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48291989</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>Han Unification was effectively "fixed" by Ideographic Variation Sequences, so no.</p>
]]></description><pubDate>Wed, 27 May 2026 09:59:27 +0000</pubDate><link>https://news.ycombinator.com/item?id=48291970</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48291970</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48291970</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Unicode 18.0.0 Beta"]]></title><description><![CDATA[
<p>As an example of having not-exactly-a-character as Unicode "characters", it is rather rare that musical symbols are embedded in running texts (which is a primary litmus test for encoding), but musical symbols are typically rendered with existing font technology so there are needs for standardized "character" codes, as SMuFL [1] does. In fact Unicode 18 will get tons of musical symbols that have been in SMuFL for a long time but not yet in Unicode [2].<p>[1] <a href="https://www.smufl.org/" rel="nofollow">https://www.smufl.org/</a><p>[2] <a href="https://www.unicode.org/L2/L2025/25017-miscellaneous-musical-symbols.pdf" rel="nofollow">https://www.unicode.org/L2/L2025/25017-miscellaneous-musical...</a></p>
]]></description><pubDate>Wed, 27 May 2026 09:51:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=48291910</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48291910</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48291910</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Stop Advertising in Your Commits"]]></title><description><![CDATA[
<p>Notably though, Linux's requirement (Assisted-by) is different from what Claude Code actually does (Co-Authored-By). I'm not sure, but it might be intentional (to make the signaling explicit).</p>
]]></description><pubDate>Tue, 26 May 2026 19:35:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=48284861</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48284861</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48284861</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Browser-based file encryption tool using WebCrypto"]]></title><description><![CDATA[
<p>I wouldn't recommend to paste a completely opaque script though. ;-) For the reference, the uncompressed code is not that big either:<p>async function p(){let e=document.createElement("input");e.type="file",e.onchange=async e=>{let t=e.target.files[0];if(!t)return;let a=await t.arrayBuffer(),n=new Uint8Array(a),i=prompt("Enter password:");if(!i)return;let c=window.crypto.subtle,r=new TextEncoder().encode(i),l=await c.importKey("raw",r,"PBKDF2",!1,["deriveKey"]),s;try{let o=n.slice(0,16),y=n.slice(16,32),w=n.slice(32),p=await c.deriveKey({name:"PBKDF2",salt:o,iterations:1e5,hash:"SHA-256"},l,{name:"AES-GCM",length:256},!1,["decrypt"]),d=await c.decrypt({name:"AES-GCM",iv:y},p,w);s=new Uint8Array(d),console.log("File successfully decrypted!")}catch(m){console.log("Decryption failed. Proceeding with encryption...");let $=crypto.getRandomValues(new Uint8Array(16)),h=crypto.getRandomValues(new Uint8Array(16)),f=await c.deriveKey({name:"PBKDF2",salt:$,iterations:1e5,hash:"SHA-256"},l,{name:"AES-GCM",length:256},!1,["encrypt"]),g=await c.encrypt({name:"AES-GCM",iv:h},f,n),u=new Uint8Array(g);(s=new Uint8Array(32+u.byteLength)).set($,0),s.set(h,16),s.set(u,32)}let _;_=t.name.endsWith(".enc")?t.name.slice(0,-4):t.name+".enc";let E=new Blob([s],{type:"application/octet-stream"}),K=document.createElement("a");K.href=URL.createObjectURL(E),K.download=_,K.click(),URL.revokeObjectURL(K.href)},e.click()};p()</p>
]]></description><pubDate>Tue, 26 May 2026 03:41:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=48274707</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48274707</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48274707</guid></item><item><title><![CDATA[New comment by lifthrasiir in "WebAssembly 128-bit packed SIMD Extension"]]></title><description><![CDATA[
<p>FYI: This has been an integral part of WebAssembly since 2.0. WebAssembly 3.0 also added "relaxed" SIMD instructions which result is allowed to vary under specified constraints at implementation's choice.</p>
]]></description><pubDate>Tue, 26 May 2026 02:44:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=48274386</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48274386</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48274386</guid></item><item><title><![CDATA[New comment by lifthrasiir in "sp.h: Fixing C by giving it a high quality, ultra portable standard library"]]></title><description><![CDATA[
<p>Feel free to ignore if you don't feel so.</p>
]]></description><pubDate>Sat, 23 May 2026 18:22:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=48249908</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48249908</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48249908</guid></item><item><title><![CDATA[New comment by lifthrasiir in "Microsoft starts canceling Claude Code licenses"]]></title><description><![CDATA[
<p>4.7 turned out to be a disaster in multilingual settings, so I sticked to 4.6 so far. 4.7 seemed to be optimized for (very specific slice of) coding at the expense of everything else.</p>
]]></description><pubDate>Sat, 23 May 2026 10:42:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=48246538</link><dc:creator>lifthrasiir</dc:creator><comments>https://news.ycombinator.com/item?id=48246538</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48246538</guid></item></channel></rss>