Q&Aでわかる Red Hat Universal Base Image でどこまでやっていい?

Red Hat Universal Base ImageについてのFAQをまとめた資料です

GENERAL Distribution Q&A でわかる Red Hat Universal Base Image で どこまでやっていい ? 1 2020 年 1 月 21 日 レッドハット株式会社 森若 和雄 そもそも UBI とは…… ? UNIVERSAL BASE IMAGE UBI 登場までの課題 RHEL base image 汎用目的で利用できる RHEL のコンテナイメージ。 RHEL と同じエンタープライズ契約 (EA) でカバーされ、 RHEL や OpenShift 上で利用すると基盤とともにサポー トできる。 他の人にコンテナイメージを配布したい EA 契約で第三者への配布が制限されているので直接の配 布は不可。コンテナイメージを Red Hat に一旦預ければ OK(Red Hat Container Catalog) だが独自に配布したい ケースではこのポリシーは受け入れにくい。 3 CentOS 等を base image に使えばいいのか ? 契約上の問題はないものの、当然 Red Hat はサポートで ない。 UNIVERSAL BASE IMAGE Universal Base Image によるソフトウェア流通 再配布可能なコンテナイメージ RHEL7 および 8 のサブセットで、 無償で入手・改変・再配布が可能 なコンテナイメージと rpm パッ ケージ群 Red Hat 基盤ではサポート対象 RHEL または OpenShift 上で利用 する場合は UBI もサポート対象 ソフトウェア配布に ソフトウェアをコンテナイメージ で配布する場合のベースイメージ として最適 GENERAL Distribution UBI を入手するには Red Hat Container Catalog から https://catalog.redhat.com/software/containers/explore Provider に Red Hat, Inc. Product に Red Hat Universal Base Image と指定して検索 5 GENERAL Distribution Container Catalog の 各イメージのページ ● 各ツールでの入手方法 ● podman ● docker ● openshift ● イメージの更新日などの メタデータ ● 関係するドキュメントや 環境変数 ● 既知の脆弱性などに もとづく Health index 6 UBI の基本的な Q & A 7 Q. UBI は何のためにあるの ? RHEL をベースにした ISV 製品の配布をスムーズにする ために作られました ISV 製品入り コンテナイメージを 自由に配布できる Red Hat のコンテナ 環境ならサポート可 App 非 Red Hat 環境では サポートは不可だが 利用は OK App App UBI UBI UBI RHEL or OpenShift CentOS, Fedora, etc. Q. UBI は何のためにあるの ?( 続 ) UBI は RHEL コンテナベースイメージも兼ねています RHEL のパッケージを含むと再配布は不可なので要注意 社内用 RHEL コンテナイメージを 作成するベースに App RHEL rpm UBI Red Hat のコンテナ 環境ならごく普通に 購入 & サポート可 App RHEL rpm 非 Red Hat のコンテナ 環境ではサポートは不可だが 要サブスクリプション App RHEL rpm UBI UBI RHEL or OpenShift CentOS, Fedora, etc. Q. UBI の想定利用シーンは ? ● ● RHEL 上で UBI をベースにして ISV 製品を入れ てビルド、第三者へ配布 イメージを受けとって実行する人は任意の環境 で実行できる – RHEL or OpenShift であればサポートされて嬉しい – その他の環境でも別に害はない Q. UBI はどういう契約で提供されるの ? ● End User License Agreement(EULA) です。 – – RHEL など通常の製品は EULA と Enterprise Agreement の 2 本の契約が行われます。 再配布する場合イメージ内に EULA をそのまま維持す る必要があります。 https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI Q. UBI と RHEL のパッケージは同じ ? この質問は 2 通りの解釈ができるので両方回答します…… ● ● UBI と RHEL に含まれているパッケージのセットは異なります ( ほとんど全てのサーバや kernel は UBI に含まれません ) UBI と RHELリポジトリに同じ名前の rpm パッケージが存在 する場合、署名を含め完全に同じファイルです。差はありませ ん。 Q. UBI と同じイメージを自分で リビルドできる ? ● UBI 構築時の Dockerfile は公開されていますが 社内のビルドシステムで作られたイメージから 派生しているので自分でリビルドはできません 費用、再配布、サポート可否の Q&A Q. UBI を RHEL or OpenShift 上で使っていい ? ● 当然 OK! ● UBI 部分もサポート対象になります App UBI RHEL or OpenShift Q. UBI を public cloud 各社の managed OpenShift 上にもっていっていい ? ● 当然 OK! ● UBI 部分もサポート対象になります App UBI managed OpenShift public cloud (IaaS) Q. UBI を public cloud 各社の (Red Hat 製品では ない ) managed k8s 上にもっていっていい ? ● 使うのは OK! ● サポートはできません App UBI managed k8s public cloud (IaaS) Q. UBI を CentOS 等の上で使っていい ? ● 使うのは OK! ● サポートはできません App UBI CentOS Q. UBI に CentOS 等のパッケージを入れていい ? ● ● ● 入れる行為自体は OK 。ただし RHEL or OpenShift 上 でもサポートできなくなります。 ソフトウェア配布のために必要なパッケージがあれば bugzilla へリクエストしよう。 必要なら RHEL のパッケージを入れよう。 ( その場合については次のページ ) App CentOS rpm UBI Q. UBI に RHEL のパッケージを入れていい ? ● ● OK! ただし RHEL のパッケージを 1 つでも入れる と、 RHEL の制限が適用されるので第三者に配 布できません。通常の RHEL のバイナリと同様 に扱う必要があります。 App RHEL rpm UBI Q. UBI に RHEL パッケージを入れて CentOS 等の上で使っていい ? ● ● 使うこと自体は OK サポートはできませんが RHEL のサブス クリプション費用が必要です。そのため 現実的には無意味な組み合わせです。 $$$ App RHEL rpm UBI CentOS Q. UBI に RHEL パッケージを入れて public cloud の managed k8s 上で使っていい ? ● ● 使うことは禁止されていませんが…… RHELサブスクリプションをいくつ買 えばいいのかなどは決まっていないので Red Hat の担当営業にご相談ください。 ( ほとんどの場合現実的な話には なりません。 ) $$$ $$$ $$$ App RHEL rpm UBI managed k8s public cloud (IaaS) UBI をコンテナイメージとして使う場合のまとめ RHEL or OpenShift 基盤 non Red Hat 基盤 UBI + 自作ソフトウェア サポート○ 追加費用なし○ 再配布可能○ サポート不可 × 追加費用なし○ 再配布可能○ UBI + RHEL パッケージ サポート○ 追加費用なし○ 再配布不可 × サポート不可 × 追加費用あり × 再配布不可 × UBI + CentOS パッケージ サポート不可 × 追加費用なし○ 再配布可能○ サポート不可 × 追加費用なし○ 再配布可能○ その他の Q&A Q. 「 ISV 製品の配布」の “ ISV” って 何か契約とか要るの ? ● ● 要りません。 Red Hat には ISV を含む「テクノロジーパート ナー」の制度がありますが、 UBI を使ったり UBI をベースとし たイメージを再配布するだけであれば無関係です テクノロジーパートナーになると自社製品を Red Hat のコンテ ナカタログに掲載できるなどの特典があるので、 UBI の利用に 必須ではありませんがそれはそれでご検討ください :-) 詳しくはこちら→ https://connect.redhat.com/ Q. UBI に含まれる rpm パッケージだけを 再配布していい ? ● OK! ● EULA を添付する必要がある点に注意。 Q. UBI に OpenJDK のベースイメージはないの ? ( 将来は登場するかもしれませんが ) 今のところありません ● ● DockerHub にある ubi8/openjdk は Red Hat と無関係の第 三者によるものです。 openjdk/openjdk-8-rhel8 などは OpenShift の一部です。 UBI の一部ではありません。 Q. RHEL のパッケージを混在させない方法 ● ● RHEL 上で UBI を利用すると、デフォルトではホストの subscriptionmanager での登録状況を引き継ぎます。 – ホストが登録されていれば yumRHEL パッケージを利用します。 – UBI は RHEL の base image を兼ねているため、意図された動作です。 第三者配布用のコンテナイメージ作成時には、 yum の実行時に ” --disableplugin=subscription-manager” とオプションをつけることで RHEL のパッケージが混在しないよう制限します。 – ホスト側で subscription-manager unregister とかしてもいいですが、ホスト の状態に依存しないでビルドできるので Dockerfile 等を修正する方が安全 Thank You!

kindle本の読みあげで試行錯誤したメモ

結論

試行錯誤中だけどユーザ体験としていちばんいいのはFireタブレット

はじめに、Fire HD10でkindle読みあげ

2020年元旦に投稿された以下の記事に触発され、その時やっていたkindle本のセールで10冊くらいNHK 100分de名著シリーズのテキストを買いました。 anond.hatelabo.jp

そのちょっと前に購入していた Fire HD10のkindleアプリでは、Android版やiOS版にはない自動読みあげ機能がついていて、音声の品質はいまいち(ゆっくり音声よりいいけどAlexaよりはだいぶダメ)ながら読みあげをしてくれる。

オンラインでもオフラインでも読みあげてくれて、ページも自動でめくってくれるので良いです。私が黙読する速度は2倍速よりやや速いくらいですが、聞きとりづらくなるのと間違った読みを確認する時間の余裕もほしいので、ややゆっくり目の1.5倍速で聞いています。 文体や言葉づかいにもよりますがときどき間違えるのでその時には画面をチラッと確認して使っています。

その他のkindle本を読みあげる方法

さて、日常的にAlexaやGoogle Assistantとかを使っているのでもうちょっといい声で再生したいです。同じことを考える人は多く、既にいくつかの方法があります。

Alexaのkindle本の読みあげ機能を使う

Alexa(echo端末でもAndroidiOSのアプリでもよい)に対して「アレクサ、○○を読んで」と言うとその本の最後に読んでいたあたりから読みあげてくれます。登場当初は速度変更ができませんでしたが現在は「アレクサ、早く(遅く)読んで」のように言うと1.25倍や1.5倍などの速度で読みあげてくれます。

  • 良いところ: 読みあげ音声品質。
  • 悪いところ: 操作の粒度があらい。具体的には脚注などを大量に読みはじめたときにスキップさせたり、「ちょっとだけ戻して」みたいな操作がみあたらない。 (1/21追記:「1分早送り」「30秒巻き戻し」のように言うと飛ばしてくれます。AndroidのAlexaアプリでは30秒早送りおよび巻き戻しボタンがあります。)

Androidアクセシビリティ機能(TalkBack)、iOSアクセシビリティ機能(VoiceOver)を使う

AndroidまたはiOSKindleアプリを実行して、OSの画面読みあげ機能を使います。

  • 良いところ: 読みあげ音声品質。電話は普段持ちあるいているので物が増えない。
  • TalkBackの悪いところ: 動かない端末がある。具体的には私が電話として使っている Huawei P20 lite ではKindle本のコンテンツは読みあげられませんでした。Talkbackのほとんどは動作しているようなのですが謎です……。
  • VoiceOverの悪いところ: 画面表示上のページの区切れ目と、読みあげの区切れ目がことなる。おそらく段落ごとに読みあげ開始するのですが、あるページが段落の途中からはじまっていると次の段落から読みはじめたりします。当然ページめくりも同期しません。

まとめ

読み上げ品質

どれも聞きとれるんで実用上大きな違いはないのですがおおむね以下くらいの印象。Fire HDの音声がAlexaと同じくらいになってほしい……。

Google TalkBack = Alexa > Siri(VoiceOver) >> Fire HD

画面との同期

現状の日本語音声読み上げはあたりまえに間違いが入るので、私は画面をチラ見したいです。そういう点では以下のようになります。

Fire HDのKindleアプリ > Google TalkBack >> Siri(VoiceOver) >>> Alexa(画面がないのでしょうがない)

利用の簡単さ

標準機能であるKindleアプリとAlexaはさすがに利用はスムーズです。

VoiceOverは前述のページ区切りとのズレさえ飲みこめれば利用そのものは簡単です。専用のフローティングアイコンが常に表示されるのでゲームなどをする人には邪魔かもしれません。

Google TalkBackは視覚障害者むけのアクセシビリティ機能ということで、画面をみなくても使えるよう工夫されています。今回のように「Kindleの読みあげだけさせたい」というユースケースでは普段のAndroid利用とかなり異なる独特の手順を覚えることになるので面倒です。

Fire HDのKindleアプリ > Alexa > Siri(VoiceOver) >>> Google TalkBack

画面表示がいらない人むけtips

多少間違いがあってもオーディオブックみたいな使い方をしたい場合は、以下の記事が参考になります。

katsumakazuyo.hatenablog.com

Kindle以外について

Google Play BooksのAndroidアプリではごく普通に読みあげしてくれました。「100分de名著」のテキストは売ってないので今回使えませんが青空文庫を読ませたい人にはいいかもしれません。

自分の現状

もろもろ踏まえて、以下のようにおちつきました

  • 移動先ではiOSのVoiceOver (普段遣いはAndroidなので、TalkBackが動けばそちらがよかった)
  • 家ではFire HD10のKindleアプリの利用

MusicBrainz Picardで音楽ライブラリのタグ付けしたメモ

正月やすみにMusicBrainz Picardを使って音楽ライブラリのタグ付けをみなおしました。

MusicBrainz Picardとは

MusicBrainz Picardは、mp3やogg vorbisなどのファイルに「半自動で」タグをつけるソフトウェアです。名前から予想されるとおり MusicBrainzのデータをつかってタグが存在しない楽曲でもそれなりに推定してくれます。

picard.musicbrainz.org

f:id:mrwk:20200105113915p:plain

なんでやったの?

再生に不備はないので放置していたんですが、自分の音楽ライブラリのタグがカオスでした。

  • 昔のmp3には文字エンコードSJISでタグついてたり
  • そもそも自分がローマ字でタグやファイル名つけてたり
  • それをoggに変換したときに使ったツールがUTF8前提にしていて文字化けしたり
  • さらに自作スクリプトのバグでArtistタグが設定されていないファイルを変換したときに関係ないArtistタグが入ってしまったり……

最近Spotifyを使いはじめたら自分のライブラリをお気に入り楽曲として登録する機能があるんですね。登録するとライブラリの中身を反映していい感じのプレイリストを作ってくれるわけです。この機能には当然タグが使われるわけで、急遽「タグづけちゃんとしないとな……」という機運が高まりました。

おおまかな作業の流れ

  1. Add Folderからフォルダを適当に選択
  2. Unclustered Filesに曲がはいるのでClusterを押すと既存のタグ情報でアルバムごとに分類してくれる
  3. アルバムを選択したScanを押すとAcoustIDを計算し、別のペインに「マッチしそうなMusicBrainzのアルバムとその楽曲、マッチしそうな度合い(タグやAcoustIDのマッチ度から計算)
  4. その後検出情報を修正する。典型的には「ベストアルバムをスキャンする→複数のシングルとアルバムとして検出される→どれか1つの楽曲で検索して目当てのアルバムを指定→誤分類された楽曲を移動(アルバムからアルバムにまとめてできる)→トラックの誤割り当てがないか確認」
  5. Saveボタンを押してタグ書き込み

全部やるのに2日くらいかかりました。ずっとやってたわけじゃないけど7-8時間くらいかかった気がします。

誤検出は?

  • AcoustIDによる曲の誤検出はほぼ無い。5000曲くらいのアーカイブで作業して2,3曲くらい。むしろ厳しすぎて該当してるのにマッチしてくれない(false negative)のは300-400曲くらいあった。
  • アルバムを検出したあとアルバム内の楽曲にフィットするときにはタグ情報を加味して適当にあてはめてくれる。これはもとのタグ品質にもよるので間違い多数。もとのタグやファイル名を見て人間(=僕)ががんばってなおした。
  • そしてそれよりはるかに多いのは同じ楽曲が複数のアルバムやシングルに存在していて、想定と違うアルバムに分類されてしまうこと。あと限定版とかバージョン違いとか外国版とかもある(これはOther versionsというメニューで切り替えできる)。

MusicBrainzのDBも完全ではないのでもとのCDのデータがないケースではタグづけてきないことがあります。false negativeの可能性もあるのでここの確認をどれだけするかは悩ましいところ。アルバム10曲あれば1-2曲はヒットしてくれるので全くないときは『たぶんMusicBrainzに無い』ということにしてスルーしました。

MusicBrainz Picardのえらいところ

タグつけなおしのために考え抜かれて作られていることがわかる非常にいいソフトです。

  • もとのタグを利用したクラスタリング機能があるおかげで作業が大幅にはかどる。
  • アルバムで全曲フィットするとディスクのアイコンが金色表示されたり、マッチ率によりtrackのアイコンや背景色がかわる、変更される可能性があるタグを色づけするなど、人間が見るべきところを見つけやすくする工夫が随所にみられる。
  • 誤検出を前提にして 「Search for similar tracks...」というメタデータで探すメニューや、MusicBrainzのWebを参照する機能がある。
  • MusicBrainzで推定したアルバムが複数ある場合、アルバムからアルバムにドラッグ&ドロップすると適当に推定してtrackを割りあてなおしてくれる。自動割りあてできなかったtrackはUnmatched tracksのような分類で表示される。
  • 基本的にSaveしなければ他の操作でタグが変わることがない。探索的に使いやすい。
  • ステータスバーにtrackのファイル名が出るしダブルクリックで詳細がでる。タグをちゃんとつけてなくてファイルの場所から推定するしかないときにとても便利。

オチ

デジタルでしか音楽買わない世代うらやま。

Nature Remoを買ったメモ

導入のきっかけ

このQiita記事を読んで「あ、ぼくもやりたい」と思ったので年末にポチってNature Remoを導入した。モニタリング好きなんですよね。

qiita.com

12月31日に注文して1月1日に到着しました。たしかにヨドバシのサイトには1月1日って書いてたけど、持ってきてくれた郵便局の人に申し訳ない感。"いそがなくていい便"がほしいすな……。

赤外線操作の家電を登録

Nature Remoを買ったからにはウリの赤外線リモコン操作したいんで設定しました。2個だけですけど。

エアコンはすんなり認識、基本機能はカバーされているのでまあOK。 よく使う「ダッシュ」ボタンがなかったけど、リモコンから学習させてボタンを追加することはできないみたい。別のデバイスとして見せればなんとかはなるかもしれない。

  • 扇風機 (ZEPEAL ゼピール DFT-A3409 )

扇風機はその他の機器扱い。電源on/offがトグルスイッチなので「offにする」と言ってもonになったりする。自動化に不向きだけどon/off明示的に分かれてたり状態管理してそうな扇風機のリモコンって見たことないなあ……。

注意点としては、電源ボタンを登録するときにアイコンを「Google Assistant対応のアイコン」から選ぶこと。「全てのアイコン」から選ぶとGoogle homeなどからデバイスの存在は見えるけど操作できない。

副作用

我が家ではTP-Linkのスイッチを1つ使ってディスプレイや机の電灯、電気ポットがつながっているテーブルタップの電源on/offをしている。今まで「OK Google、電源をいれて」「OK Google、電源を切って」と言って操作していたのですが、上記の設定をしたら扇風機もつくようになってしまった。

これからは「OK Google、机をオン」とかで生きていこう……。

設置場所

環境モニタリングが主な目的なので自分の体感に近いものを測定したい。ちょっと考慮して机の横においてあるカラーボックスに貼りつけることにした。普段座っている位置からも近いしリモコンもちゃんと届く。

f:id:mrwk:20200102110847j:plain

ダッシュボード

冒頭の記事にあったリビング環境監視ダッシュボードは詳細な手順のおかげであっけないほど簡単にできました。

GASの時間ベースのトリガー、1時間ごとが一番短い単位みたい。15分おきとかがよかったけどEnterprise版だとあったりするのかしら。(1/10修正: 「時間ベースのトリガー」とは別に「分ベースのトリガー」などがありごく普通に15分おきの設定できました。

Googleデータポータルのグラフ、カスタマイズの範囲がめちゃくちゃ狭いのでExcelみたいなのを期待して作り込みしたい人にはきびしいかも。でもちゃっちゃとダッシュボード作るという点では良いバランスな気がする。

f:id:mrwk:20200102112417p:plain

「Linuxデスクトップ元年」から20年経った

僕にとってはLinuxデスクトップ元年は学部4回生だった1999年あたりにきて、一瞬(研究室でMacbookを買ってもらって結局firefox+emacs+端末しか触らなくなったという)浮気した時期があったものの20年ほど主なデスクトップ環境としてはLinuxだけを使う生活をしています。

たまにバグレポートをするくらいで積極的に開発に参加しているわけではない身ですが、いろいろなものが順当に進化しているなと思っています。

あとこれは僕がたまたまそうなだけで一般的には言えない話なのですが、仕事でLinuxに詳しくなったのがそのまま日常生活に有益だし、その反対もあるのでLinuxデスクトップすごくいいです。日常でちょっとハマッた時に仕事の知見がつかえるのはかなりお得感があります。

ちょうど2019年も今日で終わりですので、僕の記憶からここ20年くらいのLinuxデスクトップについての思い出や感想をつらつら書いていきます。裏をとらずに記憶や気分で書くので間違いも多いかと思います。気になることがあればコメントください。

  • デスクトップ環境の大幅な進化

    • 20年前だとまだSolarisはCDEがデフォルトだった気がします。僕もfvwm2とか愛用してました。友人がビルドしたKDE 1を見て「すげーwindowsの真似すげー」って叫んだ日を覚えています。
    • GNOMERHELやSLES, Solarisの標準的なデスクトップ環境になって(人的に)強化され、3.x初期には機能劣化があったものの順当に成長して日常的に使って困ることはほとんどない環境になっています。
    • KDEは何回かトライしたのですが最近は触っていません。カスタマイズ沼は好きなんですがね……。
  • 綺麗なフォント

    • 良い日本語アウトラインフォントがなかったのが昔話になったの、本当にありがたいです。
    • IPAフォント関係者の皆様ありがとうございます。本当に助かりました。
    • Notoフォント関係者の皆様ありがとうございます。ウェイトもたくさんあって素晴らしいです。
  • StarOfficeOpenOfficeLibreOffice

    • 学生や前職のあいだはオフィススイートを使うことはほぼなくて、Red Hatに入社してから使うようになりました。StarOffice(日本では商標の関係でStarSuite)は機能はともかくクラッシュ頻度がやばかったですね。LibreOfficeになる前後あたりから本当にすごく良くなった気がします。
    • 直接関係ないですがRed Hat社内にはlibreoffice-list というメーリングリストがあって「このファイルがバグった。たすけてー」って投げられるの最強の福利厚生だと思ってます。
  • ブラウザ上で動くもの、ブラウザをベースとしたアプリケーションの進化と普及

    • これはLinuxデスクトップが良くなったという話ではないのですが、日常的に「ドキュメント書くのもメールもチャットもカレンダーもビデオ会議も他社サービスのコンソールも社内システムもみんなブラウザで1日ブラウザばっかり使ってた……」というような日が増えてきました。
    • LinuxにはFirefoxChromiumChromeもあるので「Safari/Edgeでの見た目を確認したい」というケースでなければ日常ほとんど困ることはありません。環境チェックが厳しいサイトはひっかかることがあるのですが、できればe-taxみたいに「警告はわかったけど強行する」みたいな選択肢がほしいです。
    • 2015〜17年ごろは Adobe flashのバージョン差異のため動作しないサイトを見ることがたまにありました。flashそのものが2020年に終わるということで現在ではこの問題も事実上なくなりつつあります。
  • systemdやNetworkManagerによる足回りの整備

    • systemdによる世界征服が順調に進んできた結果デスクトップ環境にも各種の恩恵があります。
    • サスペンド/ハイバネート/電源管理 の標準化
    • オンデマンドなサービス起動(systemd+udevでハードウェア挿抜によるサービス起動、systemdのsocket activationでサービス呼び出し時にはじめてサービス起動、など)
    • systemd-logindによるmulti-head環境対応
    • 多数の無線基地局の接続情報を管理しつつダイナミックに実際の設定を変更するNetworkManager
  • ソフトウェア開発環境としてのLinux地位向上

    • (Red Hatがリードできなかったのはくやしいですが、) Ubuntuが精力的にデスクトップ環境としての地位を固めていったおかげで「IaaS上ではLinux上で動作させるソフトウェアを開発するのに手元がWindows/Macじゃなくていいよね」という風にかわってきたように感じます。
    • 特にREST API叩きながらアレコレする時に、API提供する側のサンプルがsh+curlだったり、各種Public CloudサービスのドキュメントにLinux/Windows/Macの手順が併記されているのを見るとそのように思います。
    • JetBrainsのIDE群がLinuxに対応してるのも大きいですね。
  • Waylandがついにきそう

    • 長い、本当に長い開発期間を経て各種ディストリビューションでWaylandがデフォルトになっています。
    • まだスクリーンキャプチャあたりに過渡期感がありますが、既に一般的なデスクトップ用途ならWaylandの方がいいんじゃないかと思うようになっています。
  • かな漢字変換、入力メソッド

    • 僕自身は1996年くらいからずっとSKKを使っているのであまり何も困ってはいないのですが、mozcのメンテナンスが止まってしまい、日本語かな漢字変換が潤沢に提供されているとは言いにくい状態です。辞書のメンテナンスひとつとっても膨大な開発者の労力が必要なので、AndroidやChromiumOSなどの開発努力にのっかれるような工夫があるといいのかもと思ったりはします。
  • Steamによるゲーム

    • さすがにWindowsに勝てる気はしませんが、20年前には思いもしなかったほど状況がよくなりました。
    • ValveのSteamがLinux対応したことと、ゲームエンジンLinux対応も進んでいるおかげでかなり大量のゲームが存在します。昨日もOxygen Not IncludedやFaster than lightで遊びました。
  • flatpak, snapdなどによる配布

    • Linuxにはさまざまなディストリビューションがあり、間違いなくLinux利用者にはよいことなのですが、デスクトップアプリケーションを開発する側からみると「それぞれのパッケージング技術、ポリシー、リリースタイミング、現在のライブラリバージョンなどがバラバラなのに対応するのは大変しんどい」という点が大きな問題です。
    • ArchのAURや、Gentooなどのようにユーザが自前でビルドするのだと割りきってしまえればいいのですが個人的には選んでダウンロードしてすぐ使いたいです。
    • flatpak, snapdなどコンテナ技術を参考にした配布方式が登場したことで、ディストリビューションのパッケージや、新旧バージョンの競合を心配せずに複数ディストリビューションへ対応したバイナリを配る基盤がととのいつつあります。
    • 間にディストリビューションが介在しないこのモデルは、ユーザがサポート窓口などを必要とする場合にはうまくマッチしませんが、upstream開発者とエンドユーザの距離が近くなること自体は最新版へのフィードバックが増えることに繋がります。エンドユーザむけ掲示板などとの組み合わせでうまい形で広まるといいなと思っています。
  • オンラインサービス・デバイスとの連携

    • ブラウザ上で各種の操作ができるのはいいのですが、オンラインサービスと連携して動作する点は不安のあるところです。
    • たとえばGNOME Online AccountsではGoogle, Facebook, Microsoft, Nextcloudなどとの連携が可能で Google DriveをNetwork Driveのように扱うこともできますが、数えきれないほど沢山あるオンラインサービス(の内デスクトップと連携できるといいもの)から考えるとほんのわずかです。
    • またデバイスも、wacom製以外のペンタブレットでは設定ツールがないなど対応が手薄です。
    • オンラインサービス・デバイス側に十分なモチベーションがない限りこの手の問題は解決しませんので、たくさんのユーザに使ってもらい、シェアをとっていく活動は大事です。

来年こそみんなにとってのLinuxデスクトップ元年がきますように (-人-)

Red Hat Enterprise Linux 8 の嬉しいところ

Red Hat Forum Tokyo 2019の資料です。

Red Hat Enterprise Linux 8 の概要と、おおきく3つのトピック「VM,コンテナでのテプロイ」「運用管理」「新しいOSSやサービスの利用」の側面でRed Hat Enterprise Linux 8がどう良くなったかを紹介します

RED HAT FORUMS Red Hat Enterprise Linux 8 の嬉しいところ Kazuo Moriwaka Solution Architect 2019-11-15 GENERAL Distribution 概要 2 ● Red Hat Enterprise Linux 8 の概要 ● VM, コンテナでのデプロイを簡単に行いたい ● 運用管理を簡単にしたい ● 新しい OSS やサービスを活用したい Red Hat Enterprise Linux 8 概要 GENERAL Distribution Red Hat Enterprise Linux 8 Red Hat のエンタープライズ向け OS の最新版 Fedora 28 をベースに開発 リリース日 2019 年 5 月 7 日 8.0 リリース (RHEL7 の GA から 4 年 11 ヶ月ぶり ) 2019 年 11 月 5 日 8.1 リリース (RHEL 8.0 から約 6 ヶ月 ) ほとんどのコンポーネントを 10 年間サポート 2029 年 5 月末まで 一部のコンポーネントは独自のライフサイクルが定義される ハードウェアパートナー SILICON OEM IHV RED HAT ENTERPRISE LINUX 8 認定クラウドパートナー 6 GENERAL Distribution パフォーマンスの向上 GENERAL Distribution セキュリティの強化 TLS 1.3 サポート 脆弱な暗号化スイートやプロトコルの排除 SSL v3 や、 OpenSSH での古いプロトコルなどはビルド時に排除 システム全体の暗号化ポリシー設定 プロファイルの選択により複数の暗号化ライブラリとアプリ群をまとめて設定 自動チェックリスト SCAP Security Guide の更新 PCI DSS (Payment Card Industry Data Security Standard) 3.2.1 へ対応 OSPP (Operating System Protection Profile) 4.2 へ対応 GENERAL Distribution ライフサイクルの変更 ほとんどのコンポーネントを 2029 年 5 月までサポート ※ 一部コンポーネントは 2 〜 5 年の短期サポート 5 年間のフルサポート、 5 年間のメンテナンスサポート ELS の提供を GA 時に宣言 (RHEL 史上初 ) VM, コンテナでのデプロイを 簡単に行いたい GENERAL Distribution 背景 従来 : インストーラを中心とした RHEL のデプロイ技術 kickstart install や Red Hat Satellite も含めて、 RHEL のデプロイはインス トーラ (anaconda) を中心として整備されてきた。 仮想マシンイメージ、コンテナイメージによるデプロイ 仮想マシンやコンテナではイメージを配布する手法が一般的。 RHEL 8 はイメージ配布時の問題を解決 GENERAL Distribution 仮想マシンイメージによるデプロイ 従来 : 仮想マシンイメージの作成が大変 標準仮想マシンイメージは配布されていたものの「独自イメージの作成手順」は存在 しなかった RHEL 7 から : Image Builder を提供開始 ただし Technology PreviewRHEL 7.7 からフルサポート開始。 RHEL 8 では : Image Builder がサポート対象、 Web Console での UI 提供 AWS, Azure, GCP, Alibaba Cloud 用の仮想マシンイメージ作成にも対応 GENERAL Distribution 仮想マシンイメージに対する設定 RHEL7 から : RHEL System Roles 従来 kickstart 内で設定していた設定を Ansible で実施 ● selinux ● kdump ● network ● timesync ● storage (8.1 から提供 ) GENERAL Distribution コンテナイメージによるデプロイ 従来 : RHEL の base image は第三者に配布できない RHEL 6, RHEL 7 の base image は提供されているが、契約上第三者への配布や公開は 不可。一部の ISV だけが Red Hat Container Catalog 経由で配布。 Universal Base Image を基盤とするソフトウェアの配布 ● ● ● ● UBI は RHEL (7, 8) をもとにしたコンテナ base image と、ライブラリなどの一部 パッケージを提供するリポジトリからなる。 RHEL のサブセットですが費用はかからず、再配布についても制約はなし。 アプリケーションを追加して公開・再配布をおこなえる。 (RHEL のパッケージを 導入した場合には不可 ) Red Hat のコンテナ基盤上で実行する場合は、 UBI についても Red Hat によるサ ポートの対象となる。 GENERAL Distribution つまり…… VM をデプロイしたい → Image Builder で仮想マシンイメージ作ってデプロイできる ! コンテナでデプロイしたい →UBI で「 ISV 製品△△のコンテナイメージをとってきて RHEL(OpenShift) で実 行」が簡単にできる基盤がととのった ! 運用管理を簡単にしたい GENERAL Distribution 背景 システムの多機能・複雑化 新しい機能に気付かない → 使ってもらえない 多くの運用管理者は Linux だけに集中できない 運用管理が本業でない人 ( ソフトウェア開発者など ) による利用 ● 運用管理者は Windows や各種 IaaS, SaaS なども担当 → 簡易に利用したい・継続的な知識のアップデートがむずかしい ● GENERAL Distribution Web Console でシステムをリモート管理 ブラウザ UI での管理 ホストのセキュリティ機構を 活用したリモート管理を提供 標準的な技術を利用 独自のものではなく標準的な 管理技術を活用 GENERAL Distribution Red Hat Insights SaaS 形式のシステム診断サービス RHEL (6,7,8) や RHEL をベースとする各種製品で 追加費用なく利用できる 設定の問題や統計情報など多様な 項目をチェック Red Hat のナレッジをもとにルールを作成・維持 多数のマシンを定期的にチェックして レポート。具体的な対策をガイド 対応できるものは Ansible playbook を自動生成 GENERAL Distribution つまり…… GUI で運用したい ( でも X Server 立てるのは面倒 ) → Web ブラウザ上で従来 GUI で管理できたことはほとんどできる ! 知識のアップデートをしつづけるのが大変 → 最新の知見を反映した Insights でアドバイスします ! 新しい OSS やサービスを活用 したい GENERAL Distribution 背景 新しいパッケージを必要とするソフトウェアやサービス ● ● ● ● ● Ruby on Rails 6.0 Drupal 8 Angular 8 Wordpress GitHub → Ruby 2.5.0 以降 → PHP 7.1 以降 → node.js 10.9.0 以降 → PHP 5.6.20 以降 → git 2.0 以降 標準的なパッケージでないと使いづらい ● ● 従来提供していた Software Collections ではディレクトリ配置が標準的でない ため、利用しづらいケースが発生していた Software Collections 自体の知名度が低く、あまり使われていなかった GENERAL Distribution リリース頻度 マイナーリリースを 6 ヶ月おきに出荷 GENERAL Distribution Application Streams 複数バージョンを並行して提供 PostgreSQL 12 stream PostgreSQL 10 stream PostgreSQL 9.6 stream Red Hat® Enterprise Linux® 8 RHEL から独立したライフサイクルで、 同一ソフトウェアの複数バージョンを提供 順次新バージョンを提供 マイナーリリース時に新しい安定版を追加 標準的な配置 標準的なディレクトリレイアウトで利用 しやすい GENERAL Distribution Application Stream Retirement Date Application Stream Retirement Date authd 1.4.4 2021-05 openjdk 1.8.0 2023-06 container-tools 1.0 2021-05 openjdk 11 2024-10 dotnet 2.1 2021-08 perl 5.24 2021-05 git 2.18 2021-05 php 7.2 2021-05 httpd 2.4 2024-05 postgresql 10 2024-05 Identity Management DL1 2024-05 postgresql 9.6 2021-11 mariadb 10.3 2023-05 python 2.7 2024-06 maven 3.5 2022-05 redis 5 2022-05 mercurial 4.8 2022-05 ruby 2.5 2021-02 mysql 8 2023-04 scala 2.1 2022-05 nginx 1.14 2021-05 swig 3 2022-05 nodejs 10 2021-04 varnish 6 2022-05 GENERAL Distribution つまり…… ○○ を使うためには△△のバージョン x.y 以上が必要 → RHEL 8 のフルサポート中なら、新しいバージョンを並行して提供 ! Red Hat Software Collections って何 ? → 全部 RHEL の中に入っているので見つけやすい ! まとめ GENERAL Distribution Red Hat Enterprise Linux 8 いつも通りのところも、大きく変わったところもあります VM, コンテナでのデプロイを簡単に行いたい Image Builder や UBI で簡単に ! 運用管理を簡単にしたい Web Console で GUI 操作による管理、 Insights で知見も提供 新しい OSS やサービスを活用したい 進歩が早い主要なソフトウェアに対して、新しい安定バージョンを順次出荷 GENERAL Distribution 早速ためしてみよう RHEL 8 の新機能を試すオンラインラボ https://lab.redhat.com/ ブースで展示中。ログインなども不要で手軽 ! Red Hat Developer Program https://developers.redhat.com/ 個人ソフトウェア開発用サブスクリプション ドキュメントから入りたい人は 「 RHEL 8 の導入における検討事項」で検索。 RHEL7 からの違いがまとまっています RED HAT FORUMS THANK YOU linkedin.com/company/RedHat facebook.com/RedHatAPAC youtube.com/user/ RedHatAPAC twitter.com/Red_Hat_APAC