JSLinux

 (bellard.org)
4 ポイント 投稿者 GN⁺ 2025-04-15 | 2件のコメント | WhatsAppで共有
  • JSLinuxは、ブラウザ内で Linuxや他のオペレーティングシステム をそのまま実行して試せるVM一覧で、CPU・UI・VFsync・設定ファイルまであわせて確認できる
  • 実行項目は x86_64、x86、riscv64 に分かれており、Alpine Linux、Buildroot、Fedora 33、Windows 2000、FreeDOSが含まれる
  • x86_64 Alpine Linux 3.23.2 Consoleは AVX-512 と APX のサポートを含み、x86 Alpine Linux 3.12.0はConsole版とX Window版が別々に提供される
  • グラフィカルまたはX Window環境はWindows 2000、FreeDOS、Alpine Linux、Buildroot、Fedora 33で提供され、一部のX Windowメニューは 右マウスボタン で開く
  • riscv64 Fedora 33項目には 起動時間がより長い という警告があり、Windows 2000にはVFsyncアクセスなしで別途免責事項がリンクされている

ブラウザで実行可能なVM一覧

  • JSLinuxは、ブラウザで Linuxまたは他のオペレーティングシステム を実行するエミュレートシステム一覧を提供する
  • 各項目はCPU、オペレーティングシステム、ユーザーインターフェース、VFsyncアクセス の可否、起動リンク、設定ファイル、備考で構成される
  • 表にはVFsyncアクセスの可否とTEMU関連の設定リンクがあわせて表示される

CPUとオペレーティングシステム別の実行項目

関連記事

2件のコメント

 
GN⁺ 2025-04-15
Hacker Newsの意見

  • Fabriceは自己完結型ソフトウェアを本当にうまく作り、その成果物が独自の生命力を持つことも多い
    あまり知られていない例として、JSLinuxのターミナルエミュレータは何度かフォークされ、今ではxterm.jsとして知られ、Webに埋め込めるターミナルエミュレータの主流になっている
    今はJSLinuxの本当の後継を作っていて、カーネルとユーザー空間をネイティブにWasmへコンパイルするのでずっと速く、ターミナルエミュレーションには当然xterm.jsを使っている
    まだ共有すべきではなさそうなバグだらけのデモが好きなら、https://linux.tombl.devを見る価値はあるが、現状はbusyboxシェルだけなので、lsの代わりにecho *に慣れる必要がある

    • Fabriceは、他の人たちが一生メンテナンスする価値のあるサイドプロジェクトを作る、と表現されがち
      QEMU、ffmpeg、LTE関連の仕事、QuickJSは知っていたが、xterm.jsも彼から始まったとは知らなかった
    • どんなコマンドを実行しても、以下のようにattempted to munmapとカーネル警告が出る
      WARNING: CPU: 3 PID: 36 at kernel/exit.c:812 0x00000000、Comm: sh Not tainted 6.1.132のようなスタックトレースが表示され、vmlinux-NLTKI6YG.wasmとworker-MHWHWELT.jsの方へ続いていく
    • 懐かしい。しばらく見ていなかったけれど、12年前の自分のフォークのフォークが今も元気に生きているのはうれしい
      ほとんど書き直されているように見えるし、たぶんより良くなっているはず
      https://github.com/xtermjs/xterm.js
      https://github.com/chjj/term.js
    • すごい。JSLinuxより電力効率が良く、iOSでも動くなら、A-ShellやiSHの良い代替になるかもしれない
      MacBookで試したが、キーボード入力が認識されなかった
    • 動くコマンドはあるのか？ ps、cat、vi、edが全部クラッシュする
      busyboxの組み込みに詳しくないので、何をすればいいのか分からない

  • Fabriceはすごい。この人が作ったものの量は本当に信じがたいほどだ
    彼が作ったもののうち1つだけでも自分が作っていたら、たとえばffmpeg、QEMU、tinycのどれか1つだけでも一生自慢していただろうに、彼はただひたすら別のクールなものをハックし続けている

    • いっそ彼が何を欲しがっているのか突き止めて、それを渡せばいいのでは。そうすればお返しに、私たちが抱えている壊れたものをちゃんと書き直してくれそうだ
      携帯電話、OS、デスクトップ環境、国家、アプリストアなど全部
    • この人はいい。彼のQEMUはあまりに広く使われているので、世界中のAndroid開発の半分は彼のおかげで楽になっていて、その影響はさらに大きくなっている
    • DOSを使っていた人にはなじみがあるかもしれないLZEXEも、同じ人が書いたもの
    • 彼が作業対象をどう選んでいるのか気になる。単に興味に従っているだけなのかもしれない

  • ブラウザで動く仮想マシンはそれほど多くない
    https://copy.sh/v86/
    https://webvm.io/
    https://bellard.org/jslinux/
    https://jamesfriend.com.au/pce-js/（https://github.com/jsdf/pce）
    https://www.pcjs.org/は多くのハードウェアとOSをサポートしている（https://github.com/jeffpar/pcjs）
    Mac OS方面ではhttps://infinitemac.org/（https://blog.persistent.info/2023/03/infinitemac-dot-org.htm...）、https://jamesfriend.com.au/projects/basiliskii/BasiliskII-wo...、https://jamesfriend.com.au/pce-js/pce-js-apps/もある

  • 非常に生産的な開発者たちの極端な例を見ると、「関数やファイルは絶対に x 行を超えてはならない」といった教条主義との対比が興味深いものになる。
    quickjs.c は5万行あり、数百行の関数もある。
    https://github.com/bellard/quickjs/blob/master/quickjs.c
    もちろん、状況によって別のアプローチが正しいこともある。

    • 答えは簡単。Bellard は5万行分の文脈をすべて覚えていられるが、ほとんどの人はそうではない。
      自分もワーキングメモリが大きいほうなので、後になって自分のファイルや関数サイズの限界が他人よりずっと高いことに気づいた。
      そうした教条は、複数人が同じファイルを読んだり書いたりしなければならないときに必要になる。
    • そのコードベースで作業していて、私たちは QuickJS-ng としてフォークした。
      最初は威圧感があるが、適切なエディタを使えば意外と作業しやすい。ただし、多くのエディタはこれほど大きなファイルではもたつく。
      ファイルは非常に大きいものの、ある程度意味ごとに並んでいるので、たとえば新しいイテレータメソッドを追加するときも関連コードが近くに集まっていて作業しやすい。
    • 一緒に働く人たちが Fabrice ではないからだ。いつルールを破っても安全なのかを説明するより、「X はそもそもやるな」と言うほうが簡単。
      使っている言語にもよる。たとえば JVM は、バイトコード命令数が特定のしきい値を超える関数をインライン化しないことがある。
    • 良い例として、.NET のガベージコレクタは5万4千行の単一 C++ ファイルだ。
    • 強く結合していて推論しにくい複数の関数より、1つのことをうまくこなす長い関数がよい場合もある。
      教条をそのまま適用するプログラマは有害になり得る。

  • Kohei Tokunaga がこの系譜の次世代を作っている。
    https://ktock.github.io/container2wasm-demo/
    Emscripten の fetch ベースのブラウザネットワーキングや、POSIX 互換の WebSocket プロキシを使っている。
    https://ktock.github.io/container2wasm-demo/amd64-debian-was...

  • 20年ぶりに Windows 2000 を触ってみた。郷愁で目が曇ることはあると分かっているが、あの UI なら今すぐ戻りたい。
    ごちゃごちゃしていないタスクバー、役に立たないおすすめや広告で埋まっていないシンプルなスタートメニューが本当に快適だった。

    • Windows 2000 をもう一度使いたいとはまったく思わないが、UI に一貫性があった Windows のバージョンを見るのは興味深い。
      今は4世代分の GUI ツールキットが混ざり合い、ある UI はあるスタイル、別の UI はまた別のスタイルという寄せ集めになっている。
    • 関連記事:
      “Windows 2000 Server named peak Microsoft. Readers say it's all been downhill since Clippy”
      https://www.theregister.com/2025/04/11/windows_2000_best_mic...
      https://news.ycombinator.com/item?id=43653421
    • そこに Visual Basic 6 をインストールしてみようとしたが、インストール済みの Firefox で SSL エラーが出て、ISO のダウンロード段階すら越えられなかった。残念。
    • 少なくとも2010年から Xfce を使ってきた理由がまさにこれ。今でも同じように動作する。
      オープンソースは本質的にユーザーと利害が一致していて、エンシッティフィケーションを防ぐ仕組みがあると感じる。

  • Fabrice Bellard がどうやって収入を得ているのか知っている人はいる？ この人のオープンソース成果物は本当に驚異的だ。
    同じレベルの人がいるのかどうかも比べるのが難しい。VMware が彼を採用しようとしたり、Google がビデオコーデック、V8、Chromium のレンダリング、ffmpeg の方面に引き入れようとしたりしていてもおかしくない気がする。

  • フランスからは、非常に才能があり創造的で生産的なソフトウェアアーティストや個人コントリビューターがかなり出ているように思う。
    フランス的な要因なのか、エコールのような教育システムのためなのか、それとも別の理由なのかは分からないが、目立っている。

    • Bootlin はフランス企業で、主要なオープンソース貢献者だ。一緒に働いたことがあり、おすすめできる。
      フランスの技術には昔の Renault の古い車の品質のような評判があったが、実際にはそうは見ていなかった。Renault や Citroen でもむしろ感心させられた。
      逆にドイツのソフトウェアエンジニアたちと働くのは大変だった。「自分たちが作ったものでなければダメだ」という態度が非常に強かった。あくまで私の一般化だ。
      欧州の技術エコシステムの問題は単純だ。私たちは売るのが下手で、資源効率に最適化している。「競争力のある給与」が、どんな場合でも市場価格を超えては払わないという意味になりがちだ。
      米国は成長に最適化し、より高い給与を受け入れて成長によってコストを償却しようとする。
      最後に、私の出身地では移民のせいでフランスは壊れたと嘲笑することが多い。そういう見方もあるだろうが、フランスが植民地から頭脳流出を取り込み、非常に有能で生産的な人々を確保したのも事実だ。
      私の修士課程の指導教員もコートジボワール出身だったし、Bootlin でもフランス語圏らしくない名前のトップレベルのエンジニアたちと働いた。
    • Fabrice Bellard と比較できるような人を名前で挙げられる？

  • https://barebox.org/webdemo で JSLinux を使い、潜在的なユーザーが実際のハードウェアにフラッシュしなくても ブートローダーシェルの使い勝手を確認できるようにしている
    ここで言及されているいくつかのフォークはうれしいし、どれが bareDOOM を最もうまく動かせるのか、あるいはサウンドが動作するものがあるのか確認してみたい

  • JSLinux は Endor（https://endor.dev）を作る際の着想源になっており、彼の QEMU 関連の作業も多くの Wasm 関連ブラウザプロジェクトの基盤になっている

    • 仮想マシン、コンテナ、Wasm ネイティブのアプローチがどのように実装されているかについて、公開されている詳細な資料はあるのだろうか？
 
ndrgrd 2025-04-16

CORSの設定が誤っているため、リンク先は https://www.bellard.org/jslinux/ ではなく https://bellard.org/jslinux/ にアクセスしないと正常に動作しませんね。