But we're talking about source compatibility, not binary compatibility. So getting around the quirks of the old devices is an already solved problem, even if it needs to be #ifdef'd out for the newer devices. The problem isn't technical, it's a philosophy that treats every device as an opaque special case, rather than factoring out the common parts and abstracting out the differences. Of course the incidental complexity continues to pile up.
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.
> The problem isn't technical, it's a philosophy that treats every device as an opaque special case, rather than factoring out the common parts and abstracting out the differences.
IIRC, the Android kernel will merge with mainline by 3.7. At that point, all such problems will be solved.
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.