Пока все встраивают AI в свои инструменты wallaby решил сделать новые инструменты чтобы было проще дебажить сгенерированный говнокод.

По ссылочке есть видео и больше информации
https://wallabyjs.com/blog/diagrams.html

Наконец-то в Linux появился реально классный графический редактор которого так не хватало!
Он только только вышел, а уже очень меня радует.

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

С горой документации, и видео туториалами.

и все это FOSS, , и судя по родмапу это они только начали.

(Заставка сделана в нем через минуту после установки)

https://pixieditor.net/download/

В Typescript что вышел пять дней назад (5.9) завезли фичу - разворачивающихся подсказок с типами
https://devblogs.microsoft.com/typescript/wp-content/uploads/sites/11/2025/06/expandable-quick-info-1.mp4

Что еще там:

- import defer - импорт модулей которые будут инициализированы лениво

- --module node20 - флаг с которым можно рекваерить (require) esm модули

- кэширование которое значительно улучило перф ts-a при работе с такими либами как как Zod и tRPC

- fileOrDirectoryExistsUsingSource - убирает лишние обертки над функциями из анализа улучшая время старта tsserver на 11%

Брейкинг Ченжи в lib.d.ts:

- ArrayBuffer это больше не супертип для всех TypedArray
Миграция выглядит вот так:

 let data = new Uint8Array([0, 1, 2, 3, 4]);
- someFunc(data)
+ someFunc(data.buffer)

Странная история с этой фичей - сначала она была добавлена
Потом ее ревертнули
Потом снова замержили
и сейчас она как бы есть но почему-то ни у кого не работает

Мне всегда было интересно а что там будет если превысить MAX_SAFE_INTEGER.
Понятно что ничего хорошего, но все же, что именно?

const x = Number.MAX_SAFE_INTEGER + 1;
const y = Number.MAX_SAFE_INTEGER + 2;
console.log(x === y); // true

// YES. BUT

const a = Number.MAX_SAFE_INTEGER + 111
const b = Number.MAX_SAFE_INTEGER + 112
console.log(a === b) // false

Произойдет "квантование", или по простому - снижение точности.

Сначала JS перестает "видеть" разницу между числами которая 2 и меньше. И чем дальше тем точность больше будет "загрубляться"

Чтобы легко было запомнить, я представил себе что это такой динамический LOD - когда текстуры и модели в игре начинают терять детализацию по мере отдаления от камеры игрока.

Немного душноты для тех кому интересна техническая часть

Это связано с тем, как IEEE 754 представляет числа. После MAX_SAFE_INTEGER шаг между представимыми числами становится 2, затем 4, затем 8 и т.д. +1 и +2 попадают в один "слот", а +111 и +112 — в разные.

Мантисса: 52 бита + 1 скрытый бит = 53 значащих бита, и при превышении 2^53 младший бит мантиссы представляет 2 единицы, не 1

Только что у узнал что у 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()
}

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