schnell18

#!/usr/bin/env python

import re
import sys

HEADER = r"""
\documentclass{article}
\usepackage{booktabs,makecell,multirow,threeparttable,diagbox}
\usepackage{caption}

schnell18

#!/bin/bash

# limactl start \
#   --name=k8s \
#   --cpus=6 \
#   --memory=8 \
#   --vm-type=vz \
#   --rosetta \
#   --mount-type=virtiofs \
#   --mount-writable \

schnell18

# Review and modify the following configuration for Lima instance "k8s".
# - To cancel starting Lima, just save this file as an empty file.

# Deploy kubernetes via kubeadm.
# $ limactl start ./k8s.yaml
# $ limactl shell k8s kubectl

# It can be accessed from the host by exporting the kubeconfig file;
# the ports are already forwarded automatically by lima:
#

schnell18

#!/usr/bin/env python

import re

import requests

url = "https://raw.githubusercontent.com/rshkarin/mason-nvim-lint/910dadb99cb2bf0d5176026c7a4ab1861c4e561f/lua/mason-nvim-lint/mapping.lua"

if __name__ == "__main__":
    try:

schnell18

sudo dd if=xxx.iso of=/dev/sdX bs=4M conv=fsync oflag=direct status=progress

schnell18

curl https://pyenv.run | bash
sudo apt install -y \
    wget \
    build-essential \
    libreadline-dev \
    libncursesw5-dev \
    libssl-dev \
    libsqlite3-dev \
    tk-dev \
    libgdbm-dev \

schnell18

openssl s_client -connect www.example.com:443 </dev/null 2>/dev/null | openssl x509 -inform pem -text

schnell18

gist of consistent hashing

Resolve rebalance problem of dynamic cluster. Key techniques:

• determine hash space, eg 2 * PI or 16K like redis
• map keys and nodes to the same hash space using hash function(s)
• keys are placed on the first node with hash value greater than the key, or on the first node
• use binary search tree to speed up locating the node for a paticular key
• when new node joins, move keys with hash value smaller than the new node from its successor to the node
• when existing node leaves, move keys on this node to its successor

schnell18

# virtualbox 6.1.36 and vagrant 2.3.0 are broken
# instruction to downgrade to working versions

curl https://archive.archlinux.org/packages/v/virtualbox/virtualbox-6.1.32-2-x86_64.pkg.tar.zst -o virtualbox-6.1.32-2-x86_64.pkg.tar.zst
sudo pacman -U virtualbox-6.1.32-2-x86_64.pkg.tar.zst

curl https://archive.archlinux.org/packages/v/virtualbox-guest-iso/virtualbox-guest-iso-6.1.32-1-any.pkg.tar.zst -o virtualbox-guest-iso-6.1.32-1-any.pkg.tar.zst
sudo pacman -U virtualbox-guest-iso-6.1.32-1-any.pkg.tar.zst

curl https://archive.archlinux.org/packages/v/vagrant/vagrant-2.2.19-2-x86_64.pkg.tar.zst -o vagrant-2.2.19-2-x86_64.pkg.tar.zst

schnell18

Jobs or pipelines run unexpectedly when using changes:

You might have jobs or pipelines that run unexpectedly when using rules: changes
or only: changes without
merge request pipelines.
Pipelines on branches or tags that don't have an explicit association with a merge request
use a previous SHA to calculate the diff. This calculation is equivalent to git diff HEAD~
and can cause unexpected behavior, including:

The changes rule always evaluates to true when pushing a new branch or a new tag to GitLab.