ぶていのログでぶログ

思い出したが吉日

Ubuntu 18.10 Cosmic Cuttlefish にアップグレードした

f:id:buty4649:20181019145212p:plain

Ubuntu 18.10 が出たので早速アップグレードした!!!ビーバーからイカちゃんへ CosmicCuttlefish/ReleaseNotes 2018年10月19日号 Ubuntu 18.10 “Cosmic Cuttlefish” のリリース

触った感想とか

ちょびっと問題が出たが(後述)、シュッとアップグレードできた。 アップグレードにはだいたい1時間くらいかかった。 パッケージのダウンロードに一番時間がかかった気がする。

上の画像ではわかりづらいけど、全体的にちょっとオシャンティーな感じになった感じがする。 フラットデザインとかとか。

一通りアプリケーションを起動してみたが、ほぼ問題なく動いている。 ・・・のだが、Slackアプリが起動するとコアダンプするのであった。。。つらい

$ slack
Segmentation fault (コアダンプ)

straceとかしてみてもよくわからなかった。。 snapアプリとしてインストールすれば起動はするのだが、日本語入力出来ないのであった*1。。 この問題が直るまでは、Web版を使うことにした。

アップグレード時の問題

ここではアップグレードを行うときに発生した問題について書いておく。 まずはじめに do-release-upgrade できない問題があった。 まぁ、これは、初期インストールのときにLTSリリースを使ったために、LTS以外のリリースが降ってこないのであった。 なので、これを変更する。

$ diff -u release-upgrades /etc/update-manager/release-upgrades
--- release-upgrades    2018-10-19 10:13:49.639702894 +0900
+++ /etc/update-manager/release-upgrades        2018-10-19 10:14:00.619688422 +0900
@@ -14,4 +14,4 @@
 #           used if the currently-running release is not itself an LTS
 #           release, since in that case the upgrader won't be able to
 #           determine if a newer release is available.
-Prompt=lts
+Prompt=normal

これで do-release-upgrade すればアップグレードが始まるのだが、なぜかエラーで止まってしまった。。

(appstreamcli:24569): GLib-ERROR **: 10:15:55.449: g_variant_new_parsed: 11-13:invalid GVariant format string
Trace/breakpoint trap (core dumped)

アップデート中にエラーが発生しました

アップデート中に問題が発生しました。通常、これはネットワークにおける何らかの問題です。ネットワーク接続が可能であることをチェックし、あらためて試してください。

ネットワークの問題ではないのは確定的に明らかなので、エラーメッセージでググってみた。 すると libappstream4 をresintallすると直る的な記事を見つけたので、実際にやってみたら直った。

$ sudo apt-get install --reinstall libappstream4
$ sudo do-release-upgrade

アップグレード後、ログインしようとしたら失敗した。 これは、ActiveDirectoryアカウントを使用してPCにログインしていたのだが、アップグレードのタイミングでキャッシュが消されてしまったらしく、認証が通らないのであった。 会社のネットワークに入り、再度ログインを試したところ問題なくログインできた。

*1:この問題早く直って欲しい

Ubuntu18.04のDNSリゾルバをsystemd-resolvedからdnsmasqに変更する

デスクトップLinuxとして使っているUbuntu18.04で、ドメインごとに問い合わせるDNSサーバを変更したい場面が出てきた。 具体的には、VPNを接続してその接続先のドメインだけはDNSサーバを変更したいみたいな。

Ubuntu18.04ではDNSゾルバとして、systemd-resolvedを使っている。 こいつでは、やりたいことは出来ないようなのでdnsmasqに変更することにした。

なぜdnsmasqなのか?

すでにインストールされていて*1、そしてNetworkManagerが対応している。 Ubuntu18.04ではネットワーク関連の設定をNetworkManagerが管理しているので、とても都合がよい。 そんなこんなでdnsmasqを使うことにした。

systemd-resolvedを止める

止める手順としてはまず、/etc/systemd/resolved.confResolve セクションに DNSStubListner=no を設定する。

[Resolve]
DNSStubListener=no

設定を行ったら systemd-resolved を再起動する。

$ sudo systemctl restart systemd-resolved

再起動した後、digっても何も返ってこないはず。

NetworkManagerの設定をする

この状態でdnsmasqを起動してもいいのだが、NetworkManagerと連携させないとDHCPで降ってくるDNSサーバの情報を反映させることができないため、連携設定を行う。 連携設定は /etc/NetworkManager/NetworkManager.confmainセクションに dns=dnsmasq を設定する。

[main]
dns=dnsmasq

次に、NetworkManagerを再起動したいのだが、実はまだdnsmasqとの連携設定が出来ていない。 というのも /etc/resolv.conf が systemd-resolvedが生成するresolv.confへのシンボリックリンクになっている場合、NetworkManagerは自動的にsystemd-resolvedと連携するようになる。 なので、 このシンボリックリンクを削除する。

$ ls -lah /etc/resolv.conf
lrwxrwxrwx 1 root root 39  8月 10 17:32 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
$ sudo unlink /etc/resolv.conf

/etc/resolv.conf は作らなくてもNetworkManagerを再起動すれば作成されるので問題ない。 ということで、NetworkManagerを再起動する。

$ sudo systemctl restart NetworkManager

dnsmasqの設定を変える

ここまでの設定でdnsmasqがDNSゾルバになっているはず。 しかし、まだ当初やりたかった 特定ドメインだけDNSサーバを変える を達成していない。 NetworkManagerで起動するdnsmasqは /etc/NetworkManager/dnsmasq.d 配下にあるファイルを読み込むのでこのディレクトリ配下に設定ファイルを作成する。 ファイル名は何でも良いのだが、なんとなく default.conf にした。

$ cat /etc/NetworkManager/dnsmasq.d/default.conf
server=/example.com/192.0.2.0

設定ファイルを作成後、NetworkManagerを再起動すると反映される*2

digれない!

dnsmasqを使うようになってからdigを打ったら何も取得できない!!!

$ dig

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 57447
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b9472f88fb4991ce (echoed)
;; QUESTION SECTION:
;.                              IN      NS

;; Query time: 3 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Oct 12 19:46:35 JST 2018
;; MSG SIZE  rcvd: 40

結論からいうと、私の環境が悪かった。 dnsmasqが問い合わせに行く上位のDNSサーバ(つまりDHCPで設定されたDNSサーバ)が、DNS cookieを受け付けていなかったのであった。 よって、+nocookie オプションをつければ問題は解決された。

$ dig +nocookie

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28281
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       77519   IN      NS      j.root-servers.net.
.                       77519   IN      NS      k.root-servers.net.
.                       77519   IN      NS      m.root-servers.net.
.                       77519   IN      NS      h.root-servers.net.
.                       77519   IN      NS      b.root-servers.net.
.                       77519   IN      NS      l.root-servers.net.
.                       77519   IN      NS      a.root-servers.net.
.                       77519   IN      NS      e.root-servers.net.
.                       77519   IN      NS      c.root-servers.net.
.                       77519   IN      NS      d.root-servers.net.
.                       77519   IN      NS      i.root-servers.net.
.                       77519   IN      NS      g.root-servers.net.
.                       77519   IN      NS      f.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net.     86400   IN      A       192.58.128.30
a.root-servers.net.     26879   IN      A       198.41.0.4

;; Query time: 8 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Fri Oct 12 19:49:53 JST 2018
;; MSG SIZE  rcvd: 284

ちなみにこの問題はsystemd-resolvedのときは起こらなかった。 systemd-resolvedは上位のDNSサーバに問い合わせるときには、どうやらDNS cookieをつけていないようだった。 dnsmasqでも同じ設定ができるのかどうかは調査中…。

Tips: 現在設定されている問い合わせ先DNSサーバを知る

通常、問い合わせ先のDNSサーバは /etc/resolv.conf を見ればわかるんのだが、今回の設定によりローカルをみるようになっている。 しかし、nmcliから確認することができる。

$ nmcli d sh | grep DNS

ちなみに、systemd-resolvedでは systemd-resolv というコマンドがありこちらで確認できる。

*1:私の環境ではインストールされていた。もしかしたら、何かのついでにインストールされていたのかもしれない

*2:もしかしたらこの手順は不要かもしれないが、調査していない

Nano Pi NEO2でBluetooth PAN(NAP)を設定する

半年ほど放置していたNano Pi NEO2を引っ張り出しLEDマトリクスパネルの制御に使っている。 制御用のプログラムをアップデートするには、どうにかしてログインしないといけないわけで、これが結構悩ましい。

Nano Pi NEO2には有線LANがついているので、これを使うというのが妥当ではあるのだが、組み込み用途だと持ち運びができなくて不便になる。 次にWiFiという選択肢なのだが、これもやはり持ち運びが不便だ。 SSIDを登録しておけば、移動先でもアクセスできるのだが、それを設定するのが面倒である。。 また、数年前の知識なのだが小型のUSB WiFiドングルはかなり熱を持つので長時間使うには向いていない。 シリアルコンソールという方法もあるが、これはこれでファイル転送ができなくてかなり不便である。

そこで、USBのBluetoothドングルを接続してBluetooth PANを使うことにした。

Bluetooth PAN

Bluetooth PANはPersonal Area Networkの略称で、Bluetoothを使ってTCP/IP通信する企画である。 スマートフォンBluetoothを使ってテザリングをするときに使われるのが一般的だと思う。

Bluetooth PANには以下の3つの役割がある。

  1. NAP
  2. GN
  3. PANU

Bluetoothテザリングをしたときに、スマートフォンがNAP。 スマートフォンに接続したPCが、PANUになる。 今回は、Nano Pi NEO2をNAPにする。

USB Bluetoothドングルの選択

これはLinuxで使えればなんでもよい。 ただし、Nano Piにはカーネルソースが提供されておらず*1カーネルモジュールをビルド出来ないので、デフォルトでカーネルに含まれているドライバで動くドングルを選択する必要がある。 私は、Amazonエレコムのやつを買った(LBT-UAN05C2)。

LinuxBluetooth PAN(NAP)の設定

設定自体は以下のサイトを参考にした。

raspberrypi.stackexchange.com

設定を行う前に、以下のパッケージをインストールする。

$ sudo apt-get install -y bridge-utils bluez-tool

次にネットワークの設定を行う。 参考サイトはraspbian用の設定で、Nao Pi NEO2で使っているUbuntu xenialでは少し設定を変えないといけない。 具体的には、systemd-networkdが使えないので、ブリッジの設定とDHCPサーバをなんとかしないといけない。

以下のような設定を /etc/network/interfaces に追加する。 ポイントは bridge_portsnone に設定するところ。 bridge_portsがないとブリッジインターフェイスにならないが、ブリッジにインターフェイスを追加したくないのでnoneにする必要がある。

auto pan0
iface pan0 inet static
  address 192.0.2.1
  network 192.0.2.0
  netmask 255.255.255.0
  broadcast 192.0.2.255
  bridge_ports none
  bridge_fd 0
  bridge_stp off

設定が終わったらpan0を起動しておく。

$ sudo ifup pan0

次にDHCPサーバの設定をする。 dnsmasqがインストールされているのでこれを使う。 以下の設定を /etc/dnsmasq.conf に設定する。

dhcp-range=pan0,192.0.2.11,192.0.2.250,24h

設定が終わったらdnsmasqを有効化する。

$ sudo systemctl enable dnsmasq
$ sudo systemctl start dnsmasq

次にbt-agentとbt-networkの設定をする。 それぞれ、デーモン化する必要があるので、以下のようなUnitファイルを作る。

$ cat /etc/systemd/system/bt-agent.service
[Unit]
Description=Bluetooth Auth Agent

[Service]
ExecStart=/usr/bin/bt-agent -c NoInputNoOutput
Type=simple

[Install]
WantedBy=multi-user.target
$ cat /etc/systemd/system/bt-network.service
[Unit]
Description=Bluetooth NEP PAN
After=pan0.network

[Service]
ExecStart=/usr/bin/bt-network -s nap pan0
Type=simple

[Install]
WantedBy=multi-user.target

設定が終わったら有効化する。

$ sudo systemctl enable bt-agent.service
$ sudo systemctl start bt-agent.service
$ sudo systemctl enable bt-network.service
$ sudo systemctl start bt-network.service

これで準備が出来たので後はペアリングするだけである。 これについては割愛する。

まとめ

Bluetooth PANの設定ができた。 これでどこに持ち運んでもBluetoothを接続すれば、sshできるようになって便利。 さすがに、Bluetoothではそこまで速度はでないがオペレーションするくらいなら十分である。 しばらくこのまま運用してみようと思う。

*1:aptではいるわけでもなく、どこからかDLできるわけでもなさそう?

ISUCON8に参加した

ISUCON8DMZという名前で参加した。 名前の由来は、参加メンバーの頭文字3つ。 ちょうど、非武装地帯(DMZ)になってゴロが良くて気に入っていたw 結果は予選敗退。。 やはり、壁は厚いなと思いつつも、参加して3年目でついに1万点の壁を突破したので嬉しかった!*1

やったこと

午前中〜お昼くらいまで、ベンチマークを走らせてもほとんどfailedしてしまって全然スコアが出なかった。。 ベンチマークが感想しないと、ログがでないのでどこがボトルネックかわらかないのでこれを最初に解決した。 初期ではアプリケーションとDBが1つのサーバに乗っていたので、これをわけることにした。 これで、10回に1回しか成功してなかったベンチマークが5回に1回くらい成功するようになった。

次にアプリケーションの見直しを行った。 ぱっとソースを読んだ感じ、get_eventsが遅そうだということでこの部分を見直し。 また、reservationテーブルやsheetsテーブルにインデックスを追加。 そして、get_eventsから呼び出されていて、かつ、様々なところから呼び出されていたget_eventも見直した。

get_eventは見たまんまN+1でどうにかするしかないなっと思ったのだが、どうしたら解決するか全くわからなかった。。 仕方ないので、出力するデータをホワイトボードに書き出し、何が必要でどういうデータが入っているかを把握することにした。 実際に書き出してみると行っていることは単純で、かつ、sheetsテーブルは必要がなかった*2ので、シュッと書き直した。 これらの変更によりスコアが3500点くらいになった。

次に私は、 /api/user/:id を見直すことにした(この時点でだんだん疲れてきていて、他のメンバーが何やっていたかうろ覚え…)。 get_events/get_eventの見直し後にベンチマークを走らせたところ、このURLへのアクセスが遅いと書かれていたというのが理由。 /api/user/:id は、ユーザが直近で予約した席とイベント情報を表示するためのJSONを返す。 内部では、get_eventを呼び出して席の予約情報を取得しているのだが、一番重い処理である各シートランクごとの予約情報(event['sheets'][:rank]['details'])を使っていなかったので、これを固定値で書き直して、get_eventを叩かないようにした。 また、直近のイベント情報は直近の席情報に含まれるイベント情報と差異がなかったので、event_idをキーにしてuniqしたArrayを返すようにした。 これで、12000点くらいになった。

ここらへんで16時くらい。 もうあまり時間がないので、シュッとできる点数が上がりそうなことをやることにした。 最初に、セッションをredisに保存するようにした。 このredisは、3台あるサーバの中で唯一何もしていないサーバに配置した。 また、アプリケーションサーバを2台のサーバで実行するようにした。 フロントはh2oのままで、重い処理である /admin 配下の処理をわけるようにした。 最初はredisを載せている側で、/admin 配下を処理していたのだが、こちらはやたらメモリを食う処理があったので、変更した。 最終的には以下のような感じ。

  1. h20 + アプリケーション( /initialize/admin/ 配下)
  2. DB
  3. redis + アプリケーション(1以外のすべての処理)

この分離を行ってベンチを取ったら18000点くらいになって、ktkr!!!!っとなったので一旦リブートしベンチをとることにした。 そうしたら、failしてしまった。。。 原因は、アプリケーションをわけてせいで /admin/api/reports/sales というめちゃくちゃ重い処理がロックを取れずに500エラーを返すことだった。 もう残り時間も少なくシュッと解決できなかったので、begin〜resuceで処理を囲み成功するまでSELECTする作戦で回避した。。 競技終了前に再度リブートをかけ、ベンチを取ったところ 19045点だった。

感想

今まで、インフラレイヤ担当として参加していたが、今年はアプリケーション担当としてコード変更をメインに作業した。 これが結果として功を奏したのかもしれない。 私がインフラ担当だったら、まずh2oをNginxにして、mariadbMySQLにして…みたいなことを考えていたと思う。 今年はそこをきっぱり諦め、まずアプリケーションを治すところに専念したのが良かったのかもしれない。

また、インフラ担当とはいえアプリケーションコードを理解するのは大切だと改めて思った。 これはISUCONに限らず実務でもそうで、アプリケーションコードを把握していないと、どこがボトルネックか?どこで障害が起こっているか?などすぐに出てこない。 開発担当に聞くのもありだけど、インフラ側がその部分を修正できるとよりDevOpsっぽくなるのかなぁっと思った次第。

*1:自分たちで最後に集計した結果で、公式発表の点数は後日発表されるはず

*2:IDに紐づくランク、座席番号、価格は固定だった

開発効率をあげるgitテクニックというタイトルで社内発表会で発表してきた

ペパボカクテルのメンバーが企画した「シェル大活用講座」という発表会で発表してきました。 gitの話が中心ですが、シェルに関連するということでちょっぴりシェル芸も入っています。 資料を作っていて改めて調べ直すと、自分が使っているコマンドより更に便利な方法があることをしれたりして、とても勉強になってよかったです。 ただ、途中でxargsの話を書き始めたらものすごく熱が入ってしまい文字だけのスライドになってしまったw(なお、本番では時間の関係でスキップされた)

ここからは余談。 昨日夢で、発表会でプロジェクタの接続にとちってあわわわあわわしているうちに発表時間がなくなるという最悪の内容で飛び起きた。。。 で、それを今日も再現してしまい完全に正夢になってしまった・・・・・・・・・・・・・・・・・ 夢と違うのはみんなの協力によりリカバリーできたのでちゃんと発表できたのであった*1。めでたしめでたし。

*1:なお、原因はLinux端末に不慣れであったこと。メインディスプレイとサブディスプレイで解像度が違う場合にミラーリングするのがすごくめんどくさいということがわかったのであった。。

LinuxデスクトップのランチャーアプリとしてUlauncherを使い始めた

Linuxデスクトップを使い始めたのは前回書いたとおり。 macOSのときはAlfredを酷使していて、これがないと生産性がガタ落ちであった。 そこで、Linuxデスクトップでも同じ感じのランチャーを探すことにした。

linux alfred alternative とかで検索するとまずはじめにMutateが目に止まるのだけど、3年前くらいから開発が止まっているようなのでやめた。 次にAlbertを使い始めた。しかし、日本語周りの扱いが怪しかったり、ほしいプラグインがなかったりしてこれも使うのをやめてしまった。 そして最終的に行き着いたのがUlauncherだった。 このランチャーにもほしいExtensionがなかったのだけど、Pythonで自作できるようなので自作してしまった。

Github/Github Enterprise リポジトリ検索

github.com

仕事柄GithubというかGithub Enterprise(GH:E)にアクセスすることが多々ある。 ブラウザのブックマークでは管理が煩雑すぎるので、ランチャーから直接リポジトリトップを開けるととても生産性があがる。 Alfredのときもalfred-github-workflowをヘビーユーズしていた。 このExtensionはぶっちゃけ、alfred-github-workflowのポーティング版である。 ただ、オリジナルと違うのはGithub API v3を使わずにGithub GraphQL API v4 を使っている。 なぜ、GraphQLを使ったかというと、v3の方ですべてのリポジトリを取得するのにかなりの時間とリクエストを飛ばす必要があることがわかったためである。 alfred-github-workflowではキャッシュを入れることで軽減しているが、その機構を作るのがめんどくさかったのであった…。 また、新しい技術に触れてみたいというのもあったのであった。

GraphQLのアクセスには、Pythongqlを使っているので事前にこれをインストールしておかないとエラーになると思う。

$ sudo pip install gql

Firefoxブックマーク検索

github.com

こちらもAlfredのときにそこそこ使っていたのでポーティングした。 公式ページにあるExtensionページにはChrome版はあるのだが、Firefox版がなかった。 簡単に実装できるだろうっと思ったのだけど、FirefoxSQLiteにブックマーク情報を格納していたり、テーブル構造を理解していないといけなかったりで結構大変だった。。

Extensionの作り方

これに関しては公式のドキュメントにまとまっているので、この通りに作っていけば特にハマるところはなかった。 シンプルな作りですぐにExtensionがつくれるのもUlauncherの魅力の一つだと思った。

Ulauncher 4.0 documentation — Ulauncher 4.0.0 documentation

まとめ

Ulauncherを使い始めて、そしてExtensionを自作することでかなり生産性があがった。 AlfredのWorkflowほど詳細な処理はできないにしても、シンプルにExtensionを開発できるので私はかなり気に入った。 Ulauncher本体の開発も継続的に行われていて安心感もあるのがよい。 ひとつ懸念があるとしたら、Python2.7で開発されているのでどこかのタイミングでPython3系に移行してもらいたいのであった…。

LinuxデスクトップのターミナルアプリとしてAlacrittyを使い始めた

f:id:buty4649:20180728214241p:plain

最近、会社用のPCをLinuxデスクトップに変えた。なんで変えたのかとかは別の機会でブログを書く…っと思う。

で、職業柄ターミナルアプリを酷使するので自分の手にあったものを使いたい。 今までMacを使っていたときはiTerm2を使っていた。 LinuxにはもちろんiTerm2はないので代わりのアプリを探さないといけない。 当初は、GNOME Terminalを使っていたのだがなんと OSC52が使えない のであった*1。 tmuxのクリップボード機能でOSC52を多様している*2私にとってこれは死活問題…。 仕方ないのでOSC52が使えるターミナルを探した。

そこで、xtermを使い始めた。 OSC52だけではなくSixelにも対応している! HiDPIな環境で色々設定は大変だったが、なんとか実用できるようにはなった。 …が、描画が致命的に遅いことがわかった。 tail -fやrsync -avなどでログが流れると、CPU使用率がかなり高くなりマウスがカクカクになって使い物にならなかった…。

で、最終的にAlacrittyに行き着いた。

クロスプラットフォームGPUアクセラレートターミナル

github.com

AlacrittyはクロスプラットフォームGPUアクセラレートを謳っている。 たしかに、macOSを使っているときに、試したことがあるが問題なく動作していた(結局はiTerm2に戻ったけど)。 GPUアクセラレートを謳っているだけあって確かに描画時のCPU負荷はかなり低い。 それでも、CPU使用率が15%程度になるが、xtermより圧倒的に速い。 また、OSC52にも対応している!!!神か??? しかしながら、Linux環境ではカラー絵文字が表示されない問題があるようだ。 ただ、個人的にはカラー絵文字が使えないことはあまり問題ではないので気にしないことにした。

OSC52のバッファが1000byteしかない

OSC52が使えるのだが、デフォルトでは1000byteしかない。 この1000byteは、Base64化したあとの文字列1000byte分なのでコピーできる文字はこれより少なくなる。 実際この制約はかなり厳しく、コマンドの結果がコピーできないことがしばしば起こっていた。

この問題は以下のissueで報告されているが、Fixされていない。

github.com

FixされていないがPRはでているので、私はこれを取り込んだものをビルドして使っている。

github.com

パッケージビルド

github.com

例のごとくパッケージビルダーを作った。 ・・・のだが、いつのまにかcargo-debに対応したためにdockerを用意しなくてもお手軽にビルドできるようになってしまった(cargoすげー)。 とはいえ、先に書いたOSC52のパッチを当てたいし、パッケージのバージョンが常に0.1.0で固定されているのが個人的に管理しづらかったのでそこら辺をよしなにしている。

まとめ

AlacrittyはLinuxのターミナルアプリとしてかなり便利に使っている。 カラー絵文字だったり、複数タブが開けないとかはあるが、開発は活発だしそのうち解決されるだろうたぶん。

OSC52対応が必須でなければGNOMEターミナルで十分だと思うし、ここらへんは好みかなぁっと思った次第。

*1:GNOME vte widgetのBugzillaに要望がでているのでこれがFixされれば使えるようになるかも? https://bugzilla.gnome.org/show_bug.cgi?id=795774

*2:https://buty4649.hatenablog.com/entry/2017/02/09/202007