gg582

It is a long way but I shall continue..

I guess there are cultural biases here, I hope to study together with somebody who knows Latin or Greek :)

Yep that's right. Using #if/#endif excludes whole lines(so compiler won't see any lines). And this difference can prevent when struggling with nested comments :)

Honestly I don't pretty sure if this post will impress somebody or not. But after a long period of vibe-coding I think I'm trying to do these methods..

some logics were reorganized. 感->減(sensing->reduction)

Some conventions are socially made... In C, some uses

#if 0

    these_lines_are();
    not_executed();

#endif

but most of the cases people just use

/* comments

* these_lines_are();

* not_executed();

*

* end comment */

Then, why?

#if 0

#endif

looks clear and it definitely says how a computer skips many lines.

But we just don't use it because it implies low-level knowledge "that every C developers have"

yep. There was a maintenance. :)

That's cool. Using a same logic, we can say 'Undefined behaviors are not behaviors.'

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

I wrote this post as a bit of an unconventional thought experiment.

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.

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:

* Revoking visibility via CAS before freeing (orthodox safe reclamation)

* Asymmetric pipeline handoffs

* Classic use-after-free bugs from premature freeing

* Race conditions caused by blind `memset` zeroing

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.

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.

:)

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.

I guess my comment is kinda messy, hm..Anyway, thanks for the reminder. Have a good day!

:)

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:

- 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.

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.

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.