Как работает планировщик задач в Linux — простыми словами
Твой компьютер прямо сейчас делает десятки вещей одновременно. Музыка играет, браузер грузит страницу, терминал ждёт команды. Но процессор — он один. Как он успевает всё? За это отвечает планировщик задач, и он куда умнее, чем кажется.
Главная идея
Процессор не делает всё одновременно. Он очень быстро переключается между задачами. Настолько быстро, что мозг воспринимает это как параллельность. Планировщик решает: кому дать слово сейчас, кого поставить в очередь, а кого вообще временно заморозить.
Как было раньше
Старые планировщики делили время честно — каждому процессу выделяли квант времени, обычно несколько миллисекунд. Отработал — следующий. Звучит справедливо, но на практике было тупо. Системный процесс и торрент-клиент получали одинаковое внимание. Курсор мышки лагал, потому что ждал своей очереди в общей толпе.
Что сейчас — CFS
С версии ядра 2.6.23 в Linux живёт CFS, Completely Fair Scheduler. Название говорит само за себя — полностью справедливый планировщик. Но справедливость тут не про равные кванты, а про равное виртуальное время.
Каждый процесс накапливает vruntime — виртуальное время работы. Кто накопил меньше всего, тот следующий на очереди. Простаивающий процесс получает приоритет автоматически. Твой терминал молчал пять секунд? Значит, его vruntime низкий, и когда ты нажмёшь Enter, он получит процессор почти мгновенно.
Приоритеты через nice
Процессам можно выставить приоритет через значение nice от -20 до 19. Чем ниже число, тем важнее процесс. Процесс с nice -20 накапливает vruntime медленнее — то есть как будто работает меньше, чем реально. Поэтому его снова и снова выбирают первым. Процесс с nice 19 — наоборот, считается жадным, накапливает vruntime быстро и сидит в конце очереди.
Запустить что-то с низким приоритетом просто:
nice -n 19./тяжёлый_скрипт.sh
Так можно гонять компиляцию или бэкап в фоне, и система не будет тормозить.
Классы планирования
CFS — не единственный режим. Есть ещё SCHED_FIFO и SCHED_RR для задач реального времени. Там другая логика: процесс работает, пока сам не отпустит процессор или не появится задача с приоритетом выше. Это используют, например, звуковые серверы вроде PulseAudio и Jack — им критично не пропустить момент воспроизведения буфера.
Балансировка по ядрам
На многоядерных системах планировщик ещё и балансирует нагрузку между ядрами. Он следит, чтобы одно ядро не задыхалось, пока соседнее гуляет. Это называется load balancing, и оно работает автоматически. Ядра периодически смотрят друг на друга и перекидывают процессы туда, где свободнее.
Посмотреть, что происходит прямо сейчас, можно командой:
cat /proc/schedstat
Или поставь htop и включи отображение по ядрам — будет наглядно.
Почему это важно
Понимание планировщика помогает отлаживать тормоза, правильно расставлять приоритеты процессам и писать код, который не ведёт себя как хам в очереди. Linux не магия. Это система с чёткими правилами — и знать их полезно.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Твой компьютер прямо сейчас делает десятки вещей одновременно. Музыка играет, браузер грузит страницу, терминал ждёт команды. Но процессор — он один. Как он успевает всё? За это отвечает планировщик задач, и он куда умнее, чем кажется.
Главная идея
Процессор не делает всё одновременно. Он очень быстро переключается между задачами. Настолько быстро, что мозг воспринимает это как параллельность. Планировщик решает: кому дать слово сейчас, кого поставить в очередь, а кого вообще временно заморозить.
Как было раньше
Старые планировщики делили время честно — каждому процессу выделяли квант времени, обычно несколько миллисекунд. Отработал — следующий. Звучит справедливо, но на практике было тупо. Системный процесс и торрент-клиент получали одинаковое внимание. Курсор мышки лагал, потому что ждал своей очереди в общей толпе.
Что сейчас — CFS
С версии ядра 2.6.23 в Linux живёт CFS, Completely Fair Scheduler. Название говорит само за себя — полностью справедливый планировщик. Но справедливость тут не про равные кванты, а про равное виртуальное время.
Каждый процесс накапливает vruntime — виртуальное время работы. Кто накопил меньше всего, тот следующий на очереди. Простаивающий процесс получает приоритет автоматически. Твой терминал молчал пять секунд? Значит, его vruntime низкий, и когда ты нажмёшь Enter, он получит процессор почти мгновенно.
Приоритеты через nice
Процессам можно выставить приоритет через значение nice от -20 до 19. Чем ниже число, тем важнее процесс. Процесс с nice -20 накапливает vruntime медленнее — то есть как будто работает меньше, чем реально. Поэтому его снова и снова выбирают первым. Процесс с nice 19 — наоборот, считается жадным, накапливает vruntime быстро и сидит в конце очереди.
Запустить что-то с низким приоритетом просто:
nice -n 19./тяжёлый_скрипт.sh
Так можно гонять компиляцию или бэкап в фоне, и система не будет тормозить.
Классы планирования
CFS — не единственный режим. Есть ещё SCHED_FIFO и SCHED_RR для задач реального времени. Там другая логика: процесс работает, пока сам не отпустит процессор или не появится задача с приоритетом выше. Это используют, например, звуковые серверы вроде PulseAudio и Jack — им критично не пропустить момент воспроизведения буфера.
Балансировка по ядрам
На многоядерных системах планировщик ещё и балансирует нагрузку между ядрами. Он следит, чтобы одно ядро не задыхалось, пока соседнее гуляет. Это называется load balancing, и оно работает автоматически. Ядра периодически смотрят друг на друга и перекидывают процессы туда, где свободнее.
Посмотреть, что происходит прямо сейчас, можно командой:
cat /proc/schedstat
Или поставь htop и включи отображение по ядрам — будет наглядно.
Почему это важно
Понимание планировщика помогает отлаживать тормоза, правильно расставлять приоритеты процессам и писать код, который не ведёт себя как хам в очереди. Linux не магия. Это система с чёткими правилами — и знать их полезно.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Тот самый CEO, который уволил 900 человек через Zoom прямо перед Рождеством, теперь хочет вернуть свою должность
Вишал Гарг, бывший генеральный директор компании Better.com, прославился на весь мир в декабре 2021 года, когда собрал около 900 сотрудников на групповой звонок в Zoom и за несколько минут сообщил им, что они уволены. Прямо перед Рождеством. Без особых предисловий. «Если вы на этом звонке, значит, вы часть несчастливчиков, которых я увольняю», — примерно так это и звучало.
Видео утекло в сеть, разлетелось по всем медиа, и Гарг мгновенно стал символом корпоративной бесчеловечности. Под давлением общественного скандала совет директоров фактически вынудил его взять «отпуск». Потом он вернулся. Потом компания провалила IPO через SPAC, потеряла миллиарды капитализации, провела ещё несколько волн увольнений и в итоге скатилась в банкротство.
И вот теперь этот человек, судя по всему, снова метит на роль руководителя. Потому что, видимо, первого раза было недостаточно, чтобы понять простую вещь: может, дело в тебе.
Интернет, разумеется, встретил эту новость с тем же теплом, с каким Гарг в своё время встретил своих сотрудников на том декабрьском звонке.
Источник (r/nottheonion): https://www.reddit.com/r/nottheonion/comments/1vohg3r/the_ceo_who_fired_900_people_on_zoom_just_before/
Подпишись на создателей: https://t.me/linuxexex
Вишал Гарг, бывший генеральный директор компании Better.com, прославился на весь мир в декабре 2021 года, когда собрал около 900 сотрудников на групповой звонок в Zoom и за несколько минут сообщил им, что они уволены. Прямо перед Рождеством. Без особых предисловий. «Если вы на этом звонке, значит, вы часть несчастливчиков, которых я увольняю», — примерно так это и звучало.
Видео утекло в сеть, разлетелось по всем медиа, и Гарг мгновенно стал символом корпоративной бесчеловечности. Под давлением общественного скандала совет директоров фактически вынудил его взять «отпуск». Потом он вернулся. Потом компания провалила IPO через SPAC, потеряла миллиарды капитализации, провела ещё несколько волн увольнений и в итоге скатилась в банкротство.
И вот теперь этот человек, судя по всему, снова метит на роль руководителя. Потому что, видимо, первого раза было недостаточно, чтобы понять простую вещь: может, дело в тебе.
Интернет, разумеется, встретил эту новость с тем же теплом, с каким Гарг в своё время встретил своих сотрудников на том декабрьском звонке.
Источник (r/nottheonion): https://www.reddit.com/r/nottheonion/comments/1vohg3r/the_ceo_who_fired_900_people_on_zoom_just_before/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the nottheonion community on Reddit: The CEO who fired 900 people on Zoom just before Christmas wants his job back
Explore this post and more from the nottheonion community
команда, которую ты скорее всего не знаешь: nl
большинство людей знает cat, less, head, tail. но есть nl -- утилита для нумерации строк файла. звучит скучно, но дьявол в деталях.
базовый вызов:
nl файл.txt
выведет файл с номерами строк слева. ничего особенного, скажешь ты. окей, погнали глубже.
по умолчанию nl нумерует только непустые строки. это уже интереснее, чем cat -n, который нумерует вообще всё подряд включая пустые строки. иногда это критично когда читаешь логи или конфиги.
полезные флаги:
nl -ba файл.txt
-- нумеровать абсолютно все строки, включая пустые. режим "body all".
nl -v 100 файл.txt
-- начать нумерацию не с 1, а с 100. удобно когда склеиваешь куски вывода из разных мест.
nl -s ": " файл.txt
-- заменить разделитель между номером и строкой. вместо табуляции будет ": ". читается приятнее в некоторых форматах.
nl -w 1 файл.txt
-- ширина поля номера 1 символ вместо дефолтных 6. убирает лишние пробелы слева.
nl -nrz файл.txt
-- нумерация с ведущими нулями. 000001, 000002 и так далее. полезно если потом сортируешь строки как текст а не как числа.
реальный кейс: ты получил дамп sql или большой конфиг, тебе говорят "смотри строку 847". открывать в редакторе лень, less +847 работает но теряешь контекст нумерации при прокрутке. делаешь:
nl -ba -nrz -w 4 файл.sql | less
теперь у тебя перед глазами пронумерованный файл, можно жать / и искать нужный номер прямо в less.
ещё трюк -- nl отлично работает в пайпах:
dmesg | nl -ba | grep -n "error"
или
cat /etc/passwd | nl -ba -v 0
нумерация с нуля, если тебе нужен индекс в стиле массива.
nl есть во всех дистрибутивах по умолчанию, входит в gnu coreutils. ничего устанавливать не надо. просто большинство людей о ней не вспоминают.
маленькая утилита, конкретная задача, делает её хорошо. это и есть unix-философия в чистом виде.
канал linux.exe
Подпишись на создателей: https://t.me/linuxexex
большинство людей знает cat, less, head, tail. но есть nl -- утилита для нумерации строк файла. звучит скучно, но дьявол в деталях.
базовый вызов:
nl файл.txt
выведет файл с номерами строк слева. ничего особенного, скажешь ты. окей, погнали глубже.
по умолчанию nl нумерует только непустые строки. это уже интереснее, чем cat -n, который нумерует вообще всё подряд включая пустые строки. иногда это критично когда читаешь логи или конфиги.
полезные флаги:
nl -ba файл.txt
-- нумеровать абсолютно все строки, включая пустые. режим "body all".
nl -v 100 файл.txt
-- начать нумерацию не с 1, а с 100. удобно когда склеиваешь куски вывода из разных мест.
nl -s ": " файл.txt
-- заменить разделитель между номером и строкой. вместо табуляции будет ": ". читается приятнее в некоторых форматах.
nl -w 1 файл.txt
-- ширина поля номера 1 символ вместо дефолтных 6. убирает лишние пробелы слева.
nl -nrz файл.txt
-- нумерация с ведущими нулями. 000001, 000002 и так далее. полезно если потом сортируешь строки как текст а не как числа.
реальный кейс: ты получил дамп sql или большой конфиг, тебе говорят "смотри строку 847". открывать в редакторе лень, less +847 работает но теряешь контекст нумерации при прокрутке. делаешь:
nl -ba -nrz -w 4 файл.sql | less
теперь у тебя перед глазами пронумерованный файл, можно жать / и искать нужный номер прямо в less.
ещё трюк -- nl отлично работает в пайпах:
dmesg | nl -ba | grep -n "error"
или
cat /etc/passwd | nl -ba -v 0
нумерация с нуля, если тебе нужен индекс в стиле массива.
nl есть во всех дистрибутивах по умолчанию, входит в gnu coreutils. ничего устанавливать не надо. просто большинство людей о ней не вспоминают.
маленькая утилита, конкретная задача, делает её хорошо. это и есть unix-философия в чистом виде.
канал linux.exe
Подпишись на создателей: https://t.me/linuxexex
Совет по безопасности для линуксоида, который не хочет однажды проснуться с выпотрошенным сервером.
Тема сегодня: sudo и почему ты, скорее всего, настроил его как идиот.
Большинство людей добавляют себя в sudoers через usermod -aG sudo username и забывают об этом. Окей, работает. Но потом они удивляются, почему какой-то скрипт с npm или pip внезапно попросил пароль, получил его от невнимательного пользователя, и дальше сам себе хозяин.
Что стоит сделать по-человечески.
Первое. Открой /etc/sudoers через visudo и посмотри, что там вообще написано. Если у тебя там есть строчка вида username ALL=(ALL) NOPASSWD: ALL, закрой ноутбук, выйди на улицу и подумай о жизни. NOPASSWD: ALL означает, что любой процесс от твоего имени может делать всё что угодно без единого запроса пароля. Это не удобство, это дыра.
Второе. Ограничь список команд, которым разрешён sudo без пароля, если вообще хочешь такое оставить. Например:
username ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/systemctl restart nginx
Уже лучше. Не идеально, но хотя бы не апокалипсис.
Третье. Включи логирование sudo-команд. По умолчанию всё пишется в /var/log/auth.log или /var/log/secure в зависимости от дистрибутива. Но можно настроить отдельный лог через Defaults logfile="/var/log/sudo.log" в sudoers. Смотри туда хотя бы иногда, не каждый день, но после подозрительных событий точно.
Четвёртое. Установи timeout сессии. По умолчанию sudo помнит твой пароль 15 минут. За это время много чего можно натворить. Можно поставить меньше:
Defaults timestamp_timeout=5
Или вообще 0, тогда пароль будет спрашиваться каждый раз. Раздражает, зато честно.
Пятое. Не добавляй в sudo-группу всё подряд. У тебя есть пользователь для деплоя, для бэкапов, для мониторинга? Пусть каждый из них имеет ровно те права, которые нужны, и ни байтом больше. Принцип минимальных привилегий придумали не для галочки в учебнике.
Шестое, и это вишенка. Проверь, нет ли у тебя SUID-битов на исполняемых файлах, которые не должны их иметь. Команда:
find / -perm -4000 -type f 2>/dev/null
Посмотри на вывод. Если там что-то незнакомое или подозрительное, это повод гуглить и разбираться. GTFOBins в помощь, там есть список бинарников, через которые можно поднять привилегии, если SUID стоит не там где надо.
Безопасность в Linux не требует паранойи. Требует внимательности и пяти минут раз в несколько месяцев, чтобы убедиться, что ты сам контролируешь свою систему, а не кто-то контролирует её вместо тебя.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Тема сегодня: sudo и почему ты, скорее всего, настроил его как идиот.
Большинство людей добавляют себя в sudoers через usermod -aG sudo username и забывают об этом. Окей, работает. Но потом они удивляются, почему какой-то скрипт с npm или pip внезапно попросил пароль, получил его от невнимательного пользователя, и дальше сам себе хозяин.
Что стоит сделать по-человечески.
Первое. Открой /etc/sudoers через visudo и посмотри, что там вообще написано. Если у тебя там есть строчка вида username ALL=(ALL) NOPASSWD: ALL, закрой ноутбук, выйди на улицу и подумай о жизни. NOPASSWD: ALL означает, что любой процесс от твоего имени может делать всё что угодно без единого запроса пароля. Это не удобство, это дыра.
Второе. Ограничь список команд, которым разрешён sudo без пароля, если вообще хочешь такое оставить. Например:
username ALL=(ALL) NOPASSWD: /usr/bin/apt, /usr/bin/systemctl restart nginx
Уже лучше. Не идеально, но хотя бы не апокалипсис.
Третье. Включи логирование sudo-команд. По умолчанию всё пишется в /var/log/auth.log или /var/log/secure в зависимости от дистрибутива. Но можно настроить отдельный лог через Defaults logfile="/var/log/sudo.log" в sudoers. Смотри туда хотя бы иногда, не каждый день, но после подозрительных событий точно.
Четвёртое. Установи timeout сессии. По умолчанию sudo помнит твой пароль 15 минут. За это время много чего можно натворить. Можно поставить меньше:
Defaults timestamp_timeout=5
Или вообще 0, тогда пароль будет спрашиваться каждый раз. Раздражает, зато честно.
Пятое. Не добавляй в sudo-группу всё подряд. У тебя есть пользователь для деплоя, для бэкапов, для мониторинга? Пусть каждый из них имеет ровно те права, которые нужны, и ни байтом больше. Принцип минимальных привилегий придумали не для галочки в учебнике.
Шестое, и это вишенка. Проверь, нет ли у тебя SUID-битов на исполняемых файлах, которые не должны их иметь. Команда:
find / -perm -4000 -type f 2>/dev/null
Посмотри на вывод. Если там что-то незнакомое или подозрительное, это повод гуглить и разбираться. GTFOBins в помощь, там есть список бинарников, через которые можно поднять привилегии, если SUID стоит не там где надо.
Безопасность в Linux не требует паранойи. Требует внимательности и пяти минут раз в несколько месяцев, чтобы убедиться, что ты сам контролируешь свою систему, а не кто-то контролирует её вместо тебя.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Как работает планировщик процессов в Linux — простыми словами
Каждый раз, когда ты запускаешь несколько программ одновременно, возникает вопрос: кто получает процессорное время прямо сейчас? У тебя одно ядро — а желающих поработать десятки. Этим занимается планировщик процессов, и он куда умнее, чем кажется.
Суть простая: процессор один (ну или несколько, но конечных), а процессов — тысячи. Каждый из них хочет считаться. Планировщик решает, кому дать слово, на сколько миллисекунд, и кого поставить в очередь.
Современный Linux использует CFS — Completely Fair Scheduler. Название говорит само за себя: он пытается быть честным. Не в смысле "все получают поровну", а в смысле "каждый получает столько, сколько заслуживает по приоритету".
CFS не работает с фиксированными временными слотами. Вместо этого он ведёт виртуальные часы для каждого процесса — vruntime. Это накопленное "виртуальное время", которое процесс уже провёл на процессоре. Кто меньше всего накрутил этот счётчик — тот следующий на очереди. Всё хранится в красно-чёрном дереве, где крайний левый узел — самый голодный процесс.
Приоритеты тоже есть. Это nice-значения от -20 до 19. Чем ниже число — тем важнее процесс. Nginx с nice -5 будет получать больше времени, чем твой скрипт на Python с nice 10. Но даже низкоприоритетный процесс не умрёт от голода — CFS всё равно даст ему поработать, просто реже.
Отдельная история — процессы реального времени. Для них есть другие планировщики: SCHED_FIFO и SCHED_RR. Они работают вне CFS и имеют абсолютный приоритет. Если аудиодемон или промышленный контроллер требуют гарантированного времени отклика — их ставят туда. CFS для таких задач слишком "демократичный".
Есть ещё одна штука — preemption, вытеснение. Если появился процесс с меньшим vruntime, пока другой работает, ядро может прервать текущий процесс и переключиться. Это и есть вытесняющая многозадачность. Никакой процесс не может монополизировать процессор бесконечно — ядро его вежливо, но жёстко отодвинет.
На многоядерных системах добавляется балансировка нагрузки. Каждое ядро имеет свою очередь процессов, и периодически планировщик смотрит: не перегружено ли одно ядро, пока другое простаивает. Если дисбаланс есть — процессы мигрируют между ядрами. Прозрачно для пользователя, незаметно, но постоянно.
Итого: планировщик Linux — это не простая очередь. Это система с виртуальным временем, приоритетами, деревьями, вытеснением и балансировкой. Всё это крутится в фоне каждую миллисекунду, пока ты смотришь ролики и компилируешь код одновременно. И делает это настолько незаметно, что большинство вообще не думает о его существовании.
Вот это и есть хорошо написанный системный код.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Каждый раз, когда ты запускаешь несколько программ одновременно, возникает вопрос: кто получает процессорное время прямо сейчас? У тебя одно ядро — а желающих поработать десятки. Этим занимается планировщик процессов, и он куда умнее, чем кажется.
Суть простая: процессор один (ну или несколько, но конечных), а процессов — тысячи. Каждый из них хочет считаться. Планировщик решает, кому дать слово, на сколько миллисекунд, и кого поставить в очередь.
Современный Linux использует CFS — Completely Fair Scheduler. Название говорит само за себя: он пытается быть честным. Не в смысле "все получают поровну", а в смысле "каждый получает столько, сколько заслуживает по приоритету".
CFS не работает с фиксированными временными слотами. Вместо этого он ведёт виртуальные часы для каждого процесса — vruntime. Это накопленное "виртуальное время", которое процесс уже провёл на процессоре. Кто меньше всего накрутил этот счётчик — тот следующий на очереди. Всё хранится в красно-чёрном дереве, где крайний левый узел — самый голодный процесс.
Приоритеты тоже есть. Это nice-значения от -20 до 19. Чем ниже число — тем важнее процесс. Nginx с nice -5 будет получать больше времени, чем твой скрипт на Python с nice 10. Но даже низкоприоритетный процесс не умрёт от голода — CFS всё равно даст ему поработать, просто реже.
Отдельная история — процессы реального времени. Для них есть другие планировщики: SCHED_FIFO и SCHED_RR. Они работают вне CFS и имеют абсолютный приоритет. Если аудиодемон или промышленный контроллер требуют гарантированного времени отклика — их ставят туда. CFS для таких задач слишком "демократичный".
Есть ещё одна штука — preemption, вытеснение. Если появился процесс с меньшим vruntime, пока другой работает, ядро может прервать текущий процесс и переключиться. Это и есть вытесняющая многозадачность. Никакой процесс не может монополизировать процессор бесконечно — ядро его вежливо, но жёстко отодвинет.
На многоядерных системах добавляется балансировка нагрузки. Каждое ядро имеет свою очередь процессов, и периодически планировщик смотрит: не перегружено ли одно ядро, пока другое простаивает. Если дисбаланс есть — процессы мигрируют между ядрами. Прозрачно для пользователя, незаметно, но постоянно.
Итого: планировщик Linux — это не простая очередь. Это система с виртуальным временем, приоритетами, деревьями, вытеснением и балансировкой. Всё это крутится в фоне каждую миллисекунду, пока ты смотришь ролики и компилируешь код одновременно. И делает это настолько незаметно, что большинство вообще не думает о его существовании.
Вот это и есть хорошо написанный системный код.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
This is the perfect brake system.
Это идеальная тормозная система.
Зачем вообще существуют ободные тормоза или механические диски, если есть вот это?
Источник (4chan /n/): https://boards.4chan.org/n/thread/2074957
Подпишись на создателей: https://t.me/linuxexex
Это идеальная тормозная система.
Зачем вообще существуют ободные тормоза или механические диски, если есть вот это?
Источник (4chan /n/): https://boards.4chan.org/n/thread/2074957
Подпишись на создателей: https://t.me/linuxexex
boards.4chan.org
/n/ - This is the perfect brake system. Why do rimjobs - Transportation - 4chan
This is the perfect brake system. - "/n/ - Transportation" is 4chan's imageboard for discussing modes of transportation like trains and bicycles.
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
Если коротко: 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
Когда Линус Торвальдс в 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
Речь про 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
Источник (r/linux): https://www.reddit.com/r/linux/comments/1vnovqd/what_a_real_lts_looks_like_kubuntu_2604/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the linux community on Reddit: What a real LTS looks like: Kubuntu 26.04
Explore this post and more from the linux community
Как 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
Когда ты пишешь в терминале 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
Если тебе нужно стереть данные так, чтобы их не восстановили даже спецслужбы, на сцену выходит малоизвестная широкому кругу, но пиздец какая полезная утилита 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
ВСУ продолжают утрачивать населенные пункты по всем направлениям СВО.В этот раз от Украины отминусовалось сразу 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
Если ты хоть раз работал с 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
Если ты до сих пор ищешь по коду через 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
Представь: у тебя 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
Источник (r/worldnews): https://www.reddit.com/r/worldnews/comments/1vq2zhb/korea_relaunches_hunt_for_assets_accumulated_by/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the worldnews community on Reddit: Korea relaunches hunt for assets accumulated by pro-Japanese collaborators
Explore this post and more from the worldnews community
Совет по безопасности для тех, кто сидит на 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
Самая частая проблема не в том, что система дырявая, а в том, что ты расслабился. Вот несколько вещей, которые реально стоит сделать прямо сейчас, если ещё не сделал.
Первое. Не работай под рутом. Вообще никогда. Даже если "надо быстро". Именно эта привычка убивает сервера быстрее всего. Для временного повышения привилегий есть 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