Trying to turn an ARM-64 -based, Android-hosted, prooted Linux Guest System, into a software development platform.

In a preceding posting I described, how I had used an Android app that does not require or benefit from having ‘root’, to install a Linux Guest System on a tablet, that has an ARM-64 CPU, which is referred to more precisely as an ‘aarch64-linux-gnu’ architecture. The Android app sets up a basic Linux system, but the user can use apt-get to extend it – if he chose a Debian 10 / Buster -based system as I did. And then, for the most part, the user’s ability to run software depends on how well the Debian package maintainers cross-compiled their packages to ‘AARCH64′. Yet, on some occasions, even in this situation, a user might want to write and then run his own code.

To make things worse, the main alternative to a pure text interface, is a VNC Session, based on ‘TightVNC’, by the choice of the developers of this app. On a Chromebook, I chose differently, by setting up a ‘TigerVNC’ desktop instead, but on this tablet, the choice was up to the Android developers alone. What this means is, that the Linux applications are forced to render purely in software mode.

Many factors work against writing one’s own code, that include, the fact that executables will result, that have been compiled for the ‘ARM’ CPU, and linked against Linux libraries! :-D

But one of the immediate handicaps could be, that the user might want to program in Python, but can’t get any good IDEs to run. Every free IDE I could try would segfault, and I don’t even believe that these segfaults are due to problems with my Python libraries. The IDEs were themselves written in Python, using Qt5, Gtk3 or wxWidgets modules. These types of libraries are as notorious as the Qt5 Library, for relying on GPU acceleration, which is nowhere to be found, and one reason I think this is most often the culprit, is the fact that one of the IDE’s – “Eric” – actually manages to report with a gasp, that it could not create an OpenGL rendering surface – and then Segfaults. (:3)

 

(Edit 9/15/2020, 13h50: )

I want to avoid any misinterpretations of what I just wrote. This does not happen out of nowhere, because an application developer decided to build his applications using ‘python3-pyqt5′ etc… When I give the command:

 


# apt install eric

 

Doing so pulls in many dependencies, including an offending package. (:1) Therefore, the application developer who wrote ‘Eric’ not only chose to use one of the Python GUI libraries, but chose to use OpenGL as well.

Of course, after I next give the command to remove ‘eric’, I also follow up with the command:

 


# apt autoremove

 

Just so that the offending dependencies are no longer installed.

 

(End of Edit, 9/15/2020, 13h50.)

 

Writing convoluted code is more agreeable, if at the very least we have an IDE in front of us, that can highlight certain syntax errors, and scan includes for code completion, etc. (:2)

Well, there is a Text Editor cut out for that exact situation, named “CudaText“. I must warn the reader though, that there is a learning curve with this text editor. But, just to prove that the AARCH64-ported Python 3.7 engine is not itself buggy, the text editor’s plug-in framework is written in Python 3, and as soon as the user has learned his first lesson in how to configure CudaText, the plug-in system comes to full life, and without any Segfaults, running the Guest System’s Python engine. I think CudaText is based on Gtk2.

Screenshot_20200914-124954_VNC Viewer

This might just turn out to be the correct IDE for that tablet.

 

(Updated 9/19/2020, 20h10… )

Continue reading Trying to turn an ARM-64 -based, Android-hosted, prooted Linux Guest System, into a software development platform.

Getting the Orca Screen-Reader to work under Plasma 5

In case some readers might not know, even though computing is heavily visual, certain advanced desktop-managers can be set up for impaired people to use – which also falls under the category of “Accessibility”. This includes the ability of the computer to speak a robotic description of what’s happening on the screen, in case a user can hear, but not see properly.

There are some users who feel they should stick with Windows, because Accessibility can be so hard to set up under Linux.

There are other users who are sorry they every clicked on “Accessibility”, because now they cannot turn it off.

If a visually-impaired user wants Accessibility set up on a Linux computer, I’d definitely suggest letting a trusted other person set it up, because until it’s set up, complicated things may need to be done, and accessibility will not be set up, so that the end-user will not benefit from Accessibility, while trying to set it up.

Some regular users find screen-readers trying for their patience, because of the fast, robotic voice, until they manage to shut it down again. Personally, I only find screen-readers trying, If I happen to have set one up late at night, because the voice could cause some sort of noise-complaint from my neighbors, droning on until I manage to disable it again. In the middle of the day, I don’t find these experiments trying.

I guess that a good question which some people might ask me, would be why I even do such an experiment, given that I’m not visually impaired and don’t need it. And what I do is set everything up until it works, and then disable it again.

On my recently-installed Debian / Stretch computer named ‘Plato’, which is also running Plasma 5 as its desktop-manager, I just did manage to get this feature to work, and then to disable it again.

(Updated 15h50, 1/17/2018 : )

The first thing I had to do, was install a long list of packages. The list below includes what was installed, but it should not really be necessary to give the command to the package-manager manually, to install everything here, because some of these packages will follow as dependencies from other packages. But here is a roundabout list:

Continue reading Getting the Orca Screen-Reader to work under Plasma 5