Testversie Windows 10 biedt toegang tot Linux-bestandssystemen

Microsoft heeft previewbuild 20211 van Windows 10 vrijgegeven aan Windows Insiders die het OS in het Dev Channel draaien. De belangrijkste wijziging is de mogelijkheid om Linux-bestandssystemen te kunnen benaderen, waaronder via de verkenner.

Testgebruikers die previewbuild 20211 van Windows 10 draaien kunnen een schijf in Windows Subsystem for Linux 2 mounten met bijvoorbeeld ext4. Wie Windows en Linux dualboot draait, krijgt zo toegang tot Linux-bestanden vanaf Windows 10.

Gebruikers kunnen schijven mounten in WSL 2 door in Powershell met beheerdersrechten wsl --mount <DiskPath> te draaien. De Linux-bestanden zijn na het mounten ook in de verkenner te benaderen, door naar \wsl$ te navigeren en de betreffende map te openen.

Standaard probeert WSL 2 schijven als ext4 te mounten, maar het is mogelijk andere bestandssystemen te specificeren. Het is nog niet mogelijk alleen partities te mounten, alleen complete schijven en ook is er nog geen ondersteuning voor usb-sticks.

Een andere wijziging bij previewbuild 20211 is dat het mogelijk is te zoeken op bestandstype, protocol en apps bij het wijzigen van de standaard-apps om bestanden te openen. Microsoft bood de helft van de testgebruikers in de Fast Ring die mogelijkheid al sinds april, maar maakt de functie nu voor elke Windows Insider in het Dev-kanaal beschikbaar.

Reacties (120)

Op zich mooi. Nog fijner zou ik het vinden als je inderdaad USB schijven met ext4 kunt benaderen.

En als kers op de taart LUKS full disk encryption.

Maar goed, ik droom lekker verder

Wat ik nog steeds altijd merkwaardig heb gevonden is dat Windows full disk encryption kan toepassen wanneer Windows actief is.

Meestal in de Linux tak van sport moeten dat soort operaties met unmounted schijven gebeuren. En in het geval van LUKS tijdens de installatie draait alles in het geheugen via een live boot.

Kan iemand hier aan toevoegen hoe dit werkt aan de MS kant?

Iets gelijkaardig aan dit waarschijnlijk: https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3

M.a.w. in de vrije ruimte wordt een nieuwe partitie opgezet met encrypted blocks. In de uitleg hierboven gaat men op die manier van ext naar btrfs. Noot that btrfs encryptie los van LUKS kan. M.a.w. met bovenstaande kan je van een ext naar een encrypted btrfs gaan.

ps. Volgens mij gaat dit ook met een mounted ext naar btrfs werken. Maar geen idee of dat ook een goed idee is.

edit: merk op dat bij de conversie van ext naar btrfs enkel de metadata voor btrfs in die vrije ruimte terecht komt (en dat die dan initieel gaan verwijzen naar de ext blocks) en dat de conversie daarom zoals een btrfs snapshot kan teruggefloten worden -- waardoor je daarna, zoals bij snapshot revert, terug je ext partitie hebt). Maar bij encryptie wil je nu net dat de oude gegevens echt wel weg zijn (zelfs meerdere keren met 0xDEADBEEF overschreven), en echt wel vervangen worden door encrypted blocks. Anders kan je de harde schijf eruit nemen en de originele gegevens (die dus nu encrypted moeten zijn) toch nog lezen. Laat nu dat net zijn wat je net niet wil bij disk-encryptie. Dus gelijkaardig maar hopelijk niet gelijk. Anders maakt Windows een ernstige security fout (en als je van ext naar encrypted btrfs gaat, op deze manier, maak je er zelf zo één. Zoals 'n ITer die een hamer gebruikt in plaats van een schroevendraaier om een schroef in een plank te krijgen).

[Reactie gewijzigd door freaxje op 10 september 2020 21:17]

Dat gebeurd met Bitlocker. En als ik het goed begrijp nestelt bitlocker zich tussen Windows en de schijven door de IO.driver te zijn. Bitlocker encrypt en decrypt on the fly Windows krijgt en schrijft unencrypted bestanden via de Bitlocker IO driver

Ext4?? BTRFS onder Windows ;p

Ja eigenlijk wel. Tijd dat Microsoft misschien gewoon zelf maar van NTFS naar iets als ZFS of BTRFS moet overgaan.

Die verouderde filesystemen met hun beperkte mogelijkheden altijd ...

In Windows Server 2019 (en volgens mij 2016 ook al) kan je gebruik maken van ReFS

https://docs.microsoft.co...torage/refs/refs-overview

[Reactie gewijzigd door Mike2k op 10 september 2020 21:59]

Ik denk dat BTRFS beter is in de huidige en toekomstige staat.

Wat ReFS doet is eens in de zoveel tijd checken of data corrupt is. En BTRFS checkt dat volgens mij altijd en houd een soort check/journaal bij.

Journalling ? Dat doeet NTFS al, dat is bepaald niet uniek in BTRFS. Het "eens in de zoveel tijd checken of data corrupt is" is ook al normaal. Ik zie daar ook geen argument waarom BTRFS beter zou zijn.

Je hebt mij totaal verkeerd begrepen.

Hier een vergelijking:

https://www.phoronix.com/...page=news_item&px=MTA0NDA

ReFS heeft dus B+ (b-tree at the leaves) en als je NTFS kunt lezen schrijven dan ook ReFS. Waar zfs en BTRFS alleen B (b-tree)hebben. (Theoretisch gezien ondersteunt Linux ntfs in userland via fuse Dus reFS misschien ook?)

Maar Btrfs en zfs ondersteunen wel alle 2 snapshots waar ReFS Dat wel doet maar met een omweg.

Het artikel van Phoronix gaat uit van ReFS in 2012. Wellicht is er eea veranderd in 8,5 jaar?

Klopt. Daar had ik niet naar gekeken. (Was niet veel te vinden in een directe vergelijking)

Hier een forum discussie die meer op to date is;

https://forums.overclocke...fs-refs-apfs-etc.1195906/

Je bootschijf kan vziw nog geen refs zijn en als je issues hebt zijn er geen tools om ze op te lossen. Een jaar of 2 geleden een refs schijf over 2 SSDs mogen weggooien hierdoor.

Er is een versie van OpenZFS voor Windows. De onderliggende ZFS code is goed, die wordt vanaf OpenZFS 2.0 (die dit najaar uitkomt) gedeeld met FreeBSD, Linux en macOS. Ik weet alleen niet hoe goed de aansluiting met Windows is.

Het is van dezelfde developer als ZFSonOSX en daar geeft hij nu even prioriteit aan boven de Windows versie omdat macOS vanaf OpenZFS 3.0 een tier 1 platform moet worden naast FreeBSD en Linux.

[Reactie gewijzigd door Maurits van Baerle op 11 september 2020 00:15]

Het zou vooral goed zijn dat we C:\ een ZFS kunnen maken tijdens de installatie van Windows zelf. M.a.w. dat C:\Windows op een ZFS partitie staat. Zoals dus hoe we hetzelfde kunnen doen tijdens de installatie van tal van Linux distributies met ext4, btrfs, zfs, en zo verder (zelfs vfat).

En Windows moet gewoon USB keys met een normaal modern file systeem ondersteunen ipv enkel verouderd NTFS en extreem absurd idioot verouderd FAT32.

en wat is er 'naar jouw idee' zo verouderd aan ntfs dat je denkt zfs nodig te hebben,

voor dataopslag 'misschien' maar voor een systemdrive?

Ik denk aan Copy On Write, snapshots en subvolume support. Maar er zijn veel features aan bv. dan wel ZFS dan wel BTRFS die NTFS gewoonweg helemaal niet heeft.

Hier een lijstje: https://www.linuxlinks.com/btrfs/

ps. Met containers, docker, virutalisatie, en zo verder is het concept "systeemdrive" iets dat gedegradeerd is naar de jaren negentig. Misschien dat dat zo nog is op jouw laptopje. Maar IT en automatisatie gaat natuurlijk véél véél verder dan hoe jij jouw computer gebruikt. Het is bv. helemaal niet zo raar om een paar honderd Windows (of whatever operating systeem) instanties te beheren op één systeem (wat zelf ook een Windows zou kunnen zijn). Dan wil je vaak een deftig filesysteem i.p.v. iets dat enkel het concept "er is toch maar één systeemdrive?" hanteert. Neen. Dat is totaal niet zo, niet noodzakelijk. Op zulke omgevingen is het handig om te kunnen snapshotten, bijvoorbeeld. Is het handig om snelle copieen te kunnen maken adhv Copy On Write. Is het handig om .. en zo verder. En eigenlijk is CoW altijd handig. Ook op "er is maar één systeemdrive" scenarios (waarom zou je op C: tragere kopieen willen dan op je D: ?). Bovendien zou je met bv. een LiveCD je "systeemdrive" kunnen snapshotten, reboot naar je Windows, wat rommel op je "systeemdrive" installeren, LiveCD er terug in, revert snapshot en je "systeemdrive" staat terug zoals voorheen. Dat zou ook een handige feature zijn voor 'laptop met één systeemdrive'-gebruikers.

[Reactie gewijzigd door freaxje op 11 september 2020 10:35]

COW, snapshots en subvolume support op een USB stickje? Dat lijkt me nogal overkill voor die toepassingen.

En als je het concept "systeemdrive" zo gek vind, dan is "root file system" onder Linux zeker ook gek? Daar is er ook maar één van, per machine (fysiek of virtueel).

Dat root filesysteem heb ik inderdaad graag als een ZFS of BTRFS, wat ik dan ook precies aangaf in mijn eerdere comment.

"Het zou vooral goed zijn dat we C:\ een ZFS kunnen maken tijdens de installatie van Windows zelf. "

Is equivalent aan

"Het is momenteel goed dat we dit wel kunnen doen tijdens de installatie van heel wat Linux distributies"

Waarom zou je root file system een ZFS moeten zijn? Je wil je bootloader, kernel en andere OS files erop bewaren, en de mount points voor de andere filesystemen. Dat is praktisch gesproken read-only.

Om zo eens 2 dingen te noemen:
- Omdat je voor de update van je kernel er een snapshot van wilt maken (zodat je in geval van problemen makkelijk terug kunt).
- Op basis van een van de snapshots zien hoeveel blocks er zijn veranderd wat kan wijzen op een wijziging (hack) van je kernel?

exfat werkt toch prima? Werkt ook onder MacOS en Linux zonder problemen.

Welke besturingssystemen een type filesysteem implementeren is geen feature van het filesysteem zelf maar wel van de besturingssystemen die je op lijst. Daar ging mijn comment niet over.

"En Windows moet gewoon USB keys met een normaal modern file systeem ondersteunen ipv enkel verouderd NTFS en extreem absurd idioot verouderd FAT32. "

Dat doen ze dus ook, en dat wilde ik je vertellen.

Geen idee hoe stabiel het is, ik heb het nooit gebruikt, maar er bestaat een driver: https://github.com/maharmstone/btrfs

Beschrijft dit artikel niet juist dat je nu ext4 schijven kunt benaderen? Maakt het uit of ze via SATA/NVME/PCI-Express/USB zijn aangesloten?

Uit het artikel:

Het is nog niet mogelijk alleen partities te mounten, alleen complete schijven en ook is er nog geen ondersteuning voor usb-sticks.

Dus ik denk dat schijven via USB wellicht wel gaan maar USB-sticks niet. Ik weet niet wat het verschil is maar ik weet dat besturingssystemen er anders mee om gaan. Volgens mij kan je niet zo eenvoudig een partitietabel op een USB-stick maken en ik heb ook wel eens een embedded Linux-apparaat gebruikt die de ene wel maar de andere niet kon mounten.

De form factor maakt niet uit. Het is allemaal USB Mass Storage. De keuze om wel of geen partitie-tabel te gebruiken staat hier ook weer los van.

Linux mount geen disks of partities, maar filesystemen. Als je probeert /dev/sdb te mounten (hele disk) maar het filesysteem staat in de partitie /dev/sdb1, dan werkt je commando niet, en andersom ook niet. Dat is geen beperking van Linux, maar het gevolg van het verkeerde commando gebruiken.

Dan vraag ik me wel af wat de auteur bedoeld met

geen ondersteuning voor usb-sticks.

dit kan niet? Ik kan mij heugen ext4 te kunnen benaderen, kan zijn dat ik een extra driver heb geinstalleerd.

Er zijn inderdaad extra tools die dat kunnen, maar performance en stabiliteit daarvan zijn niet al te best voor zover ik weet. Mounten doorgaans ook als ext2, niet ext4.

Zou mooi zijn. Momenteel gebruik ik daar Ext2Fsd voor.
Recent nog getest met ext4 en werkt.

Een paar jaar geleden dacht ik ureka met Ext2Fsd om mijn ext4 schijven te benaderen onder win laptop.
Na een keer een belangrijke linux config file geedit te hebben onder Windows ging dat progie heel snel de deur uit. Linux en Windows gaan anders om met de volgende: Carriage Return,NewLine /// Carriage Return/new Line van een file..
Blijkbaar is dat probleem opgelost. heel fijn.

Da' ongeacht filesystem zo. In linux valt het op met vi (heb jd ineens ^M staan). Bepaalde programmas (zoals notepad++) kunnen specifiek daar tussen schakelen.

Helaas vaak genoeg scripts of configs hier op klem zien lopen.

Dat heeft werkelijk niks te maken met Ext2/Ext4. Zo werken line-endings gewoon in Linux vs Windows. Gebruik een teksteditor die het kan herkennen en omschakelen. Notepad++ of VS Code ofzo.

Dat hangt ook van je text editor af. Notepad is daar nooit goed in geweest, ik gebruik Notepad++ en zet voor de veiligheid ook nog eens verborgen tekens aan.

Mooi hè die standaarden
Windows = CRLF aka \r\n
Linux = LF aka \n
en
OSX = CR aka \r

Osx ook LF, alleen oeroude versies deden CR.

Gewoon notepad++ ipv Microsoft's eigen tools gebruiken. Op Windows bestaan er veel editors die perfect om kunnen met standaard UNIX text files (en die ook zo schrijven).

Dat is ook gewoon een kwestie van de juiste editor gebruiken. Oplossingen op een ander niveau (zoals ftp text mode) geven alleen maar problemen.

Als je even verder leest, is het de wsl-linux die de schijven leest. Het is msWindows die de draaiende wsl gebruikt om het filesysteem te lezen.

[toegevoegd]
Het blijkt dat vanaf msWindows via het powershell commando een disk onder wsl gemount wordt. Daar maak ik uit op dat je onder wsl zelf wel de partities kan mounten en dat dan via de \wsl$ route vanuit msWindows beschikbaar hebt.
Wel slordig dat ze alleen de eerste/default partitie kunnen mounten en 'vergeten' zijn dat ze ook in 1 keer alle partities hadden kunnen mouten, of een selectie mogelijkheid inbouwen zodat je er net iets meer mee kunt.

[Reactie gewijzigd door beerse op 11 september 2020 12:03]

Ik heb onlangs een NUC i5 10th Gen ingericht met docker containers op WLS 2, echt dramatisch sloom en vreet onwijs veel CPU en Memory.

Usecase:
VMware met Home Assistant
Dockers met onder andere NZBGet, Radarr, Sonarr, Transmission etc.

De reden dat we Windows nodig hebben is dat er een Windows only app draait voor de camera’s.

Ik vraag me af of de performance beter wordt als ik Windows virtualiseer in plaats van andersom.

Iemand ervaring hiermee?

Je moet je files op de \\wsl$-share zetten, dat geeft een gigantische performanceboost

Gaat dus precies tegen het hele idee in... Ik wil mijn sourcecode niet IN de linux omgeving hebben... alleen de apps. Kan ik net zogoed een VM spawnen en daarin gaan werken.

Wellicht kun je deze vraag beter stellen op het forum.. Want daarvoor is het forum.
En tbh, virtuele Windows machines op een NUC, die amper in staat is om 1 Windows versie te draaien, laat staan 2 of meer... Koop gewoon een échte server joh.

[Reactie gewijzigd door SilentDecode op 10 september 2020 23:40]

Een i5/10th moet prima kunnen virtualiseren.
Met voldoende geheugen zeker

Hier een i5-4570 met 16GB zonder problemen meerdere VM's naast elkaar.
Proxmox en ESX baremetal installeren, zal iig schelen.

@OMEGA_ReD : geen idee welke camera's het zijn, maar er kan zomaar een open source vervanger voor zijn ( MotionEyeOS onder Docker ? )

Zie deze pagina van Microsoft. Zoals pachacuti al aangeeft kun je een enorme performance boost halen door de files in de linux share te zetten.

https://docs.microsoft.co...em-for-faster-performance

In de VMware community zijn heel veel mensen die alles op NUC's draaien (wel met veel geheugen toegevoegd!), het is een prima platform voor thuis. Ik denk alleen dat je aanpak een beetje in de verkeerde volgorde is (als ik de uitleg goed begrijp).

Nu heb je op de NUC Windows draaien, daarop vervolgens WSL, met daar weer in docker waarop vervolgens weer containers draaien. Daarnaast heb je VMware op Windows draaien (Workstation?) met daarin een home assistant VM?

Als je het goed wilt inrichten doe je het volgende:
Je installeert VMware (ESXi) op de NUC.
Vervolgens draai je de volgende VM's:
- Windows voor je camera app
- Home Assistant
- Linux met docker en daar in je containers

Op die manier kun je de Windows VM limiteren qua resource gebruik en zal de rest van je workloads prima draaien.

Zoals jij het beschrijft kom je op 4 "lagen" in de Windows variant (Windows > WSL > Docker > Container), maar jouw oplossing heeft dat ook: VMWare ESXi > Linux > Docker > Container.

Klopt, alleen heb ik Windows vervangen door een hypervisor die er voor gemaakt is om dit uit te voeren in plaats van desktop software met als extraatje linux virtualisatie. Daar bovenop heb je nog een keer de winst dat je de resources van de Windows VM zelf kan managen.
Het gaat dus niet zo zeer om het aantal lagen, maar de software in de verschillende lagen die het verschil maken.

Mocht je zelf over die 4 lagen struikelen en je hebt toegang tot VMware software met licentie (Enterprise Plus) plus 16GB extra geheugen, dan kun je met vSphere Integrated Containers nog een verdere stap de goede richting op doen.

Als zelfs dat niet voldoende is dan ga je naar native containers op vSphere, dan heb je echter wel serieuze hardware nodig en een bak aan licenties (Enterprise Plus, NSX, Kubernetes on vSphere, etc), maarja dan zit je wel aan het summum qua performance waar zelfs een baremetal linux met docker niet aan kan tippen.

[Reactie gewijzigd door drocona op 11 september 2020 00:51]

Docker is geen laag tussen Linux en de container. Linux heeft de benodigde support (namespaces etc) al ingebakken. Docker is vooral een toolset om die containers te managen. Executables in de container draaien op dezelfde Linux kernel als de host omgeving.

Gewoon een hypervisor installeren. Btw als het gaat om BlueIris gaat, kan je het sowieso wel shaken, daar moet je een dedicated bak voor hebben. Verder gewoon naar het forum gaan voor dit soort vragen.

Home Assistant werkt ook prima in een Docker. Dit lost iig daar het CPU/Memory probleem op wat VMWare zal claimen.

Daarnaast zou op WLS 2 de performance van Docker prima moeten zijn, zolang al hun opslag op het Linux bestandssysteem staat.
Echter heb ik hier ook regelmatig 'vreemdheden' in gezien en zou ik als ik jou was kijken of er niet toch een oplossing is voor de camera's op Linux, of nog beter: in een Docker.
Zeker als de NUC weinig RAM heeft zou dan een bijna kaal host Linux os met daarop een aantal dockers ideaal zijn (aangezien deze geen CPU en RAM claimen tenzij ze het echt gebruiken.

Kijk in ieder geval of geen van de dockers zich aan het misdragen is met:

docker stats

of voor oudere docker installaties:

docker ps -q | xargs docker stats --no-stream

@OMEGA_ReD @Martin.Air heeft goede punten.

Je kunt ook overwegen om een Proxmox installatie te doen (Debian based).
Vervolgens 2 VM's maken:
- Windows voor je camera systeem
- Linux voor al het andere.

Proxmox zelf neemt weinig resources in, als je vervolgens zoveel mogelijk in docker containers draait op je linux VM dan hou je de rest over voor je Windows VM.

Zo, dat is mooi. Dit ging met externe softwares (zoals ext2read) wel al langer. Maar toch goed dat Microsoft steeds meer en meer begrijpt dat het Linux gebruikers moet ondersteunen.

Maar toch goed dat Microsoft steeds meer en meer begrijpt dat het Linux gebruikers moet ondersteunen.

Zo optimistisch was ik ook, een paar maanden terug. Toen maakte Microsoft bekend dat het mogelijk wordt Linux-applicaties te maken die niet op Linux draaien. Nu ben ik er niet meer zo zeker van dat de dagen van Embrace, Extend, Extinguish echt voorbij zijn. Vroeg of laat breidt Microsoft de ondersteuning van Ext4 uit met iets dat typisch is voor NTFS. Een specifieke vorm van encryptie? Bepaalde tekens in bestandsnamen? Geforkte bestanden? File change log? Hoe dan ook, dan creeëren ze een Ext4-partitie die niet of slecht werkt onder Linux, maar perfect te benaderen is onder WSL.

Ik hoop dat de tijd mijn ongelijk bewijst, tot die tijd vertel ik mezelf dat een oude vos slechts zijn haren verliest.

edit:
Ik verwarde een oude vos met een wolf in slaapskleren. Ik voel me een beetje Fred van Ria

[Reactie gewijzigd door 84hannes op 10 september 2020 21:43]

Ik heb best veel vertrouwen in de licenties die we (ik ben zelf een maintainer van een aantal open source projecten (geweest, nog steeds een beetje, etc)) de afgelopen jaren gebruikt hebben.

Ik heb geen enkele angst hiervoor. Als we Oracle aankonden door gewoon MySQL te forken als MariaDB, Sun door OpenOffice als LibreOffice en XFree86 door X.Org (en, en, en en want er gaan er veel zijn die zich nu misnoegd voelen omdat ik hun project niet vernoem) dan kunnen we eigenlijk om het even wat Microsoft tegen ons kan smijten aan.

Het is heel eenvoudig: juridisch gezien is wat we ooit in open source gereleased hebben, voorgoed in open source gereleased (enigzinds afhankelijk van de exacte licentievorm, maar dan nog). Niets of niemand draait dat nog terug. En wat er al aanwezig is, is gewoonweg belachelijk goed. VEEL beter dan en VEEL te veel voor om het even welke commerciële speler om iets alleen tegen te beginnen. Ook voor Microsoft. Ook voor een speler die letterlijk honderdduizenden programmeurs in dienst kan houden voor meer dan tien jaar. De open source wereld is nog veel, veel groter.

Het is, zeg maar, te groot voor de gehele Westerse kapitalistische economie. Het groeit nog steeds. Het zal blijven groeien. En dit zal nooit meer ophouden.

Het is zoals het beton in de wereld van architecten. Zoals de straten en autosnelwegen. Het gaat niet meer weg. Het is te groot en te veel geworden voor om het even welk bedrijf.

Microsoft's nieuwe CEO ziet dit ook in en heeft het enige wijze besluit genomen om dit te accepteren.

Het gaat niet echt om de magie van open source, maar om het ecosysteem. Als Microsoft het voor elkaar krijgt om iets Linux-achtigs te maken wat alleen op Microsoft-Linux werkt en daar dan heel veel community/geld/tijd achter kan hangen kan dat best vervelend zijn.

Daar ben ik het mee eens. Maar in dat geval heeft Microsoft ook iets gemaakt dat het het waard is dat er zich zo'n community achter wil scharen. Dan is dat prima. Zo heeft Microsoft al een aantal nuttige en mooie open source projecten die het nu uitbaat en beheert. En dat is goed. Waarom niet? Het zal ook altijd maar beperkt blijven tot de omvang van die community.

De mens, haar ideologieën en vooral de gepassioneerden in onze samenleving zijn erg divers. De strijd om dan wel de macht van één monopolie dan wel de veelvuldigheid van het gebeure 'open source' is niet gewonnen door Microsoft's monopolie of Windows of zo, maar door de open source wereld.

En dit in tegenstelling tot de olie industrie zonder dat er een regering van een groot land het moest opsplitsen.

Misschien dat dit wel zal gaan nodig zijn voor bepaalde Internetdiensten zoals social media, amazon, search, en zo verder? We zullen zien.

Zo heeft Microsoft al een aantal nuttige en mooie open source projecten die het nu uitbaat en beheert

Mijn vertrouwen in open source licenties is helaas beperkt. Zo heeft Microsoft een wrapper gemaakt die DirectX aan kan spreken vanuit WSL2. Die wrapper is open source dus je zou hem zonder al teveel moeite op Linux kunnen draaien. Maar op Linux heb je geen DirectX dus die wrapper is waardeloos.

Ik zie het probleem niet ...

Ik dus wel. De toekomst zal het uit moeten wijzen, maar Microsoft heeft me nog steeds niet kunnen overtuigen dat ze hun intenties hebben bijgesteld. De indruk die ze tot op heden nog steeds achter laten is dat ze vooral Linux technologie inzetten om er zelf beter van te worden, in plaats van samen te smelten met de open source wereld, met als doel dat iedereen er beter van wordt.

Het spreekwoord: "Een vos verliest wel zijn haren maar niet zijn streken!" staat nog steeds als een huis. En daarbij: wat verwacht je van een commercieel bedrijf die als hoofddoel heeft elk jaar méér winst te maken dan het vorige? Niks toch? Mij zullen ze in ieder geval nooit overtuigen van "juiste" intenties. Het draait vooralsnog nog steeds om "hun" intenties...

Microsoft is dan ook een bedrijf en geen liefdadigheidsinstelling.

Via MS Research wordt er ook al (vele jaren) veel onderzoek ge-opensourced of kennis daar van vrijgegeven. Hier ziet niet altijd een winst oogmerk achter, maar de rest van Microsoft heeft dat wel.

Embrace, Extend, Extinguish gaat nog altijd gewoon door. Microsoft is nu op veel vlakken Linux buitenspel aan het zetten door de hele Linux wereld te degraderen tot Windows "app". Aan de ene kant een mooie ontwikkeling dat Linux 'native' op Windows te gebruiken is, maar het doel van MS erachter is wat minder.

Ik denk dat we over twee verschillende dingen hebben.

• Jij denkt dat de open source community niet kapot te krijgen is.
• Ik denk^* dat Microsoft nooit zal stoppen dat te proberen.

^*Ik weet dat niet zeker, maar zoals @batjes al stelt: Microsoft is geen filantropische instelling. De enige reden dat ze open source (nu lijken te) omarmen is uit commercieel belang. Dus als ze geld kunnen verdienen door open source te stimuleren zullen ze dat zeker doen, maar als ze gewin zien bij tegenwerking dan zullen ze ook niet twijfelen.

Het gaat eerder als volgt:

De doelstelling die ik voor ogen had ergens in 1997 of 1996 toen ik me met open source dingen begon bezig te houden zijn bereikt (en meer), die doelstellingen zal Microsoft niet meer ongedaan kunnen maken.

Zou het kunnen dat Microsoft die 'en meer' kan vertragen? Misschien zo. Maar ik zie dan enkel een vertraging als mogelijkheid en geen stopzetting van die 'en meer'.

Ik waardeer je optimisme, maar ik ben er niet van overtuigd.
Ik zou Linux graag als het meest succesvolle open source project willen zien: Het begon als een hobby, mensen die in hun vrije tijd code schreven en deelden. Ergens onderweg is Linux zo belangrijk geworden dat fabrikanten (Intel, Realtek en ja, ook NVidia) het belangrijk genoeg vonden om mee te schrijven. Ofwel aan de kernel, ofwel met closed source drivers die ze zelf aanleverden. Dat moment zou ik de singularity willen noemen: het kritische moment waarop de commerciële markt Linux omarmde. Ik weet niet of ieder project zo'n singularity kent, en of die ook zou ontstaan als je nu opnieuw begint. Windows is een stuk stabieler en MacOS een stuk uitgebreider dan toen Linux begon, dus wellicht zou de kritische massa nooit opgebouwd worden. Hetzelfde vrees ik voor complexe taken als beeldherkenning en digitale assistenten: ik zou graag een offline asssitent hebben waaraan ik kan vragen om dingen op internet op te zoeken, maar Google Assistent en Siri zijn heel ver gevorderd en de Open Source alternatieven lopen zo ver achter dat ik betwijfel of deze projecten ooit hun singularity zullen bereiken.

Maar ik hoop met je mee.

Ik wil hier wel even aan toevoegen dat dat wat jij "Linux" noemt niet één project is maar wel letterlijk tienduizenden projecten. Zelfs honderdduizenden. En dat MacOS bv. ook heel veel van diezelfde projecten hergebruikt om er MacOS als besturingssysteem mee op te bouwen.

Linux als individueel project is enkel de kernel. Dat is ook een erg succesvol project. Maar wanneer jij "Linux" op je laptop installeert, dan installeer jij een Linux Distributie die uit tienduizenden andere open source projecten bestaat. Waarbij Linux enkel de kernel is.

Wat ik Linux noem is de Linux kernel. Maar je hebt gelijk dat alle projecten er omheen bijgedragen hebben aan het succes van de kernel: zonder bijvoorbeeld GCC was er waarschijnlijk weinig van terecht gekomen.

Vergelijk het met het ontstaan van leven. We zeggen, beetje vloeibaar water, geeft het tijd en er zal wel leven ontstaan. Maar we weten niet zeker of die voorwaarden echt voldoende zijn. We weten alleen dat het een keer gelukt is in een situatie waar inderdaad vloeibaar water is. Zo ook met het Linux of GNU/Linux, zo u wilt: we kennen de omstandigheden waarin het een succes was, maar we weten niet wat de minimale voorwaarden zijn.

Ik heb best veel vertrouwen in de licenties die we (ik ben zelf een maintainer van een aantal open source projecten (geweest, nog steeds een beetje, etc)) de afgelopen jaren gebruikt hebben.
<knip>
Het is heel eenvoudig: juridisch gezien is wat we ooit in open source gereleased hebben, voorgoed in open source gereleased (enigzinds afhankelijk van de exacte licentievorm, maar dan nog). Niets of niemand draait dat nog terug.

Maar dat werkt alleen als Microsoft een bestaande driver heeft hergebruikt. Als ze de code helemaal zelf hebben geschreven mogen ze iedere licentie gebruiken die ze willen.

Het is nu niet alsof we, de open source wereld, er nog nooit in geslaagd zijn iets te reverse engineeren.

We deden de afgelopen twintig jaar en langer niet anders dan dat.

Alleen kan die Extinguish dus niet. Net dankzij de licentie. Stel dat MS ext4 gaat uitbreiden. De enige manier dat ze dat kunnen doen is door een volledig eigen implementatie van Ext4 te schrijven (wat niet moeilijk mag zijn voor MS) maar dan ben je Ext4 al niet meer aan het uitbreiden, maar aan het vervangen. Voor het uitbreiden van bestaande code moet je simpelweg voldoen aan de GPLv2 voorwaarden, elke aanpassing moet opnieuw openbaar gemaakt worden. Dus als zij bijvoorbeeld een eigen vorm van encryptie willen toevoegen, dan moeten ze die implementatie ook open source maken.

ext4 heeft support voor extended security attributes, voor bijvoorbeeld seLinux. Microsoft kan een eigen extended security attribute toevoegen, voor een eigen encryptie module. Dat heetf geen impact op de ext4 driver, en geen licentie-gevolgen. Je hebt dus niet gelijk als je zegt dat het nodig is om een volledig eigen implementatie te schrijven. Het is zelfs niet eens nodig om de bestaande implementatie aan te passen.

Extinguish is geen kwestie van techniek of licenties maar van marketing. IE6 had technisch gezien nooit enig marktaandeel kunnen hebben,maar het drukte alle concurrentie weg.

Voor MS is het alleen maar een kwestie om haar linuxprojecten, nu een omgeving binnen Windows, straks een eigen Windows distro, in enige mate incompatible te maken. Net zoals Android geen linux is voor de meeste practische doeleinden, is MS Windows dat straks ook niet, maar Windows gaat wel dieper naar binnen en haalt meer overhoop.

[Reactie gewijzigd door mae-t.net op 12 september 2020 00:09]

Kijk opnieuw naar het DirectX voorbeeld. Microsoft heeft DirectX zelf niet openbaar gemaakt, alleen de Wrapper naar DirectX. Dus op Linux gaat het niet werken. Ze hoeven de Wrapper niet te extinguishen want mensen zijn hierdoor toch al gebonden aan WSL: Linux is hiermee buiten spel gezet. Maar als ze ook WSL willen blussen is dat ook niet moeilijk: dan maken ze DirectX incompatible met de Wrapper. Klaar ben je. Hetzelfde geintje kunnen ze met Ext4 uithalen: gewoon een paar system calls naar Windows en ze zijn weer helemaal in controle.

maar dan ben je Ext4 al niet meer aan het uitbreiden, maar aan het vervangen.

Dat is toch ook wat Microsoft met Visual Java deed? Een eigen implementatie schrijven die niet compatibel was met die van Sun Microsystems. Ze hebben niet de code, maar de taal uitgebreid.

Maar wel enkel op windows.
Nu werkt wat op windows werkt ook enkel op windows.

Wat op linux werkt blijft op linux werken.

Ik verwacht een beetje dat Windows 14 (of hoe het tegen die tijd ook heet) een linux distro is. Inderdaad even goed uitkijken.

Misschien moet je die file-system-drivers voor msWindows niet meteen weg gooien.

Als je iets verder leest, zie je dat je een draaiende wsl nodig hebt om vanuit msWindows het filesyteem te benaderen. Dat heeft veel meer overhead dan de filesystemdriver. Om maar te zwijgen van het benodigde onderhoud: de msWindows omgeving wordt wel netjes bijgewerkt maar de wsl-linux omgeving moet je zelf onderhouden.

Dit wordt wellicht een killer feature voor developers die afhankelijk zijn van Docker Desktop zoals mijzelf.

Op dit moment kent Docker wegens de interne fileshare een behoorlijk hinderlijke delay, veroorzaakt door een conversie van data wat nu nog aangeboden wordt dmv Samba.

Requests die nu nog 2,6 seconden duren, nemen dan nog maar 100ms van je tijd in.

Als je met de huidige opzet vanuit WSL2 bestanden serveert heb je al een zeer goede performance. Als je de sync dan van en naar het Windows FS opzet heb je een prima ontwikkelomgeving.

de populariteit van o.a. Docker heeft MS inderdaad verplicht meer moeite te moeten doen voor het supporteren van het linux platform. Eindelijk! Third party drivers kunnen dit al sinds vorige deccenia...

nou ben ik al aardig op leeftijd, maaarehh: zat dit er niet vanaf het begin in met het Posix Subsystem?
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Nee. Dat gebruikte gewoon NTFS, en had verder ook niets met Linux te maken.

Ik moet toegeven, de integratie met de WSL distro's en Windows is beter en beter met iedere versie.

Er is niets zo leuke om WSL2 Debian te draaien met Docker for Windows ( WSL2 versie ). En dan via Visual Studio Code containers te starten met je code in de Debian met een volume. De flexibiliteit om snel een PHP/GO/... container te starten, met je code integratie en plugin support.

Was geen voorstander van WSL2 wegens de hoge geheugen gebruik maar met de huidige 8GB beperking, is het perfect doenbaar. En vooral de bestand acces snelheid is een enorm voordeel als je code compileert.

De ondersteuning voor GPU access vanuit de Distro's word ook beter en beter.

Wie Windows en Linux dualboot draait, krijgt zo toegang tot Linux-bestanden vanaf Windows 10

Los van het lezen van het bestandssysteem: dit impliceert dat windows überhaupt dual-boot gaat ondersteunen. Dat is op zich al nieuws. Op dit moment is om de haverklap je bootloader weg, is windows met linux aan het ruziën over tijdsinstellingen, en met een beetje pech is je hele linux-partitie foetsie (vooral als windows "your files are exactly where you left them" tegen je zegt ).

Dat windows geen linux-bestandssysteem kon openen was wel mijn minste probleem bij dual-boot.

[Reactie gewijzigd door bwerg op 10 september 2020 23:09]

Als je dual-boot draait op een enkele 'schijf' dan heeft wsl waarschijnlijk wel moeite om de (juiste) partitie voor je linux data te vinden. Dat moet je dan zelf in wsl mounten waarna je vanaf windows, via wsl er wel goed bij kunt.

Dat de dual-boot na een grote msWindows upgrade weg is, zal wel blijven. Alleen als je de linux en windows omgevingen echt op verschillende 'disks' hebt staan en als je de uefi goed inricht zodat je vanuit uefi kiest welke disk je boot, dan zou msWindows daar vanaf moeten blijven.

Het is wel vreemd als de linux partities van je disk echt weg zijn na een msWindows update. Zelf kan ik mij dat alleen voorstellen als je handmatig een upgrade hebt opgestart vanaf een extern medium. Want dat is de enige keer dat de partitie indeling langs komt.

Over de klok-tijd uit het systeem: msWindows gaat in de regel uit van een lokale tijd en kan/wil dat niet eenvoudig anders doen. Linux heeft er wel faciliteiten voor. Daar kan je gewoon netjes instellen dat je de bios tijd in lokale tijd wilt draaien. Dat moet je bij linux dan zowel netjes in de kernel als ook netjes in de tijd-sync (ntp of wat je gebruikt) software instellen.

Het is wel vreemd als de linux partities van je disk echt weg zijn na een msWindows update. Zelf kan ik mij dat alleen voorstellen als je handmatig een upgrade hebt opgestart vanaf een extern medium. Want dat is de enige keer dat de partitie indeling langs komt.

Dit was bij de gratis upgrade van windows 7 naar windows 10. Daarbij maakte windows zelf wat back-up-data aan, en schijnbaar dacht hij dat de linux-partie daarvoor wel geschikt was.

Ja, het is allemaal mogelijk en ik heb het ook gedaan, maar dat je de hele tijd bootloaders moet fixen en dergelijke haalt voor mij de lol er wel af.

Bij de upgrade van 7 naar 10.... dat is een spannende. Als dat een update/upgrade was dan kan ik mij ook niet voorstellen dat de setup een linux partitie heeft opgegeten. Maar als je zoals ik meestal deed eerst alles update voor de licentie activatie en daarna toch nog een schone installatie, dan is het die schone installatie. Maar daarmee toegegeven, de resultaten van de upgrade heb ik nooit echt goed bekeken.

Overigens ben ik van dual boot al vrij snel overgestapt op virtualisatie (vmware workstation) en daarna gewoon meer systemen omdat de oudere systemen het ook nog goed genoeg bleken te doen.

Als dat een update/upgrade was dan kan ik mij ook niet voorstellen dat de setup een linux partitie heeft opgegeten.

Ik heb gewoon letterlijk een dd-kopie van de linux-partitie (mijn low-level backup ) vergeleken met na de upgrade en de partitie was gewoon overschreven. Misschien niet alles, hoor. Maar het begin was in ieder geval weg.

Ben wel geïnteresseerd, wat is de (technische) reden dat USB-sticks nog niet kunnen?

Volgens de WSL2 FAQ wordt in het algemeen geen USB devices daaruit volgt (naar mijn inzien) dus ook geen USB sticks. Exacte details waarom USB verder niet werkt in WSL2 weet ik echter niet.

https://docs.microsoft.co...20USB%20device%20support.

Benaderen als in lezen? Of kun je er meer mee.

Opzig we handig, ik heb nog steeds een windows installatie draaien en een gedeelde schijf tussen windows en linux, als ik deze hiermee van ntfs naar f2fs of ext4 over kan zetten zou dat fijn zijn.
Unix permissies werken niet goed in ntfs. Ik vraag me af of er problemen / beperkingen zijn met het lezen / schrijven van linux partities, gezien de verschillende permissiesystemen.

Ik moet verder zeggen dat ik mijn windows partitie in maanden niet gebruikt en dat ik misschien de gedeelde schijf toch een keer om zal gooien.

[Reactie gewijzigd door qlum op 10 september 2020 21:39]