SELinux on Android
SELinux on Android
Posted Aug 31, 2014 10:45 UTC (Sun) by yaap (subscriber, #71398)In reply to: SELinux on Android by intgr
Parent article: SELinux on Android
> developers are too incompetent to work on something as complex as X.
> Usually to be proven wrong months or years later.
Competence is not the topic here. Did you know that Fabrice Bellard implemented a LTE eNB in software on a PC using a GNU Radio SDR box for example? Well I did, so I know that a very talented person can implement significant parts of the system.
But because of the huge scope and certification constraints (necessary for the system to work at scale) to get to a deployment quality product requires a lot of QA. The test equipment alone is above $1M, and if you go through a certification lab it'll cost more over time. And it's a lot of human effort to move from "works in the lab" to certified and then to "works well in the field".
So what I mean is that getting to a real product is not possible at an amateur level: you need significant funding.
On principle an open source implementation is possible, but due to the practical funding requirements there would need to be a business case. I don't see one, but would be happy to be proven wrong.
I think we can all agree that Fabrice Bellard contributions to open source are outstanding. But he didn't open source his eNB implementation, it's closed source through a company call Amarisoft (http://www.amarisoft.com/). I guess that even for someone as open source friendly as him the level of work involved requires getting some money out of it. And here I don't think one could monetize this work if open sourced. Why? Because Amarisoft is not a deployment ready product, it's more a technological platform. Only a few companies have the resources to get this into a field product, and if open source they could do this directly without paying. Just my opinion here.
>> You don't want a clueless person degrading possibly several cells
>> capacity just because he boosted his phone transmit power because
>> it's "l33t"
>
> Nice straw man there.
I don't think so, I had real situations in mind when I wrote this.
When open source WiFi AP became available (and I love them, been an OpenWRT user for a while) you could see in the forum people boasting about how they boosted the Tx power to "get better performance". Some did it thinking they extended their reach, not realizing that without boosting the STA side the UL would still limit the reach. Other did it for higher throughput, apparently without realizing too that they could get higher MCS at the price of more interference for others, and that if everyone did the same everyone would loose.
Another example is from the implementation of a 2G device stack (I seem to remember it was discussed on LWN, TBC). The guys told they did their first field tests at max Tx power because gain control wasn't implemented yet. Now this is not as bad in 2G as it would in 3G, but still no operator would allow that in their network.
All this from memory, and I won't spend time searching for precise reference. But it seems common sense that if some parameters become easy to tweak thanks to an open source implementation, some people who are not on top of the consequences will do so, possibly with bad results for others. Not everyone of course, but you can't expect all users to act responsible and it take only one to mess up a cell or more. The tragedy of the commons do apply to airwaves.
This is why I believe cellular networks implementation will remain locked.
I like open source, use Debian whenever I can, but I also believe that locked certified radios attached to open host is the best scheme for all. It's just my opinion, but it's back by years of experience in the field.
