akshayn

> We also recommend to save the command used to generate a figure in the LaTeX file

An approach I have adopted recently is Knitr[1], so this layer of indirection goes away. With knitr, my data goes directly into the paper repository, and then my Makefile has something like this:

  %.tex: graphs/%.Rnw
    Rscript -e "library(knitr); knit('$?')"

The nice thing is exactly what the authors recommend: it's much easier to enforce a standard appearance across all the figures, and automatically incorporate more recent data into the paper as part of the compilation process.

[1] https://yihui.name/knitr/

While HP's "The Machine" specifically appears to never have gone beyond the marketing phase, I think your excitement about the underlying technologies - silicon photonics combined with nonvolative memory combined with resource disaggregation - is valid [0], and they are probably coming.

You can buy NVM today [1], and building systems for resource disaggregation work is an active problem [2].

[0] https://www.usenix.org/conference/fast14/technical-sessions/...

[1] https://www.intel.com/content/www/us/en/products/memory-stor...

[2] https://www.usenix.org/system/files/osdi18-shan.pdf

Often a research university will interview many candidates, give offers to/recruit many candidates, and yet find that for each individual it recruited, there was a competing university which worked better for that candidate.

Usually (from what I have seen) candidates on the academic job market don't end up in industry (at least not immediately) - they are in the job market because they are passionate about academia.

The Jacquard loom is what started [1] the punched card era. Check out this episode [2] of the podcast 99 Percent Invisible for an accessible explanation.

[1] https://en.wikipedia.org/wiki/Jacquard_loom

[2] https://99percentinvisible.org/episode/kids-clothes-articles...

As I commented here [1], one of my biggest issues with Zulip is that the mobile apps don't have a "jump to most recent" feature, and whenever I open the app I have to manually scroll past hours (or days or weeks, since I dislike opening the app so much) of old conversations.

Has this been fixed/improved?

[1] https://news.ycombinator.com/item?id=17623592

My research group (at MIT) also uses Zulip for messaging.

While I agree with everything jremmons said (hi john), it's important to note that their mobile apps are so bad that they're basically unusable - there's a particularly aggravating bug in the iOS app where if you don't open the app for a while, it forces you to load and scroll through days of messages to read the most recent ones.

I think this is unlikely. Part of the advantage of having built your own datapath is being able to change it on a whim; I don't see Google giving this up by agreeing to stick to some fixed specification.

You should compare this to the cost of buying an FPGA. It can be cost-effective.

"If, instead, we had identified sessions using only layer 4 data, then mobile IP would have worked perfectly."

Mobile IP can still work with the current infrastructure -- https://en.wikipedia.org/wiki/Mobile_IP

This proposal was basically a service which would host a static IP for you (similar to the LTE structure but with IP underneath instead of L2), and forward to whatever your "real" IP was using IP-in-IP encapsulation.

As the author states, layers are only ever added :)

You may be interested in the following:

Practical BFT: http://pmg.csail.mit.edu/papers/osdi99.pdf The Night Watch: https://www.usenix.org/system/files/1311_05-08_mickens.pdf

Generally the idea is to assume that there will be fewer than k failures out of the n nodes you have.

If you want to see a Buran without hiking through the desert for 3 days, you can go to Technik Museum Speyer [1] - they also have other great air&space related exhibits (notably including an Antonov An-22 and a retired Boeing 747-200).

[1] https://speyer.technik-museum.de/en/spaceshuttle-buran

This is no longer true in most of the USA (and many other countries) [1].

[1] https://en.wikipedia.org/wiki/The_long_tailpipe

Highways (tolls) tend to be far less profitable than rail systems (ticket sales). If the US didn't like government subsidies, we wouldn't have built all these highways.

Right, it's unclear however the context of the YouTube results. If they evaluated on links bottlenecked at the edge at 128Kbps, BBR isn't really competing with Cubic anywhere.

This isn't to say that BBR is "bad" - just that it's not mentioned what the "quality of experience metrics" are. They're obviously not getting better throughput, and the only way they can improve delay is if the edge buffer is overprovisioned (i.e. bufferbloat). In that case (edge bottleneck, relatively low BW), I'd be interested to see a comparison to Sprout[1].

[1] https://www.usenix.org/system/files/conference/nsdi13/nsdi13...

This is a delay-based scheme; it is unlikely to work well if competing with a drop-based aggressive scheme like TCP Cubic.

As a result, while BBR is fantastic for deployment e.g. in Google's private WAN, it's unclear how well it would do in the Internet, and initial experiments are not promising [1].

[1] http://www.ietf.org/mail-archive/web/tsvwg/current/msg14798....

They'd need to continue paying for their font license.

"The biggest factor is that we have recurring costs: the sync server and the licensing fees for Ideal Sans, Vesper’s typeface."

They'd need to continue paying for their font license.

Unlikely - the founding editor of The Intercept is Glenn Greenwald, one of the journalists who published the original Snowden stories.

Fair enough. Ultimately, HSR has far higher bandwidth than self-driving cars - density could be achieved either by efficient land use or by a feeder network (local transit or self-driving cars).

Presenting self-driving cars and HSR as mutually exclusive is a false dichotomy.

This would encourage sprawl-y and inefficient land use.

As vslira alluded: https://en.wikipedia.org/wiki/The_Restaurant_at_the_End_of_t...

Great map! Not sure if you are aware of http://www.openrailwaymap.org - although your project includes interesting snippets ("proposed for reopening", etc)

I imagine the data sources are proprietary; i.e. I as a layperson could not call some API to find the exact location of every ship in the world.

So I imagine Bloomberg must negotiate for access to this data, and that's what I'm really paying for? The actual terminal application is secondary.