If one actually looks at the current pingora API, it has limited ability to initialize async components at startup - the current pattern seems to be to lazily initialize on first call. An obvious downside of this is that a service can startup in a broken state. e.g. https://github.com/cloudflare/pingora/issues/169
I can imagine that this could easily lead to less visibility into issues.
It has no mention of any chloroquine trials in Denmark, but mentions an upcoming one for azithromycin and hydroxychloroquine:
"A Randomized, Placebo-controlled Double-blinded Trial Evaluating Treatment With Azithromycin and Hydroxychloroquine to Patients With COVID-19 N=226 patients with positive COVID-19 test/diagnosis during the hospitalization randomised to Azithromycin and Hydroxychloroquine or placebo".
It seems more likely that the news article is slightly inaccurate here, rather than the agency's information being outdated, but either is possible.
Actually, the thing we started using nix for was reliable caching of compiled artifacts, including not just your code, but all the programs and libraries that your code depends on. It's another thing that's difficult to do in a general sense, but if you have a fairly strong notion of reproducible builds, it's possible.
I know it's less of an issue for go users, but one of the great things about nix is how your runtime dependencies are (mostly) defined by inference from the programs you've built. So, if you build a program that links against libpg.so, the runtime requirements will automatically include that library!
Since your runtime requirements depend on how you compile a system, you usually have to be quite careful with keeping your Dockerfile in sync with what you're building. This busywork just goes away.
Nix involves quite a large upfront time commitment to understand it, but it solves problems that I haven't seen solved elsewhere (well, I guess guix is similar), and does it across all the languages you write for. That it can work across toolchains and languages is a unifying force, and so I think it's one of the better systems for reducing the "exponential fragmentation" referred to above.
Yup! I assume that at this point general counsel is involved in everything Google says publicly; it's then worth nitpicking at the exact details of what has or has not been admitted, because legal folk definitely have!
That is not what the note said. It said that screenshots made their way outside the company.
I would associate that with an email account that wasn't the work account, a printed page that was taken off-premises, a non-work cloud-hosted storage service, or to a computer that wasn't a work computer. It does not say that the place the information was sent to was any third party.
It could turn out that the information was sent to a third party, but that has not (yet) been claimed.
Agreed that there's not enough context to say why screencapping happened, what happened to said screencaps, and how all of this turned into scared employees.
I currently perceive Google's note as if it were a press release; treat with appropriate scepticism. We'll have to see if more information comes to light.
Google's statement does not claim that the screenshots were shared with others. "Outside the company" covers a multitude of possibilities. It could also include saving screenshots in one's personal GMail account (in Google Docs, etc.), which Google may be able to access (I don't know if they can or not, but the relevant company is the US, where these things are usually more legal than in the EU).
If so, it might suggest a wish to share with people in future, e.g. in a court case, etc., but it doesn't necessarily mean that this information _has been_ shared.
It could also mean that the information _was_ shared with others, just pointing out that it isn't exactly what the statement says.
I do appreciate that some people felt unsafe, but I wonder how exactly the messaging was made. Nobody ever came to me and asked how I felt about my work calendar being shared. You can't even get that information from Google.
So this information on sharing was provided to particular people, and they were asked, "do you feel scared?". Presentation is everything, and if presented in terms of how their personal information was included, it can feel different compared to when shown in neutral terms. In addition, if these people were told that the four employees were dangerous or a threat, this will also colour their viewpoints.
Bluetooth and kidney transplant arguments are about two hypothetical stories, and pointing out that if these had happened, it would be weird (well, yes it would, but that's not this story, they are very different).
I meant, there is no way for subscribers to a calendar to do that automatically. There are possible heuristics that could filter out clearly personal entries (keywords, etc.), but that feature would need to be implemented by (cough) Google.
There are obvious ways for calendar owners to separate the information (which was not done in the instances that Google refer to).
They obviously subscribed to work calendars in order to follow the work activities of those people. There is no other technical way to do that.
There isn’t a way to separate out personal events — which shouldn’t be there, or at least should be marked private.
That this information was included, does not indicate that it was a target; it does indicate that it was a useful way for Google to attack their actions.
Google’s statement is, in my opinion, disingenuous.
Including personal information on your work calendar without using privacy controls is pretty bad practice, though obviously some people occasionally did it. There is no indication that this information was a target of the fired employees. There is also no indication that these personal events were included in screenshots “outside the company”. And that phrase encompasses a wide range of possibilities, I suspect that Google made it so general because the specifics would have sounded more benign.
The statement in general is designed to cast the four in the worst possible light.
Okay, I see what you mean. It is a statistic, and so far as it is what it is describes, it's true. And it has some use.
The problem is that what people are usually asking for, is the 99th percentile of response time for user requests, and they get the above statistic, not because they want it, but because they are limited by their monitoring systems; they accept it as a proxy for what they want, when it is actually something completely different, and may have completely different values.
It would be more useful to calculate the distribution for overall response time, and also calculate the distribution for each individual machine; you could then look for anomalies (in your statistics) that could identify which machines are performing badly.
How about this: you have a load balancer that sends much less traffic to servers that are running slowly (but still a small amount of traffic, so that it recognises when the machine recovers). One backend server has a hardware problem; requests that usually take milliseconds now take seconds; the 99th percentile on that machine is much higher than anywhere else. But it's actually serving a tiny tiny fraction of traffic. Is the value useful in indicating the performance of the service as a whole?
The general aim of error handling in languages like Elm is for types to not lie. If you can either return a result, or an error, the type represents that. The more places that can return an error: the more complex the types, and the more complicated the error handling. You can always pass the error value up through layers, but as people would say, it's just easier to make illegal states unrepresentable.
It's not an aim to pretend that failures don't happen, especially when doing remote calls, and the types will be transparent in showing where this occurs.
1. the large number of values that you now know definitely have a value, and you can access without fear that they don't.
2. the helper functions for Maybe that let you deal with optionality in various ways; the possibilities are extensive and useful. null doesn't give you any help, and generally any helper syntax is limited to one or two possibilities.
3. Code cannot fail due to trying to access a null pointer accidentally. Functions that definitely return a value (ignoring severe issues like OOM, etc.) is a somewhat useful property.
The string concatenation API for Java IS terrible, but see modersky's post for the reasoning.
Just don't mistake a bad API for some kind of belief that Scala in general idly converts between types. The weakest point is APIs that use methods defined in java.lang.Object (e.g. toString and equals); they can universally use these methods without restricting the type.
Note that if you define a type as a knowledge of what actions can be performed on an object, then no type safety has been lost; toString() is universally available, though it may not do exactly what you want.
I can imagine that this could easily lead to less visibility into issues.