Pull to refresh

Comments 53

Чтобы исключить бодания с ораклом и его джавой?
И ос реального времени будет всяко быстрее андроида.
>И ос реального времени будет всяко быстрее андроида.
Ну вы еще скажите что памяти меньше будет потреблять. От смены платформы — мозг у разработчиков не сменится. Будут так-же го*нокодить и подключать по 850 библиотек в один проект.
Ну это можно так решить: разработчик пишет приложение, + исходник отправляет гуглю. А дальше коммисия либо аппрувят или посылают дальше учиться.
С такими методами надо будет за аппрув платить и ждать неделями, комиссия же не резиновая.
UFO just landed and posted this here
Но исходники пока не просят. :))
Зато UX оценивают (по крайней мере хочется надеяться :/).
Да ладно вам, сейчас апрув 2-3 дня максимум…
UFO just landed and posted this here
Официальной информации по поводу «пары дней» до сих пор так и не поступило.
Как и до этого, в один момент, проверять стали в среднем за рабочую неделю.
Им никто не мешает снова вернуть пару недель если кому то покажется что качество приложенек значимо просело.
Смею напомнить, что у гугломаркета и так местами весьма специфические представления о «Разрешить. Иван Иванович» и «Не разрешить. Иван Иванович», а Вы хотите им на рецензию еще и код дать?
От чуть более строгой модерации будут плакать все разработчики и платформа будет аутсайдером. Тем более если на нее нет наработок (привет Windows Phone и Blackberry). Для захвата доли рынка отличной от 1% надо давать возможность простого конвертирования приложений, а это уже отменяет возможность премодерации кода.
Этого не будет.
Во-первых не весь софт опенсорс.
Во-вторых никто не будет просматривать исходники — это дорого.
А не надо его человеком просматривать: роботов обучить искать плохие подходы не проблема.
Это будет очень, очень не правильно, если «комиссия» людей будет каждое приложение рассматривать.
Вы считаете надо в каждом проекте изобретать заново 850 велосипедов?
Порой лучше написать одну-две функции, чем тянуть целый пакет. Конечно это дело вкуса, но простые вещи должны оставаться простыми.

В идеале при подключении сторонней библиотеки, компилятор в манифесте пишет что-то вроде этого:
В сборке использовано 40% библиотеки А, 25% библиотеки Б и 10% библиотеки В. Естественно в пакете хранится только используемая часть.
При установке проходит проверка на уровень использования библиотек всеми уже установленными.
Если он превысит 100%, то закачивается и устанавливается библиотека целиком, а ранее установленные части дропаются.
Можно вообще обойтись без скачивания, если будет алгоритм, который из кусков соберет целую библиотеку.

Это вы в нескольких строках описали как примерно работает ProGuard, который сейчас почти всегда используется при сборке Android-приложений
Эти пару функций надо покрывать тестами и документацией для других участников проекта. В каком месте тут простота? Иногда да, можно написать, если так объективно выйдет лучше. Но я просто не понимаю что это за фобия на «пакеты».
Приходится, из-за патентов…
Да, в том числе и на ноде. Но специализируюсь больше на C#.
Так чтобы исключить бодания с ораклом и джавой, нужно было бы разрабатывать язык программирования а не ОС.
Скорее всего просто ставят эксперименты. Компания богатая, может себе позволить.
Причем здесь ядро системы и Java?
Можно на любое ядро Яву навесить. Можно и под LINUX ядром без явы жить.
вообще-то суд уже признал претензии Oracle безосновательными.
1. Реального или не реального времени система не связаны с производительностью. Если программе, чтобы отрисовать себя, необходимо произвести 1000 операций, это не изменить.
2. Не зря пользовательские системы не реального времени. Никого не порадует в качестве основной системы что мягкого, что жесткого реального времени (не успела программа отрисовать пол экрана — плевать, убиваем процесс, будем надеяться, в следующий раз отрисует, ага).
3. ОС реального времени выглядят как… #include «task.h» // loading TASK subsystem from freeRTOS, мало кому понравится пересобирать систему, когда понадобится поставить стороннее приложение.
ОС реального времени вообще не обязана быть быстрой. Она всего лишь обязана давать отклик за заданное время. Это сушественно разные вещи. И, если Вы скажете, что система с гарантированным откликом в 15 минут — не система реального времени, то Вы вообще не разбираетесь в реальном времени. Тем более, что заводить речь об ОС РВ в контексте этой статьи вообще странно.
Сейчас тренд на IoT, ну и делают видать легкую ос, хотя хуавей тоже уже слабал подобную.
И ни слова о том, что Magenta — реализация Darwin поверх ядра Linux, имеющая бинарную совместимость с iOS. На эту тему была статья от 2012-ого тут же — https://habrahabr.ru/post/145643/. Если они сюда прикрутят стек Android и замену проприетарным либам iOS, то Apple не позавидуешь.
Смысл? приложения и AppStore все равно не запустить
А может быть тут есть какая-то связь со Swift? Т.е. разработчик пишет на одном языке апп, и потом публикует его во все сторы.
Да но для этого не нужно Darwin переносит, Swift открытый, сделай чтоб он работал у тебя и все. Но UI и многие компоненты все равно будут работать тока под iOS…
С учетом различий паттернов UX/UI, нормально не получится.
А вы уверены что это та самая Magenta а не другая?

Исходники той 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

>> И ни слова о том, что 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/

Мне кажется, что это — их ответ майкрософтовской Win10 IoT.

Бегло посмотрел качество кода (случайные файлы), создалось впечатление, что написан wannabe-kernel-developers, то есть людьми с опытом разработки в целом, но не опытом программирования, например, Linux. Возможно, просто неудачные файлы посмотрел. А вот за такое нас ещё в школьном кружке ругали.

Забавное наблюдение: в коде активно используются аттрибуты типа «weak» и «noreturn», но при этом освобождение ресурсов выполнено классической goto-лесенкой вместе аттрибута «cleanup», который давно поддерживается gcc и clang.
Вооще-то там замечены Тревис Гейселбрехт и прочие такие… как бы сказать что у них общие представления, ну язык не повернётся.

Я оценивал код, а не авторов. Что касается авторства… создалось впечатление, что файлы понадёрганы из разных мест и написаны разными людьми. Во-первых, везде стоит первой строчкой


Copyright 2016 The Fuchsia Authors

Во-вторых, копирайт Тревиса датируется разными годами между 2008 и 2016, у некоторых файлов копирайт Гугла с разбросом дат 2013-2016. У Тревиса в резюме не отмечено, чтобы он когда-либо сотрудничал с Гуглом, как и нет упоминания данного проекта вообще.

Я так понимаю, они взяли за основу ядро NewOS, которое Тревис написал после краха Be.Inc. Наверно потому и копирайты старые, а всё что переделывается по новому, озаглавливается как вы сказали «Copyright 2016 The Fuchsia Authors».
Вобщем насчёт качества кода не знаю… но если появится ещё одна ОС, и не просто появится, а пойдёт в люди, это будет хорошо.
А «такое» — это то, что указатели с 0 сравниваются, или что item не проверяется? Если второе — то это несколько бессмысленно, т.к. это интрузивный список.

Там должно быть


return item->prev != 0 || item->next != 0;

Eсли, конечно, true и false не переопределены =)

Ну это уже coding style, как мне кажется.
Писать 3 лишние строки (а почему тогда ещё 4 не добавить со скобками?) не выглядит хорошим coding style.
А что плохого в 40 строке?
Посмотрите AOSP (android). Там такой ужас происходит… Считать репозитории гугла эталоном точно не стоит — это обычная комерческая компания, которой побыстрее нужно выйти на рынок.
Мне видится два варианта использования:
-Гугломобиль, там в некоторых системах необходим жесткий реалтайм.
-Носимые микрогаджеты, максимум это смарт смарт часы, а более вероятно «умная» одежда.
Google разрабатывает новую соцсеть Google+, но никто не знает, зачем
Google опять разрабатывает очередной велосипед, но опытные ит-спецы не попадают в эту ловушку и не плодят никаких своих велосипедов и другим не советуют.
Only those users with full accounts are able to leave comments. Log in, please.