А еще можно указать ссылку на первоисточник, в начале которого есть список всех зависимостей и несколько вариантов configure под разные кейсы использования.
Почему Red Hat вложился в собственный протокол, когда RDP и Citrix уже существовали? Однозначного ответа нет, но среди факторов наверняка были:
отсутствие открытого протокола для Linux VDI
желание контролировать весь стек (KVM + libvirt + SPICE)
независимость от лицензионной политики Microsoft и Citrix
Тут вроде все плюсы за VNC.
Результат: композитор рендерит всё в offscreen buffer и отдаёт QXL готовый framebuffer. 2D-команды не задействуются. QXL становится просто framebuffer'ом с дополнительными фичами.
историю изменений можно складывать рядом с главной таблицей
оптимистичные блокировки можно реализовать и без CQRS
модели для чтения/записи можно дополнить вьюхами или материализованными вьюхами
Еще в CQRS проекции всегда будут отставать и никогда не сможете это контролировать, так как это будет зависеть от нагрузки на приложение в данный момент.
Звучит вкусно, но есть множество подводных камней.
Есть проект, который построен на этой архитектуре - Zitadel.
Вместе с плюсами, есть минусы:
каждое обновление агрегата сопровождается блокировкой агрегата для вычисления currentSequence
для логина и других чувствительных к актуальности операциях придется ходить в этот append-log, на-лету вычислять актуальное состояние и производить операцию; а теперь представьте какая нагрузка на базу будет, если несколько тысяч пользователей пойдет логиниться
таблицу event store будет очень сложно шардировать, так как у каждого агрегата будет свой ключ; а эта таблица будет самой большой
можно словить приколов с большим потоком записи (как вы построите восстановление проекции без перехода по позиции сообщения?) - события будут пропускаться
еще можно словить приколов с Projector, когда он не сможет обработать сообщение: что с ним делать: пропускать или повторять? А как быть с консистентностью после пропуска?
В заключение скажу, что команда разработки Zitadel словила множество проблем с этой архитектурой и планирует перейти к традиционной архитектуре реляционной базы, а event store оставить для аудита и внешних интеграций: https://github.com/zitadel/zitadel/issues/9599
А еще можно указать ссылку на первоисточник, в начале которого есть список всех зависимостей и несколько вариантов configure под разные кейсы использования.
Спасибо за ценный ответ.
Есть аргументы?
А не сталкивались с кейсом, когда cron в докер контейнере alpine после нескольких задач зависал?
Я задал похожий вопрос в поддержку, мол почему облачный сервер дороже такого же на VDS.
Они ответили, что в облачном сервере есть локальная сеть и другие платформенные сервисы.
А правильно ли я понимаю, что злоумышленник сначала получает доступ на редактирование конфигов nginx, а уже потом перенастраивает его как хочет?
Если да, тогда не понимаю в чем уязвимость nginx?
Подскажите, на каком wayland-композиторе вы это все запускали?
Тут вроде все плюсы за VNC.
Тут прям четко про то, что хорошо умеет VNC.
Претензий нет, просто размышления.
Интересно, чем VNC их не устроил, как в qemu?
Есть либа, которая на фронте и гошке это реализует: https://github.com/peer-calls/peer-calls
Кстати про сравнение:
историю изменений можно складывать рядом с главной таблицей
оптимистичные блокировки можно реализовать и без CQRS
модели для чтения/записи можно дополнить вьюхами или материализованными вьюхами
Еще в CQRS проекции всегда будут отставать и никогда не сможете это контролировать, так как это будет зависеть от нагрузки на приложение в данный момент.
Звучит вкусно, но есть множество подводных камней.
Есть проект, который построен на этой архитектуре - Zitadel.
Вместе с плюсами, есть минусы:
каждое обновление агрегата сопровождается блокировкой агрегата для вычисления currentSequence
для логина и других чувствительных к актуальности операциях придется ходить в этот append-log, на-лету вычислять актуальное состояние и производить операцию; а теперь представьте какая нагрузка на базу будет, если несколько тысяч пользователей пойдет логиниться
таблицу event store будет очень сложно шардировать, так как у каждого агрегата будет свой ключ; а эта таблица будет самой большой
можно словить приколов с большим потоком записи (как вы построите восстановление проекции без перехода по позиции сообщения?) - события будут пропускаться
еще можно словить приколов с Projector, когда он не сможет обработать сообщение: что с ним делать: пропускать или повторять? А как быть с консистентностью после пропуска?
В заключение скажу, что команда разработки Zitadel словила множество проблем с этой архитектурой и планирует перейти к традиционной архитектуре реляционной базы, а event store оставить для аудита и внешних интеграций: https://github.com/zitadel/zitadel/issues/9599
Ну Игорь же, не Иван.
Не пробовали angie?
Было бы круто, используя облачные сервисы, посмотреть митап онлайн.
А можете еще написать статью про подключению GPU к Linux и как с ним xserver и wayland-compositor работают?
И насколько этот подход легален для юр.лиц?
Не понял про пункт "Повышение эффективности/сокращение убытков идёт на пользу в том числе и работнику".
Это благо, что работника просят поднапрячься?
А это не что-то на базе wine?
В ubuntu 24.04 появилось обновление tigervnc server, который начал поддерживать OpenGL (даже с последними проприетарными дровами nvidia).
Таким образом можно запустить контейнер с убунтой и tigervnc server с пробросом видеокарты.