Link to Original Source
If you got $500 from writing a tech article, would you rather pay $200 of it in taxes or $2?
Also, doesn't Apple have a duty to shareholders to cough up as little in taxes as legally possible?
...in Another Bloody Century. He kind of pooh-poohs it as some of the other commenters here have done, saying that it plays a small part but is mostly an annoyance.
> As a former Marine I'm afraid I'm going to have to "liberate" you
I think the nomenclature these days is that he's a target that needs to be "serviced".
Speaking of avoiding downtime, the recently published Web Operations is excellent. Lots of good anecdotes, advice, and procedures to make things better (RCA, 5 whys, etc). I've been doing devops stuff for a while and have picked up a lot from this book.
Hm, interesting, I haven't observed that. FWIW, I don't think you need to lock the tables if you're using innodb - you can dump the db with the 'single-transaction' option. I don't deny your experience... but I dunno.
Now, I have had problems with replication halting in odd ways and having to skip errors. That's annoying, indeed.
Anyhow, I'll happily leave MySQL behind and move to PostgreSQL any chance I get.
Sure, yup, Slony and WAL shipping and whatnot. But I think having it built in makes a big difference...
> We started using PostgreSQL back when Sun bought MySQL
Right on. And PostgreSQL is about to remove one of the last big barriers for using it - streaming replication is coming in 9.0. Huzzah! I was just listening to a "Rails on PostgreSQL" talk from Pivotal Labs and that was cited as one of the few places where MySQL was ahead... not for long...
...and Google knows it. The government is flourishing, huzzah!
Yeah, ANTLR's great for that... and it would be a pile of work to get JavaCC to output lexers and parsers in languages other than Java... sigh.
> ANTLR, which is a far superior alternative to lex/flex yacc/bison IMHO.
Another alternative is JavaCC, which (shameless plug!) I document in great detail in my book Generating Parsers with JavaCC.
...right here. One commenter had some interesting things to say about "quote stuffing":
Just because the folks at Nanex can't figure out why a system was entering orders and cancelling them frequently does not mean that they were being "stuffed" to thwart competitor's systems.
The logic on the machines placing those orders (HFT or otherwise) may have been severely screwed up by the craziness of 5/6 and the latency on data feeds - but there is no way to profit by spewing lots of quotes.
First, everyone in the HFT space has plenty of headroom to process the full raw feeds (rather than the SIAC consolidated feeds Nanex is looking at). A few thousand extra quotes per second is not meaningful to systems that can process millions of quotes per second.
More to the point though, each exchange gives each participant a port on which to send their order flow. Those ports are rate limited. That means that if you send thousands of spurious quotes that are not going to hit, the only harm you cause is to your own trading strategies, since when you finally did want to execute a trade at a price where the execution was remotely likely, you are going to have that order queue behind all of your other orders on the same port.
So it might not be the big advantage that Nanex sees it as.
Yup, I used pg_migrator for the last RubyForge upgrade, very handy!