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.
I'm disappointed that they (in my opinion) managed to make a worse color scale. If you look at the CVD-Jet color bar you can see blocks that appears quite similar separated by too sharp transitions. This is a common problem in e.g. rainbow scales. They highlight them selves that yellow appears as highligt, yet the highest values get translated to black. How is black supposed to be interpreted as more luminescent/intense than yellow? It happens to be a color scale that makes the cells look good, but to me that is happenstance.
CVD-Jet is not the new color scale, it's a simulation of what Jet looks like for certain colorblind users.
To my eyes, cividis (which is the new scale) is good by the numbers, and there's a strong argument it's more robust for colorblind users, but viridis looks better.
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.
> it still requires copyright notice in binary distribution.
Really? I thought MIT/ISC just meant one can't remove that notice when redistributing the source. Is one supposed to do something particular with binaries as well?
The MIT license says: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
Typically, "Software" means also binaries [1]. The MIT license text is usually included in the software documentation or about box. If you are not sure where to put it, then ask the open source project owners how to attribute them.
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.
