gxti

This is already on the front page here: http://news.ycombinator.com/item?id=1490284

And a follow-up here: http://news.ycombinator.com/item?id=1492344

Every time someone brings up "exclusionary language" or calls a word sexist, I roll my eyes and long for feminists to collectively declare victory and leave the field so humanity as a whole can move on.

Young women aren't put off by the phrase "founding fathers", not even the tiniest bit. Maybe the root cause of the gender imbalance is biological or maybe it's political, but the one thing I'm certain of is that pieces like this only serve to reinforce perceptions of inequality. Do something positive instead -- get kids involved in engineering and computer science.

Bigger numbers take much longer to crunch.

It's a debugging feature. It scratched a particular itch that a particular developer had at the time that they wrote it. If it weren't there at all, would this blog post still have been written?

txpostgres implements psycopg's async interface for Twisted, which uses a similar eventloop/callback model: http://git.wulczer.org/?p=txpostgres.git

Not that "unnecessarily complicated", but Twisted is a lot more mature with respect to coding patterns and has formalized callbacks into a Deferred object that makes it much easier to understand.

Trees do dissolve. Forest fires are the most elegant way -- the reaction liberates much of the carbon and all of the oxygen into gasses including CO2, and the cycle is complete.

Bacteria that break down the rotting remains of a dead tree also consume the energy stored in the cellulose and release gasses like carbon dioxide and methane. At some point the remains don't contain bonds with easily freed energy and you have regular old dirt. If they had a way to break down the dirt further they would, but the cost is too high.

Bah! Not only is slow shipping disturbingly cheap, but it's like Christmas when it finally shows up because you completely forgot that you'd bought anything!

FUN FACT: (and you probably already know this but many do not): "fsync = off" is postgresql-ese for "please destroy all my data". Don't do it. Ever. The 9.0 docs are finally improving the language here to indicate that you must not set fsync off if you value your job.

Setting "synchronous_commit = off" nets you 99.9% of the performance improvement without the possibility of corrupting your entire database.

Thanks for correcting me, I've never used google apps so I'd never noticed you could register domains there. Personally I'd still register my own domains elsewhere as I've had bad experiences with combined registration and hosting, and even the almighty Google has been known to partake in shenanigans.

In any case I'm pretty sure you don't even have to be a registrar to get lists of newly registered domains, not that it matters because the rest of my post addresses why registration has nothing to do with this.

To clarify:

* Google isn't a domain registrar. If they were then one would hope that google.com would be registered under them, not markmonitor.com (a popular corporate registrar)

* The server hostname is a subdomain of amazonaws.com and doesn't require registration.

* In fact, the entire name is autogenerated from the IP address using a simple substitution rule.

* I'm not sure how Google finds these, because their own "what links here" doesn't turn anything up.

* Side note: while searching for backlinks in Google, I noticed that this article seems to have been copypasta'd to a dozen other blogs. That's SEO, baby!

EDIT: Damnit HN, you look like reddit, why can't you use a sane text preprocessor like reddit?

Loads instantly here, but is completely blank with javascript blocked. That's how you know he's a true professional.

If anyone is still reading this thread, I made a chart overnight using a better corpus:

http://partiallystapled.com/~gxti/misc/2010/06/25-shootout.p...

http://partiallystapled.com/~gxti/misc/2010/06/25-linux-2.6....

It segfaulted at the end, after taking 7m28s. I don't know how big the result was because it got truncated to 35 bytes.

I don't think they mean that one exchange was DoSing another.

Quotes within a single exchange are disseminated immediately to all interested parties -- if one party was spamming thousands of quotes at a stock, that stream would be repeated for everyone with a feed from that exchange. There's no way to tell which party is sending it, so the only thing you can measure is the quantity being sent by the exchange. Thus it is technically accurate to say that "one exchange was sending an extremely high number of quotes". It's in the exchange's best interest to disseminate quotes as quickly as possible in order to attract order flow and thus collect fees.

On the other hand, inter-exchange feeds are federally mandated and used primarily to comply with Regulation NMS rules that prevent trades from executing at a price inferior to the NBBO (national best bid/offer). In other words, if I send a buy order to NYSE but NASDAQ has a lower price, NYSE is required to either reject the order or route it to NASDAQ for a fee (it's up to the customer which method is used). It's not necessary to send 5000 quotes per second to another exchange because the primary motivation is compliance. Generally, institutions will send their orders directly to the exchange with the best price in order to avoid the extra fee for having it routed by the exchange.

I may be way off on the inter-exchange feeds as I am not a professional, but there are undoubtedly many here who are so please correct me.

The scary part was that you could watch it unfold: http://partiallystapled.com/~gxti/charts/2010/05/06-spread.p...

When you can see the spread like that then something has gone terribly wrong. As I read it, that spread is between NYSE on the bottom and the rest of the market on the top.

I've found that on many types of data, xz -2 is twice as fast and compresses better than gzip -9. Of course gzip -1 kicks the pants off xz but there's absolutely no reason to use gzip at its higher levels, nor to use bzip2 at all. And if you want fast, LZO does it better -- the lzop tool provides a typical unix compress interface.

Using 50MiB from a tarball I had lying around, best of 3:

     prog    time(s)   size(%)
    gzip  -1  1.703    38.7
    gzip  -9 14.670    35.1    (worse than xz -1)
    bzip2 -1  7.714    34.0
    bzip2 -9  8.035    31.4    (worse than xz -1)
    xz    -1  6.278    31.3
    xz    -9 42.445    22.7    (best compression)
    lzop  -1  0.670    46.1    (fastest)
    lzop  -9 18.144    38.0

Is Yahoo actually a registrar, or did they simply register the domain on his behalf? If the former then yes they would be compelled to let him transfer it elsewhere. If the latter then Yahoo technically owns the domain and can do with it as they please.

Always, always control your own domain registration and do so at a reputable registrar. Don't use your webhost and don't use a company that does anything but domain services.

Companies that do registration on the side or as a bonus to hosting packages tend to do things like automatically re-register your domain even after billing fails without notifying you, then submit the whole $20 to a bill collector without notifying you, keep the domain operating for an extra 6 months so you have no idea that anything went wrong, but kill it after said 6 months with another 6 months left on the registration with no way to make any changes to the domain because they refer any support requests to the bill collector -- because this definitely did not happen to me and it definitely didn't happen at a company called 1&1 Internet Inc. because that would be totally absurd. cough.

Agreed, I've been using Consolas on linux for quite a while and can find no fault with it.

thinkorswim is an excellent broker for this specifically -- they not only have an excellent options trading platform, but you can sign up for free and papertrade with a 15m delay. It's all Java-based so it works great on Linux.

That said, don't force it. It takes talent and dedication to beat the market. You will probably fail. I lost quite a bit of money trading single options, but I never traded money I needed and never borrowed money that wasn't closely guarded so I came out unscathed. I still suck but without a doubt a few people reading this post can succeed.

> The whole system can become unresponsive from the load of a single process.

Two cores is great if you have only one CPU-hogging thread, but as soon as a multithreaded app gets thrown in you have the same problem again -- more runnable threads than CPUs. If your dual core CPU doesn't "become unresponsive" when you start a 2+-threaded task then your single core problem is probably not processor-related.

On the other hand, my dual-core laptop regularly screeches to a halt when certain IO loads get involved, esp. vmware, due to poor filesystem design (ext3/ext4). I've switched to data=writeback, sacrificing some integrity for responsiveness, but ultimately I think new filesystems like btrfs will go a long way towards improving response times.

There's definitely a significant confusion of terminology here. FTA:

> The syntax itself is unimportant (some languages use foreach, others for i in l, etc…), what really matters is that iterators are gone.

The final example "for i in l" is Python. Python implements this construct precisely using iterators behind the scenes. Other languages are very similar, but Python in particular has a contract for an iterable object and that is how for loops work.

I think he meant to say "iterators should be invisible", not "iterators are an evil concept" but it's hard to be sure that he isn't just very confused as to what an iterator is in the general sense.

The original post is obvious and not worthy of nearly so many words, but yours is damn interesting. I have a thing for infrastructure, I guess.

SQLite is so hardcore about being totally unbreakable that they have a section in their documentation dedicated to explaining all the horrible things the OS has to do just to get it to fail: http://www.sqlite.org/lockingv3.html#how_to_corrupt

Reading about their testing process is also informative: http://www.sqlite.org/testing.html

Mercurial has http://bitbucket.org/ -- not nearly as popular but a tad less cluttered IMHO.

It's not that complicated, people are just too proud of their ignorance to bother learning (OP excepted since he went to the trouble of asking).

For one, it doesn't affect their pricing. If they're confident that the price will go up, then collecting some more money on lending fees is just icing on the cake.

For two, it helps to understand who actually owns shares. Most individuals trade in a "margin" account in which the trader gets some additional liquidity in exchange for lessened rights. These people don't actually own the shares they buy -- they are in fact owned by their broker, who keeps a pool of all the shares their clients purchase. Because of this, the broker can loan out some of the shares in that pool for additional revenue. If I remember correctly, there's little risk involved if the clients sold more shares than were still in the pool because the broker can simply call the loaned shares and force the borrower to find another lender. Additionally, dividends are not diminished by lent shares because the borrower is forced to pay the forgone dividend to the lender. There is, however, trouble with voting -- you can't vote shares you don't own, and your broker can't vote shares on your behalf if he doesn't own them either. So in effect, your voting power is diminished by the percentage of shares lent.

If you don't want your broker lending out your shares you can use a cash account instead. This puts the shares in your name, but you lose your ability to sell shares before the purchase has settled 2 business days later. Additionally you can't short-sell or borrow money. None of these are a great hindrance to a long-term investor though, so it may be worth the trouble.

As pointed out by others here already, SQL may not be the optimal fit for every scenario at large scales but it will nearly always work at smaller scales, and I can't imagine that you're already trying to write the next amazon.com. So in other words, start with SQL.

There are three main free software SQL databases: MySQL, PostgreSQL, and SQLite. Don't use MySQL, it'll get you into a great deal of bad habits, is missing an ass-ton of useful features (the default engine doesn't even support transactions), and likes to corrupt data. It also has questionable licensing and is owned by Oracle (a commercial database vendor) which as you can imagine doesn't have a lot of incentive to improve it.

SQLite is a very robust database that is great for read-mostly sites (like blogs) and for embedding into applications (Firefox for example). Its primary limitation is that there can only be one writer at a time. It is very easy to pick up and get going with since there's no persistent daemon, you just point it at a file and start writing. I'd recommend starting here.

PostgreSQL is the more featureful database and supports hundreds of concurrent connections, locking, access control, etc. This is the real "workhorse" database you're likely to find in production at large sites that do make use of free-software RDBMS. Eventually you will need to use something more powerful than SQLite, and this is probably it.

Can Arrington and Calacanis fight to the death already? I've been following HN now for less than a week and I'm already sick of their shenanigans.

Matt Taibbi has already proven that he can't tell a short sale from a hole in the ground. Perhaps Rolling Stone isn't the best place to be learning about markets.

cf.: http://www.businessinsider.com/john-carney-matt-taibbi-falls...

Market pricing appears random, but it is not because of a random number generator deciding when to go up and when to go down. It appears random because prices actively resist the formation of patterns, and a chart with no pattern by definition appears random. If a trader recognizes a pattern in a stock that is 100% guaranteed to play out they can borrow heavily and put it all into trading the pattern and walk away with a huge profit. If there's even a small probability that a pattern will play out, then a trader can place a proportionally small bet on it and still have a significant edge over everyone else. But the act of trading a pattern works to counteract the existence of the pattern: if the pattern predicts that the price will go up, then people will buy, thus driving the price up and making it harder for others to jump in until the profitability of the trade evaporates.

Now imagine 10,000 people (and robots) all doing this simultaneously. This is how markets work at the micro level. It may sound like a self-fulfilling prophecy but it happens so fast that the pattern never really exists to begin with -- it's just a way to explain why there are no patterns.

At least theoretically. Most traders (by head count, not dollars) haven't the tiniest idea what they're doing. Luckily, these "noise traders" all tend to counteract each other, and when they do manage to push prices off-course then someone who does know what's going on steps in and pushes things back in the right direction, making a profit in the process. Sometimes there are catastrophic failures, but while they might scare investors they don't affect the ability of the market to predict pricing long-term. The broad markets recovered extremely quickly during the flash crash and without any regulatory intervention.

As for whether the random walk means the pricing is "noise": the market price is an estimation of the fundamental value of the company, which is an imaginary number that is impossible to calculate but is occasionally pinned down when someone gets bought out. Because it is an estimation, and because the fundamental value is also ever-changing due to uncountable external factors (interest rates, consumer confidence, phase of the moon), the result looks like a random walk. It's a noisy estimation of an imaginary number. Neat, huh?

</wall-of-text>