Шесть гигантов мобильной и телекомуникационной индустрии - Motorola, NEC, NTT DoCoMo, Panasonic, Samsung и Vodafone, основали (http://www.linuxdevices.com/news/NS2923387573.html) некоммерческую организацию LiMo Foundation (http://www.limofoundation.org/), целью которой является координирование создания новой программной платформы для мобильных устройств построенной на базе Linux.
В качестве базиса для создания интерфейса пользователя выбрана библиотека GTK+. Наработки проекта будут представлены в исходных текстах, с использованием лиценции GPL, API же будет лицензировано под лицензией "Foundation Public License" (FPL), откорректированной GPL в плане использования запатентованных технологий.
Параллельно развиваются альтернативные проекты по созданию или стандартизации мобильной Linux платформы:
- Trolltech Greensuite (http://www.trolltech.com/products/qtopia/phone_edition/green...
- Access Linux Platform (http://en.wikipedia.org/wiki/Access_Linux_Platform) (ALP) и Hiker Application Framework (HAF);
- The Linux Foundation Mobile Linux Initiative (http://en.wikipedia.org/wiki/Embedded_Linux#Open_Source_Deve...
- The Linux Phone Standards Forum (http://en.wikipedia.org/wiki/Linux_Phone_Standards_Forum) (LiPS).
В заключение, приведу несколько ссылок на обзоры планшетного ПК Nokia N800, как лавина свалившихся после начала продаж данного устройства:- "Выпущен (http://www.notacloud.com/blog/?p=26) предварительный вариант "OS 2007/770 Hacker Edition (http://os2007on770.garage.maemo.org/)" - редакции OS 2007 от N800 для устройств N770. Дополнительные подробности здесь (https://garage.maemo.org/projects/os2007on770/) и здесь (http://thoughtfix.blogspot.com/2007/01/770-future-and-forbid....
- "The Nokia N800 (http://cs.gmu.edu/~sean/stuff/n800/)" - отличное сравнение N800 с Apple Newton;
- Обзоры от журналов и авторитетных изданий:- "cnet.com: Nokia N800 Internet Tablet (http://reviews.cnet.com/Nokia_N800_Internet_Tablet/4505-3126...
- "computerworld.com Review: Nokia N800 Internet Tablet is fascinating but incomplete (http://www.computerworld.com/action/article.do?command=viewA...
- "osnews.com Review: The Nokia N800 Internet Tablet (http://www.osnews.com/story.php?news_id=17052)";
- "PC Pro: First look: Nokia's iPhone Killer? (http://www.pcpro.co.uk/news/103044/first-look-nokias-iphone-...
- Небольшие обзоры и заметки в блогах:
- "Nokia N800 Review; A Real World Analysis After One Month’s Use (http://mobilecrunch.com/2007/01/18/nokia-n800-a-real-world-r...
- "Nokia N800 Internet Tablet First Thoughts Review (http://www.brighthand.com/default.asp?newsID=12725)";
- "Nokia N800 Review: First Impressions of Nokia's Latest Internet Tablet (http://forums.mobileburn.com/showthread.php?t=20294)";
- "Nokia N800 Review (http://thoughtfix.blogspot.com/2007/01/nokia-n800-review.htm...
- "Nokia N800 - My Review (http://www.hanno.de/blog/2007/01/24/nokia-n800-my-review/)&q...URL: http://www.linuxdevices.com/news/NS2923387573.html
Новость: http://www.opennet.me/opennews/art.shtml?num=9638
Strannoe zhelanie zasunut' linux v kazhduju kofevarku.
лучше netbsd? 8)
FYI: NetBSD поедет не на всяком железе, на котором ездит линукс.Со стороны производителей труб и поставщиков услуг (крупные в трубное дело тоже всё равно вмешаны) это не странное, а вполне закономерное желание не допустить того, что произошло с их коллегами на рынке ПК. Вот и играют на опережение.
Ещё пара ссылок по теме -- здесь: http://www.linux.kiev.ua/ru/news/comments/view/2542/
>лучше netbsd? 8)
Чем лучше?Тем что производители засунут ваш же код в свои железки и не дадут вам адаптированные сорцы? oO
Клева, вот вы и занимайтесь развитием такой системы.А меня не прет если мой код засунут в девайс так что потом я даже не смогу получить его адаптированную версию и что-то там поменять.
блять, ну когда же фанаты научатся сначала читать а потом писать?
"Наработки проекта будут представлены в исходных текстах, с использованием лиценции GPL,"
>блять, ну когда же фанаты научатся сначала читать а потом писать?
>"Наработки проекта будут представлены в исходных текстах, с использованием лиценции GPL,"
Не тормози, я это про *BSD с их тупой лицензией по которой любому можно спи..ть код, засунуть его в свой девайс и ни с кем им потом не делиться.Итого вы пашете а сливки снимают другие - весьма классная лицензия у *BSD-унов... в редмонде бы радовались если б оно развилось - типа вы пашете а мы сливки снимаем, все по их мнению было бы честно 8)
вот сам и не тормози - там смайлик был!
а holy wars достали уже!!! Не нравится лицензия или не понимаешь её смысл - просто не используй её. Это очень просто. А своё дремучее мнение держи при себе, ну или пиши "ИМХО" (это тоже несложно).
>Не тормози, я это про *BSD с их тупой лицензией...
вот видишь, не всем догадываются про твои смайлы :) а ведь дети могут принять за чистую монету и использовать как аргумент в очередном споре. так и создаются мифы. древней греции :)
Интересно, почему тупой GTK, а не продвинутый Qt?
>Интересно, почему тупой GTK, а не продвинутый Qt?
Единственное pro, которое нашёл -- платформа на Qtopia уже есть и там вполне коммерческие интересы троллей рядом (телефонная часть за деньги). Интересно, что Nokia -- в эту организацию из линуксовых мобильщиков по сути только она не вошла, при этом N770/800 -- гномячьи.
Есть мнение, что тогда сторонние разработчики под этот мобильник либо смогут писать только опенсорц, либо надо будет платить за Qt. А так да, жалко. GTK отвратен как с точки зрения пользователя, так и разработчика.
>GTK отвратен как с точки зрения пользователя, так и разработчика.Не надо заливать. Да, с точки зрения девелопера(ну или хотя бы с моей точки зрения) это пипец. Но вот look and feel меня более чем устраивают. Пользуюсь gqview, gajim, gimp, отвращения от gtk не испытываю.
> Да, с точки зрения девелопера(ну или хотя бы с моей точки зрения) это пипец.GTK+ - великолепная графическая библиотека, чтобы понять и начать писать на gtk нужен максимум день и никаких подводных камней.
То, что QT лучше GTK+ - миф. Их нельзя даже сравнивать, разные вещи.
QT - с++ операционная система.
GTK+ - компактная и простая gui библиотека для c, c++, python, perl, ruby, php и многих других языков...
PHP тоже многие считают великолепным и простым языком. В результате под него существуют очень большое количество кривых поделий. Тоже самое справедливо и для GTK+. QT же ближе к java. В результате если брать среднее качество приложений на QT и на GTK то шансов встретить хорошее приложение на QT гараздо выше чем на Gtk+.
Так-же как и на Java, на QT полно перегруженных монстров, типа kde&co.GTK+ это прежде всего C.
>Так-же как и на Java, на QT полно перегруженных монстров, типа kde&co.
>GTK+ это прежде всего C.
...и C менее ресурсожорок чем С++ что для таких девайсов один из решающих критериев.Меньше молотить процессором - отзывчивее интерфейс, меньше хавается батарейка, etc.Сименс с его кульным концептом ака меню на Java пролетел как фанера над парижем.Потому что тормоза бесят юзеров а на высокие концепции программинга на жабе им насрать :)
>...и C менее ресурсожорок чем С++ что для таких девайсов один из
>решающих критериев.Меньше молотить процессором - отзывчивее интерфейс, меньше хавается батарейка, etc.
Бред сивой кобылы. Ресурсожрание к языку имеет крайне слабое отношение.>Сименс с его кульным концептом ака меню на Java пролетел как фанера
>над парижем.Потому что тормоза бесят юзеров а на высокие концепции программинга
>на жабе им насрать :)
А java работает в vm. В результате получаются более высокие накладные расходы.
>Бред сивой кобылы. Ресурсожрание к языку имеет крайне слабое отношение.
Но си++ код обычно жирнее и тормознее сишного, тянет за собой больше библиотек... много лишних сущностей которые не всегда нужны.Можете сколько влезет считать это бредом но статистика штука упрямая.>А java работает в vm. В результате получаются более высокие накладные расходы.
Угу.Конечно с с++ такого ужоса как с жабой не получается, но см.выше.
>Но си++ код обычно жирнее и тормознее сишного, тянет за собой больше
>библиотек... много лишних сущностей которые не всегда нужны.Можете сколько влезет считать
>это бредом но статистика штука упрямая.
во-первых, использовать stl никто ни кого не заставляет. а во-вторых, затраты времени на написание/отладку кода в процедурном языке растут экспоненциально с ростом проекта. обьектность - попытка свести рост сложности к линейному. видимо, вы просто не пишите больших программ
>>Бред сивой кобылы. Ресурсожрание к языку имеет крайне слабое отношение.
>Но си++ код обычно жирнее и тормознее сишного, тянет за собой больше
>библиотек... много лишних сущностей которые не всегда нужны.Можете сколько влезет считать
>это бредом но статистика штука упрямая.
Ссылку в студию!
>Но си++ код обычно жирнее и тормознее сишного, тянет за собой больше
>библиотек... много лишних сущностей которые не всегда нужны.Можете сколько влезет считать
>это бредом но статистика штука упрямая.
Еще раз повторяю. БРЕД СИВОЙ КОБЫЛЫ. На больших проектах можно получить вообще прямо противоположную ситуацию.>Угу.Конечно с с++ такого ужоса как с жабой не получается, но см.выше.
Ага шесть раз! :)
Что это за бредятина? Таже не буду просить привести точные цифры, поэтому что это бред. Нет никакой критической разницы по потреблению памяти и требованиям к процессору ни в C++ vs C, ни в Qt vs GTK. Ладно, можно быть настолько тупым, чтобы про Qt судить по KDE. Но про ресурсоемкость C vs. C++, которая еще и решающий критерий - это, извините, п%%ец.
>Так-же как и на Java, на QT полно перегруженных монстров, типа kde&co.
Как среда мне KDE нравится больше чем Gnome.>GTK+ это прежде всего C.
Любой большой проект желательно писать с использованием ООП. Что получается в противном случае мы видим на примере Gnome.
GTK - это объектно-ориентированная библиотека. Только в отличие от QT, с ней можно работать и без использования объектно-ориентированных языков.
Жжоте! В каком месте она обьектно-ориентированая? Учитывая что она написана на C? А? Где там полиморфизм? Завязывайте уже траву курить.
>Жжоте! В каком месте она обьектно-ориентированая? Учитывая что она написана на C?
>А? Где там полиморфизм? Завязывайте уже траву курить.Вы глубоко заблуждаетесь, если считаете что Объектно Ориентированное Программирование возможно только на языке непосредственно поддерживающим данную идиому.
GTK+ - является объектно-ориентированной библиотекой с наследованием и полиморфизмом, достигая этого только средствами языка C.
К примеру, полиморфизм поведения на C достигается через указатели на функции.
>Вы глубоко заблуждаетесь, если считаете что Объектно Ориентированное Программирование >возможно только на языке непосредственно поддерживающим данную идиому.
Ага а безногий тоже может использовать костыли для ходьбы. Но это не значит, что он сможет бегать.>GTK+ - является объектно-ориентированной библиотекой с наследованием и полиморфизмом, >достигая этого только средствами языка C.
Она не является объектной. Да можно реализовать подобие ООП в C. Но оно будет работать заметно хуже чем ООП в C++ и не будет реализовывать это так же быстро как в C++.>К примеру, полиморфизм поведения на C достигается через указатели на функции.
5 баллов! А деструкторы и конструкторы? А абстрактные функции и наследование ? ;) Я еще могу много примеров привести. Результатом эмуляции объектного подхода на процедурном языке будет только увеличение громоздкости кода и его усложнение. То что в любом ООП языке делается легко и не принужденно, в такой модели будет делаться через одно место.
>оно будет работать заметно хуже чем ООП в C++ и не
>будет реализовывать это так же быстро как в C++.
Хуже? Интересно в каких это попугаях будет измеряться эта "хужесть".
И насчёт "быстро" я весьма весьма сомневаюсь ;)>>К примеру, полиморфизм поведения на C достигается через указатели на функции.
>5 баллов! А деструкторы и конструкторы? А абстрактные функции и наследование ?
Это тоже фукнции и указатели на функции ;) С наследованием похуже, придётся структуру начанать с другой структуры. Зато из синтаксиса будет понятно что это за переменная и откуда она взялась в иерархии наследований - т.е. повышать читаемость кода.>;) Я еще могу много примеров привести. Результатом эмуляции объектного подхода
>на процедурном языке будет только увеличение громоздкости кода и его усложнение.
>То что в любом ООП языке делается легко и не принужденно,
>в такой модели будет делаться через одно место.Да, несколько угромоздиться. Зато если я увижу a=b+c, я не буду думать а что это происходит на самом деле, не скрывается ли за этим какой то operator+. Читаемость кода без ООП намного лучше - код сам себя описывает.
Да и время компиляции C куда поменьше чем C++.
Так что молиться на ООП, как на спасителя, не стоит. Ибо часто кол-во сущностей преумножается сверх необходимого.
>>То что в любом ООП языке делается легко и не принужденно,
>>в такой модели будет делаться через одно место.
>Да, несколько угромоздиться. Зато если я увижу a=b+c, я не буду думать
>а что это происходит на самом деле, не скрывается ли за
>этим какой то operator+. Читаемость кода без ООП намного лучше
>- код сам себя описывает.
Не могу согласиться. Предложенный случай -- вырожденный, когда операция тривиальна, а автор текста подразумевается злоумышленный или повреждённый головой.С другой стороны, о "читабельности кода" на C++ и Java могу только похихикать после Ruby. Но это другой вид спорта, хотя в качестве точки для превращения экстраполяции в интерполяцию в обсуждении читабельности ООП/plain кода -- очень даже.
>Не могу согласиться. Предложенный случай -- вырожденный, когда операция тривиальна, а
>автор текста подразумевается злоумышленный или повреждённый головой.
А учитывая что если выше по тексту кода указано что a, b и с объекты, то что это не оператор может не догадаться только человек имеющий смутное представление о ООП.
>Хуже? Интересно в каких это попугаях будет измеряться эта "хужесть".
>И насчёт "быстро" я весьма весьма сомневаюсь ;)
Хужесть будет измерятся в том как это реализовано.>Это тоже фукнции и указатели на функции ;) С наследованием похуже, придётся
>структуру начанать с другой структуры. Зато из синтаксиса будет понятно что
>это за переменная и откуда она взялась в иерархии наследований -
>т.е. повышать читаемость кода.
Бред. Вы что никогда не программировали на С++? Может объясните мне идиоту как вы будете вызывать из функции потомка функции предка ? :)>Да, несколько угромоздиться.
Скажем не несколько, а очень сильно.>Зато если я увижу a=b+c, я не буду думать
>а что это происходит на самом деле, не скрывается ли за
>этим какой то operator+. Читаемость кода без ООП намного лучше
>- код сам себя описывает.
Очередной бред. a, b и с объявляются выше. Если это объекты то соответсвенно + это оператор. И никак иначе.>Да и время компиляции C куда поменьше чем C++.
За счет ваших костылей, оно сильно меньше не будет.>Так что молиться на ООП, как на спасителя, не стоит. Ибо часто
>кол-во сущностей преумножается сверх необходимого.ООП это единственная парадигма которая позволяет наиболее естественным образом хорошо реализовывать большие и сложные проекты. На процедурном языке реализовывать тоже самое будет на порядок сложнее.
>ООП это единственная парадигма которая позволяет наиболее естественным образом хорошо реализовывать большие
>и сложные проекты. На процедурном языке реализовывать тоже самое будет на
>порядок сложнее.
Про функциональные часом не слышали? Коллеги тут весьма нетривиальные вещи воротили, от моделирования поведения подушек безопасности до веб-проектов (где постепенно сползли уж не помню с чего тоже на лисп).Самому сейчас тоже доводится царапать помаленьку на схеме, так после годов императивщины спасает, наверное, только двухтомник по лиспу в пятом классе и тот же руби под конец меня как разработчика ;)
>Про функциональные часом не слышали? Коллеги тут весьма нетривиальные вещи воротили, от >моделирования поведения подушек безопасности до веб-проектов (где постепенно сползли уж не >помню с чего тоже на лисп).Слышал. Для определенных вещей может быть удобнее и круче других. Я понимаю что на чем угодно можно сделать что угодно. Только вот вопрос состоит только в том какие усилия прийдется приложить для реализации этого.
>а во-вторых, затраты времени
>на написание/отладку кода в процедурном языке растут экспоненциально с ростом проекта.
>обьектность - попытка свести рост сложности к линейному.
>видимо, вы просто не пишите больших программ
>Любой большой проект желательно писать с использованием ООП. Что получается в противном
>случае мы видим на примере Gnome.
Когда-то Вирт поколебал обоснованность подобных высказываний ;-) Ничего не имею против объектно-ориентированного программирования в общем и С++ в частности. :-)
>Когда-то Вирт поколебал обоснованность подобных высказываний ;-)
да, и студентов до сих пор учат во многих вузах на Паскале. бугугага
>PHP тоже многие считают великолепным и простым языком. В результате под него
>существуют очень большое количество кривых поделий. Тоже самое справедливо и для
>GTK+. QT же ближе к java. В результате если брать среднее
>качество приложений на QT и на GTK то шансов встретить хорошее
>приложение на QT гараздо выше чем на Gtk+.А знаешь почему? Потому что кол-во кривых поделий на Java, коих скорее всего столько же, сколько на PHP, просто являются недоделаными проектами так и не увидевших свет из за времени разработки, цены разработчиков, сложности разработки.
Hint: в мире программирования время разрабоки является очень важным фактором. Если делается сайт представляющий определённые услуги, то тот кто первый его сделает тот и подомнёт под себя рынок. Пример: Windows, Java, ICQ.
>А знаешь почему? Потому что кол-во кривых поделий на Java, коих скорее всего столько же, >сколько на PHP, просто являются недоделаными проектами так и не увидевших свет из за >времени разработки, цены разработчиков, сложности разработки.
Неверное высказывание. Java имеет более высокий уровень вхождения и используемая модель навязывает делать в ее рамках. В результате имеем более прямые реализации.
>Неверное высказывание. Java имеет более высокий уровень вхождения и используемая модель навязывает
>делать в ее рамках. В результате имеем более прямые реализации.
J2EE, в свою очередь, навязывает парадигму "навалимся в 50 человек, которых натаскивали пару лет хотя бы"... (цифры условные, но рядом тут так и напоролись с не очень большим проектом, который решили перетащить на EE)В этом есть разные стороны.
>>Неверное высказывание. Java имеет более высокий уровень вхождения и используемая модель навязывает
>>делать в ее рамках. В результате имеем более прямые реализации.
>J2EE, в свою очередь, навязывает парадигму "навалимся в 50 человек, которых натаскивали
>пару лет хотя бы"... (цифры условные, но рядом тут так и
>напоролись с не очень большим проектом, который решили перетащить на EE)
>
>
>В этом есть разные стороны.Это позволяет этой команде в 50 человек реализовывать в достаточно малые сроки, то что на другой платформе потребует гараздо большего времени. Не забываем это промышленная платформа.
>>В этом есть разные стороны.
>Это позволяет этой команде в 50 человек реализовывать в достаточно малые сроки,
>то что на другой платформе потребует гараздо большего времени. Не забываем
>это промышленная платформа.
Так я ж и не спорю ("разные стороны"). Просто для огородных работ такой шагающий экскаватор дороговато получается, а на своей площадке требует приличных initial setup costs. Что ни разу не откровение.
>Так я ж и не спорю ("разные стороны"). Просто для огородных
>работ такой шагающий экскаватор дороговато получается, а на своей площадке требует
>приличных initial setup costs. Что ни разу не откровение.
Только до тех пор когда китайцев капающих огороды не пригоняют выполнять работу шагающего экскаватора.
Компактная? Сравни размеры дистибутивов, не забудь что GTK еще нужен GLIB и прочее дерьмо, а потом вспомни что умеет Qt, и что умеет GTK. `Компактная и простая' my ass.
>Интересно, почему тупой GTK, а не продвинутый Qt?
Элементарно, Ватсон.Потому что для продвинутостей в таких девайсах ресурсов как-бы не дофига и потому не до наворотов...
FPL как и патенты на софт в целом должны умереть!
Авось вот этот проект http://openmoko.org/ поможет им окочуриться побыстрее.
>FPL как и патенты на софт в целом должны умереть!
>Авось вот этот проект http://openmoko.org/ поможет им окочуриться побыстрее.
Эй, гики:)Лучше вот этих поддерживаем - эти думают не о наживе а о юзере, в отличие от :).Сами выбирайте в каком мире вы хотите жить, в мире реально открытых решений для людей или в полуоткрытом мире где правят мегакорпорации которые может даже и прогнувшись поюзают линукс но не забудут сунуть туда secure boot, DеRьMо и прочая чтобы держать вас подальше от прямого доступа к железу, "а то вы можете [в теории] завалить оператору сеть" (т.е. операторы признаются что их сети халтура и сделаны на соплях?)
по лицензии QT нужно для коммерческих проектов покупать столько лицензий, сколько разработчиков в проекте, что для больших разработок просто неоправдано -- куча программеров к гуи никакого отношения не имеют.
Ну во первых QT придумано не только для разработок GUI.А во вторых что-то мне даже не верится что QT нужно покупать больше лицензий чем количество программистов его использующих.
мне вот интересно мнение гуру GUI... почему не fltk?
только не отвечайте общими фразами, типа "Qt может все, fltk - ничего".
насколько я могу судить, fltk - наикомпактнейшая и самая портируемая библиотека, освоить ее - дело нескольких часов, полный контроль за событиями, не заставляет иметь предопределенную структуру приложения... или соображения чисто политического характера?
>мне вот интересно мнение гуру GUI... почему не fltk?
Не-майнстрим? (кажется, когда-то там были ещё грабли то ли с размерами или упаковкой виджетов, то ли с шириной под переводы... впрочем, могу путать с xforms, где их точно было)PS: только я ни разу не гуй-гуру :) "с точки зрения обыкновенного ползователя(TM)"
> Не-майнстрим?
может быть...
я вот хочу использовать fltk в нескольких проектах. был бы признателен за причину, по которой следует отказаться :) хотя, по-моему там настолько все просто и мало, что должно было быть все десять раз отлажено за годы существования
>> Не-майнстрим?
>может быть...
>я вот хочу использовать fltk в нескольких проектах. был бы признателен за
>причину, по которой следует отказаться :) хотя, по-моему там настолько все
>просто и мало, что должно было быть все десять раз отлажено
>за годы существованияНе советую. В FLTK нету понятия DeviceContext. В итоге, если будете писать собственные виджеты, то Вам придется "рисовать" их и под X Window, и под Win32. Я уже молчу по вывод на печать, ее тоже придется отдельно программировать.
Сам сидел на FTLK, но лет 5 как уже перешел на fox-toolkit.org и ни капли не жалею.
Размер конечно побольше чем FLTK, но архитектура на порядок лучше.
Написана на настоящем объектноориентированном языке, что большое преимущество по сравнению с "объектной" Gtk. Да и с политикой там всё в порядке - LGPL. Существует даже DE на расширенной FLTK http://ede.sourceforge.net/
На мой взгляд, один недостаток: приложения не будут иметь нативный внешний вид ни в Гноме, ни в КДЕ, или это решаемо?PS Не гуру в GUI
>Написана на настоящем объектноориентированном языке, что большое преимущество по сравнению с "объектной"
>Gtk. Да и с политикой там всё в порядке - LGPL.
>Существует даже DE на расширенной FLTK http://ede.sourceforge.net/
здорово. а UTF8 поддерживается? для меня это, наверное единственный вопрос остался
2<Dvorkin> а почему не www.fox-toolkit.org ?
>2<Dvorkin> а почему не www.fox-toolkit.org ?
интересная штучка. в закладки! :)
Неужто мы их дожали?Теперь это вот так... http://www.nokia.ru/phones/models/n800
P.S. не ослабляйте нажим, пинайте нокию посильнее - успех надо закрепить и развить.Активно допекаем нокию о моменте начала продаж :).После чего набегаем толпой и закупаемся, наконец то не только нудный виндовс мобиле будет на рынке :)