Windows11 HomeのWindowsUpdate(具体的には2024年11月にリリースされたKB5048667)を適用すると、Windowsの再起動待ち状態になるけれど、再起動が完了して「設定」からWindowsUpdateの状況を確認すると、相変わらずの再起動待ち。。。もちろん、素直に再起動してもやっぱり再起動待ちの状態が解消することがない。
続きを読む
Windows11のアップデートで24H2にアップデートされた端末がNASに接続できなくなった。ブラウザからは接続できたので、ネットワーク的には疎通しているけれど、SMBで参照しようとするとうまくいかない。
続きを読む
全銀ネットでの障害が発生して、まぁまぁ時間が経っているけれど、未だに復旧していない。1973年に稼働開始したシステムはとにかく可用性が売りだっただろうし、多くの金融機関もその実績を信用していたのではないか。
Internet Watchにドコモがネットワーク品質向上に取り組む旨の記事が掲載されていた。
以前の記者会見だと、都内の渋谷や新宿あたりのかなり混雑してるエリアの品質向上に取り組むって内容だったような気がするが、それが2000地点に増えたらしい。
続きを読む
さくらインターネットのさくらのクラウドで動いているインスタンスについて、さくらインターネットからメンテナンスを実施する旨の連絡が届いた。とある日までに、当該インスタンスを停止→起動(再起動ではなく)すれば、さくらインターネットが実施する強制的な停止→起動を回避できるとのこと。まぁ、どうせやらなきゃいけないのであれば、ある日、突然、停止→起動されるよりは、調整した上でタイミングを見計らって実施したいところ、ってことで停止→起動を実施してみたら、インスタンスのCPUが変わっていた。
続きを読む
WF-1000XM4をSONYに修理に出してみた
SONYの完全ワイヤレスイヤホンのWF-1000XM4を使っていたのだが、購入してから1年くらい経ったあたりから不自然に右イヤホンのバッテリーのバッテリーの減り方が激しくなったような気がした。言い換えると、バッテリー残量が著しく減ってるような、そんな印象だった。
続きを読む
うるう秒は避けられないとしても、それをいかにしておおごとにしないかはなかなか重要なことな気がする。まぁ、そういう観点ではleap smearすることによってなんとかするのも1つではあるけれど、やっかいなことにleap smearしないNTPサーバとleap smearするサーバを混ぜて参照するのは止めた方がよさそうだ(まぁ、普通に混乱するだろうな)
…だがしかし、publicなNTPサーバのうち、leap smearしてるかどうかを明記してるNTPサーバってそんなに数多くない気がする。まぁ、書いてなきゃleap smearしてないんだなくらいの理解でもいいんだろうけれど。
続きを読む
中古で買ってきたThinkCentre M720q TinyにRocky Linux8.6をインストールした。搭載しているCPUはCore i5-8500Tなので、第8世代のCore i5であり、開発時のコードネームはCoffee Lake。
インストール自体はすんなり終わったけど、よく見てると、まぁ、時計がズレまくっている。timedatectlコマンドの結果を確認してみると、NTPで調整してみても、結果的にRTC time(リアルタイムクロック)の時刻がすさまじい勢いで進んでしまうので、chronydが同期をあきらめてしまうようなレベルでズレていた。
続きを読む
Amazon Linux2022のことが発表されて、しばらくプレビュー版のまま。なかなかGAにならないなぁと思ってはいたけれど、もう7月。2022年の半分が終わってしまったことになる。いっそ、Amazon Linux2023くらいにしておいた方がよかったんじゃないかなぁーと無邪気に思ってたら、Amazon Linux2のEOLが延期されてた。延長されたEOLは2024年6月30日。
そっと、Amazon Linux2のFAQページが更新されてるのが興味深い。
AmazonLinux2のEOLが2024年6月30日に1年間延長
PHP8.0を動かすインスタンスを構築しようと思っていて、Amazon Linux2022を待っていたけれど、結局、PHP8.0のEOLが2023年11月26日なのでPHP8.0のEOLの方がAmazon Linux2よりも早くEOLを迎えることになるので、まぁ、なかなかGAにならないAmazon Linux2022を待つよりもAmazon Linux2で構築しちゃおうか。
さくらのクラウドで、サーバーをクローンするためにディスクをクローンしようとしているけど、「待機中」のステータスになって、いっこうにディスクのコピーが進捗するする気配がない。ディスクのコピーは常にインスタンスからアクセスされているストレージ(SANだったっけ)のリソース(帯域幅やCPU)をがっつり使うことになるので、コピーの優先度を上げるわけにはいかないだろう。例えば、複数のユーザーからのディスクコピーのリクエストがパラレルに走らないような制御がなされているんだろうけど…。
例えば、ヤバい！って事態に陥って、急遽、サーバをクローンしようとしてこの状況に直面すると切ないだろうな…と思いながら、まったく進まないプログレスバーを眺めてみたりして。
しかし、AWSだとこういう待ち時間がなかったような気がするんだけどなぁ。インスタンスを起動するときにはAMIの裏側のS3からEBSにがっつりデータをコピーしているはずだし、サーバのクローンをする時にもEBSとS3の間でゴリゴリとデータをコピーしているはずだけど、特にちょっと待ってってステータスになっているのは見たことがない気がする。まぁ、さくらのクラウドがショボいというか、むしろ、AWSのEBS周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。