Я ни к чему не подталкиваю. Мои статьи — не про выбор «правильного VDI», а про границы инструментов и устройство протокола. Думаю нужно сначала понять сценарий (офис, видео, 4K, WAN), а уже потом выбирать протокол и архитектуру. SPICE — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.
В VDI нет потоков Linux↔Windows как таковых. Всегда есть «гостевая ОС → протокол → клиент». Так что тип ОС внутри не важен: сжатие выполняется на сервере по содержимому экрана, а не по ОС. Разница появляется только на клиенте — в выборе кодеков под его производительность. Но тоже не существенная
VNC образца 2007 был значительно беднее (без аудио, USB, нормального clipboard). К слову, и сегодня open-source VNC так и не получил аудио — PR в TigerVNC висит с 2023 года, а clipboard в noVNC работает через костыли с тем же spice-vdagent.
Но вы правы насчёт framebuffer'а — разница в том, как он передаётся: SPICE использует адаптивное сжатие и эвристики для детекта видеопотоков, VNC — фиксированные encoding'и (Tight, ZRLE) на весь кадр.
В целом, вы попали в точку: именно поэтому Red Hat сегодня рекомендует VNC для серверов. Когда разница нивелирована — зачем тянуть отдельный протокол? Но это не для VDI а для админов.
Про «забросили» — скорее нет. Это не активная гонка за фичами, а режим поддержки: проект живёт, чинится, используется (тот же Proxmox), просто без резких движений.
Хороший вопрос, без шуток. В SPICE TCP — это не просто «подложка», а часть мышления протокола. Там много решений, которые молча опираются на поведение TCP: порядок, блокировки, backpressure, отдельные соединения на каналы. Поэтому «прозрачно заменить транспорт» не получается — это уже будет другой протокол, с другими допущениями и болью. Связь SPICE и TCP на самом деле глубже, чем влезает в комментарий. Я, пожалуй, отдельно про это напишу: почему так вышло исторически и к чему это привело сейчас.
Я ни к чему не подталкиваю. Мои статьи — не про выбор «правильного VDI», а про границы инструментов и устройство протокола.
Думаю нужно сначала понять сценарий (офис, видео, 4K, WAN), а уже потом выбирать протокол и архитектуру. SPICE — один из вариантов, хороший в своей нише, но не универсальный ответ на всё.
В VDI нет потоков Linux↔Windows как таковых. Всегда есть «гостевая ОС → протокол → клиент». Так что тип ОС внутри не важен: сжатие выполняется на сервере по содержимому экрана, а не по ОС. Разница появляется только на клиенте — в выборе кодеков под его производительность. Но тоже не существенная
VNC образца 2007 был значительно беднее (без аудио, USB, нормального clipboard). К слову, и сегодня open-source VNC так и не получил аудио — PR в TigerVNC висит с 2023 года, а clipboard в noVNC работает через костыли с тем же spice-vdagent.
Но вы правы насчёт framebuffer'а — разница в том, как он передаётся: SPICE использует адаптивное сжатие и эвристики для детекта видеопотоков, VNC — фиксированные encoding'и (Tight, ZRLE) на весь кадр.
В целом, вы попали в точку: именно поэтому Red Hat сегодня рекомендует VNC для серверов. Когда разница нивелирована — зачем тянуть отдельный протокол? Но это не для VDI а для админов.
Ну дело в том, что VNC — это remote framebuffer из 1998 года, созданный для совсем других задач.
Про «забросили» — скорее нет. Это не активная гонка за фичами, а режим поддержки: проект живёт, чинится, используется (тот же Proxmox), просто без резких движений.
Хороший вопрос, без шуток. В SPICE TCP — это не просто «подложка», а часть мышления протокола. Там много решений, которые молча опираются на поведение TCP: порядок, блокировки, backpressure, отдельные соединения на каналы. Поэтому «прозрачно заменить транспорт» не получается — это уже будет другой протокол, с другими допущениями и болью.
Связь SPICE и TCP на самом деле глубже, чем влезает в комментарий. Я, пожалуй, отдельно про это напишу: почему так вышло исторически и к чему это привело сейчас.