## A Tiny Little Error in the Post-Install, of the Debian / Stretch Package ‘xrdp’

One of the projects which I have just undertaken on the newly reactivated computer I name ‘Klexel’ was, to install an XRDP Server on it, so that I’ll be able to create remote sessions on it.

In case readers do not know, XRDP implements an analogue of the RDP protocol, but only acts as a go-between, that listens on another port, starts a VNC session, and then makes an internal connection to the VNC session, looping back to port ‘127.0.0.1:5900′ by default. And, if multiple clients of that sort are connected, the VNC ports continue with the numbering ‘5901…’ One big problem in trying to use VNC all by itself is, the need to have physical access to the machine, to start a new VNC session, to which multiple viewers may connect, including a person sitting in front of that machine. And another way in which XRDP can be used, is to connect to the X-Server / Xorg Session already running locally…

If the user wants to allow connecting to an existing, local X-Server session, then he needs to install the package ‘xorgxrdp’ from the repositories. What this will do is to install the X-Server modules that allow ‘connections from the side’ like that. Using this package requires a restart of the X-Server, once after installing it, while using Xrdp only for remote sessions, does not.

AFAIK, Connecting to an existing local X-Server session additionally requires that the package ‘x11vnc’ be installed, but I have not tested this.

The way I’ve chosen to use ‘xrdp’ for the moment is, with the additional package ‘tigervnc-standalone-server’, that is not automatically selected as a dependency.

I first tried to install the package ‘xrdp’ (meaning, the 32-bit version under Debian / Stretch) from the repository, only to find that there was a bug in the post-install script. It would generate an RSA Key-Pair, which is the correct thing to do, but it would then try to install that key-pair in the file:

/etc/xrdp/rsakeys.ini

The problem is, that this file is first set with wrong attributes. It belongs to user ‘xrdp’, to group ‘root’, and has permission-bits set, so that ‘xrdp’ can read and write, but ‘root’ cannot. This might be brilliant once the server is running, but because apt-get is only running as ‘root’, which does not yet belong to group ‘xrdp’, the post-installation hangs, not in generating the keys, but just in trying to write them to that file.

I’ve tried changing the attributes concurrently with the waiting script, as well as afterwards, re-attempting to configure the package. But the additional problem then becomes the fact that the post-install script deletes whatever file was already there, and then just recreates one with the incorrect attributes again.

I think a lot of other users would like it, if the package became installable on 32-bit systems.

What I did instead was, to custom-compile Xrdp, and to install my custom-compilation. It runs beautifully.

Dirk

## (Solved) How the Latest Wine-Staging Release, for Debian, Introduces a Packaging Problem: Unresolved Dependencies.

One piece of software which many Linux users benefit from is called “Wine”, which is an acronym that stands for ‘Wine Is Not an Emulator’ . This software allows some Windows programs to run under Linux, but has recently been made more powerful, to allow graphics-intensive games to run as well. The version of wine which I’ve been subscribing to is called ‘wine-staging’ , and contains the latest, bleeding-edge features that Wine is to contain, at any later point down the road.

But as I’ve been receiving updates to wine-staging, the latest update would have taken all my computers from version 4.0-rc2, to version 4.0-rc4, which means, ‘…Release Candidate 4′ . At that point, some of my computers could not install the update, because of unresolved package dependencies.

Apparently what’s been happening with Wine-Staging is twofold:

1. The original maintainers are no longer running the project, which also means that Wine is in the midst of a Code Freeze, and that present updates may offer fewer or no new features, from what Linux users are used to, and
2. In the interest of allowing the Windows games with the highest graphics requirements to run (potentially), the devs have nevertheless created a dependency of the latest Wine packages, on the OpenCL packages that install OpenCL natively under Linux.

‘OpenCL’ is a user-side API, which also requires system-side drivers for the specific graphics hardware, and which allows greatly parallel computations to be carried out on the GPU, instead of on the CPU. Apparently, some games use either ‘OpenCL’ or ‘CUDA’ these days, in order to incorporate complex Physics simulations into the game.

(I will assume that the version of CUDA which Wine emulates, requires OpenCL to be installed on the side of Linux.)

The problem under Debian which I’ve detected is, that the newly-introduced dependency of ‘wine-staging-amd64′ (as an example) is simply mainly:

‘ocl-icd-libopencl1′

Which means, that Wine will now insist on using the generic OpenCL drivers, that were developed for and by the Linux community, while not allowing the use of proprietary OpenCL drivers, that are closed-source, and that were developed by the manufacturers of each graphics card.

The problem with this is, that as users, we may only have one or the other OpenCL driver-set installed. We cannot install both the generic and the proprietary drivers. When we try to update Wine-Staging now, doing so will try to install the package above, which will also try to ‘kick out’ , any proprietary packages we may have installed, that provide OpenCL.

## Understanding the long long data-type with C++

One of the conventions which I was taught when first learning C++, was that, when declaring an integer variable, the designations were to be used, such as:


short int a = 0;  // A 16-bit integer
int b = 0;  // A 32-bit integer
long int c = 0;  // Another, 32-bit integer



But, since those ancient days, many developments have come to computers, that include 64-bit CPUs. And so the way the plain-looking declarations now work, is:


short int a = 0;  // A 16-bit integer
int b = 0;  // A 32-bit integer
long int c = 0;  // Usually, either a 32-bit or a 64-bit, depending on the CPU.
long long d = 0;  // Almost always, a 64-bit integer



The fact is not so surprising, that even on 32-bit CPUs, modern C++ runtimes will support 64-bit values partially, because support for longer fields, than the CPU registers, can be achieved, using subroutines that treat longer numbers similarly to how in Elementary School, we were taught to perform multiplication, long division, etc., except that where people were once taught how to perform these operations in Base-10 digits, the subroutine can break longer fields into 32-bit words.

In order to avoid any such confusion, the code is sometimes written in C or C++, like so:


uint16_t a = 0;
uint32_t b = 0;
uint64_t c = 0;



The ability to put these variables into the source-code does not pose as much of a problem, as the need which sometimes exists, to state literals, which can be assigned to these variables. Hence, a developer on a 64-bit machine might be tempted to put something like this:


uint64_t c = 1L << 32;



Which literally means, ‘Compute a constant expression, in which a variable of type (long) is left-shifted 32 bits.’ The problem here would be, that if compiled on a 32-bit platform, the literal ‘1L’ just stands for a 32-bit long integer, and usually, some type of compiler warning will ensue, about the fact that the constant expression is being left-shifted, beyond the size of the word in question, which means that the value ‘0’ would result.

If we are to write source-code that can be compiled equally-well on 32-bit and 64-bit machines, we really need to put:


uint64_t c = 1ULL << 32;



So that the literal ‘1ULL’ will start out, as having a compatible word-size. Hence, the following source-code will become plausible, in that at least it will always compile:

#include <cstdlib>
#include <iostream>

using std::cout;
using std::endl;

int main(int argc, char* argv[]) {

long int c = 1234567890UL;

if (sizeof(long int) > 7) {
c = (long int) 1234567890123456ULL;
}

cout << c << endl;

return 0;
}



The problem that needed to be mitigated, was not so much whether the CPU has 32-bit or 64-bit registers at run-time, but rather, that the source-code needs to compile either way.

Dirk

## Some Suggested Code

In This Earlier Posting, I had written at first some observations about Bluetooth-pairing, but then branched out on the subject, of whether a Diffie-Hellman Key Exchange could be easier to compute, if it was somehow simplified into using a 32-bit modulus. Obviously, my assumption was that a 64-bit by 32-bit divide instruction would be cheap on the CPU, while arbitrary-precision integer operations are relatively expensive, and actually cause some observable lag on CPUs which I’ve used.

And so, because I don’t only want to present theory in a form that some people may not be able to visualize, what I did next was to write a C++ program, that actually only uses C, that assumes the user only has a 32-bit CPU, and yet that performs a 64-bit by 64-bit division.

This has now been tested and verified.

One problem in writing this code is the fact that, depending on whether the divisor, which is formatted as a 64-bit field, contains an actual 64-bit, 32-bit, 24-bit, or 16-bit value, a different procedure needs to be selected, and even this fixed-precision format cannot assume that the bits are always positioned in the correct place.

I invite people to look at this sample-code:

http://dirkmittler.homeip.net/text/divide64.cpp

(Update 06/10/2018, 23h30 : )

I needed to correct mistakes which I made in the same piece of code. However, I presently know the code to be correct.

Just to test my premises, I’m going to assume that the following division is to be carried out, erroneously as a simple division, but assuming a word-size of 32 bits: