Future-proof your skills with Linux, Python, vim & git as I share with you the most timeless and love-worthy tools in tech through my two great projects that work great together.

Live-streaming With Github Copilot in NeoVim for Motivation

I'm experimenting with NeoVim, a vim-compatible fork, to live-stream in my journal. I'm also exploring the Meissner and Schwinger effects to create more thrust. To achieve my goals, I'm using Linux, Python, Vim, and Git. I'm creating an updated graphic of my stack to help others succeed. Join me as I dive head-first into my project tomorrow.

Experimenting with NeoVim to Live-Stream and Create More Thrust with Linux, Python, Vim, and Git

By Michael Levin

Thursday, March 30, 2023

Building up the motivation to do a thing is the hardest part. I’m going to try a project using the MOZ Links API, doing it the sort of way I advocate doing these things: on Python on Linux. That way you’re using standard Linux paths, and your code is portable between standard instances of same-distro Linux. I’m going to tend to target Debian-based Linux distros as a sort of universal portable interoperable layer for executing standard server scripts.

The scripts can be very standard indeed now, with the Windows subsystem for Linux installing a standard modern Ubuntu distro. The Macs can use the MutiPass installer from Canonical that accomplishes the same thing. Point is, very standard Debian-derivative Linux instance running, on which you can do further software installs and run system services. These systems are basically Python scripts but with support from the OS to keep it running.

Long-running scripts is a style of scripting. Often times there’s a temptation to just use cron as built into ye ole Unix. And while it’s true it’s a good hard core fall-back, we have something better today in the form of standard systemd services. These are the same services that run the Linux kernel and can just keep running your Python script. You can even have it restart if the server reboots. This is a very standard way to run a script on a server.

So it’s a seldom discussed super power of Linux that you can run a Python script as system serves, with the OS keeping it running and restarting it when necessary. As it turns out, this is the next level of professional development Jupyter Notebooks users should be aiming for. As soon as you’ve got something worked out in a Notebook, promote it to a systemd Linux service. This is the very cool competitive advantage of Linux over Windows and Mac.

The underlying concept here is that there should be one generic unit of local computing power that can be used for any purpose. This is the Linux VM. One very impressive capability of most modern hardware and processors is to run what is called a Hypervisor. This is a virtual machine manager that can run separate virtual machines on the same hardware.

The Hypervisor is a very powerful piece of software that can run multiple Linux VMs on the same hardware. This is a very powerful concept. It’s like having a bunch of computers in one computer. This is the sort of thing that makes cloud computing possible, but it’s possible right on your own machine with very little effort. On Windows, it’s the activation of the Windows subsystem for Linux, aka WSL. On Mac, it’s the installation of a Linux VM using VirtualBox, but even that’s simplified by an Ubuntu installer from Canonical called MutiPass.

Between WSL on Windows and MutiPass on Mac, you can get such a standard Linux running that you can have subsequent installs of Python and Jupyter Notebooks including the whole Linux-based Jupyter server so that your Notebooks can actually be executing Linux-based Python code. This is the sort of thing that makes Linux so powerful and so much more than just a hobbyist OS. The stuff you set up on a tiny little Linux VM on your laptop is the exact same way you’d set up a server in the cloud. It’s the same thing.

The reason I’m going to use Linux for this is because it’s the most portable code execution environment. Scripts you write to run on it will be sure to work as you intend for a very long time. If you pin software versions so execution context doesn’t change, you can be sure that your code will work for years to come, even if you don’t touch it. This is assuming any APIs you’re connecting to don’t change, nor supported protocols.

Python, which is quite portable in its own right, especially with things like pathlib, but when paired with Linux, it’s even more portable. Neither Linux nor Python are the cure-all technology for every situation, but they do go a long way together. They go so far in fact that you need only layer in a couple of other commands so popular that they are now included as standard in modern Linux distros. Those are vim and git.

Vim is a text editor that is so popular that it’s included in most Linux distros. It’s actually part of the standard for Unix, thus is also standard for Linux, and also means it will always be available. Learn it and develop your muscle memory on it, and the carpet can never be pulled out from under you. Vendors figuring out how to design obsolescence into their products to keep you buying can’t target you if you’re a vimmer.

Ugh, that motivation! I don’t have the energy to do a live stream of me connecting to the MOZ Links API. Maybe I’ll just do a video of me doing it. I had the motivation earlier, but I was going to live stream it to a MOZ-only on YouTube. I’ve noticed a co-worker providing Google Drive links to videos. I suppose I could do it that way, but YouTube live-streaming spares me having to have local files. It just will be very raw and unedited.

I can always send links that have those YouTube t= number of seconds links. That’s how I can capture a whole raw experience of seeing documentation and an API for the first time. This is all still now under the category of tooling. How to do this while keeping it in the family. Not everything needs to be Youtuber to a public audience. This audience of my employer will appreciate me using the infrastructure and GSuite integrated permission security content for this sort of content. It’s in the cloud, but still quite organizationally secure.

Switching from vim to NeoVim has also been quite a kick. The kick is doubly kicky because I made the switch so I could use Github Copilot.

Why is it that the Meissner effect and the Schwinger effect will create more thrust combined than the Schwinger effect alone? The Schwinger effect will create a steady stream of instantly self-annihilating electron-positron pairs, but for the brief moment they exist, they will be perfectly polarized, because the photon source was polarized. Normally white-noise neutralized energy will be aligned, thus producing macro-scale fields, and a general pressure unbalance in the cosmic background energy field. This could provide a bit of thrust.

The Meissner effect is the effect of a superconductor that will repel a magnetic field. This is the effect that allows magnets to float over a superconducting ceramic disk, usually cooled with liquid nitrogen. It’s a common enough experiment. The reason the magnets stay locked in place levitating rather than rolling of from instability like two magnets is the fact that superconductors can actually trap magnetic fields in tiny deliberately designed imperfections in the superconductor, caused by sandwiching layers.

If you use the Schwinger effect to create a steady stream of polarized energy, and then use the Meissner effect to trap that energy in a superconductor, you can get a steady stream of thrust. It will be more thrust than the Schwinger effect alone, because the Meissner effect will trap the energy and double-focus it sort of like the way using two lenses in a telescope will double-focus the light. The Meissner effect will double-focus the energy, and you have an antigravity propulsion system.

There I go getting carried away with anti-gravity propulsion systems again. How could I not given the CoPilot GPT-4 integration with vim? It’s not really even vim anymore. That’s going to take some getting used to. It really tests my openness.

Hey, I’m live-streaming in my journal in NeoVim after having just switched from vim in order to get the CoPilot GPT-4 integration. I’m not sure if I’m going to be able to do this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to get used to this. I’m going to have to o

Okay, enough of that silliness. But seriously, how could I not live-stream this nutty evolution of technology, society, humanity? It’s nuts, right?

This is really just an experiment. I have to start clocking some time in on NeoVim. It’s all about exercise and muscle memory. I advocate Linux, Python, vim and git, and here I go switching from vim to NeoVim. But vim is still in the name, isn’t it? NeoVim is actually a highly vim-compatible fork of the actual original vim.

What is it, about 9:00 PM on a Thursday? I have a little time tomorrow to dive head-first into this project I haven’t been able to get myself to really start. I think I’ve been overwhelmed with tooling advance. People using CoPilot in VSCode must be going through something similar. But I doubt they use VSCode for… on The Why Files is airing…

I’m going to watch that, folks. Haha! But I’m glad I got this out of my system. A first real live-stream of me using CoPilot in NeoVim.

For now, let me at least get the first reference to this graphic out there. It’s an update to an old “my stack” graphic I made. I like this one more. It’s more attuned to the times. I think I’m going to be able to lead a lot of people seeking this sort of guidance in a rather unexpected yet still quite fruitful direction. I’m going to be able to lead them to the Linux, Python, vim and git stack or toolchain, which will serve them well in the future.

Mike Levin Stack

I’ve got to get the “timelessness” of it all into this graphic somehow.

Oh, hello! Let’s start fresh…