Кодовые базы сильно разошлись за 7 лет, Аврора быстро разивается . В Авроре много нового API, вообще другой жизненный цикл приложений, подписи, свои контролы, даже по компилятору могут не сойтись. Примитивные приложения, наверное, при небольших доработках можно будет запустить.
Иметь совместимость с Sailfish нет смысла
1) это тормозит, так как Sailfish не развивается, под Sailfish не было выпущень за всю историю ни одно коммерческого приложения
2) у нас свой путь, мы быстро развиваем систему , знаем куда её вести и наша экосистема в которой есть Rustore, МойОфис, Wildberries, Иинфотекс и Криптпро дают вектор для улучшений
Это Аврора SDK с эмулятором ОС Аврора на Apple Silicon, поддержку Mac Arm от нас просили очень многие в экосистеме, в Аврора 5.2 мы выпускаем первый Аврора SDK с этой поддержкой.
Телефон на Авроре, дизайн у нас отличается. Кому-то это нравится, кому-то нет, но свой путь он такой .
Если вы не вносите изменений в AOSP как вы получите опыт? Инженерный опыт получается только когда что-то делается: удачное-неудачное, впрок его не получить. Кож aosp на своих серверах не отличим от прошивки aosp на своих серверах. Это набор битов, в которых нет экспертизы.
Вы привели пример Tizen - да это огромная работа, огромный опыт и он действительно на запасной пути, тысячи инженеров, часть из которых я знаю, прошли через разработку Tizen. Это отличный пример, как нужно делать.
Да, будут бесконечные машинокомплекты, и вы сможете собирать это AOSP ещё лет 5 (дальше экосистема отвалится).
Но для этого не нужно было строить завод, достаточно было стоянки бесконечных BMW, потому вто ваши действия дальше неотличимы от взятия готового. Проводя аналогию , можно на нексус положить прошивку AOSP , её никто не отберёт.
Этот подход, на первый взгляд, кажется верным. Сейчас возьмём самое лучшее, а "если что" - подхватим. Но у него есть фундамертальная уязвимость, которую хорошо видно на примере завода BMW в Калининграде.
Был завод, который делал BMW из машинокомплектов , получались классные BMW, в один день их перестали поставлять и почему-то не подхватили, завод встал.
Тут ответ кажется очевидным - ну мы же только собирали и прикручивачивали, проектирование-то делали в Мюнхене. Тут все понятно.
Открытый код (а в aosp он не везде открытый) создаёт иллюзию, что сядем и разберёмся, а пока можно в это не вкладываться- это ментальная ошибка, а иногда введение в заблуждение. Для того, чтобы обладать технологией, нужно её развивать (плохо, хорошо, с ошибками, с проблемами - это инженерный путь проектирования, опыта, коррекции).
Huawei не сел на AOSP, он стал вкладывать ОГРОМНЫЕ инженерные ресурсы в написание своего app framework, баз данных , протоколов обмена данными, ядра, пусть оно пока и не очень, там миллиарды и не рублей в RND. Он это делал ДО пинка санкциями, а в 2020 ускорился. Новое поколение опенхармони он вытащил совместимость с Android , потому что её не может не быть, если ты не зависишь от AOSP (Google).
В этом и заключается главная ловушка Google, пока ты хочешь совместимости с экосистемой Android - ты зависим от поставок из Маунтинвью. Если ты самурай - ок, но тогда нужны большие инженерные ресурсы проходить путь как Android.
И топовые инженеры с контрибьютом в апстрим Linux. Вы все про про админ ресурс какой-то . Давайте мериться инженерными решениями - это технический ресурс.
Дебиан сильно отстаёт по механизмами безопаности . В авроре все аппы в песочница, подписаны, в debian калькулятор читает данные банковского приложения - пользователь то один )
Мне кажется вы Аврору с Астрой перепутали, нет ?
Оно просто заточено пож корпоратов. Признаем, в b2c сценарии это непривычно
Спасибо за вашу оценку - будем стараться улучшать наши материалы
Не заработает.
Кодовые базы сильно разошлись за 7 лет, Аврора быстро разивается . В Авроре много нового API, вообще другой жизненный цикл приложений, подписи, свои контролы, даже по компилятору могут не сойтись. Примитивные приложения, наверное, при небольших доработках можно будет запустить.
Иметь совместимость с Sailfish нет смысла
1) это тормозит, так как Sailfish не развивается, под Sailfish не было выпущень за всю историю ни одно коммерческого приложения
2) у нас свой путь, мы быстро развиваем систему , знаем куда её вести и наша экосистема в которой есть Rustore, МойОфис, Wildberries, Иинфотекс и Криптпро дают вектор для улучшений
Этот режим также зависит от аппаратного обеспечения. С точки зрения ОС мы будем поддерживать его во всех подходящих устройствах. Будут и смартфоны.
https://habr.com/ru/companies/rostelecom/news/969690/
Мне кажется у нас элегантней - но дело вкуса
Это Аврора SDK с эмулятором ОС Аврора на Apple Silicon, поддержку Mac Arm от нас просили очень многие в экосистеме, в Аврора 5.2 мы выпускаем первый Аврора SDK с этой поддержкой.
Телефон на Авроре, дизайн у нас отличается. Кому-то это нравится, кому-то нет, но свой путь он такой .
Если вы не вносите изменений в AOSP как вы получите опыт? Инженерный опыт получается только когда что-то делается: удачное-неудачное, впрок его не получить. Кож aosp на своих серверах не отличим от прошивки aosp на своих серверах. Это набор битов, в которых нет экспертизы.
Вы привели пример Tizen - да это огромная работа, огромный опыт и он действительно на запасной пути, тысячи инженеров, часть из которых я знаю, прошли через разработку Tizen. Это отличный пример, как нужно делать.
Вот тут тоже есть уязвимое место.
Да, будут бесконечные машинокомплекты, и вы сможете собирать это AOSP ещё лет 5 (дальше экосистема отвалится).
Но для этого не нужно было строить завод, достаточно было стоянки бесконечных BMW, потому вто ваши действия дальше неотличимы от взятия готового. Проводя аналогию , можно на нексус положить прошивку AOSP , её никто не отберёт.
Этот подход, на первый взгляд, кажется верным. Сейчас возьмём самое лучшее, а "если что" - подхватим. Но у него есть фундамертальная уязвимость, которую хорошо видно на примере завода BMW в Калининграде.
Был завод, который делал BMW из машинокомплектов , получались классные BMW, в один день их перестали поставлять и почему-то не подхватили, завод встал.
Тут ответ кажется очевидным - ну мы же только собирали и прикручивачивали, проектирование-то делали в Мюнхене. Тут все понятно.
Открытый код (а в aosp он не везде открытый) создаёт иллюзию, что сядем и разберёмся, а пока можно в это не вкладываться- это ментальная ошибка, а иногда введение в заблуждение. Для того, чтобы обладать технологией, нужно её развивать (плохо, хорошо, с ошибками, с проблемами - это инженерный путь проектирования, опыта, коррекции).
Huawei не сел на AOSP, он стал вкладывать ОГРОМНЫЕ инженерные ресурсы в написание своего app framework, баз данных , протоколов обмена данными, ядра, пусть оно пока и не очень, там миллиарды и не рублей в RND. Он это делал ДО пинка санкциями, а в 2020 ускорился. Новое поколение опенхармони он вытащил совместимость с Android , потому что её не может не быть, если ты не зависишь от AOSP (Google).
В этом и заключается главная ловушка Google, пока ты хочешь совместимости с экосистемой Android - ты зависим от поставок из Маунтинвью. Если ты самурай - ок, но тогда нужны большие инженерные ресурсы проходить путь как Android.
И топовые инженеры с контрибьютом в апстрим Linux. Вы все про про админ ресурс какой-то . Давайте мериться инженерными решениями - это технический ресурс.
Ок, ну это вы меня обвинили во лжи, спросил в чем - сразу в кусты.
Готов к технической дискуссии, что AOSP и Linux имеют принципиально разные модели разработки. Раз для вас это неудобный вопрос - ок, извиняюсь.
В чем?
Есть два тезиса, с вашей стороны эмоции. 0 экспертизы. Предлагаю перейти к вопросам к моим тезисам
Давайте конкретику, или опять кусты ?
Ну я внимательно прочитал статью, полагаюсь на неё: раздел про SDK.
Читать статью забавно, потому что описывает опыт сборщика чужой кодовой базы, это неплохо, но разработкой ОС я назвать это не могу.
Давайте, в чем вру?
Мой патч есть в апстриме ядра Linux, я хорошо представляю как работает принятие решений в ядре.
Надеюсь, Вы мне покажете код AOSP 18. Но, скорее всего, пропадете, так как пустые заявления делать легче, чем факты приводить
Разница принципиальная. AOSP разрабатывает только Google, причём в закрытом режиме.
Linux разрабатывают публично.
То есть ключевые отличия от Aosp - сервер времени и локации?
При этом для "российской" ОС надо пользоваться бинарным Android SDK с сайта Google, судя по ответам.
А что разработано в России кроме chroot в lxc контейнер с
RedhatRedOS?Дебиан сильно отстаёт по механизмами безопаности . В авроре все аппы в песочница, подписаны, в debian калькулятор читает данные банковского приложения - пользователь то один )