Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
Часть элементов явно походит на одну известную мобильную ОС.
Но круглые иконки приложений мне определенно нравятся))
Но круглые иконки приложений мне определенно нравятся))
Жду 8 ядерный смартфон!
Черт, парсер удалил тег < sarcasm
Смартфон разработанный Mozilla?
Тогда ещё минимум 4 ГБ ОЗУ :)
Тогда ещё минимум 4 ГБ ОЗУ :)
А что какой-то из продуктов Mozilla по-вашему много жрет?
у меня на компе firefox с 160+ вкладками и около 30 расширениями жрет в 2 раза меньше чем chromium с 80+ вкладками и 10 расширениями.
у меня на компе firefox с 160+ вкладками и около 30 расширениями жрет в 2 раза меньше чем chromium с 80+ вкладками и 10 расширениями.
А вот странно, кстати. У меня тоже ФФ ест меньше того же хрома, но при этом отклик интерфейса у него (открытие новой вкладки, переключение между уже существующими) происходит заметно медленней, чем у Хрома.
Может не в тему, но очень интересно. А вы реально работаете с 160 открытыми вкладками в браузере? Или специально для теста запустили?
Я реально работаю. Вот прямо сейчас 224 открытых вкладки и гигабайт занятой процессом памяти. Тормозов нет, хотя, ранее у Мозиллы с этим было не так безоблачно.
В Firefox — работаю)) а вот Chromium чуть за 100 уже всю оперативу у компа сжирает напрочь.
Просто нужно закладками пользоватся, когда-то у меня была такая проблема, открыл, а потом не хочешь закрывать, что бы потом воспользоватся информацией на той вкладке, но потом по пару месяце висит она.
Радикально… Но звучит очень перспективно.
сразу подумал о xss — страшно!
Весьма неоднозначные ощущения от концепта. Интересно посмотреть, как реализованы интерфейсы к железу и API в целом.
Да там, скорее всего, смотреть особо нечего… Вы, наверное, с Node.js не работали или для embedded на JS разрабатывали… Просто будут экспортировать специальные объекты, реализующие API. Сделал в своей программе
var device = new Device();
или
var device = require(«device»);
или типа того и все… Работай с имеющимся объектом в соответствии с документацией…
var device = new Device();
или
var device = require(«device»);
или типа того и все… Работай с имеющимся объектом в соответствии с документацией…
Вот бы ещё какая-нибудь игровая компания выпустила коммуникатор с игровой интерфейсом-платформой.
Я понимаю, что пока концепт, но когда ждать в железе?
ASP, JSP
были потуги. GWT например
C производительностью, возможно, вы правы (хотя никто не запрещает компилировать JS в бинарник) а вот с языком-то какие проблемы?
Стандартной библиотеки для делания чего? В JavaScript есть встроенные в язык массивы, словари, определены операции над ними, определены классы и объекты для работы со строками, со временем, есть математические функции.
Это то, что касается непосредственно языка. Всё остальное — варианты использования этого языка в различных средах. Классы и объекты, описывающие среду исполнения, могут различаться.
Например, в node.js может, в отличие от браузера, не быть понятия Window, зато будет HttpServer — какой смысл всё это включать в одну, «стандартную» библиотеку?
Это то, что касается непосредственно языка. Всё остальное — варианты использования этого языка в различных средах. Классы и объекты, описывающие среду исполнения, могут различаться.
Например, в node.js может, в отличие от браузера, не быть понятия Window, зато будет HttpServer — какой смысл всё это включать в одну, «стандартную» библиотеку?
Согласен, что не ограничивается. Но, стандартная библиотека, содержащая много таких специализированных структур данных, будет большой по объему и медленно прогрессирующей. Какой в этом смысл для быстро развивающихся веб-приложений? Кто эту библиотеку будет поддерживать, ведь на это необходимы немалые ресурсы?
Сейчас есть много маленьких открытых библиотек, каждая из которых предоставляет строго определенные функции и слабо зависима от других библиотек, как по коду, так и по сообществу разработчиков. За счет этого возникает конкуренция и развитие, появляются новые библиотеки, более эффективно реализующие уже известную функциональность.
Один из примеров: Crossroads.js — одна из реализаций паттерна Route/Dispatch — паттерн довольно стандартный для веб-приложений, можно было бы включить в «стандартную» библиотеку. Но, раз появляется такое большое количество альтернативных реализаций, значит, какая-то одна из них многих не устраивает. А из альтернатив обычно можно выбрать наиболее подходящую для Вашего ПО, и не быть загнанным в рамки стандартной библиотеки.
Другой пример: succint trie для эффективного хранения массивов слов вряд ли войдет в «стандартную» библиотеку — слишком специализировано (далеко не всем нужно хранить большие массивы слов). Но, тем не менее, для Вашего прикладного ПО такая функциональность может понадобиться, и вы ее подключите без проблем при необходимости.
Обычно, если Вы находите замену для функций, реализованных в рамках стандартной библиотеки, то последняя становится больше грузом, от которого невозможно избавиться, чем полезным подспорьем. И, опять же, обычно, бывает так, что заменяются не все функции, поэтому полностью избавиться от нее полностью невозможно. Да, можно организовать «стандартную» библиотеку в виде модулей — но тогда они по сути ничем не будут отличаться от уже существующих и, зачастую, признанных сообществом, открытых библиотек.
Никто не мешает крупным компаниям выпускать свои библиотеки и разрабатывать стандарты. Например, компания Zend вообще переписала движок PHP, а также разработала собственный фреймворк, который стал популярным в настоящее время, поэтому можно назвать его одним из стандартов в среде PHP. Google, в свою очередь, разработала Closure Library для JavaScript — чем не стандарт, который может принять разработчик при поиске средства реализации того или иного проекта.
Еще одно следствие наличия одной «стандартной» библиотеки — невозможность в короткие сроки предложить что-то, возможно, лучшее, взамен: огромные усилия требуются создателям Mono при повторной реализации созданной Microsoft'ом «стандартной библиотеки», чтобы обеспечить совместимость прикладных программ.
Подводя итоги: я за то, чтобы в базовой функциональности было только самое необходимое. Пусть разработчики движков хотя бы о реализации этого договорятся между собой. Остальное должно оставаться почвой для конкуренции.
Сейчас есть много маленьких открытых библиотек, каждая из которых предоставляет строго определенные функции и слабо зависима от других библиотек, как по коду, так и по сообществу разработчиков. За счет этого возникает конкуренция и развитие, появляются новые библиотеки, более эффективно реализующие уже известную функциональность.
Один из примеров: Crossroads.js — одна из реализаций паттерна Route/Dispatch — паттерн довольно стандартный для веб-приложений, можно было бы включить в «стандартную» библиотеку. Но, раз появляется такое большое количество альтернативных реализаций, значит, какая-то одна из них многих не устраивает. А из альтернатив обычно можно выбрать наиболее подходящую для Вашего ПО, и не быть загнанным в рамки стандартной библиотеки.
Другой пример: succint trie для эффективного хранения массивов слов вряд ли войдет в «стандартную» библиотеку — слишком специализировано (далеко не всем нужно хранить большие массивы слов). Но, тем не менее, для Вашего прикладного ПО такая функциональность может понадобиться, и вы ее подключите без проблем при необходимости.
Обычно, если Вы находите замену для функций, реализованных в рамках стандартной библиотеки, то последняя становится больше грузом, от которого невозможно избавиться, чем полезным подспорьем. И, опять же, обычно, бывает так, что заменяются не все функции, поэтому полностью избавиться от нее полностью невозможно. Да, можно организовать «стандартную» библиотеку в виде модулей — но тогда они по сути ничем не будут отличаться от уже существующих и, зачастую, признанных сообществом, открытых библиотек.
Никто не мешает крупным компаниям выпускать свои библиотеки и разрабатывать стандарты. Например, компания Zend вообще переписала движок PHP, а также разработала собственный фреймворк, который стал популярным в настоящее время, поэтому можно назвать его одним из стандартов в среде PHP. Google, в свою очередь, разработала Closure Library для JavaScript — чем не стандарт, который может принять разработчик при поиске средства реализации того или иного проекта.
Еще одно следствие наличия одной «стандартной» библиотеки — невозможность в короткие сроки предложить что-то, возможно, лучшее, взамен: огромные усилия требуются создателям Mono при повторной реализации созданной Microsoft'ом «стандартной библиотеки», чтобы обеспечить совместимость прикладных программ.
Подводя итоги: я за то, чтобы в базовой функциональности было только самое необходимое. Пусть разработчики движков хотя бы о реализации этого договорятся между собой. Остальное должно оставаться почвой для конкуренции.
P.S. Насколько я знаю, CIL — это объектно-ориентированный ассемблер, то есть для него определена только архитектура виртуальной машины и система команд. Классы и объекты, входящие в «стандартную библиотеку» (например, Microsoft .NET) — это уже более высокий уровень. Они предназначены для исполнения на этой виртуальной машине и будут предоставлять некий программный интерфейс в её терминах, а реализованы будут либо на CIL, либо, в угоду оптимизации, написаны или скомпилированы из CIL в процессоро-зависимые инструкции.
Ой ли? Недайбог всё производители так сделают — и будет ситуация аналогичная различным браузерам и их версиям.
Вроде такого:
Ой, я у меня кнопка уползла. Наверное не прописали хак для $BROWSER_NAME.
Вроде такого:
Ой, я у меня кнопка уползла. Наверное не прописали хак для $BROWSER_NAME.
$BROWSER_NAME у всех будет один — Mozilla же разрабатывает. Зато раз в полтора месяца будет выходить новая версия ОС, правда половина приложений будет переставать работать в новой версии, но это можно будет пофиксить специальным хаком реестра :)
Интересно, когда Opera сделает себе мобильную ОС…
Интересно, когда Opera сделает себе мобильную ОС…
Так у Оперы оно уже давно… Вот, например: www.opera.com/business/sdk/
На практике выглядит как ядро Линукса (по сути ванильное + пропиетарный референсный модуль от производителя оборудования) у которого сразу после загрузки запускается Опера (или WebKit, или какой-нибудь ANT Galio на базе все того же FF) с дополнительными библиотеками поддержки оборудования, которые экспортируют для JS-приложений специальные объекты, реализующие API. Ну и все. :-)
ps: Производители, кстати, довольны как слоны: им по GPL достаточно выложить тупо ядро Линукса, а все самое интересное, где «мякотка» — пропиетарное и раскрытию не подлежит. :-) Я после того, как всего этого насмотрелся — в GPL перестал верить…
На практике выглядит как ядро Линукса (по сути ванильное + пропиетарный референсный модуль от производителя оборудования) у которого сразу после загрузки запускается Опера (или WebKit, или какой-нибудь ANT Galio на базе все того же FF) с дополнительными библиотеками поддержки оборудования, которые экспортируют для JS-приложений специальные объекты, реализующие API. Ну и все. :-)
ps: Производители, кстати, довольны как слоны: им по GPL достаточно выложить тупо ядро Линукса, а все самое интересное, где «мякотка» — пропиетарное и раскрытию не подлежит. :-) Я после того, как всего этого насмотрелся — в GPL перестал верить…
Разъясните пожалуйста по поводу GPL. Как я понимаю, если исходный продукт выпущен под GPL, то и производный от него также должен релизиться под GPL с сорцами. Если в данном случае исходный продукт выпущен под другой лицензией — не обязывающей раскрывать свои исходники, то зачем тогда вообще что-то под GPL релизить?
Извините, если нубство…
Извините, если нубство…
О каком конкретно продукте идет речь? Я же не о программе какой-то, а в целом о прошивках embedded-девайсов. Достаточно долгое с ними взаимодействие показывает полный fail GPL'а, т.к. производители выкладывают только то, что обязаны (обычно — ядро линкса и busybox), но сообществу от этого — толку никакого… А кто хочет — тот и вообще ничего не выкладывает, а потом начинаются эпические судебные процессы из-за все того же busybox'а… Собственно, я сам поэтому и против GPL (в пользу BSD), т.к. не вижу в ней на практике реального смысла. :-)
вы не правы. GPL тут не при чём. GPL — это не LGPL. разрабы обязаны выкладывать заодно и все исходники к дровам и т.п., что в конце концов приводит к обязанности выложить весть vendor-specific, кроме кастомных лоунчеров и прочего UI-треша. другое дело, что по ясным причинам, этого никто не делает. да, нарушение лицензии. а разруливанием ситуации заниматься некому. не Торвальдсу же по судам бегать.
Вы не правы. Самописные модули ядра не являются «derived work» в терминал GPL, поэтому, разумеется, не обязаны быть под ней. А в случае embedded именно в вендорских модулях вся радость-то и сокрыта… :-)
зависит от типа линковки с ядром. я в прошивках телефонов не разбираюсь, но раньше был уверен, что они компилят одно цельное ядро.
Вот у меня сейчас на столе девайс (правда тоже не телефон ;-) ) — на флеше блоки ядра и корневой записаны. Ядро — почти ванильное MIPS'овское — там ничего интересного нет. Весь функционал работы с оборудованием лежит в пропиетарном модуле на ФС, который ядро подгружает при загрузке. И все, кто не хочет/может идти на контакт — делают также и ничего тем самым не нарушают…
> Самописные модули ядра не являются «derived work» в терминал GPL
Вот про это я и спрашивал. Можете разжевать?
Для меня embedded device представляет программно-аппаратный комплекс (если хотите в «советской терминологии») и, опять же, мне кажется, что мой продукт, работающий на базе (из под) программной среды с GPL лицензией, можно назвать производным. Я наверняка неправильно трактую. Поэтому и спрашиваю.
Вот про это я и спрашивал. Можете разжевать?
Для меня embedded device представляет программно-аппаратный комплекс (если хотите в «советской терминологии») и, опять же, мне кажется, что мой продукт, работающий на базе (из под) программной среды с GPL лицензией, можно назвать производным. Я наверняка неправильно трактую. Поэтому и спрашиваю.
Ой, ну я на самом деле не настолько большой спец в GPL, чтобы мог в деталях разжевывать. :-) Чтобы работа не была признана производной — она должна быть независима от работы, лицензированной по GPL. Если программа просто реализует некоторый интерфейс (например — является модулем ядра, который ядро само подгружает и использует, а не наоборот), то производной от тех, с которыми она по этому интерфейсу общается, — не является.
На самом деле, тут действительно достаточно тонкая граница: если мы пишем программу и не линкуем ее статически с какой-то библиотекой, то по сути тоже можно говорить о реализации некоего интерфейса-API, однако же линковка производный продукт создает…
Насчет «программно-аппаратных комплексов» — это надо уже GPLv3 смотреть, но т.к. Линукс использует вторую версию — все вендоры довольны. :-)
На самом деле, тут действительно достаточно тонкая граница: если мы пишем программу и не линкуем ее статически с какой-то библиотекой, то по сути тоже можно говорить о реализации некоего интерфейса-API, однако же линковка производный продукт создает…
Насчет «программно-аппаратных комплексов» — это надо уже GPLv3 смотреть, но т.к. Линукс использует вторую версию — все вендоры довольны. :-)
Спасибо.
Наткнулся на курсы от free-electrons. На пятом слайде:
Опять ничего не говорится как должны релизиться модули которые входят в ваш продукт, который как раз «Linux based» будет. Или тогда две отдельных фирмы должны работать совместно — одна релизит устройство с сорцам линукса, а другая софтовую проприетарщину. Так?
The whole Linux sources are Free Software released
under the GNU General Public License version 2 (GPL v2).
For the Linux kernel, this basically implies that:
When you receive or buy a device with Linux on it,
you should receive the Linux sources, with the right to
study, modify and redistribute them.
When you produce Linux based devices, you must
release the sources to the recipient, with the same rights,
with no restriction
Опять ничего не говорится как должны релизиться модули которые входят в ваш продукт, который как раз «Linux based» будет. Или тогда две отдельных фирмы должны работать совместно — одна релизит устройство с сорцам линукса, а другая софтовую проприетарщину. Так?
Нашел в тех же слайдах разъяснения по вопросу лицензирования. Модификации кода ядра линукс и модули, которые компилируются вместе с ядром должны релизиться под GPL. Драйвера к железу, такие как, например, драйвера для видеокарт от NVidia/ATI расположились в «серой зоне», т.е. формально могут быть проприетарными, хоть это и не одобряется каммьюнити. А вот драйвера и другой софт в «User Space» уже свободны.
последние 4 версии FF количество репортов о несовместимости дополнений можно сосчитать на пальцах.
Может, не совсем по существу, но все же не стоит вводить читателей в заблуждение такими фразами:
и, в то же время,
Операционная система, в традиционном понимании этого слова, — это прослойка между аппаратурой и прикладными программами. Её не может не быть на устройстве.
не имеет операционной системы в традиционном понимании этого слова
и, в то же время,
Boot2Gecko — полностью открытая платформа на базе ядра Linux.
Операционная система, в традиционном понимании этого слова, — это прослойка между аппаратурой и прикладными программами. Её не может не быть на устройстве.
Браузер будет прослойкой между прикладными программами и аппаратурой.
Сейчас: ядро (драйвера) — операционная система умеющая запускать разные программы и имеющая доступ к железу — браузер — вебприложения.
Будет: ядро (драйвера) — браузер с доступом к железу — вебприложения.
Сейчас: ядро (драйвера) — операционная система умеющая запускать разные программы и имеющая доступ к железу — браузер — вебприложения.
Будет: ядро (драйвера) — браузер с доступом к железу — вебприложения.
Все-таки, доступ к железу будет обеспечивать ядро Linux. А браузер будет обращаться к драйверам, к файловой системе (это уже далеко не железо) — точно так же происходит и в нынешних ОС.
Единственное отличие — графический интерфейс реализован с помощью веб-движка. Все равно существует прикладная программа «Браузер» (пусть, написанная с использованием веб-технологий), которая использует графический интерфейс (читайте, встроенный веб-движок + фреймворк Gaia) для отображения элементов управления и веб-страниц.
Единственное отличие — графический интерфейс реализован с помощью веб-движка. Все равно существует прикладная программа «Браузер» (пусть, написанная с использованием веб-технологий), которая использует графический интерфейс (читайте, встроенный веб-движок + фреймворк Gaia) для отображения элементов управления и веб-страниц.
Сейчас: ядро (драйвера, фс, сеть) — шелл (включая иксы и DE) — браузер — вебприложения. Браузер обращается как к API ядра (драйвера, фс, сеть), так и к API шелла (графика, UI).
Будет (если я правильно понял): ядро (драйвера, фс, сеть) — браузер — вебприложения. Браузер будет обращаться к ядру как сейчас (драйвера, фс, сеть), так и рисовать сам (графика, UI). А может иксы или что-то вроде этого оставят (было бы разумно, если от парадигмы окон и т. п. не уходят) и браузер заменит собой только DE. Грубо говоря вместо гнома, в котором запускается файерфокс, будет сразу грузиться файрфокс, с расширенным апи, предоставляющий страницам доступ к драйверам, фс, сети.
Будет (если я правильно понял): ядро (драйвера, фс, сеть) — браузер — вебприложения. Браузер будет обращаться к ядру как сейчас (драйвера, фс, сеть), так и рисовать сам (графика, UI). А может иксы или что-то вроде этого оставят (было бы разумно, если от парадигмы окон и т. п. не уходят) и браузер заменит собой только DE. Грубо говоря вместо гнома, в котором запускается файерфокс, будет сразу грузиться файрфокс, с расширенным апи, предоставляющий страницам доступ к драйверам, фс, сети.
А как же Open WebOS и Envy? :-(
С поддержкой Телефоники у него есть все шансы стать реальным
Mer, не, не слышали?
Ух! Скорей бы!
Идея интересная. Концептуально это что-то вроде Google Chrome OS для смартфонов, только интеграция веб-приложений и железа происходит на более глубоком уровне. На лэптопах такая схема, вроде как, пошла не очень, посмотрим как это пойдет.
<вопль> Уберите, уберите пожалуйста 'плавные' выезжания и слайдирования. </вопль>
Вы заметили, с какой скоростью работает сей девайс? Даже панелька с набором номера выезжает с заметным лагом.
Где же развитие той самой части, что является телефоном — звонилка, адресная книга. В android например до сих пор не ввели качественного поиска контактов при использовании клавиатуры набора номера (имею в виду учет t9 в процессе набора для поиску одновременно по имени, телефону, и вообще всем полям контакта), да вендоры сами что пилят (к примеру у HTC есть своя).
Интересно, доступ к радиомодулю сделан достаточно абстрагировано? А интерфейс звонилки? А настройка прав доступа? Можно ли будет дать доступ к адресной книге вебсайту или 'приложение необходимо установить'?
Вы заметили, с какой скоростью работает сей девайс? Даже панелька с набором номера выезжает с заметным лагом.
Где же развитие той самой части, что является телефоном — звонилка, адресная книга. В android например до сих пор не ввели качественного поиска контактов при использовании клавиатуры набора номера (имею в виду учет t9 в процессе набора для поиску одновременно по имени, телефону, и вообще всем полям контакта), да вендоры сами что пилят (к примеру у HTC есть своя).
Интересно, доступ к радиомодулю сделан достаточно абстрагировано? А интерфейс звонилки? А настройка прав доступа? Можно ли будет дать доступ к адресной книге вебсайту или 'приложение необходимо установить'?
когда появлялись утечки q3 (не говоря уже о doom3 ) все тоже писали вполь — на каком железе это будет работать.
Сейчас q3 можно пускать на мобильных платформах.
Сейчас q3 можно пускать на мобильных платформах.
до сих пор не ввели качественного поиска контактовТак ведь код будет
Поэтому, кто захочет заапгрейдить поиск контактов и сделать его существенно более качественным, тот просто возьмёт в руки клавиатуру да JavaScript, сочинит крутонавороченный поиск и выложит на GitHub — забирáйте, люди дóбрые, пóльзуйтеся, фóркайте, жду ваших пулреквéстов!
Я не помню когда последний раз пользовался таким архаизмом как поиск в контактах по T9(кстати у меня на моторола дефай он работает).
Гораздо ведь удобнее поиск c qwerty клавиатуры. или если база контактов небольшая — выбрать напрямую.
Да и вообще избранные контакты рулят. А у Моторолы еще и сами создаются временные ярлыки в избранном на те контакты с которыми ты более менее часто говорил за последний день.
Гораздо ведь удобнее поиск c qwerty клавиатуры. или если база контактов небольшая — выбрать напрямую.
Да и вообще избранные контакты рулят. А у Моторолы еще и сами создаются временные ярлыки в избранном на те контакты с которыми ты более менее часто говорил за последний день.
А на видео видно то как тормозит)
Слабо верится в будущее такого девайса не текущем этапе развития техники. Обработка HTML и яваскрипта очень сложна с точки зрения нагрузки на процессор. Нативные приложения как раз для того и создаются, чтобы упростить задачу процессору. HTML имеет слишком давнюю историю и был предназначен не для этих целей. Думаю, что это не тот путь, по которому стоит идти.
Хочу
Ёлы палы, дак это же WebOS от HP :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Open Web Device — смартфон на платформе HTML5