Newer hardware can make use of newer features which will change what should be considered the best optimisations. Addition used to be much faster than multiplication until they put barrel multipliers in chips. Once floating point cores were added, other things became faster but the early FPUs could do things like add and multiply and anything else could be very slow. I wrote a floating point library for OS9 for the radio shack color computer which had a 2 mhz 8 bit cpu with good 16 bit instructions and no floating point hardware and I could do trig and log functions faster than a 4.77 mhz 8087 floating point unit. I could use tricks like bit shifting and de-normalising floating point numbers for quick adds. There was one function that the typical Taylor series used a /3 + /5 + /7 type thing but there was an alternate that used /2 + /4 + /8 but took more steps but an integer CPU can divide by a power of 2 something like 50 times faster than dividing by an odd number so the doing the extra steps was faster. My library took advantage of precision shortcuts like simply not dealing with some of the low order bits when the precision was going to be lost in the next step or two which are things that you simply can't do efficiently with current floating point hardware.

When I was in high school we had a FORTRAN class and one of the assignments was print out as many Pythagorean triples as you can in the allowed 1 minute of run time. Most students would start with power and square root function which would provide about a page and a half of results of which one was wrong because of rounding errors. Going from A^2 to A*A would get you far more pages. The system had a multiply-accumulate function that worked very well so a few changes in a formula could double the number of results.

If you are going to do your own round counts, there are better ways to make it so you can't use hardware to attack your system. One trivial way with hashes is to xor the 1st byte with 0xaa on the 12th round. That alone means anyone building hardware or a GPU approach needs to take that odd step into account and that should about double the work needed by a GPU using today's techniques for optimisation. Another thing that works is to use a different table. For example MD5 uses an internal table that is something like 256*sine((0..255)/256.0). A simple swap of two bytes somewhere in the table means it is incompatible with off the shelf solutions and should be the same strength. There is a risk that doing this will cryptographically weaken the hash. For example if you use the XOR trick too early or too often in the rounds, you end up forcing bits to a known state and that makes it much weaker much like messing with S-boxes in DES does and for the same reasons. Moving around values in large tables tends to be safe as does some conditional byte manipulation in later rounds assuming you are doing more than the standard count. A great way to find out what doesn't work is write a md5 like function with 32 bits and just a few rounds. That can show lots of tweaks are very bad ideas.

It could have been a small subset of a larger leak. Perhaps 13,000 out of millions that just happen to have the same seed values so they could be cracked easier. Of course then someone would have had to try those 13,000 against some of the top 100 web sites in the world but that should have left their fingerprints in logs all over the world.

I have a very old sparc based Tadpole laptop. While the thing will run off batteries, I wonder if they would have done better business by getting in the battery powered electric camp stove business since they have most of that part working fine.

I wrote a C compiler that would sometimes not compile correctly but it was based on a an attempt to use neural nets to do complex parsing.

The ear follows the rules Nyquist created about sample rates (i.e. there are hairs in your ear that are turned to hear 40 kHz but you can't hear that high). There is no reason the eye can't be doing the same thing.

They are using an ethernet solution over fiber so the next steps above 10 are 40 and 100 gig. This is what you can do when you roll out a data network and not an overgrown cable tv network like all the xPON and FTTH, FTTP networks we keep hearing about.

It is a result of the stupid and outdated firewall model of "Trust/Untrust/DMZ" when applied nearly anywhere.

Modern production networks should be firewalling everything from everything else. Nothing should be on the "Trusted" side. Get something like an SSG-140 and load it up with a bunch of 8 port cards which will give you 42 ports and 42 zones for things to talk to. That way you can allow the CNC machine to talk to its support site for its update but it can't ever talk to the laser cutter or other CNC machines.

The sad thing is the SSG is EOL and I don't know anyone else that makes a low cost multi-port firewall and most switches with firewall capability just don't do proper intrusion detection and malware detection.

The FAA has been trying to point out this fact for decades. The paper pilots carry around isn't a pilots license, it is a certificate of license. The license is held in a computer somewhere and when that is revoked, the paper saying you have a license is meaningless.

Most antennas turned for 2.4 Ghz are shorts to a ground plane.

I'm a US citizen living in Australia and I have often been contacted about working in the USA under and H1-B visa for very good pay. When they find out that I don't need the visa to work for them, they aren't interested so something else is going on.

The only world that 20 cent deliveries can work is the same one where "Lucy in the Sky with Diamonds...

Football has a strong connection to military training. It is the best sport to teach future cannon fodder to blindly obey the rules while working as a team and follow the chain of command.

If the data is in cache, it is faster to open a file, read the data in as a text file, do a linear search, process the data, close the file than it is to just do a connection to an sql server. Most online stores are selling so few products that their entire product database should fit in L1 cache. If you want fast, make sure everything that has to be run can live in L1/L2 cache except what has to be be written out. Modern file systems are very good at writing out small files quickly without making the person in front of a screen wait.