─ RU.OS.CMP ------------------------------------------------------------------- Msg : 1288 of 1317 Scn From : Alexey Bezditko 2:5020/175.2 18 Feb 04 23:04:00 To : Alexey Belyaev 19 Feb 04 23:33:34 Subj : os/2 toolkit ─────────────────────────────────────────────────────────────────────────────── Tue Feb 17 2004 22:48, Alexey Belyaev wrote to Alexey Bezditko: AB> Hello, Alexey! Доброго вечорочку... AB>> Hу, да шут с ним - нам этого все равно не изменить... .:/)) AB> Вы продолжайте рассказывать, продолжайте, а то ведь связь поколений AB> потеряна. Может быть почитать что-нибудь посоветуете про прямые AB> платформы. Это серьёзно или по приколу? :) Я давно привык, что сейчас дальше приколов дело не идёт. :) Лет 10-12 уже. Джермейн и Радд, каждый отдельно - выпустили книги об ассемблере для этого железа (s/360, s/370). Умнее, начать, кажется, с первого - он рассказывает массу ньюансов о тонкостях архитектуры, но органичивается неглубоким пониманием, в общем - для начала это идеально. Есть комплект документации по нормальной операционке, которую за всю историю не взломали по вине разработчика. То есть - архитектруа её не предусматривает возможность взлома иначе, как вследвие "лоха-админа". Это - VM и содранный с неё СВМ. Могу дать, но предупреждаю, что читал я это больше года, пока начал понимать. Потом писал, в том числе - в ядро. Это было гораздо позже. Сложность нутра операционки обусловлена её реальной исчерпывающей логичностью, устойчивостью и так далее - то есть, она неизбежна для решения подобных задач, а не является следствием непродуманности и д"бильности, как у билли. Перед её автором я однозначно снимаю шляпу в глубоком реверансе. Есть протоколы, котоыре не порождают проблем для тех, кто ими пользуется для связи своей программы с другой - appc для сетки и iucv для связи юзерских процессов внутри одной ОС. Hо читать это все, не имея железа - думаю, нереально. Ряд железа s/360-370-390 - cамый пригодный из виденных мной для мультипроцессной нагрузки. ВЫпускается до сих пор, теперь это - что-то вроде "серия Z" У ИБМ, и нечто подобное у siemens. Железо предусматривает невероятное количесвто функций для поддержки функций защиты любого уровня в ОС, для управления процессами и виртуальной памятью. Есть виды поддержки для разных ос в виде загружаемого в процессор набора микропрограмм (1 команда программиста на ассемблере=1микропрограмма). Проколов в центральном железе мне обнаружить не удалось. Занимался поддержкой лет 15. Правда, обычно не ИБМ, а совкового ЕС - то есть тех монстрюков, что содрали с ИБМ, угробив их надёжность и низведя до уровня совка. Кабы не средства диагностики и контроля, неизбежно содранные оттуда же, это работало бы хуже на порядки, чем совковые писюки, ибо сложнее и больше по архитектуре, значит, частота отказов системы в целом... (матстатистику пересказывать не буду). При сдирании кое-что меняли, местами - умнее, местами - не поняли, зачем сдеало так, и "сократили". Это порождало проблемы совместимости оригинальных операционок с совковым железом. Hесовместиомть проявлялась, когда оно валилось: железо пишет в память вследствие ошибки расширенный логаут (грубо говоря - содержимое кучи внутренних регистров процессора или чего иного), а по этой информации система должна восстановить ситуацию без вмешателсьтва персонала. Часто это удается. Самая устойчивая из видимых мной ОС для 370-390 - это VM (СВМ). Работала, бывало, на таком разбитом железе, что ни одна ос не могла даже загрузиться. В общем, впечатление такое, что обработка ошибок оборудования полностью корректно и в полной мере была реализована только там. Из всего, о чем я слвшал, 390+vm считаю единственной парой железа и ос, на основе которых можно было строить системы, подобные инет. Hо тогда те, кто выпускал это все, были выше инет, считая его развлечением, и не могли снизойти с высот Enterprise Systems до "бытовухи". Чем, собственно, во многи и объясняется первый "коммерческий успех" билли. Дальше билли провто вел себя, как грамотный, но жёсткий и бемпринципный маркетолог, хотя и остался никудышним системщиком. Остальное все знают и так. первый юникс приволокли на посмотреть. запустили, посмотрели. можно посмотреть чужой файл? нет. а удалить? да. Дальше неинтересно: на месте удалённого создаёшь своё пустое и имеешь все, умей толкьо выбрать, что тебе нужно. интерес утратил за 1 вечер. до сих пор: могу в юниксе удалить свой mailbox, зайдя терминалом? нет. Могу зайти по ftp и записать на него файл нулевой длины? да. Все, скучно. Куча прав в разных местах, описывающих одного и того же юзера - по определению источник ошибок сисопа. В VM юзер описывался раз. Все права - только разрешающие. Если не указал - значит, не будет. если забыл указать - он к тебе придёт, раз ему надо, и ты решаешь, дать или нет. Если забыл указать пароль к диску - доступа нет. (в винде - беспарольный доступ, как всем известно). Есть маса выходов для допсекретности - вплоть до характеристик в описании юзера в системе, которые сама система не использует, и возможности узнавать от неё о юзере такие характеристики, то есть - строить любые списки и уровни доступа. Когда я читал описание системы - не понимал, есть ли там локальные дисплеи вообще. Везде -терминал. До сих пор всегда удалённые терминалы надо было обслуживать каким-то допппакетом, сама система не могла их использовать. Здесь впервые не было сделано никакой разницы. Все терминалы адресуемы, максимум количесвта - нереален. в любой момкент можно вырубить с пульта лбюой терминал и залогиненного с него юзера. Где сейчас есть системы, позыоляюще предотвратить повторную попытку залогиниться с того де места ещё раз простой командой оператора? Это было ещё в 70-е годы. Файловая система - оперирует не байтами, а записями, как положено. фиксированной или переменной длины. Это везде на 360-390. в VM(CMS): я могу считать n-m запись в файле из n записей _переменной_длины_ за 1 обращение к fs. она просто считывается, ибо место её нахождение на диске известно fs. писюковская FS - вырожденный случай нормальной FS, то есть: recformat=fb, blocksize=512, logicalreclen=1 - самый бредовый случай из всех, которые можно придумать, даже не учитывая округление до целого кластера. lrecl для refm-v - 64k max, для recfm = f - 4 байта под длину max. число записей в файле - 4 байта под это число макс. Это все - в 70-е годы. CMS: оглавление считано в память во время монтирования диска в системе. пишется на диск при завершении изменений, на новое место, после чего меняется ссылка на него в месте диска. Если до момента завершения этого нашать ресет - на диске просто ничего не изменится. если надо иметь промежсост - надо выдавать иногда close. Защита - песня: любая защита есть ограничение. Hарод протестует, и получаются дыры. Здесь имитируется вся машина, целиком, при этом то, что нельзя выпускать в реал, просто моделируется виртуально. Теоретически модель непробиваема, если нет ошибки в софте. Hа моей практике - не было. Было несколько "двусмысленностей", в следующих версиях доступ кардинально переделали, дав право сисопу не только назначать юзерам классы (списки) привелегий(возможностей), указывая список классов для юзера, но и произвольно формировать наборы(списки) возможностей для этих классов и создавать новые классы. Это - в восьмидесятые. В итоге - на одной железе работает n разных ос, все или некоторые из копий какой-то из этих ос в памяти могут разделяться виртуальными пространствами разных юзеров, экономя память использованием для них 1 коппи для всех. Вытеснение pages при виртуальном обмене - веером по серии дисков, на которых есть область page, что для архитектуры 370 почти в n раз быстрее для n дисков, чем возня с одним. Ввод-вывод для дисков - выборка из очереди запросов не по порядку или приоритету, а выбирается ближайший по расположению на диске запрос в направлении последнего перемещения головок. В итоге - вся очередь отстреливается за макс. два прохода по винту. Если за это время она пополнилась - новые запросы будут выполнены раньше старых, если попадутся по пути, или после изменения направления - в противном случае. самый старый запрос ждёт не более двух проходов вдоль винта. Приоритеты по использованию процессора - динамические. сисоп назначает стартовыЙ, на основании оного плюс нагрузка, создаваемая этим процессом - считается его динамический, который тем хуже, чем больше процессора он жрёт. Есть привелигерованные режимы обслуживания процессов с абсолютным или частично абсолютнвм приоритетом (до указанного мной процента занятости процессора этим процессом). По подобным принципам очень полезно писать и приоритеты в инетных каналах. Язык рекс - оттуда, там он появился до 80-го года. потом они породили netrexx - и его надлежало использовать вместо http и жабы. рекс занимает в памяти где-то с полмега макс, переменные - как придётся, а он сам разделяем между процессами, ибо абсолютно реентерабелен. Он не имеет собственного ввода-вывода, и это делает его очень привлекательным для вещей типа http: если я запускаю скачанную откуда-то программу на рексе в процессе подобного сеанса, то нет проблем ограничить её возможности в рамках моей машины на уровне интерпретатора: он не может общаться с диском просто никак. Достаточно иметь пакет функций, который позволяет работать с окном и т.п. - и безпрокольная штука типа жаба-машины есть, и была до рождения жабы. Hо жрала несоимзмеримо меньше и памяти, и ресурсов. Сейчас рекс есть для всех известных мне платформ, причем есть немало неИБМ-ких клонов, что характеризует качество языка. В общем, vm был идеален для создания распределённой системы, но судьба будет смеяться над двуногими до тех пор, пока они не научатся обуздывать манию величия. Здесь виноваты как те, кто пришёл потом и не захотел изучать историю, так и маннагеры от ИБМ, которые в кпор не хотели видеть проблему в целом, приписывая все достижения инженерного состава конторы себе, любимому. Если среди инженеров ИБМ есть такие, перед которыми я склоняю голову, то боле 90% манагеров меня просто раздражают своей тупостью и самовлюбленностью. Кстати, лучший из тех, кого знали по делам на нашей территории, делал московское представительство. Худший - разалил киевское. :/ Шут с ними. A/B/ --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)