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


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

New Handheld Computer Is 100% Open Source 195

metasonix writes "While the rest of the industry has been babbling on about the iPad and imitations thereof, Qi Hardware is actually shipping a product that is completely open source and copyleft. Linux News reviews the Ben NanoNote (product page), a handheld computer apparently containing no proprietary technology. It uses a 366 MHz MIPS processor, 32MB RAM, 2 GB flash, a 320x240-pixel color display, and a Qwerty keyboard. No network is built in, though it is said to accept SD-card Wi-Fi or USB Ethernet adapters. Included is a very simple Linux OS based on the OpenWrt distro installed in Linksys routers, with Busybox GUI. It's apparently intended primarily for hardware and software hackers, not as a general-audience handheld. The price is right, though: $99."

Comment It's a huge issue to app developers, not Googlers. (Score 5, Informative) 211

I've developed 7 Android apps and the huge diversity of Android versions and devices out there really is a nightmare. I have an enormous number of extra code paths due to it. All this extra complexity makes apps tougher to write, tougher to test, tougher to debug, tougher to enhance.

Some examples of bizarre stuff I have to do:
Android 1.5 has a Java NIO bug that forces me to copy data to a temporary array on its way to buffers to be rendered via OpenGL. This hurts performance on older phones that often need it the most. It also means I have to do more testing to make sure both code paths are well exercised. I bet many developers don't even realize the bug is there an just have broken OpenGL apps on Android 1.5. The bug fix would be trivial to port back to Android 1.5, which would make it drastically more likely to get on to these older phones, but there's no sign this will ever happen. Do I keep code paths like this? Or do I give up the 25% of the market that is Android 1.5? Neither is desirable.

Another really frustrating one is how I have to detect specific devices and request certain size depth buffers just to get decent performance. Hardware graphics acceleration is only enabled on the Samsung Galaxy for depth buffer size 16, for example, not for no depth buffer. Depth buffer size 24 works best on the Droid, etc.. The Galaxy has had this bug for a very long time. The Archos tablet has no hardware acceleration and there are promises that cheaper phones will be similar. Do I write all the extra code for adjusting rendering for each of these? Or do again give up large swaths of the market?

Anyway, I'm constantly dealing with issues like this. It is really disappointing that Android team, the carriers, and the device manufacturers don't do more to prevent it. Doing things like back porting fixes so that older phones can be more trivially updated would help enormous numbers of apps and app developers compared to the very few resources needed on Google's part to do it.

Meanwhile Google isn't even interested in solutions to these problems from what I've seen. One developer brought up another potential solution during a session at Google IO. He suggested making the highest level of Android a distributable framework, like .NET. This would allow updating it much easier. Not nearly as many phones would be stranded with old, buggy versions of the Java portion of Android at least. The Google staffers just brushed the idea off without even discussing it. They said fragmentation should really be called progress and to deal with it.

This isn't really surprising. If you look at a recent app produced by Google, the Twitter app, you'll see that it is unavailable to a huge percentage of the market because they don't support older versions of Android with it. Independent developers can't afford to ignore large sections of the marketplace like that. Google isn't in the app business, so the Googlers just go ahead and ignore the issue. You can see a graph of the versions of the devices on Android Market here:

And of course there are plenty of devices not on Google's market, many of which are even less likely to receive updates because they are updated by PC software rather than over the air.

So Googlers aren't even eating their own dog food on this issue. They just make app developers put up with it on their own, never experience it themselves, and then ridicule the issue as a bogeyman. I think I was happier before I read the blog post. At least then I could imagine they were working hard on the issue and just doing terrible at it. Now I know they don't even consider it an issue.

Comment Google C&Ding CyanogenMod (Score 1) 328

I'm surprised that Google sending a C&D letter to CyanogenMod didn't make the list. Google had been trying to market its cell phone OS, Android, as an open platform that welcomed innovation and contributions. Then they decided to threaten an immensely popular third party rom that did wonders for Android's performance.

The official distribution at the time had many issues. Performance degraded the longer you went without a reboot. You couldn't install apps on SD cards, only the tiny internal storage space, so quickly ran out of room for apps. CyanogenMod provided a great option for frustrated or highly technical users to get the performance and bleeding edge features they wanted.

Meanwhile Microsoft actually has a good reputation for turning a blind eye to people making roms for Windows Mobile. Google actually managed to make themselves look less open than Windows on this one. They also angered a lot of technical users who could have become Android evangelists.

Slashdot Top Deals

CCI Power 6/40: one board, a megabyte of cache, and an attitude...