NetBSD

NetBSD

　NetBSD/i386 6.1.xをベースにデスクトップ用途としてインストールから、その後の利用まで必要と思われる一通りの基本的な情報及びプラスアルファの情報を記してみました。

　メニュー項目の内容に加え、suやsudoの設定、公式なGNOME2/GNOME3、KDE 3.5/KDE4、Xfce4、JWM、Openboxなどはもちろん、将来公式となるかもしれないパッケージ集wipのダウンロードと展開、これによるLXDE(NetBSD的にはlight-desktop)の導入、更に最新のPCManFMやlxde-icon-themeなどについては、ソースコードのtarballをダウンロード・展開した上で./configure、make、make installしてみたり、NetBSDにインストールしたQEMU上でのWindows 95/98/XP、FreeDOS、FreeBSD/OpenBSDなどの起動も行っており、これらのスクリーンショットもあります。

　GNOMEやKDEなど統合デスクトップ環境標準のブラウザやメーラー含む各種アプリはもちろん、Firefox/Seamonkey、ThunderbirdといったMozilla系ブラウザやメーラー、また、ブラウザOpera、セキュアなFTP対応のFilezilla、ドローイングソフトGIMP、多機能メディアプレーヤーVLC。。。といったソフトウェアももちろん使えますし、サービスによっては、Flash Player/Shockwave Playerに完全に依存するケースもありますが、YouTubeやradiko、サイマルラジオ、らじる★らじる、Gyao!の視聴もできます。

　なんなら、WindowsエミュレートするWineも当然、利用できますし、*BSDには、Linux用のソフトウェアをそのまま利用できる何らかのLinuxバイナリエミュレーション機能があり、NetBSDも後述のような多彩なアーキテクチャに対応していることもあり、各カーネルにおけるNetBSD自体のバイナリエミュレーションもLinuxバイナリエミュレーションもできるようになっています。

　また、ウィンドウマネージャでも統合デスクトップ環境でもスキャナはXSaneのインストールですぐに利用可能です。

　一方、amd/Auto Mount Daemon(Automounter)やBSD LPD、LPRng、CUPSはあるものの、統合デスクトップ環境であってもデジカメは、マウントする必要があり、プリンタもひと手間ふた手間かかりますし、VLCメディアプレーヤーのようなオールインワンソフトのプレーヤーを使う場合は、必要ありませんが、そうでないプレーヤーを使いたい場合には、各種コーデックやライブラリ、サウンドサーバなども自身でチョイスしてインストールする必要があったりします。

　これは、NetBSDの魅力の1つでもあるコンパクトかつ強力で洗練されたオリジナルのカーネル+ユーザーランドをベースに必要に応じて随時追加していくことで最小構成のシステムから凝りに凝った構成まで自由にシステムを構築できるというメリットとのトレードオフと言えるでしょう。

　なぜなら、仮に同じデスクトップ用途を望む場合であっても使い方(用途)によって必要なソフトウェアは人それぞれだからです。

　Windows用ソフトウェアなどは尚更ですが、プロプライエタリであるが為に共有しきれず、ソフトウェアごとにライブラリなどを丸抱えすることによるディスク容量の肥大化やライブラリ間の衝突などはフリーズの原因となります。

　Linuxでも中には、インストールすれば何をするにも、すぐに使える手軽なものもあり、Windowsからの乗り換えを含む初心者であっても敷居が低いということもあり、そうではないLinuxよりも人気が高いというか流入者が多い傾向にあるかとは思います。

　そうしたオールインワンタイプは、その結果としてCPU、RAM、そしてハードディスク容量などハードウェア資源の使用率が高くなる為、導入可能なマシンについても、そのハードルが上がると共に余力のないPCに無理に入れても動作が極端に遅くなったり、単体なら使えても他の作業ができなかったり、フリーズ(ハングアップ)する原因にもなります。

　そんな時、人によってそれぞれ必要のないソフトウェアやライブラリなどを簡単にそぎ落とせるとしたなら、同じLinuxの同じ環境を同じマシンに入れても快適に使うこともできる可能性が高いということです。

　ただ、実は、単体、または、依存関係において何が必要で何が不要かの判断に困るものもあったりして、それらの構成に精通するにしても、結局は、最初から入っているものを削ぎ落とすよりも、最小構成から積み上げる方が容易というか、スマートに構成できる場合が多いはずで、そうした場合には、NetBSDやOpenBSD、少し必要なRAM容量はかさみますが、FreeBSD、Gentoo、Arch Linuxのように最小構成を組むことができ、汎用的に使うことが可能なシステムは、重宝するわけです。

　更にGNU/Linuxディストリビューションは、GentooやArch Linuxも含め、Linuxカーネルとユーザーランド(GNUユーティリティ)を共有しているので削ぎ落とすにも限界があり、これらは別として、いわゆる軽量と言われるLinuxディストリビューションは、アップグレードせず同じバージョンのLinuxカーネルを使い続ける、またアップデートせずに同じバージョンのソフトウェアも使い続けることが多く、こうしたものの場合、インストールできるものであってもその状況からLiveメディアとして使うのが妥当、賢明であり、また、これらと併用、もしくは、単独でGNUユーティリティ部分に組込系で使われるBusyboxなどコマンドを集約する技術を使うなどすることでこれを実現しています。

　一方、カーネルとユーザーランドがオリジナルである*BSD、特にNetBSDとOpenBSDは、それらが、とてもコンパクトであり、そうであるように維持されており、フルスペックの標準システムで最小構成から組み上げることができます。

　言ってみれば、レゴやジオラマ、プラモデル、バイクや車のドレスアップやカスタマイズみたいなもの、最初は難しそう。。。と尻込みしたとしても、そこは、好きこそものの上手なれ、やってみれば、それなりに結構できてしまう一方、凝れば、可能性は無限、そんな感じじゃないでしょうか。

　そんなこんなで後述するように、あらゆる面から見ていくとArch Linux系以上に*BSDやGentoo系の、そうは言っても、やはり、*BSDの、中でもNetBSDとOpenBSDの、更には、NetBSDの魅力が、他を上回っているように思えてくる一方、マシンが2台以上あるなら先に挙げたうちの1つ、例えばNetBSDを全てに入れ、その内、1台については必要なら手軽なLinuxやWindows、Mac OS X、もしくは、これらを任意にマルチブートにするとベストじゃないかななんて思う次第です。

備考

　そんな自身は、MS-DOSの利用に始まり、Windowsの使用歴が今尚、最も長く、Linux、Solarisを知った頃もFreeBSD、NetBSDという名をなんとなく聞いたことがある程度、しかも、その頃、すっかり勘違いしており、機能が極めて少ない(機能を絞りすぎて退屈な)MS-DOSと変わらないものという誤った認識を持っていました。

　こうしたイメージの誤りに気づいたり、過去にOSがMS-DOSでCRTモニタのPC-98シリーズ、確かOSがWindows 3.1のTOSHIBA Libretto？だったかdynabookだったかのノートPC、やはり、ノートで発売間もなかったOSがWindows 95、Pentium搭載のSharp Mebiusなど3台ほど処分した後も尚、手持ちのPCが3台となっていた頃、若干遅まきながら、仮想マシンを作成できる仮想化ソフトウェアの存在を知りました。

　それでも、まだ、Linuxの方が身近に感じていましたが、CPU:Intel Celeron 500MHz/RAM:128MBのSOTEC e-oneのOS:Windows 98SEを入れ替えるべく、数多くのLinux/*BSD/PC-UNIXをRAMベースで検証した結果、たどり着いたのは、ロースペックマシンでデスクトップ用途であっても標準的なシステムを稼働可能な*BSDでした。

　中でもNetBSDとOpenBSDのi386版は、Busyboxという組み込み系で利用される苦肉の策を講じている軽量で有名なLinuxよりも低スペックなマシン(PC/AT互換機)で、まして『標準システム』が快適に動作した為、2択となり、その決め手は、うすらぼんやりしたものでしたが、最終的にNetBSDを選択するに至りました。

　当時、物理マシンへのOSのインストール自体、ほぼ初めて、マルチブートももちろん同様、よってブートローダの検証や外付けHDD増設前だったこともあり、ディスク容量が限られ、個々の仮想マシンへの割り振りが不十分だったことなどもあってNetBSD関連だけで10個前後の仮想マシンを使っていろいろ試した後、ようやくe-oneにインストール。

　これと前後して知人からのXPマシン入れ替え話が持ち上がり、CPU:Intel Celeron M 380 1.60GHz/RAM:512MB/FUJITSU FMV C6320のOS:Windows XPを、更に自身のCPU:Intel Celeron M 520 1.60GHz/RAM:512MB/TOSHIBA dynabook Satellite T30 160C5WのOS:Windows XPをNetBSDに入れ替えました。

　その間、Vistaの入ったHDD故障、これに伴い、HDDを入れ替え、RAMを微増強、現状としてCPU:Intel Core 2 1.80GHz/RAM:2GBのHP Pavilion Slimline s3140jpとなったPCをMBRパーティションでマルチブート構成とし、基本パーティション1つをブートローダ(GRUB2)用、1つをNetBSD、拡張パーティションの論理パーティションにFedora(Linux)を入れています(が、まだ、かなり余裕があります)。

　Fedoraを先に入れて若干時間をおいてNetBSDをインストールした関係でVistaのHDDが壊れた後、dynabookに入れたNetBSD、それからHDDを換装したPavilionに入れたFedoraと、めまぐるしくメインを切り替えることになりましたが、PavilionにNetBSDを入れてからは、これにKDE4/GNOME2/Xfce4/(まだ非公式のNetBSD的には、今のところlight-desktopと呼ばれている)LXDE、Openboxを入れ、kdmで切り替え、これをメインとしています。

　これには、後述するように複数台のマシンを効率よく、より最新の状態にアップデートするには、より速いマシンにpkgsrcを展開しておくのが都合がよいという理由もあるので今時の更にハイスペックなマシンを入手するにしてもNetBSDは入れることになるでしょう。

　ただ、NetBSD 6.1.2から入ったNetBSD初心者な自身としては、こうしたことも1台、また1台と物理マシンにNetBSDを入れて使っていく中で後に知ったことであって初めから想定していたわけではありません。

　とはいえ、え。。。wipではなく標準配布されているpkgsrcでも展開後、cvs updateしてもpkgclean(もしくは、パス/usr/pkgsrcでmake clean clean-depends)してもmake installでエラーになるものがあることも珍しくなく、対処して解決できることもあれば、解決できないこともあって、解決できなかった場合、ライセンス上か否かに関わらず、バイナリの配布がなされていなかったりすると正直、脱力してしまうこともあります。

　そんな自身が、NetBSDをメインとしているのは、最小構成から組み上げていくにあたり、できる限り、理解、吸収しながらやっていると新たな発見も多々あり、例えば、Linuxが自動でやってくれることも手動で設定することも多く、いろんな方面に調査が及びつつ、知識の再確認や拡充になり、他に2台ある構成が同一でないNetBSDマシンとのアップデートの連携における最適解を探しつつやっていることなどから必然的に関わる時間が長くなるということもありますが、そうしたことを含め、極めて、おもしろい(興味深い)から、という一言に尽きます(が、これは気力があるからであって、もし、気力が萎えたら手に余ってギブアップする可能性もないとは言いきれませんけどね)。

NetBSDの魅力

　*BSDについては、デスクトップ用途に限って言えば、Linuxほど充実しているとは言えないものの、NetBSDに魅了される点は、*BSD全体の魅力を含めて、いくつもあります。

　そもそも*BSDは、サーバ用途や組込み用途においては、現状でも十分であり、後述のようにNetBSDにおいては尚更であること。

　*BSDは、その名の通り、BSD由来で伝統的、歴史的な香りが漂っていること。(今時点では、人間の年齢で言うとそうでもないが、OSとしては。)

　*BSDでは、1つのスライス(BIOSパーティションなど)の中にBSDパーティションとしてルートやスワップ領域含め、柔軟に配分することができ、マルチブート構成にする場合もスワップ領域を含めてディスク上には1つの(BIOS/GPT)パーティションしか必要とせず、スマートであること。

　*BSDは、カーネル及びユーザーランドがオリジナルであること。

　*BSDは、オリジナルのカーネル＋ユーザーランドをベースにユーザーの嗜好に合わせて最小構成のシステムから構築可能であること。

　同じくLiveCDなどからchroot環境でインストールシステムを構築していくArch LinuxやGentooも最小構成で構築可能も(NetBSDには、これを自動化するpkg_compやmksandboxもあり、更に)、*BSDは、インストール後、一定の初期設定を要するものの、インストーラがある分、(仮にtarballをダウンロードして展開するにしても)導入が容易であること、何れのインストールにも慣れたとしても、やはり、*BSDの方が(再)導入が容易であること。

　*BSDは、数種類あるインストーラは、何れもシェルベースの軽量なインストーラである為、インストーラ用イメージをダウンロードするにもCDやUSBメモリなどに書き込むにも短時間で準備できること。(実はゴージャスなインストーラを持つLinuxであっても探せば同じようなインストーラもあることも多いが。)

　NetBSDのカーネルをアップグレードする場合、インストーラ(sysinst)にアップグレード用メニューがあるのでインストール時と同様に、これを利用することもできること。

　また、sysupgardeなら、sysinstを使う必要もなく、システム稼働中に、これを実行するだけで(、とは言え、念の為、バックアップが推奨されるものの、)既存システムに影響なく、カーネルを生成、対話的に/etc以下のファイルの処理方法を答えていき、再起動すれば、カーネルのアップグレード(バージョンアップ)が完了し、sysinstを使う方法よりも手間が少なく、短時間で済むこと。

(カーネルすらモジュール化され、ソフトウェアのアップデートと一緒にカーネルもアップグレードされ、少なくともその時点では、意識する必要すらないLinuxの方が簡単と言えば簡単。)

　*BSDには、なんらかのLinuxバイナリエミュレーション機能があること。

　NetBSDには、Xenという仮想化ハイパーバイザがあること(FreeBSDにはbhyve、LinuxにはKVMがある)。

　NetBSDは、トースターのような家電、Raspberry PiやザウルスなどのPDAへの組み込み系含め、他のどのディストリビューションよりも幅広くアーキテクチャ及びマシンをサポートしており、それも手伝ってロースペックマシンから(一部、最新ハードウェアの対応が若干遅れることもあれど)ハイスペックマシンまで対応していること。

　CPUにIntel製、BIOSシステム、OSにWindowsを標準採用のPC/AT互換機において64ビット化を急ぐ空気に流され、32ビット(x86/IA-32)すら見放そうとしているディストリビューションも出始め、Mac OS Xに至っては64ビット前提という中、今や最小構成で構築可能なArch LinuxやGentooでさえ、ある時点から実質、既に対象外となってしまったRAM256MB未満のロースペックマシンでも利用可能なi386版をサポートしていること。

　NetBSDとOpenBSD、これよりも若干RAM容量を要するものの、FreeBSDは、LinuxにおけるBusyboxのようなトリッキーな仕組みを使うことなく、性能の低いPCや制約の多い組込み系においても標準システムを円滑に稼働させることができること。

　*BSDは、後でインストールはできるものの、標準システムにbashを含まず、/bin/shは、伝統的なBourne Shell、または、これのクローンである初期のkshをベースとしたPOSIX準拠のshellであり、これを使用すれば、スクリプトや関数を作成するにあたって自ずとプラットフォーム非依存(クロスプラットフォーム)対応のものを作成可能である(GNU/Linuxでは、/bin/shはbashのシンボリックリンクでbashには、POSIXモードがあるも、普段、bashに慣れているとPOSIXモードで書くのは意外と難しい)こと。

　NetBSDには、FreeBSD由来及びNetBSDで改良・追加したものを含むソースコードベースとバイナリベースの両方の管理システムであるpkgsrc及びpkg_add/pkg_delete/pkg_create/pkg_info/pkg_admin。。。、更にpkg_*やpkg*と名付けられた管理ツール、バイナリベースのパッケージ管理システムpkginなど続々と開発・追加され、これらpkg_*/pkg*やpkgin、pkgsrcは、システムを維持する上で一貫性があること。

　pkg_add/pkg_deleteをベースにしつつ、改良及び大幅な機能増強がなされたpkginにおいては、pkgin upgradeやpkgin full-upgradeを使えば、バイナリベースでインストール済みパッケージの自動アップデートも簡単にでき、yum、aptにあるような機能は一通り備える上、pkg_*との併用で尚、一層、機能性に優れていること。

　NetBSD開発のpkgsrcは、元になったFreeBSDのPorts同様、基本的にパッケージごとのディレクトリに移動し、[make]、[make install]、[make update]。。。などコマンド1つ2つで依存関係も解決の上、より最新のパッケージをインストール、アップデート、削除。。。するなどパッケージの管理が、とても簡単なこと。

　更にpkg_selectを使えば、pkgsrcのこれら操作をボタン1つで実行できる上、パッケージ検索、パッケージ説明、依存パッケージ参照などなどのプラスアルファの便利な機能も使えること。

　pkg_selectでも使われているpkgfindを単独で使えば、コマンドラインシェル上でも直接pkgsrcパッケージを検索でき、pkgsrc上のパス、パッケージ名、パッケージの簡易説明を得ることができること。

　pkg_selectまたは、pkgfindの検索結果とpkgin avail、pkgin listにおいてそれぞれgrepを併用した結果を、仮想ターミナルを複数並べることで見比べながらインストールやアップデート、アンインストールすることもできること。

　pkg_admin audit、pkg_admin fetch-pkg-vulnerabilitiesを使えば、日々発見される可能性のある脆弱性のあるパッケージの情報を得ることができ、当該パッケージを削除するなど対策を講じることができること。

　cvs updateを使えば、pkgsrcのアップデートを簡単に行なうことができること。

　pkg_chkやpkg_rolling-replaceを使えば、pkgsrcのソースコード情報を基にインストール済みパッケージの自動アップデートを行なうことができること。

　cvs update後、pkg_chkやpkg_rolling-replaceを使ってアップデートすれば、バイナリによるアップデート以上にシステムを最新に維持できること。

　この時、同時にバイナリを生成しておけば、入れなおすにしてもバイナリを元にインストールでき、マシンが複数台ある場合、他のマシンについては、NFS、Samba、HTTP、FTPなどを介してバイナリを使ってアップデートすることで最新の状態に維持できること。

　pkg_infoを使えば、コマンドラインシェル上でも、一覧や個別に、より詳しくパッケージの情報を得ることができること。

　pkg_*/pkg*には、他にも依存関係のないパッケージを洗い出し、一括削除するものなど便利な管理ツールがたくさんあり、これを利用できること。

　こうしたpkgsrc、pkg_*、pkginを開発後、すぐに汎用として公開しており、Linuxや*BSD、FreeBSDを基盤とするDarwinベースでNetBSD/OpenBSDの成果も多く取り入れているMac OS X、Solaris、OpenSolaris、実質、その後継となるOpenIndiana/Illumosなど、あらゆるプラットフォームで容易に導入、利用できること。

　そうした仕組みを持たない多くのLinuxにも簡単に導入できること。

　これにより異なる環境下でも一貫した操作性を保つことも可能であり、対応アーキテクチャ・対応マシンが多彩、古いマシンから新しいマシンまで対応と裾野がとても広いこと。

　NetBSD(pkgsrc/pkg_*/pkgin)、FreeBSD/OpenBSD(Portsとpkg_*(pkgngへ移行中))、Gentoo(Portageとemerge)においては、ソースベース／パッケージベースのパッケージ管理システムを何れも備え、インストールはもちろん、何れにおいてもインストール済みパッケージの自動アップデートもできること。

　特にサードパーティ製ソフトウェアの場合、バイナリでは、常時、本家とディストリビューションのリポジトリの同期が取れるわけではないことから、ソースベースでアップデートできることは、結果、システムを、より最新に維持できるということであること。

　これにより、巷の最新サービスを利用するにあたり、某サードパーティ製ソフトウェアの最新版を要求されるケースなども比較的容易に対応可能であること。

　同じく、ライセンス上、バイナリでの配布はできないが、ソースコードでの配布が許容されるようなソフトウェアの導入も容易であること。

　同じく、自身のマシンを最適化する為にコンパイルオプションを付与した上でのコンパイル、インストールも容易であること。

(少なくとも執筆時点までは、Debian系やRed Hat系、Arch Linuxもソースコードのパッケージ管理システムを持つものの、何れもソースコード情報を元にしたインストール済みパッケージの自動アップデートには対応していない。)

　pkgsrcに公式に登録されていない場合でもpkgsrc.seやsourceforge.netに正式登録を目指すものや公式にする程でもないが必要な人には必要なパッケージ、テスト中のパッケージ等を収録した[wip]があり、これを利用することができること。(FreeBSD/OpenBSDの各portsにも別途wipはある)

　なんならpkgsrcを自分で作るにあたってport2pkg、rpm2pkg、url2pkg等々を使ってPortsやrpmなどからその素地を作成することもできること。

。。。等々でしょうか。

ちなみに

　pkgsrcもさることながら、汎用のソースベースのパッケージ管理システムには、Finkもあり、GNU SRCもリリースされた模様である中、未だ多くのLinuxディストリビューションは、このようなパッケージ管理システムを採用することに躊躇している、というより、特に初心者はソースベースを敬遠しがちでユーザーの裾野を広げることにはならないとの考えからか、そもそも前面に出す気がないようにすら見受けられます。

　しかし、近年、次期Windowsであり、期間限定でアップデートを無償化すると言われているWindows 10においては、OneGetなるサードパーティ製ソフトウェアのパッケージ管理システムの標準採用の噂もあり、これが実現するとバイナリパッケージ管理システムは、OS・ディストリビューション問わず、もはや、当たり前の機能となります。

　こうしたことを考慮するにしてもしないにしても、より早い段階でソースコードベースのインストールにおける柔軟性と有用性、アップデートの利便性やセキュリティ上の重要性などを広く伝えた方が、なんなら積極的に伝えないまでも*BSDやGentooのようにArch Linuxについては、Arch Build Systemを使うなりしてソースコードベースの自動アップデートもできるように、他の多くのLinuxは、こうしたパッケージ管理システムを標準採用しておくのが賢明だと思います。

　*BSDも、中でもNetBSDも、もっと何かと話題にのぼり、ネット上でも広く活発に情報交換がなされていても(開発者やユーザーによるいろんな情報がもっとたくさん散らばっていても)よさそうなものですが、それほどでもないところが不思議で仕方ありません。

　尚、全く別の視点から手軽かつ*BSDでは、まだ実装がなされていないような特に先進的なパッケージも積極的に導入するDebian系やRed Hat系ディストリビューションの内どれか1つあれば、補完という意味も込めて十分なのではないかという観点から個人的には、最終的にFedoraを選択しましたが、結果的に実装の確認という意味でも役立っています。