I’ve been experimenting with Android on the RCA Viking Pro 10 for a while now. Yes, I should have gotten the Pro 12 for its slightly better keyboard, but, putting aside that massive design flaw, Android itself sucks. This entire “lock everything down to make it useless” approach is only interesting for a couple of days. I mean applications cannot even write to the /tmp directory so everything you try to install in one of those terminal apps has be to custom coded to reference $TMPDIR (or whichever environment variable the terminal shell provides) instead of /tmp referenced by millions of scripts and applications around the world.
Having every app under the sun force Malvertising on you is both annoying and unsafe. No, I’m not being Chicken Little using that term.
I will be the first to admit trying to base something you wish to be secure on Linux, or any OS which originated on PC hardware is rather stupid. They all had vicious design flaws. While much of the kernel is written by more senior level developers, the bulk of everything else is written by 12 year old kids with time on their hands and just a little bit of coding skill, not design, coding. Every one of them seems to find some distro somewhere which lets them check in code and that code then gets kicked back up the food chain.
Most of you, even the non-geeks reading this, have probably heard expression like “passing by pointer” and “buffer overrun.” There are many others, but, generally, the second happens because someone did the first and had no knowledge of either design or software architecture. Even though there were many examples of how to do things right, most new coders and those who are in a hurry take shortcuts which leave gaping security holes in their final product. Most PC based operating systems (OS) have this issue in both their kernel and core drivers such as network and disk drivers. They accept things by reference (pointer or address if you prefer) and ass-u-me what it is.
High quality operating systems pass everything via descriptor or fixed size value. By fixed size value I mean binary data such as an integer or floating point data type which has a fixed size defined by the platform. There is no chance of overflow with platform defined values because only the N-bytes defined by the platform are ever used.
Descriptors have different names on different high quality operating systems. If they are only used at the API (Application Programming Interface) level and not the kernel+driver level, then it is not a high quality operating system. By and large descriptors have a somewhat common layout.
struct dsc$descriptor {
unsigned short dsc$w_length; /* specific to descriptor class; typically a 16-bit (unsigned) length */
unsigned char dsc$b_dtype; /* data type code */
unsigned char dsc$b_class; /* descriptor class code */
char *dsc$a_pointer; /* address of first byte of data element */
};
Please forgive any spacing errors in the above.It was a cut and paste from the PDF of “The Minimum You Need to Know to Be an OpenVMS Application Developer” where I discuss the concept of descriptors in much more depth. While there will be many different descriptors for many different data types they all start with a common beginning. Yes, descriptors themselves are typically passed by reference but that very first component: dsc$w_length is a fixed size value containing the byte size of the descriptor. The second value: dsc$b_dtype indicates the data type. The third value: dsc$b_class indicates the descriptor class and you can pretty much decipher from the comment the fourth value is the address of the data itself.
Without geeking out too much on you, the combination of the type and class identify not only what the data is to the receiver, but which descriptor to use. Bringing the topic down to common language, if you had a list of counting numbers stored in an array the class would be something to indicate ARRAY and the type would be some form of INTEGER. Yes, different programming languages store arrays differently in memory, but that is too much geek for this blog.
So, why does any of this matter? you ask.
Andriod is a hodge podge of a platform bolted onto a Linux kernel. Between kernel tweaks and the hodge podge it was designed to keep the user locked out of most things the Linux kernel normally allowed a general user to do, such as write to the /tmp directory. /tmp is the universal temporary directory most everything can use on Linux and each distro makes decisions about cleaning it either when a user logs out or when the system is rebooted. In short, you leave stuff lying around and periodically your mommy comes by and cleans your room.
I haven’t dug into the code for Fuchsia but I’ve seen quite a few blog posts like this one. I have little hope this will turn out any better than Android or Chrome primarily because of the pool of developers Google seems to pull from. Kids that never worked on real computers. Given they are starting with Magenta, another OS I haven’t dug into the source on but one which pulls from the same developer pool according to what I read, I hold out little hope this kernel will mandate the passing of things via descriptor which means it will not be any more robust or secure than previous platforms. The readme.md file offering a link to the Canonical (makers of ubuntu) repository gives me pause. We now have two companies forking their own version of a kernel which means cross platform development for app creators will be yet another naked crawl down an alley covered in broken glass.
Most of you haven’t seen what is going on in the Linux touchscreen world. We will skip the ugly and disgusting Unity interface Canonical is forcing on the world and talk about Elementary. It works well on touch screens (those which support common driver APIs) offering flick, drag, and with the correct type of touch screen pinch. If you don’t know what those gesture terms mean, the interface is pretty much like those identity theft enabling devices some people call “smart” phones. It has the familiar commonly used/favorites app quick access bar at the bottom and a full application menu at the top. I don’t remember, but I think you can also move that app bar to any screen edge you like. I seem to recall doing it by accident once.
The point is this is a full blown Linux which already gives you an Android type user experience so, why would anyone who has ever tried this choose a cobbled together thing like Android? With Elementary you don’t have Malvertising forced on you. You can use great editors and email clients which don’t share all of your private data with Google or you can choose to use Google applications, not an intelligent choice, but one which might be forced on you by an employer.
While this little device is light weight and seems to have good battery life, the Android platform frustrates me minute by minute. Google has forgotten the prime rule of devices. They must first make the user’s life better. Android fails miserably here. Google focused more on enriching itself now that everyone runs ad blockers because we are sick and (^)(*&)(*ing tired of Adwords popping up everywhere dragging down page load time and causing pages to jump spastically displaying then hiding banner ads after the top of the page has loaded.
Having said all of this, I cannot wait to finish my cross compilation experiments so I can try loading Elementary on this unit, permanently uninstalling all traces of Google.