WEBVTT
00:00:00.000 --> 00:00:18.810
35C3 Vorspannmusik
00:00:18.810 --> 00:00:23.810
Herald: Wer von euch im Publikum kennt
noch den Bildschirmtext? Bitte mal
00:00:23.810 --> 00:00:33.910
aufzeigen! Und wer von euch kennt noch den
BTX-Hack vom CCC? Sehr schön, wir haben
00:00:33.910 --> 00:00:41.239
hier also ein Fachpublikum sitzen für
einen Fachvortrag. Und der Vortragende,
00:00:41.239 --> 00:00:47.990
das ist Christian Berger. Christian
Berger ist Elektroingenieur der
00:00:47.990 --> 00:00:51.879
Nachrichtentechnik und das aus
Leidenschaft, und seine besondere Vorliebe
00:00:51.879 --> 00:00:58.149
gilt antiken Technologien, wie etwa dem
Bildschirmtext. Und in diesem Vortrag wird
00:00:58.149 --> 00:01:02.440
er euch gleich erklären, wie das ganze
damals funktioniert hat, und was für
00:01:02.440 --> 00:01:07.300
Aspekte dieser Technologie man vielleicht
für einen Webservice wiederverwenden kann.
00:01:07.300 --> 00:01:10.500
Einen herzlichen Applaus bitte für
Christian Berger.
00:01:10.500 --> 00:01:15.729
Applaus
00:01:15.729 --> 00:01:24.729
Christian: So also guten Morgen erstmal!
Der Vortrag ist zugegeben etwas radikaler,
00:01:24.729 --> 00:01:32.090
er geht von den Grundlagen aus, getreu dem
Motto Refreshing Memories beschreibe ich
00:01:32.090 --> 00:01:38.020
hierbei quasi die Dinge, die nicht in den
Standarddokumenten drin stehen, so dass
00:01:38.020 --> 00:01:42.329
man mal die Grundlagen hat. Ich kann da
aber bisher schneller darüber eingehen.
00:01:42.329 --> 00:01:49.091
Also erstmal die absoluten Grundlagen.
Binäre Daten: man immer zwei Zustände,
00:01:49.091 --> 00:01:56.549
1 und 0. Die werden dann irgendwie
darstellt. Bei BTX in dem Fall da das
00:01:56.549 --> 00:02:01.560
traditionell über ein FSK-Modem geht, wird
es über eine Tonhöhe, also über die
00:02:01.560 --> 00:02:08.038
Frequenz von dem Ton beschrieben. Und da
gibt's zwei Kanäle. Der eine Kanal, der
00:02:08.038 --> 00:02:13.349
Forward-Kanal, der hat 1200 Bits pro
Sekunde und der Backward-Kanal hat 75 Bits
00:02:13.349 --> 00:02:22.210
pro Sekunde. Um da jetzt genau zu sagen,
wann gilt der Zustand, verwendet man bei
00:02:22.210 --> 00:02:26.871
BTX die asynchrone Datenübertragung,
sprich man lässt es quasi immer im
00:02:26.871 --> 00:02:32.959
Zustand 1, und wenn man was schicken will,
wechselt man in den Zustand 0, und das ist
00:02:32.959 --> 00:02:38.090
quasi der Beginn des sog. Startbits, und
man weiß dann, wann die nächsten Bits
00:02:38.090 --> 00:02:44.010
anfangen und enden. Und somit kann man
eben z. B. 8 Bits übertragen bei BTX, und
00:02:44.010 --> 00:02:48.460
dann ein Stoppbit übertragen, so dass die
Hardware auch noch feststellen kann, ob
00:02:48.460 --> 00:02:52.849
nicht vielleicht irgendwie ein Fehler
passiert ist, und auch Zeit hat, um es
00:02:52.849 --> 00:03:02.099
weiter zu verarbeiten. Damit wir das
effizienter schreiben können, tun wir
00:03:02.099 --> 00:03:06.330
einfach vier Bits in ein Hexadezimalzeichen.
Dass ist auch wichtig, wenn man
00:03:06.330 --> 00:03:10.890
die Standards verstehen möchte, da ist es
nämlich immer quasi in Vier-Bit-Gruppen
00:03:10.890 --> 00:03:17.410
beziehungsweise Hexadezimalzahlen
untergliedert, damit man es versteht.
00:03:17.410 --> 00:03:22.040
Man möchte jetzt natürlich nicht nur Zahlen
oder einzelne Bits übertragen, sondern
00:03:22.040 --> 00:03:29.710
Buchstaben oder Texte. Dafür gibt es den
ASCII-Code, der hier in den Spalten 2 bis 7
00:03:29.710 --> 00:03:37.031
druckbare Zeichen hat, also Buchstaben,
Zahlen, Sonderzeichen; und hier in den
00:03:37.031 --> 00:03:44.500
ersten beiden Spalten links spezielle
Steuerzeichen, die besondere Bedeutung
00:03:44.500 --> 00:03:49.390
haben und eben je nach Standard, der dann
drüber liegt, unterschiedlich benutzt
00:03:49.390 --> 00:03:58.819
werden. Bei BTX wird z. B. schon mal
direkt über der Modemschicht eine
00:03:58.819 --> 00:04:05.970
Fehlerkorrektur gemacht. Sprich man
überträgt die Daten, bzw. man teilt die
00:04:05.970 --> 00:04:12.590
Daten in Blöcke ein, setzt dann davor ein
STX-Zeichen, dahinter ein ETX-Zeichen, so
00:04:12.590 --> 00:04:18.738
dass man weiß, wo der beginnt und endet.
Dann überträgt man eine Prüfsumme und das
00:04:18.738 --> 00:04:25.040
Terminal bestätigt dass dann. Die Idee
dahinter ist: wenn bei der Übertragung ein
00:04:25.040 --> 00:04:31.120
Fehler passiert, dann kann das Terminal
sagen: NAK, da ist ein Fehler passiert.
00:04:31.120 --> 00:04:36.520
Dann kann der Zentralrechner quasi die
Daten noch mal schicken. Und somit kriegt
00:04:36.520 --> 00:04:41.400
man auch über schlechtere Verbindungen
eine fehlerfreie Verbindung. Das ist vor
00:04:41.400 --> 00:04:46.170
allen Dingen jetzt auch bei VoIP wichtig,
weil da kann es manchmal sein, dass wenn
00:04:46.170 --> 00:04:53.040
der Takt vom ATA und der Takt vom
Zentralrechner auseinanderdriften, dann
00:04:53.040 --> 00:04:57.510
sind irgendwann mal zu wenig oder zu viele
Samples drin, und dann muss er entweder
00:04:57.510 --> 00:05:07.510
Stille einfügen oder Samples wegwerfen,
und das gibt natürlich dann Bitfehler. Und
00:05:07.510 --> 00:05:12.260
deswegen ist es heutzutage relativ wichtig
dass das drin ist. Zur Not geht es im LAN
00:05:12.260 --> 00:05:24.700
auch ohne, aber es ist schon besser mit.
Dann die grundlegende Sache: manche kennen
00:05:24.700 --> 00:05:31.220
ja vielleicht so Web Services, so
traditionelle, bzw. das World Wide Web. Da
00:05:31.220 --> 00:05:36.230
ist es so: da wird ein Dokument komplett
übertragen und dann durch den Client
00:05:36.230 --> 00:05:42.770
dargestellt. Ein Terminal hingegen hat
eine ganz andere, hat einen ganz anderen
00:05:42.770 --> 00:05:48.020
Gedanken dahinter, man hat quasi ein
Dokument, zum Beispiel traditionell ein
00:05:48.020 --> 00:05:55.220
Blatt Papier, und man schickt dann Befehle
an das Terminal, quasi z. B. das Zeichen
00:05:55.220 --> 00:06:01.550
"A", und das Terminal druckt dann auf
dieses Dokument ein "A". Dadurch ist es
00:06:01.550 --> 00:06:06.690
sehr einfach, Änderungen an dem Dokument
durchzuführen. Das ist für Anwendungen
00:06:06.690 --> 00:06:13.940
sehr praktisch. Kann man damit sehr leicht
machen, während man im Web z. B. die
00:06:13.940 --> 00:06:17.890
komplette HTML-Seite nochmal übertragen
müsste - nach der reinen Lehre - auch wenn
00:06:17.890 --> 00:06:25.400
man jetzt irgendwie nur ein Zeichen ändern
wollte. Jetzt wie schaut dieses Dokument
00:06:25.400 --> 00:06:34.870
aus? Als man ursprünglich begonnen hat mit
der Idee Bildschirmtext zu machen, hat man -
00:06:34.870 --> 00:06:40.910
war RAM noch extrem teuer. Deswegen hat
man sich überlegt, nimmt man doch 7 Bit
00:06:40.910 --> 00:06:48.030
pro Zeichen, das geht dann, da gab's schon
entsprechende Chips, die genügend Speicher
00:06:48.030 --> 00:06:55.270
hatten. Und man wollte aber trotzdem
farbige Grafiken haben, bzw. farbigen
00:06:55.270 --> 00:07:02.470
Text. Deswegen hat man sich hierbei
überlegt, man sieht hier die Wörter, und
00:07:02.470 --> 00:07:08.810
dazwischen sind Steuerzeichen. Jedes
Steuerzeichen belegt einen Platz im
00:07:08.810 --> 00:07:15.950
Bildschirmspeicher bzw. eine
Zeichenposition. Da man de facto eh jetzt
00:07:15.950 --> 00:07:22.050
ein Wort vielleicht in einer Farbe haben
möchte, oder z. B. ein Wort in doppelter
00:07:22.050 --> 00:07:28.400
Höhe oder blinkend machen möchte - Blinken
sieht man jetzt natürlich nicht - ist es
00:07:28.400 --> 00:07:32.390
keine große Einschränkung und das ist
tatsächlich auch das, was im Videotext
00:07:32.390 --> 00:07:36.771
auch heute noch verwendet wird.
Ursprünglich war auch der Gedanke, dass
00:07:36.771 --> 00:07:42.960
man an den schon vorhandenen Videotext-
Dekoder im Fernsehgerät quasi noch einen
00:07:42.960 --> 00:07:49.990
Mikroprozessor und ein Modem dranhängt, um
damit dann Bildschirmtext zu machen, was
00:07:49.990 --> 00:07:54.990
natürlich die Kosten und die Verbreitung
enorm beflügelt hätte. Minitel macht es
00:07:54.990 --> 00:08:02.811
meines Wissens nach auch so, also mit dem
einfacheren Verfahren. Aber man hat
00:08:02.811 --> 00:08:08.250
festgestellt, also gut, bei Videotext muss
man quasi immer die komplette Seite
00:08:08.250 --> 00:08:13.970
übertragen. Das ist natürlich jetzt, wenn
man nur 1200 Bits pro Sekunde hat, eine
00:08:13.970 --> 00:08:20.470
relativ mühselige Sache. Deswegen gibt's
Cursor-Steuerzeichen. Es gibt da immer
00:08:20.470 --> 00:08:24.700
einen gedachten Cursor. den kann man
bewegen, in dem Fall nach links, rechts,
00:08:24.700 --> 00:08:28.531
oben, unten. Man kann die Bildschirm
komplett löschen. Man kann ganz nach links
00:08:28.531 --> 00:08:33.809
gehen auf der Zeile und man kann zu einer
bestimmten Position gehen. Damit kann man
00:08:33.809 --> 00:08:38.710
sehr effizient dann eben bestimmte
Bereiche vom Bildschirm aktualisieren,
00:08:38.710 --> 00:08:46.210
ohne den Rest zu ändern. Aber jetzt kamen
plötzlich die 80er Jahre auf.
00:08:46.210 --> 00:08:50.180
Arbeitsspeicher war relativ, er ist
billiger geworden und es war absehbar,
00:08:50.180 --> 00:08:55.740
dass Arbeitsspeicher billiger wird, das
heißt man hat sich dann leisten können
00:08:55.740 --> 00:09:00.560
nicht nur 7 Bit pro Zeichen zu verwenden,
sondern 32 Bit. Damit kann man
00:09:00.560 --> 00:09:04.860
dann für jedes Zeichen einzeln die Farbe
bestimmen, auch die Hintergrundfarbe. Man
00:09:04.860 --> 00:09:11.250
kann benutzerdefinierte Zeichen machen,
also extra nochmal Zeichen, die man
00:09:11.250 --> 00:09:16.670
beliebig definieren kann, um Grafiken zu
machen. Man kann auch die Größe
00:09:16.670 --> 00:09:22.800
einstellen. Dann kam auch die Laser Disk
auf, so als ewig futuristisches Medium.
00:09:22.800 --> 00:09:29.240
Man dachte sich damals, das man vielleicht
einen Laser-Disk-Player an den
00:09:29.240 --> 00:09:35.020
Bildschirmtextdecoder anschließt, und wenn
man dann im Versand, also im $versandhaus
00:09:35.020 --> 00:09:41.350
bestellt, kriegt man anstelle vom Katalog
eine Laser Disk, die legt man ein. Man
00:09:41.350 --> 00:09:45.510
wählt sich dann in BTX ein und sieht dann
quasi die Preise und die
00:09:45.510 --> 00:09:49.590
Produktbeschreibungen, die kommen über die
Telefonleitung, aber die Bilder im
00:09:49.590 --> 00:09:55.850
Hintergrund kommen quasi von der Laser
Disc. Oder die nächste Stufe dann wenn der
00:09:55.850 --> 00:10:00.800
Glasfaserausbau Mitte der 90er Jahre
fertig ist...
00:10:00.800 --> 00:10:06.280
Gelächter
Applaus
00:10:06.280 --> 00:10:09.230
Ja, damals war man noch optimistisch und
00:10:09.230 --> 00:10:12.530
damals gab es auch noch keinen
Schwarz-Schilling. Damals, also,
00:10:12.530 --> 00:10:15.800
dann war eben auch der
Gedanke, dass man vielleicht
00:10:15.800 --> 00:10:20.330
sogar komplette Hintergrund-Videos
überträgt. Weil es war damals schon dafür
00:10:20.330 --> 00:10:27.450
ausgelegt, dass man Video überträgt mit
280 Megabit downstream, 140 Megabit
00:10:27.450 --> 00:10:31.670
upstream, und da kann man natürlich ein
Videosignal einfach übertragen, das dann
00:10:31.670 --> 00:10:39.670
von der Zentrale kommt. Deswegen wollte
man da mehr machen, und hat da auch
00:10:39.670 --> 00:10:42.840
ziemlich viel dann reingestopft und auch
ziemlich viel in die Standards gemacht.
00:10:42.840 --> 00:10:48.390
Man möchte da jetzt mehr Zeichen
darstellen, man möchte nicht bloß einen
00:10:48.390 --> 00:10:51.861
deutschen Zeichensatz haben, oder einen
amerikanischen, sondern man möchte
00:10:51.861 --> 00:10:56.790
eigentlich Texte in allen europäischen
Sprachen darstellen können.
00:10:56.790 --> 00:11:01.790
An chinesischer oder sowas hat damals noch
niemand gedacht. Deswegen möchte man mehr
00:11:01.790 --> 00:11:08.010
als die 96 Zeichen vom ASCII-Code
darstellen. Deswegen hat man sich
00:11:08.010 --> 00:11:16.470
überlegt, den Zeichenvorrat von 256
Zeichen, das sind ja 96 beim ASCII-Code
00:11:16.470 --> 00:11:23.450
als druckbare Zeichen definiert, dass man
nochmal ein gleiches Fenster daneben
00:11:23.450 --> 00:11:29.250
macht, quasi mit dem höchstwertigen Bit
gesetzt. Somit hat man zwei Fenster, in
00:11:29.250 --> 00:11:36.560
denen Zeichensätze quasi einblenden
konnte. Sprich man sagt dann z. B.
00:11:36.560 --> 00:11:41.170
Single Shift 2, dann wird hierbei das
nächste Zeichen aus dem Zeichensatz G2
00:11:41.170 --> 00:11:46.130
gewählt. Wenn ich jetzt also ein "$"
haben möchte, schicke ich Single Shift 2
00:11:46.130 --> 00:11:50.420
und den entsprechenden Code für das
Dollarzeichen dann. Weiß ich jetzt nicht
00:11:50.420 --> 00:11:56.550
auswendig, aber es müsste eine Ziffer
sein. Und da gibt es auch die Möglichkeit
00:11:56.550 --> 00:12:01.920
das als Locking Shift zu machen, dann
bleibt es an der Stelle drin, oder nur als
00:12:01.920 --> 00:12:06.560
Single Shift. Und diese Zeichen hier, die
so grau hinterlegt ist - ich weiß nicht,
00:12:06.560 --> 00:12:11.750
sieht man das? Nö, das sieht man ganz
leicht - auf jeden Fall von - bis hier,
00:12:11.750 --> 00:12:18.050
das ist das letzte - die sind quasi
Akzente. Man hat damals gesagt, Single
00:12:18.050 --> 00:12:25.040
Shift G2, dann das Zeichen und dann "A",
da er ein "Ä" gedruckt, z. B. Damit kann
00:12:25.040 --> 00:12:29.040
man eben sich viel sparen, muss nicht so
viel Zeichencodes machen, und vor allen
00:12:29.040 --> 00:12:34.030
Dingen, wenn ein Terminal jetzt kein "Ä"
kann, dann kann es immer noch "A" drucken,
00:12:34.030 --> 00:12:41.690
und das ist lesbar. Es so weit ist es
eigentlich noch ziemlich so, wie auch die
00:12:41.690 --> 00:12:47.020
üblichen VT100-Terminals, die auf unseren
Rechnern als Emulation heute noch laufen.
00:12:47.020 --> 00:12:52.320
Aber wie macht man jetzt da Bild und Ton?
Man hat sich damals auch schon überlegt,
00:12:52.320 --> 00:12:56.100
vielleicht direkt über den digitalen Kanal
Bild und Ton zu machen, deswegen hat man
00:12:56.100 --> 00:13:04.710
sich überlegt dass man dann noch mal ein
gedachtes Protokoll darüber schickt.
00:13:04.710 --> 00:13:11.930
Sprich man hat hierbei das Zeichen 1F,
Unit Separator, und hier unten ist das was
00:13:11.930 --> 00:13:15.740
wir vorher schon gesehen haben, quasi der
Sprung des Cursors zu einer bestimmten
00:13:15.740 --> 00:13:24.610
Position und das alles hier oben sind im
Prinzip ungültige Positionen. Das heißt,
00:13:24.610 --> 00:13:32.790
ein sorgfältig produzierter Decoder würde
sich dann quasi da abschalten und dann
00:13:32.790 --> 00:13:35.600
erst wieder sich einschalten wenn er
wieder irgendwo in den Bildbereich
00:13:35.600 --> 00:13:44.970
springt. Was man darüber aber machen kann
sind Zusatzfunktionen. Zum Beispiel also -
00:13:44.970 --> 00:13:49.230
es gibt hierbei die Möglichkeit - ich weiß
nicht, ob das irgend jemand benutzt hat -
00:13:49.230 --> 00:13:55.050
dass das Terminal sich selbst meldet bzw.
das man anfragen kann, was denn das
00:13:55.050 --> 00:14:05.170
Terminal kann. Es gibt da die User Defined
Characters, die im Bildschirmtext intensiv
00:14:05.170 --> 00:14:09.460
genutzt wurden. Damit kann man dann
Grafiken machen. Die Zeichen sind
00:14:09.460 --> 00:14:15.380
standardmäßig in zwölf mal zehn Pixel, was
auf Heimcomputern ein bißchen ein Problem
00:14:15.380 --> 00:14:19.750
war. Also auf dem C64 hat man dass nicht
gut darstellen können. Man hat aber auch
00:14:19.750 --> 00:14:23.270
niedrigere Auflösungen nehmen können, um
mehr Farben - da gab es alle Spielarten.
00:14:23.270 --> 00:14:32.370
Man hat die Palette neu definieren können:
man hatte quasi 4x8 Farben zur Verfügung
00:14:32.370 --> 00:14:38.340
und die konnte man beliebig auswählen aus
einer Palette von 4096 Farben. Also
00:14:38.340 --> 00:14:43.980
richtig schöne Farbgrafiken damit machen.
Man kann hier mit Define Format kann man -
00:14:43.980 --> 00:14:48.720
bin ich mir jetzt gerade nicht sicher -
aber Timing Control, damit kann man Delays
00:14:48.720 --> 00:14:52.749
machen, weil wenn man jetzt eine
schnellere Verbindung hat, z. B. ISDN,
00:14:52.749 --> 00:14:56.850
dann möchte man eventuell beim Bildaufbau
mal kurz warten und anhalten und dann
00:14:56.850 --> 00:15:03.270
weiter machen. Man kann auch die
Bildschirmgröße sogar einstellen, das ist
00:15:03.270 --> 00:15:09.730
tatsächlich im Standard vorgesehen, im
Prinzip beliebig groß. Man würde dann halt
00:15:09.730 --> 00:15:15.040
hierbei anstelle von einem Zeichen mehrere
Zeichen hernehmen, wenn die Bildgröße
00:15:15.040 --> 00:15:21.800
jetzt größer ist als hier quasi vorgesehen
ist. Ich glaub, das Limit ist irgendwo -
00:15:21.800 --> 00:15:28.290
das sind normalerweise alphabetische
Zeichen hier. Und hier sind die Features,
00:15:28.290 --> 00:15:34.860
die in Deutschland nicht eingesetzt worden
sind. Also das ist Geometriedaten,
00:15:34.860 --> 00:15:42.400
Vektorgrafiken in 2D und 3D. Das
österreichische System MUPID hat 2D-Grafik
00:15:42.400 --> 00:15:46.529
unterstützt, 3D weiß ich nicht ob es
irgendjemand unterstützt hat. Und hier
00:15:46.529 --> 00:15:53.080
Photographic Pixel und Table Data, das ist
quasi so eine Art Proto-JPEG, mit dem man
00:15:53.080 --> 00:15:56.710
dann Hintergrundgrafiken darstellen kann.
Die Idee dahinter war man hat quasi
00:15:56.710 --> 00:16:00.540
mehrere Ebenen - mehrere Bildebenen
hintereinander und immer wenn die
00:16:00.540 --> 00:16:06.120
vorherige transparent ist, wird die
dahinterliegende angezeigt. Und es gab
00:16:06.120 --> 00:16:09.741
auch - wobei das ich glaub nicht ganz
definiert war - die Möglichkeit Sound zu
00:16:09.741 --> 00:16:15.000
übertragen in so 80er-Jahre Codecs, die
dann so 720 Kilobit pro Sekunde gebraucht
00:16:15.000 --> 00:16:21.910
haben für gute Qualität - in Mono, mit
denen man heute auch im Prinzip dann OPUS
00:16:21.910 --> 00:16:25.950
machen könnte, wenn man neue Standards
machen würde. Telesoftware und
00:16:25.950 --> 00:16:31.779
Transparente Daten ist mehr oder weniger
selbst erklärend. Hier sind die Standards,
00:16:31.779 --> 00:16:37.220
wo die ganzen Details definiert sind. Es
gibt hier auch schöne Bücher dazu. Das
00:16:37.220 --> 00:16:41.800
Buch hier z. B. hat die Codesequenzen
drin. Und hier sind auch noch zwei
00:16:41.800 --> 00:16:48.670
Websites. Und ich möchte noch Philipp
Maier und Michael Steil noch danken dafür
00:16:48.670 --> 00:16:55.649
dass - die haben quasi die Software
geschrieben, die über der Link-Layer-
00:16:55.649 --> 00:17:00.280
Schicht läuft auf den Terminals beim
Vintage Computing drüben.
00:17:00.280 --> 00:17:04.379
Und hier sind noch meine Kontaktdaten.
00:17:04.379 --> 00:17:09.259
Herald: Ja vielen herzlichen Dank, einen
großartigen Applaus würde ich sagen!
00:17:09.259 --> 00:17:13.990
Applaus
00:17:13.990 --> 00:17:17.540
Herald: Da wir eben schon herausgefunden
haben, dass wir hier ein Fachpublikum vor
00:17:17.540 --> 00:17:22.810
uns sitzen haben, würde ich gerne darum
bitten, Fragen zu stellen. Wir haben jetzt
00:17:22.810 --> 00:17:27.710
noch 3, 4 Minuten Zeit für Fragen. Das
heißt, der eine oder andere kann jetzt das
00:17:27.710 --> 00:17:30.030
loswerden, was er immer schon
mal fragen wollte.
00:17:30.030 --> 00:17:34.970
Frage: In der Ankündigung hast du
geschrieben, dass du planst, das irgendwie
00:17:34.970 --> 00:17:40.090
jetzt wieder aufzubauen. BTX ist ja tot,
die Serverhardware ist wahrscheinlich
00:17:40.090 --> 00:17:45.020
komplett verschrottet worden, da gibt es
nichts mehr, aber man könnte quasi die
00:17:45.020 --> 00:17:49.190
Servertechnik emulieren, neu bauen.
Christian: Genau! Natürlich, wir haben
00:17:49.190 --> 00:17:54.300
tatsächlich auch im Vintage Computing die
Servertechnik emuliert. Was auch noch der
00:17:54.300 --> 00:17:59.460
Gedanke ist: die Clients werden jetzt auch
immer älter und immer kaputter. Man kann
00:17:59.460 --> 00:18:03.080
natürlich so was auch wunderbar in ein
Badge bringen, und dann hat man den
00:18:03.080 --> 00:18:06.700
Vorteil, man muss nicht mehr irgendwie die
Entwicklungsumgebung der Badge haben,
00:18:06.700 --> 00:18:09.970
sondern man kann einfach den kleinen
Serverdienst starten irgendwo auf einem
00:18:09.970 --> 00:18:15.140
Raspberry Pi, der irgendwo rum steht, und
dann mit einer kleinen Zehnertastatur,
00:18:15.140 --> 00:18:20.150
weil mehr braucht man für BTX für die
Bedienung nicht, dann Dienste nutzen, dass
00:18:20.150 --> 00:18:26.170
wir darüber quasi dann interaktive Dienste
haben kann, ohne dass man gleich eben sich
00:18:26.170 --> 00:18:33.220
einarbeiten muss in die Badge.
00:18:33.220 --> 00:18:35.750
Frage: Du hattest gesagt dass es Pläne gab
00:18:35.750 --> 00:18:43.060
für Hintergrundbilder von Laser Disc, gab
es denn da überhaupt schon - oder oder
00:18:43.060 --> 00:18:50.150
über Glasfaser - gab es denn da überhaupt
schon entsprechende Dateiformate? Also
00:18:50.150 --> 00:18:55.290
Laser - also für Bilder weiß es nicht, bei
Videos war es ja so, Laser Disk ist ja ein
00:18:55.290 --> 00:18:58.120
analoges Videoverfahren...
Christian: genau
00:18:58.120 --> 00:19:00.690
Frage: ... wie wäre das mit Video, mit
Bildern gewesen?
00:19:00.690 --> 00:19:05.700
Christian: Also es gab - mit Laser Disk
hätte man einfach ein Standbild genommen,
00:19:05.700 --> 00:19:13.290
das kann Laser Disc, und bei - also in
Singapur soll angeblich der Datenkanal von
00:19:13.290 --> 00:19:19.390
der Zentrale über Funk gegangen sein und
da war das dann quasi so ein JPEG-Format,
00:19:19.390 --> 00:19:24.210
das ist im Standard definiert, das ist
ungefähr JPEG.
00:19:26.500 --> 00:19:31.210
Herald: Und damit sind wir am Ende von
diesem Talk! Vielen Dank für eure
00:19:31.210 --> 00:19:34.410
Aufmerksamkeit, für eure Fragen und dir
Christian ganz herzlichen Dank für diesen
00:19:34.410 --> 00:19:36.800
super Vortrag! Einen herzlichen Applaus
noch mal!
00:19:37.190 --> 00:19:39.130
Applaus
00:19:41.180 --> 00:19:44.995
Abspannmusik
00:19:44.995 --> 00:20:04.000
Untertitel erstellt von c3subtitles.de
im Jahr 2019. Mach mit und hilf uns!