CyanogenMod 9 Working On the Nexus S 218
MrSeb writes with an article in Extreme Tech about progress toward getting an AOSP build working on the Nexus S. From the article: "Over the past week, ROM Manager extraordinaire Koush has been frantically working on making a working build of CyanogenMod 9 (Ice Cream Sandwich) for the Samsung Nexus S. The custom ROM, which is built purely from the Android Open Source Project, has now reached 'alpha 11.' All major features are present and no significant bugs remain. It's too early to say that the build is ready for prime time or mission-critical work — the final release of CM9 is due in the new year — but it's certainly stable enough for daily use. The most significant feature, if you can call it that, is that Koush's build of ICS is really very smooth — it's as nimble as Gingerbread, if not more so. Unlike the previous, non-CM build that was released last week, this alpha build of CM9 has every feature enabled, including Google Wallet, and setting a mobile data limit. As usual, the custom ROM is pre-rooted, has ROM Manager installed, and absolutely no bloatware. "
Re:Lies (Score:5, Informative)
Although Android is not a true open source project, they normally release the source code with one major exception. A lot of the argument about that was because Google refused to release the 3.x Honeycomb source code. Google themselves said that the reason they never released it was that it was a 'hack' to get Android on tablets and was not up to their quality standards and they didn't want it spread any further than necessary. They promised that they would release 4.0, dubbed Ice Cream Sandwich, which would meld the phone and tablet code and they have done so, leading to the CyanogenMod 9 release.
Open source vs. community development (Score:5, Informative)
A project that releases source code under an open source license is an open source project.
Android, unlike many open source projects, isn't an open community development project, but while those two things often go together, they have no necessary relationship.
Re:Yay (Score:5, Informative)
You sure are demanding and lazy, aren't you?
Re:Yay (Score:5, Informative)
No, it was "dropped" because Nokia's internal politics damaged the company enough that they stuck an ex-Microsoft executive in the CEO slot who promptly killed off the winner they managed to create in the N9 and forced Nokia on to WP7.
But please, blame the core OS for political and managerial failures.
Re:SGS4G support Please! (Score:5, Informative)
I have had to use ICBINB builds of Gingerbread for my Samsung Galaxy S 4G because CM7 was not available for that phone.... please please please support it for CM9!
If you're into hacking, the difference between the SGS 4G and the SGS is the radio (IIRC), so you'll need to replace the radio drivers with ones that work (I.E. one's you've backed up from the device). I had to do this on a Motorola Milestone (and the locked bootloader didn't help).
This is a "Do at your own risk" thing, if someone more knowledgeable then I has better advice, by all means please post it, mine info is 2 years out of date.
Re:Lies (Score:5, Informative)
That's right. Just to clarify, even Honeycomb's code has been released at this point, although it's not "tagged" so it isn't as easy to get to. Google did this on purpose to encourage developers to build using the Ice Cream Sandwich code instead, which is probably better for everyone involved.
Re:Yay (Score:0, Informative)
Just another reason to never be involved with open source. Sure, there are tons who say they'll donate but I'm sure most never do and if you don't appease your audience with the answer to every want and need you'll get a storm of excuses like "I was going to donate until I found out that your software doesn't wipe my ass." Not unlike the "I'd buy music if it only cost 99cents a song, uh... wait, make that 49 cents... uh... hold on, I meant a nickle a song".
It's a losing battle unless you're building a tool for your own use and decide to open it up to others just for the fuck of it all.
Re:Open source vs. community development (Score:1, Informative)
A project that releases source code under an open source license is an open source project.
And any open source project that releases major new versions without source is called a "bait and switch" project. Some of the code some of the time has never been an accepted standard, even if it's Google doing it and they allegedly had good reasons for it. The standard for an open source project is if it's good enough to ship binaries, it's good enough to ship code. If say Oracle released MySQL6 and said "Hey, we're still cleaning up the code but it'll be released for MySQL7 mmmkay?" would you call that open source? No. I don't see why Google should get a free pass at something you'd never accept from another open source project.
Re:Yay (Score:4, Informative)
Debian runs on the Neo Freerunner, and there's software for the phone functionality. You can make calls, receive and send SMS, connect over GPRS and read your email, browse, use the GPS. It's usable, although running desktop apps on a phone can be frustrating sometimes. And it's slow.
There's a project to run Debian on Nokia N900, however it's incomplete and because of a few proprietary components you can't "compile and install" something to make the phone work. The community is working on replacing those.
The original OS on the phone is Maemo, which is essentially Debian-based, X-based, and you can compile and run it except for those few components. You can also run full Debian in a chroot. You can also port the apps missing in Debian from there any time you wish. It's non-trivial perhaps.
You can run Kubuntu on N900. The phone functionality in Debian and Kubuntu is being worked on.
That's the joke. (Score:4, Informative)
Re:Yay (Score:5, Informative)
Well... there's a little more to it than that. A "phone" environment is fundamentally different in the sense that an incoming phone call usually will (and should) stop whatever else you're doing dead in its tracks until the call is dealt with. A scheduling and notification strategy optimized for realtime multiplayer games is going to be completely dysfunctional when your real-world use case involves being able to freeze the action mid-shot and take an incoming phone call, then gracefully ease back into the action when it's finished. That's why Android makes such a big deal about differentiating between "service" and "activity" -- a service can keep running when another activity has the activity focus.
If Android apps weren't forced to divide up the workflow and separate out the parts into "things that can (and should) run in the background without a user interface", and "things that only make sense when the application has focus and the user's exclusive attention", we'd have the same problems that IOS does. Where things in Android's world become confusing is the ambiguity at the "service" end, between "things that happen occasionally on a schedule" (like polling a server), "things that happen in response to something else" (incoming communication, arrival at location, change of sensor state, etc), and "things that should happen, and keep happening, until something else gives them a reason to stop" (like music playback). Complicating things more is the fact that you can sort of *get away* with doing things in background services using threads and traditional Java sleep/wait strategies, but Android will break things that insist on doing things that way in increasingly aggressive ways (particularly Gingerbread and beyond), even when they do it in ways that are considered to be perfectly legitimate and polite in mainstream Java.
Starting with Gingerbread, Android has started becoming downright mean & aggressive towards apps that use TimerTask to schedule periodic tasks in background services instead of using alarms & intents... not quite breaking apps outright, but getting VERY aggressive about killing background services that use TimerTask with partial wakelocks in ways that even a year ago would have been considered mainstream and exceptionally well-behaved (like grabbing a partial wakelock ONLY during actual network activity, to at least ensure that the phone didn't get put to sleep halfway through a http request, even if the service itself ended up suspended until the phone was awakened by something). Now, Android will kill background services after about an hour simply because it decides they've been running for "too long", even if they've been asleep in a TimerTask for most of it. I never even noticed this until I got my Photon last month, because my previous phone (Samsung Galaxy S/Epic 4G) was stuck in Froyo-land, and my app worked flawlessly on it. I knew it didn't reliably poll when the phone was asleep, but it still managed to make it work often enough to not be a big deal. Once I got the Photon, I noticed that it was just silently dying outright after about an hour, and not coming back to life after the phone was awakened.
I can see Google's logic, but I don't think they've done a particularly good job of reaching out to developers (many of whom are still stuck in Froyo-land, if only because American carriers suck & most users are still stuck with it, often including the developers themselves). Yes, the emulator exists for newer versions, but frankly, it's so slow, even on a fast quadcore PC, I'd rather tear off my fingernails one by one than suffer its slowness (and the fact that it seems to either die, or spontaneously lose contact with Eclipse, once or twice per hour, necessitating even more delay and interruption). After I bought my new Photon, my old Epic turned into my "permanently tethered to the computer development phone".