ZFX + Developia

Faszinierender Artikel :) allerdings finde ich "social engineering" viel bedrohlicher... Cosmo, the Hacker ‘God’ Who Fell to Earth ist zwar recht pathetisch geschrieben, aber die Bedrohung durch "social engineering" wird schnell deutlich, insbesondere im Angesicht totaler Überwachung der Kommunikationskanäle.

Und wo bekomme ich Hardware her bei der ich weiß was sie macht? Ich weiß das es Open Source Hardware gibt... aber ich wüsste nicht das die einen gängigen PC ersetzen könnte, und falls doch wird es wohl nur von 0,0000001% aller Leute gemacht. Wenn ich einen Open Source Nvidia-Treiber nutze, kann die Hardware ja immer noch Hintertüren haben/öffnen. Bei einer Grafikkarte ist das vielleicht nicht so einfach (vielleicht sogar unmöglich... keine Ahnung wie gut man dort solchen Unfug unterbringen könnte), aber auf einem Mainboard, in einer Netzwerkkarte oder einem BIOS/UEFI könnte man wahrscheinlich ganz gut eine "Zustatzfunktion" verstecken die z.B. einen Keylogger und Remote-Zugriff auf dessen gesammelte Daten implementieren, oder Infos zum Netzwerkverkehr weiterleitet. Das ist schon sehr paranoid, und ich erwarte das jetzt nicht unbedingt. Aber wenn man glaubt sich mit mit freier Software komplett absichern zu können, dann ist man meiner Meinung nach im Irrtum (auch wenn es ein sinnvoller Schritt ist und die Sicherheit deutlich erhöht). Selbst wenn man jede Codezeile selbst gelesen und nachvollzogen hat und sie dann mit einem handgeschriebenen Compiler kompiliet hat (den man vorher in Maschienencode direkt auf die Festplatte gemeißelt hat damit der Compiler mit dem man den selbstgemachten Compiler kompiliert nicht doch wieder eine Hintertür einbaut :) ), so hat man immer noch keine Sicherheit das man auch der Hardware vertrauen kann.
Vielleicht könnte man auch einfach absichtlich "Bugs" in der Hardware anlegen um Schwachstellen in den gängigen Treiber-Implementierungen zu öffnen... ich denk es gibt viele Möglichkeiten. Bei Geräten aus einem Guss (Router, Smartphones, ...) die immer online sind dürfte die Sache sogar noch weitaus einfacher sein als bei einem PC.

Ja; das sagen auch die gängigen Verschwörungstheorien die behaupten, der Zufallszahlengenerator von Intels Sandy-Bridge hätte eine NSA-Hintertür.

>> Auch Open Source sagt nichts über Sicherheit aus so lange du nicht den Compiler von Hand geschrieben hast.
>>>> Der Compiler sollte natürlich auch freie Software sein. Aber wenn man cl nutzt... :P.
>>>> Achtung: freie Software != open source Software.

Es gibt freie Treiber und BIOS/EFIs :). Wenn, dann müssten sie das schon "echt" in die Hardware einlöten.
Ob das wirklich so geht, wie du dir das vorstellst.. ich weiß nicht. Die CPU hat doch erstmal (ohne die Nutzung jeglicher Software) keine Ahnung davon, mit welchen Netzwerktreibern und -karten sowie mit welchen Motherboards es zu tun hat, was aber vermutlich Voraussetzung ist. Ähnlich verhält es sich mit dem Betriebssystem, schließlich sind die entsprechenden Calls für eine Netzwerkverbindung bei Windows nicht die selben wie bei einem POSIX-Konformen System.

Lies den Link. Tipp: Auch dein freier Compiler muss mit irgendeinem Compiler übersetzt worden sein, den du höchstwahrscheinlich nicht Maschinenbefehl für Maschinenbefehl verfiziert hast. Du kannst also auch nicht annehmen, dass deine selber übersetzten Programme tun, was ihr Quelltext vorschreibt.

GCC wird doch auch mit GCC compiled? ;)

"You simply tell it once, then you can use this self-referencing definition"
[...]
"Such blatant code would not go undetected for long. Even the most casual perusal of the source of the C compiler would raise suspicions."

Ein bisschen weiter lesen, dann sollte der Groschen fallen.
Der Compiler, der den Compiler kompiliert, ist ja schon kompiliert. Du hast keine praktische Möglichkeit nachzuprüfen, ob der Compiler nicht beim Compiler kompilieren den Trojaner in die nächste Version des Compilers reinkompiliert (und der kann das dann bei der nächsten Version tun).

Genau. Vor allem gibt es keine Möglichkeit mehr, über den Quelltext nachzuvollziehen, ob der Compiler so einen Trojaner einfügt oder nicht. Da könnte 2002 mal eine Version mit infiziert worden sein und man würde es nicht merken.

Bei dem Umfang moderner Software lässt sich z.B. ein selbstfortpflanzender Trojaner, der die für AES-Verschlüsselung typische Befehlsfolge durch Leerlauf ersetzt, beliebig gut verstecken. Dann wäre dein TrueCrypt kompromittiert obwohl du den kompletten Quelltext gelesen und mit einem Compiler übersetzt hast, dessen Quelltext du ebenfalls gelesen und selber kompiliert hast.

Die einzige Möglichkeit, den zu finden, wäre eine Analyse der Maschinenbefehle. Und die ist – oh Wunder – bei Closed Source Software ähnlich schwierig (ohne hier einen Streit über die Details vom Zaun brechen zu wollen).

Und danach geht es weiter mit Sternmulls Einwänden wie, dass der Microcode deines Prozessors kompromittiert sein könnte und er garnicht die Befehle ausführt, die du ihm vorschreibst. Klingt abwegig; aber bis vor ein paar Wochen war es auch abwegig, dass eine Behörde die ganze Welt überwachen könnte.

Verstehe :)

Krishty hat geschrieben:Bei dem Umfang moderner Software lässt sich z.B. ein selbstfortpflanzender Trojaner, der die für AES-Verschlüsselung typische Befehlsfolge durch Leerlauf ersetzt, beliebig gut verstecken. Dann wäre dein TrueCrypt kompromittiert obwohl du den kompletten Quelltext gelesen und mit einem Compiler übersetzt hast, dessen Quelltext du ebenfalls gelesen und selber kompiliert hast.

Das würde nicht gehen weil der Truecryptcontainer dann inkompatibel zu korrekt kompilierten Versionen wäre. Das dürfte recht bald auffallen. Aber man könnte vielleicht was einbauen das alle in Truecrypt eingegebenen Passwörter irgendwo hinterlegt (vielleicht versteckt in einem ungenutzten Bereich des Containers selbst). Aber das ist zugegebenermaßen nebensächlich weil es hier ja nicht um die potentielle Funktionalität des Schadcodes ging sondern um die Möglichkeit solchen unentdeckt unterzubringen.

Krishty hat geschrieben:Und danach geht es weiter mit Sternmulls Einwänden wie, dass der Microcode deines Prozessors kompromittiert sein könnte und er garnicht die Befehle ausführt, die du ihm vorschreibst. Klingt abwegig; aber bis vor ein paar Wochen war es auch abwegig, dass eine Behörde die ganze Welt überwachen könnte.

Aus ählichem Grund wie beim Truecrypt-Trojaner müsste sich die CPU (oder was auch immer manipuliert wird) schon kompatibel zu der nicht manipulierten Version verhalten. Aber ich könnte mir ganz gut vorstellen das man einem Mainboard mit onboard-Netzwerkkarte ein kleines "Extra" verpasst das Netzwerkpakete und Tastatureinbaben an eine ander Maschine übers netzwerk schickt. Das könnte man z.B. durch ein spezielles Netzwerkpaket von außen aktivieren. Es würde also auch keiner entdecken bis irgendwann jemand den Netzwerkverkehr analysiert während das Ding grad aktiv ist. Die Informationen könnten auch erst mal auf einem ungenutzten Bereich der Festplatte abgelegt und irgendwann gebündelt verschickt werden... ich denk es gibt diverse praktikable Wege um Hintertüren in Hardware einzubauen.

Sternmull hat geschrieben:

Krishty hat geschrieben:Bei dem Umfang moderner Software lässt sich z.B. ein selbstfortpflanzender Trojaner, der die für AES-Verschlüsselung typische Befehlsfolge durch Leerlauf ersetzt, beliebig gut verstecken. Dann wäre dein TrueCrypt kompromittiert obwohl du den kompletten Quelltext gelesen und mit einem Compiler übersetzt hast, dessen Quelltext du ebenfalls gelesen und selber kompiliert hast.

Das würde nicht gehen weil der Truecryptcontainer dann inkompatibel zu korrekt kompilierten Versionen wäre. Das dürfte recht bald auffallen. Aber man könnte vielleicht was einbauen das alle in Truecrypt eingegebenen Passwörter irgendwo hinterlegt (vielleicht versteckt in einem ungenutzten Bereich des Containers selbst). Aber das ist zugegebenermaßen nebensächlich weil es hier ja nicht um die potentielle Funktionalität des Schadcodes ging sondern um die Möglichkeit solchen unentdeckt unterzubringen.

Ja; genau. Die RNGs oder der Passwort-Hash wären viel einfachere und unauffälligere Angriffspunkte. Aber war ja, wie gesagt, nur exemplarisch.

Krishty hat geschrieben:Und danach geht es weiter mit Sternmulls Einwänden wie, dass der Microcode deines Prozessors kompromittiert sein könnte und er garnicht die Befehle ausführt, die du ihm vorschreibst. Klingt abwegig; aber bis vor ein paar Wochen war es auch abwegig, dass eine Behörde die ganze Welt überwachen könnte.

Aus ählichem Grund wie beim Truecrypt-Trojaner müsste sich die CPU (oder was auch immer manipuliert wird) schon kompatibel zu der nicht manipulierten Version verhalten.[/quote]Naja; ich brauche ja „nur“ ein paar Code-Bytes mit so einem Alleinstellungsmerkmal wie dem Versatz des Anweisungszeigers vom Beginn der aktuellen Seite oder spezieller Registerinhalte kombinieren. Es ist reichlich unwahrscheinlich, dass 08/15-Anwendungen die Anweisungsfolge einer Krypto-Anwendung an gleicher Position aufweisen.

Krishty hat geschrieben:Ich war jung. Ich habe die Leute reden gehört:

    „C ist besser als C++, weil ich mir eine Zeile C ansehen kann, und weiß, was sie tut“.

Dann dachte ich mir:

    „Idioten. Nur, weil sie nicht kapiert haben, dass dynamic_cast<void *>() immer die speziellste Klasse zurückgibt.
    Nur, weil sie nicht kapiert haben, dass in der Zeile da überladene Funktionen Vorrang vor Template-Funktionen haben.
    Nur, weil sie nicht kapiert haben, dass die Template-Metakonstruktion in der Zeile da immer das optimalere von Pass-by-Value oder Pass-by-Reference auswählt.
    Nur, weil sie nicht kapiert haben, dass …“

Mittlerweile bin ich klüger: Ich will kein C++ mehr sehen. Ich will nie mehr mit jemandem zusammenarbeiten, der C++ benutzt. Ich werde meine C++-Kenntnisse ab jetzt nicht mehr erweitern sondern die Energie nur noch in LLVM Assembly stecken.

    @.fcs = private unnamed_addr constant [9 x i8] c"fuck C++\00"
    declare i32 @puts(i8* nocapture) nounwind

    define i32 @main() {
        %fcsptr = getelementptr [9 x i8]* @.fcs, i64 0, i64 0
        loop:
            call i32 @puts(i8* %fcsptr)
            br label %loop
    }

Der ganze implizite Scheiß und der Syntax Sugar können mir gestohlen bleiben. Ich schreibe Programme jetzt nur noch so, dass ich dabei auch weiß, was sie tun werden.

Nur, dass du den ersten BB auch benennen solltest und dannach in %loop branchen solltest, sonst gibt's Fehler vom Parser.
Außerdem könnte man netterweise @main mit noreturn flaggen, damit der Compiler überflüssigen exit-Code rausschmeißen kann.

antisteo hat geschrieben:Nur, dass du den ersten BB auch benennen solltest und dannach in %loop branchen solltest, sonst gibt's Fehler vom Parser.

Ja; genau. Ich musste den Post dummerweise aus dem Kopf verfassen :-)

Krishty hat geschrieben:    @.fcs = private unnamed_addr constant [9 x i8] c"fuck C++\00"
    declare i32 @puts(i8* nocapture) nounwind

    define i32 @main() {
        %fcsptr = getelementptr [9 x i8]* @.fcs, i64 0, i64 0
        loop:
            call i32 @puts(i8* %fcsptr)
            br label %loop
    }

Der ganze implizite Scheiß und der Syntax Sugar können mir gestohlen bleiben. Ich schreibe Programme jetzt nur noch so, dass ich dabei auch weiß, was sie tun werden.

Naja schön und verständlich sind für mich wohl andere Sachen. Aber jedem das Seine. Ich lob mir da den impliziten Scheiß und den syntaktischen Zucker. Sie vereinfachen mein Leben sehr. Aber ich hab wahrscheinlich andere Ansprüche. :)

Dann kompiliere ich es dir eben zu C# wenn du damit arbeiten musst ;)

Ja, versteh mich nicht falsch. Ich finde LLVM echt eine gute Sache. Kann ja auch seit einiger Zeit .net/mono soweit ich weiß, worauf du wahrscheinlich anspielst. Für mich wäre es nun aber absolut nix in LLVM-Assembly Code zu schreiben, vorallem nicht wenn man recht abstrakte Sachen machen will. Ich finde auch dein Engagement gut, dass du wirklich auf Optimierung und Reduzierung von Zustand Wert legst. Aber ich weiß nicht ob es global gesehen (also für die meisten Leute und Anwendungsfälle) sinnvoll ist, sich zu sehr mit Low-Level zu beschäftigen. Das kommt auf den Anwendungsfall an, aber ich glaube, dass die meisten Anwendungsfälle (und da zählen keine Spiele zu) sowas nicht unbedingt berücksichtigen müssen. Mobile Apps hängen da vielleicht wieder mehr dran, das kann sein. Aber ich lobe mir seit einiger Zeit die Features von C#, auch wenn ich früher ein absoluter Gegner wahr und C++ über alles gestellt habe. C++ ist mir für viele Dinge einfach zu umständlich geworden. Bei mir zählt heute ein zeitnahes und einfaches (minimaler Aufwand) Ergebnis mehr als Effizienz und Kompaktheit. Gerade im Bereich von Büroanwendungen und ähnlicher Software (was für mich gefühlt immer noch den größten Teil ausmacht) ist es einfach sinnvoller eine Oberfläche schnell und einfach zu erstellen und nicht auf Speichermanagement achten zu müssen, als sich Sorgen zu machen, dass die Anwendung langsamer läuft oder etwas größer wird.

Versteh du mich auch nicht falsch: LLVM Assembly ist nicht der Weisheit letzter Schluss; es strotzt nur so vor nerviger Redundanz (z.B., dass man vor dem Verwenden einer Variable JEDES MAL explizit ihren Typ hinschreiben muss).

Ich verachte C++, weil ich nicht sagen kann, was die Programme machen. Es ist so einfach, ein komplettes Subsystem auf der undefinierten statischen Initialisierungsreihenfolge aufzubauen, oder den +-Operator durch einen Tippfehler zu - zu machen, oder einen bei einer einzigen zusätzlichen Überladung zusammenbrechenden Template-Dschungel zu bauen, dass ich mittlerweile nicht mehr glaube, dass sich damit überhaupt größere Software zuverlässig implementieren lässt. Wenn ich auf eine noch-so-banale Zeile C++ sehe, kann ich einfach nicht mehr sagen, was passiert, wenn sie ausgeführt wird. Sogar dann nicht, wenn ich Compiler und Zielplattform kenne. Das ist ein Debugging-Feuersturm, der Mannstunden biblischer Ausmaße verheizt.

C ist um Klassen besser weil halbwegs eindeutig; aber die Syntax ist der pure Grauen.

Darum ist mein Gedanke: Wenn ich mittlerweile eh die Hälfte der Entwicklungszeit dadurch vernichte, Maschinentext gegen Quelltext zu prüfen, kann ich mir meine Programmiersprache diesmal bottom-up entwerfen, indem ich erst mit der konkretesten Programmiersprache beginne und sie dann stückweise abstrahiere (statt umgekehrt wie bei C++). Assembler ist eine Lebenszeitverschwendung weil null portabel und historisch gewuchert; LLVM als portabler Allround-Assembler mit Luxus wie Exception Handling und Label Addresses ist hingegen perfekt dafür.

Und bei C# weiß ich leider kein Bisschen mehr, was das Programm macht, wenn ich eine Zeile seines Quelltextes sehe. Es ist genau die Gegenrichtung.

Es grüßt Dich der Duke :D Ich weiß, dass Dich eine GC Sprache nicht interessiert, aber Du hast so schön aufgeführt, warum Java & Co. existieren. Ich habe mich aus den von Dir genannten Gründen ebenfalls von C++ abgewandt. Ich habe bei C++ zwar nur an der Oberfläche gekratzt, aber schon da hatte ich immer das Gefühl gegen mich selbst zu kämpfen. Das ist übrigens ebenfalls ein Grund warum ich mit Clojure, Scala und auch ein bisschen C# hadere. Ich wünsche Dir viel Glück bei Deiner Reise :)

Krishty hat geschrieben:Darum ist mein Gedanke: Wenn ich mittlerweile eh die Hälfte der Entwicklungszeit dadurch vernichte, Maschinentext gegen Quelltext zu prüfen, kann ich mir meine Programmiersprache diesmal bottom-up entwerfen, indem ich erst mit der konkretesten Programmiersprache beginne und sie dann stückweise abstrahiere (statt umgekehrt wie bei C++). Assembler ist eine Lebenszeitverschwendung weil null portabel und historisch gewuchert; LLVM als portabler Allround-Assembler mit Luxus wie Exception Handling und Label Addresses ist hingegen perfekt dafür.

Das klingt irgendwie nach einer vernünftigen Idee. Du warst ja eh ab und an dabei an einer neuen Sprache zu tüfteln bzw. Konzepte dafür zu entwickeln. Ich drück die Daumen.

Krishty hat geschrieben:Und bei C# weiß ich leider kein Bisschen mehr, was das Programm macht, wenn ich eine Zeile seines Quelltextes sehe. Es ist genau die Gegenrichtung.

Ja ich verstehe schon in welche Richtung du gehst. Ich wollte nur sagen, dass mir von Jahr zu Jahr gleichgültiger wird, was das Programm unten drunter macht. Das, was es im Gesamten macht, sehe ich auch bei C# (schon allein weil man so abstrakt arbeitet, dass man viele Fehler gar nicht machen kann, bzw. größere Aufgaben einfach mit einem Befehl anschubst). Wie es das im Detail macht, kann mir relativ egal sein, sofern es die Aufgabe erfüllt und die Performance in einem vertretbaren Rahmen liegt. Und genau das ist in nahezu allen Fällen zutreffend. Klar muss ich hier moderne Spiele rausnehmen oder Abstand von Embedded und Mobile nehmen - daher sagte ich ja auch, dass der Anwendungsfall entscheidend ist.

Ich glaube einfach, dass mit hoher Abstraktionsebene zwar die Kontrolle flöten geht, aber auch die Wahrscheinlichkeit für Fehler drastisch sinkt (ja man kann nicht so viel nachvollziehen was abgeht, aber wenn einem das meiste abgenommen wird, dann musst du das gar nicht mehr). Und dann kommt es mMn nur noch drauf an, ob man Kontrolle braucht oder nicht. Ich weiß, dass nicht alles perfekt ist, aber bislang arbeitet der ganze Unterbau doch recht zuverlässig bei C#.

Ich habe auch immer verflucht, dass bei C# alles prinzipiell versteckte Referenzen sind und man sollte meinen, dass dadurch auch ziemlich krasse Dinge ungewollt passieren. Aber um ehrlich zu sein, ist mir da bislang erst einmal was unglückliches passiert. Und wenn ich dann runterblicke (nicht gehässig) auf C++ und C, dann bin ich doch ganz froh diese "Verschleierungsebene" zu haben. Ich programmiere ab und an auch C++, da ich noch größere Projekte rumliegen habe, aber es ist einfach nur noch mühsam. Mir ist mittlerweile einiges ans Herz gewachsen, was sicherlich meine Faulheit unterstützt, aber dazu stehe ich.

Ich würde ganz gern anmerken das man mit guter Abstraktion durchaus auch Kontrolle gewinnen kann. In einem C-Programm das alle Deallokationen und Fehlerpfade explizit ausdrücken muss, kann der wesentliche Ablauf recht schwer erkennbar sein. In C++ würde man das nicht mehr "explizit konrollieren" sondern über Destruktoren und Exceptions abwickeln. Dafür würde man das Wesentliche des Programms aber leichter herauslesen können und gewissermaßen doch wieder Kontrolle gewinnen, halt auf höherer Ebene. Ähnliches gilt für Interfaces: Wenn sie gut gemacht sind, bieten sie eine klare Schnittstelle und befreien einen davon sich mit Implementierungsdetails herumschlagen zu müssen.
Das sind halt so Sachen wo Hochsparachen ihre Stärken haben. Klar kann man auch in Assembler (oder LLVM IR) eine Funktionstabelle anlegen und als Interface verwenden. Aber es würde mich sehr wundern wenn das übersichtlicher ist als in einer brauchbaren Hochsprache.

Sternmull hat geschrieben:Ich würde ganz gern anmerken das man mit guter Abstraktion durchaus auch Kontrolle gewinnen kann. In einem C-Programm das alle Deallokationen und Fehlerpfade explizit ausdrücken muss, kann der wesentliche Ablauf recht schwer erkennbar sein. In C++ würde man das nicht mehr "explizit konrollieren" sondern über Destruktoren und Exceptions abwickeln. Dafür würde man das Wesentliche des Programms aber leichter herauslesen können und gewissermaßen doch wieder Kontrolle gewinnen, halt auf höherer Ebene. Ähnliches gilt für Interfaces: Wenn sie gut gemacht sind, bieten sie eine klare Schnittstelle und befreien einen davon sich mit Implementierungsdetails herumschlagen zu müssen.
Das sind halt so Sachen wo Hochsparachen ihre Stärken haben. Klar kann man auch in Assembler (oder LLVM IR) eine Funktionstabelle anlegen und als Interface verwenden. Aber es würde mich sehr wundern wenn das übersichtlicher ist als in einer brauchbaren Hochsprache.

Das war etwas unsauber formuliert. Mit Kontrolle meinte ich in diesem Kontext tatsächlich die Kontrolle auf unterster Ebene, also wie was und wo in Register geschoben und optimiert wird (oder halt nicht) oder grob gesagt was aus deinem Code dann letztlich als Prozessorbefehle übrig bleibt. Das was du hier (als "Kontrole auf höherer Ebene") ansprichst meinte ich mit "Vermeidung von Fehlern". Ich denke wir meinen also prinzipiell das Gleiche. Gerade weil einem viel abgenommen wird und man das nicht selbst schreiben muss vermeidet man Fehler, verliert aber die Kontrolle auf Low-Level-Ebene, weil man es eben nicht selbst macht und auch nicht unbedingt gucken kann wie es gemacht wird.

Ja. Und das ist auch gut so wenn einem an der Stelle egal ist wie es letztenendes implementiert ist. Das macht den Kopf frei und schafft Zeit für produktiveres als selbst Compiler zu spielen :)

Krishty hat geschrieben:Versteh du mich auch nicht falsch: LLVM Assembly ist nicht der Weisheit letzter Schluss; es strotzt nur so vor nerviger Redundanz (z.B., dass man vor dem Verwenden einer Variable JEDES MAL explizit ihren Typ hinschreiben muss).

Ich verachte C++, weil ich nicht sagen kann, was die Programme machen. Es ist so einfach, ein komplettes Subsystem auf der undefinierten statischen Initialisierungsreihenfolge aufzubauen, oder den +-Operator durch einen Tippfehler zu - zu machen, oder einen bei einer einzigen zusätzlichen Überladung zusammenbrechenden Template-Dschungel zu bauen, dass ich mittlerweile nicht mehr glaube, dass sich damit überhaupt größere Software zuverlässig implementieren lässt. Wenn ich auf eine noch-so-banale Zeile C++ sehe, kann ich einfach nicht mehr sagen, was passiert, wenn sie ausgeführt wird. Sogar dann nicht, wenn ich Compiler und Zielplattform kenne. Das ist ein Debugging-Feuersturm, der Mannstunden biblischer Ausmaße verheizt.

C ist um Klassen besser weil halbwegs eindeutig; aber die Syntax ist der pure Grauen.

Darum ist mein Gedanke: Wenn ich mittlerweile eh die Hälfte der Entwicklungszeit dadurch vernichte, Maschinentext gegen Quelltext zu prüfen, kann ich mir meine Programmiersprache diesmal bottom-up entwerfen, indem ich erst mit der konkretesten Programmiersprache beginne und sie dann stückweise abstrahiere (statt umgekehrt wie bei C++). Assembler ist eine Lebenszeitverschwendung weil null portabel und historisch gewuchert; LLVM als portabler Allround-Assembler mit Luxus wie Exception Handling und Label Addresses ist hingegen perfekt dafür.

Und bei C# weiß ich leider kein Bisschen mehr, was das Programm macht, wenn ich eine Zeile seines Quelltextes sehe. Es ist genau die Gegenrichtung.

Wir bauen sehr zuverlässige embedded Devices damit, so schlimm isses nicht :).

Gruß Kimmi

Ich war früher auch ein Verfechter von unmanaged Code und für sauberes Allokieren, Deallokieren von Speicher. Da ich es aber nach Jahren immer noch nicht fehlerfrei beherrsche, keine Use-after-Free-Fehler mehr zu machen und das Feedback zu solchen Fehlern erst sehr spät, sehr subtil (Absturz beim Beenden) oder gar nicht auftaucht, bin ich inzwischen ein Verfechter von Garbage Collectors. Da die meisten Programme, die ich schreibe, eh nur noch Netzwerkverbindungen aufbauen, irgendwelche Daten schicken, verarbeiten und weiterschicken, ist inzwischen das Netzwerk und nicht mehr die CPU der Flaschenhals. Und CPU-Cores hat man inzwischen genug, dass sich eher die Frage stellt, wie man für sich selbst am verständlichsten parallelisiert (und nicht den Überblick verliert bei den ganzen Locks)

Chromanoid hat geschrieben:Ich weiß, dass Dich eine GC Sprache nicht interessiert, aber Du hast so schön aufgeführt, warum Java & Co. existieren.

Java existiert, damit möglichst viele Leute durch möglichst viel Software von der Malware eines Konzerns abhängig sind. Du könntest genau so gut sagen, Apple wolle die Welt verbessern.

Sternmull hat geschrieben:In einem C-Programm das alle Deallokationen und Fehlerpfade explizit ausdrücken muss, kann der wesentliche Ablauf recht schwer erkennbar sein. In C++ würde man das nicht mehr "explizit konrollieren" sondern über Destruktoren und Exceptions abwickeln. Dafür würde man das Wesentliche des Programms aber leichter herauslesen können und gewissermaßen doch wieder Kontrolle gewinnen, halt auf höherer Ebene. Ähnliches gilt für Interfaces: Wenn sie gut gemacht sind, bieten sie eine klare Schnittstelle und befreien einen davon sich mit Implementierungsdetails herumschlagen zu müssen.

Du machst den Fehler, anzunehmen, dass Programmierer diese Sachen grundsätzlich zum richtigen Zweck einsetzen würden. Jaja Christentum und Sozialismus sind auch ganz ganz fantastische Dinge auf dem Papier; mit Nächstenliebe und Teilen und so. Sie scheitern nur daran, dass jeder Mensch grundsätzlich alles kaputtmacht, was man ihm in die Hände gibt.

kimmi hat geschrieben:Wir bauen sehr zuverlässige embedded Devices damit, so schlimm isses nicht.

Das sagst du weil es

1. deine eigenen Werke sind; und
2. du dich durch dein Alter bedingt nicht jeden Tag mit den Script-Kiddies rumschlagen musst, die glauben, dass sie eine Eclipse-Installation zu Programmierern macht.

Ich versuche weiterhin nicht, hohe Komplexität zähmbar zu machen, sondern sie im Gegenteil möglichst weh tun zu lassen, damit man sie erst garnicht entstehen lässt.

50 Bytes of Code That Took 4 GB to Fail to Compile

Krishty hat geschrieben:

Chromanoid hat geschrieben:Ich weiß, dass Dich eine GC Sprache nicht interessiert, aber Du hast so schön aufgeführt, warum Java & Co. existieren.

Java existiert, damit möglichst viele Leute durch möglichst viel Software von der Malware eines Konzerns abhängig sind. Du könntest genau so gut sagen, Apple wolle die Welt verbessern.

The Java Language: An Overview. | Introduction hat geschrieben:Simple

We wanted to build a system that could be programmed easily without a lot of esoteric training and which leveraged today's standard practice. Most programmers working these days use C, and most programmers doing object-oriented programming use C++. So even though we found that C++ was unsuitable, we designed Java as closely to C++ as possible in order to make the system more comprehensible.
Java omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. These omitted features primarily consist of operator overloading (although the Java language does have method overloading), multiple inheritance, and extensive automatic coercions.

We added automatic garbage collection, thereby simplifying the task of Java programming but making the system somewhat more complicated. A common source of complexity in many C and C++ applications is storage management: the allocation and freeing of memory. By virtue of having automatic garbage collection (periodic freeing of memory not being referenced) the Java language not only makes the programming task easier, it also dramatically cuts down on bugs.

The folks at Archimedes wanted to spend their time thinking about levers and pulleys, but instead spent a lot of time on mundane programming tasks. Their central expertise was teaching, not programming. One of the most complicated of these programming tasks was figuring out where memory was being wasted across their 20K lines of code. [...]

:P

Ich habe nicht genug Hände und Füße um mich so gesichtszupalmen wie ich jetzt will.