All this hassle can be avoided by using `cleanup` compiler attribute.

Manage classical C resources by auto-cleanup variables and do error-handling the normal way. If everything is OK, pass the ownership of these resources from auto-cleanup variables to C++ ctor.

Note this approach plays nicely with C++ exception, and will enter C standard in the form of `defer`.

Yes, but now your code is no longer C or C++ standards compliant as it relies on compiler-specific attributes, if that matters to the programmer.

Unfortunately, even the Linux kernel is no longer C because they use GCC compiler extensions (and are currently discussing adding MS ones too).

A kernel will make use of asm, and can't abstract over the machine, so it will always be unportable and relying on compiler extensions.

The Linux kernel did not always rely on compiler extensions though...

The kernel once did not need asm? That's a compiler extension, although a popular one.

Note that these books were written when design pattern was still a buzzword.

Hence the apropos title of "Ghosts of Unix Past" :-)

IIRC, all latency-driven congestion control algorithms suffer from violent rtt variance, which happens frequently in wireless networks. How does BBR perform under such circumstances?

> The future may reduce the economic prosperity and push humanity to switch to some different economic system (maybe a better system).

Humans never truly produce anything; they only generate various forms of waste (resulting from consumption). Human technology merely enables the extraction of natural resources across magnitudes, without actually creating any resources. Given its enormous energy consumption, I strongly doubt that AI will contribute to a better economic system.

> Humans never truly produce anything; they only generate various forms of waste

What a sad way of viewing huge fields of creative expressions. Surely, a person sitting on a chair in a room improvising a song with a guitar is producing something not considered "waste"?

It's all about human technology, which enables massive resource consumption.

I should really say humans never truly produce anything in the realm of technology industry.

But that's clearly not true for every technology. Photoshop, Blender and similar creative programs are "technology", and arguably they aren't as resource-intensive as the current generative AI hype, yet humans used those to create things I personally wouldn't consider "waste".

The real issue is determining how much non-renewable resource consumption is justified for these "valuable" things? Note that we are always inclined to value ourselves too much.

I agree the things you mentioned are valuable in the very common sense and I deliberately assign them no value to the avoid the above issue.

> Humans never truly produce anything; they only generate various forms of waste

Counterpoint: nurses.

I just checked it for Rust:

"18 17 change Rust page Rust 0.97% -0.20%"

My understanding is that the signaling server could be used as the perfect place to perform MITM attack. The README does not mention how berb addresses this concern at all.

Oh I would love some more details if you think that's the case. With Berb only two clients can connect really. So let's say you somehow guess a peer ID, which is very tough, and connect to a random user. You can technically send a file but they can easily ignore it since they didn't initiate the transfer. That being said, I can definitely add a way to verify the file is legit like the suggestion in the reply with hashes.

Should users trust the signaling server? IIRC, the signaling server can easily intervene SDP offer/answer so that it can intercept user files or instruct users to send files wherever it wants.

Oh I see what you are saying. Yeah I guess if we didn't know what the signalling server was doing, that would be a valid argument. But in my case we can see the server code is pure and simple. Unless you mean there's a bug that allows an attacker to do that?

Either way, would love to know your thoughts on improving trust with this.

Do you have a proposal? (Showing file hashes could help, perhaps?)

Serious software development is rarely an individual endeavor; most issues should be resolved through collaboration. In other words, they should be addressed through management. What the author needs to overcome, in my view, is essentially a form of extreme individualism.

I guess that's a problem for a lot of us who learned to program as teenagers. A big reason programming felt good for me is precisely because it let me do interesting and impressive stuff myself, and not collaboratively. There were very few kids who had even remotely similar interests to me back then - and that's true in adulthood too, outside of work contexts. While on the job, my projects may be collaborative in nature, but after hours, there's very few people among my family and friends who'd even be interested in doing a small software project, much less capable of doing so.

I should mention that Drepper's old implementation and thus uclibc/uclibc-ng's implementations are much simpler and do not have this bug. The musl libc does not have this issue because it puts an upper limit on the number of user-space spins in one try. Unlimited spin should NEVER appear in user space!

I cannot believe that such a highly-reproducible bug is left untouched for nearly a year.

PS: All versions of glibc since 2.25 are affected.

> Python doesn't have a language package manager, you're free to use pip or poetry or uv or whatever, but it does have PEP 517/518, which allow all Python package managers to interact with a common package ecosystem which encompasses polyglot codebases.

This is a long-standing pain point. LWN has a series of reports covering this, one of which is: https://lwn.net/Articles/920832/