古い xmobarrc を生き返らせる | 要約: with_weather

disclaimer: xmobarrc を蘇らせる方法は明確にしたが、ドキュメント上のビルドオプションや PKGBUILD がこうなっとることの怪に関しては怪のままになっとる。以下、怪奇を信じない人向け

最近ウィンドウマネージャの管理や設定にこだわりがなくなったので、2011年〜2014年あたりにいじっていた xmonad の環境をいまだに使っている (ので、当時自分が最強だとおもったキーバインドで完全に覚えているため、他人の PC のことがまったくわからん)。 さて、今確認したところ、手元の xmonad のバイナリは 2016年だった。あれからいろいろなことがあったね。

しかし xmobar を pacman 任せにしているとそのうち困ります。古い設定ファイルを食うとわけわからんエラーを吐いて死ぬから。いままで壊れた上のバーのことなんか一切気にしてなかったんだけど、不便かもしれないなと思い直したため、 xmobar だけ設定ファイルをビルド可能にしてみます。

で、こういうやつ

% cat .xmobarrc
Config { font = "xft:Inconsolata-7:bold"
       , bgColor = "#303040"
       , fgColor = "grey"
       , position = Top
       , lowerOnStart = False
       , commands = [
                      Run Network "eth1" ["-L","0","-H","32","--normal","green","--high","red"] 10
                    , Run Battery ["-t","<left>%","-L","20","-l","red","--high","#ccf","-p","3"] 100
                    , Run Network "wlp3s0" ["-L","0","-H","32","--normal","green","--high","red"] 10
                    , Run Wireless "wlp3s0" ["-t","<essid>:<quality>%","-p","3"] 10
                    , Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 20
                    , Run Memory ["-t","Mem: <usedratio>%","--normal","green","--high","red"] 10
                    , Run Com "uname" ["-s","-r"] "" 36000
                    , Run Date "%a %b %_d %Y %H:%M:%S" "date" 10
                    , Run TopMem [] 10
                    , Run Weather "RJTT" [ "--template", "<skyCondition> | <fc=#4682B4><tempC></fc>°C | <fc=#4682B4><rh></fc>% | <fc=#4682B4><pressure></fc>hPa"] 3600
                    , Run StdinReader
       ]
       , sepChar = "%"
       , alignSep = "}{"
       , template = "%cpu%  | %memory%(%topmem%) | %eth1%/%wlp3s0%(%wlp3s0wi%) } %StdinReader% { %RJTT% | <fc=#ee9a00>%date%</fc> | %battery% "
       }
% xmobar
Invalid configuration file: "Config" (line 19, column 10):
unexpected "s"
expecting space or "Run"

マジで意味不明すぎるバカメッセージなんだが、これはようは Run Weather がないと怒ってるんやな。本当にエラーメッセージをまともに出す能力がない人々のつくった最悪ソフトウェアであることがわかる。

で、

github.com

obsolete again じゃあないんだよ　真面目にやれ

ようは simpleHTTP がシンプルすぎて https に対応していなかったところ、天気情報が https オンリーになって「ア」となったといういい話っぽい。人類はちゃんと進化してるんですね。で、

will only work if compiled with the flag with_conduit (which is not set by all_extensions)

flag with_conduit (which is not set by all_extensions)

アホ草

もちろん pacman で入るやつの PKGBUILD にはそんなのは立ててない git.archlinux.org

とりあえず最新のやつをとってきて stack でビルドするとエラーは吐かなくなった。というのもこのフラグはいつのまにか with_weather にかわって、どうやら all_extensions で入るようになったっぽいから。というかこれデフォルトとかかいてあるぞ。

は？じゃあなんで……まあええわ…… ためしに with_weather 立てると→なんかぶっ壊れた→……………まあええよ

github の公式の stack.yml でビルドしとけばうごきまちた

pacman -S stack && stack setup && git clone "https://github.com/jaor/xmobar" xmobar-git && cd xmobar-git && stack install```

AWS ECS で perf-record する方法

EC2-backed ならできた。 Fargate との compatibility は諦めてね。新しい Task 定義を作成して、EC2-backed に Service を切り替えます。

CAP_SYS_ADMINをつける

これを見よ: docs.aws.amazon.com github.com docs.aws.amazon.com

要は Task definition に以下を追加し、Fargate との別れを告げる。

            "linuxParameters": {
                  "capabilities": {
                      "add": ["SYS_ADMIN"]
                  }
            },

他の方法

だめな場合

これを確認せよ:

  • /proc/sys/kernel/perf_event_paranoid を 2以下にする。
  • ubuntu などから COPY /usr/bin/perf perf などした場合、それはただのラッパースクリプトである。
  • 上記すべての方法は Fargate では無理

最小HTTPD Docker image (< 80kB)

ポエムパート

さて、〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓という必要から sidecar として httpd を生やすことになった一行だったが、そのために nginx.conf を書いて FROM nginx に ADD してあーしてこうして……そしてその無意味な仕事のために50MBの (alpine 版も 十数MB ある) コンテナを生成し、どこかに置く、あるいは --volume だか ConfigMap だかを書いて生の nginx に無理やり設定ファイルを注入する、といったことを繰り替えして終わるお前の人生

alpine darkhttpd イメージより 180 倍小さい httpd イメージ

こういうとき手元ではどうする？もちろん darkhttpd を立てる。ところで darkhttpd の image を探すと alpine 上に apk でインストールしているというのが多い。2MB。アホか

シングルバイナリの darkhttpd

-static つけて musl とリンクして一発

docker イメージにする

まず考えるのはこういうやつだ。

FROM scratch
ADD ./darkhttpd /darkhttpd
ENTRYPOINT ["/darkhttpd"]
CMD ["/"]

おっと、自分自身を配ってしまう。まあそれは darkhttpd に手を入れて解決してもいいんだが (起動したら自分を消すとか)、 -v /mnt:/ したときが最悪だ。そしてそれは必ず起きる。

そこで実際に書くのはこんなかんじだ:

FROM scratch
RUN mkdir /public
ADD ./darkhttpd /darkhttpd
ENTRYPOINT ["/darkhttpd"]
CMD ["/public"]

人間はおろかなので scratch イメージでも mkdir を試みてしまう。

結局、 multistage build でディレクトリをビルドするという感じになる。ディレクトリはファイルであり、ファイルはビルドして生成するものだということ、 空のディレクトリを作るのも天地創造以前は不可能だったということ、 busybox はいわばスコップだということなどの当然の事実ともう一度向き合うことになる。

FROM busybox
RUN mkdir /public

FROM scratch
COPY --from=0 /public /public
ADD ./darkhttpd /darkhttpd
ENTRYPOINT ["/darkhttpd"]
CMD ["/public"]

アホ向けにイメージ上げといた: https://hub.docker.com/r/iorivur/darkhttpd/

サイズ感として、70kB台というかんじです。

結論

mkdir を使うためだけに multistage build は草

gentoo TV

ゆく河の流れは絶えずして、しかももとの水にあらず。淀みに浮かぶうたかたは、かつ消えかつ結びて、久しくとどまりたるためしなし。

これは鴨長明の記した方丈記の冒頭の文である。むろん、この意味は gentoo のローリングリリースはなんと無常なのだろうか、ということだ。

たましきの都のうちに、棟を並べ、甍を争へる、高き、卑しき、人のすまひは、世々を経て尽きせぬものなれど、これをまことかと尋ぬれば、昔ありし家はまれなり。

多くのソフトウェアがリポジトリにある現代、その多寡や新しさなどで各々が自慢しあい競い合って、多くの昔から充実したソフトウェアコレクションがあると言ってみたところで、当時から今まで通用するドキュメントは一体どれだけあるのだろうか。鴨長明の随筆が訴えかけるソフトウェアの変遷の早さの虚しさは、800年を経た今でもなお谺している。

そういうわけで、

d.hatena.ne.jp

に書いてあることは嘘になってしまったので、記す。

上の怪文書の古いポイント

  1. PT2 のドライバの ebuild として示されているリンク先のダウンロードリンクが切れている
  2. てか PT2 の話を聞きたいわけではない
  3. ここがいまや嘘

    実は最新版のICカードリーダツールはB-CASに対応していません。なので、バージョンを落としてやる必要があります

2017 年に PT3 を発掘して、たまたま差した先が gentoo だったら、というわけで。

ところでここになんか ebuild がありますね

github.com

emerge --ask pcsc-lite pcsc-tools ccid libarib25 pt3
rc-update add pcscd default

なんか LED ついてるカードリーダが点滅を止めた

pcsc_scan
:
:
:
:
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B F0 12 00 FF ......
        Japanese Chijou Digital B-CAS Card (pay TV)

でるやんけ

あとは recpt1 --b25 --http 8080 --sid hd --device /dev/pt3video とかでいいと思います

その後のことは誰もしらない

動機

テレビコンテンツはあまりにも無常だなと思ったので

おまけ

地上波の流れは絶えずして、しかも再放送を除くともとの水にあらざるのだが、一方で低予算アニメはミクチャで配信されています:

mixch.tv

ミクチャは非常にリベラルなサービスなので、 /u/${uid} の ${uid} 部分が連番になっており、非常にスムースにユーザのクロールが出来るほか、ユーザ数の推移もなんとなく大公開状態で投資家にも安心です。 (もちろん

みたいなことはやろうと思えばいくらでもできるわけだが) その上、なんと動画を右クリックからの Open video in new tab で cloudfront 直リン即 DL というおおらかさです。一方でボリュームもシークバーも画質のバリエーションもループコントロールなにもかもないので (ミュート機能はある) 、やっぱりアメリカのような素朴な精神性が求められる。

上記の低予算アニメのように観ているのが本当に辛いコンテンツはシークしたいし、そうなるとこうしたアンチファサービスを通して自由のありがたみをこうして日々実感できるという仕組みです。

一方オタクは物理メディアを買った:

FreeBSDのVPSのストレージのリサイズ

序

このまえもボエ〜〜〜になっていながら物体を VPS 上でビルドしようとしたところコケるんでなんやねんワレになっちゃって>バルターSSD VPS Servers, Cloud Servers and Cloud Hosting by Vultr - Vultr.com←これはアフィリエイトリンクで、お前がここからインスタンスを作ると二ヶ月うちのサーバがタダになりますを見に行ったところ、なんか価格がかなり改定されていて同じ値段 ($5) でストレージが 15G から 25G 、メモリが 768M から 1G に増えとるやんけって気づいたので適宜やっていきます。

産→殺

まず新しいインスタンスを立ててスナップショットをねじ込む作戦でいきます、これが悪かった。退勤直前にスナップショットボタン押しといて帰ったらわちゃる戦略です。時間がかかるので。さてポチッと押しました。しばらく経ったら取れとります。新しいインスタンスをスナップショットから立てます。立てるのに時間かかる間によく考えたらウェッブコンソーのルから rc.conf パチパチしてしばかないと IP 疎通せえへんやん、はい。コンソーどこやねんってやってる間に、既存のインスタンスをリサイズするボタンを発掘。迷わず押したら即リサイズ完了したんで立てはじめたばかりの胎児状態のインスタンスは殺しました。また産んだらええ。

伸

で、シュシュシュとやっていきます。あなたは FreeBSD の gpart や fdisk の使い方を覚えてますか？私はまったく覚えてません。

# man gpart
:
:

読む気が起きないので適宜これ→→ 17.3. Resizing and Growing Disks

をよみます

よみましたね？

やっぱ GPT なんでケツが死んどって激 [CORRUPT] 状態なのでリカバーしてすっとしてしゃっとします。 VPS 上のディスク (実体は SSD 上)のアライメントって何？なんか車？と関係ありますかね

関係なさそうだけどあらゆる物体は 4k でアライメントされているものといないものだったらいたほうがなんとなくええんちゃう？？みたいに軽率にアライメントします。カインは 4k にアライメントされていないパーティションを、アベルは少し小さくても 4k にアライメントされたパーティションを捧げたが、ヤハウェはアベルの供物に目を留めカインの供物は無視したと聖書にもあります。そういうわけで→

# gpart recover vtbd0
vtbd0 recovered
# gpart show vtbd0
=>      34  52428733  vtbd0  GPT  (25G)
        34        94      1  freebsd-boot  (47K)
       128  31457119      2  freebsd-ufs  (15G)
  31457247  20971520         - free -  (10G)
# gpart resize -i 2 -a 4k -s 23G vtbd0
vtbd0p2 resized
# growfs /dev/vtbd0p2
Device is mounted read-write; resizing will result in temporary write suspension for /.
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/vtbd0p2, mounted on /, from 15GB to 23GB? [Yes/No] Yes  ←←←←←ここはお前がいれるんじゃ、ええな
super-block backups (for fsck_ffs -b #) at:
 31744192, 32768192, 33792192, 34816192, 35840192, 36864192, 37888192, 38912192, 39936192,
 40960192, 41984192, 43008192, 44032192, 45056192, 46080192, 47104192, 48128192
# df -h | grep vtbd0p2
/dev/vtbd0p2     22G    6.7G     14G    32%    /

よくみたら swap ないやんけ　そりゃ落ちるわ

じゃあはい、そういうことで足します。まあそれはどうでもええな。 growfs しておわりや。とっぴんぱらりのぷう

IO benchmark HAMMERFS @ DragonflyBSD 4.6.1 vs. ZFS @ FreeBSD 11.0 vs. btrfs @ Linux 4.9.6 (Archlinux 2017.02 live) on kvm guest + physical disk

概要

近年、どうのこうの、はい。そこで本調査では、飽きないかぎりやってきます。kvm guest でやるのは別に IO をどうのこうのとかではなく、単純にベアメタルの環境にあれこれインストールするのがだるいからです。

環境

HDD は古い余ってるやつを適当に使います。なんかまっさらですね。なんだこれ。

# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.28.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
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: 0x708a25e6

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976769023 976766976 465.8G  7 HPFS/NTFS/exFAT

CPU は Intel® Celeron® CPU G1840 @ 2.80GHzです。新しいけどしょぼいやつですね。メモリは 4GB しかありません。

セットアップ

HDD は場所によって速度が違ったりするのでなんか適当にパーティション切ってマルチブートにしてそれぞれで地元のパーティションでベンチするというわけにいきませんね。だるいね。このまっさらなディスク全体を kvm instance に食わせて自由自在に使ってもらうことにしましょう。 ……ウッ、 HDD を机の上に置いてたら低周波で気持ち悪くなってきた……

QEMU の設定

さて、まあアレやな。こんなもんでどないでしょう。本当は OS の性能を知りたいので SATA コントローラごと渡してしまうのが筋なんでしょうけど、ちょいちょいちょいということで、ほいほいほいです。

# #ほいほいほいの様子
# qemu-system-x86_64 -drive file=boot.img,index=0,if=virtio -drive file=/dev/sdb,cache=none,index=1,if=virtio -vnc :1 -m $(expr 1024 \* 3)M

host の環境

4.9.6-gentoo-r1 とのこと。そういうわけなのでひとことで完全な再現状態を表現するのは難しい。わかってくれ。

バトルするひとたち

最近の HAMMER が気になってるのでやります。 {ext4, btrfs}@linux, ufs@{Dfly, F}, ZFS@F あたりと戦わせますかね。

  • Archのアレ
  • Dfly
  • F

たたかい

mkfs & tar の展開 & ファイルツリーの削除 & fio (randrw) & fio (seqread)

もちろん OS ごとに実際は作業するわけですが、便利のために、タスクごとにわけてかきます。こう、行列の転置みたいなやつや。

とりあえずあらかじめ手元にやっときます。

% curl https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.10.1.tar.xz > l.tar.xz
% ip a
% darkhttpd .

こういうこまやかな準備がね…… こうして、こういうことをしようなどという考えです。

# wget http://192.16.XX.XX/l.tar.xz
# tar xf l.tar.xz
# cd linux*/

FS 作る速度

UFS@FreeBSD

# time newfs /dev/vbd1
:
:
0.165u 0.034s 0:06.33 3.0% 38+334k 7+774io 0pf+0w

ZFS@FreeBSD

そういえば、 ZFS って何をもって FS を作ったっていうんだ？ tank ？

UFS@Dfly

# time newfs /dev/vbd1
:
:
1.628u 1.629s 3:04.71 1.7% 21+244k 0+0io 0pf+0w

HAMMERFS@Dfly

# time newfs_hammer -L TEST /dev/vbd1
:
:
1.827u 1.124s 0:11.84 24.8% 17+65k 0+0io 0pf+0w

btrfs@Linux

# time mkfs.btrfs -f /dev/vdb
:
:
mkfs.btrfs -f /dev/vdb 0.00s user 0.01s system 5% cpu 0.231 total

mkfs コマンドの実家のような安心感。

FS づくり、 btrfs や ZFS のような一瞬で作り終わるやつと昔ながらの UFS 作るやつみたいな二種類しかないと思っていたら、 HAMMER は一瞬ではないが早く終わるみたいな馴染みのない挙動をしますね。

tar のコピー + 展開 + 削除

delete.sh はこれである↓↓

#!/bin/tcsh

foreach x ( `find linux-4.10.1` )
    rm $x >& /dev/null
end

UFS@FreeBSD

# time cp ~/l.tar.xz .
0.000u 0.089s 0:01.49 5.3% 32+264k 2+721io 0pf+0w
# time tar xf l.tar.xz
10.344u 6.586s 1:38.42 17.1% 71+174k 19+132558io 8pf+0w
# time ~/delete.sh
21.101u 76.885s 2:22.46 68.7% 296+298k 2980+114394io 0pf+0w

ZFS@FreeBSD

# time cp ~/l.tar.xz .
0.000u 0.052s 0:00.07 71.4% 22+184k 5+719io 0pf+0w
# time tar xf l.tar.xz
10.490u 7.289s 0:18.97 93.6% 70+171k 45+67682io 0pf+0w
# time ~/delete.sh
19.932u 74.867s 1:35.40 99.3% 299+299k 7372+0io 0pf+0w

UFS@Dfly

# time cp ~/l.tar.xz .
0.000u 0.124s 0:01.21 9.9% 8+98k 4+3860io 0pf+0w
# time tar xf l.tar.xz
10.276u 4.866s 1:23.05 18.2% 28+69k 1030+263146io 14pf+0w
# time ~/delete.sh
12.291u 62.247s 4:33.96 27.2% 28+1295k 0+228788io 0pf+0w

HAMMERFS@Dfly

# time cp ~/l.tar.xz .
0.000u 0.302s 0:00.81 37.0% 8+98k 4+2560io 0pf+0w
# time tar xf l.tar.xz
9.575u 2.845s 0:18.25 68.0% 27+67k 26+0io 14pf+0w
# time ~/delete.sh
10.909u 54.797s 1:07.90 96.7% 26+1186k 18+0io 0pf+0w

btrfs@Linux

# time cp ~/l.tar.xz .
cp ~/l.tar.xz . 0.00s user 0.04s system 96% cpu 0.038 total
# time tar xf l.tar.xz
tar xf l.tar.xz 7.92s user 3.05s system 75% cpu 14.594 total
# time ./delete.sh
./delete.sh 3.07s user 37.90s system 47% cpu 1:26.15 total

さて、おもろいな、全体的に UFS がしょぼすぎる。 btrfs は速い。 HAMMER もまあいうて速い。ZFS はそれらを追う形。

グラフにするとこうなる。こうして見ると、結構雰囲気が分かる。

f:id:Ieshoriveul:20170228094659p:plain

FIO (randrw, seqread)

UFS@FreeBSD

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/TdFL
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/BFej

ZFS@FreeBSD

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/QXhT
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/ZNbE

UFS@Dfly

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/TIMZ
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/XDef

HAMMERFS@Dfly

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/giFF
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/SQNL

btrfs@Linux

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/hUVf
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/SOOC

f:id:Ieshoriveul:20170228194708p:plain

btrfs がランダムアクセスに弱いですね。KVM 上の raw デバイスだとそういうことがあったような気がしなくもない。 HAMMERFS は思ったよりも健闘してますね。

まあざっくりこんなもんでいいでしょう。 MySQL のベンチとかもやろうと思えばすべきだと思いますが、まあ、ね。 もう少し真面目にやってくれなどの気持ちがあれば、お金をくれ次第 Ryzen + NVMe でベアメタルでやってやんよ。頼むで。