ctrl+r — поиск по истории команд в реальном времени. Вы про него знаете, но половина не пользуется.
Жмёшь ctrl+r, начинаешь набирать кусок команды — терминал сам находит последнее совпадение из истории. Нашёл нужное — Enter. Не то — жмёшь ctrl+r ещё раз, идёт дальше в глубь истории.
Вместо того чтобы листать стрелкой вверх сто раз или заново набирать длинный docker-compose или ffmpeg с кучей флагов — просто вспоминаешь пару букв из команды и находишь за секунду.
Но это все знают. Вот что знают меньше:
Если в ~/.bashrc или ~/.zshrc добавить:
HISTSIZE=100000
HISTFILESIZE=200000
HISTCONTROL=ignoredups:erasedups
...то история перестаёт обрезаться и дублироваться. И ctrl+r начинает работать по базе из десятков тысяч команд, включая то, что вы вводили полгода назад.
Ещё один уровень — поставить fzf. После установки ctrl+r превращается в интерактивный fuzzy-поиск с превью прямо в терминале. Ищет нечёткко, не требует точного совпадения, показывает сразу несколько вариантов. Ставится одной командой, интегрируется в bash и zsh автоматически.
На большинстве систем: git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf && ~/.fzf/install
После этого работа с историей команд меняется кардинально. Особенно если вы постоянно гоняете одни и те же длинные команды с разными аргументами — находите старую, редактируете на месте и запускаете.
Мелочь, но за день экономит минут десять-пятнадцать гарантированно. За год это несколько рабочих дней.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Жмёшь ctrl+r, начинаешь набирать кусок команды — терминал сам находит последнее совпадение из истории. Нашёл нужное — Enter. Не то — жмёшь ctrl+r ещё раз, идёт дальше в глубь истории.
Вместо того чтобы листать стрелкой вверх сто раз или заново набирать длинный docker-compose или ffmpeg с кучей флагов — просто вспоминаешь пару букв из команды и находишь за секунду.
Но это все знают. Вот что знают меньше:
Если в ~/.bashrc или ~/.zshrc добавить:
HISTSIZE=100000
HISTFILESIZE=200000
HISTCONTROL=ignoredups:erasedups
...то история перестаёт обрезаться и дублироваться. И ctrl+r начинает работать по базе из десятков тысяч команд, включая то, что вы вводили полгода назад.
Ещё один уровень — поставить fzf. После установки ctrl+r превращается в интерактивный fuzzy-поиск с превью прямо в терминале. Ищет нечёткко, не требует точного совпадения, показывает сразу несколько вариантов. Ставится одной командой, интегрируется в bash и zsh автоматически.
На большинстве систем: git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf && ~/.fzf/install
После этого работа с историей команд меняется кардинально. Особенно если вы постоянно гоняете одни и те же длинные команды с разными аргументами — находите старую, редактируете на месте и запускаете.
Мелочь, но за день экономит минут десять-пятнадцать гарантированно. За год это несколько рабочих дней.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
VFS: файловая система, которой не существует
Когда ты открываешь файл в Linux командой open(), ядру глубоко фиолетово, где этот файл реально живёт. На жёстком диске? На флешке с FAT32? В оперативной памяти? В сети через NFS? Ядро говорит: разбирайся сам, VFS.
VFS расшифровывается как Virtual File System, и это один из самых изящных слоёв абстракции во всём ядре. Суть простая: между твоей программой и реальной файловой системой стоит посредник, который притворяется, что всё одинаковое.
Как это работает внутри.
VFS держит в памяти несколько ключевых структур. Первая называется inode. Это не файл и не его имя, это описание объекта: размер, права доступа, владелец, время модификации, указатели на данные. У каждого файла или директории есть свой inode. Имя файла хранится отдельно, в структуре dentry. Получается, что имя и содержимое связаны через inode, а не напрямую. Отсюда и растут жёсткие ссылки: ты можешь иметь десять имён для одного inode, удалить девять из них, и файл никуда не денется.
Третья структура называется file. Она создаётся, когда процесс открывает файл, и хранит текущую позицию в нём, флаги доступа и указатель на операции. Именно через эту структуру ядро знает, что именно делать с read() или write() для конкретного файла.
И наконец, суперблок. Это метаданные всей смонтированной файловой системы: тип FS, размер блока, сколько места свободно, указатель на корневой inode.
Когда ты монтируешь ext4 или btrfs или tmpfs, каждая реальная файловая система регистрирует в VFS набор функций-обработчиков. Типа: вот моя функция для чтения inode, вот для записи, вот для создания файла. VFS просто вызывает нужную функцию через указатель. Твой код на Си не знает и не должен знать, что под капотом.
Почему это важно.
Именно VFS позволяет тебе делать cat /proc/cpuinfo, хотя никакого файла на диске нет. procfs просто реализует интерфейс VFS и на лету генерирует содержимое из данных ядра. То же самое с /sys, с /dev/null, с сокетами через /proc/self/fd.
Это также объясняет, почему на Linux можно без боли читать ntfs-раздел Windows или монтировать образ диска как директорию. Пока драйвер реализует интерфейс VFS, ядру всё равно что там внутри.
Ещё один побочный эффект: кеш страниц. VFS сидит поверх него, и когда ты читаешь один и тот же файл дважды, второй раз данные летят из оперативки, а не с диска. Это не магия файловой системы, это работа VFS совместно с page cache.
Весь этот слой написан на Си, весит несколько десятков тысяч строк и работает на каждой машине с Linux прямо сейчас. Незаметно, как хороший сисадмин.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Когда ты открываешь файл в Linux командой open(), ядру глубоко фиолетово, где этот файл реально живёт. На жёстком диске? На флешке с FAT32? В оперативной памяти? В сети через NFS? Ядро говорит: разбирайся сам, VFS.
VFS расшифровывается как Virtual File System, и это один из самых изящных слоёв абстракции во всём ядре. Суть простая: между твоей программой и реальной файловой системой стоит посредник, который притворяется, что всё одинаковое.
Как это работает внутри.
VFS держит в памяти несколько ключевых структур. Первая называется inode. Это не файл и не его имя, это описание объекта: размер, права доступа, владелец, время модификации, указатели на данные. У каждого файла или директории есть свой inode. Имя файла хранится отдельно, в структуре dentry. Получается, что имя и содержимое связаны через inode, а не напрямую. Отсюда и растут жёсткие ссылки: ты можешь иметь десять имён для одного inode, удалить девять из них, и файл никуда не денется.
Третья структура называется file. Она создаётся, когда процесс открывает файл, и хранит текущую позицию в нём, флаги доступа и указатель на операции. Именно через эту структуру ядро знает, что именно делать с read() или write() для конкретного файла.
И наконец, суперблок. Это метаданные всей смонтированной файловой системы: тип FS, размер блока, сколько места свободно, указатель на корневой inode.
Когда ты монтируешь ext4 или btrfs или tmpfs, каждая реальная файловая система регистрирует в VFS набор функций-обработчиков. Типа: вот моя функция для чтения inode, вот для записи, вот для создания файла. VFS просто вызывает нужную функцию через указатель. Твой код на Си не знает и не должен знать, что под капотом.
Почему это важно.
Именно VFS позволяет тебе делать cat /proc/cpuinfo, хотя никакого файла на диске нет. procfs просто реализует интерфейс VFS и на лету генерирует содержимое из данных ядра. То же самое с /sys, с /dev/null, с сокетами через /proc/self/fd.
Это также объясняет, почему на Linux можно без боли читать ntfs-раздел Windows или монтировать образ диска как директорию. Пока драйвер реализует интерфейс VFS, ядру всё равно что там внутри.
Ещё один побочный эффект: кеш страниц. VFS сидит поверх него, и когда ты читаешь один и тот же файл дважды, второй раз данные летят из оперативки, а не с диска. Это не магия файловой системы, это работа VFS совместно с page cache.
Весь этот слой написан на Си, весит несколько десятков тысяч строк и работает на каждой машине с Linux прямо сейчас. Незаметно, как хороший сисадмин.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Команда: nl
Большинство людей, когда нужно пронумеровать строки файла, сразу тянутся к cat -n или grep -n. Но есть nl — и она делает это умнее.
nl расшифровывается как number lines. Она нумерует строки файла, но в отличие от cat -n умеет делать это гибко и с умом.
Базовый пример:
nl файл.txt
Выведет файл с пронумерованными строками. Пока ничего особенного. Но дьявол в деталях.
По умолчанию nl не нумерует пустые строки. cat -n нумерует всё подряд, включая пустоту. nl пропускает пустые строки и не тратит на них номер. Иногда это именно то, что нужно.
Флаги, которые реально пригодятся:
-b a — нумеровать все строки, включая пустые. Поведение как у cat -n.
-b t — нумеровать только непустые строки. Это поведение по умолчанию.
-b p PATTERN — нумеровать только строки, которые совпадают с регулярным выражением. Вот тут начинается магия.
Пример: хочешь пронумеровать только строки, содержащие слово error:
nl -b p'error' лог.txt
Строки без error выводятся без номера, строки с error — с номером. Удобно при разборе логов.
Ещё полезные флаги:
-n ln — номер выравнивается по левому краю.
-n rn — по правому краю без нулей (по умолчанию).
-n rz — по правому краю с ведущими нулями, типа 001, 002, 003.
-w N — ширина поля под номер. По умолчанию 6, можно поставить меньше.
-s STRING — разделитель между номером и строкой. По умолчанию табуляция. Можно поставить например двоеточие или пробел.
nl -s ': ' -n rz -w 3 файл.txt
Получишь красивый вывод вида:
001: первая строка
002: вторая строка
Реальный сценарий использования: ты ревьюишь конфиг или скрипт и хочешь быстро сослаться на номер строки в разговоре с коллегой. nl выдаёт чистый нумерованный вывод без лишнего шума. Или парсишь лог и хочешь видеть только строки с нужным паттерном вместе с их позицией в файле.
nl есть в любом GNU/Linux по умолчанию, входит в пакет coreutils. Никаких установок, никаких зависимостей.
Мелкая, неприметная, но иногда точнее cat -n там, где нужна избирательность.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Большинство людей, когда нужно пронумеровать строки файла, сразу тянутся к cat -n или grep -n. Но есть nl — и она делает это умнее.
nl расшифровывается как number lines. Она нумерует строки файла, но в отличие от cat -n умеет делать это гибко и с умом.
Базовый пример:
nl файл.txt
Выведет файл с пронумерованными строками. Пока ничего особенного. Но дьявол в деталях.
По умолчанию nl не нумерует пустые строки. cat -n нумерует всё подряд, включая пустоту. nl пропускает пустые строки и не тратит на них номер. Иногда это именно то, что нужно.
Флаги, которые реально пригодятся:
-b a — нумеровать все строки, включая пустые. Поведение как у cat -n.
-b t — нумеровать только непустые строки. Это поведение по умолчанию.
-b p PATTERN — нумеровать только строки, которые совпадают с регулярным выражением. Вот тут начинается магия.
Пример: хочешь пронумеровать только строки, содержащие слово error:
nl -b p'error' лог.txt
Строки без error выводятся без номера, строки с error — с номером. Удобно при разборе логов.
Ещё полезные флаги:
-n ln — номер выравнивается по левому краю.
-n rn — по правому краю без нулей (по умолчанию).
-n rz — по правому краю с ведущими нулями, типа 001, 002, 003.
-w N — ширина поля под номер. По умолчанию 6, можно поставить меньше.
-s STRING — разделитель между номером и строкой. По умолчанию табуляция. Можно поставить например двоеточие или пробел.
nl -s ': ' -n rz -w 3 файл.txt
Получишь красивый вывод вида:
001: первая строка
002: вторая строка
Реальный сценарий использования: ты ревьюишь конфиг или скрипт и хочешь быстро сослаться на номер строки в разговоре с коллегой. nl выдаёт чистый нумерованный вывод без лишнего шума. Или парсишь лог и хочешь видеть только строки с нужным паттерном вместе с их позицией в файле.
nl есть в любом GNU/Linux по умолчанию, входит в пакет coreutils. Никаких установок, никаких зависимостей.
Мелкая, неприметная, но иногда точнее cat -n там, где нужна избирательность.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Дыхательные упражнения гасят физическую реакцию тела на острый стресс
Новое исследование показало: специальные техники дыхания реально снижают физиологический отклик организма на острый стресс. Не в переносном смысле, не "помогает расслабиться морально" - а именно меняют то, что происходит внутри тела на уровне физиологии.
Острый стресс - это когда тебя внезапно накрывает: публичное выступление, конфликт, неожиданная плохая новость. В такие моменты тело запускает классическую реакцию "бей или беги": сердце колотится, давление растёт, кортизол прёт вверх, мышцы напрягаются. Всё это управляется вегетативной нервной системой и в моменте почти не поддаётся сознательному контролю. Почти - потому что дыхание как раз является тем редким инструментом, через который можно влезть в эту автоматику вручную.
Исследователи зафиксировали, что дыхательные практики - в частности, медленное диафрагмальное дыхание и техники с удлинённым выдохом - активируют парасимпатическую нервную систему. Это та ветка, которая отвечает за торможение стрессовой реакции и запуск режима восстановления. В результате снижается частота сердечных сокращений, нормализуется вариабельность сердечного ритма и падает уровень маркеров стресса.
Ключевой момент: эффект зафиксирован именно на физиологических показателях, а не только на субъективных ощущениях участников. То есть это не просто "мне кажется, что я успокоился" - приборы показывают реальные изменения в работе тела.
Для тех, кто хочет попробовать: самая простая схема с доказанным эффектом - вдох на 4 секунды, задержка на 4, выдох на 6-8 секунд. Удлинённый выдох - это ключ, именно он сильнее всего давит на тормоз стрессовой реакции.
linux.exe | @linuxexe_bot
Источник (r/science): https://www.reddit.com/r/science/comments/1vo949n/breathing_exercises_blunt_the_bodys_physical/
Подпишись на создателей: https://t.me/linuxexex
Новое исследование показало: специальные техники дыхания реально снижают физиологический отклик организма на острый стресс. Не в переносном смысле, не "помогает расслабиться морально" - а именно меняют то, что происходит внутри тела на уровне физиологии.
Острый стресс - это когда тебя внезапно накрывает: публичное выступление, конфликт, неожиданная плохая новость. В такие моменты тело запускает классическую реакцию "бей или беги": сердце колотится, давление растёт, кортизол прёт вверх, мышцы напрягаются. Всё это управляется вегетативной нервной системой и в моменте почти не поддаётся сознательному контролю. Почти - потому что дыхание как раз является тем редким инструментом, через который можно влезть в эту автоматику вручную.
Исследователи зафиксировали, что дыхательные практики - в частности, медленное диафрагмальное дыхание и техники с удлинённым выдохом - активируют парасимпатическую нервную систему. Это та ветка, которая отвечает за торможение стрессовой реакции и запуск режима восстановления. В результате снижается частота сердечных сокращений, нормализуется вариабельность сердечного ритма и падает уровень маркеров стресса.
Ключевой момент: эффект зафиксирован именно на физиологических показателях, а не только на субъективных ощущениях участников. То есть это не просто "мне кажется, что я успокоился" - приборы показывают реальные изменения в работе тела.
Для тех, кто хочет попробовать: самая простая схема с доказанным эффектом - вдох на 4 секунды, задержка на 4, выдох на 6-8 секунд. Удлинённый выдох - это ключ, именно он сильнее всего давит на тормоз стрессовой реакции.
linux.exe | @linuxexe_bot
Источник (r/science): https://www.reddit.com/r/science/comments/1vo949n/breathing_exercises_blunt_the_bodys_physical/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the science community on Reddit: Breathing exercises blunt the body’s physical reaction to acute stress
Explore this post and more from the science community
Как Linux понимает, что ты нажал кнопку на клавиатуре
Давай разберём подсистему ввода в ядре Linux. Без академической скуки, просто и по делу.
Когда ты давишь на клавишу, железо генерирует прерывание. Процессор бросает всё, что делал, и говорит ядру: эй, кто-то что-то нажал. Ядро смотрит, от какого устройства пришло прерывание, и передаёт управление нужному драйверу. Это первый слой — железо разговаривает с драйвером.
Драйвер клавиатуры принимает сырой скан-код. Это просто число, которое означает физическую клавишу. Не букву, не символ — именно физическую кнопку на плате. Нажал A — получил одно число, отпустил A — другое. Драйвер пока не знает, что это вообще буква.
Дальше скан-код попадает в слой input subsystem. Это абстракция, которую Линус и компания придумали, чтобы не писать отдельную логику для каждой железки. Input subsystem живёт в drivers/input и говорит на универсальном языке событий. Событие — это структура с типом, кодом и значением. Тип говорит что это: кнопка, движение мыши, колёсико. Код говорит какая именно кнопка. Значение — нажато или отпущено.
Эти события летят в evdev. Это виртуальное устройство, файл вида /dev/input/event0, event1 и так далее. Любая программа в юзерспейсе может открыть этот файл и читать сырые события. Так работает, например, libinput, которую использует Wayland. Она читает события из evdev, применяет настройки ускорения курсора, мёртвые зоны, раскладки — и уже готовый результат отдаёт оконному серверу.
Параллельно существует старый путь через /dev/tty и консольный слой. Там скан-коды превращаются в keysym по таблице раскладки прямо в ядре. Так работает виртуальная консоль когда ты вышел из графики в tty1.
Самое крутое в этой архитектуре — разделение ответственности. Драйвер не знает про раскладки. Input subsystem не знает про оконные серверы. Evdev не знает, что делает приложение с событиями. Каждый слой делает одно и делает это хорошо.
Поэтому один и тот же драйвер USB-клавиатуры работает и на сервере без GUI, и в GNOME, и в игре через SDL. Никто ни с кем не договаривается заранее — просто события текут снизу вверх по слоям.
Вот так нажатие одной кнопки проходит через железо, прерывание, драйвер, абстракцию событий и добирается до твоего браузера. Меньше чем за миллисекунду.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Давай разберём подсистему ввода в ядре Linux. Без академической скуки, просто и по делу.
Когда ты давишь на клавишу, железо генерирует прерывание. Процессор бросает всё, что делал, и говорит ядру: эй, кто-то что-то нажал. Ядро смотрит, от какого устройства пришло прерывание, и передаёт управление нужному драйверу. Это первый слой — железо разговаривает с драйвером.
Драйвер клавиатуры принимает сырой скан-код. Это просто число, которое означает физическую клавишу. Не букву, не символ — именно физическую кнопку на плате. Нажал A — получил одно число, отпустил A — другое. Драйвер пока не знает, что это вообще буква.
Дальше скан-код попадает в слой input subsystem. Это абстракция, которую Линус и компания придумали, чтобы не писать отдельную логику для каждой железки. Input subsystem живёт в drivers/input и говорит на универсальном языке событий. Событие — это структура с типом, кодом и значением. Тип говорит что это: кнопка, движение мыши, колёсико. Код говорит какая именно кнопка. Значение — нажато или отпущено.
Эти события летят в evdev. Это виртуальное устройство, файл вида /dev/input/event0, event1 и так далее. Любая программа в юзерспейсе может открыть этот файл и читать сырые события. Так работает, например, libinput, которую использует Wayland. Она читает события из evdev, применяет настройки ускорения курсора, мёртвые зоны, раскладки — и уже готовый результат отдаёт оконному серверу.
Параллельно существует старый путь через /dev/tty и консольный слой. Там скан-коды превращаются в keysym по таблице раскладки прямо в ядре. Так работает виртуальная консоль когда ты вышел из графики в tty1.
Самое крутое в этой архитектуре — разделение ответственности. Драйвер не знает про раскладки. Input subsystem не знает про оконные серверы. Evdev не знает, что делает приложение с событиями. Каждый слой делает одно и делает это хорошо.
Поэтому один и тот же драйвер USB-клавиатуры работает и на сервере без GUI, и в GNOME, и в игре через SDL. Никто ни с кем не договаривается заранее — просто события текут снизу вверх по слоям.
Вот так нажатие одной кнопки проходит через железо, прерывание, драйвер, абстракцию событий и добирается до твоего браузера. Меньше чем за миллисекунду.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Один ноутбук, одна задача, пять Linux-дистрибутивов
Сравнивать дистрибутивы по обоям и логотипам бессмысленно. Возьмём конкретный сценарий: разработчик получает чистый ноутбук и должен подготовить окружение для проекта на Node.js с Git, Docker, PostgreSQL и VS Code.
Ubuntu
Установка простая, документации море, почти любой баг уже кто-то решил на форуме. Docker, драйверы и сторонний софт ставятся без особых приключений. Пакеты не самые свежие, зато окружение предсказуемое.
Итог: лучший вариант, если нужно начать работать сегодня, а не изучать устройство системы.
Fedora
Свежие ядро, GNOME и инструменты разработки. Podman доступен сразу и может заменить Docker, но проектные инструкции часто написаны именно под Docker, поэтому иногда приходится адаптироваться. С проприетарными кодеками и драйверами обычно нужны дополнительные репозитории.
Итог: современная рабочая станция без экстремального риска rolling release.
Arch Linux
Можно собрать окружение ровно под себя: минимальная система, свежие Node.js, Docker и PostgreSQL, огромный AUR. Но настройка занимает время, а обновления иногда требуют прочитать новости проекта и вмешаться руками.
Итог: отличный выбор для тех, кому настройка системы тоже часть работы. Плохой выбор, если через час созвон и срочно нужно поднять проект.
Debian
Стабильный и скучный в хорошем смысле. Docker и серверные инструменты работают надёжно, но версии пакетов в стабильной ветке могут заметно отставать. Для Node.js это решается через nvm, контейнеры или сторонние репозитории.
Итог: прекрасная база для сервера и спокойной разработки, если новизна пакетов не является целью.
openSUSE Tumbleweed
Свежие пакеты, мощный YaST и важное преимущество: снимки Btrfs со Snapper. Если обновление сломало окружение, систему можно откатить. Минус в том, что инструкций и готовых решений для openSUSE меньше, чем для Ubuntu или Arch.
Итог: интересный компромисс между rolling release и возможностью быстро вернуть всё назад.
Кто победил?
Для корпоративного ноутбука: Ubuntu.
Для свежего десктопа разработчика: Fedora.
Для полного контроля и обучения: Arch.
Для стабильной базы: Debian.
Для экспериментов с удобным откатом: openSUSE Tumbleweed.
Главный вывод: лучший дистрибутив определяется не рейтингом в интернете, а конкретной задачей. В нашем примере Ubuntu быстрее доведёт разработчика до первого docker compose up, Arch даст больше контроля, а Fedora предложит разумный баланс между свежестью и удобством.
Подпишись на создателей: https://t.me/linuxexex
Сравнивать дистрибутивы по обоям и логотипам бессмысленно. Возьмём конкретный сценарий: разработчик получает чистый ноутбук и должен подготовить окружение для проекта на Node.js с Git, Docker, PostgreSQL и VS Code.
Ubuntu
Установка простая, документации море, почти любой баг уже кто-то решил на форуме. Docker, драйверы и сторонний софт ставятся без особых приключений. Пакеты не самые свежие, зато окружение предсказуемое.
Итог: лучший вариант, если нужно начать работать сегодня, а не изучать устройство системы.
Fedora
Свежие ядро, GNOME и инструменты разработки. Podman доступен сразу и может заменить Docker, но проектные инструкции часто написаны именно под Docker, поэтому иногда приходится адаптироваться. С проприетарными кодеками и драйверами обычно нужны дополнительные репозитории.
Итог: современная рабочая станция без экстремального риска rolling release.
Arch Linux
Можно собрать окружение ровно под себя: минимальная система, свежие Node.js, Docker и PostgreSQL, огромный AUR. Но настройка занимает время, а обновления иногда требуют прочитать новости проекта и вмешаться руками.
Итог: отличный выбор для тех, кому настройка системы тоже часть работы. Плохой выбор, если через час созвон и срочно нужно поднять проект.
Debian
Стабильный и скучный в хорошем смысле. Docker и серверные инструменты работают надёжно, но версии пакетов в стабильной ветке могут заметно отставать. Для Node.js это решается через nvm, контейнеры или сторонние репозитории.
Итог: прекрасная база для сервера и спокойной разработки, если новизна пакетов не является целью.
openSUSE Tumbleweed
Свежие пакеты, мощный YaST и важное преимущество: снимки Btrfs со Snapper. Если обновление сломало окружение, систему можно откатить. Минус в том, что инструкций и готовых решений для openSUSE меньше, чем для Ubuntu или Arch.
Итог: интересный компромисс между rolling release и возможностью быстро вернуть всё назад.
Кто победил?
Для корпоративного ноутбука: Ubuntu.
Для свежего десктопа разработчика: Fedora.
Для полного контроля и обучения: Arch.
Для стабильной базы: Debian.
Для экспериментов с удобным откатом: openSUSE Tumbleweed.
Главный вывод: лучший дистрибутив определяется не рейтингом в интернете, а конкретной задачей. В нашем примере Ubuntu быстрее доведёт разработчика до первого docker compose up, Arch даст больше контроля, а Fedora предложит разумный баланс между свежестью и удобством.
Подпишись на создателей: https://t.me/linuxexex
Как работает планировщик задач в 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