А ещё можно ИИшечный рабочий репозиторий клонировать не из сети, а из локальной папки. Да, это добавляет потом работы тебе как “дирижёру” этих работяг по пушу этих веток ещё выше по апстримной иерархии, зато такой вот небольшой ценой защищает основной репозиторий от излишних активностей. Да и сетевой доступ тогда можно ещё сильнее зарезать.
Цитата из статьи, дословно - “В результате GPU несколько лет работал на предельных температурах.”
В комментариях на Reddit, кстати, тоже пишут, что вся ситуация звучит довольно странно: если проблема в перегреве VRM - она должна была проявиться на годы раньше. У чела периодически возникали чёрные экраны, но он аж почти пять лет списывал их на G-Sync или драйверы и, по сути, игнорировал. Ну вот кто в этой ситуации сам себе злобный Буратино? Да, ситуация неприятная, но раз уж терпел так долго и не жаловался - не стоит уже и начинать, поезд с гарантией ушёл. Гарантия от производителя, кстати, 3 года, то есть он не чуть-чуть не уложился, он прям основательно продолбал все сроки.
На днях с коллегами-программистами пришли к заключению, что если заменить “ИИ” на “индус” (из мемов про индусский код, разумеется) - ничего существенно не поменяется: эта сущность быстро и (относительно) дёшево напишет простыню кода, а потом четыре раза её перепишет, качество будет… сомнительным (но не для самой сущности, ей вообще без разницы), общаться не так уж и просто, для получения сколь-нибудь адекватного результата надо “кормить” крошечными разжёванными задачами, и так далее, и тому подобное
При всём понимании ситуации и сочувствии к buczi94, откуда компания или конкретные сотрудники СЦ, проводящие обслуживание, могут знать, что это действительно косяк с завода, а не сам buczi94 прилепил плёнку и собрал, а затем демонстративно разобрал?
К тому же, все сколь-нибудь прошаренные люди (а buczi94 таки сам нашёл проблему, значит он не совсем глупенький) знают, что перегрев означает проблемы с охлаждением, и надо почистить от пыли и проверить термоинтерфейсы на дееспособность. Но этот бедолага “почти пять лет” жил с “GPU, работающем на предельных температурах” - это надо быть очень невнимательным, или очень пофигистом. Хотя может быть питанию действительно было нормально всё это время, кроме небольшого срока в конце…
Хотя опять-таки, даже с таким дефектом, видеокарта проработала “почти пять лет” и больше гарантийного срока, то есть производитель свои гарантийные обязательства (в данном случае фактически нулевые, потому что обращений во время гарантийного срока не было) выполнил безупречно.
ripgrep и не стремится стать заменой обычному grep. Кстати, у вас в репозитории и ripgrep тоже есть, он достаточно популярный и быстрый, чтобы его просто игнорировать. Попробуйте на досуге
А это… Разве нельзя взять любой источник радиации (хоть даже естественный фон), счётчик Гейгера, просто количество частиц в единицу времени и брать остаток от деления?
По цене и по сложности это даже для кружка в старшей школе с инженерным уклоном пойдёт, вместо “15 милликельвинов”…
Обновлять Fedora на следующий релиз бывает “весёлым” аттракционом.
Пользуюсь Fedora аж с 13 версии, с переменной интенсивностью. На моей памяти, при обновлениях всей системы ломались только пакеты из сторонних репозиториев, которые ещё не успели подготовить к выходу нового релиза. Вся система вроде бы ни разу у меня не умирала ни разу (после первичной настройки, до неё бывало всякое - особенно весело раскочегаривать из минимальной установки).
А вот VirtualBox - та ещё зараза, бывает что даже после обычного обновления ядра перестаёт нормально работать, особенно в гостевой машине любит этот экстеншон отломиться.
Я примерно в декабре попросил одного такого нейробедолагу расставить мне типы функций в Python 2 (так надо) файлике. Я сразу ему сказал, мол файл - на Python 2, расставь типы. Этот работяга заботливо расставил мне типы в стиле 3 Python, прям внутри сигнатур функций. Я ему говорю, мол, что в 2 типы нужно писать в комментарии вида # type: (str, bool) -> int. Он тут же побежал переделывать, и таки перенёс свои типы в эти комментарии... только сами комментарии он написал в той же строке, что и сама сигнатура функции. Я ему говорю, что вообще-то они должны идти в следующей за сигнатурой строке - он перенёс. Потом мне уже совсем надоело, и я уже вручную исправил его list на более адекватные list[string].
То ли дело в локально развёрнутой сети (Qwen3-Coder 30b), то ли я не умею промпты писать, то ли им буквально надо разжёвывать каждую мелочь (вроде того же конкретного стиля написания этих типов) - но у него была одна работа, которую он делал 3 раза и всё равно за ним пришлось подчищать. Ну хоть сами типы он сумел адекватно вывести, а то бы вообще позор был.
Тем не менее, pkg-config файлы для libav-семейства можно в любом дистрибутиве Linux, какие могут быть проблемы? Есть готовый cmake_pkg_config, если же у вас древний CMake - ну что поделать, запускайте pkg-config вручную и выковыривайте оттуда. Да и вообще, странно требовать от внешней зависимости, как она должна собираться...
Отправлял в Discord (десктопный). Видимо, бекенд по расширеню понял, что это видео, и решил его отдавать с плеерной обвязкой, а там уже фронтендовая часть сумела раскодировать по внутренностям.
Разработчик open source проекта несёт ровно столько же ответственности за исправление уязвимостей, сколько и closed source - очень часто "no warranty".
Размер (конкретного) ПО и количество багов конечно только если проект больше не получает новых фич, лишь исправления багов. И даже в этом случае, количество багов может расти: обновились системные библиотеки, железо, настройки окружения - и ваш продукт начал вести себя не как положено.
"теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей" - и эти 10 сканеров найдут 10 000 уязвимостей, из которых не галлюцинациями будут, скажем, 3% - как один человек это всё проверит? Почитайте Death by a thousand slops, особенно 4 пример, Buffer overflow in strcpy
"Например, можно включить дополнительную стадию в свой CI\CD процесс" - см. п. 3 про кучу не-уязвимостей. А кто будет за эти прогоны платить, лично GitHub?
Да.
Не обязательно быть мейнтейнером, чтоб стать контрибутором. Раз уж говорим про open source, то вот как раз патч прислать может любой мимокрокодил. Да, не факт, что любой "мимокрокодильный" патч примут как есть, но он как минимум покажет один из возможных методов исправления.
С другой стороны как раз сидит ИИшенка, которая по своему шаблону завела баг. И даже если нет - в самом баге УЖЕ написано, какие сроки разглашения - почему сторона, создающая баг не могла первой связаться с представителями проекта?
Когда вам в проект накидывают кучу... просто кучу, вам нужно потратить время и силы чтобы это всё разобрать, категоризировать, приоритизировать. В какой-то момент, накидываемая куча становится настолько большой, что вы не можете с ней совладать, и она начинает бесконтрольно расти, а настоящие баги начинают теряться. Это натуральный DoS. Тем более мерзко, что примерно в то же время, кто-то из Google дал интервью вида "наше DeepSleep такое крутое, нашло 20 багов в мультимедиа продуктах - только вот их не исправили ещё".Это подгонка фактов и вампирский пиар. Аж сейчас упоминать про это противно, тьфу.
Многим пользователям GUI-IDE приходится страдать от того, что запустив сборку проекта приходится ждать окончания непредсказуемое время.
У меня в MS VS прям графический прогресс-бар рисуется :)
Простой счётчик файлов в принципе не сильно поможет решить проблему "Вы никогда не можете сказать сколько еще осталось ждать до окончания процесса":
есть великое множество single-header библиотек, они просто не попадут в счётчик как он есть. Это легко исправить, но...
файл на 50 строк и файл на 1050 строк будут собираться за очень разное время. Очень может быть, что у вас не очень большая программа, которая по тем или иным причинам собирает SQLite из его амальгамации - там пара .h и .c занимают вместе под 10 мегабайт
а ещё после сборки чаще всего идёт линковка, и может быть не одна (если это какой-то массивный проект с пачкой промежуточных библиотек), и может быть ещё и с LTO, которое может линковку замедлить в десятки раз
В итоге, конечно, со счётчиком чуть нагляднее, чем совсем вслепую, но не сильно точнее, чем прогресс-бары / счётчики при копировании файлов: есть и число файлов, и суммарный объём, и подсчёт уже затраченного времени - но предсказание всё равно плавает как ветка в шторм
Как будто бы мессенджеры не очень поддерживают MKV как видеоконтейнер?.. WebM, MOV - да, видел работающими.
Ради интереса записал OBSкой 2 секунды видео в MKV, но с обычными MP4шными кодеками (AVC + AAC LC). Telegram и Discord предлагают его скачать как любой другой бинарный файл, не показывают как видео (хотя Discord показывает превьюшку при отправке, видимо Electron сумел декодировать - Firefox тоже успешно воспроизводит MKV, если в него кинуться). Вот если переименовать файл в .mp4 - тогда всё нормально, подставляют плеер как положено.
В статье очень не хватает информации, что этот баг найден в кодеке для LucasArts SANM / Smush. Соответственно, "в дикой природе" используется он только для просмотра катсцен в некоторых играх LucasArts.
Какая разница, где он найден? А такая, что просто так, при стандартных сценариях работы с современным мультимедиа, наткнуться на использование этого кодека невозможно.
нужно решить проблему останова в общем случае (а то как вы определите, вот эта вот конкретная машина, сделавшая уже дофигаллиард операций, остановится, или ушла в бесконечный цикл?)
если оно вычислимо - можно написать конечную программу, считающую BB(n), следовательно, она будет реализована на машине Тьюринга с X состояниями, следовательно, BB(n) в принципе не может расти быстрее, чем позволяет реализовать машина Тьюринга с X состояниями, то есть до BB(x) оно растёт с одной скоростью, а после BB(x) резко замедляется? Парадокс?
Эти большие числа - на самом деле последовательности, и сравнивается не фактическое значение какого-то конкретного элемента, а скорость роста последовательности. Добавление слагаемых, возведение в степень, и даже применение функции к самой себе не увеличивает скорость роста фундаментально, поэтому это всё избыточно.
К сожалению, в статье не объясняется ничего, и не даётся никаких ссылок для заинтересовавшихся. Те крохи пояснений по теме, которые всё же попали в статью, в лучшем случае заставят вспомнить эффект Манделы монады (как только вы начинаете понимать монады, вы теряете способность объяснить, что это такое), в худшем - RTFM.
Буквально по этой теме, т.е. про число Лоадера, есть пара видео от CodeParade:
сотни других простаивают, занимая дорогостоящие GPU
Так, падажжи. Обычная Ollama с настройками по умолчанию выгружает модель, если к ней не приходят запросы в течение 5(?) минут. А ещё она выгружает старые модели, если требуется загрузить новую, а ресурсов не хватает.
Ускорители переключаются между моделями в реальном времени, прямо в процессе генерации ответов.
Они догадались, что после завершения вычислений одного слоя / группы слоёв можно не брать следующий, а переключиться на другую задачу? То есть они изобрели планировщик задач для GPU?
Так я ж и не говорю про нейросети, да и (массово, как стадо помешанных баранов) работу на них мы перекладываем буквально года 2-3. SQL, например, не вернёт вам то, чего вы не запрашивали. Численные методы решения дифф. уравнений дадут ответ формально неточный, но с известным диапазоном погрешности. С другой стороны, методом Монте-Карло уже десятки лет быстро получают приблизительные ответы, но без гарантии.
Только вот при использовании Монте-Карловых симуляций мы знаем, что для повышения точности в Х раз надо увеличить количество симуляций в Y - а с нейросетями у нас даже этого нет. Вы же не будете 1000000 раз скармливать её один и тот же промпт, чтобы ну прям почти наверняка получить точный ответ (после некоего "усреднения")? Вот и получается, что для каких-то "обзорных" запросов нейросети, в общем-то, подходят, а для точных ответов - точно не подходят.
А ещё можно ИИшечный рабочий репозиторий клонировать не из сети, а из локальной папки. Да, это добавляет потом работы тебе как “дирижёру” этих работяг по пушу этих веток ещё выше по апстримной иерархии, зато такой вот небольшой ценой защищает основной репозиторий от излишних активностей. Да и сетевой доступ тогда можно ещё сильнее зарезать.
Цитата из статьи, дословно - “В результате GPU несколько лет работал на предельных температурах.”
В комментариях на Reddit, кстати, тоже пишут, что вся ситуация звучит довольно странно: если проблема в перегреве VRM - она должна была проявиться на годы раньше. У чела периодически возникали чёрные экраны, но он аж почти пять лет списывал их на G-Sync или драйверы и, по сути, игнорировал. Ну вот кто в этой ситуации сам себе злобный Буратино? Да, ситуация неприятная, но раз уж терпел так долго и не жаловался - не стоит уже и начинать, поезд с гарантией ушёл. Гарантия от производителя, кстати, 3 года, то есть он не чуть-чуть не уложился, он прям основательно продолбал все сроки.
На днях с коллегами-программистами пришли к заключению, что если заменить “ИИ” на “индус” (из мемов про индусский код, разумеется) - ничего существенно не поменяется: эта сущность быстро и (относительно) дёшево напишет простыню кода, а потом четыре раза её перепишет, качество будет… сомнительным (но не для самой сущности, ей вообще без разницы), общаться не так уж и просто, для получения сколь-нибудь адекватного результата надо “кормить” крошечными разжёванными задачами, и так далее, и тому подобное
При всём понимании ситуации и сочувствии к buczi94, откуда компания или конкретные сотрудники СЦ, проводящие обслуживание, могут знать, что это действительно косяк с завода, а не сам buczi94 прилепил плёнку и собрал, а затем демонстративно разобрал?
К тому же, все сколь-нибудь прошаренные люди (а buczi94 таки сам нашёл проблему, значит он не совсем глупенький) знают, что перегрев означает проблемы с охлаждением, и надо почистить от пыли и проверить термоинтерфейсы на дееспособность. Но этот бедолага “почти пять лет” жил с “GPU, работающем на предельных температурах” - это надо быть очень невнимательным, или очень пофигистом. Хотя может быть питанию действительно было нормально всё это время, кроме небольшого срока в конце…
Хотя опять-таки, даже с таким дефектом, видеокарта проработала “почти пять лет” и больше гарантийного срока, то есть производитель свои гарантийные обязательства (в данном случае фактически нулевые, потому что обращений во время гарантийного срока не было) выполнил безупречно.
Anthropic: “ИИ нужно регулировать, нельзя допускать плохих гадостей из-за бесконтрольного развития”
Anthropic: “Наша новая модель такая опасная, мы боимся давать доступ широкому кругу лиц, только избранным организациям”
Anthropic: “Наша новая публичная модель - это та же самая опасная, только обезопашенная”
*Приходит запрет*
Anthropic: “Ну как так-то, это нечестно!”
При всём уважении к труду всё ещё настоящих сотрудников, это называется корпоративная биполярочка.
ripgrep и не стремится стать заменой обычному grep. Кстати, у вас в репозитории и ripgrep тоже есть, он достаточно популярный и быстрый, чтобы его просто игнорировать. Попробуйте на досуге
Что значит “до рабочего состояния”, вообще без ошибок? Тогда ни на чём, кроме всяких Coq и LEAN ничего рабочего не написали.
А так есть ripgrep, Zed и Helix, ruff, fish, uv, и много чего ещё
А это… Разве нельзя взять любой источник радиации (хоть даже естественный фон), счётчик Гейгера, просто количество частиц в единицу времени и брать остаток от деления?
По цене и по сложности это даже для кружка в старшей школе с инженерным уклоном пойдёт, вместо “15 милликельвинов”…
Пользуюсь Fedora аж с 13 версии, с переменной интенсивностью. На моей памяти, при обновлениях всей системы ломались только пакеты из сторонних репозиториев, которые ещё не успели подготовить к выходу нового релиза. Вся система вроде бы ни разу у меня не умирала ни разу (после первичной настройки, до неё бывало всякое - особенно весело раскочегаривать из минимальной установки).
А вот VirtualBox - та ещё зараза, бывает что даже после обычного обновления ядра перестаёт нормально работать, особенно в гостевой машине любит этот экстеншон отломиться.
Я примерно в декабре попросил одного такого нейробедолагу расставить мне типы функций в Python 2 (так надо) файлике.
Я сразу ему сказал, мол файл - на Python 2, расставь типы. Этот работяга заботливо расставил мне типы в стиле 3 Python, прям внутри сигнатур функций.
Я ему говорю, мол, что в 2 типы нужно писать в комментарии вида
# type: (str, bool) -> int. Он тут же побежал переделывать, и таки перенёс свои типы в эти комментарии... только сами комментарии он написал в той же строке, что и сама сигнатура функции.Я ему говорю, что вообще-то они должны идти в следующей за сигнатурой строке - он перенёс.
Потом мне уже совсем надоело, и я уже вручную исправил его
listна более адекватныеlist[string].То ли дело в локально развёрнутой сети (Qwen3-Coder 30b), то ли я не умею промпты писать, то ли им буквально надо разжёвывать каждую мелочь (вроде того же конкретного стиля написания этих типов) - но у него была одна работа, которую он делал 3 раза и всё равно за ним пришлось подчищать. Ну хоть сами типы он сумел адекватно вывести, а то бы вообще позор был.
Тем не менее, pkg-config файлы для libav-семейства можно в любом дистрибутиве Linux, какие могут быть проблемы? Есть готовый cmake_pkg_config, если же у вас древний CMake - ну что поделать, запускайте pkg-config вручную и выковыривайте оттуда.
Да и вообще, странно требовать от внешней зависимости, как она должна собираться...
Отправлял в Discord (десктопный). Видимо, бекенд по расширеню понял, что это видео, и решил его отдавать с плеерной обвязкой, а там уже фронтендовая часть сумела раскодировать по внутренностям.
Разработчик open source проекта несёт ровно столько же ответственности за исправление уязвимостей, сколько и closed source - очень часто "no warranty".
Размер (конкретного) ПО и количество багов конечно только если проект больше не получает новых фич, лишь исправления багов. И даже в этом случае, количество багов может расти: обновились системные библиотеки, железо, настройки окружения - и ваш продукт начал вести себя не как положено.
"теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей" - и эти 10 сканеров найдут 10 000 уязвимостей, из которых не галлюцинациями будут, скажем, 3% - как один человек это всё проверит? Почитайте Death by a thousand slops, особенно 4 пример, Buffer overflow in strcpy
"Например, можно включить дополнительную стадию в свой CI\CD процесс" - см. п. 3 про кучу не-уязвимостей. А кто будет за эти прогоны платить, лично GitHub?
Да.
Не обязательно быть мейнтейнером, чтоб стать контрибутором. Раз уж говорим про open source, то вот как раз патч прислать может любой мимокрокодил. Да, не факт, что любой "мимокрокодильный" патч примут как есть, но он как минимум покажет один из возможных методов исправления.
С другой стороны как раз сидит ИИшенка, которая по своему шаблону завела баг. И даже если нет - в самом баге УЖЕ написано, какие сроки разглашения - почему сторона, создающая баг не могла первой связаться с представителями проекта?
Когда вам в проект накидывают кучу... просто кучу, вам нужно потратить время и силы чтобы это всё разобрать, категоризировать, приоритизировать. В какой-то момент, накидываемая куча становится настолько большой, что вы не можете с ней совладать, и она начинает бесконтрольно расти, а настоящие баги начинают теряться. Это натуральный DoS.
Тем более мерзко, что примерно в то же время, кто-то из Google дал интервью вида "наше DeepSleep такое крутое, нашло 20 багов в мультимедиа продуктах - только вот их не исправили ещё".Это подгонка фактов и вампирский пиар. Аж сейчас упоминать про это противно, тьфу.
У меня в MS VS прям графический прогресс-бар рисуется :)
Простой счётчик файлов в принципе не сильно поможет решить проблему "Вы никогда не можете сказать сколько еще осталось ждать до окончания процесса":
есть великое множество single-header библиотек, они просто не попадут в счётчик как он есть. Это легко исправить, но...
файл на 50 строк и файл на 1050 строк будут собираться за очень разное время. Очень может быть, что у вас не очень большая программа, которая по тем или иным причинам собирает SQLite из его амальгамации - там пара
.hи.cзанимают вместе под 10 мегабайта ещё после сборки чаще всего идёт линковка, и может быть не одна (если это какой-то массивный проект с пачкой промежуточных библиотек), и может быть ещё и с LTO, которое может линковку замедлить в десятки раз
В итоге, конечно, со счётчиком чуть нагляднее, чем совсем вслепую, но не сильно точнее, чем прогресс-бары / счётчики при копировании файлов: есть и число файлов, и суммарный объём, и подсчёт уже затраченного времени - но предсказание всё равно плавает как ветка в шторм
Как будто бы мессенджеры не очень поддерживают MKV как видеоконтейнер?.. WebM, MOV - да, видел работающими.
Ради интереса записал OBSкой 2 секунды видео в MKV, но с обычными MP4шными кодеками (AVC + AAC LC). Telegram и Discord предлагают его скачать как любой другой бинарный файл, не показывают как видео (хотя Discord показывает превьюшку при отправке, видимо Electron сумел декодировать - Firefox тоже успешно воспроизводит MKV, если в него кинуться). Вот если переименовать файл в
.mp4- тогда всё нормально, подставляют плеер как положено.В статье очень не хватает информации, что этот баг найден в кодеке для LucasArts SANM / Smush. Соответственно, "в дикой природе" используется он только для просмотра катсцен в некоторых играх LucasArts.
Какая разница, где он найден? А такая, что просто так, при стандартных сценариях работы с современным мультимедиа, наткнуться на использование этого кодека невозможно.
Busy Beaver, как раз, не вычислимо, потому что
нужно решить проблему останова в общем случае (а то как вы определите, вот эта вот конкретная машина, сделавшая уже дофигаллиард операций, остановится, или ушла в бесконечный цикл?)
если оно вычислимо - можно написать конечную программу, считающую BB(n), следовательно, она будет реализована на машине Тьюринга с X состояниями, следовательно, BB(n) в принципе не может расти быстрее, чем позволяет реализовать машина Тьюринга с X состояниями, то есть до BB(x) оно растёт с одной скоростью, а после BB(x) резко замедляется? Парадокс?
Эти большие числа - на самом деле последовательности, и сравнивается не фактическое значение какого-то конкретного элемента, а скорость роста последовательности. Добавление слагаемых, возведение в степень, и даже применение функции к самой себе не увеличивает скорость роста фундаментально, поэтому это всё избыточно.
К сожалению, в статье не объясняется ничего, и не даётся никаких ссылок для заинтересовавшихся. Те крохи пояснений по теме, которые всё же попали в статью, в лучшем случае заставят вспомнить эффект
Манделымонады (как только вы начинаете понимать монады, вы теряете способность объяснить, что это такое), в худшем - RTFM.Буквально по этой теме, т.е. про число Лоадера, есть пара видео от CodeParade:
https://www.youtube.com/watch?v=Mzgw6zMtipQ
https://www.youtube.com/watch?v=kQLcoSuMKHg
Да, там тоже мало что объясняется для непосвящённых, но там хотя бы есть намёк на связное повествование. А не просто
Самодиагонализация(кого, чего?)Так, падажжи.
Обычная Ollama с настройками по умолчанию выгружает модель, если к ней не приходят запросы в течение 5(?) минут. А ещё она выгружает старые модели, если требуется загрузить новую, а ресурсов не хватает.
Они догадались, что после завершения вычислений одного слоя / группы слоёв можно не брать следующий, а переключиться на другую задачу? То есть они изобрели планировщик задач для GPU?
Так я ж и не говорю про нейросети, да и (массово, как стадо помешанных баранов) работу на них мы перекладываем буквально года 2-3.
SQL, например, не вернёт вам то, чего вы не запрашивали. Численные методы решения дифф. уравнений дадут ответ формально неточный, но с известным диапазоном погрешности. С другой стороны, методом Монте-Карло уже десятки лет быстро получают приблизительные ответы, но без гарантии.
Только вот при использовании Монте-Карловых симуляций мы знаем, что для повышения точности в Х раз надо увеличить количество симуляций в Y - а с нейросетями у нас даже этого нет. Вы же не будете 1000000 раз скармливать её один и тот же промпт, чтобы ну прям почти наверняка получить точный ответ (после некоего "усреднения")? Вот и получается, что для каких-то "обзорных" запросов нейросети, в общем-то, подходят, а для точных ответов - точно не подходят.