Der Datenverlust über Zeit/Verlust alter Hardware. Wie alte Medien einlesen?

In den Prozessoren und anderen Komponenten laufen ja ebenfalls diverse Dinge die für "Sicherheit" sorgen sollen.
Ja. UEFI ist sicherlich nicht das einzige Problem. Es folgt nur dem allgemeinen Trend der Komplexitätssteigerung.

Ich würde ja bei Geheimdiensten gerne mal in die Akten schauen
Die Geheimdienste haben übrigens auf der anderen Seite ein starkes Interesse daran, das in der von Ihnen verwendete Hardware solche Sachen wie Management-Engine etc. abschaltbar ist. :-)
 
Ja, diese Geheimdienstbackdoor ist meiner Meinung nach auch eher ein Gerücht. Welcher Geheimdienst hätte denn Interesse daran dass man einfach mal so jegliche Hardware kapern kann. Natürlich wird man den einen oder anderen Fehler der nicht trivial ist für sich behalten, aber Grundsätzlich hat ja ein Geheimdienst ein großes Interesse daran, dass die Geräte sicher sind. Denn die Backdoor die man selbst nutzen könnte, die könnte auch ein anderer nutzen oder das Wissen darüber gewinnbringend weitergeben.

Ganz davon abgesehen muss man ja nur auf facebook, Instagram und Twitter gehen. So was erleichtert die Arbeit... Die Stasi wäre froh gewesen wenn alle damals so leichtfertig persönliche Dinge gepostet hätten :)
 
Das das ne Backdoor ist würde ich so auch gar nicht behaupten. Allerdings ist es prinzipiell ja schon problematisch, da es ja jegliche Sicherheitsmaßnahmen aushebeln kann. Wenn da also mal z.B. ein Bug drin ist, hast Du ein ziemlich großes Problem. Das ist Anreiz genug es abschalten zu wollen.

Natürlich wird man den einen oder anderen Fehler der nicht trivial ist für sich behalten,
Nicht nur das. Die werden ja teilweise auch aktiv aufgekauft. Und zwar primär nicht deshalb, um sie zu fixen, sondern damit man einen Angriffspunkt beim Feind hat.
Damit nimmt man natürlich in Kauf das Geräte unsicher bleiben (die Lücke die durch WannaCry ausgenutzt wurde, war ja schon lange bei der NSA bekannt).

Man darf ja bei diesem Ankauf ja auch nicht vergessen, das der Verkäufer das einem ja vielleicht nicht exklusiv überlässt. Wenn er von "den Russen" nochmal kassieren kann, warum sollte er es dann nicht tun?

aber Grundsätzlich hat ja ein Geheimdienst ein großes Interesse daran, dass die Geräte sicher sind.
Im Sinne davon, das das Ausland nicht spionieren kann schon. Allerdings gibts ja durchaus auch ein Interesse daran, die eigenen Leute auszuspionieren (Inlandsgeheimdienst).

Ganz davon abgesehen muss man ja nur auf facebook, Instagram und Twitter gehen. So was erleichtert die Arbeit
In der Tat. Und das wird ja auch gemacht.
Nur kriegst Du damit halt nicht die Leute, die nicht gesehen werden wollen.
 
Wenn dich die aktuelle IT so ankotzt, dann mach doch was anderes. Kauf dir ein Bienenvolk oder züchte Orichideen. In jedem Post von dir mit Boomerrhetorik gegen die aktuelle IT schimpfen oder/und über das böse böse Management, kann doch nicht alles sein oder?
Naja, ich nenne das Verantwortungsgefühl.

IT wird ja so gut wie gleichgesetzt mit Innovation, und Innovation gilt jetzt offenbar unhinterfragbar als gut. Ich finde es hingegen auch wichtig zu fragen, ob eine Innovation sinnvoll und nützlich ist.

Darüberhinaus, wie hier am Originalthema ersichtlich wird, geht das ja immer weiter; es gibt nicht nur eine Innovation von non-IT nach IT, sondern die IT innoviert sich fortwährend weiter und überholt sich selbst - es reicht nicht, einmal was neues zu lernen, weil das neue nach ein paar Jahren schon wieder überholt ist. (In der Biologie zB nennt man soetwas, was aus sich selbst heraus ständig weiterwuchert, Krebs.)

Der Innovationshype wirft dann ein paar Fragen auf, die, wie ich finde, gestellt werden sollten. Z.B:
Ist es wirklich sinnvoll und nützlich, wenn Kinder im Vorschulalter statt einen Malbuch einen Gameboy (oder wie das heißt) kriegen?
Ist es wirklich sinnvoll und nützlich, wenn Kranke von einer KI statt von einem Arzt therapiert werden?
Ist es wirklich sinnvoll und nützlich, wenn die öffentliche Verwaltung in der Hauptsache online erfolgt, und der Zugang für Menschen ohne Computer erschwert wird?
Und dergleichen mehr.

Darüber mu8 man sich natürlich keine Gedanken machen, aber ich finde, man kann sich Gedanken darüber machen.
 
Naja, ich nenne das Verantwortungsgefühl.

IT wird ja so gut wie gleichgesetzt mit Innovation, und Innovation gilt jetzt offenbar unhinterfragbar als gut. Ich finde es hingegen auch wichtig zu fragen, ob eine Innovation sinnvoll und nützlich ist.
IT ist kein Selbstzweck, sie soll etwas vereinfachen/automatisieren, schlussendlich einem Unternehmen oder den Privatleuten "Dienen".
Ich glaube hier ausrechend an die freie Marktwirtschaft, dass sich kein Scheiß durchsetzt, wobei "kein Scheiß" nicht immer die technisch beste und sicherste Lösung ist. Es gibt nunmal auch Dinge wie Kosten/Wartbarkeit die in so eine Überlegung einfließen.

Es gibt auch genug IT Hypes die floppen, wie z.b. gerade das ganze Meta gedöns von Zuckerberg, auch wenn das natürlich eher Consumer Unterhaltungs IT ist.

Für meinen Teil sehe die großen Neuerungen der letzten Jahre (IAAS, Container, Cloud) als große Bereicherung, in vielen Teilen macht es das Leben einfacher. Und wenn es für einen Anwendungsfall nicht passt, MUSS man das ganze ja nicht verwenden. Man sollte nur als Verantwortlicher über alles bescheid wissen.

Darüberhinaus, wie hier am Originalthema ersichtlich wird, geht das ja immer weiter; es gibt nicht nur eine Innovation von non-IT nach IT, sondern die IT innoviert sich fortwährend weiter und überholt sich selbst - es reicht nicht, einmal was neues zu lernen, weil das neue nach ein paar Jahren schon wieder überholt ist. (In der Biologie zB nennt man soetwas, was aus sich selbst heraus ständig weiterwuchert, Krebs.)

Das ist glaube ich des Pudels Kern. Du willst nichts neues Lernen. Das muss man aber in fast jedem Job der halbwegs gut bezahlt ist. Auch ein Arzt lernt ständig neue Behandlungsmethoden, auch wenn die alten funktionieren, vielleicht sind die neuen billiger, weniger lethal oder unangenehm für den Patienten. Auch im Handwerk gibt es dauern Fortbidlungen und Schulungen. Selbst die Manager müssen sich mit neuen Wirtschafstheorien und dem Markt beschäftigen.

Der Innovationshype wirft dann ein paar Fragen auf, die, wie ich finde, gestellt werden sollten. Z.B:
Ist es wirklich sinnvoll und nützlich, wenn Kinder im Vorschulalter statt einen Malbuch einen Gameboy (oder wie das heißt) kriegen?

Davon abgesehen dass man heute keinem Kind mit nem Gameboy ne freude macht, aber setzen wir hier mal Smartphone ein. Wieso? Es ist wichtig sich früh mit der Technik zu beschäftigen, die Zukunft baut darauf auf. Nicht jedes Kind mag malen, ich hatte das auch immer gehasst. Ich bin jetzt kein Kinderpsychologe, aber ich denke solange andere Bereiche nicht zu stark in den Hintergrund geraten soll sich das Kind die Zeit vertreiben wie es Spass macht.
Wir haben früher mit Plastikpistolen "Krieg" gespielt, dass machen Kinder heute auch nicht mehr, ist dass jetzt schlimm? Oder sogar besser? Meine Eltern sind noch auf Pferden durch die Gegend geritten, wird heute auch nicht mehr gemacht. Dinge verändern sich eben.

Ist es wirklich sinnvoll und nützlich, wenn Kranke von einer KI statt von einem Arzt therapiert werden?

Ich wüsste nicht wo das gemacht wird, es gibt aber sehr wohl Studien die zeigen, dass KIs besser als Menschen sind z.b. Röntgenbilder oder CT Aufnahmen auszuwerten und Krebs und Co zu erkennen. Wieso also nicht wenn es besser als der Mensch ist?

Ist es wirklich sinnvoll und nützlich, wenn die öffentliche Verwaltung in der Hauptsache online erfolgt, und der Zugang für Menschen ohne Computer erschwert wird?
Und dergleichen mehr.

In 15 Jahren wirds keine Leute mehr geben die keine Ahnung von Computern haben. Es sei denn sie haben sich aktiv verweigert. In dem Falle selbst schuld.
Es wäre schon ein großer Schritt wenn mal alles online möglich wäre. Am besten mit freien Standards. Dann kann man immer noch den legacy Support für offline langsam auslaufen lassen.
Darüber mu8 man sich natürlich keine Gedanken machen, aber ich finde, man kann sich Gedanken darüber machen.
 
IT ist kein Selbstzweck, sie soll etwas vereinfachen/automatisieren, schlussendlich einem Unternehmen oder den Privatleuten "Dienen".
Ja, so hab ich das auch immer verstanden. Inzwischen heißt es aber, dass die Menschen bzw. die Gesellschaft "transformiert" wird, offenbar um der IT zu dienen.

Für meinen Teil sehe die großen Neuerungen der letzten Jahre (IAAS, Container, Cloud) als große Bereicherung,
Magst Du mir zeigen wo die Neuerung ist? Denn wenn ich mir das angucke, finde ich sie nicht. Okay, ich hab keine Container, weil FreeBSD keine unterstützt. Ich hab ein paar Maschinen in der Cloud, just for fun; das sind dann halt weitere Nodes im LAN die irgendwas machen können. Aber was ist das besondere dran - ausser dass ich sie mieten und kündigen kann wie ich will?

Das ist glaube ich des Pudels Kern. Du willst nichts neues Lernen.
Au, das ist nicht nur unfreundlich, sondern auch ganz falsch. Im Gegenteil, ich finde das Neue nicht, was zu lernen wäre!
Wenn immer etwas Neues auftaucht, lasse ich ihm erstmal ein, zwei Jahre Zeit, um sang- und klanglos wieder zu verschwinden - und vieles tut das. Und dann schaue ich es mir an, d.h. ich kämpfe mich durch den Jargon, bis ich das finde, was da wirklich die Funktion ist, und verstanden habe wie es genau funktioniert. Und das entpuppt sich dann meistens als nichts neues.

Machen wir's mal konkret am Beispiel: ich möchte pgadmin4 (das postgres-frontend) auf meinem BSD installieren. Und da gibt es keinen Port.
Ich will das auch nicht einfach auf den Desktop aufspielen, sondern als reguläre Server-Application irgendwo auf einem eigenen Node betreiben.
Schauen wir uns das Handbuch an: https://www.pgadmin.org/docs/pgadmin4/latest/server_deployment.html
Was man da findet, sind Beispielkonfiguriationen zum abtippen - die vielleicht funktionieren (oder auch nicht), WENN man eben das betreffende Environment hat. Was fehlt, sind die Erklärungen, was genau konfiguriert wird und welcher Parameter was tut, bzw. die Schnittstellendefinitionen. [Das bitte mal merken, das brauchen wir nachher noch.]
Nützen tut mir das soweit erstmal nichts, weil ich meinen eigenen Application-Stack habe und v.a. auch das pgadmin4 nicht auf demselben Node haben will wie den Webserver (das braucht nämlich MIT-Kerberos, während FreeBSD per default mit Heimdal-Kerberos lauft).

Dann gibt es zum Glück noch eine Seite für "Container Deployment": https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html
Das ist zwar im selben Stil gehalten (Configfile-Snippets zum Abtippen), aber da ist immerhin so viel Material, dass man sich die Schnittstellen, die man eigentlich braucht, allmählich zusammenreimen kann.

Und jetzt folgern wir zurück: was also ist "Container Deployment"? Ist es einfach eine korrekte Schnittstellendefinition, sodass die Applikation zu einer eigenständigen Einheit wird, die man dann beliebig plazieren kann?

Das wäre dann nichts neues, denn das haben wir im Unix schon immer so gemacht - deswegen ist unser Grafikbildschirm ja auch ein Server, der auf Port 6000 lauscht, und die Fenster selber können irgendwo anders gerechnet werden.
Gleichermaßen der LAMP-Stack: es gibt einen Node für die Datenbank, einen für die Anwendung, einen für den Webserver - und das sind ganz unabhängige Systeme. (Dass das Datenbank-Passwort der Anwendung durch einen gehackten Webserver erbeutet werden kann, ist schlichtweg unmöglich - wenn man sauber designt.)

Ich weiss nicht, warum man diesen Design-Stil, der ursprünglich Best-Practice war, irgendwann aufgegeben hat - aber offenbar hat man ihn aufgegeben, oder warum sonst wollte jemand auf meinem Webserver die Datei /mysql.initial.sql (und dergleichen mehr) lesen?

Die Schwierigkeit dabei ist natürlich diese: um solche Layouts korrekt zu designen, muss man erstmal verstehen wie die Anwendung wirklich funktioniert. Idealerweise sollte man auch die Protokolle, TCP/IP, HTTP, Datenbankabfrage, usw. (low-level) kennen und verstehen.
Und das ist offenbar nicht mehr Usus. [Das auch bitte mal festhalten.]

Davon abgesehen dass man heute keinem Kind mit nem Gameboy ne freude macht, aber setzen wir hier mal Smartphone ein.
Keine Ahnung wie die Dinger jeweils konkret heißen - sie haben gemeinsam, dass ihre Benutzer typischerweise nicht wissen, warum das Ding funktioniert oder was es eigentlich tut.
Und eben das halte ich für problematisch, denn...

Wieso? Es ist wichtig sich früh mit der Technik zu beschäftigen, die Zukunft baut darauf auf.
.. ein Kind will be-greifen (das ist etwas das wir mit den Fingern tun) - es will verstehen wie die Welt zusammenhängt und wie etwas funktioniert. Mit einem trix-Baukasten kann es das, mit einem Bildschirm wohl eher nicht.

Nicht jedes Kind mag malen, ich hatte das auch immer gehasst. Ich bin jetzt kein Kinderpsychologe, aber ich denke solange andere Bereiche nicht zu stark in den Hintergrund geraten soll sich das Kind die Zeit vertreiben wie es Spass macht.
Keine Sorge, hab ich auch gehaßt, ich bin halt nicht musisch begabt. Aber ich bin froh dass ich in meiner Zeit noch die Chance hatte, zu sehen wie man einen Computer selber bauen kann - notfalls aus einzelnen Transistoren, so wie Seymour Cray das gemacht hat.
Diese Chance hat die heutige Generation nicht mehr - die lernen nur noch, dass das Facebook heißt und man da ganz viel kaufen kann.

Ansonsten: Kinder brauchen die Zeit ja nicht vertreiben, weil sie von sich aus gar nicht zwischen Arbeit und Spiel unterscheiden, sondern da noch alles Lernen ist (und einfach das gelernt wird, was die Umgebung grad anbietet - ob das nun der Dorfbach ist oder der Baum auf den man klettert - und wie gesagt: lernen durch be-greifen, nicht durch im-fernseher-sehen). Wenn man ein Kind vor den Fernseher setzt, ist es ruhig, quengelt nicht und fragt nichts. Dass es dann auch Übergewicht und Aufmerksamkeitsdefizit hat, nunja, kann man halt nix machen.

In 15 Jahren wirds keine Leute mehr geben die keine Ahnung von Computern haben.
Das könnte man ebensogut andersrum formulieren: in 15 Jahren wird es keine Leute mehr geben die Ahnung von Computern haben. Computer werden überall sein, und keiner wird mehr wissen was die eigentlich alles tun.
Dein Auto ist jetzt schon eine Blackbox: es tut alles mögliche, aber das brauchst du gar nicht zu wissen, hauptsache es ist gut für dich. (Was gut für dich ist, bestimmen andere.)
Ja, und der Spezialist in der Werkstatt hat auch nur ein Handbuch, und das sieht genauso aus wie das was wir uns eben angeschaut haben - da steht auch nicht drin wie das alles eigentlich funktioniert, sondern nur: "wenn diese Anzeige, dann das eintippen".

Und jetzt frage ich Dich: das nennen wir dann "ständige Weiterbildung"? Ohne zu verstehen, was wir eigentlich tun?

Und um das klar zu sagen: ich bin keineswegs gegen Innovation, Fortschritt und Weiterentwicklung. Ich denke nur, dass da was wichtiges auf der Strecke bleibt: es wird immer mehr Abstraktion obenauf gepackt, und immer weniger Leute wissen, was da eigentlich wie zusammenwirkt.
Beispiel: eine Freundin von mir, jung, intelligent, ohne spezifisches Computerwissen, hat beschlossen, Java-Entwickler zu werden. Okay, nach einem halben jahr oder so war sie es. Nach ner Weile ist ihr das offenbar öd geworden, und sie hat beschlossen, sie will jetzt System-Architektin sein. Ja, dann hab ich mal ein bischen aufgezählt, was da -meines Erachtens- alles an Skills und Erfahrungen dazugehören sollte. Ihre Antwort: "aber das kann doch niemand!"
Und das ist jetzt schon wieder ein paar Jahre her - da war es also offenbar schon selbstverständlich, dass die ganzen Zusammenhänge gar niemand mehr kennt.

Andersrum wird eher ein Schuh draus: wenn man die Grundlagen und Zusammenhänge kennt, dann ist die ganze Innovation längst nicht so innovativ wie sie hingestellt wird. Denn die kochen alle nur mit Wasser.

Es wäre schon ein großer Schritt wenn mal alles online möglich wäre. Am besten mit freien Standards. Dann kann man immer noch den legacy Support für offline langsam auslaufen lassen.
Ich will auch dass die Sachen online verfügbar sind. Aber ich will im Fall des Falles auch einen Menschen ansprechen können, der da zuständig ist, und nicht mit einer Roboter-Hotline abgespeist werden, die nichtmal versteht worum es mir geht.
 
Ich sehe das bei weitem nicht so eng wie du. Ein Anwender, egal ob Sysadmin, Entwickler oder Nutzer muss nicht immer alles bis ins kleinste Detail verstehen. Wie auch in anderen Bereichen unseres Lebens: Werkzeuge werden moderner.

Ich muss nicht verstehen wie ein Transistor physikalisch funktioniert, ich muss nicht verstehen wie ein TCP/IP Paket erstellt wird, ich muss nicht verstehen was ein syscall für eine Auswirkung auf das Betriebssystem hat. Ich kann mich natürlich dafür informieren und es lernen, aber am Ende benutze ich z.B. für IPC ein Messagebus System und schreibe "sendMessage("Queue", "Message")", ob ich das nun Transistoren, TCP/IP oder Syscalls verstanden habe oder nicht.

Viele Leute meinten damals auch, sie hätten alles verstanden. Das Ergebnis ist, dass wir Betriebssysteme in C oder C++ geschrieben haben und auch heute noch schreiben. Über die letzten Jahrzehnte haben wir eine schier unfassbare Anzahl an Sicherheitslücken gefunden. Tja, der Entwickler, für wie toll und erfahren er sich gehalten hat, hat halt doch nicht alles verstanden. Er hat mehrere Fehler gemacht. Tausende Entwickler haben in Summe hunderttausende Fehler gemacht, hunderttausende Entwickler... ich denke du verstehst.

Warum haben Sie diese Fehler gemacht? Ihre Werkzeuge waren zu schlecht. Ihre Werkzeuge haben sie nicht darauf aufmerksam gemacht, dass das ein Fehler ist. Sie haben sie auch nicht davon abgehalten Programme mit fatalen Fehlern auszuliefern. Auch die darüberliegenden Workflows haben nicht dafür gesorgt, dass der Fehler keine Auswirkungen haben. Und das gilt sowohl für Software-Entwicklung, als auch die Inbetriebnahme dieser.

Und genau aufgrund dieser Tatsache haben wir das was wir jetzt haben, was du als "ist doch nichts neues" bezeichnest. Doch, ist es. Du verstehst nur den Grund dahinter nicht. Genauso wie die Entwickler damals nicht verstanden haben, dass sie gerade hunderte Sicherheitslücken produzieren.

tl;dr / Alternativ: Warum läuft ein simples Programm wie Ping in einer Sandbox: https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc
 
Zuletzt bearbeitet:
Das mit der Sicherheit ist wirklich ein Thema. Letztens hatten wir mit @Clas ja eine Diskussion das sich Linux in eine falsche Richtung entwickelt/entwickeln würde. Als langjähriger C++ Entwickler hatte ich auch zuerst meine Zweifel an dem Einzug von Rust in den Linux Kernel. Aber auch ich weis aus Erfahrung dass die C/C++ Sprachen ihre Stärken und Schwächen haben. Zuerst hatte ich mich auch geistig gegen Rust "gesträubt": "Was kann das was mein C++ nicht kann? Warum soll man das einsetzen?" Mittlerweile verstehe ich die Antwort.


2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.
While correlation doesn’t necessarily mean causation, it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code.

Ja. Was bedeutet das für uns Entwickler? Die Leute welche bei google arbeiten sind keine Heiligen oder Übermenschen. Die kochen wie wir alle auch mit Wasser und machen vielleicht die gleichen oder andere Fehler wie wir. Aber die Korrelation zwischen den Speicher Fehlern und dem neuen Code lässt sich nicht leugnen. Das bedeutet aber nicht das C/C++ überflüssig ist. Diese "neuen Sprechen" haben auch ihre eigenen Probleme und Beschränkungen. Was mich wirklich stört ist das Rust kein Iso Gremium hat und keine Spezifikation aka C++98/C++03/C++11. Auch gibt es nur eine Implementierung aber es wird an einer gcc Implementierung gearbeitet. Gui scheint auch noch so eine Baustelle zu sein ...

Meine eigenen Projekte sind noch alle C++. Ich werde versuchen mich weiter zu entwickeln und einen Blick auf "die andere Seite" zu bekommen.

Ich stimme in teilen @PMc zu aber auch @-Nuke- . Nur eines: Das Thema ist mittlerweile echt weit weg.... :ugly:
 
Nicht nur Linux bzw. Google wechselt bzw. führt ein. Auch Microsoft wechselt wo möglich von C/C++ zu Rust. Amazon und Facebook ebenso.


Teile von Windows sind sogar schon zu Rust portiert worden:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Ich habe mich vor ein paar Wochen auch mal wieder in C++20 eingearbeitet. Es ist meiner Meinung nach immer noch viel zu einfach Fehler zu machen. Es gibt einfach viel zu viele falsche Möglichkeiten Speicher zu allokieren. Sicherer C++ Code ist nicht Sprach-Standard, sondern ist von der Disziplin und Erfahrungen des Entwicklers abhängig. Und das ist fatal, völlig egal für was für einen Gott sich der C++-Entwickler hält. Darum halte ich C++ in Zeiten wo Rust existiert einfach für das völlig falsche Werkzeug. Nicht persönlich nehmen, ist nur allgemein gesagt.
 
Meine eigenen Projekte sind noch alle C++. Ich werde versuchen mich weiter zu entwickeln und einen Blick auf "die andere Seite" zu bekommen.

Statt dem Rust-Hype nachzurennen, wäre wohl ein Blick auf die bereits über 40 jährige Programmiersprache Ada angebrachter. Ein guter Einstieg in diese Programmiersprache bieten die zahlreichen e-Books auf der Webseite:

Ada wird gerne für "Safety"-Anwendungen empfohlen. Unter "Safety"-Anwendungen werden alle technische Einrichtungen verstanden, deren Fehlwirkung oder Ausfall direkt Menschenleben gefährdet.

So wird zum Beispiel in der Bahnnorm EN 50128 der Einsatz der Programmiersprache Ada mit "Highly Recommended" empfohlen. Der Einsatz der Programmiersprache C/C++ wird nur mit "Recommended" empfohlen. Die Gründe, weshalb C/C++ nur eine Empfehlung "Recommended" erhält, sind allgemein bekannt. Rust ist schlicht zu neu um Einzug in eine Bahnnorm zu erhalten.

Für erste Gehversuche mit Ada genügt der GNAT (GNU Ada Compiler)

Für den ernsthaften Einsatz von Ada ist der Einsatz von GNAT Pro zu empfehlen.

Für GNAT Pro wird der Einsatz einer unter "Platforms" aufgeführten Plattform empfohlen:

Beim Studium der für "Safety"-Anwendungen relevanten Normen und Empfehlungen, wie:

  • DO-178C
  • IEC 61508
  • EN 50128
  • ISO 26262
  • IEC 62304

wird jedem Programmier:in schnell klar, dass mit der guten Wahl der Programmiersprache noch lange kein für eine "Safety"-Anwendung genügend sichere Software geschrieben wird...
 
Ich sehe das bei weitem nicht so eng wie du. Ein Anwender, egal ob Sysadmin, Entwickler oder Nutzer muss nicht immer alles bis ins kleinste Detail verstehen. Wie auch in anderen Bereichen unseres Lebens: Werkzeuge werden moderner.

Ich muss nicht verstehen wie ein Transistor physikalisch funktioniert, ich muss nicht verstehen wie ein TCP/IP Paket erstellt wird, ich muss nicht verstehen was ein syscall für eine Auswirkung auf das Betriebssystem hat. Ich kann mich natürlich dafür informieren und es lernen, aber am Ende benutze ich z.B. für IPC ein Messagebus System und schreibe "sendMessage("Queue", "Message")", ob ich das nun Transistoren, TCP/IP oder Syscalls verstanden habe oder nicht.
Das ist doch okay. Dann bau uns einfach was schönes. :)

Und genau aufgrund dieser Tatsache haben wir das was wir jetzt haben, was du als "ist doch nichts neues" bezeichnest. Doch, ist es. Du verstehst nur den Grund dahinter nicht.
Okay, erklär mir den Grund.

Genauso wie die Entwickler damals nicht verstanden haben, dass sie gerade hunderte Sicherheitslücken produzieren.
Das ist ein Irrtum, die haben das sehr wohl verstanden. Ich erinnere mich, in den 90ern hat ein BSD-Entwickler mal ganz offen zugegeben, dass er seine Backdoor im Code hat (damit er noch in das System kommt wenn der Sysadmin sich ausgesperrt hat) - und das war okay.

Und ich denke nicht dass das ein Einzelfall war - das war eine ganz andere Mentalität - das war damals noch ein Wissenschaftsnetz. Da hatten alle Maschinen einer Uni noch ihre eigene IP und waren von überall erreichbar.
Der Trouble mit der Sicherheit kam erst ab 2000 mit der Kommerzialisierung - weil dann Geld im Spiel war. Da gabs dann was zu klauen.

Hätte man damals die Anforderungen von heute gehabt, dann hätte man auch schon die Werkzeuge anders formuliert. C ist einfach ein klasse Macro-Assembler, und das war es was man gebraucht hat. Es setzt voraus, dass man weiss wo die Bits und Bytes sind. (Wie sinnvoll es ist, so ein Werkzeug dann auf objektorientiert umzurüsten, sei mal dahingestellt. Wenn das jetzt Rust wird, dann ist das doch okay.)

Für die Militärs war das mit der Sicherheit schon vor 2000 ein Problem - die kamen dann mit ADA. Also haben wir die Ariane in ADA programmiert - und dann ist sie halt runtergefallen - und das war ein Fehler den so kein Programmierer im Code haben wollte.

Lessons not learned: Software, die Fehler vermeiden hilft, ist gewiß eine gute Sache, aber das eigentlich entscheidende, das worum es mir geht, erspart sie einem gerade nicht: nämlich die Grundlagen zu kennen, und zu verstehen und konsequent zu reflektieren wie das ganze zusammenhängt und zusammenwirkt.

Gelernt hat man diese Lesson leider nicht - sonst hätte es eine Boeing-max in der Form nicht gegeben - und da war dann nicht mehr nur Blech kaputt, sondern Menschen tot. Da hatte man auch wieder gedacht, wir sind ja auf der sicheren seite und die Software macht das schon recht.

Systemisch war beides derselbe Fehler: man hat die Schnittstellen und Zusammenhänge nicht genau genug angeschaut. Das ist etwas, was das bessere Softwaretool genuin nicht leisten kann, denn das kann auch kein mathematischer Beweis der logischen Verifizierung - der kann nur innerhalb des definierten Systems die Schlüssigkeit beweisen.

Und die Gefahr mit den besseren Softwaretools ist, dass man sich in einer trügerischen Sicherheit wähnt.
Dabei interessiert mich das mit den Sicherheitslücken und den Hintertüren gar nicht sehr; das ist eher was für Spion&Spion. Was mich interessiert ist: wie kann man IT so bauen, dass ich ihr mein Leben anvertrauen kann, und vielleicht auch das meiner Nachkommen. Sprich: interplanetary, interstellar...
 
Das ist ja das Problem an Rust etc pp. Man fühlt sich sicher aber kann auch riesen Mist bauen.

Die Wahrscheinlichkeit, dass man das tut ist im Vergleich zu C++ aber um mehrere Größenordnungen geringer.

Statt dem Rust-Hype nachzurennen, wäre wohl ein Blick auf die bereits über 40 jährige Programmiersprache Ada angebrachter.

Der Hype hat schon seine Begründung. Natürlich gab es auch vor Rust schon sichere Programmiersprachen. Java, Python, Ruby, ... alles "sichere" Sprachen, neben Ada. Ich halte dich natürlich absolut nicht davon ab deine Software in Ada zu schreiben. Nur zu. Ich würde nur gerne Leute davon abhalten Software in C oder C++ zu schreiben.

Rust wurde aber mit dem Ziel entwickelt in den Feldern zum Einsatz zu kommen, wo sonst nur C/C++ eingesetzt wird. Also alles bis runter zum Betriebssystemkern. Also genau das was man aktuell tut. Man braucht sich nur in das typische Speichermanagement von Ada einarbeiten, um zu sehen, warum bis heute keine Treiber in Ada für Linux entwickelt wurden. Darum gibt es z.B. das "unsafe" Keyword in Rust. Weil es eben manchmal nicht anders geht. Aber nur weil ich das für 3 Zeilen Code brauche, muss nicht gleich meine ganze Anwendung "unsafe" sein. Und ich muss auch nicht ein Großteil meiner Laufzeit-Performance opfern.
 
Zuletzt bearbeitet:
Okay, erklär mir den Grund.

Habe ich doch. Es erhöht auf mehreren Ebenen die Sicherheit. Neben der reinen Sicherheit, falls mal jemand einbricht. Sei es nun der Webserver der in einem Container läuft oder eben der "ping" Befehl, der vorsichtshalber in eine Sandbox gepackt wurde. Auch ein irre altes Tool. Funktionalität gibt's seit 1983. Hat auch 2022 noch Sicherheitslücken. Kurz prüfen in welcher Sprache es geschrieben ist.... C... na sowas. Zum Glück war man bei FreeBSD aber so weitsichtig und hat's nicht "wie immer" gemacht, sondern anders.

Arbeite dich doch einfach mal ins Thema Container und Sandboxing ein. Dass du das nicht verstanden hast, zeigt schlicht den Text den du dazu geschrieben hast. Ich kenne deine Denkweise, du bist nicht die erste "technisch abgehängte Person" mit der ich rede. Du willst alles auf das überführen, was du schon kennst. Wie dir schon vorgeworfen wurde. Du willst nicht lernen, du willst nur neuen Kram auf das Abbilden was du kennst. Das sehe ich schon daran, dass du einen Container als "das haben wir in Unix schon immer so gemacht" bezeichnest. Nein. Einfach nein. Deine Denkweise scheint auf irgendwelchen formellen Schnittstellen zu basieren und darum willst du alles darauf abbilden.

Sowas funktioniert aber nicht immer. Du blendest damit einfach nur alles aus was die Technologie ausmacht und darum siehst du auch "nichts neues": Du brauchst einen Anstoß deine eingesessenen Ansichten und Denkweisen mal zu durchbrechen. Das soll auch nicht böse gemeint sein.

Ich habe vor 2 Jahren auch einen neuen Job angetreten. Hauptentwickler der Anwendung waren auch alles so 40+. Ein Problem der Anwendung war/ist z.B. die Performance. Ich hatte das mal analysiert und Vorschläge gemacht, wie man diese verbessern kann. Man begegnete mir mit viel Misstrauen und auch Aussagen wie "das haben wir probiert, das hilft nicht"... ich musste ca. ein halbes Jahr rumnörgeln bis ich endlich mal das Go für die Umsetzung bekommen hatte und siehe da, ich konnte die Performance der Anwendung verzehnfachen. Warum konnte ich das? Weil es schlicht niemand korrekt probiert hat, alle waren in ihrer Denkweise festgefahren, haben "moderne" (in dem Fall nicht sooo modern) Ansätze nicht verstanden und standen denen allgemein misstrauisch gegenüber. Man hat's halt so gemacht wie man es immer gemacht hat...

Ich sollte auch mal einem 50+ jährigen Oracle DB Admin/Dev PostgreSQL erklären. Da habe ich auch gemerkt, er wollte nicht PostgreSQL lernen, er wollte wissen wie die Dinge, die er in Oracle tut in PostgreSQL macht. Er wollte auch nicht lernen was vllt. anders oder besser geht, er wollte einfach ein 1:1 Mapping seines Wissens haben. Und alles was sich so nicht mappen lies war scheiße und ein "Mangel in PostgreSQL".

Das ist ein Irrtum, die haben das sehr wohl verstanden.

Ich glaube nicht, dass du verstanden hast, was ich geschrieben habe. Denn das von dem du redest sind Fehler die entweder absichtlich, mangels Endkontrolle oder aufgrund fehlerhafter Spezifikation entstanden sind. Natürlich hält dich nichts davon ab bei der Implementierung logische Fehler zu machen.

Aber darum geht's nicht. Es geht darum, warum so viele gerade auf Rust umsteigen. Es vermeidet einfach eine große Menge an versehentlichen Fehlern, die immer und immer wieder in C oder C++ Programmen auftreten. Und es vermeidet sie, ohne eine Tonne Nachteile mit sich zu schleppen wie z.B. Java. Niemand will ernsthaft Treiber in Java oder Python schreiben. Aber Leute fangen an Treiber in Rust zu schreiben und es wird mehr. Warum? Weil die Vorteile die Nachteile überwiegen und das massiv.
 
Gelernt hat man diese Lesson leider nicht - sonst hätte es eine Boeing-max in der Form nicht gegeben - und da war dann nicht mehr nur Blech kaputt, sondern Menschen tot. Da hatte man auch wieder gedacht, wir sind ja auf der sicheren seite und die Software macht das schon recht.
Ursache für die Abstürze der Boeing 737 MAX war/ist eine fehlende Sicherheitskultur im Unternehmen (Boeing). Leider ein in der Praxis häufiges Problem bei der Entwicklung von "Safety"-Anwendungen => Profit versus Sicherheit.

Die fehlende Sicherheitskultur im Unternehmen Boeing führte zu einer mangelhaften Sicherheitsnachweisführung der Boeing 737 MAX. Siehe dazu dieses Video:
Das Thema Risikoanalyse und Sicherheitsnachweisführung wird im Video ab der 23. Minute behandelt.

Darum gibt es z.B. das "unsafe" Keyword in Rust.
Der Ariane 5-Absturz geht in Richtung "unsafe-Keyword". Da wurde bewusst eine Variable vom Programmier:in aus der Kontrolle auf Wertbereichsüberschreitung herausgenommen. Siehe dazu den amüsanten Golem-Beitrag:
 
Arbeite dich doch einfach mal ins Thema Container und Sandboxing ein.

Das ist schwerlich möglich: auf meinem BSD gibt es keine Container. Und der Tenor in der Szene ist auch nicht gerade so, dass man die unbedingt bräuchte.


Ich sollte auch mal einem 50+ jährigen Oracle DB Admin/Dev PostgreSQL erklären. Da habe ich auch gemerkt, er wollte nicht PostgreSQL lernen, er wollte wissen wie die Dinge, die er in Oracle tut in PostgreSQL macht. Er wollte auch nicht lernen was vllt. anders oder besser geht, er wollte einfach ein 1:1 Mapping seines Wissens haben. Und alles was sich so nicht mappen lies war scheiße und ein "Mangel in PostgreSQL".
Genau das kannst Du mit mir auch erleben, wenn Du mir ein Oracle in die Hand drückst: an allem was Oracle nicht so kann, wie ich es von Postgres gewöhnt bin, bist dann natürlich Du schuld. ;)
Und was hat das jetzt mit dem Alter zu tun?
 
Ursache für die Abstürze der Boeing 737 MAX war/ist eine fehlende Sicherheitskultur im Unternehmen (Boeing). Leider ein in der Praxis häufiges Problem bei der Entwicklung von "Safety"-Anwendungen => Profit versus Sicherheit.

Die fehlende Sicherheitskultur im Unternehmen Boeing führte zu einer mangelhaften Sicherheitsnachweisführung der Boeing 737 MAX.
Das Thema Risikoanalyse und Sicherheitsnachweisführung wird im Video ab der 23. Minute behandelt.
So kann man das natürlich politisch korrekt auch ausdrücken.
Ich hab es mir von Piloten erklären lassen - das sind die die es in erster Linie angeht - und die sehen das mit dem instabilen Airframe etwas anders. Keine Ahnung wer nun recht hat, aber das ist ja nur der erste Klopper hier. Der zweite ist die dilettantische Umsetzung. Der dritte dann, dass man den Piloten (der ja letztlich die Verantwortung hat) gewaltsam entmündigt. Und der vierte ist, dass soetwas offensichtlich durch den ganzen Apparat an Überwachungen und Behörden usw. glatt hindurchgeht.
Wenn das nicht reicht, weiss ich auch nicht. Ich denke eher, wenn das nun ein Einblick in die Arbeitsweise unserer HiTech Industrie ist, dann sollte man eigentlich Angst kriegen.
(Soviel ich weiss, hat der Airbus bislang noch einen AUS-schalter für die KI. Aber ob der funktioniert?)
 
Die Wahrscheinlichkeit, dass man das tut ist im Vergleich zu C++ aber um mehrere Größenordnungen geringer.
Ich glaube das ist nicht mal so unwahrscheinlich. Jemand der seine Sprache umstellt hat noch seine alte Denkweise. In meinem Buch das gerade lese heißt es:
You have to use a smart pointer type, such as Rc, and interior mutability—a topic we haven’t even covered yet. Rust prefers for pointers, ownership, and data flow to pass through the system in one direction, as shown in Figure 5-11. Figure 5-11. A tree of values The reason we bring this up right now is that it would be natural, after reading this chapter, to want to run right out and create a “sea of structs,” all tied together with Rc smart pointers, and re-create all the object-oriented antipatterns you’re familiar with. This won’t work for you right away. Rust’s ownership model will give you some trouble. The cure is to do some up-front design and build a better program.
Wenn die Designphase überspringe und direkt Code schreibe, kommt in jeder Sprache mist raus. Dann werden Stolpersteine so gelöst

Code:
static mut STASH: &i32 = &128;
fn f(p: &i32)
{
  // still not good enough 
  unsafe {  STASH = p;  }
}
 
Es geht doch bei Rust gar nicht darum, spezialisierte Sprachen für Anwendungen höchster Anforderungen an garantiert korrekte Funktion wie eben die genannte Steuersoftware von Flugzeugen, Raketen und ähnlichen Dingen zu ersetzen. Dort ist die Sprache bzw. das genutzt Framework sowieso nur die Kirsche aus dem Eis, der ganze Entwicklungsprozess ist ist hoffentlich auf diese speziellen Anforderungen zugeschnitten und entsprechend aufwändig.

Stattdessen ist das sozusagen Ziel von Rust, den hunderttausenden bis Millionen Entwicklern von Wald- und Wiesen-Code dort draußen ein Werkzeug an die Hand zu geben, welches die unendlichen Probleme mit Speichermanagement und Nebenläufigkeit / Threading von C / C++ drastisch abmildert. Das heißt auch, dass man oftmals nicht eine ganze alte und entsprechend komplexe Anwendung in Rust neuschreiben muss. Oft reicht es schon, besonders kritische Teile wie beispielsweise in C / C++ immer sehr spaßigen Parser aller Art zu ersetzen, um seine Angriffsfläche drastisch zu verkleinern und Programme robuster zu machen. Nicht zuletzt war einer der ersten großen Einsatzzwecke von Rust der Adressparser und später der CSS-Parser vom Firefox. Oder als anderes Beispiel der von @-Nuke- genannte Windows Fontparser...

Man wird auch den Linux-Kernel nicht in Rust neuschreiben. Stattdessen wird Rust sehr wahrscheinlich in der ersten Zeit ebenfalls vor allem in Bereichen eingesetzt werden, wo Eingaben geparst werden müssen oder komplexe Nebenläufigkeiten implementiert sind. Vielleicht wird Rust C / C++ auf lange Sicht bei Neuprojekten verdrängen, dass wird aber eine Entwicklung über Jahre bis Jahrzehnte sein. Und selbst wenn, gibt es genug C / C++ Code dort draußen, dass eine Myriade Entwickler genug für ihr restliches Berufsleben zu tun hat. Dagegen ist COBOL ein Witz.
 
Wenn der Einsatz der Programmiersprache C unvermeidlich ist, wären wohl (auch für "Wald- und Wiesen-Code") einige Gedanken zum Einsatz von Programmierstandards wie:


angebracht. Zu diesen Programmierstandards ist auch ein entsprechendes Pendant für die Programmiersprache C++ erhältlich. Für die Kontrolle der Einhaltung der oben genannten Programmierstandards sind zahlreiche (kommerzielle) Produkte erhältlich.

Dort ist die Sprache bzw. das genutzt Framework sowieso nur die Kirsche aus dem Eis, der ganze Entwicklungsprozess ist ist hoffentlich auf diese speziellen Anforderungen zugeschnitten und entsprechend aufwändig.
Programmierstandards wie MISRA-C sind bildlich dargestellt Teil der "Sahne zur Kirsche".
 
Programmierstandards wie MISRA-C sind bildlich dargestellt Teil der "Sahne zur Kirsche".
Es gibt ja MISRA-C++ 2008 und auch JSF C++ (Der Guide welcher für die F35 verwendet wurde). MISRA-C++ ind der JSF-C++ unterscheiden sich in einigen Punkten bzw. widersprechen sich. Wenn man sich aber immer weitergebildet hat und "sicheren" Code schreiben wollte hat man vieles schon gemacht.
 
Und was hat das jetzt mit dem Alter zu tun?

Naja, ältere Leute arbeiten typischerweise schon länger als jüngere und sind "eingesessener" in ihren Denkweisen. Und wenn ich 50+ schreibe, weiß man grob wie lange diese Person schon im Berufsleben sein könnte.

Wenn die Designphase überspringe und direkt Code schreibe, kommt in jeder Sprache mist raus. Dann werden Stolpersteine so gelöst

Code:
static mut STASH: &i32 = &128;
fn f(p: &i32)
{
  // still not good enough
  unsafe {  STASH = p;  }
}

Ja und eine weitere Person schaut jetzt auf den Code und braucht gar nicht erst überlegen ob dieser ggf. "unsafe" ist. Es steht direkt im Code, dass das der Fall ist.
Es geht nicht einfach so wie in C oder C++, es ist direkt vorgesehen, dass Dinge nicht gehen. Es ist eben unsicher. Und du kannst jetzt hinterher einfach deinen Sourcecode nach "unsafe" greppen und schon findest du mögliche Probleme.
Man braucht auch gut ein Großteil dieser ganzen C/C++ Guidelines für sichere Programmierung nicht, weil es in sicheren Programmiersprachen von Haus aus so nicht geht. Natürlich nicht alles, weil in solchen Guidelines auch sowas wie die Variablenbenennung oder Klammerung steht.
 
In 15 Jahren wirds keine Leute mehr geben die keine Ahnung von Computern haben. Es sei denn sie haben sich aktiv verweigert. In dem Falle selbst schuld.
Solche Prognosen sind regelmäßig falsch. Als der erste Computer lief, da wurde gesagt es gibt kein Bedarf Weltweit für mehr als fünf Stück oder so. Seit dem ersten Heimcomputer soll quasi alle 5 Jahre in jedem Haushalt mindestens ein Computer stehen. Das hat die letzten Jahrzehnte ja nun nicht geklappt. Ich weiß nicht warum es dieses Jahrzehnt anders laufen sollte.

Egal wie man es dreht und wendet, ein Computer ist zum Leben auch heute nicht notwendig. Er macht das Leben zwar in vielen Bereichen einfacher, aber es geht auch ohne genau so gut. Es gibt nicht wenige Familien die auch nicht die finanziellen Möglichkeiten haben für eine Ausstattung mit Internet.

Dazu kommt dann noch der Lauf der Dinge. Je älter man wird, desto weiter rückt Technik in den Hintergrund. Natürlich gibt es auch Senioren die Technik im hohen Alter entdecken und gerne nutzen, aber die Mehrheit reduziert die Nutzung im fortschreitenden Alter. Ich merke es ja selbst wie es sich verändert. Früher jeden Trend mitgemacht und nicht verstanden warum nicht alle die Möglichkeiten nutzen. Heute denke ich mir eher: Warum soll ich mich damit befassen, es geht ja auch jetzt und wenn ich eh in der Stadt bin, dann kann ich noch dieses und jenes gleich mitmachen und ein Mensch kann bei Fragen besser antworten als ein Formular.

Technik wird zumindest absehbar nichts sein was jeder überall zur Verfügung haben wird.
 
Ich denke, man muss sehen, dass die Lücke zwischen "einen Computer benutzen" und "einen Computer verstehen" mit zunehmender Verbreitung und fortschreitendem technischen Fortschritt immer größer wird. Am Anfang war jeder Computerbenutzer ein Hardwaremensch und ein Programmierer. In absehbarer Zukunft werden wir den Punkt erreicht haben, dass jeder weiß, was ein Computer ist und der absolute Großteil aller Menschen einen Computer bedienen kann. Wie der Computer funktioniert, wird und muss aber kaum mehr einer davon wissen.

Als schlechte Analogie der gute, alte Autovergleich: Wer im Jahr 1905 Auto fuhr, war meist Mechaniker, der sein Fahrzeug technisch komplett verstanden hatte. Im Jahr 2022 weiß jeder, was ein Auto ist und ein Großteil der Menschen hat ein Führerschein, aber nicht zwingend ein gleiches Auto. Das Auto reparieren kann und wieder muss aber kaum einer davon.

Das ist einfach der Lauf der Dinge. Nicht jeder kann und muss alles verstehen, verbreitete Dinge nutzen zu können, reicht aus. Die Fähigkeit des Menschen, dass sich einzelne Individuen auf grundverschiedene Dinge spezialisieren können, unterscheidet uns von Tieren und hat uns ermöglicht die Zivilisation zu entwickeln.
 
Zurück
Oben