Top Level Public Wiki: feralcoder shared
feralcoder IT

Tutorials and intros, and other data useful to a certain type...
LilMatrixMisfit: Getting Started With Linux
LilMatrixMisfit: Hardware Testing
LilMatrixMisfit: MSI Z170A Gaming Rig
Servers: SkyLake KabyLake

Algorithmic work is so fundamental to the Linux experience that the bash shell has its own built-in language. Every distro packages a multitude of languages and libraries ready to install, and most default installations will include a few of them pre-installed.

Software engineers and programming language purists will object to BASH's language for some good reasons. But even so, the ability to hammer out algorithms from the command line makes it an essential tool, with its warts. Many would say it's not a "real" language, and I kind of agree.

This is an interpreted language that finds application close to the system, and is the de facto language of system administrators. It's also popular with data scientists, machine learning, and in educational environments.

This interpreted language is older than python and it saturated industry years before Python escaped the universities. It has an iron grip on web frontend engineering, as well as an enduring presence in internet backends and APIs, and big data platforms. This language tends to be very verbose and its value tends to be more high-level than is useful to system administrators. In particular, the "write-once run-anywhere" mantra of java conflicts with the necessarily divergent realities across operating systems, keeping this language in higher-level application domains.

100% not related to Java, other than that you find them frequently used together. Java Script is most commonly used to run web frontend code in the browser, but it can also run on the server side of the connection.

C++ is C plus object-oriented features, plus the Standard Template Library, plus other high-level capabilities. Both are compiled languages, and can be fit tightly to the underlying machine code for maximum efficiency. Programs which need to be aware of machine differences and exploit them are frequently written in C or C++. Windows, Linux, and MacOS are all written in C and C++ (Objective C instead of C++ in the case of MacOS). Their kernels are all written in C and the assembly language of their target hardware.

The C's are also great languages for embedded applications, which is to say "running on devices that aren't actually computers", because of their leanness at run-time, the tighter size of libraries, and better ability to interface with the assembly language of any machine architecture. Another reason they are embedded favorites is that other languages lean on the operating system more heavily, where C languages operate with more primitive system calls - many embedded applications use very gimped OS's.

This is the language of the machine, direct-translated into human-readable mnemonics. This is specific to a machine's architecture.

The same operating system code written for multiple architectures will include a mix of languages. The C++ will look largely similar between the Power PC and x86 architectures, the C will be more divergent, and the assembly will be entirely different.

PHP, Go, R, Ruby, Scala, Rust... All are well-supported in any Linux distribution.

The Python project maintains a great tutorial on its own site:
https://docs.python.org/3/tutorial/appetite.html

As you write larger and more complex programs it becomes increasingly challenging to keep track of which changes you made for what reasons, for testing or reversion. As you start to collaborate this problem increases expenentially. This is what version control is all about.

The basic idea is that a coder does some amount of local work, and then commits batches of related changes as a unit, with some description of the changes, to a central repository. This repository may be shared with a team to facilitate coordinated integration of everybody's work, or it may be a tool to help a solo developer organize, test, roll back, and deploy their own work.

There are some options here, with small and big differences... I'll vote Git every time.

Git is a distributed system - instead of there being a single central repository, there may be many peer repos. An organization could, and often does, enforce some form of centralization, EG a single central repo which all developers ultimately commit to, but this is convention and definitely not required. This distributed nature would allow team-mates to commit changes directly between their own local repos. Some examples of where this model excels:

• Collaboration between sub-teams, without exposing the larger team to incomplete sets of changes.
• Maintaining parallel environments or staging pipelines, each having its own "master" version of the code (eg DEV, STAGE, PROD).
• Offline work against a local repo, to be reconciled periodically against a remote central repo.

NOTES: While Git is perfectly suitable to run entirely locally, it's also trivial to mirror a repository to github for publication to the world, or even for a private 3rd-party-managed code base.

SVN is a classic centralized versioning tool. It's simple and intuitive, which can help minimize tangles when it comes to resolving merge conflicts. It also requires a connection back to the master repo to do any committing or sharing. Big changes could hit bandwidth limitations when it comes to sharing code, even to local teammates, when the SVN master is off-site.

Another distributed system, this one is simpler than git's "blobs and pointers" architecture. Unlike git, partial checkouts aren't allowed, so work on large code bases may be inconvenienced by some large irreducable operations. Written entirely in Python, with an array of reliable and unreliable extensions...

Client-Server model, with plugins. Offers directory tracking (not supported by git or mercurial), but no partial checkout. Free hosting on Launchpad and Sourceforge.

It's free!

You can either start a repo on github and then clone it down to your local environment, or start one locally and push it to GitHub.

Create a new repository in the GitHub GUI, preferably including README.md and LICENSE.md files. Once ready, clone it locally with the link provided on GitHub:

cd ~/CODE/$GITHUB_USERNAME && git clone $GITHUB_REPOSITORY_LINK

If you have an existing directory of code to turn into a repository, do this:
Start by creating an empty repository on GitHub, then using the link provided:

cd $LOCAL_REPO_DIRECTORY
git init
# You should have a README.md and LICENSE.md file for correctness, though not required...
git add README.md LICENSE.md other file names...
git commit -m "first commit message"
git branch -M main
git remote add origin $GITHUB_REPOSITORY_LINK
git push -u origin main

• git status: Show status of current repo. This command will tell you if you have any local changes which haven't been committed.
  
• git diff: Show difference between last commit and any changes since.
  
• git add fileX fileY ...: Stage files for the next commit. Note that once changes are staged, they're no longer shown in "git diff".
  
• git commit [-m "Commit message."]: Finalize staged changes into a commit, with a message.
  
• git push: Push local commits to remote repository. Often this pushes to GitHub, configurations may vary.
  
• git pull: Pull down changes from your upstream repository. This will fail if you have local changes which have not been committed.
  
• git reset HEAD: Unstage any changes since your last commit, but keep them. This essentially undoes a "git add ..." command. This command can be handy when you accidentally add too many files in a "git add ..." command.
  

• git log --oneline: Condense output into one line per commit
  
• git log --follow filename: Only list commits which are related to filename
  
• git log --oneline --follow filename: I have no idea what this could possibly be.
  
• git diff --staged: Show changes which have already been staged for commit.
  
• git reset HEAD --hard: Delete all changes since your last commit, including staged ones. DANGER! This delete is for real!
  
• git diff HEAD~1 HEAD: Show changes between the last 2 commits.
  
• git diff commit-reference1 commit-reference2: Show all changes between any 2 commits. The reference ID's can be discovered, eg, with 'git log'.