iX 4/2020
S. 6
Leserbriefe
April 2020

Leserbriefe April 2020

Kein Tutorial für die meisten Nutzer

(C++-Tricks: Speicherlecks finden; iX 3/2020, S. 132)

Also die allermeisten C++-Nutzer schreiben High-Level-Code, entweder direkt Anwendungscode oder anwendungsnahen Library-Code. Dort haben aber new und delete heutzutage nichts mehr zu suchen, sondern man nutzt fertige, funk­tio­nie­rende und gut getestete Container und Datenstrukturen aus der Standardbibliothek, aus Boost oder aus anderen Abstraktionsbibliotheken. Und – genauso wichtig – man nutzt sie richtig, also zum Beispiel mit make_shared(), statt shared_ptr selber anzulegen und zu initialisieren.

Ich finde, ein Tutorial, das sich an die breite Masse richtet, sollte erst einmal damit anfangen, was die meisten C++-Nutzer am meisten brauchen. new und delete gehören nicht dazu.

Ach ja, und wenn man tatsächlich Speicherlecks jagen muss (zum Beispiel weil man Legacy-Code hat, der von nackten new und delete nur so wimmelt – was ja leider häufiger vorkommt, als einem lieb ist), dann würde ich vorschlagen, existierende Memory-Leak-Checker zu benutzen, statt mühsam einen eigenen – durch Überladen von operator new und so weiter – nachzubauen.

Lars Rohwedder, aus dem iX-Forum

Layer 3 statt Layer 2

(RINA: Die Recursive InterNetwork Architecture RINA; iX 3/2020, S. 114)

Der ganze Protokollstack um TCP/IP ist nicht mehr zeitgemäß. Allein, dass Endgeräte ihre eigene Übersetzungstabelle (ARP-Tabelle) pflegen müssen und über gelernte Adressen Buchführung betreiben, ist ein konzeptioneller Blödsinn.

Dabei bin ich gar nicht so sehr gegen TCP/IP. Was mich am meisten stört, ist die Sicherungsschicht (Layer 2). Sie ist unnötig wie ein Kropf und bietet keinerlei Mehrwert beziehungsweise keinen Nutzen, den ich nicht auch auf Layer 3 abbilden könnte. Die MAC-Adressen sind weltweit eindeutig, was die physikalische Kommunikation unter den Geräten gewährleistet. Aber mit der Einführung von IPv6 mit 3,4 × 1038 Adressen könnte man OSI-Layer 2 komplett abschaffen. VLAN-­Tags könnte man ebenso auf Layer 3 anwenden, QoS über Layer 3 (DSCP), Fehlererkennung auf Layer 3 und so weiter. Auf Layer 2 gibts fast nix, was man nicht auch auf Layer 3 abhandeln könnte.

Marco Schmid, via E-Mail

Bei der Digitalisierung immer hinterher

(Editorial: Ende einer Legende; iX 3/2020, S. 3)

Da haben wir jahrelang drauf gewartet. Und jetzt, wo seit fünf Jahren Passwörter eh nicht mehr das Mittel der Wahl sind, weil 2FA mit FIDO endlich überall angekommen ist ... da hat das BSI ein Einsehen. Besser kann man die Probleme hierzulande bei der Digitalisierung nicht zusammenfassen.

Christoph Puppe, Berlin

Images auch für Hyper-V

(Cloud-Appliance: Vorkonfigurierte UCS-Images für Nextcloud, ownCloud und Seafile; iX 3/2020, S. 74)

Die UCS Core Edition wird auch für Hyper-­V angeboten. Wenn ich das Nextcloud-Image nicht kommerziell nutzen möchte, kann ich dann auch mit der UCS-Core Edition starten und aus dem UCS App Center das Nextcloud-Image laden?

Norbert Gießler, via E-Mail

Ja, das ist korrekt. Jeder Leser kann sich das für ihn am besten passende UCS-Image herunterladen und hat darüber auch Zugang zum App Center, über das er sich Nextcloud installieren kann.

Auch neu für erfahrene Nutzer

(RINA: Die Recursive InterNetwork Architecture RINA; iX 3/2020, S. 114)

Der Heise-News-Artikel zu RINA machte neugierig, enthielt aber wenige Infos. Daraufhin griff ich zum Heft, aber irgendwie kam ich mir nach dem Lesen und teilweisen Verstehen immer noch dumm vor. Totaler Netzwerk-Anfänger bin ich ja nun nicht (seit fast 30 Jahren im Internet unterwegs), aber ich konnte mir immer noch nichts recht vorstellen. Nachdem es meinem dienstältesten Guru genauso erging („mit Beispielen hat er sich arg zurückgehalten“), wusste ich, dass es nicht nur an mir lag.

Auch die englische Wikipedia-Seite war mir irgendwie noch zu hoch. Aber ich stieß auf einen sehr interessanten Vortrag (siehe ix.de/zrg8).

Da ist mächtig viel gebündeltes Fachwissen drin, doch man bekommt wenigstens eine bessere Vorstellung. Die Sache ist auf jeden Fall seriös und spannend und hat offensichtlich auch Zukunft.

Reinhard Wobst, via E-Mail

Schlechte Empfehlungen

(SAP-Security: SAP-Basiswissen – ein kleines Kompendium; iX 2/2020, S. 112)

Sie hatten ja letztens einen Artikel zum Thema SAP und Sicherheit – das scheint leider in der Realität nicht wirklich zusammenzupassen. SAP empfiehlt allen Ernstes, das Serverzertifikat mit privatem Schlüssel auf die Client zu kopieren. Wozu aktivieren die dann überhaupt noch die Verschlüsselung …?

Christoph von Wittich, via E-Mail

Ergänzungen und Berichtigungen

(iX vor 10 Jahren; 4/2020, S. 47)

Die Digital-Health-Messe ConHIT heißt seit letztem Jahr DMEA (Digital Medical Expertise & Applications).

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.

Der direkte Draht zu

Direktwahl zur Redaktion: 0511 5352-387

Redaktion iX | Postfach 61 04 07
30604 Hannover | Fax: 0511 5352-361
E-Mail: post@ix.de | Web: www.ix.de

Für E-Mail-Anfragen zu Artikeln, technischen Problemen, Produkten et cetera steht die Redaktion gern zur Verfügung.

post@ix.de
Redaktion allgemein
akl@ix.de
Alexandra Kleijn
ane@ix.de
Alexander Neumann
avr@ix.de
André von Raison
cle@ix.de
Carmen Lehmann
csc@ix.de
Carina Schipper
fo@ix.de
Moritz Förster
jd@ix.de
Jürgen Diercks
mdo@ix.de
Madeleine Domogalla
map@ix.de
Matthias Parbel
mfe@ix.de
Markus Feilner
mm@ix.de
Michael Mentzel
nb@ix.de
Nicole Bechtel
odi@ix.de
Dr. Oliver Diedrich
rme@ix.de
Rainald Menge-Sonnentag
sih@ix.de
Silke Hahn
sun@ix.de
Susanne Nolte
un@ix.de
Bert Ungerer
ur@ix.de
Ute Roos

Listing-Service:
Sämtliche in iX seit 1990 veröffentlichten Listings sind über den iX-FTP-Server erhältlich: ftp.heise.de/pub/ix/