| Записки системщика. |
... Это утверждение останавливает на себе наше внимание. На
первый взгляд оно кажется ерундой. Кажется ерундой оно и на
второй взгляд. И только на третий, пристальный и дотошный взгляд,
нам начинает мерещиться, что это - полный и окончательный бред.
Итак, настало время оглядеть тот мир, который вращается
вокруг нас, и в котором вращаемся мы.
Мне, как программисту, по большому счёту безразлично -
какая платформа. Моё дело - язык Си, да то, чтобы то, что описано
в документации, работало именно так, как оно описано, а не как
Бог на душу положит. Работало так, чтобы я мог программировать
то, что хочу я, а не получать неожиданные сюрпризы. Чтобы оно
мне помогало, а не заставляло превратиться в мастера лавировки и
извращений. Работало правильно, в меру быстро и надёжно. Ну и
удобно, конечно же, не люблю я писать заклинания да ещё в
десятке мест сразу. Помнить все эти места очень лениво.
MS DOS
* BASIC - Васик. Не язык. Человек, начавший изучать
программирование с этого с позволения сказать языка, навеки
останется нравственным и интеллектуальным уродом.
* Достижение результата: "Я это могу" и "Это в принципе
возможно и мне по силам". Пишется черновик, прототип программы.
Главным здесь является новизна и получение уверенности в своих
силах. Плохой программист на этом и останавливается, сотворив
новую и плохую программу, которая НЕ делает того, что могла бы,
и оттого ещё обиднее.
Ну что за мерзкие сети TCP/IP! Всего каких-то 32 бита на
адрес - разве ж этого хватит на весь мир? Адресов уже
катастрофически не хватает, NIC выдаёт новые номера подсетей с большим
скрипом.
UNIX справедливо ругают за сложность администрирования
системы. У этого есть только одно оправдание: после недель
настройки всего, что только можно (и что порой не нужно), всё работает
как танк. Этим приятным свойством другие системы часто не отличаются.
Короче говоря, машина должна не мешать мне программировать.
А это больше всего связано с качеством ОС.
Самое главное, зачем собственно программы, операционные
системы и разный инструментарий написаны - это чтобы я мог как
можно проще и легче получить результат, сделать то, что мне
нужно (или просто хочется: "хочу" - есть двигатель развития).
Я видел массу "глюков" в ранних Solaris-ах. С прискорбием
должен сообщить, что их количество (а главное: убойная сила) в
версии 2.4 упало на порядок. Работает уже не "сносно", а
"хорошо". Этот путь и HP UX 10, и DEC, и Microsoft с его Windows NT
ещё должны пройти.
Вообще, сейчас есть две противопоставляемые тенденции
насчёт увеличения скорости работы машин. Одна - это ускорение
процессора. Всё мило, пока у вас процессор не начинает обгонять все
остальные части компьютера настолько, что быстрый процессор
вынужден долго-долго ждать, к примеру, системной шины, которая ему
подаёт данные из памяти. Называется такая весёлая ситуация
несбалансированностью машины. Вторая тенденция - клепать
многопроцессорные машины с не обязательно сверхбыстрыми процессорами.
Мол, распараллелим вычисления, так N мужиков за 1 час сделают то
же самое, что сделает за один час один мужик, способный один
работать за N человек. Идея в меру здравая, кроме одного тонкого
момента: не все задачи поддаются распараллеливанию; а того хуже
- сейчас параллельно написанных программ маловато. Значит,
работать надо, писать их, да старые переписывать. Но на это ж масса
денег, людей и времени нужна!
Всё прекрасно, только я хочу и много и быстро сразу. Давайте делать многопроцессорные системы, и давайте делать быстрые
процессоры. Ни про что не забывая.
Ну вот тут-то опять пора вспомнить про сбалансированность.
Если у нас есть 4 процессора, а коридор из памяти к ним (шина,
естественно) позволяет только один из них на полную мощь питать,
то другие три будут ждать освобождения этого коридора, какими бы
быстрыми они не были. Что будет, если четырёхрядное шоссе
направить через однорядный переулок? Правильно: пробка!
Вариант обратный: коридор широкий, процессоры слабенькие -
еле жуют. На шине данные давно есть, а процессоры их потребить
не могут. Отсюда вывод: в компьютере всё должно быть красиво, и
CPU, и шина, и память, да и диски.
Для ускорения доступа в память в своё время процессорный
кэш изобрели - который в регистровой быстрой памяти часто
используемые данные сохраняет, и тем уменьшает число обращений к
более медленной оперативной памяти. Ясно, что чем больше кэш,
тем более процессору безразлична узость коридора, поскольку он
изолирован от жестокого мира. Но вот досада: так происходит лишь
до тех пор, пока данные более-менее умещаются в кэш. А если
программа линейно суммирует массив в 1 ГБ? Тут никакой кэш не
поможет - тут быстрая шина необходима.
Теперь ещё - пусть у нас шина мощная. И пусть из памяти
данные последовательно выбирает. Но у нас в многозадачной
системе ещё процессоры есть, которые другим делом занимаются. И им
тоже нужна шина. Значит, пока она занята - они будут ждать. Как
быть?
Выходов два: первый - иметь несколько шин, которые не
блокируют друг друга при обращении к общей оперативной памяти. Па-
мять для этого должна быть "слоёная". Тут, правда, сложная
проблема с синхронизацией данных возникает: ежели через одну шину
данные читаются, а через другую - в это же время, те же самые -
записываются. А второй выход - сделать такую шину, которая
быстро- быстро освобождается.
Как работает нормальная шина? Выставляется на неё запрос,
устройство (память, например) на него отвечает, своими мозгами
не слишком резво шевеля, затем шина освобождается - и другой
процессор, который всё это время ждал, выставляет свой,
следующий запрос к памяти. А вот в Sun используется другая шина,
пакетная, называется XDBus. Она делает чуть иначе. Процессор говорит:
дай мне такие-то данные по таким-то адресам. Шина запрос
передаёт, и если память (или карта ввода-вывода) на него не
может ответить немедленно готовыми данными, отключается. По шине
можно слать другие запросы или данные - к другим процессорам.
Как только данные будут готовы, запрошенное устройство говорит
шине: "готово". И в свободный интервал захватывает шину и
отсылает данные к ждущему их процессору. Короче говоря, получается
что по одному телефону могут говорить не два человека, а много -
используя те паузы, когда кто-то замолкает для обдумывания
своего ответа. Обмен происходит пакетами, максимально плотно
"упакованными" во времени. Шина всё время (а не эпизодически)
работает на максимальной пропускной способности. То есть, если
продолжить аналогию с телефоном, в проводе никогда нет молчания,
хотя всё время говорят разные голоса. В принципе, если взять
более быструю шину, но не packed switched, то один процессор
вероятно будет иметь более быстрый доступ к памяти. Но если
процессоров много - начнётся толчея, паузы, ожидания, и некоторые из
процессоров будут простаивать, причём много дольше, чем в packed
switch шине с меньшей скоростью!
Есть ещё одна аналогия: с поездом-экспрессом. Ему
освобождают путь, притормаживая все остальные поезда. Экспресс доходит
быстро, зато все остальные поезда в результате опаздывают на
много часов. Неравноправие, отсутствие симметрии и сбалансированности.
Следующим шагом является бесшинная архитектура, использование
коммутатора. Шину можно представить как ящик с N входами,
где в каждый момент времени могут быть соединены между собой два
входа. Остальные вынуждены ждать. Точнее так: они тоже слышат
разговор двух соединённых входов, но игнорируют его, поскольку
адрес, запрошенный в этом соединении, к ним не относится. Пусть
у нас, однако, есть хотя бы два процессора, память и контроллер
дисков. Четыре входа. Почему бы не позволить одному процессору
общаться с памятью, а второму одновременно в это время же не
работать с контроллером? Такая схема, где у ящика с N входами
может быть N/2 попарных независимых одновременных соединений,
носит название "switch" или "коммутатор". Для многопроцессорных
машин это ещё более эффективное решение, чем даже "packed
switched bus". В аналогии с железной дорогой - это железнодорожное
полотно с N/2 параллельными путями.
А теперь - о многопроцессорности. Пусть у вас идут на машине д
ве задачи. С квантованием времени: то одна на процессоре
поработает, то другая. Для интенсивных по данным задач кэш этого
процессора будет часто вытряхаться: то загружая данные одной
задачи, то другой. А если у вас есть два процессора, то жить
как-то легче. Может хоть одна осядет на фиксированном процессоре.
Да и вообще, прошло время одиночек. Теперь проблему принято
решать коллективно, гуртом. Ну а уж если и в одиночку - то пусть
другой процессор хоть обед для мыслителя готовит: данные там с
диска или из сети подкачивает, графический интерфейс обслуживает,
прерывания ловит (то есть исполняет роль "жены", несущей в
семье все тяжести быта). Короче говоря, в многозадачной системе
(каковой 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 принято раздавать тексты системных
программ и утилит), занимают гигабайты и десятки гигабайт.
А если их ещё начать компилировать... А если ещё положить тут же
базу данных... Результат превзойдёт самые смелые ожидания :-)
это не система, а скорее загрузочный монитор для программ.
Отсутствие защиты и многозадачности (или притягивание их за уши
через задний проход) не позволяют сколько-нибудь серьёзно
рассматривать эту систему для индустриального применения (а не для
настольных игр). Особенно когда надо обслужить много народу. В
сети. Да ещё и вирусом их файлы не поразить.
UNIX
очень сложная и откровенно плохая операционная система.
Проблема в том, что ничего лучше, надёжнее и отлаженнее пока не
придумали; а если и придумали, то оно ещё не вышло за стены
лабораторий и из макетов. Изобретения Microsoft - новее, но не
лучше.
MS Windows
когда туда добавится многозадачность, наверное будет
неплохо. Но всё же - это система, выросшая вокруг графического
интерфейса. Что, впрочем, не есть плохо - поскольку притянуло за
собой объектную ориентированность и средства общения программ
между собой. Проблема в том, что всё это, и в более совершенном
виде, уже было к тому времени в UNIX. Проблема UNIX - что этим
мало кто пользовался. Все предпочитали ругать UNIX за командный
недружественный интерфейс, нежели пользоваться дружественной
оболочкой X Window, которая там уже давно была.
Тут можно пронаблюдать и иные интересные
проблемы, связанные как раз с открытостью. UNIX -
система открытая, её развивает, улучшает и изучает в исходных
текстах масса народу по всему
свету: система-лаборатория для всего hacker-сообщества. Зато
коммерческие поставщики UNIX для разных платформ до недавнего
времени рычали друг на друга, прятали всё своё по углам,
подкладывали друг другу свинок. Как же - UNIX UNIXом (ибо UNIX - он и
в Африке... Единственная ОС, перенесённая на десятки архитектур
машин), но денежки врозь. Тем временем на рынок вылез Microsoft,
который никому ничего из исходных текстов не показывал (то есть
был и есть абсолютно закрыт), ни с кем кроме себя не соревновался,
и слепил software, которым сразу стали пользоваться миллионы.
Да, никто не говорит, что он сделал самое лучшее (или худшее),
но самое массовое - несомненно. И тут - увы UNIXам. Раньше
UNIXисты свысока смотрели на недосистему MS DOS и почивали на
лаврах. Теперь...
Зато это сыграло положительную роль - и ещё не слишком
поздно - UNIX-производители перестали рычать друг на друга злобно,
а ослабили тон до "насторожённо". И пришлось им всем вместе думать
о том, как лучшую операционную систему (да ещё и уже существующую,
и давно) ещё и в люди вытолкнуть. Такие пироги. Монстры
против выскочки Microsoft-а.
NetWare
её почему-то именуют "сетевой операционной системой", да
какая ж она операционная система? DOS через сеть - система
перекачки файлов в локальной (и только) сети. Несерьёзно, господа.
Вы somputer science изучали? Что такое ОС знаете? Ну и где она?
Ну ладно, ладно, пусть даже операционная система. Но не для
работающего на машине человека. Для выделенного сервера. А потому
- не "сетевая операционная система", а "система для сети".
Сетевая - это когда операционная система (в том числе) через сеть
работает, ресурсы раздаёт.
Да, ещё очень меня раздражает когда Писюк в Novell-овской
сети "рабочей станцией" величают. Смешно. Забыли, что такое
рабочая станция - а ведь десять лет назад это лучше знали. Когда
через десять лет понятию дают выхолощенное значение - это удручает.
В понимании NetWare любая рабочая станция в UNIXной сети -
это сервер, поскольку она в состоянии предоставлять всем другим
свои файлы с локальных дисков, отображать окна с других машин
(вот то, что есть в оконной системе X Window и нигде больше),
итп. При этом она одновременно является рабочим местом человека
(вот что даёт многозадачность+многопользовательность).
Что же такое сервер в понимании UNIX? Машина, специально
соптимизированная для обслуживания большого числа клиентских
машин. Заметьте - машина! Операционная же система на рабочих
машинах ("рабочих станциях" - отличает их как правило просто большой
экран) и серверах (которые преимущественно многопроцессорные и
держат много дисков) одна и та же.
NeXTstep
окстись, это тоже UNIX! Да, но что-то
он как-то уж графический и объектно-ориентированный какой-то больно.
Microsoft-у
такое и не снилось... Да-да, а теперь эта объектно- ориентиро-
ванная графика перекочевала в UNIX - под названием OpenStep.
Вот, в Solaris, например.
Spring
"а это что за зверь такой?", - спросит подавляющее большинство.
А это такая распределённая объектно-ориентированная
операционная система от SunSoft. Вот все кричат "микроядра", а кто их
силу реально использует? OSF/1 над MACH построенная? Нет. А вот
Spring - использует, просто для того и делался. А на что похожа?
А ни на что. Вот например: процесс в ней может иметь часть памяти
на одной машине, часть - на другой. Где надо и где удобнее -
там и будет иметь. А кто её видел? А работает она в лабораториях
SunSoft! Как готовая полноценная система, в частности цикл её
разработки ведётся под нею самой, без привлечения UNIXа. А
приложения под неё есть? А нету... Эта система, вероятно, не будет
коммерческой. Зато послужит прототипом операционной системе 21
века. Должен же быть последователь у UNIXа. Кстати, UNIXный
интерфейс к Spring пишут русские программисты.
UNIX
снова UNIX. Чего тут теперь только нет! И не по знаменитому
принципу "и того нет, и этого нет". Иначе.
* MS Windows есть, WABI (Windows Application Binary
Interface) называется. Собственно, под ним я эту статью и пишу,
на SPARCstation 20 под Solaris 2.4 сидючи.
есть, называется MAE (Macintosh Application
Environment).
* И вообще чего у вас нет, то у нас есть. Вот загадка для
знатоков: верно ли обратное?
Вообще, на UNIX посмотришь: свалка-свалкой. Вот что значит
- открытая система. Что хотят, то и добавляют. Экспериментальный
полигон какой-то, а не операционная среда. Да ещё с богатым
арсеналом средств для связывания воедино несовместимых между собой
вещей - вивисекция сплошная. Вот одно только неприятное для
авторов всех других систем свойство имеется: стандарт на UNIX.
SVR4 называется. А ни на что другое стандарта пока нет, в том
числе на горячо любимый MS Windows API. Так что в UNIX народ
побалует-побалует, эксперимент поставит, что-нибудь новое
изобретёт (как в своё время TCP/IP тут отладили), да потом - бац! - и
стандарт на это примет. А все остальные - догоняй.
Windows-95, Windows/NT, OS/2
меня забавляют, но и заставляют кривиться громкие заявления
производителей НОВЫХ операционных систем о том, что вот, они
добавили новую выдающуюся возможность - вроде кэширования файлов в
памяти или оптимизации размещения файлов на диске - которая
сделала их систему непревзойдённой. Ребята, в UNIX я об этих самых
возможностях слышал минимум 6 лет назад. И печально видеть
развешивающих ушки чайников, и вправду считающих это изобретением
их любимой фирмы, откровением и новинкой, оставляющей далеко
позади всех неизвестных им конкурентов. Незнание и невежество даёт
повод для чванства.
Жаль то, что реально новых идей - а не позаимствованных
друг у друга - немного. Например, объектность в ОС. Новые идеи к
тому же долго мусолятся, испытываются на прочность, разные
реализации одного и того же превращаются в войну авторов реализаций.
Обнадёживает во всём этом процессе одно: рано или поздно
полезное приживается, нежизнеспособные побрякухи отмирают и
отваливаются, и начинает пахнуть стандартом (что не означает
окончание процесса развития и улучшений); а также то, что рано или
поздно все базовые вещи сольются воедино. Различие и многообразие
наблюдается только на переднем фронте исследований: молотки
и вилки должны быть привычны и единообразны, иначе мы не сможем
удобно и привычно пользоваться ими повседневно.
* C - язык для меня родной, хотя и не первый. Не буду я
рассуждать ни о его достоинствах, ни о недостатках. Язык рабочий
- на нём вполне можно писать и писать эффективно. Как на ассемблере.
* C++ - немало дней, ночей и месяцев было посвящено этому
языку. Впечатления? Монстрик. Не монстр, как Ada, или того лучше
PL/I, но всё же монстрик. Программисту помнить надо не только
классы и методы, но и множество разных правил самого языка.
Недаром его автор - Страустрап - так неохотно рассматривает
расширения языка. Он и так уже неизящный. Однако в меру строгий к
ошибкам, чего объектно-ориентированные языки с динамическим
связыванием не дают (но от этой же строгости - его сложность).
* Java - язык, который сочетает в себе достоинства C и C++
и не содержит их недостатков. Компания Sun Microsystems прочит
его как универсальный язык для сети Internet. Этот язык
транслируется в байт-коды специальной интерпретирующей машины и бинар-
ные программы на нём могут быть выполнены на любой машине в
глобальной сети! То есть вы можете затребовать часть кодов своей
программы с другой машины в сети, может быть с другого конца
мира (или с Луны).
* Smalltalk - единственный абсолютно объектно-ориентированный
язык. Даже буквы и числа в нём - объекты, не говоря уж о
том, что и исходный текст программы и её скомпилированный код -
объекты тоже. Увы, Smalltalk - это интерпретатор, хотя и очень
совершенный, быстрый и эффективный. К нему можно добавить новые
примитивы, написанные, скажем, на Си, но его невозможно (да и не
нужно) выполнить непосредственно на процессоре. Скомпилированный
код - это специальные "байткоды" для интерпретатора. В частности
поэтому нельзя использовать Smalltalk из Си. Зато это даёт
абсолютную переносимость его скомпилированного в байткоды образа без
изменений на любую машину.
В прежние годы Smalltalk был просто операционной системой,
а также замкнутой средой разработки на машинах фирмы XEROX.
Сегодня он стал равноправным членом зоопарка языков и сред,
расплодившихся (к примеру) под UNIX.
Главное же достоинство пожалуй таково: язык очень прост. На
изучение достаточно получаса.
За что я не люблю Объектно-Ориентированное Программирование:
за огромное число классов и методов, которые хотя и схожи
по интерфейсу, который наследуют друг у друга, но по площади
своей "поверхности" не укладываются в мою, человеческую,
память... Впрочем, я никогда не писал на нём всерьёз (а это теперь
стало возможным - писать на нём серьёзные вещи, а не игрушечные).
Так что, если б не было Objective-C и написанного на нём
{Open,NeXT}step - я бы выбрал Smalltalk.
* Objective-C - гибрид чистого Си и Smalltalk-а. Фактически
только одна новая конструкция - посылка сообщения:
ответ = [кому селектор аргументы];
Но связывание метода с вызовом - чисто динамическое (для
любителей C++ поясняю: все функции виртуальные). Что не позволяет ловить массу ошибок во время компиляции. Зато язык прост и
строен. В меру даже изящен. Короче, это - мой любимый язык.
* Pascal - в общем весьма неплохой язык, особенно потоптанный
фирмой Borland. Поддерживает вложенные процедуры и
динамически отводимые массивы, чем в Си и не пахнет
(массивами - пахнет, при помощи alloca. Но неизящно).
Недостаток ровно один:
очень уж многословный язык - то и дело пиши длинные слова begin,
end... Вместо лаконичных { и }. Другой недостаток не имманентный:
всё же больше всяких библиотек на Си написано. И для Си.
* Modula - лишена многих недостатков Pascal и обладает
многими достоинствами Си. Хороший язык, но кто на нём пишет?
* Ada - язык с претензиями, но похоже мертворождённый.
Излишняя сложность программиста удручает, и он выбирает другой
язык.
* FORTRAN-77 - язык для физиков, да и то вымирающий. Не
люблю. Некрасиво, очень уж машиной фон Неймана отдаёт, да ещё и
препарированной.
* PL/I - язык, вобравший в себя худшее из FORTRAN и COBOL.
Но и кое-что полезное из Algol. Но всё же он ужасен. Ужасен!!!
* COBOL - по иронии судьбы - первый язык, который я пытался
выучить, один из старейших практических языков. Монстр. Но без
претензий. Россию миновала (практически) участь познакомиться с
этим языком. И возблагодарим за это Господа.
* FORTRAN-90 - не знаю, что будет, если к телеге привинтить
крылья и реактивный двигатель, но... надеюсь, что всё же
полетит. Впрочем, я рассматривал бы прогрессивным такой процесс из-
менения языка, в котором прежде всего не добавляются новые
могучие возможности, а избавляются от идиотизма старого (не внося
при этом новых удачных ухудшений).
* LISP - идея, конечно, интересная... Но уж больно много
скобок. Да и образ мышления нужен другой: списочно-линейный. Из
головы и хвоста - без тела. А ещё надо уметь лямбда-выражаться.
Непривычно.
* Scheme - более мощное развитие LISP. Непривычно, но сильно.
* Prolog - тоже непривычно, хотя по-другому. Но ещё мощнее
и ещё интереснее. Фон Нейман с его машиной спрятался куда-то.
Это тот язык, на который я согласен потратить время. Хотя бы
потому, что сам научусь мыслить логичнее. Эффективность? Особенно
интересно будет, когда ветви логического вывода будут обрабатываться
параллельно на многих процессорах. Но пока я не увижу такого
продукта на своём столе, я не буду говорить о его индустриальном
использовании. Хотя, знаю я и про такое.
* VisualBasic и Tcl/Tk - да, и такие странные языки появились.
Языки для программирования интерактивного графического
интерфейса. Tcl/Tk - это примочка для UNIX. Это интерпретативный
язык, не требующий компиляции. Имеет два ценных свойства: может
встраиваться в Си программы, а ещё - имеет встроенный механизм
общения с другими процессами, на Tcl же написанными.
* Ассемблер - не рассматривается как кандидат для решения
сколь-нибудь сложных задач. Я хочу думать о том, что мне надо
спрограммировать, а не как побороть аппаратуру компьютера. Кроме
того, использование ассемблера в любой части проекта тут же
намертво привязывает весь проект к конкретному типу машины.
Ассемблер остётся для разработчиков компиляторов, оптимизированных
библиотек, да для той братии, которая как раз и борется с железом
по долгу службы: для системных программистов, пищущих
машинно-зависимую часть ядра ОС. Но я им не завидую: труд их тяжек,
но не живёт дольше конкретной ОС и конкретной машины.
* Резюме: языков много, единого нет, самого хорошего нет. В
стремлении сделать более хороший язык, кто-то сочиняет ещё один
- и свалка увеличивается. Сказать же, что для каждой задачи
необходим свой, специализированный, язык, лучше всего отражающий
чаяния данной конкретной задачи, я тоже не могу: будет
Вавилонское столпотворение. Даже при наличии переводчиков. Но и единый
язык, явно, не родится. Хотя бы потому, что у программирования
не одна парадигма (ну к примеру - фон Нейман и логическое
программирование). Мы учим английский, но предпочитаем трепаться
между собой по-русски. А французы - по-французски.
А уж японцы-то и вовсе... А резюме всё же такое: плохую программу можно
написать на любом языке.
* После того, как результат в ПРИНЦИПЕ получен, думаешь "а
как это надо сделать ПРАВИЛЬНО?" И вот теперь, привлекая весь
прежний опыт, в программе пере- и до- писывается до 80% мест.
Порой (и не так уж редко) переписывается ВСЯ программа-прототип.
* Доводка. Приведение к "почти идеалу". Идеал недостижим,
ибо запросы со временем растут, изменяются, и исходят из уже
достигнутого; а опыт (сын ошибок трудных) тоже растёт и подаёт
новые идеи. Посему процесс улучшения не имеет конца. Но первое
приближение к идеалу достижимо: мы дописываем к программе не
только то, чего "я хочу, сейчас", но и то, чего "я мог бы в
принципе захотеть" - и делаем это заранее. Заранее, чтобы ПОТОМ
об этом не заботиться, а если уж и припрёт, то иметь уже намётки:
как это сделать, не с нуля. Заранее сделанное позволяет нам
облегчить жизнь в будущем и отвязаться от этой программы, забыть
про неё.
* Не так ли и в обычной человеческой жизни?
Но я-то хотел сказать что-нибудь про физические сети.
* Тонкий Ethernet - всё хорошо, пока у вас не пропадает
контакт хоть на одном BNC-разъёме. После этого вся сеть перестаёт
работать, и вас осаждают нервные пользователи. А вы неприкаянно
бродите и проверяете все соединения.
* Витая пара - описанная ситуация в принципе невозможна:
если что-то дохнет, то только один провод от машины к хабу. Все
остальные продолжают работать. Зато нужен надёжный хаб, потому
что может зависнуть и он. Ethernet на витой паре существует для
10 и 100 МегаБит в секунду, второй из них требует проводов
повышенного качества, так что не экономьте центы! Кроме того, не
заблуждайтесь, что 10 Мбит/сек. - это много. При пересчёте в
байты - это 1 МБайт/сек. При учёте заголовков пакетов и
столкновений плучится 300-450 КБайт/сек. В лучшем случае.
* Фибероптика - самое надёжное и быстрое. Вам случалось
видеть, как после дождя падает качество связи на телефонных линиях
(а следовательно на модемах)? Мне - да. И так - с любым
металлическим проводом. А с оптическим - не так, ему хоть в речке лежи.
Да, самое надёжное решение (если, конечно, танком не переедут),
но зато и самое дорогое. Существенно дороже прочих.
Проблемы же системного администратра состоят, главным
образом, в том, что он должен знать очень много разнородных вещей.
Причём вещей "универсальных": языков для оформления чего-нибудь.
Языков, а не набора меню и экранных форм. Потому главные
инструменты 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 верна
"обратная" поговорка: "Две головы хорошо, но одна - лучше". В силу
того, что у сети, работающей как одна большая машина, должен быть
один хозяин, который знает все тонкости. Ему же хуже: он должен
так много знать и помнить. Но другим - лучше. Потому, что когда
каждый начинает ставить опыты, и левая рука не знает, что делает
правая нога - результаты получаются ужасающими. Мне доводилось
видеть сети, которые администрировались несколькими людьми.
Некоторые из них были некомпетентны. Это увеличивало работу
главного администратора вдвое и втрое - ему приходилось переделывать
всё за криворукими. С другой стороны, один человек не может
знать всё. И для делания того, что он не знает - ему следует
призвать помощников. Но только пусть они не делают ничего больше!
Итак, в администрировании одна голова лучше - она помнит
всё, общую картину. Но одна голова - и хуже. В том смысле, что
если один заболел, уволился, загулял - все остальные вряд ли
быстро разберутся в накрученных им настройках. Поэтому мэнеджер
должен требовать от администратора записывать хотя бы места,
имена файлов и систем, которые он настраивал. В лучшем же случае
- он должен вести журнал.