Forgot your password?
typodupeerror

Comment: T-Mobile (Score 1) 305

by athakur999 (#47242687) Attached to: When will large-scale IPv6 deployment happen?

Many of the newer phones from T-Mobile (the US version, anyway) are configured out of the box to use native IPv6. A third of their data traffic is now terminating on IPv6. They're using NAT64 for reaching hosts that don't have a native IPv6 address.

IPv6 rollout is happening, just not in the places some of us are looking.

Comment: Re:Still relevant nowadays? (Score 1) 58

by cide1 (#47191987) Attached to: Mesa 10.2 Improves Linux's Open-Source Graphics Drivers

Ive been working on a platform that is Linux running on a 1 GHz, 32 bit ARM, where we want to run an already existing Qt Quick 2 application. We have run mockup applications with X using the virtual framebuffer and the mesa software renderer, and found performance to be really bad. On the order of 1 FPS or so. Any suggestions on ways to make the software renderer more usable? My understanding is that LLVM would help here, but only works on x86 and x64.

Comment: Re:BeOS kicked butt, give Haiku a break! (Score 5, Interesting) 70

by cide1 (#47090279) Attached to: Haiku Gains Support For Current Radeon HD Cards

On hardware from circa 2001, BeOS had an audio latency of about 3 msec from input to output. I don't know the x86 / x64 number, but in 2014 running on the best ARM hardware available, by default, the Linux scheduler runs every 10 msec, so audio latency of 40-80 msec is pretty common. In many applications, that is quite a significant difference. There are good reasons why Linux has this latency, but it is a question of optimizing for different use cases. BeOS had a laser focused use case of Desktop performance. Linux is used on servers, desktops, embedded, super computers, and all kinds of wierd places.

Comment: Re:This just in... (Score 4, Interesting) 160

by Verteiron (#45078321) Attached to: Car Dealers vs the Web: GM Shifts Toward Online Purchasing

Heh, unless you work for a GM dealership, you have NO idea how bad GM is at IT. Their dealer-side website still does not officially support anything other than IE8. Business reporting relies on ActiveX integration with Excel, and only works properly with Excel 2000 and 2003. It can be made to work under 2007, but they don't support anything higher. Parts of the service-related workbenches still use VBScript. It used to be accessible only over a super-slow satellite link, but they changed that a few years ago, thank god.

To be fair, though, Toyota's web back-end, Dealer Daily, is even worse. IE-only, accessible only through a dedicated T1 which may not be used for anything else (but which you still pay full price for, of course). Blank page under anything other than IE.

Come to think of it, a lot of dealership stuff is locked on IE. Dealertrack (intentionally locks out non-IE browsers), Dealersocket CRM (featured-limited under non-IE browsers). ADP is the biggest supplier of dealership management software in the US and most of their stuff is entirely reliant on IE.

It's a pathetic state of affairs.

Comment: Write some code (Score 3, Interesting) 121

by bwhaley (#44701531) Attached to: Ask Slashdot: Hands-On Activity For IT Career Fair

Come up with a few simple programming projects that students can run through. There's something magical about writing code and seeing the computer execute exactly what you told it to do. Write a Ruby Sinatra or Python Flask app and show how to access it from the command line. This will teach them what a web server is and how to write simple code at the same time.

Comment: Re:Brute-forcing the lock code (Score 1) 239

by Verteiron (#43703025) Attached to: Apple Deluged By Police Demands To Decrypt iPhones

That was the point. It's not hard. I'm a general IT guy and I was able to do it easily. These PDs are saying they need Apple's help bypassing lock codes. Not just passwords, but lock codes like the one I bruteforced with free tools in a few hours. That they claim to need Apple's help for that is ridiculous.

Comment: Brute-forcing the lock code (Score 5, Informative) 239

by Verteiron (#43700175) Attached to: Apple Deluged By Police Demands To Decrypt iPhones

Brute-forcing an iPhone's lock code is relatively trivial with freely available tools. This puts the device in DFU mode, so "Erase device on X unlock attempts" doesn't take effect. That version of the tools only bruteforces lockcodes, but there's no theoretical reason you couldn't try at least a dictionary attack on a password, too. Since it's also possible to dump the hardware key and a complete (encrypted) image, I imagine an offline attack on the image is possible, too. You wouldn't have to rely on the relatively slow hardware in the iPhone.

Using those tools I have successfully bruteforced the 4-digit lockcode to an iDevice running 6.0.2, and that's with no prior experience with or knowledge of iOS. I even used an emulated Mac to compile the necessary firmware patch. And that's just what I was able to do in with a few hours of fiddling. There are people who do this for a living, and tools dedicated specifically to extracting data from mobile devices. Are these PDs really saying they can't get into devices with simple lock codes?

Counting in octal is just like counting in decimal--if you don't use your thumbs. -- Tom Lehrer

Working...