The blog does not say what the contributor says it does. The closest it comes is noting that the links from the negative reviews never counted in the first place because the sites hosting the reviews used the "rel=nofollow" attribute on the links. What it does say is that they have altered the algorithm to punish bad businesses more effectively in response to the NYT article that suggested that being bad could be good for business.

Move along, nothing to see here!

Design your application to modularize the OS-dependent code away from the OS-independent code. When it comes time to port (if it ever happens) you should only have to worry about the OS-dependent stuff with minimal modification to the core of the application.

TCP/IP is routable, period. The "non-routable" blocks are simply IP addresses that can't be used across the Internet but will still work fine in an internal network. HP's users might need to talk to each other, but there's no reason for me to able to ping all of them from home.

This is obviously coming along with the increased focus on removing distractions from driving (cell phones, texting, DVDs, etc). The problem is that flying a plane has almost nothing in common with driving a car, beyond some rudimentary instrumentation similarities and the overall goal of getting from point A to point B. The skies are not crowded like a freeway--a pilot doesn't have to worry about the plane next to him cutting him off on the way to LAX, because there is no plane next to him--flight paths are planned well in advance. The pilot only has to worry about situations that can't be handled by auto pilot, like mechanical failure or turbulence.

So, in other words, the FAA is saying, "We want you to give your full attention to flying, but you can't do anything to keep yourself awake." I don't care how much sleep you get, a 17+ hour trans-Atlantic flight with nothing to do but check your instrumentation is going to bore you to sleep. In trying to improve flight safety, this is going to have the opposite effect.

Reading comprehension: I'm not advocating Virtual XP. I'm suggesting running MS-DOS 6.22 as the guest OS--that is, applying the same methodology as Windows 7's "Virtual XP" mode to use a "Virtual DOS" mode rather than emulating it (poorly) in the kernel via NTVDM.

Certainly the best way to eliminate this threat is to do away with the NTVDM altogether and use virtualization, similar to how Windows 7 Pro has "XP Mode." Microsoft should create a virtual HD (*.vhd) file with MS-DOS 6.22 installed on it and then offer it as a free download. Users could either use Virtual PC or the virtualization solution of their choice (VirtualBox, VMWare, etc).

DOSBox is also a decent solution, although it is geared more towards DOS games than to completely and accurately emulating MS-DOS.

Actually, violent crime has been on a steep downward trend over the last 18 years.

http://www.ojp.gov/bjs/glance/viort.htm

Note: this graph includes all violent crime, not simply homicides.

Violent crime peaked around 1994--before Grand Theft Auto, before Modern Warfare, before Quake. The game industry has exploded during the same time; if violent games had a causative relationship with violent crime, wouldn't the statistics reflect it?

The issue is that the browser is only allowed to use a handful of requests at a time, and with a 3rd-party server some fraction of those requests are going to someone else's server. Therefore the goal should be to make sure that your content gets loaded first. This can be done in the browser--and may already be done; I'm not in the mood to parse FireFox's sourececode--using a simple prioritization algorithm:

1. Content from the page host gets first priority (tech.slashdot.org)
2. Content from the same domain gets second priority (*.slashdot.org)
3. Content from anywhere else gets lowest priority.

And of course, there are HTML tricks that can be used to boost render time, like using absolute hight/width attributes on every image and avoiding the use of relative metrics against dynamic portions of the page. In other words, don't define the width of your main body element as a percentage of your advertising banner's width!

Still, I can't help but think this just 1998 again, "Now with more JavaScript!"

As a fairly recent graduate of Army Basic Combat Training, there is nothing pointless about making training courses safer. The training schedule is very very tightly packed--there is virtually no room for a soldier-in-training to get injured and keep up with his classmates. At best, the soldier will be restarted with a new unit; at worst, the soldier might get sent home for convalescence leave (paid), or if the injury is serious enough it might require separation. So if training can be made safer, that means fewer injuries and smoother training schedules.

Fail! That's not even a 32-bit instruction. Everyone knows the ultimate instruction is 0xDEADBEEF!

This actually isn't entirely MS Office's fault. I used to do technical support for Adobe Acrobat, and a very common support call was, "My document looks fine on the screen and prints to my printer fine, but when I make a PDF the layout is messed up!"

MS Office formats the page relative to the currently selected printer's printable area. The problem arises when you have a document that puts objects near the page margins, and then change the selected printer (File > Print > Change printer and click "Close" instead of "Print"), MS Word reflows (reformats) the document on-the-fly for the new printer.

If your template is well-designed, nothing major will change (maybe some line breaks). A badly designed template, like one that uses manually inserted page breaks instead of letting a style insert the page break, will break in interesting ways, like inserting an unnecessary blank page or floating text next to a table or something like that.

Nasty reflow almost always boils down to poorly written documents that do stupid things like use an empty paragraph to put a blank line between paragraphs, use underscores instead of underlined spaces to create a blank, use a manual page break instead of a paragraph rule to force pagination, and other hacks. Learn how to use the software, and it'll behave properly.

In 1993, dial-up PPP was still billed by the hour and most Internet use was among government researchers and schools. If anyone had it at home, they were dialing into a UNIX server and using a shell.

Implementing a phone-home activation would have meant millions of dollars in phone lines, trunk hunting, modem banks, technical staff, just to avoid piracy that might've lost a couple hundred thousand sales at the most. It's no wonder Microsoft declined to use the technology.

Did the patented technology involve creating a profile of the PC that would uniquely identify the computer it was installed on, and require re-validation if the hardware configuration changed significantly? 1993 pre-dates the PCI bus and Plug-and-Play, so probably not.

If this case sets a precedence for more software patents being thrown out, then I for one welcome our software-patent-tossing overlords.

Texas Instruments makes damn fine graphing calculators, but would it be so hard to write a damn x64 driver? I can't use the USB interface with either my home PC or my laptop because both are running x64 (7 Pro on the desktop, Vista Home Premium on the laptop). And I'll be damned if I go back to 32 bits just to make the calculator happy.

I did googling and didn't find anything existing; has anyone tackled writing a homebrew x64 USB driver? I think all the information needed is already out there, but I don't have the time/motivation to write the driver myself (especially having never written a driver before).

This is less "TCP/IP over Pidgeon" and more "Sneakernet Over Pidgeon." Although if all the memory cards were the same size you could get away with calling it ATM over Pidgeon, I guess.

Not true. Early PS3s had the complete PS2 chipset included, so in those cases the PS2 games were being run natively. Later model PS3s had only the GS in hardware, and used software emulation for the EE. The newest models have neither the EE nor the GS, and these are the models that have no backwards compatibility at all. The main problem is that the GS had features that the PS3 chipset doesn't have.