Это перевод поста, опубликованного в англоязычном блоге «Лаборатории Касперского».
Он не столько о вирусах, сколько о демосцене и лучших произведениях в этом жанре искусства.

Недавно Евгений Касперский опубликовал в своем блоге запись «Призраки вирус-оперы, или Ситхи Ассемблера», посвященную сверхкомпактным и мощным вредоносным приложениям, обнаруженным недавно, но написанным в стиле 15-летней давности. Мой возраст позволяет помнить этих парней и их блестящую работу – речь ведь не обязательно о создателях вирусов, они были лишь частью программистского сообщества, специализировавшегося на «ручном» написании кода и программировании на ассемблере. Это похоже на Джедаев и Ситхов из мира «Звездных войн» – существ, чье оружие, лазерные мечи, было крайне специфическим и, несмотря на это, воспринималось всеми остальными героями как одно из самых мощных (кроме шуток, спросите Йоду). Увы, похоже, людей, которые помнят этих мастеров-программистов, осталось трое (я, Касперский и Билл Гейтс). А если серьезно – в сегодняшнем мире, где драйвер мышки занимает 50 мегабайт, довольно трудно вообразить, на что способен хакер старой школы при совсем небольшом количестве выделенных ресурсов. Поэтому я решил показать, о чем говорит Евгений, на несколько ином примере – а вы уж решайте, насколько плохи новости об «олдскульных» авторах заразы.

Введение

Добрый день!

В этой статье я хотел бы рассказать о типах областей OSPF. Статьи по настройке OSPF с использованием областей как-то здесь мне уже попадались. Я же хочу рассмотреть, чем эти типы областей отличаются друг от друга: normal, stub, totally stubby, NSSA, totally NSSA. Итак, начнем.

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

Не желая мириться с подобным неудобством для программ, использующих Hunspell словари (FireFox, Seamonkey, Miranda и др.) было принято решение создать автоматическую графическую утилиту для склейки нескольких языков, с возможностью дальнейшего использования полученных словарей.

Здравствуйте. Сегодня на глаза попался пост о курсе программирования под Android на сайте Linux Foundation, а вместе с ним — и немало комментариев о том, что хотелось бы видеть и перевод этих уроков. Поскольку я сейчас, после четырех лет разработки под микроконтроллеры, начал изучать и программирование для мобильных устройств, то параллельно решил сделать перевод первой части урока.

Каждый год 31 декабря David Eppstein публикует обзор препринтов за прошедший год, посвященных структурам данных и алгоритмам, опубликованным на arxiv.org. По ссылкам можно познакомиться с материалами за 2010 и 2011 (мой перевод) годы.

Раздел cs.DS развивается хорошими темпами: в этом году появилось 935 препринтов по алгоритмам и структурам данных, в то время как за 2011 их было 798. Раздел пока не дотягивает до сотни в месяц, хотя в июле (98 препринтов) этот порог был очень близок.

Это мой личный список из десятка препринтов, которые кажутся мне особенно интересными. Как обычно, я не вношу в него мои собственные работы и некоторые другие, о которых я писал раньше. Кроме того, здесь нет результатов (например, более быстрый алгоритм нахождения максимального потока), не появлявшихся на arxiv.org.

Вот они, в хронологическом порядке:

Возможно, вы уже знакомы с обобщёнными константными выражениями. Если нет — можете почитать о них, например, вот здесь). В этой статье я хочу поделиться своим опытом в использовании объединений (unions) в константных выражениях.

Объединения не очень популярны в ООП из-за той бреши в безопасности типов, которую они открывают, но иногда они предоставляют некоторые незаменимые возможности, которые лично я оценил при работе с Fernando Cacciola над черновиком std::optional.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

Понадобилось мне как-то сделать интерфейс для загрузки в микроконтроллер график функции «сопротивление -> температура» (график решили задавать по нескольким точкам, а потом их интерполировать). По ходу дела выяснилось, что график будет оч-чень нелинейным (180 Ом -> 100^o, 6 000 Ом -> 0^o, 30 000 Ом -> -30^o). Поэтому пришлось мне погрузиться в тему логарифмических шкал… и сразу вынырнуть, так как я не нашел того, что мне нужно. А нужно-то мне было всего лишь понять математику (и реализацию на С++) таких дел. ЧуднО — вроде такая нужная тема, а не расписано! Ну да ладно — мозги заскрипели и вспомнили высшую математику из университета, и программа была написана. Решил описать я свои мытарства тут — может, кому пригодится.

В этой статье я распишу теорию (а также базовые виртуальные классы), в следующей возьмусь за конкретные реализации средствами Qt.

Осторожно: в тексте много графики!

Как известно, в программном интерфейсе приложений для магазина Windows (Windows Store apps) отсутствуют многие функции работы с потоками, начиная с CreateThread() и заканчивая работой с TLS ключами. И это отличный повод перейти от параллелизма, основанного на системно-зависимых потоках к параллелизму, основанному на задачах. Данный пост излагает пошаговую инструкцию о том, как написать простейший многопоточный пример, который проходит аттестацию для магазина Windows (Windows App Certification Kit validation) и, гипотетически, может быть масштабирован до игрушек космического масштаба. А поскольку используется кроссплатформенная библиотека Intel Threading Building Blocks (Intel TBB, TBB, threadingbuildingblocks.org), то вычислительная часть может быть легко перенесена на другие платформы, и задача будет заключаться только в том, чтобы нарисовать новый красивый графический интерфейс.

Администраторам Linux писать скрипты на Bash приходится регулярно. Ниже я привожу советы, как можно ускорить эту работу, а также повысить надежность скриптов.

Совет 1

Не пишите скриптов, которые выполняют действия ничего не спрашивая. Такие скрипты нужны довольно редко. А вот всевозможного «добра» для копирования, синхронизации, запуска чего-либо, хоть отбавляй. И если в любимом Midnight Commander Вы вдруг нажали не на тот скрипт, то с системой может произойти все что угодно. Это как правила дорожного движения — «написано кровью».

Совет 2

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

read -n 1 -p "Ты уверен, что хочешь запустить это (y/[a]): " AMSURE 
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2

Команда echo, кстати, здесь нужна потому, что после нажатия кнопки <y> у вас не будет перевода строки, следовательно, следующий любой вывод пойдет в эту же строку.

Совет 3

Это ключевой совет из всех. Для того, чтобы не писать каждый раз одно и то же — пользуйтесь библиотеками функций. Прочитав много статей по Bash, я вынужден констатировать, что этой теме уделяется мало внимания. Возможно в силу очевидности. Однако я считаю необходимым напомнить об этом. Итак.
Заведите свою библиотеку функций, например myfunc.sh и положите ее, например в /usr/bin. При написании скриптов она не только поможет сократить ваш труд, но и позволит одним махом доработать множество скриптов, если Вы улучшите какую-либо функцию.
Например, в свете совета 2 можно написать такую функцию:

У вас в vk.com есть любимые музыкальных группы или друзья, с которыми ваши музыкальные вкусы совпадают? У меня да. И хотелось иметь актуальную локальную копию музыки этих групп и друзей, чтобы слушать её, например в машине, телефоне, плейере или где-нибудь ещё. Так родилась идея создания консольного open source приложения vmd (vkontakte music downloader), которое я обещал выложить на github вот в этом посте. Программа мультиплатформенная работает под linux, windows и mac os x. Скачать бинарные сборки под эти ОС можно скачать на домашней странице проекта. Под хабракатом рассказано, как vmd использовать и некоторые технические подробности.

С незапамятных времен в Visual Studio существовала возможность написания визуализаторов для своих C++ типов, что позволяет изменить способ отображения типов в окнах отображающих содержимое переменных в отладчике (такие как auto, watch, locals и всплывающие подсказки для переменных). В Visual Studio 2012 появилась возможность в расширениях к Visual Studio распространять визуализаторы в новом формате natvis.

Были конвертированы старые визуализаторы для Boost'а и мои старые для TinyXML, а также добавил новые визуализаторы для Boost, wxWidgets и TinyXML2. Получилось в итоге расширение к Visual Studio 2012 — C++ Debugger Visualizers

Несколько лет назад, когда CardBus и FireWire (IEEE 1394) еще были относительно «в ходу», многие производители ноутбуков в своей продукции использовали контроллеры семейства PCIXX21 и PCIXX11 фирмы Texas Instruments: один небольшой чип обеспечивал поддержку не только упомянутых интерфейсов, но и многих популярных стандартов сменных карт памяти.

Такой чип (а именно, PCI7411) стоит и в моей NEC Versa S950. Этот малоизвестный ноутбук я в свое время предпочел даже ThinkPad-серии практически исключительно из-за более лучшей поддержки FreeBSD (оборудования в целом и спящего режима в частности) — специально тестировал в новосибирском Техносити перед покупкой. Долгое время я не пользовался встроенным кард-ридером, по привычке обходясь USB'шными «свистками». Но недавно я обнаружил, что FreeBSD до сих пор его не поддерживает. И если лет пять-шесть назад это можно было объяснить отсутствием нормального драйвера для этих контроллеров (нужно было что-то скачивать и собирать самому), то теперь я точно знал, что они «из коробки» поддерживаются во FreeBSD драйвером sdhci(4), о чем прямо сказано на странице руководства (и позже подтвердилось чтением исходников).

Я начал неспешно гуглить на эту тему, и картина стала вырисовываться невеселая. Оказалось, что таких «счастливчиков», как я, немало. Многие постили в рассылки и форумы «портянки» dmesg и pciconf -lv, заводили баги в трекерах (например, OpenBSD PR i386/5843), но решения никто не предлагал. Более того, фактически поставив точку в вопросе, Александр Мотин, автор драйвера sdhci(4), в 2010 г. написал на форуме, что-де TI документацию на чип не дают, а значит, если производитель сконфигурировал чип неверно, а его настройка через BIOS не предусмотрена, сделать что-либо затруднительно. В свою очередь, Theo de Raadt закрыл i386/5843 со словами: «We do what we can. This vendor, amongst other, have their sdhc controllers locked out and hidden behind little undocumented bits. We've strugged before to find this information, and failed. If you can find this information on some other operating system, or in some vendor documentation, we would be thrilled.»

Вопрос о столах поднимался несколько раз (раз, два).

Однако, на чем же мы сидим перед столом?

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

Все мы работаем с компьютером и порой не замечаем, на чем же мы сидим.

Оказывается наши санитарные правила и нормы (СанПиН 2.2.2/2.4.1340-03) достаточно хорошо описывают удобный эргономичный стул для работы взрослых за компьютером!

А какой стул правильный?