Только что у узнал что у fedora есть atomic версия - это иммутабельная система где все графические приложения устанавливаются только через flatpack, а cli и либы через Toolbx/Distrobox

❓Почему это круто и почему я сейчас же это попробую:

Я часто что-то билжу у себя локально. Ну например - вчера я собирал демку для моего ESP32 устройства в новом для себя фреймворке Espressif IDF.
Для того чтобы она собралась надо поставить зависимости в систему. МНОГО зависимостей.

sudo dnf install flex bison gperf cmake ninja-build ccache libffi-devel openssl-devel dfu-util libusb1-devel

В последствии я вероятно перелезу на что-то еще, а весь этот хлам так и останется в системе.

А на прошлой неделе я собирал кастом прошивку на мой принтер - и там была аналогичная ситуация.

В итоге:
🔻 Cистема обрастает хламом который нужен одному конкретному проекту
🔻 Вероятность словить конфликты зависимостей каждый раз возрастает
🔻 dnf обрастает кучей лишних репозиториев которые замедляют обновление.

Я думаю вы теперь понимаете почему что-то во мне каждый раз кричит о том что это все не правильно, и все равно что зависимости каждого js проекта ставить с флагом --global

Как я пытался это решать:

🔸Docker.
Для некоторых проектов я собирал докер образ внутрь которого создавалось окружение и происходил билд . В целом схема рабочая, но это потеря времени на написание докер файла. К тому же если билд таким образом получится сделать, то вот подебажить или поработать из иде внутри контейнера уже проблематично.

🔸 Dev Containers
В целом это тоже самое что первый пункт но без минуса - теперь можно работать внутри него.
Цена - нормально поддерживается только в vscode (в zed вроде тоже можно но я не осилил), и писать конфиг dev контейнера на практике оказалось ничуть не проще, а порой даже сложнее чем докер файл

🔸 Devbox
Решение на базе Nix. Иногда это работает, особенно в популярными экосистемами такими как у rust, go, js или python. Что-то более редкое, различные репы на C++ / C или Zig оказалось запускать в этом окружении
Во многом оно просто работает только в том случае, если до вас кто-то уже отстрадал и потом еще обновляет и поддерживает результат своих страданий.
Самому менеджить никс и создавать в нем пакеты оказалось в 10 раз сложнее чем дев контйенеры! К тому же изоляция не "настоящая" и ограниченна переменными окружения - C пакеты с makefile клали на них большой болт

🧩А вот что предлагает atomic.

🔹 GUI приложения → Flatpak

flatpak install org.mozilla.firefox
flatpak install com.visualstudio.code

🔹 CLI инструменты → Toolbx/Distrobox

# Создание изолированного контейнера
toolbox create my-container

# Работа внутри контейнера
toolbox enter my-container

# Внутри контейнера - обычная Fedora!
sudo dnf install nodejs python3-pip docker vim
pip install poetry
npm install -g typescript
code .

# Выходим из контейнера и удаляем когда не нужен вместе со всеми зависимостями
exit
toolbox rm my-container

🔹 Системные компоненты → rpm-ostree layering

# Только для критичных системных пакетов
rpm-ostree install zsh fish

# Требует перезагрузки!
systemctl reboot

rpm-ostree layering работает похоже на git - можно легко откатиться на любой состояние системы с снова вернуться к нему (полезно например для определения что вызвало баг)
Кроме того любой системный пакет можно восстановить на "родное состояние"

# Заменить системный пакет на другую версию
rpm-ostree override replace /path/to/custom-kernel.rpm

# Откатить замену
rpm-ostree override reset kernel

Вообще я заметил что многие docker недооценивают. Обычно из перечисленных ниже трех сценариев использованию знают только об одном или двух:

🔹 Контейнеризация приложения.
Классический сценарий использования - Dockerfile описывает всё окружение и последовательность действий для запуска приложения, а снаружи "торчит" только порт который приложению позволено слушать.

Такой контейнер запускается и в норме работает до следующего деплоя изменений. Запускается обычно командой docker run

🔹 Build container
Это менее известный сценарий (хотя я его использую даже чаще) - Dockerfile описывает окружение необходимое для сборки приложения, собирает его, и на выход отдает некие артефакты.

Запускается командой docker build -o output/path. Dockerfile выглядит (упрощенно) так:

FROM whatewer AS build
# describe build env
# describe build steps

FROM scratch AS export
COPY --from=build /target/ ./

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

🔹 Песочница
Пожалуй самый редкий сценарий использования. Это dockerfile в котором главная роль принадлежит инструкции ENTRYPOINT и флаги :ro, --network=none.
Представим что мы хотим запустить какой curl bash, ну или даже подозрительный npm пакет у себя в системе, один из тех в которые любят встраивать бекдоры.
Оговорюсь что такие вещи бывает опасно запускать даже в одном контейнере с приложением, т.к. они могут, например, украсть ключи из переменных окружения.

Но довольно безопасно запускать их в песочнице, например htmlhint

 
FROM node:24-alpine3.21
RUN npm install -g htmlhint
ENTRYPOINT ["htmlhint"]

и потом запустить в полностью иммутабельном окружении и с запретом на доступ в сеть

docker run --rm --network=none -v ${PWD}:${PWD}:ro htmlhint ${PWD}

Впрочем для таких простых случаев можно и без Dockerfile (да, учтите что его надо будет разочек предсобрать командой docker build с разрешением доступа в сеть, ведь npx-у надо пакет откуда-то взять)

docker run --network=none -v ${PWD}:${PWD} --workdir=${PWD} node:24-alpine3.21 npx prettier --fix

Как дебажить LLM?

Сложно не замечать слона в комнате - текущие LLM выдают очень не стабильные результаты.

Жалобы на "вчера было хорошо а сегодня плохо" проходят постоянным фоном в каждом обсуждении LLM, дошло даже до небольшого скандала.

Люди гадают в чем дело (перегрузка серверов, не та модель, не та Иде, не те mcp, не тот план, не тот размер контекста, не та фаза луны и вовсе всемирный заговор).

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

Я успокаивал себя тем что - ну и ладно, я же не вижу ассемблер который получается из моего кода.

Но все же, если подумать, это не та-же ситуация. Во первых, при желании, ассемблер можно все таки посмотреть (в случае же LLM даже выкладывание в опенсорс модели не дает по сути ничего для ее понимания). Во вторых даже скриптовые ЯП работает достаточно детерминировано чтобы в этом не было нужды в подавляющем большинстве случаев. Я могу повторить то же действие и получить тот же результат. У меня нет дня когда один и тот же js код работает хуже или лучше чем вчера.

Не может такого быть что в первый день релиза новой версии один и тот же JS код выполнялся верно, а на второй - перестал.

Мне не привычно работать с такими нестабильными инструментами, с таким уровнем неопределенности и размытости, ориентироваться в настолько плотном тумане...

Сказал человек который 5 лет изучал психологию : ). Есть тут некоторые параллели, например мы точно так же спрашиваем LLM почему она допустила ошибку, в надежде лучше понять проблему (и она точно так же как человек едва ли скажет правду) Хотите верьте, хотите нет, но даже у Карла Рэнсома Роджерса было больше определенности чем сегодня в том, что касается "поведения" LLM.

Самые популярные версии на данный момент (по убыванию):
- Nvidia GPU для Framework 16 / Framework Desktop
- ARM опция материнки для ноутбуков
- Ryzen Strix Halo процессор для Framework 16
- 3D принтер (почему то его все ждут от фереймворка каждый раз)
- LED / тачскрин для 13шки
- Смартфон

Причем первая опция упоминается значительно чаще остальных.
Создается впечатление что комьюнити Framework точно знает чего хочет )

Gemini считает что это будет что-то для рыбалки

Из интернетов:

Вайб-кодинг полностью излечил мой синдром самозванца.

Не потому, что я вайб-кодер, а наоборот.

Раньше я думал: "Что я за программист такой, что не могу толком вспомнить, когда память выделяется в куче, а когда в стеке."
А теперь мне ребята из отдела продаж скидывают в личку ссылку на localhost:3000, спрашивая, почему у них null pointer exception в JavaScript коде.
В JavaScript вообще нет указателей. Где ты нашёл указатель, Стив!?

И самое ужасное - у этих ребят вообще нет синдрома самозванца. Я никому не желаю иметь синдром самозванца, но если ты реально самозванец, то это уже не синдром.

Ты можешь называть себя вайб-кодером, если хочешь, но...
На днях в самолёте рядом со мной сел парень, который говорит: "Ты программист? Я тоже.". Но как только у нас пропал Wi-Fi и он не смог попросить ChatGPT исправить его код я наблюдал, как он пытается починить его сам, ставя точку с запятой в разные места своего кода.

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

Он писал на python

"Вы знаете кому это отправить"

Если вы часто пользуетесь встроенным в chrome браузер переводчиком то наверняка заметили что он плохо дружит с VDOM библиотеками.
Авто перевод страницы часто приводит к белому экрану, головной боли как у пользователей так и разработчиков приложений, которые не могут понять почему у некоторых клиентов крошится приложение даже с выключенными расширениями.

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

Однако сегодня в рассылке я увидел довольно интересный костыль в виде браузерного расширения.

Почему это интересно:

1. Во первых код расширения можно забрать себе в (условно) реакт проект когда ваши пользователи придут с этой проблемой

2. Во вторых позволит вам починить приложения которыми вы вынуждены пользоваться, но не можете заставить разработчика это починить

Создатели FliperZero делают Flipper One - вот такую вот дуру которую в карман уже не положишь. С полноценным Linux, но при этом монохромным дисплеем, разрешением немного больше чем у первой версии. Да, оттуда выпилили все-все радио модули так как оригинальный девайс забанили уже кажется везде (спасибо сотням кликбейт видео о том что девас за 100$ угонит ваш машину).

Кому нужен этот недо-стимдек не понятно. Вроде бы к нему будет прилагаться модули с датчиками и тп, но в таком формфакторе... У меня большие сомнения что кому-то это надо

начнется через 15 минут

в этот раз Framework 16 получил все плюшки:
- Новая материнка
- Новыe Ryzen CPU 300 серии - AMD Ryzen AI 7 350 и AMD Ryzen AI 7 370
- NVidia 5070 (8GB DDR7). CUDA - 384 GB/s
- Можно вместо GPU подключать до 16 TB m2 ssd памяти
- Новый блок питания (текущего хватает едва едва, можно умудриться загрузить ноут так что он будет по-немногу разряжаться даже стоя на зарядке)
Похоже это самый мощный GaN блок питания, так если вам вдруг нужно 240 W (Вааат) type-c блок питания - оно у них есть и продается отдельно)

Плюшки поменьше -
- Wi-FI 7
- Улучшенная вебка
- крышка из более жесткого алюминия (хз что с текущей не так)
- более тихие кулеры (если вы читаете мой блог то в курсе что сейчас ноут довольно шумный под нагрузкой)
- теперь монитор можно подключать не в 3 слота а 5 слотов. Это круто потому что обычно ноут где-то сбоку а не по центру двух мониторов, и второй кабель втыкался "не с той стороны"
- в новых GPU доках в задний порт теперь можно втыкать не только монитор но так же зарядку. И даже одновременно и то другое (типо от блока питания монитора?, хз)
- Теперь видеосигнал с дискретного GPU можно пускать напрямую на экран. Больше событие для linux-оводов
(практически все современные ноутбуки с дискреткой работают "сквозь встроенку CPU. Т.е. система всю графику отдает на CPU а тот делает "offload", т.е. отдает расчеты на дискретку и потом отдает как свое.
В первую очередь это было придумано для того чтобы переключаться в режим энергосбережения и обратно без перезагрузки ПК, но софтверно технология очень бажная особенно на Linux и особенно если этот второй GPU это NVIDIA.
Чтобы вы понимали, долгое время для того чтобы это поддержать в linux создавалась вторая графическая X сессия и основная на дискретке, откуда картинка на основную перебрасывалась тем же механизмами что используются для проброса X сессий по сети.
Кроем того потенциально была проблема с тем что сильно загруженный CPU мог тормозить и картинку с GPU)

'use strict'
{
  const async = async () => {
    const package = 'leftpaf@2.3.1';
    console.log(package)
  }
  async()
}

Как думаете здесь есть ошибка?

Все обсуждают свежее исследование влияния AI на скорость закрытия задач.
- тестировали на мейнтейнерах крупных опенсорс репозиториев
- на реальных задачах
- анализировали записи экрана вместо того чтобы полагаться на ощущения разработчиков
- один инструмент у всех - cursor.

В кратце выводы - в общем замедление на 20%, из-за накладных расходов - время генерации, время написания промптов, время на ревью кода написанного агентом.

Интерпретация через призму моего опыта (roo code, claude code, zed):
- применение AI ко всем задачам подряд действительно даст замедление. Ускорение есть только на задачах подходящих для AI. Попытки заставить его делать любые задачи отнимают больше времени чем экономят.

Да, первое время это может быть даже весело и увлекательно, но в сухом остатке - пул задач где AI эффективна весьма ограничен.

Попробую его обозначить:

Написание чистых утилитарных функций

Администрирование Linux:
- анализ системы и определение источника проблема
- разрешение конфликтов пакетов
- доустановка необходимых пакетов
- исправление проблем с драйверами
- создание cron / systemd задач
- генерация сложных cli команд

Работа с небольшими приложениями , библиотеками, прототипами:
Тут самый важный критерий - можете и ли вы точно и коротко сформулировать какие именно изменения надо внести в код. Если нет - то и оценить предложенные изменения агентом будет сложно.

Шансы на успех увеличиваться если:
- язык со строгой типизацией
- стек стандартный для индустрии
- все связи в коде явные
- в коде досрочно комментариев а сущности удачно названы
- много тестов / сначала был написан тест

В итоге я очень активно используют AI "в быту" для решения своих насущных проблем - что то править, сделать утилиту, лениво покодить esp32.

Но в рабочих задачах в большом монорепе, где весь болиерплейт написан а код дедуплицирован я 70% времени анализирую проблему и ищу правильное решение, а сам код я пишу в весьма скромных количествах.
Те несколько сотен строк что мне останется написать дольше просить чем написать самому, особенно когда AI автокомплит мне помогает

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

Очень своевременно

Если вы не первый день пользуйтесь wayland то вам 100% знакома такая утилита как ydotool
Именно благодаря ей другие программы могут управлять мышью, вводом с клавиатуры, и т.п. программно.

Я заметил интересную вещь в репозитории этой тулы - её автор (ReimuNotMoe*) собирается переписать ее с C на JS, используя в качестве рантайма некий Resonance который он сам же и разрабатывает.
Интересно что он так же утверждает что

The RAM consumption (RSS) will NOT exceed 1MB.

Плохая новость - разработка этого рантайма ведется в закрытом репозитории. По крайней мере пока.

Хорошая новость - пока я ее искал я нашел rEFui - "The Retained Mode JavaScript framework" - выглядит весьма интересно.

Удивительно что я о нем раньше не слышал, тут и сигналы и NativeScript и из коробочный HMR, и даже параллельная поддержка как jsx так и шаблонных литералов одновременно
(готовый проект на нем SudoMaker/LoShark-Dashboard )
—
* я вам рекомендую полистать его github, а так же - github.com/SudoMaker
там много годноты

Spec driver development это такая противоположность vibe-coding. Подразумевается строгий процесс разбитый на этапы от планирования к реализации.

На данный момент все AI ide и расширения едины в порыве этот процесс поддержать, а кто-то даже зафорсить. Причем не только в задачах разработки, но и в смежных сферах - вот например расширение для системной аналитики которое делает тоже самое

По ссылке в начале поста можно найти cli тул от команды GitHub который не привязан к конкретной ide, поддерживает несколько разных coding агентов, и, наверное самое интересное - подход при котором план это не один большой монолитный файл а много много маленьких файлов-спецификаций разложенных по директориям. Это позволит здорово экономить контекст

Хороший тачпад на ноуте штука очень удобная. Я сам это понял только после того как у меня появился Framework. На Lenovo и HP трэкпады как бы есть, но пользовался ими очень не удобно.

Когда я себе захотел трэкпад я уже точно понимал как огромна эта разница, и мне хотелось что-то уровня тачпада фреймворка.

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

И много раз видел утверждение о том что пожалуй лучше чем apple-овские трэкпады ничего нет.

Наверное это и стало триггером для меня. Я поставил себе вот - во чтобы то не стало найти такой трэкпад который будет лучше. Ведь утверждения о том что нет ничего лучше, чем то что делает apple еще ни разу не оказались правдой, и вряд-ли в этот раз у нас исключение.

Первое что я начал копать - это кто делает тачпады для фремворка. В целом я нашел несколько прикольных DIY решений, в которых как раз он и использовался (он ведь отдельно продается).

Но честно говоря этот путь тернист, по скольку тачпад этот требует некоторое количество железа до того как его можно будет воткнуть в usb (или по bluetooth), так что как готовое решение я его посоветовать не могу.

Однако, в процессе я нашел кое что более интересное - опенсорсный, сделанный с нуля трэкпад где уже решены все софтовые и железные проблемы. Конечно же там оверкил gпо обеим пунктам это обычно бывает в опенсорс железках, но и при этом он все ещё дешевле чем вариант от apple. И он у меня уже в вишлисте.

https://ploopy.co/trackpad/

P.S. я пообщался с автором этого трэкпада на предмет того - почему там корпус из пластика а не стекла (я очень люблю стеклянные тачпады). В целом он говорит что были у них и такие эксперименты, и он работает если прикрепить стекло до 2х мм сверху, но в виду того штука это скорее эстетическая - решили оставить без него. В теории можно настроить чувствительность и на большую ширину стекла, и он готов мне с этим помочь.