>Вот Вам ссылка http://www.unix.org/version3/online.html - вышлите ее Торвальдсу и Ваше имя попадет
>в историю линукса.

хорошо вам. Оперируете современным положением. А в средине 90-х сильно было поумничать негде...  ну и почитать нахаляву. (кста, остальные 8 частей где мона нарыть ? - возможно путаю общее количество разделов посикса, ну а если это все - то все ок, современные торвальсды имеют больше возможностей проявить себя)

>Не путайте теплое с мягким: posix определяет интерфейс для т.н. user threads
>(пользовательских нитей), то, что Вы называете группами процессов и процессами линуха,
>на самом деле является kernel threads (тьфу-ты, procs) и POSIX-ом не
>регламентируется. Тип связи между ними выражается цифирками 1:1, N:M и т.д.
>и закладываетя в libpthreads. Времени нет объяснять Вам дальше, что это
>такое, поройтесь в Google.
писал это по памяти с цытаты Торвальдса. Но суть передал четко.
Хотя, я сам посикс по вопросу не читал.

>> Делалось для того, чтобы полноценно учесть все нити (процессы) при шедулинге.
>В проектировании NPTL упор делался на light weight в ущерб fairness-у шедулинга.
возможно. Не знаю о чем именно и когда говорил Торвальдс. Возможно с тех пор многое изменилось.

>По сравнению с, например, NGPT (не буду сравнивать с BSD и
>соляркой), времена исполнения группы "одинаковых"(если так можно выразится) тредов будет иметь
>несколько меньшее мат. ожидание при большей дисперсии.
да, смотрю ты это курил в правильном математическом свете. Я пока недотягиваю (не интересовало именно это пока что)

>Так, что для задач,
>у которых критично именно максимальное, а не среднее время отклика, NPTL
>учитывает все не самым полноценным образом.
возможно. Не стремился это проверить.