PHP をインストールしたら Apache2 も付いてきた😅

Python3 は標準でインストールされているけれど PHP は Ubuntu 24.04 に標準では入っていなかったのでインストールしました。特に PHP のバージョンに拘りがないことから指定なしで
sudo apt install php
としたところ、インストールされたのは PHP 8.3 でした。
コンソール画面を見ていると PHP だけでなく Apache2 もインストールされた模様。
セット物なのか理由は分かりませんが、まぁ Httpd も使う場面もあるだろうから良しとしましょう。

とりあえず自動起動を無効にする

http://127.0.0.1/ を叩くと Apache2 さんコンニチハ！！って、即時に起動している様子。使いたいときだけ起動すればいいので自動起動の変更を施しました。
systemctl のコマンドで設定の方法で行いました。

自動起動の有効化
sudo systemctl enable サービス名
自動起動の無効化
sudo systemctl disable サービス名
自動起動の確認
sudo systemctl is-enabled サービス名

Apache2 のサービス名は、私の Ubuntu 環境では "apache2" ですが、他の Linux 環境では "httpd" というサービス名となっていたりと環境によっては異なるようです。

とりあえず自動起動はしないように出来たので使いたいときに手動で開始／停止
サービスの開始
sudo systemctl start サービス名
サービスの停止
sudo systemctl stop サービス名

AH00558 エラー？ の対処

Apache2 を自動起動にしていると見えないので分かりませんが、コマンドで開始／停止としていると何やら妙なメッセージを見かけました。

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

なんだか分からないので検索してみると
127.0.0.1 は localhost という名前で bind されているけれど
127.0.1.1 に割り当てている名前が未解決なのでこの問題が発生するそうです。

・・・なにも設定してないのですが😅😅😅

どうやら Ubuntu へのインストール時に、127.0.0.1 に加えて、127.0.1.1 で Ubuntu のサーバー名でエントリーが自動で作成されることに起因しているとのこと。

対処としてはローカルの hosts ファイルに追記で 127.0.1.1 のエントリーを設けるとかでもいいそうです。

私の場合は Apache2 の conf への追加で対処しました。
sudo sh -c "echo ServerName $HOSTNAME > /etc/apache2/conf-available/fqdn.conf"
sudo a2enconf fqdn
systemctl reload apache2
systemctl start apache2

Apache2のconfのテストで正しいかどうか分かります
sudo apache2ctl configtest

Syntax OK
と出ていれば大丈夫

これって、ちょとしたライフハックらしく
sudo echo ServerName $HOSTNAME > /etc/apache2/conf-available/fqdn.conf
bash: /etc/apache2/conf-available/fqdn.conf: 許可がありません

普通に bash に渡すとリダイレクトの部分が通常の権限になるので
sudo で起動した sh に -c でやらせて書き込むという小技

足りないモジュールを追加でインストール

libapache2-mod-php はセットで入っていました。

追加したのは（入っていなかったのは）

●php-curl（HTTP通信）
sudo apt install php-curl

●php-mbstring（マルチバイト文字対応）
sudo apt install php-mbstring

これ以外にも必要なモジュールがありそうだけど、とりあえずはこれだけでいいかな。

Ubuntu 24.04 でアプリを初めてビルドした

Linux環境に乗り換えてから特に不都合もなくビルド済みのアプリを利用することで事足りているのですが、オープンソースの世界だから、やっぱり自前でソースコードからいつかはビルドする場面が来るだろうと思っていました。そんな折、必要に迫られるような状況ではないけれど、ふとしたきっかけでどうやってビルドするのだろう？ と、必要なツールなどを見てみたところ、GCC とか make など殆どが最初から Ubuntu 環境には入っているようなので少し整備するだけでビルドができそうに感じられたので思い立って、やってみることにしました。

ビルド対象は、とあるネトゲ(？)のクライアント

ネトゲのクライアントをビルドというのは不思議に思うところかもしれませんが、オープンソースで提供されているタイトルの1つの 「Second Life」 のビルドにチャレンジなのです。

secondlife.com

この Second Life のクライアントソフト(ビュワーと呼ばれます)は、公式サイトが提供するものや、オープンソース故に改変したものなど色々と公開されています。そんな中、Linux 向けのクライアントソフトは現在は公式からの提供はなく、第三者が制作した物のみとなっています。いくつか Linux 対応がある中で、私がビルド対象としたのは 「Cool VL Viewer」 です。

sldev.free.fr

Cool VL Viewer のLinux版ビルドに必要な環境

The tools required to build the viewer are:
 - gcc/g++ v8.1 or newer (1), or clang/clang++ v7.0 or newer (2), that is a
   full-fledged C17/C++17 compiler.
 - binutils (as, ld & Co) and optionally elfutils (for eu-strip)
 - make
 - cmake (v3.10 or newer); v3.16+ recommended for a much faster compilation.
 - python (v3.3 or newer)
 - tar, bzip2 and gzip
 - bash
 - grep (for the linux-build.sh script)
 - coreutils (for the linux-build.sh script)

You will also need:
 - The headers and shared libraries for glibc v2.28 or newer.
 - The headers and shared libraries for libstdc++ v6.0.25 or newer.
 - The headers and libraries for X11, Xrender, Xinerama, OpenGL, Mesa (GL/GLU).
 - A working connection to Internet for the automatic retrieval of the
   pre-built libraries (note that once those libraries are cached on your
   build system (3), the connection is no more necessary).

なんだか色々と必要そうだけど、よく見ると Ubuntu に最初から入っていそうなものもチラホラと伺えるのが、もしかしなくても簡単に出来そうだと感じたのです。

既にインストールされていたもの (Ubuntu 24.04 LTS + Xfce)

gcc --version                      // 13.3.0
ldd --version                      // (Ubuntu GLIBC 2.39-0ubuntu8.4) 2.39
apt list|grep binutils|grep イン   // 2.42-4
make --version                     // GNU Make 4.3
python3 --version                  // 3.12.3
bash --version                     // GNU bash 5.2.21
grep --version                     // GNU grep 3.11
apt list|grep coreutils|grep イン  // 9.4.3
apt list|grep libstdc|grep イン    // 13.3.0 (dev も入っていた)

無かったので追加したもの

# Cmake
sudo apt install cmake

# X11 libraries
sudo apt install libx11-dev

# libxrender libraries
sudo apt install libxrender-dev

# libxinerama
sudo apt install libxinerama-dev

# opengl
sudo apt install libopengl-dev

# mesa
sudo apt install mesa-common-dev

そしてビルドしてみたら・・・

なにも変更していないのにエラーというか Warning で止まってしまいました。😅😅😅
調べてみたところ、どうも GCC の v11 以降では、おせっかいな、ここって変じゃない？みたいな解析をする機能があるらしく、それに引っかかる箇所があるみたいだと理解しました。

Warning を無視するオプションを付けて再度ビルドで難なく完了。

最後での LINK のところでも Warning が出ていたけれど、大丈夫なのでしょう。

統合開発環境の導入はしていない

まずは自分の PC でビルドできる環境を得るところまで来ました。
Windows を使っていたときのように統合開発環境(IDE)としたいところですが、なにが良いのやらさっぱり分かりません。 Windows 環境では Microsoft の Visual なんたらな環境で、楽々でしたね。まぁ、そのへんは、おいおいやっていきたいです。

とりあえず、IDEは無くて手打ちのコマンドラインでのビルドですが、そのまま同じバイナリとはならないように、ちょっとばかり変更しています。

GCC v8系 → v13系
コンパイルで
SSE2指定 → SSE4.1指定

としたころ、元の公開アプリでは付いていたオプションの一部がなくなっていました。
単に GCC のバージョンが違うからなのかな？　まだまだ分からない事だらけです。

なくなったオプションは
-fsched-pressure -frename-registers -fweb -fira-hoist-pressure
この４つです。
バージョンは違うけれど GNU のサイトで解説を見ることができました。

gcc.gnu.org

-fsched-pressure
    Enable register pressure sensitive insn scheduling before register allocation. This only makes sense when scheduling before register allocation is enabled, i.e. with -fschedule-insns or at -O2 or higher. Usage of this option can improve the generated code and decrease its size by preventing register pressure increase above the number of available hard registers and subsequent spills in register allocation.

-frename-registers

    Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization most benefits processors with lots of registers. Depending on the debug information format adopted by the target, however, it can make debugging impossible, since variables no longer stay in a “home register”.
    Enabled by default with -funroll-loops.

-fweb

    Constructs webs as commonly used for register allocation purposes and assign each web individual pseudo register. This allows the register allocation pass to operate on pseudos directly, but also strengthens several other optimization passes, such as CSE, loop optimizer and trivial dead code remover. It can, however, make debugging impossible, since variables no longer stay in a “home register”.
    Enabled by default with -funroll-loops.

-fira-hoist-pressure

    Use IRA to evaluate register pressure in the code hoisting pass for decisions to hoist expressions. This option usually results in smaller code, but it can slow the compiler down.
    This option is enabled at level -Os for all targets.

ただリビルドしただけで効果は感じられました

なんとなくだけど描画のキレが良くなった気がします。やや間が空く感じでモッサリした描画だったのがすっきりくっきりってところでしょうか。気の所為レベルかもしれません。状況によっては改悪となっているかも・・・。描画が速いに越したことはないけれど、まずは正しく動作しないと意味がないので使い続けて問題が出ないことを祈るばかりです。

Linux の Nvidia ドライバーは複数ある (535, 550, 570)

グラフィックボードの入れ替えでNvidiaのドライバーも入れ替えようとしたら何故だか入れ替え対象の選択肢が複数あって (当記事時点では 535, 550, 570) どれがいいんだろう？ と、悩むことに・・・😅 普通に考えると日付の新しいものが最新という位置づけだと判断しますが、何故だか Linux のドライバーに関しては何れも (535, 550, 570) 同じ日付のリリースとなっています。その違いは何だろう？と探してみたものの明確な結論には至りませんでした。そんな異なるバージョン番号同時リリースの怪異と Linux 環境でのコアな部分のドライバーの入れ替えという点で書き留めておけば参考になったりするのかなと自身の日記ですがBlogネタにしておこうと思いました。

GTX 600番台から 900番台へ乗せ換え

ウチのこのPCの環境は、元が Windows XP (32) で、デュアルBOOTで Ubuntu 24.04 と同居しています。今では殆ど Linux 環境しか使わないのですが Win XP も時折使っています。そんな状況なので今どきに GTX で、しかも３桁番号を選択するなんてありえない（性能の面でもコストの面でも） のですが、 Windows XP (32/64) で使うことのできるグラフィックボードは 900番台までなのです。改造したドライバーで GTX での４桁番号台を XP で稼働させることはできるらしいのですが 3D 機能は全く使えないとのこと。なお 900番台であっても公式のドライバーでは Windows XP 環境で GTX 960までしか対応しないことになっていますが設定用のファイルを書き換えることで 970, 980, 980 TI等の上位モデルも問題なく動作するというのは広く知れ渡っています。

GTX 900番台での選択

900番台での選択となると最上位の 980, 980 TI もしくは同系列の Quadro M6000 (メモリー 12Gbyte)　が性能面では最高ですが、消費電力も大きく
980無印 → TDP 165W
980 TI   → TDP 250W
M6000  → TDP 250W
今どきの(RTXの)ハイエンドモデルと比較すると大したことに感じない電力量ですが、それでも私からすると電力大食いと感じてしまうので何れも乗せ換え先としては対象外。何れも TDPで示す値は GPU 単体での数値なので付随するメモリーや冷却ファンの電力量も加味するともっと電力が必要です。

そうなると900番台での選択肢は 950, 960, 970 の何れか。930に関しては元の600番台のグラボより性能面で劣るので930は対象外。

GTX 960を選択

950, 960, 970 の3つに絞ったところで下位の950がコストパフォーマンス的には魅力ですが、それは販売当時の新品であったときのお話。現時点では「中古」として入手するしか手段はなく価格差も殆どありません。そうなると現状の600番台のグラフィックカードとシェイダー数などがほぼ同じとなってしまう 950 を選ぶ理由はなく、960 もしくは 970 の２択です。

リリース当時の価格的な差は970と960で日本円で \20,000ほどあったりします。
上位モデルはいつの時代でも高級品ですね😅

性能面でもちょっとどころではない差があり中古でほぼ同じ値段で入手できるなら970を選ぶのが最善でしょう。

最低限が GTX 970 というのは、FF14 の動作環境で必須とされているところでもあります。

jp.finalfantasyxiv.com
まあ今時はそんな環境が最低要件なんだなぁと感じつつ、それでも選択したのは GTX 960 です。
選択した理由は TDP の違いですね。
GTX 960 (GM206) → 120W
GTX 970 (GM204) → 148W

僅かしか必要電力が違わないじゃないかと感じるでしょうが、私は30W近く違うというのが認めたくないと思うところ。というのも消費電力が半分になる！と蛍光灯からLED照明に交換した近年なので、せっかく電力を抑えたのにPCでまたまた必要電力量を増やしてしまうのは考えものでした。30Wもあれば室内のLED照明もお釣りが来る電力です。室内照明と違って常時に全力でGPUが稼働するのではないので同じではないですが、少しでも電力を抑えたいとの考えで、性能差よりも電力差で GTX 960 を選択となりました。

そもそも何でグラボを乗せ換え？しかも中古で今どき・・・

このPCの構成は、
マザーボード = 中古
CPU = 中古
メモリー = 中古
電源 = 新品
グラボ = 新品
ストレージ(SSD / HDD) = 新品
ディスプレイ = 新品
キーボード = 中古
マウス = 新品
と、まぁ経年で消耗が激しい部分は新品で故障があったら交換するってスタイルです。グラボもずっと昔には一度だけ中古を買ったことはあります。グラボは以前から Nvidia の信者で、さすがに NV1 は持っていませんが Riva の時代から使っています。ほんとうに一度だけ、型番の末尾の数字が "8" の高性能なカードを使ってみたくて、中古で購入したことがあります。そして高性能なグラフィクボードを購入しても、すぐに新しい世代の製品が発表されて性能的には追いつかれてしまうので高価な高性能カードを購入するよりも、そこそこの性能の最新のモデルを買ったほうがコストもかからずに良いのではと思うようになって、それっきりですね "8" 番台は。そうこうして月日が経ち、ゲームを全くしなくなって GTX 600番台に乗せ換えたのを最後に今日まで普通に使っていました。まったくゲームをしないこともなくて（ゲームなのかな？）https://secondlife.com/ というアバターチャット（というのが近い）を今もやっています。

故障があったら該当部分を交換して使い続けるスタイルのなので、ゲームもしなくなったことからグラフィックボードは故障することもなく性能差が大きくなりすぎたときに交換するってところで、それが近年で顕著化したことからグラボの交換となりました。

先述の Second Life での使用でもGPUの非力さを感じるところはありましたが、それが主な要因ではなく主因は "HEVCのハードウェア対応" の必要性です。600番台のグラボでは HEVC (H.265) のハードウェア支援機能が無く、HEVCでの動画の再生はできるのですが、その都度 CPUで頑張るしかないので色々と具合が悪い状況を打破したいとの狙いです。また、Nvidia で現状での公式サポートは 700番台以降からとなっており、もはや600番台は論外という状況もグラボ乗せ換えの必要性を感じたのでした。トドメとして先述の Second Life で 「物理レンダリングモデル」 が導入されたので、もう600番台のグラボでは描画が止まってしまうことがしばしばです。

そこでグラボ交換しかないと思い立ったら吉日の性分なので現在の流行りをみてみたのですが、なんですか RTX ですか、レイトレーシング？ ふ～ん。という感じで新しいものに食指が伸びるものの Windows XP(32) 環境を抱えるので 900番台の中での選択となるので当然に中古でしか入手できないのでした。将来的に全く XP(32)環境を使わなくなったら、VESA標準ドライバのみで 3D は捨てて Linux 環境の方にのみ 3D がある状態にするでしょうね。

グラボを入れ替えて設定 (Windows XP32側)

もはやサポートされないOSだけど、Windowsなんちゃらセンターに接続しますか？ な、いつもの新しいハードウェアを検出しましたイベントで全てキャンセルしてドライバーの入れ直し。どうせ同じドライバーを入れるのだから自動で設定変更しないものかなと思いつつ通過儀礼のドライバーインストールは難なく完了。

グラボを入れ替えて設定 (Ubuntu 24.04側)

最悪はGUIでのBOOTが出来なかったらどうしようと懸念があったので、とりあえずPCが使えるようにと先に Windows XP 側から設定したので少しの安心と緊張しながら Ubuntu を起動。ところが何も変化がなかったように普通に起動してしまいました。🙃🙃🙃

どうも以前600番台で使っていたNvidia ドライバーでも 900番台 はそのまま動作するらしい？

ちなみに 600番台 (Kepler) までの Linux のドライバーは 470.xxx.xxx のバージョンのものになるらしく、それ以前の 各シリーズ毎での対応があるみたいです。
ちょっと古い記事でしたが纏まっている投稿がみあたらなかったので、下記より転記。

forums.developer.nvidia.com

複数の異なるドライバーバージョンが同時リリース

Nvidia の公式サイトで見られるドライバーは 535, 550, 570 とも同時リリース

グラボを変えてから Ubuntu の更新アプリでも 535, 550 が表示されるようになりました。
以前の 600番台のグラボでは 470 のみ表示されていました。

なんで複数のバージョンがあるの？

記事の冒頭でも述べましたが、確実な理由は分かりませんでした。
しかし理由の１つに対応する CUDA のバージョンの違いがあげられるようです。

docs.nvidia.com

Nvidia の公式ドライバーは・・・

なにかと自己責任でと免罪符のように言われますが Nvidia の公式ドライバーを使用して GPU が破損するトラブルもあるらしいです。

www.nichepcgamer.com
主に Windows 向けのドライバーでの不具合が多いですが Linux 向けドライバーでも例外ではありません。トラブルに遭わないように Nvidia からの公式ドライバーを直接に利用するのではなく、 Linux の各種ディストロの配布元で確認の取れている（パッケージとしてリストされている）ものを使うのが最善です、壊れてからではどうしようもありません・・・。けれども Ubuntu のようにオープンソースでないドライバー類も積極的に採用しているものでない限りは各自の選択で Nvidia のドライバーを入れることになるでしょう。何かと新しいものにはご注意を。

結局(いまのところ)元の 470.xxx.xxxなドライバーを使っています

550系を入れてはみたものの、どう設定しても　2D 描画での文字のフォーカスが甘い感じがして落ち着かないので元の470.256.02を使っています。たぶん個体差とかなんか環境の違いだと思うのですがフォーカスが甘いドライバーが出るのは昔から Nvidia あるあるな事象だと思います🤣🤣

【追記：2025-05-07】
その後に570系のドライバーにしてみたところ気になっていたフォーカスも問題がなさそうに感じたので470系→570系へと入れ替えました。

ゴミ箱に移動が出来ないのはドライブの所有権の違いでした

ふと削除したファイルをもう一度閲覧しようと"ゴミ箱"を開いてみたら１つも削除ファイルは見当たりませんでした。そういえば最近に削除するときになんかメッセージが出てたなぁと。Ubuntu だとドライブ毎に作成されるゴミ箱フォルダの名前は ".Trash-1000" なのですが、それが作成されているドライブと全く存在しないドライブ、存在するけれどゴミ箱として使えないものの３種ありました。

ゴミ箱のアクセス権はドライブの所有権と等しくなるっぽい

ゴミ箱が使えない原因を調べていくうちに、どうやら ".Tash-1000" のフォルダーのアクセス権(Read/Write) が無いのでゴミ箱フォルダーに移動できない状態というのが分かり、ゴミ箱に入れることが出来るドライブは、".Tash-1000" の所有権、アクセス権ともログイン中のユーザー名と等しく、ゴミ箱に入れることが出来ないドライブは、所有権、アクセス権とも root となっていました。

XFce の ファスルマネージャ Thunar でも同様の「ゴミ箱に入らない」メッセージが出ます

アクセス権と所有権を変えれば使えるようになるのかな？

とりあえずターミナルからコマンドで ".Trash-1000" の所有権とアクセス権の変更を試みるも効かないみたいで、じゃあ削除したらどうなるのかとフォルダーごと削除しても再作成されず、それなら手打ちでフォルダーを作成したらと、手動で同名のフォルダー名を作成するも所有者、アクセス権とも root となってしまい変化なしでした。

どこが違うのかゴミ箱が機能する／しないドライブの違いを観察

そういえば Ubuntu をインストールした初期だと普通にゴミ箱は使えていたよねって思い起こして、その後に弄ったところから得たヒントは。

・ゴミ箱が使えるドライブ
　→　ログイン後に media 配下に追加でマウントしているドライブ
・ゴミ箱が使えないドライブ
　→　システム起動時に自動で mnt 配下にマウントしているドライブ

という違いがあり、マウント先の違いもあるけれど、ドライブそのものの所有権が root になっているからダメだった様子。
ちなみに私のUbuntu-PC環境でゴミ箱問題が発生したのは NTFS でのパーティションのものです。他のファイルシステム形式でも同様にゴミ箱問題が発生するのかは分かりません。

起動時の自動マウントでも所有権 = ユーザーとなるように書き換え

マウント時のオプションで
uid=ユーザー名,gid=ユーザー名
というパラメーターを追加してドライブそのものの所有権をログインユーサーにすることでシステム起動時でのマウントでも ".Trash-1000" のアクセスが可能になりました。

他のログインユーザー ID で入ったら同様にゴミ箱アクセスが出来ないじゃんwww
というのが目に見えるのですが、とりあえず一人で使う分にはいいかと。
けっこうマウントポイント指定でバッチを書いていたりするので今更変更するのも面倒くさいなぁというのが大きいですね。
たぶん Ubuntu 的には 追加のドライブは media として毎回にログイン後にマウントして使うのが正しいような気がします。

Flatpak で Tuner をインストール

いままでインターネット・ラジオの視聴には snap 版の shortwave を使っていたのですが先日のアップデートで何故だかステーションのアイコンが表示されない、ステーションの一覧上で表示順の指定が効かないダークモードにも出来ないという不具合(私だけかな？)に遭遇したので別のアプリにしようかとアプリケーションセンターで物色したものの思わしいアプリがない。調べていくうちに、このラジオ一覧はアプリ固有のものではなくて RadioBrowser という共通の一覧から取得しているらしく linux 他のプラットフォームで採用しているアプリがたくさん掲載されていました。(linuxでのお薦めは Flatpak 版の shortwave でした) snap 版 → Flatpak 版 の shortwave にして不具合が解消するかもと考えたけど、どうせなら違うアプリにしようかと 軽量そうな Tuner を選択。

flathub.org

まずは Flatpak をインストール

インストールは公式ページの手順通りに行いました。

flatpak.org

そして Tuner を Flatpak でインストール

コマンドラインでは Flatpack じゃなくて Flatpak なんですね😅😅

で、こちらでも mesa ライブラリ？ が関連でインストールすることになってる様子。
やたらとサイズが大きい😅

snap 版の方の mesa ライブラリーをアンインストール

Shortwave のアップデートと同時にインストールされたので、他には誰も使ってないんじゃないかと sudo apt autoremove としてみたけれど、なにも削除されず。
仕方ないのでアプリケーションセンターから　「アンインストール」指示で削除しました。
その後に再起動しても特に問題なく、また、sodo apt update としても追加はされなかったので今のところイラナイみたいで大丈夫😅

Flatpak は素晴らしくいい感じ

公開されているアプリの数と種類がとても多く、Ubuntu に初期から入っている アプリセンターで探すよりもずっといい感じです。特にゲームもたくさんあるある

flathub.org

JDownloader2へのFFmpegの組込み

Windows環境でお世話になっていた "JDownloader 2" が、そのまま Linux 環境でもサポートされていて全く同じように使えるのですが、今回、ストリーミング形式のリソースを対象として動作させようとしたところ "FFmpegがインストールされていない" というメッセージが出て、そう言えば別途に必要だったなぁと思い起こし、ちょっとばかし弄ることに。ところが、そう簡単には行かなかったのでした。

どれをインストールしていいか分からないFFmpeg

本体のアプリである JDownloader2 は、アプリセンターのツールからインストールしていたので同様にアプリセンターのツールから FFmpeg で検索してみると何やら似た名称のものがたくさん・・・。どれがいいんだろうと思いつつ、一番最初に出ている得票数の多い無印な FFmpeg を選択。そして JDownloader2 起動で、変化はあるかと見てみたけれど相変わらずエラーになる。調べてみると、先の画像で示した拡張設定の部分で FFmpeg の収容先を指定する必要があるらしい。(赤枠の部分)

ところが path を設定しようとすると、どうやっても指定先を認識してくれない状態で snap 版だから path が違うのも加味したけれど変化なし。

結局は、snap 版ではなく apt 版を使うことで解決

先のFFmpeg のインストールで snap 版ではなく apt 版を使うことでローカルな派生ビルドに迷うこともなくオリジナルのものがインストールできると分かったので、同様に本体の JDownloader2 も snap 版ではなく オリジナル版を使うことで解決できるというネタを見つけて、あっさり解決。

snap版(左)とオリジナル版(右)の違いは、JAVAの環境の違いとインストール先の違いだけのようで、それ以外は全く同じでした。JAVA違いとインストール先の違いがあるので同時に起動してスクリーンショットを撮っています。(この後で snap 版は削除しました)

なお、オリジナル版の JDownloader2 では、インストール直後の初期状態で path が自動設定されていました。

もしかしたらインストールする順番で変わるのかも？

この記事を書いていて、ふと思ったのですが、今回、オリジナル版の JDownloader2 をインストールする前に FFmpeg のインストールをしていることと、snap版をインストールしたときでは そのときは FFmpeg は無かったかも知れないので、もしかしたら snap版でも先に FFmpeg を導入できていたら自動で検出したのかも知れないと思うところはあります。でも、そーいう検証が目的ではないので、ちゃんと動作してくれれば Okay だから、 snap 版がダメダメということではなく、私の場合はこうだった～という結果に過ぎません。

一応、手順としては
1.FFmpeg を apt からインストール
 sudo apt-get install ffmpeg
2.JDownloader2のWEBサイトから Linux 版のインストーラーをダウンロード
3.JDownloader2のインストーラーを起動(.shのスクリプト)

( 必要なら snap 版の JDownloader2 は、アプリセンターの管理メニューからアンインストールするか、コマンド操作でアンインストール sudo snap remove jdownloader2 )

でも、他にも不具合じゃないけどアプリセンターからインストールできるものって、最新ではないものも少なくないので絶対ではないということに気をつけたいですね。選択が可能でどちらも同じであるなら snap 版を私は使いたいです。いや、単にアプリケーションの収容先が /snap 配下で綺麗に纏まるからってだけですが・・・

RTC のタイムゾーンは UTC か Local かどっちがいいの？

ウチの Linux な PC は、Windows とのデュアルブート仕様なので、時折に起動した直後に時間が −９時間 となることがあり不思議に思っていたのですが、どうやらその原因は RTC の時刻をそのまま使っている Windows XP(32) と RTC の時刻は UTC としてローカル時間(JST)に調整してから表示する Linux との動作の違いのようでした。

基本は RTC = UTC っぽい

時刻関連で RTC 絡みの項目を検索してみると
"/etc/default/rcS" の内容を確認　とか grub のオプションに追記　など出てくるのだけれど、そんなものは無いので詳しく見てみると、それは古い仕組みで現在は timedatectl が担っているとのこと。

そういえば時刻合わせのときに触った気がしますね。

とりあえず現在の設定を見てみると
"RTC in local TZ : no" と なっていて、確かに RTC = UTC の設定でした。

RTC = Local に設定すると警告が！

ちょいちょいと設定を変えればいいだろうと
timedatectl set-local-rtc 1 --adjust-system-clock
RTC = ローカル時間に設定変更すると

なにやら長い文字列で Warning が・・・。
どうも RTC = ローカル時刻指定 だと、動作保証しないよ～、夏時間とか計算されないよ～、色々とマズイから RTC = UTC の設定をオススメするよ～　というような文面

🤔少し考えたけれど、今は Linux 環境をメインで使っているから
RTC = UTC の設定のほうがいいかなーって思って
元に戻しました🙂🙂🙂