Комментарии 49
Исследование показало, что выпущенная в августе операционная система HarmonyOS от Huawei уже в следующем году займет 2% рынка
А где исследование-то?
По ссылке сходил, там исследование не нашёл, только вот это:
a new report claims that the market share of HarmonyOS will reach 2 percent globally next year
Без ссылок на этот самый new report.
Нда… Мечтать не вредно
Не знаю, в Китае вполне может занять лидирующее место, а это уже не мало
Неа. Это очень мало. Что такое Китай? Это всего 1.5 млрд населения от 7. 20-25% рынка. И то — вместе с Индией.
Основная проблема — кто будет писать приложения под новую ось?
У Гугла с эпплом экосистемы для поддержки разработчиков, а у Хуавея?
По отзывам коллег из мобильщины, писать под китайскую аудиторию и особенно саппортить китайцев — так проще просто забить на этот рынок.
На некитайском рынке она нужна полутора гикам. Потому что не айфон и не андроид. Всё с иероглифами и вообще непонятно.
Основная проблема — кто будет писать приложения под новую ось?
У Гугла с эпплом экосистемы для поддержки разработчиков, а у Хуавея?
По отзывам коллег из мобильщины, писать под китайскую аудиторию и особенно саппортить китайцев — так проще просто забить на этот рынок.
На некитайском рынке она нужна полутора гикам. Потому что не айфон и не андроид. Всё с иероглифами и вообще непонятно.
Китайцы и будут писать?
Тут вон все от Диснея до NBA прогибаются аки пресмыкающиеся, лишь бы доступ к китайскому рынку не закрыли.
Китайский рынок — вещь в себе, и даже внутренние продукты себя очень неплохо чувствуют, а потом экспансия с кучей бабла… Сценарий отработанный, в общем.
Китайский рынок — вещь в себе, и даже внутренние продукты себя очень неплохо чувствуют, а потом экспансия с кучей бабла… Сценарий отработанный, в общем.
Пользуюсь на работе таблицами из бесплатного китайского офиса — работает очень быстро, ниразу не падало. Перешёл после того как libre не смог отсортировать большой csv.
Вопрос о оыночной доле. Да линукса продаётся мало, это правда. Но мы то знаем что дело не совсем в этом.
Мы можем считать количество активных установок…
Market share это не только продажи.
Market share это не только продажи.
Всё просто — достаточно не указать о каком рынке речь.
Вдруг речь о Горбушке идет.
PS. Автору поста не мешало бы пройти мастер-класс прожаривания заголовков у Ализара.
«Новая ОС скоро затмит мировых лидеров» или как-то так.
Вдруг речь о Горбушке идет.
PS. Автору поста не мешало бы пройти мастер-класс прожаривания заголовков у Ализара.
«Новая ОС скоро затмит мировых лидеров» или как-то так.
Честно говоря, я бы не смешивал ОС для ПК и для гаджетов.
Но то я, экспертам виднее.
Но то я, экспертам виднее.
НЛО прилетело и опубликовало эту надпись здесь
Что значит у Линукс меньше процента? Все сервера на линукс крутятся. Или речь про мобильные ос? Тогда откуда у Windows такие огромные проценты?
Или, судя по тому, что там макос речь идет о клиентских мобильных и полноценных ос?
Или линукса так мало, потому что учитывают только платные дистрибутивы? А как тогда оценивают аппле оси, которые сами по себе не продаются? И что новая harmony os будет доступна для установки на любых девайсах? Или она займет такую долю, сколько хуавей наклепает устройств с этой ос от общего количества?
Статья из раздела "опираясь на последние достижения мировых учёных все уже давно знают, что Земля плоская".
НЛО прилетело и опубликовало эту надпись здесь
В статье показывают данные statcounter, а те считают по веб-аналитике. Т.е. корректно было бы говорить о доле среди ОС, на которых пользуются браузерами.
А так-то, даже если не считать серверов, то и в пользовательских устройствах доля Линукса явно выше хотя бы за счёт домашних роутеров, точек доступа и пр.
А так-то, даже если не считать серверов, то и в пользовательских устройствах доля Линукса явно выше хотя бы за счёт домашних роутеров, точек доступа и пр.
Только почему то она называется LiteOS
github.com/Awesome-HarmonyOS/HarmonyOS
The underlying layer of HarmonyOS is composed of HarmonyOS microkernel, Linux kernel and Lite OS and it will become a complete HarmonyOS microkernel architecture in the future.
github.com/Awesome-HarmonyOS/HarmonyOS
В настоящее время ведущие позиции на рынке занимает Android с долей 39%
Linux же является пятой по величине операционной системой с долей 0,77%.
Взаимоисключающие параграфы?
Нет. Следствие победы оптимизма над здравым смыслом. В своё время было сломано много копий на тему GNU/Linux.
Оптимисты победили: GNU/Linux сегодня называется Linux. А всякие Android, ChromeOS и прочие — так то не Linux, а Android, ChromeOS, HarmonyOS и так далее. И неважно — какое там у них ядро.
Бойтесь своих желаний — они иногда сбываются…
Оптимисты победили: GNU/Linux сегодня называется Linux. А всякие Android, ChromeOS и прочие — так то не Linux, а Android, ChromeOS, HarmonyOS и так далее. И неважно — какое там у них ядро.
Бойтесь своих желаний — они иногда сбываются…
НЛО прилетело и опубликовало эту надпись здесь
Не могут. Вот Microsoft попробовал — в результате пришлось-таки ядро Linux тянуть.
Hyrum's Law в действии.
Особенно если учесть, что в ChromeOS (в отличие от Windows) бегают и GUI программы из GNU/Linux тоже.
То есть в Google Fuchsia я верю в том смысле, что вокруг неё будет много шума… а потом поверх водрузят Linux — и в таком виде «народ схавает» (ну как MacOS: взяли микроядро, водрузили сверху BSD Unix — и получили «микроядерную операционку»).
А вот чего-то другое — уже будет сделать затруднительно.
Hyrum's Law в действии.
Особенно если учесть, что в ChromeOS (в отличие от Windows) бегают и GUI программы из GNU/Linux тоже.
То есть в Google Fuchsia я верю в том смысле, что вокруг неё будет много шума… а потом поверх водрузят Linux — и в таком виде «народ схавает» (ну как MacOS: взяли микроядро, водрузили сверху BSD Unix — и получили «микроядерную операционку»).
А вот чего-то другое — уже будет сделать затруднительно.
в Google Fuchsia я верю в том смысле, что вокруг неё будет много шума… а потом поверх водрузят Linux
А зачем? Fuchsia проектируется как замена Android. У которого zygote вместо init-а, и bionic вместо stdlibc. Сопцна, там stdlibc и binder поддержать (может быть что-то еще NDK-специфичное), и андроидовский middleware переедет. Особенно, если его как 9-ю джаву подробят на модули, что немаловероятно с учетом желания Google заехать и в IoT с их Things.
А зачем?Не зачем, а «почему». Потому что Гугле умные люди работают. И гробить свою платформу в угоду теоретикам (как это сделал Microsoft) — там не будут.
У которого zygote вместо init-аЕсли бы zygote там была вместо init-а, то когда
adb shell killall zygote во время отладки приводила бы к совсем другим эффектам. Но это к слову.Сопцна, там stdlibc и binder поддержать (может быть что-то еще NDK-специфичное), и андроидовский middleware переедет.Уже пробовали. ARC Welder, ARChon… не работает.
Особенно, если его как 9-ю джаву подробят на модули, что немаловероятно с учетом желания Google заехать и в IoT с их Things.Они могут подробить что угодно и как угодно. Но факт остаётся фактом: чтобы программы работали — им придётся ядро линукса поверх этого водрузить.
Собственно работа в этом направлении, похоже, уже идёт. И Android приложения и Linux приложения сейчас пускаются не в контейнере, а в полноценной виртуалке.
И вот в то, что внешнее ядро они смогут на что что-то заменить — я, в общем, верю… а вот «внутреннее»… извините — но нет.
Но факт остаётся фактом: чтобы программы работали — им придётся ядро линукса поверх этого водрузить.
Нет.
И вот в то, что внешнее ядро они смогут на что что-то заменить — я, в общем, верю… а вот «внутреннее»… извините — но нет.
Нет «внешнего» и «внутреннего» ядер.
Есть ядро, которое предоставляет системный API для порождения процессов, доступа к драйверам, и т.п.
Есть стандартная библиотека, которая скрывает и абстрагирует системный API в компилируемом языке типа C/C++.
Сопцна, вопрос переезда с одного ядра на другое — это вопрос смены «прокладок» от функций стандартной библиотеки к API ядра.
Уже пробовали. ARC Welder, ARChon… не работает.
Работает же, ну. И в хромоси Linux-приложения работают без всяких виртуалок, потому что ChromeOS — это ubuntu.
Увы, но таки да.Но факт остаётся фактом: чтобы программы работали — им придётся ядро линукса поверх этого водрузить.Нет.
Таки есть. Когда вы пакеты для Debian ставите — вы работаете с полноценной виртуальной машиной. А не с контейнером. И то же самое планируется делать с Android'ом. Это уже решённый вопрос — только пока неясно когда. Но процесс уже идёт.И вот в то, что внешнее ядро они смогут на что что-то заменить — я, в общем, верю… а вот «внутреннее»… извините — но нет.Нет «внешнего» и «внутреннего» ядер.
Есть стандартная библиотека, которая скрывает и абстрагирует системный API в компилируемом языке типа C/C++.Нет такой библиотеки в природе. И быть не может. Любая программа может спокойно вызывать системные вызовы ядра. Более того — некоторые программы свою «личную» системную билиотеку тянут. И тогда через bionic не ходит ничего (крому нескольких функций на Java).
А есть программы, которые просто статические бинарники в APK'шке приносят и их вызывают.
Сопцна, вопрос переезда с одного ядра на другое — это вопрос смены «прокладок» от функций стандартной библиотеки к API ядра.В теории нет разницы между теорией и практикой. А на практике есть.
Простая, блин, истина, которую вы никак не хотите понять.
Люди разрабатывавшие поддержку Android для ChromeOS с вашей великолепной теории начали (я выше ссылку давал). Не взлетело. Вот совсем-совсем не взлетело.
Следующий этап — контейнеры. Стало получше… но всё равно — ядро на ChromeOS и Android последней версии — разные. Сейчас вот виртуалку пилят, чтобы ядро было той же версии (sic!).
А вы предагалаете его на что-то другое заменить. Не взлетит.
То, что попытаются заменить — могу поверить. Что заработает — нет.
И в хромоси Linux-приложения работают без всяких виртуалок, потому что ChromeOS — это ubuntu.Слушайте, а может не стоит спорить о вкусе устриц с теми, кто их ел?
Вот вам скриншот с экрана моего Pixelbook'а
Не объясните — как так получилось, что в CroSh — ядро 4.4.186, а в Linux на том же самом Pixelbook'е — 4.19.60? Думаете там хитрозадое ядро — двуликий янус? Нет. И об этом все людям, которые знают о том, как CromeOS устроена прекрасно известно. Как и о том, что она на основе Gentoo построена, а к Ubuntu вообще никакого отношения не имеет (иначе официальная дока не включала в себя кучу ссылок на доку из Gentoo «в подвале»).
Вывод uname в данном случае ничего не говорит кроме того, что в одной консоли якобы 4.19, а во второй — 4.4. lscpu покажите, пожалуйста с флажками — тогда поверю.
Там английским по белому написано «мы используем portage от Gentoo, вот доки если что». Там нигде не написано, что хромось — это дериватив Gentoo.
Когда я ставлю пакеты Debian в Debian — я имею дело с хостовой системой, запущенной непосредственно на железе, ровно таким же образом работает Android поверх ядра Linux.
Жеваный крот. а glibc — это что? a stdlibc++ (или как оно там правильно)? а? если такой библиотеки нет и быть не может — расскажите мне тупенькому, как исходники для *nix компилируются в win32 PE в окружении mingw, который совсем не Linux?
И как после этого скомпиленные из никсовых исходников бинарники работают на NTKernel-based оси?
Может. Но зачем? Дублировать слой абстракции от системы?
С разморозкой, это называется статическая компиляция. И это никак не противоречит концепции системной библиотеки.
Даааа, конечно. Он же просто так лежит, для красоты.
Вы б жизненный цикл процесса в android погуглили что ли.
Может вы что-то делали не так, а не у людей не взлетело? Ядро под android из критичного содержит только binder, которого нет в стоковом.
Можно перекомпилировать ядро с патчем на binder, можно упороться и скомпилировать binder в виде ядерного модуля, можно переписать libbinder на userspace. В общем, ничего там магического и страшного нету, как я говорил.
Регрессии гонять — долго, да. Отлаживать на реальных устройствах. Поэтому рефакторинг андрюши в фуксию — это вытащить то, что было прибито гвоздями к Linux-ядру на слой совместимости.
она на основе Gentoo построена, а к Ubuntu вообще никакого отношения не имеет (иначе официальная дока не включала в себя кучу ссылок на доку из Gentoo «в подвале»).
Там английским по белому написано «мы используем portage от Gentoo, вот доки если что». Там нигде не написано, что хромось — это дериватив Gentoo.
Таки есть. Когда вы пакеты для Debian ставите — вы работаете с полноценной виртуальной машиной.
Когда я ставлю пакеты Debian в Debian — я имею дело с хостовой системой, запущенной непосредственно на железе, ровно таким же образом работает Android поверх ядра Linux.
Нет такой библиотеки в природе. И быть не может.
Жеваный крот. а glibc — это что? a stdlibc++ (или как оно там правильно)? а? если такой библиотеки нет и быть не может — расскажите мне тупенькому, как исходники для *nix компилируются в win32 PE в окружении mingw, который совсем не Linux?
И как после этого скомпиленные из никсовых исходников бинарники работают на NTKernel-based оси?
Любая программа может спокойно вызывать системные вызовы ядра.
Может. Но зачем? Дублировать слой абстракции от системы?
Более того — некоторые программы свою «личную» системную билиотеку тянут.
С разморозкой, это называется статическая компиляция. И это никак не противоречит концепции системной библиотеки.
И тогда через bionic не ходит ничего (крому нескольких функций на Java).
Даааа, конечно. Он же просто так лежит, для красоты.
Вы б жизненный цикл процесса в android погуглили что ли.
Люди разрабатывавшие поддержку Android для ChromeOS с вашей великолепной теории начали (я выше ссылку давал). Не взлетело. Вот совсем-совсем не взлетело.
Может вы что-то делали не так, а не у людей не взлетело? Ядро под android из критичного содержит только binder, которого нет в стоковом.
Можно перекомпилировать ядро с патчем на binder, можно упороться и скомпилировать binder в виде ядерного модуля, можно переписать libbinder на userspace. В общем, ничего там магического и страшного нету, как я говорил.
Регрессии гонять — долго, да. Отлаживать на реальных устройствах. Поэтому рефакторинг андрюши в фуксию — это вытащить то, что было прибито гвоздями к Linux-ядру на слой совместимости.
Вывод uname в данном случае ничего не говорит кроме того, что в одной консоли якобы 4.19, а во второй — 4.4. lscpu покажите, пожалуйста с флажками — тогда поверю.Какие, нафиг, вам флажки нужны? В одной консоли открыт CroSh, в другой — консоль Linux из ChromeOS. lscpu можно только в консоли Linux сделать, в CroSh очень мало команд поддерживается, это всё-таки диагностическое средство в первую очередь.
Там английским по белому написано «мы используем portage от Gentoo, вот доки если что». Там нигде не написано, что хромось — это дериватив Gentoo.А чем, собственно, Debian от Gentoo отличается, вы в курсе? Что это у вас за Ubuntu такая без Dpkg, но с Portage?
Когда я ставлю пакеты Debian в Debian — я имею дело с хостовой системой, запущенной непосредственно на железе.Когда вы ставите пакеты для Debian в Debian — да, когда вы ставите пакеты для Debian в ChromeOS — нет.
Причём тут вообще Debian на голом железе? Его Google не разрабывает и не продаёт.
ровно таким же образом работает Android поверх ядра Linux.Опять-таки: в случае с телефоном — да, в случае с ChromeOS — нет.
если такой библиотеки нет и быть не может — расскажите мне тупенькому, как исходники для *nix компилируются в win32 PE в окружении mingw, который совсем не Linux?И никак не компилируются. Если нет достаточного количества
#ifdef'ов — то и нет у вас пакета под mingw. Сравните хотя бы количество пакетов в mingw и в Debian — и подумайте почему так.И как после этого скомпиленные из никсовых исходников бинарники работают на NTKernel-based оси?С трудом. Куча фич не поддерживается в этом случае, даже если программа как-то, в принципе, собирается. А если вы захотите поддерживать что-то без перекомпиляции… про то, что и Microsoft, тоже, в конце-концов отказался от эмуляции и взял ядро Linux как оно есть — я уже писал…
И это никак не противоречит концепции системной библиотеки.Противоречит. Если у вас программа слинкована со своей libc — то и всё, вы можете в вашей системой библиотеке делать что угодно… а программа будет ходить напрямую в ядро.
Может. Но зачем? Дублировать слой абстракции от системы?Понятия не имею. Вы это у разработчиков спросите. Но то, что они это делают, и довольно часто — это просто факт. К нему можно по разному относиться, но это уже неважно: программы ходят напрямую в ядро — и вы ничего с этим не можете поделать. Даже в Windows есть такие программы, но так как там с этим делом идёт война (каждый релиз перенумеровывает все системные вызовы), то таких программ меньше. Но они есть всё равно.
Вы б жизненный цикл процесса в android погуглили что ли.Вы это человеку, который каждый день этот процесс в GDB наблюдает говорите? Тот же Skype год назад точно имел вторую копию системной библиотеки. Нафига она ему — понятия не имею. Но у нас из-за этого возникают определённые проблемы… вернее возникали — сейчас мы Skype просто вычеркнули из списка. Но Гугл не может сам для себя решать — что ему поддерживать, чего не стоит…
Может вы что-то делали не так, а не у людей не взлетело?Если бы взлетело — то они, наверное, за пять лет обновили бы версию Android'а… вы так не думаете? В ARC Welder по прежнему KitKat…
В общем, ничего там магического и страшного нету, как я говорил.Говорить — всякий может. Вы сделать попробуйте. У Гугла — не получилось. У вас — может получится, я не знаю.
Если получится — можете попробовать продать вашу реализацию в Google. Тогда, может из Fuchsia и выйдет…
Если у вас программа слинкована со своей libc — то и всё, вы можете в вашей системой библиотеке делать что угодно… а программа будет ходить напрямую в ядро.
Нет. Стектрейс посмотрите. В ядро ходит системная библиотека.
Даже в Windows есть такие программы, но так как там с этим делом идёт война (каждый релиз перенумеровывает все системные вызовы), то таких программ меньше. Но они есть всё равно.
Таких — очень мало. В самом минимальном случае такая программа линкуется лишь с ntdll.dll.
Если бы взлетело — то они, наверное, за пять лет обновили бы версию Android'а… вы так не думаете?
Нет, не думаю. Там в API менялось довольно мало.
Вы это человеку, который каждый день этот процесс в GDB наблюдает говорите?
Ну судя по хромоси — да. Или вы в хромоси под Android разрабатываете? Тогда сильно вам сочувствую.
Вы сделать попробуйте. У Гугла — не получилось.
Так Гугл нигде не говорил что фуксия отменяется, и не взлетело. Пилят. Так что получилось/не получилось — рано обсуждать.
Это теория. А на практике — никто не помешает вам вызвать SVC (или SYSENTER) и работать с ядром напрямую.Если у вас программа слинкована со своей libc — то и всё, вы можете в вашей системой библиотеке делать что угодно… а программа будет ходить напрямую в ядро.Нет. Стектрейс посмотрите. В ядро ходит системная библиотека.
В самом минимальном случае такая программа линкуется лишь с ntdll.dll.В Windows просто выбора нет. Так как для того, чтобы посмотреть таблицу системных вызовов нужно как-то же сходить в ядро… а как это сделать, если вы ещё ни одного номера syscall'а не нашли?
Достаточно для того, чтобы куча программ не работали на KitKat. Да и про то, что от ARC Google отказался говорилось почти публично. Вот тут например — ARC++ чётко позиционируется как замена, а не альтернатива.Если бы взлетело — то они, наверное, за пять лет обновили бы версию Android'а… вы так не думаете?Нет, не думаю. Там в API менялось довольно мало.
Или вы в хромоси под Android разрабатываете? Тогда сильно вам сочувствую.Если бы я разрабатывал под Андроид — то ещё бы как-то можно было бы. Но, увы, я разрабатываю Андроид (один из форков)… тут ChromeOS пасует.
Pixelbook — это лёгкий ноут у меня, разработку можно только на десктопе вести… и да — это напрягает.
Так что получилось/не получилось — рано обсуждать.Уже нет. Что там будет с фуксией — да, тут пока не всё ясно. Я говорил про попытку заменить в Android'е ядро. Вот от этого — уже отказались. Ну как отказались: пока ещё контейнер импользуется и то ядро, что в самой системе. Но, думаю, это временно. Скорее всего сделают как и с GNU/Linux-приложениями: отдельное ядро, VM, всё как положено.
Скорее всего сделают как и с GNU/Linux-приложениями: отдельное ядро, VM
И где отдельное ядро и VM в Android?
В Windows просто выбора нет. Так как для того, чтобы посмотреть таблицу системных вызовов нужно как-то же сходить в ядро
Не надо ничего смотреть. Есть ntdll, есть экспорты из нее. Они смаплены на соответствующие syscall numbers. Прямые вызовы в ядро — это стрельба в ногу.
Нормальная программа пользуется системной библиотекой — ntdll/glibc/whatever
Я говорил про попытку заменить в Android'е ядро. Вот от этого — уже отказались
Пруфцы?
НЛО прилетело и опубликовало эту надпись здесь
macOS, опять-же, без Linux (и без Unix) обходятся.
Макосовское ядро XNU это всётаки потомок BSD, хотя и смешанный с Match
так что это всётаки правнук юникса
НЛО прилетело и опубликовало эту надпись здесь
Расщифровываться оно может как угодно. А насчёт правнука… там классическая история с Кораблём Тесея: XNU была сделана из BSD 4.3, а BSD 4.3 — таки из Unix. потому там вроде нет ни строчки кода от AT&T, но история чётко прослеживается.
НЛО прилетело и опубликовало эту надпись здесь
частично совмещенное с частью кода BSD, да
Хотя бы википению почитали, блин. XNU — это Mach плюс пристроенное сверху ядро BSD.
Причём толку в этой конструкции — ровно нуль, так как идея микроядра — в том, что настоящее ядро будет состоять из отдельных компонент, которые будут общаться через микроядро.
А в XNU — вся безопасность как раз в монолитном ядре поверх Mach.
В результате получаем чудный гибрид, удачно сочетающий недостатки микроядер (тормоза, повышенный расход памяти и прочее) и монолита (отсутствие защиты компонентов ядра друг от друга и прочее).
Причём толку в этой конструкции — ровно нуль, так как идея микроядра — в том, что настоящее ядро будет состоять из отдельных компонент, которые будут общаться через микроядро.
А в XNU — вся безопасность как раз в монолитном ядре поверх Mach.
В результате получаем чудный гибрид, удачно сочетающий недостатки микроядер (тормоза, повышенный расход памяти и прочее) и монолита (отсутствие защиты компонентов ядра друг от друга и прочее).
Я не про Linux. Я про MacOS. Там есть микроядро Mach. А поверх него — один процесс — полное ядро BSD Unix. А «сверху» — уже всё остальное.взяли микроядро, водрузили сверху BSD UnixЭэ, вообще-то Linux — это и есть ядро, все эти стандартные системные утилиты UNIX и POSIX ещё задолго до ядра Торвальдса существовали.
Офигительный дизайн, да.
Вот и Fuchsia, скорее всего, этим кончит.
НЛО прилетело и опубликовало эту надпись здесь
Один из процессов*:Он может быть «один из», но если он умирает — то ни одна программа не может работать в принципе. Так как и файловые системы и процессы и сигналы — всё это живёт именно там. По вашей же ссылке написано.
Фактически — это монолитное ядро из которого вынесена часть компонент. Linux тоже так умеет: FUSE и прочее.
Что вы так пессимистичны-то: с 70х какой-никакой прогресс в архитектуре ОС всё-же был.Количественный был, качественный… скорее нет. Единственная ОС, в корне отличающаяся от Unix — это Windows. И не могу сказать, что это такой уж большой шаг вперёд.
НЛО прилетело и опубликовало эту надпись здесь
Нуу, есть ещё как минимум QNX, OS/2, z/OS, VxWorks, Haiku и тд.Вы ещё Amoeba и Oberon с Palm OS вспомните.
Речь же не о том, что никто ничего не делал… просто не прижилось.
UNIX далеко не верх эволюции в плане стабильности, скорости и удобства использования.Согласен — тем не менее остальные OS приходят и уходят, а UNIX — остаётся.
Так как 99,99% пользователей Андроид рут-доступ не получают (не умеют, не нужно, боятся потери гарантии и т.п.) то считать это Линуксом наверное (ИМХО) неправильно.
Я чего те не понимаю, а разве Android не построен на ядре Linux?
На Linux подняли java машину и все, вот и готов Android — разве не так?
На Linux подняли java машину и все, вот и готов Android — разве не так?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HarmonyOS к 2020 году спрогнозировали пятое место на рынке ОС с долей 2%