Comments 30
Виртуальная машина загружается за 2-3 секунды (это быстрее, чем Docker, потому что используется минимальный initramfs).
Что-то я ни разу не замечал, чтобы контейнеры в докере стартовали дольше секунды (за исключением случаев, когда надо было сначала скачать образ, разумеется).
Единственное ограничение — Docker. Внутри виртуальной машины нельзя запустить вложенную виртуализацию (nested virtualization). Docker работает, но только в режиме rootless (без KVM).
Причём тут вообще вложенная виртуализация, и как связаны rootless режим докера с наличием KVM?
У меня ощущение что этот текст написан в GPT и немного нагаллюцинирован
У меня есть ощущение, что там не "немного", и GPT не должен галлюционировать прям настолько сам по себе. Его еще направлял кто-то со своим интересным полетом.
Вы проснулись только сегодня? Сейчас почти весь Хабр-контент на ИИ сгенерирован, это стало нормой, в статье хотя бы более менее глубокий разбор есть
В статье продемонстрирован ряд заблуждений, по моему мнению, не характерных для LLM, но характерных для людей. Собственно мой комментарий был о мясном источнике галлюцинаций, а не о использовании/неиспользовании LLM при создании. Сожалею, если не смог написать эти два предложения достаточно понятным языком.
Да, всё верно, правильные части написаны при помощи LLM, а не правильные мной самим (мясная природа галюцинаций), на то я и человек, проверяю заблуждения и если это действительно мои заблуждения - признаю и исправляю. Поэтому и предложил обсудить в комментариях. В течении суток всё проанализирую. А за исправления всех благодарю!
Раздел "1. Flutter, OpenGL и 50 лет технического долга" вообще не содержит полезную информацию. Он похож на одну сплошную галлюцинацию. Если он вас не смущал до публикации, то в этой области вы не ориентируетесь вообще.
Я боюсь, что суток никак не хватит, чтобы усвоить базу достаточную для того, чтобы не допускать путаницы в терминологии и объяснениях.
Просто не нужно писать, особенно так подробно, про такие сложные области без понимания. Ну либо писать в формате "я тут пытаюсь разобраться, помогите".
Автор написал огромную статью, единственную в своем роде попытку объяснения стратегии Гугла и влияния Флаттера на эту стратегию, а вы отправляете его изучать базу??? Возможно в каких-то моментах он допустил неточности, но это технические моменты, такие технические неточности можно найти в каждой статье на хабре и не только на хабре, а общий вектор статьи они особо не меняют. Он имеет полное право ответить вам в стиле "Я художник - я так вижу.", но отвечает лояльно, выражает готовность исправить материал в течении суток.
Не логичнее ли вам самому изучить базу социального общения между людьми и не выставлять себя всезнающим дядей?
Извините, но там не "неточности", а информация, которая противоречит реальности чуть ли не до противоположности. От нее вреда намного больше чем пользы, так как люди в теме не разбирающиеся могут на нее опереться.
Этот текст позиционируется как информационный, а не как развлекательный. Чтобы относиться к нему как к "видению художника", его нужно позиционировать соответственно.
Действительно, существуют социумы и культуры, в которых поддакивание и взаимное социальное одобрение имеют приоритет перед признанием объективных проблем. Я, скажем, не считаю этот подход к построению коммуникации единственно верным.
Вас никто не просит поддакивать и социально одобрять, вы можете указать на неточности в предметной области, а не переходить на личности и не расставлять приоритеты.
А сейчас, вы из огромного текста выдернули узкий контекст, в котором, возможно, разбираетесь лучше и из него делаете вывод типа "не шарит в этом = не шарит ни в чем", "весь раздел - галлюцинация, автора отправить изучать базу".
Я, скажем, не считаю этот подход к построению коммуникации единственно верным.
То, как вы считаете - не является единственно верным.
Извините, но там не "неточности", а информация, которая противоречит реальности чуть ли не до противоположности. От нее вреда намного больше чем пользы
А реклама колбасы и шоколада не противоречит? А сможете повлиять? Маркетологи будут слушать вашу версию вреда и пользы?
По моему проблемы Flutter как раз начались когда они перешли на Metal и внезапно выяснилось что им в skia на тот моментдоступна только рантайм компиляция metal shareds, а на OpenGL все отлично работало.
В результате они запилили свой движок, про качество его идут дискуссии, но skia уже тоже подтянулась.
Вообще я думаю что Flutter нужен был как "план Б" во время судебных тяжб с Oracle по поводу реализации Java.
про качество его идут дискуссии
я бы сказал, речь даже не о качестве, есть еще один момент, который я не упомянул - зависит от того какое приложение вы делаете, в некоторых редких случаях лучше по производительности подходит именно skia, но по своей структуре "для бизнес приложух" импеллер лучше и выигрывает
А можно выбирать? Я думал они уже просто все перешли Impeller
Я помню дискуссии в Twitter где-то в мае 2025 - что мол skia тоже уже сделали компиляцию шейдеров и никаких лагов и там не было бы, зачем мы ввалили столько сил в свой движок, который порой и тормознее и памяти ест больше, а ключевой, вдохновивший проект разработчик просто бросил его.
Но тут конечно надо делать поправку что это Twitter и там любят передергивать ситуацию
Да, можно, по дефолту сейчас Impeller, и именно под него команда Flutter оптимизирует стек. А в задачах примерно так:
Impeller:
Лучше для типичных Flutter-приложений:
бизнес-UI,
сложные layout’ы,
анимации,
скроллы.
Предсказуемый frame time.
Меньше «внезапных» лагов.
Skia:
В некоторых нишевых кейсах реально быстрее:
кастомная 2D-графика,
нетипичные эффекты,
плотная работа с canvas.
Но требует аккуратной настройки и понимания
То есть сейчас это не «Impeller всегда быстрее», а: Impeller выигрывает по UX-стабильности, Skia иногда по сырой пропускной способности. В последних версиях Flutter Impeller — основной рендерер по умолчанию, но Skia жива и применима и доступна по флагу при желании, ее хотели убрать, но оставили и правильно сделали. На мой взгляд, надо оставить оба рендера + Skia тоже подтянулась.
Небольшая неточность с React Native. Моста уже нет, но Skia при желании уже есть. Причём на одном экране можно использовать и рендеринг в Skia и нативные контролы OS, получив нативное поведение (например, критикуемый во Flutter скроллинг).
C ABI означает отсутствие type safety. Вызов glUniform4f(location, r, g, b, a) — если перепутал порядок аргументов, получаешь random pixels. Компилятор не поможет, потому что все аргументы имеют тип float. В Rust или Dart это была бы ошибка компиляции.
location – GLint, остальные флоты. Что по-вашему происходит в rust/dart – отдельный тип для красного цвета, отдельный для зеленого?
Каждый вызов glDrawArrays() — это синхронный вызов драйвера.
Синхронный вызов, который синхронно только сохраняет команду в очередь.
Это невозможно исправить в OpenGL, потому что спецификация не позволяет прекомпилировать шейдеры заранее.
Шейдеры вообще можно один раз на старте приложения скомпилировать. То, что конкретная реализация динамически собирает шейдеры, чтобы заинлайнить параметры виджета не относится к тому, что шейдер нельзя скомпилировать заранее, а к тому, что исходного кода шейдера заранее не существует в конкретной реализации skia.
Дальше читать пока духу не хватило, нужно немного собраться с силами.
location – GLint, остальные флоты. Что по-вашему происходит в rust/dart – отдельный тип для красного цвета, отдельный для зеленого?
речь была не о «семантических типах цвета», а о позиционной небезопасности immediate-mode API с однотипными аргументами:
Ни в Rust, ни в Dart никто не вводит отдельные типы Red, Green, Blue для raw OpenGL.
Происходит одно из двух:
Тонкий unsafe binding (как
gl-rs):unsafe { gl::Uniform4f(location, r, g, b, a); }→ никакой дополнительной type safety нет.
Safe wrapper уровня движка:
set_uniform(location, Color { r, g, b, a });или
shader.setColor(Color(r, g, b, a));
И вот здесь типизация появляется не на уровне ABI, а на уровне API-дизайна.
Синхронный вызов, который синхронно только сохраняет команду в очередь.
согласен, сам вызов не блокирует GPU напрямую. Под «синхронностью» я имел в виду runtime-валидацию и работу драйвера в момент draw-call, а не буквальное ожидание выполнения на GPU.
Шейдеры вообще можно один раз на старте приложения скомпилировать. То, что конкретная реализация динамически собирает шейдеры, чтобы заинлайнить параметры виджета не относится к тому, что шейдер нельзя скомпилировать заранее, а к тому, что исходного кода шейдера заранее не существует в конкретной реализации skia.
Про шейдеры: да, их можно компилировать заранее, и проблема не в невозможности как таковой, а в отсутствии надёжного и переносимого механизма предкомпиляции и кэширования на разных драйверах. Здесь вы правы.
Я вижу, что вы убрали многие ложные подробности из статьи, за что вам спасибо.
Однако, там их осталось предостаточно, а отвечая на мой комментарий, вы судя по всему, так и не вникли в суть замечаний. Никакой из ваших примеров не защищает от неправильного порядка 4 флотов. Неважно, передавать их напрямую в вызов функции или в конструктор Color.
Хорошо, что вы убрали упоминание ABI из статьи. Вулкан, как и OpenGl предоставляет такой же C апи, так как это часть драйвера и разработчик прикладного по на это влиять не может.
В статье по-прежнему упоминаются wgpu и webgpu. Первый – это библиотека на расте и к теме, судя по всему, отношения вообще не имеет. Второе – реализация современного графического апи в браузере.
Сейчас флаттер для веба до сих пор использует skia, если верить беглому поиску.
Impeller не отказывается от "парадигмы opengl", пруф –
OpenGL ES Development Setup.
"Механизм предкомпиляции" – это чисто прикладная реализация, она от апи не зависит.
Странная статья. Странные "прогнозы"
первый Tensor с интегрированным модемом появится в Pixel 10 (2027 год)
Pixel 10 уже полгода как есть. И в нем модем... Самсунговский Exynos 5400.
eSIM (embedded SIM) — это виртуальная SIM-карта, которая программируется через интернет. Вам не нужна физическая карточка. Вы скачиваете профиль оператора и активируете его
И как ЭТО (eSIM) поможет реализации модема? С учетом того, что eSIM это по факту замена SIM, а та, в свою очередь, просто хранит ключи -а значит, необходимо реализовать всю ту же работу радиотракта что и для обычной SIM - поэтому eSIM вообще никак не повлияет на ситуацию.
В общем, странные утверждения и предположения.
Из какого года вообще статья? Из 2022? Потому, что если смотреть на позиции сегодняшнего дня, то можно практически быть уверенными, что Google "прикопала" проект своего модема и перебросит все усилия на NPU в новых процессорах, оставив модем на далекое-далекое "потом".
Я объяснил это себе так что статья написана ИИ
Pixel 10 (2027 год)
Да, это опечатка, имелось ввиду 12
Из какого года вообще статья? Из 2022? Потому, что если смотреть на позиции сегодняшнего дня, то можно практически быть уверенными, что Google "прикопала" проект своего модема
С этим не соглашусь, для пользователей пикселей всё актуально, а андроид до этого года испытывали на пикселях
Прекрасная статья, спасибо! Очень плотно по информации и очень вдохновляюще. Появляется какая-то симпатия к гуглу и его инженерам через близость и сложность задач по обеспечению совместимости и трансформации нагорячую, ну и конечно, из-за сумасшедшего масштаба (по сути, вся планета).
Можно два тупых вопроса?
Почему приложение камеры в телефоне в рамках модели ухудшается с каждым обновлением? Наблюдал на мейзу, мотороле и ванплюсе по мере смены телефона. Типа ядро обновляется, и вендору просто лень писать новые драйверы на уровне старой функциональности?
Как вы оцениваете будущую динамику деятельности сообществ по подготовке неоффициальных прошивок, особенно для старой техники? Я так понимаю, для новых изделий FIDL облегчает переносы драйверов плюс сокращается количество оболочек плюс легче вырезать сервисы гугла из-за открытости платформы. А для старых устройств нас ждет ренессанс реинкарнаций или ничего особо не изменится, потому что для старых компонентов не будут переписывать драйвера, как минимум, нативно под фуксию?
плюс легче вырезать сервисы гугла из-за открытости платформы
Их вообще не надо вырезать. Ставите открытую прошивку, переносите дравера - всё работает. Примерно как сейчас с андроидом, где можно взять чистую сборку AOSP нужной версии с гугловского билд-сервиса, залить, и все работает (почти всё - сломается secure boot, плюс те же улучшайзеры для камеры, например, сидят внутри родных приложений, и прибиты гвоздями к родной прошивке).
В конце 2025 года техноблоги взорвались инсайдами: Google планирует выпустить премиальный ноутбук под брендом Pixel. Но работать он будет не на ChromeOS, как привычные «Хромбуки», и не на Windows.
Кодовое имя инициативы — Aluminium. Что попалось сразу. Новость не обошла стороной и хабр.
Суть проекта как обычно для Google проста и жестока: ChromeOS как отдельная операционная система должна умереть. Будущее — это Android, который научился быть десктопом.
Очередной "прорывной" проект Гугла, который похоронят через несколько лет ради очередного другого "прорывного" проекта. Надо быть очень фанатичным поклонником Гугла, что-бы покупать такие "премиальные ноутбуки".
Большое спасибо за описание механизма прав в Zircon! Доказал их корректность и поигрался с ними в Isabelle/HOL, далее можно будет уже лепить реальный код для эмулятора .
Патенты это такое дикое зло, с сомнительными преимуществами и огромными очевидными недостатками, что я не понимаю почему мы не говорим об этом постоянно.
"разумные условия" — это 5-7% от стоимости устройства.
А посему бы не сделать дешевые устройства, подключаемые по USB? В телефоне предусмотреть отдельный порт для них, в автомобилях вообще можно было бы расположить на крыше, где радиосигнал лучше ловится.
Уточню по seL4.
Микроядро seL4 было верифицировано в несколько этапов-
2009 год — была опубликована первая значимая работа по формальной верификации seL4. В этой работе была доказана функциональная корректность реализации ядра относительно абстрактной спецификации, а также показано отсутствие определенных классов ошибок (например, нарушение безопасности доступа).
Последующие годы — верификация продолжалась и расширялась. Были добавлены:
Доказательство безопасности (security proof) — гарантии целостности и конфиденциальности.
Доказательство отсутствия зависимостей от времени выполнения (proof of termination) и других свойств.
2014 год — была завершена комплексная верификация.
---
Flutter, Fuchsia, Zircon, ChromeOS, Aluminium OS, WGPU, Tensor Modem, RIL, SeL4, FIDL будущее Андроида и других ОС №2