bd_at_rivenhill

This is a common misconception. OPEC isn't unified and the Saudi strategy is far more ambitious; they aren't trying to choke out the frackers and other high-price producers, they're trying to choke out the environmentalists. 5 years of prices at this level will put millions more SUVs on US highways and will make maintenance of existing oil-fired infrastructure appear more economical than investment in new clean energy alternatives (solar, wind, etc as you said). Additionally, they get to kick the Iranians in the nuts, which is in line with their stategic goals, squeeze the Russians and the Venezualans, which makes them more popular with the US government which will already be happy about the economic boost from low prices, and yes, they would hopefully be one of the strongest producers standing when oil prices rise again.

They can be described in a single sentence, but detecting the difference between spoofing and legitimate activity can be very difficult, especially when some participants are trading cross-border and cross-asset; their orders are reacting to events which are not local to the exchange where they occur and legitimately change at a high rate because they are being affected by many different factors.

I know that ISE had some sort of automatic cancellation feature from the beginning or very close to the beginning, so not sure if PHLX was the originator of this idea. Also, nearly all electronic options exchanges have a "mass quote" feature that allows changes in prices over a large number instruments at the same time. I would expect that this feature is available on every US exchange and only a few overseas exchanges lack it, and managing the generation of mass quotes vs exchange message rate limits is one of the more complicated parts of designing option quoting systems. Finally, there is also a "cancel by underlying" feature that cancels all options on a specific underlying; if it is the case that the mass quote doesn't allow quotes to be cancelled (i.e. modified to 0 size), then the usual approach is to cancel by underlying and then immediately requote at the new price level.

I've worked in automated option market making in the past; if I were on a jury hearing this case, there's no way I would convict these guys of spoofing. They are taking advantage of a feature built in to the market for purposes similar to this: hiding your intentions. The only people who could realistically be damaged by this are professionals, retail customers will either benefit from the tiny bit of extra liquidity added by the 1 or won't be adversely affected by the hidden AON orders on the other side. The algo traders who complained to the SEC should be embarrassed at doing so; they should have been burned on a couple of trades, figured out what they were doing wrong and fixed their code to compensate. Blindly stepping up your quote or order for size on a 1 lot in order to capture rebate is just foolish and anyone who can make money off you for doing so should be entitled to it.

(not so) Detailed Analysis of a Trade: lots of detail is lost here, you can see the problems start right at the beginning with this quote: "The 2nd column is the timestamp of the event - this is from CQS/CTA, the consolidated quote and trade SIP (Securities Information Processor)". Looks like they are determined to show only timestamps from the consolidated tape, which has been pretty much useless as a source of information for about 10 years or more. They omit the firm's receive timestamp for each message and also details of the trade execution reports received from Goldman Sigma X, which they are claiming as the source of information leakage that causes this order to be faded. Regarding Phantom Liquidity, they ask the pertinent question directly in the article: "what kind of liquidity"? but they get the wrong answer. The liquidity where you can dump a 20,000 share order directly on a market with tight spreads and not get faded does not exist now and never existed in the past; spreads were wider back in the day where you could have a hope of doing this. If you want to move large size with low slippage, you need to ship it to someone with good algorithms or spend the money to develop those algorithms yourself (along with the required technical infrastructure such as direct feeds, etc); those are really the only options available.

Author has things reversed. Automation is affecting jobs with higher wages and higher productivity first, turning those markets into winner take all or eliminating labor altogether. The remaining workers are forced to crowd into lower productivity jobs and work longer hours for lower wages to make ends meet. Automation appears to cause lower overall productivity, but the actual effect will be quite obvious when the cost of automation is low enough that it comes for all the low wage workers.

You have to assume that the brokerage must retain and report the information, otherwise you can lie all you want about your cost basis without any way for the IRS to cross check at scale. If caught in an audit, you can just claim a bookkeeping error; probably not what they want given the lengths they've gone to in order to fill common holes (c.f. the whole "provide a 1099 to pretty much everyone you have a financial relationship with" pile of bullshit).

Frankly, we ended up with the cure AND the disease. Special purpose entities were used by Enron to muddy up its accounting so nobody could tell that it was doing stupid deals to hit its quarterly numbers and wasn't really making any money, and then they were used again during the real estate bubble on an even wider scale to mask the risks of the mortgage origination machine (with convenient help from the bone-headedness of the ratings agencies). So the "cure" really didn't seem to help the disease very much.

Instead of dumping a bunch of new reporting requirements on everybody, it should be pretty simple: increase the amount of equity capital that needs to be held against debt (i.e. force a decrease in leverage) and change the accounting rules so shit that could blow up the company by some mechanism has to show up on the balance sheet. However, the current system creates a lot more work for lawyers, accountants and bureaucrats so it seems unlikely to be simplified anytime soon.

I use a Happy Hacker keyboard in a customized emacs environment, but I'm pretty much Linux only, so no issues with transition between laptop and desktop, although I do have an older Thinkpad and the layout is slightly different, but not enough to screw me up. I cut my teeth on Sun Sparcs, and haven't found a layout that I like better. In fact, I actually have two keyboards; one for home and one for work, and the latter has a lot of "mileage" on it because it regularly travelled with me from New York to Hong Kong.

I think we will start to see less use of GCs in mobile going forward, especially now that Apple has deprecated GC in favor of automatic reference counting. The issues caused by the interaction between the memory hierarchy and the fragmentation that is naturally introduced by GC are difficult to measure, but nevertheless an important component of performance.

"You're never going to see a power tool or a tractor or whatever designed in OpenSCAD."

I beg to differ on this, I've been using OpenSCAD for a couple of years now, and the two most complicated designs I have done were for a dual drive robot base and a simple 3-axis CNC machine. Many of the parts were COTS (which I built modules for) and the rest were designed for these projects, including some parts which were sent directly to my 3D printer. In doing this, I've been developing various functions and modules that simplify common operations such as attaching two separate parts and using difference to form a free fit hole for a specific type of screw. I find this to be much easier than clicking on dimensions in a sketch, but this is because I have all of the mental habits developed by learning to build complex software.

I've met some of the guys from Ufora and seen a demo of their technology; very impressive. I've always been leery of the claim that you can create smart software to make the problems of writing parallel code magically disappear, but what they've done has made me rethink some beliefs related to working with big data at scale. Definitely a company to keep an eye on.

I believe 100% in proactive error prevention as a means of building robust programs but, as you say, there are failures that cannot be handled this way; when the kernel fails (as in this case) or when the hardware fails (e.g. spontaneous bit flip error in the memory when not using ECC/ECM) there is no way to handle this. Given that this is the case, you must also make the system robust, and one element of that is being disciplined about communicating program state via mechanisms such as heartbeats. This is not a magic bullet, but produces much better results than a lackadaisical approach. I think that as much or more effort should be spent on system robustness as program robustness because much of the error handling code I've seen at the program logic level is overly complicated and under-tested; when in doubt, call abort() and let the overall system sort things out (and design your system so that this approach works, check out Netflix's Chaos Monkey).

All kinds of badness here. Bug #2 really reduces the level of comfort I would have with using ZooKeeper as a tool.

First of all, the default Java policy of terminating the thread, instead of the process, when a runtime exception is not handled is fully boneheaded and the first thing you should always do in a server program is to set a default uncaught exception handler which kills the program. Much better to flame out spectacularly than to limp along with your fingers crossed hoping for the best, as this bug amply demonstrates.

On the heels of that, there's this: "Unfortunately, that means the heartbeat mechanisms would continue to run as well, deceiving the followers into thinking that the leader is healthy." Major rookie mistake here; the heartbeat should be generated by the same code (e.g. polling loop) which does the actual work, or should be conditioned on the progress of such work. There's no indication that ZooKeeper is bad enough to have a separate thread whose only responsibility is to periodically generate the heartbeat (a shockingly common implementation choice), but it is clearly not monitoring the health of the program effectively.

Suffering a kernel level bug is outside the control of a program, but this demonstrates a lack of diligence or experience in applying the appropriate safety mechanisms to construct a properly functioning component of a distributed system.