Фуксия — небольшой вечнозеленый кустарник семейства кипрейных с красивыми цветками. А еще это новый проект Google
Большинство операционных систем и программных платформ, разработанных корпорацией Google, основаны на ядре Linux. В число таких продуктов компании входят Chrome OS, Android, Chromecast. Фактически, Linux является центром экосистемы программного обеспечения «корпорации добра».
В то же время, ядро Linux далеко не всегда является идеальной базой для специализированного ПО. Особенно это актуально для встроенных устройств с ограниченным программным обеспечением. Сейчас несколько инженеров Google работает над созданием новой операционной системы, предназначенной для таких устройств. Исходный код выкладывается в новый репозиторий с названием Fuchsia (фуксия).
Новые коммиты появляются уже несколько недель, но на этот репозиторий сторонние разработчики обратили внимание только сейчас. После анализа содержимого оказалось, что Fuchsia базируется на (L)ittle (K)ernel и Magenta. LK — это небольшая ОС, созданная для встроенных небольших устройств. Размер ядра LK составляет от 15 до 20 КБ, исходники доступны здесь. Это открытое программное обеспечение, которое распространяется по лицензии MIT. Magenta используется в современных телефонах и персональных компьютерах с продвинутой конфигурацией, оснащенных гигабайтами памяти и современными процессорами. Fuchsia, насколько можно понять, является гибридной системой, построенной одновременно на основе этих двух платформ. Она поддерживает 32- и 64-битные ARM-процессоры.
В репозитории сейчас много исходников. Судя по всему, Fuchsia поддерживает Dart, JSON, SSL, Google GO, LLVM, Rust. Есть и специальная версия Fortune — простую программу, которая показывает псевдослучайное сообщение, впервые появившуюся в Version 7 Unix.
В Fuchsia для создания пользовательского интерфейса использован Flutter. Основной программный язык — Dart. И вершиной всего этого является Escher, поддерживающий ряд визуальных эффектов. Скорее всего, инженеры Google планируют использовать Material Design в своей новой системе.
Для чего все это? Пока сложно сказать, но делаются предположения о том, что Fuchsia будет работать в качестве ОС на смартфонах и ПК. Возможно, корпорация Google планирует в один прекрасный день заменить Chrome OS и Android своей новой системой. С другой стороны, компания может разрабатывать Fuchsia в качестве ОС для своих умных систем вроде Google Home и OnHub.
А может быть, это только эксперимент компании, и мы никогда не увидим готовый к использованию коммерческий продукт. Правда, разработка ядра и операционной системы — это сложная задача, на выполнение которой требуется время и ресурсы. Так что если и эксперимент, то очень масштабный.
Опробовать новую ОС в деле можно самостоятельно. Вскоре Fuchsia будет доступна на Raspberry Pi 3.
Комментарии (53)
Meider1
14.08.2016 19:34+5Сейчас тренд на IoT, ну и делают видать легкую ос, хотя хуавей тоже уже слабал подобную.
albik
14.08.2016 20:15-1И ни слова о том, что Magenta — реализация Darwin поверх ядра Linux, имеющая бинарную совместимость с iOS. На эту тему была статья от 2012-ого тут же — https://habrahabr.ru/post/145643/. Если они сюда прикрутят стек Android и замену проприетарным либам iOS, то Apple не позавидуешь.
joann
14.08.2016 20:29Смысл? приложения и AppStore все равно не запустить
isden
14.08.2016 20:38+2А может быть тут есть какая-то связь со Swift? Т.е. разработчик пишет на одном языке апп, и потом публикует его во все сторы.
joann
14.08.2016 21:14Да но для этого не нужно Darwin переносит, Swift открытый, сделай чтоб он работал у тебя и все. Но UI и многие компоненты все равно будут работать тока под iOS…
NeoCode
14.08.2016 20:51+2А вы уверены что это та самая Magenta а не другая?
a5b
15.08.2016 04:01+1Исходники той Magenta, что реализовывала Darwin 11 — https://github.com/christinaa/kernel_diff
В 2013 году автор объявил(а) о прекращении разработок http://crna.cc/cat/open-source
Magenta was my attempt at implementing a mach compatibility layer on top of the Linux kernel (this is NOT related to my work involving XNU). Unfortunately, I no longer develop this project, but old sources (as of the date of their publication) of major components of Magenta are still made available on my GitHub.
libSystem_and_linker — core system library responsible for libc routines, syscall handling and also doubling as the linker (dyld).
Kernel DIFF — a rather large diff file the needs to be applied to the Linux kernel to add the extensions for features like mach tasks, ports, IPC and BSD features like psycnh.
Fuchsia + Magenta — конечно же совсем другой проект, в котором от ядра Linux взяты лишь некоторые имена директорий (kernel/arch, kernel/lib, kernel/kernel) и "объектный стиль":
https://fuchsia.googlesource.com/magenta/+/master
beeruser
14.08.2016 22:18+4>> И ни слова о том, что Magenta — реализация Darwin поверх ядра Linux
Потому что это не так.
https://fuchsia.googlesource.com/magenta/+/HEAD/docs/mg_and_lk.md
LK is a Kernel designed for small systems typically used in embedded applications. It is good alternative to commercial offerings like FreeRTOS or ThreadX. Such systems often have a very limited amount of ram, a fixed set of peripherals and a bounded set of tasks.
Magenta inner constructs are based on LK but the layers above are new. For example, Magenta has the concept of a process but LK does not. However, a Magenta process is made of by LK-level constructs such as threads and memory.
Вообще Pink и Purple были коднеймами Taligent и iPhone соответственно
https://en.wikipedia.org/wiki/Taligent
http://www.wired.com/2012/08/forstall-talks-ingenuity-ui/
mbait
15.08.2016 06:38+1Бегло посмотрел качество кода (случайные файлы), создалось впечатление, что написан wannabe-kernel-developers, то есть людьми с опытом разработки в целом, но не опытом программирования, например, Linux. Возможно, просто неудачные файлы посмотрел. А вот за такое нас ещё в школьном кружке ругали.
Забавное наблюдение: в коде активно используются аттрибуты типа «weak» и «noreturn», но при этом освобождение ресурсов выполнено классической goto-лесенкой вместе аттрибута «cleanup», который давно поддерживается gcc и clang.qwerty135
15.08.2016 10:36Вооще-то там замечены Тревис Гейселбрехт и прочие такие… как бы сказать что у них общие представления, ну язык не повернётся.
mbait
15.08.2016 17:38+1Я оценивал код, а не авторов. Что касается авторства… создалось впечатление, что файлы понадёрганы из разных мест и написаны разными людьми. Во-первых, везде стоит первой строчкой
Copyright 2016 The Fuchsia Authors
Во-вторых, копирайт Тревиса датируется разными годами между 2008 и 2016, у некоторых файлов копирайт Гугла с разбросом дат 2013-2016. У Тревиса в резюме не отмечено, чтобы он когда-либо сотрудничал с Гуглом, как и нет упоминания данного проекта вообще.
qwerty135
16.08.2016 11:43Я так понимаю, они взяли за основу ядро NewOS, которое Тревис написал после краха Be.Inc. Наверно потому и копирайты старые, а всё что переделывается по новому, озаглавливается как вы сказали «Copyright 2016 The Fuchsia Authors».
Вобщем насчёт качества кода не знаю… но если появится ещё одна ОС, и не просто появится, а пойдёт в люди, это будет хорошо.a5b
16.08.2016 16:00Код Magenta и NewOS не совпадает (у NewOS еще более старые копирайты в нескольких файлах что я сравнил): https://fuchsia.googlesource.com/magenta/+/master/kernel/kernel/ https://github.com/travisg/newos/tree/master/kernel
ToSHiC
15.08.2016 15:27А «такое» — это то, что указатели с 0 сравниваются, или что item не проверяется? Если второе — то это несколько бессмысленно, т.к. это интрузивный список.
mbait
15.08.2016 17:20-2Там должно быть
return item->prev != 0 || item->next != 0;
Eсли, конечно,
trueиfalseне переопределены =)
jex
17.08.2016 14:09Посмотрите AOSP (android). Там такой ужас происходит… Считать репозитории гугла эталоном точно не стоит — это обычная комерческая компания, которой побыстрее нужно выйти на рынок.
huhen
15.08.2016 11:54-1Мне видится два варианта использования:
-Гугломобиль, там в некоторых системах необходим жесткий реалтайм.
-Носимые микрогаджеты, максимум это смарт смарт часы, а более вероятно «умная» одежда.
pengyou
15.08.2016 19:55Google опять разрабатывает очередной велосипед, но опытные ит-спецы не попадают в эту ловушку и не плодят никаких своих велосипедов и другим не советуют.
lanseg
Чтобы исключить бодания с ораклом и его джавой?
И ос реального времени будет всяко быстрее андроида.
daggert
>И ос реального времени будет всяко быстрее андроида.
Ну вы еще скажите что памяти меньше будет потреблять. От смены платформы — мозг у разработчиков не сменится. Будут так-же го*нокодить и подключать по 850 библиотек в один проект.
Meider1
Ну это можно так решить: разработчик пишет приложение, + исходник отправляет гуглю. А дальше коммисия либо аппрувят или посылают дальше учиться.
Disasm
С такими методами надо будет за аппрув платить и ждать неделями, комиссия же не резиновая.
vlreshet
Apple это не мешает. У них сейчас примерно так и есть — «за аппрув платить и ждать неделями».
Greendq
Но исходники пока не просят. :))
rzhikharevich
Зато UX оценивают (по крайней мере хочется надеяться :/).
mopsicus
Да ладно вам, сейчас апрув 2-3 дня максимум…
vlreshet
Может это зависит от типа приложения. Мы сабмитили бизнес-приложение — так больше месяца затянулся процесс.
powerscin
Вообще-то пару дней.
kex1k
Официальной информации по поводу «пары дней» до сих пор так и не поступило.
Как и до этого, в один момент, проверять стали в среднем за рабочую неделю.
Им никто не мешает снова вернуть пару недель если кому то покажется что качество приложенек значимо просело.
Oberon812
Смею напомнить, что у гугломаркета и так местами весьма специфические представления о «Разрешить. Иван Иванович» и «Не разрешить. Иван Иванович», а Вы хотите им на рецензию еще и код дать?
daggert
От чуть более строгой модерации будут плакать все разработчики и платформа будет аутсайдером. Тем более если на нее нет наработок (привет Windows Phone и Blackberry). Для захвата доли рынка отличной от 1% надо давать возможность простого конвертирования приложений, а это уже отменяет возможность премодерации кода.
saboteur_kiev
Этого не будет.
Во-первых не весь софт опенсорс.
Во-вторых никто не будет просматривать исходники — это дорого.
kolipass
А не надо его человеком просматривать: роботов обучить искать плохие подходы не проблема.
linakun
Это будет очень, очень не правильно, если «комиссия» людей будет каждое приложение рассматривать.
mrigi
Вы считаете надо в каждом проекте изобретать заново 850 велосипедов?
profesor08
Порой лучше написать одну-две функции, чем тянуть целый пакет. Конечно это дело вкуса, но простые вещи должны оставаться простыми.
Deosis
В идеале при подключении сторонней библиотеки, компилятор в манифесте пишет что-то вроде этого:
В сборке использовано 40% библиотеки А, 25% библиотеки Б и 10% библиотеки В. Естественно в пакете хранится только используемая часть.
При установке проходит проверка на уровень использования библиотек всеми уже установленными.
Если он превысит 100%, то закачивается и устанавливается библиотека целиком, а ранее установленные части дропаются.
Можно вообще обойтись без скачивания, если будет алгоритм, который из кусков соберет целую библиотеку.
0leGG
Это вы в нескольких строках описали как примерно работает ProGuard, который сейчас почти всегда используется при сборке Android-приложений
mrigi
Эти пару функций надо покрывать тестами и документацией для других участников проекта. В каком месте тут простота? Иногда да, можно написать, если так объективно выйдет лучше. Но я просто не понимаю что это за фобия на «пакеты».
igorch96
Приходится, из-за патентов…
mariner
вы на ноде пишете?
mrigi
Да, в том числе и на ноде. Но специализируюсь больше на C#.
NeoCode
Так чтобы исключить бодания с ораклом и джавой, нужно было бы разрабатывать язык программирования а не ОС.
Скорее всего просто ставят эксперименты. Компания богатая, может себе позволить.
sav13
Причем здесь ядро системы и Java?
Можно на любое ядро Яву навесить. Можно и под LINUX ядром без явы жить.
vangelfeld
вообще-то суд уже признал претензии Oracle безосновательными.
kahi4
1. Реального или не реального времени система не связаны с производительностью. Если программе, чтобы отрисовать себя, необходимо произвести 1000 операций, это не изменить.
2. Не зря пользовательские системы не реального времени. Никого не порадует в качестве основной системы что мягкого, что жесткого реального времени (не успела программа отрисовать пол экрана — плевать, убиваем процесс, будем надеяться, в следующий раз отрисует, ага).
3. ОС реального времени выглядят как… #include «task.h» // loading TASK subsystem from freeRTOS, мало кому понравится пересобирать систему, когда понадобится поставить стороннее приложение.
Bedal
ОС реального времени вообще не обязана быть быстрой. Она всего лишь обязана давать отклик за заданное время. Это сушественно разные вещи. И, если Вы скажете, что система с гарантированным откликом в 15 минут — не система реального времени, то Вы вообще не разбираетесь в реальном времени. Тем более, что заводить речь об ОС РВ в контексте этой статьи вообще странно.