Зачем править сгенерированный нейросетью код руками, когда его должна править сама нейросеть же, после соответствующего исправляющего промта?
Исправить уже существующий код или написать новый с новым промтом?
Я вот просто беру классическую для меня проблему: есть ядро линукса. Есть новое устройство для которого надо написать драйвер. Чтобы драйвер органично и без костылей вошел в ядро надо несколько расширить ядерные интерфейсы. Если что - это нормально, в линуксе часто переделывают внутренние API.
Как мне заставить LLM сделать это? Весь код ядра очевидно не влезет в контекст. Дообучить LLM на конкретной версии кода и потом попросить сделать diff?
Или просто сказать "сделай мне новое ядро как старое, только с новым драйвером"?
Коптеры стали популярны относительно недавно (а не лет 50 назад) благодаря трем вещам: емким и легким аккумуляторам, силовой электронике, которая позволяет эффективно коммутировать адские токи и дешевым доступным MEMS датчикам.
Сделать же раму и намотать катушки в двигателе - действительно много ума не надо.
Порошковая покраска - это в принципе и есть напыление пластика. Типа - нанесли пластиковый порошок, засунули в печь, он там расплавился и равномерно покрыл деталь.
Вы как-то вообще упустили такую штуку как отображение файлов в память. А ведь это именно то что позволяет очень эффективно работать с содержимым файлов в любой современной OS. Например, исполняемые файлы не читаются с диска в память процесса. Они туда просто отображаются. А читаются они в тот самый страничный кеш. Точно этот же механизм используются для работы со свопом, кстати.
AFAIK, ничего оно не читает. Просто обращается к системному менеджеру аутентификации с запросом типа "а сколько времени прошло после последней успешной проверки юзера?"
Как раз в отличии от десктопов, мобильные приложения даже пукнуть не могут без разрешения от системы.
Зачем вам отчет об уязвимостях? Там будет сертификат о безопасности, где будет написано что аврору делали сертифицированные разработчики сертифицированными методами разработки на сертифицированном оборудовании. Сертификаты разработчиков, методов разработки и оборудования прилагаются. Отчет о процедуре сертификации разработчиков можно посмотреть в приложении Н.12 бис 3.
Любая сертификация - это процесс написания 100500 бумажек, которые создают видимость управляемости разработки. К собственно разработке она имеет мало отношения.
Например, я вот сейчас наблюдаю процесс safety сертификации кода, который был написан 15 лет назад и сейчас используется на серверах во всем мире. Пока что он состоит в том что тривиальные куски кода приводятся в соответствие с MISRA C, а для всех нетривиальных кусков оформляется deviation. Как вы думаете, станет код безопаснее после этого?
Занимаюсь embedded в том числе и в automotive проектах. Всем этим большим автоконцернам интересно делать двигателя, кузова и подвески. А софт - это для них что-то чуждое. У них нет ни экспертизы в этом и нет желания заниматься этим. Зато есть куча стандартов по safety в том числе и для ПО. Поэтому создание софта отдается компаниям которые умеют проходить сертификацию и подготавливать 100500 документов для этой сертификации. Собственно писать софт им тоже не очень интересно. Вот поэтому и имеет что имеем.
Самое забавное что при этом все еще нужны люди, которые будут писать вот эти самые компиляторы/трансляторы и прочее. Код же не сам по себе транслируется. Нужен код который умеет транслировать.
При этом выходят все новые архитектуры процессоров, для них нужны новые компиляторы, на них надо портировать ядра ос, драйвера, загрузчики, кучу системного софта.
Ну анатомия-анатомией, а вы посмотрите внимательно на мотоцикл с первой картинки. У него три ручки на руле (или что это за фигня торчит над бензобаком?), какое-то месиво вместо блока цилиндров, вилка переднего колеса вообще представляет собой devil's fork: проследите взглядом перья, как они идут от колеса вверх и приходят... куда?
Этот паттерн, кстати, много где прослеживается: емкость батарей растет, энергоэффективность процессоров растет, а смартфоны как работали один-два дня так и работают.
Количество гигагерц растет, размер памяти растет, скорость дисков тоже растет, а софт как тупил, так и продолжает тупить.
Да, и в одном и в другом случае можно сказать что увеличилась сложность софта (или уменьшилась его стоимость), но факт остается фактом - софт будет пожирать все возможные ресурсы.
Я так понимаю, тут "инженеры" противопоставляются "кодерам". Вот "кодеров" точно надо меньше. Точно так же, как на завод вместо найма пяти токарей можно купить два ЧПУ станка и нанять одного оператора.
Инженеры все равно нужны, без инженеров пока никуда не деться. А вот бездумные исполнители частично заменяются бездушными машинами.
Запрещает iOS или запрещает эппловский магазин приложений? Я в принципе могу представить как ядро может запретить приложению помечать регионы памяти как исполняемые, но это поломает динамический загрузчик, так что у меня есть сомнения что это сделано. Хотя от Apple можно всякого ожидать, конечно.
Идея хорошая, но я ни разу не видел чтобы это где-то поддерживалось. Вроде бы сам гугл так тоже не умеет.
Исправить уже существующий код или написать новый с новым промтом?
Я вот просто беру классическую для меня проблему: есть ядро линукса. Есть новое устройство для которого надо написать драйвер. Чтобы драйвер органично и без костылей вошел в ядро надо несколько расширить ядерные интерфейсы. Если что - это нормально, в линуксе часто переделывают внутренние API.
Как мне заставить LLM сделать это? Весь код ядра очевидно не влезет в контекст. Дообучить LLM на конкретной версии кода и потом попросить сделать diff?
Или просто сказать "сделай мне новое ядро как старое, только с новым драйвером"?
Генератор судов по правам человека.
Коптеры стали популярны относительно недавно (а не лет 50 назад) благодаря трем вещам: емким и легким аккумуляторам, силовой электронике, которая позволяет эффективно коммутировать адские токи и дешевым доступным MEMS датчикам.
Сделать же раму и намотать катушки в двигателе - действительно много ума не надо.
Порошковая покраска - это в принципе и есть напыление пластика. Типа - нанесли пластиковый порошок, засунули в печь, он там расплавился и равномерно покрыл деталь.
Вы как-то вообще упустили такую штуку как отображение файлов в память. А ведь это именно то что позволяет очень эффективно работать с содержимым файлов в любой современной OS. Например, исполняемые файлы не читаются с диска в память процесса. Они туда просто отображаются. А читаются они в тот самый страничный кеш. Точно этот же механизм используются для работы со свопом, кстати.
Чтобы не быть голословным: https://developer.android.com/training/sign-in/biometric-auth#no-explicit-user-action
AFAIK, ничего оно не читает. Просто обращается к системному менеджеру аутентификации с запросом типа "а сколько времени прошло после последней успешной проверки юзера?"
Как раз в отличии от десктопов, мобильные приложения даже пукнуть не могут без разрешения от системы.
Мне кажется что 3/4 комментирующих тоже прочитало заголовок и сразу пошло в комментарии.
Зачем вам отчет об уязвимостях? Там будет сертификат о безопасности, где будет написано что аврору делали сертифицированные разработчики сертифицированными методами разработки на сертифицированном оборудовании. Сертификаты разработчиков, методов разработки и оборудования прилагаются. Отчет о процедуре сертификации разработчиков можно посмотреть в приложении Н.12 бис 3.
Любая сертификация - это процесс написания 100500 бумажек, которые создают видимость управляемости разработки. К собственно разработке она имеет мало отношения.
Например, я вот сейчас наблюдаю процесс safety сертификации кода, который был написан 15 лет назад и сейчас используется на серверах во всем мире. Пока что он состоит в том что тривиальные куски кода приводятся в соответствие с MISRA C, а для всех нетривиальных кусков оформляется deviation. Как вы думаете, станет код безопаснее после этого?
При этом ядро linux, хоть и написано на C, но является объектно-ориентированным. Так и живем.
Да и любая более-менее сложная программа на С начинает обретать признаки ОО архитектуры.
Занимаюсь embedded в том числе и в automotive проектах. Всем этим большим автоконцернам интересно делать двигателя, кузова и подвески. А софт - это для них что-то чуждое. У них нет ни экспертизы в этом и нет желания заниматься этим. Зато есть куча стандартов по safety в том числе и для ПО. Поэтому создание софта отдается компаниям которые умеют проходить сертификацию и подготавливать 100500 документов для этой сертификации. Собственно писать софт им тоже не очень интересно. Вот поэтому и имеет что имеем.
Я в этих ваших виндах слабо разбираюсь. Там что, NodeJS работает в контексте юзера, а не как системный сервис?
А что будет если это терминальный сервер и там сидит два десятка юзеров? У кого откроется окошко?
Ну это наверное не сама винда, а тот самый Defender, который тут предлагают отключить...
Я не уверен что вы правильный управляющий символ используете. И строка у вас не так написана. Попробуйте
s = "smeta_n\u202Efdp.exe"
Самое забавное что при этом все еще нужны люди, которые будут писать вот эти самые компиляторы/трансляторы и прочее. Код же не сам по себе транслируется. Нужен код который умеет транслировать.
При этом выходят все новые архитектуры процессоров, для них нужны новые компиляторы, на них надо портировать ядра ос, драйвера, загрузчики, кучу системного софта.
Ну анатомия-анатомией, а вы посмотрите внимательно на мотоцикл с первой картинки. У него три ручки на руле (или что это за фигня торчит над бензобаком?), какое-то месиво вместо блока цилиндров, вилка переднего колеса вообще представляет собой devil's fork: проследите взглядом перья, как они идут от колеса вверх и приходят... куда?
Этот паттерн, кстати, много где прослеживается: емкость батарей растет, энергоэффективность процессоров растет, а смартфоны как работали один-два дня так и работают.
Количество гигагерц растет, размер памяти растет, скорость дисков тоже растет, а софт как тупил, так и продолжает тупить.
Да, и в одном и в другом случае можно сказать что увеличилась сложность софта (или уменьшилась его стоимость), но факт остается фактом - софт будет пожирать все возможные ресурсы.
Я так понимаю, тут "инженеры" противопоставляются "кодерам". Вот "кодеров" точно надо меньше. Точно так же, как на завод вместо найма пяти токарей можно купить два ЧПУ станка и нанять одного оператора.
Инженеры все равно нужны, без инженеров пока никуда не деться. А вот бездумные исполнители частично заменяются бездушными машинами.
Запрещает iOS или запрещает эппловский магазин приложений? Я в принципе могу представить как ядро может запретить приложению помечать регионы памяти как исполняемые, но это поломает динамический загрузчик, так что у меня есть сомнения что это сделано. Хотя от Apple можно всякого ожидать, конечно.