Experience

The project aimed to create a cloud product that used consumers' mobile devices for computation, providing a familiar cloud experience while leveraging unused processing power on mobile devices. Mobile CPUs are increasingly powerful, and many phone owners don't use them 24/7, making it worth exploring how to utilize this idle capacity.

In May 2015, Dr. Lloyd Watts reached out after discovering my open-source project CrystaX NDK, recognizing my work in enabling Boost C++ libraries on Android after reading my announcement regarding this matter and trying it on his own. This demonstrated that Android could be used for more serious applications beyond typical user-oriented mobile applications and games.

For a long time, I was the sole developer, conducting extensive research to assess the project's technical feasibility.

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.

Over time, I addressed all these questions. It was an extremely ambitious project, where I encountered 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 that enables full GNU/Linux systems to run on non-rooted Android devices. This posed a significant challenge, as modern Linux containerization techniques require elevated privileges — something not possible on consumer Android devices, where application developers cannot control the device's firmware. Without access to elevated privileges or control over device firmware, I worked within the sandbox constraints to achieve a fully functional implementation.

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

• I developed a mobile Android application, PhonePaycheck, to act as a work node for the cloud. Also, I integrated my 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 (as compensation, we paid device owners for the rented CPU time). No need for device rooting or complex configurations. A smooth and fully automated workflow.

  This part of the project was implemented in Java.

• I developed a server-side management platform to coordinate work nodes, distribute tasks, and deliver results to customers, alongside the necessary administration and maintenance functions.

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

This project not only tested my technical skills but also resulted in invaluable experiences and a strong professional relationship with Dr. Lloyd Watts.

This project harnesses home computers globally for protein folding computations. The scale of computations required in protein folding 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 rapidly spreading COVID-19 pandemic. 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 targeted only Intel x86_64 systems running Windows, GNU/Linux, and macOS.

We started looking for contacts in the Folding@home project to talk with and to determine if our contribution 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.

After months of development and 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

CrystaX NDK was an open-source project that enabled C and C++ development for Android.

Launched as a fork of Google's Android NDK (Native Development Kit), CrystaX NDK quickly gained popularity. Initially, it only enhanced Google's Android NDK with better C++ support, particularly for exceptions as the official NDK lacked robust C++ support at the time. 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 features I personally needed. 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.

As a result, CrystaX NDK grew over time into 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++ highly compatible with industry standards, aiming to match 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 became the project's core 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. For those unfamiliar, Boost is a comprehensive collection 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.

This made Boost 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. It became possible because my approach since the beginning was focusing on adjusting CrystaX NDK to fully comply with industry standards, rather than altering third-party projects to ensure compatibility.

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.

CrystaX NDK gained popularity as a drop-in replacement for Google's Android NDK, widely adopted by open-source and commercial projects worldwide. While many users remain unknown due to the project's open-source free-to-download nature, Ogre3D, OpenCV, Kivy, and even NASA were among the most famous of them.

Over time, however, Google improved its NDK enough, and the need for CrystaX NDK diminished. In 2016, I decided to stop working on the project full-time. I still maintain it, but only on a part-time basis. At the moment, the project is in a stable state, and I'm proud of what I've achieved with it.

I don't know what the future holds for CrystaX NDK, but I'm happy to have contributed to the Android development community. And, who knows, maybe one day, I'll return to it.

Here, I contributed to the development of the VIZIO VTAB1008, an Android-based tablet, as a subcontractor. This project was a pivotal experience for me, as it involved creating a customized version of AOSP (Android Open Source Project). Unlike typical Android development, we were deeply engaged in the fundamental "development of Android" itself, in contrast to the usual "development for Android."

Throughout the project, I gained in-depth knowledge of Android's internals, from the kernel level to the user interface, which has greatly influenced my subsequent work.

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

I contributed to the development of Rhodes, an open-source product and part of the RhoMobile Suite.

Although I joined the project in its early stages, I quickly took responsibility for the Android, iOS, and Blackberry backends, significantly advancing their development. I implemented a unified C++ engine for the Android and iOS backends, replacing separate Java and Objective-C implementations. This greatly reduced the maintenance effort for these backends.

During this project, I realized the need for a robust C++ development toolkit for Android. Developing the same logic in different languages — Java for Android and Objective-C for iOS — was inefficient. This insight led me to create my open-source project, CrystaX NDK (see above).

Additionally, I learned Ruby and the Ruby on Rails platform, which was an enriching experience. In my view, Ruby is one of the most feature-rich programming languages, though it often remains overshadowed by Python. Ruby's versatility makes it excellent for various automation and production tasks, and I regret that it hasn't received the same attention as Python. Despite this, Ruby remains a powerful language, and I continue to use it in my projects.

I am grateful to Adam Blum, who demonstrated through his example that open-source projects can also be commercial ones. His example reshaped my view of how open-source and commercial projects can coexist and led me to the next level of professional development, where I started my own open-source project, CrystaX NDK.

This project was a comprehensive unified communications platform, integrating email, instant messaging, calendars, and VoIP into a single solution.

I began as a developer and eventually led my own department, focusing on developing the server-side components. VoIP posed the biggest challenge due to its real-time requirements. A delay of over 200ms in a two-way conversation can disrupt the flow for listeners, so it was crucial to ensure timely delivery or, when necessary, drop packets and smooth the audio.

I developed libraries to handle SIP and RTP protocols, integrating them into the VoIP server for call routing and proxying. This was achieved using C++, delivering high-performance results.

This project marked a significant point in my career, teaching me both advanced technical skills and leadership in managing teams.