← 2026-02-23 の一覧へ戻るホーム
**FreeBSD 上で Linuxulator がまるで魔法のように感じられる**

2026/02/23 3:45

**FreeBSD 上で Linuxulator がまるで魔法のように感じられる**

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

主なメッセージ：
VS Code の独自ビルドは FreeBSD 上で動作しませんが、オープンソース版は Linux 環境（

Linuxulator
）経由で実行すると動作します。このレイヤーを有効にし、SSH を設定してカスタム 
BASH_ENV
を持つ Linux シェル（
/compat/linux/bin/bash
）を起動することで、Remote SSH 拡張機能はスムーズに機能します。

主な詳細：

  • 著者は ARM64 FreeBSD マシンが必要です。現在のノートパソコンは Apple Silicon と比べて性能とバッテリー寿命で遅れています。
  • 従来の NFS/SSHFS を用いたリモート開発は、OpenWRT、組み込み Linux、FreeBSD など大規模プロジェクトでは遅くエラーが起きやすいです。
  • Remote SSH は OpenWRT 上でネイティブに動作しますが、初めは FreeBSD で「Unsupported platform: FreeBSD.」と失敗します。
  • 解決策として 
    service linux enable/start
    と 
    pkg install linux_base-rl9
    を使用し、Linux 固有の PATH を設定する 
    .bash_linux
    ファイルを作成します。
  • SSH 設定（
    SetEnv BASH_ENV=".bash_linux"
    および 
    RemoteCommand /compat/linux/bin/bash
    ）により、VS Code セッションで Linux 環境が起動されます。
  • すべての拡張機能はロードされますが Rollup は除外されます。これは 
    package.json
    に WebAssembly ビルドをオーバーライドして解決します。
  • 結果として、FreeBSD 上で高速かつ完全な機能を備えたリモート開発体験が実現し、Linux ABI の安定性と ARM64 ワークフローにおける Linuxulator の実用性が示されます。

インパクト：
開発者は FreeBSD 上で VS Code を性能や機能を犠牲にせず使用できるようになり、ARM64 開発のための FreeBSD への採用拡大が促進されます。

本文

過去数年間、私の選択肢としているエディタは Visual Studio Code です。
完璧というわけではなく、軽量とも言えませんが、機能・拡張機能・パフォーマンスのバランスが絶妙です。

FreeBSD 上で Microsoft の商用ビルドを動かすことは現実的ではありませんが、オープンソース版は問題なく動作します。そこで VS Code が既に使えるなら何故この記事を書くのでしょう？ それは ARM64、あるいは何もない という理由です。

私は ARM64 のマシンを必要としています。
Apple の M1/M2 Mac（x86_64 デスクトップから移行した）で時間を過ごしているうちに、再び x86_64 に戻るのは性能・バッテリー寿命ともに後退感が強く感じられます。残念ながら現在、Apple Silicon に真似できる FreeBSD（あるいは Linux でも）対応 ARM64 ノートパソコンは存在しません。将来 Framework や他社がそれを変えてくれることを願っています。

私にとっての生産性殺し：リモート開発

Debian（私のお気に入り Linux ディストリビューション）と macOS の両方で VS Code は素晴らしい体験です。しかし、私が手掛けるプロジェクトはほぼ外部にあります。組み込み Linux システムや OpenWRT デバイス、そして最近では FreeBSD ボックスです。通常は NFS マウント、SSHFS などのセットアップになります。正直言って、それらはひどいです。

現在の主力スタックは SvelteKit と Go バックエンドで、日常業務も多く OpenWRT を扱っています。プロジェクトが大きくなるにつれて、NFS や SSHFS 上でコードを編集することは LSP が多数走ると痛いものです。あるケースではファイルを開くだけで 5〜10 分かっていました。NFS の方は少し耐えられましたが、多数の奇妙な権限問題に直面して完全に諦めてしまいました。その時点で生産性への真の障害となっていたのです。

VS Code Remote SSH が登場

ここ数日、VS Code の Remote SSH 拡張機能を試してみました。公式にはほぼすべての主要 OS でサポートされていますが、OpenWRT（musl ベース）や FreeBSD は例外です。OpenWRT でも試したところ、驚くほどベアボーンで動作しました。SSH 経由で接続し、デバイス上のファイルを直接編集でき、すべてがスムーズでした。パフォーマンスは期待以上で、ハックやトラブルもありませんでした。本当に魔法のように感じました。

自然と次に FreeBSD を試しました。
現在取り組んでいる FreeBSD に特化した大規模プロジェクト「Sylve」を SSHFS/NFS で管理するのは、ファイル数・ディレクトリ数が多いため大変でした。互換性やサポートについて詳しく調べずに Remote SSH を試してみると、予想どおり

Unsupported platform: FreeBSD

というメッセージが出ました。

途中で諦めずに調査を進めた結果

そこで偶然見つけた素晴らしいリポジトリ：https://github.com/morganwdavis/vscode-server-freebsd

セットアップはほぼ笑えるほど簡単でした。実際、FreeBSD の初期設定時にほとんど同じ手順を踏んでいました。

service linux enable   # Linuxulator エミュレーションレイヤーを有効化
service linux start
pkg install linux_base-rl9  # Linux ベースシステム（ここでは Rocky 9）をインストール

Linux 固有の 

PATH
はグローバル環境や 
.zshrc
に入れず、ホームディレクトリにある別ファイル 
.bash_linux
に記述しました。

PATH="/compat/linux/usr/local/sbin:/compat/linux/usr/local/bin:/compat/linux/usr/sbin:/compat/linux/usr/bin:/compat/linux/sbin:/compat/linux/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

このファイルは、VS Code が Linuxulator 経由で SSH 接続したときにのみ読み込まれます。

sshd
に 
BASH_ENV
変数を受け入れるよう明示的に指示します。

sysrc sshd_flags="-o AcceptEnv=BASH_ENV"

そしてクライアント側の SSH 設定でそれを設定します。

SetEnv BASH_ENV=".bash_linux"

すべてが整った後、macOS クライアントから FreeBSD ボックスへの最終的な SSH 設定は次のようになりました。

Host sylve-code
    Hostname 192.168.72.172
    SetEnv BASH_ENV=".bash_linux"
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3
    RemoteCommand /compat/linux/bin/bash

そして…うまく動作しました。

正直なところ半分の拡張機能が壊れるだろうと、言語サーバーがクラッシュするだろうと、パフォーマンスは最低限しか出ないと思っていました。しかし何も起きませんでした。私が頼りにしているほぼすべての拡張機能は完璧に動作し、Rollup だけが FreeBSD 用バイナリを提供していませんでした。ですがそれも障害ではありませんでした。WASM ビルドがあるので 

npm
の依存関係を上書きするだけです。

{
  "overrides": {
    "rollup": "npm:@rollup/wasm-node@^4.30.1"
  }
}

これで解決しました。

最後に

結果として、FreeBSD 上で Linux バイナリを Linuxulator を通じて透明に実行することで、高速・スムーズ・完全な機能を備えたリモート開発体験が得られました。本当に魔法のようです。もっと重要なのは、Linux ABI の安定性と FreeBSD の Linuxulator がそれをどれだけうまく実装しているかを示す証拠です。このセットアップは私の FreeBSD での作業方法を完全に変え、ワークフロー上最大の摩擦点の一つを消しました。

非常に感動していますし、このアプローチがどこまで発展できるか楽しみにしています。紙上では脆弱に見える設定ですが、実際にはまさに「これで完璧」な仕組みになっています。

同じ日のほかのニュース

一覧に戻る →

2026/02/23 4:12

私は「Timeframe」、すなわち私たち家族用の電子ペーパー・ダッシュボードを構築しました。

## Japanese Translation: 著者は長期プロトタイプを **Timeframe** に変え、カレンダー・天気・スマートホームデータを電子ペーパー画面に表示する常時稼働型ファミリーダッシュボードを作り上げました。 初期テストでは、自然光下で読みづらい Magic Mirror LCD と 30 分ごとしか更新されないジャイルブレークされた Kindle e‑ink ディスプレイから始めました。2019 年に著者は Visionect の電子ペーパー パネル（6″、10″、13″、32″）へ切り替え、単一充電で 10 分ごとに更新可能となりました。これらは Raspberry Pi 上の Ruby on Rails と IMGKit を用いて PNG を生成することで制御されました。13″ パネルの価格が 1,000 ドル、さらにデバイスあたり月額 7 ドルの新料金がかかったため、システムは高価になってしまいました。 2021 年末にマシャル火災で著者の家を失い、再建にはより信頼性の高いソリューションが必要だったため、Boox の 25.3″ Mira Pro 電子ペーパー画面（HDMI 経由でリアルタイム更新）と Mac Mini プロトタイプを採用しました。現在のディスプレイには、時計、Sonos 曲情報（node‑sonos‑http‑api を介して取得）、Dark Sky の翌時間降水予報などのリアルタイムデータが表示されます。 バックエンドは Rails/Redis から Home Assistant (HA) に書き換えられました。HA は Google カレンダー、Apple Weather、Sonos などを直接取得し、データベース層を排除します。著者は Home Assistant のテンプレートセンサー（例：食洗機のリマインダー）を追加し、コード再配備なしでアラートをトリガーできるようにしました。これにより電子ペーパー画面上で自動化されたステータスアラートが実現しました。 現在のディスプレイには左上に「ハウスヘルス」インジケーターがあり、ドアの開閉状態・ロック解除状況・洗濯完了など、必要な情報のみを表示して画面を常に確認する手間を省きます。 残っている課題は、保守不要で配備可能な組み込みハードウェアの強化、すべてのデータソースを HA に完全統合すること、および 25″ Boox の約 2,000 ドルというコストと複雑性を削減することです。著者は Timeframe を継続的に開発しつつ、潜在顧客からの関心を得て、Home Assistant アプリとして市場へ投入することを目指しています。同時に日常業務のソフトウェア作業と並行して個人的な情熱プロジェクトとして進めています。

2026/02/23 7:42

**FreeBSD 15 の新しいブリッジ機能** FreeBSD 15 では、パフォーマンスの向上・設定の簡易化・安定性の強化を実現したスリム化されたブリッジ実装が導入されました。 --- ### 主な改善点 - **低レイテンシ** を実現するために最適化されたパケット処理経路。 - ブリッジインターフェース上で直接 VLAN タギングをサポート。 - 帯域幅やキュー制限のチューニング用 `sysctl` 設定が簡素化。 - ブリッジ接続セグメント間で IPv6 フォワーディングを組み込みでサポート。 --- ### インストールと設定手順 1. **ブリッジモジュールの読み込み** ```sh kldload bridge ``` 2. **ブリッジインターフェース作成**（例：`bridge0`） ```sh ifconfig bridge0 create ``` 3. **メンバーインターフェースの追加** (`em0`, `em1`, …) ```sh ifconfig bridge0 addm em0 addm em1 up ``` 4. **IP アドレスを割り当てる（管理用に任意）** ```sh ifconfig bridge0 inet 192.168.10.1/24 ``` --- ### よくある利用ケース - L2 仮想化（例：KVM ゲストが同一ネットワークセグメントを共有） - 複数のアップリンクで冗長構成 - 追加ルーティング不要で VLAN 分割をシンプルに実現 --- ### パフォーマンス向上のヒント - NIC がサポートしている場合は `bridge_hwfilter` を有効化し、ハードウェアアクセラレーテッドフィルタリングを利用。 - トラフィックプロファイルに合わせて `bridge_maxframe` と `bridge_mtu` の `sysctl` 値を調整。 - `netstat -e` や `sockstat -4` でブリッジ統計情報をモニタリング。 --- ### トラブルシューティング - ブリッジ上のインターフェースに IP アドレス競合がないか確認。 - カーネルログ（`dmesg`）で「bridge」に関するエラーを探す。 - `ifconfig bridge0` でメンバー接続と状態を確認。 --- これらの手順を踏むことで、FreeBSD 15 の新ブリッジ機能を活用し、高性能かつ信頼性の高いネットワーク環境を構築できます。

## Japanese Translation: FreeBSD 15は、従来のVLANごとのブリッジモデルを廃止し、`vlanfilter` フラグで複数のタグ付きまたはタグなし VLAN をホストできる単一の多機能ブリッジに置き換えました。新設計では個別のブリッジが不要になり設定が簡素化されます。sysctl `net.link.bridge.member_ifaddrs` は、ブリッジメンバー上のレイヤー3アドレスをソフト非推奨にし（FreeBSD 16.0‑RELEASEで削除予定）、VLAN フィルタリングが有効でない場合はタグ付きメンバーを追加すると ``` ifconfig: BRDGSIFVLANSET ix1: Invalid argument (extended error VLAN filtering not enabled) ``` というエラーになります。 最小構成例: ``` ifconfig_ix1="up -tso4 -tso6 …" cloned_interfaces="bridge0" ifconfig_bridge0="vlanfilter addm ix1 tagged 2,3,128" ``` VNET ジャイルは `jib` スクリプト（またはカスタム `/scripts/vnetif`）を使い、epair デバイスを作成して正しい VLAN タグでブリッジに接続できます。カーネルは現在 epair 用の安定した MAC 生成 (`net.link.epair.ether_gen_addr`) を提供しているため、jib スクリプトの MAC 安定化ロジックは不要です。例として `/scripts/vnetif` は epair を作成し、IPv6 link‑local を無効にし、ポート名を付け、一方の側をタグなし VLAN 2 としてブリッジへ追加します。 Bhyve VM では手動でタップインタフェース（例: `tap133`）が事前に作成され、ブリッジに追加されます (`ifconfig bridge0 addm tap133 untagged 2`)。VM 設定はこれらのタップを参照しますが、新しいブリッジ/VLAN モデルへのネイティブサポートはありません。FreeBSD 15 の変更後は `network0_mac` フィールドが無効になるため、タップインタフェース作成時に安定した MAC アドレスを設定する必要があります。 総じて、新しいブリッジ＋VLAN デザインは従来の VLAN ごとのアプローチよりも設定が簡単になり、カスタムスクリプトへの依存が減少し、ギガビット速度でのパフォーマンスが向上します（10 Gbps でも潜在的にメリットがあります）。残る懸念点としては、ルーター・オン・ア・ストック構成との互換性があります。

2026/02/23 3:56

「Loopsは、フェデレーテッド（分散型）でオープンソースなTikTokです。」

## Japanese Translation: > Loopsは、現在オープンベータ段階にある企業支配を拒否するオープンソースの分散型短編動画プラットフォームです。分散化されたアーキテクチャにより、ユーザーは単一の企業エコシステムに縛られることなく、独立したサーバ間でコンテンツを共有できます。Fediverseモデルに従い、Loopsはクリエイターとコミュニティに作品とオーディエンスデータの所有権を与えることで力を付与します。このプラットフォームはクリエイターに優しく、広告は一切含まれていません。持続可能性はユーザーによるスポンサーシップから来ており、すべての寄付は開発・インフラストラクチャー・コミュニティイニシアチブへと向けられ、Loopsが独立した状態を保つようにしています。