Команда, про которую почти никто не знает: ts
Большинство людей знают tail -f, знают grep, знают awk. Но вот ts из пакета moreutils встречают редко, хотя она реально меняет жизнь при отладке и мониторинге.
Что делает ts? Добавляет временную метку к каждой строке вывода. Звучит просто, но применений масса.
Установка:
apt install moreutils
или
yum install moreutils
Базовое использование:
ping google.com | ts
Вместо голых строк получаешь:
Jul 14 21:03:01 64 bytes from 142.250.74.46
Jul 14 21:03:02 64 bytes from 142.250.74.46
Хочешь формат с миллисекундами:
ping google.com | ts '%.S'
Хочешь относительное время с момента запуска:
ping google.com | ts -s
Вот где это реально спасает:
Логирование скриптов. Запускаешь деплой или бэкап, и каждая строка вывода получает метку. Потом не надо гадать, на каком шаге всё зависло и сколько оно там провисело.
./deploy.sh 2>&1 | ts '[%Y-%m-%d %H:%M:%S]' | tee deploy.log
Отладка тормозных процессов. Видишь, между какими строками лог молчал 30 секунд. Без ts ты просто видишь вывод, с ts видишь картину целиком.
Мониторинг в реальном времени. Любой tail -f превращается в нормальный журнал:
tail -f /var/log/syslog | ts
Разница между ts и просто добавлением date в скрипте в том, что ts работает как обёртка над любым процессом без правки его исходников. Не трогаешь чужой скрипт, не переписываешь сервис — просто пайпишь через ts и получаешь метки.
Мелочь? Да. Но именно такие мелочи экономят час жизни в самый неподходящий момент.
Поставь moreutils, там кстати ещё куча полезного — sponge, vidir, pee и другие штуки, про которые тоже мало кто знает.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Большинство людей знают tail -f, знают grep, знают awk. Но вот ts из пакета moreutils встречают редко, хотя она реально меняет жизнь при отладке и мониторинге.
Что делает ts? Добавляет временную метку к каждой строке вывода. Звучит просто, но применений масса.
Установка:
apt install moreutils
или
yum install moreutils
Базовое использование:
ping google.com | ts
Вместо голых строк получаешь:
Jul 14 21:03:01 64 bytes from 142.250.74.46
Jul 14 21:03:02 64 bytes from 142.250.74.46
Хочешь формат с миллисекундами:
ping google.com | ts '%.S'
Хочешь относительное время с момента запуска:
ping google.com | ts -s
Вот где это реально спасает:
Логирование скриптов. Запускаешь деплой или бэкап, и каждая строка вывода получает метку. Потом не надо гадать, на каком шаге всё зависло и сколько оно там провисело.
./deploy.sh 2>&1 | ts '[%Y-%m-%d %H:%M:%S]' | tee deploy.log
Отладка тормозных процессов. Видишь, между какими строками лог молчал 30 секунд. Без ts ты просто видишь вывод, с ts видишь картину целиком.
Мониторинг в реальном времени. Любой tail -f превращается в нормальный журнал:
tail -f /var/log/syslog | ts
Разница между ts и просто добавлением date в скрипте в том, что ts работает как обёртка над любым процессом без правки его исходников. Не трогаешь чужой скрипт, не переписываешь сервис — просто пайпишь через ts и получаешь метки.
Мелочь? Да. Но именно такие мелочи экономят час жизни в самый неподходящий момент.
Поставь moreutils, там кстати ещё куча полезного — sponge, vidir, pee и другие штуки, про которые тоже мало кто знает.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
/hpg/ & /sg/ & /hifi/ - Общий тред по наушникам, колонкам и Hi-Fi
Наушники miiku.
Как запрашивать советы:
Местоположение (цены и наличие могут отличаться)
Бюджет
Что именно ищешь (чем подробнее, тем лучше)
Предыдущее железо и твои впечатления о нём
Проводные наушники с открытым задником:
Hifiman HE400se
Sennheiser HD 560S
Sennheiser HD 6XX (США)
FiiO FT1 Pro
Проводные наушники с закрытым задником:
Beyerdynamic DT770
Shure SRH440A/SRH840A
AKG K361/K371
FiiO FT1
Беспроводные Bluetooth-наушники:
https://www.rtings.com/headphones/reviews/best/by-feature/wireless-bluetooth
Беспроводные игровые наушники:
https://www.rtings.com/headphones/reviews/best/wireless-gaming-headsets
Дешёвые связки усилитель/ЦАП:
JDS Atom2 Stack
Schiit Magni Unity + Mesh
Apos Gremlin/Merlin
Донглы (Fiio, Crinacle)
DX5II убрали из списка, потому что он теперь жжёт наушники по той же схеме, что и L30: https://www.audiosciencereview.com/forum/index.php?threads/topping-dx5-ii.60996/page-127#post-2492199
Активные настольные/полочные колонки:
Edifier R1280/MR3/MR4
iLoud Micro
Kali LP-6 v2
Neumann KH 80
KEF Coda W
Пассивные настольные/полочные колонки:
KEF Q1/Q3 Meta
Ascilab F6B
Интерфейсы:
Steinberg IXO22
Topping E1x2
Motu M2
Усилители для колонок:
Loxjie A30
Yamaha R-S202
WiiM Amp
Программный EQ/DSP:
Equalizer APO (Windows)
EasyEffects (Linux)
Wavelet / RootlessJamesDSP (Android)
PEQdb (браузер)
Железный EQ/DSP:
Qudelix 5K
Neutron DAC V1
miniDSP
Полезные ресурсы:
https://xiph.org/video/
https://harmanhowtolisten.blogspot.com/
https://www.audiosciencereview.com/forum/index.php
https://superbestaudiofriends.org/index.php
https://diyaudioheaven.wordpress.com/
https://www.erinsaudiocorner.com/
https://peqdb.com/
Источник (4chan /g/): https://boards.4chan.org/g/thread/109477097
Подпишись на создателей: https://t.me/linuxexex
Наушники miiku.
Как запрашивать советы:
Местоположение (цены и наличие могут отличаться)
Бюджет
Что именно ищешь (чем подробнее, тем лучше)
Предыдущее железо и твои впечатления о нём
Проводные наушники с открытым задником:
Hifiman HE400se
Sennheiser HD 560S
Sennheiser HD 6XX (США)
FiiO FT1 Pro
Проводные наушники с закрытым задником:
Beyerdynamic DT770
Shure SRH440A/SRH840A
AKG K361/K371
FiiO FT1
Беспроводные Bluetooth-наушники:
https://www.rtings.com/headphones/reviews/best/by-feature/wireless-bluetooth
Беспроводные игровые наушники:
https://www.rtings.com/headphones/reviews/best/wireless-gaming-headsets
Дешёвые связки усилитель/ЦАП:
JDS Atom2 Stack
Schiit Magni Unity + Mesh
Apos Gremlin/Merlin
Донглы (Fiio, Crinacle)
DX5II убрали из списка, потому что он теперь жжёт наушники по той же схеме, что и L30: https://www.audiosciencereview.com/forum/index.php?threads/topping-dx5-ii.60996/page-127#post-2492199
Активные настольные/полочные колонки:
Edifier R1280/MR3/MR4
iLoud Micro
Kali LP-6 v2
Neumann KH 80
KEF Coda W
Пассивные настольные/полочные колонки:
KEF Q1/Q3 Meta
Ascilab F6B
Интерфейсы:
Steinberg IXO22
Topping E1x2
Motu M2
Усилители для колонок:
Loxjie A30
Yamaha R-S202
WiiM Amp
Программный EQ/DSP:
Equalizer APO (Windows)
EasyEffects (Linux)
Wavelet / RootlessJamesDSP (Android)
PEQdb (браузер)
Железный EQ/DSP:
Qudelix 5K
Neutron DAC V1
miniDSP
Полезные ресурсы:
https://xiph.org/video/
https://harmanhowtolisten.blogspot.com/
https://www.audiosciencereview.com/forum/index.php
https://superbestaudiofriends.org/index.php
https://diyaudioheaven.wordpress.com/
https://www.erinsaudiocorner.com/
https://peqdb.com/
Источник (4chan /g/): https://boards.4chan.org/g/thread/109477097
Подпишись на создателей: https://t.me/linuxexex
RTINGS.com
The 5 Best Wireless Headphones of 2026
The Sony WH-1000XM6 are the best wireless headphones we've tested in part due to their combination of premium features and outstanding noise isolation performance.
jq — парсер JSON из командной строки, который большинство разработчиков либо не знает, либо знает, но использует на 5% от возможностей.
Ставится одной командой, работает везде, и буквально меняет то, как ты работаешь с API, логами и конфигами в терминале.
Базовое использование такое: берёшь вывод curl и прогоняешь через jq.
curl -s https://api.example.com/users | jq.
Получаешь красиво отформатированный JSON с подсветкой. Уже удобно. Но это только начало.
Хочешь вытащить конкретное поле из ответа:
curl -s https://api.example.com/users | jq '.[].name'
Получишь список имён всех пользователей. Хочешь только первого:
jq '.[0].name'
Хочешь отфильтровать массив по условию — например, только активных пользователей:
jq '[.[] | select(.active == true)]'
Хочешь переформатировать объект и взять только нужные поля:
jq '[.[] | {id:.id, login:.email}]'
Работаешь с вложенными структурами — без проблем:
jq '.data.users[].profile.city'
Самое полезное в реальной жизни: у тебя есть здоровый JSON-лог от какого-нибудь сервиса, и тебе нужно быстро найти все записи с ошибками за последний час. Делаешь это прямо в терминале без Python-скрипта, без Excel, без боли.
cat service.log | jq 'select(.level == "error") | {time:.timestamp, msg:.message}'
Другой сценарий — у тебя Kubernetes и ты хочешь узнать, на каких нодах крутятся поды с определённым лейблом:
kubectl get pods -o json | jq '.items[] | select(.metadata.labels.app == "nginx") |.spec.nodeName'
Или парсишь terraform output и вытаскиваешь конкретные адреса ресурсов. Или смотришь конфиг AWS через CLI и не хочешь читать тысячу строк глазами.
jq умеет ещё: арифметику над полями, строковую интерполяцию, рекурсивный обход через.., работу с env-переменными через --arg, чтение из файла через -f, компактный вывод через -c, raw-строки через -r чтобы убрать кавычки из вывода.
Флаг -r особенно важен когда ты хочешь передать результат дальше в скрипт:
jq -r '.[].id' | xargs -I{} curl -s https://api.example.com/user/{}
Ставится так:
На Debian/Ubuntu: apt install jq
На Arch: pacman -S jq
На Mac: brew install jq
На Alpine: apk add jq
Онлайн-площадка для экспериментов — jqplay.org. Вставляешь JSON, пишешь фильтр, смотришь результат. Удобно когда надо быстро проверить запрос перед тем как вставить в скрипт.
jq кажется простым инструментом, но это обманчивое впечатление. Чем больше ты с ним работаешь, тем больше находишь применений. Это из разряда тех утилит, которые после привыкания ты уже не представляешь как жил без них.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Ставится одной командой, работает везде, и буквально меняет то, как ты работаешь с API, логами и конфигами в терминале.
Базовое использование такое: берёшь вывод curl и прогоняешь через jq.
curl -s https://api.example.com/users | jq.
Получаешь красиво отформатированный JSON с подсветкой. Уже удобно. Но это только начало.
Хочешь вытащить конкретное поле из ответа:
curl -s https://api.example.com/users | jq '.[].name'
Получишь список имён всех пользователей. Хочешь только первого:
jq '.[0].name'
Хочешь отфильтровать массив по условию — например, только активных пользователей:
jq '[.[] | select(.active == true)]'
Хочешь переформатировать объект и взять только нужные поля:
jq '[.[] | {id:.id, login:.email}]'
Работаешь с вложенными структурами — без проблем:
jq '.data.users[].profile.city'
Самое полезное в реальной жизни: у тебя есть здоровый JSON-лог от какого-нибудь сервиса, и тебе нужно быстро найти все записи с ошибками за последний час. Делаешь это прямо в терминале без Python-скрипта, без Excel, без боли.
cat service.log | jq 'select(.level == "error") | {time:.timestamp, msg:.message}'
Другой сценарий — у тебя Kubernetes и ты хочешь узнать, на каких нодах крутятся поды с определённым лейблом:
kubectl get pods -o json | jq '.items[] | select(.metadata.labels.app == "nginx") |.spec.nodeName'
Или парсишь terraform output и вытаскиваешь конкретные адреса ресурсов. Или смотришь конфиг AWS через CLI и не хочешь читать тысячу строк глазами.
jq умеет ещё: арифметику над полями, строковую интерполяцию, рекурсивный обход через.., работу с env-переменными через --arg, чтение из файла через -f, компактный вывод через -c, raw-строки через -r чтобы убрать кавычки из вывода.
Флаг -r особенно важен когда ты хочешь передать результат дальше в скрипт:
jq -r '.[].id' | xargs -I{} curl -s https://api.example.com/user/{}
Ставится так:
На Debian/Ubuntu: apt install jq
На Arch: pacman -S jq
На Mac: brew install jq
На Alpine: apk add jq
Онлайн-площадка для экспериментов — jqplay.org. Вставляешь JSON, пишешь фильтр, смотришь результат. Удобно когда надо быстро проверить запрос перед тем как вставить в скрипт.
jq кажется простым инструментом, но это обманчивое впечатление. Чем больше ты с ним работаешь, тем больше находишь применений. Это из разряда тех утилит, которые после привыкания ты уже не представляешь как жил без них.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Факт дня из истории Linux и опенсорса.
В 1991 году Линус Торвальдс написал в конференцию comp.os.minix примерно следующее: "Я делаю свободную операционную систему — просто хобби, не будет большой и профессиональной, как GNU". Ему было 21 год, он студент финского универа, и он искренне думал, что пишет маленькую игрушку для себя.
На тот момент у него уже был работающий планировщик задач и базовый драйвер терминала. Ядро умещалось в несколько тысяч строк кода и запускалось только на 386-м процессоре Intel. Торвальдс вообще не думал о портируемости — он писал под конкретное железо, которое стояло у него на столе.
Сейчас ядро Linux содержит около 30 миллионов строк кода. Над ним работают тысячи разработчиков из Intel, Google, Meta, Red Hat, Samsung и сотен других компаний. Оно крутится на андроид-телефонах, серверах, суперкомпьютерах, автомобилях, телевизорах, роутерах и даже на Марсе — вертолёт Ingenuity от NASA летает под управлением системы на ядре Linux.
Отдельный прикол в том, что Торвальдс изначально хотел назвать ядро Freax — гибрид от слов free, freak и unix. Именно под этим именем он загрузил первые файлы на FTP-сервер. Но администратор сервера Ари Лемке без спроса создал для проекта директорию с именем linux, и название прилипло навсегда. Сам Торвальдс поначалу считал это имя слишком самонадеянным.
Так что, если подумать, имя крупнейшей опенсорсной операционки в мире выбрал случайный сисадмин, которому было лень называть папку freax.
Подпишись на создателей: https://t.me/linuxexex
В 1991 году Линус Торвальдс написал в конференцию comp.os.minix примерно следующее: "Я делаю свободную операционную систему — просто хобби, не будет большой и профессиональной, как GNU". Ему было 21 год, он студент финского универа, и он искренне думал, что пишет маленькую игрушку для себя.
На тот момент у него уже был работающий планировщик задач и базовый драйвер терминала. Ядро умещалось в несколько тысяч строк кода и запускалось только на 386-м процессоре Intel. Торвальдс вообще не думал о портируемости — он писал под конкретное железо, которое стояло у него на столе.
Сейчас ядро Linux содержит около 30 миллионов строк кода. Над ним работают тысячи разработчиков из Intel, Google, Meta, Red Hat, Samsung и сотен других компаний. Оно крутится на андроид-телефонах, серверах, суперкомпьютерах, автомобилях, телевизорах, роутерах и даже на Марсе — вертолёт Ingenuity от NASA летает под управлением системы на ядре Linux.
Отдельный прикол в том, что Торвальдс изначально хотел назвать ядро Freax — гибрид от слов free, freak и unix. Именно под этим именем он загрузил первые файлы на FTP-сервер. Но администратор сервера Ари Лемке без спроса создал для проекта директорию с именем linux, и название прилипло навсегда. Сам Торвальдс поначалу считал это имя слишком самонадеянным.
Так что, если подумать, имя крупнейшей опенсорсной операционки в мире выбрал случайный сисадмин, которому было лень называть папку freax.
Подпишись на создателей: https://t.me/linuxexex
Мало кто знает, что первое сообщение Линуса Торвальдса о Linux в 1991 году начиналось со слов "Это просто хобби, оно не будет большим и профессиональным, как GNU". Буквально. Человек вышел в интернет и сказал: не ждите ничего серьёзного, я просто балуюсь.
Конкретно 25 августа 1991 года он написал в newsgroup comp.os.minix сообщение, в котором спросил, что люди хотели бы видеть в Minix. Вот оттуда и пошло. Никакого пафоса, никакого манифеста, никакой революции в заголовке. Просто студент из Хельсинки, которому было скучно, решил написать свою операционную систему потому что Minix его раздражал лицензионными ограничениями, а покупать UNIX было не на что.
Ему было 21 год.
Через два месяца, в октябре того же года, вышла версия 0.02. Она умела запускать bash и gcc. Всё. Больше ничего не работало толком. Но люди уже начали присылать патчи.
Вот что реально странно: Линус выбрал лицензию GPL не потому что был идейным борцом за свободное ПО. Он вообще сначала выпустил Linux под своей собственной лицензией, которая запрещала коммерческое использование. Только в 1992 году он переключился на GPLv2 -- и это решение, принятое почти случайно, в итоге определило то, каким стал весь open source мир. Потому что GPL потребовала от всех, кто брал код, отдавать изменения обратно. Именно это и сделало Linux тем, чем он стал.
Сейчас в ядре Linux более 27 миллионов строк кода. В разработке участвуют тысячи людей из сотен компаний, включая Intel, Google, Red Hat, Samsung. А началось всё с парня, который публично сказал что это несерьёзно и ничего из этого не выйдет.
Иногда лучший способ сделать что-то великое -- это не знать, что ты это делаешь.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Конкретно 25 августа 1991 года он написал в newsgroup comp.os.minix сообщение, в котором спросил, что люди хотели бы видеть в Minix. Вот оттуда и пошло. Никакого пафоса, никакого манифеста, никакой революции в заголовке. Просто студент из Хельсинки, которому было скучно, решил написать свою операционную систему потому что Minix его раздражал лицензионными ограничениями, а покупать UNIX было не на что.
Ему было 21 год.
Через два месяца, в октябре того же года, вышла версия 0.02. Она умела запускать bash и gcc. Всё. Больше ничего не работало толком. Но люди уже начали присылать патчи.
Вот что реально странно: Линус выбрал лицензию GPL не потому что был идейным борцом за свободное ПО. Он вообще сначала выпустил Linux под своей собственной лицензией, которая запрещала коммерческое использование. Только в 1992 году он переключился на GPLv2 -- и это решение, принятое почти случайно, в итоге определило то, каким стал весь open source мир. Потому что GPL потребовала от всех, кто брал код, отдавать изменения обратно. Именно это и сделало Linux тем, чем он стал.
Сейчас в ядре Linux более 27 миллионов строк кода. В разработке участвуют тысячи людей из сотен компаний, включая Intel, Google, Red Hat, Samsung. А началось всё с парня, который публично сказал что это несерьёзно и ничего из этого не выйдет.
Иногда лучший способ сделать что-то великое -- это не знать, что ты это делаешь.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Прорыв может изменить подход к лечению метастатического рака простаты
Исследователи сделали открытие, которое способно перевернуть методы лечения метастатического рака предстательной железы. Новые данные указывают на то, что определённые молекулярные механизмы, ранее считавшиеся второстепенными, на самом деле играют ключевую роль в распространении опухоли по организму.
Метастатический рак простаты остаётся одной из главных причин смертности среди мужчин. На поздних стадиях болезни традиционная гормональная терапия нередко теряет эффективность, и раковые клетки продолжают делиться вопреки лечению. Именно здесь новое открытие может сыграть решающую роль.
Учёные сосредоточились на механизмах устойчивости опухоли к существующим препаратам. Выявленные молекулярные мишени открывают возможность для разработки принципиально новых схем терапии, способных бить по раку там, где он раньше был практически неуязвим.
Если результаты исследования подтвердятся в клинических испытаниях, это может означать реальный сдвиг в онкологии — не очередной косметический апгрейд протоколов, а смену самой логики лечения для пациентов с запущенными формами заболевания.
Источник (r/technews): https://www.reddit.com/r/technews/comments/1vkq6rg/breakthrough_may_change_treatment_for_metastatic/
Подпишись на создателей: https://t.me/linuxexex
Исследователи сделали открытие, которое способно перевернуть методы лечения метастатического рака предстательной железы. Новые данные указывают на то, что определённые молекулярные механизмы, ранее считавшиеся второстепенными, на самом деле играют ключевую роль в распространении опухоли по организму.
Метастатический рак простаты остаётся одной из главных причин смертности среди мужчин. На поздних стадиях болезни традиционная гормональная терапия нередко теряет эффективность, и раковые клетки продолжают делиться вопреки лечению. Именно здесь новое открытие может сыграть решающую роль.
Учёные сосредоточились на механизмах устойчивости опухоли к существующим препаратам. Выявленные молекулярные мишени открывают возможность для разработки принципиально новых схем терапии, способных бить по раку там, где он раньше был практически неуязвим.
Если результаты исследования подтвердятся в клинических испытаниях, это может означать реальный сдвиг в онкологии — не очередной косметический апгрейд протоколов, а смену самой логики лечения для пациентов с запущенными формами заболевания.
Источник (r/technews): https://www.reddit.com/r/technews/comments/1vkq6rg/breakthrough_may_change_treatment_for_metastatic/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the technews community on Reddit: Breakthrough may change treatment for metastatic prostate cancer
Explore this post and more from the technews community
ctrl+r — это штука, которую большинство людей знают, но почти никто не использует по-настоящему.
Находишься в терминале, нужно повторить команду, которую писал час назад. Что делаешь? Жмёшь стрелку вверх и листаешь историю как дурак. Так делают все. И так делать не надо.
Жмёшь ctrl+r — терминал входит в режим обратного поиска по истории. Начинаешь печатать кусок команды — любое слово, флаг, путь — и bash или zsh мгновенно находит последнее вхождение. Нашёл нужное — Enter чтобы выполнить, или стрелка вправо чтобы отредактировать перед запуском. Хочешь следующее совпадение — жмёшь ctrl+r ещё раз.
Это работает из коробки везде: bash, zsh, fish с небольшими отличиями. Никаких плагинов, никаких настроек.
Но это только начало. По умолчанию история в bash хранит 500-1000 строк и не сохраняет дубли. Это мало. Добавь в ~/.bashrc такое:
HISTSIZE=50000
HISTFILESIZE=100000
HISTCONTROL=ignoredups:erasedups
shopt -s histappend
Перезапусти терминал — теперь у тебя десятки тысяч команд в истории без мусора и дублей. ctrl+r начинает работать в полную силу.
Отдельная история — fzf. Это fuzzy finder, который можно повесить на ctrl+r вместо стандартного поиска. Ставится одной командой, интегрируется в shell автоматически. После этого поиск по истории превращается в интерактивный список с нечётким поиском — можно искать по частям слов в любом порядке, сразу видишь все совпадения, выбираешь стрелками.
Поставить fzf:
git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install
Соглашаешься на интеграцию с shell — и ctrl+r теперь другой. Попробовав один раз, к стандартному поиску уже не возвращаешься.
Ещё один момент, который мало кто знает: восклицательный знак в bash — это history expansion. Пишешь!! — вставляется последняя команда. Забыл написать sudo? sudo!! — готово. Пишешь!ssh — выполняется последняя команда, начинавшаяся на ssh. Пишешь!$ — подставляется последний аргумент предыдущей команды.
Создал директорию mkdir /очень/длинный/путь/к/чему-то, хочешь туда перейти — пишешь cd!$ и не повторяешь путь руками.
Это не какие-то хитрые трюки, это базовый инструментарий терминала, который существует десятилетиями. Просто никто не объясняет это в начале пути, и люди годами жмут стрелку вверх там, где можно было сделать за секунду.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Находишься в терминале, нужно повторить команду, которую писал час назад. Что делаешь? Жмёшь стрелку вверх и листаешь историю как дурак. Так делают все. И так делать не надо.
Жмёшь ctrl+r — терминал входит в режим обратного поиска по истории. Начинаешь печатать кусок команды — любое слово, флаг, путь — и bash или zsh мгновенно находит последнее вхождение. Нашёл нужное — Enter чтобы выполнить, или стрелка вправо чтобы отредактировать перед запуском. Хочешь следующее совпадение — жмёшь ctrl+r ещё раз.
Это работает из коробки везде: bash, zsh, fish с небольшими отличиями. Никаких плагинов, никаких настроек.
Но это только начало. По умолчанию история в bash хранит 500-1000 строк и не сохраняет дубли. Это мало. Добавь в ~/.bashrc такое:
HISTSIZE=50000
HISTFILESIZE=100000
HISTCONTROL=ignoredups:erasedups
shopt -s histappend
Перезапусти терминал — теперь у тебя десятки тысяч команд в истории без мусора и дублей. ctrl+r начинает работать в полную силу.
Отдельная история — fzf. Это fuzzy finder, который можно повесить на ctrl+r вместо стандартного поиска. Ставится одной командой, интегрируется в shell автоматически. После этого поиск по истории превращается в интерактивный список с нечётким поиском — можно искать по частям слов в любом порядке, сразу видишь все совпадения, выбираешь стрелками.
Поставить fzf:
git clone --depth 1 https://github.com/junegunn/fzf.git ~/.fzf
~/.fzf/install
Соглашаешься на интеграцию с shell — и ctrl+r теперь другой. Попробовав один раз, к стандартному поиску уже не возвращаешься.
Ещё один момент, который мало кто знает: восклицательный знак в bash — это history expansion. Пишешь!! — вставляется последняя команда. Забыл написать sudo? sudo!! — готово. Пишешь!ssh — выполняется последняя команда, начинавшаяся на ssh. Пишешь!$ — подставляется последний аргумент предыдущей команды.
Создал директорию mkdir /очень/длинный/путь/к/чему-то, хочешь туда перейти — пишешь cd!$ и не повторяешь путь руками.
Это не какие-то хитрые трюки, это базовый инструментарий терминала, который существует десятилетиями. Просто никто не объясняет это в начале пути, и люди годами жмут стрелку вверх там, где можно было сделать за секунду.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Расскажу про одну вещь в bash и zsh, которую большинство людей просто не замечают годами, хотя пользуются шеллом каждый день.
Это parameter expansion с заменой подстрок. Вот смотри.
Есть переменная:
file="backup_2024_server.tar.gz"
Ты хочешь заменить "2024" на "2025". Без sed, без awk, без форка вообще. Прямо в шелле:
echo "${file/2024/2025}"
Получишь backup_2025_server.tar.gz.
Это заменяет первое вхождение. Хочешь заменить все вхождения сразу -- двойной слэш:
str="aababab"
echo "${str//ab/X}"
Получишь aXXX.
Но это ещё цветочки. Вот где начинается настоящая магия.
Удаление префикса:
path="/home/user/projects/myapp"
echo "${path#/home/user/}"
Получишь projects/myapp. Один решётка -- удаляет самый короткий совпадающий префикс.
Двойная решётка -- самый длинный:
echo "${path##*/}"
Получишь myapp. По сути это basename без запуска отдельного процесса.
То же самое с суффиксом через процент:
echo "${file%.tar.gz}"
Получишь backup_2024_server. Это dirname/basename логика прямо в шелле.
Двойной процент -- жадное удаление суффикса:
str="one.two.three"
echo "${str%%.*}"
Получишь one.
Теперь длина строки без wc:
echo "${#file}"
Просто и без лишнего процесса.
Подстрока по позиции:
str="hello world"
echo "${str:6:5}"
Получишь world. Синтаксис: переменная, двоеточие, начало, двоеточие, длина.
Отрицательный индекс работает тоже -- берёт с конца. В bash нужен пробел перед минусом чтобы не спутать с дефолтным значением:
echo "${str: -5}"
Получишь world.
Зачем это знать? Каждый раз когда ты пишешь в скрипте что-то вроде:
result=$(echo "$var" | sed 's/foo/bar/')
ты создаёшь подпроцесс, пайп, тратишь форк. В цикле на тысячах итераций это реально ощутимо. Parameter expansion работает внутри самого шелла, без форков, мгновенно.
В zsh всё это тоже работает, плюс там есть дополнительные флаги через скобочный синтаксис типа ${(U)var} для uppercase, ${(L)var} для lowercase. Bash делает то же самое через ${var^^} и ${var,,}.
Так что следующий раз когда потянешься за sed для простой замены в строке -- вспомни этот пост.
linux.exe | @linuxexe_bot
Подпишись на создателей: https://t.me/linuxexex
Это parameter expansion с заменой подстрок. Вот смотри.
Есть переменная:
file="backup_2024_server.tar.gz"
Ты хочешь заменить "2024" на "2025". Без sed, без awk, без форка вообще. Прямо в шелле:
echo "${file/2024/2025}"
Получишь backup_2025_server.tar.gz.
Это заменяет первое вхождение. Хочешь заменить все вхождения сразу -- двойной слэш:
str="aababab"
echo "${str//ab/X}"
Получишь aXXX.
Но это ещё цветочки. Вот где начинается настоящая магия.
Удаление префикса:
path="/home/user/projects/myapp"
echo "${path#/home/user/}"
Получишь projects/myapp. Один решётка -- удаляет самый короткий совпадающий префикс.
Двойная решётка -- самый длинный:
echo "${path##*/}"
Получишь myapp. По сути это basename без запуска отдельного процесса.
То же самое с суффиксом через процент:
echo "${file%.tar.gz}"
Получишь backup_2024_server. Это dirname/basename логика прямо в шелле.
Двойной процент -- жадное удаление суффикса:
str="one.two.three"
echo "${str%%.*}"
Получишь one.
Теперь длина строки без wc:
echo "${#file}"
Просто и без лишнего процесса.
Подстрока по позиции:
str="hello world"
echo "${str:6:5}"
Получишь world. Синтаксис: переменная, двоеточие, начало, двоеточие, длина.
Отрицательный индекс работает тоже -- берёт с конца. В bash нужен пробел перед минусом чтобы не спутать с дефолтным значением:
echo "${str: -5}"
Получишь world.
Зачем это знать? Каждый раз когда ты пишешь в скрипте что-то вроде:
result=$(echo "$var" | sed 's/foo/bar/')
ты создаёшь подпроцесс, пайп, тратишь форк. В цикле на тысячах итераций это реально ощутимо. Parameter expansion работает внутри самого шелла, без форков, мгновенно.
В zsh всё это тоже работает, плюс там есть дополнительные флаги через скобочный синтаксис типа ${(U)var} для uppercase, ${(L)var} для lowercase. Bash делает то же самое через ${var^^} и ${var,,}.
Так что следующий раз когда потянешься за sed для простой замены в строке -- вспомни этот пост.
linux.exe | @linuxexe_bot
Подпишись на создателей: https://t.me/linuxexex
Какой шанс, что в Switch 2 есть дыра в BootROM?
Нет, серьёзно, давайте в цифрах. Switch 1 взломали именно так — баг в BootROM, прошивка read-only, железо уже в продаже, Nintendo ничего не могла сделать. Непатчуемый хардварный взлом, мечта любого хакера.
Понятно, что Nintendo не дура и после того позора наняла 86 разных контор аудить этот код и фаззила его до полного расплавления мозга. Но вопрос всё равно стоит: какой реальный процент вероятности, что в Switch 2 есть аналогичная дыра в BootROM?
Источник (4chan /g/): https://boards.4chan.org/g/thread/109552989
Подпишись на создателей: https://t.me/linuxexex
Нет, серьёзно, давайте в цифрах. Switch 1 взломали именно так — баг в BootROM, прошивка read-only, железо уже в продаже, Nintendo ничего не могла сделать. Непатчуемый хардварный взлом, мечта любого хакера.
Понятно, что Nintendo не дура и после того позора наняла 86 разных контор аудить этот код и фаззила его до полного расплавления мозга. Но вопрос всё равно стоит: какой реальный процент вероятности, что в Switch 2 есть аналогичная дыра в BootROM?
Источник (4chan /g/): https://boards.4chan.org/g/thread/109552989
Подпишись на создателей: https://t.me/linuxexex
boards.4chan.org
/g/ - What are the chances there's an exploitable ARM Bo - Technology - 4chan
What are the chances there's an exploitable ARM BootROM bug in the Switch 2? I m - "/g/ - Technology" is 4chan's imageboard for discussing computer hardware and software, programming, and general technology.
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