mnarayan01

For anyone else confused by this, the control logic described in the comment happens in https://github.com/ifduyue/musl/blob/master/src/math/cos.c

Git has all sorts of options for using proxies, but running socat would be the quick and dirty way to do this, something like:

  socat TCP-LISTEN:8080,fork,reuseaddr OPENSSL:github.com:443

Unfortunately e.g. the RHEL 7 world doesn't have mitigations=off yet (in addition to many other kernel command line sugars).

0/0 = NaN

Code Blocks probably aren't necessary

When you're reading raw markdown they're extremely useful for short snippets since they save you two wasted lines per block.

The other requests are still taking the latency hit.

That's a block returning a Hash; see bhuga's sibling comment where he notes that they're using blocks to lazy load the constants in the type definition, which may seem silly for e.g. Integer, but consider e.g. some high-dependency Rails model which requires auto-loading 10,000 other classes.

Then you'd need an extra set of delimiters, e.g.:

  sig {{name: String, returns: Integer}}

The parser thinks that's a block not a hash.

mouse(!) selection of arbitrary text that can be piped to commands and so on

E.g.:

  xclip -out | ...

You can specify multiple digests for an asset, so a non-versioned one can be updated sans downtime:

1. Provider informs clients that a new version with digest X will be deployed.

2. Clients add the new digest in addition to the current digest.

3. Provider switches to new asset version.

4. Clients remove old digest (optional).

Versioned assets are obviously better unless you're in a really weird situation, but SRI doesn't particularly require them.

3rd parties should version their JavaScript resources with a version number in the URL

I mean yes this is true, but it seems almost totally orthogonal to SRI (which is aimed at security AIUI), particularly given you can give more than one hash for a particular resource. If for some reason a third-party can't use fingerprinted URLs, they can still update the resource provided they give "sufficient" advanced notification of the new fingerprint to clients.

And this should be a manual process because automating it would defeat the whole point of SRI.

Obviously it should be offline/write-once, but unless you're reviewing the actual assets as well I'm not sure I see the need to avoid automation.

https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-s...

The #ifndef rigamarole is https://en.wikipedia.org/wiki/Include_guard and at least used to be fairly common. I also used to see the __FOO_BAR_H__ naming convention for these defines all over the place. I'm not sure if __ identifiers being reserved is a (not very) new thing or if it's always been around and people are just now more generally knowledgeable about the fact that they shouldn't be used.

If you include it (possibly indirectly) in a file which you compile, then no, you do not need to compile it separately.

Signing each commit is totally stupid. It just means that you automate it, and you make the signature worth less.

Linus (from 2009) on problems with signing every commit: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

  if a = foo()

  if (a = foo())

The article looks like it's just a generic sports' journalist reporting on a novel statistical technique, with cross language translation added into the mix for extra confusion. I wouldn't take it too literally.

I'd guess that either "Impect disregards all passes that go backwards or don’t beat any defender" would be better phrased as "Impect disregards passes unless they go forward or beat defenders" or the statisticians would defend the original solely in terms of it being a heuristic that makes the problem more tractable.

Additionally, your linked example, with #25 picking up the ball in a danger position after a deflection, is the kind of "penalty box slop" that, naively at least, seems extremely difficult to handle analytically.

From your source machine:

  < /path/to/source ncat remote-host 8001

  ncat -l 8001 > /path/to/dest

Or just skip the shell entirely:

  tar -C /dest/dir -xf -

There has to be an ABI in order for loadable kernel modules to exist

Given a particular install, yes, but it will change independent of kernel version based on e.g. build flags and even conceivably compiler chosen, etc.

it's stable enough that the likes of Nvidia can write installers for their proprietary drivers that recompile a bit of interface glue between kernel and blob

Well...they certainly can. It also can infuriate me beyond all reason...

Nit: AIUI, the kernel has no stable API. It has no ABI period.

Mix "other quite similar videos are explicit" with "other videos from the uploader are inappropriate for children" and pour it into an overly-aggressive automated algorithm.

The majority of the lanes on the road are already dedicated to private motor vehicles

IME, having any lanes dedicated to private motor vehicles is extraordinarily rare. I'm not sure I've ever even seen it, though I do have a vague sense of something like that happening on the NJ Turnpike or one of the interstates going into NYC.

Wow. I do this all the time, and the additional step of piping to sed never ceased to annoy me.

You've made my day.

Well it could be rewritten to use 0x1f (i.e. unit separator) to separate items. I mean it already has significant tabs. Though invariably people would be like "How is it acceptable for make to not support filenames which contain unit separators? It's 2020 guys, get with the program!"

though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon

It's perfectly fine for a rule to have multiple targets, e.g.

  output.txt error.txt: source
    build source > output.txt 2> error.txt

There's this program called make...

A C#-style cancellation token API, orthogonal to promises, is simple, easy to build, and easy to understand.

The problem is that promises were added to the language without any of that being hashed out. Now you may say "Having language-level support for promises is useful; cancellation tokens are more library details", and you'd have a point. The flip-side, however, is that e.g. the Fetch API is only now getting any sort of cancellation ability, and currently I believe it's limited to Firefox and Edge.

Which is not to say that I'm even confident that language support for Promises should have been held up. But I understand the complaints.