15Гб это само по себе огромная проблема! Какой смысл для независимого разработчика в микро ядре для работы с которым нужно скачать монолитную комбинацию тулзов-библиотек на 15 ГБ, которые еще надо скомпилировать чтобы после этого просто написать Хелло-Ворд? Какова будет популярность такого "микро"-ядра при таком пороге для его использования, как вы это прогнозируете?
Компиляцию 15 Гб исходников для написания Hello, world делать не нужно. Внешний разработчик скачивает SDK для KasperksyOS и устанвливает его себе локально. Внутри есть адаптированный SDK Flutter для сборки Flutter приложений, а также бинарные библиотеки Flutter Engine, которые используются в рантайме для запуска Flutter приложений. Т.е. для внешнего разработчика процесс выглядит совсем не сложно, несколько шагов и вы получите запущенное в симуляторе приложение. Собираться будет только код самого приложения (Hello, world), все остальное уже бинарное из состава SDK.
Я думаю вы согласитесь что вряд ли можно гордиться не тривиальностью процесса.
Процесс сборки такого сложного продукта как операционная система по определению не может быть тривиальным. Но с точки зрения внутреннего разработчика (внешние разработчики пользуются уже бинарным SDK) локальная сборка выглядит не сложно: нужно склонировать корневовй репозиторий, выбрать конфигурацию и запустить под докером сборку одной командой, а вся магия происходит "под капотом".
Я формулирую это маленько по другому: они много лет варятся в собственном соку и никому не могут нормально объяснить что же они делают.
Они действительно "варятся в собственном соку" для того чтобы разрабочикам не нужно было отвлекаться от своих задач и вникать во все тонкости процесса построения (а их действительно хватает). Однако у нас неплохо налажено межкомандное взаимодействие, есть большая база знаний: когда есть желание и время, можно вникнуть во все детали, прийти к коллегам и они все расскажут и объяснят. Они открыты к идеям по улучшению процесса - это приветствуется, когда разрабортчик испытывает боль от какого-то процесса и знает как его улучшить делится своими идеями.
Да этот момент меня интересует, но я не могу знать как с этим моментом связаны агенты конвеера с кэшами при построении так как я не являюсь разработчиком вашего ядра поэтому не понятно зачем вы ссылаетесь на них в обсуждении вне кампании.
Наверное, я неправильно вас понял и увел обсуждение в особенности внутреннего построения операционной системы. Получается ответ на ваш изначальный вопрос выше: бинарные библиотеки входят в состав SDK и внешним разработчика собирать их из исходников не нужно.
Ну движение после долгой стагнации это уже хорошо.
А о какой стагнации сейчас речь?
Я понимаю, что они заложники сложившейся ситуации. К сожалению, смелости и силы сделать свое решение среди них пока не нашлось. Это конечно печально.
А свое это какое? Новые языки программирования и фреймворки рождаются и умирают с завидной регулряностью (обычно это называют изобретением велосипеда). Но те кто из них выжили доказали свое право на существование.
Слепое следование это сидеть постоянно на предлагаемых "внешних" решениях и просто зарабатывать на них деньги.
Как я уже писал выше, в случае KasperskyOS выбор какому решению следовать мы предоставляем пользователем, потому что KasperskyOS это платформа. Если говорить в целом о компании Kaspersky так она, как раз, представляет свои собственные решения на рынке. И изобретать свои "велосипеды" мы тоже любим - вот, например, взяли и написали "свой git" :) но, само сабой, не ради получения удовольствия от процесса, а отвечая потребностям разработчиков, поэтому он имеет определенные оригинальные преимущества по сравнению с git.
То позор, то молодцы - вас что-то не поймешь, но второй вариант мне нравится больше :)
Жаль, что Вы как представитель продукта КасперскийOS позволяете себе оскорбления используемые в качестве доказательства своей позиции.
Это было не доказательство: вы поделились своим видением позора, а я в ответ своим. Вы, видимо, примерили его на себя и оскорбились - предлагаю впредь не навешивать ярлыков и избегать неуместных оценочных суждений.
Мало ли кто какой технологии отдает предпочтение, а что теперь оскорблять их. Вот скажем может вас оскорбляют разработчики других подходов?
Так это же вроде бы вы вылили ведро помоев в сторону целого комьюнити разарботчиков Java, Swift и Dart, нет?
Ничего умного в слепом следовании умирающей технологии я не вижу. Вы схватили списанный со счетов продукт и играетесь.
Не совсем понтяно какой смысл вы вкладываете в "слепое следование" в данном случае - наша задча расширять экосистему операционной системы, поэтому мы стараемся предоставить разработчикам как можно больше знакомых и удобных технологий, а какой из них следовать это уже выбор пользователей. Что касается Flutter, ты мы не считаем его умирающей технологией, анализ рынка показывает обратное. Более того запрос на Flutter есть у нескольких наших крупных партнеров. Но в любом случае мы получили полезный для себя опыт портирования такого крупного и технологически сложного фреймворка, который не исчерпывается графической подсистемой и извлекли уроки как сделать так, чтобы портирование обходилось дешевле в будушем.
И кто станет разрабатывать графическую систему для чужую систему?
Графическая система обычно является частью самой операционной системы и писать ее сторонним разработчикам не нужно. Важно где проходит граница, набор устоявшихся протоколов и интерфейсов таких, например, как Wayland. А вот разработчики молодого кроссплатформенного фреймворка могут быть заинтересованы в предоставлении из коробки как можно большего количества поддерживаемых платформ.
Который претерпел уже вторую революцию виртуальной машины и постепенно вырастает Flutter из новой системы Fucsia? Это просто отличный пример умирающего легаси.
Flutter является родным графическим фреймворком для Fuchsia, которую Google планировал как замену Android, но, как мы видим, этого не происходит, а Android живет себе спокойно дальше и развивается. То что виртуальная машина претерпевает революционные изменения также говорит о ее развитии, а не отмирании.
Возможно. Просто ряд фактов вроде увольнение команды разработчиков Flutter и Dart и создание свободных форков вроде Flock, а так же ощущение, что Google выкидывает на мороз технологию сложилось.
Возможно, Google хочет перераспределить ресурсы на поддержку Kotlin/Compose Multiplatform - очень похожие по своей сути технолгии с Dart/Flutter. А уход Flock в свободное от политик Google комьюнити вполне может дать ему новый импульс развития.
Я все еще скептический отношусь к выбору Java, Swift или Dart. А разработчиков готовых прыгнуть под новый подход ради парочки бесплатных библиотек у меня особое мнение.
Для того чтобы мнение имело хоть какой-то вес оно должно подкрепляться аргуменами и реальным опытом, иначе это просто бессмысленная болтовня очередного диванного эксперта.
Решили в очередной раз на переиспользовать чужой опыт ценой вкатывания в временный инструментарии и изображать с серьезными лицами целую отрасль, а еще участвовать в crossconf.com выглядит для меня позором.
KasperskyOS это целая отрасль без малейших преувеличений, а портирование на нее Flutter, это интересный, на наш взгляд, опыт, которым мы делимся с сообществом. И, раз уж вы тут взялись ярлыки навешивать, то для меня, например, позор это сидеть на дивание и настрачивать малограмотные комментарии по вопросам в которых мало что смыслишь :)
С кем не говорю, так одна песня. Сложно (читай нет специалистов), дорого (никто не хочет платить) и не примут (все молятся на идолов вроде Google).
Жаль что из общения с умными людьми не извлекли для себя ничего :) KasperskyOS это как раз вывод на рынок очень сложного для продаж продукта, зато своего и полностью оригинального. А раз есть платформа никто не мешает разрабатывать под нее собственный графический фреймфорк или портировать существующий, как например, Flutter.
Уже проходили несколько раз и так ничему не научились? Такая же история была с центральным репозиторием Java где миллионы библиотек
А что не так с Maven Central и Java или JS? Живее всех живых и вполне успешно развиваются, будучи стандартами в некоторых отраслях.
Похоронено все давно.
Вон оно как оказывается.
Думаю, что участь Dart примерно такая же.
Понятно, ну вы прямо Настродамус от IT :)
Ага, да вы еще вспомните "Java runs on more than 2billiondevices...".
Тут есть логика? Flutter SDK является частью SDK KasperskyOS получается?
Да, адаптированный Flutter SDK входит в SDK KasperskyOS, чтобы разработчики могли собирать Flutter приложения под KasperskyOS. Логика здесь вроде бы самая прямолинейная :)
Другие вопросы нужны? Будете объяснять?
Спрашивайте - объясню, конечно. Только вежливо, без истерик.
Так и хочется спросить: при построении чего?
Операционной системы KasperskyOS и ее продуктов из исходных кодов. И процесс этот совсем не тривиальный, им занимается отдельная команда в инфраструктуре с многолетней экспертизой в этой области.
Что можно строить, а для начала разрабатывать, на ваших агентах конвеера?
Внешним разработчикам ничего, конвееры находятся внутри компании для разработчиков самой операционной системы.
Такое ощущение складывается, от вашего комментария, что разработка вас не интересует, а с ней отладка, удобство навигации, конфигурации исходного кода проекта,
Статья была не об инструментах разработчиков KaseprskyOS. А из каких исходных вы делаете выводы что с этим есть какие то проблемы? :) У нас прекрасная команда тулинга, которая обеспеичвает разработчиков всем необходимым. С помощью адаптированного gdb можно полноценно отлаживаться, есть компонент для отслеживания сбоев и символизации бэктрейсов, есть продвинутый логгер, мощный эмулятор на основе QEMU, а также плагин для VS Code, для удобной навигации по коду. Просто это все не имеет прямого отношения к материалу статьи, но если интересно можно пройти по ссылкам, сходить на курсы или поучаствовать в других мероприятиях для разработчиков.
главное что есть агенты конвеера с кэшами при построении
Для кого главное? Вы сами начали говорить про "бинарные библиотеки", подумал может вас именно этот момент заинтересовал.
А вы знаете что любые такие новомодные усовершенствования билд-системы обычно не совместимы с функциями отладки проекта, то есть просто делают нормальную отладку проекта невозможной?
Когда усовершенстования делаются профессионально и с четкой целью обычно они работают хорошо и не вызывают проблемм, которых не должны создавать.
Кстати, я думаю очень будет интересно потенциальным пользователям KasperskyOS, какие функции доступны проекту приложения с этим голым микроядром
Микроядро не голое, вокруг него вполне зрелая экосистема, теперь вот еще и Flutter. А что такое проект приложения? Если имеется в виду пользовательское приложение, то ему будут доступны те функции, которые вы как разработчик в него заложите. Со стороны же KasperskyOS вы получите стандартный набор функционала, который предоставляет любая зрелая операционная система.
Ответьте, если вы действительно хотите конструктивного обсуждения, а не пишите для того чтобы подавить неудобное мнение.
Отвечаю :) Ну "мнение" это слишком громко сказано, для того чтобы составить мнение нужно иметь хотя бы минимальные знания из предметной области (а лучше не минимальные), которую собрались конструктивно обсуждать, а то у вас пока получается что-то из серии "я ничего не знаю о KasperskyOS, но она мне не нравится" :)
Можно, но форк придется поддерживать в актальном состоянии, поэтому большого смысла в этом нет. Есть определенные надежды на Flock (форк от Flutter), но, насколько мне известно, изменения от Huawei для поддержки HarmonyOS до сих пор не влиты.
Ну назвать Flutter поделкой, а уже тем более подзаброшенной у меня бы язык не повернулся :) Вы бы, прежде чем кидаться такими сомнительными утверждениями, посетили бы, например, https://crossconf.com, чтобы понимать чем сейчас живут разработчики мобильных приложений. И увидели бы как они благодарны Flutter когда можно писать чистый код на современном языке высокого уровня, таком как Dart, который прямо заточен под UI. Минимальный порог входа - прочитал туториал, и пошел писать полноценное приложение, когда для тебя уже написали 100500 отличных готовых библиотек, которые ты добавляешь себе в проект одной строчкой, а потом нажимаешь пару конопок в удобном IDE и видишь как твое приложение уже раскатано на Android и iOS и ведет себя одинаково. Оценка, конечно, же прводилась, но вывести на рынок удачный графический фреймворк, который примет сообщество и под него начнут активно писать это задача мягко говоря ресурсозатратная с туманными перспективами выхода на рынок и явно не на один год. А в контексте идей, заложенных KasperskyOS, не имеет особого смысла, т.к. напрямую не решает архитектурных вопросов безопасности.
1) В данный момент, к сожалению, нельзя. Мы были бы рады влить наши изменения в основную ветку Flutter и проводим анализ как это можно сделать, но есть определенные риски что патч не будет принят по политическим соображениям. 2) Да, но минимальные: отключили сбор аналитики, попытки получать хэши из git-репозитория и добавили расширили поддержку флага --offline для нескольких комманд.
Графическая подсистема в ядро не входит. DirectX это проприетарная библиотека Microsoft и не распространена за пределами Windows. Если говорить о стандартах, то скорее уместнее упоминать OpenGL или Vulkan. Wayland это открытый протокол, расширяемый благодаря своей гибкой архитектуре. Широко распространен в Nix системах, в том числе коммерчески успешных. Более того интерфесы Wayland описываются в xml-файлах и биндинги могут быть сгенерированы при желании под любой ЯП (т.е. не привязаны к C/C++).
Сбавьте тон для начала, зачем же сразу всех записывать в круглые идиоты? :) Тем более, судя по посланию, вы еще слабовато разобрались в матчасти, которую кинулись столь яростно критиковать. О каком проекте в 150 строк идет речь? Если речь о приложении под KasperskyOS, то для этого не нужно качать 15 Гб исходников: в статье вполне внятно написано, что будет достаточно установить SDK. О скачивании всего интернета тоже нигде речи не было, непонятно откуда взялись такие фантазии. Но все исходники, из которых строится операционная система, естественно живут в наших внутренних репозиториях и находятся под нашим полным контролем. Любой внешний код, который туда попадает, предварительно проходит через специальную процедуру и отдел ИБ. А вот как устроены наши кэши при построении на агентах конвеера, как принимается решение нужно ли пересобирать конкретный бинарный артефакт это тема для отдельной статьи и не относится к Flutter.
В микроядре KasperskyOS около 100 тысяч строк. Полное дерево исходников Flutter Engine занимает около 15 ГБ. Связи между этими цифрами нет, потому что Flutter не входит ни в одно ядро операционной системы, а уж тем более в микроядро.
Почему вы так полагаете? Человек утверждает что версия с шаблоном никогда не вызывается, я наоборот привел примеры когда это происходит. Что снова не так? :)
Когда примеры кода в текст вставляют в виде картинок -- это, с моей точки зрения, прямое неуважение к читателю.
Ну это же были не те примеры, которые есть смысл собирать и что-то менять в них. Это скорее иллюстрация описываемой проблемы. Реализация и примеры использования приводятся в конце статьи как ссылки - там можно "пощупать" реальный код.
Что и было сделано в мягкой форме.
Страшно представить как вы это делаете в жесткой форме :) бедный монитор.
За обилие смайлов в ответных комментариях еще одна порция оных.
Смайлами точно не хотел оскорбить, наоборот даже. И вы это... не изойдите совсем на эту субстанцию, оставьте немного для других авторов :)
Еще одно доказательство для тех, кто сомневается в адекватности подобной системы отбора.
Так вы еще и HR специалист оказывается, а как же нужно делать, по вашему мнению?
Компиляцию 15 Гб исходников для написания Hello, world делать не нужно. Внешний разработчик скачивает SDK для KasperksyOS и устанвливает его себе локально. Внутри есть адаптированный SDK Flutter для сборки Flutter приложений, а также бинарные библиотеки Flutter Engine, которые используются в рантайме для запуска Flutter приложений. Т.е. для внешнего разработчика процесс выглядит совсем не сложно, несколько шагов и вы получите запущенное в симуляторе приложение. Собираться будет только код самого приложения (Hello, world), все остальное уже бинарное из состава SDK.
Процесс сборки такого сложного продукта как операционная система по определению не может быть тривиальным. Но с точки зрения внутреннего разработчика (внешние разработчики пользуются уже бинарным SDK) локальная сборка выглядит не сложно: нужно склонировать корневовй репозиторий, выбрать конфигурацию и запустить под докером сборку одной командой, а вся магия происходит "под капотом".
Они действительно "варятся в собственном соку" для того чтобы разрабочикам не нужно было отвлекаться от своих задач и вникать во все тонкости процесса построения (а их действительно хватает). Однако у нас неплохо налажено межкомандное взаимодействие, есть большая база знаний: когда есть желание и время, можно вникнуть во все детали, прийти к коллегам и они все расскажут и объяснят. Они открыты к идеям по улучшению процесса - это приветствуется, когда разрабортчик испытывает боль от какого-то процесса и знает как его улучшить делится своими идеями.
Наверное, я неправильно вас понял и увел обсуждение в особенности внутреннего построения операционной системы. Получается ответ на ваш изначальный вопрос выше: бинарные библиотеки входят в состав SDK и внешним разработчика собирать их из исходников не нужно.
А о какой стагнации сейчас речь?
А свое это какое? Новые языки программирования и фреймворки рождаются и умирают с завидной регулряностью (обычно это называют изобретением велосипеда). Но те кто из них выжили доказали свое право на существование.
Как я уже писал выше, в случае KasperskyOS выбор какому решению следовать мы предоставляем пользователем, потому что KasperskyOS это платформа.
Если говорить в целом о компании Kaspersky так она, как раз, представляет свои собственные решения на рынке.
И изобретать свои "велосипеды" мы тоже любим - вот, например, взяли и написали "свой git" :) но, само сабой, не ради получения удовольствия от процесса, а отвечая потребностям разработчиков, поэтому он имеет определенные оригинальные преимущества по сравнению с git.
Планов серьезно вкладываться во фреймворк "забугорного дяди" в данный момент нет, в приоритете развите самой платформы.
Рад что мои ответы оказались полезными! По техническим вопросам отпишусь чуть позже.
Старались минимизировать вмешательство - отрезали только то что явно мешает :)
То позор, то молодцы - вас что-то не поймешь, но второй вариант мне нравится больше :)
Это было не доказательство: вы поделились своим видением позора, а я в ответ своим. Вы, видимо, примерили его на себя и оскорбились - предлагаю впредь не навешивать ярлыков и избегать неуместных оценочных суждений.
Так это же вроде бы вы вылили ведро помоев в сторону целого комьюнити разарботчиков Java, Swift и Dart, нет?
Не совсем понтяно какой смысл вы вкладываете в "слепое следование" в данном случае - наша задча расширять экосистему операционной системы, поэтому мы стараемся предоставить разработчикам как можно больше знакомых и удобных технологий, а какой из них следовать это уже выбор пользователей.
Что касается Flutter, ты мы не считаем его умирающей технологией, анализ рынка показывает обратное. Более того запрос на Flutter есть у нескольких наших крупных партнеров.
Но в любом случае мы получили полезный для себя опыт портирования такого крупного и технологически сложного фреймворка, который не исчерпывается графической подсистемой и извлекли уроки как сделать так, чтобы портирование обходилось дешевле в будушем.
Графическая система обычно является частью самой операционной системы и писать ее сторонним разработчикам не нужно. Важно где проходит граница, набор устоявшихся протоколов и интерфейсов таких, например, как Wayland. А вот разработчики молодого кроссплатформенного фреймворка могут быть заинтересованы в предоставлении из коробки как можно большего количества поддерживаемых платформ.
Flutter является родным графическим фреймворком для Fuchsia, которую Google планировал как замену Android, но, как мы видим, этого не происходит, а Android живет себе спокойно дальше и развивается. То что виртуальная машина претерпевает революционные изменения также говорит о ее развитии, а не отмирании.
Оценку по React Native проводили, выглядит чуть менее затратным чем Flutter:
https://reactnative.dev/docs/out-of-tree-platforms
https://github.com/react-native-skia/react-native-skia
Тоже хотели бы взять, в планах есть.
Возможно, Google хочет перераспределить ресурсы на поддержку Kotlin/Compose Multiplatform - очень похожие по своей сути технолгии с Dart/Flutter.
А уход Flock в свободное от политик Google комьюнити вполне может дать ему новый импульс развития.
Для того чтобы мнение имело хоть какой-то вес оно должно подкрепляться аргуменами и реальным опытом, иначе это просто бессмысленная болтовня очередного диванного эксперта.
KasperskyOS это целая отрасль без малейших преувеличений, а портирование на нее Flutter, это интересный, на наш взгляд, опыт, которым мы делимся с сообществом. И, раз уж вы тут взялись ярлыки навешивать, то для меня, например, позор это сидеть на дивание и настрачивать малограмотные комментарии по вопросам в которых мало что смыслишь :)
Жаль что из общения с умными людьми не извлекли для себя ничего :)
KasperskyOS это как раз вывод на рынок очень сложного для продаж продукта, зато своего и полностью оригинального. А раз есть платформа никто не мешает разрабатывать под нее собственный графический фреймфорк или портировать существующий, как например, Flutter.
А что не так с Maven Central и Java или JS? Живее всех живых и вполне успешно развиваются, будучи стандартами в некоторых отраслях.
Вон оно как оказывается.
Понятно, ну вы прямо Настродамус от IT :)
Ага, Android вспомнил.
Да, адаптированный Flutter SDK входит в SDK KasperskyOS, чтобы разработчики могли собирать Flutter приложения под KasperskyOS. Логика здесь вроде бы самая прямолинейная :)
Спрашивайте - объясню, конечно. Только вежливо, без истерик.
Операционной системы KasperskyOS и ее продуктов из исходных кодов. И процесс этот совсем не тривиальный, им занимается отдельная команда в инфраструктуре с многолетней экспертизой в этой области.
Внешним разработчикам ничего, конвееры находятся внутри компании для разработчиков самой операционной системы.
Статья была не об инструментах разработчиков KaseprskyOS. А из каких исходных вы делаете выводы что с этим есть какие то проблемы? :) У нас прекрасная команда тулинга, которая обеспеичвает разработчиков всем необходимым. С помощью адаптированного gdb можно полноценно отлаживаться, есть компонент для отслеживания сбоев и символизации бэктрейсов, есть продвинутый логгер, мощный эмулятор на основе QEMU, а также плагин для VS Code, для удобной навигации по коду. Просто это все не имеет прямого отношения к материалу статьи, но если интересно можно пройти по ссылкам, сходить на курсы или поучаствовать в других мероприятиях для разработчиков.
Для кого главное? Вы сами начали говорить про "бинарные библиотеки", подумал может вас именно этот момент заинтересовал.
Когда усовершенстования делаются профессионально и с четкой целью обычно они работают хорошо и не вызывают проблемм, которых не должны создавать.
Микроядро не голое, вокруг него вполне зрелая экосистема, теперь вот еще и Flutter. А что такое проект приложения? Если имеется в виду пользовательское приложение, то ему будут доступны те функции, которые вы как разработчик в него заложите. Со стороны же KasperskyOS вы получите стандартный набор функционала, который предоставляет любая зрелая операционная система.
Отвечаю :) Ну "мнение" это слишком громко сказано, для того чтобы составить мнение нужно иметь хотя бы минимальные знания из предметной области (а лучше не минимальные), которую собрались конструктивно обсуждать, а то у вас пока получается что-то из серии "я ничего не знаю о KasperskyOS, но она мне не нравится" :)
Можно, но форк придется поддерживать в актальном состоянии, поэтому большого смысла в этом нет. Есть определенные надежды на Flock (форк от Flutter), но, насколько мне известно, изменения от Huawei для поддержки HarmonyOS до сих пор не влиты.
Поправил ссылку.
Ну назвать Flutter поделкой, а уже тем более подзаброшенной у меня бы язык не повернулся :) Вы бы, прежде чем кидаться такими сомнительными утверждениями, посетили бы, например, https://crossconf.com, чтобы понимать чем сейчас живут разработчики мобильных приложений. И увидели бы как они благодарны Flutter когда можно писать чистый код на современном языке высокого уровня, таком как Dart, который прямо заточен под UI. Минимальный порог входа - прочитал туториал, и пошел писать полноценное приложение, когда для тебя уже написали 100500 отличных готовых библиотек, которые ты добавляешь себе в проект одной строчкой, а потом нажимаешь пару конопок в удобном IDE и видишь как твое приложение уже раскатано на Android и iOS и ведет себя одинаково.
Оценка, конечно, же прводилась, но вывести на рынок удачный графический фреймворк, который примет сообщество и под него начнут активно писать это задача мягко говоря ресурсозатратная с туманными перспективами выхода на рынок и явно не на один год. А в контексте идей, заложенных KasperskyOS, не имеет особого смысла, т.к. напрямую не решает архитектурных вопросов безопасности.
Репозиторий Flutter/Dart библиотек: https://pub.dev/ - это около 55 тысяч кроссплатформенных пакетов на все случаи жизни (https://verygood.ventures/blog/pub-in-focus-the-most-critical-dart-flutter-packages-of-2024).
Вот некая статистика по количеству пользователей фреймворка:
https://www.dhiwise.com/post/flutter-builder-break-the-app-development-trends
"Flutter has over 2 million users and is still growing."
1) В данный момент, к сожалению, нельзя. Мы были бы рады влить наши изменения в основную ветку Flutter и проводим анализ как это можно сделать, но есть определенные риски что патч не будет принят по политическим соображениям.
2) Да, но минимальные: отключили сбор аналитики, попытки получать хэши из git-репозитория и добавили расширили поддержку флага --offline для нескольких комманд.
Графическая подсистема в ядро не входит.
DirectX это проприетарная библиотека Microsoft и не распространена за пределами Windows. Если говорить о стандартах, то скорее уместнее упоминать OpenGL или Vulkan.
Wayland это открытый протокол, расширяемый благодаря своей гибкой архитектуре. Широко распространен в Nix системах, в том числе коммерчески успешных. Более того интерфесы Wayland описываются в xml-файлах и биндинги могут быть сгенерированы при желании под любой ЯП (т.е. не привязаны к C/C++).
Сбавьте тон для начала, зачем же сразу всех записывать в круглые идиоты? :) Тем более, судя по посланию, вы еще слабовато разобрались в матчасти, которую кинулись столь яростно критиковать.
О каком проекте в 150 строк идет речь? Если речь о приложении под KasperskyOS, то для этого не нужно качать 15 Гб исходников: в статье вполне внятно написано, что будет достаточно установить SDK.
О скачивании всего интернета тоже нигде речи не было, непонятно откуда взялись такие фантазии.
Но все исходники, из которых строится операционная система, естественно живут в наших внутренних репозиториях и находятся под нашим полным контролем. Любой внешний код, который туда попадает, предварительно проходит через специальную процедуру и отдел ИБ.
А вот как устроены наши кэши при построении на агентах конвеера, как принимается решение нужно ли пересобирать конкретный бинарный артефакт это тема для отдельной статьи и не относится к Flutter.
Там это где? В микроядро не входят ни драйвера ни toolchain.
В микроядре KasperskyOS около 100 тысяч строк.
Полное дерево исходников Flutter Engine занимает около 15 ГБ.
Связи между этими цифрами нет, потому что Flutter не входит ни в одно ядро операционной системы, а уж тем более в микроядро.
Почему вы так полагаете? Человек утверждает что версия с шаблоном никогда не вызывается, я наоборот привел примеры когда это происходит. Что снова не так? :)
Ну это же были не те примеры, которые есть смысл собирать и что-то менять в них. Это скорее иллюстрация описываемой проблемы. Реализация и примеры использования приводятся в конце статьи как ссылки - там можно "пощупать" реальный код.
Страшно представить как вы это делаете в жесткой форме :) бедный монитор.
Смайлами точно не хотел оскорбить, наоборот даже. И вы это... не изойдите совсем на эту субстанцию, оставьте немного для других авторов :)
Так вы еще и HR специалист оказывается, а как же нужно делать, по вашему мнению?
Если нужно возвращать, например, int нужно пользоваться версией view с шаблоном:`auto d = v.view<int>([](int i) -> int {`