amarao

Как-то за грандиозными облаками и AI'ками забылась простая история с администрированием локалхоста (своей собственной машины). Кажется мелочь, ерунда, но иногда оно пушает в область high-end administration.

Давным-давно, в другой стране, в другом политическом режиме, на ядре 2.6.18 на дистрибутиве Debian Etch я сделал файловую систему для ценных данных. Я выбрал в качестве файловой системы xfs, потому что на тот момент был вайб, что xfs хорошо подходит для больших объёмов с крупными файлами. Эта файловая система жила на raid1 поверх LVM, пережила несколько увлекательных приключений (включая исчезновение одной из PV в середине копирования), сменила несколько мажорных версий ядра, почти с десяток дистрибутивов (Debian etch -> Sid/Forky), неизвестное количество поколений процессоров, дисков и т.д.

И вот, случилось. 6.18 (иронично, 2.6.18 -> 6.18) отказывается монтировать эту файловую систему, ибо v4, а надо v5. Migration path нет. Шринка xfs не поддерживает. И это самая большая файловая система на моей машине.

Вообще, в моей машине осталось всего 4 блочных устройства: nvme, ssd и парочка жёстких дисков в raid1, и вот эта файловая система живёт на vg из двух жёстких дисков, размером 2ТБ (HDD 2x4TB). 2ТБ больше, чем любая другая VG на моей машине.

Пока что я откатился на 6.17 и имею доступ к файловой системе, но пришло время миграции. После долгих раздумий я решил отказаться от linux-raid и перейти на btrfs-raid, потому что btrfs способна выбрать правильную копию когда данные с обоих дисков рейда различаются, а linux-raid нет, т.к. не имеет чексумм. В новой файловой системе я буду использовать, наверное raid1+dup для метаданных и raid1 для данных.

Всё осложняется тем, что я не могу использовать LVM для btrfs, т.к. lvm поверх raid, а я хочу raid разобрать.

Мой план:

1. Прогнать long smart selftest на обоих дисках (по-очереди)
2. Сделать checking для рейда.
3. Вывести один диск из рейда, перевести рейд в linear.
4. Выведенный диск сконвертировать в новую VG, сделать LV, сделать btrfs (dup, no raid).
5. Скопировать всю файловую систему (rsync).
6. Поменять профиль btrfs на raid1
7. Оставшийся диск во вторую VG, аналогичную LV, добавить в btrfs
8. Запустить rebalance.

(отвечая на вопросы: бэкапы частично есть, частично нет и не будет, ибо жирновато для некоторых видов данных).

Вот такие вот будни localhost'а.

Меня заставляют использовать Claude, а я предпочитаю Codex.

Claude очень misaligned. Он всегда что-то подприсовывает. Ему говорят "поправь в модуле таком-то", он поправляет всюду. Ещё он туповат, то есть вместо того, чтобы вкопаться в суть проблемы, он шлёпает квадратно-гнездовое, срезая углы всюду, где можно.

Codex куда более crispy. Он точно следует инструкциям, хорошо понимает намерение через неточную формулировку, и больше думает вглубь.

Ещё Сlaude невероятно дорогой. За 20 баксов я получил у кодекса практически анлим (я понимаю, что эншитификация yet to come, но пока что я ни разу ниже недельного 50% usage не падал), у клауди за 20 баксов можно пару дней очень аккуратно поработать и всё.

Ещё codex каким-то волшебным образом (умная компактификация? subagents?) умудряется расходовать контекст очень экономно. В одном чате можно долго вести проблему и контекст тратится только на общение (и "обозревание" кодовой базы). А claude каждая мелкая опечатка - сожжёный контекст.

План на 2026: переехать с grep на ripgrep.

Нет, это не маленькое изменение, это перестройка куска фундамента.

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

Вместо этого оно существенно повышает качество. Наверное, это тихая революция в software engineering, потому что количество найденных идиотизмов и ошибок зашкаливает. Через несколько лет, когда ai-reviewed код начнёт составлять ощутимый процент от общей кодовой базы мы начнём видеть синергентический эффект этого. Что-то поменяется (если к тому времени AI не перепишет всё к чертям, во что я не верю).

Оно повышает не лучшее качество, оно повышает худшее качество. Миллион глупостей остающихся в коде, документации, ранбуках и т.д. внезапно оказываются хотя бы частично исправлены.

Что исправляет больше ошибок? Система типизации или AI? AI ловит ошибки совершенно недоступные для системы типов и линтеров, включая логические ошибки и ложные посылки.

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

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

With a great power comes great "it's not me, it's bug in the script".

Родилось на Реддите: человек, супервизящий AI - это senior yell operator. Кто-то, кто командует и требует сделать по-другому.

Так вот, это весьма и весьма утомительное занятие. Я бы сказал, сравнимое с code review (которое всегда сложнее, чем написание кода, если делать review правильно). В отличие от code review, где качество самого ревью никто не может проверить (кроме как покачать головой глядя на апрувнутое), после плохой yell-сессии результат - потеря контекста, избыточные изменения, накопление слопа в коде и т.д., то есть фидбэк луп для поддержания высокого уровня усилий есть. Что делает его ещё более утомительным.

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

https://anycrap.shop/

Открыл для себя .info для tree.

Почитал формат. Надо literal tab (0x9) внутри формата.

Закрыл для себя .info.

Идея хорошая, формат слишком суров.

... Когда мы потеряли таб как валидный символ? Наверное, когда С и остальные языки начали принимать его в качестве whitespace separator. В этот момент tab стал redundant и был обречён. Сначала редакторы сделали замену таба на пробелы, потом люди придумали делать табы разной ширины и у них поехала вёрстка смесью табов и пробелов, и они решили её с помощью запрета табов.

После этого редакторы стали использовать замену табов на пробелы, и таб перестал быть literal input и превратился в служебную кнопку класса "F11", каждый вешает на неё что-то своё.

После этого сам символ, вне алфавита, превратился в obscure, а его визуальное сходство с пробелами только ухудшило его карму.

На выходе: отличная идея field separator умерла, потому что визуально была схожа с пробелом и путала. Сначала людям это нравилось, потом стало причиной неприязни.

Если бы с самого начала tab давал визуализацию таблицы... то его бы путали с символом визуализации. Чтобы выжить нормально, tab с самого начала должен был показывать таблицу. Не похожую на любой другой символ, с характерным поведением. Тогда у него были бы шансы остаться на общих правах. Если бы ПО с самого начала использовало символ как разделитель данных, а не символ форматирования...

a = [1 ↹ 2 ↹ 3] - отличный метод перечислять значения в массиве.

func foo(arg1 ↹ arg2 ↹ arg3) - тоже.

cp ↹ source file name ↹ dest file name - отлично. И никакой путаницы с пробелами.


... Все умны задним числом, да?

Я посмотрел как коллега пытается это делать. Wow, там серьёзный скилл нужен. Человек не понимает что ожидать от LLM, пишет странное, хочет слишком много за раз, не готов подстраиваться под ограничения и допиливать напильником.

Выглядит так, что скиллы для vibe'а ровно так же надо нарабатывать, как и все остальные.