Исправление atrus, (текущая версия) :
А тут в вейлэнд эту прозрачность добавляют, и как будто у вейлендфилов методичку поменяли - они начали нахваливать сетевую прозрачность в самом вейленде.
А вот сейчас вам станет стыдно. Хотя, кого я обманываю, вам не станет. Но вы тут все просто помогаете блогеру насиловать разработчика.
Нет, правда, сходили бы по ссылке, нашли бы там упоминание об этой мега-новости. А её там нет. Зато в первом упоминании в рунете есть примечание, что Samsung опубликовал набор патчей для поддержки сетевой прозрачности.
И уже дальше пошли перепечатки, в котором включение этих патчей превозносилось, как свершившийся факт.
На самом же деле...
Есть proof of concept, который не рекомендуется ко включению, потому что
1. В текущем виде - открытая дыра безопасности.
2. Поддержка ограничена рядом систем (вероятно только unixlike).
3. В реализации есть серьёзные проблемы с адским количеством используемых файловых дескрипторов. (см дискуссию).
4. Далеко не все приложения смогут в сетевую прозрачность.
Автор напоминает, что причины как минимум те же, что мешают некоторым X приложениям в прозрачность. Как вы будете гонять по сети произвольные шаренные буферы памяти?
Итого, для реализации сети потребуется или ограничить возможные каналы обмена информацией (но тогда начнут ныть, что локально работает медленно) или возложить выбор способа на приложение. Т.е. фактически на тулкиты. Которые может сделают, а может нет. Т.е. приложения будут или работать или не работать или глючить, если проблемы будут с отдельными виджетами. И тогда поток проклятий обратится в сторону разработчиков Wayland, потому что про тулкит подумают в последнюю очередь, тем более, разработчики тулкитов традиционно займут очередь нытиков первыми.
Впрочем, если проблемы с дескрипторами будут улажены, а контроль сетевого доступа добавлен, может и вольют в Weston. Потому что:
1. Протокол вроде как не затрагивает.
2. Есть не просит и уже написано.
3. Не мешает работе на локали.
4. Разработчикам Wayland не привыкать к нытью и необоснованным проклятиям в свой адрес. :)
5. А может и не добавят, потому что в Weston можно тупо реализовать RDP. И подвижки вроде как есть...
Так зачем добавлять это в протокол
В какой протокол?
feel free to add that line to your compositor and give it a try (hint: in Weston it’s right before load_modules in main).
Исправление atrus, :
А тут в вейлэнд эту прозрачность добавляют, и как будто у вейлендфилов методичку поменяли - они начали нахваливать сетевую прозрачность в самом вейленде.
А вот сейчас вам станет стыдно. Хотя, кого я обманываю, вам не станет. Но вы тут все просто помогаете блогеру насиловать разработчика.
Нет, правда, сходили бы по ссылке, нашли бы там упоминание об этой мега-новости. А её там нет. Зато в первом упоминании в рунете есть примечание, что Samsung опубликовал набор патчей для поддержки сетевой прозрачности.
И уже дальше пошли перепечатки, в котором включение этих патчей превозносилось, как свершившийся факт.
На самом же деле...
Есть proof of concept, который не рекомендуется ко включению, потому что
1. В текущем виде - открытая дыра безопасности.
2. Поддержка ограничена рядом систем (вероятно только unixlike).
3. В реализации есть серьёзные проблемы с адским количеством используемых файловых дескрипторов. (см дискуссию).
4. Далеко не все приложения смогут в сетевую прозрачность.
Автор напоминает, что причины как минимум те же, что мешают некоторым X приложениям в прозрачность. Как вы будете гонять по сети произвольные шаренные буферы памяти?
Итого, для реализации сети потребуется или ограничить возможные каналы обмена информацией (но тогда начнут ныть, что локально работает медленно) или возложить выбор способа на приложение. Т.е. фактически на тулкиты. Которые может сделают, а может нет. Т.е. приложения будут или работать или не работать или глючить, если проблемы будут с отдельными виджетами. И тогда поток проклятий обратится в сторону разработчиков Wayland, потому что про тулкит подумают в последнюю очередь, тем более, разработчики тулкитов традиционно займут очередь нытиков первыми.
Впрочем, если проблемы с дескрипторами будут улажены, а контроль сетевого доступа добавлен, может и вольют в Weston. Потому что:
1. Протокол вроде как не затрагивает.
2. Есть не просит и уже написано.
3. Не мешает работе на локали.
4. Разработчикам Wayland не привыкать к нытью и необоснованным проклятиям в свой адрес. :)
Так зачем добавлять это в протокол
В какой протокол?
feel free to add that line to your compositor and give it a try (hint: in Weston it’s right before load_modules in main).
Исходная версия atrus, :
А тут в вейлэнд эту прозрачность добавляют, и как будто у вейлендфилов методичку поменяли - они начали нахваливать сетевую прозрачность в самом вейленде.
А вот сейчас вам станет стыдно. Хотя, кого я обманываю, вам не станет. Но вы тут все просто помогаете блогеру насиловать разработчика.
Нет, правда, сходили бы по ссылке, нашли бы там упоминание об этой мега-новости. А её там нет. Зато в первом упоминании в рунете есть примечание, что Samsung опубликовал набор патчей для поддержки сетевой прозрачности.
И уже дальше пошли перепечатки, в котором включение этих патчей превозносилось, как свершившийся факт.
На самом же деле...
Есть proof of concept, который не рекомендуется ко включению, потому что
1. В текущем виде - открытая дыра безопасности.
2. Поддержка ограничена рядом систем (вероятно только unixlike).
3. В реализации есть серьёзные проблемы с адским количеством используемых файловых дескрипторов. (см дискуссию).
4. Далеко не все приложения смогут в сетевую прозрачность.
Автор напоминает, что причины как минимум те же, что мешают некоторым X приложениям в прозрачность. Как вы будете гонять по сети произвольные шаренные буферы памяти?
Итого, для реализации сети потребуется или ограничить возможные каналы обмена информацией (но тогда начнут ныть, что локально работает медленно) или возложить выбор способа на приложение. Т.е. фактически на тулкиты. Которые может сделают, а может нет. Т.е. приложения будут или работать или не работать или глючить, если проблемы будут с отдельными виджетами. И тогда поток проклятий обратится в сторону разработчиков Wayland, потому что про тулкит подумают в последнюю очередь, тем более, разработчики тулкитов традиционно займут очередь нытиков первыми.
Впрочем, если проблемы с дескрипторами будут улажены, а контроль сетевого доступа добавлен, может и вольют в Weston. Потому что:
1. Протокол вроде как не затрагивает.
2. Есть не просит и уже написано.
3. Не мешает работе на локали.
4. Разработчикам Wayland не привыкать к нытью и необоснованным проклятиям в свой адрес. :)