there's bad actors that use bots to sign up to websites using bogus data.

Wait! Are you saying that you process new registration attempts without any rate limit, captcha, etc? Because the moment to filter out (or limit) bad actors is before they submit an email address, not through it.

Yeah, good luck with that. Captchas are basically useless in today’s world, so are IP rate limits for anything just a little sophisticated. Of course it helps, but if you think this solves all problems, you live in a dream world.

The plus sign is a pet peeve of mine, too. But I stopped keeping a list of bad sites when their number has become double digit!

> you absolutely can navigate Windows + Office keyboard only

Unfortunately in Excel many operations can be done only with the function keys (e.g. F2, Shift-F8). I'd argue that leaving the center of the keyboard to press the function keys is not easier or quicker than reaching for the mouse.

Writing to array[n] and not incrementing n means that the value just written is outside the "useful" range (from 0 to n-1) and will not be considered (it will be overwritten the next iteration).

Nitpicking the C variant:

> #define BLQS_CMP(a, b) ((a) < (b))

A function that returns true when one operand is Less Than the other, should be called BLQS_LT. The CMP abbreviation is idiomatic for a function that returns -1,0, or 1.

In modern CPUs a mispredicted branch is much more expensive than a memory write.

The unsaid assumption is that the array is filled with random values between 0 and 1000, so the "if" condition has a 50% of chances to be true. The branch is mispredicted 50% of times.

Of course this trick won't work when the statement protected by "if" is a more complex and costly action, or one that can't be undone (in the example, note that when the counter is not incremented, the value written to memory will be overwritten in the next cycle, so it's "undone" in a certain way).

> In modern CPUs a mispredicted branch is much more expensive than a memory write.

Mostly because of caching. The writes either go to the same address as a previous one or move only a small increment, so most writes are likely going to hit L1 cache. If it wrote to a random memory location after every iteration the cost of a misprediction would probably disappear in the noise.

> doesn't allow windows to stay on top.

Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere!

I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more.

I think the sensitive default should be to block it, and allowing it should be behind some user's conscious action. Yes, it adds some friction to some workflows and it takes a bit to get accustomed to. But it doesn't deserve the label "security paranoia".

Are you aware that if software misuses the capabilities its given by the system you can choose to stop using that software?

You can't do anything about a compromised app or JS from a random website. I always find it weird when people attack Wayland's security model, more isolation is obviously a great idea, as demonstrated by supply chain attacks in the recent decade.

It's that Wayland's design, implementation, their attitude, and everything else about it is terrible. It could have been implemented without compromising on features or convenience by explicitly specifying minimalistic controlled side channels in their security model from the start, instead of shifting it onto ad-hoc implementations. And of course the windowing system is already too large of an attack surface. Many people are thinking about going full Qubes due to the current realities, while the others live in denial and call even window isolation "paranoia". Fascinating.

Turn off the web browser feature that allows JS in an advertisement in a background tab to globally grab your input.

Sure, browsers had three decades of adversarial testing to evolve into sandboxes, but what are you going to do in case of something like the xz backdoor in a desktop application? It's no longer a hypothetical in 2020s.

You're going to be hacked. There's no useful middle ground between letting programs modify how your computer works and not letting programs modify how your computer works.

Of course there is: fine-grained access control and attack surface reduction. It's not all or nothing.

Do you want to see the dancing bunnies? [Yes] [No]

Apple apologists keep making the excuse that Apple has to provide no side loading because if there was any single way to do it, all scammers would be making all grandmas do that. They're correct.

That's a complete strawman though, I'm not talking about any of that.

True. But it's often all or nothing: you can't surf the web without the ads.

> unprivileged X11 programs that use the Scroll Lock light as an indicator

I didn't know such apps existed! What do they use it for?

One use case is a new message indicator. Unlike icons on the desktop, keyboard lights are visible even when a full-screen application is running, or when we're to the side of or across the room from the computer, or when the display is asleep. I depend on this for my daily communications.

Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences.

Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.

Which programs can be configured in this way? Something custom you wrote?

UTF-8 notoriously doesn't prevent ambiguous encoding by construction, but only prohibiting it in the specs. It's known as overlong encoding. It's up to the encoder/decoder to prevent, correct, or reject it. This burden on the software is exactly what TFA tries to eliminate with the bijou64 format (unfortunately replacing it with another burden: overflow check).

Nice. But you've just invented Zig!

C with Zig's comptime is compelling though. Zig doesnt allow you to access all the features your C compiler does, and puts you in the LLVM ecosystem. I've been working on something similar; extending C with both Zig/C++ inspired reflection and linear types, with a compiler that compiles to a subset of C to allow you to leverage GCC and all its extenstions.