kornholi

Don't need to be a superpower: https://spire.com/aviation/.

Although GPON is shared, it is not half duplex! I'm not exactly sure why the asymmetrical version won out, perhaps due to cheaper optics back in the day?

Latest iterations (NG-PON2 and XGS-PON) are 10G symmetrical, and XGS-PON is now cheap enough that GPON doesn't make much sense. AT&T Fiber in the US has been deploying it for the last few years.

This was posted recently: https://tonsky.me/blog/font-size/

Yeah, ML libraries are a huge offender. The Torch 1.8.1 manylinux wheel is 1.6G unpacked, with 1.1G going to CUDA support.

Yes, the different bands are not collected at the same time across the whole scene, so you get ghosting with moving objects. The SkySat sensor [1] is split in two halves: panchromatic and RGBN (where N is near-infrared). It takes lots of captures as the satellite travels that are later aligned and combined into one version.

[1] https://directory.eoportal.org/documents/163813/5615117/SkyS...

Higher res imagery from Planet: https://twitter.com/planetlabs/status/1291010972983992320

> Ok, but that decision would have to be made by the project maintainer, in this case Google, not the person using Bazel to compile protobuf.

No, that's up to the user. If you include protobuf in your Bazel workspace and have a toolchain configured, protobuf will be built with that toolchain (this is also how you would cross-compile). Bazel workspaces are still a little rough around the edges and interactions between them can be very confusing, as Google doesn't need them internally (everything is vendored as part of the same tree).

Under the hood there's a default auto-configured toolchain that finds whatever is installed locally in the system. Since it has no way of knowing what files an arbitrary "cc" might depend on, you lose hermeticity by using it.

Of course, the whole model falls apart if you want to depend on things outside of Bazel's control. However in practice I've found that writing Bazel build files for third-party dependencies isn't as hard as it seems, and provides tons of benefits as parent mentioned.

For example, last week I was tracking down memory corruption in an external dependency. With a simple `bazel run --config asan -c dbg //foo`, I had foo and all of its transitive dependencies re-compiled and running under AddressSanitizer within minutes. How long would that take with other build systems? Probably a solid week.

https://github.com/bazelbuild/bazel/issues/4558

I wish Bazel was more explicit about things leaking in from outside the workspace, but you can always vendor the toolchain to be more hermetic. For example see https://github.com/grailbio/bazel-toolchain which sets up LLVM and Clang for you.

From Krebs tweets:

The NSA's Neuberger said this wasn't the first vulnerability the agency has reported to Microsoft, but it was the first one for which they accepted credit/attribution when MS asked.

Sources say this disclosure from NSA is planned to be the first of many as part of a new initiative at NSA dubbed "Turn a New Leaf," aimed at making more of the agency's vulnerability research available to major software vendors and ultimately to the public.

That's not exactly true, for example see https://github.com/grailbio/bazel-toolchain

BGRA is a "weird" convention in the graphics world that goes back to at least OS/2 bitmaps, when there was no wrong answer, and has stuck since then. Since early GPUs targeted Windows (where BGRA is the native format for GDI/D2D), it makes sense that it made it this far :)

Yeah, I've used GCE's console many times with SysRq to debug frozen instances. Surprised that AWS doesn't have one.