Вряд ли кто-нибудь слышал об операционной системе DOS-777. А такая реально существовала. Правда, в действительности это была самая обычная MS DOS с незначительными изменениями, предназначенная для работы на единственном компьютере и выполнения одной единственной программы. Своим появлением этот клон в некотором роде обязан проблеме обратной совместимости. Но обо всем по порядку.

Новая и важная программа вдруг повела себя совершенно загадочным образом. Это настолько взбесило ее авторов, что было решено дисассемблировать MS DOS, разобраться в нюансах ее работы и найти причины странных ошибок. Сейчас, даже в запальчивости, вряд ли кто-то решится дисассемблировать, например, Windows-10 и разобраться во всех ее особенностях. Но тогда, в начале 90-х, когда ОС представляла собой три сравнительно небольших файла, их дисассемблирование и анализ заняли недели две.

Уважаемые граждане России! Дорогие друзья!

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

Я имею самый обычный рабочий график: 5/2, 8ч/день. В настоящий момент удаленно учусь в аспирантуре (коронавирус, все дела) и единственный день, когда я могу вдоволь почувствовать себя человеком-соседом и поделать что-то по дому, – это суббота. Как вы понимаете, здесь что-то пошло не так и вместо обещанных будничных пар, которые должны были проходить по вечерам после работы, нам утрамбовали всю субботу. Но дела ведь себя не переделают, поэтому решено было написать на python простого бота-кликера, который мог бы заходить на пару, стартовать запись экрана со звуком, ожидать окончания пары, выключать записть и выходить с пары.

Я, Георгий Меликов, являюсь контрибьютором проектов OpenZFS и ZFS on Linux. Также я занимаюсь разработкой IaaS в команде облачной платформы Mail.ru Cloud Solutions. Хотя в продакшене нашего подразделения мы и не используем ZFS, но хозяева подкаста SDCast пригласили меня рассказать именно о нём. Из выпуска и родилась эта статья, а вот тут можно послушать аудиоверсию.

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

Дисклеймер: это сценарий идеального технического собеседования в Delivery Club Tech. Мнение нашей команды может не совпадать с мнением читателей.

1. Собесы бывают разные: жёлтые, зелёные, красные (лирическое отступление)

1. Логироваться должны сведения обо всех процессах, даже о короткоживущих.
2. У нас должны быть сведения о полном пути к исполняемому файлу для всех запущенных процессов.
3. У нас, в пределах разумного, не должно возникать необходимости в модификации или перекомпиляции нашего кода для разных версий ядра.
4. Дополнительное требование: если хост-система является узлом Kubernetes или использует Docker, то у нас должна быть возможность определить то, к какому именно поду/контейнеру принадлежит процесс. Для этого обычно достаточно знать cgroup ID процесса. Дело в том, что с точки зрения ядра нет такого понятия, как «контейнер» или «идентификатор контейнера». Ядро оперирует лишь такими понятиями, как «контрольные группы», «сетевые пространства имён», «пространства имён процессов», оно работает с различными независимыми API, с помощью которых средства контейнеризации вроде Docker реализуют механизмы контейнеризации. Если попытаться идентифицировать контейнеры посредством ID уровня ядра, нужен уникальный идентификатор контейнера. В случае с Docker данному требованию удовлетворяют идентификаторы контрольных групп.

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

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

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

Это вторая часть расшифровки доклада Ивана Углянского (dbg_nsk) с JPoint 2020, посвященного связи Java с нативным кодом. В прошлой части мы поговорили про традиционный способ связи — через Java Native Interface (JNI), рассмотрели специфичные ему проблемы и оценили производительность. Картина получилась удручающей, поэтому давайте разбираться, чем можно заменить JNI?

Java и другие управляемые языки просты и удобны во многих случаях, но иногда их возможностей недостаточно — например, если нужна библиотека, написанная только на C или C++. Иногда хочется позвать пару методов из системного API, или попытаться улучшить производительность для модуля — и тогда прямой путь в нативный код.

Но тут возникают подводные камни: написать нативный метод и вызвать библиотеку может быть и легко, но JVM начинает крашиться в случайных местах, производительность падает, сборщик мусора перестает справляться с работой, а в репозитории царствуют бесконечные C-шные файлы с буквами JNI. Что же могло пойти не так?

Иван Углянский (dbg_nsk) из Huawei разбирается со всем по порядку: что необычного в интеропе между Java и нативным кодом, как оно работало раньше и что нужно делать для их нормальной совместной работы (и можно ли это вообще сделать). Иван рассказывает, как избежать просадок производительности, внезапных OOM и размышляет на тему будущего — в контексте проектов Panama и Sulong.

Мы подготовили текстовую версию доклада о работе с нативами в Java. В первой части:

• Зачем вообще работать с нативным кодом в Java.
• С какими ошибками и проблемами придётся столкнуться при работе с нативами.

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

Далее — повествование от лица спикера.

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

Нашел на просторах интернета интересную инфографику DevOps Roadmap. Из моего опыта с указанными сервисами и программным обеспечением часто приходится сталкиваться в DevOps практике, поэтому инфографика вполне может быть ориентиром новичкам для становления DevOps инженерами.