Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

BZip2の後継を名乗る圧縮ツール「bzip3」は何を目指しているのか

古い圧縮形式の名前が、いまGitHubで少し違う形で目を引いています。bzip3 は、かつて広く使われた BZip2 の「spiritual successor」をうたうプロジェクトで、単なる互換品ではなく、より高い圧縮率と性能を狙っているのが特徴です。圧縮は地味に見えて、バックアップや配布、アーカイブの速度と容量をじわじわ左右します。だからこそ、この手の道具がどう更新されているかは、いまも十分に見る価値があります。

bzip3 は README で何を示しているか

GitHub 上の iczelia/bzip3 は、BZip2 の後継を名乗る公開リポジトリです。README の最初で、このソフトは「より良く、より強い」後継だと説明されていて、圧縮率と性能の両方を上げたと主張しています。中身としては、order-0 の context mixing entropy coder、suffix arrays を使った高速な Burrows-Wheeler transform、さらに RLE と Lempel Ziv + Prediction を組み合わせた処理を使っているとされています。要するに、昔ながらの bzip2 系の文脈を引き継ぎつつ、より新しい圧縮技術を寄せ集めて作った道具です。

用途の面では、テキストやコードの圧縮に強いと書かれています。これは bzip2 らしさをかなり強く残した説明で、ログやソースツリーのような「似た文字列が多いデータ」に向いているという意味です。インストール方法は、git clone した場合なら ./bootstrap.sh、./configure、make、sudo make install という流れ。macOS では Homebrew から brew install bzip3 でも入れられる、と案内しています。

README のかなりの部分はベンチマークです。作者は Perl5 の全リリースを集めて解凍し、それらをまとめた all.tar を作って各圧縮方式を試しています。xz -T16 -9 -k all.tar は 12:09.24、bzip2 -9 -k all.tar は 17:16.64、bzip3 -e -b 256 -j 12 all.tar は 7:10.10、bzip3 -e -b 511 -j 4 all.tar は 7:08.65、zstd -T12 -16 all.tar は 6:35.62 でした。圧縮サイズは xz が 2,056,645,240 bytes、bzip2 が 3,441,163,911 bytes、bzip3 -b 256 が 1,001,957,587 bytes、bzip3 -b 511 が 546,456,978 bytes、zstd が 3,076,143,660 bytes。作者の結果では、bzip3 は特に -b 511 でかなり小さく圧縮できています。

展開速度の比較も載っています。WD Blue HDD 上での wall clock time は、xz が 4分40s、bzip2 が 9分22s、bzip3 (parallel) が 4分06s、zstd が 3分51s でした。さらに lrzip と組み合わせた実験もあり、長距離重複排除をかけた all_none.tar.lrz を bzip3 で圧縮すると 22.411 秒で終わり、サイズは 60,672,608 bytes になったとしています。比較として lrzip + lzma は 64,774,202 bytes、lrzip + bzip2 は 75,685,065 bytes でした。

ただし README には強い警告もあります。作者はデータ損失の責任を負わないと明記し、圧縮とは「あとで元に戻せる」という前提のうえに成り立つが、複雑な実装なのでバグが残る可能性はゼロにできない、と書いています。とはいえ不安を煽るだけではなく、bzip3/libbz3 は慎重に作られ、広くテストされてきたとも述べています。対応アーキテクチャとしては x86、x86_64、armv6、armv7、aarch64、ppc64le、mips、mips64、sparc、s390x が挙げられています。ライセンスは LGPLv3 で、コードの一部には Apache 2.0 や BSD、GPL 系の部品が含まれるものの、プロジェクト全体としては LGPLv3 だけだと整理されています。

bzip3 の強みは「bzip2 の続編」より実験精神にあると思う

まず面白いのは、このプロジェクトが単に「bzip2 を少し速くした」程度の話ではないことです。README を読む限り、bzip3 は圧縮理論のいくつかをまとめて押し込んだ、かなり野心的な実装です。Burrows-Wheeler transform を軸にしながら、context mixing や LZP を足して、テキストに強いという bzip2 的な性格を保ったまま圧縮率を大きく押し上げようとしている。ここには、古典的な圧縮方式を現代の計算資源で再構成する面白さがあります。私は、この種のプロジェクトは「互換ソフト」ではなく、むしろ研究寄りの実用品だと思っています。

ベンチマークは魅力的だが、読み方には少し慎重さが要る

一方で、README の数字をそのまま一般化するのは危ないとも感じます。作者が使っているのは Perl5 の全リリースという、かなり偏りのあるデータです。ソースコードや tar をまとめたような、テキスト中心で似た構造が多い素材なら bzip3 は強いはずですが、写真、動画、混在したバックアップ、暗号化済みデータのようなものでは話が変わります。bzip3 -b 511 が極端に小さなサイズを出しているのも、条件にかなり依存しているはずです。つまり、このベンチマークは「bzip3 は何でも圧縮界で最強」という証明ではなく、「特定のデータではかなり効く」というサンプルとして読むのが自然です。

それでも、bzip3 が示しているのは“圧縮の居場所”がまだあることだ

最近は zstd が実務の標準として強く、xz は配布物の定番として残り、gzip は互換性で生き続けています。その中で bzip2 の後継を名乗るのは少し懐古的にも見えますが、実際には「まだ埋まっていない用途がある」と示しているのだと思います。たとえば、テキストアーカイブを長期保存したい人、巨大なソースツリーを少しでも小さく持ちたい人、あるいは圧縮方式の研究や比較をしたい人です。そういう層には、bzip3 のように実装が公開され、設計意図もベンチマークも見える道具は価値があります。圧縮は裏方ですが、裏方だからこそ、道具の思想がはっきりしていると使い道が見えやすい。

気になるのは、速さよりも「どこまで信頼して使えるか」だ

README には十分な注意書きがありますが、圧縮ソフトではここがいちばん大事です。データを小さくできても、復元できなければ意味がありません。しかも bzip3 は、実装の複雑さゆえに特別なケースで問題が起こるかもしれないと自分で認めています。これは弱点というより誠実さに近いですが、運用する側から見れば重要な警告です。バックアップ用途で新しい圧縮形式を使うなら、少なくとも検証用の復元テストや、長期保存時のフォーマット固定の方針が必要になります。bzip3 は魅力的ですが、気軽に置き換える対象ではなく、まず試して性格を見極めるべき道具だと思います。

参考: GitHub - iczelia/bzip3: A better and stronger spiritual successor to BZip2.

同じ著者の記事

ロサンゼルスの「今ある建物」だけを積み上げた地図が見せるもの

ロサンゼルスの街を、建物ごとにひとつの箱として描き、その箱を「建てられた年」に沿って並べた可視化が公開された。見えてくるのは、都市の成長史そのものというより、いま現存している建物だけで作った“生き残りの街”だ。取り壊された建物は含まれないので、過去の都市の完全な再現ではないが、その偏りがかえって都市の時間の層をくっきり見せる。ふだんは意識しない「何が残り、何が消えたのか」を、直感的に考えさせる作品になっている。 元記事は、ロサンゼルス市内に今立っている建物をすべて、1棟につき1つの箱として表現したインタラクティブな地図を紹介している。箱は建物の輪郭や高さを反映しており、建てられた年ごとに出現する。つまり、年を追うと都市に建物が少しずつ積み上がっていく様子が見える仕組みだ。説明文では、これは「The surviving city, 1880 to now」とされていて、いま残っている建物だけで構成したロサンゼルスだと明言している。途中で壊された建物は入っていないので、「当時の街並み」そのものではなく、現在まで生き残った建物が作る都市の断面図というわけだ。 画面には「Decade buil

papoo.work

画面を見続ける私たちは、どこで本を失ったのか

子どもが本を読まなくなった、という話は昔から「最近の若者は」で片づけられがちだった。だが今回の元記事は、その手の懸念を単なる懐古主義として退けない。Timesのコラムニスト、James Marriottの新刊『The New Dark Ages』を手がかりに、読書離れ、テレビ、スマホ、そして注意力の縮み方を一本の流れとして描いている。面白いのは、犯人を安易に「スマホ」と決めつけず、もっと前から起きていた変化として話を組み立てている点だ。だからこれは、媒体の移り変わりを論じる本の紹介であると同時に、私たち自身の生活習慣へのかなりきつい鏡でもある。 元記事の書き出しは、著者Ed West自身の親としての不安から始まる。10代の男の子たちの画面には、YouTubeのくだらない企画動画が次々に流れ、昔の90年代の「退屈なテレビ」さえ、いま振り返ればドストエフスキー並みに複雑だったように見える、と皮肉る。さらにWestは、子どもたちが読書をしなくなっていることが、周囲の親の間で「気がかり」から「不安」、ついには「パニック」へ変わりつつあると書く。 そこから話題は、James Marriottの新

papoo.work

欧州の宇宙輸送で、Isar Aerospaceが「2回目」で軌道到達を果たした意味

欧州の新興企業 Isar Aerospace が、2回目の飛行で軌道に到達し、ペイロードの分離までやり切ったと発表した。しかも打ち上げ場所はノルウェーの Andøya、つまり米国やロシアの既存インフラに頼らない「欧州発」の宇宙輸送として大きな節目になった。単なる成功報告に見えるかもしれないが、この記事は欧州の商業宇宙産業が抱えてきた弱点、つまり打ち上げ能力の不足を正面から揺さぶる内容だ。ここでは発表内容を整理したうえで、これが何を変えるのかを少し踏み込んで見たい。 Isar Aerospace は 2026年9月5日、ノルウェーの Andøya Space にある自社専用の発射施設から「Onward and Upward」と名付けたミッションを打ち上げた。打ち上げ時刻は CEST 22時12分で、同社はこの飛行で衛星を軌道に送り込み、ペイロードの展開まで完了したと発表している。発表文では、ヨーロッパの商業宇宙企業として初めて「衛星を軌道へ届けた」と強く打ち出しており、しかも達成は「たった2回目の飛行」だったと強調している。 CEO 兼共同創業者の Daniel Metzler 氏は、こ

papoo.work

LinkedInでAI下書きを見抜かれる話が、思った以上に切実だった

SNSの中でLinkedInだけが妙に生き残っている、という少し皮肉な出発点から始まる文章だが、そこで筆者が言いたかったのは単なる愚痴ではない。いま多くの人が仕事の発信や近況共有にAIを使い始め、その結果として「読めるけれど、本人らしくない文章」があふれている。元記事はその違和感をかなり露骨に言語化していて、しかもLinkedInという場の性質まで絡めているので、AI時代の文章の問題が見えやすい。書き手は便利さを否定していないのに、なぜ「自分の声」を手放すと損をするのかをかなり強く突いている。 元記事の筆者はまず、LinkedInが自分にとって「重要なソーシャルネットワーク」になってしまったと打ち明ける。ただし、それはLinkedInが優れているからではない、とすぐに釘を刺す。むしろ筆者の比喩では、LinkedInは「ソーシャルネットワーク界のジェラルド・フォード」だという。周囲のSNSが次々と崩れていく中で、少し不器用で地味ではあるが、完全に腐ってはいない。だからこそ居場所として残っている、という見方だ。 そのうえで筆者が本題に入る。LinkedInでは、LLMを使って投稿文を生成す

papoo.work

カリフォルニア工科大が「AIで数学を解く」40時間競争を開く

AIが画像や文章だけでなく、純粋数学の研究にも踏み込もうとしている。そんな流れを、そのままイベント化したのが Caltech Mathathon だ。元記事は、数学の未解決問題をAIと人間のチームで解く40時間のハッカソンを告知しているだけではない。AIが証明や理論構築をどこまで速くできるのか、そして人間の数学者の役割は何になるのか、というかなり大きな問いを前面に出している。研究競争の話でありながら、同時に「数学研究の作法そのものが変わるかもしれない」という宣言でもある。 元記事によると、Caltech Mathathon はカリフォルニア工科大学で開かれるイベントで、開催日は October 30th から November 1st。参加するのは世界中から集められる100チームで、与えられるのは frontier models と呼ばれる最先端のAIモデルだ。挑む対象は open conjectures、つまりまだ解かれていない数学の予想や問題で、単に答えを出すだけでなく、新しい数学理論を組み立てることも求められる。 このイベントが面白いのは、解けたかどうかだけで終わらない設計になっ

papoo.work

「skills files」は結局どう持つべきか、Hacker Newsで割れた本音

AIエージェント向けの「skills files」をどう管理するか。Hacker Newsで投げかけられたこの質問には、便利な運用ノウハウだけでなく、「そもそも技能ファイルは要るのか」というかなり根本的な疑問まで集まりました。話題になっているのは、モデルに毎回同じ作業のやり方を覚えさせるためのテキストやスクリプトを、個人で、あるいはチームでどう整理するかです。便利だと感じる人もいれば、むしろノイズだと見る人もいて、使う人の熟練度や仕事の種類で評価がかなり変わっていました。 投稿者はまず、skills をどう見つけ、整理し、実際に役立つ状態に保つのかを尋ねています。時間がたっても改善し続けているのか、という問いもありました。投稿者自身は、いつか skills はモデルの能力に吸収されていく気がするが、それまでは管理の仕方を知りたい、という立場です。 返答の中で目立ったのは、「外から集めるより、自分で書く」という姿勢でした。ある参加者は、skills を探すのではなく、頻繁に繰り返す作業から自分用に作っていると書いています。ファイルはローカルと GitHub で version contr

papoo.work

1024バイトのPythonを手で作る遊びが、思ったより本気だった

Austin Z. Henley が、Cで「Pythonのごく一部」を 1024バイトに収める実験を公開した。狙っているのは、CPythonのような本格実装ではなく、見た目がPythonらしく振る舞う最小限のインタプリタだ。しかも今回は、コードゴルフの技巧をただ見せたいのではなく、どう削ればここまで小さくできるのかを、途中で何度も失敗しながら追っているのが面白い。完成物は短い。だが、その短さに行き着くまでの割り切り方はかなり過激だ。 Henley は週末に手でコードを書くと「人間に戻れる」と書いたうえで、512バイトか1024バイトのCコードでPythonインタプリタを作る挑戦を始めた。もちろん、本物のPython全部は入らない。そこで彼が考えたのは、「Pythonっぽく見える最小構成は何か」を選び抜くことだった。例として最初に挙げたのは FizzBuzz で、`def`、コロン、インデント、`if` に括弧がない書き方など、見た目がPythonそのものに見える断片を確認していく。 最初の試みは512バイトを目指したが、すぐに無理だと分かった。式を足し算できるようにし、変数代入を入れ、

papoo.work

Internet Archiveの「3倍支援」キャンペーン、実はサーバー維持費の話だった

Internet Archiveが9月に入って、継続寄付を増やしてほしいと呼びかけています。しかも今回の話は、単に「寄付してください」というお願いではありません。月額25ドル以上の recurring donation を始めると、初回の寄付が2対1で上乗せされ、実質的に3倍の支援になるというキャンペーンです。Webの保存や書籍のデジタル化の裏で、どれだけ地味で高いコストがかかっているのかが見えてくる内容でもあります。 元記事は、Internet Archive の9月の寄付キャンペーンを告知するものだ。書き手はまず、Wayback Machine を検索したり、Internet Archive のコレクションを開いたりするたびに、世界中の学習者に開かれた「グローバルな図書館」に触れているのだと位置づける。そこには単なるサイト運営以上のものがあり、「Universal Access to All Knowledge」という理念を支えるには、書籍スキャンや web crawler だけでなく、サーバー、ストレージ、電力、冷却、そしてシステムを作り保守する人員が必要だと説明する。 Inte

papoo.work

LINEの既読がつかない・相手に表示されない原因と対処法【2026年9月・全面改訂版】

このテーマは半年ほど前に一度書いた。当時の結論は「通信を疑う、アプリを再起動する、数時間待つ、ブロックと決めつけない」で、実際それで大半は片付いていた。 ところがこの半年で前提が二つ壊れた。ひとつは2026年2月のトークタブ全面刷新で、一括既読の場所が変わり、刷新直後にはトーク一覧が真っ白になる不具合まで出た。もうひとつはiOS 26で、長年定番だった「既読を付けずに読む」裏技が事実上封じられた。 つまり「既読がつく／つかない」の意味そのものが、半年前とは少しズレている。前の記事の手順は間違っていないが、その前にそもそも何が起きているのかの切り分けから書き直す必要が出た。 ここを混ぜると、待っても直らない・再起動しても直らない、という噛み合わない状態になる。 ① 送信自体が失敗している — 相手の端末に届いていない。既読以前の問題。 ② 届いているが、相手がトークルームを開いていない — いちばん多い。純粋に待つ案件。 ③ 相手側の設定で弾かれている — ブロック、またはメッセージ受信拒否。 順番も大事で、**①→②→③ の順でしか正しく

papoo.work

ChatGPT「セッションが切れました」の原因と対処法【2026年9月・全面改訂版】

このテーマは1年ほど前にも一度書いた。当時の結論は「リロードする、キャッシュを消す、再ログインする」で、実際それでだいたい片付いていた。ところが2026年に入ってから、同じ手順を踏んでも直らない、あるいはそもそも再ログインできなくなるという相談が増えた。理由ははっきりしていて、この1年でChatGPT側のセッション管理そのものが大きく作り替えられたからだ。 具体的には、6月にアクティブセッション一覧が追加されて「いま何がログイン中か」が初めて可視化され、パスワードログインを無効化する高度なアカウントセキュリティが入り、8月にはAtlasブラウザが停止して既存のログイン状態が丸ごと巻き戻った。前の記事の手順は間違ってはいないが、いまはその前にどの層のセッションが切れたのかを見極めないと、正しい対処に辿り着けない。今回はそこから書き直す。 ChatGPTで「セッション」と呼ばれているものは、実際には出所の違う4つが同じ言葉で呼ばれている。ここを混ぜると、キャッシュを消しても直らない・待っても直らないという噛み合わない事態になる。 **① 認証セッショ

papoo.work