RustDesk Pro в России не купить. После долгих лет администрирования мы собрали своё честное решение

[achekalin]

RustDesk Pro в России не купить. После долгих лет администрирования мы собрали своё честное решение

1. Почему LLM так любят слово "честный"?

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

[arturwise]

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

Да на самом деле и статьи я не умелец писать, поэтому честно прошу прощения.

Но в целом статья должна понравиться, я постарался рассказать об основных выжимках проекта.

[MikalaiR]

При этом - это форк RustDesk без публикации исходников, что прямо нарушает AGPLv3.

Это не так. Вы обязаны предоставить исходники только тем, кому предоставляете бинарники или SaaS. Публиковать - не обязаны.

[arturwise]

Вы правы. Спасибо за уточнение.

[AngryEvilCookie]

Да по сути такая же обёртка над видео кодеком без магии, в отличии от энидеск. Поправьте, если не прав.

[cpud47]

Я не обязан публиковать форк - потому что форка нет. Есть downstream-патчи, которые публичные (в моём workflow-репо) и AGPL-совместимые.

Форк(т.е. derived work) есть, просто не в самой традиционной форме. Но исходники Вы в любом случае публикуете, поэтому с этим проблемы нет.

Главная - upstream ломает имена. Я однажды добавил sed-патч под анкер PopupMenuButton<String>, а upstream переименовал виджет в следующем релизе. Sed молча не нашёл паттерн (continue-on-error: true), сборка прошла, но функционал не добавился.

По-хорошему, вместо sed лучше бы перейти на diff+patch. Таким образом будет более надёжная и внятная проверка, что всё применялось корректно. Ну и создавать это удобнее. См. suckless как практический пример.

Это работает, но через год upstream уйдёт далеко, и поддерживать форк становится больно. У RustDesk коммиты прилетают каждый день.

git rebase и всё поддержка сводиться к минимуму. +git rerere. Всё ещё нужно разрешать конфликты, но это и в Вашем подходе нужно, т.к. Вы довольно таргетированные замены делаете.

По сути, это сильно похоже на подход с патчами, только ещё более автоматизированный.

Сборка одного клиента - 25-40 минут

Зачем собирать клиент под каждого пользователя/потребителя?

Можно вынести все конфигурации в (embedded) конфиг и просто перешивать конфиг под потребителя.

Ну и привязывать работоспособность прода к gh actions — не самое разумное решение, особенно в российских реалиях...

[Granulex]

Подход "не форк, а патч при каждой сборке" элегантен, но имеет скрытую стоимость: каждый релиз RustDesk потенциально ломает патчи, и нужно либо следить за каждым upstream-коммитом, либо иметь smoke-тест, который поймает поломку ещё в CI. Чем больше точек патчинга, тем выше операционный долг. Для небольшой команды это разумный trade-off – форк потребовал бы полного merge при каждом обновлении. Но стоило бы добавить в README явный SLA: за сколько часов после upstream-релиза выходит обновлённая сборка.