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


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Smart Phones (Score 1) 58

The only thing I've ever heard about them was their smart phones, which are apparently appallingly awful, and only available in pink!

You forgot to mention that they're all made in sweatshops by buck-toothed little Asians who can't drive, wear glasses, and are all martial arts experts.

Just for the record, I own a silver (not rose gold) LeEco, it's a really nice phone, a bit like a Samsung Galaxy but at a fraction of the price and without the incendiary tendencies. I have several friends who have them as well.

Comment Re:And the cost of such design flubs ... (Score 1) 99

It's not about support, it's about security. Knox (only on Samsung) is the closest you can get to decent security on Android,

By Knox I assume you mean Samsung's backdoored malware-injection vector? You can get the same "security" by visiting the alternative Android app store at

Comment Re:This is a joke- you can't seriously call it sec (Score 1) 68

Yeah, I think you guys are doing a great job, sort of what IBM tried to do 15 years ago with their 4758, but failed due to hardware constraints (you had to run some funky embedded OS with equally funky IBM-specific development tools). The one thing that'd be nice to have is what someone suggested in a previous thread, a fibre-optic link that can be used to lock it into a physical location, so an attacker can't steal it and attack it at their leisure.

Comment Re:What? (Score 1) 68

It's actually some way removed from what's built into POS terminals. Terminals have to be as cheap as possible and the vendors cut corners at every opportunity (what's certified is often not what's shipped). You can defeat the physical security of many POS terminals using a few items you can pick up at your local hardware store. The ORWL is another matter entirely.

Comment Re:ARM driver vendor code is atrocious (Score 2) 150

I've seen an appreciable number of cases where perhaps 75% of the code for something is either okay or actually pretty nice, but there are also really shitty chunks that appear to have been written by people under the influence of a random assortment of hard drugs sprinkled across the whole codebase.

See my other comment, the Arm environment more or less drives that, you've got 75% that's common and the remaining 25% is semi-documented special-snowflake crap that you have to reverse-engineer from partial docs in order to get it to work.

Comment Re:ARM driver vendor code is atrocious (Score 5, Interesting) 150

It's not just the code, it's the hardware environment as a whole. Every single freaking ARM SoC is a custom special-snowflake device with its own special-case add-on IP cores, Chinese-menu instruction set (we'll do this extension, and that one, but not that one over there, and the config register read that tells you whether it's available is privileged to it'll trigger an exception if you try and read it), undocumented memory-mapped crap, or a 1,000-page manual with partial documentation which in any case changes completely if you order an XYZb rather than an XYZa even though it's the same family from the same manufacturer. Just the perfect environment for vendor lock-in, but terrible for devs.

Slashdot Top Deals

Nature, to be commanded, must be obeyed. -- Francis Bacon