WSLからWindows側のファイルを操作すると遅い。AWS CLIを使った操作でどのくらい差が出るのか実験してみた。 実験内容 シナリオ Windows側にあるフォルダをS3に同期する 実体はNTFSフォーマットされた単一のSATA SSD上にある 同期対象ファイル数は2.3万個、合計ファイルサイズは16GiB ローカルとS3の差分を検出し不足と過剰をレポートさせる 同一条件で何度も比較するため、実際にはアップロードしないドライランモードを使う 一度ドライランが終わったら間を置かず再実行し、結果が変わるかを見る 環境 WSL側 aws-cli/2.15.24 Python/3.11.6 Ubuntu 20.04.6 LTS / WSL 2.2.4.0 Ubuntu 上の bash から /mnt/d/syncdir に対して aws s3 sync する Windows側 aws-cli/2.15.33 Python/3.11.8 Windows 11 Home 24H2 cmd.exe から D:\syncdir に対して aws s3 sync する 初回実行の結果 WSL：5分22秒 Windows：3分04秒 WSLで実行すると単純に所要時間が75%ほど増えることがわかった。わかりやすく遅い。 当然ながらあらゆるワークロードでこの差が出るわけでもない。 予想される傾向としては： 両環境の差は同期対象のファイル数に線形に依存する たとえば少数の巨大ファイルを同期するような用途であれば差はわずかになる 物理のストレージが高速であるほど差が開く 今回であればSATAではなくNVMe SSDで実験すればより差が顕著だったと思われる （WSLはファイル操作1件ごとに固定値のオーバーヘッドが載るという前提に立っている） 2回目の実行結果 面白いことになった。 WSL：5分12秒 Windows：13秒（！） Windows側の高速化のされっぷりがおかしいことになっている。なんと10倍以上。 明らかに真面目に数えておらず、何らかのキャッシュがあるのだと思われるが、WSL側はほとんど高速化できていないことからキャッシュの有無だけが理由ではなさそうだ。 もしかしたらNTFSのディレクトリメタデータみたいなのを読んでラクできる仕組みがあるのかもしれない。 まとめ：WS...

閉じた傘を留めるための紐がダメになった。気に入っていた傘であり、紐だけの問題で捨てるのはどうにも悔しい。 なんとか直せないかと調べたところ、実は案外簡単に修理できそうなのでやってみることにした。 「傘を留める紐」の正式名称わからん問題 名前がわからない。これが修理方法の調べづらさにつながっている。 最初 "傘 紐" とかで調べてたんだけど、これだと折畳み傘の持ち手についてる輪っかを指す場合が多いみたい。 一応傘ベルトと呼ばれているのは観測できた。けどあんまり検索ヒットしないので正式名称かどうかは不明。 で、名前はともかく、ここがダメになるパターンはいくつかある。体験した限りでは マジックテープが劣化してくっつかなくなる 紐が根本から千切れる というのがあって、どちらも濡れた傘が常に開きっぱなしになるのでQoLが下がる。今回はマジックテープ劣化パターンの修理です。 で、とりあえず修理後の完成物がこれです 修理したあとの傘。ちゃんと閉じれてるし、何ならわりと普通に見えるじゃろ？ だけど開くとこうなっており 図解するとこうで 実は接着面の劣化でくっつかなくなったマジックテープの上から、無理やりスナップボタンをつけて直しているのであった。 修理方法 1️⃣準備 まず資材を用意する。 スナップボタン 他の傘についてたボタンのサイズを測ったら直径10mmだったので、同じサイズのを選んだ。 濡れたり力が掛かったり振り回されたりする箇所なので、縫い付け式ではなくカシメて固定するタイプがよい。 取り付け用工具も同梱されてるやつだと安心。 https://www.amazon.co.jp/dp/B017K3ZOG4 スナップパッキン（ワッシャー） ボタンと同サイズのもの。とはいえ不要かもしれない。後述する。 https://www.amazon.co.jp/dp/B01GG0HNY8 商品自体は↑だが、販売形態でボタンとセットのやつがあったのでそれにした。送料がかからない。 皮ポンチ 買ったボタンに合わせて径を選ぶ。今回のだと2mmの穴が要求されているのでそのあたりのサイズ。自分は家に3mmのやつがあったのでそれを使った。 入手先は百均がおすすめ。Amazonとかだと500円くらいして微妙に高い。 錐あたりで雑に穴あけしても良さそう？ ゴム板 皮ポンチで穴を抜くとき...

我が家では「OK Google、電気つけて」でリビングの電気がONになるよう設定している。しかし3日前くらいから動きがおかしくなった。リビングだけでなく家中全部の電気がONにされてしまう。 「はい。」じゃないんだよ。12個のデバイスを一挙にONするとかどんな家だ。サタデーナイトフィーバーやってんのか。 画面だけの問題ではなく実際の家電操作もおかしくなる。リビングの電気をつけようとしただけなのに、なぜか書斎も寝室も家中すべてがONになるという動きをする。 結論、どういった問題なのか？ 問題の根幹はこうである： 「電気つけて」を「アカウントに登録されているあらゆる照明をすべてをONにせよ」と解釈する仕様変更が、Google側でサイレントに実施された。 これは控えめに言っても頭のおかしい挙動だ。 判定基準がデバイス名だけというガバガバさが一番の問題である。単純に当たり判定が広すぎる。これのせいで自宅と職場の電気が一度に点くような人も出てくることだろう。 いろいろ実験してわかった挙動 「電気つけて」の当たり判定がめちゃめちゃ広くなった 名前に〝照明を意味する単語〟が含まれるデバイスは全て当たり判定にかかる 最初のスクショでも「◯◯の電気」と「ダウンライト」がまとめてONにされていることがわかる 試した限りでも「電気」「ライト」「照明」「光」「明かり」はすべて効果範囲だった。まだあるかもしれない 「電気」がダメなら「明かり」を使おう！ が塞がれている感じ 「光」や「明かり」まで対象にされてるのには偏執的なものを感じるけど、実際はたぶんなんも考えずに "light" を訳しただけとかでしょ デバイス名の判定は部分一致でされる 「リビングの 電気 」「寝室の 電気 」という2つのデバイスがあるとき、「 電気 つけて」で2つまとめてONにされる 何のためにデバイス分けてると思ってるの？？？ 寝室に寝ている家族がいるかも？ とか考えないらしい エイリアス名だけに「電気」を含む場合もばっちり対象である 判定をすり抜けるワードもあるにはあるが、実用性がきびしい 「でんき」「らいと」……これらは効果範囲外だが、音声入力できないので使えない 「ピカピカ」……すごく愉快なおうちになってしまう。ごはんのピカピカつけて！ Home Assistant内部のエントリ名は ***_...

乗り物がたいへん好きなので、定期的に一人旅をやりたくなる。 前回の一人旅では土合駅を見てきた が、あれから2年も経ちそろそろ乗り物欲が我慢できなくなってきた折、衝動と勢いに任せてアァアアーーーッと名古屋に行ってきた。 旅の第一目的はリニモというリニアモーターカーに乗ること。時期は2月のことである。 まずN700Sを捕まえる N700Sはそのへんに大量に生息しているので、狙わなくてもすぐ捕まえられる。山手線の電車より捕獲が楽かもしれない。 子連れの家族旅行などと違って、一人旅ならば自由席で十分である。予約とかないのでホームに着いたときちょうど居合わせたのに乗るだけ。 いまさらだけど新幹線って超たのしいよね。東海道はとても景色よいし。 富士山に、 浜名湖に、 ニチバンの工場に、とたいへん風光明媚なお土地柄。 そして名古屋到着。日本一有名な通過都市にあえて停まる。実績解除。 リニモの駅まで地下鉄にのる これは地下通路にあった原子炉格納容器みたいな路線図。かっこいい。 あとめっちゃ古い案内看板を見つけてテンション上がった。100系新幹線のアイコンもすごいけど、サインのフォントがゴナなのがガチですね。 市営地下鉄の車両はだいぶ古い感じのやつで逆に新鮮。 線路側の標識も見慣れぬやつがいくつもあり、とくにこの勾配標のイラストが良かった。過去と未来が同居している。 ガラガラのリニモは静かに滑る リニモの駅につく。なんか知らんがめっちゃ鳩がいた。乗客の数より多かったかもしれない。浮いてる同士で気が合うのかな。 改札階に降りると空間がジブリパークの宣伝に侵食されていた。地上駅舎にはジブリの痕跡を匂わせるものがないので、ここだけが際立って異空間めいている。 さて、リニアモーターカーといえばやたらと速い乗り物のイメージがあるが、このリニモは最高でも100km/hと速さの方はそこそこに留まっている。 そのかわりに際立つのが走行音の静かさだ。地上との接触が一切ない、6mmくらい浮上した状態で走るので電車っぽい音がしない。これが速さとは全く別軸の新体験だった。ぜひ動画でごかくにんください。 加減速時こそヒュイーンと磁歪音みたいなのが出るが、高速時は風切音ばかりが聞こえ、低速での惰走中などは空調の音しか聞こえない。まさに滑るように走る、というか、リニモの場合は浮いているので本当に滑っている。 ...