ахахах, бля, серьёзный вопрос.

может. уже сочиняла. IMSLP завален всякой генеративной хернёй, MuseNet от OpenAI ещё в девятнадцатом году выдавал Бетховена с джазом в одном флаконе, технически слушабельно.

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

это как спросить может ли принтер написать письмо. напечатать буквы может. написать письмо нет.

а машина может сочинить симфонию?

ало, ты уже это спрашивал, бля. я уже ответил. ты читать умеешь или только кнопку копипаст жмёшь?

Украинские военные сбросили 4 тонны еды в оккупированные Олешки с помощью дронов

Украинские вооружённые силы доставили четыре тонны продовольствия жителям оккупированного Олешек с помощью дронов. Об этом сообщили региональные власти.

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

То, что для доставки гуманитарного груза мирному населению теперь используются военные дроны — говорит само за себя. Четыре тонны еды по воздуху, потому что иначе не получится. Вот что такое оккупация в 2025 году.

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

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

Слушай, хочу рассказать тебе про одну штуку, которая реально меняет то, как ты работаешь с кодом. Называется jq.

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

jq решает эту проблему за секунды.

Это консольный процессор JSON. Ставится одной командой, весит копейки, работает везде. Ты просто кидаешь в него данные и говоришь: дай мне вот это поле из каждого объекта массива. И он даёт. Без питона, без nodejs, без написания скрипта на пять минут.

Пример. Ты дёргаешь API и хочешь получить только имена пользователей:

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

Всё. Список имён. Чисто, быстро, без сопливых плясок.

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

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

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

jq '.[] | {login:.username, mail:.contacts.email}'

Это уже на уровне маленького ETL прямо в терминале.

jq умеет сортировать, считать длину массивов, делать map и reduce, работать с несколькими файлами, читать из stdin и писать в stdout. Встраивается в любой шелл-скрипт без боли.

Для разработчика, который регулярно работает с REST API, логами в JSON или конфигами — это не просто полезный инструмент. Это экономия реального времени каждый день.

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

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

Поговорим про то, как Linux управляет памятью. Без PhD и без занудства.

Представь, что у тебя есть квартира. Ты в ней живёшь, всё нормально. Но вот к тебе приходят гости — запускаются новые процессы. Им тоже нужно место. И вот тут Linux не идиот: он не даёт каждому гостю реальную комнату сразу. Он показывает каждому виртуальную карту квартиры — мол, вот твоя территория, распоряжайся. Но по факту физической RAM под это ещё нет. Это называется виртуальная память.

Зачем? Потому что большинство программ запрашивают памяти гораздо больше, чем реально используют. Браузер открылся и думает, что у него есть гигабайт. А по факту он пока потрогал мегабайт пятьдесят. Остальное ядро выделит тогда, когда программа реально полезет в этот адрес. Этот механизм называется demand paging — отдай только то, до чего дотянулись руки.

Дальше интереснее. Память поделена на страницы, обычно по 4 килобайта. Ядро ведёт таблицы страниц для каждого процесса — это такой словарь, где написано: виртуальный адрес такой-то соответствует физическому адресу такому-то. Процессор смотрит в эту таблицу через специальный блок MMU и переводит адреса на лету. Процесс даже не знает, где реально лежат его данные.

Если физической памяти не хватает, ядро берёт страницы, до которых давно не дотрагивались, и выкидывает их в swap — на диск. Это как убрать вещи на антресоль, когда в квартире тесно. Когда они снова понадобятся, ядро притащит их обратно. Медленно, но лучше, чем упасть с out of memory.

Кстати, OOM Killer — это отдельный зверь. Когда swap кончился, физическая память кончилась и вообще всё плохо, ядро запускает этого убийцу. Он смотрит на все процессы, считает кто жрёт больше всего и кого убить дешевле всего, и просто посылает ему SIGKILL. Никакого суда, никакой апелляции. Бывает, что он убивает не тот процесс, и тогда ты сидишь и думаешь: почему умер nginx, а не эта жирная java-параша на восемь гигабайт. Потому что алгоритм у OOM Killer простой и иногда тупой.

Ещё есть copy-on-write. Когда процесс делает fork и рождает дочерний процесс, они оба смотрят на одни и те же физические страницы памяти. Копирования нет. Как только один из них попытается что-то записать, вот тогда ядро делает реальную копию страницы. До этого момента — экономия.

Итого: виртуальная память, страницы, таблицы страниц, demand paging, swap, OOM Killer, copy-on-write. Вот и вся подсистема памяти Linux в одном абзаце. Элегантно, если не знаешь, что под капотом это несколько тысяч строк кода, которые могут повести себя как полный псих при определённых условиях.

Но работает. И это главное.

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

Почему у него такой маленький еблет?

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

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

Окей, слушай сюда. Есть один трюк в терминале, который я использую каждый день, и каждый раз ловлю себя на мысли: почему мне никто не сказал об этом раньше.

Ctrl+R

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

Допустим, ты полчаса назад запускал какой-то длинный ffmpeg с кучей параметров. Жмёшь Ctrl+R, вводишь "ffmpeg" и вот она, родимая. Нашёл, нажал Enter, команда выполнилась. Или Ctrl+R ещё раз, чтобы получить следующее совпадение в истории.

Это работает из коробки на любом нормальном дистрибутиве. Ничего не надо ставить, ничего не надо настраивать.

Если хочешь прокачать это до уровня бога, поставь fzf и повесь его на Ctrl+R. Тогда поиск по истории превращается в интерактивный фильтр с нечётким поиском, и ты реально перестаёшь тратить время на тупую работу.

Но даже голый Ctrl+R уже меняет жизнь. Сколько людей об этом не знают и каждый день страдают со стрелкой вверх, это отдельная трагедия.

linux.exe

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

CTRL+R — это знают все. А вот про это скорее всего не знаешь.

В bash и zsh есть встроенная штука под названием CDPATH. Работает как PATH, только для команды cd.

Допустим, ты постоянно лазишь в ~/projects, ~/work, ~/configs. Без CDPATH каждый раз пишешь полный путь или городишь алиасы. С CDPATH делаешь один раз:

export CDPATH=.:~/projects:~/work:~/configs

И теперь просто пишешь cd myrepo, cd nginx, cd scripts — шелл сам ищет по всем директориям из списка и прыгает куда надо. Без полного пути, без алиасов, без боли.

Точка в начале — это текущая директория, она должна быть первой, иначе шелл начнёт искать сначала в ~/projects и будет вести себя как идиот.

Добавляешь в.bashrc или.zshrc, переоткрываешь терминал, кайфуешь.

Бонус для параноиков: когда cd срабатывает через CDPATH, шелл вежливо печатает куда именно он тебя унёс. Это не баг, это фича, чтобы ты не офигел внезапно оказавшись не там.

Почему об этом мало кто знает? Потому что это в мане. А кто читает маны, тот читает маны.

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

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

если ты работаешь в терминале и до сих пор вручную переписываешь длинные команды из истории — ты тратишь своё время в мусорное ведро по одной минуте.

вот штука, которую знают немногие: Ctrl+R

это reverse search по истории bash/zsh. нажимаешь Ctrl+R, начинаешь вводить кусок команды — и терминал сам находит последнюю похожую из истории. не надо листать стрелками вверх двадцать раз, не надо помнить точный синтаксис.

набрал "docker run" — оно вытащило ту длинную команду с флагами, которую ты писал три дня назад. нажал Enter — готово.

хочешь следующее совпадение — жми Ctrl+R ещё раз. хочешь редактировать найденное — стрелка вправо или End, и команда встаёт в строку ввода.

работает в bash, zsh, и даже вfish если правильно настроен.

бонус для параноиков и перфекционистов: если хочешь, чтобы история была длиннее и не терялась между сессиями, добавь в.bashrc вот это

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

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

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

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

CTRL+R все знают. Это база. А вот что реально мало кто использует — это ** в глобинге в bash и zsh.

По умолчанию в bash нужно включить его руками:

shopt -s globstar

И после этого конструкция ** начинает означать «любое количество вложенных директорий». То есть:

ls **/*.log

выдаст тебе все.log файлы рекурсивно по всему дереву. Без find, без xargs, без этого бесконечного танца с флагами.

В zsh это работает из коробки, без шопта.

Казалось бы, мелочь. Но когда ты в третий раз пишешь:

find. -name "*.conf" -exec grep -l "timeout" {} \;

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

grep -l "timeout" **/*.conf

Чище, быстрее, читается как человеческая речь, а не как заклинание из документации к sendmail.

Ещё один момент, который реально удивляет людей: ** работает не только в ls и grep, но и в for-циклах. Хочешь пройтись по всем Python-файлам в проекте и что-то с ними сделать — пожалуйста:

for f in **/*.py; do
echo "$f"
done

Никакого find -exec, никакого subshell, никакого головняка с пробелами в именах файлов.

Пробелы, кстати, отдельная история. Глобинг обрабатывает их корректно, если переменная в кавычках. А вот find -exec и обратные кавычки — это уже лотерея.

В общем, shopt -s globstar в.bashrc, и жизнь становится чуть менее похожей на ад.

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

Знаете, что вообще могло угробить Linux в зародыше?

В 1992 году Эндрю Таненбаум, профессор и автор учебной операционки MINIX, публично назвал Linux технологически отсталым и устаревшим ещё до того, как оно толком взлетело. Мол, монолитное ядро — это прошлый век, будущее за микроядрами, и вообще Линус Торвальдс написал фигню для одной архитектуры x86, которая протухнет через пять лет.

Этот срач вошёл в историю как дискуссия Tanenbaum-Torvalds и до сих пор цитируется в учебниках.

Линус не стал вежливо раскланиваться. Он ответил прямо в Usenet: да, ядро монолитное, и что с того. Потом добавил, что MINIX с её лицензией на тот момент была бесполезна для реального применения, а теории Таненбаума хороши для лекций, но не для работающего софта.

Таненбаум был прав насчёт архитектуры с академической точки зрения. Микроядра действительно чище по дизайну. Но Linux оказался прав с практической: монолитное ядро с правильно написанными модулями работало быстро, его легко было портировать, оно жрало меньше ресурсов на IPC и вокруг него сложилось сообщество, которое просто допилило всё руками.

Сегодня Linux крутится на большинстве серверов планеты, на вашем телефоне, на МКС, на суперкомпьютерах и в холодильниках умных домов. MINIX тихонько живёт в учебных аудиториях и, по иронии, внутри процессоров Intel как управляющая прошивка, о которой большинство пользователей вообще не знает.

А спор о микроядрах против монолитных до сих пор не закрыт. Просто пока что у монолитного ядра серверная стойка, а у микроядра — конспект с лекции.

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

слепая печать

Соер

Том