Решили мы как-то перевести свой проект на Visual Studio 2015 — там ведь столько захватывающих фич! Вчера вот только решили, а уже сегодня утром я запустил её инсталлятор. Небо было безоблачным, ничто не предвещало беды. Ну что, в самом деле, может пойти не так? Сколько уже этих Visual Studio переставлено — не счесть (я, помнится, ещё 6.0 когда-то ставил). Кто бы мог подумать, что эта тривиальнейшая задача может вылиться в весьма неожиданный забег по граблям длинной почти в целый рабочий день.

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


Хм. Не поставился значит, Team Explorer и ещё пару минорных пакетов. Ну ок. Закрываем, переустанавливаем. Не помогает. Удаляем студию, перезагружаемся, устанавливаем — та же ошибка. Лезем в Гугл с вопросом об ошибке установки Visual Studio 2015 на этапе инсталляции компонента Team Explorer и понимаем, что проблема это массовая — десятки ссылок с тем же описанием:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17

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

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

Нередко у программистов, пишущих драйверы, возникают некоторые трудности с обменом данными в 64-битном формате. Давайте разберём некоторые ситуации.

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

Тем не менее, с появлением libclang, можно писать собственные анализаторы и генераторы кода прямо в compile time, устраняя достаточно большое множество проблем на ранних этапах работы. Сочетание инструментов статического анализа общего плана (coverity, clang-scan), инструментов анализа для конкретного проекта, а также дисциплины написания кода позволяет намного улучшить качество и безопасность кода, написанного на Си. Конечно, это не даст гарантий, каких дает haskell или даже rust, но позволяет существенно оптимизировать процесс разработки, особенно в случае, когда переписывать огромный проект на другом языке является нереальной задачей.

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

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

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

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

От переводчика: представляю вашему вниманию перевод статьи Майкла Штейла. Я давно хотел подготовить подобный обзор методов использования виртуализации для задач обеспечения совместимости. Я даже опубликовал некоторые заметки на эту тему: в учебнике по симуляции, глава 1, и на Хабре в посте про системные ВМ. Однако мне не удалось раскрыть вопрос так глубоко, как он представлен в этой работе. Поэтому я решил поделиться переводом с читателями.

---

Производители операционных систем сталкиваются с этой проблемой один или два раза в десятилетие: им необходимо перевести свою пользовательскую базу со старой операционной системы на их сильно отличающуюся новую ОС, или им требуется перейти с одной архитектуры ЦПУ на другую с сохранением возможности запуска старых приложений без модификаций, а также помочь сторонним разработчикам портировать свои приложения на новую ОС.

Давайте рассмотрим, как это происходило в последние 30 лет, на примерах MS DOS/Windows, Apple Macintosh, Amiga OS и Palm OS.

Доброго времени суток!
Хочу представить вашему вниманию перевод статьи Джонатана Барлетта (Jonathan Bartlett), который является техническим директором в компании New Medio. Статья была опубликована 16 ноября 2004 года на сайте ibm.com и посвящена методам управления памятью. Хотя возраст статьи достаточно высок (по меркам IT), информация в ней является фундаментальной и описывает подходы к распределению памяти, их сильные и слабые стороны. Всё это сопровождается «самопальными» реализациями, для лучшего усвоения материала.

Аннотация от автора
Решения, компромиссы и реализации динамического распределения памяти
Получите представление о методах управления памятью, которые доступны Linux разработчикам. Данные методы не ограничиваются языком C, они также применяются и в других языках программирования. Эта статья даёт подробное описание как происходит управление памятью, на примерах ручного подхода (manually), полуавтоматического (semi-manually) с использованием подсчёта ссылок (referencing count) или пула (pooling) и автоматического при помощи сборщика мусора (garbage collection).

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

Вот о чем речь:

<VirtualHost *:80>
    ServerName host1.example.com
    ServerAdmin webmaster1@example.com
    ServerUserGroup user1 group1
    DocumentRoot /var/www/host1
</VirtualHost>
<VirtualHost *:80>
    ServerName host2.example.com
    ServerAdmin webmaster2@example.com
    ServerUserGroup user2 group2
    DocumentRoot /var/www/host2
</VirtualHost>

При этом корневые директории виртуальных хостов могут быть доступны только соответсвующим пользователям:

# ls -la /var/www
total 16
drwxr-xr-x   4 root  root   4096 Oct 26 16:10 .
drwxr-xr-x  21 root  root   4096 Oct 26 01:13 ..
drwxr-x---   2 user1 group1 4096 Oct 26 16:10 host1
drwxr-x---   2 user1 group2 4096 Oct 26 16:10 host2

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

Не так давно у меня появилась необходимость загружать конфигурацию приложения при очень ограниченных ресурсах. Не было доступа, практически, ни к каким стандартным функциям C. Очень повезло, что были стандартные функции по работе с памятью malloc()/free().

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

Из этого можно сделать вывод, что надо либо:

1. Писать свой редактор бинарного формата.
2. Использовать текстовый формат.

От переводчика. Представляю вашему вниманию перевод поста Майкла Штейла (Michael Steil) http://www.pagetable.com/?p=308. В нём затрагиваются вопросы сомнительной практики именования сущностей в спецификациях вычислительных архитектур.
Эта заметка очень хорошо отражает ситуацию с именами, возникающую в процессе длительной эволюции документации, и моё собственное недоумение, когда я впервые встретился с этими понятиями.
Комментарии к тексту размещены во всплывающих подсказках.

Имеется в виду выполнение записи по аппаратно защищённому от записи адресу памяти в архитектуре x86. И то, как это делается в операционной системе Linux. И, естественно, в режиме ядра Linux, потому как в пользовательском пространстве, такие трюки запрещены. Бывает, знаете ли, непреодолимое желание записать в защищённую область … когда садишься писать вирус или троян…

Описание проблемы

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

• В архитектуре x86 существует защитный механизм, который при попытке записи в защищённые от записи страницы памяти приводит к возбуждению исключения.
• Права доступа к странице (разрешение или запрет записи) описываются битом _PAGE_BIT_RW (1-й) в соответствующей этой странице структуре типа pte_t. Сброс этого бита запрещает запись в страницу.
• Со стороны процессора контролем защитой записи управляет бит X86_CR0_WP (16-й) системного управляющего регистра CR0 — при установленном этом бите попытка записи в защищённую от записи страницу возбуждает исключение этого процессора.

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

Если вам интересно, чем безопасности прошивки могут помочь STM, SGX и PSP — жду вас под катом.

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

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



Ниже под катом — расшифровка нашей беседы для тех, кто видео не очень.

Как синхронизировать параллельные шелл-процессы, используя named pipes (FIFO-файлы) в качестве условных переменных. Как выполнить параллельно зависимые задач в топологическом порядке с минимумом средств: POSIX shell, mkfifo, POSIX kernel. Как параллельный запуск ускоряет загрузку встраиваемых систем и *BSD (rc-этап FreeBSD с 27 до 7 секунд) или старт приложений в пользовательских контейнерах Docker, LXC и jail. Как это повышает аптайм в отказоустойчивых кластерах Jet9.

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



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

Раз в год в Европе проходит событие, которое мечтают посетить все, кто хоть что-то знает про Linux. Событие, которое собирает вокруг себя самое большое сообщество, когда-либо существовавшее на этой планете. Сообщество энтузиастов, хакеров, инженеров, программистов, админов, корпоративных боссов, всех тех, кто имеет работу и хобби благодаря Linux и open source. Мы в НТЦ Метротек привыкли делиться знаниями и получать их, поэтому такое пропустить не могли. Дамы и господа, добро пожаловать в Дублин на тройную конференцию LinuxCon + CloudOpen + Embedded LinuxCon Europe 2015!

Уже в эту среду, 14 октября, в петербургском офисе компании Oracle состоится встреча JUG.ru c Фолькером Симонисом из SAP. Тема встречи — внутреннее устройство SAP JVM.


Наверняка многие из вас слышали про SAP — немецкого гиганта, который делает разные корпоративные системы — бухучёт, контроль за производством, финансы, HR, кадры, управление складом и прочий «Кровавый энтерпрайз», который с большой вероятностью стоит в вашей организации, если ее численность превышает тысячу человек.

Фокус в том, что многие (если не все) из перечисленных решений так или иначе работают на Java, и соответственно внутри них крутится JVM. Прикол в том, что это их собственная JVM. Ну как собственная — в свое время она была лицензирована у Sun вместе с исходниками, из которых и разрабатывалась. В данный момент — она лицензируется у Oracle. Соответственно, это некоторый форк Oracle JDK / JVM со своими косынкой и секретаршами, лицензированный, совместимый и т.д. и т.п.

Однако это не только форк, но и порт, поддерживающий 7 CPU-архитектур: x86, x86_64, SPARC, PowerPC, Itanium, z/Arch and PA-RISC на семи разных операционках: OS X, Windows, Solaris, Linux, AIX, as400 and HP/UX. По заявлению SAP, они поддерживают единую систему конфигурирования, единое поведение, одинаковые плюшки и расширения, инструменты анализа и поддержи на всей этой аццкой комбинации платформ.



Как видно из этой таблички, они до сих пор поддерживают Java с 1.4 до 8 на всех упомянутых платформах. Например, Oracle поддерживает нынче только Java 8, а Azul и Red Hat, как я понимаю, только 6, 7 и 8.

Так вот, у нас большое счастье. В эту среду на питерском JUG Volker Simonis, наш большой друг и разработчик SAP JVM, будет в стандартном двухчасовом формате рассказывать про все это щастье. Он будет выступать на Joker и планировал прилетать в четверг, но мы специально попросили прилететь его на день раньше, чтобы сделать с ним отдельный JVM-ный ивент.

                                                                                    - Что-то беспокоит меня Гондурас...
                                                                                    - Беспокоит? А ты его не чеши.

В предыдущих частях обсуждения (1-я, 2-я и 3-я) мы рассматривали как, используя возможность поменять содержимое sys_call_table, изменить поведение того или иного системного вызова Linux. Сейчас мы продолжим эксперименты в сторону того, можно ли (и как) динамически добавить новый системный вызов в целях вашего программного проекта.

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

Предыдущую часть обсуждения мы завершили на такой вот оптимистической ноте: «Подобным образом мы можем изменить поведение любого системного вызова Linux». И тут я слукавил — любого… да не любого. Исключение составляют (могут составлять) группа сетевых системных вызовов, работающих с BSD сокетами. Когда сталкиваешься с этим артефактом в первый раз — это изрядно озадачивает.

Сегодня я приготовил для вас большое интервью с Андреем Паньгиным aka apangin, ведущим инженером Одноклассников. Андрей больше 6 лет проработал JVM-инженером в Sun Microsystems, в том числе, в команде HotSpot, а последние 5 лет работает в Одноклассниках, решая там вопросы, связанные с JVM и производительностью. Так что Андрей по праву считается одним из сильнейших JVM-щиков в России.



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

Вот о чем мы поговорили с Андреем:

• чего стоит переезд с Java 7 на Java 8;
• что происходит с sun.misc.Unsafe;
• архитектура Одноклассников;
• инженерные компромиссы, шардинг и GC;
• системы хранения данных и Cassandra;
• в чем Одноклассники впереди планеты всей, а чему еще стоит поучиться у Google;
• как стать крутым системным программистом.

(Я знаю, что начало затянутое. Будем работать над тем, чтобы быстрее раскачиваться и входить в тему.)

Для тех, кому опять некогда смотреть видео, под катом расшифровка интервью.