Андрей Богатырев. Записки системщика
... Это утверждение останавливает на себе наше
внимание. На первый взгляд оно кажется ерундой.
Кажется ерундой оно и на второй взгляд. И только на
третий, пристальный и дотошный взгляд, нам начинает
мерещиться, что это - полный и окончательный бред.
---------------------------------------------------------------
© Copyright 1995 Андрей Богатырев
Андрей Богатырев (abs@openwin.msk.su)
Родился в 1965, написал это весной 1995.
http://sun.nstu.nsk.su/vendors/sun/bogat.html
---------------------------------------------------------------
Итак, настало время оглядеть тот мир, который вращается
вокруг нас, и в котором вращаемся мы. В этом мире я с 1984 года
обитаю в среде UNIX, и не жалею. Пришлось и в текстах ядра BSD
поковыряться, и в шеллах разных, да и в прикладных программах
поучаствовать. А уж администрировать и настраивать... Нет,
UNIX - это конечно не идеал и даже не подарочек. Но ведь
горизонт - это то, что отодвигается, сколько бы мы к нему ни
стремились. Так же и с идеалом...
* Операционная система. *
это не система, а скорее загрузочный монитор для программ.
Отсутствие защиты и многозадачности (или притягивание их за уши
через задний проход) не позволяют сколько-нибудь серьезно
рассматривать эту систему для индустриального применения (а не
для настольных игр). Особенно когда надо обслужить много
народу. В сети. Да еще и вирусом их файлы не поразить.
очень сложная и откровенно плохая операционная система.
Проблема в том, что ничего лучше, надежнее и отлаженнее пока не
придумали; а если и придумали, то оно еще не вышло за стены
лабораторий и из макетов. Изобретения Microsoft - новее, но не
лучше.
когда туда добавится многозадачность, наверное будет
неплохо. Но все же - это система, выросшая вокруг графического
интерфейса. Что, впрочем, не есть плохо - поскольку притянуло
за собой объектную ориентированность и средства общения
программ между собой. Проблема в том, что все это, и в более
совершенном виде, уже было к тому времени в UNIX. Проблема UNIX
- что этим мало кто пользовался. Все предпочитали ругать UNIX
за командный недружественный интерфейс, нежели пользоваться
дружественной оболочкой X Window, которая там уже давно была.
Тут можно пронаблюдать и иные интересные проблемы,
связанные как раз с открытостью. UNIX - система открытая, ее
развивает, улучшает и изучает в исходных текстах масса народу
по всему свету: система-лаборатория для всего hack
er-сообщества. Зато коммерческие поставщики UNIX для разных
платформ до недавнего времени рычали друг на друга, прятали все
свое по углам, подкладывали друг другу свинок. Как же - UNIX
UNIХом (ибо UNIX - он и в Африке... Единственная ОС,
перенесенная на десятки архитектур машин), но денежки врозь.
Тем временем на рынок вылез Microsoft, который никому ничего из
исходных текстов не показывал (то есть был и есть абсолютно
закрыт), ни с кем кроме себя не соревновался, и слепил soft
ware, которым сразу стали пользоваться миллионы. Да, никто не
говорит, что он сделал самое лучшее (или худшее), но самое
массовое - несомненно. И тут - увы UNIХам. Раньше UNIХисты
свысока смотрели на недосистему MS DOS и почивали на лаврах.
Теперь...
Зато это сыграло положительную роль - и еще не слишком
поздно - UNIX-производители перестали рычать друг на друга
злобно, а ослабили тон до "настороженно". И пришлось им всем
вместе думать о том, как лучшую операционную систему (да еще и
уже существующую, и давно) еще и в люди вытолкнуть. Такие
пироги. Монстры против выскочки Microsoft-а.
ее почему-то именуют "сетевой операционной системой", да
какая ж она операционная система? DOS через сеть - система
перекачки файлов в локальной (и только) сети. Несерьезно,
господа. Вы somputer science изучали? Что такое ОС знаете? Ну и
где она? Ну ладно, ладно, пусть даже операционная система. Но
не для работающего на машине человека. Для выделенного
сервера. А потому - не "сетевая операционная система", а
"система для сети". Сетевая - это когда операционная система (в
том числе) через сеть работает, ресурсы раздает.
Да, еще очень меня раздражает когда Писюк в Novell-овской
сети "рабочей станцией" величают. Смешно. Забыли, что такое
рабочая станция - а ведь десять лет назад это лучше знали.
Когда через десять лет понятию дают выхолощенное значение - это
удручает.
окстись, это тоже UNIX! Да, но что-то он как-то уж
графический и объектно-ориентированный какой-то больно. Mi
crosoft-у такое и не снилось... Да-да, а теперь эта объектно-
ориентированная графика перекочевала в UNIX - под названием
OpenStep. Вот, в Solaris, например.
"а это что за зверь такой?", - спросит подавляющее
большинство. А это такая распределенная
объектно-ориентированная операционная система от SunSoft. Вот
все кричат "микроядра", а кто их силу реально
использует? OSF/1 над MACH построенная? Нет. А вот Spring -
использует, просто для того и делался. А на что похожа? А ни на
что. Вот например: процесс в ней может иметь часть памяти на
одной машине, часть - на другой. Где надо и где удобнее - там и
будет иметь. А кто ее видел? А работает она в лабораториях Sun
Soft! Как готовая полноценная система, в частности цикл ее
разработки ведется под нею самой, без привлечения UNIХа. А
приложения под нее есть? А нету... Эта система, вероятно, не
будет коммерческой. Зато послужит прототипом операционной
системе 21 века. Должен же быть последователь у UNIХа. Кстати,
UNIХный интерфейс к Spring пишут русские программисты.
снова UNIX. Чего тут теперь только нет! И не по
знаменитому принципу "и того нет, и этого нет". Иначе.
- MS Windows есть, WABI (Windows Application Binary In
terface) называется. Собственно, под ним я эту статью и пишу,
на SPARCstation 20 под Solaris 2.4 сидючи.
- Macintosh OS7 есть, называется MAE (Macintosh Application
Environment).
- NeXTstep есть.
- NetWare есть, в виде поддержки протоколов IPX/SPX.
- И вообще чего у вас нет, то у нас есть. Вот загадка
для знатоков: верно ли обратное?
Вообще, на 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 секунда, то
- доступ в кэш процессора займет 20 секунд.
- доступ к основной оперативной памяти через шину - 3 минуты 20 секунд.
- доступ к диску... 7 месяцев.
Чем больше памяти, тем реже нужен диск - и это
драматически увеличивает быстродействие. Да, совсем забыл
объяснить - почему. Потому что UNIX данные, раз считанные с
диска, старается сохранить в буферах в оперативной памяти - в
кэше. И не лазить за ними каждый раз на мееедлееенный диск.
Следующий затык возможен в сети, когда у вас так много
машин, что они дерутся между собой за единственный провод
Ethernet. Кто кого перекричит. Сеть сразу переполняется.
Решением тут может быть разделение машин на несколько
изолированных сегментов сети, с приемлемым числом машин в
каждом сегменте; или использование интеллектуальных хабов и
свитчей, которые уменьшают число столкновений пакетов.
Ну и напоследок про экстерьер. Монитор. Мне всегда не
хватало размера монитора, поскольку я люблю обкладываться на
столе бумагами, прикалывать их на стенку, и даже подставлять
стулья для неуместившихся листочков. Были бы мониторы 30", 40"
- я бы занял и это пространство. К счастью, Sun поставляет
olvwm - virtual window manager, который нажатием пары клавиш
предоставляет вам другой экран (точнее говоря, другую область
рабочего поля, которое огромно и больше размера экрана
монитора). Это хоть и не решает проблему размера рабочего
стола, но хотя бы предоставляет их в неограниченном количестве.
Слава разработчикам, экраны на рабочих станциях имеют высокое
разрешение и не портят глаза.
Ах да, еще диск. Не буду говорить про оптимизацию скорости
доступа к нему - всякие там RAID 5 и stripes, а также зеркала,
которые позволяют размалывать кувалдой один из дисков и при
этом продолжать работать - нет, меня как пограммиста волнует
другое: емкость. Исходные тексты всяких систем, которые у меня
есть (легально, господа! - в UNIX принято раздавать тексты
системных программ и утилит), занимают гигабайты и десятки
гигабайт. А если их еще начать компилировать... А если еще
положить тут же базу данных... Ну, вобщем, вы поняли, да?
Ну что за мерзкие сети TCP/IP! Всего каких-то 32 бита на
адрес - разве ж этого хватит на весь мир? Адресов уже
катастрофически не хватает, NIC выдает новые номера подсетей с
большим скрипом.
Но я-то хотел сказать что-нибудь про физические сети.
- Тонкий Ethernet - все хорошо, пока у
вас не пропадает контакт хоть на одном BNC-разъеме. После этого
вся сеть перестает работать, и вас осаждают нервные
пользователи. А вы неприкаянно бродите и проверяете все
соединения.
- Витая пара - описанная ситуация в
принципе невозможна: если что-то дохнет, то только один провод
от машины к хабу. Все остальные продолжают работать. Зато нужен
надежный хаб, потому что может зависнуть и он. Ethernet на
витой паре существует для 10 и 100 МегаБит в секунду, второй из
них требует проводов повышенного качества, так что не
экономьте центы! Кроме того, не заблуждайтесь, что 10 Мбит/сек.
- это много. При пересчете в байты - это 1 МБайт/сек. При учете
заголовков пакетов и столкновений плучится 300-450 КБайт/сек. В
лучшем случае.
- Фибероптика - самое надежное и
быстрое. Вам случалось видеть, как после дождя падает качество
связи на телефонных линиях (а следовательно на модемах)? Мне -
да. И так - с любым металлическим проводом. А с оптическим - не
так, ему хоть в речке лежи. Да, самое надежное решение (если,
конечно, танком не переедут), но зато и самое дорогое.
Существенно дороже прочих.
* Языки программирования. *
- BASIC - Васик. Не язык. Человек,
начавший изучать программирование с этого с позволения сказать
языка, навеки останется нравственным и интеллектуальным уродом.
- C - язык для меня родной, хотя и не
первый. Не буду я рассуждать ни о его достоинствах, ни о
недостатках. Язык рабочий - на нем вполне можно писать и писать
эффективно. Как на ассемблере.
- C++ - немало дней, ночей и месяцев
было посвящено этому языку. Впечатления? Монстрик. Не монстр,
как Ada, или того лучше PL/I, но все же монстрик. Программисту
помнить надо не только классы и методы, но и множество разных
правил самого языка. Недаром его автор - Страустрап - так
неохотно рассматривает расширения языка. Он и так уже
неизящный. Однако в меру строгий к ошибкам, чего
объектно-ориентированные языки с динамическим связыванием не
дают (но от этой же строгости - его сложность).
- Smalltalk - единственный
абсолютно объектно-ориентированный язык. Даже буквы и
числа в нем - объекты, не говоря уж о том, что и исходный текст
программы и ее скомпилированный код - объекты тоже. Увы,
Smalltalk - это интерпретатор, хотя и очень совершенный,
быстрый и эффективный. К нему можно добавить новые примитивы,
написанные, скажем, на Си, но его невозможно (да и не нужно)
выполнить непосредственно на процессоре. Скомпилированный код -
это специальные "байткоды" для интерпретатора. В частности
поэтому нельзя использовать Smalltalk из Си. Зато это дает
абсолютную переносимость его скомпилированного в байткоды
образа без изменений на любую машину.
В прежние годы Smalltalk был просто операционной системой,
а также замкнутой средой разработки на машинах фирмы XEROX.
Сегодня он стал равноправным членом зоопарка языков и сред,
расплодившихся (к примеру) под UNIX.
Главное же достоинство пожалуй таково: язык очень прост.
На изучение достаточно получаса.
За что я не люблю
Объектно-Ориентированное Программирование: за огромное число
классов и методов, которые хотя и схожи по интерфейсу, который
наследуют друг у друга, но по площади своей "поверхности" не
укладываются в мою, человеческую, память... Впрочем, я никогда
не писал на нем всерьез (а это теперь стало возможным - писать
на нем серьезные вещи, а не игрушечные).
Так что, если б не было Objective-C и написанного на нем
{Open,NeXT}step - я бы выбрал Smalltalk.
- Objective-C - гибрид чистого Си и
Smalltalk-а. Фактически только одна новая конструкция - посылка
сообщения:
ответ = [кому селектор аргументы];
Но связывание метода с вызовом - чисто динамическое (для
любителей C++ поясняю: все функции
виртуальные). Что не позволяет ловить массу ошибок во время
компиляции. Зато язык прост и строен. В меру даже изящен.
Короче, это - мой любимый язык.
- Pascal - в общем весьма неплохой
язык, особенно потоптанный фирмой Borland. Поддерживает
вложенные процедуры и динамически отводимые массивы, чем в Си и
не пахнет (массивами - пахнет, при помощи allo
ca. Но неизящно). Недостаток ровно один: очень уж
многословный язык - то и дело пиши длинные слова begin, end...
Вместо лаконичных { и }. Другой недостаток не имманентный: все
же больше всяких библиотек на Си написано. И для Си.
- Modula - лишена многих недостатков
Pascal и обладает многими достоинствами Си. Хороший язык, но
кто на нем пишет?
- Ada - язык с претензиями, но похоже
мертворожденный. Излишняя сложность программиста удручает, и он
выбирает другой язык.
- FORTRAN-77, PL/I - языки для физиков,
да и то вымирающие. Не люблю. Некрасиво, очень уж машиной фон
Неймана отдает, да еще и препарированной.
- COBOL - по иронии судьбы - первый
язык, который я пытался выучить, один из старейших практических
языков. Монстр. Но без претензий. Россию миновала (практически)
участь познакомиться с этим языком. И возблагодарим за это
Господа.
- FORTRAN-90 - не знаю, что будет, если
к телеге привинтить крылья и реактивный двигатель, но...
надеюсь, что все же полетит. Впрочем, я рассматривал бы
прогрессивным такой процесс изменения языка, в котором прежде
всего не добавляются новые могучие возможности, а избавляются
от идиотизма старого (не внося при этом новых удачных
ухудшений).
- LISP - идея, конечно, интересная...
Но уж больно много скобок. Да и образ мышления нужен другой:
списочно-линейный. Из головы и хвоста - без тела. А еще надо
уметь лямбда-выражаться. Непривычно.
- Scheme - более мощное развитие LISP.
Непривычно, но сильно.
- Prolog - тоже непривычно, хотя
по-другому. Но еще мощнее и еще интереснее. Фон Нейман с его
машиной спрятался куда-то. Это тот язык, на который я согласен
потратить время. Хотя бы потому, что сам научусь мыслить
логичнее. Эффективность? Особенно интересно будет, когда ветви
логического вывода будут обрабатываться параллельно на многих
процессорах. Но пока я не увижу такого продукта на своем столе,
я не буду говорить о его индустриальном использовании. Хотя,
знаю я и про такое.
- VisualBasic и Tcl/Tk
- да, и такие странные языки появились. Языки для
программирования интерактивного графического интерфейса. Tcl/Tk
- это примочка для UNIX. Это интерпретативный язык, не
требующий компиляции. Имеет два ценных свойства: может
встраиваться в Си программы, а еще - имеет встроенный механизм
общения с другими процессами, на Tcl же написанными.
- Ассемблер - не рассматривается как
кандидат для решения сколь-нибудь сложных задач. Я хочу думать
о том, что мне надо спрограммировать, а не как
побороть аппаратуру компьютера. Кроме того, использование
ассемблера в любой части проекта тут же намертво привязывает
весь проект к конкретному типу машины. Ассемблер остется для
разработчиков компиляторов, оптимизированных библиотек, да для
той братии, которая как раз и борется с железом по долгу
службы: для системных программистов, пищущих машинно-зависимую
часть ядра ОС. Но я им не завидую: труд их тяжек, но не живет
дольше конкретной ОС и конкретной машины.
- Резюме: языков много, единого нет,
самого хорошего нет. В стремлении сделать более хороший язык,
кто-то сочиняет еще один - и свалка увеличивается. Сказать же,
что для каждой задачи необходим свой, специализированный, язык,
лучше всего отражающий чаяния данной конкретной задачи, я тоже
не могу: будет Вавилонское столпотворение. Даже при наличии
переводчиков. Но и единый язык, явно, не родится. Хотя бы
потому, что у программирования не одна парадигма (ну к примеру
- фон Нейман и логическое программирование). Мы учим
английский, но предпочитаем трепаться между собой по-русски. А
французы - по-французски. А уж японцы-то и вовсе... А резюме
все же такое: плохую программу можно написать на любом
языке.
Уж так долго 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: языки и продукты.
- shell - язык программирования
комндных файлов произвольной сложности, впрочем их гораздо
больше: sh,
csh,
ksh,
jsh,
vcsh,
tcsh,
bash,
wish.
Шеллы - одно из главных средств склеивать друг с другом
разномастные программы, говорящие чаще всего на разных языках;
- Си - язык, на котором написана
операционная система. Имея компилятор и описание библиотек
(которые в UNIX есть всегда) можно сделать все;
- perl, awk,
sed - языки программирования обработки данных,
"переводчики" с языка на язык;
- make - система автоматического
построения больших проектов по описанию; Туда же
imake - препроцессор к make;
- nroff, tbl,
eqn, pic - языки описания
форматирования текстов;
- HTML - язык для форматирования
гипертекстов в Mosaic;
- NIS+, DNS -
всяческие сетевые информационные сервисы. Нетривиальный язык
(формат) описания таблиц и куча команд.
- TCP/IP routing - это на самом деле
предшествует DNS;
- OnLine DiskSuite - система
зеркалирования дисков. Тоже масса команд;
- NetWorker - система бэкапирования на
магнитные ленты;
- sendmail - маршрутизатор электронной
почты. Язык;
- SunNet Manager - система управления
сетью;
- SecureRPC, NFS,
automounter - всяческие штуки для сетевых
файловых систем;
- UUCP - чтобы настроить этот "UNIX-
UNIX copy" надо уметь биться с модемом и писать загадочные
скрипты;
Программисту кроме того полезно знать lex
и yacc - генераторы лексических и
синтаксических анализаторов (для построения компиляторов).
Да, еще есть масса могучих и неочевидных в управлении
текстовых редакторов:
emacs,
TeX,
vi,
ed,
sed.
А еще он должен уметь читать без словаря англоязычную
техническую документацию.
Кстати, раз уж речь зашла и о программистах: как правило
разработчики (особенно фанатичные) не любят ни писать
комментарии, ни документацию. Следствие этого таково: проще
заново написать программу, чем доделать или модифицировать
чужую. Из плохо (или совсем не-) документированной программы
удается надергать в лучшем случае отдельные функции. В итоге -
масса программ, делающих почти одно и то же. Свалка и
разношерстность растут, качество же - существенно медленнее
количества.
В отношении системного администратора в UNIX верна
"обратная" поговорка: "Две головы хорошо, но одна - лучше". В
силу того, что у сети, работающей как одна большая машина,
должен быть один хозяин, который знает
все тонкости. Ему же хуже: он должен так
много знать и помнить. Но другим - лучше. Потому, что когда
каждый начинает ставить опыты, и левая рука не знает, что
делает правая нога - результаты получаются ужасающими. Мне
доводилось видеть сети, которые администрировались несколькими
людьми. Некоторые из них были некомпетентны. Это увеличивало
работу главного администратора вдвое и втрое - ему приходилось
переделывать все за криворукими. С другой стороны, один человек
не может знать все. И для делания того, что он не знает - ему
следует призвать помощников. Но только пусть они не делают
ничего больше!
Итак, в администрировании одна голова лучше - она помнит
все, общую картину. Но одна голова - и хуже. В том смысле, что
если один заболел, уволился, загулял - все остальные вряд ли
быстро разберутся в накрученных им настройках. Поэтому мэнеджер
должен требовать от администратора записывать
хотя бы места, имена файлов и систем, которые
он настраивал. В лучшем же случае - вел бы журнал.
Процесс написания программы
- Достижение результата: "Я это могу" и "Это в принципе
возможно и мне по силам". Пишется черновик, прототип
программы. Главным здесь является новизна и получение
уверенности в своих силах. Плохой программист на этом и
останавливается, сотворив новую и плохую программу, которая НЕ
делает того, что могла бы, и оттого еще обиднее.
- После того, как результат в ПРИНЦИПЕ получен, думаешь
"а как это надо сделать ПРАВИЛЬНО?" И вот теперь, привлекая
весь прежний опыт, в программе пере- и до- писывается до 80%
мест. Порой (и не так уж редко) переписывается ВСЯ
программа-прототип.
- Доводка. Приведение к "почти идеалу". Идеал
недостижим, ибо запросы со временем растут, изменяются, и
исходят из уже достигнутого; а опыт (сын ошибок трудных) тоже
растет и подает новые идеи. Посему процесс улучшения не имеет
конца. Но первое приближение к идеалу достижимо: мы дописываем
к программе не только то, чего "я хочу, сейчас", но и то, чего
"я мог бы в принципе захотеть" - и делаем это заранее.
Заранее, чтобы ПОТОМ об этом не заботиться, а если уж и
припрет, то иметь уже наметки: как это сделать, не с нуля.
Заранее сделанное позволяет нам облегчить жизнь в будущем и
отвязаться от этой программы, забыть про нее.
- Не так ли и в обычной человеческой жизни?
Оказывается, русские программисты в России пишут на разных языках; но все они -
Русский Язык. Есть масса русских кодировок, отличающихся порядком букв, то
есть какой букве приписано какое числовое значение (encoding).
- КОИ-8 - исторически принятая на
русских UNIX системах - самая ранняя из появившихся
восьмибитных кодировок. Отличается тем свойством, что если у
нее обрезан восьмой бит:
c & 0177
то она все же читаема с терминала как транслитерация
латинских букв. Именно этой кодировкой пользуется автор этой
статьи (как и большинство UNIX-sites сети RelCom). Имеет то
неприятное свойство, что буквы в ней идут не в алфавитном
порядке.
- ISO 8859/5 - это американский
стандарт на русскую кодировку. А русские программисты к ее
разработке не имеют никакого отношения. Ею пользуется
большинство коммерческих баз данных.
- Microsoft 1251 - это та кодировка,
которой пользуется Microsoft Windows. Возможно, что
именно к этой кодировке придут и UNIX системы.
- Альтернативная кодировка для MS DOS -
русская кодировка с псевдографикой, использовавшаяся в MS DOS,
и в силу этого оказавшаяся достаточно распространенной (в
России все плохое распространяется широко).
- Кодировка для Macintosh - тоже
особенная.
А поддерживать приходится их все (или по крайней мере
большинство), и при том - одновременно.
Ну и еще упомянем мультибайтовые кодировки, где русские
буквы кодируются вообще пока неизвестно как. А еще есть
украинские буквы. И прочие.
Это великое "разнообразие" причиняет массу неудобств. Но,
господа, это Россия - что значит - широта души и абсолютный
бардак.
Relax and enjoy it. Раз бардак однажды начался,
избавиться от него удастся не скоро.
---------------------------------------------------------------
Ну и в качестве послесловия - нажмите на эту кнопку и
прочтите текст вверху экрана
Last-modified: Sat, 21 Mar 1998 12:30:03 GMT