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:
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.
An adequate bootstrap is a contradiction in terms.
