私は10年ほど前に買った液晶モニタを今でも使っているのだが、ちょっと長年の不満があって。今さらながら。
実際のところゲームやったりデザインしたりするわけでもなく、コードや文章を書いてWeb見たりするだけの用途。不満は発色とか解像度ではなくて、起動の遅さですね。普段MBPの外部ディスプレイとしてHDMI/USBの切替器経由で使っているんだけど、MBPをスリープから復帰させるために外部キーボードや外部タッチパッド(切替器経由のUSB接続)を叩いてから、画面が出てくるまでが遅い。気がする。ディスプレイもMBPも両方スリープ状態になってるので、MBP側が外部ディスプレイに映像を出すまでの時間が長い可能性もあるが、別の機器の出力が画面に出てくるまでの時間を考えても、ディスプレイ側なんじゃないかと思って。
そして画面が出るのを待っているうちにまたスリープに入ってしまい(この見切りはMBPが早すぎると思う)、あれやこれやしている間にわけわかんなくなってしまう。普通に画面開いて使う場合と比べると、快適度が下がってしまうんだよね。
画像生成が話題ということで、自分の手元のMBPでも動くということで、試してみている。普通のパラメータで動かすとさすがに1回1時間以上かかるけど、1枚きりの生成にすると2分弱で出てくるね。めちゃくちゃな時代になったな。こりゃーGPUも売れるだろうよ。
とりあえず「専用スタジアムになった等々力」みたいな画像。ラインも周辺環境もぐちゃぐちゃですが…屋根ないのも困るなあ。
(WordPressに上げると.jpgに変換されて.pngのtEXtタグは消えちゃうんだな)
愛用のキーボードが微妙に壊れてしまった。あるキーだけが反応しなくなった。2013年12月に買った、ARCHISSの黒軸のやつ。在宅勤務が定常化してからは仕事にも使っているやつで、壊れると非常に困る。というか実際困った。
裏のシールを見ると、製造は2012年12月なのかな。毎日元気に叩かれ続けて、はや9年目。軽快な音を出しながら、自分に合ったタッチ、ほどよい打鍵感覚。
たまにキートップを水洗いしてまして。この春にもやったばかり。戻す時に乾き切ってなかったのかも、という後悔がある。あとボード側の掃除も甘かったかもしれない。気に入っていただけにいろいろ考えてしまう。
ただ、そうは言ってもこのキーが打てないのは耐えられないので、FILCOの似たやつを発注、無事に届いたので、こうやって文章を書ける。まあ同じCherry MX黒軸でも、ちょっとタッチは違うかなー(使っていっていい感じにエイジングされれば同じようなタッチになるのかもしれない)。刻印が控えめで、見た目は割とカッコ良くなった。
打てなくなったのは「9」のキーです。「(」でもあるので、この記事は壊れてたら書けなかったですね。今週は「(」と「9」常にエディタに表示していて、打ちたくなったらそこからコピペしてました。
log4jの割とでかい脆弱性が世間を賑わせていますねー。年に一度のお祭りといった趣。このサイトのアクセスログにすら出てきてます。Wordpress丸出しで、まあだいぶ古いですがnginxとphp-fpmだから(リプレースしたい)、log4jを使ってるとは思えないはずですが、まあインターネット全体が見境なくフルスキャンされまくってるってことなんでしょうね。
このサイトは「ログ取得ツール」という名前にしていますけど、ログの取得と蓄積はソフトウェア技術においてはかなり重要度の高いもので、適切なログを吐くコードになってるかというのはプログラマが優秀かそうでないかを見分ける要素の一つだったりしますね。何かトラブルが起きた時は必ずログを見るわけで。それは昔から、このサイトを作った頃(2008年)にはすでにそうで、もしかしたら先代サイトの2003年ですらそうで、それから今に至るまで、変わりません。このくらい続くと、もはや「真理」と言ってもいいのでは？
MacBook Pro(7年前から使用)、Amazon Fire TV Stick(5年前から使用)、Raspberry Pi(5年前から使用)、Huaweiの電話(4年前から使用)と、かなりガタが来ていた感があった。順次入れ替えて行こうと。
きっかけはFire TV Stick。こいつには律儀にアップデートが来ているんだけど、こないだUIが変わったと思ったらものすごく重くなった。DAZNなんて1分持たずにアプリが落ちて再起動してしまい、全く実用にならない。Fire TV Stickは事実上DAZNマシンなので、これはすごく困る(しょうがないのでJリーグや代表の試合はMBPをリビングのTVにつないで見ていた)。そして新しいモデルが発表されているのを見て、怒りの予約。安いし。その後、到着までの間に電源off/onしたら快適になったから、買い換える必要はなかったなと思ったが、おとなしく到着を待ち、新しいモデルに変更した。なんとかMaxとかいうやつ。キビキビ動くし、割と快適になったので結果オーライか。
ここのところ、自宅のMBPがスリープからの復帰で非常に不快な動きをするようになって悩んでいた。古くなってきてるからそのうちM1のやつに買い換えようとは思ってるんだけど、それまではしょうがない。で、OS再インストールで直るんじゃないかという気持ちがあるが、それをやるダメージは割と大きいので、ひとまず~/Library/Cachesを削除(実際はrename)してリブートして様子を見ることにした。
現象としては、スリープから復帰して例えばChromeのアドレスの欄を触るなりiTerm2のウィンドウに文字を入力するなりMacのメニューを触るなりすると、マウスカーソルが待ち状態になって何もできなくなるというもの。この現象が数分続いたのちにMacが使えるようになる。これなら再起動したほうが早いんだが…正常なシャットダウンすらできないからどうしようもない。電源長押しが最速かも(←それはやったことがない)。こうなる場合とならない場合があって、スリープからの経過時間と関係があるんじゃないかという印象がある。ハイバネート(ディープスリープ？)限定で起きるということなのかもしれない。
一つ前のエントリやら何やらで、sshdのポート番号を変えてたらbrute forceのlogin attemptが劇的に減るとかなんとか書いた。
すると、最近になって変えたポートで待ち受けるsshdへのlogin attemptが激増した。割とタイムリーだったのか。アクセス元のIPアドレスは3000種類くらいで、かなり規則性のあるバラツキがあるが、多いやつは600回くらい試行している。一応まだログインされた形跡はないと思うけど、気持ち良いものではないよなー。
うーん、このサーバって一応fail2banも入れてたはずなんだけどなー、と思って設定を見直してみたら、actionを書いてなかった！ つまりDBに書くだけで実際にはbanしていなかったというオチを経験する一幕があった。デフォルトでfirewallcmd-ipsetにしとかないとダメですよね。
xmlrpc.phpの問題も、fail2banに任せればいいのかな。ちょっと設定してみたけど、効くかどうかは不明。
このサーバは借りたホストで自前で管理しているんだけど、よくいろんな国からログイン試行のアクセスが来る。sshでも来るし、Wordpress(WP)のログイン試行も多い。治安悪いなぁ。
fail2banやWPのBrute Force Login Protection(BFLP)といったソフトウェアは、ログイン試行を記録して不正と見なすほどの頻度で来た場合にそのIPアドレスをブロックするというものだ。割と有効で、ちょくちょく通知メールが来る。BFLPはApacheの.htaccessを作ってくれるけど、私はincronと自作スクリプトを組み合わせてnginxで運用している。
sshならポートを変えたり、WPならLogin rebuilderというプラグインがあって、ログインページのURLを変更することができる。これも効果があって、特にsshによるlogin attemptは劇的に減った。しかしWPのBFLPの通知は相変わらず、頻繁に来続けた。ログインページ変更ってほとんど効果ないじゃん。
アクセスログを見てみたら、不正なログインはxmlrpc.phpに向けたPOSTリクエストだった。wp-login.phpの倍くらいのxmlrpc.phpへのPOSTが来ている。なるほど。このエンドポイントもURL変更しないと効果は半減というわけか。ただこのエンドポイント、自分としては消すことはできなくて、Androidとかから投稿するのに必要なんだよね。
2020年夏。在宅勤務が続いたので、まずは自宅のネットワーク環境を改善しようとした。とりあえず無線LANの調子がよくなかったこともあり、有線に戻した。私物MBPと会社のMBPを有線に。今時のスイッチングハブと、細めで長さがちょうどいいケーブルを調達して、と。
ついでに自宅のRaspberry Piの環境を改善しようと思ったんです。別の部屋に隠してあったRaspberry Piのサーバを自室の棚に引き取って。このサーバにはバスパワーのHDDがついていて、負荷をかけると電源が足りなくなって、落ちる。MBPのバックアップ先でもあり、PDF変換サーバでもあり、githubに上げる前の書きかけソフトウェアのリポジトリサーバでもある。その重要性にも関わらずこの貧弱さはどうだ。見たら1Aまでしか供給できないUSB充電器が使われていた。そりゃ足らんよ。今までその充電器で戦ってたのね。せめてHDDはセルフパワーにしてあげないと。うーむ…
https://github.com/wtnb75/rtow1#performance
話題沸騰(?)のRayTracing In One Weekendやってレイトレを完全に理解しました。性能度外視でいいかとPythonでやりましたが、PyPyを使うと割と実用的な速度で動くということがわかった。環境としては、普通に世間でvCoreとか言って売ってるVPSと、手元のRaspberry Pi。普通のCPythonは十分遅いけど、PyPyを使うことでそこそこ高速に動くことができる。Raspberry Piは2Bと3Bの2つ持ってて、2Bの方は設置場所の問題もあって、負荷をかけ続けると安定動作してくれない。最後のやつはついに完成しませんでした。どうしても途中で落ちてしまう。3Bは余裕だった。
それでこういう計算の場合、PyPyはPythonよりも10倍以上高速だということが判明した。なかなか凄いです。何より、ちゃんと動くという点も偉い。PyPyなかなか侮れませんよ。
しかしCPythonだと流石にきついね。最後のなんて、Xeonなのに45時間もかかりましたよ。PyPyなら1時間半で終わる。まあ、最適化も何もしてないGILありのPythonでシングルスレッドだから、高速とは最初から思っていないけども。まー単純にmultiprocessingで並列化するだけでもかなり効果はあると思うけどね。RasPi3Bだって4コア持ってるから。
ログ取得ツール