LINUX.ORG.RU

Ubuntu 13.10 будет использовать Mir по умолчанию

 , ,


0

4

Разработчики Ubuntu сегодня сообщили о своих планах поставки графического сервера Mir по умолчанию в Ubuntu 13.10 Saucy Salamander. Работать это будет на базе XMir – прослойки для запуска приложений «X» через Mir.

Как заявлено, XMir будет доступен с некоторыми ограничениями, такими как работа только с открытыми графическими драйверами (Intel, Nouveau и Radeon). Пользователи, использующие проприетарные аналоги, будут перенаправлены на обычный X-сервер. Полную поддержку без режима совместимости планируется добавить к выходу Ubuntu 14.04 LTS.

>>> Подробности на английском

★★★★★

Проверено: maxcom ()
Последнее исправление: cetjs2 (всего исправлений: 2)

Ответ на: комментарий от Reset

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

AVL2 ★★★★★
()
Ответ на: комментарий от special-k

Кинь мне пруф, что вайленд взлетит и подарит шапке много юзеров

Шапке вейланд никаких юзеров (с деньгами) до rhel8 не принесет, а до этого лет пять. Вейланд пилится desktop тимом в свободное от rhel'а время - благо до релиза далеко и могут не напрягаться.

anonymous
()
Ответ на: комментарий от plm

Они свою инфраструктуру строят на RH? Или ты говоришь о продаже лизензий для ЕС2?

cryptohedge
()
Ответ на: комментарий от templarrr

Мне вот интересно, каким именно образом тебе на винде это мешало жить. В примерах и иллюстрациях.

SjZ ★★★★★
()
Ответ на: комментарий от lazyklimm

поставить KDE, так чтобы оно запускалось и работало, а в системе не было konkeror-а можно.

Но ты не можешь, и я не могу. Так зачем оно тогда, это «можно»? Душу греть?

SjZ ★★★★★
()
Ответ на: комментарий от SjZ

Так используй ос х раз тебе оно надо. Там эта фича уже реализована.

как по мне идеально: каждая десктопная программа лежит в своей папке

Если как-то так, то частично согласен, но не для всего софта в системе.

cryptohedge
()
Ответ на: комментарий от cryptohedge

Какая именно фича? //придет время, так обязательно буду

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

SjZ ★★★★★
()
Последнее исправление: SjZ (всего исправлений: 1)
Ответ на: комментарий от lazyklimm

Списка не надо, я просил удалить ОДИН.

SjZ ★★★★★
()
Ответ на: комментарий от Atheist

А что же там выборе 8 из 10 Ubuntu тогда?

AMI в основном делает комьюнити, многие на этом деньги зарабатывают. Амазон дает только платформу. По AMI авторства лично амазона статистика такая:

  • Windows - 19
  • Fedora - 6
  • Other linux - 4

https://aws.amazon.com/amis?ami_provider_id=1&selection=ami_provider_id

provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 1)
Ответ на: комментарий от numas13

Если использовать дискретного монстра, безусловно. Но на сколько это справедливо для интегрированной графики? Полагаю такая жертва вполне уместна в современных реалиях.

Надо все же смотреть по потреблению ресурсов. Было хороший пост Dianne Hackborn о цене аппаратного ускорения на андроидах: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s7

Простое включение OpenGL в приложениех требует дополнительных 8 Мб памяти. Если приложение потребляет 2 Мб - такой оверхед довольно существенный.

Как я себе это представлю на дескотпе с композитингом каждое приложение аллоцирует себе сурфейс по возможности на видеопамяти, где приложение рисует само себя не зная о своем положение на экране (могу что-то путать). Если например у меня 10 приложений, то как понимаю все они будут держать изображение себя в сурфейсе, даже, например, когда полностью закрыты или минимизированы. Плюс сам десктоп задействует ресурсы видео ускорителя.

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

Сетевая прозрачность большинству не нужна, в итоге ей жертвуют. Что печально, против течения не попрёшь. )8

Микрософт таки пошла против такого течения, убрала Аеро на восьмерке и развивает РДП. Другое дело на телефонах и планшетах отказ от сетевой прозрачности сейчас действительно более распространенный случай.

anonymous
()
Ответ на: комментарий от anonymous

Надо все же смотреть по потреблению ресурсов. Было хороший пост Dianne Hackborn о цене аппаратного ускорения на андроидах: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s7

К сожалению нет доступа.

Простое включение OpenGL в приложениех требует дополнительных 8 Мб памяти. Если приложение потребляет 2 Мб - такой оверхед довольно существенный.

Как я себе это представлю на дескотпе с композитингом каждое приложение аллоцирует себе сурфейс по возможности на видеопамяти, где приложение рисует само себя не зная о своем положение на экране (могу что-то путать). Если например у меня 10 приложений, то как понимаю все они будут держать изображение себя в сурфейсе, даже, например, когда полностью закрыты или минимизированы. Плюс сам десктоп задействует ресурсы видео ускорителя.

Это справедливо для OGL, но в вэйленд используют GLES2. К сожалению с GLES дел не имел, но всё же я надеюсь, что ситуация не настолько ужасна.

numas13
()
Ответ на: комментарий от AVL2

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

предположу, что это тупо отвалится (в смысле, будет no-op) на андроиде (и все равно там наверно нет понятий «дефолтный монитор», «перейти в полный экран»), и, опять предположу, будет тупо форвардится туда, кем исполнялось и раньше на десктопе

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Pakostnik

Нигде не будет работать, кроме божественной Убунты.

да как ты посмел — Божественная с большой буквы пишется, еретик!

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от Atheist

Ай ай ай. Как же они не поинтересовались у русских не возникнет ли у них каких либо неправильных ассоциаций. Пидорашка as is, lol.

anonymous
()
Ответ на: комментарий от numas13

Это справедливо для OGL, но в вэйленд используют GLES2. К сожалению с GLES дел не имел, но всё же я надеюсь, что ситуация не настолько ужасна.

Это ровно тот же самый OpenGL.

note173 ★★★★★
()
Ответ на: комментарий от Reset

а в каких программах кроме xcalc, xterm, xbill и прочего legacy остались такие вызовы?

 [ivan@hp-f19]~% ldd -r /usr/bin/konsole | grep X
        libQtXml.so.4 => /lib64/libQtXml.so.4 (0x0000003faee00000)
        libX11.so.6 => /lib64/libX11.so.6 (0x000000350a200000)
        libXext.so.6 => /lib64/libXext.so.6 (0x000000350aa00000)
        libXft.so.2 => /lib64/libXft.so.2 (0x000000350ee00000)
        libXau.so.6 => /lib64/libXau.so.6 (0x0000003509a00000)
        libXpm.so.4 => /lib64/libXpm.so.4 (0x000000350d400000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x000000350ae00000)
        libXtst.so.6 => /lib64/libXtst.so.6 (0x000000350e600000)
        libXcursor.so.1 => /lib64/libXcursor.so.1 (0x000000350d000000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x000000350be00000)
        libXi.so.6 => /lib64/libXi.so.6 (0x000000350b600000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x000000350c600000)
        libXinerama.so.1 => /lib64/libXinerama.so.1 (0x000000350ba00000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x0000003512000000)

Вызовы к Xlib или к XCB сейчас есть почти везде. Тут проще перечислять где их нет.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Reset

Потому что Qt использует X11 и, естественно, либы будут отображаться в ldd.

Согласен. Тогда можно так попробовать. Тут правда уже меньше зависимостей.

[ivan@hp-f19]~% readelf -d /usr/bin/konsole | grep X
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libQtXml.so.4]
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libXext.so.6]
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libXft.so.2]
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libXau.so.6]
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libXpm.so.4]

Ну и от libX11, libXft, libXext, libXau почти все libkde* зависят. Так что хоть каким-то портированием заняться придётся.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от awesomenickname

каковы достоинства Mir перед иксами?

«It will be brand new awesome graphics server» Больше не знаю.

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

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

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

chabapok
()
Ответ на: комментарий от chabapok

за ними подтянутся другие дистры и разрабы

NO.

вейленд говном

синдром NIH.

i_gnatenko_brain ★★★★
()
Ответ на: комментарий от chabapok

Вряд ли такая крупная компания стала бы в это просто так инвестировать

Ubuntu TV

anonymous
()
Ответ на: комментарий от numas13

Это справедливо для OGL, но в вэйленд используют GLES2.

Речь шла про андроид где как раз мобильный GL, т.е. под что пилят Mir. Напутал ссылку, лишняя цифра 7 была на конце: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

anonymous
()

Кабы оно не потекло в остальные дистры :C

HazardousNaN
()
Ответ на: комментарий от cruxish

Это, видимо, человек начитался про Слаку, запомнил страшное выражение, и даже не слышал про пакетные менеджеры.

anonymous
()

Люди издеваются

«работа только с открытыми графическими драйверами (Intel, Nouveau и Radeon)» - ну да, поддержка apu (Radeon) этими драйверами вообще шикарная, ток вчера из xorg-edgers загрузились 1 драйвера, которые запустились на ноуте, а не висят черным экраном, а когда запустились, то они глючили настолько, что vesa драйвер работал намного быстрее XD

anonymous
()
Ответ на: комментарий от anonymous

Оптимизируют, опять надеюсь.

Раньше считал, что GLES менее требователен. Всё таки ориентация на встройку и моб. устройства, не тут то было.

numas13
()
Ответ на: комментарий от lazyklimm

пример, пожалуйста

удали в дефолтном дебиане с гномом empathy, пакетный менеджер потянет за собой весь гном

Poisoned ★★★
()
Ответ на: комментарий от numas13

Раньше считал, что GLES менее требователен. Всё таки ориентация на встройку и моб. устройства, не тут то было.

Ориентация на встройку и мобильные устройства за счёт выкидывания частей API, которыми и в полноценном OpenGL не особо часто пользуются (меньше фич -> проще железо и драйвера). В остальном всё зависит от реализации, на вещи типа количества отводимой под буферы памяти спецификация повлиять не может хотя бы потому, что универсального решения для всех 100500 возможных юзкейсов нет и быть не может.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.