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:
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… )
(As of 5/02/2020 : )
Under Debian 9 / Stretch, installing ‘Snap’ is relatively straightforward. As ‘root’, we give the commands:
# apt-get update # apt-get install snapd
Yet, even though some sources might suggest, that just to get Snap itself installed is so simple, in reality, what happens in the background of the user’s Linux computer is not. Not only does the Snap daemon need to be set up, but, when not working in text mode, the user’s environment needs to be able to find the PATH at which snaps can be executed, and must also display those newly-installed entries in the Launcher, to be launched with a single click.
What I’ve actually done was, to add the following entry to the file which is also known as ‘~/.bashrc':
For most purposes, this was an unnecessary thing for me to do. All it really does is, to allow me to run Snaps from the command-line, and whenever I’ve controlled my Snap installation as root, I’ve gotten the warning, that ‘/snap/bin’ was not found in my path. The reason I get this warning is the fact that the user ‘root’ has his own ‘.bashrc’, which I’ve never edited.
But the following is an absolute MUST:
- Either reboot the computer after installing ‘snapd’, or log out the user and log him or her back in.
On some computers, actually doing a reboot may actually be the simpler of the two options. But one of these actions must be taken, so that entries will appear in the Launcher, for whichever Snap we later decide to install.
Under Debian 9, the act of actually installing snaps and managing them, must still be carried out from the command-line. I suppose that ‘Ubuntu’ is one-up on us, in that Ubuntu’s Software Centre gives the user graphical controls, to manage his Snaps as well. And yet, I’ve always been able to manage the few Snaps I installed, as ‘root’, from the command-line.
And now, to the subject of focus of this posting: To install ‘Visual Studio Code’. (As ‘root’…)
# snap install code --classic
Note: An important detail which must not be forgotten, for this Snap, is the command-line option ‘–classic’. The reason this is important is the possibility that without it, the system could end up installing the Snap in question with ‘strict’ security, whereas, with ‘Visual Studio Code’, we explicitly wish to install it with the more-relaxed ‘classic’ security model. Why? Because of my hunch, that this IDE relies on back-ends, actually to compile software, and not just to act as a text editor, and must therefore have access to the required back-ends, belonging to the Host Computer. Without more-relaxed access to the host computer’s resources, the complex task of compiling code, would just not seem possible.
But then, because I already had ‘snapd’ itself set up, before my most-recent reboot, installing ‘VSCode’ did not require any more reboots, and I was able to perform two experiments with it. One experiment was, to install the C/C++ extension:
And the next experiment was, to install the C# extension:
Just by looking at the details of how C++ is installed, I see that there are 4 downloaded packages. Those should allow the IDE actually to compile code. But I claim to know that they depend to some extent on the Host computer, because they only took a few seconds to download. If VSCode needed to run in a ‘strict’ security context, then I’d also expect, that it should take minutes and not seconds, for the 4 packages to download, that eventually allow C/C++ source-code to be compiled for any given target.
There’s more of a comment to be made, on how the ability to install the C# compiler eventually proceeded. It also took only a few seconds, and, when it was complete, I essentially obtained the error message, that ‘.NET Core’ could not be downloaded. When clicking on the provided link, doing so opens a Web-browser window, which somehow invites the user to install .NET to his computer, in this case meaning, on his Host Computer.
(Update 5/02/2020, 19h50 : )
Interestingly, this is a known issue, which is partially explained At This Link. However, in order to apply the suggested solution, I needed to run three commands as ‘root’ and not one:
# snap install dotnet-sdk --classic # snap alias dotnet-sdk.dotnet dotnet # ln -s /snap/dotnet-sdk/current/dotnet /usr/local/bin/dotnet
This installs ‘dotnet’ as a separate Snap – not from within the previous GUI – and then, makes the executable within this Snap visible to all other Snaps, including ‘VSCode’. The result for me is, that the ‘VSCode’ GUI still displays the C# extension as half-installed, but an error message which I used to obtain, stops appearing, even though I did not disable said error message. (:4)
(End of Update 5/02/2020, 19h50.)
In a different vein, I have to expect that, the way it’s set up right now, ‘VSCode’ on my computer can compile programs in C and/or C++, but not, using ‘Microsoft Foundation Classes’, and again, I have not explored whether I could purchase that from Microsoft, for use within ‘VSCode’, running as a Snap. (:1)
What I have confirmed is, that the editor and IDE seem to run, with as many restrictions as I expected. And, the C# extension seems to ignore the fact completely, that I already had ‘Mono’ installed on the host computer.
(Update 5/02/2020, 21h50 : )
What some simple trials with ‘VSCode’, running as a Snap and under Linux reveals is, that beyond not supplying any libraries, this package fails to supply any header files. And the way I determined this was, to test a simple ‘MFC’ project which I had created several decades ago, back in the days when I was still using Windows, and to see how far I’d get in trying to recompile it.
Typically, under Windows, in order to set up an ‘MFC’ C++ Project, the header file ‘StdAfx.h’ is included. In certain cases, only a subset of what it in turn would include, is actually included. Well, when I specify this header file, the IDE, quite correctly, points out that it cannot be found. And, it also cannot be found anywhere within the mount-point of the Snap, which only includes whatever libraries it needs, in order to run under Linux.
Therefore, ‘VSCode’ quickly guides me to the correct entry in the correct .JSON File, where I can specify whatever include path I want. I can set that to my Linux-based include directory “/usr/include/**”, and Save that. After having done so, I can ‘#include <stdio.h>’, and doing so generates no squiggly line, which would otherwise tell me I had done something wrong. Yet, ‘#include <StdAfx.h>’ will generate a squiggly line if uncommented. And either way, none of the classes etc., that would be defined within it, are recognized as defined or declared.
It would make sense if a similar set of constraints applies to libraries.
Thus, when run under Linux, ‘VSCode’ is a very fancy text editor, as well as a compiler, but not a full-featured software development platform, beyond the libraries and header files that the user can supply.
When Microsoft refers to their “Windows Subsystem for Linux”, which is also known as ‘WSL’, what they are referring to is a Linux Virtual Machine that can be installed under Windows, so that, from Windows, Linux applications can be developed.
(5/02/2020, 22h15 : )
Just to avoid confusing readers. If the header files specified are in angle-brackets, which means that they are system-wide or system-installed, as opposed to being project-specific, even when using ‘VSCode’, there is really no need to specify their system-wide directory. The compiler is ‘smart enough’ to know where to find that.
I just added it above for the sake of illustration, and also, as a result of my own searching, for the possibilities of finding other include directories (which I didn’t find). If I were to keep this special setting, I’d next be able to specify:
And that would constitute an error, precisely because ‘stdio.h’ is system-installed.
(5/02/2020, 22h55 : )
The use of ‘VSCode’ can greatly be simplified, by right-clicking anywhere in the editing panel, and then left-clicking on ‘Command Palette…’ . Out of the drop-down list, the entry “C/C++: Edit Configurations (UI)” can be chosen. And what the user will next see is, that if he simply deselects ‘clang-<whichever version>’, and selects ‘g++’ from the drop-down list, not only does the strange behaviour of the IDE normalize, but the fact becomes obvious from this view, that the actual compilers built-in to his Linux system are still doing the compiling. I don’t really know why this IDE prefers the ‘clang’ compiler, but, once I learned to find my way around the IDE, I was quickly able to correct the situation. The following example compiled without a hitch:
The reasons it did were:
- The fact that I controlled exactly what I wanted the compiler to do,
- The fact that I already knew this is an example of working code.
Hence, the compiling did not provide any surprises. For me, learning to use this IDE was just a bit of a learning curve.
(Update 5/03/2020, 7h35 : )
Actually, it’s not 100% correct to say, that the programming hours are divided exclusively between Linux distributions. I was oversimplifying.
It can easily happen that a single programmer writes an application and posts its source code on GitHub. After that, a package maintainer already working for Debian could see the application, and decide to adapt it to Debian, alongside the many other applications he has included in whichever Debian repository. The work has not been duplicated, as the maintainer is not doing what was necessary to write the original application. He’s just compiling it with such a set of parameters, that the resulting binaries will be linked to the existing libraries belonging to the Debian Branch in question, and he would also be listing what all its dependencies are, so that he can include them as meta-data in one or more packages…
Thus, 2x the original amount of work is not truly being done.
Under Debian 9 / Stretch, the actual location of the disk images is:
And, their mount-point is:
Within this second directory, there is a file named:
Which points out that the folder in question uses minimal storage, because it’s a mount-point, and not any directory into which Snaps might have been unpacked.
(Update 5/03/2020, 8h25 : )
I think that the real accomplishment which has taken place in this exercise was, that the .NET SDK was installed as a separate Snap, that can in turn actually be used to compile and test applications written in C#, and that it’s not ‘Mono’ (the debranded version of C#). The following is the state of ‘dotnet’ as presently installed:
dirk@Phosphene:~$ dotnet --info .NET Core SDK (reflecting any global.json): Version: 3.1.201 Commit: b1768b4ae7 Runtime Environment: OS Name: debian OS Version: 9 OS Platform: Linux RID: debian.9-x64 Base Path: /snap/dotnet-sdk/69/sdk/3.1.201/ Host (useful for support): Version: 3.1.3 Commit: 4a9f85e9f8 .NET Core SDKs installed: 3.1.201 [/snap/dotnet-sdk/69/sdk] .NET Core runtimes installed: Microsoft.AspNetCore.App 3.1.3 [/snap/dotnet-sdk/69/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.3 [/snap/dotnet-sdk/69/shared/Microsoft.NETCore.App] To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download dirk@Phosphene:~$
It’s a shame that I just don’t know C#.
(Update 5/03/2020, 10h30 : )
Obviously this exercise can be extended, to enable one of the Python extensions. Two are readily available:
The first alternative shown above is actually offered by Microsoft, while the second is offered by a developer named “Thomas Haaken Townsend”. Because doing so is more conform to the spirit of this blog posting, I have chosen to install the Microsoft extension, which is documented elsewhere not to work on macOS, but documented elsewhere to work with Linux. Either way, it assumes that the Python 3 interpreter is to be used, that is already installed on the Host Computer.
When this extension is first installed, it immediately tries to build a Wheel, that being its own Linter. Therefore, ‘python3-wheel’ should be installed from the package manager, on Debian Linux systems, before this ‘VSCode’ extension is installed. Also, since Python 3.4 is deprecated, attempting to use this ‘VSCode’ extension with Python 3.4 will cause predictable error messages, since ‘pip3′ will no longer install anything with Python 3.4 .
As it happened, I did not have ‘python3-wheel’ installed, for which reason that latter step of the installation failed. Then, I went to my package manager and installed ‘python3-wheel’. Because ‘VSCode’ does not reattempt to build this wheel automatically, my next test was, to recover from this misstep, such that the extension is fully installed. After installing the Linux package in question, I restarted ‘VSCode’, opened a Python 3 script to debug, right-clicked on the editing panel, left-clicked on the resulting context menu entry ‘Command Palette…’, and, from the drop-down list, selected ‘Python: Select Linter’. Here, it would have missed the point of the exercise had I chosen anything other than ‘flake8′. And fortunately, doing so reconfirmed that this Linter was not yet installed, with a message box where I was able to click, to install it.
At that point, the second attempt to build the Wheel succeeded, and ‘flake8′ became my Python 3 syntax checker.
I found that this syntax checker was much more strict, than the one built-in to ‘Eric’, which might be the default Python IDE to use under Linux. Yet, I was able to satisfy all the demands which ‘flake8′ made, and then to Debug my Python program, to find it still works:
The ‘VSCode’, Microsoft Python Extension has more features, some of which have to do with ‘Jupyter’,
and which I did not test. I would expect that if the reader of this blog was to test these features, unless all the required Jupyter packages are already installed from the package manager, ‘VSCode’ will try to install those using ‘pip3′ and ‘Wheel’ again. Some users may be picky about only installing Python packages in this way, if those packages are not available directly from the package manager.
(Update 5/04/2020, 17h50 : )
I have now tested any ability the Microsoft, ‘VSCode’, Python Extension has to open and run Jupyter Notebooks. Apparently, this depends on having a sufficiently powerful version of Jupyter installed, to the same Python interpreter.
The version of Jupyter which I have installed, is only ‘4.2.1’, and comes from the package manager which ‘Debian 9 / Stretch’ offers. If the reader has a ‘Debian 10 / Buster’ -based Linux computer, then he would also be able to install a much more up-to-date version of Jupyter on it, which ‘VSCode’ will presumably be compatible with.
When it comes to installing Python packages, Linux users really have three main routes to follow:
- They can install packages from their distribution’s package repositories,
- They can use either the ‘pip’ or the ‘pip3′ command, to install packages into their user-space, or, even into the system files on their computers, if they can apply ‘root’ privileges,
- There even exists A script which users can download, that would install “Anaconda” to Linux computers, which in turn specifically provides Jupyter.
The Individual License for Anaconda is Free, but expensive alternative licenses for this server also exist, from the same site as above.
My personal issue with this last option is twofold:
- I already have a system for starting Jupyter, installed from my package manager, which runs a ‘SageMath’ kernel (very successfully), in addition to a ‘Python 2′ and a ‘Python 3′ kernel. I would not think it right, to install two servers on the same computer, which would essentially provide the same thing – even by what they are named in code,
- If another user chooses to install Anaconda as described, then there will be zero isolation, between that server and the user’s Linux computer. And this ventures beyond my own comfort zone.
But I actually pursued this subject intensely today, of wanting to open ‘Jupyter’ Notebooks from within ‘VSCode’. Apparently, VSCode does not discriminate against one build of Jupyter or another. It’s just that my approach, of only installing Python packages from the Debian repositories, has left me with a version of Jupyter that does what it was originally designed to do in a very stable way, but that lacks certain features, which VSCode just expects whichever Jupyter version to have, to be able to open their Notebooks.
And what my ‘Jupyter’ version has always done well from day one was, to open ‘SageMath’ Notebooks from within a generic Web-browser, with no apparent deficit in functionality. I don’t really understand what added functionality it should bring, to be able to open them via ‘VSCode’.
‘VSCode’ never promised in any specific way, to be able to open ‘Jupyter’ Notebooks that belong to the ‘SageMath’ kernel, only, to the Python 3 kernel. Yet, assuming that a connection is established to the Jupyter server, VSCode also allows the user to select between the kernels that that server offers. One aspect of this which I haven’t explored in my own Computing History was, ‘Python 3 Jupyter Notebooks’, as opposed to ‘SageMath Jupyter Notebooks’. But apparently, even to be able to run ‘IPython’ from within such a context can be interesting, because sometimes, what the user needs is a numerical toolbox, as well as certain plotting and visualization capabilities, while I have usually sought the various Computer Algebra Systems, including SageMath.
Now, If I were to persist in connecting a version of ‘VSCode’, only 2 weeks old, to ‘Jupyter v4.2.1′ Notebooks, then what I could do, is specifically to install “Don Jayamanne’s” Jupyter Extension to VSCode. But doing so would actually be the reverse of what we’re supposed to do, which is to use the Microsoft Python Extension’s built-in support for Jupyter. But what Don Jayamanne specifically tried to do was, to enable backwards-compatibility with older Jupyter versions (like mine).
Because the emphasis of my posting is to keep the software, installed to Linux, but via a Snap, as authentic as possible, this posting will not go on about that avenue of pursuit.