That is the hid mode parent is mentionning.
With ykman you can configure the Yubikey to simulate being a USB keyboard (Human Interface Device) and then "type" a static password. The default setting is to type a Yubico specific OTP that can be checked by calling an API. The issue with the static password is that anybody getting near the yubikey with a device having a USB port can steal the password in seconds.
And any accidental button-press while in a chat-app or website will leak your password. I've seen many yubikey otp's accidentally pasted into irc, if you set it to password, you just posted that. I'd never recommend using that mode.
I used to play a lot of this with my grandmother and cousins when I was a child. Later I happened to work in the factory mentionned in the article, which was at the time rented as warehouse and office for an E-commerce company. There was a huge Dujardin logo painted on the outer wall, which was preserved when they repainted the building [0]
I had a similar problem with the Tecurs KB510 I got at work. The only way I found to type F1-F12 keys on Linux was to set up a hack with kbct [0] and the Super key... until I tried the configuration described in the gist you linked. Thanks a lot for that !
Putting in place an infrastructure to test this kind on changes on the 5-10 most popular browser would be, I think, very cheap for a company like Google. I can't help thinking these may be deliberate moves to eat the little market shares of Chrome concurrents.
I remember reading here on HN an article written by an ex-Mozilla insider relating the dissonance between the "friendly" Mozilla-Google employees exchanges and the year-long track record of very oddly recurrent "unfortunate mistakes" from Google degrading the Firefox compatibility.
Yes - they clearly don’t test the GCP console in Firefox since they “accidentally” break it on a regular basis, and there’s just no excuse for that happening at such a rich, well-staffed company.
> Putting in place an infrastructure to test this kind on changes on the 5-10 most popular browser would be, I think, very cheap for a company like Google.
The problem wasn't some web server, it's the Firefox backend services running on GCP.
Testing wouldn't have revealed anything because this didn't break with Firefox outright, it only broke when Firefox telemetry used it due to a complex series of circumstances.
Technical amendment: UTF-16 can represent the full range of Unicode scalar values with surrogate pairs. Code points includes the surrogates U+D800–U+DFFF, scalar values don’t. Like all other Unicode encodings, UTF-16 cannot represent surrogates.
That’s where the real problem lies: almost nothing that uses UTF-16 actually uses UTF-16, but rather potentially ill-formed UTF-16.
This isn't a consequence of using UTF-16 as such - Java, .NET etc could totally have an API around UTF-16 strings that handles surrogate pairs. The problem, rather, is that those languages introduced a 16-bit type that they called "character", even though it wasn't even a Unicode codepoint. And then used that type throughout all string APIs, including strings themselves (indexing etc).
In .NET land you're now supposed to use https://docs.microsoft.com/en-us/dotnet/api/system.text.rune instead. It transparently handles surrogate pairs, so the app needn't be aware of anything - and yet the internal encoding is still UTF-16.
Frankly if you go with the most popular extensions: Flask-SQLAlchemy, Flask-Login and Flask-Admin you will have more or less all the features of Django with a nicer API, better documentation and more flexibility
I've been using all of them, and no, not at all. Flask-admin is a far cry from the django admin. It's also buggy sometimes.
Flask-SQLalchemy is not well integrated at all. E.G: try to play with it in the shell, the session management is annoying as hell.
As of flak-login, it doesn't have a tenth of the
Also you forgot: csrf handling, i18n, xss, click hijacking, cache backends, and so on. That's again, more plugins you have to select.
And that's a lot to configure, learn doc, then upgrade when the times come, on top of that.
All of them will, obviously, not be compatible with SQLA 2 next year, because the projects are not a whole, so it's going to be even more fun on the months to come.
This is a good summary. Sometimes I too forget how much stuff Django provides out of the box for free. But now it is an old and boring tech, apparently. Oh well.
The technology most suited to improve one's resume will be the one most in demand on the job market, and therefore also the most difficult skill to hire for...
