2026/09/06更新
R1/beta6 – Release Notesの私訳です。訳のおかしいところは原文を参照ください。

R1/beta6 – リリースノート

Haikuは、ほとんどボランティアからなる小さなチームで開発されています。純正のコンポーネントでは、‘AI’で生成されたコードや材料は使用していません。我々の、パーソナルコンピューティングをターゲットとしたオープンソースデスクトップオペレーティングシステムを創るミッションが魅力的に聞こえるなら、参加を検討してください!

Haiku R1 6番目のベータ版は、ちょうどHaikuの25周年記念の1週間後に登場しました。プロジェクトが2001年の4半世紀前に始まってから長い道のりを歩んできました。これまで私たちを支えてくれてありがとうございます。そしてこれからのHaikuの25年も!

本リリースは、Haikuの機能と全体的な安定性の改良、およびより多くのソフトウェアを使えるようにするためのほぼ2年間の開発チームのハードワークを含んでいます。530を超えるバグおよび機能強化のチケットが本リリースで解決されました。

Haikuは、ベータ品質のソフトウェアであることを心に留めておいてください。つまり、機能は完成しているが既知や未知のバグがまだ含まれていることを意味します。安定性にはますます自信がありますが、データ損失に対して保証はできません。

今回のリリースサイクルのほとんどに、waddlesplashがHaikuで活動する契約者として雇用されました。皆様のような読者のHaiku, Inc., a 501(c)3 non-profitへの惜しみない寄付で彼の契約は現在も続いています。

Haikuのダウンロード、または以前のリリースからのアップグレードについて学ぶなら“Get Haiku!”を参照ください。プレスの問い合わせは、“プレス窓口”を参照ください。

システム要件

本リリースは、x86 32-bitおよび64-bitプラットフォームで利用できます。

最小構成(32-bit)

  • プロセッサー: Intel Pentium II; AMD Athlon
  • メモリ: 256MB
  • モニター: 800x600
  • ストレージ: 2GB

推奨構成(64-bit)

  • プロセッサー: Intel Core i3; AMD Phenom II
  • メモリー: 2GB
  • モニター: 1366x768
  • ストレージ: 16GB

新しい機能

Mozilla Firefox

R1/beta5リリースの数カ月後、最初のMozilla Firefoxコードベースで動くブラウザーがソフトウェアデポに登場しました。最初は大変バグが多く、公式のブランドも使っていませんでした。過去2年間で、より安定になりました(Haiku側および移植そのものへの作業のおかげで)。さらに最近、Mozillaが公式に“Firefox”ブランドを使う許可をくれました。そのため、“FirefoxはHaikuで動きますか?”と聞かれたら、"はい、動きます!"と答えられます。

Firefoxコードベースの様々な他のソフトウェアもHaikuDepotで利用できます。これには、LibreWolf, Waterfox, Floorp, Icedove(Thunderbirdのブランドを除いたバージョン)などを含みます。

(今のところ、Firefoxと派生物は現在x86_64用のみ利用できることに注意してください。また、Haikuはまだベータ品質のソフトウェアなので、Linuxや他のOS上のFirefoxと比べて欠けている機能や不十分な機能に遭遇した場合、それはおそらく私たちの責任でありMozillaの責任ではありません。そのような問題は、HaikuPortsへ報告すべきです。)

QEMU (x86_64)用のハードウェア仮想化

Haikuは“NVMM”、つまり NetBSD Virtual Machine Monitor (NetBSDを起源としますが、Haikuに移植される前に少なくともDragonFlyBSDに移植されています)をサポートしました。これは、Intel VT-xまたはAMD-Vをサポートするほとんどのx86_64システム上でQEMUへのハードウェア仮想化のサポートを提供します。それは、32-bitと 64-bitゲストの両方、SMP、幅広いQEMUのエミュレートするハードウェアとオプション、そして多くの様々な種類のゲストOSをサポートします。QEMUのコマンドライン引数に-accel nvmmを追加するだけです。

(NVMMアクセラレーションは多少実験段階であることに注意してください。遭遇した問題はバグトラッカーへ報告してください。)

移植されたソフトウェア

HaikuPortsプロジェクトは様々なソフトウェアのHaikuへの移植のメンテナンスを続けています。単純に新しい移植が多いので、すべてをここに記載することはできませんが(多くのKDEやGTKアプリケーションも含みます)、数ある中でも目立つものの一つを以下に記載します:

Go

プログラミング言語Goのコンパイラとランタイムの移植がパッケージリポジトリで利用できるようになりました。この移植は少し古く(1.26.1)、まだアップストリームのGoに統合を提出(submitted)していないことに注意してください。しかし、多くの機能やパッケージは、恐らく少しのパッチでHaiku上で動作することがすでに確認されています(Hugo、メインのHaikuウェブサイト自体で使われている静的サイト生成ツールを含みます)。

変更点&バグ修正

数百のバグやその他小さい問題、または機能拡張リクエストが前のリリースから解決されました。それらは多すぎてここにすべてを記載することができません(Monthly activity reportsは、変更のより完全な報告を含んでいます)。実際、システムのすべての領域がある程度の手当(attention)を受け取っており、その結果がHaikuのこれまででもっとも洗練され安定したリリースです。しかし、あちこちに粗削りのところが残っています。

全体的なパフォーマンス最適化

本リリースでは、パフォーマンスを向上するためにかなり多くの変更やリファクタがシステムの大部分にわたって行われました。以下にいくつかの(やや技術的な)ハイライトを記載します:

最後の2つは、git statusのような多くのファイルを立て続けにアクセスする動作に置いて特に劇的な効果がありました。これらの変更後の一つのテストで、160,000を超えるファイルがあるリポジトリ内でのgit statusは、コールドディスクキャッシュでは~33sから~20s、ホットキャッシュでは、~15sから ~2.5sまで下がりました!

コンパイルパフォーマンスにおける、これらすべての最適化の重複効果(加えて以下で詳しく述べるメモリ管理の変更)は、きわめて重大になりえます。比較的単純なコンパイルジョブでは、以前より少し速いぐらいですが(Linuxより約~40%遅い)、非常に複雑なコンパイルジョブでは大きく異なる動作をするでしょう。HaikuWebKitのフルリビルド(同じバージョン、同じコンパイラ、ほとんど同じな依存パッケージセット、同じビルドホスト)では、R1/beta5上で4h53m、R1/beta6上で2h33m掛かりました。ほぼ半分の減少です!

ユーザーインターフェースとユーザーエクスペリエンスの改良

Tracker: 修飾キーの変更によるメニューのライブ更新

Tracker、つまりHaikuのファイルマネージャーでは、多くの操作(または対応するショートカット)で、“Shift”キーの押し下げとともに呼び出された場合、挙動が異なります。今では、メニューが開いている間にShiftキーを押すか離せば、異なる挙動のメニューアクションは、実際に“Shiftを押された”アクションのように表示を変更するでしょう。

Tracker: フォルダーフィルタリングクエリ

Haikuが受け継いで発展させてきたBeOSのユニークな機能の一つが、拡張属性をサポートし、これらの属性をファイルシステムネイティブにインデックス化し、任意の“クエリ”をファイルシステム全体に走らせて特定の式にマッチするファイルを素早く見つけ出す“データベースのような”ファイルシステムです。

クエリ自体は、ファイルシステム全体(インデックスはパス情報を持たないため)を検索しますが、時々特定のディレクトリ内のファイルだけを見たいかもしれません。それを達成するために、Trackerはその“検索”ウィンドウでフォルダを選択できるようになりました。クエリの結果も指定されたフォルダ(またはサブフォルダ)からのファイルのみ表示するでしょう。

(コマンドラインのqueryツールもフォルダフィルタリングクエリの結果をサポートを受けられました。)

ソフトウェアの更新&pkgman: ディスククリーンアップ

Haikuパッケージは、実際にはブロック圧縮されたファイルシステムイメージです。システムのファイルシステム作成のため、起動時ごとにある種の“union”へマウントされます。これは、インストールやアンインストールが低コストであることを意味しています。なぜなら、それらは“union mount”からパッケージを追加または削除するだけだからです。そのため、変更を戻したい場合(または前の状態からブートしたい場合、ブートローダーから直接可能です)に備えて、システムは古いパッケージを“以前の状態”に保存できます。

以前は、そのような“以前の状態”は決して自動的にクリーンアップされませんでした(しかし、それらを管理するいくつかのサードパーティソフトはありました)、それらは無制限に溜まっていき、ますますディスクスペースを占めていきます。今では、ソフトウェアの更新はしばらく経った後に自動的に古い状態を削除します(しかし、設定で無効化できます)。pkgmanコマンドラインツールも多量の古い状態がある場合指摘を行い、それらを削除するためにpkgman cleanupを実行することを提案します。

# pkgman install/uninstall/full-sync...
[system] Changes applied. Old activation state backed up in "state_2026-08-22_22:38:28"
[system] Cleaning up ...
[system] Done.
[system] 3 old state(s) can be cleaned up. Use "pkgman cleanup" to remove them.

$ pkgman cleanup
Clean up 3 old states (166.27 MiB)?[yes/no] (yes) :

スクリーンショット: 範囲選択

組込みの“スクリーンショット”ツール(キーボード上のPrintScreenを押すと現れます)は、スクリーンショット用に画面の特定の範囲を選択することができるようになりました(画面全体や個々のウィンドウのスクリーンショット取得はすでにサポートされています)。

チームモニター: チームのグループ化

“チームモニター”は、Ctrl+Alt+Delを押すと現れるツールですが、GUIアプリケーションで生成されたすべての非GUIアプリケーションを生成元の下へグループ化するようになりました。これは、マルチプロセスウェブブラウザ(たくさんのサブプロセスを生み出します)やターミナルの扱いを簡素にします。

DriveSetup: “ディスクイメージ”メニュー

Haikuのパーティションマネジャー兼エディターであるDriveSetupから、ディスクイメージを直接扱えるようになりました。新しい“ディスクイメージ”メニューを通じて行います。パーティションをディスクイメージにコピーでき、ディスクイメージをパーティションに書き込むことができます。また、ディスクイメージをカーネルに登録して、それらがディスクであるかのように動作させることもできます(マウント、アンマウントパーティションの作成・削除など)。

app_server: 再起動処理

app_server、つまりHaikuのGUIアプリケーションサーバー(ディスプレイサーバー、ウィンドウマネージャー、描画サーバー)は、強制終了またはクラッシュで再起動したときに、すべての実行中アプリケーションの再接続と現状の再確定を処理できるようになりました。これは、app_serverのクラッシュが、そこからの回復のためにシステムの再起動やデスクトップの再起動をもはや必要としないことを意味します: 代わりに、多くの場合すべての実行中アプリケーションはサーバーの再起動完了後自動的に再接続し、ユーザーは中断したところから正しく再開できます。たいていの場合、これは数秒未満で起こります。

バッテリーの状態: 複数のバッテリーを持つシステムでの改良

バッテリーの状態は、バッテリー情報を表示するアプリケーション(および Deskbar内のバッテリースッテータスアイコン)ですが、複数のバッテリーを持つシステム上の動作、特に稼働中にバッテリーが抜かれた場合や、充放電が異なる時間や速度で行われる場合に対して多くの改良を受け取りました。

多くのアプリケーションに対する、“ダークモード”とHiDPIのさらなる修正

多くの組み込み(ファーストパーティ)Haikuアプリケーションが、“ダークモード”とhigh-DPIの設定を正しく扱えるようにするために次のような多数の修正と改良がありました: ハードコードされた色・ブレンド・サイズの修正など。

launch_roster: 状態の全体像

Haikuの起動およびサービスマネージャー(launch_daemon)とやりとりするコマンドラインツール(launch_roster)には、大きなアップグレードが行われ、すべての登録済ジョブやサービスの状態が表形式でひと目で見られるようになりました:

$ launch_roster
                           Name  Type     State    Enabled
----------------------------------------------------------
     check-daylight-saving-time  job      stopped  yes
                    first-login  job      stopped  yes
                    update-time  job      stopped  yes
                  x-vnd.be-trak  service  running  yes
                  x-vnd.be-tskb  service  running  yes
         x-vnd.haiku-app_server  service  running  yes
          x-vnd.haiku-autologin  job      stopped  yes
       x-vnd.haiku-debug_server  service  running  yes
       x-vnd.haiku-media_server  service  running  yes
       x-vnd.haiku-mount_server  service  running  yes
         x-vnd.haiku-net_server  service  running  yes
x-vnd.haiku-notification_server  service  stopped  yes
     x-vnd.haiku-package_daemon  service  running  yes
       x-vnd.haiku-power_daemon  service  running  yes
          x-vnd.haiku-registrar  service  running  yes

システム全体にわたるメモリ管理のリファクタ

システム全体にわたるパフォーマンス最適化に加えて、システム全体にわたるメモリ管理サブシステムへの非常に多くのリファクタやオーバーホールもありました。そのうちのいくつかはこれまでの項目で記載されたパフォーマンス最適化に貢献していますが、多くは、いずれにしろパフォーマンスには大きく影響しない(多数はメモリ使用量に影響しているが)。以下にハイライトのいくつかを記載します:

これらの変更の複合効果は、128MBしかRAMを搭載していない32-bit上のシステムで、再びHaikuを少なくとも起動できるようになったことです(しかし、スムーズに実行するには、“必要最低限の”インストールが必要になります)、更にそれに関するいくつかの作業が終了しています。すなわち、モダンウェブブラウザを必要としない限りは!

特に、先に列挙された変更に加えて、いくつかの変更は特別な言及と考察にふさわしいものです。それらを以下に記載します:

新しいユーザーランドmalloc

長年に渡り、Haikuはユーザーランドのメモリアロケーター(例 mallocやC標準ライブラリコールの背後の実装)として、“hoard”メモリアロケーターのカスタムバージョンを使用しています。このアロケーターは、特に新しいアロケーター(または“hoard”自体のより新しいバージョン)と比較した場合古くなっており、かなり前から置き換える予定でした。

色々なアロケーターを評価後、最終的に多くの部分をOpenBSDのものをベースとしたアロケーターを考えだしました。ただし、我々の変更も多く含んでいます(例. グローバルキャッシングレイヤー)。この新しいアロケーターは多くの場合古い“hoard”に対する控えめなパフォーマンス改良、古いアロケーターの病的な挙動が引き起こす少数の場合における著しいパフォーマンス改良、不使用メモリをシステムへ戻すあたりの著しく良い挙動(特にメモリのタイトなローエンドなハードウェア上で長時間実行するアプリケーションに大きな利益をもたらします)を提供します。

メモリ領域分割の改良

アプリケーションやライブラリが大きなメモリの塊を要求する(例. mmapを通じて)が、その後この大きな塊の真ん中の小さい塊を解放する(例. munmapを通じて)場合、カーネルは大きな領域の管理(bookkeeping)データをひとつでなく、ふたつに分割する必要があります。特に、問題のメモリの塊がプロセス間で共有されている、ページごとの保護がされている(mprotectで設定されたような)、またはほかの特別な状況である場合、実装は実際少々トリッキーなものとなります。

以前、Haikuにはこれに対する部分的な実装がありました。しかし、古いユーザーランドmallocはそれを使用していませんでした。そのため、それは自身で進んだメモリ管理を行う(またはカスタムmalloc実装を同梱した)サードパーティのアプリケーションだけでこれまで使われてきました。これは、比較的珍しいことなので、特に十分にテストされていなかった。しかし、新しいユーザーランドmallocは、この機能をたびたび使用します(新しく移植されたウェブブラウザーも同じく使います)、そのため、実用に達するようにかなりリファクタされました。

メモリが少ないときの挙動の改善

Haikuはほとんどのメモリをオーバーコミットしません(そのため、“OOM killer”もありません): オーバーコミットはオプトインで、エリア/メモリ領域ごとのみであり、すべての過剰なメモリ(overages)はオーバーコミットを行うアプリケーションに対してのみ負の結果をもたらす結果となります(その場合でも、問題を捕捉して優雅に復旧するチャンスがまだ残っています)。ほかのすべてのメモリ領域は前もって予約(しかし、パフォーマンスを下げるため割当はされていない)されており、足りない場合は、領域の生成はENOMEMや同じような標準エラーで失敗します。

しかし、システムがエラーを返すからといって、システムのすべての部分がこれらのエラーを処理する準備ができているわけではありません。すでに予約されたメモリに支援されていないすべてのメモリ割付は、失敗するかもしれないので、システムがメモリの少ない状況になった場合、カーネルとドライバーは、malloc(または同等のルーチン)が、ENOMEMを返すことを許可する必要があります。一方、他のOSでは、カーネルレベルのmallocは、失敗しないことを保証します(他に利用できるメモリがなければ、利用できるようにするためいくつかのユーザーランドアプリケーションを強制終了するからです)。

これらのエラー(または、システムが低メモリでの際に起こりえるまたはいろいろなほかの一般的でない状態)処理に失敗すると、奇妙なシステム動作になったり、ソフトロックやクラッシュすることさえあります。多数のこれらの問題は、本リリースサイクルのメモリ管理変更で修正されました。システムは、以前より危険な低メモリ状態からの復帰がさらにできるようになりました。

guarded_heapの改良

デフォルトのカーネルとユーザーランドのmalloc実装(一般的な“production”利用のためにデザインおよびチューニングされています)に加えて、Haikuはいくつかのデバッグmalloc実装をシステムに組み込んでいます。そのひとつがguarded_heapです。このmalloc実装は、ひとつひとつの割当をマップされていないページのすぐ隣りにある自身のメモリページの最後に配置します。これは、大量のメモリとアドレススペースを無駄に消費しますが、タイミングに影響を受けないバッファーオーバーラン(メモリ再利用を無効にすればuse-after-freeやdouble-freeも)の検出に100%効果的です。また、追加の計器(instrumentation)は要求しません(すなわち、-fsanitizeやほかの特別なオプションを付けて再コンパイルする必要はありません)。

カーネルのguarded_heapは、本リリースの間で完全に書き直され、ユーザーランドのものと機能に関して同等以上となりました。ユーザーランドで利用できるものとよく似ていて、再コンパイルを要求する代わりに、少なくともナイトリーのカーネルで実行時に(ブートローダーのオプションを通じて)有効にできるようになりました(リリースカーネルはパフォーマンスのためにオプション無しでコンパイルされています)。

ファイルシステムの改良

本リリースには、Haikuのファイルシステムドライバーへのかなりの数の改良があります。これらの変更のいくつかのハイライトは以下を含みます:

ファイルシステムドライバー自体に加えて、本リリースでは多数の変更が全体的にファイルデータキャッシングシステム内に行われてきました。これらで最も重要なのは、それぞれのディスクデバイスに対してひとつのファイルデーター書き込みキューがあることです(システム全体に一つだけでなく)。これらのキューは、変更されたデータが仮想のドライブに書き込まれる速度を記録しています。また、ファイルデータキャッシングシステムはキューが非常に大きくなるのを防ごうとします。

これは、多くのLinuxシステムで見られる(少なくともデフォルトの設定で)、遅いデバイス上のパーティションに大量のデータがきわめて速く“コピーされた”ように見えるが、アンマウントやsyncが非常に長く掛かる(実際にはデータはとても速いカーネルのキャッシュに追加され、遅いデバイスには書き込まれないからです)問題は、たいていの場合、Haikuでは起こらないことを意味しています: キャッシュレイヤーは書き込みキューが書き出しより速く大きくなることに気づき、データーが書き込まれるまでさらなる書き込みが起こるのを防ぎます。これは、速いディスクから遅いディスクのパーティションへの大量のデータコピーは、ディスクの実速度により近い速度を行われることを意味し、最後のsyncも最大でも数秒で終わるはずです。

ハードウェア互換性の改善

本リリースは、特に最近の(過去~5年) x86システムに対しての、多くのハードウェア互換性の修正と改良を含みます。前のリリースで全く立ち上がらなかった多くのシステムは、とてもスムーズにR1/beta6を動作するはずです。ほとんどの基本的なハードウェアを組込みのドライバーでサポートしているためです。

オーディオ出力の修正と改良

特にローエンドのハードウェア上で、オーディオ出力が完全にまたは部分的に壊れる数多くの問題を本リリースで解決してきました。この作業の一部として、遅延初期化も実装されました: サウンド出力ハードウェアは最初にメディアを再生しようとするまで完全に初期化されません。それにより電力とCPUサイクルを節約します。

VESA BIOSライブパッチ

modesetting-capableドライバーの無いシステムでは、代わりにフォールバックグラフィックドライバーを使用します: EFIではdumb framebuffer、レガシーBIOSシステムではVESAです。VESAは、実行時ビデオモード変更をサポートしていますが、それはプリセットリストからモードを選択することしかできません。そのため、たいていの場合、カスタムビデオモードを選択したければ、フルのmodesettingドライバーがないと残念ながら不可能です。

しかし、いくつかのハードウェアでは、実際にVESA BIOSを直接変更して、プリセットリストにカスタムビデオモードを挿入し、使用することができます。Haikuはこのテクニックが動作すると知られている選ばれたVESA BIOSに対してこれを実装しています。

USBイーサネットとWiFiアダプタのさらなるサポート

Haikuにはソース互換レイヤーがあり、ほとんど修正無くFreeBSDやOpenBSDのネットワークドライバーを使用できます。互換レイヤーは、USBイーサネットアダプターのサポートを追加するため、またUSB WiFiアダプターとの互換性を拡張するため、前のリリースから改良されました。さらに、既存のドライバーもアップストリームのFreeBSDやOpenBSDのと同期しました。そのため、現在さまざまな追加ハードウェアがサポートされました。

POSIX互換性の向上

Haikuは、POSIXへの順守を向上させ、開発者にソフトウェアの移植を容易にさせる方法に常に目を向けています。最新バージョンのPOSIX標準は、前のリリースの数ヶ月前に発行されました。そのため、その多くの変更や新機能は前のリリースでなく、本リリースに存在します。この分野での変更や追加は多いので、個々に記載できませんが、いくつかのハイライトを記載します:

必要または実用的(sensible)な、POSIX標準に対するGNU / BSD拡張も実装しています。その分野での変更及び追加のハイライトをいくつか記載します:

さらに、すべての拡張は、“standards mode”が要求されない限りデフォルトでC/C++ヘッダーに見えています (__STRICT_ANSI__または_POSIX_C_SOURCEを定義することで“standards mode”になります。これは、特定の“GNU”バージョン、たとえば-std=gnu++11を指定する代わりに、同等の標準バージョン、たとえば-std=c++11を要求することで、暗黙的にC/C++コンパイラで定義されます)。

全体的な安定性への取り組み

かなりの時間がシステム全体の安定性に関する取り組みに注がれました。多くのカーネルやドライバーのクラッシュ、ハングアップ、データ破壊、起動失敗などが本リリース開発サイクル中に追跡され修正されました。全体として、システムはこれまでよりさらに安定しているようです。

“今はまだですが…”

残念ですが、過去2年間にわたる開発作業のすべてが本リリースにマージされてはいません。そのうちのいくつかはまだ実験段階なのでデフォルトで無効となっています。まだ開発中ですが、興味深い機能をいくつか記載します:

ARM64

多様な貢献者の努力のおかげで、ARM64 portは、仮想化環境上でデスクトップまで起動しました!(貢献者はさらにマージされていないブランチを持ち、そこではApple M1ハードウェア上でデスクトップのブートができています)。行う作業はまだ多いですが、全体として、R1/beta5のコードの状態より大きな進捗です。

マルチプロセスWebKit

Haiku組込みのWebPositiveは、まだシングルプロセスバージョンのWebKitエンジンを使用しています。しかし、Haiku上でマルチプロセスモードを動作させようとする背後で順調な進捗があります。すでにブラウザエンジンは開始していて、基本的なウェブサイトは表示できます。ただし、WebPositive自体を置き換えるまでには、長い道のりがあります。

新しい貢献者

前回のリリースから、新たにコミット権を持つ開発者が1名加わりました: Zardshardは、Icon-O-Maticおよびその他のHaiku純正アプリケーションの作業をしています。ようこそ!!

ソースコード

Haiku自体のソースコードへは、GitHubミラーから、または HaikuのGitインスタンスを通じてアクセスできます。パッチはGerritを通じて貢献できます。

問題の報告

Haikuのバグトラッカーには、3,900個近くのオープンチケット、16,000個を超えるクローズドチケットがあります。問題と思うものを見つけたなら、バグトラッカーを検索して、すでに報告されているか確かめてください。もし報告されてなければ、バグトラッカーへ新しいチケットを登録してください。

リリース後に修正された主要な問題の情報は Release Addendumページを見てください。

さらに詳しいヘルプについては、'Quick Tour'を手にとって、‘Userguide’ を読んでください。どちらもHaikuデスクトップ上にリンクされています。WebPositiveはデフォルトで'Welcome'ページを開きます。そこにはHaikuプロジェクトのウェブサイトと同じく、有益な情報やたくさんの役に立つリンクがあります。

Haikuに関するサポート/ヘルプはフォーラムに投稿するか、IRC/Matrix/XMPPルームに参加するか、またはメーリングリストへメッセージを送ってください。私達の親切なコミュニティが手助けしてくれるでしょう。

プレス窓口

プレスの問い合わせは、直接以下へ: