コグノスケ

企業のドメイン

今の企業は公式サイトを持っていなほうが珍しいと思いますが、ドメイン名の使い方は各社でバラバラで面白いです。特にグローバル企業は日本だけでなく世界各国向けに公式サイトを構築する必要があるため、迂闊に「会社名.co.jp」みたいなドメインを使うと海外展開時に困ってしまいます。

解決方法はいくつかパターンがあるみたいです。

• gTLD（.com）ドメイン
• gTLD（.com）ドメイン＆ドメイン先頭（www部分）が地域名
• ccTLD（汎用JPなど）ドメイン
• 日本だけ属性型JP（.co.jp）ドメイン、他国はccTLD（汎用JPなど）ドメイン
• 企業名ドメイン

一番良く見かけるタイプでオーソドックスな解決方法だと思われます。gTLD（generic Top Level Domain）である.comドメインのあとに地域名や国名を表すパスが続きます。ドメインを増やすことなく各国地域対応が可能で、スマートですね。

• アイシン: https://www.aisin.com/jp/, https://www.aisin.com/en/
• デンソー: https://www.denso.com/jp/ja/, https://www.denso.com/fr/fr/
• 電通: https://www.dentsu.com/jp/jp, https://www.dentsu.com/fr/fr
• 三菱商事: https://www.mitsubishicorp.com/jp/ja/index.html, https://www.mitsubishicorp.com/fr/en/
• Panasonic: https://www.panasonic.com/jp/about.html, https://www.panasonic.com/fr/
• PlayStation: https://www.playstation.com/ja-jp/, https://www.playstation.com/fr-fr/
• 住友商事: https://www.sumitomocorp.com/ja/global/, https://www.sumitomocorp.com/zhcn/easia/

亜流としてNECのように、.comドメイン＆ドメイン先頭（www部分）が地域名になる会社もありました。.comドメインだけどパス名の代わりにドメインの先頭を使うんですね。これはこれでスマートです。

• NEC: https://www.nec.com/, https://jpn.nec.com/, https://fr.nec.com/

もう一つはccTLD（country code Top Level Domain、つまり汎用JPドメインなど）を使う会社です。一貫性がありますね。

• トヨタ: https://toyota.jp/, https://www.toyota.fr/

亜流として日本だけ属性JPドメイン（.co.jp）、他国はccTLDドメインを使う会社もあります。日本だけ違うのは過去の互換性のためでしょうか？

• ホンダ: https://www.honda.co.jp/, https://www.honda.fr/
• 日産: https://www.nissan.co.jp/, https://www.nissan.fr/
• ソニー: https://www.sony.co.jp/, https://www.sony.fr/

珍しいパターンとしては企業名ドメインもありました。このタイプのドメインの名称が良くわからないんですが、企業名がトップレベルドメインになっています。でも他国向けはccTLDでした。謎の作りですね。

• SHARP: https://global.sharp/, https://jp.sharp/, https://www.sharp.fr/
• 東芝: https://www.global.toshiba/jp/top.html, https://www.toshiba.fr/pages/fr/

日本だけ特別扱い系の謎

日産やホンダは.co.jpを使っていますが、.jpはアドレス解決ができないところから使っていないように見えます。.jpドメインはどうなっているんでしょうか？Whois情報を見ると、

$ whois nissan.jp

Domain Information: [ドメイン情報]
[Domain Name]                   NISSAN.JP

[登録者名]                      日産自動車株式会社
[Registrant]                    Nissan Motor Co., Ltd.

[Name Server]
[Signing Key]

[登録年月日]                    2001/03/26
[有効期限]                      2025/03/31
[状態]                          Active
[ロック状態]                    DomainTransferLocked
[ロック状態]                    AgentChangeLocked
[最終更新]                      2024/08/06 16:25:46 (JST)

見慣れない"DomainTransferLocked"と"AgentChangeLocked"が設定されています。これはドメイン名移転申請ロック、指定事業者変更ロックのことだそうでJPRSのサイト（指定事業者変更ロック - JPドメイン名のルール - JPドメイン名について - JPRS）に解説があります。

企業と関係のない登録者に勝手に使われないように申請を弾いてくれる仕組みですね。こんな機能があるとは知らなかったです、なるほど便利だ。

shapezレベル100達成

目次: ゲーム

書くの忘れてました。放置してたshapezを夏ごろにレベル100まで進めました。レベル27から納品物がランダムになるので「何でも作れる機構」を構築しないとレベル100達成はしんどいです。

実績は41/45まで取りました。取り逃しは、取る気が元々ないスピードラン系3つ＋操作ミスで取り逃した「King of Inefficiency」です。

shapezの実績

レベル100程度ならさほど納品速度は要求されませんが、高レベルになると作成したShapeを納品する場所（ハブ）に超高速で納品しなければならないです。何でも作れる機構＋倉庫に大量のShapeをためて、たまったら一気に流し込む機構が必要です。

レベル100までやってみた感想ですけど、総合的には面白かったです。効率的な機構を考え付いたときが爽快です。個人的な面白さのピークは「何でも作れる機構」を作りレベル30くらいを突破する辺りでした。そのあとはコピペ感が強くなってやや盛り下がるのはシステム上仕方ないですね。

近々shapez2がリリースされる（今はearly access版）みたいですが、さらに複雑になっているようで買うかどうか微妙です。やると疲れるんで……息抜きには向いてないです。

メモ: 技術系の話はFacebookから転記しておくことにした。

Microsoft Office 2024を購入

Microsoft Office 2016のまま8年間ほったらかしにしてきましたが、ついにMicrosoft Office 2024に買い替えました。Amazonで31,000円くらいでした。うーん、高い。Office 2024もきっと8年くらい使うでしょう。買い替えるモチベーションがほとんどないし……。

買い替えのきっかけはOffice 2024 Homeです。今年からMicrosoftが改心してOffice 2024 Home（かつてのPersonal相当と思われる）からOutlookを消してPowerPointを入れてくれました。私が欲しいのはPowerPointとExcel（Wordはあってもなくても良い）だったので、これはありがたい変更でした。

• 2021 Personal: Word, Excel, Outlook
• 2024 Home: Word, Excel, PowerPoint, OneNote

従来のOffice 2021はPowerPointとExcelが安価に購入できるパッケージが存在しないことが悩みどころで、前回は仕方なくOffice Personal 2016とPowerPoint 2016の2つを買いました。ただでさえ高いのにバラバラに買うと余計高いし、Outlookも無用の長物で非常に嫌な構成でした。

不思議現象

Office 2024をインストールした直後、謎のディレクトリ「Microsoft OneNote Namespace Extension for Windows Desktop Search」がデスクトップに生成されました。しかも誰かが使っているのか移動もできません。

謎のディレクトリがデスクトップに生成

しかも調べているうちにディレクトリごと消滅しました。謎ですね。一体なんだったんでしょうか……。

Microsoft 365を使わないのか？

Officeが全部使えるMicrosoft 365ならばPowerPointのあるなしに悩むことはなくなりますが、問題点は異常に高いことです。サブスクリプション契約1年で15,000円もします、2年で永続パッケージが買えてしまいます。

Office製品は家庭でヘビーユースしませんし、年15,000円払うほどの価値を感じません。月500円（年6,000円）くらいなら良かったんですけどね……。

Ubuntu 20.04 LTSでxrdpのエラーを再現できるか挑戦

目次: Linux

先日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、Ubuntu 20で再現できるかやってみました。グラフィクスは種類が違いますがAMDのGPU（Radeon RX 6900 XT）です。条件は同様でgdm3は終了させてxrdpのみ起動しています。

結論から言うと再現しました。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2712263]: DEBUG(+): Enabling debugging
gnome-session-binary[2712263]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-binary[2712263]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
gnome-session-binary[2712263]: WARNING: Error creating FIFO: File exists

ログにはデバッグ有効であること以外は特に何も出ません。FIFOが作れない警告が出ます、これは何だろう？まあいいか。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。画面は真っ黒になってすぐに切断されます。Ubuntu 20.04 LTSでも再現するんですね。ログは下記のようになりました。

gnome-session-binary[2712010]: DEBUG(+): Enabling debugging
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712146): WARNING **: 14:44:50.573: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[2712010]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:2712203): WARNING **: 14:44:55.610: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[2712010]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[2712010]: CRITICAL: We failed, but the fail whale is dead. Sorry....

前回も見かけたamdgpu_get_auth()のエラーが出て止まりました。AMDのGPUの場合、エラーが起きると止まってしまう疑いが強まりました。本当はエラーが起きたらソフトウェアレンダリングにフォールバックしてほしいんですけど、そうならないようです……。

デバイスファイルが/dev/driに全く存在しなくてもamdgpu_get_auth()が怒ってくるところを見ると、X.orgはPCのグラフィクスの種類（VirtualBoxなのかAMDのGPUなのか）を最初から決め打ちにしているんですね。

VirtualBoxでxrdpのエラーを再現できるか挑戦

目次: Linux

昨日（2024年10月1日の日記参照）のUbuntu 22とxrdpの組み合わせで起きるエラーですが、VirtualBox 7.0.18で再現できるかやってみました。グラフィクスはVMSVGAを選択しています。VMSVGAは/dev/driの下にcard0とrenderD128が生成されるようです。ちなみにgdm3は終了させてxrdpのみ起動しています。

ちなみに結論から言っておくと再現しません。以下が通常時のログです。正常に画面が表示されます。

gnome-session-binary[2774]: DEBUG(+): Enabling debugging
gnome-session-binary[2774]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

ログにはデバッグ有効であることと、libEGLが何かしら見つけて反応しています。それ以外は特に何も出ません。

次にcard0とrenderD128をリネームしてアクセスできないようにして試しました。しかし正常に画面が表示されます。えぇー？ログは下記のようになりました。

gnome-session-binary[4319]: DEBUG(+): Enabling debugging
gnome-session-check-accelerated: GL Helper exited with code 512
libEGL warning: DRI2: failed to authenticate
gnome-session-check-accelerated: GLES Helper exited with code 512
gnome-session-binary[4319]: GLib-GIO-DEBUG(+): _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’

AMDのGPUでも見かけたfailed to authenticateが出ています。が、エラーは無視されるんでしょうか？謎の動きですね。

Ubuntu 22.04のxrdpに接続できない病

目次: Linux

WindowsからUbuntu 22.04 LTSのxrdpに接続すると真っ黒な画面しか出ず、すぐに接続が切断されてしまう問題に遭遇しました。どこでクラッシュしているか調べるため、xrdpがGNOMEを起動するところまでを追いかけると下記のようになっていました。

/etc/xrdp/startwm.sh
  exec /bin/sh /etc/X11/Xsession
    /etc/X11/Xsession.d/99x11-common_start
      /usr/bin/ssh-agent /usr/bin/im-launch x-session-manager
        /usr/bin/x-session-manager
          /usr/libexec/gnome-session-binary

スクリプトx-session-managerを書き換えてgnome-session-binaryの引数に--debugを足すと、GNOMEはより詳細なメッセージを出力します。メッセージはホームディレクトリの.xsession-errorsに記録されます。GNOMEのエラーメッセージは下記です。

** (gnome-session-check-accelerated-gles-helper:3301100): WARNING **: 13:50:04.884: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: DEBUG(+): hardware acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: GLib-DEBUG(+): setenv()/putenv() are not thread-safe and should not be used after threads are created
gnome-session-binary[3300977]: GLib-DEBUG(+): posix_spawn avoided (fd close requested)
gnome-session-is-accelerated: No hardware 3D support.
gnome-session-check-accelerated: GL Helper exited with code 256    ★★ここでエラーが発生している
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)
amdgpu_device_initialize: amdgpu_get_auth (1) failed (-1)

** (gnome-session-check-accelerated-gles-helper:3301174): WARNING **: 13:50:09.927: eglInitialize() failed
gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-binary[3300977]: WARNING: software acceleration check failed: Child process exited with code 1
gnome-session-binary[3300977]: CRITICAL: We failed, but the fail whale is dead. Sorry....

エラーメッセージ曰くamdgpu_get_auth()が失敗しています。関数名から推測するにAMDのGPUが装着されているマシンでしか発生しないエラーなのかもしれません。この関数は何者なのかDRMのソースコード（Mesa/libdrmのソースコードリポジトリへのリンク）を見ると、

// drm/amdgpu/amdgpu_device.c

/**
* Get the authenticated form fd,
*
* \param   fd   - \c [in]  File descriptor for AMD GPU device
* \param   auth - \c [out] Pointer to output the fd is authenticated or not
*                          A render node fd, output auth = 0
*                          A legacy fd, get the authenticated for compatibility root
*
* \return   0 on success\n
*          >0 - AMD specific error code\n
*          <0 - Negative POSIX Error code
*/
static int amdgpu_get_auth(int fd, int *auth)
{
	int r = 0;
	drm_client_t client = {};

	if (drmGetNodeTypeFromFd(fd) == DRM_NODE_RENDER)
		*auth = 0;
	else {
		client.idx = 0;
		r = drmIoctl(fd, DRM_IOCTL_GET_CLIENT, &client);    //★★エラーを返すのはこの関数だけ★★
		if (!r)
			*auth = client.auth;
	}
	return r;
}


// drm/xf86drm.c

/**
 * Call ioctl, restarting if it is interrupted
 */
drm_public int
drmIoctl(int fd, unsigned long request, void *arg)
{
    int ret;

    do {
        ret = ioctl(fd, request, arg);    //★★drmIoctl()はioctl()が返すエラーをそのまま返す★★
    } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
    return ret;
}

ソースコードから推測するにグラフィクス系のデバイスファイルにioctl()しようとして失敗しているものと思われます。

XのグラフィックスはDRI（Direct Rendering Infrastructure）と呼ばれるインタフェースを経由してGPUを使用します。Xとカーネルの間にはlibDRMがおり、libDRMはLinuxカーネルのDRM（Direct Rendering Manager）を使用してGPUにアクセスします。DRMのデバイスファイルは/dev/driディレクトリの下にありますが、名前がDRIだったりDRMだったりして謎ですね。グラフィクス周りはあまり詳しくなくて理由はわかりません……。

# ls /dev/dri/* -la

crw-rw-rw-+ 1 root video  226,   0  4月 30 15:00 /dev/dri/card0
crw-rw-rw-+ 1 root render 226, 128  4月 30 15:00 /dev/dri/renderD128

上記のようにキャラクタデバイス/dev/dri/card0と/dev/dri/renderD128のパーミッションを0666にしたところエラーが出なくなりました。今回はこの2つのデバイスファイルで解決しましたが、他のデバイスファイルにもアクセスしていた場合はさらに調査が必要かもしれません。グラフィクス系のエラーは簡単に調べる方法がないのが辛いですね。

ちなみにこの症状はQEMUだと再現しません。card0のパーミッションを0000にするとlibEGLがエラーになるのですが、なぜかGNOMEはエラーを無視して起動してしまいます。AMDのときだけなんで止まるんでしょうか。いまいち釈然としません……。

TAS動画をニコニコ動画にアップロードできない

クラッキングでぶっ壊されてしまったニコニコ動画が復活し、シン・ニコニコ動画になって帰ってきました。いちユーザーとしては嬉しい気分でいっぱいです。

しかし前と比べて困ったことが起きていて、BizHawkで出力した動画をシン・ニコニコ動画にアップロードしようとすると「この動画の映像形式には対応していません」とエラーが出てしまって投稿できません。試行錯誤の末、解決方法を見つけたのでメモしておきます。

端的に言えば原因はピクセルフォーマットでした。BizHawkは特に何も言わないとYUV444で出力しますが、ニコニコ動画はYUV420でないと受け付けてくれないようです。どこにもそんな制約は書いていないため、仕様か？バグか？どちらともわかりません。

YUV420にする方法ですけども、BizHawkの出力設定を[Custom]にして、下記のようにピクセルフォーマットを明示的に指定すればYUV420で出力してくれました。

-c:a aac -c:v libx264 -preset ultrafast -pix_fmt yuv420p -f mp4

もしすでにYUV444で出力済みの動画ならば、ffmpegを使って再エンコードすれば良いです。

$ ffmpeg -i input.mp4 \
    -vcodec libx264 -vb 2048000 -r 60 -s 1280x720 -pix_fmt yuv420p \
    -acodec aac -ar 44100 -ab 192000 output.mp4

動画ビットレート（-vb）、フレームレート（-r）、動画サイズ（-s）は元の動画に応じて調整してください。