@plan-A (ﾟヮﾟ)

I am doing a technical review on a video course on the Go programming language. The creator uses MS/VSCode in the course so it was necessary for me to use that for the review. So far I am not upset with the editor but it is unnatural for me so I had to adapt.

One of the things that bothered me was that when using the shell via VSCode's integrated terminal was that I lost all of my normal shell env that I have taken a lot of time historically setting up. This was not acceptable. So I did a deep dive and found that VSCode runs one instance of the shell for itself and then creates a subshell for it's integrated terminals. I have shields in my configuration that prevent it from being sourced multiple times which can lead to bloat and an environment with a path that has the same directories in it multiple times. So VSCode's approach stopped the integrated terminals from being able to source my configuration so my desired env was not available in VSCode's integrated terminal. I found a toggle that allowed me to turn that feature off so that my env was sourced in the integrated terminals.

Now this may be a small detail to some. Though I do 90% of my work in the terminal and not having access to my normal env was not pleasant at all. It basically made using the integrated terminals painful and unproductive. I was pretty excited to see Nemo Dragon rear his head in the integrated terminal as it showed my env was indeed being sourced! 😉

The only negative part of using MS/VSCode is the feeling that MS is watching, lol, of course I have a copy of VSCode built from sources so I know that is not possible in my case. As I would have seen the code on inspection and I would see evidence of the telemetry on my network.

Would you install a stock version of VSCode and see if you get any telemetry? I would appreciate it if you could do that test for me. Do not use a copy distributed by a third party such as they have in the Fedora repo, get the version distributed directly from MS. I know you will do a very thorough investigation 😀. I have faith in your paranoia 😛

@plan-A (ﾟヮﾟ)

It is a common mistake to believe that shell script is a bash script, zsh script or sh script. Essentially the langue your shell provides. This is not reality. A shell script can be written in many languages. To explain try this:

$ echo "echo hello world" > helloworld
$ chmod +x helloworld
$ ./helloworld

it still executes despite not having a shebang line. As we have demonstrated. In fact if you are creating shell scripts in the bash language (versus the bash shell) and using bash then you do not need a shebang line. This is the default scripting language for the bash shell.

So why do we have a shebang line in the first place? It does not make the file executable, that is what chmod +x does. The shebang line tells us what interpreter to use for this script. That language could be bash, python, perl, tcl, gambas, pascal, ... it does not matter. They are all shell scripts. If they are written in these languages as shell scripts. As many of these languages can also be used to write actual programs versus a shell script.

So when exploring shell scripting understand that you are not limited to any specific language. There are many choices, more than I will list here.

Here is a fun fact for you. Notice how many languages will accept a # as a comment line? This is not an accident or coincidence. It is a design feature so that the language itself will ignore the shebang line in a script.

In fact a large number of common commands we use on the CLI are shell scripts and many are written in python or perl. They are shell scripts. This is why we do not use file extensions on our shell scripts. Though if we were writing a program that is entirely independent from the shell it would be acceptable.

@plan-A (ﾟヮﾟ)

Keep this in mind. If it is part of the name a user has to type that too in order to execute it. So if your script grows to where you have to go from bash, to python or perl, then the filename changes and your script is no longer accessible to those that are unaware of the change.

For files that are consumed by other applications or services then yes, you should use an extension such as .html, .php. If you had a library of functions and shell variable or even environmental variables then you may use a .sh extension, though you would not use a shebang line and you would not make that file executable as it would only be sourced, and never executed.

Keep in mind that file extensions do not really exist in 'nix. a dot is just another character in the filename except when it is the first character and it tells the shell that this is a configuration file and should not be displayed by default. The concept of an extension comes from DR/CPM and then was inherited by MS/DOS etc. Because the extension is used in MIME types by applications and servers we pretend there are extensions in 'nix, even though there is no such built in construct.

Say you have a python script, if it is part of an application and is not a command you use on the CLI then it is completely acceptable to use a .py extension. If it is a command to be used on the CLI then it should not have a .py extension.

There are a lot of new people in the 'nix domain that come from MS/DOS and MS/Windows and they have a hard time accepting that certain artifacts that were necessary on MS OSes are no longer needed or even advised.

The rule of thumb is easy. If it will be executed as a command on the CLI it should not get an extension. If it is an application that will not be used on the CLI then extensions are fine.

@plan-A (ﾟヮﾟ)

I doubt you would need a new cmake 😉. Your build would not be the same as mine though. I build it with Cuda Support for my Nvidia Video card. I keep my Cuda Development Kit in a distrobox container that I created from an OCI container I built with podman. This is necessary because Cuda Dev Kit is not available for Fedora 43. I use a a Fedora 42 Toolbox image as a base to build my OCI image. This is my Containerfile:

FROM registry.fedoraproject.org/fedora-toolbox:42

# 1. Install prerequisites for the installer
RUN dnf -y install wget perl gcc-c++ make cmake kernel-devel && \
    dnf clean all

# 2. Download and Install CUDA 13.1 Update 1 (Version 13.1.1)
# Using the -O flag ensures the file is named correctly for the next command

RUN wget https://developer.download.nvidia.com/compute/cuda/13.1.1/local_installers/cuda_13.1.1_590.48.01_linux.run && \
    sh cuda_13.1.1_590.48.01_linux.run --silent --toolkit --override && \
    rm cuda_13.1.1_590.48.01_linux.run

# 3. Set Environment Variables
ENV PATH=/usr/local/cuda-13.1/bin${PATH:+:${PATH}}
ENV LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

# Label for Toolbox/Ptyxis integration
LABEL com.github.containers.toolbox="true"

to build:

podman build -t cuda131-toolbox .

It takes a while for it to build because the Cuda Dev Kit is like 16gb. I then create a dropbox as it is the easiest way to integrate my ptyxis terminal with the Container, it handles all the bind mounts and Volumes for me.

to create dropbox:

distrobox create --image cuda131-toolbox --name cuda-dev-dbx --nvidia

of course for this to work you have to have a Nvidia GPU, Install the Nvidia drivers from RPMFussion Non-free, and create a CDI. This all has to be done before you build the OCI container image and create a dropbox.

Though when done it creates a seamless Cuda Development Environment that I can use for building llama.cpp with cuda support as well as custom version of PyTorch, etc.

I only rebuild the container when a more recent version of the Cuda Dev Kit comes out. So I use the same container for quite a while before I need to rebuild it.

I just synced my fork to llama.cpp on github yesterday and did the build this morning. I had to tweak the build to allow the binaries and libraries to work on my host machine and not just in my dev environment. I just told it to not use shared libraries, and statically link the cuda runtime.