about summary refs log tree commit diff
path: root/content/notes
diff options
context:
space:
mode:
Diffstat (limited to 'content/notes')
-rw-r--r--content/notes/containerd-to-firecracker.md22
-rw-r--r--content/notes/making-sense-intel-amd-cpus.md20
-rw-r--r--content/notes/stuff-about-pcie.md10
-rw-r--r--content/notes/working-with-go.md30
-rw-r--r--content/notes/working-with-nix.md8
5 files changed, 45 insertions, 45 deletions
diff --git a/content/notes/containerd-to-firecracker.md b/content/notes/containerd-to-firecracker.md
index b64586b..2159598 100644
--- a/content/notes/containerd-to-firecracker.md
+++ b/content/notes/containerd-to-firecracker.md
@@ -28,7 +28,7 @@ this. I've been meaning to look into Firecracker for a while and into
 containers'd API, so this is a perfect opportunity to get started. The
 code is available [here](https://github.com/fcuny/containerd-to-vm).
 
-# #1 Pull a container from a registry with `containerd`
+## #1 Pull a container from a registry with `containerd`
 
 `containerd` has a pretty [detailed
 documentation](https://pkg.go.dev/github.com/containerd/containerd).
@@ -73,7 +73,7 @@ with:
 docker.io/library/redis:latest
 ```
 
-# #2 Create a loop device to store the container's filesystem on
+## #2 Create a loop device to store the container's filesystem on
 
 This is going to be pretty straightforward. To create a loop device we
 need to:
@@ -132,7 +132,7 @@ if err := command.Run(); err != nil {
 }
 ```
 
-# #3 Unpack the container into the mounted loop device
+## #3 Unpack the container into the mounted loop device
 
 Extracting the container using `containerd` is pretty simple. Here's the
 function that I use:
@@ -166,7 +166,7 @@ making a number of assumptions regarding their type (we should be
 checking the media type first). We read the layers and extract them to
 the mounted path.
 
-# #4 Create a second block device and inject other stuff
+## #4 Create a second block device and inject other stuff
 
 Here I'm going to deviate a bit. I will not create a second loop device,
 and I will not inject a kernel. In their article, they provided a link
@@ -179,7 +179,7 @@ files to container (`/etc/hosts` and `/etc/resolv.conf`).
 Finally, since we've pre-allocated 2GB for that container, and we likely
 don't need that much, we're also going to resize the image.
 
-## Add init
+### Add init
 
 Let's refer to the [specification for the
 config](https://github.com/opencontainers/image-spec/blob/master/config.md).
@@ -247,14 +247,14 @@ We're once again creating a temporary file with `renamio`, and we're
 writing our shell scripts, one line at a time. We only need to make sure
 this executable.
 
-## extra files
+### extra files
 
 Once we have our init file, I also want to add a few extra files:
 `/etc/hosts` and `/etc/resolv.conf`. This files are not always present,
 since they can be injected by other systems. I also want to make sure
 that DNS resolutions are done using my own DNS server.
 
-## resize the image
+### resize the image
 
 We've pre-allocated 2GB for the image, and it's likely we don't need as
 much space. We can do this by running `e2fsck` and `resize2fs` once
@@ -281,7 +281,7 @@ with the following size for the image:
 -rw------- 1 root root 216M Apr 22 14:50 /tmp/fcuny.img
 ```
 
-## Kernel
+### Kernel
 
 We're going to need a kernel to run that VM. In my case I've decided to
 go with version 5.8, and build a custom kernel. If you are not familiar
@@ -301,11 +301,11 @@ make vmlinux -j8
 Note that they also have a pretty [good documentation for
 production](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md).
 
-# #5 Attach persistent volumes (if any)
+## #5 Attach persistent volumes (if any)
 
 I'm going to skip that step for now.
 
-# #6 Create a TAP device and configure it
+## #6 Create a TAP device and configure it
 
 We're going to need a network for that VM (otherwise it might be a bit
 boring). There's a few solutions that we can take:
@@ -351,7 +351,7 @@ in `etc/cni/conf.d/50-c2vm.conflist`:
 }
 ```
 
-# #7 Hand it off to Firecracker and boot that thing
+## #7 Hand it off to Firecracker and boot that thing
 
 Now that we have all the components, we need to boot that VM. Since I've
 been working with Go so far, I'll also use the [Go
diff --git a/content/notes/making-sense-intel-amd-cpus.md b/content/notes/making-sense-intel-amd-cpus.md
index 22633af..988bcb3 100644
--- a/content/notes/making-sense-intel-amd-cpus.md
+++ b/content/notes/making-sense-intel-amd-cpus.md
@@ -7,9 +7,9 @@ tags:
   - cpu
 ---
 
-# Intel
+## Intel
 
-## Core
+### Core
 
 The line up for the core family is i3, i5, i7 and i9. As of December
 2021, the current generation is Alder Lake (12th generation).
@@ -51,7 +51,7 @@ List of suffixes:
 > is made with the an unlocked clock multiplier. When used with some
 > specific chipset, it's possible to overclock the processor.
 
-### Sockets/Chipsets
+#### Sockets/Chipsets
 
 For the Alder Lake generation, the supported socket is the
 [LGA<sub>1700</sub>](https://en.wikipedia.org/wiki/LGA_1700).
@@ -101,7 +101,7 @@ performance or efficiency).
 As of December 2021 this is not yet properly supported by the Linux
 kernel.
 
-## Xeon
+### Xeon
 
 Xeon is the brand of Intel processor designed for non-consumer servers
 and workstations. The most recent generations are:
@@ -117,9 +117,9 @@ The following brand identifiers are used:
 -   silver
 -   bronze
 
-# AMD
+## AMD
 
-## Ryzen
+### Ryzen
 
 There are multiple generation for this brand of processors. They are
 based on the [zen micro
@@ -145,14 +145,14 @@ List of suffixes:
 | U      | standard mobile                            |
 | M      | low power mobile                           |
 
-## EPYC
+### EPYC
 
 EPYC is the AMD brand of processors for the server market, based on the
 zen architecture. They use the
 [SP3](https://en.wikipedia.org/wiki/Socket_SP3) socket. The EPYC
 processor is chipset free.
 
-## Threadripper
+### Threadripper
 
 The threadripper is for high performance desktop. It uses the
 [TR4](https://en.wikipedia.org/wiki/Socket_TR4) socket. At the moment
@@ -162,7 +162,7 @@ there's only one chipset that supports this process, the
 The threadripper based on zen3 architecture is not yet released, but
 it's expected to hit the market in the first half of Q1 2022.
 
-## Sockets/Chipsets
+### Sockets/Chipsets
 
 The majority of these processors use the [AM4
 socket](https://en.wikipedia.org/wiki/Socket_AM4). The threadripper line
@@ -174,7 +174,7 @@ socket. The more advanced ones are the B550 and the X570.
 
 The threadripper processors use the TR4, sTRX4 and sWRX8 sockets.
 
-## Zen 3
+### Zen 3
 
 Zen 3 was released in November 2020.
 
diff --git a/content/notes/stuff-about-pcie.md b/content/notes/stuff-about-pcie.md
index a3644f1..022cfd6 100644
--- a/content/notes/stuff-about-pcie.md
+++ b/content/notes/stuff-about-pcie.md
@@ -6,7 +6,7 @@ tags:
   - harwdare
 ---
 
-# Speed
+## Speed
 
 The most common versions are 3 and 4, while 5 is starting to be
 available with newer Intel processors.
@@ -39,7 +39,7 @@ If we apply the formula, for a PCIe version 3 device we can expect
 
     8GT/s * 4 lanes * (1 - 2/130) - 1G = 32G * 0.985 - 1G = ~30Gb/s -> 3750MB/s
 
-# Topology
+## Topology
 
 The easiest way to see the PCIe topology is with `lspci`:
 
@@ -75,12 +75,12 @@ The easiest way to see the PCIe topology is with `lspci`:
                +-18.6  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 6
                \-18.7  Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7
 
-# View a single device
+## View a single device
 
     $ lspci -s 0000:01:00.0
     01:00.0 Non-Volatile memory controller: OCZ Technology Group, Inc. RD400/400A SSD (rev 01)
 
-# Reading `lspci` output
+## Reading `lspci` output
 
     $ sudo lspci -vvv -s 0000:01:00.0
     01:00.0 Non-Volatile memory controller: OCZ Technology Group, Inc. RD400/400A SSD (rev 01) (prog-if 02 [NVM Express])
@@ -165,7 +165,7 @@ A few things to note from this output:
     (here, we can use 4 lanes)
 -   **MaxPayload** is the maximum size of a PCIe packet
 
-# Debugging
+## Debugging
 
 PCI configuration registers can be used to debug various PCI bus issues.
 
diff --git a/content/notes/working-with-go.md b/content/notes/working-with-go.md
index b5e690e..af7bf20 100644
--- a/content/notes/working-with-go.md
+++ b/content/notes/working-with-go.md
@@ -8,14 +8,14 @@ tags:
 
 *This document assumes go version \>= 1.16*.
 
-# Go Modules
+## Go Modules
 
 [Go modules](https://blog.golang.org/using-go-modules) have been added
 in 2019 with Go 1.11. A number of changes were introduced with [Go
 1.16](https://blog.golang.org/go116-module-changes). This document is a
 reference for me so that I can find answers to things I keep forgetting.
 
-## Creating a new module
+### Creating a new module
 
 To create a new module, run `go mod init golang.fcuny.net/m`. This will
 create two files: `go.mod` and `go.sum`.
@@ -26,7 +26,7 @@ In the `go.mod` file you'll find:
 -   the list of dependencies (within `require`)
 -   the version of go to use for the module
 
-## Versioning
+### Versioning
 
 To bump the version of a module:
 
@@ -41,11 +41,11 @@ Then as a user:
 $ go get -d golang.fcuny.net/m@v1.2.3
 ```
 
-## Updating dependencies
+### Updating dependencies
 
 To update the dependencies, run `go mod tidy`
 
-## Editing a module
+### Editing a module
 
 If you need to modify a module, you can check out the module in your
 workspace (`git clone <module URL>`).
@@ -62,13 +62,13 @@ project, the cloned module will be used.
 This is particularly useful when trying to debug an issue with an
 external module.
 
-## Vendor-ing modules
+### Vendor-ing modules
 
 It's still possible to vendor modules by running `go mod vendor`. This
 can be useful in the case of a CI setup that does not have access to
 internet.
 
-## Proxy
+### Proxy
 
 As of version 1.13, the variable `GOPROXY` defaults to
 `https://proxy.golang.org,direct` (see
@@ -151,33 +151,33 @@ require (
 
 # Tooling
 
-## LSP
+### LSP
 
 `gopls` is the default implementation of the language server protocol
 maintained by the Go team. To install the latest version, run
 `go install golang.org/x/tools/gopls@latest`
 
-## `staticcheck`
+### `staticcheck`
 
 [`staticcheck`](https://staticcheck.io/) is a great tool to run against
 your code to find issues. To install the latest version, run
 `go install honnef.co/go/tools/cmd/staticcheck@latest`.
 
-# Emacs integration
+## Emacs integration
 
-## `go-mode`
+### `go-mode`
 
 [This is the mode](https://github.com/dominikh/go-mode.el) to install to
 get syntax highlighting (mostly).
 
-## Integration with LSP
+### Integration with LSP
 
 Emacs has a pretty good integration with LSP, and ["Eglot for better
 programming experience in
 Emacs"](https://whatacold.io/blog/2022-01-22-emacs-eglot-lsp/) is a good
 starting point.
 
-### eglot
+#### eglot
 
 [This is the main mode to install](https://github.com/joaotavora/eglot).
 
@@ -199,9 +199,9 @@ The configuration is straightforward, this is what I use:
 `eglot` integrates well with existing modes for Emacs, mainly xref,
 flymake, eldoc.
 
-# Profiling
+## Profiling
 
-## pprof
+### pprof
 
 [pprof](https://github.com/google/pprof) is a tool to visualize
 performance data. Let's start with the following test:
diff --git a/content/notes/working-with-nix.md b/content/notes/working-with-nix.md
index 9e697d5..3d208e4 100644
--- a/content/notes/working-with-nix.md
+++ b/content/notes/working-with-nix.md
@@ -6,7 +6,7 @@ tags:
   - nix
 ---
 
-# the `nix develop` command
+## the `nix develop` command
 
 The `nix develop` command is for working on a repository. If our
 repository contains a `Makefile`, it will be used by the various
@@ -26,9 +26,9 @@ they map as follow:
 In the repository, running `nix develop --build` will build the binary
 **using the Makefile**. This is different from running `nix build`.
 
-# the `nix build` and `nix run` commands
+## the `nix build` and `nix run` commands
 
-## for Go
+### for Go
 
 For Go, there's the `buildGoModule`. Looking at the
 [source](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/go-modules/generic/default.nix)
@@ -38,7 +38,7 @@ a result, we don't have to define them ourselves.
 If we run `nix build` in the repository, it will run the default [build
 phase](https://github.com/NixOS/nixpkgs/blob/fb7287e6d2d2684520f756639846ee07f6287caa/pkgs/development/go-modules/generic/default.nix#L171).
 
-# `buildInputs` or `nativeBuildInputs`
+## `buildInputs` or `nativeBuildInputs`
 
 -   `nativeBuildInputs` is intended for architecture-dependent
     build-time-only dependencies