Instead of doing cat file1 file2 | grep -i searchTerm, it is better to use grep directly. The result is not only more efficient, but it’s more informative aswell.

Here is why

I came across a video by [[Luke Smith]], where he explains why you should avoid using cat into grep. This video made me reflect on my own usage of cat , and what it’s really meant for, which is concatenate and write files.

Look at the following output of running cat file1 file2 | grep -i fox:

cat file1 file2 | grep -i fox
The quick brown fox jumps over the lazy dog.
foxes are beautiful animals

Now take a look at the output, using only grep;

grep -i fox file1 file2
file1:The quick brown fox jumps over the lazy dog.
file2:foxes are beautiful animals

Do you notice the difference?

Not only do we save memory by eliminating the use of another program (cat), but we also get information about which files the search string appears in.

It’s a good practice to always be thinking about how you can strip down redundant programs and lines of code, so that you are left with only the bare minimum.

Changing a bad habit that is engrained in your mind can be tough, but mindful reflection will help you to adopt new ways of thinking.

Links :

202407101228

https://www.youtube.com/watch?v=82NBMvx6vFY

https://www.gnu.org/software/coreutils/manual/html_node/cat-invocation.html#cat-invocation

https://www.gnu.org/software/grep/

Not convinced yet? Check out the GitHub page , and scroll down a bit until you reach “example.mp4”. You’ll see a video that demonstrates some of its cool features.

You can check out other nice features here , like scrollable preview, bulk rename and integration with tools like fd , rg , ueberzugpp and more.

Installation and quick start

https://yazi-rs.github.io/docs/installation/

Good luck!

Links:

202405211803

https://github.com/sxyazi/yazi

https://yazi-rs.github.io/

Helm is the best way to find, share, and use software built for Kubernetes . It helps you manage Kubernetes applications and helps you define, install, and upgrade even the most complex Kubernetes application.

Helm is a graduated project in the CNCF and is maintained by the Helm community .

What is a helm chart?

a Helm chart is a powerful tool that simplifies the deployment, management, and sharing of applications on Kubernetes by packaging all necessary resources and configurations into a single, reusable unit.

In other words, a Helm chart is a package that contains all the necessary information and resources to deploy an application or service onto a Kubernetes cluster. It includes a collection of files that describe a related set of Kubernetes resources.

Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste.

How to install helm

https://helm.sh/docs/intro/install/

Example Structure of a Helm Chart

mychart/
  Chart.yaml        # Chart metadata
  values.yaml       # Default configuration values
  charts/           # Dependency charts (optional)
  templates/        # Templates for Kubernetes resources
    deployment.yaml
    service.yaml
    ...
  README.md         # Documentation (optional)

Components and functionality of a Helm chart:

1. Chart.yaml: This file contains metadata about the chart, including the name, version, description, and any dependencies on other charts.

2. Values.yaml: This file defines the default configuration values for the chart. Users can override these values when they install or upgrade a chart to customize the deployment.

3. Templates: This directory contains a set of templates that generate Kubernetes manifest files. The templates use Go templating syntax and can include variables that are defined in Values.yaml or provided by the user at installation time.

4. Charts: This directory (optional) can contain dependencies, which are other charts that this chart depends on.

5. Files: Additional files can be included in the chart for reference, such as README.md or any other documentation.

How Helm Charts Work

• Packaging: Helm charts are packaged into .tgz (tarball) files, which can be distributed and shared.
• Installation: When you install a chart using the helm install command, Helm takes the templates, substitutes any values, and generates Kubernetes manifests that are then applied to the Kubernetes cluster.
• Customization: Users can provide their own configuration values via the --values or --set flags to customize the deployment without modifying the chart’s source code.
• Versioning: Charts can be versioned, allowing for consistent deployments and the ability to roll back to previous versions if necessary.

What are the benefits of using Helm Charts?

• Reusability: Helm charts encapsulate Kubernetes resources into reusable packages, making it easy to share and reuse configurations across different environments.
• Simplified Management: Helm abstracts the complexity of Kubernetes configurations, making it easier to manage and deploy applications.
• Dependency Management: Helm manages dependencies between different charts, ensuring that all required services are deployed in the correct order.
• Version Control: Helm charts support versioning, which helps in tracking changes and rolling back to previous versions when needed.
• Customization: The ability to override default values allows users to customize deployments without altering the original chart.

Common Helm commands

1. helm repo add <repo-name> <repo-url>

   • Adds a Helm chart repository to your local Helm client.
   • Example: helm repo add stable https://charts.helm.sh/stable

2. helm repo update

   • Updates the local cache of the Helm chart repositories.
   • Example: helm repo update

3. helm search repo <keyword>

   • Searches for charts in the added repositories that match the given keyword.
   • Example: helm search repo nginx

4. helm install <release-name> <chart> [flags]

   • Installs a Helm chart to create a new release.
   • Example: helm install my-nginx stable/nginx-ingress

5. helm upgrade <release-name> <chart> [flags]

   • Upgrades an existing release to a new version of the chart.
   • Example: helm upgrade my-nginx stable/nginx-ingress

6. helm uninstall <release-name> [flags]

   • Uninstalls a release from the Kubernetes cluster.
   • Example: helm uninstall my-nginx

7. helm list [flags]

   • Lists all releases in the current namespace.
   • Example: helm list

8. helm status <release-name>

   • Displays the status of the specified release.
   • Example: helm status my-nginx

9. helm rollback <release-name> <revision>

   • Rolls back a release to a specific revision.
   • Example: helm rollback my-nginx 1

10. helm template <chart> [flags]

    • Generates Kubernetes manifest files from a Helm chart without actually installing the chart.
    • Example: helm template stable/nginx-ingress

11. helm show values <chart>

    • Displays the default values for a Helm chart.
    • Example: helm show values stable/nginx-ingress

12. helm get all <release-name>

    • Retrieves all information about a specific release, including values, hooks, and manifest files.
    • Example: helm get all my-nginx

13. helm package <chart-path> [flags]

    • Packages a Helm chart directory into a .tgz (tarball) file.
    • Example: helm package ./mychart

14. helm lint <chart>

    • Runs a series of tests to ensure that a chart follows best practices.
    • Example: helm lint ./mychart

15. helm test <release-name> [flags]

    • Runs tests for a release to validate its deployment.
    • Example: helm test my-nginx

16. helm dependency update [flags]

    • Updates the dependencies for a chart based on the Chart.yaml file.
    • Example: helm dependency update ./mychart

17. helm pull <chart> [flags]

    • Downloads a chart from a repository and (optionally) decompresses it.
    • Example: helm pull stable/nginx-ingress

18. helm repo list

    • Lists all the repositories that have been added.
    • Example: helm repo list

These commands cover the most common tasks you’ll perform with Helm, from managing repositories and searching for charts to installing, upgrading, and maintaining releases. Check out the official documentation page to learn more about Helm.

Good luck!

Links :

202405161033

https://helm.sh/

https://helm.sh/docs/

In Kubernetes, the relationship between nodes and pods is central to how applications are deployed and managed. Understanding what nodes and pods are, individually, helps clarify their interaction.

What are Pods?

A pod is the smallest deployable unit in Kubernetes and serves as a wrapper for one or more containers. Each pod is designed to run a single instance of a given application or service. It can contain one or multiple containers (usually Docker containers), and these containers within a pod share resources like networking and storage. Containers in the same pod can communicate with each other using localhost, as they share the same network namespace.

Pods encapsulate:

• Application containers
• Storage resources
• A unique network IP
• Options that govern how the container(s) should run

A pod is designed to run a single instance of a given application. If your application requires scaling, you create multiple instances of the same pod, each of which might be identical but isolated from others.

What are Nodes?

A node is a worker machine in a Kubernetes cluster. This machine can be either a physical computer or a virtual machine (VM) depending on the environment in which the Kubernetes cluster is deployed. Each node is managed by the master components (such as the scheduler, API server, and controller manager), which make decisions about where to place pods, monitor node and pod status, and respond to changes in the cluster. Nodes have the necessary services to run pods, including the Docker runtime and the Kubelet, which is responsible for maintaining a set of pods as specified by the Kubernetes API.

Each node in a Kubernetes cluster fulfills one or more of the following roles:

• Master Node: Runs cluster management tasks.
• Worker Node: Hosts the Pods that are the components of the application workload.

Nodes are responsible for providing the resources (CPU, memory, network, and storage) that pods need to run their applications.

Relationship between Nodes and Pods

• Nodes provide the runtime environments for pods. Each node can host multiple pods.
• Pods are assigned to nodes by the Kubernetes scheduler based on resource availability, policy, and other constraints.
• Each pod is bound to a node and remains on that node until terminated or deleted. If a node fails, the pods scheduled on that node are scheduled for deletion, and they may be recreated by the control plane on other nodes.

This relationship enables Kubernetes to manage large-scale, distributed environments efficiently, ensuring that applications are reliably available and can be scaled as needed across the various nodes in the cluster.

Links:

202405142258

Kubernetes documentation home: https://kubernetes.io/docs/home/

inkscape input.svg --export-filename=output.pdf

• Replace input.svg with the name of your SVG file and output.pdf with the desired output PDF file name.

Example use case

Say you have developed a drawing or mindmap in Excalidraw. You can export this to SVG and then run the command to convert it to PDF. Very cool!

Links :

202403241251

Why write this script?

I’m using Arch Linux (btw) and the Obsidian electron AppImage from AUR. It works great, but for some reason the obsidian git community plugin makes the app super sluggish. I removed the plugin and wrote my own bash script instead.

How the script works

• Auto-pushes Obsidian notes to GitHub via a cronjob every 30 minutes
  • crontab -e -> */30 * * * * /home/jonash/.local/bin/obsidian-sync-github
• Sends a notification via dunstify and your e-mail address of choice

#!/bin/bash

# Navigate to your repository directory
cd ~/obsidian/

# Fetch changes from remote repo and merge updates into current local branch
git pull --rebase

# Add all changes to git
git add .

# Commit the changes with a current timestamp
git commit -m "Automated commit on $(date)"

# Push the changes
git push origin main

# Send notification after the push is sent
if git push origin main; then
  # Check if dunstify is available (dunst's notification tool)
  if command -v dunstify >/dev/null 2>&1; then
    # Send a notification
    dunstify "Successfully pushed obsidian notes to GitHub!"
  else
    echo "dunstify not found, cannot send notification"
  fi
  
  # Email details
  recipient="jonash@jonash.xyz"
  subject="Subject: Obsidian Notes Push Successful"
  body="Your Obsidian notes have been successfully pushed to GitHub on $(date)"
  
  # Send the email
  echo -e "$subject\n\n$body" | msmtp "$recipient"

else
  echo "git push failed"
fi

It’s a framework written in Go , designed to convert code and content into static websites. HUGO is exceptionally fast at compiling websites, even those with thousands of pages. It is an excellent choice for projects where speed, security, and simplicity are prioritized.

Here’s how it works

HUGO takes your content, which you can write in Markdown (a lightweight markup language), and your templates, which define the structure and design of your site, and combines them to generate a complete, static website. These websites are made up of prebuilt HTML files, making them very fast to load and easy to host.

Unlike dynamic site generators that require databases to store your site’s content, HUGO works with files only. This means your website’s content and layout are defined through text files, templates, and configurations without needing a database. This simplicity leads to increased security and ease of maintenance.

HUGO is highly customizable, allowing you to create websites that range from blogs and portfolios to documentation and company websites, all while providing a wide range of themes and plugins to enhance functionality and appearance.

It offers a live reload feature, which means you can see the changes you make in real-time as you develop your site. This makes the development process more intuitive and faster.

Since HUGO generates static websites, these sites are inherently secure, fast, and reliable. They can be hosted on any web server or services like GitHub Pages, Netlify, and Vercel, often with little to no cost for hosting.

Let’s (hu)GO!

Step 1: Install HUGO

Here is the installation guide from the official documentation.

Step 2: Create a New Site

• Open a terminal or command prompt.
• Navigate to the directory where you want your site.
• Run the following command:

hugo new site mywebsite -f "yaml"

(replacing mywebsite with your desired site name)

Step 3: Add a Theme

• Find a theme you like from HUGO Themes .
• Clone the theme into your project: e.g.

git clone https://github.com/reorx/hugo-PaperModX themes/PaperModX --depth=1

• Add the theme to your site’s config file: echo 'theme : nameOfYourTheme' >> config.yml
  • e.g. echo 'theme: PaperModX' >> config.yml
  • you can remove the hugo.toml file, since we are using yaml config instead

Step 4: Add Content

• cd into the archetypes folder and replace the contents of defaults.md with the following code:

---
title : '{{ replace .File.ContentBaseName "-" " " | title }}'
date : {{ .Date }}
draft : false
---

• Create a new post:

hugo new posts/my-first-post.md

• Open the file in a text editor ( neovim btw )
• You’ll see some front matter at the top (the dashed lines)
• Add your content below the front matter
  • It’s important that you write your content in markdown format

Step 5: Start the HUGO Server

• Run hugo server in your site directory.
• Open a web browser and go to http://localhost:1313 to see your site.

Step 6: Build Your Site

• When ready to publish, run hugo to build your static site.
• The output will be in the public directory, ready to be deployed to your hosting provider.
• I have added an alias, to my .zshrc file, to update my website after building with the hugo command, with the help of rsync:

  update_website="rsync -vrP --delete-after /home/jonash/dotfiles/website/website/jonashxyz/public/ root@jonash.xyz:/var/www/jonashxyz/" \

• I got the alias from Luke Smith

• I then made the following alias to automate the building and deploying:

alias hugo="hugo && update_website" \

• It’s amazing.

Congratulations!

You’ve just created a website with HUGO.

For more detailed instructions, visit the official HUGO documentation .

Also, read the documentation of your chosen theme, e.g. PaperModX .

Good luck!

Links:

202403081313

https://go.dev/

https://gohugo.io/

https://en.wikipedia.org/wiki/Markdown

GRUB is a boot loader, which lets you boot up your system. The abbreviation stands for GNU GRand Unified Bootloader, and is a boot loader package from the GNU Project. GRUB is the primary bootloader for many Linux distributions, allowing users to choose from multiple operating systems or different versions of the same operating system at boot time. It’s designed to be highly configurable and supports a wide range of operating systems, not just Linux.

GRUB features include:

• The ability to boot multiple operating systems, including Linux, Windows, and macOS.
• Support for reading data from various file systems, allowing it to load boot files from these file systems directly.
• A flexible and powerful command-line interface that can be used to troubleshoot boot issues.
• The capability to load operating systems from a network, which is particularly useful in managed IT environments.
• A customizable menu interface that can display graphics and themes, allowing for a visually appealing boot menu.

GRUB has evolved over time, with GRUB 2 being the successor to the original GRUB (referred to as GRUB Legacy). GRUB 2 offers improved modularity, portability, and features compared to its predecessor.

Why make this guide?

The reason I made this simple guide is to help myself remember how to set up grub bootloader in Arch Linux installation guide, chapter 3.8 .

Installing GRUB EFI in Arch Linux

First off, we install some packages:

sudo pacman -S vim networkmanager grub efibootmgr dosfstools os-prober mtools

(Networkmanager is optional, but highly recommended)

EnableNetworkManager

systemctl enable NetworkManager

Mount EFI-partition

mount --mkdir /dev/drive /boot/EFI

Install GRUB

grub-install --target=x86_64-efi --bootloader-id=grub_uefi --efi-directory=/boot/EFI --no-nvram --removable --recheck

Make grub config file

grub-mkconfig -o /boot/grub/grub.cfg

Reboot

• Exit the chroot environment by typing exit or pressing Ctrl+d.
• Optionally manually unmount all the partitions with umount -R /mnt: this allows noticing any “busy” partitions, and finding the cause
• Finally, restart the machine by typing reboot: any partitions still mounted will be automatically unmounted by systemd.
• Remember to remove the installation medium and then login into the new system with the root account

Links:

https://www.gnu.org/software/grub/

https://wiki.archlinux.org/title/Installation_guide#Boot_loader

• fd is a simple and fast file search tool, enhancing the Unix find command.
• lsd is a modern replacement for ls, enhancing file listing with better defaults.
• dog is a modern, feature-rich DNS client for the command-line.
• ncdu is a console disk usage analyzer for quick space management.
• bat is a cat clone with syntax highlighting and Git integration for the command-line.
• sd is a simple and intuitive find-and-replace CLI tool, aiming to improve upon sed.
• dust visualizes disk usage with an emphasis on clarity, acting as a more intuitive du.
• xh is a friendly and fast HTTP client for the terminal, inspired by curl and HTTPie.
• duf is a modern disk usage utility for the command-line with an intuitive interface.

• Communication
• Collaboration
• Integration
• Automation

The goal of DevOps is to improve and speed up the delivery of software applications and services. By fostering a culture where building, testing, and releasing software can happen rapidly, frequently, and more reliably, DevOps has become a key practice in the software industry.

Key Principles of DevOps

• Continuous Integration (CI): Developers merge their changes back to the main branch as often as possible. Automated tests run with these integrations to catch bugs quickly.

• Continuous Delivery (CD): This practice involves automatically deploying all code changes to a testing or staging environment after the build stage. It ensures that the software can be reliably released at any time.

• Automated Testing: Automation in testing reduces manual workload and speeds up the process of software development and deployment.

• Infrastructure as Code (IaC): Managing and provisioning infrastructure through code instead of through manual processes, improving operational efficiency and cloud management.

• Monitoring and Logging: Keeping track of the performance of applications and infrastructure to quickly respond to issues.

• Collaboration and Communication: Encouraging open communication and collaboration within and between teams to enhance the development process.

Benefits of DevOps

• Faster Time to Market: Shortened development cycles lead to faster innovation and a quicker time to market.

• Improved Collaboration: Breaking down silos between teams enhances collaboration and efficiency.

• Increased Efficiency: Automation and streamlined workflows increase the efficiency of the development and deployment processes.

• Enhanced Quality: Continuous integration and delivery ensure that quality is maintained through frequent code updates and testing.

• Higher Customer Satisfaction: Rapid deliveries of updates and new features lead to higher customer satisfaction.

DevOps is not just a set of practices, but a culture that needs to be adopted for its full potential to be realized. By embracing DevOps, organizations can enhance their ability to deliver applications and services at high velocity, thereby outpacing their competitors in today’s fast-paced digital world.