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`.
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.
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.
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.
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.
> If I work on a repo, all I have to do is enter my dev distrobox, SSH in from my IDE, and work within that environment - no devcontainer or flake.nix required.
With Ubuntu 24.04 and vagrant virtual machines, you could have even less hassle than with Bluefin.
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 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.
Can't agree more. As a longtime user of Eclipse CDT on Ubuntu Desktop， I've not seen the kind of bugs mentioned in the article for more than five years.
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`.