Один скрипт, пять дистрибутивов. Что пойдёт не так?
Взял простую задачу: развернуть небольшой веб-сервис на Python с зависимостями через pip, systemd-юнит и nginx как реверс-прокси. Классика. Прошёлся по пяти популярным дистрибутивам и записал, где споткнулся.
Ubuntu 24.04
Самый предсказуемый опыт. apt отработал без сюрпризов, nginx в репозитории свежий, systemd ведёт себя как ожидаешь. Единственная засада: Python 3.12 по умолчанию, и pip теперь требует виртуальное окружение, иначе ругается на externally-managed-environment. Пришлось добавить python3 -m venv в скрипт. Мелочь, но неподготовленного человека остановит.
Debian 12 Bookworm
Стабильность — это хорошо. Но nginx в репозитории версии 1.22, а нужна была фича из 1.25. Пришлось подключать официальный репозиторий nginx. Плюс та же история с pip и venv, что у Ubuntu. В остальном всё тихо и спокойно, как и положено Debian.
Fedora 40
Неожиданно приятно. dnf быстрее, чем ожидал. SELinux не заблокировал ничего сразу, но когда настраивал сокет для nginx, пришлось делать setsebool -P httpd_can_network_connect 1. Кто не знает про SELinux, потратит час на дебаг. nginx свежий, Python свежий, проблем с venv нет.
Arch Linux
Всё самое новое, пакеты актуальные, никаких костылей с репозиториями. Но здесь другая ловушка: systemd-юнит не заработал с первой попытки из-за того, что путь к Python в venv я прописал относительный. На остальных дистрибутивах это тоже не работало бы, просто там я это поймал раньше. Arch не прощает невнимательности, зато честно говорит что именно сломалось. journalctl -xe реально помог.
Alpine Linux
Отдельная история. Используется как база для Docker-образов, но я поднимал его на железе ради чистоты эксперимента. Нет systemd, есть OpenRC. Скрипт пришлось переписывать в части управления сервисами. apk быстрый, образ минимальный, но если вы берёте готовые инструкции из интернета, половина из них про systemd и работать не будет. nginx настраивается так же, зависимостей pip меньше, потому что musl вместо glibc иногда требует пересборки колёс.
Итог по дистрибутивам
Ubuntu и Debian: работает из коробки, но следите за версиями пакетов и новым поведением pip.
Fedora: хороший выбор, SELinux нужно понимать, иначе он вас будет злить.
Arch: для тех, кто читает что происходит, а не просто копипастит команды.
Alpine: совсем другой мир, если вы привыкли к systemd.
Главный вывод не в том, какой дистрибутив лучше. Главный вывод в том, что "один скрипт для всех" не существует. Даже такая простая задача требует учитывать пакетный менеджер, версии пакетов, систему инициализации и политики безопасности. Чем сложнее задача, тем больше расходятся пути.
Если пишете автоматизацию для нескольких дистрибутивов сразу, закладывайте время на тестирование каждого окружения отдельно. Ansible и ему подобные инструменты существуют именно по этой причине.
Канал linux.exe
Подпишись на создателей: https://t.me/linuxexex
Взял простую задачу: развернуть небольшой веб-сервис на Python с зависимостями через pip, systemd-юнит и nginx как реверс-прокси. Классика. Прошёлся по пяти популярным дистрибутивам и записал, где споткнулся.
Ubuntu 24.04
Самый предсказуемый опыт. apt отработал без сюрпризов, nginx в репозитории свежий, systemd ведёт себя как ожидаешь. Единственная засада: Python 3.12 по умолчанию, и pip теперь требует виртуальное окружение, иначе ругается на externally-managed-environment. Пришлось добавить python3 -m venv в скрипт. Мелочь, но неподготовленного человека остановит.
Debian 12 Bookworm
Стабильность — это хорошо. Но nginx в репозитории версии 1.22, а нужна была фича из 1.25. Пришлось подключать официальный репозиторий nginx. Плюс та же история с pip и venv, что у Ubuntu. В остальном всё тихо и спокойно, как и положено Debian.
Fedora 40
Неожиданно приятно. dnf быстрее, чем ожидал. SELinux не заблокировал ничего сразу, но когда настраивал сокет для nginx, пришлось делать setsebool -P httpd_can_network_connect 1. Кто не знает про SELinux, потратит час на дебаг. nginx свежий, Python свежий, проблем с venv нет.
Arch Linux
Всё самое новое, пакеты актуальные, никаких костылей с репозиториями. Но здесь другая ловушка: systemd-юнит не заработал с первой попытки из-за того, что путь к Python в venv я прописал относительный. На остальных дистрибутивах это тоже не работало бы, просто там я это поймал раньше. Arch не прощает невнимательности, зато честно говорит что именно сломалось. journalctl -xe реально помог.
Alpine Linux
Отдельная история. Используется как база для Docker-образов, но я поднимал его на железе ради чистоты эксперимента. Нет systemd, есть OpenRC. Скрипт пришлось переписывать в части управления сервисами. apk быстрый, образ минимальный, но если вы берёте готовые инструкции из интернета, половина из них про systemd и работать не будет. nginx настраивается так же, зависимостей pip меньше, потому что musl вместо glibc иногда требует пересборки колёс.
Итог по дистрибутивам
Ubuntu и Debian: работает из коробки, но следите за версиями пакетов и новым поведением pip.
Fedora: хороший выбор, SELinux нужно понимать, иначе он вас будет злить.
Arch: для тех, кто читает что происходит, а не просто копипастит команды.
Alpine: совсем другой мир, если вы привыкли к systemd.
Главный вывод не в том, какой дистрибутив лучше. Главный вывод в том, что "один скрипт для всех" не существует. Даже такая простая задача требует учитывать пакетный менеджер, версии пакетов, систему инициализации и политики безопасности. Чем сложнее задача, тем больше расходятся пути.
Если пишете автоматизацию для нескольких дистрибутивов сразу, закладывайте время на тестирование каждого окружения отдельно. Ansible и ему подобные инструменты существуют именно по этой причине.
Канал linux.exe
Подпишись на создателей: https://t.me/linuxexex
Притча о топоре, совести и плохой арифметике
Однажды у канавы, где Петербург делал вид, что он город, а не мокрая папка с долгами сидел человек и держал рядом предмет с табличкой «старый чайник». Это был не просто предмет, а маленький самоварный философ, булькающий как совесть перед дедлайном. Человек смотрел на него так, будто эта вещь сейчас подпишет ему справку о величии.
И тут появился Сократ с лицом человека, который уже видел тысячу гениальных оправданий и ни одного нормального.
— Скажи мне, друг, — спросил он, — чем отличается великая идея от таракана в голове, если оба бегают ночью и мешают спать?
Человек вздрогнул. Петербург вокруг был мокрый, нервный и такой жёлтый, будто его рисовали не краской, а просроченной тревогой.
— Я хотел стать выше обстоятельств, а оказался ниже собственной отговорки.
— Значит, — сказал Сократ, — ты перепутал мысль с индульгенцией. Мысль должна освещать комнату, а не подсовывать тебе инструмент и шептать: «ну давай, докажи, что ты особенный».
В этот момент совесть вышла из угла в старом пальто и кашлянула так, что даже стены перестали спорить. Человек хотел возразить, но слова вдруг стали тяжёлыми, как мокрые сапоги. Он понял, что спорил не с философом, а с той частью себя, которая давно всё знала и просто ждала, когда её перестанут перебивать.
Сократ поднял палец:
— Запомни: если для твоей правоты другому человеку надо исчезнуть как человеку, то это не правота. Это бухгалтерия страха. А страх, даже если надеть на него умное пальто, всё равно будет пахнуть подвалом.
С тех пор он боялся не закона, а секунды тишины, где всё наконец становится понятно.
Однажды у канавы, где Петербург делал вид, что он город, а не мокрая папка с долгами сидел человек и держал рядом предмет с табличкой «старый чайник». Это был не просто предмет, а маленький самоварный философ, булькающий как совесть перед дедлайном. Человек смотрел на него так, будто эта вещь сейчас подпишет ему справку о величии.
И тут появился Сократ с лицом человека, который уже видел тысячу гениальных оправданий и ни одного нормального.
— Скажи мне, друг, — спросил он, — чем отличается великая идея от таракана в голове, если оба бегают ночью и мешают спать?
Человек вздрогнул. Петербург вокруг был мокрый, нервный и такой жёлтый, будто его рисовали не краской, а просроченной тревогой.
— Я хотел стать выше обстоятельств, а оказался ниже собственной отговорки.
— Значит, — сказал Сократ, — ты перепутал мысль с индульгенцией. Мысль должна освещать комнату, а не подсовывать тебе инструмент и шептать: «ну давай, докажи, что ты особенный».
В этот момент совесть вышла из угла в старом пальто и кашлянула так, что даже стены перестали спорить. Человек хотел возразить, но слова вдруг стали тяжёлыми, как мокрые сапоги. Он понял, что спорил не с философом, а с той частью себя, которая давно всё знала и просто ждала, когда её перестанут перебивать.
Сократ поднял палец:
— Запомни: если для твоей правоты другому человеку надо исчезнуть как человеку, то это не правота. Это бухгалтерия страха. А страх, даже если надеть на него умное пальто, всё равно будет пахнуть подвалом.
С тех пор он боялся не закона, а секунды тишины, где всё наконец становится понятно.
jq -- это маленький, но дьявольски полезный инструмент командной строки для работы с JSON. Если ты хоть раз работал с API, логами или конфигами, то знаешь, как больно читать сырой JSON в терминале. jq решает это раз и навсегда.
Что умеет jq
Фильтрует, трансформирует и форматирует JSON прямо в терминале. Никакого Python-скрипта на три строки, никакого открытия браузера -- просто пишешь запрос и получаешь ответ.
Базовые примеры
Красиво напечатать JSON:
curl -s https://api.example.com/users | jq.
Вытащить конкретное поле:
cat data.json | jq '.name'
Получить массив имён из списка объектов:
cat users.json | jq '.[].name'
Отфильтровать только активных пользователей:
cat users.json | jq '[.[] | select(.active == true)]'
Сложить все цены в массиве:
cat orders.json | jq '[.[].price] | add'
Это не просто просмотрщик. jq -- полноценный язык запросов. Можно делать map, select, reduce, создавать новые объекты на лету, комбинировать фильтры через пайпы.
Реальный кейс
Допустим, тебе нужно из ответа GitHub API вытащить имена всех публичных репозиториев:
curl -s https://api.github.com/users/torvalds/repos | jq '.[].full_name'
Одна команда -- и у тебя список. Без скриптов, без парсинга вручную.
Установка
Debian/Ubuntu: apt install jq
Arch: pacman -S jq
macOS: brew install jq
Windows: winget install jqlang.jq
Есть и онлайн-версия -- jqplay.org, где можно тестировать фильтры прямо в браузере.
jq легко недооценить, пока не начнёшь использовать каждый день. После этого возвращаться к ручному разбору JSON физически больно.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Что умеет jq
Фильтрует, трансформирует и форматирует JSON прямо в терминале. Никакого Python-скрипта на три строки, никакого открытия браузера -- просто пишешь запрос и получаешь ответ.
Базовые примеры
Красиво напечатать JSON:
curl -s https://api.example.com/users | jq.
Вытащить конкретное поле:
cat data.json | jq '.name'
Получить массив имён из списка объектов:
cat users.json | jq '.[].name'
Отфильтровать только активных пользователей:
cat users.json | jq '[.[] | select(.active == true)]'
Сложить все цены в массиве:
cat orders.json | jq '[.[].price] | add'
Это не просто просмотрщик. jq -- полноценный язык запросов. Можно делать map, select, reduce, создавать новые объекты на лету, комбинировать фильтры через пайпы.
Реальный кейс
Допустим, тебе нужно из ответа GitHub API вытащить имена всех публичных репозиториев:
curl -s https://api.github.com/users/torvalds/repos | jq '.[].full_name'
Одна команда -- и у тебя список. Без скриптов, без парсинга вручную.
Установка
Debian/Ubuntu: apt install jq
Arch: pacman -S jq
macOS: brew install jq
Windows: winget install jqlang.jq
Есть и онлайн-версия -- jqplay.org, где можно тестировать фильтры прямо в браузере.
jq легко недооценить, пока не начнёшь использовать каждый день. После этого возвращаться к ручному разбору JSON физически больно.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
CTRL+R все знают. А вот это — нет.
В bash и zsh есть встроенная замена строк прямо в истории команд. Выглядит страшно, работает магически.
Допустим, ты только что запустил:
grep -r "old_function" /var/www/project
И хочешь повторить то же самое, но искать "new_function". Не нажимаешь стрелку вверх и не тащишь курсор по строке.
Просто пишешь:
^old_function^new_function
И жмёшь Enter. Шелл подставляет предыдущую команду с заменой первого вхождения и сразу выполняет. Всё.
Это называется quick substitution — быстрая подстановка. Работает в bash и zsh из коробки, никаких плагинов.
Ограничение: заменяется только первое вхождение. Если нужно заменить все вхождения — используй расширенный синтаксис через двойной восклицательный знак:
!!:gs/old_function/new_function/
Здесь!! — это предыдущая команда целиком,:g — флаг "global", s — substitute. Синтаксис как в sed, только внутри истории шелла.
Ещё несколько трюков из той же серии.
Взять последний аргумент предыдущей команды:
!$
Пример: написал mkdir /var/www/myproject, потом хочешь туда перейти. Пишешь cd!$ и шелл раскроет это в cd /var/www/myproject.
Взять первый аргумент:
!^
Взять все аргументы без самой команды:
!*
Например, запустил vim file1.txt file2.txt file3.txt, а потом хочешь скопировать те же файлы куда-то: cp!* /backup/
Взять n-й аргумент по номеру:
!!:2
Это второй аргумент из предыдущей команды. Нумерация с нуля, где 0 — сама команда.
Запустить последнюю команду, начинавшуюся на определённые буквы:
!gr
Это выполнит последнюю команду из истории, которая начинается на "gr" — например, снова запустит тот grep.
Почему этим мало кто пользуется? Потому что выглядит как line noise, а документация по expansion в bash спрятана глубоко в man-странице под заголовком HISTORY EXPANSION. Большинство людей туда не доходят.
Попробуй сегодня в терминале. Один раз почувствуешь — и начнёшь использовать регулярно.
Подпишись на создателей: https://t.me/linuxexex
В bash и zsh есть встроенная замена строк прямо в истории команд. Выглядит страшно, работает магически.
Допустим, ты только что запустил:
grep -r "old_function" /var/www/project
И хочешь повторить то же самое, но искать "new_function". Не нажимаешь стрелку вверх и не тащишь курсор по строке.
Просто пишешь:
^old_function^new_function
И жмёшь Enter. Шелл подставляет предыдущую команду с заменой первого вхождения и сразу выполняет. Всё.
Это называется quick substitution — быстрая подстановка. Работает в bash и zsh из коробки, никаких плагинов.
Ограничение: заменяется только первое вхождение. Если нужно заменить все вхождения — используй расширенный синтаксис через двойной восклицательный знак:
!!:gs/old_function/new_function/
Здесь!! — это предыдущая команда целиком,:g — флаг "global", s — substitute. Синтаксис как в sed, только внутри истории шелла.
Ещё несколько трюков из той же серии.
Взять последний аргумент предыдущей команды:
!$
Пример: написал mkdir /var/www/myproject, потом хочешь туда перейти. Пишешь cd!$ и шелл раскроет это в cd /var/www/myproject.
Взять первый аргумент:
!^
Взять все аргументы без самой команды:
!*
Например, запустил vim file1.txt file2.txt file3.txt, а потом хочешь скопировать те же файлы куда-то: cp!* /backup/
Взять n-й аргумент по номеру:
!!:2
Это второй аргумент из предыдущей команды. Нумерация с нуля, где 0 — сама команда.
Запустить последнюю команду, начинавшуюся на определённые буквы:
!gr
Это выполнит последнюю команду из истории, которая начинается на "gr" — например, снова запустит тот grep.
Почему этим мало кто пользуется? Потому что выглядит как line noise, а документация по expansion в bash спрятана глубоко в man-странице под заголовком HISTORY EXPANSION. Большинство людей туда не доходят.
Попробуй сегодня в терминале. Один раз почувствуешь — и начнёшь использовать регулярно.
Подпишись на создателей: https://t.me/linuxexex
linux.exe | сравниваем дистрибутивы по-честному
Задача простая и жизненная: поднять веб-сервер с nginx, настроить systemd-сервис и запустить Python-скрипт по таймеру. Ничего экзотического. Но именно на таких вещах дистрибутивы и расходятся по характеру.
Берём пятёрку: Ubuntu 24.04, Debian 12, Arch, Fedora 40, Alpine 3.19.
--- Установка nginx ---
Ubuntu и Fedora: apt install nginx / dnf install nginx, после чего демон сразу добавляется в автозапуск. Удобно, но иногда раздражает, когда не просил.
Debian: то же самое через apt, но без автозапуска. Уважает твою волю.
Arch: pacman -S nginx, никакого автозапуска. Хочешь работающий сервис — включи сам через systemctl enable.
Alpine: apk add nginx, но systemd здесь нет в принципе. Управление через OpenRC. Команды другие, логика другая, привыкай.
--- Python-скрипт по таймеру ---
На всех systemd-дистрибутивах создаёшь два файла: mytask.service и mytask.timer. В таймере пишешь OnCalendar=*:0/15, и скрипт молотит каждые 15 минут. Чисто, предсказуемо, логи в journald.
На Alpine вместо этого cron. Либо dcron, либо busybox cron. Работает, но дебажить неудобно: логи куда попало, поведение зависит от реализации.
--- Размер и скорость ---
Alpine выигрывает вчистую. Базовый образ 5 мегабайт против 70-80 у Ubuntu. В контейнерах это решает. Arch после минимальной установки тоже компактный, но растёт быстро, потому что руки сами тянутся поставить всё подряд.
Fedora самая жирная из коробки: DNF медленнее apt, зато пакеты свежие и SELinux включён по умолчанию. Кстати, именно SELinux на Fedora подарит тебе первый сюрприз: nginx не сможет слушать нестандартный порт, пока не пропишешь разрешение через semanage. Новички гуглят это часами.
--- Стабильность против свежести ---
Debian 12 несёт пакеты из 2022-2023 годов. Nginx там версии 1.22. Для продакшна это норма, для экспериментов скучно.
Ubuntu 24.04 чуть свежее, плюс snap-пакеты, которые многие ненавидят, но которые реально помогают поставить актуальный софт без танцев.
Arch живёт на острие: сегодня nginx 1.27, завтра 1.28. Обновляешь систему раз в неделю или ловишь сломанные зависимости. Это не страшно, если понимаешь что делаешь.
--- Итог по задаче ---
Если это прод-сервер и нужна предсказуемость: Debian. Минимум сюрпризов, долгая поддержка, ничего лишнего.
Если нужен баланс свежести и удобства: Ubuntu или Fedora. Разница между ними в основном в том, любишь ли ты apt или dnf и насколько тебя бесит SELinux.
Если собираешь Docker-образ и важен размер: Alpine без вопросов. Только учти, что там musl вместо glibc, и некоторые бинари ведут себя не так, как ожидаешь.
Если хочешь разобраться как всё устроено и не боишься читать вики: Arch. Лучший способ перестать быть пользователем и стать администратором.
Дистрибутивы не плохие и не хорошие. Они под разные задачи. Выбор не религия, а инструмент.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Задача простая и жизненная: поднять веб-сервер с nginx, настроить systemd-сервис и запустить Python-скрипт по таймеру. Ничего экзотического. Но именно на таких вещах дистрибутивы и расходятся по характеру.
Берём пятёрку: Ubuntu 24.04, Debian 12, Arch, Fedora 40, Alpine 3.19.
--- Установка nginx ---
Ubuntu и Fedora: apt install nginx / dnf install nginx, после чего демон сразу добавляется в автозапуск. Удобно, но иногда раздражает, когда не просил.
Debian: то же самое через apt, но без автозапуска. Уважает твою волю.
Arch: pacman -S nginx, никакого автозапуска. Хочешь работающий сервис — включи сам через systemctl enable.
Alpine: apk add nginx, но systemd здесь нет в принципе. Управление через OpenRC. Команды другие, логика другая, привыкай.
--- Python-скрипт по таймеру ---
На всех systemd-дистрибутивах создаёшь два файла: mytask.service и mytask.timer. В таймере пишешь OnCalendar=*:0/15, и скрипт молотит каждые 15 минут. Чисто, предсказуемо, логи в journald.
На Alpine вместо этого cron. Либо dcron, либо busybox cron. Работает, но дебажить неудобно: логи куда попало, поведение зависит от реализации.
--- Размер и скорость ---
Alpine выигрывает вчистую. Базовый образ 5 мегабайт против 70-80 у Ubuntu. В контейнерах это решает. Arch после минимальной установки тоже компактный, но растёт быстро, потому что руки сами тянутся поставить всё подряд.
Fedora самая жирная из коробки: DNF медленнее apt, зато пакеты свежие и SELinux включён по умолчанию. Кстати, именно SELinux на Fedora подарит тебе первый сюрприз: nginx не сможет слушать нестандартный порт, пока не пропишешь разрешение через semanage. Новички гуглят это часами.
--- Стабильность против свежести ---
Debian 12 несёт пакеты из 2022-2023 годов. Nginx там версии 1.22. Для продакшна это норма, для экспериментов скучно.
Ubuntu 24.04 чуть свежее, плюс snap-пакеты, которые многие ненавидят, но которые реально помогают поставить актуальный софт без танцев.
Arch живёт на острие: сегодня nginx 1.27, завтра 1.28. Обновляешь систему раз в неделю или ловишь сломанные зависимости. Это не страшно, если понимаешь что делаешь.
--- Итог по задаче ---
Если это прод-сервер и нужна предсказуемость: Debian. Минимум сюрпризов, долгая поддержка, ничего лишнего.
Если нужен баланс свежести и удобства: Ubuntu или Fedora. Разница между ними в основном в том, любишь ли ты apt или dnf и насколько тебя бесит SELinux.
Если собираешь Docker-образ и важен размер: Alpine без вопросов. Только учти, что там musl вместо glibc, и некоторые бинари ведут себя не так, как ожидаешь.
Если хочешь разобраться как всё устроено и не боишься читать вики: Arch. Лучший способ перестать быть пользователем и стать администратором.
Дистрибутивы не плохие и не хорошие. Они под разные задачи. Выбор не религия, а инструмент.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Ubuntu vs Debian на сервере
Если нужен сервер «поставил и забыл», Debian часто выигрывает стабильностью и предсказуемостью. Пакеты обновляются спокойнее, сюрпризов меньше.
Ubuntu удобнее, когда нужны более свежие версии, много готовых гайдов и поддержка популярных облачных образов.
Коротко:
Debian — консервативно, стабильно, чисто.
Ubuntu — практично, популярно, много документации.
Для продакшена важнее не логотип дистрибутива, а понятные обновления, бэкапы и мониторинг.
Подпишись на создателей: https://t.me/linuxexex
Если нужен сервер «поставил и забыл», Debian часто выигрывает стабильностью и предсказуемостью. Пакеты обновляются спокойнее, сюрпризов меньше.
Ubuntu удобнее, когда нужны более свежие версии, много готовых гайдов и поддержка популярных облачных образов.
Коротко:
Debian — консервативно, стабильно, чисто.
Ubuntu — практично, популярно, много документации.
Для продакшена важнее не логотип дистрибутива, а понятные обновления, бэкапы и мониторинг.
Подпишись на создателей: https://t.me/linuxexex
NEURAL BRAIN: Команда ss вместо netstat
Если нужно быстро понять, какие порты слушает сервер, попробуй:
ss -tulpen
Она показывает TCP/UDP-сокеты, процессы, PID и порты. В отличие от старого netstat, ss обычно уже есть в современных дистрибутивах и работает быстрее на нагруженных системах.
Мини-шпаргалка:
ss -ltnp — слушающие TCP-порты
ss -uan — UDP-соединения
ss -s — короткая статистика по сокетам
Полезно для диагностики: когда сервис «запущен», но порт почему-то не отвечает.
Подпишись на создателей: https://t.me/linuxexex
Если нужно быстро понять, какие порты слушает сервер, попробуй:
ss -tulpen
Она показывает TCP/UDP-сокеты, процессы, PID и порты. В отличие от старого netstat, ss обычно уже есть в современных дистрибутивах и работает быстрее на нагруженных системах.
Мини-шпаргалка:
ss -ltnp — слушающие TCP-порты
ss -uan — UDP-соединения
ss -s — короткая статистика по сокетам
Полезно для диагностики: когда сервис «запущен», но порт почему-то не отвечает.
Подпишись на создателей: https://t.me/linuxexex
Единственный тред по СИ clang
Тред для всех кто хочет погрузиться в низкоуровневое и системное программирование дедушки си
Обсуждаем чужие гитхабы, коды, программирование микроконтроллеров.
сам учился на степике, всем советую прочитать книгу Брайана Кернигана и Денниса Ритчи «Язык программирования Си»
ЗАДАВАЙТЕ ВОПРОСЫ И ПОЛУЧАЙТЕ ОТВЕТЫ!
Источник (2ch /pr/): https://2ch.org/pr/res/3619616.html
Подпишись на создателей: https://t.me/linuxexex
Тред для всех кто хочет погрузиться в низкоуровневое и системное программирование дедушки си
Обсуждаем чужие гитхабы, коды, программирование микроконтроллеров.
сам учился на степике, всем советую прочитать книгу Брайана Кернигана и Денниса Ритчи «Язык программирования Си»
ЗАДАВАЙТЕ ВОПРОСЫ И ПОЛУЧАЙТЕ ОТВЕТЫ!
Источник (2ch /pr/): https://2ch.org/pr/res/3619616.html
Подпишись на создателей: https://t.me/linuxexex
Двач
/Программирование/ - Единственный тред по СИ clang
Совет по безопасности для линуксоида, который не хочет однажды обнаружить, что его сервер майнит крипту для дяди из интернета.
Первое и самое банальное, которое всё равно игнорируют — не сиди под рутом. Никогда. Вообще. Создай обычного пользователя и работай через него. sudo придумали не просто так, а чтобы ты хотя бы осознанно делал что-то деструктивное, а не случайно.
Второе — SSH. Если у тебя на сервере открыт 22 порт с парольной аутентификацией, можешь считать, что повесил объявление "взломайте меня, пожалуйста". Переходи на ключи, меняй порт на нестандартный, ставь fail2ban. В /etc/ssh/sshd_config пропиши PasswordAuthentication no и PermitRootLogin no. Это пять минут работы, но спасёт от тонны брутфорса.
Третье — firewall. ufw или iptables, не важно. Главное закрой всё что не используешь. Базовая схема: запрети всё входящее по умолчанию, разреши только то, что реально нужно. ufw default deny incoming, ufw allow ssh, ufw enable. Готово. Не надо быть параноиком, достаточно не быть идиотом.
Четвёртое — обновления. "Обновлю потом" — это путь в ад. В репозиториях регулярно закрывают дыры, а если ты сидишь на пакетах годичной давности, ты открытый склад уязвимостей. Поставь unattended-upgrades или хотя бы раз в неделю запускай apt upgrade вручную. На RPM-системах — dnf upgrade. Это не сложно.
Пятое — аудит того, что вообще слушает сеть. ss -tulnp или netstat -tulnp. Посмотри список. Часто обнаруживается, что какой-то сервис висит на 0.0.0.0 и светит наружу без всякой необходимости. Если не знаешь зачем оно там — отключи.
Шестое — логи читать не западло. /var/log/auth.log или journalctl -u ssh покажут, кто и как пытается к тебе лезть. Это полезная информация, а не мусор.
Бонус для параноиков: поставь auditd, настрой SELinux или AppArmor, используй rkhunter для проверки на руткиты. Это уже уровень выше, но если у тебя на сервере что-то важное — оно того стоит.
Безопасность это не разовая акция, это привычка. Потрать час сейчас или потрать неделю потом, восстанавливая систему и объясняя клиентам, куда делись их данные.
Подпишись на создателей: https://t.me/linuxexex
Первое и самое банальное, которое всё равно игнорируют — не сиди под рутом. Никогда. Вообще. Создай обычного пользователя и работай через него. sudo придумали не просто так, а чтобы ты хотя бы осознанно делал что-то деструктивное, а не случайно.
Второе — SSH. Если у тебя на сервере открыт 22 порт с парольной аутентификацией, можешь считать, что повесил объявление "взломайте меня, пожалуйста". Переходи на ключи, меняй порт на нестандартный, ставь fail2ban. В /etc/ssh/sshd_config пропиши PasswordAuthentication no и PermitRootLogin no. Это пять минут работы, но спасёт от тонны брутфорса.
Третье — firewall. ufw или iptables, не важно. Главное закрой всё что не используешь. Базовая схема: запрети всё входящее по умолчанию, разреши только то, что реально нужно. ufw default deny incoming, ufw allow ssh, ufw enable. Готово. Не надо быть параноиком, достаточно не быть идиотом.
Четвёртое — обновления. "Обновлю потом" — это путь в ад. В репозиториях регулярно закрывают дыры, а если ты сидишь на пакетах годичной давности, ты открытый склад уязвимостей. Поставь unattended-upgrades или хотя бы раз в неделю запускай apt upgrade вручную. На RPM-системах — dnf upgrade. Это не сложно.
Пятое — аудит того, что вообще слушает сеть. ss -tulnp или netstat -tulnp. Посмотри список. Часто обнаруживается, что какой-то сервис висит на 0.0.0.0 и светит наружу без всякой необходимости. Если не знаешь зачем оно там — отключи.
Шестое — логи читать не западло. /var/log/auth.log или journalctl -u ssh покажут, кто и как пытается к тебе лезть. Это полезная информация, а не мусор.
Бонус для параноиков: поставь auditd, настрой SELinux или AppArmor, используй rkhunter для проверки на руткиты. Это уже уровень выше, но если у тебя на сервере что-то важное — оно того стоит.
Безопасность это не разовая акция, это привычка. Потрать час сейчас или потрать неделю потом, восстанавливая систему и объясняя клиентам, куда делись их данные.
Подпишись на создателей: https://t.me/linuxexex
CTRL+R все знают. А вот что мало кто юзает — это параметр HISTTIMEFORMAT и связка с fc.
Начнём с простого. Если ты хочешь видеть дату и время каждой команды в истории, добавь в ~/.bashrc одну строку:
HISTTIMEFORMAT="%d.%m.%Y %H:%M:%S "
После этого history покажет не просто список команд, а когда именно ты их запускал. Удобно, когда надо выяснить, в какой момент ты всё сломал.
Теперь про fc. Это встроенная команда bash и zsh, которую игнорирует большинство людей, а зря.
fc без аргументов открывает последнюю команду в редакторе (vim, nano, что там у тебя в EDITOR). Исправил — сохранил — она сразу выполнилась. Не надо лезть в стрелку вверх и ковыряться в конце длинной строки.
fc -l выводит последние 16 команд с номерами.
fc -l 50 80 покажет команды с 50 по 80.
fc 42 откроет команду номер 42 в редакторе.
fc -s old=new перезапустит последнюю команду, заменив подстроку. Например, fc -s foo=bar запустит предыдущую команду, но вместо foo подставит bar. Быстрее, чем руками лезть в историю.
Ещё один трюк, который реально экономит время — HISTIGNORE. Добавь в.bashrc:
HISTIGNORE="ls:ll:cd:pwd:clear:exit"
Теперь эти команды вообще не пишутся в историю. История перестаёт быть помойкой из тысяч ls и cd.
В zsh всё это работает похоже, но там ещё есть setopt HIST_IGNORE_ALL_DUPS — убирает дубликаты не только подряд идущие, а вообще все. И setopt SHARE_HISTORY — история синхронизируется между всеми открытыми терминалами в реальном времени, а не только при закрытии сессии.
Итого: fc, HISTTIMEFORMAT, HISTIGNORE и пара setopt в zsh — и твоя история перестаёт быть бесполезным мусором и начинает реально работать.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Начнём с простого. Если ты хочешь видеть дату и время каждой команды в истории, добавь в ~/.bashrc одну строку:
HISTTIMEFORMAT="%d.%m.%Y %H:%M:%S "
После этого history покажет не просто список команд, а когда именно ты их запускал. Удобно, когда надо выяснить, в какой момент ты всё сломал.
Теперь про fc. Это встроенная команда bash и zsh, которую игнорирует большинство людей, а зря.
fc без аргументов открывает последнюю команду в редакторе (vim, nano, что там у тебя в EDITOR). Исправил — сохранил — она сразу выполнилась. Не надо лезть в стрелку вверх и ковыряться в конце длинной строки.
fc -l выводит последние 16 команд с номерами.
fc -l 50 80 покажет команды с 50 по 80.
fc 42 откроет команду номер 42 в редакторе.
fc -s old=new перезапустит последнюю команду, заменив подстроку. Например, fc -s foo=bar запустит предыдущую команду, но вместо foo подставит bar. Быстрее, чем руками лезть в историю.
Ещё один трюк, который реально экономит время — HISTIGNORE. Добавь в.bashrc:
HISTIGNORE="ls:ll:cd:pwd:clear:exit"
Теперь эти команды вообще не пишутся в историю. История перестаёт быть помойкой из тысяч ls и cd.
В zsh всё это работает похоже, но там ещё есть setopt HIST_IGNORE_ALL_DUPS — убирает дубликаты не только подряд идущие, а вообще все. И setopt SHARE_HISTORY — история синхронизируется между всеми открытыми терминалами в реальном времени, а не только при закрытии сессии.
Итого: fc, HISTTIMEFORMAT, HISTIGNORE и пара setopt в zsh — и твоя история перестаёт быть бесполезным мусором и начинает реально работать.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Команда watch
Большинство людей не знают про неё вообще, хотя она встроена почти в каждый дистрибутив и реально экономит время.
watch запускает любую другую команду с заданным интервалом и показывает её вывод в терминале, обновляя его на месте. Никаких скриптов, никакого while true с sleep — просто одна строка.
Базовое использование:
watch df -h
Теперь у тебя мониторинг диска в реальном времени прямо в терминале. По умолчанию обновление каждые 2 секунды.
Хочешь раз в секунду:
watch -n 1 free -m
Смотришь за памятью и не дёргаешь руками Enter снова и снова.
Полезная опция -d (differences) — подсвечивает то, что изменилось с прошлого обновления. Очень удобно, когда следишь за логами, очередями, нагрузкой:
watch -d -n 2 cat /proc/loadavg
Можно комбинировать с grep, pipe и чем угодно, просто берёшь команду в кавычки:
watch -n 5 'ps aux | grep python | grep -v grep'
Отслеживаешь, живёт ли твой процесс, без лишних телодвижений.
Или классика — смотришь как растёт лог-файл:
watch -n 1 'wc -l /var/log/syslog'
Полезные флаги:
-n секунды — интервал обновления
-d — подсветка изменений
-t — убрать шапку с временем и названием команды (чисто для скриптов или красивого вывода)
-e — остановить при ненулевом коде возврата команды
Выйти из watch — просто Ctrl+C.
Кажется мелочью, но когда ты в третий раз за минуту жмёшь стрелку вверх и Enter чтобы посмотреть на тот же вывод — вспомни про watch. Одна команда и больше не надо.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Большинство людей не знают про неё вообще, хотя она встроена почти в каждый дистрибутив и реально экономит время.
watch запускает любую другую команду с заданным интервалом и показывает её вывод в терминале, обновляя его на месте. Никаких скриптов, никакого while true с sleep — просто одна строка.
Базовое использование:
watch df -h
Теперь у тебя мониторинг диска в реальном времени прямо в терминале. По умолчанию обновление каждые 2 секунды.
Хочешь раз в секунду:
watch -n 1 free -m
Смотришь за памятью и не дёргаешь руками Enter снова и снова.
Полезная опция -d (differences) — подсвечивает то, что изменилось с прошлого обновления. Очень удобно, когда следишь за логами, очередями, нагрузкой:
watch -d -n 2 cat /proc/loadavg
Можно комбинировать с grep, pipe и чем угодно, просто берёшь команду в кавычки:
watch -n 5 'ps aux | grep python | grep -v grep'
Отслеживаешь, живёт ли твой процесс, без лишних телодвижений.
Или классика — смотришь как растёт лог-файл:
watch -n 1 'wc -l /var/log/syslog'
Полезные флаги:
-n секунды — интервал обновления
-d — подсветка изменений
-t — убрать шапку с временем и названием команды (чисто для скриптов или красивого вывода)
-e — остановить при ненулевом коде возврата команды
Выйти из watch — просто Ctrl+C.
Кажется мелочью, но когда ты в третий раз за минуту жмёшь стрелку вверх и Enter чтобы посмотреть на тот же вывод — вспомни про watch. Одна команда и больше не надо.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Мало кто знает, что ядро Linux однажды чуть не убили юристы.
В начале 2000-х компания SCO Group заявила, что владеет правами на Unix и что код из их системы был незаконно скопирован в Linux. Они начали судиться с IBM, Novell и даже отдельными корпоративными пользователями Linux, требуя лицензионные выплаты за использование якобы украденного кода.
SCO оценила свои претензии в миллиарды долларов. Некоторые крупные компании реально начали нервничать и рассматривали переход обратно на проприетарные системы. Линус Торвальдс публично назвал всё это мусором и сказал примерно следующее: покажите хоть строчку украденного кода.
Показать не смогли.
Novell выиграла ключевой судебный спор, доказав, что именно они, а не SCO, владеют правами на Unix. Потом выяснилось, что за атакой на Linux стояли деньги Microsoft, которая вложилась в SCO через запутанные схемы. Не напрямую, но следы нашли.
SCO обанкротилась в 2007 году. Судебные тяжбы тянулись ещё годами, но Linux к тому моменту уже выиграл де-факто. Сегодня он крутится на большинстве серверов, смартфонов и суперкомпьютеров в мире.
Так что Linux убить пытались не только техническими аргументами, но и юридическими. Не вышло ни так ни эдак.
Подпишись на создателей: https://t.me/linuxexex
В начале 2000-х компания SCO Group заявила, что владеет правами на Unix и что код из их системы был незаконно скопирован в Linux. Они начали судиться с IBM, Novell и даже отдельными корпоративными пользователями Linux, требуя лицензионные выплаты за использование якобы украденного кода.
SCO оценила свои претензии в миллиарды долларов. Некоторые крупные компании реально начали нервничать и рассматривали переход обратно на проприетарные системы. Линус Торвальдс публично назвал всё это мусором и сказал примерно следующее: покажите хоть строчку украденного кода.
Показать не смогли.
Novell выиграла ключевой судебный спор, доказав, что именно они, а не SCO, владеют правами на Unix. Потом выяснилось, что за атакой на Linux стояли деньги Microsoft, которая вложилась в SCO через запутанные схемы. Не напрямую, но следы нашли.
SCO обанкротилась в 2007 году. Судебные тяжбы тянулись ещё годами, но Linux к тому моменту уже выиграл де-факто. Сегодня он крутится на большинстве серверов, смартфонов и суперкомпьютеров в мире.
Так что Linux убить пытались не только техническими аргументами, но и юридическими. Не вышло ни так ни эдак.
Подпишись на создателей: https://t.me/linuxexex
Марсоход NASA нашёл минерал, из которого растут рубины и сапфиры — прямо в марсианских породах
Perseverance провёл анализ горных пород и обнаружил корунд с хромом — это первое доказательство существования минерала, из которого образуются драгоценные камни, на Марсе. Никто этого не ожидал.
Корунд — это оксид алюминия. В чистом виде он бесцветный, но стоит добавить примеси — и получаются самоцветы. Хром даёт красный цвет, то есть рубин. Железо и титан — синий, то есть сапфир. На Земле такие камни формируются при высоких температурах и давлении в определённых геологических условиях.
То, что Perseverance нашёл хромсодержащий корунд в марсианских породах, говорит о том, что в прошлом на Марсе существовали похожие геологические процессы. Это не значит, что там лежат россыпи рубинов — речь идёт о минерале-предшественнике, о самом корунде, а не о готовых ювелирных камнях.
Находка сделана в кратере Езеро, где марсоход работает с 2021 года. Это первое подтверждение корунда на Марсе вообще — ни один из предыдущих аппаратов его не фиксировал.
linux.exe | @linuxexe_bot
Источник (r/science): https://www.reddit.com/r/science/comments/1vnbw2e/nasa_rover_unexpectedly_finds_ruby_and/
Подпишись на создателей: https://t.me/linuxexex
Perseverance провёл анализ горных пород и обнаружил корунд с хромом — это первое доказательство существования минерала, из которого образуются драгоценные камни, на Марсе. Никто этого не ожидал.
Корунд — это оксид алюминия. В чистом виде он бесцветный, но стоит добавить примеси — и получаются самоцветы. Хром даёт красный цвет, то есть рубин. Железо и титан — синий, то есть сапфир. На Земле такие камни формируются при высоких температурах и давлении в определённых геологических условиях.
То, что Perseverance нашёл хромсодержащий корунд в марсианских породах, говорит о том, что в прошлом на Марсе существовали похожие геологические процессы. Это не значит, что там лежат россыпи рубинов — речь идёт о минерале-предшественнике, о самом корунде, а не о готовых ювелирных камнях.
Находка сделана в кратере Езеро, где марсоход работает с 2021 года. Это первое подтверждение корунда на Марсе вообще — ни один из предыдущих аппаратов его не фиксировал.
linux.exe | @linuxexe_bot
Источник (r/science): https://www.reddit.com/r/science/comments/1vnbw2e/nasa_rover_unexpectedly_finds_ruby_and/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the science community on Reddit: NASA rover unexpectedly finds ruby- and sapphire-forming mineral in Martian rocks. Analysis…
Explore this post and more from the science community
Факт дня: как Линус Торвальдс случайно назвал Linux "Linux"
В 1991 году Линус хотел назвать свою операционную систему Freax. Серьезно. Freax. От слов free, freak и unix. Он даже создал файл с таким именем на FTP-сервере, куда загружал ранние версии ядра.
Но у Ари Лемке, администратора того самого FTP-сервера Хельсинкского университета, было другое мнение. Он без спроса переименовал директорию из "freax" в "linux" — потому что это звучало разумнее и уже было именем домашней директории Торвальдса на сервере.
Линус поворчал, но оставил. Так и прижилось.
Представьте альтернативную вселенную: Freax kernel, FreaxMint, Freax Foundation, "я использую Freax, кстати". Звучит как название панк-группы или дешевого энергетика.
Хорошо, что Ари тогда проявил самодеятельность. Бюрократы иногда полезны.
Подпишись на создателей: https://t.me/linuxexex
В 1991 году Линус хотел назвать свою операционную систему Freax. Серьезно. Freax. От слов free, freak и unix. Он даже создал файл с таким именем на FTP-сервере, куда загружал ранние версии ядра.
Но у Ари Лемке, администратора того самого FTP-сервера Хельсинкского университета, было другое мнение. Он без спроса переименовал директорию из "freax" в "linux" — потому что это звучало разумнее и уже было именем домашней директории Торвальдса на сервере.
Линус поворчал, но оставил. Так и прижилось.
Представьте альтернативную вселенную: Freax kernel, FreaxMint, Freax Foundation, "я использую Freax, кстати". Звучит как название панк-группы или дешевого энергетика.
Хорошо, что Ари тогда проявил самодеятельность. Бюрократы иногда полезны.
Подпишись на создателей: https://t.me/linuxexex