Installing Visual Studio Code under Linux.

Linux users have often been avid followers, but left thirsting for some ability to run the proprietary applications, that Windows and Mac users have had access to since the beginning of Computing for the Masses. In fact, the narrow supply of Open-Source Applications for various Linux distributions has been aggravated by the fact that many Linux distributions exist, and when one follows the subject to its smallest detail, one finds that every Linux computer evolves into a slightly different version of Linux, because they can all be configured slightly differently, which means that some users will configure their Linux boxes in their own, personalized way. Actually, this is not a very good thing to do, unless you really know what you’re doing. But the mere fact that many, professionally configured Linux distributions exist, has also meant that packages destined for one distribution would either not install on another, or that packages which were not meant to be installed on a given distribution, could actually break it, if the user supplied his ‘root’ privileges, to so-install the package anyhow.

At the same time, the total amount of programming time available to open-source development has always been scarce, which means for the sake of this blog posting, that programming hours ended up divided between different Linux distributions. (:2)

In recent Linux distributions, there have been two main mechanisms developed over the years, to reduce the severity of this problem. In fact, since Debian 9 / Stretch, both these solutions have been available:

  • Flatpaks,
  • Snaps.

For the moment, I’m going to ignore that Flatpaks exist, as a very viable way to install software, just because Flatpaks had as their main purpose, to install purely Linux software, but on a wider variety of Linux distributions. So, why do both ‘Flatpak’ and ‘Snap’ exist? I suppose that one reason they both exist is the fact that each was invented, and that in principle, both work. But another reason why these two vehicles exist is, the fact that ‘Snaps’ are really disk images, which get mounted as loopback devices, and that therefore, ‘Snaps’ can install software which is binary in nature and therefore, not open-source, yet, install such software on a Linux computer, where the emphasis has traditionally been on open-source software. (:3)

Both mechanisms for installing software have a limited interface, of which features on the host computer the guest application is meant to have access to, since, if both methods of installing software were completely unrestricted, Linux users would lose the security which they initially gained, through their choice of Linux. I think that the way it is, ‘Snaps’ tend to have more-severe security restrictions than ‘Flatpaks’ do, and this is also how it should be.

What all of this inspired in Linux users, was the hope that eventually, they would also start to be able to install certain proprietary applications. And, the main goal of this posting is to assess, to what extent that hope seems to have been materializing. And I’m just going to ignore the fact for the moment, that some ‘Snaps’ are really just Linux applications, which their programmers compiled to the additional target, that being a ‘Snap’, and that for this reason, some Snaps just don’t work, usually because their programmers did not take into consideration that on an eventual host computer, each Snap only has access to the Interfaces which the security model allows, even though, when residing on Linux computers natively, the same application ‘just works fine’. For the sake of argument, software developers might exist, who are professional enough in what they do, to compile Snaps as Snaps, which in turn do work as intended.

An idea which could make some Linux users uneasy would be, that the supply of proprietary software available as Snaps, may not have grown as much as hoped, and that Linux users could be looking at a bleak future. Well, in order to get a full idea of how many Snaps are presently available, user can just visit ‘the Snap store’, and browse to see what it has to offer. And this would be the URL:

What most Computer Users would seem to notice is the fact, that there is not a huge abundance of software, at least, according to my tastes, and at the time I’m writing this. Also, users do not need to pay for anything at this so-called Snap store. However, I have at least one Snap installed, of which I know, that if I activated that, I’d need to make a one-time payment to its developers, before it would actually function as one user-license.

What I’d just like to explore for the moment is the possibility that a User might want to program and compile code he wrote himself, in his favourite language, such as, in C / C++, or in C#, and that additionally, said user might prefer “Visual Studio Code” as his Editor, as well as his IDE. In reality, Linux users do not depend very strongly on the ability to use ‘VSCode’, as it’s also called, because under Linux, we actually have numerous IDEs to choose between. But let’s say I wanted to write code in these 2(3) languages, and, to use ‘VSCode’ to do so…

(Updated 5/04/2020, 17h50… )

Continue reading Installing Visual Studio Code under Linux.

Trying to bridge the gap to mobile-friendly reading of typeset equations, using EPUB3?

One of the sad facts about this blog is, that it’s not very mobile-friendly. The actual WordPress Theme that I use is very mobile-friendly, but I have the habit of inserting links into postings, that open typeset Math, in the form of PDF Files. And the real problem with those PDF Files is, the fact that when people try to view them on, say, smart-phones, the Letter-Sized page format forces them to pinch-zoom the document, and then to drag it around on their phone, not getting a good view of the overall document.

And so eventually I’m going to have to look for a better solution. One solution that works, is just to output a garbled PDF-File. But something better is in order.

A solution that works in principle, is to export my LaTeX -typeset Math to EPUB3-format, with MathML. But, the other EPUB and/or MOBI formats just don’t work. But the main downside after all that work for me is, the fact that although there are many ebook-readers for Android, there are only very few that can do everything which EPUB3 is supposed to be able to do, including MathML. Instead, the format is better-suited for distributing prose.

One ebook-reader that does support EPUB3 fully, is called “Infinity Reader“. But if I did publish my Math using EPUB3 format, then I’d be doing the uncomfortable deed, of practically requiring that my readers install this ebook-reader on their smart-phones, for which they’d next need to pay a small in-app purchase, just to get rid of the ads. I’d be betraying all those people who, like me, prefer open-source software. For many years, some version of ‘FBReader’ has remained sufficient for most users.

Thus, if readers get to read This Typeset Math, just because they installed that one ebook-reader, then the experience could end up becoming very disappointing for them. And, I don’t get any kick-back from ImeonSoft, for having encouraged this.

I suppose that this cloud has a silver lining. There does exist a Desktop-based / Laptop-based ebook-reader, which is capable of displaying all these EPUB3 ebooks, and which is as free as one could wish for: The Calibre Ebook Manager. When users install this either under Linux or under Windows, they will also be able to view the sample document I created and linked to above.

(Updated 1/6/2019, 6h00 … )

Continue reading Trying to bridge the gap to mobile-friendly reading of typeset equations, using EPUB3?

How NOT to control our Gaming Keyboards, from a Linux computer.

One of the commodities which serious computer enthusiasts might want to buy, is a gaming keyboard. One reason may be the fact that by coincidence, gaming keyboards tend to be sound mechanical keyboards as well, which have per-key switches, which in turn have the desired tactile response, which bubble-keyboards today often lack.

But then, one of the features which gaming keyboards may add, is the ability to store and play back macros when in gaming-mode, those macros being key-sequences which a player needs to enter repeatedly, but tires of typing each time.

Another feature gaming keyboards can have, is fancy LED back-lights, which can even be customized to highlight different groups of keys, depending on how those groups of keys are important to certain uses of the KB. ( :1 )

I just bought the “ThermalTake eSports Poseidon Z RGB”, with Blue Key-Switches. The blue key-switches are switches that not only give good tactile feedback, but also make a distinct, high-pitched clicking sound, at exactly the right instant, during a key-press.

They have mechanical hysteresis.

One less-optimistic side-effect for this, under Linux, is the fact that some of the customization of this KB requires that proprietary software be used, of which there only exists the Windows version. The main functioning of the KB will work under Linux (Debian / Stretch), but if we want to program the layout-coloring / highlighting, then we need to use the proprietary software. These layouts can then be stored in 1 out of 5 Profiles, on the KB itself, which has its own 32-bit embedded micro-controller (i.e., this KB has its own CPU).

I tried to find out, whether I could install the software under a specific Wine folder, and then create symlinks to various device-files that exist natively under Linux, so that those device-files will appear as generic, DOS-type serial ports. Since Wine, by default, does not have direct access to the host machine’s USB-connected hardware.

The result was, that I bricked the keyboard. I needed some support from the retailer who sold me the keyboard, to recover a fully-functional instance.

The sum total of what this means, is that I can use this KB under Linux. I must just store its customizations using an old Windows laptop I have – a dual-boot ‘Acer Aspire 5020′ – after which I can disconnect the KB from that laptop, and connect it to my main (Linux) desktop again.

(Edit 04/05/2018 : )


(One problem with trying to photograph this keyboard with a simple phone-cam is, the fact that the LEDs produce light with high intensity. This light tends to saturate the light-sensor in a conventional camera-phone, which in turn results in a reduction, to the recorded color saturation. I.e., when the BG light-level is normalized by a camera-phone, the brightest primary colors are off-the-scale, but limited to scale as encoded.

Therefore, Blues will seem to look similar to Greens, and Yellows look similar to Whites.

When seen with the naked eye, all these colors look very deep. )


Continue reading How NOT to control our Gaming Keyboards, from a Linux computer.