davidkhess

I think that's coming regardless. AI just might be the perfect storm to bring the timeline in considerably.

One way it works is if you think of cognitive debt as the "house". As in "the house always wins".

Should probably mention that Guido ended up on the team working on a pretty credible JIT effort. Though Microsoft subsequently threw a wrench in it with layoffs. Not sure the status now.

Xonsh is perfect for this: https://xon.sh

Last time I looked at SQRL, it had an unfixable man-in-the-middle problem.

Though, general acceptance of QR Codes does seem to have finally taken off.

Yes, these will be stored in cloud storage like iCloud Keychain. But I can go into my iCloud Keychain and delete individual passkeys - or I may have only one Apple device and then lose it. Or some malware clears out all of my iCloud Keychain.

Normal usage would require a reauthentication - i.e. FaceId or TouchId - to produce the passkey.

I think this is really great news and am glad to see FIDO move forward as I think it greatly increases account security.

One aspect of FIDO that could still be troublesome is account recovery in case of inadvertent loss of passkey. OOB recovery with SMS or email is considered too weak and the main recommended alternatives are to maintain multiple authenticators (i.e. multiple copies of your passkeys), re-run onboarding processes for new users or just abandon the account.

It's going to be interesting to see how those alternatives play out in real world situations.

Not that this validates the claim, but this was a pretty influential post by the author of Flask circa 2016:

https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asynci...

Ditto. I started out on Twisted back in the day and stayed with it for 6 years all they way up until they introduced deferreds combined with yield/generators (the same technique which is the heart of today's asyncio).

It was great at the time but ultimately tiresome. It introduced framework specific incantations all over the place and any framework using I/O had to be Twisted-aware in order to use it straight-forwardly. The exact same complaints I have today of asycnio.

I went to gevent 10 years ago and have never regretted it. If you have some reasonable knowledge of threading and synchronization then it is a really nice developer experience.

You are jumping to mistaken conclusions based on one review, the motivations of which you don't know.

I think cross-platform apps are commonly misapplied and really only make economic sense with the appropriate assumptions. Once a company has the necessary resources they should go native and go all in on platform conformity.

But for many folks, that's not a feasible place to start from.

I built the initial version of this app for a startup:

https://apps.apple.com/us/app/listeners-on-call/id1498666617...

It has a very good UX designer and I've developed multiple commercial Qt/QML mobile applications previously.

I think the economics make sense with the following assumptions:

* The startup doesn't have the resources to build for two platforms natively (yet).

* The developer(s) can get their hands dirty and "go native" on either platform when needed.

I find Qt/QML for cross-platform mobile applications to be a great solution. It uses the same basic architecture as Flutter – they both do not use native widgets and instead draw the entire UI on a blank graphics canvas. I think that approach preserves the most code between platforms and reduces the kinds of presentation hitches that HTML web view and hybrid native widget approaches can run into.

In relation to the particular problems of technical debt related to third party modules mentioned in this article, QML rides on top of Qt which is a 26 year old C++ cross-platform toolkit with a lot of mature technology in it. I.e. there is a lot more "batteries included".

There are still plenty of times you have to "go native" to integrate something Qt doesn't cover but it apparently isn't as often as with Flutter.

Not retired though - currently at Microsoft.

Not sure if it matches your use case or not, but I use sshfs with Sublime Text and it's just as good as local editing.

I would not underestimate the value of experience. And the older you get, the more of it you have a chance to acquire.

I think the mistake most people make is to deliberately slow down as you get older. Never slow down and you'll keep pulling ahead.

Here's an approach I've used before successfully. It's not perfect but it's better than nothing.

1. Create your own root Certificate Authority.

2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't be repeated between devices.

3. Add to your product support for ZeroConf/mDNS/DNS Service Discovery and advertise an https web server at myiotdevice-AABBCCDD.local.

4. Provide instructions to your users on how to download and install the certificate for your root CA (this only needs to be done once).

5. Print the name "myiotdevice-AABBCCDD.local" on the device and instruct users to type that in to a browser's address bar.

I'm doing this from memory so I may have missed an intricacy here or there (like DNS SD is a weird story on Windows 10) but this approach should basically work well enough.

EDIT - good commentary in replies about the dangers of the CA being compromised. Also, good mention of X.509 Name Constraints and how they can be used to mitigate that danger somewhat. More info here: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...

I'm curious, when you refer to Qt, do you mean the QWidget application approach or QML? QML is much more like Flutter (but is indeed somewhat arcane to learn how to work with).

My perspective is that Flutter is positioned dead on against Qt's QML. I develop mobile and desktop QML applications and this seems to be trying to be very competitive with it.

Qt also has a WebAssembly build for QML apps on the web but in my experience it has suffered from some of the same issues reported here about the Flutter WebAssembly runtime.

Edit: One key difference is Flutter seems to do everything with procedural code. QML is based on a declarative DSL plus Javascript.

I developed a different take on this issue recently. It's not that technology could destroy us - it's that the amount of complexity we are continually building with technology will eventually outstrip the resources and intellect of the human species to manage it.

Another way to put it: what if the Great Filter (https://en.wikipedia.org/wiki/Great_Filter) is really that biological life doesn't have the resources available or the capability to develop the intellect necessary to manage all the technology required for a species to go intergalactic?

What if the root cause is the ever increasing complexity that software is trying to manage? At all levels (legislature, management, bureaucrats, programming languages, developers, testers, users, subjects) we are creating more and more complex situations we ask software and the institutions that produce it to manage for us.

But as the complexity goes up and the number of these complex situations increases, are we reaching a point where we outstrip the amount of money, talent and experience our institutions would need to deliver solutions to successfully manage them?

With our resources and intelligence as a species being capped, it seems at some point this is inevitable.

Recounting my own experience w/ unpkg:

They had an issue where they were responding with 302s redirecting to malicious adware:

https://twitter.com/unpkg/status/852660203275276289

They promised a post-mortem which (to my knowledge) never happened:

https://twitter.com/unpkg/status/852666784792444928

I removed unpkg from my infrastructure and won't be using any of these services again. The minimal gains aren't worth the risk in my estimation.

How does this compare to StackPath? https://www.stackpath.com

This is impressive but I think it's interesting that Apple is seemingly jettisoning Auto Layout with the introduction of SwiftUI with Stacks and Alignments.

Having worked with a lot of different layout and alignment systems, Auto Layout seemed to me to be considerable overkill. I found it generally not worth all the brain power needed to understand it and more importantly debug it when it isn't doing what you want.

This submission was a misfire. Can a moderator please kill it?

So, here's what I'm really curious about. Anybody know why they didn't use OAuth 2.0? Some of the bits of this API smell somewhat like OAuth, but this seems simpler and is handled mostly in the frontend (via an iframe I assume) vs. the URL redirect dance of OAuth.

Is this what OAuth should look like in a more front-end centric web day and age?