Zur Feier des 20-jährigen Macintosh-Jubiläums diese Woche plaudert Adam mit Bruce Horn, der den Finder geschrieben hat. Und zwar über seine Tätigkeit bei Apple, wo überall er seitdem beschäftigt war und an welchen Macintosh-Projekten er zurzeit arbeitet. Außerdem stößt Brady Johnson zu uns mit einem Bericht darüber, ob das neue CAN-SPAM Gesetz in den USA irgendeine Auswirkung auf unser zunehmendes Spam-Volumen haben wird. In den Neuigkeiten geht es um die Auslieferung von Dantz Retrospect 6 sowie die von OrangeWare vorgestellten Mac OS X Treiber für WiFi-Karten inklusive solcher nach dem 802.11a Standard, die Atheros Chip-Sets verwenden.
Themen:
Copyright 2004 TidBITS: Reuse governed by Creative Commons
license
<http://www.tidbits.com/terms/>
Contact: <editors@tidbits.com>
[Übersetzung: Roland Müller <mail@duesenschrieb.de>]
Mac-Anwender auf der "A"-Liste -- Mit der Vorstellung von Apples AirPort Extreme (IEEE 802.11g) WiFi-Netzwerk im Januar 2003 hatte Steve Jobs ein älteres, ähnlich schnelles Netz für tot erklärt. Er sagte, dass 802.11a mit seinen von AirPort (802.11b) und AirPort extreme unterschiedlichen Frequenzen auf dem Müll der Geschichte landet – durch seine fehlende Abwärtskompatibilität dem Untergang geweiht. Ein Jahr später erfreut sich 802.11a dank zusätzlich freigegebener Frequenzen und der großen Zahl von Apple-fremden WiFi-Karten, die 802.11a, b und g unterstützen, immer noch bester Gesundheit. 802.11a leidet nicht so sehr unter Interferenzen aus dem Rundfunkband wie b und g. Mac-User sind jedoch bislang bei dieser Revolution außen vor geblieben.
OrangeWare bietet jetzt Software-Treiber an, die sie für 3Com zur Unterstützung der Atheros Chipsets entwickelt haben, ein Konkurrent von Apples Drahtlos-Zulieferer Broadcom. Obwohl die Treiber von OrangeWare unter Mac OS X WiFi-Karten von Atheros ansteuern, können Mac-Anwender weiterhin 802.11g-Karten von Linksys, Buffalo, Belkin und anderen verwenden. Diese greifen auf die Broadcom-Chips zu, die seit dem AirPort 3.1 Update in der AirPort Extreme Baureihe zum Einsatz kommen. Mit den 15 US$ teuren OrangeWare Testtreibern kann man 802.11a oder a/g PC- oder PCI-Karten von NetGear, Fujitsu, D-Link und anderen verwenden. OrangeWare hat eine kurze Liste der Karten angelegt, die getestet wurden. [GF]
<http://www.orangeware.com/endusers/wirelessformac.htm>
von Glenn Fleishman <glenn@tidbits.com>
[Übersetzung: Roland Müller <mail@duesenschrieb.de>]
Die ehrwürdige Retrospect Backup-Software von Dantz Development ist mit der heute zum Herunterladen freigegebenen Version voll Panther-kompatibel. Zwar sollte Retrospect 5.1 ebenso wie der Retrospect Client einwandfrei unter Panther funktionieren, trotzdem hat Dantz einen Waschzettel voller Situationen aufgelistet, die man vermeiden sollte, wenn man nicht Probleme mit dem Betrieb des Programms nach Systemneustarts und bei Systemfehlern riskieren will. (Wir hängen alle an Jaguar auf unseren Backup-Servern.)
<http://www.dantz.com/>
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28093>
Man könnte Retrospect 6.0 für eine Zwischenversion mit einem saftigen Upgrade-Preis halten – es sei denn, man hat eines von vier ganz speziellen Bedürfnissen: Backups, die größer sind als ein Terabyte; Backups auf ein Xserve RAID; die Verwendung von auf Band gespeicherten Backups via SCSI oder Fiber-Channel; oder das Zusammenfassen von mehreren Festplatten in einem einzigen Backup – etwas, womit sich Adam selbst mit seiner derzeitigen Backup Strategie herumschlägt. Zudem weist das Unternehmen auf Geschwindigkeitssteigerungen hin.
<http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=28121>
<http://db.tidbits.com/getbits.acgi?tbart=07295>
Das Programm kann ab sofort heruntergeladen werden; die verpackte Version ist ab Mitte Februar erhältlich. Das Preisschema ist kompliziert, wie üblich mit der Vielzahl von Versionen, die Dantz für kleine, mittlere und große Netzwerke anbietet.
Retrospect Desktop kann für einen lokalen Mac und zwei mit ihm vernetzte Windows-, Mac OS- oder Red Hat Linux-Systeme per mitgelieferter Retrospect Client-Software das Backup anlegen. Es kann jedoch nicht Backups von Rechnern ziehen, die unter Mac OS X Server laufen (lokal oder per Retrospect Client). Und es bietet nicht die Möglichkeit, auf große Bandlaufwerke, Xserve RAID oder im Terabyte-Bereich Backups anzulegen. Der Listenpreis beträgt 130 US$, das Upgrade von Vorversionen kostet 60 US$.
Retrospect Workgroup und Retrospect Server bieten Clients-Unterstützung für jeweils 20 und 100 Geräte sowie alle "großen" Backup-Optionen. Jedoch nur Retrospect Server kann Backups von Mac OS X Server-Systemen ziehen. Workgroup kostet 500 US$, das Upgrade 200 US$; Server kostet 800 US$, das Upgrade 350 US$.
Alle Versionen beinhalten Retrospect 5.1 für den Fall, dass man Retrospect auf einem Mac unter Mac OS 9 laufen lassen will; Retrospect 6.0 kann Backups von älteren Macs anlegen, auf denen Retrospect Client läuft. Ebenso enthalten ist eine bootfähige Notfall-CD, allerdings nur in der verpackten Version und nicht im Download.
von Adam C. Engst <ace@tidbits.com>
[Übersetzung: Hartmut Greiser <hgreiser@linarte.com>]
Zwanzig Jahre Macintosh. Während der diesjährigen Macworld Expo führte Steve Jobs eine Version der berühmten "1984" Werbung vor, mit der der Mac gestartet wurde und Alan Oppenheimer, zu einem großen Teil für AppleTalk verantwortlich, lieferte einen wunderbaren Beitrag zur Geschichte "Mac und Netzwerke". Ich fand es hochinteressant, dass viele der Mitarbeiter von damals auch nach zwanzig Jahren nicht nur immer noch dabei sind, sondern dass sie immer noch großartige Arbeit leisten. Die Geschichte des Mac wird nicht nur immer weiter geschrieben, zum Teil schreiben immer noch die gleichen Leute die Fortsetzungen.
<http://www.opendoor.com/nethistory/>
Ich möchte Ihnen ein anderes Mitglied des Original-Macintosh-Teams vorstellen: Bruce Horn, der für eine ganze Anzahl von Schlüsselaspekten des Mac zuständig war und der auch weiterhin innovativen Code geschrieben hat. Bei Apple war Bruce für das Design und die Einführung des Finders (ach, das!) verantwortlich, für den type/creator Metadata-Mechanismus der Dateien und Programme und für den Resource Manager (der sich um Lesen und Schreiben der Resource Fork bei den Dateien kümmerte; ein Hinweis in Apples technischer Dokumentation vermerkt an einer Stelle "Der Resource Manager ist keine Datenbank!"). Auch der Dialog-Manager und der "multi-type" Aspekt der Zwischenablage sind Bruces Einfallsreichtum zu verdanken.
Zum Gedenken an das 20. Macintosh-Jubiläum wollte ich mich Bruce also nicht nur über seine bisherige Arbeit bei Apple unterhalten, sondern auch über seine aktuellen Pläne, da seine Arbeit heute in vielerlei Hinsicht zum einen eine Rückkehr zu seinen Wurzeln ist und zum anderen einen Blick darauf ermöglicht, was der Macintosh in der Zukunft möglicherweise leisten kann.
Bruce: Eine Reihe unterschiedlicher Ziele haben mir diese Lösungen aufgezwungen. Nachdem ich meine Programmiererfahrungen hauptsächlich in der Smalltalk Umgebung von Xerox gewonnen hatte, wo man jede beliebige Änderung auf der Runtime-Ebene machen konnte (also während das Programm selbst lief), suchte ich jetzt nach einer dynamischen Methode, Objekte im System so zu handhaben, dass Daten wie übersetzbare Strings, Menüs, Images usw. auch von Nicht-Programmierern geändert werden konnten, ohne den Quellcode erneut zu kompilieren. Außerdem stellte ich fest, dass die Art Daten, die ich mit dem Finder verwalten wollte - Icons für Programme und Dokumente und die Bindungen an diese Icons - den gleichen Mechanismus benötigten, und ich war auf eine einheitliche Lösung aus. Die Datenbank des Finder-Desktops war also der Treiber für viele Ergebnisse, die der Resource Manager schließlich bot.
Die Metadaten der Dateien wurden ebenso von den Ansprüchen des Finders getrieben. Ich hatte schon früh festgestellt, dass ich einen einfachen Weg suchen musste, ein Dokument mit einem Programm zu verlinken, um es per Doppelklick standardmäßig von diesem öffnen zu lassen. Da verschiedenartige Programme in der Lage sind, unterschiedliche Dateitypen zu öffnen, konnte ich mich nicht mit einem einzigen Mapping von einem Typ zu einer Applikation begnügen, mit dem alle Dateien dieses Typs bearbeitet würden. Daher rührt die Trennung zwischen Type-Code (dem eigentlichen Dateiformat) und dem Creator-Code (der Standard-Applikation, die leicht geändert werden konnte). Durch das Abspeichern unabhängigen Type und Creator Codes im Dateisystem konnten wir vermeiden, den Dateinamen mit Type-Informationen zu überschwemmen, nach meiner Meinung ein großer Vorteil gegenüber anderen Lösungen.
Die Desktop Datenbank diente als Cache für die Bindungen zwischen Types und Creators sowie die Icons, die sie repräsentieren und die als Ressourcen abgelegt wurden. Da Application Bundles - Gruppen von verbundenen Ressourcen mit Informationen über Dokumenttyp und über die Icons - in Application Resource Forks abgelegt waren, bedeutete das Installieren eines Programms ein einfaches Kopieren der entsprechenden Programm-Resources auf den Desktop. Die redundante Information - Type und Creator Informationen im Verzeichnis und Bundleinformationen in den Resourceforks der Applikation - ermöglichten es, die Datenbank jederzeit verlustfrei wiederherzustellen. Wie sich herausstellte, ziemlich wichtig damals.
Resources waren natürlich im Dauergebrauch, um Nicht-Programmdaten (wie Menüs und Text-Strings) auszusortieren, die in andere Sprachen übersetzt werden können. Mit Hilfe von ResEdit konnten Sprachexperten schnell Programmversionen erstellen, ohne Zugang zum Quellcode zu benötigen.
Nachdem ich Andy Hertzfeld von der Nützlichkeit des Resource Managers überzeugen konnte, schrieb er den größten Teil der Toolbox neu, um diesen Vorteil zu nutzen, der sich darin zeigte, dass ziemlich viel Platz im ROM eingespart wurde und dass wir ganz allgemein Anwendungen auf einfache Art übersetzen können.
Bruce: Ja und nein. Der ursprüngliche Gedanke dahinter war, dass Mac OS X mit den Windows-Konventionen für Dateinamen kompatibel sein sollte, dafür war es nötig, die Verfügbarkeit von Datei-Erweiterungen zu erzwingen. Da es so viele Möglichkeiten gibt, wo eine Datei den Schutzraum des Mac OS X verlässt und sich der bösen Welt aussetzt, in der Erweiterungen verlangt werden, schien es unmöglich, Namen aus der Mac Konvention (mit Types und Creators) in die Konvention der Außenwelt zu übersetzen. Was die Kompatibilität betrifft - das hat funktioniert.
Mit der Zeit wurde es aber offensichtlich, dass es schwierig war, hier keine Fehler zu machen und der Originalmechanismus mit redundanten Type-Informationen und der Möglichkeit für Anwender, die Dateien nach Belieben zu benennen, war flexibler und weniger fehleranfällig. Es stellte sich heraus, dass Mac OS X immer noch einen Creator-Mechanismus benötigte, mit dessen Hilfe individuelle Dokumente durch spezifische Anwendungen geöffnet werden konnten, deshalb wurde diese Information in der Resource Fork der Datei abgelegt (ausgerechnet hier, obwohl Apple von der Benutzung der Resource Fork abrät), anstatt einfach in einem Creator Code.
Die Sache mit der Dateierweiterung hat also funktioniert, wenn auch nicht ganz so elegant wie im Original.
Bruce: Das wäre schön gewesen. Ich hatte ein paar Ideen, aber als es darum ging, alles in die 64K ROM zu pfriemeln, konnten wir nur den Resource Manager unterbekommen. Alle hatten sich redlich bemüht, möglichst schlanken Code zu schreiben. Der Resource Manager hatte 3K und der Finder 46K - ziemlich erstaunlich, wenn man an die heutigen Programmumfänge denkt.
Bruce: Ich habe Apple im Frühling 1984 verlassen, nachdem ich eine "endgültige" Finderversion fertiggestellt hatte. Eigentlich suchte ich nur nach einer neuen Aufgabe: nach mehreren Jahren intensiver Arbeit für den Mac hatte ich eine Pause verdient. Die Arbeit im Mac-Team mit den absolut tollsten Leuten war eine der wichtigsten Erfahrungen in meinem Leben und ich denke immer noch sehr gern an diese Zeiten zurück.
Bruce: Nach Apple ging ich zu Adobe, wo ich mich mit verschiedenen kleineren Projekten beschäftigt habe, u.a. mit einem LaserWriter Spooler. Dort habe ich ein paar Diplomanden von Carnegie Mellon kennen gelernt und - um hier mal abzukürzen - die haben mich davon überzeugt, dass ich mich auch an der CMU für ein Diplom einschreiben sollte (Chuck Geschke, einer der Gründer von Adobe war übrigens auch ein CMU Ph.D.). Diese Schule war eine großartige Erfahrung. Ich war eine Zeit lang als Forschungsassistent an der Universität von Oslo, Norwegen, habe ab und zu Beratertätigkeit für Apple gemacht und konnte als Student mit einigen faszinierenden Start-Ups zusammen arbeiten. Meine Diplomarbeit beschäftigte sich mit dem Design einer bedingungsbasierten, objektorientierten Programmiersprache mit Namen Siri, die ich gern eines Tages mal wieder einsetzen würde. Nach dem Diplom bin ich als Berater zurück zu Apple gegangen und zwar in die Gruppe "Advanced Technology". Dort habe ich u.a. mit Tom Bonura und Jim Miller am Projekt LiveDoc gearbeitet. LiveDoc war ein Experiment für das automatische Strukturieren von Dokumenten, um zu erreichen, dass die verschiedenen Bestimmungsinstrumente erkennen können, "555-1212" ist eine Telefonnummer und bei "124 Main Street" handelt es sich um eine Adresse und um entsprechende kontextbezogenen Aktionen für diese Items anbieten zu können. Das hat viel Spaß gemacht und ich wünschte, es gäbe LiveDoc heute für Mac OS X. Sbook von Somson Garfinkel bietet einige dieser Merkmale als PIM-Applikation.
Kein einziges dieser Projekte beschäftigte sich aber mit dem Problem, das ich lösen wollte, nämlich: Wie kann ich einen Informationsbrowser entwerfen, der mit jeder Art Daten zurecht kommt, von E-Mail-Nachrichten über Images und Musikdateien bis hin zu Dokumenten und der einen allgemein gültigen Mechanismus zum Organisieren, Durchsuchen und zum Ansehen dieser Informationen bietet?
Deshalb begann ich 1997 mit dem iFile-Projekt, mit dem ich mich ein paar Jahre beschäftigt habe, bis ich es auf kleine Flamme gestellt habe, um meine andere Firma, Marketocracy, zu starten, bei der ich jetzt seit Mitte 1999 bin. Marketocracy ist eine Fonds-Gesellschaft, die ich mit meinem Geschäftspartner Kann Kam zusammen gegründet habe. Unser Team hat eine Website mit WebObjects und einer FrontBase-Datenbank am Macintosh aufgebaut, mit deren Hilfe über 50.000 Anwender weltweit Aktien in Echtzeit (aber mit Spielgeld) kaufen und verkaufen können, um so ein Modell-Aktienportfolio aufzubauen. Wir stellen eine große Auswahl an Hilfsmitteln zur Verfügung, um unseren Kunden zu helfen, bessere Portfolio-Manager zu werden. Durch die Beobachtung ihrer Leistungsfähigkeit im Laufe der Zeit und dadurch, dass wir ein Ranking für sie machen, finden wir die Besten weltweit, um unsere Fonds managen zu lassen. Unser Master 100 Fonds, der sich auf die Top-100 unserer Gemeinschaft gründet, läuft jetzt seit zwei Jahren und er hat sogar uns mit seiner eindrucksvollen Performance und seinem niedrigen Risiko überrascht. Seit seinem Start hat er um 39 Prozent zugelegt und das zu einer Zeit, als der Markt ziemlich am Boden lag und mit einer Betaversion 0.47 - halb so risikoreich wie der Markt!
<http://www.marketocracy.com/>
Bruce: Vor kurzem habe ich bei iFile (im Moment ist das nicht mehr als ein Arbeitstitel) die Arbeit dort wieder aufgenommen, wo ich 1999 stehen geblieben war. iFile ist - wie der Finder - ein einheitlicher Desktop-Informationsbrowser, der aber ganz bedeutende architektonische Verbesserungen enthält. Er basiert auf einer objekt-orientierten Datenbank, die ich entworfen habe, mit der man auf allgemeine Weise alle möglichen Objekttypen verlinken und organisieren kann. Eine Organisationsgrundeinheit nennt man "Sammlung", die sich von einem Ordner dadurch unterscheidet, dass ein Objekt in vielen "Sammlungen" enthalten sein kann, aber nur in einem einzigen Ordner. "Sammlungen" sind wie iPhoto-Alben oder iTunes-Playlists, sie können aber beliebige Inhalte haben: Textdateien, Bilder, Email, Musikdateien, Adressen, Notizen, Termine usw. Das klingt zwar etwas nach einer Kombination aus BFS (BeOS Filing System) und dem BeOS-Tracker, ist aber viel allgemeiner und kann mit den entsprechenden Treibern auf jedem Dateisystem genutzt werden.
Was als erste Applikation für die iFile-Technologie auf der Hand lag, war ein Fotoorganisations-Instrument, ein Gebiet, auf dem iPhoto sich schon ganz gut etabliert hat. Trotzdem bietet iFile mehr Organisationsmöglichkeiten für die Metadaten der Bilder (zurzeit hat es 46 verschiedene Metadaten für jedes Bild im Griff) und es dürfte sich für größere Sammlungen besser anpassen lassen als iPhoto. iFile ist aber nicht einfach ein Fotomanager: es ist ein Informationsbrowser für alle möglichen Zwecke, der sich auf verschiedene Weise einsetzen lässt. Er kann sehr einfach verschiedene Informationsquellen integrieren, unter anderem z.B. PIM, E-Mail und Musik. Ich denke, dass die iFileversion, die ich veröffentlichen werde, auf diesen Feldern noch viel mehr Möglichkeiten bieten wird.
Bruce: Möglicherweise. Es ist nur viel ehrgeiziger als das, was ich ursprünglich im Sinn hatte. Wenn ich es schlussendlich schaffe, ihn auf ein Niveau zurück zu nehmen, sodass neue Anwender ihn schnell verstehen, dann könnte es eine ganz schöne Alternative zum Finder werden.
Bruce: 1999 habe ich es zuerst der Finder-Gruppe gezeigt, dann Avie Tevanian und schließlich Steve Jobs. Vermutlich hatte Apple sich damals voll darauf konzentriert, so schnell wie möglich mit Mac OS X fertig zu werden, ein alternativer Finder stand auf deren Liste nicht besonders weit oben. Ich nehme an, dass man schon neugierig war, sich aber schon in einer anderen Richtung festgelegt hatte und keine Möglichkeit mehr sah, alles zu stoppen, um die Vorteile der iFile-Technologie ausnutzen zu können. Vor dem Hintergrund des Werdeganges von Mac OS X muss man sagen, dass die Entscheidung richtig war.
Bruce: Für die aktuelle Version von iFile muss der Anwender die Ordner angeben, die iFile "im Auge behalten" soll; das geschieht durch das Ziehen der Ordner in das Fenster des iFile Workspace. Danach verfolgt iFile jegliche Änderungen der Ordnerinhalte und aktualisiert bei Bedarf automatisch die Datenbank. Ein Beispiel: der Anwendern kann einen Bilderordner herein ziehen und durch alle Bilder blättern, Sammlungen erstellen usw. ohne irgendeine Datei tatsächlich zu kopieren oder Daten zu bewegen. iFile respektiert deine Verzeichnisstrukturen und ändert niemals etwas direkt, im Gegensatz zu iPhoto, das die Bilder in seine eigene Verzeichnishierarchie kopiert.
Die endgültige Version von iFile wird vom Anwender nicht verlangen, bestimmte Ordner scannen zu lassen. Statt dessen wird iFile am Anfang eine Sicht auf das Home-Verzeichnis des Anwenders anbieten und alle Dateien und Ordner im Hintergrund automatisch scannen.
Bruce: Ja, kann es. Sammlungen sind eine Möglichkeit, Dateien nach ihren Eigenschaften automatisch zu kategorisieren. Da iFile die Metadaten der Dateien in der Objektdatenbank vorhält, sind sehr schnelle Such- und Sortiervorgänge möglich, die zu den entsprechenden Dateien führen. Darüber hinaus sind Sammlungen "live": speziell wenn Dateien auf der Platte auftauchen, die zu den Spezifikationen einer Sammlung passen, dann werden diese Dateien automatisch zu dieser Sammlung hinzugefügt, unabhängig davon, ob diese Sammlung gerade angesehen wird. Man kann sich alle möglichen interessanten AppleScript Skripts vorstellen, die auf Grund dieser Events ausgelöst werden könnten.
Sammlungen erfassen Dateien auch auf Grund ihres Inhaltes. Anders als bei Google, wo nach einzelnen Wörtern gesucht wird, suchen Sammlungen nach Schlüsselbegriffen: nach einem Wort oder einem Satz. Dateien, die irgendeinen der Schlüsselbegriffe enthalten, die in einer Sammlung spezifiziert wurden, werden automatisch in diese Sammlung aufgenommen. Sammlungen machen also nichts anderes, als einen neuen Weg anzubieten, die ohnehin vorhandenen Informationen aufzuteilen und auseinander zu nehmen, ohne gezwungen zu sein, Daten zu importieren oder sich einer völlig neuen Organisation zu unterwerfen.
Bruce: Prima Idee, die wurde auch schon seit einiger Zeit diskutiert. Apple hat sogar schon an einem Projekt gearbeitet, das auf dieser Idee beruhte. "Piles" waren automatische, inhaltsbezogene Gruppierungen von Dateien:
<http://www.theregister.co.uk/ content/ archive/ 30360.html>
Eine der Herausforderungen ist hier, eine angemessene Ähnlichkeitsfunktion zu bestimmen: wie entscheidet man, was eine Sammlung a priori sein soll, um die Probleme von Hunderten von Sammlungen zu vermeiden, jede mit einer Datei oder - im Gegensatz dazu - eine kleine Anzahl von Sammlungen mit Tausenden von Dateien? Daran muss noch gearbeitet werden.
Bruce: Absolut. Eine Sammlung ist eigentlich nichts anderes als ein smarter Ordner mit einer Abfrage-Spezifikation. Es ist z.B. einfach, eine Sammlung mit allen Bildern zu erstellen, die mit einem bestimmten Kamera-Modell gemacht wurden, indem man spezifiziert: <Modell> ist "2500", <Marke> ist "Nikon", da diese Daten in den EXIF-Metadaten jedes Bildes enthalten sind. In ähnlicher Weise sind Metadaten wie die ID3Tags für Musik, Bilddaten wie Auflösung, Breite und Höhe, Dateidaten wie Dateinamen, Erstellungs-, Änderungsdaten und Größen usw. allesamt in der Datenbank gespeichert, um als Objekte abgerufen und dann organisiert zu werden. Für Sammlungen gibt es also 3 Gruppierungsmechanismen: von Hand per Drag und Drop, automatisch über die Spezifikation der Metadatenabfrage und automatisch über passende Schlüsselbegriffe.
Bruce: Du hast recht: der Teufel steckt tatsächlich in den Details. Ich arbeite zur Zeit daran, all diese Information in einer angemessen intuitiven Art zu präsentieren und ich denke, dass ich mich der Lösung nähere, aber da gibt es noch eine Menge Arbeit.
iFile fängt mit der traditionellen, iconbasierten Datei- und Containerorganisation an (Container sind entweder Ordner oder Sammlungen), geht dann aber darüber hinaus mit einer Anzahl verschiedener Sichten und Layouts. Viele der Layouts gewähren eine Vorschau auf die Dateiinhalte und bei Textdateien erstellt iFile aus dem Text heraus automatisch Hyperlinks zu verwandten Sammlungen.
Es ist schwer zu erklären, aber der erste Gebrauch von iFile wird dir beweisen, dass einige der Ansichten dir die Möglichkeit geben, deine Daten aus verschiedenen Perspektiven zu studieren. Je mehr Hinweise du iFile darüber gibst, wie du deine Daten sichten möchtest - über die Definition der Sammlungen - desto besser kann es dir beim Querindizieren helfen und Zusammenhänge aufzeigen, die bisher unklar waren
Bruce: Ich gebe zu, dass iFile für neue Anwender etwas einschüchternd sein kann: iFile beherrscht eine Menge verschiedener Dinge und es sollte mehr unmittelbare Genugtuung während des Gebrauchs zu spüren sein. Das Erstellen von Sammlungen ist schon mal ein guter Anfang, und ich denke, dass die Kraft der Technologie offensichtlicher wird, wenn man nützliche Sammlungen nicht nur mit Bildern, sondern auch mit Dokumenten und Emails erstellt. Ich plane, einige dieser Punkte in den nächsten paar Monaten einzuführen, bleibt also dran! Interessenten dieser Technologie, die informiert werden möchten, sobald eine öffentliche Version verfügbar ist, können sich auf der u.a. Website eintragen, ich werden sie dann auf dem Laufenden halten. In einer der nächsten TidBITS-Ausgaben kann ich gern näher über die Freigabeversion sprechen.
<http://www.ingenuitysoftware.com/>
von Brady Johnson <brj@fremontlaw.com>
[Übersetzung: Alexander Lorani <alexander.lorani@web.de>]
Ein echtes Déjà vu. Ich kann mich erinnern, dass ich eine ähnliche Einleitung bereits schon einmal für einen TidBITS Artikel geschrieben habe; jedes Mal musste ich die betrüblichen Spam-Statistiken nach oben korrigieren [Spam = unerwünschte Werbe E-Mail - ALO]. Ich schaue mir zuerst immer Seiten wie Brightmail an, die den Spamverkehr verfolgen, um zu sehen, wie gut die Eindämmung mittlerweile funktioniert. Leider waren die Nachrichten noch niemals gut. Sogar der Amerikanische Kongress merkte dies in seinem Anfangssatz der CAN-SPAM Gesetzesvorlage an und verfügte folgenden traurigen Kommentar in das Gesetz: "Ungewünschter kommerzieller elektronischer Postverkehr macht heute über die Hälfte des gesamten E-Mail Verkehrs aus, im Jahre 2001 waren es noch geschätzte sieben Prozent. Und die Menge steigt stetig an."
<http://db.tidbits.com/getbits.acgi?tbser=1169>
Wenn man Brightmail glaubt, steigt die Spam-Menge sogar schneller als das Thermometer an einem heißen Sommertag. 2002 waren es schon 40 Prozent aller E-Mails. Wenn also die 7 Prozent der Kongress-Statistik korrekt ist, gab es zwischen 2001 und 2002 einen Zuwachs von fast 600 Prozent. Ende 2003 lag die Zahl bei 58 Prozent und wenn wir den Trend so anhält, werden Ende 2004 65 Prozent unser E-Mail Spam sein.
<http://www.brightmail.com/spamstats.html>
Um sich gegen diese Flut zu stemmen, hat der Kongress "das Gesetz zur Regelung des Angriffs von nicht-erwünschter Pornografie und Marketing", kurz CAN-SPAM, auf den Weg gebracht. Am 16. Dezember 2003 unterzeichnete Präsident Bush die Vorlage zum Gesetz, und es trat am 1.1. 2004 in Kraft.
<http://www.spamlaws.com/federal/108s877.html>
CAN-SPAM löste viele Diskussion und Debatten aus, wobei der größte Teil der vernetzten Gesellschaft das Gesetz als Pakt mit dem Teufel verurteilte und die Marketinggemeinschaft es als wichtigen Schritt vorwärts einstufte, um Spam zu bekämpfen.
Wenn man die verschiedenen Kommentare zu CAN-SPAM liest, wird einem schnell klar, dass der Hauptdissens der Kontrahenten die eigentliche Definition von "Spam" ist. Für den normalen Internetbenutzer bedeutet Spam jegliche unerwünschte E-Mail Massensendung aus beliebiger Quelle. CAN-SPAM spricht nur eine kleine Teilmenge dieser Definition an und legitimiert den Rest. Die Vertreter von Marketingorganisationen und andere Parteien sind dagegen, dass E-Mail Massensendungen, die nicht irreführend oder betrügerisch sind, als freie kommerzielle Redefreiheit gelten und nicht schlimmer sind als normale Werbebriefpost. Also, so schlussfolgern sie, sind diese Arten von E-Mailwerbung nicht in der Definition von Spam enthalten. Für diese Anwendergruppe ist CAN-SPAM ein Schritt vorwärts.
Was ist denn nun eigentlich "Spam"? -- Ich fühle mich verpflichtet darauf hinzuweisen, dass Spam in Wirklichkeit ein rosafarbenes Fleischverarbeitungsprodukt ist, welches von Hormel hergestellt wird. Hormel hat rechtliche Schritte bezüglich der begrifflichen Verwendung ihres Produktnamens für unerwünschte E-Mail unternommen und versucht aus markenrechtlichen Gründen die Verwendung in anderen Produktnamen wie "SpamArrest" zu unterbinden.
<http://abcnews.go.com/sections/scitech/Business/techtv_spam030801.html>
Aber für die meisten Leute bedeutet Spam einfach nur unerwünschte E-Mail eines Fremden, der ihnen einen Produkt verkaufen möchte, eine bestimmte Position einnimmt, eine Webseite bewirbt oder die Meinung des Lesers irgendwie beeinflussen möchte. Als die Anti-Spam Gesetze in den verschiedenen Bundesstaaten erlassen wurden, hat sich die Definition langsam in "unerwünschte kommerzielle E-Mail" verwandelt und verengt, abgekürzt mit UCE [Unwanted Commercial Email - ALO]. Damit waren nichtkommerzielle E-Mails von politischen oder wohltätigen Organisationen ausgenommen. CAN-SPAM schränkt diese Definition noch weiter ein.
CAN-SPAM benutzt den Begriff "Spam" nur in der Titelabkürzung und in einem der Erstkommentare des Gesetzes (Kommentare in einem Gesetz haben keine gesetzliche Relevanz und dienen eher politischen Stellungnahmen, um Gerichten zu helfen, das Gesetz zu interpretieren). CAN-SPAM definiert "kommerzielle elektronische Post" als E-Mail, "dessen Hauptzweck die kommerzielle Bewerbung oder Promotion eines kommerziellen Produktes oder Dienstleistung ist." Politische oder wohltätige Werbung ist nach wie vor ausgenommen von dieser Definition, genau so wie "transaktionale" oder "beziehungsbestehende" Nachrichten, welche typischerweise E-Mails von Partnern sind, mit denen man eine existierende Verbindung hat.
CAN-SPAM erlaubt der Bundeshandelsbehörde FTC [Federal Trade Commission - ALO] die Definition von "transaktionalen" oder "beziehungsbestehenden" Nachrichten zu verändern, für den Fall, dass Veränderungen in der E-Mail Technologie und Anwendung dies nötig machen, damit der Zweck des Gesetzes erhalten bleibt. Aber die FTC hat keine Autorität, die Definition von "kommerzieller elektronischer Post" zu verändern.
Schlüsselbestimmungen -- CAN-SPAMs schärfste Verbote zielen auf bestimmte Arten von irreführender und betrügerischer E-Mail. Diese können die Erzeuger von Spam mit beträchtlichen Strafen von bis zu drei Jahren Gefängnis für Ersttäter und bis zu fünf Jahren für Wiederholungstäter bestrafen. Dies würde zum Beispiel die vielen Nachrichten abdecken, in denen ein Exilpolitiker vorgibt, Geld waschen zu wollen und dem Empfänger an dem Geldberg teilhaben lassen möchte, wenn er ihm nur ein gültiges Bankkonto zur Verfügung stellt. Diese Nachrichten - bereits durch bestehende Gesetze unter Strafe - werden unter CAN-SPAM zusätzlichen Strafen unterworfen.
Andere kriminelle Aktivitäten, wie die Benutzung von Computern, Servern oder Domain-Adressen, um kommerzielle E-Mail ohne die Erlaubnis des Besitzers zu versenden oder weiterzuleiten bzw. die Nutzung falscher Kopfzeilen oder irreführender E-Mail Titel unterliegen neben der Strafverfolgung nun auch zivilrechtlichen Schritten und Bußen.
CAN-SPAM geht von einem Modell der "Option auf Abbestellung" aus (Engl.: opt-out - ALO), bei dem alle kommerziellen Nachrichten eine Abbestellungsmethode beinhalten müssen, damit man in Zukunft keine Mail mehr bekommt. Außerdem muss die echte E-Mail Adresse des Absenders und eine Briefpostadresse angegeben werden. Das Gesetz schreibt vor, dass Spam einen mailto-Link oder einen anderen Online-Mechanismus beinhalten muss, die es dem Empfänger erlaubt die Mail abzubestellen. Alle kommerziellen E-Mail unter CAN-SPAM müssen als Werbepost kenntlich gemacht werden. Das Gesetz spezifiziert nicht, auf welche Weise sich Spam-Erzeuger identifizieren müssen. Dies macht die FTC, die bis zum 1. April, April 2004 Zeit hat, die Identifizierung zu bestimmen, die Spam-Erzeuger dann benutzen sollen. Dieser Zwang zur Identifikation trifft nicht auf E-Mails zu, deren Empfänger ausdrücklich der Zusendung zugestimmt hat.
CAN-SPAM stuft verschiedene Aktivitäten als "besonders schwere Verstöße" mit höheren Strafandrohungen an. Diese umfassen die gebräuchliche Praxis E-Mail Adressen von verschiedenen Internet Quellen abzufassen und sogenannte "Telefonbuch"-Attacken. Die Benutzung des Servers eines anderen ist ebenfalls ein besonders schwerer Verstoß.
Eine schwer kritisierte Bestimmung des Gesetzes ist die Aufhebung aller Gesetze von Bundesstaaten, die Spam nur mit einigen wenigen Ausnahmen behandeln. Die einzigen lokalen Gesetze, die diese Verstümmelung überleben, sind diejenigen, die Falschheit und Irreführung in kommerzieller E-Mail verbieten. Dies betrifft die Gesetzesvorschriften des Staates Washington und große Teile der Kalifornischen Vorschriften und auch nur diejenigen die nur zufällig E-Mail betreffen. Beispiele für Vorschriften mit zufälligen Auswirkungen auf E-Mail sind generelle Computereinbruchsgesetze, Konsumentenschutzbestimmungen und andere Gesetze, die sich im weiteren Sinne auf das Thema E-Mail anwenden lassen. Dies bedeutet, dass die meisten bestehenden Ländergesetze am Straßenrand liegen bleiben und das die kalifornische "Option auf Abbestellung" Vorschriften, die dieses Jahr in Kraft treten sollten, in den Hauptpunkten im Prinzip null und nichtig wurden.
Was die Strafverfolgung betrifft, erlaubt CAN-SPAM keine Anwendung vom Individuum. Das heißt, dass Opfer von Spam-Erzeugern nicht vor Gericht gehen und auf die Einhaltung des Gesetzes pochen können. Autorisierte Verfolger sind die FTC und andere staatliche Behörden des Bundes, der Bundesstaatsanwalt und
Internet-ServiceAnbieter. Dabei sollte man anmerken, dass Internet-Service-Anbieter oftmals eigene Vorschriften haben, wie weit Spam und E-Mail-Benutzung innerhalb des eigenen Netzwerks erlaubt sind. Das neue Bundesgesetz tastet diese privaten Richtlinien nicht an, so dass ein Serviceanbieter auf Basis seiner Richtlinien Benutzer löschen oder abschalten kann und auch Schadensersatz geltend machen kann. Dadurch, dass die Serviceanbieter ihre Autorität behalten, erlaubt dies eine unabhängige, wenn auch selten genutzte, Möglichkeit, Spam-Erzeuger haftbar zu machen.
Wird CAN-SPAM funktionieren? -- Ich glaube nicht. CAN-SPAM ist ein guter Anfang, aber meiner Meinung nach hat es zu viele Unzulänglichkeiten um effektiv Spam zu stoppen oder sogar nur zu verringern.
CAN-SPAMs gute Ansätze sind, dass es sich um ein Bundesgesetz handelt und dadurch einheitlich in den Vereinigten Staaten angewendet wird. Das beseitigt ein zeitweises konfuses Flickwerk an verschiedenen Gesetzen in Bundesstaaten die bereits Anti-Spam Vorschriften verabschiedet hatten. Außerdem beseitigt es die Zuständigkeitsprobleme, ob ein Bundesstaat überhaupt die ausführende Gewalt über ein Unternehmen außerhalb seiner Grenzen war. Diese Zuständigkeitsdispute waren mit der Spam-Verfolgung innerhalb von Bundesstaaten gang und gäbe.
Es ist auch gut, dass verschiedene "vorsätzliche Verstöße" endlich deutlich genannt und beschrieben werden, da die zusätzliche Klarheit der Strafandrohung das Leben der Staatsanwaltschaften vereinfacht.
Außerdem wird alles, was die mögliche Haftung von Spam-Erzeugern erhöht, die ökonomische Balance von Spam ins Schwanken bringen. Wenn das Versenden von Spam mit Gefängnis geahndet wird, müssen die Spam-Erzeuger abwägen, ob die Resultate das potenzielle Risiko aufwiegen. Während zusätzliche Haftung sich vielleicht nicht unbedingt auf Gesetzesbrecher auswirkt, die die Gesetze ohnehin bis zur Verhaftung ignorieren, bedeuten die Anhebung des Gefängnisrisikos oder hohe Geldstrafen für Firmen, die vorher die Illegalität nur angekratzt haben, eine Abschreckung.
Trotz aller dieser guten Ansätze überwiegen doch die Mängel. Schauen wir sie uns an.
[Übersetzung: Dr. Walter Sonnenberg <dr.w.sonnenberg@t.online.de>]
Probleme der Internationalität -- Leider funktioniert CAN-SPAM so nur in den Vereinigten Staaten. - Denn das U.S.-Recht und internationale Verträge bestimmen U.S.-Gerichte als zuständig, wenn es Auswirkungen in die Vereinigten Staaten gibt. Auch wenn sich das auf dem Papier recht gut ausmacht, gibt es doch zwei wesentliche Probleme:
Zuallererst gibt es das Problem, Spammer zu belangen, die von außerhalb der USA operieren, weil amerikanische Gerichte ihnen gegenüber machtlos sind und selbst wenn man sie erreichen kann, ist jeder Richterspruch und jede gerichtliche Verfügung wertlos, weil sie nicht verfolgt werden. Damit kann gegen Spammer aus dem Ausland nur mit diplomatischen Mitteln vorgegangen werden. Ihnen dürfte klar sein, dass das amerikanische Anti-Spam-Gesetz wohl kaum Priorität vor anderen diplomatischen Zielen hat. Außer wenn Sie vielleicht nachweisen können, dass sich hinter der Spam Terroristen verstecken.
Zweitens beißt sich der Ansatz von CAN-SPAM direkt mit anderen - wenn nicht allen - Prinzipien der modernen Welt. Die europäische Gemeinschaft hat eine Richtlinie veröffentlicht, nach der jeder Mitgliedsstaat Gesetze erlassen muss, die die Richtlinie implementieren. (Die erste der unten angegebenen URLs verweist auf die englische Fassung der EG-Direktive, die zweite URL verweist auf eine Liste anderssprachiger Versionen).
<http://europa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf>
<http://europa.eu.int/information_society/topics/ecomm/useful_information/library/legislation/text_en.htm#dir_2002_58_ec>
Auch Australien hat eine eigene Strategie gegen Spam beschlossen, die nach Australien gesendet wird. Für den Anfang bedient man sich, nachdem die meisten Spam-Nachrichten wohl aus den USA kommen oder Dienstleistungen resp. Produkte amerikanischer Firmen bewerben, damit, sich dem amerikanischen Abwehrsystem anzuschließen und entzieht sich damit einer allgemeinen Lösung.
Diese gegensätzlichen Ansätze werden wohl ähnliche Probleme schaffen wie sie heute schon existieren oder schlimmere schaffen. wie sie in den USA existierten, bevor das amerikanische Bundesgesetz erlassen wurde, als verschiedene Bundesstaaten zuständig waren und unterschiedliche Mandate und Standards vorgaben. In den USA waren diese Bundesstaaten wenigstens unter einen gemeinsamen Bundesgesetzgebung zu vereinigen und konnten auf gemeinsame Kriterien verpflichtet werden. Auf internationaler Ebene werden sich die gegensätzlichen Vorgaben schlimmer auswirken. Da das amerikanische Gesetz weniger restriktiv ist als europäische und australische Vorgaben, glaube ich, dass die EU-Staaten und Australien weiterhin von Spam überflutet werden, die zwar in den U.S.A legal ist aber in den anderen Staaten eben nicht.
Probleme der Option auf Abbestellung (Opt-Out) -- Das Abstellen der Spam durch explizites abbestellen mag zwar für legitime Vermarkter funktionieren, kann aber nicht befriedigt werden, wenn skrupellose Spamversender versuchte Abbestellungen oder Verweise im Internet zur Gewinnung von E-Mail-Adressen missbrauchen. Die meisten solcher Nachrichten sind nicht legitim und benutzen enthaltene Verweise nur, um E-Mail-Adressen zu verifizieren oder neue zu gewinnen. Indem CAN-SPAM ermuntert, solche eingebauten Verweise zur Eindämmung von Spam zu nutzen, wird es den Umfang illegaler Spam tatsächlich erhöhen, es erhöht also das Risiko, dass E-Mail-Adressen gestohlen werden und andere Verbrechen an naiven Internetbenutzern begangen werden.
Probleme der Aktivierung -- CAN-SPAM verlagert die ganze Arbeit auf die Schultern von Leuten, die ohnehin überarbeitet sind bei Bundes- oder Staatsbehörden, die schon fatale Neigung zur Bearbeitung nur dringlicher und vorrangiger Probleme zeigen. Es ist also wahrscheinlich, dass ISPs als erste reagieren werden, aber die meisten ISPs haben gar nicht soviel Personal, dass sie die anfallenden Arbeiten bewältigen könnten, nämlich Spammer identifizieren, auch in fremden Ländern, oder andere Maßnahmen unternehmen, um Spammer einzuschränken.
Um fair zu bleiben, vor CAN-SPAM mussten die meisten solcher Arbeiten von privaten erledigt werden, davon viel in Staaten, in denen es keine Regelungen gegen Spam gab. Meist sind Private nicht in der Lage, intensives Suchen nach Spammern zu finanzieren, oder sie können dies nicht ohne Hilfe ihrer ISPs. CAN-SPAM erlaubt es auch nicht, dass Private Informationen über Spammer zusammentragen. Es sieht kontraproduktiv aus, dass die Mithilfe Freiwilliger nicht unterstützt wird, so könnte man Spam bekämpfen und könnte Hilfsmittel für Spam-Opfer schaffen. Die Leidtragenden sind wieder nur die Endandwender, sie könnten Spammer auffinden und verantwortlich machen.
Letztlich wird CAN-SPAM selbst dann, wenn Spammer vor Gericht gestellt werden können, an seinen Schleifen leiden. So wird der "Hauptgrund" laut Spam Definition umgangen werden, indem Spammer persönliche Informationen in ihre Sendungen einflechten und argumentieren, dass die Werbung nicht der Hauptgrund der Sendung wäre, Ich vermute, dass viele Leser bereits Spam erhalten haben, die die Empfänger anspricht: "Wie geht es Ihnen? Ich bekam zufällig (Produkt) und nehme an, es interessiert Sie". Auch wenn diese Masche wohl den Lachtest vor Gericht nicht bestehen wird, zeigt sie doch einen Ansatz, der vor Gericht erst einmal ausprobiert werden muss. Damit lässt sich wieder Zeit gewinnen, bis ein Richter die richtigen Schlüsse zieht. Auch so könnten Individuen viele Erfahrungen beitragen und das Vorgehen gegen Spam beschleunigen.
Fassen wir zusammen -- in früheren Artikeln habe ich gezeigt, dass Spam außergesetzlich ist und dass nur Gesetzeslose Spam produzieren. Ein immer noch zunehmender Anteil an Spam verletzt bereits heutige Gesetze und muss nicht ausgegrenzt werden, weil die Gesetze nicht greifen. Legitim arbeitende Firmen haben versucht, mit legalen Mitteln Werbung zu treiben, Wenige legitime Werber verletzen willkürlich alle alten und neuen Schranken und können nicht belangt werden, solange man ihrer nicht persönlich habhaft wird.
Letztlich bietet CAN-SPAM zwar einen netten Anfang, ist aber mit zu vielen Fehlern belastet, um gegen Spam effektiv eingesetzt werden zu können. Wie vorhandene Gesetze einiger Staaten wird es von legitim werbenden Firmen beachtet (nicht dass diese vor dem Gesetz besonders Spam-intensiv geworben hätten), aber es wird weder auf Spammer von außerhalb der USA eine Wirkung zeigen, die ohnehin den Gesetzen der U.S.A nicht unterliegen, noch auf skrupellose Spammer wirken, die ohnehin alle Gesetze ignorieren, wenn sie nicht gerade ins Gefängnis gesteckt werden. Die Inkonsistenz der Anti-Spam-Gesetzgebung wird immer die Umgehung lokaler Regelungen provozieren.
Einfach gesagt, CAN-SPAM sagt den Spammern, dass sie weiter Spam senden können, solange sie die gesetzlichen Regeln beachten. Enttäuschend ist dabei, dass wir lange auf eine Regelung gewartet haben und das, was wir jetzt haben, ist nicht so gut, wie es sein könnte, ja nicht einmal so gut, wie die Regelungen einzelner U.S.-Staaten. Das ist schade und wir werden damit eine Zeit leben müssen.
[Brady Johnson ist Rechtsanwalt in Seattle und hasst Spam sehr.]
vom TidBITS-Team editors@tidbits.com
[Übersetzung: Roland Müller <mail@duesenschrieb.de>]
Internationale Versionen von AppleWorks -- Es war noch nicht ganz klar bei der Vorstellung des letzten AppleWorks-Updates, aber zugleich ist auch eine internationale Version aktualisiert worden (Ausnahme: Frankreich). ("AppleWorks international versions" - 2 Beiträge)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2145>
Angriff auf Habeas -- Habeas sieht sich dem ersten ernsthaften Test im Kampf gegen Spam ausgesetzt. Können sie erfolgreich Spammer verklagen, die gegen ihre mit Copyright und Warenzeichen geschützten Haiku-Header verstoßen? ("Habeas under attack" - 5 Beiträge)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2144>
Apple baut eine komplette Audio-Produktlinie auf -- Wie werden Apples neuesten Audioprogramme (einschließlich der angekündigten aber noch nicht ausgelieferten) die Wahrnehmung des Unternehmens seitens der Konsumenten und der Audiobranche beeinflussen? ("Apple creating a full audio product line" - 2 Beiträge)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2143>
Erste Eindrücke von iPhoto 4 -- Mehr als alles andere halten die Leser die Geschwindigkeitsoptimierungen in iPhoto 4 für so ziemlich das Beste an iLife ’04. ("iPhoto 4 initial impressions" - 2 Beiträge)
<http://db.tidbits.com/getbits.acgi?tlkthrd=2142>
Übersetzung dieser Ausgabe: Hartmut Greiser <info@linarte.com>, Alexander Lorani" <alexander.lorani@web.de>, Roland Müller <mail@duesenschrieb.de> und Dr. Walter Sonnenberg <dr.w.sonnenberg@t.online.de>.
Lektorat: Heike Kurtz <mail@heikekurtz.de>.
Koordination dieser Ausgabe: Jens Peter Franke <jpfranke@gmx.net>.
Copyright der deutschen Ausgabe: Heinz Gnehm <gnehm@infotrax.ch>.
Nichtkommerzielle oder gemeinnützige Medien dürfen unsere Artikel nachdrucken, wenn sie einen Link auf die Seite der deutschen TidBITS oder eine volle Referenz angeben. Andere kontaktieren uns bitte per E-Mail. Der Inhalt der Artikel ist ohne Gewähr. Wenden Sie sich bitte an den Autor. Namen von Publikationen, Produkten oder Firmennamen können durch Gebrauchsmustereintrag geschützt sein. TidBITS engl. ISSN 1090-7017.