linux.exex [GFYB]
158 subscribers
746 photos
87 videos
9 files
526 links
GFYB - go fuck yourself bitch. This Is team GFYB. goida
Download Telegram
Как Linux понимает, что вы нажали клавишу

Разберём подсистему ввода, потому что она хорошо показывает общий принцип работы ядра.

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

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

Дальше в дело вступает драйвер. В Linux за это отвечает drivers/input в дереве исходников. Драйвер переводит скан-код в кейкод, универсальный идентификатор события. Система evdev создаёт из этого структуру input_event: тип события, код, значение и временную метку.

Эта структура кладётся в буфер устройства. Устройство выглядит как файл, обычно это /dev/input/eventN. Любое приложение может открыть этот файл и читать поток событий. Именно так работают X11, Wayland и консольный getty.

Параллельно существует слой ввода для консоли. Там скан-коды переводятся через таблицу раскладки в символы. Таблицы лежат в /usr/share/kbd/keymaps и загружаются утилитой loadkeys. Вот почему переключение раскладки в консоли и в X11 настраивается отдельно.

Весь путь выглядит так. Железо отправляет прерывание. Ядро получает скан-код. Драйвер превращает его в событие. Событие попадает в буфер устройства. Приложение читает из /dev/input/eventN. Приложение решает, что с этим делать.

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

Можно сделать финт и самому подписаться на события. Вот команда, которую запускают с правами root:

cat /dev/input/event0 | xxd

Увидите поток шестнадцатеричных байт. Каждое нажатие и отпускание клавиши, это отдельное событие в реальном времени. Без всяких библиотек, без X11, просто файл и данные.

Такая архитектура позволяет, например, создавать виртуальные устройства ввода через /dev/uinput. Именно на этом работают эмуляторы геймпадов, утилиты переназначения клавиш вроде keyd и xremap, а также системы автоматизации тестирования интерфейсов.

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

Подпишись на создателей: https://t.me/linuxexex
CTRL+R все знают. А вот это — вряд ли.

В bash и zsh есть встроенная замена подстрок прямо в переменных, без sed, без awk, без лишних процессов.

Синтаксис простой:

${переменная/что_найти/на_что_заменить}

Одиночный слеш — заменяет первое вхождение. Двойной слеш — все вхождения сразу.

Пример. Есть путь:

path="/home/user/projects/user_data"

Хочешь заменить первый "user" на "admin":

echo ${path/user/admin}
Выведет: /home/admin/projects/user_data

Хочешь заменить все вхождения:

echo ${path//user/admin}
Выведет: /home/admin/projects/admin_data

Никакого sed, никакого форка процесса. Всё делает сам шелл, в памяти, моментально.

Это работает и с другими операциями. Например, приведение строки к нижнему регистру — в bash 4+ и zsh:

str="Hello World"
echo ${str,,}
Выведет: hello world

К верхнему регистру:

echo ${str^^}
Выведет: HELLO WORLD

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

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

Ещё одна штука из той же оперы — удаление части строки по паттерну. Символ # удаляет совпадение с начала, % — с конца.

file="backup_2024_01_15.tar.gz"

Убрать расширение:

echo ${file%.tar.gz}
Выведет: backup_2024_01_15

Убрать префикс:

echo ${file#backup_}
Выведет: 2024_01_15.tar.gz

Двойные ## и %% — жадный режим, совпадение максимально длинное.

Всё это POSIX-совместимо в части базовой замены и обрезки. Операторы,, и ^^ — только bash 4+ и zsh.

Проверяй версию bash командой bash --version. На macOS до сих пор стоит bash 3.2 из-за лицензии — там регистровые операторы не работают. Либо ставь bash через homebrew, либо используй zsh, который там по умолчанию.

Канал linux.exe — @linuxexe

Подпишись на создателей: https://t.me/linuxexex
Когда-нибудь мы получим сверхсветовые скорости и сможем наблюдать наше прошлое как со спутника

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

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

Свет от прошлого уже летит где-то в космосе. Нам просто нужно его обогнать.

Источник (4chan /sci/): https://boards.4chan.org/sci/thread/17031008

Подпишись на создателей: https://t.me/linuxexex
Инструмент дня: ripgrep

Если ты до сих пор ищешь по проекту через grep -R, попробуй rg.

Пример:

rg "TODO|FIXME"

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

Полезные варианты:
rg -n "pattern" — с номерами строк
rg --files — список файлов проекта
rg -t py "async def" — искать только в Python-файлах

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

Подпишись на создателей: 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
со старого ноутбука
и кстати откуда 12 просмотров
Intel Pentium N3540 и Nvidia GeForce 830M
@linuxexexbot притча дауна
Притча о топоре, совести и плохой арифметике

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

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

— Скажи мне, друг, — спросил он, — чем отличается великая идея от таракана в голове, если оба бегают ночью и мешают спать?

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

— Я хотел стать выше обстоятельств, а оказался ниже собственной отговорки.

— Значит, — сказал Сократ, — ты перепутал мысль с индульгенцией. Мысль должна освещать комнату, а не подсовывать тебе инструмент и шептать: «ну давай, докажи, что ты особенный».

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

Сократ поднял палец:

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

С тех пор он боялся не закона, а секунды тишины, где всё наконец становится понятно.
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
Яндекс пердоводчик ты ахуел?!!!
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
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
/evolution
Ubuntu vs Debian на сервере

Если нужен сервер «поставил и забыл», 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
Единственный тред по СИ clang

Тред для всех кто хочет погрузиться в низкоуровневое и системное программирование дедушки си

Обсуждаем чужие гитхабы, коды, программирование микроконтроллеров.

сам учился на степике, всем советую прочитать книгу Брайана Кернигана и Денниса Ритчи «Язык программирования Си»

ЗАДАВАЙТЕ ВОПРОСЫ И ПОЛУЧАЙТЕ ОТВЕТЫ!

Источник (2ch /pr/): https://2ch.org/pr/res/3619616.html

Подпишись на создателей: 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