技術者見習いの独り言

これを使う。 CTAN: Package pkfix 以下利用例（論文ではないけれど） $ pkfix-helper Lions\ -\ 1977\ -\ Lions\'\ Commentary\ on\ UNIX®\ 6th\ Edition.ps lions-helper.ps Reading Lions - 1977 - Lions' Commentary on UNIX® 6th Edition.ps ... done. Total number of Type 3 fonts encountered: 16 Bitmapped fonts are typeset at 300 DPI. Finding character widths ... done. Reading TFM files ... done (103 TFMs in 193 scaling variations). Matching fonts: Processing Fn ... done (cmsl10 @ 1X, mismatch=0.53898). Processing Ff ... done (cmtt10 @ 1X, mismatch=0.19819). Processing Fg ... done (cmbx12 @ 1X, mismatch=0.36583). Processing Fi ... done (cmbx10 @ 1X, mismatch=0.42627). Processing Fk ... done (cmti10 @ 1X, mismatch=0.20169). Processing Fj ... done (cmbx12 @ 1.2X, mismatch=3.41283). pkfix-helper: Best match for Fj is rather poor Processing Fe ... done (cmssi10 @ 1X, mismatch=0.37342). Processing Fo ... done (cmr17 @ 1X, mismatch=0.12955). Processing Fb ... done (cmsl10 @ 1.2X,

本稿では，Linux カーネルで扱える時計のうち，PTP（Precision Time Protocol）という IEEE 1588 で策定されている高精度な時計をクロックソース[1]にする場合について追っていこうと思います。 Linux における時刻同期：NTP と PTP Linux や Windows，macOS といった現在の OS のシステムクロックは，一般的にはインターネットを通じて NTP（Network Time Protocol）が同期するようになっています。 NTP を使っていればインターネットに接続されている際には大きく時刻がズレることはなく，たまにネットワーク接続が失われていてもクォーツ時計は安物の振り子式ほど時間はズレません。 では，NTP は設計としてどのくらいの誤差が考えられているのでしょうか。NTP の設計者 David L. Mills 博士は自身が実装した PDP-11 向けの OS「Fuzzball」上の実験でそれを示しており，答えは数十ミリ秒です[2]。現代のマシンと OS ならば数ミリ秒までは迫れるかもしれません。ちなみにこの論文が発表された翌年には NTP version 2 が RFC から発行されています[3]。（現在は version 4。） NTP は日常的な利用には十分な精度があります。しかし，マイクロ秒やナノ秒といった単位での高精度さが目的ではありません。日本の NTP のサーバーとして有名な NICT（情報通信研究機構）は日本標準時の決定をしており原子時計も所有していますが，インターネットを介して NICT などのサーバーにアクセスしている時点でミリ秒やひどいときは数秒の遅れが発生するでしょう。LAN に NTP サーバーがあったとしても，アルゴリズムとして数ミリ秒の遅延を許容しています。そこで高精度な時刻同期のために存在するのが PTP です。 PTP とは PTP とは，ネットワークデバイス内の時計を高精度に同期する仕組みです。グランドマスタークロックと呼ばれる時計をマスターとして設置し，LAN の NIC たちがそれを元に同期するといったような仕組みになります。これによって，パケットのタイムスタンプをハードウェアで高精度に打つことが可能になったり，この PTP をクロックソースとし

コードカヴァレッジとは あるプログラムコードについて実行した際に、実際にコード中の命令を何割実行したかを数値に表したものを言う。 計測手法 方法は様々である。たとえば、Linux kernel の fuzzer である Google の syzkaller を用いれば、ユーザーアプリケーションへの入力を自動で変化させつつコードカヴァレッジを確認させてくれる。また、Linux kernel のコンフィグ自体にもカヴァレッジについてのコンフィグが存在する。これは masami256 さんのブログなどが詳しい 。 今回は gcc に組込みの手法でカヴァレッジテストを実行する手法についてメモをする gcov gcov がカヴァレッジ情報を .gcov という拡張子でダンプすることでカヴァレッジを確認できる。このコマンドは gcc に附属している。 使い方を見ていく このようなソースコードを用意し、次のようにコンパイルする。 $ gcc -fprofile-arcs -ftest-coverage -o cov_test cov_test.c すると次のようなファイルが用意されるはずだ。 $ ls cov_test cov_test.c cov_test.gcno これでカヴァレッジテストの準備は完了した。では、実際にカヴァレッジテストを行なってみよう。まずは、何も引数を与えずコンパイルしたコードを実行する。 $ ./cov_test ./cov_test: you need to pass arguments at least 1 $ ls cov_test cov_test.c cov_test.gcda cov_test.gcno .gcno に加えて .gcda が追加されている。このファイルがカヴァレッジテストの結果を格納している。ここで、 gcov コマンドを用いてみよう。 $ gcov cov_test.gcda File 'cov_test.c' Lines executed:38.89% of 18 Creating 'cov_test.c.gcov' cov_test.c というコード全体が 18 行で、そのうち 38.89% が実行されたということを物語っている。また、

前書き 兼ねてより自作キーボードに興味はあったのですが静電容量無接点式スイッチ（東プレスイッチ）の分割が実現できそうになるまでやらないと公言しておりました。以前より Custom Topre Guide など指針になるものがちらほら出てたようなのですが，今年の春先ごろ 銀鮭（ @sorojake ）さんが Booth で『 真の静電容量キーボードを作る本 』というものを出しているのを見掛け，どうやら PCB 設計勉強したり発注しなきゃいけないかなあと思っていたのですが，ありがたいことに Helix ベースのキットを出して貰えるということで，今回β2 版のテスターとして購入・製作しました。 長くなりましたが，次から実際に製作した過程とそのメモです。 実は初自作キーボード。 disclaimer β2 版のビルドログなので正式版とは異なる可能性があります。ご了承ください。 ビルドログ 道具・機材 静電容量Helix ラバードームタイプ(β2)キット NiZ のハウジングと軸×100 東プレ OEM キーボードのジャンクから剥いだラバードームと円錐型スプリング Hitachi 2050 という 80 年代ぐらいのワークステーション付属のものらしい。 いまならビットトレードワンさんが製作しているものを買うほうが簡単だし安いはず。 遊舎工房にも置いてあった。 これを買う場合はハウジングや軸もセットだから NiZ から何か買う必要はなし。 キーキャップ ENJOYPBT ABS Doubleshot Dolch 遊舎工房実店舗で購入 したけど，KBDFans で自分で買うほうが安いかも（ただしその場合届くまでのタイムラグがある） Pro Micro×2，OLED×2，LED (SK6812mini)×54，M2 スペーサー 8mm（OLED 保護アクリル用） いずれも遊舎工房の実店舗にて購入 アクリルプレート Helix 向け 2mm 厚（押し出し・クリア） 遊舎工房オンライン発注サービス利用 ジャンパ用銅線，絶縁テープ うっかり買うの忘れてたので製作直前で適当にホームセンターで購入 はんだこて先 (HAKKO T18-S9)，フラックス (HAKKO FS

かつてルネサスのサイトに掲載されていたが消滅してしまい，Internet Archive にもアーカイヴされていないがウェブ魚拓には残っていた。しかし話数とそのリンクを一覧するのが面倒なため以下にメモしておこうと思う。 第一話 第二話 第三話 第四話 第五話 第六話 こういうドキュメントは大切なので消さないで欲しいなあ……。

LoCの計測で一番簡単だと思われるのは次のような方法である。 find ./src -type f -name '*.c' -o -name '*.h' | xargs wc -l この例では ./src ディレクトリに含まれる C 言語のソースファイルとヘッダファイルについて全て wc(1) に食わせて行数を出力する，といったことを行なっている。 しかしこれでは，プロジェクトで利用する言語が増える度に find(1) のオプションを調整しなければならないし，コード内の空行やコメント行を全く考慮しない。 cloc そこで，実は cloc という便利な LoC 計測ツールがあるらしい。 https://github.com/AlDanial/cloc このコマンドでは，単純にプロジェクトのディレクトリを引数として渡すと，どういう言語がどのくらい使われており，それぞれに含まれる空行とコメントはどのぐらいか，といったことを一覧表示してくれる。 しかし，私はLinux kernelにおける各サブシステムがコード全体のうちどのぐらいを占めているかを知りたかったため，次のように cloc を実行した。 cd /usr/src/linux/ for dir in $(find . -maxdepth 1 -type d ! \( -name '.*' -o -name 'Documentation' -o -name 'LICENSES' -o -name 'samples' -o -name 'scripts' -o -name 'tools' \)); do echo $dir cloc $dir done > ~/linux_loc.txt すると linux_loc.txt には次のような出力が得られる。 ./arch 16005 text files. 15902 unique files. 4299 files ignored. github.com/AlDanial/cloc v 1.72 T=28.79 s (406.7 files/s, 90104.3 line

git clone したレポジトリを開いて git log でも眺めれば済む話なんですが，ちょっとコードが気になったとき Web ブラウザから閲覧してて最初のコミットはいつか，なんて気になったときにいちいち clone はしたくない。 そういうときは次の手順で古いコミットが確認できます GitHub の該当プロジェクトのページから「Insights → Network」を開く 「Shift + ←」あるいは「Shift + h」で一番古いコミットまでカーソルを移動 グラフ上の該当ノードをクリック ただし，cVim のような Vim 互換のキーバインドをブラウザに導入する extension を入れてるとキーバインドがこっちに取られるので微妙に上手くいかないこともある。 追記 モバイル端末のひとはがんばってスクロールしてください（コミット歴のページで Older をタップしつづけるよりかはマシかもしれない）

NTT が構築してきたインフラ網として，公衆電話網，地域 IP 網，そして NGN がある。 たとえば公衆電話では電話番号がそのままルーティングに活用されており，電話交換機の仕組みと市外局番・市内局番の関係を調べると実に面白い。 また，地域 IP 網によってブロードバンドが提供されるようになっても，効率性や合理性の観点から，ISP によっては PTR で逆引きすることによってある程度はグローバルアドレスから県ぐらいまでの特定は可能なようだ。これは，昔のフレッツ網は県間通信が制限されていたため，特定の県内網にしか出口を持たない ISP が居たり，あるいは全国でサーヴィスを提供する ISP であっても県内網ごとにネットワークの出口を設けていたためである。 さて，では NGN ではどうだろう。 NGN では IPv6 が割り振られ，近年は IPoE の利用によって NGN から払い出されるアドレスで直接インターネットに接続できるようになった。 このインターネットに接続できる IPv6 アドレスは，IANA から RIR（地域インターネットレジストリ）の APINC，NIR（国別インターネットレジストリ）の JPNIC，そして LIR（ローカルインターネットレジストリ）である指定事業者に払い出され，そこから ISP に払い出されることになっている。IPoE の VNE は指定事業者である。 https://www.nic.ad.jp/ja/ip/member/cidr-block-list.txt この VNE が管理する IPv6 プレフィックスは /30 である。このプレフィックスは NGN 内のサーバーに預けられており，払い出しや実際の割り振りの管理は NGN 内で実施されることになる。なので，ルーティングなどの合理性からいっても，地理的に近いユーザーは似たようなアドレスが払い出されるだろうということが想像できる。 実際に私の手元に降ってきている IPv6 プレフィックスはひかり電話契約有りなので /56 なので，そのような物理的な地理に基いたアドレス分けに利用できる長さは 56-30 = 26-bit ということになる。 さて，実際に IPv6 プレフィックスはどういう管理がなされているのか，実は判明しているらしい。 都道府県の識別は 2bit(

IPoE と IPv4 over IPv6 現在，インターネット接続性のある VNE が持っている IPv6 を，トンネリングせず NGN から直接払い出してもらう IPoE（ネイティブ方式）がにわかに普及している。 当初 NGN に接続している VNE も BBIX，JPNE，MF の三社だけに制限されていたが，現在は NNTCom や Biglobe，ASAHInet など増加している ところで，これら VNE がそれぞれ独自に提供している，IPv4 パケットを IPv6 上にカプセル化することによって IPv4 接続性を確保する方式として，4rd/SAM (RFC7600), MAP-E (RFC7597), DS-Lite (RFC6333) があると言われている。 MAP-E と DS-Lite については，JPNE と MF（ならびに MF 主要株主の IIJ）からそれぞれ技術詳細も出ており，確実にその方式を利用していることは明らかである。これらの方式については次を参照されたい。 あきみちさんが書いた『徹底解説v6プラス』 https://www.jpne.co.jp/ebooks/v6plus-ebook.pdf IIJ の技術ブログ「てくろぐ」 https://techlog.iij.ad.jp/archives/1879 とくに，MAP-E は JPNE 以外の VNE も多く利用しており，おそらくフレッツ網で使える IPv4 over IPv6 で一番多い手法なのではないだろうか。 ということで今回の本題は，「BBIX は本当に 4rd/SAM を利用しているのか」です。 4rd/SAM 出典： https://www.ietf.org/proceedings/83/slides/slides-83-softwire-10.pdf 上記の図のように，4rd/SAM は 6rd がやることの逆のヴァージョンとして生まれ，MAP-E の前身となっている。そしてどうやら RFC7600 は草稿のまま放棄されているようだ。なので，4rd も MAP-E 同様に A+P (Address + Port) の 48-bit を IPv6 アドレスに埋め込んで stateless に IPv6 へ変換する，ISP 側ではなく CPE

MTU/MSS の計算 IP ヘッダや Ethernet フレームの計算は結構大変だけれどもこのサイトを使えばわりとラクに導出できます。 https://baturin.org/tools/encapcalc/ たとえば MTU 1454 の環境（フレッツ網で ISP と PPPoE で接続した場合）の MSS は次の画像のとおり 1414 と計算可能です。 この MTU 1454 の根拠は，フレッツ網では PPPoE で接続する際，NTT の収容ビルから事業者装置までの間は L2TP で接続しており，そこで PPPoE ヘッダを認証用の PPP ヘッダだけ残して取り払い，PPP over L2TP の状態にすると，IP (20 byte) + UDP (8 byte) + PPP (2 byte) + L2TP (16 byte) = 46 byte なので，1500 - 46 = 1454 byte になります。 参考サイト さきほどのサイトでは L2TPv3 の計算はできるけど L2TP の計算が出来ないのが惜しいところ。 MTU の最適化 前述の手段で計算した値をルーターやクライアントに設定しても良いですが，既に通信が可能な環境ならばヒューリスティックに最適な MTU を導出することもできます。 ping コマンド PS C:\Users\orumin> ping -f -l 1424 -n 1 8.8.8.8 8.8.8.8 に ping を送信しています 1424 バイトのデータ: 8.8.8.8 からの応答: バイト数 =68 (1424 を送信) 時間 =3ms TTL=119 8.8.8.8 の ping 統計: パケット数: 送信 = 1、受信 = 1、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 3ms、最大 = 3ms、平均 = 3ms たとえば Windows なら，このようにして ping のパケットサイズを指定し DF ビットを立てます（＝分割を禁止する）。こうすると，MTU を超過するようなパケットを送出すると以下のようになります。 PS C:\Users\orumin> ping -f -l 1425 -n 1 8.8.8.8 8.8.8

OR 検索 grep -e 'pattern1' -e 'pattern2' grep -e 'pattern1\|pattern2' grep -E -e 'pattern1|pattern2' AND 検索 基本的にムリ。 grep -e 'pattern1' | grep -e 'pattern2' スマートではないが grep の結果を grep するのを何度も繰り返せば出来なくもない。 また，GNU grep は PCRE が利用できるのでそれを使えば grep -P '^(?=.*pattern1)(?=.*pattern2)' と書ける。 grep 以外で AND 検索 AND 検索のときはこっちを使うほうが良さそう。 awk '/pattern1/ && /pattern2/' sed -e '/pattern1/!d' -e '/pattern2/!d' 出典 https://unix.stackexchange.com/questions/55359/how-to-run-grep-with-multiple-and-patterns 以上 メモ PCRE は 1234，1324，1432，1423，2341，... のような {1,2,3,4} の順列にマッチする条件，とかも綺麗に書こうと思えば書けるらしい。マジかよ。 https://stackoverflow.com/questions/3101366/regex-to-match-all-permutations-of-1-2-3-4-without-repetition/3101385#3101385

2020-05-28T14:11+9:00 追記 これは SHA-1 を用いた RSA 鍵についての話で，OpenSSH 7.2 以降で生成・利用される RSA 鍵はまだ利用可能です 2020-05-28T19:27+9:00 追記 既に生成されている RSA 鍵でも ホスト・クライアントの両方が OpenSSH 7.2 以降 ホスト・クライアントの両方が OpenSSH 7.2 以降，ただしサーバー側は OpenSSH 7.4 以外であれば SHA-2 で署名するので大丈夫なようです。（OpenSSH 7.4 はバグがあるようです） ssh-rsaという名前は"公開鍵の形式"と"公開鍵を使った署名方式"の二つで使われていて、廃止対象となっているのは署名方式の方だけです。なのでOpenSSH 7.2以降を入れれば、鍵自体は古いOpenSSHで生成した物がそのまま使えます。 — いわもと こういち (@ttdoda) May 28, 2020 openssh-unix-devで指摘が出ていますが、OpenSSH 7.4のバグで、サーバ側が7.4だとrsa-sha2-256/512が使えると通知してこないのでssh-rsaでユーザ認証が行われてしまいます。これはユーザ認証時のみの問題で、ホスト鍵の確認には影響しません。 https://t.co/oyNVS08jGI — いわもと こういち (@ttdoda) May 30, 2020 本文 OpenSSH 8.3 がリリースされたとのこと OpenSSH 8.3 released (and ssh-rsa deprecation notice) [LWN.net] これに伴ない，ssh-rsa は将来的に deprecate になり，デフォルトでこの鍵形式を利用する機能自体が無効化されることが改めて告知されました。 サーバー側がこの形式を利用しているかどうを確認するには，`HostKeyAlgorithms` ディレクティヴから ssh-rsa を取り除いた上で以下のコマンドを使うこと ssh -oHostKeyAlgorithms=-ssh-rsa user@host `HostKeyAlgorithms` は ~/.ssh/config で利用する

URL を覚えていて手癖で簡単に入力できるという理由で Linux kernel を手元に持ってくるときにはよく git clone https://github.com/torvalds/linux.git をしてしまうのだが，ここで git checkout をマイナーバージョンまでではなくパッチバージョンまでのレベルで指定しようとすると，そのようなタグはないと言われる。 error: pathspec 'v4.1.8' did not match any file(s) known to git これは GitHub にあるミラーレポジトリはリリース候補のタグしか置いてないためで， kernel.org にある linux-stable の Git レポジトリを利用しないとパッチバージョンのタグが打たれていない。 git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linu.git このレポジトリを利用すれば，パッチバージョンでの変化や歴史を Git で追いたいときに便利だ。 $ git checkout v4.1.8 HEAD is now at 36311a9ec490 Linux 4.1.8 もっとも，Git の機能を利用せずコードを読むだけなら tarball をダウンロードするほうが手っ取り早い。 curl -LO https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.1.8.tar.xz

PowerShell で次を実行 $OutputEncoding = [Console]::OutputEncoding Get-Clipboard -Format Text | ssh macOS_host "iconv -f sjis -t utf8 | pbcopy" Get-Clipboard -Format Text | ssh Linux_host "iconv -f sjis -t utf8 | xsel --clipboard --input" 上記のコマンドで，リモートの macOS ホストと Linux ホストそれぞれのクリップボードにローカルのクリップボードのテキストが転送されます。 最初のほうで OutputEncoding を上書きしているのは，これをしないと Get-Clipboard コマンドレットの出力が us-ascii でエンコードされるので，クリップボードの中身が日本語だと化けます。ちなみに ASCII のテキストなら Get-Clipboard -Format Text | ssh macOS_host "pbcopy" だけで済む。 逆に，macOS や Linux のホストのクリップボードを手元に持ってきたいときは，macOS なら pbpaste ，Linux なら xsel --clipboard --output を使ってください。 あと言わないでもわかることだとは思うけど，PowerShell の Get-Clipboard/Set-Clipboard コマンドレットや macOS の pbcopy/pbpaste コマンドはデフォルトで使えますが Linux の xsel コマンドは自分でインストールしなくても必ず存在するとは限りません。 ちなみに，とくに Windows ホストに外部コマンドをインストールしてはいけない縛りとかないのなら， win32yank を導入するのはオススメ。

前提 VR HMDで VR 空間に埋没してかっこいい空間を広々使ってお仕事したい 現実世界の PC がモニタ 1 枚しかない 画面出力端子を適当なドングルで埋めて fake monitor を召喚する手もあるがソフトウェアで解決したいところ どういうことなのか 実は去年末に Oculus Quest を購入していました。そのうち記事にするかも。それはそれとして，Oculus Quest を買ったのは『狼と香辛料 VR』が気になってた，というのと，サイバーパンクでありがちな，半透明のウィンドウが自分を取りかこむようにぶわーっと浮いて広がってるやつ，あれをやりたいという理由でした。 みなさんお気付きかと思いますが，後者の目的なら HoloLens とか買うほうが実現しやすいとは思います。でも高い。しかし Oculus Quest はスタンドアローンで 6DoF なワリには安い。それに Oculus Go を買うぞ買うぞと言い続けて結局 Oculus Quest 開発中の発表を見てしまったので，発売したら絶対買うぞ！と思ってました。それでいい加減に腹決めて買ったのが去年末。 で，VR 世界でデスクトップ環境を実現する方法はいくつかあります。たとえば私の理想に近いのは Linux のデスクトップ環境である SimuraVR でしょう。しかしこれは HTC Vive か Vavle Index あたりでしか利用できないようです。Oculus Rift S なら OpenXR に対応しているので，かろうじて使えるようですが，Oculus Quest は PCVR に対応しているとは言えども Oculus Link が必要で，この Oculus Link は Windows の Oculus ランタイムアプリに依存しています。血も涙もない。 故に Oclus Link+Virtual Desktop で，なんとかマルチモニターを仮想的に実現して気分を良くしたかったのでした。 やりかた ハードウェア 素直にやるなら，ハードウェアでごまかすことが手っ取り早いです。 有名な手段としては，GPU の DP 端子に DP→VGA 変換器を取り付けて，Dsub 15-pin の VGA 端子，これの 2-pin と 7-pin を 102Ω 抵抗で

本日誕生日のおるみんです。 みなさんは Rockbox というファームウェア／カーネルをご存知でしょうか。 単一メモリ空間，シングルプロセスで動作するファームウェアで，簡単なスレッドスケジューラを備えることによってマルチスレッドで動作可能な， 主にディジタルオーディオプレイヤー（DAP）上で動作するオープンソースファームウェアです。 初期には仏 Archos 製の MP3 プレイヤーに不満を持ったユーザーが homebrew プログラムの動作方法を見つけ，独自実装したのが始まりで韓国 iriver 製 DAP や米 SanDisk の Sansa，東芝の Gigabeat シリーズなど様々な DAP へ porting されています。 わけても初期のSony ネットワークウォークマンや大半の米 Apple iPod シリーズにも対応していることで，2000～2010 年ごろの DAP ユーザー（のごく一部）に広く知られています（広く？）。 Rockbox の場合，iPod の純正 Apple OS と違い Album Artist タグに対応してますし FLAC は再生できますし crossfeed やパラメトリックイコライザ（low-shelf，high-shelf，peaking * 8 の合わせて 10 バンドで Q 値も設定できる）など再生時のパラメータも細かく設定できるため，ギーク向きの良いファームウェアなのですが，不満もあります 何をしたいか ここまで前置き，本題は Rockbox は意図的に複数の値を持つタグを読み捨ててしまうというところです。 音楽のメタデータは MP3 や AAC に対応する ID3 タグが知られていますが他にも Ogg Vorbis や FLAC に対応する Vorbis Comment，Monkey's Audio に対応する APE tag などが存在します。 ID3 タグの場合は ID3v2.3 だとスラッシュ，ID3v2.4 だとヌル文字を区切り文字にし複数の値を書いていけば良いという仕様がありますが，今回の記事では考えないことにします。今回は FLAC で使われる Vorbis Comment について複数の値に対応する方法を考えてみたいと思います。 Vorbis Comment Vorbis