Linux *

Измерение времени — очень сложная задача. Я выяснил это, набив шишки при попытке запрограммировать расширяемый хронометр для небесных тел Солнечной системы. Сложность в том, что все календарные системы имеют так много правил и исключений, что сборщик календаря, по сути, становится ещё одним языком программирования. Впрочем, мне хорошо знаком закон Завински*, поэтому я постарался избежать создания ещё одного Emacs.

^{*Закон Завински — выдуманный закон computer science, высмеивающий неизбежное разрастание фич. Он гласит, что каждая программа рано или поздно постарается прочитать электронную почту. Стоит отметить, что закон сформулирован в 90-х, поэтому и речь об электронной почте. Кстати, я нашёл хороший веб-сайт с другими законами computer science.}

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

Y2K, Y2038 и другие баги Y2xx — это на самом деле не совсем «баги», а простые переполнения выделенного пространства памяти. Unix и подобные ему компьютерные системы измеряют время, выполняя инкремент секунд в единой целочисленной переменной time_t. Естественно, такой хронометраж назван временем Unix, а 0 в нём означает полночь 1 января 1970 года.

В разных реализациях времени Unix для time_t используются разные типы данных. Когда тип данных достигает своего верхнего предела, он «сбрасывается» или до обратного (отрицательного) значения, или до нуля. В текущей основной ветви ядра Linux используются 64-битные числа со знаком. В таком решении точка сброса приходится на 292 277 026 596 год. Он настанет примерно через 292 миллиарда 277 миллионов 24 тысяч лет.

Но что потом?

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

Подарили мне как то YubiKey 5C Nano. Попользовался пару дней и захотелось автоматизировать работу с ним.

Когда счастливый и довольный достиг того, чего хотел — вкатился в Linux‑разработку. Но получил не совсем то, чего хотел. Или хотел, но еще не понял, что хотел.

Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL. Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом).

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

Disclaimer:
Материал не является сборником best practices и не претендует на фундаментальный труд. Это шпаргалка. Если угодно - application note в свободной форме. Основная задача материала - "сделать короткую статью, которая помогла бы лично мне быстро разобраться, если бы я впервые столкнулся с темой". Если вы знаете что-то лучше - дополнения и замечания по существу приветствуются. Мотивацией для написания послужила недавно встреченная статья, которая как раз объясняла эти аспекты не очень хорошо.

Продолжим знакомство с svg-виджетами для tcl/tk. Напомним, что рассматриваемые примеры, сам пакет svgwidgets и интерпретаторы tcl/tk с необходимыми пакетами можно найти на github-е. После выхода первой статьи все они претерпели изменения. Начнем мы статью с примера скрипт_button_PACK.tcl:

$/usr/local/bin64/tclexecomp140_svg_Linux64 скрипт_button_PACK.tcl

Материал подготовлен на основе выступления с CppCon 2015 "Greg Law: Give me 15 minutes & I'll change your view of GDB" (доступно по ссылке ). Многие моменты я изменял и корректировал, поэтому учтите, что перевод достаточно вольный.

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

В статье будет рассматриваться отладка кода на C в ОС Linux.

Всем привет! Мы продолжаем нашу серию статей по созданию собственного SSO. В этой статье мы увидим итоговый проект и разберём самые интересные решения из него. Подумаем над безопасностью приложения и настроим защиту от XSS и CSRF атак, а также изучим разные Security Headers. В заключение статьи мы создадим собственый Grant Type.

Что касается абсолютного большинства устройств, поддерживаемых в ядре Linux, от вас не требуется почти никакого вмешательства, чтобы пустить их в работу. Пожалуй, устройство потребуется включить (например, при помощи регулятора), отменить команду сброса или обратиться к нескольким конфигурационным регистрам. Но среди устройств есть и достаточно сложные; чтобы в полной мере использовать имеющиеся в них функции или добавлять собственные, для таких устройств требуется специализированная прошивка. Некоторые подобные устройства изначально рассчитаны на подключение заранее запрограммированной персистентной памяти, но в других предусматривается механизм, получающий им подтягивать прошивку из какого-либо приложения. Есть даже такие устройства, в которых одновременно предоставляются обе эти возможности.

Почти у каждого есть старый ПК или ноутбук, который и выбросить жалко, и использовать не получается. Как правило такие девайсы не могут нормально работать из-за старого процессора, малого объема ОЗУ и прочих проблем. Особенно много такой техники бывает на складах у компаний.

Один из вариантов нормальной эксплуатации подобного оборудования — установка специализированных дистрибутивов Linux, которым для работы не нужен большой объем ОЗУ и быстрый процессор. Одна из таких сборок —  postmarketOS.

Меня зовут Максим, я ведущий разработчик в VK. Занимаюсь инфраструктурой доставки электронной почты в проекте Mail.ru. Наша команда разработала и довела до эксплуатации файловую систему (ФС) на FUSE в рамках проекта распределённой почтовой очереди. В проекте требовалось реализовать сетевую ФС, которая сохраняет данные в трёх копиях, в разных ЦОДах. Цель — повысить отказоустойчивость, чтобы даже полный выход из строя одного ЦОДа не приводил к нарушениям SLA. Эта статья для всех, кто интересуется файловыми системами и хранением данных. Мы обсудим:

- зачем писать свою ФС;

- как написать свою ФС с помощью фреймворка FUSE;

- какие подводные камни есть у эксплуатации FUSE в production.

Эта статья — результат трёх лет разработки ФС. Сейчас самое время заварить чай, рассказ будет долгим. 

Привет, Хабр! Наша инициативная группа приступила к работе над интересным проектом, который претендует на определенную значимость в масштабе отечественной ИТ-индустрии. Речь идет об универсальном веб-инструментарии для централизованного управления разнородными службами каталогов для крупных холдингов и корпораций, будь то Microsoft Active Directory (MS AD), либо службы каталогов, основанные на Samba DC или FreeIPA. Разрабатываемое решение позволит осуществлять управление наиболее востребованными функциями из единой точки доступа вне зависимости от типа используемых в доменах служб каталогов.

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

И вот, тогда я узнал об одной прекрасной утилите - Android Debug Bridge, ADB. Прекрасный инструмент для работы с Android - подключил телефон, и занимайся чем хочешь. Но иногда так лень запоминать разные команды, вводить их каждый раз... Вот здесь на помощь приходит Python. Прекрасный язык с большими возможностями.

В этой статье я рассмотрю как работать с ADB через python.

Если вы - разработчик или тестировщик приложений для Android, просто обычный программист или юзер - то вы попали по адресу.

Всем привет! Меня зовут Михаил, я разработчик в команде, которая создает ОС Astra Linux.

Тема логирования в дистрибутивах Linux всегда живо обсуждается как среди наших клиентов и партнёров, так и внутри компании.

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

Описанные выше пробелы в знаниях сообщества побудили меня подумать над тем, как помочь коллегам сориентироваться в непростом хитросплетении путей, по которым запись лога проходит от исходной программы до конечного файла. Так мне пришла идея написать цикл статей, посвященный логированию в операционной системе Astra Linux Special Edition.

Несколько дней назад компания Canonical представила новый релиз одного из своих дистрибутивов. Речь идет об операционной системе Ubuntu Core 24, которая предназначена для IoT-устройств. Это LTS-дистрибутив со сроком поддержки в 12 лет. В нем немало важных нововведений, изменений, о которых многим читателям Хабра будет полезно узнать. Подробности — под катом.

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

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

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

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

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

Покуда разработчики по прежнему пытаются использовать mmap в новых СУБД, мы написали эту статью, чтобы предупредить остальных, что mmap это не подходящая замена привычному буферу. Далее мы обсудим основные недостатки mmap, а также покажем явные ограничения производительности, которые мы обнаружили в наших экспериментах. На основании этих находок мы поделимся рецептами, когда разработчикам СУБД следует избегать mmap для реализации файлового ввода/вывода.