I bring up Ken Thompson’s talk because today I was reminded of why he said he was leaving Apple in that talk. After starting Visual Studio Code on my brand new M1 Max MacBook Pro I attempted to check for VS Code updates and was gobsmacked with the following error dialog:

Look in the lower right corner at the dialog with the red circled ‘X’ about running on a read-only volume. There’s a link to mitigate the issue, but the the statement that “This might mean the application was put on quarantine by macOS” just royally pisses me off. This is the very first time I’ve been hit with the “quarantine application” issue on macOS, but not the first time I’ve run into a show-stopping problem on macOS that shouldn’t have happened.

I followed the link in the message, and based on the post I performed the following to get things straightened out.

sudo chown $USER Library/Caches/com.microsoft.VSCode.ShipItxattr -dr com.apple.quarantine ~/Applications/Visual\ Studio\ Code.app

My VSCode is located locally in my account folder, not under global /Applications. I’m sure that chown isn’t needed, but still it’s good to have around. Once those changes were made, I quite VSCode and restarted it via Launchpad as always, then checked again for updates, and it worked just fine (VSCode was already up to date anyway).

It’s obstacles thrown up like that that make developers like me who actually know how to get work done want to just walk away from Apple. I’m sure Apple will point to XCode, but I don’t want to develop with XCode because I do a lot of wide-ranging work well beyond Apple and macOS. It’s not as bad as Microsoft, who have basically driven me away from Windows permanently with their shenanigans with regards to Windows 11. But it’s getting close. If it gets bad enough I may indeed contemplate migrating to Asahi Linux; that’s another reason why I chose this M1 Max over a later version of Apple Silicon; Asahi Linux was originally developed on, and for, the M1.

Links

Code won’t update on macOS #7426 — https://github.com/microsoft/vscode/issues/7426

Let me note up front that I have my Raspberry Pi 5 plugged into an LG 27GL850-B monitor with a native resolution of 2560×1440 (purchased last Christmas during an incredible sale from Amazon), no overscan or special screen manipulation needed. That gives me a rather wide screen, which in turn allows me to open up an editor such as VSC that allows me to set up a vertical three-panel layout (see above) with plenty of space in all three panels.

After following Microsoft’s directions for installing .NET 8 on Ubuntu I was able to follow their basic tutorials on how to compile and debug C# on Linux. Let me again emphasize that this is Linux on a Raspberry Pi 5, which is AArch64/ARM, not x86-64. And it works. I find all of this amazing considering how I started with the original Raspberry Pi 2 ten years ago and struggled to get Python running.

In my not-so-humble opinion the best distribution to run on the Raspberry Pi 5, bar none, is Ubuntu 23.10 for the Raspberry Pi. Everything works with one notable exception: manipulating the GPIO and through that, physical computing. But I have found an easy solution for that (which I will document later), and it all seems to work without a hitch as well as it would under Raspberry Pi OS for the Raspberry Pi.

As they say, more to come.

Links

• Install the .NET SDK or the .NET Runtime on Ubuntu — https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu
• Tutorial: Create a .NET console application using Visual Studio Code — https://learn.microsoft.com/en-us/dotnet/core/tutorials/with-visual-studio-code?pivots=dotnet-8-0
• Tutorial: Debug a .NET console application using Visual Studio Code — https://learn.microsoft.com/en-us/dotnet/core/tutorials/debugging-with-visual-studio-code?pivots=dotnet-8-0

Note that I did not install support for Android (Android SDK and Android Studio) nor the Web (via Chrome). All I’m doing is writing Flutter desktop applications.

The Flutter plugin within VSCode automates quite a lot. Using the VSCode Command Palette, you can create an initial Flutter application (Flutter: New Project) that will create skeleton code and build files that compiles and runs the graphical equivalent of hello, world.

As you can see, the Flutter tools for both the framework and the VSCode plugin provide an effortless on-ramp to developing applications. Creating the start of an application is ridiculously easy, and it’s capable of building and executing from the get-go. One feature this has and I use quite a lot is hot reload. When I make changes to the code, when I save the changes they’re rebuilt and the running application restarted immediately showing those changes. That’s why I use this setup.

And here is the initial application’s extremely simple desktop window. When this works well, it’s a little like magic.

Unfortunately I ran into a problem where Clang, one of Flutter’s dependencies, could not link a C++ application that is part of the Flutter application. The error message reported by the Flutter tooling was (with much superfluous reporting snipped away):

.../usr/bin/ld: cannot find -lstdc++: No such file or directory...

This really annoyed me because I have this same setup on my other Linux Mint system, the UM250. With a bit of googling I discovered what was wrong, and how I’d accidentally side-stepped the issue on the UM250. I solved the problem on the Series 7 with sudo apt install libstdc++-12-dev. After that the Flutter tool chain just worked.

Why didn’t I see this issue on the UM250? Because I’d installed gcc/g++ version 12 to support another small project I was working on. On the UM250 I have both versions 11 and 12. Then when I later updated an older installation of Flutter and ran the same simple tests, everything worked there as well. I don’t intend to install gcc/g++ version 12 on the Series 7 as there is no need.

What I don’t understand is how Clang and GCC got out of sync on Linux Mint 22.1. The version of Clang installed is version 14, and requires libstdc++-12. Unfortunately Linux Mint 22.1 installs GCC version 11, which means that if you wanted to build with Clang you’re out of luck unless you know of Clang 14’s dependencies.

As I wrote earlier I’ve switched back to Visual Studio Code on my Linux Mint 21.1 system for C++ development. In order to support Qt 6 C++ development, I needed to modify the C++ plugin’s include path to point to specific Qt 6 include files. The easiest way to do this is (and this assumes you have the Microsoft C/C++ extension installed to begin with):

1. Select Extensions in Visual Studio Code on the far left.
2. On the C/C++ Extension left-click the gear.
3. On the menu that appears, select Extension Settings.
4. In the Settings screen that opens, scroll down to C_Cpp > Default: Include Path.
5. Click the blue Add Item button.
6. In the input text box that appears, type in the full path to the Qt include files. Note in my example I have two paths to the Qt 6 include files.

Once you’ve updated the include paths just close the Settings tab. If you don’t have those additional paths in the Microsoft C/C++ plugin, then any and all Qt include files will have the dreaded Red Squiggly Lines underlining all those include files it can’t find.

There’s a lot to like about Emacs. There’s the easy keyboard control, the ability to pick a productive theme, and the way it highlights code as I write it. It’s not an IDE, and I don’t want it to be an IDE. But I do want more than just a simple text editor, especially when I’m working with C++, Go, or Rust.

Unfortunately, I’m set in my ways when it comes to how my code should look as I type it in. The greatest irritant to me is tab spacing in code. I expect tab spacing to work like this: four spaces, no tab characters, only spaces for tabs. Most of the time Emacs does this with aplomb. Wonderful formatting, especially in Rust and Go. Unfortunately it doesn’t always want to do this with C or especially C++. In spite of reading every document dump, every dedicated wiki, ever sub Reddit, every Medium article, every Stack Overflow post, Emacs has decided to set tab stops to two spaces, no matter how I configure those settings via init.el. I even tried to drop back to an earlier Emacs release, only to find that whatever Emacs Lisp configuration scripts had been picked up by my current Emacs release wouldn’t execute properly with an earlier release.

Since I couldn’t satisfy my frustration by actually fixing the tab space issue within Emacs, I opened up Visual Studio Code and went looking to see why it was constantly consuming processor overhead. I found the guilty plugin by turning off one plugin after another and restarting VSCode. I found the guilty plugin, a plugin I seldom use, disabled it, and I’m now back to happily writing code in VSCode again.

I’ve been working a bit with GNU C/C++ (version 11.3) on Linux Mint 21. I’ve been trying to use Visual Studio Code for coding, thinking that it, along with Microsoft’s extension, would help me write more effectively by pointing out problems/errors and providing suggested solutions. Sometimes that works, sometimes it doesn’t, meaning that I get the error but no idea how to solve it, no clues whatsoever. Rather, if I take the problematic code and let GNU C++ try to compile it, I get very verbose errors that include helpful suggestions on how to correct the problem.

This post uses a very simple program that requires C++ in order to compile and execute. Here’s the correct listing.

#include <iostream>#include <iterator>int main(int argc, char *argv[]) {std::copy(argv, argv + argc, std::ostream_iterator<char *>(std::cout, "\n"));}

It’s just six lines of code (five if you ignore the whitespace). The key line is line 5, a one-liner that prints out all the arguments passed along to the application when it’s called, one argument/line. I didn’t create this, but I learned it decades ago and have kept it in my “back pocket” along with many other bits of proven and useful code.

The problem occurred in another application when I failed to include a library that required an iterator definition. I eventually fixed it, but only on the command line using GNU’s C++. I then whipped up this example to show what I’m complaining about. If you look at the top screen capture you’ll see that VS Code has put red squiggles underneath the problem code. I’ve deliberately used an ostream_iterator that calls out for the inclusion of the iterator library. Unfortunately, as you’ll note above, clicking on the bad code in VS Code does nothing more than state the obvious. No clue how you might fix this. And before you say anything, I’ve worked with other IDEs in the past that actually did offer suggestions, and even offered to fix it for you. For example, Android Studio and the IDE it was derived from, JetBrains’ IntelliJ IDE. Granted those tools are all about Java and Kotlin, but still, they’re a lot more helpful and productive.

In the end it was GNU’s C++ that provided all I needed to fix the contrived problem.

cli.cpp: In function ‘int main(int, char**)’:cli.cpp:5:39: error: ‘ostream_iterator’ is not a member of ‘std’5 | std::copy(argv, argv + argc, std::ostream_iterator<char *>(std::cout, "\n"));  |   ^~~~~~~~~~~~~~~~cli.cpp:2:1: note: ‘std::ostream_iterator’ is defined in header ‘<iterator>’; did you forget to ‘#include <iterator>’?1 | #include <iostream>  +++ |+#include <iterator>2 | //#include <iterator>

This help included not only what library definition to include, but where (yes, I commented out the original to break it). Line five in the error listing shows you where ostream_iterator is defined, and line 7 helpfully shows you where to place the include in your code. This kind of compiler help reminds me of the help that Rust’s compiler also produces when it comes across a problem.

My experience with C++ goes back to 1986 when it was first called C with Classes and you had to run cfront on your C++ code to produce C code that was then compiled and linked. All this on a Micro VAX running Ultrix, DEC’s version of BSD Unix (which was nothing more than bog-standard BSD with all the licensing text replaced with DEC). I know it’s so much fun denigrating C++, but it’s evolving to answer the critiques and the needs of its users, both in the language as well as the tooling.

One of the benefits of using Powerline with Bash to modify the command prompt is when I use a shell within another application, in this case Visual Studio Code version 1.70.0. It’s a full blown shell that allows me to do anything I would want to do within an external Gnome terminal. VSCode might not be perfect, and many may consider it tainted because it came from Microsoft, but the developer community has embraced it everywhere and on every platform, and with the exception of some cases totally dependent upon specific features unique to an OS, VSCode works the same everywhere.

I love working on, and with, Linux. It works for me and that’s really all that matters.

Because I couldn’t update my existing Debian 10 container to Debian 11, I deleted my existing Debian 10 container. In the process I also removed all folders that showed up in the files application under Linux folders, and as to be expected all installed applications such as Visual Studio Code. It would later turn out that I could create another Debian container, which is a topic for a later post. Re-creating my first Debian 11 container allowed me to document the steps necessary to add additional software development tools to the container.

Once the container was installed I updated Debian 11 with sudo apt update && sudo apt upgrade -y to make sure the software was fully up-to-date. For those reading this post you’ll find a tremendous amount of older documentation where apt-get is used. The newer form just uses apt, and so can you, saving some typing. The older form is still aliased so copying and pasting instructions into a shell will still work, everything else being equal.

Once the update was finished I attempted to install htop (sudo apt install htop -y) and Visual Studio Code. In order to install Visual Studio Code you need to go to the Microsoft website and download the x86-64 Debian file (see https://code.visualstudio.com/download ). You’ll save the .deb file somewhere in your container’s home directory, and then install it with sudo dpkg -i code_1.66.2-1649664567_amd64.deb where you saved the file.

The problem with this is you’re going to get an error message from apt telling you that there are unmet dependencies for both packages. The error message will even tell you how to fix the problem. To meet those dependencies you’ll need to execute sudo apt --fix-broken install at the command line. I would recommend that if you want both, install both even though they’ll both fail, so that when you fix the broken install both of them will be fixed and installed. One last install is for Visual Studio Code. Visual Studio Code will throw a keyring error. To keep this from happening install gnome keyring: sudo apt install gnome-keyring.

While we’re installing applications, I would recommend you go ahead and install the utility tree as it’s not part of the base install. Read the man page for tree or check this online example: https://www.computerhope.com/unix/tree.htm .

Once all that is installed, you need to decide what languages you’ll develop for. Debian 11 comes with a reasonably current version of Python, version 3.9.4. So if all you want to do is Python development you can stop there. If you want to develop for another language you can install those as well. For example, I wanted to do Rust development, so I installed Rust in the container following the Rust installation instructions here: https://www.rust-lang.org/learn/get-started . To support Rust development you’ll also need to install gcc because Rust uses the local environment’s linker cc, which is a part of gcc: sudo apt install gcc. If you do install gcc you get the side benefit of being able to develop in C. If you want to develop in C++ then you’ll also need to install g++ (sudo apt install g++ -y) and make (sudo apt install make). The tool git is already installed, so if you want to keep your work up on GitHub for example (which I strongly advise) you can do so out-of-the-box.

With everything installed, including a small repo, the total footprint of everything is a little over 4GiB. And I set up my container with a 40GiB disk area, which is probably too much considering what you might do. Since I’m not going to be compiling a Linux kernel, that’s quite enough elbow room to do non-trival work.

Once you’ve install Visual Studio Code you can start it from the Chromebook desktop by hitting the search key on the keyboard (that’s the key on the left above shift with the magnifying glass glyph). It should look something like this:

The icon for Visual Studio Code in my example showed up in the upper left corner. Once you start it by clicking on it, it will show up on your shelf. You can then double-finger click on it to pin it to your shelf for even easier access. My shelf runs vertically on the far left.

I’ve already gone to the trouble to install VS Code plugins for Python and Rust. I won’t go into that because there’s lots of detailed online help if you need that. Suffice to say that the instructions work, even on a Chromebook. In my example I’m beginning to do some Rust development.

Rust will compile and execute either at the command line or within VS Code. I’m sure there are limitations to very large projects, but for quite a bit of work there is more than enough resources to work on this Chromebook.

Why would I push a Chromebook instead of a MacBook or Windows notebook? Cost. The best bang-for-the-buck development environment believe it or not is going to be a Chromebook. A Windows notebook might reach down to what a Chromebook costs, but my reason for avoiding Windows is how Microsoft is trying to turn Windows users into another revanue source with intrusive ads and the limitations against third party applications that is creaping deeper into the OS, especially Windows 11. If you’re an independent developer a Chromebook is the best all-around compromise, especially in these times of high costs for basics and increasing inflation. You can still spend upwards of $400 on a Chromebook such as this Lenovo, but there are all sorts of interesting offers at half that amount, and who knows what you can find used.

A Chromebook like this is even a better deal than say a Raspberry Pi 4 with 4GiB or 8GiB, because you still need a keyboard, mouse and screen. And I do know all about the Raspberry Pi 400. But you can’t fold up a Raspberry Pi 400 or your Raspberry Pi rig and carry it out with you. Portability isn’t the Raspberry Pi’s forte.

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’m working with Pycom ( https://pycom.io/ ) IoT devices. One of the tools they supply to work with their devices is a plugin named PyMakr. They have release a version for Visual Studio Code and Atom. The version for VS Code has never worked on my MacBook Pro 15″ or 16″. As a consequence I’ve turned to Atom just to run the plugin. It seems to work properly with Atom. But I’d rather have it work with VS Code, since I do everything else with VS Code.

Here is the setup for the software environment.

• macOS Catalina, version 10.15.6
• Visual Studio Code, version 1.49.2
• PyMakr, version 1.1.7
• Node.js, version 14.12.0 (installed via Homebrew)

I’ve gone through all the recommended solutions that others say they’ve discovered, and none of them work for me. I’ve seen such error messages in the past on Unix/Linux systems and fixed those error messages in fairly short order. The biggest source is usually a bad shebang at the top of the script. Fix that, and those error messages disappear. But the JavaScript file has no execute bit set, and it appears from the other error messages that node is being used directly instead of invoked within the script itself. The path to the file, and the filename, are all correct.

To make this even more maddening, I have the same setup on a 2012 Mac Mini Server running the same software listed above, and it works. But when it comes to running on my MacBook Pro 15″ or newer 16″, it won’t work at all.

The deb file was built on the Jetson Xavier NX board, then copied to a thumb drive, then moved over via the thumb drive over to the Rasbperry Pi and installed from there. So far it’s behaved reasonably well. I’ve learned quite a bit about the build tools that come with the source. I suppose it’s good that I found some of the directions I did on the web, but now that I’ve gone through this whole process a number of times, what I used to start with short circuits what is available in the source tree cloned from GitHub.

I appreciate that I can use the Jetson NX as a build system. I also appreciate that there is a method in the source tree for building the deb file. That to me is super. Now I can keep up with releases, knowing I can target 64-bit ARM binaries for Debian/Ubuntu.

And speaking of Debian, the 64-bit OS running on the Raspberry Pi now identifies itself simply as Debian.

Once I feel comfortable running the full build suite in Visual Studio Code I’ll post a streamlined how-to for ARMv8/aarch64/arm64. Too many labels, frankly.

As before I used the directions on Clarence’s Wicked Mind blog ( https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). Even though these directions are now over a year old, they still work, which to me is amazing considering how bit rot can quickly set into any given how-to. Since I’m still building off trunk, and not the latest formal release, I wound up with this version:

The current formal release is 1.46 (I checked on my Mac).

I went in and picked out the extensions I wanted to work with because of what I’m working with on the NX:

And for the curious, I’m running the Docker extension with Docker on the NX, and just for grins, I opened up the debug console on the right, just to see what that was all about. All pretty impressive and it looked really interesting, except for the Recommended section on the bottom left, which is empty. And that’s what kept sending me over into the weeds.

I could have sworn on a stack of Bibles that Recommended is never empty. So I went and checked again on my Mac, and wouldn’t you know it, it only had two entries. The behavior I’m describing used to be this way, on Windows. But it changed, and even though I’ve been good to keep up with the updates, I just didn’t pay attention. So when I saw zero recommendation I thought it was somehow broken. Until I went searching for something, and discovered this behavior all over again:

When I searched for ‘angular’ as an example, lo and behold I got all the Angular plugins. A few more searches and I was finally convinced I had a fully working VSCode for the Jetson SBCs. I was just absolutely stupid.

And since I started out with Docker, here’s a bit more of the Docker plugin to gaze upon:

The Docker plugin gives a bit more control and insite into Docker containers. The middle upper window is latest.json for the image, while the bottom middle is attached to the bash shell running inside the container. The right window is the debug window for all of VSCode, just so it looks cool in the blog post. Whatever…

Right now I’ve got a fully operational instance of VSCode by following someone else’s directions to build it. And I couldn’t be happier. Hopefully, I’ve gotten past this patch of personal stupids. But you never know.

{"nameShort": "Code - OSS","nameLong": "Code - OSS","applicationName": "code-oss","dataFolderName": ".vscode-oss","win32MutexName": "vscodeoss","licenseName": "MIT","licenseUrl": "https://github.com/Microsoft/vscode/blob/master/LICENSE.txt","win32DirName": "Microsoft Code OSS","win32NameVersion": "Microsoft Code OSS","win32RegValueName": "CodeOSS","win32AppId": "{{E34003BB-9E10-4501-8C11-BE3FAA83F23F}","win32x64AppId": "{{D77B7E06-80BA-4137-BCF4-654B95CCEBC5}","win32UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32x64UserAppId": "{{C6065F05-9603-4FC4-8101-B9781A25D88E}","win32AppUserModelId": "Microsoft.CodeOSS","win32ShellNameShort": "C&ode - OSS","darwinBundleIdentifier": "com.visualstudio.code.oss","linuxIconName": "com.visualstudio.code.oss","licenseFileName": "LICENSE.txt","reportIssueUrl": "https://github.com/Microsoft/vscode/issues/new","urlProtocol": "code-oss","extensionsGallery": {"serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery","cacheUrl": "https://vscode.blob.core.windows.net/gallery/index","itemUrl": "https://marketplace.visualstudio.com/items"},

In spite of starting with a fresh pull, the build ran much faster due to having all the npm packages already in place. Starting VSCode took the same amount of time as before. When it finally finished the first start, the extensions gallery was visible. Isn’t it lovely to behold?

So then I decided to install three extensions; C/C++, Go, and Python. We’ll lead off with the Python extension because that’s what always seems to bubble up to the top when we first open the extensions gallery.

After installing the first three extensions, I closed and re-opened VSCode. First problem is that the C/C++ extension won’t work on ARM.

I removed the C/C++ extension, then decided to see what else I could find in the extensions gallery. Except, when I removed the extension and opened the gallery, the gallery was empty. Restarting VSCode wouldn’t bring it back. It’s now empty.

Oh well. At least I can still edit C/C++ source files, with decent syntax highlighting, as shown below.

I will continue to use this version of VSCode for the time being. I suppose I could outfit Vim the same way I’ve done on Raspbian, or install Emacs and extend it as well. But I really do like the VSCode environment, and am slow to give it up even with the problems it appears to exhibit here. So far it behaves quite well as a source editor, probably the best of all the editors I’ve mentioned (and far better than gedit). I could also help the community by debugging further, or going back to the last branch release and trying that to see how it works. Getting npm set up fits with other projects I have in mind, so it definitely isn’t a waste for me. But I don’t want to get pulled down a deep rabbit hole working on VSCode for Ubuntu ARM on the Jetson Nano. The primary purpose of the Nanos are in support of embedded machine learning development.

Who knows where this will eventually lead…

My second Jetson Nano Developer’s Kit arrived Monday. Following Nvidia’s directions I had their version of Ubuntu up and running in about thirty minutes. I’ve mounted the Noctua NF-A4x20 5V PWM fan on top with nylon ties, exactly like the first. One reason for buying the B01 is it now comes with two MIPI CSI camera connectors on the edge, CAM0 (right) and CAM1 (left). All versions before this had only one, CAM0. The power selection block is now further inboard, and wonder of wonders, it comes with a shorting block. In the photo the shorting block is in place to select the barrel connector and I have a 5VDC 4A power supply connected via the barrel connector.

A minor editorial comment: I’ve now installed and worked with two Jetson Nano boards, the A02 and B01. In both instances I never once encountered any issues configuring, installing the OS and software tools, or attaching devices. This is counter to the insanely stupid complaints I read on Amazon where a number of knuckleheads gave the board 1 star and bitched about how terrible the Jetson Nano was. The boards are great and work just fine. But you can’t be an idiot around them, or you will break them.

Rather than give screen shots running software you already know about, this is a screen shot where I downloaded and built Visual Studio Code. VSCode for ARM isn’t provided from the same source as all other operating systems. There is a third-party DEB file, built from a year-or-two-older version of VSCode, but no thanks. Instead, I followed the directions here ( “Building Visual Studio Code on Jetson Nano”, https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). I made one major modification to Clarence’s directions, and that was to install NodeJS version 12 instead of 10 using setup_12.x. That’s because the current LTS is version 12. Nevertheless it built, and I was gob-smacked when it came up with the introductory screen the first time I ran it. I was then able to open Bash, C/C++, and Python source files.

The only issue right now is I can’t install any extensions. The extension list is empty. There is a fix I have not tried yet, but which I will the next time I build VSCode. I’m building on my Crucial MX500 .5TiB SSD, so I have plenty of space to just re-clone and re-build with that fix on Clarence’s web page. I wanted to see if it would at least build without errors before I made any modifications to the product.json file. Since it obviously does work, the next step is to try and get the extensions working.

I am so happy to have this building and working on any ARM-based system.

In case you’re curious we’re running with standard Ubuntu 18.04.4.

This is the fully built Visual Studio Code version, from trunk. Note that it’s version greater than the current official installable release, which is 1.44.2.