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.

:)

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.

The challenge outlined by the article is the lack of communication regarding the change in availability of Debian volunteers themselves. TFA doesn't mention issues regarding recruitment of new developers.

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!

:)

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.