ejona86

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."

"Resident keys" is the solution, not the issue.

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.

1. https://www.betaarchive.com/forum/viewtopic.php?t=29115 2. https://groups.google.com/g/s100computers/c/Q8BUj8xHp5E/ (my post)

Size-optimized, RAM-only mods. Sounds interesting...

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.

disclaimer: I'm part of the gRPC team.

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.

gRPC actually still has to calculate the length of a message before transferring it.

And using HTTP/2 directly allows using HTTP/2-based load balancers and reverse proxies, which is a huge bonus.

When people might be comparing it to REST with JSON, it is fast.

gRPC can be used with flatbuffers and similar. The experience has been targeting protobufs, but at its core it just expects a serialized message. Other formats can be made to work with relatively low effort. So if protobuf is the issue, try swapping to your favorite marshaller.

Immutability is still there. You get to choose whether you want it or not.

For when you actually want a nullable field, I think the idea is that it is easy to have a wrapper message (just like boxing in languages). Such wrappers could even be made standard and provided by protobuf.

The Java examples are in the examples folder: https://github.com/grpc/grpc-java/tree/master/examples/src/m...

The examples folder references a tutorial at https://github.com/grpc/grpc-common/blob/master/java/javatut...

It varies based on language: some languages use async callbacks, some use futures/promises, some block and require threads, and some support multiple forms. The intent is that programmers in that language would handle concurrency however they would normally handle concurrency.