Yeah... I mean they should have just copied whatever video conferencing platforms do because they all work fine behind corporate proxies and they also don't suffer from this "increasing delay" problem.
I haven't actually looked into what they do but presumably it's something like webrtc with a fallback to HLS with closed loop feedback about the delay.
Though in fairness it doesn't sound like "watching an AI agent" is the most critical thing and mjpeg is surprisingly decent.
One mistake they did unfortunately ship though is bind patterns that look like variable names.
widely acclaimed new TV show that became a monster hit earlier this year.
7.3 on IMDB (not great for a TV show).
Unfortunately there are techniques that work with black and white printers too. I don't know if any have actually been implemented though.
do people really use Lisp family for AI dev tho?
Not since the 70s. They almost all use Python.
FP has absolutely nothing to do with modern AI.
You only need to check half of the string, so I think a technically optimal solution would have some take_while and maybe char_indices in there...
LLMs don't usually make trivial language mistakes like supposively.
I think this is just a really inexperienced or unskilled developer. Or possibly a very dedicated troll.
The biggest problems with gRPC are:
Plain HTTP can be type safe. Just publish JSON schema or Typespec files or even use Protobuf.
Yeah depends on what you're using it for. CSV is terrible in many many ways but it is widely supported and much less complex.
I would guess if you're considering Parquet then your use case is probably one where you should use it.
JSON is another option, but I would only use it if you can guarantee that you'll never have more than like 100MB of data. Large JSON files are extremely painful.
Would be cool to have more people on Linux finding and fixing these little details.
Unlikely to happen. This is very complicated low level stuff that's often completely undocumented. Often the hardware is buggy but it works with Windows/Mac because that's what it's been tested with, so you're not even implementing a spec, you're implementing Windows' implementation.
Also the few people that have the knowledge to do this a) don't want to spend a ton of money buying every model of monitor or whatever for testing, and b) don't want to spend all their time doing boring difficult debugging.
I actually speak from experience here. I wrote a semi-popular FOSS program for a type of peripheral. Actually it only supports devices from a single company, but... I have one now. It cost about £200. The other models are more expensive and I'm not going to spend like £3k buying all the other models so I can test it properly. The protocol is reverse engineered too so.. yeah I'll probably break it for other people, sorry.
This sort of thing really only works commercially IMO. It's too expensive, boring and time consuming for the scratch-an-itch developers.
It doesn't sound like it's difficult, just extra work that they don't want to do.
For example they might want to use native USB instead of libusb which is LGPL. I've done that in the past because libusb was lacking some features. It means you have to implement your USB code for each platform and doing that work for Linux probably isn't worth it, even if it isn't difficult.
FOSS is the only answer. Fuck capitalism. Fuck paid software.
Grow up. FOSS is great but it obviously isn't the only answer.
I think this could have been about 1/4 the length. Fairly basic stuff by modern standards and you don't need so many words. It is all correct at least, as far as I could see!