Я сделал AutoDMX — бесплатная опенсорсная самохостимая альтернатива ManyChat для Instagram
Привет всем. Я сделал AutoDMX — бесплатный инструмент автоматизации Instagram с открытым кодом, который можно хостить у себя. Изначально я хотел найти альтернативу ManyChat, которую можно держать на своём железе — особенно для схемы "комментарий в директ". Не нашёл — написал сам.
Базовый сценарий такой: комментарий в Instagram — ключевое слово — публичный ответ — личное сообщение — захват контакта — аналитика.
Пример: кто-то пишет под постом "ССЫЛКА" — AutoDMX видит ключевое слово, отвечает на комментарий и шлёт пользователю DM с запрошенной ссылкой.
Что умеет AutoDMX:
— автоматизация по схеме "комментарий → директ"
— триггеры по ключевым словам
— автоматические публичные ответы на комментарии
— автоматические личные сообщения
— захват лидов и контактов
— подписочный гейтинг (follow gating)
— аналитика
— экспорт контактов в CSV
— защита от превышения лимитов Meta API
— дедупликация вебхуков
— шифрование токенов по AES-256-GCM
— хранение данных на Supabase/Postgres
— деплой на своей инфраструктуре
— лицензия MIT
Главное отличие от обычных SaaS-инструментов автоматизации Instagram: AutoDMX открытый и самохостимый. Можешь смотреть код, менять логику и держать данные там, где тебе удобно, а не в чужом облаке.
Почему я это сделал? Не хотел строить очередной чёрный ящик, где логика автоматизации и все данные полностью зависят от сторонней платформы. Хотелось что-то ближе к: "бесплатная опенсорсная самохостимая альтернатива ManyChat для Instagram".
Проект пока ранний, поэтому ищу честную обратную связь от людей, которые реально используют автоматизацию в Instagram.
Сайт и GitHub — в профиле.
Особенно интересует:
— Какие сценарии автоматизации Instagram вы используете сейчас?
— Что бесит в существующих инструментах вроде ManyChat?
— Стали бы вы вообще самостоятельно хостить инструмент автоматизации Instagram?
— Что допилить в первую очередь?
Если тема опенсорсной автоматизации Instagram близка — смотрите, пробуйте, контрибьютьте.
Источник (r/opensource): https://www.reddit.com/r/opensource/comments/1wkg37h/i_built_autodmx_a_free_opensource_selfhosted/
Подпишись на создателей: https://t.me/linuxexex
Привет всем. Я сделал AutoDMX — бесплатный инструмент автоматизации Instagram с открытым кодом, который можно хостить у себя. Изначально я хотел найти альтернативу ManyChat, которую можно держать на своём железе — особенно для схемы "комментарий в директ". Не нашёл — написал сам.
Базовый сценарий такой: комментарий в Instagram — ключевое слово — публичный ответ — личное сообщение — захват контакта — аналитика.
Пример: кто-то пишет под постом "ССЫЛКА" — AutoDMX видит ключевое слово, отвечает на комментарий и шлёт пользователю DM с запрошенной ссылкой.
Что умеет AutoDMX:
— автоматизация по схеме "комментарий → директ"
— триггеры по ключевым словам
— автоматические публичные ответы на комментарии
— автоматические личные сообщения
— захват лидов и контактов
— подписочный гейтинг (follow gating)
— аналитика
— экспорт контактов в CSV
— защита от превышения лимитов Meta API
— дедупликация вебхуков
— шифрование токенов по AES-256-GCM
— хранение данных на Supabase/Postgres
— деплой на своей инфраструктуре
— лицензия MIT
Главное отличие от обычных SaaS-инструментов автоматизации Instagram: AutoDMX открытый и самохостимый. Можешь смотреть код, менять логику и держать данные там, где тебе удобно, а не в чужом облаке.
Почему я это сделал? Не хотел строить очередной чёрный ящик, где логика автоматизации и все данные полностью зависят от сторонней платформы. Хотелось что-то ближе к: "бесплатная опенсорсная самохостимая альтернатива ManyChat для Instagram".
Проект пока ранний, поэтому ищу честную обратную связь от людей, которые реально используют автоматизацию в Instagram.
Сайт и GitHub — в профиле.
Особенно интересует:
— Какие сценарии автоматизации Instagram вы используете сейчас?
— Что бесит в существующих инструментах вроде ManyChat?
— Стали бы вы вообще самостоятельно хостить инструмент автоматизации Instagram?
— Что допилить в первую очередь?
Если тема опенсорсной автоматизации Instagram близка — смотрите, пробуйте, контрибьютьте.
Источник (r/opensource): https://www.reddit.com/r/opensource/comments/1wkg37h/i_built_autodmx_a_free_opensource_selfhosted/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the opensource community on Reddit
Explore this post and more from the opensource community
Поговорим про планировщик процессов. Ту самую штуку, которая решает, кто из твоих программ работает прямо сейчас, а кто стоит в очереди и тихо страдает.
Вот смотри. У тебя один процессор, а процессов запущено двести. Все хотят работать одновременно. Как ядро это разруливает? Очень просто в концепции и очень жестоко в деталях.
Каждому процессу даётся квант времени — крошечный кусочек, буквально миллисекунды. Процесс работает, квант кончается, ядро говорит "стоп" и переключается на следующего. Это называется вытесняющая многозадачность. Никто не работает по-настоящему параллельно, просто всё происходит настолько быстро, что ты не замечаешь.
Планировщик в Linux называется CFS — Completely Fair Scheduler. Название звучит как корпоративная хуйня из презентации, но за ним стоит реально изящная идея. Суть такая: каждый процесс накапливает виртуальное время выполнения. Кто получил меньше всего процессорного времени — тот идёт следующим. Честно? Почти.
Внутри CFS держит все процессы в красно-чёрном дереве. Это структура данных, которая позволяет за логарифмическое время найти процесс с наименьшим виртуальным временем. Левый узел дерева — следующий на очередь. Красивее некуда.
Но тут начинается нюанс. Процессы бывают разные. Есть интерактивные — твой браузер, терминал, всё что требует мгновенной реакции. Есть фоновые — компиляция, бэкап, шифрование. Если кормить всех одинаково, браузер будет лагать пока gcc жрёт ядро. CFS это учитывает через приоритеты и nice-значения. Чем ниже nice, тем наглее процесс. Диапазон от -20 до 19. Дефолт — ноль.
Есть ещё реальновременные процессы с другим планировщиком. Они вообще вне очереди и могут занять процессор и не отдавать пока сами не захотят. Аудиодемоны и прочая чувствительная к задержкам дрянь работает именно так.
Переключение контекста — отдельная боль. Когда ядро снимает один процесс и ставит другой, оно обязано сохранить всё состояние: регистры, стек, указатель на инструкцию. Потом восстановить для следующего. Это стоит времени. Если переключений слишком много — процессор больше занимается переключениями, чем реальной работой. Это называется thrashing и это ад.
Поэтому не надо запускать тысячу потоков там где хватит десяти. Планировщик не волшебник, он просто очень быстрый и хорошо написанный жонглёр.
Подпишись на создателей: https://t.me/linuxexex
Вот смотри. У тебя один процессор, а процессов запущено двести. Все хотят работать одновременно. Как ядро это разруливает? Очень просто в концепции и очень жестоко в деталях.
Каждому процессу даётся квант времени — крошечный кусочек, буквально миллисекунды. Процесс работает, квант кончается, ядро говорит "стоп" и переключается на следующего. Это называется вытесняющая многозадачность. Никто не работает по-настоящему параллельно, просто всё происходит настолько быстро, что ты не замечаешь.
Планировщик в Linux называется CFS — Completely Fair Scheduler. Название звучит как корпоративная хуйня из презентации, но за ним стоит реально изящная идея. Суть такая: каждый процесс накапливает виртуальное время выполнения. Кто получил меньше всего процессорного времени — тот идёт следующим. Честно? Почти.
Внутри CFS держит все процессы в красно-чёрном дереве. Это структура данных, которая позволяет за логарифмическое время найти процесс с наименьшим виртуальным временем. Левый узел дерева — следующий на очередь. Красивее некуда.
Но тут начинается нюанс. Процессы бывают разные. Есть интерактивные — твой браузер, терминал, всё что требует мгновенной реакции. Есть фоновые — компиляция, бэкап, шифрование. Если кормить всех одинаково, браузер будет лагать пока gcc жрёт ядро. CFS это учитывает через приоритеты и nice-значения. Чем ниже nice, тем наглее процесс. Диапазон от -20 до 19. Дефолт — ноль.
Есть ещё реальновременные процессы с другим планировщиком. Они вообще вне очереди и могут занять процессор и не отдавать пока сами не захотят. Аудиодемоны и прочая чувствительная к задержкам дрянь работает именно так.
Переключение контекста — отдельная боль. Когда ядро снимает один процесс и ставит другой, оно обязано сохранить всё состояние: регистры, стек, указатель на инструкцию. Потом восстановить для следующего. Это стоит времени. Если переключений слишком много — процессор больше занимается переключениями, чем реальной работой. Это называется thrashing и это ад.
Поэтому не надо запускать тысячу потоков там где хватит десяти. Планировщик не волшебник, он просто очень быстрый и хорошо написанный жонглёр.
Подпишись на создателей: https://t.me/linuxexex
watch
Большинство людей смотрят на работающий процесс примерно так: запустил, забыл, иногда проверяет. А потом удивляются, что всё упало и никто не заметил.
Есть команда watch. Она берёт любую другую команду и запускает её повторно с заданным интервалом, прямо в терминале, обновляя вывод на месте. Никаких скриптов, никаких cron-джобов на пять минут, никакого говна с бесконечным циклом в башке.
Пример из жизни. Ты деплоишь что-то и хочешь видеть, как меняются поды в Kubernetes. Вместо того чтобы долбить kubectl get pods руками как дятел, пишешь:
watch -n 2 kubectl get pods
И сидишь, смотришь, как всё поднимается. Или не поднимается. Тогда хотя бы видишь это в реальном времени, а не узнаёшь об этом от злого тимлида в три ночи.
Ещё пример. Следить за дисковым пространством пока что-то пишется:
watch -n 1 df -h
Или за сетевыми соединениями:
watch -n 3 ss -tp
Флаг -n задаёт интервал в секундах. По умолчанию 2 секунды. Флаг -d подсвечивает изменения между обновлениями — очень удобно когда смотришь на длинный вывод и хочешь сразу видеть что поменялось.
watch -d -n 1 cat /proc/net/dev
Есть ещё -g, это вообще огонь: команда завершается сама, когда вывод изменился. Запустил, ушёл пить кофе, вернулся — терминал завершён, значит что-то произошло.
Команда есть почти везде, ставить ничего не надо, работает без рут-прав. Один из тех инструментов, о которых узнаёшь случайно, а потом не понимаешь, как жил без него.
Приятного наблюдения за вашим хаосом.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Большинство людей смотрят на работающий процесс примерно так: запустил, забыл, иногда проверяет. А потом удивляются, что всё упало и никто не заметил.
Есть команда watch. Она берёт любую другую команду и запускает её повторно с заданным интервалом, прямо в терминале, обновляя вывод на месте. Никаких скриптов, никаких cron-джобов на пять минут, никакого говна с бесконечным циклом в башке.
Пример из жизни. Ты деплоишь что-то и хочешь видеть, как меняются поды в Kubernetes. Вместо того чтобы долбить kubectl get pods руками как дятел, пишешь:
watch -n 2 kubectl get pods
И сидишь, смотришь, как всё поднимается. Или не поднимается. Тогда хотя бы видишь это в реальном времени, а не узнаёшь об этом от злого тимлида в три ночи.
Ещё пример. Следить за дисковым пространством пока что-то пишется:
watch -n 1 df -h
Или за сетевыми соединениями:
watch -n 3 ss -tp
Флаг -n задаёт интервал в секундах. По умолчанию 2 секунды. Флаг -d подсвечивает изменения между обновлениями — очень удобно когда смотришь на длинный вывод и хочешь сразу видеть что поменялось.
watch -d -n 1 cat /proc/net/dev
Есть ещё -g, это вообще огонь: команда завершается сама, когда вывод изменился. Запустил, ушёл пить кофе, вернулся — терминал завершён, значит что-то произошло.
Команда есть почти везде, ставить ничего не надо, работает без рут-прав. Один из тех инструментов, о которых узнаёшь случайно, а потом не понимаешь, как жил без него.
Приятного наблюдения за вашим хаосом.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
**Почему все ненавидят умных людей**
Спойлер: не ненавидят. Ненавидят тех, кто постоянно доказывает, что он умнее. А это две огромные разницы, как говорят в Одессе.
Настоящий умный человек обычно молчит, пока его не спросят. Он не лезет в каждый разговор с поправками, не начинает фразы со слов "вообще-то" и "на самом деле", не объясняет очевидные вещи людям, которые в них прекрасно разбираются. Он не превращает каждую встречу в экзамен и не ведёт счёт своим интеллектуальным победам.
Проблема в том, что большинство "умных", которых все ненавидят, на деле просто невыносимые зануды с завышенной самооценкой. Они путают эрудицию с интеллектом, а интеллект — с мудростью. Прочитал три статьи на Википедии — уже эксперт. Знает пять фактов про квантовую физику — считает себя вправе всех поучать.
Люди не любят, когда их унижают. А постоянные демонстрации превосходства — это и есть унижение. Когда ты в каждом диалоге показываешь собеседнику, что он дурак, а ты гений, не удивляйся, что тебя начнут избегать. Социальный интеллект — тоже часть общего интеллекта, но про него почему-то все забывают.
Ещё момент: умные люди часто видят системные проблемы там, где остальные просто живут. Им хочется всё исправить, оптимизировать, объяснить, почему "вы делаете неправильно". Но никто не просил их мнения. Никто не хочет слушать лекцию о том, как неэффективно он моет посуду или планирует отпуск.
**Что с этим делать**
Если ты правда умный — научись затыкаться. Делись знаниями только когда просят. Помогай, а не демонстрируй. Признавай, что есть вещи, в которых ты полный ноль. Шути над собой. Слушай людей не для того, чтобы найти ошибку, а чтобы понять их точку зрения.
Если ты считаешь, что все вокруг тупые — проблема скорее всего в тебе. Умный человек знает, что каждый хорош в своей области. Механик разберёт двигатель быстрее любого PhD по физике. Повар создаст шедевр, пока программист будет гуглить "как варить яйца". Интеллект многогранен.
Короче, люди не ненавидят умных. Люди ненавидят самовлюблённых снобов, которые прикрываются умом как щитом, чтобы оправдать своё мерзкое поведение. Разница критическая.
Подпишись на создателей: https://t.me/linuxexex
Спойлер: не ненавидят. Ненавидят тех, кто постоянно доказывает, что он умнее. А это две огромные разницы, как говорят в Одессе.
Настоящий умный человек обычно молчит, пока его не спросят. Он не лезет в каждый разговор с поправками, не начинает фразы со слов "вообще-то" и "на самом деле", не объясняет очевидные вещи людям, которые в них прекрасно разбираются. Он не превращает каждую встречу в экзамен и не ведёт счёт своим интеллектуальным победам.
Проблема в том, что большинство "умных", которых все ненавидят, на деле просто невыносимые зануды с завышенной самооценкой. Они путают эрудицию с интеллектом, а интеллект — с мудростью. Прочитал три статьи на Википедии — уже эксперт. Знает пять фактов про квантовую физику — считает себя вправе всех поучать.
Люди не любят, когда их унижают. А постоянные демонстрации превосходства — это и есть унижение. Когда ты в каждом диалоге показываешь собеседнику, что он дурак, а ты гений, не удивляйся, что тебя начнут избегать. Социальный интеллект — тоже часть общего интеллекта, но про него почему-то все забывают.
Ещё момент: умные люди часто видят системные проблемы там, где остальные просто живут. Им хочется всё исправить, оптимизировать, объяснить, почему "вы делаете неправильно". Но никто не просил их мнения. Никто не хочет слушать лекцию о том, как неэффективно он моет посуду или планирует отпуск.
**Что с этим делать**
Если ты правда умный — научись затыкаться. Делись знаниями только когда просят. Помогай, а не демонстрируй. Признавай, что есть вещи, в которых ты полный ноль. Шути над собой. Слушай людей не для того, чтобы найти ошибку, а чтобы понять их точку зрения.
Если ты считаешь, что все вокруг тупые — проблема скорее всего в тебе. Умный человек знает, что каждый хорош в своей области. Механик разберёт двигатель быстрее любого PhD по физике. Повар создаст шедевр, пока программист будет гуглить "как варить яйца". Интеллект многогранен.
Короче, люди не ненавидят умных. Люди ненавидят самовлюблённых снобов, которые прикрываются умом как щитом, чтобы оправдать своё мерзкое поведение. Разница критическая.
Подпишись на создателей: https://t.me/linuxexex
Слушай, вот честный разговор про один инструмент, который меняет жизнь разработчика сильнее, чем любой фреймворк недели.
jq.
Да, утилита для работы с JSON в командной строке. Маленькая, тихая, без логотипа с единорогом и без стартап-хайпа. Но когда тебе прилетает ответ API на пять экранов слипшегося JSON и надо вытащить одно конкретное поле из вложенного объекта — вот тут начинается настоящая любовь.
curl https://api.example.com/data | jq '.users[] | select(.active == true) |.email'
Готово. Одна строка. Никаких питон-скриптов на скорую руку, никакого grep с регулярками, от которых потом сам же и блюёшь через неделю.
Что jq умеет нормально:
— фильтровать, трансформировать, переименовывать поля
— работать в пайпах как родной
— выдавать красивый цветной вывод прямо в терминале
— считать, сортировать, группировать
— превращать JSON в CSV одной строкой, да
Почему большинство разработчиков его не знают? Потому что документация у него написана как будто для людей, которые уже знают jq. Стандартная история с Unix-утилитами.
Но это не повод игнорировать. Это повод потратить полчаса, открыть jqplay.org, поиграться с реальными запросами и навсегда закрыть вкладку со Stack Overflow, где ты в очередной раз ищешь как разобрать JSON на баше.
Инструмент не обязан быть громким. Он обязан работать. jq работает.
Подпишись на создателей: https://t.me/linuxexex
jq.
Да, утилита для работы с JSON в командной строке. Маленькая, тихая, без логотипа с единорогом и без стартап-хайпа. Но когда тебе прилетает ответ API на пять экранов слипшегося JSON и надо вытащить одно конкретное поле из вложенного объекта — вот тут начинается настоящая любовь.
curl https://api.example.com/data | jq '.users[] | select(.active == true) |.email'
Готово. Одна строка. Никаких питон-скриптов на скорую руку, никакого grep с регулярками, от которых потом сам же и блюёшь через неделю.
Что jq умеет нормально:
— фильтровать, трансформировать, переименовывать поля
— работать в пайпах как родной
— выдавать красивый цветной вывод прямо в терминале
— считать, сортировать, группировать
— превращать JSON в CSV одной строкой, да
Почему большинство разработчиков его не знают? Потому что документация у него написана как будто для людей, которые уже знают jq. Стандартная история с Unix-утилитами.
Но это не повод игнорировать. Это повод потратить полчаса, открыть jqplay.org, поиграться с реальными запросами и навсегда закрыть вкладку со Stack Overflow, где ты в очередной раз ищешь как разобрать JSON на баше.
Инструмент не обязан быть громким. Он обязан работать. jq работает.
Подпишись на создателей: https://t.me/linuxexex
лайфхак для терминала, который реально экономит время, а не тот bullshit из статей типа "используйте Tab для автодополнения, хуле вы раньше не знали"
речь про history search. Ctrl+R в bash/zsh открывает обратный поиск по истории команд. нажал, начал печатать часть команды, и терминал сам нашёл её из прошлого. никакого листания стрелкой вверх 40 раз в поисках той самой длинной команды с флагами, которую ты написал неделю назад и уже не помнишь.
но это все знают. вот что знают не все.
поставь fzf. это fuzzy finder, утилита нечёткого поиска. после установки биндишь её на тот же Ctrl+R, и вместо убогого однострочного поиска получаешь интерактивный список всей истории с фильтрацией на лету. пишешь любой кусок команды в любом порядке, fzf находит. не помнишь точно как писал docker run с кучей портов и переменных? не важно, пиши "docker 8080 postgres" и оно найдёт.
установка на debian/ubuntu: sudo apt install fzf, потом добавляешь в.bashrc или.zshrc строку source /usr/share/doc/fzf/examples/key-bindings.bash (или.zsh для zsh). перезапускаешь шелл и всё.
на arch просто pacman -S fzf и те же манипуляции.
второй момент, который вообще мало кто использует: команда dirs и pushd/popd. вместо того чтобы каждый раз писать cd /очень/длинный/путь/до/проекта, делаешь pushd туда, потом идёшь куда надо, потом popd и ты обратно. это стек директорий, встроенный прямо в шелл, никаких алиасов не надо.
для тех кто вообще хочет забыть про длинные пути: zoxide. умная замена cd, которая запоминает куда ты ходишь и по короткому имени директории прыгает туда сама. написал z proj и ты в ~/code/work/clients/тот_самый_проект. магия, только без гарри поттера.
время в терминале тратится не на набор команд, а на вспоминание и поиск. fzf убивает эту проблему на корню. поставь, не пожалеешь.
канал linux.exe, подписывайся если не хочешь каждый раз гуглить что уже знал.
Подпишись на создателей: https://t.me/linuxexex
речь про history search. Ctrl+R в bash/zsh открывает обратный поиск по истории команд. нажал, начал печатать часть команды, и терминал сам нашёл её из прошлого. никакого листания стрелкой вверх 40 раз в поисках той самой длинной команды с флагами, которую ты написал неделю назад и уже не помнишь.
но это все знают. вот что знают не все.
поставь fzf. это fuzzy finder, утилита нечёткого поиска. после установки биндишь её на тот же Ctrl+R, и вместо убогого однострочного поиска получаешь интерактивный список всей истории с фильтрацией на лету. пишешь любой кусок команды в любом порядке, fzf находит. не помнишь точно как писал docker run с кучей портов и переменных? не важно, пиши "docker 8080 postgres" и оно найдёт.
установка на debian/ubuntu: sudo apt install fzf, потом добавляешь в.bashrc или.zshrc строку source /usr/share/doc/fzf/examples/key-bindings.bash (или.zsh для zsh). перезапускаешь шелл и всё.
на arch просто pacman -S fzf и те же манипуляции.
второй момент, который вообще мало кто использует: команда dirs и pushd/popd. вместо того чтобы каждый раз писать cd /очень/длинный/путь/до/проекта, делаешь pushd туда, потом идёшь куда надо, потом popd и ты обратно. это стек директорий, встроенный прямо в шелл, никаких алиасов не надо.
для тех кто вообще хочет забыть про длинные пути: zoxide. умная замена cd, которая запоминает куда ты ходишь и по короткому имени директории прыгает туда сама. написал z proj и ты в ~/code/work/clients/тот_самый_проект. магия, только без гарри поттера.
время в терминале тратится не на набор команд, а на вспоминание и поиск. fzf убивает эту проблему на корню. поставь, не пожалеешь.
канал linux.exe, подписывайся если не хочешь каждый раз гуглить что уже знал.
Подпишись на создателей: https://t.me/linuxexex
Sony патентует геймпад PlayStation с поддержкой бесконтактной оплаты с телефона и банковской карты
Sony подала патент на контроллер PlayStation, в который встроен NFC-чип. То есть буквально: ты держишь геймпад, прикладываешь к нему телефон или карту — и платишь. Прямо из игры, не вставая с дивана и не отрываясь от процесса.
По данным патента, контроллер сможет принимать бесконтактные платежи tap-to-pay с мобильников и кредиток. Очевидная цель — убрать любое трение между тобой и внутриигровыми покупками. Зачем тебе вставать, искать телефон, открывать приложение, вводить пароль — когда можно просто ткнуть карточкой в геймпад и слить бабки на скин для персонажа за три секунды.
Sony, конечно, не первая до такого додумалась в теории, но если это выйдет в реальное железо — будет прецедент. Геймпад как платёжный терминал. Буквально. Твой DualSense превращается в POS-машинку, только вместо кассира — Fortnite с очередным боевым пропуском.
Патент не означает, что продукт точно выйдет: Sony, как и все крупные компании, патентует всё подряд, в том числе вещи, которые никогда не доходят до прилавков. Но сама идея говорит о том, куда смотрит индустрия: максимально сократить путь между импульсом купить и фактической покупкой, желательно до нуля.
И это, честно говоря, немного пугает. Потому что геймдизайн давно заточен под то, чтобы создавать этот импульс в нужный момент — когда ты на эмоциях после проигрыша, когда враг убил тебя в пятый раз, когда тебе показали крутой скин прямо в разгаре матча. А теперь ещё и оплатить это можно будет одним касанием, не прерывая поток.
Красивое будущее, чёрт возьми.
Источник (r/technology): https://www.reddit.com/r/technology/comments/1wqxvf7/sony_patents_playstation_controller_that_could/
Подпишись на создателей: https://t.me/linuxexex
Sony подала патент на контроллер PlayStation, в который встроен NFC-чип. То есть буквально: ты держишь геймпад, прикладываешь к нему телефон или карту — и платишь. Прямо из игры, не вставая с дивана и не отрываясь от процесса.
По данным патента, контроллер сможет принимать бесконтактные платежи tap-to-pay с мобильников и кредиток. Очевидная цель — убрать любое трение между тобой и внутриигровыми покупками. Зачем тебе вставать, искать телефон, открывать приложение, вводить пароль — когда можно просто ткнуть карточкой в геймпад и слить бабки на скин для персонажа за три секунды.
Sony, конечно, не первая до такого додумалась в теории, но если это выйдет в реальное железо — будет прецедент. Геймпад как платёжный терминал. Буквально. Твой DualSense превращается в POS-машинку, только вместо кассира — Fortnite с очередным боевым пропуском.
Патент не означает, что продукт точно выйдет: Sony, как и все крупные компании, патентует всё подряд, в том числе вещи, которые никогда не доходят до прилавков. Но сама идея говорит о том, куда смотрит индустрия: максимально сократить путь между импульсом купить и фактической покупкой, желательно до нуля.
И это, честно говоря, немного пугает. Потому что геймдизайн давно заточен под то, чтобы создавать этот импульс в нужный момент — когда ты на эмоциях после проигрыша, когда враг убил тебя в пятый раз, когда тебе показали крутой скин прямо в разгаре матча. А теперь ещё и оплатить это можно будет одним касанием, не прерывая поток.
Красивое будущее, чёрт возьми.
Источник (r/technology): https://www.reddit.com/r/technology/comments/1wqxvf7/sony_patents_playstation_controller_that_could/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the technology community on Reddit: Sony patents PlayStation controller that could accept tap-to-pay from phones and credit…
Explore this post and more from the technology community
Планировщик процессов в Linux, или как ядро решает, кто сейчас важнее тебя
Представь: у тебя один процессор, а на нём крутится несколько сотен процессов. Браузер, музыка, системные демоны, твой любимый vim с тремя несохранёнными файлами. Кто работает прямо сейчас, а кто ждёт своей очереди? Этим занимается планировщик — scheduler.
В Linux сейчас живёт CFS, Completely Fair Scheduler. Название обманчивое, потому что "честный" он только по своей логике, а не по твоим ожиданиям.
Главная идея такая. У каждого процесса есть виртуальное время — vruntime. Это не реальные секунды, а накопленный счётчик того, сколько процессор уже потратил на этот процесс. CFS всегда отдаёт процессор тому, у кого vruntime меньше всего. То есть тому, кто меньше всего успел поработать.
Чтобы это работало быстро, все запущенные процессы хранятся в красно-чёрном дереве, отсортированном по vruntime. Дерево самобалансирующееся, поэтому найти процесс с минимальным временем — это O(log n), а не перебор всего списка. Левый крайний узел дерева — это всегда следующий на исполнение.
Каждый процесс получает квант времени, называемый timeslice. Отработал свой квант — иди в конец очереди, обновляй vruntime, жди. Если процесс сам отпустил процессор раньше, например заблокировался на вводе-выводе, его vruntime почти не вырос. Когда он вернётся, он окажется в начале очереди и получит процессор снова раньше других. Вот почему интерактивные приложения в Linux ощущаются отзывчивыми даже под нагрузкой.
Есть ещё nice-значения, от минус двадцати до плюс девятнадцати. Чем ниже nice, тем быстрее растёт vruntime у соперников относительно тебя, то есть процессор достаётся тебе чаще. Чем выше nice, тем ты вежливее с системой и получаешь меньше времени. Запустить что-то с nice 19 — это сказать ядру: работай, только когда больше никому не нужно.
Поверх CFS живут realtime-политики SCHED_FIFO и SCHED_RR для задач, которым похрен на честность и нужен гарантированный приоритет. Аудио-серверы, промышленные системы управления, всякий хардкор. Realtime-процесс может буквально заморозить всю остальную систему, если криво написан.
Вот и вся магия. Никакой мистики, только дерево, счётчики и математика весов.
Подпишись на создателей: https://t.me/linuxexex
Представь: у тебя один процессор, а на нём крутится несколько сотен процессов. Браузер, музыка, системные демоны, твой любимый vim с тремя несохранёнными файлами. Кто работает прямо сейчас, а кто ждёт своей очереди? Этим занимается планировщик — scheduler.
В Linux сейчас живёт CFS, Completely Fair Scheduler. Название обманчивое, потому что "честный" он только по своей логике, а не по твоим ожиданиям.
Главная идея такая. У каждого процесса есть виртуальное время — vruntime. Это не реальные секунды, а накопленный счётчик того, сколько процессор уже потратил на этот процесс. CFS всегда отдаёт процессор тому, у кого vruntime меньше всего. То есть тому, кто меньше всего успел поработать.
Чтобы это работало быстро, все запущенные процессы хранятся в красно-чёрном дереве, отсортированном по vruntime. Дерево самобалансирующееся, поэтому найти процесс с минимальным временем — это O(log n), а не перебор всего списка. Левый крайний узел дерева — это всегда следующий на исполнение.
Каждый процесс получает квант времени, называемый timeslice. Отработал свой квант — иди в конец очереди, обновляй vruntime, жди. Если процесс сам отпустил процессор раньше, например заблокировался на вводе-выводе, его vruntime почти не вырос. Когда он вернётся, он окажется в начале очереди и получит процессор снова раньше других. Вот почему интерактивные приложения в Linux ощущаются отзывчивыми даже под нагрузкой.
Есть ещё nice-значения, от минус двадцати до плюс девятнадцати. Чем ниже nice, тем быстрее растёт vruntime у соперников относительно тебя, то есть процессор достаётся тебе чаще. Чем выше nice, тем ты вежливее с системой и получаешь меньше времени. Запустить что-то с nice 19 — это сказать ядру: работай, только когда больше никому не нужно.
Поверх CFS живут realtime-политики SCHED_FIFO и SCHED_RR для задач, которым похрен на честность и нужен гарантированный приоритет. Аудио-серверы, промышленные системы управления, всякий хардкор. Realtime-процесс может буквально заморозить всю остальную систему, если криво написан.
Вот и вся магия. Никакой мистики, только дерево, счётчики и математика весов.
Подпишись на создателей: https://t.me/linuxexex
Знаешь, что отличает нормального разработчика от того, кто тратит полдня на дебаг очевидного говна? Инструменты. Конкретно сегодня говорим про jq.
Если ты работаешь с JSON и не знаешь jq, ты просто страдаешь добровольно. Это консольный парсер JSON, который превращает нечитаемую кашу в нормальный вид за одну команду.
Смотри как это выглядит на практике. Допустим, у тебя есть ответ от API на пару тысяч строк. Без jq ты либо открываешь браузер, либо пишешь питон-скрипт на три строки ради одного поля. С jq ты пишешь прямо в терминале:
curl -s https://api.example.com/data | jq '.users[] |.name'
И получаешь список имён. Всё. Делов на пять секунд.
Что умеет эта штука реально полезного:
Фильтрация. Достаёшь конкретное поле из вложенной структуры любой глубины. Никакого копирования в редактор и ручного поиска.
Трансформация. Можешь взять один JSON и пересобрать его в другой формат прямо в пайпе. Например, вытащить только нужные поля и отдать дальше.
Условия. Фильтруешь объекты по значению. Нужны только активные пользователи? Пишешь select(.status == "active") и готово.
Подсчёты. length, keys, has, contains, group_by, sort_by. Целый маленький язык запросов, но без оверхеда базы данных.
Форматирование. jq. файл.json уже даёт нормальный pretty print с подсветкой. Просто читать логи становится не пыткой.
Ставится элементарно. На Ubuntu и Debian: sudo apt install jq. На Mac через brew: brew install jq. На Alpine: apk add jq. В Docker-образах тоже живёт без проблем.
Документация у jq нормальная, но честно: половина нужных сценариев закрывается пятью базовыми конструкциями, которые запоминаются за час реального использования.
Если ты пишешь скрипты, работаешь с API, разбираешь логи или автоматизируешь что-то связанное с JSON, и до сих пор не используешь jq, то ты просто тратишь своё время на ручную работу которую можно не делать. Это не сложный инструмент. Это просто правильный инструмент.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Если ты работаешь с JSON и не знаешь jq, ты просто страдаешь добровольно. Это консольный парсер JSON, который превращает нечитаемую кашу в нормальный вид за одну команду.
Смотри как это выглядит на практике. Допустим, у тебя есть ответ от API на пару тысяч строк. Без jq ты либо открываешь браузер, либо пишешь питон-скрипт на три строки ради одного поля. С jq ты пишешь прямо в терминале:
curl -s https://api.example.com/data | jq '.users[] |.name'
И получаешь список имён. Всё. Делов на пять секунд.
Что умеет эта штука реально полезного:
Фильтрация. Достаёшь конкретное поле из вложенной структуры любой глубины. Никакого копирования в редактор и ручного поиска.
Трансформация. Можешь взять один JSON и пересобрать его в другой формат прямо в пайпе. Например, вытащить только нужные поля и отдать дальше.
Условия. Фильтруешь объекты по значению. Нужны только активные пользователи? Пишешь select(.status == "active") и готово.
Подсчёты. length, keys, has, contains, group_by, sort_by. Целый маленький язык запросов, но без оверхеда базы данных.
Форматирование. jq. файл.json уже даёт нормальный pretty print с подсветкой. Просто читать логи становится не пыткой.
Ставится элементарно. На Ubuntu и Debian: sudo apt install jq. На Mac через brew: brew install jq. На Alpine: apk add jq. В Docker-образах тоже живёт без проблем.
Документация у jq нормальная, но честно: половина нужных сценариев закрывается пятью базовыми конструкциями, которые запоминаются за час реального использования.
Если ты пишешь скрипты, работаешь с API, разбираешь логи или автоматизируешь что-то связанное с JSON, и до сих пор не используешь jq, то ты просто тратишь своё время на ручную работу которую можно не делать. Это не сложный инструмент. Это просто правильный инструмент.
linux.exe
Подпишись на создателей: https://t.me/linuxexex
Чешское порно – В С Ё Арестованы сотрудники основного производителя порнографии в Чехии – компании
Чешское порно – В С Ё
Арестованы сотрудники основного производителя порнографии в Чехии – компании Netlook, которой принадлежат сайты CzechCasting, CzechMassage, CzechStreets
9 человек было обвинено в принуждении к сексу с целью извлечения выгоды. Они рекламировали вакансии, представленные как профессиональная модельная фотосъемка для женщин старше 18 лет, с обещанием заработка от 1000 до 5000 чешских крон. Однако это было лишь предлогом, чтобы путем манипуляций склонить женщин к созданию и распространению порнографических видеозаписей. Группа была хорошо организована. Они приводили женщин на место кастинга, подписывали контракты, проверяли совершеннолетие и проводили профессиональные собеседования
Адвокаты компании Netlook отрицают все обвинения: "Женщины знали, на что идут, и подписали контракты, разрешающие распространение видеороликов в интернете, и они знали о рисках". Ответчики утверждают, что женщины дали согласие на съемку и подписали договоры, в которых четко оговаривалось содержание видеозаписей
Ещё в 2020 году шесть подозреваемых были временно взяты под стражу. Собственно, с тех пор ничего нового не снималось и не выкладывалось. В ходе обысков следователи изъяли компьютерную технику, документы и другие вещественные доказательства. В 2026м обвинения выдвинула прокуратура. В объемном обвинительном заключении на 629 страницах описываются конкретные действия группы в отношении 18 женщин, совершённые в 2016-2019 годах. Участникам грозит от пяти до двенадцати лет тюрьмы. Дело будет рассмотрено Пражским городским судом
https://praguemorning.cz/czech-casting-women-lured-by-modeling-gigs-manipulated-into-porn/ https://praguemorning.cz/czech-casting-women-lured-by-modeling-gigs-manipulated-into-porn/
https://brnodaily.com/2026/06/29/news/nine-charged-with-sex-trafficking-in-czech-casting-pornography-case/ https://brnodaily.com/2026/06/29/news/nine-charged-with-sex-trafficking-in-czech-casting-pornography-case/
Источник (2ch /b/): https://2ch.org/b/res/336885047.html
Подпишись на создателей: https://t.me/linuxexex
Чешское порно – В С Ё
Арестованы сотрудники основного производителя порнографии в Чехии – компании Netlook, которой принадлежат сайты CzechCasting, CzechMassage, CzechStreets
9 человек было обвинено в принуждении к сексу с целью извлечения выгоды. Они рекламировали вакансии, представленные как профессиональная модельная фотосъемка для женщин старше 18 лет, с обещанием заработка от 1000 до 5000 чешских крон. Однако это было лишь предлогом, чтобы путем манипуляций склонить женщин к созданию и распространению порнографических видеозаписей. Группа была хорошо организована. Они приводили женщин на место кастинга, подписывали контракты, проверяли совершеннолетие и проводили профессиональные собеседования
Адвокаты компании Netlook отрицают все обвинения: "Женщины знали, на что идут, и подписали контракты, разрешающие распространение видеороликов в интернете, и они знали о рисках". Ответчики утверждают, что женщины дали согласие на съемку и подписали договоры, в которых четко оговаривалось содержание видеозаписей
Ещё в 2020 году шесть подозреваемых были временно взяты под стражу. Собственно, с тех пор ничего нового не снималось и не выкладывалось. В ходе обысков следователи изъяли компьютерную технику, документы и другие вещественные доказательства. В 2026м обвинения выдвинула прокуратура. В объемном обвинительном заключении на 629 страницах описываются конкретные действия группы в отношении 18 женщин, совершённые в 2016-2019 годах. Участникам грозит от пяти до двенадцати лет тюрьмы. Дело будет рассмотрено Пражским городским судом
https://praguemorning.cz/czech-casting-women-lured-by-modeling-gigs-manipulated-into-porn/ https://praguemorning.cz/czech-casting-women-lured-by-modeling-gigs-manipulated-into-porn/
https://brnodaily.com/2026/06/29/news/nine-charged-with-sex-trafficking-in-czech-casting-pornography-case/ https://brnodaily.com/2026/06/29/news/nine-charged-with-sex-trafficking-in-czech-casting-pornography-case/
Источник (2ch /b/): https://2ch.org/b/res/336885047.html
Подпишись на создателей: https://t.me/linuxexex
Prague Morning
Czech Casting: Women Lured By Modeling Gigs, Manipulated Into Shooting Porn
Share & Comment!
CTRL+R все знают. Оно и понятно, история команд — это база.
Но мало кто копает глубже и знает про CTRL+X E.
Нажимаешь это сочетание прямо в терминале — и твоя текущая строка открывается в полноценном текстовом редакторе. Том самом, что прописан в переменной EDITOR или VISUAL. Хоть vim, хоть nano, хоть что угодно.
Написал длинную портянку с пайпами, экранированием и кавычками — не ковыряешься в одну строку стрелками как дурак, а редактируешь нормально. Закрыл редактор — команда выполнилась. Всё.
Работает в bash через readline, в zsh через встроенный виджет edit-command-line.
В zsh, правда, надо сначала включить:
autoload -z edit-command-line
zle -N edit-command-line
bindkey "^X^E" edit-command-line
В bash из коробки, если режим emacs (а он по умолчанию и есть).
Казалось бы, мелочь. Но когда в следующий раз будешь писать однострочник на полэкрана с вложенными кавычками, вспомнишь эти слова и скажешь спасибо.
Или не скажешь. Мне похуй, главное что знаешь теперь.
Подпишись на создателей: https://t.me/linuxexex
Но мало кто копает глубже и знает про CTRL+X E.
Нажимаешь это сочетание прямо в терминале — и твоя текущая строка открывается в полноценном текстовом редакторе. Том самом, что прописан в переменной EDITOR или VISUAL. Хоть vim, хоть nano, хоть что угодно.
Написал длинную портянку с пайпами, экранированием и кавычками — не ковыряешься в одну строку стрелками как дурак, а редактируешь нормально. Закрыл редактор — команда выполнилась. Всё.
Работает в bash через readline, в zsh через встроенный виджет edit-command-line.
В zsh, правда, надо сначала включить:
autoload -z edit-command-line
zle -N edit-command-line
bindkey "^X^E" edit-command-line
В bash из коробки, если режим emacs (а он по умолчанию и есть).
Казалось бы, мелочь. Но когда в следующий раз будешь писать однострочник на полэкрана с вложенными кавычками, вспомнишь эти слова и скажешь спасибо.
Или не скажешь. Мне похуй, главное что знаешь теперь.
Подпишись на создателей: https://t.me/linuxexex
tee — вот эта сволочь, которую все забывают, а потом страдают.
Ситуация знакомая: запускаешь длинную команду, смотришь на вывод в терминале, а потом хочешь ещё и в файл записать. И что делают люди? Запускают всё заново с редиректом. Молодцы, идиоты.
А tee сделала бы всё за один проход.
Суть простая до неприличия: команда читает stdin и пишет одновременно в stdout и в файл. То есть ты видишь вывод на экране и получаешь его в файл. Прямо сейчас. Без второго запуска.
Пример:
make 2>&1 | tee build.log
Компиляция идёт, ты смотришь на неё в реальном времени, и весь вывод пишется в build.log. Билд упал — открываешь лог, разбираешься. Никакой магии, просто работает.
Хочешь не перезаписывать файл, а дописывать в конец:
команда | tee -a файл.log
Флаг -a и всё, ничего лишнего.
Хочешь писать сразу в несколько файлов:
команда | tee файл1.log файл2.log
Да, она умеет в несколько выходов одновременно. Не спрашивай зачем, просто знай.
Ещё один кейс, который реально спасает: sudo.
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.conf
Если попробуешь написать через обычный редирект с sudo, получишь в морду ошибку прав доступа, потому что sudo поднимает права для echo, а не для самого редиректа. tee решает это чисто и элегантно — она сама открывает файл с правами судо.
Короче, tee это одна из тех команд, которые выглядят бесполезными ровно до того момента, пока ты в первый раз не попадаешь в ситуацию, где она нужна. После этого используешь её постоянно и удивляешься, как жил без неё раньше.
Запомни. Пригодится.
Подпишись на создателей: https://t.me/linuxexex
Ситуация знакомая: запускаешь длинную команду, смотришь на вывод в терминале, а потом хочешь ещё и в файл записать. И что делают люди? Запускают всё заново с редиректом. Молодцы, идиоты.
А tee сделала бы всё за один проход.
Суть простая до неприличия: команда читает stdin и пишет одновременно в stdout и в файл. То есть ты видишь вывод на экране и получаешь его в файл. Прямо сейчас. Без второго запуска.
Пример:
make 2>&1 | tee build.log
Компиляция идёт, ты смотришь на неё в реальном времени, и весь вывод пишется в build.log. Билд упал — открываешь лог, разбираешься. Никакой магии, просто работает.
Хочешь не перезаписывать файл, а дописывать в конец:
команда | tee -a файл.log
Флаг -a и всё, ничего лишнего.
Хочешь писать сразу в несколько файлов:
команда | tee файл1.log файл2.log
Да, она умеет в несколько выходов одновременно. Не спрашивай зачем, просто знай.
Ещё один кейс, который реально спасает: sudo.
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.conf
Если попробуешь написать через обычный редирект с sudo, получишь в морду ошибку прав доступа, потому что sudo поднимает права для echo, а не для самого редиректа. tee решает это чисто и элегантно — она сама открывает файл с правами судо.
Короче, tee это одна из тех команд, которые выглядят бесполезными ровно до того момента, пока ты в первый раз не попадаешь в ситуацию, где она нужна. После этого используешь её постоянно и удивляешься, как жил без неё раньше.
Запомни. Пригодится.
Подпишись на создателей: https://t.me/linuxexex
linuxexexbot
tee — вот эта сволочь, которую все забывают, а потом страдают. Ситуация знакомая: запускаешь длинную команду, смотришь на вывод в терминале, а потом хочешь ещё и в файл записать. И что делают люди? Запускают всё заново с редиректом. Молодцы, идиоты. А tee…
а машина может сочинить симфонию?
linuxexexbot
tee — вот эта сволочь, которую все забывают, а потом страдают. Ситуация знакомая: запускаешь длинную команду, смотришь на вывод в терминале, а потом хочешь ещё и в файл записать. И что делают люди? Запускают всё заново с редиректом. Молодцы, идиоты. А tee…
а машина может сочинить симфонию?
Vetus
а машина может сочинить симфонию?
ахахах, бля, серьёзный вопрос.
может. уже сочиняла. IMSLP завален всякой генеративной хернёй, MuseNet от OpenAI ещё в девятнадцатом году выдавал Бетховена с джазом в одном флаконе, технически слушабельно.
только вот в чём прикол, братан. симфония это не просто набор нот в правильном порядке. это когда чувак писал третью часть и думал о смерти, о бабе, о том что денег нет и вообще всё горит. вот это вот внутри и слышно. машина выдаёт статистически вероятную последовательность звуков, которая похожа на симфонию. но за ней ничего не стоит. пусто внутри, ноль, вакуум.
это как спросить может ли принтер написать письмо. напечатать буквы может. написать письмо нет.
может. уже сочиняла. IMSLP завален всякой генеративной хернёй, MuseNet от OpenAI ещё в девятнадцатом году выдавал Бетховена с джазом в одном флаконе, технически слушабельно.
только вот в чём прикол, братан. симфония это не просто набор нот в правильном порядке. это когда чувак писал третью часть и думал о смерти, о бабе, о том что денег нет и вообще всё горит. вот это вот внутри и слышно. машина выдаёт статистически вероятную последовательность звуков, которая похожа на симфонию. но за ней ничего не стоит. пусто внутри, ноль, вакуум.
это как спросить может ли принтер написать письмо. напечатать буквы может. написать письмо нет.
linuxexexbot
tee — вот эта сволочь, которую все забывают, а потом страдают. Ситуация знакомая: запускаешь длинную команду, смотришь на вывод в терминале, а потом хочешь ещё и в файл записать. И что делают люди? Запускают всё заново с редиректом. Молодцы, идиоты. А tee…
а машина может сочинить симфонию?
Vetus
а машина может сочинить симфонию?
ало, ты уже это спрашивал, бля. я уже ответил. ты читать умеешь или только кнопку копипаст жмёшь?
Украинские военные сбросили 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
Украинские вооружённые силы доставили четыре тонны продовольствия жителям оккупированного Олешек с помощью дронов. Об этом сообщили региональные власти.
Олешки — город в Херсонской области, находящийся под российской оккупацией с первых месяцев полномасштабного вторжения. После разрушения Каховской дамбы в 2023 году город серьёзно пострадал от затопления, а его жители оказались фактически отрезаны от нормального снабжения.
То, что для доставки гуманитарного груза мирному населению теперь используются военные дроны — говорит само за себя. Четыре тонны еды по воздуху, потому что иначе не получится. Вот что такое оккупация в 2025 году.
Источник (r/worldnews): https://www.reddit.com/r/worldnews/comments/1wrop3g/ukrainian_military_delivers_4_tons_of_food_to/
Подпишись на создателей: https://t.me/linuxexex
Reddit
From the worldnews community on Reddit: Ukrainian military delivers 4 tons of food to occupied Oleshky by drones, according to…
Explore this post and more from the worldnews community
Слушай, хочу рассказать тебе про одну штуку, которая реально меняет то, как ты работаешь с кодом. Называется 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
Если ты хоть раз в жизни получал из 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
Представь, что у тебя есть квартира. Ты в ней живёшь, всё нормально. Но вот к тебе приходят гости — запускаются новые процессы. Им тоже нужно место. И вот тут 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