Point 1: So far, based on the projects we've done, there isn't a Linux phone out there yet that matches an RTOS (Real Time Operating System), Symbian or WinMo phone for general quality of finish. One of the core problems here is you, as the user, really don't want to be reflashing your phone ROM too much - it's not something I'd do with something I'd paid for, but I'll let people do it with test hardware I'm leant.
Of the several dozen live phone projects we're working on at the moment, only 1 or 2 are Linux and most of those have ended up "dumped" on the market in China because none of the European networks would accept them quality wise. It's why I'm agnostic about Android, there's been several Linux/Java platforms produced and most of them have flopped because in order to keep them working they have to be locked down to a certain extent to avoid somebody buggering up some of the hard stuff.
Point 2: Split into many little points... This is a tricky one. As another person mentions, the easiest way to get around this is to have a second processor running the radio stack and have a command line interface to the OS - historically this would be AT commands, although most people are moving to an open API. This is easy to build, and is the approach Apple took, however, you'll find it won't be as reliable as a purpose build phone platform like you'd get from Sony Ericsson or Nokia. It also pushes the price up. From what I've been told, this is also true of the iPhone as an actual phone, but most people don't mind because it's shiny.
Having 2 cores also pushes the prices up and makes power management a nightmare, so what you see are most of the silicon providers pushing for single core where the radio and application processor are on the same chipset. This is harder to integrate and get to work, but the results are worth it. Of course, testing and debugging a phone to the expected quality of a typical user is a huge undertaking and requires access to a lot of really really expensive kit, like Anite or Rhode and Swartz network emmulators and a real Faraday cage. I worry that the open source people won't have access to these million dollar goodies.
Finally, network security and networks are a problem which is why, to a greater or lesser extent all the open source options will either be locked down or come without the network logic which will have to be added as a black box later. Manipulating, for example, the Quality of Service system on a WCDMA network can tear down a local cell and I don't think that the phone companies nor the government will be happy with people being sold a hacking tool for networks.
Even then, quality can be a problem. I know of a trial in 2003 where 20,000 test phones pulled down a major network's Base Stations in the London area.
Android is more likely to be a better bet and work better because Google are at least subsidizing the phones, but I just don't see true Open Source surviving an encounter with the demands of consumer quality mass market products with significant 3rd party dependancies.
no subject
Point 1:
So far, based on the projects we've done, there isn't a Linux phone out there yet that matches an RTOS (Real Time Operating System), Symbian or WinMo phone for general quality of finish. One of the core problems here is you, as the user, really don't want to be reflashing your phone ROM too much - it's not something I'd do with something I'd paid for, but I'll let people do it with test hardware I'm leant.
Of the several dozen live phone projects we're working on at the moment, only 1 or 2 are Linux and most of those have ended up "dumped" on the market in China because none of the European networks would accept them quality wise. It's why I'm agnostic about Android, there's been several Linux/Java platforms produced and most of them have flopped because in order to keep them working they have to be locked down to a certain extent to avoid somebody buggering up some of the hard stuff.
Point 2: Split into many little points...
This is a tricky one. As another person mentions, the easiest way to get around this is to have a second processor running the radio stack and have a command line interface to the OS - historically this would be AT commands, although most people are moving to an open API. This is easy to build, and is the approach Apple took, however, you'll find it won't be as reliable as a purpose build phone platform like you'd get from Sony Ericsson or Nokia. It also pushes the price up. From what I've been told, this is also true of the iPhone as an actual phone, but most people don't mind because it's shiny.
Having 2 cores also pushes the prices up and makes power management a nightmare, so what you see are most of the silicon providers pushing for single core where the radio and application processor are on the same chipset. This is harder to integrate and get to work, but the results are worth it. Of course, testing and debugging a phone to the expected quality of a typical user is a huge undertaking and requires access to a lot of really really expensive kit, like Anite or Rhode and Swartz network emmulators and a real Faraday cage. I worry that the open source people won't have access to these million dollar goodies.
Finally, network security and networks are a problem which is why, to a greater or lesser extent all the open source options will either be locked down or come without the network logic which will have to be added as a black box later. Manipulating, for example, the Quality of Service system on a WCDMA network can tear down a local cell and I don't think that the phone companies nor the government will be happy with people being sold a hacking tool for networks.
Even then, quality can be a problem. I know of a trial in 2003 where 20,000 test phones pulled down a major network's Base Stations in the London area.
Android is more likely to be a better bet and work better because Google are at least subsidizing the phones, but I just don't see true Open Source surviving an encounter with the demands of consumer quality mass market products with significant 3rd party dependancies.