Ubuntu User Blog

記事の更新日：2026/09/22　評価の記述、誤字の修正 1.概要 新しいPCは性能向上が著しく、CPU性能だけでなくディスプレイの解像度も高度化しています。以前はVGA,SVGAを利用して、1024x768のディスプレイが利用できるようになると、「すごい」と思ったものです。更に、1920x1080の横長のハイビジョン対応のディスプレイを利用できるようになって、操作性が著しく良くなりました。 linux起動時のkernel paramaterに参考資料に記載があるvgaパラメータを以前は設定していました。いつ頃からわすれましたが、vgaパラメータでは解像度は変更できなくなってしまいました。ディスプレイの解像度は、HWの進歩により非常に高密度になってしまい既定値（最高の解像度）では文字を読むことがとても辛くなりました。 新しいkernelパラメータとして、video=1024x768があるとの記事を見つけて試したのですが、思ったようには解像度は変わりません。efi環境で解像度変更をGoogleAIに助けてもらって実現できたので、その内容を記述します。 私の評価は以下の通りです。 (1) kernel parameterに、nomodeset video=efifb:1024x768を設定できます (2) uefiBIOS上のframebuffer設定で解像度を下げる設定です (3) 標準のvideo=1024x768ではuefiBIOSでの設定変更はできないようです (4) 理由はわかりませんが、nomodesetの組合せが使えました 2.詳細 利用したのはディスプレイが3:2の表示可能なNotePCです。解像度は2160x1440です。これでは文字が小さくてテキストモードで読むのはとても辛いのですが、仕方なく利用していました。色々過去に解像度設定を試したのですが、nomodesetを指定しても解像度を下げることができず、半分諦めていました。 GoogleAIが提案したkernelパラメータは、video=efifb:1024x768です。 しかし、この設定でも解像度を下げることができません。 ダメ元で、nomodeset video=efifb:1024x768と設定すると表示解像度を1024x768に変更できました。何でも試してみるののです。以前は無理な設定をす...

記事の更新日：2026/09/12 1.概要 IoTデバイス向け通信方式としてMQTTが広く利用されています。Queueと聞くと待ち行列で駅に人が到着するモデルが浮かびます。また、汎用機のジョブ管理(JES2等)のジョブキューや出力キュー、オンライントランザクション処理のインプットキュー等の方が私にはわかりやすく感じます。ネットで調べると、MQTTのmosquittoが簡単で一般的とのことなので、試してみました。その内容を記述します。 私の評価は以下の通りです。 (1) MQTTはランダムに発生するデータを一列に並べて同期処理に変えることができます (2) 一列に並ぶので整合性が取れる形でデータベースなどを更新できます (3) MQTTのmosquittoが簡単で一般的で学習する上で最適です (4) Dockerを利用して簡単に試験できます 2.詳細 参考資料のdocker-hubの記述に従って実施します。 MQTTの環境構築はDockerコンテナを利用することで非常に簡単です。それよりも試験の仕組みを理解して試験するほうが難しい。今回はterminalを３個利用します。１個めはmosquitto本体が稼働している環境です、２個めは受信環境、３個めが送信環境です。 (1) 1個めのterminalを起動 まず、ディレクトリを作成 mkdir ~/mosquitto/config cd ~/mosquitto/config vi mosquitto.conf エディットする中身は下記内容です persistence true persistence_location /mosquitto/data/ log_dest file /mosquitto/log/mosquitto.log 起動 docker run -it -p 1883:1883 -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto 下記メッセージが表示されるとOKです。 Status: Downloaded newer image for eclipse-mosquitto:latest 操作方法はdocker-hubに記載はありません。別の参考資料を参照します。 (2) 2個めのterminalを起動 doc...

記事の更新日：2026/09/29　評価を加筆 1.概要 SynologyのNAS( DS216J )でディスクでエラーが発生しました。RAID1(ミラー構成)であったので代替NASへデータを移行していたのですが、ディスクを入替えて復活させることに挑戦しました。新品のディスクに交換して初期設定すると良いのですが、せっかくのチャンスなのでRAIDのリカバリで復旧することに挑戦しました。 SynologyのNASでディスクのRAID修復は初めてです。大型のストレージ装置でRAIDのリカバリ経験はあるので、手順書を参照しながら実施できると考えました。RAID1のリカバリ手順を利用して、RAID1構成の２台のディスクを新しいディスクへ入れ替えるた手順となっています。 私の評価は以下の通りです。 (1) RAID1構成はデータ消失リスクは低いのですが、ディスクエラー管理は必須です (2) 機種に依存ですが、容量が多ければ異なるディスク間のRAID1も実現できました (3) RAID1同期時間短縮と考えて、ディスク上のデータ削除は無意味でした (4) 同じ型番のディスクでRAID1同期は時間短縮になりました 2.詳細 SynologyはToshibaの2TBディスクが2台でRAID1構成です。ディスクが１台クラッシュしたので、既に代替NASへ移行していたのですが、2TBのディスクを２台購入して、Synologyの復旧をしてみました。ディスクが値上になり、同じ製品でなく、手頃な値段のディスクを購入しました。１台を交換してRAIDを修復すると利用できるのですが、異なる製品で性能も違うので、もう１台もこのタイミングで交換することにしました。OS部分の再導入は実施せずにRAIDの修復を行いました。 手順は以下のとおりです。 (1)故障ドライブの確認 Synologyを起動するとRAID構成が片系になり、ストレージマネージャが起動します。 まず、故障したドライブを見つける機能で探します。Disk1が故障であることを確認します。 (2)SynologyからDisk1の取外し 分解するので掃除もします。Disk1の取付位置はディスク取付金具に記載されています。 (3)Synology起動 Disk2だけで起動することを確認します。OS部分を再利用するので、不要なデータ部分は削除して、RAID...

 記事の更新日：2026/09/29　評価を加筆 1.概要 LinuxMint-22.3が2026-01-13にリリースされました。過去のリリースを参照して、21.3が21の最終リリースなので、22.3も22の最終リリースになる可能性があり、21.3から22.3へ移行することを始めようと思っています。22.2を評価利用していたので、21.3と大きく変わるとことがなく、移行は難しくないと思っています。しかし、LinuxMint 21.3からLinuxMint 22.3へのUpgradeは推奨しません。 私はHome Directory( ~/ )にデータがなく、別ストレージで管理しているので、OSドライブをLinuxMint 21.3からLinuxMint 22.3へ変更して、別ストレージのデータを参照します。MailなどのHome Directoryが必要なものはバックアップをリストアする方式です。この方式ならば、移行に問題があっても戻すことができます。 私の評価は以下の通りです。 (1) LinuxMint 21とLinuxMint 22の使用感には差はありません (2) 私はデータを別ストレージを利用するので、新規インストールと調整だけでした (3) LinuxMint 21からLinuxMint 22へのupgradeは実施していません (4) LinuxMint 22.3のISOブート後、boot-repairを導入できます、LinxuMint 21.3は駄目です 2.詳細 実際に導入をしてみて、LinuxMint-21.3とLinuxMint-22.3の導入及び初期設定で変わるところはありません。細かい点で変更箇所は多数あると思いますが、Ubuntu-22.04からUbuntu-24.04への移行のように、「え〜！」と思うようなことは起きません。 LinuxMint-22.3のインストーラはLinuxMint-21.3と同じ、また、Ubuntu-22.04以前とも同じです。Ubuntu-24.04でインストーラを変更した理由は私にはわかりません。以前、CentOS(RedHat)でインストーラに大きな変更があり、使わなくなってしまったことがあります。同じものであることを期待してバージョンアップをするので期待を裏切ることはやめてほしいと思います。 U...