«на русской сцене мы удивляем друг друга тем, что вообще что-то делаем», © manwe
(из статуса SCRIMERS на demoscene.ru/forum)

Пятиминутка мета: в этом тексте вам, котятки, предстоит прочитать о том, как потратить свое время совершенно неэффективно с точки зрения отношения размера полученного продукта к потраченным времени и усилиям.
Предположим, что мы хотим сделать что-нибудь эдакое, например, интру размером до 4кб, но мы нищеброды, и у нас нет денег на виндовс и видеокарту с шейдерами, поддерживающими ветвления. Или мы просто не хотим брать стандартный набор из apack/crinkler/sonant/4klang/боже-что-там-еще-есть, делать очередную «смотрите все! я тоже умею рэймарчинг дистанс филдс!» и теряться среди десятков-сотен таких же. Ну или же мы просто любим выпендриваться как попало в надежде, что девочки на нас наконец-то обратят внимание.

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

Итак, в прошлом посте, который был посвящен гарантиям в договоре на разработку ПО, я остановился на гарантии работоспособности («Warranty of functionality»). Я предлагаю продолжить этот увлекательный экскурс по миру гарантийных обязательств и рассмотреть особенности использования гарантии соблюдения прав третьих лиц «Infringement Warranty».

В современном мире защита прав интеллектуальной собственности весьма актуальна. Вот и Заказчик, начитавшись новостей про многомиллионные иски правообладателей ИС-прав к нарушителям, интересуется: «нет ли при разработке рисков, связанных с нарушением прав третьих лиц?» и «кто в ответе за это нарушение?».

В контракте на разработку ПО порядок этих правоотношений описывается посредством «Infringement Warranty». Суть этой гарантии заключается в том, что при разработке и дальнейшей передаче заказчику исключительных прав на использование ПО, разработчиком умышленно не будут нарушены авторские, патентные и любые иные права третьих лиц.

Для начала простой пример из жизни. Детство и глубокая юность, когда любая мотивация выражается только лишь словом «хочу». Она еще не подкреплена знаниями и возможностями для достижения нужной цели, которые из-за этого кажутся недостижимыми. Взрослая жизнь, когда воплотить почти любую юношескую мечту (в разумных пределах) так же легко, как просто щелкнуть пальцами. Теперь когда «те» цели уже достигнуты, они не кажутся такими недостижимыми, но теперешние цели как раз наоборот, запредельны. Но как только мы покоряем новую вершину, то начинаем теряться в недоумении: «Ну почему я раньше думал что это, если не невозможно, то уж слишком трудно и сложно, чтобы я(!) смог это осилить?»

Интересно? Велкам под «кат».

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

Естественно я сделал его в виде подключаемого файла для сборки в wix. Получилась ситуация что часть модулей в различных инсталяциях имеет одинаковый ComponentId.
Вроде как это допускается, поскольку у продуктов разный ProductId/UpgradeCode, а отслеживание компонентов ведется по связке ProductId.ComponentId. Это специально уточнялось в свое время в одном из блогов разработчика Wix.

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

Технология Windows Installer (MSI) является стандартом де-факто в мире системных администраторов, занимающихся распространением и поддержкой программного обеспечения для десктопных и серверных версий Windows. Формат MSI поддерживается всеми крупнейшими системами управления конфигурациями (Microsoft SCCM, CA Unicenter и многими другими), а для некоторых систем распространения ПО — является единственным поддерживаемым форматом.
Мой опыт работы с этой технологией — как теоретический, так и практический — приобретен за время работы в компании «Инфопульс Украина» и связан с созданием MSI-пакетов и подготовкой готовых MSI-пакетов к автоматической установке в корпоративной среде.

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

Новости из мира науки: матрицы размера теперь умеют умножать за . Другими словами, доказано, что , где  — экспонента умножения матриц. Доказала это совсем недавно Вирджиния Василевска-Вильямс, улучшив тем самым оценку , полученную Копперсмитом и Виноградом в 1987 году. Я напишу про важность этого алгоритма совсем немножко. Тем, кому интересно узнать побольше, предлагается почитать посты Скотта Ааронсона, Ричарда Липтона и Билла Гасарша.

Итак, многие теоретические верхние оценки на время работы алгоритмов используют экспоненту умножения матриц. В частности, много алгоритмов на графах эксплуатируют данную идею: если A — матрица смежности графа, то  — количество (не обязательно простых!) путей длины k между вершинами i и j. Эта простая идея позволяет за время проверить, есть ли в графе треугольник (3-клика): нужно возвести матрицу смежности в куб (для этого потребуется два умножения матриц) и посмотреть на диагональ. Отметим, что речь здесь именно о теоретических оценках, поскольку продвинутые алгоритмы умножения матриц хоть и обгоняют асимптотически простой кубический алгоритм, но на практике дают ускорение только на огромных размерах матриц.

Ещё несколько примеров:

Предстала на первый взгляд тривиальная задача: написать скрипт с различными опциями при запуске. Допустим нужно обработать всего две опции: name и dir. И задача действительно тривиальна при условии, что опции у нас короткие. Но если есть жгучее желание использовать длинные опции, то пиши пропало: getopts, который планировалось использовать изначально, в bash совсем на это не годится.

Недавно задался вопросом ведения документации по исходному коду и сборки её используя Doxygen и CMake. Столкнулся сразу с неприятной проблемой. Дело в том, что в своих проектах я использую следующую структуру:

  build/
  src/
  CMakeLists.txt
  Doxyfile

Сборка, в моём случае, происходит в каталоге build. Но сборка может быть выполнена из любого места. Так вот, если изменить каталог сборки, документация не будет собрана, т.к. Doxygen не найдет исходников по которым нужно собрать эту самую документацию. Тогда то я и задумался, как же управлять процессом сборки документации в связке CMake и Doxygen? Что если мне нужно получить несколько видов документации: пользователя и разработчика? Держать два файла конфигурации для Doxygen? Мне такой вариант не нравится, т.к. файлы будут отличаться значением только одной переменной ENABLED_SECTIONS. Ниже я расскажу о там как можно управлять сборкой документации.

Вы наконец-то можете сделать кое-что со своим старым LCD монитором, который завалялся у Вас в гараже. Превратите его в шпионский монитор! Для всех вокруг он будет выглядеть просто белым экраном, но не для Вас, потому что у Вас будут специальные «волшебные» очки.

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

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

В предверии начала работы климатического саммита ООН хакеры опубликовали переписку членов Межправительственной группы экспертов по изменению климата (Intergovernmental Panel on Climate Change — IPCC), смысл которой заключается в следующем: борьба с глобальным потеплением ведется путем агрессивных инвестиций невероятных размеров в энергетические компании, которые и должны привести выбросы парниковых газов к приемлемому уровню, что, как утверждается, положит начало позитивным изменениям в климате. В частности, хакер(ы) утверждают, что, согласно переписке IPCC, мир должен инвестировать до 2030 года 37$ триллионов в бизнес энергетических компаний и энергосберегающие технологии, что приведет к глобальной нищете, при том, что факт вредного влияния выбросов не признан безусловным фактором изменения климата.

Доброго времени суток, уважаемое Хабрасообщество.
Недавно приходилось наблюдать дискуссию о каррировании и частичном применении. Суть этой полемики состояла в том, что лучше, для практических целей, иметь в языке программирования: встроенное частичное применение (например, как в Nemerle) или встроенное каррирование (как, например, в Haskell).

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

Алгоритм LZW

Алгоритм Лемпеля — Зива — Велча (Lempel-Ziv-Welch, LZW) — это универсальный алгоритм сжатия данных без потерь.

Программы на C++ используют под локальные и временные переменные так называемую автоматическую память (automatic storage). Обычно автоматическая память реализована поверх стека программы, поэтому ее называют стековой. Ее большой плюс – выделение и освобождение памяти выполняется крайне быстро (обычно одна инструкция процессора). Ее большой минус – относительно небольшой объем, попытка выделить память сверх этого объема приводит к так называемому переполнению стека и тогда программа аварийно останавливается.

Из этого вытекает ограничение – нельзя пытаться выделить на стеке слишком много памяти. Слишком много? Сколько это? Ответ не так очевиден, как можно подумать на первый взгляд.

Организация Common Crawl сделала щедрый подарок разработчикам и компаниям, которые работают в области поиска и обработки информации. В открытый доступ на Amazon S3 выложен индекс из 5 миллиардов веб-страниц с метаданными, PageRank и графом гиперссылок.

Если вы видели в логах веб-сервера CCBot/1.0, то это их краулер. Некоммерческая организация Common Crawl выступает за свободу информации и поставила целью сделать общедоступный поисковый индекс, который будет доступен каждому разработчику или стартапу. Предполагается, что это приведёт к созданию целой плеяды инновационных веб-сервисов.

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

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

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

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

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

Перехватить функции open, mmap и прочие невозможно, так как ld.so слинкован с библиотекой си статически, исполняемые файлы, загруженные же своим загрузчиком, «неполноценны» (даже с перехватом функций в libdl): они не регистрируются в списке загруженных библиотек и/или их символы не видны через dlsym. Следовательно, остается только перехват системных вызовов.

Изначально пост планировалось посвятить ошибке 64х-битового компилятора xlc которую я безуспешно отлавливал многие часы и которая имеет место быть на серверах фирмы IBM архитектуры AIX. Но так уж получилось, что подобная ошибка затрагивает многие компиляторы, не стал исключением и Visual Studio 2010 с установленным пакетом обновления SP1. Что в итоге кажется забавным, так как наводит на мысли, что специалисты Microsoft сотрудничают с разработчиками из IBM в деле создания оптимизирующих компиляторов.

Немного предыстории. Есть один научный проект, который был написан на С++ достаточно давно и сейчас успешно переносится на многие платформы, среди которых можно отметить мейнфреймы HP-UX, IBM AIX, Oracle Solaris. Перенос по большому счету состоит в том, что исправляются ошибки времени компиляции, запускается группа тестов и если все тесты проходят, то делается вывод о работоспособности кода.

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

Я бы, конечно, мог попробовать отловить эту ошибку непосредственно на мейнфрейме IBM AIX, будь у меня в запасе достаточно времени, но за отсутствием отладчика (в debug mode ошибка не проявлялась) ловить приходилось по-старинке, методом вставки printf в участки кода. Удаленный доступ к IBM AIX мне так и не дали, приходилось работать непосредственно в дата-центре и за те несколько часов, проведенных за терминалом, ничего внятного понять не удалось, кроме того, что ошибка имеет место быть и достаточно устойчивая. В итоге, ошибка так и сидела в коде на протяжении долгого времени.

Так продолжалось до тех пор, пока я не попробовал перенести код на Visual Studio 2010 SP1.