Gnome 3.18 geeft direct toegang tot Google Drive-files

De aanstaande uitgave van de opensource-desktopomgeving Gnome 3.18 krijgt waarschijnlijk native Google Drive-ondersteuning. Een werkende internetverbinding is hierbij wel nodig omdat de functie niet werkt als een echte Linux-client voor Drive.

Dat schrijft Omg Ubuntu naar aanleiding van de release-notes van de aanstaande Gnome-versie. Google zegt al sinds de komst van Google Drive-support voor Windows en Mac dat het een echte Linux-client zal uitbrengen, maar dat is vooralsnog niet gebeurd. De ondersteuning voor Google Drive in de bestandsverkenner Nautilus zal dan ook afhangen van een werkende internetverbinding. Dat laatste is nodig, omdat de bestanden niet lokaal gesynchroniseerd worden. Veel andere online opslagdiensten voorzien wel in lokale synchronisatie als het om op Linux gebaseerde omgevingen gaat. Mogelijk voegt het ontwikkelteam van Gnome dat voor Drive nog toe in de toekomst.

Google Drive wordt geladen in de zijbalk van Nautilus als een bestandssysteem op afstand. Dit gaat automatisch als een Google-account aan de Gnome online-accounts wordt toegevoegd. Acties via de drive werken net zoals bij andere netwerkdrives en de bestanden laden gewoon alsof ze in een lokale map zitten en met thumbnails. Het toevoegen van bestanden werkt gewoon zoals binnen Nautilus door middel van kopiëren en plakken of slepen. Drive-specifieke files, zoals Documents en Spreadsheets worden automatisch in de standaardbrowser geopend.

De functie maakt gebruik van Google Drive api v2. Ondanks dat het nog steeds niet ideaal is in vergelijking met native clients, zoals Dropbox en Copy.com die wel aanbieden, is het voor Drive-grootgebruikers een prettige toevoeging, al zijn er al meerdere externe applicaties waarmee een vergelijkbare functionaliteit voor Drive wordt toegevoegd.

Gnome 3.18 komt 23 september uit. Er zit wel een addertje onder het gras, meldt Omg Ubuntu: het kan nog gebeuren dat de feature niet in de uiteindelijke versie van de desktopomgeving terechtkomt.

Reacties (45)

[Anoniem: 579177]

"al zijn er al vele externe applicaties waarmee een vergelijkbare functionaliteit voor Drive wordt toegevoegd".
Zo veel zijn er niet. Grive-tools is voor zover ik ken de enige gratis versie met UI, maar deze is niet open source. De commandline versie Grive waar het op leunt overigens wel. En ik geef een derde closed-source partij liever geen onbeperkt toegang tot mn Drive... Ook de support is ruk, krijg geen enkele reactie op vragen aan The Fan Club.

Google predikt al een paar jaar dat ze werken aan een Drive client voor linux. Als ze dat al doen, dan wel met een heeeeeeel lage prioriteit.

[letatcest]

ja.. ik wacht ook al lang.. aan de andere kant werk ik bijna alleen nog maar in de browser, dus ik merk er steeds minder van.

Gebruikte lange tijd Jolicloud op mijn ouwe Netbook, dat had ook Google Drive-integratie die prima werkte, maar dat is al weer een tijd terug. Heb nooit de behoefte gevoeld een vaag extern programmaatje te gebruiken eigenlijk. Wat je zegt: liever geen rare derde partijen toegang geven.

[Anoniem: 579177]

Grappig dat je dat ook ervaart; sinds ik op Linux geen Google Drive client meer heb werk ik ook vrijwel alleen nog via de browser. Zo veel dat ik Drive op Windows ook heb gedeinstalleerd en ik mis het eigenlijk totaal niet.
(Het niet meer gebruiken op Windows had ook een andere reden; wanneer je na een half jaar of zo een Acronis of Clonezilla image terug zet met daarin een gekoppelde Google Drive ben je totally f*cked; honderden tot duizenden dubbele bestanden met verschillende datums en zoek maar uit wat de goede zijn...)

[robindemey]

Net daarom wss dat Google er geen werk meer van maakt. Heb zelf een iMac, maar gebruik niets van Apple software, gezien online minstens even handig is. Gmail, kalender, drive en docs in Chrome. Enkel voor andere bestanden gebruik ik nog de client (Photoshop, cad...).

[Rudy]

Handig maar erg zwaar voor je processor. 'native' is in deze context dan ook eerder 'standaard meegeleverd met gnome'.

[Dykam]

Hoezo zwaar voor je processor? Meer dan een beetje netwerk IO is het niet.

[Rudy]

Vergeet niet al die API calls. Een beetje google drive grootverbruiker heeft op zijn minst 1tb. Een zoek opdracht op die manier vreet CPU

[Robin H]

Een API-call is absoluut niet zwaar voor je CPU.
Gewoon een HTTPS-request sturen, iets anders doen, en dan de response tonen als foldertjes/bestandjes op het scherm.

En die resultaten komen écht snel aan hoor!
https://developers.google.com/drive/web/search-parameters

Edit:
Link toegevoegd naar het relevant stukje code.
Bestanden zoeken laat je volledig over aan Google

[Reactie gewijzigd door Robin H op 27 juli 2024 00:31]

[Rudy]

1 api call niet nee.. laten we het er maar op dat houden een bestandje zoeken in je fuse met slechts een https request per api call (dus niet per zoekopdracht), veel zwaarder is dan wanneer dat bestandje op je hard disk staat. Ik baseer mijn mening op mijn ervaring met http://gdfuse.forge.ocamlcore.org en met de aanname dat in dit nieuwsartikel hier ook over gerept wordt.

[Reactie gewijzigd door Rudy op 27 juli 2024 00:31]

[Robin H]

Je opent een map:

• API request naar google om de content van die map te vragen.
• CPU hoeft nu niets te doen
• API response ontvangen en omzetten naar foldertjes/directories

We spreken hier niet over een seconde.
Sprinkel er een beetje cache in zodat je vlot 'back' kunt en dit gaat heel vloeiend aanvoelen.

En over het zoeken:
Tja, als je gaat zoeken door eerst zelf een index te maken van alle directories en bestanden ( wat veel api-calls nodig heeft ) duurt het lang.
Véél beter is als je het zoeken overlaat aan Google en gewoon de resultaten toont.
Wist je trouwens dat Google standaard OCR toepast op je foto's en pdf's?
Op die manier kan je zelfs tekst zoeken die voorkomt in een foto en zal die foto opgenomen worden in de resultaten!

Edit:
Lijkt erop dat je het zoeken inderdaad niet zelf kunt efficiënt maken in fuse :-/

[Reactie gewijzigd door Robin H op 27 juli 2024 00:31]

[Rudy]

Met een file system in user space is het dus nou net zo dat je dat zoeken toch echt zelf moet doen ! Het werkt prima totdat je gaat praten over 100GB's. Je OS behandeld het als een filesystem als ieder ander en is niet aware dat het een Google Drive betreft. Verwacht geen magische functionaliteit die totaal niet past bij een file system, het gaat vies tegenvallen. LEES HET NIEUWSARTIKEL OP OMG UBUNTU

[Reactie gewijzigd door Rudy op 27 juli 2024 00:31]

[Robin H]

Heb er me net even in verdiept en denk dat je bedoelt dat het zoeken net iets is dat het OS zelf blijft doen.
Dus het OS gaat zelf op zoek naar het bestand in je fuse waardoor die tonnen API-calls moet maken.

Ik ging er vanuit dat je de search zelf moest implementeren waardoor je dit zo efficiënt mogelijk kon doen.

[goarilla]

Nee search, tree walking (find,grep,...) dat is iets wat de utilities zelf tewerkstelligen door de (g)libc calls getdents,stat,read,write,fstat,fseek, ... en hun resultaten aan elkaar te lijmen. En uiteindelijk zijn dat meestal direct 1 op 1 calls die de VFS serveert vanuit de filesystem specifieke implementaties (voor meer info: http://www.makelinux.net/books/lkd2/).

[Rudy]

Helaas. Tonnen API-calls inderdaad, heb er eens mee lopen stoeien op een raspberry pi 2 en na twee weken aanpoten compileren erachter komen dat de performance niet je van het is.

heb 't toen wel gevoeld

[tormentor1985]

Deze techniek gebruik de drive api v2. Zoals je https://developers.google.com/drive/web/search-parameters hier kunt lezen kan je met 1 query 1 zoekopdracht starten. Een zoekopdracht tussen een drive met een paar terrabyte aan data hoeft niet langer dan een paar milliseconde te duren.

[latka]

Als de implementatie dat dus gebruikt. Er wordt een beetje langs elkaar gepraat. Er zijn (grofweg) 2 mogelijke manieren om een remote filesysteem te maken:

1) Doe alsof het lokaal bestandsysteem is en lees de data van iedere file in als je die nodig hebt (voor zoeken naar een tekst betekent dit dus alles over de lijn halen. File voor file)

2) Doe iets heel slims en vertaal gebruikersacties (zoek woord in bestand) naar een functionele API call (niet LeesBestand, maar ZoekWoord). Dan gebeurt het zoeken op de server en krijg een lijstje van bestanden terug die het woord bevatten (die je dan op kunt halen).

1 is makkelijk (SMB/CIFS, NFS, AppleTalk) maar takketraag voor bepaalde zaken

2 is veel sneller maar ontzettend moeilijk (de API is veel groter dan die voor een file-share achtige oplossing) en door abstracties en verfijningen in de software is de gebruikers acties soms lastig te vertalen op 1 exacte API call en verval je weer in mode 1 die altijd werkt.

Fuse is een voorbeeld van optie 1, Google Drive in je browser is typisch optie 2.

[Dykam]

Duizende API calls, als die er al zijn, zijn alsnog niet zwaar. Je lijkt te missen dat een netwerk request minstens een factor 1000 langer duurt dan wat CPU werk om het aan te gang te krijgen. De CPU is vooral aan het wachten.

[halofreak1990]

Lijkt mij dat je als cloudprovider dan een lokale Db daarvoor inricht, zodat je niet miljoenen callbacks moet doen om even je cloud mapje te doorzoeken.
Of ben ik nu te vooruitstrevend?

[Rudy]

bij gdfuse is er wel sprake van een cache ja maar geen db. In het nieuwsartikel wordt ook gesproken over een file system. Iedereen hierboven die denkt dat een een bestandje zoeken met 1 api call lukt gaat bedrogen uitkomen wanneer ze het uitproberen in gnome 3.18

Zie nieuwsartikel: 'Although not a perfect solution it is a welcome one.'

[Reactie gewijzigd door Rudy op 27 juli 2024 00:31]

[goarilla]

Waarom, passeren fuse filesystems niet via de VFS en de dentry cache ? Of willen ze meer cachen ?

[Xudonax]

Dat lijkt mij relatief simpel, VFS e.d. zitten op kernel niveau terwijl FUSE geheel* in userspace draait. Dat is dan ook net de kracht ervan.

* want er zit wel een kernel extensie bij die dit geheel mogelijk maakt. De filesystems zelf draaien bij mijn weten volledig in userspace.

[goarilla]

Ik denk dat fuse nog altijd de VFS passeert, eg ipv traditioneel:
applicatie -> VFS -> filesystem
dus dit:
applicatie->VFS->FUSE->filesystem.
Fuse gebruikt in mijns inziens dus geen direct IO dat de VFS wel links laat.

[Rudy]

het is een cache file waarvan je zelf kunt instellen hoe groot die mag worden dacht ik. Verder gaat je vraag mijn pet ook te boven

[himlims_]

de tool lult met een api; die geeft (zoek)result terug; want de content staat bij google en niet op je lokale hdd. geloof dan ook neit dat je cpu daar zo druk mee is. wil je dat wel(en dus die TB's lokaal in je ~ frotten; https://github.com/odeke-em/drive

[Reactie gewijzigd door himlims_ op 27 juli 2024 00:31]

[Rudy]

kijk daar zit een verschil in. Het hangt dus van de implementatie af, jouw tool is een command line utility om bestanden aan te vragen. Ik heb het over een compleet filesystem.

[himlims_]

dat kan prima met die cli tool; je zet een sync aan op je root van gdrive;
wordt in lokaal mapje gezet.

zijn diverse UI's die gebruik maken van drive cli; en zo een gebruiksvriendelijke (dropbox-like) oplossing bieden

[sfranken]

Nee hoor. Ik heb het hier even getest (Fedora 23, development versie, met Gnome 3.17.x, wat 3.18 word). Ik heb m'n Google account gekoppeld in "Accounts", en dan komt er indedaad netjes in Nautilis een optie "[e-mail]" bij. Klik erop en hij word gemount. Daarna met een terminal het volgende gedaan:

$ find <pad naar google drive mount> -type f | wc -l
Dat resulteerde in 20.144 files. Daarna het volgende gedaan:

$ time find <pad naar google drive mount> -type f

En dat gaf het volgende terug:

Real: 0m0.403s
User: 0m0.021s
sys: 0m0.057s

Daarna hetzelfde gedaan met de Systeemmonitor open voor m'n CPU load. Die zag ik bij her uitvoeren van deze commando's niet stijgen.

[Cheap Apps]

Dit ziet er eerder uit als een ftp/sftp server. Als ik daar mee verbonden ben heb ik eigenlijk nergens last van en echt traag vind ik het niet, mijn HDD is langzamer.

[sfranken]

Dit gebruikt onderhuids dezelfde implementatie in GNOME ja. Ook Google Drive word een "extern FS".

[Rudy]

[bkor]

Dit is helemaal niet zwaar voor de processor zoals al eerder vermeld. Dit is een nieuwe backend voor gvfs. Bijna alles gebruikt gvfs al. Een nieuwe backend die wat netwerk IO doet maakt dingen niet opeens "zwaar". Nogal hetzelfde als b.v. de gvfs mtp backend (zodat je de bestanden op je telefoon kan zien). Verder spreken sommige mensen over b.v. FUSE, maar die extra laag wordt alleen gebruikt wanneer nodig.

Zou graag willen weten waar je dit "zwaar voor je processor" vandaan haalt. Als iemand die al 10+ jaar meehelpt met GNOME (maar ben geen ontwikkelaar) heb ik het idee dat je maar wat zegt.

[Rudy]

Kan maar zo. Ik gaf eerder al aan dat ik mijn mening baseerde op mijn ervaring met: https://github.com/astrada/google-drive-ocamlfuse en er vanuit ging dat het ook hierover ging in deze nieuwspost.

[Anoniem: 16328]

Je hebt toch https://www.insynchq.com/ als client? Kost iets van 15 dollar lees ik bij Ubuntu Blog.

[rxr1991]

Het belangrijkste is hoe het OS omgaat met de geïndexeerde files. Als het os de files ziet als een gemounte schijf, dan zou het OS de indexering doen en kost het niets meer of minder dan als ze lokaal zouden staan. In praktijk zijn het dan alleen symbolic links naar de files in de cloud.

Het enige wat hier spannend aan is, is de indexing actueel houden. Met folders die veel veranderen of waar veel gebruikers aanwerken zou je dus vaak je indexering opnieuw moeten doen. Als ze hier dus een handig trucje voor hebben bedacht is het probleem dus opgelost en is het niet echt anders dan lokaal. Het enige verschil is dat een bestand daadwerkelijk gebruiken wat meer resources kost. Ophalen, verwerken en presenteren maar goed, daar zijn de meeste hardware componenten al redelijkgoed geoptimaliseerd voor.

[simon stokvis]

De vereiste dat je internet verbinding moet hebben, en dat ie niet alles synchroniseert vind ik juist ideaal. Als ik 2 TB in de cloud heb opeslagen wil ik juist dat 'ie alles pas download als ik er op klik, ik wil de data niet op mijn laptop hebben. Sowieso is mijn HDD daar te klein voor.

Je zou dan kunnen zeggen dat je dan net zo goed de web interface kan gebruiken, maar gewoon via nautilus lijkt me eigenlijk wel ideaal met copy/paste e.d.

Ben sowieso nog steeds op zoek naar de juiste cloud voor mij. Heb de tijd niet om een eigen owncloud te draaien, zou wel graag encryptie willen, en het moet betrouwbaar zijn. Mega is goedkoop, maar heb ik niet zo'n betrouwbaar gevoel bij. Denk dat het toch maar SpiderOak wordt.

[Superstoned]

SpiderOak is een goede keuze, denk ik. Als je toch graag een web interface wilt en makkelijker wilt delen kun je ook een ownCloud provider kiezen, zie https://owncloud.org/providers

[Zjemm]

Als gebruiker hou ik zaken toch liever in mijn eigen cloud. Ik snap steeds minder goed dat mensen maar van alles aan Google toevertrouwen. Zekers ze maken enorm goede producten en het werkt ook allemaal fantastisch. Maar langzamerhand raak je steeds afhankelijker.

Los daarvan is gnome lekker op weg en word het steeds meer een vertrouwde omgeving waar lekker op te werken is. Houden ze het alleen bij Google drive of staan er meer op de lijst?

[Cranzai]

Intern wordt er bij google veel gebruik gemaakt van linux daarom vind ik het ook raar dat er niet al lang een Drive client is voor linux. Ik denk mij te herinneren dat ik een keer iets gelezen heb over een semi-sync client voor linux. Dit was een passief gesynchroniseerde map die ook bij google intern gebruikt werd. Google is een vooruitstrevend bedrijf met een open source mobiel os maar waarom is hun drive client er dan nog niet voor linux?!

[JonasDeMoor]

Dit vraag ik me ook al enige tijd af. Heb gehoord dat werknemers bij Google gebruik maken van ChromeOS en een variant van Ubuntu. Waarom ze geen Drive client uitbrengen voor Linux , blijft mij ook een raadsel.

[Anoniem: 579177]

Google heeft er geen enkel belang bij om een Drive client voor ChromeOS uit te brengen; het is een OS waarop je niets kunt installeren en alles via de (Chrome) browser doet. Google wil jouw bestanden graag en primair in hun cloud houden . Daarnaast ondersteunt ChromeOS offline Drive bestanden, net als op Android, dus dat maakt het nog meer overbodig.

[Eloy]

Na lange tijd geen GNOME gebruiker te zijn geweest ben ik sinds een tijdje weer terug. GNOME is goed bezig als ze doorgaan met dit soort ontwikkelingen!

[Roel911]

Ik gebruik momenteel KDE, wat zijn de voordelen van Gnome tov KDE?

[hiekikowan]

Standaard ondersteuning voor Google Drive (vanaf versie 3.18)...

Specifieke voordelen zijn er niet, dit is geheel afhankelijk wat je van je desktopomgeving verwacht. Zelf vind ik eyecandy minder belangrijk, performance des te meer, dus gebruik ik XFCE. Qua eye-candy zit je met zowel Gnome als KDE wel goed, De consistentie is bij beide omgevingen ook prima geregeld dus dat is ook niet echt meer een argument.

Wil je gerichter advies, zul je toch meer informatie over je wensen/eisen moeten geven...

[Superstoned]

Troll poging of serieuze vraag? Als het een troll poging was is ie wel heel mooi mislukt ;-)

Als het een serieuze vraag is - bdalenoord gaf een mooi antwoord. Gewoon uitproberen zou ik zeggen.

[Anoniem: 695774]

Gelukkig gebruik ik geen GNOME, ben een blije i3 user