JavaScript веб-разработчик
0,0
рейтинг
16 сентября 2012 в 08:21

Разработка → Есть что-то волшебное в Firefox OS перевод

Последние полтора года я уделял все больше времени работе над новым проектом Mozilla — Firefox OS. За это время я буквально влюбился в него и в его идею, испытав то, чего не испытывал прежде.


Скриншот Firefox OS



Буду откровенен, Firefox OS является началом чего-то невероятного. Это ожидающая своего пробуждения революция. Глоток свежего воздуха. Кульминация новейших технологий. Оно волшебно и оно изменит все.

Что такое Firefox OS?


Для тех, кто не знает о чем я говорю, вот короткое описание.

Firefox OS — это новая мобильная операционная система разработанная Mozilla в рамках проекта Boot to Gecko (B2G). ОС использует ядро Linux и загружается в Gecko — веб-движок, который позволяет пользователям запускать приложения созданные на HTML, JS и любых других Open Web API приложений.
Mozilla Developer Network


Короче говоря, проект Firefox OS собрал в себе все веб-технологии для создания полноценной мобильной операционной системы. Остановитесь на секунду и задумайтесь — это мобильная ОС, созданная на JavaScript!

Для этого был модифицирован Gecko (движок Firefox), который предоставляет набор новых JavaScript APIs, необходимых для создания функционала подобного существующему в современных мобильных ОС. WebTelephony для телефонных звонков, WebSMS для отправки текстовых сообщений и Vibration API для, хм… для того чтобы вибрировать.



Firefox OS — это гораздо больше, чем затея использовать последние веб-технологии так, как этого никто не делал прежде. Это также и сочетание многих других проектов Mozilla как единственное виденье — Web как платформа. Open Web Apps initiative и Persona являются одними из таких проектов, нашим решением в области идентификации и авторизации в интернете (известным под официальным именем «BrowserID»). Удивительно наблюдать, как большое количество проектов от Mozilla сливаются в одно целое.

Я больше не буду вдаваться в мелкие подробности, больше информации вы можете найти на страницах MDN о Firefox OS. Очень рекомендую почитать.

Почему Firefox OS?


Вы наверняка думаете: «Звучит отлично, но почему именно JavaScript?» Это действительно хороший вопрос. Существует множество причин, по которым лучшим решением стала разработка мобильной ОС на JavaScript.

Две основных причины заключаются в том, что Firefox OS заполняет пробел и создает альтернативу текущей проприетарности и ограничениям на рынке мобильных платформ.

Заполнение пробела на рынке мобильных платформ

Ни для кого не секрет, что смартфоны часто просто до смешного дорогие, даже в тех странах, где уровень дохода достаточно высок. Но если вы думаете, что такие цены существуют только в богатых странах, то вы глубоко ошибаетесь. 16GB iPhone 4S в Бразилии стоит около 615 фунтов стерлингов, что на 100 фунтов дороже чем такой же телефон в Англии!

Такие цены в Бразилии обусловлены высоким налогом на импорт. Судя по всему, Apple уже работает над устранением этой проблемы, планируя построить местные производственные линии в стране. Несмотря на это, данный случай прекрасно дает понять, что хороший смартфон многим не по карману. Не говоря уже о том, что в некоторых странах вам лучше не размахивать смартфоном, стоимость которого равна стоимости небольшого автомобиля.

Так что же делать, если вы хотите получить хороший смартфон и при этом не тратить на него огромную сумму? Можете купить дешевый смартфон на Android, но такие, как правило, работают плохо и постоянно тормозят.

К счастью, теперь у нас есть Firefox OS…

Цель Firefox OS заключается не в создании конкуренции high-end устройствам, а в том, чтобы предложить смартфоны начального и среднего уровня по цене обычного мобильного телефона.
Bonnie Cha


Firefox OS прекрасно подходит для этого. Эта ОС может предложить вам полноценный смартфон на основе устройства с низкой производительностью, что сравнимо с Android на устройстве среднего класса. И это не шутка.

Для примера, в настоящее время я тестирую JavaScript игры на телефоне за 50 фунтов. От устройства по такой цене многого ожидать не стоит, но на самом деле эти игры не только работают быстрее, чем на таком же телефоне с Android запущенные в браузере (Firefox или Chrome), но и так же быстро, если не быстрее, чем на Android устройствах цена которых в 4-5 раз больше.

Почему же происходит такой прирост производительности в сравнении с результатами работы в браузере Android на одинаковых устройствах? Секрет в быстром обмене данными между Gecko и железом, что дает возможность JavaScript работать очень быстро.

Высокая производительность JavaScript на дешевых устройствах стала для меня одной из причин, по которой я уверен, что Firefox OS — это начало чего-то огромного.

Должен отметить, что Mozilla не обязательно будет запускать ОС с телефонами стоимостью в 50 фунтов, это устройство мы используем для разработки и тестирования.

Альтернатива и открытая платформа

Вторая причина «Почему Firefox OS?» — это попытка не только создать альтернативную и открытую мобильную платформу, но и противостоять и попытаться повлиять на крупных игроков рынка.

С момента основания Mozilla в 1998 как разработчика ПО и позже как компании и организации, нашей миссией было создание открытых технологий, которые могут соревноваться с доминирующими корпоративными продуктами.
Steve Lohr


Mozilla пытается повторить свой успех с Firefox, который буквально ворвался на рынок браузеров и показал пользователям, что существует альтернатива, что они могут контролировать то, как они используют веб.

Теперь это мобильный веб, который находится под угрозой. И угроза исходит не от Microsoft, но от Apple и Google, производителей ведущих мобильных платформ. Их приложения, закрытые платформы, проприетарные магазины приложений и весьма капризные правила для разработчиков. Apple и Google только усугубляют положение веб-технологии.
Thomas Claburn


Одна из главных областей, которая нуждается в развитии — портативность приложений…

Весь ажиотаж вокруг мобильных приложений, в некотором смысле, есть шаг назад: они приковывают пользователей к определенной ОС и устройствам, что ее поддерживают. Веб эволюционировал и пришел к тому, что на любом железе он может восприниматься одинаково.
Mozilla, создатель веб-браузера Firefox, полна решимости сделать то же самое и для мобильных устройств.
Don Clark


Firefox OS стремится использовать вездесущность веб-технологий, чтобы дать вам возможность пользоваться одними и теми же приложениями на вашем смартфоне, ПК, планшете и любом другом устройстве, имеющем браузер. Разве не хотели бы вы иметь возможность продолжить игру в Angry Birds на десктопе с того места, где закончили ее на своем смартфоне? Я бы очень этого хотел!

Мечта разработчика

Еще одна причина, почему нам нужна Firefox OS — в данный момент не существует ОС, которую можно было бы легко редактировать (можно немного изменить Android, но это сделать не так просто).

Firefox OS построена целиком и полностью на HTML, JavaScript и CSS. Имея базовые навыки веб-разработки, вы можете полностью изменить всю ОС. Редактирование одной строки CSS может повлиять на способ расположения иконок или их форму, или же вы можете изменить JS, который обрабатывает телефонные звонки.

Эта платформа уникальна для разработчиков, и мне очень интересно знать, что они сделают с ней и к чему это приведет.

Удачный момент


Работая вот уже полтора года в Mozilla, я осознал, как мне повезло оказаться здесь именно в момент рождения Firefox OS. Если я все правильно помню, то проект был анонсирован (как Boot to Gecko) в первые несколько недель моей работы в компании.

Все было восхитительно, но со временем стало еще более восхитительно. Firefox OS — приоритет номер один в моей работе на данный момент, и честно говоря, мне это нравится. Это большая честь быть частью такого проекта.

Я много раз задавался вопросом: это восхитительное чувство — похоже ли оно на то, что испытываешь работая в Mozilla во время запуска Firefox? Волнение, страсть, нервозность и неспособность объяснить, насколько все это удивительно, и почему кого-то это должно волновать.

Честно говоря, я не думаю, что многие до конца понимают, что на самом деле значит для всех запуск Firefox OS. Так же, как и Firefox, я полагаю.

В данный момент я счастлив работать в Mozilla, в столь интересный период в жизни компании.

Восхищенные


Люди, которые осознали всю важность этого проекта — разработчики. Они держали в руках демо-устройства сотрудников Mozilla на наших ивентах. И мало что может быть так захватывающе, как возможность наблюдать за этими людьми пока они исследуют устройство и переживают различные эмоции…

  1. Все начинается с легкой растерянности — «Вы дали мне Android? Это очень похоже на Android.»
  2. Далее приходит внезапное осознание того, что это не Android и что система построена на JS.
  3. После небольшой паузы следует что-то вроде «Твою ж мать!»
  4. Еще немного и человек полностью погружается в систему, изучая все ее углы.
  5. Последняя стадия — нежелание расставаться с устройством, когда я прошу его обратно и финальное «Это очень неплохо, я удивлен!»


Вы можете подумать, что я лишь расхваливаю проект, чтобы всем казалось, будто это очень захватывающе. Но на самом деле так реагировали многие. Забавно было за этим наблюдать.

Из того, что я видел, как люди реагировали на Firefox OS, я понял, что она изменит многое. Все настолько восхищены, что, мне кажется, никому ничего и не нужно объяснять.

Проблемы


Было бы несправедливо все время хвалить Firefox OS, не упомянув о некоторых проблемах, которые нам нужно решить.

Существуют общие вопросы, такие как создание открытой экосистемы приложений или фрагментация устройств, что происходит с Android. Это важно, но в конечном итоге совершенно мне неинтересно.

Больше всего меня интересует проблема HTML5 игр на мобильных устройствах — восприятие и производительность, на что разработчики часто жалуются. Эта проблема не принадлежит сугубо Firefox OS (Android и iOS так же плохи в этом), но сейчас я целиком сосредоточен на ней и на проблеме производительности.

Большинство ранее созданных мобильных HTML5 игр работают очень медленно (0—20FPS), или чуть быстрее (20—30FPS). Часто эти игры имеют нестабильный FPS, что заметно ухудшает игровой процесс.

Интересно, что многие проблемы не обязательно связаны с устройством или JavaScript. Есть несколько тяжелых игр, таких как Biolab Disaster. Эта игра идет отлично даже на том же телефоне за 50 фунтов (40—60FPS).

Для меня совершенно ясно, что иногда устройство и платформа могут быть причиной низкой производительности в играх (не так часто, как некоторые думают). Мы можем почерпнуть многое из игр, которые отлично работают на слабых устройствах. Изучить техники и приемы, которые использовали разработчики, и рассказать о них тем, кто собирается работать с HTML5 играми для мобильной платформы.

Я искренне верю, что тяжелые HTML5 игры могут отлично работать на любых устройствах, даже на самых слабых. Почему я так уверен? Потому что люди уже сегодня делают такие игры. Есть две вещи, которым я доверяю больше всего в своей жизни… мои глаза.

Не только мобильные телефоны


Больше всего я взволнован не тем фактом, что Firefox OS будет установлена на мобильном устройстве, которое мы выпустим в следующем году, а тем, что будет в будущем. Я затронул эту тему ранее, когда говорил о «мечте разработчика», как другие могут расширить границы использования ОС.



И это происходит уже сегодня. У нас уже есть Firefox OS портированная на Raspberry Pi и Pandaboard. Они не идеальны, но что круто (я очень старался избежать этого слова), так это то, что все это происходит задолго до первого релиза.

Уже есть возможность опробовать Firefox OS на Mac, Windows и Linux. Конечно же, у вас не будет доступа ко всем функциям, которые есть в смартфоне, но все же вы сможете кое-что попробовать (например, приложения, работающие параллельно). Установка системы довольно проста.

Я могу только представить тот недалекий день, когда Gamepad API появится в Gecko и будет доступен на десктопном клиенте Firefox OS. Что в этом такого? Ну, не так уж сложно представить себе устройство, подключенное к телевизору, с ОС настроенной для работы с геймпадом вместо мыши или сенсора (и это все JavaScript, помните).

Это послужит началом эры консолей для HTML5 игр, и это то, над чем я работаю в свое «свободное» время за пределами Mozilla.

Я хочу сказать, что мы подходим к тому моменту, когда многие устройства смогут работать на тех же технологиях, что мы обычно используем для создания веб-сайтов. Так что же мы можем сделать с миром, полным устройств, работающих на базе технологий, которые везде могут получить доступ и обмениваться данными, используя одни и те же API?

Я отчаянно хочу увидеть этот мир!

Переведено и опубликовано с разрешения автора.

Автор с радостью ответит на все вопросы о Firefox OS. Писать в эту ветку.

Полезные ссылки:
Перевод: Rob Hawkes
Роман Лютиков @roman01la
карма
36,2
рейтинг 0,0
JavaScript веб-разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (297)

  • +102
    Такой оптимист этот автор.
    • +36
      Положительно заряженный автор!
    • +26
      Не оптимист, а евангелист.
      • –15
        i.e. врун
        • 0
          Я этого не говорил.
          В данном случае, возможно, скорее зеалот.
          • +6
            По-русски пишется «зелот» от древнегреческого «ζηλωτής».
            • –1
              Zealot?
              • +13
                Да, есть такое английское слово. Но (я надеюсь) Вы же не пишете «ивэнджелист» вместо «евангелист»? А почему? Да потому, что все вероисповедные термины были заимствованы из греческой речи вот ужé тысячу с лишним лет назад. Так и с зелотами.
            • +6
              А почему не «зилот»?
              • +1
                О да, спасибо, «зилот» даже вероятнее.

                Но, во всяком случае, не «зеалот».
                • 0
                  • +1
                    Не путайте Гоголя с Гегелем, Гегеля с Бебелем, Бебеля с Бабелем. :)

                    Обе страницы — и «зелоты», и «зилоты» — объединены перекрёстными ссылками с призывами не путать эти термины. Слово же, лежащее в основе их обоих, одно и то же. Вся тонкость заключена в произношении буквы «η», различающимся для древнегреческого и новогреческого языков.
                    • +1
                      … а кобеля от суки. Сорри, не удержался, анекдот хороший :-)
                      • +1
                        Спасибо! Я догадывался, что кто-нибудь не удержится.
                • 0
                  Вообще в английской транскрипции "zealot" читается как «зелот», но никак не «зеалот».
  • +13
    Очень интересно, однако все еще осталось недопонимание. Кто будет делать смартфоны под эту ОС? Кто будет делать приложения под эту ОС? Как с портированием на другие платформы, на других осях для доступа к системе чаще всего нужен PhoneGap. Огромный вопрос про гайдлайны, они есть? Все таки, когда каждое приложение выглядит по своему, это печально. И возможно мне показалось, но отзывчивость интерфейса желает желать лучшего.
    • +2
      Пока только TCL Communication Technology (Alcatel) и ZTE. Первый такой телефон будет выпущен в Бразили, в начале следующего года. Приложения можем делать и мы с вами. Здесь список всех устройств, на которых уже сейчас можно запустить Firefox OS. Гайд по портированию. Немного информации о разработке приложений. Гайдов по UI судя по всему пока нету, но думаю, что скоро будут, если уже в следующем году первые устройства будут в продаже.
      • +4
        Вот гайд по UI если что — wiki.mozilla.org/Gaia/Design/BuildingBlocks

        Вообще, большая часть информации о Firefox OS находится в wiki, а не в mdn.
        • 0
          Отлично, спасибо!
          • +1
            Добавьте ссылки в футер статьи, если не сложно.
            И апдейт про автор ответит на вопросы тоже (можно даже указать начало ветки, чтобы вопросы были сразу видны).
            • +1
              Сделано. Спасибо за совет!
    • 0
      А зачем выпускать специальные нелефоны для открытой платформы? Чем вам не хватает продающихся дешевых android смартфонов по 100-300 баксов, родная ось на которых тормозит?
      • +4
        Обыкновенный пользователь дешевых тормозящих Андроидов никогда не займется самостоятельной переустановкой Адроида на xxxOS, чем бы xxx не был.
        • +2
          О, вы, видимо, не слыхали пословицу «все юзеры делятся на яблокофилов, виндофономанов, андроидолюбов и спиководов» (не точно).
          Соль в том, что Samsung выпустила телефон i5700 Galaxy Spica, 3.5 дюйма экран, туча аппаратных кнопок, andriod 1.4.
          В телефоне был 800 МГц samsung процессор и даже видеочип, под который, кстати, так дровы и не написал никто, даже производитель.
          Андроиды развивались, а «спику» продавать было жалко в силу ее удобства и адекватности цены.
          Тогда начались кастомы. ЧТо народ только ни придумывал, чтобы сделать из спики полноценный девайс на 2.х андроиде. И успехов было много. Но везде были глючки, подвисоны, перезагрузки.
          Вплоть до того, что одна и та же прошивка на 10 устройствах вела себя по-разному.
          Это провоцировало пользователей на постоянные перепрошивки всеми известными способами.
          Сам пол года владел чудо-девайсом, лиш примерно раз в месяц, иногда чаще. В итоге так и не нашел компромисса и продал другу, который шил спику еще чаще, но компромисс таки нашел.

          Еще хороший пример — HTC HD2, который изначально оснащен WM6.5, но работает как на Andriod, так и на WP7. И некоторые товарищи даже держат по две прошивки одновременно и по настроению пользуются попеременно.
          • +8
            Про что вы только что написали этот пост? Если про обычных пользователей, то вы точно ошиблись.
            • +4
              Да, как недавно я для себя выяснил, обычные пользователи ходят в салон сотовой связи что бы установить на айфон игрушку, три кнопки на экране им не нажать.
              • 0
                Устроились на работу в салон сотовой связи? (:
          • +2
            Я купил в свое время Спику, один раз прошил официальной прошивкой от Самсунга на 2.1 и вот уже третий год пользуюсь без нареканий. Я — обычный пользователь или нет?
        • 0
          А что до «обычный пользователь», то открытые платформы и обычный пользователь — не слишком рядом.
          • 0
            Андроид тоже открытая платформа. И? Вы считаете, что телефоны на Андроиде покупают только и исключительно гики?
            • +2
              Андроид я бы назвал максимум условно-открытой.
            • +1
              Я к тому что обычному пользователю побарабану. А если вы не обычный пользователь и хотите допиливать — вас не смутит дешевый девайс. Скорее наоборот.
    • 0
      С портированием, кстати, всё очень просто. Например, с помощью Appcelerator.
  • +53
    В общем стоит с высокой вероятностью ожидать, что они достойно реализуют запатентованную в андроиде технологию динамичного подтормаживания интерфейса.
    • +10
      Думаете, Гугл их засудит?
      • +1
        Все необходимые патенты уже закуплены :)
        • +19
          Как владелец Nexus, могу с уверенностью сказать в 4.1 Google отказался от патента «динамичного подтормаживания интерфейса.». Mozilla может его бесплатно использовать
          • 0
            Любопытно, что сторонние сборки, включая известный Cyanogen, продолжают использовать эту популярную технологию, и по какой-то неизвестной причине не могут от неё полностью отказаться. Говорю, как владелец Nexus с CM10.
            • +1
              ArtRoman — так а кто вас заставляет их использовать? Меня ВСЕ устраивает в ванильном 4.1 (лукавлю, все кроме поисковой строки сверху) и даже не нужно Apex и Nova. Тут уж вам решать или рюшечки в виде профилей и тп или стабильность и плавность интерфейса. Я за второе. Поэтому Сток рулит и заруливает))
              • 0
                Никто не заставляет, и Nova стоит и устраивает. И профили не нужны, но вот одной функции не хватает, которая совсем уж могла бы быть в дефолтном андроиде — переключение треков по долгому нажатию клавиш громкости, это просто очень удобно при прослушивании музыки через проводные наушники.
          • 0
            Как владелец Nexus (7) могу с уверенностью сказать, что в 4.1 действительно отсутствует фича подтормаживания, но в 4.2 они исправили этот досадный баг, и 4.2 (у меня, по крайней мере) тормозит иногда похлеще, чем старенький андроидофон.
  • +7
    А эта ОС случайно не нарушает патент Apple на иконку настроек в виде шестерёнки?
    • +1
      я больше подумал что круглые иконки нового nano
    • +3
      Я вот не уверен в том, что в Бразилии существует патент на значок шестерёнки.
      • +1
        Иск к Фонду Мозиллы в Штатах, правда, теоретически возможен, но на практике породил бы массовую неприязнь к истцу и никакой существенной выгоды.
        • +1
          Не думаю, что Фонд Мозиллы будет получать прямую прибыль от продаж ОС, следовательно и иск к ним выдвигать не будут
  • –1
    Очень странно выглядит привязка телефона именно к цене. Хотелось бы все же увидеть ТТХ этого девайса «за 50 фунтов». Для примера — за такую сумму можно взять андроидофон с 1ГГц процессором и 256 Мб памяти.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +13
    Автор сектант.
  • +13
    Даже на видео видны тормоза интерфейса. А что будет на смартфонах за 50 баксов? Их начнут ненавидеть, как и саму ось.
    • +2
      Там распери пи.
      Кроме того видно что лагает сам скринкастинг.
    • +3
      Слушайте, а вы не думали, что лагает из-за того, что это тот самый Otoro device за 50 баксов и на нём ОС которой ещё и года нет?
      • 0
        Ну если сейчас они не заложат аппаратное ускорение графики и JS, то потом это будет сделать невозможно. Вот и первое впечатление можно сильно подпортить.

        Причем возможна та проблема, что есть у Андроида, но нет у Айфона — поддержка всего зоопарка оборудования. Тут либо строгая сертификация, либо только одна заточенная платформа. В топике про разработку игр под Андроид видели фотографию стола с сотней девайсов на Андроиде?
        • +2
          Аппаратное ускорение там и так присутствует, другое дело, что какие другие участки кода не оптимизированы.

          Кучу аднроид фонов видел. Только не могу понять причём тут конечный разработчик под FxOS. Вы спокон веков делали сайты под разные мониторы. Responsive Design это не так сложно как кажется.

          На счёт сертификации возможно вы правы и вендорам устройств придётся подстраиваться под ту архитектуру, что будет. Но хочу напомнить, что Mozilla это некоммерческая организация, Apple или Google. И всё, что они могут это только сотрудничать с заинтересованными вендорами.
  • 0
    Текст писал не Стив Джобс? Ну, в смысле, вы поняли. Могут быть проблемы с Apple из за воспевающего стиля описания продукта)
  • +4
    как то в последнее время в html5 в качестве платформы для мобильных приложений стали разочаровываться… вон, и Цукерберг заявил, что отныне все аппы для фейсбука будут нативными.
    • +1
      B Firefox OS HTML5-приложения и будут нативными.
    • +3
      Вы один из тех наивных людей, которые прочитали одну новость с 3мя словами вырванными из контекста? А потом прочитать новости с заголовками «Что на самом деле имел введу Цукенберг говоря о HTML5» прочитать не судьба?
  • +2
    Звучит не плохо, однако не совсем понятно как будет реализована система безопасности firefox OS. Сегодня, это основная проблема как мобильных ОС так и веб. Если они предложат нечто революционное в этой области, то как раз это и будет настоящим прорывом.
    • +2
      Дайте авторам помечтать, единый DOM на всю систему и возможность подменить из любого скрипта любую функцию системных js-объектов, это ли не торжество гибкости и открытости.
    • 0
      С документацией о безопасности можно ознакомится здесь.
  • +13
    ОС должна быть на Си и асме. Точка. И не только ядро, но и гуи.
    Хуже яваскрипта в эмбеддед могут быть только системные демоны на питон.
    • –7
      Современные джаваскриптовые движки не так уж и уступают Си по скорости.

      А придёт IonMonkey — вообще веселье начнётся.
      • –1
        Я даже больше скажу. В андроиде вон Java. И не тормозит. Браузер в андроиде. На Java. И тоже не тормозит.
        В B2G (уж извините, называю по старинке) Gecko на нативном коде. Почему он должен тормозить?
        • +13
          Браузер в андроиде не на java. Он на webkit который является компонентом системы и выполняется в нативном коде.
          • 0
            Ну в таком случае сорри.

            Но всё равно — если не тормозит webkit на нативном коде, то почему должен тормозить gecko?

            P. S. А огнелис под android тоже на нативном коде?
            • 0
              то почему должен тормозить gecko?

              У них местами движок более тяжелый, необходимо оптимизировать.

              А огнелис под android тоже на нативном коде?

              Насколько знаю да. NDK доступно под Android давненько.

              • 0
                Под Android и FxOS движок Gecko естественно немного другой и очищен от всякого лишнего кода и XUL, так как там нет надобности поддерживать всякие WinXP и древнее.
                • 0
                  Ну что касается XUL, я сомневаюсь. Кажется, в Gaia UI было что-то на xul…
                  • 0
                    Я писал там email приложение для Gaia, нет там никакого XUL. Это на десктопе есть используется XUL window для запуска Gaia, а на FxOS даже иксов не будет.
                    • 0
                      Да, сейчас посмотрел, ничего похожего не нашёл.
                      Видимо это и правда в десктопном варианте было :)

                      Зато обнаружил WebGL в галерее).
            • 0
              Конечно в нативном. Не так просто взять и переписать 150Мб кода из c++ в java.
              • 0
                Вы конечно правы, но API ведь везде разное. В win — всякие WinAPI, в маке — это Carbon (для c++).

                И в этих 150 мб нужно было как минимум две трети портировать на новую платформу.
        • 0
          И я также больше скажу: есть средства для компиляции Си и Си++ в JavaScript. Из которых наиболее известен Emscripten.
          • +2
            Ну давайте вы переведёте код на C/C++ в JS и запустите его в IonMonkey, а я скомпиляю его посредством ICC с -O3 IPO и PGO. А потом сравним производительность ;-)
          • 0
            В JS вообще компилится всё, что не лень: Ruby, Python, perl, scala, java, c#, даже lisp и haskell.

            Ну, собственно, ссылка: github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
        • +5
          Не тормозит? Java не тормозит? Ну и шутки у Вас…
          • +1
            Вспомните Томми: иногда и вправду не тормозит.
    • +11
      GUI на C и асме? Что вы курите?
      • –4
        Ничего. МакОС, вынь, кде, гном= гуй си + асм.
        • +7
          В МакОСи Objective-C, который от C и асма достаточно далек.

          KDE — это Qt, который от C и асма тоже весьма и весьма далек (вплоть до аналога GC на подсчете ссылок).

          • +1
            Гном — гуй на js.
            • 0
              Ну будет точнее сказать gnome 3 (gnome shell и gnome classic).

              Используется gjs, внутри spidermonkey
          • +3
            смысл не в языке, а в минимуме прослоек.
            • –2
              Эта фраза абсолютно бессмысленна.
          • 0
            Ну, всё же подсчёт ссылок — это далеко не GC.
            • +2
              Я знаю. Просто в Qt можно делать что-то типа такого:

              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. Программист по возможности максимально огорожен от каких-либо низкоуровневых действий.

              Но из-за того, что это С++, у некоторых людей начинаются непроизвольные оргазмы «это же!!! С++!!!» :) Хотя оно работате со скоростью того же дотнета :)
              • 0
                В приведенном примере структура напоминает дерево. Если один виджет владеет остальными и может их удалить в деструкторе, то это ни разу не GC. Это как приводить в пример связный список и говорить что это GC.
                Также, имея С++, можно в нужных местах писать производительный код… + использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.
                • 0
                  Я и это знаю :) Я веду к тому, что Qt максимально изолирует разработчика от низкоуровневости C++. Код с использованием Qt мало чем отличается от кода, написанного на дотнете, наример. При этом использовать низкоуровневые вещи (да даже и высокоуровневые, типа шаблонов) достаточно опасно, потому что можно порушить всю эту хрупкую красоту.

                  А производительность Qt — ну так, так себе.

                  > использовать различные библиотеки в местах критичных к производительности тоже надо с умом, тогда все с производительностью будет в лучшем виде.

                  Ну так это относится не только к Qt ;) Никто не мешает в критичных к скорости кусках на Ruby/Python/.NET/вставить_свое использовать библиотеки на С/С++ ;)
                  • 0
                    Я просто обычно использую Qt для связи с интерфейсом и т.п., а если в процессе появляется например необходимость обсчитать какую-нибудь рабочую область какого-нибудь невероятного устройства или проложить какой-нибудь хитро-выделанный маршрут на невероятных размеров карте, то создаем обычный класс и, никуда не переключаясь, в C-style пишем все быстро и оптимально. Идеологически это конечно не совсем тру, но «какого черта, мне надо чтобы программа в этом месте выжала максимум из компьютера!» :)
                    На той же яве реализовать такой подход было бы ИМХО труднее.
                    P.S. Использую Qt в исследовательских проектах и для мат. моделирования… вполне встречаются ситуации, когда программе надо даже в виде сишных массивов отожрать гиг-другой памяти и активно его колбасить. Зато если надо что-нибудь сделать с интерфейсом или отображением, или не критичный к производительности алгоритм, то также не напрягаясь можно сделать это используя всю мощь Qt.
                    • 0
                      Ну, то есть, мы по сути достигли с вами консенсуса и взаимопонимания :)
                      • 0
                        Вполне :) В двух словах: я пытался донести мысль, что при правильном применении, выигрыш в производительности софта при использовании С++ и Qt совсем не мифический.
              • 0
                Ну и как этот подсчет ссылок влияет на скорость работы если эти все видгеты разрушаются один раз и одновременно? При закрытии окна приложения еще скорее всего к тому ж.
                • 0
                  Там помимо подсчета есть много чего другого ;) Собственно сам GUI, сигналы/слоты, сделанные, по сути, на коленке
              • 0
                В данном случае это даже не подсчёт ссылок. QObject может иметь родителя и только одного. Родитель знает обо всех своих детях. При собственнос уничтожении, он уничтожает и детей. Логика простая.

                PS да, я тоже люблю Qt. А ещё COW замечательная штука.
          • –1
            в конечном счете — все на асме :-))
      • –9
        Меня вообще умиляют всякие вендройд-пейсатели, которые не знают даже, как на ARM'е прибавить к переменной в памяти значение (на асме). Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа. Не знаю как для вас, но для меня это абсолютный нонсенс.
        • +7
          Это может вам не нравиться, но это цель, к которой ведет прогресс в языках программирования.
          Наращивают уровни абстракции, вытесняя низкоуровневое — когда-то на асме писали все, потом его вытеснили до уровня вставок, сейчас вытеснили почти полностью, причем даже из эмбеддед, на его место пришел «среднеуровневый» С.
          Даже С++ из прикладного активно вытесняется, добавляя еще один уровень абстракции в виде ВМ — явами, дотнетами, даже теми же питонами.

          • –1
            Вытеснили-не вытеснили это я могу поспорить. Берем ffmpeg и какой-нибудь абстрактный MIPS-процессор от всем известного кетайского ноунейма. Девайс — ну пусть будет электронная книжка. И что же мы видим в ffmpeg? Тонны SIMD инструкций на асме, типа конвертации цветов, ресайза и прочего. И так много где в разных девайсах. Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.

            Я понимаю, что против течения плыть смысла нет, и если что-то нужно нопейсать на андройде, то выбора особого нет. Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.
            • +2
              >Вендройд и iOS не беру к рассмотрению, так как относительно первого руки опускаются а относительно второго сорцов нет.

              Это и значит что вытеснили. Количество мест где он остался катастрофически мало — ну да, в кодеках где-то в глубине может остаться. Но количество таких мест сокращается. Не говоря уж о том, что все больше таких жрущих вещей интегрируют на аппаратном уровне в SoC, те же кодеки.

              >Но с другой стороны, возможно хорошо, что есть такие как я, которые если видят очередной калькулятор размером в 50 мегабайт, отжирающий для своей работы метров 200 оперативы, у них просто нет слов.

              Я не уверен, что негодование на форумах — это прямо хорошо. В конце концов, если это выбор юзеров, значит им нравится этот калькулятор. Если вы не пишете свой, на удобном вам языке, который сможет вытеснить тот, 50-метровый — то это негодование лишено смысла. Если вы напишете его, но он будет проигрывать в юзабилити, в качестве интерфейса и т.п., пользователям будет глубоко плевать на то, что он весит в десять раз меньше.

              А скорость разработки (и отладки и рефакторинга) сильно падает со снижением уровня языка.
            • +2
              Задачи обработки видео очень специфичные!

              Трудно что-то поделать с современной разработкой ПО — уже почти никто не заботится о том, чтобы программа нормально работала на устройстве пользователя, мой любимый пример — разница в скорости работы 2008 и 2010 MS VS. Даже в MS при разработке конечного несистемного продукта не особо думали об экономии, чег ждать от кустарных разработчиков или из них поднявшихся — коих большинство среди Android девелоперов.
        • +5
          > Как блеадь можно программить, если ты не знаешь, что происходит с твоим кодом на уровне железа.

          Ну-ка ну ка. Вы точно знаете, во какие инструкции оптимизирующий компилятор разворачивает ваш код на разных процессорах? На x86? На ARMе? С набором инструкций SSE2? SSE3? С оптимизацией по скорости? С оптимизацией по размеру?

          Да нифига. Вы даже близко не имеете представления.
          • –3
            А если таки имею представление? На ARMе мало пишу, поэтому тут да, точно не знаю. А вот с x86 могу с вами поспорить. Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме. И да, я знаю как будет с оптимизацией по скорости или по размеру. Матрицы между собой не множу, поэтому SSE2, SSE3 не использую.
            • +1
              > А если таки имею представление?

              Тогда вы входите в 0.01% разработчиков. Не потому что разработчики тупые, а потому что оптимизирующие компиляторы слишком умные и стандарты слишком огромные.

              > Когда я пишу код на высокоуровневом языке, я имею четкое представление во что он компилируется на асме.

              Вот насчет четкости я очень сильно сомневаюсь. Хотя, повторю, вы можете входить в 0.01% разработчиков, которые досконально знают стандарт соответствующего ЯВУ и все особенности целевой платформы.

              А для использования SSEx и не надо матрицы перемножать.
          • +8
            Это правда. Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера, потому что примерно знаю какой код С++ как реализован. Я точно знаю где происходит аллокация и деаллокация. Я точно знаю это и могу рассматривать детерминированные сценарии использования памяти. Я не боюсь, что в какой-то момент запустится мусоросборщик и всё зависнет.

            Наконец, все вот эти вот фразы, что «у нас всё работает не медленнее чем на С или С++» — это как правило значит, что люди серьёзные приложения не сравнивали. Ну быстрее работает неинтерпретированный код. Быстрее. И не только потому, что оптимизирующий С++ компилятор имеет больше времени на оптимизации, чем JIT. Сама структура языка предполагает более детерминистский подход к программированию. Это сложнее, да. Но если этим правильно пользоваться, то будет реально быстрее.

            Мне ОЧЕНЬ не хватает нормальной поддержки С++ на Андроиде. Мне будет точно также не хватать её в этой ОС. Я ещё понимаю, если бы скорость девайсов была такая, что интерпретированность не чувствовалась. Так ведь нет же: берут слабую железку, заставляют писать на высокоуровневых и менее эффективных (с точки зрения исполнения) языках. При этом ещё обрубают высокоэффективные средства разработки на С++.

            Ну и наконец, вся эта хвалёная стабильность систем на Яве. Всё это на практике виснет, глючит и падает ничуть не меньше, чем нативный код. Программы с утилитами точно также глючат, при этом ещё съедают гораздо больше памяти.

            Тогда спрашивается — НАФИГА было затеваться с Явой?
            Ну сделайте вы систему открытой. Допилите под неё gcc и прочее. Остальные постепенно подтянутся.
            Пусть кто на чём может, тот на том и будет писать. Кто не может или не хочет С++, пусть пишет на Яве, Яваскрипте, да хоть брэйнфаке.

            Что это за дурацкие проприетарные ограничения, которые выдаются гигантами за охрененно продвинутый современный подход, которые к тому же плохо себя показывают на практике?
            • +4
              Вот действительно. У меня недавно умер HTC Inspire 4G, хожу опять со старым HTC Herald под WM 6.5, с 200мгц процессором и 64 мб оперативки. И ничего, все работает достаточно шустро, оперативки хватает на 3-5 приложений, потому что тогда заботились об оптимизации, а сейчас — нет.
            • 0
              А джаву вообще-то пилили — был такой проект, gcj, так он компилировал джава-код до версии 1.5 в нэйтивы с использованием как раз-таки gcc, как я понимаю. К сожалению, его забросили, а значит это не пользовалось спросом.
              А вообще с джавой есть смысл затеваться. Она намного комфортнее и быстрее для разработки, чем любой другой язык старше ее из мне известных. И всем пофигу, что она где-то может быть не так эффективна в исполнении. 5 лет назад, я бы сказал, что на джаве гораздо сложнее сделать критические ошибки, чем на сях. Теперь я думаю, что и джава плохой язык, потому что они тоже зафиксировали стандарт — теперь надо переходить на следующий уровень — котлин, например.
            • 0
              > люди серьёзные приложения не сравнивали

              Что такое «серьезные приложения»?

              > Тогда спрашивается — НАФИГА было затеваться с Явой?

              Потому что они хотели больше контроля над системой, например?
              • +2
                Ява даёт больше контроля над системой, чем С++? Я верно понял ваш тезис?
                • 0
                  Ява может дает больше контроля производителю над тем, что понапишут горе-программисты :)
                  • 0
                    Что такое «контроль производителя»?
                    • 0
                      Что разработчик не сожрет память, не оставить память течь и т.п.
                      • +2
                        В С++ при правильном подходе у разработчика также будет изъята возможность устраивать проблемы с памятью (я писал об этом статью в своё время).
                        Я также утверждаю, что эти проблемы решить куда проще, чем проблемы многопоточности, проблемы неверной логики работы алгоритмов, проблемы покрытия различных ситуаций (включая нештатные). Ява здесь не решает вообще ничего по сравнению с С++.
            • +1
              > Но я могу хотя бы примерно примерно оценить сверху скорость выполнения отдельных участков кода БЕЗ профайлера

              Аналогично для любого ЯВУ :-\ Потому что на первом месте алгоритмы, а потом уже то, во что оно компилируется. Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
              • +2
                Профайлер вам не покажет, что вообще ВСЁ в Яве делается медленнее, чем в С++. Начиная от обращения к переменной, и заканчивая работой с динамической памятью. Вы лишь увидите наиболее относительно медленные участки. Вот только относительно чего? Вы же не уберёте мусоросборщик, не поменяете внутреннюю логику работы с переменными (там где С++ работает со стеком процессора, меняя всего один его регистр).
                И здесь я даже не говорю про память. А на этом стоило бы остановиться подробнее.
                Но — зачем? Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++. Нужно ли мне тратить время на разубеждение? Не вижу смысла.
                • +1
                  > Вы пришлю сюда заранее уверенным в том, что Ява может быть не медленнее С++.

                  Нет. Как всегда, на хабре люди не умеют читать. Вот, что я написал:

                  Только вот профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).


                  Тут не говорится, что Java быстрее C++.
                  • 0
                    Понимаете, всё это не объясняет, почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.
                    Маркетинговые заголовки типа «решает проблемы с динамической памятью» — потускнели и покрылись трещинами. Из самописных андроидовских программ на яве, дай бог если половина не падает.
                    • +3
                      Потому же, почему подавляющее большинство энтерпрайз систем не на С++, а на managed-языках типа явы и дотнета.
                      Выше скорость разработки, проще поддерживать код, больше ошибок ловится на стадии компилляции.
                      • 0
                        Если сравнивать Яву с С++ и фремворками образца начала 2000-х, то скорость разработки безусловно выше. С тех пор многое поменялось. Вот не самый свежий пример:
                        www.ultimatepp.org/www$uppweb$vsswing$en-us.html
                    • +1
                      > почему вместо хорошего фреймворка С++, потребовалось городить отдельный язык с фреймворком.

                      Вы вообще сейчас про что? Про Яву вообще или только про Андроид.

                      Если про Яву вообще, то причины, по которой она создавалась, можно почитать в той же Википедии. Если в общем говорить, не только про Яву, то С++ не позволяет огромное количество вещей. Например, ФП в него надо заколачивать гвоздями, и результат выглядит не просто убого, а сверхубого. И это только вершина айсберга.

                      Для большинста прикладных задач хватает любых языков, и С++ там не поможет.
                      • 0
                        Отлично! Забыли про динамическую память, теперь говорим про ФП.
                        Скажите пожалуйста, чем отсутствие ФП в С++ мешает, как вы там выразились, для большинства прикладных задач?
                        • 0
                          Гы, так linq + ef и спроектирован для enterprise, чтобы писать так:

                          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-запрос, который выберет лучшего клиента (по кол-ву дорогих заказов). Границы между данные в базе и загруженными в память стёрты (хотя можно гибко управлять политиками загрузки, если требуется оптимизация).
                          • 0
                            Как я говорил выше, подобный уровень удобства давно уже дают фреймворки в С++. И давно уже есть компиляция (compile-time!) на необходимый диалект SQL. Например, вот так.
                            • +3
                              Это всё дикие костыли. Без поддержки Expression Trees в языке невозможно добавлять свои SQL-функции, специфичные для СУБД, без влезания во фреймворк.
                              • 0
                                Что значит костыли? Кусок, отодранный из Cω, и добавленный спустя пять лет после разработки основного языка, это не костыли?
                                Мы ведь говорим об эффективности, о памяти, об удобстве. Тот пример запроса, что вы привели выше, давно уже компилируется и в С++, я вам привёл пруфлинк. Всё работает стабильно, быстро. И пользоваться удобно.

                                Что касается SQL-функций, то имеется в виду PL/pgSQL и что-то подобное? Если да, то это довольно большая специфическая тема, далёкая от обсуждаемого «большинства прикладных задач».
                                • 0
                                  Нет, пример не работает ))))
                                  Это голый 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 одновременно
                            • +1
                              И эти фреймворки будут работать с такой же скоростью, как и аналогичные на не-С++. Чудес не бывает.
                              • 0
                                Простите, а вы сколько программ на этих фреймворках написали, чтобы это говорить? )

                                «Эти фреймворки», как вы выразились, работают в 2-3 раза быстрее STL даже на базовых операциях типа работы с динамическими массивами или строками.
                                Компиляция SQL идёт на стадии компиляции программы. То есть, с точки зрения динамических языков, во время выполнения происходят мгновенно.
                                • 0
                                  На многих и разных. Конкретно на этом не работал
                                • –1
                                  Какая разница, если ещё как минимум две прослойки до СУБД (ODBC-драйвер и TCP/IP, например)
                            • 0
                              Главный недостаток предложенного фреймфорка — это трансляция в голый SQL, когда нормальные ORM умеют мапить объект по нескольким таблицам, поддерживают наследование, lazy-загрузку по ссылкам, поддержку отношений 1-ко-многим и их lazy-загрузку либо генерацию sql по аггрегированным запросам к ним т.п.
                              • 0
                                Да, этого нет. И здесь я бы воспользовался возможностью динамической генерации кода — но без ненужных свистелок вроде мусоросборщика и лишних проверок. Что касается отложенного исполнения — это очень серьёзный вопрос, я бы не стал однозначно высказываться за его наличие в том виде, как оно подаётся сейчас. Мне сейчас недостаёт контроля над отложенными операциями, что критично при закрытии программы или окна, например.

                                Если бы было что-то подобное, локально-динамическое и гибкое для С++ — я бы задумался о переходе. Без огромных виртуальных машин (они могут быть локальные и очень маленькие), без оверхеда по памяти и мусоросбощика и прочего.
                        • 0
                          Никто ничего не забыл. Был один из возможных ответов, почему некоторые задачи не решаются фреймворками на C++.

                          C++ — не панацея. Это достаточно неудобный и достаточно низкоуровненвый язык. Он банально не подходит для решения большинства задач.

                          Ява появилась, потому что нужен был язык с гарантией типизации и защитой памяти, которую С++ (особенно на начало 90-х) представить не мог (а благодаря наличию C-style cast не может гарантировать типизацию и сейчас).

                          Другие языки появлялись и будут появляться, потому что С++/Java/C#/вписать_свое не дают решения каких-либо других задач.

                          При этом вздохи «ах, эти все языки медленнее, чем C++» можно смело отправлять в /dev/null, потому что

                          профайлер потом покажет, что проблема в БД, сети, доступе к диску — и это задолго до того, как начнутся проблемы в нативном/интерпретируемом коде (для большинства прикладных задач).
                          • –1
                            1. Защита памяти.
                            И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++? А плохо написанные приложения на Яве — не падают?
                            Я пробовал разные приложения что на чистой Яве, что на Андроиде — и знаете что — они падают. И падают довольно часто. Может, конечно, у меня с Явой что-то не то, не знаю.

                            2. По поводу плюсов и минусов Явы перед С++, в той самой Википедии, на которую вы ссылаетесь, написано следующее.
                            а) Независимость байт-кода от операционки (мы все знаем, что на деле распространяется несколько бинарников для нескольких процессоров, что покрывает 99% пользователей).
                            б) Система безопасности. О ней я писал выше — там всё очень и очень спорно, как минимум.

                            И что же мы получаем за эти неочевидные преимущества:
                            — замедление работы кода в несколько раз
                            — потребление памяти в 10-30 раз больше

                            Заметьте, это не я придумал, это написано в Википедии, на которую вы сами же и ссылаетесь.
                            • +3
                              > И как защита памяти от Явы, спасла? Приложения на Яве — стабильнее нормально написанных на С++?

                              У разработчика средней руки — да.

                              > И что же мы получаем за эти неочевидные преимущества:
                              > — замедление работы кода в несколько раз
                              > — потребление памяти в 10-30 раз больше

                              Боже. Вы научитесь хоть когда-нибудь читать?

                              Для подавляющего большинства прикладного кода это некритично.

                              • +1
                                > Для подавляющего большинства прикладного кода это некритично.

                                Как я говорил выше, против религии аргументы бессильны. Если для вас всё о чём говорилось — некритично, то обсуждать просто нечего.
                                • 0
                                  Ну, религия только у вас. Это вы тут считаете С++ и фреймворки на нем панацеей от всего.

                                  Например, в GUI C++ не нужен даже даром. Там важно не мифическое «в два-три раза быстрее», а отзывчивость интерфейса. Которое, очень грубо говоря, ограниченно порогом моргания человека (~50ms, емнип), и это обеспечивает любой язык программирования влегкую.

                                  В вебе С++ не нужен даже даром, потому что приложение сначала упрется в ограничения (нативной!) базы данных и/или (нативной!) сетке прежде, чем начнутся проблемы собственно с приложением.

                                  GUI + Веб сейчас покрывают ~70-90% прикладных направлений.

                                  И только для оставшихся, где нужна высокая производительность (низкоуровневое, системное, графика, видео) С++ вполне подойдет.

                                  Я же говорю: вы неспособны читать, что вам пишут, ибо С++ застил вам глаза
                                  • 0
                                    > Это вы тут считаете С++ и фреймворки на нем панацеей от всего.

                                    Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.
                                    Что касается остального потока сознания в вашем комментарии, я не буду ничего писать по причине, изложенной выше. Предлагаю вам прекратить этот бессмысленный диалог.
                                    • 0
                                      > Это вы так читаете, попутно скатываясь к переходам на личности. Что вас не красит.

                                      Да ну? Кто тут рассказывает сказки про то, что все можно и нужно решать фреймворками на С++? Не я же

                                      > Что касается остального потока сознания в вашем комментарии

                                      И это человек мне еще говорит о религии :)))
                          • 0
                            А еще потому, что для большинства приложений и профайлер не потребуется запускать — приложение будет работать «достаточно быстро». Ну а там, где будет работать недостаточно быстро, зачастую можно будет докупить/заменить железо, что в итоге выйдет дешевле оптимизации кода.
                            • –1
                              А еще чаще (по вебу знаю) сначала достаточно подтюнить базу данных и дисковую систему, чтобы скорость приложения выросла в разы.

                              Пользуясь случаем: MySQL (натвный, на С!!) — говно :)
                              • +1
                                Или базу, или запросы, да. Что и неудивительно, поскольку огромное число веб-приложений — суть прослойка между гуем и базой.
                    • +1
                      Если отвлечься от практики и потеоретизировать, направление на managed-среды в ОСестроительстве давно просматривается (Microsoft чтобы внезапно не оказаться отставшей понемногу тоже пилит).

                      Плюсы понятны: убрать границы между процессами. Убрать оверхед на IPC и переключение адресных пространств. С другой стороны, будут подтягиваться компиляторы и верификаторы программ. В циклах проверка границ будет только для начального и конечного индекса, а не при каждом обращении к массиву и т.п. Это уменьшит тормоза managed-кода. В идеале компилятор научится полностью доказывать корректность алгоритма (сейчас это возможно, но очень затратно вычислительно) и ставить проверки только на входные параметры функции, а программисту давать warnings — «не могу оптимизировать, выкинув проверки, потому что в таких-то входах программа свалится».

                      Но пока в юзер-программах есть хоть строчка native-кода, это остаётся небезопасным.
                      • 0
                        Очень интересно будет посмотреть на производительность этой системы. )
                        А особенно интересно будет, если, как вы предлагаете, всё делать в одной задаче: если вдруг что с виртуальной машиной, то падает вообще весь user space. Напоминает старые времена DOS.
                        Этакий anti-unix way.
                        • 0
                          На всякий случай — это такое заглядывание в далёкое и неизбежное будущее, я не говорю, что сейчас так надо делать.

                          Производительность будет выше, т.к. нет процессов, нет kernel и user, нет IPC, нет классического клипбоарда (любая передача данных — просто ссылка на managed-объект, а все объекты пусть будут read/only, как в чистом лиспе).

                          Падений не будет, т.к. ВЕСЬ код формально верифицирован и доказана правильность выполнения при корректных входных данных. А проверка корректности входа будет выполнятся единожды при передаче на вход алгоритма. Там, где доказательство провалилось, проверки будут как обычно (к слову, постоянный challenge для математиков: если какая-то сортировка не доказывается формально, а интуитивно правильная, это надо исправлять и фиксить «компилятор»)
                        • +1
                          Это вообще несерьезно. С тем же успехом можно сказать «если вдруг что с ядром то падает вообще весь юзерспейс» — что, кстати, весьма частое явление при падении дров. Разумеется, если падает низкий уровень, то отвалится и все остальное, или если у вас ядро выпадет с бсодом или паником, юзерспейс останется живым?)

                          А подобные системы есть, дотнет микрофреймворк допустим.
            • +1
              >Тогда спрашивается — НАФИГА было затеваться с Явой?
              Это вы сейчас про Android? А как быть с зоопарком процессоров? На телефоны ставить gcc, из маркета скачивать исходники и компилировать на месте?
        • 0
          Скажите, а вы точно знаете что происходит в двигателе вашей машины, когда вы включаете зажигание? В каком порядке следуют циклы, без подсматривания в википедию, знаете? Какие сигналы посылает контроллер форсункам? Вам надо это знать чтобы доехать из точки А в точку Б?
          • +4
            Да, я точно знаю что происходит в двигателе моего автомобиля. Начинал с обычного карбюраторного, а сейчас инжектор.Без подсматривания в википедию.
            • 0
              Я поздравляю вас, что вы всё точно знаете )
              Я занимался электротехникой и эектроникой, знаю как работает компьютер на физическом уровне. Я не про команды на ассемблере, а про физическую реализацию логических элементов на основе транзисторов и т.д., конечно. Вы, надеюсь, тоже знаете? Ведь невозможно без этого точно понимать что скрывается за каждой ассемблерной командой. Да что там ассемблерной, мне посчастливилось увлечься машинным кодом, правда недолго. Интерес интересом, но в работе это не нужно.
              Сейчас пишу на языках высокого уровня, а это осталось как хобби. И скажу вам честно, эти знания абсолютно необязательны для программиста на языке высокого уровня.
              Если вы представляете как всё реализованно на несокольких уровнях абстракций, то это даёт вам, разумеется, эстетический самолюбовательный бонус, но не более того. Для практики достаточно знать свой уровень и работать с конкретной предоженной моделью без знания внутренних деталей.
              А ниже электротехники есть ещё физика.
              Вы же не знаете, как взаимодействует материя на уровне квантовой физики? Я вот не знаю, но живу )
              • 0
                Если этого не требуют Ваши задачи, это не означает что у других все так же.
          • +2
            Всё зависит от задачи.
            Пользователю (а автолюбитель — это максимум уровень продвинутого пользователя) действительно не так важно знать, как оно работает. Уметь хотя бы минимально настраивать — уже хорошо (ну там фильтр воздушный зима-лето, жидкостей подливать когда надо, проверять стёртость колодок и т.п.).

            Программисту (то есть автоконструктору) знать эти вещи обязательно. И, уверяю вас, он их знает без всяких Википедий.
            • +1
              Знаете, я в корне не согласен, что это нужно знать. Я вот например проектирую средние и большие корпоративные приложения. Несколько БД, сети, GUI на разных языках и платформах. Если бы я вдавался в детали реализации той или иной операции на уровне ассемблера я не смог бы сфокусироваться на архитектуре в целом. Да меня даже не интересует порой как тот или иной запрос работает на разных СУБД, пока конечно этот запрос не начнет создавать проблемы. Современная парадигма программирования позволяет мне абстрагироваться от деталей реализации нижних уровней, так зачем мне о них знать? Тем более если эти детали работают так как заявлено.
              • +1
                Ни в коем случае не спорю с тем, что вы говорите! Полностью согласен.
                Я говорю об уровне с которого нужно уметь писать свои фреймворки. Там в их внутренности нужно разбираться детально.
                А если говорить об уровне приложений, то разбираться конечно не обязаны. Нужно лишь уметь примерно качественно оценить затраты той или иной функции (хотя бы на уровне O(n) или O(nlog(n)) и т.д.)
                • 0
                  Имхо, в подавляющем большинстве случаев достаточно знать уровень, который непосредственно используешь (библиотеки, фреймворки и т. п.) и иметь представление о нижележащем.
        • +2
          Вы уж не обижайтесь, но вы абсолютно не лучше тех, кто пишет демоны на Python, и ОС на JavaScript. Вы такой же фанатик, и рассуждаете также фанатично.

          Ясное дело, что представлять как работает железо, и что там происходит — полезно. Но как было и ниже сказано, и выше, языки программирования развиваются в сторону повышения абстракции. Это не хорошо, и не плохо — это нормальная реакция на реалии разработки ПО.

          И сейчас нормальное дело, что есть такие низкоуровневые ниндзя как вы к примеру, хорошо понимающие нижние слои абстракции, и есть ниндзя которые виртуозно разрабатывают на языках высокого уровня. Разные потребности, разные задачи, разные специализации.

          Давайте просто каждый будет заниматься своим делом, и не лезть со своим уставом в чужой монастырь, просто потому что, ваши взгляды не совпадают со взглядами людей, которые занимаются совершенно другими задачами или проводят эксперимент в проекте, в котором вы не принимаете участие. Может оно кажется диким, но если они могут провести эксперимент — почему нет, вдруг что-то выйдет?
  • +21
    Ждем проекта Boot2Excel от Microsoft. Операционная система на макросах и формулах Office. VBScript в массы!
    • 0
      Времена Бейсика прошли. Джаваскрипт — это Бейсик сего дня!
      • +2
        И это очень грустно. Есть несколько гораздо более удобных языков, вроде Python или Ruby. Но в бейсики всегда выбиваются какие-то бейсики.
        • +1
          js среди динамических языков занимает место, которое принадлежит C++ у статических.
          Все ругают, но в то же время стандарт, куча библиотек, гибкость и т.п.
          • 0
            Я знаю какое место он занимает. Но, практически любой, попробовав Python или Ruby поймет, что место это незаслуженно. Особенно если учитывать библиотеки, лаконичность кода. А гибкости хватает у всех. Зато граблей в других языках на порядок меньше.
        • 0
          Могу ли я услышать от Вас, чем Python гораздо удобнее по сравнению с JavaScript?
          • 0
            Скобочек меньше :) А если серьёзно, то очень не хватает в JS нормальной модульности. Ну и плюс многим удобнее иметь дело с сильной типизацией, а не слабой.
            • 0
              Ну вроде готовят EcmaScript 6 с модульностью, питонистостью и рубистостью. =)

              Но ИМХО, JS должен оставаться таким как есть, и не быть затычкой везде где можно. Даешь Ruby и Python как дефакто на мобильных платформах
            • 0
              Пишите джаваскриптом на движке Node.js там модульность, насколько я могу судить по опыту, не ненормальная.
              • 0
                Насколько я знаю, там модульность эмулируется через объекты.
              • 0
                ИМХО, но не стоит делать JS затычкой для всего. Не буду вдаваться в холивары, но лично мое мнение — JS не про server-side. Он мне нравится как язык для клиентской разработки. Для server-side есть более подходящие и мощные языки и технологии.
  • +2
    Не знаю. Как по мне было бы намного лучше если бы они шли немного в другом направлении, например компиляции Javascript кода в бинарный код под конкретную платформу. Естественно многие динамические фичи станут недоступны, появится какой-то Javascript-C. Но проблема производительноси была бы решена? Знающие люди подскажите, неужели так сложно создать компилятор Javascript в машинный код? Причем компилировать можно ведь прямо во время установки приложения, под конкретную платформу.
    • 0
      Но зачем?
    • +1
      Всё равно производительность будет другой.
      Во-первых, на лету скомпилировать также качественно не удастся. Оптимизирующий компилятор того же С++ (в режиме полной оптимизации) требует совсем других времён и совсем другой памяти — ничего этого в маленьком устройстве может не быть, не говоря уже о том, что это сотни мегабайт данных, которые динамически генерятся и «перевариваются» процессором.

      Всё, на что можно рассчитывать в JIT — это баланс между скоростью и памятью при компиляции против её качества. Как правило, не в пользу качества.

      Но это ещё не всё! Как ты ни компилируй, у тебя останутся свистелки вроде фонового мусоросборщика, дополнительных накладных расходов памяти при аллокации, и самое главное — проблемы скорости динамических переменных. Работа с переменной в С++ не сравнится с той же задачей в Яваскрипт. Там, где С++ обходится простым вызовом процессорной инструкции, Яваскрипт осуществит массу проверок, выполнит массу кода, прежде чем перейдёт к непосредственной работе. И эта проблема ПРИНЦИПИАЛЬНО не решается оптимизирующей компиляцией, это логика работы динамических языков.
      Якобы, это спасает от проблем времени выполнения. На практике, даже этот довод оказывается очень спорным: от действительно серьёзных проблем в логике программы, динамическое программирование всё равно не спасает — программа, даже если не упадёт, то окажется неработоспособной. По сути, на практике выясняется, что нужна та же самая работа по отладке, что и в неконтролируемой среде.
      Да, динамическое программирование позволяет делать некоторые «финты», которые в ряде случаев уменьшают затраты на разработку. Но извините, пользователю пофигу на это всё: ему важно, чтобы программа на его не самом мощном устройстве хорошо и быстро работала. А по этой характеристике, динамические языки позади статических. Особенно, на слабых процессорах с минимумом оперативной памяти.
  • +3
    Firefox OS является началом чего-то невероятного. Это ожидающая своего пробуждения революция. Глоток свежего воздуха. Кульминация новейших технологий. Оно волшебно и оно изменит все.

    Ваша революция была отлично реализована в Palm WebOS и на ней даже существовали аппараты. И если выйдут аппараты на FirefoxOS я его даже куплю чтобы перешить на WebOS.
    • +1
      А почему вы ждете аппарата на firefox os, чтобы перешить под webos? Сейчас что мешает? Берете любой телефон и развлекайтесь. Проблемы будут точно такими же, загрузчик могут лочить, не будет драйверов под железо и т.п.
      • 0
        Проблемы будут точно такими же, загрузчик могут лочить, не будет драйверов под железо и т.п.

        Не будет. Потому что FirefoxOS. Его фишка в открытой аппаратной базе в том числе. К тому же открытая версия WebOS только только вышла.
        • +1
          А можно посильнее раскрыть слова «открытая аппаратная база»?
          Сейчас процентов 80 функциональности смартфонов заключено в центральной SoC. А на них вендоры категорически отказываются отдавать даташиты. Дают только производителям под NDA.
          Откуда тогда открытая аппаратная база?
          • +1
            А можно посильнее раскрыть слова «открытая аппаратная база»?

            Будут доступны не бинарные драйвера. Проще говоря вы сможете сами собрать свою модификацию под телефон.

            Сейчас процентов 80 функциональности смартфонов заключено в центральной SoC. А на них вендоры категорически отказываются отдавать даташиты.

            Вы вообще в теме? В SoC того же TI закрыт в данный момент только OpenGL драйвер к примеру. Причем он опять же доступен после регистрации. Именно по этой причине на N900 можно запускать что-то отличное от Maemo. И многие другие производители так же дают драйвера после регистрации. То что есть например такие жлобы как Nvidia и Qualcomm, как-то не отрицает наличие железа с доступными драйверами.
            • 0
              «Такие жлобы как NVidia и Qualcomm» отхватили огромную долю рынка, если планируют делать платформы для этого ФФОС на железе трехлетней давности, как нокиа 900, то вряд ли они далеко уйдут.
              • 0
                Если про Qualcomm еще хоть как-то похоже на правду, но вот про Nvidia точно нет :) Ну и не только на чипсетах Qualcomm делают телефоны.
                • 0
                  А как же Tegra3?
                  Кто ей противопоставлен, да еще и с открытыми доками?
                  • 0
                    А как же Tegra3?

                    И в скольких устройствах есть Tegra2 и Tegra3?

                    Кто ей противопоставлен, да еще и с открытыми доками?

                    TI OMAP 5, TI OMAP 4, Freescale i.MX53, Freescale i.MX 6

                    Основная проблема сейчас это OpenGL и GPU ядра там. Потому что как правило они изготовлены не этими компаниями и закрыты патентами. Но бывает что GPU драйвер доступен и закрыта только OpenGL библиотека. При этом бинарная сборка этой OpenGL библиотеки доступна.
                    • 0
                      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


                      Достаточно?
                      • 0
                        А теперь посмотрите список того что есть на чипсетах Qualcomm и сравните. Ну так для интереса.

                        i.MX53 одноядерный, до Тегры не дотянет.

                        И что? У нас давно тегра является эталоном производительности? Вообще вопрос шел доступны ли платформы с открытыми драйверами. И открывают ли вендоры даташиты. Я привел примеры кто открывает. И замечу там есть нормальные по производительности процессоры. Которых более чем достаточно для FirefoxOS.
                        • 0
                          Qualcomm тоже не открывает.

                          Пример вы не тот привели, под «открывает документацию» я имел в виду именно открытую документацию на SoC. Ту, где можно увидеть регистры, эррату и прочее.
                          Покажите мне современный SoC с таким даташитом, я бы хотел поглядеть.
                          Даже на всякое MIPSовое старье типа Atheros AR9330 не найти дока — хотя бы с перечислением регистров его периферии.
                          • 0
                            Qualcomm тоже не открывает.

                            А я где-то писал что открывает?

                            Пример вы не тот привели, под «открывает документацию» я имел в виду именно открытую документацию на SoC. Ту, где можно увидеть регистры, эррату и прочее.

                            www.ti.com/analog/docs/analogtechdoc_hh.tsp?viewType=mostuseful&rootFamilyId=3000&familyId=3020&docCategoryId=2

                            Я просто без регистрации зашел и кнопку нажал.
                            • 0
                              И что это должно символизировать?
                              Так можно и ссылки на AVR-даташиты покидать, говоря «вот они, открытые платформы». Это процессоры общего назначения, а не те SoC на которых делают смартфоны, в этих нету GSM модулей.

                              Можете привести ссылки на распространенные SoC, на которых собраны какие-нибудь более-менее известные смартфоны (не столетней давности), с подобным даташитом?
                              • 0
                                Это процессоры общего назначения, а не те SoC на которых делают смартфоны, в этих нету GSM модулей.

                                Эээ. Товарищ вы уверены что вы в теме? GSM модуль не входит в SoC. Я сколько видел, это всегда отдельное устройство. Потому что это удобнее и проще. Вот вам внутренности iPhone 4S www.ifixit.com/Teardown/iPhone-4S-Teardown/6610/2
                                Обратите внимание на два чипа Qualcomm RTR860 и Qualcomm MDM6610. В данный момент проще производить процессор с пачкой выводов общего назначения куда цепляется уже все остальное. И gsm модуль чаще всего представляет из себя вообще отдельную систему, со своей ОС.

                                Можете привести ссылки на распространенные SoC, на которых собраны какие-нибудь более-менее известные смартфоны (не столетней давности), с подобным даташитом?

                                На OMAP3 были телефоны. И там есть datasheet на него. Вопросы?
                                • +1
                                  О как, прямо отдельная ОС.
                                  А вы уверены, что вы в теме?

                                  >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 высокой степени интеграции — большая редкость.
                                  • +1
                                    О как, прямо отдельная ОС.
                                    А вы уверены, что вы в теме?

                                    Отдельный процессор со своим отдельным ПО. Весьма часто бывает.

                                    Вот вам Qualcomm'овский проц, причем даже не последний, на нем еще старый HTC Desire делали иже с ним. Встроенный GSM модуль. Встроенный Wi-Fi модуль.

                                    Слово embedded DSP вас не смущает ну никак да? Да оно может быть внутри. Я этого не отрицаю. Но чаще бывает с наружи. В случае Tegra к примеру так. Потому что Nvidia в отличии от Qualcomm не специализируется на GSM.

                                    В данный момент явно наблюдается тенденция к интеграции всего в один чип как раз, времена кучи отдельных проходят — хотя, конечно, такие решения еще остались.

                                    И еще долго останутся. Не всем надо внутри DSP для работы с GSM. Часто бывает проще скомпоновать CPU с DSP.

                                    Я бы не сказал что OMAP3 настолько распространен в телефонах. Ок, даташит есть — один нашли процессор.
                                    Общая суть все равно остается той же, доки на современные SoC высокой степени интеграции — большая редкость.

                                    Напомню вопрос стоял есть или нет. Так вот есть. И как раз товарищи из Mozilla хотят телефон на аппаратной базе с открытыми драйверами. Сейчас это возможно. О том что этот продукт не будет конкурентом флагманам рынка, так это и так понятно.
                                    • +1
                                      Хорошо, я не совсем верно изначально выразился — я не отрицаю, что на какие-то чипы найти можно.
                                      Я имел в виду, что на специализированные SoC — те у которых внутри есть Wi-Fi, либо Bluetooth, либо GSM модули — очень трудно, иногда невозможно, найти адекватные доки.
                                      Я с этим столкнулся, к примеру, для SoC, которые в Wi-Fi точках доступа, вроде линукс на них стартует, значит откуда-то драйверы Wi-Fi части, как минимум, нашлись, но общей документации нет. Встает вопрос — как тогда этот драйвер писали, не имея доков. Не верится как-то что реверсили исходную прошивку, хотя такое тоже возможно.

                                      Я боюсь, если товарищи из мозиллы не станут гнаться за флагманами, они проиграют, их попросту вытеснят с рынка, подавляющему большинству людей важнее соответствие параметров продукта параметрам флагманов, чем открытость и т.п…
                                      Кстати, был когда-то проект «опенхардварного телефона», любительский. Было бы неплохо если бы сделали что-то аналогичное, но не на дерьмовых китайских GSM модулях и т.п., а на нормальном железе. Но, я так понимаю, мозилла не ставит задачи всю хардварную составляющую открыть?
                                      • 0
                                        Я имел в виду, что на специализированные SoC — те у которых внутри есть Wi-Fi, либо
                                        Bluetooth, либо GSM модули — очень трудно, иногда невозможно, найти адекватные доки.

                                        Это может быть.

                                        Встает вопрос — как тогда этот драйвер писали, не имея доков. Не верится как-то что реверсили исходную прошивку, хотя такое тоже возможно.

                                        Когда как. Иногда реверсили иногда драйвер банально предоставлен производителем.

                                        Я боюсь, если товарищи из мозиллы не станут гнаться за флагманами, они проиграют, их попросту вытеснят с рынка,

                                        В данный момент у них нет столько денег чтобы тягаться с флагманами. Вон Microsoft все пытается впрыгнуть в поезд и у нее получается это довольно плохо. А если же начать с бюджетных моделей, их могут купить на поиграться. Опять же цели захватить рынок на 90% у ниг не стоит.

                                        Кстати, был когда-то проект «опенхардварного телефона», любительский. Было бы неплохо если бы сделали что-то аналогичное, но не на дерьмовых китайских GSM модулях и т.п., а на нормальном железе. Но, я так понимаю, мозилла не ставит задачи всю хардварную составляющую открыть?

                                        Скорее всего используют новый MTK от MediaTek который недавно вышел.
  • 0
    А можно будет писатт на Cappuchino? Чтобы obj-c style?
  • 0
    > В Бразилии налог на импорт
    > Apple строит там производственные мощности, чтобы это обойти
    > Firefox OS магическим образом отменит налог на импорт

    В общем, все хорошо до тех пор, пока автор не надел розовые очки и не начал описывать будущее ОСи
    • 0
      Телефоника выпускает телефоны прямо в Бразилии. Первый выпуск телефонов будет именно там в начале 2013 для v1. Дальше возможно пойдёт и ZTE.
      • 0
        Ну тогда будут пошлины в другую страну, какая разница? :)
        • 0
          Речь идёт о захвате низкого и среднего сегмента. В первую очередь это Бразилия и прилежащие. А если вы волнуетесь о России, то кхм… Разве кого то здесь останавливает айфонушка за 35к? Ну а если серьёзно, то например телефоны от Нокиа, нижнего сегмента, всегда были по приемлемой цене, значит и эти могут быть.
          • 0
            Ни о ком я не волнуюсь, не беспокойтесь :)

            Нижний сегмент достаточно активно захватывает Андроид, отбирая его у Симбиана, в первую очередь. Почему вдруг этот сегмент захватит FirefoxOS, непонятно
            • 0
              Симбиан, имхо, всё же средний сегмент. Нижний — это Series 40. Почему бы не уступить более современной ОС не понятно. Главная чтобы она на подобном железе работала. Плюс Firefox узнаваемый многими бренд, даже теми, кто не знает что такое ОС (большинство владельцев Series 40 в частности об этом и не подозревают).
  • +4
    >Для примера, в настоящее время я тестирую JavaScript игры на телефоне за 50 фунтов. От устройства по такой цене многого ожидать не стоит, но на самом деле эти игры не только работают быстрее, чем на таком же телефоне с Android запущенные в браузере (Firefox или Chrome), но и так же быстро, если не быстрее, чем на Android устройствах цена которых в 4-5 раз больше.

    Какое хитрое сравнение. С тем же жаваскриптом, но запущенным в андроидном браузере.
    Разумеется после этого можно прыгать и кричать о феноменальной скорости, но почему не сравнивают эти жаваскриптовые приложения с обычными приложениями андроида? (Я уж не говорю с нативными, хотя бы с явовскими...)
  • +3
    Я правильно понял, что для 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)
    • 0
      Ага, согласен со всем, включая грядущий геморрой разработчикам.
      Но, я думаю, в JS будут компилить, скорее всего. Из той же явы — есть же средства, порождающие JS-код из более удобных языков.
      • 0
        > Но, я думаю, в JS будут компилить, скорее всего.
        Сомневаюсь что в конце концов это будет работать эффективнее чем использование более-менее платформенно-оптимизированного промежуточного представления.
        • 0
          Я тоже сомневаюсь, я вообще во всей этой затее с Firefox OS сомневаюсь.
          Если бы они свой JS движок сделали кросс-платформенным (в аппаратном плане) и ставящимся на голое железо, тогда еще было бы что-то интересное (типа как гипервизоры, которые ставятся на железо сразу).
          А тут — все тот же линух внизу, плюс еще один слой из JS-интерпретатора… Хз.
          • +1
            Перейти на Dart предлагаемый Google и не мучаться :)
    • +3
      Очень много людей стараются переместить в JS все те приемы, методы, паттерны разработок, к которым они привыкли используя другие языки программирования. Результат всегда одинаковый: «JS отстой», «Разработка на JS сопровождается только попоболью», «JS-фигня».

      Опять же привожу свой опыт, в качестве примера. Мы отказались от ООП головного мозга, даже не пытаясь повторять опыт разработки системных приложений, возложив на JS работу сценариев и мелких утилит (unix-way). Блох вылавливаем очень редко.

      В названии самого языка содержится слово Script, что подразумевает сценарийный подход к разработке. По крайней мере мне 15 лет так казалось…
  • –11
    Писать на JS — это все равно, что в 21 веке писать на ассемблере.
    • +6
      Как-то странно сравнивать JavaScript с ассемблером
      • –3
        В чем странность?
    • 0
      Не в первый раз уже слышу такое сравнение)
      Собственно, поэтому и появились инструменты для генерации JS из Java и т.п.)
      • –1
        И я о том же. Есть же HaXe, к примеру, который отлично генерит JS, а язык на уровнь выше, чем AS3. Но народ упорно пишет на JS. Когда небо было голубее, то тоже было круто писать на ассемблере. Ну ничо, работа дураков любит :)
        • +2
          Ну вон люди и на Coffeescript пишут — только не популярно это. Яваскрипт не такой уж и сложный язык, он просто другой. А начиная писать на надстройке над языком вы можете столкнуться с проблемами, которые еще никто не решал и не факт что они будут решены.
          • 0
            Язык не сложный да, но посмотрите сколько к нему костылей уже прикручено, чтобы сделать из этого простого что-то удобно используемое.
            • +2
              На самом деле это зависит от точки зрения, я так думаю.

              Каков наиболее используемый (по числу зависимостей от него) модуль для Node.js по сведениям менеджера пакетов npm?

              Это Underscore.

              Можно ли Underscore назвать костылём?

              Underscore — это библиотека для обработки данных и функций с поддержкой цепного вызова (chaining).

              Если отсутствие такой библиотеки в самом языке следует считать хромотóю — тогда да, это костыль.

              Но я так не считаю, у меня другая точка зрения. Для меня Underscore — просто инструмент: он весьма удобен, но не всегда необходим мне. Мне доводилось сочинять джаваскрипты из десятков строк и ни разу не прибегнуть к Underscore.

              А костыли — это такие средства, без которых программирование невозможно или хотя бы мучительно.

              Тому примером jQuery: вот это и впрямь костыль. Но костыль не для языка JavaScript, а для довольно скверной системы DOM, имеющей чрезмерно длинные имена методов и свойств и притом не совершенно кросс-платформенной. Надобно быть захеристом-мазохистом, чтобы вместо $('#some') записывать document.getElementById('some') и наслаждаться.
              • –1
                function $(e){ return document.querySelector(e); }

                Наслаждайтесь.
          • –1
            Я немножко не в теме — Coffeescript это примерно то же, что Dart?
            • +1
              CoffeeScript — это такой язык с упрощённым синтаксисом, компилируемый в JavaScript.

              Вот его сайт.
              • 0
                Ну так Dart работает по тому же принципу. Ну так они не столько популярны в связи с тем, что люди привыкли к стандартной связке HTML+CSS+JS и тяжело относятся к
                а) статической типизации
                б) замене букв JS на что-то еще.
                • 0
                  Честно говоря, в кофескриптах нет никакой статической типизации.
                  • 0
                    Упс. Спалился — не успел посмотреть. Но суть, видимо, все-таки общая. С другой стороны ни у чего, что компилится в джаваскрипт не может быть настоящей статической типизации.
                    • +1
                      Статическая или динамическая типизация это свойство синтаксиса языка. Никто не мешает статическую или динамическую накручивать поверх другой.
  • 0
    Я вот не поленился и скачал себе эмулятор. Впечатление хорошие, но я бы так не расхваливал FOS. Да интересно, да забавно, да я веб-разработчик и смогу ковырять свою ось и мне не надо будет учить java или obj-c. Но это не приемущества на рынке. Им важно сделать так, что бы конкурировать с андройдом, а не с IOS, потому что весовая категория разная. Что бы набрать популярность им надо что бы FOS ставили на все говнопланшеты и недосмартфоны и оно не тормозило.
    • 0
      Автор говорит о заполнении пробела на рынке. Имеется в виду стремление заполнить продукцией ту часть рынка, в которой сейчас ничего нет, а это смартфоны по цене обычных телефонов для развивающихся стран.
  • +2
    Facebook: Мы окончательно решили, что делать приложения на html5 — было нашей ошибкой, поэтому мы будем делать native приложения!
    — Trollzilla: Мы выпускаем OS, которая полностью будет на JavaScript
    Facebook: D'oh!
    • 0
      Ну с другой стороны для fos у них уже почти готовое приложение) да и вообще, все компании с веб-клиентами практически имеют уже приложения для fos
      • +2
        С поддержкой работы в оффлайн, ага.
        С нормальной работой по медленному каналу, ага.

        Есть целая пропасть между веб-сайтом, работающем в браузере и веб-приложением с хорошим experience на мобильнике…
    • +2
      Все как-то забыли, что первый айфон вышел тоже только с веб-приложениями. Через год они выкатили полноценный SDK, потому что HTML5 пока что отстой
      • 0
        Это стоит воспринимать как Back to the primitive? Потому что полноценный SDK до сих пор существует и развивается, а от разработки под мобилки на HTML5 хорошего пока не слышно, значит «пока что» — до сих пор актуально:)

        И да простят меня адепты веба в данном топике, не холивара ради, но заметил интересную вещь:
        Если к 1му ипфону флеш на мобилках был отстой, и я согласен, так и было, то сейчас — стал на порядок лучше, флеш игры попадают в топы аппстора и всё такое, а разные компании наоборот, задумываются о переходе на него в разработке простых казуалок. Успехом назвать конечно рано, но прогресс чувствуется, что радует, ведь у его собрата (хе-хе) html5 дела, походу, обстоят хуже на этом рынке)
        • 0
          Ну, на мобилзках Flash умер и реинкарнировался в виде нативных приложений :)

          • 0
            они не совсем нативные
            это ж кросскомпиляция:)

            Кстати, а нет ли попыток сделать компилируемый js?
        • +1
          а разные компании наоборот, задумываются о переходе на него в разработке простых казуалок.

          Задумываться они начали, когда услышали, что Flash for Android больше не поддерживается?
          • 0
            когда-нибудь люди на этой планете научатся анализировать всё то г*вно, простите, что они читают, и не вестись на желтые заголовки.

            Flash player под Android — мёртворождённый, и я рад, что они приняли такое решение.

            НО(!) Flash — это не только player, есть ещё AIR, и он живее всех живых;)
            • 0
              Точно не живее. Поддержка Linux свёрнута.
              • 0
                о да, мертвее некуда, ведь всю целевую аудиторию потеряли:) без linux флешу однозначно смерть придёт)

                А вообще, имхо linux сообщество само себе яму роет в этом направлении, ну серьёзно. Если б FP не был б так гиморно разрабатывать в linux-окружении, то ничего бы не сворачивали:)
                • 0
                  >> без linux флешу однозначно смерть придёт)
                  Вот вы говорите, а я вот жду-не дождусь возможности гонять в production видео на WebRTC, и одна из причин — отсутствие возможности нормально разрабатывать флэш-приложения под Linux. Linux — потому что сервер-сайд на человеческом Erlang(erlyvideo). И я не один такой.
                  JS, конечно, то еще говно, но для него хотя бы отладчики вменяемые под Linux 64bit есть.

                  >> Если б FP не был б так гиморно разрабатывать в linux-окружении
                  Когда руки из нужного места растут, под Linux разрабатывать что бы то ни было удобнее, но это холиварно, согласен.
                  А если строить нормальные уровни абстракции, кроссплатформенность не настолько сложна, особенно для компании с такими конскими ценами на продукты, как у Adobe.
                  • 0
                    > кроссплатформенность не настолько сложна

                    только при условии таскать все зависимости с собой. потому что терпения на все дистрибутивы линукса не наберешься
                    • 0
                      Cкажем, NVidia справляется терпимо — блоб + открытая обвязка для него.
    • НЛО прилетело и опубликовало эту надпись здесь
  • –2
    А Firefox OS так же течет и жрет 2 гига памяти, как и Firefox Browser?
    • +3
      Я сейчас смотрю на Ваш комментарий из Firefox 16, занимающего 394 мегабайта по сведениям Диспетчера задач Windows.
      • 0
        Хотите сказать, браузер, занимающий 394 МБ оперативной памяти для мобильного устройства — это ерунда?
        • 0
          У меня на мобильнике HTC Desire стоит мобильная версия Файерфокса. Могу заверить, что она жрёт не сотни мегабайтов, потому что в HTC Desire всего-то 576 мегабайтов в целом, а у меня параллельно запущены Скайп и Твиттер.

          Правда, мобильный Файерфокс и не хранит в памяти структуры данных, необходимые для быстрой работы кнопки «назад», для изменения интерфейса при помощи XUL, для мгновенного отображения заблаговременно декодированных иллюстраций, и так далее.
  • 0
    Что скажет гугл, когда первое впечатление от оси:
    «Вы дали мне Android? Это очень похоже на Android»
  • 0
    Эх, затейка интересная, красивая, для веб-девелоперов сказка просто (я так же про webOS думал), но вот невероятно сомневаюсь я что это будет действительно шустро работать. Если только JS будет транслироваться в некий бинарный код… Или процы на уровне железа будут JS как то кушать… Или js будет оберткой для запуска каких нибудь сишных скомпиленных прог и либ… Или надо будет просто 16 ядерный смартфон с 32гб памяти, чтобы поиграть в GTA3 на JS телефоне. Ноg ока не будет реальных девайсов говорить о чем то конкретном рановато.
  • 0
    Поставлю себе такую на Xiaomi 2

    Или не смогу?
  • 0
    Конкуренция производителей двигает развитие технологий, но мне одному показалось что автор использует странные обороты речи похожие на НЛП?
    • 0
      А какие обороты речи? Процитируйте примеры.
  • 0
    Идея то уж не нова. Есть WebOS и Tizen (ну где то в заповедниках, куда и FirefoxOS отправится).
  • 0
    Chrome OS, Firefox OS. Следующая версия Windows будет называться Internet Explorer OS?
  • 0
    Если так хочется игр на JS лучше бы сделали игровую консоль с хорошим экраном, управлением и т.п. Слабо верится что обычные пользователи будут руками менять CSS или JS. Драйвера скорее всего так и остануться закрытыми, разве что Mozilla сама будет производить все устройства и делать их открытыми. Но т.к. платформа планируется быть открытой, то производителей возможно будет много, значить опять фрагментация и не совместимость. Так же не ясно что с безопасностью? Мне, например, безопасность моих данных важнее чем куча игр.
    • 0
      Драйвера закрыты, АПИ доступа железке(драйверам) открыт.
      Да обычный пользователь делать ничего не будет,
      но большое количество энтузиастов улучшателей — будут.
      А уровень вхождения в разработку для такого комплекса значительно ниже чем для того же андроида.
  • +4
    Идея использования виртуальной машины (движка в данном случае) в мобильной системе не лучшее решение изначально. Будет еще один андроид.
    Ничего не имею против, но при наличии выбора я выберу мобильную ОС без виртуальных машин и такого BDSM.
  • +2
    Хех, это только мне кажется странным, что они хотят платформу для low-end железа и при этом основывают ее на JS сравнивая результатами веб-приложений в других смартфонах? Если нужна хорошая производительность на слабом железы — зачем такие высокоуровневые инструменты и столько слоев абстракции? А если хотят удобную для разработки высокоуровневую платформу — то не стоит ожидать, что она будет летать на слабом железе. Я, например, не вижу технических причин, почему JS в Geko будет бежать быстрее, чем скажем Java в Андроидовском Дальвике или СLR-код в WP-шной .NET VM.
    • 0
      Насколько я понимаю, достоинством тут (объ)является возможность перенести именно веб-приложение в Firefox OS, мало что в приложении переписывая с нуля для достижения нативности.
      • 0
        Именно так. По сути, все что нужно сделать — добавить файл manifest.json в папку веб-приложения. Этот файл содержит некоторые данные о приложении.
  • 0
    30 раз в тексте сочетание «Firefox OS» :)
  • +2
    Я не против Firefox OS, но позвольте уточнить, почему это в принципе называется операционной системой, если оно по-прежнему грузит Linux? Разве в таком случае оно не является простым Desktop Environment по типу Xfce, Gnome или KDE, пусть и написанным на XUL и javascript поверх C++-ного движка Gecko?

    Выходит, что сейчас автором «инновационной операционной системы» может стать любой, кто в состоянии добавить новую строчку в inittab, а то и вовсе в .xinitrc. Чем же тогда занимаются те люди, которые пишут операционные системы, не являющиеся по факту Linux-приложениями?
    • +1
      То, что обычно называют Linux является ОС GNU/Linux, также популярен Android/Linux, теперь вот FirefoxOS/Linux. А просто Linux это ядро, полноценной ОС не являющееся.
      • 0
        > А просто Linux это ядро, полноценной ОС не являющееся.

        Тут все сложно. В спорах определение, что такое Linux является контекстно-зависимым. Это может быть Линукс, как сфероОСь (например, когда речь идет о вендекапце), а может быть как ядро. Из-за этого очень сложно вести споры с излишне преданными сторонниками Линукса.
      • 0
        Ну тогда MinGW, получается, тоже полноценная операционная система на базе ядра Windows, которая полноценной ОС не является?
        • 0
          Не могу судить, не сталкивался. Но ядро Windows полноценной ОС не является, у полноценной должны быть средства взаимодействия с пользователем.
  • +1
    А «Firefox OS» точно дальше смартфонов не пойдет? А то, я переживаю или радуюсь за свой холодильник,
    • 0
      Наоборот. И уже пошла дальше, в статье об этом упоминается. Почему бы и не холодильник :)
  • +2
    «Остановитесь на секунду и задумайтесь — это мобильная ОС созданная на JavaScript!»
    Остановился и задумался — писец! Нунах.
    • 0
      После небольшой паузы следует что-то вроде «Твою ж мать!»
      • 0
        Нет, не следует.
        Я достаточно давно отношусь с разумным скепсисом к такого рода прослойкам между софтом и железом. И с интересом замечаю как воодушевлённо молодёжь встречает всякие новинки в этой области до собственно их появления на рынке и как через год-другой появляются сообщения, что в общем-то вовсе это и не панацея, напрямую работает оказывается (ага, а то мы не догадывались) лучше и т.п.
  • +1
    >> Имея базовые навыки веб-разработки, вы можете полностью изменить всю ОС. Редактирование одной строки CSS может повлиять на способ расположения иконок или их форму, или же вы можете изменить JS, который обрабатывает телефонные звонки.

    И появится Bolgen Mobile OS… :D
  • +3
    Автор с радостью ответит на все вопросы о Firefox OS. Желательно писать по существу.
    • 0
      Насколько совместимы файлы для портирования из device// с теми, что предназначены для CyanogenMod?
    • 0
      А как насчёт поддержки планшетов?
      • 0
        Для v1 планируется только поддержка телефонов.
      • 0
        В статье автор упомянул о том, что ОС уже портирована на ряд других, не мобильных, устройств. Так что, я думаю, планшеты не есть проблема.
    • 0
      Как автор видит будущее Firefox OS, если говорить о ней, как об игровой платформе?
    • 0
      Как насчёт расхода батареи? Понятно, что телефон тестовый и они могут быть с различной емкостью аккумов, и много чего он еще не умеет (звонить? Wi-Fi?), но тем не менее хотелось бы узнать промежуточные результаты.
      • 0
        Звонить и Wi-Fi умеет кстати. Как писал Крокфорд — мой первый смс спам на b2g :)
        • 0
          Тем более… :)
      • 0
        Здесь изображение наглядно показывающее все Device Access API, уже действующее и находящиеся в разработке — arewemobileyet.com
    • +1
      Вопрос-бесплатная-идея-фичи:
      Для Дрюши есть замечательное приложение — AirDroid. Для тех кто не в курсе, приложение представляет собой небольшой web-сервер и позволяет управлять телефоном через браузер компьютера, что очень удобно. Я, к примеру, чаще всего, использую его для написания смс-ок, т.к. на большой клавиатуре это гораздо удобнее.
      А тут у нас целая ОС в браузере. Возможна ли, и планируется ли подобная функциональность?
      Возможно это стало бы неплохой фичей из коробки. Небольшой web-сервер для телефона + набор js «библиотек», реализующий некое подобие удаленного вызова процедур для специфичного API.
      Думаю, достаточно удобно использовать для написания смс сообщений, разбора различных файлов на устройстве,

      Интеграция с настольной Firefox?
      • 0
        Кстати поддержу, было бы очень здорово. Плюс, имеем встроенную защиту от кражи. Возможность скинуть, например, файлы на телефон или из него без подключения к компу. И очень много других плюсов.
    • 0
      Как насчет работы с двумя сим-картами?
  • +2
    Вроде бы вопрос уже поднимался в комментариях, но чем FireFox OS будет лучше webOS? Тем более, что webOS сейчас тоже выпускают в виде продукта с открытым исходным кодом. А если точнее, то не получиться ли из FireFox OS система со всеми проблемами webOS, но только основанная на «более тяжеловесном» движке Gecko вместо WebKit?

    Насколько я помню, первые версии webOS были далеко не полностью основаны на веб-технологиях — там внутри системы оставалось достаточно много частей на Java, по большей части из-за того, что проект поменял направление в процессе разработки. Когда же в следующих версиях webOS «очистили от Java» и полностью перевели на веб-технологии, то оказалось, что она стала еще более требовательной к железу, из-за чего существующие ранее устройства не могли нормально потянуть эту новую версию и, соответственно, не получили обновление до нее. Столкнувшись с этим, разработчики обратно потянули в систему не-веб-технологии.

    Устройства у Palm и HP никогда не были особыми монстрами в плане железа и производительности, но и low-end девайсами их назвать было нельзя. Т.е. насколько вообще актуально пытаться сделать платформу для доступных и слабых устройств на веб-технологиях?
  • 0
    Был уже и есть ChromeOS/Chromium OS.
    Вроде все тоже самое, что описано возможно. Живет и здравствует.
    Разве что предназначение не для смартфонов.
    Иконки красивые, согласен, но дизайн опять такой же как у остальных (не Win8) мобильных платформ.
    Впрочем, еще одна линуксоподобная OS для привлечения внимания к Linux, кто против?.. Я, нет.
    • 0
      Еслиб гугл продвигал Chrome OS для мобильных устройств, а не Android, тогда да, можно было бы сравнивать и тогда, не было бы надобности в проекте от Mozilla. Но гугл просто делает деньги :)
  • 0
    Кто нибудь поставил?
    • 0
      На телефон нет, не хочется убивать Андроид, так как куча настроек и так далее. На десктоп ставил и приложение писал даже.
  • 0
    Если дела будут поставлены так же как разработка расширений для лисы, не завидую я разработчикам под эту ось.
  • –1
    Глупая затея, не взлетит. Рынок смартфонов поделен в пользу андроидов и айфонов, плюс какие-то попытки мелкософта залезть. Время webOS, Chrome OS и подобных еще не пришло. Мобильные процессоры всё еще слабенькие, не тянут такой «высокий уровень». Впрочем, баксы печатают, девать же их куда-то нужно, отчего бы и не взять и не пилить какую-нибудь очередную вебось, если фантазии на большее не хватает :)
  • –1
    Кстати, по поводу жалоб на фпс в играх на html5 под мобилки, проблема лишь в том, что гуглу/яблоку не интересно оптимизировать данное направление, хотят видимо нативное рабство :) Впрочем, проблема решаема, люди пилят вот такое dev.appmobi.com/index.php?q=content/directcanvas-accelerates-html5-game-performance
    • 0
      Интересно. На сколько я понял, directCanvas отбрасывает все ненужные для работы игр функции оставляя только прорисовку на canvas. Логичный ход.
  • +7
    НЯ!
    Эта статья полна любви и обожания.
    Возможно, стоит добавить ещё больше?
  • 0
    По скринам очень похоже на Андроид. Автор сильно увлечен проектом. Посмотрим что получиться из этого.
    • +1
      Автор любит свою работу, автор любит Web и автор естественно радуется этому прогрессу, как и все остальные работники Mozilla.
  • 0
    ос для разработчиков — не для пользователей

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.