51–60 of 77 posts
That's really nice, but I don't think I'll be touching anything until this page is completed: http://wiki.cyanogenmod.org/wiki/Samsung_Galaxy_S_III_(Veriz... It just freaks me out to follow directions found on some random forum.
Earlier quoted context omitted.
> reduced and clunky functionality 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!
Just various little things that are off - general laggier response than sense rom, a text message along with every voicemail, odd power management with the screen not turning on when it's supposed to, lack of FM radio, etc. All little niggling things that I've been willing to put up with for an immature project with a solid foundation, with the expectation that it will mature into something greater.
Earlier quoted context omitted.
Eh? The device was supported at one time. 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…
> Ubuntu doesn't say "too bad, we no longer own any six year old Thinkpad T60's" when they release a new version. 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.
One improvement I really appreciate is an improvement in the dynamics of scrolling among the five screens or parts of the launcher / home screen.
Earlier quoted context omitted.
No, I've been listening. It's just that nobody has been making any actual points besides 'stfu'. So thank you for bringing the discussion back to technicals. 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…
Every version of Android generally uses a newer kernel release, but many Android drivers are binary-only and thus cannot be updated to work with newer kernels. To get ICS working on the G2, for example, hackers had to create a frankenkernel that could load old 2.6.x drivers but had the 3.x features that ICS needs. This is a lot of work and it has to be done for every SoC. Also, I get the impression that the custom RO…
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.
My Nexus 7 updated itself to 4.2 yesterday. Am I correct in assuming that since it is based on 4.1, if I install CM 10.0, I will lose most of the improvements in the 4.2 update? One improvement I really appreciate is an improvement in the dynamics of scrolling among the five screens or parts of the launcher / home screen.
Personally, I only use Cyanogen as a last resort on phones that no longer receive updates or that have poor stock ROMs (Samsung Captivate, for example). I have no desire to install CM on my perfectly functional and supported Nexus 7.
Case in point - Samsung Galaxy S2. The S2 had an official ICS ROM release by Samsung and devs managed to get a stable build of CM9 running on it. However, as of now there is no official JB update for the S2 and CM 10 is far from stable on that device. There are problems with the Yamaha sound chip (low volume), problems with the graphics chip (Hardware Composer), USB, TV-out, etc.
I am really hopeful about the new Nexus devices though. The Nexus 10 is the most OSS friendly Android device I've seen - everything except the GPU driver is available as open source.
The problem with the CM project is most of the devices it tries to support are not open source. What I mean is that the drivers for the radio, GPU, audio, etc. chips are not available in source form like Android itself (via AOSP). In order to compile a ROM for any device, the developers have to rely on binary blobs ripped from an official update or a different device. Unfortunately, that means bad support for devices…
That's really nice, but I don't think I'll be touching anything until this page is completed: http://wiki.cyanogenmod.org/wiki/Samsung_Galaxy_S_III_(Veriz... It just freaks me out to follow directions found on some random forum.
Android mods like this are great ideas, but this and the other super popular mods could really use a person that takes the role of technical or documentation editor.
It really irks me that there are no builds for older devices. What is the point of installing CM and putting up with reduced and clunky functionality, just to be left by the wayside for updates? I don't know if this is due to CM or Google itself running amok on the upstream tree, but a philosophy that considers a two year old device obsolete is utterly preposterous.
Others have already said that it's a community project and so YMMV with respect to older phones. 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…
[1]: http://code.google.com/p/sgscm10/issues/list
[2]: http://forum.xda-developers.com/showthread.php?t=1778526