The version of containerd
that OpenFaaS
will download during the
installation doesn't support cgroup v2, so we need to configure
systemd
to avoid using the Unified cgroup Hierarchy, and reboot the
system:
From 96d52b6e40060c104cd4e08c2fab73ad1a899fba Mon Sep 17 00:00:00 2001 | |
From: Sergio Lopez <[email protected]> | |
Date: Mon, 18 Jul 2022 13:51:24 +0200 | |
Subject: [PATCH 1/4] Update vendor of containers/storage | |
Backport 39880517a19ffde1ca2fca5f29cb051309e56773 from the main | |
branch. | |
Signed-off-by: Sergio Lopez <[email protected]> | |
--- |
flatpak --user install flathub org.mozilla.firefox
flatpak run org.mozilla.firefox
# Personalize the browser, log in to the places you
# want to visit with your own account, and quit it.
# Save a copy of the app's data directory to use it
# as a template.
cp -a $HOME/.var/app/org.mozilla.firefox \
I hereby claim:
- I am slp on github.
- I am slpnix (https://keybase.io/slpnix) on keybase.
- I have a public key ASB2otsGKzZEFFPxwpuoQ0ZXOVqZ6DMEAMpnb_fNVDtQ8Ao
To claim this, I am signing this object:
# | |
# Automatically generated file; DO NOT EDIT. | |
# Linux/x86 5.3.0-rc3 Kernel Configuration | |
# | |
# | |
# Compiler: gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1) | |
# | |
CONFIG_CC_IS_GCC=y | |
CONFIG_GCC_VERSION=90101 |
This morning, my laptop got stuck for a minute during boot in the typical waiting for... message coming from systemd.
Of course, the easiest and funniest approach here would be blaming systemd and writing an angry tweet about how it sucks, but let's see if we can do better.
First, once the system booted, let's find out which services failed:
[localhost ~]$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● systemd-udev-settle.service loaded failed failed udev Wait for Complete Device Initialization
[root@rhel74-docker ~]# docker run -ti --rm alpine
Unable to find image 'alpine:latest' locally
Trying to pull repository registry.access.redhat.com/alpine ...
Trying to pull repository docker.io/library/alpine ...
latest: Pulling from docker.io/library/alpine
88286f41530e: Pull complete
Digest: sha256:1072e499f3f655a032e88542330cf75b02e7bdf673278f701d7ba61629ee3ebe
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
Running on KVM (4.4.0-21-generic/qemu-2.5.0). | |
Test computes cost of write() and read() moving 16384 x 4K blocks. | |
Filesystem is tmpfs for Linux and GNU Hurd (translator), memfs for Magenta. | |
Magenta (014c20cb2b99f1ec80c8d244c243bf17cf1f134f) | |
================================================== | |
elapsed time: 900.43 ms cost per call: 54.96 us |
Running on Raspberry Pi 3. | |
Test computes cost of write() and read() moving 16384 x 4K blocks. | |
Filesystem is tmpfs for Linux and memfs for Magenta. | |
Magenta (3e34cf26a478ca07dd620e741e2140a9a6b7fd8b) | |
================================================== | |
elapsed time: 1987.18 ms cost per call: 121.29 us |
This document is a draft. This information may be incomplete and/or inaccurate
After reading an article on Hacker News about Google's Fuchsia OS, I decided to take a look at its microkernel, Magenta.
I always had an interest on microkernels, and over the years I've read a lot of code from Mach variants, L4 family, MINIX 3, HelenOS, and so on. I even maintain a MkLinux (OSFMach+Linux) repo to preserve its code (https://github.com/slp/mkunity) and made minor contributions to GNU Mach and GNU Hurd.
I'm also curious about Google's approach with Magenta because writing a pure microkernel in the era of SSDs and 10 Gbps interfaces, is one the most challenging tasks you can find. To be able to extract the full potential of such devices, you need to both find the shortest possible path from user application to device (that is, keeping the lowest CPU induced latency) and being able to parallelize the IO load without compromises.