Прогать с агентом зачастую выматывает сильнее, чем без него.

Сначала надо сгенерить код. Это кажется просто, но перед этим действием нужно уже провести много работы, продумать требования и нюансы (ибо магии нет: говно на входе = говно на выходе). План-хуян. Потом наконец генеришь и даёшь другому агенту на ревью. Если код сложный, то в 99% случаев что-то вылезает. Ладно, чинишь. Даёшь другому агенту посмотреть. Вылезает что-то странное, ты не понимаешь, он прав или нет. Начинаешь читать код вручную (это всё равно пришлось бы делать, но надеялся, что позже, когда основное будет пофикшено). Читать чужой код, написанный инопланетянамм (сам бы так не написал). Тратишь дофигища энергии, чтобы построить в голове ментальную модель высера. Просишь объяснить тестами. Понимаешь, что это нечитаемое говно, просишь агента переделать так-то и упростить тут-то. И всё равно - ну не то, блин. Нет удовольствия от хорошо сделанной раьоты.

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

И так целыми днями. Про баги на проде я уже писал - чинить их намного сложнее, так как в голове не прошивается нужная информация.

А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода.

эх

#книги
Andrew Tanenbaum - Modern Operating Systems
23.04.2026 - 24.07.2026

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

Часть 2. Processes and Threads
Некоторые объяснения не назвать простыми. Например, в процессах и тредах примеры не самые наглядные для того, у кого нет опыта программирования и понимания того, как могут переключаться разные параллельные задачи.
Очень громоздкое объяснение концепции data race. Тысяча лишних деталей...
Глава про синхронизацию идет со скрипом. Тема сложная, но я точно знаю, что можно написать проще, как в книге Three Easy Pieces. И на удивление в Three Easy Pieces более подробное и качественное рассмотрение возможных алгоритмов шедулера ОС.

Часть 3. Memory Management
Некоторые предложения главы про память - это прямо тест на advanced english с идиомами и просто редкими словами, хотя в целом книга в плане языка написана довольно доступно.
Глава про виртуальную память сложная, но, так как я не глупый и уже знаком с идеей, то делаю вывод, что это она плохо написана))

Часть 7 (Virtualization and the Cloud)
Очень сложно. Очень плохо написано. Процентов 20 пропустил. В главе про многопроцессорность начало казаться, что это графомания.

Часть 9 Security
В этой части мысль про графоманию только укрепилась и ушла куда-то очень далеко: 30 страниц забористой академической теории про безопасность - это вряд ли то, что ожидаешь от книги про ОС. Эта часть очень скучная в начале, но очень интересно про Meltdown и Spectre - я наконец-то понял, в чем их суть (в общих чертах, конечно).

После частей с общей теорией идут Case Studies: про Linux, Android и Windows. Только в case study по линуксу я начал читать то, что я ожидал от книги по ОС, но это воодушевление быстро угасло, и уже case study для Андроида и Windows я сильно пролистывал, читая только интересовавшие меня главы и абзацы.

Вспоминая другие книги Таненбаума, я понимаю, что мне определенно не нравится, как он пишет. Это неудовлетворение сложно формализовать, но факт его наличия я осознал. Не раз ловил себя на мысли, что какая-то идея уже объяснена в книге, но понимания не появилось. Странное свойство, я считаю, что проблема не во мне, так как во многих других книгах такого нет, а тут есть. Очень хорошо работает подход: прочитать главу, скормить ее LLM и попросить объяснить основную идею. LLM отлично справляется, и неясно, почему автор не формулирует основную идею так же - сначала.

Все-таки я считаю, что это плохо написанная книга. Ее трудно читать. Способ объяснения далеко не самый лучший. Часто после прочтения главы не понимаешь, как можно было такую простую идею так сложно объяснить. Чтение книги я воспринимал как "нахвататься фактов про операционные системы".

Все это я пишу, сравнивая её с бесконечно интересной и одной из моих любимых книг вообще - Three Easy Pieces. Если хочется почитать про ОС, то лучше начать (и возможно ограничиться) ей.

А с Таненбаумом я, пожалуй, закончил.

ZSH '=' expansion

Некоторые файлы в unix-like системах - это soft links на бинарники. Об этом говорит первая буква l выводе команды ls -l

 > ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

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

 > which python
/usr/bin/python

и только потом передать в ls -l, что неудобно. Можно это объединить в одну команду, что я и делал всегда:

 > ls -l $(which python)
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

Но это тоже неудобно.

Сегодня узнал, что существует '=' expansion в zsh, что сильно всё упрощает:

 > ls -l =python        
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

Ну или если есть алиас на ls -l:

 > ll =python
lrwxrwxrwx 1 root root 7 Jun 15 14:36 /usr/bin/python -> python3

https://zsh.sourceforge.io/Doc/Release/Expansion.html#g_t_0060_003d_0027-expansion-1

iaasm

Оказывается, из iPad очень легко сделать второй монитор. На MacOS, полагаю, это из коробки работает, но на Linux тоже вышло несложно: создается виртуальный дисплей на компе, он шарится через VNC, а на айпаде через RealVNC или аналоги отображается картинка.

#книги
Теодор Драйзер - Финансист, Титан, Стоик
15.05.2026 - 26.08.2026

В книге рассказывается история жизни предпринемателя из США. Кроме самой истории, было интересно погрузиться в США конца XIX - начала XX века: многие реалии того времени становятся частью повествования - например, пожар в Чикаго в 1871 году или такой вид транспорта, как конка.

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

Codex

ЛЛМ написала функцию, которая из строки делает int64:

func lockIDFromString(value string) int64 {
  hasher := fnv.New64a()

  _, _ := hasher.Write([]byte(value))

  lockID := int64(hasher.Sum64())

  return lockID
}

Мне тут не нравится, что игнорируется ошибка И нет комментария, который объясняет, почему так. То есть, чтобы исправить нужно:
1. Или добавить комментарий
2. Не игнорировать ошибку и внутри if err != nil уже не возвращать ошику (но тоже с комментарием, почему так)

Выбираю второй вариант. Делаю промпт:

_, _ = hasher.Write([]byte(value)) Тут игнорируются все возвращаемые значения. Err надо все-таки вернуть, но внутри проверки на err != nil написать, что мы ее игнорируем явно.

ЛЛМ отдает такое:

func lockIDFromString(value string) (int64, error) {
  hasher := fnv.New64a()

  _, err := hasher.Write([]byte(value))
  if err != nil {
    return 0, err
  }

  lockID := int64(hasher.Sum64())

  return lockID, nil
}

Проблема в том, что error из функции возвращать не надо т.к. он всегда nil. Он всегда nil т.к. метод Write у fnv.New64a() всегда возвращает nil.

Почему так? Потому что в моем промпте есть слово "вернуть" и ллм поняла это как "вернуть из функции", а не вернуть из метода Write? Или она это поняла верно, но не учла, что Write всегда возвращает nil т.к. не проверила реализацию?

Вот такие моменты конечно не могут нравится т.к. всегда есть шанс, что или кривая формулировка промпта, или еще что-то приведут не к лучшей реализации.

А я хотел видеть это:

_, err := hasher.Write([]byte(value))
if err != nil {
  // sum64a.Write always returns len(value), nil.
}

или это:

_, _ = hasher.Write([]byte(value)) // err always nil

Navier-Stokes Equation

Есть шанс, что была корректно решена одна из задач тысячелетия - уравнение Навье-Стокса

https://openai.com/index/navier-stokes-solution/

Если это подтвердится, то будет 2 решенных задачи из 7: гипотезу Пуанкаре в 2006 доказал Г. Перельман.