Релиз X Server 1.5.0 / X.Org 7.4, вновь перенесен (http://www.phoronix.com/scan.php?page=article&item=xorg_74&n...) и теперь ожидается в течение мая, что в свою очередь блокирует выпуск Linux дистрибутива Fedora 9, основанного на X.Org 7.4 (http://xorg.freedesktop.org/wiki/Releases/7.4) и отложенного ранее до 13 мая (http://fedoraproject.org/wiki/Releases/9/Schedule) (релиз X.Org 7.4 планировалось выпустить в марте, а потом в конце апреля).В настоящее время не устраненными остаются около 40 блокирующих релиз ошибок, что может привести к дальнейшей череде переносов релиза на июнь или даже на июль.
К сожалению, релиз не только запаздывает более чем на два месяца, но и будет содержать существенно меньше новшеств, чем планировалось ранее. Так поддержка Multi-Pointer X (MPX), XGE (X Generic Events), XKB 2, Glucose (новая архитектура акселерации основанная на OpenGL) и RandR 1.3 будет реализована только в X.Org 7.5.
В X.Org 7.4 ожидается:
- Переработанные (работа через инфрастр...URL: http://www.phoronix.com/scan.php?page=article&item=xorg_74&n...
Новость: http://www.opennet.me/opennews/art.shtml?num=15712
Ой, та кто бы боялся. Кому надо - федору 9 пре уже поставили (к примеру, я из-под нее пишу).В общем, понимаем, любим, ждем чего-то более стабильного в виде релиза, а не убунтовское "лишь бы выпустить вовремя".
>>В общем, понимаем, любим, ждем чего-то более стабильного в виде релиза, а не убунтовское "лишь бы выпустить вовремя".Что ж вы злые такие...
>Что ж вы злые такие...Нет нет. Это не плохо, просто разные политики и каждому свое, вот и все.
Убунту любим не меньше остальных :-)
лепота, а не диалог.
все бы так.
>Поддержка DRI2 Direct Rendering, пока только для карт Intel;они бы DRI1 нормально к этим картам вначале прикрутили.
а еще что-то можете? :-))) скажи какие функции вызываются:
namespace Func1 { struct A; struct B; void func1(int); void func2(A); }
namespace Func2 { void func1(int i) { func1(i); } func2(Func1::A x) { func2(x); } void z(Func1::B y) {z(y); } }
только писать из под федоры, могу и юзать :-)))))))
никаких. это лишь декларация
хорош выпендриваться
Типы части функций и аргументов пропущены. Фэйл.
Учись дальше, ученый.
он все правильно написал тут задача про то какая функция вызовется, а не про аргументы и типы,,,, - это про то какая функция будет скрыта, а какая функция будет в области видимости,,,,,,,
А на синтаксические правила можно положить, так?
А почему сказали "отложен на неопределенный срок"?, когда прочитал подумал xorg=dead.
>А почему сказали "отложен на неопределенный срок"?, когда прочитал подумал xorg=dead.точно, такая же реакция была на новость
>А почему сказали "отложен на неопределенный срок"?, когда прочитал подумал xorg=dead.потому что в процессе фикса 40 критических багов вылезут больше сотки некритических-не ходи к гадалке )))
Я считаю X.Org устаревшей системой. Зачем писать на C? Зачем X.Org перешел на autotools, когда другие проекты перестают их использовать (например, kde)? Почему нельзу было использовать cmake? В одной статье читала, что протокол X11 может быть ужат. Получается, что из-за этого X11 протокола теряется производительность. Не проще ли перейти на более современную оконную систему, например Qtopia Core? Конечно в этом случае нельзя будет запускать X11-приложения, но может Qt-приложений достаточно?
> Зачем писать на C.Скорость.
>Зачем X.Org перешел на autotools
Думаешь до этого было легче.
>Почему нельзу было использовать cmake
Ну нелзу, зачит нелзу...
>X11 может быть ужат
Может!
> из-за этого X11 протокола теряется производительность.Нет!
>Не проще ли перейти на более современную оконную системуНет, QT принадлежит Nokia.
>Нет, QT принадлежит Nokia.Хреновый аргумент, раньше Qt принадлежал Trolltech... и? Одна фирма, другая фирма... их же не microsoft купил.
> принадлежал Trolltech...По этому и не используем :)
Лицензия GPL , а для таких целей нужна LGPL или "эквивалент". Тогда будет не важно кто кого купил.
Ах да.... Xorg работает не только под Linux, есть ещё много интересных OS...
а вот это действительно аргумент. (в соседней новости с ним opensolaris раздают)
плюс - есть такое понятие как стандарты.
Светочка. Во-первых X.Org нужен не только для отрисовки окошек. Во-вторых, тормоза и потребление ресурсов от GTK/Qt несравнимо выше самих иксов. В третьих, тормоза прикладных программ ещё увеличиваются от использования модных языков вроде Питона, Явы и пр..Чтобы оценить нетормознутость X.Org, посмотрите тесты скорости работы игр в сравнении с виндами, например http://www.phoronix.com/scan.php?page=article&item=897&num=3
Мдя смешнее не чего не читал
С очень красивый и краткий язык. В отличии от монстрообразного С++.
зависит от пищущего
обновить nv следует, он там жутко кривойпоставил на работе linux на машину со встроенным видео он nv, так разрешение пыталось отдавать только 800х600 для LCD Samsung 720N, пришлось ставить дрова от nvidia, хотя 3D там ни кому и даром не надо
man xorg.conf
FSF о Microsoft Public License (Ms-PL) отзвается весьма нелестно, о чём автор статьи как-то не упомянул:This is a free software license, compatible with version 3 of the GNU GPL. It is incompatible with version 2 of the GNU GPL because of the conditions in sections 3(B) and 3(C).
PLEASE DO NOT USE this license for anything you write; there are already well-known free software licenses that serve the same purpose, such as the Apache License version 2.0, and we must all stand together to combat license proliferation. However, there is no reason to avoid using software released under this license.
Ну бывает, ну промахнулся эхой... в смысле новостью :)
Кстати, ничего "весьма нелестного" не нашёл.
>>Почему нельзу было использовать cmake
>Ну нелзу, зачит нелзу...Это не аргумент. А autotools must die. Мегебайтовый скриптик под названием configure - это уже слишком. А причин, по которым cmake или scons не подходят для сборки XOrg я не вижу, скорее всего выбор в пользу autotools был сделан из-за их распространенности. Однако это не их достоинство. Тогда надо все программы писать под Windows, т. к. она вроде популярнее Linux. И на C++ вполне можно написать оконную систему. Потеря производительность если и будет, то незначительная, зато проще будет разрыбатывать такую систему и, таким образом, избежать некоторых багов, а возможно, и проще оптимизировать. На Java, а тем более на Python, Perl, Ruby, думаю, писать оконную систему не стоит.
Абсолютно поддерживаю. Все драйвера на Xorg - это реализация С++ на С. Это бред. С++ сильно упрощает и уменьшает код что в свою очередь упрощает разработку и поддержку и увеличивает понимание кода что в свою очередь уменьшает кол-во ошибок. А скорость уже давно не аргумент, разве что скорость компиляции действительно увеличится.
>Абсолютно поддерживаю. Все драйвера на Xorg - это реализация С++ на С.
>Это бред. С++ сильно упрощает и уменьшает код что в свою
>очередь упрощает разработку и поддержку и увеличивает понимание кода что в
>свою очередь уменьшает кол-во ошибок. А скорость уже давно не аргумент,
>разве что скорость компиляции действительно увеличится.Скорость компиляции С++ ?!
Смеялся навзрыд...
+1
скорость компиляции c++ компилятором из набора gcc это... ну в общем сложно передать словами. скажу просто - я не видел, чтобы кто-то делал это медленнее.
>Абсолютно поддерживаю. Все драйвера на Xorg - это реализация С++ на С.
>Это бред. С++ сильно упрощает и уменьшает код что в своюисходный код, прошу заметить
>очередь упрощает разработку и поддержку и увеличивает понимание кода что в
>свою очередь уменьшает кол-во ошибок. А скорость уже давно не аргумент,
>разве что скорость компиляции действительно увеличится.какой С++ может быть в столь критичных приложениях как X?
там на ассемблере писать надо!
Конечно, пусть прикладные программисты поучат системных, чтоб им жизнь медом не казалась.
>>Абсолютно поддерживаю. Все драйвера на Xorg - это реализация С++ на С.
>>Это бред. С++ сильно упрощает и уменьшает код что в свою...И тема обсуждения забыта-потеряна-умерла, а меня больше волнует почему, цитирую -- "X.Org 7.4 отложен на неопределенный срок" ведь это "сердце" любой современной системы, кому это выгодно???
> это "сердце" любой современной системы, кому это выгодно???вот именно. так что торопиться тут не надо.
а то что только по верх него не работает. и compiz, и qt/kde, и gtk, и всё это вместе.
и, к сожалению, после форка с xfree валиться иксы стали чаще.
вы из убунтовцев? :)
не понял вопрос. при чем здесь ubuntu.
я их все юзаю. gentoo токо щас нет.
кстати, последняя ubuntu на АБСОЛЮТНО дерьмовом ноуте (и не старом acer aspire 4720z) работает великолепно.
я предпочитаю руками не собирать гую, ставлю из дистрибутива (Мандрива) и не трогаю.
не падает! compiz-fusion, nv, все в порядке.
и давно не видел, чтобы иксы падали. редхат тоже свои (кроме федоры) дистрибутивы вылизывает, как и suse... остаются только "ручные" типа генту или убунту. потому и спрашиваю.
вот в suse и сыпятся.
как я сказал в ubuntu 8.04 - пока хорошо.
и с каких пор ubuntu ручная? тут пахнет наездом на гентушников. :-)
>>>Абсолютно поддерживаю. Все драйвера на Xorg - это реализация С++ на С.
>>>Это бред. С++ сильно упрощает и уменьшает код что в свою
>
>...И тема обсуждения забыта-потеряна-умерла, а меня больше волнует почему, цитирую -- "X.Org
>7.4 отложен на неопределенный срок" ведь это "сердце" любой современной системы,
>кому это выгодно???Спешка хороша при ловле блох, а когда речь идёт о сердце любой современной системы, то лучше лишний раз проверить.
Ну, и вспоминая старый конликт X.org -- Xfree86, то начинаешь понимать, что X - это как раз тот проект, где здоровый консерватизм не повредит. Слишком уж у икс-орговцев планов громадьё...
>Ну, и вспоминая старый конликт X.org -- Xfree86, то начинаешь понимать, что
>X - это как раз тот проект, где здоровый консерватизм не
>повредит. Слишком уж у икс-орговцев планов громадьё...Оне ж не умерли?
XFree86 Release
4.7.0 release was released on 12 August 2007. Our next full release will be 4.8.0, and is expected to be released in the summer/winter of 2008
We make our releases on a yearly basis and each release number matches the year i.e. 2007 = 4.7.0.Кто пробовал последние релизы и может высказать мнение?
присоединяюсь к вопросу. хотелось бы узнать судьбу проекта.
и насколько xorg и xfree теперь различаются?
и где используются?
Xfree скорее мертв, чем жив. У них реально очень мало разработчиков осталось, большинство сбежало в Xorg. Это же и было причиной конфликта - разработчики считали, что руководство не дает им развернуться во весь рост. Вот все и потянулись за Кейтом Паккардом, когда тот свалил в Xorg. Так что и по фичам XFree здорово отстали, т.е., по моему, в них так и не реализовано расширение AIGLX, через которое работают новомодные штуки типа Compiz, и которое к тому же позволяет получать хардвперное ускорение на локальном X-сервере для клиентских приложений запущенных удаленно. Ну, кроме того они остались на старой системе сборки.А так все примерно тоже самое - антиалиасинг для шрифтов, локальное ускорение (ну, это конечно же больше от Mesa зависит и ядерных модулей). Проблем со сборкой тоже нет. В том смысле, что если приложение специально не требует новой версии протокола, то его без проблем можно собрать как под Xorg, так и под XFree. Так что какой-то стандартизованный API они всё же сохраняют.
сэнкс.
>Xfree скорее мертв, чем жив. У них реально очень мало разработчиков осталось,
>большинство сбежало в Xorg. Это же и было причиной конфликта -
>разработчики считали, что руководство не дает им развернуться во весь рост.вообще-то писали, что у них там возникли вопросы по лицензиям.
>сэнкс.
>>Xfree скорее мертв, чем жив. У них реально очень мало разработчиков осталось,
>>большинство сбежало в Xorg. Это же и было причиной конфликта -
>>разработчики считали, что руководство не дает им развернуться во весь рост.
>
>вообще-то писали, что у них там возникли вопросы по лицензиям.Вообщем-то, да, конечно. Только это, скорее, был формальный повод к началу боевых действий, поскольку недовольство руководством XFree, по-видимому, копилось давно.
На ассемблере писать нужно только действительно критические блоки в драйверах. Оптимизация С и С++ достигла достаточно высокого уровня чтобы забыть про ассемблер почти во всех контекстах. Равно как и скорость программ на С++ мало отличается (если вообще отличается) от С.Я даже больше скажу, столь критичные и большие проекты как X ни в коем случае нельзя писать на ассемблере (вставок ассемблера никто не запрещает, там где это действительно надо)!
>На ассемблере писать нужно только действительно критические блоки в драйверах. Оптимизация С
>и С++ достигла достаточно высокого уровня чтобы забыть про ассемблер почти
>во всех контекстах. Равно как и скорость программ на С++ мало
>отличается (если вообще отличается) от С.
>Втыкать сюда : http://lj.rossia.org/users/kouzdra/446546.html
>Я даже больше скажу, столь критичные и большие проекты как X ни
>в коем случае нельзя писать на ассемблере (вставок ассемблера никто не
>запрещает, там где это действительно надо)!
И не забыть почитать комментарии. Там много справедливой критики прежде чем постить ссылки
Имхо просто проекты где очень критична скорость исполнения, както различные системные проекты, не стоит писать на базовых классах и прочей всякой стандартной лабуды..Использовать ++ расширения можно для оптимизации и упрощения процесса разработки, и совсем необязательно хапать стандартные классы, которые расчитаны на прикладные а не на системные программы, как предков для такой системы как X.
А если с умом заложить базу системы, хоть на фортране :), и потом на ней строить ++ код.. идея более чем живая.. Зато переход на ++ даст вменяемую по масштабируемости и развитию систему в будущем. И пример этому есть - БеОС.
++ это инструмент, который можно использовать бездумно.. а можно по назначению.. как впрочем и любой другой язык.
да не написан BeOS на С++.
читаем внимательно - http://en.wikipedia.org/wiki/Beos
особенно следующие строки:
The API was written in C++ for ease of programming. It has POSIX compatibility and access to a command line interface through the bash shell, although internally it is not a Unix-derived operating system.только API на C++. Тоже самое и в линухе, если брать например KDE.
т.е. KDE API на C++, с этим ведь никто не спорит? и не надо спускаться до уровня X-Window.а если хотите доказать свою правоту, то напишите сами.
мы все с удовольствием по-тестируем.
а взглянуть на этот якобы "C++" код можно здесь:
http://svn.berlios.de/svnroot/repos/haiku/haiku/trunk/src/
Про структуру беос я в общемто вкурсе.. и если внимательней я нигде и не пишу что она написана на ++. я пишу - "А пусть хоть на фортране.." :) А ++ апи предоставляет возможность понятного и удобного дальнейшего развития.Хотя может я и не совсем точно выразился.
> Втыкать сюда : http://lj.rossia.org/users/kouzdra/446546.htmlПросто когда как в выше приведенных ссылках некорректно с моей точки зрения начинают пользоваться инструментом.. получаются всякие монстрообразные проекты и продукты..
Можно сделать любой тест и повернуть все таким образом что останутся одни гетзефакты. А с моей точки зрения, вот эта ссылка показывает только то что использовать vector для хранения и сортировки 2000000 объектов тупо.. И при таких задачах нужны какбы совсем иные алгоритмы/реализации/библиотеки.
Ну а апи на ++ к кедам это конечно здорово.. но я б от такого же может не отказался и к Х и к кернелу :) Вот только ктобы все это причесал и систематизировал :)
Ну уж нет. что сказал, то сказал.
> Зато переход на ++ даст вменяемую по масштабируемости и развитию систему в будущем. И > пример этому есть - БеОС.а api на C++ к ядру, к X, и т.д. имеются в ОЧЕНЬ большем количестве.
разговор был о целесообразности написания приложений, подобных xorg, на C++.
и нечего теперь тему переводить разговор на другие темы.
так что сиди на прикладном уровне и не лезь в системный.
а то, блин, звездеть все горазды, а написать своё - только в коментах.
таких бы в m$ отправить. чтоб наверняка.
Проблем от использования мало распространённой системы сборки будет больше нежели от мегабайтного скрипта.