(Vor­be­mer­kung: Ich grei­fe dies­mal gele­gent­lich auf Fach­be­grif­fe zurück und wer­de sie nicht immer erläu­tern, ich bin ja nicht die Wikipedia.)

In einem Anflug von Hei­ter­keit beschloss ich, zur Abwechs­lung neben diver­sen Linux­dis­tri­bu­tio­nen, die ihren Dienst auf den von mir ein­ge­setz­ten Ser­vern, Desk­tops und in einer vir­tu­el­len Maschi­ne ver­rich­ten, auch ein­mal BSD aus der Nähe zu betrachten. 

BS-wat?

Linux ist – lei­der – inzwi­schen all­ge­mein bekannt, wird aber gern mit Unix ver­wech­selt. Tat­säch­lich ist Linux ein Anfang der 90-er Jah­re ent­stan­de­ner, frei­er Nach­bau des pro­prie­tä­ren Lehr­sy­stems Minix, das wie­der­um das damals lizenz- und kosten­pflich­ti­ge Unix, von dem seit sei­nen Anfän­gen 1969 (als „UNICS“) zahl­rei­che Deri­va­te ent­stan­den waren, imi­tier­te. Eines die­ser Deri­va­te, BSD („Ber­ke­ley Soft­ware Dis­tri­bu­ti­on“), wur­de seit 1977 an der Uni­ver­si­tät von Kali­for­ni­en in Ber­ke­ley ent­wickelt, und obwohl dort nach und nach immer mehr Code neu geschrie­ben wur­de, ent­hielt das System noch immer lizenz­pflich­ti­ge Code­tei­le. Als die Ent­wick­lung von Linux begann, gab es daher kein voll­stän­dig frei­es Betriebs­sy­stem, dem Erfolg ver­spre­chen­den GNU-System fehl­te immer noch der Ker­nel. Erst ein Jahr nach Linux 0.0.1, im Jahr 1992, wur­de mit 386BSD die erste BSD-Ver­si­on ver­öf­fent­licht, die die frag­li­chen Code­be­stand­tei­le nicht mehr ent­hielt und somit die Basis für diver­se freie BSD-Ver­sio­nen war und ist. „Frei“ ist in die­sem Fall eigent­lich schon ein Kom­pa­ra­tiv, denn die BSD-Lizenz ist weni­ger restrik­tiv als die GPL.

(Inter­es­sier­ten Lesern emp­feh­le ich die­sen Pod­cast zum The­ma BSD, den in der eng­li­schen Spra­che Kun­di­gen unter ihnen auch die­se Ein­füh­rung in die Unter­schie­de zwi­schen BSD und Linux.)

War­um BSD?

Da Free­BSD (wie auch sei­ne Abkömm­lin­ge) in der Lage ist, die mei­sten Linuxan­wen­dun­gen nativ aus­zu­füh­ren, sind die tech­ni­schen Unter­schie­de zwi­schen dem Ori­gi­nal und der (bil­li­gen) Kopie nicht mehr all­zu groß, und was fehlt, ist dank der gege­be­nen POSIX-Unter­stüt­zung in der Regel meist pro­blem­los por­tier­bar: Selbst grö­ße­re Pake­te wie KDE und Libre­Of­fice funk­tio­nie­ren weit­ge­hend anstands­los unter sämt­li­chen aktu­el­len BSD-Derivaten.

Anders als Linux ist BSD in der Regel ein geschlos­se­nes tech­ni­sches Öko­sy­stem: Das „Kern­sy­stem“ besteht, anders als bei Linux, aus dem Ker­nel und allen ver­füg­ba­ren Anwen­dun­gen, wird also in Gän­ze zen­tral gepflegt und aktua­li­siert, was die War­tung eines BSD-Systems gegen­über einem über die Jah­re gereif­ten Linux mit etli­chen zusätz­li­chen Repo­si­to­rys eini­ger­ma­ßen erleich­tert. Auch des­halb hat BSD den Ruf, siche­rer zu sein als Linux; per­for­man­ter jeden­falls ist es gele­gent­lich.

Anfän­ger raus!

BSD ist im Gegen­satz zu den mei­sten Linux­dis­tri­bu­tio­nen nicht ohne Vor­be­halt für Quer­ein­stei­ger aus der Win­dows-Welt geeig­net. Im Vor­feld mei­nes kur­zen Tests las ich die tref­fen­de Fest­stel­lung, BSD sei für Linux­nut­zer eben­so rät­sel­haft wie Linux für BSD-Nut­zer. Das ist sicher­lich zutref­fend, denn auch ein erfah­re­ner Nut­zer von pro­fes­sio­nel­len Linux­dis­tri­bu­tio­nen, also nicht gera­de von Ubun­tu, ist wahr­schein­lich nur mit dem GNU-User­land, also gcc und nano und der­glei­chen, ver­traut, das in der BSD-Welt kei­ne gro­ße Rol­le spielt, und andersherum.

Zwar gibt es mit PC-BSD inzwi­schen einen beson­ders ein­steig­er­freund­li­chen Abkömm­ling von Free­BSD, der sogar über ein eige­nes gra­fi­sches Instal­la­ti­ons­sy­stem ver­fügt und ent­spre­chen­den Zulauf erhält, da ich aller­dings nach einem Blick in ein deutsch­spra­chi­ges PC-BSD-Por­tal befürch­te, dass PC-BSD zwar idio­ten­si­cher ist, aber mit den ande­ren BSDs nicht mehr viel zu tun hat, habe ich von einem Test Abstand genom­men. (Nach­trag von Novem­ber 2012: Ich möch­te die­sen Absatz revi­die­ren. PC-BSD ist ein voll­wer­ti­ges, vor­kon­fi­gu­rier­tes Free­BSD, das im Kern nicht ver­än­dert wur­de. Inter­es­sen­ten soll­ten es sich ein­mal ansehen.)

Nichts­de­sto­trotz habe ich mir ein­mal die Frei­heit genom­men, die­sen Test aus der Sicht eines eini­ger­ma­ßen erfah­re­nen Win­dows- und Linux­nut­zers durch­zu­füh­ren, denn die mei­sten Leu­te, die die­sen Arti­kel hier lesen wer­den, ver­wen­den wahr­schein­lich eines die­ser bei­den Systeme.

Die Test­um­ge­bung: Virtuell.

Um in der Lage zu sein, bei auf­tre­ten­den Pro­ble­men wäh­rend der Instal­la­ti­on eine Lösung zu fin­den, habe ich die bei­den Pro­ban­den – Free­BSD 9.0‑RELEASE und Dra­gon­Fly BSD 3.0.1 – unter Win­dows 7 in einer vir­tu­el­len Maschi­ne instal­liert. Um die Über­ra­schung schon vor­her zu ver­der­ben: Obwohl Dra­gon­Fly BSD auf Free­BSD 4.x basiert, sind die Unter­schie­de durch­aus etwas grö­ßer als ange­nom­men; der Instal­la­ti­ons­pro­zess jedoch ist weit­ge­hend identisch.

Apro­pos Installation.

Ich hat­te ja schon ange­deu­tet, dass BSD nicht unbe­dingt ein System für Maus­freun­de ist. Die Instal­la­ti­on ist auch eher trist, Debi­an­freun­de soll­ten das kennen:

Bereits wäh­rend der Instal­la­ti­on von BSD emp­fiehlt sich, sofern man eine Instal­la­ti­on per Inter­net vor­zieht, die Grund­kennt­nis der eige­nen Netz­werk­kom­po­nen­ten, denn zwar wer­den DHCP und ver­schie­de­ne Netz­werk­ge­rä­te unter­stützt, wenn jedoch die erkann­ten Vor­ein­stel­lun­gen für den DNS-Ser­ver und das Gate­way nicht stim­men oder die Erken­nung gänz­lich fehl­schlägt, sitzt man auf dem Trockenen.

Die Par­ti­tio­nie­rung hat ähn­li­che Tücken: Wer BSD neben einem bestehen­den System instal­lie­ren will, jedoch von Par­ti­tio­nie­rung kei­ne Ahnung hat, der soll­te die gewünsch­te Par­ti­ti­on bereits vor der Instal­la­ti­on anle­gen. Bun­te Bild­chen wie bei open­SU­SE gibt es hier nicht.

Im wei­te­ren Ver­lauf bemerkt der instal­lie­ren­de Benut­zer, dass auch BSD ein modu­la­res System ist und aus dem Basis­sy­stem, dem Ker­nel und den ports besteht; dazu wei­ter unten mehr.

Die Inbe­trieb­nah­me.

Irgend­wann hat man dann die Instal­la­ti­on hin­ter sich gebracht. Win­dows- und die mei­sten Linux­nut­zer rech­nen nun damit, dass nun die Stan­dard-Arbeits­um­ge­bung erscheint. BSD hat so etwas aber nicht.

free­bsd#

Dra­gon­Fly BSD weist immer­hin dar­auf hin, dass die Ein­ga­be startx die ent­hal­te­ne Arbeits­um­ge­bung – fvwm, das älte­re Linux­nut­zer, eben­so wie den Befehl startx, auch noch ken­nen dürf­ten – auf­ruft, die aller­dings einen eher rusti­ka­len Charme versprüht:

Free­BSD sieht das lei­der etwas anders:

startx: Com­mand not found.

Es ist nun also not­wen­dig, sich damit zu beschäf­ti­gen, wie unter BSD eigent­lich das mit den Pake­ten funk­tio­niert. Die kur­ze Ant­wort lau­tet: Paket­ma­na­ger wie syn­ap­tic gibt es nicht, statt­des­sen gibt’s Ports.

Exkurs: Erst mal Chef sein.

Da es nun an die System­ver­wal­tung geht, soll­te man sich zunächst ein­mal root-Rech­te beschaf­fen. Eine Anmel­dung als root ist mög­lich; sie ist auch unver­meid­lich, denn als nor­ma­ler Benut­zer guckt man zunächst in die Röhre:

$ su
su: Sorry

Klar, nicht jeder Hans­franz darf Admi­ni­stra­tor spie­len. Also tip­pen wir jetzt brav exit ein und mel­den uns als root an.

Unter BSD darf nur su benut­zen, wer in der Grup­pe „wheel“ ist (die­se Bezeich­nung hat histo­ri­sche Grün­de). Um den Benut­zer „testuser“ in die Grup­pe „wheel“ zu set­zen, genügt ein Befehl:

# pw user mod testuser ‑G wheel

Da jetzt unser unpri­vi­le­gier­ter Benut­zer sich bei Bedarf Pri­vi­le­gi­en holen kann, ist die­ser Teil schon mal erledigt.

Was sind Ports?

Wer zwar noch kein BSD, aber schon ein­mal Gen­too Linux oder ähn­li­che Dis­tri­bu­tio­nen aus­pro­biert hat, der soll­te mit die­sem Prin­zip bereits ver­traut sein: Anstel­le ver­schie­de­ner Repo­si­to­rys wird ein loka­ler Ver­zeich­nis­baum gepflegt, der Instal­la­ti­ons­skrip­te (Make­files) für alle ver­füg­ba­ren Anwen­dun­gen beinhal­tet und so zur Über­sicht bei­trägt. Von eini­gen die­ser Anwen­dun­gen wer­den auch Binär­pa­ke­te („packa­ges“) ange­bo­ten, was auf älte­ren Com­pu­tern gele­gent­lich eine Arbeits­er­leich­te­rung dar­stellt, der emp­foh­le­ne Weg ist es jedoch, alle zu instal­lie­ren­den Anwen­dun­gen direkt aus ihrem Quell­code zu über­set­zen, um sie best­mög­lich an das jewei­li­ge System anpas­sen zu können.

BSD wäre nicht BSD, wenn es in die­sem Zusam­men­hang kei­ne Unter­schie­de gäbe: Net­BSD und Dra­gon­Fly BSD etwa ver­wen­den pkgsrc, ein den Ports ähn­li­ches System, das aber im Wesent­li­chen genau so funk­tio­niert. Im Fol­gen­den beschrän­ke ich mich auf die Ports von Free­BSD, die Vor­ge­hens­wei­se für ande­re BSDs ist aber ähn­lich und etwa hin­ter obi­gem Ver­weis aus­führ­lich dokumentiert.

Die größ­te Stär­ke ist die größ­te Schwäche.

Die­ser Auf­bau führt mit sich, dass selbst tri­via­le Auf­ga­ben wie die Ein­rich­tung von open­box als ein­fa­che Arbeits­um­ge­bung nicht per Klick wäh­rend der Instal­la­ti­on erle­digt wer­den kön­nen, son­dern eini­ge Hand­ar­beit nötig ist. Auch, wenn man Binär­pa­ke­te ver­wen­det, sich also das geson­der­te Kom­pi­lie­ren erspart, müs­sen die nöti­gen Ände­run­gen an Kon­fi­gu­ra­ti­ons­da­tei­en manu­ell vor­ge­nom­men werden.

Abhän­gig­kei­ten wer­den aller­dings sowohl für Ports als auch für Pake­te berück­sich­tigt. Dass Open­box etwa eini­ge ande­re Biblio­the­ken vor­aus­setzt, ist kei­ne not­wen­di­ge Kennt­nis, denn BSD über­prüft die in den Make­files – oder den Binär­pa­ke­ten – ver­merk­ten Abhän­gig­kei­ten bei der Installation.

Quell­code oder Binärpaket?

Grund­sätz­lich soll­te man bei schnel­ler Inter­net­ver­bin­dung und schnel­lem Pro­zes­sor immer auf die Ports zurück­grei­fen, da sie beim Kom­pi­lie­ren die größt­mög­li­che Kon­trol­le über das Resul­tat erlau­ben. Binär­pa­ke­te beneh­men sich außer­dem anders als man es viel­leicht gewohnt ist; ein ein­fa­ches Bei­spiel ist die Instal­la­ti­on von Open­box per Binärpaket:

# pkg_add ‑r openbox

Der Para­me­ter r bedeu­tet „remo­te“ und bedeu­tet, dass Free­BSD auf dem Ser­ver nach­sieht, wel­che Ver­si­on des Pakets „open­box“ gera­de aktu­ell ist, und die­se mit allen Abhän­gig­kei­ten her­un­ter­lädt und instal­liert. Will man Open­box aber wie­der deinstal­lie­ren, ist es mit pkg_delete open­box nicht getan:

# pkg_delete openbox
pkg_delete: no such packa­ge ‚open­box‘ installed

Das stimmt, denn man hat eigent­lich gar nicht open­box instal­liert, son­dern openbox‑3.5.0, was ein wenig Auf­merk­sam­keit bei der Instal­la­ti­on erfor­dert: pkg_delete openbox‑3.5.0 funk­tio­niert. (Dass es die instal­lier­ten Abhän­gig­kei­ten nicht eben­falls ent­fernt, ist selbst­ver­ständ­lich, denn dar­um hat man es ja auch nicht gebeten.)

Und so viel kom­pli­zier­ter ist das mit den Ports auch nicht. Die Vor­ge­hens­wei­se besteht nur aus zwei Schrit­ten, dem Fin­den und dem Kompilieren.

Blei­ben wir bei Openbox:

# wher­eis openbox
open­box: /us­r/­ports/x11-wm/o­pen­box

/usr/ports ist unter Free­BSD das Ports-Ver­zeich­nis, in dem sich alle ver­füg­ba­ren Ports, nach Kate­go­rien sor­tiert, befin­den; unter Dra­gon­Fly BSD heißt es /usr/pkgsrc. Die­ses Ver­zeich­nis lässt sich wie jedes ande­re Ver­zeich­nis auch durch­su­chen und benut­zen. (Vom Löschen rate ich ab.)

# cd /us­r/­ports/x11-wm/o­pen­box

In die­sem Ver­zeich­nis lie­gen in der Regel ein Make­file, Paket-Meta­da­ten und der CVS-Ord­ner. Anders als unter Linux üblich ent­fällt der Befehl ./configure, den Port instal­liert man mit einem ein­zi­gen Befehl:

# make install clean

Free­BSD holt nun die Quell­codes von Open­box und allen Abhän­gig­kei­ten vom Ser­ver und kom­pi­liert sie. (Das „clean“ bedeu­tet, dass die tem­po­rä­ren Datei­en nach dem Kom­pi­lie­ren ent­sorgt wer­den.) Sofern ein­zel­ne Ports modu­lar sind, also bestimm­te Funk­tio­nen beim Kom­pi­lie­ren berück­sich­tigt wer­den kön­nen, wird jedes Mal ein Kon­fi­gu­ra­ti­ons­fen­ster angezeigt:

Ich will Grafik!

Nach einer Wei­le sind dann also Open­box und die sepa­rat gewünsch­ten Extras (tint2, obconf und so wei­ter) mit allen Abhän­gig­kei­ten, ob binär oder als Port, instal­liert. Aller­dings gibt es noch kei­ne Kon­fi­gu­ra­ti­ons­da­tei­en. Die kön­nen wir uns aber schnell erstellen:

# mkdir ‑p ~/.config/openbox
# cp /usr/local/etc/xdg/openbox/* ~/.config/openbox/
# chmod u+w ~/.config/openbox/*

Die­se Kon­fi­gu­ra­ti­ons­da­tei­en gel­ten, wie unter Linux und (mei­stens) Win­dows, für jeden Benut­zer sepa­rat, wes­halb sie im Heim­ver­zeich­nis (~) lie­gen müs­sen. Da wir sie nun haben, kön­nen wir auch gleich ein paar grund­le­gen­de Ein­stel­lun­gen tref­fen, zum Bei­spiel auto­ma­tisch ein Panel star­ten, denn Open­box ohne ein Panel ist irgend­wie lang­wei­lig. Dafür ist die Datei ~/.config/openbox/autostart.sh zu ändern, die alle Befeh­le beinhal­tet, die beim Start von Open­box aus­ge­führt wer­den sol­len. Um etwa tint2 zu ver­wen­den, das dafür natür­lich instal­liert sein muss, genügt es, den Befehl tint2 & hinzuzufügen.

Aber wie lässt sich Open­box nun star­ten? Tja, Free­BSD besitzt kei­nen Log­in­ma­na­ger wie gdm, kdm oder slim, in dem wir das ein­fach per Klick erle­di­gen könn­ten, es sei denn, wir rich­ten ihn selbst ein.

Aber ohne X‑Server geht nichts. X.org läuft auch unter BSD:

# cd /us­r/­ports/x11/x­org-mini­mal/
# make install clean
# Xorg ‑con­fi­gu­re

Und da wir gera­de dabei sind, instal­lie­ren wir auch gleich einen Log­in­ma­na­ger. Ich mag slim:

# cd /usr/ports/x11/slim
# make install clean

Um SLiM bereits beim Anmel­den zu akti­vie­ren, genügt ein Ein­trag in der Datei /etc/rc.conf. Die­se Datei ist sozu­sa­gen die System­kon­fi­gu­ra­ti­ons­da­tei von BSD, in der System­mo­du­le akti­viert und deak­ti­viert wer­den kön­nen. Die­se Datei lässt sich mit einem belie­bi­gen Text­edi­tor ändern. Free­BSD lie­fert stan­dard­mä­ßig den (sehr merk­wür­di­gen) Edi­tor ee mit, aber das Instal­lie­ren eines belie­bi­gen ande­ren Edi­tors soll­te ja nun kein Pro­blem mehr dar­stel­len. Der Ein­trag lau­tet: slim_enable=„YES“.

Apro­pos: An die­ser Stel­le kön­nen auch HAL und dbus – kennt man als Linux­nut­zer ja – akti­viert wer­den. Da ich ver­mu­te, dass ich Tasta­tur und Maus auch unter X brau­chen könn­te, hole ich das gleich nach:

hald_enable=„YES“
dbus_enable=„YES“

Wie unter Linux kennt der X‑Server die Datei .xini­trc im Heim­ver­zeich­nis, in der jeder Benut­zer sei­ne gewünsch­ten Ein­stel­lun­gen für die Arbeits­um­ge­bung fest­hal­ten kann. Dort kann nun der Befehl exec open­box-ses­si­on ein­ge­tra­gen wer­den, so dass mit dem Start des X‑Servers auch Open­box gestar­tet wird, denn sonst weiß SLiM nicht, was es nach der Ein­ga­be tun soll.

Und jetzt star­ten wir mal neu:

# reboot

Na also:

Das funk­tio­niert so ähn­lich natür­lich auch für ande­re Arbeits­um­ge­bun­gen wie KDE, hier gebe ich aber zu beden­ken, dass geeig­ne­te Gra­fik­trei­ber rat­sam sind.

Alles ist neu?

Noch ein Vor­teil von BSD als ein­heit­li­ches System ist es, dass die Aktua­li­sie­rung des Systems eben­falls zen­tral ver­läuft, da die Ports ein fester Bestand­teil sind. Da es für ein voll­stän­di­ges Systemup­grade jeweils meh­re­re Metho­den gibt, was den Rah­men die­ses Tex­tes wohl spren­gen wür­de, und ich in der kur­zen Test­pha­se kei­ne Gele­gen­heit hat­te, das zu testen, ver­wei­se ich auf die Doku­men­ta­ti­on für die jewei­li­gen BSD-Ver­si­on (wobei die von Dra­gon­Fly BSD, zuge­ge­be­ner­ma­ßen, eini­ger­ma­ßen mau ist). Um aber ein­zel­ne Pro­gram­me zu aktua­li­sie­ren, ist es nicht nötig, das gan­ze System zu aktualisieren.

Eine Aktua­li­sie­rung aller instal­lier­ten Ports und Binär­pa­ke­te führt man unter Free­BSD wie folgt durch:

# port­up­grade ‑af

Dabei wer­den alle instal­lier­ten Pake­te ent­fernt und in der neu­en Ver­si­on ein­ge­rich­tet, das kann also eine Wei­le dau­ern. Möch­te man statt­des­sen nur die Pake­te aktua­li­sie­ren, von denen es eine neue Ver­si­on gibt, so lau­tet der Para­me­ter -aO. BSDs, die auf pkgsrc set­zen, haben meh­re­re Mög­lich­kei­ten, der Funk­ti­on von port­up­grade kommt man mit pkg_rol­ling-replace nahe:

# cd /usr && make pkgsrc-update
# pkg_rol­ling-replace ‑u

Erkennt­nis­se.

Man­chen Lesern, die es bis hier­her geschafft haben, erscheint BSD viel­leicht wie ein Relikt aus alten Zei­ten, bevor es Linux gab. Bedenkt man aber, dass das (schreck­li­che) Mac OS X zu einem beacht­li­chen Teil auf Code aus Free­BSD fußt (und vie­le Free­BSD-Ent­wick­ler mitt­ler­wei­le für Apple arbei­ten), so ist dies viel­leicht ein Anlass, den Trend zu Linux ein­mal zu hin­ter­fra­gen. Der Linux-Ker­nel ist seit 1991 auf­grund zahl­rei­cher Por­tie­run­gen immer wei­ter gewach­sen und wächst inzwi­schen gemäß eige­ner Aus­sa­gen auch Linus Tor­valds gele­gent­lich über den Kopf. BSD ist ein soli­des System, das nicht ver­sucht, auf alles eine Ant­wort zu haben, und sei­nen Anwen­dern nur den roten Tep­pich aus­rollt, wenn sie sich das ehr­lich erar­bei­tet haben – die­se Ein­stiegs­hür­de jedoch sorgt zwar dafür, dass BSD im Gegen­satz zu vie­len Linux­dis­tri­bu­tio­nen nicht jeden ent­täusch­ten Win­dows­nut­zer mit bun­ten Bil­dern anlockt und somit eher über­schau­ba­re Nut­zer­zah­len vor­zu­wei­sen hat, dass aber die­je­ni­gen, die BSD ein­mal ein­ge­rich­tet haben, sich mit ihrem System so gut aus­ken­nen wie nur weni­ge Linux-Neu­ein­stei­ger. (Damit wäre dann neben­bei auch wider­legt, dass man angeb­lich Linux brau­che, um sei­nen Com­pu­ter zu ver­ste­hen – vie­le Linux­nut­zer sind näm­lich „dank“ Ubun­tu, open­SU­SE und ähn­lich ein­stiegs­freund­li­chen Dis­tri­bu­tio­nen eini­ger­ma­ßen stroh­doof.) Zur­zeit ist übri­gens pkgng in der Beta­pha­se, das den Umgang mit Binär­pa­ke­ten ver­ein­fa­chen soll und dem von Debi­an bekann­ten apt ähnelt. Es lohnt sich, die Ent­wick­lung im Auge zu behalten.

Nichts­de­sto­trotz ist man zumin­dest bei Free­BSD ohne ein gutes Hand­buch – oder einen zwei­ten Com­pu­ter mit lauf­fä­hi­gem Inter­net­brow­ser – eini­ger­ma­ßen auf­ge­schmis­sen. „Mal eben BSD testen“ klingt leich­ter, als es tat­säch­lich ist: Es ist viel Lern­auf­wand nötig, bis ein jung­fräu­li­ches Free­BSD für die täg­li­che Arbeit taug­lich ein­ge­rich­tet wor­den ist. Viel­leicht lohnt sich der Auf­wand nicht in jedem Fall, aber man hat am Ende doch das Gefühl, alles, was bis zu die­sem Punkt getan wer­den muss­te, zumin­dest ver­stan­den zu haben – und das ist ja auch nicht schlecht.