2022年1月22日土曜日

ついにG Suite legacy無償版 G Suite(Google Apps の従来の無償版)が2022/7/1をもって終了へ

初っ端から恐縮ですが、以下タワゴトです。

表題の件、ついに来るべきものが来てしまいました。

メールによる案内はまだ来ていないのですが、メディア各社による報道で数日前に知りました。

こちらのGoogle Workspace 管理者ヘルプによりますと、7/1終了とタイトルに記しましたが、実際には5/1で終了します。

但し、5/1までに有料の Google Workspace サブスクリプションにアップグレードし、かつ支払情報を登録した場合は7/1まで無償で利用が可能ということだそうです。

思えば2011年に発生した東日本大震災における計画停電のため、UPSではカバーしきれない停電時間を、せめてメールサーバだけでもなんとかならないかと思って知ったサービスでした。

それ以来11年もの間、無償で利用させていただいて、感謝の念に堪えません。加えて、無償利用の期限以降も、料金さえ払えばこれまで通り、という点でも感謝です。移行、できません!!とか、移行できます、ただしこれまでのデータは全部チャラ!!、とか結構平気であるので、これはありがたいことだと思っています。

実は、有料化したら震災前の体制に戻せばイイヤという目論見で、すべて機材やサーバソフトウェアなどの準備は常に整えてあり、DNSのMXレコードの振り向け先を変更するだけにはしてはあるのですが、やはり11年という年月は長かったようです。

特に、私だけの事情だけでも、独自ドメインのメールアドレスといっても、GoogleさんからするとGMailの単なる1メールアドレスに見ているようで、例えばこのBloggerさんの登録情報を確認してみると、Google Appsで作成したメールアドレスが、がっちりGMailアカウント扱いされてしまっていました。

まだすべてを調べ切れていませんが、Googleさんのサービスにおいて、この「GMailアカウント(扱い)」ってのが結構重要な意味を持っている場合があるような気がします。

更に確認してみると、その他Google Play Developer ConsoleだのGoogle Cloud Consoleだのその他アレコレで契約メールアドレスを変更することがそもそも行えるのかどうかもわからない状況となっています。多分させてくれないサービスはいくつか出るだろうなとは思っています。

Android端末も、地味に困るのかなという感じです。

こういった数ある事情が、メンバーの数だけあるので、仮に移行するならばよほど慎重に行う必要がありそうです。

それに、GoogleさんのGMailの迷惑メールへの対応能力が素晴らしすぎて、自前で管理するメールサーバに戻したとして、情熱をもって管理しきれるのか、ということも考えなくてはなりません。

ま、要するに、見事にロックインというわけです。

2004年から使っているメールアドレスを、Googleさんにゆだねたまま安易に11年もの間、甘えてきたツケを支払う時がやってきたわけです。

自業自得ですね。

このままGoogleさんにお願いした場合、最安でも一ユーザ毎に税込み年額一人当たり\8,976円。無論人数分かかります。

自前での管理に戻す場合、まさかThunderbirdを今更皆にインストールしろ、なんていえません。WebメールはRainLoopでいいとして、カレンダーツールは?、あれは?、これは?、アップデートの監視は?、セキュリティの監視は?、トラブル対応は?、SPAMの対応は?、サーバが死んだら代替は?(新サーバ導入までの一時的運用ならGoogle WorkspaceかOutlook365でいいかも)

何の利益を生み出さないのにこの価格や労力を支払うことが、果たしてどうなんだという結論もあるかもしれません。その場合は、このドメインを(メール用には)捨てるという決断もありうるかもしれません。

今のところどうなるかわかりませんが、それにしても、本当にG Suite legacy無償版 G Suiteの提供は実にありがたかったです。

選択肢は多いので、ゆっくり考えたいと思います。

ゆっくり過ぎて5/1を過ぎても、お金さえ払えばこれまで通り、という点で大変安心です。
安心しすぎて、結局居心地がよくて支払い続けることになりそうな予感・・・

このような駄文をここまでお読みいただいてありがとうございました。

2022年1月15日土曜日

CentOS 7.9.2009上でHandBrakeCLI を1.2.2から1.5.1へ更新

気が向いたので更新してみました。

/usr/local/src/HandBrake-1.5.1に展開して作業する前提です。

目標はバッチ処理用CLIコマンドの生成です。

なお、HEVCとAACに関係しないにもかかわらずビルドの障害となるものは特に無理をして使えるようにするつもりはありません。

とりあえずビルドしてみます。

1
2
3
4
5
6
7
8
$ ./configure \
        --disable-gtk \
        --enable-x265 \
        --enable-fdk-aac \
        --disable-numa \
        --disable-nvenc \
        --disable-vce \
        --verbose

すると

1
ERROR: minimum required cmake version is 3.16.3 and /usr/bin/cmake is 2.8.12

早速cmakeが古すぎるとかでお冠です。
そこでcmakeをビルドします。ちなみに、HandBrake1.2以前からのアップデートの場合はnasmも必要になります。
さて、cmakeのビルドに必要なパッケージをインストールします。
1
2
3
4
5
6
7
8
# yum remove cmake
# yum install openssl-devel \
        keyutils-libs-devel \
        krb5-devel \
        libcom_err-devel \
        libselinux-devel \
        libsepol-devel \
        libverto-devel

無論、removeせずにalternativesでも何でもいいです。configureオプションにcmakeの場所を指定できないのが残念です。
$ wget https://github.com/Kitware/CMake/releases/download/v3.22.1/cmake-3.22.1.tar.gz -O cmake-3.22.1.tar.gz
ダウンロードしたソースを/usr/local/src/cmake-3.22.1に展開して作業します。
$ ./bootstrap 
$ make
# make install

/usr/local/bin/にcmakeができたので、改めてhandbrakeをビルドしたいところですが、その前にcontrib/ffmpegのビルドに失敗しますのでconfigureの前にcontrib/ffmpegのビルドオプションを変更して置きます。

/usr/local/src/HandBrake-1.5.1/contrib/ffmpeg/module.defsを編集して
--enable-libopus(49行目)を--disable-libopusに
--enable-libvpx(54行目)を--disable-libvpxに それぞれ変更してください。

なお、
libvpx-devel-1.3.0-8.el7.x86_64
libvpx-1.3.0-8.el7.x86_6
opus-1.0.2-6.el7.x86_64
opus-devel-1.0.2-6.el7.x86_64
がインストールされていてもcontrib/ffmpegのビルドが失敗しますが、これらはlibhbでも必要とされていますのでインストールが必要です。

ビルドに必要なコマンド及びライブラリのパッケージ名は以下の通りでしたのでインストールします。
1
2
3
4
5
6
7
8
9
10
11
# yum install \
         meson \
         ninja-build \
         libvpx \
         libvpx-devel \
         opus \
         opus-devel \
         turbojpeg \
         turbojpeg-devel \
         libvpx-devel \
         speex-devel
上記のパッケージ群をインストールしたら、改めてconfigureしてbuildします。
すると、
1
2
3
4
5
6
./libhb/libhandbrake.a(hb.o): 関数 `hb_read_preview.constprop.2' 内:
hb.c:(.text+0x5ba): `tjDecompressToYUVPlanes' に対する定義されていない参照です
./libhb/libhandbrake.a(hb.o): 関数 `hb_save_preview' 内:
hb.c:(.text+0x13c0): `tjCompressFromYUVPlanes' に対する定義されていない参照です
./libhb/libhandbrake.a(hb.o): 関数 `hb_read_preview' 内:
hb.c:(.text+0x1a90): `tjDecompressToYUVPlanes' に対する定義されていない参照です

とか抜かしてコンパイルに失敗します。
CentOS7のturbojpeg パッケージが古すぎるのですかね。

今回のケースではHEVCにもAACにもかすりもしないので、関数を呼び出している2か所をコメントアウトして、戻り値を格納する変数に!0を代入しておきます(この機能が必ず失敗終了するようにするため)。
/usr/local/src/HandBrake-1.5.1/libhb/hb.c の545行目と2441行目の二か所です。
tjAllocとかtjDestroyとかも退屈なら削ってもいいんでしょうが、私は超どうでもいいので古いturbojpegパッケージを入れたままにしてあります。

編集が終わったら、再度makeを続行しますと、HandBrakeCLIのビルドが完了です。

後は目障りなdevelなどのパッケージを削除して終了です。
お疲れさまでした。

HandBrake1.2.2に搭載のHEVC encoder version 2.9は今回の更新でHEVC encoder version 3.5+1-f0c1022b6となりましたが、同一オプションで同一ファイルをエンコードすると、エンコード速度は2fpsほど上昇しましたがエンコード後のファイルサイズが10%ほど増えてしましました。

超やっつけで申し訳ございません。

お読みいただいてありがとうございました。