openSUSE + LibreOffice virtual conference 2020参加の感想（その２：技術・実装）
表題のイベントの感想、その２。今回は技術・実装編。
繰り返しますが、「イベントレポート」ではなく、つまり各トークの内容を紹介するものではなく、 背景とか前提とか、 聞きながら私が思ったり感じたりしたことを書き出す……というのが、この記事の趣旨です。 ちゃんと内容知りたい方は動画・資料の公開待った方がいいと思いまする。
この記事は全３回予定です。
- その１：LibreOfficeプロジェクトとコミュニティ
- その２：技術・実装
- その３：移行など・その３：その他（openSUSE関係、全体の感想）
ワークショップなど
How to debug Writer, forwards and backwards / by Michael Stahl / 2020 October 16 - 16:00
これめちゃんこよかったです！
Writerの、けっこうめんどくさいバグを解析する様子をscreencastで録画したやつに、 解説の音声をかぶせたビデオをみんなで見つつ、チャット欄で質問してMichaelが答えてくれるという趣向。
とはいえ私LibOの開発もLinux上のデバッグもWriterの実装もあんまり把握してないので、ここで共有されていた知見の半分も理解できていた自信がない。皆さんは追って公開されるであろうビデオを参照ください。ここでは軽く箇条書き。
- 追ってた問題はこれ。Bug 134253 - CRASH: undoing field paste
- ちょっと複雑なWriter文書をCtrl-Aで全選択して、Ctrl-Cでコピーして、再度ペーストして（クリップボードの内容にあるもとと同じ内容で上書きされることになる）、それをUndoするとクラッシュするという問題
- 使っていたのはrr。gdbのPythonによるフロントエンド。
- rrにはrcってコマンドがあってreverse continue。死んだところから逆再生をしてくれる（？）。ほかにも逆ステップ実行とかあって猛烈に強力。
- rrはIntel CPUでしか動かなかったけどちょっと前にAMD CPUで動くパッチがマージされたので今は動くかも、とのこと。ちょっと不安定なこともあってrcしたりすると死んだりもするけど、動けばめちゃくちゃ強力なので使いましょうと
- QAチームのXiscoが「デバッグにかかる前に再現データ小さくしたりしないの？」と質問したところ、「順実行と逆実行、あと条件付きブレークポイントを駆使してポイントを絞っていくほうが早い」とのMichaelの言
- rr上での配列やリストの表示は最大表示個数を設定できるんだけど、表示個数10000とかにしちゃって、rrのログ機能をONにしといてそのログをテキストエディタで開いてそっちで確認するとなると、文書オブジェクトみたいなデカい構造オブジェクトを見やすくなる
- 今回の場合はUndoの前後でノードが消えてて？位置がずれてて？、それを知らないやつが元のノードを参照しようとして落ちてたというのが表層的に起きてたこと
- その現象をもとに怪しいコードを順逆実行などで詰めていく
- 怪しい場所を見つけたら
git log -pで差分を追いかけるとそのコードがどのコミットで（どういう意図で）入ったか確認できる
とにかく非常に面白かったのですがこっちの理解がおぼつかない＆くそ眠かったので、ビデオ公開されたらまた見直したいです。チャット欄も何とかして保全されてねーかな、あれも後で参照したい……。
あとこういうの見ちゃうとやっぱWindowsじゃなくてLinux上で開発したくなりますね。Visual Studioじゃこんなに柔軟なデバッグできないよ、ね……？
LibreOffice Virtual Hackfest / by Ilmari Lauhakangas / 2020 October 17 - 14:00
担当のIlmariはTDFの「開発マーケティング」担当で、要は新しい開発者に対するメンタリングをしたり、 開発やQAで活発に活動してる人を一本釣りして「こういう活動してみない？」って言ったり、 そういう役割の人。ちょういい人でもあります。 本人はC++あんまりできないことを気にしてるらしいと聞いたことがあるけど、どの言語が書けるとか書けないとかではなく、メンターとして優れてると思います。
で、通常LibOConはHackNightっていう合同ハックイベントをやるんですけど、 今年はできないので、1時間のワークショップをしましょうと。で、これもまた非常によかった。
これも箇条書きで。
- お題は「bibisect」「バグのトリアージ方法について」「ヘルプの作成について」「その他質疑応答」
- bibisectは「binary bisect」ってことで、要はLibOのデイリービルドをGitリポジトリに突っ込んだものがあって、それを用いてgit bisectして「どのデイリービルドで不具合が混入したか」を調べること
- bibisectのやり方を説明するビデオを作ってくれたのでみんなでそれを見ました。このビデオ非常に分かりやすくてよかった。あとで↑のWikiにも貼るよ、とのことでした
- ついでバグトリアージ。つまり誰かが起票されたバグをチェックして、その先開発者が解決に取り組めるような状態にすること
- トリアージの最初はまず重複（dup）を見る。同じバグを別の人が報告してないか
- タイトルや詳細説明を見て、象徴的な単語を拾って検索して探す。同義語なんかも考慮する
- 見つからない場合はOPEN以外のステータス、あるいはResolutionをすべて
---にするなど - あるいはうんと単語数を絞って、後ろから（最近出たバグから）順にみていくのも効果的
- DUPの場合はそれぞれのバグを見比べて「より良い」方を残す。「良い」というのは、条件を不要に限定しすぎていないってことも見る
- 例えば「サイドバーでこんな不具合がある」という報告であったとき、別の報告で「メニューバーでもサイドバーでも不具合がある」とあったら、そっちのほうが条件が広いので
- DUPとして落とすべきバグ票は、Whiteboardがあったら消して「Status」を「RESOLVED/DUPLICATE」にして、残すべきバグ票の番号を記載して閉じる
- 昔は動いてたんだけど……というたぐいのバグはキーワードにregressionとbibisectRequestedをつけておく。bibisectはあとで自分でやってもいいし、このキーワードついてたら誰かやってくれるかも
- あとBugzillaのAdvanced Searchのコツをいくつか紹介してもらいましたが、この手のノウハウはBZ使ってる他のOSSプロジェクトとも共有できそうな気がします
- お次はヘルプ。LibOのヘルプはXHPという形式で書かれてます。
- XHPのオーサリングには専用のオンラインエディタ LibreOffice Documentation XHP Editor があるので使おう、構文チェックとかできて便利。CLIでgit触らなくてもコミットできます
- 基本的な情報はWikiにある。入り口 -> XHPの文法など
- LibOのソース検索システム opengrok を使って既存のヘルプを検索するのもいい
- 最後に質疑応答
- Q: 直したい問題があったときにコードのポインタをどうやって知ればいい？
- A: opengrok でももちろん良いが、ローカルにコードがあるなら git grep するのが早い
- コメント: 似たような問題を git log で探して、その修正コミットを参照するのもよい
なおバグトリアージについては、イベントでメンターしてほしかったらタイムゾーン的に無理がない範囲でやるから連絡ちょうだいね、というIlmariのメッセージがありました。
Implementation Detail / by Stephan Bergmann / 2020 October 16 - 15:00
全然ワークショップじゃないのだけどLibreOfficeの特定のコンポーネントについての話ではないのでここで紹介。新しいC++で入った言語機能と、それをLibOのコードでどう使えるかって話。
Stephenは毎年、LibOConではこの手の話をしてくれて、門外漢にもとても分かりやすいし面白くて非常に楽しみです。むしろファンだと言ってもいい。
ここも理解おぼつかないので箇条書きでごまかす。
- 今のLibOは基本C++17。structured bindingとか色々使えます
- ただしC++20、C++23対応を進めて行ってるよというステージらしい
- ちょっと横入ですが、私の理解するところでは、LibreOfficeのC++バージョンはしばしばツールチェーンのサポート状況で決まります。 Linuxはだいたい問題ないのですが、Visual Studio（MSVC++）とXcodeがですね。 前者は今のmasterはllvmでビルドするようになったからあんまり問題ないのかしら。後者は「Old ｍacOSで実行可能なバイナリは古いXcodeでしか生成できない」問題がありますね。 なので古いmacOSをサポートから落とさないとコンパイラのバージョンも上げられない。
- さらに横道ですが前提として cpprefjp - C++日本語リファレンス でC++の各標準間の新機能をおさえてからこのトークに臨めばよかったなーとちょっと後悔
- すごい雑駁な理解だと C++20 だとコンパイル時評価がさらに進んだのでそれを使うと記述スッキリできるしいろいろよいよという話
- 例として挙げられていたのはLibOの文字列を表現するクラス
OUStringとそのリテラルOUStringLiteral OUStringは内部的にはrtl_uStringへのポインタで、rtl_uStringは参照カウンタと文字数（？バイト数？どっちだろ）とNUL終端の文字列ががっちゃんこしたもの- こいつのリテラルからの生成をコンパイル時評価使うといいよ、みたいな話だった気がする
- 一見for文でループぐるぐる回りながら値をコピーしてるっぽいコードがコンパイル時評価で実はループ回してるわけじゃないんだよ（きもっ）とか
- さらに
constevalでstd::copy_n()が使えるようになりさらに可読性アップ……とか、そんな話だったと思うのだけど、間違えてたらすみません - 質問で「それビルド遅くならない？」「なるねえ」みたいな話がありました。LibOのビルド、いまでも十分遅いからな……
Google Summer of Code 2020 Panel / 2020 October 16 - 14:30
GSoCの成果発表。残念ながら前と後ろが押して、Yusuf Ketenさんの、拡張機能を追加するためのダイアログAdditions Dialogだけ聞きました。
いままで拡張機能って専用の差異とに行って *.oxt 入手してそれをLibOの拡張機能マネージャーで開いて追加する……って、かなりめんどくさい手順だったのが、
今回はLibOから直接ダイアログ開いて追加できる……これはすばらしいですね。次期メジャーリリース 7.1 で入るみたいです。
LibOコア関係
Implementing Vulkan-capable drawing using the Skia library / by Luboš Luňák / 2020 October 15 - 14:00
7.0のリリースノートにさりげなく書いてあるこの一文：
この説明をするトークです。実は私はSkiaとVulkanの関係性も理解してないぐらい、この件よくわかってなかったので、ちょうどよいなーと。
- LibOのウィジェット描画抽象化レイヤとしてはこれまでVCL（Visual Class Library）があって
- このVCLのバックエンドに各プラットフォーム別の実装がある
- VCL自体1990年から使われておりいろいろつらみが
- 俺たちはオフィスソフトの開発者であってグラフィックライブラリの開発者じゃねーんだよ
- より広く使われており信頼性の高いライブラリを用いてVCLの層を薄くしたい
- そこでSkia。GoogleがChromeのために開発した2Dグラフィックライブラリ
- Skia自身にいくつかのバックエンド実装があって、その中でGPUを用いるものがVulkan
- ほかにもCPUで頑張るやつや、OpenGLを用いる実装なんかもあるそうな
- ということでVCLのバックエンドとしてSkiaを用いるようにして、Windowsでは（元々のOpenGLを自分たちで叩く実装の代わりに）それを標準にしたよ、というのが現状
- VCLは設計が古いためI/Fも古く、1bppやパレット付きビットマップなどSkiaでは直接提供されていないものを扱う必要があるため、そこは適切に変換する
- グラフィック操作をVCLに任せるのではなくよりハイレイヤー（LibOのコード内）で行っている場合があり、そういう部分を対応する必要があった
- ただしOpenGL化のときにある程度は見直せており、その成果がある程度は使えた
- パフォーマンス。Linuxにおいて、Raster Skia（Vulkanではなく）であっても、非Skia（X11）では非常に高速になった
- デモを見ると確かに非常に速い
- 疑問）7.0ではいくつかCJKのレンダリングがおかしくなったという問題があるらしくSkiaをオフにすると直るという話だが、今回の説明だとVCLのバックエンドを差し替えただけなのでそういう問題が起きるというのは若干考えにくい。途中コメントがあったハイレイヤーとの不適切な責務分担のせいかな……？
OOXML / PDF Digital Signing in Draw and elsewhere / by Miklos Vajna / 2020 October 16 - 11:30
コロナ禍で注目されている文書の電子署名に関するLibOの機能について。
- ODF署名：OOoのころからある機能。だいぶ古い。GPG署名とは別の機能
- OOXML署名は、名前の通りMS OfficeがOOXMLに対して署名する機能の互換性のために導入。なぜか署名情報に画面解像度とかOSバージョンとかの情報が露出する
- PDF署名はもちろんPDFの仕様にのっとった署名だが、LibOが持つ三つのPDFパーサーは全部これが解釈できない（Popplerベース、PDFium、Hybrid PDFのためのもの）ので、さらにもう一個実装が必要
- multiple signaturesは証明書チェーンの検証が必要でちょっと面倒
- PDFの仕様以外に、アプリケーションとしてのAcrobatと動作を合わせないといけない部分がありつらかった
- 意味が分からないなりに目盛ったキーワード：XML-DSig（昔LibOConで聞いた記憶がある）、DocuSign （https://www.docusign.jp/ だよね）、libxmlsec（実装で使ってるらしい）
ここ注目度が高い技術なのと、私の本業にも近いのでもう少しちゃんと勉強しないとなと思った次第でございました……。
LibreOffice Online / Collabora Office mobile関係
Making Online trivial to setup / by Muhammet Kara / 2020 October 15 - 15:30
トルコのLibO開発者Muhammet Karaさん。トルコ国内でHackFestを実施したり、若手技術者育成なんかにも力を注いでるナイスガイです*1。
さておき、LibreOfficeをブラウザベースで使えるLibreOffice Online（通称LOOL）。あるいはそのCollaboraブランドCollabora Online（COOL）。便利ですが構築はやや大変でした。 商用利用ならコストかけて真面目に構築してもいいけど、個人用にひょいっと立てるには若干ハードルが高かったのも事実。
それが、なんとなんと、OSSのDropboxクローンであるNextcloud*2のアプリ（プラグイン的なもの）である「Collabora Online」
を使うと、NextcloudのWeb UIからワンクリックで（COOLが）インストールできるようになっちゃったんですね*3。その技術解説。
……なんですけど、このときすでにだいぶ眠くってね……あんまりちゃんと聞き取れませんでした。以下「たぶん」って内容を箇条書き。
- ワンクリックで入るCOOLはAppImage化されたもの
- 通常LOOL/COOLとクライアントアプリはWebSocketで（WOPIというプロトコルを用いて）しゃべるのだけどAppImageだとWebSocketがしゃべれない（……んだと、思う）
- なのでPHPでプロキシプロセスを立てて、WSじゃなくてHTTPSで通信してる
- HTTPSだとWSでつなぎっぱなしにしてバイナリなプロトコルでやり取りするのにくらべ、TLSのセッション確立およびHTTPヘッダの分下駄を履いてしまうのでパフォーマンスがつらい
- なので可能な限りセッションを維持する工夫をしている
- 一部ではどうしてもポーリングしないといけないところがあり（理由失念）、そのチューニングも頑張っている
ちょっと理解おぼつかなかったところもあるので、こいつも資料後で読み返すなりして復習したいです。 スライドに丁寧に参考文献が挙げてあったと記憶してるので。
History of Online & Mobile / by Jan Holesovsky / 2020 October 17 - 12:00
KendyことJan Holesovsky氏の発表は名前の通り、主にCollaboraが今注力してるオンラインとモバイルの歴史について。
- 2011～2012年の時点でSUSE社内でAndroidでLibOを動かすという実験プロジェクトがあった。「まあ動く」程度のものはできたが、死ぬほど遅いとかデバッグが人類には不可能とかいろいろあった
- 大きな転機は2013年、CloudOnという会社が「OOXMLのiOSビューアのエンジンとして」LibOを使いたいという要求があって、そのために（SUSEから離れたメンバーが創設したばかりの）Collabora Productivityが協力することに
- この時生まれたのがLibreOfficeKit（LOKit）、LibOのエンジンを直接キックするC/C++のライブラリ
- メモリ制約が厳しいモバイルOSのために「タイルレンダリング」が導入される。つまりLibOの文書のレンダリング結果をビットマップタイルにして得るという方法
- これであれば画面に表示される部分のタイルだけを扱えばよくなりメモリ使用量が大幅に削減される
- ここ、私の歴史認識が違って、てっきりLOOLが先にあって、LOOLのために作ったタイルレンダリングをモバイルでも使うよという話だったのかと思ってたけど逆なんですね
- CloudOnのアプリは確かクローズドベータは出て、公開ベータするよってなったところでDropBoxに会社ごと買われてしまいました。多分まるごとPapersのチームに吸収されたんだと思います
- CloudOnが買収されなかった未来はどうなってたんでしょうねえ……歴史にでもしかはありませんが
- で、この2015年にIceWarpという会社の投資を受けてLOOLの開発スタート、このときにLOKitで作ったタイルをLeafletで並べて描画するという基礎ができる
- なぜだか知らないけどLibOにはクラウドやモバイルが存在する前からmultiple view機能というものが存在して（正直、使い道不明……）、そいつがLOOLの共同編集に使えた
- LOOLは共同で使うアプリなので設定ダイアログも複数人が設定いじることを考えなければならず、当然LibOのコアはそんな考慮されてないのでいろいろつぶしていった、ここらへんは過去のLibOConでいろいろ発表がありました
- そして2019年、Adfinis SyGroup AGの投資を受けてCollabora Officeのモバイル版開発がスタート、去年のLibOConでも発表があったとおり「アプリのサブプロセスとしてLOOLサーバーを動かして、アプリの実体はWebViewでLOOLのUIを出す」という実装
- モバイルだとタッチ主導UIである必要があるが、それを担うのが「サイドバー」。デスクトップ版と見た目異なるが提供するものは一緒。この点については今年Bringing the Sidebars Online という発表があったのでそっち参照
- モバイルで必要なUIをすべて実現するにはUNO APIだけだと足りず、一部は（エンドツーエンドテスト用の）untest APIを使って実現したとか
- 今後はleaflet/poco依存を減らしたいなどと言っていたのがちょっと気になりますね
技術的にめっちゃ踏み込んでるわけじゃなくて歴史をさらったお話なのでわたくしのような薄い人間にもわかりやすくてよかったです（小学生みたいな感想）。
Online – Improving visual consistency / by Pedro Silva / 2020 October 17 - 13:00
これはですね……うーん、ちょっと思っていた内容と違いました。自分的に面白いと思ったところだけ：
- Pedro Silva氏はCollaboraのデザイナーさん。デザイナーさんだけあってスライドのデザインはカッチョよかった
- 肝心の「Visual consistencyとはなんぞや」みたいなことは実はいまいち理解できなかったけど、いろんなトピックがあるみたい
- 例えばCSS。Consistentyを保つためにはファイルをまたいで冗長な部分があってはいけない（全体を統一的に直したいときに、一部コピペされたところが直ってなかったとかつらい）とか、特定解像度を仮定したコーディングがあったらだめだとか
- 徹底するために https://stylelint.io/ でlint。きちんと除外ルールを整備。それで
make runするたびにチェックする仕組みを作る。すばらしい - 使い勝手がよいだけではなく実装もきれいになっていることが大事。これ開発とUI/UX設計の距離が近くないと難しいよね
- Collabora Office for Mobileでは可能だろうけど、LibOの開発にこういうやり方ができるかというとどうなんだろ。どういうやり方があるんだろ
- 後半はどっちかというとメタな考え方の話で正直聞いてて眠かったです……あとCOOLの宣伝が長い……
- 「モバイルアプリなのに保存アイコンがフロッピーなのはvisual consistentなの？」みたいな質問が出て、なんかいろいろ長々と答えてたけど、どうにも言い訳してるようにしか聞こえなかったのが若干残念（私のヒアリング能力のせいで、ちゃんと答えてた可能性はあります）。フロッピーはダメだとしたらどういうものが保存を意味するのにふさわしいかって考えが知りたかった
- アプリによっては右上にチェックマークってやつもあるけどアレもあんまりわかりやすくないよね身たいな話はあったようななかったような
- 保存なんて考えるのは平成までだよねー、自動保存が当然じゃない？って考えもありえるのかなあ……
Improvements to PDF support in Collabora Online / by Tomaž Vajngerl / 2020 October 16 - 18:00
LOOL / COOLでPDFインポートを強化したよというタイトル通りのお話。
- DrawのPDFインポート機能はPopplerベース。インポートしたものが編集可能になるというのはメリットだけど、一方で正確性に難がある。応用によっては編集可能性よりも正確さが嬉しいこともある
- そんなわけで正確性を重んじて、挿入されたPDF画像の処理はPDFiumという別のライブラリ（Chrome/Chromiumが使っている奴）を用いるようにしている
- この件については2018年のLibOConで発表があったのでそれを見るか、解説したブログ記事を読みましょう
- LOOL/COOLではDrawは機能としてないので、PDFインポートはビューアとしての機能になり、基本PDFiumを用いてるけど、単なるビューアとしても機能は必要でそれを追加したという話
- 足りない機能というのは、検索機能と注釈（annotation）機能
- 検索については、PDFiumの内部オブジェクトはレンダリング後のグラフィックオブジェクト以外にPDF自体をメモリ上に持ってるのでそれを使って検索できる
- 検索結果の位置を矩形で取り出すAPIも生えているので、それを用いて結果表示可能
- PDFの注釈機能はテキストだけじゃなくていろんなものにつけられるけどまずはテキストへの注釈を実装し、そのあと描画オブジェクトにも実装……とか言ってた気がする
- ここらへんでメモがぷっつりと切れてました……
Open Document Format (ODF)
ODFは言わずと知れたLibreOfficeのネイティブフォーマット。詳しくは過去に記事書いた*4 のでよかったらそちらを参照してください。
ODF state of the union - ODF 1.3 ante portas / by Thorsten Behrens / 2020 October 15 - 15:00
ODF 1.3はOASISの委員会勧告になって今ISO/IEC標準化を目指してるけど、そういう現状が聞けるかなというトーク。 ただ、このときJitsi meet bombをくらって発表がめっちゃ大変そうで、私もそっちに気を取られてあんまり聞けてないですね……。
なので一点だけ。ODF 1.3に続いてODF Nextという取り組みが始まってるんだけど、 そっちでは標準の編集そのものをCI化する（実はぴんと来てないけどODFの標準は文書で記載された定義とXMLのスキーマとの両方なので後者のことを言ってるのかな） 、 メールベースの議論ではなくGitHubに持っていく、とかそういう取り組みが話されていて、技術で解決できる物事は技術で解決して、 標準策定までのリードタイムを短縮しようという試みはよいなと思いました*5。
ODFについては、Svante Schubert氏の：
という発表もあって、聞きに行った記録は残ってるんだけど内容についてまったく残ってない……どういうことだ自分。ごめんなさい。 お詫びにODF ToolkitのURL貼っておきますので関心のある人はどぞ。
マクロ・機能拡張・その他
« LibreOffice Python scripting made simple w/ IDE_utils » - Dev/Doc tracks / by Alain Romedenne / 2020 October 17 - 10:00
@LibreOfficiant ことAlainさんによるLibreOfficeのPythonによるマクロ開発のセッション。
ASPOっていうLibreOfficeのPythonマクロ統合開発環境の説明が興味深かったですね。
こいつについては去年のLibOConでも @LibreOfficiant さんのトークで名前知ってたんですが、 LibOのBasicの開発環境程度なんじゃないの？ と勝手な偏見を持ってあんまりちゃんとチェックしてなかったんですよね。 でもビルトインされたPython consoleでLibOの内部コンテキストと同じ状態を作っていろいろ試せたりするみたいで、 なんというかJavaデコーディングするときにもIntellij IDEAでブレークポイントで止めた状態でインスペクタでコード片を書いて動きを確認つつコードを書いてる私には、 結構いいかも……と思いました。
LibOのPythonマクロもずっと宿題なので、今度真面目に触ってみますかね。
LibreOffice Document Encryption API / by Vasily Melenchuk / 2020 October 17 - 12:30
機密性を保って文書交換したい場合、PPAPはイヤですよね。かといってLibOの機能でパスワードロックかけたとしても、パスワードは人類に使いこなすのは難しすぎるのです。 強度も弱いし、パスワード漏洩しちゃうと無力だし、あれこれ……。
なのでCMISとかNextcloudとかGoogle Driveとかの機能を使いたいねとなるわけですが、そんなあなたにRights Management Services = RMS*6。
そのRMSの対応をする拡張機能を作ったよという話っぽいです。 モチベーションとしてはRMSでロックされたOOXMLを読めるようになりたいという。 MSの仕様をもとに暗号化された文書を解釈できるようにして、 実装上はUNOのXPackageEncryptionインターフェースを拡張する……みたいな話に聞こえました（雑）。
Windowsでしか動かないけどサンプルの拡張機能ここにあるそうです。興味がある人はどぞ。
Windowsでしか動かないのはMSがSDKをWindowsでしかリリースしてないから？という質問に対して、いやマルチプラットフォームで存在するはず、と答えてましたが、 じゃあなんでWindowsでしか動かないんだろう……ソース見ろって？
Remotely accessing files in a distributed LDAP+Samba-based infrastructure / by Marco Marinello / 2020 October 17 - 10:30
イタリアで複数の学校をつないで、各学校に所属する人たちが、公衆網から接続して安全に自分の学校のSambaファイルサーバーにアクセスできる仕組みをつくったよ……という話らしいです。 FUSSプロジェクトというGNO/Linuxベースのシステムの一環らしい。イタリア語読めないですが……。
クラウドサービスでも使えばいいのになんでこういうの独自に実装するのというと、それはやっぱりGDPR的というか、自分たちの情報は自分たちでセルフホストしないとってことらしい。 ヨーロッパはここら辺やっぱセンシティブなんですねえ。
それはともかく発表者のMarco Marinello氏はなんと19歳！ 19歳でこんなプロジェクトにかかわって国際イベントで登壇してるんだ。すごいな。
LibreOffice AppImages: Past, present and future / by Simon Peter, Antonio Faccioli / 2020 October 16 - 19:00
AppImageはLinuxにおけるパッケージングシステムの一つで、普通に単独のファイルとして配布されてて、手元に持ってきて実行権限つけるだけで実行可能になるというもの。 特にQA作業で古いバージョンをちょっと動かしたいみたいなときに超便利です。
で、私は単にAppImageの単なるユーザーだったんで中身のことはさっぱり知らんのですけど、このプレゼンでそこらへん説明があったので資料公開されたらもっかい読もうっていうのと、
ここにAppImage版LibOのビルドスクリプトがあるので眺めてみようと思います。
近々の機能としてはAppImageに閉じ込められたLibOをアップデートする機能、しかもGUIの「更新を確認」が機能するというのはなかなかよいなと。 古いバージョン塩漬けじゃなくて、AppImageで最新追いかけたいってニーズもあるかもわかんないですからね。
それと最後に、FreeBSDの上でLinux版AppImageが普通に動いてるという驚きのスクショが公開されてビビりました。そんなことできるんだ……すごいな。
……ということで
その２、終わりです。最後は力尽きて駆け足になってしまいました。というか十分すぎるほど長いですしね、この記事……。
つづきはその３です。今日拾えなかったトピックをまとめて。ではまた。
*1:関係ないけど彼と私と榎さんで飲んだときに、「いやー日本人面白いなー」ってやたら言ってもらったのを覚えてます。いや、たぶん私（や榎さん）は典型的な日本人じゃないよ……。
*3:Nextcloudのオフィス文書共同編集ソリューションにはOnlyOfficeというやつもあり、こっちはPure JavaScript実装なのでサーバー側の手当てが不要で、その手軽さで好まれたりしてて、巻き返しのために簡単インストールが必要だったんじゃないかな……と、想像。
*4:関係ないけど、編集可能なリッチテキストを表現するフォーマットとして、正しい意味で「国際標準」であるものとしては唯一のものであるODFを、イギリスや台湾に倣って日本でも政府が用いる標準フォーマットにしましょうという提案が、デジタル改革アイデアボックスに出ています（その１・その２）。よろしければぜひ、「賛成」をポチっとしてください。
*5:アプリケーションの都合でどんどん仕様追加されているのに、標準側は本質的でないTypo修正しかしてないどっかの標準に爪の垢を煎じて飲ませたいですね。
*6:ここらへん参照でしょうか： RMS の動作のしくみ | Microsoft Docs
