I now have LyX working properly, on my Linux tablet.

According to This Earlier Posting, I had installed “GNURoot (Debian)” and “XSDL” on an old tablet, that are both Android apps available from Google Play, and which do not use ‘root’. There were numerous Linux-applications which would run, and many more that do not. I had also installed numerous Linux-packages that can collectively be referred to as “LaTeX” on that tablet, which actually just means by itself, command-line programs. Yet, even when typesetting using ‘LaTeX’, it’s often more fun to use a GUI. And the Linux-application “LyX” is such a GUI.

So, I have the hypothetical ability to do serious document-work on that tablet, even though the tablet is only using an emulated mouse, and “Hacker’s Keyboard”, and the mentioned emulated X-server.

What I recently did, was to get LyX to work properly:


Continue reading I now have LyX working properly, on my Linux tablet.

How to Add a Web-browser to GNURoot + XSDL.

In This earlier posting – out of several – I had explained, that I’ve installed the Android apps “GNURoot Debian” and “XSDL” to my old Samsung Galaxy Tab S (first generation). The purpose is, to install Linux software on that tablet, without requiring that I root it. This uses the Android variant of ‘chroot’, which is actually also called ‘proot’, and is quick and painless.

However, there are certain things which a ch-rooted Linux system cannot do. One of them is to start services to run in the background. Another is, to access hardware, as doing the latter would require access to the host’s ‘/dev’ folder, not the local, ch-root’s ‘/dev’ folder. Finally, because XSDL is acting as my X-server, when GNURoot’s guest-software tries to connect to one, there will be no hardware-acceleration, because this X-server is really just an Android app, and does not really correspond to a display device.

This last detail can be quite challenging, because in today’s world, even many Linux applications require, direct-rendering, and will not function properly, if left just to use X-server protocol, à la legacy-Unix. One such application is any serious Web-browser.

This does not result from any malfunction of either Android app, because it just follows from the logic, of what the apps are being asked to do.

But we’d like to have a Web-browser installed, and will find that “Firefox”, “Arora” etc., all fail over this issue. This initially leaves us in an untenable situation, because even if we were not to use our Linux guest-system for Web-browsing – because there is a ‘real’ Web-browser installed on the (Android) host-system – the happenstance can take place, by which a Web-document needs to be viewed anyway – let’s say, because we want to click on an HTML-file, that constitutes the online documentation for some Linux-application.

What can we do?

Continue reading How to Add a Web-browser to GNURoot + XSDL.

Why OpenShot will Not Run on my Linux Tablet

In This earlier posting, I had written, that although I had already deemed it improbable that the sort of Linux application will run on my Linux tablet, I would nevertheless try, and see if I could get such a thing to run. And as I wrote, I had considerable problems with ‘LiVES’, where, even if I had gotten the stuttering preview-playback under control, I could not have put LiVES into multi-tracking mode, thereby rendering the effort futile. I had also written that on my actual Linux laptop, LiVES just runs ~perfectly~.

And so a natural question which might come next would be, ‘Could OpenShot be made to run in that configuration?’ And the short answer is No.

‘OpenShot’, as well as ‘KDEnlive’, use a media library named ‘mlt’, but which is also referred to as ‘MeLT’, to perform their video compositing actions. I think that the main problem with my Linux tablet, when asked to run such applications, is that it is only a 32-bit quad-core, and an ARM CPU at that. The ARM CPUs are designed in such a way, that they are optimal when running Dalvik Bytecode, which I just learned has been succeeded by ART, through the interpreter and compiler that Android provides, and in certain cases, at running Codecs in native code, which are specialized. They do not have ‘MMX’ extensions etc., because they are RISC-Chips.

When we try to run CPU-intensive applications on an ARM CPU that have been compiled in native code, we suffer from an additional performance penalty.

The entire ‘mlt’ library is already famous, for requiring a high amount of CPU usage, in order to be versatile in applying effects to video time-lines. There have been stuttering issues, when trying to get it to run on ‘real Linux computers’, though not mine. My Linux laptop is a 64-bit quad-core, AMD-Family CPU, with many extensions. That CPU can handle what I throw at it.

What I also observe when trying to run OpenShot on my Linux tablet, is that if I right-click on an imported video-clip, and then left-click on Preview, the CPU usage is what it is, and I already get some mild stuttering / crackling of the audio. But if I then drag that clip onto a time-line, and ask the application to preview the time-line, the CPU usage is double what it would otherwise be, and I get severe playback-slowdown, as well as audio-stuttering.

In itself, this result ‘makes sense’, because even if we have not elected to put many effects into the time-line, the processing that takes place, when we preview it, is as it would be, if we had put an arbitrary number of effects. I.e., the processing is inherently slow, for the eventuality that we’d put many effects. So slow, that the application doesn’t run on a 32-bit, ARM-quad-core, when compiled in native code.

(Updated 10/09/2017 : )

Continue reading Why OpenShot will Not Run on my Linux Tablet

Getting Some Software To Run On My Linux Tablet, which Was Not Meant To Run

One of the computing adventures which I’ve been blogging about, is that I’ve been able to install a Linux Guest System, under the Android Host System, on my Samsung Galaxy Tab S, First-Generation tablet. I use the two Android apps, ‘GNURoot’ and ‘XSDL’, which can be obtained from Google Play, and which do not require root.

In this posting, I had as a message to my readers, that certain types of Linux applications are poor candidates for this sort of environment – a chroot-Linux-Shell, that connects externally to an X-server, which in turn seems to provide pure X-server protocol as well as a port, to connect PulseAudio clients to.

But in the same posting, I had named a specific Linux-application, which would solve each of the two purposes, and which in my opinion at the time, might have the best chances to run – assuming that any have a chance to run:

  1. ‘mhWaveEdit’
  2. LiVES

As some of my readers might expect, since that posting, I have nevertheless pressed ahead, and experimented with installing each of these Linux-applications, on the guest-system.

Long story short, I found that mhWaveEdit seems to work fine, and installed effortlessly, while LiVES does not.


One observation which I’ve made, is that the PulseAudio server built-in to the Android app ‘XSDL’, offers sound output, but not sound input. Hence, I cannot connect to the mike, which is built-in to the tablet. But this is a very minor issue, since I’ve exceeded typical usage-scenarios in what I’ve already been able to do.

Continue reading Getting Some Software To Run On My Linux Tablet, which Was Not Meant To Run