Comments 45
мощности мобильных устройств растут и грань между ними и большими братьями размывается.
по мощности планшеты\телефоны давно обогнали десктопы 2005 года. но проц Arm и мерзкие недо ОС не позволяют запустить ничего приемлемого. если бы андроид не тратил батарею в режиме ожидания за день, то и имел бы смысл на него что-то устанавливать. всякий раз открывая игру на телефоне судорожно прикидываешь когда доберешься до розетки и не должен ли тебе кто позвонить
а несовместимость АРМ и х86\х64 ставит крест на обратной совместимости. будущее видимо за плашето-нетбуками винды, когда цена перестанет так кусаться.
а несовместимость АРМ и х86\х64 ставит крест на обратной совместимости. будущее видимо за плашето-нетбуками винды, когда цена перестанет так кусаться.
коду написанному на языке высокого уровня без разницы где выполняться «АРМ или х86\х64». Все дело в компиляторах. Сей час все идет к объединению, ни кто не хочет писать приложения дважды.
Позвольте уточнить: что вы называете "языком высокого уровня"?
Исторически так называют все, что выше ассемблера, в том числе C.
Позвольте я внесу ясность — Mono, Java байткоды или даже LLVM, вот уж действительно без разницы какой язык и какая платформа.
p.s. когда же наконец весь мир перейдет полностью на LLVM
p.s. когда же наконец весь мир перейдет полностью на LLVM
Ага, перенесите что-нибудь посложнее hello world с Андроида под Ubuntu без правки кода. Там же Java с байткодом.
Перестаньте путать язык програмирования, фреймворки и платформу — это почти независимые вещи! Просто практика существования таких вещей как Delphi, MS Visual Studio, да и сама Java комунити или тот же Adobe Flash почти намертво привязали в сознании людей что язык + фреймворк + платформа не делимы, и даже среда разработки неразлучны (что логично, ибо деньги и монополия).
На текущий момент не существует универсального инструментария, позволяющего без особых затрат, сменить фреймворк или язык программирования (а очень часто и платформа прибита намертво), хотя изредка можно попытаться, типа собрать cpp программу в java байт-код, или преобразовать php приложение в cpp и т.п. но зачастую это титанический труд (создание таких трансформеров) и куча куча ограничений.
Я считаю что если разработчики всего мира хотят пореже изобретать велосипеды, заново программируя одну и ту же логику на все новом и новом языке, необходимо поставить посередине (между языком и фрейфмворком с платформами) что то типа LLVM
И тогда один разработчик, написав супер эффективное решение задачи на любимом GO ориентируясь на Web платформу, позволит другому его использовать в своей Си программе для микроконтроллера.
На текущий момент не существует универсального инструментария, позволяющего без особых затрат, сменить фреймворк или язык программирования (а очень часто и платформа прибита намертво), хотя изредка можно попытаться, типа собрать cpp программу в java байт-код, или преобразовать php приложение в cpp и т.п. но зачастую это титанический труд (создание таких трансформеров) и куча куча ограничений.
Я считаю что если разработчики всего мира хотят пореже изобретать велосипеды, заново программируя одну и ту же логику на все новом и новом языке, необходимо поставить посередине (между языком и фрейфмворком с платформами) что то типа LLVM
И тогда один разработчик, написав супер эффективное решение задачи на любимом GO ориентируясь на Web платформу, позволит другому его использовать в своей Си программе для микроконтроллера.
байткоды или даже LLVM, вот уж действительно без разницы какой язык и какая платформаЭто не я написал.
Байт-коды, а тем более LLVM — это ещё одна платформа, со своими ограничениями, что не решает всех проблем и добавляет новые. Помнится, лет двадцать назад, когда только появилась Java, про неё говорили точно так же, как Вы сейчас про LLVM, но, как мы знаем, чуда не произошло, и даже Гуглу пришлось добавлять в Android поддержку нативного кода. В действительности, функции виртуальной машины с успехом выполняет компилятор, который ещё может и оптимизировать машинный код с учётом архитектурных особенностей целевой системы.
Теперь о фреймворках. Они пишутся на определённом языке, и, как следствие, сильно с ним связаны. Гораздо сильнее, чем с машинным или байт-кодом. Бывают обёртки для других языков, но это уже дополнительные надстройки, со всеми вытекащими недостатками.
Ну и, наконец, о платформе. Это не только архитектура процессора, но ещё и куча всего, начиная от простого ввода/вывода до медиаускорителей и специфической периферии вроде барометров. Насколько я понимаю, на это LLVM вообще никак не влияет, а вот фреймворк может включать соответствующие функции, в качестве примера напрашивается Qt.
Но мы сильно удалились от начала дискуссии. Парой комментариев ниже я привёл небольшой список проектов, которые были успешно перенесены с x86 на ARM в рамках одной программной платформы (GNU/Linux) и безо всяких виртуальных машин. Что, собственно, подтверждает тезис sprutspb. А также моё мнение, что при наличии доступа к исходникам виртуальная машина не нужна.
Да, к сожалению сама LLVM не решает проблемы фреймворков, т.е. тот самый доступ к оборудованию… тут нужна либо еще одна абстрация/фреймворк, либо открывать доступ LLVM к платформе/операционной системе, соответственно теряя независимость от них.
Я за создание аппаратной абстракции, особенно если производители оборудования не будут мешать (как это делают разработчики радиомодулей и видеоускорителей, например).
p.s. скажите пожалуйста, а почему именно java байт-код не взлетел? случайно не владелец (sun/oracle) патентов на него руку к этому приложил? по уму это была хорошая попытка, и сейчас, если нужна действительно кросплатформенность, то в списке вариантов java практически на первом месте.
Я за создание аппаратной абстракции, особенно если производители оборудования не будут мешать (как это делают разработчики радиомодулей и видеоускорителей, например).
p.s. скажите пожалуйста, а почему именно java байт-код не взлетел? случайно не владелец (sun/oracle) патентов на него руку к этому приложил? по уму это была хорошая попытка, и сейчас, если нужна действительно кросплатформенность, то в списке вариантов java практически на первом месте.
Насколько я помню, Sun не вёл такой агрессивной патентной политики — это началось в Oracle. Я бы не говорил, что java байт-код не взлетел — всё же он весьма распространён. Но ему присущи недостатки прочих виртуальных машин: потеря производительности из-за двойной компиляции (java в байт-код и байт-код в команды процессора) и недостатки кроссплатформенности: если для переноса программы на C/C++ нужен только компилятор, то для Java уже требуется наличие виртуальной машины на целевой платформе. То есть, то, что должно облегчать переносимость, на самом деле ей мешает.
Аппаратная абстракция это хорошо, но эту задачу решают стандартные API вроде OpenGL или VA API. Пытаться делать более низкоуровневые абстракции на мой взгляд не имеет смысла, т.к. чем ближе к железу, тем больше различий придётся унифицировать.
Прежде всего нужен набор виджетов, но добавлять ещё и это в виртуальную машину по-моему неверно. В Java, кстати, есть Swing, однако, он не всегда достаточно хорошо реализован, поэтому приложения нередко выглядят инородно. Хотя это уже уровень языка, а не VM, он всё равно приводит к разрастанию среды выполнения, что может создавать проблемы, особенно при изменении API. Например, в Windows приходится держать несколько версий .net.
Так что виртуальные машины — это не серебряная пуля, а костыли для обеспечения переносимости при отсутствии исходного кода. При определённых условиях такой серебряной пулей может стать open source. Поэтому тот факт, что планшеты и телефоны на Ubuntu в отличие от Firefox OS продолжают выходить и не становятся закрытыми, как устройства на Tizen, очень радует.
Аппаратная абстракция это хорошо, но эту задачу решают стандартные API вроде OpenGL или VA API. Пытаться делать более низкоуровневые абстракции на мой взгляд не имеет смысла, т.к. чем ближе к железу, тем больше различий придётся унифицировать.
Прежде всего нужен набор виджетов, но добавлять ещё и это в виртуальную машину по-моему неверно. В Java, кстати, есть Swing, однако, он не всегда достаточно хорошо реализован, поэтому приложения нередко выглядят инородно. Хотя это уже уровень языка, а не VM, он всё равно приводит к разрастанию среды выполнения, что может создавать проблемы, особенно при изменении API. Например, в Windows приходится держать несколько версий .net.
Так что виртуальные машины — это не серебряная пуля, а костыли для обеспечения переносимости при отсутствии исходного кода. При определённых условиях такой серебряной пулей может стать open source. Поэтому тот факт, что планшеты и телефоны на Ubuntu в отличие от Firefox OS продолжают выходить и не становятся закрытыми, как устройства на Tizen, очень радует.
Я думаю, автор комментария имел ввиду что-то другое, т.к. конкретно для С разница есть, и те, у кого был опыт переноса кода с одной платформы на другую тут со мной согласятся. Конечно, если писать изначально многоплатформенное приложение и использовать хороший HAL для взаимодйствия с платформой, а само приложение писать строго по стандартам межплатформенных компилятора, который будет использвоаться — то проблем практически не возникнет. Но грамотно продуманная архитекрута — вещь крайне редкая.
Не знаю, что имел в виду автор комментария, но для грамотно построенной программы больших проблем нет. Конечно, если автор ощущает себя крутым хакером и не может совладать с шаловливыми ручками, плоды его трудов будут непереносимы, ну и слава Богу.
Возьмите дистрибутив GNU/Linux для ARM, там Вы обнаружите практически все те же пакеты, которые есть и для i386/amd64: Firefox, GIMP, LibreOffice, XBMC (Kodi) и даже Blender, хотя в возможности комфортно использовать последний я сильно сомневаюсь. Если б проблемы переноса были столь существенны, как Вы утверждаете, этого бы не было, просто потому что разработчики этих немаленьких приложений не обладают большими ресурсами. Кстати, GIMP по-моему написан на C. GTK-то уж точно.
Возьмите дистрибутив GNU/Linux для ARM, там Вы обнаружите практически все те же пакеты, которые есть и для i386/amd64: Firefox, GIMP, LibreOffice, XBMC (Kodi) и даже Blender, хотя в возможности комфортно использовать последний я сильно сомневаюсь. Если б проблемы переноса были столь существенны, как Вы утверждаете, этого бы не было, просто потому что разработчики этих немаленьких приложений не обладают большими ресурсами. Кстати, GIMP по-моему написан на C. GTK-то уж точно.
Ну вот, к примеру XBMC. Первый ARM, на который его портировали был Apple TV2. Вот код на гитхабе: https://github.com/xbmc/atv2. Вот пресс-релиз: https://kodi.tv/you-asked-for-it-xbmc-for-appletv2-ipad-iphone4/. Вот цитата из пресс-релиза:
Как думаете, чем занимались все эти люди? Минимум 3 девеолпера и ещё несоклько других девелоперов и тестеров. Писали команду make в консоли?
Конечно, портировать можно всё, что угодно. Код всегда останется кодом, не имеет никакого значения, о каком языке идёт речь — вопрос только во времени, затраченном на портрование.
А разговор, если вы ещё не забыли, начался с того, что некто sprutspb заявил, что разницы, мол, для любого высокоуровневого языка вообще нет. Так давайте различать понятия — "пишется один раз для всех платформ"© и "портируется в разумные сроки".
The XBMC team is proud to present our first ARM-based release, and it’s a big one. Scott Davilla, with the help of Edgar (gimli) Hucek and Zeljko (amet) Ametovic and several other developers and testers, is finally ready to pull the curtain off of his fun little secret.
Как думаете, чем занимались все эти люди? Минимум 3 девеолпера и ещё несоклько других девелоперов и тестеров. Писали команду make в консоли?
Конечно, портировать можно всё, что угодно. Код всегда останется кодом, не имеет никакого значения, о каком языке идёт речь — вопрос только во времени, затраченном на портрование.
А разговор, если вы ещё не забыли, начался с того, что некто sprutspb заявил, что разницы, мол, для любого высокоуровневого языка вообще нет. Так давайте различать понятия — "пишется один раз для всех платформ"© и "портируется в разумные сроки".
Так давайте различать понятия — «пишется один раз для всех платформ»© и «портируется в разумные сроки».Разумеется. А также давайте различать понятия «архитектура процессора» и «платформа». sprutspb написал о первом, Вы же приводите пример перевода на новую платформу, причём закрытую. Портирование Windows <-> GNU/Linux может потребовать заметных усилий даже на одном компьютере, а Android <-> Windows для телефона скорее всего и вовсе невозможно, тогда как ARM <-> x86 для Ubuntu нередко действительно сводится к команде `make` (после настройки среды кросс-компиляции, хотя небольшой проект и на целевом устройстве собрать можно).
Все верно «архитектура процессора». А кроме процессора есть куча периферии, вот с ней и бывают обычно проблемы. Оптимизация под различные периферийные блоки обычно занимает львиную долю при переносе кода между проектами. ДМА, видео ускорители, аппаратное шифрование и другое все это призвано ускорить работу «платформы», но за ускорение работы мы платим слабой переносимостью кода.
Похоже, что вы спорите ради того, чтоб спорить, т.к. предмет дискуссии исчерпал себя уже давно.
Отнюдь. У меня довольно много более интересных и полезных дел, чем отстаивание тезиса, что при наличии исходников портирование грамотно построенного приложения в рамках одной ОС для разных аппаратных платформ несложно. Особенно в случае open source.
Поэтому я очень рад, что у Вас закончилось желание искать контраргументы.
Поэтому я очень рад, что у Вас закончилось желание искать контраргументы.
В корне с вами не соглашусь. Под кодом на языке высокого уровня, вы наверное имеет в виду bash-скрипты. В этом случае — да.
В остальных случаях, программирование, даже на С, подразумевает частое использование разных интересных фич CPU, MTRR и прочее платформо-ориентированное. Даже программирование игр включает в себя пилинг фич под конкретные видеокарты, которые в свою очередь работают на конкретных шинах, и там УЖЕ развелся неплохой такой зоопарк.
Если бы все так было легко, как вы говорите, то интернет бы не пестрел жалобами на тему «а чо так медленно» и «а чо не компилится моя %softwarename%».
В остальных случаях, программирование, даже на С, подразумевает частое использование разных интересных фич CPU, MTRR и прочее платформо-ориентированное. Даже программирование игр включает в себя пилинг фич под конкретные видеокарты, которые в свою очередь работают на конкретных шинах, и там УЖЕ развелся неплохой такой зоопарк.
Если бы все так было легко, как вы говорите, то интернет бы не пестрел жалобами на тему «а чо так медленно» и «а чо не компилится моя %softwarename%».
Программирование прикладных программ, даже на C, "частое использование разных интересных фич" не предполагает. Необходимость оптимизации под конкретную платформу, конечно, есть, но не так часто, и она должна быть локализована на уровне системы (gstreamer, OpenGL, etc.).
Насколько я пониаю, игры, которые требуют "пилинг фич под конкретные видеокарты", требуют и изрядной мощности этих карт и ЦП, поэтому их и переносить на ARM не имеет смысла.
Остальные проблемы, вроде выравнивания данных исправляются довольно просто.
Насколько я пониаю, игры, которые требуют "пилинг фич под конкретные видеокарты", требуют и изрядной мощности этих карт и ЦП, поэтому их и переносить на ARM не имеет смысла.
Остальные проблемы, вроде выравнивания данных исправляются довольно просто.
А почему не указали важную деталь, что телефончик Meizu не поддерживает переключение в десктопный режим при подключении периферии? А это же одна из главных киллерфич Ubuntu на смартах!
Meizu Pro 5 Ubuntu Edition не поддерживает подключение внешнего дисплея через USB Type-C, так что отсутствие там Desktop Mode не кажется слишком удивительным. На планшете же десктопный режим доступен как с внешним дисплеем, так и без него — элементы управления окнами при этом достаточно мелкие, не думаю что на Ubuntu-смартфоне без внешнего дисплея десктопный режим был бы удобным или практичным решением.
Так ведь подключение смартфона к монитору и превращение его в полноценный пк на Linux — самая главная фишка Ubuntu на смартах. Так ещё смарт имеет type-c разъём( я, правда, не знаю какой там у него USB: полноценный 3.1 или 3.0USB или у него только штекер), который так и проситься на роль подключения всей периферии для смарта. Мне было бы очень удобно иметь одно устройство размером в ладонь, которое я смогу использовать как телефон и десктоп. Но без этой фишки толку от такого Смарта, лично для меня, не будет.
Так вроде ни один из убунтофонов не имел выхода для монитора. Что мне тоже кажется странным.
В качестве такого комбинированного устройства Ubuntu предлагают использовать их планшет.
У планшета есть свои плюсы, в частности, ему для превращения в ноутбук достаточно клавиатуры с мышкой. Но идея соорудить десктоп из относительно небольшого смартфона, просто подключив к нему монитор и периферию намного интереснее.
Ой даже не знаю. Я обладатель двух планшетов. У обоих — 2 Гб DDR3, у одного проц ARM Allwinner A20, на другом X86 Atom Z3735F.
Оба хороши, просто замечательны. В том числе на Windows 10. Даже Скайримчик могу погонять на низких настройках.
Но как только я их подключаю к монитору, срабатывает какая-то невидимая магия, и планшеты начинают тормозить. Ну как начинают… заикаются при открытии 10-ти вкладок в Chrome (а что такого? на десктопе это вполне себе нормально)… интенсивно начинают использовать своп, если к 10-ти вкладкам в Chrome я еще и Скайпик открываю. Прокрутка на страницах типа Linkedin — периодически фризится. Открываю плюс к этому Офис, и планшеты раскаляются. Мой неттоп при тех же самых задачах — еле тепленький.
Так что как по мне, так телефоны и планшеты НЕ ПРЕДНАЗНАЧЕНЫ для выполнения десктопных задач, хоть и могут их выполнять.
***
Лучше бы софтостроители работали над оптимизацией своего несколькогигового софта, а то знаете, больно читать как Вояджер 70х годов, находящийся за хреналионы километров от нас, прошили с Земли на скорости килобайт в час, а твой планшет в руках тебе пишет «Недостаточно памяти для новой firmware» :))
Оба хороши, просто замечательны. В том числе на Windows 10. Даже Скайримчик могу погонять на низких настройках.
Но как только я их подключаю к монитору, срабатывает какая-то невидимая магия, и планшеты начинают тормозить. Ну как начинают… заикаются при открытии 10-ти вкладок в Chrome (а что такого? на десктопе это вполне себе нормально)… интенсивно начинают использовать своп, если к 10-ти вкладкам в Chrome я еще и Скайпик открываю. Прокрутка на страницах типа Linkedin — периодически фризится. Открываю плюс к этому Офис, и планшеты раскаляются. Мой неттоп при тех же самых задачах — еле тепленький.
Так что как по мне, так телефоны и планшеты НЕ ПРЕДНАЗНАЧЕНЫ для выполнения десктопных задач, хоть и могут их выполнять.
***
Лучше бы софтостроители работали над оптимизацией своего несколькогигового софта, а то знаете, больно читать как Вояджер 70х годов, находящийся за хреналионы километров от нас, прошили с Земли на скорости килобайт в час, а твой планшет в руках тебе пишет «Недостаточно памяти для новой firmware» :))
Про Atom ничего не скажу, а A20 процессор древний и в разы слабее MT8164A. Тем более Exynos с 3-4 гигами памяти. Конечно, они будут проигрывать десктопным процессорам, но хватит ли их мощности для типовых задач, можно узнать только попробовав. Для моих скорее всего хватит, а к лагам интерфейса я достаточно толерантен.
Кстати, разрастание десктопных приложений происходит во многом благодаря наличию ресурсов. Когда системы с их недостатком станут достаточно популярными, разработчики начнут под них подстраиваться.
Как раз на про5 десктоп-режим был бы гораздо более актуален в силу аппаратной мощности.
Жду когда можно будет подрубить телефон к монику и периферии и заменить стационар на неспециализированных задачах.
Жду когда можно будет подрубить телефон к монику и периферии и заменить стационар на неспециализированных задачах.
Откуда информация что не поддерживает? Юзаю Meizu MX4, при подключении мышки и клавы (через OTG-кабель) включается десктопный режим. Подключение монитора тоже есть но через Miracast и только на MX5 Pro, для MX4 тоже обещают.
Подключение монитора тоже есть но через Miracast и только на MX5 Pro
Эта функция будет, но на аппаратах, присутствующих на стенде она "не была готова", так же как и сенсор отпечатков пальцев. Вероятно в финальной версии она будет реализована, возможно тогда десктопный режим появится и на Meizu Pro 5 Ubuntu Edition.
Как я понимаю, теперь здесь двойной набор софта? Потому что в обычном магазине приложений для Ubuntu как не было ничего, так и осталось, afaik.
Весь, скажем прямо, небогатый набор софта приложений в магазине Ubuntu будет работать и в десктопном режиме (в отдельных окнах), а вот какие изначально "десктопные приложения" будут предустановлены и будут ли они дублироваться — точно ответить не могу. На планшете мне с гордостью демонстрировали полноценную версию Firefox, с плагинами, LibreOffice, GIMP и еще игрушку Cut of Rope.
Большая часть ПО для Ubuntu свободна, для него больших проблем из-за смены архитектуры не будет, т.к. всегда можно пересобрать из исходников под нужный процессор.
Жаль, что про выход планшета пока ничего не известно — мой недавно совсем сломался, и M10 выглядит естественным кандидатом на замену, причём без конкурентов. Если BQ не слишком завысят цену — E4.5 и E5 выглядят на фоне аналогов чересчур дорогими.
Жаль, что про выход планшета пока ничего не известно — мой недавно совсем сломался, и M10 выглядит естественным кандидатом на замену, причём без конкурентов. Если BQ не слишком завысят цену — E4.5 и E5 выглядят на фоне аналогов чересчур дорогими.
Всё же, судя по фото мне кажется что у BQ Aquaris M10 Ubuntu Edition не mini а micro-HDMI порт для подключения внешний дисплеев
3D работает? Аппаратное видео кодирование и декодирование работает в ffmpeg/vlc/браузер? При подключении к монитору видео в браузере синхронизовано со сменой кадров (vsync) и не расслаивается?
меню многозадачности приятное
Sign up to leave a comment.
По следам #MWC16: Гаджеты Ubuntu — BQ Aquaris M10 и Meizu Pro 5 Ubuntu Edition