hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
ユーザインタフェース コンピュータ
ユーザーは従来的なコマンド入力を行わず、身振り手振りや音声を使って意思を伝達し、出力は映像や音声で行われる方式。KinectやSiri/Cortanaなどが挙げられる。
リフレクシブユーザインタフェース (英: reflexive user interface)
ユーザインタフェース全体をユーザーが再定義可能な方式。主に非常にリッチなGUIでのみ可能。
タンジブルユーザインタフェース (英: tangible user interface, TUI)
物理的な接触を重視したユーザインタフェース。
テキストユーザインタフェース
出力はテキスト形式だが、入力はコマンド入力以外の方式も可能なユーザインタフェース。テキスト方式のメニュー操作などを指す。
音声ユーザインタフェース
電話において、音声で案内し、ユーザーは電話機のプッシュボタンで入力する方式。音声ガイダンス。
ズーミングユーザインタフェース
GUIの一種で、情報オブジェクト群が異なる詳細さレベルで表示され、ユーザーがその中からオブジェクトを選ぶとさらに詳細が表示されるという方式。Microsoft Windows 8で導入されたModern UIスタイルのアプリケーションでは、「セマンティックズーム」と呼ばれる。
ユーザインタフェース コンピュータ
ユーザインタフェースの歴史は、支配的なユーザインタフェースの種類によって以下のように分けることができる。
1990年代以降に勃興したユーザインタフェースとして、以下のものがある。
ユーザインタフェースにおけるモダリティとは、入出力に使用されるコミュニケーションの経路である。例えば、
ユーザインタフェースは複数の冗長なモダリティを備えることがあり、ユーザーがいずれかを選択して使うことができるようになっている。
一方、モードはこれとは異なる概念で、プログラムの状態が異なると同じ入力を与えても異なる結果を生じることを意味する。モードを多用するとユーザーは常に現在の状態を覚えておく必要があるため、ユーザビリティの低下を招く。
小池田マヤ
小池田 マヤ（こいけだ マヤ、1969年5月4日 - ）は、日本の漫画家。山口県光市虹ヶ丘生まれ、大阪府出身。京都市立芸術大学版画科卒業。女性。
本名「山田佳子」（やまだけいこ）。逆に読むと「こいけだまや」となる。
専門学校での非常勤講師経験あり。
小池田マヤ 作風・特徴など
1991年、大学在学中に芳文社『まんがホーム』8月号「女流新人4コマまんが展」に「愛ラブうずらチャン」で入選。翌月9月号より「すいーとキッチン」の連載が開始された。その後芳文社の各誌に連載を持ち、「僕のかわいい上司さま」などで再録4コマ誌『まんがタイムコレクション』が数回発売されるなど同社の主力作家の1人として活躍した。後に芳文社から全作品の出版契約を引き上げ、現在は非4コマ誌や青年誌など各社の漫画雑誌に活動の場を拡げている。
4コマ漫画に連続性を持たせながら第1話から最終回に至る大きな話を描く、「ストーリー4コマ」の手法を得意とする。「僕のかわいい上司さま」「すーぱータムタム」「バーバーハーバー」などの著作では、連続する複数の4コマを1つのストーリーとして関連づけるのみならず、コマ枠外部への書き込み、1つのエピソードを異なる視点から2本の4コマ漫画に仕立てる、4コマの後に見開きを配置するなど多様な表現法が使われている。
小池田マヤ 主な作品リスト
ときめき まっくん!（芳文社、全3巻）、双葉社より文庫版として全1巻が発行。まんがタイム平成7年5月号で連載開始。
ISBN 9784832260832（1996年12月）
ISBN 9784832261198（1998年10月）
ISBN 9784832261631（2000年3月）
文庫版 ISBN 978-4-575-72693-0（2008年11月）
すーぱータムタム（芳文社、全3巻）、完結編（講談社）、双葉社より文庫版が上下巻で発行。まんがタイムラブリー平成7年1月号で連載開始。
ISBN 9784832260948（1997年9月）
ISBN 9784832260986（1997年11月）
ISBN 9784832261242（1998年12月）
完結編 ISBN 9784063374711（2001年7月）
文庫版 上 ISBN 9784575727340（2009年10月20日）
文庫版 下 ISBN 9784575727357（2009年10月20日）
小池田マヤ 主な作品リスト
マイペース! ゆず★らん（双葉社、全5巻、文庫版2巻）
ISBN 978-4-575-93638-4（1999年8月）
ISBN 978-4-575-93695-7（2000年6月）
ISBN 978-4-575-93753-4（2001年8月）
ISBN 978-4-575-93820-3（2003年3月）
ISBN 978-4-575-93915-6（2004年11月）
文庫版 上 ISBN 9784575727104（2009年4月）
文庫版 下 ISBN 9784575727111（2009年4月）
家政婦さんシリーズ（1~3巻祥伝社、4巻〜双葉社）2021年8月現在、既刊7巻
放浪の家政婦さん ISBN 9784396764630（2009年7月）
ピリ辛の家政婦さん ISBN 9784396765118（2010年12月）
誰そ彼の家政婦さん ISBN  9784396765644 (2012年11月)
颯爽な家政婦さん ISBN 9784575336092（2015年10月17日）
波飛沫せし家政婦さん ISBN 9784575336634 (2017年4月)
令和の家政婦さん1（2020年9月17日）
令和の家政婦さん2（2020年11月17日）
小池田マヤ 主な作品リスト
女と猫シリーズ（双葉社) 
女と猫は呼ばない時にやってくる ISBN 9784575334807 (2012年5月）
老いた鷲でも若い鳥より優れている ISBN 9784575335514（2013年4月17日）
鳴く蝉よりも鳴かぬ蛍が身を焦がす ISBN 9784575335514（2014年5月17日）
カラスと書き物机はなぜ似てる? （2015年10月17日）
仕事は狼ではなく森へは逃げない 上（2018年4月17日）
仕事は狼ではなく森へは逃げない 下（2018年5月17日）
釣りとごはんと、恋は凪（ぶんか社）
ISBN 978-4-8211-3607-0 (2018年4月1日）
ISBN 978-4-8211-3821-0（2019年8月1日）　　　　
ISBN 978-4-8211-3821-0（2020年8月17日）
ISBN 978-4-8211-2956-0（2022年5月13日）
ISBN 978-4-8211-5988-8（2025年3月14日）
ISBN 978-4-8211-5989-5（2025年3月14日）
カーネル
カーネル（英: kernel）は、階層型に設計されたオペレーティングシステム (OS) の中核となる部分で、アプリケーションとハードウェアの架け橋である。具体的には、システムのリソースや、ハードウェアとソフトウェアの連携を管理する。そのほか、通信制御を行うことが多い。
オペレーティングシステムの基本コンポーネントとして、カーネルはメモリ、CPU、入出力を中心としたハードウェアを抽象化し、ハードウェアとソフトウェアがやり取りできるようにする。また、ユーザープログラムのための機能として、プロセスの抽象化、プロセス間通信、システムコールなどを提供する。
これらのタスクはカーネルによって方式が異なり、設計や実装も異なる。モノリシックカーネルは全てを一つの仮想アドレス空間に格納されたコードで実行して性能を向上させようとする。マイクロカーネルはサービスの大部分をユーザー空間で実行し、コードの保守性とモジュール性を向上させようとする。多くのカーネルはこの二つのカテゴリのいずれか、あるいは中間である。
カーネル 概要
全てではないが、多くのオペレーティングシステム (OS) はカーネルを内包する。ハードウェアとソフトウェアの間の通信を管理するソフトウェアとしてのカーネルは、性能、メモリ効率、セキュリティ、プロセッサのアーキテクチャなどが複雑に絡んだ問題への妥協的解答である。
多くの場合、ブートローダーがカーネルを特権モードのプロセスとして起動する。しかし、初期化が完了すると、カーネルはいわゆるプロセスとしては存在せず、ディスクアクセスなどの高い特権レベルを必要とする処理を必要としたときにユーザプログラムから呼び出される機能の集合体として存在することになる。カーネルの処理の流れはユーザープロセスの処理の流れの延長上にあり、システムコールによってカーネルに処理がわたり、終了するとユーザーに戻っていく。初期化時のコンテキストはそのまま消えるようにする設計もあるが、「アイドルプロセス」とか「collects」と呼ばれる、プロセッサが何もすることがないときに実行されるコードに流用される設計とすることもある。省電力のため、プロセッサが「休む」ような命令を繰り返すようなコードとすることも多い。
カーネル 概要
カーネル開発はプログラミングの中でも複雑で難しいタスクのひとつと考えられる。オペレーティングシステムの中核部であるということは、高い性能を要求される最重要なソフトウェアであり、正しく設計し実装することは難しい。カーネルはユーザプログラムの互換性や移植性を考慮する必要などから、設計が制限されることがあり、そのことがさらに開発を難しくしている。
カーネル カーネルの機能
カーネルの仕事はコンピュータのリソースを管理し、他のプログラムがそれらのリソースを使って動作できるようにすることである。典型的なリソースとしては以下のものがある。
コンピュータには何らかの入出力デバイスがある（キーボード、HDD、USBなど）。カーネルはアプリケーションから入出力要求を受け付け、適切なデバイス（あるいはデバイスの一部、たとえばファイルやウィンドウなど）に対して入出力を実行し、デバイスを使用するための便利な方法を提供する（一般に、アプリケーションがデバイスの実装の詳細を知らなくてもすむように抽象化する）。
リソース管理に必要な重要な観点は、実行領域（アドレス空間）の定義とその領域内のリソースへのアクセスを調停する保護機構である。
また、カーネルは一般にプロセス同士の同期と通信の手段も提供しており、プロセス間通信 (IPC) と呼ぶ。
カーネルは自前でそれらの機能を実装していることもあるし、何らかのプロセスに委任していることもあるが、後者の場合はプロセス間で機能へのアクセスを可能にするIPCを提供する必要がある。
最後に、カーネルはそれら機能群へのアクセスを要求する手段をプログラムに提供しなければならない。
カーネルの主な仕事はアプリケーションの実行を許可し、ハードウェア抽象化などの機能によってそれをサポートすることである。
カーネル カーネルの機能
プロセスは、アプリケーションがアクセスできるメモリの範囲を定義する。カーネルのプロセス管理は、ハードウェアの持つメモリ保護機構を考慮しなければならない。
カーネルはアプリケーションを実行するためアドレス空間を設定し、アプリケーションのコードを含むファイルをメモリにロードし、プログラムのためのコールスタックを設定し、そのプログラムの所定の位置に制御をわたすことで実行を開始する。
マルチタスク可能なカーネルは、ユーザーから見て実際にそのコンピュータが同時実行できるプロセス数よりも、多数のプロセスが同時並行して実行されているかのようにみせかける。一般にシステムが同時並行して実行できるプロセス数は、そのシステムの持つCPU数に等しい（同時マルチスレッディングをサポートしている場合はそのかぎりではない）。
カーネル カーネルの機能
プリエンプティブ・マルチタスクシステムでは、カーネルは各プログラムにタイムスライス（そのプログラムがCPU上で実行される連続時間）を与え、プロセスからプロセスへと高速に切り換えていくので、ユーザーから見ればそれらのプロセスが同時並行して実行されているように見えるのである。カーネルは次に実行すべきプロセスを決定し、タイムスライスの長さを決定するスケジューリングアルゴリズムを持つ。一般にプロセスには優先度が設定される。カーネルはそれらのプロセス間の通信手段も提供する。これはプロセス間通信 (IPC) と呼ばれ、パイプ、共有メモリ、メッセージ、RPC、ソフトウェア割り込みなどがある。
ほかに協調型マルチタスクもあり、各プロセスは自らカーネルに制御を戻すまで割り込まれずに実行を続けることができる。制御をカーネルに戻すことを "yielding" と呼び、プロセス間通信の際や何らかのイベントを待つ際に行われ、そのときにカーネルが別のプロセスを動作させる。古い Windows や Mac OS はこの方式だったが、コンピュータの性能向上に伴ってプリエンプティブ方式に切り換えた。
カーネル カーネルの機能
オペレーティングシステムは、マルチプロセッシング（SMPやNUMA）をサポートすることもある。この場合、複数のプログラムやスレッドが複数のプロセッサ上で動作する。そのようなシステムでカーネルを動作させる場合、「リエントラント（再入可能）」あるいは「割り込み可能」になるよう大幅な改造が必要となる。これはつまり、何か処理をしている最中にほかからも要求を受け付けるということである。この改造ができれば、異なるプロセッサ上で動作するプログラムが同時にカーネルを呼び出しても大丈夫になる。カーネルは複数のプロセッサからのメモリアクセスを同期させる方法（スピンロックなど）も提供しなければならない。これはメモリ管理とプロセス管理にまたがる問題である。
カーネルはシステムの全メモリへの無制限のアクセスが可能で、ユーザープロセスの要求に応じて安全なメモリアクセスを提供しなければならない。このための第一歩はページング方式やセグメント方式による仮想アドレッシングである。仮想記憶方式では、カーネルは物理アドレスを別のアドレス、つまり仮想アドレスに変換する。これにより、各プログラムは（カーネル以外では）仮想空間上唯一のコードに見え、プログラムが互いに他のプログラムを破壊することを防止する。
カーネル カーネルの機能
多くのシステムで、あるプログラムの仮想アドレスはメモリ上にないデータを指していることがある。仮想アドレッシングによるインダイレクション層は、本来なら主記憶 (RAM) になければならないデータをハードディスクなどの補助記憶装置に退避させることを可能にする。結果としてOSは物理的な容量以上のメモリをプログラム群に提供可能となる。RAMにないデータがあるプログラムで必要になった場合、CPUはカーネルにそれを知らせ（ページフォールト）、（必要なら）カーネルが使われていないメモリブロックの内容をディスクに退避させ、必要なデータをそのメモリブロックに復帰させる（ページ置換アルゴリズム）。すると、プログラムは要求を行った時点から処理を再開させることができる。これをデマンドページングと呼ぶ。
仮想アドレッシング方式では、仮想空間をカーネル用の部分（カーネル空間）とアプリケーション用の部分（ユーザー空間）に分けることができる。アプリケーションはカーネル用メモリにアクセスできないので、アプリケーションにバグがあったとしてもカーネルにダメージを与えることはない。この根本的な分離は多くの汎用カーネルで実際に使われているが、別の方式を採用したカーネルの研究も行われている（たとえば、Singularity）。
カーネル カーネルの機能
メモリ管理のもうひとつの機能として、カーネル内の各モジュールやデバイスドライバが使用するメモリの割り当てがある（動的メモリアロケーション）。
実際に何らかの作業をするには、OSはコンピュータに接続された周辺機器にアクセスする必要があり、周辺機器はその開発元などが書いたデバイスドライバを通して制御される。デバイスドライバはOSがハードウェアデバイスとやりとりするためのプログラムであり、OSに対して何らかのハードウェアを制御・通信するための情報を提供する。ドライバはアプリケーションにとっても重要で不可欠である。ドライバの設計目標は抽象化である。ドライバの機能はOSの定めたインタフェースからデバイス固有のインタフェースに変換することである。理論上、デバイスは適当なドライバがあれば正しく動作する。デバイスドライバは、ビデオカード、サウンドカード、プリンター、スキャナー、モデム、LANカードなどに対応して存在する。一般的なデバイスドライバの抽象化レベルを次に示す。
たとえば、ユーザー向けに何かを画面に表示する場合、アプリケーションがカーネルに要求し、その要求がディスプレイドライバに送られ、ディスプレイドライバが実際の文字やピクセルの描画を行う。
カーネル カーネルの機能
カーネルは使用可能なデバイスの一覧を保持しなければならない。この一覧は、事前に知られている場合（たとえば、組み込みシステムでは利用可能なハードウェアが変われば、カーネルを書き換える）、ユーザーが設定する場合（古いPCや個人用に設計されていないシステムなど）、OSが実行時に検出する場合（プラグアンドプレイ）がある。プラグアンドプレイのシステムでは、デバイス管理は最初にさまざまなバス（PCIやUSB）上をスキャンして実装されたデバイスを検出し、対応するドライバを探す。
デバイス管理は各OS固有の部分であり、カーネルの設計によってドライバの扱い方は異なるが、一般にカーネルはドライバが物理的にデバイスにアクセスするための入出力ポートやメモリ空間を用意する必要がある。デバイスへのアクセスはコンテキストスイッチを引き起こしたり、CPUを浪費したりすることになりやすく、性能オーバヘッドの元となるため、デバイス管理の設計は重要である。
意味のある作業を実行するには、ユーザプログラムはカーネルの提供する全サービスにアクセスできなければならない。これはカーネルによって実装が異なるが、多くは標準CライブラリやAPIが提供され、そこから対応するカーネル機能が呼び出される。
カーネル機能を呼び出す方法は主にCPUがどのような機能を提供しているかに依存する。カーネル空間とユーザー空間が分離されている場合、ユーザープロセスが直接カーネルを呼び出すことはできない。たとえば以下のような技法を採用する。
カーネル カーネル設計の観点
カーネル設計において重要な観点として、障害（フォールトトレラント性）と悪意ある動作（セキュリティ）からの保護（プロテクション）サポートがある。この2つは通常明確には区別されず、明確に区別しようとするとリングプロテクションでは対応できなくなる。
カーネルが提供する機構または方針は、いくつかの基準で分類できる。
などである。
階層型プロテクションは、一般に「CPUモード」でサポートされる。ハードウェアサポートによる単純で効率的な方法は、MMUにメモリアクセスのたびにその妥当性をチェックさせるもので、その機構をケイパビリティベースドアドレッシングと呼ぶ。ただし、多くの商用コンピュータアーキテクチャではMMUがケイパビリティをサポートしていない。
カーネル カーネル設計の観点
代替手法は、階層型プロテクションでケイパビリティをシミュレートするものである。この場合、保護されたオブジェクトはアプリケーションがアクセスできないアドレス空間になければならない。カーネルもそのようなメモリ空間のケイパビリティのリストを保持する。ケイパビリティによって保護されたオブジェクトにアプリケーションがアクセスしたい場合、システムコールを行い、カーネルが実際のアクセスを代行する。これにはアドレス空間の切り替えを必要とするため、オブジェクト間で複雑なやりとりが必要なシステムでは性能が低下するが、現代のOSはアクセス頻度が低いオブジェクトや性能を要求されないオブジェクトについてはこの方式を採用している。保護機構をより高い階層でシミュレートする方式も可能だが（たとえば、直接サポートされていないハードウェアについてのページテーブルを操作してケイパビリティをシミュレートするなど）、性能上の問題がある。言語ベースの保護を選択するシステムでは、ハードウェアサポートがなくても問題にならない。
カーネル設計における重要な点として、セキュリティの機構と方針を実装する抽象化レベルの選択がある。カーネルのセキュリティ機構は、高度なセキュリティをサポートする上で重要である。
カーネル カーネル設計の観点
1つの方式として、ファームウェアとカーネルでフォールトトレラント性をサポートする方式があり、その上に悪意ある動作に対するセキュリティ方針を構築し（必要に応じて暗号機構を追加する）、一部の責任をコンパイラに委任する。コンパイラやアプリケーションレベルへのセキュリティ方針の責任委譲の方式を一般に「言語ベースのセキュリティ」と呼ぶ。
現代の主流のOSの多くは重要なセキュリティ機構が欠如しているため、アプリケーションの抽象化レベルでの適切なセキュリティ方針実装ができないことがある。一般にカーネルサポートがどうであれ、アプリケーションで任意のセキュリティ方針を実装可能だとされているが、間違いである。
現代の一般的コンピュータは、ハードウェアが強制した規則を使ってプログラムのデータへのアクセスを許可している。プロセッサは動作を監視し、規則に違反したプログラムを停止させる（たとえば、カーネル空間のメモリを読み書きしようとしたユーザプロセスを停止させるなど）。ケイパビリティをサポートしていないシステムでは、プロセスは相互に隔離されたアドレス空間で動作する。ユーザプロセスがカーネルを呼び出すことは、上述したシステムコールの技法を使って統制されている。
カーネル カーネル設計の観点
代替手法として言語ベースの保護（プロテクション）がある。言語ベースのプロテクションシステムでは、カーネルは信頼されている言語コンパイラが生成したコードのみ実行を許可する。そしてその言語は、セキュリティに違反するようなコードをプログラマが書けないように設計されている。
この方式には次のような長所がある。
一方、次のような短所がある。
言語ベースのプロテクションを採用したシステムとしては、JXやマイクロソフトのSingularityがある。
エドガー・ダイクストラは論理的観点から、バイナリセマフォにおける不可分なロックとアンロック操作だけで、プロセス間の任意の協調作動を実現できることを証明した。しかしそのような方式は一般に安全性や効率性が欠如しており、メッセージパッシング方式の方が柔軟性が高い。他の方式もいくつかあり、現代のカーネルでは共有メモリやRPCなどのシステムをサポートしていることが多い。
入出力デバイスを並行して協調作動する他のプロセス群から一様に扱えるようにするというカーネルの考え方は、Per Brinch Hansen が提唱し実装したのが最初である（似たような考え方は1967年にも示唆されていた）。Hansen はその説明で、「共通の」プロセス群を「内部プロセス」、入出力デバイスを「外部プロセス」と呼んでいる。
カーネル カーネル設計の観点
物理メモリと同様、アプリケーションがコントローラのポートやレジスタに直接アクセスすることを許可すると、コントローラが不正作動したり、システムがクラッシュすることになる。それに加えて、デバイスの複雑さに応じて対応するプログラムは非常に複雑化することがあり、しかも複数の異なるコントローラを使うことがある。そのため、デバイスを管理するためのより抽象化されたインタフェースを提供することが重要である。この抽象化を提供するのは一般にデバイスドライバや Hardware Abstraction Layer (HAL) である。アプリケーションは必要なら頻繁にデバイスへのアクセスを要求する。カーネルはシステムに接続されたデバイスの一覧を何らかの方法で保持しなければならない。これはBIOSや各種システムバスの機能（PCI/PCIeやUSB）を使ってなされる。あるアプリケーションがあるデバイス操作を要求すると（たとえばディスプレイに文字を表示する）、カーネルは対応するドライバ（たとえばビデオドライバ）に要求を送らなければならない。するとそのドライバがデバイスに対して必要な処理を行う。マイクロカーネルの場合、この際にプロセス間通信 (IPC) が使われる。
カーネル カーネル全体の設計方針
もちろん、上述したタスク群や機能群の提供方法は設計や実装の面でさまざまである。
「機構と方針の分離」の原則は、マイクロカーネルとモノリシックカーネルの哲学の間でかなり大きな相違がある。ここで、「機構」はさまざまな「方針」の実装を可能とするものであり、「方針」は特定の「操作のモード」である。たとえば「機構」面では、ユーザーがログインしようとしたとき認証サーバを呼び出してアクセスを認めるべきか否かを決定するということが考えられる。一方「方針」面では、認証サーバがパスワードを要求し、データベース内の暗号化されたパスワードと照合するかもしれない。機構が汎用的であれば、機構と方針が同一モジュールに統合されている場合よりも方針の変更（たとえば、パスワードの代わりにセキュリティトークンを使うなど）がより容易になる。
最小のマイクロカーネルでは非常に基本的な方針のみが含まれ、その機構はカーネル上で動作させるもの（OSの残りの部分やアプリケーション群）自身がどのような方針（メモリ管理、高度なプロセススケジューリング、ファイルシステム管理など）を採用するか決定することを可能にする。一方モノリシックカーネルは方針の大部分をカーネル内に含む傾向があり、結果としてその上の部分の自由度は制限される。
カーネル カーネル全体の設計方針
Per Brinch Hansen は機構と方針の分離のための主張を展開した。すなわち、この分離が不適切であることが既存のOSで本質的技術革新が見られないことの主要因だとし、コンピュータアーキテクチャにおける共通課題だとした。モノリシック設計は、従来の商用システムで一般的な保護技法である「カーネルモード」と「ユーザーモード」に分離するアーキテクチャ（いわゆるリングプロテクション）から生まれた。そのアーキテクチャでは、保護（プロテクション）を必要とするモジュールを可能な限りカーネルに含めようとする。このようなモノリシック設計と特権モードの関係が機構と方針の分離における重要な問題として再注目されている。実際「特権モード」のアーキテクチャ技法は保護機構とセキュリティ方針を融合させる傾向があるが、これとは大きく異なるアーキテクチャ技法であるケイパビリティベースドアドレッシングではその2つを明確に区別し、自然にマイクロカーネル設計が可能となる。
カーネル カーネル全体の設計方針
モノリシックカーネルはカーネルの全コードを同じアドレス空間（カーネル空間）で実行するが、マイクロカーネルでは多くのサービスをユーザー空間で実行しようとし、コードベースの保守性とモジュール性を向上させようとしている。多くのカーネルは明確にどちらかに分類できるわけではなく、その中間の実装ともいうべきハイブリッドカーネルになっている。さらに特殊な設計としてナノカーネルやエクソカーネルが研究されているが、広く使われるまでには至っていない。エクソカーネルの例としてXenハイパーバイザがある。
モノリシックカーネルでは、全OSサービスはひとつのカーネル空間内に存在し、カーネルスレッド上で実行される。この手法は強力なハードウェアアクセスを提供する。UNIXの開発者ケン・トンプソンは、モノリシックカーネルの方がマイクロカーネルより実装が容易だとしている。主な欠点はシステム構成要素間の依存関係の複雑さである。たとえば、デバイスドライバにバグがあっただけでシステム全体がクラッシュするし、大きなカーネルは保守が非常に困難である。
カーネル カーネル全体の設計方針
Unix系OSが伝統的に採用してきたモノリシックカーネルは、OS中核機能とデバイスドライバを全て含んでいた。デバイスドライバ、スケジューラ、メモリ管理、ファイルシステム、ネットワークのプロトコルスタックなど、多くのプログラムが必要とするがライブラリとしてユーザー空間で実行することができない機能は、全てカーネル空間に置かれた。それら全サービスへのアクセスを可能にするため、数多くのシステムコールがアプリケーションに対して提供されている。
必要とされないサブシステムを伴って最初からロードされるモノリシックカーネルは、より汎用的な意味ではあるが、特定ハードウェア向けに設計されたものよりもチューニングが可能である。LinuxやFreeBSDなどの現代のモノリシックカーネルはUnix系OSであり、実行時にモジュールをロードする機能を備えており、必要に応じて容易に機能を拡張でき、同時にカーネル空間で動作するコード量をなるべく最小に抑えることができる。モノリシックカーネルには次のような長所がある。
カーネル カーネル全体の設計方針
モノリシックカーネルはシステムコールの延長で動作する部分がほとんどである。システムコールは一般にテーブル構造で保持されるインタフェースであり、ディスク操作などのカーネル内サブシステムへのアクセスを行う。プログラム内でライブラリルーチンを呼び出すと、その中で要求をチェックしてコピーし、システムコールにわたす。したがって、それほど重い呼び出しではない。Linuxカーネルはモノリシックだがかなり小さくできる。これは、ローダブル・カーネル・モジュール機能と、カスタマイズが容易なためである。実際、フロッピーディスク1枚にカーネルだけでなく多数のユーティリティを搭載し、それだけで完動するOSとすることもできる（最も有名な例として muLinux がある）。このカーネルを小型化できる能力があるため、Linuxは組み込みシステムで急速に採用が増えている（組み込みLinux）。
カーネル カーネル全体の設計方針
このようなカーネルはOSの中核機能とデバイスドライバからなり、実行時にモジュールをロードする機能を備えている。それらによって、下層のハードウェアについての豊富で強力な抽象化を提供する。それらは単純なハードウェア抽象化の小さなセットを提供し、サーバと呼ばれるアプリケーションを使ってさらなる機能を提供する。この特定の手法でハードウェア上の高度な仮想インタフェースを定義し、プロセス管理、並行性管理、メモリ管理といったスーパーバイザモードで動作するいくつかのモジュールでOSサービスを実装し、システムコールでそれらを呼び出せるようにしている。しかし、このような設計には以下のような短所や制約がある。
マイクロカーネルとは、伝統的な「カーネル」から「サーバ」群に機能を移転するOS設計方針を意味し、最小化したカーネルだけをカーネル空間に残し、サーバ群を可能なかぎりユーザ空間で動作させる。マイクロカーネルでは、ハードウェアの単純な抽象化と最小のプリミティブ（システムコール）で最小のOSサービスを実装する（メモリ管理、マルチタスク、プロセス間通信など）。他の全てのサービス（ネットワークなど）は「サーバ」としてユーザ空間に実装される。マイクロカーネルはモノリシックカーネルよりも保守が容易だが、システムコール回数やコンテキストスイッチ回数が増大するために性能が低下する傾向がある。
カーネル カーネル全体の設計方針
どうしても特権モードでなければならない部分だけがカーネル空間に置かれる。それは、IPC（プロセス間通信）、基本スケジューラ（スケジューリング・プリミティブ）、基本メモリハンドラ、基本I/Oプリミティブなどである。スケジューラ本体やメモリ管理、ファイルシステム、ネットワークスタックといった大部分はユーザ空間で動作する。マイクロカーネルは、システム機能全体がプロセッサのシステムモードで動作する1つのプログラムになっているモノリシックカーネルの設計方針への反発から生まれた。マイクロカーネルを採用したOSとしては、QNXや GNU Hurd がある。マイクロカーネルは基本的に次のような長所を持つ。
カーネル カーネル全体の設計方針
多くのマイクロカーネルは、何らかのメッセージパッシングシステムを採用しており、サーバからサーバへの要求の転送を行う。一般にマイクロカーネルがそのためのポートを用意している。たとえばメモリ追加要求を送ると、マイクロカーネルのあるポートが開き、そこを通して要求が転送される。マイクロカーネルにメッセージが受信されると、その後はシステムコールのように処理される。これによってシステムアーキテクチャのモジュール性が高まり、システムがより整理され、デバッグや動的変更が容易になり、ユーザーのニーズに従ったカスタマイズが可能となる。AIX、BeOS、Hurd、macOS、MINIX、QNX といったOSは多かれ少なかれマイクロカーネルの設計方針を取り入れている。マイクロカーネル自体は非常に小さいが、システム機能全体を構成するコードを全て集めると、モノリシックカーネルよりも大きいことが多い。モノリシックカーネル支持派はまた、マイクロカーネル方式の2層構造によりOSの大部分がハードウェアと直接相互作用できなくなるため、決して小さくないコストが上乗せされ、システムの効率を低下させると主張している。マイクロカーネルは通常、アドレス空間定義部、プロセス間通信 (IPC)、プロセス管理といった最小限のサービスだけを提供する。ハードウェア処理といった他の機能はマイクロカーネルで直接扱うことはない。マイクロカーネル支持派は、モノリシックカーネルでのエラー（バグ）がシステム全体のクラッシュを引き起こすという欠点を指摘する。しかしマイクロカーネルでは、サーバがクラッシュしてもそのサービスを再起動することでシステム全体のクラッシュを防ぐ可能性がある。しかし、現にLinuxなどのモノリシックカーネルは年単位で安定動作している実績があり、このようなマイクロカーネルの利点がどれほど重要かは疑わしい。
カーネル カーネル全体の設計方針
ネットワーキングなどのカーネルサービスは「サーバ」と呼ばれるユーザ空間のプログラムとして実装される。サーバを停止・再起動するだけでOSを更新可能である。たとえばネットワークをサポートしていないマシンで、ネットワークサーバは起動する必要がない。サーバ群やカーネルの間でデータをやり取りする作業があるため、モノリシックカーネルにはないオーバヘッドが生じ、効率が低下する。
マイクロカーネルの短所はたとえば次のようなものがある。
マイクロカーネル方式では、OSの他の部分を通常のアプリケーションのように高水準言語で書くことができ、同一のカーネル上で異なるOS（のインタフェース）を使用することができる。また動的にOSを切り換えたり、複数のOSを同時に使用することもできる。
カーネルが巨大化するにつれて、さまざまな問題が明らかになってきた。最も明らかな問題はカーネルの大きさ（メモリ使用量）の増大である。これは仮想記憶をカーネル空間にも適用することである程度まで和らげられるが、全てのコンピュータ・アーキテクチャが仮想記憶をサポートできるわけではない。カーネルのサイズを削減するため、不要なコードを削除するなどの改善が必要となるが、これはカーネルの各モジュール間の明らかにされていない依存関係があるために非常に困難である。
カーネル カーネル全体の設計方針
マイクロカーネルと比較したときのモノリシックカーネルのさまざまな欠点から、1990年代の初期までにモノリシックカーネルは時代遅れと考えられるに至った。結果としてLinuxがモノリシックカーネルを採用したことでリーナス・トーバルズとアンドリュー・タネンバウムの間で有名な論争が発生した（アンドリュー・タネンバウムとリーナス・トーバルズの議論）。この議論では、両者の言い分にそれぞれメリットがある。
モノリシックカーネルは設計が容易で、マイクロカーネルよりも迅速に成長することが期待できる。しかし、モノリシックカーネル内のバグは一般にシステムクラッシュを引き起こすのに対して、マイクロカーネルでは一部のサーバに問題が限定される。モノリシックカーネルの支持者は、不正なコードがカーネルになければマイクロカーネルの利点はほとんどないと論じる。どちらの側にも成功例がある。マイクロカーネルはロボットや医療用システムで使われており、各コンポーネントが別々の保護されたメモリ空間で動作する。これは最新のモジュールロード方式であってもモノリシックカーネルには不可能であろう。モノリシックカーネルは共有型カーネルメモリを使用するよう最適化されていて、マイクロカーネルのような低速なメッセージわたしとは異なる。
カーネル カーネル全体の設計方針
モノリシックカーネルはコード全体を同じアドレス空間（カーネル空間）に置くよう設計されており、一部の開発者はシステム性能向上に必須の特徴だとしている。一部の開発者はうまく書けばモノリシックカーネルは極めて高効率になるとしている。
1980年代から1990年代初めにかけてのマイクロカーネルの性能は低かった。そういった初期のマイクロカーネルの性能を実測する研究が行われたが、性能が低い原因を深く分析することはなかった。そういったデータが一人歩きし、カーネルモードとユーザモードの切り替え回数が増え、プロセス間通信の回数が増え、コンテキストスイッチの回数が増えたためだ とみなされた。
そして1995年、マイクロカーネルの性能が低い原因として以下のことが推測されている。
この時点でマイクロカーネルを効率化する方法はまだ研究途上であり、正しい技法の構築が求められていた。
一方でモノリシックカーネルの設計の基盤となっている階層型プロテクション でも、プロテクションの階層間でのやりとりには値（メッセージ）のコピーが必要であり、そのやりとりが増えるほど性能が低下することがわかっていた。
近年、L4 やK42といった新世代のマイクロカーネルが登場し、上述の性能問題をある程度解決している。
カーネル カーネル全体の設計方針
Windows NT系などの商用OSでよく見られる。Appleの macOS も、カーネギーメロン大学のMachとFreeBSDのモノリシックカーネルのコードをベースとしたXNUというハイブリッドカーネルを採用している。マイクロカーネルの性能オーバヘッドを削減するため一部のサービス（通信プロトコルスタックやファイルシステム）をカーネル空間で動作させるが、一部のカーネルコード（デバイスドライバなど）はサーバとしてユーザ空間で実行する。これは、純粋なマイクロカーネルが高性能を提供できると示される以前、妥協的に考案された技法であり、マイクロカーネルにモノリシックカーネルの特性を一部取り入れて拡張したものといえる。
ハイブリッドカーネルではカーネルがモジュール化されているが、モジュールの大部分は同じカーネル空間内にロードされる。そのため、バグを含むモジュールをロードするとカーネルの動作が不安定になる可能性がある。マイクロカーネルの場合、カーネルとは全く別の空間でモジュールを動作させることができ、安全に評価することができる。モノリシックカーネルと比較したハイブリッドカーネルの長所を以下に挙げる。
モジュール群は何らかのモジュールインタフェースを使ってカーネルとやりとりする。そのインタフェースはOS固有ではあるが汎用化されており、常にモジュールとして分離実装できるわけではない。デバイスドライバにはモジュールインタフェース以上の柔軟性が必要なことが多い。基本的にモノリシックカーネルではカーネルとの呼び出しが1回で済むところを、ハイブリッドカーネルでは2回呼び出す必要がある。モジュール化の短所として次の事柄が挙げられる。
ナノカーネルは全てのサービスをデバイスドライバとして分離する。これにはたとえば最も基本的な割り込みコントローラやタイマーの制御も含まれる。これによりカーネルメモリはマイクロカーネルよりもさらに小さくなる。
エクソカーネル (exokernel) はまだ実験段階のOS設計技法である。他のカーネルとの違いは、物理ハードウェアのプロテクションと多重化に機能を限定している点で、アプリケーションに対して全くハードウェアの抽象化を提供しない。このようにハードウェアのプロテクションをハードウェア管理から分離することで、利用可能なハードウェアを最大限に生かすように個々のプログラムを開発できるという利点が生じる。
エクソカーネル自体は非常に小さい。しかし、通常のOSの持つ機能をアプリケーション開発者に提供するためのライブラリ型OSを伴う。エクソカーネル型システムの最大の利点は、このライブラリ型OS機能を複数用意できるという点で、それぞれが異なるAPIを提供できる。たとえば同じシステム上で、高度なUIを持つアプリケーションを開発し、同時にリアルタイムシステム制御を行うアプリケーションも開発できる。
カーネル カーネル開発史
厳密にいえば、オペレーティングシステム（とカーネル）はコンピュータを動作させるのに必須ではない。プログラムはマシン上に直接ロードされ実行されることも可能であり、そのようなプログラムはOSのサービスや抽象化なしで記述しなければならない。多くの初期のコンピュータではそのような手法が一般的であり、プログラムを入れ替えるときにリセットとリロードが必要だった。その後、プログラムローダーやデバッガといった補助的な小さなプログラムがメモリに常駐したり、ROMからロードされるようになった。これらが初期のオペレーティングシステムのカーネルの元となった。直接実行の手法は今日でもゲーム機や組み込みシステムで使われているが、一般に最近のコンピュータではオペレーティングシステムとカーネルが使われている。
1969年の RC 4000 Multiprogramming System では、小さな中核部の上で異なる目的のOS群を整然とした方法で構築するというシステム設計哲学を導入しており、マイクロカーネル方式のさきがけとなっている。
UNIX以前の10年間、コンピュータは劇的に能力を向上させ、マシンの未使用時間を使う手法が求められた。この期間の主な開発のひとつがタイムシェアリングシステム (TSS) である。TSSは何人かのユーザーがCPUのタイムスライスをそれぞれ割り当てられる。
カーネル カーネル開発史
タイムシェアリングシステムの開発は多くの問題を発生させた。ひとつの問題は大学のユーザーはCPU時間が欲しいというよりもシステムをハックしたがっているという点である。このためセキュリティやアクセス制御が1965年のMulticsプロジェクトの重要な課題となった。もうひとつの問題は計算リソースの正しい扱い方である。ユーザーは計算リソースを使わずに画面を凝視することにほとんどの時間を費やしており、タイムシェアリング方式ではそのようなCPU時間を他のユーザーに与えるべきと考えられた。最終的に、メモリ階層の多層化が進み、リソースの分割が仮想記憶システムの開発へと繋がっていったのである。
UNIXの設計段階で、全ての高レベルのデバイスをファイルとして抽象化することが決定された。なぜならUNIX設計者は情報処理の目的をデータの変換であると考えていたからである。
カーネル カーネル開発史
たとえば、プリンターもファイルとして抽象化され、データをそのファイルにコピーすると印字が行われる。他のシステムでは同様の機能を提供するにあたって、デバイスを低レベルに抽象化する傾向があった。デバイスもファイルも何らかの低レベルの概念の実体化である。システムをファイルのレベルで仮想化したことにより、ユーザは既存のファイル管理機能と概念で全てを扱うことができるようになり、操作が大幅に簡略化された。同じパラダイムを拡張して、UNIXはファイルを複数の小さなプログラムで操作するパイプの概念を可能とした。最終的な結果は同じであっても、このような小さなプログラム群を使うことで柔軟性が劇的に向上しただけでなく、開発も利用も容易になった。
UNIXでは、オペレーティングシステムは2つの部分で構成される。さまざまな操作を実行するユーティリティプログラム群とカーネルである。プログラミングの観点から見ると両者の違いは小さい。カーネルは特権モードで動作するプログラムであり、プログラムローダーとしての役割とシステムの残りの部分を構成するユーティリティプログラム群を監督する役割を持つ。そして、それらプログラムにロックと入出力サービスを提供する。つまり、カーネルはあらゆる場面に介在しているわけではなかった。
カーネル カーネル開発史
その後、計算モデルが変化し、UNIXの何でもファイルで表す手法が常に適用可能な方法ではなくなってきた。端末はファイルで表せるが（どちらも文字列を読み書きできる）、GUIはそのように扱うことはできない。コンピュータネットワークは別の問題を提起した。ネットワーク経由の通信はファイルアクセスに対応させることができるが、低レベルのパケット指向アーキテクチャはファイルというよりも離散的なデータの塊として扱う必要がある。コンピュータの機能が拡大するにつれ、UNIXのコードは増大していった。それはまた、UNIXカーネルのモジュール性が非常にスケーラブルなためでもあった。初期のカーネルのソースは10万行ほどだったが、Linuxカーネルなどでは1300万行にもなっている。
現代のUnix系OSは、モノリシックカーネルにモジュールローディング機能を加えたものとなっている。たとえば、Linuxカーネルを採用した各種Linuxディストリビューションや、BSDの子孫である FreeBSD、DragonFly BSD、OpenBSD、NetBSD、macOS などがある。
カーネル カーネル開発史
Appleは1984年、最初のMac OSを同社のパーソナルコンピュータMacintoshに同梱して発売した。後継のmacOSはDarwinをベースとしており、4.4BSDユーザーランドとMachカーネルを統合したXNUと呼ばれるハイブリッドカーネルを採用している。
Microsoft Windowsは1985年、MS-DOSへのアドオンとしてリリースされた。他のOSに依存していたため、Windows 95までのリリースはOSではなくオペレーティング環境とみなされている。その製品ラインは発展して、Windows 9x系となり（32ビット化やプリエンプティブ・マルチタスクといった強化を経て）、最終的に2000年にWindows Meがリリースされた。マイクロソフトはまた、ハイエンド向けにWindows NT のラインも1993年の Windows NT 3.1からスタートさせ、こちらは2000年以降も続いている。
2001年10月にリリースされたWindows XPでWindows 9x系を置換して一般ユーザー向けOSが一新された。Windows NT系のカーネルはWindow ManagerやIPC Managerとクライアント・サーバ型階層型サブシステムモデルを採用しており、ハイブリッドカーネルとみなされている。
汎用マイクロカーネルとしてはカーネギーメロン大学が1985年から1994年まで開発したMachが有名だが、特定用途向けにもいくつかのマイクロカーネルが開発された。L4はマイクロカーネルの性能が悪くないことを実証するために作られた。ここから派生した新たな実装の Fiasco や Pistachio はLinuxをその上で動作させることができる。
QNXはマイクロカーネル設計を採用したリアルタイムオペレーティングシステムであり、1980年代初期に開発され、Machよりもはるかに成功している。ソフトウェアが不正作動することが致命的な状況で使われることが多く、スペースシャトルのロボットアームの制御やガラスを精密に磨く機械の制御で使われている。
物性物理学
物性物理学（ぶっせいぶつりがく）は、物質のさまざまな巨視的性質を微視的な観点から研究する物理学の分野。量子力学や統計力学を理論的基盤とし、その理論部門を物性論（ぶっせいろん）と呼ぶことも多い。これらは日本の物理学界独特の名称であるが、しばしば凝縮系物理学に比定される。狭義には固体物理学を指し、広義には固体物理学（結晶・アモルファス・合金）およびソフトマター物理学・表面物理学・物理化学、プラズマ・流体力学などの周辺分野を含む。
物性物理学 歴史
18世紀以前において、物理学は物体の運動や天体の運行など解析学や幾何学によって説明できる分野を中心としていた。これに対して化学は物質の性質をあるがままに、すなわち博物学的に記述することが一般的であった。
18世紀に発展した熱力学は、物質としての気体の性質を巨視的な観点から現象論的に体系づけたものであり、これが物性物理学の基礎となった。19世紀後半になると物質の熱力学特性を、より微視的な立場から体系的に記述する統計力学の考え方が本格的に導入され、現象論に過ぎなかった熱力学に基礎付けがなされた。さらに20世紀前半には量子力学が確立し、固体の結晶構造や化学反応を記述できるようになった。
また最近では高分子や液晶、コロイド等を対象とするソフトマター物理学も物性物理学の一つの分野となっている。ただし、日本において物性論あるいは物性物理学という言葉が使われるようになったのは1940年代以降である。
物性物理学 理論
物性理論は、理論モデルを用いた物質状態の性質の理解と関連する分野である。これには、固体の電子状態モデルの研究、例えば、ドルーデモデル・バンド構造・密度汎関数理論といったものが含まれる。また、相転移の物理の理論モデルの研究（例えば臨界指数の理論やギンツブルグ-ランダウ理論など）や、量子場の理論や繰り込み群に使われる数学的手法を応用するといった分野も発展している。現代的な理論研究は、電子状態の数値計算や、高温超伝導・トポロジカル秩序・ゲージ対称性等の現象理解のための数学の利用とも関係している。
物性物理学 実験
物性実験は、実験装置を用いて物質の新しい性質を発見することに関連する分野である。例えば、電磁場を作用させて周波数特性や熱伝導特性、温度を測定したりする。よく用いられる実験手法には、X線や赤外線、非弾性中性子散乱を利用した（広義の）分光法や、熱的応答の研究、つまり比熱や伝導による輸送熱の測定といったものがある。
物性物理学 応用
物性物理学の研究は、様々なデバイスへの応用を生み出した。例えば、トランジスタ、レーザー技術、ナノテクノロジー:111ffで研究される様々な現象が挙げられる。走査型トンネル顕微鏡の技法はナノスケールでの制御過程に応用され、ナノリソグラフィという研究分野を生んだ。
量子コンピュータの分野では、情報は量子ビット（またはキュービット）で表される。量子ビットは、計算が終わるより前に素早く量子デコヒーレンスを起こしてしまうかもしれない。この重大な問題は量子コンピュータが実用化される前に解決されなければならない。ジョセフソン接合による量子ビット、磁性体のスピン配向を用いたスピントロニカル量子ビット、分数量子ホール効果状態から得られるトポロジカル非アーベルエニオン等、問題解決のためのいくつかの有望なアプローチが物性物理学の分野から提案されている。
物性物理学は生物物理学の分野にも重要な応用がある。例えば、核磁気共鳴画像法は医療診断の現場で広く使用されている。
物性物理学 物性論を扱う高等教育機関
かつては、物理第二学科（東北大学、名古屋大学）、物性学科（広島大学）として、独立の学科組織を持ったところもあった。
1963年に創設された広島大学の物性学科は、物性物理学以外に、生物物理学といった化学との境界領域の研究、教育が行われたが、物理系講座の増加で独立学科としての存在意義を失って学科募集を停止し、講座は物理科学科と化学科（生物物理化学系のみ）に吸収された。
東京大学では理学部・工学部・教養学部の他、大学院新領域創成科学研究科、物性研究所でも物性物理学の研究が行われている。この中で物性研究所は、文部省と科学技術庁が日本学術会議の勧告を元に共同で設立した物性物理学分野の全国共同利用研究所であり、理論・実験の両分野にわたって幅広く教育研究が行われている。この他の全国共同利用研究所では、東北大学金属材料研究所、京都大学基礎物理学研究所に物性物理学関連の研究室がある。
磁性体
磁性体（じせいたい）とは、一般には磁性を帯びることが可能な物質であり、専門的には反磁性体・常磁性体・強磁性体の3つに分けられる(注：近年はこれ以外にも交代磁性体という新たな磁性体の分類が加わり注目されている)。このため、すべての物質が磁性体であるといえるが、通常は強磁性体のみを磁性体と呼ぶ。比較的簡単に磁極が消えたり反転したりしてしまう磁性体は軟質磁性体と呼ばれ、そうでない磁性体は硬質磁性体と呼ばれる。
代表的な磁性体に酸化鉄・酸化クロム・コバルト・フェライト・非酸化金属磁性体（オキサイド）などがある。
固体状態のものは磁石として、電動機の界磁として使用される。
硬質材料の円盤上に磁性粉を塗布あるいは蒸着したものがハードディスクドライブ（のプラッタ）に用いられる。柔軟な合成ゴムにまぜて板状にするとマグネットシートになり、液体にコロイド分散させると磁性流体となる。医療分野では強力な磁力を使ったMRIやごく微弱な磁力を利用するSQUIDの形で実用化されている。新しい情報記憶素子のMRAMなどを含むスピントロニクスと呼ばれる科学研究分野が注目されている。
磁性体 磁性体材料の評価
磁性材料の評価は、磁場を正負の磁場に掃引させることに得られるヒステリシスカーブによる解析が主だが、測定結果は、測定対象物の磁気モーメントの平均値となるので、対象物中の磁気相互作用や保磁力の分布に対する情報は得ることができない。近年では、ナノスケールの磁性材料やナノコンポジット磁石などの研究も盛んになっており、磁気特性を評価するためには、平均化された特性だけでなく、材料中の構成物質間の相互作用などについての評価も重要になってきている。
磁化された磁性体を磁化されていない状態に戻すために必要な反対向きの外部磁場の強度。
飽和磁化は材料固有の磁気物性値で強磁性物質を磁界中に置いて磁界を増加させていくとある磁界以上で磁化が一定となる。この磁化を飽和磁化という。温度の上昇とともに、飽和磁化は減少する。
磁石が持つエネルギーの大きさは、B-H減磁曲線上の磁束密度Bと磁場Hの積に比例する。このBxHの最大値を最大エネルギー積(BH)maxと呼び、kJ/m3(MGOe)で表す。
あらゆる形の磁石には磁化と磁化の大きさに比例する反対方向の磁場（反磁場）Hdが必ず発生する。
この反磁場Hdは下記のように表される。
Hd = -NJ （N ： 反磁場係数）
磁性体 磁性体材料の評価
このときＮは反磁場係数と呼ばれ、磁石（磁性体）の形状によって決まる数値で、反磁場係数Nの代わりに、次式で定義されるパーミアンス係数Pcを使って磁場解析をすることが多い。
Pc = -Bd/Hd
一般的には磁化方向と垂直な断面積が大きいほど、また磁化方向の厚みが薄いほど反磁場Nは大きくなり、逆にパーミアンス係数Pcは小さくなる。
パーミアンス係数Pcと反磁場係数Nの間には、次のような関係が成立つ
。
Pc = （1-N）/N
結晶磁気異方性定数は材料固有の磁気物性値で、磁石特性のひとつである保磁力と関連しており、この定数が大きければ大きいほど保磁力を大きくすることが可能で磁化しやすい結晶軸方向に磁化させるエネルギーと磁化しにくい結晶軸方向に磁化させるエネルギーの差を表す。
着磁済みの磁石は周囲の温度が変化すると、熱エネルギーの関係で磁気特性が変化する。
元の温度に戻ると磁気特性も同じ値に戻る可逆温度変化と温度が戻っても磁気特性が戻らない不可逆温度変化がある。
温度が起因する着磁後の減磁は一般的には不可逆温度変化によるもので、これには初期減磁に起因するものと経時変化に起因するものがある。
可逆温度変化（可逆減磁）、不可逆温度変化（不可逆減磁）については、特にHcjの温度係数に注意する必要があり、磁石形状によるパーミアンス係数も重要な要素になる。
誘電体
誘電体（ゆうでんたい、英: dielectric）とは、導電性よりも誘電性が優位な物質である。広いバンドギャップを有し､直流電圧に対しては電気を通さない絶縁体としてふるまう。身近に見られる誘電体の例として、多くのプラスチック、セラミックス、雲母（マイカ）、油などがある。
誘電体は電子機器の絶縁材料､コンデンサの電極間挿入材料､半導体素子のゲート絶縁膜などに用いられている。また、高い誘電率を有することは光学材料として極めて重要であり、光ファイバー、レンズの光学コーティング､非線形光学素子などに用いられている。
誘電体 誘電分散
誘電率は電界の周波数に依存する。これを誘電分散と呼ぶ。
空間電荷分極と配向分極は緩和型、イオン分極と電子分極は共鳴型の誘電分散を示す。