You have to accept a license agreement and you will get to download msdos.zip
It's not BS.
The USPTO lowered its standards [at the behest of Congress] to lower its standards to reduce its backlog. If an application is denied, it can be refiled [many times]. The only way to truly clear it is to approve it [and toss it into the court system]:
$10,000 times 20 is a trivial amount [on a corporate level] compared to an NRE budget for a legit R&D outfit. There seems to be plenty of [unscrupulous] VC money to back such refilings to get something that can be used to [patent] troll others. The first round funding for even a small startup [post angel round] is minimally $10M. This translates into 1,000 refilings.
(Also, isn't this really a question for superuser.com or similar?)
According to a strength test, the password has only 49 bits of entropy, so it's surprising GCHQ couldn't crack it:
< 28 bits = Very Weak; might keep out family members
28 - 35 bits = Weak; should keep out most people, often good for desktop login passwords
36 - 59 bits = Reasonable; fairly secure passwords for network and company passwords
60 - 127 bits = Strong; can be good for guarding financial information
128+ bits = Very Strong; often overkill
The checker had been posted on slashdot a while back [IIRC]:
Thanks. Had read an article a while back about the trouble of getting the high lumen LEDs. State of the art may be advancing. But, my local store only had the 60 watt equiv LED when I was buying the incandescents.
While I've been using 90% CFL's for ten years, I have one fixture in the ceiling of a walk-in closet that needs an incandescent.
The bulb is inverted and is completely covered/enclosed. Can't use a CFL there [overheats the transformer]. Nor a halogen [too hot](?). Don't know about LED's or "high efficiency" incandescents, but the heat dissipation problem seems to be a factor. Can't change the fixture since I'm renting [and the landlord would be loathe to retrofit hundreds of units]. So, I don't have a ready replacement for my one remaining incandescent, so I stocked up on Jan 31. Prematurely, it seems.
While I like CFL's it seems most people don't. Particularly those families that have [small] children, since a broken CFL releases mercury, which is toxic. Also, I prefer the lumen output of a 100 watt equiv (27 watt CFL). Ultimately, I think LED's will be the long term solution. I did buy an LED just to try it, but the brightest I've found is barely the 60 watt equivalent.
This was one of the few cases where the regulation outpaced the technology.
Thanks for this. It could [very easily] be the one I was thinking of.
There was an article not too long ago (can't remember where) that mentioned that a lot of the performance improvement over the years came from better algorithms rather than faster chips (e.g. one can double the processor speed but that pales with changing an O(n**2) algorithm to O(n*log(n)) one).
SSD's based on flash aren't the ultimate answer. Ones that use either magneto-resistive memory or ferroelectric memory show more long term promise (e.g. mram can switch as fast as L2 cache--faster than DRAM but with the same cell size). With near unlimited memory at that speed, a number of multistep operations can be converted to a single table lookup. This is done a lot in a lot of custom logic where the logic is replaced with a fast SRAM/LUT.
Storage systems (e.g. NAS/SAN) can be parallelized but the limiting factor is still memory bus bandwidth [even with many parallel memory buses].
Multicore chips that use N-way mesh topologies might also help. Data is communicated via a data channel that doesn't need to dump to an intermediate shared buffer.
Or hybrid cells that have a CPU but also have programmable custom logic attached directly. That is, part of the algorithm gets compiled to RTL that can then be loaded into the custom logic just as fast as a task switch (e.g. on every OS reschedule). This is why realtime video encoders use FPGAs. They can encode video at 30-120 fps in real time, but a multicore software solution might be 100x slower.
- Saves on printing costs
- Makes direct deposit easier
- Helps attract trendy brogrammers
- Helps corporate tax avoidance without such plans as "Double Irish Dutch Sandwich"
- The new hot topic in boardrooms
Probably why they trade marked pinterest (3 syllables) vs "Premium Interest" (6 syllables). But, legalities aside [even if Pinterest is forced to change its name], the term pinterest is already poisoned for use by Premium Interest. The market already associates the term with pinterest.com. Trying to use it for another company is just adding an additional burden on Premium Interest.
Premium Interest appears to be a muddled/watered down version of reddit (2 syllables). (P)Interestingly, on the premiuminterest.com page, they have a "like" button called "Pi Score".
The smart (entrepreneurial/business/non-lawyering) way out for everybody: Sell the trademark to pinterest. Change premiuminterest.com to piscore.com (2 syllables).
Even without the trademark flap, "Premium Interest" is a lousy name for a business. Barry Diller changed askjeeves.com to ask.com. Everybody remembers Google but [virtually] nobody remembers AltaVista. Lycos? The exception that proves the rule, I guess
Time will tell whether Alex Hearn is half as savvy a businessman as Diller.
With x32 you get:
- You get 16 registers instead of 8. This allows much more efficient code to be generated because you don't have to dump/reload automatic variables to the stack because the register pressure is reduced.
- You also get a crossover from the 64 bit ABI where the first 6 arguments are passed in registers instead of push/pop on the stack.
- If you need a 64 bit arithmetic op (e.g. long long), compiler will gen a single 64 instruction (vs. using multiple 32 ops).
- You also get the RIP relative addressing mode which works great when a lot of dynamic relocation of the program occurs (e.g.
You get all these things [and more] if you port your program to 64 bit. But, porting to 64 bit requires that you go through the entire code base and find all the places where you said:
int x = ptr1 - ptr2;
long x = ptr1 - ptr2;
Or, you put a long into a struct that gets sent across a socket. You'd need to convert those to int's
Granted, these should be cleaned up with abstract typedef's, but porting a large legacy 32 bit codebase to 64 bit may not be worth it [at least in the short term]. A port to x32 is pretty much just a recompile. You get [most of] the performance improvement for little hassle.
It also solves the 2037 problem because time_t is now defined to be 64 bits, even in 32 bit mode. Likewise, in struct timeval, the tv_sec field is 64 bit
RC4 comes from Ron Rivest [of RSA fame] and stands for either "Rivest Cipher 4" or "Ron's Code 4" http://en.wikipedia.org/wiki/RC4
Given the following:
what would happen if the car decided to recharge itself? Would the car be arrested?
I still have my original copy of the IEEE journal paper that I clipped in the 1970's. It stood out as a landmark paper then. About 15 years ago, I was at a technical talk and was able to get Martin Hellman to autograph it.