I have for some time now been running multiple versions of Linux as VMs on my 2019 MacBook Pro via Parallels. Up to this point everything has run smoothly. Until recently, that is, with Visual Studio Code. For whatever reason, something was altered within VSCode that causes it to completely render the display either as you see it above, or if I resize the window, as a red-only window with the white, in which the black is replaced with red. I at least traced to the release where the problem did not occur to 1.52.1, the November 2020 release. Every release since then has exhibited this problem.
Normally I’d take this as something of a challenge and try to find and fix the issue, but before I decided to dive in and look into it I fired up a RHEL 8.3 VM. I had VSCode installed on it and I needed to do some rather quick code work inside VSCode. I have all my VMs sharing common data using a folder on the Mac so it’s rather easy to keep data and source code easily synced. Unfortunately the same problem reared its ugly head on the RHEL VM.
I believe that there is something unique about the current release of VSCode that causes it to improperly render when running within a Parallels Linux VM.
In the mean time I’ve dropped back to VSCode 1.52.1 and blocked it from being updated. I’ve also built and installed Emacs 28, just like I did on the Nvidia Xavier under Ubuntu 18.04. If this problem remains unsolved in VSCode then it looks like I’ll stick with Emacs.
I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.
The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).
Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.