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.

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....

I mean, what are the chances?

...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.

WHERE IS THIS TEAM?

Now they're all sheltering in place in their homes.

It's amazing how big a difference you can make in the world if you can just get started... a month ago.

Regardless of wire gauge, bundles of wire noticably reduce your heat dissipation ability and therefore reduce your safe current carrying capacity accordingly. That's why electrical code significantly de-rates the current capacity of circuits which run more than just a few conductors in a single conduit or through the same hole.

Probably just misunderstood; what you said is a mixed up jumble of bits of actual facts.

C.diff is something that you always have some of (you'll never be rid of it, nobody is), but it usually gets out-competed by other bacteria. But it's exceptionally hard to kill partly because it can form tough spores that go dormant. So if you take powerful antibiotics, there's a good chance that all that'll be left is the c.diff, which gets problematic when there's a lot of it. Fungus is similar in the sense that bacteria compete with it, so killing the bacteria leaves you vulnerable to fungus as well.

This is precisely why you're supposed eat probiotics during certain kinds of treatments. People talk about "healthy gut flora" or whatever like its a new age alternative medicine, but really you just need a ton of different kinds of benign bacteria filling the space so that no particular one strain of pathogen gets enough critical mass to have an effect.

Oh yes? A productivity bonanza you think? I'm in the Seattle area and my office has been shut down for at over a week now. It's not been as rosy as you think. Here's what it's actually like:

First, the company has always been extremely supportive. Many employees have been working from home exclusively for years and nearly all of us WFH from time to time at least. The processes and expectations are well established. Engineers have always been supplied with a laptop in addition to their workstation, so WFH has always been immediately possible for everyone. You get your pick of hardware, but all the systems and services and processes have been optimized to make it reasonable (not just possible) to get serious engineering work done with nothing but a Chromebook. I've seen many programmers working _at the office_ from a Chromebook because they liked the interface. But for most of us... it's not optimal.

Corp work has to be done on Corp-owned hardware. This is enforced by technical controls that can't readily be circumvented, so even if you have a great computer at home, you'll be working from your laptop. Many of us at the kitchen table. Unless, of course, you've gotten a corp-issued rig in your house... which can't have happened in the past couple of months because the computer hardware supply chain in China has been shut down for a long time. Think you'll just go buy a nice monitor from Best Buy and dock it with your laptop? You weren't the first to think that; computer monitors are sold out across the city (having 4 giant tech companies all go 100% WFH at the same time will do that).

At a team level, it's been a mess. Productivity is definitely not up. We still get a lot of stuff done and we haven't adjusted any of our forecasts, but coordination has become a whole lot harder. Sure the company has been generally ready for this for a long time, but as individuals we were a bit blind-sided by the suddenness of it. Oh, and the local school district has gone "remote-learning" as well for this month (think WFH, but for 9-year-olds), so local parents are doubling as home-school proctors. It's not a distraction-free environment.

Thing is, we wouldn't have offices if it we didn't work more efficiently there. It's not like working from home is something foreign to us; like I said, we all do it as often as we like. Each of us maybe a couple of days a month, as circumstances require. But sending everyone home at the same time, that hasn't been the utopia it might seem to the casual onlooker.

That should be a given.

Linking to a paywalled source for an audience that you can't guarantee are all subscribers is like telling everyone to just trust you that a story exists.

Being first to report something is ultimately worthless, and absolutely not what we want to encourage (rushing to publish in order to be first).

What matters in actual journalism, and what we should encourage, elevate, and credit, is the BEST reporting. That is, the most accurate, most readable, most informative, most honest.

Factors like misleading clickbait, content-free speculation, inflammatory commentary, and poor fact-checking need to disqualify outlets from consideration when determining which news source to promote on a given story.

I don't mean necessarily junking a publisher categorically for past sins, but rather looking at each story individually and determining whether someone else is reporting it BETTER.

PKIs are a much more general system, but this is a very specific PKI that was built specifically for web browsers. You can use others, you can even build your own. The fact that the this PKI was first, means that some people depend on it who probably shouldn't. But its still by the browsers, for the browsers.

At no point have the browsers ever not been running the whole TLS show. The CAB forum is a useful construct, but its usefulness has a specific place.

Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote.

That be a useful set of meetings.

But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.

I tried to read this 4 times. I really did.

But I couldn't get past "Take A Way".

Take... A... Way... Take a way. Take exactly one way. A way to take. I have three ways, you get to take one. Need a way? Take a way! Feel free to take a way from the way jar. Life finds a way... and then takes it.

This.

The whole point of k8s, the reason Google wrote it to begin with, was to commoditize the management space and make vendor lock-in difficult to justify. It's the classic market underdog move, but executed brilliantly.

Going with a cloud provider's proprietary management solution gives you generally a worse overall experience than k8s (or at least no better), which means AWS and Azure are obliged to focus on improving their hosted k8s offering or risk losing market share.

Plus, you can't "embrace and extend" k8s into something proprietary without destroying a lot of it's core usability. So it becomes nearly impossible to create a vendor lock-in strategy that customers will accept.

Following your metaphor, what about email between Bob and Carol which mentions Alice explicitly, using her name and email address? Should Alice be entitled to a copy of that private message between Bob and Carol?

Does information become yours if it is about you, even if you aren't a participant in it's creation or distribution?

It's easy to argue that advertising distribution lists are private conversations between FB and advertisers, and hard to argue that they're not. Saying I'm entitled to a copy of that conversation if I'm mentioned becomes a hard position to take.

I think the problem they're printing out isn't the writing, it's the content. Coroutines and event loops are two independent concepts. And scheduling tasks cooperatively in userspace is another concept still. You've got three different concepts: coroutines, event loops, and cooperative multitasking; and you're saying they're the same thing.

There are lots of reasons to open source internal software, and only a minority of them involve establishing a serious community and driving significant adoption. But the PR claim you're making isn't particularly credible. The ROI is abysmal if that's all you're after, and there are easier ways to get it.

Based on your specific complaints, it sounds like your opinion doesn't matter in this case; you're not the audience. You want support and a predictable future: you're looking for a product, not for technology. This isn't a product, and it's not a platform.

If instead you represented another company looking into solving this same problem yourself, and are looking at starting points, then you're the perfect audience. In that case, you'd have time and motivation to contact the developers directly rather than gripe on HN. You'd be less interested in whether there was an organized community, and more interested in how to directly influence the roadmap. You'd care about what the code looks like, how they solved Problem X and Problem Y, that kind of thing.