-
Explaining choices behind the project
01/14/2017 at 01:00 • 6 commentsWhy develop something new when there are dumbphones and rootable smartphones available?
Three main factors are accessibility, innovation and openness of both hardware and software. It's that much easier to tinker with mobile phones and write all kinds of apps when you have a phone that's as modifiable as possible and is cheap. Besides, I have problems with the OS that seems obvious for open-source - Android (explained below).
For me, this project is a huge undertaking that, if done right, will influence the way we perceive mobile phones, help us in solving the privacy and security concerns we're currently facing, as well as allow us to develop better open-source GSM technology and power our mobile phone hacks. I believe this can change the world for the better - by enabling people to experiment with things that have become inseparable from us but are so far away from being open to experiments.
Besides, this is an open-source Linux-powered phone you can independently assemble for <50$ - that's pretty cool and alone deserves being brought to life!
But Raspberry Pi isn't fully open-source! Neither hardware schematics nor Gerbers for Pi Zero are available, and there are binary blobs that are necessary for the Pi to work! And we can't be sure that SIM800/ATMega doesn't have any backdoors!
No doubts, Raspberry Pi isn't fully open-sourced and open-hardware (though we might get there sooner or later, there are no guarantees). However, if you examine current single-board computers that can be bought for a reasonable price, Raspberry Pi has superior community support, price, availability, power consumption and, last but not least, hardware that's actually supported instead of simply being there with no software to back it up.
Moreover, the component choices were made to ensure the project has as much chances to succeed as possible. Want to hear more of the reasoning behind this? It's going to be explained in one more article soon.
I see a small display and a keypad. Where's my big touchscreen display?
Price, simplicity and ease of development. Touchscreen-enabled displays are pricier, take more GPIO (sometimes requiring too much pins or reserving some that would be typically required by other hardware present) and will consume more energy (the battery life is a concern worth working on already). Moreover, there are numerous lessons that we can learn from the existing keypad-enabled phones we've had.
Furthermore, developing an efficient UI for larger displays while keeping up with the demands of users can quickly become much harder than anticipated - for example, once this phone will have a big display, there'll be many users wanting to use native Linux apps, and most of them aren't optimised for touchscreen usage. While I'm not that concerned about any patents this might infringe on, the fact that most the patents for keypad phones are likely to have expired by now can help avoid patent trolls' attacks, which is unlikely to happen, but sure is a nice thing to be calm about.
I'll also remind you that it's possible to simply keep the Pi Zero and the back panel with modem and develop a touchscreen display front panel - this is open-source hardware! In the end, it will just be simpler for the project to start this way.
What about Android? There are fully open-sourced forks of it, many oriented on security features and many - on customizability!
That is true, however, let's start with the fact that porting Android to Pi Zero wasn't successful, even though there seemed to be some movement behind it. This alone makes this project much more difficult for me to tackle - especially given that Android seems to have mostly dropped support for ARM processors as old as a Zero has onboard.
Also, Android is a big complicated system. I want to make development easy even for those coming from a non-Java background. In the end product, I'm going to use lots of Python with C in places where performance matters. That means discarding the app ecosystem of Android, which is a bold move, but a necessary one - let's see why.
My main concern is that most apps, however simple they could be, aren't open-source - this is simply not something developers are used to in the Android world. You put the app out there, support it some, possibly, make money on the ads and/or sales - there's hardly ever an incentive to open-source an Android app, unless as a gesture of kindness from the developer. Theoretically, there's nothing wrong with that - however, there's a corellation between this and a huge market of apps that are bloated, collect too much private data or don't really work well (or all three simultaneously, such as infamous Facebook app). Add this to the fact that a keypad&small display phone can't make use of most of the apps touchscreens are for
After all, Android doesn't have any apps for the types of displays we're using - and by the time this project grows to be big enough to have a good touchscreen UI, there is even a possibility of having an Android emulation layer in Linux, which will be a nice addition that, unfortunately, isn't yet feasible. As for now - I'm sure we should get Snake on this! (if you're ready to help, PM me and I might just have a prototype board for you).
Hey, Python is slow!
Not slow (I have a UI project fully in Python that's very responsive) - and certainly not in the places it's going to be used for. It makes sense to use lower-level languages in segments of code which are visited very frequently or take a long time to be executed. Most of the code that runs a phone like this will be neither, and the readability benefit we get is an enormous contribution to making this project accessible for others to tinker with and build upon it. Let's also not forget the fact that Python is language of choice for most Raspberry Pi users using it for programming!
Simply put, it's much easier for a beginner to achieve his goals using a Python-powered phone as a base than it could be with C - and since this project is meant to be modified and improved upon, Python is the best choice you could make.
Also, since the architecture of UI framework won't be monolythic, it will be possible to port the app-facing side of UI framework to many different languages, enabling you to develop for this phone using your language of choice!