FirastClassのオペレーションの鍵となったのは、基礎を成すFCP (FirstClass Protocol)だった。FCPは、トランスポート層の通信プロトコルで、FirstClassにおけるすべての通信で使用される。このプロトコルは、ファイル転送のみならず、すべての動作に対してエラーの無い通信を保証する。FCPは異なる複数の物理層で実行できた。初めはモデムとAppleTalkに対応し、後にNovellのIPXやTCP/IPに対応した。サーバーとクライアントはこれらのどのリンクを通してでも通信できたので、自宅からでもオフィスからでも場所を選ばず、同じサーバーへのアクセスが可能になった。FCPは、様々なパケットサイズを異なるネットワークプロトコルに合わせる、スライディングウィンドウをベースとした通信を行っていた。後のバージョンで、TCP/IPといったエラーフリーのリンク上で実行する際には、FCP独自のエラー訂正システムを使わないようにすることができるようになった。また、FCPにはBlowfishをベースとする暗号化システムがオプションで実装されていた。これらの機能を使わないようにした場合、FCPは当時主流だった2400bpsのモデムでも良いパフォーマンスを発揮した。さらにすべてのFCPパケットは、TCP/IPにおけるポート識別と同様の「タスクナンバー」識別名を備えていた。これによりFCPは、それぞれのクライアントとサーバー間でいくつもの仮想リンクを構成することを可能にした。サーバーはマルチスレッドのカーネルを実装し、クライアントに要求されたすべてのタスクに対して新しいスレッドを開いた。ユーザーはメールを読んだり作成したりしながらも、ファイルのアップロードとダウンロードを同時に行うことができた。
FirstClassはもともと、SoftArc社の製品である。SoftArc社は、カナダ・トロントのダウンタウンにあったノーテル社のリサーチ部門である、ベル・ノーザン研究所のメンバーであった3人により創設された。兄弟二人とその友人から成るその3人は、Meridian Mailシステムの初期の開発者であり、その開発で成功を収めた彼らは自らをトロント・アイデア・グループと呼称した。経営が軌道に乗ると彼らは退職し、コンサルティング会社としてSoftArc社を設立する。FirstClassは、スカボロー教育委員会(現トロント教育委員会の一部)で働く家族や友人の要望に応えて開発された。トロント・アイデア・グループは、LAN接続もモデム接続も可能で、GUIを採用し、個人的な電子メールや公のディスカッションエリア(会議室)を利用できる、安価なMacintoshベースの電子メールシステムを探すように頼まれる。掲示板はモデム接続と会議室の条件は満たしていたが、一般的にLAN接続には対応していなかった上に、キャラクターベースであった。MacのGUIベースで、LAN対応の電子メールシステムはたくさんあったが、他のMacの電子メールシステムはモデム対応に乏しく会議室機能を持つものが少なかった。チームが見つけ出した唯一の製品はTeleFinderで、条件を満たすところまであと一歩だった。しかし、LAN接続するためには、機能拡張し、AppleTalkデータをある種の仮想モデムポートにリダイレクトしなければならないという短所があった。GUIを改良することもできたので、契約を交わしTeleFinderシステムをセットアップしても良かったのだが、チームはより良い新製品を開発することを申し出た。その提案が受け入れられ、1989年にEduNetの取り組みが始まり、1990年に利用が開始された。.
異形態（いけいたい、英語: allomorph）とは、同一の形態素であるものがいくつかの異なる形をもって現れるときに、その個々の互いに異なる形を指す。
古村理（ふるむら　おさむ、1945年 - ）は京都市出身のグラフィックデザイナー、アートディレクター、日本を代表するブランディングディレクター。愛称「ロングセラーの古村」と呼ばれている。
前翅長は16-17.5 mm。オス、メスとも他のフィリピン諸島に広く分布するT. jalajala、パラワン島に産するT. isaeusやミンドロ島に産するT. alangani によく似ているので、同定には注意が必要である。
名義タイプ亜種はミンダナオ島のアポ山（3,144 m）で採集されているだけである。レイテ島産の個体は別亜種(T. m. motokoae)[:en]になっている。
ハカム1世（al-Hakam 1st; 771年-822年）は、796年から822年までアンダルスを治めた後ウマイヤ朝の君主。
f00f命令を問題のあるシステム上で実行しても、ハードウェア的なダメージを起こさない。もちろんファイルシステムやオペレーティングシステム、その他の状況にもよるが、ディスクバッファがフラッシュされていなかったり書込み操作中にドライブに割り込まれたり、とあるアトミックでない操作中に割り込まれたりした状態でこのコードを踏み、フリーズしたならば、データを失うことはあり得る。技術的に正しい例えかどうかわからないが、f00f命令はしばしばHCF命令、ないしkiller pokeとして考えられる。f00fバグは一般的に知られたので、この言葉は時々よく似たハードウェア設計ミス、例えばCyrix coma バグのようなものを指すのにも使われる。
広く普及していたプロセッサにエラッタが発見されたことから、オペレーティングシステムベンダは発生条件を検知してクラッシュを防ぐ対策を実装する作業に追われた。回避にはオペレーティングシステムでの対策を要する。例外発生時に、例外ハンドラへのアクセスが、まずページフォールトを発生するようにして、不具合を回避する（詳細はインテルの技術資料等を参照）。
6to4では、途中のノードがIPv6に対応しなくても通信が行えるため、IPv6が整備される初期の段階で特に必要となる技術である。ただし、あくまでIPv6への移行段階で使うためのものであり、恒久的に使われることを意図したものではない。6to4は、ホスト単体でも、ローカルなIPv6ネットワークに対しても適用することができる。あるホストを6to4対応とする場合、そのホストにはグローバルなIPv4アドレスが必要であり、また6to4としてのパケットのカプセル化や取り出しはホストが自前で行う必要がある。ホストが他のクライアントからIPv6のパケットを受け取って、それを6to4にカプセル化するように設定する、つまり6to4のルーターを設置することもできる。ほとんどのIPv6ネットワークは自動設定されるが、この場合IPv6アドレスの下位64ビットがホストに割り当てる分となる。6to4では、最初の16ビットが2002:と固定され、続く32ビットにはIPv4のアドレスが入り、残りの16ビットはルーターが選ぶこととなる。自動設定が有効なIPv6ホストでは、ホスト自身で下位64ビットが一意に決定されているので、残り64ビットをルーター通知することでIPv6アドレスが完成する。6to4ルーターは、宛先の上位16ビットが2002:なら続く32ビットのIPv4アドレスへ直接、そうでなければIPv6ネイティブなネットワークとの通信が行えるリレーサーバーへ、パケットをIPv4にカプセル化して送信する。6to4は、IPv4しか使えないホストとIPv6しか使えないホストの相互通信を可能とする技術ではなく、あくまでIPv6ホスト同士が通信するための透過的に使えるレイヤーである。設定ミスの多発や性能が出ていない現状を前にして、2011年8月には6to4をどのように導入すべきかというRFCが公開された。