Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#686/30-Jun-03

Voordat je uren doorbrengt met het optimaliseren van de harde schijf van je Mac, lees het artikel van David Shayer waarom het zonde van je tijd is. Ook maakt Adam deze week z'n MacHack verslag af met anekdotes over de mensen, evenementen en de mode van de conferentie. Tenslotte noteren we de winnaars van de Apple Design Awards van dit jaar, verhelderen we enkele Mac OS X adoptie aantallen, vertellen we over Extensis' aankoop van DiamondSoft en het overlijden van Casady & Greene, en we vragen om Duitse vertalers.

Onderwerpen:

Copyright 2003 TidBITS Electronic Publishing. All rights reserved.
Information: <[email protected]> Comments: <[email protected]>

-> Denk je dat TidBITS interessant is voor <-
-> je vrienden, kennissen, collega's? Geef <-
-> hen de tip zich ook GRATIS te abonneren <-
-> of stuur deze aflevering naar hen door! <-

Je kunt je gratis abonneren op de Nederlandse afleveringen van TidBITS door een (blanco) mailtje te sturen naar: [email protected]. Je krijgt deze dan per e-mail toegestuurd.
Om je abonnement op te zeggen, kun je een mailtje sturen naar: [email protected].

Deze editie van TidBITS werd gedeeltelijk gesponsord door:

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de USA.

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

Hoe je ons kunt bereiken kun je lezen op:
<./tidbits-nl/contact.html>

MailBITS/30-Jun-03

[vertaling: PEP, SL]

Casady & Greene houdt ermee op -- Na 19 jaar houdt Casady & Greene, een van de oudste bedrijven in de Macintosh markt, ermee op; vertelt Bonnie Mitchell, vice-president van Casady & Greene voor Public Relations. Nog niet alle details zijn bekend op het tijdstip dat wij dit schrijven maar het lijkt erop dat Casady & Greene eenvoudig niet genoeg financiële ruimte had om door te gaan. Hoewel het bedrijf dit jaar een aantal Mac OS X producten, waaronder Spell Catcher X, tri-Catalog, Clone X en iData Pro op de markt bracht (zie " iData Pro X 1.0.5, de digitale schoenendoos" in TidBITS-675), waren de inkomsten niet voldoende om open te blijven en om de programmamakers te betalen. Geen van de huidige producten heeft de uitstraling van het eerdere Conflict Catcher (dat niet meegroeide naar OS X) of Soundjam, dat de basis werd voor iTunes van Apple; de overstap naar OS X bleek een groot probleem voor dit bedrijf. [ACE]

<http://www.casadyg.com/>
<http://db.tidbits.com/getbits.acgi?tbart=07145>

Extensis neemt DiamondSoft over -- Net een paar dagen nadat Apple laat weten dat Mac OS X 10.3 Panther een programma zal kennen voor het beheer van lettertypes dat ze Font Book noemen kondigt Extensis (de makers van Suitcase) aan dat ze DiamondSoft (de makers van Font Reserve) overnemen. Toeval? Eigenlijk, ja; aangezien zulke overnames toch altijd meer dan een paar dagen vergen. Nicole Andergard van Extensis bevestigde dat de overname al enige tijd werd voorbereid en de aankondiging van Font Book verraste beide bedrijven. Het doel van de overname is om de kracht van de cliënt-functie van Suitcase met de kracht van de server-functie van Font Reserve te combineren om de allerbeste fontbeheertoepassing te maken voor de uitgeversbranche. Hoewel Apple nog weinig details van Font Book bekend heeft gemaakt gelooft Nicole op basis van wat ze nu weet dat zo'n basis fontbeheerprogramma niet zal voldoen aan de eisen van de beroepsgebruikers van Suitcase.[ACE]

<http://www.extensis.com/press/releases/063003_fr.html>
<http://db.tidbits.com/getbits.acgi?tbart=06751>
<http://db.tidbits.com/getbits.acgi?tbart=06797>

Remember? niet vergeten -- Remember? van Dave Warker, een subliem eenvoudige kalender met een herinnerfunctie die ooit begon als een bureaublad accessoire heeft eindelijk een Mac OS X opvolger met versie 4. Hoewel Remember? geen wimpel over meerdere dagen kan vertonen is het met z'n fantastisch en eenvoudige interface en flexibele herinneringen een waardig alternatief voor iCal, en voor $20 shareware is het een koopje.[MAN]

<http://www.warker.com/remember.html>

Nog eens de Jaguar upgrade percentages -- Verleden week vertelde ik dat ik van een ontwikkelaar op MacHack had gehoord dat slechts een marginaal percentage van Mac OS X gebruikers niet was overgestapt van Mac OS X 10.1 naar Jaguar, een feit dat mij zeer verbaasde. Het blijkt dat ik met reden verbaasd was - het feit was onjuist (zoals de ontwikkelaar zei, je moet niets geloven van wat je hoort als je al 48 uur niet hebt geslapen). Hier is hoe het zat. 75 procent van de klanten van deze ontwikkelaar gebruiken OS X, daarvan gebruikt slechts 1 procent nog steeds Mac OS X 10.1. Een andere ontwikkelaar met een toepassing die automatisch terugrapporteert over de besturingssysteemversie van zijn klanten vertelde mij zijn cijfers, haast identiek, dus dacht ik dat het aantal gebruikers die nog met Mac OS X 10.1 draaiden zeer laag was.

Maar je moet bij deze cijfers een aantal slagen om de arm houden. Hoewel ze automatisch worden verzameld is het verstrekken van deze informatie een optie, het is dus mogelijk dat klanten die nog onder een eerdere versie van Mac OS X draaien dit niet laten weten. Ten tweede, en van meer invloed op de tellingen, komen deze cijfers van mensen die nieuwe software registreren op hun computers, op zich een gebeurtenis die vaak samenhangt met het opwaarderen van een nieuw besturingssysteem. Hoe zal ik het zeggen, gebruikers die niet betaalden voor hun nieuwe Jaguar zullen waarschijnlijk geen gebruik maken van de mogelijkheid om nieuwe shareware te registreren? [ACE]

Apple reikt ontwerpprijzen 2003 uit -- Aan het eind van de Worldwide Developer Conference (WWDC) afgelopen week maakte Apple de winnaars van zijn jaarlijkse Apple Design Awards bekend. Net als vorig jaar zijn de prijzen bedoeld als erkenning voor Mac OS X programma's die uitblinken in zeven categorieën. Bovenaan de lijst, met twee prijzen, was Salling Clicker 1.5 van Salling Software. Dit programma kreeg de prijs voor het beste Mac OS X product (beste van de show) en voor het meest vernieuwende Mac OS X product. Door middel van Bluetooth netwerken kunnen bezitters van bepaalde Sony-Ericsson mobieltjes scriptbare programma's zoals iTunes of Keynote op hun Macs aansturen. (Vooral de mogelijkheid, "proximity sensor" scripts te draaien die actief worden als de telefoon in het Bluetooth-bereik van de Mac komt, is gaaf.)

<http://developer.apple.com/wwdc/designawards.html>
<http://db.tidbits.com/getbits.acgi?tbart=06818>
<http://homepage.mac.com/jonassalling/Shareware/Clicker/>

De prijs voor de beste Mac OS X gebruikerservaring ging naar Starry Night Backyard 4.0 van Space Holdings (zie "Op naar boven met Starry Night Backyard" in TidBITS-542). World Book 2003 Jaguar Edition van Software MacKiev werd bekroond voor het beste gebruik van Mac OS X technologie. Martin Ott, Martin Pittenauer, Dominik Wagner, en Ulrich Bauer van de Technische Universitat Munchen werkten samen aan het samenwerkingsgereedschap, Hydra 1.0.1, een op Rendezvous gebaseerde tekstverwerker waarmee verschillende mensen gelijktijdig kunnen werken aan een document, en wonnen daarmee de prijs voor het beste Mac OS X studentenproject. (Adam en ongeveer tien andere bezoekers van MacHack gebruikten Hydra om aantekeningen te maken gedurende de Hack wedstrijd van dit jaar.) De universiteit van Michigan wist het beste open sources te gebruiken voor Mac OS X, met Fugu 1.0, een grafische interface voor SFTP (Secure File Transfer). En er was dit jaar een nieuwe categorie: de Best Mac OS X Server Solution prijs. Die werd gewonnen door BioTeam met iNquiry 1.0, software die op meer Mac OS X Server machines geladen kan worden zodat ze gezamenlijk kunnen gaan rekenen, om zo biologische gegevens te analyseren (zie "Bioinformatics en de Mac" in TidBITS-622). Onze gelukwensen aan de winnaars, en aan de programma's die net naast de prijzen grepen. Je vindt een opsomming op de website van Apple. [JLC]

<http://www.starrynight.com/>
<http://db.tidbits.com/getbits.acgi?tbart=06069>
<http://www.mackiev.com/>
<http://hydra.globalse.org/>
<http://db.tidbits.com/getbits.acgi?tbart=07244>
<http://rsug.itd.umich.edu/software/fugu/>
<http://www.bioteam.net/>
<http://db.tidbits.com/getbits.acgi?tbart=06764>

Duitse (en Nederlandse) vertalers gezocht! Onze Duitse vertaalploeg is zodanig teruggelopen in omvang en beschikbare tijd dat het ze al een tijdje niet meer gelukt is TidBITS te vertalen. (Met onze Japanse, Nederlandse en Franse vertalingen verloopt alles naar wens; voor Spaans en Russisch zijn nieuwe vertaalploegen nodig.) Als je wekelijks wat tijd kunt missen om te helpen met de vertaling van TidBITS in het Duits, of om te helpen met het in elkaar zetten en verspreiden van het eindproduct (als je het Duits goed genoeg beheerst om de redactie te kunnen doen, maar moeite hebt met vertalen), zal het Duitstalige deel van de Macintosh-gemeenschap je dankbaar zijn. Neem voor meer informatie contact op met Heinz Gnehm <[email protected]>. (De Nederlandse ploeg heeft geen problemen, maar om dat zo te houden is versterking even goed welkom. Neem als je interesse hebt contact op met Sander Lam <[email protected]>.) Bedankt voor je hulp! [ACE]

MacHack 2003 inkijkjes

door Adam C. Engst <[email protected]>
[vertaling: GH, MSH, JG]

Meestal trek ik na Macintosh conferenties enkele conclusies over wat er voor de hele Macintosh wereld aan lering getrokken kan worden uit de deelnemers, de discussies, de toehoorders en de rest. Na de MacHack van dit jaar valt er niet zoveel te concluderen, met dank aan Apple voor het verschuiven van de Worldwide Developer Conference (WWDC) naar de dag nadat de MacHack eindigde. Dat betekende dat de ontwikkelaars op de MacHack slechts konden speculeren over de mogelijke aankondigingen op de WWDC, en erger, het betekende dat er geen Apple Feedback sessie was en maar een handjevol Apple werknemers in plaats van een stuk of 15. (Er waren 20 procent minder toeschouwers, een belangrijk gegeven gezien het conflict met WWDC.) Bijna alle hacks gebruikten Mac OS X en je moest echt zoeken naar iemand die Mac OS 9 nog gebruikte, maar dat zegt niet echt veel meer. Op het eind was de MacHack minder op de Macintosh gericht, en mijn indruk van de gehoorde commentaren was dat de sessies en werkstukken bijzonder goed waren dit jaar. Erg goed te genieten (en wellicht representatief) was de heropvoering van de sessie van Keith Stattenfield van vorig jaar "Mac OS 9 is dood!" , waarin hij bewogen sprak over wat Mac OS 9 nog betekent voor mensen en hoeveel mensen het nog gebruiken voordat hij de nadruk legde op "Mac OS 9 is NOG STEEDS dood!" en hij lanceerde 5 dia's met eufemismes voor "dood."

In feite hebben de organisatoren van de conferentie besloten om het vergrote aandachtsgebied van de conferentie te erkennen, door hem te hernoemen in Advanced Developers Hands On Conference (ADHOC) en meer sessies toe te voegen over Unix, Palm en andere platformen. De hackwedstrijd zal ook iets veranderd worden, omdat de mensen die hem de afgelopen 17 jaar organiseerden tegenwoordig andere belangen hebben. Maar ondanks de naamsveranderingen en het uitgebreidere onderwerp heb ik er vertrouwen in dat er qua ervaring van de conferentie niet veel zal veranderen. Dat komt omdat, in tegenstelling tot elke andere industriële conferentie, de mensen die de sessies, werkstukken en andere gebeurtenissen organiseren zelf ook sinds tijden bezoeker zijn. Als eerste en belangrijkste, het is een conferentie van de ontwikkelaars, voor de ontwikkelaars, en door de ontwikkelaars, om de Gettysburg verklaring te parafraseren. Kijk uit naar ADHOC volgend jaar, spannend geagendeerd van 21 tot 24 juli 2004, maar onderhevig aan verandering als dat noodzakelijk is om andere conferenties te vermijden.

<http://www.adhocconf.com/>

Dus in plaats van verreikende conclusies te trekken geef ik liever een paar inkijkjes hoe het voor mij is om op de MacHack te zijn, samen met een paar achter-de-schermen plaatjes van elk.

<http://www.tidbits.com/resources/686/machack-2003.html>

Week van de Overall -- Sinds hij de hoofdtoespraak een paar jaar geleden op de MacHack gehouden heeft is Andy Ihnatko net zo verslaafd geworden aan de MacHack als ik, en hij komt ieder jaar. Maar afgelopen jaar had hij niet gehoord van de informele oudste t-shirt wedstrijd, dus in een vlaag van nerdigheid riep hij MacHack uit tot "Week van de Overall" en verscheen elke dag stijlvol in een overall. Hij begon met een Wingz overall, een homage aan de begindagen van de Mac toen het Wingz spreadsheet een enorme klapper maakte op de Macworld Expo. De volgende dag een overall gedragen door technici van de nucleaire fabriek Yankee Point 3 (gekocht in een Leger des Heils winkel, en met een vriend gecontroleerd op radioactiviteit). En de derde dag bracht een authentiek Space Shuttle vlieg-overall uit het pre-Challenger tijdperk, compleet met NASA en shuttle emblemen.

<http://www.cwob.com/>

Nieuws! mobieltjes te klein! Kort na aankomst op de MacHack kon Greg Robbins, werkend aan RealOne Player bij Real Networks, en hij woonde een paar kilometer bij ons vandaan in Issaquah, Washington, zijn GSM niet vinden in zijn tas. Nadat hij een paar minuten gezocht had belde ik hem vanaf mijn GSM en het overgaan bevestigde dat hij in de omgeving van de tas was. Ondanks verder zoeken kon Greg hem nog steeds niet vinden en een tweede belpoging toonde aan dat hij uit z'n tas gevallen was in een plantenbak in de hotellobby. Nog iets kleiner en we moeten deze gekke telefoons aan ons lichaam vastbinden in plaats van aan de riem.

<http://www.real.com/>

Als je bij een vork komt -- (Amerikanen noemen een tweesprong in een weg een vork, vert.) Zoals het fameuze gezegde van Yogi Berra gaat, als je bij een vork in de weg komt, pak hem op. Yogi heeft er waarschijnlijk nooit over nagedacht waar vorken de meeste tijd doorbrengen (in andermans mond), maar omdat dit een van de weinige keren was dat Geoff Canyon, die bij Runtime Revolution werkt, en ik een echte vork in een echte weg zagen hebben we hem genomen. Z'n foto eigenlijk. En we vroegen ons af of z'n nabijheid bij de MacHack eigenlijk betekende dat het een codevork was.

<http://www.inspiredlogic.com/>
<http://www.runrev.com/>

Oprispingen in de nacht -- Na de tweede lezing van Scott Knaster, gevuld met talrijke verhalen over Apple en General Magic die ik nog nooit gehoord had, bezette een aantal mensen een van de vergaderkamers voor een informele whisky en port proeverij. (Aantekening voor mijzelf: Denk niet dat je fatsoenlijke port kunt kopen binnen rij-afstand van het hotel in Dearborn, Michigan.) Chris Page, die werk aan de Palm Desktop voor de Mac, nam ook wat snacks mee. Zijn amandeltaartjes genereerden een paar riskante grappen (denk eraan dat het op dit punt 3 uur in de ochtend is), dus toen Chris de volgende snack uit zijn tas pakte, zei hij droog, "En hier hebben we een doos dubbelzinnigheden." Ik denk niet dat er mensen zich in hun drank verslikt hebben, maar een paar mensen kwamen in de buurt toen ze dubbel lagen van het lachen.

<http://www.chris-page.org/>
<http://www.palm.com/us/software/desktop/mac.html>

Een familie die samen hackt... De auteur van Default Folder, Jon Gotow, en zijn 15 jaar oude zoon Ben waren meestal onafscheidelijk tijdens MacHack terwijl ze werkten aan hun winnende hack, Unstoppable Progress (zie "De MacHax Beste Hack wedstrijd 2003" in TidBITS-685). Op MacHack is technologie niet alleen uiterst sociabel, maar brengt tieners er ook toe bij hun ouders te willen blijven. Nou ja, sommige tieners tenminste, al moet ik zeggen dat de studenten die ik door de jaren heen ontmoet heb op MackHack meer dan gemiddeld aangepast leken.

<http://www.stclairsoftware.com/DefaultFolderX/>
<http://db.tidbits.com/getbits.acgi?tbart=07244>

MacHack voedsel --Na vele jaren te hebben meegedaan aan MacHack heb ik een goede manier gevonden om om te gaan met het dubieuze eetschema en het junkfood van programmeurs dat zo bij de conferentie hoort. Onderweg naar het vliegveld stopte ik bij een kruidenier en kocht acht prima Braeburn appels. Zodoende kon ik iedere dag een appel eten als "ontbijt" voorafgaand aan de door het hotel aangeboden "lunch" die anders meestal de eerste maaltijd van de dag betekent. Ik weet niet hoe jij erover denkt maar ik kan niet tegen een volledige warme lunch na het ontwaken, maar de appel hield mijn maag voor de gek, die dacht dat hij naar de tweede maaltijd van die dag doorging. Dan, na een aantal snacks en vierkante pizzas om middernacht, bood een tweede appel een prima manier om wat gezond voedsel te verorberen. Bewijs dat ik iets ontdekt had? Iedere keer dat ik een appel uit mijn tas haalde keek een ander er verlangend naar en vroeg waar ik die vandaan had gehaald. Dit is misschien een hint dat we allemaal ouder aan het worden zijn.

In feite was het voedsel dit jaar een verbetering ten aanzien van wat het hotel als standaard levert want de conferentie-organisatie overtuigde de hotelkoks dat MackHack bezoekers avontuurlijke eters waren. De eerste lunch had een mexicaans thema, het moge geen haute cuisine (of authentiek Mexicaans) zijn, het was stukken beter dan de "alsjeblieft niet weer!" rijstpilaf met naar keuze kip of zalm. De tweede lunch draaide rondom een Russische of althans een Noordeuropees thema en wederom, al was het niet precies mijn keuze geweest om zoiets een uur na het opstaan te eten, saai was het tenminste niet.

Een van de koks kreeg het zelfs te pakken en kerfde een appel in een fruitsaladeschaal van watermeloen en hielp bij het bakken van een koekje dat wel leek op de Spinning Pizza of Death. Maurita Plouff, die assisteerde bij het koekje, riep experts op om de kok te helpen een multimedia visitekaart samen te stellen, te gebruiken bij wedstrijden van de koks.

Bestanden delen nog steeds irritant -- Het is verbazingwekkend dat, ondanks alle vooruitgang van de afgelopen tien jaar, een bestand verhuizen van de ene computer naar een andere nog steeds onnodig moeilijk is. Het interne MacHack netwerk werd geplaagd door wat een foute switch geweest zou kunnen zijn, en als resultaat liet Rendezvous, handig voor het tonen van TCP/IP netwerken, niet altijd gedeelde computers zien. En dan waren er de vergissingen van gebruikers - mensen die bestanden delen niet aangezet hadden, of mensen die om een of andere reden de onjuiste permissies op hun Drop Box mappen ingesteld hadden, of andere problemen. In sommige gevallen loste overschakelen naar een Computer to Computer Network (Apples naam voor ad hoc netwerken, passend genoeg voor de toekomstige naam van deze conferentie) het probleem op. Moraal van het verhaal is dat bestanden delen steeds beter wordt maar er is nog steeds ruimte voor verbetering.

Verpletter Hulk -- Tenslotte zijn we samen de Hulk film gaan zien na het feestbanket en, wow, wat was dat een slechte film. Zelfs niet een goeie slechte film, waar je van geniet maar je een beetje schuldig voelt omdat je geen Mighty Wind gezien hebt (Spinal Tap voor folk-muziek, hoewel bijna niets zo grappig is als Spinal Tap) of Bend It Like Beckham (een bijzonder leuke film over een indiaas meisje dat voetbalt in Engeland). Nee, de Hulk is gewoon een slechte film die alle stripfans irriteerde en alle anderen verwarde, vermoedelijk komt een deel van de schade doordat de Hulk toegestaan was om naar het script te kijken. "Hulk verplettert plot. Petieterige mensen schrijven stomme film." Gedurende de traditionele "Keith Explains" groepspoging om te begrijpen wat er werkelijk in de film gebeurd was (waarbij Keith Stattenfield van Apple en de rest van ons ieder klein detail onderzochten om meer humor dan feitelijk aanwezig was aan de film te onttrekken), was er een kleine discussie over de beste scène in de Hulk: het optreden van Marvel Comics' Stan Lee en Lou Ferrigno (die de Hulk jaren geleden speelde in de tv-serie) als bewakers in het begin van de film, of de trailer voor Tomb Raider II, die belooft een veel aangenamere slechte film te zijn.

<http://keithexplains.com/>
<http://www.thehulk.com/>
<http://amightywindonline.warnerbros.com/>
<http://www.foxsearchlight.com/bendit/>
<http://www.tombraidermovie.com/>

Optimaliseren van disks is tijdverspilling

door David Shayer <[email protected]>
[vertaling: EB, TK, RAW]

Optimaliseren van disks is tijdverspilling. Zo, ik heb het gezegd. Het hoge woord is eruit. Dus waarom geloven zoveel mensen dat een 'optimizer' een essentieel onderdeel is van de gereedschapskist van elke Mac-gebruiker? En wat betekent het optimaliseren van een disk eigenlijk?

Achtergrondfragmenten -- Wanneer je een bestand op een disk bewaart, kijkt het bestandssysteem naar een lege plek om de data te schrijven. Als er geen enkele plek is die groot genoeg is, wordt het bestand verdeeld over een aantal kleinere plekken. Wanneer een bestand is opgeslagen in meer dan één deel, zeggen we dat het gefragmenteerd is. Elk deel van zo'n bestand heet een fragment.

Een bestand kan gebroken zijn in twee fragmenten, of 20 fragmenten, of 200 fragmenten. Het kan het bestandssysteem niet schelen, dat kan elk aantal fragmenten even goed aan. Het lezen van een gefragmenteerd bestand kost echter meer tijd dan het lezen van een ongefragmenteerd bestand. Hoe meer fragmenten, hoe langer het lezen. Dat is omdat de leeskop van de harddisk van fragment naar fragment moet bewegen en elk fragment afzonderlijk moet lezen. Het lezen van een aaneengesloten brok data is snel, zelfs wanneer dat een nogal groot brok is. Maar het bewegen van de kop van fragment naar fragment is in vergelijking langzaam. (En ik bedoel "in vergelijking" - we hebben het hier over extra milliseconden.)

De oplossing voor deze vertraging? Defragmenteren of optimaliseren. Sommige programma's claimen een disk te defragmenteren, andere zeggen hem te optimaliseren en een paar bieden beide functies aan. Wat is het verschil?

Defragmenteren is het in één fragment wegschrijven van bestanden die in meerdere fragmenten zijn opgedeeld. Maar het defragmenteren van bestanden is maar een deel van het probleem, omdat de vrije gedeeltes van een disk vaak in veel stukjes zijn gesplitst, een beetje hier en een beetje daar. Het komt erop neer dat de vrije ruimte gefragmenteerd is. Je hebt misschien 5GB vrij, maar dat kan in 5000 stukjes van 1mb elk zijn. Het volgende bestand dat je bewaart kan meteen gefragmenteerd zijn, eenvoudig omdat er niet voldoende ongefragmenteerde vrije ruimte is. Dat is waar optimaliseren gaat meespelen - het defragmenteert alle gefragmenteerde bestanden en de vrije ruimte.

Sommige 'optimizers' plaatsen gelijksoortige bestanden fysiek bij elkaar, zoals alle besturingssyteembestanden. Dit zou de computer nog sneller maken, omdat besturingssyteembestanden waarschijnlijk tegelijk benaderd worden, en zo wordt voorkomen dat de leeskop grote afstanden moet overbruggen om het volgende bestand te lezen. Hoewel het concept in eerste instantie goed klinkt, twijfel ik eraan of deze techniek enige waarneembare snelheidsverbetering veroorzaakt. Behalve in een aantal simpele gevallen is het namelijk erg moeilijk te voorzien welke volgend bestand de computer wil zien.

Dus optimaliseren van de harddisk zou je Mac sneller maken, toch? Nou, misschien. Als een bestand dat je de hele tijd gebruikt gefragmenteerd is, zoals een deel van het besturingssysteem met een sleutelrol, dan zou het defragmenteren van zo'n bestand echt kunnen helpen. Maar het besturingssysteem is gewoonlijk op de disk geschreven, direct nadat die vers geformatteerd was. De disk was leeg, dus het besturingssysteem is zelden gefragmenteerd. Als een bestand dat je zelden gebruikt is gefragmenteerd, zoals die Quicktime-film van tante Ethel's verjaardagspartij, maakt het niet uit zolang je normale toegang tot het bestand hebt - het filmpje afspelen in dit geval. Kortom, het vermijden van fragmentatie is alleen behulpzaam bij bestanden die constant gebruikt worden.

Maar waar komt die cultus van disk-optimalisatie nou vandaan? In de begintijd van Windows, en DOS daarvoor, gebruikten PC's het FAT (File Allocation Table) bestandssysteem. Volgens de legende ging het FAT-bestandssysteem niet zo best om met gefragmenteerde bestanden, dus disks raakten snel enorm gefragmenteerd. Destijds waren disks - en computers in het algemeen - extreem langzaam, zeker naar hedendaagse maatstaven. Met die pijnlijk langzame disks en computers kon het optimaliseren van een disk een merkbare prestatieverbetering opleveren. Moderne computers en harddisks zijn uiteraard veel sneller en hebben ook veel grotere en meer verfijnde 'diskcaches', wat alles bij elkaar de invloed van een gefragmenteerde disk significant vermindert.

Toen Apple het HFS (Hierarchical File System) bestandssysteem ontwierp voor de Mac, en later toen ze HFS vervingen door HFS+, deed men speciale moeite om fragmentatie te minimaliseren. Alle harddisks slaan data op in brokken van 512 byte, 'sectors' geheten. FAT, HFS en HFS+ gebruiken grotere brokken, die 'clusters' heten bij FAT en 'allocation blocks' bij HFS. Een doel van 'clusters' en 'allocation blocks' is te proberen fragmentatie te reduceren, door bestanden in grotere stukken op te slaan. Maar HFS gaat een stap verder. Bij het bewaren van een bestand op disk verdeelt het Mac-bestandssysteem de ruimte in nog grotere brokken, 'clumps' genoemd, in een verdere poging fragmentatie te verminderen.

Wanneer het Mac-bestandssysteem een bestand bewaart, zoekt het naar een vrije ruimte die groot genoeg is om het hele bestand te bevatten. Als dat er niet is vindt het het grootste beschikbare vrije stuk, dan het volgende grootste enzovoort, in een poging fragmentatie zoveel mogelijk te reduceren. HFS zal nooit een bestand fragmenteren als dat voorkomen kan worden.

Fragmentatie in de realiteit -- Bij de meeste mensen heeft schijffragmentatie twee oorzaken: een volle schijf en e-mail.

Het HFS+-bestandssysteem van de Mac slaagt er in het algemeen vrij goed in de fragmentatie te beperken, op voorwaarde dat er een redelijke hoeveelheid vrije ruimte op de schijf overblijft wanneer de bestanden in aaneengesloten brokken worden geschreven. Hoeveel vrije ruimte moet je aanhouden? Daar bestaat geen vaste regel voor, maar 20-25 procent van de totale schijfcapaciteit is een goede leidraad.

Als je op je schijf van 60 GB maar 5 GB vrij hebt, betekent dat niet dat je één vrij blok van 5 GB hebt. Meer dan waarschijnlijk zijn het tientallen, of zelfs honderden kleinere stukjes. Het grootste vrije blok is misschien maar 500 MB groot. Wanneer een schijf heel vol raakt, is er niet alleen minder vrije ruimte in totaal, maar is het grootste vrije blok ook veel kleiner. Dit leidt dan ook tot meer fragmentatie.

Welk type van bestand wordt nu het vaakst gefragmenteerd? De meest waarschijnlijke kandidaten zijn bestanden die regelmatig aangroeien, met altijd maar kleine toevoegingen. Telkens wanneer het bestandssysteem het bestand groter maakt, zoekt het een vrij blok, en het bestand wordt nog iets meer gefragmenteerd. Verschillende types van bestanden vallen onder deze noemer, maar e-mail staat wel bovenaan het lijstje.

Het Inbox-bestand van mijn e-mailprogramma is in meer dan 100 stukken gefragmenteerd. Heeft dit belang? Nee, het werkt nog altijd perfect. Draait mijn e-mailprogramma er trager door? Jazeker, maar niet zoveel dat ik er iets van merk. De belangrijkste reden waarom veel gebruikers hun schijf optimaliseren is dat zij hun Mac sneller willen laten werken. Je Mac wordt er ongetwijfeld iets sneller door, maar ik heb maar zelden een merkbare snelheidstoename gezien bij gebruik in de echte wereld.

Voor- en nadelen -- Je Mac sneller laten werken, zelfs al is de verbetering nauwelijks merkbaar, is dus één reden om je harde schijf te optimaliseren. Er is nog een tweede reden om bestanden te defragmenteren. Als je schijf gecrasht is, is het voor een herstelprogramma moeilijker om sterk gefragmenteerde bestanden te herstellen dan ongefragmenteerde bestanden, gewoon omdat het dan meer stukken moet opsporen. Welke bestanden lopen nu de grootste kans op fragmentatie? E-mailbestanden, die ook de meest waarschijnlijke kandidaat zijn van recente wijzigingen, wat ook met zich meebrengt dat de nieuwste versie waarschijnlijk niet in je laatste backup zit. (Verplichte vermelding - als je geen recente backup hebt, ga er dan na het lezen van dit artikel meteen een maken. Doen!)

Er zijn ook enkele goede redenen om niet te optimaliseren, en ironisch genoeg is snelheid er één van. Optimalisatieprogramma's zijn traag. Een schijf optimaliseren duurt uren. Heeft het zin je Mac uren vast te zetten om hem nadien je mailbox een seconde sneller te laten openen?

Angstaanjagender is het feit dat als het optimalisatieprogramma crasht, de schijf wel eens - om het met een technische term te zeggen - "om zeep." zou kunnen zijn. Een optimalisatieprogramma moet namelijk bijna elk stukje data op de schijf verplaatsen. De beste optimalisatieprogramma's werken met algoritmes die het risico op dataverlies tot zo goed als nihil herleiden, zelfs als de stroom tijdens een lange optimalisatie wordt onderbroken, maar een kleine kans op iets onverwachts blijft altijd bestaan wanneer je een programma alles op je schijf laat verplaatsen.

Het probleem is dat geen enkel programma perfect is. In eerdere versies van sommige optimalisatieprogramma's zaten bugs waardoor data verloren ging of schijven werden beschadigd. Bij mijn weten zijn de huidige optimalisatieprogramma's vrij van dit type van catastrofale bugs. Dat betekent echter niet dat toekomstige versies ook bugvrij zullen zijn, of dat een huidige versie geen problemen zal hebben wanneer je ze gebruikt met een nieuwe versie van het Mac OS. Neem geen risico's met optimalisatiesoftware!

Optimalisatieraadgevingen -- Als je je schijf gaat optimaliseren, controleer de schijf dan eerst met een programma zoals Schijf-EHBO of Schijfhulpprogramma van Apple. Een beschadigde schijf zou zelfs het beste optimalisatieprogramma kunnen doen crashen wanneer het beschadigde data of data op een totaal onverwachte plaats aantreft.

Het is ook een goed idee om eerst van je volledige schijf een backup te maken (of op zijn minst van je belangrijkste data). Maar zodra je een backup hebt, zou je net zo goed de schijf kunnen wissen, en alles van je backup terugplaatsen. Op deze manier wordt de schijf even goed geoptimaliseerd als met een optimalisatieprogramma. Bovendien krijg je zuivere directory-structuren door een harde schijf te herformatteren, en als je de schijf herformatteert met de optie "Alle gegevens omzetten in nullen" (wat lang duurt en alleen de moeite loont als je schijf vreemde problemen vertoonde), laat je de schijf ook eventueel ontstane slechte blokken markeren. Dat is waarom volgens mij Retrospect het beste optimalisatieprogramma is - het beschermt je data en optimaliseert je schijf.

<http://www.dantz.com/products/mac_express/>

Speed Disk, het optimalisatieprogramma in Norton Utilities van Symantec, biedt enkele nuttige eigenschappen voor het analyseren van een schijf. Het deelt de algemene schijffragmentatie in licht, matig, of ernstig in. Het loont vrijwel zeker niet de moeite een schijf te optimaliseren tenzij ze ernstig gefragmenteerd is, en vaak zelfs dan nog niet. Dat is waarom Speed Disk de fragmentatie van een schijf beoordeelt op basis van een combinatie van het aantal gefragmenteerde bestanden, de mate van fragmentatie, en de mate van fragmentatie van de b-trees (directory-structuren van de schijf). Het laatste item kan de diagnose wat alarmerend doen lijken, omdat de b-trees als initiator werken: als zij sterk genoeg gefragmenteerd zijn, kan Speed Disk automatisch de hele schijf een "ernstige" beoordeling toeschrijven, zelfs als de andere bestanden op de schijf onder andere omstandigheden hier geen aanleiding toe zouden geven.

<http://www.symantec.com/nu/nu_mac/>

Speed Disk laat een plaatje zien van de documenten en de vrije ruimte op je schijf, waaraan je kunt zien hoe sterk de vrije ruimte is gefragmenteerd. Het meldt ook de grootte van het grootste vrije blok, een nuttig stukje informatie om te onthouden, omdat elk bestand dat groter is noodzakelijkerwijs gefragmenteerd zal worden bij het opslaan. Als je vaak met bestanden werkt die groter zijn dan je grootste vrije blok, is het aan te raden om je schijf te optimaliseren.

Tenslotte maakt Speed Disk een lijst van alle gefragmenteerde bestanden en het aantal fragmenten per document en kun je individuele bestanden defragmenteren. Waarom zou je dat willen doen? HFS+ kan tot acht fragmenten bijhouden op de cataloguskaart van een bestand. Als een bestand meer dan acht fragmenten heeft, maakt HFS+ extra kaarten aan om de extra fragmenten bij te houden. Omdat bestanden met meer dan acht fragmenten iedere keer als ze geopend worden die extra kaarten moeten lezen, is een bestand met meer dan acht fragmenten zeker een goede kandidaat voor defragmentatie, als je het tenminste zo vaak gebruikt dat defragmenteren een echt voordeel heeft.

Je hebt doorgaans geen Speed Disk nodig om individuele bestanden te defragmenteren. Dat komt omdat je meestal zelf een bestand kan defragmenteren door het eenvoudigweg te dupliceren in de Finder. Wanneer het bestandssysteem het duplicaat-bestand aanmaakt, gebruikt het automatisch een enkel fragment voor het bestand, aangenomen dat er genoeg aaneengesloten vrije ruimte op de schijf beschikbaar is. Daarna kun je het origineel vernietigen en de kopie de naam van het originele bestand geven.

DiskWarrior 3 van Alsoft heeft de unieke eigenschap dat het een plaatje van de directory van een schijf kan laten zien, met een kleurenschema voor elementen die niet op volgorde staan. De "rebuild"-functie van DiskWarrior wordt normaal gebruik om defecte schijven te repareren, maar als het gebruikt wordt op een gezonde schijf, zal het de directory "optimaliseren". Hoewel Alsoft deze taak "optimalisatie" noemt, is het heel wat anders dan wat andere schijfoptimaliseerders doen. Andere schijfoptimaliseerders defragmenteren de bestanden op een schijf. DiskWarrior sorteert de schijfcatalogus.

<http://www.alsoft.com/DiskWarrior/>

De catalogus is opgebouwd uit knopen. Deze bevatten kaarten die met bestanden overeenkomen. Deze knopen vormen een boomstructuur, waarin alle knopen met elkaar verbonden zijn in een bepaalde volgorde. Het bestandssysteem probeert de knopen in de juiste volgorde te houden. Maar met het toevoegen en vernietigen van bestanden op de schijf worden er ook knopen aangemaakt, vernietigd en rondgeschoven, en zo kunnen ze uit volgorde raken. Dit is niet gevaarlijk, of zelfs maar verkeerd, het is alleen niet optimaal.

DiskWarrior zet de knopen weer op volgorde. In theorie zou dit een schijf sneller moeten maken, om dezelfde reden waarom defragmentatie een schijf sneller maakt, namelijk dat gerelateerde informatie samen wordt opgeslagen, zodat de schijfkop niet in verafgelegen sectoren hoeft te zoeken bij het ophalen. Maar ik vraag ik me af of het verschil in snelheid in werkelijkheid merkbaar is, vooral omdat het bestandssysteem delen van de catalogus in het geheugen bewaart, waardoor de toegang veel sneller is dan wanneer de informatie alleen op de harde schijf is opgeslagen. DiskWarrior is prima voor het herstellen van schijven met beschadigde directories, maar het optimaliseren van een goed werkende catalogus is onnodig.

Eindconclusie -- Samenvattend valt er voor de meeste mensen meestal niet genoeg winst te behalen met het optimaliseren van je schijf om de moeite te nemen. Er is niets fout aan het optimaliseren van een schijf, en voor een zwaar gefragmenteerde schijf die traag reageert bij het lezen van regelmatig gebruikte bestanden kan het zelfs nuttig zijn. Maar in het algemeen is het onnodig en er is altijd een klein risico. Als je echt je schijf wilt optimaliseren, is de beste manier om een backup te maken (met een tweede backup voor de zekerheid), je harde schijf opnieuw te formatteren en van de backup weer op te bouwen.

[David Shayer was een hoofdprogrammeur van Norton Utilities voor de Macintosh versies 3.0, 4.0 en 5.0. Daarvoor werkte hij aan Public Utilities, een schijfreparatieprogramma dat ooit de Redactieprijs van MacUser won, en aan Sedit, een schijfbewerker op laag niveau.]

PayBITS: Blij dat je geen tijd of geld hoeft te verspillen
aan schijfoptimalisatie? Bedank David via PayBITS! <http://www.amazon.com/paypage/P12NE4WQ7K8ODD>
Lees meer over PayBITS: <./paybits.html/>

(Natuurlijk is een gift aan de Nederlandse vertaalploeg ook welkom: <https://www.paypal.com/xclick/business=d.flach%40chello.nl&item_name=TBNL>.)

Recente onderwerpen in TidBITS Talk/30-Jun-03

door TidBITS Staff <[email protected]>

[De discussies waarnaar verwezen wordt zijn in het Engels, daarom hebben we de titels niet vertaald - Tb-NL.]

Power Mac G5 specs -- Seriële ATA-poortsnelheden, uitwisselen van harde schijven, het afvoeren van warmte, maximale RAM en meer in deze studie van de Power Mac G5. (27 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1981>

Older Power Macs still available -- In de nasleep van de aankondiging van de Power Mac G5 verkoopt Apple nog steeds een Power Mac G4-model... dat zelfs nog in Mac OS 9 kan opstarten! (4 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1982>

The "Outlook" for Mail -- De Mail-applicatie van Apple zal de Safari-engine gebruiken om HTML-berichten weer te geven in Mac OS X 10.3 Panther. Hoe kunnen we HTML-weergave beperken om kwaadwillende spammers een spaak in het wiel te steken? (5 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1983>

Motorola's PowerPC future -- Nu de PowerPC G5 is aangekondigd, wat gaat er gebeuren met de PowerPC G4-processor van Motorola? (2 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1984>

G5-based PowerBooks -- PowerBooks met de nieuwe PowerPC G5-chip, zullen die binnenkort verschijnen... of nooit? (6 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1985>

Text Clippings to the Palm -- Wat is de gemakkelijkste manier om simpele stukjes tekst op een Palm handcomputer te krijgen? Lezers geven een paar mogelijkheden. (4 berichten)

<http://db.tidbits.com/getbits.acgi?tlkthrd=1988>

Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering