Комментарии 36
Микроядро компактно и не растет со временем (в отличие от Linux, Android, Windows). Сейчас в Linux ~ 27 миллионов строк кода, в KasperskyOS ~ 100 тысяч.
Полное дерево исходников состоит из нескольких десятков репозиториев (включая сторонние) и занимает около 15 ГБ. Только после этого инструмент можно начинать строить.
Чувствую что меня где то накалывают но не понимаю где.
Там же кроме кода ядра еще toolchain, различные библиотеки, драйвера, да много чего. Размер кода ядра идет на мегабайты.
Ну да! Чтобы скомпилировать свой проект на 150 (просто сто пятьдесят, не миллионов, не тысяч, а единиц строчек, да пусть даже 1.5 тысячи строчек...) нам надо скачать 15ГБ исходников и просто их скомпилировать (ну еще наверно сконфигурировать, версии проверить-согласовать, ...)
Зато у нас микро-ядро и компиляция только после полной загрузки всего (интернета)!
Какой дурак придумал бинарные библиотеки использовать, которые компилируются не зависимо? Это же полный отстой, да и не умеем мы бинарные библиотеки делать, которыми пользоваться можно, даже знать про них не хотим.
Сбавьте тон для начала, зачем же сразу всех записывать в круглые идиоты? :) Тем более, судя по посланию, вы еще слабовато разобрались в матчасти, которую кинулись столь яростно критиковать.
О каком проекте в 150 строк идет речь? Если речь о приложении под KasperskyOS, то для этого не нужно качать 15 Гб исходников: в статье вполне внятно написано, что будет достаточно установить SDK.
О скачивании всего интернета тоже нигде речи не было, непонятно откуда взялись такие фантазии.
Но все исходники, из которых строится операционная система, естественно живут в наших внутренних репозиториях и находятся под нашим полным контролем. Любой внешний код, который туда попадает, предварительно проходит через специальную процедуру и отдел ИБ.
А вот как устроены наши кэши при построении на агентах конвеера, как принимается решение нужно ли пересобирать конкретный бинарный артефакт это тема для отдельной статьи и не относится к Flutter.
ну объясняйте лучше тогда, раз так сложно разобраться.
Вот эту вот логику, например, объясните:
Нам приходится брать Flutter SDK с сайта, адаптировать его и класть в SDK KasperskyOS for Mobile.
Тут есть логика? Flutter SDK является частью SDK KasperskyOS получается?
Другие вопросы нужны? Будете объяснять?
А вот как устроены наши кэши при построении на агентах конвеера, как принимается решение нужно ли пересобирать конкретный бинарный артефакт
Так и хочется спросить: при построении чего? Что можно строить, а для начала разрабатывать, на ваших агентах конвеера? Такое ощущение складывается, от вашего комментария, что разработка вас не интересует, а с ней отладка, удобство навигации, конфигурации исходного кода проекта, главное что есть агенты конвеера с кэшами при построении. А вы знаете что любые такие новомодные усовершенствования билд-системы обычно не совместимы с функциями отладки проекта, то есть просто делают нормальную отладку проекта невозможной?
Кстати, я думаю очень будет интересно потенциальным пользователям KasperskyOS, какие функции доступны проекту приложения с этим голым микроядром, что добавляет использование супер навороченного Флатер?
Ответьте, если вы действительно хотите конструктивного обсуждения, а не пишите для того чтобы подавить неудобное мнение.
Тут есть логика? Flutter SDK является частью SDK KasperskyOS получается?
Да, адаптированный Flutter SDK входит в SDK KasperskyOS, чтобы разработчики могли собирать Flutter приложения под KasperskyOS. Логика здесь вроде бы самая прямолинейная :)
Другие вопросы нужны? Будете объяснять?
Спрашивайте - объясню, конечно. Только вежливо, без истерик.
Так и хочется спросить: при построении чего?
Операционной системы KasperskyOS и ее продуктов из исходных кодов. И процесс этот совсем не тривиальный, им занимается отдельная команда в инфраструктуре с многолетней экспертизой в этой области.
Что можно строить, а для начала разрабатывать, на ваших агентах конвеера?
Внешним разработчикам ничего, конвееры находятся внутри компании для разработчиков самой операционной системы.
Такое ощущение складывается, от вашего комментария, что разработка вас не интересует, а с ней отладка, удобство навигации, конфигурации исходного кода проекта,
Статья была не об инструментах разработчиков KaseprskyOS. А из каких исходных вы делаете выводы что с этим есть какие то проблемы? :) У нас прекрасная команда тулинга, которая обеспеичвает разработчиков всем необходимым. С помощью адаптированного gdb можно полноценно отлаживаться, есть компонент для отслеживания сбоев и символизации бэктрейсов, есть продвинутый логгер, мощный эмулятор на основе QEMU, а также плагин для VS Code, для удобной навигации по коду. Просто это все не имеет прямого отношения к материалу статьи, но если интересно можно пройти по ссылкам, сходить на курсы или поучаствовать в других мероприятиях для разработчиков.
главное что есть агенты конвеера с кэшами при построении
Для кого главное? Вы сами начали говорить про "бинарные библиотеки", подумал может вас именно этот момент заинтересовал.
А вы знаете что любые такие новомодные усовершенствования билд-системы обычно не совместимы с функциями отладки проекта, то есть просто делают нормальную отладку проекта невозможной?
Когда усовершенстования делаются профессионально и с четкой целью обычно они работают хорошо и не вызывают проблемм, которых не должны создавать.
Кстати, я думаю очень будет интересно потенциальным пользователям KasperskyOS, какие функции доступны проекту приложения с этим голым микроядром
Микроядро не голое, вокруг него вполне зрелая экосистема, теперь вот еще и Flutter. А что такое проект приложения? Если имеется в виду пользовательское приложение, то ему будут доступны те функции, которые вы как разработчик в него заложите. Со стороны же KasperskyOS вы получите стандартный набор функционала, который предоставляет любая зрелая операционная система.
Ответьте, если вы действительно хотите конструктивного обсуждения, а не пишите для того чтобы подавить неудобное мнение.
Отвечаю :) Ну "мнение" это слишком громко сказано, для того чтобы составить мнение нужно иметь хотя бы минимальные знания из предметной области (а лучше не минимальные), которую собрались конструктивно обсуждать, а то у вас пока получается что-то из серии "я ничего не знаю о KasperskyOS, но она мне не нравится" :)
Спасибо за развернутый ответ! Он снимает все претензии в предвзятости!
Далее по техническим вопросам:
Статья была не об инструментах разработчиков KaseprskyOS. А из каких исходных вы делаете выводы что с этим есть какие то проблемы?
15Гб это само по себе огромная проблема! Какой смысл для независимого разработчика в микро ядре для работы с которым нужно скачать монолитную комбинацию тулзов-библиотек на 15 ГБ, которые еще надо скомпилировать чтобы после этого просто написать Хелло-Ворд? Какова будет популярность такого "микро"-ядра при таком пороге для его использования, как вы это прогнозируете?
И процесс этот совсем не тривиальный, им занимается отдельная команда в инфраструктуре с многолетней экспертизой
Я думаю вы согласитесь что вряд ли можно гордиться не тривиальностью процесса. Я формулирую это маленько по другому: они много лет варятся в собственном соку и никому не могут нормально объяснить что же они делают. Как минимум источники сложности должны формулироваться относительно просто и не противоречиво.
Вы сами начали говорить про "бинарные библиотеки", подумал может вас именно этот момент заинтересовал.
Да этот момент меня интересует, но я не могу знать как с этим моментом связаны агенты конвеера с кэшами при построении так как я не являюсь разработчиком вашего ядра, а
конвееры находятся внутри компании для разработчиков самой операционной системы.
поэтому не понятно зачем вы ссылаетесь на них в обсуждении вне кампании.
Спасибо за развернутый ответ! Он снимает все претензии в предвзятости!
Рад что мои ответы оказались полезными! По техническим вопросам отпишусь чуть позже.
15Гб это само по себе огромная проблема! Какой смысл для независимого разработчика в микро ядре для работы с которым нужно скачать монолитную комбинацию тулзов-библиотек на 15 ГБ, которые еще надо скомпилировать чтобы после этого просто написать Хелло-Ворд? Какова будет популярность такого "микро"-ядра при таком пороге для его использования, как вы это прогнозируете?
Компиляцию 15 Гб исходников для написания Hello, world делать не нужно. Внешний разработчик скачивает SDK для KasperksyOS и устанвливает его себе локально. Внутри есть адаптированный SDK Flutter для сборки Flutter приложений, а также бинарные библиотеки Flutter Engine, которые используются в рантайме для запуска Flutter приложений. Т.е. для внешнего разработчика процесс выглядит совсем не сложно, несколько шагов и вы получите запущенное в симуляторе приложение. Собираться будет только код самого приложения (Hello, world), все остальное уже бинарное из состава SDK.
Я думаю вы согласитесь что вряд ли можно гордиться не тривиальностью процесса.
Процесс сборки такого сложного продукта как операционная система по определению не может быть тривиальным. Но с точки зрения внутреннего разработчика (внешние разработчики пользуются уже бинарным SDK) локальная сборка выглядит не сложно: нужно склонировать корневовй репозиторий, выбрать конфигурацию и запустить под докером сборку одной командой, а вся магия происходит "под капотом".
Я формулирую это маленько по другому: они много лет варятся в собственном соку и никому не могут нормально объяснить что же они делают.
Они действительно "варятся в собственном соку" для того чтобы разрабочикам не нужно было отвлекаться от своих задач и вникать во все тонкости процесса построения (а их действительно хватает). Однако у нас неплохо налажено межкомандное взаимодействие, есть большая база знаний: когда есть желание и время, можно вникнуть во все детали, прийти к коллегам и они все расскажут и объяснят. Они открыты к идеям по улучшению процесса - это приветствуется, когда разрабортчик испытывает боль от какого-то процесса и знает как его улучшить делится своими идеями.
Да этот момент меня интересует, но я не могу знать как с этим моментом связаны агенты конвеера с кэшами при построении так как я не являюсь разработчиком вашего ядра поэтому не понятно зачем вы ссылаетесь на них в обсуждении вне кампании.
Наверное, я неправильно вас понял и увел обсуждение в особенности внутреннего построения операционной системы. Получается ответ на ваш изначальный вопрос выше: бинарные библиотеки входят в состав SDK и внешним разработчика собирать их из исходников не нужно.
Там это где? В микроядро не входят ни драйвера ни toolchain.
Наверно там где микроядро это про KasperskyOS а там где говорится про десятки репозиториев и 15 ГБ это то что потребуется выкачать для сборки Flutter-а.
В микроядре KasperskyOS около 100 тысяч строк.
Полное дерево исходников Flutter Engine занимает около 15 ГБ.
Связи между этими цифрами нет, потому что Flutter не входит ни в одно ядро операционной системы, а уж тем более в микроядро.
Отдельно хотел рассказать про интеграцию с графической подсистемой по протоколам Wayland.
графическая подсистема в микро ядро не входит, надо понимать. И про DirectX похоже речь не идет в рамках графической подсистемы. А DirectX это фактически стандарт интерфейса к драйверам видео адаптеров, каждый раз, каждому новому адаптеру придется драйвера переписывать под графическую подсистему с, ну супер модными-широко известными-хорошо документированными протоколами Wayland. Сколько таких модных протоколов DirectX пережил?
А! Да, DirectX это опять про бинарную совместимость... блин да мы вообще С++ отменили нельзя не-ядерных разработчиков до него допускать, это наверно важнее всего для безопасности, кстати!
Кому они, нафик, нужны: С++, бинарная совместимость, без них веселее, запустил компиляцию и иди гуляй на пол дня! Блин, там правда исходники все равно на С++ которые пол дня компилируются, опять что-то не сходится, блин.
Главное наверно в том что если за пол дня не скомпилируется или вообще не скомпилируется безопасность точно не пострадает!
Графическая подсистема в ядро не входит.
DirectX это проприетарная библиотека Microsoft и не распространена за пределами Windows. Если говорить о стандартах, то скорее уместнее упоминать OpenGL или Vulkan.
Wayland это открытый протокол, расширяемый благодаря своей гибкой архитектуре. Широко распространен в Nix системах, в том числе коммерчески успешных. Более того интерфесы Wayland описываются в xml-файлах и биндинги могут быть сгенерированы при желании под любой ЯП (т.е. не привязаны к C/C++).
"Приходите в нашу команду" - но как, там же все ссылки 404.
Есть пара вопросов:
1) где-то можно посмотреть на вашу реализацию flutter shell или не планируете опенсорсить?
2) пришлось ли вносить изменения во flutter sdk?
1) В данный момент, к сожалению, нельзя. Мы были бы рады влить наши изменения в основную ветку Flutter и проводим анализ как это можно сделать, но есть определенные риски что патч не будет принят по политическим соображениям.
2) Да, но минимальные: отключили сбор аналитики, попытки получать хэши из git-репозитория и добавили расширили поддержку флага --offline для нескольких комманд.
В данный момент, к сожалению, нельзя. Мы были бы рады влить наши изменения в основную ветку Flutter
Можно наверно форк расшаренный сделать, на него политические соображения принятия вроде не распространяются, заодно проверите.
Можно, но форк придется поддерживать в актальном состоянии, поэтому большого смысла в этом нет. Есть определенные надежды на Flock (форк от Flutter), но, насколько мне известно, изменения от Huawei для поддержки HarmonyOS до сих пор не влиты.
насколько мне известно, изменения от Huawei для поддержки HarmonyOS до сих пор не влиты.
а что вы все ищете одобрения от забугорного дяди? Сделайте так чтобы ваш форк стал популярнее чем базовый проект, чтобы самим выдавать одобрения! Вы к чему стремитесь?
Для этого можно сделать, например, чтобы библиотеки подгружались и компилировались не все скопом не зависимо от того нужны они в исходном коде кастомного проекта или нет и чтобы эти зависимости было легко идентифицировать и управлять ими, управлять структурой проекта и набором его зависимостей. Это такой базовый-профессиональный аспект разработки который мало кто вовремя осознает-понимает, а когда осознает (потому что "если" осознает было бы совсем пессимистично) то уже трудоемкость внедрения сопостовима с вложенной трудоемкостью.
Про хеши: :)
С клавиатурой и accessibility правда ничего не делали на уровне sdk?
Наша команда Mobile SDK and Applications Development, конечно, тоже захотела использовать Flutter при создании приложений
Конечно не претендую на роль настоящего сварщика, но столько тут страданий. Каких-то раскопок позаброшенных поделок Google, разборок с редкими системами сборки и многое другое для обеспечения поддержки приложений на редкостном языке Dart.
Вопрос у меня в том, а перед подобными портированием кто-то вообще оценивает, что может дешевле сделать MVP и свой стандарт? Такой, что не нужно будет в этот самый Dart и можно будет уже существующий код C++ переиспользовать и очень просто. Интерфейсы просто накидать в коде на популярных VBox-ах, а потом подтесать/обточить.
Понятное дело, что наверное взывать сегодня к единому какому-то ABI рисования, виджетов, управления событиями и т.д. просто бесполезно - столько кормиться с этого разных компаний, что стандартизацию погонят в шею даже на самом начале.
Ну назвать 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."
Язык TS по всем показателям лучше Dart, и на нем есть более популярный судя по списку куда более крутых приложений React native.
Планируете его поддерживать?
Оценку по React Native проводили, выглядит чуть менее затратным чем Flutter:
https://reactnative.dev/docs/out-of-tree-platforms
https://github.com/react-native-skia/react-native-skia
Тоже хотели бы взять, в планах есть.
Ну назвать Flutter поделкой, а уже тем более подзаброшенной у меня бы язык не повернулся :)
Возможно. Просто ряд фактов вроде увольнение команды разработчиков Flutter и Dart и создание свободных форков вроде Flock, а так же ощущение, что Google выкидывает на мороз технологию сложилось.
Вы бы, прежде чем кидаться такими сомнительными утверждениями, посетили бы, например, https://crossconf.com, чтобы понимать чем сейчас живут разработчики мобильных приложений.
Не осуждаю вас и жду так же отсутствие осуждения с вашей стороны. Позвольте людям иметь свое собственное мнение относительно происходящего.
Я все еще скептический отношусь к выбору Java, Swift или Dart. А разработчиков готовых прыгнуть под новый подход ради парочки бесплатных библиотек у меня особое мнение.
Решили в очередной раз на переиспользовать чужой опыт ценой вкатывания в временный инструментарии и изображать с серьезными лицами целую отрасль, а еще участвовать в crossconf.com выглядит для меня позором.
Время в целом покажет, но продолжают резать пирог рынка из-за отсутствия регуляторов в отрасли.
Оценка, конечно, же прводилась, но вывести на рынок удачный графический фреймворк, который примет сообщество и под него начнут активно писать это задача мягко говоря ресурсозатратная
С кем не говорю, так одна песня. Сложно (читай нет специалистов), дорого (никто не хочет платить) и не примут (все молятся на идолов вроде Google). А пока продаем что есть и что уже написано и сделано. Проще и дешевле как-то подстроиться и сделать очередной костыль к какой-то библиотечке. В лучших традициях. Ну что ж это ваш выбор на ближайшие 10-20 лет, а там как пойдет.
Репозиторий Flutter/Dart библиотек это около 55 тысяч кроссплатформенных пакетов на все случаи жизни
Уже проходили несколько раз и так ничему не научились? Такая же история была с центральным репозиторием Java где миллионы библиотек, а потом с JavaScript где миллионы библиотек, а потом еще помню был миллион прилоржений под Windows Phone. Где сейчас все это? Похоронено все давно. Думаю, что участь Dart примерно такая же.
Flutter has over 2 million users and is still growing.
Ага, да вы еще вспомните "Java runs on more than 2 billion devices...".
Возможно. Просто ряд фактов вроде увольнение команды разработчиков 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 2 billion devices...".
Ага, Android вспомнил.
KasperskyOS это целая отрасль без малейших преувеличений, а портирование на нее Flutter, это интересный, на наш взгляд, опыт, которым мы делимся с сообществом.
Молодцы, что поделились. Жаль, что выбрали Flutter.
И, раз уж вы тут взялись ярлыки навешивать, то для меня, например, позор это сидеть на дивание и настрачивать малограмотные комментарии по вопросам в которых мало что смыслишь :)
Жаль, что Вы как представитель продукта КасперскийOS позволяете себе оскорбления используемые в качестве доказательства своей позиции.
Мало ли кто какой технологии отдает предпочтение, а что теперь оскорблять их. Вот скажем может вас оскорбляют разработчики других подходов?
Жаль что из общения с умными людьми не извлекли для себя ничего :)
Ничего умного в слепом следовании умирающей технологии я не вижу. Вы схватили списанный со счетов продукт и играетесь. Поиграетесь и забросите скорее всего через пару лет. Давайте подождем и понаблюдаем.
А раз есть платформа никто не мешает разрабатывать под нее собственный графический фреймфорк или портировать существующий
И кто станет разрабатывать графическую систему для чужую систему? Именно по этому вы и схватились за Flutter.
Ага, Android вспомнил.
Который претерпел уже вторую революцию виртуальной машины и постепенно вырастает Flutter из новой системы Fucsia? Это просто отличный пример умирающего легаси.
Пока что статистика играет против вас
Молодцы, что поделились.
То позор, то молодцы - вас что-то не поймешь, но второй вариант мне нравится больше :)
Жаль, что Вы как представитель продукта КасперскийOS позволяете себе оскорбления используемые в качестве доказательства своей позиции.
Это было не доказательство: вы поделились своим видением позора, а я в ответ своим. Вы, видимо, примерили его на себя и оскорбились - предлагаю впредь не навешивать ярлыков и избегать неуместных оценочных суждений.
Мало ли кто какой технологии отдает предпочтение, а что теперь оскорблять их. Вот скажем может вас оскорбляют разработчики других подходов?
Так это же вроде бы вы вылили ведро помоев в сторону целого комьюнити разарботчиков Java, Swift и Dart, нет?
Ничего умного в слепом следовании умирающей технологии я не вижу. Вы схватили списанный со счетов продукт и играетесь.
Не совсем понтяно какой смысл вы вкладываете в "слепое следование" в данном случае - наша задча расширять экосистему операционной системы, поэтому мы стараемся предоставить разработчикам как можно больше знакомых и удобных технологий, а какой из них следовать это уже выбор пользователей.
Что касается Flutter, ты мы не считаем его умирающей технологией, анализ рынка показывает обратное. Более того запрос на Flutter есть у нескольких наших крупных партнеров.
Но в любом случае мы получили полезный для себя опыт портирования такого крупного и технологически сложного фреймворка, который не исчерпывается графической подсистемой и извлекли уроки как сделать так, чтобы портирование обходилось дешевле в будушем.
И кто станет разрабатывать графическую систему для чужую систему?
Графическая система обычно является частью самой операционной системы и писать ее сторонним разработчикам не нужно. Важно где проходит граница, набор устоявшихся протоколов и интерфейсов таких, например, как Wayland. А вот разработчики молодого кроссплатформенного фреймворка могут быть заинтересованы в предоставлении из коробки как можно большего количества поддерживаемых платформ.
Который претерпел уже вторую революцию виртуальной машины и постепенно вырастает Flutter из новой системы Fucsia? Это просто отличный пример умирающего легаси.
Flutter является родным графическим фреймворком для Fuchsia, которую Google планировал как замену Android, но, как мы видим, этого не происходит, а Android живет себе спокойно дальше и развивается. То что виртуальная машина претерпевает революционные изменения также говорит о ее развитии, а не отмирании.
То позор, то молодцы - вас что-то не поймешь, но второй вариант мне нравится больше :)
Ну движение после долгой стагнации это уже хорошо.
Так это же вроде бы вы вылили ведро помоев в сторону целого комьюнити разарботчиков Java, Swift и Dart, нет?
Я понимаю, что они заложники сложившейся ситуации. К сожалению, смелости и силы сделать свое решение среди них пока не нашлось. Это конечно печально.
Не совсем понтяно какой смысл вы вкладываете в "слепое следование"
Слепое следование это сидеть постоянно на предлагаемых "внешних" решениях и просто зарабатывать на них деньги.
Что касается Flutter, ты мы не считаем его умирающей технологией
Понятно. В целом если в дистрибутиве KasperskyOS это будет опциональным решением, так хоть OpenMotif портируйте - не жалко.
Android живет себе спокойно дальше и развивается. То что виртуальная машина претерпевает революционные изменения также говорит о ее развитии, а не отмирании.
Оптимистично. Время покажет.
Ну движение после долгой стагнации это уже хорошо.
А о какой стагнации сейчас речь?
Я понимаю, что они заложники сложившейся ситуации. К сожалению, смелости и силы сделать свое решение среди них пока не нашлось. Это конечно печально.
А свое это какое? Новые языки программирования и фреймворки рождаются и умирают с завидной регулряностью (обычно это называют изобретением велосипеда). Но те кто из них выжили доказали свое право на существование.
Слепое следование это сидеть постоянно на предлагаемых "внешних" решениях и просто зарабатывать на них деньги.
Как я уже писал выше, в случае KasperskyOS выбор какому решению следовать мы предоставляем пользователем, потому что KasperskyOS это платформа.
Если говорить в целом о компании Kaspersky так она, как раз, представляет свои собственные решения на рынке.
И изобретать свои "велосипеды" мы тоже любим - вот, например, взяли и написали "свой git" :) но, само сабой, не ради получения удовольствия от процесса, а отвечая потребностям разработчиков, поэтому он имеет определенные оригинальные преимущества по сравнению с git.
а Android живет себе спокойно дальше и развивается.
Вы как бы аргументируете свою точку зрения, но на самом деле воспроизводите устоявшиеся клише аппелируя как раз к тому что они устоявшиеся и их просто не принято подвергать сомнению. (Не могу утверждать конечно, мне так кажется во многих случаях.) Тот кто опонирует вам пишет что-то действительно от себя это как минимум на порядок сложнее, потому что нет готовых формулировок которые в таком случае можно использовать, мы их только ищем!
Например, я тоже считаю что Андроид держится только за счет своего монопольного положения – нет альтернатив, конкурентов! Пользователям и сторонним разработчикам больше не с чем работать.
Ай фон? Куда он делся?
Вин-мобайл? Мне кажется его специально по тихому(по договоренности?) прикрыли чтобы не создавал конкуренцию.
HarmonyOS? По моему мертва!
Как мы раскрыли внутреннюю архитектуру Flutter и затащили его на собственную платформу