● 経緯
自宅サーバ用のマシンとして使っていた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 固定のままのほうがよいと思っていたほうが良さそう。
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
● 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
IT技術を活用できるように変革をするべきとうったえる本。ビジネスは顧客の利益となるよう常に変化していかなければならないと前置きした上で、IT技術が社会の変革をもたらすからこそ、IT技術を生かしたビジネスモデルやマインドや組織づくりをしていく必要がある、と主張している。
「ソフトウェア」と本書では言っているものの、あまりソフトウェア特有の視点が多くなく、どちらかというとネットワークやシステムづくりも含めたIT技術と主張したほうが本書の論調にあっているように思う。それらは、IT部門や現場だけでなく、管理層や役員も含めた全社員にかかわるような変革をもたらすからこそ、担当者任せにせず、各々がビジネスの進め方を常に見直していくべきで、またそのために、内製化や内製化とはいかなくても自社でIT基盤をコントロールできるような組織へと変化していかなければならない、という主張が特に強調したい点なのだと思う。
ただ、個人的にその主張がいまいち響かなかった。確かに言ってる内容はそのとおりだと思うし、それらをていねいに主張してはいるんだけど、個人的にはそれらが「当たり前のことを言っているだけ」に感じられた。私はかなり前から根っからのソフトウェア開発者(だと思っている人)なので、主張そのものはもう大昔から何度も聞いてきたことの繰り返しにしか思えなかった。
著者は、DEC・Microsoft・Googleという経歴とのことで、根っこのマインドとしては私に近いはずだと思う。そんな著者が、いわゆる日本の大企業を相手にコンサルしていった先に本書のような主張が出るということは、逆に、私や著者が当たり前と思っているそんなマインドが全然当たり前になっていないというのがまだまだ現在の実情なんだろうなというように思う。
というわけで、IT技術がビジネスモデルや組織をどう変えていかざるをえないように追いやっているのかの話を今一度ちゃんと学び直したい人向けの本。逆に、データサイエンティストやAI技術といった新しく盛り上がっているソフトウェア技術がもたらす新たなパラダイムシフト、みたいなのを期待する人はあまり読まなくてもいいかと思う。
P91「本来、自動車は移動のための手段です。」 走る歓び、みたいな主張をするメーカもあり、変革したくない・変革する必要がないという振り戻しが起こっていたりもしていて、象徴的な文章だなぁと思った。
P109「内製化するのは現実的ではないと思う方もいらっしゃるでしょう」 日本の大企業を相手にしたときにこういう主張が必要になるのだろうなと感じた。開発終わっても社員だと切れないとか、多重下請け問題とか、そういうことを言っている間にもはや自部門や自社でやりきるというマインドすら失われてしまった組織や会社も当たり前のように目にしてしまう今日このごろ。
P271「リモートワーク」 この本はコロナの前に書かれた本だからどちらかというと必要性については抑制的だけど、逆に今は著者はどう考えているのだろうかとも思った。人手人材不足も待ったなしになった今の日本だと、皆が平等に働くようなやり方ではなく、アメリカのように少数の猛烈に働く人を中心とした開発体制にでもしないと厳しいのだろうか。
]]>TCP輻輳制御アルゴリズムについての本。インターネットとTCPの位置づけを歴史踏まえながら概要説明し、TCPの輻輳とそれに対処するアルゴリズムを解説し、近年の輻輳対策のトレンドを紹介している。
ほぼタイトルしか見ずに買った私のせいではあるけど、本書はTCPの本ではなくてTCP輻輳の本だった。TCP輻輳制御アルゴリズムの話で2/3くらいを占める。さすがに私も細かいとこはもういいやとなってしまった。読んでて予感はしたけど著者はやっぱりNTT本社研系の人だった。
インターネットのようなノード間通信の延長にあるネットワークでは輻輳他のトラブルに対する制御が極めて難しい、という話はもはや説明するまでもない前提で話が始まるけど、一般人には「輻輳」という用語すら知られていないのが実際なので、このあたりはもっと丁寧に書くべきだったのではと思った。まぁこの本は一般人を相手にしていないから気にしてないというだけなのかもしれない。
本書を読んだ感想として、専門家でもない人が抑えておくべきポイントは、輻輳制御は難しい、Reno CUBIC そして新顔のBBR、広帯域高遅延や無線(ケータイ)をどうするかがトレンド、というあたりまでかなとは思っている。第7章は、成果アピールや予算獲得的な話にしか見えなかったのでスルーで。
というわけで、TCP輻輳制御アルゴリズムに入門したい人におすすめする本。逆に、そうでない人は正直読まなくていいんじゃ、とも思ってしまった。
P107「Linuxにおける輻輳制御アルゴリズムの実装」LinuxだけでなくWindowsやBSDについても触れてほしかった。私は理論上の話ではなくて現実世界の話のほうに興味があるので。
P177「既存アルゴリズムとの親和性」理論屋さんがハマりやすい話なのかなと思った。皆が新しいアルゴリズムに一気に乗り換えるのが理想だけど、現実はそうはいかない、進化論のような生存競争だと他者を押しのけるのが正解だけど、ネットワークだとそれがいいとは限らない。既存アルゴリズムのままの人もそれなりに通信できるように公平性を保つにはどうやればよいのか。
P201「パケットロスのおもな要因はバッファ溢れによるものです」近年は通信機器も高性能化したので、信頼性が上がっている反面、安易にバッファを増やして遅延増加を招いているだけでなく、溢れたときにバースト的にパケロスを起こしてしまう、という実情の話、あまり考えたこともなかったので参考になった。確率的に早めにロスさせたり帯域制御したりして基幹のノードでパケロスが頻発しないように対処したりしているのだろうか。
]]>中から大規模のソフトウェア開発の実例から、ソフト開発がうまくいかないことによる損失が見過ごせないほど大きいことをデータで示しつつ、旧来のウォーターフォール的なやり方からアジャイル的なやり方へ転換すれば改善できると説いた本。
アプローチとしては、いわゆる「アジャイル宣言」にほぼ沿っている。つまり、エクストリームプログラミング・スクラム・アジャイル・ペアプログラミング・CI,CD・Devops・テスト駆動・リファクタリング、といった内容になる。なぜこれらが良いのかについての根拠が若干弱い気がするが、いずれにせよ、旧来からの開発のやり方から脱却するためのプラクティスとして説いている。
ただ、これらプラクティスのエッセンスという意味では、この本を読むよりも、それぞれの内容そのものにフォーカスした別の本を読んだほうがいいんじゃないかと私は思ってしまった。この本ならではの点が何かを考えてみるに、開発方法の転換を図りたくてもなかなかできないような現場にて上を説得するための材料や根拠をコンサル視点っぽく提供してくれること、なのかな。
とはいえ、最後の章が典型的だけど、やろうと思ってもなかなかできないのが現実で、ひたむきに真摯に取り組み続けることの難しさみたいな精神的な面を語っていたりもする。本著のタイトル「レガシーからの脱却」はそういうところなのかとも思う。
というわけで、アプローチのエッセンスについてはそれぞれの個別の本を参照したほうが良いと思う。アジャイル的な話の中身をわかっちゃいるけど実践できないような停滞感のある現場を知っている人がそれでもやっぱり転換したいと思ったときに手に取るのがよいではないかと思う。
ページ28 2.3.2蔓延「バグ修正に多くの時間を費やす人は少ない」え?逆じゃないの?バグ解析や修正に時間がかかることが多いんじゃないの?ものすごく違和感を感じる記載だった。
ページ63 5章プラクティス1「開発の半分もの時間が要求収集に費やされていた」 ソフトウェア開発者がソフトウェア開発をやっていないというのはもはやこの業界のあるある。仕様を取りまとめたりチェックシートを整備したり進捗確認したりバグチケットの取締をしたり、そういう中間管理の仕事をする人が*割を占める。*には好きな数字を入れてくださいな。
]]>● 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)誤字脱字を訂正
インターネットの情報を検閲・統制するGAFAは、アメリカ政府からの資金が減ったのを機に、半導体を牛耳るTSMC有する台湾とそれを実質支配している中国の言いなりになってしまっている、経済的にも思想的にも市場を支配するGAFAが独占している現状の危険性を暴く、という内容の本になっている。
まじかよGAFAやべーな今すぐ規制してトランプ政権を樹立して中国を排除だ、という思想に染まっている取り巻きでYouTubeチャネルが潤う程度に、「自称保守」の非常にヤバい集団が政治家も巻き込んでネット上でさも正論を吐いているように活動している、という事実を知ることができた点が一番の収穫である。
メタバースこそがGAFA独占を打破するための技術なのだ、ということを言いたかったのだと思う(第5章)が、ビジネス書という前置きをしても、何を主張したいのか全く理解できなかった。Web3でアレ呼ばわりされて回収された本のほうがまともだと断言できてしまう程度には悲しい章になっている。もはやメタバース以前に、ヘタに技術用語を概要レベルで理解させつつ話を無理にでもつなげて誘導し「GAFAは悪」という結論ありきに導いて陰謀論をとなえる本書のほうが先の本よりもはるかに罪が深いと思う。
著者は、短大卒業直後に中国でのビジネスに関わっていい加減さを肌で知ったところが中国嫌いの原点となっているようで、2020年アメリカ大統領選挙でドタバタに巻き込まれ(突っ込み?)アカウント停止を食らったのを契機に、GAFAを中国と同一視して敵認定し、日本の過激な保守思想と絡まり、現在の主張に行き着いたようだ。著者の経歴をちゃんと見てもらえばわかるが、ITビジネスアナリストを自称しているものの、主張する内容は技術的な方面も含めて非常に怪しい。
100ページ「そもそもファクトは一つではない」といいつつ、GAFAの主張するファクトは真実ではない自らの主張が真実なのだ、と自信満々に書いてしまうあたり、ファクトチェックの難しさを全くわかってないのだと思う。突き詰めれば精神論・宗教論に行き着くわけだけど、それを経験してもなお客観的事実に基づく科学教を信仰し続ける人たちの苦悩を考えたことはあるんだろうか。
132ページ「彼らにプログラムなんて書けない」、ビルゲイツをプログラム書けない呼ばわりするのは個人的には見過ごせない。そりゃキャリア中盤以降は自身で書くことなんてなかっただろうけど、ビルゲイツをまがい物呼ばわりするアンタはいったい何者なんだと本気で怒りたくなる。
というわけで、ビジネス書の顔をした陰謀論、しかもかなりトンテモより、そんなものがAmazonでレビュー高評価のベストセラーとして購入できるし、著者もYouTubeチャネルで懐が潤うというあたりに、GAFAの真の意味での怖さを知るわけです、はい。例の回収されたWeb3本のお供として購入したこっちのほうが遥かに闇が深かった...
]]>● 需要と供給の話
・SEO対策したサイトで収益を得たい管理者(A)
・何でもいいから記事を書いて原稿料を得たい記者(B)
・話題のキーワードでググって世間話のネタを得たいユーザ(C)
の三者で成り立っているのでなくならない。
● 供給側の話
私も含め、(A)と(B)が同一人物であると思っている人も多そうだけど、別なことが多いらしい。(A)は、アクセス数さえ増えればいいので、SEO対策のためにも「それっぽい」文章を(B)に求めて発注する。(B)は、話題のキーワードでかつ「それっぽい」文章のために文字数を稼ぐ必要があり、あのような回りくどい中身のない文章が作られる。ゴミサイトを排除するAIを欺くためにも、「それっぽい」文章はそれなりに論理的である必要があるらしく、論理的な文章を量産できる人はそれなりに限られるため、(B)のような記者が必要となる、らしい。
● 需要側の話
一般ユーザは、真実や正確な情報はどうでもよくて、世間話や暇つぶしになればよいので、あのような文章で満足する。世間一般的に、論理的な文章をきちんと読める人は少ないらしく、ましてやその利用目的もあってどうせ斜め読みするので、最低限の品質の文章で事足りる、らしい。
● 高みを目指したい人の都合
真実や正確な情報を効率よく拾いたい人にとって冗長な文章というのは耐え難い。時間こそが貴重なリソースなのに、長い文章を読むのに時間を取られた挙げ句「わかりませんでした」ではブチ切れる。こうして多くの人が目にしているであろうキーワードはググるに値しないものと認識される。結局は、前提知識や分野を絞った検索が必要になるので、そういった用途を求めてSNSやコミュニティへと流れていかざるを得ない。
● 「増殖Webがうざい」話
以前「増殖Webがうざい」という記事を書いた。昔は適当に文章をコピーしてきた程度でWeb検索エンジンを騙せたが、今はそうもいかないので、先の(B)のような記事を書く人が必要となった。ただ、Web検索エンジンを騙せればよいので、機械翻訳を介して自動生成したサイトというのも放置できないほどに増えてきた。記者に記事を書いてもらうやり方ではスケールしないので、この手の自動生成のアプローチは、手法が少しずつ変化していくだろうけど、根本的にはなくならないのだろう。
● その他
文字読めない人のための動画(YouTube)の繁栄、言語(英語)の壁、本当のことなんて信じない・信じたいと思うもののみを信じる、みたいなリテラシーにも繋がる話だけど、そこまで絡めると範囲が広すぎるので、またにしたい。
いろいろと話題になっている本だけど、目に止まってすぐに注文した結果、販売中止になる前に手に入れることができてよかった。何がまずいのかを自分なりに確認したかったので。
根本的な事実誤認については、すでに他の人も書いているのでもういいかとも思っていたけど、一箇所だけどうにも気になったので、先に書く。P173「分散データベースで使用される通信方式は、「クライアント・サーバ側」と呼ばれています」、分散データベースを通信方式でのみ述べるのは視野が狭すぎるし、そもそもピアツーピアな方式のものも多いしで、ブロックチェーンを持ち上げるためであれば何書いても許されるみたいな文章になってしまっている。
本書がなぜ批判されるかについて考えるに、SaaSのような形でしかコンピュータ技術に触れてこなかった人が、ブロックチェーンを持ち上げるためにWeb3というマーケット用語を用いてしまい、その肉付けをするためにブラウザだHTTPだTCP/IPだOSだを適当に持ち出してきて語ってしまっている点にあるかと思う。今となってはおおむねその定義や価値が定まっている用語を、まだふわふわしている分野の用語と同列に扱ってしまっては、そりゃ怒りたくもなるわなと。それこそ人生かけて分野を切り開いてきた人もそこらに普通にいるわけだし。
著者は1994年生まれの28歳と思われるが、ということは、物心ついた頃からインターネット...というかWebがふつうにあり、ブロードバンドが当たり前の中で成長し、スマホネイティブな大学時代にブロックチェーンに感銘を受けた、という道を歩んできたかと思う。つまり、ネットスケープがブラウザを作りWorld Wide Webをインターネットのキラーアプリケーションに作り上げたことは、日本の敗戦や高度経済成長やオイルショックやバブルと同様、すべて教科書の中の歴史でしかないのだろう。どの程度の昔から存在するものなのかに興味がなく、またおそらくSaaSのような形でしか技術に触れてないからCPUやOSやTCP/IPプロトコルスタックやについても興味がないのだろう。
あくまでビジネス本としてだけど、Chapter 3以降については類似の他の本に比べればそれなりにちゃんと書けているかと思う。現状のブロックチェーンを取り巻く動きを俯瞰するという目的ではそれほど悪くはないと思う。ただし、ブロックチェーンではない既存の技術についての説明で致命的にダメな箇所が複数あるため、技術者目線ではどうしても引っかかってしまう。
ことWeb3に関してはもはやただのバズワードだけど、この界隈を私なりに書くと、オープン・分散・匿名を信仰するブロックチェーン教であり、ブロックチェーンに裏付けされた暗号資産を使ってエコシステムを作ろうという信者の集まりである、という感じになる。イーサリアムを作ったヴィタリック・ブテリンはいわば教祖か?いやこの場合は予言者か?今のところは没落してはいないが、「円天」ですら5年以上も持ってしまうのが投資の世界なので、信用の裏付けが弱いものが転げ落ちるとあっという間だよなぁ、と心配してしまうわけです。
結局今回は、株式会社インプレスは販売中止&回収するに至ったわけだけど、世の中トンデモ本なんていくらでもあるわけで、この本がそこまでしないといけないものかと言われるとちょっと違うと思う。もちろん批判はあってしかるべきだし、事実誤認は誤字脱字と同様に訂正の形で公表してほしいけど、たかがビジネス書で述べた個人の持論を回収しないといけないとなると、ますます本がなくなっていってしまう。TwitterやFacebookやAmazonレビューやブログに書く個人の感想なんて、紙の本に比べりゃ全く後世に残らないよ。
技術屋と投資屋が仲良くする必要はないと思うけど、だからこそヘタに接点を作らないほうがお互いのためではないかと思うわけであります、はい。
]]>Linux上でのPCM音の入出力の標準となっているALSAについての入門書。音をデジタルデータとして扱うための導入、ALSAの役割とその基本的なAPIについて、ALSAを使ったサンプルプログラミングの解説、という構成になっている。
プログラミングというタイトルになってはいるものの、音をハードウェアから出力する部分を扱うため、比較的低レイヤーなプログラムの話になるし、同時に音をどのような形でデジタル表現しているかについての知識を要する内容になっている。たしかに入門書的な説明の本とはいえ、このへんの分野のことを学ぶんだという心構えは最低限必要かと思う。
プログラミングという触れ込みの本ではあるが、サンプルコードを見る限り、著者はどうもコーディングに慣れていないように見受ける。分野が分野なだけに、信号処理やリアルタイム処理やDSPといったハードよりの分野から流れてきたのかなと推測される。サンプルプログラムは、処理のフローを理解するのにはよいが、細かなコーディングの手癖はマネしない方がよい。
ハイレゾやらUSB Audio Device Classやらの話が登場するが、ハイレゾは本書ではほとんど関係ないし(ビットレート計算くらい)、また現代ではalsaがUSB限定というわけでもないので、このへんは差し引いて読んだほうがよい。
入門書にケチを付けても仕方ないのだけど、実践的な内容にまでは触れられていない。いつでもどこからでもデータを拾い放題な音声ファイルをALSAのクロック任せで出力すれば良いケースは一番シンプルな例で、現実は、音声ってストリームなリアルタイムのデータなので、アンダーラン・オーバーランやレイテンシやASRC(asynchronous sample rate convert)なんかを気にしないといけないのだけど、さすがにそういう内容を求めるのは酷か?とはいえ、P79のNoteにあるniceで優先度をあげようの部分なんか、ごまかすにしてももう少し書きようがあるだろうにと思ってしまう。ここはSCHED_FIFOのキーワードくらいは記載すべき。
と酷評気味に書いてしまったが、ALSAをていねいに解説したものなんて、書籍でもネット上の記事でも皆無に近いので、そういう意味では非常に貴重な本となっている。逆に、ALSAなんて公式ドキュメント読めばいいだろ(当然英語)、というくらいの心構えがある人はやっぱりあえて読まなくても良いとなってしまうか。
]]>● Qiitaで思ったより伸びた
正直これほど反応が来るとは思っていなかった。確かに「シグナルハンドラなんて使うな」という一点を強調した記事にはしたが、反響を得たかったわけではなくて、初心者が生半可な知識でシグナルハンドラを書いてやらかす例をイヤというほど見てきたので、それを改善したいという思いで書いた。その結果、もう超えることはないだろうと思ってたフラッシュメモリ記事を1週間で上回ったんだから、世の中、ソフトの、ユーザランドの、アプリよりのほうが人口多いんだなぁと改めて思い知った。
● 経験でしか学べない
「賢者は歴史に学び愚者は経験に学ぶ」、歴史を引き継がなければ学べないので経験に頼るしかなくなる。self pipe trickもシグナルスレッド方式も、シグナルハンドラ実装のための定石だと説明した書籍なりネット記事なりがほとんど存在しない。そりゃこんな状況じゃ、痛い目見ないと注意しようとも思わないよね。痛い目見てる人そこそこいるようなのに、なんで歴史として学べるようにできないんだろうか。もはや日本語圏じゃそんなことできる人やお金はない、英語を必須にしていかなければいけないという言語の壁の問題?
● 他のシリーズ
fork()とexec()の間で余計なことするな、pthread_cancel()なんて茨の道だからやめとけ、プロセスのfork(),exec()とSIGCHLDを正しく使う、ポーリング/ビジーループするなselect(),epoll()を正しく使え、みたいな定石をちゃんと整備できないだろうか。システムプログラミング系の書籍では、機能を教えるけど、筋がいい・悪いまでは語ってくれない事が多い。「malloc()したらfree()しよう」「openしたらcloseしよう」みたいなレベルまでしか教育が及ばないのだろうか。
● その他
気が向いたら追記するかもしれない。とはいえ、Qiita記事のPVが増えたとはいえ、さすがにこの記事までたどり着いて読もうという人はほぼいないか。
レイジレーサー - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%AC%E3%82%A4%E3%82%B8%E3%83%AC%E3%83%BC%E3%82%B5%E3%83%BC
PS1世代のゲームなので当時は「CD-ROMによりゲームのロード時間が長く」なんて言われたが、今どきのゲームに比べれば圧倒的にロードが早い。というより、今どきのゲームはロード時間が長すぎテンポが悪すぎで手軽に遊べない。
]]>完結したはずの前作(みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」)のまさかの続編。前途多難で非常に苦労し全面刷新して構築したシステム「MINORI」が稼働したものの、その後も断続的にシステム障害を起こしているみずほ銀行のシステム障害の詳細を掘り下げようという趣旨の本。
立て続けに障害が起こったものの、それらをわかっている範囲で個別に原因を項目化するだけでなく、なぜそのような事象に至ってしまったのかについてもできるだけ掘り下げようとしている。他の例と比較しながら、銀行システムならではの事情や、海外での似たような障害の例も紹介しつつ、1つ1つは他のシステムでも起こっている問題でありつつ、みずほの場合はそれが波及的に連鎖して大規模システム障害に至ってしまっている点を指摘している。
これまでの本は、経営者層がシステム開発と運用を軽視しているという論調が多かったけど、今回の本はその色は弱めた内容だった。とはいえ、テストや運用にさく工数をケチってるんじゃないかの指摘はしており、特に小さなシステム障害が起こった場合の対処マニュアルや実施訓練がほかと比べて不十分というのを具体例を出して述べている。
なんというか、批判するのは簡単なんだけど、じゃどうすればよいのかを大規模開発を対象に語る難しさというのを感じる。規模の差はあれ、私自身も似たように多人数の関わる大規模プロジェクトが迷走する実例をよく見るだけに、この本から何を教訓にすべきかを意識して読まざるを得なかった。プロジェクトなんて成功するか失敗するかは水ものだから、どれだけ小さく早く開発を回せるようにするかがキーなのかなぁ。もしくは、ある程度見識を持った少人数の集団で集中的に開発しコア部分を作り上げてしまうべきなのかなぁ。OSS類をモジュールとしてたくさん利用するのが当たり前な昨今、いくらモジュール志向をもって開発したとしても特定プロジェクトでしか使われないのならば汎用性が低いものしかできあがらない、それを洗練させるには複数のプロジェクトの採用例を増やしてアダプトさせるしかないのかなぁ。などなど。
以下はこれまでと同様に読んでて気になった項目をずらずらと。
第3章p133「二重エラーが発生している旨を伝えた」「二重エラーの報告は受けていない」、障害発生時の情報共有を口頭でのみ行っているという決定的な例かな。エラーメッセージなんて1字1句間違わないようにコピペしてテキストで共有するのが当たり前ですね。
第3章p167「オールフラッシュのストレージ装置に移行していれば、ハードディスクの故障という前時代的なトラブルに遭遇しなかった可能性」、いやそれはさすがに主張がおかしいだろと。SSDも壊れる。HDDより壊れにくいなんてことはない。ただ、頻繁な読み書きをするストレージ部位をSSDにすれば圧倒的な性能でシステムのボトルネックを取り除けるのは確か。
第4章p178「自らの持ち場でやれることはやっていたといえる」、部分最適の極みは実は相当難しい。というのも、システムの開発や運用をやっている末端は、子会社や孫会社どころかそこの孫請けやひ孫請けで、彼らは仕事を受けた単位が自分の持ち場だけなので持ち場を離れて横断的に作業をする義理もないしお金ももらっていない、むしろ契約書に書かれた担当をおろそかにしたと責められる。かといって全体責任を持つ上位の人は指示を出す仕事だけでいっぱいいっぱいになりとても現場の実情をチェックすることもできない。組織の壁でさえよく批判を受ける話なのにそれが会社や契約をまたぐととてもじゃないけどそうはいかない。権限を持った人も現場に入っているような体制でないとこれはそう簡単には解決しない。
第5章p183、みずほのシステム開発の歴史表は参考になる、
第5章p185、銀行各社の統合とそれに連動したシステム統合も参考になる、
どちらも、20-30年といった人のキャリアすべてを費やすような単位で進行するので、人生をかけてシステム開発に携わる覚悟のある人を何人も囲い込まないと成功させるのは難しいよなぁと思う。
第6章p262「(セブン銀行は)東阪交互運用方式を導入する」、予備システムをホットスタンバイさせるのをさらに進めて、何もなくてもメインサブを定期的に入れ替えてシステム運用するの、ウワサには聞いたことあるけど本当にやってるのかなぁこれ。
]]>● プロセス置換
bashプロセス置換(process substitution)とは、ファイル名を渡されたかのように振る舞いつつ、実際には別のプログラムのSTDOUTを与えることができる。
内部実装としては、pipeへのreadとwriteになり、ファイル名の代わりにfile descriptorのpath(/dev/fd/[N]など)が渡される。
よく使うコマンドは、ファイル名の代わりにSTDINにPIPEを渡せることが多いが、その機能を持ってないような場合に使える。
...とはいえ私があまり使いこなせていないので良い例が思い浮かばない...
● isatty()をごまかす
STDIN/STDOUTがTTYなのかどうかを識別する関数としてisatty(3)がある。isatty(3)をうまく使うことで便利にしているコマンドが多いが、逆に、パイプやリダイレクトにしたときに挙動が変わり困ることがある。そういう場合、例えば、
$ cat - | prog
とすれば、isatty()はTTYじゃないといいつつ、キーボードからインタラクティブに入力することができる。
...あれ、これの逆は?
TTYのfd番号を調べて、/dev/fd/[N]にwriteすれば、isatty()はTTYだといいつつ、プログラムからSTDINに流し込める?
● c++でヘッダから実装stubを自動生成する
stubgenというのがあるが、C++03やC++11などには未対応の模様
https://github.com/mjradwin/stubgen
Lazy C++というのがあるが、略記法な疑似C++からヘッダと実装を生成するツールの模様。
code generation - Automatically generate C++ file from header? - Stack Overflow
https://stackoverflow.com/questions/1404614/automatically-generate-c-file-from-header
上記によればimpl_meというのがあるらしいが、swigを使う部分でうまく動かせなかった。
swig(1)は、C/C++と他の言語とで呼び出しをbridgeするwrapperを自動生成するツールらしい?
● 国旗の絵文字
国旗の絵文字は、Unicdeのコードポイントが用意されているわけではない。
ISO 3166-1に従いRegional Indicatorを2つ組み合わせてCombining Characterとして表現する。
このため、表示できるかどうかは環境に依存し、フォントだけでなくレンダリングシステムにも依存すると思われる。
2022年現在、Windows10は表示できないが、それ以外はだいたい表示できる模様。
なお2022年現在、Web版のTwitterやFacebookでは、Unicodeとして表示するのではなく、SVG画像に変換して表示している模様。(アプリ版は不明)