歴史学者たちは古代の記録が365年の破滅的な地震だけに言及しているのか、それとも350年から450年の間に発生した地震の数々を習合した歴史的記憶として説明しているのかという疑問について議論し続けている。現存する文学的証拠の解釈は、古代末期の著述家たちの自然災害を政治的・宗教的事件に対する神の反応として表現する傾向のために複雑なものとなっている。特に、当時勢いを増していたキリスト教と異教との間の敵意に満ちた反目によって、著述家たちの記録の取り扱いが歪められている。ソフィストのリバニウスと教会史家ソゾメヌスは365年の大地震と別のより規模の小さな地震の情報を混同しているように見え、それぞれが自身の視点に依って、異教信仰を復活させようとしたユリアヌス帝が2年前に死去したことに対する神の嘆き、または怒りとしてこの地震を位置付けている。とは言え、全体としては、歴史的記録が僅少であることに特徴付けられるこの時代にあって比較的多数の諸地震への言及が存在することは、地震活動が活発化していた状況を強調するものである。例えば、キプロス島のクリオンはこの時代、80年の間に5回の強い地震に襲われたことが知られ、このために破壊され滅亡した。
最近（2001年）の地質学的研究によって、365年のクレタ地震は東地中海における4世紀から6世紀にかけての主たる地震活動と関連付けられるものと考えられている。これらの地震はこの地域の全ての主要なプレート境界の再活性化を反映している可能性がある。この地震はクレタ島における9メートルもの隆起の原因であると考えられており、その規模は地震モーメント1×10²² N·m (7.4×10²¹ lbf·ft)、モーメント・マグニチュード8.6に相当すると推計されている。この規模は、この地域に影響を及ぼした現代の既知の地震全てを上回っている。炭素年代測定はクレタ島沿岸のサンゴが10メートル持ち上がり、一度に水面に押し出されたことを示唆している。これは365年の津波がクレタ島そばで急激に落ち込むヘレニック海溝での地震によって発生したことを示している。科学者はこのような大規模な隆起は5,000年に1度しか発生しないと見積もっている。だが、海溝の他の部分も同じ規模でスリップを起こす可能性はあり、それは800年周期で発生している可能性もある。「隣接している部分の1つが将来スリップを起こす」かどうかは不明瞭である。
クレタ地震は365年7月21日（ユリウス暦）の夜明け頃に発生した地震である。震源は東地中海のクレタ島近くと想定されている。地質学者たちは今日、この海底地震のモーメント・マグニチュードが8.0以上であると見積もっている。この地震は中央および南部ギリシャ、北部リビア、エジプト、キプロス島、シチリア島、スペインなど広範囲に壊滅的な被害を及ぼした。クレタ島ではほぼ全ての都市が破壊された。この地震では津波が発生し、地中海の南部および東部沿岸、特にリビア、アレクサンドリア、ナイルデルタを壊滅させ、数千人の死者を出し船を3キロメートル内陸まで運んだ。この地震は古代末期の人々に深い印象を残し、当時の数々の著作家がこの出来事に言及している。
全体がセイヨウナシのような左回りの芝コース。コースはほぼ平坦で1周は16ハロンで直線は5ハロンと広大なコースが特徴。平地競走用のコースの内側には障害競走用のコースがある。
プロセスグループ (Process Group) とは、POSIX準拠のオペレーティングシステムにおいて、1個以上のプロセスの集まりを意味する。この集まりはプロセスグループリーダーとなっているプロセスのプロセスIDと同じ値をプロセスグループIDとして識別に使用する。プロセスグループはシグナルを複数のプロセスに配布するために使用される。killシステムコールはシグナルを個々のプロセスに送るだけでなく、プロセスグループに送ることもできる。プロセスグループに向けられたシグナルは、そのグループのメンバーである全プロセスに送られる。プロセスグループへのシグナル送信は、シェルプログラムが使用するジョブコントロールの基本となっている。ttyデバイスドライバは、キーボードからの割り込みを契機としてフォアグラウンドのプロセスグループに SIGTSTP、SIGQUIT、SIGINTというシグナルを送る。また、フォアグラウンドでないプロセスグループが端末からの入力待ち状態（また、適切なフラグが設定されていれば表示待ち状態も）になっている場合にSIGTTINシグナルやSIGTTOUシグナルを送る。シェル（ひいてはその操作者）はコマンドパイプラインからプロセスグループを生成し、どのプロセスグループが端末の制御を握るフォアグラウンドのプロセスグループになるかを制御する。プロセスグループは常にひとつのリーダーから始まるが、必ずしも常にリーダーが必要というわけではない（リーダーが他のプロセスより先に終了することがある）。POSIXによれば、プロセスが偶然にグループリーダーなることはない。そのため、あるプロセスIDがプロセスグループIDとして使われている間は、それがプロセスIDとして再利用されないようにする必要がある。プロセスグループのリーダーになるには、明示的に setpgid() または setsid() システムコールを呼び出す必要がある。setpgid()システムコールは新たなプロセスグループを生成したり、プロセスを既存のプロセスグループに入れたりする汎用の呼び出しである。リーダーになるには、自身のプロセスIDを指定すればよいが、通常 setpgid(0,0) という形で呼び出す。シェルがコマンドパイプラインのために新たな子プロセスをforkすると、親であるシェルプロセスと子プロセスは直ちにそのプロセスをプロセスグループリーダーにしようとする。（両者がそれを試みるのは、子プロセスがプロセスグループリーダーになろうとすること、子プロセスがコマンドを実行しようとすること、親または端末デバイスドライバがジョブコントロールのシグナルをそのプロセスグループに送ろうとすること、これらの競合状態が発生するのを防ぐためである。）プロセスグループ自体はセッション (session) の一員となる。これはテキストユーザインタフェースが使われているUnix系システムで使われたもので、いわゆる「ログインセッション」を意味している。グラフィカルユーザインタフェース (GUI) が使われるようになってこのコンセプトはほとんど意味がなくなり、カーネルがセッションに関して行っていた処理の大部分も無視されている。GUIではログインセッションに関しては全く別の機構が使用されている。セッションリーダーと呼ばれるひとつのプロセスが制御端末とやり取りして端末が切断されるときにセッション内の全プロセスが停止することを保証する。セッションリーダーがいない場合、その端末のフォアグラウンドのプロセスグループがセッション内の他のプロセスグループの面倒も見ることが期待されている。プロセスは異なるセッションのプロセスグループに移動することはできず、プロセスグループも別のセッションに移動することはできない。プロセスグループを生成するプロセスは、自身が入っているセッション内でしかプロセスグループを生成できない。setsid()システムコールを使用して新しいセッションを作る。成功すると、そのプロセスは同時に新たなプロセスグループリーダーにもなる。つまり、このシステムコールはひとつの新しいプロセスグループを持つ新しいセッションを生成することを目的としている。そのとき現在のプロセスがセッションとプロセスグループのリーダーとなる。