Здравствуйте, aik, Вы писали:
aik>Между рабочей станцией и сервером 30мбит, но 220мс пинг. На сервере git репозиторий ядра линукса. Везде linux. Ищется возможность работать с git с комфортом, т.е. gitk и git citool. Как народ решает проблему?
aik>Когда пинг 10мс, x-forwarding работает супер. Когда пинг 220мс, только первое окно открывается минуту. Шарить файловую систему оттуда на мой комп и запускать локально — gitk будет запускаться час. Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза, держать всё локально нельзя, потому что тестовое железо "там" и там же билдсервер с 200+ потоков.
aik>Сейчас я хожу по ssh (220мс кое как хватает) и для браузенья по репо использую tig, а для коммитов git add -i, но это убогие копии gitk и git citool. vim fugitive годится только для "Gblame".
aik>Чем народ пользуется нынче? Нет ли способа разогнать X? Суперотзывчивости не надо. Может, из wayland как то можно что то вытянуть?
Как я понял нужно вести правку кода на удаленном сервере.
У меня в некотором роде схожая ситуация — сервер поближе, но latency 90 ms.
По моему опыту:
— классический x-forwarding — годится только для LAN (причины написали выше — приложения не оптимизированы под сеть).
— софт на основе x-forwarding c оптимизациями, например NXMachine, Xpra, X2go — существенно лучше, но тоже недостаточно. Я использую x2go — пробовал работать с документами в libreoffice — слишком медленно.
— RDP — уже приемлимо, но я пробовал только в паре rdp клиент (linux) -> rdp сервер (windows). Как будет работать rdp сервер linux не могу сказать. Работа была как раз с кодом (IDE и графический Git клиент)
Кстати Вы как раз написали, что RDP и VNC нормально работает, тогда в чем проблема?
Если нужно именно на основе x-forwarding, то наверное имеет смысл попробовать X2go.
Здравствуйте, aik, Вы писали:
aik>Между рабочей станцией и сервером 30мбит, но 220мс пинг. На сервере git репозиторий ядра линукса. Везде linux. Ищется возможность работать с git с комфортом, т.е. gitk и git citool. Как народ решает проблему?
aik>Когда пинг 10мс, x-forwarding работает супер. Когда пинг 220мс, только первое окно открывается минуту. Шарить файловую систему оттуда на мой комп и запускать локально — gitk будет запускаться час. Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза, держать всё локально нельзя, потому что тестовое железо "там" и там же билдсервер с 200+ потоков.
aik>Сейчас я хожу по ssh (220мс кое как хватает) и для браузенья по репо использую tig, а для коммитов git add -i, но это убогие копии gitk и git citool. vim fugitive годится только для "Gblame".
aik>Чем народ пользуется нынче? Нет ли способа разогнать X? Суперотзывчивости не надо. Может, из wayland как то можно что то вытянуть?
Был опыт работы через VS Code. Но там нужна поддержка или допиливание, как я понял. Суть в том, что ты работаешь полностью удалённо, все файлы на сервере, редактор VS Code отсылает только изменения, причём делает это асинхронно относительно редактирования, поэтому задерки сети не ощущаются (у меня был пинг ~300мс). И, как я понял, нужна активная серверная часть для такой схемы. Протокол, по которому работает VS Code, позволяет отсылать и всякие подсказки, дополнения кода и прочее.
Здравствуйте, ·, Вы писали:
·>bisect можно и удалённо в ssh-сессии запустить, и локально. Впрочем да, не особо удобно. Хотя вроде gui тут не нужен, и не очень-то поможет.
Не, гуй не нужен. Но рассинхронизация дерева тут и дерева там неизбежна.
·>А... Может через sshfs попробовать? Для одного файлика вполне терпимо.
Конфиг (100кб) сохраняется 15 секунд (и блочит vim). Вау. Лучше уж rsync, жалкие 3 секунды или scp (4 секунды).
Между рабочей станцией и сервером 30мбит, но 220мс пинг. На сервере git репозиторий ядра линукса. Везде linux. Ищется возможность работать с git с комфортом, т.е. gitk и git citool. Как народ решает проблему?
Когда пинг 10мс, x-forwarding работает супер. Когда пинг 220мс, только первое окно открывается минуту. Шарить файловую систему оттуда на мой комп и запускать локально — gitk будет запускаться час. Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза, держать всё локально нельзя, потому что тестовое железо "там" и там же билдсервер с 200+ потоков.
Сейчас я хожу по ssh (220мс кое как хватает) и для браузенья по репо использую tig, а для коммитов git add -i, но это убогие копии gitk и git citool. vim fugitive годится только для "Gblame".
Чем народ пользуется нынче? Нет ли способа разогнать X? Суперотзывчивости не надо. Может, из wayland как то можно что то вытянуть?
Здравствуйте, netch80, Вы писали:
aik>>Когда пинг 10мс, x-forwarding работает супер. Когда пинг 220мс, только первое окно открывается минуту. N>Сжатие на X Forwarding включал? (типа ssh -XYC)
А то, не помогает вообще. Даже хуже, на самом деле, и в районе 100мс такая же фигня. Ну, окно открывается полминуты, а не минуту. Там, я так понимаю, много маленьких пакетов передается, и, вероятно, X просто неизлечим.
Может, есть всё таки консольные, но уже человеческие оболочки для гита?
Здравствуйте, aik, Вы писали:
aik>Когда пинг 10мс, x-forwarding работает супер. Когда пинг 220мс, только первое окно открывается минуту. Шарить файловую систему оттуда на мой комп и запускать локально — gitk будет запускаться час. Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза, держать всё локально нельзя, потому что тестовое железо "там" и там же билдсервер с 200+ потоков.
Так локально редактируйте (в vim) и все изменение пуште туда. А там поставьте jenkins или gulp и пусть собирает и тестит.
Здравствуйте, aik, Вы писали:
aik> Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза
Откуда там тормоза?
Это, имхо, самое быстрое должно быть, т.к. шлются только изменённые файлы, размер репы значения не имеет. Типичный push должен быть несколько секунд, даже с таким пингом, т.к. там туда-сюда запросов не так много.
Здравствуйте, ·, Вы писали:
aik>> Гонять постоянно git pull/push из-за каждого изменения — тоже тормоза ·>Откуда там тормоза? ·>Это, имхо, самое быстрое должно быть, т.к. шлются только изменённые файлы, размер репы значения не имеет. Типичный push должен быть несколько секунд, даже с таким пингом, т.к. там туда-сюда запросов не так много.
Да понятно, но возникает организационная проблема. Вот у меня репа, в ней 5 worktree, это мне надо и тут, и там вызвать одни и те же команды чтоб деревья совпадали и последующие push были быстрыми. Если я удалил worktree тут — хорошо бы удалить и там (ну, остальное git gc подберёт). Это всё геморои. Ну можно и так, конечно.
Мне непонятно другое — иксы же выдумали при царе горохе и модемах на 2400, т.е. оно как то работало тогда, чего оно такое тормозное сегодня? gtk что ли виноват?
Здравствуйте, aik, Вы писали:
aik>Мне непонятно другое — иксы же выдумали при царе горохе и модемах на 2400, т.е. оно как то работало тогда, чего оно такое тормозное сегодня? gtk что ли виноват?
Иксы можно использовать совершенно по-разному.
Стиль, который был в начале их использования, катастрофически отличается от того, что сейчас. Сложность виджетов выросла на порядки. Плотность обмена данными — тоже. Была предзакачка изображений и в основном умное их кэширование, сейчас это меньше используется. Полная перерисовка со стороны программ по каждому чиху. Это только навскидку.
99% оптимизируют локальное использование и просто не думают про удалённое.
Здравствуйте, aik, Вы писали:
aik> ·>Откуда там тормоза? aik> ·>Это, имхо, самое быстрое должно быть, т.к. шлются только изменённые файлы, размер репы значения не имеет. Типичный push должен быть несколько секунд, даже с таким пингом, т.к. там туда-сюда запросов не так много. aik> Да понятно, но возникает организационная проблема. Вот у меня репа, в ней 5 worktree, это мне надо и тут, и там вызвать одни и те же команды чтоб деревья совпадали и последующие push были быстрыми. Если я удалил worktree тут — хорошо бы удалить и там (ну, остальное git gc подберёт). Это всё геморои. Ну можно и так, конечно.
Как вариант — заскриптовать пачку команд...
Но в общем, более продуктивный подход тут уже упомянули — разрабатывать локально, тестировать-собирать через CI удалённо.
aik> Мне непонятно другое — иксы же выдумали при царе горохе и модемах на 2400, т.е. оно как то работало тогда, чего оно такое тормозное сегодня? gtk что ли виноват?
Ну графику передавать туда-сюда всегда небыстро, тем более с таким пингом, будешь управлять как марсоходом. А 2400 это ширина канала, полагаю пинг не самый плохой был, да и привык ты уже к хорошей жизни, во времена модемов тормоза были более привычными.
Здравствуйте, ·, Вы писали:
aik>> Да понятно, но возникает организационная проблема. Вот у меня репа, в ней 5 worktree, это мне надо и тут, и там вызвать одни и те же команды чтоб деревья совпадали и последующие push были быстрыми. Если я удалил worktree тут — хорошо бы удалить и там (ну, остальное git gc подберёт). Это всё геморои. Ну можно и так, конечно. ·>Как вариант — заскриптовать пачку команд...
Да уже. Но скриптовать надо как то дофига и как то стрёмно трогать текущее дерево в гит. Вот ядро — собирается out-of-tree и сырцы я не меняю, но меняю конфиг, который не в git потому что в другой папке. Т.е. это "git add -u && git commit -m building && git push -f blabla:~/linux && git reset HEAD^" и сверху ещё "rsync blabla-build/.config blabla:~/blabla-build/". Т.е. ssh надо 3 раза запускать — третий раз уже для make. Ну, ssh пишут сердобольные, новый коннект быстр c ControlMaster, но всё таки.
aik>> Мне непонятно другое — иксы же выдумали при царе горохе и модемах на 2400, т.е. оно как то работало тогда, чего оно такое тормозное сегодня? gtk что ли виноват? ·>Ну графику передавать туда-сюда всегда небыстро, тем более с таким пингом, будешь управлять как марсоходом.
В консоли это далеко не так больно, однако. И в браузере если открыть KVM до сервака — тормозит, конечно, но отклик типа 1-2 секунды, а не минута. RDP тот же вполне вменяемо работает, VNC похуже, но всё равно раз в 10 быстрее иксов.
Здравствуйте, aik, Вы писали:
aik> ·>Как вариант — заскриптовать пачку команд... aik> Да уже. Но скриптовать надо как то дофига и как то стрёмно трогать текущее дерево в гит. Вот ядро — собирается out-of-tree и сырцы я не меняю, но меняю конфиг, который не в git потому что в другой папке. Т.е. это "git add -u && git commit -m building && git push -f blabla:~/linux && git reset HEAD^"
Можно просто новые коммиты создавать, потом сквошнешь|заребейзишь. Ну или "commit --amend".
aik>и сверху ещё "rsync blabla-build/.config blabla:~/blabla-build/".
Ну можно конфиг в сорцы закинуть временно, и линкнуть в нужное место.
aik>Т.е. ssh надо 3 раза запускать — третий раз уже для make. Ну, ssh пишут сердобольные, новый коннект быстр c ControlMaster, но всё таки.
Может make из post-receive хука триггерить?
aik> ·>Ну графику передавать туда-сюда всегда небыстро, тем более с таким пингом, будешь управлять как марсоходом. aik> В консоли это далеко не так больно, однако. И в браузере если открыть KVM до сервака — тормозит, конечно, но отклик типа 1-2 секунды, а не минута. RDP тот же вполне вменяемо работает, VNC похуже, но всё равно раз в 10 быстрее иксов.
Ну да... Иксы похоже не по для того используют, для чего изначально проектировали.
Здравствуйте, ·, Вы писали: aik>> Да уже. Но скриптовать надо как то дофига и как то стрёмно трогать текущее дерево в гит. Вот ядро — собирается out-of-tree и сырцы я не меняю, но меняю конфиг, который не в git потому что в другой папке. Т.е. это "git add -u && git commit -m building && git push -f blabla:~/linux && git reset HEAD^" ·>Можно просто новые коммиты создавать, потом сквошнешь|заребейзишь. Ну или "commit --amend".
Гы. Вот понадобилось git bisect сделать. Это уже не коммиты создавать надо, а ssh blabla git -C blabla-src checkout $(git show --format=%h). Жить гораздо проще когда всё в одном месте.
aik>>и сверху ещё "rsync blabla-build/.config blabla:~/blabla-build/". ·>Ну можно конфиг в сорцы закинуть временно, и линкнуть в нужное место.
Так ведь он же там изменится и его надо назад скопировать, чтоб редактировать актуальную копию.
aik>>Т.е. ssh надо 3 раза запускать — третий раз уже для make. Ну, ssh пишут сердобольные, новый коннект быстр c ControlMaster, но всё таки. ·>Может make из post-receive хука триггерить?
Мне надо получить вывод от make сразу, чтоб по ошибкам ходить. Хуки так могут? Хотя пофиг, +1 коннект это ерунда.
Здравствуйте, aik, Вы писали:
aik> aik>> Да уже. Но скриптовать надо как то дофига и как то стрёмно трогать текущее дерево в гит. Вот ядро — собирается out-of-tree и сырцы я не меняю, но меняю конфиг, который не в git потому что в другой папке. Т.е. это "git add -u && git commit -m building && git push -f blabla:~/linux && git reset HEAD^" aik> ·>Можно просто новые коммиты создавать, потом сквошнешь|заребейзишь. Ну или "commit --amend". aik> Гы. Вот понадобилось git bisect сделать. Это уже не коммиты создавать надо, а ssh blabla git -C blabla-src checkout $(git show --format=%h). Жить гораздо проще когда всё в одном месте.
bisect можно и удалённо в ssh-сессии запустить, и локально. Впрочем да, не особо удобно. Хотя вроде gui тут не нужен, и не очень-то поможет.
aik> aik>>и сверху ещё "rsync blabla-build/.config blabla:~/blabla-build/". aik> ·>Ну можно конфиг в сорцы закинуть временно, и линкнуть в нужное место. aik> Так ведь он же там изменится и его надо назад скопировать, чтоб редактировать актуальную копию.
А... Может через sshfs попробовать? Для одного файлика вполне терпимо.
aik> aik>>Т.е. ssh надо 3 раза запускать — третий раз уже для make. Ну, ssh пишут сердобольные, новый коннект быстр c ControlMaster, но всё таки. aik> ·>Может make из post-receive хука триггерить? aik> Мне надо получить вывод от make сразу, чтоб по ошибкам ходить. Хуки так могут? Хотя пофиг, +1 коннект это ерунда.
Да, этот хук выполняется в удалённом репо и отправляет свой вывод назад и ты видишь всё через вывод команды push.
и пусть собирает и тестит.
