Thema
Softwarelebenszyklus und Lock-in
Innerhalb der Facette Thema verbindet die Themenanalyse Softwarelebenszyklus und Lock-in Artikel, die ein gemeinsames Thema, einen Signalfokus oder ein Monitoring-Thema teilen. Die Seite bietet den Lesern einen umfassenderen Zugang zu verwandter Berichterstattung, Quellenbelegen, Marktakteuren und Infrastrukturfolgen – mit ausreichend Kontext, um zu verstehen, warum das Thema für Unternehmensaktivitäten, Governance-Entscheidungen, regionale Risikoexposition und operationelle Risiken relevant ist. Leser können wiederkehrende Signale, betroffene Organisationen, öffentliche Belege, Marktkontext, Servicekontinuität, Beschaffung, Wettbewerb, Compliance und strategische Planungsfragen hinter dem Thema vergleichen, statt bei einer dünnen Liste passender Artikel stehenzubleiben. Es erklärt, was das Thema abdeckt, welche Infrastrukturakteure oder -politiken beteiligt sind, welche Belege die Berichterstattung stützen und warum das Thema für Betreiber, Kunden, Investoren und politisch interessierte Leser von Bedeutung sein kann.
Geschichte
Adele Goldberg und der Vertrag, der Smalltalk-80 auf Reisen schickte
Das Blue Book machte aus einem lebenden System eine portable Vereinbarung: dasselbe Image bewahren, Objektspeicher, Bytecodes, Kontexte und Primitive für unterschiedliche Rechner implementieren und damit dasselbe Smalltalk-80 ausführen. Diese Vereinbarung ermöglichte…
Geschichte
Join hatte keine Quittung: Wie der Baum aus RFC 2117 durch Erneuerung weiterlebte
Die erste PIM-SM-Spezifikation behandelte den Beitritt zu einem Multicast-Baum nicht als bestätigte Zustellung. Der Zustand blieb bestehen, weil Router ihn vor Ablauf ihrer Timer erneut ankündigten – die fehlende Bestätigung war Teil des Kontrollmechanismus.
IETF
Vor dem Senden gehört der Entwurf nur seinem Autor: RFC 9787 und die kryptografische Bindungsgrenze
E-Mail-Sicherheit wird meist am fertigen Versandobjekt diskutiert. RFC 9787 lenkt den Blick auf einen früheren und operativ schwierigeren Zustand: den gespeicherten Entwurf. Solange eine Nachricht noch verändert werden kann, soll ihre Vertraulichkeit nicht vom entfernten…
Geschichte
Der Browser erinnerte die Sitzung, nicht die Person: RFC 2109
Im Beispiel von RFC 2109 legte ein Server `Customer="WILE_E_COYOTE"` im Browser ab. Spätere Anfragen brachten den Namen zusammen mit Artikelnummer und Versandart zurück. Damit erhielt HTTP ein Gedächtnis für eine Folge von Vorgängen. Aus dem Anwendungslabel wurde jedoch weder ein…
Geschichte
Gleiche Zähler, begrenzte Aussage: Der Messvertrag von RFC 2108
RFC 2108 übernahm die Bedeutung zentraler Repeater-Zähler aus IEEE 802.3 und machte sie per SNMP vergleichbar. Das schuf eine gemeinsame Instrumentierung — aber weder eine automatische Ursachenanalyse noch einen Freibrief für Eingriffe.
Geschichte
Kathleen Booth und die Grenze zwischen Symbol und Maschinenbefehl
1947 beschrieben Kathleen H. V. Britten und Andrew D. Booth, wie ein mathematisches Verfahren in einen 20-Bit-Befehl übergeht. Ihre Kurznotation machte diesen Übergang prüfbar, ohne die Ausführung mit der Richtigkeit des Vorhabens zu verwechseln.
Geschichte
Die Adresse sagte „zu Hause“. Die Einwahlleitung sagte „entfernt“: RFC 2107
RFC 2107 gab einem entfernten Einwahlrechner den Anschein, im Heimnetz zu stehen. Diese Illusion hing an Foreign Agent, Home Agent, gemeinsamem Geheimnis, Tunnel ID und Zuständen, die in der richtigen Reihenfolge entstehen und verschwinden mussten.
Geschichte
Karen Spärck Jones gab seltenen Treffern mehr Gewicht – nicht mehr Wahrheit
Dasselbe Wort kann in einer Sammlung allgegenwärtig und in einer anderen ungewöhnlich sein. Karen Spärck Jones machte diese Differenz zu einem messbaren Retrievalsignal. IDF bewertet die Trennschärfe innerhalb eines Bestands; über Bedeutung und Wahrheit entscheidet es nicht.
Geschichte
Der Router gab dem Arbeitsplatz eine Adresse, aber keine Identität: RFC 2106
RFC 2106 bündelte viele entfernte SNA- und NetBIOS-Arbeitsplätze hinter einem DRAP-Server. Weniger Backbone-Peers bedeuteten zugleich mehr Zustand, Entscheidungsmacht und Vertrauen am Übergang.
Geschichte
Das Tag bewegte das Paket, bewies aber nicht den Pfad: RFC 2105
Ein Paket kam mit einer kurzen Kennung an. Der Switch schlug sie exakt nach, ersetzte sie und leitete das Paket über die gespeicherte Schnittstelle weiter. So knapp war der Datenpfad der 1997 beschriebenen Tag-Switching-Architektur von Cisco. Die Gründe für den Eintrag lagen…
Fallakte
Die W3C-Gruppe zur Browser-Datenportabilität beginnt mit einem Bericht, nicht mit einem Standard
Auf dem iPhone lässt sich ein Teil der Safari-Daten bereits exportieren und in einen anderen Browser importieren. Das ist eine konkrete Produktfunktion mit klaren Versions- und Systemgrenzen. Die am 15. September gestartete Browser Data Portability Community Group des W3C…
IETF
NFFRR: Wer darf die zweite Rettung verbieten?
Fast Reroute ist dafür gebaut, Pakete trotz eines lokalen Ausfalls weiterzubringen. Genau diese Stärke kann bei einer zweiten Reparatur zur Schwäche werden: Zwei jeweils plausible lokale Entscheidungen können gemeinsam einen Loop erzeugen. RFC 9791 macht daraus einen…
Fallakte
RFC 9682: Reproduzierbar ist nicht automatisch richtig
Die Herkunft eines ausgelieferten Validators muss sich rückwärts prüfen lassen: Welcher Verbraucher hat ihn geladen, woraus wurde er erzeugt, welche semantische Darstellung wurde kompiliert? Die entscheidende Gegenprobe ist eine reproduzierbare Neuerzeugung mit exakt denselben…
Geschichte
Zwei Hash-Durchläufe machten den MAC wiederverwendbar, nicht die Vertrauensentscheidung: RFC 2104
RFC 2104 formte vorhandene iterative Hashfunktionen mit einem inneren und einem äußeren Schlüsseldurchlauf zu HMAC. Die Konstruktion blieb beim Austausch des Hashes erkennbar und nutzbar. Ein passendes Tag belegte jedoch nur eine eng umrissene Beziehung zwischen Schlüssel, Bytes…
Geschichte
Erst wechselte der Locator, dann bewegte sich das Netz: RFC 2103
Nimrods Mobilitätsaufsatz begann mit einer eleganten Trennung: Die Identität eines Endpunkts bleibt stabil, nur der Locator für seine Erreichbarkeit wird ersetzt. Dann fand er den Fall, der diese Eleganz aufbrach: Ein Netz konnte sich bewegen, ohne dass sich die Locator seiner…
Geschichte
Kein einheitlicher Baum, aber eine eindeutige Zustandszeile: RFC 2102
RFC 2102 schrieb Nimrod keinen Multicast-Algorithmus vor. Es verlangte eine schmalere Gemeinsamkeit: Unterschiedlich erzeugter Zustand musste in jedem beteiligten Router dieselbe ausführbare Bedeutung besitzen.
Geschichte
Die Zelle übersprang Routerarbeit. Die Route erbte sie nicht: RFC 2098
In einem Cell Switch Router entschied ein kleiner Nachschlagevorgang, ob eine eintreffende ATM-Zelle Zelle blieb oder wieder Teil eines IP-Datagramms wurde. Traf VPI/VCI auf einen Eintrag, ging sie durch das Schaltwerk; ohne Treffer folgten Wiederzusammensetzung und…
Geschichte
Die Verbindung war offen. Jeder Name brauchte noch Zulassung: RFC 2097
PPP konnte einen entfernten Rechner an den Rand eines NetBIOS-Frames-Netzes bringen. RFC 2097 setzte Link-Aufbau jedoch nicht mit Erreichbarkeit gleich. NBFCP handelte aus, welche 16-Oktett-Namen auf das entfernte Netz projiziert wurden, welche scheiterten, welche Klasse der Peer…
IETF
Der Name links vom Schrägstrich wurde registriert. Das Deployment ist damit nicht belegt
RFC 9694 macht aus einer seltenen Namensentscheidung eine Verpflichtung für das Ökosystem. Ein neuer Top-Level-Medientyp kann bestimmen, wie unbekannte Formate gruppiert, Anwendungen gewählt und Inhalte dargestellt werden. Der IANA-Eintrag ist ein Fakt, aber erst der erste Beleg…
Geschichte
Der vierte Buchstabe entschied, was der Editor behalten durfte: RFC 2083
Ein PNG kann nach einer vollständigen Bildänderung plausibel aussehen und dennoch unbekannte Metadaten aus dem alten Zustand mitführen. RFC 2083 erklärte solche Daten nicht für wahr. Die Spezifikation kodierte eine engere Entscheidung in der Groß- und Kleinschreibung von vier…