気の向くままに辿るIT/ICT/IoT
システム開発

*BSD/PC-UNIX/Linux

ホーム前へ次へ
*BSD/PC-UNIX/Linuxって?

*BSD/PC-UNIX/Linux

*BSD/PC-UNIX/Linux

 *BSD/PC-UNIX/Linuxは、UNIX風のOS機能を成すものの総称ですが、*BSD/PC-UNIXはカーネルとユーザーランドがオリジナルであるのに対し、Linuxとは、本来、Linuxカーネルを指し、ユーザーランド(カーネル以外の部分で起動やその後の利用に辺り、最低限必要となるコンパイラなどを含む一式)としてGNUユーティリティを組み合わせた、いわゆるGNU/Linuxが主流となっていることやLinuxカーネル登場の背景など若干その生い立ちに違いがあります。

*BSD/PC-UNIX/Linuxの歴史概略

 UNIXとは、1969年アセンブリベースで開発、移植性を高めるべく、1971年から1972年にCベースで書きなおされ、当初無償だったUNIXもその後商用リリースされる製品が出始めます。

 UNIXの1つとして、例えば、BSDの主要開発者が1982年に創立したSun Microsystems社がリリースしたSunOS(1990年初め頃、これをSolarisと改名)があり、2005年には、オープンソース版OpenSolarisをリリース、2010年、Sun社がOracle社に買収されるとOpenSolarisプロジェクト存続における懸念が大きくなり、後継となるべく、OpenIndiana/illumosプロジェクトが発足、いくつもの派生プロジェクトがあります。

 PC-UNIXとは、Intel製CPU、OSとしてMS-DOS/Windows、ファームウェアとしてBIOSを採用したIBM PC/AT互換機上で動作可能としたUNIXです。

 *BSDは、当初、無償だったUNIXが出願特許の認可により、ロイヤルティが必要となり、当時、大学での研究などに使うには相当高価だった為、安価に利用できるようにしたいという思いに端を発し、1977年に開発されたBSD/Berkeley Software Distribution及び、これに由来するものを指します。

 BSDがUNIX特許係争に至ると自由に使えるものを求め、ジョリッツ夫妻が1992年386BSDをリリースするも手に追い切れず更新が止まったこと、他方、係争中のBSDが、4.2BSD、4.3BSDとバージョンを重ね、これをベースに1993年にNetBSD 0.8がリリース、1994年には、FreeBSDが、これらが1994年リリースされたUNIX特許に抵触しないと認められた4.4BSD-Liteを基に再構成された後、1995年NetBSDから分離・独立したOpenBSDが登場しています。

 Linuxは、本来、カーネルを指し、1987年に開発されたUNIXの特許を回避する形でアンドリュー=タネンバウム氏が考案/開発した教育用Minixを広く利用できるOSにできないか。。。とリーナス=トーバルズ氏が1991年に発表したカーネルを基に有志が手を加えたことで実用化レベルに至り、これをベースとしたディストリビューションが登場しはじめ、1992年にSLS/Softlanding Linux System、1993年にDebian Linux ReleaseやSlackware Linuxのベータ版、1995年にRed Hat Linuxのリリースなどを経て今に至っています。

 そんなMINIXは、その後、NetBSDの成果を次々と取り込んだことでNetBSDと互換性を持つに至り、近年、欧州連合より助成金を受けることができることになったことからMinix 3/MINIX 3からは、教育用に留まらず、汎用でx86、ARM対応のフリーソフトウェア・オープンソースとしてリリースされるに至っています。

 Mac OS 9からMac OS X 10.0に移行したMac OS Xは、FreeBSD+Mach 3.0を基盤とするDarwinをベースとしたUNIXライクなOSでNetBSDやOpenBSDの成果も数多く取り入れられ、Mac OS X v10.5 Leopardからは、正式なUNIXとして認証を受けるに至っています。

*BSD/PC-UNIX/Linuxとは

 *BSD/PC-UNIX/Linuxの成り立ちは前述の通りですが、各フレーズの意味するところを改めて簡潔に記すと次のようになるでしょう。

 PC-UNIXとは、IBM PC/AT互換機上で動作するUNIXのことを指す便宜的な総称(通称・俗称)です。

 *BSDとは、BSD/Berkeley Software Distribution由来のFreeBSD/NetBSD/OpenBSD...etc.を指す便宜的な総称です。

 Linuxとは、本来、カーネルである一方、Linuxカーネルを使った数多く登場したディストリビューション群の代名詞・総称でもあります。

 ここでは、主にPC/AT互換機における*BSD/PC-UNIX/Linuxについて触れますが、*BSDやLinuxは、家電や携帯電話、PDA端末、スマホといった組み込み系などの環境でも動作します。

 特にNetBSDは、複数のアーキテクチャに対して同一ソースコードで対応し、同時リリースできる無駄のない洗練された美しいソースコードにより、UNIXマシンやPowerPC(Mac OS)等々、その対応アーキテクチャ・対応マシンは、数十種類に及び、多彩で移植性の高いOSとして知られています。

フリーソフトウェアとオープンソース

 途中、UNIX特許など係争はありましたが、他方でUNIX周辺においては、フリーソフトウェアの文化が根付いており、そうした中では、元になるソースコードも公開されます。

 ただし、フリーソフトウェアとオープンソースは、必ずしも同一ではありません。

 フリーソフトウェアのフリーとは『自由』という意味に重きを置いたフレーズであり、もちろん、インターネット経由などであれば、ソースコードも『無料』で入手することはできるわけですが、例えば、雑誌や書籍に付属のインストールCD/DVDは、普通、書籍代に含まれているというだけで無料配布されているわけではなく、その収益は、フリーソフトウェアの開発に当てられ、プロジェクト存続の原資の1つとなっています。

 いざ、『自由』を定義しようとすると実は、難しかったりしますが、これらを定義する(定義しようと試みる)BSDライセンスやGNUのGPL系ライセンスやApacheライセンスなどによって『入手、改変、再配布』などにおいてそれぞれ一定のライセンスの下で自由であることを目指しています。

 一方、オープンソースには、例えば、「自社の有償製品へのフィードバックを目的に広く使ってもらいたい為、ソースコードは公開するが、権利はベンダ(提供者)側にある」といったものも含まれます。

 よってフリーソフトウェアにおいては、オープンソースという意味合いも含まれますが、その逆は必ずしも成り立たないので、これらの用語を混同しないように注意する必要があります。

 ちなみにWindows用のソフトウェアにおいて無料のものをフリーソフトウェアと呼ぶ場合がありますが、この場合、まず、ソースコードの公開がなされることはなく、ソースコードを入手することもできず、改変も許されず、個人使用は自由であっても商用利用は連絡を要すか、有償だったり、権利も放棄しないとするものも多く、ここで言う用語とは全く一致しないという点も留意が必要でしょう。

 そんなWindowsやMac OS X/OS Xは、商用/プロプライエタリ(ベンダ/製品提供者が独占的な権利を持つ)OSとしてフリーソフトウェアと区別して認識されることがあります。

 ちなみにOS X v10.9 Mavericksからはアップデートが無償となりましたし、次期リリースのWindows 10では時限付きながら一定期間は無料アップデートを実施する予定のようですが,プロプライエタリであることに変わりはありません。

ディストリビューション≒カーネル+ユーザーランド+その他ソフトウェア

 こうしたU*IXライクなOSを始めとするフリーソフトウェアの世界では、OS機能と言えば、『カーネル』(OSの核となる部分)と『ユーザーランド』(明確な定義があるわけではなく、その境界は曖昧も各種コンパイラやユーティリティなど一式)を指します。

 *BSDやPC-UNIXは、それぞれBSDやUNI*に由来し、どちらも独自開発及びメンテナンスしています。

 一方、Linux(GNU/Linux)は、前述のように(Linuxカーネル+GNUユーティリティの)どちらも共用しています。

 これらに任意の各種『サードパーティ製ソフトウェア』を加えて配布されるものは、『ディストリビューション/ディストリ/ディストロ』(配布物)と呼ばれています。

 サードパーティとは、第三者という意味であり、サードパーティ製ソフトウェアは、他の任意のプロジェクトや企業・団体がリリースしたソフトウェアのことを指します。

リポジトリ

 カーネルやユーザーランドが異なると当然ながら、システムに含まれるコマンドが異なったり、同名のコマンドがあったとしてもオプションが異なるケースもあり、Linuxは、これらを共有している為、基本的に同じですが、Linuxと*BSDが異なるのはもちろん、FreeBSDとNetBSD、OpenBSD間も異なることは珍しくありません。

 「基本的に」というのは、Linux/*BSD/PC-UNIXに関わらず、カーネルについては、カーネルパラメータによる調整を行なうことも可能となっており、そのバリエーションは多岐に渡るものの、これを以って特徴とするディストリビューションは、あまりないと思いますが、他方、リリースされたそのままのカーネルは、特にバニラカーネルと呼ばれ、Linuxの中には、バニラカーネルであることを特徴としているディストリビューションはあります。

 これは、Linux間でも*BSD間でも、同じだったり、似ている部分もあるものの、基本的にソースコードや、そこからコンパイルして生成されるバイナリも異なることを意味します。

 こうしたこともあり、各ディストリビューションでは、ユーザーが自由に利用できるように、これらのソースコードやバイナリパッケージをまとめておいておくのが一般的となっており、その場所を指して『リポジトリ』と呼ぶことがあります。

 各ディストリビューションごとのリポジトリは、名称は様々ですが、公式/標準、コミュニティ版、開発段階、テスト段階といったように分類され、複数存在するケースも多く、実際には、HTTPサイトやFTPサイト、バージョン管理システムCVS/Concurrent Versions SystemやSubversion、Gitなどに収録され、インターネットを介して取得できるようになっています。

 また、サードパーティ製ソフトウェアによっては、Linux用、FreeBSD用、NetBSD用(、Mac OS X用)...といった具合に各ディストリビューション用のリポジトリを公開している場合もあったりします。

 ただ、リポジトリとは、データの貯蔵庫という意味合いであり、インターネットを介したものに限らず、CD/DVDに収録されたもの、また、ローカルマシン上でもこのような用途としてまとめたディレクトリがあれば、それもリポジトリと呼ばれることもあります。

各ディストリビューションの特徴は?

 *BSDやPC-UNIXは、カーネルとユーザーランドがオリジナルである点が第一の特徴となり、それによる個性も特徴として際立つこともありますが、これらを共有しているLinuxは、カーネルがバニラカーネルか否かの違いはあるにせよ、基本的に、その特徴は、これら以外のところに見出しています。

 サードパーティ製のフリーソフトウェアは基本、自由に選択できるので利用できるか否かは、ディストリビューションの対応次第ですが、特に人気がある、有用性が高いソフトウェアについては、どのディストリビューションも対応するよう努めますから、基本的にどれをチョイスするかは、特徴とはなり得ません。

 ただ、広く開かれた活発なプロジェクトには、人も集まり、開発者も多く、更にその歴史が長ければ、そのプロジェクト用のパッケージ作成者も多い可能性という統計的な部分では、例えば、Linuxの中でもDebian系は特に群を抜いて対応パッケージが多いということはあり得ます。

 一方、それは、往々にして初期の段階での話であってFreeBSDのPorts、その派生OpenBSDやDragonfly BSDのPorts、Macports、NetBSDのpkgsrc、これとは別にRed Hat系のrpmなどソースコードを扱う手法は、共通部分も多いことから、変換プログラムで大方のところは変換、その後、調整するという形で取り込むケースも多々あり、これは,既に多くのパッケージを持つディストリビューションも言えることなのでなんですが、マンパワーや時間軸の差こそあれ、時間と共に対応するソフトウェアも増えていく傾向にあります。

 また、中には、パッケージ作成者が企業・団体だったり、そうしたスポンサーがついていて余力もあり、多くの人々に使って欲しいという場合、例えば、VLCメディアプレーヤーのようなケースでは、初めから開発元がDebian系Linux/RedHat系Linux/FreeBSD/NetBSD/Mac OS X/Windowsなど各種ディストリビューションやプロプライエタリOSに対応している場合もあります。

 *BSDに関しては、Linuxに限らないものの、バイナリエミュレーション機能があるので全てとは言わないまでも*BSD上でLinux用バイナリをそのまま実行できたりもします。

 *BSDでもLinuxでもWindowsをエミュレーションするWineも利用できます。

 こうした渦中に利用可能なソフトウェアという視点でディストリビューションを選択する可能性という点では、当該ディストリビューションの特徴と言えなくもありませんが、近年、多いと20,000〜30,000種類、少ないと言っても3,000種類もあると余程ピンポイントなニーズでもない限り、実のところ、あれがなくて困るというケースは、ほとんどないと思われる一方、個人利用においては、「多いに越したことはない」ということが決定打となっているケースは多いのかもしれません。

 さて、こうした点については、最もわかりやすく、目につきやすい部分であり、これを以って主な選択基準としてしまうケースも少なくないでしょう。

 しかし、実は、これだけでは、不十分であり、重要な視点が欠けていると言えます。

 今や多くの人々にとってOSは、あって当たり前、機能して当たり前、便利に使えて当たり前。。。のものであって特に思い入れなどもないでしょうし、場合によっては、意識したことすらないというケースもあることでしょう。

 こうした幅広いユーザーの中には、そもそもLinux/*BSD/PC-UNIXと言われてもピンと来ないけど、Windowsのセキュリティサポート期限が切れるにあたって次のWindowsはスペック的に入らないけど、PCはまだまだ使えそうだ、代わりに無料で使えるモノがあるって聞いたから、使ってみたいというケースもあることでしょう。

 仮にそうした場合であっても重要なのは、「Windowsのセキュリティサポート期限が切れるから」「代わりに使ってみたい」という部分です。

 この場合、代替品を欲するのは、無料だからという以前に使っていたOSの「セキュリティサポートが切れるから」です。

 ところが、特にWindowsのみの使用体験しかないユーザーなどWindowsが自身の中のOSの常識となっていたりすると、そもそもの動機を解決する為の視点が抜けてしまうことが多いのです。

 Windowsユーザーは意識しないことも多いですが、Windowsは、セキュリティサポートされていたとしても実は、サードパーティ製ソフトウェアの管理システムがない点でLinux/*BSD/PC-UNIXよりも脅威に対して脆弱です。

 これは、PCを買った時にWindowsと一緒に入っていたサードパーティ製ソフトウェアも、購入後、後からどこからともなくダウンロードしてインストールしたものも含めた全てのパッケージ管理システムです。

 いやいや、Windowsにも。。。と思うかもしれませんが、少なくともWindows 8.1までは、自動で行われるのは、WindowsやIEなどMicrosoft社のソフトウェアのセキュリティアップデートであってサードパーティ製ソフトウェアの為のものではありません。

 一部の大手が提供するサードパーティ製ソフトウェアについては、個々に自動アップデートなどが行われることがあったとしても、それ以外は、そうしたサポートは普通ありませんし、逆に全てのソフトウェアが個々にアップデータを持ってアップデートしていたらWindowsで管理しきれないどころか、システムリソースを消費し過ぎて何をするにも動作が重くなったり、Windows自体がフリーズしてしまうことでしょう。

 OSだけでなく、サードパーティ製ソフトウェアにも、セキュリティ上の脆弱性はあり、OSと同等以上に脅威となり得るものも含むので、こうしたことは、セキュリティという点では致命的です。

 ちなみにMicrosoft社は、次期Windows 10には、開発中だったOneGetというサードパーティ製ソフトウェア用の管理ソフトを標準搭載する予定のようです。

 一方、Linux/*BSD/PC-UNIXは、サードパーティ製ソフトウェア用のパッケージ管理システムを持つものが主流です。

 主流という表現を使ったのは、OS自身についてもサードパーティ製ソフトウェアについてもソースコードをコンパイル済みのバイナリ(二進数に置き換えられた人間が読むには一般的ではない形式)だけを扱うWindowsとは、状況が違うからです。

 少なくともフリーソフトウェアであるLinux/*BSD/PC-UNIXにおいては、ソースコードも公開されており、直接ソースコードを扱うことができ、Linux/*BSD/PC-UNIXの中にもというか、*BSD/PC-UNIXは、次の6項めが前提となっていますが、Linuxにおいては、数通りあります。

  1. 伝統的な手作業でソースコードを扱うことを前提としたもの
  2. ソースコードのみを扱う前提で一部の手作業を省くことができるソースコードベースの簡易パッケージ管理システムを持つもの
  3. 伝統的な手作業でソースコードを扱うことはできるが、バイナリ用のパッケージ管理システムを主体とし、インストール済みパッケージの管理において一貫性のないもの
  4. ソースコードベースの簡易パッケージ管理システムとバイナリ用のパッケージ管理システムを持つが、後者を主体とし、インストール済みパッケージの管理において一貫性のないもの
  5. ソースコード用パッケージ管理システムもバイナリ用パッケージ管理システムも併せ持つが、インストール済みパッケージの管理において一貫性のないもの
  6. ソースコード用パッケージ管理システムもバイナリ用パッケージ管理システムも併せ持ち、かつ、インストール済みパッケージの管理において一貫性のあるもの
  7. ...etc.

 Windowsから乗り換える場合は特に、こうしたことを知る前に、仮に情報として少し知った後も往々にして「インストールすればデスクトップ環境が起動する」、「そこそこのソフトウェアが最初から入っている」、「利用者が多く(多そうで)ドキュメントやコミュニティによるQ&Aなどが充実している」、「ログインシェルや仮想ターミナルを意識せずに利用できる」。。。などの条件で探し、選択する結果、Debian、Ubuntu、Linux Mint、CentOS、Fedora、OpenSUSEといった4項めのディストリビューションに、マシンスペック的に制約がある場合には、Puppy Linux、Damn Small Linux、Tiny Core Linuxなど3項めのディストリビューションに辿り着きがちです。

 その選択は、別に間違いではなく、そもそも悪意を持つものからターゲットとされやすいという説を前提とするならWindowsよりもLinux/*BSD/PC-UNIXの方が、安全といえば安全ですし、ましてサードパーティ製ソフトウェア用のパッケージ管理システムを持つLinux/*BSD/PC-UNIXなら尚更です。

 ただ、簡単に言えば、万能であるに越したことはないのでバイナリによる管理を望む場合であっても、すぐに馴染めるか否か、すぐに利用するか否かに関わらず、これと併せてソースコードも扱うことができるものを、もちろん、その扱いを容易にしてくれるパッケージ管理システムを持つものを、更にバイナリを基にしたかソースを基にしたかに関わらず、一貫性をもってパッケージを管理することを考慮したディストリビューションを選択するのが賢明と言えます。

 これは、ディストリビューションごとのリポジトリにあるバイナリパッケージが、特にサードパーティ製ソフトウェアの場合、本家と比べて常に最新の状態にあるわけではない、というより、そうでないケースも多いことが1つの理由です。

 1つは、フリーソフトウェアの世界には、ソースコードでの配布は許容されるものの、バイナリでの配布を禁止しているものもあることです。

 前者においては、最新のソフトウェアが必要な場合、後者においては、これ自体を必要とする場合、ソースコードからコンパイルすることになる為、これを容易にしてくれるソースコードベースのパッケージ管理システムがあるに越したことはありません。

 また、より精通してきて、ソフトウェアを最適化したいといった場合、バイナリではできませんが、コンパイルオプションを指定してソースコードからコンパイルすれば、これを行なうこともできます。

 現時点で、これに該当するのは、Portsとpkg_*/pkg*を採用しているFreeBSD、OpenBSD、pkgsrcを持つNetBSDやOpenIndiana/Illumos、MINIX等々、Linuxでは、Portageとemergeを持つGentoo系くらいでしょう。

 尚、Debianではdpkg、RedHat系にはrpmやyumで、Arch Linuxには、ソース用にArch Build System(ABS)、バイナリ用にpacmanを持ち、ソースも扱うことができますが、ソースコードを基にしたインストール済みパッケージの自動アップデートほかパッケージを一貫して管理することが考慮されていないので除外します。

 Microsoft社がWindows 10とは限らず、将来的には、Windowsのオープンソース化もあり得るニュアンスのアナウンスをしたのは、この辺りを見据えての牽制であって世の中がクラウドにまっしぐらとなれば、別ですが、時が経つほどに万全なセキュリティなんてあり得ないイタチごっこ状態にある中、クラウドというのは、雲というより、絵空事であり、有無を言わさないほどの世にも奇妙な怪しい強大な力でも働き、クラウド推進プロパガンダによって誰もが思考停止でもしない限り、そこまでの浸透は、あり得ないと思われ(るものの、BYOD/Bring your own deviceについては、こうした力が働いたようなので微妙で、あり得ないとも言えませんが、)、クラウド、ひいては、Azureの大盛況なしでは、Windowsの無償化は成り立たず、そうであれば、Windows自体の収益がガタ落ちしない限り、それはそれで課題が残るでしょうから、何れにしてもWindowsのオープンソース化は現実的な話ではないでしょう。

 これらは、何れもサーバ用途でもデスクトップ用途でも使え、デスクトップ用途については、GNOMEやKDE、Xfce、LXDEなども使えますし、これらのベースでもあり、より低スペックなマシンなど必要なら単独でデスクトップとしても利用可能なウィンドウマネージャは多岐に渡ります。

 仮にマシンスペック上の制約がある場合でも、しばしば軽量と言われるTiny Core LinuxやPuppy Linuxと同じウィンドウマネージャをNetBSDやOpenBSDにインストールした場合、NetBSDやOpenBSDの方が軽快に動作します。

 Damn Small Linuxは、より軽量だったりもするものの、挙げればキリがありませんが、トリッキーな軽量化ではなく、標準システムで動作する、プロジェクトが活発であるという点だけをとってもNetBSD、OpenBSDという選択肢の方が現実的でしょう。

 ざっと調べた限り、NetBSDとOpenBSDは、ログインシェルでRAM24MB、JWM、Openboxといったウィンドウマネージャなら32MB、Fluxboxで48MBで軽快に動作、Linuxでは、JWMとFluxboxを採用したDamn Small LinuxがRAM64MBで動作するものの、Tiny Core LinuxはアプリなしのTinyCoreで128MB、アプリ込みのCorePlusは、256MBは必要、Puppy Linuxは、128MBでも動作しないこともないものの、256MBは欲しいところです。

 尚、オリジナルのカーネルとユーザーランドを持つNetBSDとOpenBSDは、これらが標準システムであるのに比し、前述の通り、カーネルとユーザーランドを共有するGNU/Linuxにおいては、ディストリビューションごとに軽量化を図ることができる部分は皆無であり、組み込み系用途にLinuxを使う場合のトリッキーな特殊な方法としてBusybox(ユーザーランドとして裏方でBusyboxという1つのコマンドをラッパとして多くのコマンドを実装することで容量を節約する仕組み)を使ってこれを実現しています。

 更にこうした軽量化に特化したLinuxディストリビューションにおいては、Linuxカーネルは2.4や2.6固定だったり、ソフトウェア、特に時代と共に進化及び使用リソースの増加著しいブラウザもアップデートせずに古いものを使うことが前提となっています。

 近年、要求されるシステムリソースが、ブラウザやウィルス駆除ソフトなどサードパーティ製ソフトウェアに左右される点については、*BSD/PC-UNIX/Linux/Mac OS X/Windowsなど何れも同じと言えますが。

 他方、各ディストリビューションは、個々に目標や目的を定めてプロジェクトが発足するわけですが、その目標・目的によっては、継続サポートすることが難しいことも多く、達成したらそこで終わってしまうこともあり得、軽量化に特化することも例外ではなく、プロジェクト自体が、それほど活発ではないか、いつ次のアクションがあるか不明、実質停止してしまっているケースも珍しくありません。

 このように古いLinuxカーネル、古いソフトウェアを使い続けることが前提、そのプロジェクトは停止状態。。。となるとセキュリティ面において大きな不安が残る点は否めません。

 そういった点で軽量化を望む場合でもカーネルとユーザーランドがオリジナルであり、新規開発、改良、セキュリティパッチ適用、ある時点でのセキュリティパッチ吸収・統合、アップグレードがなされ、継続サポートされる前提の標準システムが動作するということは、ユーザーにとっては、かなり、重要なポイントと言えます。

 まして軽量化に特化したものよりも軽量・軽快なわけですから、本来、選択の余地はないでしょう。

 ただ、派生ではなく、オリジナルのFreeBSD、NetBSD、OpenBSD、Gentoo(、Arch Linux)については、最小構成のシステムを構築できることもメリットの1つです。

 これには、例えば、万人がデスクトップを必要とするわけではないので、基本的にインストール直後は、ログインシェルのみ利用可能な状態で、ウィンドウマネージャやデスクトップ環境が必要な場合、手順は明快なものの、自身でインストール及び設定する必要があるといったことも含まれます。

 一方、これらの派生には、最初からウィンドウマネージャやデスクトップ環境を提供するプロジェクトとしてFreeBSDには、PC-BSD...、Gentooには、Sabayon Linux...、Arch Linuxには、ArchBangやManjaro、Chakra...といったものもあり、Live版も用意されているものもあるので、これらを利用するという手もあります。

 こうしたものは、往々にして仮想ターミナル(仮想端末)の利用が、前提となりますが、そこさえクリアすれば、とても魅力的な選択肢となるはずです。

 マシンスペックと合致しないとか、話がピンと来ないとか、まだ、ちょっとハードルが高いといった場合には、致し方ないですが、何れは、こうしたディストリビューションをメイン、もしくは、サブとして利用することを検討してみると良いのではないかと思います。

*BSDとLinuxの比較

 *BSDとLinuxについては、歴史的な違い、*BSDがあらゆる方面で利用されていたり、広く技術的な基盤となっていること、標準システムがコンパクトであること、パッケージ管理が理に適っていること等々といった点で*BSDが、Linuxディストリビューションより優位な点が多いことは前述の通りです。

 ただ、パッケージ管理に限定すれば、Gentooは、*BSDと同じようなスタンスをもっています。

 *BSDとGentooを強いて比較するなら次のような点が挙げられるかもしれません。

 ディストリビューション自体のインストールという点では、対応アーキテクチャが多彩で非力なマシンからハイスペックマシンに至るまで幅広く対応する*BSDでは古めかしいながらもインストーラがある分、自由度が高いがゆえにLive版などからchroot環境で構築していくGentoo(やArch Linux)よりもインストールが容易と言えるかもしれません。

 他方、ディスク全体にクリーンインストール及びフルインストールすれば、とりあえず、意識する必要はなくなるものの、*BSDには、スライス(BIOSパーティション)内にBSDパーティションを作成する必要があり、これをディスク全体を使うことなく、1つのBIOSパーティション内で柔軟に配分できるというメリットがあります。

 尤もマルチブートしない場合はメリットとはなり得ないととらえることもあるでしょうし、これを難しいととれば、デメリットとともなり得ますが。

 尚、chroot環境での作業は、Linux/*BSD/PC-UNIXにおいては、インストールに限らず、システムアップグレードの方法の1つとして、また、仮想マシンのような使い方としてやオリジナル含むLive版作成時など何かと有用なので何れを使うにしても、ゆくゆくは覚えておくに越したことはなく、NetBSDには、pkg_compやmksandboxといったchroot環境を自動構築するコマンドがあったりします。

 ソースコード情報を基にインストール済みパッケージをアップデートするにあたっては、ソースコード情報のアップデートもemergeで管理できるGentooの方が、cvs updateをしてからpkg_chkやpkg_rolling-replaceを実行するNetBSDよりも一貫している感もあり、スマートと言えるかもしれません。

 リリーススケジュールに関しては、*BSDは、これまで最小限のシステムリソース要求スペックを維持しつつ、ある程度、一定周期でリリースされているのに比し、Gentoo(やArch Linuxなど)は、ローリングリリースです。

 ローリング・リリースは、ユーザーがリリースを意識する必要なく、日常的にアップデートする中で新たなリリースの差分が取り込まれるわけですが、インストール時にマシンスペックがギリギリであった場合には特に、気をつけないとたいした時間も経過していないのに、ある日突然、要求されるシステムリソースのスペックがあがっていてアップデートしたら起動できないとか、いざインストールしようにもできなくなっていたなんてことも起こり得る(参考)ものと思われ、アップデート時に、これを承知している場合には、マシンスペック上の制約がある以上、一部の更新に留めるか、更新することなく、古いまま使用せざるを得なくなるでしょう。

 こうしたリリース形態でなくてもマシンスペックを超える可能性はあり得るものの、普段通りアップデートしてみたら・・・という事態にはなり得ませんし、Gentooの場合、LinuxカーネルやGNUユーティリティといったある種外部の影響は避けられませんが、これらがオリジナルの*BSDでは、これ(外部の影響で標準システムが肥大化すること)はあり得ません。

 この時、他に乗り換えるくらいなら、初めから、少しでも余裕のある、また、リリースの傾向などから、こうしたことが起こりにくいディストリビューションを選択しておくのが賢明と言えるでしょうし、そうしたケースにおいてもFreeBSDはともかくもNetBSDやOpenBSDは最適です。

 対応パッケージ数で言うと*BSDよりもLinuxの方が多いイメージがあるかもしれませんが、Debian、Ubuntu、Mintあたりに限定される話であってRed Hat系と言えども*BSDともさほど遜色なく、FreeBSDに至っては、Debian系と比較してもさほど遜色ないと言えるでしょう。

 クロス環境での利用という意味では、*BSDは、カーネルとユーザーランドがBSD/Berkeley Software Distribution由来でオリジナルである為、[/bin/sh]は、純粋なBourne Shell、もしくは、その後、/bin/shの独自拡張が散見されるようになったことから、このクローンkshの初期のものをベースに標準規格化されたPOSIX 1003.x系準拠である一方、GNU/Linuxでは、デフォルトシェルがなんであれ基本bashは標準インストールされており、[/bin/sh]は、普通、GNU Bash/Bourne-Again Shellのシンボリックリンク(実体はbash)でposixモードもありますが、常にposixモードを使わない限り、混在する可能性、文法が混乱する可能性がありますが、*BSDならbashとの混同は基本的にないというメリットがあります。

 これに関連し、FreeBSD/NetBSD/OpenBSDにおいては少なくともbashを標準シェルとしているものはなく、それぞれbashのインストールも可能も(サードパーティ製パッケージの依存関係上、インストールされることはあるにしても)標準インストールはされない為、2014年09月発覚したbashの脆弱性に基づくShellShockの影響は限定的だったことでしょう。

 同じく脆弱性を指摘されたOpenSSHやOpenSSLは、OpenBSDの成果物ですが、これは*BSD、Linux問わず、重宝され、広く利用されていたという意味で比較にはならないので除外してよいでしょう。

 尚、ここでは、GNUオリジナルのカーネルによるGNU/HurdやMach3+FreeBSDから成るDarwinをベースとしたMac OS X/OS X、更にOSを超えてファイル共有できるFreeNASがFreeBSDベースであったり、また、Debian/NetBSDやDebian/kFreeBSD、Gentoo/FreeBSD、Arch BSDといった*BSDカーネルとGNUユーティリティを組み合わせようという試みにおいては、各*BSDやGNUが主体で行なうならまだしも、Linuxカーネルを使わないのにLinuxディストリビューションが主体で行っているというのも、よく考えると不思議といったことなどについては、さておきます。

FreeBSD/NetBSD/OpenBSDの比較

 *BSD(FreeBSD/NetBSD/OpenBSD)間の比較においては、しばしば、FreeBSDは、安定性、高速性、NetBSDは、移植性が高く対応アーキテクチャが豊富、同一ソースで複数のアーキテクチャに対応可能な洗練されたソースコード、OpenBSDはセキュリティに強いと言われることが多いようです。

お薦めのディストリビューション

 様々な観点から各種*BSD、Linuxを見てきた中で*BSDとGentooが、他を凌いで理に適っており、更に絞り込むとするならば、オリジナルのカーネルとユーザーランド、互換性の点で優位なBourne ShellやPOSIX準拠の/bin/shを採用しており、1つの基本(≒プライマリ)パーティション内にBSDパーティションを柔軟に配分できるなどの点で*BSDが、その中でもNetBSD、OpenBSD、FreeBSDの順にこの3つが、お薦めです。

 とは言え、何らかの理由でDebian系やRed Hat系などのLinuxも手放せず、魅力的という場合もあるかもしれません。

 そんな時、PCが複数台あるなら1台は*BSDと手軽なLinux、WindowsやMac OS Xとのデュアルブート、もしくは、*BSDを含む、これら3つ以上のマルチブート、あと1台は、また、他に2台以上ある場合でもソースコード情報を最新にアップデートした1台をベースにNFS/Network File SystemやSamba(CIFS/SMBFS)を介してアップデートできるように*BSDの内の何れか1つに絞るとよいのではないかなと思ったりします。

 Windowsも含める場合、次期Windows 10正式リリースにあたっては、旧バージョンからの移行を一定期間、無償化すると謳っている点とクラウド(もねぇ。。。)への移行がどのくらい進むかによっても以後どうなるのかは未知数ですが、少なくとも従前は、ハードウェアの進歩に足並みを揃えることでWindowsとPC一体で買い替えを促すかのようにサポート期限が切れたら後継はPCスペック上、利用には無理があるという点、サポート期限が過ぎるとセキュリティ上、昨今必須のインターネットにつなぐことすらできず、メールもできないということもあり、プリインストールPCだと面倒という場合には、なんですが、専用に1台持つまでもない気がするので環境が許すなら手軽なLinuxとマルチブートで十分だと思います。

 実際のところ、マルチブートにした場合、メインが決まると他は、よほど必要なとき以外は、使わなくなると思うのでWindowsと異なり、基本的にアップデートし続ければ、ずっと使える*BSDかLinuxをメインにしておく方が無難でしょう。

備考

 かく言う自身は、3台の内、1台は、NetBSDを含めたマルチブート用にディスクは空けてあるも他は未だいれておらず、今のところFedoraのみ、他の2台はNetBSDと(なんとなく必要になることもあるかな?程度の気持ちで)FreeDOS(≠FreeBSD)のマルチブート構成ですが、Fedoraを入れたマシンにも当然ながらNetBSDも入れる予定です。

 => 後日、Fedoraに加えてPavilionにNetBSDをインストールしました。

 => 更に後日、PavilionにDebian wheezyのインストール・jessieにアップグレードしました。

 使用歴という意味では、MS-DOS、Windows 3.x、初めて買ったPCのOSはWindows 95、続いて98SE、XP、Vistaを最後に先日、手持ちはなくなったものの、今尚、Windowsの使用歴が最も長く、Cygwin、Linux、Solarisの利用経験はあります。

 また、雑誌や書籍の購入でRed Hat Linux 7.1、Fedora Core 2などのインストールCDやDVDは持っていながら後になるまでインストールすることはなく、*BSDは、なぜかMS-DOSと似たりよったりだと勘違いしており、実際にインストールしてみたという意味では、遅まきながら出会った仮想化ソフトウェアで作成した仮想マシンにLinux/*BSD/PC-UNIX共に相当数のディストリビューションを順不同に次々と、物理マシンについては、*BSD(NetBSD数台)が若干ながら早く、次いでLinux(Fedora)といった具合です。

 当初、認識が薄く誤解していた*BSDの内、認識も新たにNetBSDを真っ先に物理マシンに、結果、3台続けざまにインストールしようと思ったのは、何れもマシン上の制約からで、ウィンドウマネージャ、または、デスクトップ環境込みで、より軽量でありつつ、トリッキーでないものを求めた結果であり、そういう意味では前述の通り、OpenBSDでも良く、甲乙つけがたかったものの、なんとなくNetBSDを選択したに過ぎませんでしたが、使用しながら、他と何が違うのか比較していく内、ソースベースとバイナリベースの管理が可能なpkgsrc(pkgsrc、pkg_*、追加でpkgin)開発元であると共にこれを標準採用、複数台のアップグレードへの配慮と対応、低スペックマシンにも長年対応、POSIX準拠/bin/sh、幅広いアーキテクチャへの対応と、この多くに同一のソースコードを適用、同時配布できる洗練されたソースコード、最新技術への一定の順応。。。等々を考えるにつけ、NetBSDという選択は、妥当だったと思うに至っています。

[追記:2016/05]

 デスクトップよりノートが低消費電力であることは承知の上でデスクトップをメインとして使っていたものの、いざ、PC・周辺機器の消費電力をチェックし、数値を目の当たりにしたら、メインはノートに、更に以前から頭の片隅にあったファイルサーバ(NAS)等々なら手持ちのPCよりRaspberry Piと関連パーツ購入を検討すべきでしょということで実際にRaspberry Pi 2 Model Bを購入Raspberry Pi用OSを準備、そのOSは、Raspbianとし、Samba・CUPS・UPnP/DLNAなどにより各種サーバを設定の上、現在、NAS・メディアサーバ他を運用中

 NetBSD、FreeBSDもRaspberry Piに対応しており、*BSDの方がサーバには向いていると思いますし、*BSDでもシングルボードコンピュータには、NetBSDの方がなんとなく妥当と思うもインストール済みでかつシンプルな最小限の構成のOSイメージがなかったこと、UUIDに対応していない模様であることなどからLinux、UbuntuはPCでも重量級、ArchとPidoraは、なんとなく忙しないイメージというなんとも適当な取捨選択によりRaspbianに落ち着きました。

 サーバがRaspbianでメインとするに至ったクライアントとなるノートPCのOSはNetBSD、文書・画像編集、ネット、CD/DVD、ストリーミング配信など音楽・動画視聴、VNC越しのメールクライアントやスキャナの利用、ssh、scp、rsyncなど日常困ることは特にありませんし、パッケージも主要なものやレアなものまでそれなりに一通りあると思います。

 ただ、UPnP/DLNAサーバーは問題ない一方、複数あるのに実質使えるモノが限られるUPnP/DLNAクライアントとか、当然、ブラウザでCUPS管理画面にアクセスすることはできるものの、検出含め、素直にCUPSプリンタを使えない(後に無条件でCUPSを使えていたKDE4のフルパッケージがなくなっている模様だったり、コンパイルオプションの設定でCUPSを選択可能にできたXfce4用のプリンタ追加ダイアログがなくなったり、GTK関連オプション設定などで各種パッケージにおいて印刷ダイアログに表示させることができていたCUPSの選択肢も表示されなくなっていたりと、なぜか更にCUPSが使えないようになっている節もある)といったような点では、NetBSDをクライアントのメインとするには、ちょっと微妙。。。

 何か事情があるにせよ、CUPSの件に関しては、この手順だけでは、とてもじゃないけど利用できるまでに至らないできるよ的な微妙なwiki.netbsd.org情報がチュートリアルとして残っている一方、使えるようになるどころか、以前より更に状況が後退している模様なのは、残念。。。メンテナがいないのかな。。。と言っても、プリンタを使うことは、まず滅多にないんですけどね。

 それでも先の通り、サーバとしては一通り、クライアントとしても、たいていの場合は、不足はないですし、得るものも多いのでメインかサブかは別としてNetBSDはもう使わない!なんてことにはならないと思います。

ホーム前へ次へ