Архітектура сервера / клієнта Xorg дозволяє забезпечити прозорість мережі, що означає, що можна запустити x-клієнтів на віддаленій машині та відобразити графічний інтерфейс на локальній машині (тобто через x-переадресацію за допомогою ssh).
Чи буде у Wayland такий самий чи подібний спосіб дозволяти відображати графічні інтерфейси програм у іншій системі, ніж вони працюють?
Чи потрібна ця функція, перш ніж вжити будь-яких кроків по заміні Xorg на Wayland в системах Ubuntu?
Відповіді:
Згідно з http://mmol-6453.livejournal.com/253081.html прозорість мережі є у списку того, що потрібно зробити, вона знаходиться лише внизу цього списку. Якщо сказане там відповідає дійсності, ми зрештою зможемо графічно підключитися до іншої машини та запустити додатки, але не відразу, і, ймовірно, ДО Х випаде. Я сподіваюся, що це правда, тому що, як і інші, я вважаю це основною перевагою для системи на базі X, ніж інші, наприклад Windows.
Я розумію, що X зможе працювати на вершині Wayland як клієнт. Дивіться діаграми внизу http://wayland.freedesktop.org/architecture.html, наприклад.
Вони згадують про це лише з точки зору можливості спільного використання вхідних пристроїв з X для зворотної сумісності, але я припускаю, що це означає, що можна буде спілкуватися з сервером X через віддалене з'єднання, навіть якщо він працює на Wayland.
Я не знаю жодної графічної програми, яку я не можу запустити протягом сеансу ssh. Я, і, напевно, кожен, кого я знаю, професійно використовую це щодня. Не тільки на роботі, але і вдома. Compiz та інші класні ефекти - це розкіш. Прозорість мережі для кожної графічної програми, яку я можу встановити, є обов'язковою умовою . RDP або VNC є неприйнятними замінниками.
Все, що я бачу на цю тему, - це коментарі на кшталт "не хвилюйся через це, тому що ... [вставити слова, які змушують мене турбуватися тут].
Я хочу, щоб хтось, хто розробляє Wayland, публічно сказав "не хвилюйся через це, оскільки" прозорість мережі - це головний пріоритет для нас ". Вони знають, що ми хочемо це почути, але вони не вийдуть і скажуть це без хеджування.
Правильна відповідь: "Прозорість мережі виходить за межі протоколу Wayland".
Повне пояснення міститься в цьому FAQ, але короткий підсумок може бути таким: "мета Wayland - це визначити невеликий протокол, намагаючись утриматися від найбільшої помилки X: робити занадто багато і робити обов'язки (X навіть мав сервер друку в ньому !!!). Маючи на увазі цю концепцію, немає видатних причин додавати прозорість мережі в протоколі Wayland. Це можна зробити в автономному API та його сервері / клієнті. Ніщо в протоколі Wayland не суперечить прозорості мережі . "
Одне, що варто згадати, - це те, що поточні реалізації X вже не є прозорими для мережі , як це пояснює Даніель Стоун у цьому відео (що ви дійсно повинні побачити, якщо вам цікавий аргумент, і якщо ви хочете мати хороший --nerdy-- ).
Жоден Wayland менш амбітний, що Xorg і не матиме прозорості мережі.
Цитуючи з блогу Марка Шуттлворта:
Деякі з головних цілей X роблять складніше досягти цього досвіду користувачів на X, ніж на рідному GL, ми вибираємо пріоритет якості досвіду над тими вихідними значеннями, як прозорість мережі.
посилання: http://www.markshuttleworth.com/archives/551
Як особиста думка, я не вважаю, що мережева прозорість графічного «сервера» є функцією, необхідною для настільного комп’ютера, це особливість, яка найкраще відповідає архітектурі tiny_client / big_workstation.
Здатність Wayland запускати X вкладене означає, що можна буде підтримувати більшість ситуацій прозорості мережі та подібних функцій. Також я читав, що ця функціональність може бути замінена кращим методом (якщо я знову зможу знайти посилання, я надам її).
Хоча прозорість мережі виходить за межі шляхуlandland , ніщо не заважає композиторам реалізовувати мережеву прозорість, або навіть проект, як-от накопичувач для створення сервера віддаленої візуалізації поверх Wayland для використання композиторами