howtofly

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

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

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?

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.

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

I just checked it for Rust:

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

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.

> I wonder what makes our experiences so different? Do you unit test a lot? Particularly with TDD? I am guessing that this practice means I just don't get to see a lot of the bugs that a debugger would help me with.

Debugger helps a lot when performing TDD. You will enjoy setting a breakpoint to check whether a line is hit as expected by a test case.

I've used classic eclipse-cdt for over a decade until it cannot keep up with post-C++14 standards. It seems that it recently regains activity with the introduction of https://github.com/ghentschke/eclipse-cdt-lsp

> For anything quasi-realtime, I can certainly hunt down and squash everything systemd is running at the wrong time, but in practice it's much easier to install something else, ensure no processes are running other than the ones I care about, and move those concerns to userspace.

Should these issues be fixed by CPU/IO schedulers? Are there any systemd realtime tasks involved?

I really hope that there will be joint-force between CMake and Conan package manager.

Any good CMake integration besides https://github.com/modern-cmake/cppfront?

This issue is specific to glibc. Neither musl nor uclibc suffers from it.

It seems that all versions of glibc are affected.