April 10th, 2014

Бритоголовый и С1-97

Как он так сделал?

Продолжим тему всяких непонятных картинок и видео, сегодня – про котиков.

thecatscan

Судя по тому, что картинку я честно попер с http://thecatscan.tumblr.com/, сделана она, как следует из названия, при помощи кота и сканера. Но как? Лично меня смущает, например, то, что на одной горизонтальной линии получается аж две кошачьих мордочки.

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Про свечение на Марсе

curiosity

Все носятся с фотографиями чего-то странного, что запечатлел марсоход Curiosity, кто-то уже проверяет схрон с патронами, а я захотел еще раз посмотреть фильм “Пустыня Тартари” (Il deserto dei Tartari).

tartari

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Слышали звон

Имел удовольствие прочитать вот такой текст:

При исправлении учтите пожалуйста сценарии использования поворота экрана, переключения оконного режима. Телефонный сафари очень любит издеваться над пользователями, а наибольший трафик на сайт идёт именно со свзяки iphone/safari 7.

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

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

При исправлении учтите, пожалуйста, поворот экрана и переключение оконного режима.

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

PS Кстати, вопрос на засыпку “писателям” – чем цель отличается от задачи?

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Пара слов про heartbleed

На днях прочитал такое мнение по поводу известного бага в OpenSSL:

Yes, tell me more about how crypto should only be written in memory unsafe languages.

Мол, язык C, на котором написана OpenSSL, допускает произвольный доступ к памяти, из-за чего, собственно, и появляется возможность доступа к уже освободившейся памяти, занятой чужими данными. А вот если бы OpenSSL писали на правильном языке, не допускающем таких штук – то все было бы хорошо.

К сожалению, дело не в языке. Начну хотя бы с того, что используемые сегодня процессоры и операционные системы нельзя назвать memory-safe. Любая загруженная библиотека имеет доступ ко всей памяти процесса – и неважно, на каком языке она написана. Предлагается просто поверить в то, что реализация “правильного” языка подобных ошибок не содержит, фактически – перенести ответственность с авторов библиотеки на авторов компилятора или интерпретатора. Напоминает сказку про кашу из топора? Правда, я как-то писал про это, только в другом контексте.

На C, кстати говоря, тоже можно писать в стиле memory-safe. По большому счету это требование – лишь набор некоторых ограничений, которые можно либо соблюдать, либо нет. По большому счету, все упирается в еще одно “критическое” место – реализацию некоторых функций из стандартной библиотеки. Если мы можем предположить, что malloc() и free() реализованы корректно, то можно попробовать доказать или опровергнуть то, что то или иное обращение к памяти будет безопасно. Второй путь, “практический” – реализовать эти функции так, чтобы некорректная работа с памятью приводила к ошибкам и “падению” программы. Так сделано, например, в libc – но…

http://article.gmane.org/gmane.os.openbsd.misc/211963

Оказывается, что в OpenSSL реализованы свои функции распределения памяти, и реализованы они криво (как показывает существование этого бага). А зачем это сделано? Оказывается, на “некоторых платформах” штатные malloc() и free() работают, по мнению авторов OpenSSL, “медленно”.

После этого вы хотите поговорить о “memory-safe”? Уверен, что в таком случае талантливые разработчики OpenSSL найдут еще с десяток причин нарушить это ограничение, как бы вы не старались. Страуструп писал в своем талмуде по C++ (по поводу ключевых слов private и public):

Защита закрытых данных базируется на ограничении использования имен членов класса. Эту защиту можно обойти манипулированием с адресами и путем явного преобразования типа. Но это, конечно, уже жульничество. C++ защищает от случайного, а не умышленного нарушения правил. Защиту против злонамеренного доступа к закрытым данным в языке высокого уровня можно осуществить только на аппаратном уровне, и даже это является довольно сложной задачей в реальной системе.

То же самое можно сказать, наверное, о любых ограничениях любого языка. От “грязных хаков” может спасти лишь соответствующее к ним отношение в процессе разработки, своеобразная дисциплина разработчиков – а с этим в OpenSSL туговато. Еще раз призываю перечитать слова Тео де Раадта по ссылке выше и убедиться, что даже с тестированием у них печаль-беда:

On ALL PLATFORMS, because that option is the default, and Ted’s tests show you can’t turn it off because they haven’t tested without it in ages. <…> OpenSSL is not developed by a responsible team.

Печально, что такие безответственные люди разрабатывают одну из важнейших библиотек (и дело даже не в криптографии – скажем, даже в нынешнем виде OpenSSL вполне мог бы удовлетворять российским сертификационным требованиям для класса КС1 или даже КС2).

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).

Бритоголовый и С1-97

Про названия

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

http://www.tasteofthai.ru/tom-kha/

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

Калган (”галангал”), кстати, в Европе в свое время называли “русским корнем” – потому что он попадал в Европу через Китай и далее через Россию, а у нас его использовали для ароматизации пряников, браги, сбитня и кваса. Зачем тут нерусское название?

Лично мне кажется, что все эти лемонграссы с каффир-лаймами происходят от безграмотности. Прочитал английские буковки, криво передал звучание на русском – и все, перевод готов. Хау ду ю финк, из зыс э транслейшен ор нот?

Запись опубликована в блоге Шуры Люберецкого. Вы можете оставлять свои комментарии там, используя свое имя пользователя из ЖЖ (вход по OpenID).