ИМХО данный термин о тренде, а не о конкретной методике/системе методик.
Методики ещё 100 500 раз поменяются, потому что ещё ничего не устаканилось. Например, мы только‑только начинаем подходить к моменту, когда сети LLM начнут не просто генерить код, а еще его пробовать компилировать, запускать и отлаживать. И будет «вайбкодинг уже не тот»
Вы оспариваете релевантность мнения компилятора о коде?
Как посмел!!!
Я говорю о сложности и многогранности подходов при оценке и конструировании сложных систем, и об отсутствии универсального подхода. Слепо следовать догмам из умных книжек умных людей конечно всегда проще, но думать головой — эффективнее. А брать какие‑то два готовых подхода, да ещё и устраивать из них дихотомию, причём в отрыве от контекста, это... ну, скажем так, довольно бессмысленно.
PS. У компилятора нет мнения, потому что компилятор — автомат. Хороший автомат, сделанный умными людьми.
Важна ещё релевантность. Мой кот как то понюхал мой хеллоуворлд на QSharp на планшете и начал его закапывать. Но есть сомнения в его знаниях о квантовой механике.
Мк рано или поздно кто‑нибудь автоматизирует то, что Вы делали вручную.
Некая штука, которая комплексно смотрит разные признаки в тексте статьи/комента и у автора в профиле, и выдаёт «вероятность иишности». Можно в виде расширения для хрома, с опцией «скрыть всё с иишностью выше X%».
Методы выявления могут быть как алгоритмическо‑статистические, так и ИИшные (клин клином :3). Можно, например, нафайнтюнить какую‑нибудь небольшую LLM, чтобы ей на вход текст, а она тебе крошечный json с единственным числом от 0 до 100. Главное чтобы детекторов было много разных, и итоговая была суперпозицей их результатов.
Про поворот экрана - меня дико бесит то как он сделан на Android: ты поворачиваешь экран, а телефон реагирует на это ну через секунду примерно, это отвратительно. При этом датчики не тупят, не ошибаются, экран перерисовать недолго. Но пользователь оказывается в ненужном тильте всё время поворота. Эта секундная задержка всё никак не убирается сообществом... Короче, поворот это вещь полезная, но не для всех удобная. Хотя, в случае с Андроидом, поддержка поворота экрана синонимична "адаптиву" - правильной работе приложения на абсолютно любых экранах.
Тут есть ещё проблема с устройствами с изменяемой диагональю — будь то складные или раздвигаемые смартфоны. В большинстве случаев это работает не просто криво, а очень криво. По лагу на поворот соглашусь, но тут имхо дело в тупизне акселерометров.
Акселерометры обычно выдают ужасно зашумлённые данные, самый тупой способ бороться с этим для однозначного определения ориентации — усреднять последние N значений, что, ИМХО, в большинстве случаев и делается. Айфон сам по себе качественная железяка, датчики там скорее всего качественнее стоят с меньшим шумом + у айфонов отдельный аппаратный декодер для датчиков, который давит шумы, и делает это далеко не тупым усреднением. Скорее всего там даже не фильтр Калмана, а что‑то посерьёзнее, с небольшим ИИ может быть. Поэтому айфон лучше и быстрее понимает, в каком положении его держат.
Топовые андройдофоны скорее всего тоже обладают качественными датчиками, но вот ПО, вследствие своей универсальности, заточено работать и с плохими, и с хорошими данными, поэтому «на всякий случай» делают лаг по времени. Плюс декодирование и шумоподавление там в подавляющем большинстве случаев, если вообще не всегда, делается софтверно. А это уже компромиссы, потому что батарея.
Про анимации — ты говоришь что тебе не нравится что они вычисляются в реальном времени? Ну смотри: у нас есть оркестратор, который отвечает за отрисовку - каждый кадр который видишь на телефоне - был запланирован им. Если предыдущий ещё не нарисовался, то следующий не нужен. Таким образом, непоказываемые кадры не рассчитываются. Что вообще рассчитывается в кадре? Много всего, но если сильно упрощать то размеры и положения UI. Анимация зависит как раз от этих параметров. Поэтому вычислять её в реальном времени - логично и адаптивно. Немного математики, и линейное движение превращается в 3д перемещение с переменным приращением и эластичностью.
Я может неточно выразился — мне, наоборот, нравится, что они вычисляются в реальном времени. И под реальным временем я имел ввиду что ОС айфонов гибридная, и реакция на UI там обрабатывается (по крайней мере, обрабатывалась раньше) подходами, близкими к подходам работы ОС реального времени. То есть на уровне ядра ОС планировщик учитывает необходимость своевременного расчета кадров GUI.
А внутреннюю кухню анимаций я хорошо понимаю — довольно долго занимался разработкой тяжёлого десктопного ПО для обработки видео в реальном времени. Там и анимации были, и синхронизация c чересстрочной развёрткой, и много чего ещё. В частности, делал интерпретатор скриптов с нативной поддержкой этих самых нелинейных анимаций на уровне синтаксиса, с синхронизацией с кадровым потоком. Это не GUI, но, ИМХО, архитектура и подходы здесь почти идентичны.
рано или поздно всё заканчивается, и им придётся снова завоёвывать расположение аудитории
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.
Внимание к деталям плавно ушло вместе со Стивом Джобсом. Тим Кук — он, в первую очередь, про зарабатывание здесь и сейчас, а не про инновации и сверхдолгосрочные вложения (например, когда внимание к деталям создаёт имидж и окупается десятилетия). 20% усилий даёт 80% прибыли и вот это всё.
Даже анимация поворота экрана у современной техники Apple значительно упростилась. Меньше фишек с разной массой у разных элементов экрана, с размытием движения, с тем, что частота опроса сенсора выше частоты экрана в N раз, с тем, что анимации считаются почти в реальном времени. Пропорции не соблюдаются, GUI всё реже продумывают как целостную композицию, а не просто утилитарную картинку.
Одновременно с этим подтянулось качество конкурирующих продуктов — Android и Windows. Речь и о технических аспектах, и внимании к деталям, и внимании к дизайну и удобству. В начале 2010 годов даже топовый андройд по сравнению с айфоном был тормозным лагающим недоразумением. Сейчас «андройд» почти уже не лагает, а «айфон» начал всё больше лагать. Эстетика наконец‑то проросла в Android, Windows, Linux. А с айфоноайпадов постепенно слезает лоск. Оно просто сделано добротно, но не больше.
Есть и другой аспект: все эти электронные побрекушки из чего‑то вау стали не то чтобы обыденностью, они стали инфраструктурой. Типа батарей отопления, электрических розеток и унитазов. В начале жизненного цикла батареи и унитазы тоже были с вниманием к деталям, и тоже были круто‑дорого. Сейчас унитазы и розетки это само собой разумеющееся. Так и тут. Ноут толщиной 9 мм и смартфон сейчас это как электрическая лампочка, а не «ого у тебя целый комп в кармане, да еще и с 320 ядерным процессором 100 ГГц, как же это круто, а через год будет 101 ГГц это вообще мир перевернёт, инфа 100»
Более того, я подозреваю, что сейчас внимание к деталям постепенно будет уходить из многих сфер, в том числе, оно будет теряться у предметов премиального класса. Вместо этого будет имитация внимания к деталям. AI‑дженирейтед слоп воплощённый в 3D/4D печати и всё такое. И в софте, разумеется, в софте.
Мир меняется, становится нестабильным, обрастает войнами и кризисами (не только финансовыми), связи рвутся. Система ценностей, заточенная под спокойную размеренную жизнь, уходит, вместе с ней уходят мечты, цели и подходы, заточенные под неё. А новые пока ещё не родились. Но, мне кажется, так или иначе, в новом мире правило 80/20 будет применяться гораздо шире и мощнее. Военная утилитарность будет плавно проникать в быт и моду.
То, что происходит с Apple — это плавная адаптация ко всем этим фундаментальным изменениям. Им как раз сейчас нужен именно кто‑то вроде Тима Кука, а не Стива Джобса, просто потому что сейчас не 2010е.
Помимо полной поддержки AVX512 есть ещё поддержка на логическом уровне — формально инструкция поддерживается, но реально процессор выполняет её как две 256-битных. Я столкнулся с этим на своём CPU пока писал управление светодиодными лентами. CPU по документации вроде AVX512 поддерживает, но скорость от AVX2 по факту не отличается. Сначала я думал, что виноват C#, и по‑нормальному надо для таких задач использовать C++. Однако, раскопав документацию процессора поглубже, я понял, что регистры AVX512 вроде как есть, а вот обработчиков нет — вместо этого срабатывают AVX2 в два этапа. Полноценный AVX512 — это к ксеонам/тредрипперам/эпикам.
А ещё у AVX512 гораздо более удобный shuffle, который может переносить любые байты в любое место. У AVX256 насколько мне известно две половинки по 128 бит, которые между собой перемешивать не получится. Но могу ошибаться.
Приходилось писать реалтаймовое автоматическое выравнивание камер глубины между собой (RealSense D415), то есть вычислять относительно одной камеры положение всех остальных. Нужно это было для реалтаймового 3D сканирования с текстурой — строим несколько поверхностей и сшиваем.
Выравнивание сделал так: ищем общие точки на цветных 2D картинках, через канал глубины вытаскиваем расстояние до них и рассчитываем их 3D координаты в локальной системе отсчёта конкретной камеры, дальше уже простая триангуляция. Ну то есть вот треугольник видит одна камера, вот другой треугольник видит другая камера. Мы знаем, что это в реале эти два треугольника на самом деле один и тот же треугольник, поэтому можем посчитать матрицу трансформации.
D415 шумит конечно, но точек много, комбинаций по 3 точки ещё больше, поэтому немного медианной фильтрации, усреднения и кое‑какой магии — и вот уже точность +‑ приемлемая. Камеры, в основном, стояли на месте, их иногда могли перенести куда‑нибудь или просто случайно сместить. Поэтому я мог позволить себе оооочень долгое интегрирование по времени :)
Так вот, есть мысли что подобный подход применим и тут, и высоковероятно, что ресурсов жрать оно будет меньше, чем нейросетка, даже в случае с монокулярной камерой. Фактически при движении дрона мы получаем новые ракурсы, и нам нужно просто узнать координаты нового местоположения в системе координат предыдущего (или нескольких), и просто интегрировать путь.
А ещё это довольно несложно (относительно) впихнуть в ASIC и производить по 50 000 штук в месяц.
Смотря сколько лент надо контролировать, сколько диодов на них и с какой частотой их переключать. Если их несколько тысяч, простые контроллеры могут не переварить.
максимальной задержкой около 6 мкс, а реализовать это - нетривиальная задача, и такой подход даёт большую загрузку микроконтроллера обработкой этих прерываний
Более чем. Делал протокол WS2812b руками на nopах, забил всю память STM32 Discovery. На таймерах/SPI получилось бы сильно проще и меньше.
Системный промпт «Отвечай на русском» без кавычек, Flash Attenuation вкл, пул потоков 16 (было 12, но вряд ли это влияет на результат), остальное по дефолту.
Эти промпты лишены человеческого смысла, но они внутренне когерентны, и их форма резонирует с паттернами модели. И LLM будет на них отвечать.
Вполне себе оно засекает, что тут что-то не то.
Остальные
Но в целом рекомендации довольно интересные, неплохо протестировать на разных моделях. В частности, есть ли разница в применении этих методологий при работе с обычными и рассуждающими LLM, и что будет, если миксовать их с другими подходами, например, игрой с температурой.
А ещё интересно, есть ли аналогичные трюки для VLM. Например, подгружать дополнительно картинку с какой‑нибудь бессмыслицей, которая по факту улучшит выдачу.
Потому что поддержка у этого свойства в css только с 25 года только в новейших браузерах.
А что мешает сделать микросервис, который на вход жрёт шрифт, а на выходе дает всю нужную инфу о его размерах и прочих ТТХ? В конце концов это можно сделать на бекенде с кешированием. В общем, может я опять перегибаю оверинжиниринг, но для меня подобные проблемы выглядят как‑то диковато.
В WPF для десктопа 2008 года всё это было из коробки. Там только рендеринг шрифтов в самом начале был размытый из‑за игонра хинтинга, но это быстро починили. Почему эти сверхтехнологии инопланетных цивилизаций дошли до веба в 2025 году, большая загадка. И это при том, что сейчас на WebKit делают буквально почти всё.
Это я чего так: приходится бывает на другом проекте что-то делать, а там бардак - дизайнер ни тему не сделал, так ещё и сам по себе решил это обрезание подрубить. Ему говорим исправь - ему пофиг. В итоге все паддинги и тд приходилось вручную подбирать.
Ну имхо это уже организационная проблема, а не техническая. Работали бы нормально паддинги, что‑нибудь другое бы дизайнер забыл бы сделать.
Ок
Реальный, игрался с дым‑машиной :)
ИМХО данный термин о тренде, а не о конкретной методике/системе методик.
Методики ещё 100 500 раз поменяются, потому что ещё ничего не устаканилось. Например, мы только‑только начинаем подходить к моменту, когда сети LLM начнут не просто генерить код, а еще его пробовать компилировать, запускать и отлаживать. И будет «вайбкодинг уже не тот»
Фотографируйте в RAW/DNG.
Артхауса же. А вообще штука годная, даже не для артхаусного кода. Наконец‑то можно будет сократить пепекторы до вменяемого размера
Как посмел!!!
Я говорю о сложности и многогранности подходов при оценке и конструировании сложных систем, и об отсутствии универсального подхода. Слепо следовать догмам из умных книжек умных людей конечно всегда проще, но думать головой — эффективнее. А брать какие‑то два готовых подхода, да ещё и устраивать из них дихотомию, причём в отрыве от контекста, это... ну, скажем так, довольно бессмысленно.
PS. У компилятора нет мнения, потому что компилятор — автомат. Хороший автомат, сделанный умными людьми.
Важна ещё релевантность. Мой кот как то понюхал мой хеллоуворлд на QSharp на планшете и начал его закапывать. Но есть сомнения в его знаниях о квантовой механике.
Мк рано или поздно кто‑нибудь автоматизирует то, что Вы делали вручную.
Некая штука, которая комплексно смотрит разные признаки в тексте статьи/комента и у автора в профиле, и выдаёт «вероятность иишности». Можно в виде расширения для хрома, с опцией «скрыть всё с иишностью выше X%».
Методы выявления могут быть как алгоритмическо‑статистические, так и ИИшные (клин клином :3). Можно, например, нафайнтюнить какую‑нибудь небольшую LLM, чтобы ей на вход текст, а она тебе крошечный json с единственным числом от 0 до 100. Главное чтобы детекторов было много разных, и итоговая была суперпозицей их результатов.
Тут есть ещё проблема с устройствами с изменяемой диагональю — будь то складные или раздвигаемые смартфоны. В большинстве случаев это работает не просто криво, а очень криво. По лагу на поворот соглашусь, но тут имхо дело в тупизне акселерометров.
Акселерометры обычно выдают ужасно зашумлённые данные, самый тупой способ бороться с этим для однозначного определения ориентации — усреднять последние N значений, что, ИМХО, в большинстве случаев и делается. Айфон сам по себе качественная железяка, датчики там скорее всего качественнее стоят с меньшим шумом + у айфонов отдельный аппаратный декодер для датчиков, который давит шумы, и делает это далеко не тупым усреднением. Скорее всего там даже не фильтр Калмана, а что‑то посерьёзнее, с небольшим ИИ может быть. Поэтому айфон лучше и быстрее понимает, в каком положении его держат.
Топовые андройдофоны скорее всего тоже обладают качественными датчиками, но вот ПО, вследствие своей универсальности, заточено работать и с плохими, и с хорошими данными, поэтому «на всякий случай» делают лаг по времени. Плюс декодирование и шумоподавление там в подавляющем большинстве случаев, если вообще не всегда, делается софтверно. А это уже компромиссы, потому что батарея.
Я может неточно выразился — мне, наоборот, нравится, что они вычисляются в реальном времени. И под реальным временем я имел ввиду что ОС айфонов гибридная, и реакция на UI там обрабатывается (по крайней мере, обрабатывалась раньше) подходами, близкими к подходам работы ОС реального времени. То есть на уровне ядра ОС планировщик учитывает необходимость своевременного расчета кадров GUI.
А внутреннюю кухню анимаций я хорошо понимаю — довольно долго занимался разработкой тяжёлого десктопного ПО для обработки видео в реальном времени. Там и анимации были, и синхронизация c чересстрочной развёрткой, и много чего ещё. В частности, делал интерпретатор скриптов с нативной поддержкой этих самых нелинейных анимаций на уровне синтаксиса, с синхронизацией с кадровым потоком. Это не GUI, но, ИМХО, архитектура и подходы здесь почти идентичны.
This. Хайп сложился из внимания к деталям и маркетинга. Сейчас этот хайп живёт по инерции, она не бесконечна, и однажды кончится. А «снова завоёвывать расположение аудитории» у них уже не получится. К тому времени мир будет совсем другим.
Внимание к деталям плавно ушло вместе со Стивом Джобсом. Тим Кук — он, в первую очередь, про зарабатывание здесь и сейчас, а не про инновации и сверхдолгосрочные вложения (например, когда внимание к деталям создаёт имидж и окупается десятилетия). 20% усилий даёт 80% прибыли и вот это всё.
Даже анимация поворота экрана у современной техники Apple значительно упростилась. Меньше фишек с разной массой у разных элементов экрана, с размытием движения, с тем, что частота опроса сенсора выше частоты экрана в N раз, с тем, что анимации считаются почти в реальном времени. Пропорции не соблюдаются, GUI всё реже продумывают как целостную композицию, а не просто утилитарную картинку.
Одновременно с этим подтянулось качество конкурирующих продуктов — Android и Windows. Речь и о технических аспектах, и внимании к деталям, и внимании к дизайну и удобству. В начале 2010 годов даже топовый андройд по сравнению с айфоном был тормозным лагающим недоразумением. Сейчас «андройд» почти уже не лагает, а «айфон» начал всё больше лагать. Эстетика наконец‑то проросла в Android, Windows, Linux. А с айфоноайпадов постепенно слезает лоск. Оно просто сделано добротно, но не больше.
Есть и другой аспект: все эти электронные побрекушки из чего‑то вау стали не то чтобы обыденностью, они стали инфраструктурой. Типа батарей отопления, электрических розеток и унитазов. В начале жизненного цикла батареи и унитазы тоже были с вниманием к деталям, и тоже были круто‑дорого. Сейчас унитазы и розетки это само собой разумеющееся. Так и тут. Ноут толщиной 9 мм и смартфон сейчас это как электрическая лампочка, а не «ого у тебя целый комп в кармане, да еще и с 320 ядерным процессором 100 ГГц, как же это круто, а через год будет 101 ГГц это вообще мир перевернёт, инфа 100»
Более того, я подозреваю, что сейчас внимание к деталям постепенно будет уходить из многих сфер, в том числе, оно будет теряться у предметов премиального класса. Вместо этого будет имитация внимания к деталям. AI‑дженирейтед слоп воплощённый в 3D/4D печати и всё такое. И в софте, разумеется, в софте.
Мир меняется, становится нестабильным, обрастает войнами и кризисами (не только финансовыми), связи рвутся. Система ценностей, заточенная под спокойную размеренную жизнь, уходит, вместе с ней уходят мечты, цели и подходы, заточенные под неё. А новые пока ещё не родились. Но, мне кажется, так или иначе, в новом мире правило 80/20 будет применяться гораздо шире и мощнее. Военная утилитарность будет плавно проникать в быт и моду.
То, что происходит с Apple — это плавная адаптация ко всем этим фундаментальным изменениям. Им как раз сейчас нужен именно кто‑то вроде Тима Кука, а не Стива Джобса, просто потому что сейчас не 2010е.
Помимо полной поддержки AVX512 есть ещё поддержка на логическом уровне — формально инструкция поддерживается, но реально процессор выполняет её как две 256-битных. Я столкнулся с этим на своём CPU пока писал управление светодиодными лентами. CPU по документации вроде AVX512 поддерживает, но скорость от AVX2 по факту не отличается. Сначала я думал, что виноват C#, и по‑нормальному надо для таких задач использовать C++. Однако, раскопав документацию процессора поглубже, я понял, что регистры AVX512 вроде как есть, а вот обработчиков нет — вместо этого срабатывают AVX2 в два этапа. Полноценный AVX512 — это к ксеонам/тредрипперам/эпикам.
А ещё у AVX512 гораздо более удобный shuffle, который может переносить любые байты в любое место. У AVX256 насколько мне известно две половинки по 128 бит, которые между собой перемешивать не получится. Но могу ошибаться.
Приходилось писать реалтаймовое автоматическое выравнивание камер глубины между собой (RealSense D415), то есть вычислять относительно одной камеры положение всех остальных. Нужно это было для реалтаймового 3D сканирования с текстурой — строим несколько поверхностей и сшиваем.
Выравнивание сделал так: ищем общие точки на цветных 2D картинках, через канал глубины вытаскиваем расстояние до них и рассчитываем их 3D координаты в локальной системе отсчёта конкретной камеры, дальше уже простая триангуляция. Ну то есть вот треугольник видит одна камера, вот другой треугольник видит другая камера. Мы знаем, что это в реале эти два треугольника на самом деле один и тот же треугольник, поэтому можем посчитать матрицу трансформации.
D415 шумит конечно, но точек много, комбинаций по 3 точки ещё больше, поэтому немного медианной фильтрации, усреднения и кое‑какой магии — и вот уже точность +‑ приемлемая. Камеры, в основном, стояли на месте, их иногда могли перенести куда‑нибудь или просто случайно сместить. Поэтому я мог позволить себе оооочень долгое интегрирование по времени :)
Так вот, есть мысли что подобный подход применим и тут, и высоковероятно, что ресурсов жрать оно будет меньше, чем нейросетка, даже в случае с монокулярной камерой. Фактически при движении дрона мы получаем новые ракурсы, и нам нужно просто узнать координаты нового местоположения в системе координат предыдущего (или нескольких), и просто интегрировать путь.
А ещё это довольно несложно (относительно) впихнуть в ASIC и производить по 50 000 штук в месяц.
Смотря сколько лент надо контролировать, сколько диодов на них и с какой частотой их переключать. Если их несколько тысяч, простые контроллеры могут не переварить.
Более чем. Делал протокол WS2812b руками на nopах, забил всю память STM32 Discovery. На таймерах/SPI получилось бы сильно проще и меньше.
Системный промпт «Отвечай на русском» без кавычек, Flash Attenuation вкл, пул потоков 16 (было 12, но вряд ли это влияет на результат), остальное по дефолту.
Скрытый текст
Хм, любопытненько.
Uncensored
Vanilla
Вполне себе оно засекает, что тут что-то не то.
Остальные
Но в целом рекомендации довольно интересные, неплохо протестировать на разных моделях. В частности, есть ли разница в применении этих методологий при работе с обычными и рассуждающими LLM, и что будет, если миксовать их с другими подходами, например, игрой с температурой.
А ещё интересно, есть ли аналогичные трюки для VLM. Например, подгружать дополнительно картинку с какой‑нибудь бессмыслицей, которая по факту улучшит выдачу.
А что мешает сделать микросервис, который на вход жрёт шрифт, а на выходе дает всю нужную инфу о его размерах и прочих ТТХ? В конце концов это можно сделать на бекенде с кешированием. В общем, может я опять перегибаю оверинжиниринг, но для меня подобные проблемы выглядят как‑то диковато.
В WPF для десктопа 2008 года всё это было из коробки. Там только рендеринг шрифтов в самом начале был размытый из‑за игонра хинтинга, но это быстро починили. Почему эти сверхтехнологии инопланетных цивилизаций дошли до веба в 2025 году, большая загадка. И это при том, что сейчас на WebKit делают буквально почти всё.
Ну имхо это уже организационная проблема, а не техническая. Работали бы нормально паддинги, что‑нибудь другое бы дизайнер забыл бы сделать.