Hacker Newsnew | past | comments | ask | show | jobs | submit | more state_machine's commentslogin

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


Thanks for pointing this out. I understand that EDF was the driving force behind this initiative, but the fact that the sensors were mounted on Google cars seems to have diverted attention from that fact.

There's a growing effort to monitor CO2, CH4, and CO at very fine spatial scales, and to do inverse modeling to infer emission rates ("fluxes") from the snapshots. (E.g., https://megacities.jpl.nasa.gov/portal/)


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


There's a provision in the TPP (which is this 'unrelated trade bill' you speak of) that allows for extension of 215 of the USA PATRIOT Act. It's not a filibuster; but it's definitely related to the TPP.


Wait, what, really? This is my number 1 thing about Congress that grinds my gears. Attach little bits of (significant) legislation, many times at the last minute, that have absolutely no relation to the bill's topic. At least this time Wyden and Rand Paul are doing something about it.


Sadly, this happens all the time. And it does it in really sneaky ways, things like "Strike paragraph 1a from USC 1234 that says 'June 30, 2015' and replace with 'June 30, 2019'". That way if you're searching through the bill, you not only need to know what those other bills are, but those specific paragraphs are; and there's no way from just reading a bill what the intent is.


It's like a really slow, broken, expensive, rigged version of Github.


Just as newspapers, radio and television, etc. have brought increased transparency and clarity to the inner-workings of government, likewise we should definitely be using even more recently developed tools like branching, revision histories, hyperlinks and various diffing algorithms to elucidate exactly what has been or is being proposed or adopted and by whom.


It should be a point of procedure that all bills be voted in page by page.


It should be a point of procedure that all bills do exactly one thing. Small and easily reviewable commits, please; software engineers learned this long ago.

Page-by-page of a single bill doesn't work, though; see also attempts at a "line-item veto". For the most obvious failure mode, consider a bill that replaces one tax with another and a veto on the removal of the old tax. Or consider a bill that adds a tax and a service funded by that tax, and a veto on the service but not the tax.


Or, maybe each congressperson casts a tri-state vote on each line item (bill must contain this, bill must not contain this, or no opinion). Congress then runs a SAT solver to determine if there is any combination of line items that pass the criteria given by a majority of congresspeople. If none exist, the bill fails. If multiple candidate bills succeed, each congressperson is allowed to nominate one candidate bill for consideration, and the legislative body then votes on the best candidate via approval voting.


Well, "one thing" isn't a coherent concept. That's the same problem that the line-item veto has.

It's a fuzzy ideal that you can try to stay close to, but it can't be a point of procedure because it has no actual definition.


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


To be fair, I just searched for "aurora software" and "aurora open source" and got nothing for that project on the first page of results.

A lot of the good names are already taken; there's going to be overlap, and they're very different products.


Name-clashing with an Apache project really surprises me. Also, consider the fact that Aurora stems from Mesos, which supposedly Amazon (cloud; although DB people are doing this one) folks have to know.


Also, the first thing I thought of when I saw the word Aurora was the 2012 shooting in Colorado. That's sad that the word is associated with that, but also a facet of the naming consideration.


Michael Stonebraker created a database called Aurora more than 10 years ago.

http://cs.brown.edu/research/aurora/


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


Interesting - I've worked at US companies with policies just like the one at the top of that page. I had no clue they were illegal. Hard to enforce was obvious though, and I do remember breaking such a policy at least once.


There are policies that the company can't disclose your salary, but I think that people just assume the existence of a (highly illegal) policy that says that you can't discuss your own salary. I make a point of telling anybody who wants to know, and when the specific number is relevant to a conversation (not very often) to not hesitate in giving it.

It's the least I can do for fellow workers, and I know that my salary is no measure of my worth.


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: