Чем больше памяти, тем реже нужен диск - и это драматически увеличивает быстродействие. Да, совсем забыл объяснить - почему. Потому что 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. Раз бардак однажды начался, избавиться от него удастся не скоро.