Изменения

Гугл — лицемеры. Говорить чтоЭтот пост я начал писать ещё 28 октября 2013 года :-то о свободном ПО в то время, как делаете такой огороженный и несовместимый с обычным linux’ом андроид — аморально.)

* Модульность и пакетная организация системы, как в любом нормальном linux’е. Возможность обновления по кускам.* Встроенные В ЛЮБУЮ СИСТЕМУ ВСЕГДА ДОСТУПНЫЕ root права для пользователя. Любые способы «защиты телефона от пользователя» (например, selinux) должны быть ОТКЛЮЧАЕМЫМИ.* Отсутствие DRM. Ну не было бы без DRM фильмов в play — И НЕ НАДО. Каждый, кто делает DRM — проприетарная сволочь, и А возвращаюсь я бы предпочёлк нему каждый раз, если бы этих людей не стало (как Столлман сказал про Джобса — я не рад, что он умер, но я рад, что его больше нет).* Работа когда думаю об обновлении прошивки на стандартном ядре Linuxтелефоне, отсутствие костылей типа binder’а задумываюсь об устройстве Андроида и «зиготы»испытываю по этому поводу сильный рвотный рефлекс. Вместо первого — сокетыНу почему там внутри такое уродство? Зачем лицемерный гугл, вместо второго — dalvik assembly (которые надо было бы, конечно, сначала запилить, чтобы они работали).* Лицензия GPLv3 на всю систему вместо текущей Apache! Причём, вреда бы это не принесло никакого, а наоборот — уменьшило бы фрагментацию, потому болтающий что производители вынуждены были бы открывать свои идиотские костыльные доработки типа изменённых интерфейсов и прочего-то об опенсорсе, и их было бы гораздо легче поддерживать и обновлять. И это бы позволило изначально использовать нормальные linux’овые компонентыделает его таким монолитным, например, busybox неудобным для ковыряния и нормальный uclibc вместо bionic.по факту закрытым?

Дальше Короче, вот каким бы, по-моему, мог быть ПРАВИЛЬНЫЙ андроид:* Первое, что должно быть — модульность и пакетная организация системы, как в любом нормальном linux’е. Возможность обновления '''системной части''' по кускам или установки различных версий интерфейса: захотел — воткнул TouchWiz, захотел — воткнул гугловскую оболочку, захотел — MIUI, захотел — от Sony… без извращений со скачиванием идиотских «Zver Edition» сборок с бестолковых файлообменников. Без сбросов, без бэкапов. Опять-таки, как в любом нормальном linux’е!!!* Вот эту фичу, кстати, в последнем андроиде почти реализовали: возможность выбора конкретных разрешений, предоставляемых приложениям, при установке, вместо безальтернативного «согласиться». «Почти» реализовали потому, что вроде-как возможности отрубить приложению доступ в интернет всё равно нет.* Работать оно должно на стандартном ядре Linux, без костылей типа binder’а, «зиготы», эмуляции регистронезависимой ФС через fuse… Вместо первого — нужна тоненькая обёртка над банальными unix сокетами, вместо второго (с целью экономии памяти) — assembly, то есть «разделяемые библиотеки» на dalvik’е — насколько я понимаю, это есть в .NET, нужно было бы запилить аналогично.* С учётом выпиленной зиготы запуск приложений тоже надо делать нормально — не через intent и вызов activity, а запуском обычного процесса. Тут конечно будут нюансы с обеспечением запуска под нужным юзером, но всё равно всё решаемо.* GUI фреймворк делать надо так, чтобы его можно было использовать из любых языков, а не только из управляемого кода на яве! Самый очевидный способ сделать это — написать его на C/C++, а не на управляемой яве/далвике. Менее очевидный способ — как-то умудриться предоставить API с помощью Assembly, см. предыдущий пункт (тем более что AOT компиляция в андроиде уже другая фантазияесть). Также очень полезна была бы возможность замены UI фреймворка на другой (хоть Qt, хоть GTK, если захочется), без создания дополнительной прослойки.* Естественно, обязательна поддержка usb mass storage (выпиленного в 4-ом андроиде каким-то идиотом), хоть даже напрямую в ext4, чтобы мелкософт своим убогим патентом на FAT32 LFN не потрясывал.* Коли уж APK приложения не имеют зависимостей, вполне нормально было бы поддержать установку приложений '''вместе с данными''' в собственный каталог или раздел, не затрагиваемый при обновлении системы, а также поддержать произвольное разбиение диска. Чтобы на флешке при этом не копилась дикая свалка разнородного мусора, оставляемого приложениями — запись в другие директории разрешать только после подтверждения пользователем. При сносе приложений данные '''не удалять'''! Ибо они — собственность пользователя, а не приложения, и, соответственно, пользователь должен иметь к ним доступ. Бывает, конечно, всякий мусор типа кэша webview, но его просто нужно складывать отдельно, да и всё.* Root права для пользователя должны быть доступны ВСЕГДА! Телефон и вообще софт должен защищать пользователя, а не ЗАЩИЩАТЬСЯ ОТ пользователя. То есть все selinux’ы и прочее фуфло должно быть либо отключаемым, либо реализовано так, чтобы пользователь всегда имел доступ ко ВСЕЙ системе.* DRM, разумеется, быть не должно, в частности потому, что при наличии рута (который в итоге-то всё равно всем доступен) он всё равно БЕСПОЛЕЗЕН. На половые проблемы проприерастов, занимающихся продажей приложений (и фильмов, и прочего), мне в целом положить, но если уж им очень хочется, пусть делают свою защиту через привязку к серверу — способ вполне адекватный для смартфонов: скрестить какойуже сейчас нехилая часть приложений — тупо UI для чего-нибудь декларативный язык описания UI . Ну, калькуляторы продавать, конечно, уже не получится — НУ ТАК И НЕ ХРЕН. Ну не будет фильмов в маркете — тоже мне потеря. Всегда мечтал смотреть фильмы за деньги на 5" экране мобилы. Через мобильный интернет, ага. Всегда мечтал.* Маркет должен быть более ориентирован на интеграцию с JS процессом разработки приложения: пусть там будет багтрекер, исходники в git, wiki, история версий, информация о лицензии, документация… Ну или просто интеграция с github’ом.* НОРМАЛЬНАЯ опенсорсность самой системы. Сейчас андроид под лицензией Apache, в официальном репозитории поддерживается только для nexus’ов, и загрузкой из вебаэто создаёт огромные неудобства — каждый производитель городит свою закрытую оболочку со своими патчами, своим закрытым загрузчиком, своей системой обновления прошивки, да что там системой обновления… зачастую вообще без обновлений! Чтобы такого не было, нужно либо поменять лицензию на GPLv3 и вынудить производителей открывать все доработки, либо просто административным ресурсом загнать всех в ОДИН общий репозиторий, в котором и поддерживать. По сути, всё должно разрабатываться как CyanogenMod — система общая, а для разных девайсов различаются только специфичные части. Ещё лучше, если сделать и лицензию нормальную (GPLv3), и загнать всех в общий репозиторий. И поддерживать было бы проще, и обновлялись бы все охотно, и «фрагментации» бы пресловутой не было, и можно было бы изначально использовать нормальные компоненты, например, busybox и нормальный uclibc вместо bionic.

Типа «html5» приложение с P.S: Ещё есть идея по поводу кроссплатформенных HTML/JSприложений — так как их очевидная проблема это непосредственно сам HTML, но вместо HTML — QML с его reflow’ами и отсутствием нативных контролов — нужно просто придумать другой нормальный скриптуемый язык описания интерфейсов (там JS уже какой-то естьпричём без особой специфики, с другой стороны это не XMLчтобы можно было его сделать кроссплатформенным), ну или . Типа как стандартный андроидовский язык (XMLописания интерфейсов, но не очень удобныйтолько более приведённый к «вебовому» виду, может со скриптами и не подойтидаже, ибо не особо заточен на динамическое создание)… наверное, с возможностью грузить описания Activity с сервера аналогично HTML страницам сайтов («экраном») будет та же страницас кэшированием, открытая по какому-то адресу (URLконечно). В JS предоставить DOM и вообще APIБыло бы, похожие на обычный браузерный JS настолько, чтобы этого было достаточно для запуска всяких стандартных JS фишек.Плюс видимо какпо-то эти «описания страниц» кэшироватьмоему, чтобы всё-таки не каждая активити очень круто — многие мобильные приложения сейчас представляют из инета открываласьсебя просто нативные интерфейсы к сайтам, либо чтобы вообще была возможность завернуть её а так их даже не нужно было бы оборачивать в пакет приложенияприложения — нативный интерфейс появлялся бы прямо в процессе просмотра интернетов.То есть очевидная идея{{wl-publish: в чём проблема html5 приложений? В самом html5. Ну так заменить его на что2015-то и чики06-пуки.Как это натянуть на андроид — ХЗ, явно нужна какая-то дополнительная прослойка, т.к по дефолту активити описываются в манифесте и только в нём.Но сама идея по-моему хорошая, так как максимально упрощается вообще ВСЁ, появляется вариант генерить страницы на лету бэкендами (или может наоборот он не особо нужен), плюс есть теоретический шанс суметь сделать это кроссплатформенно.[[Category02 23:35:VitaliPrivate]]51 +0300 | VitaliyFilippov }}