ak4g

From their FAQ, the change will only happen on routers produced after June of this year. So technically, the best time to buy a TP-Link router is right now!

You'd be wrong to pick a clear winner based on the numbers you have (which, apologies, I didn't check, also because Friday). The construction emissions will be astronomical - or maybe it'd be more appropriate to characterize them as "geological" :P.

It's far from obvious that CO2 emissions from excavating millions of tons of sand and earth would be dwarfed by the savings in the transit emissions of high-tonnage freight ships, which, unless I'm much mistaken, represent by far the most efficient means of transportation humanity has ever come up with.

OTOH, I assume there weren't many bulldozers in the mid 19th-century (I actually have no idea how suez was built). But, it's not really reasonable to just throw human power at something and declare it CO2-friendly.

And here's the bottom line. For better or for worse, externalities don't actually count. You can piss in the pool. People banding together and deciding otherwise - when their ancestors have gotten most of the pissing their hemisphere will ever need to do out of the way, and the rest of the world is still clawing their way out of abject poverty - is... maybe well-intentioned, but don't hold your breath. Poverty is really fucking awful. People on their way out of it will not tolerate if their governments try to put on the brakes because they watched an Al Gore movie. It's just not going to happen.

The good news is that the consequences likely aren't going to be too severe. We're not facing extinction (that many other species are is irrelevant, that ship sailed a long time ago). Florida goes away, sure. Indonesia loses a lot of it's land area. It's not going to happen overnight, people are not going to drown. They will move to higher ground. And at the end of it all, you have a world population that's not poor. That's a good trade, and I have every confidence in humanity's ability to manage whatever other consequences follow, we're pretty damn good at making tough decisions once we have something to lose. But right now, that's just not the case, except in the developed world.

Confirming. Vast majority of SQL isn't written by developers or engineers to begin with, it's not even close. I administer a few DBs almost entirely queried by other departments, they'll ask for performance help (which, to date, has always consisted of eyeballing EXPLAIN output and adding an index) when something gets too slow. This happens maybe once every quarter.

[2012]

Can you not tell from the running system what the currently-applied values are? That would address your concern. OTOH, if a nonsensical value without a comment (and, at a minimum, an indication of who made the change, when, and a reference to a bug/case/URL with the full details) is present, you have nothing to work with. Your only option is to change it and see if production breaks, and that is never an option until until production is already broken. At which point, you always discover that there are, in fact, multiple configuration values set that make no sense.

Barring release blockers discovered in RC1, yes, early January.

http://www.postgresql.org/message-id/20706.1450460549@sss.pg...

> where as Greenland (Denmark), which arguably has tougher laws is 26 on the list.

...which resulted from 11 - eleven! - homicides. It's an anomalous stat because Greenland is so sparsely populated. I can't help but feel you're making an incredibly dishonest argument.

The Denmark mainland is on the list too, which is worth mentioning. It's ranked #202, with 47 homicides. Sure, the population is that of a smallish US state - it'd be somewhere around the 20th most-populous state - but the US had twelve thousand murders in the year listed. The rate is more than four times higher. Not a single US state, as of 2010, had a lower murder rate than Denmark's 0.8/100k.

https://en.wikipedia.org/wiki/Gun_violence_in_the_United_Sta...

> You don't need a gun to kill someone, and I would wager most murder occurs through some sort of beating/strangulation.

Oh come on, google it. The stats are hardly tentative.

https://www.fbi.gov/about-us/cjis/ucr/crime-in-the-u.s/2014/...

> Information collected regarding types of weapons used in violent crime showed that firearms were used in 67.9 percent of the nation’s murders

The back years are posted here:

https://www.fbi.gov/about-us/cjis/ucr/crime-in-the-u.s

2014 wasn't a fluke. Two thirds of murders in the US are committed with guns.

> Gun control is more-or-less just a politically charged topic that is used to garner votes from the public based on emotional pleas.

At least we can agree on this. For some reason people react emotionally to violent crime, go figure. What's unfortunate is that it doesn't (and realistically never will) garner nearly enough votes to enact policies that could put a dent in the murders.

It could also be the case that they have monitoring systems on the host machines that would have reliably detected this issue being exploited, even before this specific vulnerability was discovered (or perhaps better to say, given the age of the bug, before being discovered by someone that disclosed it to Xen).

I was referring to the situation in the comment I was replying to, where a number of individuals have both valid and canary keys for unlocking an HSM, and the presence of a canary key when attempting to unlock causes the HSM to wipe it's protected key, but it can't be established which individual did not cooperate.

So the starting premise is that the device in question is already under the control of LE, a group of individuals has the ability to unlock the device (if they provide the correct keys), and they are being legally compelled to do so. In that specific situation, if anyone "defects" (provides the canary key), it's a crime, and everyone can go down for conspiracy, even if they themselves provided a valid key (which, in this scenario, is something we're assuming couldn't be proven anyway) and even if they never intended to break the law. That's the key part of a conspiracy prosecution - it doesn't matter which participant actually committed the crime, all the participants can be tried as if they were the "trigger-man".

TBH I'm not up for tracking all this down in the US legal code (got stuff to do, and IANAL), but here's the statute in the California penal code:

http://codes.findlaw.com/ca/penal-code/pen-sect-182.html

Note, in particular (heavily snipped for brevity/relevance):

> (a) If two or more persons conspire: [snip] (5) To commit any act injurious to the public health, to public morals, or to pervert or obstruct justice, or the due administration of the laws.

> They are punishable as follows: [snippity snippity snip....] When they conspire to commit any other felony, they shall be punishable in the same manner and to the same extent as is provided for the punishment of that felony.

There's no provision that the conspirators (or the prosecution) know which of their number actually committed the crime.

None of this would be relevant for HSMs on devices that aren't part of an investigation, or in general, any situation except one where a group of people are being legally compelled to enable access to evidence.

The bigger-picture point is just that using a split-key mechanism to give plausible deniability to each individual key-holder doesn't actually pose any problem for the criminal justice system. Legal authority would be pretty meaningless if it could be foiled by crypto gimmicks. IRL, it's "haha, very clever, now the HSM gets unlocked or all of you go down for obstruction."

edit: fixing formatting of the quoted blocks

If the HSM gets wiped, via whatever mechanism, you prosecute (successfully) everyone involved for obstruction of justice. At that point they've all participated in a criminal conspiracy to destroy evidence. The m'th hand doesn't have to know that the n'th hand gave the canary key; that changes nothing. You pre-arranged to allow yourself or a collaborator to commit a crime, and (at least) one of them did - everyone's guilty of the conspiracy charge, go directly to jail, do not pass go.

The law doesn't have to - and never does - respect clever CS constructions.

I disagree. Grew up in NC, spent a year and change in NYC, in SF for the last two years.

The biggest difference was the cost of a pack of cigarettes, when I still smoked. Now the biggest difference is the weather, which I gather varies quite a lot just within CA.

My coworkers are variously local and transplants like myself, and I wouldn't be able to tell except for being told.

One of the effects of the last half-century of mass media is the wholesale homogenization of American culture. I'm fine with this, and I wish our political structures would adapt accordingly; I happen to think American norms of 2015 are considerably better than North Carolina's norms circa 1965.

If you eliminate private prisons entirely and leave everything else alone, a pitifully small proportion of the people wronged by the criminal justice system would even notice, let alone receiving fair recompense. It's not so much that they "should not" be fought against, it's that it barely matters. It is simply poor allocation of attention.

Forest, trees, etc.

If you're using Chrome, have it authed to your google account, and have browsing history enabled in your sync settings, it's all here:

https://history.google.com/history/

I find it invaluable.

This. I'm more than willing to try different UNIXes, and I have. But when we're talking about running a business-critical database, it's a hard requirement that both myself and my teammates are able to maintain, keep patched, and generally competently administer the system. Trading an OS that my team has decades of combined experience running in production with for one where we collectively have zero production experience is a non-starter.

That compression ratio is one I'd love to have. PG's built-in data compression is limited to large values in a single row - if you have a hundred billion 100-byte tuples, TOAST isn't going to help.

The closest thing I know of to achieve something comparable with PG would be to use a data directory mounted on something with transparent filesystem-level compression (meaning, practically speaking, ZFS). This gives you the less-than-ideal choice of a not-mainline-linux filesystem (for your database's data directory, which is worth being nervous about) or running an OpenSolaris descendant, which is a big departure for plenty of people who have only ever run production dbs on Linux servers.

And in shells. Alt-u uppercases the word following the cursor with vanilla bash+readline everywhere I've tried. So the sequence would be to type "server_retry_timeout", Ctrl-a to jump to beginning of line, Alt-u-u-u to uppercase the next three words.

The wording was confusing for me too. At first reading I understood it as saying CVEs were no longer being issued for Acrobat, which definitely isn't the case. I assume the intended meaning was that Acrobat was first released in 1993[0], but the first CVE was CVE-1999-0001 (source: downloaded the raw dump from [1], ran grep -m1 CVE-....-0001).

But, I'm doubtful there would have been all that many CVEs issued for Acrobat from 1993-1998. There was only one CVE that mentioned "Acrobat" each year from 1999-2001, and three in 2002. The more recent years are the fun ones - but I have no idea whether that's a result of freshly-introduced exploitable bugs or just increased attention.

[0]: https://en.wikipedia.org/wiki/Adobe_Acrobat_version_history

[1]: https://cve.mitre.org/data/downloads/index.html

> I don't like wasting my time on things my computer could do for me.

So don't. Let the interpreter check profile.verified_email twice (horror of horrors!) and get back to your day job.

Even if there are no in-program side effects, removing a 2nd check for verified_email immediately before preparing and sending the email introduces a race condition: the user's email is verified, your first check runs, then you go talking to the DB and who knows what else for the last_interaction fetch/business logic, meanwhile, user changes their email address, and now profile.verified_email is false. By skipping your 2nd if check, you send your email to an address that is still pending verification. This assumes that .verified_email is a property that talks to the DB, and while it'd be better style in that case to make it an .is_verified_email() method to make that clear, doing so is a plausible and not-incorrect use of properties.

It's not worth your (employer's) time to even check if that's the case. Leave the non-broken code as-is and return to your regular programming.

And not just the GPL, but the AGPL. That one caught me by surprise. Does this mean there is going to be a MySQL-style dual-licensing situation in the future? (or is this already the case?)

Esper is really curious. I looked at it while getting a feel for the general landscape of streaming data tools in late 2013 - to be clear, it was a very cursory look, on the timescale of a few hours at most. I quote what my final take-away was at the time:

> Seems good but... such a weird project. Codehaus, svn, not high activity, but consistent, stable releases for five years. Maybe just not the kind of thing webdevs get into? Not sure if that's a strike against or not.

With the demise of Codehaus it looks like they've moved to github:

https://github.com/espertechinc/esper

But oddly they don't seem to have migrated their svn history, and the README implies they don't plan to... I certainly hope they didn't lose it when Codehaus shut down. There was, as noted, already 9 years worth of code changes in that repo. That would be unfortunate.

Um, this is the postgres article:

https://aphyr.com/posts/282-call-me-maybe-postgres

There were no acknowledged writes lost. The only unacked-but-successful writes resulted from a connection while a commit ack was in-flight. That doesn't qualify as a data-consistency error, it means the client has to check if the data is present after reconnecting.

But in no cases would the client reconnect to find that there were acknowledged-as-committed records that were missing or stale. In no cases would the client find that responded-as-rolled-back data was actually committed. This is very, very different than what is seen with MongoDB.

Wow. Can you provide a URL?

For those who haven't seen it:

http://www.classnamer.com/

The Spring-flavored generator has an extra DesignPatternFactoryMixin.

http://www.classnamer.com/index.html?generator=spring

the json type just stores the string value passed to it, but only the final value is available to the JSON-aware operators.

  mydb=# select
      ('{"foo": 1, "foo": 2}'::jsonb)->'foo' jsonb_foo,
      ('{"foo": 1, "foo": 2}'::json)->'foo'  json_foo;
  jsonb_foo|2
  json_foo|2

Bup satisfies both.

https://github.com/bup/bup

But the frontend is kinda bare-bones. In many cases, it's git.

I have heard that attic is similar but more fleshed-out. But I have not tried it myself.

https://github.com/jborg/attic