It wasn't originally -- it was created in Palo Alto, by people not affiliated with Russia. It's gone through changes since then, though, and I don't know the current ownership status.
"Ox is easier to use than Vim because it doesn’t have modes where the keyboard is repurposed, however it takes the idea of being a keyboard-only editor and being able to act just like an IDE after some configuration."
He's not claiming that you can brute-force the encryption key -- he's proposing another way to brute-force the PIN itself that won't trigger exponential timeouts or auto-wipe of the device. I don't know if he's right or wrong, but let's at least make sure we're clear what his argument is first.
I remember doing this a few companies ago. Except we didn't have a modem, we just found a phone we could send commands to. It had some user interface that would pop up after every sent message, so we rigged up a terrible little hack to press the acknowledge button every few seconds to dismiss it. It worked surprisingly well :)
It's true that the SEC makes this data available free of charge, but it's typically not useful without a lot of extra processing. XBRL(http://en.wikipedia.org/wiki/XBRL) is a standard of sorts, but there seems to be no enforcement of how it's used across different companies' filings (or even across multiple filings from the same company), and many critical pieces of information are filed under e.g. company-specific extensions. It's definitely a pain working with the data in any meaningful way.
FWIW, www.downside.com had a hard time reading the latest filings for AAPL, the only one I tried. Visiting http://www.downside.com/cgi/testfinancialsextract.cgi?url=ht... threw an error "ERROR: SGML Parse error: EXCEPTION reading from net: The filing is bigger than the maximum allowed size of 5000000 bytes. at EDGAR/netutil.pm line 75."
Maybe. If you're just loading constants onto the stack, it seems like it would be pretty forgiving of optimizations and such, and even work across architectures (assuming the same endian-ness, at least).
I'd definitely look for init code for some calculation (as it appears the author has done here), rather than actual computation code, since, as you point out, optimizations could have a huge impact on the instructions emitted for those.
It's 10 dense pages of tables, but it essentially sets a lower bound on the pricing you can get from one of the companies discussed in the article. Everyone would love to see the card networks lower (and simplify) their fees, but that's not what's being railed against in the article.
I applied to work at a Radio Shack when I was 16. I didn't get a job there. The guy interviewing me spent most of the time making sure I knew the difference between being paid hourly, and being paid on commission, and making sure I really knew what a spiff was. In retrospect it was kind of weird. It was kind of weird at the time, too.
Reading these, I don't feel like I missed out on too much.
That was really interesting, thanks. In particular,
"The Enforcement Process. Congressional investigations often begin informally, with the interested committee or subcommittee first seeking information on a voluntary basis (i.e., by sending a letter request or asking for an informal interview), rather than by issuing compulsory subpoenas. Although there is no legal obligation that a party comply with such a request, it is typically in the responding party’s best interest to do so"
Source: I worked there a long time ago.