I haven't used it for a production app, but I will say that it kicks AIR's ass with regards to CPU and memory usage. Titanium has way lower resource utilization for the same app as compared to Adobe AIR.
The problem with your assessment is that it proves Don's point in the article. The B trader will reveal his inside information much more rapidly than if he were not able to act on it, thus increasing the amount of information available to the market as a whole, enabling better decisions by others regarding the security in question.
I agree, the "B" traders are more likely, but that's a good thing.
There is a technical term for this phenomenon: an Akerlof market. Where there is a large information asymmetry in favor of the sellers, the price of items in said market is driven down since buyers will not pay the sellers' requested prices due to high variances in quality. "Lemon laws" are an example of a countermeasure against an Akerlof market developing for used cars.
More to your point, if insider trading were common, as you propose, then the prices of these transactions (and therefore the profit gained from them) would begin to fall as buyers would increasingly begin to distrust said transactions. Therefore. it would be in the best interest of traders with inside information to not act in the manner in which you suggest lest they significantly deflate the market from which they are looking to extract profit.
This is already the case and happens all day every day, although it goes by the name "high-frequency trading". The information that HFT systems trade on is "concealed" via the latency differences between multiple systems interacting with a given exchange(s). This "latency arbitrage" can be understood to be an extremely high-speed version of insider trading.
For Windows, there definitive source in book form is the Microsoft Windows Internals series. I worked with a guy that used to work at Microsoft and he prefered this book to looking things up in the source code ;-)
If you're in school, Microsoft also has an academic program that allows universities (almost) full access to the source code of various Windows kernels. Its called the Windows Research Kernel program and might help you along if you can get ahold of it because it comes with a ton of documentation: the original NT design papers, proposed class materials and a full copy of the aforementioned Microsoft Windows Internals book in PDF form.
For Mac, the online kernel guides are pretty good. The Mac OS X Internals book isn't so great for driver or kernel development directly, but is a good reference for learning about how things work. Having said that, the book is a bit dated at this point and could use an update for the later kernels.
IMHE, all AIR apps "leak" over time (meaning, absorb more and more RSS as time goes on). This is regardless of whether they were written with Flash/Flex or HTML/JavaScript or a combination. I wrote a really small AIR app (one pane with some JavaScript, no images or other media) and it starts off at 100MB on boot and continues on until I kill it at well over 350MB RSS a day or two later. TweetDeck, Twhirl, FriendDeck, etc, they all leak for me, too, on both Mac and Linux.
qmail itself is completely unmaintained and patches to it are actually rejected. net-qmail and others have sprung up to fill this void, but its got nowhere near the community surrounding it that Postfix does. Plus, qmail is very hard to use for someone just looking to send some mail, which is the common case (not the case qmail was designed for, either).
These chips are usually dirt cheap. I bet the radios cost more. Also, the iPhone already has significant retail price margin built in, so I doubt it would hurt them much.
I know Winer's a great figure in the history of the Web, but this might be the most incoherent post I've seen this year. It made no sense to me, in that the history lesson has nothing to do with the problem at hand, if indeed it is a problem at all. Winer needs to realize that his problems with Twitter are not the same as Twitter's problems on the road to success, as much as he'd like them to be.
Did no one else notice that this paper was authored by the C-Store guys, the ones that went on to create and found Vertica (specifically Stonebraker)? They have an intense bias against map/reduce, as could be expected.
As well, one important fact that people seem to have missed is that they admit that m/r was better at loading the tuning the data, a task which in its regular name (ETL) dominates most data warehousing workloads.
Finally, please note the price tags on the solutions advocated by this paper. They are far out of the reach of any startup founders reading this paper. I looked at them at both Commerce360 and Invite Media and they were just nowhere near reasonable enough for us to replace our existing Hadoop infrastructure with.
This report is kind of obvious. Those of us using AWS and others knew about this a long time ago. Its pretty simple math to be able to see when your cloud will cost more than DIY.
Pure marketing bullshit. M/R vs. SQL is a crazy comparison since you use them in two different spots. The paper's authors all have a financial or egotistical stake in Vertica and they fail to mention that any real DW effort is dominated by ETL times (which they admit M/R was better at). Another thing they fail to mention is the exhorbitant price tags associated with the current batch of commercial column-store databases (re: 6 figures and up for Vertica or Aster).
I'm confused: given the quota problems and serious constraints of the real App Engine, why would I want a clone of it that I also have to maintain and manage myself? Isn't the value-add here that I get SysOps and all that for free with GAE? Isn't the cost-savings of GAE coming from its scale, and if so, how could a private AppScale cloud running on Eucalyptus or similar garner the economies of scale to make it cheap enough to be viable? As well, don't you have to have the expectation of servicing a large number of applications of the type that work with GAE to even consider something like this? (something that a typically enterprise is not going to need)
In short, I'm really confused as to what the big deal is. Can someone elaborate on the above questions?
The point of the data structure in this case was not the radix trie alone but rather the combination of the use of tries in concert with the aggregation characteristics of IP traffic. This type of innovative combination is common in the network world due to the necessity of providing ever more introspection and functionality over ever higher throughputs and ever lower latencies. For some serious treatment of the subject, check out the book "Network Algorithmics" by George Varghese.
ARRGH! Did no one actually read that paper? Its 1MB limit on data size and concentration on HA for writes makes it unsuitable for this purpose, just as it is unsuitable for S3 (a previous rumor purported by the commenters on this site). RTFP, people!
RDDB makes no sense to me. I was at RubyConf when it was announced. Why clone CouchDB in Ruby? Its got none of the awesomeness Erlang brings to the table for things such as this and you can embed Ruby in CouchDB with less work than Anthony did building RDDB in the first place.
What a cop-out. Those teachers are banning one of the greatest sources of information on the Web today just so they don't have to teach their students the concept of 'caveat emptor' (http://en.wikipedia.org/wiki/Caveat_emptor). All sources have some error and bias, not just Wikipedia. You want to deal with that, teach? Require more sources.
How much you want to bet those same teachers go home and watch Fox News at night?