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.
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.
As someone who actually DOES read the manual for everything, your objection about accomplishing nothing is BS. It's a bit of an upfront investment, but you long term efficiency is dramatically higher. You have time to post comments on HN, you have time to read the damn manual.
But as someone who also designs UX, I never design anything that requires instructions. There are plenty of good ways to make things self-explanatory. It's just harder.
However, command line UX is different. You can make the basics self explanatory, but you're so limited in your options that exposing the advanced stuff intuitively muddies everything else. So there's a trade-off you have to live with.
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.
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.
Magical indeed. Except that public opinion counts for nothing in copyright law; you have to fight it out in court. Luckily, Sun isn't the kind of company that would file questionable lawsuits against Linux users just to... wait.. wasn't Sun bought by another company?
Well, whoever owns the copyright now, you're probably reasonably safe unless they're a hyper-litigious corporation with deep pockets and an army of lawyers, who see lawsuits about software licensing as a potential source of income....
> ...disliked ZFS because they feel it was designed to be incompatible with Linux...
Ya... That may have just a bit to do with the fact that ZFS is released under a licence that was explicitly designed to be incompatible with Linux.
"Mozilla was selected partially because it is GPL incompatible. That was part of the design when they released OpenSolaris. ... the engineers who wrote Solaris ... had some biases about how it should be released, and you have to respect that."
I can see how that might suggest to Linux maintainers that they are not welcome to use this code. Maybe sorta.
The point is that just because you don't want most sites to use these features doesn't mean that no use exists. I just want to make sure I don't get nag notifications begging me to turn it on every time I visit a news site.
Notifications? I need those from my calendar app and chat app.
Badges? Messaging systems I use rarely but which are important.
Visibility? I want resource intensive apps to "sleep" when not in use.
USB? I want an Arduino web ide to be able to communicate with hardware.
Screen lock? I don't want the machine to go into sleep mode when I'm presenting a slide deck.
Key lock? I don't want the browser intercepting keystrokes in my word processor or SSH session.
Discord replaced ventrillo and teamspeak for gaming communities. For those you actually ran a "server". Whether or not the company started out calling these accounts "servers" initially, that customer base sure did. It was the terminology customers were used to. They neither knew nor cared what the technical aspects were of having a separate server; it just what you called that thing that the team used to communicate.