MacOS krijgt nieuw bestandssysteem met High Sierra

Apple heeft macOS 10.13 High Sierra gepresenteerd. De fabrikant heeft onder meer browser Safari gewijzigd. Daarnaast werkte het bedrijf naar eigen zeggen vooral aan het beter maken aan de release van Sierra vorig jaar.

High Sierra zal draaien op apfs, Apple File System, in plaats van het dertig jaar oude hfs. Het nieuwe bestandssysteem is gebouwd op 64bits-processors en maakt volgens het bedrijf veel acties in macOS sneller op dezelfde hardware.

Apple zet h265-ondersteuning in macOS High Sierra. Dat gebeurt bij oudere Macs via software en de nieuwste varianten krijgen door hardware versnelde ondersteuning voor hevc, onder meer voor 4k-hdr-videomateriaal.

Met High Sierra kondigde Apple ook Metal 2 aan, de tweede versie van zijn grafische api Metal. Die krijgt ondersteuning voor externe grafische kaarten. Ook komt er een vr-versie van Metal 2, waarbij Final Cut Pro video in 360 graden kan gaan bewerken. Bovendien werken de engines van Unreal en Unity met Metal 2. Er komt ook een developer kit met een thunderbolt-kaart en een AMD RX580.

Safari gebruikt volgens Apple machine learning om tracking op internet tegen te gaan. Het bedrijf ging niet in op details hoe het werkt, maar benadrukte dat het niet ging om adblocking, maar om tracking tegen te gaan. De browser heeft in de nieuwe macOS-versie autoplay-blocking, waardoor video's niet meer automatisch kunnen afspelen op een tabblad.

Mail krijgt een splitscreen-view om tegelijk mail te kunnen lezen en een nieuwe mail op te stellen. De Foto's app kan namen van mensen op foto's synchroniseren tussen apparaten. Ook komen er nieuwe bewerkingstools in het fotoprogramma en kunnen gebruikers alle imports in een overzicht zien. Er komen daarnaast fotoboekdiensten van derden in de fotoapp.

High Sierra komt maandag uit als testversie voor ontwikkelaars, terwijl de definitieve versie dit najaar zal uitkomen.

Reacties (116)

[wimkamerman]

Wat ik nou jammer vind: de mail app is nog steeds niet écht verbeterd. Functies die ik mis:

• Autodiscover zoals bij Outlook
• Fatsoenlijke styling van berichten zodat ook in niet-apple clients de tekst er goed uitziet en zonder winmail.dat bestand of andere rommel (check http://universalmailer.github.io/UniversalMailer/)
• Het (makkelijk!) toevoegen van html handtekeningen incl afbeeldingen
• En dan ook gelijk het synchroniseren van die handtekeningen via iCloud (net zoals de accountgegevens)
• Integratie met reminders
• Bug: multimonitor, bij het minimaliseren van een nieuwe e-mail in fullscreen modus komt dat scherm over het andere scherm heen

Zo is er nog van alles op te noemen. Het kan ook simpel en dan wél goed. Verder een fijn programma hoor, maar dit zijn wel punten die mij irriteren. Het is niet moeilijk om op te lossen, maar Apple's prioriteit ligt duidelijk niet bij het echt verbeteren van de mail app. En ja, je kunt plugins gebruiken maar dat werkt vaak toch minder prettig.

Ik ben benieuwd: herkennen mensen zich in mijn punten?

[MetalG]

Autodiscover werkt toch gewoon?

[wimkamerman]

Nee, helaas. Wel met Exchange maar niet met 'normale' IMAP en POP servers. Ik heb succesvol op mijn VPS autodiscover ingesteld. Werkt vlekkeloos in Outlook maar tot mijn verbazing niet in Apple mail. Er is ook geen alternatieve manier voor Apple mail beschikbaar.

[MetalG]

Aaah ja, dat zou kunnen

[MediQ]

Wat ik nog nergens genoemd zie, zijn de system requirements. Volgens Ars Technica draait High Sierra op alle Macs die ook Sierra ondersteunen:

MacBook (late 2009 and later)
iMac (late 2009 and later)
MacBook Air (2010 and later)
MacBook Pro (2010 and later)
Mac Mini (2010 and later)
Mac Pro (2010 and later)

[Keypunchie]

Vooral spannend hoe/of de conversie van HFS+ naar APFS zal gaan. Op de iPhone was dat makkelijk, want daar had je bij de upgrade een verplichte backup, die je terugzet naar het nieuwe FS. Maar hoe doe je dat "in-place? En werkt het straks goed samen met Time machine/FileVault?

[Xerxes249]

WWDC 2016 had een leuke wwdc video hierover.

Basically:
1. Eerst ga je in de datalaag van HFS+ de APFS headers schrijven
2. Swap data + header lagen
3. Nou zit de HFS+ header in een APFS data laag en alles werkt.

Denk dat het deze was: https://developer.apple.com/videos/play/wwdc2016/701/

[gerwinpl]

antwoord:

https://developer.apple.c...l/APFS_Guide/FAQ/FAQ.html

[CyBeR]

Die upgrade van HFS naar APFS was in-place. Er werd dus geen backup gemaakt en gerestored.

Dat is wel een keer eerder gebeurd toen Apple de partities wijzigde in het HFS-tijdperk, maar dat betrof een veel eerdere update (iOS 5 of iets dergelijks.)

[Maurits van Baerle]

De conversie zal het probleem niet zijn, zo ingewikkeld is dat niet.

Ik vind het eerder opmerkelijk hoe snel ze dit doen. Het FS is pas een paar jaar oud en wordt nu al ingezet voor productie (en is op iOS al maanden geleden in productie genomen). Dat is erg snel voor een filesystem waar er doorgaans erg veel op het spel staat. De overstap bij iOS is kennelijk goed bevallen en nu kan het lastigere (wegens veel meer hardware en configuratiemogelijkheden) macOS kennelijk ook over.

[Guru Evi]

Apple heeft al enkele jaren aan een nieuw bestandssysteem gewerkt. Initieel gingen ze ZFS gebruiken maar vanwege licentietoestanden met Oracle/Sun is dat dan niet verder gegaan (alhoewel ZFS en de tools wel in 1 versie van OS X zat).

Er was toen al sprake dat ze een eigen bestandssysteem die HFS+ in-place kon vervangen aan het maken waren, dit is waarschijnlijk wel 10 jaar geleden. APFS zit ook al enkele versies in iOS zonder al te veel problemen.

[Xerxes249]

APFS zit pas in iOS sinds 10.3 dus dat valt wel mee ^^

[xoniq]

Plus de patch versies erna en de betas.

[BeosBeing]

Apple heeft al enkele jaren aan een nieuw bestandssysteem gewerkt....
Er was toen al sprake dat ze een eigen bestandssysteem die HFS+ in-place kon vervangen aan het maken waren, dit is waarschijnlijk wel 10 jaar geleden.

Als ze er al zo lang mee bezig zijn, dan zal het wel goed zijn. Toen het net uit kwam gaf ik aan dat ik dat erg vroeg vond (percies zoals @Maurits van Baerle hierboven al aangeeft).

Wel typisch dat ze nu zijn overgestapt op een 64-bits bestandssysteem terwijl BeOS dat in 1999 al had (om van Windows maar helemaal te zwijgen).

[Verwijderd]

"De conversie zal het probleem niet zijn, zo ingewikkeld is dat niet."

Nou. ik kan me toch moeilijk een voorstelling maken hoe je een filesystem converteert zonder dat je iets van buffer storage hebt.
lijkt me stug dat ze gedurende de conversie twee filesystems door elkaar laten bestaan.
Zouden ze vrije ruimte opsnoepen van de bestaande slice en dit stukje bij beetje toevoegen aan een nieuwe slice en daar dan zodra er genoeg ruimte is bestanden naartoe gaan moven en dan die ruimte weer overzetten?
Lijkt met wel een riskant proces.

Ik ben wel benieuwd hoe ze de conversie doen.

[H!GHGuY]

Arstechnica had er een artikel over. Ze maken in de vrije ruimte de nieuwe metadata structuur. Eens ze daarmee klaar zijn kan de knop om en is de oude metadata gewoon empty space.

[Maurits van Baerle]

Klopt. En omdat het bij een SSD niet meer uitmaakt of de index aan het begin van de fysieke schijf staat is het dan ook geen probleem dat hij waarschijnlijk ergens "in het midden" terecht komt, voor zover je van een midden kunt spreken bij een SSD.

[Blokker_1999]

Als MS van FAT naar NTFS kan gaan lijkt het mij dat Apple ook wel een oplossing zal hebben om van HFS naar APFS te gaan.

[debroervanhenk]

Beetje off-topic, maar wanneer krijgt Windows eens iets nieuws? Dat aftandse ntfs kan toch echt niet meer.

[Blokker_1999]

NTFS vandaag is niet meer de NTFS vanuit het OS/2 tijdperk. Er zijn verschillende versies van en is wel degelijk met zijn tijd meegegaan. Er zijn door de jaren heen verschillende pogingen gedaan om het te vervangen, maar geen 1 is tot in productie geraakt. ReFS is vandaag wel in productie, maar kan niet voor je bootschijf gebruikt worden en er ontbreken nog altijd tools voor.

[Shark.Bait]

Ze wilden ooit WinFS introduceren voor Longhorn.

nieuws: Microsoft geeft videopresentatie over WinFS

in 2003....

[Umbrah]

Veel van de features die hier in zaten zijn ge-backport naar NTFS. Wat wel degelijk nieuwe major/minor updates heeft gehad. Er zijn zelfs een lading instellingen die een popup geven: "waarschuwing, werkt hierdoor niet meer op oude Windows mogelijk!"

[Shark.Bait]

Klopt, maar het blijft NTFS.

[thomas1907]

Wat is er dan mis met ntfs? Ik als best advanced gebruiker heb er geen problemen mee.

[Yggdrasil]

Er is niet veel *mis* met NTFS, maar het ontbreekt aan features die in in modernere filesystems wel aanwezig zijn, zoals:
- lichtgewicht kopieën (via copy-on-write)
- snapshots (via copy-on-write)
- logical volumes (is later alsnog toegevoegd)
- data integriteit (checksumming)
- crash consistency (geen fs check meer nodig want fs detecteert zelf fouten)
- deduplicatie (compressie op block niveau, niet file niveau).

In ReFS zijn een aantal van deze features wel beschikbaar. APFS ondersteund ook sommige van deze features. De meesten kunnen wel nog toegevoegd worden.

[bogy]

ntfs zit aan versie 3.0 geloof ik momenteel...
waarom zou het vervangen moeten worden? het werkt toch goed en snel, is secure......

[firest0rm]

Ik denk dat je GPT vergeet. Die is sinds de komst van Windows 8 de standaard voor windows

[Reactie gewijzigd door firest0rm op 30 juli 2024 01:20]

[Steef435]

GPT is geen bestandssysteem maar een partitietabelstandaard dus dat heeft hier weinig mee te maken.

[faim]

Al die miljoenen servers die op NTFS draaien? Dat wordt een zooitje, zelfs al zou Microsoft iets nieuws uitbrengen, dan wilt de zakelijke markt daar de komende 10 jaar toch niet aan.

[Yggdrasil]

Mwah, ik kom ReFS toch al regelmatig tegen in het bedrijfsleven, terwijl het pas sinds Server 2016 beschikbaar is, o.a. op backupservers vanwege de ingebouwde deduplicatie.

[Dutch2007]

Her nieuwe heet ReFS, is alleen nog niet vanaf te booten, wordt voor storage spaces gebruikt.

[batjes]

NTFS is 'nieuw'.

De ontwikkeling hiervan is niet gestopt. Het bestandssysteem wordt zo'n beetje elke Windows release verder uitgebreid en geupdate.

[mikesmit]

Die overgang was niet zonder formatteren, maar ze zullen ongetwijfeld een oplossing bedacht hebben voor dat probleem

[SKiLLa]

Niet helemaal waar, Win2K en WinXP hadden convert.exe om 'automagisch' van FAT naar NTFS te converteren met behoud van data ...

[mikesmit]

Dat was toch niet voor de primaire schijf?

[Xiphalon]

NT 4.0 deed zelfs eerst installeren op FAT en daarna de conversie naar NTFS

[mikesmit]

Een tijdje geleden hoorde je ze over reFS (jaar of 10) maar Volgensmij is dT alleen te vinden op servers

[Verwijderd]

Komt binnenkort mogelijk in Windows 10 Workstation.

[Dutch2007]

ReFS kan je al via storage spaces in win10(pro) gebruiken 😉

[Damic]

Je kon het starten in windows maar je moest herstarten zodoende dat de schijf niet meer in gebruik was en dan doet ie vrolijk verder, hetzelfde systeem dat fdisk gebruikt.

[Maurits van Baerle]

Klopt, alleen had je dan wel het probleem dat 'Everyone' alle rechten had op alle bestanden (omdat FAT natuurlijk geen rechten kent) en als ik me goed herinner kon de conversietool de blockgrootte niet wijzigen. Zo kon je aan een partitie later nog zien of hij native NTFS was of begonnen als FAT en later geconverteerd.

[Jaccoh]

Dat zal vrijwel naadloos gaan vermoed ik. De reden dat ik dat vermoed: iOS 10.3 heeft als APFS. Heeft niemand wat van gemerkt tijdens de upgrade.

[Jasper Janssen]

Op de iPhone werd ook gewoon een in place upgrade gedaan.

[Caelestis]

Met een dongle.

[mrtl]

Leuk dat Metal 2, maar wanneer komt ondersteuning voor OpenGL 4.5 en Vulkan? Toch bizar dat ze zo extreem hun eigen API pushen dat de concurrentie niet eens mogelijk is om te gebruiken op Mac OS.

[MacWolf]

Lijkt me sterk dat Apple überhaupt nog werk gaat steken in OpenGL. Het was al jaren een ondergeschoven kindje voor Metal op de markt kwam en liep flink wat versies achter. Ik denk dat Apple hier geen moeite meer in zal steken. Maar wie weet pakt de Khronos groep het op? Microsoft schrijft toch ook geen OpenGL implementatie voor Windows of wel? En wellicht voor Vulkan idem.

Ik vermoed trouwens dat de meeste game porting bedrijven al hun eigen middleware hebben geschreven die DirectX API's naar Metal e.d. vertalen, om het porteren van spellen eenvoudiger te maken.

En wat te denken van MoltenVK?

[Reactie gewijzigd door MacWolf op 30 juli 2024 01:20]

[Overv]

De Khronos groep werkt alleen aan de standaard achter OpenGL en Vulkan, niet de implementaties van die API's. Op Windows en Linux worden die implementaties o.a. door NVIDIA en AMD geleverd.

Het verschil bij OS X is dat Apple zelf de drivers voor de videokaarten beheerd in plaats van dat aan NVIDIA en AMD over te laten. Daardoor heeft Apple de macht om API's zoals OpenGL en Vulkan minimaal of zelfs helemaal niet te ondersteunen. Dit is vergelijkbaar met het verbieden van andere browser engines dan Safari op iOS.

[Reactie gewijzigd door Overv op 30 juli 2024 01:20]

[BeosBeing]

Daardoor heeft Apple de macht om API's zoals OpenGL en Vulkan minimaal of zelfs helemaal niet te ondersteunen. Dit is vergelijkbaar met het verbieden van andere browser engines dan Safari op iOS.

En daar gaat de cross-compatibiliteit

[jqv]

Niets nieuws onder de zon. Dit doen ze al heel lang en is de afgelopen tien jaar enorm succesvol gebleken.
Door hun eigen API te gebruiken, houden ze ook controle erover.

[Verwijderd]

En garanderen ze een zeer goede gebruikers experience. En dat is iets dat veel mensen moed willend vergeten of expres weg laten om zelf slimmer te klinken.

Als Metal inderdaad zoveel sneller en beter is als OpenGL en Vulkan, waarom zouden ze dan in godsnaam OpenGL of Metal moeten ondersteunen?

Je ziet dat met Chrome en Safari ook. Safari == 10 uur browsen op je Macbook Pro. Chrome == max 5 uur als je geluk hebt en FireFox == 4 uur.. Dit betekend dus dat je op iOS hetzelfde kan verwachten als Apple andere API's of browserengines gaan toestaan.

En dat is met Metal gewoon hetzelfde. Apple kan met Metal een zeer goede userexperience aanbieden. Waarom denk je dat Microsoft DirectX zo heeft gepushed de afgelopen jaren?

Want hoe je het ook went of keert. Of Vulkan nou goed of slecht zou werken op MacOS Apple word toch wel vuil aangekeken.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 01:20]

[Hugo_ijslijk]

Waarom ze het zouden ondersteunen? Omdat het een open standaard is die ook vrij goed performed. Alle andere platforms ondersteunen het, dus als Apple het zou ondersteunen zou het meer games naar macOS brengen

[Dutch2007]

Niet op de iphone, daar is en blijft de render engine die van apple, zit dan alleen een chrome of firefox schilletje om heen.

[Verwijderd]

Dat zeg ik toch ook.

Je ziet dat met Chrome en Safari ook. Safari == 10 uur browsen op je Macbook Pro. Chrome == max 5 uur als je geluk hebt en FireFox == 4 uur.. Dit betekend dus dat je op iOS hetzelfde kan verwachten als Apple andere API's of browserengines gaan toestaan.

[Blokker_1999]

En door de eigen API te gebruiken bemoeilijk je net multi platform development. Als een studio vandaag een spel ontwikkeld en ze willen dit porten naar macOS moeten ze al een hoop werk verzetten om het draaiende te krijgen, maar moeten ze bij Apple ook nog eens een andere API gaan ondersteunen die geen enkel ander platform heeft. Met het beperkt aantal gamers op macOS wordt het dan ineens een dure bedoening die het vaak niet eens waard is.

[Xieoxer]

Ik kan maar 1 redenen bedenken en dat is dat Metal 2 veel beter presteert dan OpenGL 4.5 en Vulkan. Ze willen geen tijd en geld verspillen aan software dat niet het zelfde presteert als Metal 2.
Stel ze zouden het wel ondersteunen en ontwikkelaars kiezen voor de slechte varianten, wat krijg je dan? Slechte user experience. De gebruiker verteld vervolgens weer door hoe slecht een MacBook presteert. Mensen horen dit aan en denken wel 3x na voordat ze een MacBook gaan kopen. Gebruikers denken niet zoals ons. Wij weten dat slecht werkende software door de software ontwikkelaar komt en niet door Apple. Gebruikers snappen dat verschil niet. Apple probeer zoals altijd de beste user experience over te brengen aan de eind gebruiker.

[kozue]

Maar dit hoeft niet zo te zijn. Als je bv kijkt naar hoeveel slechte ports er tussen pc en console onderling worden gemaakt: een game wordt geoptimaliseerd voor een platform en andere vreemde API's worden daar aan toegevoegd voor een beetje extra OS-ondersteuning en daarmee verkopen, maar krijgen niet de aandacht die het hoofdplatform verdient.

Ik denk dat OS X voor geen enkele game het hoofdplatform is (meestal de console of Windows), dus de Metal driver zal altijd het ondergeschoven kindje blijven, terwijl OpenGL of Vulkan wellicht betere ondersteuning krijgt. Door SteamOS is ondersteuning voor Linux tegenwoordig wellicht belangrijker dan die paar gamers op OS X. En daarmee krijg je dus juist wel verhalen als "Game X draait slecht op een Macbook", juist omdat Apple z'n eigen API pusht.

[BartOtten]

Leuke theorie, maar ik usability land is ondertussen ook al wel boven komen drijven dat Apple niet (alleen) gaat voor goede usability. Form over function is schering en inslag. Disk sleeves met scherpe randen en een 'onzichtbaar' inputveld om een telefoonnummer te plakken zijn slechts kleine voorbeelden.

Het verhaal blijft mooi, maar de realiteit toont anders aan.

Ps. Usability is in hoge mate verbonden aan UX. Ik haal ze niet per ongeluk door elkaar

[Reactie gewijzigd door BartOtten op 30 juli 2024 01:20]

[Verwijderd]

Zouden ze nu dan eindelijk echt case sensitive zijn?

[ZpAz]

Als je in OSX momenteel je HD formatteert kan je met het huidige filesystem kiezen tussen case ssensitive en insensitive.

[xleeuwx]

Klopt echter dan kan je geen steam meer gebruiken, voor de rest werkt het prima.

[siraic]

Toen ik het 2 jaar geleden probeerde werkte ook de Adobe suite niet meer.

[DJFliX]

Oei! Dat is dan wel een lichte nalatigheid van Steam (lijkt me?). Maar een Disk Image miunten met daarin een case insensitive filesystem en dan daar je Steam/Library in zetten zou dan ws wel werken? Wel interessant, dit heb ik nog niet eerder gehoord

[freakin_ruben]

Klopt, via een image werkt t wel. Zo heb ik Adobe en Steam ook lang gebruikt

[Blokker_1999]

Er is zoveel software dat er niet mee overweg kan dat je gek bent als je dat doet met HFS. Dat het kan klopt, maar daarmee is ook alles gezegd.

[Verwijderd]

Hopelijk niet (of althans niet verplicht)

[Blokker_1999]

Waarom niet? Onderbouw dat eens? En zelfs al zou het aanstaan en je wil er zelf geen gebruik van maken, hoe zit het dan in de weg?

[MacWolf]

Ik ben het helemaal eens met het artikel "On Unix File System's Case Sensitivity":

... Case-sensitivity seems like a great idea to UNIX-heads. These are people who want every possible command and workflow to have a distinct, deterministic result — the kind of thinking you expect from an academic/research environment. Synonymous workflows that arrive at the same result are anathema to science. Students filling up directories with lab data like for there to be a difference between “a.dat” and “A.dat” and sorts them according to ASCII value rather than orthography. It's a sure-footed, obedient scheme, one where the computer does exactly what the user wants it to do — because the user is one who has the expertise to issue instructions that are very clear and precise and speak the same internal language that the computer does.

But that's not who desktop OSes are written for. In a desktop OS, there is no conceivable reason why you would want to have two files in the same folder that are, for all intents and purposes, named the same thing. “Picture1.jpg” is the same thing as “picture1.jpg”. No, really — it is. It's the metaphor by which you organize the people in your address book. Would you consider “john thomas” to be a different person from “John Thomas”? Would you be unconfused by a set of introductions at a party with both these fellows in attendance?

Mac and Windows users have to have filenames read to them over the phone by support techs. They have to be able to write little sticky notes to their mothers about how to open up the mail program, without worrying about how the filenames are capitalized. Haven't you ever fumed over a URL with initial-caps in the folder names in the path, having to fiddle with capitalization until you get a response that's anything but a 404? Haven't you ever been secretly pleased that e-mail addresses aren't case-sensitive?

...

[P_Tingen]

Ik werk zelf als ontwikkelaar in een taal die case-insensitive is. Op Windows ook nog, dus ook daar geen last van case-sensitivity. En misschien dat het daardoor komt, maar ik kan me echt niet voorstellen wat de voordelen zijn van een case-sensitive OS of ontwikkeltaal of waarom je het überhaupt zou willen.

Dus "onderbouw waarom je het niet wil"? Omdat ik niet zie dat het voordelen oplevert, maar wel potentiële problemen.

[Verwijderd]

Veel hoofdpijn en verwarring en ambiguïteit. Dat je twee bestanden "hallo.txt" en "Hallo.txt" kunt hebben, waar je je in kunt vergissen, dat je bij het intypen ook case sensitive moet zijn, enzovoort. Ik vind het extreem onhandig en levert mijns inziens NUL voordelen.

Dat er anderen zijn die juist liever wel een case sensitive filesystem willen, prima, maar ik hoop toch echt van ganser harte dat ze bij Apple case INsensitive ook als mogelijke optie houden.

[ede]

Ja, APFS is case sensitive

[Nibbz]

High Sierra zal draaien op apfs, Apple File System, in plaats van het dertig jaar oude hfs. Het nieuwe bestandssysteem is gebouwd op 64bits-processors en maakt volgens het bedrijf veel acties in macOS sneller op dezelfde hardware.

Zal een bestandssysteem nu voor zoveel meer performance moeten gaan zorgen?

[Guru Evi]

Wel zeker. Momenteel moeten bestandssystemen dingen zoals TRIM implementeren (een lelijke hack eigenlijk) en nog steeds de 'koppen' van de schijf aanspreken. Ook kun je maar 1 instructie tegelijk geven en moet je een queue bijhouden die maar 32 instructies kan bevatten. Ook moet je alle trucs voor SSD's toepassen in een klein stukje CPU/RAM op de schijf zelf en een groot stuk opslag om bij te houden waar je bepaalde "kop/sector" combinaties echt op de chip staan (voor wear leveling). Elke instructie kost dus extra tijd om alle vertalingen te doen en om sneller te gaan moet je dus snellere CPU's maken op de schijf (ARM om kosten te besparen) alhoewel er 16 cores van 5GHz een paar cm verder gewoon aan het wachten zijn op data.

Dit heeft natuurlijk wel zin in een draaiende schijf maar als je het hele systeem aanpast naar SSD kun je alles optimaliseren op de gewone CPU/GPU en dingen als wear-leveling moeten dan geen extra vertaalslag op de SSD maken.

[Blokker_1999]

Er zijn zeker voordelen te vinden in een nieuw FS, zeker als het oude 30 jaar oud is. Vergeet niet dat we op gebied van opslag technologie enorm ver zijn gekomen in die 30 jaar en voor sommige doelen heeft men moeite moeten doen om het er in te krijgen.

[Maurits van Baerle]

Onder iOS zorgt het in ieder geval wel voor performance verbeteringen. Omdat het ontwikkeld is voor SSDs in plaats van HDDs zijn er een aantal zaken die je efficiënter kunt aanpakken omdat je niet meer te maken hebt met leeskoppen die maar één ding tegelijk kunnen lezen bijvoorbeeld.

Verder ligt de basis voor HFS+ (de voorloper) decennia geleden, inmiddels is er veel mogelijk en vereist van het OS en een nieuw OS van scratch opbouwen betekent dat je niet meer rekening hoeft te houden met zaken die ooit belangrijk of beperkend waren.

[Aaargh!]

Jazeker. Het feit dat het copy-on-write is maakt het e.a. al een heel stuk sneller. Zo is het veel makkelijker op backups te maken met een COW filesystem.

[Marctraider]

Mja allemaal leuk en aardig zo'n nieuw filesystem, misschien dat het in de oude hardeschijven tijd allemaal uitmaakte, maar zeker nu we supersnelle NVMe drivers hebben merk je er echt geen drol meer van. Misschien als je honderd duizenden kleine mini bestandjes tegelijkertijd kopieert ofzo.

[Dim]

Nee, daar heb je dus volkomen ongelijk in. De oude filesystems zijn allemaal ontworpen voor traag draaiende roestige schijven, die maar 1 of 2 commando's tegelijkertijd kunnen verwerken, en die tientallen milliseconden toegangstijd hebben. Laten we het al helemaal niet over cylinders, koppen en tracks hebben enzo.

Het is juist heel belangrijk om filesystems nu aan te passen om ze beter te laten aansluiten op de eigenschappen van snelle flash storage. Dingen als Copy On Write, snapshotting, integriteitscontrole, enzovoorts, die kunnen allemaal veel efficienter met flash.

Voor een gemiddelde gebruiker zal het natuurlijk allemaal worst wezen, maar "sneller!" doet het dan toch ook goed?

[Blokker_1999]

Maar wat ga je met een nieuwe high performance motor doen in een chassis dat gebouwd werd in een periode dat de Mini en de 2PK populair waren? Heel je OS is modern, maar je bestandssysteem is in de basis 30 jaar oud.

[landcross]

Er zijn al best veel bestandssystemen. Wat maakt deze nieuwe van Apple dan zo bijzonder? Wat maakt deze 'sneller'? Waarom kon er niet een (nieuwer/ander) bestaand bestandssysteem worden gebruikt?

Niet als kritiek bedoeld overigens, vraag het me oprecht af

[ZpAz]

Het heeft instant copying.

Enkel meta data wordt gekopieerd, en wijzigingen worden bijgehouden, althans dat is wat ik er van snap. Dat zou ook direct schijfruimte schelen.

[Blokker_1999]

Je maakt gewoon een nieuwe entry aan in de bestandstoewijzingstabel en de data blijft staan waar hij staat. Pas je dan 1 van de 2 bestanden aan dan worden enkel de gewijzigde blokken opnieuw gelinked aan het aangepaste bestand. Je bespaard dus inderdaad ruimte met het maken van een kopie. De techniek op zich is niet nieuw, maar het is interessant dat Apple het nu zo beschikbaar maakt voor de eindgebruiker.

[iAR]

Dat is toch wel vrij nieuw voor eindgebruikers toch of zijn er andere FSs die zo werken?

Is het dan in theorie zo dat op een 20GB schijf je 1 bestand van 10GB hebt, dat je dupliceerd waarna je nog steeds 10GB vrij hebt? En pas elke wijziging in bestand 2 neemt "nieuwe ruimte".
Even afgezien van details.

[Reactie gewijzigd door iAR op 30 juli 2024 01:20]

[NiLSPACE]

Lijkt mij ook dat dit best verwarrend kan zijn. Stel ik heb 20 GB over op mijn volume en kopieer een bestand van 30 GB. Dit lijkt gewoon te werken, maar als ik dit bestand dan aanpas krijg ik plotseling te horen dat ik te weinig ruimte over heb.

[Blokker_1999]

Om dezelfde reden dat MS blijft vasthouden aan NTFS: het in eigen beheer houden van je bestandssysteem zodat je niet gebonden bent aan wat welke richting anderen willen uitgaan.

[Nha]

Dus liever achterlopen maar "controle" behouden? Zwak excuus wanneer je net zo goed 30 jaar bij een oude versie van gelijk welk FS kunt blijven zonder het zelf te hoeven schrijven. En dan gewoon de features kopieren van die FS'en dat je lekker negeerde in al die tijd.
Ze wilden jaren geleden al overschakelen naar iets anders maar Jobs' ego zat dik in de weg (Sun had het voor Apple aangekondigd en daardoor viel de "deal" in het water). Weinig te maken met "controle behouden" al zullen ze dit nu misschien wel aanhalen als excuus want velen zijn dat voorval al vergeten of hebben er nooit van geweten.

(al valt er wel iets te zeggen over controle behouden)

[Keypunchie]

Het is vooral tijd. HFS+ is over tijd steeds meer uitgebreid en daardoor zijn er soms compromissen. (o.a. het aantal verschillende autorisatiemodellen op een file is eng)

Ooit had Apple een poging om ZFS te introduceren, maar dat ging mis op patenten. Op veel manieren is APFS de tweede poging. Zonder in detail te treden, veel van de features zijn vooral gericht op het feit dat de onderliggende hardware doorgaans geen HDD maar een SDD is geworden (copy-on-write is daardoor heel zinnig).

Een voorbeeldje daarvan was in de demo: een duplicatie wordt daardoor nagenoeg instant. Pas als je gaat modificeren, krijg je een echte kopie.

[Niet Henk]

Wikipedia heeft een lijstje van features. Een aantal handige zijn clones (bestanden kopiëren zonder extra ruimte in beslag te nemen, de echte kopie komt er pas als er wijzigingen worden gemaakt), snapshots (backups waarbij vanaf dan alle wijzigingen worden bijgehouden, zonder dat dit veel extra ruimte kost), encryptie op file system niveau en meer.

Kortom, duidelijk een vooruitgang. Een modern bestandssysteem biedt best wat voordelen ten opzichtte van één van 30 jaar geleden.

Waarom Apple kiest een eigen bestandssysteem te ontwikkelen, i.p.v. één van de open source alternatieven, zal je aan hen moeten vragen. Waarschijnlijk de controle houden. Maar ZFS zonder online deduplication aan en btrfs bieden vergelijkbare voordelen.

[divvid]

Nu maar hopen dat de Linux ondersteuning voor APFS niet al te lang op zich laat wachten, soms is het verrekte handig om zoals nu HFS+ondersteuning te hebben.

[Maurits van Baerle]

Apple heeft al aangegeven de specificaties te gaan publiceren dus dat moet relatief eenvoudig worden. Ik denk dat het wachten is op het moment dat de specificatie stabiel genoeg is dat er geen backward-incompatible wijzigingen meer komen.

[Electrifying]

Nou vraag ik me af met betrekking tot HEVC. Je hebt best wel een performance hit als je VP9 filmpjes van Youtube af gaat spelen via Chrome (VP9 is min of meer vergelijkbaar met HEVC). Apple maakt HEVC decoding ook beschikbaar op oudere machines met een Software decoder. Apple kennende zullen ze dat alleen doen met de wetenschap dat het dan ook goed werkt op deze oudere machines. Wat voor performance gaan we hiervan verwachten?

[Verwijderd]

Wat bedoel je met "Apple maakt HEVC decoding beschikbaar", HEVC codecs en players zijn toch al lang mainstream? VLC, MPlayerX, enzovoort spelen dat toch al sinds jaar en dag prima af zonder iets speciaals van Apple nodig te hebben?

[Verwijderd]

Ik neem aan dat het om QuickTime en Safari gaat.

[Electrifying]

Klopt. Althans, is een aanname. Ik heb de Keynote bekeken gisteren en daarin werd dit aangegeven. Dus ik neem aan dat het dan gewoon om Native support gaat.