Microsoft wil exFat-bestandssysteem beschikbaar maken in Linux-kernel

Microsoft gaat zijn exFat-bestandssysteem vrijgeven voor toevoeging aan de Linux-kernel. Het propriëtaire bestandssysteem wordt veel gebruikt in Windows en in opslagapparaten zoals sd-kaartjes en usb-sticks.

Microsoft schrijft op zijn opensourceblog het belangrijk te vinden dat de Linux-community exFat kan gebruiken en daarom de technische specificatie van het bestandssysteem vrij te geven. Dat moet resulteren in de toevoeging van ondersteuning voor exFat aan de Linux-kernel en Microsoft zegt daarbij te zullen helpen. Ook hoopt Microsoft dat er uiteindelijk een Linux-kernel met exFat-ondersteuning in de Linux System Definition van het Open Invention Network wordt opgenomen.

ExFat wordt gebruikt in Windows en is ook het officiële bestandssysteem voor sd-kaartjes met een hoge capaciteit. Het bestandssysteem is gebaseerd op Fat, een van de eerste bestandssystemen voor floppy's. De exFat-variant bestaat sinds 2006. Microsoft heeft de patenten in handen en bedrijven moeten daarom licentieovereenkomsten afsluiten om er gebruik van te maken.

Reacties (136)

Microsoft heeft de patenten in handen en bedrijven moeten daarom licentieovereenkomsten afsluiten om er gebruik van te maken.

Nou, dan moeten ze híer eerst eens wat aan doen. Niemand zal het toch willen implementeren in een vrije open source kernel als je daar patenten mee schend?

Misschien kunnen ze het beter als fuse implementatie bouwen en het buiten de kernel laten. Dan kan iedereen die er wel licenties voor wil betalen het nog los aan z’n systeem toevoegen.

Microsoft wil de exfat patenten onderbrengen bij het Open Invention Network (OIN) en dan is het gedaan.

Microsoft wil de exfat patenten onderbrengen bij het Open Invention Network (OIN) en dan is het gedaan.

WTF??? Even serieus: _Waarom_ is de Open Invention Network ook weer in het leven geroepen?
Degenen die wel enig geschiedenis-besef hebben (het gaat hier over ca 2008), zullen zich hopelijk herinneren, dat bedrijven zich hierin verenigden omdat ze werden aangeklaagd door Microsoft, nota bene voor het gebruik van het FAT-bestandssysteem!

Dus MSFT wil nu patenten waarmee ze vroeger hun tegenstanders aanvielen, gaan onderbrengen in het verdedigings-vehikel dat is opgezet om die tegenstanders tegen MSFT te beschermen? De ironie

nieuws: Microsoft klaagt TomTom aan voor patentinbreuk
nieuws: TomTom wordt lid van Linux-patentgroep

Ed: Degenen die zich de werkwijze van het OIN herinneren, zullen waarschijnlijk ook het volgende voordeel voor MSFT kunnen herkennen:
-Zij die gebruik maken van de patenten uit de patent-pool van het OIN, mogen dat doen zolang ze de aanbieders van die patenten niet aanklagen. Dus iedere partij die gebruik maakt van de exFAT patenten die in het OIN worden ondergebracht, zien ervan af om MSFT aan te klagen voor eventueel patent-inbreuk.

[Reactie gewijzigd door kidde op 29 augustus 2019 12:53]

2008 is meer dan 10 jaar geleden. In die tijd is de bedrijfsvoering bij Microsoft 180 graden gedraaid.

Nou, nee, dat klopt dus niet helemaal. Het OIN is een 'patent-pact'; dat wil zeggen dat je alleen van de patenten gebruik mag maken als je je aansluit bij het OIN als lid.

Dat is iets heel anders dan "patenten doneren aan de Linux-community" (zoals een hoop media dit onterecht noemen) of "dan is het gedaan", en het faalt dan ook bijvoorbeeld de "Desert Island test" van de Debian Free Software Guidelines.

Ik kan helaas geen +3 geven op reacties op mezelf, maar wat mij betreft had dit wel in het artikel zelf mogen staan. Dit is cruciaal voor een kernel implementatie.

1e regel: Microsoft gaat zijn exFat-bestandssysteem vrijgeven voor toevoeging aan de Linux-kernel.

Onder vrijgeven versta ik dat het licentievrij is. De techniek was immers al vrijgegeven in de zin van patenten.

"Onder vrijgeven versta ik dat het licentievrij is."
Niet per definitie.
Ik kan mij bv voorstellen dat MS de Linux community iets gratis wil geven, maar zeer zeker niet wil dat bv Apple er gebruik van gaat maken.

Waarom, Apple en Microsoft staan op redelijke goede voet met elkaar. In vergelijking tussen Microsoft & Google of Apple & Google.

Inderdaad, als Microsoft Apple niet had geholpen in 1997 had Apple nu zeker niet meer bestaan.

Sindsdien werken ze meer samen. macOS zou bijvoorbeeld niet zo groot zijn geworden zonder Office.

exFAT zit al jaren in macOS

Apple is een slecht voorbeeld.
Veel van "Apple's" software wordt door Microsoft gemaakt en gerebrand naar Apple.
Little known fact...

[quote]
1e regel: Microsoft gaat zijn exFat-bestandssysteem vrijgeven voor toevoeging aan de Linux-kernel.

Onder vrijgeven versta ik dat het licentievrij is./quote]
Dat lijkt me nogal onhandig voor de Linux kernel, licentie-vrij. De kernel zelf is namelijk GPL (General Public License) en dus niet licentie-vrij. Ik ga er dus van uit dat Microsoft een licentie-keuze gaat aanbieden, commercieel of GPL.

volgens mij als je iets toevoegt aan de linux kernel die open source is dan aanvaard je daarmee ook dat de code die je toevoegt onderdeel van dezelfde open source linux code wordt.
Het toevoegen betekend feitelijk dat je het open source maakt en doe je dat kun je geen geld meer voor het patent daarop vragen.

Nope, de technologie die je implementeerd is gepatenteerd, ook al stopt de patenthouder de code in een open source project, dan is de project eigenaar verantwoordelijk voor het rejecten van deze implementatie.

Wat ze moeten doen is het patent in het Open Invention Network (OIN) onderbrengen zoals terloops wordt vermeld in het artikel en uitgelegd in andere comments hierboven.
Op dat moment is het pantent wel geldig maar valt het onder een communal open source licentie, wat betekent dat ze in het ergste geval hun pantent kunnen terugtrekken (bijvoorbeeld in het geval van andere patentzaken etc), en kan iedereen die de OIN communcal licentie accepteert er gebruik van maken.

Open Source is ongelijk aan publiek bezit. Jij bedoeld het vrijgeven van het gebruiksrecht van de vrijgegeven broncode.

Je kunt prima geld vragen voor vrijgegeven broncode.

Nou eigenlijk heb ik het herhaald, want het staat er wel in andere bewoording.

“Hoopt” klinkt niet echt beklonken

Tja, MS gaat die Linux kernel niet bouwen noch er opdracht toe geven, dus veel meer dan hopen kunnen ze nou eenmaal niet.

Jawel, Microsoft is al een tijdje een vrij actieve contributor aan Linux en opensource projecten... een van de grootste zelfs.

https://www.theinquirer.n...code-canonical-linux-2632

Google er maar eens op er is heel veel over te vinden, ze doen blijkbaar ontzettend veel maar op de een of andere manier krijgen ze de credits er niet voor die bedrijven als Google wel krijgen.

[Reactie gewijzigd door MicGlou op 29 augustus 2019 11:47]

If you can't beat them, join them. En dat alles vanwege eigenbelang, niet omdat Microsoft ineens "sympathie" heeft voor open source. Ze bereiden zich voor op een nieuwe strategie en verdienmodel. De relevatie van Linux is zó groot dat ze niet meer anders kunnen. Anders missen ze de boot....

Iedere contributor doet het uit eigen belang, dat is echt geen argument. Maar goed... jij doet eigenlijk precies wat anderen nog steeds doen en waarom ze nooit de credits krijgen voor dit soort zaken, Microsoft is niet meer het bedrijf wat ze vroeger waren... maar op de een of andere manier is het lastig om die visie bij mensen te veranderen.

Het duurt gewoon veel langer om het vertrouwen te herstellen. Nu onder Satya Nadella is het snel een redelijk fair spelend bedrijf geworden. De scherpe kantjes zijn ervan af. Ik respecteer dat, maar mijn achterdocht is niet weg. Wie zegt dat er volgend jaar niet weer zo iemand als Steve Ballmer aangesteld wordt? Ik vertrouw ze tegenwoordig genoeg om hun diensten te gebruiken, maar voor ik ze als Linux aanhanger als serieuze steunpilaar van Linux (en de hiermee onlosmakelijk verbonden open-source beweging) zal zien zal er nog een hoop moeten gebeuren.

Even een wat extremer voorbeeld. Zou je bijvoorbeeld Facebook ooit nog vertrouwen als ze met een totale "privacy first" strategie komen? Ik niet. Ze laten nu zien dat hun bedrijfscultuur en moraal door en door ziek is. Een nieuwe topman en een fris PR verhaaltje zal daar wellicht wat verandering in brengen maar als een bedrijf zo snel van slecht naar goed kan veranderen dan kan het omgekeerde ook net zo goed gebeuren. Ik zie liever een bedrijf dat ethisch handelen heeft verankerd in hun identiteit, in plaats van alleen maar meewaait met de grillen van de huidige topman.

[Reactie gewijzigd door GekkePrutser op 29 augustus 2019 22:34]

Volgens mij is het niet een geval "van slecht naar goed"; het is eerder een geval dat je je bedrijfsfilosofie verandert. Onder Steve Ballmer en al zijn voorgangers, was de gedachte (en dus de bedrijfsfilosofie) dat openbare broncode eng is (dan kunnen anderen het namaken en daar dan geld aan verdienen). Open Source heeft inmiddels ruimschoots bewezen dat dit niet (perse) het geval is; als jij met openbare code een prachtig stukje software neer weet te zetten, dan zijn er mensen die er best voor willen betalen (vooral voor support en (dus) een garantie dat er patches komen als jij een probleem ervaart).

Een mooi voorbeeld hiervan is Lilypond (http://lilypond.org/), een programma waarbij muzieknotatie in tekst gevangen kan worden en er voor zorgt dat de score er erg professioneel uit komt rollen als pdf. Professionele muzikanten hebben er geld voor over om nieuwe features te krijgen. Grappig was te zien dat jaren terug dit al best wel scrum-achtig gebeurde: De feature werd aangevraagd, de bouwer gaf aan hoeveel tijd/moeite het zou kosten (en dus hoeveel geld hij nodig had), dat werd dan verzameld door de geintereseserde partijen (je bent zelden de enige die het nodig heeft) en als het er was, werd het gebouwd. Maar goed, back on topic.

Microsoft heeft dus ingezien dat het helemaal niet eng is om broncode vrij te geven. Dat de producten er alleen maar beter op worden. Omdat het verdien model van Microsoft steeds minder gebaseerd raakt op Windows, maar steeds meer op Azure (Microsoft wil de cloud boot nog halen), is her Microsoft veel aan gelegen om er voor te zorgen dat Linux ook op Azure kan draaien... dat is dan ook meteen een van de grootste bijdrages geweest. exFat ondersteuning in de Linux kernel zal zeker nut hebben: als er steeds minder windows gedraaid wordt, is dit ook geen verdienmodel meer... als alle licentiehouders met elkaar gaan zitten en iets anders als standaard afspreken, is het snel gedaan met exFat. exFat als standaard is handig omdat iedereen windows draaide... maar dat is dus steeds minder het geval. (gebaseerd op de verhalen dat de desktopmarkt steeds kleiner wordt)

Nee, dat klopt. Als een bedrijf je "dood" wil, dan zullen ze dat vertrouwen ook niet meer terugkrijgen. Ik keur niet af dat ze op zoek zijn naar een ander verdienmodel. Ze moeten wel. Maar Microsoft draagt in de Linux kernel alleen bij op de punten die henzelf dient, niet het algemeen belang. En dus vind ik de "sympathie" naar Microsoft voorbarig. Het spreekwoord die gaat over "vos" en "streken" bestaat niet voor niks.

Het feit dat Microsoft exFAT wil (laten) implementeren in de Linux kernel betekent dus dat ze zich ergens op aan het voorbereiden zijn. Misschien zelfs een nieuwe variant op Windows, draaiend op een breed ondersteund exFAT, wellicht omdat Microsoft het niet ziet zitten om een dergelijk systeem op een Linux/Unix (bijvoorbeeld EXT) bestandssysteem te laten draaien? Of misschien omdat dit niet lekker strookt met het bijbehorende rechtensysteem van bijvoorbeeld diezelfde EXT? De tijd zal het leren waartoe dit met exFAT dient....

Het is een aanname die ik doe. Misschien zelfs vergezocht, maar ik heb wel vaker gekke uitspraken gedaan over Microsoft in het verre verleden. En die zijn bijna allemaal uitgekomen.

[Reactie gewijzigd door Qalo op 29 augustus 2019 12:58]

Misschien wel een Windows met Linux kernel.

Ja, dat bedoelde ik ook. Windows met Linux kernel, en dan geïnstalleerd op exFAT. Zoiets eigenlijk...

Op zich passen de stappen die Microsoft met betrekking tot Linux hebben gezet perfect in hun beproefde 'Embrace, extend, and extinguish'-methode.
Ze hebben linux nu omarmd: Zetels gekocht in bestuur van the Linux Foundation, ze zijn bezig allerlei onderdelen in Windows aan het integreren en Windows onderdelen aan Linux toe te voegen (extend) en als ze zo doorgaan is er straks niets meer dat je wel in Linux kunt doen maar niet in Windows.

Windows is niet waar ze op verdienen. Office, exchange (ugh) wel. Kan minder schelen waar dat dan op draait.

vergeet Azure niet... die wordt steeds belangrijker.

Ik weet dat MS op meerdere punten al lange tijd erg naar Linux kruipt, goede zaak. Maar ze gaan toch geen kernels bouwen zelf?

en WSL2 dan?

Sterker nog dat hebben ze al gedaan. Azure Sphere heeft een eigen MS Linux Kernel
https://techcrunch.com/20...-for-its-new-iot-service/

En dat terwijl Google juist de andere kant op beweegt en meer en meer Closed Source maakt: vanuit Android overhevelen naar Google apps, service, e.d. Voor Android tenminste.

Eens verdacht, altijd verdacht, eens goed gedaan, altijd de goedzak, blijkbaar.

Dat report is van 2012. In 2017 staan ze al niet meer vermeld.

https://www.linuxfoundati...rnel-report-landing-page/

Waarom zouden ze dat niet doen? Microsoft wil de driver in de kernel, dus moeten ze hem zelf maar schrijven. Bovendien hebben ze het meeste ervaring met exFAT.

De Driver is het probleem niet, die was er al.

Maar als je de driver gebruikt moet je rechten aan MSFT betalen ivm. gebruik van patenten. (paar EU per apparaat).
Gevolg daarvan was een FAT driver die het net even anders doet dan officieel ==> niet een 100% correcte FAT driver ==> geen afdrachten.
Ander gevolg apparaten die FAT in het geheel niet ondersteund.

Wel/Geen driver is niet het issue, afdrachten ihkv patenten wel. Niet voor jou persoonlijk als je zelf een kernel bouwt ... maar wel voor een leverancier van een apparaat (bv. TomTom) die de SD kaartjes wil kunnen lezen.

Dat zegt ZDnet, maar in de aankondiging van Microsoft staat dat niet zo expliciet.

Misschien kunnen ze het beter als fuse implementatie bouwen en het buiten de kernel laten.

De FUSE implementatie bestaat al en is best wel stabiel. Ik denk niet dat Microsoft daar veel aan kan toevoegen. exFAT is technisch geen rocket science, in tegenstelling tot bijvoorbeeld NTFS, btrfs, ZFS... Zoals je noemt zijn het de patenten en licentieovereenkomsten die het lastig maken.

Microsoft wilt dat de kernel zelf exFAT ondersteunt. Veel systemen hebben bijvoorbeeld boot partities die FAT32 zijn, zodat zowel de boot loader als de kernel tijdens het opstarten bestanden ervan kunnen lezen. Een voorbeeld betreft extra (encrypted) sleutelmateriaal om de root partitie te bereiken, dat men voor het gemak niet in een initramfs wilt proppen. Voor dat soort situaties zie ik weinig toegevoegde waarde voor exFAT, maar misschien heeft Microsoft dat wel.

[Reactie gewijzigd door The Zep Man op 29 augustus 2019 09:39]

Kan iemand mij trouwens uitleggen waarom sticks en dergelijke geen ntfs gebruiken? Of is dit net als exFat een semi patenten verhaal? Voor zover mijn kennis reikt (en dat is niet heel ver op dit gebied) is dat tot nu toe the best,, maarja zoals stated geen kennis (en op een zeilboot op zee met beperkt internet). Alvast thanks voor degene die mij een mooie uitleg kan geven ^^

Dank allen voor de verhelderende info ^^ deze nerd heeft weer wat geleerd en is er dankbaar voor.

[Reactie gewijzigd door Unsocial Pixel op 29 augustus 2019 17:42]

Een groot verschil tussen FAT en NTFS is dat bij NTFS veel meer meta-data zit die op een stick beslist niet relevant is.

Bijvoorbeeld rechten op een bestand voor bepaalde gebruikers. Daarbij staan dan account-nummers en hun rechten op het filesysteem. Steek je een stick met ntfs en rechten in een heel ander systeem, dan komen die rechten bij heel andere gebruikers terecht of zelfs helemaal niet.

Eigenlijk is het andersom: Het fat-filesysteem is ontworpen voor de Pc, de PERSONAL computer, met de nadruk op persoonlijk. In die dagen (CP/M, ms-dos, windows 3.x en zo) was er nog helemaal geen account informatie. Dus was er nog geen reden om dat in het filesysteem op te nemen. En toen was elke bit heilig dus wat niet hoefde werd niet opgeslagen. ntfs is pas gekomen met windows nt. Het is daar ook mee gegroeid en vergroeid.

Je begrijpt dat een foto toestel ook geen boodschap heeft aan account informatie, die wil gewoon de foto's opslaan en/of terug lezen. Daarom geen account informatie in het filesysteem zodat dat ook niet fout kan gaan.

NTFS is een journalizing system. Het heeft net als ext3/4 . Btfrs , zfs enz.

Fat 32/64, ext. 2 , reiserFs (1,2,3) hebben dat niet. ReiserFS 4 volgens mij wel.

Bij een journalizing system: Dat is zeg maar een dagboek die bij houd wat waar gebeurt. Stel bit er wordt een fout gemaakt dan kan een apperaat in dat dagboek kijken of het klopt en soms herstellen. Btfrs is als alles goed werkt het meest superieur van allemaal. Maar daardoor wel trager.

Bij camera's USB sticks enz. Die worden vaak veel ontkoppelt (ook onveilig) Zo'n dagboek maakt het trager en kleiner. Plus is dat vaak ook niet nodig.

Met gparted kon je al in exfat formatteren maar gaf soms wel problemen. Toch ga ik liever voor ext2 of 3 als ik kan kiezen.

Een journal filesystem is niet zoals een dagboek. Het is een filesystem waarin schrijfoperaties atomisch (ondeelbaar) zijn zoals in database engines. Dit betekent dat een schrijfactie pas wordt geaccepteerd als die netjes wordt afgesloten. Data wordt niet meteen overschreven maar het vervangende blok wordt apart geschreven, dan als het klaar is netjes gemarkeerd als het nieuwe geldige data blok en dan pas wordt het oude blok gemarkeerd als oud en daarmee vrijgegeven als beschikbaar data blok, en afhankelijk van het type en settings eerst gewist (overschreven met nullen, random bits of een of ander patroon). Nieuwe blokken worden op dezelfde manier gemaakt.
Het doel is dat een plotselinge crash of stroomstoring het filesystem nooit in een ongedefinieerde en dus corrupte staat achterlaat.
Het systeem is altijd in een van de atomische staten zoals:
afgesloten || nieuw blok begonnen maar nog niet klaar en gemarkeerd als het nieuwe geldige blok || oud blok vrijgegeven
Na een crash analyseerd het OS het filesystem en hoeft dan alleen dit Journal toe te passen.

Bij camera's USB sticks enz. Die worden vaak veel ontkoppelt (ook onveilig) Zo'n dagboek maakt het trager en kleiner. Plus is dat vaak ook niet nodig.

Vergeet ook niet het potentieel sneller slijten van flash geheugen. Daar zijn tegenwoordig wel slimmere technieken voor, maar vroeger was dat best wel belangrijk.

Met gparted kon je al in exfat formatteren maar gaf soms wel problemen. Toch ga ik liever voor ext2 of 3 als ik kan kiezen.

mkfs.exfat is een onderdeel van het exFAT FUSE pakket. Ik gebruik het al jaren, en het is stabiel. Doordat het file system zo simpel is, is de kans op bugs kleiner dan bij journaling file systems.

[Reactie gewijzigd door The Zep Man op 29 augustus 2019 11:08]

Ik werk zelf 99% van mijn tijd op Mac waar HFS+ (en tegenwoordig APFS) de standaard is. Als ik even iets over moet zetten met een USB stick dan pak ik hier vaak exFAT voor, gezien dit ‘cross-platform’ werkt.

Voor bijv. de Synology NAS moet ik een extra plugin kopen van €3,99 om exFAT aan te kunnen. Synology DSM is ook gebouwd op UNIX, dus als de licentie veranderd wordt en vrij beschikbaar zonder extra kosten, zie ik dit als een waardevolle toevoeging om makkelijk mediadragers aan te sluiten, ongeacht welk OS/platform er gebruikt wordt (mits exFAT ondersteuning erin zit natuurlijk)

Puur patenten verhaal.

exFAT en NTFS kun je prima lezen en schrijven vanuit Linux, alleen moet dat via "fuse" omdat het niet in de kernel mag vanwege patenten. Op je vette PC maakt het niet veel uit, maar met name embedded systemen hebben er behoorlijk baat bij als er geen userspace proces nodig is.

Ntfs word niet (veel minder) ondersteund in andere apparaten. Autoradio, videocamera, enzovoort. De kost om bv ntfs, ext3, hfs enzovoort te ondersteunen is duurder door patenten en extra ontwikkelings kosten.

Als een onwetende consument dan zoiets koopt en het werkt niet dan komen ze klagen dat die kapot is.
Dus het minste gezeik voor de firma's is het meest ondersteunde bestandssysteem erop te zetten.

Maar je kan die herformateren naar andere bestandssystemen zoals je wil he.
Ik doe dat geregeld voor bepaalde installaties van besturingssystemen.

Dus het komt eigenlijk altijd neer op kosten. Op de apparatuur kost het meer om te ondersteunen. Op de usb stick kost het meer aan ondersteuning en garantie aanvraag omdat het "niet werkt".

[...]
Microsoft wilt dat de kernel zelf exFAT ondersteunt. Veel systemen hebben bijvoorbeeld boot partities die FAT32 zijn, zodat zowel de boot loader als de kernel tijdens het opstarten bestanden ervan kunnen lezen.

Nu heb je net daar geen licenties voor nodig.

Het punt van de Microsoft FAT32 licentie is namelijk dat het een patent licentie is voor hun patent dat beschrijft hoe je lange filenamen kunt maken op een FAT partitie die eigenlijk 8.3 formaat ondersteunt. En dat is een erg specifiek patent - het gaat letterlijk over het **aanmaken** van die lange namen.

En dat is meteen waarom patenten moeilijke dingen zijn, zowel voor techneuten als juristen. Zelfs een groot bedrijf als Microsoft kan in zo'n patent kleine dingen over het hoofd zien - bijvoorbeeld dat hun patent maar één manier beschrijft om lange filenames te maken. En je kunt dus op andere manieren hetzelfde bereiken, en dan heb je ook een FAT32 filesysteem zonder Microsoft licenties. En één manier om dat te doen is door TomTom gepatenteerd en al in 2009 aan de OIN patentpoel toegevoegd, dus die is voor Open Source projecten gratis te gebruiken.

Hoezo als MS besluit het vrij te geven en hun patent niet actief beschermd is het patent vanzelf vervallen.

Daarnaast zijn er bergen patenten waarvan de eigenaar zegt dat je de kennis licentieloos mag gebruiken.

[Reactie gewijzigd door leonbong op 29 augustus 2019 09:30]

Om in de kernel te mogen, moet de software licentie GPLv2 compatible zijn.

Dat hoeft helemaal niet zo te zijn. Volvo heeft ooit een patent genomen op de 3-punts veiligheidsgordel. Vooral om het aan alles en iedereen duidelijk te maken dat het er is en hoe het gebruikt kan worden. Met daarbij expliciet de aanduiding dat iedereen het altijd en overal kan en mag gebruiken.
Daarnaast heeft volvo ook een patent genomen om te voorkomen dat anderen het patent zouden nemen.

Hoezo als MS besluit het vrij te geven en hun patent niet actief beschermd is het patent vanzelf vervallen.

Nee, dat is niet hoe patenten werken; patenten vervallen niet omdat ze niet verdedigd worden. Het is voor de houder van een patent prima mogelijk om er tien jaar lang niks mee te doen en vervolgens selectief mensen aan te klagen. Dit is iets wat patent trolls herhaaldelijk gedaan hebben.

Ik denk dat je in de war bent met trademarks (merkenrecht), wat wel onder het "use it or lose it" principe werkt.

"Niets doen" is net weer wat overdreven. Je moet wel de jaarlijkse kosten betalen om het patent te houden, in tegenstelling tot merken en auteursrecht zijn patenten niet gratis.

ExFat bestaat al jaren als fuse module.

Verder ben je wel heel erg selectief aan het quoten; er staat ook

en daarom de technische specificatie van het bestandssysteem vrij te geven

vrijgeven vat ik in deze als meer dan alleen "vertellen hoe het werkt" op

Kennelijk komt er iets van een licentiemodel waardoor bijv alleen makers van embedded devices moeten betalen maak de systemen die met deze devices conecten niet???

We zullen microsofts activiteiten moeten afwacgten

vrijgeven vat ik in deze als meer dan alleen "vertellen hoe het werkt" op

Hoe jij het opvat doet er voor de wet niet zo veel toe. Daar staat letterlijk alleen dat ze gaan vertellen hoe je het kunt bouwen, niet dat je jouw implementatie of die van MS licentieloos mag gebruiken.

We zullen microsofts activiteiten moeten afwacgten

Nee, zo werkt het dus niet met het bouwen van software. Niemand gaat tijd steken om iets te bouwen wat niet gebruikt kan worden. Ze zullen eerst duidelijkheid moeten scheppen over de status van licenties voordat de kernel ontwikkelaars ook maar gaan overwegen om de implementatie op te nemen in de standaard codebase.

To this end, we will be making Microsoft's technical specification for exFAT publicly available to facilitate the development of conformant, interoperable implementations. We also support the eventual inclusion of a Linux kernel with exFAT support in a future revision of the Open Invention Network's Linux System Definition, where, once accepted, the code will benefit from the defensive patent commitments of OIN's 3040+ members and licensees.

https://www.zdnet.com/art...or-linux-and-open-source/

Kom ajb niet met 'de wet' smijten als je daar verder weinig van snapt

Hoe ik het opvat 'komt omdat ik weet waarover ik praat' textueel begrip van het recht is in deze erg belangrijk.

Vrijgeven betekent in deze mogelijk 2 dingen maar zodra je in de context meeneemt dat MS patenthouder en dus licentiegever is zul je snel begrijpen dat het slechts vertellen hoe het werkt en willen helpen niet genoeg is als er geen gebruijsrecht aaan verbonden is

Daarom noemde ik één van de mogelijkheden
z1rconium noemde een andere

[Reactie gewijzigd door i-chat op 29 augustus 2019 10:02]

Microsoft gaat zijn exFat-bestandssysteem vrijgeven

Dat is toch al een mooie stap?

[...]
Misschien kunnen ze het beter als fuse implementatie bouwen en het buiten de kernel laten. Dan kan iedereen die er wel licenties voor wil betalen het nog los aan z’n systeem toevoegen.

Dat is hoe het nu werkt...

Waarom zou Linux ExFat willen? Als MS betere interoperabiliteit mbt USB-sticks e.d. willen kunnen ze toch net zo goed Ext2-support in Windows inbouwen?

Maar goed, ze kunnen beter gewoon de patenten aan de community doneren, dan komen de implementaties vanzelf als er voldoende vraag naar is.

Ext2 ondersteuning is leuk voor bestandsuitwisseling tussen Linux machines, maar het gros van de usb devices (en daarbij denk ik aan mediaspelers en dergelijke) ondersteunt eerder exfat dan ext2.

Dat komt omdat die apparaatjes allemaal FAT ondersteunen omdat de gebruiker dat kan lezen. Ofwel, omdat windows ext niet kan lezen. Ondertussen draaien ze intern gewoon embedded linux op een ext systeem.

[Reactie gewijzigd door jeroen3 op 29 augustus 2019 10:38]

Ext2 ondersteuning is leuk voor bestandsuitwisseling tussen Linux machines, maar het gros van de usb devices (en daarbij denk ik aan mediaspelers en dergelijke) ondersteunt eerder exfat dan ext2.

Ik heb het nooit gecontroleerd, maar ik ga er van uit dat de meeste van die devices ook ext2 spreken, ook al staat het niet op de verpakking. Vrijwel al dat soort spul draait tegenwoordig op Linux. Waarom zouden ze zo'n driver er uit gaan slopen? (Op de allerkleinste devices zou het ruimte kunnen besparen, maar alles bij elkaar is een Ext driver nog geen megabyte, dat is tegenwoordig geen probleem meer).

De 'nieuwere media spelers zijn op een linux kernel gebaseerd en kunnen dus van nature beter met ext* filesystemen overweg dan met fat* filesystemen.

Aangezien zo goed als geen enkel bestaand device (denk richting camera etc) ondersteuning heeft voor ext2/3/4 is je oplossing niet erg praktisch.

Camera's ondersteunen exFAT omdat de gebruikers graag met Windows hun fotootjes willen ophalen uit de camera of de SD kaart. Technisch gezien was ext4 veel makkelijker voor het apparaat, maar de "consument" wil iets anders.

Windows ondersteunt geen ext2/3/4 vanwege politiek en marketing. En waarschijnlijk ook omdat een filesystem driver schrijven voor Windows een rotklus is waar je echt niet blij van wordt.

Idem trouwens met macOS, het enige praktische crossplatform filesystem is ExFAT.

Technisch gezien was ext4 veel makkelijker voor het apparaat, maar de "consument" wil iets anders.

en vervolgens

En waarschijnlijk ook omdat een filesystem driver schrijven voor Windows een rotklus is waar je echt niet blij van wordt.

Welke van de twee is het, in mijn optiek kan onmogelijk beide waar zijn?

Daarnaast:
Het gegeven dat devices al enige tijd (ex)fat ondersteunen is dus een teken dat het belangrijk is die ondersteuning aan linux toe te voegen lijkt me? (en ja ik weet dat fat reeds te lezen is)

Ik snap het argument dus niet dat het andersom zou moeten en dat alles maar ext* moet ondersteunen. Moet iedereen met iets oudere hardware dan iets nieuws kopen zodat we met z'n allen geen exfat hoeven gebruiken?

Puur voor data storage is exfat overigens bijzonder geschikt, in het bijzonder vanwege de eenvoudige implementatie. Het is dan ook juist voor dergelijke portable devices ontwikkeld, waar ext* vele malen gecompliceerder is. Die devices draaien bovendien niet allemaal op linux.

Welke van de twee is het, in mijn optiek kan onmogelijk beide waar zijn?

De camera draait waarschijnlijk geen Windows. Vandaar. Op de camera ext4 gebruiken is simpel en gratis en vrij, waarschijnlijk alleen het vinkje in de kernel config aan laten staan.

Het gegeven dat devices al enige tijd (ex)fat ondersteunen is dus een teken dat het belangrijk is die ondersteuning aan linux toe te voegen lijkt me? (en ja ik weet dat fat reeds te lezen is)

FAT wordt niet beschermd door patenten en zit dus standaard in de Linux kernel en vele andere OSsen ingebouwd.

exFAT wordt door patenten beschermd en is dus niet compatible met de GPLv2 licentie bijvoorbeeld.

Je kunt vanuit Linux prima exFAT (en ook NTFS trouwens) lezen en schrijven, maar daarvoor moet de de kernel licentie schenden (te omzeilen via "fuse" wat o.a. Ubuntu doet) en het patent van MS (dat mag als je dat maar in prive sfeer doet).

Ik snap het argument dus niet dat het andersom zou moeten en dat alles maar ext* moet ondersteunen. Moet iedereen met iets oudere hardware dan iets nieuws kopen zodat we met z'n allen geen exfat hoeven gebruiken?

Het argument is puur technisch: ext2..4 is voor met name beperkte apparaten (zoals camera's en stokoude hardware) uitstekend geschikt, en ook nog eens open en gratis. In tegenstelling tot fat (dwz, FAT32, FAT16) mogen bestanden groter dan 4GB worden.
De keus voor exfat is technisch gezien geen beste. Het is wel het enige bestandssysteem dat Windows wil ondersteunen op removable media met support voor files groter dan 4GB. En als Windows het niet ondersteunt, dan bestaat het niet voor Jan Modaal, dus zitten we aan exfat vast.

Puur voor data storage is exfat overigens bijzonder geschikt, in het bijzonder vanwege de eenvoudige implementatie. Het is dan ook juist voor dergelijke portable devices ontwikkeld, waar ext* vele malen gecompliceerder is. Die devices draaien bovendien niet allemaal op linux.

exFAT bevat technisch gezien helemaal geen enkel nieuw idee, en is gewoon FAT met een paar tweaks en een paar slimme truukjes om er patent op te kunnen krijgen.

Ik weet niet waar jij het idee vandaan haalt dat ext* "gecompliceerd" zou zijn. Het presteert juist op devices met beperkte capaciteit (met name: weinig RAM) veel beter dan FAT.

Linux draaien is helemaal geen eis voor ext2/3/4 support, ik heb het vaak genoeg gebruikt op andere OSsen.

Thanks voor de onderbouwing/uitleg Weer wat geleerd.

Als je foto's uit de camera wil ophalen hoef je geen FAT systeem te gebruiken, het is voldoende om te doen alsof. (!)

En dat is een kritisch verschil. Het Microsoft FAT patent dekt alleen FAT als het fysiek gebruikt wordt. Een geëmuleerde FAT schijf (met ext2 backing) valt er niet onder. En FAT is dusdanig simpel dat je het prima kunt emuleren.

Nee, maar die gebruiken allemaal FAT, geen ExFAT.

Fat is een verzamelnaam van filesystemen:
fat-8: gebaseerd op een 8 bits opslag systeem. Of dit echt geïmplementeerd is weet ik niet.
fat-12: gebaseerd op een 12 bits opslag systeem. Terug te vinden op de meeste ms-dos floppies
fat-16: gebaseerd op een 16 bits opslag systeem. Terug te vinden op de eerste ms-dos harddisks en oudere/kleinere geheugendragers.
fat-32: gebaseerd op een 32 bits opslag systeem. Terug te vinden op de grotere/latere ms-dos harddisks en grotere geheugendragers.
exfat: uitbreidingen op voorgenoemde fat filesystemen om nog grotere structuren aan te kunnen.
Elke camera die een geheugen medium kan gebruiken van meer dan de grens van fat-16 (of was het fat-32)? kan met exfat overweg.

Update (na @MadEgg en @MSalters ):
ExFAT is inderdaad alleen in naam 'fat' en technisch iets heel anders. In gebruik is ze echter wel meer vergelijkbaar met fat dan met ntfs en/of ext2/3/4.
vFat is wel een uitbreiding: Dat geeft de mogelijkheid om 'lange' filenamen te gebruiken. Meer dan 8+3 karakters. fat32 is altijd vfat. fat12 en fat16 zijn in antieke computers nog wel eens zonder vfat geïmplementeerd.

[Reactie gewijzigd door beerse op 29 augustus 2019 23:14]

Ja. Waar FAT gezegd wordt wordt tegenwoordig overal FAT-32 bedoeld. ExFAT is bij mijn weten niet backwards compatible met FAT-32. Dat het erop voortborduurt is dan niet heel relevant.

Nope. ExFAT is alleen in naam een FAT systeem, maar valt buiten die familie. Wat wél in de FAT familie thuishoort is VFAT, wat de techniek is om lange namen (255) op een FAT disk te gebruiken. Dat kan al vanaf FAT-12; vanaf FAT-32 is het standaard.

Dat is onjuist. Een zeer groot aantal devices ondersteund ExFAT gezien de limitaties van het oude FAT bestandsysteem. Denk aan camera's, camcorders, mobiele telefoons, pc's , netwerkapparatuur, NAS devices, TV's, media centers en consoles. ExFAT ondersteuning is breed verspreid inmiddels.

De belangrijkste beperking van FAT is dat het geen bestanden van meer dan 4GB ondersteund. Voor camcorders wellicht een relevante beperking, maar verder amper. Camera's en telefoons werken zelden / nooit met bestanden van dergelijke omvang. Er zijn bijvoorbeeld ook weinig afdruk-kiosks die met ExFAT kunnen werken.

Je vergeet dat er op camera's en telefoons bijvoorbeeld ook gefilmd wordt wat, zeker bij hoge resoluties, grote bestanden kan veroorzaken. Denk ook aan het meenemen van films, het gebruik van een telefoon als opslag device, offline zetten van streaming media etc. Het zijn juist dit soort devices welke vaak ondersteuning voor ExFAT bieden, mede om deze redenen.

De beperking rond grote bestanden is in veel meer gevallen relevant, zie ook de andere genoemde devices (wat slechts een beperkte opsomming is). FAT is langzaam legacy aan het worden net als de genoemde afdruk-kiosks (welke in veel gevallen ook gewoon ExFAT kunnen lezen).

[Reactie gewijzigd door Bor op 29 augustus 2019 10:24]

Ook vervelend als je even een film op een stickje wil zetten.

Van meer dan 4GB? Houdt bij mij doorgaans wel op met 2GB. Je kunt je stickje natuurlijk ook gewoon als NTFS formatteren natuurlijk.

Het punt is juist dat NTFS veel minder breed ondersteund wordt op non Windows devices. ExFAT is juist bedoelt als minder zwaar en breder beschikbaar alternatief. Een film is doorgaans al heel snel groter dan 4GB. Kijk eens verder dan alleen jouw eigen situatie.

Nou ja, ik gebruik sporadisch Windows, voornamelijk Linux en af en toe wat Mac OS X. Toch nog nooit behoefte aan ExFAT gehad. Wel af en toe grotere bestanden, maar zowel Linux, Windows als Mac OS X kunnen prima met NTFS uit de voeten. Voor de rest voldoet FAT prima.

Maar goed, ik heb er niet direct bezwaar tegen hoor. Ik zou het alleen liever omgekeerd zien. Ext2/4 is mijn filesystem of choice. Ondersteuning daarvoor in Windows zou ik veel meer aan hebben dan ondersteuning van ExFAT in Linux (wat er via Fuse ook al is).

Windows probeert zelf te voorkomen dat je NTFS op removable media gebruikt. Technisch kun je NTFS ook op een floppy zetten, maar je moet er wel wat voor tweaken om Windows zover te krijgen.

Dat is weer tricky als je hem in macOS wil beschrijven.

Het lijkt mij onwaarschijnlijk dat fabrikanten zelf een OS opbouwen in deze markt. Er zal waarschijnlijk een linux variant in zitten.

Als MS betere interoperabiliteit mbt USB-sticks e.d. willen kunnen ze toch net zo goed Ext2-support in Windows inbouwen?

En waarom zou Microsoft dat willen, met hun pak-em-beet 90% marktaandeel?
Het zou voor Microsoft ook nog eens een extra testprocedure bij hun updates kunnen betekenen - en dat kost weer tijd en geld.

En de andere 10% marktaandeel is macOS dat ook geen ext2 support heeft.

Maar waarom stoppen bij ext2, als er ook gewoon ext4 bestaat? Na het herformatteren van een SD kaart met ext4 (vanaf een soort hybride van ext3 en ext4) werkt op mijn ARM SBC alles veel sneller. Ext2 heb ik voor het laatst gebruikt in het jaar 2000.

Omdat ext2 veel eenvoudiger is en minder overhead heeft. Uitstekend geschikt voor verwisselbare media.

Het staat er niet heel duidelijk, maar Open Invention Network gaat feitelijk om gedoneerde patenten. Wat ik ervan lees is het de bedoeling dat de bestaande exFat-implementatie van Samsung in de Linuxkernel wordt opgenomen en neemt deze stap van Microsoft de obstakels daarvoor weg.

Naast Windows en Linux zijn er echter een heleboel apparaten die usb sticks kunnen lezen, en de meeste daarvan kunnen alleen overweg met fat32. Als je de stick alleen onder Linux wilt gebruiken houdt niets je tegen om er gewoon ext4 op te zetten, maar de meeste sticks zullen in de praktijk tot in lengte van dagen op fat32 blijven draaien.

Natuurlijk zou ik dan ook niet weten waarom je er exfat op zou willen zetten want volgens mij is de device support dan net zo belabberd als met ext4. Ik denk dus niet dat het om usb sticks zal gaan hier.

Waarom zou Linux ExFat willen?

Draait het eens om: waarom zou je het niet willen? Een bredere ondersteuning voor filesystemen lijkt mij eerder gunstig dan een nadeel.

Als MS betere interoperabiliteit mbt USB-sticks e.d. willen kunnen ze toch net zo goed Ext2-support in Windows inbouwen?

Er is veel apparatuur wat niet overweg kan met Ext2 wat een uitdaging is. Daarnaast wordt ExFat niet alleen gebruikt op removable devices.

Goed nieuws. Eindelijk een bestandssysteem wat eenvoudig te gebruiken is onder de grote drie, Windows, MacOS en Linux zonder dat je zelf nog iets moet installeren. In MacOS zat het al vanaf versie 10.6.5 en binnenkort dan ook in Linux.

Die waren er al: FAT32 en nog beter, UDF.

FAT is inderdaad simpel. Afgelopen week nog een 1.4MB image van een 180KB FAT12 MSX disk hersteld door handmatig de sectoren van alle bestanden achter elkaar te zetten. Inderdaad geen rocket science. Was de eerste keer dat ik het onderzocht.

Voor USB sticks en dergelijken is UDF geen echt goed alternatief. Probleem zit in de manier hoe sticks omgaan met garbage collection, blck assignments en de eerste paar sectoren van de disk.

Die eerste paar sectoren hebben vaak een speciale behandeling aangezien daar de indexes worden geplaatst door FAT. Een stick laat die sectoren vaak door meerdere threads tegelijkertijd benaderen en beschrijven, terwijl de andere sectoren vaak maar door 1 thread tegelijk benaderd mag worden.
UDF heeft zijn indexes niet alleen in die eerste paar sectoren staan waardoor het inefficiënt wordt gebruikt en er ook fouten kunnen voorkomen doordat het block waar je een index wil updaten door de garbage collector is vastgezet. Resultaat : foutmelding.

Je ziet dit bijvoorbeeld ook terug als je sommige telefoons mount in je computer. Dan mag je maar 1 ding tegelijkertijd doen. En blijft de finder of Explorer blanco bij het browsen als je al aan het kopiëren bent bijvoorbeeld.

Je ziet dit bijvoorbeeld ook terug als je sommige telefoons mount in je computer. Dan mag je maar 1 ding tegelijkertijd doen. En blijft de finder of Explorer blanco bij het browsen als je al aan het kopiëren bent bijvoorbeeld.

Is dat geen beperking van MTP, niet zozeer het bestandsformaat?

For devices that expose their storage that way it most definitely is.

Die eerste paar sectoren hebben vaak een speciale behandeling aangezien daar de indexes worden geplaatst door FAT. Een stick laat die sectoren vaak door meerdere threads tegelijkertijd benaderen en beschrijven, terwijl de andere sectoren vaak maar door 1 thread tegelijk benaderd mag worden.

De vraag is hoe ver je terug gaat in de tijd voor de eerste bewering. Voor floppy disk ja, maar nu zijn USBsticks b.v. 2GB of 8GB. Er is een grootte grens van wanneer een storage device als floppy danwel HDD wordt beschouwd, maar ook als je een MBR op een klein storage device zet, ziet i.i.g. Linux dat als een HDD. Door moderne LBA methodes is de eerste sector de MBR, dan 2047 niks en dan pas de eerste partitie. Dus daar zouden zich dan de 2 FATs bevinden.
Dat is in ieder geval mijn huidige praktijk en ervaring. Ik weet niet of je voor SDcards van 8GB dezelfde aannames mag doen als voor USBsticks, ik doe het in ieder geval wel. Ik gebruik veel BTRFS op SDcards van ongeveer genoemde grootte. 10 jaar geleden ook Ext4 als rootfs in een netbook. Kan zijn dat het toen 62 sectoren aan het begin waren die ongebruikt waren.

https://lwn.net/Articles/428584/

Is een leuk stuk. Het zal best zo zijn dat diverse media niet meer deze methodes gebruiken, maar ik heb ook diverse moderne media die nog wel op deze manier reageert.

Ik had dat artikel een jaar of wat geleden al eens doorgespit toen dit ter sprake kwam in de btrfs kernel mailinglist. Zoals Arnd Bergmann zelf ook al aangeeft, je weet het niet wat er in een flash-storage device (SDcard of USBstick) zit aan controllers en methodes. SSD's kun je nog openschroeven en dan b.v. vaststellen dat er b.v. een Sandforce chip inzit die alle blokken comprimeert om maar eens wat te noemen. Is ook achterhaalde methode, maar dat terzijde.
Verder is het artikel helaas 8 jaar oud. Wat erin beschreven is zou als een toolkit beschikbaar moeten zijn, zodat je je (goedkope) flash-storage device kan 'ranken'. Die is er niet naar mijn weten, dus blijft het in mijn ogen prijs+ervaring enz wat een graadmeter is hoe goed een flashdevice presteert en/of hoe lang ie het uithoud. Mijn taktiek is een filesysteem gebruiken wat op zich goed is tegen wearing en silent blockcorruptie. Mocht ik een SDcard hebben/treffen die daardoor slecht presteert, dan komt ie laag op de ranking te staan: niet weer kopen. Ik heb bij mijn weten maar 1 keer iets met min of meer hardcoded FAT gehad en 2 keer een USB houdertje voor SDcard 'opgerookt' (tijdens beschrijven in een PC om later in smartphone te stoppen aan oververhitting totaal kapot gegaan). Ook wel een paar keer een falende scrub gezien, maar dit is vele malen gunstiger dan er op gegeven moment achter komen dat 1 corrupt block ergens in een file je maanden heeft beziggehouden.

FAT32's limieten vormen tegenwoordig een probleem. Vooral max. bestandsgrootte van 4GB is te weinig voor bepaalde doeleinden, en max. filesystem grootte van 2TB is ook aardig krap tegenwoordig. Dat er dus een breed ondersteunde moderne vervanger moet komen is duidelijk.

ExFAT support zit al in Android (en ChromeOS), overigens en dat is toch het grootste OS, dus de grote drie hebben het al.

Niet helemaal. Zo hebben Android One en Nokia telefoons geen ondersteuning voor exfat omdat dit niet in stockandroid zit. Als fabrikant moet je zelf exfat toevoegen en dus ook patenten hiervoor betalen.

Met het vrijgeven van de patenten, wordt dit probleem opgelost en zal exfat ook in de kernel van Linux op Android komen.

Aan de andere kant heeft het ook wel veel gebreken. Geen journalling, geen snapshots, geen online defragmentatie, geen block checksums, allemaal mooie dingen die een modern filesystem robuust maken zodat je niet meteen een filesystem crash hebt als je je computer een keer hard uitzet.

Puur voor statische opslag / meenemen op usb stickjes is het wel leuk omdat het makkelijk te implementeren is. Maar een serieus filesystem is het natuurlijk niet in deze tijden. Ik zou het bijvoorbeeld niet eens voor een externe HDD gebruiken waar ik de bestanden op heb waar ik mee aan het werk ben.

Het zou op zich heel fijn zijn als er echt een cross-platform robuust filesystem kwam zodat je wel overal mee kan werken.

Of ze geven je de keuze om de kaart te formatteren met verschillende bestandssystemen. Voor mij zijn ext4, F2FS en ZFS nuttiger dan welke vorm van FAT of NTFS dan ook, dus dan zou het ook veel handiger zijn om zelf te kunnen bepalen hoe de opslag geformatteerd wordt.

exFAT is allang gemakkelijk te gebruiken onder veel Linux distributies. Het betreft de FUSE implementatie. Voor veel gebruikers is het plug & play.

Er is toch al een gratis exFat kernel module voor Linux? Zit alleen niet standaard in de kernel. Het zit trouwens ook gewoon in MacOS.

[Reactie gewijzigd door terracide op 29 augustus 2019 09:29]

Wat nu in Linux zit zal een reverse engineered geval zijn.
In MacOS zit meen ik een offiële versie op basis van een licentie.

Apple en Microsoft delen bijzonder veel patenten met elkaar, wellicht is exfat daar onderdeel van.

Oh, dat zou ook goed kunnen. Geen idee, maar klinkt aannemelijk.

ExFat support is beschikbaar vanaf Mac OS X versie 10.6.6 en hoger.

Het is niet reverse engineered, het is alleen niet patentvrij. Android en ChromeOS zijn ook Linux distributies, met die kernel module meegebakken - maar Google betaalt de licensie. Nu wordt het ook beschikbaar voor Linux distributies die geen licensie willen betalen.

hmm, dan zal dat wel in de begin tijd zijn geweest.
Lang, lang geleden.

Het zit dus niet standaard in de kernel vanwege de licentie en dergelijke. Het is de bedoeling van microsoft dat ze wel in de kernel komt. Daarom geeft ze het nu wel vrij.

Hopelijk komt exFAT dan ook snel naar *BSD.

De gewone fat's zijn wel handig omdat ze tegen hard shutdown kunnen maar geen idee wat we hieraan zouden kunnen hebben.

Zodat je je geheugen kaart uit je telefoon of camera kan mounten.

Er zit 4G, Wifi en Bluetooth op. Waarom moet je hem eruit halen?

Omdat sommige mensen dat nou eenmaal willen.
Het gaat er niet om wat jij vindt.

Op QNAP kan ik een licentie kopen voor exFat $3,99. Geen onoverkomelijk bedrag. Maar toch; als exFat ondersteuning straks by default mogelijk is, maakt het dit toegankelijker voor een grotere groep gebruikers. En dat is goed nieuws.

Ben benieuwd of Synology het exFAT addon package dan niet meer nodig is. Nu moet je nog betalen hiervoor.
https://www.synology.com/...ices_with_my_Synology_NAS

Terwijl Synology zonder problemen een NTFS disk kan gebruiken.

Vind het alleen maar positief dat ze dit doen. Je kan zeggen, ja we hebben het nu al. Dat is een fuse implementatie. Officiele ondersteuning is beter.

En het is goed dat dit soort dingen gedeeld worden met de opensource community.

Dus ja, het is mischien maar een klein ding, maar ik zie geen negatieven hier

Hoezo "we hebben het nu al" ?
Hoe kunnen ze het dan nog beschikbaar maken?

Er is een fuse oplossing. Deze is echter niet officieel.

Via een officiele release is altijd beter, dan kan het direct de kernel in ipv via een fuse oplossing.

sudo apt-get install exfat-fuse exfat-utils

Dit command zou je read en write support moeten geven op linux

De exFat-variant bestaat sinds 2006. Microsoft heeft de patenten in handen en bedrijven moeten daarom licentieovereenkomsten afsluiten om er gebruik van te maken.

Loopt dat patent niet binnenkort af? Dan is het voor Microsoft inderdaad een goed moment om de licenties vrij te geven, zonder al te veel licentiekosten mis te lopen.

Welk patent? Als exFAT pas sinds 2006 bestaat, denk ik van niet. Misschien patenten die op FAT van toepassing zijn wel.