That's the answer, almost all of QUIC is encrypted for privacy and protection against meddling middleboxes and protocol evolution. ACKs can be done in many ways which should enough reason for them to be protected so middleboxes doesn't stop protocol evolution.
U+241E is "SYMBOL FOR RECORD SEPARATOR". It seems a bit weird to use that as a separator instead of simply U+1E which is the ASCII character "record separator".
I just skimmed the paper [1], and their conclusion starts:
> We identified one colormap in particular to be optimal for viewing by those with or without CVD, which
we name cividis (Figs 4 and 5), generated by optimizing the viridis colormap and selecting the J'
linearization that maximizes the range of J'. We chose this map due to its wide range of colors, resulting
from a wide range of J0 values while still changing b0 significantly, and overall sharpness when overlaid
onto complex images.
They aren't confidential, at least not more than your full name. It's a common myth, probably stemming from the fact that there's plenty of laws about how to treat information that can be used to identify people. But those laws pretty much also applies if you just a have list of peoples full name.
Edit: Reading through the law, they are more confidential than your full name, though not by much. Generally you can't publish them publicly. And usage within companies and the state are regulated, but fairly permissive. Datatilsynet has explicitly said that they shouldn't be used to identity that a person is who they say they are, and only should be used as a primary key to differentiate people.
I believe the "/or" was added after it was submitted the OSI and FSF, because they felt that it could be misinterpreted without. However it appears that OpenBSD didn't change their version (probably because they don't believe it's ambiguous).
Though, just a language simplification of the MIT License. (not that that is bad). However it is not as permissive as the 1-clause BSD spelled out in the article, since it still requires copyright notice in binary distribution. The Boost license is one of the licenses I remember to be in effect the same as that 1-clause BSD license. Which is nice since you can use the Boost header-only libraries without having to consider where you going to credit them, much like any standard library in most languages.
I have tried to read into why PostgresSQL doesn't yet (they are working it) have upserts. Several times I have come across people discussing that Merge which is much more powerful the simple upserts, also doesn't really mandate the nature of upserts in most databases.
Simply a user might expect that upserts always succeed with either an update or insert, and never return an error (except when the consistency model is set high enough).
The problem is that many implementations of merge doesn't provide that guarantee, unbeknownst to many users. Or they are simpler databases such as sqlite (which doesn't provide the same multi-user/transaction performance). Postgres, as they are well known for, want to implement it properly. They know that application developers does not expect that they have to resubmit failed upsert. Aside: they are also working on audit features, which presents a number of implementations difficulties that upserts also does. So some time or later, probably not to far away, we will see upserts in postgres. Proper atomic, performant, nice upserts.
I'm just guessing here. Current technology uses all sorts of tricks to focus/manipulate/use 193nm light so that you can build something smaller than the size of wavelength. However many of these tricks don't work with EUV or bigger but smaller than current light because it has to be done in a vacuum. So basicly you have to go even smaller to be better.
In addition, I pretty sure many European keywords can type µ by alt-gr+m, at least in Windows on my Danish keyword. Only know that because once I had a keyword were they actually had printed it on the key, just like they always do with € on E.
When you say safe alternatives, you mean ASCII right. You should think about looking into something which also understand the characters a bit better. For example å,æ,ø can mostly be turned into aa,ae,oe for danish and norwegian. Just turning them into a,?,o would change the meaning.
Notice that this question is 2 years old. I would imagine that several lots of things have happened for Roslyn. (They even talk about some of what they were working on). Nevertheless quite interesting.
It is my impression that LLVM has matured quit a bit since unladen swallow. Not least in the JIT domain. A lot of unladen swallows development was spent on improving LLVM and not on implementing Python as fast a possible. I seem to recall that the LLVM developers have had discussions on how to better support JIT compilers in LLVM, since unladen swallow, some of it precisely because unladen swallow failed.
On the other hand, inline test does make it easier to write tests while writing the function. Besides many well-written programs already contains inline documentation (not comments) that can be a lot longer than the function they describes.
Code folding in a IDE goes a long way to make this bearable.
Python is fairly simple in implementation while being as flexible as possible.
Look up the concept of descriptors for something fairly difficult to optimize when you consider __getattr__ or __getattribute__. Consider also that you can directly access the __dict__ of both an instance and of the class of that instance. You can monkey-patch the class extensively or directly into it's __dict__. You can even replace the __class__ reference on instance to make it a subtype of different class (which is insanely flexible). Then there's the stuff about metaclasses, which is fairly advanced and collides with all of the other flexibility.
Basically pretty much anything not from __builtin__ or from a C extension is entirely mutable at any time. Consider one of the problems PyPy had with some packages. PyPy didn't support `locals()[42] = value`, which some packages actually depended upon. Nor does PyPy support `instance.__dict__[42] = value` which even more depended upon. Generally Python used a lot of simple concepts such as mutable dictionaries with heterogeneously-typed keys as the implementation of how classes, modules, etc works, which is flexible but very hard to optimize in any way (especially since they are mutable).
A self-driving car would be able to provide a lot more information about how the accident happened.
This would probably except a lot of accident since they could prove that what they did was (mostly) correct, and it was either the other drivers' fault or something outside of their control.
Any accident this wouldn't cover, would undergo a lot of scrutiny, more like how airplane crashes are, than car crashes are today. And they would be able to fix it. Which would be a pretty good argument for self-driving cars.
Imagine a violent crime: A person takes some medical drug which this time causes a psychotic break wherein he kills a store clerk. How long should he be locked up? Clearly he's pretty much "rehabilitated" as soon as he's of the drug.
FLAC would probably be a bad example, since it is lossless. It makes fewer assumptions about the content of the audio file, since it anyway has to encode all of the noise and minor stuff. Making too many assumptions of the content would only necessitate a facility to introduce specified noise into the audio later. Which I can't imagine would be both fast and small.
SPDY requires that you run it inside TLS. Within the already existing TLS handshake the client and server can advertise that they support SPDY instead of HTTP.
The way you describe it comes of as more complicated?!
Of the things to note is that nothing of SPDY describes encryption, which is why a lot of people have thought about using it without TLS via some other negotiation strategy (but nobody have really implemented this, since the value is only minor/non-existent outside internal networks).