Google vervangt Google Drive op desktop per abuis door onaangekondigde dienst

Google lijkt met een foutieve update de komst van een nieuwe versie van back-updienst Drive te hebben verklapt. Gebruikers meldden dat zij software met de naam Backup and Sync op hun computer zagen verschijnen, al lijkt deze nog niet te functioneren.

Meldingen van Backup and Sync verschenen onder meer op de ondersteuningsfora van Google. Verscheidene gebruikers lieten daar weten de software automatisch op hun pc te hebben gekregen. Daarbij wordt echter een foutmelding getoond waarna de software afsluit. Dat komt waarschijnlijk omdat Google de software nog niet heeft geactiveerd op zijn servers.

Waarschijnlijk ligt een foutieve update ten grondslag aan het plotselinge verschijnen van Backup and Sync. Per abuis werd de bestaande Google Drive-applicatie op de desktop overschreven door een niet-werkende versie van Backup and Sync. Uit meldingen die de software geeft, blijkt ook dat de software niet bedoeld is voor een release voor het grote publiek.

Google heeft in een reactie erkend dat het om een fout gaat, en dat de Drive-software met een update zal worden hersteld. Inmiddels zou de back-updienst bij sommige gebruikers alweer moeten zijn hersteld. Over de nieuwe Backup and Sync-dienst werd echter niets gezegd; het lijkt erop dat dit de opvolger moet worden van Drive, maar details komen waarschijnlijk pas nadat Google de software officieel beschikbaar maakt.

Reacties (67)

[Barsonax]

Dat is dan weer een nadeel van continuous deployment. Het deployen word zo makkelijk dat het per ongeluk kan gebeuren XD.

[supersnathan94]

Deployment naar productie mag nooit geautomatisserd zijn dusdanig dat dit niet handmatig wordt geactiveerd.

Deze software had nooit zomaar in productie kunnen komen als de test en acceptatie omgeving hun werk hadden gedaan.

Daarnaast is dit project een hele andere repository. Dat krijg je niet zomaar door elkaar.

Vooralsnog verdenk ik een persoon die per abuis de verkeerde updates heeft gestaged in de update deployment tool. Dat moet dus handmatig gebeurt zijn want een CI omgeving ziet bijvoorbeeld aan het versie nummer al dat het niet klopt.

[ANdrode]

Deployment naar productie kan prima geautomatiseerd zijn

Waneer je aan staged roll-outs doet kan je geen harde lijn meer trekken tussen de releases en acceptatie builds.

Op deze schaal is de "software tester" rol gelukkig weer geautomatiseerd. Fouten en problemen komen voor, het gaat er om dat ze niet teveel gebruikers raken. Dat doe je door geautomatiseerde testen en eerst maar een klein deel uit te rollen.

[supersnathan94]

Waarom is er dan geen enkele alarmbel gaan rinkelen?

Het is een kompleet ander stuk software, met een kompleet losstaande repo (dat kan bijna niet anders), andere versienummering en een andere naam.

Die vier dingen zouden CI tools direct zien. Ook een groot verschil in bestanden/code wordt opgemerkt. Zoiets kan niet zomaar een minor update zijn.

Hier is eht wel meer aan de hand dan een falende CI omgeving.

[gjmi]

Een CI tool hoeft niet alles te zien. Je kunt van alles automatiseren ook dat een CI tool dit gewoon accepteerd. Het is zeer waarschijnlijk de bedoeling dat die in de toekomst wel een keer op deze manier gebeurt. Misschien was iemand een script aan het testen die juist hiervoor geschreven was. Echter komt er dan een handeling aan pas van iemand om de goede namen en versies in te vullen. Dat kan heel goed mis zijn gegaan.

[ANdrode]

Ik zeg niet dat het alleen een falende CI omgeving is

Het is een logische vervolgstap op Drive. Dit wil je naar een kleine groep testers (mogelijk: zelfs interne alpha) uitrollen.

Dat doe je met dezelfde tools als waar je normaal "nieuwe" releases uitrolt. Daarin is een foutje zo gemaakt ("x% van live naar nieuwe pakket" ipv "x% van intern-alpha"). Als je zoveel deliverables hebt als Google gaat dat jaarlijks een paar keer mis

[Verwijderd]

ITT: mensen die er heftig op los speculeren en aannames doen, zonder enkele inzicht in de systemen van Google te hebben.

[supersnathan94]

Hoezo? De systemen van google mbt workflow en code deployment staan uitgebreid op internet gedocumenteerd.

[nullbyte]

Als het automatisch gaat, dan was dat net als bij vorige updates gewoon goed gegaan, dat is het niet dus, een menselijke fout.

[JeroenB89]

Daarnaast is dit project een hele andere repository. Dat krijg je niet zomaar door elkaar.

Alhoewel je uiteindelijk natuurlijk wel gelijk hebt en je twee producten niet zomaar door elkaar zult kunnen halen, is wat je hier zegt toch niet helemaal waar.

Zie ook dit artikel: http://m.cacm.acm.org/mag...ingle-repository/fulltext

[supersnathan94]

Dezelfde codebase betekent niet dat het ook dezelfde directory is.

Google has an automated testing infrastructure that initiates a rebuild of all affected dependencies on almost every change committed to the repository. If a change creates widespread build breakage, a system is in place to automatically undo the change. To reduce the incidence of bad code being committed in the first place, the highly customizable Google "presubmit" infrastructure provides automated testing and analysis of changes before they are added to the codebase. A set of global presubmit analyses are run for all changes, and code owners can create custom analyses that run only on directories within the codebase they specify. A small set of very low-level core libraries uses a mechanism similar to a development branch to enforce additional testing before new versions are exposed to client code.

Zomaar deployen vanuit een andere directory kan bijna niet automatisch. Er zijn zoveel pre commit checks en geautomtiseerde rollbacks in de CI omgeving dat dit wel handmatig gedaan moet zijn.

[Mr777]

Of het is gewoon opzettelijk om de gebruikers alvast warm te maken voor de nieuwe dienst die eraan komt. Zeggen dat iets "per abuis" gebeurt of laten weten dat iets "uitgelekt" is, is een prima manier om de nieuwsgierigheid wat te prikkelen. De marketingjongens schuwen geen enkele leugen of psychologische truuk om je aandacht te kapen, dat weten we al langer dan vandaag.

[Blokker_1999]

Je gaat niet opzettelijk de dienstverlening verstoren en gebruikers in de problemen brengen om onaangekondigde software te hypen.

[1nsane]

Je zou het haast wel denken. Op mijn werk doen we ook aan continuous integration and deployment en hoewel we ook met regelmaat iets stuk maken in productie, zo'n omzetting is wel behoorlijk en dat zouden we niet zomaar deployen zonder dat het af is.

[Rataplan_]

Niet? How about het gedoe met Google Chrome en QUIC gisteren? Net zo'n ongecontroleerde actie die veel problemen veroorzaakte.

[Neko Koneko]

Niet? How about het gedoe met Google Chrome en QUIC gisteren? Net zo'n ongecontroleerde actie die veel problemen veroorzaakte.

Google is inderdaad lekker bezig momenteel

[kane_sting]

Ja precies. Ik werk dagelijks met Microsoft software en merk ook dat daar wel eens iets onaangekondigd kan verschijnen. Zoals laatst kwamen een aantal nieuwe webparts tevoorschijn in SharePoint Online. Toen we Microsoft hierover informeerde stonden die ook te kijken dat de webpart online was gekomen. Paar dagen later kwam er weer eentje voorbij:P

[Verwijderd]

Bij Microsoft werken ze veel met feature flags, in ieder geval voor visual studio online. Dus iedereen heeft de nieuwste bits, alleen niet alle code paden zijn voor iedereen beschikbaar.

Kan best dat dit hier ook fout is gegaan. Code deployed, alleen feature flags stonden niet goed. Misschien werken ze bij Google wel met compiler flags en was daar een fout.

[stijnos1991]

Google wordt veel te groot. De stabiliteit die er ooit was is er al tijden niet meer. Te vaak storingen van allerlei diensten.. Je merkt nu pas hoe enorm afhankelijk je eigenlijk bent van Google.

[Reactie gewijzigd door stijnos1991 op 24 juli 2024 06:18]

[dakathefox]

Sinds wij zijn overgestapt van Microsoft naar Google is de downtime gereduceerd tot praktisch nul. Ik weet niet waar jouw stelling vandaan komt, maar ik merk er weinig van.

[vali]

Tja, maar je gaat er op andere punten wel flink op achteruit. Jij hebt als bedrijf geen invloed waar je data wordt opslagen aangezien bij Google het verspreid wordt over de gehele wereld. Bij Microsoft en andere public Cloud diensten heb je dit niet. Maar dat wist jij lijkt mij wel toen je de overstap naar Google ging maken.

Laat er nou flink wat landen zijn waar ze niet zo nou met privacy omgaan... En dat om iets minder down-time? Tevens is 0 procent downtime onmogelijk. Het kan zijn dat jij het niet door hebt, maar ze zijn er wel tegelijk bij Google.

Mijns inziens is het fegenwoordig slimmer om je dienst tussen verschillende public en/of private Cloud diensten te verspreiden. Dat is de enige manier om downtime tegenwoordig zo laag mogelijk te houden. Zeker als je een grote complexe omgeving beheerd.

[Reactie gewijzigd door vali op 24 juli 2024 06:18]

[kristofv]

Als je als bedrijf een cloud opslag dienst aanbiedt aan je end users ( box dropbox onedrive for business whatever) is het in de praktijk veel te duur (en bovendien niet te managen) om een andere cloud opslag dienst als DR/backup te gebruiken.

En dan zwijgen we nog maar over de gebruiksvriendelijkheid voor de end user, het is al moeilijk genoeg om uitgelegd te krijgen hoe één cloud opslagdienst werkt, laat staan dat ze er nu ineens 2 verschillende voorgeschoteld krijgen.

Als je in een bedrijf volledig redundante HA file sharing wil aanbieden zit je toch echt wel vast aan een meer traditioneel smb/cifs model naar mijn mening

[vali]

Als je als bedrijf een cloud opslag dienst aanbiedt aan je end users ( box dropbox onedrive for business whatever) is het in de praktijk veel te duur (en bovendien niet te managen) om een andere cloud opslag dienst als DR/backup te gebruiken.

Wie zegt dat ik heb het over diensten zoals Dropbox en OneDrive?

Als je in een bedrijf volledig redundante HA file sharing wil aanbieden zit je toch echt wel vast aan een meer traditioneel smb/cifs model naar mijn mening

Nee hoor dat zit je niet. Er zijn genoeg andere oplossingen alleen moet je dan wat verder denken dan hier op tweakers wordt geposted. Denk bijvoorbeeld aan een Openstack omgeving draaiend over verschillende Cloud diensten i.c.m. owncloud. Waar denk je dat Google en Microsoft hun data opslaat? Die maken allemaal gebruik van dezelfde technieken.

En dan zwijgen we nog maar over de gebruiksvriendelijkheid voor de end user, het is al moeilijk genoeg om uitgelegd te krijgen hoe één cloud opslagdienst werkt, laat staan dat ze er nu ineens 2 verschillende voorgeschoteld krijgen.

Daarom is er tot heden voor een IT-bedrijf altijd werk Ook is duur een woord wat per bedrijf/persoon kan verschillen. Paar ton investering kan voor jou heel veel zijn, maar voor gemiddeld bedrijf is dat niks. Paar minuten/uren downtime kan zo flink wat meer kosten dan de investering van een goede IT-omgeving

[Reactie gewijzigd door vali op 24 juli 2024 06:18]

[kristofv]

Nee hoor dat zit je niet. Er zijn genoeg andere oplossingen alleen moet je dan wat verder denken dan hier op tweakers wordt geposted. Denk bijvoorbeeld aan een Openstack omgeving draaiend over verschillende Cloud diensten i.c.m. owncloud. Waar denk je dat Google en Microsoft hun data opslaat? Die maken allemaal gebruik van dezelfde technieken.

Dan kom je terug op die "veel te duur" , natuurlijk kan het wel, maar die rekening zal behoorlijk snel aantikken. Niet enkel wat cloud betreft, ook wat manuren betreft naar je personeel + eindgebruikers toe. Reken maar eens uit wat enkel en alleen de owncloud licenties je al kost.

Als je budget ongelimiteerd is (zoals bij die spelers die je opnoemt) dan kan het allemaal vlotjes natuurlijk.. the sky is the limit.

Maar dat geef je zelf ook al aan..

[vali]

Dan kom je terug op die "veel te duur" , natuurlijk kan het wel, maar die rekening zal behoorlijk snel aantikken. Niet enkel wat cloud betreft, ook wat manuren betreft naar je personeel + eindgebruikers toe. Reken maar eens uit wat enkel en alleen de owncloud licenties je al kost.

Dat valt wel mee hoor, het heeft allemaal met investeren te maken als bedrijf die de diensten gaat aanbieden. Hoe denk je dat Stack zo goedkoop kan zijn? Of Cloud vps met hun omgeving? Die maken ieder gebruik van dezelfde technieken.

[Reactie gewijzigd door vali op 24 juli 2024 06:18]

[kristofv]

Ik bekijk het vanuit een intern bedrijfsplatform perspectief, niet met het oog op het verder aanbieden als dienst naar betalende klanten toe

Dat is een compleet ander gegeven natuurlijk, daar valt overduidelijk wel nog iets mee te verdienen

[vali]

Van die kant kan je het uiteraard ook bekijken. Zelf heb ik meegewerkt met een project waar we een flinke openstack omgeving hadden opgezet om dit aan klanten aan te bieden. Kan je verzekeren, er is genoeg vraag naar.

Als je tientallen Terabytes aan data hebt wil je dit altijd kunnen bereiken en niet door zo'n knullige blunder van Google even niet kunnen benaderen.

[Reactie gewijzigd door vali op 24 juli 2024 06:18]

[kristofv]

Je zal de openstack omgeving van CERN vast wel leuk vinden dan , daar val je echt van omver wat pure omvang betreft

[vali]

Haha ja, echt een droom van iedere IT-er (tenminste die van mij in ieder geval) om daar aan mee te werken.

[dakathefox]

Tja, maar je gaat er op andere punten wel flink op achteruit. Jij hebt als bedrijf geen invloed waar je data wordt opslagen aangezien bij Google het verspreid wordt over de gehele wereld.

Het wordt dusdanig gefragmenteerd opgeslagen dat ik dit een minder zwaarwegend argument vindt. Ik kan me echter wel voorstellen dat anderen dit wel een zwaarwegend argument vinden.

En dat om iets minder down-time? Tevens is 0 procent downtime onmogelijk. Het kan zijn dat jij het niet door hebt, maar ze zijn er wel tegelijk bij Google.

Inderdaad. De uptime die Google biedt in haar SLA is 99.9%, inclusief gepland onderhoud. Microsoft biedt 99.9% exclusief gepland onderhoud. En in de oude situatie zaten we vaak rond de 92-95% uptime, inclusief gepland onderhoud.

[vali]

Het wordt dusdanig gefragmenteerd opgeslagen dat ik dit een minder zwaarwegend argument vindt

Dat kan wel zijn, maar de grip is er nog steeds niet. Je data kan dus "gefragmenteerd" in Amerika zijn opgeslagen.

Inderdaad. De uptime die Google biedt in haar SLA is 99.9%, inclusief gepland onderhoud. Microsoft biedt 99.9% exclusief gepland onderhoud. En in de oude situatie zaten we vaak rond de 92-95% uptime, inclusief gepland onderhoud.

Daarom moet je ook niet afhankelijk zijn van 1 Cloud aanbieder, dan had je geen last gehad van hun geplande onderhoudt. Al kan ik mij niet voorstellen dat ze bij hun tientallen datacenters tegelijk onderhoud plegen.

[Reactie gewijzigd door vali op 24 juli 2024 06:18]

[Blokker_1999]

Die afhankelijkheid heb je zelf in de hand. Ik heb persoonlijk namelijk nergens last van gehad maar dat komt omdat ik geen 1 van de getroffen diensten/software gebruik. En ik probeer ook om diensten over zoveel mogelijk aanbieders te verdelen. Hoewel je dan single sign-on verliest kan je dat probleem tegenwoordig snel wegwerken met een goede wachtwoordmanager.

[thePiett]

Ik gebruik veel Google en heb nooit last van instabiliteit of storingen.

Als je vindt dat je te afhankelijk bent, dan stap je toch lekker over?

[Chaosstorm]

"Je merkt nu pas hoe enorm afhankelijk je eigenlijk bent van Google."

Dat doe je zelf. Ik heb er namelijk niks van gemerkt .

[BigBrotha]

Kan je dit aantonen?

[Tom 1234]

Ik kan meestal gwoon iets googelen hoor.
Als ik bijvoorbeeld bing gebruik vind ik niet wat ik bedoel

[RielN]

Dit zou ik graag onderbouwd zien. Na Next komt Google wel met een hele hoop nieuwe features, dat zijn ze niet gewend

[pasarica]

Zouden ze eindelijk ook een native linux client hiervoor gaan uitbrengen? Je weet wel... wat ze al jaren belovenden voor de huidige versie.

[svennd]

stack van transip werkt ander nadeloos op mijn linux distro

[sfranken]

Duhh, dat is owncloud

[peterrus_]

Ik kan je ook InSync aanraden, niet gratis, (zo'n 30 dollar voor een lifetime license) heb het zelf aangeschaft toen het volgens mij nog maar 10 dollar was, gebruik het in ieder geval al een jaar of twee en het doet gewoon z'n werk: https://www.insynchq.com/pricing

Uiteraard doodzonde dat er geen officiele native client is!

[Vexxon]

Gaat Google nu alweer een dienst de nek omdraaien ten faveure voor iets anders? Kunnen ze niet gewoon die functionaliteit toevoegen aan Drive? Voor de gemiddelde gebruiker is dit erg verwarrend, die is ineens zijn Google Drive kwijt.

[Amorandron]

Het lijkt me sterk dat ze opeens Drive gaan stoppen, het is zo'n populair product wat veel mensen gebruiken. In tegenstelling tot bijvoorbeeld Hangouts wat relatief weinig had.

[DukeBox]

Ze zijn lekker bezig, eergisteravond een probleem met drive en de gsuite support paginas (kon geen pin meer aanvragen). Gisteren dal de hele dag issues met chrome 57 door QUIC protocol en vandaag dit weer.
Erg apart zo kort achter elkaar terwijl over het algemeen er zeer weinig verstoringen zijn.

[418O2]

JOHN DID YOU PUSH TO MASTER?!

Lijkt me wel een ongeluk, anders zou het wel al werken. Misschien zelfs maar een kleine fout in een omgevingsinstelling ofzo

[Reactie gewijzigd door 418O2 op 24 juli 2024 06:18]

[Swerfer]

Backup and Sync. Sync is natuurlijk het 'Drive' gebeuren waarbij je bij de huidige Drive eigenlijk niet mag spreken van een backup, want als je een bestand lokaal overschrijft of wist, dan gebeurt in de cloud hetzelfde, dus weg backup.

Dan zal de nieuwe 'Backup' wel een echte backup service worden gok ik zo...

[tweaker2010]

Zou kunnen inderdaad. De naam is wel weer verre van onderscheidend. Backup and Sync als opvolger van Drive...hoe verzinnen die marketing mensen het?

[rbr320]

Hopelijk brengen ze voor deze nieuwe dienst ook een client uit voor Linux. Er is al jaren vraag naar een Linux client voor Google Drive, maar die is er nooit officieel gekomen. Er zijn wel een aantal onofficiële implementaties maar die hebben natuurlijk garantie tot de deur, zodra Google iets wijzigt werkt dat niet meer. Google belooft al jaren met een Drive client voor Linux te komen maar heeft nooit woord gehouden.

[McBrown]

Op zich wel een logische benaming voor de tool. Gezien hij geen drive emuleert, maar een map synct.

[Verwijderd]

Ik denk dat de naamswijziging van Google Drive Sync samenhangt met de introductie van Team Drives en/of Drive File Stream.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 06:18]