state_machine

FWIW, CockroachDB doesn't claim to beat CAP: https://www.cockroachlabs.com/blog/limits-of-the-cap-theorem

Yeah, that's fair. If I have to take LIRR, I'll generally use Atlantic and switch at Jamaica if needed -- anything to avoid Penn.

it takes longer to load a train with assigned seating -- that's why say, Amtrak might do it, but commuter rail trains, that at peak run minutes apart and want to minimize dwell-times at highly contended platforms, optimize for loading speed.

I've only done much less hellish Grand Central version, and I think Metro North publishes track assignments much earlier.

That said though, just imagine how much worse it would be if that mass rush was between platforms, fighting opposing traffic, instead of just from a (mostly) open waiting area.

I can see why the MTA wouldn't want you telling people to go to a track before it is actually assigned -- if the train ends up on a different track, now you need to get all those people back up, off that platform an on to the new one, clogging stairs that that people who actually wanted that platform might be trying to use too. Obviously it would be nice to assign tracks earlier, so that people can head straight to the right platform, but sending people to potentially the wrong platform seems even worse.

EDIT: Penn is extremely platform/track constrained -- NJ Transit, LIRR and Amtrak are all sharing a fixed number of platforms, some of which are too short.

To maximize platform utilization, they have to wait until the last minute to finalize track assignments -- if you reserve one too early and the train ends up late, you're wasting an empty platform. Once you send a horde of people to a platform, moving them to a different one is a challenge (stairs/bottlenecks, communication, etc).

I did not realize the physiological effects would be as severe:

The fraction of carbon dioxide is growing: It just crossed 400 parts per million, and high-end estimates extrapolating from current trends suggest it will hit 1,000 ppm by 2100. At that concentration, compared to the air we breathe now, human cognitive ability declines by 21 percent.

In case anyone is interested in even more of the technical specifics, the original design RFC might be interesting too: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...

One of the challenges for us in implementing something like LISTEN/NOTIFY comes from our distributed nature: since a table is likely broken up across many nodes, you somehow need to aggregate changes from all of them back into a single change feed wherever the listener is, and in such a way that it doesn't create a single point of failure.

Yes, change feeds (and triggers) are on the roadmap (though not yet in active development).

We're still working on integration with other monitoring systems, but the one we've tested the most and documented is prometheus: https://www.cockroachlabs.com/docs/monitor-cockroachdb-with-...

Additionally, you can get some of the same status info on the dashboard using the `node status` command (https://www.cockroachlabs.com/docs/view-node-details.html).

Whoops, sorry about that. If you're looking for more on how it works (rocksdb, raft, distributed transactions across multiple raft groups, etc), you might find the design doc interesting: https://github.com/cockroachdb/cockroach/blob/master/docs/de...

[cockroachdb employee]

Short answer: no.

Long answer: at their closest earth and mars are about 54m km apart, at the furthest it's over 400, with an average of around 225m km, so theoretical latency is varies between 4 and 24 minutes.

CockroachDB uses synchronous replication via raft, and that latency would cause problems as would some other setting like our window sizes and their interaction with timeouts.

The 14 issues tagged 1.7.1:

  net: retry DNS lookups before failure?
  io: endless loop in MultiReader in Go 1.7
  path/filepath: EvalSymlinks is broken for relative paths on Windows
  net/http/httputil: Proxy terminates HTTP/2 stream before reading response body.
  hash/crc32: wrong output for unaligned input on s390x
  cmd/compile: incorrect assignment to uint64 via pointer converted to *uint16 (new in 1.7)
  doc: deprecation message for Transport.CancelRequest is not correct Documentation
  compress/zlib: Writer appears to ignore underlying writer errors at times.
  net: NATs client can't connect to server when client built with go1.7: "dial tcp: no suitable address found"
  doc: go1.7 release notes include typo for TLSConfig.NextProtos Documentation
  reflect: ChanOf makes "han" types instead of "chan" types
  x/mobile: Binding go mobile framework on iOS 9 with golang1.7rc6 crash when call debug.FreeOSMemory()
  net/http: nil pointer dereference in closeConnIfStillIdle
  website: retina favicon Suggested

Personally I value (lack of) variance much more than absolute duration: I can easily plan around a either a 19 or 22 minute commute as long as that's consistent -- it's the needing to allow for 20-40 (looking at you, MUNI) that made planning hard, and that I'll pay a premium to avoid.

The previous post in this series toured the `io` package: https://medium.com/@benbjohnson/go-walkthrough-io-package-8a...

[engineer at cockroach]

How high you can set it depends on your access patterns -- there is some overhead to iterating though MVCC revisions during reads, in addition to the on-disk space you mention.

If your workload involves frequent writes to the same rows, GCing some of those revisions sooner would have a greater impact, whereas if you have a write-light workload, or if your writes are spread over rows such that a given row doesn't doesn't see frequent repeated updates, then you could probably use much a higher GC threshold with minimal overhead.

[engineer at cockroach]

Basically, yes, all keys the KV, including the index entries, include a timestamp suffix.

Repeated edits to the same value will accumulate MVCC revisions until they are GCed, and those will be iterated over during access, so, as you point out, a use-case like yours would likely benefit from shorter a GC cutoff and GC _is_ configurable in cockroach.

More details on the program: https://www.edf.org/climate/methanemaps and the other cities they've mapped: https://www.edf.org/climate/methanemaps/city-snapshots

More info on the issue: http://www.openssh.com/txt/release-7.1p2

"experimental support for resuming SSH-connections (roaming) ... could be tricked by a malicious server into leaking ... private client user keys."

How does this work, only if he stops can the process continue?

The senate isn't actually discussing or voting on the USA Freedom Act today (floor schedule is for discussions of an unrelated trade bill) and this discussion can be cut off tomorrow anyway, so this isn't technically a filibuster (yet).

“Aurora" is already the name of a cloud infrastructure management product, an open-souce apache project no less: http://aurora.incubator.apache.org/

Using an existing name for a product in a similar space is just confusing and hurts everyone.

In the US, federal law bars employers from forbidding internal discussions of salary and benefits.

http://www.twc.state.tx.us/news/efte/salary_discussions.html

systemd doesn't care what it is starting, so you can hand it a shell script just as easily as anything else.

See item #4 on http://0pointer.de/blog/projects/the-biggest-myths.html

Some highlights from the FAQ: "Instead of charging the device from pc with electricity you will charge our device ( WiFiEX) with internet from your home-wifi."

also: "And yes , we will also try to cover the whole planet with satellites for sure"

This doesn't appear to support TCompactProtocol, which in the official Python implementation uses a different byte-order on the wire than the official implementation in every other language.

https://issues.apache.org/jira/browse/THRIFT-1639

Sure, the context of the thread is that ruby-core is reluctant to start changing OpenSSL defaults because Security is Hard, the ruby team is volunteers who might not have expert-level crypto understanding, and and you risk doing more harm than good if you mess with crypto when you do not know what you're doing, so they'd rather leave OpenSSL's defaults alone, and let OpenSSL, written and reviewed by security focused people, fix any issues (I think this is a fair summary?).

While these are valid concerns, you can't wholly pass the buck to OpenSSL and to people installing a new version of OpenSSL and re-linking ruby against that -- ruby project should should always ship the most secure ruby possible, all the time.

Newer OpenSSL has already changed these defaults, smart people who know what they are doing have already agreed and documented that this is a good idea, and ruby is only hurting their users by dodging responsibility.

edit: spelling.

"Ruby is not a project for security."

That's from ruby-core. That's a frightening attitude for a project to take.

As one of OP's direct reports, I can attest to this system working really well and, at least for me, being a much faster and more comfortable experience than doing a written peer review.

Protecting the OS does protect you: stealing my data/cookies today is different than installing OS level backdoor / keylogger and stealing my bank password, tax prep, etc next month/year/etc.

Anyone have suggestions for a good, cheap-ish, USB DAC? I use my rpi for Airplay but the onboard DAC is not the best.