Forgot your password?

Comment: Re:Now the next step... (Score 1) 143

by Forever Wondering (#46052233) Attached to: US Supreme Court: Patent Holders Must Prove Infringment

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.

Comment: Strength test (Score 1) 374

by Forever Wondering (#45981129) Attached to: Man Jailed For Refusing To Reveal USB Password

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]:

Comment: Some fixtures need incandescent (Score 1) 767

by Forever Wondering (#45958207) Attached to: Incandescent Bulbs Get a Reprieve

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.

Comment: Re:Rock Star coders! (Score 4, Interesting) 275

by Forever Wondering (#45895535) Attached to: End of Moore's Law Forcing Radical Innovation

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.

Comment: Premium Interest is too long a name anyway (Score 2) 133

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 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 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 to (2 syllables).

Even without the trademark flap, "Premium Interest" is a lousy name for a business. Barry Diller changed to 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.

Comment: Re:Subject (Score 5, Informative) 262

by Forever Wondering (#45780287) Attached to: Linux x32 ABI Not Catching Wind

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. .so files).

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;
instead of:
    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
Etc ...

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

Never trust a computer you can't repair yourself.