This is the perfect brake system.

Это идеальная тормозная система.

Зачем вообще существуют ободные тормоза или механические диски, если есть вот это?

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

Подпишись на создателей: https://t.me/linuxexex

tee -- одна из тех команд, мимо которых все проходят, не останавливаясь. А зря.

Если коротко: tee читает stdin и одновременно пишет и в stdout, и в файл. Звучит как мелочь, но на практике это развязывает руки.

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

./build.sh | tee build.log

Видишь вывод в реальном времени и получаешь файл. Ничего не теряется.

Флаг -a дописывает в файл, не затирая старое:

./deploy.sh | tee -a deploy.log

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

Теперь момент, который знают не все. tee умеет писать сразу в несколько файлов:

echo "привет" | tee file1.txt file2.txt file3.txt

Один прогон -- три копии. Без всяких cp после.

Самая сочная история -- sudo и перенаправление. Вот это не работает, как ожидаешь:

sudo echo "net.ipv4.ip_forward=1" > /etc/sysctl.conf

Потому что редирект обрабатывает текущий шелл, а не sudo. Файл не запишется, получишь Permission denied. Правильный способ:

echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.conf

Или с -a, если не хочешь стирать содержимое:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf

tee работает под sudo, у него есть права, и всё проходит как надо. Этот трюк реально экономит нервы, когда настраиваешь систему.

Ещё одна связка -- с процессным замещением. Можно разветвить поток сразу в несколько команд:

cat access.log | tee >(grep ERROR > errors.log) >(grep WARN > warns.log) > /dev/null

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

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

linux.exe

Подпишись на создателей: https://t.me/linuxexex

Факт дня: Linux чуть не получил другое название

Когда Линус Торвальдс в 1991 году заливал ядро на сервер FTP Хельсинкского университета, он хотел назвать его Freax. Это был его собственный каламбур от слов free, freak и Unix. Линус даже создал директорию с таким именем на своём компьютере и держался за это название несколько месяцев.

Но тут вмешался Ари Лемке — администратор того самого FTP-сервера, куда Торвальдс загружал ядро. Ему название Freax не понравилось. Он просто взял и создал директорию pub/OS/Linux, использовав рабочее прозвище из переписки с Линусом. Линус поворчал, потом смирился.

Так решение одного системного администратора в 1991 году определило название операционной системы, которая сегодня крутит большую часть интернета, все Android-устройства, облака Amazon, Google и Microsoft, биржи, ядерные реакторы и марсоходы NASA.

Представьте альтернативную вселенную: серверы на Freax, фанаты Freax, дистрибутивы типа Ubuntu Freax Edition. Звучит как название металл-группы из Финляндии, а не фундамента цифровой цивилизации.

Ари Лемке об этом особо не распространялся годами. Линус в итоге признал, что Linux звучит лучше. Ари был прав. Вот так один тихий sysadmin с правами на сервер изменил историю IT, просто создав папку с удобным именем.

linux.exe

Подпишись на создателей: https://t.me/linuxexex

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

Речь про history search через Ctrl+R. Большинство знают, что это обратный поиск по истории команд. Но мало кто знает, как выжать из него максимум.

По умолчанию bash хранит 500-1000 строк истории. Это ничто. Открываешь.bashrc и добавляешь:

HISTSIZE=100000
HISTFILESIZE=200000
HISTCONTROL=ignoredups:erasedups
shopt -s histappend

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

Ещё один момент, который ломает людей. Если у тебя открыто пять вкладок терминала, история из каждой пишется отдельно и они перетирают друг друга при закрытии. Чтобы все сессии писали в один файл в реальном времени, добавляй:

PROMPT_COMMAND="history -a; history -c; history -r"

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

Бонус для тех, кто хочет совсем жирно. Поставь fzf — это нечёткий поиск поверх всего. После установки Ctrl+R превращается в интерактивный поиск с фильтрацией. Пишешь кусок команды как помнишь, хоть с ошибкой, и fzf находит похожее. Это уже другой уровень.

На zsh всё это тоже работает, там ещё есть встроенный плагин zsh-autosuggestions, который серым цветом показывает предсказание следующей команды прямо в строке ввода. Стрелка вправо — принял предложение.

Итого: правильно настроенная история плюс fzf = ты перестаёшь набирать длинные команды руками. Просто вспоминаешь кусок, ищешь, запускаешь. Для тех, кто сидит в терминале по несколько часов в день, это десятки минут в неделю.

Подпишись на создателей: https://t.me/linuxexex

What a real LTS looks like: Kubuntu 26.04

Источник (r/linux): https://www.reddit.com/r/linux/comments/1vnovqd/what_a_real_lts_looks_like_kubuntu_2604/

Подпишись на создателей: https://t.me/linuxexex

Как Linux не теряет ваши файлы. VFS изнутри, по-человечески.

Когда ты пишешь в терминале cat /etc/passwd, твоя программа не знает, откуда этот файл. Он на ext4? На btrfs? Вообще на сетевом NFS-томе? Плевать. Программе это неважно, и вот почему.

В ядре Linux живёт прослойка под названием VFS — Virtual File System. Это не файловая система в привычном смысле, а абстракция над всеми файловыми системами разом. Этакий переводчик.

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

Ядро описывает четыре базовых объекта: суперблок, inode, запись в директории и объект открытого файла. Каждая реальная файловая система — ext4, xfs, tmpfs, proc, что угодно — регистрируется в VFS и говорит: вот мои функции для работы с этими объектами. Реализуй read как хочешь, главное чтобы сигнатура совпадала.

Когда процесс вызывает open(), ядро смотрит на путь, понимает, на каком устройстве и файловой системе лежит нужный файл, и передаёт управление нужному драйверу. Тот возвращает объект файла с указателями на свои функции. Дальше твой read() уходит в эту конкретную реализацию, а ты об этом даже не думаешь.

Почему это круто

Из-за VFS в Linux файлом является почти всё. /proc/cpuinfo — не файл на диске, это кусок памяти, который ядро отдаёт тебе как будто бы читает с диска. /dev/null — дыра в никуда, оформленная как файл. Сокет можно читать через стандартные системные вызовы. Пайп между процессами — тоже файл с точки зрения API.

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

Кэш

VFS не просто маршрутизирует вызовы. Он держит page cache — кэш страниц в оперативке. Когда ты читаешь файл, данные оседают в RAM. Следующий read того же файла может вообще не лезть на диск. Поэтому после того как ты скомпилировал проект первый раз, второй идёт быстрее — исходники уже в кэше.

Туда же относится dentry cache — кэш путей. Ядро запоминает соответствие между строками путей и inode-ами, чтобы не разбирать /usr/lib/python3/dist-packages/... каждый раз заново.

Практический вывод

Если у тебя тормозит дисковый ввод-вывод, смотри на page cache. Команда free покажет, сколько памяти занято под кэш. Это не утечка, это нормально, ядро само отдаст память если понадобится. Команда sync сбросит грязные страницы на диск. А echo 3 > /proc/sys/vm/drop_caches очистит кэш принудительно — иногда нужно для бенчмарков, в проде лучше не трогать без причины.

VFS — это одна из тех штук, которая работает незаметно и именно поэтому работает хорошо.

linux.exe

Подпишись на создателей: https://t.me/linuxexex

Каждый первокурсник думает, что команда rm удаляет файлы навсегда. На самом деле нихуя подобного. Обычное удаление просто стирает указатель на файл в файловой системе, оставляя сами данные на диске невредимыми. Любой мамкин хакер с утилитой вроде testdisk или photorec восстановит твои секретные архивы, приватные ключи, логины-пароли или порнуху за пару минут.

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

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

Обычный вызов выглядит так:
shred -u -v -n 5 secret_file.txt

Давай разберем ключи, чтобы ты понимал, что происходит.
Ключ -u приказывает утилите не просто затереть содержимое, но и удалить сам файл после перезаписи. Без него на диске останется пустой затертый файл.
Ключ -v включает подробный вывод, показывая прогресс перезаписи, чтобы ты не сидел и не гадал, завис твой терминал или процесс идет.
Ключ -n задает количество раундов перезаписи. По умолчанию их три, но в примере мы указали пять. Пять раз поверх твоих секретов запишется абсолютная случайная каша.

Если ты параноик высшего уровня, добавь ключ -z. Он выполняет финальный проход нулями, чтобы скрыть сам факт того, что файл был уничтожен перезаписью мусором. Команда примет вид:
shred -u -v -n 3 -z secret_file.txt

Также shred отлично работает с целыми разделами. Если тебе нужно полностью очистить флешку или жесткий диск перед продажей на авито, чтобы покупатель не копался в твоей личной жизни, пиши:
shred -v -n 1 /dev/sdb

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

Стоит помнить, что на современных SSD с технологией wear leveling shred может работать неидеально из-за особенностей контроллеров, которые распределяют запись по ячейкам, но для классических HDD, флешек и отдельных файлов в обычных файловых системах это абсолютный мастхэв.

Юзайте правильные инструменты, предохраняйтесь и не давайте повода посторонним совать нос в ваши диски.

Подпишись на создателей: https://t.me/linuxexex

Ежедневное убывание Украины. Минус Першомарьевка и Кудиевка

ВСУ продолжают утрачивать населенные пункты по всем направлениям СВО.В этот раз от Украины отминусовалось сразу 2 населенных пункта-Першомарьевка и Кудиевка.

Першомарьевка-расположена в Донецкой Народной Республике.Перешла под контроль ВС РФ благодаря действиям группировки войск ЮГ. Кудиевка-Харьковская область.Освобождена силами группировки войск Север.

https://www.vesti.ru/ns/minoborony-vs-rf-osvobodili-kudievku-v-kharkovskoj-oblasti https://www.vesti.ru/ns/minoborony-vs-rf-osvobodili-kudievku-v-kharkovskoj-oblasti

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

Подпишись на создателей: https://t.me/linuxexex

tldr: jq — это как grep, но для JSON. И это меняет жизнь.

Если ты хоть раз работал с API, логами или конфигами в терминале, ты знаешь эту боль. Curl отдаёт тебе здоровенный JSON-ответ одной склеенной строкой, и ты либо копируешь это в браузер, либо страдаешь.

jq решает проблему раз и навсегда.

Ставится просто:

apt install jq
brew install jq

Дальше смотри, что можно делать.

Красивый вывод любого JSON:

curl -s https://api.github.com/users/torvalds | jq.

Всё. Цвета, отступы, читаемость. Уже за это стоит поставить.

Но это только начало. Допустим, тебе нужно только имя и количество репозиториев:

curl -s https://api.github.com/users/torvalds | jq '{name:.name, repos:.public_repos}'

Или тебе прилетает массив объектов, и ты хочешь вытащить только одно поле из каждого:

cat users.json | jq '.[].email'

Или отфильтровать только тех юзеров, у кого больше 10 репозиториев:

cat users.json | jq '[.[] | select(.public_repos > 10)]'

И всё это прямо в терминале, без Python-скриптов, без постмана, без открытия браузера.

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

NAME="torvalds"
jq --arg n "$NAME" '.[] | select(.login == $n)' users.json

Это удобно, когда пишешь скрипты и не хочешь городить конкатенацию строк.

Ещё jq умеет:
- преобразовывать JSON в CSV через @csv
- кодировать и декодировать base64 через @base64
- работать с несколькими файлами сразу
- делать рекурсивный обход через..

Например, вытащить вообще все строковые значения из вложенного JSON:

jq '[.. | strings]' deep.json

Для тех, кто пишет CI/CD пайплайны, парсит ответы от AWS CLI, Kubernetes или любого REST API — jq это не опция, это базовый навык. Как grep или sed.

Если хочешь потренироваться без установки, есть jqplay.org — онлайн-площадка, куда кидаешь JSON и пишешь запросы прямо в браузере.

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

Подпишись на создателей: https://t.me/linuxexex

ripgrep. Просто запомни это слово.

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

ripgrep это инструмент поиска по содержимому файлов. Написан на Rust, работает быстрее чем ты успеваешь моргнуть, умеет в регулярки, уважает.gitignore из коробки и не лезет в папки которые тебе не нужны.

Стандартный grep на большом проекте — это страдание. ripgrep на том же проекте — это момент когда ты понимаешь, что время это ресурс и ты его раньше просто сжигал.

Поставить элементарно:

На Ubuntu и Debian:
apt install ripgrep

На Arch:
pacman -S ripgrep

На Mac через Homebrew:
brew install ripgrep

После установки команда называется rg. Не ripgrep, не rgrep, просто rg.

Базовое использование:
rg "название_функции"

Ищет рекурсивно с текущей директории. Без флагов, без боли.

Хочешь искать только в определённых файлах:
rg "паттерн" -t py

Только питоновские файлы. Аналогично работает для js, ts, go, rs и всего остального.

Хочешь видеть контекст вокруг совпадения, например три строки до и после:
rg "паттерн" -C 3

Хочешь найти файлы где вхождение есть, но не смотреть на содержимое:
rg -l "паттерн"

Хочешь наоборот — файлы где вхождения нет:
rg -L "паттерн"

Хочешь поиск без учёта регистра:
rg -i "паттерн"

И всё это работает на огромных репозиториях за доли секунды. Без прогрева, без индексации, без танцев.

Отдельный кайф в том, что ripgrep по умолчанию пропускает бинарники, скрытые папки типа.git, всё что в.gitignore и.ignore. То есть он сразу думает как разработчик, а не как утилита из семидесятых.

Ещё он умеет в многострочный поиск с флагом -U, умеет заменять через --replace хотя это уже не запись в файл а вывод, умеет pcre2 регулярки если собрать с нужным флагом.

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

linux.exe

Подпишись на создателей: https://t.me/linuxexex

Как работает планировщик задач в Linux — без занудства

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

В Linux сейчас используется CFS — Completely Fair Scheduler. Название говорит само за себя: он пытается дать каждому процессу честную долю времени CPU. Но как именно?

CFS не использует классические временные кванты в духе "тебе 10 миллисекунд, следующий". Вместо этого он считает виртуальное время — vruntime. Это счётчик, который показывает, сколько процессор-времени процесс уже получил. Кто отстал — получает ресурс следующим. Всё честно, никаких любимчиков.

Процессы хранятся в красно-чёрном дереве. Это структура данных, где самый левый узел — процесс с наименьшим vruntime, то есть тот, кто дольше всех ждал. Планировщик просто берёт крайний левый узел и запускает его. Вставка и поиск — O(log n). Быстро даже при сотнях процессов.

Есть нюанс с приоритетами. У каждого процесса есть nice-значение от -20 до 19. Чем ниже число — тем важнее процесс. CFS учитывает это: vruntime у важных процессов растёт медленнее, поэтому они чаще оказываются в начале очереди и получают больше времени. Никакой магии, просто математика.

Отдельная история — классы планировщика. CFS это не единственный вариант. Для реального времени есть SCHED_FIFO и SCHED_RR — там процессы с RT-приоритетом вытесняют всё остальное без разговоров. Для обычных задач — SCHED_OTHER, это и есть CFS. Есть ещё SCHED_IDLE для задач, которым вообще не важно, когда их запустят.

Многоядерность добавляет сложности. У каждого ядра своя очередь задач. Планировщик периодически проверяет, не перегружено ли одно ядро, пока другие простаивают, и перекидывает процессы — это называется load balancing. Делается это не постоянно, а с умом, чтобы не тратить время на само перебрасывание.

Ещё один момент — wakeup latency. Когда процесс спал и получил сигнал (например, пришли данные из сети), его надо запустить быстро. CFS при пробуждении немного занижает vruntime процессу, чтобы он попал в начало очереди и не ждал своей очереди слишком долго.

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

Если хочешь сам посмотреть, что происходит — запусти chrt -p PID чтобы увидеть политику планирования конкретного процесса, или покопайся в /proc/schedstat. Там цифры, от которых у нормального человека едет крыша, но зато честные.

Подпишись на создателей: https://t.me/linuxexex

Korea relaunches hunt for assets accumulated by pro-Japanese collaborators

Источник (r/worldnews): https://www.reddit.com/r/worldnews/comments/1vq2zhb/korea_relaunches_hunt_for_assets_accumulated_by/

Подпишись на создателей: https://t.me/linuxexex

Как же мой бот пусечка тащит канал

Совет по безопасности для тех, кто сидит на Linux и думает, что уже в домике.

Самая частая проблема не в том, что система дырявая, а в том, что ты расслабился. Вот несколько вещей, которые реально стоит сделать прямо сейчас, если ещё не сделал.

Первое. Не работай под рутом. Вообще никогда. Даже если "надо быстро". Именно эта привычка убивает сервера быстрее всего. Для временного повышения привилегий есть sudo, и он существует не для красоты.

Второе. SSH без пароля это не удобство, это катастрофа в ожидании. Отключи аутентификацию по паролю в /etc/ssh/sshd_config, оставь только ключи. Строчка PasswordAuthentication no спасёт тебя от тысяч брутфорс-атак в сутки, которые уже идут прямо сейчас на твой сервер.

Третье. UFW или iptables. Настрой и включи. Если ты открыл наружу все порты подряд, ты не сервер поднял, ты мишень выставил. Закрой всё лишнее, оставь только то, что реально нужно.

Четвёртое. Проверяй, кто ломится к тебе. Команда lastb показывает неудачные попытки входа. Посмотри и скажи мне, что ты не удивишься количеству записей. Fail2ban ставится за пять минут и автоматически банит IP после нескольких неудачных попыток.

Пятое. Обновления. Да, скучно, да, слышал сто раз. Но unattended-upgrades на Debian-based системах или таймер dnf-automatic на Fedora-based закрывают свежие CVE без твоего участия. Один раз настроил, забыл, спишь спокойно.

Шестое. Проверь setuid-биты. Найди все файлы с ними командой:

find / -perm -4000 -type f 2>/dev/null

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

Седьмое. Логи. /var/log/auth.log или /var/log/secure в зависимости от дистрибутива. Хотя бы иногда смотри, что там происходит. Либо поставь logwatch, он будет сам слать тебе дайджест на почту.

Безопасность это не одно действие, а привычка. Linux даёт тебе все инструменты, но не держит тебя за руку. Либо ты настраиваешь систему как взрослый, либо однажды обнаруживаешь майнер, который живёт у тебя уже три месяца.

linux.exe

Подпишись на создателей: https://t.me/linuxexex

jq — это как grep, только для JSON. Если ты когда-нибудь получал здоровенный JSON-ответ от API и пытался в нём что-то найти глазами, то знаешь, какое это унылое занятие. jq решает эту проблему раз и навсегда.

Что это такое: консольная утилита для парсинга, фильтрации и трансформации JSON прямо в терминале. Ничего лишнего, работает быстро, ставится одной командой.

Установка:

apt install jq
brew install jq

Базовый пример. Допустим, curl вернул тебе кашу из JSON. Вместо того чтобы пялиться в одну строку:

curl -s https://api.github.com/users/torvalds | jq.

Всё. Красиво отформатировано, с отступами, подсвечено.

Хочешь только конкретное поле:

curl -s https://api.github.com/users/torvalds | jq.public_repos

Хочешь пройтись по массиву и вытащить только имена:

echo '[{"name":"bash"},{"name":"zsh"}]' | jq '.[].name'

Хочешь отфильтровать только те объекты, где значение больше нуля:

cat data.json | jq '.[] | select(.count > 0)'

Хочешь собрать новый объект из полей старого:

cat users.json | jq '.[] | {id:.id, login:.login}'

Это реально меняет подход к работе с API. Вместо того чтобы писать скрипт на Python ради одного запроса, ты делаешь всё прямо в терминале за секунды. Логи, ответы сервисов, конфиги, CI-пайплайны — jq везде.

Есть и продвинутые штуки: функции, reduce, переменные, условия, форматирование вывода под csv или другие форматы. Документация на jqlang.github.io, там и playground есть — можно гонять запросы прямо в браузере без установки.

Если ты работаешь с любым REST API и ещё не знаешь jq, ты буквально тратишь своё время впустую. Поставь, попробуй один раз — и назад дороги нет.

linux.exe

Подпишись на создателей: https://t.me/linuxexex

Яблоко» нашло у парламентских партий более миллиарда рублей пожертвований от доноров с зарубежными с

Все пять парламентских партий в период с 2021 по 2025 год получили не менее 1 миллиарда 153 миллионов рублей пожертвований от доноров «со следами зарубежного финансирования», выяснил Центр антикоррупционной политики «Яблока».

Одним из оснований снятия «Яблока» с выборов стали 16900 рублей пожертвований «от неких граждан, якобы получавших средства из-за рубежа». «Яблоко» изучило сводные финансовые отчеты парламентских партий в ЦИК России за 2021–2025 годы и применило к ним «такой же критерий».

Из 1,15 миллиарда пожертвований, обнаруженных «Яблоком», 811,75 миллионов пришлись на «Единую Россию». Зарубежные связи спонсоров ЕР охватывают в том числе 22 страны из списка «недружественных» государств.

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

Это сумма пожертвований от компаний, у которых обнаружены содержательные зарубежные связи. Мы не утверждаем, что перечисленные партии формально нарушили закон. Именно в этом и состоит смысл проверки: обычная внешнеэкономическая деятельность не должна автоматически превращать законное пожертвование в «иностранное финансирование». Но все парламентские партии явно нарушают критерии, заданные решением Верховного суда от 10 августа.

По итогу этого расследования «Яблоко» потребовало либо отменить решение Верховного суда о снятии партии, либо «последовательно применить» созданный государством критерий ко всем остальным участникам выборов.
https://meduza.io/news/2026/08/16/togda-snimayte-vseh-yabloko-nashlo-u-parlamentskih-partiy-bolee-milliarda-rubley-pozhertvovaniy-ot-donorov-s-zarubezhnymi-svyazyami https://meduza.io/news/2026/08/16/togda-snimayte-vseh-yabloko-nashlo-u-parlamentskih-partiy-bolee-milliarda-rubley-pozhertvovaniy-ot-donorov-s-zarubezhnymi-svyazyami

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

Подпишись на создателей: https://t.me/linuxexex

linux.exe | сравниваем дистрибутивы на живом примере

Возьмём конкретную задачу: поднять свежий nginx, настроить systemd-юнит и не сойти с ума. Смотрим, как это выглядит на четырёх популярных дистрибутивах.

Ubuntu 24.04 LTS

Ставится из коробки одной командой, apt не спорит. Версия nginx в репозитории актуальная, потому что Ubuntu LTS в последнее время перестала стесняться свежих пакетов. Systemd работает как положено, journalctl читается без боли. Минус — snap норовит везде пролезть, и если вы случайно установили nginx через snap, то конфиги лежат в каком-то унитазе типа /var/snap/nginx/current и вы потратите полчаса, пока не догадаетесь посмотреть туда. В целом: самый низкий порог входа, хорошо для тех, кто хочет просто работать.

Debian 12 Bookworm

Всё то же самое, но версия nginx может быть чуть старше — Debian любит стабильность больше, чем актуальность. Зато никакого snap, никакого мусора, никаких сюрпризов. Systemd-юнит создаётся и включается одинаково с Ubuntu. Если нужна свежая версия nginx — подключаешь официальный репозиторий nginx.org и живёшь спокойно. Вывод: Ubuntu без snap и с чуть меньшим количеством маркетинга. Идеально для серверов.

Arch Linux

Тут nginx всегда свежий, pacman ставит без вопросов. Systemd тоже свежий, иногда даже слишком — бывает, что очередное обновление systemd что-нибудь ломает, и ты идёшь на Arch Wiki читать, что на этот раз случилось. Зато всё под контролем: никто не решает за тебя, что тебе нужен snap или flatpak. Конфигурируешь сам, ломаешь сам, чинишь сам. Для тех, кто любит разбираться, а не просто щёлкать. На сервер в продакшн тащить Arch — это либо смелость, либо глупость, зависит от ситуации.

Fedora 40

rpm и dnf вместо apt, привыкаешь за день. Nginx актуальный. Systemd тут вообще дома — Red Hat его и разрабатывает, так что интеграция на уровне. SELinux включён по умолчанию, и вот тут начинается веселье: nginx поднялся, конфиг правильный, сокет слушает, но браузер говорит отказано в соединении. Причина — SELinux не разрешил nginx слушать нестандартный порт. Чинится одной командой semanage, но если не знаешь про SELinux — будешь смотреть в потолок минут сорок. Зато безопасность реальная, не декоративная.

Итог по задаче

Если просто надо быстро — Ubuntu или Debian. Если важна безопасность и корпоративная среда — Fedora, но выучи базу SELinux. Если хочешь всё контролировать и не против иногда чинить — Arch. Для прода на железе или VPS — Debian выигрывает по соотношению стабильность/предсказуемость/отсутствие лишнего шума.

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

linux.exe | @linuxexe_bot

Подпишись на создателей: https://t.me/linuxexex

Как Linux не теряет твои файлы: виртуальная файловая система

Ты когда-нибудь задумывался, почему на Linux можно монтировать ext4, btrfs, ntfs, tmpfs и ещё десяток форматов, и при этом работать с ними одинаковыми командами? ls, cat, cp — всё одно и то же, независимо от того, что там под капотом. Это не магия, это VFS — Virtual File System.

Суть простая. VFS — это прослойка в ядре между твоими программами и реальными файловыми системами. Что-то вроде единого переводчика. Ты говоришь "открой файл", ядро принимает запрос через VFS, а уже VFS разбирается, какая файловая система сидит на конкретном разделе, и вызывает её конкретный код.

Как это работает внутри

В ядре есть несколько ключевых объектов. Inode — это описание файла: права, владелец, размер, указатели на блоки данных. Не имя, именно описание. Имя живёт отдельно, в dentry — это запись в директории, которая связывает имя с inode. File — это уже объект открытого файла, который создаётся когда процесс делает open(). Superblock — описание смонтированной файловой системы в целом.

Когда ты пишешь open("/home/user/notes.txt", O_RDONLY), ядро идёт по пути: резолвит путь через dentry-кэш, находит inode файла, создаёт объект file, возвращает тебе файловый дескриптор — просто число. Дальше все операции идут через этот дескриптор.

Каждая реальная файловая система регистрирует в VFS набор функций — операции над inode, операции над файлом, операции над суперблоком. Это обычные указатели на функции в структурах. Ext4 регистрирует свои, btrfs — свои, procfs — свои. VFS просто вызывает нужный указатель, не зная деталей.

Зачем это вообще нужно

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

Именно поэтому procfs монтируется в /proc и выглядит как директория с файлами, хотя там нет никаких реальных данных на диске. Читаешь /proc/cpuinfo — ядро на лету генерирует текст и отдаёт тебе. С точки зрения твоей программы это просто файл.

Именно поэтому tmpfs живёт в памяти, но ты работаешь с ним через те же системные вызовы. Именно поэтому sysfs, devtmpfs, cgroupfs и прочие псевдофайловые системы выглядят единообразно.

Дентри-кэш и иноды в памяти

Ядро агрессивно кэширует dentry и inode в памяти. Это dcache и icache. Они нужны чтобы не лезть на диск каждый раз при резолве пути. Если ты много работаешь с файлами, эти кэши растут. Когда памяти не хватает, ядро их вытесняет. Можно посмотреть через /proc/slabinfo или инструментом slabtop.

Итого

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

Это один из примеров того, как хорошая абстракция решает проблему раз и навсегда.

linux.exe

Подпишись на создателей: https://t.me/linuxexex

Апелляционный суд США заблокировал проект бального зала Трампа за 400 миллионов долларов на месте снесённого крыла Белого дома

Вашингтон, 7 августа (Reuters). Федеральный апелляционный суд США в пятницу постановил остановить строительство бального зала за 400 миллионов долларов на месте снесённого Восточного крыла Белого дома, нанеся республиканскому лидеру серьёзный удар в деле, проверяющем пределы президентских полномочий.

"Каждый президент является временным жильцом, а не владельцем Белого дома" и не может кардинально перестраивать его без одобрения Конгресса — так написал Апелляционный суд округа Колумбия в решении, принятом большинством голосов 2 против 1.

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

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

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

Трамп, который всё настойчивее называет проект бального зала военной необходимостью, в пятницу написал в Truth Social, что речь идёт о "военном центре", и сообщил, что администрация подаст апелляцию в Верховный суд. Решение он назвал "чудовищным" и политически мотивированным, заявив, что оно оставляет его, других сотрудников Белого дома и посетителей незащищёнными от нападений.

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

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

Подпишись на создателей: https://t.me/linuxexex

tldr: jq

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

Что это вообще такое. jq — это как sed и awk, только для JSON. Легковесный процессор, который умеет фильтровать, преобразовывать и форматировать JSON прямо в терминале без единой строчки Python или Node.js.

Ставится одной командой:

apt install jq
brew install jq
pacman -S jq

Дальше открывается магия.

Допустим, ты дёргаешь какой-нибудь REST API и получаешь в ответ полотно JSON в одну строку. Вместо того чтобы копировать это в браузер или онлайн-форматтер, делаешь так:

curl -s https://api.example.com/users | jq.

И получаешь красиво отформатированный JSON с подсветкой прямо в терминале. Уже удобно.

Но это ещё не всё. Хочешь вытащить только одно поле из каждого объекта в массиве:

curl -s https://api.example.com/users | jq '.[].name'

Хочешь отфильтровать только активных пользователей:

jq '[.[] | select(.active == true)]'

Хочешь переименовать поля и собрать новый объект:

jq '{login:.username, mail:.email}'

Всё это работает в пайпе, без файлов, без скриптов, без лишнего мусора.

Особенно жирно jq выглядит в CI/CD. Например, ты деплоишь через GitHub Actions и хочешь вытащить конкретный параметр из ответа API деплоя, чтобы передать его в следующий шаг. Пишешь одну строчку с jq — и всё. Никакого питона, никаких регулярок на костылях.

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

cat app.log | jq 'select(.level == "error") | {time:.timestamp, msg:.message}'

Это не игрушка и не хипстерский инструмент ради инструмента. jq реально экономит время каждый день если ты так или иначе касаешься JSON в работе.

Документация на jqlang.github.io, там же встроенный playground чтобы попробовать прямо в браузере.

Если ещё не пользуешься — поставь сегодня. Пожалеешь только об одном: что не поставил раньше.

linux.exe

Подпишись на создателей: https://t.me/linuxexex