MSI Afterburner получит плагин GPUProbe для чтения скрытых датчиков видеокарт Создатель MSI Afterburner Алексей Unwinder Николачук представил встроенный плагин GPUProbe, который возрождает концепцию одноименного инструмента для RivaTuner. Плагин умеет считывать данные через регистры MMIO и шину I2C, открывая доступ к скрытым датчикам: температуре HotSpot, отдельных чипов VRAM, силовых элементов VRM и контроллеров питания. Пользователи смогут добавлять новые сенсоры самостоятельно через конфигурационные файлы, не дожидаясь официальных обновлений программы. В качестве примера автор показал интеграцию с кастомными картами ASUS ROG Astral. Плагин считывает ток с каждого контакта 12VHPWR и формирует «сигнал тревоги», если сила тока на пине превышает 12 А или разница между контактами составляет более 5,5 А. Afterburner может автоматически реагировать на аварийный статус — например, снижать Power Limit или выключать ПК. Из-за ограничений соглашений с NVIDIA полноценная встроенная поддержка этих функций в утилите отсутствует, поэтому GPUProbe останется плагином для энтузиастов.

Noctua проверила более 100 корпусов и нашла ошибки в спецификациях 56 моделей Компания Noctua вручную измерила реальный запас высоты под процессорные кулеры в сотне корпусов и зафиксировала расхождения с официальными ТТХ у 56 моделей. К примеру, в Lian Li B4-mATX заявлены 168 мм, но реальный замер показал 164,5 мм, из-за чего флагманский NH-D15 G2 туда просто не влезает. У ASUS Prime AP201 вместо паспортных 170 мм оказалось 168,3 мм — кулер помещается, но поднять вентилятор над высокой ОЗУ уже нельзя. Встречаются и обратные отклонения: у ряда корпусов Corsair фактический запас превысил заявленный почти на 10 мм. По итогам замеров австрийский производитель запустил собственную базу совместимости своих систем охлаждения с корпусами сторонних брендов. Компания планирует постоянно пополнять ее по мере тестирования новых моделей, чтобы уберечь пользователей от ошибок при сборке ПК.

Субботняя история Недавно во время отпуска мы останавливались в Стамбуле в одном дорогом и очень колоритном отеле. Называется он Divan Решил погуглить, что означает это слово. И вы не поверите - в турецком языке divan переводится как диван Оказывается, в Турции диван, это исторически важное и почётное место. Именно на диванах в Османской империи проходили заседания совета министров при султане. Сам совет, кстати, тоже назывался Divan. Так что, если вас когда-нибудь назовут «диванным экспертом», можно даже немного этим гордиться. Немного почувствовал себя министром и я, когда на очень удобном диване в нашем отеле, читая интересную книгу. Называется она - Your Life Is Manufactured. How the World Is Made and How We Can Do It Better (примерный перевод - Всё в вашей жизни произведено. Как создаётся наш мир и как мы можем делать это лучше ) Фото в шапке поста ⤴️ Это одна из самых впечатляющих nonfiction книг, которую я когда либо читал. Будь я действительно министром, сделал бы из этой книги учебник и заставил бы прочитать его всех студентов технических специальностей (да и гуманитариям, думаю, было бы очень полезно) Главная идея книги довольно простая - практически всё, что нас окружает, появилось в результате сложных производственных процессов. И большинство людей даже не представляет, насколько эти процессы сложны и насколько далеко друг от друга могут находиться участники одной производственной цепочки. Даже такая простая вещь, как рулон туалетной бумаги, это результат работы десятков предприятий, которые могут находиться на разных континентах. Кроме того, в книге есть история развития промышленности, промышленных революций и прогнозы автора о том, как производство будет развиваться в будущем. Во многом взгляд автора совпадает с моими представлениями о роли материального производства в жизни общества. Поэтому я хочу поделиться с вами некоторыми историями и идеями из этой книги в следующих постах. Пусть простит меня за это автор - Тим Миншалл, профессор производственных инноваций Кембриджского университета. Не переключайтесь. Незаметный бизнес

Борис описывает проблему, которая, на мой взгляд, является законом Лемана на стероидах (второй закон эволюции ПО):

Код будет гнить, если его гниению активно не противодействовать.

Это всегда было актуально и для человеческой разработки, особенно в больших проектах. Проблема с агентами в том, что с ними проект растёт и развивается гораздо быстрее, чем раньше, а значит, и гнить он начинает быстрее. Но я считаю, что это решаемая проблема даже на текущем уровне развития агентов и LLM. Нам с Уроборосом пришлось долго учиться противодействовать заслопливанию кода, и из этого в том числе появились принципы IMMUNE. Правильно выстроенная система адверсариального ревью тоже довольно неплохо помогает. Но ревью должно опираться на явную иерархию требований, начинающуюся с конституционных формулировок. В Уроборосе вершина этой иерархии лежит в BIBLE.md: требования важнее архитектуры, архитектура важнее реализации. На мой взгляд, ключевая проблема тут в том, что LLM нехватает длинного контекста, а основные харнессы плохо помогают им сохранять целостную ментальную модель проекта. Поэтому: 1. Я очень жду LLM с 10B контекстом. 2. Продолжаю развивать Уробороса и делать ставку на мета-системы, которые автономно улучшают и сам процесс разработки: "Improve the generator, not the generation". Мы точно не упёрлись в предел качества автономных агентов, а просто научились очень быстро генерировать код, при этом ещё плохо умеем с той же скоростью противодействовать его гниению.

🧨 Появился набор скиллов, которые мешают ИИ-агентам делать глупости и сжигать токены — ру дизайнер выкатил nodumbmode для фикса типичных ошибок. Внутри лежат 4 скилла: → nodumb — манифест здравого смысла для агента и набор главных рекомендаций. → changelog-discipline — ведёт журнал решений и записывает, что поменялось, почему и что отвергли. → system-feedback — проверяет, понятно ли юзеру, что произошло после действия и что делать при ошибке. → ask-nodumb — дизайнер-консультант, который разбирает продуктовую или UX-задачу до проектирования решения. Самое крутое — все скиллы собраны из реальных ошибок в проектах и новый скилл появляется только после конкретного фейла. Ставится за одну команду:

npx skills@latest add hronicasync/nodumbmode

Сохраняем — тут. @notboring_tech

And to remind you of bipolar nature of my mind, here are my notes on local LLMs: 1. 99% of them are horrible, just outright barely usable even for low-risk applications. Qwen 3.6 derivatives passed some benchmarks but SUX ARSE (Prism 27B included). Nvidia's own stuff is trash too. 2. The exact model is more important than the family. The size (8B, 12-14B, 27B, etc) maters less than how tuned and mixed it is. 3. For my goals I ended up with two very capable models: https://huggingface.co/Brunobkr/OFFELLIA_Gemma-4-E4B-8b-Claude-4.6-Opus-Reasoning-MTP - a tiny 7.5B model but very well tuned for tech stuff. Makes some mistakes, so ask wisely. Can run on a laptop. https://huggingface.co/mudler/gemma-4-26B-A4B-it-Claude-Opus-Distill-APEX-GGUF - fairly big MoE for all sorts of stuff. Eats tons of RAM, but Mix of Experts with APEX allows it to still be very fast. And I run stuff via LM Studio #AI@GameDEV

В США 50 штатов и в каждом штате свои законы, акты постановления. И если корпорация достаточно велика – она зависит от всех 50 штатов и хотела бы на все эти 50 штатов влиять. Когда в профильном комитете конгресса условной Невады возникает очередная не очень приятная для бизнеса идея, то лоббисту Walmart надо бы на всех парах мчаться именно в Неваду, стучаться именно в этот комитет, и объяснять, доказывать, договариваться. #стартапдня State Affairs продает удобный инструмент для мониторинга таких идей. Его продукт – база знаний обсуждений, законопроектов, предложений и прочих личинок будущих законов. Они ещё не приняты и не опубликованы официально, на них ещё можно повлиять – и именно в этот момент живой человек прямо из здания конгресса вносит их в систему, а AI перерабатывает в пригодный для поиска и фильтрации вид. Клиент спрашивает что-то типа: “какие есть обсуждения по маркировке AI-контента” и сразу узнает общий срез по всем стране. Мониторинг одного штата стоит порядка 600 долларов в год – и State Affairs утверждает, что треть законодателей страны платят эту сумму, чтобы читать по сути про самих себя. Полная подписка на США целиком обходится корпорациям уже в десятки тысяч долларов – впрочем, для них всё равно копейки. Инвестиций стартап привлек около 70 миллионов. Любопытно, что существенную их часть он потратил на покупку старых, иногда столетних микробизнесов – местных парламентских вестников в столицах штатов. Их бывшие корреспонденты как сидели на слушаниях, так и сидят. Для них изменилась только админка, куда надо загружать отчеты. https://stateaffairs.com/ #сша #юристы #roundb

Ваши вопросы к представителям компании на собеседовании - очень важный этап. Он же может стать решающим. Я как то на собеседовании в Мету на менеджера спросил могу ли я уволить всю команду в один день и нанять новую. В те далекие долэйофные годы следующего этапа не последовало. Это был один из вопросов Бугаенко "на менедждера", в Лондон я переезжать не планировал поэтому ради прикола решил спросить. Один раз живем. Так вот. По следам треда @beshenadze решил написать, что стоит спрашивать, а какие вопросы стоит задавать когда уже пройдете испытательный срок. Во-первых: совершенно точно нужно задавать вопросы! Особенно если вы идете на сеньорную позицию. Если у вас нет вопросов - это очень плохой сигнал:  Вы читали про компанию и ее бизнес? Вам совсем не важно как с кем и с чем вы будете работать? Ничего не хотите добавить к своим ответам? Что точно не стоит спрашивать Давать непрошеные советы и критиковать выбор людей. Даже если мягко. Во-первых у тебя околонулевой контекст. Даже если ты изначально спросил какая у них платформа (хороший вопрос), а потом начинаешь критивовать и сокрушаться, что они все выбрали не правильно. Тебе скорее всего ответили прямым ответом: У нас технология Х. У тебя нет необходимых данных, метрик и причин почему у них так. И за одну минуту ответа ты не сможешь открыть тупым глаза на их ошибки и заработать авторитет. Но ты можешь показать, что ты с порога несогласен. Начинаешь давать советы неразобравшись. Зачем тебя брать если ты уже недоволен с чем тебе придется работать? На собеседовании ты продаёшь не только экспертизу, но и предсказуемость. Компания (особенно если это уже работающий бизнес, а не совсем зелёный стартап) хочет понять: Ты сможешь встроиться в существующую систему? Ты будешь решать их проблемы или создавать новые? Ты уважаешь чужой контекст или сразу начинаешь мерить всё своей меркой Критиковать само собеседовение тоже не стоит. Особенно в лицо людям, которые к дизайну собеседования не имеют отношения. Как например спрашивать, пишут ли программисты алгоритмы каждый день на работе? Кому что кроме своей раздражительности ты этим вопросом хочешь показать? Особенно если ты НЕ МОЖЕШЬ решить задачу. Что стоит спрашивать На собесе ты исследователь и дипломат. Молчать совершенно точно нельзя, а задавать качественные вопросы, которые показывают сеньорность. Если ты молчишь и только киваешь, ты выглядишь как исполнитель, а не как человек, который будет влиять на архитектуру. Хороший баланс — задавать вопросы, которые раскрывают ситуацию, а не оценивают её. Про нагрузку и масштаб «Какая сейчас нагрузка? Какие планы по росту на год-два?» Про текущие боли «Какие самые болезненные проблемы прямо сейчас в инфре/деплое/костах?» Про структуру команды «Как устроена команда? Кто принимает архитектурные решения? Как выглядит процесс изменений?» Про бизнес-контекст «Какие требования бизнеса сейчас важнее всего: скорость фич, косты, надёжность?» Про квалификацию и процессы «Какой уровень экспертизы в команде по платформе/куберу/терраформу?» Про историю развития «Это первая версия системы? Как бы выглядела идеальная система для этой задачи? Какие риски в текущей архитектуре вы видите?» Можно урвать эти 5 минут и наоборот уточнить свой ответ, если вы осознали, что что-то недосказали. Этой возможностью вообще довольно редко пользуются. Самый сильный сигнал сеньорности — это когда ты: задаёшь точные вопросы; демонстрируешь, что понимаешь компромиссы; оставляешь пространство для того, что у них могут быть на все веские причины о которых тебе не рассказали. На собеседовании твоя главная задача — собрать максимум информации и показать, как ты думаешь, а не «спасти» компанию от страшной ошибки за 5 минут. А уже после оффера (или испытательного срока), когда ты внутри и у тебя есть полный контекст и выстроены отношения блядь, — можно и нужно спорить, отстаивать свою точку зрения.

Интересное в мире хай-тек 7 августа 2026 Кратко о событиях за прошедший день 🌐 Google Chrome начнёт требовать до 20 ГБ свободного места для загрузки локальных ИИ-моделей. Ранее пользователи уже заметили фоновую установку Gemini Nano на 4 ГБ, а теперь Google расширяет требования для On-device AI. 💸 Bybit подала иск против КНДР и группировки Lazarus из-за крупнейшей криптокражи на $1,5 млрд. Биржа уже добилась заморозки части похищенных средств — атака привела к потере более 400 тыс. ETH и stETH. 😀 OpenAI готовит первый собственный гаджет — умную колонку в форме пончика, созданную вместе с Джони Айвом. Устройство без экрана получит камеры, датчики и движущиеся элементы, а выход запланирован на 2027 год при цене выше $300. 🦴 В Steam бесплатно раздают Breathedge — сюжетный выживач в космосе с полной русской локализацией. Забрать игру можно до 9 августа. ✊ AMD обнаружила уязвимость TONTOU в процессорах Zen 1–4, которая позволяет обходить защиту Linux от атак Spectre V2. Проблема затрагивает Ryzen 1000–7000/8000G, но AMD уже выпустила исправление, включённое в актуальные ядра Linux. 🎦 На PRO Hi-Tech вышло видео, в котором разберем, насколько важен процессор для игр, как со временем меняются требования к нему и почему нельзя оценивать видеокарту в отрыве от CPU. #хайтекзадень

Заменит ли AI журналистов ✍️ Пока я без устали переписываю за авторами текстов ужасные иишные формулировки, уж точно нет. Ну а если серьезно, многие из тех, кто не занимается медиа профессионально и думает, что медиа полностью можно делать с помощью ИИ, ошибаются в одном: журналистика — это не только производство текста. В последнее время дискуссий на эту тему много в англоязычной прессе, и я стараюсь за ними следить. Substack, например, выпустил целый цикл интервью с уважаемыми журналистами, писателями, редакторами и авторами о том, как они используют ИИ. А The Rebooting Брайана Моррисси вместе с WordPress VIP сделали целый отчет о том, как AI меняет доверие, прозрачность и редакционную репутацию. Опросили 40 медиапрофессионалов, почти половина из которых — топ-менеджеры. Главный вывод такой — редакции уже используют AI почти повсеместно, но в основном не для того, чтобы заменить журналистов, а чтобы ускорить работу. 87% респондентов используют AI для ресерча, 53% — для SEO-оптимизации, 42% — для анализа аудитории, 37% — для создания саммари и заголовков. И только 18% пишут с помощью ИИ тексты. При этом 94% считают, что журналистика, которую делают люди, остается критически важной для доверия аудитории. Самый интересный вывод отчета — доверие больше нельзя просто наследовать как часть сильного бренда. Раньше редакция могла во многом опираться на репутацию — мы медиа с таким-то брендом, значит, нам можно верить. Теперь этого недостаточно. Аудитория все чаще хочет понимать, кто стоит за материалом, как он был сделан, где использовался AI, кто проверял факты и по каким правилам работает редакция. Авторы отчета называют такой подход open kitchen — открытая кухня. Хорошая формулировка для медиа в эпоху AI. Редакциям придется больше показывать людей, процессы, источники, стандарты и саму механику работы и выстраивать отношения с читателем. При этом у большинства команд пока нет нормальной системы управления AI. 62% организаций формально не отслеживают его использование, у 24% нет понятного ответственного за AI-стратегию, а только 12% связывают AI с измеримыми результатами. То есть инструмент уже работает внутри редакций, а правила, ответственность и метрики часто еще догоняют реальность. AI, конечно уже помогает ускорять ресерч, разгребать рутину, измерять аудиторию, собирать черновики и заголовки. Но конкурентным преимуществом медиа станет не скорость генерации текста, а то, что ИИ не умеет и никогда не научится делать — репортерская работа, общение с источниками и спикерами, мнение авторов, прозрачность и доверительные отношения с читателем. Ниже пара интересных графиков из отчета 🔽 @karpovaventures✍️

❓ Научитесь отвечать на вопрос «зачем?», прежде чем ставить задачу ИИ Моё знакомство с Codex началось, когда появилась вполне конкретная задача: собрать сайт для @mirabistro. Сайты я делал и раньше — первый написал на PHP ещё в восьмом классе. Но никогда не вайбкодил и относился к этому довольно скептически. Несмотря на десять лет работы в анализе данных, мне казалось, что нормальный рабочий продукт всё равно придётся долго собирать руками. А тратить время на проект без понятной цели я не хотел. 🌐 Здесь наконец появилась конкретная цель. К тому же все «эксперты по ИИ» в соцсетях уже рассказывали, что теперь такие вещи можно собрать чуть ли не за один вечер. Я решил проверить — и сайт действительно получился. Напишите в комментариях, как он вам 👇 После этого я начал вайбкодить почти каждый день. 😁 Но именно тогда я понял главное: когда ИИ позволяет очень быстро собрать практически любой MVP, становится особенно важным ещё до начала работы ответить на вопрос: «зачем?» 🏠 Недавно у меня появилась новая «задача». Дома стоит старый видеодомофон Tantos. У него есть приложение vhOme, которое работает довольно медленно, не присылало уведомления о звонках на iPhone и просто не нравилось мне визуально. Приложения под Android я тоже писал — как вы помните. Правда, это было ещё в 2014 году. И самое смешное, что vhOme выглядело примерно так же, как мои приложения того времени. Но у меня хотя бы не было дизайнера. Точнее, дизайнер был — я сам 😅 Я такой: — Сейчас сделаю своё приложение. 📱 Закинул в Codex APK Android-приложения. Он разобрал его, вытащил используемые методы, нашёл механизмы подключения к домофону и получения видеопотока. Ещё немного — и можно было начинать писать полноценное приложение под iOS. Можно было упороться окончательно: сделать системный экран входящего звонка, после ответа сразу открывать видео, добавить две кнопки — «Открыть» и «Не открывать», оформить аккаунт разработчика и попробовать выложить всё это в App Store. В целом многие приложения теперь действительно можно допиливать и переделывать под себя. Если есть работающий клиент, ИИ способен исследовать его поведение, разобраться с протоколами и собрать свое решение. В итоге я потратил несколько часов на исследование vhOme. 🤔 Но перед тем, как переходить к полноценной разработке и публикации в App Store, я всё-таки остановился и задумался: а точно ли эту задачу нужно решать таким сложным способом? Нет ли чего-то проще? И главное: зачем мне вообще собственное приложение? Мне было нужно не приложение само по себе. Мне было нужно не пропустить звонок в дверь. 🔔 А потом выяснилось, что проблема была не в домофоне: пришлось поиграться с режимами «Фокусирование» на iPhone и правильно настроить допуск уведомлений. После этого они начали приходить. Собственное приложение с быстрым переходом к видео и двумя кнопками всё ещё было бы удобнее. Но когда пуш уже работает, потенциальный аплифт от разработки резко снижается. 🎓 Если, конечно, перед вами не стоит образовательная цель. Тогда ответ на вопрос «зачем?» тоже есть: разобраться в чужом приложении, исследовать протоколы и научиться собирать собственные продукты под iOS. В этом случае само исследование уже становится результатом. 🤔 Но изменилось ли что-то с появлением вайбкодинга? В вопросе целеполагания — ничего. Ведь и раньше существовало огромное количество бесполезных стартапов, научных статей и корпоративных проектов, которые пятый год подряд делают одно и то же второй раз. ИИ не решает проблему целеполагания. Он помогает быстрее написать код и дешевле проверить гипотезу, но не способен решить за вас, какой результат действительно нужен и стоит ли вообще браться за проект. 🎯 Поэтому главный навык сейчас — умение отвечать на вопрос «зачем?». Так было всегда: на вопрос «зачем?» должен уметь отвечать заказчик и любой руководитель, который несёт ответственность за результат. Но теперь, когда вы ставите задачу ИИ и с его помощью пишете код, вы тоже становитесь руководителем — как минимум собственного проекта. А значит, теперь и вам нужно уметь отвечать на главный вопрос: «зачем?»