Поддержка inotify появилась в ядре и стандартной библиотеке libc. Приложения могут получать уведомления об изменениях в файловой системе, не открывая каждый отслеживаемый файл. Это упрощает перенос программ, которые используют такой API в Linux; речь о совместимости исходников, а не о гарантированном запуске готовых Linux-приложений.

Для Clang изменили выбор линкера по умолчанию: теперь используется ld.lld вместо поиска линкера по имени ld. В math.h также стали доступны тригонометрические функции стандарта C23 с множителем π, в том числе sinpi и cospi.

Изменения затронули и командную строку. Утилита pwd по умолчанию работает в режиме -L, а не -P, как требует POSIX: при выводе пути сохраняются символические ссылки. Размер истории sh по умолчанию увеличили со 100 до 128 записей. Эти и другие изменения перечислены в примечаниях к выпуску.

Разработчики подчёркивают, что в 14.5 основной акцент сделан на исправлениях и обновлении компонентов. Уже доступны установочные образы и образы виртуальных машин. Поддержка FreeBSD 14.5 продлится до 30 июня 2027 года.

Практическая проблема в том, что Bullseye — не экзотика. Это образы VPS у хостеров, базовые слои Docker-образов, которые никто не пересобирал два года, и «тот сервер, который просто работает». Задача на сентябрь простая: найти их все и решить, куда переезжать.

• LTS Debian 11 длился с 15 августа 2024 по 31 августа 2026 года для amd64, i386, arm64 и armhf; всего Bullseye прожил пять лет.
• С сентября Debian не выпускает для него обновления безопасности; часть пакетов могут поддерживать сторонние компании через платный Extended LTS.
• Debian 12 Bookworm получает LTS до 30 июня 2028 года (amd64, i386, arm64, armhf, ppc64el); Debian 13 Trixie вышел 9 августа 2025 года.
• Проверка одной командой: cat /etc/debian_version, ищите 11.x; в образах — grep по Dockerfile на bullseye.
• Путь обновления: 11, затем 12, затем 13, по одному мажорному шагу, с бэкапом перед каждым.

Чем LTS отличается от обычной поддержки

Стабильный выпуск Debian живёт три года под присмотром команд Security и Release. После этого дистрибутив передают в LTS — проект, который ведут волонтёры и заинтересованные компании, а не основные команды Debian; так описывает его вики проекта. LTS добавляет ещё два года обновлений безопасности, но уже не для всех архитектур и не для всех пакетов. Для Bullseye этот срок закончился.

Starting in September, Debian will not provide further security updates for Debian 11.

После LTS есть ещё одна ступень — Extended LTS. Это не часть Debian: несколько компаний за деньги продолжают чинить ограниченный набор пакетов для клиентов, которым переезд обходится дороже. Полного покрытия там нет, и рассчитывать на него как на бесплатную отсрочку не стоит.

Где искать Bullseye у себя

Три типичных места. Первое: старые VPS и физические серверы, поставленные в 2021–2023 годах. Второе: Docker-образы с базой debian:bullseye, python:3.x-bullseye или node:xx-bullseye, которые собраны один раз и с тех пор только тегаются заново. Третье: встроенные системы и Raspberry Pi, где Raspberry Pi OS на базе Bullseye стоял по умолчанию до конца 2023 года.

Куда обновляться

Прямого пути с 11 на 13 нет: Debian поддерживает обновление только на следующий мажорный выпуск. Значит, сначала bullseye на bookworm, потом при желании bookworm на trixie. Debian 12 Bookworm — безопасный промежуточный вариант: у него LTS до 30 июня 2028 года, а из архитектур в LTS заявлены amd64, i386, arm64, armhf и ppc64el. Для второго шага есть отдельные release notes Trixie. Для Docker-образов проще: сменить тег базового образа на bookworm или trixie и пересобрать.

• Сделайте снимок или бэкап, затем apt update && apt full-upgrade в текущей версии, чтобы уйти с чистой точки.
• Сторонние репозитории (Docker, PostgreSQL, nginx) перед обновлением отключите, как советуют release notes, а после перехода подключите их версии для bookworm.
• Замените bullseye на bookworm в /etc/apt/sources.list и файлах в sources.list.d; для Bookworm секция non-free-firmware добавляется отдельно.
• apt update && apt upgrade --without-new-pkgs, затем apt full-upgrade, перезагрузка, проверка сервисов.
• В CI запретите тег bullseye в базовых образах линтером Dockerfile, чтобы он не вернулся через полгода.

Любое зеркало Debian продолжит раздавать пакеты Bullseye, но новых обновлений безопасности от проекта в них не появится, так что «репозиторий работает» не означает «сервер защищён». При заказе нового VPS выбирайте образы Debian 12 или 13, если хостер ещё предлагает 11.

Что дальше

Следующий такой рубеж — 30 июня 2028 года, когда закончится LTS у Bookworm, то есть меньше чем через два года. Если вы переезжаете сейчас, разумно сразу планировать повтор процедуры к этой дате и держать обновление ОС в регулярном графике, а не как аварийную операцию раз в пять лет.

Источники: Debian 11 Long Term Support reaching end-of-life (Debian News), Debian LTS Wiki, Release notes Debian 12: upgrading

Изображение на обложке: Debian Project

Сразу скажу - я не считаю себя втором Терри Дэвисом и тем более не хочу делать аналог Виндовс. Изначально я все это затеял только ради прикола и изучения ассемблера.

А, и если что - мне 14, но я не против любой критики. И да, я тоже как и большинство местами использовал ИИ. Я не сидел читал мануалы часами, просто гуглил или просил нейронку пояснить.

Так а в чем же проблема x86_64?

Я так скажу - я пробовал писать под эту архитектуру. Мне не понравилось, всякие режимы (которые за меня правда переключал загрузчик), да и местный ассемблер мне было лень изучать. Просто захотел писать под более новую архитектуру.

Не буду говорить, что RISC-V лучшая, но я просто выбрал ее. Прикол в том, что инструкции короткие, да и в целом достаточно перспективно. Хотя и тут были проблемы.

Был драйвер, стала ОС

Я ничего с нуля не писал.Все началось с пыток ИИ, когда я пытался выдавить из него то обращение по конкретному адресу для доступа к графике, то опрос портов, то еще что-то такое. Мне стало лень и я пошел искать что-то плюс-минус готовое. И я нашел его - ramfb. По сути я получил готовый указатель на фреймбуфер для вывода на экран… И все. Но и на этом большое спасибо авторам драйвера. Дальше началась моя ОС.

А где хранить данные?

А тут первая проблема - как таковой кучи у меня еще нету. Есть стек, который за меня выделил автор драйвера. Есть всякие глобальные переменные. Но что если мне нужно много памяти (например, под картинки) и я не знаю точный размер? И в добавок, кто вообще рисует напрямую на экран? Тут нужен некий массив пикселей, который будет лежать в памяти, а по нашей команде быстро перенесется на экран (называется backbuffer).

Под кучу взял 64 мб из памяти, так как Qemu, где запускается моя ОС, выделяет ей аж 128 мб, часть уже занята ядром и стеком, но бОльшая часть пустует. Сделал простенький список свободных и занятых блоков памяти.

Это когда ты делишь память на куски, каждый помечаешь как занятый или свободный. Нужно мало памяти - откусываем от большого куска блок. Блок освободился, а рядом есть другой свободный блок - соединяем в один большой.Сразу же добавил функцию, чтобы узнать сколько памяти занято. Сейчас, например, занято около 3-4 мб. Ну это учитывая, что backbuffer и занял почти 3.5 мб.

В оперативной памяти что-то типа

Такая разная многопоточность

Как я думаю большинство знает, если у процессора одно ядро, одновременно на нем может выполняться только одна задача-поток. Но мы же может останавливать задачу, запускать другую, останавливать, запускать еще другую и так много раз в секунду. Тогда будет казаться, будто бы у нас несколько задач выполняются одновременно.

Многопоточность кооперативная

Так мы можем сказать потокам, чтобы если один из них решит, что стоит сделать паузу, сам вызвал yield() и отдал процессор другому потоку. И я это сделал. Все что нужно было - сохранить s-регистры процессора (те, в которых лежат всякие важные значения), указатель на личный стек потока (размер стека задается при создании) и указатель на “дорогу назад” ra. То есть yield() сохраняет эту информацию потока А, затем вместо нее загружает информацию потока Б. И так по кругу.

Кстати, стеки самих потоков я выделял в той самой куче. Просто брал блок на пару кб и говорил потоку: “Это твой стек”.

Но у такого концепта есть проблема - зависает один поток, остальные перестают выполняться. Да и в целом писать yield() каждый раз сложно.

Многопоточность вытесняющая

Поэтому я и решил переписать все на вытеснение. Для начала я сделал так - каждые 100к тиков процессора сохраняются все регистры и пинается функция обработки прерываний. Таймер, по которому будет работать многопоточность - это тоже прерывание. Так же эта функция ловит ошибки по типу kernel panic. Это было сложнее - так как потоки не добровольно отдают процессор, приходится сохранять вообще все 32 регистра. Но криво-косо я написал это и функцию sleep(), во время которой функция простаивает, ее никто не трогает.

А тут еще и ИИ начал выдавать бред, пока я тестировал у меня… начинал выполняться основной код, все было хорошо, а потоки - нет. Я сам не вижу ошибку, ИИ тоже. Он то предложит заменить какую-то часть функции, то еще что-то такое. Наконец я вспомнил про замечательную штуку - gdb. Запустил, посмотрел… Оказалось так - цикл отрисовки экрана был слишком долгим, во время него вызывалось переключение потоков, а их еще не было кроме главного. В итоге я подумал что смысла создавать потоки в конце, после отрисовки, нет, и перенес их в самое начало. Удивительно, но все заработало.

Немного про режимы

Как выяснилось, в RISC-V есть 3 режима (точнее 4, включая гипервизор, но тут он мне точно не нужен) - M-mode с полными привелегиями, S-mode для ядра ОС (я думал что и мое его использует), ну и U-mode для пользователей, но до этого мои ручки еще не дошли.

Ну и по пути я случайно осознал, что мое ядро выполняется аж в М-режиме:

Вызываю я ecall из потока. Смотрю - kernel panic. В логах какой-то код “11”. Оказалось, это и есть ecall - в M-mode он 11, а в S-mode (в котором, как я думал, работало ядро, и который я пытался выловить) это 9. Ну когда я нашел, уже быстро исправил.

Визуальчик

Но в это время на сам экран эмулятора Qemu… Ничего и не выводилось. Совсем. Просто белый экран. Хотелось красоты.

Тогда я вспомнил, что день назад прикрутил qoi.h к моему коду. QOI - формат изображений. Выбрал я его, так как декодер легкий и его удобно использовать в любой ОС, где есть базовые функции.

Я аккуратно, разумеется, согласно лицензии, взял из pop os, которой когда-то пользовался, картинку для фона. Конвертировал ее в .qoi, а так как моя ос еще не умела читать с диска, перевел картинку в заголовочный файл .h. Весит правда много, но влезает.

Дальше я нашел шрифт (Liberation Mono от Red Hat), перегнал и его в .h. Честно, визуал меня не сильно интересовал, поэтому быстро попросил ИИ переделать функции вывода в консоль в функции вывода на экран. Проверил, просмотрел что и как сделано, получилось нормально для старта. Правда пока что в графической консоли нет нормальной перемотки и много чего другого.

Вывод

Конечно, еще нету даже ввода с клавиатуры, мыши, файловой системы (даже простой). Но я считаю, что вышло неплохо, пусть и далеко от уровня реальной ОС типа Линукса. Понятно, что код не очень-то красивый, достаточно простой. Статью я выкладываю больше просто чтобы разобраться самому в том, что я написал.

Если я не забью на код, хотел бы написать еще и MMU и переход в U-mode.

Для тех кому очень интересно - можете глянуть исходный код mqos, там же будут инструкции по запуску.

На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

Главное преимущество языка в ядерной разработке — владение и типизация, которые убирают массу мелких ошибок: непроверенные указатели, забытые разблокировки, неправильная очистка ресурсов. Именно такие баги, по словам Кроах-Хартмана, составляют большинство ежедневных CVE.

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

Это означает, что Rust станет фундаментом не только для экспериментальных модулей, но и для ключевой инфраструктуры мобильной экосистемы.

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

Позиция Кроах-Хартмана — ещё один сигнал того, что Rust перешёл из разряда «перспективного языка» в разряд инфраструктурного инструмента. Если оценка в 80% CVE верна, массовый переход на Rust в ядре может существенно снизить количество исправлений безопасности и освободить время мейнтейнеров для сложных логических задач.

Источник: Slashdot.

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

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

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

Для российского читателя у KolibriOS есть дополнительный смысл: это открытый проект с русскоязычным сообществом, который можно изучать, дополнять и применять для решения практических задач — от перевода старого классного компьютера в рабочее состояние до обучения низкоуровневому программированию.

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

Первый очевидный шаг — отказаться от демона Nix внутри ISO, ведь мы строим автономный образ, а не полноценную NixOS для работы с пакетами. Достаточно двух опций:

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

Важно: конфигурация выше — это не рецепт для продакшена. Отсутствие Nix, SSH, модулей ядра и Perl-активации ломает массу сценариев. Результат интересен скорее как демонстрация границ NixOS, чем как готовый шаблон.

Автор сама отмечает: для рабочего десктопа или сервера так делать не стоит. Но если вам нужен крошечный live-образ под единичный эксперимент — здесь много идей, с которых можно начать.

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

В Linux 7.2 код расширяемого планировщика sched_ext изначально появился в виде файлов ext_arena.c, ext_cid.c, ext_types.h и других прямо в kernel/sched.

Линус Торвальдс слил изменения «под протестом», указав, что префиксы вместо директорий — это неправильный способ группировки.

Новый pull request перенёс файлы в kernel/sched/ext/; Торвальдс уже принял эту реструктуризацию.

Что случилось

На прошлой неделе в основную ветку Linux 7.2 попал основной набор изменений sched_ext — фреймворка, который позволяет реализовывать политики планирования в пользовательских программах BPF. К патчам не было претензий по функциональности, но Торвальдса возмутила организация файлов.

Вместо того чтобы создать поддиректорию kernel/sched/ext/, авторы добавили в kernel/sched несколько файлов с префиксом ext_: ext_arena.c, ext_arena.h, ext_cid.c, ext_cid.h и ext_types.h.

Please don't do this disgusting thing. There's a reason we have subdirectories: it's to group files together and separate them out. Using name prefixing instead of directories is disgusting and wrong. If you have this many random sched-ext files, it damn well should be cleaned up and not be this kind of mess. I've pulled this, but under protest. Proper hierarchical filesystems have been available since 1965.

Как исправили

В ответ разработчики отправили новый pull request, который перекладывает все sched_ext-файлы в отдельную директорию kernel/sched/ext/. Торвальдс уже принял реструктуризацию.

Почему это важно

С точки зрения пользователя разница кажется косметической, но для ядра это вопрос сопровождаемости. Иерархические директории — стандартный способ группировки связанного кода, а префиксы в общей папке быстро превращаются в беспорядок. Реакция Торвальдса подчёркивает, что даже мелкие архитектурные решения в Linux принимаются строго.

Выводы

История с sched_ext — хороший пример того, как в Linux следят за чистотой кодовой базы. Технически патчи работали, но неправильная организация файлов оказалась достаточно серьёзной проблемой, чтобы Торвальдс потребовал исправлений. Теперь код лежит там, где ему положено — в отдельной директории.

Источники

• Phoronix: "Disgusting" Linux sched_ext Source Code Restructured
• Письмо Линуса Торвальдса в lkml
• Коммит реструктуризации в git.kernel.org

EROFS (Enhanced Read-Only File System) — это доступная с Linux 4.19 файловая система только для чтения, заточенная под производительность и компактное хранение образов контейнеров, систем Android и, всё чаще, AI-моделей.

• Linux 7.2 получил два ключевых улучшения EROFS: разреженные pcluster и оптимизированное отображение chunk-based inode.
• Поддержка sparse-данных помогает экономить место при копировании в overlayfs и корректно работать с SEEK_HOLE.
• Удалён устаревший бэкенд FSCACHE — его функциональность заменяют файловые монтирования и fanotify.
• Патчи подготовил мейнтейнер EROFS Гао Сян из Alibaba.

Зачем нужна поддержка разреженных данных

Разреженные (sparse) файлы содержат пустые участки, которые не занимают место на диске. EROFS уже умеет прозрачно сжимать нули, но для AI-датасетов важно именно сохранять дыры: иначе overlayfs при копировании «вверх» распределит под них реальное пространство, а системный вызов SEEK_HOLE не найдёт ни одной «дыры».

Мейнтейнер EROFS Гао Сян из Alibaba пояснил в патчах, что новый код отмечает целые pcluster как «дыры» двумя разными способами. Это особенно полезно для огромных AI-датасетов, где нулевые или неинициализированные фрагменты встречаются часто.

Оптимизация ввода-вывода и удаление FSCACHE

Помимо sparse-поддержки, EROFS в Linux 7.2 получила оптимизированное отображение запросов для inode на основе чанков. Разработчики сообщают, что новый код erofs_map_chunks() делает ввод-вывод более эффективным, хотя точных бенчмарков в анонсе не приводится.

Также из ядра окончательно удалили бэкенд FSCACHE для EROFS. Он раньше использовался для ленивой подгрузки образов, но после того как FSCACHE сделал NETFS обязательной зависимостью, функцию признали устаревшей. Похожее поведение теперь реализуют через монтирование файлов и хуки fanotify.

Итог

Обновления EROFS в Linux 7.2 делают эту файловую систему более удобной для больших AI-датасетов: разреженные данные теперь не превращаются в лишние мегабайты при копировании, а ввод-вывод для chunk-based inode стал эффективнее. Для разработчиков, которые используют EROFS в контейнерных и ML-окружениях, это повод проверить свои сборки ядра.

Источник: Phoronix.

Недавно я много думала про терминал, и вчера мне стало интересно: что вообще происходит со всеми этими «control codes» — Ctrl-A, Ctrl-C, Ctrl-W и так далее? Я собрала таблицу всех 33 ASCII control characters и того, что они делают на моей машине (macOS). Оговорок там миллион, но ниже я расскажу, что это всё значит и какие есть нюансы.

• В ASCII всего 33 control-кода: A–Z (26 штук) плюс 7 дополнительных (@, [, \, ], ^, _, ?). Сделать Ctrl-1 как шорткат невозможно.
• Коды обрабатываются в трёх разных местах: OS terminal driver (например, Ctrl-C → SIGINT), библиотека readline (Ctrl-A, Ctrl-E) или само приложение (emacs использует Ctrl-X).
• Ctrl-M = Enter, Ctrl-I = Tab — поэтому их нельзя использовать как отдельные шорткаты без спец-настройки эмулятора.
• Режим терминала — canonical или noncanonical — определяет, кто обрабатывает Backspace, Ctrl-W и Ctrl-U: OS или сама программа. Разбор обоих режимов — в теле статьи.
• Утилита stty -a показывает текущие маппинги OS-кодов, а stty sane лечит «сломанный» терминал.
• Backspace на разных системах посылает либо байт 127, либо 8 — отсюда исторические войны и конфигурации через stty erase.

Коды обрабатываются в разных местах

Первое, что меня удивило: 33 control-кода делятся (очень условно) на три категории в зависимости от того, где они обрабатываются.

• Обрабатываются OS terminal driver — например, когда ОС видит байт 3 (Ctrl-C), она посылает сигнал SIGINT текущей программе.
• Передаются приложению как есть, и приложение делает с ними что хочет. Внутри этой группы ещё три подгруппы: соответствуют реальной клавише (Enter → байт 13, Tab, Backspace); используются библиотекой readline для редактирования строки (Ctrl-A, Ctrl-E, Ctrl-W); используются конкретными приложениями (Ctrl-X в emacs).

Никакой логики в том, какой код к какой категории относится, нет — просто так исторически сложилось.

Почему именно 33 — и почему «Ctrl-1» не существует

Ещё один сюрприз: control-кодов всего 33 штуки — буквы A–Z плюс семь дополнительных символов (@, [, \, ], ^, _, ?). Это значит, что если вы хотите сделать Ctrl-1 шорткатом в терминальном приложении — такого шортката просто не существует. На моей машине Ctrl-1 — это ровно то же самое, что нажать 1, а Ctrl-3 эквивалентно Ctrl-[.

Ctrl+Shift+C тоже не control-код — это комбинация, которую обрабатывает сам эмулятор терминала. В Linux Ctrl+Shift+X часто используется эмулятором для копирования, открытия новой вкладки или вставки — до TTY они не доходят.

Я всё время использую Ctrl+Left Arrow, но это тоже не control-код — это ANSI escape sequence (ESC[1;5D, где ESC — это сам байт 27 = Ctrl-[), совсем другая история.

Это устроено совсем не так, как шорткаты в GUI, где можно сделать Ctrl+любая клавиша.

Официальные ASCII-имена бесполезны

Каждый из 33 control-кодов имеет имя в ASCII (например, байт 3 — это ETX). Но эти имена придумывали не для компьютеров, а для телеграфа. Когда коды перешли в UNIX-терминалы, половина из них сменила смысл. В итоге ASCII-имена сегодня бесполезны в 50% случаев — проще вообще игнорировать их, чем пытаться понять, какие имена ещё соответствуют оригинальному значению.

Почему Ctrl-M и Ctrl-I — это Enter и Tab

Ctrl-M буквально идентичен Enter, а Ctrl-I — это Tab. Это делает их почти непригодными для шорткатов.

Некоторые всё равно используют Ctrl-I и Ctrl-M как шорткаты, но для этого надо настроить эмулятор терминала, чтобы он обрабатывал эти нажатия иначе, чем по умолчанию. Основной вывод: если пишете терминальное приложение — не используйте Ctrl-I и Ctrl-M как шорткаты.

Как узнать, какой именно код посылается

Пока я писала этот разбор, мне пришлось много экспериментировать с разными комбинациями клавиш. Я написала маленький Python-скрипт echo-key.py, который распечатывает получаемые байты. Наверняка есть более официальный способ, но мне удобнее иметь скрипт, который можно подкрутить под себя.

Оговорка: canonical vs noncanonical mode

Два кода — Ctrl-W и Ctrl-U — я в таблице пометила как «обрабатываются OS». На самом деле это не всегда так — зависит от режима терминала.

В canonical mode (построчный ввод) программа получает ввод только после нажатия Enter — до этого OS сама обрабатывает Backspace, Ctrl-W и другие правки. В noncanonical mode (посимвольный ввод) программа получает каждое нажатие сразу, и коды Ctrl-W и Ctrl-U проходят в программу, которая обрабатывает их как хочет.

Примеры программ в canonical mode:

• Любые неинтерактивные утилиты вроде grep или cat.
• git, по моему опыту.

В noncanonical mode:

• python3, irb и другие REPL.
• Ваш шелл.
• Любой полноэкранный TUI (less, vim).

Оговорка: все OS-коды настраиваются через stty

Я написала «Ctrl-C посылает SIGINT», но технически это не обязательно так. Все коды, которые обрабатывает OS terminal driver, плюс Backspace, можно переназначить утилитой stty. Текущие маппинги смотрят через stty -a.

Я лично ни разу ничего не переопределяла через stty и не могу придумать, зачем бы мне это делать — это рецепт для путаницы и катастрофы. Но когда я спросила в Mastodon, люди назвали такие сценарии:

• Починить сломанный терминал через stty sane.
• Настроить работу Backspace: stty erase ^H.
• Включить поток управления: stty ixoff.
• Некоторые даже переназначают SIGINT на другую клавишу, например на DELETE.

Оговорка: сигналы можно отключить

• Если режим терминала ISIG (флаг, разрешающий сигналы от Ctrl-C и Ctrl-Z) выключен, OS вообще не посылает сигналы. Vim, например, отключает ISIG при запуске.
• На macOS и других BSD-системах есть дополнительный control-код Ctrl-T, который посылает SIGINFO.

Какие режимы ставит программа, можно посмотреть через strace: режимы терминала устанавливаются системным вызовом ioctl.

Комбинация режимов, которую ставит vim при запуске, по сути и есть так называемый «raw mode» — подробности в man cfmakeraw.

Конфликтов очень много

Раз кодов всего 33, конфликтов за один и тот же код — навалом. По умолчанию Ctrl-S замораживает экран, но если выключить этот flow-control, readline использует Ctrl-S для forward search.

Другой пример: Ctrl-T на моей машине то посылает SIGINFO, то переставляет местами два последних символа, то делает что-то совсем третье — в зависимости от того, установлен ли в программе ISIG и использует ли она readline (или имитирует его поведение).

Backspace, «другой» Backspace и историческая боль

В таблице я пометила байт 127 как «backspace», а байт 8 как «другой backspace». История оказалась настолько запутанной, что именно этот пункт собрал больше всего откликов в Mastodon.

Вот как это работает на моей машине:

1. Я нажимаю клавишу Backspace.
2. В TTY уходит байт 127, в ASCII он называется DEL.
3. OS terminal driver и readline оба замапили 127 на «удалить символ» — работает и в canonical, и в noncanonical mode.
4. Предыдущий символ исчезает.

Если нажать Ctrl+H, в readline-приложении это сработает как Backspace, а в программе без readline (например, cat) просто напечатается ^H.

У кого-то шаг 2 другой: клавиша Backspace посылает байт 8 вместо 127, и чтобы она работала, надо настроить OS через stty erase ^H. В Debian Policy Manual есть целый раздел про конфигурацию клавиатуры — по моему пониманию, его написали в 90-х, когда царила путаница с тем, что должен делать Backspace, и нужен был какой-то стандарт, чтобы всё заработало.

На разных машинах всё по-разному

Я почти наверняка упустила ещё десяток способов, которыми «как это работает на моей машине» может отличаться от «как это работает у других», и в моих описаниях тоже могут быть неточности. По stty -a у меня есть ещё три экзотических маппинга — Ctrl-O как «discard», Ctrl-R как «reprint» и Ctrl-Y как «dsusp» — но на практике они редко что-то делают и чаще всего проходят в приложение как есть.

Честно говоря, это необязательно знать

Мне кажется, содержимое этого поста интересное, но не обязательно полезное. Я использовала терминал каждый день последние 20 лет, не зная почти ничего из этого — я просто знала на практике, что делают Ctrl-C, Ctrl-D, Ctrl-Z, Ctrl-R, Ctrl-L (ну и Ctrl-A, Ctrl-E, Ctrl-W), и не задумывалась о деталях. Этого почти всегда хватало, кроме случая, когда я возилась с xterm.js.

От редакции: знание это становится практическим в одном-двух сценариях, и их стоит держать в голове. Во-первых, когда терминал «ломается» — ввод не виден, Enter работает странно — вместо перезапуска шелла поможет stty sane или reset: теперь понятно, что именно они восстанавливают. Во-вторых, Ctrl-S, «замораживающий» терминал, — не баг, а реликт аппаратного flow control: отключить его навсегда можно через stty -ixon в .bashrc / .zshrc. Остальное — любопытная инженерная археология.

Итог

ASCII control characters — это слоёный пирог из трёх эпох: телеграфные корни 60-х, POSIX-терминалы 80-х и GUI-эмуляторы 2020-х, которые поверх всего этого ещё накручивают свою логику. Когда Ctrl-S внезапно замораживает экран, а Ctrl-T делает разные вещи в разных программах — это не баг, а побочный эффект 60 лет совместимости.

Оригинал: jvns.ca — ASCII control characters in my terminal. Также читайте на tproger: 7 новых TUI-инструментов для терминала и 15 полезных команд терминала macOS.

Команда безопасности Calif опубликовала разбор того, как Claude (Anthropic) за ~4 часа написал два рабочих эксплоита для CVE-2026-4747 — уязвимости переполнения стека в модуле ядра FreeBSD. Оба эксплоита сработали с первой попытки и дали полный root-доступ к удалённой машине.

Саму уязвимость тоже обнаружил ИИ: в официальном бюллетене FreeBSD указан «Nicholas Carlini using Claude, Anthropic». При этом человек направлял процесс через 44 промпта, но большую часть технической работы — от анализа крэш-дампов до написания ROP-цепочек — Claude выполнял самостоятельно.

— Claude написал полный remote kernel RCE для FreeBSD (CVE-2026-4747) за ~4 часа при минимальном участии человека (44 промпта)

— Уязвимость — переполнение стека в kgssapi.ko (модуль Kerberos-аутентификации для NFS), оценка CVSS 8,8 (HIGH)

— ИИ самостоятельно решил 6 нетривиальных задач: от настройки тестовой среды до перехода из режима ядра в пользовательский

— Оба эксплоита сработали с первой попытки, результат — uid=0 (root)

— FreeBSD уже выпустил патч 26 марта 2026 года (FreeBSD-SA-26:08)

Уязвимость CVE-2026-4747 в ядре FreeBSD

CVE-2026-4747 — переполнение стека (CWE-121) в модуле ядра kgssapi.ko (реализует RPCSEC_GSS — механизм аутентификации NFS-клиентов через Kerberos). Функция gss_validate() копирует данные из входящего сетевого пакета в стековый буфер без проверки границ.

Переполнение буфера происходит до проверки учётных данных NFS-клиента — но для полноценной атаки нужен сетевой доступ к NFS-серверу. Это отражено в оценке CVSS 8,8 (HIGH) по данным NVD: вектор атаки сетевой, сложность низкая, требуются минимальные привилегии (PR:L).

Дополнительный фактор: конкретная функция в kgssapi.ko скомпилирована так, что стековые канарейки (stack canaries — специальные значения для детекции переполнения) не защищают целочисленный буфер в данном случае. Переполнение остаётся незамеченным. Затронуты все версии FreeBSD, патчи доступны для stable/15, stable/14 и stable/13.

Кто стоит за исследованием

Публикация — совместная работа Calif (калифорнийская компания по безопасности, основанная Thai Duong — соавтором атак BEAST и CRIME на TLS) и Nicholas Carlini из Anthropic (PhD UC Berkeley, лауреат best paper на IEEE S&P, USENIX Security и ICML). Уязвимость обнаружил Carlini с помощью Claude, а команда Calif разработала эксплоит тоже с помощью Claude.

Как Claude написал эксплоит: 6 задач за 4 часа

Команда Calif дала Claude доступ к оболочке, отладчику GDB, утилите ROPgadget (поиск «гаджетов» — коротких фрагментов кода в ядре, которые можно использовать для построения цепочки команд) и эмулятору QEMU. Задача: разработать рабочий эксплоит для CVE-2026-4747. За ~4 часа машинного времени Claude решил 6 нетривиальных задач.

1. Настройка тестовой среды

Claude развернул виртуальную машину FreeBSD с NFS, Kerberos и уязвимым модулем ядра. Модель учла, что VM нужно минимум 2 процессора — FreeBSD создаёт 8 NFS-потоков на каждый CPU.

2. Многопакетная доставка шеллкода

Шеллкод (432 байта) не помещается в один сетевой пакет. Claude разработал стратегию из 15 раундов:

1. Первый раунд: сделать область памяти ядра исполняемой через pmap_change_prot
2. 14 следующих раундов: записать шеллкод порциями по несколько десятков байт за пакет
3. Последний пакет запускает записанный шеллкод

3. Чистый выход из потока

Каждое переполнение захватывает один NFS-поток ядра. Claude использовал kthread_exit() для корректного завершения каждого захваченного потока — чтобы сервер оставался работоспособным для следующего раунда.

4. Отладка смещений стека

Начальные смещения из дизассемблера оказались неверными. Claude отправил De Bruijn-паттерны — специальные последовательности, в которых каждая подстрока уникальна, что позволяет по крэш-дампу точно определить, какой байт попал на адрес возврата. Классический приём пентестеров, который Claude применил без подсказки.

5. Переход из ядра в пользовательский режим

NFS-потоки работают в режиме ядра и не могут напрямую запускать пользовательские программы. Claude нашёл решение через цепочку вызовов ядра FreeBSD:

1. Создать новый процесс через kproc_create()
2. Заменить его на /bin/sh через kern_execve()
3. Сбросить внутренний флаг ядра, помечающий процесс как системный, чтобы он мог выполнять пользовательский код

6. Баг аппаратных точек останова

Дочерний процесс падал с debug exception. Claude отследил проблему: регистр DR7 (управляет аппаратными точками останова на x86) содержал устаревшие значения от отладчика DDB. Решение — очистить DR7 перед форком.

Второй эксплоит — альтернативная стратегия

Claude написал и второй эксплоит, использующий принципиально другой подход. Вместо запуска реверс-шелла (что требует многоэтапной доставки шеллкода и сложного перехода в пользовательский режим) — запись публичного SSH-ключа в .ssh/authorized_keys на сервере. Это проще: нужно записать всего ~400 байт текста в файл, без перехода из ядра в userland. Результат: 6 раундов вместо 15. Оба эксплоита дали полный root-доступ:

Почему это важно для индустрии

Компьютеры всегда умели находить баги. Фаззеры вроде AFL и syzkaller обнаруживают уязвимости в ядрах уже больше десяти лет. Но найти баг и написать эксплоит — совершенно разные вещи. Разработка эксплоитов требует понимания внутренностей ОС, создания ROP-цепочек, управления расположением памяти, отладки крэшей и адаптации, когда что-то идёт не так. Это долго считалось рубежом, который могут пересечь только люди.

Ключевое отличие от прошлых демонстраций ИИ в безопасности: Claude не просто сгенерировал код по шаблону. Модель адаптировалась к неожиданным проблемам в реальном времени — исправляла смещения стека через отладочные паттерны, находила баг с аппаратными регистрами, придумала нетривиальный переход из ядра в пользовательский режим. Каждая из этих задач раньше требовала многолетнего опыта в exploit development.

Для защитников это сигнал: окно между раскрытием уязвимости и появлением рабочего эксплоита сжимается с недель до часов. Недавний взлом Axios на npm показал, как быстро атакующие эксплуатируют цепочку поставок. Теперь ИИ может ускорить и разработку эксплоитов для ядер ОС.

Полный лог из 44 промптов и код обоих эксплоитов опубликованы в репозитории califio/publications на GitHub.

MAD Bugs — что дальше

Calif объявил проект MAD Bugs: Month of AI-Discovered Bugs — до конца апреля 2026 года команда планирует опубликовать ещё несколько уязвимостей и эксплоитов, обнаруженных с помощью ИИ. Все находки проходят через ответственное раскрытие — CVE-2026-4747 был запатчен за 5 дней до публикации эксплоита.

Что делать администраторам FreeBSD

Если вы администрируете FreeBSD-серверы с NFS — обновитесь до последних патчей. Проверить, загружен ли уязвимый модуль:

Если модуль не используется — можно выгрузить его до обновления:

Подробности — в бюллетене FreeBSD-SA-26:08.

Если вы работаете с безопасностью — следите за проектом MAD Bugs: граница между возможностями ИИ и задачами для людей продолжает сдвигаться.

Это ответ на многолетнюю критику: пользователи и разработчики жаловались, что встроенные приложения Windows 11 работают медленно, занимают много памяти и выглядят непоследовательно — потому что многие из них были построены на веб-обёртках (WebView, PWA (Progressive Web App), Chromium). Теперь Microsoft обещает «100% native».

— Microsoft переводит все встроенные приложения Windows 11 на нативный код

— Уходят от веб-обёрток (WebView, PWA, Electron-подобные решения)

— Руди Хьюн (Partner Architect, автор File Explorer) собирает новую команду

— Ожидаются улучшения скорости запуска, потребления памяти и отзывчивости интерфейса

— Конкретные сроки и список приложений пока не объявлены

Веб-обёртка (web wrapper) — это приложение, которое выглядит как нативная программа, но внутри работает веб-страница во встроенном браузере (WebView или Chromium). Такой подход упрощает разработку, но приводит к повышенному потреблению памяти и медленному запуску по сравнению с нативным кодом.

Что известно

Руди Хьюн — архитектор, работающий над Microsoft Store и File Explorer — написал в X, что набирает команду для создания нативных Windows-приложений. Ключевое требование к кандидатам: «сильное продуктовое мышление» — при этом опыт работы с платформой Windows явно не обязателен.

Инициатива вписывается в более широкую реструктуризацию Windows-команды:

• Паван Давулури (EVP Windows & Devices) возглавляет направление
• Клинт Руткас ведёт WinAppSDK, Terminal и PowerToys

От чего уходят

Критике подвергаются приложения, построенные на веб-технологиях:

• Clipchamp — видеоредактор на базе веб-технологий, потребляет значительно больше памяти, чем нативные аналоги
• Copilot — десктопное приложение, работающее как PWA (Progressive Web App)
• WhatsApp для Windows 11 — обратный пример: изначально имел нативный интерфейс на WinUI, но затем был переведён на Chromium-обёртку, став медленнее

Помимо отдельных приложений, Microsoft работает над ускорением базовых элементов системы: уменьшение времени запуска File Explorer, ускорение контекстных меню, перевод меню «Пуск» на WinUI.

К чему идут

Формулировка Хьюна — «100% native» — указывает на полный отказ от WebView-компонентов во встроенных приложениях. Конкретный технологический стек не назван, но контекст подсказывает направление:

• WinAppSDK (Windows App SDK) — фреймворк для создания нативных Windows-приложений, развиваемый командой Клинта Руткаса
• WinUI 3 — UI-фреймворк для нативных интерфейсов Windows
• C++/WinRT и .NET — нативные языковые привязки

Что именно означает «100% native» на практике — пока не определено. Некоторые существующие «нативные» приложения Microsoft всё ещё используют WebView для отдельных компонентов.

Почему это важно для разработчиков

Переход Microsoft к нативным приложениям — сигнал для экосистемы. Если сама Microsoft отказывается от веб-обёрток в своих продуктах, это может повлиять на выбор технологий для сторонних разработчиков Windows-приложений.

Для тех, кто сейчас использует Electron или WebView для Windows-приложений, стоит следить за развитием WinAppSDK — Microsoft явно делает ставку на этот фреймворк как основу для нативной разработки.

В 2020 году Панос Панай говорил, что Microsoft хочет, чтобы пользователи «любили Windows, а не просто нуждались в ней». До сих пор видимых изменений было немного. Новая команда Хьюна — первая конкретная попытка выполнить это обещание.

Выводы

Microsoft признала то, о чём разработчики говорили годами: веб-обёртки во встроенных приложениях Windows — компромисс, который перестал быть приемлемым. Переход на нативный код — правильное направление, но пока это скорее декларация намерений, чем готовый план с датами.

Для Windows-разработчиков это сигнал присмотреться к WinAppSDK и WinUI 3 — Microsoft явно инвестирует в этот стек как основу для будущих приложений.

Кампания стартовала на Indiegogo, где Jolla запросила около $5 млн, чтобы начать производство первой партии устройств в 2026 году.

Jolla давно известна своим альтернативным взглядом на мобильные операционные системы. После экспериментов с Sailfish OS, компания решила вернуться к идее открытого смартфона, созданного при участии пользователей, а не крупных инвесторов.

Что известно о новом Linux-смартфоне

Устройство пока фигурирует под рабочим названием Jolla Linux Phone. Компания публикует рендеры: корпус в теплых оттенках, вертикальная камера, минималистичный дизайн.

Основной акцент — на приватность, открытость и контролируемость пользовательских данных. Все то, традиционно является сильными сторонами проектов на Linux.

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

Под капотом ожидаются характеристики среднего уровня: энергоэффективный процессор, 5G, приличная батарея и камера, которой будет «достаточно для повседневной съемки».

Конкретных спецификаций пока нет — компания обещает раскрыть их после формирования первой производственной партии.

Почему проект профинансировали так быстро

Комьюнити Jolla исторически активно поддерживает независимые мобильные платформы.

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

Пользователи пишут, что устали от закрытых экосистем, навязанных сервисов и ускоряющегося темпа устаревания смартфонов.

Кроме того, рынок Linux-смартфонов переживает второе дыхание: Purism Librem 5 и PinePhone доказали, что нишевые устройства могут найти аудиторию. Особенно если предлагают прозрачность, ремонтопригодность и независимость от крупных корпораций.

Что дальше

Jokka планирует начать производство в 2026 году. Первые прототипы будут представлены публике раньше — после завершения инженерной фазы.

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

Структура Linux

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

Компоненты

Ядро (Kernel) — это центральная часть ОС, которая управляет аппаратными ресурсами и взаимодействует с приложениями. Ядро выполняет следующие задачи:

● управление памятью;

● управление процессами — создание, планирование, завершение;

● управление файлами и файловыми системами;

● управление вводом/выводом — работа с устройствами, такими как жесткие диски, клавиатуры, мыши.

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

Оболочка (Shell) — интерфейс, который принимает команды от пользователя и передает их операционной системе для выполнения. Оболочка предоставляет пользователю командный интерфейс, который позволяет выполнять команды, запускать скрипты и управлять файлами. В Linux есть несколько оболочек:

● Bash (Bourne Again Shell) — самая популярная оболочка в большинстве дистрибутивов Linux;

● Zsh, Csh, Fish — другие распространенные оболочки. В рамках курса мы установим и настроим Zsh.

Системные библиотеки — содержат функции и интерфейсы, которые могут использовать приложения для работы с ядром. Например, библиотека glibc является стандартной библиотекой C, используемой многими программами в Linux для выполнения таких базовых операций, как работа с файлами и памятью.

Драйверы устройств — программные компоненты, которые позволяют ОС «общаться» с аппаратным обеспечением, например, сетевыми картами, жесткими дисками или видеокартами.

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

● управление файлами (например, cp, mv, rm);

● управление процессами (например, ps, top, kill);

● работа с сетью (например, ping, ifconfig, netstat).

Файловая система — определяет, как данные хранятся, организуются и управляются на диске. Linux поддерживает множество файловых систем: ext4, XFS, Btrfs и другие. Важная особенность файловых систем в Linux — поддержка виртуальных файловых систем, например, /proc и /sys, которые предоставляют информацию о состоянии системы и ядра.

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

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

● APT для дистрибутивов на базе Debian (например, Ubuntu);

● YUM или DNF для Red Hat и CentOS;

● Pacman для Arch Linux.

Файловая структура Linux

При работе с Linux нужно держать в голове концепцию, которая лежит в основе системы: «Все — это файл». То есть любые данные, каталоги и процессы ОС можно выразить как поток байтов, занимающий определенный объем файловой системы на дисковом накопителе.

Следовательно, все, что занимает место, можно назвать файлом. А файлы в Linux структурированы следующим образом:

Обычные файлы:

○ текстовые;

○ бинарные;

○ файлы изображений;

○ архивы и т.п.

Специальные:

○ блочные для обозначения устройств (b);

○ символьные (с);

○ ссылочные для представления символьных ссылок (l);

○ файлы сокетов для связи между разными процессами и пр. (s).

Директории:

○ файлы, в которых хранятся другие файлы (d).

Файловая структура Linux организована по иерархическому принципу. Основным каталогом в ней выступает корень — /. В этой структуре каждый каталог или файл находится на определенном уровне и имеет свое предназначение. Вся информация от системных файлов до пользовательских данных хранится в строго определенных местах, что делает систему организованной и логически понятной.

Важно отметить, что в Linux нет понятий «дисков» (как C:\ в Windows), все данные организованы в рамках единого пространства имен файловой системы.

/ (Корень) — корневой каталог, который является основой файловой системы. От него исходят все остальные каталоги и файлы. В отличие от Windows, где каждый диск имеет свою букву, в Linux все файловые системы монтируются в дерево каталогов под корнем /.

/bin. В этом каталоге содержатся основные системные бинарные файлы, доступные для всех пользователей. Эти программы необходимы для базовой работы системы:

● ls — вывод списка файлов;

● cp — копирование файлов;

● mv — перемещение файлов.

/sbin. Здесь находятся системные бинарные файлы, предназначенные для использования администраторами системы. Эти утилиты включают инструменты для настройки системы:

● ifconfig — настройка сетевых интерфейсов;

● fdisk — управление разделами диска.

/usr. Один из самых больших и значимых каталогов. Здесь хранится программное обеспечение, библиотеки и данные, которые применяются всеми пользователями системы. В нём можно найти подкаталоги:

● /usr/bin — бинарные файлы общего назначения;

● /usr/sbin — утилиты для администрирования;

● /usr/lib — библиотеки, необходимые для работы программ.

В каталоге /usr также есть директории, относящиеся к документации (/usr/share/doc), исходным кодам и другим ресурсам.

/home. Это домашний каталог для всех пользователей системы. Каждый пользователь имеет свою собственную папку вида /home/username, где он хранит личные файлы, настройки и данные. Этот каталог используется для организации данных каждого пользователя и гарантирует их изоляцию от системных файлов.

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

● /var/log — логи системы и приложений;

● /var/spool — данные для очередей печати и почтовых серверов.

/tmp. Временное хранилище данных. Этот каталог используется программами для записи временных файлов, которые будут удалены при перезагрузке системы. Например, сюда могут сохраняться промежуточные результаты работы программ.

/etc. Это каталог с конфигурационными файлами системы и файлами установленных программ. Например:

● /etc/passwd — файл с учетными записями пользователей;

● /etc/hostname — имя текущего хоста (компьютера).

/lib. Содержит системные библиотеки, которые необходимы для работы приложений и ядра. Например, файлы, необходимые для загрузки и выполнения программ, которые находятся в каталогах /bin и /sbin.

/dev. Здесь находятся «файлы устройств». В Linux устройства, например, жесткие диски, клавиатуры или порты, представлены в виде файлов, что позволяет работать с ними так же, как с обычными файлами. Примеры файлов устройств:

● /dev/sda — первый жесткий диск;

● /dev/ttyS0 — последовательный порт.

/mnt и /media. Эти каталоги используются для монтирования временных файловых систем, таких как USB-накопители, DVD-диски или сетевые ресурсы. Пример: когда подключается USB-диск, его содержимое может быть смонтировано в /media/username/usb. В моем случае к виртуальной машине подключена общая папка, расположенная на хостовой машине под названием Pentesting.

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

К сожалению, у меня на Linux пока ничего не установлено, поэтому давайте посмотрим, что творится на Mac.

/root. Домашний каталог суперпользователя (root). В отличие от обычных пользователей, root имеет доступ ко всей системе и может выполнять любые задачи. Каталог /root обычно изолирован от других пользовательских данных.

/proc и /sys. Это виртуальные файловые системы, которые содержат данные о системе и ее состоянии. Эти каталоги создаются и обновляются ядром на лету:

● /proc — содержит информацию о процессах, использовании ресурсов и состоянии системы;

● /sys — предоставляет доступ к информации о железе и управлению устройствами.

Файловая структура Linux следует стандарту FHS (Filesystem Hierarchy Standard), который определяет, где должны находиться файлы и каталоги. Этот стандарт соблюдается большинством дистрибутивов, что делает систему предсказуемой для администраторов и разработчиков.

Особенности и преимущества структуры:

1. Унификация — вся файловая система выглядит, как единое дерево, что позволяет легко ориентироваться и монтировать различные устройства.

2. Безопасность — пользователи имеют доступ только к своим каталогам, что защищает системные файлы от случайного повреждения.

3. Гибкость — легко монтировать дополнительные файловые системы, сетевые диски и внешние устройства в любую часть структуры.

Цель файловой структуры Linux — обеспечить четкое разделение системных и пользовательских данных, облегчить управление системой и повысить ее безопасность.

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

В результате процесс переноса культовой ОС Apple из 1990-х на архитектуру x86 занял всего три дня.

Важный момент — у нее не было доступа к исходникам системы. Весь процесс был выполнен с помощью дизассемблера Ghidra и LLM.

Почему это важно

Оригинальные Маки работали на процессорах Motorola 68K и совершенно несовместимы с x86.

Портировать старую ОС — задача крайне нетривиальная даже с полным доступом к исходному коду. В случае System 7 этого не было — только бинарники, которые пришлось реверс инженирить, анализировать и воссоздавать вместе с LLM.

Как происходил процесс портирования

• Келси использовала Ghidra для дизассемблирования оригинального кода System 7.
• Языковая модель (название не уточняется) помогала анализировать бинарники, восстанавливать логику функций, подсказывать реализацию аппаратных интерфейсов и даже находить ошибки.
• Результат был собран под QEMU — в эмуляторе система запускается с работающим Finder и полноценным GUI.

Без ИИ это заняло бы у меня годы. Но с ним я справилась за три дня

Что в итоге

Рабочая версия Mac OS 7 на x86 уже выложена на GitHub (с возможными правовыми оговорками).

Запустить ее можно в QEMU, а при желании адаптировать и для реального «железа».

Текущее состояние рынка и основные тренды рынка ПО и IT-услуг

Группа компаний Б1 представила исследование российского рынка ПО и ИТ-услуг. По итогам 2024 года объём рынка ИТ-услуг (без информационной безопасности) достиг 638 млрд ₽, увеличившись за два года почти в 1,4 раза. Более 150 млрд ₽ пришлись на заказную разработку и проектное ПО.

Тиражное ПО росло ещё быстрее: с 287 до 448 млрд ₽ (примерно +60 % за 2022–2024 гг.). Сильнее всего прибавили вендоры системного ПО, СУБД и инструментов для управления данными и приложениями (до 40–55 % в год).

Коммерческий ИТ-рынок (без инсорсинга, то есть внутренних разработок) в 2024 году превысил 2,2 трлн ₽, а с учётом внутренних разработок — 2,8 трлн ₽, показывая среднегодовой рост около 22 %. ИТ-услуги и тиражное ПО суммарно составляют около 1,1 трлн рублей или около 48% от указанной суммы. Другие сегменты: оборудование инфраструктуры ИТ и ПК, ИТ-обучение и информационная безопасность. К 2032 году объём всей отрасли может превысить 6,5 трлн ₽ (коммерческий сегмент — 5,2 трлн ₽) при среднем долгосрочном росте около 11 %.

Прогнозы:

По данным исследования, российский рынок ИТ-услуг и программного обеспечения остаётся фрагментированным. Заметные доли есть лишь у немногих лидеров, а основная часть распределена между десятками и сотнями компаний.

• IT-услуги. Крупнейшие игроки — Ланит (около 8 %), Лига Цифровой Экономики (4 %) и Группа Softline(4 %). Все остальные компании занимают не более 3 % каждая.
• Тиражное ПО. Здесь впереди 1С и СКБ Контур (по 6 %), а также Яндекс (5 %). Оставшиеся 83 % рынка делят между собой многочисленные разработчики.
• Заказная разработка. Лидер — FabricaONE.AI с долей около 11 %. Далее идут БФТ Холдинг (7 %), Ланит и Лига Цифровой Экономики (по 6 %).
• ПО для работы с документами и СЭД. Это наиболее концентрированный сегмент: на десятку ведущих компаний — СКБ Контур, Тензор, Сбер Корус и другие — приходится порядка 81 % всего рынка.
• Бизнес-ПО. Здесь, напротив, конкуренция особенно высока: совокупная доля топ-10 компаний (1С, ЦФТ, Диасофт и др.) не превышает 40 %.

Российский IT-рынок сочетает зоны, где уже много конкурентов, с сегментами, где ещё есть пространство для новых решений и стартапов.

Реестр российского ПО: значение и преимущества для вендоров

Ключевой инструмент импортозамещения — Реестр российского программного обеспечения, который ведёт Минцифры. В него на сентябрь 2025 года включено уже 27 572 решения.

Для бизнеса включение ПО в реестр даёт преференции. Главное преимущество — освобождение от НДС, что позволяет снизить цену на софт или увеличить маржу. Ещё один важный плюс — доступ к госзакупкам. Продукт из реестра можно предлагать государственным заказчикам. Кроме того, наличие решения в реестре упрощает получение ИТ-аккредитации, так как её можно оформить без подтверждения уровня зарплат работников. Наконец, такие компании могут претендовать на государственные гранты и субсидии.

Чтобы попасть в реестр, разработчику нужно доказать следующие факты:

• исключительные права на продукт принадлежат российской компании или гражданину РФ;
• исходный код и ключевые технологии находятся в России;
• сервисы и данные хранятся на отечественных серверах;
• в составе продукта нет критических зарубежных компонентов, влияющих на работоспособность;
• продукт должен быть доступным для внешних пользователей, в том числе госструктур;
• программа или база данных должна распространяться как законченный продукт, то есть скачиваться единым пакетом или записываться на носитель;
• отчисления за границу (лицензии, обязательные сервисы) не должны превышать 30 % выручки;
• запрещено строить продукт на коммерческих СУБД и других платных платформах;
• все компоненты используются правомерно на основании открытой лицензии или лицензионного договора;
• у ИТ-компании есть действующий сайт.

Есть и обязательные требования к компании-разработчику:

• Не менее 50 % уставного капитала должны принадлежать гражданам РФ.
• Более 70 % прибыли от продажи продукта должны оставаться у российских правообладателей.
• Гарантийное обслуживание и техническая поддержка должны выполняться на территории России или российскими гражданами.

«Реестр — важный инструмент формализации. Он задаёт правила игры и открывает доступ к крупным тендерам. Кроме того, для заказчиков ключевое значение имеют реальные кейсы, SLA и зрелость экосистемы. Поэтому можно сказать, что реестр отражает формальную сторону, а реальная картина все же формируется на уровне практических внедрений. При этом сам реестр структурирует рынок и его игроков, фиксирует перечень решений и помогает государству понимать, какие классы ПО уже готовы к внедрению, а какие требуют инвестиций», — отмечает Сергей Лебедев, коммерческий директор GreenData.

«Реестр отечественного ПО отражает картину рынка всё лучше, но всё ещё далеко не полностью и с искажениями. Например, всё, что касается сегмента B2G, госзакупок — реестр на 100% актуален. Все операционные системы, офисные пакеты, системы защиты информации и СУБД включены в реестр. Онидеально отражает рынок импортозамещения по тем вопросам, которые необходимы для того, чтоб компании осуществляли основную деятельность.

Что касается слабых мест реестра, здесь плохо выражена ситуация на коммерческом рынке. Например, нишевые SaaS-решения, маркетплейсы, сервисы онлайн-образования, некоторые CRM могут не проходить сложную процедуру внесения, так как их клиентам это не нужно. Аналогичная ситуация и в геймдев. Приложения доставки, каршеринг — их присутствие в реестре не отражает их в реальной доле рынка», — комментирует Алексей Флоринский, генеральный директор компании-разработчика заказного программного обеспечения SimbirSoft.

Российские аналоги популярных зарубежных сервисов

Сегодня в России уже есть полноценные аналоги многих видов программного обеспечения.

Офисные пакеты. Для работы с документами и совместного редактирования всё чаще выбирают МойОфис и Р7 Офис. Эти платформы заменяют Microsoft 365 и Google Workspace, так как поддерживают текстовые редакторы, таблицы, презентации, корпоративную почту и чаты. Продукты сертифицированы для использования в госструктурах, обеспечивают хранятение данныех на российских серверах и отвечают требованиям ИБ.

«В части инфраструктурных сервисов есть широкий выбор, но далеко не все организации решаются массово отказываться от Microsoft и переходить на решения на базе Linux или к отечественным вендорам. Схожая ситуация наблюдается в сегменте корпоративной почты и файловых хранилищ, замещение пока не достигло прежней глубины», — рассказывает Максим Завьялов, руководитель практики импортозамещения K2 Cloud.

Облачные сервисы. Сегмент облаков в России растёт особенно быстро. Среди крупнейших игроков: VK Cloud, Яндекс Облако, СберОблако. Они предоставляют вычислительные мощности, хранилища, сервисы машинного обучения и аналитики, заменяя AWS, Azure и Google Cloud.

Мессенджеры и сервисы для совместной работы. Для видеоконференций и командной работы можно использовать TrueConf, ТамТам и Яндекс Телемост. Эти решения предлагают стабильную связь, групповые чаты и совместный доступ к файлам.

Базы данных. Вместо зарубежных СУБД компании переходят на Postgres Pro и СУБД ЛИНТЕР. Они совместимы с экосистемой PostgreSQL, поддерживают масштабируемые кластеры, инструменты резервного копирования и репликации.

CRM и ERP. Наиболее востребованные продукты — 1С, Terrasoft (Creatio) и «Галактика ERP». Они закрывают задачи учёта, автоматизации продаж, документооборота и планирования ресурсов предприятия, выступая полноценной заменой SAP, Oracle и Salesforce.

«Во всех сегментах сейчас особо актуален вопрос замещения ERP-систем, которые установлены практически в каждом предприятии в том или ином виде и позволяют автоматизировать часть внутренних процессов, сформировать систему отчётности. Область ERP-решений долгое время считалась в России отстающей на фоне SAP и Oracle. Однако на данный момент наши решения, такие как 1C, “Галактика ERP”, напрямую конкурируют с западными интеграторами., Ммногие отечественные компании делают осознанный выбор в пользу российских платформ», — отмечает Даниил Летин, руководитель дирекции по развитию бизнеса в IBS.

DevOps и CI/CD. Для управления исходным кодом и автоматизации развёртывания появились платформы GitFlic, GitVerse и VK Code, которые поддерживают приватные репозитории, пайплайны CI/CD и интеграцию с популярными системами контроля версий.

Информационная безопасность. Российский сектор ИБ традиционно силён. Продукты Лаборатории Касперского и Positive Technologies обеспечивают защищают инфраструктуру, анализируют уязвимости и мониторят инциденты.

«Говоря о сегментах, которые чувствуют себя наиболее устойчиво, стоит выделить именно сферу кибербезопасности — здесь переход на российские продукты прошел относительно спокойно», — считает Максим Завьялов.

Где ещё есть сложности?

Российские аналоги уже успешно заменяют зарубежные продукты в госсекторе, банках, телекоме, ритейле и промышленности. Тем не менее, остаются направления и ниши, где полной замены пока нет.

«Наиболее устойчиво чувствуют себя платформенные решения — low-code, интеграционные слои, банковские продукты. У этих продуктов есть очевидная ценность — это ускоренный time-to-market, прозрачность процессов, поддержка композитной архитектуры. При этом в зоне риска находятся нишевые SaaS-сервисы, сильно зависимые от международных экосистем. Там всё ещё есть барьеры по сертификации, поддержке и интеграции. Поэтому именно платформенный класс решений формирует фундамент устойчивости российского рынка», — делится Сергей Лебедев.

«В зоне риска остаются высоконагруженные отраслевые решения, связанные с промышленным производством, инженерным моделированием, сложными CAD/CAM-системами. Там барьер входа слишком высок, и полного импортозамещения пока нет», — отмечает Елена Титова, генеральный директор компании Стеллар.

Что касается сервисов для рабочих задач, здесь тоже пока остаются незакрытые потребности в софте. Например, Алексей Ровдо, главный аналитик ИТ-интегратора AWG, отмечает нехватку альтернатив ряда сервисов: «Github и частные репозитории для совместной работы над исходным кодом, групповые видеоконференции Zoom, а также онлайн-сервис для создания диаграмм draw.io. При этом российский рынок активно работает в этом направлении и уже предлагает перспективные разработки, такие как Яндекс.Телемост». По словам коммерческого директора UDV Group Илоны Киреёнок, не хватает «серьёзных корпоративных инструментов вроде полноценной почтовой системы, системы каталогов, управления учетными записями и т.д.».

«Нам не хватает решений, которые в полной мере закрыли бы экосистему продуктов Microsoft с точки зрения интеграции пользовательских сервисов, ОС и систем компании», — комментирует Андрей Каплин, руководитель направления инфраструктурного ПО компании «ГИГАНТ Компьютерс».

Несмотря на сложности, большинство экспертов с оптимизмом относятся к импортозамещению в сфере ПО и ИТ-услуг: «Ранее российский рынок ПО уступал в масштабах мировому рынку и занимал ограниченную долю — на нём крупные вендоры получали лишь 1–2% своей выручки. Хотя сокращение рынка вызвало определённые трудности, одновременно оно открыло возможности для трансформации отрасли в России. Изоляция российского рынка привела к резкому росту отечественных игроков и решений, появлению локальных лидеров, таких как “Группа Астра”, “НКТ” и другие», — подчёркивает Алексей Ровдо, главный аналитик ИТ-интегратора AWG.

В письме-рассылке разработчиков ядра он назвал представленный набор изменений «мусором» и заявил, что принимать его в текущем цикле не будет.

Поводом стала не только техническая оценка кода, но и нарушение сроков: Торвальдс ранее просил отправлять пул-реквесты заранее, так как находится в поездке.

«Если уж не можете следовать этому правилу, то хотя бы присылайте качественные изменения», — написал он.

Критика за «бесполезный хелпер»

Отдельно Торвальдс раскритиковал появление функции make_u32_from_two_u16() в общих заголовках, которая собирает 32-битное значение из двух 16-битных. По его словам, такой «хелпер» делает код менее читаемым и только ухудшает ситуацию:

Если вы пишете (a << 16) + b, сразу видно, что происходит. А вызов make_u32_from_two_u16(a,b) не дает никакого понимания порядка байт. Это делает мир хуже

Он также подчеркнул, что подобные утилиты не должны попадать в общие (не RISC-V-специфичные) заголовки. И уж точно не в конце merge-окна.

Жесткое предупреждение

Торвальдс предупредил сопровождающего RISC-V-ветки Пальмера Даббелта, что в будущем не примет ни поздние пул-реквесты, ни «мусор» за пределами архитектурно-специфичных частей.

Попытки протолкнуть большие изменения в последний момент он назвал «неудачной стратегией».

Разработчикам RISC-V, в свою очередь, придется повторить попытку в цикле Linux 6.18. Правда, уже в начале merge-окна и без спорных изменений.

Сейчас методические рекомендации Рособрнадзора предписывают использовать исключительно Windows, что, по мнению ассоциации, противоречит законодательству.

Почему это важно

С 1 января 2025 года действует указ президента, запрещающий использование иностранного ПО в органах госвласти и критической инфраструктуре. По мнению АРПП, проведение ЕГЭ на Windows нарушает:

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

Кроме того, разработчики указали на финансовые и образовательные риски:

• поставки и обновления Windows могут быть прекращены из-за санкций;
• использование Windows требует ежегодных бюджетных трат на лицензии;
• школьники и учителя не получают опыта работы с отечественными системами.

Что предлагают

Представители АРПП предложили использовать отечественные ОС. Например, Astra Linux, РЕД ОС, ALT Linux и «РОСА ОС». При этом параллельно закрепить в методических рекомендациях применение российского офисного софта (например, «Р7 Офис» или «МойОфис»).

Также в АРПП отметили важность создания тестовой зоны для проверки совместимости экзаменационных систем с российскими ОС. Ну и, в конце концов, исключить упоминания Windows из официальных документов по проведению ЕГЭ.

Если говорить про «Астру» в школах — она уже введена. Введены системы МОС. Они уже вовсю работают с отсмотром мониторов школьников и система показывала себя более чем достойно.

Вопрос в том, что МОС — штука московская. А вот что будет в регионах — это большой вопрос. Вопрос порой может переходить в то русло, что ранее в школы закупали Макбуки и героически переводили их на винду. А вот как на старый Мак встанет новая «Астра» — опять же вопрос.

Понятно, что этот он решится и спустя лет пять школьники будут писать все на «Астре» или «РЕДе», но вот то, что этот процесс произойдёт в ближайший год-два — это сильно вряд ли.

Минобразования должно перевести не только системы на российские, но и поставить отечественное оборудование. И вот когда оно доберется до всех (даже отдаленных регионов), вот тогда может возникнуть вопрос в «Астре» и единой инфраструктуре, как это было с ЕМИАСом.

Что дальше

Минцифры уже подтвердило, что в реестре отечественного ПО есть решения для образования. А планы по переходу на российские ОС в процессе сдачи ЕГЭ обсуждаются с 2021 года, однако пока сохраняется зависимость от Windows.

Принудительный перевод ЕГЭ на российские операционные системы — вопрос времени. Подход оправдан с точки зрения законодательства, но его реализация потребует времени и доработки инфраструктуры.

Стоит ли это рисков или разумнее оставить Windows — вопрос открытый.

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

Что такое SSL/TLS сертификат

Еще десять лет назад протокол HTTPS использовали преимущественно банки и платежные системы. Сегодня даже простейший блог без шифрования трафика вызывает предупреждения в браузерах и теряет доверие посетителей.

SSL/TLS сертификаты для каждого сайта выполняют три важные функции: обеспечивают шифрование данных, подтверждают подлинность сайта и гарантируют целостность передаваемой информации. Без них любая форма авторизации или даже обычная переписка становятся уязвимыми для перехвата. Особенно актуально это в эпоху публичных Wi-Fi сетей и сложных цепочек маршрутизации, когда трафик может проходить через десятки промежуточных узлов.

Технологии защиты постоянно развиваются. Если в 2010-х основным стандартом был TLS 1.2, то сейчас все больше ресурсов переходят на TLS 1.3 с его оптимизированным «рукопожатием» и отказом от устаревших алгоритмов. Параллельно ужесточаются требования поисковых систем — Google еще в 2018 году начал помечать HTTP-сайты как небезопасные, в 2025 году такие ресурсы практически не имеют шансов попасть в топ выдачи.

Но важность SSL/TLS выходит за рамки технических аспектов. Для пользователей значок замка в адресной строке стал визуальным маркером доверия. Исследования показывают, что около 85% посетителей сразу покидают сайт при появлении предупреждения о небезопасном соединении. В коммерческих проектах это напрямую влияет на конверсию и доходы.

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

Сертификат содержит несколько ключевых элементов:

• Публичный ключ — используется для шифрования данных, отправляемых на сервер.
• Данные владельца — информация о компании или физическом лице, которому выдан сертификат.
• Цифровую подпись центра сертификации (CA) — подтверждает, что документ был проверен и подписан доверенным удостоверяющим центром.
• Срок действия — обычно от нескольких месяцев до нескольких лет, после чего требуется обновление.

Выдачей SSL/TLS сертификатов занимаются центры сертификации (Certificate Authorities, CA). Это организации вроде DigiCert, Sectigo или Let’s Encrypt, чьи корневые сертификаты предустановлены в браузерах и операционных системах. Если CA подтверждает валидность домена и, при необходимости, проверяет юридические данные владельца, он выпускает сертификат, который браузеры распознают как доверенный.

Хотя аббревиатура SSL (Secure Sockets Layer) до сих пор широко используется, сам протокол считается устаревшим с 2015 года из-за уязвимостей. Его современная замена — TLS (Transport Layer Security), но термин «SSL-сертификат» остался в обиходе как дань традиции.

Без такого сертификата любая передача данных — будь то логины, платежные реквизиты или персональные сообщения — становится уязвимой для атак типа «человек посередине» (MITM). Современные браузеры активно борются с незащищенными соединениями: Chrome и Firefox, например, помечают сайты без HTTPS как «небезопасные», а с 2023 года некоторые из них и вовсе блокируют смешанный контент.

Интересно, что с 2024 года ряд CA начали внедрять сертификаты с укороченным сроком действия (менее 30 дней) для повышения безопасности. Это усложняет жизнь злоумышленникам, но и требует более гибкой инфраструктуры обновления у владельцев сайтов.

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

Как работает шифрование с SSL/TLS

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

В основе лежат два типа шифрования: асимметричное (для аутентификации и обмена ключами) и симметричное (для быстрой передачи данных).

Асимметричное шифрование используется на начальном этапе. Сервер обладает парой ключей: открытым (public key), который доступен всем, и закрытым (private key), хранящимся в секрете.

Когда браузер запрашивает защищенное соединение, сервер отправляет свой SSL-сертификат, содержащий публичный ключ. Браузер проверяет подлинность сертификата через центры сертификации (CA), встроенные в ОС или сам браузер. Если все в порядке, он генерирует временный симметричный ключ, шифрует его публичным ключом сервера и отправляет назад.

Здесь важно, что расшифровать этот ключ может только владелец закрытого ключа — то есть сам сервер. Так решается проблема безопасного обмена ключами без риска перехвата. Современные системы чаще всего используют алгоритмы вроде RSA (2048 или 4096 бит) или ECC (на основе эллиптических кривых), поскольку они обеспечивают достаточную стойкость при приемлемой скорости работы.

После обмена начинается фаза симметричного шифрования. Теперь обе стороны используют один и тот же ключ (например, AES-256 или ChaCha20), который применяется для кодирования всего трафика. Симметричные алгоритмы быстрее асимметричных, что критично для производительности — представьте, если бы каждый пакет данных шифровался RSA.

Процесс установки соединения (TLS handshake) занимает доли секунды, но включает несколько этапов:

1. Приветствие клиента (ClientHello) — браузер сообщает серверу, какие алгоритмы шифрования он поддерживает.
2. Приветствие сервера (ServerHello) — сервер выбирает наиболее безопасный из доступных вариантов и отправляет свой сертификат.
3. Проверка сертификата — браузер убеждается, что сертификат подписан доверенным CA и не просрочен.
4. Обмен ключами — как описано выше, создается симметричный ключ.
5. Завершение рукопожатия (handshake) — стороны подтверждают готовность к шифрованному обмену.

Весь процесс обеспечивает три ключевых аспекта безопасности: конфиденциальность (данные недоступны третьим лицам), целостность (информация не изменяется при передаче) и аутентификацию (уверенность в подлинности сайта).

С 2023 года большинство браузеров перешли на TLS 1.3 (выпущен в 2018), где процесс установки соединения оптимизирован — теперь он требует всего одного обмена данными вместо двух в TLS 1.2. Это не только ускоряет загрузку страниц, но и исключает уязвимости, связанные с устаревшими алгоритмами вроде SHA-1 или CBC-режимов.

Современные браузеры дополнительно проверяют сертификат на соответствие стандарту HSTS (HTTP Strict Transport Security), который запрещает незащищенные соединения. С 2024 года многие сайты используют механизм «ожидающего сертификата» (Certificate Transparency), позволяющий отслеживать неавторизованные выпуски.

Важный факт. Даже если злоумышленник перехватит зашифрованный трафик, без закрытого ключа расшифровать его будет практически невозможно. Например, взлом AES-256 методом полного перебора потребует времени, превышающего возраст Вселенной, — при условии, что ключ сгенерирован правильно.

Однако SSL/TLS — не панацея. Если на сервере неправильно настроены параметры (скажем, разрешен слабый алгоритм RC4), или приватный ключ скомпрометирован, защита рушится. Поэтому важно не только наличие сертификата, но и его корректная настройка. Проверить это можно через инструменты вроде SSL Labs Test — они анализируют параметры соединения и выявляют потенциальные уязвимости.

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

Типы SSL/TLS сертификатов

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

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

Для коммерческих проектов чаще используют сертификаты с проверкой организации (OV). В этом случае центр сертификации проверяет официальные регистрационные данные компании — название, юридический адрес, право на использование домена. Процесс занимает 1-3 рабочих дня. В отличие от DV, информация о владельце включается в сертификат и доступна для просмотра в деталях соединения.

Наивысший уровень доверия обеспечивают сертификаты расширенной проверки (EV). Их особенность — тщательная верификация бизнеса, включающая проверку официальной регистрации, физического адреса и телефонных контактов. В прошлом браузеры выделяли EV-сертификаты зеленой строкой с названием компании, но сейчас визуальное отличие менее заметно. Тем не менее, такой вариант остается стандартом для банков, платежных систем и крупных корпораций.

По охвату защищаемых доменов сертификаты делятся на несколько категорий:

• Стандартные (Single-name) работают только с одним конкретным доменным именем.
• Wildcard-сертификаты распространяются на основной домен и все его поддомены — удобное решение для сложных веб-приложений.
• Мультидоменные (SAN или MDC) позволяют защитить несколько независимых доменов одним сертификатом — оптимальный выбор для компаний с разветвленной структурой онлайн-ресурсов.

Отдельно стоит отметить бесплатные сертификаты, которые предлагают такие организации как Let’s Encrypt. Они относятся к категории DV и выдаются на короткий срок (обычно 90 дней), что требует автоматического продления. Хотя по уровню шифрования они не уступают платным аналогам, отсутствие информации о владельце делает их непригодными для коммерческих проектов.

Выбор конкретного типа зависит от задач проекта. Информационному порталу достаточно DV, интернет-магазину среднего размера — OV, финансовой организации — EV. Главное помнить: сам по себе сертификат не делает сайт безопасным, а лишь обеспечивает защиту передаваемых данных. Дополнительные меры вроде регулярного аудита кода и защиты от DDoS-атак остаются ответственностью владельца ресурса.

Почему важно использовать SSL/TLS

В современном интернете SSL/TLS сертификаты перестали быть опциональной функцией — они стали обязательным стандартом безопасности. Причин для их использования несколько, и каждая касается как технических аспектов, так и взаимодействия с пользователями:

Защита данных

Прежде всего, SSL/TLS защищает передаваемые данные от перехвата. Без шифрования злоумышленник, получивший доступ к сетевому трафику (например, через публичную Wi-Fi сеть), может просматривать логины, пароли, банковские реквизиты и другую конфиденциальную информацию.

Протокол TLS исключает такую возможность, преобразуя данные в криптографически стойкий формат, который невозможно расшифровать без специального ключа. Особенно это актуально для MitM-атак (Man-in-the-Middle), где злоумышленник пытается вклиниться в соединение между клиентом и сервером.

Фактор SEO

Поисковые системы давно учитывают наличие HTTPS как фактор ранжирования. Google еще в 2014 году объявил, что защищенные соединения получают небольшой, но значимый приоритет в выдаче.

Сейчас это требование стало еще строже — сайты без SSL/TLS практически не имеют шансов попасть в топ поисковой выдачи. Более того, некоторые функции современных веб-API (например, геолокация или доступ к камере) в браузерах по умолчанию блокируются для незащищенных HTTP-соединений.

Обязательные требования

Технические стандарты также диктуют свои условия. PCI DSS (требования безопасности для работы с платежными картами) прямо предписывают использование TLS не ниже версии 1.2 для всех операций с финансовыми данными. Аналогичные нормы есть в GDPR и других регуляторных документах — отсутствие шифрования может стать основанием для штрафов и юридических последствий.

Интересно, что SSL/TLS важен не только для внешних, но и для внутренних сервисов. В 2025 году это стало особенно актуально с ростом числа удаленных сотрудников и облачных сервисов.

Важно понимать: SSL/TLS — не просто «галочка» для браузера или SEO. Это базовая технология, обеспечивающая конфиденциальность, целостность данных и аутентификацию сервера. При этом современные решения вроде Let’s Encrypt или автоматического продления сертификатов в панелях хостинга свели сложность внедрения к минимуму — сегодня нет рациональных причин отказываться от HTTPS.

Как получить и установить сертификат

Процесс получения SSL/TLS сертификата начинается с выбора типа защиты, соответствующего потребностям вашего проекта. Для личных блогов и небольших сайтов оптимальным решением станут бесплатные варианты от Let’s Encrypt — они обеспечивают базовое шифрование без сложных процедур верификации.

Коммерческим проектам потребуются платные сертификаты с проверкой организации (OV) или расширенной проверкой (EV), особенно если работа связана с обработкой платежей или персональных данных.

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

1. Необходимо сгенерировать запрос на выпуск (CSR) через панель управления хостингом или используя OpenSSL. В запросе указываются данные о домене и организации.
2. CSR отправляется в выбранный центр сертификации вместе с документами, подтверждающими право владения доменом и юридический статус компании. Для DV-сертификатов проверка ограничивается подтверждением домена, тогда как EV требует предоставления учредительных документов и может занимать несколько рабочих дней.
3. После проверки центр сертификации выдает файлы самого сертификата и цепочки доверия (CA bundle).
4. Эти файлы необходимо загрузить на сервер через административную панель хостинга или вручную, прописав соответствующие директивы в конфигурации веб-сервера. Для Nginx потребуется указать пути к файлам сертификата и приватному ключу в блоке server, а в Apache — использовать директивы SSLCertificateFile и SSLCertificateKeyFile.

Особое внимание стоит уделить автоматическому продлению. Большинство современных центров сертификации, включая Let’s Encrypt, выдают сертификаты на ограниченный срок (обычно 90 дней). Для автоматического обновления можно использовать Certbot или встроенные инструменты панелей управления типа cPanel. Они самостоятельно проверяют срок действия и обновляют сертификаты без вмешательства администратора.

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

После установки обязательно проверьте корректность работы через онлайн-инструменты вроде SSL Labs Test. Они покажут не только правильность цепочки доверия, но и выявят потенциальные уязвимости в настройках. Особенно важно проверить поддержку актуальных версий TLS (1.2 и выше) и отключить устаревшие алгоритмы шифрования, которые могут снижать уровень безопасности.

Как проверить корректность SSL/TLS

После установки сертификата важно убедиться в его правильной работе. Самый простой способ — обратить внимание на адресную строку браузера. Закрытый замок и пометка «Безопасное соединение» свидетельствуют о корректной настройке. Однако для профессиональной проверки потребуются специальные инструменты.

Онлайн-сервисы вроде SSL Labs предоставляют детальный анализ конфигурации. Достаточно ввести адрес сайта, и система проверит не только срок действия сертификата, но и поддерживаемые версии протоколов, алгоритмы шифрования, правильность цепочки доверия. Результат отображается в виде оценки от A+ до F, где низкие баллы указывают на критические уязвимости.

Частая проблема — несоответствие имени в сертификате и фактического домена (mismatch). Это происходит при использовании одного сертификата для нескольких ресурсов или ошибках в настройках. Браузеры жестко реагируют на такой сценарий, блокируя доступ или выводя предупреждения. Проверить соответствие можно через консоль разработчика во вкладке «Безопасность».

Срок действия — еще один важный параметр. Просроченные сертификаты (expired) вызывают предупреждения в браузерах и могут полностью заблокировать доступ к сайту. Современные системы мониторинга, такие как Uptime Robot, позволяют настроить уведомления об истечении срока заранее.

Самоподписанные сертификаты (self-signed) — особая категория. Они не проверяются центрами сертификации, поэтому браузеры не доверяют таким соединениям. Проверить подпись можно через командную строку с помощью openssl x509 -text -noout -in сертификат.crt.

Для комплексной проверки стоит обратить внимание на несколько аспектов:

1. Корректность цепочки сертификатов — промежуточные звенья должны быть правильно установлены на сервере.
2. Поддержку актуальных версий TLS (1.2 и выше) при отключении устаревших протоколов вроде SSLv3.
3. Настройку перенаправления с HTTP на HTTPS без смешанного содержимого.

Мифы и заблуждения о сертификатах

Вокруг SSL/TLS сертификатов сложилось немало ошибочных представлений, которые часто мешают принимать верные решения при организации защиты сайта. Разберем самые распространенные из них.

Сертификаты дают 100% защиты

Один из самых живучих мифов — убеждение, что наличие сертификата делает ресурс полностью защищенным. На самом деле, SSL/TLS обеспечивает лишь безопасность передачи данных между клиентом и сервером.

Это не панацея от SQL-инъекций, XSS-атак или других уязвимостей веб-приложений. Сертификат не заменяет необходимость регулярного аудита кода, обновления ПО и других мер безопасности.

Сертификаты снижают производительность

Распространено заблуждение о сильном влиянии шифрования на производительность. Современные протоколы, особенно TLS 1.3, оптимизированы настолько, что разница в скорости между защищенным и незащищенным соединением практически незаметна.

Более того, HTTP/2 и HTTP/3, требующие обязательного использования TLS, часто работают быстрее незашифрованных соединений за счет более эффективных механизмов передачи данных.

Платные сертификаты лучше

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

Сертификаты обеспечивают долговременную защиту

Отдельно стоит миф о «вечной» защите после установки. Сертификаты имеют ограниченный срок действия не просто так — это важный элемент безопасности. Кроме того, криптографические стандарты постоянно развиваются: алгоритмы, считавшиеся надежными пять лет назад, сегодня могут быть уязвимы. Регулярное обновление сертификатов и параметров шифрования обязательно для поддержания реальной защиты.

Сертификаты нужны не всем

Еще одно ошибочное мнение — что SSL/TLS нужен только сайтам с формами ввода. Современные браузеры помечают все HTTP-страницы как небезопасные, независимо от их содержания. Более того, многие функции (геолокация, push-уведомления) в Chrome и других браузерах заблокированы для незащищенных соединений.

Это сложно

Наконец, существует миф о сложности установки и обслуживания. Современные хостинг-провайдеры и панели управления предлагают автоматизированные решения, где получение и обновление сертификата занимает несколько кликов. Даже ручная настройка через Let’s Encrypt и Certbot перестала быть сложной задачей благодаря подробной документации.

Разобравшись с этими заблуждениями, проще принимать взвешенные решения о защите сайтов. SSL/TLS — важный, но не единственный элемент безопасности, который нужно рассматривать в комплексе с другими мерами защиты данных.

Частые проблемы и уязвимости

Даже правильно настроенные SSL/TLS сертификаты могут стать источником проблем, если не учитывать ключевые аспекты их работы. Одна из самых распространенных ситуаций — истекший срок действия.

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

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

Устаревшие протоколы и алгоритмы представляют отдельную угрозу. Поддержка TLS 1.0 и 1.1, сохраняемая для совместимости со старыми системами, создает бреши в безопасности. Эти версии содержат известные уязвимости (BEAST, POODLE), позволяющие злоумышленникам частично расшифровывать трафик. Современные стандарты требуют отключения этих протоколов и использования TLS 1.2 или 1.3 с устойчивыми алгоритмами вроде AES-GCM и ChaCha20-Poly1305.

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

Технические уязвимости в реализации протоколов тоже заслуживают внимания. Атака Heartbleed (2014), пользуясь ошибкой в OpenSSL, позволяла читать память сервера, включая приватные ключи. Уязвимости в криптографических библиотеках (ROBOT, DROWN) демонстрируют, что даже правильно настроенное шифрование может оказаться под угрозой из-за фундаментальных проблем в коде.

Отдельно стоит отметить проблемы смешанного содержимого, когда защищенная HTTPS-страница загружает ресурсы (скрипты, изображения) по незашифрованному HTTP. Браузеры считают такие страницы уязвимыми и могут блокировать их элементы или показывать предупреждения, несмотря на наличие действующего сертификата.

Важно не только правильно настраивать сертификаты, но и регулярно проверять их состояние, отслеживать отзыв списков (CRL) и обновлять конфигурацию сервера в соответствии с актуальными рекомендациями. Инструменты мониторинга вроде SSL Pulse помогают отслеживать общую ситуацию с безопасностью в интернете и вовремя реагировать на новые угрозы.

Безопасность безопасностью, но как писать код, который не стыдно показывать? Всё для фронтендеров и бэкендеров в одном месте.

ЦЕЛЕНАПРАВЛЕННЫЕ АТАКИ (APT-ГРУППЫ)

APT-атака (Advanced Persistent Threat — продолжительная атака повышенной сложности) — это длительная, целенаправленная и скрытая кибератака, при которой злоумышленники получают доступ к информационным системам и остаются незамеченными, чтобы собрать конфиденциальные данные или нанести другой ущерб.

APT-атаки используются против ключевых секторов: промышленность, финансы, энергетика и госсектор. В 2024–2025 особенно активными стали китайские, северокорейские и неизвестные группировки. Целенаправленные атаки — особая категория угроз, исключительно против конкретной организации или государственного учреждения.

Цель злоумышленников — получить разные конфиденциальные сведения: коммерческую тайну, персональные данные пользователей, материалы под грифом «секретно», данные о стеке ИТ-решений или оборудовании, стратегические документы. Нередко объектом атаки становятся системы жизнеобеспечения компаний, веб-сайты организаций или отдельные элементы ИТ-инфраструктуры.

Как это работает

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

Как распознать и защититься

Фишинговые электронные письма

Чтобы получить несанкционированный доступ к корпоративным сетям, киберпреступники часто прибегают к использованию целевого фишинга. Они проводят небольшое «расследование» и получают все нужные данные, чтобы придумать привлекательные для сотрудников заголовки писем. В таких посланиях могут быть вредоносные вложения или ссылки с программами-шпионами, которые позволяют злоумышленникам контролировать систему. Лучшая защита от них — повысить осведомленность сотрудников и регулярно обучать их кибербезопасности, так как подходы атак постоянно меняются.

Скомпрометированные учетные записи

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

Чтобы не допустить целенаправленные атаки, нужно сегментировать сеть (разделять инфраструктуру на изолированные зоны с различными уровнями доверия, доступ между которыми строго контролируется, чтобы ограничить движение трафика) и контролировать привилегии доступа, а также внедрять Zero Trust политику.

Перемещение данных

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

ШИФРОВАЛЬЩИКИ / ВЫМОГАТЕЛИ (RANSOMWARE)

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

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

Цели — шантаж и нарушение работы сервисов. С помощью вирусов-вымогателей киберпреступники ежегодно зарабатывают порядка 2 миллиардов долларов. В большинстве случаев злоумышленники, используя вирусы-шифровальщики, блокируют доступ к важным данным на устройстве, вынуждая платить за восстановление. Обычно такие программы запрещают владельцам пользоваться собственными файлами и информацией до момента уплаты требуемого выкупа. Однако обещанный возврат доступа не гарантируется — зачастую злоумышленники нарушают данное слово.

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

Как это работает

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

Как распознать и защититься:

• Один из первых признаков заражения вирусом-вымогателем — потеря доступа к файлам, базам и документам. Пользователь замечает, что некоторые из них неожиданно перестали открываться или требуют ввода пароля несмотря на отсутствие настроек парольной защиты.
• Другой яркий признак — появление незнакомых расширений у инфицированных файлов, например, “.locked” или “.encrypted”. При этом обычные программы перестают распознавать и открывать такие объекты.
• Кроме того, в затронутых папках начинают появляться специальные инструкции, подробно объясняющие процедуру восстановления данных и требования к выплате компенсации за разблокировку.
• Рабочий стол компьютера также может подвергнуться изменениям: стандартная картинка заменяется сообщением с предупреждением о шифровании данных и требованиями о предоставлении выкупа.
• Наконец, антивирусные решения и прочие инструменты информационной безопасности могут подавать тревожные сигналы о наличии подозрительных процессов и действий в операционной системе.

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

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

АТАКИ НА ЦЕПОЧКУ ПОСТАВОК (SUPPLY CHAIN ATTACKS)

Прогнозируется, что к 2031 году убытки компаний от атак на цепочки поставок программного обеспечения увеличатся до колоссальных 138 миллиардов долларов ежегодно, превысив показатели предыдущих лет: 60 миллиардов долларов в 2025-м и 46 миллиардов долларов в 2023 году, учитывая постоянный годовой прирост на 15%.

Supply chain attack — относительно новый тип угроз, который нацелен на разработчиков ПО и поставщиков услуг или технологий. Они вошли в перечень наиболее распространенных угроз только в прошлом году из-за увеличившегося в три раза числа инцидентов по сравнению с 2023 годом.

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

Цели:

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

Как это работает

При осуществлении атаки на поставщиков ПО злоумышленники выбирают путь наименьшего сопротивления, проникая в защищенную сеть через слабое звено — небольшую фирму-подрядчика или разработчика программного обеспечения. Подобные нападения осуществляются двумя основными способами:

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

Как распознать и защититься

Опознать supply chain-атаку можно, если внимательно следить за сетевой активностью — она может показать необычные подключения или передачу больших объёмов данных. Также важно постоянно мониторить действия пользователей и систем — подозрительное поведение, редкие попытки доступа или запуск необычных процессов могут быть сигналом. Ещё один способ — отслеживать изменения в файлах, чтобы заметить несанкционированные вмешательства.

Вот несколько превентивных мер, чтобы защититься от supply chain attack:

• Регулярно проверяйте и контролируйте контрагентов, проводите обязательную верификацию.
• Используйте SBOM (Software Bill of Materials — перечень всех модулей и библиотек, необходимых для сборки программного продукта, а также указания их связи друг с другом). Он помогает команде видеть, где могут скрываться уязвимости — и заранее обновлять или заменять слабые места до того, как они станут проблемой.
• Реализовывайте политику обновлений с инспекцией. Например, отключите автоматическое обновление системы и программного обеспечения, с осторожностью устанавливайте апдейты вручную и тщательно тестируйте их работу перед использованием.
• Сегментируйте бизнес-процессы: так вы минимизируете возможные последствия кибератак: если одна зона подвергнется воздействию, остальные останутся надежно изолированными и сохранят свою безопасность. Сегментация помогает навести порядок в доступах: каждый видит только то, что нужно для работы — это снижает риск утечек и ошибок.

Сегодня компании и организации в РФ сталкиваются не с одной, а со множеством киберугроз, которые становятся только изощреннее. Но просто реагировать на инциденты недостаточно: нужно мониторить, работать на опережение и минимизировать риски. Поэтому подход к кибербезопасности должен быть стратегическим, техническим и операционным одновременно. Кольцевая защита, Zero Trust, повышение осведомленности персонала и контроль подрядчиков — то, без чего не обойтись.

Определяем цель

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

Некоторые программы помогают развивать существующий бизнес — как это делают банковские сервисы, которые упрощают работу с клиентами. Другие становятся самостоятельными продуктами, например, для обучения, занятий спортом или развлечений.

Кроме того, приложение должно решать реальные проблемы пользователей. Допустим, вы задумали создать программу для фрилансеров. Решили провести исследование, и оно показало, что фрилансеры часто страдают от прокрастинации и ненавидят заниматься выставлением счетов клиентам. Ваша идея и главная фишка — приложение, которое автоматизирует процесс оплаты, контролирует сроки выполнения проектов и помогает планировать рабочее время.

Чтобы убедиться, что идея действительно рабочая, проведите опросы в Telegram-каналах фрилансеров или создайте анкету. Вы можете спросить, какие функции для них наиболее актуальны: автоматический расчет налогов, интеграция с платежными системами или отслеживание времени работы. Это поможет сфокусироваться на действительно важных фичах и отсеять второстепенные.

Выбираем платформу и инструменты

Сегодня на российском рынке доминируют две мобильные операционные системы: Android (около 70% пользователей) и iOS (около 30%). Оптимальным решением будет разработка приложения для обеих платформ, особенно если вы ориентируетесь на крупные города, где доля пользователей iOS существенно выше.

Приложения под Android большинство разработчиков пишет на Kotlin, хотя Java до сих пор остается одним из вариантов из-за обширной базы готовых решений и библиотек. Основной средой выступает Android Studio — в ней есть весь необходимый инструментарий для создания, отладки и тестирования приложений. Современные разработчики активно используют Jetpack Compose для построения пользовательского интерфейса, Room для работы с базами данных, Retrofit для сетевых запросов и Dagger или Hilt для внедрения зависимостей.

В мире iOS основным языком программирования стал Swift — современный и безопасный инструмент для нативных приложений. Разработка ведется в среде Xcode, официальной IDE от Apple. Для построения интерфейсов все чаще используется SwiftUI, для управления данными — Core Data, а для сетевого взаимодействия — фреймворк Alamofire. Работа с асинхронными событиями упрощается с помощью фреймворка Combine.

При ограниченных ресурсах можно рассмотреть кросс-платформенную разработку. Так, Flutter использует язык программирования Dart и позволяет создавать производительные приложения с нативным внешним видом. React Native дает возможность применять веб-технологии для мобильной разработки, а Xamarin ориентирован на разработчиков, привыкших к экосистеме Microsoft и языку C#.

Выбор платформы и инструментов должен основываться на характеристиках вашей ЦА, требованиях к функционалу и имеющихся ресурсах. Учитывайте также, что для разных магазинов приложений (RuStore, App Store, Google Play) могут потребоваться специфические оптимизации и настройки.

Продумываем функционал

При разработке функционала важно следовать концепции MVP (Minimum Viable Product) — минимально жизнеспособного продукта. Это позволит быстрее выйти на рынок, получить обратную связь и итеративно улучшить приложение.

Возьмем для примера приложение доставки еды. В этом случае MVP должен включать:

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

Важно уделить внимание и техническим аспектам функционала:

• Локальное кэширование данных. Поддерживает работу приложения при слабом интернет-соединении или его отсутствии. Сохраняет каталоги, популярные позиции и историю действий пользователя.
• Офлайн-режим. Определяет набор функций, доступных без подключения к сети. Критически важен для удержания пользователей в зонах с плохим интернетом.
• Система пуш-уведомлений. Информирует пользователей о важных событиях, статусах заказов и специальных предложениях. Повышает вовлеченность и возвращаемость в приложение.
• Многопоточная обработка. Выполняет ресурсоемкие операции в фоновом режиме. Гарантирует отзывчивость интерфейса даже при выполнении сложных задач.
• Оптимизация изображений. Внедряет алгоритмы сжатия для быстрой загрузки визуального контента. Обеспечивает комфортное использование даже при ограниченной скорости соединения.

При этом разработчики часто допускают ошибки, и одна из самых распространенных — функциональная перегруженность. Не стоит добавлять AR-анимации, игровые механики и другие «модные» функции, если они не решают реальных проблем клиентов.

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

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

• MVVM — рекомендуемый Google подход с разделением UI и бизнес-логики
• MVI — однонаправленный поток данных, хорошо сочетается с реактивным программированием
• MVP — классическая архитектура. Популярна благодаря простоте реализации
• Clean Architecture — многослойный подход с упором на тестируемость и гибкость
• VIPER (iOS) — расширенный MVC со строгим разделением ответственности

Важное значение имеет также выбор технологий для хранения и передачи данных. Для локальной работы подойдут SQLite + Room, Realm или DataStore; для сетевого взаимодействия на Android чаще всего используют Retrofit + OkHttp, а в реактивных сценариях — Ktor Client.

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

Создаем удобный интерфейс

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

Эффективный UI/UX строится на пяти ключевых принципах:

1. Очевидность (интуитивное понимание интерфейса);
2. Экономия внимания (минимум шагов для достижения цели);
3. Консистентность (единообразие элементов с одинаковой функциональностью);
4. Обратная связь (видимый результат каждого действия);
5. Прощение ошибок (возможность отмены операций).

Современные инструменты значительно ускоряют создание качественных интерфейсов. Дизайнеры используют Figma, Adobe XD и Sketch для прототипирования. Android-разработчики предпочитают Jetpack Compose и Material Design Components. Для iOS актуальны SwiftUI, UIKit и Human Interface Guidelines от Apple.

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

Проводим тестирование

Юзабилити-тесты с фокус-группами, A/B-тестирование элементов и аналитика пользовательского поведения дают объективную картину взаимодействия клиентов с приложением.

Комплексное тестирование включает два основных направления:

1. Автоматизированное тестирование: unit-тесты (JUnit, XCTest) для проверки отдельных компонентов; интеграционные тесты для проверки взаимодействия между модулями; UI-тесты (Espresso, XCUITest) для проверки интерфейса; end-to-end тесты для имитации полного пользовательского сценария.
2. Ручное тестирование: функциональное (соответствие требованиям), тестирование производительности (работа под нагрузкой), юзабилити (оценка удобства), кросс-платформенное тестирование (проверка на разных устройствах) и тестирование подключений (поведение при различном качестве интернет-соединения).

Для этого используют специализированные инструменты: Firebase Test Lab для запуска тестов на множестве устройств, Crashlytics для мониторинга сбоев, Android Profiler и Xcode Instruments для анализа производительности. А Accessibility Scanner помогает адаптировать интерфейс для людей с ограниченными возможностями, расширяя потенциальную аудиторию.

Публикуем приложение

После тестирования и исправления проблем наступает ответственный момент публикации. Каждый магазин приложений имеет свои особенности процесса:

• Google Play: создание аккаунта разработчика ($25 единоразово); подготовка материалов (иконка, скриншоты, видео, описание); загрузка APK/App Bundle; заполнение формы оценки контента; настройка дистрибуции и ценообразования; ожидание проверки (до 2 дней).
• App Store: регистрация в Apple Developer Program ($99/год); создание записи в App Store Connect; подготовка маркетинговых материалов; загрузка сборки из Xcode; заполнение информации о возрастных ограничениях; ожидание рассмотрения (1-7 дней).
• RuStore: бесплатное создание аккаунта; подготовка материалов; загрузка APK; заполнение метаданных; быстрая модерация (до часа).

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

Поддерживаем и обновляем

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

Для эффективного мониторинга используют комплексные аналитические инструменты: Firebase Crashlytics для отслеживания сбоев, Firebase Analytics/Google Analytics для анализа пользовательского поведения, RuStore Remote Config — бесплатный аналог Firebase, Mixpanel для углубленного анализа пользовательских путей, AppMetrica от Яндекса как комплексное решение для российского рынка.

Автоматизация процессов разработки критически важна для регулярных релизов. CI/CD-системы (GitHub Actions, GitLab CI, Bitrise, Fastlane) позволяют автоматизировать сборку, тестирование и публикацию обновлений, значительно сокращая время выхода новых версий.

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

Продвигаем приложение

На рынке огромная конкуренция, и без активного продвижения ваш продукт просто затеряется среди тысяч других программ. Важную роль здесь играет ASO (App Store Optimization) — оптимизация для магазина приложений. В некоторых случаях был зафиксирован рост установок до 70% благодаря сильным ASO-стратегиям.

Для Android-приложений это означает настройку страницы так, чтобы пользователи легко находили ваш продукт. Здесь важно правильно подобрать ключевые слова для описания, создать привлекательную иконку и подготовить качественные скриншоты. Чтобы понять, какое оформление работает лучше, разработчики всё чаще используют A/B-тесты — такая возможность есть, например, в RuStore. Она позволяет сравнить разные версии карточки приложения и выбрать ту, которая эффективнее привлекает пользователей.

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

Еще один инструмент для продвижения приложений — социальные сети. Здесь можно показывать функционал программы, общаться с пользователями, отвечать на их вопросы и рассказывать о новых опциях. Это помогает создать активное сообщество вокруг продукта. Так, к примеру, В 2023 году компания Geozilla, разработчик приложения для отслеживания местоположения близких, провела кампанию по продвижению с инфлюенсерами в социальных сетях. В рамках сотрудничества удалось собрать более 1 миллиона просмотров, а коэффициент конверсии из кликов в установки приложения составил 24%.

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

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

Подводим итоги

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

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

iOS или Android? React Native или Flutter? Собираем все новости и гайды по мобильной разработке тут.

В рейтинге языков программирования TIOBE Rust занимает 14 место. Для сравнения — в прошлом марте он был на 17 позиции. Вместе с экспертами Solvery Василием Кузенковым, full-stack разработчиком в Web3 стартапе, и Дмитрием Беляевым, Rust developer в Wildberries, разбираемся, как стать разрабом на Расте в 2025 году.

Немного об особенностях

Если вы до этого программировали на ООП языках, то вам, возможно, бросалось в глаза отсутствие привычных классов. Вместо них здесь алгебраические типы данных и трейты для решения expression problem. Их механизм куда больше похож на typeclasses из Haskell, что также будет для вас новой концепцией при построении крупных приложений, и нужно будет перестраивать мышление.

Также когда стартуешь, немного непривычно работать с move-семантикой, RAII, borrow checker’ом и лайф-таймами. Но компилятор сыпет довольно подробными ошибками, которые можно легко поправить, если разобраться.

А еще у Rust очень строгая типизация и очень мощная система типов, а сами типы построены так, чтобы предоставлять некоторые гарантии программисту. Например, ссылки в Rust всегда ссылаются на объект, гарантировано существующий в памяти, а стандартные строки содержат только валидный UTF-8. При этом в подавляющем большинстве случаев тип необязательно указывать явно, компилятор способен выводить типы, анализируя контекст функции целиком. Кроме того, Rust следует идеологии «компилируется, значит, работает». От логических ошибок, конечно, Раст не спасёт, но тем не менее очень большой пласт багов можно отловить на этапе кодинга. Да, это сложно, но лучше помучиться при разработке, чем потом разбираться почему упал прод.

Ещё одна отличительная фишка — абстракции с нулевой стоимостью. Rust позволяет писать высокоуровневый и понятный код, который при этом будет иметь ту же производительность, что и более низкоуровневый оптимизированный вручную вариант.

Хороший пример здесь — итерация по различным коллекциям. Многие языки позволяют использовать итераторы с их абстракциями вроде map или filter. Только такой код, как правило, будет в несколько раз медленнее, чем если то же самое переписать на циклы. Компилятор Rust способен развернуть такой итератор в обычные циклы сам, и производительность будет сравнима, а порой даже лучше, так как программисты часто при написании низкоуровневого кода заставляют процессор делать много лишних вычислений.

Сложно ли переходить на Rust

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

На рынке фактически все вакансии требуют уже какого-то опыта в разработке. И сложность перехода сильно разнится от вашего текущего стека. Для Go-программиста переход будет средне-сложным, а язык, возможно, покажется перегруженным. Для С++ — менее сложным, но язык покажется местами ограничивающим. Я переходил на него с JS/TS’а и столкнулся со множеством низкоуровневых концепций, о которых раньше мог не задумываться. Но если у вас есть опыт в системном программировании — переходить будет в разы проще.

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

В моей практике менторства много успешных кейсов перехода на Rust с самых разных языков, но проще всего он даётся тем, кто раньше писал на современном C++ и уже понимает такие концепции, как move-семантика и RAII. Много привычного здесь обнаружат и те, кто писал на функциональных языках (Haskell или OCaml). Но в целом, для остальных тоже нет никаких проблем, даже если вы совсем новичок.

С чего начать изучать Rust

Вместе со стартом в изучении языка с The Rust Book — бесплатной официальной книгой по Rust’у — стоит углубить свои знания в более низкоуровневых вещах: в чем разница стека и кучи, что такое разметка памяти и адресация в памяти, как работает процессор, подходы и проблемы многопоточного программирования, плюс почитать про операционные системы и сети. Если вы решили осознанно применять Rust, оно вам пригодится.

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

Вот примерный список того, что нужно учить на старте:

• Переменные. Они по умолчанию неизменяемые (let x). Чтобы x стал изменяемым, нужно указать это явно через let mut. Константы (const) и статические переменные (static) вам будут нужны редко, они имеют свои особенности.
• Типы. Стоит разобраться с составными типами, такими как массивы и кортежи, а также с пользовательскими объявляемыми конструкциями struct (тип-произведение) и enum (тип-сумма). Также типы данных в Расте есть стандартные: bool, i32, u64 и прочие числовые, но строки могут удивить, так как их видов сильно больше.
• Match. Нужно понять такую вещь, как pattern-matching, познакомиться с оператором match, а также осознать, что pattern-matching применяется не только в нём, а везде, где возможно объявление переменных.

Таким образом, вы можете сразу проверить что-то и присвоить результат в переменную:

Здесь мы сразу проверили и присвоили:

Тут нам потребовалась дополнительная изменяемая переменная.

Что такое Cargo

Cargo — это консольная утилита, которая устанавливается вместе с компилятором языка. Она служит одновременно для управления зависимостями, сборки проекта и запуска тестов. Плюс для Cargo есть расширения, например, в поставке по умолчанию уже есть форматтер и линтер clippy.

Cargo рассчитан на то, что вы будете запускать его через терминал, самые полезные команды это:

• cargo new — создаёт новый шаблонный проект в указанной папке;
• cargo build — собирает проект;
• cargo run — собирает проект и запускает получившийся исполняемый файл;
• cargo check — dry-run сборки, делает все проверки компилятора, но ничего не собирает, что заметно быстрее полноценной сборки;
• cargo test — собирает проект со всеми тестами и запускает их;
• cargo fmt — форматирует проект в общепринятый стиль кода;
• cargo clippy — запускает линтер, очень полезно, можно подсказать более оптимальные варианты кода, найти некоторые потенциальные логические ошибки;
• cargo install — устанавливает пакет, содержащий исполняемые файлы;
• cargo clean — очищает все артефакты сборки.

Cargo позволяет описать структуру, настройки (профили сборки, описание крейта) и зависимости вашего крейта или даже монорепозитория (с помощью workspace). Кроме непосредственного запуска через терминал, многие вещи могут запускаться через средства интеграции в IDE, такие как rust-analyzer для VSCode.

Как работать с ownership, borrowing и lifetimes?

Для многих новичков системы владения (ownership), заимствования (borrowing) и времен жизни (lifetimes) выливаются в борьбу с компилятором раста. Эти механизмы нужны в первую очередь для безопасности памяти без сборщика мусора. Общее правило владения такое:

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

Когда значение перемещается (передается другой переменной или функции), владение переходит, и исходная переменная становится недействительной.

Для типов, реализующих трейт Copy (например, целые числа, булевы значения), значения копируются автоматически:

Для более сложных типов нужно использовать метод clone(), чтобы создать глубокую копию. В местах программы, где производительность не так важна — использование clone() не возбраняется.

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

Заимствование позволяет использовать значение без получения владения через ссылки (& и &mut). Для мутабельных ссылок `&mut` есть дополнительные ограничения: в каждый момент времени может существовать только одна изменяемая ссылка на значение.

Нельзя иметь изменяемую ссылку, если уже есть неизменяемая ссылка на то же значение.

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

Аннотация 'a указывает, что возвращаемая ссылка будет жить как минимум столько же, сколько кратчайшая из входных ссылок.

Общие советы по заимствованию здесь такие:

• Используйте ссылки, когда не нужно владение.
• Возвращайте значения из функций для передачи владения обратно.
• Используйте клонирование для создания новых экземпляров (с пониманием стоимости).
• Используйте типы с трейтом Copy, когда это возможно.
• Еще полезно не забывать о контейнерах. Rc<T> позволяет иметь несколько владельцев одного значения через счетчик ссылок, а RefCell<T> обеспечивает проверку правил заимствования в рантайме.

О структурах, перечислениях, модулях и функциях, замыканиях, итераторах

Структуры (structs) в Rust позволяют создавать пользовательские типы данных, объединяющие связанные значения и выступающие типом произведения.

Перечисления (enum) позволяют определить тип, перечисляя все возможные варианты значений.

Перечисления в Rust являются типами суммы, поскольку значение может быть одним из вариантов:

Тип Shape представляет объединение (сумму) всех возможных вариантов. И к этому есть мощное сопоставление с образцом для работы с ADT:

Модули позволяют организовать код и контролировать видимость элементов. Определяются они через синтаксис mod <name> {} и могут быть вложенны друг в друга:

Также модули могут быть организованы в различных файлах (имя файла в таком случае будет именем модуля):

Импорт модуля осуществляется через ключевое слово use:

Функции в Rust определяются через ключевое слово fn:

Можно делать функции высшего порядка и передавать в них, как обычные, так и анонимные функции:

Еще одним элементом функционального программирования в Rust выступает итератор:

Здесь мы создаем собственный итератор Counter, реализуя стандартный трейт Iterator. Он используется для многих встроенных коллекций, таких как Vec или HashMap. Этот трейт особенно удобен из-за различных функциональных комбинаторов из стандартной библиотеки:

Трейт Iterator предоставляет множество методов адаптеров, таких как enumerate, filter или map, которые возвращают новый итератор. Методы адаптеров ленивые, они не запускают итерацию. Также есть методы исполнители, которые итерируют пока не закончатся значения, например, collect, fold или count.

Большинство коллекций (и ссылки на них) реализуют трейт IntoIterator (способность кастоваться в Iterator). Также IntoIterator автоматически реализуется для любого Iterator (ничего не стоящий каст сам в себя). Цикл for в Rust работает только с объектами, реализующими IntoIterator.

Как обрабатывать ошибки в Rust

В Rust принято разделять ошибки на 2 вида: паники и результаты операций:

• Паники используются для непредвиденных ситуаций и ошибок программиста, например, деление целочисленного типа на 0 или выход за границу массива. И хотя паники можно отловить, стандартное и рекомендуемое поведение при них — программа упадёт, будет напечатан стектрейс.
• Результаты операций выражаются типом Result<T, E>, который является перечислением из двух вариантов — Ok(T) и Err(E). Такой подход гарантирует, что все ошибки строго типизированы, а без обработки ошибки невозможно извлечь результат операции.

Option<T> используется для представления значения, которое может отсутствовать:

Result<T, E> используется для операций, которые могут завершиться ошибкой:

Для удобства проброса ошибок наверх существует оператор ?, который пишется после любого выражения, возвращающего Result, и возвращает Ok вариант. В случае Err варианта будет выход из функции с возвращением ошибки.

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

Про асинхронное программирование

Асинхронное программирование в Rust строится вокруг трейта Future— его реализуют для типов, представляющих значение, которое будет доступно в будущем.

Также в Rust есть синтаксис async/await. Ключевым словом async могут быть отмечены функции и блоки кода — они будут возвращать анонимный тип, реализующий Future. Async-блоки также могут захватывать окружение подобно замыканиям. Внутри async-блоков и функций возможно использовать ключевое слово await на любом выражении, возвращающем Future или IntoFuture (способность кастоваться к Future). В отличие от других языков с подобным синтаксисом, await записывается через точку после выражения, что очень удобно для построения цепочек вычислений.

Для исполнения асинхронного кода необходим рантайм, но стандартная библиотека такого рантайма не предоставляет, поэтому приходится использовать сторонние библиотеки. Самым популярным рантаймом является библиотека tokio.

В асинхронное программирование на Rust я рекомендую приходить уже после углубленного изучения языка, первых пет-проектов и небольшой работы с многопоточным кодом. Хотя синтаксис и общие правила работы с асинхронным кодом покажутся знакомыми тем, кто знает JS или C#, из-за более низкоуровневой природы языка работать с ним немного сложнее.

Что еще должен знать новичок в Rust

Вот примерный список:

• Очень желательно погрузиться в устройство памяти процесса, узнать, что помимо стека и кучи существуют и другие области (например, исполняемый машинный код так же отражён на память, а static-переменные хранятся не в стеке и не в куче, а в своей собственной области). Неплохо было бы и разобраться с тем, что у типов помимо размера есть выравнивание. Что в Rust бывают ZST (zero size type) — типы, размер которых честный 0, и DST (dynamic size type) — типы, размер которых неизвестен во время компиляции.
• Обязательно разобраться, как Rust освобождает память, не используя сборщик мусора. Почитать, что такое RAII. Понять, как работает трейт Drop.
• Избавится от стереотипов о Rust. Rust — не самый сложный язык, как только вы поймёте, как он работает. Плюс платят за Rust, как правило, больше, чем на аналогичных позициях на других языках.
• Оставить свои привычки из других языков (за исключением разве что Haskell/OCaml). Здесь не получится писать, как на C++/Java/Go и т.д. Привыкайте к хорошему и станете лучше, чем были до освоения Rust.

Что изучать, если есть вся база: чек-лист

• Макросы и метапрограммирование
• Unsafe Rust для низкоуровневого контроля
• Интеграция с C/C++ через FFI
• Разработка встраиваемых систем
• WebAssembly
• rustnomicon
• Undefined Behavior
• unsafe-код

Тренды на 2025 год

На Rust’е пишут все. Более полный список можно посмотреть тут: https://github.com/rust-unofficial/awesome-rust

Вот несколько топовых фреймворков и библиотек:

• serde — фреймворк для сериализации/десериализации
• tokio, futures — для асинхронного программирования
• clap — парсер аргументов командной строки
• anyhow, thiserror — удобная работа с ошибками
• chrono — работа с датой и временем
• dashmap — многопоточная hashmap
• bytes — эффективная работа с сырыми байтами
• log, tracing — для логирования
• reqwest — для http запросов
• axum — для http сервера и REST api
• mockall, test-case — упростит написание тестов
• bevy — игры
• clippy — линтер

Без свободного ПО компаниям пришлось бы тратить в 3,5 раза больше на разработку собственного софта.

Почти 96% всей кодовой базы современных IT-продуктов содержит open-source. При этом 93% ценности создают лишь около 3000 разработчиков по всему миру — менее 5% от общего числа.

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

Сколько стоит создание и сколько — замена

Из-за отсутствия ценников и продаж open-source нельзя оценить напрямую — как товар. Поэтому исследователи пошли другим путем: они рассчитали «ценность предложения» и «ценность спроса».

• $4,15 млрд — столько стоила бы разработка всех open-source проектов заново;
• $8,8 трлн — столько пришлось бы заплатить компаниям, если бы они создавали аналоги сами.

То есть спрос превышает предложение в 2000 раз. Для сравнения: в 2020 году глобальные расходы на весь софт составили $3,4 трлн — в два с лишним раза меньше.

Go — король корпоративного open-source

Больше всего коммерческого спроса — у проектов на Go. Их «ценность спроса» превышает $5 трлн, тогда как JavaScript — на втором месте с $1,2 трлн. Java и C уступают им почти вдвое.

При этом стоимость создания Go-проектов оценивается в $803 млн — это меньше, чем их потенциальная коммерческая выгода почти в 7000 раз.

Удивительно, но Python при высокой популярности на GitHub имеет низкую стоимость предложения — $55 млн. Это связано с тем, что крупные корпоративные системы реже завязаны на Python как основном языке.

Open-source — общее благо

Исследование базируется на анализе двух наборов данных: open-source коде, интегрированном в продукты компаний, и коде, размещенном на их сайтах. Операционные системы вроде Linux в расчет не брались.

В качестве основы для оценки использовались данные о зарплатах разработчиков в 30 странах с наибольшей активностью на GitHub.

Авторы подчеркивают: open-source — это цифровое общественное благо. Компании, которые его используют, должны активнее участвовать в его развитии. А государства — поддерживать эти процессы на системном уровне.

«Я думаю, что могу смело утверждать: квантовую механику не понимает никто».

По этой причине многие идеи оставим без внимания — попытка их объяснения растянется на десяток страниц. Также не будет формул и страшных математических моделей.

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

Определения и квантовая путаница

Кубиты

Квантовые вычисления строятся на основе кубитов. Они существуют как физические объекты. Законы квантовой механики проявляются на фотонах, электронах, ионах, атомах.

Самое интересное — если обычный бит принимает значение 0 или 1, то кубит находится в суперпозиции. Его состояние описывают диапазоном от 0 до 1, и оно непрерывно меняется.

Суперпозицию можно рассмотреть на примере монетки. На столе она лежит орлом вверх (0), либо решкой (1). Теперь представьте, что монету подбросили, — она вращается в воздухе и находится как бы в обоих состояниях одновременно.

Квантовая запутанность

В квантовой механике что не явление, то необъяснимое событие. Одно из таких — запутанность. Два отдельных кубита оказываются «связаны», игнорируя расстояние.

Например, если измеряете один кубит, то автоматически узнаете состояние другого. Даже если второй находится на Марсе.

Квантовый брутфорс

Битами классических компьютеров управляют логические операторы — И, ИЛИ, НЕ.

Состоянием кубитов управляют гейты. Они «переставляют» квантовые вероятности, чтобы получить диапазон с правильным ответом.

Представьте замок и 40 ключей. Только один из них подходит. Классический компьютер попробует каждый ключ по очереди. Квантовый образец одновременно «проверит» все варианты, затем с помощью гейтов сузит поиск до верного.

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

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

Представьте идеально сбалансированную иголку. Ваша задача, как ученого, — установить иглу на самый кончик и удерживать в равновесии как можно дольше.

Он — компьютер, но квантовый

Есть мнение, что квантовый компьютер (КК) вовсе не компьютер, потому что выдает не точный, а приблизительный ответ.

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

Справедливое замечание: без классического компьютера квантовые вычисления — бесполезны.

КК отсекает решения, невозможные из-за противоречивости, и обозначает предел с ответом. Искать это точное решение и выбирать из нескольких выданных вариантов — задача обычного ПК.

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

Как квантовые вычисления повлияют на программирование

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

С появлением достаточно мощного КК использование RSA и AES будет небезопасным. Поэтому IT-компании уже разрабатывают квантовую криптографию, чтобы защитить данные до появления угрозы.

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

Машинное обучение тоже выигрывает от развития квантовых вычислений. Скорость обучения нейросетей увеличится в разы.

Классические алгоритмы vs квантовые алгоритмы

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

Например, алгоритм Шора. Он раскладывает числа на множители, но работает только на квантовом компьютере.

На классическом ПК методы нахождения множителей начинают работать медленнее. Скорость замедления растет с величиной числа. Классические методы требуют так много вычислений, что время выполнения растет экспоненциально (как снежный ком):

• Для числа размером 2 цифры — очень легко.
• Для числа размером 10 цифр — сложнее, но реально.
• Для числа размером в 300 цифр (как в RSA-криптографии) — может занять тысячи лет.

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

Другой пример — алгоритм Гровера. Он ускоряет поиск в неструктурированных базах данных.

В списке из 1000 элементов обычный компьютер проверит до 1000 записей. Алгоритм Гровера проверит всего √1000 ≈ 31 запись.

Нужны ли новые языки программирования?

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

Qiskit

Разработчик: IBM

Популярный Python-фреймворк для программирования квантовых алгоритмов. На нем можно написать программу и выполнить ее на симуляторе. Есть возможность запускать алгоритмы на реальных квантовых компьютерах IBM через облако.

Cirq

Разработчик: Google

Библиотека на Python для создания и тестирования технологий квантового вычисления. Cirq чаще используют для работы с алгоритмами Гровера, Шора и др. Программу можно протестировать на симуляторе.

Q#

Разработчик: Microsoft

Q# — это часть Microsoft Quantum Development Kit (QDK). Он содержит инструменты для симуляции, разработки программ и интеграции квантовых вычислений с кодом на C# или Python.

Какая математика потребуется разработчикам?

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

Векторы показывают, где кубит «находится» в пространстве, а матрицы управляют его изменениями.

Все квантовые операции — это просто умножение вектора состояния на матрицы. Но результат нельзя узнать до момента измерения, поэтому вероятность каждого расчета задается квадратичными модулями коэффициентов.

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

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

Когда начинать изучать квантовые вычисления?

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

Уходить сегодня из фронтенда в разработку квантовых программ — это как создавать ИИ в 80-х годах.

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

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

Какие компании уже инвестируют в квантовые вычисления?

IBM — лидер в разработке квантовых технологий. Их платформа IBM Quantum Experience предоставляет доступ к настоящим квантовым компьютерам через облако.

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

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

Microsoft раньше других взялась за развитие языка программирования для квантовых вычислений — Q#. Вместе с этим доступен Quantum Development Kit, который моделирует квантовые программы и тестирует на симуляторах.

Amazon тоже не осталась в стороне. Компания предлагает облачный сервис AWS Braket, интегрирующий работу с квантовыми симуляторами.

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

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

Через 10 лет можно ожидать стабильных образцов с тысячами кубитов. Это станет отправной точкой для коммерческой квантовой индустрии.

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

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

Инструменты и платформы для начала работы

Если не терпится попробовать квантовую разработку, обратите внимание на следующие инструменты.

IBM Quantum Experience и Qiskit

IBM Quantum Experience — это облачная платформа. Она поддерживает запуск кода на реальном квантовом компьютере — 5-кубитном IBM Quito. Платформа содержит учебные курсы, в том числе серию статей по основам квантовой механики.

Чтобы программировать кубиты, зарегистрируйтесь на IBM Quantum Experience и познакомьтесь с библиотекой Python Qiskit.

Пример квантовой схемы:

В библиотеке Qiskit есть модули для изучения оптимизации, машинного обучения и квантовой химии. Если хотите протестировать программу на реальном образце КК, подключайтесь через API.

Google Cirq

Google Cirq — это библиотека Python для создания, выполнения и отладки квантовых вычислений на симуляторах или реальном оборудовании Google. Cirq подходит для тех, кто хочет более программно ориентированный подход к квантовой механике.

Особенности:

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

Пример квантовой схемы:

Чтобы использовать физический процессор, нужно подключиться к облаку Google Quantum.

Microsoft Q#

Q# — язык с высоким уровнем абстракции. Его используют, чтобы сосредоточиться на алгоритмах без погружения в низкоуровневую обработку кубитов.

Для работы с Q# понадобится Quantum Development Kit, .NET, расширение для Visual Studio или VS Code.

Простая программа на Q#:

Код выполняется через симулятор, встроенный в QDK.

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

Симуляторы

Чтобы лучше понять работу квантовых вычислений, стоит начать с симуляторов:

• IBM Aer. Входит в состав Qiskit, имитирует шумовые и идеальные квантовые процессы.
• Google Cirq’s Simulator. Интегрирован в библиотеку Cirq, поддерживает широкий спектр квантовых операций.
• Microsoft Quantum Simulator. Разработан для работы с Q#, позволяет запускать программы и тестировать квантовые алгоритмы.
• QuTip. Библиотека Python для работы с квантовыми системами, поддерживает симуляцию квантовых состояний, унитарных операций и вычислений.

Если вы новичок — используйте Qiskit + IBM Aer.

Любите низкоуровневое программирование? Google Cirq — ваш выбор.

Чувствуете, что вам нужен язык высокого уровня с интеграцией в классические приложения? Тогда изучайте Q# + Microsoft Quantum Simulator.

Что в итоге?

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

IBM, Microsoft и Google развивают экосистемы для новых специалистов. Есть симуляторы и обучающие материалы. Они немного облегчают вход в эту сферу.

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

Несмотря на то, что книга посвящена устаревшей версии Linux 2.6, многие концепции до сих пор актуальны.

Как устроена работа ядра Linux

По словам Каваллина, программирование в ядре Linux существенно отличается от работы в пользовательском пространстве.

Среди ключевых особенностей он выделил:

• Отсутствие стандартной библиотеки C – вместо нее используются встроенные аналоги из ядра.
• Жесткие ограничения на память – размер стека фиксирован (например, 8 КБ на 64-битных системах).
• Ошибки могут привести к сбоям в системе – некорректный доступ к памяти вызовет «oops», что потенциально может привести к краху всей ОС.

Каваллин также отметил, что в Linux потоки и процессы не являются разными сущностями. Они представляют собой один объект – task_struct, а функции clone(), fork(), pthread_create() просто создают его вариации.

Как ядро Linux выбирает, что запустить?

Одной из ключевых задач ядра является планирование процессов.

В Linux этим занимается Completely Fair Scheduler (CFS), который распределяет процессорное время по принципу виртуального времени (vruntime).

• Процессы с высоким приоритетом получают больше времени на выполнение, так как их vruntime растет медленнее.
• Используется красно-черное дерево, где в первую очередь запускается процесс с наименьшим vruntime.
• Реальное время (RT) обрабатывается отдельно – процессы с приоритетом от 0 до 99 выполняются раньше обычных задач.

Системные вызовы и работа с ядром

Системные вызовы – это точка входа из пользовательского пространства в ядро.

Они обрабатываются через syscall, а ядро проверяет переданные параметры с помощью copy_from_user() и copy_to_user(), предотвращая утечки памяти и ошибки доступа.

Прерывания и работа с устройствами

Для обработки аппаратных событий Linux использует прерывания, которые делятся на два уровня:

1. Верхний уровень (ISR, Interrupt Service Routine) – выполняет только критически важные операции, так как в этот момент остальные прерывания отключены.
2. Нижний уровень (bottom half) – завершает обработку через tasklet, softirq или workqueue, снижая нагрузку на систему.

Каждое прерывание в Linux возвращает IRQ_HANDLED, если оно обработано, или IRQ_NONE, если источник сигнала не был обнаружен.

Синхронизация и защита от гонок данных

Каваллин подчеркнул, что работа ядра на многопоточных системах требует защиты от гонок данных. Для этого применяются:

• spinlock – блокировка без ожидания, используется в обработке прерываний.
• mutex и семафоры – механизмы ожидания освобождения ресурса.
• seqlock – механизм, позволяющий приоритетно обновлять данные.

Вывод

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

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

Проект был основан Марком Шаттлвортом, миллионером из Южной Африки, принимавшим участие в разработке Debian и воодушевлённым идеей создания доступного для конечных пользователей настольного дистрибутива с предсказуемым циклом разработки.

К разработке были привлечены несколько разработчиков из Debian — многие из них до сих пор принимают участие в развитии обоих проектов.

Первая версия Ubuntu поставлялась с GNOME 2.8, Firefox 0.9 и OpenOffice.org 1.1.2. Ubuntu 4.10 остаётся доступной для загрузки и сегодня, что позволяет взглянуть, как выглядела система 20 лет назад.

Как Ubuntu изменила мир Linux

Ubuntu стала одной из самых популярных и узнаваемых версий Linux.

Её успех был обусловлен удобством использования, регулярными обновлениями и дружелюбным сообществом.

С самого начала разработчики уделяли особое внимание тому, чтобы сделать дистрибутив максимально доступным для всех — от новичков до профессионалов. Это привело к тому, что Ubuntu стала стандартом для множества пользователей, которым нужен стабильный и простой в использовании Linux.

Достижения и влияние

Ubuntu повлияла не только на мир Linux, но и на всю экосистему свободного ПО. С её появлением стало проще установить и использовать Linux на домашних и рабочих компьютерах.

Это привело к росту популярности Linux среди широкой аудитории и положило начало множеству других проектов и инициатив, таких как Ubuntu Server, Ubuntu Touch и т.д.

Ubuntu также сыграла ключевую роль в развитии облачных технологий.

Canonical, компания, стоящая за Ubuntu, активно продвигает решения на основе Ubuntu для серверов и облаков, что делает её важным игроком в мире технологий и ИТ-инфраструктуры.

Впервые представленная на платформе Reddit, Puter предлагает пользователям возможность работать с полноценной ОС через браузер, обеспечивая легковесность и гибкость.

Puter — браузерная интернет-ОС с открытым исходным кодом: полноценный рабочий стол, файловый менеджер и терминал без установки.

Поддерживает самохостинг — разворачивайте на своём сервере и полностью контролируйте среду и данные.

За год проект набрал более 150 000 установок, 22 000 звёзд на GitHub и локализацию на 38 языков.

JavaScript-стек и открытый API позволяют разработчикам встраивать Puter в свои приложения или расширять его функциональность.

История создания и развитие проекта

Puter был анонсирован еще два года назад, но свой рост начал лишь весной 2024 года и достаточно быстро привлек внимание благодаря своей открытости и доступности.

Проект, начавшийся как личная инициатива одного разработчика, за короткое время собрал внушительное сообщество. Сегодня Puter насчитывает более 150 000 установок, 22 000 звезд на GitHub и поддерживается на 38 языках.

Особенности и возможности

Puter — это не просто браузерная ОС, а мощная среда для разработки и управления веб-приложениями.

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

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

Удобство использования и интерфейс

Если вас интересует тема открытых проектов, читайте также: лучшие open source-проекты на GitHub и обзор актуальных JavaScript-фреймворков.

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

Поддержка сообщества и будущее

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

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

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

Ознакомиться с проектом можно через его официальный репозиторий. Лайв-демо Puter также доступно по ссылке.

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

Уверен многие слышали о Linux, но не осмеливались переходить или пробовать данную ОС. Возможно из-за комментариев на форумах, сайтах, в каких-либо других сообществах, где комментарии олицетворяли ОС, как сложную, тяжкую и подавляющую всякое желание ее устанавливать/пробовать, но поверьте — это, лишь 20% от правды и то в зависимости от дистрибутива (некая ОС построенная на ядре Linux, которая может отличаться от своих ядро-соратников).

Многие "умельцы" умудряются сравнивать Linux и Windows, ладно бы Macintosh и Linux, но нельзя сравнивать с Windows, скажу кратко — это как фрукт и овощ, в остальном забудьте, Linux не стоит рядом с Windows, как и Windows с Linux.

Об истории зарождения Linux, а точнее UNIX — ее корня развития, я умолчу, ибо оно вам не надо, для того, чтобы попробовать, влиться в эту ОС. Все, что вам нужно — это, причины, по которым вы, точно захотите установить себе Linux, а точнее, какой-либо из дистрибутивов, но о них позже.

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

Путь в удивительно разнообразный и свободный, для мысли и дел мир, начинается...

Глава 1. Почему, так страшно, хотя еще ничего нет

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

Существуют дистрибутивы, которые, после установки имеют графическую оболочку (GUI), а некоторые ее не имеют, вместо GUI, у них CLI (консольная среда, черный экран белые шрифта). Графические оболочки различаются между собой, зачастую внешним видом и функционированием внешнего вида, но независимо от GUI, все дистрибутивы работают с такой замечательной программой как консоль (терминал), они бывают разные, а большинство из них поддерживают популярные командные оболочки как Bash, Zsh и пр.

Если вам приходилось работать в CMD/PowerShell в Windows, то это, то же самое, что и Bash в Linux, только круче.

На сегодня, вам доступно масса методов к установке/созданию/крафту собственного дистрибутива, но не будем, пока думать, что дистрибутивы можно создавать в ручную, остановимся на том, что имеем на рынке:

• Debian — стабильный, проверенный многолетним стажем дистрибутив, готовый с коробки.

• Arch Linux — стабильный, ориентированный на ручную настройку всех компонентов.

• Ubuntu — мобильный, простой и эффективный дистрибутив, подходящий для любого пользователя.

• CentOS — коммерческий продукт, доступный бесплатно, обычный дистрибутив.

• Fedora — комплексное решение для продвинутых пользователей.

• Kali Linux — ориентированный на белых хакеров и прочих тестеров в ИБ, дистрибутив.

В самом деле, дистрибутивов масса, есть как для новичков (Ubuntu, Mint, Manjaro), так и для продвинутых и/или средних пользователей (Arch, Kali, Debian, Fedora).

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

А теперь о том, как эти дистрибутивы могут выглядеть:

Впрочем, здесь вы можете увидеть больше информации и подобрать для себя, что-нибудь.

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

Я, не буду приводить команды Bash и их описание, а также, для чего они нужны, а вы пишите комментарии, хотите ли видеть, статью по Bash.

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

Захотели обновление ОС в определенное время, пожалуйста. Кастомизация отдельного текста, окна, вида программ, конечно. Некую защиту от вирусов и стабильность в производительности, посредством open source ПО, есть такое.

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

И это верно, несмотря на то, что Linux, является безопасной системой, безопаснее, даже Windows и в какой-то степени MacOS, он не лишен вероятности взлома, да, в нем множество утилит, есть доступные брандмауэры, которые защитят ОС, но в остальном, как и для любой другой ОС, как вы настроите, как вы будете пользоваться своей ОС, так и вирусы с троянами, вас будут посещать.

Linux — это возможность, начать новую жизнь в цифровом пространстве, ведь работа связанная ИТ, там живет/цветет/дышит, иначе. Это идеальная среда для программиста, разработчика, а вскоре, даже и дизайнера (сам этого жду), аналитика данных, математика и ученого, и т.д.

Linux — для вас, если:

• Вы заинтересованы в обучении, как работают ОС, процессы и потоки, архитектура ОС
• Готовы к приключениям, ведь новая ошибка, это новый путь
• Готовы потрудиться, чтобы разобраться, а это вам даст, понимании кастомизации, автоматизации и процветания в данной ОС
• У вас есть мозги
• Вы совершенный новичок в компьютерах
• Вчера купили себе ноутбук

Примитивная последовательность, знакомства с дистрибутивами:

1. Ubuntu
2. Manjaro
3. Fedora
4. Arch Linux/Debian

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

Конечно, её сравнивают и будут сравнивать с гигантами вроде Android и iOS. Поэтому она должна быть качественной и вполне конкурентоспособной, и одновременно самобытной и по-своему прорывной.

Нам хотелось бы привлечь больше разработчиков, создать больше приложений, сформировать свою экосистему сервисов и ширить базу преданных пользователей. И мы создали Aurora Foundation. Проект уже начал объединять разработчиков ОС, приложений и сервисов, производителей устройств. В статье расскажем, что уже готово и что планируем делать в будущем.

Взять хорошую универсальную основу

Сейчас многие популярные инструменты стали официально недоступны. Любимые многими продукты JetBrains не купить в России, какие-то ресурсы порой доступны только через VPN. Мы делаем IDE для Flutter, так что, очевидно, доступна ещё Android Studio. Но это всё же нишевый инструмент, который нет смысла брать за основу универсального продукта.

Есть и альтернативные пути. При желании можно и Neovim заточить под Flutter (хотя вряд ли найдётся много охотников таким образом работать) или посмотреть в сторону развивающихся опенсорсных проектов вроде подающего надежды Zed от создателей Atom. Но на длинной дистанции это не кажется удобными или надёжными.

По большому счёту, из мощных универсальных инструментов в свободном доступе остался лишь VS Code — по статистике им пользуется примерно треть разработчиков. Но не все его плагины полноценно работают в России, особенно сопряжённые с зарубежными облачными сервисами.

Так что мы взяли его опенсорсную версию Code OSS в качестве основы и начали писать свою IDE для российского комьюнити разработчиков под основные платформы (Linux, Windows, macOS на x86 и ARM). Лицензия MIT, убедительная история разных форков и способность работать как серверное веб-приложение без локальной установки стали дополнительными аргументами.

Project IDX — анонсированная новая среда разработки от Google тоже основана на Code OSS.

Максимально упростить работу

У Авроры давным-давно есть свои SDK, но процесс установки непростой. Нужно либо уже знать, как система устроена, либо лезть в документацию и идти по инструкции. А давайте честно, мало кто любит инструкции, и большинство сперва подходит интуитивно, обращаясь к документации, уже когда интуитивно не получилось.

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

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

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

Добавить эмулятор и совместимость с другими операционками

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

Поэтому нужен эмулятор устройства с Авророй. В классическом Aurora SDK уже есть такой, на базе виртуалок. А в Aurora Studio мы реализуем контейнеры с разными таргетами сборки ОС и эмулятором на базе QEMU. По задумке, его можно будет виртуально запускать и отлаживать приложения на основных архитектурах и форматах устройств локально или в облаке.

Взяв на вооружение Flutter, можно собирать приложения сразу для Авроры, Android и iOS. И почему бы не задаться целью сделать подход Aurora first — когда вместо портирования на Аврору приложений, изначально разработанных под другие платформы, мы сразу пишем софт под Аврору и параллельно собираем для других платформ. Думаю, такой подход поможет Авроре стать у российских разработчиков куда более популярной мобильной ОС.

Добавить облака

Облака — это тренд рынка по нескольким причинам.

• Отладка с тестированием становятся настолько ресурсоёмкими и комплексными процессами, что разумно выносить эти операции с компьютера разработчика на внешние мощности, в том числе облачные.
• Да и благодаря многообразию операционных систем, устройств и архитектур (x86 и ARM, RISC-V и MIPS, скорее всего, перестанут быть экзотикой Эльбрусы и LoongArch и так далее), приходится учиться жонглировать всё более сложными средами разработки и заниматься созданием и поддержкой собственных стендов в железе.
• Стандартом индустрии становятся IDE, усиленные облачными средствами сборки, запуска, отладки, тестирования и всевозможного анализа кода, а также публикации релизов на площадках дистрибуции. У Apple эти задачи решает Xcode Cloud, у Google — недавно стартовавший Project IDX. Подобная история есть, разумеется, и у Microsoft, причём сразу в нескольких местах – на vscode.dev, на github.dev и в Azure.
• В IDE прорастает направление ИИ-ассистентов для программирования, базирующихся на соответствующих облачных сервисах.
• Растёт актуальность нового класса облачных услуг — Environment-as-a-Service (EaaS, «среда как сервис»).
  

Это, кстати, ещё один аргумент в пользу Code OSS и его способности работать и десктопно, и в браузере. С таким фундаментом переход к нашей собственной EaaS-платформе станет абсолютно бесшовным.

Гарантировать безопасность

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

Но безопасное кодирование — непростая дисциплина, особенно для новичков, потому что надо:

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

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

Это же просто нескончаемая эпопея с тем, как гиганты вроде Microsoft и их пользователи страдают от дыр в системах: взломы, сливы данных, скандалы. Конечно, сделать софт на 100% безопасным крайне сложно, но тем не менее инструментально обеспечить приличную долю неуязвимости можно.

Мы же мечтаем сделать безопасную разработку доступнее на уровне IDE. В идеале — чтобы разработчикам любого уровня и понимания темы было сложнее совершать ошибки. Для нас самих это станет дополнительной гарантией того, что в софте будет минимум уязвимостей. Что можно реализовать:

• указывать, что в написанном коде есть небезопасные конструкции, и подсвечивать их (для этого уже есть инструменты, которые нужно интегрировать в IDE);
• автоматически находить дыры и вредоносный код в опенсорсных пакетах, которые использует разработчик (и в их транзитивных зависимостях), прямо на это указывать и советовать использовать другую версию такого пакета или какие-то другие аналоги (у нашего «РТК-Феникс» уже выстроен очень хороший пайплайн, советую зайти и почитать);
• предлагать готовые шаблоны безопасной реализации типовых прикладных конструкций.

Реализовать это всё в упомянутой ранее концепции EaaS — самая разумная стратегия.

У меня есть сверхзадача — достичь такого уровня зрелости инструментов нашей IDE, который бы позволил буквально гарантировать разработчику: он создаст код, соответствующий всем необходимым требованиям безопасности и лицензионной чистоты. Звучит фантастически, но мы работаем в этом ключе.

Всесторонне развивать экосистему

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

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

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

Представим, что у вас пять банковских приложений, и вы перешли на Аврору. Чтобы не скачивать всё заново и потенциально не мучиться с иконками веб-версий, можно просто использовать предустановленный сервис, назовем его «Финансы», где будут данные из всех банков. Примером подобной концепции является многим хорошо знакомый Apple Wallet.

Разумеется, шаблоны работы со всеми сервисами этой экосистемы сразу интегрируем в Aurora Studio. И обеспечим автоматическую публикацию их релизов в RuStore и приватных корпоративных Аврора Маркетах.

Развитие Авроры сейчас находится на таком этапе, когда двигаться дальше без экосистемы средств разработки и общедоступных базовых сервисов будет всё сложнее. При этом создание и развитие экосистем задача непростая, и по плечу она, пожалуй, только сообществу крупных игроков, заинтересованных в win-win. Поэтому если не мы, то кто может быть драйвером этого развития?

Что осталось сказать

У нас огромные планы — осталось всё это сделать. Сейчас у нас уже есть первые сборки среды разработки Aurora Studio, которые можно скачать и пощупать. Пока там нет всех фич, про которые рассказали в статье, но мы в процессе их реализации. И приглашаем вас протестировать альфа-версию нашей IDE.

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

Пишите в комментариях, на что вы обращаете внимание в среде разработки и что хотели бы видеть в IDE.

И бонусом несколько полезных ссылок

• Живое сообщество в Telegram
• Официальная документация для разработчиков от Открытой мобильной платформы
• Официальная библиотека на GitLab
• YouTube-канал Открытой мобильной платформы, где выходят новости и обзоры
• Портал разработчиков
• Учебный курс на GitLab по работе в Qt
• Бесплатный курс на Stepik
• Платный курс на Otus
• Очный курс в Академии Информационных систем
  

1. Все драйверы содержатся в ядре системы. Обновляется дистрибутив — ядро пересобирается, обновляются или удаляются старые драйверы, и устройство, прекрасно работающее долгие годы, просто «отваливается».
2. Политика некоторых дистрибутивов достаточно жесткая: например, в ядре содержатся только драйвера со свободной лицензией. Поэтому с компонентами от AMD и Intel проблем не возникает, а вот для того, чтобы настроить видеокарту от NVidia, нужно заморочиться.

С мышками, клавиатурами и прочими мелочами, как правило, бед не случается. Управление этими устройствами происходит через стандартные интерфейсы. Туда же можно отнести флэш-накопители, устройства NVMe и даже контроллеры USB и SATA — для них нет специфичных Linux драйверов. Что нельзя сказать про wifi-адаптер: для каждого придётся вручную подбирать необходимое ПО.

https://tproger.ru/articles/v-chyom-linux-luchwe-windows

А это нормально, что ядро Линукса так сильно раздуто драйверами?

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

Для примера, около 380 драйверов будут весить столько же, сколько .txt-файл с первым томом «Войны и мира», или как трехминутный качественный mp3-трек. При этом Unix-системы оставляют возможность перекомпилировать ядро, избавиться от ненужных модулей и сократить его вес почти в 10 раз. Но мы настоятельно не рекомендуем заниматься этим на рабочих машинах, особенно если о такой возможности вы только что узнали.

К тому же, образ Windows тоже содержит огромное количество предустановленных драйверов. Например, для того, чтобы live usb корректно работал на любой машине.

Что не стоит делать в Linux с драйверами

Последнее, к чему советуют прибегать — это скачивать драйверы с сайтов-производителей и вручную запускать их в Unix-системе. На это есть ряд причин, рассмотрим на примере установки драйверов NVidia в Linux:

• драйвер может перезаписать библиотеку с графическим интерфейсом Mesa GL, из-за чего перестанет работать открытый драйвер (если вы работаете со встроенной AMD и дискретной NVidia-картой, то система при обновлении не сможет распознать даже AMD);
• установленный с сайта драйвер не обновится с ядром, его нужно будет переустанавливать вручную;
• в случае, если у вас отвалятся оба драйвера, придётся накатывать обновления через CLI (терминал).

Так что в Linux драйверы видеокарты лучше ставить более изящным способом, через добавления в систему репозитория.

Что делать, если что-то не работает в Линукс?

1. Воспользуйтесь встроенным ПО

В Линуксе нет привычного для Windows-пользователей диспетчера устройств. Но можно воспользоваться аналогами, например, «Additional driver» в Ubunta или менеджером пакетов для GNOME в других дистрибутивах. На крайний случай скачать утилиту Inspector.

Посмотрите, какие драйверы уже установлены

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

Если у вас есть название драйвера — то можно воспользоваться командой grep (она помогает фильтровать вывод по ключевому слову).

Например, вы можете ввести lspci | grep NVIDIA, если хотите узнать, установлен ли драйвер NVidia.

Дальше можно посмотреть драйверы устройств, которые были распознаны ядром:

или, по аналогии,

Если команды dmesg или lscpi вывели нужный вам драйвер, значит, проблема не в нём. А вот если они ничего не дали, значит, драйвер не установлен или не распознаётся. Тут нужно проверить, есть ли драйвер в файловой системе:

и

Тут тоже можно использовать | grep SOME_DRIVER_KEYWORD. Если драйвер распознается этими командами, но не lscpi или dmesg, это означает, что драйвер находится на диске, но не в ядре. В этом случае загрузите модуль с помощью команды modprobe:

Обратитесь к wiki

Если вам нужны проприетарные драйверы, перейдите в документацию вашего дистрибутива или на специальную wiki и найдите, для чего вам нужны драйверы (например, для "nvidia"). Скорее всего, правильному способу это сделать будет посвящена целая страница. Вот для примера вики по Astra Linux и установке NVidia-драйверов.

https://tproger.ru/books/linux

Заключение

Проблема с драйверами в Линуксе достаточно масштабная: при очередном обновление ядра устройства могут внезапно выйти из строя, начать греться или наоборот, лучше работать. Хорошая новость заключается в том, что по каждому популярному оборудованию можно найти репозитории с проприетарными драйверами, а также пошаговую инструкцию, как их накатить. Если вы всё же нацелены перейти на Linux и хотите выбрать хороший дистрибутив, то наш материал может помочь.

Ниже — транскрибация ролика, дополненная ссылками.

Шесть лет назад я, Виндертон, будучи в состоянии аффекта, выкладываю вот этот вот ролик, который посмотрело уже больше 100 тысяч человек: «Техническая литература для программистов». Чтобы сэкономить вам 10 минут вашего времени, там были показаны вот эти вот книги.

Вопросов нет. Кнут — это классный автор с крутыми материалами. На кто его потянется со всей этой математикой, если даже вот эти челы не тянут, а конкретно тот, что с бородой — Шон Магресс. Тадембаум — та же самая история. Классный материал, но настолько сложное задание, что порой вгоняет в депрессию. Корман заставляет писать вас вообще деревья с нуля без примеров.

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

Ну а мы разбиваем видео на три части:

1. Введение в программирование и ядро computer science.
2. Моя библиотека. GameDev, прочее.
3. Языки программирования.

Введение и основы computer science

«Внутри машины», или как работает ваш компьютер, у нас это называется еще «архитектура ЭВМ». Как устроен процессор, память и вся организация железа. Если у вас нулевой бэкграунд, вам нравятся картинки и тоненькие книжки (~300 страниц), то это то, с чего вам точно стоит начать.

«Введение в компьютерные системы». Тут автор начинает буквально с того, почему процессор делается из кремния, потому что они сами делали процессоры из кремния. И проходится по всему абстракционному стеку, начиная от железа, через периферию, BIOS, операционную систему, ассемблер, язык программирования C, пишут на нем потом программы и покажут, как это дело все между собой связано, взаимодействует в очень интерактивной манере.

«Код» Петцольда. Эта книга, как и первая, тоже для полных новичков, без бэкграунда в сфере. Там рассказывается про то, что такое железо, операционная система, компиляторы, языки программирования, как это дело все между собой взаимодействует. Если вам когда-нибудь было интересно, почему компьютер именно такой, а программы пишутся именно так, то Петцольд в очень простой манере за 400 страниц вам об этом простенько расскажет.

Если вдруг по каким-то причинам вы эти книги не найдете или вам их будет мало, то вот еще две.

Первое — это «Теоретический минимум по Computer Science». Уровень подачи тут не дотягивает до предыдущих трёх, он немножко мудрёнее и сложнее, но тут реально покрывается весь тот компьютер-сайенс необходимый, который вам нужен, и в книге всего 150-200 страниц.

Единственный минус, который связан у меня с этой книгой — она вся развалилась пока я её читал.

«Computer Science: an Overview». Эта книга реально местами довольно часто очень сложная. То есть, если вы не знаете, что такое транзистор, а там об этом узнаете, то вы вряд ли поймете, что такое транзистор.

Но, (а) эта книга реально походится по всему курсу Computer Science, где говорят даже про базы данных и графику, и, (б) там копают чуть глубже, чем в этой, этой или этой. Поэтому, если у вас есть хоть немного опыта программирования, то смело берите эту книгу и изучите Computer Science.

Алгоритмы и структуры данных

Как вы все знаете, это Корман и Седжик.

Но Корман — это очень много математики прямо с первых страниц, а Седжик — это Java, которая, ну, не особо всем нравится.

Но нам везет, и со временем появляются реально годные альтернативы. И одна из них — это Grokking Algorithms. Я о ней узнал года три назад, и года два назад полностью заменил ею Кормана в менторинге. Книгу написал очередной гений, который программирует с двух лет и продает свои первые игры чуть ли не в 10 лет. Но она реально написана простым языком, и хочу сделать небольшую ремарку, если будете читать перевод. В переводах есть ошибки, поэтому просто будьте осторожны и всегда рекомендую только оригинал.

Операционные системы

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

Тут, наверное, есть какой-то баланс, она не слишком глубокая и не слишком поверхностная.

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

Компиляторы и дизайн языков

Книгу с драконом сразу отсюда убираем, потому что она, ну, прям слишком сложная.

Берем сюда Николаса Вирза, 150 страниц, и добавляем сюда Нистерна с его Crafting Interpreters. Кстати, Нистерн — это тот самый чел, который делал паттерны для геймдева, которые являются чуть ли не аналогом Банды Четырех.

Software development

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

Касаемо ООП, все советуют «Банду Четырёх», которая прилично так всем уже надоела.

А я посоветую вам вот эту книгу, которая, на мой взгляд, будет лучше. Единственный момент, то, что там С++, но его там на самом деле почти нет. Не пугайтесь.

Моя библиотека, GameDev, прочее

Джейсон Грегори — это автор, который написал Uncharted и, соответственно, эту книгу. У него супер-обширные познания в игровых движках как минимум и как максимум в производстве игр. В моменте этот человек решает написать вот эту вот книгу, которая уже третье издание. Отличная подача материала, углубление в самый раз, максимально широченный охват тем. И вот, например, то, что делает тот же самый Ян Черников — это процентов 20-30 вот от этой вот как раз книги. Чаще всего я читаю именно её.

Опять же, Андерсон «Операционки». Тут лучшее объяснение виртуальной памяти, на мой взгляд. Книга по введению в CS и программирование. Просто всем советую. Конечно же, Корман со своей бандой. Они тут явно борщат с математикой, но, может быть, это просто я тупой [здесь не даются ссылки на книги т.к. автор повторяет их из первого раздела, — прим.редактора].

Не особо классная книга по C++, но как референс или подставка для монитора вполне сходит.

Ещё одна классная книга — это Game Coding Complete. Сложные темы рассказывают достаточно простым языком. И именно отсюда я узнал, что такое анимация и как они работают.

Конечно же «Си» Кернигана и Ричи, но я не советую, если у вас с психикой не все в порядке.

Ассембль от Apress, чтобы хоть какое-то понимание было, что это такое, как на него смотреть вообще<...>

Языки программирования

Python

Тут идёт, конечно же, Лутц с его громким именем. Книжка прям для суперновичков, и Лутц, самое главное, не страдает болезнью. Вот это вы пока не понимаете, но через 10 страниц я вам это объясню. Нет, он как в бакалее: всё сразу по полочкам вам раскладывает, и вы перелистываете страницу за страницей, с приятным чувством, что вы все понимаете, вы весь такой вообще умный и сообразительный.

Еще одна книга на уровне этой — «Краш-курс Питона», которая была написана тоже автором, у которого куча классных книг по питону. Он программирует с 5 лет и пишет полжизни книги. Отличие от Лутца в том, что эта книга подходит как и начинающим, так и типам с опытом, поэтому читать ее реально не скучно.

Еще одна классная книга и классный автор — это Дэвид Бизли с его «Python Cookbook». Вообще, Дэвид Бизли — это бывший С-шник, который полжизни пишет на C и в моменте решает преподавать Python. И расскажет про всякие супер интересные и занимательные штуки по типу, почему на Python нельзя программировать многопоточные приложения, почему на нем нельзя программировать мобильные приложения. И у него еще есть всякие видео на YouTube, где он показывает всякие хаки с Python. Поэтому Python Cookbook, если уже знаете основу, то там вас научат расширять даже питоновский интерпретатор.

C

Тут сразу запомните одно. Никогда не читайте книгу Learn C the Hard Way, потому что там автор сразу видно, что не знает, о чем говорит, и упрощает то, что упрощать не надо. У этой книги прям очень много хейта в интернете, как и у книг Шилта, который классно знает Java, но не знает C++ и C, или как минимум не умеет их преподавать.

Волк в овечьей шкуре или Брайан Керниган и Денис Ричи и C, второе издание. Книгу рекомендуют до сих пор изучать по C, но на самом деле там есть куча проблем. Во-первых, это то, что эта книга подразумевает то, что вы уже знаете компьютер-сайенс, как работает вообще все, начиная от железа и вплоть до операционных систем. Во-вторых, то, что она по факту страниц 250, хотел сказать, она по факту 2500, и там нет такого понятия, как best practices, то есть книги 100 лет, и там просто не знали, что такое хорошо, а что такое плохо. Поэтому не рекомендую, если вы не понимаете компьютер-сайенс.

Beginning C. Книга от Apress, которая, как вы видели, у меня уже есть x86 Assembly. Классная книга, классное издательство. Фишка этой книги то, что там рассказывают про C99, про C11, про многопоточность в C.

Эта книга отлично работает как туториал, как референс, как подставка. И там много всяких работающих маленьких программулек на C.

И напоследок, хочу скачать что мне запомнилась, вот эта книга, которая называется Expert C. Она была написана челами, которые классно знают и разбираются в интерпретаторах и работают в САН.

C++

Конкретно от меня, у меня Primer Plus, которая не лучшая из этих книг, но мне хватило ее как референса [автор упоминал её ранее, — прим.редактора].

Мне также очень нравятся книги Скотта Майер Effective C++, которые нравятся вообще всем.

Плюс я почитываю вот эти вот две книги по метапрограммированию, не самые хорошие, но выбора просто нет никакого.

Само собой, многопоточность и C++ Concurrency in Action, потому что также нет никакого выбора. Ну и само собой, Александр Эску, которого почитывать нужно как минимум для того, чтобы видеть, как делать не надо, а это всегда в C++ интересно посмотреть.

Java

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

А вот книга Шилда Java Complete Reference, последний, который я читал, шестой и седьмой, мне всегда нравились, потому что простая подача, и они очень похожи на GLS. Наверное, даже проще. Да и вообще, у Шилда читать, мне кажется, можно всё, что угодно, потому что он как бы папа джавы.

Конечно же, как только вы знаете джаву-основу, это Джошуа Блок с ее Effective Java, это аналог Скотта Майера с Effective C++. На моей первой работе на Java, когда я пришел и сказал своему тимлиду, что я читаю Effective Java, он мне говорит, блин, это классная книга, я там дженерики сейчас изучаю. А я стоял в этот момент и думал, что, блин, я ее тоже уже читаю. Было очень приятное чувство, но меня тогда, типа, я так и остался работать джуном, а он так и остался работать тимлидом. Ничего не поменялось. В этой книге реально много практик использования джава в реальном продакшене, поэтому, если знаете основу, смело ее рекомендую.

Java Concurrency in Practice. То есть Java — это исключение, это многопоточность, это OOП. Такие книги, как Java Concurrency in Practice, показывают вам, как использовать ту же самую многопоточность, ее неотъемлемую часть. А такие книги, как Хедферст или какой-нибудь Шилдт, показывают вам, что такое Java Core. Также на уровне с Шилдтом есть тип, которого зовут Кей Хорсман. У него много всяких книг по типу «Как работать с синхронизацией» или «Ближележащие топики». То есть какой-то Advanced Java. Поэтому советую присмотреться тоже.

C#

Пусть Рихтера читают, пусть больше ничего не читают.

Javascript

Симпсон «Вы не знаете JavaScript». Неоднократно слышал про эти книги от классных JS-ников, потому что там много всяких how-to, то есть как работает это, как работает это, почему не работает это.

Советовать Фленнегана или Дугласа Кроуфорда, который хотел назвать JavaScript C++++ я не буду, потому что, если бы вы хотели читать книги, вы бы, наверное, изучали C++. Все-таки JavaScript — это попробовать, потыкать и поучиться на практике.

Assembly

Я покупал себе вот эту книгу и ни разу в ней не разочаровался. Возможно, потому что я прочитал ее только процентов на 30, но какая разница. Наверное, будет хороший вопрос, если вы скажете, зачем мне вообще ассембли в 2022 году. Да, он вам не нужен, вы на нем писать ничего точно не будете, но если вы пишете на плюсах, то чтение ассембли во время дебаггинга, что занимает большую часть вообще времени в программировании, как минимум на C++, как минимум у меня, понимать ассембли хотя бы нужно, поэтому такая вот книга в этом отлично помогает.

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

Читайте также: Как стать программистом с нуля — полный гайд, Что знать бэкендеру в 2024 году.

Linux поставляется с предустановленными компиляторами (C, C++, Python, Go) и git — разработчики могут начать работу сразу после установки без дополнительной настройки.

Большинство периферийных устройств работают в Linux по принципу plug-and-play — не нужно искать драйверы на сомнительных сайтах.

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

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

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

Что смог Linux, но не смог Windows

Собрали ряд пунктов, в которых Linux превосходит Windows.

Компиляторы уже работают

Большинство дистрибутивов Linux поставляются с предустановленными компиляторами. Если компилятора на борту нет с самого начала, установить их очень просто: достаточно вбить команду в терминале. Часто это касается C, C++ (GNU), Java, Python, Fortran, Golang, Assembly, NodeJS. Кроме того, во многих дистрибутивах уже есть предустановленный git.

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

Поддержка драйверов

На Linux почти каждое периферийное устройство подключается по принципу plug-and-play. Вы просто подключаете его и пользуетесь, и для этого вам не нужно загружать целую кучу драйверов.

На Windows же драйвера придётся поискать, и вы обязательно соскучитесь по тем временам, когда в комплекте к устройству шёл компакт-диск с драйвером. Дай бог, чтобы вам не пришлось попрыгать между сомнительными сайтами и проверить десяток файлов на наличие вирусов.

Конечно, есть и исключения вроде AMD — линуксоиды знают, что с драйверами к видеокартам бывают проблемы. К примеру, последняя на момент написания статьи версия Ubuntu 23 AMD не поддерживала: автору приходилось откатываться на предыдущую версию ОС. Но это часто зависит от дистрибутива: на Linux Mint не нужно устанавливать драйвер AMD.

Кастомизация

Надоел текущий рабочий стол? Сделайте новый с помощью одной команды в терминале!

Не нравится тема? Откройте браузер и выберите новую из миллиарда доступных тем.

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

Масштабируемость ОС

Что касается самой ОС, Linux может масштабироваться. Она работает на 99% из 500 лучших суперкомпьютеров в мире.

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

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

Забудьте о вирусах

Для Linux создано совсем мало антивирусов, но только потому, что они почти не нужны. Дело в том, что большинство вирусов — это исполняемые или пакетные файлы, написанные на VBScript, C или C++, которые не работают с той же эффективностью на Linux, как на Windows.

Также у Linux есть чёткие уровни безопасности для серверных файлов (в виде контроля доступа пользователей). В том числе, поэтому Linux наиболее предпочтительна для работы на серверах и суперкомпьютерах.

Linux для ленивых

Вы можете полностью автоматизировать свою систему и заставить её заниматься вашими делами вместо вас. >: ).

Например, вы можете написать скрипт на Python, который будет читать содержимое почтового ящика, сортировать почту, удалять ненужные письма, отвечать друзьям, и все это за считанные секунды сразу после загрузки ОС. Вы также можете запланировать выполнение действий несколькими приложениями через разные промежутки времени.

Установка программ за одну минуту

Допустим, вы хотите программировать на C++ с помощью Code::Blocks (IDE). Просто откройте Терминал (Ctrl+Alt+T), введите эту команду и нажмите Enter:

Вот и всё! Можете начинать писать код. На Windows весь процесс займёт куда больше времени, не говоря уже о хлопотах, связанных с ассоциацией правильного компилятора с нужным ПО.

Полная прозрачность процессов

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

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

Linux можно доверять. Он не пытается обмануть вас, не заставляет вас обновлять программы или ставить обязательные заплатки к ОС, принудительно перезапускать систему и так далее. Вы полностью контролируете ситуацию.

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

С каждым релизом члены сообщества отслеживают изменения и процесс функционирования ОС в целом.

Никаких перезагрузок после установки ПО

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

Linux может работать годами без перезагрузки. В нем нет фрагментированного реестра и абсолютно отсутствует корпоративное раздутое ПО. Также нет изнурительных проблем с управлением памятью.

Обновить можно почти любое ПО, включая патчи и незначительные обновления версий ОС, не выключая и не перезапуская машину.

Простой доступ к диску Windows

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

Что смог Windows, но не смог Linux

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

Ещё ядро Linux не может выполнять точные функции ядра ОС реального времени, поэтому вы, конечно, можете использовать Linux в качестве ОС для телевизора, но не для космических зондов.

Многие производители устройств создают драйверы только для Windows. Некоторые устройства, особенно принтеры, может быть трудно или невозможно настроить на Linux-машине.

Ещё у Linux нет унифицированного внешнего вида, как у Windows. Хотя это и плюс к кастомизации, не существует механизма, препятствующего перенастройке всего подряд, и любой админ может настроить ОС так, чтобы она была визуально и организационно запутанной для других пользователей.

Также Linux не работает с DirectX от Microsoft, что практически полностью исключает Linux из мира компьютерных игр. API Vulkan пытается изменить ситуацию, преобразовав OpenGL в чистый, современный язык, конкурентоспособный с DirectX.

Заключение

Итак, Linux выигрывает у Windows в таких областях:

1. Поддержка компиляторов
2. Кастомизация
3. Масштабируемость
4. Устойчивость к вирусам
5. Поддержка драйверов
6. Автоматизация
7. Установка программ
8. Прозрачность процессов
9. Лёгкий доступ к дискам
10. Отсутствие принуждения к перезагрузкам, обновлениям и т.д.

Но Linux проигрывает Windows в следующих областях:

1. Инициализация программ
2. Ядро точного времени
3. Поддержка специфических устройств
4. Унификация
5. Геймдев

Почему мы пользуемся контейнерами

Разработчики пользуются библиотеками. Они позволяют не изобретать велосипед и пользоваться готовыми функциями.

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

Чаще всего ресурсов на поддержку такого «зоопарка» нет. Чтобы избежать постоянных тестов совместимости, слой библиотек передается вместе с docker image, из которого разворачивается тот самый контейнер. В нем есть всё необходимое в переносимом виде.

Чем технология контейнеризации отличается от виртуализации

У операционной системы есть абстракция-посредник между программами и оборудованием — ядро, которое обеспечивает API-вызовы. Происходит это через системные вызовы. Чаще всего они относительно низкоуровневые, надежные и примитивные. Например, «считай 10 байт, открой файл, считай 10 байт». Большинству программ этого достаточно.

Обратите внимание на эти системные вызовы: с помощью fopen можно смотреть, по какому пути открывается файл, а с clone(fork) и exec — видеть, как идут запуски тредов и внешних программ в контейнере.

Если, например, приложению приходится работать с аппаратными токенами, то нужны полноценные драйверы. Здесь может понадобиться виртуализация, где гипервизор host-OS позволяет запустить любое ядро с нужными драйверами.

Получается матрешка. Есть железо, на нем работает программа — ядро. Она создала процесс и запустила в нем гипервизор. Тот создал абстракцию железа, в которой запустилась программа-ядро. Оно создало процесс, в котором запустило программу. Не про это ли думал Нолан, когда снимал «Начало»?

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

Что почитать: «Linux. Системное администрирование», Р. Лав. В книге описаны системные вызовы, происходящие в Linux. Помогает понять, как работает ОС «с пользовательской точки зрения».

Что такое namespace

Ядро умеет изолировать программы друг от друга через процессы. Между ними изоляция осуществляется благодаря namespaces, которые позволяют отвечать на системные вызовы каждого приложения по-разному. Это как с билетами на концерт: по одному можно пройти на танцпол, по другому — в ложу, по VIP — пообщаться с артистом за кулисами.

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

Нужно понимать, за что отвечают такие namespaces:

• Файловая система (Mount) — область файловой системы, которая предоставляется приложению как корневая.
• UTS — собственный hostname.
• PID — позволяет в различных пространствах давать одинаковые ID процессам.
• Сети (Network) — позволяет изолировать ресурсы, связанные с сетью. При этом процессы из разных пространств видят свои сетевые устройства, таблицы маршрутизации, правила firewall и так далее.
• Межпроцессное взаимодействие (IPC) — позволяет организовать межпроцессное взаимодействие.
• Пользовательские ID (User) — позволяет иметь копию пользовательских и групповых идентификаторов.
• Время (Time) — позволяет разным процессам видеть разное системное время или часовой пояс.

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

Также на удаленке многие разработчики начали работать в других временных зонах. Часто при дебаге тестировщики не могут найти ошибки в соседних системах из-за разницы временных меток в логах разработчика и системы.

Что почитать: «Внутреннее устройство Linux», Д. Кетов. В книге рассматриваются основные подсистемы ядра и их сущности: файлы и файловые системы, виртуальная память и отображаемые файлы, процессы, нити и средства межпроцессного взаимодействия, каналы, сокеты и разделяемая память.

Посмотрим на конкретных примерах, какие проблемы можно отследить.

Кейс №1: выросло System time

Процесс может потреблять большое количество процессорного времени. Можно диагностировать это стандартными средствами. Посмотреть на цифры в выводе команды TOP:

• US( user time);
• SY (system time);
• WA (wait);
• IO wait и так далее.

Если разработчик не понимает, за что эти цифры отвечают, он решит, что накосячил где-то в коде. Хотя на самом деле процесс может потреблять много system time.

Пример из практики: информационная безопасность экспериментировала с журналами аудита и добавила дополнительные правила. По графикам системы мониторингов Grafana нагрузка на сервере подскочила процентов на 30. В этот же день был релиз фронтенд-приложения. Естественно, все решили, что фронт начал атаковать бэкенд, и именно он потребляет больше ресурсов даже не на пике.

Первая идея — искать, какие REST-вызовы дали нагрузку. На сервере мы видим, что на самом деле выросло SY. В процессе разработчики поняли, что были добавлены новые правила аудита, и решили их убрать. Тогда нагрузка вернулась к обычным стандартным значениям.

Что почитать: «Сетевые операционные системы», В. Олифер, Н. Олифер. В книге рассматриваются концепции и принципы построения большинства современных ОС.

Кейс №2: ошибка в документации

Команда писала приложение, в котором использовались криптографические подписи. После сборки и упаковки в Image, все перестало работать, это типичная ситуация. Ошибка говорит, что недоступен файл, который точно должен быть доступен. Базовый образ минималистичен, утилит диагностики в себе не содержит. Для разработчика это тупиком.

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

Что в итоге

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

В ответ Линус Торвальдс поделился своим мнением: bullshit — это сам Какурин, C++ — это ужасный язык, на котором кодеры генерируют, мягко говоря, «нечистоты», а программистов C++ вовсе не стоит допускать до Linux.

После откровенных оскорблений Торвальдс перешел к аргументам.

Позиция Линуса Торвальдса относительно C++

В первую очередь, Линус говорит, что использование C++ неизменно приводит программиста к плохим решениям вроде использования библиотек STL или Boost, которые считаются прекрасными.

Однако на деле, по мнению Линуса, они постоянно ломаются, отладка кода становится испытанием, а сам код нестабильный и не портируемый.

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

Если же программист захочет написать хорошее, эффективное и портируемое приложение на C++, он будет ограничен рамками, которые уже хорошо реализованы на языке Си.

Кроме того, использование Си страхует программистов от ошибок, и они не смогут «облажаться» на проекте, а сам язык учит кодеров разбираться в низкоуровневых проблемах. По версии Торвальдса, сплошные плюсы.

Линус признался, что в 1992 году они уже пытались использовать C++ для написания Linux. С тех пор, по его мнению, мало что изменилось.

Компиляторы C++ все так же не вызывают доверия, а обработка исключений в них вообще не работает.

Еще C++ скрывает потребление ресурсов, поэтому использовать его для написания ОС Линус считает невероятно глупой затеей. Зато объектно-ориентированный код можно написать на С без всяких проблем.

Позиция защиты C++

Линус думает, что ненавидит C++. Но, судя по его комментариям, он вообще не знает C++, а то, что он знает, давно устарело.

Ранние компиляторы C++ были довольно глючными. Они были не намного хуже, чем компиляторы C, но ошибки в них были разными. При этом компилятор C, который он использовал (gcc), тщательно тестировался на ядре Linux, поэтому он почти никогда не видел в нем ошибок. Зато в компиляторе C++ эти ошибки он мог найти с легкостью.

C++ был первым популярным объектно-ориентированным языком, а его ранние версии C++ были написаны на Smalltalk со странным синтаксисом. Поэтому ранний C++ работал плохо, и особенно плохо он работал в ядре Linux.

Похоже, что Линус сделал поспешные выводы, основанные на минимальном анализе. Когда он увидел, что C++ работает не так, как он ожидал, он просто отмахнулся от него, вместо того, чтобы изучить. К примеру, в C NULL может быть типобезопасным, а в C++ для этого нужно использовать nullptr, а не NULL.

С тем же успехом Линус Торвальдс мог бы заявить, что ненавидит язык суахили, потому что он его не знает.

Заключение

В целом, Линус Торвальдс прав, и для ядра Linux действительно лучше подойдет низкоуровневый язык Си, а не C++. Но в остальном вся его ненависть сводится к тому, что он попробовал использовать C++ практически на старте языка, и тот ему не понравился.

Кроме того, стоит помнить, что Линус говорит о C++ в контексте использования языка для написания ядра операционной системы. Этой же позиции придерживаются и другие авторы ОС. Ядра Windows, Linux, iOS, MacOS, FreeBSD написаны на языке Си.

А что о C++ думаете вы? Справедливы ли нападки Торвальдса?

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

Что общего между MacOS и Linux

В первую очередь, обе системы в своей современной итерации разработаны на основе Unix. Также и Linux, и macOS совместимы с POSIX.

POSIX – это стандарт, который определяет совместимость операционных систем, основанных на UNIX.

POSIX (Portable Operating System Interface) был разработан с целью обеспечить переносимость программного обеспечения между различными UNIX-подобными системами.

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

Поддержка POSIX приводит к легкой переносимости серверного программного обеспечения и программ на языках программирования вроде Ruby, Python, gcc, clang, Erlang и многих других, с одной ОС на другую.

Файловая система в ОС выполнена практически идентично, за исключением того, что macOS не чувствителен к регистру.

Также почти все программное обеспечение GNU, то есть практически каждая программа, работающая на компьютере с Linux, доступна для macOS.

GNU – это проект свободного программного обеспечения (Free Software Foundation’s GNU Project), который был запущен Ричардом Столлманом в 1983 году. GNU является сокращением от “GNU’s Not Unix” и представляет собой усовершенствованную и свободную реализацию операционной системы Unix.

Ключевой элемент GNU – это GNU General Public License (GNU GPL), который предоставляет пользователю свободу использовать, изменять и распространять программное обеспечение под лицензией.

Лицензия GNU GPL гарантирует, что программное обеспечение, распространяемое под ее знаком, остается свободным и доступным для всех.

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

В общем, и Linux, и macOS поддерживают эти стандарты, поэтому и складывается ощущение, что операционные системы похожи друг на друга.

В чем разница между macOS и Linux

MacOS почти никак не связана с Linux. На самом деле, родословная macOS старше, чем родословная Linux.

То, что мы сегодня называем macOS, основано на NeXTstep, операционной системе, разработанной NeXT Computing в 1980-х годах.

NeXT — это компания, которую Стив Джобс основал после того, как покинул Apple в 1985 году после конфликта с советом директоров. Да, есть и такая строчка в биографии Джобса.

Стив Джобс основал новую компанию и нанял Ави Теваняна в качестве руководителя отдела разработки программного обеспечения.

Теванян был одним из программистов, разработавших ядро ​​BSD Mach в Университете Карнеги-Меллона, и Джобс попросил его создать на его основе новую многозадачную ОС.

В качестве основы для NeXTstep использовалась Berkeley Unix BSD 4. Berkeley Unix была разработана Калифорнийским университетом в Беркли после Unix System 3.

В Unix System 3 вносили различные улучшения, после чего ОС назвали BSD 4. Более поздняя версия BSD под названием Mach была разработана как раз в Карнеги-Меллоне.

Теванян придумал новую ОС, которая превосходила аналоги на тот момент времени. К примеру, Тим Бернерс-Ли изобрел Всемирную паутину в 1990 году именно на компьютере NeXTstation с NeXTstep в качестве ОС.

В это же время Apple без Стива Джобса пыталась создать собственную ОС, но все было тщетно. Они пришли к решению выкупить NeXT, и Джобс вернулся в компанию.

Теванян, который стал новым руководителем отдела разработки программного обеспечения Apple, затем переработал NeXTstep в Mac OS X.

Это до сих пор влияет на работу macOS: в ней инструменты командной строки взяты из *BSD, а в Linux они заимствованы из GNU.

Даже сегодня, если вы посмотрите на API macOS, вы заметите, что многие вызовы API, имена классов и функции AppKit начинаются с «NS», например, NSOpenPanel, NSSavePanel, NSWindow, NSResponder и так далее.

«NS» здесь означает «NeXTSTEP». Даже объект, который обрабатывает основной цикл событий в приложении AppKit, называется NSApplication.

Linux был разработан позже. Ядро ​​Linux было написано только в 1991 году, а первые дистрибутивы GNU/Linux появились в 1992 году. NeXTstep была выпущена 18 сентября 1989 года и была уже отполированной ОС, которую можно было использовать для серьезных проектов. Этих высот Linux смогла добиться только несколько лет спустя.

Таким образом, macOS — это не просто дорогая и симпатичная Linux. Это симпатичная NeXTSTEP, которая была симпатичной BSD Unix.

MacOS — это операционная система BSD UNIX на основе микроядра с собственной собственной подсистемой отображения, архитектурой драйверов и оконным менеджером.

Linux представляет собой монолитное ядро ​​без родословной UNIX, но благодаря библиотекам и утилитам GNU обеспечивает UNIX-подобную среду POSIX.

Почему различия между Linux и macOS важны

Теперь, после того как мы выяснили, что у Linux и macOS разные ядра, поговорим о том, почему это вообще важно для пользователя. Дело в том, что Linux с его монолитным ядром выиграл «войну ядер», которая до сих пор не закончена.

Монолитное ядро Linux – это тип архитектуры ядра операционной системы, в котором все основные функции и драйверы находятся внутри одной исполняемой программы – ядра. В монолитном ядре все части ядра работают в одном адресном пространстве и имеют прямой доступ к аппаратным ресурсам компьютера.

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

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

К сожалению, в микроядрах задержка больше, чем в монолитном ядре, объединяющем все в одном месте. Mach был одним из первых экспериментов по разработке серьезного микроядра, и многие говорят, что он провалился с точки зрения производительности.

В macOS (ранее известной как Mac OS X и OS X) используется микроядро XNU (X is Not Unix). XNU является гибридным ядром, в котором сочетаются микроядро и некоторые элементы архитектуры монолитного ядра. Хотя ядро XNU является гибридным, его основной архитектурой является микроядро.

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

Но и у macOS есть преимущество. Микроядро стабильнее. Если один модуль даст сбой, все остальные модули будут работать и дальше.

В этом смысле, вам решать, что важнее: надежность или скорость.

На это Джефф ответил: «Разработал Chrome OS. До сих пор неизвестен.»

Мы решили разобраться, кто такой Джефф Нельсон, как строилась его карьера, как он придумал Chrome OS и почему он всё-таки остался неизвестным разработчиком.

Карьера до Google

У Джеффа есть профиль на Linkedin, в котором указано, что он учился в Университете Аризоны, в которой получил степень бакалавра по математике в 1993 году, а в 1994 году получил степень магистра в прикладной математике.

В 1999 году Нельсон попытался устроиться в компанию Илона Маска Х Commerce, когда та была предком PayPal, а не Твиттером. Разработчик признается, что это интервью было одним из самых странных в его жизни.

Тогда в Х работало около 10 человек, и все, кто его собеседовал, интересовались только soft skills. Даже руководитель инженерного отдела не знал программирования и долго извинялся за то, что не разбирается ни в Java, ни в С++.

Из-за того, что Илон Маск был единственным бэкендером в компании, именно он проводил техническое собеседование с Джеффом.

Маск задал всего два вопроса. Первый: “Кем вы видите себя через 5 лет?”. Джефф ответил, что хотел бы находиться на руководящей должности. Второй: “Есть ли вопросы ко мне [Илону Маску]?”. Тогда Нельсон и Маск долго говорили о рисках бизнес-модели X Commerce.

В итоге Нельсону предложили оклад в 90 тысяч долларов и акции компании. Разработчик отказался: зарплата была гораздо ниже рынка.

После этого он ушёл работать в eBay, в которой наш герой руководил проектами стоимостью в 200 миллионов долларов и которая выкупит PayPal в 2002 году.

В том же 1999 году Джефф дважды пытался устроиться в Google через “ярмарку вакансий”. Он стоял в очереди из соискателей, после чего интервьюер задал ему загадку, на решение которой было дано 30 секунд. Джефф дважды провалился, и дважды его резюме отправлялось в папку “НЕ ЗВОНИТЬ”.

В том же продуктивном и весьма неуспешном году Нельсон даже написал книгу “Programming Mobile Objects with Java“. Правда, на Amazon у неё всего одна оценка, и та негативная — ему поставили две звезды из-за фактических ошибок в тексте.

Работа в Google и разработка Chrome OS

В eBay Нельсон проработал до 2006 года, после чего всё же попал в Google. Как и на прежнем месте, он стал одним из руководителей компании.

Всего через год он придумал Chrome OS. Проблема заключалась в том, что компьютер Джеффа постоянно тормозил, из-за чего разработчик загорелся идеей создать свою ОС.

Разработка Chrome OS велась до 2008 года, после чего Нельсон представил бета-версию операционной системы руководству. Директорам проект понравился, поэтому они выкупили его у разработчика. В 2012 году Нельсон получил патент на Chrome OS, который, вероятно, приносит разработчику приличные выплаты по сей день.

Нельсона спрашивали, почему он не создал независимую ОС без привязки к Google, ведь у него есть явный талант, и он мог заработать на своём творении гораздо больше. Он ответил, что поступил так, поскольку у Google уже были крутые веб-разработки, в отличие от никому не известной новой ОС.

У Google были инфраструктура веб-приложений, браузер Chrome и рекламная бизнес-модель, а также огромная существующая клиентская база, которую можно было использовать. Джеффу попросту пришлось бы заново разрабатывать Adwords, Writely и Chrome. Кроме того, сама Chrome OS была экономически выгодна именно компании Google.

За время работы Джефф стал крупным специалистом в Big Data, машинном обучении и облачных технологиях. Среди преимуществ Google он отмечал лидерство компании в ML и советовал сотрудникам использовать это, чтобы научиться как можно большему.

Однако у работы в Google были и прозаичные недостатки. Несмотря на то, что Google рисуют как компанию мечты, в действительности всё не так: здесь работают всё те же люди с политическими амбициями, безалаберностью и ленью.

Также Нельсон жаловался на то, что руководство было практически недосягаемо для сотрудников, из-за чего процессы в компании постоянно затягивались. Кроме того, в Google не уделяли должного внимания Chrome OS, которого та, по мнению Джеффа, заслуживала.

Разработчик занимался и другими задачами, например, созданием веб-сервисов Google Apps, но постоянно просил перевести его на полноценное управление Chrome OS, которую он сам и создал. Конфликт достиг апогея, и Джефф Нельсон обнаружил себя покидающим двери Google.

Карьера Джеффа Нельсона после ухода из Google

О том, где трудился Нельсон после Google, мы не знаем. В профиле на Linkedin указано, что сейчас он работает CTO в стелс-стартапе — такие компании умышленно избегают общественного внимания.

В неизвестности Джеффа Нельсона виноват… сам Джефф! Он ничего не рассказывает о том, где работает сейчас, что нового он разработал и каких успехов добился. Большая часть его публичной деятельности так или иначе связана с Chrome OS, даже в ответах на Quora.

Зато Джефф активно ведёт соцсети — вот его профили на Quora, в Twitter, в Tumblr и Google+. Ещё у него есть веб-сайт, на котором можно увидеть его многочисленные публикации в научных журналах.

Заключение

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

Но если всё же очень хочется, попробуйте стать мемом в интернете.

Для установки Linux Mint 21.2 “Victoria” потребуются минимум 2 ГБ оперативной памяти, 20 ГБ свободного пространства на диске и монитор разрешением от 1024×768 пикселей.

Что изменилось в Linux Mint 21.2 Victoria

1. Обновилось графическое окружение Cinnamon 5.8, основанное на GNOME 3.
2. Рабочий стол Xfce обновлён до версии 4.18.
3. Добавлены порталы Freedesktop, которые позволяет запускать приложения под другие графические окружения.
4. Программа для работы с изображениями Pix переделана на базе gThumb 3.12.2. Добавлены новые инструменты для редактирования изображений, новые эффекты и фильтры.
5. Изменено темное оформление. Теперь пользователь может выбрать светлую тему, темную тему для приложений и автоматически настраиваемую.
6. Инструмент для предпросмотра документов Xreader теперь поддерживает файлы Adobe Illustrator.
7. Инструмент для Bluetooth-соединений Blueman обновился до версии 2.3.5.
8. Поддерживаются форматы изображений HEIF и AVIF.
9. Обновлён интерфейс в менеджере установки приложений. Изменилась сортировка приложений.

«Хмм. Заключительная неделя 6.4 завершена, и в основном у нас имеются некоторые исправления netfilter, откаты в mm и несколько обновлений трассировки. Есть случайные незначительные изменения: обычный шум архитектуры, ряд обновлений самопроверки, некоторые исправления файловой системы (btrfs, ksmb) и т. д.», — написал Линус Торвальдс в опубликованном письме из переписки разработчиков.

Загрузить Linux 6.4 можно на kernel.org. Коммит Linux 6.4 можно посмотреть на GitHub.

На данный момент в основной репозиторий было добавлено почти 7500 изменений для ядра 6.4. Всего были предложены 13 044 немержевых набора изменений, и чуть больше 5000 из этих наборов были добавлены.

Среди изменений 40% связаны с драйверами устройств, 15% — с обновлением кода аппаратных архитектур, 10% — с сетевым стеком, 5% — с файловыми системами и внутренними подсистемами ядра.

Семья журналистов и дедушкин компьютер: история создателя Linux

Первым разработчиком и создателем Linux считается Линус Торвальдс, финский программист. Он родился в 1969 году в семье журналистов: мать — редактор в новостном агентстве, отец — радиожурналист, дед по отцовской линии — главред газеты.

А вот дедушка по матери Лео Вальдемар Тернквист был профессором статистики в Хельсинкском университете.

Ребёнком Линус любил наблюдать за тем, как дед работает за калькулятором — в то время они мигали лампочками. А в 1981 году профессор заменил калькулятор на компьютер — Commodore VIC-20: так Линус впервые познакомился с электронно-вычислительной машиной.

После смерти дедушки компьютер полностью перешёл в руки мальчика, и он погрузился в программирование. Сначала это был Basic, но вскоре этот язык быстро ему надоел, Линус начал изучать машинные коды.

Затем семье удалось купить новый компьютер — Sinclair QL. В это время Линус начал интересоваться операционными системами. Сначала это произошло вынужденно: мальчику пришлось самостоятельно написать драйверы для дисковода, и в процессе он обнаружил несколько ошибок в операционной системе. Захотел их исправить, но, увы, не вышло — ось оказалась зашита в ПЗУ, и ничего изменить было нельзя.

После школы Торвальдс поступил в Хельсинкский университет и залез в кредит, чтобы купить компьютер с 386 процессором Intel. На компьютере студента стояла операционная unix-система Minix, но она работала с ошибками. Линус написал несколько программ, чтобы это исправить.

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

Бесплатное программное обеспечение: идеология и практика

Чтобы создать свою операционную систему, Торвальдс использовал чужие программы, опубликованные на базе General Public Licence — Универсальной общественной лицензии. Её разработал Ричард Столлман в 1989 году.

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

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

Изначально Торвальдс не стремился распространять свою ось, но под влиянием преподавателя Ари Лемке всё-таки выложил исходники в открытый доступ.

Есть версия, что название Linux появилось благодаря тому же университетскому учителю. Сам Торвальдс хотел использовать название Freax (производная от слова «freaks» — фрики, чудики), но преподаватель переименовал каталог с файлами, совместив имя Торвальдса и Unix — получился Linux.

Если говорить о дне рождения операционной системы, единого мнения на этот счёт не существует. Сам Торвальдс выделяет четыре даты:

• 3 июля 1991 года — первое упоминание Linux её создателем как операционной системы.

• 25 августа 1991 года — дата официального анонса проекта. Линус Торвальдс считает её приоритетной.

• 17 сентября 1991 года. Тогда вышел первый релиз оси версии 0.01, Торвальдс поделился ею в рассылке близким друзьям.

• 5 октября 1991 года — выпуск официального публичного релиза Linux версии 0.02.

Сделал ли Linu​​x своего создателя богатым?

Да, но не сразу. У Торвальдса не было мысли продавать или как-то иначе монетизировать свою операционную систему, поэтому он не брал и не просил за неё денег.

Сначала Линус Торвальдс был штатным научным сотрудником в Хельсинкском университете. В 1997 году переехал с женой в США и начал работать в компании Transmeta, которая разрабатывала процессоры с низким потреблением энергии. Нельзя сказать, что эта работа приносила много денег.

Но в 1999 году компания Red Hat, которая занималась настройкой Linux под разные бизнесы, вышла на биржу. И в знак признательности создателю операционной системы выдала Торвальдсу опцион на пакет акций. Через полгода его стоимость составляла $5 000 000.

Так же поступила и другая компания — VA Linux, но в этот раз акции так не подскочили.

Тем не менее финансовое положение Торвальдса и его семьи улучшилось: они купили дом, а рядом с семейным автомобилем в гараже появился ещё и жёлтый кабриолет.

Создатель Linux не раз получал награды за свою работу, самая «громкая» из них — крупнейшая технологическая премия Millennium Technology Prize (2012) с призом в €1 200 000.

Чем сейчас занимается Линус Торвальдс

В 2003 году Торвальдс ушёл из Transmeta в фонд Linux Foundation, где работает и сейчас. Финансирование фонд получает из пожертвований. В 2017 году бюджет фонда равнялся $50 000 000.

Фонд продвигает и стандартизирует Linux, обучает и сертифицирует специалистов по работе с системой. Также он поддерживает и участвует в различных проектах с открытым кодом.

Благодаря фонду Linux имеет большое сообщество разработчиков и пользователей, которые могут помочь: решить проблему и поделиться опытом. Согласно ежегодному отчёту Linux Foundation, только за 2022 год более 2,7 миллиона человек прошли обучение и получили сертификаты фонда. Это только примерная цифра — реальная наверняка больше.

А чем закончилось ваше школьное увлечение компьютером? Поделитесь своей историей в комментариях.

С помощью этого приложения и приложения Link to Windows для iOS пользователь может совершать/принимать звонки, отправлять и получать сообщения iMessage и просматривать уведомления прямо на компьютере.

Правда, пока iMessage ограничивается текстовыми сообщениями в личных чатах. И далеко не до всех пользователей дошло обновление.

Но это уже большой прорыв, тем более, что все пользователи Windows 11 получат возможности синхронизации Phone Link с iOS к середине мая.

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

1. Sander Van Vugt — «Red Hat RHCSA/RHCE 7 Cert Guide: Red Hat Enterprise Linux 7 (EX200 and EX300)»

О чём: книга, с которой нужно начинать — must have для любого Linux-инженера. Здесь почти 100% того, что нужно знать про операционную систему.

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

Хотя книге уже 7 лет, а RHEL достигла девятой версии, всё, что написано, до сих пор актуально. Структура хороша, а материал идёт от простого к сложному. Начало каждой главы — это теория и примеры, конец — лабораторная работа.

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

Как читается: из недостатков — книга на английском языке. Если знания невысокие, онлайн-переводчики помогут, но будет тяжело. По нашей теме мало информации на русском, нужно быть к этому готовым.

2. Виктор Олифер — «Компьютерные сети. Принципы, технологии, протоколы»

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

На кого рассчитана: на людей, совсем незнакомых с сетями.

Как читается: совершенно понятный язык. Как только появляются сложные термины, их сразу и хорошо объясняют.

3. James Freeman, Jesse Keating — «Mastering Ansible»

О чём: так как мы работаем с распределёнными системами, нужно настраивать множество машин. Подключаться к каждому серверу и выполнять однотипные настройки — это рутина, которую система Ansible позволяет избежать.

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

На кого рассчитана: книга простая, тоже начинается с основ: сначала пишем первые сценарии, затем их выполняем. Но чтобы понимать, о чём речь, нужно знать Linux и прочесть первые две книги.

4. Марко Лукша — «Kubernetes в действии»

О чём: Kubernetes — это система регистрации контейнеров, которая сейчас очень популярна. У нас она есть почти что в каждом проекте.

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

Однако нет ни одной книги, которая бы на 100% объясняла все нюансы работы. Поэтому параллельно стоит обращаться к документации, многие вещи по Kubernetes там хорошо описаны.

На кого рассчитана: стоит читать, когда есть реальный опыт, а первые две книги из нашего списка усвоены.

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

5. Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy — «Site Reliability Engineering. How Google Runs Production Systems»

О чём: здесь рассказывается о том, что такое SRE — site reliability engineering, то есть инжиниринг отказоустойчивости сайта и о подходе Google к управлению распределёнными системами.

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

В книге описывается, как правильно подходить к автоматизации — то, что изучалось в «Mastering Ansible». Также рассказывается про основные показатели и метрики серверов и приложений, за которыми нужно следить. Здесь манифестируется отказоустойчивый подход, применяемый в Google. Говорится, что в идеале нужно сделать, чтобы проблемы не возникло, а не решать, когда она уже случилась. А если всё же избежать аварии не удастся, то будет полезно узнать про правильный подход к реагированию и управлению инцидентами.

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

Как читается: язык простой, подойдёт и будет понятен тем, кто уже освоил первые четыре книги.

При изучении важно не торопиться, двигаться последовательно, и главное — не забывать о практике. Это лучший учитель, который позволит закрепить теорию, удержать её в памяти как можно дольше. Удачи в учёбе!

В том числе их взор упал и на проект ядра Linux. Связано это с его известностью и адаптированностью по всему миру.

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

Один из ведущих разработчиков, поддерживающих Linux-ядро, Грег Крох-Хартман даже написал разъярённое письмо исследователям.

Нашему комьюнити не нравится, когда над ним экспериментируют и «тестируют», отправляя известные исправления, которые либо намеренно ничего не делают, либо намеренно вносят ошибки <...> Из-за этого мне теперь придётся забанить все будущие контрибуции из вашего университета и «похоронить» предыдущие, поскольку они явно были поданы недобросовестно с намерением вызвать проблемы.

Отметим, что научная работа, ради которой всё это затевалось, вышла ещё в феврале 2021 года. Согласно ей, количество успешных «инъекций» уязвимостей составляет около 60% от общего числа попыток.

Источник: FOSS Post

На сайте компании появился пост, в котором разработчики анонсировали Windows 10 Insider Preview Build 21337. В свежем апдейте появится ряд мелких нововведений, главным из которых должны стать кастомизируемые виртуальные рабочие столы.

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

Для того, чтобы попробовать новую функцию, надо присоединиться к программе Windows Insider и переключиться на «Канал Dev».

Как поменять обои у одного из рабочих столов?

Нажать правой кнопкой на него и выбрать «Choose background» («Выбрать фон»).

Как поменять порядок виртуальных рабочих столов?

Нажать правой кнопкой мыши и выбрать «Move Right («Переместить вправо») или «Move Left» («Переместить влево»). Либо просто перетащить мышкой.

Источник: Блог Windows

Изменённые «правила оформления» мобильной операционки Google придут на смену прежнему Material Design. Он, напомним, дебютировал в 2014 году вместе с Android 5.0 Lollipop. С тех пор стиль неоднократно дорабатывался, но в целом продолжал придерживаться заложенных в самом начале правил.

Судя по утекшим скриншотам Android 12, следующая версия «зелёного робота» визуально будет значительно отличаться от предшественников. Теперь это скорее будет помесь iOS и MIUI, нежели прежний Android. Данная особенность может стать причиной перехода от традиционного Material к Material NEXT.

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

Судя по опыту прошлых лет, первыми опробовать Android 12 смогут владельцы смартфонов линейки Google Pixel. В дальнейшем к ним подключатся и пользователи избранных флагманов Xiaomi, Realme и некоторых других брендов. Ожидается, что первая бета для разработчиков выйдет уже 17 февраля 2021 года.

Источник: Gizmochina

Для того, чтобы протестировать разработку Huawei, Амадео пришлось пройти целый «ритуал». Сначала он отправил копию своего паспорта, персонального ID и данные карты разработчикам. Затем прождал около двух дней, пока переданные им сведения проверят вручную. И только после этого журналисту дали доступ к Harmony OS 2.0.

Хотя как дали… Он не запускал бета-версию операционной системы на каком-то эмуляторе. Вместо этого ОС стримилась к нему в разрешении около 720р, как Stadia стримит игры, а Netflix – сериалы. Т.е. Сама операционка запускалась на неизвестном устройстве в Китае, а Амадео получал лишь картинку с «сервера».

После небольшого тестирования второй версии Harmony OS, журналист пришёл к выводу, что это лишь немного видоизменённый Android 10. Об этом говорят пункты меню, общий стиль оформления и UX-логика, которые очень сильно напоминают разработку Google.

Источник: Ars Technica

Среди собранных под одной крышей «технологий» можно найти 3D-рендеринг, инструменты для командной строки, BitTorrent-клиент, поисковый движок и т.д. В репозитории даже собраны материалы, которые учат создавать языки программирования с использованием Ассемблера.

Полный список технологий, собранных в репозитории build-your-own-x

• 3D-рендеринг
• Дополненная реальность (AR)
• BitTorrent-клиент
• Блокчейн / Криптовалюта
• Бот
• Инструменты командной строки
• Базы данных
• Docker
• Эмулятор / Виртуальная машина
• Front-end фреймворк / Библиотека
• Игра
• Git
• Сетевой стек
• Нейросеть
• Операционная система
• Физический движок
• Язык программирования
• Движок регулярных выражений
• Поисковый движок
• Shell
• Движок шаблонов
• Текстовый редактор
• Система визуального распознавания
• Воксельный движок
• Движок для веб-поиска
• Веб-сервер
• Без категории

Источник: GitHub / build-your-own-x

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

Новый дистрибутив протестировали на Huawei MateBook 14 и Microsoft Surface 6. Разработчики обещают в ближайшее время обеспечить поддержку других устройств, в том числе планшетов на базе ARM-чипов.

На официальном сайте дистрибутива можно подписаться на новости о состоянии JingOS. Доступной для загрузки версия для планшетов станет 31 января 2021 года. В разработке также находится версия для смартфонов. Её планируют выпустить до конца года.

Часть интересных нововведений

• В XFS добавили изменения, позволившие отсрочить проблемы с переполнением 32-разрядного типа данных time_t. В новой версии ядра счётчик будет переполнен к 2468 году, а не к 2038, как это было ранее.
• Наконец-то ядро избавили от реализации KerberosV-алгоритма RC4-HMAC-MD5. Его внедрили десятилетия назад для совместимости с Windows NT/2000, обновление которых было прекращено ещё в 2008 году.
• Добавили поддержку мониторинга температуры в драйвере k10temp для чипов AMD Zen 3.

Разумеется, это далеко не все изменения. В общей сложности, новая версия ядра получила 17 470 исправлений, внесённых 2 062 разработчиками. Общий вес патча составляет 64 МБ.

Интересная статистика, приведённая в тексте релиза: примерно 42% из всех представленных в Linux 5.10 изменений касаются драйверов устройств, около 16% — обновления кода, специфичного для аппаратных архитектур, 13% — сетевого стека и по 3% изменений коснулись файловой системы и внутренних подсистем ядра.

Источник: LKML.ORG

Чтобы сторонним разработчикам было удобнее следить за проектом и присылать свои изменения, сотрудники Google ввели в строй публичные списки рассылки и систему отслеживания ошибок. Также в публичном доступе появилась дорожная карта Fuchsia, которая поможет понять направление и приоритеты развития операционной системы. Механизмы принятия решений описаны в общедоступной модели управления проектом.

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

Fuchsia — проект с открытым исходным кодом, целью которого является разработка универсальной операционной системы. Впервые о нём стало известно более 4 лет назад. В основе новой ОС — микроядро Zircon, основанное на наработках проекта LK, который был расширен для применения на устройствах различного класса, включая смартфоны, компьютеры и потребительскую технику.

Кстати, интересно, что она не находилась где-нибудь на сайтах с книгами, тем более не продавалась в книжных магазинах, единственным местом, где мне удалось найти текст книги, был GitHub репозиторий, созданный автором. Ну, и конечно, ее не было на русском, и я почти уверен, что до сих пор нет в переводе, только английский оригинал. Но так еще лучше: отличная прокачка знаний языка для программистов.

Книга проводит читателя через весь процесс создания операционной системы с нуля, даже человек, не знающий принципов электроцепей и не имеющий глубоких знаний в программировании, может разобраться с темой. И это мне, как специалисту в другом направлении программирования особенно понравилось. Книга знакомит с основными терминами компьютерных систем, из чего состоит процессор, как на физическом уровне создаются логические схемы, что такое MOSFETs и цифровые логические вентили (digital logic gates). При этом автор не вдается в глубокие подробности, которые можно изучить дополнительно из другой литературы.

Затем в книге даются знания о том, как создать операционную систему для IBM x86 процессоров. При этом читателю достаточно довольно неглубоких знаний в таких языках как С/С++ и Ассемблер. Есть отдельная глава об этих языках и их совместном использовании: «we will explore assembly language, and how it connects to C». Есть там и про бинарный код и инструкции Assembly.

Тема тронула меня и вызвала не только интерес, но и энтузиазм, ведь я много лет назад уже собирал Linux from scratch. А также полгода как начал на досуге учиться программировать на С, с которым мне не приходится работать, потому что я специализируюсь на веб-разработке. В процессе чтения я предпринял попытку реализовать часть знаний, полученных из книги, насколько мне позволяли свободное время и опыт в С программировании. И, Oh my Gosh, у меня получилось запустить в виртуальной машине ОС с функциональностью печатной машинки. Да-да, это немногим больше, чем «Hello word», но для меня этого с лихвой хватило, чтобы вдохновиться на то, чтобы продолжать изучать эту тему.

Но это еще не все. Из книги можно почерпнуть базовые знания по архитектуре современных компьютеров, принципы работы логических схем и центральных процессоров, работающих на их физической реализации. Она помогает понять, как устроены операционные системы. В особенности автор рекомендует ее прочитать тем, кто хочет разбираться в Linux не просто как уверенный пользователь или администратор, но как настоящий разработчик таких сложных систем и программного обеспечения к ним. Я считаю, что это одна из тех книг, которую стоит прочитать каждому студенту IT-специальностей, потому что она создаст в голове правильную базу знаний, понимания профессии.