driax

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.

So pretty closely related :)

[1] https://arxiv.org/ftp/arxiv/papers/1712/1712.01662.pdf

The decoder is under the Apache license. But yes otherwise GPLv3+

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.

And more important: I he hadn't he wouldn't have had the money to found NeXT, which was quite probably required for Apple to survive.

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).

I don't get it when people keep repeating something like this. Google pushed a lot for adding TSL/SSL encryption between Google's servers and the client, to the point of inventing several performance improvements in TSL start-up. However they sure don't encrypt inside the client [note] and then sends it as a blob to server to storage, mostly because that's not really how webapps can work (for practical "can work" values). For example this wouldn't allow you to full-text-search all your own emails in gmail. Moreover this would mean significant performance regression every time you would open up any Google web app, because the client would have to decrypt all data, without much help from indexes. [note] Even encrypting and decrypting in the client would only help so much. It is likely they could be ordered to splice they data while in the client for any person of interest. Cloud web apps simply requires a legal system that respects peoples' data.

The point the grand parent was making seems to me to be rather simple. He says that the designers of Perl (not the author of the article) didn't consider parseability of Perl an objective, since they focused more on making a scripting language for humans. Of course the author (and many others) would have liked if Perl was statically parseable since a lot of static tools like documentation require this to be complete. So it just shows that maybe static parseability should have been an objective of the Perl designers or any other language designer in the future.

Technically only the Mozilla Foundation is non-profit. The Mozilla Corporation which is the organization that has the deal with Google about the search feature, and is the one which distributes common versions of Firefox is not non-profit. Granted Mozilla Corporation is owned by Mozilla Foundation, but still, this just shows that in non-non-profits organizations the decisions are governed by owners, for better or for worse.

Crashing would be a side-effect. However your idea is correct. Consider instead:

    [True, SpinForever()]

You can consider any "variable" in Haskell to have a value of the type of that variable or the bottom value. The bottom value is tech-speak for no-value at all, since it means that the program has gone into a infinite-loop trying to produce the value.

Eagerness would fix this since, such a program as above would always cause a infinite-loop, and thus the program would no longer be a useful construction. While with lazy evaluation it only spins if you try to evaluate any more than the first element in the list.

Of course you could also fix this by going with total programming which basically removes the implicit bottom-value from the language. Which is a nice concept. Though then you need to explicitly declare you infinite data from you finite data (think a network socket, compared with string). And you lose Turing-completeness (but who needs that anyway :) )

Related is the term x32, which is an architecture (from the point of view of the Linux kernel) for x86-64 code designed to run in 0x86-64 32-bit mode.

Why would you do this? Given that you never use 4 GB of memory, you can save a few bytes of memory (32-bit pointers instead of 64-bit) while still getting the extra registers and operations of x86-64 code.

One thing to keep in mind, is that author mentions that the same card does not perform equivalently in Windows and Linux, specifically multi-screen support under Linux. From the forum post:

"I own a NVidia GTX 690 which I bought for two reasons, gaming, and multi monitor setup for work, NVidia made it very clear that this card would drive up to 3 screens in 2d, which it does quite nicely :-+... under windows :--! The tight asses have decided that if you want this feature under Linux you have to get a Quadro which has Mosaic support :palm:. So naturally I decided to look at how mod the card, as the price difference is over $1000 between the GTX 690 and the Quadro K5000 (same GPU) and, get this... the K5000 is only single GPU and clocked some 25-30% slower then the gaming card, what a joke"

It might be that he had expected 3 screens under Linux but didn't get it, so he set out to "fix" it. It seems a bit excessive to expect someone to spend $1000 for a card performing 25-30% less just to get Linux support :)

The other day I used Bing to search for "C++14 ...", because Google doesn't recognize it as a search term. Though it does understand C++11.

Granted I didn't get many worthwhile hits, but I did get some. Google simply provided me with the results of "C++ 14", which is pretty useless.

You mean by not being a tax haven for profits from outside the US. Or am I missing something?

It it noteworthy to remember that the reason LFTR advocates says that LFTR reactors will stop nuclear proliferation is that all the U233 will be comtaminated with the highly radioactive U232 isotope. To extract U233 from the active core of an LFTR would take just as much engineering as normal enrichment plants, if not more. The current enrichment plants would never allow U232 inside their plants since it is so difficult and dangerous.

Of course that's all hearsay from the LFTR advocates :P

Most of the links you give talks primarily about thorium as an alternative fuel in traditional nuclear reactors, which is not what this article talks about. It talks primarily about Liquid Fluoride Thorium Reactors which are entirely differently to current reactors, which are all solid-state reactors.

It's really sad to see the different topics gets confused, because they are really different. Thorium as an alternative fuel doesn't really solve much, besides it's maybe cheaper for some countries. Of course the entire expression "Thorium reactors" are somewhat at fault. It's incredible ambiguous, especially when people inside the current nuclear establishment talks about using thorium in (slightly modified) traditional nuclear reactors, such Pressurized Water Reactors.

Of course there are many things which can be said against LFTRs, mostly that it's still an unproven technology. Sadly it'll stay that way if nobody does something about it.