Предлагаю читателям «Хабрахабра» перевод публикации «100 Prisoners Escape Puzzle», которую я нашел на сайте компании DataGenetics. Все ошибки по данной статье присылайте, пожалуйста, в личные сообщения.

По условию задачи в тюрьме находится 100 заключенных, каждый из которых имеет личный номер от 1 до 100. Тюремщик решает дать заключенным шанс на освобождение и предлагает пройти придуманное им испытание. Если все заключенные справятся, то они свободны, если хотя бы один провалится — все умрут.

Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).

Спасение невозможно?

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

Авторитетный веб-ресурс VirusTotal, который является наиболее распространенным сервисом онлайн-проверки файлов и URL-ссылок различными AV-сканерами, внедрил дополнительный механизм уведомления о т. н. false positive. Под этим понятием подразумевается чистый (не зараженный) файл, обнаруживаемый (ошибочно) как вредоносная программа одним или несколькими антивирусными сканерами. Сами false positive являются довольно распространенным явлением и обнаружение с чистого файла может быть убрано вендором за несколько часов, тем не менее, такой подход вводит пользователя в заблуждение.

Статистика вокруг нас

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

Еще будучи студентом психологического факультета СПбГУ, я заинтересовался когнитивной психологией. Кстати, Иммануил Кант не считал психологию наукой, так как не видел возможности применять в ней математические методы. Мои текущие исследования посвящены моделированию психических процессов, и я надеюсь, что такие направления в современной когнитивной психологии, как вычислительные и коннективисткие модели, смягчили бы его отношение!

[FF D8]

Вам когда-нибудь хотелось узнать как устроен jpg-файл? Сейчас разберемся! Прогревайте ваш любимый компилятор и hex-редактор, будем декодировать это:

Специально взял рисунок поменьше. Это знакомый, но сильно пережатый favicon Гугла:

Последующее описание упрощено, и приведенная информация не полная, но зато потом будет легко понять спецификацию.

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

[FF D8] — маркер начала. Он всегда находится в начале всех jpg-файлов.

Следом идут байты [FF FE]. Это маркер, означающий начало секции с комментарием. Следующие 2 байта [00 04] — длина секции (включая эти 2 байта). Значит в следующих двух [3A 29] — сам комментарий. Это коды символов ":" и ")", т.е. обычного смайлика. Вы можете увидеть его в первой строке правой части hex-редактора.

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

Данная статья посвящена оптимизациям компилятора Visual C++. Я собираюсь обсудить наиболее важные техники оптимизаций и решения, которые приходится применить компилятору, чтобы правильно их применить. Моя цель не в том, чтобы рассказать вам как вручную оптимизировать код, а в том, чтобы показать, почему стоит доверять компилятору оптимизировать ваш код самостоятельно.

Посмотрите на это фото.



Это совершенно обычная фотография, найденная в Гугле по запросу «железная дорога». И сама дорога тоже ничем особенным не отличается.

Что будет, если убрать это фото и попросить вас нарисовать железную дорогу по памяти?

Если вы ребенок лет семи, и никогда раньше не учились рисовать, то очень может быть, что у вас получится что-то такое:

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

В прошлой части мы расширяли алгебру и смогли делить на ноль арифметически. В качестве бонуса, способ оказался не единственным. Однако, все эти алгебры не дали ответа на вопрос: “Что там внутри или почему нам это не показывают?”

Пока древние вязали узелки, такой вопрос возникнуть не мог. Сейчас, куда не глянь, “бла-бла, для а≠0”. Значит ответ затаился где-то между узелками и настоящим. В математике все строго и последовательно, а значит и ответ не мог потеряться.

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

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

В тексте выше ключевое слово «если». Что, если компилятор знает, какую функцию на самом деле надо вызывать?

Сейчас один биткоин можно купить всего за 212, а еще вчера покупку можно было совершить по более низкой цене — за 185 долларов США. Таким образом, падение Bitcoin по отношению к доллару всего за месяц составило около 40 процентов.

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

Данный пост продолжает серию из трех статей об оптимизациях для x86 в GCC 5.0. В предыдущей статье речь шла о векторизации. Напомню, что GCC 5.0 находится сейчас в фазе stage3, то есть внедрение новых оптимизаций уже фактически заверешено и уровень производительности за редким исключением останется прежним и в продуктовом релизе. Сегодня речь пойдет об ускорениях позиционно-независимого кода или position independent code (PIC) в 32-битном режиме для x86.

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

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

Мой посыл не в том, что убедить вас отказаться от самостоятельного использования криптографических средств или пойти и нанять консультанта с зарплатой от $1000 в час всякий раз когда вы задумываетесь о шифровании.
Частично я веду к тому, что вам никогда не следует расслабляться, всегда нужно быть начеку, изыскивая пути, которые злоумышленник может использовать для получения дополнительной информации о вашей системе, а частично к тому, что Padding Oracle Attack является крутой демонстрацией всего этого. Итак, начнем.

Часть 1. Вобще-то уже все поделили до нас!
Часть 2. Истина где-то рядом

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

Часть 1

4.2 Разделённое владение shared_ptr

Не у каждого объекта может быть один владелец. Нам надо убедиться, что объект уничтожен и освобождён, когда исчезает последняя ссылка на него. Таким образом, нам необходима модель разделённого владения объектом. Допустим, у нас есть синхронная очередь, sync_queue, для общения между задачами. Отправитель и получатель получают по указателю на sync_queue:

void startup() 
{ 
  sync_queue* p = new sync_queue{200}; // опасность! 
  thread t1 {task1,iqueue,p}; // task1 читает из *iqueue и пишет в *p 
  thread t2 {task2,p,oqueue}; // task2 читает из *p и пишет в *oqueue 
  t1.detach(); 
  t2.detach(); 
} 

Введение. Постановка вопроса.

В школьной программе, к сожалению, сферическую геометрию и геометрию Лобачевского не изучают. Тем временем, их изучение совместно с Евклидовой геометрией, позволяет глубже понять происходящее с объектами. Например, понять связь правильных многогранников с разбиениями сферы, разбиениями плоскости Евклида и разбиениями плоскости Лобачевского.
Знания геометрии пространств постоянной кривизны помогает подниматься над трёхмерием и выявлять многогранники в пространствах размерности 4 и выше. Вопросы нахождения многогранников, нахождения разбиений пространств постоянной кривизны, вывода формулы двугранного угла правильного многогранника в n-мерном пространстве — так тесно переплетены, что выносить всё это в название статьи оказалось проблематично. Пусть в центре внимания будут, всем понятные, правильные многогранники, хотя они не только результат всех выводов, но и, одновременно, инструмент для постижения пространств высших размерностей и равномерно искривлённых пространств.

Для тех кто не знает (забыл) сообщаю (напоминаю), что в привычном нам трёхмерном Евклидовом пространстве всего пять правильных многогранников:

1. Тетраэдр:	2. Куб:	3. Октаэдр:	4. Додекаэдр:	5. Икосаэдр:

Давно хотел написать общую статью, содержащую в себе самые основы Image Recognition, некий гайд по базовым методам, рассказывающий, когда их применять, какие задачи они решают, что возможно сделать вечером на коленке, а о чём лучше и не думать, не имея команды человек в 20.

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

Раз предыдущая статья про банкомат вызвала определённый интерес — то продолжаем банковскую тему. «Пластиковая карта» — обывательское название банковской платежной карты (БПК). Вещь в хозяйстве крайне полезная — ведь её можно прекрасно использовать чтобы ровнять дорожку вырезать из неё отличный медиатор для электрогитары. Но — шутки в сторону — любопытная конкретика…

Никого из нас не удивить банкоматом (АТМ). Даже люди старшего поколения мало-помалу привыкли к этому устройству и свою пенсию в состоянии как-то снять. Однако кроме всего прочего — банкомат – это крайне занятная штука с технической и организационной точки зрения. Даже сотрудники банковских учреждений (в т.ч. и связанных с платежными картами) не всегда представляют себе тонкости его работы. В прошлой жизни я достаточно много лет был связан с платежными картами и обслуживанием банкоматов. Мне доводилось и отогревать его феном и выковыривать оттуда по кусочкам мышь кровь кишки, застрявшую в обнимку с купюрами. Даже спалил один из подконтрольных банкоматов. Дважды. Поэтому поделюсь некоторыми, на мой взгляд, интересными техническими нюансами в работе АТМ.

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

Для рейтинга был найден последний, судя по дате, пост 2013 года. Первый после него пост 2014 года был 11 января. Видимо автор начал писать его до НГ, а потом резко оказалось 11 января после праздников. А вот следующий уже ближе к началу года. В общем, возможно, есть минимальные погрешности.

За 2014 год на Хабре и GT, куда переехали некоторые посты, находится 7672 опубликованные записи. Это примерно 21 пост в сутки.

Из всех этих записей были выбраны 20 топовых по количеству плюсов, 10 антитоповых по количеству минусов, и по 15 интересных записей из разных хабов, где количество постов с рейтингом +20 было более 10. Интерес поста оценивался простой формулой «на глаз». Результат равен рейтингу*5 плюс количество попаданий в избранное*2 и плюс комментарии. Коэффициенты добавлены для того, чтобы минусные посты ушли дальше в минус и, если в них было много комментариев, они не вытеснили интересные посты из топа.

В общем, дайджест топовых, фатальных и интересных постов Хабра за 2014 год под катом.

Соавтор: Святослав Размыслов SvyatoslavMC.

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