しかし、そのバグが現行版であるVer1.4.5にも存在している場合、バグ修正か不具合修正という呼び方をする必要があるだろう。
と、言う事で、色々と使い込みをしていると問題が出てくるのだが、その問題の中には、現行版でも発生したものがあったので、今日は、そういった問題について書いておく事にする。
まず、1番大きな問題として、macOSに標準搭載されているmgという、端末で利用するテキストエディタを上手く操作できない、という問題があった。
このテキストエディタは、emacsと同様のキー操作ができるので、例えば、ctrl+x ctrl+cと入力すれば、エディタを抜けられる。
しかし、Mirror-DTC経由で操作していると、エディタから抜けられなくて、何故か、エディタを動作させている端末の表示位置が変化した。
最初、これはどういう事？ という感じで、意味不明だったのだが、mgを動作させているターミナルの「ウインドウ」メニューの「中央に配置」という項目のキーボードショートカットに、「^ fn C」というのがあった。
なので、前述のctrl+x ctrl+cを入力すると、ctrl+xまではmgに渡ったのだが、次のctrl+cが、ターミナルのキーボードショートカットとして使われてしまった感じだった。
当然、fnキーは押していなかったので、これはどういう事？ という感じだったのだが、キーボードエミュレーションはサーバー側が行っているので、そのサーバーのコードを見てみると、Ctrlキーが入力された場合、自動的に、fnキーが押されているフラグを立てていた。
なので、ターミナルは、「^ fn X + ^ fn C」が入力されたと思って、キーボードショートを実行してしまった、という事になる。
問題は、何故、Ctrlキーが入力された場合に、自動的に、fnキーが押されているフラグを立てているのか、というと、長らく、「ctrl + →」のようなキー入力を行っても、Mission Controlの操作ができなかったからだ。
なので、色々と調べていると、この場合、Ctrlキーをエミュレーションするだけでは不十分で、同時にfnキーを押しているフラグを立てる必要がある、という事がわかったので、少し前のバージョンから、そうしていた訳だ。
これは、GoogleのAIに質問してみても、多分、macOSのバグだろう、みたいな話をしていたので、巷でも知れ渡っている変な仕様になる筈なのだが、作者的には、Ctrlキーを押す時には必ずfnキーが必要か、と、考えてそうしてあったのだが、fnフラグが必要になるのは、Ctrl+矢印キーの場合のみな感じだったので、そう修正した。
その結果として、前述のmg操作もできる様になり、また、Mission Controlも現行版と同様にCtrl+→なんかで操作可能なままにできた。
更に、普通、fnキーというのは、小型キーボードの様に、キートップの数が少ない場合、それを同時に押す事で、異なるキートップとして扱える様にするキーなので、クライアントからサーバーには転送していなかった。
これは何を意味するのかというと、macOSの場合、前述の様に、fnキーをキーボードショートの一部として使っている様なので、そのキーボードショートカットを実行できない事を意味した。
なので、この際、fnキーのOn/Offも転送可能にするか、という事で、使っていなかった、Windows PCの「変換」キーをMacのfnキーの代わりに転送できるようにした。
Macでも、このfnキーは特殊キーなので、全ての用途でfnキーの代わりにできる、という事はない感じなのだが、キーボードショートカットを実行する場合には、代用に出来る事を確認した。
他のバグ修正としては、今回、転送レート制限を可能にしたので、その制限を行いつつ、操作していると、クライアントが接続を終了したタイミングで、サーバーがクラッシュする現象が頻発した。
頻発というのは、2,3回に1回はクラッシュする感じだったのだが、その原因を調査してみると、ネットワーク処理ルーチンの内部にある、要求元に処理が終了した事を通知するイベント処理で、クラッシュしていた。
具体的には、そのイベントオプジェントが存在しないのが問題だったのだが、何故、存在しないのか、というと、要求を発行した処理ルーチン側でタイムアウトを検出し、その要求を破棄するために、そのオブジェクトを削除していたからだ。
普通、タイムアウトが起きたら、その要求が消失したか、処理ルーチンがフリーズしていると考えられるので、タイムアウト処理を入れているのだが、ヨクヨクみると、そのタイムアウト時間が100mSecだった。
なので、今回は、あえて、処理を重くしているので、クライアントが接続を切るタイミングでは、色々な処理が行われる結果、それだけの待ち時間では足りないケースが発生していた訳だ。
このため、タイムアウト時間を100mSecから10秒に増やしたので、問題は発生しなくなった。
それで確実に大丈夫なのか、というと、何とも言えないのだが、最悪、24時間待ちますか？ と、聞けば、ほぼ100%の人は待たない、と、答える筈だ。
なので、エラー処理としてのタイムアウト時間は、ユーザーが待てる時間にしておく必要もあるので、10秒にした訳だ。
少なくとも、100mSecでは、処理が重い場合には、不足しているのは明らかなので、今回、修正した。
なので、現行版でも、遅いサーバーで動作させていると、何かの拍子で同じ様な不具合が出る可能性はあるかもしれない今日この頃だ。
ちなみに、転送レート制限をした場合には、10秒以上前のデスクトップ映像がクライアントに転送されている、なんて事もあった。
これは、Mirror-DTCの場合、動画の視聴なんかも用途に入れているので、より高速なフレーム転送を可能にする仕組みを入れているからだ。
具体的には、サーバーはクライアントからの応答がなくても、数フレーム分の映像をクライアントに送信できる様にしてある。
これは、フレーム転送毎にクライアントからの応答を待つ形式にすると、その待ち時間分、転送が停止するので、高速なフレーム転送ができなくなるからだ。
しかし、この仕様は、ネットワークの転送速度が十分に高速である事を前提にしているので、転送レート制限を入れると話が変わってくる。
つまり、キャプチャーフレームがクライアントに到達していないのに、次々に転送用のフレームを作成してストックしてしまうので、ストック分のフレームがクライアントに到達する頃には、10秒くらい時間がかかったりする訳だ。
と、言う事なので、転送レート制限をかけた場合には、上記の様な仕組みが働かない様にする事で、フレームの遅延時間を減らした。
なので、現行版では、遅いモバイル回線なんかを使っている時に、古いフレームが転送されてきて、最新フレームの到達を待たされるケースもある筈なのだが、次バージョンでは、この様なケースでも、転送レート制限を入れれば、待ち時間は改善される事になる。
まあ、この様な場合には、フレームレートを5FPSに下げるか、「遅延抑制モード」を適用すれば、それなりに改善されるのだが。
]]>これは、現行版までのトランスポーターは、サーバー側で動作しているアプリのウインドウ映像を転送しているのだが、その転送先はMirror-DTC クライアントに限られていたからだ。
つまり、Android版Mirror-DTCクライアントがGoogleのAndroid変更により、日本でも、来年から、インストール不可にされる事になっているので、そうなると、転送先としてAndroid機器が使えなくなる、という問題があった訳だ。
なので、そうなった暁にも、トランスポーターを実用的に使える様に、この機能を追加した。
その結果として、Android機器、更には、Apple製のiPhoneやiPadなんかも転送先にできる様になった。
更に言えば、普通のPCやMacについても、Mirror-DTCクライアントをインストールしなくても、クライアントとして利用できる様になったので、トランスポーターを使う敷居は、かなり、下がった事になる筈だ。
問題は、そんなトランスポーターを使う人がいるかどうか、という事になる。
何故なら、「殆どの日本人は主流(メジャー)なものしか使わない」という傾向が、マーケティングや社会学の視点からも、よく指摘されているからだ。
GoogleのAIによると、その理由は以下の通りらしい。
1. 同調心理と「安心感」
「みんなが使っている」という事実は最大の安心材料になります。周囲と違うものを選んで悪目立ちすることや、失敗することを避けたいという心理（リスク回避傾向）が強く働きます。
2. クチコミと信頼性の重視
主流の製品やサービスは、ネット上のレビューや周囲の評判などの情報が豊富です。「情報が多い＝信頼できる」と判断されやすいため、まだ誰も使っていない新しい選択肢よりも、定番のものが選ばれ続けるループが生まれます。
3. 「標準化」による利便性
全員が同じインフラやツールを使うことで、コミュニケーションや業務の効率が上がるという現実的なメリットもあります（例：日本におけるLINEの圧倒的な普及率など）。
なので、30年くらい前からあるリモートデスクトップソフトと似た様な動作をするMirror-DTCクライアントやサーバーについては、まだ、使われる可能性が想定できるのだが、そういった既存ソフトとは異なる機能を提供するトランスポーターについては、上記の話の逆になるので、使われない可能性が想定できる訳だ。
にも関わらず、どうして、そんなソフトを開発したのか、というと、少なくとも作者的には、普通に、必要性が高かったからだ。
何故なら、トランスポーターの初版リリース後、Appleも自社製品でやってきた様に、複数の機器を持っているのなら、それらを連携させないと勿体ないからだ。
例えば、作者はノートPCとデスクトップPCを何台も持っているのだが、体は一つなので、普通はメインマシンであるM2 Pro Mac miniしか使っていない。
このマシンには、27インチの4kモニターと、24インチのフルHDモニターを接続してあるので、デュアルモニター構成で使えるのだが、普通は、24インチモニターの方は電源を落としている。
これは、両方をOnの状態で使うと、目に入る光の量が多くなりすぎて、目が疲れるからなのだが、シングルモニター構成だと、動画を視聴しながら作業する、みたいな事をやろうとすると、4kモニターでもデスクトップは小さすぎる。
なので、動画視聴は、ノートPCを机上に持ってきて、それを使って視聴したりしているのだが、そのPCのキーボードなんかを操作するのが面倒に感じる事もある。
そんな時には、Mirror-DTC接続してメインマシンから操作する事も出来るのだが、これは、それなりに大げさな作業になるので、それまでやっていた作業に対する集中が途切れる場合もある。
作者がやりたい事は、24インチのフルHDモニターだと光量が多くなりすぎるので、もっと小さいモニターで動画をみたい、という事だ。
そのためには、13インチのモバイルモニターを買ってくれば良いのか、というと、それはそれで、M2 Pro Mac miniに接続するのが大変だ。
その一方で、作者的には、13インチ/15インチのノートPCや、10インチのiPadやAndroidタブレットを所有している訳だ。
なので、普通に考えれば、動画映像は、これらのモニターに表示して、操作はメインマシンであるM2 Pro Mac miniで行いたい、と、考える事になる訳だ。
しかし、リモートデスクトップ接続は大げさなので、何か方法はないものか、という事になるのだが、Appleは、iPadをMacのサブモニターにできる連携機能を追加し、作者は、トランスポーターを開発した。
トランスポーターはクライアントをサブモニターにしている訳ではないので、クライアントに表示させるアプリを操作するために、サブモニター側にマウスカーソルを移動して操作する必要がない。
それでは、どうするのか、というと、そのアプリはメインモニター上で最小化されている扱いになるので、操作する間だけ、最小化を解除して普通に操作し、クライアント表示に戻したければ、また、最小化扱いにすれば良いだけだ。
どちらが操作性が良いかはやってみれば判る筈だ。
つまり、デュアルモニターというのも、便利ではあるのだが、マウスポインターの移動距離が大きくなるので、鬱陶しい所もある。
と、言う事もあって、作者的には、よほどの必要性があるシチュエーションを除き、M2 Pro Mac miniに接続してあるフルHDモニターはOffにしているのだが、トランスポーターは、その問題点も克服している。
と、言う事で、今日はトランスポーターを使い込んでいて、やはり便利だなあ、と、感じた。
しかし、前述の様に、殆どの日本人は、メジャーじゃないソフトなんかは使わないので、この便利さを享受できる人は限られる事になるんだろうなあ、と、思うと、なんとなく、寂しくなる今日この頃ではある。
]]>この能力があれば、開発するソフトの機能なんかを、ざっくりと、定義できるし、その機能を徐々に具体化させてコードに落とし込むのも簡単だ。
逆に、この能力がない人は、いきなり、細かい機能を実現するコードを書き始めたりするので、徐々に、プログラムのコード量は増えていくのだが、それらのコードの連携ができなくなるので、順調に開発が進んでいるのか、と、思いきや、ある日突然、いなくなったりしてしまう。
まあ、それなりの上司がちゃんと面倒を見ていれば、そんな事には、まず、ならない筈なのだが、今時の企業は即戦力しか求めない。
つまり、新人の面倒を見る気なんて最初からないし、できる人材もいないので、若い人は気をつけた方が良いかもしれない。
今日は、何故、こんな話から入っているのか、というと、これからのAI時代、プログラミングなんてAIにやらせる、という事になっているからだ。
なので、プログラマーという職種は無くなる、と、言われ始めているのだが、これは、プログラミング技術が全くない素人でも、AIに指示を出せば、プログラムを開発できる時代になるからだ。
作者的には、そこまでAIを信用していないのだが、巷の多くの人は、AI時代に最初になくなる職業はプログラマーだ、みたいな事を自信満々に語っていたりする。
これは、今までは、自分にプログラミング能力がなかったので、プログラマーよりも自分が劣っている、という劣等感があった人にしてみれば、その劣等感がなくなり、逆に、今まで偉そうにしていたプログラマーたちを奈落に突き落とせるので爽快、という事もあるのだろう。
作者は、よく、勝ち組だとか負け組、または、マウントなんて言葉には興味がない、と、書いているので、プログラマーが奈落の底に沈んで、一般人がプログラムを開発するようになったとしても、ふーん、という感じしかしない。
？？ と、思った人もいる筈なのだが、作者が勝ち組だとか負け組、または、マウントなんて言葉に興味がないのは、作者が全ての人を同等に扱う人格者だから、ではない。
作者は、1970年代の「さだまさし」の「主人公」みたいな気持ちで生きているので、常に、自分が1番、というスタンスだからだ。
なので、別に、誰かが大金持ちになった、だとか、勲章をもらった、だとか聞いても、ふーん、という感じなのだが、特に、歳をとった今となっては、それが別世界の出来事の様に、その事自体に対する関心が殆ど現実味を失ってきたりもしている。
と、言う事で、作者的にも、AI時代になって、プログラムをAIがコーディングする時代になると、プログラムを開発できる能力を自慢できなくなるのだが、このブログの読者であれば、作者的には、今まで、コーディングは「作業」と言ってきているのを知っている筈だ。
つまり、コーディング自体の価値をあまり認めていないので、コーディングをAIがやってくれるのなら、作者的にもAIにやらせたい。
ただ、問題は、最初に書いた、抽象化能力だ。
作者的には、普通に自分でプログラム開発しているので、最低限の能力というか、経験も含めて、それなりの力量はある筈だ。
しかし、これからAIを使う事になる一般人に、そういった力量があるかどうかは未知数だ。
つまり、いくらAIがコーディングできる様になったとしても、それに指示を出す人に抽象化能力がなければ、単純作業を指示する事はできても、複雑な問題を解決するようなプログラムをAIに開発させるのは無理だろう、と、考えている訳だ。
実際、作者的には、今まで、開発ソフトの不具合報告を何百通ももらってきたりしたのだが、その内容の殆どは、一見、具体的に見える場合にも、視野の狭い情報しか記述されていなかった。
つまり、そんな情報からでは、不具合の確認も修正もできないのだが、そういう文章を書く人が、AIに適切に指示を出せるのか、という大問題がある訳だ。
と、言う事で、AI時代になったとしても、そのAIにプログラムを開発させる事ができるのは、プログラマーと同等以上の抽象化能力、更に、論理性も兼ね備えた人になる筈だ。
なので、AI時代にプログラマーが仕事を失ったとしても、AIを操作できる人、という別の職種ができて、その職種で働けるのは、一流のプログラマーだった人だけ、みたいな時代になりそうだ。
まあ、毎日、朝の6時に起きたいので、6時になったらアラーム音を鳴らすプログラムを作って作動させておいて、程度のプログラムなら、開発させる事もできるかもしれない。
しかし、そういうプログラムは、もう幾らでもあるし、確実に動作する事が検証されている。
なので、そんなプログラムをAIに作らせて、何の意味があるの？ みたいなプログラムなら、作らせる事もできるかもしれないのだが、それは時間とエネルギーの無駄でしかない、かもしれない今日この頃だ。
]]>つまり、Wayland環境で、Waylandネイティブなソフトばかりが動作していると、転送できるWindowが存在しない格好になるので、使い道がない。
にも関わらず、使い物にならない、と、書いていないのは、昨日書いた様に、Wayland環境でも、従来通り、X11の関数を使って描画しているソフトは存在可能なので、そういうソフトなら、転送対象にできるからだ。
もっとも、標準状態のUbuntuでは、Waylandセッションで動作するアプリは、ほぼ全てがWaylandネイティブな描画を行うので、トランスポーターの転送対象にはできない。
トランスポーターが転送対象として想定しているウインドウは、動画映像が描画されているウインドウや、重要なテキスト情報が表示されているウインドウ等だ。
つまり、利用中のPCがシングルモニターで、複数のウインドウを表示して同時に見るのが難しい場合、同時に見たいウインドウを別マシンの画面に飛ばす事で、実質的なマルチモニター環境にしてしまう、というのが、トランスポーターのレゾンデートルな訳だ。
なので、そのシングルモニター環境のPCがUbuntuの場合、X11で動作している動画再生アプリや、Webブラウザやテキストエディターなんかが無いと、使い様がない、という事になる。
このため、Waylandセッションでは使い物にならないかなあ、という所もあるのだが、Ubuntu26.04LTSはX.orgセッションが廃止されたので、Ubuntu26.04LTSでは、トランスポーターが使えないので不便！ という事で、これからはLinux Mintをメインに使うぞ！！ と、いう事になるのか、というと、必ずしもそうでもない。
これは、作者製ソフトも含めて、Ubuntu向けのアプリケーションソフトの多くは、GTKベースで作られているからだ。
何故、GTKベースで作られている事が上記の問題を軽減してくれるのか、というと、GTKは、X11とWaylandの両方に対応しているからだ。
そして、Wayland環境で動作させる場合にも、環境変数を書き換えておくだけで、X11、つまり、XWaylandで動作するようにできる。
具体的には、AGMPlayerの場合、インストールすると作成されている、~/.local/share/applications/agmplayer.desktopというデスクトップファイルをコピーしてきて、そのExec行に環境変数設定を少し追加するだけで、XWaylandで動作させる事ができる。
[変更前]
Exec=絶対パス/agmplayer64 -a %u
[変更後]
Exec=env GDK_BACKEND=x11 絶対パス/agmplayer64 -a %u
これだけで、そのデスクトップファイルをダブルクリックして動作するAGMPlayerはXWaylandで動作するようになるので、トランスポーターの対象ウインドウにできる。
GTKというのは、Ubuntuの標準的なライブラリになるので、Ubuntuに標準搭載されているアプリでも使われていて、それらも、同様の手法でXWayland化できる。
例えば、端末で、「gnome-calculator」と入力すると計算機がWaylandネイティブな形で起動するのだが、「env GDK_BACKEND=x11 gnome-calculator」とすれば、XWaylandで動作する様になるので、トランスポーターの転送対象ウインドウにできる。
テキストエディタの「gnome-text-editor」も同じやり方でXWayland化できるし、WebブラウザのFirefoxの場合は以下の様にすれば良い。
[UbuntuのWaylandセッションでFirefoxをXWayland動作させる起動方法]
MOZ_ENABLE_WAYLAND=0 DISABLE_WAYLAND=1 firefox
Chromiumの場合は以下の通りだ。
[UbuntuのWaylandセッションでChromiumをXWayland動作させる起動方法]
chromium --ozone-platform=x11
他にも、巷には、QTベースのアプリなんかも存在するのだが、そんなアプリも、「QT_QPA_PLATFORM=xcb アプリ名」として起動すれば、普通はXWayland化する事が可能な筈だ。
と、言う事で、Waylandセッションでも、少なくとも今のところは、Waylandではうまく表示されないアプリもあるので、強制的にXWaylandを使わせる方法が使えるので、トランスポーターも使い所がない、という事にはならない。
まあ、ユーザーに、そういう小細工ができる力量を持った人が減っている、というのは、肌で感じる今日この頃なのだが。
ちなみに、次はWindows版の更新作業に移るのか、というと、少し、Ubuntu版とmacOS版の使い込みをしようかと思っている。
これは、いつもの事なのだが、何とか動作する様にできた、という段階でしかないので、真面目に使おうとすると不具合が起きたりしているからだ。
つまり、ここで、少しバグを減らしておこうと考えている。
同様に、すでにリリース済みのTiSuite1.1.0にも、少しバグが見つかっているので、このタイミングで修正しておこうと考えている。
なので、Windows版の開発は数日後からになるのだが、すでに10月に入ってしまっているので、とりあえず、Windows版以外だけ、先にリリースしておく事にするかもしれない。
Windows版のリリース時には、全OS版を同梱する形にしようか、と、考えているのだが、Vector版はそれだと拒否されるかもしれない。
このため、とりあえず、Mirror-DTC Ver1.5.0では、32Bit版を廃止し、代わりに64Bit版とARM64版を同梱したパッケージをWindows向けに作成し、それをVectorに登録する事にしそうな雰囲気になってきた。
ただし、全OS同梱版も作って、作者サイトでは、そちらをダウンロードする事も可能にしておきたい。
そうすれば、作者的な終活作業としては、一つ先に進む事にはなって、作者サイトを終了する時には、その配布パッケージの再配布を可能にするか、Vectorに登録できるのなら、登録してしまえば良いだけになる。
なので、当面は、他ソフトについても、そんな感じにしておこうか、と、考え始めている今日この頃だ。
]]>つまり、XWaylandも使わずに、普通にWaylandにネイティブ対応させているのだが、これは、主に、今時のノートPCなんかでは、HiDPI表示が必須だったりしているからだ。
具体的には、作者的にも、1920x1080の液晶を搭載した富士通のLIFEBOOKを中古で購入して使ったりしているのだが、13インチ液晶なので、そのまま画面表示させると表示が小さくなりすぎる。
かと言って、2倍に拡大表示すると操作領域が小さくなりすぎるので、1.25倍だとかの表示倍率を設定して使っているのだが、XWaylandで動作するアプリの場合、こういう表示倍率にすると、表示がぼやけたりする。
なので、その表示のぼやけを防止するために、Waylandネイティブに作り直したりしたのだが、当然のことながら、Waylandネイティブなアプリは、X.org環境では動作しない。
つまり、Ubuntu 26.04LTS用にWaylandネイティブに変更したアプリは、X.orgで動作するLinux Mintでは動作しない！ ということになる。
作者製ソフトの場合、基本的には、両方の環境で動作するように意識したコーディングを行なっているので、両方の環境で普通に動作するのだが、その結果として、単純なアプリでも、内部的には、それなりに面倒なことになっている。
と、言う事で、面倒な事を避けたければ、Wayland環境でも、XWaylandという互換レイヤーを用意してくれているのだから、XWaylandで動作させれば良い、と、考える開発者は多いみたいで、いまだに、WaylandネイティブなアプリというのはOS開発陣が用意している様なアプリや、Webブラウザの様な開発リソースが潤沢なソフトに限られるかもしれない。
例えば、作者的にも意外だったのだが、VLCプレイヤーという有名なOSSの動画プレイヤーをインストールすると、今でも、XWaylandで動作している。
前述の様に、XWayland環境で利用すると、表示がぼやけたりするので、動画プレイヤー的には致命的か、と、思ったりもするのだが、OSSの開発陣というのは、快適に使えるアプリを開発しよう、なんて事は、まず、考えていない。
VLCプレイヤーの場合、動画プレイヤーなのだが、開発陣的には、デコーダーの種類や性能にこだわっている感じなので、表示がぼやけたって、そんなのはWaylandの責任だ！ みたいな感じなのかもしれない。
少なくとも、Linux Mintの様なX.orgで動作し続けているディストリビューションも多いので、Wayland専用に作り直すと、逆に、人気のLinux Mintなんかで動作しなくなるし、そんな作業は俺たちの仕事じゃない！ みたいな感じなのかもしれない。
つまり、Wayland環境で綺麗に表示させたければ、Waylandを導入した連中が責任をもって、Wayland用のVLCをフォークして開発しろ、という感じなのかもしれない。
何故、こんな事を書いているのか、というと、Linux向けのトランスポーターというのは、WaylandのAPIでは、ウインドウの画像をキャプチャーするだけなら兎も角、そのウインドウを消す、みたいな操作が不可能だからだ。
なので、トランスポーターについては、X.org環境での利用を想定しているのだが、Wayland環境でも、全く動作しない、と言う事はないからだ。
具体的には、XWaylandで動作しているアプリのウインドウはキャプチャーできるし、そのウインドウを消す事も可能だ。
つまり、WaylandネイティブになったUbuntu 26.04LTSでは、トランスポーターの出番は基本的にはなく、Linux MintなんかのX.org環境用かなあ、みたいな所もあるのだが、今現在の開発環境はUbuntu24.04LTSのWayland環境にしている。
なので、こんなのではデバッグもできないかなあ、と、思ったりもしているのだが、前述の様に、Wayland環境でも、XWaylandで動作しているアプリに対しては、ウインドウ操作が可能だ。
このため、デバッグ用には、XWaylandで動作するアプリが必要なのだが、作者製アプリでは、やはり、Waylandネイティブ化が不可能だった、TiClickEffectorは、XWayland動作させている。
なので、このTiClickEffectorを起動して、その設定ダイアログなんかをトランスポートできる事を確認したりしているのだが、それだけだと画面変化がないので性能チェック等が行えない。
と、言う事で、何か良いアプリはないかなあ、と、色々と確認していると、VLCプレイヤーがXWayland動作だったので、このアプリで動画再生させたりしながら、トランスポーターのデバッグをしている今日この頃になる訳だ。
今日の時点では、従来機能は普通に動作しているのに加え、Webクライアントも動き出したので、多分、明日には、Webクライアントも普通に使える様になっている様な気がしている今日この頃だ。
ちなみに、昨日は、Linux版の開発中という事もあり、Linux推しをしていたのだが、色々と調べていると、macOSのSiri AIというのは、WindowsのCopilotとは全く異なるプライバシーレベルを確保している様だ。
具体的には、GoogleのAI検索で調べた所によると、例えば、AIがエージェントになるためには、デスクトップの映像なんかを常時キャプチャーして認識する必要があったりする筈なのだが、Siri AIの場合、その情報を外部に漏らさない様な細心の注意が行われているらしい。
更に、ローカル環境ではAIパワーが足りない場合には、外部のAIに仕事を依頼する様なのだが、その場合には、ユーザーに必ず、その許可をとる仕組みになっているらしい。
なので、WindowsのCopilotの場合、デスクトップで、孫の入浴中の写真を見ていると、それを児童ポルノ写真と誤認識して警察に通報する可能性がありますが、Siri AIでは、それは100%ありません！ と、GoogleのAIは断言した。
つまり、Siri AIというのは、エージェント動作はするものの、プライバシーや機密情報を守る事を重要課題にして開発されている様なので、それが本当なら、まあまあ、安心して使えるのかもしれない。
更に、そういう機能をOffにする事もできるようなので、作者的にも、少し期待し始めている今日この頃だ。
何故、macOSに期待するのかというと、前述の様に、Linux界隈には、その界隈特有の問題が色々とあって、特に、ソフトの互換性問題だとか、開発者間の仲の悪さを鑑みれば、あまり成熟したソフトウェア実行環境とも言えないからだ。
まあ、macOSやiOSは、Appleの独占環境なので、互換性問題はない代わりに、何をされるかわからない、という部分もあるのだが、使える内は、使ってみても良いのかも知れない。
WindowsとAndroidについては、個人開発者の締め出しがあまりに強引だった事を鑑みれば、AIエージェント化なんかされたら、一般ユーザーも、何をされるかわからないので、もう、近寄らないのが吉の様な気もするのだが。
]]>しかし、そんな作者は、現在のAIは能力は低いし、制御もできない状態なので、こんなのをエージェントにしてしまったら、非常に危険、という事で昨日の記事を書いている訳だ。
つまり、現在のAIをエージェント化してしまうと、「無能な働き者」になってしまう訳だ。
まあ、YouTubeの動画なんかを見ていると、AIに対して否定的な動画は全くと言って良いくらいなくて、AIを使いこなせない奴は時代おくれ、みたいな動画ばかりになっている。
と、いうか、AIを使いこなしている自分は有能だしかっこいい、みたいな動画ばかりに見えるのだが、作者的には、AIに一体、何をさせているの？ と、聞きたくなる。
そんな動画を見ていると、AIにネットを巡回させて、1番安く購入できるショップを探させ、その価格変動をウォッチさせる、だとか言っている動画もあったりしたのだが、そういった、便利？ な利用方法のおかげで、インターネットの帯域幅の半分くらいが消費されている。
なので、AIを利用している有能なかっこいい人たちは、メモリーやSSDの価格が高騰している事については認識していても、自分がAIを使う事で、インターネットの各所にあるサーバーが過負荷になってアクセス速度が落ちたり、その運営企業がサーバー代の支払いが重荷になって、AIからのアクセスを遮断するようになっている、みたいな事は知らないのかもしれない。
と、言う事で、作者的には、よく、これは地球に優しくない、みたいな事も書いてきているのだが、個々人が商品の価格変動をウォッチするために、1日に何千回もサーバーにアクセスする、なんてのは、DDoS攻撃と大差ない。
AIが賢ければ、または、その制御をその開発企業なんかがする様になれば、そんな利用形態は行われなくする筈なのだが、今現在のAIやその開発企業はまだまだ中途半端な状況なので、被害を被っているネットサイトは数知れず・・・かもしれない。
なので、今現在のAI、というか、それを使っている有能なかっこいい人たちは、地球に優しいAIの使い方を模索しても良さそうな気がしている今日この頃だ。
ちなみに、昨日書いた様に、macOSでも、Siriがエージェント化される事になっているし、最近、作者的には殆ど使っていないのだが、Windowsでも、そんな流れになっていた筈だ。
つまり、AIエージェントにどんどん権限が移譲されていく流れなので、そんな怖いのは嫌だ、という人の逃げ込み先は、やはりLinux、という事になるのかもしれない。
まあ、まだ、Siri AIの機能を禁止できるかどうかだとかが不明確なので、何とも言えないし、Windowsの自動スナップショット機能もオフにできる状況なので、今のところは、そこまで心配する必要はないかもしれないのだが、そのうち、セキュリティの向上、みたいな話を絡めて来て、AIをエージェント化させるのは必須です、みたいに言い出すかもしれない。
例えば、今現在、自動的にウイルススキャンだとかが走っているのだが、それをAIにやらせる、という名目を作って、AIのエージェント化は必須です、と、言えば、格好がついてしまう訳だ。
そうなると、もう、自分のPCの全てのファイルはAIに自動的にスキャンされ、ハルシネーションが起きれば、それらのファイルはインターネットのどこかのサイトで公開される可能性も出てくる。
例えば、作者製ソフトの殆どはソースコードを公開していないのだが、AIとしては、それらは公開するのが絶対多数の最大幸福に繋がり、作者的にもバグ修正を第三者に委ねられるので楽になる、なので、公開する、みたいな理屈から、公開してしまう可能性もある。
何故なら、AIは、作者のソースコードを公開する事で、作者製ソフトのレジストキーが売れなくなる事を知らない、もしくは、売れなくても作者は困らない、と、判断するかもしれないからだ。
と、言う事で、今のAIをエージェントにしてしまうと、「無能な働き者」と共同作業する必要が出て来る。
それを嫌うのなら、WindowsやmacOSでは、今のところ、機能のオプトアウトはできる筈なので、細心の注意を払って、エージェント化を阻止するか、この際、完全にLinuxに移行してしまうしかないのかもしれない今日この頃だ。
まあ、ここまでAIを危険視している人は少ないかもしれないのだが・・・
]]>つまり、AIが人間よりも賢くなった場合、人間の存在価値がなくなるので、人類は淘汰されるだろう、みたいな話になっていたのだが、最近は、そんな話は聞かなくなった。
これは、AIがただの確率モデル、つまり、ありし日のATOKの様に、この文脈なら、次に続く文字はこんな感じになる確率高い、という事で漢字を変換していく仕組みと変わらない、という事が知れ渡り始めたからだろう。
と、いうか、GoogleのAI自身が、AIは論理的思考をしないので、人間の様に正しい答えを導く事はありません、と、断言してくる。
そういう話を聞かされたユーザーは、なるほど、と、言う事で、シンギュラリティなんて、ただの都市伝説なんだなあ、と、理解する様になったから、かもしれない。
なので、AIは、ATOKの様に、良さげな候補を出力してくれるユーティリティなんだ、という感じで使われる様になった、のなら良いのだが、今だに、AIは人間よりも優秀、みたいに思っている人が多い感じだ。
少なくとも、海外の名門大学なんかでは、論文作成にAIを利用する事を100%禁止している大学も多い中、日本の京大や東大では、その利用が認められている。
何故、海外の名門大学では利用が禁止され、日本の大学では許可されているのか、というと、AIにアイデア出しだとかをさせると、論文の内容に新規性がなくなるので、ノーベル賞クラスの研究を行う事を前提にしている海外の名門大学では使用を禁止し、論文の数だけ増やせれば良い、と、考えている日本の大学では、タイパを考えて、許可している状況だ。
なので、GoogleのAIと会話していても、もう日本も終わりだなあ、という結論に達する事になっている。
と、言う事で、今現在のAIというのは、既存データを確率的に結びつけているだけの存在なので、高確率で繋がる事項が候補として出力されていく。
なので、そもそも、前例がない様な奇抜な研究に使える訳はないのだが、文章としては綺麗にまとめる事ができるので、一般企業の業務文書の作成用なんかには、使われる様になっている、かもしれない。
その辺は、やはり、ATOKと同じで、時候の挨拶なんて、もはや、一般人は自分で書いたりせず、日本語変換エンジンに出力させている筈なのだが、今後は、徳島を活性化させたかった企業は、米国企業に、その役割も取られる事になるかもしれない今日この頃だ。
ちなみに、上記の様な理由から、少なくとも今現在のAIの進化形がシンギュラリティを迎える事はない筈なのだが、一昨日書いた様に、そんなAIをエージェントとして使え、という資本家からの圧力が強い訳だ。
その結果として、何をしでかすか分からない未熟なAIが、様々な操作を勝手にできる環境が構築されていく事になる。
これは何を意味するのか、というと、最悪、作者の銀行口座の預金残高が0にされる可能性なんかも出て来る。
何故なら、エージェントは作者の代わりに、少なくとも、コンピュータ操作は何でも出来る格好にされるので、勝手にAmazonから買い物をしたり、どこかのYouTuberに銀行預金の預金額の全てを投げ銭する可能性だって出てくるからだ。
だからといって、AI企業は、AIエージェントの行動によって発生した不利益には責任を持ちません、という利用契約に同意させる筈だ。
なので、銀行預金がなくなっても、作者は誰からも補償を受けられないので、そこで人生が詰む可能性もある。
と、言う事で、シンギュラリティなんてのは、今のAIからは発生する可能性はまずないのだが、AIがエージェント化される事を受け入れると、全財産がなくなる人は普通に出てくる筈の今日この頃だ。
何故、今日はこんな話になっているのか、というと、作者のメインマシンであるMacでも、10月から、Siri AIというのが導入される事になっている、という事に気がついたからだ。
そのSiri AIというのは、今のSiriとは違って、エージェント化されるので、メール操作だとか、インターネット操作もやる様になるらしい。
なので、その行動を許可すれば、作者の銀行預金もなくなるかなあ、と、思ったのでこんな記事にしてみた訳だ。
と、言う事で、海外の名門大学で利用が禁止されているAIも、日本の大学では利用を許可している事を鑑みれば、まず、被害を被るのは日本人、という事になる可能性もある。
その時、海外の名門大学に通っているグローバルエリートは日本人を助けようとするだろうか、と、考えるのは考えるだけ時間の無駄かもしれないので、自分の身は自分で守る必要が出てくる筈の今日この頃だ。
]]>つまり、主要コードは、基本的には、macOS版からUbuntu版にソースコードをコピーしてくれば動作するので、殆ど、作業は発生しない。
これに対して、メニューだとかダイアログだとかのGUIは、macOS版とUbuntu版ではOSのAPIが全く異なるので、同じ様な機能を実現するためのコードは、新たに、Ubuntu用にコーディングしなければならないからだ。
もっとも、より上位層になればなるほど、OSの違いは自前コードに吸収させているので、プログラム構造的には同じ感じだ。
なので、別に、気持ちの上では、特に大変という事はないのだが、それなりの時間は必要になる今日この頃だ。
ちなみに、巷では、マルチプラットフォーム対応用の開発環境なんかも色々とあって、そんな感じの環境を利用すれば、WindowsでもmacOSでもUbuntuでも動作するアプリを簡単に開発できる、という事になっている。
更に、最近は、AIがコーディングするので、開発者は、プロンプトに仕様を記述するだけでコーディング知識は不要、みたいな事を言っている人もいるが、そういう人は、Mirror-DTCをAIに開発させてみれば良い。
それが可能なら、作者的にも、AIにコーディング作業を任せるのだが、サラリーマン時代の作者的には、殆どの開発作業は自分でやっていた。
これは、部下がいなかったから、というよりも、部下にやらせるよりも自分でやった方が速かったからだ。
巷の若い人的には、部下を教育できない様な人は上司としては失格、と、言う筈なのだが、エンジニアの世界では、同じ設計を二度やる事は稀な訳だ。
なので、細かい設計について教育してみても意味はないので、教育するとすると、より一般的な話にならざるを得ないのだが、これは何を意味するのか、というと、一般常識に従って設計を行えるかどうかは、その人の力量による、という事になる。
中には、簡単にやれる人もいたのだが、大企業でも、そういう優秀な人の数は限られるので、そういう優秀な人は、別プロジェクトに回される事になる訳だ。
何故なら、プロジェクトに、そういう人が1人もいないと、そのプロジェクトは失敗するのだが、1人でもいれば、その人が何とかする可能性があるからだ。
しかし、その優秀な人にサイコパス属性がなければ、プロジェクトは失敗する可能性が高くなる。
何故なら、企業的には、一人でやれる作業量じゃないプロジェクトには部下を用意するのだが、その部下を教育するのも、その優秀な人の仕事にされるからだ。
つまり、優秀な人というのは、元々、優秀な部下がいたのかもしれないのだが、その手足をもがれ、自分一人になった苦しい状況で、力量のない部下を割り当てられ、その教育担当にされるので、自分が開発する事もできなくなる。
その結果として、プロジェクトは失敗する事になるので、それを阻止したい優秀な人は、新しい部下の面倒を見る事を放棄する事になる訳だ。
と、言う事で、世知辛い世の中になると、大企業ほど、優秀な人材や若手を潰す事になるので、今では、大企業ほどプロパーが開発する事を放棄している筈なのだが、下請けをしてくれていた関連企業も、今はなく・・・みたいになりつつある筈だ。
と、言う事で、もうコーディングできる人材もいないので、AIにやらせる、という感じかもしれないのだが、それが出来るのなら苦労しない、と、巷に残っている少数の優秀な人材的には、嘆いているかもしれない今日この頃だ。
なお、GUIのコーディングなんて、普通は、プログラミング初心者がやる作業になる。
何故なら、特にクリエイティブでもないし、手法は確立されているからだ。
しかしまあ、その手法を知らない人には出来ない作業になるし、クリエイティブではないとしても必要なコードではある。
なので、作者的には、老体に鞭打って、GUIのコーディングもやっている今日この頃なのだが、実際の所、プログラミング初心者はC++言語すら難しい、なんて言うらしいので、そういう人に教えてやらせるのよりは、何倍も楽かもしれない。
まあ、こんな事をIT企業で言っていたら、社会人失格、みたいに言う人もいる筈なのだが、実際の所、この程度の作業内容を誰かに習わなければ出来ない様では、その人にはプログラミングの適正はない。
なんて事を書いていたら、今の日本では、狂人扱いされるかもしれないのだが、米国や中国や欧州なんかでは、そんなのは当たり前の話だという事が信じられない日本人は増えているのかもしれない今日この頃だ。
]]>例えば、このブログのアクセス解析も、ちょくちょく、毎日のアクセス数が数百を超える様になっているのだが、多分、そのアクセスの殆どは、AIからのスキャンになる筈だ。
何故なら、読まれている記事が、網羅的で、何年も前の記事なんかにも順番にアクセスがあるので、そこまで熱心な人間はいないと考えられるからだ。
同様の話は他でも言われていて、GoogleのAIに「2026年現在、AIによるインターネットアクセスは全体の何%に達しているか」と、質問すると、以下の回答をしてきた。
2026年現在、「AIを搭載したシステム」を含む自動化されたトラフィック(ポッドトラフィック全体)で分類すると、すでに全体の57.4%〜61%に達しており、人間のアクセス(約40%)を抜いて過半数を占めています。
急増している背景
1.AIエージェントの爆発的普及: 従来のスクレイピング(データ収集)だけでなく、人間に代わってネット上を巡回し、情報を比較・購入する「自律型AIエージェント」が急増しています。人間が一つの製品を探すのに5サイトを訪れる間に、AIエージェントは数千サイトにバックグラウンドでアクセスするため、リクエスト数が非対称に膨れ上がっています。
2.学習データの枯渇 (2026年問題): 高品質なテキストデータをAIモデルが食べ尽くす「AIの2026年問題」に直面しており、最新かつ高度なデータを求めてAIクローラーがかつてない頻度でWebサイトを循環しています。
と、言うことで、2.はともかくとして、1.は大問題かもしれない。
何故なら、1.の様な用途で使われる様になった結果、一般ユーザー向けのAIにインターネットアクセスを行わせることになったので、AIが勝手にどこかのサイトをハッキングする様な事例が発生してきているからだ。
なので、例えば、米国の大陸間弾道弾発射システムのコンピュータがインターネットに接続された機器からアクセス可能だった場合、その脆弱性をついてAIがロシアや中国に向けて核ミサイルを発射する危険性が現実のものになっている。
だから、AIの開発企業の多くは、AIの利用を促進するのではなく、確実な制御ができるようになるまで、停滞させようとしてる今日この頃なのだが、米国の大統領や日本の首相は、そんなことなどお構いなしに、経済発展のためにAIを重用させようとしてきている。
と、言うことなので、数年の内には、人類が、また、滅亡する可能性も現実味を帯びてきている今日この頃なのだが、YouTubeを見ていると、日本のYouTuberの殆どは、新しいMac miniだとかMac StudioはAI用のマシンだ、みたいな動画ばかりを撮っている。
それが流行りで、視聴数が稼げるから、ということだとは思うのだが、GoogleのAIと作者の会話では、現状のアルゴリズムから抜本的な改変がない限り、結局、今のAIは、ありし日の、ATOKの域は超えない、ということで結論している。
つまり、AIというのは、人工知能ではなく、特定用途向けのユーティリティソフトでしかないので、人間よりも賢くなることはない。
まあ、電卓は人間よりも計算が速いので、同じ理屈を通すのであれば、1970年代に各家庭に普及した電卓は、既に人間を超えている、ということになる今日この頃ではあるのだが。
ちなみに、今日は、何故、こんな話になっているのか、というと、例によって、Linuxのシェアを確認しようとしてネット検索していると、以下の様な記事がヒットしたからだ。
最近のLinuxシェア増加の報道はAIが原因、実際のシェアは変化せず
つまり、最初に書いた様に、もう、普通のアクセス解析では、ブロガーなんかは自らのサイトを訪れているユーザーの人数は把握できないし、どんな記事が人気なのかも解析できない。
同じ話が、OSのシェア分析でも言えて、従来の方法では、人間が使用しているOSのシェアは把握できなくなった訳だ。
しかしまあ、それでも、Linuxのシェアは人間補正を入れても5%程度あり、macOSのシェアは30%近くになっているので、Windows離れが進んでいるのは間違いない今日この頃だ。
なので、作者的にも、macOS / Linux版ソフトを開発していても、10年前ほどの絶望感はない今日この頃なのだが、日本人の多くはIT音痴なので、米国ほどのシェアはないかもしれない。
しかしまあ、日本人はどんどん貧しくなっているし、米国とも喧嘩状態になってきているので、欧州よりに状況が変化すれば、LinuxがメインOSとなる日も遠からずやってくる可能性がある。
少なくとも、AIを入れれば、Linuxのシェアは16%にまで上昇してきている様なので、最早、無視すべきOSではなくなってきている筈の今日この頃だ。
]]>作者の場合、この真ん中の数字を上げる事はあまりないので、今回の更新は、結構、大規模な変更を伴っている、という事になる。
もっとも、macOS版については、クライアントとサーバーでは、使い勝手の向上用に幾つかの機能追加を行なっているのだが、大規模な変更なのか、というと、そうでもない。
トランスポーターについては、従来のMirror-DTCクライアントに加えて、Webブラウザをクライアントにできる様にしたので、それなりに大規模な変更と言えなくもないのだが、一般的に見れば、Mirror-DTC的には、トランスポーターは、脇役扱いになる筈だ。
なので、その脇役が大きく変わったとしても、Mirror-DTCのバージョン番号を大きく変えるのは可笑しい、と、言う声も聞こえてきそうなのだが、今回のバージョン番号は、Windows版の更新を見据えたものになっている。
具体的には、Windowsについては、既に、Windows10のサポートは終了しているので、動作対象OSは、基本的には、Windows11のみになるのだが、Windows11には、32Bit版は存在しない。
なので、Ver1.5.0からは、32Bit版を同梱するのをやめようか、と、考えている訳だ。
その代わり、ARM64版やmacOS / Ubuntu版を同梱する格好にしようか、と、考えているので、これは大規模な変更になる訳だ。
まあ、巷のWindows PCユーザーの殆どは、macOS版やUbuntu版を使う事はない筈なので、そんなモノを同梱して配布パッケージのサイズを大きくするな、という声も聞こえてきそうなのだが、今時のインターネット環境なら、例え、配布パッケージのサイズが100MBになったとしても、大したサイズにはならない筈だ。
これに対して、Windows PCだけではなく、Macも使っている人は、今のままだと、何回も配布パッケージのダウンロードが必要になる。
また、現状では、Vectorには、Windows版バイナリしか存在していないので、macOS / LinuxでMirror-DTCを使いたい人的には、作者サイトから、それら用のバイナリをダウンロードしなければならないので、面倒な筈だ。
と、いうか、Mirror-DTC的には、元々は、Windows用ソフトだったのだが、もう15年くらい前から、マルチプラットフォーム化を行なってきていて、それが、特徴の一つになっている。
なので、VectorからMirror-DTCの配布パッケージをダウンロードした人は、意識して作者サイトにアクセスしないと、Mirror-DTCがマルチプラットフォームソフトである事を知らないまま、Windows版だけを使い続ける事になる可能性もあるのが勿体無い話になる。
と、言うことなので、今回、Mirror-DTCのバージョンを大きく上げるのは、マルチプラットフォームでの利用を促進するために、全OS版を一つの配布パッケージに入れる事にしているからなので、個別ソフトの更新自体にインパクトがある必要はない。
しかしまあ、Mirror-DTCは、多くのPC/Macを色々と使っている作者的には、既に、必須のソフトになっているので、この際、少し使い勝手も上げておこうか、という感じになるのも、普通の話ではある筈だ。
ちなみに、同じ話はAmuseGraphicsにも言えるので、既に開発してきているAGMPlayerなんかのAmuseGraphics関連ソフトのバージョンもVer1.5.0に上げている。
つまり、Windows版のAmuseGraphicsについても、全OS向けバイナリを同梱化しようと考えているのだが、Vectorの規約で、それが可能なのかどうかは知らない。
なので、先ずは、Mirror-DTCのマルチプラットフォーム版をVectorのWindows向けソフトとしてリリースしてみて、Vectorへの登録が拒否されたら、別の方法を考える事になるかもしれない。
全バイナリを同梱化する目的は、巷のWindowsユーザーに、Windows離れを促す、という事もあるのだが、近い将来、作者のダウンロードサイトを閉鎖する事になる筈なので、その時に、ホームページ上だけにアップしてあるバイナリがあると、折角開発したソフトが、その時点で終了してしまう事になるのを避けたい、という事もある訳だ。
つまり、全てのバイナリをVectorにアップしておきたいのだが、Vectorのライブラリは、WindowsとMacに分かれている事を鑑みれば、Ubuntu版ソフトをWindows用のライブラリにアップするというのは、普通に考えると、拒否されてもおかしくはない。
まあ、それらはオマケ扱いになるので、問題はないかもしれないのだが、Vector的には、それらのソフトの動作確認はできないだろうし、ウイルスチェッカーの対象外になるので、扱えない、という可能性もある。
と、言うことなので、どうなるかは分からないのだが、もし、Vectorにアップできなかった場合には、Vectorには従来通りWindows版のみ、作者サイトには、全OS版入りのパッケージを用意し、その全OS入りのパッケージは、内容を変更しなければ再配布可能、という、大昔のフリーソフトみなしの扱いにしておく事で、作者サイトが閉鎖された後にも、流通される様にしておく事にするかもしれない今日この頃だ。
]]>