投稿

3月, 2017の投稿を表示しています

VanillaOS 3を試す

イメージ
以前仮想マシンで試したものの、あまり時間が取れず、しっかり使えていなかった。 余っている(テスト用においてある)Thinkpad x390に実際に入れて試してみた。 Vanilla OS ところが、サイトに行ってみると少し前(2026-08-24)にUpdateされており2→3へと2年ぶりの更新。 簡単に言うとイミュータブルなOSで、OS本体の書き換えは基本的にできず、A/Bパターンで起動する必要がある。 Aでインストールしたものは、Bに入れられ、起動時にBを選択するとインストール後の状態で使える仕組み。不具合があればまたAに戻せるというもの。 若干、コマンド類が変わってしまっているらしい。 イミュータブルなOSは、これまでにも試したものの日本語がうまく扱えないなど常用するには結構厳しいものがあった。 とはいえ、時間の経過で様々なアプリケーションがFlatpakやAppImageで出揃ってきたので、今回テストすることにした。 インストーラ自体は小さく、起動用のUSBに書き込んで起動すればOK。 インストール完了後、マシン名やユーザ名を入力することで、環境設定は完了。 基本的にはFlatpakでインストールするのが正しい使い方らしいので、必要そうなものを入れてみた。 vscode Brave Browser LMStudio DBeaver-ce Thunderird Obsidian opencode LibreOffice など・・・ どれも、サクサクと動作して気持ちいい。 日本語環境 さて、問題は日本語環境だが、調べてみるとflatpakにmozcもfcitx5も存在していた。 これんらばと思い、入れてみる。 https://note.kurodigi.com/vanillaos-fcitx5-mozc/ が、vanillaOS2の記事のようだけれども、同じ手順でOKだった。 すばらしい。 いつも使用しているmozcが動作するようになった。 ところが、LMStudioでハマった… flatpak特有の問題 LMStudioはすんなり入り、LMLinkでローカルのAIサーバも使用可能。 で、URLを指定したときにWEBサイトを取りに行かせて、処理させるMCPでハマった。 https://github.com/modelcontextprotocol/servers...

UTF8の指定ではまった

MariaDB+PHPにて PHPでDB上のデータを大量に処理するプログラムを書いていて、おかしな現象に出くわした。 1万件+42万件+43万件のjoinで、必要なもののみ取り出して、updateをかけるという手作業ではやる気にならない処理なので、サクッと書いてぶん回すしかない…。 ローカルでmysqlモニタを使用してSQLを叩くと、問題なく結果が返ってくる。 でもって、サーバ上で実行すると、結果がEmpty…。 あれれ? 試しに、phpmyadmin上でSQLだけ叩いてみる。 ローカルと同じ結果になる。 何かがおかしい。  :  : $mysqli = new mysqli("localhost",$username,$password); if($mysqli->connect_error){   print('<p>データベースへの接続に失敗しました</p>'.$mysqli->connect_error);   exit(); } $mysqli->select_db($dbname); $mysqli->set_charset("utf-8"); $sql="SELECT bill.bill_id,bill_item.bill_item_id,bill_item_detail.bill_item_detail_id,              bill.billing_id,bill.bill_month,bill.bill_date,bill.deposit_receive_date   FROM `bill_item_detail`   join bill_item on bill_item_detail.bill_item_id=bill_item.bill_item_id   join bill on bill.bill_id=bill_item.bill_id   WHERE `bill_item_detail`.`name` LIKE '繰越残高' AND  :  :   order by bill.b...

404エラーが多発?

イメージ
Google Search Consoleからメールが来た 今度は、なりすましではなく…。 本家からエラーが急に出ているよと報告のメールが届いた。 特に、外部へのリンクは多く張らないようにしているし、急に増えるというのが解せない。 何か、トラブルが起きたのか? ということで、エラーの内容を確認してみる。 Search Consoleで確認 とりあえず、どのリンクでエラーが出ているのかを見てみると、 2013_03_null_archives.html とか、2015_04_null_archives.html という日付のアーカイブ?なのか、null_archivesなので、アーカイブでないのか良くわからないリンクへのエラーが大量に発生。 図は、すでに該当のリンクを全て「修正済とする」と指定した直後。 2017/02/05に初めて1件のエラーが出ているが、これは上記に残っているアタックと思われるアドレス。 大量に発生しているのは3月に入ってからで、10日以降にドンと発生している。 これらのリンクとして考えられるのは、レイアウト情報にあるガジェットの「ブログアーカイブ」くらいしかない。 過去の記事を、年月指定で見に行くガジェットで、別に自作したものではない。 Google謹製なので、自前のツールでエラーが出ているとしか思えない。 多分、時間と共に収束するのかもしれないが、気持ちが悪い。 まず、修正済にして様子を見てみるしか、現時点では手がない。 海外でも、同様のメールが届いたが、何をすればよいか?という書き込みを見つけたが、公式の案内に書かれている事以外、特に解決策らしきものはなさそうだ。 これでも、同じように404エラーを吐くのであれば、robots.txtにエラーとなるURLをすべて書き込むしか解決方法はなさそう…。 面倒なので、ちゃんとクロールするようにしてくれるのが嬉しいのだが…。

LINE乗っ取りにまんまとヤラれてしまった

イメージ
事の顛末 朝から少々面倒なデータ編集作業と、コード書きをしていて…。 頭が疲れてきたので、通常のメールの確認と、迷惑メール内のチェックをしてました…。 で、普段なら軽々しく信用しないのですが… で、以下がそのメール本文。 差出人は軽くチェックし、画面へ遷移。 いつもなら、URLも確認するんだけど…。 これが、その画面。 まあ、ログインして確認しておこうと、ログインしたのですが…。 で、さっくり乗っ取られて…。 ぐはぁ…と。 素人同然のことをやってしまいました。 疲れた脳味噌は判断力を低下させてくれるようです。 あちこちから、お電話もらいました。 絶対にヤラれているわ…とか、おかしいと思った…、とか。 連絡しようにも、LINE自体が使えないので、電話しか…。 ということで、本当に申し訳ないことをしました。 LINEのメッセージを信じて被害に遭わないことを祈って・・・。 本当にご迷惑をお掛けしました。 LINEには、乗っ取りの連絡をしてあるので、何時間かで収束するとは思うのですが…。