[life.sport.darts] Давно ничего не писал про дартс

И, видимо, еще долго ничего писать не буду. Но пару слов сказать можно.

Наверное, удалось более-менее разобраться в самом себе. Очень похоже, что я разучился радоваться небольшим успехам и постоянно концентрируюсь на неудачах. Набор в 100+ очков стал восприниматься как само-собой разумеющееся, а наборы в 26/41/43/45 очков -- как тяжелейший промах. Закрытие первым дротиком -- нормально, вторым или третьим -- трагедия. Не закрываешься с первого подхода и все, настроение на нуле и больше ничего никуда не летит. Между тем, если оценивать по статистике, имея средний набор с подхода в 64 очка, небольшие наборы, вроде 45 очков, как раз являются нормой, а сотенные наборы -- приятным исключением.

В таких условиях главный вопрос, который постоянно крутится в голове, это: "А зачем тебе все это надо?" Смотришь на себя со стороны и понимаешь, что очень плотно занимаешься дартсом уже три года, а какого-то ощутимого результата не наблюдается. Причем чем дальше, тем меньше прогресс заметен вообще.

То ли дело раньше, три года назад. Успехи на каждом шагу: первый 180, затем второй максимум, затем по одному 180 каждую неделю, затем по одному максимуму каждый день, а затем и не по одному. Не было концентрации на своих статистических показателях, не было зацикливания на технике и скорости броска, даже на противника (особенно сильного) не очень обращаешь внимания. Если противник сильный, то проигрыш ему -- это вполне ожидаемо, поэтому и не расстраивает. А вот хорошая игра против него -- это вселяет большую уверенность в себе и дает стимул к дальнейшим тренировкам. Даже частая смена дротиков, которую я когда-то практиковал, добавляла интереса и удовольствия занятиям дартсом.

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

Удивительно, но несмотря на то, что в таком состоянии я находился уже далеко не один месяц, посмотреть на происходящее со стороны и разобраться в себе удалось только сейчас. Хочется надеяться, что диагноз поставлен правильно, а со временем и действенное лекарство найдется. Нужно заново учиться радоваться наборам в 60 очков и не стесняться прыгать от радости от 100+ закрытий. А может и еще какие-нибудь новые дротики опробовать, благо приближается осень, производители начинают анонсировать новые модели (например, некоторые уже анонсированы на PureDarts).

Кстати о дротиках. Все-таки дротики имеют значение. Под себя нужно подбирать форму, вес и тип насечки. Нужно ли для этого перебрать несколько десятков, как это сделал я? Фиг знает. Наверное нет, достаточно было бы опробовать 3-4 модели. Главное, чтобы они кардинальным образом отличались по форме и весу. Причем проверять их нужно не только на тренировках, но, в обязательном порядке, на соревнованиях. Я, например, на тренировках вполне нормально бросал дротиками в 19, 20 и 21 грамм. А вот в напряженных матчах, когда адреналина в крови намного больше нормы, просто переставал их чувствовать в руках. Как будто пушинку в мишень бросаешь. С 26-граммовыми, наоборот. Для соревнований самое то, а вот во время длительных тренировок быстрее устаешь. В результате пришел к выводу, что оптимальным для меня является вес от 23 до 25 грамм. Поэтому уже давно играю 24-х граммовыми дротиками.

В общем, подводя итог сего потока сознания, нужно отметить правильность давно известной истины: хороший результат в чем-то можно получить, только делая это с удовольствием. Так что постараюсь вновь научиться радоваться своим достижениям в дартсе. Хотя в ближайшие 8-10 месяцев это будет сложно: пора переходить на борьбу с n01 на 7-ом уровне (из 12-ти). Полгода назад, играя с n01 на 6-м уровне мне в лучших матчах удавалось выиграть 1-2 сета. В последний месяц счет нередко доходил до 5-4 по сетам в ту или сторону, но мои выигрыши перестали быть эпизодическими и стали случаться регулярно. А сегодня мне удалось сделать n01 со счетом 5-0. Понятно, что повезло, и генератор наборов у n01 сегодня не отличался производительностью ;) Но все-таки очень приятно. И есть огромное желание двигаться дальше, пусть даже мне предстоит длительная череда поражений 0-5. Зато будет как три года назад: противник явно сильнее, поэтому нет смысла расстраиваться проигрышу, нужно просто получать удовольствие от удачных подходов.

А вообще: играйте в дартс, это здорово!

[prog] Залил два .gem-а на RubyGems.org

Пользуясь наличием свободного времени уделил немного внимания своим старым разработкам.

Во-первых, залил на RubyGems.org версию 1.6.0 системы сборки Mxx_ru. Эта версия уже была опубликована на RubyForge, но оттуда ее нужно было забирать и затем устанавливать к себе вручную. Теперь же для установки Mxx_ru 1.6.0 достаточно выполнить gem install Mxx_ru, а для обновления с предыдущей версии -- gem update Mxx_ru.

Нужно сказать, что в последнее время Mxx_ru занимался не я, а мои, теперь уже бывшие подчиненные, в первую очередь, Николай Шмаков. Что меня лично не может не радовать, т.к. вряд ли я сам смогу внести еще какой-то заметный вклад в Mxx_ru.

Во-вторых, опубликовал на RubyForge и RubyGems давным-давно написанную версию старого проекта ClsRuby. Эта версия, 1.1.2, практически ничего не добавляет к функциональности, но, в отличии от 1.0.2, работает под Ruby 1.9.*.

Про ClsRuby можно сказать несколько слов. В начале 2000-х сделали такой интересный язык программирования -- Curl (я когда-то рассказывал о нем). Программировать мне на нем не довелось, но вот его синтаксис я решил задействовать для оформления конфигурационных файлов. Для чего сначала сделал библиотеку на C++, а затем, в период активного использования Ruby, и на Ruby. Так и получился проект ClsRuby.

К исходникам ClsRuby я уже давно не притрагивался. Но, поскольку ClsRuby используется внутри некоторых проектных файлов SObjectizer-а, то потребовалось исправить досадное упущение и опубликовать таки последнюю актуальную версию.

Попутно закачал исходники ClsRuby в репозиторий на RubyForge. Ранее они лежали в svn-е Интервэйла, но т.к. для меня он уже закрыт, то пускай отныне лежат в доступном месте.

Заодно обнаружил, что мой древний-предревний сайт eao197.narod.ru переехал с Yandex-а на uCoz. Т.е. переехал то он уже пару месяцев как, но я об этом узнал только сейчас :) Не самое приятное открытие, нужно сказать. Не все символы разрешается использовать в именах каталогов, глубина директориев ограничена всего четырьмя уровнями, в одном каталоге не больше 200 файлов... В общем, когда-то я туда заливал документацию по своим разработкам. Теперь вряд ли буду это делать. С грехом пополам обновил документацию по ClsRuby. Посмотреть можно здесь. Теперь нужно найти силы и желание сделать тоже самое с документацией по RuCodeGen :(

[prog.thoughts] И еще на тему Go (после прочтения всего Effective Go)

Странные ощущения меня одолевают после штудирования Effective Go (а до этого и A Tour of Go). Попробую перечислить основные моменты.

---

Во-первых, не могу сказать, что из прочтенных документов я понял, как на Go программировать. Очень вероятно, что это моя менеджерская тупость. Но как-то не сложилось у меня в голове картинка. Когда изучал Ruby по отличной книге Programming Ruby, то представлял себе из чего состоит Ruby-новая программа. Когда изучал Eiffel по "Объектно-ориентированному проектированию программных систем" -- то же самое. А вот здесь что-то не понимаю. Должна ли программа на Go быть похожа на C-шную программу с функцией main, набором функций и структур данных? Или же это должно быть больше в стиле Java: набор классов для решения прикладной задачи?

Думаю, это из-за того, что в прочитанных мной учебниках по Go очень мало места уделено пользовательским структурам данных. Много говорят о каналах. Много говорят о том, как писать методы и привязывать методы к разным типам. Но вот о самих типах говорится немного. Да, есть примеры простых структур. Да, есть совсем чуть чуть о том, как имитировать в структурах наследование, в том числе и множественное. Но это все. И лично у меня нет понимания, как эти тривиальные примеры отмасштабировать на что-то более-менее реальное и жизненное.

Вообще, очень сильное ощущение, что Go предназначен для разработки мелких программ на выброс утилит в духе unix way: одна операция на утилиту, для более сложных задач собирается конвейер из подобных мелких утилит.

И еще одно ощущение, от которого не удается отделаться. Каналы -- это, очевидно, киллер-фича языка. Но что привлекательного остается в языке, если не пользоваться каналами? Например, для написания большого фрагмента кода, решающего чисто вычислительные задачи? Будет ли Go удобен для обработки сложных структур данных? У меня нет даже предположений по этому поводу.

В общем, после более плотного знакомства с Go вопросов и недопонимания оказалось больше, чем я ожидал. А желания использовать Go, напротив, намного меньше. Возможно, попрограммируй я на Go пару-тройку месяцев, все бы встало на свои места. Но вряд ли я это буду делать.

---

Во-вторых, не уверен, что полностью понимаю, зачем вообще нужно было создавать новый язык.

Я когда-то писал про презентацию Роба Пайка о языке Go. В которой делается попытка обосновать причины появления Go. Но я не был полностью удовлетворен этими причинами тогда. Сейчас же непонимание усилилось еще больше. Особенно после беглого просмотра презентаций, ссылки на которые были даны в этом посте: Advanced Go Concurrency Patterns

Если Go решал проблемы многозадачности (не придумал лучшего термина в этом контексте для concurrency), то почему нельзя было обойтись библиотекой или набором библиотек для C++? Аналоги Go-шных каналов на шаблонах C++ могут быть написаны, да так, чтобы и пользоваться ими было удобно, и в эффективности они не теряли. Да, для C++98/03 это было бы многословно, гораздо многословнее, чем на Go. Но те самые паттерны, о которых говорят разработчики Go, могли бы быть использованы на уже существующем языке с большим количеством готового инструментария и большущей армией опытных программистов во всем мире.

Однако, очевидно, что в языке с ручным управлением памятью (таком как C++ или C) написание многозадачного кода не есть простая тема. Я на себе это прочувствовал, когда делал и использовал SObjectizer. Так что сочетание каналов со встроенным в язык сборщиком мусора -- это разумный ход. (Хотя здесь можно было бы подискутировать о том, насколько сложно потом будет бороться с эффектами сборки мусора в нагруженных приложениях. И о том, какого качества сборщик мусора будет на первых порах в Go. Но лучше оставить эти вопросы за рамками обсуждения.)

Но тогда возникает вопрос, почему за основу не был взят какой-нибудь управляемый язык со сборкой мусора? Та же Java, например. Тем более, что в Google, насколько мне известно, Java давно и активно используется.

Аргументы против Java, конечно же, лежат на поверхности. Это и очень большая многословность, и не такая высокая производительность (как у хардкорного C/C++ кода), и плохая приспособленность для околосистемных/низкоуровневых задач (например, отсутствие беззнаковых целых чисел, отсутствие контроля за расположением данных в памяти и пр.). Но тут еще как посмотреть: вопросы производительности, например, для сервер-сайда не так критичны, как для десктопа или чистых числодробилок.

В общем понятно, что каналы можно было реализовать в виде библиотек для уже существующих языков. Но это выглядело бы не так компактно и привлекательно. В этом плане создание нового языка выглядит оправданным.

С другой стороны, создан совсем новый язык, в котором несколько фич выглядят очень здорово и позволяют записывать некоторые приемы многозадачного программирования весьма компактно. Но при этом новый язык:

• поддерживает какую-то мутную схему обработки ошибок посредством panic-ов и recover-ов (подробнее см.здесь);
• не имеет серьезной кодовой базы и большого количества инструментальных средств. Плюс к этому полное отсутствие опытных разработчиков на рынке труда;
• и, самое главное для меня, не имеет никаких средств для обобщенного программирования.

И вот этот последний пункт, на счет обобщенного программирования, для меня наиболее важен и непонятен. Сейчас все более-менее заметные в мейнстриме языки поддерживают обобщенное программирование: в C++ есть шаблоны, в Java/C# -- генерики, в Scala, например, без генериков вообще никуда. В Haskell-е, насколько я понимаю, обобщенное программирование -- это краеугольный камень. Про динамически типизированные языки (Python, Ruby, JavaScript) даже не приходится говорить. А вот в Go с этим просто швах. Никаких шаблонов. Хочешь чего-нибудь обобщенного -- прячь все это за интерфейсами. А вот получится ли у тебя на интерфейсах сделать какой-нибудь сложный контейнер, который мог бы хранить как string-и, так и пользовательские структуры или int-ы -- это большой вопрос. Подозреваю, что не получится.

Ну и еще одно. При всех своих проблемах и недостатках те же C++ и Java доказали, что они позволяют создавать большие и сложные программные комплексы из больших и сложных библиотек функций/шаблонов/классов. Возможно, отдельные "недостатки" этих языков как раз таки являются ценой, которую приходится платить за эту самую возможность строить очень большое и очень сложное из больших и сложных частей. Предназначен ли Go для того, чтобы создавать большие приложения из компонентов, сравнимых по объему с Qt/ACE/ICU/Boost (для C++) или Eclipse Platform (для Java)? Я почему-то думаю, что нет. И это так же заставляет задуматься о том, зачем он вообще нужен.

---

В-третьих, похоже, вообще шансов для попадания в мейнстрим у новых языков нет. Если только новый язык не является просто синтаксическим сахаром над наработками на более старом мейнстримовом языке (например, Scala или Ceylon над Java-библиотеками для JVM).

Высказывая это предположение я в большей степени говорю как менеджер, не как программист. Как программисту мне было бы интересно время от времени пробовать новые игрушки языки, просто для того, чтобы мозги не заквасились и глаз не замылился.

Но вот как менеджер я понимаю, что работать нужно здесь и сейчас, быстро и качественно. Это означает, например, что если тебе приходится иметь дело с СУБД MS SQL Server, ты не можешь позволить себе искать более-менее работающий ODBC драйвер для нового языка программирования на каком-нибудь github-е или SourceForge. И не можешь позволить себе писать какую-нибудь библиотеку с нуля или же помогать кому-нибудь в ее создании. Потому что вокруг уже есть аналоги для C/C++, Java, C# или даже Haskell-я. Более взрослые, функциональные, отработанные, со сложившимися коммьюнити. И уж если тратить свое время на помощь кому-то, то лучше присоединяться к серьезным, устоявшимся проектам. Риски в этом случае меньше.

Представляется, что уже вполне определились следующие экосистемы:

• чистый нэйтив в лице C и C++;
• Java и языки вокруг JVM (Scala, Ceylon, Kotlin и иже с ними);
• C# и .NET (включая Visual Basic и экзотику вроде F#);
• JavaScript (как client-side в браузере, так и средство разработки UI для десктопа);
• динамически-типизированные языки, каждый из которых является собственной программной платформой: Perl, Python, Ruby, PHP, Erlang.

Ну и плюс к этому нишевые экосистемы, размер и значимость которых я не могу определить: Objective-C (платформы Apple), нативная функциональщина (в первую очередь Haskell, OCaml, различные варианты Lisp-ов и ML-ей), Adobe ActionScript (Flash-овый client-side в браузере).

Такие экосистемы сложились не сегодня, и даже не вчера. Но с каждым днем их размер, а так же взаимные различия, только увеличиваются. Поэтому новым языкам нужно уметь встраиваться в какую-то из них максимально прозрачным образом: обязательно уметь использовать уже существующий код и желательно уметь предоставлять старому коду возможность взаимодействия с новым кодом. Как раз то, что демонстрируют Scala и Ceylon в мире JVM.

Объясняется моя точка зрения очень просто. Я не верю в то, что кто-то сейчас может вложиться и написать для нового языка что-то сравнимое с Qt или JDK. ИМХО, это не реально. Да и вряд ли кому-то нужно. Поэтому у новых языков, если они претендуют на звание универсальных языков общего назначения, нет другого выхода, кроме как позволять очень простым способом использовать написанное ранее для других языков.

И вот здесь у чистых нейтив языков ситуация совсем аховая. Если интегрироваться с C еще возможно, то вот как интегрироваться с C++ным кодом, да еще с современным шаблонным C++ным кодом?

В этом плане как раз у фунциональшины в лице Haskell-я ситуация намного лучше, чем у Go, D или Rust. Там совсем другой подход к программированию. Поэтому-то и библиотеки нужны совсем другие, ценность плюсовых библиотек для Haskell-я невелика.

Вот и получается у меня, что в чистом нейтиве нормальные шансы на развитие есть только у C/C++ и у Haskell-я. Всему остальному придется создавать/отвоевывать себе узкую нишу, баррикадироваться там намертво и никого не пущать :)

[prog.flame] Что-то уж слишком многого я не понимаю в языке Go

В попытке изучить текущий вариант языка Go (версия 1.1.1 на данный момент) прочитал почти весь документ Effective Go. Постоянно ловлю себя на впечатлении, что это какой-то хакерский язык: он был придуман хакерами для хакеров и только хакеры будут с удовольствием на нем программировать :(

Есть в Go вещи из разряда "запомнытэ это, патамушта панять это нэвозможно!". Вот, например, почему для признака публичности имени используется регистр первой буквы в имени? Т.е. MyType -- это публичное имя, которое экспортируется из пакета. А вот myType -- это приватное имя, которое вне пакета не видно.

Или еще. Почему для объявления переменных используется две синтаксических конструкции: декларация var с указанием типа переменной и декларация имени с инициализацией через оператор :=? Вот так это выглядит в коде:

var i int = 0 j := 0

Или вот почему в Go так легко запустить гороутину, но нет простого встроенного способа определить момент завершения ее работы? Нужно вручную создавать канал, передавать его в гороутину, там в конце работы что-то в канал записывать, по месту старта гороутины читать из канала. Почему бы это все не спрятать за каким-то вариантом старта гороутин? Чтобы, например, вместо

f := make(chan int) go func(r chan int) {    // Здесь что-то делаем...    r <- 0 }(f) <-f

использовать что-то вроде:

f := go func() {    // Здесь что-то делаем... }() f.Wait()

Ну а апофеозом моего непонимания стала реализация неблокирующей записи значения в канал. Мой привыкший к C++ мозг был буквально разорван тем, что неблокирующая запись (как и чтение) в канал реализуется посредством оператора select (который в C/C++/Java известен как switch):

select { case freeList <- b:    // Buffer on free list; nothing more to do. default:    // Free list full, just carry on. }

Ну вот не могло мне придти в голову, что для неблокирующей записи оператор <- нужно помещать внутрь select-а, в котором обязательно должна быть секция default. И даже после того, как я узнал об этом, мне не удается понять, какой логикой руководствовались авторы языка, придумывая такую штуку.

Я до сих пор помню свои впечатления, когда после языка Паскаль начал изучать C и как радовали C-шные конструкции i+=1 или i++ после унылых Паскалевских i:=i+1. А уж классический while(*p++) вообще широко распахивал двери в, как тогда казалось, настоящее программирование. Это потом уже, имея десятки лет опыта разработки за плечами и кучу набитых на ++, -- и дефолтных преобразованиях к bool шишек, пришло понимание, что лаконичность записи посредством хакерских штучек далеко не всегда хорошо. Поэтому сейчас видя в Go какую-то кучу приемов и приемчиков, сокращающих текст программы, но не имеющих очевидного логического обоснования, становится как-то не по себе.

[management.thoughts] Все под контролем?

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

Полагаю, что чем более творческим и непредсказуемым процессом руководит человек, тем больше он осознает, как же мало он контролирует на самом деле, насколько сильно ему приходится полагаться на своих подчиненных. К таковым процессам, определенно, можно отнести разработку ПО. Думаю, что во многом из-за этого у менеджеров программистов есть стремление к формализации, к внедрению разнообразной отчетности, формальных метрик и пр. вещей, которые создают впечатление "прозрачности" происходящего. Особенно у менеджеров, которые пришли в коллектив "со стороны", поскольку им в короткое время нужно уразуметь "объективную картину мира". Хотя как раз из-за огромного количества деталей и частностей, которые не могут быть оттранслированны наверх, эта прозрачность оказывается в большей степени иллюзорной. Особенно, если "объективность картины мира" базируется лишь на формальных метриках. Поскольку когда подчиненные понимают, что их оценивают лишь по формальным параметрам, они очень быстро приспосабливаются манипулировать этими метриками в своих интересах.

Еще один источник неопределенности -- это самостоятельность сотрудников. Чем больше у них самостоятельности, тем более неожиданные для руководства действия они могут предпринимать. Поэтому еще одно вполне естественное желание руководителей -- это ограничение свободы своих подчиненных. В пределе: никаких самостоятельных решений без предварительного согласования. Однако, неординарность мышления и способность к генерации нестандартных идей, как правило, дополняется инициативностью и самостоятельностью. Поэтому, если мы ждем от подчиненных новых идей, то следует ждать от них и самостоятельных действий, а так же нежелания работать в условиях тотального контроля. И наоборот, склонность действия по указке, на мой взгляд, является следствием отсутствия собственных идей и/или желания нести за них ответственность. Что, опять же, ведет к тому, что чем более творческим процессом приходится руководить, тем больше приходится полагаться на непредсказуемых, инициативных, способных к самостоятельным действиям, не боящихся ответственности подчиненных. В таких условиях утверждение "У меня все под контролем!" становится еще более условным, т.к. в любой момент где-то внизу может произойти все, что угодно ;)

В качестве иллюстрации приведу пример из воспоминаний Б.Е.Чертока:

В условиях крайнего напряжения и постоянного недосыпания испытателей на технической позиции происходили досадные происшествия. Однажды по ошибке испытателей подорвали пиропатроны механизмов сброса отсеков и КТДУ. Другим происшествием было разрушение автоматической лунной станции (АЛС) внешним избыточным давлением барокамеры, потому что забыли дать уравновешивающее давление в гермокорпус АЛСа после испытаний на герметичность.

Тюлин подписывал телеграммы министрам, требуя санкций за низкое качество изделий...

19 февраля случилось уж совсем конфузное происшествие. При пуске венерианского зонда не запустился двигатель третьей ступени блока «И». Расследование показало, что отказ явился результатом негерметичности в керосиновой магистрали, которая проходит через туннель бака жидкого кислорода. Разделительный клапан подтекал, и керосин замерз в туннельной трубе. Третья ступень вообще не сработала, и зонд погиб.

10 марта на полигоне Государственная комиссия слушала доклад Шабарова по этому вопросу и принимала программу межпланетных пусков на ближайшие два месяца. 11 марта последовал вызов Госкомиссии и всех главных конструкторов в Москву для доклада в Кремле на заседании ВПК. «Похоже, что у Хрущева терпение кончилось и он дал команду всыпать нам всем по заслугам», — предположил Тюлин. В Москву мы вылетели большим составом, оставив на полигоне Шабарова и Осташева с задачей не прерывать подготовку всех объектов ни на час.

13 марта 1964 года в 17 часов все прилетевшие, а также остававшиеся в Москве Королев и Келдыш предстали в Кремле перед Комиссией по военно-промышленным вопросам при Совете Министров СССР.

В Овальном зале знаменитого здания архитектора Казакова заседание проводил председатель ВПК Леонид Смирнов. Присутствовали все члены комиссии — министры, председатели государственных комитетов и руководство оборонного отдела ЦК.

Первым докладывал Королев. Он начал с того, что его вызывает для доклада товарищ Брежнев, ночью всем нам надо вылететь обратно на полигон, поэтому он убедительно просит не затягивать обсуждения. Что касается последней аварии, то это досадная оплошность, не распространяющаяся на последующие машины. Виновные в недосмотре уже наказаны, все еще раз проверено, и необходимо только согласие на последующие пуски...

После очень коротких докладов главных конструкторов и заключения Тюлина ВПК без обсуждения мирно постановила:

«Принять к сведению сообщения главных конструкторов — товарищей Королева, Рязанского, Пилюгина, Хрусталева, Морачевского, что при подготовке космических объектов 3МВ и Е-6 приняты необходимые меры по обеспечению высокой надежности всех систем объектов и носителей с учетом рекомендаций экспертных комиссий и опыта предыдущих пусков».

Далее ВПК перешла к обсуждению хода подготовки к пилотируемому пуску «Восхода».

В это время мне передали записку: «Б.Е.! Срочно выйдите в приемную. Ирен». Случилось, очевидно, нечто страшное, ибо дисциплинированная и опытнейшая секретарша в приемной ВПК Ирен не решилась бы без крайней необходимости вызывать меня с такого заседания. Когда я выскользнул из зала, Ирен сказала, чтобы я срочно звонил к себе по «кремлевке» — «там на ВЧ-связи с полигона ждет Шабаров». Тот сообщил, что часа два назад при испытаниях АЛСа Е-6 Пиковский перепутал кабели, устроил на «борту» пожар, вышли из строя батареи и приборы. Аппарат к пуску непригоден, график сорван начисто.

[life.idiotic] Ну и сразу еще раз про пароли

Не успел закончить предыдущую заметку про комбинации к кодовым замкам, как жизнь тут же подкинула прямо таки великолепный пример отношения к паролям. В почту упало уведомление о доступе к очередной части бесплатного видеокурса по фотографии, с кодом доступа к видеоролику:

Не смотря на то, что пароль в email-е был указан правильно, предъявить я его сходу не смог. В чем причина? (ответ под катом)

[life.history] Про пароли к кодовым замкам (из неофициальной истории Манхэттенского проекта)

В книге Ричарда Феймана "Вы, конечно, шутите, мистер Фейман" есть глава "Ты шнифер, и я шнифер", в которой Фейман рассказывает о своем увлечении во время работы в Лос-Аламосе над Манхэттенским проектом. Он научился подбирать пароли к кодовым замкам шкафов, в которых сотрудники Лос-Аламоса хранили секретные документы. В результате Фейман заработал репутацию опытного взломщика. Впрочем, интересующимся лучше прочитать всю главу самостоятельно, она очень легко и увлекательно написана, а забавного и поучительного в ней много. Я же хочу здесь процитировать всего несколько фрагментов.

Фрагмент первый, использование social engineering :)

Однажды летом после войны мне понадобилось закончить одну работу, и из Корнелла, где я в тот год преподавал, я отправился в Лос-Аламос. Во время этой работы мне понадобился мой старый отчет, который хранился в библиотеке.

Я пошел в библиотеку, но возле нее расхаживал взад и вперед солдат с винтовкой. Это была суббота, а после войны по субботам библиотека была закрыта.

Тогда я вспомнил о занятии своего хорошего приятеля, Фредерика де Хоффмана. Он работал в комиссии по рассекречиванию. После войны военные решили рассекретить некоторые документы, и ему пришлось постоянно бегать в библиотеку: взглянуть на эту бумагу, взглянуть на ту бумагу, проверить это, проверить то, - от всего этого с ума можно было сойти! И он сделал копии всех документов, - всех секретов атомной бомбы, - и забил ими девять шкафов своего кабинета.

Я спустился в его кабинет и нашел, что там горит свет. Дело выглядело так, словно кто-то, - его секретарша, наверное, - только что на минуту вышел. Я стал ждать. Ожидая, я принялся крутить лимб замка одного из шкафов (кстати, последних двух чисел сейфов де Хоффмана я не знал: они были установлены после войны, когда я уже уехал из Лос-Аламоса).

Я крутил лимб и вспоминал книжки про взломщиков. Я думал: "На меня никогда не производили впечатления описанные в этих книжках трюки, и я никогда не пытался попробовать их. Однако посмотрим, нельзя ли открыть сейф Хоффмана, руководствуясь советами из этих книг".

Трюк первый: секретарша. Она боится забыть комбинацию и где-нибудь ее записывает. Я начал искать в местах, упомянутых в книге. Ящик стола оказался заперт, но это был обычный замок из тех, открывать которые меня научил Лео Лавателли. Чпок! Я смотрю с краю - ничего.

Потом я просматриваю бумаги секретарши. Нахожу листок, который есть у любой секретарши. На нем тщательно вырисованы буквы греческого алфавита, чтобы их можно было опознать в математических формулах, и против каждой написано ее название. Там же, в верхней части листка, небрежно написано: р = 3,14159. Так, шесть цифр, да еще на кой черт секретарше знать число пи? Ясно, зачем: других причин нет!

Отправляюсь к шкафам и набираю на первом: 31-41-59. Не открывает. Пробую 59-41-31. Тоже не годится. 95-14-13. Назад, вперед, вверх тормашками, так, эдак - никак!

Запираю ящик стола и уже направляюсь к двери, когда снова приходит в голову из книжки про взломщиков: попробуйте психологический метод. Говорю себе: "Фредди де Хоффман именно такой тип, от которого можно ждать использования математической константы в качестве комбинации для сейфа".

Снова возвращаюсь к первому шкафу и набираю 27-18-28 - ЩЕЛК! Сработало! (Основание натуральных логарифмов e = 2,71828 - вторая по важности после пи математическая константа.) Шкафов девять, я открыл первый, но нужной бумаги в нем не было - бумаги шли в алфавитном порядке фамилий авторов. Пробую второй шкаф: 27-18-28 - ЩЕЛК! Открылся той же комбинацией. "Чудесно, - думаю я, - я открыл все секреты атомной бомбы, но если я собираюсь когда-нибудь рассказывать этот анекдот, я должен убедиться, что все комбинации действительно одинаковы!" Некоторые из шкафов были в соседней комнате, я попробовал 27-18-28 на одном из них, и он открылся. Теперь я открыл три сейфа - и все три одной комбинацией.

Однако лично мне в этой истории нравится не столько то, что в качестве шифра для всех шкафов использовались первые шесть цифр константы e. А то, что для преодоления дурацкого режима доступа к документам, один из сотрудников проекта просто сделал копию всей документации и хранил ее так, как ему было удобно, не считаясь с необходимостью охраны государственной тайны.

Второй фрагмент, который я хотел бы опубликовать здесь, составлен из нескольких кусочков для краткости, поскольку в книге он занимает довольно много места.

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

Кабинет Капитана помещался на третьем этаже одного из тех собранных на скорую руку деревянных зданий, в которых у всех нас были кабинеты, а заказанный им сейф был железный и тяжелый. Такелажникам пришлось делать деревянные помосты и использовать специальные тали, чтобы поднять его по лестнице. Так как развлечений у нас было немного, все мы собрались поглазеть на великие усилия, с которыми сейф тащили в кабинет Капитана, и похихикать насчет секретов, которые он будет хранить в этом сейфе. Кто-то даже предлагал махнуться сейфами. Словом, об этом сейфе знали все.

...

Вывозивший сейф хозяйственник хотел получить за него премию, однако сначала его надо было опорожнить, а единственными людьми, знавшими его комбинацию, были Капитан, который в это время был на Бикини, и Альварес, который забыл ее. Парень обратился с просьбой ко мне.

Я пошел к секретарше капитана и спросил:
- Почему бы Вам не позвонить шефу и не узнать у него комбинацию?
- Я не хочу его беспокоить. - ответила она.
- Слушайте, Вы собираетесь беспокоить меня в течение, может быть, восьми часов. Я не возьмусь за это, если Вы не попытаетесь дозвониться до шефа.
- Хорошо, хорошо, - и она взялась за трубку, а я пошел в другую комнату посмотреть на сейф. Он стоял там огромный и железный, а его дверцы были открыты.
Я вернулся к секретарше:
- Он открыт.
- Восхитительно! - зачирикала она, бросая трубку.
- Нет, - сказал я, - он уже был открыт.
- Ах! Наверное, хозяйственникам в конце концов удалось открыть его!
Я отправился к хозяйственнику:
- Я сходил к сейфу, но он уже был открыт.
- Ну да, - сказал он, - извините, не успел предупредить Вас. Я послал штатного слесаря просверлить его, но прежде чем сверлить, он попробовал открыть, и ему удалось.

Далее Фейман рассказывает как он разыскал слесаря, начал общаться с ним и ждал подходящего момента, чтобы завести разговор о сейфе капитана и выведать секрет вскрытия этого типа сейфов. Вот кульминация этой истории:

- Покажи, - сказал он, и я показал ему, как это делается. Он повернулся ко мне:
- А как тебя зовут?
До этого момента мы не представлялись друг другу.
- Дик Фейнман, - сказал я.
- Боже! Так ты Фейнман, - сказал он с благоговением, - Великий взломщик! Я слышал о тебе и давно хотел познакомиться с тобой. Я хочу, чтобы ты научил меня вскрывать сейфы!
- Какого черта? Ты сам умеешь открывать сейфы!
- Нет, не умею.
- Послушай, я знаю про случай с сейфом Капитана, и с тех поря приложил столько стараний, чтобы познакомиться с тобой! А ты говоришь мне, что не умеешь открывать сейфы.
- Не умею.
- Ладно, ты должен знать, как сверлить их.
- Я и этого не знаю.
- КАК? - воскликнул я, - этот тип из хозяйственного отдела сказал, что ты собрал свои инструменты и пошел сверлить сейф Капитана.
- Поставь себя на мое место. Тебя взяли слесарем. К тебе приходят и говорят, что надо просверлить сейф. Что бы ты стал делать?
- Ладно, - согласился я, - я собрал бы свой инструмент и отправился к сейфу. Там я ткнул бы дрелью куда-нибудь в сейф и ж-ж-ж-ж.., принялся сверлить, чтобы меня не выгнали с работы.
- Именно так я и собирался сделать.
- Но ты же открыл его! Значит, ты знаешь, как вскрывать сейфы.
- О да. Я знаю, что замки приходят с завода установленными на 25-0-25 или на 50-25-50, и я подумал: "Чем черт не шутит. Может этот олух не потрудился сменить комбинацию", и вторая комбинация открыла замок.

Итак, кое-что я от него все же узнал, - он открывал сейфы тем же чудодейственным способом, что и я. Но занятнее всего все же было то, что этот индюк Капитан получил супер-суперсейф, не постеснялся заставить пыхтеть кучу народа, которая тащила его сейф наверх, а потом даже не позаботился установить свою комбинацию.

Я прошелся по кабинетам своего здания, пробуя эти две заводские комбинации, и открыл каждый пятый сейф.

Цитаты закончились. Пора переходить к морали. Хотя это слово здесь не очень подходит. Пусть будет что-то вроде выводов:

• забавно, но я не ожидал, что с проблемой дефолтных паролей люди столкнулись намного раньше появления MS SQL Server (MSSQL я упомянул потому, что в свое время был шокирован узнав, как много его инсталляций работают с дефолтным паролем для учетной записи sa) ;)
• если даже из соображений самой-самой большой важности внедрить неудобные для людей правила работы (в данном случае речь идет о режиме доступа к секретным документам), то люди, в конце-концов, придумают способы их обхода. И будут думать только о собственном удобстве, а не о "соображениях самой-самой большой важности". Можно обзывать это халатностью или пренебрежением. Но лучше исходить из того, что это произойдет и предпринимать соответствующие меры до, чем развешивать ярлыки, накладывать взыскания и устранять ущерб после;
• чем выше находится руководитель, тем меньше реальных подробностей деятельности в своем проекте он знает. Это я сейчас вспоминаю самодовольные утверждения Лесли Гровса, руководителя Манхэттенского проекта, о том, что у него на проекте были приняты достаточные средства обеспечения безопасности. Очевидно, что средства эти были довольно дырявыми. Если же сюда добавить еще и режим жесткого разделения информации между подразделениями, в результате которого каждый коллектив был вынужден "варится в собственном соку" (примеры я приводил здесь), то вспоминается очень хороший вопрос: "Что это -- глупость или измена?" ;)

[life.photo;humour] Чистокровный хиппи

Снимок сделан на праздновании Дня Независимости на "Прудах".

PS. Кто-нибудь знает, что это за порода?