Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
For the out-of-band Slashdot experience (mostly headlines), follow us on Twitter, or Facebook. ×

+ - Shady car dealers install secret GPS trackers. 1 1

FarnsworthG writes: A news story about the capture of a kidnapper mentioned that he was caught because a car dealer had secretly installed a GPS device on his car. Apparently this is becoming common for "buy-here-pay-here" dealers. The devices are sold by Spireon and Jalopnik among many others. Raises interesting privacy questions.

+ - Website peeps into 73,000 unsecured security cameras via default passwords-> 1 1

colinneagle writes: After coming across a Russian website that streams video from unsecured video cameras that employ default usernames and passwords (the site claims it's doing it to raise awareness of privacy risks), a blogger used the information available to try to contact the people who were unwittingly streamed on the site. It didn't go well. The owner of a pizza restaurant, for example, cursed her out over the phone and accused her of "hacking" the cameras herself. And whoever (finally) answered the phone at a military building whose cameras were streaming on the site told her to "call the Pentagon."

The most common location of the cameras was the U.S., but many others were accessed from South Korea, China, Mexico, the UK, Italy, and France, among others. Some are from businesses, and some are from personal residences. Particularly alarming was the number of camera feeds of sleeping babies, which people often set up to protect them, but, being unaware of the risks, don't change the username or password from the default options that came with the cameras.

It's not the first time this kind of issue has come to light. In September 2013, the FTC cracked down on TRENDnet after its unsecured cameras were found to be accessible online. But the Russian site accesses cameras from several manufacturers, raising some new questions — why are strong passwords not required for these cameras? And, once this becomes mandatory, what can be done about the millions of unsecured cameras that remain live in peoples' homes?

Link to Original Source

Comment: Re:FP? (Score 1) 942 942

5'6"1/2 is plenty readable to me. That's 1689mm. Both are 4 digits long. I don't see a clear advantage of using mm.

There are advantages if you are ever doing any calculations on that number, say divide it by three for example.
Also, since you were fine in rounding the distance to half an inch (~12.5 mm), why would you not round the metric number to whole centimeters (10 mm)? That would make it a nice 169 cm. Three digits, and all in the same unit!

Comment: Re:Reviving the bit wars? (Score 5, Informative) 773 773

The increased address space is not the important part of the ARMv8 64-bit architecture in this case.
Instead it has twice the number of general purpose registers (31) with twice the size (64 bit) than that of the previous ARMv7 architecture. It also has 32 x 128 bit vector registers, which again is doubled. This allows for more data being processed at the same time, and also saves a bit on memory accesses, which are horribly slow. There are also other improvements such as built in AES encrypting and SHA hashing instructions.

Comment: Re:universal connector (Score 2) 393 393

You are of course correct. They use the "device attached" pin of the USB port with a specific resistor to switch the USB data lines into two analog audio outs.
While this is a cool hack, it still suffers from a few limitations that the apple dock connector doesn't have. It can't do analog in at the same time (think microphone input for a car handsfree), or video, or simultaneous USB data transfer, to name a few things.
Also, this is not part of the USB standard, which means the cable only works with certain phone models, and can actually make other devices misbehave. Try connecting a Galaxy Nexus to that cable. :-)

AMD

+ - AMD confirms CPU bug found by DragonFly BSD's Matt Dillon->

An anonymous reader writes: Matt Dillon of DragonFly BSD just announced that AMD confirmed a CPU bug he found. Matt quotes part of the mail exchange and it looks like "consecutive back-to-back pops and (near) return instructions can create a condition where the processor incorrectly updates the stack pointer". The specific manifestation in DragonFly were random segmentation faults under heavy load.
Link to Original Source

news: gotcha

Working...