Weekly Edition
Return to the Announcements page
| |||||||||||||
|
| |||||||||||||
Kuhn: At Least Motorola Admits It
On his blog, Bradley M. Kuhn looks at Motorola's decision to lock-down its Droid X and Droid 2 phones. "I appreciate the fact that [Motorola's Lori] Fraleigh and Motorola are honest in their disdain for software developers. Unlike Apple — who tries to hide how developer-unfriendly its mobile platform is — Motorola readily admits that they seek to leave developers as helpless as possible, refusing to share the necessary tools that developers need to upgrade devices and to improve themselves, their community, and their software. Companies like Motorola and Apple both seek to squelch the healthy hacker tendency to make technology better for everyone." A related issue to ponder is the report that the Droid X will turn into an expensive brick if you try to change its firmware.
(Log in to post comments)
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 5:36 UTC (Fri) by butlerm (subscriber, #13312) [Link]
"Motorola readily admits that they seek to leave developers as helpless as possible"
This statement in the linked post is not even a vaguely reasonable paraphrase of what the Motorola representative actually said, and the poster should be ashamed of himself for trafficking in such reckless fabrications.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 6:03 UTC (Fri) by rsidd (subscriber, #2582) [Link]
I don't see why it is not a reasonable paraphrase. Motorola's representative is recommending that developers buy one of two non-Motorola phones (ADP1 or Nexus One, both made by HTC). What could be more explicit than that? If you're interested in developing, don't buy Motorola.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 8:13 UTC (Fri) by drag (subscriber, #31333) [Link]
It's more then that.
Alternative firmwares can provide significant advantages over the 'stock' ones. This means that if your a technology loving type of guy/gal that cares about value and features then this phone should not be a priority purchase.
So it's not just developers that should avoid these phones.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 14:26 UTC (Fri) by sepreece (subscriber, #19270) [Link]
The problem is multiple definitions of the word "developers".
Motorola (and other Android-product manufacturers), like Apple, are confining developers to building installable applications. That's perfectly reasonable for a consumer device. Most Android devices are more open to installing apps than Apple's mobile devices, though some carriers have continued their walled-garden model even on Android.
What Lori said was that if you want to do firmware/OS development, you should buy a phone that is designed and marketed for that purpose.
Motorola has been pretty upfront about this since the beginning of its Linux involvement. In fact, Motorola has gone to significant lengths to protect the operating software (and, sometimes, hardware) in almost all of its devices, for decades.
Linus, and at least some other core Linux developers, have expressed their comfort with this model - using Linux inside a device does not require the operating software be replaceable. Other open-source developers are not willing to allow this sort of use; hence the GPLv3 anti-Tivoization restrictions.
[Disclaimer - I used to work at Motorola on Linux-phone development and occasionally had to represent this policy to open-source audiences. It's not the way I would do things myself, but there are reasonable arguments for it.]
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 14:32 UTC (Fri) by foom (subscriber, #14868) [Link]
> there are reasonable arguments for it
In the case of Apple's iOS, there are reasonable arguments for it [Apple doesn't want people selling apps for the iPhone/Pod/Pad without paying the Apple Tax on each app sold].
In the case of Motorola's Android hardware, I really can't see what's in it for them.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 16:34 UTC (Fri) by sepreece (subscriber, #19270) [Link]
Motorola worries a lot about gray markets - about the possibilities that it might sell phones through one carrier or market at one price and have a third party buy them, reflash them (possibly turning on features the first vendor didn't), and resell them in competition with one of its distributors.
This does happen with some kinds of products. It's reasonable for a manufacturer to want to control it.
I'm not particularly defending the policy, just trying to explain it.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:14 UTC (Fri) by donbarry (guest, #10485) [Link]
I beg to disagree. Not all agree that using Linux (the kernel) inside a
device does not require the operating system to be replaceable. That Linus (the person) says so only proves that there exist multiple perspectives.
GPLv3 made fully explicit what is both implicit and explicit in GPLv2 under
What has not occurred is litigation to establish this within a legal framework.
That what Motorola and others are doing is wrong in an ethical framework is
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:34 UTC (Fri) by rsidd (subscriber, #2582) [Link]
The thing I find creepy here is the "e-fuse" described in patrick_g's links below, that bricks the device if any attempt is made to change the firmware. I certainly don't want such "features" on my phone, even if I only ever intend to use the phone to make phone calls.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:41 UTC (Fri) by swetland (subscriber, #63414) [Link]
I've seen no indication that Motorola is using the efuse features to destroy phones as some kind of anti-third-party-firmware countermeasure. I would be quite surprised if they did, given that, in my experience, OEMs have a deep and abiding fear of anything that could lead to an RMA or support calls.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 16:23 UTC (Fri) by lutchann (subscriber, #8872) [Link]
I would be very surprised as well to see devices self-destruct if POST firmware checksums don't match. Why would any manufacturer want to turn a sporadic flash read error into a permanent one?
Kuhn: At Least Motorola Admits It Posted Jul 17, 2010 3:40 UTC (Sat) by butlerm (subscriber, #13312) [Link] I don't see why it is not a reasonable paraphrase. Motorola's representative is recommending that developers buy one of two non-Motorola phones (ADP1 or Nexus One, both made by HTC). What could be more explicit than that? If you're interested in developing, don't buy Motorola.This is what the Motorola representative actually said (after a paragraph describing their application development environment): We understand there is a community of developers interested in going beyond Android application development and experimenting with Android system development and re-flashing phones. For these developers, we highly recommend obtaining either a Google ADP1 developer phone or a Nexus One, both of which are intended for these purposes. At this time, Motorola Android-based handsets are intended for use by consumers and Android application developers, and we have currently chosen not to go in to the business of providing fully unlocked developer phones.That is a far cry from "seeking to leave developers as helpless *as possible*". Motorola has extensive support for _application_ developers, just not for system developers. The only reasonable conclusion from the original "paraphrase" is that either someone is about to get fired or the poster is making things up for effect. To say nothing of engaging in highly selective quotation.
Kuhn: At Least Motorola Admits It Posted Jul 22, 2010 20:41 UTC (Thu) by nix (subscriber, #2304) [Link]
They recommend obtaining phones that are no longer to be manufactured! Excellent advice, or something.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 6:47 UTC (Fri) by patrick_g (subscriber, #44470) [Link]
Have you seen these links ? It's very interesting.
http://www.mydroidworld.com/forums/droid-x-discussion/333...
http://laforge.gnumonks.org/weblog/2010/07/16/#20100716-m...
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 18:31 UTC (Fri) by richardw (subscriber, #23638) [Link]
Those links description of the brick condition is not correct. A more accurate description can be found on this link. Approved software (signed by Mot) will work boot.
http://www.engadget.com/2010/07/16/motorola-responds-to-d...
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 19:16 UTC (Fri) by Trelane (guest, #56877) [Link]
It's rather lacking details. The eFuse is clearly somehow involved:
"In reference specifically to eFuse, the technology is not loaded with the purpose of preventing a consumer device from functioning, but rather ensuring for the user that the device only runs on updated and tested versions of software. If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed."
*what* it does precisely is rather undefined. That it modifies the silicon, however, is uncontested:
"pecifically, the culprit is said to be a technology known as eFuse -- developed by IBM several years ago -- which allows circuits to be physically altered at the silicon level on demand."
http://en.wikipedia.org/wiki/EFUSE
So perhaps it's not permanent, although the linked article on antifuses indicates that they are.
Conclusion seems to be that more data is needed. :)
Kuhn: At Least Motorola Admits It Posted Jul 18, 2010 21:37 UTC (Sun) by jzbiciak (✭ supporter ✭, #5246) [Link]
I sincerely doubt they'd be blowing e-fuses due to a reflash. Blowing e-fuses tends to require special device modes (ie. engaging factory test mode) and may require voltages that may not even be available in a deployed configuration. In at least some cases, I don't think they even work on packaged parts. (I've heard stories about caps blowing off of device packages, but that was many years ago when the transistors were much bigger and the voltages higher.)
E-fuse tends to be used for things such as RAM repair (diverting bad RAM columns/rows to redundant good columns/rows), changing the RAM read timing margins, tweaking the requested supply voltage to minimize leakage, that sort of thing. Basically, it just adjusts certain parameters to compensate for both minor defects and process spread, so that you get more (and better!) working parts out of the same batch. But, that happens once during device characterization at the factory. This isn't some Terminator 2 morph-on-the-fly thing that's continually changing once deployed, like Wikipedia's brief summary implies.
E-fuse also gets used for device specific identifiers and keys. Again, that's a "blow-once and then package the part" sort of action. Once all the E-fuses have been programmed, you generally want to lock down any further programming so that a transient device failure (battery glitch, cosmic ray, whatever) doesn't become a permanent one. In the e-fuse controllers I know of, there are "disable future writes" fuses that once blown makes the fuse settings it controls permanent.
E-fuse could be involved in that it holds the device specific ID or key that prevents you from moving a flash image from one phone to another. But, that's a read-only application of E-fuse.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 0:52 UTC (Mon) by Trelane (guest, #56877) [Link]
Could be. We have very very few details about how precisely it's involved.
Sadly, many times I've said "they couldn't possibly be that stupid" yet to find out that yes, yes they are. *shrug*
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 1:09 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] I did some googling around, and it appears the Droid X is based on a newer OMAP device. I work for TI, but I only have passing familiarity with the OMAP specifics. From what I remember in our other devices, we don't let our customers program e-fuses. We do that for them at the factory. More than likely, they're using M-Shield, which I'm reasonably certain provides for binding content and code to a specific device (ie. a specific Droid X phone) or devices (all Droid X phones), and only allowing signed code to load. E-Fuse is just the technology that allows storing key information in the device to that that can work, kinda like TPM chips do in a PC environment. If that's the case (and it seems the most likely), then it matches up nicely with Motorola's statement that you can re-flash an authorized image to restore the device's original functionality. Take off the tin-foil hat and apply Occam's Razor. The simplest explanation is most likely the correct one.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 2:28 UTC (Mon) by Trelane (guest, #56877) [Link]
"I work for TI, but I only have passing familiarity with the OMAP specifics"
ah, cool. I just toured down there with a group of student from ou/uark a couple of weeks ago (we saw the fab in dmos 6, I think it was).
"From what I remember in our other devices, we don't let our customers program e-fuses."
That's at odds from the report, which says that the bootloader tells the efuse to blow. (follow slashdot->mobilecrunch->mydroidworld forum posting by "ps3droid").
However, the original post that kicked this whole thing off was
"So this post is a mix of hard information and a bit of conjecture on my part (guesses)."
How much is of each is unstated. and I've no idea who this person is or how he/she got his/her information. So the trail grows cold here.
*shrug* The ultimate source of the *fuse* bit is rather misty, so I think I'll have to give mot the credit of the doubt (although I'd give pause before handing over hundreds of my own hard-earned dollars).
"it matches up nicely with Motorola's statement that you can re-flash an authorized image to restore the device's original functionality."
Well actually the quote is that
It doesn't say that the end-user can do the re-install and recovery, only that it will reboot once approve software has been re-installed. Is the efuse one-way, or can it be reset?
"Take off the tin-foil hat and apply Occam's Razor."
"tin-foil hat" tends to be used deprecatingly, and I tend to bristle when people accuse me of wearing a tinfoil hat. Perhaps you didn't mean to be insulting; I'll give you the benefit of the doubt. Regardless, hard experience (e.g. I'm a ps3 owner who bought the ps3 more for the linux than for the games; sadly it's now gotta be 100% linux) has taught me to be very, very, very cautious when I regard what large businesses (and other entities in general, although the power disparity in a relationship with a large megacorp as an end-user is so absurdly large that we mice have to beware of the elephant's feet!) say, and look at the *letter* of what they say, not the spirit.
However, permanent, temporary, carrier-serviceable, or other, the core point that Kuhn makes is clear; Mot doesn't seem to appreciate end-user freedom. and I'm rather fond of maintaining my freedoms.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 3:28 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] That's at odds from the report, which says that the bootloader tells the efuse to blow. (follow slashdot->mobilecrunch->mydroidworld forum posting by "ps3droid"). However, the original post that kicked this whole thing off was "So this post is a mix of hard information and a bit of conjecture on my part (guesses)." The e-fuse part seems to be pure conjecture based on seeing the name of the technology in M-Shield's key storage (e-fuse), and then thinking it must work like the ones you buy down at Radio Shack, or the thermal fuse you find in an average coffee pot. ie. If you accidentally do something bad with the device, it blows its fuse and refuses to work until the fuse is replaced. The thin description on Wikipedia doesn't help. In my experience with other secure devices I've worked directly with at TI, only the factory (TI) blows e-fuses. E-fuses are used more like jumpers of yore (only shrunk to be on the die) than like the ones in your fusebox in the garage. We architect our software and arrange our manufacturing flows accordingly. (Beyond that level of description, I'm not sure where I cross into proprietary information, so I'll stop there.) It doesn't say that the end-user can do the re-install and recovery, only that it will reboot once approve software has been re-installed. Is the efuse one-way, or can it be reset? The e-fuse technology in OMAP is one-way, if it's at all like the e-fuses I've worked with before. You can't unblow an e-fuse. The fact that the device is recoverable by a reflash implies that nothing truly permanent has happened to the device. Now, I don't know anything about the Droid X and how Mot's "recovery mode" works. This mode should be the same mode the phone goes to if a legitimate update fails, say, due to a power glitch during the update. It may be that to recover the phone requires a special tool or device or bit of software that only Mot's authorized service centers have access to. That's got nothing to do with the e-fuse question at hand, though. It just determines how you restore the phone once it's been flashed with unauthorized code. When I said "you", I didn't mean you specifically. I just meant that Motorola's statement makes it clear that the device isn't a brick, it can be reflashed with the right equipment. "Tin-foil hat" tends to be used deprecatingly, and I tend to bristle when people accuse me of wearing a tinfoil hat. There seems to be a lot of wild speculation about that assumes the worst possible motives on the part of Motorola, and what I was saying is that you don't need wild conspiracy theories about Mot bricking phones on purpose to explain this. Refusing to load unsigned code until a service center reinstalls it isn't nearly so malevolent as irreversibly destroying the phone. The former may require a trip to the service center, and the latter requires you to buy a new phone. Motorola built a phone that is meant to be used as a consumer gadget with its walled garden, and it disabled jail-breaking as part of the process. It still allows folks to develop Android apps, but it doesn't allow people to replace the OS image. I imagine this is in part at the urging of the carriers, but I don't know. the core point that Kuhn makes is clear; Mot doesn't seem to appreciate end-user freedom. and I'm rather fond of maintaining my freedoms. No doubt about that. It's a consumer electronics market, and that's the default in that space: Everything's a closed, sealed appliance; no user serviceable components inside. I'm not saying that's the way I'd like it to be, I'm just saying that that's how it currently is. It's more than enough for 99% of the people out there who run away screaming from anything too complicated. Folks at work keep asking me why I didn't buy one of several Android phones, including the easily-rooted ones, when I bought my latest phone. I told them I didn't want to have to root my phone to be able to use it in the way that I want. I feel like that's just asking for trouble. It's not really the intended mode of operation for Android, even if I buy a pre-rooted phone. So, I have an N900 instead, and I had a working Xterm straight out of the box, no hacking required. A few taps later, and I have working a working compiler, VPN, Subversion, yadda yadda all on the phone. And I know it's never going away.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 3:57 UTC (Mon) by Trelane (guest, #56877) [Link]
"The e-fuse part seems to be pure conjecture based on seeing the name of the technology in M-Shield's key storage (e-fuse), and then thinking it must work like the ones you buy down at Radio Shack, or the thermal fuse you find in an average coffee pot. ie. If you accidentally do something bad with the device, it blows its fuse and refuses to work until the fuse is replaced. The thin description on Wikipedia doesn't help."
Right, but the problem is that we have only conjecture about what parts are true, which parts are false/wrong, and what parts are conjecture. :)
"E-fuses are used more like jumpers of yore (only shrunk to be on the die) than like the ones in your fusebox in the garage. We architect our software and arrange our manufacturing flows accordingly. (Beyond that level of description, I'm not sure where I cross into proprietary information, so I'll stop there.)"
No worries; I respect that (I used to work at a large hard drive manufacturer for two summers). It sounds a lot like this is a plausible scenario.
"The fact that the device is recoverable by a reflash implies that nothing truly permanent has happened to the device."
Well, no. Strictly speaking, Mot says
"If a device attempts to boot with unapproved software, it will go into recovery mode, and can re-boot once approved software is re-installed."
How the re-installation can occur is completely unspecified. It could conceivably be that the OP was correct that the software can fuse a selected part in order to require you to go back to the shop and get a new chip, or get a second fuse blown for you (perhaps something like DVD drives do where you get five free reflashes at the store and then it's clear you're a baddie and you have to buy a new phone (or even just a new chip)) It's hardware/software; the primary constraints are laws, consumer (or customer, if they're like me and know and use the distinction) reaction and how much we can pack into a chip before it's too big/consumes too much power. Hooray for digital progress!
"This mode should be the same mode the phone goes to if a legitimate update fails, say, due to a power glitch during the update." It *could* be the same, but we have only supposition.
"That's got nothing to do with the e-fuse question at hand, though. It just determines how you restore the phone once it's been flashed with unauthorized code."
They might be unrelated. They might not be unrelated. We have no [b]data[/b], we have only supposition (and layer upon layer of it). There are definitely scenarios that could involve the fuse, even if the supposition that the fuse is permanently blown is true.
"Refusing to load unsigned code until a service center reinstalls it isn't nearly so malevolent as irreversibly destroying the phone."
Malevolence is motivation and rather tangential to the questions at hand. Rather, the question is what the [i]problems[/i] to us would be. and how problematic having a phone be a brick until you get it to a service center depends on a lot of things, and notably how far and inconvenient it is to get to the service center. :)
To summarize, my current position is that we need a lot more data before we can draw reliable conclusions about anything in this situation. Hopefully mot will be forthcoming with it. I'm very very glad you brought more data to the table. Despite not necessarily being directly transferable to the mot scenario, they're at least indicative about the state of current technology.
"I told them I didn't want to have to root my phone to be able to use it in the way that I want."
I'll drink to that! (Is incidentally why I don't have an iphone; my mac fanatic friends/colleagues said, well just root it to get an xterm and ssh.. riiiiight. "Jailbreaking" is rather a poor metaphor; rather, it should be something like hostage-freeing perhaps, or something involving a raid on a property theft ring and getting your TV back. :)
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 9:33 UTC (Mon) by mpr22 (subscriber, #60784) [Link] It could conceivably be that the OP was correct that the software can fuse a selected part in order to require you to go back to the shop and get a new chip, or get a second fuse blown for you I would be surprised, given a device equipped to update its own firmware without return-to-base, if they designed it in a way that meant their service department would have to remove the casing, demount the screen, rework the PCB, remount the screen, and reinstate the casing just to recover the firmware if the update glitched. (The manufacturer lockdown module is unlikely to be able to tell the difference between "misprogrammed official firmware" and "unofficial firmware", and a mobile phone doesn't have room for socketed components.)
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 9:59 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
I agree.
It also seems extremely unlikely that they'd pick the most complicated and likely most expensive chip on the board (OMAP3) and blow e-fuses within it to implement such a scheme. That more or less would translate into needing to swap out the entire PCB that contains the OMAP.
It seems quite sufficient for the device to just check the flash signature and go to a recovery mode on signature failure, especially since TI builds that function into the ROM and CPU (M-Shield, linked above). It just uses e-fuse for key information.
So, while it's technically possible they could have a truly self-destructing phone, it seems extremely unlikely.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 11:43 UTC (Mon) by Trelane (guest, #56877) [Link]
*shrug* You're probably both right. Especially since the source is a dude on the internet. :)
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 16:08 UTC (Fri) by Aliasundercover (subscriber, #69009) [Link]
It seems to me developer friendliness is beside the issue. The phone is booby trapped to self destruct. That is plain old simple fraud.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 7:20 UTC (Fri) by Janne (guest, #40891) [Link]
So, "developer-hostile" Apple has a phone with thousands of kick-ass apps, whereas "developer-friendly" openMoko was nothing but crap. "developer-friendly" Nokia is also crap.
If Apple is so hostile towards developers, why is it that their platform has the best apps? Why aren't the platforms that give developers the most freedoms leading the pack?
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 7:46 UTC (Fri) by rsidd (subscriber, #2582) [Link]
It is a good (and uncomfortable) question, especially since Apple's platform is very new, compared to Symbian and Windows Mobile in particular. One answer is, of course, that the universe of "developers" is much larger than the universe of "free software developers". Additionally, apps for phones are mostly not trivial ports of desktop apps, so a Linux-based or Windows-based phone doesn't really have a developer advantage over other systems. And, of course, the coolness factor of the iPhone -- which was truly revolutionary when it was introduced and has managed to stay at the front of the pack -- is its biggest advantage in attracting developers. Symbian is distinctly showing its age, "regular" (non-Android) Linux (whether Nokia or Palm or anyone else) is not there yet, and Windows was never cool: only Android looks like it can compete, but not if companies like Motorola start to dominate handsets.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 7:49 UTC (Fri) by fb (subscriber, #53265) [Link]
> If Apple is so hostile towards developers, why is it that their platform has the best apps? Why aren't the platforms that give developers the most freedoms leading the pack?
Because the devs are (largely) following the users.
[...]
Linux was in many ways more developer friendly than Windows, yet windows had more applications for it. Windows is the leading desktop platform, and therefore it is the first platform for most devs.
The iphone is (in a way) the leading phone platform, so most devs write first for the iphone. Surprised? I'm not.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 9:02 UTC (Fri) by RCL (guest, #63264) [Link]
Linux is more developer friendly? Not if you develop C/C++ applications.
1) Distributing binaries is hard (read this for longer explanation: http://www.gamedev.net/reference/programming/features/lin... )
2) Graphics & sound are both mess. You may safely target only NVidia proprietary drivers. OpenGL itself is not a developer-friendly API as it is much more high-level than Direct3D and you don't get the same level of control over hardware. Thanks God UNIX is not stuck with PHIGS though!
3) Debugging & profiling graphics applications is a joke. Is there anything like this: http://en.wikipedia.org/wiki/PIX_%28Microsoft%29 ? Has FSF's GDB got support for "Edit and Continue"? Can you easily debug full-screen applications or ones that grab your mouse?
Ohh... sorry, I probably didn't sleep well today and got into trollish mood.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 9:39 UTC (Fri) by niner (subscriber, #26151) [Link]
"Ohh... sorry, I probably didn't sleep well today and got into trollish mood."
Seems like, since you're completely missing that 3D games are not even a big part of all development. Not even of the development done in C/C++.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 11:13 UTC (Fri) by AlexHudson (guest, #41828) [Link]
Fundamentally, though, his point is pretty sound: Windows has always been about developers, has generally offered the very best development tools, and has been less successful when they've forgotten about them.
Additionally, free software has tended to be more successful where the developer tools are good: PHP for example, while not being a great language itself, gave developers a simple and straightforward web development platform.
I also wouldn't say Apple was developer-unfriendly per se; a lot of stuff they do is, but some stuff they do isn't: the iPhone api is relatively simple and provides developers with a lot of goodies, and people can get up and running on it pretty quickly. Same for Android in a lot of ways.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 14:14 UTC (Fri) by RCL (guest, #63264) [Link]
I believe that game development is the engine of the software market. They drive both software and hardware innovation. They are the only reason why "regular" people still buy Core i7 and Fermi.
This is probably applicable to some other "multimedia" applications.
From the developer standpoint, I believe that nothing streamlines the OS both API-wise and performance-wise better than listening to feedback that your game developers give you. Microsoft does that.
Back on-topic: I don't believe Android will beat Apple in developer-friendliness. That's not a first hand experience, but from what I know, right now Android is a mess:
No hardware specs at all:
1) some devices are hardware-accelerated in 16bpp, some in 24bpp, some aren't at all - with no clean way to query for that,
2) some CPUs do not have hardware floating point while some do,
3) there are four (optional) standards for texture compression, forcing game devs to ship 4 versions of the same textures,
Software also has its troubles:
1) there's a growing number of Android versions around, introducing fragmentation.
2) native code is shunned, and some APIs aren't available for it, making porting harder than it could have been...
Compare it with console-like Apple's platform with fixed specs and much wider deployment and decide yourself what would you develop for.
Kuhn: At Least Motorola Admits It Posted Jul 17, 2010 1:58 UTC (Sat) by cmccabe (subscriber, #60281) [Link]
> I believe that game development is the engine of the software market. They
> drive both software and hardware innovation. They are the only reason why > "regular" people still buy Core i7 and Fermi.
The engine of the software market is people's willingness to pay for software in its various forms. Software comes in the form of websites, a desktop applications, embedded systems, and hundreds of other forms. Payment comes in a lot forms too-- advertisements, royalties, commissions, etc.
Game development pushes the hardware market forward, but so does Moore's law, Microsoft's latest operating system, the new Office suite, and hundreds of a lot of other things. Game development often requires specialized hardware that the rest of the market doesn't have, like $500 graphics cards. Also, these days, more and more game development happens on special platforms called consoles.
> From the developer standpoint, I believe that nothing streamlines the OS
Really, what is so great about game development? The codebases for games are usually finished as quickly as humanly possible and then abandoned. Buggy code is much more acceptable in a game than it would be in a payroll application, or a scientific application, or pretty much anywhere else.
How many updates have you gotten for Grand Theft Auto 2 lately? Yeah, I thought so. None. But other applications written at the same period in time are still being updated and maintained.
Also, if anything, game development has lagged behind the rest of the industry in adopting things like Microsoft's .NET environment, Java, or Ruby. Whether or not you like these things, they are the future of application-level software development.
> from what I know, right now Android is a mess
Because it supports multiple hardware platforms, it's "a mess"? It will just have to join other messy platforms like Win32, POSIX, and just about every other successful platform in the history of computing. Too bad it can't be a nice, clean, platform like the open moko or Apple Lisa where only one version was ever made (because they were huge failures.)
The iPhone has multiple hardware revisions out now too. Some of them are faster than others. Some have higher resolutions. Deal with it.
Game development as the engine of the software market Posted Jul 18, 2010 16:52 UTC (Sun) by jrn (guest, #64214) [Link]
> Really, what is so great about game development? The codebases for games are usually finished as quickly as humanly possible and then abandoned. Buggy code is much more acceptable in a game than it would be in a payroll application, or a scientific application, or pretty much anywhere else.
I think that was RCLÂ’s point. Games have to be fast to develop, easy to deploy, and fast to run; so, the theory goes, if you pay attention to what game developers need then your system will be improved in these respects.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 10:54 UTC (Mon) by RCL (guest, #63264) [Link] > Also, if anything, game development has lagged behind the rest of the> industry in adopting things like Microsoft's .NET environment, Java, or > Ruby. Whether or not you like these things, they are the future of > application-level software development. That's not game developers' fault. That's fault of these languages which still fail to provide adequate control over hardware - enough to allow acceptable (sustainable!) performance on current PC hardware, not to mention consoles and/or mobile devices. Fix them, we'll use them.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 12:12 UTC (Mon) by farnz (guest, #17727) [Link] AIUI, game developers do use these safer languages for things like AI, where they're not tied into awkward real-time constraints; they then control the behaviour of the language runtime embedded into the game engine such that any adverse behaviour (like cacheline thrashing, or pauses caused by a stop-the-world GC) occurs at a point in time when the gameplay won't be affected. If language implementors want to attract game developers, they need to remember that games are soft real-time applications; a game developer cares massively about getting a stable frame rate, and isn't normally that bothered about getting an occasional burst of higher speed - 20fps sustained looks better than 30fps with a 3 frame pause every minute or two, and 30fps sustained looks better than 60fps with a slowdown to 50fps when things get busy.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 11:53 UTC (Fri) by Trelane (guest, #56877) [Link]
not sure about the rest (I think gallium probably is headed toward what you want on the debugging side), but it doesn't look like you know about the fact that installshield exists for Linux. (http://www.flexerasoftware.com/products.htm)
Rolling your own installer for a nontrivial program is always going to be a bear.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 12:03 UTC (Fri) by fb (subscriber, #53265) [Link]
I did qualify my assertion with "Linux was _in many ways_ ...". "Eco-systems" so large as Linux and Windows will always have different sub-groups which are worse or better in one respect or another.
In any case, people in this thread should be making a greater distinction between system developers and application developers. Both Android, and the iphone are quite supportive of application developers (Apple restrictions on cross-platform development, and vetoing of apps set aside for the moment). Both offer SDKs, stable APIs, and decent documentation.
The trouble with these new Motorola phones is not about application developers -they support the full Android API- but with system development and hacking.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:31 UTC (Fri) by Karellen (guest, #67644) [Link]
I'm reading the gamedev.net link, and it seems like a lot of bollocks to me.
"Newer versions of a [shared] library might use all new symbol versions, which would be unresolved in an older library version."
Uh, what? If a Windows developer has a more recent version of a 3rd party DLL than a tester, and the developer's version has functions which he uses which are not present in the testers older version, is the author seriously suggesting that Windows is capable of magic that inserts the missing symbols into the testers 3rd party DLL? Utter crap.
"Some distributions may not have all the libraries installed that you need. [...] game libraries like SDL, Ogg/Vorbis, and OpenAL may not be [available]"
Name 1 distribution that is not incredibly niche (say, must be in top 50 at distrowatch), and is meant to be general purpose (so, no specifically "minimal" or "rescue" distros), which does not provide any of the above libraries. If no such distro exists, I call FUD.
"if you link your executable against the OpenAL library, you may discover that the OpenAL library requires other libraries like ALSA, arts or esd"
And distros specify these things call "dependencies" so that if the tester installs OpenAL, all the libraries OpenAL requires are also installed automatically.
"Different distributions may build libraries differently."
OK. This one has the potential to cause problems, e.g. if you use OpenSSL's implementation of MD4, but a distro has not built MD4 support in its version of OpenSSL because it's so old and broken. I'm not sure it's particularly likely though. Most distros ship libraries as complete as possible to prevent this kind of problem - after all, every single one of the apps they provide that depend on that library have to work with the version they ship. So I'm sceptical as to how likely this is to happen in real life.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 16:52 UTC (Fri) by RCL (guest, #63264) [Link]
"Uh, what? If a Windows developer has a more recent version of a 3rd party DLL than a tester, and the developer's version has functions which he uses which are not present in the testers older version, is the author seriously suggesting that Windows is capable of magic that inserts the missing symbols into the testers 3rd party DLL? Utter crap."
I guess his point is that in Windows world you always ship all the DLLs you rely upon (except for system ones, which are extremely stable). Sometimes you ship system dlls, too (e.g. before introduction of manifests most programs shipped their own msvcr70.dll which is libc). Shipping DirectX redistributables is a standard practice as well.
"Name 1 distribution that is not incredibly niche (say, must be in top 50 at distrowatch), and is meant to be general purpose (so, no specifically "minimal" or "rescue" distros), which does not provide any of the above libraries. If no such distro exists, I call FUD."
Again, his point is that you cannot download the binary application from the web and run it (as is customary in Windows world). You have to instruct the user to install (using his distro's package manager) all the missing dependencies, which is not really a solution for certain types of users (ones that happen to play games the most, who want a click-and-run experience).
You may avoid it by packaging your application for all the supported distros so it integrates well with your user's package manager, but it is not a perfect solution either (he explains why: because you have to rebuild and repackage the application every time a distro in your supported set gets updated, which is inconvenient).
So his solution is to recompile the "middleware" libs you use so they depend only on really basic (and widely available) libraries and ship them with your application, akin to how Windows developers do. That's a reasonable practice and in fact NVidia and other commercial vendors often do this.
If I was to ship commercial application for Linux, I'd go this way, too.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 17:18 UTC (Fri) by Trelane (guest, #56877) [Link]
"his point is that you cannot download the binary application from the web and run it (as is customary in Windows world)."
If that is indeed the point, then it's wrong. Such systems, e.g. InstallShield are available to do just that.
"You have to instruct the user to install (using his distro's package manager) all the missing dependencies, which is not really a solution for certain types of users (ones that happen to play games the most, who want a click-and-run experience)."
No, you don't. You can something like InstallShield, like you do on Windows.
"So his solution is to recompile the "middleware" libs you use so they depend only on really basic (and widely available) libraries and ship them with your application, akin to how Windows developers do. That's a reasonable practice and in fact NVidia and other commercial vendors often do this."
There's more to it than just compiling, which is where installer systems come in.
Kuhn: At Least Motorola Admits It Posted Jul 17, 2010 0:41 UTC (Sat) by shmget (subscriber, #58347) [Link]
"Linux is more developer friendly? Not if you develop C/C++ applications."
We are in 2010 and Microsoft still doesn't have a C99 compliant compiler.
Kuhn: At Least Motorola Admits It Posted Jul 18, 2010 12:03 UTC (Sun) by cortana (subscriber, #24596) [Link]
And we're in 2010 and we still don't have a debugger like Visual Studio. One that can actually look inside the standard C++ containers rather than uselessly revealing that your iterator is an un-nameable struct containing a single _M_thing pointer. One that supports edit-and-continue. The knife cuts both ways. MS, for their part, say that they haven't bothered to implement C99 features because their customers haven't asked for them.
Kuhn: At Least Motorola Admits It Posted Jul 18, 2010 13:04 UTC (Sun) by foom (subscriber, #14868) [Link]
> One that can actually look inside the standard C++ containers
We do have that, at least, in GDB 7.
Kuhn: At Least Motorola Admits It Posted Jul 18, 2010 13:16 UTC (Sun) by cortana (subscriber, #24596) [Link]
And I've actually used it, and it does not (yet) compare to Visual Studio's debugger. :(
Kuhn: At Least Motorola Admits It Posted Jul 18, 2010 14:13 UTC (Sun) by Trelane (guest, #56877) [Link]
Could you perhaps expound on this, with concrete examples?
Kuhn: At Least Motorola Admits It Posted Jan 20, 2011 15:39 UTC (Thu) by cortana (subscriber, #24596) [Link]
Sorry this has taken so long. I've been very busy. This is probably my biggest bugbear: rp is a map<string, foo>::iterator.
>(gdb) p rp
Ok, but listing all the members at once is annoying: there are many of them, and some of them are vectors that themselves have many elements.
> (gdb) p rp->second.bar
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 13:58 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]
If you've used it, why do you say it doesn't exist?
If your beef was really with the crappy gdb UI, not any missing features, why not just say so?
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 8:46 UTC (Fri) by vadim (subscriber, #35271) [Link]
Nokia doesn't only make Symbian stuff.
I'm very happy with the N900, it's exactly the sort of thing I was looking for.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 11:49 UTC (Fri) by paragw (subscriber, #45306) [Link]
May be it is just about the good ole money? Isn't it obvious that Apple had a great head start in mobile application development and distribution and their phone sells to loads of users that actually don't shy from spending money and so the most chances of making money from a developer standpoint are still on Apple's platform?
And with Android starting to compete very well with Apple iPhone - if the momentum continues you will see even better development tools, even more ISV interest on Android. I wouldn't be surprised if you see the best apps coming to Android first once developers start making money.
Same for Palm webOS - if they put out more modern hardware people will actually buy their phones and they already have pretty good development tools.
I don't think it has anything to do with developer freedom - not yet anyways. But I hardly think that's going to be the case if Android and webOS continue to increase their potential of making the developers money. If developers can make equal or more money on Android and WebOS obviously they will prefer more flexible and open platforms without the uncertainty associated with the App Store.
And we can stop talking desktop apps/games - no one buys apps on Linux.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 11:58 UTC (Fri) by Trelane (guest, #56877) [Link]
"And we can stop talking desktop apps/games - no one buys apps on Linux. "
You need to update your antiquated set of misconceptions.
http://2dboy.com/2009/10/26/pay-what-you-want-birthday-sa...
Didn't you get the memo?
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:11 UTC (Fri) by paragw (subscriber, #45306) [Link]
LOL! I am fairly certain you are not serious but yeah I guess we could say that 11350 real people buying a game for running on Linux desktop along with a rumor of Valve bringing Steam to Linux - that is as good as any news can get for Linux gaming!
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:34 UTC (Fri) by Trelane (guest, #56877) [Link]
I was being serious.
Taken literally, your statement that "no one buys apps on Linux" is wrong.
Taken figuratively, your statement is also wrong. Linux users are willing to pay for apps, and what's more they're also willing to pay *more* for apps. Linux gamers donated 25% of all humble bundle revenue. What's more, 2dboy saw more detailed statistics: http://2dboy.com/2009/10/26/pay-what-you-want-birthday-sa... Note the per-user platform averages. What's more, "Also, the per-platform download breakdown was pretty surprising, with Windows accounting for 65%, and Mac and Linux pretty much splitting the remainder evenly. [pie chart]"
an analysis of how this increased spending jibes with big titles (why they don't sell hugely on non-windows platforms is at one of the humble bundle's blogs, http://blog.wolfire.com/2010/05/The-state-of-Mac-and-Linu.... Very informative reading which explains all the data we have to date.
Like I said, you need to get a new trolling line. You *did* get the memo, didn't you?
Now, about your TPS reports.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 16:41 UTC (Fri) by paragw (subscriber, #45306) [Link]
Sigh. Way to take one tidbit and make a mountain of "evidence" out of it. Come on you understand that selling a charity ware game once and showing marginally better, questionable numbers does not count as significant success for Linux in the gaming department. Not sure I want to argue further on a very "literal" but at the same time very "flexible-at-drawing-conclusions" type of ground.
PS There was no need to play the troll card. That would have been warranted if Linux was Windows of gaming and I was saying "literally" no one ever bought a game for Windows.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 17:12 UTC (Fri) by Trelane (guest, #56877) [Link]
"Way to take one tidbit and make a mountain of "evidence" out of it. "
So you're saying it's not a representative sample. Could you bring some other facts to the table?
"selling a charity ware game once"
They weren't charityware, and it wasn't once.
"questionable numbers"
Unsupported statement.
Could you please bring some actual *data* to the table?
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 19:23 UTC (Fri) by misiu_mp (subscriber, #41936) [Link]
Note the figures from the "pay what you want" sale do not include the ordinary sales. Apparently when the game became available for Linux, the sales for that platform broke daily records for all other platforms.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 19:35 UTC (Fri) by Trelane (guest, #56877) [Link]
I'd forgotten that; thanks!
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 12:03 UTC (Fri) by Trelane (guest, #56877) [Link]
"their platform has the best apps?"
I don't think you've proven this central aspect of your argument conclusively.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 14:28 UTC (Fri) by Janne (guest, #40891) [Link]
Well, they have the widest selection by far (even though they entered smartphone-business years later than their competitors did), even though they are supposedly "developer-hostile" and they are only at third-place when it comes to global smartphone-sales. And when I read comparisons between iOS and Android, it always seems to be about how Android-apps lack refinement when compared to iOS-alternatives.
And Symbian is utter crud. Maemo seems better but it too seems awkward and cumbersome, even when compared to Android.
How did Apple manage all this if they are so "developer-hostile"?
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 14:57 UTC (Fri) by dskoll (subscriber, #1630) [Link] How did Apple manage all this if they are so "developer-hostile"? Apple managed this by creating a brand and keeping an iron grip on their platforms. They are developer-hostile (their terms of use for developing on the iPhone and iPad are disgusting), but because of their loyal customer base, developers put up with that to make money. Also, you need to distinguish between developers and hackers (in the good sense of the word.) Apple needs to have developers make apps for its products, but it hates hackers because they loosen its iron grip. I would never develop for Apple nor buy any Apple products, but that's because I value freedom. Sadly, most consumers value flashiness and brand image over freedom.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:03 UTC (Fri) by paragw (subscriber, #45306) [Link]
"And when I read comparisons between iOS and Android, it always seems to be about how Android-apps lack refinement when compared to iOS-alternatives."
I suggest actually trying out Android apps instead of reading the biased kool-aid flavored, subjective comparisons.
Sure you could go out and download a random app from Android Market and compare that with some curated iOS app and then complain about the lack of refinement but that is not to say the whole of Android apps suck or that there is something wrong with Android UI. As with every other open platform you need to pick your apps carefully. There is no wall to guard you.
Ever since I got my N1 - my iPod touch 3G sees no use at all. I actually hate the limited experience. I don't use every app in the store - I do spend a minimal effort scanning through the list of apps and their ratings whenever I need that occassional new app but most of the ones I end up using are very reasonably polished and refined. And the notification system along with multitasking makes the whole experience way better than what I have today with iOS 4 on the iPod Touch.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:35 UTC (Fri) by Zack (guest, #37335) [Link]
>are supposedly "developer-hostile"
Nothing "supposedly" about it, nor is there any need to put
>How did Apple manage all this
Just because they haven't harmed the majority of their developers doesn't mean they are developer-friendly.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 13:54 UTC (Fri) by adesharatushar@gmail.com (guest, #49449) [Link]
Developer needs to be paid, either in cash (as in case of Apple) or in code which is usable and free (free to run, modify and distribute). None of the current open OS allow developer to treat his phone just like a computer with 2G/3G modem for voice and data.
Also few bad experience in past (e.g. Sony Play Station and One Laptop per child changing its Linux policy midway) with open but not open enough hardware may be reason of reluctance of free software developer for mobile app.
Unless some big company comes up with really open hardware, this looks difficult.
Nokia's N900 seems only hope for now. One more hope is HTML5 which is far more powerful and can be easily used for simple to moderately complex apps.
Kuhn: At Least Motorola Admits It Posted Jul 19, 2010 14:11 UTC (Mon) by liljencrantz (subscriber, #28458) [Link]
My n900 is pretty much just that. It uses a pretty standard Debian based Linux stack with Linux, busybox, X, gstreamer, dpkg, apt, dbus and pulse. Because of the small physical dimensions of the device, it uses a custom fullscreen window manager, but porting apps to it isn't all that hard. MyPaint has been converted to run on the n900 and the results are amazing. I installed a custom compiled kernel version. I could run debian in a chroot.
A few of the kernel drivers are proprietary, so in order to make full use of the hardware, you must use a kernel version with an identical ABI. Many of the applications, like the dialer, are proprietary, so to run a fully open user space, you'll have to replace them, which is entirely possible.
The n900 may not be perfect, freedom wise, but it is easily close enough that it can be used like a tiny laptop with a data/voice modem.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 15:38 UTC (Fri) by gorpon (subscriber, #25040) [Link]
'"developer-friendly" Nokia is also crap. '
What do you mean by crap? I am having lots of fun and getting a lot of use from maemo apps and features on my n900.
The Ovi store may not have a ton of free apps for download, but the maemo does have a lot of the standard software you would expect to see on or available to a more conventional desktop install of debian or ubuntu (x-windows, wireshark, pidgin, snes and bochs emulators, freeciv, vpnc, gnumeric, etc...)
The last time I checked there was no way to run an x-server for android(outside of vnc) or the iPhone. Well it works out of the box in maemo.
This morning I wrote a python script on my phone that helps me catch my morning train. :)
Last week I had windows 95 running inside of bochs on it. :)
shiny vs freedom, shiny wins Posted Jul 17, 2010 15:21 UTC (Sat) by nhippi (subscriber, #34640) [Link]
Open platforms are not "leading the pack" for a simple reason. Most endusers simply dont mind being locked down to play in a sandbox. LOCK ME IN HARDER, just GIVE US MOAR SHINY APPS! And the minority that minds, is happy to use jailbroken iphones and other unofficial and possibly risky hacks to gain their freedom (and access to pirated apps).
There is simply too few who believe vendors should give them freedom by default. And even they expect the vendor to provide something that works reliably out of box. OpenMoko betted on being community friendly would attract developers to finish the loose ends, which clearly didn't work out. The Nokia N900 otoh isn't "open enough" for the freedom purists. For others, N900 doesn't have enough shiny.
As long as more people prefer "shiny" over "freedom", the vendors will continue to have shiny as their #1 priority.
Kuhn: At Least Motorola Admits It Posted Jul 16, 2010 18:32 UTC (Fri) by waucka (subscriber, #63097) [Link]
This news makes me feel ashamed to own a Droid. I will definitely not be purchasing any other product from Motorola ever again.
Kuhn: At Least Motorola Admits It Posted Jul 21, 2010 3:06 UTC (Wed) by Kamilion (guest, #42576) [Link]
Just recently got a Motorola Droid nee Milestone via work.
I've had it for less than a week, already rooted it, got cyanogen6 and jdlfg's low voltage '7-slot' 1.2Ghz kernel.
Oops. Apparently nobody told the Cortex A8 that 600MHz was it's limit. (!)
7-slot indicates how many clock speeds are available for the linux power management ondemand governor to choose from. This one steps at 250/400/500/700/1000/1100/1200Mhz, but you can set a thermal limit in SetCPU, which will restrict the speeds back down during high temperatures.
Browsing the web with dolphin and flash 10.1 is nice and speedy, sitting down to play some killer instinct was honestly better than my old PSP by far. Picked up a little rubber 'gamegripper' that overlays a D-pad and the familiar four button gamepad cluster over the keyboard. Honestly, after previously playing around with a nexus one, I'm much happier with the hacked droid.
As for my apps, I paid for the xtralogic RDP client, since I can't find a nxclient or x2 client, at least I can connect to xrdp. VNC's actually more of a pain; I have to unlock my pubkey in ConnectBot, connect over SSH, add a port forward, then use android-vnc-viewer to connect to localhost with connectbot running in the background. Any hiccups in the SSH connection kills VNC. Ick. Barada's kind of cool, nice two-factor app. Dropbox for files, Evernote for voice recording, Titanium Backup, and sipdroid to connect to our asterisk pbx at work. Round it out with a couple emulators to pass idle time, and the various google nav apps.
Motorola makes some nice, compact, powerful hardware; that's to be sure. Locking us out of it is a crying shame.
Kuhn: At Least Motorola Admits It Posted Jul 21, 2010 11:09 UTC (Wed) by Trelane (guest, #56877) [Link]
Cool. Thanks for the post!
It's good to know that it's rootable, despite their attempts to the contrary.
Kuhn: At Least Motorola Admits It Posted Jul 21, 2010 16:36 UTC (Wed) by bronson (subscriber, #4806) [Link]
The Droid was always hackable. It's the Droid X that has the eFuse. Nobody's managed to get around it yet.
http://www.engadget.com/2010/07/16/motorola-responds-to-d...
|
|
||||||||||||