ich möchte mich intensiver mit Embedded Systems und Echtzeitsystemen beschäftigen, finde aber den richtigen Einstieg nicht so recht.
Im Studium habe ich ein wenig mit ADA (Ravenscar-Subset) auf STM32-Boards gearbeitet. Als Hobby habe ich außerdem erste Erfahrungen mit dem ESP32 und FreeRTOS gesammelt sowie grundlegende Programmierung mit AVR und C ausprobiert.
Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt. Besonders ADA mit Ravenscar hat mir viel Spaß gemacht: Die Sprache wirkte auf mich sehr logisch, robust und durchdacht – auch wenn die Programmierung teilweise etwas umständlich war.
Ich bin mir unsicher, ob es sich lohnt, tiefer in ADA einzusteigen, oder ob meine Zeit in anderen Sprachen besser investiert wäre. Hat jemand von euch Erfahrung damit? Welche Sprachen und Tools werden heutzutage typischerweise für Echtzeitsysteme eingesetzt? Ist ADA noch relevant oder eher ein Auslaufmodell?
Beeindruckt hat mich z.B. dieses Projekt hier – eine kleine 2D-Physik-Engine in ADA:
https://github.com/Kidev/DemoAdaPhysics2D
Allerdings ist das verwendete Board auch schon über 10 Jahre alt und mit rund 50 € definitiv nicht das günstigste.
Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder ist es eher ein Relikt vergangener Tage?
Ich freue mich auf eure Meinungen und Erfahrungen!
Programmiersprachen kommen und gehen wie unterschiedliche Schraubendreher. Interessanter sind die Produkte, die nan damit baut. Wenn du irgendeine eine Programmiersprache drauf hast sammle damit Erfahrung. Diese auf eine andere Sprache umzusetzen, ist im Vergleich zu anderen Aufgaben eine der einfachen. Es ist besser, in wenigstens einer Programmiersprache sehr gut zu sein, als in vielen auf Anfänger Lebel.
Wie seht ihr das? Hat ADA noch eine Zukunft in der Embedded-Welt – oder
ist es eher ein Relikt vergangener Tage?
In der Embedded Welt hat derzeit nur ein Relikt vergangener Tage eine Zukunft und das heisst C. Vielleicht noch C++. Es gibt auch ein paar die bruellen jedem ins Ohr das die Zukunft Rust sein wird, aber solange die noch bruellen ist das sehr sehr unsicher.
Aber zum programmieren gehoert sehr viel mehr als eine Programmiersprache. Sowas ist nur eine austauschbare Grundlage.
Erster Post von einer Neuanmeldung. Ist denn heute schon Freitag? Ach ne, nur langes Wochenende.
Für diejenigen, die irgendwann später diesen Thread finden weil sie wirklich das Problem haben:
Als "Studierter" in der Softwareentwicklung sollte man mehr können und wollen als nur Kodieraffe zu spielen.
Programmiersprachen sind nur ein kleiner Teilaspekt der Softwareentwicklung. Man baut seine Karriere nicht um eine Programmiersprache oder ein Tool herum auf. Zumindest nicht als "Studierter" der Karriere machen will statt nur Kodieraffe zu sein.
Programmiersprachen sind Handwerk von denen man mehrere kann. Was gerade benötigt wird. Man ist in der Lage sich schnell noch eine weitere drauf zu schaffen wenn es gefragt wird.
Spezifisch für ADA:
ADA spielt sich hauptsächlich in Nischen in der Luft- und Raumfahrt und in der Verteidigung ab. Kurz: Fliegt und/oder macht Bum. In Programmiersprachen-Indizes wie TIOBE ist ADA aus gegebenem Anlass aufsteigend (aktuell Platz 15 in TIOBE, vor 12 Monaten noch 22. Langzeitkurve über Jahrzehnte allerdings absteigend [1]).
Aktuelle findet man auf https://de.indeed.com/q-ada-programmierung-jobs.html sechs "ADA"-Jobs. Bei gerade mal zwei scheint es wirklich um die Programmiersprache zu gehen. Dabei in beiden Fällen als "nett zu können" gewünscht, kein absolutes Muss. Branche? Fliegt und macht Bum.
Wenn man da hin will und dort in eine ADA-Nische, dann lernt man halt mal ADA. Das schreibt man unten in seine Bewerbung mit rein. Nach den anderen Fähigkeiten mit denen man glänzen möchte. Neben all den anderen Programmiersprachen die man kann.
__
[1] Programmiersprachen-Indizes sind mit Vorsicht zu genießen.
Habe die Kernaussage verstanden. Programmiersprachen sind Werkzeuge und und manche eignen sich besser für einen Job als andere. Und Tischler ist man nicht dann, sobald man die Kreissäge beherrscht.
Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten bot sich dieses Forum an.
ich möchte
hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das
richtige Werkzeug dafür.
Das Merkmal eines Hobbies ist das Fehlen der Sinnanforderung. Ob du da Basic, Assembler, ADA, oder Brainfuck verwendest, ist dein reines Privatvergnügen.
Hilfreich ist es aber in all den Fällen, daß es eine brauchbare und gut verfügbare Toolchain für die Hardware deiner Wahl gibt.
Abgesehen davon brauchts zum Entwurf eh gar keine Programmiersprache.
Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte
hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das
richtige Werkzeug dafür. In der Hoffnung Tipps von Experten zu erhalten
bot sich dieses Forum an.
Wenn du es hobbymäßig für dich alleine machen willst: tu es.
Wenn du dich mit gleichgesinnten austauschen willst: such mal nach "ADA" in Foren wie diesem. Dann siehst du, wieviele sich darüber mit dir potentiell unterhalten könnten/würden. Wenn du kaum Treffer bekommst, dann solltest du eher die Finger davon lassen. Verbreitet sind eben immer noch C, C++ und Assembler. <schulterzuck>
Welche Sprachen und Tools werden heutzutage typischerweise für
Echtzeitsysteme eingesetzt?
Auf der ganz harten Echtzeit im us-Bereich: C und C++. Wenn langsamer auch reicht: Java und Python. Aber in der Industrie programmiert kein Mensch in Ada.
Nun frage ich mich, welcher Weg langfristig am meisten Sinn ergibt.
Dann schau mal von deinem "habe ich im Studium kennengelernt"-Suppenteller auf in die weite Welt hinein. Dann stellt sich diese Frage ganz anders: Was willst du in 10 Jahren machen?
Anwendungen .. Weltraum, Hochsicherheit. Seltsamerweise nicht Automotive.
Der Vorteil von ADA ... stark typisiert und durchgesetzt. Mehrdeutige Konstrukte wurden definiert, resp entfernt, sodass der Code maximal Lesbar und sicher ist. Man kann sich darauf verlassen, dass der Code macht, was er soll. Kein uups, Klammer vergessen und nicht gesehen. Kein Eingerueckt und daher Kommentar. Mit extensiven Checks gleich eingebaut
zB
var u:integer range 0..10_000
// irgendwo muss natuerlich definiert werden was bei ueberlauf geschieht.
Und Ada unterstuetzt Tasks und parallele Konzepte direkt in der Sprache, ohne spezielle Konstrukte ohne Libraries.
task ABC is
entry READ( ..)
entry WRITE(..)
end;
task body ABC is
TABLE: ...
loop
select
accept READ( ...)
end
or
accept WRITE(...)
end
or terminate
end select
end loop
Wobei obiges Konstrukt einem WaitMultipleObject entspricht, welches sonst eine eher aufwendige Geschichte ist. Hinter einem "select" steht ein semaphorengeschuetzter Eingang, allenfalls auch eine Warteschlange.
Der Nachteil .. der Preis des Compilers. Es ist nahezu unendlich aufwendig einen Compiler zertifizieren zu lassen. Fuer die Compiler gibt es Testsuites, welche durchlaufen werden muessen. Bedeutet der Compiler passt auf den Controller. Konfigurationsfehler darf es natuerlich nicht geben.
Ich hab grad nachgeschaut, es gibt Referenzmanuals fuer 20$, zur Inspiration. Meins war noch eine Ecke teurer.
Ich empfehl ein Studium davon, ohne es einzusetzen. Mir war der Compiler damals zu teuer. Ich mag mich noch an etwas von gegen 10k erinnern, fuer einen 8086, wobei ein Turbopascal fuer 100$ erhaeltlich war.
Kodieraffe möchte plane ich nicht zu werden, sondern ich möchte
hobbymäßig qualitative, robuste Embedded Systeme entwerfen und suche das
richtige Werkzeug dafür.
Am Ende ist es Code in einer formalen Sprache. Ob Matlab/Simulink/Stateflow, C/C++ oder UML. Kodieraffen sind heute genauso selten wie Tippsen.
Und lass Dich nicht täuschen: Entwürfe in UML oder anderen "High-Level"-Sprachen sind oft eher vage Ideen unverstandener Genies.
Die Frage ist halt, was du damit machen willst.
David schrieb im Beitrag #7888657:
Welche Sprachen und Tools werden heutzutage
typischerweise für Echtzeitsysteme eingesetzt?
Auf die Allgemeinheit bezogen, C und C++. Oder ein Betriebssystem kommt drauf und dann wird 'ganz normal' programmiert.
Soweit ich mitgekriegt habe, wird ADA in besonders sicherheitskritischen Bereichen verwendet, weil es von sich aus schon ziemlich sicher ist. Rust könnte ADA vielleicht ablösen, hat sich aber bisher noch nicht eindeutig durchgesetzt.
Ich würde sagen:
Wenn du ADA besonders magst, programmier ADA.
Wenn du allgemein Embedded Systems programmieren willst, nimm C oder C++.
Wenn du in den Sicherheitsbereich gehen willst, informiere dich über ADA und Rust.
Ada (Merke, keine Abkuerzung, wie 'ADA' suggeriert) ist schon nicht so doof, und wird auch noch verwendet. Die Firma Adacore bietet immer noch eine gut gewartete Toolchain an und der gnat-Compiler tickert hier in der Continuous Integration.
Fuer die Hardware-Ansteuerung nehme ich dann aber doch lieber schlicht C, der Sprachenmischmasch laesst sich per Gnu-Compiler ja problemlos linken.
Aber wie schon gesagt Nische und nur fuer Safety-Geschichten sinnvoll, wo die Anforderungen entsprechend stehen. Sonst laesst sich auch ein C-Code entsprechend fuer Safety verifizieren.
Ist halt ein bisschen verbose/geschwaetzig, was gegenueber der Unlesbarkeit von Rust aber schon Vorteile beim re(verse)-Engineering hat. Siehe auch endlose Diskussionen zum verwandten VHDL.
Siehe auch endlose Diskussionen zum verwandten VHDL.
Wurde das nicht von System-C abgeloesst? Oder ist es in einer internationalen Welt wo alle cool auf English stehen nicht Zeit auf Verilog zu wechseln? :-p
Siehe auch endlose Diskussionen zum verwandten VHDL.
Wurde das nicht von System-C abgeloesst? Oder ist es in einer
internationalen Welt wo alle cool auf English stehen nicht Zeit auf
Verilog zu wechseln? :-p
Vanye
Ne dumme Frage:
Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich
beschreib ja damit ein Modell?
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
Danke an alle, die ihre Einschätzungen geteilt haben. Ich werde Ada vorerst ad acta legen und mir zunächst fundiertes Wissen zu Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen, wie man diese Systeme in C programmiert.
Ich denke, das ist langfristig einfach sinnvoller. Sobald die Wissensbasis vorhanden ist, kann ich mir mit Ada immer noch ein neues „Werkzeug“ erschließen.
Mir ist klar geworden, dass die Programmiersprache, in der man Embedded Systems entwickelt, nur einen kleinen Teilaspekt der gesamten Entwicklung ausmacht. ;)
Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich
beschreib ja damit ein Modell?
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es deutliche Überschneidungen. Zuweisungen, Bedingungen und Schleifen braucht man zum Beispiel in Beschreibungs- und Programmiersprachen. Da liegt dann die Ähnlichkeit.
Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich
beschreib ja damit ein Modell?
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es
deutliche Überschneidungen.
So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und
weniger die Semantik, die VHDL von Ada geerbt hat.
Ich werde Ada
vorerst ad acta legen und mir zunächst fundiertes Wissen zu
Mikrocontrollern, Embedded- und Echtzeitsystemen aneignen und lernen,
wie man diese Systeme in C programmiert.
Jaaa....
Das scheint mir ein brauchbarer Ansatz zu sein.
Wobei ich über ADA nicht viel sagen kann, außer dass es mir im Data General AOS/VS Umfeld begegnet ist. Da hatten "wir" einen solchen Compiler und ein paar ADA Anwendungen im Einsatz.
Also: Mehr als ein Seepferdchen ist da nicht dran.
Den Freischwimmer habe ich, ungefähr zur gleichen Zeit, auf DG/UX und SCO Xenix in C gemacht.
C++ ist erst viel später, mit Arduino, bei mir aufgetaucht.
Wie auch immer, ich empfehle mit C++ zu beginnen.
Es kann viele C Quellen einfach so mit übersetzen.
Zumindest kann man C Objekt Dateien recht problemlos in C++ Hauptprogramme linken.
C++ ist gegenüber C deutlich mächtiger, OOP, Templates, Operator Überladungen usw.
Verallgemeinerungen:
Wer C++ lernt, lernt die C Grundlagen gleich mit. Automatisch.
Wer einmal eine prozedurale Sprache (z.B. C) richtig gelernt hat, hat es meist mit der OOP viel schwerer, als wenn er gleich damit angefangen wäre.
Klarer: Der Paradigmenwechsel ist nur in eine Richtung leicht.
Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich
beschreib ja damit ein Modell?
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
Auch wenn die Konstrukte unterschiedliche Auswirkungen haben, gibt es
deutliche Überschneidungen.
So ist es. Es ist vor allem die (IHMO schreckliche ;-)) Syntax und
weniger die Semantik, die VHDL von Ada geerbt hat.
Obige Zeile ADA-Code führte 1996 zu einen Schaden in Höhe von mehreren hundert Millionen Euro. Und das obwohl derselbe Code all die Jahre zuvor es bestens tat und "seinem Schöpfer" in Lohn und Brot hielt.
Die Grund für diesen Zweck-Umkehr ist nicht im Code sondern im System (hier Wertebereich Sensor) zu suchen. Insofern biste mit "robuste Embedded Systeme" schon in der richtigen Richtung unterwegs. Und viel lernt man aus Fehlern. Also ist es eigentlich wurscht welche verschiedenen Programmiersprachen mal erlernt, Hauptsache man lernt was grundlegend Neues und füllt sich nicht mit kalten Kaffee ab.
Also mein Tipp ist daher, sich eher ein exotisches System zaufzubauen (bspw. DIY-PCB mit Padauk MCU) und from the scratch aka vom Datenblatt weg zu programmieren. Dann beginnt man, das System zu verstehen.
Ist VHDL und Verilog nicht ne "Zusammenbausprache", ich
beschreib ja damit ein Modell?
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
ADA und VHDL teilen sich die selbe Entstehungsgeschicht, beide stammen von Department of Defense der USA, resp. wurden von diesen als die von ihren "Zuliefern" zu verwendeten Sprachen vorgeschrieben. Und dienten zu Beginn hauptsächlich zur Überprüfung der Requirements (auf Vollständigkeit/Widersprüche/...) und weniger der endgültigen Implementierung.
Das man aus ADA wie aus Verilog/VHDL ausführbaren Code bekommt, wurde da eher als "Zugabe" verstanden.
ADA und VHDL haben beide auch bestimmte "Features" die reine Programmiersprachen nicht kennen, wie "ranges" (Wertebereiche/Teilmengen von Typen) und Konstrukte zu Modellierung parall ("concurrently") laufender Funktionen ("tasks" resp. "processes")
Wurde das nicht von System-C abgeloesst? Oder ist es in einer
internationalen Welt wo alle cool auf English stehen nicht Zeit auf
Verilog zu wechseln? :-p
Bei uns wurde es von Python abgeloest. System C wuerde ich als HDL jetzt eher als broken by design ansehen, ausserhalb akademischer Kreise gibt's wohl einige, die damit modellieren, aber fuers Engineering ist man wieder bei einer Low-Level-Transfersprache wie Verilog. VHDL wird von einigen FPGA-Herstellern fortschreitend stiefmuetterlicher unterstuetzt.
Ada ist ja ne Programmiersprache, kann man die trotzdem
mit VDHL vergleichen?
So wie Verilog/System Verilog riecht und schmeckt wie C, riecht und schmeckt VHDL wie Ada.
Auch viele Vor- und Nachteile (mangelnde Typsicherheit bei C, gefühlte Verbosität bei Ada) finden sich bei Verilog und VHDL wieder.
Immerhin scheint niemand etwas gegen PL/1 zu haben.
Ich hatte mal einen PL/9-Compiler ... das war eine Variation von PL/M, das wiederum auch irgendwie mit PL/1 zu tun hatte. PL/M wiederum führte zu CP/M.
(Ja, damals waren Schrägstriche der letzte Schrei, so wie später dann "2000" überall dranstehen musste)
Ehm..die Schraegstriche waren kein Schrei, sondern schlicht der amerikanische Marker fuer eine Abkuerzung. Also: Programming Language One, Control Program for Microcomputers...
Zum Thema Ada, VHDL und robuste Verifikation kann ich nur empfehlen, sich trotz allem negativem Geunke die ghdl-Toolchain von Tristan Gingold reinzuziehen. Das gehoert mitunter zum vorbildlichsten, nachhaltigsten Code der mir die letzten 20 Jahre untergekommen ist (unter Beruecksichtigung der unfassbaren Komplexitaet von VHDL).
Wird in der Digitalisierung unserer Gesellschaft immer wichtiger, robuste Systeme auch weit abseits DoD und Aerospace entwickeln zu koennen. Die Probleme, die mit dem Rust-Hype noch lange nicht abgefruehstueckt sind, deckt Ada lange schon ab.
Zugegeben, ich halte die Ada-Syntax fuer schwerfaellig, und VHDL ist eigentlich entsetzlich ineffizient, aber als Transfer-/Simulationssprache ist es immer noch geeigneeter als eine assemblerartige RTL.
Wenn es die zugrundelegenden Mechanismen erlauben, robusten Code, der ueber teilidiotische Ansaetze von statischer Analyse bis zu MISRA C hinausgeht, zu entwickeln, ist mir die Syntax relativ egal, solange sich im Klartext die Fehlerszenarien durchtickern lassen. Da ist v.a. die Lesbarkeit wichtig.
So als anekdotisches Beiprodukt: Um in Zeiten des sog. Fachkraeftemangels die Spreu vom Weizen zu trennen, wurde auch schon mal die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass man sowas heute alles neu in Java macht, und Assemblerprogrammierung schwer 80er ist, durfte er sein Koefferchen wieder schliessen.
die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten
Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass
man sowas heute alles neu in Java macht, und Assemblerprogrammierung
schwer 80er ist, durfte er sein Koefferchen wieder schliessen.
Ehrlich, einer mit soviel Verachtung für die Programmierarbeit seiner Mentoren hat "summa cum laude" bekommen ?! Das nennt man dann wohl "wegloben".
So als anekdotisches Beiprodukt: Um in Zeiten des sog.
Fachkraeftemangels die Spreu vom Weizen zu trennen, wurde auch schon mal
die Frage an einen 1-erKandidaten mit summa cum gestellt, ob er alten
Cobol-Code auf einer DEC VAX anfassen wuerde. Nach der Belehrung, dass
man sowas heute alles neu in Java macht, und Assemblerprogrammierung
schwer 80er ist, durfte er sein Koefferchen wieder schliessen.
P.S. Die Cobol-Frage war eine fiese Troll-Frage.
Mann, hier lesen bildet ungemein-
Ja, in unserer Welt gelten nicht Ehrlichkeit und Respekt untereinander,
sondern der beste Schauspieler gewinnt.
$1 Der Chef hat immer Recht!
§2 Sollte der Chef mal nicht Recht haben,
tritt automatisch §1 in Kraft! :-O
Was ist eigendlich mit dem russischen Offizier passiert,
der erkannt hat, das sein System spinnt, und die Atomrakete
Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!?
Nach der Belehrung, dass man sowas heute alles neu in Java macht, und
Assemblerprogrammierung schwer 80er ist, durfte er sein Koefferchen
wieder schliessen.
Heute können sich junge Softwareentwickler eben aussuchen, an welchen Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht.
Heute können sich junge Softwareentwickler eben aussuchen, an welchen
Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht.
Immer abhängig von der Hardware, die zur Verfügung steht. Und manchmal ist es halt eine DEC VAX die mal vor Unzeiten qualifiziert wurde und einfach so alles neuschreiben ist mancherorts sprichwörtlich ne Todsünde.
Apropos treffen, bei den vielen Zivilfliegern die von Militätraketen runtergeholt werden, fragt man sich, ob deren Programmierer auch solche Jungsporne sind, die nur Ballerspiele coden wollen. Und wenn was schief geht, alle Schuld auf den Projektleiter schieben.
Der Beitrag in der PC-World, auf den sich Der Standard hier bezieht, ist mittlerweile auch schon 15 Jahre alt. Ein Großteil davon dürfte mittlerweile nicht mehr wahr sein...
Heute können sich junge Softwareentwickler eben aussuchen, an welchen
Projekten sie mit arbeiten wollen. Er hat da nichts falsch gemacht.
Naja. Er hat:
sich als Topkandidat beworben
seine Art der Problemloesekompetenz demonstriert
Und viel aussuchen konnte er sich auch nicht mehr, da sich der Verdacht erschlich, dass er lange nur in einer akademischen Wohlfuehlumgebung 'funktioniert' hat. Waere nach dem PhD sein erster hands-on Job gewesen.
Das schreit nach Troll-Frage, auch wenn's gemein ist. Der Fall mit der Vax kam woanders her, das Ding steuerte ne Fabrikanlage.
Was ist eigendlich mit dem russischen Offizier passiert,
der erkannt hat, das sein System spinnt, und die Atomrakete
Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!?
S. Petrov? falls du den meinst, soweit ich mich erinnere, wurde er nicht ins Straflager geschickt, aber seine Karriere war vorbei, der Rest wurde totgeschwiegen. Bei Wiki immerhin ein laengerer Eintrag, der wohl stimmen wird.
Was ist eigendlich mit dem russischen Offizier passiert,
der erkannt hat, das sein System spinnt, und die Atomrakete
Ende der 80'iger Jahre NICHT auf Deutschland abgefeuert hat?!?
Nicht viel. Er wurde einerseits gelobt und andererseits für Fehler im Papierkram kritisiert. Letzteres wohl pro forma, weil eine Medaille zuviel Aufmerksamkeit auf das unzuverlässige System gelenkt hätte.
Nicht viel. Er wurde einerseits gelobt und andererseits für Fehler im
Papierkram kritisiert. Letzteres wohl pro forma, weil eine Medaille
zuviel Aufmerksamkeit auf das unzuverlässige System gelenkt hätte.
IMHO ein Beispiel des Absurden in der Russerei, gleichzeitig Held und Beweis für die Unfähigkeit der Vorgesetzten und des ganzen Systems. Arm das Land das Helden braucht.
