В данной статье расскажем про ключевые процессы обслуживания клиентов, и смежные процессы управления — контроль качества и аналитику. Основной акцент сделаем на искусственном интеллекте. Рассмотрим также речевые технологии, вскользь коснемся классических подходов к построению автоматических сервисов.
Повышение привилегий через Disk Group — это метод, при котором злоумышленники используют членство в группе управления дисками в системах Linux. Основной целью таких атак является диск /dev/sda — основной жесткий диск. Атакующие пытаются использовать ошибки в настройках или уязвимости, чтобы получить доступ к данным и повысить свои права в системе.
Вопрос: В декабре 2024 года на полях открытой конференции ИСП РАН вы получили награду в номинации «Лучшая командная работа по статическому анализу» от ФСТЭК России и Центра исследований безопасности системного ПО ИСП РАН. Расскажите об этой награде и о вашей команде.
Николай Костригин: С 2021 года при координации со стороны Института системного программирования РАН ведется работа по проверке свободного программного кода. В деятельности Консорциума сейчас участвуют более 60 организаций — это и институты, и коммерческие компании. Мы подключились с самого начала.
Всё это делается с целью повышения доверия к программным компонентам, которые в мировом сообществе признаны критическими.
Награждение в этом году происходило впервые, это подведение первых итогов деятельности Консорциума.
Вопрос: Кто входит в Консорциум и какую он роль играет в обеспечении безопасности ПО?
Н. Костригин: Основная роль Консорциума — организационная, координационная. Через Консорциум распределяются задачи, можно отслеживать, чтобы не было дублирования, когда мы что-то проверяем по собственной инициативе. Также Консорциум накапливает и систематизирует экспертизу в области проведения исследований. Она становится доступной участникам при присоединении.
Работа по повышению безопасности отечественного ПО строится на совместных исследованиях, обмене результатами анализа, доработке и освоении новых инструментов выявления уязвимостей.
Чтобы дать собеседнику представление о масштабах проблемы лежащей перед исследователями безопасности ПО, довольно часто прибегаю к количественному описанию GNU/Linux дистрибутива: в репозиторий свободного ПО входят десятки тысяч бинарных пакетов. В дистрибутиве, который включает около двух-трех тысяч пакетов, на поверхности атаки оказываются десятки пакетов.
Давно хотели научиться работать с Wine в Linux или Mac Для запуска Windows приложений? Мой обзор-гайд для вас. Я в подробностях расскажу о том как запускать прилоежния, дебажить их, решать проблемы и покажу различные wine-loaders для работы.
Приятным событием на этой неделе стала покупка нового телевизора. Гуляя по магазину и любуясь ценниками, я заметил, что у моделей Philips и AOC в графе операционной системы стоит доселе неизвестная для меня Titan OS. Про Android TV, Tizen и WebOS был наслышан, поэтому подумал, что это просто какой-нибудь переделанный вендором Android, не более. По большому счету мне было все равно: источником изображения я планировал сделать компьютер. В итоге взял Philips 9000er series — UHD 4K телевизор с фирменной подсветкой Ambilight и Mini-LED дисплеем на 144 Hz. Но главное, внутри живет та самая Titan OS. Дальше о ней и расскажу.
Прошел ровно год с момента, когда мир с открытым ртом следил за расследованием одного из самых изощрённых бэкдоров в истории Linux. История с библиотекой xz Utils напоминала триллер: внедрение под реальным именем, доверие сообщества, закладки в коде — и случайное обнаружение в самый обычный рабочий день.
29 марта 2024 года программист Андрес Фройнд проснулся, как обычно, рано. На кухне уже фыркала кофемашина, а ноутбук мигал знакомым индикатором обновлений. Андрес любил утренние часы: пока город только-только просыпался, он уже погружался в привычную рутину — тесты, логи, графики загрузки процессора.
Утром он запустил стандартный набор тестов. Всё выглядело штатно: графики ровные, CPU не перегружен, багов не видно. И вдруг — странность. Незначительная ошибка, но не из тех, что просто игнорируешь. Андрес нахмурился. «Что это было?» — пробормотал он. Он подключился по SSH к серверу, чтобы проверить детали, и заметил ещё одно отклонение: задержка отклика в 500 миллисекунд. Полсекунды. Для большинства — ерунда. Но для Андреса — первый тревожный звонок. Он начал копать глубже.
Не так давно ко мне в руки попала игровая ретро-консоль и у меня возникло желание написать для неё свою игру. А возникало ли у вас желание написать свою игру под игровую консоль?
Сколько себя помню, меня всегда привлекали счётчики памяти в Linux: смотришь в условный htop – в плане потребления CPU вроде всё +/- понятно, а вот память всегда считалась как-то не так, как ты это на первый взгляд ожидаешь, и долгое время у меня было довольно наивное и ошибочное представление о механизмах её работы.
Со временем некоторые вещи прояснялись, приходило понимание, как именно оно работает под капотом (до определённой степени). В какой-то момент возникла рабочая необходимость понять, куда уходит память на реальной системе – и этот случай в очередной раз показал, что местами оно устроено довольно неочевидно, и на этот вопрос не всегда просто дать ответ. Ну а помимо рабочей необходимости у меня дома давно стоит сервер, обвешанный метриками, и всегда хотелось высветить себе их в понятной форме, чтобы потом в реальном времени наблюдать, как ведёт себя система, когда в ней происходят те или иные процессы.
В этой статье я попробую разобрать, как сделать такой мониторинг и как интерпретировать его результаты. Сразу оговорюсь, что никогда не занимался разработкой ядра – вся информация ниже исключительно из личного опыта, поверхностного чтения исходников ядра и обильного гугления. Поэтому не исключено, что где-то могу быть неточным или вовсе неправым, но будем надеяться, что не сильно.
Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.
Все они позволяют организовать сборку программных пакетов, релиз пакетов в репозиторий и пр. Большинство систем обладают обширным функционалом, например тот же OBS позволяет собирать как deb пакеты, так и rpm, так и AppImage и т. д. Koji позволяет разбить сборку по разным машинам и управляя билдерами организовать сборку огромного числа тяжелых пакетов, многие комплексы типа OBS и Copr вообще организованы в виде сервисов в сети и позволяют различным пользователям собирать пакеты и публиковать их в публичных репозиториях.
Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?
Объясню - хотелось бы что-то простое в установке и настройке, как например gitea, такое, что можно просто поднять на локальной машине и организовать сборку из проектов, которых не так много и которые не такие монструозные, требующие несколько билдеров.
Двоичная совместимость в Linux омрачена одним аспектом, который часто упускают из виду при рассмотрении выпуска ПО для Linux. В этой статье я расскажу, как можно увидеть этот аспект, как решать эту проблему при выпуске современного ПО и что же именно нужно сделать, чтобы устранить её полностью.
Поскольку прошлая статья про «особенную» Java вызвала интерес, мы решили продолжить праздник. Настало время познакомить разработчиков С# с темной стороной любимой технологии — сегодня шатаем .NET!
Как сделать высоконагруженную систему хранения данных в сжатые сроки? Чтобы она не падала через день, не теряла данные и не поглощала ресурсы, как Гулливер провизию в амбаре лилипутов. А еще нужно реализовать дедупликацию и заложить будущий функционал на этапе создания архитектуры. Неплохо бы и стоимость хранения гигабайта снизить до минимума, а скорость передачи данных наоборот, увеличить до второй космической.
Меня зовут Ростислав, я эксперт по разработке ПО отдела систем обработки данных в YADRO. Расскажу о вкладе нашей команды в разработку TATLIN.BACKUP: как мы с нуля создали дедуплицирующую файловую систему, а также какие вызовы преодолели за два года разработки и 200 тысяч строк кода.
В последнем обновлении нашей кроссплатформенной библиотеки EMX Controls для Avalonia UI мы существенно повысили производительность контролов DataGrid и TreeList. Время создания и отрисовки улучшилось почти в 3 раза, а скорость скроллинга - более чем в 2 раза. В этой статье мы приведем конкретные цифры и подробнее остановимся на подходах, которые позволили нам добиться таких результатов.
Работая над проектом «SVG-виджеты для tckl/tk», я с нетерпением ждал выхода не только релиза Tcl/Tk-9.0, но и выхода интерпретатора tclexecomp с его поддержкой. Релиз Tcl/Tk-9.0 появился в сентябре 2024 года, когда работа над проектом приближалась к завершению. После выхода релиза Tcl/Tk-9.0.0, сразу же появилось желание протестировать свой проект с новым интерпретатором, но я решил дождаться появления и интерпретатора tclexecomp с поддержкой нового релиза Tcl/Tk.
Время шло, на Хабре была выложена финальная статья про svg-виджеты, а tclexecomp на базе Tcl/Tk-9.0 так и не появлялся. В настоящее время уже вышел второй релиз, а именно Tcl/Tk-9.0.1. И тогда было решено воспользоваться советом Ивана Владимировича Мичурина:
Привет! С вами Станислав Ермохин, руководитель группы методического обеспечения в команде КОМПАС-3D. Мы продолжает разработку КОМПАС-3D под ОС на базе ядра Linux. Релиз, который состоится в этом году, все ближе и ближе. Правда, пока нам есть над чем работать, но система уже находится в наиболее стабильном состоянии, когда можно производить нагрузочное тестирование. Окончательными результатами тестирования мы поделимся чуть позже, добавив к ним результаты тестирования от наших пользователей после бета-тестирования.
Привет, меня зовут Андрей, и я написал книгу.
Нет, не о синтаксисе и не про очередной набор «лучших практик».
А о том, что часто остаётся за кадром — в рефлексии, в мыслях после проектов, в спорах между «пишем быстро» и «делаем правильно».
24 марта 2025 года Линус Торвальдс представил первый стабильный релиз ядра Linux 6.14. Выпуск новой версии ядра Linux вышел в соответствии с графиком, спустя два месяца после выхода предыдущей стабильной версии Linux 6.13 в середине января. Выпуск Linux 6.15 ожидается в конце мая или начале июня 2025 года.
Сергей Каличев, старший разработчик, Angie Software
Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.
Для тех, кому удобнее читать в PDF, вот ссылки:
А теперь сама статья.
