Sidste uge bloggede en Microsoft medarbeder stolt om deres ny "GVFS - Git Virtual File System"
Kernen i blogindlægget er flg: "For example, the Windows codebase has over 3.5 million files and is over 270 GB in size. The Git client was never designed to work with repos with that many files or that much content."
Microsoft har "løst" problemet ved, som overskriften antyder, at lave et virtuelt filsystem, frem for at tage et kritisk kig på hvad fanden det er de i det hele taget har gang i.
Hvis vi, vildt optimistisk, antager at kun 1% af de 3.5 millioner filer har en enkelt fejl, bliver det stadig til 35 tusinde fejl totalt set.
Eller hvis vi antager at der er 100 filer i hvert katalog og at man kan opsummere hvad kataloget indeholder og gør med en enkelt linie tekst, skal man stadig bruge en hel pakke papir og et bogholderringbind for at lave en oversigt.
Tre en halv million filer er et vanvittigt komplexitetsniveau, langt hinsides noget andet vi som mennesker giver os af med. Skibsværftet havde f.eks kun 1 million stumper at holde styr på, da de byggede CVN-76, USS Ronald Reagan:
Antallet af filer og den samlede volumen siger imidlertid ikke ret meget om indholdet, ud over at Microsoft ikke rutter med metadata og commit-messages: Hver fil fylder i gennemsnit mindre end 8kB.
Men vi kan prøve at regne på det.
I Varnish har vi en testfil for hver 200 linier kode og halvanden testfil for hver kildetekstfil og ret god dækning af koden.
Lad os antage at Microsoft er ti gange mere omhyggelige, således at de har en test per 20 linier kode, femten testfiler per kildetekstfil.
Det bliver til lidt over 200 tusinde kildetekstfiler med ca. 65 millioner linier kode, hvilket alt i alt ikke lyder usandsynligt.
Og hvis deres fejlrate er en tiendedel af det normale, dvs. en fejl per titusinde kodelinier, er der "kun" 6500 fejl tilbage i Windows.
Den udregning overser naturligvis de 15/16 af isbjerget der er under vandoverfladen: Testprogrammer og -data har erfaringsvist ikke lavere fejlrater end kode.
Giver vi Microsoft endnu en faktor 10 fordel, er der kun ca. titusinde fejl i under vandoverfladen.
Opsummeret: Hvis Microsoft er ti gange ti gange ti, tusinde gange bedre og mere omhyggelige end jeg er, er der kun ca. 15 tusinde fejl i Windows.
Så meget for den numeriske side af sagen.
Hvis ens projektræ tager 12 timer og en harddisk i "git clone" er svaret ikke at skrive et filsystem der gemmer problemet bort[1], men at splitte projektet op i mange mindre projekter.
Jeg gider ikke engang spilde tekst på at forklare hvorfor to projekter på N linier har bedre chancer end et projekt på 2N linier, det er børnelærdom og hvis nogen mener det modsatte kan de starte med at tage tid på at splitte regningen fair for 10 hhv. 20 personer på en italiensk restaurant.
Det decentralisering og modularitet strider imidlertid totalt imod Microsofts fundamentale verdensbillede og "corporate culture".
Vi taler om firmaet de har proppet alt hvad de kunne komme i tanke om ind i Windows og/eller Office, firmaet der var villig til at teknisk handicappe den ene version af Windows efter den anden, i deres jagt på forretningsområder de kunne invadere med deres monopolprofit.
Med "GVFS" er banen ryddet således at der kan skolves endnu flere filer og gigabyte ind i Windows projektet, med det matematisk lovmæssige resultatet at kvaliteten vil falde yderligere.
Om jeg fatter hvordan nogen tør bruge Windows på vigtige computere...
phk
[1] Hvis ikke for andre årsager, så fordi "No sane person writes a filesystem voluntarily" (-- Kirk McKusick)
Nogen burde sammen finde en holdbar løsning på sourcekode modularitet og Git - GVFS viser at der er et behov for at løse det problem, og som du påpeger er det ikke den rette vej MS er gået. En modularisering af kodebasen giver andre fordele, og Git burde tilbyde løsningen.
Ja, det er virkeligt underligt, at det her Microsoft Windows bliver brugt af nogen.
https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-... Citat:
The first big debate was – how many repos do you have – one for the whole company at one extreme or one for each small component? A big spectrum. Git is proven to work extremely well for a very large number of modest repos so we spent a bunch of time exploring what it would take to factor our large codebases into lots of tenable repos. Hmm. Ever worked in a huge code base for 20 years? Ever tried to go back afterwards and decompose it into small repos? You can guess what we discovered. The code is very hard to decompose. The cost would be very high. The risk from that level of churn would be enormous. And, we really do have scenarios where a single engineer needs to make sweeping changes across a very large swath of code. Trying to coordinate that across hundreds of repos would be very problematic.
After much hand wringing we decided our strategy needed to be “the right number of repos based on the character of the code”. Some code is separable (like microservices) and is ideal for isolated repos. Some code is not (like Windows core) and needs to be treated like a single repo. And, I want to emphasize, it’s not just about the difficulty of decomposing the code. Sometimes, in big highly related code bases, it really is better to treat the codebase as a whole. Maybe someday I’ll tell the story of Bing’s effort to componentize the core Bing platform into packages and the versioning problems that caused for them. They are currently backing away from that strategy.
Hvis ikke for andre årsager, så fordi "No sane person writes a filesystem voluntarily" (-- Kirk McKusick)
Det fik mig uværgeligt til at tænke på Hans Resier.
Nøgleordet her er netop "tenable". Git muliggør det ikke godt nok med submodules, og add-ons som Android's Repo er ikke tilstrækkelig integreret.
MS citatet skitserer jo udmærket problemstillingen.
Jeg mener at have læst et sted at Google også har al deres kode i et enkelt repository.
Jeg synes det giver mening da det gør det enklere at lave atomare commits. F.eks. hvis et API ændrer sig.
Måske enklere, men ikke særlig afkoblet.
Jeg mener at have læst et sted at Google også har al deres kode i et enkelt repository.
Jeg synes det giver mening da det gør det enklere at lave atomare commits. F.eks. hvis et API ændrer sig.
Det kan jo sagtens være rigtigt - antallet af repos kan vel godt primært afspejle arbejdsprocesser og opbygningen af teams, mere end kildekodens design og modularitet. Koden kan f.eks godt være modulært bygget op, selvom du kun har ét repo.
Men den anden vej...
Humlen lader til at være, at Microsoft jvf Lars Skovlunds citat ovenfor føler sig presset ud i en beslutning om kun ét repo, via en uadskillelig, ikke-modulær, gigantisk hårbold af kode. Selvom de måske kunne have haft gavn af opsplitning i flere.
I øvrigt bruger Google er egetudviklet system, og ikke Git.
http://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions...
[1] Hvis ikke for andre årsager, så fordi "No sane person writes a filesystem voluntarily" (-- Kirk McKusick)
Nu er det, trods alt, ikke et filsystem de har skrevet, men en filter driver (tænk FUSE) - der er rimeligt stor forskel.
Jeg er egentligt enig i at det virker som en både klodset og vanvittig løsning. Men på den anden side, forståeligt at man vælger at gå den... pragmatiske... vej. Det løser (eller, rettere, mitigerer kraftigt) et her-og-nu problem der er konsekvensen af årtiers arbejde på et centralt repository. (Man kan undre sig over at Google også bruger monolit-repo, man skulle tro folk var blevet klogere...)
Med hensyn til størrelsen kunne det være interessant at se en sammenligning med Linux. Det er jo ikke bare Windows kernen der ligger i det repository, men (kilde):
That size is actually the entire OS repo. It includes Windows OneCore, Desktop, Mobile, HoloLens, Xbox, IOT, etc. Plus tools, and other code we ingest from feeds and store in our tree. It’s the full enchilada, not just Desktop.
Nu vil alle versioneringssystemer jo ikke tilgå modulatitetsproblemet på samme måde, problemet er ikke monolit vs. modulær, men om det monolitiske kan tilgås i fornuftige bidder - en mere granulær adgang der de facto er lig modulariserede opdelte enkelt- repositorier.
Det decentralisering og modularitet strider imidlertid totalt imod Microsofts fundamentale verdensbillede og "corporate culture".
Jeg synes nu de tænker mig modularitet ind i deres nye ".net core" og "asp.net core" hvor alt er DLL'er/Nugets. Og det er vel også noget af det de prøver med nano server?
Nu vil alle versioneringssystemer jo ikke tilgå modulatitetsproblemet på samme måde, problemet er ikke monolit vs. modulær, men om det monolitiske kan tilgås i fornuftige bidder - en mere granulær adgang der de facto er lig modulariserede opdelte enkelt- repositorier.
Jeg vil nu ellers mene at der i høj grad er et problem mellem monolitisk og modulært design. Ja, det er teknisk muligt at lave "ét gigantisk repo der kan tilgås i mindre bidder" - det er Git ikke super egnet til, men det lader til at være hvad Google har bikset sammen.
Men hvor har du det største incitament til at strukturere din kode modulært, med veldefinerede grænseflader mellem de forskellige moduler? I et system hvor du smider hele din organisations sourcekode ind i et stort dump, eller i et system hvor du har flere mindre repositories?
Enhver der har læst "The Mythical Man-month" vil vide at dette kunne have været "foresight" frem for "hindsight" for Microsoft.
Klart med flere mindre repositories, vi er helt på samme side der. Min pointe var mere, at Google har laver noget der understøtter deres softwares modularitet på en for dem tilstrækkelig måde.
Jeg vil til enhver tid foretrække de mange små individuelle repositorier, min oprindelige kommentar var affødt af manglen på tools der gør et sådant setup operationelt på en generel måde.
Een ting et modulariteten af software man versionsstyrer, en anden systemet til den versionsstyring. Jo mindre konceptuel forskel der er på de to, jo bedre. Og der fejler Git. Hvor godt Google's Piper understøtter det ved jeg så ikke.
Jeg synes nu de tænker mig modularitet ind i deres nye ".net core" og "asp.net core" hvor alt er DLL'er/Nugets. Og det er vel også noget af det de prøver med nano server?
En virksomhed med så mange medarbejdere som Microsoft, kan næsten ikke undgå før eller siden at ansætte folk der tænker sig om og/eller forstår sig på det de beskæftiger sig med. Selv hvis MS aktivt skulle forsøge at undgå dette.
Så før eller siden vil der nok opstå tiltag til forsøg på at gøre tingene rigtigt. Men bagkataloget ligger der jo stadig.
Hvis de havde økonomisk fordel af at optimere eller skrive hele molevitten om, havde de gjort det for længst. Jeg tror mange nørders undren over Microsoft primært kommer af, at de glemmer at Windows er designet ud fra 100% økonomiske overvejelser. Det er ikke sådan en demo-scene agtig "det skal bare være det fedeste OS"-motivation der ligger bag, sådan som det var for f.eks. Amigaen.
Som mange allerede er inde på mangler der helt nogle bedre features i GIT til modularitet. Submodules er slet ikke stærkt nok. Men særligt hvis et projekt indeholder store mængder af grafik filer er GIT helt håbløst (og nej; Argumentet om at man "bare" skal finde på en anden løsning til sine binære filer køber jeg ikke. De bør kunne ligge i et Repo og det spiller da også nogenlunde med feks svn)
Det er måske netop grafik filerne der får MS' repo til at blive så gigantisk? Det lyder dog stadig som en sær løsning at lave et nyt fil system...
Det er interessant at Microsoft i deres analyse snakker om at visse komponenter ("Windows core") ikke kan adskilles i mindre dele. GNU/Linux har demonstreret at et styresystem kan udvikles som en masse decentraliserede, usammenhængende repositories. Det har ikke været som et bevidst designvalg, som en nødvendighed af at udviklingen altid har foregået som en masse uafhængige projekter, der kommunikerer med hinanden via offentlige snitflader. I dette tilfælde har den sociale struktur for udviklingen gjort at man har undgået behovet for at skulle skalere sin teknologi og udviklingsproces højere end hvad der nok er fornuftigt. Det største problem her er som sådan ikke om ens versionssystem skalerer til millioner af filer, men at ens komponenter er så tæt koblede, at de er nødt til at leve i samme repository.
Det tætteste man kommer på Microsoft's (og andres) kæmpe-repositories er ironisk nok (blogindlæg-forfatteren taget i betragtning) BSD'erne, der inkluderer både kerne og userland i samme repository. Der er dog tale om langt mindre kode, og den virkelig store del (ports og semi-officielle pakker) er i separate repositories, eller i det mindste kun tilstedeværende som installationsscripts, og (vigtigst) meget løst koblet til resten af systemet.
Vi behøver lave sammenligninger her, den struktur Microsoft har valgt er objektivt dum og til overflod veldokumenteret problemskabende for så vidt softwarekvalitet.
Selv uden en eneste konkurrent i markedet, ville det være dumt.
Hvornår skiftede Microsoft til git, og hvad brugte de før?
Det gik godt nok hurtigt med at glemme Balmers "vise" ord...
Jeg synes nu de tænker mig modularitet ind i deres nye ".net core" og "asp.net core" hvor alt er DLL'er/Nugets.
Jeg har engang læst en historie om en der var hyret af Microsoft til at lave noget om i Windows login. Det lykkedes ham ikke at løse opgaven i det år han var ansat, problemet var at der skulle laves ændringer i 5forskellige API'er fra NT kernen og op. Og dem der ejede de forskellige interfaces var ikke interesserede i ændringer, da det vil ødelægge funktionalitet. Det var heller ikke deres prioritet at fortælle hvorledes at han fik bygge miljøet op og køre således at han selv kunne genbygge kernen.
Nogle gange kan ting blive så afkoblet at det bliver til en monolit... :-)
Intern binding mod et interface lyder som rigtig skidt software design. Hvis ikke interfacet kan opdateres uden at ødelægge funktionalitet er der stadig en binding - som sagtens kan "vende indad".
Så før eller siden vil der nok opstå tiltag til forsøg på at gøre tingene rigtigt.
Jeg tror du tager fejl..
Det har undret mig siden engang i starten af 80'erne, at det i så mange år var mere væsentligt ($-fiksering) at annoncerer, vise samt udsende klyt, hullet sikkerhed eller 85% færdigt "et eller andet", som der efterfølgende lappes på i utallige år - det sænker jo niveauet + renomme for en hel branche!
MS har da både de nødvendige ressourcer i form af $ samt ansatte, har haft flere læssevis af tid, så det er alene viljen der mangler.
Intern binding mod et interface lyder som rigtig skidt software design. Hvis ikke interfacet kan opdateres uden at ødelægge funktionalitet er der stadig en binding - som sagtens kan "vende indad".
Nu består Microsoft af mange grupperinger (firmaer i firmaet), hvor hver har deres ansvar, og deres interne og externe interfacs. Jeg kan forestille mig at de samme grundlæggende abstraktioner findes i mange lag, startende med Defered Procedure Call, via. IoCtrl, WinX API, og .Net. Hvis der er brug for at lave om i et API der vedrøre flere lag, kan det være fristende at lave således at én person kan chekke monolitten ud, og teste ændringene selv i alle lag.
Hvis man laver for mange 'afkoblede' legacy indkapslinger af interfaces oven på hinanden, og disse interfaces er levende, så har man i praksis skabt en monolit.
Jeg tror du tager fejl..
Den tro har du så ikke rigtigt noget at hænge op på.
Der er her i debatten allerede leveret henvisning til at nogen i MS har forsøgt at gøre tingene rigtigt. De er langt fra kommet i mål, hovedsageligt pga en sammenfiltret legacy kodebase. Forsøget på dette tiltag er dog gjort.
MS har da både de nødvendige ressourcer i form af $ samt ansatte, har haft flere læssevis af tid, så det er alene viljen der mangler.
De der har forsøgt at modularisere via git har jo haft viljen. Hvis det ikke prioriteres fra forretningens side, kan du sagtens påstå at MS ikke har viljen, uden at jeg modsiger dig. Men så har du nok læst mit indlæg forkert: Der vil opstå tiltag på "at gøre det rigtige" mht modularisering, men "forsøg på tiltag" er ikke det samme som at hele supertankeren vender på en tallerken, og disse forsøg på tiltag er slet ikke sikre på at komme i mål.
Jeg er sikker på, at matematikken i holdningsartiklen er korrekt.
Men der er så meget mere end matematik der gælder, i et firma på Microsofts størrelse. Også for beslutningerne.
Og apropos dem. Jeg tænker det er en smule arrogant at antage, at der i et firma som Microsoft (og så kan I synes om deres produkter og kultur hvad I vil) nok ikke er nogen, som har sat sig ned og lavet de betragtninger PHK har lavet. Og sandsynligvis på et noget mere detaljeret niveau.
Mon ikke vi godt kan stole på, at Microsoft har gennemtænkt deres case sådan rimelig ok, og har valgt den approach til problemet, som de så gav mening?
Jeg tvivler på nogen bare har sagt "det gør vi sgu' bare, det der, det' ligemeget..."
Jeg så først denne fine titel, i URL'en, efter at have læst indlægget og kommentarerne. Jeg synes ofte Microsoft får en urimelig hård behandling. Hvis man ser nøgternt på det, så præsterer de at understøtte en enorm platform af hardware og software - også bagud i høj grad. Det er mildest talt imponerende.
Det samme kan ikke siges om andre OS, hvor du enten ingen support har, eller legacy udstyr bliver glemt nærmest før du kan nå at få det hjem.
MS er ingenlunde perfekt, men det er 'nix godt nok heller ikke. Hvis jeg skal tælle begyndende grå hår, så er de alle forårsaget af 'nix, ikke MS, som jeg trods alt altid har kunnet finde kb artikler på, eller rette fejlene i når de opstod.
Hvis man ser nøgternt på det, så præsterer de at understøtte en enorm platform af hardware og software - også bagud i høj grad. Det er mildest talt imponerende.
Det samme kan ikke siges om andre OS, hvor du enten ingen support har, eller legacy udstyr bliver glemt nærmest før du kan nå at få det hjem.
MS er ingenlunde perfekt, men det er 'nix godt nok heller ikke. Hvis jeg skal tælle begyndende grå hår, så er de alle forårsaget af 'nix, ikke MS, som jeg trods alt altid har kunnet finde kb artikler på, eller rette fejlene i når de opstod.
Hvilken sten har du levet under de sidste 15 år?
Kan jo udelukkende byde ind med mine egne oplevelser Christian. :)
Kan jo udelukkende byde ind med mine egne oplevelser Christian. :)
Så burde du lade være med at komme med generaliseringer om hvordan f.eks. andre OS'er fungerer, når du tydeligvis ikke ved noget om det.
Men jeg vil da godt medgive dig at der findes intet der er perfekt, hverken fra den ene eller anden, eller tredie, front, men at mængden af artikler for alles vedkommende er stort set ubegrænset - det sværeste er som regel at kunne formulere sit spørgsmål.
Og apropos dem. Jeg tænker det er en smule arrogant at antage, at der i et firma som Microsoft (og så kan I synes om deres produkter og kultur hvad I vil) nok ikke er nogen, som har sat sig ned og lavet de betragtninger PHK har lavet. Og sandsynligvis på et noget mere detaljeret niveau.
Det ved jeg der er, for jeg kender flere af dem. De bliver bare ikke lyttet til af ledelsen.
Baseret på egne erfaringer, så er de fleste 'nix varianter unødigt komplekse, har funktionsproblemer og der bliver lavet ændringer i basale systemprocedurer fra version til version. Der er Windows trods alt mere stabilt.
Jeg har skrottet at køre med Ubuntu Server derhjemme fordi jeg blev træt af deres konstante ændringer.. og på grund af mange andre fejl som jeg ikke vil komme nærmere ind på lige nu. Jeg brugte ellers Ubuntu eller Debian i lang tid på hjemmeæsken, nu er jeg så gået KISS routen i stedet, fordi jeg simpelt hen synes det kræver for meget vedligehold at køre full-blown linux. Det er ikke det jeg laver til dagligt, jeg kan simpelt hen ikke følge med. Det er fint for de som er eksperter på området, men det er heller ikke dem der har tid til at assistere de almindelige dødelige med "trivielle" problemer. Skal dog siges jeg stadig kører med noget 'nix baseret, bare meget simplificeret, nemlig Xpenology.
Generelt synes jeg Microsoft har en god platform, der kun bliver bedre, hvor Linux lader til at være mere retningsløs og forgrene sig mere og mere. Det er fint, hvis man kan følge med, men det kræver immervæk en indsats fra den som ønsker at basere sit liv og levned på en linux platform. MS konsulenter er vel også nemmere at få fingre i hvis det er til erhverv ;)
Det ved jeg der er, for jeg kender flere af dem. De bliver bare ikke lyttet til af ledelsen.
Hvilket er som i rigtig mange andre firmaer.
Jeg skal ikke kunne sige hvorfor. Men en af grundene er ofte, at der kan være mange forskellige perspektiver på det der bliver udført.
Der kan være en teknisk sandhed som kolliderer med en strategisk eller forretningsmæssig sandhed.
I sidste ende er det, som med så mange andre ting, en afvejning af hvad vi kan, hvad vi vil, og hvad der så bliver den bedst mulige vej at gå.
Google har også samlet det hele i et stort repository, og der er nogen foredrag derude med hvorfor de har valgt at gøre dette. Jeg er ikke sikker på jeg er enig at det er en god ide, for jeg ser hellere at man definerer og vedligeholder grænseflader hårdt mellem moduler. I et Open Source miljø er det endda helt umuligt at udvikle alt software i samme repo, så der er ikke nogen muligheder uden om. Du skal ud i versionering og vedligeholdelse af stabile APIer til andre.
Google selv nævner at de får en række fordele af deres løsning, såsom:
Til gengæld kommer du i klemme med at bygge hele verden og de build-tools Google har er jævnt skræmmende (se, bazel.io for den åbne udgave af det). Corporate vil hellere skrive ting selv og lave eksplicit vendoring af alt udefra. Ikke mindst fordi du har nogen licensbetingelser der måske skal overholdes, så alt udefra skal godkendes af en jurist.
Både MS, Google, Apple, mfl., lider under at de har en isoleret verden "for sig selv" hvor du først skal lære alt deres interne tooling. Google-rygtet er at ca 2/3 af deres folk laver tooling til andre internt. Amazon har været lidt smartere fordi de mere eller mindre har åbnet AWS for resten af verden. På den måde har man noget mere ide om hvad der foregår, og du kan hverve folk der allerede starter med noget basisviden. Det er ikke helt dumt.
Du er sjov. Først sammenligne et hangarskib med et kode-repo og derefter bede os om, at lave kompleks (fordi det skulle være fair) matematisk regnestykke på baggrund af et restaurant-besøg...også på den italienske :)
Er der en udlægger ? Betaler nogen mere end andre ? Hvad har de spist ? Hvad er fair ? Jeg må have mere info!
Udover det lyder det total langt ude, at have al kode I et repo. Men der er mange ting Microsoft har levet gennem tiderne, som er langt ude. Det næste kunne godt blive en 3d app, så man kunne "gå" rundt I de forskellige git-repos man nu engang ikke havde plads til at downloade.
Til info klarer Perforce problemet 'et megastort central repo' for git ved at tilbyde man kan skære git repos ud af Perforce depotet. Det ('GitFusion') fungerer fint med mange små git repos der clones, men det bliver så også == PHK's løsning, hvis man skal have 250GB ud. Jeg skal ikke afvise GVFS (er det med vilje de overloader gvfs navnet?, hmm) kan bruges på sigt, når man får vendt back-slashene i deres OpenSource kode, he he. Det med at man ikke behøver have filer liggende før de bruges er jo en god ide.
@Marc: Ork jo, det er jeg ikke uenig i. Tror bare det er de færreste virksomheder hvor du kan dedikere dig 100% til linux-drift. Måske hosting miljøer er en oplagt mulighed for at udvikle de nødvendige kompetencer og have den nødvendige berøring. Udviklere også.
Nu involverer mit arbejde at jeg har kontakt med mange platforme og mange systemer, hvorfor jeg ikke har mulighed for at dedikere hele min arbejdstid til at hellige mig ét system eller én platform. Tror i øvrigt mange inden for IT Drift har samme oplevelse, at man bliver mindre specialiseret og mere generalist, i takt med at services bliver købt i byen, noget outsources osv. Det er i hvert fald tendensen på min arbejdsplads.
