Ashley Mannix

It looks like the case where `rtnetlink` does logging is the sort of place I'd say is reasonable to log in a library. It looks like a sort of long-running...

That looks like it could work 👍 If `getrandom` won’t compile for the wasm target without the RUSTFLAGS (I haven’t tried it yet) then we might be able to cfg...

I think it was a bit of a lazy mistake on my part for us to rely so directly on `getrandom` to support WASM, so I'm keen to disentangle `uuid`...

On WASM I think we can make that feature a no-op and continue to use our vendored code instead. It's mostly useful on Windows where the system crypto APIs are...

I'm working through this now :+1: I think the scenarios we're still likely to break are those using `getrandom` on `wasm32-unknown-unknown` that are actually setting a source for `getrandom`. If...

`uuid` is a widely used public dependency so bumping our major version and forking the `Uuid` type would be a much worse state of affairs for everyone. Users in other...

@mitsuhiko The piece that’s missing here is a stable interface to configure randomness on platforms that don’t have an obvious source. That seems like something we could all solve in...

For this release and `getrandom` `0.3`, we're going to kick the can down the road. If you're using `getrandom` in a no-std environment, you can update your version of it...

@ChrisDenton, this actually is supported via [a type called `Builder`](https://docs.rs/uuid/latest/uuid/struct.Builder.html#method.from_random_bytes). In hindsight, I think we would’ve been better off not having any high-level constuctors on the `Uuid` type itself, and...

@Andrepuel This is basically the problem, specifically that all this functionality lives on the `Uuid` type itself. We could still maintain a single `Uuid` type if we had free-functions for...