Denne skjulte Linux-funksjonen får Windows til å se pinlig ut for utviklere

Microsofts WSL er imponerende, men avdekker fundamentale begrensninger i Windows' ressursforvaltning sammenlignet med Linux, hvor cgroups gir transparent kontroll og enklere interaksjon.

I årevis har vi sett Microsoft investere enorme ressurser i Windows Subsystem for Linux. Det ble posisjonert som den store likestilleren, broen som endelig ville gjøre Windows til en førsteklasses borger for oss som lenge har foretrukket Linux.

WSL er uten tvil imponerende. Å ha en Linux-kjerne som kjører side om side med Windows med dette nivået av integrasjon er et ingeniørmessig mesterverk. Likevel finnes det en funksjon som er så grunnleggende for Linux, så dypt vevd inn i arkitekturen, at selv de mest sofistikerte virtualiseringslag ikke kan gjenskape dens eleganse.

Det er ikke en blitsende brukergrensesnitt eller et trendy rammeverk, men innfødt, granulær og transparent kontroll over prosessressurser gjennom cgroups, eksponert via et enkelt filsystemgrensesnitt. Denne kapasiteten er grunnlaget for moderne containerisering, og den representerer et nivå av systemisk åpenhet som får Windows sin tilnærming til ressursforvaltning til å fremstå ikke bare som annerledes, men faktisk pinlig i sammenligning.

Cgroup-filsystemet

Kontroll ressursene gjennom enkle filer

Cgroups lar deg tildele, begrense og overvåke systemressurser som CPU, minne og I/O på tvers av grupper av prosesser (alle de tingene du vanligvis bryr deg om). Det alene er ikke uvanlig, da de fleste operativsystemer tilbyr en eller annen mekanisme for ressurskontroll.

Det som skiller Linux er hvordan denne kontrollen eksponeres. Cgroups vises som et filsystem, vanligvis montert på /sys/fs/cgroup. Å administrere ressurser blir en interaksjon med filer og kataloger, og for å opprette et begrenset miljø, oppretter du en katalog, skriver verdier inn i kontrollfiler, og tildeler prosesser til den katalogen.

Du kan begrense en prosess til en fast CPU-kvote og minnetak med noen få kommandolinje kommandoer uten å involvere noen kompilering, API-oppringninger eller stillaser. Systemet reagerer umiddelbart og forutsigbart (noe som er sjeldnere enn det burde være). Dette er ikke bare praktisk, men endrer også hvordan du tenker på systemet. Ressursforvaltning blir noe du kan eksperimentere med direkte, ikke noe som er skjult bak lag av verktøy.

I Windows er det nærmeste ekvivalenten jobbobjekter (den delen de fleste mennesker vagt husker eksisterer). De tillater gruppering av prosesser og anvendelse av begrensninger, men grensesnittet er helt annerledes. Interaksjonen skjer gjennom Windows API, og krever kode i C, C++ eller .NET. Funksjoner som CreateJobObject og SetInformationJobObject må kalles, håndteringer forvaltes, og feil behandles eksplisitt.

Selv enkle begrensninger krever en ikke-triviell oppsett. Bruk av kommandolinje er indirekte, vanligvis pakket inn gjennom PowerShell eller tilpassede verktøy. Som et resultat engasjerer de fleste utviklere seg aldri direkte med disse primitivene. De er avhengige av verktøy på høyere nivå som skjuler de underliggende mekanismene.

Grunnlaget for containere

Hvorfor containere føles innfødte på Linux

Cgroups er ikke en isolert funksjon. Sammen med namespaces danner de basis for containere. Når en container kjører på Linux, finnes det ingen ekstra abstraheringslag som håndhever begrensninger (ingen ekstra boks inne i en boks). Containerkjøringen oppretter en cgroup, skriver begrensninger og plasserer prosesser i den, og kjernen gjør resten.

I Windows følger containerisering en annen sti. Mange distribusjoner er avhengige av Hyper-V-isolasjon, som introduserer et virtuelt maskinlag selv når grensesnittet antyder noe lettvekts.

Dette gir isolasjon, men legger til kompleksitet og overhead. Selv i prosessisolasjon modus, er Windows avhengig av en kombinasjon av jobbobjekter og andre underliggende systemer som ikke ble designet som et enhetlig grensesnitt. Delene finnes, men de presenterer ikke en sammenhengende modell. En utvikler kan ikke navigere i en enkelt katalog og observere ressursbegrensninger i sanntid. I stedet er informasjonen spredt over API-er og administrative verktøy (uttynt).

Denne forskjellen blir åpenbar når man debugger. På Linux er ressursbegrensninger synlige og redigerbare gjennom filsystemet. På Windows krever forståelse av disse begrensningene navigering i verktøy som aldri ble designet for enkel inspeksjon.

Transparens og systemdesign

Ulike filosofier former opplevelsen

Linux har en tendens til å eksponere kjernens funksjonalitet gjennom enkle, konsistente grensesnitt. Filsystemabstraksjonen brukes gjentatte ganger fordi den er sammensatt og kjent. Dette senker inngangsbarrieren, og en utvikler som forstår det grunnleggende.

Shell-kommandoer kan raskt eksperimentere med ressursbegrensninger. Windows har tradisjonelt favoriserte abstraksjon, og kompleksitet er skjult bak API-er og administrerte grensesnitt. Dette gir en polert overflate, men begrenser den direkte kontrollen.

Jobbobjektsystemet er kraftfullt, men det krever engasjement for å forstå (og mye tålmodighet, veldig mye). Prestasjonsdata er tilgjengelige, men ofte gjennom fragmenterte systemer som ytelsestellere og WMI. Disse delene ble utviklet uavhengig av hverandre og presenterer ikke et enhetlig modell.

Resultatet er et system hvor kapabiliteter finnes, men ikke er lett oppdagbare eller sammenstillbare, og utviklere interagerer med verktøy i stedet for selve systemet. Når du er på Linux og en prosess oppfører seg rart, kan du umiddelbart se inn i cgroup-en for å finne ut hva som treffer en grense. På Windows føles den samme undersøkelsen som en plikt, som tvinger deg til å navigere gjennom flere forskjellige verktøy bare for å finne de samme svarene.

WSL-paradokset

Linux inne i Windows beviser poenget

WSL forsøker å bygge bro over dette gapet ved å integrere Linux inne i Windows. Det lykkes med å gi tilgang til Linux-verktøy, men det fremhever også den underliggende begrensningen. Når du kjører containere inne i WSL, bruker du ikke Windows ressursforvaltning. Du bruker Linux cgroups inne i en Linux-kjerne som kjører i et virtualisert miljø.

Windows-verten forblir separat, og dens native mekanismer er ikke en del av den arbeidsflyten. For å gi miljøet utviklere forventer, importerer Windows Linux i stedet for å utvide sin egen modell. Docker Desktop reflekterer det samme mønsteret. Containere kjører inne i en Linux virtuell maskin. Opplevelsen føles innfødt, men den underliggende funksjonaliteten tilbys ikke av Windows selv.

Praktiske konsekvenser

Hvor denne forskjellen faktisk viser seg

Denne forskjellen viser seg for meg i hverdagsutvikling. Når du er på Linux, er det enkelt å kjøre en lokal Kubernetes-klynge fordi verktøy som kind eller Minikube bruker vertskjernen direkte. Dine ressursbegrensninger oppfører seg akkurat slik de vil i produksjon, og du kan feilsøke alt ved hjelp av standard systemverktøy. På Windows ender den samme oppsettet vanligvis opp inne i en virtuell maskin, og du må konstant ta hensyn til det ekstra laget mellom arbeidsmengden din og maskinvaren, som uunngåelig formidler hvordan ressursene faktisk oppfører seg.

Når noe mislykkes, kan du ikke bare se på containeren; du må bekymre deg for hele orkestreringssystemet og virtualiseringsmiljøet samtidig. Du kan se det samme mønsteret i CI-systemer. På Linux kan du håndheve begrensninger via cgroups med nesten null overhead og administrere konfigurasjonen med enkle skript.

Windows-rutere, derimot, ser alltid ut til å kreve mer oppsett. Enten det er spesialiserte API-er, ekstra skriptingslag eller full virtualisering, er systemet kapabelt, men aldri helt så direkte. Over tid bygger den friksjonen seg opp, noe som er grunnen til at enklere systemer er så mye lettere å vedlikeholde og forstå.

En strukturell forskjell

Hvorfor dette gapet er vanskelig å lukke

Det som gjør cgroup-funksjonen spesielt pinlig for Windows, er at den avdekker noe grunnleggende om retningen til operativsystemdesign i skycomputing og containeriseringens tid.

Linux ble ikke designet fra starten med containere i tankene (til tross for hva mange tror). Cgroup-funksjonaliteten dukket opp gradvis, lagt til av kjerneudviklere som anerkjente verdien av å gi granulær ressurskontroll gjennom enkle grensesnitt. Likevel passer funksjonen så naturlig innenfor Linux-filosofien at det føles som om den alltid har vært der.

Filsystemgrensesnittet, tekstbaserte kontrollfiler, muligheten til å sammensette funksjonalitet med enkle skript, alle disse egenskapene er perfekt tilpasset Unix-tradisjonene som Linux arvet og utvidet. Windows mangler denne sammenhengen når det kommer til ressursforvaltning og containerisering. Funksjonene eksisterer, i en form, spredt over systemet, men de mangler den enhetlige visjonen og det konsekvente grensesnittet som gjør Linux cgroups så kraftfulle og tilgjengelige.

En praktisk realitet du ikke kan ignorere

Microsoft har investert enorme ressurser i å utvikle Windows-containere, i å forbedre...

Docker-integrasjon og bygging av WSL er imponerende tiltak, men disse innsatsene kan ikke overvinne de fundamentale arkitektoniske beslutningene som ble tatt for flere tiår siden (historien har momentum). Selskapet prøver i essens å tilpasse moderne containeriseringsevner til et system designet for en annen tid, mens Linux har utviklet seg parallelt med containeriseringsbevegelsen, og har økt kapasitetene utviklerne trengte på en naturlig og sammenhengende måte.

Jeg forventer ikke at Microsoft skal omskrive NT-kjernen for å speile Unix-filosofien; momentumet gjennom flere tiår er en vanskelig ting å endre på. Så lenge min primære interaksjon med et system innebærer å navigere gjennom lag av abstraksjon bare for å finne ut hvorfor en prosess står fast, føles "førsteklasses"-merket for Windows-utvikling mer som et markedsføringsmål enn en teknisk realitet. WSL er en strålende bro, men det er til syvende og sist en bekjennelse på at vertens egne primitive ikke ble bygget for den måten vi jobber på nå.

Hvis du vil lese flere artikler som Denne skjulte Linux-funksjonen får Windows til å se pinlig ut for utviklere, kan du besøke kategorien Linux.