Experience

It was a new cloud product intended to be a regular computational cloud from a customer's point of view but running on consumers' mobile devices instead of conventional GNU/Linux servers. Considering that mobile CPUs become increasingly powerful with time and that many mobile phone owners don't use them 24 hours a day, it was worth trying to use that free power for good.

In May 2015, Dr. Lloyd Watts contacted me after finding my open-source project CrystaX NDK and reading my announcement that with CrystaX NDK, one can now use Boost C++ libraries on Android. That was a big accomplishment, and it convinced him that Android could be used for something serious, not just for playing games with angry birds and green pigs.

Long time I was the only developer on the project. Since the beginning, it was unclear if such a project would be technically viable in principle, so a lot of research was needed to determine if it made sense to continue.

The main question was: "Would it be technically possible to run third-party code on consumers' mobile devices? Wouldn't it create a security hole on both sides - i.e., to customers, who could lose their secrets by passing them to unknown mobile devices; and to phone owners, who could lose their contacts, photos, and other personal information by allowing an unknown code running on their devices?"

Another question was: "How, in principle, can one run GNU/Linux software on Android devices?". It was a fundamental question, too, just because compatibility is the key in such a game. It's impossible to overestimate its importance.

All those questions and many others were answered by me with time. It was an extremely ambitious project, where I bumped into numerous challenges and solved many technical problems.

Not disclosing all the details and issues, here is what I accomplished in that project:

• I designed and developed a new containerization technology, which allows running full-fledged GNU/Linux systems on non-rooted stock Android phones in the background. It was a great challenge because, nowadays, all Linux kernel containerization techniques require an increased level of privileges to run containers. Obviously, there is no such ability on consumers' Android devices, where we can't control their firmware while running a typical Android application. No additional permissions, running in a sandbox, limited by all directions - but I was able to overcome all these limitations and get to the working implementation!

  This part of the project was done in C and C++.

• I developed a mobile Android application, PhonePaycheck, to act as a work node for the cloud. Also, I integrated the above-mentioned containerization technology inside that mobile application, so any Android phone owner was able to allow us to run an arbitrary GNU/Linux code on their device just by downloading PhonePaycheck from the Google Play store, plugging it into the charger, and by connecting it to Wi-Fi (in reward, we were paying the device owner fee for the rented CPU time). No device rooting, no long and complicated geeky configuration. A smooth and fully automated workflow.

  This part of the project was done in Java.

• I developed a server-side management platform to handle work nodes, distribute tasks to the workers, collect the results, provide them to customers, and so on. Also, I implemented all the administration and maintenance functionality required for such a project.

  This part of the project was done in Ruby on Rails with Redis and PostgreSQL on the backend and in JavaScript with React on the frontend.

It was a terrific project, and I'm sorry it ended for non-technical reasons. It was a big piece of my life. I took the project personally and invested all my talents and work experience. And this project gave me a precious life acquisition — Dr. Lloyd Watts, whom I can unambiguously call not just a colleague but my friend.

It's a project which uses home computers all over the world for doing protein folding computations. The amount of needed computations in this domain area is absolutely enormous. Therefore there is no (and won't be) any single computer that's capable of doing all of them within a reasonable time frame. Because of that, the Folding@home project was established in 2000. From the beginning, it was a distributed computing project aimed to run on the home computers of enthusiasts worldwide. Those enthusiasts provide their idle computational power to the project for free. Read about it on Wikipedia to get more details.

At the beginning of 2020, the project got a new life because of the quickly distributing COVID-19 pandemia. Humankind needed a vaccine to deal with it, but how was it possible to get it quickly? The only answer was: "By doing excessive computations, helping the real biological experiments go in the right direction." Using computer-based simulations, scientists can get results much quicker by disqualifying many potential paths in the early stages and not wasting their valuable time on fruitless research.

We at Neocortix quickly realized we might help in that by providing our cloud network for such computations. At that moment, we already had a working implementation of my new containerization technology, which allowed us to run GNU/Linux software on Android. But the main problem was that Folding@home was never aimed at the Arm platform. It was a typical Intel-centric project, exploiting regular Intel-based computers with Windows, GNU/Linux, and Mac OS on board.

We started looking for contacts in the Folding@home project to talk with and to clear out if our help would be valuable. We quickly found such contacts, not only in the Folding@home project but in Arm, too. Our expectations were proven true - Arm was not on the list of supported platforms in the Folding@home project. So we offered our help porting the Folding@home to Arm platform (AArch64), and they gladly accepted our help.

Long story short, after a few months of development and internal testing, I was able to move the Folding@home project to the recent GROMACS version and then fully supported the Arm platform for GNU/Linux builds of Folding@home. And then, Folding@home officially announced the Linux-on-Arm release.

Even though initially, Folding@home representatives were pretty skeptical regarding the actual value of the Arm platform for their needs, life quickly proved that my work at porting the project to the Arm platform was done in time. A few weeks after the official Folding@home Linux-on-Arm release, Apple announced their new Arm-based M1 platform. It was the first mighty consumer-class Arm device on the market. Of course, I immediately took responsibility for it and ported Folding@home to the Apple M1 platform. This time it was much easier to do, considering that the main work was already done in the previous stage. There were only minor changes in the sources required to be done to support Apple M1.

It was a great multi-company collaboration, where I got a lot of pleasure, working with people from different companies and worlds - Rex St. John and John Linford from Arm, Dr. Greg Bowman from Washington University in St.Louis, Joseph Coffland from Cauldron Development, and many others.

Here are a few links to read more about this collaboration:

• Multi-Company Collaboration For Coronavirus Research On Arm Devices
• They blinded me with science (and hit me with technology)
• Folding@home ARM support lets Android devices crunch COVID-19 research data

It was a widely-known open-source project that allowed the development of applications (or their parts) for Android in C and C++.

Initially launched as a fork of Android NDK (Native Development Kit) from Google, CrystaX NDK quickly became a popular open-source project. In its early days, CrystaX NDK was just "an improved Android NDK with C++ and exceptions" (the official Android NDK from Google didn't provide good C++ support those days). But with time, I evolved the project to a mature state, continuously improving it and always being a step ahead of Google's NDK.

As a C++ developer, I knew very well what such developers needed. So I kept adding to the project a functionality required for me. And it appeared that such functionality was needed not only by me. After all, this is a typical life trajectory of open-source projects. Do what you need; most likely, you won't be the only person who needs that.

Because of that, growing with time, CrystaX NDK became not just "an improved Android NDK with C++ and exceptions" but a full-fledged development toolkit, which included tons of new functionality. My main goal was to make the development for Android in C and C++ as compatible with industry standards as possible, ideally making it not differ from the development in C and C++ for GNU/Linux.

To overcome many Android limitations, I came up with the idea of building my own libc replacement. This library was then created and got the name "libcrystax". It was the heart of the whole project because, not being limited by the stripped Android libc, I was free to add new features and make the entire toolkit behavior conform to international C and C++ standards.

One especially important point in the project life was a moment when I added support of Boost C++ libraries to CrystaX NDK. There's no need to explain to C++ developers what Boost C++ libraries are. But for those unaware, I'll only say it's a huge project, including tons of modern C++ libraries. Many of them are implemented "on the bleeding edge," exploiting non-obvious or not-yet-standardized language features as well as unexpectedly-recognized language abilities to do some things not initially designed by the language designers.

All that made Boost project a testing ground for C++ evolvement as a language. Many new ideas go through run-in in Boost first before being included in the C++ language standard. And because of that, Boost was a great candidate to test the maturity of my project, CrystaX NDK.

It was a long road, but eventually, I got to the point where all Boost C++ libraries were built without any modification in upstream sources. That was my primary approach - if something didn't compile or didn't work correctly, I didn't modify the project being built with CrystaX NDK. Instead, I used to fix the CrystaX NDK itself, achieving the desired result of conformance of my toolkit to the industry standards.

This approach also allowed us to build and support Python on Android as well as many other open-source tools and languages from GNU/Linux world - all the same, without any modifications in the upstream sources.

The project was very popular, and many open-source and commercial projects from all over the world used to use it as a drop-in replacement for Google Android NDK. Due to the open-source free-to-download nature of the project, I'm unaware of all the projects and organizations that used CrystaX NDK, but Ogre3D, OpenCV, Kivy, and even NASA were among the most famous of them.

It was a development of a new Android-based tablet VIZIO VTAB1008.

I participated in this project as a subcontractor, and it was an extremely interesting and important experience in my life. It was a fork of AOSP (Android Open Source Project), which we then started improving and developing. It was not a "development for Android." It was literally a "development of Android."

In this project, I learned Android internals very well, from the kernel level to UI. It immensely helped me with my further endeavors.

I'm tremendously grateful to Marcus Williford, who involved me in this project.

It was a development of the open-source product Rhodes, a part of RhoMobile Suite.

I joined the project not from the beginning but in its early stage. I took responsibility for the project's Android, iOS, and Blackberry backends and significantly developed them.

I implemented a joint C++ engine for Android and iOS backends and got rid of two similar (but not identical) implementations written in Java and Objective-C, respectively. This way, I significantly lowered the amount of work needed for further development and support of those backends.

I first realized in this project that Android needs a good C++ development toolkit. It was nonsense - to develop the same logic in different languages - Java for Android and Objective-C for iOS. "If only I could use C++ for both of them..." - I thought those days. Finally, I was able to do that, but working on that project, I realized how poor and limited current C++ support is for Android. That became a trigger to start my open-source project CrystaX NDK (see above).

Also, in this project, I learned the Ruby programming language and the Ruby on Rails web backend platform. It was an amazing experience. I love Ruby - in my opinion, this is one of the most feature-rich programming languages nowadays, despite the fact that it's staying in the shadow of its more lucky competitor Python. Ruby is an excellent language for many kinds of automation and production tasks, and I'm sorry it hasn't gotten as much attention in the modern world as Python has.

I'd like to say a "big thank you" to Adam Blum, who, by his example, showed me that an open-source project could be, at the same time, a commercial one. It affected my thinking about the open-source world and its co-existence with the world of commercial projects and significantly helped my further personal development.

This was an out-of-the-box unified communications project, encompassing email, instant messaging, calendars, and VoIP, all bundled into a single package.

Initially, I started as one of the developers on this project, but over time, I eventually headed my own department. In that department, our focus was on developing the server-side components of the project.

Among all the server elements, handling VoIP posed the greatest challenge due to its real-time requirements. In a typical two-party conversation, when there's a delay of more than ~200ms between one side speaking and hearing a response from the other, the human brain perceives it as an uncomfortable delay. Hence, it was crucial to ensure timely delivery of all VoIP data or, if impossible for certain packets, dropping them and applying some smoothing techniques to maintain a comfortable conversation for the human ear.

In this project, I created libraries to manage SIP and RTP protocols, seamlessly integrating them into the VoIP server component for call routing and proxying. All of this was accomplished using C++ and delivered high-performance results.

It was an important project in my career, where I learned many new things, the technical ones, as well as those related to people management.