> we're going to ship symbols after this, no reason to over-optimize

You might want to look into debuginfod.

I don't have this particular issue, but instead the text size is hilariously huge. The CSS contains this fragment:

  @media (min-resolution: 1.5dppx) {
   :root {
    font-size: 2.4rem;
   }
  }

My 27 inch 4k monitor comes in at a device pixel ratio of ~1.58, triggering this (presumably) phone-targeted style.

Looking uncrossed at the images in the article on my phone, I can easily achieve the effect uninterrupted between fully stretched arms and about half that.

Sure, but that's the limit. I didn't say it was impossible, just that crossing your eyes basically works all the way up to your nose.

I think many of these rules are good, but that there's a too strong focus on ensuring that shell snippets are copy-pasteable without inspection. This comes at the detriment of other considerations, and I think some of the advice goes too far.

Especially so when it comes to the different package names on different Debian versions: what originally was a oneliner is now fifteen lines long with six different branches. What should the reader do if the copy-pasted code fails? How do they know which part failed? What is an "/etc/os-release"? Yes, the happy path becomes simpler, but the reader will struggle to recover from any errors.

This is how we introduced and work with clang-tidy. We enabled everything we eventually want to have, then individually disabled currently failing checks. Every once in a while, someone fixes an item and removes it from the exclusion list. The list is currently at about half the length we started out with.

RCU, despite the name, is indeed a reclamation algorithm, but not a general one. I.e. you would use RCU (or some other deferred reclamation algorithm like hazard pointers) for specific data structures when you do not have generalized garbage collection.

A generalized RCU is just a tracing GC.

The part where the article limits itself to general techniques eludes me.

The linked code is including math.h (transitively), but using the std-namespaced functions provided by cmath. That seems like a bug, but presumably works on at least one platform.

The entire proof is trivial.

The same is true of Rust. I have no idea why the author decided to print addresses only for C++ and not for Rust.

  // (1)
  struct Person {
      name: String,
      age: u8,
  }
  
  fn show(person: Person) {
      println!("Person record is at address  {:p}", &person);
      println!("{} is {} years old", person.name, person.age);
  }
  
  fn main() {
      let p = Person { name: "Dave".to_string(), age: 42 }; // (2)
      println!("Person record is at address  {:p}", &p);
      show(p); // (3)
  }

Its output is:

  Person record is at address  0x7ffcfb2b4e40
  Person record is at address  0x7ffcfb2b4ec0
  Dave is 42 years old

Just make sure that the pipeline is fast, or allow an override, and there is no issue.

Requiring manual intervention to handle a blocked pipeline over a non-issue defeats the whole purpose of continuous integration, not to mention that you are suggesting adding twice the complexity as an alternative to not adding any complexity at all.

And should I stress again that there is absolutely zero positive tradeoffs?

Who’s blocking any pipelines here? If you’re running a PR process at all, these changes are being pushed to a feature branch and reviewed before getting merged to master. If you have a feature branch that’s failing CI, that doesn’t block me from merging my feature branch once my PR is approved.

As I specifically said, the CI should fail on the feature branch. If you’re only running CI on master, you’re going to run into the exact same problem if your unit tests fail. The way to avoid that problem is to run the unit tests on your feature branch, and if you’re doing that you might as well run the linters too.

> And should I stress again that there is absolutely zero positive tradeoffs?

Just because you don't value or acknowledge them doesn't mean they don't exist.