Ubuntu doesn't say "too bad, we no longer own any six year old Thinkpad T60's" when they release a new version. They simply leave the drivers for such devices, make changes that aren't expected to break specific hardware models, and get some stablish prereleases so they can take the occasional bug report for the leaky abstractions that did break.
Contrast to Google who AFAIK throws globs of code over the wall with all of the support for older devices ripped out. And then CM presumably uses that tree as a starting point to make changes, instead of merging into a master CM tree.
CM might just be doing the best they can to cope with Google's broken process, but the whole philosophy of brittle trees tailored for specific devices is the philosophy of embedded development, not open source. So CM comes off as aiming to be the latest eye candy fluff mod for tinkerers, rather than a solid computing base for your phone.
It's not a huge problem because new x86-based computers still have to run Windows XP (they can probably run MS-DOS too) and, therefore, cannot be that much different from the six year old Thhinkpad of your example.
I've got 18 years of experience running Linux, compiling my own kernel and packages on a Slackware base up until 2002 or so. In that time I also did embedded design and development for about five years, using cp/zip/email as the ultimate revision control. I know the two philosophies pretty damn well, and I'm unequivocally stating that Android and CM are being run as embedded development projects, where code flexibility and maintainability take a back seat to just making working blobs for specific device configurations. This is ridiculous for what purports to be an open source OS running on a computer roughly equivalent to a desktop PC circa 2000.
But alas, I'm being downvoted into oblivion by non-technical fanboys who probably think that flashing a phone is a highly technical activity, rather than just annoyance due to manufacturer obfuscation (this isn't you - which is why I'm replying to your comment. it's general frustration with the non-thinking HN masses these days). The incidental complexity from the non-scalable development philosophy has built up so much that most people are incapable of even seeing my simple point.
So then, I'm out. I'll keep dreaming of being in a place where I'd have the time to dedicate to making an actual open source user-centric mobile OS to run on mass market hardware. Android will make a great Windows XP.
Every phone is a horrible special case, and those #ifdefs do not simply map forward from one version of the OS to another, unlike on a PC where a single set of drivers will get most computers to a basic working state.
More importantly, how do you suggest they debug? When a phone OS is incorrectly configured, the most likely behaviour is simply hanging with a black screen. Distributing such releases would be worse than useless. If you want to put in the work to make CM work on your device, there are plenty of people who would help you.
IIRC, the Android kernel will merge with mainline by 3.7. At that point, all such problems will be solved.
That makes supporting the Linux kernel for computers relatively trivial.
This is not the case with mobile.
You have dozens of CPU variants for each generation. Nevermind the unique brew of components that goes into every different model even from the same manufacturer. Every phone needs at least one developer who spends his time maintaining the kernel and drivers for that phone for each and every update.
Now, follow along. Developers are nerds. Nerds like new and shiny things. The probability of any developer sticking around with an old phone is zero. Hence, no updates. If this is a problem, learn how to code and keep your obsolete hardware working. Nobody owes you anything. It's up to you.
The cyanogenmod project doesn't maintain any phones. They just help organize various developers who are interested in specific phones and combine their work into a cohesive product. No interest in a phone? No release for that phone.
Your point re: Intel peripherals is true today, but wasn't really true ten years ago. It's also a bit hard to talk about the Linux kernel today, as there is obviously a lot of money and other support such that every little piece is fully tended to by someone.
So my real question is why do the old drivers have to leave the tree or at least become perma deprecated? Is there that many breaking interface changes for which drivers cannot be mostly mechanically updated? I know this is a problem that the kernel devs managed just fine over the years (sure there's been individual broken drivers accompanying major changes, but there's a big difference between saying 'the latest kernel breaks your network card' and indefinitely unsupporting your entire computer.
Maybe I'm just looking at the wrong level of CM publishes (just the releases) and hence I'm out of touch on the actual status of "unsupported" workings on various devices.
And sheesh, the alleged entitlement is the same as with any open source project - I put my faith in the project and would like to continue doing so. I'm not asking for them to conjure up someone to magically do extra work to support my device, I'm asking why they don't change their process such that this extra work is unnecessary in the first place.
Absolutely. Linux was a nightmare to get properly working then. Trust me, I remember. You essentially bought hardware that you knew was going to work. You couldn't buy anything just off-the-shelf and expect it work.
Same problem with mobile.
> So my real question is why do the old drivers have to leave the tree or at least become perma deprecated?
Because Google keeps messing with the kernel? Which is fine, they have to move the platform forward.
> Is there that many breaking interface changes for which drivers cannot be mostly mechanically updated?
Most drivers are closed source. You only have binaries. This is truly unfortunate. So if the manufacturer of the component doesn't release the source (almost never happens) or a new device goes on the market with the same component and updated Android (almost never happens), you're stuck in a very unfortunate place.
Even the slightest change will break everything.
> I know this is a problem that the kernel devs managed just fine over the years
No, they didn't manage shit. They hacked. Hacking takes effort and time. Nobody wants to spend time on old hardware.
> I'm not asking for them to conjure up someone to magically do extra work to support my device ..
You are asking that because ...
> I'm asking why they don't change their process such that this extra work is unnecessary in the first place.
... this isn't possible.
Reading the oldnewthing MS money story the other day, I couldn't help but feeling that something was lost with the emphasis on source compatibility and programming to the abstraction. Clearly there's countless of benefits of doing such, but I'm starting to feel as if making ABIs more prominent wouldn't be the worst thing either.
Why do you think you deserve anything?
I'm running a fairly stable one on my HTC for daily use.
You don't need to be a coder to help out. You can help out with documentation, helping people in the #cyanogenmod IRC channel, etc. These jobs free up CM developer time so they can work on code.
I have a Samsung Galaxy S (the first one). Since this phone has quite a following I got very lucky: CM has continuously been releasing updates for it, even though it's a very old phone by todays standards. I've been using CM7 on it, now have CM9 installed and am in the progress of upgrading to CM10. CyanogenMod's support for this phone has been awesome.
Till recently, it was pretty stable and a brilliant release. There was some issue that led to awful battery drain as I kept progressing through the daily builds in the past few weeks. Resolved it by going through a full wipe than just cache wipes.
My phone is 2-years-old now and it has been a good run. For its ruggedness (multiple and frequent drops, couple of dunks in water, clumsy usage), I just don't want to give it up, but it seems like they may have trouble doing CM11 on it.
Do turn off zRAM in the performance options for better stability.
[1]: http://code.google.com/p/sgscm10/issues/list
[2]: http://forum.xda-developers.com/showthread.php?t=1778526
To your philosophical point, I completely agree. New phones are pushed so frequently that devices become obsolete quickly. I mean, my Captivate was the first Samsung Galaxy, and now we're on the 3rd iteration already, and it's only been two years. While, I always get excited for new gadgets, the lack of support for anything over a year old is unacceptable. Few people have the inclination or money to buy a new phone so frequently. I'm not sure who to blame, but the rapid increase in technology plays a major role.
It's no miracle. A generous, competent and unpaid volunteer decided to build the support for the Captivate. If your device is not supported, you are free to download the source and fix whatever breaks yourself or pay for someone else to do it.
Being a cynic though, I feel that a lot of phones coming out having nothing to do with technology upgrades but instead have more to do with sustaining or growing revenue streams. Some of the iPhone upgrades have been so incremental yet so many people can't live without the newest one, even though they couldn't necessarily tell you what is new about it. I feel this way about vehicles too. Yes the styling changes, in the last couple of years fleet fuel economy has improved, and yes maybe the hp/lb (W/kg) have improved but fundamentally they are the same thing.
I still have my cappy not because there aren't newer and better phones out but because with a good rom it runs great, even though phones have been coming out for 2 years since. How hard has everyone had to twist samsung's arm to release software upgrades for their devices? I don't think it really comes down to money between the carriers and the phone makers but instead they see it as a threat. If everyone had the latest and greatest rom they would find their hardware still runs well for much longer than the average person holds on to their phone. It is simply controlled obsolescence. I am really, REALLY, happy that someone worked hard to build CM10 for the cappy as I can continue to use my perfectly good hardware for a long time.
What are you referring to? I consistently find that the functionality is much better than the vanilla ROMs.
I've been running the first nightly build of JellyBean for months now (it's not even a release candidate) and I've noticed almost no issues. It's easy to forget that I'm not running the standard Android experience!