Sweet. Glad to hear someone's working on it who knows what they're doing. :-P
1,047 karma · joined August 17, 2015
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.
* 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.
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.
Wow.
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.
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?
So in that case, optimizing for a single customer makes perfect sense if it's the right customer.
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 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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.