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:

https://snapcraft.io/

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.

I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )

Continue reading I’ve just custom-compiled ‘Aqsis’.

Atomic Game Engine Installed – twice

One of the projects which I have recently undertaken, is to compile and install Atomic Game Engine, both on my Linux laptop ‘Klystron’, and on my Windows 7 machine ‘Mithral’. This was originally a closed platform, but has received renewed interest, because it is now available under the MIT license, which is a form of Open-Source licensing, more permissive than GPL v3 is.

This platform has the eventual capability, to deploy 3D applications and games, to Windows, OS/X, Linux, Android, iOS and WebGL recipient-platforms, while some forms of it will run under Windows and Linux, in my own experience.

I have to say though, that my ability to get the Linux version of this game-design platform working, was not due to my own prowess, but rather to the fact that the development team at Atomic Game Engine, provided dedicated and consistent technical support to me, every time I ran into a problem. I would guess they are rather tired of answering my many questions for the moment, so it is also good news, that both under Linux and Windows, my installations of this platform are complete – to my own satisfaction.

I have exported a 3D application to Android from my Windows platform, but have not reproduced this success under Linux, mainly because the platform requires that I specify where my Android SDK and where my Ant executable are located – sensibly – and I do not have any Android SDK presently, installed on ‘Klystron’. I do have the Android SDK installed on ‘Mithral’, which as I said is required, and so the export to Android worked there.

Installation under Windows was much more straightforward than it was under Linux, which is often the case, because the Windows version comes as an available binary SDK, while under Linux it still needs to be custom-compiled. And whenever we custom-compile anything, we can run into dependency issues.

One major issue I faced under Linux, was the fact that the Mono packages that are standard for my Debian distribution, are not adequate in what they provide, for development in C# to be enabled. And so what I needed to do, was to subscribe to another Mono repository, managed by Mono project, to upgrade my whole Mono installation, and after that, C# also worked.

So, Atomic Game Engine allows for 3D applications and games to be designed, using the languages C#, JavaScript, and TypeScript, according to my own experience… But, a C# Project cannot be exported for WebGL playing.

Also, I have discovered along the way, that We are no longer expected to install ‘Visual Studio 2015 Express’, but rather “Visual Studio 2015 Community Edition”, and in order to get C# support to work properly on my Windows 7 machine, I needed to do an in-place upgrade, from ‘VS Express’ to ‘VS Community’.

I am pleased that all the installation and upgrading seems to have gone well, and seems to have left me with no major reliability issues, either on ‘Klystron’ or on ‘Mithral’.

However, because the build of Mono now on ‘Klystron’ is non-standard, I cannot vouch for it in general. On my actual server-box ‘Phoenix’, I must choose to stick with the more conservative Mono packages, that are meant to go with Debian, because this box needs to run reliably 100% of the time. OTOH, on ‘Klystron’, I had nothing else depending on Mono, for which reason I was also willing to do the upgrade.

Dirk

 

OGRE 1.10 and Geometry Shader Support

On my Debian / Jessie laptop ‘Klystron’, I gave up some time ago, in compiling OGRE 1.10, this just resulting in a mess. Instead, on that platform I was only able to build OGRE 1.9 from source code, which is fully stable, as long as we stick to the OpenGL (2) Render System.

On the Windows 7 desktop ‘Mithral’, my first attempt to build OGRE 1.10 also failed, resulting in a successful compile, but then a silent crash of the Sample Browser, indicating that something was not built right.

If I have OGRE installed on several machines, it makes most sense for them to be the same OGRE version, so next I compiled OGRE 1.9 on ‘Mithral’, successfully, using Visual Studio 2015.

In response to my observation, that I had not set up the dependencies correctly on the ‘Mithral’ build attempt of OGRE 1.10, I now re-attempted that, paying closer attention to all the details, specified within CMake 3.6.2 .

I found that I could not only build OGRE 1.10 on this machine but also run it. And I found, that contrarily to how it was with OGRE 1.9, the OpenGL3+ Render System of OGRE 1.10 is capable of producing working Geometry Shaders. At least this gives me some access to Geometry Shaders, and casts doubt back onto the MESA Drivers of ‘Klystron’, which would cause the X-Server to crash, if I ran the Geometry Shader example of OGRE 1.10 .

What I still cannot do, is build the DirectX 11 Render System that is supposed to work under OGRE 1.10 , due to errors I have not yet pinned down. But what that was supposed to bring me, is now being provided successfully by the OpenGL3+ Render System. Both of these two are stated by the OGRE Team, to be experimental render systems, for version 1.10 still.

I suspect that OGRE 1.10 is being neglected by their team, in favor of OGRE 2.1, which is their effort to port OGRE to Android.

Dirk