Není problém si to tam doplnit, já to tak dělám na DropBoxu pomocí EncFS. Je to rozhodně důvěryhodnější řešení než svěřit citlivá data nějaké uzavřené aplikaci, která bude tvrdit, že je před odesíláním na server velmi bezpečně šifruje.
To su dve neporovnatelne veci. encfs sluzi na samotne sifrovanie dat na strane klienta a ssh/sftp je API na vzdialeny pristup k nejakym suborom.
Stale nechapem preco ma kazdy potrebu vymyslat nove API na komunikaciu, ked uz tu mame dost dlho stabilne a funkcne veci typu SSH ci SFTP na prenos suborov. A je to de facto standard.
Lebo ten google super-duper klient pre windows vyuziva API ktore je "stavane" na aktivnu synchronizaciu priecinka C:\Documents s googlom? Je fakt taky problem urobit aplikaciu ktora bude robit to iste cez ssh (alebo rovno pouzit rsync cez ssh?) ci cez SFTP?
Samozrejme, ze nie a verim, ze aj menej zdatni programatori co navstevuju root su to schopni si nakodit...
Ale dovod preco este nie je ziaden funckny google drive klient pre linux? Kto by ho a pre koho robil???
Nech idu dakam s tym drive... Da sa hlasovat v tej "peticii" aj proti?
Ako som pisal, v tomto pripade SSH tvori API akym server komunikuje. SSH je standardizovany protokol (v nejakom RFC) a viac aplikacii podporuje protokol SSH ako nejaky proprietarny protokol dropboxu. Naco treba vymystal dalsie API na prenos suborov medzi klientom a serverom, ked uz tu mame dlho pouzivane SFTP ktore funguje a je podporovane aplikaciami? Aplikacie takto musia implementovat dalsi komunikacny protokol na prenos suborov naviac...
Právě jste se trefil: Proč neposkytuje Google a další firmy daný prostor přes např. SFTP, když jsou to takoví samaritáni, ale svoje uzavřené řešení (Drive, Dropbox, ...) a ještě jste jim za to vděčný, že ten klient pro vás vyrobí??? Přitom jde o ten samý prostor. Asi za to něco chtějí, ne?