tylerl

Sweet. Glad to hear someone's working on it who knows what they're doing. :-P

I spent a fair amount of time at work five or six years ago trying to figure out how to make supply chain security actually possible in the general case with standard open-source tools. And I can tell you that the fact that Docker builds are fundamentally non-deterministic caused me no end of frustration and difficulty.

This was about the time that Bazel was being open-sourced, and Matt's rules_docker extension was already in there. A solution existed, so to speak, but it would have been nutty to assume that the average project would switch from the straightforward-looking Dockerfile format to using Bazel and BUILD files to construct docker containers. And Docker Inc wasn't going to play along; they were riding a high valuation that depended on them being the final word about containerization, so vocally pretending the problem didn't exist was their safest way forward.

At one point I put together a process and POC for porting the concept of reproducible builds to docker in a user-friendly format -- essentially you'd define a spec that listed your dependencies with no more specificity than you needed. Then tooling would dep-solve that spec and freeze it into a fully-reproducible manifest that encoded all the timestamps, package versions, and other bits that would otherwise have been determined at build time. Then the _actual_ build process left nothing to chance: grab the identified sources and build and assemble in a hermetic environment. You'd attach the manifest to the container, and it gave you a precise bill of materials in a format that you could confidently use for identifying vulnerabilities. Since the builds were fully hermetic, a given manifest would only ever produce one set of bits, which could be reproduced in an automated fashion, allowing you to spot supply chain inconsistencies.

In my tooling, I leaned heavily on package providers like Debian as "owning" the upstream software dependency graph, since this was a problem they'd already solved, and Debian in particular was already serious about reproducibility in their packages.

In the end, it didn't go anywhere. There were a LOT of hacks to make it work since the existing software wasn't designed to allow this kind of integration. For example, the dependency resolution step required splicing in a lot of internal code from package managers, and and the docker container format was (and probably still is) a mess that didn't allow the end products to be properly identified as reproducible without breaking other things.

Plus, this is a problem that only people trying to do security at scale even care about. We needed a sea-change of industry thought around verifiability before my solution would seem at all valuable to people outside a few huge tech companies.

Does anyone know of a more generalized framework for doing this kind of thing? I'd been meaning to write a framework kind of like this for some time, but never got around to it, and was hoping someone else would. This one unfortunately doesn't really check the important boxes, but it's a good start. I was hoping more for:

* Target language agnostic (this one seems to get mostly there) -- the nodes communicate data/logic flow, you then serialize/deserialize accordingly. * Focus on data flow, not just execution -- IO from nodes, visual indicators of data types (colors or something) * Capable of visually encapsulating complexity -- define flows within flows * Ideally embeddable in web apps (e.g a browser/electron frontend or something)

These are pretty popular to embed in complex "design" oriented applications, especially ones that involve crafting procedures by non-programmers (e.g. artists, data scientists, etc). Examples where this is implemented that come to mind include Blender, Unity, and Unreal.

A core part of the fundamental design of each one of the successful implementations is that they allow efficient code to be crafted by people who don't think they understand code. Making it visual helps engage the brains of certain kinds of people. The "code as text" paradigm is spatially efficient, but it's like a brick wall for some people.

The communication doesn't give that impression; instead it says that the paper makes claims that ignore significant and credible challenges to those claims. Dean said that these factors would need to be addressed, not agreed with.

Publishing a transparently one-sided paper in Google's name would be a problem, not because of the side it picks, but because it suggests the researchers are too ideologically motivated to see the see the problem clearly.

Ironically, it indicates systemic bias on the part of the researchers who are explicitly trying to eliminate systemic bias. That's just a bit too relevant to ignore.

Apple's new chip "shreds" a 2016-era GPU?

Wow.

IIRC, all GCPs IPv6 support is complicated by the fact that they adopted IPv6 from the get-go for internal routing, and layer the user-visible virtual address space on top of it, embedding the user-visible addresses inside the invisible "actual" VM addresses, and that layering strategy allows for something super amazing or fast or something. Something like that.

So then you ask the engineers, "when are you going to adopt IPv6?" And they're like: "What do you mean? We've never NOT used IPv6 for everything important."

On the one had my GCP server's "native" IP address that the OS sees is always an IPv4 address. On the other hand, it's always in the 10.x.x.x/8 range. Everything else is NAT and LB.

My brother is an ER doc in a well-known facility, and he says this covid thing is freaking the everliving shit out of the front-line medical profession. This virus is just not behaving like a normal disease should.

The doctors who have been around long enough say that the feeling in the hospitals is just like the early days of AIDS. All you knew is that patients were dying from a disease that doesn't follow any of the normal rules, and nobody's sure why, and all the healthcare workers are nervous AF that they're going to get it too, but everyone is trying to be brave because the patients and family are scared out of their minds, and calm needs to start somewhere, right?

Thing is, Google requires an absolutely stupid amount of computing resources for running their core business. YouTube transcoding is a great example and a big one for sure, but I bet they have even bigger ones in there somewhere. I have no real data to base this on (and I'm sure nobody does), but I'd bet 5:1 odds that if Google were an AWS customer, they'd be bigger than all the others combined.

So in that case, optimizing for a single customer makes perfect sense if it's the right customer.

Eehm... Arbitrage is buying on one market to immediately sell on another market at a profit. Which is exactly what these folks were doing.

Except that the other market administratively blocked them from selling. Then the first market wouldn't reverse the purchase, leaving the would-be arbitrageurs holding the bag.

The study is fundamentally flawed and the article (headline claim in particular) is nonsensical.

The study is flawed in that it lacks a control group and is missing information about relevance. You say people don't see the road when you tell them to look at a screen. Wow, color me shocked. But if you're going to demand change, you need to be able to put that fact into context. Like, what are the measurements when asked to perform the same action in the built-in head unit? And is this a contrived example, or does it represent typical use.

The headline has a similar problem. We already know that driver reaction time is effectively infinitely high for distracted driving. If the driver doesn't see the obstacle then they aren't just slow to react, they don't react to it at all... because why would they react to something that they don't realize exists? So you're comparing that fact to delays caused my chemical impairment? How? A driver with phone integration will have no impairment at all if he's not looking at the display at precisely the time of the incident, but intoxication has a persistent effect.

Really? That's certainly not something I generally hear. You can levy a lot of complaints against police systems, especially the a few of the more infamous departments. But that one seems like it's pushing a bit to make a specific connection.

Uhhh, right... nobody thought that it was.

Thing is, the copyright is owned by Oracle of all companies and and the legality is more than questionable enough to allow Oracle to sue for damages the second the code shows up in use by a big enough fish.

Oracle won't relicense the code (and lose out on a chance at another software copyright lawsuit), and it won't ever be safe to touch without an ironclad licensing story.

You can hope that Oracle folds and gets bought by someone decent. But hope won't take you that far.

Throw it away. Start over from scratch. The code may be great, but it's gone. It's a shame it ended up where it did. Take a moment if you need, but then move on. ZFS isn't going to happen.