4779 - Блог

Конец выборам агента

2026-07-06T00:00:00+00:00

По-последним моим постам можно сделать вывод что я много занимаюсь разработкой в агенте. Да, это так. Размышлял о том, достаточно ли пи-агента, или попробовать opencode.

Кажется, зря я тратил на это время, потому что вижу что нас ждет другое будущее.

Антропики давно уже начали банить Opencode - который родился как клон их Claude Code. Zai выкатили своего агента zcode</a>. Про Квен-код тоже, давно уже не новость.

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

Тращенков поделился заметкой 1</a> 2</a>, как разработчики пи-агента заметили, что Opus адаптирован под инструмент из Claude Code. Я давно уже заметил аналогичное при работе с квен-модельками. Даже сделал qwen-flavor 3</a> для пи-агента.

^1

t.me/gigatrash/227</a> </div>

^2

lucumr.pocoo.org/2026/7/4/better-models-worse-tools/</a> </div>

^3

gitverse.ru/e4779/pi-etc/content/main/extensions/qwen</a> </div>

Нового ничего нет. Старый-добрый Embrace, extend, and exterminate 4</a>.

^4

wiki</a> </div>

А что делать нам?</a></h2>
Скиллы, утилиты и mcp. К счастью, все эти три штуки - уже устаканились как стандарт. Они независимы между агентами.
А всякие модель-агностик агенты типа того же pi, cline и прочих - останутся нишевыми, для каких-то небольших моделек.
К будущему с локал-фёрст я очень скептично отношусь. Ибо вижу и по-себе, что работать с контекстом в 1 миллион и глубоко рассуждающей моделью куда приятнее и проще, нежели адаптировать задачу под компактную модель.

Пи-агента достаточно

2026-06-23T00:00:00+00:00

Как-то я обустроив свой быт с пи-агентом, написал скиллов для работы с mcp поверх mcporter 1</a> сижу теперь и думаю - а не охота с него и соскакивать.

^1

lsp как mcp</a>, github</a>, chrome devtools</a> </div>

Как-то я погрузился в это всё. Написал, опять же, собственный скилл 2</a> для субагентов. И теперь думаю - а откатиться на “дефолтный” opencode будет для меня скорее деградацией в удобстве.

^2

pisub</a> не отказывайте себе в удовольствии пошариться по этому репозиторию. Там много и других скиллов. Может быть полезно. </div>

Да и opencode, внезапно, куда менее стабильный. Постоянно разламывается в новых версиях. Смотрю на сообщения в чатах от коллег. Да и у меня он однажды просто перестал запускаться.

Хватит пи-агента

2026-06-19T00:00:00+00:00

Я боюсь сложных вещей. Когда я прочитал что Opencode использует React для рендера TUI в консоли - мне стало страшно. Я не считаю себя минималистом, но к простоте стремлюсь.

И когда я читал - всякие там субагенты, инструменты, mcp - мне казалось страшным и сложным. И подвернулся мне, сначала, minimal-agent</a>. А потом я попробовал pi-agent</a>.

tldr; По-мере накопления опыта работы с пи-агентом, я поставил на него расширения, что превращают его в claudecode/opencode. Только более багованный (субагенты, например, постоянно теряли git worktree где находились).

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

Осталось понять - а это чуть более глубокое понимание работы надо вообще?

Всё не так и просто</a></h2>
Пи-агент подкупил меня простотой. Продаёт он себя офигенно. Марио, создатель пи-агента пишет про то, что mcp не нужны</a> - достаточно скриптов с утилитами. Субагенты тоже не нужны - используйте tmux + pi</a> (на самом деле, так никто не делает).
Немного попользовавшись в обозначенном Марио ключе, я быстро понял что так жить нельзя таки начал агрессивно расширять агента. Писать для него скиллы, скрипты</a>. Адаптировать системный промпт под конкретную модель (pi-qwen</a>). Идею про то, что пусть агент сам пишет расширения для себя 1</a> я прочёл благодаря тому, что читал блоги авторов пи-агента.
^1
Кажется, я прочёл об этой идее тут</a>. Там ещё mcporter упомянут. Тоже его использую с пи-агентом. Но там блог автора в целом достоин ознакомления. </div>
Однако, с этой расширяемостью есть и другая проблема - я устал. Расширение для субагентов постоянно теряет git worktree. Не знаю почему, но разбираться, если честно, лень.
То что у пи-агента минималистичный tui-рендер - да пофиг. Мне не нравится идея TUI в целом</a>. Любители юникс-вея - делайте пайпы из команды и сохраняйте их как скрипты, а не скачите по псевдосимвольным интерфейсам при помощи hjkl и команд. Правда это тоже отстой.
grep который недоступен</a></h2>
Пи-агент поставляется с двумя бинарниками - fd и rg. Удобно. Только они недоступны по-умолчанию. Есть пара инструментов - grep и второй для просмотра директорий (каюсь, забыл как называется, а искать название пока пишу заметку лень), и оба они недоступны для моделей по-умолчанию. Почему? Хз. На реддите кто-то писал, что написал расширение для пи, которое их включает.
расширение на каждый чих</a></h2>
На удивление, Пи-агент не так уж удобен для расширения. Например, если хочешь как-то условно (по-условию) изменить системный промпт - пиши расширение. Не декларативненько. В итоге ты пишешь расширения, которые взаимодействуют с другими расширениями, делаешь форки других расширений чтобы изменить в них что-то (например, чтобы писались логи субагентов). С одной стороны - это своеобразный pi-way. С другой, по-примеру совета запускать субагентов через tmux (я пробовал, это дичь) видно, что это не продуманный концептуализм и минимализм, а ответ на отъ***сь.
В заключение</a></h2>
Играя с пи-агентом я получил опыт что да как в этом мире агентской разработки. Есть возможность пробовать разные подходы к субагентам, разные расширения для задач. И главное - можно избежать шока сложности и новизны, с которым сегодня сталкиваются многие разработчики впервые запускающие агентов.

Знакомлюсь с Rust. Мысли

2026-05-12T00:00:00+00:00

На выходных решил засесть за The Rust Programming Language</a>
Почему?</a></h2>
Есть у меня одна мулька - хочу заняться мультиплатформенный геймдевом in hard way. Преимущественно под веб. Что-нибудь минималистичное и компилируемое. Думал в пользу Go + Ebiten. Начал nature of code, выполняя упражнения на tinygo. Но в итоге отказался по-причине жирного рантайма под веб.
Думал и о чистом Си + raylib какой… Но все-таки, чистый Си это тумач для меня. Хотя есть книжка Modern С, есть новый стандарт Си… Но энивей, Си у меня оставил послевкусие старого джаваскрипта, как бы смешно это не звучало.

Нет чего-то похожего на менеджер пакетов. Все изголяются по-своему.</li>
Сборка проектов - отдельный прикол.</li> </ul>
После мира победившего коммунизма (всяких там Го, Руби) понимаешь, что инфраструктура языка важна.
И таким образом (минималистичные бинари, современная инфраструктура около) я решил ознакомиться с Раст.
Не хочу графоманить, скрупулёзно собирая примеры в коде что мне понравилось. Но списочком поделиться хочу.
match выражение</a></h3>
Выглядит красиво обработка ответов через него. Как и if let - который можно использовать для работы с только ожидаемым результатом. Вообще, мне нравится что в дизайне языка заложено обрабатывать все кейсы. Отсутствие null. Это, конечно, требует от разработчика продумывать все варианты при написании кода, нежели продумывать желаемую цепочку, но код в результате будет вести себя корректнее, чем спагеттина в си/джаваскрипт - стиле.
Возврат значения последнего выражения</a></h3>
Когда последняя выражении в блоке, не оканчивающееся на ;</code> возвращается из тела. Без всяких return.
Популярные открытые модельки, доступные по api от cloud-ru 2026-05-10T00:00:00+00:00 Давно не проверял, а оказывается cloud.ru запустили новый сервис - Foundation models</a>. Простыми словами - это популярные модельки (qwen, qwen-coder, glm, minmax) - запущенные у них в облаке. Ты просто делаешь токен для доступа к ним и пользуешься по openapi-compatible апи. Раньше у клауд-ру был сервис для поднятия произвольных моделек - но я не сдюжил с настройкой. В общем, я пользуюсь сейчас сам, ну и вам советую потыкать. models.json для pi-агента</a></h2> Файлик для подключения - models.json</a>. apiKey только свой укажите. Можно сгенерировать свой аналогичный. Для списка моделей я использовал метод /models</a> апи. Для других агентов плюс-минус аналогичный конфиг должен быть. Рекомендуемые модельки</a></h2> Мне на почту пришло ещё письмо, где они уведомляют от отключении устаревших моделек, и предлагают им замены: Qwen3-235B-A22B → Qwen3.5-397B-A17B</li> Qwen3-Next-80B-A3B → Qwen3.6-35B-A3B</li> MiniMax-M2 → MiniMax-M2.5 При этом 12 мая отключим модели GLM-4.6 и Qwen3-Coder-480B. Вместо них рекомендуем перейти на GLM-4.7 и Qwen3-Coder-Next — они уже доступны в сервисе.</li> </ul> </blockquote> Руби или Перл 2026-04-18T00:00:00+00:00 Размышляя о том, какой скриптовый язык лучше пройдет через сито “минималистичности”, я задался вопросом - Руби или Перл? И мой короткий ответ на это: Перл это если надо написать сценарий больше пяти строк.</li> Руби это окружение для скриптов уровня энтерпрайз.</li> </ul> Perl</a></h2> Перл находится в пересечении нескольких множеств: Идёт, например, в составе OpendBSD. OpenBSD тут как показатель взглядов. Некоторые системные утилиты написаны на Перл</li> </ul> </li> Лучше подходит для скриптов, нежели оболочка.</li> Достаточное количество батареек в комплекте</li> </ol> Тем не менее, Перл в таком ключе именно что интегрирован в системное окружение. Нежели предоставляет своё окружение. Ruby</a></h2> Руби же, предоставляет собственное окружение для скриптов: Rake как система сборки проекта. Создания конвейера из задач1</a></li> Rspec для тестов</li> Единое соглашение для организации гемов (lib, spec - вот это всё)</li> </ul> В общем, джентльменский набор любого современного проекта. Но из коробки. ^1Юникс-утилиты для работы с данными</a> </div> Из этого у меня родилось видение: Если устраивает системное окружение и хочешь в нём написать скрипт - Перл</li> Если пишешь что-то большое и изолированное - бери Руби</li> </ul> </blockquote> Разочаровался в идее цифровых садов 2026-04-08T00:00:00+00:00 Инсайт пришел ко мне внезапно. Ютуб мне постоянно (интересно даже, почему) любит рекомендовать ролики по ведению бумажных ежедневников, календарей и конспектированию. И листая череду превьющек, я ощутил простую мысль: А зачем нужны эти конспекты? Даже красивые</li> </ul> Скажем, мне бывает интересно поделиться с миром какой-либо находкой. Или размышлением. И пойти дальше. Зачем пытаться их склеить в какую-либо целостную вики? Да и в личных заметках - я не вижу смысла в этой целостности. Обычно я просто ищу по-тексту в директории со своими заметками</li> </ul> Ну и протыкать соседние по-дате заметки. Big picture</a></h2> По-идее, вся эта связность нужна, чтобы получился граф, типа с облачками, где можно увидеть неочевидные связи… Хрень какая-то. Вообще, куда важнее это просто регулярное журналирование. Сколько раз я себя корил за то, что не сделал ридмишку или не записал как я что-либо делал в прошлом. Отложил момент записи на чуть позже… Запустить статический сервер одной строкой 2026-04-05T00:00:00+00:00 Я, как фронтендер, пользуюсь npx http-server</code>. Мне его хватает. Но нашел github gist Big list of http static server one-liners</a> где куда больше вариантов. И ещё в комментах обсуждение. Не в движке счастье 2026-04-04T00:00:00+00:00 </a> </figure> Самодельный генератор статического сайта на юникс-утилитах 2026-04-04T00:00:00+00:00 Полноценные shell-ssg</a></h3> mkws</a></li> ssg.sh</a> от Романа Золотарёва</li> mksite</a> прямо как Уриель завещал - rc, mk…</li> </ul> </li> zodiac</a> - a static website generator powered by sh and awk.</li> </ul> Make</a></h3> Fast Static Site with make</a> Static Blog Builder</a> - Предвестник статьи</li> </ul> </li> </ul> Отличие Hugo и прочих от ssg 2026-04-04T00:00:00+00:00 И все-таки, зуд продолжался в течении дня. Смотрел я на простенькие ssg</a> и понял одну вещь. Перевести маркдаун в html - проще простого. Но ssg типа Hugo, Jekyll и 11ty - это скорее системы публикации или даже что-то типа cms. В них есть таксономия - теги и категории, как в Hugo.</li> Работа с медиа - пожать картиночки.</li> Можно создавать страницы не просто из маркдаун-файликов, а из любых данных - типа json.</li> </ul> Всякие там хитрые шаблоны и шорткоды (shortcodes) ещё. В общем, мысль простая - да, за вечер можно написать скрипт, который переведет маркдаун в html, и даже картинки будет нарезать. Но вот уже с таксономией будет сложнее. Юникс хостинг 2026-04-02T00:00:00+00:00 Во-первых, как такового термина юникс хостинг</code> - нет. Это придуманное название, которое я встретил в заметке: Comments on Shared Unix Hosting vs. the Cloud</a> </blockquote> По-сути, это что среднее между классическим shared-хостингом1</a> и shell-хостингом (типа sdf.org). Типа sdf, но платный. ^{1 У нас я встречал термин “Виртуальный хостинг” </div>}В наших реалиях, я такое встречал (и даже использовал) у своего хостера - adman.com</a>. По-сути, в админке ispmanager можно включить cgi-скрипты. Будут работать шелл (bash, sh) -скрипты, на ощуп нашёл интерпретатор perl и python. Да, это лишь приближение к тому, что хотелось бы… Но хоть что-то. Зачем оно вообще надо? В статье исчерпывающе описано удобство промежуточного между vps и “виртуальным” хостингом. Я не хочу заниматься администрированием машины. Мне достаточно: Пользовательской оболочки</li> “Виртуального” apache или nginx сервера</li> Возможности запускать свои скрипты</li> </ul> Я не хочу с нуля настраивать сервер, добавлять пользователей (одного - себя), обновлять пакеты и прочее и прочее. Try - управление проектиками 2026-04-01T00:00:00+00:00 Каким-то чудом, я набрёл на утилитку try - fresh directories for every vibe (gh)</a>. Шутка в том, что я ей не пользовался, но мне показались интересными в ней пара вещей: Отличная демонстрация того, почему именно руби. на макоси он идёт в системе</li> </ul> </li> Один файл, без зависимостей утилитки и должны быть такими. Кидаешь их в какой-нибудь ~/bin</code> и оно просто работает</li> </ul> </li> </ol> Ещё там из интересного - есть и AGENTS.md и функционал покрыт тестами. В общем, всё как надо. И также случайно набрёл на try-rs (gh)</a>. blazingly fast ⚡</li> rs - не просто так. Написано на rust 🦀</li> </ul> В общем, популярная тема. Я же по-старинке пока что, завожу новые папочки в ~/dev</code> Генератор статических сайтов вдохновленный werc 2026-03-31T00:00:00+00:00 Слежу за triapul.cz/</a> и в подсайтах нашел до боли знакомый дизайн: Is this werc? </blockquote> nein, this is nein is a static website generator written in ksh, inspired by werc. It has no other dependencies. I didn’t actually read werc code, I just plagiarazed how it looks. – nein.triapul.cz/nein/</a> </blockquote> Находчиво, забавно. Правда, ожидал что там используется оригинальный werc. Build Awesome (11ty) 2026-03-10T00:00:00+00:00 Штош, 11ty ВСЁ. Оказывается, к 11ty v4 ребята задумали ребрендинг. Но не просто ребрендинг. Ключевой разработчик 11ty (и его автор, вроде как) Zack Leatherman</a> устроился в Font Awesome. И теперь ребята хотят сделать Build Awesome Pro как продукт, основанный на 11ty, который теперь Build Awesome. Как-то упустил это всё, пока не увидел пост у Brennan.day - The End of Eleventy</a> и Build Awesome’s Kickstarter is Cancelled</a> Там вышло слегка комично. Ребята решили запустить Kickstarter-кампанию. Рассылка не пошла всем кому надо и ребята решили перезапустить</a> эту кампанию. Вообще, успокаивают что 11ty</del> останется свободным и будет развиваться. Бреннан не верит. Ну да и ладно. Хочу же заметить, что 11ty реально впечатляющий проект, скажем, done right. Что не так с Go. Цитаты 2026-02-28T00:00:00+00:00 Антон на стримах</a> Вот «On bloat»: запись стрима на yt</a></li> Вот критика: запись стрима на yt</a></li> </ul> Рассказал про доклад On bloat Роба Пайка и коротенько коснулся критики (Pike is wrong on bloat</a>). Пайк ис вронг - лайтовенький разговор про зависимости. Но листая бложик нашел парочку занимательных постов: Why Go is not my favourite language</a> Go, на самом деле, имеет механизм исключений. И предупреждения компилятора</li> </ul> </li> Go is still not good</a> Two types of nil</li> проблемы с переносимостью</li> проблемы с работой c не utf-8</li> </ul> </li> </ul> А потом нашел золото. Золото</a></h2> В самое сырдечко мне попали несколько статей. Я сохранил себе понравившееся фрагменты, но ознакомления достойны обе статьи. I want off Mr. Golang’s Wild Ride</a></a></h3> Simple is a lie Most of Go’s APIs (much like NodeJS’s APIs) are designed for Unix-like operating systems… …( Дальше большой фрагмент с примерами, где показывается что на винде многие вещи (от прав доступа к файлам, до парсинга путей) отличаются в поведении. И местами реализация просто отсутствует. )… </blockquote> “But these are little things!” They’re all little things. They add up. Quickly. And they’re symptomatic of the problems with “the Go way” in general. The Go way is to half-ass things. The Go way is to patch things up until they sorta kinda work, in the name of simplicity. </blockquote> Parting words Over and over, Go is a victim of its own mantra - “simplicity”. It constantly takes power away from its users, reserving it for itself. It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness. It is a minefield of subtle gotchas that have very real implications - everything looks simple on the surface, but nothing is. </blockquote> fake “simplicity” runs deep in the Go ecosystem. Rust has the opposite problem - things look scary at first, but it’s for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately. At this point in time, I deeply regret investing in Go. Go is a Bell Labs fantasy, and not a very good one at that. </blockquote> If folks walk away with only one new thought from this, please let it be that: defaults matter. Go lets you whip something up quickly, but making the result “production-ready” is left as an exercise to the writer. Big companies that have adopted it have developed tons of tooling around it, use all available linters, do code generation, check the disassembly, and regularly pay the engineering cost of just using Go at all. </blockquote> Lies we tell ourselves to keep using Golang </a></a></h3> Evidently, the Go team didn’t want to design a language. What they really liked was their async runtime. And they wanted to be able to implement TCP, and HTTP, and TLS, and HTTP/2, and DNS, etc., on top of it. And then web services on top of all of that. And so they didn’t. They didn’t design a language. It sorta just “happened”. Because it needed to be familiar to “Googlers, fresh out of school, who probably learned some Java/C/C++/Python” (Rob Pike, Lang NEXT 2014), it borrowed from all of these. Just like C, it doesn’t concern itself with error handling at all. Everything is a big furry ball of mutable state, and it’s on you to add ifs and elses to VERY CAREFULLY (and very manually) ensure that you do not propagate invalid data. </blockquote> … you are living in the Plan 9 cinematic universe. The Go toolchain does not use the assembly language everyone else knows about. It does not use the linkers everyone else knows about. It does not let you use the debuggers everyone knows about, the memory checkers everyone knows about, or the calling conventions everyone else has agreed to suffer, in the interest of interoperability. Go is closer to closed-world languages than it is to C or C++. Even Node.js, Python and Ruby are not as hostile to FFI. </blockquote> … Making Go play nice with another language (any other language) is really hard… Calling Go from anything involves shoving the whole Go runtime (GC included) into whatever you’re running: expect a very large static library and all the operational burden of running Go code as a regular executable. After spending years doing those FFI dances in both directions, I’ve reached the conclusion that the only good boundary with Go is a network boundary. Integrating with Go is relatively painless if you can afford to pay the latency cost of doing RPC over TCP </blockquote> … All or nothing (so let’s do nothing) (там большой кусок, который я не вижу смысла перепечатывать целиком. А цитировать куски - потеряет наглядность. Вкратце, там про то, что где-то язык прощает не-инициализированные значения, а где-то нет и требует их. Это непродуманность языка. И требует кучу повсеместных проверок) … </blockquote> </blockquote> Go as a prototyping/starter language Go is an easy language to pick up (because it’s so small, right?) … All the complexity that doesn’t live in the language now lives in your codebase. </blockquote> Шелл и реактивность 2026-02-02T00:00:00+00:00 Листая публикацию про scsh 1</a> наткнулся на пару интересных иллюстраций: … Это мне напомнило другую матрицу, объясняющую что такое observables в rxjs: Узнали? Согласны? </figcaption> </figure> И там (раздел The Tao of Scheme and Unix2</a>) подаётся интересная мысль и интересная находка для scheme-оболочки: Большинство попыток встроить системную оболочку в функциональные языки программирования пытаются скрыть разницу между вызовом программы и вызовом объявленной функции. Если пользователь вводит (lpr "notes.txt")</code> оболочка сначала воспринимает lpr</code> как функцию. Если lpr не найдена среди объявленных функций, оболочка выполняет поиск программы в PATH</code>. Эта прозрачность - аналогия к вызову функций в традиционных оболочках, таких как ksh. Это фундаментальная ошибка… Эти две вычислительные модели фундаментально разные. Любая попытка их смешать, а не разграничить, приведет к уродливой и неконсистентной семантике. В мире прилагаемых3</a> функций, агенты исполняются последовательно, и организованы с помощью функциональной композиции: (g (f x))</code>. В мире процессов, агенты исполняются одновременно, и организованы в конвейеры (pipes) потоков данных: f | g</code>. </blockquote> Есть о чём подумать. И о том, что классические шеллы (ksh, bash и прочие) действительно, смешивают эти вещи для упрощения, так и то, что это, и правда, несочетаемые вещи. ^1A Scheme Shell Olin Shivers [Personal Information Architecture Note 3 4/1994](сохраненная копия)</a> </div> ^{2 признаюсь, меня привлекло tao в оглавлении, решил посмотреть. </div> ^{3 Прикладных? Прикладываемых? </div>}} Юникс-утилиты для работы с данными 2026-01-15T00:00:00+00:00 Снова и снова смотря (зачем?) на табличку harmful/less-harmful</a>, вижу в ней |-----------|--------| | Perl, Ruby|rc, awk | |-----------|--------| </code></pre> В целом, окружение юникс имеет достаточно инструментов для работы с данными. Больше того, оно для того и создавалось. AWK на вход ожидает tab-separated строки (ну, типа таблички). У меня на этот счёт скопилась парочка ссылок. Может кому-нибудь, когда-нибудь… (мне просто жаль их просто так терять, и хочется поделиться ими с миром) Using Unix Commands for Data Science</a></h4> https://matheusrabetti.github.io/data%20analysis/command-line-datascience/ Базово-вводная. От простого к сложному. И тут есть ссылка на следующую статью. Обозначена она как Command line tools vs Hadoop </blockquote> Command-line Tools can be 235x Faster than your Hadoop Cluster</a></h4> https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html На эту статью ссылается и suckless.org. Они её обозначили как Use of command-line tools for effective data processing – Philosophy, Related links</a> </blockquote> Солидно. Это что-то, да значит. Листал, классно посмотреть на конвейеры. Глубоко не вникал. Why Use Make</a></h4> https://bost.ocks.org/mike/make/ Встретил её в замечательном блоге про osh/ysh</a> Действительно, зачем?</a></h5> tldr; Makefiles are machine-readable documentation that make your workflow reproducible. </blockquote> Обработка данных - процесс нелинейный. Скачать файл тут, другой там. Распаковать и совершить преобразования. Можно, конечно, написать скрипт, но зачем, когда есть готовый инструмент, который 50 лет под рукой и позволяет описать и повторять декларативно это всё как зависимости. Синтаксис сложный, но для базового использования не обязательно знать его глубоко. Ещё один сайт, вдохновлённый Эдом Тафти 2026-01-10T00:00:00+00:00 Наткнулся на ссылочку - A website to destroy all websites</a> Узнаю знакомый стиль. Но классно доработан. Про Тафти я собирал страницу</a> (в архиве). Вообще, страница классно свёрстана. Да и сайт</a> в целом. Для вдохновения. Кнут, посрамлённый шестистрочником 2026-01-04T00:00:00+00:00 Не первый раз встречаю эту историю. Её преподносят как идею о превосходстве философии Юникс, где заносчивые снобы оказываются посрамлены находчивыми инженерами со скотчем. На мой взгляд, эта история впечатляет по-другой причине. Краткое изложение</a></h2> Оринал (pdf)</a> В июне 1986-го выходит статья про литературное программирование. В ней, автора методологии, Дональда Кнута просят продемонстрировать подход и решить тривиальную задачу: Написать программу, которая принимает текстовый файл и целое число k. Программа должна вывести список из k наиболее часто встречающих слов, в порядке убывания. </blockquote> Дональд демонстрирует своё решение. Он использует собственную систему литературного программирования WEB. Он демонстрирует всё, от парсинга числа, до разбора строк по-словам, приведение к единому регистру (нижнему) и функцию вывода результата. Решение занимает семь(!) страниц печатного текста! Маккилрой, которого попросили отрецензировать Кнута, обсуждает недостатки системы WEB, слабые алгоритмические места (например, привязку к латинскому алфавиту) и предлагает пойти дальше и дополнять человекочитаемый код ещё и наглядной диаграммой. А потом предлагает заменить семь страниц шестью строчками 1 tr -cs A-Za-z ' ' | 2 tr A-Z a-z | 3 sort | 4 uniq -c | 5 sort -rn | 6 sed ${1}q </code></pre> И рядом также шесть небольших строчек с объяснением каждой команды. {: .fullwidth} И после такого, уже как-то пофиг, что Кнут написал свой пример совсем с другой задачей - продемонстрировать литературное программирование. Рецензия Маккилроя получилась вещью в себе с очень наглядной разницей в подходах. Кнут и Маккилрой стукаются яичками</a></h2> Из этой заметки делают далеко идущие выводы. Например: https://mattrickard.com/instinct-and-culture</li> https://leancrew.com/all-this/2011/12/more-shell-less-egg/</li> </ul> Тут и философия Юникс (которая имхо, сформировалась сильно опосле смерти самого Юникса), и сильные аналогии (яйцо Фаберже Кнута против стальных яиц Маккилроя). На мой взгляд, пример Маккилроя это отличный пример того, когда меньше это больше (less is more). Короткие наглядные команды лучше подробных многословных инструкций. Короткое и наглядное - самоочевидное. </blockquote> А самоочевидное не требует никаких сложных систем. Korn shell - posix и светлое будущее, которое не случилось 2026-01-01T00:00:00+00:00 Я не вникал в это раннее, просто по-близости упоминаний считал что Bourne shell и есть тот самый posix. Оказывается, нет. Точнее, не совсем. Я со своей фиксацией на Bourne-shell не заметил слона в комнате - Korn shell. А зря. Именно он задал направление развития остальным (bash, z shell), сам став основой для стандарта. А потом его вообще попытались довести до полноценного высокоуровневого языка. Погубила его жадность AT&T. 2 тыщи долларов за лицензию. Я нашел несколько публикаций, достойных ознакомления: Ksh - An Extensible High Level Language. David G. Korn1</a> pdf</a></li> AT&T charged $2,000/site for the Korn shell (ссылка)</a></li> </ul> ^1я так понимаю, что эта публикация была подготовлена для конференции проходившей в октябре 1994-го года</a>. текст</a> </div> Дальше, краткая выжимка из них. Оболочки были неудобны</a></h2> В 80-х оболочкой по-умолчанию был Thompson shell. Ему на смену пришла оболочка Боурна (Bourne shell) в Юникс V7. В неё добавили управляющие инструкции (if, switch, for), но она все ещё была неудобна для интерактивного использования. В ней отсутствовали привычные нам: редактирование строк (readline)</li> автодополнение для команд и имён файлов по tab (tab completion)</li> ~</code> для ссылки на домашнюю директорию</li> псевдонимы для команд (aliases)</li> история команд</li> управление процессами</li> </ul> Чтобы проникнуться атмосферой тех времен - можно попробовать dash. Korn shell</a></h2> Внутри AT&T Дэвид Корн (David Korn) доработал оболочку Боурна и получился ksh - Korn Shell. Коллеги переходили на него и он стал де-факто стандартом внутри компании. Однако, он не был свободным. AT&T предлагали оформить на него лицензию - за 2000 долларов (в нынешних долларах, с учётом инфляции, все 6000). Это было очень дорого хоть для частных лиц, хоть для организаций. Bash</code> (1989) и pdksh</code> (1989) появились как свободные реализации, похожие на ksh, но не полностью совместимые с ним. Стандартизация произойдет лишь в 1992-м. Появится стандарт того самого Posix shell - POSIX.2 (IEEE POSIX 1003.2 и ISO/IEC 9945-2). По-сути, он будет похож на ksh 88-го года (ksh88). Работа над ksh была продолжена. ksh93</a></h3> C оглядкой на awk, perl, tcl появился ksh93. Заявленная цель - довести язык оболочки до полноценного высокоуровневого языка. Встроенная работа с арифметикой (раньше использовалась утилита expr</code>)</li> Ассоциативные массивы</li> Дополнительные возможности работы со строками расширенные регулярные выражения (Extended regular expression), как в awk, perl, tcl</li> новые операторы для работы со строками</li> операторы можно применять к элементам массива, ассоциативного массива</li> </ul> </li> вложенные пространства имён теперь переменная это больше чем просто ячейка для хранения значения. Можно делать геттеры для переменных</li> </ul> </li> </ul> и прочее и прочее. Можно расширять список встроенных функций собственными, написанными на Си (надо слинковывать и собирать). Можно встраивать ksh93</code> как язык сценария, как tcl или lua. Можно было разрабатывать графические приложения (на motif-виджетах, wksh) Круто! Но ksh93</code> оставался не под свободной лицензией. Он будет опубличен лишь в марте 2000 года (kornshell faq</a>, q10)! И продолжал разрабатываться до 2012-го. ksh93 сегодня</a></h2> Сейчас ksh93 развивается сообществом - ksh93/ksh (github)</a> Из коробки в Макоси есть последняя выпущенная AT&T версия ksh93 $ which ksh /bin/ksh $ ksh --version version sh (AT&T Research) 93u+ 2012-08-01 </code></pre> Как появились скрытые файлы 2025-12-15T00:00:00+00:00 Байка уровня “почему диаметр ракеты не может быть больше двух лошадинных задниц”</a>, только правдивая. Рассказана одним из отцов Юникса - Робом Пайком. Бережно сохранена</a> Xah Lee. А вспомнил я про неё, читая блог Дэна Кросса (Dan Cross) с его пропозалом, хранить дотфайлы в $HOME/etc</a>. Вкратце, когда делали иерархичность файловой системы в первых версиях Юникс, добавили сущности .</code> и ..</code> для ссылки на текущий каталог и вышестоящий. Так-то они с нами до сих пор. % cd `mktemp -d` && ls -a . .. </code></pre> Но при выводе каталога они мешались, и в ls</code> просто добавили скрытие всех членов каталога, чьё имя начиналось с точки, вместо того, чтобы исключать конкретно .</code> и ..</code>. Вот и всё. Легким движением руки у нас появились скрытые файлы и папки. И вот туда уже все полюбили класть всякие конфиги, бэкапы… И теперь домашний каталог пользователя это помойка с мусором, заметённым под точку. Роб предлагает пару выводов: дескать, думайте о последствиях небольших хаков и, дескать, в Plan9 это “исправили”. Но очевидно, что традиция уже сложилась и с нами навсегда. Собственно, возвращаясь к пропозалу - ~/etc прикольно, но тот же XDG советует пихать всё в .config. И вот у нас уже 15 несовместимых стандартов</a>. Дотфайлы - файлы или каталоги, которые начинаются с точки и скрыты по-умолчанию. Типа .profile</code> или .ssh</code>. Nature Of Code сделанный на Go 2025-12-13T00:00:00+00:00 Пройдя Go Tour захотелось немного закрепить свои навыки с Go. Но делать очередную вебню не хотелось, а хотелось чего-то творческого. Посмотреть в браузере.</a> Листая реддит, снова наткнулся на обзорную статью про creative coding. И там хороша вся серия - хотя бы картинками. The Importance of Sketching with Code</a></li> Creative Coding: The New Era</a></li> Getting started with P5JS</a></li> </ul> P5js - часть проекта Processing.org</a>. Там про обучение программированию, вот это всё. И в рамках это всего выпущена и “книга” - NATURE OF CODE</a>. На сайте она полностью доступна с живыми примерами/скетчами. Взяв её за основу я решил попрактиковаться. Исходники на гитхабе</a>. Я не первый кто решил повыполнять упражнения на Go. Есть пример на Go + Ebiten</a> (2д движок на Go). Но мне принципиально хотелось без всяких библиотек, максимально просто. Оттуда я взял пару функций. Такие штуки, мне кажется, принципиально делать на единственной доступной мультиплатформе - для веба. Ведь как сегодня, в 2к25, поделиться чем-то “живым”, что можно запустить, а не опостылевшей гифкой? Со мной желание сделать максимально просто эти примеры сыграло злую шутку. Хоть Go собирается под wasm, рантайм жирноват, и получается очень большой .wasm-файл. Разработчики языка не ставят перед собой цели чтобы бинарь был максимально компактным. Но есть tinygo</a> для embed и wasm. Но это сторонний проект, не от разработчиков Go. И там не все возможности языка поддерживаются. И тут я понял, что такое Go. Суть Go</a></h2> Мне кажется, что Go стоит не пересечении нескольких идей. Первая - это потоки вдохновленные Erlang. Вторая - это сделать прикладной язык типа Руби, Джаваскрипта или Питона, но чтобы он был скорее вдохновлен Си (не сколько синтаксически, а скорее идейно), нежели Перлом, Схемой (Scheme) или просто отвратительным вкусом (я терпеть не могу Питон). То есть, не надо воспринимать Гошку как Си со сборкой мусора, а скорее как альтернативу для Питона или Джаваскрипта. Acme Zsh 2025-11-23T00:00:00+00:00 Про странные символы при использовании zshell внутри терминала Win. Написано здесь</a>. Да, unset zle_bracketed_paste</code> помогает. Но не каждый же раз это вводить. Хочется сделать как-то красиво. Чтобы, устанавливалось лишь когда zsh внутри Acme. Ещё, лишний перевод строки бы убрать. Я в дополнение к ~/.zprofile</code> создал файл в домашнем каталоге .zshrc</code> - он исполняется в каждом экземпляре оболочки. Там я сделал проверку - что есть WINID</code> - переменная окружения, которую выставляет Acme процессам в окнах. # чтобы zsh не гадил в Win терминал acme штуками типа ^[[?2004h if [[ -n $winid ]]; then # Отключение ZLE для предотвращения проблем с отображением символов setopt no_zle # Включаем обработку возвратов каретки # setopt promptcr setopt nopromptsp fi </code></pre> Ну и при запуске acme - acmeshell=zsh</code> не забыть. Вуаля! Tinygo Wasm 2025-11-23T00:00:00+00:00 Несколько заметок, как я заводил сборку go кода под wasm. Установка tinygo руками</a></h2> Можно поставить через brew</code>, но я не ищу лёгкий путей. cd $(mktemp -d) curl -L -O https://github.com/tinygo-org/tinygo/releases/....tar.gz tar xf tinygo0.39.0.darwin-arm64.tar.gz sudo mv tinygo /usr/local </code></pre> Добавить tinygo ручка в path. ~/.zprofile ... # --tinygo export PATH=$PATH:/usr/local/tinygo/bin ... </code></pre> Однако % GOOS=js GOARCH=wasm tinygo build -o wasm.tinygo.wasm ./main.go error: could not find wasm-opt, set the WASMOPT environment variable to override </code></pre> Упс, какой wasm-opt? ;tldr curl -L -O https://github.com/WebAssembly/binaryen/releases/download/version_125/binaryen-version_125-arm64-macos.tar.gz tar xf binaryen-version_125-arm64-macos.tar.gz sudo mv binaryen-version_125 /usr/local/binaryen </code></pre> Ну и PATH поправить: ... # --tinygo export PATH=$PATH:/usr/local/tinygo/bin # -- binarien - нужено для tinygo export PATH=$PATH:/usr/local/binaryen/bin ... </code></pre> wasm_exec.js - взять из tinygo</a></h2> В примерах wasm-а хоть и указано</a> что wasm_exec.js отличается от обычного, гошного. Но я как-то не сразу понял. cp /usr/local/tinygo/targets/wasm_exec.js ./ </code></pre> n-t-roff 2025-11-17T00:00:00+00:00 Одна из важных вех в истории Юникс - когда в него добавили roff. Со временем он стал troff - для вёрстки документов на бумаге. Nroff - для вёрстки того, чтобы будет распечатано на обычных текстовых (символьных) принтерах. Groff - реализация troff от GNU. Самый популярный пакет из семейства. Neatroff</a> - лёгкий, по-сравнению с groff Heirloom</a> - тоже популярный пакет, с troff. По-большому счёту, сегодня roff-семейство хоть и используется, но популярность значительно уступает TeX. Популярно подмножество языка roff для написания руководств - mandoc. Я на полштыка интересовался этой темой. Про man</a> PIC</a></h2> Препроцессор для рисования картинок, диаграмм. Графические элементы и команды для их рисования. Plan9port имеет svgpic(1)</a> - превращает pic-команды в svg. Graphviz умеет выводить</a> свои диаграммы в PIC Pikchr</a></h3> вдохновленный PIC процессор, который возвращает SVG вместо troff-команд. Pikchr документация</a> Предполагается использовать вместе с markdown. https://janert.me/guides/praise-of-pic/ - ознакомительная статья. Апп-покалипсис сегодня. Поляризация крайностей 2025-11-16T00:00:00+00:00 В чатике токсов openbsd скинули ссылку на отличный пост</a> в блоге Аркана</a> - про принципы, которыми руководствуются в проекте. Некоторые из этих принципов, имхо, достойны быть переведены на русский. Так называемые, ‘смартфоны’ в свою ‘догнать и перегнать j2me-телефоны’ эпоху, сделали правильно несколько вещей. Одной из таких вещей было появление ‘приложений’(app); Простые, маленькие инструменты, решающие одну конкретную задачу. В то же время, эти приложения плохо взаимодействовали друг с другом (отсутствие сочетаемости) и, как следствие, было трудно комбинировать их для создания новой функциональности (отсутствие композиционности). В широком смысле, экосистема выродилась в прослойку, провожающую пользователя до приложения конкретного сервиса, нежели что-либо ещё. На десктопе, пользовательские интерфейсы встречаются, преимущественно, трех типов. Первый из них - это приложение “в себе”: сложные изолированные окружения, которые лучше всего представить как машину внутри машины (другими словами - виртуальная машина). Например, веб-браузер (Electron). Встреча с ними - неизбежна, кроме как вы не совсем крайний аскет. Второй тип - на другом полюсе спектра сложности, это относительно простые инструменты текстовой обработки основанные на конвейерах и фильтрах, такие как ‘awk’ и ‘grep’. А также чуть более интерактивные терминальные пользовательские интерфейсы (TUIs) - подмножество интерфейсов командной строки (CLIs). Они весьма ограничены своим наследием, выросшим из последовательных строк (serial lines) и терминалов c символьной графикой. Последний, третий тип - это бескрайнее пространство между предыдущими двумя, многомиллионные строчки UI-библиотек. Они обладают такой же сложностью, как и виртуальные машины, и не менее устаревшим наследием, чем терминалы. Нет чёткой границы между этими категориями. Браузер полагается на ui-библиотеки для интеграции с операционной системой, чтобы потом переопределить большую их часть в собственном стиле. Терминальные интерфейсы полагаются на виджеты из, буквально, проклятых1</a> абстракций в поиске убежища от взрыва из прошлого - терминальных протоколов. ^1в оригинале игра слов - curs(es)ed. Curses</a> – название библиотеки для создания текстовых интерфейсов (TUIs) в Unix-подобных системах. Cursed - проклятый. </div> Plan9port rc profile файл 2025-11-09T00:00:00+00:00 Во-первых, в этом нет сильно большого смысла. Мне трудно поверить что кому-то придет в голову реально использовать rc</code> как login-shell. Но, если что, profile</code> файл для rc</code> по-умолчанию ожидается в $home/lib/profile</code>1</a>. ^{1 https://github.com/e41q/p9port-utils/blob/main/lib/profile </div> Чтобы rc</code> при запуске его прочел, надо вызвать rc</code> командой}rc -l </code></pre> Там ещё есть про -</code>аргумент, но я этого не понял. If −l</code> is given or the first character of argument zero is −</code>, rc reads commands from $home/lib/profile</code> </blockquote> Я смог что-то выпытать</a> из гигачата. Возможно, это имеет смысл при создании шелл-скриптов, и назвать их со знака минус. rc(1)</a> Зачем это мне?</a></h2> Хочу внутри Acme, когда использую win + rc, чтобы всякие утилиты типа ps, ls и прочие - были из plan9port. Для этого, в скрипте запуска acme # To use a given shell (not the user's default) in win, set the SHELL environment variable SHELL=9rc # To use a given shell for button 2 execution, set the acmeshell environment variable acmeshell=9rc </code></pre> А сам скрипт 9rc: #!/usr/bin/env rc exec rc -l $* </code></pre> Несколько экземпляров редактора Acme 2025-11-05T00:00:00+00:00 Иногда бывает удобно разделить активность по нескольким окнам редактора Нашел пару таких вот скриптов https://github.com/prodhe/acme-setup/commit/cc29be58db0eff9a176c82ef158b682f45bf5876</li> https://github.com/tw4452852/MyConfig/blob/0009fa3447638c545e6afa419f739212de896d8e/.p9p/env</li> </ul> NAMESPACE</code> - каталог, где будет создан сокет Acme. Чтобы работать с другими p9port приложениями. Посмотреть его значение по-дефолту 9 namespace</code>. О нём - 9 man 4 intro</code> Я особо не парился и добавил в свой скрипт запуска NAMESPACE=`{mktemp -d} </code></pre> Каждый Acme в своем неймспейсе запускается. Пока мне это не мешает, хотя, я так понимаю, возможны проблемы с plumber. Мой скрипт для запуска acme</a> Руководство по Acme на русском 2025-11-02T00:00:00+00:00 Хотел сделать для себя заметки по-командам Acme, но подумал что можно перевести и руководство на русский язык. За полдня перёвел несколько абзацев, а до самих команд так и не добрался, бгг. Но решил выложить что успел сделать на гитхаб</a> Ну и закинул на этот сайт Acme(1)</a> Не знаю, надолго ли меня хватит. Но хотя бы эту страницу перевести в ленивом режиме должен. Как собирается руководство plan9port 2025-11-02T00:00:00+00:00 Задумал перевести часть руководства для Acme, которое идёт в составе plan9port. Внутри /usr/local/plan9/dist/</code> выполнить команду 9 mk man </code></pre> – Это пересоберет .html файлы внутри /usr/local/plan9/man/man1/</code>. Скажем, отредактировал /usr/local/plan9/man/man1/acme.1</code>, выполнил 9 mk man</code> и ls -l /usr/local/plan9/man/man1/ ... -rw-r--r-- 1 e41q staff 20621 2 ноя 08:43 acme.1 -rw-r--r--@ 1 e41q staff 32815 2 ноя 08:43 acme.html ... Упоминание этой команды нашел в `/usr/local/plan9/dist/mkfile`. Там же есть и publish, но я не разбирался с публикацией. </code></pre> Зачем нужен Plan9? 2025-10-30T00:00:00+00:00 Хорошее видео (хотя на этом канале все видео хорошие) про то, зачем сегодня может быть нужна plan9. </a> </figure> Мысли, которые извлек из ролика: </div></div>

Возврат значения последнего выражения</a></h3>
Когда последняя выражении в блоке, не оканчивающееся на `;</code> возвращается из тела. Без всяких return.</p>`

Make</a></h3>

Fast Static Site with make</a>

Static Blog Builder</a> - Предвестник статьи</li> </ul> </li> </ul>

Why Use Make</a></h4>
https://bost.ocks.org/mike/make/</p>
Встретил её в замечательном блоге про osh/ysh</a></p>

wasm_exec.js - взять из tinygo</a></h2>
В примерах wasm-а хоть и указано</a> что wasm_exec.js отличается от обычного, гошного. Но я как-то не сразу понял.</p>
`cp /usr/local/tinygo/targets/wasm_exec.js ./ </code></pre>`

4779 - Блог

Конец выборам агента

Пи-агента достаточно

Хватит пи-агента

Знакомлюсь с Rust. Мысли

Популярные открытые модельки, доступные по api от cloud-ru

Руби или Перл

Разочаровался в идее цифровых садов

Запустить статический сервер одной строкой

Не в движке счастье

Самодельный генератор статического сайта на юникс-утилитах

Отличие Hugo и прочих от ssg

Юникс хостинг

Try - управление проектиками

Генератор статических сайтов вдохновленный werc

Build Awesome (11ty)

Что не так с Go. Цитаты

Шелл и реактивность

Юникс-утилиты для работы с данными

Ещё один сайт, вдохновлённый Эдом Тафти

Кнут, посрамлённый шестистрочником

Korn shell - posix и светлое будущее, которое не случилось

Как появились скрытые файлы

Nature Of Code сделанный на Go

Acme Zsh

Tinygo Wasm

n-t-roff

Апп-покалипсис сегодня. Поляризация крайностей

Plan9port rc profile файл

Несколько экземпляров редактора Acme

Руководство по Acme на русском

Как собирается руководство plan9port

Зачем нужен Plan9?

4779 - Блог

Конец выборам агента

Пи-агента достаточно

Хватит пи-агента

Знакомлюсь с Rust. Мысли

Популярные открытые модельки, доступные по api от cloud-ru

Руби или Перл

Разочаровался в идее цифровых садов

Запустить статический сервер одной строкой

Не в движке счастье

Самодельный генератор статического сайта на юникс-утилитах

Полноценные shell-ssg</a></h3> mkws</a></li> ssg.sh</a> от Романа Золотарёва</li> mksite</a> прямо как Уриель завещал - rc, mk…</li> </ul> </li>

Отличие Hugo и прочих от ssg

Юникс хостинг

Try - управление проектиками

Генератор статических сайтов вдохновленный werc

Build Awesome (11ty)

Что не так с Go. Цитаты

I want off Mr. Golang’s Wild Ride</a></a></h3> Simple is a lie</p> Most of Go’s APIs (much like NodeJS’s APIs) are designed for Unix-like operating systems…</p>

Шелл и реактивность

Юникс-утилиты для работы с данными

Ещё один сайт, вдохновлённый Эдом Тафти

Кнут, посрамлённый шестистрочником

Korn shell - posix и светлое будущее, которое не случилось

Как появились скрытые файлы

Nature Of Code сделанный на Go

Acme Zsh

Tinygo Wasm

n-t-roff

Апп-покалипсис сегодня. Поляризация крайностей

Plan9port rc profile файл

Несколько экземпляров редактора Acme

Руководство по Acme на русском

Как собирается руководство plan9port

Зачем нужен Plan9?