If one of the possible vendors convinces you that that they have a next gen model that is so powerful it found 20+ year old bugs in a hardened operating system, that would undoubtedly have an influence on your decision even if you are only buying the current model.

The choices therefore are:

1. No bound check

2. Bounds check inserted, but that branch isn't covered by tests

3. Bounds check inserted, and that branch is covered by tests

I'm skeptical of the claim that if (3) is infeasible then the next best option is (1)

Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.

Why do you say that?

At least in Australia, drinking fountains ("bubblers"!) are fairly non standardised. I don't recall seeing many with that rubber top, but the rotating release mechanism is pretty common. I'd say press buttons are more common but both are typical.

Still not US$14k, but not quite the $25k it is in other markets.

I guess Nintendo don't see enough left over space to bother trying.

http://www.slackware.com/faq/do_faq.php?faq=general#0

If the switch had been a failure, then a lot of households that currently have a switch (only) would have bought a different console and that would likely have been a PS5 (even if they held on to their previous generation console, and waited a couple of years until the PS5 price dropped below $500)

I have a PS4 and a Switch at home. The kids play the switch and occasionally play on the PS4. I can't justify buying a PS5 because there's only so much gaming time available, and family gaming is covered by the switch and my personal gaming is good enough on my PC. Take the switch out of the equation and that changes.

PS5 is winning the AAA console lane, no doubt. But Sony could have been making more money if they could also own a significant portion of the family console lane.

That requirement forces phones to have some degree of special handling for emergency calls. It may have required (or been interpreted to require) that a phone make emergency calls over 3G if VoLTE was unavailable. I can imagine someone deciding that means "lets just use 3G for all emergency calls" because who ever expected a case where 4G was available and 3G was not.

"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.

Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.

I wonder whether you could get the benefits of weighing the evidence collectively but reduce the influence that 1 or 2 dominant jurors might have.

If 2 or 3 independent groups reached the same conclusion, does that increase the chances of them being correct?

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ss...

You can see that the team did a big refactor of key handling about 14 months ago that required multiple rounds changes to the DSA code.

That's the sort of cost that legacy code brings - it's not about make changing to the DSA feature, it's about the cost of maintaining the DSA code when you make changes across the codebase.

In the original mail, DJM mentions that they'd like to explore a post-quantum signature algorithm. Adding that to the codebase is likely to require some broad changes to key management, and that will be less work if there are fewer supported key types.

If he panicked after the Stuxnet attack, as his family is reported to have said, then it's likely he has behaving erratically and was fearful for his life.

That could easily translate to circumstances where he rides a motorcycle in a particularly dangerous manner - e.g. fleeing from someone he thought was Iranian/Dutch/US/Israeli intelligence (even if they weren't).

From the decision (linked 2 up)

At all material times, Respondents Cognizant and Google have codetermined the essential terms and conditions of employment of employees employed at the E. Parmer Lane facility and have been joint employers.

(2nd to last paragraph of "Findings of Fact > Jurisdiction")

The original article (the register) quotes a union member

Google and Cognizant have proceeded to make unilateral changes to our working conditions such as a forced return to office, removal of sick pay during a global pandemic, and the implementation of a 'Clean Room' policy that bars us from having our phones, paper, or pens in our office, without bargaining with our union.

The line of reasoning seems to be something like:

- There are decisions that Google is making that, if the workers were employees, would need to be negotiated with the union.

- Google is making those decisions with application to the contractors as well as their direct employees

- Consequently, for the purposes of union negotiation, Google is a joint employer (alongside Cognizant) of the contractors because it is making decisions that affect the workers and ought to be negotiated with a union.

If that is the argument, it seems fair to me.

If Google wants to make decisions about the employment conditions of contractors then it needs to accept that it is an "employer" of those workers. Alternatively it can decide not to make decisions about their conditions and leave all of that to Cognizant - but in that case it cannot enforce those policies on the workers until after Cognizant has negotiated with the union and reached an agreement about the the workers conditions. Google would have to make sure that every workplace policy that they wished to have applied to the contractors was handled as a contractual arrangement between Google and Cognizant, not an employment arrangement.

I strongly suspect many interviewers (myself included) would have a few "top issues" and significantly favour candidates who pointed them out. But as the candidate you don't really know which issues will seem important to the interviewer.

It's not an irrelevant exercise though - code reviews are a real part of many roles and making sensible choices about what to comment on is a necessary skill. But it is hard to avoid turning the interview into an exercise in "guess what's on the top of my list"

If your premise is "We look a lot like Google circa 2015, and I really like what they've done since then, how did they do it?" then it might make sense to replicate their hiring.

But if you want to achieve what Google achieved between 1998 (founding) and 2004 (IPO) then asking what they do now (or have done over the last 10 years) isn't particularly relevant.

And the RFC explicitly says:

    Implementations MUST reject the encoded data if it contains
   characters outside the base alphabet

You've got your directions backwards.

7pm in NYC is 4pm in SF, so you wanted to use solar power to provide evening energy then you generate in the West (SF) to power the East (NY).