結城です。このブログでは2018年に、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方と、Phabricatorというツールを使ってコードレビューを受ける手順を紹介しました。2026年現在では、既定のバージョン管理システムがMercurialからGitに移行した他、Phabricatorを使うためのツールのインストール手順が簡素化され、Firefoxへパッチを提供するためのハードルが以前よりも低くなっています。この記事では、Firefoxへの不具合報告の仕方の解説と不具合の原因調査および修正の仕方の解説に続くシリーズ完結編として、2026年の状況に基づいてFirefoxに不具合を修正するパッチを提供する手順をご紹介します。報告の流れ（おさらい）前々回記事・前回記事の冒頭において、オープンソース開発プロジェクトへの外部からの関わり方として以下の3段階がある旨を述べました。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち3の部分について、2022年に筆者が実際に報告し2025年末に解決となったBug 1762249の事例を参考にして説明します。この記事では、「WindowsでのFirefoxのビルド手順の解説に従ってFirefoxのリポジトリーをローカルにcloneしていて、そのリポジトリー上で修正のための変更を行ったけれどもまだcommitはしていない」という状況から説明を始めています。「どのような不具合だったか」については前々回記事で、「どのように修正したか」は前回記事で詳しく説明しているので、背景を知りたい方はまず前々回記事からご覧下さい。修正を提案する前回記事では、自分が報告したFirefoxの不具合について、原因を突き止め、実装の修正を手元で行ってみました。実装を修正して、回帰テストも用意できたら、いよいよ修正の提案です。本稿執筆時点では、Firefoxのソースコードの中央リポジトリーはGitHub上のGitリポジトリーとなっています1。しかし、不具合の報告の受け付けにGitHubのイシュートラッカーではなくBMO（bugzilla.mozilla.org）という別の仕組みが使われているのと同様、修正提案の受け付けやコードレビューにも、GitHubのプル

結城です。このブログでは過去何度か、FirefoxやThunderbirdの不具合の原因調査や修正の事例をご紹介してきました。ですが、原因の見つけ方や修正方針の検討の詳細な所はあまり言語化してきていなかったように思われます。この記事では、Firefoxへの不具合報告の仕方の解説の続編として、Firefoxを使用していて遭遇した不具合の原因を特定し、経緯や事情を調査して適切な修正内容をまとめる所までの詳細な流れをご紹介します。報告の流れ（おさらい）前回記事の冒頭において、オープンソース開発プロジェクトへの外部からの関わり方として以下の3段階がある旨を述べました。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち2の部分について、2022年に筆者が実際に報告し2025年末に解決となったBug 1762249の事例を参考にして説明します。「どのような不具合だったか」については前回記事で詳しく説明しているので、この記事から読もうとしている方は、まず前回記事からご覧下さい。不具合の原因箇所を特定する前回記事で詳述しましたが、この事例では、問題の発生時にFirefoxがJavaScriptの例外を投げています。端的には、この例外の出所がまさに「修正が必要な箇所」と言えます。ただ、今回発生している例外はアドオンからは「Error: An unexpected error occurred（エラー：予期しないエラーが発生しました）」という抽象的なメッセージを伴った物としてしか捕捉できていません。about:debugging から開けるアドオン用のデバッグツールのコンソールで▸をクリックしてログを展開しても、例外がセキュリティ境界をまたいで通知されている1せいで、スタックトレースは得られていません。このような場合、Firefox本体のエラーコンソール（Ctrl-Shift-J）でヒントを得られることがあります。FirefoxのWebExtensions APIはほぼすべてJavaScriptで実装されており、Firefox自体のデバッグツールであれば、Firefox内で生じた例外の詳細な情報を閲覧できます。今回の事例でも、Firefoxのエラーコンソールにはスタックトレースを伴った例外の情報が出力されていました2。Failed to

結城です。Firefoxを開発しているMozillaプロジェクトでは、ソースコードのバージョン管理システムをMercurialからGitに移行し、GitHubでホスティングしていく方針が2023年に示されました。その後、実際に移行が進んで、本稿執筆時点（2026年1月）ではソースコードの入手はGitHubのリポジトリーから行うのが規定となっています。その一方で、不具合報告の受け付け・管理のためのイシュートラッカーとしては、GitHubのイシュートラッカーではなく、Mozillaプロジェクト専用のイシュートラッカーであるbugzilla.mozilla.org（以下、BMO）が依然使われています1。このブログでは、Firefoxの不具合を修正したり新機能を追加したりといったコントリビューションを行う際のパッチの作り方を2018年に紹介しましたが、当時の記事は既に誰かによって報告された不具合へのパッチ提出が前提で、自分が見つけた不具合を報告する場面の説明は含まれていませんでした。パッチ提出の流れには当時と比べ変化があったため、その点を紹介する記事を執筆したいのですが、まずはその前段階として、この記事では具体的な事例を参照しつつ、BMOを用いたFirefoxの不具合報告の仕方をご紹介します。報告の流れ一般的に、コントリビューションを広く募っているオープンソース開発プロジェクトでは、プロジェクト外の人がソフトウェアの不具合に遭遇したときに、プロジェクトの問題を解決する方法として以下の3段階の関わり方が可能です。不具合を報告する。原因を調査して明らかにする。不具合を修正するパッチを提供する。本記事では、このうち1の部分について、2022年2に筆者が実際に報告したBug 1762249の事例を参考にして説明します。報告したい問題の詳細を明らかにする多くの場合、ソフトウェアを使っていて問題に遭遇したときには、まず「変だ！」「動かない！」「困った！」と感じるものでしょう。ただ、それをそのまま「なんか変なんだけど！」とだけ報告しても、解決には繋がりません。解決に繋がるように報告するためには、「自分が遭遇した問題がどういう問題なのか」を自分で調べて明らかにして、ソフトウェアの開発者の側でも把握できるように説明する必要があります。Bug 1762249の時は、筆者が作成したFirefox

ソフトウェアエンジニアの阿部です。最近、OpenArmというハードウェアに触る機会があったので、それに関連する記事です。OpenArmはロボットアームです。公式サイトに動画もあるのでご覧いただければどのようなモノかすぐにわかると思います。実物が手元にあっていろいろいじれるととても楽しいと思うのですが、今のところ実物が手元にないのでROS2というものでシミュレーションしてOpenArmに触れあってみた記録です。対象読者私はソフトウェアエンジニアでハードウェアのことはまったく経験なしです。普段パソコンは使うので、CPUとかメモリとかくらいの部品は知っていますが、ロボットアームやそれを構成している金属部品、モーターについてはまったく経験なしです。そんなスキルセットの私の経験談の記事なので、ソフトウェアエンジニアでLinuxの基本的な操作はできつつ、ロボットアームについては何も知らないけど興味はある！という方の参考になると思います。はじめにOpenArmはオープンソースのロボットアームです。操作するためのソフトウェアに加えて、ロボットアームを構成する部品の設計もすべて公開されています。各リポジトリ: https://github.com/enactic/openarm私はいろいろ触れ合ったので、ある程度用語の意味がわかりますが、ロボットアームの経験がない方は初見の用語が多くて親しみにくいかもしれません。本記事はすべてを理解するための解説記事ではなく、「とりあえずシミュレーションが動く」を体験することを目的にするので、用語の説明は最低限にとどめます。説明の足りないところがあるかもしれませんが、その点はご了承ください。ロボットアーム関連の用語ROS2ROSはRobot Operating Systemの略です。今回の記事を読む上では「ROS2」は「ロボットを制御するときに使う便利なソフトウェア」くらいの理解で大丈夫です。参考: https://docs.ros.org/en/kilted/index.htmlMoveIt2「MoveIt2」はROS2上で動くロボットアームの動作計画などの作成を支援するフレームワークです。ロボットアームを上げて下げる、とか一連の流れを便利に作れます。ROS2をOSとすると、MoveIt2はその上で動く便利ソフトという位置付けです。参考: http

OSS開発に参加する人を継続的に増やしていくプロジェクトOSS Gateをやっている須藤です。2026-02-13（金）にOSS Gateワークショップを東京でオフライン開催することになったのでそのお知らせです！オフライン開催OSS Gateでは「まだOSSの開発に参加したことがない人」向けのワークショップも開催しています。前はオフラインで開催していたのですが、新型コロナウィルス以降はオンライン開催が主流になりました。一般的に、オンライン開催は地域を問わずに参加できるというメリットがありますが、オフライン開催に比べて人と人のつながりを強めにくい傾向があるようです。OSS Gateでは、「まだOSSの開発に参加したことがない人」が「参加したことがある人」になって、その人が新しい「まだOSSの開発に参加したことがない人」をサポートして「参加したことがある人」にして、というようにOSS Gateに関わる人も増えることでより多くの「OSS開発に参加する人」を継続的に増やしていきたいと思っています。そのため、一度参加した人のうちできるだけ多くの人がなんらかの形で継続的にOSS Gateに関わって欲しいです。オフライン開催がその助けになるといいなぁと思って東京でオフライン開催をすることにしました。会場提供はオプティムさんオフライン開催をするには会場が必要なのですが、今回はオプティムさんが提供してくれることになりました。オプティムさんとはcsv gemのissueで知り合いました。詳細はオプティムさんのブログを読んでもらうとして、これがきっかけでRailsTokyo #1【ブルーモ証券：みんなの投資から学べる本格米国株資産運用】で声をかけてもらいました。話を聞いたところ、社内の開発者が、自分たちが使っているOSSの開発に自分たちのアプリケーションと同じように参加する組織にしていきたいということでした。クリアコードはOSS開発支援サービスとしてそのような組織を有償でサポートするサービスも提供していますが、会場を提供してくれて社外の人も参加可にしてくれるならOSS Gateワークショップを無償で開催しますよ！と提案しました。ということで、（オプティムのみなさんを優先的に参加できるようにしますが）それ以外の人も参加できます！平日開催また、今回は「平日」に開催することにしました。いつもは

結城です。このブログではこれまで、2015年と2017年にWindowsでのFirefoxの独自ビルドの作成方法をご紹介しました。本稿執筆時点では、既定のバージョン管理システムがMercurialからGitに移行していたり、MozillaBuildやブートストラップスクリプトによる自動初期化の仕組みが進歩していたりして、また状況が変わっています。この記事では、2026年1月現在においてWindows用のNightlyおよびFirefox ESR140の独自ビルドを作成する手順をご紹介します。はじめにこの記事では話を簡単にするために、Firefoxの動作の解析のためにログ出力を増やしたり、Firefoxの不具合を修正するためのパッチの有効性を実際の動作で確認したりといった、開発や検証を目的とする場合を想定することにします。また、Firefoxの法人向けサポートサービスを提供している当社においては、Firefox ESR版の運用時に遭遇したトラブルについて、原因調査や回避策の検討のためにデバッグ用ビルドを顧客環境で実行して頂く場合があるため、最終的にはその範囲にも言及します。この記事では以下の3段階に分けて、それぞれのビルド手順を順番に解説していきます。英語版Nightly Artifact Modeビルド（HTML/XML、JavaScript、CSSなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）英語版Nightly フルビルド（C++、Rustなどで実装されている箇所の変更の検証、または、それらの箇所へのログ出力追加による詳細なデバッグ用）日本語版Firefox ESR140 フルビルド（日本語版を常用している顧客の環境でのデバッグ用）情報のありかFirefoxのビルドに関する情報は、本稿執筆時点ではFirefox Source DocsというサイトのGetting Set Up To Work On The Firefox Codebaseというセクションから辿ることができます。Windowsでのビルドなら、Building Firefox On Windowsを見ることになります1。基本的には、このオフィシャルの情報のとおりにやればつつがなくFirefoxをビルドできます。本記事では、オフィシャルの情報ではカバ

fat gemはやめた方がよいと思っている須藤です。やめた方がよいとは思っているのですが、どうやらfat gemが欲しい人はいなくならなそうなので、メンテナンス可能なfat gemエコシステム案を考えています。なお、この文章を書いているのは https://github.com/ruby/rubygems/issues に英語で提案するために考えを整理したいからです。整理したら英語で提案します。fat gemで実現したいこと・避けたいことfat gemに期待されているのは次のことです。インストール時間の短縮（ビルドせずにコピーするだけだから）プロダクション環境へビルドツールをインストールしない（セキュリティの強化とストレージ容量の削減）fat gemを実現するにあたり、避けたいことは次のことです。gem開発者のメンテナンスコストが上がる新しいCRubyで使えるようになるまでにラグがある依存ライブラリーが脆弱性に対応してもfat gemが対応してくれないと対応できない（fat gem内に依存ライブラリーが含まれているため）複数のfat gemが同じ依存ライブラリーの違うバージョンを使っているとコンフリクトすることがある既存のパッケージ管理システムから学べることRubyGemsのfat gemやPythonのwheelなどバイナリーパッケージを使えるパッケージ管理システムはすでにいくつもあります。これらからできるだけ学んでよりよい仕組みを設計したいです。Python: wheel: Pythonバージョンタグで新しいPythonへの対応は楽にならないRubyGemsやwheelにはパッケージに「タグ」というメタ情報を含めることができ、ユーザーがどのパッケージを使うかの判断材料として使われています。RubyGemsはタグの中にRubyのバージョンは含まれていないので、1つのパッケージ内に対応しているすべてのRubyのバージョン用のバイナリーを含める必要があります。つまり、Ruby 3.2から3.4に対応しているけど、Ruby 4.0には対応していないパッケージをすでにリリースしていたら、同じバージョンでRuby 4.0にも対応したパッケージをリリースすることはできません。すでに同じタグのパッケージがあってコンフリクトするからです。（Improve precompiled

RailsTokyo#2【sponsored by 株式会社タイミー】でActive Record ADBC adapterを紹介しつつRailsアプリで活用できそうかどうかを聞いてきた須藤です。 Active Record ADBC adapter 関連リンク：スライド（Rabbit Slide Show）リポジトリー目的私はいろんな分野でRubyを使えるといいなぁと思っているので、Red Data ToolsというRuby用のデータ処理ツールを提供するプロジェクトをやっています。その一環としてRailsアプリで便利かもしれないActive Record ADBC adapterを作ったのですが、私はほとんどRailsアプリを書かないので本当に便利なのかがわかりません。ということで、Railsアプリを書いている人たちが集まっているRailsTokyo#2【sponsored by 株式会社タイミー】で紹介してRailsアプリ開発者のみなさんから便利そうかを聞いてみました。便利そうなのか普通にRailsアプリを書いている分には必要なさそうでした。ただ、いくつかのユースケースでは便利になる可能性がありそうでした。RDBMSではなくオブジェクトストレージにApache ParquetやCSVでデータを集めているケースでは便利になりそうです。ADBC経由でDuckDBを使ってオブジェクトストレージから高速にデータを取得できるからです。Google BigQueryを使っているケースでも便利になりそうです。現状では、Google BigQueryに大量データを高速に入れるためにはRailsアプリとは別にツールやミドルウェアを整備しないといけないそうですが、それがActive Recordのレイヤーで実現できると管理対象が減るからです。外部のBIツールにサマリーデータを提供するところでも便利になりそうですが、各種BIツール向けのADBCドライバーが整備されてからじゃないとそんなに便利にならなそうです。jokerさんからはいろいろ参考になる話を聞けました。ありがとうございました！RailsTokyoのことはhahondaさんに教えてもらいました。助かりました！まとめこれまで集めていた情報だとそんなに便利じゃなさそうな気がしてきていたのですが、便利そうなケースもありそうでした。G

RailwayでPGroongaのテンプレートを公開した児玉です。この記事では、まずRailwayについて簡単に紹介し、その後PGroongaテンプレートの使い方を説明します。最後に実際の利用例として、Redmine全文検索プラグインを利用したRedmineをRailway上で動かすデモを用意しました。RailwayとはRailwayは、アプリケーションのデプロイからデータベース管理、スケーリングまでを一元的に扱えるクラウドプラットフォームです。GitHubやDocker Imageを利用したデプロイに対応しており、PostgreSQLやMySQLなどのデータベースも簡単にデプロイして利用できます。特徴的なのは、テンプレート機能です。テンプレートを利用することで、事前に構成されたサービスをボタン一つでデプロイできます。今回公開したPGroongaのテンプレートもこの仕組みを利用しています。補足: PGroongaは日本語や中国語などの言語に対応した全文検索をPostgreSQLで実現する拡張機能です。詳しく知りたい方は、こちらをみてください。（この記事では、PGroongaがインストールされたPostgreSQLのことを「PGroonga」と呼びます。）それでは、実際にPGroongaテンプレートを使って、Railway上にPGroongaをデプロイしてみましょう。PGroongaテンプレートの利用PGroongaをRailway上で手軽に試せるテンプレートを利用します。このテンプレートを使うと、数クリックでPGroongaをRailway上にデプロイできます。PGroongaテンプレート以下では、実際のデプロイ手順を紹介します。デプロイ手順0. Railwayのアカウントを作成するRailwayにアクセスしてアカウントを作成します。GitHubアカウントを利用すると、一瞬でアカウントを作成できるのでオススメです。1. PGroongaテンプレートのデプロイアカウントを作成したら、実際にPGroongaのテンプレートを利用してデプロイします。PGroongaテンプレートにアクセスします。画面右上のDeploy Nowをクリックしてください。テンプレートの設定画面に移ります。2. テンプレートの設定テンプレートの設定画面では、利用するDocker Imageやマウント

2025年12月19日にLTS版 Fluent Package v5.0.9をリリースしました。Fluent Package v5 LTSは2025年末までのサポートを予定しており、Fluent Package v5.0.9はv5 LTSの最後のバージョンとなります。本記事では、Fluent Package v5.0.9の変更内容を紹介します。Fluent Package v5.0.9Fluent Package v5.0.9では、以下の改善を行いました。同梱のFluentdをv1.16.10からv1.16.11に更新この記事では、Fluent Package v5.0.9の主な変更点を詳しく解説します。変更内容の詳細同梱のFluentdをv1.16.10からv1.16.11に更新Fluentd v1.16.11では以下の修正が含まれています。out_forward: 不安定なネットワーク環境下でTLSを使用した場合に特定の条件下で出力が停止する問題を修正不安定なネットワーク環境下において、TLS確立後のforwardプラグインの接続処理中に通信が途絶えた場合、out_forward の接続処理が無限ループに陥り、ログの出力が停止してしまう問題がありました。既存の hard_timeout パラメータの設定値をこの接続処理にも適用し、タイムアウトによって処理を中断・復旧できる仕組みを導入しました。関連リンクFluent Packageダウンロードインストールガイドまとめ今回は、Fluent Package v5.0.9のリリース情報をお届けしました。本リリースでは、長期運用環境での安定稼働を支える修正を実施しました。Fluent Package v5 LTSは2025年末までのサポートを予定しています。スケジュールの詳細については公式サイトをご確認ください。ユーザーの皆さまには、Fluent Package v6 LTSへのアップデートもご検討くださると幸いです。日本コミュニティ向けのXアカウントをはじめました。日々、Fluentdに関する情報を発信しております。ぜひ @fluentd_jp をフォローしてください！

PostgreSQLで高速に全文検索するための拡張PGroongaの開発をしている堀本です。突然ですが、日本語には踊り字というものがあります。久々の"々"とか、こゝろの"ゝ"とか、前の文字を繰り返す記号のことです。現代の文書でも見かけますが、古い文書でも多用されています。「久々」は、「久々」と検索しそうですが、「こゝろ」は「こころ」で検索したくなります。このような表記ゆれを統一して検索したいというのは、よくある問題です。最近よく聞くセマンティックサーチもこの問題を解決するための一つの手段ですが、正規化するというのも一つの解決手段です。少し前にGroonga(PGroongaのバックエンドで動いている全文検索エンジン)に踊り字を正規化する機能を追加したので、PGroongaでそれを使う方法を紹介します。前提知識最初に正規化の説明をします。正規化とは、ある一定のルールで文字列を変換することです。今回の例だと、「こゝろ」のような踊り字が混じった文字列を「こころ」という踊り字なしの文字列に変換することを正規化といいます。次に、踊り字の説明をします。踊り字にはいくつかのパターンがあります。「久々（久久）」、「こゝろ（こころ）」、「ぶゞ漬け（ぶぶ漬け）」などの、直前の一文字を繰り返すパターン。部分々々（部分部分）のように直前の複数文字を繰り返すパターン。古々々米（古古古米）のように直前の一文字を複数回繰り返すパターン。今のPGroonga（Groonga）は1のみ対応していて、2,3は対応していません。具体的には以下の踊り字に対応しています。々 (U+3005)ゝ (U+309D)ヽ (U+30FD)ゞ (U+309E)ヾ (U+30FE)〻 (U+303B)したがって、例えば「こゝろ」を「こころ」でも「こゝろ」でも検索できますし、「バナヽ」を「バナナ」でも「バナヽ」でも検索できます。古い文書のような踊り字がよく出てくる文書に対する検索で便利な機能です。ただし、前述した通り2,3に該当する以下の2点は未対応です。「〱 (U+3031)」と「〲 (U+3032)」(くの字点)々と〻で「直前1文字の繰り返し」以外のパターン。(例えば、"部分々々" -> "部分部分"には対応していません。)使い方では、どのように使うかを見てみましょう。以下のように使います。ポイントはCREATE I

MySQL, MariaDB, Percona Serverで高速に全文検索するためのストレージエンジンMroongaのメンテナンスをしている堀本です。Mroonga 15.21をリリースしました！直近のリリースが2025-09-30なので、2ヶ月ぶりのリリースです。今回のリリースでは、Debian 13とMariaDB 11.8を新たにサポートしました。Debian 13は2025-08-09に、MariaDB 11.8は2025-06-08にリリースされました。Debian 13は数ヶ月、MariaDB 11.8に至ってはサポートに半年かかってしまいました。。。がんばってサポートしたので、この記事では、Debian 13とMariaDB 11.8のサポートに時間がかかった理由を紹介しようと思います。時間がかかった理由なぜ、時間がかかったのかですが、Debian 13については簡単で、MariaDB 11.8の対応に時間がかかったからです。Debian 13が提供するMariaDBのバージョンは11.8です。そのため、MroongaがMariaDB 11.8で使えるようにならないと、Debian 13でMariaDB + Mroongaの組み合わせでMroongaを使えません。よって、MariaDB 11.8をサポートすればDebian 13向けのパッケージもリリースできることになります。しかし、MariaDB 11.8のサポートに時間がかかったため、Debian 13のサポートにも時間がかかったというわけです。では、MariaDB 11.8のサポートに時間がかかった理由を見ていきましょう。通常、新しいMariaDBがリリースされた時は、最新版のMariaDBを使ってMroongaをビルドし直すだけで、新しいバージョンのMariaDBに対応できます。ただ、MariaDBはバージョンアップの際にストレージエンジンに提供しているAPIを変更することがあります。（結構、頻繁に変更します。）このAPIの変更に追従しないと、Mroongaのビルドに失敗しパッケージを作ることができず、リリースできなくなります。そのため、新しいバージョンでAPIが変更された場合、その変更に追従するための改良をMroongaに入れることになりますが、変更の内容によっては、原因を突き止めるのが難し

これはRuby/Rails Advent Calendar 2025の9日目の記事です。Red Data Toolsをやっている須藤です。pure RubyでApache Arrowの実装を作ることにしたのですが、Apache Arrowの実装に必要なFlatBuffersがRubyをサポートしていなかったのでそこから作っています。FlatBuffersはパースなしでデータにアクセスできるシリアライゼーションフォーマットです。たとえば、"[10, "hello", true]"というようにJSONにシリアライズした場合は、文字列の"10"をパースして数値の10にしないとデータを使うことはできませんが、FlatBuffersではそんなことをしなくてもデータを使うことができるということです。FlatBuffersを使う場合は、まずスキーマを定義して、そのスキーマから各種プログラミング言語のソースコードを生成します。その生成されたソースコードを使うと、対象のスキーマ向けにシリアライズされたFlatBuffersデータにアクセスできます。ソースコードを生成するプログラムはC++で実装されているので、Rubyのソースコードを生成するモジュールをC++で実装したのですが、レビューもマージもされなそうな気がするので、pure RubyでFlatBuffersの処理系（FlatBuffersのスキーマからそれを処理するRubyのソースコードを出力するプログラム）を作ることにしました。それがRed FlatBuffersです。Red FlatBuffersはとみたさんが紹介していたIO::Bufferを使っているので、どう使っているのかを紹介します。ちなみに、Red FlatBuffersを作り始める直前くらいにFlatBuffers「も」処理できるUnibufが公開されていましたが、StringIO#readしてからString#unpack1するとか無駄なコピーをしていそうだったのでRed FlatBuffersを作ることにしました。io::buffer">Red FlatBuffersとIO::BufferFlatBuffersのウリはパースなしでデータを使えることです。パースなしで使えるということは、暗黙的にゼロコピーという性質もついてきます。Rubyで「パースなしでゼロコピ

組み込みLinuxでは、ターゲットとなるOSをビルドするためのYoctoレシピが提供されていることがあります。そのような事例では、広く公開されているレシピをベースに、企業が独自に追加の修正を施したレシピを適用するということが行われたりします。今回は、そのようなYoctoのレシピをISAR向けに移植することになったときにはまらないためのヒントをいくつか紹介します。（Yoctoレシピにはある程度慣れているが、Debianパッケージにはあまり慣れていない人が対象です。）ISARとはYoctoのレシピは（提供元が異なっていても）ソースコードにパッチを積み重ねてビルドすることができたりするので、カスタマイズ性が高いという特長があります。その一方で、発覚した脆弱性にタイムリーに追従していきたい場合など、利用者自身によるメンテナンスコストが高くならざるを得ないという一面もあります。上記のような問題を解決する方法のひとつに、Debianのようなバイナリパッケージを配布しているディストリビューションの成果物と、Yoctoのレシピをカスタマイズしてビルドした成果物を組み合わせるというやりかたがあります。ISARは、そのようなやりかたを実現することのできるソフトウェアの1つです。ISARを利用すると、大部分のソフトウェアはDebianが提供するものを利用し、DebianになかったりするものだけYoctoのレシピを移植して使うということができます。Debianの成果物と組み合わせる場合には、長期サポート（LTS）で5年、さらにELTSを利用すると10年のサポートが得られるので、（組み込み製品にとって）Debian由来のものはそちらのアップデートを利用しつつ、独自にカスタマイズした部分のメンテナンスに注力できるというメリットがあります。また、Debianのパッケージを一部カスタマイズして採用するということもできます。ISARの利用者は、使い慣れたbitbakeコマンドを使って、パッケージをビルドしたり、OSのイメージを作成したりできます。実際にISARを採用している事例としては、EMLinuxがあります。1ISAR向け移植時のヒントISARはYoctoのレシピをベースに動作しますが、いわゆるソースディストリビューションとバイナリディストリビューションという異なるエコシステムをつなぎあわせて動

弊社では組み込みLinux機器向けのソフトウェア開発案件を承っておりますが、その一環でAOSP（Android Open Source Project）のカスタマイズについても実績があります。今回は、社内向け備忘録の意味も込めて、AOSPエミュレーターイメージのカスタマイズ方法について説明します。ビルド環境の用意まず、AOSPビルド用のOSを用意します。UbuntuのLTS版を使用するのが無難です。参考: https://source.android.com/docs/setup/start/requirementsUbuntu 24.04 LTS等の環境を用意し、以下コマンドにてビルド用のツールチェーンをインストールします。$ sudo apt update$ sudo apt install git-core gnupg flex bison build-essential zip curl zlib1g-dev libc6-dev-i386 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig repoAOSPエミュレーターイメージのビルド最初に、ベースとなるAOSPのエミュレーターイメージをビルドします。AOSP 14をビルドするコマンド実行例を以下に示します。$ mkdir ~/aosp14$ cd ~/aosp14$ repo init --partial-clone --no-use-superproject -b android-14.0.0_r67 -u https://android.googlesource.com/platform/manifest$ repo sync$ source build/envsetup.sh$ lunch sdk_tablet_x86_64-ap2a-userdebug$ m$ m emu_img_zipエミュレーターイメージは以下に生成されます。$ ls out/target/product/emu64x/sdk-repo-linux-system-images.zip out/target/product/emu64x/sdk-repo-linux-system-imag