Linux *

Тихо и незаметно вышло в свет ядро Linux 4.4 LTS (Long-Term Support), о чем известил Линус Торвальдс. Новинка включает довольно значительные обновления, включая, например, 3D поддержку виртуальных дравейров GPU. Благодаря этому можно использовать аппаратную поддержку графики в guest VM. Также включена поддержка Open-Channel Solid State Drives (SSDs) посредством LightNVM.

Более того, Linux kernel 4.4 LTS поддерживает RAID5 MD, добавлена возможность непривилегированным пользователям запускать eBPF программы. Также стоит упомянуть поддержку поллинга для улучшения общей производительности high-end устройств хранения данных, mlock2() syscal и многое другое. Улучшена поддержка 64-битных ARM, решена проблема с утечкой памяти в Skylake CPU от Intel. Добавлена возможность работы слушающих TCP-сокетов в неблокирующем режиме, возможность определения потери TCP-пакетов с использованием RACK, добавлен KMS-драйвер для «малинки» (Raspberry Pi), а xconfig переведён на Qt5.

В новой версии принято примерно 13 тысяч исправлений, внесенный 1548 разработчиками. Примерно 44% всех изменений в новой версии ядра связано с драйверами устройств.

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



Статья не претендует на глубину и/или академичность. Это попытка систематизировать опыт и обратить внимание разработчиков на не очень очевидные аспекты.

Привет, Хабр!

Давно не писали про обновления в нашем образовательном проекте Хекслет, а тут как раз Новый год — самое время поделиться хорошими новостями. Мы сделали бесплатным популярный курс «Bash: Основы командной строки»! Это уникальный курс, потому что упражнения в нем (как и везде в Хекслете) выполняются в условиях, приближенных к боевым: вам доступен личный контейнер с root-доступом, в котором среди прочего запущена оболочка Bash.

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

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

Появляется у меня периодически необходимость тестирования большого количества жестких дисков. Обычно для этого используется досовая Victoria загружающаяся по сети. Она тестирует диски по одному, что не очень удобно. К тому же последнее время пошли платы не имеющие режима IDE, что дополнительно усложняет задачу. По началу у меня возникла идея взять готовый софт под линукс с открытыми исходниками и добавить ему возможность параллельного тестирования нескольких дисков. После беглого поиска выяснилось удручающее состояние этой области в линуксе. Из софта, ведущего при тестировании статистику по времени доступа к секторам и типам ошибок нашел только whdd. Попытка разобраться с кодом whdd закончилась полным провалом. Для меня, ни разу не программиста, код показался очень запутанным. К тому же большую его часть занимает совсем не работа с железом.

Поняв, что простого решения не предвидится я решил попробовать написать подобную программу самостоятельно. Понимая, что подобный проект на C я не осилю я начал изучать возможность прямой работы с дисками из python, которым я частенько пользуюсь для решения простых задач и люблю за простоту и понятность. Информации по этому вопросу в сети кот наплакал, но все же я выяснил, что существует модуль fcntl который в том числе позволяет отправлять устройству ioctl запросы. Теперь у меня появилась возможность отправлять команды диску. Но в линуксе все диски считаются scsi дисками, а для тестирования нужно передавать диску непосредственно ata команды. Оказалось существует механизм ATA Command Pass-Through, позволяющий обернуть ata команду в scsi запрос. Основную информацию о том, как это использовать удалось почерпнуть из исходных текстов проекта sg3_utils. Осталось попробовать реализовать это все на питоне.

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

Добрый день.
Хотелось бы поделиться с вами одним интересным моим опытом – Контроллер домена на Linux. В данной статье я скорее всего напишу небольшой мини обзор систем с помощью которых я пытался реализовать альтернативу ActiveDirectory.

Немного истории:
Написано мною в Январе 2009: Вообще я далеко не профи в *nix системах, но всё таки активно интересуюсь и изучаю их. В компании, где я работаю, около 3-4 моих серверов на базе Debian и FreeBSD. Которые выполняют различные задачи для обеспечения основных бизнес процессов компании.
По поводу домена на linux я слышал множество упрёков и похвал. И вот более года назад задался вопросом поднятия домена на Linux. Во первых просто интересно, а во вторых он абсолютно бесплатен, что и требовала компания где я работал. За год перебрал кучу вариантов, кучу сборок. Поднимал в ручную… ldap+samba+krb на BSD и Linux системах. Но мне казалось что всё это не то. Либо безумно неудобно управлять, либо куча лишнего. Куча лишнего было в готовых дистрибутивах (аля-домен за одну минуту.). Было боязно внедрять их в мою не большую и не маленькую компанию(Более 80-100 рабочих станций в одном только офисе). Во первых неизвестно что и как разработчики делали с дистрибутивом, во вторых электронная поддержка на иностранном языке ))) А самому разгребать последствия не хочется.



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