Disabling upowerd on a Desktop Linux computer that never actually had a battery.

One of the facts which I’d like to make sure the reader knows, is what, exactly, the process ‘upowerd’ is responsible for on any Linux computer, lest the reader disable something that he or she may really need.

Many computers, including laptops, have batteries. ‘upowerd’ is the Linux process that monitors the battery, or the batteries, in case there is more than one to monitor. If the computer has batteries to monitor, then this process is essential and should not be disabled. But, in certain specific other cases, this process can become a problem, as it recently was on my desktop computer named ‘Phosphene’, which is running Debian 9 / Stretch, which has Plasma 5.8 as its desktop manager, and which will only ever run on A/C power, due to the very way in which its hardware is designed.

Several months ago, I noticed that the ‘North Bridge’ of this computer – an essential chip on its motherboard – was becoming rather hot. And the motherboard in question, the ‘Sabertooth X58′, manufactured in the year 2011, was already famous for the design flaw that causes its North Bridge to become 76.5⁰C hot when idle, which is actually hotter than the GPU on that computer will normally become, when pressed to work hard. Several Months ago, the North Bridge temperature when idle was 80⁰C or even 81⁰C! Whether it’s actually safe for a chip to be that hot is a subject open to opinion. This temperature will not cause an immediate failure, but if the chip is so hot continuously, then its lifespan will become shorter, than what the lifespan of chips is supposed to be, in general.

Therefore, months ago, when I first noticed this, I opened up the tower / desktop computer and examined it, to look for failed cooling fans, etc. There was no such cause for the elevated NB temperature. Not being able to remedy the problem, I just left it that way.

But only yesterday, I noticed that the process ‘upowerd’ was consuming an inordinate amount of CPU time. On the octa-core machine, that process was consuming maybe 1% of available CPU time, which was quite a lot, considering that there should have been nothing for it to do. And, never having noticed this before, it seemed possible to me that ‘upowerd’ may have been consuming 1% of available CPU time (unnoticed), since months ago.

When ‘upowerd’ misbehaves in this way, sometimes this happens, because of hardware signals, such as perhaps, a battery which continuously disconnects and reconnects, etc… Therefore, before a software kludge is attempted, all possibilities need to be followed, to find hardware causes for this behaviour, to which ‘upowerd’ would simply be responding in a normal fashion. Yet, even given hardware reasons to be active, ‘upowerd’ should not be consuming much more than 1% of available CPU time, in case the reader has some situation where this process is consuming, say, 10% of the CPU.

Observations, on how to insert Unicode and Emojis into text, using a KDE 4 / Plasma 5.8 -based Linux computer.

One of the earliest ‘inventions’ on the Internet, were ‘Smilies’, which were just typed in to emails, and which, when viewed as text, evoked the perception of whichever face they represented. But, graphical user interfaces – GUIs – replaced simple text even in the 1990s, and the first, natural thing which developers coded-in to email clients was, the ability to convert typed, text-based smilies, into actual images, flowed with the text. Also, simple colon-parenthesis sequences were replaced with other, more varied sequences, which could be converted by some email clients into fancier images, than simply, smiling faces.

Actually, the evolution of the early Internet was slightly more complex than that, and I have even forgotten some of the real terms that were used to describe that History.

But there is an even more recent shift in the language of the Internet, which creates a distinction between Smilies, and ‘Emojis’. In this context, even many ‘Emoticons’ were really just smilies. Emojis distinguish themselves, in that these pictograms are represented as part of text in the form of Unicode values, of which there is such a large supply, that some Unicode values represent these pictograms, instead of always representing characters of the Earth’s many languages, including Chinese, Korean, Cyrillic, etc. What some readers might ask next could be, ‘Traditionally, text was encoded as 7-bit or 8-bit ASCII, how can 16-bit or 32-bit Unicode characters simply be inserted into that?’ And the short answer is, through either UTF-8 or UTF-16 Encoding. Hence, in a body of text that mainly consists of 8-bit codes, half of which are not normally used, sequences of bytes can be encoded, which can be recognized as special, because their 8-bit values do not correspond to valid ASCII characters, and their sequences complete a Unicode character.

One fact which is good to know about these Emojis is, that they are often proprietary, which means that they are often either the intellectual property of an IT company, or part of an Open-Source project. But the actual aspect of that which can be proprietary is, the way in which Unicode values are rendered to images.

What that means is that, for example, I can put the following code into my blog: 🤐 . That is also referred to as Unicode character ‘U+1F910′. Its length extends beyond 16 bits by 1 bit, and the next 4, most-significant bits are all 1’s, as expressed by the hexadecimal digit ‘F’. It’s supposed to be a pictogram of a deceased entity, as if that were stated correctly by a head which has had certain features crossed out. But for my blog, the use of such a code can be a hazard, because it will not display equally on Android devices, as it displays on iOS devices. And, on certain Linux computers, it might not be rendered at all, instead just resulting in a famous rectangle that seems to have dots or numbers inside it. This latter result will form, when the client-program could not find the correct Font, to convert this code into an image. (:3)

Those fonts are what’s proprietary. And, they also provide some consistency in style, between Android devices, OR between iOS devices, OR between Windows devices, etc.

Well, I began this posting by musing about the early days of the Internet. During those days, some users – myself included 😊  – did some things which were truly foolish, and which included, to put background images into our HTML-composed emails, and, to decorate documents with (8-bit) dingbat fonts, just because it was fun to pass certain fancier documents around, than POT. I don’t think there is really anything wrong with potential readers, who still put background images into their emails. What I mean is that many of my contacts today, prefer emails which are not even HTML.

This earlier practice, of using dingbat fonts etc., tended to play favourably into the hands of the tech giants, because the resulting documents could only be viewed by certain applications. And so today, I needed to ask myself the question, of how often the use of Emojis can actually result in a document, which the recipient cannot read. And my conclusion is that today, such an indecipherable outcome is actually rare. So, how I would put a long story short is to say, that Commercialism is back, riding on the desire of younger people to put more-interesting content into their messages, and perhaps, without some of the younger people being aware that when they put Emojis, they are including themselves as the software-disciples of one larger group or another. But that larger group mainly seems to be drawing its profits, from the ability of certain software to insert the images, rather than, the ability of only certain software to render them at the receiving end (at all). Everybody knows that, even though the input methods on our smart-phones don’t lead to massively good prose, they almost always offer a rich supply of Smilies, plus Emojis, all displayed to the sender using his or her own font, but later displayed to the recipient, using a potentially different font.

The way Linux computers can be given such fonts, is through the installation of packages such as ‘fonts-symbola’ and ‘ttf-ancient-fonts’, or of ‘fonts-noto‘… The main drawback of the open-source ‘Symbola’ font, for example, is simply, that it often gives a more boring depiction of the same Unicode character, than the depiction which the true Colour Noto Font from Google would give.

One interesting way in which Linux users are already in on the party is, in the fact that actual Web-browsers are usually set to download fonts as they are needed, even under Linux, for the display of Web-pages. Yet, email clients do not fall into that category of applications, and whether they render Emojis depends on whether these font packages are installed.

Hence, if the ability to send Emojis from a Linux computer is where it’s at, then this is going to be the subject of the rest of my posting. I can put two and two together, you know…

(Updated 7/31/2020, 15h10… )

A 3rd-party, Android email client, still worth using: FairEmail.

One of the observations which I’ve made about the Android platform is, that many of the 3rd-party email apps that once used to run well, no longer do so under Android 10, and that, additionally, their devs have often abandoned them.

For that reason, I’m happy to find that such an app still exists, or newly exists, and its name is FairEmail. This is an app, the free version of which can actually be used in the long term, but which I paid for, just to get the extra features.

One of the observations which I can make about this app is, that it has a plethora of settings, some of which I haven’t learned the meaning of yet. But, by default, the way to use it is to follow what is located in its first settings tab, which displays wizards to set up email accounts according to a database of recognized providers, and then, to leave the settings at their defaults. Additional wizards help the user give the app special settings under Android. The app directs the user to the required or optional settings, but it’s up to the user actually ‘to throw the switch’ each time.

Multiple email accounts can all be set up, using the same wizard.

The app runs in phone-optimized as well as tablet-optimized formats.

One of the features that were highly important to me was, support for both ‘S/MIME’ and ‘OpenPGP’. When using OpenGPG, this app will always encode it using the trendy ‘PGP/MIME’ format, and no longer, using ‘Clearsigning’, which was also referred to as ‘Inline Format’. The use of OpenPGP requires that an additional key-management app be installed, and on my devices, Open Keychain was already so, and was recognized immediately by FairEmail.

The app displays many widgets inside displayed emails, most of which give explicit commands to do things, that might impact the privacy of the user, such as, to display images, to display tracking images, etc. The app tries to distinguish between these two types of images because additionally, being an IMAP Client, downloading even plain images will consume additional data, when many emails can Humanly be understood, without the need actually to see the images. This is especially true for actual Spam.

The app leaves Spam filtering up to the IMAP Server, but displays the Spam Folder as fully accessible.

And many configuration details show me, that it assumes trendy preferences, even though I can’t say that either I, or most of my email contacts, qualify as trendy Internet users. One trendy feature is that this app mainly supports IMAP, and that any support of POP3 which the user may find, will be incomplete at best.

Another trendy setting in this app has to do with “Flowed Text”. This is a term which refers to ‘Pure Text Emails’, in which one paragraph is essentially written on one line. Traditionally, this lack of formatting was reserved for HTML-composed emails, and the receiving email client would always display those flowed. By contrast, traditionally, Pure Text had fixed line-lengths, determined by the sender, and the receiving client would break lines where line-breaks were sent, even if doing so, or not doing so, tended to wreck the appearance of the email…

(Updated 7/24/2020, 18h20… )

A LISP function that expands macros fully: macroexpand-all .

This posting will assume that the reader is sufficiently familiar with LISP, to understand how its macros generally work. What such readers will often want to do, is to be able to expand macros, mainly for debugging purposes, before they get compiled into a function. This is because of the fact that, with many LISP implementations, functions are generally compiled in such a way, given actual LISP that acted as source code, and which the macro partially built, that the functions cannot be decompiled, nor the original LISP code recovered from them.

What Common LISP offers, are the functions ‘MACROEXPAND’ and ‘MACROEXPAND-1′, the first of which depends on the second. But, As the Common LISP Hyperspec already points out, ‘MACROEXPAND’ will only keep calling ‘MACROEXPAND-1′, until the second output from this subservient function returns as Nil. This will happen, when the argument is no longer a Macro Form. But, as is already mentioned, this second value output by the subservient function will return as Nil, even if the LISP expression still contains Macro Sub-Forms. And the reason this behaviour can be problematic is the fact that most LISP compilers will keep expanding the Macro Sub-Forms as well, when a macro has been put into a function. This is actually, what makes recursive macros fully possible.

And so, as a better debugging tool, what some LISP programmers might need, is a function that expands all the Macro Sub-Forms as well (even before the macro has been used in a function definition). The following LISP Function accomplishes this:


(defun macroexpand-lists (input)
(cond ((null (listp input)) input)
((null input) NIL)
((listp (car input)) (cons (macroexpand-all (car input))
(macroexpand-lists (cdr input)) ) )
(T (cons (car input) (macroexpand-lists (cdr input)) ) ) ) )

(defun macroexpand-all (input)
(cond ((null (listp input)) input)
((null input) NIL)
(T
(let ((expansion1 (macroexpand input)))
(cond ((null (listp expansion1)) expansion1)
((eq (car expansion1) 'cl:function) expansion1)
((listp (car expansion1))
(macroexpand-lists expansion1) )
(T (cons (car expansion1)
(macroexpand-lists (cdr expansion1)) ) ) ) ) ) ) )



Now, I suppose that what the reader may want to see next could be, how this function of mine performs, if I feed it a LISP Macro, Which I defined in an earlier posting. And the following snip illustrates this. The following snip assumes that the Macro, its subservient Function, and the Macro-Expansion Function were already loaded into a LISP session, as that session was started…

(Updated 7/20/2020, 15h05,,, )