Comments 98
С такой начинкой, ценой и потенциальной линуксосовместимостью без костылей можно ожидать, что кастомных прошивок на него будет тьма тьмущая. Если, конечно, никто не догадается на нем закрыть загрузчик или применить еще какие-нибудь ограничения.
На всякие запреты найдутся анлокеры. Рано или поздно. Будет очень любопытно глянуть, какой доступ будет из коробки.
Интересно, а что там за загрузчик? Таки EFI?
Меня больше интересует когда интел начнет хотя бы ради теста делать нетбуки с android. Пользовался asus transformer не заметил разницы между нетбуком и им, разве что приложения немного непривычные и все кнопки очень большие.
«Это для меня очень удобно, т.к. если чего нет в маркете то можно собрать без тяжелых танцев с бубном и с адаптацией под ARM.»
Не совсем понимаю как вы это будете делать, потому а) танцы с бубном нужны для того что бы адаптировать программу под NDK, там что будет свой ndk? б) о каких танцах с бубном идет речь, если тот же дебиан и убунту давно и успешно собираются под arm. И собирается все ведь как минимум из с++, который работает со стандартной библиотекой которую обеспечивает gcc, qt без каких либо танцев с бубном собирается под арм. И с танцами собирается под NDK, точнее танцы именно в том что бы взять lighthouse и реализовать недостающие вещи чеhtp NDK. Да и lighthouse уже наверно никто не берет, а форкает necessitas.
Возможно вы спутали сборку приложения под arm и под android? Если все таки ничего не спутали и уверены в своей правоте расскажи что именно я понял не так и как вы собираетесь собирать например amarok.
Не совсем понимаю как вы это будете делать, потому а) танцы с бубном нужны для того что бы адаптировать программу под NDK, там что будет свой ndk? б) о каких танцах с бубном идет речь, если тот же дебиан и убунту давно и успешно собираются под arm. И собирается все ведь как минимум из с++, который работает со стандартной библиотекой которую обеспечивает gcc, qt без каких либо танцев с бубном собирается под арм. И с танцами собирается под NDK, точнее танцы именно в том что бы взять lighthouse и реализовать недостающие вещи чеhtp NDK. Да и lighthouse уже наверно никто не берет, а форкает necessitas.
Возможно вы спутали сборку приложения под arm и под android? Если все таки ничего не спутали и уверены в своей правоте расскажи что именно я понял не так и как вы собираетесь собирать например amarok.
NDK в перспективе — почему бы и нет? Но по сути вся адаптация состоит в прописывании NDK-шного компилятора за место linux-gcc, sysroot'a и сборка 32-битного кода. В конечном итоге все библиотеки и зависимости тоже можно пересобрать без костылей и ndk-make'ов.
«NDK в перспективе — почему бы и нет? „А кто его будет делать? Вы сами?
“В конечном итоге все библиотеки и зависимости тоже можно пересобрать без костылей и ndk-make'ов.»
Каким образов вы так планируете собирать например wxWidgets? Вас не смущает отсутствие в android библиотек XWindow?
“В конечном итоге все библиотеки и зависимости тоже можно пересобрать без костылей и ndk-make'ов.»
Каким образов вы так планируете собирать например wxWidgets? Вас не смущает отсутствие в android библиотек XWindow?
Вы ставите сложные задачи. Со временем, уверен, сделают. x86 более удобная и привычная платформа для работы, где процесс портирования должен быть проще, т.к. просто опыта у людей для работы с ней больше.
>Вас не смущает отсутствие в android библиотек XWindow?
чем сложнее цель, тем больше цепочка всех зависимостей. Если у вас есть такая цель — пересоберите XWindow, системные библиотеки Android, если надо.
Я Вас понимаю, но всё дело во времени. По сути появляение смартфонов с x86 должно размыть границы между обычными компьютерами и телефонами и форсировать изменения самого Android, пусть даже путём в том числе и вашего вмешательства, если вы готовы работать как открытое сообщество.
>Вас не смущает отсутствие в android библиотек XWindow?
чем сложнее цель, тем больше цепочка всех зависимостей. Если у вас есть такая цель — пересоберите XWindow, системные библиотеки Android, если надо.
Я Вас понимаю, но всё дело во времени. По сути появляение смартфонов с x86 должно размыть границы между обычными компьютерами и телефонами и форсировать изменения самого Android, пусть даже путём в том числе и вашего вмешательства, если вы готовы работать как открытое сообщество.
Я правильно вас понял? Сделают «со временем», а преимущество сборки и запуска _любого_ линукс приложения вы декларируете уже сейчас?
«Вы ставите сложные задачи.» Я ничего не ставлю, просто уточняю все навсего то что вы сами сказали. Возможно вы понимаете в андроиде что-то такое что не понимаю я и мне просто интересно как вы собираетесь делать то, что на мой взгляд сейчас невозможно.
«x86 более удобная и привычная платформа для работы» а в чем будет разница при сборке с помощью x86_gcc и arm_gcc одних и тех же с++ исходников?
«Вы ставите сложные задачи.» Я ничего не ставлю, просто уточняю все навсего то что вы сами сказали. Возможно вы понимаете в андроиде что-то такое что не понимаю я и мне просто интересно как вы собираетесь делать то, что на мой взгляд сейчас невозможно.
«x86 более удобная и привычная платформа для работы» а в чем будет разница при сборке с помощью x86_gcc и arm_gcc одних и тех же с++ исходников?
Ок, по поводу запуска. Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield. По поводу сборки не всё так гладко, но опять-таки, некоторая доля программ соберётся обычным путём, как и под linux, без необходимости искать костыли. Насчёт ARM я столь не уверен и не имею богатого опыта, однако, думаю, не все используемые функции\библиотеки одинаковы, а потому требуют костылей для адаптации к архитектуре. Если тут я не прав, то поправьте, пожалуйста, насколько велика разница между arm \ x86 набором в NDK.
> а в чем будет разница при сборке
глобально ни в чём, по факту — в разнице в реализации библиотек\функций.
>сейчас невозможно
Согласен, многое сейчас невозможно.
> а в чем будет разница при сборке
глобально ни в чём, по факту — в разнице в реализации библиотек\функций.
>сейчас невозможно
Согласен, многое сейчас невозможно.
«Согласен, многое сейчас невозможно.» Если интел не выпустит свой вариант NDK с картами и женщинами, то так все и останется, потому что на месте гугл нет никакого смыла так фрагментировать андроид, что на арм версии будет так же как и сейчас, а на x86 будет XWindow, alsa и все остальное что есть в обычном linux.
«по факту — в разнице в реализации библиотек\функций.» Давайте взглянем что такое код на с++, это использование какого-либо стандарта языка, к примеру возьмем ISO98(могу годом ошибиться), и вызовы библиотечных функций. Стандарт языка поддерживается одинакова что в arm версии gcc что в x86, поэтому синтаксически у нас будет корректный код (если конечно программисты не делали то, что делать нельзя, а именно, полагались на то, что int всегда равен 4 байта, но эти грабли с переходом на x86_64 вроде уже пережили, и если не использовались асемблерные вставки, но мы же все-таки о коде с++ говорим). Самое интересное кроется в допустимых библиотеках. Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков(так будет до тех пор пока intel сам не выпустит свой особый NDK) поэтому сборка будет отличаться максимум какими-то специфичными ключами оптимизации для арм(если такие есть, но как правило все не парятся и Os используют).
«Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield.» Вот мы имеем x86 версию Amarok взятую из x86 сборки ubuntu как оно пойдет на android_x86? Оно же банальное kdelibs попросит которых там нет( и не будет если сами не соберете, а вы их так просто не собирете, потому что они попросят qt которого там то же нет, пока вы его не соберете, но его собрать не получится, потому что он попросит XWindow, а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену, причем совместимую на уровне h файлов, а это адовая задача, которую просто так вечером после работы не сделаешь)
Это все равно что утверждать что имея абстрактное приложение линукс оно 90% пойдет под Windows. Не пойдет, у вас корневые библиотеки разные, в первую очередь своим составом, потом они могут бинарно отличаться(например x86 и x86_64, а уже потом могут отличаться версией). Вы попробуйте сначала просто запустить амарок из состава убунты под fedora, скорее всего даже это не получится. Вы не обращали внимания что программы которые бинарно распространяются, например opera или skype имеют свои версии под разные дистрибутивы линукса, а иного ещё и разные версии одного дистрибутива. Даже имея исходники(какой-то абстрактной программы) её регулярно тяжело заставить работать в конкретной версии линукс( у вас банально обновилась библиотека, например стоит qt 4.8, в котором что-то изменилось, а программа под 4.7).
«Согласен, многое сейчас невозможно.» Проще сказать что сейчас возможно, а возможно то же что и для arm_android, писать с использованием Android SDK и Adnroid NDK, с теми же костылями и проблемами.
«по факту — в разнице в реализации библиотек\функций.» Давайте взглянем что такое код на с++, это использование какого-либо стандарта языка, к примеру возьмем ISO98(могу годом ошибиться), и вызовы библиотечных функций. Стандарт языка поддерживается одинакова что в arm версии gcc что в x86, поэтому синтаксически у нас будет корректный код (если конечно программисты не делали то, что делать нельзя, а именно, полагались на то, что int всегда равен 4 байта, но эти грабли с переходом на x86_64 вроде уже пережили, и если не использовались асемблерные вставки, но мы же все-таки о коде с++ говорим). Самое интересное кроется в допустимых библиотеках. Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков(так будет до тех пор пока intel сам не выпустит свой особый NDK) поэтому сборка будет отличаться максимум какими-то специфичными ключами оптимизации для арм(если такие есть, но как правило все не парятся и Os используют).
«Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield.» Вот мы имеем x86 версию Amarok взятую из x86 сборки ubuntu как оно пойдет на android_x86? Оно же банальное kdelibs попросит которых там нет( и не будет если сами не соберете, а вы их так просто не собирете, потому что они попросят qt которого там то же нет, пока вы его не соберете, но его собрать не получится, потому что он попросит XWindow, а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену, причем совместимую на уровне h файлов, а это адовая задача, которую просто так вечером после работы не сделаешь)
Это все равно что утверждать что имея абстрактное приложение линукс оно 90% пойдет под Windows. Не пойдет, у вас корневые библиотеки разные, в первую очередь своим составом, потом они могут бинарно отличаться(например x86 и x86_64, а уже потом могут отличаться версией). Вы попробуйте сначала просто запустить амарок из состава убунты под fedora, скорее всего даже это не получится. Вы не обращали внимания что программы которые бинарно распространяются, например opera или skype имеют свои версии под разные дистрибутивы линукса, а иного ещё и разные версии одного дистрибутива. Даже имея исходники(какой-то абстрактной программы) её регулярно тяжело заставить работать в конкретной версии линукс( у вас банально обновилась библиотека, например стоит qt 4.8, в котором что-то изменилось, а программа под 4.7).
«Согласен, многое сейчас невозможно.» Проще сказать что сейчас возможно, а возможно то же что и для arm_android, писать с использованием Android SDK и Adnroid NDK, с теми же костылями и проблемами.
>«Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield.»
Тысяча чертей! Вы правы. Там должно было быть добавлено «статически скомпонованное». И малая доля динамически. Прошу меня простить.
> а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену
Да, про что я и говорю. Это титанический труд, но задача решаема, если её надо решить. Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.
>Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков
У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? Само наличие библиотек не означает их внутреннюю идентичность. И дело не только в ключах оптимизации. Если есть где сравнение, было бы любопытно посмотреть, я не в курсе.
Тысяча чертей! Вы правы. Там должно было быть добавлено «статически скомпонованное». И малая доля динамически. Прошу меня простить.
> а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену
Да, про что я и говорю. Это титанический труд, но задача решаема, если её надо решить. Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.
>Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков
У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? Само наличие библиотек не означает их внутреннюю идентичность. И дело не только в ключах оптимизации. Если есть где сравнение, было бы любопытно посмотреть, я не в курсе.
«Тысяча чертей! Вы правы. Там должно было быть добавлено «статически скомпонованное». И малая доля динамически. Прошу меня простить.» Вернемся к Amarok, как вы себе представляете его статически скомпонованным с kdelibs?
«Это титанический труд, но задача решаема, если её надо решить» Кому надо-то? Вам вы один её не решите! У меня(как и у 2Гис) уже qt собран под android и так, правда под arm версию, но уверен что он так же легко соберется и под x86_android, но это совсем не то о чем вы говорите. В данном случае сложность адаптации qt под arm и x86 одинаковая и она достаточно большая, т.к. всю низкоуровневую часть работы с выводом на экран пришлось переделывать на через jni. И не только на экран, а ещё сеть, звук.
«Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.» После того как вы адаптируете загрузчик и прикрутите туда драйвер для PowerVR SGX, а так же тач-дисплея, устройства вывода звука, wi-fi карте. Но точно так же linux должен заработать и на обычных arm_android, потому что уже есть arm ubuntu например.
«У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? » Есть? в этом не сложно убедиться заглянув в последний ndk r8, можно начать h файлы сравнивать. Там один в один одинаковые либы для arm, x86, mips. Если бы это было не так, то при сборке андроид приложения использующего ndk разработчикам пришлось бы лепить кучу костылей для того что бы собирать разными наборами либ один и тот же код. И компиляторы там одинаковые 4.4.3.
Иными словами сборка под arm, х86 и mips происходит одинаково. Если вы используете Google NDK.
«Это титанический труд, но задача решаема, если её надо решить» Кому надо-то? Вам вы один её не решите! У меня(как и у 2Гис) уже qt собран под android и так, правда под arm версию, но уверен что он так же легко соберется и под x86_android, но это совсем не то о чем вы говорите. В данном случае сложность адаптации qt под arm и x86 одинаковая и она достаточно большая, т.к. всю низкоуровневую часть работы с выводом на экран пришлось переделывать на через jni. И не только на экран, а ещё сеть, звук.
«Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.» После того как вы адаптируете загрузчик и прикрутите туда драйвер для PowerVR SGX, а так же тач-дисплея, устройства вывода звука, wi-fi карте. Но точно так же linux должен заработать и на обычных arm_android, потому что уже есть arm ubuntu например.
«У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? » Есть? в этом не сложно убедиться заглянув в последний ndk r8, можно начать h файлы сравнивать. Там один в один одинаковые либы для arm, x86, mips. Если бы это было не так, то при сборке андроид приложения использующего ndk разработчикам пришлось бы лепить кучу костылей для того что бы собирать разными наборами либ один и тот же код. И компиляторы там одинаковые 4.4.3.
Иными словами сборка под arm, х86 и mips происходит одинаково. Если вы используете Google NDK.
>как вы себе представляете его статически скомпонованным с kdelibs
представить можно и 11-мерное пространство, но не всегда реализовать. Должны же быть грани у разумного.
>Кому надо-то? Вам вы один её не решите!
Поэтому если это надо не только вам, то организуются команды, компании нанимают людей, если им надо. Так в-общем всё устроено в разработке по. Но если хотя бы часть будет уже готова, то в идеале должно быть проще прийти к конечному результату.
> потому что уже есть arm ubuntu например.
набор ПО под него такой же богатый, как и под x86?
>Там один в один одинаковые либы для arm, x86, mips.
Поверю Вам на слово. Остается за оптимизациями и редкими архитектурными особенностями.
В-общем предлагаю прийти к консенсусу. В сборке сильных различий нет. Не всё конечно сильно проще, но исходный набор бинарников и исходников под x86 побогаче.
представить можно и 11-мерное пространство, но не всегда реализовать. Должны же быть грани у разумного.
>Кому надо-то? Вам вы один её не решите!
Поэтому если это надо не только вам, то организуются команды, компании нанимают людей, если им надо. Так в-общем всё устроено в разработке по. Но если хотя бы часть будет уже готова, то в идеале должно быть проще прийти к конечному результату.
> потому что уже есть arm ubuntu например.
набор ПО под него такой же богатый, как и под x86?
>Там один в один одинаковые либы для arm, x86, mips.
Поверю Вам на слово. Остается за оптимизациями и редкими архитектурными особенностями.
В-общем предлагаю прийти к консенсусу. В сборке сильных различий нет. Не всё конечно сильно проще, но исходный набор бинарников и исходников под x86 побогаче.
«Поверю Вам на слово. » Не надо, пойдите и сравните
заголовочные файлы!
«но исходный набор бинарников » Каких бинарников? Под виндовс? Ну запустите на андроиде хотя бы бинарник калькулятора.
«исходников под x86 побогаче» Каких исходников под x86? Ассемблерных? С++ исходники будут собираться одинаково. Потому что компилятор один и тот же, набор либ один и тот же, стандарт языка один и тот же.
Я вижу что вам как работнику интела нужно обосновать чем же лучше этот телефон стопицот других таких же на arm процах. И все видят что интел ну просто локти кусает видя как огромный рынок телефонов, планшетав и уже даже нетбуков просто уплывает из под носа. И видно что интел пытается хоть как-то на этот рынок влезть, потому что он растет и растет быстро(интересно кстати когда таки АМД начнет шевелиться). Но перестаньте расхваливать то чего нет. Переключитесь на другие особенности. Например я вижу у интела просто огромный потенциал по наращиванию мощности. Так же есть огромный потенциал по выпуску новых устройств, например нетбуков с андроидом. Или гибридных планшетов(типа того же трансформера). Выход этого телефона действительно знаковое событие для всей индустрии, андроид становится более гибким. Arm получает вменяемого конкурента, что может привести к гонке производительности(а то пообещали 2,5 ГГц чипы А15 и где они до сих пор?) Ну и вообще больше процессоров хороших и разных. Что интел умеет делать так это развязывать ценовые войны, АМД до сих пор отходит, хотя красно-зеленый лагерь мне более симпатичный чем голубой.
заголовочные файлы!
«но исходный набор бинарников » Каких бинарников? Под виндовс? Ну запустите на андроиде хотя бы бинарник калькулятора.
«исходников под x86 побогаче» Каких исходников под x86? Ассемблерных? С++ исходники будут собираться одинаково. Потому что компилятор один и тот же, набор либ один и тот же, стандарт языка один и тот же.
Я вижу что вам как работнику интела нужно обосновать чем же лучше этот телефон стопицот других таких же на arm процах. И все видят что интел ну просто локти кусает видя как огромный рынок телефонов, планшетав и уже даже нетбуков просто уплывает из под носа. И видно что интел пытается хоть как-то на этот рынок влезть, потому что он растет и растет быстро(интересно кстати когда таки АМД начнет шевелиться). Но перестаньте расхваливать то чего нет. Переключитесь на другие особенности. Например я вижу у интела просто огромный потенциал по наращиванию мощности. Так же есть огромный потенциал по выпуску новых устройств, например нетбуков с андроидом. Или гибридных планшетов(типа того же трансформера). Выход этого телефона действительно знаковое событие для всей индустрии, андроид становится более гибким. Arm получает вменяемого конкурента, что может привести к гонке производительности(а то пообещали 2,5 ГГц чипы А15 и где они до сих пор?) Ну и вообще больше процессоров хороших и разных. Что интел умеет делать так это развязывать ценовые войны, АМД до сих пор отходит, хотя красно-зеленый лагерь мне более симпатичный чем голубой.
Я высказываю своё субъективное потребительское мнение, не относящееся к компании — она, думаю, сделает свой официальный релиз и обзор, куда более техничный и сдержанный, чем мой. В своё время после пяти лет с монохромной нокией я долго искал себе телефон, который бы мог удовлетворить мои потребности, чтобы он был максимально близок по функциональности и совместимости с ПК. Так выбрал HTC'шный виндовсфон, хотя, по сути это уже был закат WinMobile, и куда более разумным был бы выбор, например, iPhone. Затем, когда Андроид стал удовлетворять мои потребности — телефон на нём. Сейчас же мне сильно импонирует именно х86 платформа, на которой не всё гладко, но возможно позволит мне делать больше, чем на братьях-близнецах ARM-телефонах, и которая мне исторически более знакома.
>Каких бинарников? Под виндовс?
Вам никогда не встречались unix-бинарники, полностью статические? Или даже не стататические, но для которых проще пересобрать одну из зависимостей, чем всё сразу?
>Ассемблерных? С++ исходники будут собираться одинаково.
пускай даже так. В природе существует софт, для которого архитектура — критична.
>нетбуков с андроидом
Допустим даже вендор заинтересуется. Большой ли прок от нынешнего андроида на нетбуке? Когда, в принципе, лёгкие linux-сборки или даже ChromeOS попросту практичнее без тачскрина?
>интел пытается хоть как-то на этот рынок влезть
я не маркетолог, но с точки зрения потребителя могу сказать, что всё-таки лучше, когда есть выбор. Одно время среди КПК выбор из ос был фактически WinMobile и точка, девайсов Apple ещё не было, а Newton'ы уже умерли. Symbian же были лишь на телефонах. Сами говорите, это подхлестнёт развитие рынка в разных направлениях.
>Каких бинарников? Под виндовс?
Вам никогда не встречались unix-бинарники, полностью статические? Или даже не стататические, но для которых проще пересобрать одну из зависимостей, чем всё сразу?
>Ассемблерных? С++ исходники будут собираться одинаково.
пускай даже так. В природе существует софт, для которого архитектура — критична.
>нетбуков с андроидом
Допустим даже вендор заинтересуется. Большой ли прок от нынешнего андроида на нетбуке? Когда, в принципе, лёгкие linux-сборки или даже ChromeOS попросту практичнее без тачскрина?
>интел пытается хоть как-то на этот рынок влезть
я не маркетолог, но с точки зрения потребителя могу сказать, что всё-таки лучше, когда есть выбор. Одно время среди КПК выбор из ос был фактически WinMobile и точка, девайсов Apple ещё не было, а Newton'ы уже умерли. Symbian же были лишь на телефонах. Сами говорите, это подхлестнёт развитие рынка в разных направлениях.
«Вам никогда не встречались unix-бинарники, полностью статические?» Эм… сферический бинарники в вакууме? Даже ls так или иначе что-то будет грузить динамически. И если такое приложение найдется — это уж точно будет приложение без GUI. А какую ценность имеют приложения без GUI на коммуникаторе? Приведите пример.
«В природе существует софт, для которого архитектура — критична» Да такой код есть, например там где используются asm вставки. Но такого кода настолько мало и он настолько узко-специфичный, что я не могу придумать примера когда даже программисту понадобится такое на смартфоне. У меня есть один единственный пример. Когда мы будем портировать нашу игру под смарфон… есть один кусок кода для расчета физики с большой долей оптимизаций на asm. И вот он скорее всего соберется, хотя я не уверен даже в этом потому что под разные компиляторы могут быть разные стандарты asm вставок. И самое главное вот этот вот конкретный проц этот код будет выполнять с частотой пол кадра в секунду. Поэтому его даже портировать никто не будет, а просто заменят физику на моделенную анимаци. Вы говорите о таких исключительных случаях, что даже не могу придумать когда это реально будет необходимо.
«Когда, в принципе, лёгкие linux-сборки или даже ChromeOS попросту практичнее без тачскрина?»
Ну вот не уверен. Вопрос в наличие приложений, игр под андроид значительно больше. И много софта очень казуального, красивого. Типа всяких твиттер клиентов, да даже скайп красивее и функциональнее (был до вчера).
Андроид скорее всего будет более юзер-френдли. А хром-ос… ну не знаю, мне ближе хранить файлы на своем жестком диске.
«Сами говорите, это подхлестнёт развитие рынка в разных направлениях» Да говорю и поэтому считаю выход этого смарфона очень хорошей новость. Ну если вас интересует мое мнения — я рад что они наконец вышли на рынок, даже очень рад. Но тут не нужно просто путать личную радость и технические возможности. И приписывать девайсу те характеристики которыми он не обладает. То есть по просту вводить в заблуждение. Иначе вы получите очень много недовольства. От людей которые попробуют сначала запустить Amarok из убунты на этом телефоне, а потом собрать и у них ведь ничего не получится. Особенно когда вы декларируете в статье: «При желании можно собрать и запустить любую linux-программу.» Amarok вполне обычная linux-программа. Соберите её пожалуста под этот телефон и запустите.
«В природе существует софт, для которого архитектура — критична» Да такой код есть, например там где используются asm вставки. Но такого кода настолько мало и он настолько узко-специфичный, что я не могу придумать примера когда даже программисту понадобится такое на смартфоне. У меня есть один единственный пример. Когда мы будем портировать нашу игру под смарфон… есть один кусок кода для расчета физики с большой долей оптимизаций на asm. И вот он скорее всего соберется, хотя я не уверен даже в этом потому что под разные компиляторы могут быть разные стандарты asm вставок. И самое главное вот этот вот конкретный проц этот код будет выполнять с частотой пол кадра в секунду. Поэтому его даже портировать никто не будет, а просто заменят физику на моделенную анимаци. Вы говорите о таких исключительных случаях, что даже не могу придумать когда это реально будет необходимо.
«Когда, в принципе, лёгкие linux-сборки или даже ChromeOS попросту практичнее без тачскрина?»
Ну вот не уверен. Вопрос в наличие приложений, игр под андроид значительно больше. И много софта очень казуального, красивого. Типа всяких твиттер клиентов, да даже скайп красивее и функциональнее (был до вчера).
Андроид скорее всего будет более юзер-френдли. А хром-ос… ну не знаю, мне ближе хранить файлы на своем жестком диске.
«Сами говорите, это подхлестнёт развитие рынка в разных направлениях» Да говорю и поэтому считаю выход этого смарфона очень хорошей новость. Ну если вас интересует мое мнения — я рад что они наконец вышли на рынок, даже очень рад. Но тут не нужно просто путать личную радость и технические возможности. И приписывать девайсу те характеристики которыми он не обладает. То есть по просту вводить в заблуждение. Иначе вы получите очень много недовольства. От людей которые попробуют сначала запустить Amarok из убунты на этом телефоне, а потом собрать и у них ведь ничего не получится. Особенно когда вы декларируете в статье: «При желании можно собрать и запустить любую linux-программу.» Amarok вполне обычная linux-программа. Соберите её пожалуста под этот телефон и запустите.
>А какую ценность имеют приложения без GUI на коммуникаторе?
Среднестатистическому юзеру никакой. Хороший пример существующий SL4A, работающий с некоторыми условностями, в отличие от родных интерпретаторов. Тот же TCL прекрасно работает в статической сборке без всяких зависимостей. Думаю, вполне возможно предположить невысокую сложность сборки (или уже существование статических бинарников) и других не-gui утилит, на которых можно построить уже вполне обычное с виду Android-GUI-приложение. Так что такая возможность больше ориентирована на разработчиков, а не на пользователей.
>расчета физики с большой долей оптимизаций
Как пример. Или другие математические программы. Сегодня для телефонов в их казуальности такие загоны ни к чему, но с размытием границ между мобильными и немобильными платформами в будущем хороший и быстрый код, способный решить нетривиальные задачи для подсчёта дырок в бубликах использование процессора всё более будет распространённым. Игры. Тулзы для анализа (например рынка ценных бумаг), порты инженерных программ. Благо, далее интерфейсы будут позволять и подключение клавиатур, мониторов.
>наличие приложений, игр под андроид значительно больше
Чем под Linux? Тем более с Wine\Cedega? Чем даже возможность запустить VM? Плюс их адаптация под размер экранов телефона\планшета, под тач-ввод за место мышино-клавиатурного метода, что снижает юзабилити. С ХромОС — ваша позиция, резонно существование приверженцев хранения локальных данных и хранимых в облаках.
Среднестатистическому юзеру никакой. Хороший пример существующий SL4A, работающий с некоторыми условностями, в отличие от родных интерпретаторов. Тот же TCL прекрасно работает в статической сборке без всяких зависимостей. Думаю, вполне возможно предположить невысокую сложность сборки (или уже существование статических бинарников) и других не-gui утилит, на которых можно построить уже вполне обычное с виду Android-GUI-приложение. Так что такая возможность больше ориентирована на разработчиков, а не на пользователей.
>расчета физики с большой долей оптимизаций
Как пример. Или другие математические программы. Сегодня для телефонов в их казуальности такие загоны ни к чему, но с размытием границ между мобильными и немобильными платформами в будущем хороший и быстрый код, способный решить нетривиальные задачи для подсчёта дырок в бубликах использование процессора всё более будет распространённым. Игры. Тулзы для анализа (например рынка ценных бумаг), порты инженерных программ. Благо, далее интерфейсы будут позволять и подключение клавиатур, мониторов.
>наличие приложений, игр под андроид значительно больше
Чем под Linux? Тем более с Wine\Cedega? Чем даже возможность запустить VM? Плюс их адаптация под размер экранов телефона\планшета, под тач-ввод за место мышино-клавиатурного метода, что снижает юзабилити. С ХромОС — ваша позиция, резонно существование приверженцев хранения локальных данных и хранимых в облаках.
«Если интел не выпустит свой вариант NDK» уже выпустил, идет в составе Android NDK
Есле точнее, то Google выпустил, а Intel помог ;).
Начиная с Android NDK 6 обеспечивается поддержка x86 инструкций:
The latest release of the NDK supports the following instruction sets:
— ARMv5TE, including Thumb-1 instructions
— ARMv7-A, including Thumb-2 and VFPv3-D16 instructions
— x86 instructions
— MIPS instructions
Начиная с Android NDK 6 обеспечивается поддержка x86 инструкций:
The latest release of the NDK supports the following instruction sets:
— ARMv5TE, including Thumb-1 instructions
— ARMv7-A, including Thumb-2 and VFPv3-D16 instructions
— x86 instructions
— MIPS instructions
UFO just landed and posted this here
«Встроенная память: 16000 Мб» — давно не видел чтоб так писали, обычно 16гб
Может это потому что 16000 Мб — это 16000 Мб, а 16гб — это 16гб? :)
Хорошо, хоть М заглавная, так бы вообще мегабиты получились ;-)
В килобайте, уже давно 1000 байт, а не 1024. Погуглите про кибибайты.
мир сошел с ума, всегда считал что 16Гб это 16384 Мб
UFO just landed and posted this here
200 фунтов скорее всего с контрактом Orange. Свободная трубка скорее всего так и будет стоить — 500+.
200 фунтов — цена самого телефона + контракт сверху. Насколько я понимаю, с контрактом телефон можно получить телефон и за 15 фунтов в месяц.
Orange San Diego price: £15.50 (24-month contract), £199.99 (PAYG)
Сам Orange продаёт только с планами, скорее всего, телефон будет так или иначе привязан. Эта компания всегда старалась высосать максимум.
Свободный Sim Free телефон продаётся за £299.99.
Свободный Sim Free телефон продаётся за £299.99.
Хотеть… Интересно будет туда ещё попробовать винду водрузить. Ради прикола. ))
Несовсем верно про цену — это операторский телефон, а значит, без контракта его никто не продаст. SGSIII с контрактом тоже не стоит 500 фунтов. В британском водафоне на самом дорогом тарифе его дают бесплатно вообще
UFO just landed and posted this here
Этот вопрос мне любят задавать. И любимый комментарий к нему: 1ГБ ОЗУ мало.
Ну если любители запускали и Vista на непредназначенных для этого девайсах, то у San Diego все шансы опробовать на себе десятки операционок.
Ну если любители запускали и Vista на непредназначенных для этого девайсах, то у San Diego все шансы опробовать на себе десятки операционок.
Минимальное разрешение для Metro приложений — 1024x768, тут — 600 x 1024. Винфон 8 правда обещает совместимость Win8 и WinPhone 8 приложений.
Понимаю, что нельзя такое в блоге Интел писать, но все-таки: вот бы еще смартфон на MIPS!
Ainol Novo 7 Paladin — MIPS-планшет на Android 4 ICS
Я знаю. О том и речь: какие-то китайцы сделали не напрягаясь MIPS'овский девайс на Андроиде и он вполне успешно работает. Интел же, если мне память не изменяет, феерическое количество усилий/денег потратил и на порт Андроида на x86 в целом и на этот девайс в частности. Т.е. встает вопрос об эффективности этих действий…
Так ли не напрягаясь? Китайцев-то миллионы.
Да и потом вклад в R&D не всегда выгоден сегодня, но может выстрелить завтра. Чтобы предсказывать риски и знать будущее надо быть экстрасенсом или играть нечестно.
Да и потом вклад в R&D не всегда выгоден сегодня, но может выстрелить завтра. Чтобы предсказывать риски и знать будущее надо быть экстрасенсом или играть нечестно.
1. На MIPS приложения с native-библиотеками под ARM вообще не запускаются, на x86 запускаются в режиме бинарной трансляции.
2. В NDK есть toolchain под MIPS, но нет образа для эмулятора. А для x86 есть всё.
3. libcpufeatures на MIPS не распознаёт никаких дополнительных расширений, а на x86 детектирует SSSE3, MOVBE и ещё что-то.
4. Чтобы задействовать SIMD-инструкции на x86 вы можете использовать ассемблер, intrinsic-функции либо авто-векторизацию. А для Ingenic Media Extensions (SIMD-расширение в процессорах XBurst, на которых построены все нынешние MIPS-планшеты) нет даже поддержки на уровне ассемблера.
И есть ещё кучу таких мелочей, которые делают user experience на x86 лучше чем на MIPS.
2. В NDK есть toolchain под MIPS, но нет образа для эмулятора. А для x86 есть всё.
3. libcpufeatures на MIPS не распознаёт никаких дополнительных расширений, а на x86 детектирует SSSE3, MOVBE и ещё что-то.
4. Чтобы задействовать SIMD-инструкции на x86 вы можете использовать ассемблер, intrinsic-функции либо авто-векторизацию. А для Ingenic Media Extensions (SIMD-расширение в процессорах XBurst, на которых построены все нынешние MIPS-планшеты) нет даже поддержки на уровне ассемблера.
И есть ещё кучу таких мелочей, которые делают user experience на x86 лучше чем на MIPS.
Отличные замечания, спасибо!
MIPS интересует прежде всего маленьким энергопотреблением — есть мнение, что смартфоны с ним чуть дольше ARM будут работать… А вот в x86 я в этом плане плохо верю — CISC к этому как-то не сильно располагает…
MIPS интересует прежде всего маленьким энергопотреблением — есть мнение, что смартфоны с ним чуть дольше ARM будут работать… А вот в x86 я в этом плане плохо верю — CISC к этому как-то не сильно располагает…
Бесплатных обедов не бывает. XBurst, возможно, потребляет меньше энергии, чем ARM Cortex A8/A9 и x86 Atom, но за счёт того что выполняет только одну операцию за такт и не имеет нормального SIMD (а некоторые модели не имеют даже FPU). С другой стороны, у Intel и ARM гораздо больше опыта в оптимизации процессоров на низком уровне, поэтому может получится и так, что XBurst более прожорлив.
Что касается CISC vs RISC, то это marketing bullshit. Во-первых, и современные ARM, и x86 можно назвать CISC-процессорами, т.к. они разбивают некоторые сложные операции на более простые. Во-вторых, и те и другие можно назвать RISC-процессорами, т.к. они умеют выполнять другие сложные операции «в железе», без разбиения на простые части. При этом идеального набора инструкций нет: в x86 хорошо то, что есть read-execute и read-execute-write инструкции (хотя они не разу и не RISC), в ARM хорошо, что все инструкции трёх-операндные и могут быть сделаны условными.
Что касается CISC vs RISC, то это marketing bullshit. Во-первых, и современные ARM, и x86 можно назвать CISC-процессорами, т.к. они разбивают некоторые сложные операции на более простые. Во-вторых, и те и другие можно назвать RISC-процессорами, т.к. они умеют выполнять другие сложные операции «в железе», без разбиения на простые части. При этом идеального набора инструкций нет: в x86 хорошо то, что есть read-execute и read-execute-write инструкции (хотя они не разу и не RISC), в ARM хорошо, что все инструкции трёх-операндные и могут быть сделаны условными.
1) Спасибо за ликбез. :-) Я занимался реверсингом на всех этих архитектурах и немного представляю себе их команды, но все равно спасибо. :-) Из всех них именно MIPS таки наиболее чистый RISC. Возможно именно потому и экономичен — нет лишнего overhead'а. И ассемблерный код на нем лучше всего с листа читается… Впрочем, это уже вкусовое…
2) Вы что-то путаете насчет характеристик MIPS'ов. Их изначально разрабатывали для параллелизма и суперскалярности. Это ж всех кто первый раз их код видит очень веселит — после команды на выход из процедуры обычно еще одна какая-нибудь идет и новички не понимают, почему она должна исполняться. В упомянутом вами XBurst SIMD есть года четыре. Да и не одним XBurst'ом… Вон, у Бродкома, если мне память не изменяет, полно чипов на MIPS'е. По крайней мере раньше было…
2) Вы что-то путаете насчет характеристик MIPS'ов. Их изначально разрабатывали для параллелизма и суперскалярности. Это ж всех кто первый раз их код видит очень веселит — после команды на выход из процедуры обычно еще одна какая-нибудь идет и новички не понимают, почему она должна исполняться. В упомянутом вами XBurst SIMD есть года четыре. Да и не одним XBurst'ом… Вон, у Бродкома, если мне память не изменяет, полно чипов на MIPS'е. По крайней мере раньше было…
1. Да, в MIPS инструкции наиболее простые, но иметь простые инструкции не обязательно хорошо. Atom умеет за один такт выполнять read-modify-write, а на RISC архитектурах это будут три инструкции с общей задержкой в 5-7 тактов.
2. Выполнение инструкции после условного перехода атавизм, и ничего хорошего в нём нет.
В XBurst SIMD есть (в новых моделях), но он работает с 32-битными регистрами. По сути это аналог ARMv6 SIMD, и то с меньшими возможностями. Производительности сравнимой с ARM NEON/WMMX2 или Intel SSEx он не обеспечит.
2. Выполнение инструкции после условного перехода атавизм, и ничего хорошего в нём нет.
В XBurst SIMD есть (в новых моделях), но он работает с 32-битными регистрами. По сути это аналог ARMv6 SIMD, и то с меньшими возможностями. Производительности сравнимой с ARM NEON/WMMX2 или Intel SSEx он не обеспечит.
2. Заметьте, под х86 самый быстрый эмулятор :)
Они пытаются влезть в мобильный рынок со своим x86. Пока они в роли отстающих. Это первый процессор который хоть как-то догнал ARM. При этом Cortex A15 уже не за горами. Как и Cortex A9 на том же тех. процессе, что и этот x86. Ну и да замечу, что Intel пришлось выпускать самим устройство. Никому x86 в этом рынке как-то не нужен.
Это будет мой следующий телефон.
Накатим ArchLinux и можно использовать как ssh консоль с кучей дополнительного софта!
Сдаётся мне вся эпичность его рассыпется о 1) цену в российских магазах — около 20000р. 2) недостаток и торможение софта, которые хорошо летает на современных 2х-ядерных android/ios смартфонах.
Если же вопрос ставить «зачем вам на телефоне тяжелые приложения» — зачем тогда вообще делать смартфон на x86 платформе, которая по определению всегда была более энергоёмкой, чем ARM?
Если же вопрос ставить «зачем вам на телефоне тяжелые приложения» — зачем тогда вообще делать смартфон на x86 платформе, которая по определению всегда была более энергоёмкой, чем ARM?
1) Будут серые телефоны как обычно.
2) Я лично такого не заметил ни для нативных, ни для ARM-приложений.
Если у вас есть с Play'a хороший пример «тяжелого» приложения, который именно тормозит из-за загрузки процессора, а не из-за кривости софта, было бы интересно тогда сравнить. Ну или если знаете, то оптимизированные под многопоточность. По бенчмаркам у San Diego вроде как хороший результат.
>зачем вам на телефоне тяжелые приложения
Я такого не писал. Я только снова вопрошаю, что же у вас так жрёт ресурсы. Да, браузер, но это больше в огород памяти, а не CPU\GPU.
2) Я лично такого не заметил ни для нативных, ни для ARM-приложений.
Если у вас есть с Play'a хороший пример «тяжелого» приложения, который именно тормозит из-за загрузки процессора, а не из-за кривости софта, было бы интересно тогда сравнить. Ну или если знаете, то оптимизированные под многопоточность. По бенчмаркам у San Diego вроде как хороший результат.
>зачем вам на телефоне тяжелые приложения
Я такого не писал. Я только снова вопрошаю, что же у вас так жрёт ресурсы. Да, браузер, но это больше в огород памяти, а не CPU\GPU.
Кстати вы интересную особенность заметили, много раз слышал мол арм настолько слаб что не дотягивает даже до атома. А оказывается что он уже ему проигрывает. Возможно все дело в оптимизациях, поживем увидим. Но в лично в моих глазах арм существенно вырос. Ещё не понятно почему графическое ядро не intel?
Юзал Lenovo K800 на Medfield. Феерическое тормозное говно. Конечно, у Orange оболочка поприятнее, но, где, чёрт побери, Ice Cream Sandwich? Свободный от наслоений недоразумений криворукости китайских говнокодеров?
Когда вендоры это поймут, что их программисты и дизайнеры на три уровня ниже аналогичных в Google?
Когда вендоры это поймут, что их программисты и дизайнеры на три уровня ниже аналогичных в Google?
SGS3- $ххх по карте мастеркард, iphone 4s-$ххх по карте мастеркард, посмотреть на BSOD на телефоне- бесценно!
Я давно ждал х86 телефонов с года 2003, когда был молод и считал, что никаких проблем задача запихать процессор в телефон не несет. А все лень и маркетинг.
Ели у этой штуки будет USB-host и HDMI я просто стану сверхмобилен. Винт на 2Тб, клавиатура и все, что я буду делать- просто втыкать его в монитор и зарядку.
(я знаю, что есть решения на арм, полностью удовлетворяющие мои потребности. Решения есть, а вот софта нет).
Я давно ждал х86 телефонов с года 2003, когда был молод и считал, что никаких проблем задача запихать процессор в телефон не несет. А все лень и маркетинг.
Ели у этой штуки будет USB-host и HDMI я просто стану сверхмобилен. Винт на 2Тб, клавиатура и все, что я буду делать- просто втыкать его в монитор и зарядку.
(я знаю, что есть решения на арм, полностью удовлетворяющие мои потребности. Решения есть, а вот софта нет).
Пардон, а вот подобное уже года полтора-два наблюдается в соответствующих местах. ;-)
c обновлением до 4.0 к концу 2012 года
А wine на нем пойдет?
>при повседневном использовании работает 1,5-2 дня, как и большинство других смартфонов
Эхх… уже и не помню когда мой андроид жил 2 дня…
Эхх… уже и не помню когда мой андроид жил 2 дня…
сколько он живёт в режиме съёмки видео?
Не пробовал, но должен жить больше 4-5 часов.
Вот, например его первые ревьюшки.
Вот, например его первые ревьюшки.
Батарея по современным меркам очень слабая. 2100 бы тогда работал бы 3-е суток ;), все же это мобильное устройство, а не гонки от розетки к розетке.
Многие производители не задумывались, что каждый может уехать на рыбалку и вернуться через неделю, а жена дозвониться не сможет по причине слабого АКБ, короче особенности национального менталитета :)
Да LCD дисплей — не есть хорошо, сегодня IPS матрицы LG не такие дорогие уже.
Многие производители не задумывались, что каждый может уехать на рыбалку и вернуться через неделю, а жена дозвониться не сможет по причине слабого АКБ, короче особенности национального менталитета :)
Да LCD дисплей — не есть хорошо, сегодня IPS матрицы LG не такие дорогие уже.
Sign up to leave a comment.
Orange San Diego уже в Европе