If you're already a password manager user, then it sounds like your gripe is "my password manager doesn't support passkeys." That seems either a short-term issue that would be resolved in time, or you need to find a more powerful manager. It seems the browsers allow passkey providers to be pluggable already, as several third-party vaults support passkeys.
So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."
I worry that people who think device attestation and not being able to backup passkey data being good things are too close to the driver's seat when it comes to the direction of passkeys. I see a possible future where free and open source passkey implementations won't be usable because relying parties will want to see device attestation.
I would love to use a hardware device in lieu of a password manager. I just need a tolerable backup/restore scenario.
Apple is playing consumer advocate here by refusing to support device attestation keys on consumer hardware. With the large market share of the iPhone that's a key wedge that should keep things relatively open on the consumer side, presuming Apple sticks to their ideals here. The biggest advocates for device attestation are doing so for corporate "enterprise environments" and that will likely be a dividing line that corporate networks may require device attestation and consumer devices and applications won't/can't.
With U2F it was hard to track which sites used the key. If I wanted to move to a different physical key, what sites should I update to not need to worry about arbitrary account recovery processes? This is one of many reasons I hate SMS verification and why I didn't use U2F beyond a few high-value sites. But with resident keys there is a list of sites I can walk through to migrate or to keep "in sync" with a spare key. Just like with passwords and OTP. Needing to sync them is an existing problem with passwords and OTP; I'd consider it solved, but even if you don't, I don't see why that's suddenly "consumer-unfriendly."
For the service lock-in concern, the resident aspect makes it easier to migrate. Yes, there might be a way to make it easier still, but when the alternative is a physical key it seems a strange demand. I'm the sort of user that'd use a physical key, though, even if the number of available resident key slots is low at the moment.
(If a site doesn't support more than one passkey, then I wouldn't use passkeys on the site.)
> ... CP/M for the in-development Vector 4. Switching would potentially mean redesigning the next line of machines.
The Vector 4 and 4-S did receive MS-DOS 2.0 support at some point. I have a working Vector 4 with MS-DOS, and this floppy[1] looks to be for the 4-S. Although larger changes would have been needed to become more "IBM compatible" (of which 4-S was a step).
> They rejected her plan to develop a new machine that would focus on networking and telecommunications, which she saw as the future of computing.
Vector was one of the first shipping a product using twisted-pair networking[2]. It seems that didn't make much of a splash; very little information is available. It was a S-100 board, which maybe limited market appeal by that time.
Not just you. It can give no results and partial results, which is sometimes fixed on a re-query.
But it also is just poor for code. I think it wants to find full words, so searching for substrings generally results in too few matches. That's made worse by its special character handling in word splitting and query parsing which makes some text impossible to find.
It is true that gRPC tends to implicitly imply Protocol Buffers. It's the only format that is worked on directly by the gRPC team.
However, C#/C++ Bond, C++ FlatBuffers, and Java Avro have some level of code generation support for gRPC. I'm not very familiar with Microsoft's Bond, but it appears to have generics for both the service and structs.
The thing that went unnoticed with that issue is that grpc-go didn't have an option to manually increase the window size. Both the Java and C implementations had the option much earlier; I see a commit adding it in Java in March 2015.
At least by August 2015 I was working on automatic window size tuning, which I've not seen in another HTTP/2 implementation to date. July 2016 it was implemented in Java, but remains disabled due to interoperability concerns that we need to spend time addressing. C now implements something similar and it may be enabled in 1.3.
For flow control to work promptly the window size should be only as large as necessary, so there is cause for keeping it small. Since the lower value is appropriate for many networks, it isn't completely outrageous.
I think the biggest failure on gRPC's part here is not having a notice in a widely-read part of documentation informing users to be aware of the limitation. That's easier said than done, but that doesn't negate its importance.
HTTP/2 has the concept of streams. Each stream is independent, but within a stream data and headers are ordered. Each HTTP request would be on a new stream.
gRPC maps calls to streams so calls can proceed at different rates, but you still receive the information on a particular call in order. So conceptually each call is completely separate, but we can use a single HTTP/2 connection for all the calls to a particular destination.
HTTP/2 is quite featureful and provides most of the advanced needs that gRPC has; HTTP/2 is pretty similar to what we would make ourselves if gRPC used TCP directly.
Using HTTP/2 though also allows fitting into the wider web ecosystem of proxies, reverse proxies, load balancers/TLS terminators, and developer familiarity.
So I see your concern as more "I need to find a password/passkey manager that fits my desires" and less "passkeys require being locked into a platform."