HM0008

HM0008 のホスティング

Sun, 15 Feb 2026 12:38:18 GMT

HM0008 のホスティング

#index #deployment

このサイト (HM0008) は静的サイト (static site) として、家の SBC 上にホスティングされている。このページでは、このシステムの技術的な要素について概観する。

技術的な要素

md-html コンパイラ

本サイトのすべてのページの内容は markdown ファイルに記載している。このため、 markdown ファイルを html ファイルに変換する必要がある。そこで、この変換を行うコンパイラを書いた。

生成された HTML を SBC にデプロイしている。これには以下の機能を利用する。

web サーバー: 今回は static-web-server (sws) を利用した。 nginx などでも問題ない。
git hook: 簡素な継続的デプロイメント (continuous deployment; CD) を実現するために利用した。
cloudflare access: sws のポートを公開するために利用した。
podman-systemd (quadlet): sws と cloudflared (cloudflare acess のクライアント) のコンテナを systemd サービス化するために利用した。

各要素の詳細

#public

Git hook (post-receive) による継続的デプロイメント

Sun, 15 Feb 2026 12:38:18 GMT

Git hook (post-receive) による継続的デプロイメント

#git #deployment

このページでは、 post-receive の使い方を記載する。

Git hooks と `post-receive` の概要

Git hooks (日本語 ) 機能を利用することで、いくつかの git 操作の前後にスクリプトを実行できる。この post-receive hook は git push の受け取り (receive) が完了すると発火されるものである。 post-receive にデプロイ処理を記述しておくことで、 git push された内容を継続的にデプロイすることが可能である。

前提: `git push` する側、される側の準備

`git push` する側

git push を行う remote repository の登録が必要。 ssh 経由で push する場合は以下:

git remote add <remote name> ssh://<user>@<address>:<path to repository>

`git push` される側 (受け取り側)

デプロイされる側も Git リポジトリが必要である。受け取り側のマシンで git init しておく。その後、 .git/hooks/ ディレクトリの配下に post-receive ファイルを作成する。

例:

git init
$EDITOR .git/hooks/post-receive

例: HM0008 のデプロイにおける post-receive の利用

HM0008 のホスティングに関するリポジトリの post-receive では以下を実施した。

working tree の更新 (push された内容の checkout)
必要なデプロイ操作: markdown ファイルを html ファイルへ変換、 systemd サービスのリロードなど

working tree の更新:

unset GIT_DIR
unset GIT_WORK_TREE
unset GIT_INDEX_FILE
unset GIT_QUARANTINE_PATH

# ----------------------
# DEPLOY
# ----------------------

# checkout the latest states
echo "Checking out latest default branch..."
for dir in $SCRIPT_DIR $COMPILER_DIR $QUADLET_CONFIG_DIR  $MARKDOWN_DIR; do
  echo "- $dir"
  git -C $dir checkout -f default || exit 1
done
echo "DONE"
echo

メモ:

hook 実行時に、いくつか環境変数が設定される (GIT_DIR など) 。 hook 内で git 操作をする場合には考慮が必要。
- 今回はそれらを unset している

コンパイラや、 markdown ファイルのリポジトリに git push された場合:

  echo "Building sinter..."
  pushd $COMPILER_DIR
  cargo build --release --quiet || exit 1
  echo "DONE"
  echo

  # recreate target directory
  rm -r $HTML_TARGET_DIR
  mkdir -p $HTML_TARGET_DIR

  echo "Compiling markdown files..."
  # compile markdown files to html
  cargo run --release \
     --quiet \
     -- \
     --input $MARKDOWN_DIR \
     --output $HTML_TARGET_DIR \
     --templates $COMPILER_DIR/templates \
     --config $CONFIG_FILE || exit 1
  popd
  systemctl --user restart zettel-pod.service || exit 1
  echo "DONE"
  echo

pod ファイルも git push でデプロイしている:

  echo "Updating unit files..."
  # copy unit files
  cp -v $QUADLET_CONFIG_DIR/*.pod $SYSTEMD_DIR || exit 1
  cp -v $QUADLET_CONFIG_DIR/*.container $SYSTEMD_DIR || exit 1
  echo "DONE"
  echo

  echo "Reloading systemd services..."
  # reload systemd
  systemctl --user daemon-reload || exit 1
  systemctl --user restart zettel-pod.service || exit 1
  echo "DONE"
  echo

メモ

pre-receive を使うと、 push 前に CI に相当する操作もできそう
pre-receive や pre-commit では、 exit 1 (正確には、 0 以外の exit status でスクリプトを終了) することで、 push / commit を abort できるようだ

#public

ベランダの音 (2026-02-08)

Mon, 09 Feb 2026 08:50:59 GMT

ベランダの音 (2026-02-08)

#fieldrecording

日時: 2026-02-08 10時頃
場所: 家のベランダ
音:
- 雪融け水が落ちる音
- 近所の音
- 建物の先にある幹線道路の音
コメント: 前日の夜から雪が降っていて、珍しく積もった

Your browser does not support the audio element.

メモ: 音声加工の記録

> ffprobe -i 260208_0033.wav -show_entries format=duration -v quiet -of csv="p=0"
3814.344000

> ffmpeg -i 260208_0033.wav -filter:a volumedetect -f null - 2>&1 | grep "volume:"
[Parsed_volumedetect_0 @ 0x7f06f4003dc0] mean_volume: -54.6 dB
[Parsed_volumedetect_0 @ 0x7f06f4003dc0] max_volume: -17.6 dB

> ffmpeg -i 260208_0033.wav -ss 30 -to 3600 -af "volume=16.5dB,afade=t=in:st=30:d=5,afade=t=out:st=3595:d=5" 260208_0033_processed.wav -y
ffmpeg version n8.0.1 Copyright (c) 2000-2025 the FFmpeg developers
  built with gcc 15.2.1 (GCC) 20260103
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      60.  8.100 / 60.  8.100
  libavcodec     62. 11.100 / 62. 11.100
  libavformat    62.  3.100 / 62.  3.100
  libavdevice    62.  1.100 / 62.  1.100
  libavfilter    11.  4.100 / 11.  4.100
  libswscale      9.  1.100 /  9.  1.100
  libswresample   6.  1.100 /  6.  1.100
[aist#0:0/pcm_f32le @ 0x55cd650d9f80] Guessed Channel Layout: stereo
Input #0, wav, from '260208_0033.wav':
  Metadata:
    encoded_by      : TASCAM Portacapture X8
    date            : 2026-02-08
    creation_time   : 12:03:14
    time_reference  : 1899789696
    coding_history  : T=XRI 008c;XRI VER=0002;MAKER=TASCAM;MODEL=X8;FW VER=2.01;SOURCE=1:INT MIC,2:INT MIC;INPUT GAIN=1:HIGH,2:HIGH;LEVEL=1:29,2:29;AUTO_LEVEL=1:OFF,2:OFF;,
  Duration: 01:03:34.34, bitrate: 3072 kb/s
  Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, flt, 3072 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_f32le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to '260208_0033_processed.wav':
  Metadata:
    ITCH            : TASCAM Portacapture X8
    ICRD            : 2026-02-08
    coding_history  : T=XRI 008c;XRI VER=0002;MAKER=TASCAM;MODEL=X8;FW VER=2.01;SOURCE=1:INT MIC,2:INT MIC;INPUT GAIN=1:HIGH,2:HIGH;LEVEL=1:29,2:29;AUTO_LEVEL=1:OFF,2:OFF;,
    time_reference  : 1899789696
    ISFT            : Lavf62.3.100
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
    Metadata:
      encoder         : Lavc62.11.100 pcm_s16le
[out#0/wav @ 0x55cd650da1c0] video:0KiB audio:669375KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000019%
size=  669375KiB time=00:59:30.00 bitrate=1536.0kbits/s speed=8.61e+03x elapsed=0:00:00.41

> ffmpeg -i 260208_0033_processed.wav -filter:a volumedetect -f null - 2>&1 | grep "volume:"
[Parsed_volumedetect_0 @ 0x7f3cd4003dc0] mean_volume: -38.3 dB
[Parsed_volumedetect_0 @ 0x7f3cd4003dc0] max_volume: -1.1 dB

> ffmpeg -i 260208_0033_processed.wav -codec:a libmp3lame -b:a 320k 260208_0033_processed.mp3 -y
ffmpeg version n8.0.1 Copyright (c) 2000-2025 the FFmpeg developers
  built with gcc 15.2.1 (GCC) 20260103
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      60.  8.100 / 60.  8.100
  libavcodec     62. 11.100 / 62. 11.100
  libavformat    62.  3.100 / 62.  3.100
  libavdevice    62.  1.100 / 62.  1.100
  libavfilter    11.  4.100 / 11.  4.100
  libswscale      9.  1.100 /  9.  1.100
  libswresample   6.  1.100 /  6.  1.100
Input #0, wav, from '260208_0033_processed.wav':
  Metadata:
    date            : 2026-02-08
    encoder         : Lavf62.3.100
    encoded_by      : TASCAM Portacapture X8
  Duration: 00:59:30.00, bitrate: 6144 kb/s
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 192000 Hz, stereo, s16, 6144 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
Output #0, mp3, to '260208_0033_processed.mp3':
  Metadata:
    TDRC            : 2026-02-08
    TENC            : TASCAM Portacapture X8
    TSSE            : Lavf62.3.100
  Stream #0:0: Audio: mp3, 48000 Hz, stereo, s16p, 320 kb/s
    Metadata:
      encoder         : Lavc62.11.100 libmp3lame
[out#0/mp3 @ 0x55af036ddbc0] video:0KiB audio:139454KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000742%
size=  139455KiB time=00:59:30.00 bitrate= 320.0kbits/s speed= 114x elapsed=0:00:31.42

#public

About

Sun, 08 Feb 2026 04:46:24 GMT

About

HM0008 について

個人的な備忘録をまとめる場所です
このサイトの内容はすべて人間によって書かれています
- ただし、文章作成のサポートとして LLM との共同作業を実施する場合があります
- 文章作成者の言葉選びの癖を残します

興味・関心

サイバネティクス
フェリックス・ガタリ
庭
Linux
generative art (not produced by Generative AI)
アンビエント
フィールドレコーディング
かたちと機能

#public

Index

Sun, 08 Feb 2026 04:45:55 GMT

Index

このサイトについては About を参照のこと。

Pages

#public

ベランダの音 (2025-12-03)

Wed, 03 Dec 2025 13:50:32 GMT

ベランダの音 (2025-12-03)

日時: 2025-12-03 15時ごろ
場所: 部屋のベランダ
音:
- 隣の公園からヒヨドリをはじめとした鳥の鳴き声
- 航空機の音
- 建物をまたいだ先にある幹線道路から自動車の音
- 近所の方のバイク、自転車、声
- 16 時近くになると放送される蛍の光
コメント: 寒くなってきました

Your browser does not support the audio element.

メモ

加工に用いた ffmpeg コマンド

# Get duration
$ ffprobe -i 251203_0015.wav -show_entries format=duration -v quiet -of csv="p=0"
4107.648000
# Normalization, trimming and fades
$ ffmpeg -i 251203_0015.wav -ss 20 -to 4087.648 -af "loudnorm=I=-20:TP=-2:LRA=11,afade=t=in:st=20:d=5,afade=t=out:st=4082.648:d=5" 251203_0015_processed.wav -y
# Convert to mp3
$ ffmpeg -i 251203_0015_processed.wav -codec:a libmp3lame -b:a 320k 251203_0015_processed.mp3 -y

#public

公園の音 (2025-11-22)

Sun, 23 Nov 2025 13:26:53 GMT

公園の音 (2025-11-22)

録音日時: 2025-11-22 11時ごろ
場所: 近所の公園
コメント: 比較的大きな公園で、近くには鉄道が走っています。たまに落ち葉の落ちる音が聞こえるかもしれません。

Your browser does not support the audio element.

メモ

フェードイン/アウト、音量調整、 mp3 出力をするスクリプト:

import os
import argparse
from pydub import AudioSegment


def add_fade(source: AudioSegment, in_ms: int, out_ms: int) -> AudioSegment:
    faded_audio = source.fade_in(in_ms).fade_out(out_ms)

    return faded_audio

def change_volume_by(source: AudioSegment, change_db: int) -> AudioSegment:
    return source + change_db

def export_wav(source: AudioSegment, file_name: str):
    source.export(file_name + ".wav", format="wav")

def export_mp3(source: AudioSegment, file_name: str):
    source.export(file_name + ".mp3", format="mp3")

def main():
    fade_duration = 2000  # 2 secconds

    parser = argparse.ArgumentParser()
    parser.add_argument("file_paths", nargs='+', help="File paths")

    args = parser.parse_args()
    filenames = args.file_paths

    for filename in filenames:
        try:
            print(f"Processing {filename}...")
            audio = AudioSegment.from_wav(filename)

            audio = add_fade(audio, fade_duration, fade_duration)
            audio = change_volume_by(audio, 16)

            output_filename = f"{os.path.splitext(filename)[0]}_processed"
            export_mp3(audio, output_filename)
            
        except Exception as e:
            print(f"Error processing {filename}: {e}")

if __name__ == "__main__":
    main()

#public

Linux の LRU リストについてのメモ

Tue, 29 Jul 2025 11:41:26 GMT

Linux の LRU リストについてのメモ

前提: Reclaimation

メモリは階層的に管理される。ページキャッシュは多くの場合 CPU キャッシュ (L1/L2/L3)、 RAM 、ディスク (の swap 領域) に保存される可能性がある。この階層は、上位の媒体ほど高速だが容量が小さく、下位ほど低速で容量が大きいという特徴がある。頻繁に利用されるページキャッシュに高速でアクセスできるよう、 CPU キャッシュや RAM で保持したい。逆に、メモリが不足する場合は、アクセスしないページキャッシュをディスクに追い出す (evict) ことも必要となる。

Traditional Linux LRU lists

従来の kswapd は 2つの LRU リストを持つ。

active_list: すべてのプロセスの active なページキャッシュのリスト
inactive_list: reclaim の候補となるページキャッシュのリスト

ページキャッシュは allocate されると inactive_list に繋がれる。アクセスが発生すると active_list に移動される。 active_list の末尾の要素が inactive_list に移動することで reclaim の対象となる。なお、 active_list -> inactive_list 移動の対象となったページキャッシュは、その参照などもチェックされ、たとえば対象ページへの参照があれば active_list に戻されたりするようだ。単純な LRU リストではなく active_list / inactive_list の 2つのリストを使用している理由は、 reclaim してはならないページキャッシュと可能なそれを分けるためだと思われる。

LRU-like な方法でうまくいかない場合があるとのこと。例えば:

inactive_list にあるページが anonymous pages の場合。 anonymous ページを RAM からディスクへ swap するのはコピーする時間がかかる。もともとディスクにデータがある (例えば、プログラムコード) ページ (file-backed page) ではこの作業が必要ない。
一つのプロセスが大量の file-backed page に書き込みを行った場合。書き込まれたページ (dirty page) の内容は、swap の前に本体のファイルに書き込まれる必要がある。その間にまたページへの書き込みが行われ、 active_list に戻ったりする。

参考:

Page Frame Reclamation

次

Multi-Gen LRU (MGLRU)

#public

カーネルコード探検: kmalloc()

Tue, 24 Jun 2025 12:12:42 GMT

カーネルコード探検: kmalloc()

Linux 6.12.y のソースを使う

> git describe --contains
v6.12.34^0

まず、 kmalloc() の定義は include/linux/slab.h にある:

/**
 * kmalloc - allocate kernel memory
 * @size: how many bytes of memory are required.
 * @flags: describe the allocation context
 *
 * kmalloc is the normal method of allocating memory
 * for objects smaller than page size in the kernel.
 *
 * The allocated object address is aligned to at least ARCH_KMALLOC_MINALIGN
 * bytes. For @size of power of two bytes, the alignment is also guaranteed
 * to be at least to the size. For other sizes, the alignment is guaranteed to
 * be at least the largest power-of-two divisor of @size.
 *
 * The @flags argument may be one of the GFP flags defined at
 * include/linux/gfp_types.h and described at
 * :ref:`Documentation/core-api/mm-api.rst <mm-api-gfp-flags>`
 *
 * The recommended usage of the @flags is described at
 * :ref:`Documentation/core-api/memory-allocation.rst <memory_allocation>`
 *
 * Below is a brief outline of the most useful GFP flags
 *
 * %GFP_KERNEL
 *	Allocate normal kernel ram. May sleep.
 *
 * %GFP_NOWAIT
 *	Allocation will not sleep.
 *
 * %GFP_ATOMIC
 *	Allocation will not sleep.  May use emergency pools.
 *
 * Also it is possible to set different flags by OR'ing
 * in one or more of the following additional @flags:
 *
 * %__GFP_ZERO
 *	Zero the allocated memory before returning. Also see kzalloc().
 *
 * %__GFP_HIGH
 *	This allocation has high priority and may use emergency pools.
 *
 * %__GFP_NOFAIL
 *	Indicate that this allocation is in no way allowed to fail
 *	(think twice before using).
 *
 * %__GFP_NORETRY
 *	If memory is not immediately available,
 *	then give up at once.
 *
 * %__GFP_NOWARN
 *	If allocation fails, don't issue any warnings.
 *
 * %__GFP_RETRY_MAYFAIL
 *	Try really hard to succeed the allocation but fail
 *	eventually.
 */
static __always_inline __alloc_size(1) void *kmalloc_noprof(size_t size, gfp_t flags)
{
	if (__builtin_constant_p(size) && size) { // コンパイル時に size が判明しているか?
		unsigned int index;

		if (size > KMALLOC_MAX_CACHE_SIZE) // KMALLOC_MAX_CACHE_SIZE よりも大きい場合は、 slab cache で対応できないため
			return __kmalloc_large_noprof(size, flags); // さらに大きいサイズを確保できる内部関数へ

		// KMALLOC_MAX_CACHE_SIZE よりも小さく、つまり用意されている slab cache のサイズで対応できる場合は、
		index = kmalloc_index(size); // どのサイズの slab cache を使うか決める
		return __kmalloc_cache_noprof(
				kmalloc_caches[kmalloc_type(flags, _RET_IP_)][index],
				flags, size); // kmalloc_caches の 
	}

	// コンパイル時に確保するサイズが定まっていない場合
	return __kmalloc_noprof(size, flags);
}
#define kmalloc(...)				alloc_hooks(kmalloc_noprof(__VA_ARGS__)) // alloc_hooks については一旦保留

alloc_hooks() はデバッグ向けの機能を色々提供していそう。いったん飛ばす。

最終的には kmalloc_noprof(__VA_ARGS__) が呼ばれるようだ。

kmalloc_noprof から呼び出される関数は、 3つに分岐する

__kmalloc_large_noprof
__kmalloc_cache_noprof
__kmalloc_noprof

`__kmalloc_large_noprof`

簡単に呼び出しグラフをまとめると、以下の通り:

mm/slab.c: __kmalloc_large_noprof()
    mm/slab.c: __kmalloc_large_node()
        mm/slab.c: __kmmaloc_large_node()
            get_order(size)
            alloc_pages_node_noprof() (inline)
                __alloc_pages_node_noprof() (inline)
                    __alloc_pages_noprof() // ページ確保の関数
            folio_address() //

最終的には、ページアロケーションに用いられる __alloc_pages_noprof にたどり着く。

参考: ページアロケーションに用いられる API (include/linux/gfp.h より):

#define alloc_pages(...)			alloc_hooks(alloc_pages_noprof(__VA_ARGS__))
#define alloc_pages_mpol(...)			alloc_hooks(alloc_pages_mpol_noprof(__VA_ARGS__))
#define folio_alloc(...)			alloc_hooks(folio_alloc_noprof(__VA_ARGS__))
#define folio_alloc_mpol(...)			alloc_hooks(folio_alloc_mpol_noprof(__VA_ARGS__))
#define vma_alloc_folio(...)			alloc_hooks(vma_alloc_folio_noprof(__VA_ARGS__))

#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)

ここでは触れないが、道中では以下のことも行っていた

trace_kmalloc(): デバッグ用の何か?
NUMA のためのノード選択処理
kasan_kmalloc_large(): KASAN の設定?
kmemleak_alloc(): kmemleak のフック
kmsan_kmalloc_large(): KMSAN の設定?

mm/slab.c より:

/*
 * To avoid unnecessary overhead, we pass through large allocation requests
 * directly to the page allocator. We use __GFP_COMP, because we will need to
 * know the allocation order to free the pages properly in kfree.
 */
static void *___kmalloc_large_node(size_t size, gfp_t flags, int node)
{
	struct folio *folio;
	void *ptr = NULL;
	unsigned int order = get_order(size); // size を order に変換している (include/asm-generic/getorder.h 参照)

	if (unlikely(flags & GFP_SLAB_BUG_MASK))
		flags = kmalloc_fix_flags(flags);

	flags |= __GFP_COMP;
	folio = (struct folio *)alloc_pages_node_noprof(node, flags, order); // ページの確保
	if (folio) { // 確保できれば
		ptr = folio_address(folio); // folio からベースとなるアドレスを取得する
		lruvec_stat_mod_folio(folio, NR_SLAB_UNRECLAIMABLE_B,
				      PAGE_SIZE << order);
	} // ページが確保できなければ ptr == NULL

	ptr = kasan_kmalloc_large(ptr, size, flags); // KASAN 向けの設定
	/* As ptr might get tagged, call kmemleak hook after KASAN. */
	kmemleak_alloc(ptr, size, 1, flags);
	kmsan_kmalloc_large(ptr, size, flags);

	return ptr;
}

GFP フラグの処理、メモリセキュリティ上の設定については無視すると、行っているのは以下:

まず get_order(size) で確保したいサイズを order (2^(order) >= size となるような最も小さい値) に変換する。
alloc_pages_node_noprof() を呼び出す。この先でページの確保が走る。
folio_address() で確保された領域のポインタを返す。

alloc_pages_node_noprof() を追いかけると、 __alloc_pages_noprof() にたどり着く

mm/page_alloc.c より:

/*
 * This is the 'heart' of the zoned buddy allocator.
 */
struct page *__alloc_pages_noprof(gfp_t gfp, unsigned int order,
				      int preferred_nid, nodemask_t *nodemask)
{
	struct page *page;
	unsigned int alloc_flags = ALLOC_WMARK_LOW;
	gfp_t alloc_gfp; /* The gfp_t that was actually used for allocation */
	struct alloc_context ac = { };

	/*
	 * There are several places where we assume that the order value is sane
	 * so bail out early if the request is out of bound.
	 */
	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) // 要求されるオーダーが MAX_PAGE_ORDER (一般的には 11) を超える場合は
		return NULL; // NULL を返す

	// [...]

	/* First allocation attempt */
	page = get_page_from_freelist(alloc_gfp, order, alloc_flags, &ac); // 一度目の要求
	if (likely(page))
		goto out;

	// [...]

	page = __alloc_pages_slowpath(alloc_gfp, order, &ac);

out:
	if (memcg_kmem_online() && (gfp & __GFP_ACCOUNT) && page &&
	    unlikely(__memcg_kmem_charge_page(page, gfp, order) != 0)) {
		__free_pages(page, order);
		page = NULL;
	}

	trace_mm_page_alloc(page, order, alloc_gfp, ac.migratetype);
	kmsan_alloc_page(page, order, alloc_gfp);

	return page;
}
EXPORT_SYMBOL(__alloc_pages_noprof);

コメントにもある通り、 zoned buddy allocator の心臓部。つまり alloc_pages などのページアロケーション API の先で呼ばれる関数が、で呼ばれている。

get_page_from_freelist() が呼ばれ、失敗した場合は __alloc_pages_slowpath() が呼ばれる。

get_page_from_freelist() もページ確保先のメモリゾーンの選定や、 watermark (ページを確保する余裕があるか否か) の検査などを行った後、実際にページを確保する。つまり zone ごとにある freelist から、 2^order サイズの page を取得する。

mm/page_alloc.c:

/*
 * get_page_from_freelist goes through the zonelist trying to allocate
 * a page.
 */
static struct page *
get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
						const struct alloc_context *ac)
{
	struct zoneref *z;
	struct zone *zone;
	struct pglist_data *last_pgdat = NULL;
	bool last_pgdat_dirty_ok = false;
	bool no_fallback;

	// [...]

	/*
	 * Scan zonelist, looking for a zone with enough free.
	 * See also cpuset_node_allowed() comment in kernel/cgroup/cpuset.c.
	 */
	// [...]
	for_next_zone_zonelist_nodemask(zone, z, ac->highest_zoneidx,
					ac->nodemask) { // ゾーンのリストを巡って、ページを確保しようとする

		// [...] // メモリのゾーン、 wartermark の検査

try_this_zone: // 問題なければ、ここにくる
		page = rmqueue(zonelist_zone(ac->preferred_zoneref), zone, order,
				gfp_mask, alloc_flags, ac->migratetype); // freelist から 2^order サイズの page を取得
		if (page) {
			prep_new_page(page, order, gfp_mask, alloc_flags); // ページの初期化

			// [...]

			return page; // ページを返す
		} else {
			// [...]
		}

		// [...]

	}

	return NULL; // ページを確保できない場合は、 NULL を返す
}

__alloc_pages_slowpath() でも何度かリトライする。

GFP フラグを調整する
ひとつ大きい order を分割して、必要としている order の領域を作る
メモリを reclaim する

今回は、 buddy allocator の標準的な方法である、

static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
						struct alloc_context *ac)
{
	bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM;
	bool can_compact = gfp_compaction_allowed(gfp_mask);
	bool nofail = gfp_mask & __GFP_NOFAIL;
	const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER;
	struct page *page = NULL;
	unsigned int alloc_flags;
	unsigned long did_some_progress;
	enum compact_priority compact_priority;
	enum compact_result compact_result;
	int compaction_retries;
	int no_progress_loops;
	unsigned int cpuset_mems_cookie;
	unsigned int zonelist_iter_cookie;
	int reserve_flags;

	// [...]

restart:

	// [...]

	/*
	 * For costly allocations, try direct compaction first, as it's likely
	 * that we have enough base pages and don't need to reclaim. For non-
	 * movable high-order allocations, do that as well, as compaction will
	 * try prevent permanent fragmentation by migrating from blocks of the
	 * same migratetype.
	 * Don't try this for allocations that are allowed to ignore
	 * watermarks, as the ALLOC_NO_WATERMARKS attempt didn't yet happen.
	 */
	if (can_direct_reclaim && can_compact &&
			(costly_order ||
			   (order > 0 && ac->migratetype != MIGRATE_MOVABLE))
			&& !gfp_pfmemalloc_allowed(gfp_mask)) {
		page = __alloc_pages_direct_compact(gfp_mask, order,
						alloc_flags, ac,
						INIT_COMPACT_PRIORITY,
						&compact_result);
		if (page)
			goto got_pg;

		// [...]

	}

	// [...]

got_pg:
	return page;
}

#public

Landlock を使ってみる

Mon, 02 Jun 2025 12:16:07 GMT

Landlock を使ってみる

Landlock はカーネルのセキュリティ機構。非特権でも、プロセスがアクセス可能なファイルパスや TCP ポートを制限できる。

今回は、 Landlock を使って簡単な sandbox を作ってみた。

簡単なコードで試してみる

リポジトリ: nohopium/smolock

読み取り権限のみ付与していることやネットワークの隔離に対応していないなど制限はあるが、とりあえず動くものができた。

テスト

例1: /etc への権限を与えていないため、 /etc への読み取りが拒否される

> ./target/debug/smolock -p /home/ ls -la /etc
ls: cannot open directory '/etc': Permission denied

例1: /home への権限を与えると、問題なく実行できる

> ./target/debug/smolock -p /home/ ls -la /home
total 0
drwxr-xr-x 1    0    0   12 Dec 13  2023 .
drwxr-xr-x 1    0    0  138 May 15 11:06 ..
drwx--x--x 1 1000 1000 1226 Jun  6 08:21 hopium

例2: 同じように、権限がなく拒否される

> ./target/debug/smolock head ./src/main.rs 
head: cannot open './src/main.rs' for reading: Permission denied

例2: 権限を付与すると、実行できる

> ./target/debug/smolock -p ./src/ head ./src/main.rs 
use std::{os::unix::process::CommandExt, path::PathBuf, process::Command};

use anyhow::Result;
use clap::Parser;
use which::which;

#[derive(Parser, Debug)]
struct Args {
    #[arg(short, long)]
    paths: Vec<PathBuf>,

いくつか備考

コマンド (実行ファイル) 実行時に要求されるファイル、例えば実行ファイルに動的リンクされる共有オブジェクトファイル、への読み取り権限がないと。
- ワークアラウンドとして /usr/lib に読み取り権限を与えている
-p で指定されたパスに対して読み取り権限しか与えていないため、書き込み権限を要する場合は拒否される。

> ./target/debug/smolock -p ./src/ rm ./src/main.rs 
rm: cannot remove './src/main.rs': Permission denied

参考

Landlock の公式サイト
開発者による講演: Linux Sandboxing with Landlock - OSS Europe 2024
- スライド

#public

Raspberry Pi 5 向け Arch Linux イメージの作成

Sun, 25 May 2025 10:57:22 GMT

Raspberry Pi 5 向け Arch Linux イメージの作成

Raspberry Pi 5 (RPi5) に Arch Linux ARM (ALARM) をインストールしたので、その手順を残す。

ALARM は RPi5 に対応しておらず、 ALARM イメージをそのまま利用しても RPi5 はブートできない。今回は x86_64 のマシン上で ALARM イメージに chroot し、必要な設定を行うことでこれに対処する。

用意したもの

ホスト: ブートメディアを作成するマシン。アーキテクチャは x86_64. ディストリビューションは Arch Linux (for x86_64).
- 必要であれば、 SD カードの読み書きができるデバイスも用意する。
Raspberry Pi 5 (RPi5): 今回のターゲット環境。アーキテクチャは arm64.

ALARM の入手

Arch Linux ARM のページから入手可能

> wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz

ホストへのパッケージ追加

arm64 向けのイメージに chroot する際に利用するパッケージをインストールする。

まずは、 aarch64 向けバイナリを動作させるのに必要なパッケージ。 binfmt によって aarch64 向けの実行バイナリが QEMU の aarch64 エミュレーション環境上で実行されるようになる。

> sudo pacman -S qemu-user-static qemu-user-static-binfmt

systemd-binfmt サービスを動かしておく。

> sudo systemctl start systemd-binfmt.service

arch-install-scripits も入れておく。 chroot の wrapper である arch-chroot を提供するパッケージで、 chroot の操作に加えて /etc/resolv.conf の bind mount を行う。

> sudo pacman -S arch-install-scripts

SD カードパーティションの作成

fdisk を使って、 SD カード (今回は /dev/sda) に boot パーティションと rootfs パーティションを作成する。

fdisk では以下の設定をした:

boot パーティションを 512MB で確保し、パーティションタイプを W95 FAT32 (LBA) へ変更。
残りのパーティションを rootfs 用に確保する。パーティションタイプの変更はなし。

以下は、作業時のログ:

> sudo fdisk /dev/sda
[...]
Command (m for help): o
Created a new DOS (MBR) disklabel with disk identifier 0x84c3e00f.
The device contains 'dos' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Command (m for help): p

Disk /dev/sda: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: Multi-Card      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x84c3e00f

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): 

Using default response p.
Partition number (1-4, default 1): 
First sector (2048-62333951, default 2048): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-62333951, default 62333951): +512M

Created a new partition 1 of type 'Linux' and of size 512 MiB.

Command (m for help): t
Selected partition 1
Hex code or alias (type L to list all): c
Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 
First sector (1050624-62333951, default 1050624): 
Last sector, +/-sectors or +/-size{K,M,G,T,P} (1050624-62333951, default 62333951): 

Created a new partition 2 of type 'Linux' and of size 29.2 GiB.

Command (m for help): p
Disk /dev/sda: 29.72 GiB, 31914983424 bytes, 62333952 sectors
Disk model: Multi-Card      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x84c3e00f

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1          2048  1050623  1048576  512M  c W95 FAT32 (LBA)
/dev/sda2       1050624 62333951 61283328 29.2G 83 Linux

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

ファイルシステムの作成

作成したパーティションのそれぞれに対して、 mkfs でファイルシステムを作成する。

boot 用に確保した /dev/sda1 には mkfs.vfat 、 rootfs 用に確保した /dev/sda2 には mkfs.ext4 を用いた。

> sudo mkfs.vfat /dev/sda1
> sudo mkfs.ext4 /dev/sda2

マウント

/dev/sda1, /dev/sda2 を適当な場所にマウントする。

> mkdir -p ./mount/root ./mount/boot

> sudo mount /dev/sda1 ./mount/boot/
> sudo mount /dev/sda2 ./mount/root/

ALARM イメージの書き込み

ダウンロードした ALARM イメージを、マウントされた rootfs 領域に書き込む。

> sudo su
# tar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C ./mount/root/
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.security.capability'
# exit

chroot

マウントした rootfs に chroot する。

> sudo arch-chroot ./mount/root /bin/bash
[root@machine /]#

pacman の初期化とパッケージ群のアップデートを行う。

# pacman-key --init
# pacman-key --populate archlinuxarm
# pacman -Syuu --noconfirm

タイムアウトしたため、いくつかのミラーを有効化すると改善した。

# diff -u /etc/pacman.d/mirrorlist.orig /etc/pacman.d/mirrorlist
--- /etc/pacman.d/mirrorlist.orig	2025-05-20 23:27:04.851321391 +0000
+++ /etc/pacman.d/mirrorlist	2025-05-20 23:29:27.156214459 +0000
@@ -33,16 +33,16 @@
 
 ### Japan
 ## Tokyo
-# Server = http://jp.mirror.archlinuxarm.org/$arch/$repo
+Server = http://jp.mirror.archlinuxarm.org/$arch/$repo
 
 ### Singapore
 # Server = http://sg.mirror.archlinuxarm.org/$arch/$repo
 
 ### Taiwan
 ## Hsinchu
-# Server = http://tw2.mirror.archlinuxarm.org/$arch/$repo
+Server = http://tw2.mirror.archlinuxarm.org/$arch/$repo
 ## New Taipei City
-# Server = http://tw.mirror.archlinuxarm.org/$arch/$repo
+Server = http://tw.mirror.archlinuxarm.org/$arch/$repo
 
 ### United Kingdom
 ## London
@@ -50,7 +50,7 @@
 
 ### United States
 ## California
-# Server = http://ca.us.mirror.archlinuxarm.org/$arch/$repo
+Server = http://ca.us.mirror.archlinuxarm.org/$arch/$repo
 ## Florida
 # Server = http://fl.us.mirror.archlinuxarm.org/$arch/$repo
 ## New Jersey

linux-rpi をインストールし、既存の linux-aarch64 を置き換える。

# pacman -Sy linux-rpi rpi5-eeprom --disable-sandbox
[...]
:: linux-rpi-6.12.28-1 and linux-aarch64-6.14.6-1 are in conflict (linux). Remove linux-aarch64? [y/N] y
[...]

RPi5 の boot に必要な .dtb が存在することを確認:

# ls /boot/bcm2712-rpi-5-b.dtb 
/boot/bcm2712-rpi-5-b.dtb

chroot を終了

# exit

boot パーティションの準備

rootfs の /boot/ ディレクトリの内容を boot パーティションにコピーする。 RPi5 はこのパーティション (/dev/sda1) を見てカーネル等をロードする。

> sudo cp -vr ./mount/root/boot/* ./mount/boot/

アンマウント

SD カードのパーティションをアンマウントする。

> sudo sync
> sudo umount ./mount/root/ ./mount/boot/

これで SD カードブートメディアの準備は完了となる。RPi5 に SD カードを挿して起動する。

参考

#public

『アンチ・オイディプス』第一章わからんメモ

Wed, 14 May 2025 08:27:02 GMT

『アンチ・オイディプス』第一章わからんメモ

一か月ほど第一章を彷徨っているので、整理する。

第一節: 欲望的生産

連接や接続をともなう様々な機械がある。器官機械が源泉機械につながれる。ある機械は流れを発生させ、別の機械は流れを切断する。

常に流れと切断がある。

自然であれ社会であれ、そこには機械がある。機械は流れを発生させ、また切断を行う。

葉緑素機械あるいは光合成機械であること、少なくとも、このような機械の中に自分の身体をひとつの部品として滑り込ませること。レンツは、人間と自然が区別される以前に、あるいはこの区別を条件とするあらゆる指標以前に身をおいたのだ。彼は自然を自然としてだけではなく、生産のプロセスとして生きる。もはや、ここには人間もなければ、自然もなく、ただ一方を他方の中で生産し、もろもろの機械を連結するプロセスだけがある。

ある機械は別の機械によって生産される。それを連結する。そういうプロセスだけがある。

自然 - 人間、自然 - 産業、自然 - 社会というこの弁別的関係は、社会の中にさえも「生産」「分配」「消費」と呼ばれる相対的に自律的な領域の区別を存在させる条件となっている。

自然 - X の二項対立が存在することを条件として、「生産」「分配」「消費」の区別が存在する。
- ここまでの話から、こうした区別が存在しないと主張したいことがわかる

すなわち、生産はそのまま消費であり、登録なのである。登録と消費は直接に生産を規定しているが、しかも生産そのものの真っ只中で生産を規定している。だから、すべては生産なのだ。

はい。

ここに存在するのは、生産の生産、つまり能動と受動の生産であり、登録の生産、つまり分配と指標の生産であり、消費の生産、享楽と不安と苦痛の生産なのである。すべてはまさに生産であるから、登録はただちに消費され消尽され、この消費は直接に再生産される。これがプロセスという言葉の第一の意味である。すなわち、登録と消費を生産そのものの中に組み込むこと、登録と消費を、同じひとつの過程の中の生産とみなすことである。

生産の要素
- 生産の生産 = 能動と受動の生産
- 登録の生産 = 分配と指標の生産
- 消費の生産 = 享楽と不安と苦痛の生産
- プロセス = 生産-登録-消費の生産

第二に、ここでは自然 - 人間の区別も存在しない。 … 因果や包含や表現などといった関係 (原因 - 結果、主観 - 客観) において捉えられるとしても、自然と人間は、相互に対面する二項のようなものではなく、むしろ唯一の同じ本質的な実在であり、生産するものと生産されるものは一体をなしているのだ。プロセスとしての生産は、あらゆる観念的カテゴリーをはみだすものであり、欲望を内在的原理としてひとつのサイクルを形成している。

note: プロセスでは自然 - X の二項対立が存在しない。プロセスでは生産するものと生産されるものを一体=サイクルとして捉える。そして欲望がプロセスの内在的原理となる。

プロセスは、目標や目的と考えられてはならないし、プロセス自身を無限に継続することと混同されてもならない。プロセスの目的化、あるいはプロセスの無限の継続は、厳密にいえば、そのプロセスの早すぎる無謀な停止と同じことであり、 …

上はプロセスの第三の意味
- プロセスは終極であってはならない。
プロセスの条件:
- 生産-登録-消費の区別を行わないすべては生産
- 生産者と生産物のサイクルで構成される
- プロセスが終極状態であってはならない

分裂症的な特性とか、その臨床実体とかいったものは、何ら存在しない。分裂症とは生産し再生産する欲望機械の宇宙であり、「人間と自然をなす本質的実在」としての根源的な普遍的生産である。

「欲望機械」が出てきた。
「人間と自然をなす本質的実在」 = 根源的な普遍的生産
- これは上で触れているプロセスと同じ?
分裂症 = 生産し再生産する欲望機械の宇宙 = 根源的な普遍的生産

欲望機械は二項機械であり、二項的規則、あるいは連合的体制をそなえた機械である。ひとつの機械は常に他の機械と連結している。生産的総合すなわち、生産の生産は、「そして」 et 「そして次に」 et pruis… という接続的な形態をもっている。つまり、ここには常に流れを生産する機械と、この機械に接続されてこの流れを切断し採取する働きをするもうひとつの機械が存在する (…)。そしてまた、今度は第一の機械が別の機械に接続され、これに対して第一の機械が切断あるいは採取の行動をする。したがって、二項系列はあらゆる方向に線型状にのびてゆく。

欲望機械 = et, et pruis で機械をつなぐ二項機械

あらゆる「対象」は流れの連続を前提とし、あらゆる流れは対象の断片化を前提としている。

圏論みたい。 IIRC, 圏は対象と射から定義される
- 対象は射を前提とし、射は対象を前提とする

おそらく、それぞれの〈器官機械〉は、自分自身の流れにしたがって、自分自身から流れ出すエネルギーにしたがって、世界全体を解釈する。眼はあらゆることを、 … 見るという言葉で解釈する。しかし、他の機械との間には、いつも接続の関係が、ある横断線によって設定される。この横断線を通じて、ひとつの機械は他の機械の流れを切断し、あるいは自分の流れが他の機械によって切断されるのを「見る」のである。

機械への入力だけで、知覚する。

それゆえ、〈流れ - 部分対象〉という接続的総合による連結は、また〈生産物 - 生産する働き〉という別の形態をもつことになる。生産する働きは、常に生産されるものに接木される。だからこそ、あらゆる機械が機械の機械であるように、欲望的生産は生産の生産なのだ。

あらゆる機械は機械の機械。
欲望的生産は生産の生産。欲望機械は、機械を接続する。流れを生産する流れ。

ここには、生産の働きとその生産物を区別する余地がない。少なくとも生産されたものは、自分自身の現場を新しい生産の働きの中にたずさえている。

ここ = 分裂症者の机

レヴィ=ストロースは器用仕事を規定するとき、緊密に結びついた諸特性の総体としてそれを提案している。すなわち、多数のチグハグな、限られたストックやコードを具えていること、もろもろの断片を、たえず新しい断片化に導く能力をもつこと。したがって生産する働きと生産物は区別されず、用いる道具の全体と、実現すべき仕事の全体も区別されない。

「器用仕事」には「ブリコラージュ」のルビあり
- bricolage c.f. 設計 design
- bricoleur: 利用可能なもので問題を解決するひと
- 『野生の思考』
緊密に結びついた諸特性の総体
- 多数のチグハグな、限られたストックやコードを具えている
  - ストック、コード?
- 断片を、新しい断片化に導く
  - 断片から別の断片をつくる
  - かならずしもある断片をさらにちいさな断片に分解するものではない?
- 用いる道具の全体と、実現すべき仕事の全体が区別されない
  - 生産されたものが、次の生産のための道具になる

たえず生産の働きを生産し、この生産の働きを生産物に接木してゆくという規則こそが、欲望機械、あるいは根源的な生産の特性なのである。

欲望機械の特性 = 生産の働きを生産する。

〈生産する働き〉〈生産物〉〈生産物と生産する働きの同一性〉……。この第三の同一性がまさに、線型状の系列の中に第三項を構成することになる。これは、未分化の巨大な対象である。

〈生産物と生産する働きの同一性〉 = 生産されたものが、時間的に続く生産を行う
- 生産物は生産を行うというだけでいいのか、生産という trait なのか。それとも、生産物と生産する働きの型が一致するものなのか。よくわからない。特に指定がないかつここまでの文脈から、前者だと思っている。
〈生産物と生産する働きの同一性〉 = 「未分化の巨大な対象」。

生産物と生産する働きの同一性:

生産物は、すなわち生産する働きを持つ。

trait Producer {
    fn produce() -> impl Producer {
        // ...
    }
}

生産物は、同じ型を生産する働きを持つ。

struct ProductFoo {
}

impl ProductFoo {
    fn produce() -> Self {
        // ...
    }
}

1 は普遍的に成り立ちそう 2 はいわゆる reproduction.

わかった。「この第三の同一性がまさに、線型状の系列の中に第三項を構成することになる。これは、未分化の巨大な対象である。」はつまり、生産物はすなわち生産する働きとなる特性は、流れの生産-切断に、第三 (あるいはさらに第四, …) の項を繋いでいく役割を果たす。

ある純粋な流体が、自由状態で、途切れることなく、ひとつの充実身体の上を滑走しているのだ。欲望機械は、私たちに有機体を与える。ところが、この生産の真っ只中で、この生産そのものにおいて、身体は、組織される〔有機化される〕ことに苦しみ、つまり別の組織を持たないことを苦しんでいる。こうして過程の最中に、第三の契機として「不可解な、直立状態の停止」がやってくる。 … もろもろの自動機械装置は停止して、それらが分節していた非有機体的な塊を出現させる。この器官なき充実身体は、非生産的なもの、不毛なものであり、発生してきたものではなくて始めからあったもの、消費しえないものである。

線形状の系列をなさない (生産/採取のない) 何かがある。それが器官なき身体。それは、自動機械装置が分節していた非有機体的な塊。
器官なき身体は、非生産的なもの (= 線形状の系列をなさない、生産過程に属しない) 不毛なもの (= 生産の働きをもたない)、発生してきたもの (= 生産物?) ではなくて始めからあったもの、消費しえないもの (= 切断-採取できないもの)

この世のものはすべて関数だと思っている節が私にあるが、それは違うらしい。

死の本能、これがこの身体の名前である。この死には、モデルがないわけではない。実際、欲望はこれもまた、死をもまた欲望するのである。なぜなら死の充実身体は、みずからは動かずして欲望を動かすものであるから。ちょうど生のもろもろの器官が作動する機械 working machine であるからこそ、欲望が生を欲望することになるように。

生の器官が作動する機械であるから、欲望が生を欲望する。死の充実身体は欲望を動かす、つまり、死は、複数の機械を生産-採取の関係によって接続する。死そのものは何も生み出さないが、具体的な死は、流れを生み出すということ? 「生のもろもろの器官が作動する機械である」がわからない。生の機械とは?

器官なき身体 = 死の本能 = 死そのもの = 死の概念?

第二節: 器官なき身体

第三節: 主体と享受

第四節: 唯物論的精神医学

第五節: 欲望機械

第六節: 全体と諸部分

#public

nRF52840 + ZMK firmware の備忘録

Mon, 12 May 2025 12:31:43 GMT

nRF52840 + ZMK firmware の備忘録

nRF52840 + ZMK ファームウェアキーボードの習作として HM0011a を設計した。

特徴

主な特徴は以下の通り:

36 キーオーソリニア配列
Seeed Xiao nRF52840 + ZMK firmware による無線化
ドングルによるキーボード側の省力化
リバーシブル基板によるコスト削減
ケース厚 10mm, 全高 20mm

設計時資料

KiCad
参考キーボード
- TOTEM
- forager
- 1984 - 36 ortholinear split keyboard
  - リバーシブル基板での回路設計
バッテリー持続時間の目安
- Power Profiler
  - nice!nano v2 が nRF52840 搭載のボードなので、目安として使える
  - ドングル仕様の場合には、キーボード側は peripheral となる
Seeed Xiao nRF52840
- Getting Started with Seeed Studio XIAO nRF52840 Series
ZMK firmware
- Documentation
  - ZMK はドキュメントが充実しているので、必要なことはだいたい書いてある。
    - 例: 新しいボードの追加、ドングルの設定方法、キーマップの設定
  - ただし、 Zephyr についてはあまり書いていない。 Zephyr 由来の Kconfig や devicetree の概念も説明が薄い気がする。
- caksoylar/zmk-config
  - ZMK 開発者の zmk-config
  - 参考として有用
- caksoylar/zmk-rgbled-widget
  - 同開発者の out-of-tree な LED ドライバモジュール
  - ドライバ開発時に役立つかもしれない
- caksoylar/zmk-smart-toggle
  - 同開発者の out-of-tree な behavior モジュール
  - behavior の実装時に役立つかもしれない

ハードウェア設計時の工夫

当初の設計方針としては以下があった。

分割無線
36-key オーソリニア
リバーシブル基板
アクリル積層サンドイッチケース

XIAO nRF52840 を採用

分割無線方式を採用したキーボードの設計は経験がなかったため、これを実現するためのハードウェア・ソフトウェアスタックで冒険するつもりはなかった。

リバーシブル基板

また、リバーシブル基板を採用した。リバーシブル基板により、一枚の基板の表裏を入れ替えることで左手用の基板としても右手用のそれとしても使用できる。

利点としては製造費用の低減があり、小ロットでは左右で2種の別デザイン基板を製造するよりも安上がりになる。

欠点としては複雑性の増加がある。今回の設計では、 XIAO nRF52840 のピン配置とキーボード基板のパッドの対応関係に注意する必要があった。 XIAO nRF52840 を左手側にはんだ付けする場合でも、右手側にはんだ付けする場合でも、デジタル IO ピンが Col/Row へ接続されるよう設計した。

アクリルプレート

アクリル層も KiCad で設計した。アクリルプレートは Kicad で設計すると基板との整合性を取りやすい。最終的に KiCad 内で DXF と PDF に変換して発注した。

トッププレート:

ミドルプレート:

ボトムプレート:

ZMK 設定時の工夫

特徴的な部分は多くないが、あえて挙げるのであれば、ドングルを採用した点にある。

Keyboard Dongle

次回のアイデアメモ

有線 / 無線切り替え
- 有線は type-c
電池容量の削減
- Power profiler 上では 200mAh で 5ヶ月になるので、十分すぎる
  - 100mAh でも 3ヶ月
HM0002 配列への回帰?
hotswap ソケット対応
choc v2 系スイッチ対応
発売されていれば, Xiao nRF52840 Plus 対応
3Dプリンタを導入していれば、3Dプリンタケース
OLED 付きドングル
XIAO nRF52840 用のパッドを、表面実装を利用して裏表で別のアサインにすれば、ソフトウェア側がややこしいことにならずに済みそう
- 左右有線接続時の UART pin も共通化できる
- 欠点: はんだ付け時の固定が大変かも

#public

HM0008

HM0008 のホスティング

HM0008 のホスティング

技術的な要素

各要素の詳細

Git hook (post-receive) による継続的デプロイメント

Git hook (post-receive) による継続的デプロイメント

Git hooks と post-receive の概要

前提: git push する側、される側の準備

git push する側

git push される側 (受け取り側)

例: HM0008 のデプロイにおける post-receive の利用

メモ

ベランダの音 (2026-02-08)

ベランダの音 (2026-02-08)

About

About

HM0008 について

興味・関心

Index

Index

Pages

ベランダの音 (2025-12-03)

ベランダの音 (2025-12-03)

メモ

公園の音 (2025-11-22)

公園の音 (2025-11-22)

メモ

Linux の LRU リストについてのメモ

Linux の LRU リストについてのメモ

前提: Reclaimation

Traditional Linux LRU lists

次

カーネルコード探検: kmalloc()

カーネルコード探検: kmalloc()

__kmalloc_large_noprof

Landlock を使ってみる

Landlock を使ってみる

簡単なコードで試してみる

テスト

いくつか備考

参考

Raspberry Pi 5 向け Arch Linux イメージの作成

Raspberry Pi 5 向け Arch Linux イメージの作成

用意したもの

ALARM の入手

ホストへのパッケージ追加

SD カードパーティションの作成

ファイルシステムの作成

マウント

ALARM イメージの書き込み

chroot

boot パーティションの準備

アンマウント

参考

『アンチ・オイディプス』第一章 わからんメモ

『アンチ・オイディプス』第一章 わからんメモ

第一節: 欲望的生産

第二節: 器官なき身体

第三節: 主体と享受

第四節: 唯物論的精神医学

第五節: 欲望機械

第六節: 全体と諸部分

nRF52840 + ZMK firmware の備忘録

nRF52840 + ZMK firmware の備忘録

特徴

設計時資料

ハードウェア設計時の工夫

XIAO nRF52840 を採用

リバーシブル基板

アクリルプレート

ZMK 設定時の工夫

次回のアイデアメモ

Git hooks と `post-receive` の概要

前提: `git push` する側、される側の準備

`git push` する側

`git push` される側 (受け取り側)

`__kmalloc_large_noprof`

『アンチ・オイディプス』第一章わからんメモ

『アンチ・オイディプス』第一章わからんメモ