Windows11のアップデートで24H2にアップデートされた端末がNASに接続できなくなった。ブラウザからは接続できたので、ネットワーク的には疎通しているけれど、SMBで参照しようとするとうまくいかない。
続きを読む
全銀ネットでの障害が発生して、まぁまぁ時間が経っているけれど、未だに復旧していない。1973年に稼働開始したシステムはとにかく可用性が売りだっただろうし、多くの金融機関もその実績を信用していたのではないか。
Internet Watchにドコモがネットワーク品質向上に取り組む旨の記事が掲載されていた。
以前の記者会見だと、都内の渋谷や新宿あたりのかなり混雑してるエリアの品質向上に取り組むって内容だったような気がするが、それが2000地点に増えたらしい。
続きを読む
さくらインターネットのさくらのクラウドで動いているインスタンスについて、さくらインターネットからメンテナンスを実施する旨の連絡が届いた。とある日までに、当該インスタンスを停止→起動(再起動ではなく)すれば、さくらインターネットが実施する強制的な停止→起動を回避できるとのこと。まぁ、どうせやらなきゃいけないのであれば、ある日、突然、停止→起動されるよりは、調整した上でタイミングを見計らって実施したいところ、ってことで停止→起動を実施してみたら、インスタンスのCPUが変わっていた。
続きを読む
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ページが更新されてるのが興味深い。
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周りのネットワークの帯域幅はどれだけ太いんだって話かもしれないけど。
以前に契約して中途半端にしか使っていなかったUQ mobileのデータ高速プランを解約することにした。
まぁ、データ高速プランはUQ mobileがMVNOっぽいSIMの売り方をしていた時の料金プランで、UQ mobileがKDDIにおけるY!モバイルっぽい立ち位置に移行してからは新規申込みを止めたプラン。今は音声契約が必須になっているので、まぁ、MNOの契約であるにも関わらず、データ専用で(SMSは付いてるけど)3GBで990円というプランは今となっては珍しいと言えるかもしれない。
いざ解約するべく調べてみたら、UQ mobileの解約はコールセンターへの電話のみという…まぁ、今時、なんだかなぁという印象。例えば、Webサイト屋auショップでも解約を受けてくれればいいのに、解約の窓口が電話しか用意しないことで解約のハードルを上げるっていうのはなかなかイケてない気がするけどな。
そして、UQ mobileのWebサイトには「必ず、契約者ご本人さまが、解約をするスマートフォン/携帯電話本体から、電話番号の前に186を付けるなどの方法で携帯電話番号を通知してお電話ください。」と書かれていたが、データ専用プランなので音声の発信ができない。データ通信専用のデータ高速プランなんて忘れられているんだろうな…。いやはや、音声通話できるドコモのSIMが入ったスマホから電話した。
というわけで、UQ mobileのコールセンターに電話したのは日曜日の13時ちょっと前。自動音声応答システムでメニューを選択する方式だった。そして、解約する電話番号と暗証番号を電話機のダイヤルパッドから入力。その後が長かった。オペレーターさんに電話がつながるまでに保留された時間がざっと30分。途中で、このまま待つか、かけ直すような案内もなされるが、休日なんてずっと混み合ってるんだろうし、コールセンターへの電話しか解約窓口を用意してぐったりするくらい保留されて解約を断念してしまったら、解約のハードルを上げてなんとかしようとするKDDIの思うつぼだし。
30分くらい保留音を聞き続けてオペレーターさんにつながった後は早かった。解約にあたっての注意事項が告げられて、それを確認して終了。MVNOなんかはWebで解約を受けてるわけだし、Webでも実現できるとしか思えないやりとりであった。総務省や公正取引委員会はこういうあたりもチェックすべきだと思うんだけどなぁ…。