davidad_

For those interested, the jury originally ruled in favor of Led Zeppelin, but this year the 9th Circuit partially vacated the judgment and recommended a new jury trial. https://www.lexology.com/library/detail.aspx?g=ab93a0e7-52e6...

Did anyone else notice the claim that “The computers had never been connected to the Internet,” followed in the next paragraph by “On another screen, Obermayer opened iHub, the encrypted Facebook-like forum that the ICIJ created to make collaboration easier across borders”? Something doesn’t add up here...

As a bonus, .rs is the filename extension for Rust source (as well as the TLD of Lobste.rs)

Those mining memory-bandwidth-hard cryptocurrencies, like zcash, may consider evaluating these. According to the article, they’ll have 1200 GB/s, vs 900 GB/s for the top nVidia Volta card. (Of course, it’s quite likely that this increase in memory bandwidth isn’t worth it for reasons of cost, ISA suitability for the particularities of Equihash, etc., but hard to say without a lot of thinking-through.)

I’m embodying an archetype here, but I can’t resist.

The use of QTermWidget makes this almost entirely an exercise in building a hello-world Qt app and very little about building a terminal. That is all very well if you are looking to learn Qt—which is by no means an unworthy aim—but I wouldn’t use the adjective “minimal” to describe any Qt app, no matter how short its main().

If you are actually looking for a minimal terminal, whose source code is intelligible and readily customizable, look no further than https://st.suckless.org/

“Everything being subsumed by TensorFlow” doesn’t seem to me like a particularly worrisome outcome. The status quo is “everything being a Python library,” and people generally seem to view that as positive. The PyData movement brought another level of interoperability to the ecosystem, so you can combine elements from Pandas, SciPy, sklearn, etc with good runtime performance and low cognitive load. Bringing everything into TensorFlow abstractions makes more optimizations possible (especially on heterogeneous architectures), and perhaps even more importantly, makes it easy to run end-to-end gradient descent on compositions of parts from across the ecosystem.

From what I can tell, it's worse than just Intel being a gatekeeper - every execution of "remote attestation" essentially relies upon the Intel Attestation Service to actually perform verification (or at least as the certificate authority). In a (hypothetical) world where all of Intel's security features are owned by the US intelligence community, this type of pattern seems like an awesome vector for deception ("false sense of security"), where surveillance groups have a large supply of Intel-certified EPID keys, which they can use to arbitrarily fool remote-attestation clients. It's concerning to me that the OP article doesn't even mention Intel's highly trusted role in this process.

What's the situation with control of TrustZone on this chip? In particular, are there any manufacturer-fused keys, and are there any user-fusable signing keys?

I have many problems with this analysis, perhaps enough to write my own blog post, but I am lazy so I will just outline my disagreements here (at least for now).

First: I claim that what we seek in a movie rating is information about whether we will like the movie, and that this can be formalized as the expected KL-divergence (information gain) between the Bayesian posterior distribution (probability of enjoying the movie conditional on its rating) and the prior distribution (probability you would enjoy a randomly selected movie). Of course, this will depend on your taste in movies, especially how much it correlates with others. But, we can _bound_ it by taking the Shannon entropy of the rating distribution: there is no way we can get more information from a rating than this! It is this bound that allows us to penalize the distributions that are heavily biased towards one side of a discrete scale, like Fandango. However, the "ideal" shape in this context is far from a Gaussian - it is uniform! The uniform distribution can also be justified as being calibrated such that the quantile function is linear - a score of 90/100 from a uniform distribution means a 90th-%ile movie. Determining a quantile is often a transform we try to perform intuitively on ratings so such a transform being trivial seems useful.

Second: The Gaussian distribution does not have bounded support! That is, a rating scheme with what you claim as the "ideal" distribution would have _some_ ratings with values that are negative or otherwise "off the scale". Not so ideal! If you wanted to model movie-goodness on an unbounded scale such that a Gaussian would have sense, then you should transform that scale into a bounded scale, eg with a logistic function, yielding an "ideal" shape of a logitnormal distribution, which incidentally can fit the strange bimodal Tomatometer distribution quite well. Even if you specifically wanted a unimodal, bell-shaped distribution, at least pick a bounded one like the beta distribution.

Third: setting aside which distribution you want to penalize distance from or why, dividing the space into three arbitrary intervals to facilitate the comparison seems ridiculous. There is already a perfectly good metric on probability distributions, the mutual information.

I do wish energy were priced per megajoule. But I suppose this is probably a symptom, like miles-per-hour vs meters-per-second, of the non-metrication of time units at the relevant scales. (It takes order of an hour to drive somewhere, and order of an hour to run a laundry machine.) If we had a metric hour of a thousand seconds, a kWh would just be a MJ, no problem. And if we had a "metric year" of a million seconds, a "TWh/yr" would just be a GW. Unfortunately, it's pretty important to humans to track time in a way that lines up with earth's rotation and revolution, and there's no way to make that metric. (If French Revolutionary Time caught on, a second would be 1e-5 days instead of 1/86400 and an hour would be 1/10 of a day, and that would be a start, but the year/day ratio is pretty intractable.)

FWIW, I do find Interface to be subjectively noticeably more pleasant than Roboto in the comparison here.

The specific problem described in the "encapsulation" section is solved in modern C++ (11/14) by std::unique_ptr. While this may seem like a trivial quibble, I think it's part of why I find modern C++ quite tolerable despite disliking almost every other "object-oriented" language.

The latter (it's been there for many hours). See also https://news.ycombinator.com/item?id=5990015, https://news.ycombinator.com/item?id=11333686.

Supersonic-capable aircraft tend to be absurdly fuel-inefficient when operating subsonic (for aerodynamic reasons I don't really understand).

Here's the differentiable stack/queue/deque paper: http://arxiv.org/abs/1506.02516

It is indeed similar to some work from FAIR, where one of the tasks was binary addition: http://arxiv.org/abs/1503.01007

I submitted the OP essay with an attribution ("see Chris Olah's blog for a fuller treatment") but it was removed by the editors of Edge before publication (apparently their policy is never to send readers away from Edge). I have asked them to at least re-insert Chris' name and I hope they do so soon.

This is a fair point which deserves a response.

Before text was invented, people communicated using spoken language. Text was a major breakthrough because once some communication was written, it became a physical object which could be stored in libraries, carried by sea or horseback, and read by more than one person. However, it was a compromise: you could no longer interact with the reader. As a result, most people prefer to communicate interactively. Even people who cannot speak use sign language instead of resorting to text.

What we are doing right now is a hybrid of textual and interactive communication; we're taking turns writing chunks of text. In the programming world, this is roughly equivalent to a REPL. But actually developing software using a REPL is still quite uncommon; I think it's reserved mostly for Emacs Lisp hackers.

We're doing this instead of communicating by audio partly to create a public indexable record of our correspondence, partly to protect our privacy, partly for synchronization reasons, and partly due to arbitrary norms and the information systems that co-evolved with them; but mostly to save ourselves from mentally keeping track of the edits we make to our expressions before committing them ("scratch that...what I meant to say is.."). When the target of one's communication is a machine with a visual display, that latter concern completely evaporates.

Naturally, the screen editor (introduced in 1961 as Expensive Typewriter for the PDP-1 and pretty well refined by the NLS era) implements this suggestion thoroughly. Yet, generally, the screen editor is used only to edit pieces of text, which are then separately turned into programs. What I'm proposing is nothing more outrageous than a screen editor which edits programs directly instead of textual representations thereof.

I am very glad that Urbit exists and is being funded. I have corresponded with the author and differ with him on some design decisions that I consider significant. Nonetheless, it is an excellent example of the "rethink everything" type of ambition that I would like to see expressed more.

My entire article is about things that happened between 1955 and 1969. The part where I state my thesis literally concludes "With a solid historical perspective we can dare to do better." I'm not sure how much more obvious I could make it that I "see the merit in the past when attempting to blaze a trail into the future".

It's the _present_ whose merit I find lacking.

I included a footnote to address this criticism. http://davidad.github.io/blog/2014/03/12/the-operating-syste...

I am very happy that you get the point! :-)

To address your criticism: Internetworking fundamentally required new hardware, Interactivity and Hypermedia depended on advances in display technology, and Virtualization and Transactions benefit substantially from hardware acceleration. However, the OS, the PL, and the GC were all independent of any new developments and hardware. Our display technologies are already way ahead of the computational features they should be able to support. Same goes for telecommunications. And the hardware acceleration that powers virtual memory and memory locking is versatile enough to be applied to more advanced abstractions as well (although the advanced abstractions might later benefit from more advanced acceleration).

I spent a few years at MIT trying to design revolutionary hardware systems and left with a deep respect for Intel. Much as I'd like to have a PC based on the Lisp Machine or the Connection Machine, I've come to believe it's we software folks who really aren't keeping up, rather than any kind of stagnation in the hardware world.

In fact, Intel comes out with a whole pile of new machine instructions every other year, and they probably never get invoked once on most PCs: most binaries are effectively compiled for AMD Opteron (the first x86_64 processor, released in 2003) so that they'll run seamlessly on anything since then.

This indirection already happens in present systems. Check out my previous blog post about it: http://davidad.github.io/blog/2014/02/19/relocatable-vs-posi... Modern hardware is optimized to do this kind of indirection reasonably fast. What I propose can exploit the same hardware acceleration.

Yes. I am working on it, but it is "kind of hard" to do by oneself. Also, writing about it is a good step, regardless of who might be convinced or not, simply because it forces me to get my ideas more straightened out.

Naïvely, glass is made from sand and copper is mined. And I can already recycle glass from my house, but not copper. So it looks like an environmental win to me. There may be something I'm missing.

I may have been overzealous here. The page also provides Garamond in various OpenType and webfont styles, and I wanted to be sure that the Garamond is displayed with ligatures, because Garamond's ligatures are really nice and not particularly noticeable (whereas I notice the lack of ligatures right away). I didn't really give thought to what happens if the page is being rendered in a different OpenType font for some reason. Perhaps I should replace "dlig" with "clig".

Wow! I like your C solution. I'm glad that at least the speedup is still measurable, but it's a close shave.

I implemented your "free 2x speedup" in asm [1]. Sure enough, solution time improved to 4.6us on my machine [2].

[1] https://github.com/davidad/8queens/commit/61119a7f0019e4a85e... [2] https://github.com/davidad/8queens/tree/free-2x-speedup

They truly, truly are.

Here [1] is the comparison repository, for anyone interested.

[1] https://github.com/davidad/8queens/tree/%2Bc_comparison

EDIT: I don't seem to have -Ofast, but I added a note to the readme to ask people to try it. I also added the recommended flags for Sandy Bridge, i.e. -march=core2 -msse4.1 -msse4.2.

It counts up every solution, thus the "92" exit code. However, the non-pretty-printing version does take some shortcuts - it can't reconstruct the entire current board state in O(1) time from its actual register state. So I'm not sure exactly what you mean by "iterate over all solutions". (It certainly doesn't bail out when it finds the first solution, if that's your question.)

See [1]; it is about a factor of 7 win vs. a reasonable C implementation.

[1] https://github.com/davidad/8queens/tree/%2Bc_comparison