Ah yeah the banners are the problem, not the fact that almost every website out there wants to know every detail of my entire life...

> almost every website

When https://european-union.europa.eu/index_en has a cookie banner, it's entirely fair to blame the EU.

Until quite recently even https://gdpr.eu/ had a cookie banner. They finally got around to fixing that irony.

Actually yes the banners bring up cookie rage. When in cookie rage I'll click anything to make that banner go away. And then repeat the next visit. The banners make me not care. Give me a global in browser setting for that.

If you look other answers here you find a solution.

I don't want those banners. I don't want extensions or artificial solutions to a manufactured problem. I want to set up my preference in my browser, once, and have it respected by all sites i visit. I'm not sure why my comment was downvoted for stating a personal preference. For me, those banners do the opposite of what they were meant to.

> This is a strength not a weakness

Massive cope, there's no excuse for the lack of decent infrastructure. I mean, the C++ committee for years said explicitly that they don't care about infrastructure and build systems, so it's not really surprising.

The reality is that for any moderately complex C++ application, actually compiling C++ code is only a small part of what the build system does.

Well yeah

We have autoconf/automake checking if you're on a big endian PDP8 or if your compiler has support for cutting edge features like "bool"

> minor one time hassle

I dont know if you're jokingor just naïve, but cmake and the like are massive time sinks if you want anything beyond "here's a few source files, make me an application"

I'm unsure a bout the profiles. If they add restrictions and need to be enabled as a compiler flag, no legacy project I'll use them since they'd probably get like 4 errors and say "oh this options breaks my code, but the code has been running for years so its fine".

Neither will those projects use Safe C++

I feel like the entire pthread_cancel and cancellation point feature is only really useful when your application is exiting and resource management doesn't matter anymore. If you want to use it on a long running process, the thread that gets canceled must effectively be completely free of any resource allocation....

Unless of course you're making use of shared memory between processes, then you could still leak even when the entire process is shut down.

Do you mean because of the newspaper called _Die Zeit_?

I think it still is in a "well technically its possible" state. And I fear it'll remain that way for a bit longer.

A while ago I made a small example to test how it would work in an actual project and that uses cmake (https://codeberg.org/JulianGmp/cpp-modules-cmake-example). And while it works™, you can't use any compiler provided modules or header modules. Which means that 1) so you'll need includes for anything from the standard library, no import std 2) you'll also need includes for any third party library you want to use

When I started a new project recently I was considering going with modules, but in the end I chose against it because I dont want to mix modules and includes in one project.

In Germany there is article 10 of the Grundgesetz. While it does allow exceptions (like through a warrant), I wouldn't be surprised that if this law was passed that our constitutional court would deny it based on article 10 (any maybe article 1, that one's important)

I deploy my dotfiles somewhat regularly. At my day job I almost exclusively work on virtual machines, with sometimes different distros. Being able to install my usual setup (fish for the shell, helix as the editor, and a bunch of tools like eza and bat) in a few commands just saves me time.

Now to be fair, since I use rotz for this, I also install extra packages with it. So its not purely dotfiles.

This looks nice Maybe I can finally replace that sshtry shell function which I've been using for a few years