libVLC the library is LGPL licensed, VLC the application is GPL licensed. This plugin was of course just using libVLC so it being GPL was not the issue. As you said several other libraries unity uses are also LGPL licensed.

Thank you for the explanation! If I knew that, I had forgotten.

it is worth pointing out that tink has binding for a bunch languages (C++, objective-c, rust, python, go and java) and has support for a bunch key management systems (GCP, AWS and Hashicorp)

The biggest difference for you is probably that WebGPU has compute shaders and WebGL does not, they are pretty nice if you want to implement more complex algorithms.

That's true. But current shaders are very simple. The big issue I have with WebGPU is that it's still not supported by all browser (see Safari) while WebGL is nowadays everywhere.

I work on a MacBook and I need to make sure that at least Safari (soooo many issues/ bugs/ specific behaviours it drives my crazy) works fine

I don't have a mac, but my understanding is that Safari Technology Preview [0] has WebGPU support (might need a change a setting too).

[0]: https://developer.apple.com/safari/technology-preview/

I don't know of any great write-ups unfortunately, but the rANS you're looking for is range asymmetric numeral systems.

There are lots of materials about ANS, e.g. gathered here: https://encode.su/threads/2078-List-of-Asymmetric-Numeral-Sy...

Both versions are quantized and should use the same amount of RAM, the difference with QAT is the quantization happens during training time and it should result in slightly better (closer to the bf16 weights) output

It looks like they mean that the curriculum is open source. Hopefully we'll eventually get lecture videos on MIT OCW.

The WiFi Alliance has a habit of always have a marketing name and a different name in the spec, you'll a lot more references to it in places like WPA supplicant if you search for Neighbor Awareness Networking (NAN). Also here is the link to the spec https://www.wi-fi.org/system/files/Wi-Fi%20Aware%20Specifica...

>The WiFi Alliance has a habit of always have a marketing name and a different name in the spec

What, the same people that named a consumer facing product 802.11g?

That would be the IEEE, and I don't think the marketing people in the Wi-Fi Alliance participate at that level.

They didn’t name it that, IEEE did.

I tried a couple videos in both this site and Kagi's summarizer, both were decent but each time Kagi did better.

Whoa, I've been using Kagi for two years and didn't realize the summarizer could do videos!

It only works when there’s a transcript. It’s not “watching” the video. That said, it works very well most of the time for me.

The docs seem to suggest that docker is fully supported. I wonder if that note on the github repo about prod use of the docker image is out of date.

https://openwisp.io/docs/stable/docker/index.html

It is almost never I good idea to assert in a library, unless the error is truly unrecoverable. I think returning an error code\throwing an exception would be very reasonable and a much better API than failing silently though.

> almost never I good idea to assert in a library, unless the error is truly unrecoverable

Like getting an input that is too long? :)

I think a library asserting that the preconditions of its arguments are true is fine.

An exception is fine if the language has them. I don't think "assert" was meant super literally and exactly the way C does it.

An error code is risky.

Honestly, I would assert. Returning an error code just gives users another thing to ignore, and incorrectly use the return value (if implemented like C, where you usually get a single internet back, treating the error code as a hash would be even worse!)

Apps crashing with assets is awfully, but at least it screams at your when you failed to read the docs, target than incorrectly storing users data for the rest of time.