<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: gg582</title><link>https://news.ycombinator.com/user?id=gg582</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 18 Sep 2026 15:02:19 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=gg582" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by gg582 in "Anecdotally, programmers dislike "reduce""]]></title><description><![CDATA[
<p>Some conventions are socially made...
In C, some uses<p>#if 0<p><pre><code>    these_lines_are();
    not_executed();
</code></pre>
#endif<p>but most of the cases people just use<p>/* comments<p>*  these_lines_are();<p>*  not_executed();<p>*<p>* end comment */<p>Then, why?<p>#if 0<p>#endif<p>looks clear and it definitely says how a computer skips many lines.<p>But we just don't use it because it implies low-level knowledge "that every C developers have"</p>
]]></description><pubDate>Thu, 17 Sep 2026 07:18:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=49737491</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49737491</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49737491</guid></item><item><title><![CDATA[New comment by gg582 in "Reconstructing Concurrency Invariants Through Medieval East Asian Logic"]]></title><description><![CDATA[
<p>yep. There was a maintenance. :)</p>
]]></description><pubDate>Sun, 13 Sep 2026 16:12:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=49685594</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49685594</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49685594</guid></item><item><title><![CDATA[New comment by gg582 in "Reconstructing Concurrency Invariants Through Medieval East Asian Logic"]]></title><description><![CDATA[
<p>That's cool. Using a same logic, we can say 'Undefined behaviors are not behaviors.'</p>
]]></description><pubDate>Sun, 13 Sep 2026 16:12:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=49685592</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49685592</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49685592</guid></item><item><title><![CDATA[New comment by gg582 in "Reconstructing Concurrency Invariants Through Medieval East Asian Logic"]]></title><description><![CDATA[
<p>tried a silly crossover mapping memory reclamation invariants (visibility, UAF, CAS) to old trigram structures in c11. surprisingly mapped 1:1 pretty well. put the puzzle and code snippets here</p>
]]></description><pubDate>Fri, 11 Sep 2026 05:44:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=49653979</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49653979</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49653979</guid></item><item><title><![CDATA[New comment by gg582 in "Reconstructing Concurrency Invariants Through Medieval East Asian Logic"]]></title><description><![CDATA[
<p>I wrote this post as a bit of an unconventional thought experiment.<p>The idea was to take the concepts of memory reclamation and pointer visibility (stuff you see in EBR or RCU) and map them onto medieval East Asian state-machine logic—specifically the structural and matrix ideas from the Song-Yuan period.<p>To keep it grounded in actual code, I set up a small concurrent deallocation puzzle using C11 atomics and mapped four classical trigram patterns (乾, 坤, 坎, 離) directly to real-world memory invariants:<p>* Revoking visibility via CAS before freeing (orthodox safe reclamation)<p>* Asymmetric pipeline handoffs<p>* Classic use-after-free bugs from premature freeing<p>* Race conditions caused by blind `memset` zeroing<p>It's an attempt to see if ancient structural framing can provide an interesting symbolic vocabulary for modern low-level systems programming, without turning it into philosophical fluff. Thought some folks here might find the crossover interesting.</p>
]]></description><pubDate>Fri, 11 Sep 2026 04:31:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=49653589</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49653589</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49653589</guid></item><item><title><![CDATA[Reconstructing Concurrency Invariants Through Medieval East Asian Logic]]></title><description><![CDATA[
<p>Article URL: <a href="https://oborona.zip/post/a-middle-period-engine-reconstructing-concurrency-invariants-through-east-asian-structural-logic">https://oborona.zip/post/a-middle-period-engine-reconstructing-concurrency-invariants-through-east-asian-structural-logic</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=49653509">https://news.ycombinator.com/item?id=49653509</a></p>
<p>Points: 19</p>
<p># Comments: 7</p>
]]></description><pubDate>Fri, 11 Sep 2026 04:19:40 +0000</pubDate><link>https://oborona.zip/post/a-middle-period-engine-reconstructing-concurrency-invariants-through-east-asian-structural-logic</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49653509</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49653509</guid></item><item><title><![CDATA[Reconstructing lattice point enumeration using Asian counting rods]]></title><description><![CDATA[
<p>Article URL: <a href="https://oborona.zip/post/polygon-partitioning-and-piled-pile-sequences-on-an-equilateral-triangular-lattice">https://oborona.zip/post/polygon-partitioning-and-piled-pile-sequences-on-an-equilateral-triangular-lattice</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=49495680">https://news.ycombinator.com/item?id=49495680</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Sun, 30 Aug 2026 04:24:35 +0000</pubDate><link>https://oborona.zip/post/polygon-partitioning-and-piled-pile-sequences-on-an-equilateral-triangular-lattice</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=49495680</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49495680</guid></item><item><title><![CDATA[New comment by gg582 in "Show HN: LibTTAK- Explicit lifetime-as-data for C systems"]]></title><description><![CDATA[
<p>That is a valid point. When you are developing an application for an STM32, allocating memory on the heap is a bad idea. But if a programmer wants to make a high-performance back-end server in C, they should allocate unpredictable amounts of memory depending on a user's input(in many cases). This is not for Embedded/Hardware control; it aims for 'C Revival for High-level Development'. For a good example, many modern Rust applications do not statically fix memory areas; that is why Rust had to develop such a complex memory ownership system. In my personal opinion, with a bag of potato chips, you can do it better in C. Honestly, this does not have a proper memory tracker, so- yes. This does not have any advantages for now. However, I am planning to develop a memory lifetime tracker that can catch issues even before we run Valgrind or GDB. You can try to develop your own memory manager. This helped me to make my C-based web development framework safer through refactoring.<p>:)</p>
]]></description><pubDate>Fri, 06 Feb 2026 15:26:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=46913983</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=46913983</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46913983</guid></item><item><title><![CDATA[New comment by gg582 in "Debian's Challenge When Its Developers Drift Away"]]></title><description><![CDATA[
<p>Yes. But in my opinion, this is more than a problem of communication.
Many open source projects fail to retain their management cycle, or ecosystem even they have their Discord, or IRC to communicate. Many open source projects are having trouble retaining themselves and the core problem of them are 'they are just thriving in their cultural boundaries'. For example, in our country, South Korea, many open source projects are born and just die within a few years. And their core problem was 'only Korean developers can understand what is actually happening in that open source group'. I think that Debian volunteers communicate quite well, but the way how they communicate is immature. And, at least, they should let people know how they try hard to keep them alive. Debian is famous, and many developers in here think that it is 'a standard one for the normal office'. That means, no matter how Debian volunteers trying so hard, many people would perceive it as a 'untouchable' realm. Then it is important to re-think how to get people to continue on some positions. Debian still has translated documentations, even in a niche language. Like that, Debian should make more ways to 'encourage' developers to cooperate, in many languages. In 21th century, there's a great translator, so allowing people who don't speak English well, may not be a problem. Something like..yep, better than disappearing.<p>I guess my comment is kinda messy, hm..Anyway, thanks for the reminder.
Have a good day!<p>:)</p>
]]></description><pubDate>Fri, 06 Feb 2026 11:11:11 +0000</pubDate><link>https://news.ycombinator.com/item?id=46911473</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=46911473</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46911473</guid></item><item><title><![CDATA[Show HN: LibTTAK- Explicit lifetime-as-data for C systems]]></title><description><![CDATA[
<p>LibTTAK is a C systems collection that moves lifetime management from control flow logic into the data model.<p>In traditional C, memory safety relies on the programmer correctly ordering `free()` calls. Even in C++ or Rust, while RAII and ownership rules automate this, the logic still lives in the control flow. LibTTAK encodes the lifetime directly into the allocation.<p>Key features:<p>Lifetime as data: Every allocation has an explicit expiry.<p>Access validation: `ttak_mem_access(ptr, tick)` enforces expiry checks at the data level.<p>Minimalistic cleanup: No GC, but automatically frees memory with an interval, which can be turned off. Also, the user can manually clean up targeted pointers.<p>Operational coupling: Simplifies staged shutdowns and subsystem boundaries by grouping allocations under a single lifetime.<p>The goal is to provide the safety of deterministic cleanup without the overhead of a garbage collector or the complexity of complex ownership tracking.<p>Docs: <a href="https://gg582.github.io/libttak" rel="nofollow">https://gg582.github.io/libttak</a></p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=46910673">https://news.ycombinator.com/item?id=46910673</a></p>
<p>Points: 3</p>
<p># Comments: 2</p>
]]></description><pubDate>Fri, 06 Feb 2026 09:13:17 +0000</pubDate><link>https://github.com/gg582/libttak</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=46910673</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46910673</guid></item><item><title><![CDATA[New comment by gg582 in "Debian's Challenge When Its Developers Drift Away"]]></title><description><![CDATA[
<p>I believe the problem with Debian and many open source projects is that communities outside the US, Greater China, India, and some advanced European countries are relatively weak, making it difficult for project leader-level figures to emerge. I was born and raised in South Korea, a virtual open-source wasteland. Listening to testimonies from developers working here, many say, “I was captivated by the GNU spirit and wanted to contribute, but the Korean community's operations were poor, and clique-based territorialism was severe.” Ultimately, many open-source projects paradoxically miss out precisely because of their idealism and open management culture. I'd like to summarize it this way:<p>- Combining open source developers outside the core development regions and major cultural spheres could potentially secure roughly as many contributors as the entire US.
- Funding shortages for non-profit foundations are deeply entrenched. Denying or attempting to fix this immediately becomes greed.
  - It is possible to manage language barriers, cultural barriers, and guidelines for distant countries without becoming a greedy for-profit entity.
  - This does not mean holding DebConf in every country. However, if the awareness is simply that ‘there used to be no borders, but now it's different from the 90s’ regarding the shortage of personnel, then improvements should be more proactive.
  - The 2020s are no longer an era of romanticism where one flies from Angola to Germany just for the sake of romance.
  - Especially as Debian has established itself as an invisible system, becoming the backbone of countless cloud services, there is less room for romanticism to intervene.<p>I've used Debian since 2015 and have had no complaints during that time. Korea also had ‘administrators’ who spared no expense on plane tickets for GNU since the 90s, but most have now stepped down due to age, or, exhausted from trying to salvage communities torn apart by toxic members, have turned around and declared ‘BSD was right’. However, the project's sustainability deteriorating due to a ‘lack of administrators’ is definitely something that needs to be considered. If sufficient people cannot be recruited, and given that we cannot extend the freeze cycle like Slackware at present, communication between upstream and downstream and the active recruitment of multinational developers are important to resolve the complaints of ‘dependent families’ like Ubuntu.</p>
]]></description><pubDate>Thu, 05 Feb 2026 05:36:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=46896061</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=46896061</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46896061</guid></item><item><title><![CDATA[New comment by gg582 in "Show HN: The Last Worm – Visualizing guinea worm eradication, from 3.5M to 10"]]></title><description><![CDATA[
<p>Visualizing medical records that are difficult for the general public to understand is an excellent idea. The thorough explanations and diagrams make it an excellent educational resource. If its UX was designed with an educational website in mind, it's honestly a huge success. However, the lack of a light mode and the absence of search functionality for specific cases are a bit disappointing. If it's meant to function well as supplementary material for students, having those features would be great. But the decision is yours, and I also respect the choice to maintain the current style while considering other directions.</p>
]]></description><pubDate>Thu, 05 Feb 2026 05:15:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=46895928</link><dc:creator>gg582</dc:creator><comments>https://news.ycombinator.com/item?id=46895928</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46895928</guid></item></channel></rss>