На главную | Поиск
Вы находитесь в Хранилище файлов Белорусской цифровой библиотеки

Андрей Богатырев. Записки системщика

... Это утверждение останавливает на себе наше внимание. На первый взгляд оно кажется ерундой. Кажется ерундой оно и на второй взгляд. И только на третий, пристальный и дотошный взгляд, нам начинает мерещиться, что это - полный и окончательный бред.
© Copyright 1995 Андрей Богатырев Андрей Богатырев (abs@openwin.msk.su) Родился в 1965, написал это весной 1995. #sun.nstu.nsk.su/vendors/sun/bogat.html
Итак, настало время оглядеть тот мир, который вращается вокруг нас, и в котором вращаемся мы. В этом мире я с 1984 года обитаю в среде UNIX, и не жалею. Пришлось и в текстах ядра BSD поковыряться, и в шеллах разных, да и в прикладных программах поучаствовать. А уж администрировать и настраивать... Нет, UNIX - это конечно не идеал и даже не подарочек. Но ведь горизонт - это то, что отодвигается, сколько бы мы к нему ни стремились. Так же и с идеалом...

* Операционная система. *

MS DOS

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

UNIX

очень сложная и откровенно плохая операционная система. Проблема в том, что ничего лучше, надежнее и отлаженнее пока не придумали; а если и придумали, то оно еще не вышло за стены лабораторий и из макетов. Изобретения Microsoft - новее, но не лучше.

MS Windows

когда туда добавится многозадачность, наверное будет неплохо. Но все же - это система, выросшая вокруг графического интерфейса. Что, впрочем, не есть плохо - поскольку притянуло за собой объектную ориентированность и средства общения программ между собой. Проблема в том, что все это, и в более совершенном виде, уже было к тому времени в UNIX. Проблема UNIX - что этим мало кто пользовался. Все предпочитали ругать UNIX за командный недружественный интерфейс, нежели пользоваться дружественной оболочкой X Window, которая там уже давно была. Тут можно пронаблюдать и иные интересные проблемы, связанные как раз с открытостью. UNIX - система открытая, ее развивает, улучшает и изучает в исходных текстах масса народу по всему свету: система-лаборатория для всего hack­ er-сообщества. Зато коммерческие поставщики UNIX для разных платформ до недавнего времени рычали друг на друга, прятали все свое по углам, подкладывали друг другу свинок. Как же - UNIX UNIХом (ибо UNIX - он и в Африке... Единственная ОС, перенесенная на десятки архитектур машин), но денежки врозь. Тем временем на рынок вылез Microsoft, который никому ничего из исходных текстов не показывал (то есть был и есть абсолютно закрыт), ни с кем кроме себя не соревновался, и слепил soft­ ware, которым сразу стали пользоваться миллионы. Да, никто не говорит, что он сделал самое лучшее (или худшее), но самое массовое - несомненно. И тут - увы UNIХам. Раньше UNIХисты свысока смотрели на недосистему MS DOS и почивали на лаврах. Теперь... Зато это сыграло положительную роль - и еще не слишком поздно - UNIX-производители перестали рычать друг на друга злобно, а ослабили тон до "настороженно". И пришлось им всем вместе думать о том, как лучшую операционную систему (да еще и уже существующую, и давно) еще и в люди вытолкнуть. Такие пироги. Монстры против выскочки Microsoft-а.

NetWare

ее почему-то именуют "сетевой операционной системой", да какая ж она операционная система? DOS через сеть - система перекачки файлов в локальной (и только) сети. Несерьезно, господа. Вы somputer science изучали? Что такое ОС знаете? Ну и где она? Ну ладно, ладно, пусть даже операционная система. Но не для работающего на машине человека. Для выделенного сервера. А потому - не "сетевая операционная система", а "система для сети". Сетевая - это когда операционная система (в том числе) через сеть работает, ресурсы раздает. Да, еще очень меня раздражает когда Писюк в Novell-овской сети "рабочей станцией" величают. Смешно. Забыли, что такое рабочая станция - а ведь десять лет назад это лучше знали. Когда через десять лет понятию дают выхолощенное значение - это удручает.

NeXTstep

окстись, это тоже UNIX! Да, но что-то он как-то уж графический и объектно-ориентированный какой-то больно. Mi­ crosoft-у такое и не снилось... Да-да, а теперь эта объектно- ориентированная графика перекочевала в UNIX - под названием OpenStep. Вот, в Solaris, например.

Spring

"а это что за зверь такой?", - спросит подавляющее большинство. А это такая распределенная объектно-ориентированная операционная система от SunSoft. Вот все кричат "микроядра", а кто их силу реально использует? OSF/1 над MACH построенная? Нет. А вот Spring - использует, просто для того и делался. А на что похожа? А ни на что. Вот например: процесс в ней может иметь часть памяти на одной машине, часть - на другой. Где надо и где удобнее - там и будет иметь. А кто ее видел? А работает она в лабораториях Sun­ Soft! Как готовая полноценная система, в частности цикл ее разработки ведется под нею самой, без привлечения UNIХа. А приложения под нее есть? А нету... Эта система, вероятно, не будет коммерческой. Зато послужит прототипом операционной системе 21 века. Должен же быть последователь у UNIХа. Кстати, UNIХный интерфейс к Spring пишут русские программисты.

UNIX

снова UNIX. Чего тут теперь только нет! И не по знаменитому принципу "и того нет, и этого нет". Иначе. Вообще, на UNIX посмотришь: свалка-свалкой. Вот что значит - открытая система. Что хотят, то и добавляют. Экспериментальный полигон какой-то, а не операционная среда. Да еще с богатым арсеналом средств для связывания воедино несовместимых между собой вещей - вивисекция сплошная. Вот одно только неприятное для авторов всех других систем свойство имеется: стандарт на UNIX. SVR4 называется. А ни на что другое стандарта пока нет, в том числе на горячо любимый MS Windows API. Так что в UNIX народ побалует-побалует, эксперимент поставит, что-нибудь новое изобретет (как в свое время TCP/IP тут отладили), да потом - бац! - и стандарт на это примет. А все остальные - догоняй.

Windows-95, Windows/NT, OS/2

меня забавляют, но и заставляют кривиться громкие заявления производителей НОВЫХ операционных систем о том, что вот, они добавили новую выдающуюся возможность - вроде кэширования файлов в памяти или оптимизации размещения файлов на диске - которая сделала их систему непревзойденной. Ребята, в UNIX я об этих самых возможностях слышал минимум 6 лет назад. И печально видеть развешивающих ушки чайников, и вправду считающих это изобретением их любимой фирмы, откровением и новинкой, оставляющей далеко позади всех неизвестных им конкурентов. Незнание и невежество дает повод для чванства. Жаль то, что реально новых идей - а не позаимствованных друг у друга - немного. Например, объектность в ОС. Новые идеи к тому же долго мусолятся, испытываются на прочность, разные реализации одного и того же превращаются в войну авторов реализаций. Обнадеживает во всем этом процессе одно: рано или поздно полезное приживается, нежизнеспособные побрякухи отмирают и отваливаются, и начинает пахнуть стандартом (что не означает окончание процесса развития и улучшений); а также то, что рано или поздно все базовые вещи сольются воедино. Различие и многообразие наблюдается только на переднем фронте исследований: молотки и вилки должны быть привычны и единообразны, иначе мы не сможем удобно и привычно пользоваться ими повседневно.

* Компьютер. *

Мне, как программисту, по большому счету безразлично - какая платформа. Мое дело - язык Си, да то, чтобы то, что описано в документации, работало именно так, как оно описано, а не как Бог на душу положит. Работало так, чтобы я мог программировать то, что хочу я, а не получать неожиданные сюрпризы. Чтобы оно мне помогало, а не заставляло превратиться в мастера лавировки и извращений. Работало правильно, в меру быстро и надежно. Ну и удобно, конечно же, не люблю я писать заклинания да еще в десятке мест сразу. Помнить все эти места очень лениво. Короче говоря, машина должна не мешать мне программировать. А это больше всего связано с качеством ОС. Самое главное, зачем собственно программы, операционные системы и разный инструментарий написаны - это чтобы я мог как можно проще и легче получить результат, сделать то, что мне нужно (или просто хочется: "хочу" - есть двигатель развития). Я видел массу "глюков" в ранних Solaris-ах. С прискорбием должен сообщить, что их количество (а главное: убойная сила) в версии 2.4 упало на порядок. Работает уже не "сносно", а "хорошо". Этот путь и HP UX 10, и DEC, и Microsoft с его Windows NT еще должны пройти. Вообще, сейчас есть две противопоставляемые тенденции насчет увеличения скорости работы машин. Одна - это ускорение процессора. Все мило, пока у вас процессор не начинает обгонять все остальные части компьютера настолько, что быстрый процессор вынужден долго-долго ждать к примеру системной шины, которая ему данные из памяти подает. Называется такая веселая ситуация несбалансированностью машины. Вторая тенденция - клепать многопроцессорные машины с не обязательно сверхбыстрыми процессорами. Мол, распараллелим вычисления, так N мужиков за 1 час сделают то же самое, что сделает за один час один мужик, способный один работать за N человек. Идея в меру здравая, кроме одного тонкого момента: не все задачи поддаются распараллеливанию; а того хуже - сейчас параллельно написанных программ маловато. Значит, работать надо, писать их, да старые переписывать. Но на это ж масса денег, людей и времени нужна! Все прекрасно, только я хочу и много и быстро сразу. Давайте делать многопроцессорные системы, и давайте делать быстрые процессоры. Ни про что не забывая. Ну вот тут-то опять пора вспомнить про сбалансированность. Если у нас есть 4 процессора, а коридор из памяти к ним (шина, естественно) позволяет только один из них на полную мощь питать, то другие три будут ждать освобождения этого коридора, какими бы быстрыми они не были. Что будет, если четырехрядное шоссе направить через однорядный переулок? Правильно: пробка! Вариант обратный: коридор широкий, процессоры слабенькие - еле жуют. На шине данные давно есть, а процессоры их потребить не могут. Отсюда вывод: в компьютере все должно быть красиво, и CPU, и шина, и память, да и диски. Для ускорения доступа в память в свое время процессорный кэш изобрели - который в регистровой быстрой памяти часто используемые данные сохраняет, и тем уменьшает число обращений к более медленной оперативной памяти. Ясно, что чем больше кэш, тем более процессору безразлична узость коридора, поскольку он изолирован от жестокого мира. Но вот досада: так происходит лишь до тех пор, пока данные более-менее умещаются в кэш. А если программа линейно суммирует массив в 1 ГБ? Тут никакой кэш не поможет - тут быстрая шина необходима. Теперь еще - пусть у нас шина мощная. И пусть из памяти данные последовательно выбирает. Но у нас в многозадачной системе еще процессоры есть, которые другим делом занимаются. И им тоже нужна шина. Значит, пока она занята - они будут ждать. Как быть? Выходов два: первый - иметь несколько шин, которые не блокируют друг друга при обращении к общей оперативной памяти. Память для этого "слоеная" быть должна. Тут, правда, сложная проблема с синхронизацией данных возникает - ежели через одну шину данные читаются, а через другую - в это же время, те же самые - записываются. А второй выход - сделать такую шину, которая быстро- быстро освобождается. Как работает нормальная шина? Выставляется на нее запрос, устройство (память, например) на него отвечает, своими мозгами не слишком резво шевеля, затем шина освобождается - и другой процессор, который все это время ждал, выставляет свой, следующий запрос к памяти. А вот в Sun используется другая шина, пакетная, называется XDBus. Она делает чуть иначе. Процессор говорит: дай мне такие-то данные по таким-то адресам. Шина запрос передает, и если память (или карта ввода-вывода) на него не может ответить немедленно готовыми данными, отключается. По шине можно слать другие запросы или данные - к другим процессорам. Как только данные будут готовы, запрошенное устройство говорит шине: "готово". И в свободный интервал захватывает шину и отсылает данные к ждущему их процессору. Короче говоря, получается что по одному телефону могут говорить не два человека, а много - используя те паузы, когда кто-то замолкает для обдумывания своего ответа. Обмен происходит пакетами, максимально плотно "упакованными" во времени. Шина все время (а не эпизодически) работает на максимальной пропускной способности. То есть, если продолжить аналогию с телефоном, в проводе никогда нет молчания, хотя все время говорят разные голоса. В принципе, если взять более быструю шину, но не packed switched, то один процессор вероятно будет иметь более быстрый доступ к памяти. Но если процессоров много - начнется толчея, паузы, ожидания, и некоторые из процессоров будут простаивать, причем много дольше, чем в packed switch шине с меньшей скоростью! Есть еще одна аналогия: с поездом-экспрессом. Ему освобождают путь, притормаживая все остальные поезда. Экспресс доходит быстро, зато все остальные поезда в результате опаздывают на много часов. Неравноправие, отсутствие симметрии и сбалансированности. А теперь - о многопроцессорности. Пусть у вас идут на машине две задачи. С квантованием времени: то одна на процессоре поработает, то другая. Для интенсивных по данным задач кэш этого процессора будет часто вытряхаться: то загружая данные одной задачи, то другой. А если у вас есть два процессора, то жить как-то легче. Может хоть одна на фиксированном процессоре осядет. Да и вообще, прошло время одиночек. Теперь проблему принято решать коллективно, гуртом. Ну а уж если и в одиночку - то пусть другой процессор хоть обед для мыслителя готовит: данные там с диска или из сети подкачивает, графический интерфейс обслуживает, прерывания ловит (то есть исполняет роль "жены", несущей в семье все тяжести быта). Короче говоря, в многозадачной системе (каковой UNIX и является) лишние процессоры никогда не повредят. Правда, если у вас машина только для набивки текстов используется - то вам это не надо по определению. Впрочем, войны процессоров вас тоже тогда не касаются. Зачем вам тогда Pentium? Зачем UltraSPARC? Какая Alpha? Купите себе PC 286 (без всякого Power) и будьте счастливы. А вот если у вас машина сразу много пользователей через сеть да через мультиплексоры обслуживает - тогда дело другое. Одни что-то считают, другие свои бессмертные творения в файлы редактором набивают (ну вот как я сейчас), третьи - компилируют что-то. А уж база данных дисками ворочает - будь здоров. Тут процессоры и шины не помешают: ни числом, ни быстродействием. Есть еще одна интересная штука, которая называется размером оперативной памяти. Ясно, что если ее мало, то операционной системе придется что-то подкачивать с диска, а не из файлового кэша. Да при том еще какие-то процессы из памяти на диск в своппинг выкачивать, чтобы кому-то другому пространство в памяти освободить. Все это катастрофически замедляет работу системы. При самом быстром процессоре, ибо диск в машине - самое медленное. Так что не жалейте памяти. Но - и не покупайте чрезмерно: простаивать будет - значит деньги свои вы выбросили на ветер. Вот такие интересные цифры приведу: если 1 наносекунда (10E-9) будет рассматриваться как 1 секунда, то Чем больше памяти, тем реже нужен диск - и это драматически увеличивает быстродействие. Да, совсем забыл объяснить - почему. Потому что UNIX данные, раз считанные с диска, старается сохранить в буферах в оперативной памяти - в кэше. И не лазить за ними каждый раз на мееедлееенный диск. Следующий затык возможен в сети, когда у вас так много машин, что они дерутся между собой за единственный провод Ethernet. Кто кого перекричит. Сеть сразу переполняется. Решением тут может быть разделение машин на несколько изолированных сегментов сети, с приемлемым числом машин в каждом сегменте; или использование интеллектуальных хабов и свитчей, которые уменьшают число столкновений пакетов. Ну и напоследок про экстерьер. Монитор. Мне всегда не хватало размера монитора, поскольку я люблю обкладываться на столе бумагами, прикалывать их на стенку, и даже подставлять стулья для неуместившихся листочков. Были бы мониторы 30", 40" - я бы занял и это пространство. К счастью, Sun поставляет olvwm - virtual window manager, который нажатием пары клавиш предоставляет вам другой экран (точнее говоря, другую область рабочего поля, которое огромно и больше размера экрана монитора). Это хоть и не решает проблему размера рабочего стола, но хотя бы предоставляет их в неограниченном количестве. Слава разработчикам, экраны на рабочих станциях имеют высокое разрешение и не портят глаза. Ах да, еще диск. Не буду говорить про оптимизацию скорости доступа к нему - всякие там RAID 5 и stripes, а также зеркала, которые позволяют размалывать кувалдой один из дисков и при этом продолжать работать - нет, меня как пограммиста волнует другое: емкость. Исходные тексты всяких систем, которые у меня есть (легально, господа! - в UNIX принято раздавать тексты системных программ и утилит), занимают гигабайты и десятки гигабайт. А если их еще начать компилировать... А если еще положить тут же базу данных... Ну, вобщем, вы поняли, да?

* Сети. *

Ну что за мерзкие сети TCP/IP! Всего каких-то 32 бита на адрес - разве ж этого хватит на весь мир? Адресов уже катастрофически не хватает, NIC выдает новые номера подсетей с большим скрипом. Но я-то хотел сказать что-нибудь про физические сети.

* Языки программирования. *

* Графика. *

Уж так долго UNIX ругали за отсутствие дружеского интерфейса, как и проглядели, что он там давно уже есть (ну лет 10 точно); а вот средств, подобных shell, в других системах как-то не образовалось. Что мы имеем? Имеем мы оконную графическую систему X Window, которая (в отличие от MS Windows) может показывать картинку не на той машине, где прикладная программа эту картинку генерит. Имеем мы библиотеку для использования этого: Xlib. И на ней написанные "toolkit"ы - библиотеки функций более высокого уровня: меню, dialog boxes, scroll bars,- wid­ gets короче говоря (непереводимый фольклор - "строительные блоки графического интерфейса"). Стиль рамочек, меню итп. - не встроен в X Window, его задают toolkitы! Захочется вам сделать другую внешность - препятствий нет. Среди них находятся OpenLook и Motif - которые до недавнего времени соревновались между собой. Победил Motif - как более похожий на MS Windows. Хотя, честно признаюсь, программировать на OpenLook-овской библиотеке XView существенно проще. Зато и вещей, которые в XView хочется добавить или переделать - тоже гораздо больше. Кстати, Tk из Tcl/Tk - это тоже toolkit, имеющий внешность Motif. Зато, в отличие от Motif, в Tk все может меняться во время выполнения программы: цвета, фонты, размеры. Motif в этом смысле фиксирован. Еще имеются всяческие расширения для трехмерной графики, вроде PEX и OpenGL. OpenGL придуман фирмой Silicon Graphics, хорош, и я удивляюсь - почему он до сих пор не стал стандартом для X Window? Но и ответ, похоже, знаю: авторы просят денег за использование. В то время как X Window вплоть до всех исходных текстов доступны бесплатно. Что, правда, не означает, что их пишут в университетах голые энтузиасты. Их финансирует консорциум крупных производителей UNIX-систем. А вложение денег в университеты в USA не облагается налогами! Так что фирмы тратят деньги "дешевле", и при том результат радует глаз. Теперь для двумерной графики в UNIX появился еще и OpenStep - та самая объектно-ориентированная графическая среда, что Стив Джобс на NeXT-ах сочинил. Да, еще язык двумерной графики PostScript прочно обосновался в UNIX. Вместе с возможностью рисовать PostScript образы в окошках (а равно печатать их на принтер). Ну, multimedia и видео еще только начинают свою историю. Но и они в X Window есть.

* Системный администратор. *

UNIX справедливо ругают за сложность администрирования системы. У этого есть только одно оправдание: после недель настройки всего, что только можно (и что порой не нужно), все работает как танк. Этим приятным свойством другие системы часто не отличаются. Проблемы же системного администратра состоят, главным образом, в том, что он должен знать очень много разнородных вещей. Причем вещей "универсальных": языков для оформления чего-нибудь. Языков, а не набора меню и экранных форм. Потому главные инструменты UNIX-администратора - это текстовый редактор и толстенное справочное руководство. Вот только кое-что для администратора Solaris 2: языки и продукты. Программисту кроме того полезно знать lex и yacc - генераторы лексических и синтаксических анализаторов (для построения компиляторов). Да, еще есть масса могучих и неочевидных в управлении текстовых редакторов: emacs, TeX, vi, ed, sed. А еще он должен уметь читать без словаря англоязычную техническую документацию. Кстати, раз уж речь зашла и о программистах: как правило разработчики (особенно фанатичные) не любят ни писать комментарии, ни документацию. Следствие этого таково: проще заново написать программу, чем доделать или модифицировать чужую. Из плохо (или совсем не-) документированной программы удается надергать в лучшем случае отдельные функции. В итоге - масса программ, делающих почти одно и то же. Свалка и разношерстность растут, качество же - существенно медленнее количества. В отношении системного администратора в UNIX верна "обратная" поговорка: "Две головы хорошо, но одна - лучше". В силу того, что у сети, работающей как одна большая машина, должен быть один хозяин, который знает все тонкости. Ему же хуже: он должен так много знать и помнить. Но другим - лучше. Потому, что когда каждый начинает ставить опыты, и левая рука не знает, что делает правая нога - результаты получаются ужасающими. Мне доводилось видеть сети, которые администрировались несколькими людьми. Некоторые из них были некомпетентны. Это увеличивало работу главного администратора вдвое и втрое - ему приходилось переделывать все за криворукими. С другой стороны, один человек не может знать все. И для делания того, что он не знает - ему следует призвать помощников. Но только пусть они не делают ничего больше! Итак, в администрировании одна голова лучше - она помнит все, общую картину. Но одна голова - и хуже. В том смысле, что если один заболел, уволился, загулял - все остальные вряд ли быстро разберутся в накрученных им настройках. Поэтому мэнеджер должен требовать от администратора записывать хотя бы места, имена файлов и систем, которые он настраивал. В лучшем же случае - вел бы журнал.

Процесс написания программы

* Русские кодировки. *

Оказывается, русские программисты в России пишут на разных языках; но все они - Русский Язык. Есть масса русских кодировок, отличающихся порядком букв, то есть какой букве приписано какое числовое значение (encoding). А поддерживать приходится их все (или по крайней мере большинство), и при том - одновременно. Ну и еще упомянем мультибайтовые кодировки, где русские буквы кодируются вообще пока неизвестно как. А еще есть украинские буквы. И прочие. Это великое "разнообразие" причиняет массу неудобств. Но, господа, это Россия - что значит - широта души и абсолютный бардак. Relax and enjoy it. Раз бардак однажды начался, избавиться от него удастся не скоро.
Ну и в качестве послесловия - нажмите на эту кнопку и прочтите текст вверху экрана

Last-modified: Sat, 21 Mar 1998 12:30:03 GMT
World LibraryРеклама в библиотекеБиблиотека не предназначена для детей! Проект Либмонстра, партнеры БЦБ - Украинская цифровая библиотека и Либмонстр Россия https://database.library.by