Zum RP2350 gibt es Neuigkeiten – neben einem Sicherheitswettbewerb (Schema Pwn 2 Own) steht ein Evaluationsboard mit einem Funkmodul ante portas. Intel verkauft seine Anteile an ARM, ARMBian geht in die Stabilisierungsphase des aktuellen Release-Zyklus und Adafruit kündigt ein Stemma-Board mit WCH-Mikrocontroller an. Die DARPA möchte derweil einen automatischen C-zu-Rust-Transpiler entwickeln, um die “Zukunftsfähigkeit” von C-Code sicherzustellen.
Raspberry Pi - Hacke den RP 2350 und gewinne 10 000 US-Dollar.
Im Hause Raspberry Pi scheint man die Sicherheits-Architektur des neuesten Mikrocontrollers sehr ernst zu nehmen. Aufgrund der gerade stattfindenden Hacker-Konferenz Def Con lancierte man den in der Abbildung gezeigte „Angriffs-Wettbewerb“, für dessen Gewinn 10 000 US-Dollar an Preisgeld ausgelobt sind.
Zur Teilnahme muss der P. T. Angreifer nicht unbedingt physikalisch anwesend sein. Es ist auch möglich, ein im Handel erworbenes Pico 2-Board durch einspielen einer speziellen Firmware in eine Zieldarstellungsdrohne zu verwandeln.
Zu beachten ist allerdings, dass diese Modifikation mit irreversiblen Einschränkungen einhergeht. Spezifischerweise ist es nach dem Aktivieren der Sicherheitsarchitektur nie wieder möglich, auf diesem Board die Harzard 3 - RISC-Kerne in Betrieb zu nehmen.
Challenger+ RP2350 WiFi6/BLE5 – Raspberry Pi Pico W 2 von schwedischem Drittanbieter
Im Bereich der Wireless-Varianten des Raspberry Pi Pico setzte man im Hause Raspberry Pi Foundation bisher auf Infineon - warum man nicht auf Espressif-Module setzt, kann wohl nur durch „Compatetive Anxiety“ erklärt sein.
Sei dem wie es sei, bringt der schwedische Anbieter ILabs nun - wie in der Abbildung gezeigt - zusammen, was zusammen gehört.
Kritisch ist an der normalerweise um rund € 25 erhältlichen Platine vor allem, dass man im Hause Raspberry Pi sehr wahrscheinlich abermals auf den Funkmodul von Infineon setzen wird. Dies führt dann zu einer Insellösung.
Infineon AIROC CYW89829 - neuer Bluetooth LE-Mikrocontroller für den Automotivebereich.
Spricht man vom Teufel, so taucht er nur allzu oft auf. Im Fall von Infineon gilt, dass ein neuer Bluetooth LE-Mikrocontroller am Start steht - Spezifischerweise wird die neue Lütte folgendermaßen beschrieben:
Def Con und Raspberry Pi - Palm OS-Entwicklerlegende Grinberg durch Security von Bühne entfernt.
Die „Kombination bzw. Ankündigung“, den RP2350-Sicherheitswettbewerb auf der Devcon stattfinden zu lassen, ist kein Zufall - jeder Teilnehmer bekommt als Namesschild einen „Kleinstcomputer“, der auf einem der Mikrocontroller basiert.
Interessant ist, dass die Entwicklung der dort befindlichen Firmware wohl von der einst aus Palm OS-Zeiten bekannten Programmierer-Legende Dimitry Grinberg vorangetrieben wurde. Aufgrund von „Lizenzstreitigkeiten“ wurde dieser dann von seinem eigenen Vortrag zum Thema entfernt.
ARM, zur Ersten - Intel verkauft seine Aktienanteile
Spätestens nach dem Debakel um Curie, Galileo und Co. war klar, dass der X86-Architektur im Mikrocontroller und MSR-Bereich keine große Zukunft zusteht.
Im Hause Intel konnte man dieses Problem bisher mit einem lachenden und einem weinenden Auge betrachten, da man ob des Besitzens eines durchaus erheblich umfangreichen ARM-Aktienpaket ja doch irgendwie am Erfolg von ARM mitschnitt.
Handelsblatt berichtet nun unter Bezug auf ein SEC-Filing, dass diese Partnerschaft durch Verkauf der Anteile geendet ist:
Das Auch-Inkludieren von RISC/V-Kernen im neuesten Raspberry Pi Pico-Mikrocontroller scheint ARM nicht sonderlich zu stören.
Im aktuellsten an die Entwicklerschaft verschickten Newsletter findet sich die in der Abbildung gezeigte Lobung des Produkts.
Emteria - Abkündigung der alten MDM-Infrastruktur final.
Im Hause der Industrie-Android-Variante Emteria gibt es ebenfalls Neuerungen. In einem heute an die P. T. Nutzerschaft versendeten Newsletter vermeldet man nach folgendem Schema, dass das „alte“ MDM-Interface im Laufe der nächsten Tage den Weg alles irdischen gehen wird:
1
PleasenotethattheoldUI(https://mdm.emteria.com/Home/ListDevices) is now officially deprecated. Due to its limitations, particularly in handling data from different servers accurately, the old UI will be completely removed on December 31st, 2024.
Adafruit - Entwicklerboard auf Basis von WCH CH32V203
Etablierte Mikrocontrollerhersteller dürften die Ankündigung des in der Abbildung gezeigten Produkts ungefähr so verfolgen, wie ein Grillkoch die Installateur eines Burgergrillroboters betrachtet.
Die vor allem wegen ihrer hohen Breitenwirkung relevante Adafruit hat nun angekündigt, eines ihrer Stemma-Boards auf Basis der WCH-Ultra Low Cost-Mikrocontroller anbieten zu wollen. Zum Zeitpunkt der Drucklegung ist das Board um fünf Euro plus Versand erhältlich. Interessant ist, dass in der „Beschreibung“ nach folgendem Schema auf die „Unzureichendheit“ der verwendeten WCH-Hardware hingewiesen wird:
1
However,pleasenotethattheCH32seriesisnotsupportednearly-as-wellasATmega,ESP32,ATSAMD,STM32,orRP2040chipsthathaveastrongcompany-leddevelopmentcommunity.WCHisvery"its a low cost chip, you figure it out"kindofcompany,andwhilethereissomecommunity-leddevelopmentitisstillbestusedbyfolkscomfortablewithhavingtouseMakefiles,clonegitrepositories,editconfigurationfiles,etc.ItdefinitelydoesnotrunCircuitPythonorMicropython,andArduinosupportisveryearly.It'sdefinitelynotgoodforbeginners!
2
---viahttps://www.adafruit.com/product/5996
DARPA TRACTOR – Projekt zur Transpilation von C in RUST
Dass die Rust-Entwicklerschaft im C-Umfeld zu wildern sucht, dürfte für Leser von Mikrocontroller.net nicht überraschend sein. In Zusammenarbeit mit der US-amerikanischen Forschungsbehörde DARPA plant man ein Projekt, das die automatisierte Transpilation von (als schwierig zu wartend angesehenem) C-Code in Rust-Code automatisieren soll:
Das hinter der im Embeddedbereich weit verbreiteten Linuxdistribution Armbian stehende Entwicklerteam informiert seine P. T. Nutzerschaft nun darüber, dass der aktuelle Release-Zyklus im Stabilisierungsbereich angekommen ist. Spezifischerweise soll der Fokus der Maintainer nun vor allem auf der Sicherstellung der Produktqualität liegen:
Wo kommt denn die Begründung "Lizenzstreitigkeiten" her? Im Tweet steht ja nur, das er nichts genaues wüsste. Und aufgrund der Streitigkeiten er überlegt die Lizenz zu entziehen.
Keine Ahnung, was Defcon mit seiner Firmware genau macht. Aber er dürfte mindestens indirekt der Verbreitung auf dem Badge zugestimmt haben. Wer die Firmware für den Badge entwickelt und ausliefert, kann nicht nachträglich dann die Lizenz entziehen. Die weitere Verbreitung (damit ich das hier zu Hause hacken kann) kann er im Zweifelsfall aber untersagen.
Was ich mich zum Rust transpiling frage: Kann man damit nicht theoretisch einfach auch C sicherer machen? In (safe) Rust muss man sich ja einfach alle Gedanken zur Speichersicherheit gemacht haben und der Compiler beschwert sich, wenn das nicht passiert ist. Also muss der Transpiler alle Speicherfehler finden, um das in safe Rust zu Übersetzen. Aber dann könnte man doch auch gleichwertigen C Code ausspucken oder nicht?
Aber dann könnte man doch auch gleichwertigen C Code
ausspucken oder nicht?
Aber dann hätte man ja keinen Grund für die x-te "sichere" Sprache, die den Programmierern das Erlernen der Grundlagen abnehmen soll. Und man hätte keine Sprache, in der altbekannte Dinge mit neuen tollen Namen ("Crate") versehen werden. Und man hätte keine Sprache mit CoC. Weil gerade auf den es ja heutzutage ankommt.
Das wäre doch total uncool. Nee, das geht also schon mal gar nicht.
Als junger Programmierer muss man alles ablehnen, womit vorangehende Generationen gearbeitet haben. Denn vorangehende Generationen sind blöd, senil und rückständig, und nur als junger, dynamischer Mensch mit allen Pronomen kann man überhaupt vernünftige Programme entwickeln.
Da kann es dir auch schon passieren das du deinen Source
einchecken willst und dann wird dir auf die Finger geklopft.
Und natuerlich sind da auch alle Warnungen an.
Aber wenn man als Fanboy unbedingt was neues mit Fussaufstampfen
durchdruecken will dann vergisst man sowas.
Das wäre doch total uncool. Nee, das geht also schon mal gar nicht.
Gegen ein paar Neuerungen waer ja auch mal nix zu sagen, aber ich
schon den Eindruck das Rust irgendwie auch eine Glaubenslehre ist.
Wichtiger, jenseits vom Basteltisch wird keiner
mit K&R von anno Tubak programmieren.
Das macht hoffentlich auch am Basteltisch niemand, denn K&R-C ist etwas, was man wirklich ablehnen darf. Mit C89 hingegen kann man auch heute noch problemlos sichere, wartbare und zuverlässige Programme schreiben.
@ Tam:
Darf man fragen warum es kritisch sein soll wenn auf dem Raspi Board ein Produkt von Infineon verwendet wird? Das Funkmodul ist doch eine Art Blackbox mit dem man als Anwender/Programmierer nichts zu tun hat. Man nutzt es nur. Genauso wie man von einem Standard ESP das Funkmodul nur verwendet, aber nichts direkt damit zu tun hat. Das Funkmodul auf dem Raspi kann damit von jeder x beliebigen Firma sein. Zudem hat Raspi nichts mit ESP zu tun, von daher haben sie freie Auswahl. Zur Frage zurück. Warum soll es kritisch sein? Vielleicht ist es ja das bessere Produkt.
Alleine die Vorstellungen, so etwas wie Misra würde irgend etwas an der Situation ändern ist schon realtätsfremd.
C ist per Definition und Grundkonzeption eine Sprache, die halt dem Programmierer alle Freiheiten gibt, auch die mit dem Schuss in den eigenen Fuss. Daran ändert auch Misra nichts.
C ist per Definition und Grundkonzeption eine Sprache, die halt dem
Programmierer alle Freiheiten gibt, auch die mit dem Schuss in den
eigenen Fuss. Daran ändert auch Misra nichts.
Doch, genau das ändert Misra. Das ist Sinn und Zweck von Misra. Was die meisten Entwickler nicht mögen: dass Misra genau diese Freiheiten von C einschränkt.
Nein. C ist einfach ein durchgesetzter von allen genutzter Standard. Kein guter! Aber ein Standard. Man muss sich Fragen ob seine Nachteile nicht durch den Vorteil ein Standard zu sein aufgehoben werden.
Vergleich es mit LED-Leuchtmitteln. Sind Gluehbirnen sicher oft ueberlegen. Kann ich aber nirgends einfach so auswechseln weil es keinen Standard ist.
So ist es mit jeder neuen Schickimickisprache die gerade durch Dorf getrieben wird auch. Und das die Rustanbeter fuer alles eigene Woerter und Verhaltensweisen erfinden muessen hinterlaesst schon etwas von Zeugen Jehova oder so auf dem Level. Man koennte sagen das Ambiente stimmt nicht. .-)
Tja, C++ ist auch standardisiert, aber sobald man das einbringt wird C
mit Inbrunst verteidigt...
Es ist doch eher so, dass Rust mit Inbrunst verteidigt wird. Und C muss verteidigt werden gegen Assembler, weil es die Programmierung von von MCs erleichtert, vor allem wenn man mit verschiedenen zu tun hat.
Was jetzt C++ in diesem Zusammenhang zu suchen hat, weiß ich auch nicht genau, aber es gibt halt gehäuft Nachrichtenaustausch zwischen Objekten - wo C++ eben auch seine Vorteile hat. Außerdem kann man ja auch mal was neues Lernen, und da die Bibliothekswelt in C++ (oder die Weiterentwicklung) auch top ist (Haskell-Bib-Einträge gab es nur zu Hype-Zeiten), warum nicht? ;)
Tja, C++ ist auch standardisiert, aber sobald man das einbringt wird C
mit Inbrunst verteidigt...
Den Eindruck habe ich nicht! Im Embeddedbereich ist es eher so das C++ leise ignoriert wird. :)
Vermutlich sogar zu recht. C++ waere IMHO die bessere Wahl, aber nur wenn man einiges im Embeddedbereich bewusst ungenutzt laesst. Das setzt aber voraus das man diese Sprache gut drauf hat um dann bewusst nur Teile zu verwenden und da scheint mir C++ zu komplex. So viele Leute die sagen koennen das sie den Sprachumfang komplett drauf haben scheint es bei C++ nicht zu geben. Jedenfalls nicht im Embeddedumfeld wo die Leute ja auch noch andere Faehigkeiten vorweisen muessen.
Aber vielleicht schaffen da ja RP2040 oder RP2350 ein umdenken. Die breite Ausstreuung von Dualcores fuer jedermann zusammen mit der PIO die auch komplexe Sachen Timinggenau erlauben wuerden es vermutlich moeglich machen C++ sagen wir mal lockerer einzusetzen. Und das viele Ram hilft da auch noch.
Unser heutiges Ueberflussleben ist schon hart. Frueher war alles besser. :-D
Man man sollte nicht vergessen, die Intention von Sprachen wie Rust oder Go ist es gute zuverlaessige Programme auch von Leuten aus der Regionalliga zu bekommen die man entsprechend gering bezahlen kann. Hinter diesen Sprachen stecken IMHO auch grosse wirtschaftliche Interessen.
Ist Rust die Lösung für alle Probleme? Nö, natürlich nicht.
Aber: Es ist ein Versuch, mit einer neuen Programmiersprache Anwendungsbereiche abzudecken, die bisher ganz gut von C (und C++) versorgt wurden, ohne jedoch diesen absoluten Fokus auf maximale Performance und "der Programmierer wird schon wissen, was er tut" zu setzen. Das finde ich gut. Im allgemeinen weiß man zwar, was man tut, aber Fehler oder Unachtsamkeiten passieren auch den besten Leuten und dann ist man froh über eine Sprache, bei der das nicht direkt zur Katastrophe führt.
Man man sollte nicht vergessen, die Intention von Sprachen wie Rust oder
Go ist es gute zuverlaessige Programme auch von Leuten aus der
Regionalliga zu bekommen die man entsprechend gering bezahlen kann.
Hinter diesen Sprachen stecken IMHO auch grosse wirtschaftliche
Interessen.
Sieh es mal so: Es gibt nur wenige Leute, die nicht in der "Regionalliga" arbeiten, du wirst also immer massenweise dieser Leute bekommen. Aktuell schreiben die murksigen C- und C++-Code, obwohl genügend Leistung vorhanden wäre, dass man Sprachen benutzen könnte, die unproblematischer sind. In Zukunft schreiben die hoffentlich murksigen Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten können, die Software wird also insgesamt besser, trotz gleichbleibender Qualifikation und Codequalität.
Ersteres preisen die C-Gurus natürlich euphorisch an, letzteres sind sie
nicht bereit zuzugeben...
Und lassen dabei gelegentliche Fettnäppchen auch nicht aus. Außerdem muss man ja auch fragen, wie hoch das technische Interesse wirklich ist, wenn man sich nicht mit Asm-Code auskennt. ARMs haben nicht viele Befehle, allerdings ist der Assemblercode auch reichlich stupide. Stört aber nicht, wenn man mehr wissen will - ein Asm? Pfui, Igitt, Ieebaba, wegdamit! usw. passt einfach nicht in diesem Zusammenhang. MCs verstehen heißt doch auch, sich mit der Hardware auseinanderzusetzen. Die C-Entwickler waren ja auch sehr gut in Asm und konnten sich bei der BS/OS-Programmierung auf ein Minimum Asm beschränken.
C-Only kann dann auch eigentlich nicht richtig C, weil ein gewisser Asm-Hintergrund ja irgendwo auch noch die halbe Miete ist.
Aber die richtigen Gurus, die vor beidem nicht zurückschrecken, können einem regelrecht Angst machen - sofern die nicht immer wieder beeindrucken. Ist halt nicht nur Asm und C bei denen, sondern auch ein theoretisch-praktischer Hintergrund, der weit von dem weg ist, was sich der normaler Mensch überhaupt vorstellen kann.
Früher kamen solche Leute, gerade bei der E-Technik eher aus dem Asm-Pascal-Bereich.
In Zukunft schreiben die hoffentlich murksigen
Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten
können, die Software wird also insgesamt besser, trotz gleichbleibender
Qualifikation und Codequalität.
Nützt nichts, wenn man besoffen, aber angeschnallt in den Jägerzaun brettert und zuletzt von einem Holzpfahl abgestochen wird.
Der Watcom C und Fortran - Compiler, bzw. das Entwicklungskit ist viel besser, das kann man auch in einem alten Windows auf den USB-Stick installieren. Offline, in der stillen Kammer, ganz in Ruhe usw.
Bei Rust braucht man ein Linux und Linux Offline ist ja auch irgendwie schwierig.
Rust werde ich genau dann ernst nehmen, wenn die Community es schafft, eine funktionierende Offline-Version für Free-DOS anzubieten.
https://www.reddit.com/r/rust/comments/ask2v5/dos_the_final_frontier/
Auf die ständige kognitive Dissonanz-Bereinigung habe ich auch keinen Bock - das kann man eine Zeit lang amüsant finden, langweilt in letzter Zeit aber nur noch.
Diese Rust Jünger können sich mal ein Beispiel an FreePascal nehmen - bevor die einen auf Heiligsprechung machen.
Alte Computer wie z.B. in Museen haben oft nur einen in Pascal entwickelten Emulator für DOS.
In Zukunft schreiben die hoffentlich murksigen
Rust-Code, bei dem zumindest einige Fehlerklassen nicht mehr auftreten
können, die Software wird also insgesamt besser, trotz gleichbleibender
Qualifikation und Codequalität.
Nützt nichts, wenn man besoffen, aber angeschnallt in den Jägerzaun
brettert und zuletzt von einem Holzpfahl abgestochen wird.
Ich weiß ehrlich nicht, was du mir damit sagen willst.
Ich habe kurz skizziert, warum ich denke, dass eine moderne Sprache, die die selbe Nische bespielt, in der auch C erfolgreich ist, erstrebenswert ist, weil dort extrem viel Code benötigt und entwickelt wird und man für diese Masse an Code nicht die notwendige Anzahl von Leuten mit extrem guter Qualifikation bekommen kann, da es davon nur sehr wenige gibt. Eine moderne Sprache könnte hier helfen, einige Klassen mit geringen Performanceeinbußen (die heute dank üppiger Leistung viel leichter verschmerzbar sind) leicht vermeidbarer und in der Realität problematischer Fehler einfach schon zur Entwicklungszeit gar nicht erst aufkommen zu lassen, was die insgesamte Softwarequalität verbessert. Ob die Sprache nun Rust sein muss? Mir echt egal, mir geht's da ums Prinzip.
Der Watcom C und Fortran - Compiler, bzw. das Entwicklungskit ist viel
besser, das kann man auch in einem alten Windows auf den USB-Stick
installieren. Offline, [...] Rust [...] Linux [...] Free-DOS [...] kognitive Dissonanz-Bereinigung [...] FreePascal [...] Heiligsprechung [...] Alte Computer [...] in Museen
Ich weiß ehrlich nicht, was du mir damit sagen willst.
Das scheint hier ja in einen wilden Streit zwischen C, Fortran, Basic, etc und Rust Fans auszuarten.
Hier einfach ein paar Punkte, die Rust meiner Meinung nach besser macht als andere Sprachen, das heißt aber nicht dass andere Sprachen irgendwie schlecht wären oder keine eigenen Vorteile hätten:
Na klar und oft zitiert: Speichersicherheit. Rust lässt einen standardmäßig keinen Unsinn machen. Das heißt aber nicht dass man das nicht kann, dafür gibt es unsafe {}, dann muss man sich halt wie in C und ASM selbst drum kümmern.
Die Speichersicherheit erstreckt sich im Embedded-bereich auch auf Peripherieregister und ganze module. Es ist in safe Rust schlicht unmöglich einen DMA-Kanal aus versehen zwei mal gleichzeitg zu verwenden. Jedes Peripheral ist im Grunde einfach ein leeres struct von dem bei der Initialisierung nur eine einzige Instanz erzeugt wird. Da das struct aber leer ist, fliegt es bei der Kompilierung raus und hat keine Performanceauswirkungen. Trotzdem gelten dieselben Regeln wie für Speicher: Genau eine Besitzer, entweder mehrere readonly Referenzen oder eine RW Referenz.
Interrupts: Es ist in Rust weder möglich unsynchronisiert auf globale Variable zuzugreifen, noch Code zu schreiben, bei dem eine Interruptunterrechung Probleme machen könnte. Auch kann man nicht vergessen danach die Interrupts wieder zu aktivieren.
Speicher: Embedded Rust hat standardmäßig nur .data, .bss und den Stack. Einen Heap gibt es von alleine nicht. Braucht man aber auch nicht, man kann problemlos ganze Netzwerkstacks ohne programmieren. Wenn man doch einen Heap will, gibts das aber auch, für fast jede Architektur gibt es eine genau dafür spezialisierte Implementierung.
Performance 1: Durch konsequente Verwendung des Stacks und nur seltener verwendung von spezialisierten Heap-implementierungen (man kann sogar mehrere für die jeweilige Anwendung optimierten Heaps verwenden), kann Rust effizienter sein als standard C malloc()
Performance 2: Rust hat standardmäßig keine virtual funcation tables wie C++ (auch hier gilt, wenn man es will bekommt man es trotzdem). Auch Generics machen keine Probleme, im Gegenteil sie werden gerade im Embedded bereich viel verwendet.
Performance 3: Spätestens wenn man in C/C++ ein RTOS braucht, ist Rust vorne. Statt einem OS mit Kontextwechsel, mehreren Stacks, ... wird einfach async verwendet. Damit lassen sich extrem einfach Dinge wie Timeouts umsetzen. Bei Netzwerkstacks unterscheidet sich die API nur minimal von Netzwerk auf Desktop. Async ist nachweislich schneller als ein RTOS und erzeugt kleineren Code. Auch async braucht keinen Heap, alle Größen können statisch berechnet werden.
Performance 4: In Rust werden fast immer zero-cost abstractions verwendet, also Abstraktion ja, Overhead nein. Obwohl die API teilweise genauso high-Level ist wie man es aus der Desktop-Programmierung kennt, verursacht das keine Performanceeinbußen.
Stromverbrauch: Da async Rust im Regelfall von Interrupts getrieben wird, wird der Prozessor während dem Leerlauf im Regelfall automatisch ohne weitere Konfiguration in den Slep-Mode versetzt. Selbst ohne besondere Vorkehrungen ist der Stromverbrauch fast Baterie-tauglich.
Auch in Rust gibt es inline ASM und man kann C-Code einbetten (und das ganz ohne komplizierte build-scripts)
Ich kann jedem nur mal empfehlen z.B. Embassy (https://embassy.dev/) auszuprobieren. Umgekehrt habe ich auch schon selbst Projekte mit C und AVR-ASM umgesetzt. Für ganz kleine Projekte mach ich das auch immer noch.
Wenn ich demnächst mal Zeit habe werde ich mal einen Artikel im Wiki zum Thema Embedded Rust schreiben.
Ich würde mir wünschen mehr über solche technischen Unterschiede zu diskutieren und sich nicht gegenseitig als "Rust-Prediger" zu beschimpfen oder sich zu beschweren, dass Rust nicht auf DOS läuft. Genau deswegen hab ich mir die Mühe gemacht diesen Beitrag zu schreiben.
The TRACTOR program aims to automate the translation of legacy C code to
Rust. The goal is to achieve the same quality and style that a skilled
Rust developer would produce, thereby eliminating the entire class of
memory safety security vulnerabilities present in C programs.
Das ernsthaft jemand glaubt, das währe machbar, unglaublich.
C ist eine formal definierte Sprache. Abgesehen vom UB, ist genau definiert, was was tut. Würde man das 1:1 in Rust übersetzen, muss man zwangsläufig auch die selben Bugs weiterhin drin haben, ansonsten ist es nicht das selbe Programm.
Darum wollen sie wohl LLMs nutzen, und es nicht 1:1 übersetzen. Nur, wenn man das nicht tut, also das C Programm nachher nicht mehr tun muss, was der Programmierer hingeschrieben hat, ist effektiv komplett undefiniert, was es tun wird und tun kann, man hat gar keine formalen Garantien mehr.
Man kann nicht beides haben. Entweder, die Übersetzung ist formal gleichwertig (inklusive Fehler), oder was es tut kann nicht mehr vorher gesagt werden, und Gott weiss was da raus kommt, jedenfalls sicher nicht, was der ursprüngliche Entwickler geschrieben hat.
Bei Computern gibt es keine Wunder und keine Magie. Auch nicht, wenn man ein LLM nutzt.
Naja, die Idee ist sicher, über vorhandene Artefakte (Spezifikationen, Tests, Handbücher, Code, etc.) LLM-gestützt eine Spezifikation zu erarbeiten und daraus dann LLM-gestützt neuen Code zu erzeugen. Im Prinzip kann das schon funktionieren und man wird dadurch sicher einige Fehler los. Nur: Im Prinzip. Wie es in der Realität aussieht, ist eine andere Frage, das kann ich zu schlecht bewerten, dafür habe ich zu wenige Erfahrungen damit.
Jetzt riecht es auf einmal ganz besonders streng nach "Moby".
Tippe eher auf c-hater
Das passt.
Naja, der Kornpichler ist zwar einigermaßen erfahren und auch halbwegs intelligent, aber halt auch doch kein Überflieger. Sonst hätte er das locker alleine ermitteln können...
Wollte er aber wohl garnicht. Oder schlimmer: sehr wahrscheinlich weiß er es längst (ist ja schließlich auch nicht besonders schwer zu ermitteln). Aber dann hätte ich natürlich argumentativ gleich einen ganz anderen Hintergrund. Dem wollte er sich wohl nicht aussetzen. Da ist es für ihn doch deutlich einfacher, mich zum Moby zu deklassieren...
Das Problem bei Moby war: der konnte eben nur Asm. Und das nicht mal gut. Und genau das ist bei mir anders. Und davor haben Typen wie der Kornpichler halt Angst. Jörg Wünsch ist genau so einer, überhaupt viele von der "alten Garde".
Viele von denen habe sich auch mal in Asm versucht, es aber nie zu besonderer Leistung geschafft. Hauptsächlich übrigens wohl deshalb, weil sie Asm nur in Anhängseln zu ihren hauptsächlich in C verfassten Anwendungen benutzt haben. Das ist eben Mist, mit diesem Ansatz kann Asm nur einen kleinen Teil seiner Vorteile ausspielen. Viele, sehr wirksame Optimierungen werden allein dadurch unmöglich, dass halt der Code in's C-ABI passen muss. Jedenfalls, wenn man die Vorteile der Benutzung der C-Runtime nicht aufgeben will. Oder kann...
Boah, dieses konstante Geningel der Rust-Adapten nervt. Scheint so eine Art vegane Programmiersprache zu sein, mit der man allen auf den Sack gehen muss.
Boah, dieses konstante Geningel der Rust-Adapten nervt. Scheint so eine
Art vegane Programmiersprache zu sein, mit der man allen auf den Sack
gehen muss.
Das konsequente Beharren der C-Only-Typen nervt. Unfähig, die Vorteile zu erkennen, die Rust bietet. Das ist was, was sich wirklich über Assembler erhebt (also eine echte Hochsprache) und nicht nur effektiv ein lausiger Macro-Assembler mit viel (effektiv überwiegend nutzlosem) Syntax-Bombast ist.
Man kann nicht beides haben. Entweder, die Übersetzung ist formal
gleichwertig (inklusive Fehler), oder was es tut kann nicht mehr vorher
gesagt werden, und Gott weiss was da raus kommt, jedenfalls sicher
nicht, was der ursprüngliche Entwickler geschrieben hat
Es reicht ja, wenn es "klaren Code" (der offensichtlich keine Fallstricke enthält) übersetzt und bei "unklarem Code" (mit Fallstricken) Eingriff fordert. Vielleicht mit alternativen Vorschlägen. Quasi wie ein gutes Merge-Tool, dass vieles allein schafft aber ab und zu nachfragt.
Jetzt faselst Du schon zum wiederholten Mal in wenigen Tagen über einen Code Of Conduct. Offenbar ist es für Dich unerträglich, wenn Menschen respektvoll miteinander umgehen wollen.
Doch. Das erkennt man schon an Glaubenskriegen wie diesem.
C ist einfach ein durchgesetzter von allen genutzter Standard.
Die allermeisten Entwickler nutzen C nur, wenn sie müssen, und zwar...
Kein guter!
...genau deswegen.
Aber ein Standard. Man muss sich Fragen ob seine Nachteile
nicht durch den Vorteil ein Standard zu sein aufgehoben werden.
Meine gute Erziehung verhindert, Dir detaillierter zu erklären, was dieser Standard mich mal kreuzweise kann, solange ich meine Aufgaben ohne ihn besser, schneller, komfortabler, einfacher und sicherer lösen kann. C mache ich heute nur noch, wenn mich jemand mit vorgehaltener Waffe dazu zwingt.
Derartige Aussagen beweisen nur, daß es sehr wohl um einen Glaubenskrieg geht, und manche Leute sich wegen religiöser Dogmen wie diesem nicht nur selbst das Leben schwer machen, sondern es auch anderen schwer machen wollen. Und wer das nicht mitmacht, ist ein Ungläubiger und wird mit Herabwürdigung bestraft!
C mache ich heute nur noch, wenn mich jemand mit vorgehaltener
Waffe dazu zwingt.
Dazu braucht es keine Waffe. Das Arbeitsamt reicht. Denn wenn du
im Embeddedbereich arbeiten willst und kein C kannst dann bist
du praktisch arbeitslos.
Offenbar ist es für Dich unerträglich, wenn Menschen
respektvoll miteinander umgehen wollen.
CoC hat nichts mit respektvollem Umgang miteinander zu tun, sondern tut nur so. Tatsächlich ist das ein moralinsaures Sprech- und Denkverbot, ausgedacht von vermeintlich progressiven Personendarstellern aus vermeintlich liberalen Kreisen in den USA.
Dazu braucht es keine Waffe. Das Arbeitsamt reicht. Denn wenn du
im Embeddedbereich arbeiten willst und kein C kannst dann bist
du praktisch arbeitslos.
Der Witz ist: Erst wenn man wirklich versteht, was C tut, kann man einschätzen, wie Scheiße C ist.
D.h.: Das Problem, kein C zu können, ist oft überhaupt kein Problem. Eher das Problem, kein C zu wollen.
Aber klar, für Geld ist man auch mal zu Kompromissen bereit und benutzt wieder besseren Wissens diesen unnützen Mist. Wenn's so gewollt ist und bezahlt wird.
Für Geld mache ich vieles Widerwärtige. Sogar Programmierung in C. Freiwillig aber niemals.
C mache ich heute nur noch, wenn mich jemand mit vorgehaltener
Waffe dazu zwingt.
Dazu braucht es keine Waffe. Das Arbeitsamt reicht.
Arbeitsämter (ich glaube, die heißen jetzt anders) sind nicht mein Maßstab.
Nebenbei bemerkt, sollen auch gute Python-, Perl-, Ruby-, Rust- und andere Entwickler ihren Lebensunterhalt ganz gut bestreiten können.
Denn wenn du
im Embeddedbereich arbeiten willst und kein C kannst dann bist
du praktisch arbeitslos.
Das stimmt, macht C aber trotzdem nicht zu einem eleganten Werkzeug. Und C zu können, hilft auch außerhalb des Embedded-Umfelds enorm. Wer bestreitet das?
Der Witz ist: Erst wenn man wirklich versteht, was C tut, kann man
einschätzen, wie Scheiße C ist.
Da Du auch mit Deinem neuen Namen nach wie vor exakt überhaupt keine Ahnung von C hast, ist Dein Geschreibsel so wie eine Empfehlung des Papstes über beglückendes Familienleben.
Was wird dir denn verboten zu sagen und zu denken?
Es wird die Bedeutung von etablierten Begriffen verdreht, um ihnen eine ausschließliche Einzelbedeutung unterzujubeln, und wer sich nicht an diese Diktion hält (die von jungen antikolonialistischen Soziologen festgelegt wird), der wird "gecancelt".
Es wird die Bedeutung von etablierten Begriffen verdreht, um ihnen eine
ausschließliche Einzelbedeutung unterzujubeln, und wer sich nicht an
diese Diktion hält (die von jungen antikolonialistischen Soziologen
festgelegt wird), der wird "gecancelt".
Und dann kommt halt sowas dabei raus:
Das war nicht die Frage. Die Frage war, was DIR verboten wird. Was möchtest DU sagen oder denken, was DU jetzt nicht mehr darfst?
Im verlinkten Artikel wird übrigens nur kritisiert, dass die Entscheidung geheim getroffen wird, nicht der CoC an sich:
At present, what we have is 'trust me, there’s problems, and we need to deal with them, but we can’t say anything.' I don’t feel comfortable with that kind of power being wielded in that much secrecy."
Fefe schreibt:
Er fand etwas lustig.
Wenn ich schreibe:
"Ich finde es lustig wie du dich bemühst, hier die Performance zu verbessern"
Ist das voll in Ordnung? Ich finde ja nur was lustig. Genauer geht Fefe nicht drauf ein, warum wohl...
Das war nicht die Frage, die Du gestellt hast. Das war aber meine Antwort. Ich muss nicht persönlich von einer Zeitgeisterscheinung betroffen sein, um sie ablehnen zu dürfen.
Das war nicht die Frage, die Du gestellt hast. Das war aber meine
Antwort. Ich muss nicht persönlich von einer Zeitgeisterscheinung
betroffen sein, um sie ablehnen zu dürfen.
Nichtsdestotrotz bleibt es ein bisschen arm, über Ententeiche zu Gackern, wenn alle Enten und Teiche weit weg sind.
Nö, das sehe ich anders. Kritik an Dingen nur noch Menschen zuzugestehen, die ganz unmittelbar davon betroffen sind, wäre eine massive Fehlentscheidung.
Denn das wäre äquivalent zu:
Du darfst erst dann ein Produkt in Frage stellen, wenn Du auch wirklich Krebs davon bekommen hast (und das nachweisen kannst).
Bis dahin wird Dir Dein Arbeitgeber weiterhin schicke Asbestjacken für die Arbeit am Hochofen zur Verfügung stellen.
