Formålet med dette kapitel er at give en smule af den teoretiske baggrund for udskrift i almindelighed og for ∪︀ i særdeleshed. Hvis du ikke har brug for dette vil du måske hellere skippe frem til næste kapitel. Jeg vil regne med du kommer tilbage til dette kapitel på et eller andet tidspunkt alligevel, for sommetider har man brug for lidt ekstra teori for at løse et praktisk problem. Udskrift er et af de mere komplicerede kapitler i IT-teknologi. Tidligere i historien måtte enhver udvikler af et program, der skulle kunne producere udskriveligt materiale ud, også selv skrive sine egne printer-drivere. Dette var temmelig kompliceret, fordi forskellige programmer har forskellige filformater. Selv programmer med det samme formål, for eksempel, tekstbehandlingsprogrammer, forstår ofte ikke hinandens formater. Der var derfor ingen fælles grænseflade for alle printere, og derfor understøttede programmørerne ofte kun nogle få udvalgte modeller. Når en ny enhed kom på markedet var det nødvendigt at programforfatterne skulle skrive en ny driver, hvis de ønskede deres program skulle understøtte den. Det var også umuligt for fabrikanter at sørge for at deres enhed var understøttet af noget som helst program i hele verden (selvom der var langt færre end i dag). Det at skulle understøtte ti programmer og et dusin printere betød, at en systemadministrator skulle håndtere 120 drivere. Så udviklingen af forenede grænseflader mellem programmer og printere blev et påtrængende behov. Fremkomsten af Sidebeskrivelsessprog, som beskriver den grafiske repræsentation af blæk og toner papirark (eller andre uddata enheder som skærme fotosættere, &etc;) i på en fælles måde udfyldte et stort tomrum. En sådan udvikling var &PostScript; af Adobe. Det betød at en programmør kunne koncentrere sig om at få programmet til at lave en &PostScript;-sprog beskrivelse af udskriftssiden, mens udskriftsenhed-udviklerne kunne fokusere på at få deres enheder til at forstå &PostScript;. Naturligvis kom der med tiden en udvikling af andre beskrivelsesmetoder. De vigtigste konkurrenter til &PostScript; var PCL (Print Control Language, fra &Hewlett-Packard;), ESC/P (fra Epson) og GDI (Graphical Device Interface fra &Microsoft;). Fremkomsten af disse sidebeskrivelsessprog gjorde livet nemmere og hjalp udviklingen for alle. Men det faktum at der stadig var forskellige, inkompatible og konkurrerende sidebeskrivelsessprog gør livet svært nok endda for brugere, administratorer, udviklere og fabrikanter. &PostScript; er den mest brugte i professionel printmiljøer såsom PrePress og udskriftsservice industrier. Indenfor &UNIX; og &Linux; domænerne, er &PostScript; den dominerende standard som et PDL. Her genererer næsten alle programmer en &PostScript;-repræsentation af dens sider når du trykket på Udskriv-knappen. Lad os kigge på et simpelt eksempel på (hjemmelavet) &PostScript;-kode. Følgende listning beskriver to simple tegninger: %!PS 100 100 moveto 0 50 rlineto 50 0 rlineto 0 -50 rlineto closepath .7 setgray fill % first box over; next 160 100 moveto 0 60 rlineto 45 10 rlineto 0 -40 rlineto closepath .2 setgray fill Dette beder den imaginære &PostScript;-pen om at tegne en sti af en bestemt form, og så udfylde den med forskellige afskygninger af gråt. Den første del oversættes til mere forståeligt engelsk som Gå til koordinat (100,100), tegn en linje med længde 50 opad; så en derfra til højre, så ned igen, og til sidst lukkes denne del af. Udfyld nu den tegnede form med 70% grå. eksempel fremvist som et billede. &PostScript; kan naturligvis være meget mere kompliceret end dette simplistiske eksempel. Det er et fuldt udviklet programmeringssprog med mange forskellige operatorer og funktioner. Du kan endog skrive &PostScript;-programmer der beregner Pi's værdi, formatere en disk eller skriver til en fil. Hovedværdien og styrken ved &PostScript; er imidlertid i evnen til at beskrive layout af grafiske objekter på en side: den kan også skalere, spejle, translatere, transformere, rotere og forvrænge alt du kan forestille dig på et stykke papir -- såsom bogstaver i forskellige skrifttyperepræsentationer, figurer, forme, skygger, farver, linjer, prikker, raster... En &PostScript;-fil er en repræsentation af en eller flere sider der skal udskrives, beskrevet på en relativ abstrakt måde. Ideelt set er det meningen at siderne skal beskrives uafhængigt af enheden. &PostScript; er ikke direkte synlig; det lever kun på disken og i RAM som en indkodet repræsentation af fremtidige udskrifter. Det du ser på et stykke papir er næsten altid et rasterbillede. Selv om din hjerne får dig til at se en linje: så tag et godt forstørrelsesglas og du vil opdage masser af små prikker... (Et eksempel på det modsatte er linjer der er tegnede med pen-plottere). Og det er det eneste som nutidens printeres markeringsmaskiner kan putte på papir: simple prikker i forskellige farve, størrelse og resolution til at lave et fuldstændigt sidebillede komponeret af forskellige bitmap-mønstre. Forskellige printere skal have rasterbilledet tilberedt på forskellig måde. Hvis du tænker på en inkjet-enhed: afhængig af dens resolution, antallet af blækpatroner (de meget gode har brug for 7 slags blæk, mens en billigere måske vil bruge 3), antallet af tilgængelige dyser (nogle printhoveder har mere ned 100!) der fordeler blæk samtidigt, dithering-algoritmen der bruges og mange andre ting, er det endelige rasterformat og overførselsrækkefølge til markeringsmaskinen stærkt afhængig af den nøjagtige model der bruges. I et tidligere liv af Linje Printer Dæmon, printere, var det maskiner der hamrede rækker af ASCII-tekst mekanisk på lange medier, foldet som en zig-zag papirslange, trukket fra kartonfelte nedenunder bordet... Sikke en forskel til i dag! Før de endelige rasterbilleder bliver putte på papir skåret ud i ark, skal de beregnes på en eller anden måde ud fra deres abstrakte &PostScript;-repræsentation. Dette er en meget beregnings-intensiv proces. Den kaldes Raster Imaging Process, eller hyppigere RIP). Med &PostScript;-printere bliver RIP-ning sørget for i selve enheden. Du sender blot en &PostScript;-fil til den. Raster Imaging Processor (også kaldet RIP) indeni printeren er ansvarlig for (og specialiseret til) at udfylde opgaven at fortolke &PostScript;-sidebeskrivelserne og putte rasterbilledet på papir. Mindre &PostScript;-enheder har en hardware-RIP indbygget, den skåret i silicon, på en særlig chip. Store professionelle printere har ofte deres RIP implementeret som en software-RIP indeni en dedikeret hurtig &UNIX;-kørt computer, ofte en Sun SPARC Solaris eller en &SGI; &IRIX; maskine. Men hvad sker der hvis du ikke er så heldig at du har en &PostScript;-printer tilgængelig? Du bliver nødt til at gøre RIP-ningen før udskriftsdata sendes til markeringsmaskinerne. Du må selv fordøje &PostScript; genereret af dit program på værtsmaskinen (udskriftsklienten). Du bliver nødt til at vide hvordan nøjagtige rasterformat for målprinterens markeringsmaskine skal komponeres. Med andre ord, da du ikke kan regne med at printeren selv kan forstå og fortolke &PostScript;, bliver problemet en hel del mere kompliceret. Du har brug for programmel der prøver at løse de involverede problemer for dig. Dette er nøjagtigt hvad den allestedsnærværende &ghostscript;-pakke gør for mange &Linux;, *BSD og andre &UNIX; maskiner der har brug for at udskrive til ikke-&PostScript; printere: &ghostscript; er en &PostScript;-fortolker, en programmeret RIP der er i stand til at køre mange forskellige enheder. For at producere rastede bitmaps fra &PostScript; inddata bruges filter-begrebet af &ghostscript;. Der er mange forskellige filtre i &ghostscript;, nogle af dem specialiseret til en bestemt model af en printer. &ghostscript;-filter til bestemte enheder er ofte blevet udviklet uden samtykke eller støtte fra vedkommende der fremstillede enheden. Uden adgang til specifikationerne og dokumentation, var det en pinefuld proces at 'reverse engineer' protokoller og dataformater. Ikke alle &ghostscript;-filtre virker lige godt for deres printere. Men nogen af de nyere som stp-filtret for Gimp-printprojektet, producerer fremragende resultater der fører til fotografisk kvalitet der er på lige fod eller endog bedre end deres &Microsoft; &Windows; driver-modstykker. &PostScript; er det de fleste programmer producerer til udskrift i &UNIX; og &Linux;. Filtre er de sande arbejdsheste for et vilkårligt udskriftssystem der. Det er dem der egentlig producerer de rigtige bitmaps fra en vilkårlig &PostScript;-inddata for ikke-&PostScript; målmaskiner. ∪︀ bruger sine egne filtre selvom filtersystemet er baseret på Ghostscript. Filtrene pstoraster og imagetoraster filters er nemlig direkte afledt fra Ghostscript-kode. ∪︀ har re-organiseret og strømlinjet hele mekanikken i denne gamle kode og organiseret den i nogle få klare adskilte moduler. Denne næste tegning (lavet ved hjælp af &kivio;) giver et overblik over filtrene og de undeliggende programmer for ∪︀ og hvordan de passer sammen. Flydningen er ovenfra og ned. De underliggende programmer er specielle filtre: de konverterer ikke data til et andet format, men de sender de parate filer til printeren. Der er forskellige underliggende programmer for forskellige overførselsprotokoller. &kprinter;-dialog startet (&kivio; kladdetegning) &kprinter;-dialog startet (&kivio; kladdetegning) Foruden den tunge del med at filteropgaven til at generere en udskrifts-parat bitmap, vil udskriftsprogrammel altid behøve en kø-mekanisme: dette er for at sætte forskellige jobs op i rækkefølge fra forskellige brugere til forskellige printere og forskellige filtre og sende dem til deres mål på efter hinanden. Udskriftsdæmonen tager sig af alt dette. Denne dæmon sørger for husorden: den er også ansvarlig for jobkontrollen: brugere skal have lov til at annullere, stoppe, genstarte &etc; deres jobs (men ikke andre menneskers jobs) og så videre. Nu da du ved hvordan en &PostScript;-sprogfil (som beskriver sidelayout på en måde der stort set er enhedsuafhængig) går over til at blive til et rasterbillede, vil du måske spørge: Nuvel, der er forskellige slags raster-uddataenheder: for det første er de forskellige i opløsning; så kan der være forskellige papirstørrelser (dupleks udskrift, pamfletter, hullet eller klipset uddata med forskellige ark af farvet papir der bliver taget fra forskellige bakker &etc;). Hvordan passer dette ind i modellen med enhedsuafhængig &PostScript;? Svaret kommer med det såkaldte de &PostScript; Printer Description (&PPD; filer. En &PPD; beskriver alle de enhedsafhængige egenskaber som kan bruges for en bestemt printermodel. Den indeholder også indkodede kommandoer der skal bruges til at kalde visse egenskaber ved enheden. Men &PPD;er er ikke en lukket bog, de er simpelthen ASCII tekstfiler. &PPD;er blev opfundet af Adobe for at gøre det nemt fabrikanter at implementere deres egne egenskaber i &PostScript;-printere, og samtidigt beholde en standard måde at gøre det på. &PPD;er er veldokumenterede og beskrevet af Adobe. Deres specifikation er en de-facto åben standard. Husk at avanceret &PostScript;-udskrift oprindeligt kun blev udviklet til brug på &Microsoft; &Windows; og Apple &Mac;-systemer. I lang tid var alle egenskabsrig udskrift på moderne enheder simpelthen ikke tilgængelig for &Linux; og &UNIX;. ∪︀ ændrer dette afgørende. ∪︀ er meget tæt knyttet til &PPD;er, og derfor kan eksisterende &PPD;er bruges i fuldt omfang af alle systemer der køres med ∪︀. Ved brug af &PPD;er kunne printerfremstillerne indsætte enheds-specifikke maskinelegenskaber i deres produkter, for egenskaber såsom dupleks, hæftning, lave huller, afslutning &etc;. Printerdriverne indlæser denne &PPD; lige som en ekstra indstillingsfil. Printerdriveren lærer således om de tilgængelige enhedstilvalg og hvad en skal kalde dem; driveren præsenterer dem også i en &GUI; til brugeren. Gennem denne mekanisme kan du stadig udskrive enheds-uafhængigt &PostScript; sidebeskrivelses-sprog filer og angive enheds-uafhængig afslutningstilvalg oveni, som bliver tilføjet til det program-genererede &PostScript;. &PPD;er var oprindeligt ikke almindeligt brugt på &UNIX; og &Linux; systemer. Forhandlerne der sørgede for disse &PPD;er havde aldrig til hensigt at de skulle bruges på noget som helst andet end understøttede &OS;er, &Microsoft; &Windows; og &MacOS;. Gennem det brillante træk fuldt ud at understøtte og udnytte eksisterende &PPD;-specifikation, giver ∪︀ nu muligheden for at bruge alle egenskaber på moderne printere til brugere af &Linux; og &Linux;-lignende systemer. &tdeprint; gør dens brug endnu mere komfortabel end selv ∪︀-udviklerne nogensinde drømte om. ∪︀ kan bruge originale &Windows; &PPD;er, distribueret af forhandlerne i tilfælde af &PostScript;-printere. Disse koster normalt ikke penge og de kan tages fra en vilkårlig &Windows;-computer med en installeret &PostScript;-driver for den model det drejer sig om, eller fra de floppydiske der kommer med printeren. Der er også adskillige steder på nettet man kan downloade dem fra. Nu ved du hvordan &PostScript;-printere kan bruge &PPD;er. Men hvad med ikke-&PostScript; printere? ∪︀ har gjort et meget smart trick: ved at bruge det samme format den samme datastruktur som &PostScript; Printer Descriptions (&PPD;er) i &PostScript;-verdenen, kan den beskrive de tilgængelige udskriftjob-tilvalg for ikke-&PostScript; printere på samme måde. For sine egne specielle formål har ∪︀ blot tilføjet et par specielle tilvalg (nemlig linjen som definerer filtret der skal bruges til yderligere behandling af &PostScript;-filen). Så udviklerne kunne bruge den samme software-maskine til at analysere Printer Description Filer for tilgængelige tilvalg for alle slags printere. ∪︀-udviklerne kunne naturligcis ikke regne med at ikke-&PostScript; fabrikanterne pludselig ville udvikle &PPD;er. De måtte selv gøre den svære start og skrive dem fra begyndelsen. Mere end 1000 af disse er tilgængelige gennem den kommercielle udgave af ∪︀, der hedder ESP PrintPro. I mellemtiden er der masser af tilgængelige ∪︀-specifikke &PPD;er. Selv nu kommer de ide fleste tilfælde ikke fra dem der laver printerne, men fra udviklere af frit programmel. ∪︀-folkene beviste det og andre fulgte efter: hvor &Linux; og &UNIX; udskrift for et eller to år siden stadig var noget rod, har man nu støtte for et stort område af printere, inkluderende 7-farve inkjets der kan producere fotokvalitet output. Du kan få &PPD;er til at bruge med ∪︀ og ikke-&PostScript; printere fra forskellige steder på nettet: for det første er der lageret på www.linuxprinting.org, som lader dig generere en CUPS-O-Matic-&PPD; online for enhver printer der allerede var understøttet af traditionel &ghostscript; udskrift. Dette hjælper dig til at skifte over til ∪︀ uden stort besvær, hvis du ønsker det. Hvis din printer virkede fint med den traditionelle &ghostscript;-metode, så tag CUPS-O-Matic til at stikke din driver ind i ∪︀-systemet, og du vil have det bedste af begge verdener. dernæst er der ∪︀-&PPD;er for de mere end 120 printermodeller, der drives af den nye universelle stp-driver. stp (stod oprindeligt for Stylus Photo) bliver nu udvikler af gimp-print-projektet; det blev startet af Mike Sweet, den førende ∪︀-udvikler og er nu tilgængelig gennem gimp-print.sourceforge.net. Denne driver udskriver rigtig fotokvalitet på mange moderne inkjet-printere og kan indstilles til at lave 120 ∪︀-&PPD;er sammen med sin egen kompilering. &HP; Laser- og DeskJet, Epson Stylus og Photo Color-modeller så vel som Canon og Lexmark er dækket. for det tredje er der en kommerciel udvidelse til ∪︀ fra selve ∪︀-udviklerne: den hedder ESP PrintPro og den kommer med mere end 2.300 printerdrivere. Der er endog forbedrede imagetoraster og pstoraster filtre inkluderede. ∪︀ gør det nemt for fabrikanterne at begynde at understøtte &Linux; og &UNIX; udskrift for deres modeller med en temmelig lav omkostning. De modulære omgivelser som ∪︀ har gør det let at stikke ethvert filter (=driver) ind med minimal indsats og at få adgang til og bruge hele udskriftsmiljøet som ∪︀ laver. Læs mere om de spændende ∪︀-egenskaber i den tilgængelige ∪︀-dokumentation på http://www.cups.org/documentation.html og http://www.danka.de/printpro/faq.html. Der er også et universelt lager på http://www.linuxprinting.org/ for alle punkter der relaterer til &Linux; og &UNIX; udskrift. Mange udviklere var længe meget utilfredse med gode gamle LPD. En hel det nye projekter blev startet for at forbedre udskrift: LPRng er det bedst kendte eksempel. Andre er PDQ, PPR, PLP, GNUlpr og RLPR. Men ingen af de nye programmer blev set som totalløsningen; de fleste af dem implementerer blot den samme gamle LPD-specifikation med nogle få (eller mange) nye udvidelser, som igen gør dem inkompatible med hinanden. Efter at have set udviklingen af ikke blot én, men forskellige brugbare alternativer til den ærværdige BSD-stil LPD, kaldte Grant Taylor, forfatteren til Linux Printing HOWTO, endelig til oprør LPD må dø! i hans Campagne til at slå 'Line Printer Daemon' ihjel. Sammen med ovenstående var der en indsats på industrisiden af tingene for at besejre de velkendte svagheder i LPD. Det begyndte med ikke-åbne udvidelser til den almindelige gamle LPD, og gik så vidt som &Hewlett-Packard;'s forsøg på at etablere &HP;-JetDirect som en ny standard for en netværksudskriftsprotokol. Resultatet var endnu flere inkompatibiliteter. Til slut var der et initiativ til at definere en ny fælles industri- og IETF-standard som tog form. Printer Working Group eller PWG, en løs forsamling af forhandlere i hardware, software og operativsystemer, skrev kladden til den nye Internet Printing Protocol, &IPP;. &IPP; v1.1 er nu blevet godkendt af IETF (Internet Engineering Task Force) som en foreslået standard, og nyder nu enstemmig støtte i industrien i Europa, USA og Japan. De fleste aktuelle netværksprinter-modeller har nu indbygget &IPP;-støtte oveni den traditionelle LPR/LPD eller JetDirect-udskrift. &IPP; ser ud til at ville løse masser af de problemer netværksadministratorer står over for. I dette område drejer det sig normalt om heterogene netværks-miljøer og mere end halvdelen af tiden går med udskriftsproblemer. Ved at lave et forenet sæt forespørgselsfunktioner for printere og servere der forstår &IPP;, for overførsler af filer og for at sætte job-kontrol-attributters &etc;, vil &IPP; før eller siden komme til at virke henover alle &OS; platforme. Dette vil imidlertid ikke ske på et øjeblik idet mange gammeldags udskriftsenheder stadig vil være i brug i mange år. Derfor er der, i &IPP; en metode til bagudkompatibilitet for alle &IPP;-implementationer. ∪︀ beviser overlevelsesevnen for &IPP;-udskrift i alle miljøer. Den mest slående fordel vil være dens integration i det eksisterende sæt af andre robuste IP-protokoller. Som en udvidelse af den trofaste, robust HTTP-1.1 protokol, for den specielle opgave at håndtere udskriftsfil og relateret data, er det også meget let at stikke andre standarder ind samtidig med at de bliver udviklede og taget i brug: Basal, Digest og Certifikat-godkendelse for brugere der vil have adgang til udskriftsservice. SSL3 og TLS-indkodning for overførsel af data. Bidirektionel kommunikation for klienter med udskriftsenheder, ved brug af HTTP/&IPP; GET og POST mekanismerne. LDAP-mappe serviceintegration for at kunne holde en konsistent database af tilgængelige printere, deres egenskaber og sideomkostninger, &etc;, så vel som brugernes kodeord, ACL'er &etc;. Pull (i modsætningen til den sædvanlige Push model)-udskrift, hvor en server eller printer blot behøver at få at vide hvilken &URL; et dokument har, hvorpå det hentes fra ressourcen på internettet og bliver skrevet ud. Har du nogensinde set en demonstration af ∪︀ formåen på et netværk? Du må hæve været ret imponeret hvis du ikke vidste i forvejen hvad du kunne forvente. Forestil dig som administratoren for et LAN. For testformål installerede du en &kde;/∪︀-felt på dit net fuldt ud, med et dusin printere indstillede og funktionelle: &PostScript;, LaserJets, InkJets og BubbleJets og så videre. Dine &kde;-brugere på den felt er meget glade, de kan udskrive som aldrig før, med brug af hele pibetøjet for hver printer. Det tog dig 2 timer at få dethele til at køre perfekt... og nu vil alle de andre 100 brugere på netværket gerne have det samme. To timer igen for hver felt? Ikke tale om du kan gøre dette før næste år, tror du? Forkert. En enkelt ændring i en indstilling i den originale ∪︀-felt gør den til en server. Installér ∪︀ på fem andre felte, som klienter. På dettidspunkt du vender tilbage til din første klient, vil du finde at brugerne er i gang med at lege med indstillingerne for det dusin printere du havde defineret tidligere på serveren. På en eller anden måde er printerne magisk kommet til syne på alle Print-dialogerne på den fem nye ∪︀-klient felte. Dine brugere udskriver, men ikke så meget som én enkelt driver var blevet installeret på klienterne, ej heller er en printerkø blevet defineret. Så hvordan virker denne magi? Svaret er slet ikke så kompliceret overhovedet. Hvis en ∪︀-server er på dit LAN, udsender den navnene på alle tilgængelige printere til dit LAN, ved brug af UDP-protokollen og port 631. Port 631 er reserveret som en velkendt port af IANA ( Internet Assigning Numbers Authority) til &IPP;-formål. Alle ∪︀-klienter lytter efter ∪︀-serverinfo sendt til deres port 631. Det er på den måde de kender til tilgængelige printere, og det er også på den måde de lærer om stien til printerne. Ved at bruge &IPP;, som i birkeligheden er en smart udvidelse af HTTP v1.1, er ∪︀ i stand til at adressere alle objekter relateret til udskriftssystemet via Universal Resource Locators eller URL'er. Udskriftjobs der skal slettes eller genstartes, printere der skal forespørges eller ændres, admin-opgaver der skal udføres på serveren, med &IPP; og ∪︀, er alt adresserbart med en vis URL. Mange vigtige ting kan gøres gennem netgrænsefladen til ∪︀, tilgængelig for eksempel med &konqueror;. Og endnu mere, klienterne kan basalt set administrere og bruge en vilkårlig printer de ser, lige som hvis den var lokalt installeret. Du kan naturligvis sætte restriktioner på den med adgangskontrollister &etc;, så ikke en vilkårlig klient må bruge en vilkårlig printer som den vil. Klienterne er ovenikøbet i stand til at udskrive uden det passende filter (eller den passende driver) installeret lokalt. Så hvordan virker dette? Hvis en klient ønsker at kende til og vælge printer-specifikke tilvalg, sender den en forespørgsel (kaldet CUPS-get-ppd) til serveren. Serveren fortæller klienten alt om alle printer-specifikke tilvalg, som læst fra serversidens &PPD;. Brugeren på klientsiden kan se tilvalgene og vælge dem der kræves. Han sender så udskriftsfilen, sædvanligvis ufiltreret raw &PostScript;, med printer-tilvalgene tilføjede til printerserveren, ved brug af &IPP; som transportprotokol. Al yderligere behandling, særlig filtreringen til at generere det endelige format for målprinteren, udføres så af serveren. Serveren har de nødvendige programmer (drivere eller filtre) til at gøre dette. På denne måde udskriver klienterne uden at behøve at installere en driver lokalt. En vilkårlig ændring på serveren, såsom at tilføje eller ændre en printer, bliver øjeblikkeligt kendt for klienterne uden yderligere indstilling. En anden avanceret egenskab indbygget i ∪︀ er evnen til at lave belastnings-balancering. Hvis du definerer de samme printerkøer på to eller flere forskellige servere, vil klienterne sende deres jobs til den der først svarer eller er tilgængelig. Dette giver en automatisk belastningsbalancering blandt servers. Hvis du bliver nødt til at tage en server af nettet for vedligeholdelse, vil de andre blot overtage dens opgaver uden at brugerne overhovedet opdager forskellen.