Linux memo 2024/03/20 自宅サーバ編

Beelink MINI-S12 Pro(Amazonアフィ)

● 経緯
自宅サーバ用のマシンとして使っていたIntel NUC DN2820FYK(過去の記事)が急に不調になり、どうもハード的に怪しいので、これを機に、少し前に買ったけどほとんど使っていなかったBeelink MINI S12 Proを代わりに当てがることにした。
実はこのIntel NUCマシン壊れるのは2度目で、1度目の2021年3月頃はちょうど近くに全く同じ型番のガワが中古で売られてたので購入しSSDだけ移植してやり過ごしていた。果たして今回は?

● ソフトの設定変更
Beelink MINI S12 Proは、2.5インチの空きベイもあるので、前のマシンで使っていた2.5インチSSDをセットして試しに電源入れてみたらなんとそのまま動いた。Linuxのデーモン類も全部問題なし。EthernetだけがUUID違いで弾かれたので再設定、とはいえ /etc/sysconfig/network-scripts/ の ifcfg-enp1s0 を参考に新しくはえたeth向けにコピーし直した程度。Linuxもgeneric kernelが当たり前になったためか、何も設定しなくても動いてしまい、時代の変化を感じる。
Beelinkといえば、技適とかWindowsのライセンスがとかでグレーと言うかアウトだけど、ライセンスはLinuxにするので問題なし、技適はBluetooth/WiFi使わないので問題ないということにする。Bluetoothは、lsusbによれば、AX201がUSBに生えてきてhci0が作られていたが、down状態なので、このままとする。WiFiは、lspciによれば、AX101D2WがPCIeにつながっているが、dmesgによるとiwlwifiが合致するfirmwareがないとかメッセージを出して動いていないようだったので、このままとする。

● Beelink S12 Proの設定
BIOS更新も一切出さないようなメーカなので、あまりBIOSを変更するのもどうかと思ったけど、下記を変更した。
次の2点はどちらもBeelink MINI S12 Pro N100ベンチマークと改造 - nabeの雑記帳より。
>Advacnced→Power→GT→RC6 Enable。これがオフだとアイドル8W。(アイドル時の消費電力が6W。)
>Chipset→PCH-IO Configuration→State After G3→S0 Stateを設定すると自動電源オンになります。
あと、PL1 PL2を5000(mW)にして消費電力(発熱)を抑えておく。
VT-dやらASPM L0sL1やらRC6やらを触ったけど、実測する限りはほとんど消費電力は変わらなかった。(Linuxでコンソールしか使ってないというのもあると思う)

● ethtoolのautonegの話
2021年1月ごろにTwitterで、autoneg off duplex fullだと問題がある、というような趣旨のつぶやきをした。今回改めて確認してみるに、どうも、autoneg offにするとAutoMDI/MDI-Xも無効になってしまうのが原因かなと思い、
ethtool -s enp1s0 autoneg off mdix on speed 100 duplex full
を試してみたけどこれもダメだった。ただ、
ethtool -s enp1s0 autoneg on speed 100 duplex full
だと問題なかった。これだと、autoneg on でも Advertised link modeが100baseT/Fullになるので、1000Base-Tではなくて100Base-TXでリンクしてくれるようになる。今でもリンクアップアイドルで200-300mWくらいは変わるみたいなので、動かしっぱなしの負荷の低いマシンだと多少は意味があるかもと思う。(相手のハブ側も同様に電力食うだろうし)
いずれにしても、1000Base-Tが当たり前になった現代では autoneg on 固定のままのほうがよいと思っていたほうが良さそう。

Linux memo 2023/12/30 glibc errno

Pofixではerrnoはthread safeとされていて、Linux(というかglibc)もthread safeだが、世の中にはそうでないシステムもあるらしく、そのせいでerrnoを使おうとすると「thread safeかどうか確認しろ」と無慈悲な指摘をするヘンテコな解析システムがあり、そいつを分からせてやるために無駄な調査を行うハメになった。

glibcのこのへんを見ると良い。
/csu/errno.c
/csu/errno-loc.c
/stdlib/errno.h

glibcがthread localに対応したのは下記かららしい。裏付けできなかったがおそらくこのタイミングでerrnoも対応したと思われる。
glibc-2.3 (2002-10-02) thread local
https://sourceware.org/legacy-ml/libc-alpha/2002-10/msg00048.html

Linuxがいわゆる昔のLinuxThreadsからネイティブスレッド(NPTL)に変更されたのはLinux-2.6.0からで、Linux-2.6.0は 18 December, 2003 にリリースされている。
https://kernelnewbies.org/LinuxVersions

errnoをgdb上から確認するために__errno_location()を直接呼ぶ方法も参考に。

Linux memo 2023/08/12 gdb,C++あたり

● gdb上でerrnoを表示する方法
(gdb) print *((int*(*)())__errno_location)()
(ただしglibc限定)
関数ポインタのキャストの型なにもわからない

● gdb中にシグナル受けて止まってうぜぇ
define nosignals
handle SIGPIPE noprint
handle SIGPIPE nostop
end
使いたいときほど設定忘れててすぐに使えずに困ることがあまりに多すぎたのでメモっとく

● ときどきSIGSEGVするプログラムをgdbで捕まえたい
define sigsegvrun
nosignals
break _exit
commands
run
end
end
時々**するプログラムを起こるまで繰り返し実行する用途に応用は利くと思う。

● debug情報が別ファイルになってる場合のgdbの設定方法
$ objcopy --add-gnu-debuglink=test.debug test
で、testというファイルにtest.debugを見に行けという情報を .gnu_debuglinkセクションに記録する
(gdb) set debug-file-directory ./debug
さらに別ディレクトリ(./debug/)にdebug情報入りelfファイルがある場合の設定方法
安定のmasamiさんブログからのコピペですすみません、、
elfファイルのdebugセクション分割とgdbの分割されたデバッグ情報のサポート機能めも
https://kernhack.hatenablog.com/entry/2016/07/18/161802

● Effective Morden C++ 項目7の補足
Effective Morden C++ 項目7「オブジェクト作成時の () と {} の違い」
には、ctorを呼ぶときは () ではなくて {} のほうがよいとしつつ、それが通用しない例をつあげている
- A) auto型変数で受ける場合
- B) initializer_listを引数に取るctorを持つclassの場合
B)の代表例として std::vector<>を提示している。

が、本に記載のない例として std::string(size_type, charT) もある。
- std::string('a', 6); // "aaaaaa" size==6
- std::string{'a', 6}; // {0x61, 0x06} size==2
参考:basic_string::コンストラクタ - cpprefjp C++日本語リファレンス

ちなみに英語でのカッコはこう呼ぶらしい
- () parentheses , round
- {} braces , curly
- [] brackets , square

「ソフトウェア・ファースト」読んだ

Amazonアフィリンク

IT技術を活用できるように変革をするべきとうったえる本。ビジネスは顧客の利益となるよう常に変化していかなければならないと前置きした上で、IT技術が社会の変革をもたらすからこそ、IT技術を生かしたビジネスモデルやマインドや組織づくりをしていく必要がある、と主張している。

「ソフトウェア」と本書では言っているものの、あまりソフトウェア特有の視点が多くなく、どちらかというとネットワークやシステムづくりも含めたIT技術と主張したほうが本書の論調にあっているように思う。それらは、IT部門や現場だけでなく、管理層や役員も含めた全社員にかかわるような変革をもたらすからこそ、担当者任せにせず、各々がビジネスの進め方を常に見直していくべきで、またそのために、内製化や内製化とはいかなくても自社でIT基盤をコントロールできるような組織へと変化していかなければならない、という主張が特に強調したい点なのだと思う。

ただ、個人的にその主張がいまいち響かなかった。確かに言ってる内容はそのとおりだと思うし、それらをていねいに主張してはいるんだけど、個人的にはそれらが「当たり前のことを言っているだけ」に感じられた。私はかなり前から根っからのソフトウェア開発者(だと思っている人)なので、主張そのものはもう大昔から何度も聞いてきたことの繰り返しにしか思えなかった。

著者は、DEC・Microsoft・Googleという経歴とのことで、根っこのマインドとしては私に近いはずだと思う。そんな著者が、いわゆる日本の大企業を相手にコンサルしていった先に本書のような主張が出るということは、逆に、私や著者が当たり前と思っているそんなマインドが全然当たり前になっていないというのがまだまだ現在の実情なんだろうなというように思う。

というわけで、IT技術がビジネスモデルや組織をどう変えていかざるをえないように追いやっているのかの話を今一度ちゃんと学び直したい人向けの本。逆に、データサイエンティストやAI技術といった新しく盛り上がっているソフトウェア技術がもたらす新たなパラダイムシフト、みたいなのを期待する人はあまり読まなくてもいいかと思う。

P91「本来、自動車は移動のための手段です。」 走る歓び、みたいな主張をするメーカもあり、変革したくない・変革する必要がないという振り戻しが起こっていたりもしていて、象徴的な文章だなぁと思った。

P109「内製化するのは現実的ではないと思う方もいらっしゃるでしょう」 日本の大企業を相手にしたときにこういう主張が必要になるのだろうなと感じた。開発終わっても社員だと切れないとか、多重下請け問題とか、そういうことを言っている間にもはや自部門や自社でやりきるというマインドすら失われてしまった組織や会社も当たり前のように目にしてしまう今日このごろ。

P271「リモートワーク」 この本はコロナの前に書かれた本だからどちらかというと必要性については抑制的だけど、逆に今は著者はどう考えているのだろうかとも思った。人手人材不足も待ったなしになった今の日本だと、皆が平等に働くようなやり方ではなく、アメリカのように少数の猛烈に働く人を中心とした開発体制にでもしないと厳しいのだろうか。

Amazonアフィリンク

TCP輻輳制御アルゴリズムについての本。インターネットとTCPの位置づけを歴史踏まえながら概要説明し、TCPの輻輳とそれに対処するアルゴリズムを解説し、近年の輻輳対策のトレンドを紹介している。

ほぼタイトルしか見ずに買った私のせいではあるけど、本書はTCPの本ではなくてTCP輻輳の本だった。TCP輻輳制御アルゴリズムの話で2/3くらいを占める。さすがに私も細かいとこはもういいやとなってしまった。読んでて予感はしたけど著者はやっぱりNTT本社研系の人だった。

インターネットのようなノード間通信の延長にあるネットワークでは輻輳他のトラブルに対する制御が極めて難しい、という話はもはや説明するまでもない前提で話が始まるけど、一般人には「輻輳」という用語すら知られていないのが実際なので、このあたりはもっと丁寧に書くべきだったのではと思った。まぁこの本は一般人を相手にしていないから気にしてないというだけなのかもしれない。

本書を読んだ感想として、専門家でもない人が抑えておくべきポイントは、輻輳制御は難しい、Reno CUBIC そして新顔のBBR、広帯域高遅延や無線(ケータイ)をどうするかがトレンド、というあたりまでかなとは思っている。第7章は、成果アピールや予算獲得的な話にしか見えなかったのでスルーで。

というわけで、TCP輻輳制御アルゴリズムに入門したい人におすすめする本。逆に、そうでない人は正直読まなくていいんじゃ、とも思ってしまった。

P107「Linuxにおける輻輳制御アルゴリズムの実装」LinuxだけでなくWindowsやBSDについても触れてほしかった。私は理論上の話ではなくて現実世界の話のほうに興味があるので。

P177「既存アルゴリズムとの親和性」理論屋さんがハマりやすい話なのかなと思った。皆が新しいアルゴリズムに一気に乗り換えるのが理想だけど、現実はそうはいかない、進化論のような生存競争だと他者を押しのけるのが正解だけど、ネットワークだとそれがいいとは限らない。既存アルゴリズムのままの人もそれなりに通信できるように公平性を保つにはどうやればよいのか。

P201「パケットロスのおもな要因はバッファ溢れによるものです」近年は通信機器も高性能化したので、信頼性が上がっている反面、安易にバッファを増やして遅延増加を招いているだけでなく、溢れたときにバースト的にパケロスを起こしてしまう、という実情の話、あまり考えたこともなかったので参考になった。確率的に早めにロスさせたり帯域制御したりして基幹のノードでパケロスが頻発しないように対処したりしているのだろうか。

Amazonアフィリンク

中から大規模のソフトウェア開発の実例から、ソフト開発がうまくいかないことによる損失が見過ごせないほど大きいことをデータで示しつつ、旧来のウォーターフォール的なやり方からアジャイル的なやり方へ転換すれば改善できると説いた本。

アプローチとしては、いわゆる「アジャイル宣言」にほぼ沿っている。つまり、エクストリームプログラミング・スクラム・アジャイル・ペアプログラミング・CI,CD・Devops・テスト駆動・リファクタリング、といった内容になる。なぜこれらが良いのかについての根拠が若干弱い気がするが、いずれにせよ、旧来からの開発のやり方から脱却するためのプラクティスとして説いている。

ただ、これらプラクティスのエッセンスという意味では、この本を読むよりも、それぞれの内容そのものにフォーカスした別の本を読んだほうがいいんじゃないかと私は思ってしまった。この本ならではの点が何かを考えてみるに、開発方法の転換を図りたくてもなかなかできないような現場にて上を説得するための材料や根拠をコンサル視点っぽく提供してくれること、なのかな。

とはいえ、最後の章が典型的だけど、やろうと思ってもなかなかできないのが現実で、ひたむきに真摯に取り組み続けることの難しさみたいな精神的な面を語っていたりもする。本著のタイトル「レガシーからの脱却」はそういうところなのかとも思う。

というわけで、アプローチのエッセンスについてはそれぞれの個別の本を参照したほうが良いと思う。アジャイル的な話の中身をわかっちゃいるけど実践できないような停滞感のある現場を知っている人がそれでもやっぱり転換したいと思ったときに手に取るのがよいではないかと思う。

ページ28 2.3.2蔓延「バグ修正に多くの時間を費やす人は少ない」え?逆じゃないの?バグ解析や修正に時間がかかることが多いんじゃないの?ものすごく違和感を感じる記載だった。

ページ63 5章プラクティス1「開発の半分もの時間が要求収集に費やされていた」 ソフトウェア開発者がソフトウェア開発をやっていないというのはもはやこの業界のあるある。仕様を取りまとめたりチェックシートを整備したり進捗確認したりバグチケットの取締をしたり、そういう中間管理の仕事をする人が*割を占める。*には好きな数字を入れてくださいな。

Unicodeの闇

● 前置き
世界中の言語の文字を統一的に扱えるようにするという野望を実現するには、自らの常識にとらわれないようにしつつ真摯にUnicodeの仕様に向き合わねばならない。

● Unicodeという名前の誤解
「16bitで1文字にすれば世界中の文字を扱えるやろ」のノリでUnicodeが始まったため、今では UTF-16 と呼ばれているエンコーディングを、昔はUnicodeと呼んでしまっていた。のちに16bitでは扱いきれない事に気づき、16bit超えも考慮したエンコーディングに拡張し(サロゲートペア)、UTF-16以外のエンコーディングも認めた上で、文字集合としてのUnicodeとエンコーディングとしてのUTF-16とを概念として分けた。

● UTF-16のワナ
文字終端が \0 ではなくて \0\0、サロゲートペアのせいで固定長ではない、ビッグエンディアンvsリトルエンディアン、BOMのありなし、そもそも圧倒的に世の中に多いASCIIなテキストも全書き換えの上サイズが倍に、などの理由により UTF-16 が実は非常に使いにくいことがわかってしまった。その結果、7bitがASCII互換となるように意図して作られた UTF-8 が実質的なスタンダードとなった。

● 「2バイト文字」のワナ
日本語含むCJK地域で特に、Unicode以前から使われていたエンコーディングのせいで、非ASCIIな文字のことを「2バイト文字」と誤って呼んでしまうことが未だにある。「マルチバイト文字」とでも呼んだ方がいいのかもしれないけど、まぁ 非ASCII で十分かと思う。UTF-8で日本語だと、ひらがなでさえ3バイト、一部漢字は4バイトになる。そもそもの話として、文字数からバイト数を推定してはいけない。

● 右から文字
横書きの時に左から右へと文字を並べる言語が多いが、そうでない言語もある(アラビア語・ペルシャ語)。どちらかに統一された文章ならばまだよいが、混在する場合にややこしい。ALM LRM RLMあたりを普通は使うが、LRO RLO のように強制的に変更するものもある。RLOはWindowsでウィルスに偽装したファイルの拡張子.exeをわかりにくくするために使われたりもした。

● 合成文字
日本語は通常「は」も「ば」も「ぱ」も独立した1つのコードポイントとして扱うことが多い(合成済み文字)。しかし「は」に濁点記号を足すというやり方もできる。「は」(U+306F) 濁点(U+3099) と続けて並べると、フォントとレンダリングシステムが対応していれば、「ば」という見た目で表示され、単独コードポイント(U+3070)のものと見た目では区別がつかない。しかしコードポイントは異なるので、うまく検索できなかったり、非対応アプリでコピペできなかったりする。さらに「文字数ってどうやってカウントするの」問題も起こる。CJKでは合成文字はあまり使われずに合成済み文字(専用のコードポイントを用意する)が多いが、欧米ではちょこちょこ使われ、アラビア語ではどんなふうに合成されるかが比較的ややこしく、タイ語は非常に難しい。なお、レンダリングシステムが難しくなる(ぶら下げのような考えも必要)が、Unicodeとしての扱いはそこまででもない。

● ノーマライズ
上の合成済み文字と合成文字とを相互変換するようなもの、ごめんうまく説明できない。ただし「株」を「木」と「朱」に分解するようなことまでは行わないため、特にCJKでは違和感を覚えるし、分解するのかしないのかわかりにくい例も多い。また、CJK部首補助・康煕部首、という部首(類)として使われることのみを想定した文字もある、らしい。

● IME
CJKでは、キーボードから直接文字を入力するのではなく、キーボード(やフリック)からは基本的な文字のみを入力して文字の組み合わせから別の文字に変換してから入力を完了させる仕組みを使っている。一般的にIMEと呼ばれるこの仕組みは、CJK以外の人からは存在すら知られていないほど理解されていない。

日本語や中国語(繁体字・簡体字)は主に「読み」を表す基本文字を入れて変換をする。ただし中国は文字が複雑でたくさんあるから他の方式もあり、漢字の部品や書き順を選んで漢字を絞っていく方式もある。

ハングルも読みを表す基本文字を入れる点は同じだが、変換は全く別の文字にすることではなく、複数の基本文字を2から4つ組み合わせて文字を組み立てていくようなイメージの操作になる。合成文字ではなく合成済み文字を出力とする。韓国ではUnicodeができる前からコンピュータが使われていたため、変換のために専用のIMEを使うのが一般的である。このため、IME変換とノーマライズがいまいち噛み合わない仕様になっている。

● 空白文字
U+0020のいわゆるスペース以外にも空白っぽい文字がたくさん存在する。このため、文字の間にしれっと挟むことで検索やコピペ対策になったりする。異体字セレクタのような制御文字も見た目に現れないという意味で同様に使える。

● 意味がグリフで変わる
○(U+25CB)は白丸、●(U+25CF)は黒丸、とUnicodeでは定義されているが、実際に表示させると、○は中抜き丸、●は塗りつぶし丸、となる。つまり、背景黒に白い文字という環境だと、○は黒色に、●は白色になる。ちなみに、U+1F534(LARGE RED CIRCLE)なんてのもあるらしい。本当に赤い。マジ闇。

U+1F5FE は日本列島の絵文字であるが、一般的に本州・四国・九州・北海道っぽい4つが描かれる。位置的に沖縄を描きにくいのはわかるけど、北方領土を描くかどうかで領土問題が起こる。例えばロシアが北海道を消したグリフのフォントを作るかもしれない。

U+1F52B はピストルの絵文字であるが、銃規制のゴタゴタの影響か水鉄砲にする話もある。

U+1F363はお寿司の絵文字であるが、にぎり寿司の絵であることは多いものの、何のネタなのかが各社のグリフで異なることが話題になったこともある。

このようにグリフで意味が簡単にねじ曲がってしまう例は非常に多い。

● 国旗の絵文字
国旗の絵文字は、Unicdeのコードポイントが用意されているわけではない。ISO 3166-1に従いRegional Indicatorを2つ組み合わせてCombining Characterとして表現する。このため、表示できるかどうかは環境に依存し、フォントだけでなくレンダリングシステムにも依存する。将来国旗が変更になった場合、旧国旗と新国旗をどう使い分ければいいのだろうか。政府が変わったとかならホント政治問題そのもの。

● 例の文字
KPS 9566は北朝鮮で使われる文字コードだが、トップの指導者の名前が文字コード的に連続するようにするための専用領域が存在する。これを一般的に「例の文字」と呼ぶ。しかしUnicodeに採用はされていない。笑い話のように思えるかもしれないが、明治(U+337E)・大正(U+337D)・昭和(U+337C)・平成(U+337B)・令和(U+32FF)をねじ込んでいる日本はどうなんだという気もする。

● 更新履歴
2022/09/06(Tue)誤字脱字を訂正

アイテム

月別 アーカイブ

ウェブページ

Powered by Movable Type 7.9.0