Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 297
Такой оптимист этот автор.
Положительно заряженный автор!
Не оптимист, а евангелист.
i.e. врун
Я этого не говорил.
В данном случае, возможно, скорее зеалот.
В данном случае, возможно, скорее зеалот.
По-русски пишется «зелот» от древнегреческого «ζηλωτής».
Zealot?
А почему не «зилот»?
О да, спасибо, «зилот» даже вероятнее.
Но, во всяком случае, не «зеалот».
Но, во всяком случае, не «зеалот».
Не путайте Гоголя с Гегелем, Гегеля с Бебелем, Бебеля с Бабелем. :)
Обе страницы — и «зелоты», и «зилоты» — объединены перекрёстными ссылками с призывами не путать эти термины. Слово же, лежащее в основе их обоих, одно и то же. Вся тонкость заключена в произношении буквы «η», различающимся для древнегреческого и новогреческого языков.
Обе страницы — и «зелоты», и «зилоты» — объединены перекрёстными ссылками с призывами не путать эти термины. Слово же, лежащее в основе их обоих, одно и то же. Вся тонкость заключена в произношении буквы «η», различающимся для древнегреческого и новогреческого языков.
Вообще в английской транскрипции "zealot" читается как «зелот», но никак не «зеалот».
Очень интересно, однако все еще осталось недопонимание. Кто будет делать смартфоны под эту ОС? Кто будет делать приложения под эту ОС? Как с портированием на другие платформы, на других осях для доступа к системе чаще всего нужен PhoneGap. Огромный вопрос про гайдлайны, они есть? Все таки, когда каждое приложение выглядит по своему, это печально. И возможно мне показалось, но отзывчивость интерфейса желает желать лучшего.
Пока только TCL Communication Technology (Alcatel) и ZTE. Первый такой телефон будет выпущен в Бразили, в начале следующего года. Приложения можем делать и мы с вами. Здесь список всех устройств, на которых уже сейчас можно запустить Firefox OS. Гайд по портированию. Немного информации о разработке приложений. Гайдов по UI судя по всему пока нету, но думаю, что скоро будут, если уже в следующем году первые устройства будут в продаже.
Вот гайд по UI если что — wiki.mozilla.org/Gaia/Design/BuildingBlocks
Вообще, большая часть информации о Firefox OS находится в wiki, а не в mdn.
Вообще, большая часть информации о Firefox OS находится в wiki, а не в mdn.
А зачем выпускать специальные нелефоны для открытой платформы? Чем вам не хватает продающихся дешевых android смартфонов по 100-300 баксов, родная ось на которых тормозит?
Обыкновенный пользователь дешевых тормозящих Андроидов никогда не займется самостоятельной переустановкой Адроида на xxxOS, чем бы xxx не был.
О, вы, видимо, не слыхали пословицу «все юзеры делятся на яблокофилов, виндофономанов, андроидолюбов и спиководов» (не точно).
Соль в том, что Samsung выпустила телефон i5700 Galaxy Spica, 3.5 дюйма экран, туча аппаратных кнопок, andriod 1.4.
В телефоне был 800 МГц samsung процессор и даже видеочип, под который, кстати, так дровы и не написал никто, даже производитель.
Андроиды развивались, а «спику» продавать было жалко в силу ее удобства и адекватности цены.
Тогда начались кастомы. ЧТо народ только ни придумывал, чтобы сделать из спики полноценный девайс на 2.х андроиде. И успехов было много. Но везде были глючки, подвисоны, перезагрузки.
Вплоть до того, что одна и та же прошивка на 10 устройствах вела себя по-разному.
Это провоцировало пользователей на постоянные перепрошивки всеми известными способами.
Сам пол года владел чудо-девайсом, лиш примерно раз в месяц, иногда чаще. В итоге так и не нашел компромисса и продал другу, который шил спику еще чаще, но компромисс таки нашел.
Еще хороший пример — HTC HD2, который изначально оснащен WM6.5, но работает как на Andriod, так и на WP7. И некоторые товарищи даже держат по две прошивки одновременно и по настроению пользуются попеременно.
Соль в том, что Samsung выпустила телефон i5700 Galaxy Spica, 3.5 дюйма экран, туча аппаратных кнопок, andriod 1.4.
В телефоне был 800 МГц samsung процессор и даже видеочип, под который, кстати, так дровы и не написал никто, даже производитель.
Андроиды развивались, а «спику» продавать было жалко в силу ее удобства и адекватности цены.
Тогда начались кастомы. ЧТо народ только ни придумывал, чтобы сделать из спики полноценный девайс на 2.х андроиде. И успехов было много. Но везде были глючки, подвисоны, перезагрузки.
Вплоть до того, что одна и та же прошивка на 10 устройствах вела себя по-разному.
Это провоцировало пользователей на постоянные перепрошивки всеми известными способами.
Сам пол года владел чудо-девайсом, лиш примерно раз в месяц, иногда чаще. В итоге так и не нашел компромисса и продал другу, который шил спику еще чаще, но компромисс таки нашел.
Еще хороший пример — HTC HD2, который изначально оснащен WM6.5, но работает как на Andriod, так и на WP7. И некоторые товарищи даже держат по две прошивки одновременно и по настроению пользуются попеременно.
А что до «обычный пользователь», то открытые платформы и обычный пользователь — не слишком рядом.
С портированием, кстати, всё очень просто. Например, с помощью Appcelerator.
В общем стоит с высокой вероятностью ожидать, что они достойно реализуют запатентованную в андроиде технологию динамичного подтормаживания интерфейса.
Думаете, Гугл их засудит?
Все необходимые патенты уже закуплены :)
Как владелец Nexus, могу с уверенностью сказать в 4.1 Google отказался от патента «динамичного подтормаживания интерфейса.». Mozilla может его бесплатно использовать
Любопытно, что сторонние сборки, включая известный Cyanogen, продолжают использовать эту популярную технологию, и по какой-то неизвестной причине не могут от неё полностью отказаться. Говорю, как владелец Nexus с CM10.
ArtRoman — так а кто вас заставляет их использовать? Меня ВСЕ устраивает в ванильном 4.1 (лукавлю, все кроме поисковой строки сверху) и даже не нужно Apex и Nova. Тут уж вам решать или рюшечки в виде профилей и тп или стабильность и плавность интерфейса. Я за второе. Поэтому Сток рулит и заруливает))
Как владелец Nexus (7) могу с уверенностью сказать, что в 4.1 действительно отсутствует фича подтормаживания, но в 4.2 они исправили этот досадный баг, и 4.2 (у меня, по крайней мере) тормозит иногда похлеще, чем старенький андроидофон.
А эта ОС случайно не нарушает патент Apple на иконку настроек в виде шестерёнки?
Очень странно выглядит привязка телефона именно к цене. Хотелось бы все же увидеть ТТХ этого девайса «за 50 фунтов». Для примера — за такую сумму можно взять андроидофон с 1ГГц процессором и 256 Мб памяти.
Автор сектант.
Даже на видео видны тормоза интерфейса. А что будет на смартфонах за 50 баксов? Их начнут ненавидеть, как и саму ось.
Там распери пи.
Кроме того видно что лагает сам скринкастинг.
Кроме того видно что лагает сам скринкастинг.
Слушайте, а вы не думали, что лагает из-за того, что это тот самый Otoro device за 50 баксов и на нём ОС которой ещё и года нет?
Ну если сейчас они не заложат аппаратное ускорение графики и JS, то потом это будет сделать невозможно. Вот и первое впечатление можно сильно подпортить.
Причем возможна та проблема, что есть у Андроида, но нет у Айфона — поддержка всего зоопарка оборудования. Тут либо строгая сертификация, либо только одна заточенная платформа. В топике про разработку игр под Андроид видели фотографию стола с сотней девайсов на Андроиде?
Причем возможна та проблема, что есть у Андроида, но нет у Айфона — поддержка всего зоопарка оборудования. Тут либо строгая сертификация, либо только одна заточенная платформа. В топике про разработку игр под Андроид видели фотографию стола с сотней девайсов на Андроиде?
Аппаратное ускорение там и так присутствует, другое дело, что какие другие участки кода не оптимизированы.
Кучу аднроид фонов видел. Только не могу понять причём тут конечный разработчик под FxOS. Вы спокон веков делали сайты под разные мониторы. Responsive Design это не так сложно как кажется.
На счёт сертификации возможно вы правы и вендорам устройств придётся подстраиваться под ту архитектуру, что будет. Но хочу напомнить, что Mozilla это некоммерческая организация, Apple или Google. И всё, что они могут это только сотрудничать с заинтересованными вендорами.
Кучу аднроид фонов видел. Только не могу понять причём тут конечный разработчик под FxOS. Вы спокон веков делали сайты под разные мониторы. Responsive Design это не так сложно как кажется.
На счёт сертификации возможно вы правы и вендорам устройств придётся подстраиваться под ту архитектуру, что будет. Но хочу напомнить, что Mozilla это некоммерческая организация, Apple или Google. И всё, что они могут это только сотрудничать с заинтересованными вендорами.
Текст писал не Стив Джобс? Ну, в смысле, вы поняли. Могут быть проблемы с Apple из за воспевающего стиля описания продукта)
как то в последнее время в html5 в качестве платформы для мобильных приложений стали разочаровываться… вон, и Цукерберг заявил, что отныне все аппы для фейсбука будут нативными.
B Firefox OS HTML5-приложения и будут нативными.
Вы один из тех наивных людей, которые прочитали одну новость с 3мя словами вырванными из контекста? А потом прочитать новости с заголовками «Что на самом деле имел введу Цукенберг говоря о HTML5» прочитать не судьба?
Так прдставители Мозиллы уже и сами успели по этому поводу высказаться- http://www.zdnet.com/mozilla-on-html5-heres-what-zuckerberg-really-meant-to-say-7000004146/.
Так представители Мозиллы уже и сами успели по этому поводу высказаться- http://www.zdnet.com/mozilla-on-html5-heres-what-zuckerberg-really-meant-to-say-7000004146/.
Звучит не плохо, однако не совсем понятно как будет реализована система безопасности firefox OS. Сегодня, это основная проблема как мобильных ОС так и веб. Если они предложат нечто революционное в этой области, то как раз это и будет настоящим прорывом.
Дайте авторам помечтать, единый DOM на всю систему и возможность подменить из любого скрипта любую функцию системных js-объектов, это ли не торжество гибкости и открытости.
С документацией о безопасности можно ознакомится здесь.
ОС должна быть на Си и асме. Точка. И не только ядро, но и гуи.
Хуже яваскрипта в эмбеддед могут быть только системные демоны на питон.
Хуже яваскрипта в эмбеддед могут быть только системные демоны на питон.
Современные джаваскриптовые движки не так уж и уступают Си по скорости.
А придёт IonMonkey — вообще веселье начнётся.
А придёт IonMonkey — вообще веселье начнётся.
Я даже больше скажу. В андроиде вон Java. И не тормозит. Браузер в андроиде. На Java. И тоже не тормозит.
В B2G (уж извините, называю по старинке) Gecko на нативном коде. Почему он должен тормозить?
В B2G (уж извините, называю по старинке) Gecko на нативном коде. Почему он должен тормозить?
Браузер в андроиде не на java. Он на webkit который является компонентом системы и выполняется в нативном коде.
Ну в таком случае сорри.
Но всё равно — если не тормозит webkit на нативном коде, то почему должен тормозить gecko?
P. S. А огнелис под android тоже на нативном коде?
Но всё равно — если не тормозит webkit на нативном коде, то почему должен тормозить gecko?
P. S. А огнелис под android тоже на нативном коде?
то почему должен тормозить gecko?
У них местами движок более тяжелый, необходимо оптимизировать.
А огнелис под android тоже на нативном коде?
Насколько знаю да. NDK доступно под Android давненько.
Конечно в нативном. Не так просто взять и переписать 150Мб кода из c++ в java.
И я также больше скажу: есть средства для компиляции Си и Си++ в JavaScript. Из которых наиболее известен Emscripten.
Ну давайте вы переведёте код на C/C++ в JS и запустите его в IonMonkey, а я скомпиляю его посредством ICC с -O3 IPO и PGO. А потом сравним производительность ;-)
В JS вообще компилится всё, что не лень: Ruby, Python, perl, scala, java, c#, даже lisp и haskell.
Ну, собственно, ссылка: github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Ну, собственно, ссылка: github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
Не тормозит? Java не тормозит? Ну и шутки у Вас…
GUI на C и асме? Что вы курите?
Ничего. МакОС, вынь, кде, гном= гуй си + асм.
В МакОСи Objective-C, который от C и асма достаточно далек.
KDE — это Qt, который от C и асма тоже весьма и весьма далек (вплоть до аналога GC на подсчете ссылок).
KDE — это Qt, который от C и асма тоже весьма и весьма далек (вплоть до аналога GC на подсчете ссылок).
Гном — гуй на js.
смысл не в языке, а в минимуме прослоек.
Ну, всё же подсчёт ссылок — это далеко не GC.
Я знаю. Просто в Qt можно делать что-то типа такого:
И оппа. Все само собой почистится и, если надо, из памяти удалится :)
Я это называю «GC для бедных». Потому что в общем и целом программировани с использованием Qt ничем не отличается от программирования на Java/.NET. Программист по возможности максимально огорожен от каких-либо низкоуровневых действий.
Но из-за того, что это С++, у некоторых людей начинаются непроизвольные оргазмы «это же!!! С++!!!» :) Хотя оно работате со скоростью того же дотнета :)
QWidget1 *a = new QWidget1();
QWidget2 *b = new QWidget2();
QWidget3 *c = new QWidget3();
QWidget4 *d = new QWidget4();
d -> addWidgets(a,b,c);
// и потом вообзе в друго месте
delete d;
И оппа. Все само собой почистится и, если надо, из памяти удалится :)
Я это называю «GC для бедных». Потому что в общем и целом программировани с использованием Qt ничем не отличается от программирования на Java/.NET. Программист по возможности максимально огорожен от каких-либо низкоуровневых действий.
Но из-за того, что это С++, у некоторых людей начинаются непроизвольные оргазмы «это же!!! С++!!!» :) Хотя оно работате со скоростью того же дотнета :)
В приведенном примере структура напоминает дерево. Если один виджет владеет остальными и может их удалить в деструкторе, то это ни разу не GC. Это как приводить в пример связный список и говорить что это GC.
Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
Я и это знаю :) Я веду к тому, что Qt максимально изолирует разработчика от низкоуровневости C++. Код с использованием Qt мало чем отличается от кода, написанного на дотнете, наример. При этом использовать низкоуровневые вещи (да даже и высокоуровневые, типа шаблонов) достаточно опасно, потому что можно порушить всю эту хрупкую красоту.
А производительность Qt — ну так, так себе.
> использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
Ну так это относится не только к Qt ;) Никто не мешает в критичных к скорости кусках на Ruby/Python/.NET/вставить_свое использовать библиотеки на С/С++ ;)
А производительность Qt — ну так, так себе.
> использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
Ну так это относится не только к Qt ;) Никто не мешает в критичных к скорости кусках на Ruby/Python/.NET/вставить_свое использовать библиотеки на С/С++ ;)
Я просто обычно использую Qt для связи с интерфейсом и т.п., а если в процессе появляется например необходимость обсчитать какую-нибудь рабочую область какого-нибудь невероятного устройства или проложить какой-нибудь хитро-выделанный маршрут на невероятных размеров карте, то создаем обычный класс и, никуда не переключаясь, в C-style пишем все быстро и оптимально. Идеологически это конечно не совсем тру, но «какого черта, мне надо чтобы программа в этом месте выжала максимум из компьютера!» :)
На той же яве реализовать такой подход было бы ИМХО труднее.
P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
На той же яве реализовать такой подход было бы ИМХО труднее.
P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
Ну и как этот подсчет ссылок влияет на скорость работы если эти все видгеты разрушаются один раз и одновременно? При закрытии окна приложения еще скорее всего к тому ж.
В данном случае это даже не подсчёт ссылок. QObject может иметь родителя и только одного. Родитель знает обо всех своих детях. При собственнос уничтожении, он уничтожает и детей. Логика простая.
PS да, я тоже люблю Qt. А ещё COW замечательная штука.
PS да, я тоже люблю Qt. А ещё COW замечательная штука.
в конечном счете — все на асме :-))
Меня вообще умиляют всякие вендройд-пейсатели, которые не знают даже, как на ARM'е прибавить к переменной в памяти значение (на асме). Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа. Не знаю как для вас, но для меня это абсолютный нонсенс.
Это может вам не нравиться, но это цель, к которой ведет прогресс в языках программирования.
Наращивают уровни абстракции, вытесняя низкоуровневое — когда-то на асме писали все, потом его вытеснили до уровня вставок, сейчас вытеснили почти полностью, причем даже из эмбеддед, на его место пришел «среднеуровневый» С.
Даже С++ из прикладного активно вытесняется, добавляя еще один уровень абстракции в виде ВМ — явами, дотнетами, даже теми же питонами.
Наращивают уровни абстракции, вытесняя низкоуровневое — когда-то на асме писали все, потом его вытеснили до уровня вставок, сейчас вытеснили почти полностью, причем даже из эмбеддед, на его место пришел «среднеуровневый» С.
Даже С++ из прикладного активно вытесняется, добавляя еще один уровень абстракции в виде ВМ — явами, дотнетами, даже теми же питонами.
Вытеснили-не вытеснили это я могу поспорить. Берем ffmpeg и какой-нибудь абстрактный MIPS-процессор от всем известного кетайского ноунейма. Девайс — ну пусть будет электронная книжка. И что же мы видим в ffmpeg? Тонны SIMD инструкций на асме, типа конвертации цветов, ресайза и прочего. И так много где в разных девайсах. Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.
Я понимаю, что против течения плыть смысла нет, и если что-то нужно нопейсать на андройде, то выбора особого нет. Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
Я понимаю, что против течения плыть смысла нет, и если что-то нужно нопейсать на андройде, то выбора особого нет. Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
>Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.
Это и значит что вытеснили. Количество мест где он остался катастрофически мало — ну да, в кодеках где-то в глубине может остаться. Но количество таких мест сокращается. Не говоря уж о том, что все больше таких жрущих вещей интегрируют на аппаратном уровне в SoC, те же кодеки.
>Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
Я не уверен, что негодование на форумах — это прямо хорошо. В конце концов, если это выбор юзеров, значит им нравится этот калькулятор. Если вы не пишете свой, на удобном вам языке, который сможет вытеснить тот, 50-метровый — то это негодование лишено смысла. Если вы напишете его, но он будет проигрывать в юзабилити, в качестве интерфейса и т.п., пользователям будет глубоко плевать на то, что он весит в десять раз меньше.
А скорость разработки (и отладки и рефакторинга) сильно падает со снижением уровня языка.
Это и значит что вытеснили. Количество мест где он остался катастрофически мало — ну да, в кодеках где-то в глубине может остаться. Но количество таких мест сокращается. Не говоря уж о том, что все больше таких жрущих вещей интегрируют на аппаратном уровне в SoC, те же кодеки.
>Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
Я не уверен, что негодование на форумах — это прямо хорошо. В конце концов, если это выбор юзеров, значит им нравится этот калькулятор. Если вы не пишете свой, на удобном вам языке, который сможет вытеснить тот, 50-метровый — то это негодование лишено смысла. Если вы напишете его, но он будет проигрывать в юзабилити, в качестве интерфейса и т.п., пользователям будет глубоко плевать на то, что он весит в десять раз меньше.
А скорость разработки (и отладки и рефакторинга) сильно падает со снижением уровня языка.
Задачи обработки видео очень специфичные!
Трудно что-то поделать с современной разработкой ПО — уже почти никто не заботится о том, чтобы программа нормально работала на устройстве пользователя, мой любимый пример — разница в скорости работы 2008 и 2010 MS VS. Даже в MS при разработке конечного несистемного продукта не особо думали об экономии, чег ждать от кустарных разработчиков или из них поднявшихся — коих большинство среди Android девелоперов.
Трудно что-то поделать с современной разработкой ПО — уже почти никто не заботится о том, чтобы программа нормально работала на устройстве пользователя, мой любимый пример — разница в скорости работы 2008 и 2010 MS VS. Даже в MS при разработке конечного несистемного продукта не особо думали об экономии, чег ждать от кустарных разработчиков или из них поднявшихся — коих большинство среди Android девелоперов.
> Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа.
Ну-ка ну ка. Вы точно знаете, во какие инструкции оптимизирующий компилятор разворачивает ваш код на разных процессорах? На x86? На ARMе? С набором инструкций SSE2? SSE3? С оптимизацией по скорости? С оптимизацией по размеру?
Да нифига. Вы даже близко не имеете представления.
Ну-ка ну ка. Вы точно знаете, во какие инструкции оптимизирующий компилятор разворачивает ваш код на разных процессорах? На x86? На ARMе? С набором инструкций SSE2? SSE3? С оптимизацией по скорости? С оптимизацией по размеру?
Да нифига. Вы даже близко не имеете представления.
А если таки имею представление? На ARMе мало пишу, поэтому тут да, точно не знаю. А вот с x86 могу с вами поспорить. Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме. И да, я знаю как будет с оптимизацией по скорости или по размеру. Матрицы между собой не множу, поэтому SSE2, SSE3 не использую.
> А если таки имею представление?
Тогда вы входите в 0.01% разработчиков. Не потому что разработчики тупые, а потому что оптимизирующие компиляторы слишком умные и стандарты слишком огромные.
> Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме.
Вот насчет четкости я очень сильно сомневаюсь. Хотя, повторю, вы можете входить в 0.01% разработчиков, которые досконально знают стандарт соответствующего ЯВУ и все особенности целевой платформы.
А для использования SSEx и не надо матрицы перемножать.
Тогда вы входите в 0.01% разработчиков. Не потому что разработчики тупые, а потому что оптимизирующие компиляторы слишком умные и стандарты слишком огромные.
> Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме.
Вот насчет четкости я очень сильно сомневаюсь. Хотя, повторю, вы можете входить в 0.01% разработчиков, которые досконально знают стандарт соответствующего ЯВУ и все особенности целевой платформы.
А для использования SSEx и не надо матрицы перемножать.
Это правда. Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера, потому что примерно знаю какой код С++ как реализован. Я точно знаю где происходит аллокация и деаллокация. Я точно знаю это и могу рассматривать детерминированные сценарии использования памяти. Я не боюсь, что в какой-то момент запустится мусоросборщик и всё зависнет.
Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.
Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.
Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.
Тогда спрашивается — НАФИГА было затеваться с Явой?
Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.
Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.
Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.
Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.
Тогда спрашивается — НАФИГА было затеваться с Явой?
Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.
Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
Вот действительно. У меня недавно умер HTC Inspire 4G, хожу опять со старым HTC Herald под WM 6.5, с 200мгц процессором и 64 мб оперативки. И ничего, все работает достаточно шустро, оперативки хватает на 3-5 приложений, потому что тогда заботились об оптимизации, а сейчас — нет.
А джаву вообще-то пилили — был такой проект, gcj, так он компилировал джава-код до версии 1.5 в нэйтивы с использованием как раз-таки gcc, как я понимаю. К сожалению, его забросили, а значит это не пользовалось спросом.
А вообще с джавой есть смысл затеваться. Она намного комфортнее и быстрее для разработки, чем любой другой язык старше ее из мне известных. И всем пофигу, что она где-то может быть не так эффективна в исполнении. 5 лет назад, я бы сказал, что на джаве гораздо сложнее сделать критические ошибки, чем на сях. Теперь я думаю, что и джава плохой язык, потому что они тоже зафиксировали стандарт — теперь надо переходить на следующий уровень — котлин, например.
А вообще с джавой есть смысл затеваться. Она намного комфортнее и быстрее для разработки, чем любой другой язык старше ее из мне известных. И всем пофигу, что она где-то может быть не так эффективна в исполнении. 5 лет назад, я бы сказал, что на джаве гораздо сложнее сделать критические ошибки, чем на сях. Теперь я думаю, что и джава плохой язык, потому что они тоже зафиксировали стандарт — теперь надо переходить на следующий уровень — котлин, например.
> люди серьёзные приложения не сравнивали
Что такое «серьезные приложения»?
> Тогда спрашивается — НАФИГА было затеваться с Явой?
Потому что они хотели больше контроля над системой, например?
Что такое «серьезные приложения»?
> Тогда спрашивается — НАФИГА было затеваться с Явой?
Потому что они хотели больше контроля над системой, например?
Ява даёт больше контроля над системой, чем С++? Я верно понял ваш тезис?
Ява может дает больше контроля производителю над тем, что понапишут горе-программисты :)
Что такое «контроль производителя»?
Что разработчик не сожрет память, не оставить память течь и т.п.
В С++ при правильном подходе у разработчика также будет изъята возможность устраивать проблемы с памятью (я писал об этом статью в своё время).
Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
> Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера
Аналогично для любого ЯВУ :-\ Потому что на первом месте алгоритмы, а потом уже то, во что оно компилируется. Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
Аналогично для любого ЯВУ :-\ Потому что на первом месте алгоритмы, а потом уже то, во что оно компилируется. Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
Профайлер вам не покажет, что вообще ВСЁ в Яве делается медленнее, чем в С++. Начиная от обращения к переменной, и заканчивая работой с динамической памятью. Вы лишь увидите наиболее относительно медленные участки. Вот только относительно чего? Вы же не уберёте мусоросборщик, не поменяете внутреннюю логику работы с переменными (там где С++ работает со стеком процессора, меняя всего один его регистр).
И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
> Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++.
Нет. Как всегда, на хабре люди не умеют читать. Вот, что я написал:
Тут не говорится, что Java быстрее C++.
Нет. Как всегда, на хабре люди не умеют читать. Вот, что я написал:
Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
Тут не говорится, что Java быстрее C++.
Понимаете, всё это не объясняет, почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.
Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
Потому же, почему подавляющее большинство энтерпрайз систем не на С++, а на managed-языках типа явы и дотнета.
Выше скорость разработки, проще поддерживать код, больше ошибок ловится на стадии компилляции.
Выше скорость разработки, проще поддерживать код, больше ошибок ловится на стадии компилляции.
Если сравнивать Яву с С++ и фремворками образца начала 2000-х, то скорость разработки безусловно выше. С тех пор многое поменялось. Вот не самый свежий пример:
www.ultimatepp.org/www$uppweb$vsswing$en-us.html
www.ultimatepp.org/www$uppweb$vsswing$en-us.html
> почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.
Вы вообще сейчас про что? Про Яву вообще или только про Андроид.
Если про Яву вообще, то причины, по которой она создавалась, можно почитать в той же Википедии. Если в общем говорить, не только про Яву, то С++ не позволяет огромное количество вещей. Например, ФП в него надо заколачивать гвоздями, и результат выглядит не просто убого, а сверхубого. И это только вершина айсберга.
Для большинста прикладных задач хватает любых языков, и С++ там не поможет.
Вы вообще сейчас про что? Про Яву вообще или только про Андроид.
Если про Яву вообще, то причины, по которой она создавалась, можно почитать в той же Википедии. Если в общем говорить, не только про Яву, то С++ не позволяет огромное количество вещей. Например, ФП в него надо заколачивать гвоздями, и результат выглядит не просто убого, а сверхубого. И это только вершина айсберга.
Для большинста прикладных задач хватает любых языков, и С++ там не поможет.
Отлично! Забыли про динамическую память, теперь говорим про ФП.
Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
Гы, так linq + ef и спроектирован для enterprise, чтобы писать так:
Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
var BestCustomer = OrdersDatabase.Orders
.Where(order => order.IsBonus == false && order.Sum > 10000)
.GroupBy(order => order.Customer)
.OrderBy(group => group.Count)
.Select(group => group.Key)
.Last();Транслируется в 1 sql-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
Как я говорил выше, подобный уровень удобства давно уже дают фреймворки в С++. И давно уже есть компиляция (compile-time!) на необходимый диалект SQL. Например, вот так.
Это всё дикие костыли. Без поддержки Expression Trees в языке невозможно добавлять свои SQL-функции, специфичные для СУБД, без влезания во фреймворк.
Что значит костыли? Кусок, отодранный из Cω, и добавленный спустя пять лет после разработки основного языка, это не костыли?
Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.
Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.
Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
Нет, пример не работает ))))
Это голый SQL. Я хочу полноценную объектную модель, чтобы положить клиенту в список заказов новый заказ, сказать Save и заказ сохранился и привязался к клиенту.
Я хочу не писать Join-ы руками, как в ваших примерах,
.From(Order)
.FullJoin(Customer)
.On(COLUMN.Of(Order) == COLUMN1.Of(Customer))
.FullJoin(City)
.On(COLUMN.Of(City) == COLUMN1.Of(Customer))
а тупо сделать .Where(order => order.Customer.City.Name='Москва')
А два join-а фреймворк сделал сам. Разница, как между Фортраном и Паскалем.
А функции… Например, bin_and(x,y) или «Customer.Name starting with 'Пет' » в Firebird. Имелось ввиду, каких это затащить в синтаксис Where, чтобы пользоваться плюшками СУБД и генератора SQL одновременно
Это голый SQL. Я хочу полноценную объектную модель, чтобы положить клиенту в список заказов новый заказ, сказать Save и заказ сохранился и привязался к клиенту.
Я хочу не писать Join-ы руками, как в ваших примерах,
.From(Order)
.FullJoin(Customer)
.On(COLUMN.Of(Order) == COLUMN1.Of(Customer))
.FullJoin(City)
.On(COLUMN.Of(City) == COLUMN1.Of(Customer))
а тупо сделать .Where(order => order.Customer.City.Name='Москва')
А два join-а фреймворк сделал сам. Разница, как между Фортраном и Паскалем.
А функции… Например, bin_and(x,y) или «Customer.Name starting with 'Пет' » в Firebird. Имелось ввиду, каких это затащить в синтаксис Where, чтобы пользоваться плюшками СУБД и генератора SQL одновременно
И эти фреймворки будут работать с такой же скоростью, как и аналогичные на не-С++. Чудес не бывает.
Простите, а вы сколько программ на этих фреймворках написали, чтобы это говорить? )
«Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
«Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
Главный недостаток предложенного фреймфорка — это трансляция в голый SQL, когда нормальные ORM умеют мапить объект по нескольким таблицам, поддерживают наследование, lazy-загрузку по ссылкам, поддержку отношений 1-ко-многим и их lazy-загрузку либо генерацию sql по аггрегированным запросам к ним т.п.
Да, этого нет. И здесь я бы воспользовался возможностью динамической генерации кода — но без ненужных свистелок вроде мусоросборщика и лишних проверок. Что касается отложенного исполнения — это очень серьёзный вопрос, я бы не стал однозначно высказываться за его наличие в том виде, как оно подаётся сейчас. Мне сейчас недостаёт контроля над отложенными операциями, что критично при закрытии программы или окна, например.
Если бы было что-то подобное, локально-динамическое и гибкое для С++ — я бы задумался о переходе. Без огромных виртуальных машин (они могут быть локальные и очень маленькие), без оверхеда по памяти и мусоросбощика и прочего.
Если бы было что-то подобное, локально-динамическое и гибкое для С++ — я бы задумался о переходе. Без огромных виртуальных машин (они могут быть локальные и очень маленькие), без оверхеда по памяти и мусоросбощика и прочего.
Никто ничего не забыл. Был один из возможных ответов, почему некоторые задачи не решаются фреймворками на C++.
C++ — не панацея. Это достаточно неудобный и достаточно низкоуровненвый язык. Он банально не подходит для решения большинства задач.
Ява появилась, потому что нужен был язык с гарантией типизации и защитой памяти, которую С++ (особенно на начало 90-х) представить не мог (а благодаря наличию C-style cast не может гарантировать типизацию и сейчас).
Другие языки появлялись и будут появляться, потому что С++/Java/C#/вписать_свое не дают решения каких-либо других задач.
При этом вздохи «ах, эти все языки медленнее, чем C++» можно смело отправлять в /dev/null, потому что
C++ — не панацея. Это достаточно неудобный и достаточно низкоуровненвый язык. Он банально не подходит для решения большинства задач.
Ява появилась, потому что нужен был язык с гарантией типизации и защитой памяти, которую С++ (особенно на начало 90-х) представить не мог (а благодаря наличию C-style cast не может гарантировать типизацию и сейчас).
Другие языки появлялись и будут появляться, потому что С++/Java/C#/вписать_свое не дают решения каких-либо других задач.
При этом вздохи «ах, эти все языки медленнее, чем C++» можно смело отправлять в /dev/null, потому что
профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
1. Защита памяти.
И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.
2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.
И что же мы получаем за эти неочевидные преимущества:
— замедление работы кода в несколько раз
— потребление памяти в 10-30 раз больше
Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.
2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.
И что же мы получаем за эти неочевидные преимущества:
— замедление работы кода в несколько раз
— потребление памяти в 10-30 раз больше
Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
> И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++?
У разработчика средней руки — да.
> И что же мы получаем за эти неочевидные преимущества:
> — замедление работы кода в несколько раз
> — потребление памяти в 10-30 раз больше
Боже. Вы научитесь хоть когда-нибудь читать?
Для подавляющего большинства прикладного кода это некритично.
У разработчика средней руки — да.
> И что же мы получаем за эти неочевидные преимущества:
> — замедление работы кода в несколько раз
> — потребление памяти в 10-30 раз больше
Боже. Вы научитесь хоть когда-нибудь читать?
Для подавляющего большинства прикладного кода это некритично.
> Для подавляющего большинства прикладного кода это некритично.
Как я говорил выше, против религии аргументы бессильны. Если для вас всё о чём говорилось — некритично, то обсуждать просто нечего.
Как я говорил выше, против религии аргументы бессильны. Если для вас всё о чём говорилось — некритично, то обсуждать просто нечего.
Ну, религия только у вас. Это вы тут считаете С++ и фреймворки на нем панацеей от всего.
Например, в GUI C++ не нужен даже даром. Там важно не мифическое «в два-три раза быстрее», а отзывчивость интерфейса. Которое, очень грубо говоря, ограниченно порогом моргания человека (~50ms, емнип), и это обеспечивает любой язык программирования влегкую.
В вебе С++ не нужен даже даром, потому что приложение сначала упрется в ограничения (нативной!) базы данных и/или (нативной!) сетке прежде, чем начнутся проблемы собственно с приложением.
GUI + Веб сейчас покрывают ~70-90% прикладных направлений.
И только для оставшихся, где нужна высокая производительность (низкоуровневое, системное, графика, видео) С++ вполне подойдет.
Я же говорю: вы неспособны читать, что вам пишут, ибо С++ застил вам глаза
Например, в GUI C++ не нужен даже даром. Там важно не мифическое «в два-три раза быстрее», а отзывчивость интерфейса. Которое, очень грубо говоря, ограниченно порогом моргания человека (~50ms, емнип), и это обеспечивает любой язык программирования влегкую.
В вебе С++ не нужен даже даром, потому что приложение сначала упрется в ограничения (нативной!) базы данных и/или (нативной!) сетке прежде, чем начнутся проблемы собственно с приложением.
GUI + Веб сейчас покрывают ~70-90% прикладных направлений.
И только для оставшихся, где нужна высокая производительность (низкоуровневое, системное, графика, видео) С++ вполне подойдет.
Я же говорю: вы неспособны читать, что вам пишут, ибо С++ застил вам глаза
> Это вы тут считаете С++ и фреймворки на нем панацеей от всего.
Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.
Что касается остального потока сознания в вашем комментарии, я не буду ничего писать по причине, изложенной выше. Предлагаю вам прекратить этот бессмысленный диалог.
Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.
Что касается остального потока сознания в вашем комментарии, я не буду ничего писать по причине, изложенной выше. Предлагаю вам прекратить этот бессмысленный диалог.
А еще потому, что для большинства приложений и профайлер не потребуется запускать — приложение будет работать «достаточно быстро». Ну а там, где будет работать недостаточно быстро, зачастую можно будет докупить/заменить железо, что в итоге выйдет дешевле оптимизации кода.
Если отвлечься от практики и потеоретизировать, направление на managed-среды в ОСестроительстве давно просматривается (Microsoft чтобы внезапно не оказаться отставшей понемногу тоже пилит).
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».
Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
Очень интересно будет посмотреть на производительность этой системы. )
А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
Этакий anti-unix way.
А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
Этакий anti-unix way.
На всякий случай — это такое заглядывание в далёкое и неизбежное будущее, я не говорю, что сейчас так надо делать.
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).
Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
Это вообще несерьезно. С тем же успехом можно сказать «если вдруг что с ядром то падает вообще весь юзерспейс» — что, кстати, весьма частое явление при падении дров. Разумеется, если падает низкий уровень, то отвалится и все остальное, или если у вас ядро выпадет с бсодом или паником, юзерспейс останется живым?)
А подобные системы есть, дотнет микрофреймворк допустим.
А подобные системы есть, дотнет микрофреймворк допустим.
>Тогда спрашивается — НАФИГА было затеваться с Явой?
Это вы сейчас про Android? А как быть с зоопарком процессоров? На телефоны ставить gcc, из маркета скачивать исходники и компилировать на месте?
Это вы сейчас про Android? А как быть с зоопарком процессоров? На телефоны ставить gcc, из маркета скачивать исходники и компилировать на месте?
Скажите, а вы точно знаете что происходит в двигателе вашей машины, когда вы включаете зажигание? В каком порядке следуют циклы, без подсматривания в википедию, знаете? Какие сигналы посылает контроллер форсункам? Вам надо это знать чтобы доехать из точки А в точку Б?
Да, я точно знаю что происходит в двигателе моего автомобиля. Начинал с обычного карбюраторного, а сейчас инжектор.Без подсматривания в википедию.
Я поздравляю вас, что вы всё точно знаете )
Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
А ниже электротехники есть ещё физика.
Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
А ниже электротехники есть ещё физика.
Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
Всё зависит от задачи.
Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).
Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).
Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
Знаете, я в корне не согласен, что это нужно знать. Я вот например проектирую средние и большие корпоративные приложения. Несколько БД, сети, GUI на разных языках и платформах. Если бы я вдавался в детали реализации той или иной операции на уровне ассемблера я не смог бы сфокусироваться на архитектуре в целом. Да меня даже не интересует порой как тот или иной запрос работает на разных СУБД, пока конечно этот запрос не начнет создавать проблемы. Современная парадигма программирования позволяет мне абстрагироваться от деталей реализации нижних уровней, так зачем мне о них знать? Тем более если эти детали работают так как заявлено.
Ни в коем случае не спорю с тем, что вы говорите! Полностью согласен.
Я говорю об уровне с которого нужно уметь писать свои фреймворки. Там в их внутренности нужно разбираться детально.
А если говорить об уровне приложений, то разбираться конечно не обязаны. Нужно лишь уметь примерно качественно оценить затраты той или иной функции (хотя бы на уровне O(n) или O(nlog(n)) и т.д.)
Я говорю об уровне с которого нужно уметь писать свои фреймворки. Там в их внутренности нужно разбираться детально.
А если говорить об уровне приложений, то разбираться конечно не обязаны. Нужно лишь уметь примерно качественно оценить затраты той или иной функции (хотя бы на уровне O(n) или O(nlog(n)) и т.д.)
Вы уж не обижайтесь, но вы абсолютно не лучше тех, кто пишет демоны на Python, и ОС на JavaScript. Вы такой же фанатик, и рассуждаете также фанатично.
Ясное дело, что представлять как работает железо, и что там происходит — полезно. Но как было и ниже сказано, и выше, языки программирования развиваются в сторону повышения абстракции. Это не хорошо, и не плохо — это нормальная реакция на реалии разработки ПО.
И сейчас нормальное дело, что есть такие низкоуровневые ниндзя как вы к примеру, хорошо понимающие нижние слои абстракции, и есть ниндзя которые виртуозно разрабатывают на языках высокого уровня. Разные потребности, разные задачи, разные специализации.
Давайте просто каждый будет заниматься своим делом, и не лезть со своим уставом в чужой монастырь, просто потому что, ваши взгляды не совпадают со взглядами людей, которые занимаются совершенно другими задачами или проводят эксперимент в проекте, в котором вы не принимаете участие. Может оно кажется диким, но если они могут провести эксперимент — почему нет, вдруг что-то выйдет?
Ясное дело, что представлять как работает железо, и что там происходит — полезно. Но как было и ниже сказано, и выше, языки программирования развиваются в сторону повышения абстракции. Это не хорошо, и не плохо — это нормальная реакция на реалии разработки ПО.
И сейчас нормальное дело, что есть такие низкоуровневые ниндзя как вы к примеру, хорошо понимающие нижние слои абстракции, и есть ниндзя которые виртуозно разрабатывают на языках высокого уровня. Разные потребности, разные задачи, разные специализации.
Давайте просто каждый будет заниматься своим делом, и не лезть со своим уставом в чужой монастырь, просто потому что, ваши взгляды не совпадают со взглядами людей, которые занимаются совершенно другими задачами или проводят эксперимент в проекте, в котором вы не принимаете участие. Может оно кажется диким, но если они могут провести эксперимент — почему нет, вдруг что-то выйдет?
Ждем проекта Boot2Excel от Microsoft. Операционная система на макросах и формулах Office. VBScript в массы!
Времена Бейсика прошли. Джаваскрипт — это Бейсик сего дня!
И это очень грустно. Есть несколько гораздо более удобных языков, вроде Python или Ruby. Но в бейсики всегда выбиваются какие-то бейсики.
js среди динамических языков занимает место, которое принадлежит C++ у статических.
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
Могу ли я услышать от Вас, чем Python гораздо удобнее по сравнению с JavaScript?
Скобочек меньше :) А если серьёзно, то очень не хватает в JS нормальной модульности. Ну и плюс многим удобнее иметь дело с сильной типизацией, а не слабой.
Ну вроде готовят EcmaScript 6 с модульностью, питонистостью и рубистостью. =)
Но ИМХО, JS должен оставаться таким как есть, и не быть затычкой везде где можно. Даешь Ruby и Python как дефакто на мобильных платформах
Но ИМХО, JS должен оставаться таким как есть, и не быть затычкой везде где можно. Даешь Ruby и Python как дефакто на мобильных платформах
Пишите джаваскриптом на движке Node.js — там модульность, насколько я могу судить по опыту, не ненормальная.
Насколько я знаю, там модульность эмулируется через объекты.
ИМХО, но не стоит делать JS затычкой для всего. Не буду вдаваться в холивары, но лично мое мнение — JS не про server-side. Он мне нравится как язык для клиентской разработки. Для server-side есть более подходящие и мощные языки и технологии.
Не знаю. Как по мне было бы намного лучше если бы они шли немного в другом направлении, например компиляции Javascript кода в бинарный код под конкретную платформу. Естественно многие динамические фичи станут недоступны, появится какой-то Javascript-C. Но проблема производительноси была бы решена? Знающие люди подскажите, неужели так сложно создать компилятор Javascript в машинный код? Причем компилировать можно ведь прямо во время установки приложения, под конкретную платформу.
Но зачем?
Всё равно производительность будет другой.
Во-первых, на лету скомпилировать также качественно не удастся. Оптимизирующий компилятор того же С++ (в режиме полной оптимизации) требует совсем других времён и совсем другой памяти — ничего этого в маленьком устройстве может не быть, не говоря уже о том, что это сотни мегабайт данных, которые динамически генерятся и «перевариваются» процессором.
Всё, на что можно рассчитывать в JIT — это баланс между скоростью и памятью при компиляции против её качества. Как правило, не в пользу качества.
Но это ещё не всё! Как ты ни компилируй, у тебя останутся свистелки вроде фонового мусоросборщика, дополнительных накладных расходов памяти при аллокации, и самое главное — проблемы скорости динамических переменных. Работа с переменной в С++ не сравнится с той же задачей в Яваскрипт. Там, где С++ обходится простым вызовом процессорной инструкции, Яваскрипт осуществит массу проверок, выполнит массу кода, прежде чем перейдёт к непосредственной работе. И эта проблема ПРИНЦИПИАЛЬНО не решается оптимизирующей компиляцией, это логика работы динамических языков.
Якобы, это спасает от проблем времени выполнения. На практике, даже этот довод оказывается очень спорным: от действительно серьёзных проблем в логике программы, динамическое программирование всё равно не спасает — программа, даже если не упадёт, то окажется неработоспособной. По сути, на практике выясняется, что нужна та же самая работа по отладке, что и в неконтролируемой среде.
Да, динамическое программирование позволяет делать некоторые «финты», которые в ряде случаев уменьшают затраты на разработку. Но извините, пользователю пофигу на это всё: ему важно, чтобы программа на его не самом мощном устройстве хорошо и быстро работала. А по этой характеристике, динамические языки позади статических. Особенно, на слабых процессорах с минимумом оперативной памяти.
Во-первых, на лету скомпилировать также качественно не удастся. Оптимизирующий компилятор того же С++ (в режиме полной оптимизации) требует совсем других времён и совсем другой памяти — ничего этого в маленьком устройстве может не быть, не говоря уже о том, что это сотни мегабайт данных, которые динамически генерятся и «перевариваются» процессором.
Всё, на что можно рассчитывать в JIT — это баланс между скоростью и памятью при компиляции против её качества. Как правило, не в пользу качества.
Но это ещё не всё! Как ты ни компилируй, у тебя останутся свистелки вроде фонового мусоросборщика, дополнительных накладных расходов памяти при аллокации, и самое главное — проблемы скорости динамических переменных. Работа с переменной в С++ не сравнится с той же задачей в Яваскрипт. Там, где С++ обходится простым вызовом процессорной инструкции, Яваскрипт осуществит массу проверок, выполнит массу кода, прежде чем перейдёт к непосредственной работе. И эта проблема ПРИНЦИПИАЛЬНО не решается оптимизирующей компиляцией, это логика работы динамических языков.
Якобы, это спасает от проблем времени выполнения. На практике, даже этот довод оказывается очень спорным: от действительно серьёзных проблем в логике программы, динамическое программирование всё равно не спасает — программа, даже если не упадёт, то окажется неработоспособной. По сути, на практике выясняется, что нужна та же самая работа по отладке, что и в неконтролируемой среде.
Да, динамическое программирование позволяет делать некоторые «финты», которые в ряде случаев уменьшают затраты на разработку. Но извините, пользователю пофигу на это всё: ему важно, чтобы программа на его не самом мощном устройстве хорошо и быстро работала. А по этой характеристике, динамические языки позади статических. Особенно, на слабых процессорах с минимумом оперативной памяти.
Firefox OS является началом чего-то невероятного. Это ожидающая своего пробуждения революция. Глоток свежего воздуха. Кульминация новейших технологий. Оно волшебно и оно изменит все.
Ваша революция была отлично реализована в Palm WebOS и на ней даже существовали аппараты. И если выйдут аппараты на FirefoxOS я его даже куплю чтобы перешить на WebOS.
А почему вы ждете аппарата на firefox os, чтобы перешить под webos? Сейчас что мешает? Берете любой телефон и развлекайтесь. Проблемы будут точно такими же, загрузчик могут лочить, не будет драйверов под железо и т.п.
Проблемы будут точно такими же, загрузчик могут лочить, не будет драйверов под железо и т.п.
Не будет. Потому что FirefoxOS. Его фишка в открытой аппаратной базе в том числе. К тому же открытая версия WebOS только только вышла.
А можно посильнее раскрыть слова «открытая аппаратная база»?
Сейчас процентов 80 функциональности смартфонов заключено в центральной SoC. А на них вендоры категорически отказываются отдавать даташиты. Дают только производителям под NDA.
Откуда тогда открытая аппаратная база?
Сейчас процентов 80 функциональности смартфонов заключено в центральной SoC. А на них вендоры категорически отказываются отдавать даташиты. Дают только производителям под NDA.
Откуда тогда открытая аппаратная база?
А можно посильнее раскрыть слова «открытая аппаратная база»?
Будут доступны не бинарные драйвера. Проще говоря вы сможете сами собрать свою модификацию под телефон.
Сейчас процентов 80 функциональности смартфонов заключено в центральной SoC. А на них вендоры категорически отказываются отдавать даташиты.
Вы вообще в теме? В SoC того же TI закрыт в данный момент только OpenGL драйвер к примеру. Причем он опять же доступен после регистрации. Именно по этой причине на N900 можно запускать что-то отличное от Maemo. И многие другие производители так же дают драйвера после регистрации. То что есть например такие жлобы как Nvidia и Qualcomm, как-то не отрицает наличие железа с доступными драйверами.
«Такие жлобы как NVidia и Qualcomm» отхватили огромную долю рынка, если планируют делать платформы для этого ФФОС на железе трехлетней давности, как нокиа 900, то вряд ли они далеко уйдут.
Если про Qualcomm еще хоть как-то похоже на правду, но вот про Nvidia точно нет :) Ну и не только на чипсетах Qualcomm делают телефоны.
А как же Tegra3?
Кто ей противопоставлен, да еще и с открытыми доками?
Кто ей противопоставлен, да еще и с открытыми доками?
А как же Tegra3?
И в скольких устройствах есть Tegra2 и Tegra3?
Кто ей противопоставлен, да еще и с открытыми доками?
TI OMAP 5, TI OMAP 4, Freescale i.MX53, Freescale i.MX 6
Основная проблема сейчас это OpenGL и GPU ядра там. Потому что как правило они изготовлены не этими компаниями и закрыты патентами. Но бывает что GPU драйвер доступен и закрыта только OpenGL библиотека. При этом бинарная сборка этой OpenGL библиотеки доступна.
i.MX53 одноядерный, до Тегры не дотянет.
В скольких устройствах есть тегра? Ну это даже на вики написано:
Motorola Atrix 4G, Motorola Droid X2, Motorola Photon, Samsung Galaxy R, Samsung Captivate Glide, ZTE Mimosa X, Micromax Superfone A85, T-Mobile G2X P999, Acer Iconia Tab A100, A200 and A500, LG Optimus Pad, Motorola Xoom,[15],Sony Tablet S, Dell Streak 7, ASUS Eee Pad Transformer, Dell Streak Pro,[16], Asus Slider, Toshiba Thrive tablet, T-Mobile G-Slate
LG Optimus X2 / LG Optimus Dual P990 / Optimus 2x SU660 (?), Avionic Design Tamonten Processor Board,[17] Exper EasyPad, Notion Ink Adam tablet, Olivetti OliPad 100, Point of View Mobii 10.1, ViewSonic G Tablet,, ViewSonic ViewPad 10s, Samsung Galaxy Tab 10.1 [3],Toshiba AC100, Toshiba Folio 100, Advent Vega, Hannspree Hannspad, Aigo n700, CompuLab Trim-Slice nettop, E-Noa Interpad, Malata Tablet Zpad, MSI 10-inch (250 mm) tablet, Toradex Colibri Tegra 2, Lenovo IdeaPad Tablet K1, Lenovo ThinkPad Tablet, Velocity Micro Cruz Tablet L510, Zyrex Onepad SP1110, Zyrex Onepad SP1113G.
ASUS Transformer Pad 300, Nexus 7[23], Sony Xperia Tablet S
Asus Eee Pad Transformer Prime,[25] IdeaTab K2 / LePad K2,[26] Acer Iconia Tab A510, Acer Iconia Tab A700, LG Optimus 4X HD, HTC One X, ZTE Era, ZTE PF 100, ZTE T98, Toshiba AT270, Toshiba AT300 (Excite 10), Asus Vivo Tab RT, Fuhu Inc. nabi 2 Tablet[27], Tesla Model S, Kungfu K3[28], Goophone I5, ASUS Transformer Pad Infinity 700 (TF700T), Fujitsu Arrows X F-10D, Ouya
Достаточно?
В скольких устройствах есть тегра? Ну это даже на вики написано:
Motorola Atrix 4G, Motorola Droid X2, Motorola Photon, Samsung Galaxy R, Samsung Captivate Glide, ZTE Mimosa X, Micromax Superfone A85, T-Mobile G2X P999, Acer Iconia Tab A100, A200 and A500, LG Optimus Pad, Motorola Xoom,[15],Sony Tablet S, Dell Streak 7, ASUS Eee Pad Transformer, Dell Streak Pro,[16], Asus Slider, Toshiba Thrive tablet, T-Mobile G-Slate
LG Optimus X2 / LG Optimus Dual P990 / Optimus 2x SU660 (?), Avionic Design Tamonten Processor Board,[17] Exper EasyPad, Notion Ink Adam tablet, Olivetti OliPad 100, Point of View Mobii 10.1, ViewSonic G Tablet,, ViewSonic ViewPad 10s, Samsung Galaxy Tab 10.1 [3],Toshiba AC100, Toshiba Folio 100, Advent Vega, Hannspree Hannspad, Aigo n700, CompuLab Trim-Slice nettop, E-Noa Interpad, Malata Tablet Zpad, MSI 10-inch (250 mm) tablet, Toradex Colibri Tegra 2, Lenovo IdeaPad Tablet K1, Lenovo ThinkPad Tablet, Velocity Micro Cruz Tablet L510, Zyrex Onepad SP1110, Zyrex Onepad SP1113G.
ASUS Transformer Pad 300, Nexus 7[23], Sony Xperia Tablet S
Asus Eee Pad Transformer Prime,[25] IdeaTab K2 / LePad K2,[26] Acer Iconia Tab A510, Acer Iconia Tab A700, LG Optimus 4X HD, HTC One X, ZTE Era, ZTE PF 100, ZTE T98, Toshiba AT270, Toshiba AT300 (Excite 10), Asus Vivo Tab RT, Fuhu Inc. nabi 2 Tablet[27], Tesla Model S, Kungfu K3[28], Goophone I5, ASUS Transformer Pad Infinity 700 (TF700T), Fujitsu Arrows X F-10D, Ouya
Достаточно?
А теперь посмотрите список того что есть на чипсетах Qualcomm и сравните. Ну так для интереса.
И что? У нас давно тегра является эталоном производительности? Вообще вопрос шел доступны ли платформы с открытыми драйверами. И открывают ли вендоры даташиты. Я привел примеры кто открывает. И замечу там есть нормальные по производительности процессоры. Которых более чем достаточно для FirefoxOS.
i.MX53 одноядерный, до Тегры не дотянет.
И что? У нас давно тегра является эталоном производительности? Вообще вопрос шел доступны ли платформы с открытыми драйверами. И открывают ли вендоры даташиты. Я привел примеры кто открывает. И замечу там есть нормальные по производительности процессоры. Которых более чем достаточно для FirefoxOS.
Qualcomm тоже не открывает.
Пример вы не тот привели, под «открывает документацию» я имел в виду именно открытую документацию на SoC. Ту, где можно увидеть регистры, эррату и прочее.
Покажите мне современный SoC с таким даташитом, я бы хотел поглядеть.
Даже на всякое MIPSовое старье типа Atheros AR9330 не найти дока — хотя бы с перечислением регистров его периферии.
Пример вы не тот привели, под «открывает документацию» я имел в виду именно открытую документацию на SoC. Ту, где можно увидеть регистры, эррату и прочее.
Покажите мне современный SoC с таким даташитом, я бы хотел поглядеть.
Даже на всякое MIPSовое старье типа Atheros AR9330 не найти дока — хотя бы с перечислением регистров его периферии.
Qualcomm тоже не открывает.
А я где-то писал что открывает?
Пример вы не тот привели, под «открывает документацию» я имел в виду именно открытую документацию на SoC. Ту, где можно увидеть регистры, эррату и прочее.
www.ti.com/analog/docs/analogtechdoc_hh.tsp?viewType=mostuseful&rootFamilyId=3000&familyId=3020&docCategoryId=2
Я просто без регистрации зашел и кнопку нажал.
И что это должно символизировать?
Так можно и ссылки на AVR-даташиты покидать, говоря «вот они, открытые платформы». Это процессоры общего назначения, а не те SoC на которых делают смартфоны, в этих нету GSM модулей.
Можете привести ссылки на распространенные SoC, на которых собраны какие-нибудь более-менее известные смартфоны (не столетней давности), с подобным даташитом?
Так можно и ссылки на AVR-даташиты покидать, говоря «вот они, открытые платформы». Это процессоры общего назначения, а не те SoC на которых делают смартфоны, в этих нету GSM модулей.
Можете привести ссылки на распространенные SoC, на которых собраны какие-нибудь более-менее известные смартфоны (не столетней давности), с подобным даташитом?
Это процессоры общего назначения, а не те SoC на которых делают смартфоны, в этих нету GSM модулей.
Эээ. Товарищ вы уверены что вы в теме? GSM модуль не входит в SoC. Я сколько видел, это всегда отдельное устройство. Потому что это удобнее и проще. Вот вам внутренности iPhone 4S www.ifixit.com/Teardown/iPhone-4S-Teardown/6610/2
Обратите внимание на два чипа Qualcomm RTR860 и Qualcomm MDM6610. В данный момент проще производить процессор с пачкой выводов общего назначения куда цепляется уже все остальное. И gsm модуль чаще всего представляет из себя вообще отдельную систему, со своей ОС.
Можете привести ссылки на распространенные SoC, на которых собраны какие-нибудь более-менее известные смартфоны (не столетней давности), с подобным даташитом?
На OMAP3 были телефоны. И там есть datasheet на него. Вопросы?
О как, прямо отдельная ОС.
А вы уверены, что вы в теме?
>Snapdragon processors enable you to connect with integrated 3G/4G LTE and wi-fi
>13-stage pipeline, Embedded 600MHz DSP (GSM, GPRS, EDGE, UMTS/WCDMA, HSDPA, HSUPA, MBMS baseband), Embedded Seventh-generation gpsOne GPS module, gpsOneXTRA Assistance, Adreno 200 GPU, OpenGL ES 2.0, OpenGL ES 1.1, OpenVG 1.1, EGL 1.3, Direct3D Mobile, SVGT 1.2, DirectDraw
Вот вам Qualcomm'овский проц, причем даже не последний, на нем еще старый HTC Desire делали иже с ним. Встроенный GSM модуль. Встроенный Wi-Fi модуль.
В данный момент явно наблюдается тенденция к интеграции всего в один чип как раз, времена кучи отдельных проходят — хотя, конечно, такие решения еще остались.
Я бы не сказал что OMAP3 настолько распространен в телефонах. Ок, даташит есть — один нашли процессор.
Общая суть все равно остается той же, доки на современные SoC высокой степени интеграции — большая редкость.
А вы уверены, что вы в теме?
>Snapdragon processors enable you to connect with integrated 3G/4G LTE and wi-fi
>13-stage pipeline, Embedded 600MHz DSP (GSM, GPRS, EDGE, UMTS/WCDMA, HSDPA, HSUPA, MBMS baseband), Embedded Seventh-generation gpsOne GPS module, gpsOneXTRA Assistance, Adreno 200 GPU, OpenGL ES 2.0, OpenGL ES 1.1, OpenVG 1.1, EGL 1.3, Direct3D Mobile, SVGT 1.2, DirectDraw
Вот вам Qualcomm'овский проц, причем даже не последний, на нем еще старый HTC Desire делали иже с ним. Встроенный GSM модуль. Встроенный Wi-Fi модуль.
В данный момент явно наблюдается тенденция к интеграции всего в один чип как раз, времена кучи отдельных проходят — хотя, конечно, такие решения еще остались.
Я бы не сказал что OMAP3 настолько распространен в телефонах. Ок, даташит есть — один нашли процессор.
Общая суть все равно остается той же, доки на современные SoC высокой степени интеграции — большая редкость.
О как, прямо отдельная ОС.
А вы уверены, что вы в теме?
Отдельный процессор со своим отдельным ПО. Весьма часто бывает.
Вот вам Qualcomm'овский проц, причем даже не последний, на нем еще старый HTC Desire делали иже с ним. Встроенный GSM модуль. Встроенный Wi-Fi модуль.
Слово embedded DSP вас не смущает ну никак да? Да оно может быть внутри. Я этого не отрицаю. Но чаще бывает с наружи. В случае Tegra к примеру так. Потому что Nvidia в отличии от Qualcomm не специализируется на GSM.
В данный момент явно наблюдается тенденция к интеграции всего в один чип как раз, времена кучи отдельных проходят — хотя, конечно, такие решения еще остались.
И еще долго останутся. Не всем надо внутри DSP для работы с GSM. Часто бывает проще скомпоновать CPU с DSP.
Я бы не сказал что OMAP3 настолько распространен в телефонах. Ок, даташит есть — один нашли процессор.
Общая суть все равно остается той же, доки на современные SoC высокой степени интеграции — большая редкость.
Напомню вопрос стоял есть или нет. Так вот есть. И как раз товарищи из Mozilla хотят телефон на аппаратной базе с открытыми драйверами. Сейчас это возможно. О том что этот продукт не будет конкурентом флагманам рынка, так это и так понятно.
Хорошо, я не совсем верно изначально выразился — я не отрицаю, что на какие-то чипы найти можно.
Я имел в виду, что на специализированные SoC — те у которых внутри есть Wi-Fi, либо Bluetooth, либо GSM модули — очень трудно, иногда невозможно, найти адекватные доки.
Я с этим столкнулся, к примеру, для SoC, которые в Wi-Fi точках доступа, вроде линукс на них стартует, значит откуда-то драйверы Wi-Fi части, как минимум, нашлись, но общей документации нет. Встает вопрос — как тогда этот драйвер писали, не имея доков. Не верится как-то что реверсили исходную прошивку, хотя такое тоже возможно.
Я боюсь, если товарищи из мозиллы не станут гнаться за флагманами, они проиграют, их попросту вытеснят с рынка, подавляющему большинству людей важнее соответствие параметров продукта параметрам флагманов, чем открытость и т.п…
Кстати, был когда-то проект «опенхардварного телефона», любительский. Было бы неплохо если бы сделали что-то аналогичное, но не на дерьмовых китайских GSM модулях и т.п., а на нормальном железе. Но, я так понимаю, мозилла не ставит задачи всю хардварную составляющую открыть?
Я имел в виду, что на специализированные SoC — те у которых внутри есть Wi-Fi, либо Bluetooth, либо GSM модули — очень трудно, иногда невозможно, найти адекватные доки.
Я с этим столкнулся, к примеру, для SoC, которые в Wi-Fi точках доступа, вроде линукс на них стартует, значит откуда-то драйверы Wi-Fi части, как минимум, нашлись, но общей документации нет. Встает вопрос — как тогда этот драйвер писали, не имея доков. Не верится как-то что реверсили исходную прошивку, хотя такое тоже возможно.
Я боюсь, если товарищи из мозиллы не станут гнаться за флагманами, они проиграют, их попросту вытеснят с рынка, подавляющему большинству людей важнее соответствие параметров продукта параметрам флагманов, чем открытость и т.п…
Кстати, был когда-то проект «опенхардварного телефона», любительский. Было бы неплохо если бы сделали что-то аналогичное, но не на дерьмовых китайских GSM модулях и т.п., а на нормальном железе. Но, я так понимаю, мозилла не ставит задачи всю хардварную составляющую открыть?
Я имел в виду, что на специализированные SoC — те у которых внутри есть Wi-Fi, либо
Bluetooth, либо GSM модули — очень трудно, иногда невозможно, найти адекватные доки.
Это может быть.
Встает вопрос — как тогда этот драйвер писали, не имея доков. Не верится как-то что реверсили исходную прошивку, хотя такое тоже возможно.
Когда как. Иногда реверсили иногда драйвер банально предоставлен производителем.
Я боюсь, если товарищи из мозиллы не станут гнаться за флагманами, они проиграют, их попросту вытеснят с рынка,
В данный момент у них нет столько денег чтобы тягаться с флагманами. Вон Microsoft все пытается впрыгнуть в поезд и у нее получается это довольно плохо. А если же начать с бюджетных моделей, их могут купить на поиграться. Опять же цели захватить рынок на 90% у ниг не стоит.
Кстати, был когда-то проект «опенхардварного телефона», любительский. Было бы неплохо если бы сделали что-то аналогичное, но не на дерьмовых китайских GSM модулях и т.п., а на нормальном железе. Но, я так понимаю, мозилла не ставит задачи всю хардварную составляющую открыть?
Скорее всего используют новый MTK от MediaTek который недавно вышел.
А можно будет писатт на Cappuchino? Чтобы obj-c style?
> В Бразилии налог на импорт
> Apple строит там производственные мощности, чтобы это обойти
> Firefox OS магическим образом отменит налог на импорт
В общем, все хорошо до тех пор, пока автор не надел розовые очки и не начал описывать будущее ОСи
> Apple строит там производственные мощности, чтобы это обойти
> Firefox OS магическим образом отменит налог на импорт
В общем, все хорошо до тех пор, пока автор не надел розовые очки и не начал описывать будущее ОСи
Телефоника выпускает телефоны прямо в Бразилии. Первый выпуск телефонов будет именно там в начале 2013 для v1. Дальше возможно пойдёт и ZTE.
Ну тогда будут пошлины в другую страну, какая разница? :)
Речь идёт о захвате низкого и среднего сегмента. В первую очередь это Бразилия и прилежащие. А если вы волнуетесь о России, то кхм… Разве кого то здесь останавливает айфонушка за 35к? Ну а если серьёзно, то например телефоны от Нокиа, нижнего сегмента, всегда были по приемлемой цене, значит и эти могут быть.
Ни о ком я не волнуюсь, не беспокойтесь :)
Нижний сегмент достаточно активно захватывает Андроид, отбирая его у Симбиана, в первую очередь. Почему вдруг этот сегмент захватит FirefoxOS, непонятно
Нижний сегмент достаточно активно захватывает Андроид, отбирая его у Симбиана, в первую очередь. Почему вдруг этот сегмент захватит FirefoxOS, непонятно
Симбиан, имхо, всё же средний сегмент. Нижний — это Series 40. Почему бы не уступить более современной ОС не понятно. Главная чтобы она на подобном железе работала. Плюс Firefox узнаваемый многими бренд, даже теми, кто не знает что такое ОС (большинство владельцев Series 40 в частности об этом и не подозревают).
>Для примера, в настоящее время я тестирую JavaScript игры на телефоне за 50 фунтов. От устройства по такой цене многого ожидать не стоит, но на самом деле эти игры не только работают быстрее, чем на таком же телефоне с Android запущенные в браузере (Firefox или Chrome), но и так же быстро, если не быстрее, чем на Android устройствах цена которых в 4-5 раз больше.
Какое хитрое сравнение. С тем же жаваскриптом, но запущенным в андроидном браузере.
Разумеется после этого можно прыгать и кричать о феноменальной скорости, но почему не сравнивают эти жаваскриптовые приложения с обычными приложениями андроида? (Я уж не говорю с нативными, хотя бы с явовскими...)
Какое хитрое сравнение. С тем же жаваскриптом, но запущенным в андроидном браузере.
Разумеется после этого можно прыгать и кричать о феноменальной скорости, но почему не сравнивают эти жаваскриптовые приложения с обычными приложениями андроида? (Я уж не говорю с нативными, хотя бы с явовскими...)
Я правильно понял, что для Firefox OS предполагается что всё будет написано на HTML+JavaScript+CSS+подобным?
Вспоминая JavaScript'овую молодость, могу лишь посочувствовать тем, кто будет под Firefox OS делать более-менее большие проекты — всё-таки (ИМХО) строго типизированные языки (Java, C++) гораздо более устойчивые к глупым ошибкам в процессе развития проекта.
Вылавливание воспроизводимых только при запуске и определённой фазе луны блох из большого JS-only проекта… удачи!
Я уж молчу про то, что портирование игр на Firefox OS будет наверняка гораздо сложнее чем между Android и iOS.
Ещё — мне кажется не совсем корректным сравнением скорости «нативного» JS в Firefox OS и браузерного JS на Android.
Кстати, на Андроиде это был Chrome? Или встроенный браузер?
С точки зрения пользователя наверное более корректным было бы сравнение fps в Angry Birds на JS в F.OS и нативно на Android.
Или даже скорее не fps, а response time (например, Firefox OS может быть высокий fps, но laggy I/O)
Вспоминая JavaScript'овую молодость, могу лишь посочувствовать тем, кто будет под Firefox OS делать более-менее большие проекты — всё-таки (ИМХО) строго типизированные языки (Java, C++) гораздо более устойчивые к глупым ошибкам в процессе развития проекта.
Вылавливание воспроизводимых только при запуске и определённой фазе луны блох из большого JS-only проекта… удачи!
Я уж молчу про то, что портирование игр на Firefox OS будет наверняка гораздо сложнее чем между Android и iOS.
Ещё — мне кажется не совсем корректным сравнением скорости «нативного» JS в Firefox OS и браузерного JS на Android.
Кстати, на Андроиде это был Chrome? Или встроенный браузер?
С точки зрения пользователя наверное более корректным было бы сравнение fps в Angry Birds на JS в F.OS и нативно на Android.
Или даже скорее не fps, а response time (например, Firefox OS может быть высокий fps, но laggy I/O)
Ага, согласен со всем, включая грядущий геморрой разработчикам.
Но, я думаю, в JS будут компилить, скорее всего. Из той же явы — есть же средства, порождающие JS-код из более удобных языков.
Но, я думаю, в JS будут компилить, скорее всего. Из той же явы — есть же средства, порождающие JS-код из более удобных языков.
> Но, я думаю, в JS будут компилить, скорее всего.
Сомневаюсь что в конце концов это будет работать эффективнее чем использование более-менее платформенно-оптимизированного промежуточного представления.
Сомневаюсь что в конце концов это будет работать эффективнее чем использование более-менее платформенно-оптимизированного промежуточного представления.
Я тоже сомневаюсь, я вообще во всей этой затее с Firefox OS сомневаюсь.
Если бы они свой JS движок сделали кросс-платформенным (в аппаратном плане) и ставящимся на голое железо, тогда еще было бы что-то интересное (типа как гипервизоры, которые ставятся на железо сразу).
А тут — все тот же линух внизу, плюс еще один слой из JS-интерпретатора… Хз.
Если бы они свой JS движок сделали кросс-платформенным (в аппаратном плане) и ставящимся на голое железо, тогда еще было бы что-то интересное (типа как гипервизоры, которые ставятся на железо сразу).
А тут — все тот же линух внизу, плюс еще один слой из JS-интерпретатора… Хз.
Очень много людей стараются переместить в JS все те приемы, методы, паттерны разработок, к которым они привыкли используя другие языки программирования. Результат всегда одинаковый: «JS отстой», «Разработка на JS сопровождается только попоболью», «JS-фигня».
Опять же привожу свой опыт, в качестве примера. Мы отказались от ООП головного мозга, даже не пытаясь повторять опыт разработки системных приложений, возложив на JS работу сценариев и мелких утилит (unix-way). Блох вылавливаем очень редко.
В названии самого языка содержится слово Script, что подразумевает сценарийный подход к разработке. По крайней мере мне 15 лет так казалось…
Опять же привожу свой опыт, в качестве примера. Мы отказались от ООП головного мозга, даже не пытаясь повторять опыт разработки системных приложений, возложив на JS работу сценариев и мелких утилит (unix-way). Блох вылавливаем очень редко.
В названии самого языка содержится слово Script, что подразумевает сценарийный подход к разработке. По крайней мере мне 15 лет так казалось…
Писать на JS — это все равно, что в 21 веке писать на ассемблере.
Как-то странно сравнивать JavaScript с ассемблером
Не в первый раз уже слышу такое сравнение)
Собственно, поэтому и появились инструменты для генерации JS из Java и т.п.)
Собственно, поэтому и появились инструменты для генерации JS из Java и т.п.)
И я о том же. Есть же HaXe, к примеру, который отлично генерит JS, а язык на уровнь выше, чем AS3. Но народ упорно пишет на JS. Когда небо было голубее, то тоже было круто писать на ассемблере. Ну ничо, работа дураков любит :)
Ну вон люди и на Coffeescript пишут — только не популярно это. Яваскрипт не такой уж и сложный язык, он просто другой. А начиная писать на надстройке над языком вы можете столкнуться с проблемами, которые еще никто не решал и не факт что они будут решены.
Язык не сложный да, но посмотрите сколько к нему костылей уже прикручено, чтобы сделать из этого простого что-то удобно используемое.
На самом деле это зависит от точки зрения, я так думаю.
Каков наиболее используемый (по числу зависимостейот него) модуль для Node.js по сведениям менеджера пакетов npm?
Это Underscore.
Можно ли Underscore назвать костылём?
Underscore — это библиотека для обработки данных и функций с поддержкой цепного вызова (chaining).
Если отсутствие такой библиотеки в самом языке следует считать хромотóю — тогда да, это костыль.
Но я так не считаю, у меня другая точка зрения. Для меня Underscore — просто инструмент: он весьма удобен, но не всегда необходим мне. Мне доводилось сочинять джаваскрипты из десятков строк и ни разу не прибегнуть к Underscore.
А костыли — это такие средства, без которых программирование невозможно или хотя бы мучительно.
Тому примером jQuery: вот это и впрямь костыль. Но костыль не для языка JavaScript, а для довольно скверной системы DOM, имеющей чрезмерно длинные имена методов и свойств и притом не совершенно кросс-платформенной. Надобно быть захеристом-мазохистом, чтобы вместо$('#some') записывать document.getElementById('some') и наслаждаться.
Каков наиболее используемый (по числу зависимостей
Это Underscore.
Можно ли Underscore назвать костылём?
Underscore — это библиотека для обработки данных и функций с поддержкой цепного вызова (chaining).
Если отсутствие такой библиотеки в самом языке следует считать хромотóю — тогда да, это костыль.
Но я так не считаю, у меня другая точка зрения. Для меня Underscore — просто инструмент: он весьма удобен, но не всегда необходим мне. Мне доводилось сочинять джаваскрипты из десятков строк и ни разу не прибегнуть к Underscore.
А костыли — это такие средства, без которых программирование невозможно или хотя бы мучительно.
Тому примером jQuery: вот это и впрямь костыль. Но костыль не для языка JavaScript, а для довольно скверной системы DOM, имеющей чрезмерно длинные имена методов и свойств и притом не совершенно кросс-платформенной. Надобно быть захеристом-мазохистом, чтобы вместо
Я немножко не в теме — Coffeescript это примерно то же, что Dart?
Ну так Dart работает по тому же принципу. Ну так они не столько популярны в связи с тем, что люди привыкли к стандартной связке HTML+CSS+JS и тяжело относятся к
а) статической типизации
б) замене букв JS на что-то еще.
а) статической типизации
б) замене букв JS на что-то еще.
Я вот не поленился и скачал себе эмулятор. Впечатление хорошие, но я бы так не расхваливал FOS. Да интересно, да забавно, да я веб-разработчик и смогу ковырять свою ось и мне не надо будет учить java или obj-c. Но это не приемущества на рынке. Им важно сделать так, что бы конкурировать с андройдом, а не с IOS, потому что весовая категория разная. Что бы набрать популярность им надо что бы FOS ставили на все говнопланшеты и недосмартфоны и оно не тормозило.
Facebook: Мы окончательно решили, что делать приложения на html5 — было нашей ошибкой, поэтому мы будем делать native приложения!
— Trollzilla: Мы выпускаем OS, которая полностью будет на JavaScript
Facebook: D'oh!
— Trollzilla: Мы выпускаем OS, которая полностью будет на JavaScript
Facebook: D'oh!
Ну с другой стороны для fos у них уже почти готовое приложение) да и вообще, все компании с веб-клиентами практически имеют уже приложения для fos
Все как-то забыли, что первый айфон вышел тоже только с веб-приложениями. Через год они выкатили полноценный SDK, потому что HTML5 пока что отстой
Это стоит воспринимать как Back to the primitive? Потому что полноценный SDK до сих пор существует и развивается, а от разработки под мобилки на HTML5 хорошего пока не слышно, значит «пока что» — до сих пор актуально:)
И да простят меня адепты веба в данном топике, не холивара ради, но заметил интересную вещь:
Если к 1му ипфону флеш на мобилках был отстой, и я согласен, так и было, то сейчас — стал на порядок лучше, флеш игры попадают в топы аппстора и всё такое, а разные компании наоборот, задумываются о переходе на него в разработке простых казуалок. Успехом назвать конечно рано, но прогресс чувствуется, что радует, ведь у его собрата (хе-хе) html5 дела, походу, обстоят хуже на этом рынке)
И да простят меня адепты веба в данном топике, не холивара ради, но заметил интересную вещь:
Если к 1му ипфону флеш на мобилках был отстой, и я согласен, так и было, то сейчас — стал на порядок лучше, флеш игры попадают в топы аппстора и всё такое, а разные компании наоборот, задумываются о переходе на него в разработке простых казуалок. Успехом назвать конечно рано, но прогресс чувствуется, что радует, ведь у его собрата (хе-хе) html5 дела, походу, обстоят хуже на этом рынке)
Ну, на мобилзках Flash умер и реинкарнировался в виде нативных приложений :)
а разные компании наоборот, задумываются о переходе на него в разработке простых казуалок.
Задумываться они начали, когда услышали, что Flash for Android больше не поддерживается?
Задумываться они начали, когда услышали, что Flash for Android больше не поддерживается?
когда-нибудь люди на этой планете научатся анализировать всё то г*вно, простите, что они читают, и не вестись на желтые заголовки.
Flash player под Android — мёртворождённый, и я рад, что они приняли такое решение.
НО(!) Flash — это не только player, есть ещё AIR, и он живее всех живых;)
Flash player под Android — мёртворождённый, и я рад, что они приняли такое решение.
НО(!) Flash — это не только player, есть ещё AIR, и он живее всех живых;)
Точно не живее. Поддержка Linux свёрнута.
о да, мертвее некуда, ведь всю целевую аудиторию потеряли:) без linux флешу однозначно смерть придёт)
А вообще, имхо linux сообщество само себе яму роет в этом направлении, ну серьёзно. Если б FP не был б так гиморно разрабатывать в linux-окружении, то ничего бы не сворачивали:)
А вообще, имхо linux сообщество само себе яму роет в этом направлении, ну серьёзно. Если б FP не был б так гиморно разрабатывать в linux-окружении, то ничего бы не сворачивали:)
>> без linux флешу однозначно смерть придёт)
Вот вы говорите, а я вот жду-не дождусь возможности гонять в production видео на WebRTC, и одна из причин — отсутствие возможности нормально разрабатывать флэш-приложения под Linux. Linux — потому что сервер-сайд на человеческом Erlang(erlyvideo). И я не один такой.
JS, конечно, то еще говно, но для него хотя бы отладчики вменяемые под Linux 64bit есть.
>> Если б FP не был б так гиморно разрабатывать в linux-окружении
Когда руки из нужного места растут, под Linux разрабатывать что бы то ни было удобнее, но это холиварно, согласен.
А если строить нормальные уровни абстракции, кроссплатформенность не настолько сложна, особенно для компании с такими конскими ценами на продукты, как у Adobe.
Вот вы говорите, а я вот жду-не дождусь возможности гонять в production видео на WebRTC, и одна из причин — отсутствие возможности нормально разрабатывать флэш-приложения под Linux. Linux — потому что сервер-сайд на человеческом Erlang(erlyvideo). И я не один такой.
JS, конечно, то еще говно, но для него хотя бы отладчики вменяемые под Linux 64bit есть.
>> Если б FP не был б так гиморно разрабатывать в linux-окружении
Когда руки из нужного места растут, под Linux разрабатывать что бы то ни было удобнее, но это холиварно, согласен.
А если строить нормальные уровни абстракции, кроссплатформенность не настолько сложна, особенно для компании с такими конскими ценами на продукты, как у Adobe.
Я сейчас смотрю на Ваш комментарий из Firefox 16, занимающего 394 мегабайта по сведениям Диспетчера задач Windows.
Хотите сказать, браузер, занимающий 394 МБ оперативной памяти для мобильного устройства — это ерунда?
У меня на мобильнике HTC Desire стоит мобильная версия Файерфокса. Могу заверить, что она жрёт не сотни мегабайтов, потому что в HTC Desire всего-то 576 мегабайтов в целом, а у меня параллельно запущены Скайп и Твиттер.
Правда, мобильный Файерфокс и не хранит в памяти структуры данных, необходимые для быстрой работыкнопки «назад», для изменения интерфейса при помощи XUL, для мгновенного отображения заблаговременно декодированных иллюстраций, и так далее.
Правда, мобильный Файерфокс и не хранит в памяти структуры данных, необходимые для быстрой работы
Что скажет гугл, когда первое впечатление от оси:
«Вы дали мне Android? Это очень похоже на Android»
«Вы дали мне Android? Это очень похоже на Android»
Эх, затейка интересная, красивая, для веб-девелоперов сказка просто (я так же про webOS думал), но вот невероятно сомневаюсь я что это будет действительно шустро работать. Если только JS будет транслироваться в некий бинарный код… Или процы на уровне железа будут JS как то кушать… Или js будет оберткой для запуска каких нибудь сишных скомпиленных прог и либ… Или надо будет просто 16 ядерный смартфон с 32гб памяти, чтобы поиграть в GTA3 на JS телефоне. Ноg ока не будет реальных девайсов говорить о чем то конкретном рановато.
Поставлю себе такую на Xiaomi 2
Или не смогу?
Или не смогу?
Список поддерживаемых устройств. Но пробовать никто не запрещает, авось повезет :)
Конкуренция производителей двигает развитие технологий, но мне одному показалось что автор использует странные обороты речи похожие на НЛП?
Идея то уж не нова. Есть WebOS и Tizen (ну где то в заповедниках, куда и FirefoxOS отправится).
Chrome OS, Firefox OS. Следующая версия Windows будет называться Internet Explorer OS?
Если так хочется игр на JS лучше бы сделали игровую консоль с хорошим экраном, управлением и т.п. Слабо верится что обычные пользователи будут руками менять CSS или JS. Драйвера скорее всего так и остануться закрытыми, разве что Mozilla сама будет производить все устройства и делать их открытыми. Но т.к. платформа планируется быть открытой, то производителей возможно будет много, значить опять фрагментация и не совместимость. Так же не ясно что с безопасностью? Мне, например, безопасность моих данных важнее чем куча игр.
Идея использования виртуальной машины (движка в данном случае) в мобильной системе не лучшее решение изначально. Будет еще один андроид.
Ничего не имею против, но при наличии выбора я выберу мобильную ОС без виртуальных машин и такого BDSM.
Ничего не имею против, но при наличии выбора я выберу мобильную ОС без виртуальных машин и такого BDSM.
Хех, это только мне кажется странным, что они хотят платформу для low-end железа и при этом основывают ее на JS сравнивая результатами веб-приложений в других смартфонах? Если нужна хорошая производительность на слабом железы — зачем такие высокоуровневые инструменты и столько слоев абстракции? А если хотят удобную для разработки высокоуровневую платформу — то не стоит ожидать, что она будет летать на слабом железе. Я, например, не вижу технических причин, почему JS в Geko будет бежать быстрее, чем скажем Java в Андроидовском Дальвике или СLR-код в WP-шной .NET VM.
30 раз в тексте сочетание «Firefox OS» :)
Я не против Firefox OS, но позвольте уточнить, почему это в принципе называется операционной системой, если оно по-прежнему грузит Linux? Разве в таком случае оно не является простым Desktop Environment по типу Xfce, Gnome или KDE, пусть и написанным на XUL и javascript поверх C++-ного движка Gecko?
Выходит, что сейчас автором «инновационной операционной системы» может стать любой, кто в состоянии добавить новую строчку в inittab, а то и вовсе в .xinitrc. Чем же тогда занимаются те люди, которые пишут операционные системы, не являющиеся по факту Linux-приложениями?
Выходит, что сейчас автором «инновационной операционной системы» может стать любой, кто в состоянии добавить новую строчку в inittab, а то и вовсе в .xinitrc. Чем же тогда занимаются те люди, которые пишут операционные системы, не являющиеся по факту Linux-приложениями?
То, что обычно называют Linux является ОС GNU/Linux, также популярен Android/Linux, теперь вот FirefoxOS/Linux. А просто Linux это ядро, полноценной ОС не являющееся.
> А просто Linux это ядро, полноценной ОС не являющееся.
Тут все сложно. В спорах определение, что такое Linux является контекстно-зависимым. Это может быть Линукс, каксфероОСь (например, когда речь идет о вендекапце), а может быть как ядро. Из-за этого очень сложно вести споры с излишне преданными сторонниками Линукса.
Тут все сложно. В спорах определение, что такое Linux является контекстно-зависимым. Это может быть Линукс, как
Ну тогда MinGW, получается, тоже полноценная операционная система на базе ядра Windows, которая полноценной ОС не является?
А «Firefox OS» точно дальше смартфонов не пойдет? А то, я переживаю или радуюсь за свой холодильник,
«Остановитесь на секунду и задумайтесь — это мобильная ОС созданная на JavaScript!»
Остановился и задумался — писец! Нунах.
Остановился и задумался — писец! Нунах.
После небольшой паузы следуетчто-то вроде «Твою ж мать!»
Нет, не следует.
Я достаточно давно отношусь с разумным скепсисом к такого рода прослойкам между софтом и железом. И с интересом замечаю как воодушевлённо молодёжь встречает всякие новинки в этой области до собственно их появления на рынке и как через год-другой появляются сообщения, что в общем-то вовсе это и не панацея, напрямую работает оказывается (ага, а то мы не догадывались) лучше и т.п.
Я достаточно давно отношусь с разумным скепсисом к такого рода прослойкам между софтом и железом. И с интересом замечаю как воодушевлённо молодёжь встречает всякие новинки в этой области до собственно их появления на рынке и как через год-другой появляются сообщения, что в общем-то вовсе это и не панацея, напрямую работает оказывается (ага, а то мы не догадывались) лучше и т.п.
>> Имея базовые навыки веб-разработки, вы можете полностью изменить всю ОС. Редактирование одной строки CSS может повлиять на способ расположения иконок или их форму, или же вы можете изменить JS, который обрабатывает телефонные звонки.
И появится Bolgen Mobile OS… :D
И появится Bolgen Mobile OS… :D
Автор с радостью ответит на все вопросы о Firefox OS. Желательно писать по существу.
Насколько совместимы файлы для портирования из device// с теми, что предназначены для CyanogenMod?
А как насчёт поддержки планшетов?
Как автор видит будущее Firefox OS, если говорить о ней, как об игровой платформе?
Как насчёт расхода батареи? Понятно, что телефон тестовый и они могут быть с различной емкостью аккумов, и много чего он еще не умеет (звонить? Wi-Fi?), но тем не менее хотелось бы узнать промежуточные результаты.
Звонить и Wi-Fi умеет кстати. Как писал Крокфорд — мой первый смс спам на b2g :)
Здесь изображение наглядно показывающее все Device Access API, уже действующее и находящиеся в разработке — arewemobileyet.com
Вопрос-бесплатная-идея-фичи:
Для Дрюши есть замечательное приложение — AirDroid. Для тех кто не в курсе, приложение представляет собой небольшой web-сервер и позволяет управлять телефоном через браузер компьютера, что очень удобно. Я, к примеру, чаще всего, использую его для написания смс-ок, т.к. на большой клавиатуре это гораздо удобнее.
А тут у нас целая ОС в браузере. Возможна ли, и планируется ли подобная функциональность?
Возможно это стало бы неплохой фичей из коробки. Небольшой web-сервер для телефона + набор js «библиотек», реализующий некое подобие удаленного вызова процедур для специфичного API.
Думаю, достаточно удобно использовать для написания смс сообщений, разбора различных файлов на устройстве,
Интеграция с настольной Firefox?
Для Дрюши есть замечательное приложение — AirDroid. Для тех кто не в курсе, приложение представляет собой небольшой web-сервер и позволяет управлять телефоном через браузер компьютера, что очень удобно. Я, к примеру, чаще всего, использую его для написания смс-ок, т.к. на большой клавиатуре это гораздо удобнее.
А тут у нас целая ОС в браузере. Возможна ли, и планируется ли подобная функциональность?
Возможно это стало бы неплохой фичей из коробки. Небольшой web-сервер для телефона + набор js «библиотек», реализующий некое подобие удаленного вызова процедур для специфичного API.
Думаю, достаточно удобно использовать для написания смс сообщений, разбора различных файлов на устройстве,
Интеграция с настольной Firefox?
Как насчет работы с двумя сим-картами?
Вроде бы вопрос уже поднимался в комментариях, но чем FireFox OS будет лучше webOS? Тем более, что webOS сейчас тоже выпускают в виде продукта с открытым исходным кодом. А если точнее, то не получиться ли из FireFox OS система со всеми проблемами webOS, но только основанная на «более тяжеловесном» движке Gecko вместо WebKit?
Насколько я помню, первые версии webOS были далеко не полностью основаны на веб-технологиях — там внутри системы оставалось достаточно много частей на Java, по большей части из-за того, что проект поменял направление в процессе разработки. Когда же в следующих версиях webOS «очистили от Java» и полностью перевели на веб-технологии, то оказалось, что она стала еще более требовательной к железу, из-за чего существующие ранее устройства не могли нормально потянуть эту новую версию и, соответственно, не получили обновление до нее. Столкнувшись с этим, разработчики обратно потянули в систему не-веб-технологии.
Устройства у Palm и HP никогда не были особыми монстрами в плане железа и производительности, но и low-end девайсами их назвать было нельзя. Т.е. насколько вообще актуально пытаться сделать платформу для доступных и слабых устройств на веб-технологиях?
Насколько я помню, первые версии webOS были далеко не полностью основаны на веб-технологиях — там внутри системы оставалось достаточно много частей на Java, по большей части из-за того, что проект поменял направление в процессе разработки. Когда же в следующих версиях webOS «очистили от Java» и полностью перевели на веб-технологии, то оказалось, что она стала еще более требовательной к железу, из-за чего существующие ранее устройства не могли нормально потянуть эту новую версию и, соответственно, не получили обновление до нее. Столкнувшись с этим, разработчики обратно потянули в систему не-веб-технологии.
Устройства у Palm и HP никогда не были особыми монстрами в плане железа и производительности, но и low-end девайсами их назвать было нельзя. Т.е. насколько вообще актуально пытаться сделать платформу для доступных и слабых устройств на веб-технологиях?
Был уже и есть ChromeOS/Chromium OS.
Вроде все тоже самое, что описано возможно. Живет и здравствует.
Разве что предназначение не для смартфонов.
Иконки красивые, согласен, но дизайн опять такой же как у остальных (не Win8) мобильных платформ.
Впрочем, еще одна линуксоподобная OS для привлечения внимания к Linux, кто против?.. Я, нет.
Вроде все тоже самое, что описано возможно. Живет и здравствует.
Разве что предназначение не для смартфонов.
Иконки красивые, согласен, но дизайн опять такой же как у остальных (не Win8) мобильных платформ.
Впрочем, еще одна линуксоподобная OS для привлечения внимания к Linux, кто против?.. Я, нет.
Кто нибудь поставил?
Если дела будут поставлены так же как разработка расширений для лисы, не завидую я разработчикам под эту ось.
Глупая затея, не взлетит. Рынок смартфонов поделен в пользу андроидов и айфонов, плюс какие-то попытки мелкософта залезть. Время webOS, Chrome OS и подобных еще не пришло. Мобильные процессоры всё еще слабенькие, не тянут такой «высокий уровень». Впрочем, баксы печатают, девать же их куда-то нужно, отчего бы и не взять и не пилить какую-нибудь очередную вебось, если фантазии на большее не хватает :)
Кстати, по поводу жалоб на фпс в играх на html5 под мобилки, проблема лишь в том, что гуглу/яблоку не интересно оптимизировать данное направление, хотят видимо нативное рабство :) Впрочем, проблема решаема, люди пилят вот такое dev.appmobi.com/index.php?q=content/directcanvas-accelerates-html5-game-performance
НЯ!
Эта статья полна любви и обожания.
Возможно, стоит добавить ещё больше?
Эта статья полна любви и обожания.
Возможно, стоит добавить ещё больше?
По скринам очень похоже на Андроид. Автор сильно увлечен проектом. Посмотрим что получиться из этого.
ос для разработчиков — не для пользователей
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть что-то волшебное в Firefox OS