Location: Brno, Czechia
  Remote: Yes, or Hybrid
  Willing to relocate: No
  Technologies: Embedded C, C++, Python, anything Linux
  Résumé/CV: https://jmnl.xyz/misc/CV_Johan_Manuel.pdf
  Email: johan29 dot manuel at gmail.com
  GitHub: https://github.com/29jm
  LinkedIn: https://www.linkedin.com/in/johan-manuel-7ba045171/

I'm an Embedded Software Engineer, with two years of experience in the aerospace sector, and looking for a new opportunity either in the embedded world, or working with C++. I have an Engineering degree, and a Bachelors in Mathematics. I'm very curious, and able get up to speed with existing systems very quickly.

The first example is from an actual game, Larsen-Korchnoi, where White does manage to put the Knight on d5. The article includes that part of the game, it's a pretty funky manoeuvre.

I'm in Japan now, and from my experience, that's incorrect. Google pay works just fine everywhere for regular payments. But you won't be able to use your phone to replace anything IC card related (like contactless payment cards for transportation).

For what it's worth I've been using libinput-gestures in combination with xdotool for exactly this purpose, it's been working great for a while.

It is, it's a checkbox at the bottom left of the "Customize" panel.

I should have explained it better, I was asking about associating actions to the "compact" titlebar (or what's called). I guess I need to wait for a proper GTK3 "header bar", if it's planned at all...

Anyway thanks.

Edit: in Chrome/Chromium works as I expected, I think I should file a bug then.

Could you expand on what's dangerous in using a curve with a non-unit cofactor? I haven't heard of this as an attack vector before.

As a sort of hand-wavy message board explanation: you design a protocol using public-key crypto with the assumption that any given public key pairs with a single private key and with no other public or private keys.

But that's not true: for both Curve25519 and in the Ed25519 signature scheme, which were designed with curves for which point validation is supposedly unnecessary and thus not performed, there are for a given curve point other points --- not valid ones, but ones for which the math will work --- that are equivalent.

For the kinds of things most developers use crypto primitives for, and most of the things everyone was using them for in 2009, these distinctions are --- I'll argue --- not that important. If your transport protocol handshake blows up because of cofactors, the problem probably isn't that you didn't check curve points; it's that you designed a bad key exchange.

But since I don't do cryptocurrency work, like, at all, it's easy to forget that the mainstream of what people do with signature schemes is a lot broader than it was before. I'll try to think of a way to word that and get it into the document.