Unlaunching Prompts

#site  #updates 

What happend to the prompts?

Prompts were an interesting concept but I’ve decided not to pursue them at this time. This is mainly a choice in how I want to spend my time.

At the end of the day, what do I want to accomplish? My main goal is to produce applications and libraries. Prompts would take my focus away from this goal.

Building Containers Images with Nerdctl

#containers  #rancher desktop 

The basic commands are nearly identical to the commands you would use to build a container with dockerd(moby). The main difference is that unlike dockerd, containers built with nerdctl are not available in Kubernetes by default.

To build a container that is available in Kubernetes you must specify the k8s.io namespace


# -n specifies the k8s.io namespace
nerdctl -n k8s.io build . -f containerfile -t app:0.0.1
# the container is visible inside Kubernetes
kubectl create deployment quick-test --image=app:0.0.1

How to determine available resources in a container

#linux  #containers  #kubernetes  #cgroup 

Linux distributes system resources using control groups (cgroup) which the kernel.org defines as

cgroup is a mechanism to organize processes hierarchically and distribute system resources along the hierarchy in a controlled and configurable manner. [1]

There are currently two versions of cgroup in use today and due to historical and compatibility reasons version 1 and version 2 of cgroups can coexist as long as there are no overlaps between which controllers are being managed.

The main, but not only, difference between cgroup version 1 and version 2 is that version 1 has a mount for each controller while version 2 unifies all the active controllers under a single mount point. This is obviously a very simplified explanation. Please see the official kernel documentation for more details on the two versions [2][3].

They typical mount point for both versions of cgroup is /sys/fs/cgroup. This is not a hard requirement and can be different depending on the distro. For instance Alpine Linux with OpenRC in hybrid mode will mount cgroup version 1 at /sys/fs/cgroup and version 2 at /sys/fs/cgroup/unified.

This table will assume that the cgroup root path is /sys/fs/cgroup and will use relative paths based on that. Adjust the relative paths based on your environment.

resource cgroup v1 cgroup v2
available memory ./memory/memory.limit_in_bytes ./memory.max
assigned cpu cores ./cpuset/cpuset.effective_cpus ./cpuset.effective.cpus
cpu bandwidth ./cpu/cpu.cfs_quota_us ./cpu.max
cpu period ./cpu/cpu.cfs_period_us ./cpu.max

Refer to the documentation for the format for each file.

To determine which cgroup your application belongs to you can reference /proc/self/cgroup which will list all the cgroup that your process belongs to. Depending on the environment you may also need to map your cgroup to the actual mount point by inspecting /proc/self/mountinfo. This is especially true if running inside a container where the cgroup may refer to the path on the host and may not be accurate when viewed inside the container.

Asking the Right Question

#linux  #containers  #cgroup  #programming  #cpp  #rust 

How many cores are on my system?

This is a seemingly simple question. We’d like to use the number of available processors to determine how many jobs we can safely run in parallel. Linux provides various ways to fetch the number of available processors including:

  • nproc
  • lscpu
  • /proc/cpuinfo

> nproc 
32

> lscpu | grep ^CPU\(s\)\: | awk '{print $2}'
32

> grep --count "processor" /proc/cpuinfo
32
Read more →

Introducing Prompts [closed: won’t do]

#site  #updates 

I’ve been thinking about ways to be more active in my Rust exploration and I think that I’ve settled on the idea of Prompts.

Prompts are project-based learning experiments where I will explore Rust concepts, crates, or tools. The prompts should be narrow enough in scope that they can be completed in about a week. While only spending at most an hour a day.

The prompts will include

  • a goal - what I am trying to learn
  • description - the scenario I am working under
  • constraints - ensures the project can be scoped to a few days or a weeks worth of work
  • models - the minimal high level objects I want to represent
  • acceptance criteria - what I consider is done

More importantly prompts should not be

  • so difficult or complex as to be discouraging.
  • gotchas or brain busters

Complex topics should be the subject of their own prompt and broken down appropriately so that they may fit into the above criteria.