program thomas_test
implicit none
integer, parameter :: n = 10**7 ! 10 миллионов элементов
real(8), allocatable :: a(:), b(:), c(:), d(:), x(:), cp(:), dp(:)
real(8) :: m, t1, t2
integer :: i
call cpu_time(t1)
print *, "Выделение памяти для n =", n
allocate(a(n-1), b(n), c(n-1), d(n), x(n), cp(n-1), dp(n))
! Наполним данными, чтобы процессор не скучал
a = 1.0d0; b = 4.0d0; c = 1.0d0; d = 10.0d0
print *, "Поехали! Считаем прогонку..."
! --- Тот самый алгоритм ---
cp(1) = c(1) / b(1)
dp(1) = d(1) / b(1)
do i = 2, n
m = 1.0d0 / (b(i) - a(i-1) * cp(i-1))
if (i < n) cp(i) = c(i) * m
dp(i) = (d(i) - a(i-1) * dp(i-1)) * m
end do
x(n) = dp(n)
do i = n-1, 1, -1
x(i) = dp(i) - cp(i) * x(i+1)
end do
! -------------------------
call cpu_time(t2)
print "(A, F10.6, A)", " Время выполнения: ", t2 - t1, " сек."
print *, "Контрольное значение x(1):", x(1)
deallocate(a, b, c, d, x, cp, dp)
end program thomas_test
результаты
$ gfortran -O3 -march=native -ffast-math thomas_test.f90 -o thomas_test
$ ./thomas_test
Выделение памяти для n = 10000000
Поехали! Считаем прогонку...
Время выполнения: 0.371780 сек.
Контрольное значение x(1): 2.1132486540518713
Нет, на мои вопросы вы не ответили. Мой основной вопрос: зачем скрывать ViewModel за абстракциями?
1. И я, и @house2008 пишем примерно о том, что на ViewModel абстракции не надо делать, протоколы тут излишни. Нигде в коде @house2008 я не вижу стирания типов. Фреймворк хочет конкретный класс ViewModel? - окей, дайте ему конктретный класс ViewModel. В чем проблема то? Нужно тестировать? - окей, подменяйте в тестах источники данных, это будет чище и прозрачнее.
2. Вот я цитирую Википедию в разделе Rationale:
MVVM was designed to remove virtually all GUI code ("code-behind") from the view layer, by using data binding functions in WPF (Windows Presentation Foundation) to better facilitate the separation of view layer development from the rest of the pattern.
Data binding - это и есть основной механизм. Это не опциональное, это и есть фундамент MVVM. Data binding - это и есть реализация паттерна "Наблюдатель", просто зашитая внутри фреймворка. Не надо предлагать вручную дублировать функционал.
Кстати, в Android разработке я могу на коллбеках построить механизм, и мне за это ничего не будет, потому что есть Garbage Collector. А вот в iOS такую схему уже так просто не реализовать, потому как циклические ссылки и всё такое. Возможно, что ради избегания циклических ссылок MVVM и становится все более популярным для iOS.
Вообще не понимаю, зачем такое сложности? Зачем делать слой абстракции, если View наразрывно связана со своей/своими ViewModel? Основной концепт подхода в том, что при изменении данных/стейта внутри ViewModel автоматически обновляется View. Делать абстракцию не нужно, потому что View + ViewModel - это и есть слой presentation (на вашей же картинке в статье это указано), который отвязан от model.
Задело? Окей, я попробую объяснить, как я это воспринимаю.
Читаю статью и вижу:
Может, написать отдельно interface со своими @Binds-методами, и отдельно object со своими @Provides-методами? Получится неудобно
Первая моя мысль: "Автор - сраный диверсант. Сейчас джуны начитаются, а потом будут такую хуиту на ревью приносить." Потом я захожу в профиль и вижу, что написано "стажер" и "Люблю промышленную разработку! Изучаю Android-разработку на Kotlin...". Моя вторая мысль: "Стажер открыл магию статики в Kotlin".
Комментарий я все-таки решил написать, но писать "КГ/АМ" как-то не сильно конструктивно, поэтому я немного раскрыл мысль, почему этот "креатив - говно". Тем более ты же буквально сейчас сам написал:
Я прекрасно понимаю, что в реальном проекте стоит делить модули по фичам или слоям
Если в реальном проекте твой подход со статикой используется чуть более чем никогда (возможно в очень-очень редких случаях и с полным пониманием зачем и почему, и то вряд ли так будут делать), то зачем ты вообще это все написал?
Однако, я прошу прощения за мой резкий тон. Тут я не прав, признаю.
Хочется и по содержанию статьи проехаться и по личности... походу я так и сдохну с отрицательной кармой :)
Автор, ты - стажер, и тебе рано еще писать технические статьи, наберись опыта. Формально ты прав, и формально так можно делать. Но этот подход НЕ полулярный, и так НЕ делают. Потому что помимо одного репозитория и экземпляра Retrofit, будут еще репозитории (внезапно), API, которые ты получаешь из Retrofit, другие сущности, совершенно не связанные с сетевой активностью. Поддержка файла с таким подходом превратится в ад при наличии сколь-нибудь чуть более сложной логики, чем единственный репозиторий. Принцип Single Responsibility придуман не просто так. Дели по смыслу ответственности даже модули в DI, не стоит усложнять себе жизнь на ровном месте.
Я как-то писал практический гайд по Hilt для новичков
Во-первых, разблокированный загрузчик, как правило, аннулирует гарантию, так что это не аргумент. Кривые руки пользователя - это проблема исключительно пользователя. Пожалуйста, не надо прикрываться "заботой о пользователе", на примере РКН мы все прекрасно видим, чего стоит такая "забота".
Во-вторых, силой действиельно никто не заставляет, однако, если телефон рутован, то отвалятся, как минимум, банковские приложения. Тут тоже, пожалуйста, не надо прикрываться "безопасностью", потому как банки по факту не несут ответственности и при нерутованном девайсе. Пользователя буквально вынуждают покупать устройство с ограниченным доступом, иначе многие приложения просто не заведутся.
В-третьих, вероятно, вы правы в том, что 99,9% не используют рут, и, вероятно в том, что "оно им не надо". Но людям нужен не именно рут доступ, им нужна возможность убрать то, что им не надо, и поставить то, что им надо. Сейчас картина выглядит примерно так: человек покупает себе топ девайс, например Samsung, за $1000-1500 (это не маленькие деньги для такого устройства), и за свои же деньги он не имеет возможности удалить то, что ему ну вот вообще никак не нужно. У него стоит ПО от Samsung (их апп стор, галерея, knox и пр. бред), обязательное ПО (Яндекс браузер, госуслуги, MAX и пр.), и пользователь никак от этого не может избавиться. При этом на тех же Samsung легальный бекдор от вендора по факту стоит.
Проблема "невладения" своим купленным устройством расширяется. Мало того, что уже сейчас пользователь не может удалить то, что ему не нравится. В исходном посте новость о том, что пользователь не сможет поставить то, что нравится. Удавка затягивается... на деньги пользователя. И конечно же, все прикрываются лицемерной "заботой о безопасности", не отвечая по сути ни за что.
ну так другие вендоры тоже "дают полный доступ без проблем" с теми же оговорками
это не так
длинный текст, который напрямую не относится к теме
Сначала я приведу в пример десктопы, а потом плавно перейду к смартфонам. Текст не сильно связанный, это больше тезисы :)
Что хочет обычный пользователь? - Он хочет условного "сел и поехал". Пользователь не хочет разбираться с правами доступа, конфигами, версиями пакетов и пр. Он хочет запустить девайс, запустить браузер и посмотреть YouTube, или поиграть в игрушку, или отредактировать документ, или еще что-либо в этом духе. И в этом плане какой-нибудь наглухо закрытый MacBook более чем подходящий инструмент.
Что хочет инженер, который обеспечивает доставку до пользователя этих возможностей? - Инженер хочет предсказуемости и скорости системы. И в этом плане открытый или условно-открытый Linux занимает доминирующее положение.
Windows как OS немного уникальна в том плане, что это нечто среднее.
Почему такое разнообразие стало вообще возможно на десктопе? - Ответ достаточно простой - "Plug-and-Play". Разные производители поставляют комплектующие, из которых собирается готовое изделие. Ядро OS в принципе может "опросить" новую деталь и, если есть драйвер, то работать с ней. Собственно, Windows и Linux примерно так и работают, поэтому у нас в принципе есть возможность тупо сменить систему. В противоположность этому Apple выпускает уже готовое изделие, где максимум, что мы можем сделать, это поменять обои на "нескучные".
Фишка смартфонов №1. Там PnP невозможен в принципе, значит производитель выпускает "изделие". Т.е. у вендора есть техническая возможность позиционировать смартфон, как весь девайс, а не набор микросхем.
Фишка №2. Гугл и различные сервисы (банки, например) создали систему, когда наличие у пользователя прав root, считай, маркирует устройство, как недоверенное. А работать в недоверенной среде они не будут, якобы для безопасности пользователя. Активно им помогает в этом технология TEE и требование Гугла делать hardware проверку, а не software, как было 8 лет назад. Забавно, что по факту банки никакой ответственности за украденные деньги не несут.
Фишка 3 следует из предыдущих. Вендор просто отключает возможность рута. Потому что... а зачем, если у юзера тупо половина аппок работать не будет? Ну а раз рута у пользователя нет, то можно и свой мусор понапихать, типа бекдоров, Knox и прочей мути.
Короче, что имеем, то имеем...
Принципиально я вашу позицию разделяю.
Рассматривайте смартфон не как устройство общего назначения, а как терминал доступа к услугам. С этой точки зрения отсутствие рута вполне логично.
Не понял комментарий. Вы мне оппонируете? Или подтвеждаете? Или что?
Мой поинт был о том, что несмотря на то, что Google закручивает гайки в плане установки софта, он вместе с тем на своих девайсах дает возможность получить полный доступ без проблем, в отличие от других вендоров.
Поразумевается, что человек знает, что делает, когда разблокирет загрузчик. Можешь GrapheneOS поставить (рута не будет, зато будет полный контроль над средой), можешь кастомную прошивку поставить (какой-нибудь ZverDVD, ага...), можешь из исходников AOSP собрать (без гугл сервисов, естественно). Если что-то пойдет не так, то можно к родной прошивке откатиться. Чтобы "окирпичить" смарфон окончательно - это надо целенаправлено сам загрузчик перепрошить, но и тут вариант восстановления возможен (как раз с сервисными утилитами и спец. ключами). Но опять же, подразумевается, что человек знает, что делает.
К чему, собственно, ваш коммент? Мы же на Хабре вроде. Ну почитайте мануал, прежде, чем что-то делать...
Либо вы разбираетесь что и как это работает, чтобы вернуть контроль над устройством себе. Либо потребляете то, что есть, то есть с телеметрией, рекламой, безопасностью и прочем. Для большинства пользователей вполне достаточно второго варианта.
Ну, справедливости ради, загрузчик на Google Pixel действительно разблокируется "простой галочкой в меню разработчика", в отличие от Xiaomi, Samsung и пр. Ставишь галочку, разблокируешь загрузчик и ставь любой образ, который хочешь.
Статью прочитал, и прям очко сжимается от воспоминаний. 2 раза удаляли. 1-й раз традиционно петлей в городской больнице - на редкость белзненный опыт. 2-й раз, когда рецидив был, мама нах послала мясников из гос. контор и в частную клинику повела. Там уже хз чем, точно не ножом, какая-то трубка с отсосом была, под местной анестезией. Довольно терпимо, кстати. Не уверен, что общий наркоз так уж необходим. Хотя может мне просто в сравнении так кажется.
Я полез разбираться с этой темой... и признаю, что я маху дал с собственными чипами и все такое... Контроллер для обработки физики там от Siemens (линк ниже). В целом, разработка собственного контроллера под это дело - работа не на один десяток лет и не на один десяток миллиардов.
Но в целом, что они сделали - вопрос интересный. И ответа с полной достоверностью дать на него не могу. Но мне пришлось достаточно много погуглить, чтобы сделать хоть какой-то приблизительный вывод.
Кто такие "ДМ Технолоджис"? Это не чисто Российская контора. Недавно это была площадка для производства станков японско-немецкого холдинга DMG Mori.
Хронология:
Итак, в марте 2023 года DMG Mori презентует модель DMG Mori T2 линк на YouTube (пока разрешено)
В сентябре 2023 года DMG Mori попадает под скандал о поставках обрабатывающих станков на нужды военных РФ линк на Insider, линк на Агенство (я хз запрещены линки туда в РФ или нет, на свой страх и риск открывайте)
В ноябре 2023 года DM Technologies презентует модель Cobalt T2 линк на mashnews.ru (понятия не имею насчет запретов)
В декабре 2023 года DM Technologies попадает под санкции линк на opensanctions.org (тоже хз насчет запретов)
Т.е. DMG Mori вплоть до скандала делились разработками со своей российской площадкой. Но со включением санкций DM Technologies оказались в ситуации, когда им резко перекрыли доступ к софту на эти станки. А без ПЛК эти станки - просто груда металла.
Но, безотносительно моральной составляющей, необходимая квалификация инженеров и доступ к оборудованию, а может и к исходникам ПО, у "ДМ Технолоджис" были. Время, небходимое для разработки ПЛК, у них было (2 года). Так что есть очень большая вероятность, что это отечественное ПО без кавычек. Да, это не топ инженерии со своим контроллером, но вполне себе достойная разработка.
Вон в комментах ниже @UFO_01 пишет, что обычно линукс для некритичных вещей, а физика станка на своих чипах.
Задачи разного уровня. Если в статье про "отечественное ПО" речь о том, что они интерфейс сделали и на линукс его запустили - то это лажа. А если речь о том, что на своих чипах с прошивкой - то это уже отечественное ПО без всяких кавычек.
Маловероятно, что линукс. Я не спец по таким вещам, но для станков я бы использовал Гарвардскую архитектуру со своим ПО, а не линукс с фон Неймановской.
На вопросы ответа не будет, потому что многое зависит от функционала. Ваш пример по сути простой "Hello world" и на таком рафинированном примере достичь цифры 21% достаточно легко. Можно и больше, используя CMP для одинакового UI.
Проблемы начинаются тогда, когда нужно работать с датчиками, камерой, bluetooth, файлами и пр. Если, скажем для сетевых запросов есть готовая библиотека Ktor, то для платформо-специфических вещей универсального решения нет. Да и не факт, что оно вообще появится когда-нибудь.
Еще есть проблема перехода команды. Далеко не факт, что разработчики под одну платформу хотя бы читали документацию по другой платформе. Т.е. процесс перехода на CMP/KMP может быть не такой быстрый и безоблачный, каким представляется на подобных примерах. Единственное, но не настолько значимое, преимущество у Android разработчиков - они хотя бы синтаксис и стиль Kotlin знают. Но опять же, это особого профита не даст.
Суммируя:
если приложение просто тонкий CRUD клиент - то однозначно имеет смысл работать с CMP/KMP
если приложение работает с hardware смартфона - то черт знает... думайте сами :)
Я уже лет 15 математикой не занимался, так что мне пришлось прибегнуть к помощи нейронки. Но результаты от этого не сильно пострадали.
Железо и компилятор
листинг
результаты
Вывода не будет...
Дополнение: Список стран (ссылка на сайт ФНС) по состоянию на 14.10.25 г.
Нет, на мои вопросы вы не ответили. Мой основной вопрос: зачем скрывать ViewModel за абстракциями?
1. И я, и @house2008 пишем примерно о том, что на ViewModel абстракции не надо делать, протоколы тут излишни. Нигде в коде @house2008 я не вижу стирания типов. Фреймворк хочет конкретный класс ViewModel? - окей, дайте ему конктретный класс ViewModel. В чем проблема то? Нужно тестировать? - окей, подменяйте в тестах источники данных, это будет чище и прозрачнее.
2. Вот я цитирую Википедию в разделе Rationale:
Data binding - это и есть основной механизм. Это не опциональное, это и есть фундамент MVVM. Data binding - это и есть реализация паттерна "Наблюдатель", просто зашитая внутри фреймворка. Не надо предлагать вручную дублировать функционал.
Кстати, в Android разработке я могу на коллбеках построить механизм, и мне за это ничего не будет, потому что есть Garbage Collector. А вот в iOS такую схему уже так просто не реализовать, потому как циклические ссылки и всё такое. Возможно, что ради избегания циклических ссылок MVVM и становится все более популярным для iOS.
Вообще не понимаю, зачем такое сложности? Зачем делать слой абстракции, если View наразрывно связана со своей/своими ViewModel? Основной концепт подхода в том, что при изменении данных/стейта внутри ViewModel автоматически обновляется View. Делать абстракцию не нужно, потому что View + ViewModel - это и есть слой presentation (на вашей же картинке в статье это указано), который отвязан от model.
Вы какую-то логику ищете?
Эти ребята блокируют заходы на сайты РЖД и Почты России с иностранных IP, т.е. контор, которые в принципе с зарубежом работают.
Задело? Окей, я попробую объяснить, как я это воспринимаю.
Читаю статью и вижу:
Первая моя мысль: "Автор - сраный диверсант. Сейчас джуны начитаются, а потом будут такую хуиту на ревью приносить." Потом я захожу в профиль и вижу, что написано "стажер" и "Люблю промышленную разработку! Изучаю Android-разработку на Kotlin...". Моя вторая мысль: "Стажер открыл магию статики в Kotlin".
Комментарий я все-таки решил написать, но писать "КГ/АМ" как-то не сильно конструктивно, поэтому я немного раскрыл мысль, почему этот "креатив - говно". Тем более ты же буквально сейчас сам написал:
Если в реальном проекте твой подход со статикой используется чуть более чем никогда (возможно в очень-очень редких случаях и с полным пониманием зачем и почему, и то вряд ли так будут делать), то зачем ты вообще это все написал?
Однако, я прошу прощения за мой резкий тон. Тут я не прав, признаю.
Хочется и по содержанию статьи проехаться и по личности... походу я так и сдохну с отрицательной кармой :)
Автор, ты - стажер, и тебе рано еще писать технические статьи, наберись опыта. Формально ты прав, и формально так можно делать. Но этот подход НЕ полулярный, и так НЕ делают. Потому что помимо одного репозитория и экземпляра Retrofit, будут еще репозитории (внезапно), API, которые ты получаешь из Retrofit, другие сущности, совершенно не связанные с сетевой активностью. Поддержка файла с таким подходом превратится в ад при наличии сколь-нибудь чуть более сложной логики, чем единственный репозиторий. Принцип Single Responsibility придуман не просто так. Дели по смыслу ответственности даже модули в DI, не стоит усложнять себе жизнь на ровном месте.
Я как-то писал практический гайд по Hilt для новичков
https://mardsoul.github.io/dev-in-action/articles/hilt-for-beginners/
Т-Банк еще и оборудование регулярно опрашивает...
Попробуй через adb придушить
хм... ну да, тоже верно. значит мой первый коммент некорректный
виртуальный плюс в карму (сам поставить не могу) за уточнение
Во-первых, разблокированный загрузчик, как правило, аннулирует гарантию, так что это не аргумент. Кривые руки пользователя - это проблема исключительно пользователя. Пожалуйста, не надо прикрываться "заботой о пользователе", на примере РКН мы все прекрасно видим, чего стоит такая "забота".
Во-вторых, силой действиельно никто не заставляет, однако, если телефон рутован, то отвалятся, как минимум, банковские приложения. Тут тоже, пожалуйста, не надо прикрываться "безопасностью", потому как банки по факту не несут ответственности и при нерутованном девайсе. Пользователя буквально вынуждают покупать устройство с ограниченным доступом, иначе многие приложения просто не заведутся.
В-третьих, вероятно, вы правы в том, что 99,9% не используют рут, и, вероятно в том, что "оно им не надо". Но людям нужен не именно рут доступ, им нужна возможность убрать то, что им не надо, и поставить то, что им надо. Сейчас картина выглядит примерно так: человек покупает себе топ девайс, например Samsung, за $1000-1500 (это не маленькие деньги для такого устройства), и за свои же деньги он не имеет возможности удалить то, что ему ну вот вообще никак не нужно. У него стоит ПО от Samsung (их апп стор, галерея, knox и пр. бред), обязательное ПО (Яндекс браузер, госуслуги, MAX и пр.), и пользователь никак от этого не может избавиться. При этом на тех же Samsung легальный бекдор от вендора по факту стоит.
Проблема "невладения" своим купленным устройством расширяется. Мало того, что уже сейчас пользователь не может удалить то, что ему не нравится. В исходном посте новость о том, что пользователь не сможет поставить то, что нравится. Удавка затягивается... на деньги пользователя. И конечно же, все прикрываются лицемерной "заботой о безопасности", не отвечая по сути ни за что.
это не так
длинный текст, который напрямую не относится к теме
Сначала я приведу в пример десктопы, а потом плавно перейду к смартфонам. Текст не сильно связанный, это больше тезисы :)
Что хочет обычный пользователь? - Он хочет условного "сел и поехал". Пользователь не хочет разбираться с правами доступа, конфигами, версиями пакетов и пр. Он хочет запустить девайс, запустить браузер и посмотреть YouTube, или поиграть в игрушку, или отредактировать документ, или еще что-либо в этом духе. И в этом плане какой-нибудь наглухо закрытый MacBook более чем подходящий инструмент.
Что хочет инженер, который обеспечивает доставку до пользователя этих возможностей? - Инженер хочет предсказуемости и скорости системы. И в этом плане открытый или условно-открытый Linux занимает доминирующее положение.
Грубо говоря, пользователю нужна услуга, инженеру - инструмент.
Windows как OS немного уникальна в том плане, что это нечто среднее.
Почему такое разнообразие стало вообще возможно на десктопе? - Ответ достаточно простой - "Plug-and-Play". Разные производители поставляют комплектующие, из которых собирается готовое изделие. Ядро OS в принципе может "опросить" новую деталь и, если есть драйвер, то работать с ней. Собственно, Windows и Linux примерно так и работают, поэтому у нас в принципе есть возможность тупо сменить систему. В противоположность этому Apple выпускает уже готовое изделие, где максимум, что мы можем сделать, это поменять обои на "нескучные".
Фишка смартфонов №1. Там PnP невозможен в принципе, значит производитель выпускает "изделие". Т.е. у вендора есть техническая возможность позиционировать смартфон, как весь девайс, а не набор микросхем.
Фишка №2. Гугл и различные сервисы (банки, например) создали систему, когда наличие у пользователя прав root, считай, маркирует устройство, как недоверенное. А работать в недоверенной среде они не будут, якобы для безопасности пользователя. Активно им помогает в этом технология TEE и требование Гугла делать hardware проверку, а не software, как было 8 лет назад. Забавно, что по факту банки никакой ответственности за украденные деньги не несут.
Фишка 3 следует из предыдущих. Вендор просто отключает возможность рута. Потому что... а зачем, если у юзера тупо половина аппок работать не будет? Ну а раз рута у пользователя нет, то можно и свой мусор понапихать, типа бекдоров, Knox и прочей мути.
Короче, что имеем, то имеем...
Принципиально я вашу позицию разделяю.
Рассматривайте смартфон не как устройство общего назначения, а как терминал доступа к услугам. С этой точки зрения отсутствие рута вполне логично.
Не понял комментарий. Вы мне оппонируете? Или подтвеждаете? Или что?
Мой поинт был о том, что несмотря на то, что Google закручивает гайки в плане установки софта, он вместе с тем на своих девайсах дает возможность получить полный доступ без проблем, в отличие от других вендоров.
Поразумевается, что человек знает, что делает, когда разблокирет загрузчик. Можешь GrapheneOS поставить (рута не будет, зато будет полный контроль над средой), можешь кастомную прошивку поставить (какой-нибудь ZverDVD, ага...), можешь из исходников AOSP собрать (без гугл сервисов, естественно). Если что-то пойдет не так, то можно к родной прошивке откатиться. Чтобы "окирпичить" смарфон окончательно - это надо целенаправлено сам загрузчик перепрошить, но и тут вариант восстановления возможен (как раз с сервисными утилитами и спец. ключами). Но опять же, подразумевается, что человек знает, что делает.
К чему, собственно, ваш коммент? Мы же на Хабре вроде. Ну почитайте мануал, прежде, чем что-то делать...
Либо вы разбираетесь что и как это работает, чтобы вернуть контроль над устройством себе. Либо потребляете то, что есть, то есть с телеметрией, рекламой, безопасностью и прочем. Для большинства пользователей вполне достаточно второго варианта.
Ну, справедливости ради, загрузчик на Google Pixel действительно разблокируется "простой галочкой в меню разработчика", в отличие от Xiaomi, Samsung и пр. Ставишь галочку, разблокируешь загрузчик и ставь любой образ, который хочешь.
оффтоп
что-то вспомнилась тема на cyberforum.ru
Дата регистрации BotHub 10 октября 2023 года, всего 439 статей. У вас такой KPI на нейрослоп статью каждые 2 дня?
Статью прочитал, и прям очко сжимается от воспоминаний. 2 раза удаляли. 1-й раз традиционно петлей в городской больнице - на редкость белзненный опыт. 2-й раз, когда рецидив был, мама нах послала мясников из гос. контор и в частную клинику повела. Там уже хз чем, точно не ножом, какая-то трубка с отсосом была, под местной анестезией. Довольно терпимо, кстати. Не уверен, что общий наркоз так уж необходим. Хотя может мне просто в сравнении так кажется.
Я полез разбираться с этой темой... и признаю, что я маху дал с собственными чипами и все такое... Контроллер для обработки физики там от Siemens (линк ниже). В целом, разработка собственного контроллера под это дело - работа не на один десяток лет и не на один десяток миллиардов.
Но в целом, что они сделали - вопрос интересный. И ответа с полной достоверностью дать на него не могу. Но мне пришлось достаточно много погуглить, чтобы сделать хоть какой-то приблизительный вывод.
Кто такие "ДМ Технолоджис"? Это не чисто Российская контора. Недавно это была площадка для производства станков японско-немецкого холдинга DMG Mori.
Хронология:
Итак, в марте 2023 года DMG Mori презентует модель DMG Mori T2 линк на YouTube (пока разрешено)
В сентябре 2023 года DMG Mori попадает под скандал о поставках обрабатывающих станков на нужды военных РФ линк на Insider, линк на Агенство (я хз запрещены линки туда в РФ или нет, на свой страх и риск открывайте)
В ноябре 2023 года DM Technologies презентует модель Cobalt T2 линк на mashnews.ru (понятия не имею насчет запретов)
В декабре 2023 года DM Technologies попадает под санкции линк на opensanctions.org (тоже хз насчет запретов)
Т.е. DMG Mori вплоть до скандала делились разработками со своей российской площадкой. Но со включением санкций DM Technologies оказались в ситуации, когда им резко перекрыли доступ к софту на эти станки. А без ПЛК эти станки - просто груда металла.
Но, безотносительно моральной составляющей, необходимая квалификация инженеров и доступ к оборудованию, а может и к исходникам ПО, у "ДМ Технолоджис" были. Время, небходимое для разработки ПЛК, у них было (2 года). Так что есть очень большая вероятность, что это отечественное ПО без кавычек. Да, это не топ инженерии со своим контроллером, но вполне себе достойная разработка.
Вон в комментах ниже @UFO_01 пишет, что обычно линукс для некритичных вещей, а физика станка на своих чипах.
Задачи разного уровня. Если в статье про "отечественное ПО" речь о том, что они интерфейс сделали и на линукс его запустили - то это лажа. А если речь о том, что на своих чипах с прошивкой - то это уже отечественное ПО без всяких кавычек.
Маловероятно, что линукс. Я не спец по таким вещам, но для станков я бы использовал Гарвардскую архитектуру со своим ПО, а не линукс с фон Неймановской.
На вопросы ответа не будет, потому что многое зависит от функционала. Ваш пример по сути простой "Hello world" и на таком рафинированном примере достичь цифры 21% достаточно легко. Можно и больше, используя CMP для одинакового UI.
Проблемы начинаются тогда, когда нужно работать с датчиками, камерой, bluetooth, файлами и пр. Если, скажем для сетевых запросов есть готовая библиотека Ktor, то для платформо-специфических вещей универсального решения нет. Да и не факт, что оно вообще появится когда-нибудь.
Еще есть проблема перехода команды. Далеко не факт, что разработчики под одну платформу хотя бы читали документацию по другой платформе. Т.е. процесс перехода на CMP/KMP может быть не такой быстрый и безоблачный, каким представляется на подобных примерах. Единственное, но не настолько значимое, преимущество у Android разработчиков - они хотя бы синтаксис и стиль Kotlin знают. Но опять же, это особого профита не даст.
Суммируя:
если приложение просто тонкий CRUD клиент - то однозначно имеет смысл работать с CMP/KMP
если приложение работает с hardware смартфона - то черт знает... думайте сами :)