Свиихнувшиеся всех стран, чтоб вам … # <- приправить по вкусу

Люди не хотят ни в чём разбираться. В очередной раз, увы.

curl … | claude

«Вот установочные промпты для клауд. Дают осечку - примерно 50 на 50. ps1 на повершелл - 2. Извини, не проверял. Вот шел скрипты есть - баш, зсш. Это из импортного. Четыре плейбука для ансибл - машина тяжелая, убойная. sh сегодня один - извини, очень быстро разбирают»

echo сделай збс | claude

Мам, я инженер!

«Я знал, что рано или поздно мы перейдём и на эту дрянь» (с)

P.S. Надо пересмотреть, кстати.

Это чистый восторг.

Отлично перекликается с новостями о том, как Claude случайно удаляет все данные на компьютере.

установочный промпт

отличный троллинг на острие прогресса, спешите пользовать, пока это кого-то тригерит

Вообще, кроме шуток, это дикий бред

Скрипты (как и код) обеспечивают воспроизводимость и надежность. Если тебе лень писать скрипты(код) самому - ок, делегируй ИИ, проверь. Ты сам отвечаешь за результат. Итоговый код все равно должен быть надежным

ИИ - это другой человек, которому можно делегировать творческую задачу. Типовую повторяющуюся задачу ему делегировать не стоит, т.к. он каждый раз размышляет о том, как ее выполнить. Дообучат нейросетку, результат будет другой. Ты никак не можешь гарантировать или ожидать, что при работе нейросетки не будет «человеческой ошибки»

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

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

Dixi

Всё бы ничего, но творческие задачи он будет решать уже известными ему методами. Т.е. совершенно нетворческими. Более того, середнячковыми методами, которыми эти задачи решаются чаще всего.

Так это суть LLM, усреднение по всему объему данных.

При чем RLHF и современная ориентация на агентное применение эту черту дополнительно усиливает, задача выравнивания сделать модель предсказуемой, а не «креативной».

Когда Клод, как пишут в очередной новости, удаляет 700 ГБ пользовательских файлов, это следствие того, что он «допускает ошибки по невнимательности» в этом будучи прямо как человек, написавший кривой скрипт.

И вот такой вариант теперь массово принимается как норма.

Я надеюсь только обойдётся без автомобилей и самолётов, которые падают по причине «ну ИИ обычно не ошибается». (Хотя не обойдётся.)

Люди не хотят ни в чём разбираться. В очередной раз, увы.

Хорошо, что я уже старый и не доживу до времён, когда цивилизация накроется. Как говаривает Делягин, бояться надо не ядерного удара, а отказа канализации.

Говорил ли Марк Твен: «Будьте осторожны при чтении книг о здоровье. Вы можете умереть от опечатки»?⁠

Ещё раз, а чем install.md принципиально отличается от Makefile?

Ещё раз, а чем install.md принципиально отличается от Makefile?

Выше ответили.

Вы считаете это ответом? Ну хорошо, если вас этот ответ устраивает.

Я тут месяц экспериментировал с попыками через те иишки задебутстрапить дебиан и добавить туда докерхост. Шли бы в пень иишки - на сотню собранных исошек - ноль смогли загрузиться.

Сосед-кэп считает, что человеку легче читать install.md.

Допустим сосед-кэп в этом прав, человеку действительно легче читать install.md, чем Makefile. Это единственное различие между описанием процесса установки в одном или другом формате или есть другие различия?

А вас то чем не устраивает?

Что чем не устраивает?

Отлично перекликается с новостями о том, как Claude случайно удаляет все данные на компьютере.

В линуксах вообще море возможностей сделать юзеру больно. Как то неглядя запросил скрипт, который должен переделать движение камеры в вар3 со стрелок на фывц. И таки он сделал скрипт на питоне. Все красиво, работет. Кроме одного - вся клавиатура и мышь заблокировались намертво. Забавно но даже SysRq. 213 дней аптайма ИИшке под хвост. Пришлось вырубать ноут кнопкой питания.

И это в первую очередь не проблема ИИшке, а проблема линукса.

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

Здорово придумали. Мне нравится!

А ИИ-скептикам ничего не мешает скачать файл и следовать инструкциям в нём самостоятельно. В конце концов они ведь не тупее ИИ.

Скрипты обеспечивают воспроизводимость и надежность

Скрипты не обеспечивают ни воспроизводимость, ни надёжность.

Странно, я думал всех такое объяснение вполне устраивает, только я тут воду мутить начал.

Теперь уже не пишут bash/powershell установочный скрипт. Теперь пишут установочный промпт

Не ну это уже IQ 3, даже не 9

«Превратить систему в Слаку» выходит на новый уровень.

Зависит от того, использовали ли при их написании голову

Если не забывать провять код возврата, обрабатывать чужие ошибки и не делать своих, обеспечивают

В общем, поэтому и переходят на ансибл - он добавляет много защиты от дурака и не игнорирует ошибки

уж если приходится писать скрипты на bash или Python, это может стать настоящим мучением. Создаст ли облачная БЯМ адекватный shell script по простому текстовому описанию с указанием всей необходимой конкретики? Бесспорно; причём заведомо быстрее локальной модели. Зато чтобы такой скрипт сразу же заработал как следует, придётся поделиться с облаком такими сведениями о своей локальной или сетевой инфраструктуре, как пути к файлам, структура внутренних папок, идентификаторы серверов и т. д. А сегодня любая утечка специфичной информации такого рода — заметная потенциальная угроза, потому что кибератаки тоже организуют при помощи ИИ, и аргумент «да кому я нужен, кто вообще сумеет связать эти обрывочные сведения именно с моей локальной сетью» уже не звучит так же убедительно, как всего лишь пять лет назад. И ещё один момент: чтобы написать корректный скрипт, не слишком уверенно владеющему синтаксисом выбранной оболочки программисту требуется тратить немало времени, переключаясь между редактором кода и браузером, где открыта справочная страница, что и замедляет работу, и мешает концентрировать мысли. Локальный же ИИ не просто выдаст некую последовательность команд, но сможет пояснить любую из них (а также логику выбора каждой) дополнительно и сколь угодно глубоко — не расходуя притом драгоценных облачных токенов. Таким образом программист не извлекает некую чудесным образом работающую китайскую грамоту из чёрного ящика, а постепенно пополняет багаж собственных знаний в области скриптов — что делает его увереннее, продуктивнее и в целом по-человечески лучше.

И это в первую очередь не проблема ИИшке, а проблема линукса.

Нет, это проблема не Linux, а модели угроз. Она в Linux и винде одинаковая. Код, работающий с дефолтными правами доступа («от пользователя»), имеет достаточно полномочий, чтобы сделать любую гадость.

В винде тоже неверно написанный код игры может сделать графический сеанс непригодным к использованию.

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

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

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

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

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

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

Там никто в здравом уме не будет работать без фаервола и антивируса, коих кучи хороших и разных.

Это никак тебе не поможет, потому что это не «вирус», а алгоритмическая ошибка.

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

У тебя и в линукс по умолчанию приложения не могут работать с «программ файлс». Это ты сам, кто разрешаешь sudo без пароля, а не ОС.

Я не зря упомянул «код, работающий с дефолтными правами доступа («от пользователя»)», потому что от rm -rf $HOME в обоих случаях модель безопасности не защищает. Это не Андроид, очевидно.

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

Да-да, особенно в двух недавних кейсах из новостей, где Клод удалил данные у пользователя под виндой. А до этого этим же отличился GPT, вот правда не помню, какая ОС была там у пользователя.

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

Ты даже не представляешь, какие замечательные зависания в играх были у меня под win10, когда приходилось перезагружать машину принудительно. Без всякого ИИ.

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

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

Поможет, если ИИшки станут радикально умнее.

Какую модель использовал?

А ограничивать не выйдет Как ограничишь, если тебе надо работать с той сферой, где оно может нагадить.

Именно.

Мне вот вчера вчера ИИ написала скрипт, который читает данные с конкретного сайта и сохраняет в удобном мне виде, в markdown. Получившийся код на питоне я, разумеется, не читал. Теоретически там может быть всё, что угодно.

Что касается воспроизводимости.

Если скрипт использует sh, на разных дистрибутивах он разный. В alpine busybox; в дебиане dash, в центоси bash.

И каждая из этих оболочек имеет свои особенности.

Если скрипт использует bash, на целевой системе его вообще может не быть.

В каждом дистрибутиве свой набор программ. Даже задача по «установить gcc» через скрипт может стать нетривиальной.

Воспроизводим скрипт будет только если его запускать в зафиксированном окружении. В любом остальном случае всё зависит от усердности и кругозора скриптописателя. А если вспомнить про винду, про всякие BSD, там ещё интересней.

Что касается надёжности.

Попробуй на sh надёжно написать команду find . | wc -l. ты быстро поймёшь, что статус выхода первой команды ты даже узнать не сможешь в стандартном sh. Что -o pipefail это башизм.

Про парсинг вывода программ вообще молчу. Там такое порой.

Шеллы (и юникс в целом) активно препятствуют тебе писать надёжный код. В теории можно, конечно. Но это совсем нетривиально.

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

Я никакую. Это цитата.

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

«Ты ко мне не подходи, я два фильма про карате видел!»

sh/bash/python детерминирован - скрипт способен делать то, что содержится в коде и не способен делать то, что в коде не записано.

Например, если из кода не следует, что скрипт даёт shell на твоей машине удаленному атакующему, значит он этого не делает.

Традиционный код в этом смысле КОНЕЧЕН.

Работа ИИ вероятноста, каждый запуск отличается от предыдущего. ИИ имеет эмерджентные характеристики а ля «сумма больше частей». По частям это просто несколько миллиардов векторов, генерирующих текст, а в сумме с агентной обвязкой – самостоятельный источник принятия решений внутри контура безопасности.

В «коде» (векторах) ИИ теоретически содержится ЧТО УГОДНО.

Стоит заметить, что это проект про «spec-driven development» (разработка по спецификации), т.е. для него такая установка своего рода демонстрация этого самого «spec-driven».

Имело бы смысл, натравливай они на install.md свой собственный движок. Причём не ИИшный, т.к. спеки предполагают детерминированность.

т.к. спеки предполагают детерминированность.

Вот с этим не соглашусь.

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

Формализованность - возможно.

Например, государственные законы формализованы, но не детерминированы.

Детерминированность это более строгое ограничение, чем наличие формальных правил.

Но «spec-driven development» – это же что-то про программирование? Тут без детерминированности нет никакого смысла. Так что не надо демагогии «за жизнь вообще» :), так и до теоремы Гёделя можно добраться, однако ж на практике математика – всё-таки вещь строгая.

Ещё раз, а чем install.md принципиально отличается от Makefile?

Если это был серьёзный вопрос, то Makefile исполняется как код, в то время как install.md интерпретируется «по смыслу» в меру понимания читающего. У команды make нет «понимания», есть конкретная версия программы, которая способна выполнять конкретные команды и операции и у своих разработчиков прошла определенные тесты (детерминированные, как надеемся предполагать).

Тот, кто интерепретирует install.md (неи важно, человеку или ИИ), оирается на широкий контекст, включая информацию о среде исполнения, предполагаемые намерения пользователя и т.п., в том числе и «на волю случая», которая в случае с ИИ имеет конкртеные параметры, такие как температура. А также на не поддающуюся строгому определению способность «понять текст».

Но «spec-driven development» – это же что-то про программирование?

Да.

Тут без детерминированности нет никакого смысла.

Я не знаком в деталях с этим новым понятием «spec-driven development», так что отвечу как сам понимаю. Предполагается, что надежный результат может быть получен итеративно. Точно так же, как мы разрабатываем код конвенциональными способами (постепенно приходя к надежному результату, закрывающему поставленные задачи), только теперь – машиной, с большим уровнем формализации спецификации.

В этом смысле «spec-driven» установка должна производиться в песочнице, чтобы было что итерировать в случае сбоя. Тут же люди предлагают делать curl ... | claude, пропустив всё, что должно быть «вокруг» этой claude.

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

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

Я тут подумал. А если к такому файлу добавить строгое требование на соответствие определённой модели опрелённой версии с определёнными весами, насколько такая конструкция станет более сложной? В использовании в том числе.

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

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

Это всё равно ничего не гарантирует, любая новая побочная информация (изменение версии ОС, списка системных пакетов, что угодно) может непредсказуемо влиять на результат, потому что точный механизм принятия решений внутри ИИ («механистическая интерпретируемость») неизвестен, и обнаружить граничные условия в том, как он приходит к выводам, мы из-за этого не можем.

Мы теоретически получим типичные проблемы традиционных методов («данный скрипт работает только на python 3 конкретной минорной версии, а на следующей минорной версии вызывает сбой, обязательно ставьте требуемый питон»), не устранив проблемы ИИ.

Да, это вполне серьёзный вопрос и спасибо за вполне серьёзный ответ. Я полностью согласен. Если сжать то, что вы сказали, то получается: markdown версия говорит, что надо делать, не вдаваясь в детали, как это делать, в то время как Makefile версия является пошаговым рецептом для исполнения. При этом, как заметили выше, читать markdown версию человеку всяко разно легче.

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

А ТС следовало просто обсудить ситуацию с коллегой, а не истерить на пустом месте.

И это в первую очередь не проблема ИИшке, а проблема линукса.

Проблема тут в прокладке между стулом и клавиатурой. У тебя есть выбор - либо у тебя отберут рута и возможность «делать всякое», либо ты будешь периодически ломать систему своими шаловливыми руками