LineageOS will be a continuation of what CyanogenMod was(lineageos.org)
lineageos.org
LineageOS will be a continuation of what CyanogenMod was
http://lineageos.org/Yes-this-is-us/
117 comments
Not directly an answer, but one of the big issues with security patches for custom ROMs is the amount of patches they don't (read can't) ship. The proprietary blobs are very often not patched when the device is vendor-supported, and once it reaches end of life from the vendor (but the community ROMs give devices significantly extended longevity), there's no more patches to these blobs.
Blobs incorporate the modem, baseband firmware, bootloaders, and many (most?) of the hardware drivers and imaging drivers.
51% of Android kernel vulnerabilities in vendor drivers are a result of missing or incorrect bounds checks, and over the whole Android kernel, 44% of all vulnerabilities were missing bounds checks, and 12% for null pointer dereference.
Looking across the whole kernel, from Jan 2014 to April 2016, 85% of kernel bugs are born in vendor drivers, with the remainder in the core kernel.
Vendors therefore are shown to write bad code. It's fairly safe to assume this is reflective of the quality of their blobs too - there's certainly a load of vulnerabilities in those if you look at the Android Security bulletins for bugs without a source reference for the fix.
So agreement with your concern, but I'd just like to highlight that custom ROMs are not really a good security solution, as there's just so much to fix (at a kernel level, requiring detailed driver knowledge of the vendor/SoC stuff), and blobs that won't get updated after the vendor abandons the phone.
Ref: https://events.linuxfoundation.org/sites/events/files/slides...
Blobs incorporate the modem, baseband firmware, bootloaders, and many (most?) of the hardware drivers and imaging drivers.
51% of Android kernel vulnerabilities in vendor drivers are a result of missing or incorrect bounds checks, and over the whole Android kernel, 44% of all vulnerabilities were missing bounds checks, and 12% for null pointer dereference.
Looking across the whole kernel, from Jan 2014 to April 2016, 85% of kernel bugs are born in vendor drivers, with the remainder in the core kernel.
Vendors therefore are shown to write bad code. It's fairly safe to assume this is reflective of the quality of their blobs too - there's certainly a load of vulnerabilities in those if you look at the Android Security bulletins for bugs without a source reference for the fix.
So agreement with your concern, but I'd just like to highlight that custom ROMs are not really a good security solution, as there's just so much to fix (at a kernel level, requiring detailed driver knowledge of the vendor/SoC stuff), and blobs that won't get updated after the vendor abandons the phone.
Ref: https://events.linuxfoundation.org/sites/events/files/slides...
Oh, that's totally true—though for many having some secure updates would be better than none, especially given the number of kernel bugs that are only locally exploitable (i.e., if the rest of the system is up-to-date, locally exploitable issues are less, but not none, of a concern).
One thing I wish there was more visibility of is "is this device still getting security updates", because there's often almost no visibility about that (and while you obviously can't say the vendor won't fix future vulnerabilities, you can say whether the vendor has fixed all known vulnerabilities), even online, yet alone anything pushed to the device to let its user know it is no longer secure.
e.g., http://web.archive.org/web/20161224231459/https://wiki.cyano... is the old CyanogenMod wiki page for the Galaxy S2: the last "development channel" (i.e., unstable) build is 2016-12-18, the last "release channel" (i.e., stable) build is 2015-11-16. There is nothing on the device page to suggest the stable build is known to be insecure (though given the number of Android bugs found in the last year unquestionably is!), yet alone anything about upstream vendors dropping support for the device and the unstable build being known to be insecure too. How is LineageOS going to do better than that? That's a damn low bar.
One thing I wish there was more visibility of is "is this device still getting security updates", because there's often almost no visibility about that (and while you obviously can't say the vendor won't fix future vulnerabilities, you can say whether the vendor has fixed all known vulnerabilities), even online, yet alone anything pushed to the device to let its user know it is no longer secure.
e.g., http://web.archive.org/web/20161224231459/https://wiki.cyano... is the old CyanogenMod wiki page for the Galaxy S2: the last "development channel" (i.e., unstable) build is 2016-12-18, the last "release channel" (i.e., stable) build is 2015-11-16. There is nothing on the device page to suggest the stable build is known to be insecure (though given the number of Android bugs found in the last year unquestionably is!), yet alone anything about upstream vendors dropping support for the device and the unstable build being known to be insecure too. How is LineageOS going to do better than that? That's a damn low bar.
Absolutely - userland is the easiest to exploit, as it's fairly common across all devices (thanks to CTS and standardisation of the runtime) - that's why stagefright was such a big deal!
Definitely agreed - I've thought about making such a list to give visibility of this before, but it would be more of a user-submitted list (perhaps with link-up to screen scraping of OEM web pages for the ones that list the latest version).
What held me back was the sheer complexity of working out whether a device still gets updates - take Samsung as an example; the user says "I have a Galaxy S6". Depending on their geographical location this might be a carrier-free G920I or G920F. If they are in the US, it could then be one of about 5 or 6 variants, and there's even a G920W8 for Canada.
User wants to know if "Galaxy S6" is safe and secure, but even different regional firmwares of the same SKU might not be getting pushed security updates. And some US carriers (Verizon, ATT) are notorious for not pushing out updates to users. And then finally when you figure out the version on a given phone, you need to try to decide if the fact the device is still on October 2016 security patch means it's unsupported or not.
Often Samsung are lagging 2 to 3 months behind on some SKUs, making it even harder to tell. The same is true for many other OEMs - Sony have a pretty complex system of ROMs for each region, meaning you have carrier and non-carrier ones, and they can be on different versions.
To make this happen, we'd ideally need a single worldwide firmware without carrier changes/tweaks/influence. Until then, I suspect it would be too complex to help users work out if their device was being supported.
Definitely agreed - I've thought about making such a list to give visibility of this before, but it would be more of a user-submitted list (perhaps with link-up to screen scraping of OEM web pages for the ones that list the latest version).
What held me back was the sheer complexity of working out whether a device still gets updates - take Samsung as an example; the user says "I have a Galaxy S6". Depending on their geographical location this might be a carrier-free G920I or G920F. If they are in the US, it could then be one of about 5 or 6 variants, and there's even a G920W8 for Canada.
User wants to know if "Galaxy S6" is safe and secure, but even different regional firmwares of the same SKU might not be getting pushed security updates. And some US carriers (Verizon, ATT) are notorious for not pushing out updates to users. And then finally when you figure out the version on a given phone, you need to try to decide if the fact the device is still on October 2016 security patch means it's unsupported or not.
Often Samsung are lagging 2 to 3 months behind on some SKUs, making it even harder to tell. The same is true for many other OEMs - Sony have a pretty complex system of ROMs for each region, meaning you have carrier and non-carrier ones, and they can be on different versions.
To make this happen, we'd ideally need a single worldwide firmware without carrier changes/tweaks/influence. Until then, I suspect it would be too complex to help users work out if their device was being supported.
Starting from Android 6, it's easy to check if the device is up-to-date from an Android point of view: in "About phone", you have an "Android security patch level" section which should be match the current month.
Yes indeed - the downside of this is that it's hard to gather this information together in a way that lets you show people "which devices" are still maintained.
It is much better for users to know if they are on the latest build. Sadly though for (most/many?) devices, the answer is "it's not", and there's nothing they can really do about it, either due to OEM latency in releasing updates, or the OEM having abandoned their phone.
Samsung [1] and LG [2] pretty much say on their own websites that only certain phones will get updates promptly (or at all) - consider their full product ranges and the cheaper devices not even listed!
[1] http://security.samsungmobile.com/introsm.html
[2] https://lgsecurity.lge.com/security_updates.html > Depending on regions and carriers, updates may be released monthly, quarterly or irregularly.
It is much better for users to know if they are on the latest build. Sadly though for (most/many?) devices, the answer is "it's not", and there's nothing they can really do about it, either due to OEM latency in releasing updates, or the OEM having abandoned their phone.
Samsung [1] and LG [2] pretty much say on their own websites that only certain phones will get updates promptly (or at all) - consider their full product ranges and the cheaper devices not even listed!
[1] http://security.samsungmobile.com/introsm.html
[2] https://lgsecurity.lge.com/security_updates.html > Depending on regions and carriers, updates may be released monthly, quarterly or irregularly.
I presume the OS can at least tell what exact model it's on, which means we could potentially at least have something (an app, given I guess Google will never ship such a thing) that says, "hey, this device isn't secure any more".
Now, obviously there's the problem with the time taken to ship fixes (do you say the device is insecure for the two-to-three months before a patch is shipped? do you say the device is insecure only six months after the exploit becomes public? etc.), so even this isn't that simple.
I still wonder about how well the "Android security patch level" will cope with OEMs and their often slow kernel updates (i.e., the fact there are OEMs that quickly release userland fixes, and very slowly release kernel updates).
Now, obviously there's the problem with the time taken to ship fixes (do you say the device is insecure for the two-to-three months before a patch is shipped? do you say the device is insecure only six months after the exploit becomes public? etc.), so even this isn't that simple.
I still wonder about how well the "Android security patch level" will cope with OEMs and their often slow kernel updates (i.e., the fact there are OEMs that quickly release userland fixes, and very slowly release kernel updates).
The only solution seems to be reverse engineering the blobs and mainlining Linux kernel drivers, without both of those security updates get much much harder to impossible.
I've no idea how to achieve that on volunteer time, maybe a crowdfunded reverse engineering and mainlining org could work?
I've no idea how to achieve that on volunteer time, maybe a crowdfunded reverse engineering and mainlining org could work?
One problem is that RE is time consuming (regardless of whether or not someone is paid to do it), and the useful life of phones tend to be much shorter than other kinds of devices, so digging apart a blob on one phone is likely to have a limited useful lifetime.
And for phones that the manufacturer actively supports, often a new version (especially if it's a new Android version) means new blobs to RE.
When you consider a lot of phones lose a ton of their user base after 2 or 3 years, it becomes much less attractive to even bother.
And for phones that the manufacturer actively supports, often a new version (especially if it's a new Android version) means new blobs to RE.
When you consider a lot of phones lose a ton of their user base after 2 or 3 years, it becomes much less attractive to even bother.
The alternative; devices with no updates and no support outside their original OS, doesn't seem very attractive either.
Maybe we can create incentives for manufacturers to do this work themselves, but I doubt that will ever happen, unless maybe we start getting obnoxious viruses like there were on the PC at one point?
Maybe we can create incentives for manufacturers to do this work themselves, but I doubt that will ever happen, unless maybe we start getting obnoxious viruses like there were on the PC at one point?
Sure, that's not a particularly attractive outcome, either.
I just think it's unrealistic to think paid RE work is going to fill this need.
I think there are two realistic options: 1) the manufacturers suck it up and agree to support devices with timely updates over a longer lifespan, or 2) manufacturers open-source every bit of software that runs on the device.
#2 seems less likely, given that a lot of hardware is driven in part by loadable firmware these days. On the other hand, if that firmware is chipset-specific and not device-specific, and the chipset manufacturer can commit to releasing security updates for those, at least 3rd-party OS images could pull them in without help from the device manufacturer.
But really, it's all about demand: Apple tends to support hardware with new releases for 4-ish years as a matter of course, and i-device users are accustomed to expecting that. Android users just don't expect that, and your average user doesn't understand security enough to get why that's such a big problem. They likely mostly just think, "oh well, I won't get the new shiny Android version Jane has on her new phone, that's ok". If average users can be educated to the point where they will switch manufacturers if they're not getting security updates for the useful life of their phone, the manufacturers will listen to their declining sales. I just don't expect that to happen.
I just think it's unrealistic to think paid RE work is going to fill this need.
I think there are two realistic options: 1) the manufacturers suck it up and agree to support devices with timely updates over a longer lifespan, or 2) manufacturers open-source every bit of software that runs on the device.
#2 seems less likely, given that a lot of hardware is driven in part by loadable firmware these days. On the other hand, if that firmware is chipset-specific and not device-specific, and the chipset manufacturer can commit to releasing security updates for those, at least 3rd-party OS images could pull them in without help from the device manufacturer.
But really, it's all about demand: Apple tends to support hardware with new releases for 4-ish years as a matter of course, and i-device users are accustomed to expecting that. Android users just don't expect that, and your average user doesn't understand security enough to get why that's such a big problem. They likely mostly just think, "oh well, I won't get the new shiny Android version Jane has on her new phone, that's ok". If average users can be educated to the point where they will switch manufacturers if they're not getting security updates for the useful life of their phone, the manufacturers will listen to their declining sales. I just don't expect that to happen.
I wouldn't be surprised if it were easier to backport kernel security fixes to the version the blob depended on than reverse engineer the blob, given the relatively short life of devices in general.
That said, neither of those two options is easy!
That said, neither of those two options is easy!
[deleted]
Yet somehow most stock ROMs are worse at maintaining security patches.
This.
It's actually astounding, albeit hardly surprising, that companies often have zero interest in pushing security patches to devices not being manufactured anymore.
It's actually astounding, albeit hardly surprising, that companies often have zero interest in pushing security patches to devices not being manufactured anymore.
If/when it becomes a risk they must mitigate against (be that a financial or reputational risk), I guess they will.
Heck, until stagefright, Google didn't even release security bulletins. It was nigh-on impossible to keep track of all the vulnerabilities They only released security patches in new version releases. That wasn't good for vendors.
Now Google has pushed forward, and it's the turn of OEMs. They shipped patches to StageFright due to the massive bad PR (headline news in many countries, was a talking point amongst even the vaguely tech savvy).
Unless regulated or they feel they will lose money by not doing so, I don't imagine anything changing soon unfortunately. Qcom and other SoC makers are part of the problem too, since they try to drive chipset sales by only supporting older chipsets for a short time.
Heck, until stagefright, Google didn't even release security bulletins. It was nigh-on impossible to keep track of all the vulnerabilities They only released security patches in new version releases. That wasn't good for vendors.
Now Google has pushed forward, and it's the turn of OEMs. They shipped patches to StageFright due to the massive bad PR (headline news in many countries, was a talking point amongst even the vaguely tech savvy).
Unless regulated or they feel they will lose money by not doing so, I don't imagine anything changing soon unfortunately. Qcom and other SoC makers are part of the problem too, since they try to drive chipset sales by only supporting older chipsets for a short time.
This is why for the first time since I started owning smartphones (2010), I am going to switch to iPhone.
That's not going to fix the problem. Installing updates on an iPhone older than a couple years bogs performance down to unusable levels.
I have an iPhone 5 (4 year old phone) running the latest OS and it works fine. No, it's not as fast as the latest devices, but it works adequately if one desires to keep using their 4-year-old device.
While I agree that's been the case in the past, supported devices are fast enough now that it really doesn't slow them down anymore. Even the lowest supported device runs well on iOS 10, and it has gotten official updates years longer than all android devices I know of.
Sure, one could install an updated and more secure rom (assuming it exists for your device). But, the vast majority of users don't care or won't bother to go through that process, rendering it a completely ineffective solution for the general consumer market.
Sure, one could install an updated and more secure rom (assuming it exists for your device). But, the vast majority of users don't care or won't bother to go through that process, rendering it a completely ineffective solution for the general consumer market.
> supported devices are fast enough now that it really doesn't slow them down anymore
That happens to be true now because Apple has dropped support for many iPad models with iOS 10, accounting for up to a third of all iPads in use.
Running iOS 9 on the iPad 2, 3, and iPad mini was frustrating. This was only three months ago, so I wouldn't rule it out for the future yet.
That happens to be true now because Apple has dropped support for many iPad models with iOS 10, accounting for up to a third of all iPads in use.
Running iOS 9 on the iPad 2, 3, and iPad mini was frustrating. This was only three months ago, so I wouldn't rule it out for the future yet.
I am aware but at least I won't get hacked which is more important than performance.
But even if Apple may be better than most android manufacturers, Apple still doesn't support devices it considers "Obsolete"...and there is nothing you can do about it other than buy a new phone since the bootloader is locked down. According to https://en.wikipedia.org/wiki/List_of_iOS_devices anything before iPhone 5 is considered "Oboslete" and they don't seem to be releasing updates. On the other hand, I've been happily using my Samsung S3 which cyanogenmod has been pushing latest android updates to nightly...and that is likely to continue as long as there are enough of us who care, even if cyanogen and samsung goes away.
Does the S3 get security updates to all the kernel-level vendor-provided blobs?
cyanogen is no more.
For the record, the Galaxy S III was released in the same year as the iPhone 5 (2012), so for now your device hasn't lasted any longer than an iPhone. But I don't doubt that it will.
SII last got an update a month and a half ago (https://download.cyanogenmod.org/?device=i777)
Without any updates for the vendor blobs.
Oh, I'm not denying most OEMs are terrible at this—this is the massive achilles heal of Android.
OTOH, in a sense I have a higher expectation of "aftermarket" OSes insofar as they're actually pushing semi-regular updates which I'd hope would include all needed security updates.
OTOH, in a sense I have a higher expectation of "aftermarket" OSes insofar as they're actually pushing semi-regular updates which I'd hope would include all needed security updates.
Something I've wondered about: why does Android require you flash a ROM to update the system?
When you buy a windows laptop you'll usually get a bunch of vendor-specific crap, but after doing a clean install you can just pick up the drivers on their website and it'll all work fine. Why isn't this an option with Android?
When you buy a windows laptop you'll usually get a bunch of vendor-specific crap, but after doing a clean install you can just pick up the drivers on their website and it'll all work fine. Why isn't this an option with Android?
ARM's SoC lack of standards.
In reality, we were really spoiled with IBM's massive mistake in standardizing the PC (the BIOS), so while Linux may not pick up your monitor, your monitor is made to work to a basic standard (VGA), so you can at least boot up, read the hard-drive, and have basic "keyboard" IO.
This was really important before Win95 made the PC practically MS owned, as you could (and were expected to) install whatever OS you wanted, so they had to have a standard Boot Sector, etc.
ARM SoC are meant to be built by a manufacturer to their specs (their CPU doesn't have to be compatible with anything because nothing is user-serviceable anyways). In other words, PCs were meant to be an Open Standard, while SoC are like old consoles/"dumb" phones.
Unfortunately, due to MS dominance in the PC world, and the collapse of independent computer manufacturers (I remember the days when buying a cheap computer meant not going to Dell but going to the mom-and-pop shop down the block, but you had to know how to fix things if anything went bust), the PC is moving slowly but surely to the appliance world.
In reality, we were really spoiled with IBM's massive mistake in standardizing the PC (the BIOS), so while Linux may not pick up your monitor, your monitor is made to work to a basic standard (VGA), so you can at least boot up, read the hard-drive, and have basic "keyboard" IO.
This was really important before Win95 made the PC practically MS owned, as you could (and were expected to) install whatever OS you wanted, so they had to have a standard Boot Sector, etc.
ARM SoC are meant to be built by a manufacturer to their specs (their CPU doesn't have to be compatible with anything because nothing is user-serviceable anyways). In other words, PCs were meant to be an Open Standard, while SoC are like old consoles/"dumb" phones.
Unfortunately, due to MS dominance in the PC world, and the collapse of independent computer manufacturers (I remember the days when buying a cheap computer meant not going to Dell but going to the mom-and-pop shop down the block, but you had to know how to fix things if anything went bust), the PC is moving slowly but surely to the appliance world.
As I have been involved with OpenWRT/LEDE and how they make builds to different devices recently, I realized that making unified builds are actually possible. OpenWRT has the same kernel and root image for many different devices that use the same SoC. So once you have OpenWRT flashed on, the content of every OpenWRT update (for every device of the same SOC) is by and large the same. The only check in place is the artificial model check to make sure you don't unintentionally flash the wrong image.
Android can technically do like OpenWRT does, but there is much more stuff involved in the Android world so making a universal build is harder. However, I personally can't think of a hard, technical barrier. New ideas for unifying devices and separating blobs such as device tree or separate vendor partition is getting traction and makers such as Sony are embracing it. Many Sony devices boot the same kernel, and that's why you consistently seeing Sony devices getting support and builds very early on from projects like CM.
BTW, I have been trying to write an answer to you by saying a slightly different version of what dispose54312 said, but then realized it didn't make sense. I came to the conclusion (for myself) this is mostly "how it is done currently for Android." So I hope my unpopular answer is not crazily misguided, and please take my perspective with a grain of salt.
Android can technically do like OpenWRT does, but there is much more stuff involved in the Android world so making a universal build is harder. However, I personally can't think of a hard, technical barrier. New ideas for unifying devices and separating blobs such as device tree or separate vendor partition is getting traction and makers such as Sony are embracing it. Many Sony devices boot the same kernel, and that's why you consistently seeing Sony devices getting support and builds very early on from projects like CM.
BTW, I have been trying to write an answer to you by saying a slightly different version of what dispose54312 said, but then realized it didn't make sense. I came to the conclusion (for myself) this is mostly "how it is done currently for Android." So I hope my unpopular answer is not crazily misguided, and please take my perspective with a grain of salt.
Thanks for your work on OpenWRT...I'm a happy user! I would hope for any expertise on unified builds could be transferred over to android. I'm wondering if android could run on top of OpenWRT, then could use the same system to update the android layer without having to update the lower levels.
Would think one of the whole points of having the many layers in the android software stack is that one layer can be modified without having to reload everything in the lower levels.
Would think one of the whole points of having the many layers in the android software stack is that one layer can be modified without having to reload everything in the lower levels.
> Something I've wondered about: why does Android require you flash a ROM to update the system?
Let me answer that by picking the question apart:
1. To update the system, you need access to write actual system-files. You need system-level access.
2. Android is built entirely up on a "user-space" model where permissions are granted to apps, and almost no apps have system-level access.
3. On rooted phones you can allow system-level access to specific apps, which in theory could install the latest OS version and binaries. In theory that sounds like 1 app which you can use to update the OS, everywhere, right?
4. Except you would need a different installation-strategy for unrooted phones anyway for the installation anyway.
5. To compound the problem the ARM platform has no standardized BIOS/UEFI layer to handle generic booting, so the kernel being booted must be device-specific in order to gain access to the rest of the phone: It can't rely on generic "BIOS"-drivers to load modules on demand from flash storage. And the boot-partition is almost always too small to have a kernel with enough drivers for "everyone" embedded.
6. So you cant make a standard phone-agnostic flashing-app, nor install medium. You do have to build a custom phone-specific initial flash-package for every model you want to support as a bare minimum.
And when you've already put in all that effort, what do you gain by creating an "app" which does this inside a pretty GUI, instead of just rebooting back to recovery to (auto) flash the latest image? Practically nothing.
"Flashing" may sound scary, but in reality it just means installing. There's no technical difference between that and just copying files to a usually write-protected partition.
AFAIK: Apple officially does exactly the same, they just don't call it by that name.
Let me answer that by picking the question apart:
1. To update the system, you need access to write actual system-files. You need system-level access.
2. Android is built entirely up on a "user-space" model where permissions are granted to apps, and almost no apps have system-level access.
3. On rooted phones you can allow system-level access to specific apps, which in theory could install the latest OS version and binaries. In theory that sounds like 1 app which you can use to update the OS, everywhere, right?
4. Except you would need a different installation-strategy for unrooted phones anyway for the installation anyway.
5. To compound the problem the ARM platform has no standardized BIOS/UEFI layer to handle generic booting, so the kernel being booted must be device-specific in order to gain access to the rest of the phone: It can't rely on generic "BIOS"-drivers to load modules on demand from flash storage. And the boot-partition is almost always too small to have a kernel with enough drivers for "everyone" embedded.
6. So you cant make a standard phone-agnostic flashing-app, nor install medium. You do have to build a custom phone-specific initial flash-package for every model you want to support as a bare minimum.
And when you've already put in all that effort, what do you gain by creating an "app" which does this inside a pretty GUI, instead of just rebooting back to recovery to (auto) flash the latest image? Practically nothing.
"Flashing" may sound scary, but in reality it just means installing. There's no technical difference between that and just copying files to a usually write-protected partition.
AFAIK: Apple officially does exactly the same, they just don't call it by that name.
There is a "fastboot" [1] tool from Google that interacts with phone bootloaders that support it and can be used to flash the ROM.
> There's no technical difference between that and just copying files to a usually write-protected partition.
"Flashing" usually means "uploading" a filesystem image onto a partition, not copying single files.
[1] https://source.android.com/source/running.html#booting-into-...
> There's no technical difference between that and just copying files to a usually write-protected partition.
"Flashing" usually means "uploading" a filesystem image onto a partition, not copying single files.
[1] https://source.android.com/source/running.html#booting-into-...
Fastboot is a interface/protocol to talk to the bootloader, in order to flash images to select partitions. On select phones. And it requires an external device to run the process. So it can't be self-hosted.
All that technical whizbang doesn't change or even address the underlying problem: What you boot still needs to be 100% device specific.
There's no UEFI/BIOS on ARM to help bootstrap the boot process.
Also: When you flash custom roms on Android, you format and then unzip a file onto the system partition. Not that I see how that's technically any different from flashing a FS-image, but if it matters to you, now you know.
In conclusion: none of my claims have been near disproven, but a few straw men has been presented to be stricken down ;)
All that technical whizbang doesn't change or even address the underlying problem: What you boot still needs to be 100% device specific.
There's no UEFI/BIOS on ARM to help bootstrap the boot process.
Also: When you flash custom roms on Android, you format and then unzip a file onto the system partition. Not that I see how that's technically any different from flashing a FS-image, but if it matters to you, now you know.
In conclusion: none of my claims have been near disproven, but a few straw men has been presented to be stricken down ;)
Probably the same people who made sure CyanogenOS users got timely updates: no one.
Last update for my phone was early september. Not holding my breath for this.
Last update for my phone was early september. Not holding my breath for this.
I want to read the full story, including how Microsoft was involved with Cyanogen(Inc/Mod).
(yes, it was involved, use Google to search for previous news.
For example at one point CyanogenInc partnered with MSFT so they have a Microsoft sponsored Android flavour with several Microsoft apps preinstalled. https://cyngn.com/press/cyanogen-announces-strategic-partner... http://www.businessinsider.de/why-microsoft-cuddled-up-to-cy... Now it smells like the "embrace, extend and extinguish" strategy that MSFT is using with great success for decades https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
So I hope at one point we will get the full story.)
(yes, it was involved, use Google to search for previous news.
For example at one point CyanogenInc partnered with MSFT so they have a Microsoft sponsored Android flavour with several Microsoft apps preinstalled. https://cyngn.com/press/cyanogen-announces-strategic-partner... http://www.businessinsider.de/why-microsoft-cuddled-up-to-cy... Now it smells like the "embrace, extend and extinguish" strategy that MSFT is using with great success for decades https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
So I hope at one point we will get the full story.)
The question is what will ensure the continual non-profitness of lineageOS?
The problem is two fold:
1. Get maintainers. 2. Make sure that the high ranking individuals can't just "take the ball and go home", and (however unpopular this opinion may be here), GPL is the only way to ensure that they will never be able to sell out ever again.
And especially after the CM/CyanogenOS/Focal/Paranoid Android situation, private ROMs seem to be too much of an "aquihire" risk.
The problem is two fold:
1. Get maintainers. 2. Make sure that the high ranking individuals can't just "take the ball and go home", and (however unpopular this opinion may be here), GPL is the only way to ensure that they will never be able to sell out ever again.
And especially after the CM/CyanogenOS/Focal/Paranoid Android situation, private ROMs seem to be too much of an "aquihire" risk.
GPL is the route that OmniROM tried to go down, in order to attempt to ensure that the ROM remained community focused and true to its roots.
One potential issue with CM is that users were signing contributor license agreements (CLAs) to the "project leads" of the "CyanogenMod Project" [1]. While everything is under Apache 2, which ensures it can be used in future, there were plenty of cases where people submitted code under the copyright of the project (see headers which state "Copyright (C) 2016 The CyanogenMod Project").
You are correct with point 2 - if you want to prevent "acqui-hire" type takeovers, you need to ensure that there isn't a tight-knit group of individuals willing to agree and sign over the rights.
This situation would be very, very different if the original CM project had taken a better approach at the start - perhaps forming a 501(c)3 for the holding of the cyanogenmod.org domain and any trademarks/name rights. Then a commercial license could be granted to the incorporated form of CM.
I wish I could find a good primary source, but best I can see at the moment are fairly blog-type news sites [2]. The issue we see here is that the project's stewards were turning their focus from the project to the "commercial spinout", rather than in keeping the project going. At that point, there's little that the contributors could do really - it seemed the leaders had made the decision to build the inc version, despite high profile disagreement. Not sure GPL would fix that, but it certainly helps ensure a community project can live on, even if it won't guarantee it will.
[1] https://review.cyanogenmod.org/static/cla_individual.html
[2] http://www.androidheadlines.com/2013/09/author-cyanogenmods-...
One potential issue with CM is that users were signing contributor license agreements (CLAs) to the "project leads" of the "CyanogenMod Project" [1]. While everything is under Apache 2, which ensures it can be used in future, there were plenty of cases where people submitted code under the copyright of the project (see headers which state "Copyright (C) 2016 The CyanogenMod Project").
You are correct with point 2 - if you want to prevent "acqui-hire" type takeovers, you need to ensure that there isn't a tight-knit group of individuals willing to agree and sign over the rights.
This situation would be very, very different if the original CM project had taken a better approach at the start - perhaps forming a 501(c)3 for the holding of the cyanogenmod.org domain and any trademarks/name rights. Then a commercial license could be granted to the incorporated form of CM.
I wish I could find a good primary source, but best I can see at the moment are fairly blog-type news sites [2]. The issue we see here is that the project's stewards were turning their focus from the project to the "commercial spinout", rather than in keeping the project going. At that point, there's little that the contributors could do really - it seemed the leaders had made the decision to build the inc version, despite high profile disagreement. Not sure GPL would fix that, but it certainly helps ensure a community project can live on, even if it won't guarantee it will.
[1] https://review.cyanogenmod.org/static/cla_individual.html
[2] http://www.androidheadlines.com/2013/09/author-cyanogenmods-...
That's the point. You can't aquihire Linux.
You can aquihire Linus, you can take his team, but any code you develop "in house" is going to have to go public anyways (because no one owns enough of the code).
You can aquihire Linus, you can take his team, but any code you develop "in house" is going to have to go public anyways (because no one owns enough of the code).
> GPL is the route that OmniROM tried to go down
You write in past tense; what happened?
You write in past tense; what happened?
Nothing, sorry - was using the past tense thinking about when the decision was made a while back. Omni seems to be getting more traction of late with people concerned about the CM issues. They are still GPL and that probably acts as a fairly decent barrier to any kind of acqui-hire attempts. Also having a diverse range of contributors (many with good jobs) helps there too, by making it very expensive/complex to try to get enough people onboard.
In an ironic sense, the argument used by CM was "CM Inc is different from CM community", and I think that was enough to keep some of the alternative ROMs pretty small. Sadly though, it has now emerged CM community was indeed a subset of CM Inc, and not so separate after all.
In an ironic sense, the argument used by CM was "CM Inc is different from CM community", and I think that was enough to keep some of the alternative ROMs pretty small. Sadly though, it has now emerged CM community was indeed a subset of CM Inc, and not so separate after all.
User donations earmarked for X phone model + Y OS version held in trust and paid out to the first developer who completes (X,Y) port of the OS as a one-time cash prizes, with Z% overhead taken out each donation to fund the central developers \ organization.
> completes
This would have be defined carefully to avoid the device dropping out of support quickly.
Personally I think full-time work would be better than bounties.
This would have be defined carefully to avoid the device dropping out of support quickly.
Personally I think full-time work would be better than bounties.
Excellent idea. Reminds me of tip4commit.com or BitHub.
I also wonder if make sense for donator to be able to select their desired Z percentage.
I also wonder if make sense for donator to be able to select their desired Z percentage.
My hope is that they can find a way to collaborate with fairphone: https://code.fairphone.com/projects/fp-osos/
LineageOS needs a flagship phone, FairPhone needs a community-empowered OS.
LineageOS needs a flagship phone, FairPhone needs a community-empowered OS.
Although I do understand the PA devs, as they _do_ need to get paid, and Android OS dev is not easy,
If google wants Android to survive as a platform, they should be directly giving money to projects like this, they are what make it bearable.
google offered to buy Cyanogen.
(http://arstechnica.com/gadgets/2014/10/google-reportedly-tri...)
Also, recall that Cyanogen (the company, not the mod) said that they were going to "put a bullet in Google's head". I bet Google has tried to offer support to them and Cyanogen turned it down.
I can't fathom why Google would buy them. Why not make a version of AOSP that people can actually use, like Cyanogenmod?
What you mean by "usable"? Vanilla Android is really usable nowadays (I have a Nexus 6P with Android 7.1.1, non-rooted with locked bootloader since I don't really root nowadays). CyanogenMod nowadays is more important for their support to multiple hardware then the customization from AOSP per see. This is especially true since for those who really want mods, things like Xposed Framework offers much more customization.
"Vanilla Android" (from the AOSP) doesn't pass the Compatibility Test Suite (CTS) nowadays, so according to Google's Android trademark rules shouldn't be called Android. Some of the "Core" apps simply don't work at all.
Don't confuse what Google publish at the AOSP with what they ship on the Nexus/Pixel devices: they're increasingly different, with AOSP increasingly dysfunctional. Heck, the initial release of Android 7 for the 5X/6P at the AOSP wouldn't even compile because it had closed source compile-time dependencies.
Don't confuse what Google publish at the AOSP with what they ship on the Nexus/Pixel devices: they're increasingly different, with AOSP increasingly dysfunctional. Heck, the initial release of Android 7 for the 5X/6P at the AOSP wouldn't even compile because it had closed source compile-time dependencies.
I know that AOSP isn't the same Android running in Nexus. However I have an Android tablet that I used to run AOSP (nowadays is running CyanogenMod, probably needs to change it to LineageOS). The core experience is exactly the same once you install GApps (at least the minimum necessary to run Play Store).
And no, I really don't need anything that CM brings (I only switched from AOSP to CM because it was better supported on my tablet, CM actually had a developer while the AOSP guy was simply pulling the changes from the CM developer).
And no, I really don't need anything that CM brings (I only switched from AOSP to CM because it was better supported on my tablet, CM actually had a developer while the AOSP guy was simply pulling the changes from the CM developer).
Supporting many devices is a double-edged sword. I feel what Google wanted for their AOSP code is to not support tens of different devices to make the code move fast. Part of what made CM valuable, I feel, was really the changes that made it compatible with so many devices. So CM would have to remain CM for the devices support, not for the features of the ROM.
My guess is doing that will not be in their best interest.
"Reportedly" tried, according to your source.
Surely the answer to Android's woes isn't more platform fragmentation.
I have never understood the desire to have 1 Homogeneous Platform with no variety, no customization, no personality.
To have a large corporate overlord dictating how I use the device I "bought"
I see these same statements in the Linux Desktop world where everyone bitches about how All the Distro's are different, and how the Arch way is different from the Debian Way, and different from Red Hat, Canonical etc.
That is what I LIKE about Linux, that is what is LIKE about Android.
If i wanted a Corporate Overlord I would use an Apple or Microsoft commercial garbage
To have a large corporate overlord dictating how I use the device I "bought"
I see these same statements in the Linux Desktop world where everyone bitches about how All the Distro's are different, and how the Arch way is different from the Debian Way, and different from Red Hat, Canonical etc.
That is what I LIKE about Linux, that is what is LIKE about Android.
If i wanted a Corporate Overlord I would use an Apple or Microsoft commercial garbage
It'd be nice if you could just customize Android on ARM and have lots of different spin-offs in the same way you have various x86/64 and PPC Linux distros. I wrote about this:
http://penguindreams.org/blog/android-fragmentation/
The problem is with all these ARM boards. As other comments have pointed out, vendors have tons of binary blobs and shim layers that link them to the kernel. Nvidia/AMD do this too with their video drivers, as well as Intel/Broadcom/Atheros with their Wi-Fi/BT chips. The difference on the PC platform is that it's standardized enough that you can run any kernel/distro on almost any x86/64 board and it will boot and give you a console.
Android vendor kernels are patched to hell, duct tape, just enough crap to get to production style software. They don't submit patches upstream because their code is often junk. ARM SoC are also all incredibly different.
You can download x86/64 versions of Debian, Gentoo, Void, Slackware, whatever and it will at a minimum boot on any PC hardware made in the past few years (probably even a Pentium if you use a 32-bit distro). Not all your hardware will work, but it will at least boot. ARM makes no similar guarantees. Cellphones don't support device trees, and even if they did the whole device tree system is a mess of its own.
Google has ultimate control over all vendors with the OHA. They can mandate standard kernels and drivers across devices. They won't though. There's simply too much money in requiring people to replace devices every two years.
http://penguindreams.org/blog/android-fragmentation/
The problem is with all these ARM boards. As other comments have pointed out, vendors have tons of binary blobs and shim layers that link them to the kernel. Nvidia/AMD do this too with their video drivers, as well as Intel/Broadcom/Atheros with their Wi-Fi/BT chips. The difference on the PC platform is that it's standardized enough that you can run any kernel/distro on almost any x86/64 board and it will boot and give you a console.
Android vendor kernels are patched to hell, duct tape, just enough crap to get to production style software. They don't submit patches upstream because their code is often junk. ARM SoC are also all incredibly different.
You can download x86/64 versions of Debian, Gentoo, Void, Slackware, whatever and it will at a minimum boot on any PC hardware made in the past few years (probably even a Pentium if you use a 32-bit distro). Not all your hardware will work, but it will at least boot. ARM makes no similar guarantees. Cellphones don't support device trees, and even if they did the whole device tree system is a mess of its own.
Google has ultimate control over all vendors with the OHA. They can mandate standard kernels and drivers across devices. They won't though. There's simply too much money in requiring people to replace devices every two years.
You're spot on here.
To also add, some (most!) vendors make dirty hacks to the kernel source, as they maintain it as a standalone tree for the most-part.
Wired the headphone jack the wrong way around? Don't bother with a new PCB revision, as deadlines are too tight, and getting things perfect seems to have no place; just hack at the driver code in a messy way and change the outputs! It's not like you're ever going to really keep the device supported for a long time anyway!
So you get layered hacks - the SoC maker adds their own hacks because their production cycles are so short. Then the OEM gets the SoC and integrates it with their board, and due to their short development cycle, hacks around any issues they have too. End result is unmaintainable spaghetti of hacks and tweaks, which mainline wouldn't touch in a million years.
To also add, some (most!) vendors make dirty hacks to the kernel source, as they maintain it as a standalone tree for the most-part.
Wired the headphone jack the wrong way around? Don't bother with a new PCB revision, as deadlines are too tight, and getting things perfect seems to have no place; just hack at the driver code in a messy way and change the outputs! It's not like you're ever going to really keep the device supported for a long time anyway!
So you get layered hacks - the SoC maker adds their own hacks because their production cycles are so short. Then the OEM gets the SoC and integrates it with their board, and due to their short development cycle, hacks around any issues they have too. End result is unmaintainable spaghetti of hacks and tweaks, which mainline wouldn't touch in a million years.
If the vendor is patching kernel they probably must release their patches and proprietary drivers as GPL requires (regarding drivers they could avoid this by moving important parts into userspace).
There's two things that happen: one is adding more hacks in the kernel that while required to be released under the GPL (and sometimes are, sometimes aren't!) are never going to reach the mainline kernel in a thousand years because they are way too hacky.
The other is creating userspace blobs that get passed void* from the kernel containing (kernel) internal data structures. The problem then comes about when the kernel changes those data structures.
The other is creating userspace blobs that get passed void* from the kernel containing (kernel) internal data structures. The problem then comes about when the kernel changes those data structures.
Because there's a very finite amount of open-source developer time in the world, and expending it all over the same territory over and over is foolish.
Developer time is not a finite resource. People contribute to projects that they are passionate about. Fragmentation can encourage engagement. It's not like unpaid xfce and kde developers would start kernel hacking if everyone converged on gnome, even if it would benefit the ecosystem. Many would pursue other hobbies.
Developer time is finite. Fact. There's no basis to question this. There's limited numbers of people on the planet and they have limited time. Sure, the number of contributors can grow (we haven't reached peak-developer numbers), but it actually grows more with success than with failure. Fragmentation is fine if there's actually enough resources for at least one project to really succeed. In most cases, and probably in the case of community-centered free/libre/open Android variants, there's a shortage of developer time and a real worry about it being fragmented into multiple projects instead of being more cooperative.
Volunteer open source developers are not interchangeable cogs ('resources') to be redeployed across projects at will by anyone except themselves - they are volunteers and work on stuff they are passionate about.
The F/OSS 'community' has some of the most entitled folk on this blue planet - I'm yet to hear anyone suggest pet shelter volunteers work together on a mega-shelter instead of "wasting effort on duplicate roles".
The F/OSS 'community' has some of the most entitled folk on this blue planet - I'm yet to hear anyone suggest pet shelter volunteers work together on a mega-shelter instead of "wasting effort on duplicate roles".
That's a false equivalency. No one suggests IT staff deploying hardware are B duplicating effort because there's a physical correlation between results and resources.
But 10 different desktop environments are each solving the same problem 10 different ways, consuming 10 developers time, when a collaborative project would be able to reduce that by a huge factor and benefit everyone.
I would also suggest it's naive to think charity's don't have opinions about the duplication of effort. 10 storage animal shelters might very well waste funding and resources which could otherwise support 2 or 3 better equipped ones.
But 10 different desktop environments are each solving the same problem 10 different ways, consuming 10 developers time, when a collaborative project would be able to reduce that by a huge factor and benefit everyone.
I would also suggest it's naive to think charity's don't have opinions about the duplication of effort. 10 storage animal shelters might very well waste funding and resources which could otherwise support 2 or 3 better equipped ones.
>But 10 different desktop environments are each solving the same problem 10 different ways, consuming 10 developers time, when a collaborative project would be able to reduce that by a huge factor and benefit everyone.
Most of the time, they don't merge because they don't want to.
For example, the guys working on Gnome3 wouldn't want to work on LXDE and vice versa. People want to scratch their itch. If I have a light computer (or have heavy tasks), I cannot run Gnome3. If LXDE didn't exist, I would go without a window-manager or would switch back to Windows.
And many who would look at an "ugly" DE like LXDE would switch back to Windows if they didn't have Gnome3.
Most of the time, they don't merge because they don't want to.
For example, the guys working on Gnome3 wouldn't want to work on LXDE and vice versa. People want to scratch their itch. If I have a light computer (or have heavy tasks), I cannot run Gnome3. If LXDE didn't exist, I would go without a window-manager or would switch back to Windows.
And many who would look at an "ugly" DE like LXDE would switch back to Windows if they didn't have Gnome3.
>> when a collaborative project would be able to reduce that by a huge factor and benefit everyone.
Or benefit no one because you create a Desktop that no one likes because it is developed in a way to pisses everyone off
Gnome users do not like the KDE Experience
Awesome Users do not like the Gnome Experience
XFCE users do not like the Awesome Experiance
This is the reason these products exisit, and no it is not "duplicating efforts" any more than have different models of Cars is "duplicating efforts"
Do you really believe the automotive industry would be better off is all the Auto Manufacturers did away with all Models and simply made 1 car.
Or benefit no one because you create a Desktop that no one likes because it is developed in a way to pisses everyone off
Gnome users do not like the KDE Experience
Awesome Users do not like the Gnome Experience
XFCE users do not like the Awesome Experiance
This is the reason these products exisit, and no it is not "duplicating efforts" any more than have different models of Cars is "duplicating efforts"
Do you really believe the automotive industry would be better off is all the Auto Manufacturers did away with all Models and simply made 1 car.
> Do you really believe the automotive industry would be better off is all the Auto Manufacturers did away with all Models and simply made 1 car.
Nope, nobody believes that. Which is why any argument attacking that sort of thinking is nothing more than straw-man arguing.
What people believe is that some situations exist where fragmentation of effort produces far inferior results to coordinated efforts. The different factors that determine this are numerous and complex. Suffice to say, this sort of situation where fragmentation is indeed bad is common but far from universal in software.
The comments in this thread show some people insisting that this type of issue exists (and they are right) and some other people insisting on some dogma that fragmentation and competition are always fine (or something that sounds like that) and are arguing with straw men who think that coordination is always good and fragmentation is always bad.
Nope, nobody believes that. Which is why any argument attacking that sort of thinking is nothing more than straw-man arguing.
What people believe is that some situations exist where fragmentation of effort produces far inferior results to coordinated efforts. The different factors that determine this are numerous and complex. Suffice to say, this sort of situation where fragmentation is indeed bad is common but far from universal in software.
The comments in this thread show some people insisting that this type of issue exists (and they are right) and some other people insisting on some dogma that fragmentation and competition are always fine (or something that sounds like that) and are arguing with straw men who think that coordination is always good and fragmentation is always bad.
This request shows a deep misunderstanding of the issue at heart and of the history between Google and Cyanogen.
For one, Cyanogen has always refused to follow Google's guide lines and license terms. This is both what makes Cyanogen appealing to a small minority of users and also why there is absolutely zero chances why Google would ever fund this kind of effort.
For one, Cyanogen has always refused to follow Google's guide lines and license terms. This is both what makes Cyanogen appealing to a small minority of users and also why there is absolutely zero chances why Google would ever fund this kind of effort.
as has been discussed elsewhere, the ability to avoid using google services is a serious disincentive for google to support cyanogenmod.
> as has been discussed elsewhere, the ability to avoid using google services is a serious disincentive for google to support cyanogenmod.
The same argument applies to AOSP (cyanogenmod's upstream), but that hasn't stopped Google from supporting it.
The same argument applies to AOSP (cyanogenmod's upstream), but that hasn't stopped Google from supporting it.
Supporting the upstream is different. One cannot simply download AOSP and install it on your phone, however custom roms provide something you can actually download and install. Google deliberately does not improve the AOSP base applications because they don't want people using their proprietary apps. Google mainly supports AOSP because they can get more people hooked on google services with it than they loose from things like Kindle.
So directly supporting an easy, installable downstream with bells-and-whistles like cyanogenmod would be a serious threat to google.
So directly supporting an easy, installable downstream with bells-and-whistles like cyanogenmod would be a serious threat to google.
With a little bit of careful adjustment to settings, you can disable all Google services on a Nexus device. It takes a little effort, but it can be done - unrooted and unmodified.
interesting. I'm aware that to quell anticompetitive accusations, google allows removal of many google apps and disabling of many services. But I believe the Google Play Services is deeply embedded in the google stock rom such that it can't be safely disabled in entirety.
I had to install CM to do that on my Nexus 5.
Maybe make it a law that company needs to maintain certain level device security via software update for N years for internet connected devices.
Or they are required to release those device's source code to (and pay for) the "communities" for the maintain the security updates.
If they don't do it, they are responsible to damage caused by those devices because of security issue or the customer's loss of data/privacy due to hacking by 3rd parties.
Similar to recent case where "food processor" company is liable if the blade is cracked into pieces into the processed food after a few years.
Or they are required to release those device's source code to (and pay for) the "communities" for the maintain the security updates.
If they don't do it, they are responsible to damage caused by those devices because of security issue or the customer's loss of data/privacy due to hacking by 3rd parties.
Similar to recent case where "food processor" company is liable if the blade is cracked into pieces into the processed food after a few years.
It's really though to legislate anti planned obsolescent legislation without people screaming socialism. This is essentially what is needed.
> Maybe make it a law that company needs to maintain certain level device security via software update for N years for internet connected devices.
Just expand the warranty laws – security updates are fixing a manufacturing defect that makes the device unusable.
Just expand the warranty laws – security updates are fixing a manufacturing defect that makes the device unusable.
Also, why don't they remerge with OmniRom?
I was hoping for the same thing. Ideally the two projects haven't diverged too much already. I don't see any mention on OmniROM's blog (last update was Dec 20). I know Omni has separate additional features like OpenDelta (for incremental updates) and OmniSwitch.
Very pleased by this. Have used CM on my phone for over a year now, was quite scared with the idea of it disappearing!
(Will also look into seeing how I can contribute, although every time I've tried I've hit a "users file crappy bugs" filter that stops me reporting without installing a debug build on my main phone.)
(Will also look into seeing how I can contribute, although every time I've tried I've hit a "users file crappy bugs" filter that stops me reporting without installing a debug build on my main phone.)
I am very happy to see the continuation of CM in the form of LineageOS. Thank you.
So is it time to buy a phone instead of my OnePlus One as it won't be updated anymore?
Beware of this if you are on a OPO running a Cyngn firmware:
https://www.reddit.com/r/oneplus/comments/5k8ppv/former_cyan...
Not really a brilliant source, but I'd be inclined to believe it in this case. It fits with my understanding of the situation.
https://www.reddit.com/r/oneplus/comments/5k8ppv/former_cyan...
Not really a brilliant source, but I'd be inclined to believe it in this case. It fits with my understanding of the situation.
You're probably better off using a stock Android derivative built for OPO. There's always a nice variety of them on xda-developers.
I used to use CM on everything but over the last few years I've been plenty happy with pure stock Android (+ root). Didn't end up using most of CM's extra features and found that it was often unstable and/or leaving lots of things just sort of half-working.
I used to use CM on everything but over the last few years I've been plenty happy with pure stock Android (+ root). Didn't end up using most of CM's extra features and found that it was often unstable and/or leaving lots of things just sort of half-working.
>There's always a nice variety of them on xda-developers.
I personally stay away from there.
For root level access, I'd prefer relying on a project with actual reputation on the line, and has periodic spot checks.
I personally stay away from there.
For root level access, I'd prefer relying on a project with actual reputation on the line, and has periodic spot checks.
If you have a popular device, that idea is fine. If you don't, I'm not sure if you're going to have much of an option moving forward. Less common devices frequently have phone-specific builds of popular distributions like CM published by a developer-user on xda as their only non-default option.
Even CM's support for a wide range of hardware was mostly bankrolled by Cyanogen Inc, which will now no longer be funding them as they rebrand under LineageOS. It's unclear whether any but the most popular phones will continue to see support from a group that has "actual reputation" on the line or not.
Even CM's support for a wide range of hardware was mostly bankrolled by Cyanogen Inc, which will now no longer be funding them as they rebrand under LineageOS. It's unclear whether any but the most popular phones will continue to see support from a group that has "actual reputation" on the line or not.
They had a lot of phones before Cyanogen Inc.
They were the base Mod behind others (like Open Kang)
They were the base Mod behind others (like Open Kang)
>Didn't end up using most of CM's extra features and found that it was often unstable and/or leaving lots of things just sort of half-working.
Privacy guard still beats whatever stock rom has.
Privacy guard still beats whatever stock rom has.
Do you have one in mind that you recommend?
OnePlus (One) hasn't been really updated well at all, Both Cyanogen and Oxygen OS builds were late and filled with problems.
That was true pretty much out of the gate.
The newer phones come with Oxygen OS or w/e they call it now and at least get some sort of periodic update.
The newer phones come with Oxygen OS or w/e they call it now and at least get some sort of periodic update.
The AOSP fork for bacon is still quite well supported. I'm sure the community support would be enough for security patches and updates given how massive it still is.
The name doesn't exactly roll off the tongue.
Rolls better than cyanogenmod, which was always hard for regular folk.
I agree -- it's almost as clumsy to pronounce as cyanogenmod, and the meaning isn't particular inspiring or evocative. HeritageOS? AncestryOS? FamilyOS? DerivationOS? Why do I want to use it, now?
would be great if software developers named their project simply based on what their project actually does (e.g. "Word"). For example: "OpenPhoneOS".
> OpenPhoneOS
So it doesn't work on tablets?
Is it open to hackers?
What's an OS?
There's a reason Amazon isn't called "books.com" - definitive names rarely make for good brands. They limit your options and can carry preconceptions.
So it doesn't work on tablets?
Is it open to hackers?
What's an OS?
There's a reason Amazon isn't called "books.com" - definitive names rarely make for good brands. They limit your options and can carry preconceptions.
fair points...that was just the first thing that came to my mind. Better might be something along the lines of: LibreMobile
Of course you don't want too definitive to limit your options. But what I'm criticizing is things like "Cyanogenmod" (what does green-blue have to do with it? is is some type of element?) or "Android" (is it a robot?). Apple won a lot of users simply with a simple definitive name "iPhone". And you can have definitive names that leave options open, e.g. "YouTube" or "The FaceBook".
Of course you don't want too definitive to limit your options. But what I'm criticizing is things like "Cyanogenmod" (what does green-blue have to do with it? is is some type of element?) or "Android" (is it a robot?). Apple won a lot of users simply with a simple definitive name "iPhone". And you can have definitive names that leave options open, e.g. "YouTube" or "The FaceBook".
"OrphanOS" would be easier to pronounce and more accurate :)
When exactly will cm shut down? Until when will I be able to get the freshest nightlies of CM14.1?
Secondary source since the website seems down right now.
http://www.androidpolice.com/2016/12/24/cyanogen-shutting-se...
At some point before 31st December (at the latest), according to their blog post. In reality, their website is down right now. Downloads and other sites are up, but the blog is down.
http://www.androidpolice.com/2016/12/24/cyanogen-shutting-se...
At some point before 31st December (at the latest), according to their blog post. In reality, their website is down right now. Downloads and other sites are up, but the blog is down.
Also, will I have to re-reclean flash LineageOS over CM?
What's the background on this?
Why is Cyanogen shutting down?
Why is Cyanogen shutting down?
There was more discussion recently at https://news.ycombinator.com/item?id=13249307. Incompatibilities in Cyanogen Inc. leadership plus some bad deals, is what I gathered.
tl;dr Cyanogen Inc failed, and is pivoting away from ROMs.
What I don't get is why they won't just give up the CM name/domain? Are they pulling an OpenOffice?
What I don't get is why they won't just give up the CM name/domain? Are they pulling an OpenOffice?
I suspect this was one of their biggest/only assets. I wonder (purely from a thought experiment point of view) how the original spin-out could have gone if the project had kept the name in trust and granted a worldwide exclusive license for a period of X years, where X was longer than the initial investment term, with a renewal option.
On the other hand, given what's gone down between both sides lately, it seems the split is somewhat less than civil, and holding onto the name and killing off the "annoying project which resents and criticises the company" might be suitably vindictive and designed to cause inconvenience to the project.
On the other hand, given what's gone down between both sides lately, it seems the split is somewhat less than civil, and holding onto the name and killing off the "annoying project which resents and criticises the company" might be suitably vindictive and designed to cause inconvenience to the project.
I'm getting really confused here.
I thought CyanogenOS was a commercial venture that arose out of CyanogenMod. But that they were essentially separate protects. I'd read about CyanogenOS coming a cropper, but understood this wouldn't affect CyanogenMod. Now, these linked articles seem to be treating -OS and -Mod as the same project/same organisation.
Can anyone explain?
I thought CyanogenOS was a commercial venture that arose out of CyanogenMod. But that they were essentially separate protects. I'd read about CyanogenOS coming a cropper, but understood this wouldn't affect CyanogenMod. Now, these linked articles seem to be treating -OS and -Mod as the same project/same organisation.
Can anyone explain?
Cyanogen Inc (the commercial venture) owns the infrastructure and trademarks of CyanogenMod (community project). So now that they've been ditched, the CyanogenMod community has to change the name and find new infrastructure.
[deleted]
Funny they'd use that quote of Andy Rubin, like it means anything nowadays.
https://twitter.com/CopperheadOS/status/772592323112869888
https://twitter.com/CopperheadOS/status/772592323112869888
Any large OSS distribution is going to have a fairly continuous stream of security fixes to ship to their users, and that takes a fair amount of time, and I'm always concerned about whether any new project (okay—it's not quite new, but they have a fraction of the number of developers they did twelve months ago!) has the resources to ship them in a timely way.