Maynard — новая графическая оболочка на основе Wayland для Raspberry Pi

В Pidora встроят по умолчанию?

Почему ламеры так отчаянно рвутся убить сетевую прозрачность?

Они явно любят Tool или Perfect Circle.

Почему ламеры так отчаянно рвутся убить сетевую прозрачность?

Потому что в протоколе она не нужна?

А зачем она на этом уровне? Чем spice с vnc не угодили?

vnc очень тяжелый протокол. Сравни, сколько байтиков перегоняет xterm, и сколько будет для такого же терминала поверх vnc.

vnc очень тяжелый протокол. Сравни, сколько байтиков перегоняет xterm, и сколько будет для такого же терминала поверх vnc.

Осталось уточнить, где ты видел приложения типа xterm, на голом xlib. И что с твоим терминалом будет, если оборвется связь.

Осталось уточнить, где ты видел приложения типа xterm, на голом xlib.

Ну так сам xterm и есть главнейшее приложение. Плюс еще emacs. Что тебе еще нужно для жизни?

И что с твоим терминалом будет, если оборвется связь.

Ничего не будет. Восстановится. На то она и сетевая прозрачность, что можно что угодно посередине подстелить.

Ну так сам xterm и есть главнейшее приложение.

А зачем его удалённо запускать?

А ты его собрался локально на айпадике запускать, что ли?

ssh?!

Ничего не будет. Восстановится. На то она и сетевая прозрачность, что можно что угодно посередине подстелить.

Ох уж эти теоретики... Вместе с соединением безвозвартно упадет и xterm.

Эмулятора терминала у вас нет, а X Server есть?

ssh?!

еще один теоретик. ssh пробрасывает X протокол. Нет иксов, нет мороженого. Вернее, будет VNC, spice или NX.

Надо будет её переименовать в Manya. :)

Выглядит забавно. А разные декорации у окон на видео - это потому что декорации клиентсайд?

Работает-то быстрее, чем иксы? Думаю, на pi разница особо заметна)

Естественно. X server легкий и есть везде.

Ну значит ipad не нужен, если там даже эмулятора терминала нет.

Не, ну не могу я привыкнуть к ее названию:)

нет, ты мне объясни нафига xterm пробрасывать?

Сначала так и прочел.

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

довольно не плохо, но очень сильно похоже что интерфейс больше ориентирован на планшеты.

Почему?

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

Потомучто оффтопик со своим RDP жестко натягивает VNC. А сетевая прозрачность где-то между ними

Плюс еще emacs

emacs не юзает голый xlib

Сначала так и прочел.

Я тоже, поэтому и написал так.

Ох уж эти теоретики... Вместе с соединением безвозвартно упадет и xterm.

Дефолтный xterm завершится после разрыва соединения с X-сервером. Но ничто не мешает в xterm предусмотреть восстановление соединения, заново нарисовать окно и продолжить прям вот с места разрыва связи.

Почему этого не сделали - это уже другой вопрос... На голом Xlib действительно сложно сделать. А в каком-нибудь Qt может хватить и патча в пару сотен строк, если перед программистами будет стоять такая задача. Можно также запилить некий Xnest/XProxy с функцией восстановления соединения (или подключения к резервному X-серверу). В менеджерах закачек HTTP/FTP такая функциональность заложена изначально и дурным тоном считается, когда нельзя продолжить прераванную закачку. Почему с X11 должно быть иначе?

В Pidora встроят по умолчанию?

Конечно встроят, и назовут May Way Pidora

Будем справедливыми, он есть.
https://itunes.apple.com/ru/app/issh-ssh-vnc-console/id287765826?mt=8 , например. В том числе работает для собственно айпада после джейлбрейка.

Ненужно портанули на ненужно котрым пользуются ненужно.

Потому что вокалиста в этих группах зовут Maynard James Kinan.

не, https://www.google.ru/search?q=maynard&newwindow=1&safe=off&sourc...

Дефолтный xterm завершится после разрыва соединения с X-сервером. Но ничто не мешает в xterm предусмотреть восстановление соединения, заново нарисовать окно и продолжить прям вот с места разрыва связи.

Не получится. Состояние окна и канва хранится на сервере. Пропал сервер - пропала и канва. Чтобы после восстановления связи восстановить прежний вид окна приложения, необходимо формировать и хранить его на стороне клиента. Это как раз то, чем занят X-сервер.

Можно также запилить некий Xnest/XProxy с функцией восстановления соединения (или подключения к резервному X-серверу).

можно. уже сделано. NX, например или xmove.

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

И да, сетевая прозрачность для таких схем нафиг не нужна. Достаточно запустить прокси локально, а по сети передавать уже поток от него.

В менеджерах закачек HTTP/FTP такая функциональность заложена изначально

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

...или Puscifer ^_^

Это ты что, садист этакий, предлагаешь xterm на qt переписать???

Потому, что ламеры.

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

Я связь уже обрывал. Потом логинился в ту же самую сессию в иксы. Ничего не упало, всё работало. Оставлял даже сутками так выполняться программы в оборванной сессии.

Не знаю насчёт анонимуса, но лично я не теоретик и у меня всё восстанавливалось при повторном подключении. Это у тебя что-то не так, возможно, с руками.

Если что, NX опирается на иксовый протокол. По сути кэширующий прокси-сервер, который вдобавок трафик сжимает. Но команды как были, так и остались иксовыми. А VNC и SPICE - это уже совсем другое. И я подозреваю, что SPICE очень убог по сравнению с решениями от того же Cirtix (надо будет попробовать).

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

Хватит уже этот xlib тыкать. Библиотека xlib мертва. Есть xcb.

anonymous> Дефолтный xterm завершится после разрыва соединения с X-сервером. Но ничто не мешает в xterm предусмотреть восстановление соединения, заново нарисовать окно и продолжить прям вот с места разрыва связи. Почему этого не сделали - это уже другой вопрос...

Всё сделали. Причём не на уровне приложения, а правильно - в менеджере сессий для удалённой работы.

anonymous> Можно также запилить некий Xnest/XProxy с функцией восстановления соединения (или подключения к резервному X-серверу).

Собственно, уже. И в самом протоколе оно нафиг не нужно, кстати.

Это не оболочка, это ланчер.

Не получится. Состояние окна и канва хранится на сервере. Пропал сервер - пропала и канва. Чтобы после восстановления связи восстановить прежний вид окна приложения, необходимо формировать и хранить его на стороне клиента.

Это возможно без переделывания протокола. Приложения повторит действия инициализации по новой после реконнекта. Для этого не нужно рисовать картинки в буфер и транслировать отрисованную клиентом картинку на сервер. Но нужно учитывать, что все старые ID-шники стали невалидными, нужно все пересоздать по новой на новом сервере, восстановить размеры элементов и т.д. После первой же перерисовки окна скорее всего получится то же самое, что было на старом сервере. Так что все в руках разработчика клиентского приложения :)

ок (%

Хватит уже этот xcb тыкать. Библиотека xcb мертва. Есть html5.

Из добавленных в GTK+ 3.12.0 улучшений можно отметить:

- Расширены возможности бэкенда Broadway (http://git.gnome.org/browse/gtk /log/?qt=grep&q=broadway), позволяющего отрисовывать вывод библиотеки GTK3+ в окне web-браузера. Для обмена данными теперь применяются только бинарные буферы и современный протокол WebSocket. Для оптимизации прокрутки задействованы кольцевые хэши. Реализована поддержка декарирования окон на стороне клиента. Добавлена обработка событий ввода с сенсорных экранов и поддержка экранной клавиатуры IPad;

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

Хватит уже этот xcb тыкать. Библиотека xcb мертва. Есть html5.

http://www.infoq.com/presentations/servo-parallel-browser (смотреть с 31 минуты).
Веб-движки до сих пор не могут в параллелизм, поэтому SOSNOOLEY практически неизбежны.