Угу. Они покупают комплектующие у американских компаний. А вот производят ли они эти комплектующие в США - или импортируют из Китая - это уже второй вопрос.
И есть большое подозрение, что на каком-то уровне резко выясняется, что "а вот это мы купили в Китае".
Первое, что делаешь, когда сервис не может что-то открыть/запустить/увидеть - отрубаешь SELinux. В большинстве случаев - помогает.
Самоё печальное, что даже в операционках, в которых SELinux поставляется включённым по умолчанию, пакеты установленные из штатного системного репозитария - могут нифига не устанавливать нужные им для функционирования права доступа. Даже такой стандарт, как апач.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
Реально, исторические права доступа в Юниксе - это тот разумный минимум, которым будет пользоваться 95%-98% пользователей. Достаточно просто и удобно, чтобы можно было пользоваться постоянно - и достаточно возможностей/функционала, чтобы решить практически все реальные задачи ограничения прав доступа.
Подход, который реализован в SELinux ( и в системе ограничения прав доступа в Windows ) - он продиктован идеей "давайте сделаем супер-пупер систему, пригодную для суперсекретной деятельности". По спецификации уродов из спецслужб США, которым абсолютно насрать на удобство использования, главное - чтобы "секьюрно".
В результате, 99% пользователей даже и не пытаются с этой системой разобраться. А значит, в принципе не пользуются. А если пользуются - то хрен его знает, не открыто ли там чего лишнего.
"Вся эта документация и проверка относительно десятков «корпоративных стандартов разработки», приемо-сдаточные испытания, проверка кибербезопасности, выкладвание в Реестр Российского ПО, проверка на 4-й уровень доверия ФСТЭК и куча другой бумагомарательной необходимой работы — в идеале будет делаться автоматически."
Вы понимаете, что это одна из проблем внедрения генерирующих нейронных сетей?
Ведь вся эта бумага, вся это "ненужна документация" и "стандарты кодирования" - они все сделаны не для того, чтобы испортить настроение разработчика. Это всё сделано для того, чтобы продуктом можно было нормально пользоваться и его развивать - человеку.
Если вы всё это отдаёте "нейросетям" - значит, можете с тем же успехом всё это просто выкинуть.
Даже хуже - отсутствие документации лучше, чем наличие бессмысленной сгенерированной документации. Которая выглядит почти как настоящая, и на 80% действительно соответствует реальности - а на 20% содержит галлюцинации.
Эту проблему обнаружили лет так 20 назад, и давно уже обсосали со всех сторон.
Вкратце, она формулируется так: "вы можете использовать формальные показатели для оценки прогресса/готовности, но как только от формальных показателей начинает зависеть оплата/повышение, люди найдут способ их фальсифицировать".
Учёт времени, потраченного на задачу - важен и нужен. Он позволяет руководителю (и вам!) оценить, какие задачи уже далеко продвинулись, а какие - конь не валялся.
Учёт времени на задачи - позволяет более-менее адекватно оценить и запланировать необходимое время на аналогичную задачу, когда она непременно возникнет в будущем.
Учет времени для задачи, разбитой на подзадачи - позволяет продемонстрировать менеджменту, что на задачу "сделать охрененно" действительно надо потратить 5000 часов, а не "ну, что там делать-то, за неделю соорудите быстренько".
Для непосредственного начальника, он таким образом может оценить, какова нормальная производительность разных сотрудников. И учесть при планировании.
Но - как только "часы на задачу" будут непосредственно учитываться для установки зарплаты, или для повышений - люди немедленно найдут способ фальсифицировать систему учёта.
Да не парьтесь вы! По статистике, 98% современных программистов работают над задачами, которые нафиг никому не нужны, и использоваться по делу никогда не будут.
И всем было бы лучше, если бы и не использовались никогда.
ИИ идеально закрывает потребность в написании такого кода.
Вообще-то это полная чушь. Вот у вас работает модель. Промпт идёт в виде текста, выводи - в виде текста. Где здесь модель может что-то "сделать" вообще?
Да блин, если у модели нет доступа на чтение к собственному исходному коду "снаружи" - думаете, она сможет в виде текста выдать те самые миллиарды параметров в выводе?
---------------
Реально, была решена с помощью этого долбанного ИИ следующая супер-мега-гига-задача:
"Напиши скрипт на bash, который запускает новый докер (вот пароли) и копирует туда вот этот кусок ПО".
Ага. Ничем не сложнее чем "напиши скрипт, который запускает докер, ставит туда следующие пакеты и копирует вот эту папку".
--------------
Саморепликация: это если бы нейросети сказали: "вот тебе консольный доступ (напрямую, текст который ты выдаёшь - уходит в bash), на машине установлен gcc и есть достаточно место. Скопируй туда себя". Доступа к исходной машине, разумеется, нет.
Угу. Давайте ИИ будет генерить сразу машинный код, чтобы человек-программист в принципе не мог понять, что он делает и в чём ошибка.
Кстати, подозреваю, что для ИИ генерация машинного кода вполне возможна, но будет проводиться через промежуточное высокоуровневое представление. Впрочем, "язык понятный ИИ" для человека также будет непонятен, поэтому практического смысла иметь не будет.
Прямо себе представляю ситуацию, когда вот у вас команда ИИ, "эффективный менеджер" над ней, и он интеративно пытается заставить команду ИИ создать сложный продукт, удовлетворяющий требованиям заказчика. И как обычно получается: чиним в одном месте, ломается в другом. И так неограниченно долго.
Лучше бы США на Марс слетали, вместо того, чтобы тратить два триллиона баксов на то, чтобы свергнуть талибов в Афганистане, и через два десятилетия вернуть их на место.
А уж если включить затраты на остальные войны, которые вёл за это время коллективный Запад - можно ещё и постоянную базу на Луне отгрохать.
Ну вот про C# то же самое говорили. Или про Java - что, кстати, почти оправдалось.
Реально встречаются Java-приложения, сложные - и работающие на любой платформе.
Вопрос же не в том, чтобы скомпилировать (этот вопрос давно закрыт с появлением llvm) - вопрос в том, чтобы предоставить разработке стандартное, универсальное API для работы. И чем оно более полное - тем сложнее и глючнее.
И да: если нужен "просто код" или "просто алгоритм" - так для этого можно или написать на интерпретируемом языке, или исходники предоставить. Все проблемы начинаются, когда хочется сделать "красиво". И интегрировано в нативное окружение.
Обращение по нулевому указателю С++ отлавливает, но в вашем примере его скорее всего просто не было. Параллельный доступ к дереву испортил его структуру, вероятно - часть памяти была утеряна, но обращения по нулевому указателю не было. "Испорченную" структуру данных типа зацикленного списка не отловит ничего, ну разве что кроме сторожевого таймера.
Рекомендую попробовать ваш пример для С++ со включённым анализатором времени исполнения - например, clang AddressSanitizer может отловить всякое.
Нет ни одной здравой причины перехватывать исключения, ну разве кроме случаев когда через исключение передают информацию о логической ошибке. Программа с ошибкой должна немедленно грохаться, чтобы эту ошибку можно было выявить и исправить. Максимум, что можно себе позволить: сохранить дополнительные данные в процессе завершения.
Нужна. Как минимум - математика в объеме до 1-2 курса хорошего вуза программисту нужна. Хотя бы для того, чтобы понимал, что такое сложность, почему экспоненциально-сложный или экспоненциальный по памяти алгоритм будет отлично работать на тестовых примерах, но завалится на реальных.
Лично я словил когнитивный диссонанс, когда обнаружил, что субподрядчик (фирма) состоит из программистов, не понимающих, как устроено кольцо целых чисел по модулю 65536.
То есть люди реально этого не понимали (то есть не понимали, что получится, если складывать uint16_t и что происходит при переполнении, и что в выражении из переменных этого типа можно раскрывать скобки и переносить слагаемые), и городили дополнительную сложность, лишь бы их алгоритм "не вызвал переполнения".
Ну и разумеется, математика отлично тренирует мозги: увеличивает сложность нейронных связей, и улучшает способность мыслить логически.
Ага, встречалось такое. Люди делают десятки классов, сложносочинённые конструкции. Спрашиваешь: "нахрена? Задача ведь сформулирована была вот ровно так?". Отвечают "а вдруг придётся делать всё через жопу в неопределённом будущем...".
Заодно убивают производительность.
Я не шучу: у меня один новый сотрудник написал замечательный класс транспорта (данные по резервированному TCP-соединению). Отдельный класс формирования заголовка, отдельный класс - вычисления контрольной суммы, отдельный класс упаковки и распаковки со ссылками на два других класса. И отдельный класс для записи данных: по одному байту через вызов виртуальной функции.
На тестах всё работало (с).
Потом "неожиданно" выяснилось, что передавать надо где-то мегабайт в секунду данных.
Знаете, сколько занимает 1 миллион вызовов виртуальной функции?
Стартап нашёл в открытой прессе его описание, и решил, что уж они-то смогут реализовать отличную идею!
Ну или хотя бы финансирование привлечь...
В крайнем случае, будут продавать русским эти ядерные отходы, типа "переработка на аутсоурсе".
Угу. Они покупают комплектующие у американских компаний. А вот производят ли они эти комплектующие в США - или импортируют из Китая - это уже второй вопрос.
И есть большое подозрение, что на каком-то уровне резко выясняется, что "а вот это мы купили в Китае".
Первое, что делаешь, когда сервис не может что-то открыть/запустить/увидеть - отрубаешь SELinux. В большинстве случаев - помогает.
Самоё печальное, что даже в операционках, в которых SELinux поставляется включённым по умолчанию, пакеты установленные из штатного системного репозитария - могут нифига не устанавливать нужные им для функционирования права доступа. Даже такой стандарт, как апач.
А по поводу решения Торвальдса делать отдельную отключаемую приблуду - на самом деле, в этом он был абсолютно прав.
Реально, исторические права доступа в Юниксе - это тот разумный минимум, которым будет пользоваться 95%-98% пользователей. Достаточно просто и удобно, чтобы можно было пользоваться постоянно - и достаточно возможностей/функционала, чтобы решить практически все реальные задачи ограничения прав доступа.
Подход, который реализован в SELinux ( и в системе ограничения прав доступа в Windows ) - он продиктован идеей "давайте сделаем супер-пупер систему, пригодную для суперсекретной деятельности". По спецификации уродов из спецслужб США, которым абсолютно насрать на удобство использования, главное - чтобы "секьюрно".
В результате, 99% пользователей даже и не пытаются с этой системой разобраться. А значит, в принципе не пользуются. А если пользуются - то хрен его знает, не открыто ли там чего лишнего.
"Вся эта документация и проверка относительно десятков «корпоративных стандартов разработки», приемо-сдаточные испытания, проверка кибербезопасности, выкладвание в Реестр Российского ПО, проверка на 4-й уровень доверия ФСТЭК и куча другой бумагомарательной необходимой работы — в идеале будет делаться автоматически."
Вы понимаете, что это одна из проблем внедрения генерирующих нейронных сетей?
Ведь вся эта бумага, вся это "ненужна документация" и "стандарты кодирования" - они все сделаны не для того, чтобы испортить настроение разработчика. Это всё сделано для того, чтобы продуктом можно было нормально пользоваться и его развивать - человеку.
Если вы всё это отдаёте "нейросетям" - значит, можете с тем же успехом всё это просто выкинуть.
Даже хуже - отсутствие документации лучше, чем наличие бессмысленной сгенерированной документации. Которая выглядит почти как настоящая, и на 80% действительно соответствует реальности - а на 20% содержит галлюцинации.
Угу. И вывод какой замечательный - надо больше микрогридов, больше децентрализации, больше солнечных батарей и домашних аккумуляторов.
Ага, конечно. Больше солнечных батарей богу зелёной энергии к трону его!
Ага. Да вы опасный человек! Дай вам волю, так вы до ZMODEM додумаетесь!
То, что демонстрируют нынешние модели ИИ - это очень интересно, забавно и прикольно.
Но - реальная незначительная польза тут может быть только в индустрии развлечений и мошенничестве.
А, и ещё мы можем засрать интернет гигатоннами сгенерированной чуши, неотличимой без гигантских усилий от реальных фактов.
С практической точки зрения, человечеству имеет смысл вот эту всю хрень запретить напрочь.
И не потому, что "ИИ нас завоюет" или "убьёт всех человеков" - а потому, что ИИ потопит нашу цивилизацию под цунами мусорных данных.
Кстати, интернет-поисковики имеет смысл также уничтожить. По тем же причинам.
Эту проблему обнаружили лет так 20 назад, и давно уже обсосали со всех сторон.
Вкратце, она формулируется так: "вы можете использовать формальные показатели для оценки прогресса/готовности, но как только от формальных показателей начинает зависеть оплата/повышение, люди найдут способ их фальсифицировать".
Учёт времени, потраченного на задачу - важен и нужен. Он позволяет руководителю (и вам!) оценить, какие задачи уже далеко продвинулись, а какие - конь не валялся.
Учёт времени на задачи - позволяет более-менее адекватно оценить и запланировать необходимое время на аналогичную задачу, когда она непременно возникнет в будущем.
Учет времени для задачи, разбитой на подзадачи - позволяет продемонстрировать менеджменту, что на задачу "сделать охрененно" действительно надо потратить 5000 часов, а не "ну, что там делать-то, за неделю соорудите быстренько".
Для непосредственного начальника, он таким образом может оценить, какова нормальная производительность разных сотрудников. И учесть при планировании.
Но - как только "часы на задачу" будут непосредственно учитываться для установки зарплаты, или для повышений - люди немедленно найдут способ фальсифицировать систему учёта.
Да не парьтесь вы! По статистике, 98% современных программистов работают над задачами, которые нафиг никому не нужны, и использоваться по делу никогда не будут.
И всем было бы лучше, если бы и не использовались никогда.
ИИ идеально закрывает потребность в написании такого кода.
Вообще-то это полная чушь. Вот у вас работает модель. Промпт идёт в виде текста, выводи - в виде текста. Где здесь модель может что-то "сделать" вообще?
Да блин, если у модели нет доступа на чтение к собственному исходному коду "снаружи" - думаете, она сможет в виде текста выдать те самые миллиарды параметров в выводе?
---------------
Реально, была решена с помощью этого долбанного ИИ следующая супер-мега-гига-задача:
"Напиши скрипт на bash, который запускает новый докер (вот пароли) и копирует туда вот этот кусок ПО".
Ага. Ничем не сложнее чем "напиши скрипт, который запускает докер, ставит туда следующие пакеты и копирует вот эту папку".
--------------
Саморепликация: это если бы нейросети сказали: "вот тебе консольный доступ (напрямую, текст который ты выдаёшь - уходит в bash), на машине установлен gcc и есть достаточно место. Скопируй туда себя". Доступа к исходной машине, разумеется, нет.
Угу. Давайте ИИ будет генерить сразу машинный код, чтобы человек-программист в принципе не мог понять, что он делает и в чём ошибка.
Кстати, подозреваю, что для ИИ генерация машинного кода вполне возможна, но будет проводиться через промежуточное высокоуровневое представление. Впрочем, "язык понятный ИИ" для человека также будет непонятен, поэтому практического смысла иметь не будет.
Прямо себе представляю ситуацию, когда вот у вас команда ИИ, "эффективный менеджер" над ней, и он интеративно пытается заставить команду ИИ создать сложный продукт, удовлетворяющий требованиям заказчика. И как обычно получается: чиним в одном месте, ломается в другом. И так неограниченно долго.
Лучше бы США на Марс слетали, вместо того, чтобы тратить два триллиона баксов на то, чтобы свергнуть талибов в Афганистане, и через два десятилетия вернуть их на место.
А уж если включить затраты на остальные войны, которые вёл за это время коллективный Запад - можно ещё и постоянную базу на Луне отгрохать.
Не понял. А зачем для копирования массива организуем цикл?
В языке что, нет способа скопировать массив в одну строчку?
Ну вот про C# то же самое говорили. Или про Java - что, кстати, почти оправдалось.
Реально встречаются Java-приложения, сложные - и работающие на любой платформе.
Вопрос же не в том, чтобы скомпилировать (этот вопрос давно закрыт с появлением llvm) - вопрос в том, чтобы предоставить разработке стандартное, универсальное API для работы. И чем оно более полное - тем сложнее и глючнее.
И да: если нужен "просто код" или "просто алгоритм" - так для этого можно или написать на интерпретируемом языке, или исходники предоставить. Все проблемы начинаются, когда хочется сделать "красиво". И интегрировано в нативное окружение.
Обращение по нулевому указателю С++ отлавливает, но в вашем примере его скорее всего просто не было. Параллельный доступ к дереву испортил его структуру, вероятно - часть памяти была утеряна, но обращения по нулевому указателю не было. "Испорченную" структуру данных типа зацикленного списка не отловит ничего, ну разве что кроме сторожевого таймера.
Рекомендую попробовать ваш пример для С++ со включённым анализатором времени исполнения - например, clang AddressSanitizer может отловить всякое.
Нет ни одной здравой причины перехватывать исключения, ну разве кроме случаев когда через исключение передают информацию о логической ошибке. Программа с ошибкой должна немедленно грохаться, чтобы эту ошибку можно было выявить и исправить. Максимум, что можно себе позволить: сохранить дополнительные данные в процессе завершения.
Никто не мешает сделать это опцией, и собирать библиотеку по-разному для разных сценариев использования.
Нужна. Как минимум - математика в объеме до 1-2 курса хорошего вуза программисту нужна. Хотя бы для того, чтобы понимал, что такое сложность, почему экспоненциально-сложный или экспоненциальный по памяти алгоритм будет отлично работать на тестовых примерах, но завалится на реальных.
Лично я словил когнитивный диссонанс, когда обнаружил, что субподрядчик (фирма) состоит из программистов, не понимающих, как устроено кольцо целых чисел по модулю 65536.
То есть люди реально этого не понимали (то есть не понимали, что получится, если складывать uint16_t и что происходит при переполнении, и что в выражении из переменных этого типа можно раскрывать скобки и переносить слагаемые), и городили дополнительную сложность, лишь бы их алгоритм "не вызвал переполнения".
Ну и разумеется, математика отлично тренирует мозги: увеличивает сложность нейронных связей, и улучшает способность мыслить логически.
Удивлю я вас до невозможности ... но с помощью осциллографа люди до сих пор отлаживаются. И бывает, что других вариантов - нет.
Тактика диверсионных групп? "Это многое объясняет (тм)"
Какое главное отличие результата деятельности диверсионных групп от разработки ПО?
А диверсионная группа или достигает цели - причём всем пофиг побочный ущерб - или нет.
Мост взорван, штаб уничтожен. Получите медали и переходите к следующему заданию.
Или - "все умерли".
А вот при разработке ПО можно сделать говно - и потом с ним придётся маяться годами.
Ага, встречалось такое. Люди делают десятки классов, сложносочинённые конструкции. Спрашиваешь: "нахрена? Задача ведь сформулирована была вот ровно так?". Отвечают "а вдруг придётся делать всё через жопу в неопределённом будущем...".
Заодно убивают производительность.
Я не шучу: у меня один новый сотрудник написал замечательный класс транспорта (данные по резервированному TCP-соединению). Отдельный класс формирования заголовка, отдельный класс - вычисления контрольной суммы, отдельный класс упаковки и распаковки со ссылками на два других класса. И отдельный класс для записи данных: по одному байту через вызов виртуальной функции.
На тестах всё работало (с).
Потом "неожиданно" выяснилось, что передавать надо где-то мегабайт в секунду данных.
Знаете, сколько занимает 1 миллион вызовов виртуальной функции?