Dropbox krijgt ergens in eerste helft 2022 native app voor Apple M1-hardware

Dropbox komt in de eerste helft van 2022 met een native applicatie voor Apples M1-hardware. Het bedrijf was niet van plan om zo'n versie uit te brengen, maar kwam daar van de week op terug na uitingen van onvrede door onder andere gebruikers.

Dropbox is al bruikbaar op M1-Macs middels gebruik van Rosetta, de compatibiliteitslaag die het draaien van bijvoorbeeld apps voor Intel-Macs mogelijk maakt op Macs met de nieuwe M1-chips. Die chips zijn sinds een jaar op de markt zijn en zijn te vinden in recente modellen van de MacBook Air en Pro, Mac Mini, iMac en iPad Pro.

Het probleem met het gebruik van Dropbox via Rosetta op M1-hardware is dat het meer rekenkracht en dus meer energie vergt dan een native oplossing. Dat is natuurlijk een extra groot probleem bij M1-hardware die met een accu werkt. Op het Dropbox-forum spreken gebruikers ervan dat ze 'bij lange na niet de verwachte accuduur halen als Dropbox draait' en, volgens 9to5Mac, de app dan een GB aan geheugen gebruikt.

Dropbox vertelde in juli dat 'dit idee [van een native M1-versie] wat meer bijval moet krijgen van andere users voordat de suggestie naar het ontwikkelteam kan'. Dropbox kwam daar na het artikel op 9to5Mac op donderdag op terug en stelde dat de werknemer die die uitspraken deed, niet op de hoogte was van het standpunt van Dropbox. In een poging om dat op te helderen meldt Dropbox, onder andere bij monde van zijn oprichter en ceo, nu dat een native M1-versie van de app in de eerste helft van volgend jaar komt.

Concurrent Google Drive heeft sinds iets meer dan een week native M1-ondersteuning, net als Box, en Microsoft werkt aan M1-support voor OneDrive. Het verwacht dat nog dit jaar beschikbaar te maken.

Reacties (67)

[EdwinHamers]

Ik snap dit toch niet echt. Dropbox hoofddienst is cloud storage. En dat werkt het beste, ik zou zeggen de enige manier, met de desktop client. Dus de focus van Dropbox zou moeten zijn dat de client optimaal functioneert op die platformen die ze willen ondersteunen.

M1 is nu sinds vorig jaar dec? beschikbaar, en waarschijnlijk voor software developers al eerder. Maar Dropbox komt pas in 2022 uit met een versie voor M1.. Dat is gewoon een business beslissing (of gewoon lui)...

Toch begrijp ik dit niet als je core business afhangt van de client en je blijft niet bij blijft met je eigen software......

[rubenvb]

De reden is nochtans vrij eenvoudig. Hun (cross platform) desktop applicatie is gebouwd op Qt. Qt 6.2 (derde major release van versie 6 waarin M1 voor het eerst gesupport is), is de eerste die feature complete is (webengine support onder andere, die dropbox hoogstwaarschijnlijk gebruikt om zijn login spul te laten werken). En laat deze nu pas (drie weken geleden?) ongeveer uitgebracht zijn.

Ik vraag me af waarom je denkt dat de x86 applicatie niet goed werkt op de M1? Dit deed toch gewoon zijn werk? Daarom dat Rosetta2 er is, toch? Om dat naadloos te doen werken?

[Reactie gewijzigd door rubenvb op 22 juli 2024 16:23]

[wernervp]

Ik ben er niet zo zeker van of Dropbox op Mac OS ook Qt gebruikt. Volgens mij heeft de app Electron UI, wat een reden is dat Dropbox ook standaard vrij veel geheugen gebruikt. OneDrive is volgens mij wel een Qt app, iig op MacOS. Het geheugengebruik van Dropbox is overigens ook op een Intel Mac vrij hoog te noemen.

Dropbox draait op zich prima op de M1, maar wel met een relatief hoog energieverbruik. Persoonlijk vind ik het vooral vreemd dat Dropbox het leveren van een voor de M1 geoptimaliseerde versie van hun software als "feature request" behandeld. Rosetta 2 is bedoeld als overgang voor ontwikkelaars om hun apps aan te passen.

[rubenvb]

Aangezien er zich een resem PyQt binaries bevinden in de program files/Dropbox/<versienummer>/ map lijkt het me een vrij straightforward assumptie dat de Windows build gewoon op PyQt gebouwd is, net zoals de Linux versie, die mijn system Qt binaries vereist.
Raar maar waar is de macOS versie anders, en lijkt ie enkel python (en een resem andere libraries) te gebruiken en geen PyQt. Lijkt dus dat ze er een "native" app van gemaakt hebben.

Dat het veel memory gebruikt zal te maken hebben met hun file sync implementatie te maken hebben.
Ik heb gemerkt dat bvb pCloud of Own/NextCloud dit veel beter doet en dat Dropbox bij uitstek een relatief grote gebruiker is van RAM geheugen.

Native M1 port behandelen als feature request? Tja, waarom er spoed achter zetten als 0,x% van je gebruikers iets meer energy use heeft (een verschil dat in de mW regio zit?). Want face it, verre van de helft van de Dropbox gebruikers die ook Mac gebruiken zit al op een M1 chip. Zo gaat dat gewoonweg niet met de introductie van nieuwe hardware. Laat staan in een Coronajaar waar de aanlevering van allerlei grondstoffen je productie dwarsboomt. Dus nee, dringend is dit niet, en ik vermoed dat betalende grote klanten meerdere features geïmplementeerd willen zien voordat dit "consumer issue" opduikt in hun backlog.

[wernervp]

De sync-engine blijkt met Rust gebouwd te zijn, dat deel is dan gecompileerd naar een native formaat verwacht ik. De interface op Mac OS is Electron, ik heb Dropbox niet meer geïnstalleerd staan, maar als je de processen bekijkt dan is dat duidelijk te zien. Dropbox komt sinds de laatste "Desktop Experience" met een eigen filemanager (Electron) app, in feite de webversie maar dan lokaal.

https://dropbox.tech/infr...-heart-of-our-sync-engine

Native M1 port behandelen als feature request? Tja, waarom er spoed achter zetten als 0,x% van je gebruikers iets meer energy use heeft (een verschil dat in de mW regio zit?)

Dat klopt, de meeste mensen zullen er ook niet om vragen omdat ze het niet weten. De relatief kleine groep technisch onderlegde gebruikers van de app zijn dan niet belangrijk genoeg om (op korte termijn) aandacht aan te besteden. Volgens de officiële bronnen bij Dropbox waren ze al wel bezig met een M1 versie, maar was dat niet goed gecommuniceerd met het support team waardoor het overkwam als een feature request.

Dropbox is volgens mij vrij veel in gebruik bij de creatieve Mac gebruikers, die zullen nog wel veel op Intel Macs werken, maar dat kan met de introductie van de nieuwe M1's weleens snel veranderen. Maar goed, Dropbox was er (als ik het me goed herinner) ook pas op het laatste moment bij met een 64bit Windows versie .

[Superstoned]

… en zelfs al was het Qt, de Nextcloud sync cliënt is ook in Qt geschreven en komt nog dit jaar met een native M1 versie. Als dat kan met een team van 4 ontwikkelaars zou je toch verwachten dat Dropbox dat wat eerder kan…

[wernervp]

Helemaal mee eens.. het is laksheid van Dropbox om hier pas zo laat mee te beginnen.

[Wolfos]

Ik kan me voorstellen dat Dropbox gewoon prima werkt via Rosetta. Het is nou niet echt een applicatie die het van z'n snelheid moet hebben. Alleen de up/download snelheid zijn belangrijk, en die zullen door Rosetta niet worden beperkt.

[wernervp]

Dropbox heeft aardig wat processen draaien om de synchronisatie te verzorgen, optimalisatie is daarom wel belangrijk. Het is namelijk ook een app die constant op de achtergrond aanwezig is, wat dat betreft is optimalisatie nog 'belangrijker' dan voor een app die je zo nu en dan opstart.

[angulardragon03]

De Developer Transition Kit was al sinds Juli 2020 beschikbaar voor developers, dus ze hebben idd ruim de tijd gehad om dit te kunnen testen en oplossen. Helaas zijn er ondanks deze hardware meerdere groot ontwikkelaars (o.a. Google) die heel lang deed over naar Universal apps te stappen.

[NielsFL]

Aan dit soort keuzes gaat gewoon een kosten/baten analyse vooraf. Dropbox heeft echt wel zicht op hoeveel betalende klanten deze "vertraging" ze potentieel kost. Kennelijk valt dat wel mee.

Sowieso denk ik dat het vooral de iCloud gebruikende Apple fans zijn die bovenop de nieuwe M1 modellen springen. De grote massa "gewone" gebruikers heeft daar veel minder haast mee.

[Menesis]

Dropbox is een dikke cash cow. Er gebeurd al tijden enorm weinig. Ze hadden bijv een prachtig fotosysteem kunnen ontwikkelen, maar het is al 10 jaar hetzelfde.
Daarom ga ik dit jaar niet weer 100 euro betalen.

[Magic]

Dropbox weet al heel lang lang niet meer wat hun klanten willen. Dit verhaal verbaast mij dan ook niets.

[Uruk-Hai]

Het probleem met het gebruik van Dropbox via Rosetta op M1-hardware is dat het meer rekenkracht en dus meer energie vergt dan een native oplossing.

Leerzaam dit.

Geld dat dan ook niet net zo goed voor Windows applicaties op Linux?

[laurxp]

Nee!

Bij het draaien van Windows applicaties op Linux via Wine is er geen vertaling nodig van de programmacode. Je draait precies dezelfde instructies op je processor. Wine werkt alleen als tussenlaag in de interface tussen het besturingssysteem en het programma. Hierbij maakt Wine bijvoorbeeld de "OpenFile()" functie van de Windows-API beschikbaar door de argumenten wat om te husselen en de "open()" van Linux aan te roepen. Dit is heel efficiënt, en de reden dat je bijvoorbeeld prima met Proton op Linux kan gamen. Wine staat dan ook voor "Wine Is Not An Emulator"

Bij de Apple M1 moet Rosetta instructie voor instructie vertalen van x86/64 naar ARM. Dit tijdens het draaien doen is mogelijk, maar vrij inefficient. Je maakt dan letterlijk een emulator, zoals je ook een Game Boy emulator hebt. Gelukkig is er een trucje: de code die je draait is vaak precies hetzelfde. Je zou dus ook van tevoren die vertaalslag kunnen doen! Bij het draaien van een non-native programma hoef je dan alleen maar te herkennen dat je x86 aan het starten bent, en de reeds vertaalde en opgeslagen ARM instructies daarvoor in plaats draaien.

Dus wat gaat er mis by Dropbox? Nou, Dropbox is geschreven in Python. Dit is een geïnterpreteerde programmeertaal. In tegenstelling tot gecompileerde talen sla je niet de CPU-instructies op, maar de programmacode zelf - of een tussenvariant. In feite bestaat de Dropbox client dus uit de Python "compiler" en een hoop bestanden met Python-broncode. Die "compiler" zet dus tijdens het draaien de programmacode om in CPU-instructies.

Rosetta zou dus prima de Python "compiler" om kunnen zetten naar ARM, maar, het moet vervolgens tijdens het draaien van Dropbox alsnog on-the-fly de uitvoer van die "compiler" vertalen van x86/64 naar ARM! En dat is dus retetraag en energie-inefficient.

[Metten]

Dat snijdt zeker hout, maar zou het dan niet ook (relatief) makkelijk moeten zijn om een M1 versie van Dropbox uit te brengen? Als het daadwerkelijk alleen om die compiler/interpreter gaat kan die conversie niet heel ingewikkeld zijn.

[laurxp]

Python 3.9.1, uitgekomen afgelopen januari, is de eerste versie met native Apple M1 ondersteuning. In theorie is het dus niet al te lastig om een nieuwe versie uit te brengen, want je kan gewoon Python upgraden.

In de praktijk gaat dit niet altijd zo makkelijk. Volgens deze analyse gebruikte Dropbox in 2019 versie 3.6 terwijl 3.7 al een jaar beschikbaar was. Ze zitten dus sowieso niet standaard op de meest recente versie. Dropbox gebruikt ook een sterk aangepaste versie van Python: de aanpassingen steeds overzetten naar een nieuwere versie zal niet triviaal zijn. Het is dus niet héél gek dat ze niet direct M1 ondersteuning hebben gekregen.

Grote bedrijven gebruiken nou eenmaal niet altijd de allernieuwste software - vooral niet als er geen héél goede reden voor is. Technisch werkt de software immers gewoon, dus waarom zou je er developertijd - en dus geld - aan besteden? Dat de gebruikerservaring in de praktijk vrij slecht is, is blijkbaar geen prioriteit voor ze.

[amx]

Grote bedrijven gebruiken nou eenmaal niet altijd de allernieuwste software - vooral niet als er geen héél goede reden voor is. Technisch werkt de software immers gewoon, dus waarom zou je er developertijd - en dus geld - aan besteden? Dat de gebruikerservaring in de praktijk vrij slecht is, is blijkbaar geen prioriteit voor ze.

Is dit in tech ook de standaard? Ik betwijfel het. Geld verdienen is de motivatie. Niet bleeding edge versie draaien inderdaad, maar "het werkt dus we zijn niet op zoek naar vernieuwing" is wel heel kort door de bocht (in de tech sector althans).

[rubenvb]

Niemand heeft iets aan bugs/mankementen geïntroduceerd door de laatste versie van library X.

Je moet minstens testen of alles nog naar behoren werkt, en soms is er gewoon iets kapot en dan moet je daar tijd en geld in steken.

Ik weet niet goed wat je met "de tech sector" bedoelt, software is software. Sommige bedrijven deployen liever bugs om de latest and greatest te hebben, maar da's eerder een keuze dan een gevolg van in de "tech sector" (whatever that's supposed to mean) te zitten.

[init6]

Een nieuwe versie wordt pas een prioriteit als er een reden is te upgraden. Upgraden voor upgraden is niet nuttig, dus als er performance improvements zijn, als er security issues zijn opgelost of als er een bug die relevant voor je is dan ga je upgraden. En dan nog bepaald je backlog dit moment.

Bepaalde pipeline integraties kunnen wel aangemaakt worden om automatisch de versie te upgraden en testen, maar als er dan iets niet werkt dan komt de fix later.

Er is een aardig tekort aan developers, bedrijf waar ik nu bij zit heeft altijd meerdere functies open staan. Er is dus altijd meer werk dan dat er mensen zijn, dan bouw je iets sneller je technical debt op en kom je minder snel toe aan Vanity projects.

[poehee]

Ik ben toch benieuwd wat er dan niet werkt. Dit zullen ze toch zelf snel moeten kunnen uitzoeken?
Kwestie van broncode onder Python 3.9.1 hangen en fixen (al zou ik zo even niet weten wat er niet upward compatible is in Python 3.x).
Moet je dan denken aan binary libraries (e.g. c++), aan niet-compatible third party libraries (of eigen libraries). Bugs of automatische tests die falen?

[laurxp]

Combinatie van alles wat je noemt, eigenlijk. Binary compatibility is niet 100%; Python 3.9 maakt van een hoop waarschuwingen errors; outdated libraries (3.10 is eerder deze maand uit gekomen, en van de 360 meest populaire libraries claimt slechts 20% er al ondersteuning voor te hebben); aanpassingen die ze hebben gemaakt aan Python die je niet 1:1 over kan nemen...

Op deze schaal is software-ontwikkeling geen snel proces. Het is een machine met héél veel radertjes, en als er ééntje tegenwerkt gaat het feest niet door. Ontwikkelingen die triviaal lijken, kunnen op de achtergrond alleen al maanden aan planning kosten!

[killerdemon]

Daarnaast is er ook al een Android versie

[Mijzelf]

Niet noodzakelijkerwijs. Rosetta moet al de programma code vertalen van x86 naar Arm, terwijl een x86 Windows programma die op x86 Linux draait grotendeels native kan draaien, alleen bij de communicatie tussen OS en programma moet er een flinterdun vertaallaagje tussen.

[fretnn]

maar is het niet zo dat die vertaling enkel de 1ste run plaats vindt, en dat die dan gecached wordt ?
De vraag is natuurlijk of het resultaat van die vertaling even efficient is als een native arm app, waarschijnlijk niet ?

[Mijzelf]

De vraag is natuurlijk of het resultaat van die vertaling even efficient is als een native arm app, waarschijnlijk niet ?

Klopt. Het lijkt me een stuk lastiger om machine code efficient te vertalen naar machine code voor een ander platform dan broncode. Bijvoorbeeld de CMPXCH instructie (compare-exchange, een veelgebuikte manier om stukken geheugen die in verschillende threads tegelijk worden gebruikt veilig aan te passen) heeft op Arm een aantal verschillende implementaties, waarbij de duurste (in CPU tijd) overeenkomt met de (enige) x86 implementatie. Maar Arm heeft ook goedkopere varianten, die gebruikt kunnen worden als aan bepaalde voorwaarden voldaan is. De programmeur kan daar in de broncode rekening mee houden, maar of de aan de randvoorwaarden is voldaan is uit de x86 code moeilijk op te maken. Met als gevolg dat de duurste variant dan maar wordt gebruikt.

[Xerxes249]

Het is niet per definitie zo want het zou best kunnen dat de oorspronkelijke applicatie veel efficienter was geschreven en dat dat opweegt tegen de kosten die komen bij emuleren/virtualiseren/jit/whatever truukjes. Maar in general ja.

[jkommeren]

Nee. Het gaat om de conversie van instructies.

X86 (intel/amd) naar Arm (Qualcomm, m1 etc) of omgekeerd. Op een X86 windows pc zul je in 99% van de gevallen Linux X86 gebruiken. Zelfde voor Android op win 11. Dan heb je hier geen last van.

Als je een X86 app op windows on arm draait heb je wel exact hetzelfde probleem. alleen heeft Microsoft geen fancy naam voor de compatibiliteitslaag (Rosetta)

Overigens wel goed dat deze "issues" nu naar boven komen, want het is dus ook voor Windows on Arm belangrijk zoveel mogelijk native apps te draaien. Hopelijk zet de trend daar ook door.

[Reactie gewijzigd door jkommeren op 22 juli 2024 16:23]

[Ryen]

Dat hangt af van welke CPU het Linux-systeem heeft. Als het een niet-Intel machine is moet de code on-the-fly 'vertaald' worden naar instructies voor de CPU en dat kost rekenkracht. Met Windows code op een Intel/Linux computer is dit niet nodig.

[MaestroMaus]

Voorop staat dat iedere vertaallaag altijd performance loss met zich mee brengt; het is tenslotte altijd extra werk om de calls te vertalen en dus altijd wat performance loss. Maar hoe groot de performance loss is, is sterk afhankelijk van de kwaliteit van de implementatie en de extra features van de implementatie.

Ik weet niets van Rosetta af, maar het zou bijvoorbeeld kunnen zijn dat ze niet alleen vertalen maar ook de applicatie sandboxen zodat hij niet rechtstreeks bij andere applicaties kan. Dat zou vanuit beveiligingsstandpunt positief zijn maar qua performance natuurlijk een extra belasting zijn.

Het efficiëntie deel komt voort uit de kwaliteit van de code, maar ook uit het handig benutten van hardware. Misschien is het wel voordelig om bijvoorbeeld de GPU te laten assisteren (ik heb werkelijk geen idee).

[Reactie gewijzigd door MaestroMaus op 22 juli 2024 16:23]

[Gustaaf437]

Het klopt niet per definitie wat in het artikel staat. Bij Rosetta 1 (PPC > X86) werd de machine code on-the-fly vertaald. Nu (met Rosetta 2) vertaalt Apple de machine-code bij installatie (of tijdens de eerste keer opstarten) en dat werkt voor sommige programma's alsof ze native voor ARM zijn gecompileerd, maar het is natuurlijk niet 100% native compileren en dan kan het CPU of geheugengebruik nog wel eens tegenvallen.

[Ventieldopje]

Rosetta vertaald tussen architecturen (intel instructies naar m1/arm instructies) en dat kost wat kracht.

Windows applicaties onder Linux met Wine gebeuren door Windows API calls te vertalen naar POSIX calls. Dat kost wat minder kracht vaak, afhankelijk van de applicatie.

[mikesmit]

Linux word voora gebruikt door mensen die hun eigen software problemen oplossen

Buiten dat vermoed ik dat de gemiddelde Linux gebruiker dezelfde persoon is als die hun eigen file hosting doen thuis

[arjan1995]

Wel typisch dat al die opslag-apps hier zo lang voor nodig hebben. Is het zoveel lastiger om deze om te zetten dan bijvoorbeeld MS Office of een Adobe-pakket?

[mikesmit]

Het gaat meer om willen dan kunnen. Nieuwe software ontwikkelen (zoals een andere architectuur) kost geld en de kosten moeten wel tegen over de baten worden gezet.

Bovendien dacht Dropbox waarschijnlijk dat ze geen actie hoefde te ondernemen door Rosetta

[pBook]

Nee hoor, Sync.com is al een tijdje native. Misschien is de codebase van Dropbox een drama en duurt het daarom zo lang om dit voor elkaar te krijgen. Er waren al Apple Silicon developer units in de zomer van 2020, dus ze hebben alle tijd gehad.

[Phanthix]

Een mooie ontwikkeling om te zien dat er steeds meer apps native worden. Ik vind het heel knap hoe goed Rosetta werkt(icm met de hardware) waardoor alle apps ondersteund blijven, maar native is toch fijner en in sommige applicaties een stuk sneller.

[Padvinder]

https://isapplesiliconready.com/

Handig overzichtje van M1 optimized apps.

[Carlos0_0]

Mag ook wel anders hadden ze bijzonder slechte naam gekregen, ook stom dat ze niet van plan waren om niet te doen.
Heel Apple platform stapt over op de nieuwe chips, en goed apps werken wel nu maar ze kunnen hun app zoveel beter maken als ze het aanpassen.

Want niet elke gebruiker weet dat app aangepast is, maar ze merken wel of de app goed werkt.
En werkt een app niet goed gaan ze klagen over overstappen, en dat moet je als een bedrijf niet willen.

[machiel]

Ik vind het verrassend dat het zoveel tijd moet kosten.

[Chris_147]

Ik dacht dat Dropbox veel gebruik maakt van Python, ook voor de cliënt: https://m-cacm.acm.org/ne...-an-amazing-ride/fulltext
https://www.techrepublic....amming-language-at-scale/

Dat het omzetten zo lang duurt, zal daar ook wel iets mee te maken hebben. Ik denk dat Python nog niet native op de M1 CPU draait.

[GekkePrutser]

"Box Drive" heeft hetzelfde probleem. Ze gebruiken een system extension (dus geen Rosetta mogelijk!) en die is nog steeds niet werkend op M1. Wel een beta versie die prima werkt, maar op mijn werk ga ik gewoon geen beta software uitrollen. Dus we wachten nog steeds met het beschikbaar maken van M1 Macs

Het is vreemd want het zijn juist dit soort appjes waarbij het niet zoveel werk is, die moeilijk doen. Onze antivirus had ook veel tijd nodig maar na 8 maanden na release van de eerste M1 was het gewoon klaar.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:23]

[bommel]

Ik ben geen Dropbox gebruiker maar was de Windows app niet ook al wat vermomde Python scripts ipv echte (Windows) app?

[kamerplant]

Ze nemen er de tijd voor dan!

[FreshMaker]

Het aloude vraagstuk
Wil je Goed, Goedkoop of Snel ?
Je mag er twee kiezen ....

Dan maar wat meer ontwikkeling, dan een snelle versie, en een jaar lang elke week een update omdat XYZ niet goed (genoeg) is

[kamerplant]

1,5 voor dit is gewoon traag.

[Verwijderd]

dropbox ben ik al mee gestopt, veels te duur ook, zit nu bij google drive
https://workspace.google.com/intl/nl/pricing.html heb toen bussines plus gehaald en gekocht, waarna het omgezet naar Enterprise.. zo hoef je geen contact met ze op te nemen. ik betaal nu 17eur voor unlimited drive en google photos zit er ook bij

[mikesmit]

“Unlimited”

Praktisch gezien zit er wel degelijk een limiet op aangezien de up en down kelderd na 50GB en als ik me niet vergis zit er een maximale grootte aan bestanden an sich.

Het is net zo “unlimited” als de meeste data plannen bij mobiele providers. Ja technisch is het zo, maar praktisch niet

[Verwijderd]

Je vergist je want je kan 5tb uploaden per bestand

[FreshMaker]

“Unlimited”

Praktisch gezien zit er wel degelijk een limiet op aangezien de up en down kelderd na 50GB en als ik me niet vergis zit er een maximale grootte aan bestanden an sich.

Het is net zo “unlimited” als de meeste data plannen bij mobiele providers. Ja technisch is het zo, maar praktisch niet

Ik heb een 'grijze' google enterprise shared folder, waar heel mijn film/tv archief opstaat.
Plex streamt deze dagelijks, en al mijn "iso's" gaan daarnaartoe.
Vooralsnog staat daar zo'n 15TB op, variërend van 2GB tot 90GB bestanden.
Alleen kan je maar 250GB per dag up/downloaden, maar als je op 249GB zit, en een file van 90GB begint te versturen, blijft die gewoon doorgaan.
komt niet zo heel vaak voor

[tricksel]

En dit is van toegevoegde waarde, want?