namecast

Meh, I'll bite, since it's been posted....

1) This is from a Nanog talk back in 2006. Nearly a decade later, it's appropriate to ask 'how do I properly do IPv6 TCP anycast then?', and the answer is, sorry, it's a quirk of IPv4 that anycast ever worked in the first place. The presentation mentions that the authors plan to deal with IPv6 anycast by dying before IPv6 is implemented.

2) The presentation lays out how TCP anycast works across 3 points of presence. Try anycasting a prefix out of 70 PoP's and your mileage will vary. There are definitely applications where TCP anycast has the same MTBGRW (mean time before global routing weirdness) as, say, geo-aware DNS directing to regional load balancers, but with every new PoP announcing the same prefix you're taking on a non-linear (possibly exponential) decrease in MTBGRW.

3) The one bullet point that needs to be re-re-re-re-emphasized: 'Effective BGP communities from upstreams is key' [sic]. Yeah they are, and the diligence and cooperation of your upstream providers are the difference between a working anycast mesh and turning the global routing table into your own personal split brain hell.

TL,DR: Don't believe the FUD but let's not start hyping things either. I'm only aware of three ASN's announcing TCP anycast prefixes in the past decade since this presentation, and Edgecast was one of 'em. TCP anycast didn't take off, most likely because ASNs and IPv4 prefixes are way too scarce.

Just under 64 years ago, Nash's Ph.D dissertation 'Non-Cooperative Games' was published in the Annals of Mathematics.

The most legible copy I've found on the web is here: http://www.cs.upc.edu/~ia/nash51.pdf

Requesciat in pace.

Hi Erik!

I imagine you're going to be flooded with advice to grab a lawyer right quick, and that it's just smarter to change your domain name immediately. I'll offer a dissenting opinion, after having dealt with one too many wannabe copyright troll lawyers myself. Here's my response to the last barrister who tried something similar with a domain I own:

> Robert, > > We believe the statement on our page specifically disclaiming any > authorization by or affiliation with http://your.site is more than enough > to prevent any possible confusion between http://your.site and our product. > > From Graham Webb Intl v Emporium Drug Mart, 916 F.Supp. 909 (E.D. Ark > 1995): > > "The Court likewise rejects Graham Webb's argument that the warnings Drug > Emporium has posted disclaiming any affiliation with or authorization by > Graham Webb are ineffective and not a question properly resolved by > summary judgment. While it is true that the effectiveness of a > disclaimer in a Lanham Act case may generally be a question of fact, see > Home Box Office, Inc. v. Showtime/Movie Channel, Inc., 832 F.2d 1311, > 1315 (2nd Cir.1987), a disclaimer expressly declaring that the seller is > "not affiliated" with the owner of the trademark or is "not an > authorized distributor" of the trademark owner's products has been held > to be an effective means of preventing confusion in the minds of > consumers as to affiliation with the owner of the trademark. Matrix > Essentials, 756 F.Supp. at 282. As in Matrix Essentials, the only > reasonable conclusion in this case is that Drug Emporium's warnings to > consumers disclaiming any affiliation with or authorization by Graham > Webb effectively prevents likelihood of confusion in the minds of > consumers as to sponsorship or affiliation." > ". > > Please view the amended site and let us know if you disagree.

Long story short: read up on the Lanham Act and all it's particulars, talk to a lawyer if you have one on retainer (a trial attorney is expensive, but legal aid and advice is relatively speaking much cheaper), and most importantly, don't freak out - this guy's claim is so vague that he doesn't have a chance of shutting you down (note: IANAL and also not your lawyer, this is just my opinion - but I've had two separate side projects shaken down by wannabe copyright trolls, and I can at least confirm that my approach has worked for me in the past and stopped any potential legal action in it's tracks.)

Somewhere on your main page, perhaps in the footer, specify that you have absolutely no affiliation with his product. Notify him that you've updated your site to clear up any potential confusion between your product and his, and ask him if he can provide any proof of customers for Caseweb confusing Caserails for his product, so that you and your counsel can further evaluate his claims in hopes of reaching an amicable resolution. His response will be illuminating, I'm sure.

Good luck.

Hmm. I think the Bloomberg article oversimplified Tobin's work to the point where a) your interpretation of the article's claim is correct but b) definitely not in line with what Tobin claimed.

If Tobin were still alive, I think he would insist that intellectual property (read: code, patents, trademarks and software licenses) also be included. He didn't care about 'factories, machines and inventory'; he cared about 'replacement costs'. The author seems to have glossed over that bit for the sake of brevity and clarity, and in the process accidentally introduced a logic error, at least IMHO.

I've been using Godeps, which feels like a close equivalent - have a gander and see if it's useful:

https://github.com/tools/godep

Semver support was what got me using godep and I haven't looked back since (at least for larger projects).

This in turn means that you can't pull any docker images if they're on the public index, e.g:

:~ $ sudo docker pull debian Pulling repository debian 2015/03/20 23:42:18 Get https://index.docker.io/v1/repositories/debian/images: x509: certificate has expired or is not yet valid

Thankfully it's a Friday night, so I'm taking this as a hint to start my weekend :)

I found this paper useful for a side project I worked on a few months ago, one that made use of n-grams in a naive bayesian classifier:

http://arxiv.org/pdf/1305.6143v2.pdf

and the lead authors's github repos are:

https://github.com/vivekn/sentiment https://github.com/vivekn/sentiment-web

He's implemented 'negative bi-gram detection' (my phrasing, not his) with this function:

https://github.com/vivekn/sentiment/blob/master/info.py#L26-...

...which I found useful as a jumping off point. Good luck!

Everyone here is mentioning the "bean flatulence" effect that soaking apparently prevents. Adding my two cents: if you take the article's advice specifically for red kidney beans, you'll have bigger problems than gas.

http://www.foodreference.com/html/artredkidneybeanpoisoning....

Nausea, vomiting and diarrhea. Ugh.

This is discussed all the time - there's a running joke about how the 200 day moving average only works because everyone believes it does.

That said, there are so many different TA techniques / indicators / gurus that, for all but the most well known TA indicators (there are easily hundreds!), there simply aren't enough people trading on the signals at the same time for the same securities with enough volume for there to be a proper feedback loop.

If there was a repeatable, predictable feedback cycle, it follows that we'd all be charting it and trading off it (or backtesting with quant analysis to confirm the existence of the cycle, or having long conversations about nothing and convincing ourselves it was fundamental analysis, or whatever your preferred method of analysis is.)

Deleted my response when I saw this better one. I'll only add these links as they're good for background:

http://en.wikipedia.org/wiki/Slippage_(finance) http://en.wikipedia.org/wiki/Market_impact

You: >the interchange fees for Visa and Mastercard have a surcharge for rewards cards. >It is definitely not the case that the rewards for your card are free (to the merchant/consumer).

Me:

> And the rewards aren't paid for with the fees charged to the customer;

I don't see a conflict with these statements, do you?

Agreed. And the rewards aren't paid for with the fees charged to the customer; they're paid for with sweetheart deals between the payment processor and reward provider. There's nothing wrong with this even - it's biz dev 101.

As an example: Mastercard (let's say) offers American Airlines cobranding, marketing (in the form of newsletters and emails pushing me to use miles whenever i pay my bill) and service perks (read: lower transaction processing fees) in exchange for frequent flyer points (note - not even dollars, a point is some fraction of a dollar in terms of flight purchasing power) for tickets on flights that would otherwise probably have a seat empty. Nice seats on full flights cost more points, of course. I get these points if I use my card often enough.

I'm fine with this arrangement - both parties are gaining here, and maybe I as a customer get a nice perk occasionally when I finally have enough incidental points saved up to go on a flight - but none of us is under the impression that there's some one to one relationship between fees charged and amount of money paid for redeemable rewards, and I expect that in volume both parties are actually making money off of this arrangement, not sacrificing revenues.

There's also a feedback loop at work here - Mastercard pushes points for American Airlines, more people use American Airlines, more of them end up using the same airline regardless of points due to familiarity and customer stickiness, so Mastercard gets more AA transactions and more fees overall - even though they've dropped the per-transaction fee rate, the increased volume makes up for it...

Not that I don't think the PDF is awesome, but this link is actually to 'How Old Is The Shepherd', an essay on mathematics education in the U.S., dated 2006.

From my comment:

"...less stays in my pocket, which means that less will be available for me to spend on the local economy (though it should be benefiting us locals indirectly via taxes, or so goes the theory.)"

I'm not excluding it, just acknowledging that money paid to the city via taxation at best takes an indirect route to benefiting local actors.

Fully agreed. (And for the record, I'm absolutely not rationalizing their violations - just pointing out that "we're out $33 MM USD because lost tax revenue" is the wrong way to be looking at this. I think we should have some sort of safe harbour provision for people making X dollars a year off AirBNB, personally - once you're making more than the cost of your annual rent, time to pay some taxes.)

That's a weird way of looking at money, isn't it?

Hypothetically: I have X dollars in my pocket for a trip to NYC. I can spend it on my hotel + the taxes that the hotel pays, or to an AirBNB host. All things being equal, let's assume AirBNB is cheaper for me because hosts don't pay these taxes, which means I get to keep a larger % of my X.

If I go for the hotel, I'm paying a larger % of my X for the rental (some of which is allocated to taxes), and less stays in my pocket, which means that less will be available for me to spend on the local economy (though it should be benefiting us locals indirectly via taxes, or so goes the theory.)

I'm not going to somehow magically find more money to spend in NYC if I choose to go with the hotel - I'm just going to spend less money, because I have less money, because I've spent more on my hotel.

Your math assumes that somehow I have the exact same amount of money to spend whether or not I choose AirBNB or a hotel, and also that the same number of short-term tenants will visit NYC regardless of the cost they realize paying for AirBNB vs. a hotel - and that further that these short-term tenants will spend the same amount of money on goods and services regardless of their rental costs.

I'm going to go out on a limb and say that's unlikely. :)

....which works out to somewhere between one and two metrocard rides per city resident worth of annual lost tax revenue, and is only ~33% of the NYPD's annual settlement slush fund: http://www.reddit.com/r/news/comments/2j57fl/new_york_city_h... . This isn't buying us much in the way of services, I'm afraid.

Fellow NYC resident here, playing devils advocate: do you think the people renting these AirBNB units are contributing more or less than $33 million to the local economy by consuming local goods/services when they stay here?

I've done this. In a word: don't.

The digital nomad freelancer lifestyle is fine, but one of the things you need to pull it off is a steady base of consulting clients already available, preferably with long term project needs, who are ok with your remote schedule.

If you go the ad-hoc elance route you'll be competing with 10/hr workers who speak English as well as you in countries with much lower CoL who do this for a living while you're scrambling to deal with flight tickets, airbnb fees and wifi drama in foreign countries. Never mind the problems of getting compensated in a timely fashion.

The second time I took an extended working vacation, I had four clients with semi-steady requirements and actually had to turn down work so I could spend as much time on the beach as possible. Way less stressful than hustling for elance/odesk jobs on a daily basis.

TLDR; first you get the clients, then you start the travel. ditch elance and use craigslist / your personal network, the lead quality will be much higher.

Hrmm. Later on it is explained:

2.1. Values

   A JSON value MUST be an object, array, number, or string, or one of
   the following three literal names:

      false null true

... so what you're receiving is technically a valid JSON value according to the RFC, no?

(I am so sorry for being this pedantic - but that RFC is marked 'informational', it's not actually a standard so much as a suggestion, and even worse, RFC 7159 obsoletes it and is an IETF standards track document - check out http://tools.ietf.org/html/rfc7159. The ambiguity is definitely removed in the updated version.)

Hmm. Is root privs escalation part of shellshock? If not, then I think this is just going to try to yum update or apt-get update as the www-data user / nobody user / apache user / you get the idea.

Anyone who's running their web server as a user with enough privileges to run package installs unattended is probably in for a worse fate than an unexpected bash update, I imagine...

I'm in for #2. And no to #1, but I'm not sure we'd notice if we did.

Here's a theory that you might be able to chase down with AWS EC2 support folks:

Many, many EC2 instances are either scheduled to be created on the hour (e.g. by cloudformation/knife ec2/whatever) or are running cron jobs that run hourly;

EC2 provisioning tasks and cron jobs usually require connections to outside servers - package installs, apt-get updates, sending logs to s3, etc. - and that means looking up hostnames;

Lots of hostnames are being looked up on the hour as a result, and <resource X> is being exhausted hourly when a flood of lookups go to the DNS server.

Important caveat: resource X may not be the AWS internal DNS server itself! It can be the port it's connected to being saturated, or a particular uplink on a two port portchannel being flaky (and the flakiness is only evident when it's under high load>, or the elastic interface that is attached to the DNS server, or any one of another dozen things.

Are you seeing this behavior across multiple AZs and regions, or just one?

(This is just a theory, mind you, but I've seen this same behavior when managing other large DNS clusters, and it sounds like a good fit.)

Common: sadly, yes. Acceptable? Yikes no!

Important details: whose passwords are being logged? His own? Other co-workers? Management? Clients? Is management or anyone else for that matter aware of this? How are they being logged? As part of an application or some sort of active traffic monitoring?

Context is king, as in all things - this could be anything from a junior dev fresh out of college with some bad habits that he'll need to be coaxed out of, to a malicious employee logging client passwords to keep them on hand when he leaves so that he can sell to the highest bidder on some Russian cracker forum. It's probably not kosher no matter what the context is, but it's hard to offer advice on how to react to this without knowing more details.

You forgot the link to dnscat2 on GH - I hope you don't mind, it's in the presentation and totally the first thing I wanted to look at:

https://github.com/iagox86/dnscat2

I see shell/exec/upload/download payloads mentioned in the command protocol docs, very cool.

Chris: you need to identify yourself if you're going to push your viewpoint here. You're the only author of a controversial blog post that's pushing what I'll gently describe as an interesting theory - not a casual HN observer just bringing up some talking points. If I hadn't caught your CAP theorem quote ("solve the CAP theorem", wha?) and the Nanex reference, I would have missed this and not drilled down to your user details.

Next time, feel free to add a </disclaimer> of some sort.

I'm not an outsider unless you've got one intense No True Scotsmen definition of the word, and I'll leave it at that. Let's just agree to disagree, and I'll say that you are certainly entitled to your opinion. Thank God, it's a free country and a free market :) Good luck.

For now I'm going to offer gut feeling. Take this or leave it - I wrote two paragraphs here that essentially came down to an argument to an authority re: my personal experience and the opinions people who know who trade. That's shitty logic, so let's go with gut feeling for now...

I don't believe that the same specific bug has manifested itself across many many different HFT algorithms run by many different actors over a long period of time, in a way that loses money consistently for everyone involved whenever the bug is triggered, without ever being addressed by anyone.

To argue otherwise is contrary to my current understanding of software engineering best practices - imagine another industry where every service provider has the same bug manifest in the same way, across all their different software stacks - some running Java, some Python, some even with their own proprietary languages - and no one ever catches it even though it's losing money and it's occurence is easily identifiable on a time-series graph (so very easy to be matched up with all available logging data)? No one has the resources to throw a team of devs at this for 6 months to identify the bug, or they do and they're just willing to lose money and not make every last nickel they can? Not a single person is trying to reach for that lost money with a bug fix or a novel tweak to their own existing algo? For years?

I believe it's more likely that either the actors who are quote stuffing believe they are benefiting by tipping their hand early with false information, or they actually are benefiting.

It's hard to imagine how these actors could be benefiting; perhaps they believe that someone is watching their quotes in transit or has visibility into their quotes before trades are executed, and the quote-stuffers are trying to fake these malicious actors out?

The alternative scenario where quote-stuffers are not benefiting from their actions - or rather, that they aren't even operating under the irrational assumption that they are benefiting (because the quote stuffers could be stuffing intentionally but incorrectly) - seems much more implausible.

It seems to involve a whole lot more things going wrong in a very specific very atypical way,from a software development standpoint, with no one every interested in picking up the money they're dropping on the floor due to this bug when things go wrong, over the course of years, even though all the data to pinpoint the source of the bug is public, charted, and discussed openly.

The first scenario just requires a quote stuffer to hold a possibly incorrect belief about the other actors in the market. The second requires multiple specific distinct software development failures to line up like dominoes and stay lined up without anyone ever addressing their root causes.

But who knows :) <shrug> Trading is chaos, after all.

There is evidence that this sort of thing is already happening. Google 'quote stuffing'. There are those who say quote stuffing in HFT is a bug; my personal opinion is that it is done by design....

This isn't the law; it's a set of guidelines for federal agencies to follow. It'd be illegal if the department of health and human services or the FDA pulled this type of stunt, because they've voluntarily agreed not to do that by amending their rules and regulations to comply with the common rule that this blog post refers to (http://www.hhs.gov/ohrp/humansubjects/commonrule/)

Facebook and OKCupid are, at least not at the moment, part of the federal government.

1) Cheaper and way more fun! 2) I try to plan weekly. I purchase legumes and rice and non-perishables weekly or even bi-weekly, and proteins (meat, fish, chicken) on a 2-3 day cycle. 3) Protein + rice or pasta + veggies. Sometimes adding more protein and veg and cutting out the rice/pasta, depends on the dish.

A deeper dive than that? Chinese, Middle Eastern, Indian, Mexican... turns out a lot of cultures like to eat variations of chicken and rice.

4) I'd guess I go for the mediterranean diet? Though all that means is that I use olive oil and eat lots of nuts...

5) Soak your dry beans in the morning. You can store tons more if you buy them dry and soaking them is a lot less hassle if you do it before work - you'll have beans ready for dinner when you get home. (Chili, beans and rice, daal, three bean salad, vegetarian tacos, lentil soup are all suddenly much easier to make....)

Yep. The rest of it is, well, xml, and it's not going to be as clean looking as json , but why do I need to see the word json at the start and stop of every element? It could at least be abbreviated to just 'j'?

On the plus side I bet the output gzip's up rather nicely in transit assuming you're HTTP GET'ting this data....

From the department-of-redundancy-department....

The output syntax is even more glorious than you'd think:

<?xml version="1.0" encoding="UTF-8"?> <json:object xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx"> <json:string name="name">John Smith</json:string> <json:object name="address"> <json:string name="streetAddress">21 2nd Street</json:string> <json:string name="city">New York</json:string> <json:string name="state">NY</json:string> <json:number name="postalCode">10021</json:number> </json:object> <json:array name="phoneNumbers"> <json:string>212 555-1111</json:string> <json:string>212 555-2222</json:string> </json:array> <json:null name="additionalInfo" /> <json:boolean name="remote">false</json:boolean> <json:number name="height">62.4</json:number> <json:string name="ficoScore"> > 640</json:string> </json:object>

...and no, I'm not joking, and don't call me Shirley.