> ага, ясно. У меня всё проще было - encfs -r и несколько
> софтин, синхронизирующих это с разными облаками.
> Насчёт извращений -  имелось в виду, что ничего в хомяк не
> тащит, в отлииче от.
> Вот ещё нагуглил ради интереса https://github.com/odeke-em/drive - потыкал палочкой,
> вроде работает... С моей точки зрения плюс в том, что в
> код на go я хоть залезть и что-то понять/подкрутить могу (да
> и почти любой из здешних обитателей может), в отличие от OCaml.

Это тоже построено на идее хранить локальную копию гуглодрайва и синхронизировать её с remote. В том смысле, что если я хочу подправить какой-нибудь файлик на гуглодрайве, мне придётся сначала скачать содержимое гуглодрайва (выполнить pull), внести все изменения, а потом синхронизировать обратно (выполнить push).
fuse-драйвер делает всё это сам. Причём сугубо по мере необходимости: если я не обращюсь к файлу, то файл не скачивается. Такая штука как гуглодрайв в моей системе представлена как файловая система, а уж как с ней работать и как одолевать data races -- я сам определюсь. У меня тут coreutils под рукой, и ещё дерево портажей в /usr/portage/.

Ну и да, go не сильно-то лучше ocaml'а в плане "не тащить ничего в хомяк". У go тоже свой пакетный менагер -- gpm, -- и если нет ебилдов, то придётся тащить в $HOME и само приложение, и депендансы к нему. Если есть ебилды, то они отстают от реальности не менее чем на полгода, а скорее даже больше, причём в случае go и прочих не очень популярных но быстро эволюционирующих вещей, все эти ебилды помечены кейвордом ~amd64, несмотря на отставание от реальности. Чтобы написать свои ебилды надо разобраться с пакетным менагером и научиться им пользоваться. Проще взять install guide к софтине, вогнать две-три команды в шелл, и начать пользоваться этой софтиной, чем превозмогать.

На правах оффтопа. Я вообще подозреваю, что пришла пора расслабиться в отношении "устанавливать в хомяк", прекратить сопротивление и попытаться получать удовольствие. Линуксовые дистрибутивы вваливаются в конкретный кризис, они не поспевают за реальностью и они не готовы меняться, приспосабливаясь к этой реальности.[1] Программисты разрабатывают пакетные менагеры под себя (gem, pip, opam, gpm, cargo...), потому что системные пакетные менагеры не справляются с теми задачами, которые нужны программистам. Сисадмины решают проблемы своим способом -- плодят контейнеры. Юзеры просто используют Steam, который ставит игры в $HOME, и не парятся по этому поводу. Системные пакетные менагеры же продолжают тащить на себе традиции и духовность, вместо того, чтобы конкурировать с тенденциями. Они проиграют, если не одумаются.

[1] https://blog.flameeyes.eu/2017/06/distributions-becoming-irr.../