fixing the visual studio code problem on jetson xavier nx

tl;dr — Visual Studio Code versions beyond 1.59.x will not work on the Jetson Xavier NX software stack which includes Ubuntu 20.04 for Armv8/Arch64. If you want working Visual Studio Code then install version 1.59.1.

In the last post I was lamenting not having a working Visual Studio code. I knew it had worked before the update because I had used it and had written of my success in the past. As it turns out I’ve outfitted the NX with a Western Digital Black 250GB NVME M.2 SSD. That’s were I stash files I don’t want to use when I trash the boot drive, which like the Raspberry Pi, is on an micro SDXC card. Sure enough I found an old Visual Studio deb file, version 1.50. I installed that and Visual Studio worked. I did a bit of installation shuffle between old VSCode releases and discovered that any version for arm64 greater than or equal to 1.60 would not work. Thus I found and installed 1.59.1 and called it a day. I have no time to waste on trying to fix this, nor do I feel the need to finger point.

In order to keep VSCode from yelling about an update, go to File | Preferences | Settings and search for Update: Mode. On the drop down menu select none. Then restart VSCode.

To keep apt from updating it when it’s run, at a prompt type sudo apt-mark hold code and press return. The next time apt is run it’ll show an update for VSCode, but it won’t install it.

I’ve now decided to repurpose the NX to something more useful, such as an environmental monitor and house hold assistant. I don’t know what I’ll use in the future, but it won’t be nVidia. Reports are appearing that nVidia is pouring all its resources into its AI products, and they’re charging top dollar for everything. I checked to see what the official price for a Jetson Orin Nano Developer kit was, and it’s $500. Back when I purchased my Xavier NX, I also purchased the then-available Nano Developer kits, and they were $100 each. There’s a reason I’ve been following and using RISC-V based microcontrollers, and that because everyone is now working on versions that can do AI/ML workloads. I’ll keep working with what I’ve already got because it’s in hand and I don’t want to waste it and let it lie idle. But whether its their AI products or their graphic cards, nVidia is out to pull every dollar it can get away with out of folks wallets. I’m tired of the too-high prices, and I’m done with nVidia.

building git 2.41 on linux mint 21.2

tl;dr — A problem I encountered building from source and then executing git, and how I solved it.

I am not afraid to download the source for a tool and to build a local copy on my Linux Mint system. I never had that fear, having learned to download and build GNU applications and tools back in the day when Unix ruled the earth. We’re talking decades ago. I’m also to the point that while I’ll run Linux Mint as my foundational operating system, I prefer to run the latest packages because those available in the Linux Mint repos are locked back in time to the Ubuntu 22.04 release cycle. Software advances quickly and 16 months is a log time. It’s even longer if you realize that Ubuntu 22.04 is based pretty heavily on Ubuntu 21.10, which makes the time differential even longer. Thus, when I want to run the latest tools I’ll first turn to flatpak or appimage versions. If that fails I’ll download the sources and build it myself.

I prefer my critical build tools to be fully up-to-date compared to what Linux Mint provides. The latest versions of those tools usually incorporate fixes and new features not available in the older distribution-provided versions. The version of git provided by Linux Mint 21.2 is 2.31.1. The latest git release version on the git website is 2.41.0. I checked to see if there was a flatpak version of git (there wasn’t) then proceeded to download the source and build it.

Git source requires you build it within the source directory itself, which I normally don’t like to do. I prefer to create a parallel build directory then configure and build within the build directory. It keeps the source directory clean and allows me to simply delete the build directory if I want to rebuild everything. Regardless, I ran configure and then make, and everything seemed to build. I installed in a non-root location (in my home folder under ~/tools/git). I set my path to point to my built version, and then set about testing it. I quickly ran into the following error message;

git: 'remote-https' is not a git command. See 'git --help'.

A little bit of search showed that I was missing an installation of libcurl. So I executed the following;

sudo apt install libcurl4-openssl-dev

Once libcurl was installed I deleted the git source directory, unpacked it again, re-configured, rebuilt and re-installed. When I used it after the second build it performed correctly. So far everything works as advertised.

Here’s a link to the source tarballs: https://mirrors.edge.kernel.org/pub/software/scm/git/