Google запустила сайт для разработчиков приложений для ОС Fuchsia Статьи редакции

Экспериментальную операционную систему поддерживает пока небольшое количество устройств.

Google запустила сайт операционной системы Fuchsia («Фуксия»), над которой работает компания. Внимание на это обратило Androidcentral.

На сайте опубликованы документы, которые должны помочь разработчикам приложений в создании продуктов для Fuchsia. Разработка осложняется тем, что система пока работает только на нескольких устройствах — среди них Acer Switch Alpha 12 и Google Pixelbook, отмечает издание.

Документы также содержат подробную информацию о микроядре Zircon, на котором построена Fuchsia. Системы Android и Chrome построены вокруг ядра Linux.

Пользователи GitHub обнаружили часть кода ОС Fuchsia в 2016 году. В начале 2018 года журналисты смогли запустить одну из версий проекта на ноутбуках Pixelbook, а в июле 2018 года Bloomberg рассказало о деталях проекта.

0
35 комментариев
Написать комментарий...
Denis Kiselev

Ну - конечно, гуглу много что есть исправлять в андроиде. Например, систему управления памятью. Сборка мусора - это ж жесть! ARC куда изящнее.

Но! У гугла и так перебор с операционными системами. Хорошо - хромоОС нужна неттопам. Но зачем ещё один андроид? Просто поправьте недостатки андроида!

А то мы сейчас имеет ещё одну достаточно дырявую Windows - но для мобильных. Пора бы сделать выводы.

Вот эппл довольно динамично делает deprecated куски своей операционки. Софт, который работал 5 версий назад может не запустится на текущей версии. Это норм, кмк - срок службы дивайсов не так велик и всегда можно не обновлять / перестать обновлять операционку. Возможно, подобным образом следует трансформироваться андроиду.

Ответить
Развернуть ветку
Василий Зеленов

А кто говорил, что это еще один андроид? Это как раз будет замена андроида и ХромОС. Они хотят пойти по пути, который выбрал майкрософт и о котором говорил Apple. Единая модульная ОС, которая будет работать на всём от кофеварок до ПК.
Если они хотят реализовать модульную систему по аналогии со следующей версией Windows, то производитель будет брать лишь необходимые модули исходя из типа устройства.
Эмуляция андроид приложений была заявлена, так что переход будет относительно безболезненным.

Ответить
Развернуть ветку
Denis Kiselev

А что мешает допилить андроид? Зачем нужно делать новую систему с новым ядром и всем-всем? «До основанья, а затем!»

Ответить
Развернуть ветку
Konst

Fuchsia будет менее открытой, как минимум.

Ответить
Развернуть ветку
Denis Kiselev

Почему? Лицензия вроде норм. Код на гитхабе

Ответить
Развернуть ветку
Василий Зеленов

Чтоб отвязаться от кучи исков со стороны Oracle связанных с Java?

Ответить
Развернуть ветку
Denis Kiselev

Там же иски были про api Java - а при сохранении возможности запуска приложений андроида - цель не будет достигнута!

Ответить
Развернуть ветку
Dmitry Vedenko

Она будет более открытой, без GPL

Ответить
Развернуть ветку
Alexander Matveev

Суть не в модульности, а в кросс-платформенности. Модули ядра были еще в 90-е.

Ответить
Развернуть ветку
Злой Полушубок

У ARC тоже есть недостатки:
1. ARC добавляет накладные расходы на reference/dereference. А последний dereference вообще может занимать прилично времени.
2. У ARC нет дефрагментации памяти.
3. ARC требует или крайне жесткого подхода типа Rust или становится источником потенциальных утечем памяти в связи с циклическими ссылками.

Ну и самое главное: под Андроид можно писать и на С++, вот только что-то желающих полностью писать на С++ не так много.

Ответить
Развернуть ветку
Denis Kiselev

Накладные расходы на освобождение памяти происходят в понятный и предсказуемый момент времени. Это - основной плюс.

Расходы на управление памятью всегда присутствуют в системах с автоматическим управлением памятью - только вот сборщик мусора включается когда ему хочется. На это сложно повлиять.

И, безусловно, ARC должна поддерживаться компилятором.

Циклические ссылки побеждают разными типами указателей.

Ответить
Развернуть ветку
Злой Полушубок

В предсказуемый момент это происходит в С++, потому что там есть явный вызов delete. А в языках с ARC заранее трудно сказать когда счетчик ссылок будет 0. Для С++ есть и умные указатели и реализации ARC (даже GC), но писать на нем все равно боль. Точно так же unsafe pointer это боль и источник ошибок.

В целом же ARC имеет меньшие накладные расходы чем GC, но требует большей аккуратности при работе с указателями. С другой стороны в среде iOS разработчиков ходят страшные байки про GC: STW паузы в минуты, потребление памяти на 100500% больше и прочее, что тоже далеко от истины. На современно смартфонном железе GC нормально работает не создавая проблем.

Ответить
Развернуть ветку
Denis Kiselev

Безусловно, в системах с «ручным» управлением памятью програмист сам указывает момент освобождения памяти. Это максимальная управляемость процессом.

В ARC - память (возможно) освобождается в момент выхода переменной из scope. Это - предсказуемый момент во время выполнения программы. Не так сложно подходить разумно к раздаче указателей и не разбрасывать их бесконтрольно. Осторожность надо проявлять при построении взаимозависимых объектов - тогда нужны слабые ссылки, но это уже не так просто.

А вот GC срабатывает по своей логике, и, иногда, в ненужный момент. Даже на современном железе это видно. Не минуту тупит, но лаги в андроиде ощущаются - особенно если знать когда и куда смотреть (например, переключился с игры на браузер).

Кмк, ARC - разумный и довольно удачный компромисс между сложностью, функциями и скоростью. Мне сложно указать на «более лучшую» систему. С «ручным» управлением памятью сравнивать некорректно.

Ответить
Развернуть ветку
Dmitry Vedenko

Не видел тормозов из-за GC на Андроиде года 4 уже. Примерно с момента, как они перешли на ART. В ARC память освобождается не при выходе из скоупа. Она освобюождается, когда объектом перестают владеть, что, в общем случае, происходит в неопределенный момент времени.

Ответить
Развернуть ветку
Denis Kiselev

Ну - не видели - понятно, что заметить тормоза на современном железе не так просто. Современный телефон мощнее многих ноутбуков пятилетней давности. Но аппараты средней ценовой зоны вполне себе тупят

А насчёт освобождения памяти - эмм. А когда память освобождается то?!

Ответить
Развернуть ветку
Dmitry Vedenko

ARC - просто смарт пойнтер. Что в нем изящного? То, что эппл пришлось для его реализации влепить костыль, да еще и имя ему дать - всё, что нужно знать про Objective-C. То, что это уехало кусками в свифт - все, что нужно знать об отношении Apple к разработчикам

Ответить
Развернуть ветку
Denis Kiselev

И ещё немножко поддержки в языке и компиляторе. С понятным моментом освобождения памяти.

А какую систему автоматического управления памятью вы считаете лучшей? Лучше, чем ARC?

Ответить
Развернуть ветку
Dmitry Vedenko

ARC - не система автоматического управления памятью. Она от std::shared_ptr отличается только тем, что для ее реализации нужен костыль в копиляторе, потому что язык, к которому ее прикрутили сбоку, после того как оказалось что писать под айфон модно, поэтому писать будут все - очень бедный. Если тебе на постоянной основе, а не в виде крайне редких исключений, надо разделять strong и weak владение - то это нельзя назвать "автоматическим" управлением.

Ответить
Развернуть ветку
Denis Kiselev

Ну - какого ни какого, но управления памятью. Точно - не «ручного». О степени автоматичности, наверное, спорить смысла нет - это субъективная оценочная категория.

А насчёт strong/weak - это нужно не все время, а в случае дедлоков и кольцевых ссылок. В целом - это проблемы архитектуры кода, если в нем кольцевые ссылки - это правило, а не исключение. К тому же часть решается пулами - если объекты попали в пул и он освобождается - вроде бы даже с кольцом память отпустится.

Ответить
Развернуть ветку
Oleg Marchuk

Android уже не исправишь, когда кода несколько миллионов строк и сложившийся архитектура то вносить хоть какие то мелкие изменения не реально, ведь если где то внести правку то может в другом месте что то поломаться, со временем ошибки и разные костыли накапливаются до такой степени что систему уже не возможно поддерживать.

Ответить
Развернуть ветку
Denis Kiselev

Как же на текущий день живы Unix, Linux, Marcos, Windows - системы с не меньшей кодовой базой и куда более давней историей?

Ответить
Развернуть ветку
Oleg Marchuk

Ага только они почти что не меняются кроме графической оболочки, скорости исполнения программ и нового значительного функционала до сих пор нету.

Ответить
Развернуть ветку
Denis Kiselev

Вы серьёзно щас утверждаете что, например, macOS не менялась?)) иконки новые рисовали.

Ответить
Развернуть ветку
Oleg Marchuk

А что там могло меняться кроме новых иконок, только дизайн и поддержка новых устройств.

Ответить
Развернуть ветку
Denis Kiselev

Переезд с carbon на cocoa. Появление uikit в дополнение к appkit. Новый metal api для графики. И куча всяких новых -kit. Это то, что сразу вспомнилось. Мелкие потребительские фичи не считаем.

Ответить
Развернуть ветку
Vladimir Ivanov

Тут скорее разговор что проще с нуля создать, чем переписать.

Ответить
Развернуть ветку
Denis Kiselev

Ну - и заодно выкинуть в топку миллионы приложений от разработчиков? Нереалистично.

Да и подход - когда до основанья, а затем - он не очень работает. Неуклонные улучшения с заменой устаревшего, такая вот реновация - мне представляются гораздо лучшей тактикой.

Ответить
Развернуть ветку
Vladimir Ivanov

Зачем же выкидывать. Их поддержку анонсировали. А через 5 лет все спокойно перепишут свои приложения под нативную фуксию. Профит

Ответить
Развернуть ветку
Denis Kiselev

Тогда получится в фуксии будет полный андроид и сама фуксия. Бардак прям.

Что мешает андроид допиливать? Делайте как эппл - отрезайте неудачные куски через 3 мажорных версии. Сначала deprecate warning программистам. Потом warning конечным пользователям. Потом - удаляем фичу.

Ответить
Развернуть ветку
Vladimir Ivanov

В том что ахитектурно в андроид с их Activity есть затыки. В том что View слой выделить тяжело. С жизненным циклом в целом проблема. У них даже их модная livedata в потрохах через fragment без отображения реализована. Ну а в остальном, да, хорошая ОС

Ответить
Развернуть ветку
Denis Kiselev

Ну и как это все мешает реализовать новые механизмы в ОС?

Тот же эппл в macOS (тогда ещё MAC OS) заменил Carbon на Cocoa. А сейчас портирует UIKit в рамках проекта Marzipan (ныне Catalyst) с iOS на macOS.

В рамках той же macOS сначала делали GC, потом делали ARC.

Язык заменили - с objective-c на Swift.

Компилятор принципиально другой прикрутили - llvm.

Довольно кардинальные штуки. Так что - было бы желание!

Ответить
Развернуть ветку
Oleg Marchuk

"Что мешает андроид допиливать?"
Ты наверное ни разу не работал над крупным проектом, где даже мелкое изменение дается с трудом а тут цела ос.

Ответить
Развернуть ветку
Denis Kiselev

Как все ИТ компании справляются - даже удивительно! Понавыдумывали себе всяких тестирований и методик, и работают. Вообще страх потеряли перед священной кодовой базой!

Ответить
Развернуть ветку
Oleg Marchuk

"Ну - и заодно выкинуть в топку миллионы приложений от разработчиков?"
95% приложений бесполезное ненужное говно.

Ответить
Развернуть ветку
Denis Kiselev

Я смотрю - вы реалист и практик! ;)

Ответить
Развернуть ветку
32 комментария
Раскрывать всегда