MaWin schrieb: > Weder Java noch Python bieten zum Beispiel die Garantie der Abwesenheit > von Data-Races. Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Das Problem hat man ja nur, wenn man threads verwendet, und mit mehreren Threads auf die selben Daten zugreift. In der Praxis braucht man das nur selten wirklich. Meistens braucht man überhaupt keine Threads. Bei python ist meistens async-await eine sehr gute Alternativen. Je nachdem kann man ein Programm auch mehrfach starten, wenn das zu verarbeitende untereinander unabhängig ist. Und in Java ist es extrem einfach, lock guards zu machen. Eigentlich muss man da meistens nur nicht vergessen, die richtigen Methoden / Blöcke mit "synchronized" oder "synchronized(objekt)" zu kennzeichnen. Zudem ist noch zu beachten, dass man den Ablauf auch falsch machen kann, ohne klassische Data-Races. z.B. Kannst du trotzdem festlegen, dass ein Bankomat Geld ausgibt, und dass er es vom Kontobetrag abzieht, ohne festzulegen, das erst das eine, und dann erst das andere passiert. Du kannst in Rust dann halt nicht gleichzeitig auf den Kontobetrag zugreifen, und es ist etwas schwerer, das so derart falsch zu machen, aber derartige Race-Conditions kannst du trotzdem erzeugen. Ist halt dann kein Data-Race mehr, sondern ein falscher Ablauf, aber kein bisschen weniger schlimm. Es ist wie überall, die Entwickler werden einfach neue Wege finden, Dinge falsch zu machen.
DPA schrieb: > Ja schon, aber es gibt viele sehr einfache Wege, diese zu vermeiden. Und genau das ist der Unterschied. Jede Sprache hat Mittel und Wege diese Fehlerklasse zu vermeiden. In Rust ist es gar nicht möglich diesen Fehler zu machen. > Das > Problem hat man ja nur, wenn man threads verwendet, und mit mehreren > Threads auf die selben Daten zugreift. In der Praxis braucht man das nur > selten wirklich. Ja, weil es in vielen Sprachen extrem schwierig ist überhaupt Threads zu verwenden. (Ab C++11 ist es wenigstens in C++ recht einfach geworden). In Rust ist es hingegen sehr einfach Threads zu verwenden. Sehr viele Rustprogramme nutzen Threads. DPA schrieb: > Bei python ist meistens async-await eine sehr gute Alternativen. Das kann Rust natürlich auch. Und zusätzlich kann es die Coroutinen auch noch in OS-Threads ausführen. Eben weil die Sprache Thread-safety erzwingt, ist dies transparent und ohne spezielle Vorkehrungen des Entwicklers möglich. Das kann Python nicht. DPA schrieb: > Eigentlich > muss man da meistens nur nicht vergessen, die richtigen Methoden / > Blöcke mit "synchronized" oder "synchronized(objekt)" zu kennzeichnen. In Rust kann man das gar nicht falsch machen, weil man gar keinen Zugriff auf die Daten bekommt, wenn man das Locking falsch macht. DPA schrieb: > aber derartige Race-Conditions kannst du trotzdem erzeugen. Das ist richtig. Hat aber auch niemand behauptet, dass Rust gleich alle Probleme löst.
MaWin schrieb: > Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel > weiter treibt (Lifetimes) als z.B. C++. Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein paar andere. Und wie andere ebenfalls sagten, ist das nur eins der Einfallstore für clevere Hacker. Es gilt der Satz des indischen Weisen: Die größte Sicherheitslücke bei IT-Systemen sitzt vor dem Bildschirm und klickt auf Links.
:
Bearbeitet durch User
Carsten P. schrieb: > MaWin schrieb: >> Es geht aber darum, dass Rust diese Konzepte erzwingt und noch viel >> weiter treibt (Lifetimes) als z.B. C++. > > Sagte ich doch, das tun Rust, Python, NanoFramework und sicher noch ein > paar andere. Lifetimes sind ein Alleinstellungsmerkmal von Rust. Mit fällt spontan gar keine andere Sprache ein, die das auch kann. Im Nachhinein ist das auch praktisch nicht in eine bestehende Sprache einbaubar. > ist das nur eins der Einfallstore für clevere Hacker. UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor", sondern es sind die Fehlerklassen, die für den Großteil der Sicherheitslücken in C/C++-Software verantwortlich sind. > Die größte Sicherheitslücke bei IT-Systemen sitzt an der Tastatur. Eben. Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler gar nicht oder nur schwer möglich sind und im Fehlerfall nicht eskalierbar sind.
MaWin schrieb: >> ist das nur eins der Einfallstore für clevere Hacker. > UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor" Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte richtig.
Carsten P. schrieb: > MaWin schrieb: >>> ist das nur eins der Einfallstore für clevere Hacker. >> UB/AOOB und Data Races sind nicht nur "irgendein Einfallstor" > > Wo habe ich "irgendein Einfallstor" geschrieben? Zitiere mich bitte > richtig. Ich habe dich richtig zitiert. Und zwar so: > ist das nur eins der Einfallstore für clevere Hacker.
Olaf schrieb: > Das Problem hier ist aber das man fremden Source in eigenen Programmen > benutzt und der nicht fehlerfrei ist. Dieser Satz lässt sehr tief blicken. Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, als eigener Code. Und genau dieser Mindset ist die Grundlage für Software-Fehler, inkl. Sicherheitslücken. Witzig dabei, dass gerade dieser Mindset immer wieder bei Embedded-Leuten zu finden ist, und in aktueller Zeit gerade unzählige Embedded-Systeme mit scheunentorartigen Sicherheitslücken glänzen. Witzig dabei auch, dass die "große" Softwarebranche(n) diesem Irrglauben vor etwa 25 Jahren auch aufgesessen ist, und brutal lernen musste, wie falsch dieser Mindset war. Tragisch dabei, dass wieder bewiesen wird, das Gruppe B nicht aus den historischen Fehlern der Gruppe A lernt, sondern die gleichen Fehler selbst durchleben will. Scheint irgendwie zum Mensch zu gehören.
> Und deshalb sollte man Sprachen so designen, dass schwerwiegende Fehler > gar nicht oder nur schwer möglich sind und im Fehlerfall nicht > eskalierbar sind. Naja. Man sollte eines dabei im Auge behalten. Es wird immer mehr in Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei vielen beliebten Programmierdialekten? Zitat von cppbert > Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt > vollbringt Wunder Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn letztere sich bereits lange in Entwicklung und damit ziemlich in hohem Maße gereift sind. Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten Sprachen wie go und Nim? Man hört Nim-mer viel .. Dem Linuxer mag es genügen wenn sein Code ihm ausgabemäßig die Konsole befüttert. Unter Windows haben es die Allermeisten aber gerne, wenn sich die App(likation) wohl aufgeräumt und im modernen Design dem Auge des Anwenders erschließt - nicht nur am Desktop, sondern am Tablet, am Smartphone, auf der Smartwatch usw. Mahnende Beispiele, die das (aufgeräumte GUI-Design) offensichtlich nicht bieten, sind hier aus dem CAD-Bereich jüngst genannt worden (verschrobene Bedienweise) bzw. wie man es besser macht oder sein kann ebenfalls. Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint und er sich lieber mit anderem befasst. Für Quantenalgorithmen gibt es Q-Sharp. Für KI listet die Computerwoche vom Nov. 21 Python, C++, JAVA, R, Julia und andere. Da ist weit und breit nix von Rust zu lesen. 1) extra in Anführung für die Fanboys ;)
> Du implizierst nämlich, dass fremder Code mehr Fehler enthalten würde, > als eigener Code. Und genau dieser Mindset ist die Grundlage für > Software-Fehler, inkl. Sicherheitslücken. Nein keineswegs. Du implizierst in deiner schlichten Gedankenwelt ein eigene Erkenntnis und baust daraus ein falsches Weltbild das du mir ueberstuelpen willst. Fremder Code kann im Rahmen gemittelter Programmiererfaehigkeit nur genauso gut/schlecht sein wie der eigene wenn er von relativ wenigen Leuten verwendet wird. Er koennte bezueglich Fehler aber auch sehr viel besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur Verbesserung beitragen. Es gibt damit aber auch Probleme: 1. Finde ich eine Luecke/Fehler in einem fremden Code kann ich das dann sofort bei vielen Geraeten ausnutzen. Und im Embeddedbereich kannst du nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet einmal im Monat updaten muss wie z.B bei Handysoftware. 2. Die Gruende viel fremden Code zu benutzen sind gleichzeitig gute Gruende den eben nicht genau zu untersuchen. Das wird ja schon jemand anderes gemacht haben. .-) 3. Gerade im Embeddedbereich passen unterschiedliche Programmierstile nicht immer perfekt zusammen. Das erhoeht die Resourcenanforderungen. Also mehr Strom oder teurere Controller. 4. Eine Tendenz jeden Kram in ein Geraet einzubauen und so die Funktionalitaet aufzublasen. Das kann natuerlich ein Vorteil sein, es ist aber auf jedenfall auch ein Nachteil. Jetzt schickt sich Rust ja an C zu verdraengen. Das wuerde ich tendenziell positiv finden, ich sehe durchaus den Nachteil von C. Allerdings gefaellt mir nicht der Mindset in den Entwicklerhirnen hinter Rust. (Erfinden von neuen Woertern fuer alten Wein (z.b crates!), Propagierung anderer Buildsysteme obwohl sowas unabhaengig von einer Sprache zu sein hat, Internetbezug/AutoUpdates) Olaf
Onkel Darwin schrieb: > Es wird immer mehr in > Sprachen programmiert, die Anwendern und Entwicklern ermöglichen, in > kürzester Zeit, d.h. ohne zeitaufwändige Einarbeitung lauffähigen > Programmcode zu generieren. Wo steht da Rust z.B. im Vergleich mit bei > vielen beliebten Programmierdialekten? Das ist eine Anforderung, die einer strengen Typisierung halt widerspricht. Wenn du Rapid Prototyping oder quick & dirty haben möchtest, nimm Python oder etwas ähnliches. > Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum Rust ist sehr C-ähnlich. Wer C kennt, findet sich schnell in Rust zurecht. > für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn > letztere sich bereits lange in Entwicklung und damit ziemlich in hohem > Maße gereift sind. Soso. In ziemlich hohem Maße gereift also. Die ständigen UB-basierten Sicherheitslücken reifen wohl mit. > Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten > Sprachen wie go und Nim? Go hat einen völlig anderen Zweck als Rust. Das steht nicht wirklich in Konkurrenz. Nim kenne ich nicht. > Vielleicht will dort Rust aber auch gar nicht hin. Vielleicht hat es der > an Rust Interessierte mit GUI nicht so, weil ihm das zu "doof" erscheint > und er sich lieber mit anderem befasst. Es ist überhaupt kein Problem GUI-Anwendungen in Rust zu schreiben. Zum Beispiel mit GTK. Das ist sicher nicht der Hauptzweck von Rust, aber es geht gut. Es wird ständig behauptet man könne Rust nicht für GUI-Applikationen einsetzen. Das ist ganz einfach falsch.
Olaf schrieb: > kannst du > nicht rumlaufen und den Leuten erzaehlen das die jedes Geraet einmal im > Monat updaten muss wie z.B bei Handysoftware. Auf meinem Mobiltelefon kommen täglich Updates rein. > Erfinden von neuen Woertern fuer alten Wein (z.b crates!) Welches Wort hättest du denn verwendet? > Propagierung anderer Buildsysteme Welches Buildsystem hättest du denn genommen? > obwohl sowas unabhaengig von einer Sprache zu sein hat Cargo ist unabhängig von der Sprache Rust. > Internetbezug Niemand zwingt dich Cargo online zu nutzen. Du kannst problemlos alle crates lokal vorhalten. Statt der Versionsnummer gibst du einfach den relativen Pfad zum Crate in Cargo.toml an. Einfacher gehts kaum. > AutoUpdates Was soll das sein?
MaWin schrieb: >> ist das nur eins der Einfallstore für clevere Hacker. "eins" ist nicht "irgendein". Nur zur Kenntnisnahme, auch auf die Gefahr hin, dass ich mich wiederhole: Ich halte "C" heutzutage für gar nichts mehr geeignet, weil es für alle möglichen Domains bessere Alternativen gibt. Würde heute noch wer ein neues Betriebssystem from scratch schreiben, würde er das sicher nicht in purem "C" machen, außer vielleicht die allerallerrudimentärsten Funktionen, die nötig sind, um einen gemanagten Kernel hochzuziehen, und danach zur Laufzeit diese rudimentären Funktionen auch gleich wieder entladen.
Onkel Darwin schrieb: > Wer (der es nicht muss) "quält" 1) sich schon freiwillig mit Zeugs rum, > für das sich auch bereits bewährte Alternativen anbieten? Vor allem wenn > letztere sich bereits lange in Entwicklung und damit ziemlich in hohem > Maße gereift sind. Was verstehst du unter bewährte Alternativen? Wenn ich Multithreading nutzen will, nützt es mir nicht viel das es C oder C++ schon so lange gibt. Ich müsste mich da für längere Zeit einarbeiten, bevor ich stabile Software entwickeln kann. Und danach musst du trotzdem immer aufpassen dass du trotz Erfahrung keine Fehler machst. Bei Rust arbeitest du dich auch einmal mühsam in die neuen Konzepte ein aber danach garantiert dir der Compiler dass bestimmte schwerwiegende Fehler ausgeschlossen sind. Onkel Darwin schrieb: > Wo stehen denn z.B. die noch vor gar nicht so langer Zeit gehypten > Sprachen wie go und Nim? > > Man hört Nim-mer viel .. Bevor Python oder Java erfolgreich wurden, gab es auch andere Programmiersprachen die gescheitert sind. Das Sprachen kommen und gehen sagt nicht viel über Rust aus. Was deine konkreten Beispiele angeht: Go wird immer noch genutzt aber kann aus Performance Gründen C++ nicht überall ersetzen. Ich denke es war auch nicht das Ziel damit Sprachen wie C++ in der gesamten Industrie zu ersetzen. Und Nim? Ich hörte davon, aber ich glaube Nim bei weitem nicht so weit wie Rust bisher.
Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. der Sprache annehmen werden und sie unterstützen wollen. Deshalb nehme ich an, daß Rust genau wie andere Sprachen offiziell von den relevanten Standardorganisationen anerkannt werden muß. Letztens hängt Adoption auch von zusätzlicher notwendiger Industrie Bürokratie ab. Der embedded Bereich muß auch besonders berücksichtigt werden. Auch Debugging und Simulation sind wahrscheinlich wichtige Gesichtspunkte. Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt durchsetzen können welche Sprachen für Produktentwicklung verwendet werden sollen. Deshalb nehme ich an, daß man geduldig sein werden muß um zu erleben wie sich die Adoption ausspielen wird. Die Inertia der Menschen ist oft der wirkliche Hinderungsgrund warum neue Paradigmen so lange brauchen um Fuß zu fassen. Erschwerend für eine Adoption werden dann manche Kunden auch darauf bestehen ein komplettes Rust Entwicklungspackage wie z.B. IAR Workbench für Rust bestellen zu können wo die praktischen Berücksichtigungen der realen Welt vorhanden sind. Bis dahin wird man schon abwarten müssen. Die Geeks mögen von Rust verzaubert sein, trotzdem fürchte ich, daß gerade das nicht genug ist. OK. Jetzt dürft ihr auf mich hauen wenn ihr könnt:-)
:
Bearbeitet durch User
So, jetzt auch mal meine Meinung zu Rust an sich, nicht das "Ja, du hast geschrieben: dies; ich sage dazu: das!" Prinzipiell finde ich die Idee von Rust sehr gut. Vom Konzept her wäre Rust gut geeignet gerade im Embedded-Bereich auf kleinen Controllern, wo die Projekte ja schon aus Speichergründen nicht unbedingt ausufern, und die Art der Ressourcen-Verwaltung in Rust in ein riesiger Fortschritt. Traits gefallen mir auch, die fördern eine klare Trennung von Daten und Methoden. In der klassischen Objektorientierung, die ja akademisch immer noch so gelehrt wird, sind Daten und Methoden immer brav in einer Klasse verpackt, aber in der Praxis ist das nur noch Ballast (Stichwort "Puppet-Player-Pattern", TDA, OCP). Was mich (das ist natürlich immer Geschmackssache) in vielen Punkten stört, ist die Syntax. Die sieht mir inkonsistent aus. Zum Einen ist es im Zeitalter der großen IDEs (seien es VS xyz, sei es Eclipse) absolut sinnfrei, ein Wörtchen wie "function" abzukürzen. Zum Zweiten, so gut ich es finde, dass Curlys zwangsweise sind (guter Stil in jeder Curly-Sprache heutzutage), kommt dann das Weglassen von runden Klammern wie etwas komplett Gegensätzliches daher und scheint ein gewisses Anbiedern an Python und sonstige Whitespace-Sprachen zu sein. Moderne Programmiersprachen sind nicht mehr auf Tipp-Effizienz, sondern auf klare Syntax ausgelegt UND stören nicht mehr mit künstlichen Störenfrieden wie * und &. C# ist z.B. mindestens so "C"-Style wie Rust, verzichtet aber auf solche Stolpersteine komplett, ebenso auf :, :: und -> außer in unsafe-Bereichen. Moderne Programmiersprachen achten viel mehr auf Lesbarkeit als der olle Kram von "damals, als alles besser war" (eigentlich ja doch schrecklicher). Oder mag wirklich jemand die Sternchen-Orgien in "C" bei Funktionszeigern oder die ollen & und -> in C++? Ein nicht besonders großes, aber hübsches Syntax-Gimmick ist, dass es keinen Unterschied mehr zwischen for- und for-each-Schleifen gibt. Braucht kein Mensch, richtig so. Das konnte schon lange wirklich mal weg! ^^
:
Bearbeitet durch User
Gerhard O. schrieb: > Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark > davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. > der Sprache annehmen werden und sie unterstützen wollen. Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern bzw. kaufen? Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch aufspringen und eine smarte Saftpresse zuhause haben. Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen Leben, da wo Geld verdient wird, eigentlich ist.
Olaf schrieb: > Er koennte bezueglich Fehler aber auch sehr viel > besser sein wenn er von sehr vielen Leuten verwendet wird die alle zur > Verbesserung beitragen. Finde den Fehler... Es gibt sehr viel Code, der von sehr vielen Leuten verwendet wird. Es gibt aber nur sehr, sehr, sehr wenig Code, der von sehr vielen Leuten verwendet wird, die da auch alle zur Verbesserung beitragen. Und die Frage, ob mehr Fehler in wenig genutzer Software besser sind, als wenige in viel genutzer, dürfte noch nicht endgültig ausdiskutiert sein. Oliver
Cyblord -. schrieb: > Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und > können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen > Leben, da wo Geld verdient wird, eigentlich ist. Da ist was dran, aber ich sage bewusst: leider. Wenn man sich die ganze Smart-Home-Szene ansieht, wo es sicher bald schon für Klospülungen ne App gibt (kennt noch wer diesen unsäglichen Werbespruch von Apple? "Ach, dafür gibt's doch bestimmt auch ne App!"), und wenn man das dann mal auf den Automotive-Bereich abstrahiert, dann Herzlichen Glückwunsch! Das ist so ein bisschen wie in der alten Zeit mit Dampfloks: "Was labern die da über Elektrifizierung! Ich steh hier mit 1000 Tonnen am Haken an der Steigung, und die Räder drehen durch!" Ob es nun Rust wird oder ne andere Sprache mit zeitgemäßen Konzepten, ist mir relativ. Andererseits bin ich faul, und wenn ich die Wahl zwischen Rust und Python haben müsste, würde ich eher Rust nehmen, weil sie mir vertrauter aussieht aka schneller vom Lernen zur Produktion. Ich bin (anders als andere hier) kein Fanboy, aber alleine schon das Ressourcen-Konzept ist ne bedenkenswerte Sache. Das Argument "das hilft mir doch aber jetzt nicht!" ist ein Zeichen von mangelnder Planung und vor allem von einer Mischung aus zu vielen Aufträgen und zu niedrigen Stunden-/Projektpreisen. Und ja, ich weiß, wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim ersten Release einigermaßen stabil läuft. (Bevor mich wer disst: Unternehmen sind meist "Gellschaften" (GmbH, AG...), drum "sie".)
:
Bearbeitet durch User
Cyblord -. schrieb: > Gerhard O. schrieb: >> Ob Rust in der Industrie Fuß fassen wird hängt wahrscheinlich doch stark >> davon ab ob sich die Platzhirsche der Compilertoolfirmen wie IAR & Co. >> der Sprache annehmen werden und sie unterstützen wollen. > > Und warum sollten sie? Welcher z.B. Industriekunde würde das fordern > bzw. kaufen? > Solche Modesprachen existieren nur in ganz kleinen Blasen irgendwelcher > akademischen Brainfucks und OO-Hipstern die auf jeden Quatsch > aufspringen und eine smarte Saftpresse zuhause haben. > > Gerade die Mitglieder dieser Gruppen verkennen die reale Situation und > können anscheinend schlecht einordnen, wie irrelevant Rust im wirklichen > Leben, da wo Geld verdient wird, eigentlich ist. Das sehe ich möglicherweise positiver als Du. Ich bin der Meinung, daß man Rust fairerweise einfach Zeit lassen muß um Fuß fassen zu können. Das geht deshalb nicht so schnell weil noch viele Erfahrungen in der realen Welt gesammelt werden müssen. Um im weiteren Bereich verwendet zu werden ist Standard Adoptierung hier absolut notwendig; geht aber nicht so schnell. Bis dahin werde ich mit Interesse die Entwicklung mit offenen Augen verfolgen. Bei C und C++ war es auch nicht viel anders.
Carsten P. schrieb: > Und ja, ich weiß, > wie knifflig bis unmöglich es ist, ner Kundin beizubiegen, dass sie auch > was davon hat, wenn wir verlässlicheren Code schreiben, der gleich beim > ersten Release einigermaßen stabil läuft. Was der zwar zunächst Geld spart, das die dann später doppelt wieder ausgibt, wenn der ganze Kram wegen Unwartbarkeit auf Grund einer Exotenprogrammiersprache in die Tonne gekloppt werden muß. Ich will jetzt nicht sagen, daß Rust dieses Schicksal droht, aber es ist noch nicht übern Berg. Oliver
Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein allgemeiner Aspekt der mir Sorgen macht: Wegen der Komplexität und Device Intercommunication moderner verbundener Anwendungen werden sehr oft Teile der Anwendung mit eingebunden komplexen externen Ressourcen verwendet die nicht immer im Quellenformat zur Überprüfung erhältlich sind. Oft müssen BT, WLAN und Ähnliches funktionieren weil die Kunden alles über Smartphone und Internet steuern wollen. Erschwerend kommt dazu, daß nicht alle Programmierer Genies sind und man sich schwer tut Probleme oder Sicherheitslücken zu erkennen bzw. Diagnostizieren zu können. Wenn das tatsächlich so ist, dann ist Produktentwicklung fast immer ein riskante Sache und die Sprache vielleicht nur sekundär wichtig. Auch wenn Rust z.B. schwerer durch böswillige Elemente zu hintergehen ist, können die eingebundenen extern entwickelten Ressourcen alle durch die Sprache gegebene Robustheit wieder total zunichte machen. Um bessere externe Sicherheit zu erzielen müssten die Probleme an der Wurzel angefasst werden. Ob man dann in C++ oder Rust programmiert ist so gesehen nicht mehr so wichtig. Was notwendig ist, externe Stacks zu finden, die robust genug sind, Attacken gehörig zu erschweren. Wie man den Rest der Anwendung kodiert ist dann nicht mehr so kritisch wenn man nicht gerade groben Unfug macht. Ob ich hier mit meinen Ausführungen etwas angeschnitten habe was wichtig ist, kann ich praktisch nicht so gut beurteilen weil ich in Sachen "Verbundenheit" nicht viel mache und ihr müsst es wahrscheinlich besser wissen wie man sichere verbundene Apps und Geräte realisiert. Noch am Rande, man sieht in den Medien und Reklame immer öfters wie man Smartphones zur Bedienung, Öffnung der Autoschlösser usw. anpreist. Ehrlich gesagt mir wäre es zu blöd jedesmal ein Handy suchen und bedienen zu müssen um in mein Auto einsteigen zu können. Es mag sich zwar sexy ansehen, aber irgendwie finde ich ist dieser ganze Trend überzogen. Ein Handy mag in gewissen Situationen auf diese Weise nützlich sein, aber nicht um jeden Preis alles vernetzen zu wollen. Gerade diese Sachen verursachen die meisten Sicherheitslücken.
Carsten P. schrieb: > kommt dann das Weglassen von > runden Klammern wie etwas komplett Gegensätzliches daher Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung abschalten. Eine Zeile in der compiler-config.
Syntax hat man schnell gelernt. Man schaut einmal auf ein Script, dann kennt man die Syntax. Das selbe einfach mit anderen Klammern / Keywords schreiben, das ist einfach. Aber plötzlich ändern müssen, wie man ein Programm schreibt, die Herangehensweise ändern müssen, und plötzlich gewisse Sachen nicht mehr so lösen zu können, wie man das immer überall sonst gemacht hat - das ist nicht einfach. C -> Python ist ersteres. C -> Rust ist letzteres. Beim Umstieg zu Rust kommt noch dazu, oft weiss man, das ist in Ordnung, aber dann sollte man das eigentlich auch noch dem Compiler beweisen. Da fängt dann wahre Frustration an. Ich und der Compiler - wir haben beide starke Meinungen, wie wir das lieber umgesetzt sehen wollen...
🐧 DPA 🐧 schrieb: > Ich und der Compiler - wir haben beide starke Meinungen, > wie wir das lieber umgesetzt sehen wollen... Das ist jetzt nicht böse gemeint, eher als "frohes neues Jahr"... Dann schreib dir doch deinen eigenen Compiler! ;-)
MaWin schrieb: > Carsten P. schrieb: >> kommt dann das Weglassen von >> runden Klammern wie etwas komplett Gegensätzliches daher > > Du kannst ja runde Klammern nutzen, wenn du das möchtest. Der > Rust-Compiler hindert dich nicht daran. Du musst nur die Warnung > abschalten. Eine Zeile in der compiler-config. Gut zu wissen. Ist echt mal ein Thema zum sich näher mit beschäftigen, und die nächsten Tage finde ich immer wieder mal ein bisschen Leerlauf. Nennt sich "nicht existenter Urlaub", aber das Thema interessiert mich jetzt echt. Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen will, dann genauso wie ne C/C++-Lib?
> Dazu kommt, daß in vielen Firmen die Entwickler nicht unbedingt > durchsetzen können welche Sprachen für Produktentwicklung verwendet > werden sollen. Ich sehe du hast Industrieerfahrung. .-) Wenn man die Frage aus dem Subject beantworten moechte dann sollte man sich vielleicht mal fragen wie kam es im Embeddedbereich zu dieser EXTREMEN C Dominanz. Irgendwie war die Sprache irgendwann da, irgendwie hat sie jeder verwendet und keiner hat es je diskutiert. Das hat mich auch immer gewundert. Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da kam noch nie jemand der Gedanke das man was anderes verwenden koennte. Das ist vollkommen anders als auf dem PC. Daher denke ich das Rust und jede andere Sprache zumindest im Embeddedbereich eine lustige Modeerscheinung bleiben wird. Aehnlich wie FORTH oder Pearl. Es ist einfach so das die ganze Industrie extrem konservativ ist. Ich bin mir sicher das wir noch die 100Jahrfeier von 4-20mA und C erleben werden. :-D Olaf
Carsten P. schrieb: > Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen > will, dann genauso wie ne C/C++-Lib? Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage anlegen. Wenn es das ist, was du meinst.
Olaf schrieb: > Pearl Meinst du Perl? Das wird leider sehr massiv in der Embedded-Entwicklung verwendet. Aber ich denke bei Perl haben mittlerweile viele Leute verstanden, dass es nicht mehr zeitgemäß ist. Sogar die Perl-Entwickler scheinen das wohl verstanden zu haben und bauen die Sprache nun nach modernen Mustern um. > Ich bin mir sicher das wir noch die 100Jahrfeier von > 4-20mA und C erleben werden. :-D Ja, da bin ich mir leider auch sicher.
Gerhard O. schrieb: > Gehört nicht unbedingt zum Thema und ist O.T., aber hier ist noch ein > allgemeiner Aspekt der mir Sorgen macht: > > Wegen der Komplexität und Device Intercommunication moderner verbundener > Anwendungen werden sehr oft Teile der Anwendung mit eingebunden > komplexen externen Ressourcen verwendet die nicht immer im Quellenformat > zur Überprüfung erhältlich sind. Im Ernst, Gerhard, wenn das OT ist, ist das ganze Forum OT. Es gibt derzeit wohl kaum ein überall heißer diskutiertes Thema in der ganzen IT-Branche als genau das da! Deswegen verbaue ich nirgendwo auch nur zwei Devices ("Dinge" im Sinne von IoT), ohne dass ich einen Knoten dazwischen habe, der die Kisten überwacht. Bei uns ist es geschäftlich und bei mir ist es privat auch so, dass kein Teil verwendet wird, das fröhlich über http oder noch tiefer im Layer unverschlüsselte Daten in die Welt posaunen darf, es sei denn, es sitzt zB wie ein einfacher Sensor so nah am nächsten Knoten, den wir wieder unter Kontrolle haben, dass du schon die Leitung anritzen müsstest, um da was abzugreifen. Ich konstruiere mal ein gar nicht so fiktives Beispiel: Du bist ein Einbrecher. Du hast die nötige technische (durchaus legal beschaffbare und auch nicht großartig aufs Konto schlagende) Hardware. Du willst natürlich wissen, wann wer zuhause ist. Das ganze Zuhause der Leute, die du ausrauben willst, ist natürlich super "smart" (eigentlich steindoof). Das Licht wird geschaltet, etwa im Flur, über gaaaanz smarte, übers WLAN angeschlossene Lichtschalter. Ja, die Daten sind verschlüsselt, die Hersteller sind ja nicht ganz bekloppt. Nur haben sie was vergessen. Also hältst du deine WLAN-Antenne da aufs Haus, fischst die Pakete ab, und stellst fest, dass OIZ324867yyxdf "Aus" bedeutet und 6jhgbsd76345r4 "Ein". Klingt harmlos. Nun stellst du auch fest, weil die Alarmanlage vom selben Hersteller und auch übers WLAN ("dafür gibt's doch bestimmt ne App!") läuft, dass 9786dfkjhTX&% "Alarm ein" und PIUz876r54gh "Alarm aus" bedeuten. Jetzt kannst du ja mal probieren, mit derselben IP (weil du natürlich im Promisk-Modus gelauscht hast) das Signal "Lampe ein" zu schicken". Wenn das geht, könnte ja vielleicht auch "Alarm aus" funktionieren. Da musst du überhaupt nicht wissen, was die Daten wirklich bedeuten. Der Trick ist übrigens schon weit verbreitet bei Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und wiedergeben. Würde der entsprechende Coder auf die Idee gekommen sein, einen Timestamp mit zu verschlüsseln, wäre das alles hinfällig. Aber wie man weiß, ist dem nicht so. Vielleicht, weil er nicht weit genug denkt, vielleicht aber auch, weil sein Chef im gesagt hat, dass bei 100.000 gebauten Autos 10 Cent für den uC schon seinen Bonus ausmachen. Stromzähler sind übrigens für so eine Schwachstelle bereits vom CCC und anderen aufmerksamen Leuten ausgemacht. Die senden gerne den Zählerstand ans EVU, und mit ein paar gar nicht so geheimen Tricks kriegt man von außen raus, wann der Stromverbrauch hoch und wann niedrig ist. Angenommen, bei entsprechenden Stückzahlen kosten ein AtTiny45 45 und ein AtMega328 328 Cent. Da kannst du dir ja vorstellen, was der Controller beim Kunden sagt, wenn du mit Datensicherheit anfängst, während der an den Bonus denkt.
:
Bearbeitet durch User
Carsten P. schrieb: > Der Trick ist übrigens schon weit verbreitet bei > Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und > wiedergeben. Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. Und es ist hier völlig Off-Topic.
MaWin schrieb: > Carsten P. schrieb: >> Frage an dich Fachperson: Wenn ich eine Rust-Lib "von woanders" aufrufen >> will, dann genauso wie ne C/C++-Lib? > > Du kannst in Rust Symbole und Strukturen mit C-Layout und C-Linkage > anlegen. Wenn es das ist, was du meinst. Ja, genau, das meinte ich, also so, dass ich sie von außen mit anderen Sprachen aufrufen kann wie ne "C"-Lib.
Olaf schrieb: > Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. 1) Es gibt C-Compiler für jedes Target. 2) Es ist kein Problem, C-Entwickler zu finden. 3) C ist relativ einfach. Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra einen Coding-Spezialisten einstellen würde, den man aber für eine komplizierte Sprache bräuchte.
MaWin schrieb: > Carsten P. schrieb: >> Der Trick ist übrigens schon weit verbreitet bei >> Auto-Dieben, die einfach das Signal des Funk-Schlüssels aufzeichnen und >> wiedergeben. > > Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei > Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. Komisch, dass die Mediatheken voll davon sind, und die sind damals, vor 20 Jahren, natürlich deswegen mit ner 16:9 Arri aufgenommen worden, als noch niemand an HD dachte, damit es heute authentisch wirkt... ^^ So viele kluge Sachen du manchmal schreibst, MaWin, manchmal schießt du deiner Glaubwürdigkeit selbst ins Knie ;-)
Nop schrieb: > 3) C ist relativ einfach. Definiere "relativ" ^^ Wir wissen alle, dass das totaler Quatsch ist. Aus Sicht eines BWLers vielleicht. Aber technisch gesehen ist blankes "C" genauso "einfach" wie Assembler. Wenn du schonmal ernsthafte (das heißt kommerziell in großen Stückzahlen verwendete und sicherheitstechnisch relevante) Software entwickelt als mit einem Nicht-Coder als Vorgesetztem, Kunden oder whatnot, weißt du, wie schnell aus der mal eben hin geschnodderten "Machbarkeitsstudie" ein Denkmal wird, das nicht mehr gemeißelt, sondern nur noch angemalt wird. Ich jedenfalls erinnere mich sehr gut daran, dass ich vor uff... knapp 30 Jahren? meinem damaligen Chef zeigte, wie man von nem PERL-Script im Sekunden-Takt Texte an nen Webbrowser (der hieß damals noch Netscape Navigator) schickt, bis er verstanden hatte, dass man daraus nen Chat bauen könnte, und der musste dann natürlich in ner Woche fertig sein. Sowas wie ne Anmeldung (ohne E-Mail-Prüfung, keine Zeit) hab ich dann nach Feierabend dazu gecodet. Das Ding ist weit gewachsen, aber an echte Sicherheit, also echte Authentifizierung hat damals keine Sau gedacht. Und die Fehler in dem hin gerotzten Code wurden natürlich gnadenlos aufgedeckt. Aber selbst dann fand mein Chef, nö, das tut's, das bringt Geld, keine Zeit, weiter zum nächsten Projekt. Heute sind manche Chefs anders und sensibler für solche Themen. Aber eben nicht alle, und genau da entstehen die @MaWin "irgendwelchen Scheunentore".
Nop schrieb: > Der dritte Punkt ist insofern relevant, als daß das eigentliche Coding > oftmals nur ein kleiner Teil der Arbeit ist, für den man nicht extra > einen Coding-Spezialisten einstellen würde, den man aber für eine > komplizierte Sprache bräuchte. Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert. Rust dreht das herum. Das Coden ist etwas schwieriger. Dafür ist das Debugging aber deutlich einfacher und beschränkt sich nur noch auf logische Fehler. It works, if it compiles. Das ist zwar natürlich etwas überspitzt ausgedrückt, aber es steckt doch ein großer Teil Wahrheit drin. Deshalb macht außerdem auch deutlich mehr Spaß.
Olaf schrieb: > Und noch erstaunlicher, C ist da mittlerweile seit 20Jahren dominant. Da > kam noch nie jemand der Gedanke das man was anderes verwenden koennte. Davor wurden Controller halt vorrangig in Assembler programmiert. C war da schon mal eine mächtige Verbesserung, weil man mit vergleichsweise geringen Einbußen an Laufzeiteffizienz eine drastische Verbesserung der Coding-Effizienz erzielen kann und (auch wenn hier alle über C dahingehend unken) ganz gewiss auch eine drastische Verbesserung der Sicherheit. Wer sich (durchaus zu Recht) über die Sicherheitslücken beklagt, die mit C möglich sind, der sollte sich einfach mal vergegenwärtigen, wie das alles mit Assemblercode aussähe. ;-) Nun wiederum, einen einmal etablierten Platzhirsch zu vertreiben, ist keine so leichte Aufgabe. So groß dürfte der Leidensdruck, C an dieser Stelle abzulösen, bei vielen Programmierern im Embedded-Bereich *) nicht sein. Gerhard hat ja viele Punkte genannt. Die Verheiratung einer Sprache mit einem eigenen Buildsystem dürfte einem solchen Ansinnen auch nicht gerade förderlich sein. *) Ich meine hier mit "Embedded" nicht so'n Highlevel-Kram wie Smartphone & Co. Alles, was mit einem fetten Betriebssystem daher kommt, ist in dieser Hinsicht ja eher PC-mäßig. Ich meine den wirklichen Lowlevel-Kram, der bis vor 30 Jahren komplett in Assembler war (8051 waren die ersten, bei denen dann jemand mit Compilern angetreten war).
MaWin schrieb: > Das ist richtig. Jedoch ist das Debugging in C relativ kompliziert. Kann ich nicht bestätigen. Zumal man embedded sowieso noch nen MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert werden, die gerne verkehrt gemacht werden. Da man embedded auch etliche Sachen meistens schlichtweg nicht benutzt, wie z.B. dynamische Speicherallozierung, sind die damit einhergehenden Fehler natürlich auch ausgeschlossen.
Nop schrieb: > Kann ich nicht bestätigen. Hast du schon einmal Rust probiert um einen Vergleich zu bekommen? > Zumal man embedded sowieso noch nen > MISRA-Checker drüberlaufen läßt, womit etliche Konstrukte angemeckert > werden, die gerne verkehrt gemacht werden. Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Der deutlich mehr Dinge prüft, weil sie erst durch die Sprache Rust prüfbar werden. Der dir auch noch Vorschläge macht, wie du die Warnungen und Fehler beheben kannst. Meistens stimmen die Vorschläge auch, oder sie lenken einen wenigstens eindeutig auf die richtige Lösung hin. > dynamische Speicherallozierung, sind die damit einhergehenden > Fehler natürlich auch ausgeschlossen. Dynamische Speicherverwaltung ist nur ein winziger Teil der Dinge, die Rust deutlich besser beherrscht als C (und auch besser als C++. Double-Free/Use-after-free ist in Rust nicht möglich). Außerdem gelten die Rust Speicherkonzepte auch für statische Allokation und Stackallokation.
Carsten P. schrieb: >> Replay-Attacks funktionieren seit 20 Jahren nicht mehr bei >> Autoschlüsseln und bei allen anderen Arten von Crypto-Funkschaltern. > > Komisch, dass die Mediatheken voll davon sind, Bei Crypto-Funkschaltern mag das so sein. Der Angriff auf Autos funktioniert ganz anders. Und weil das tatsächlich seit Jahren duch alle Mediakanäle getrieben wurde, sollte das jeder problemlos auseinander halten können. Oliver
Jörg W. schrieb: > Die Verheiratung einer Sprache mit einem eigenen Buildsystem Das ist, wie mehrfach schon gesagt, nicht wahr. Du kannst Rust ohne weiteres und insbesondere im Embedded-Bereich auch mit Make oder jedem anderen Tool verwenden.
MaWin schrieb: > Double-Free/Use-after-free ist in Rust nicht möglich). Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das benötigt aber Code zur Laufzeit. Den kann auch Rust nicht wegzaubern. D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff und es müssen ständig Datenstrukturen im Speicher mitgeführt werden, um solche Dinge abfangen zu können. In der System- und Embedded-Entwicklung will und kann man das aber meistens nicht.
:
Bearbeitet durch User
MaWin schrieb: > Hast du schon einmal Rust probiert um einen Vergleich zu bekommen? Ich habe keine speziellen Debugging-Probleme in C festgestellt, die überhaupt einer Lösung bedürften. Wenn, dann klemmt es algorithmisch, aber das wäre in jeder programmiersprache so. > Und jetzt stelle dir Rust wie einen Misra-Checker auf Steroiden vor. Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging in C tatsächlich nicht gibt?
Cyblord -. schrieb: >> Double-Free/Use-after-free ist in Rust nicht möglich). > Solche checks sind ja toll. Genauso wie das Prüfen von Arraygrenzen. Das > benötigt aber Code zur Laufzeit. Nein, benötigt es nicht. Das prüfen von Allokationen passiert komplett zur Compilezeit und das Prüfen von Arraygrenzen auch zu einem sehr großen Teil. > D.h. da läuft dann ständig irgendwelcher Code für JEDEN Arrayzugriff Nein. Wenn der Array-Index nicht beliebig sein kann, dann wird das zur Compilezeit aufgelöst. Außerdem braucht man in Rust deutlich seltener Arrays, als in C. Mit Rust-Enums zum Beispiel kann man viele Dinge tun, die man in C mit C-Enums und Arrays machen würde. > und es müssen ständig Datenstrukturen im Speicher mitgeführt werden Ständig nicht. Aber teilweise natürlich schon. Ein Slice ist zum Beispiel ein Zeiger und eine Länge. Aber das ist in C auch nicht anders. An den Stellen, wo du in Rust ein Slice verwendest, würdest du in C einen Pointer und ein Längen-Integer manuell mitschleppen. Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C.
Nop schrieb: > Schön, aber der Leidensdruck ist schlichtweg nicht da. Wozu eine > deutlich kompliziertere Sprache, wenn es das angebliche Horrordebugging > in C tatsächlich nicht gibt? Ja, dann ist doch alles gut. Niemand zwingt dich.
MaWin schrieb: > Nein, benötigt es nicht. > Das prüfen von Allokationen passiert komplett zur Compilezeit und das > Prüfen von Arraygrenzen auch zu einem sehr großen Teil. Ahso alles zur Compilezeit. Also wenn es dynamische Allokation gibt, dann muss man auch Grenzen zur Laufzeit prüfen. > Wenn der Array-Index nicht beliebig sein kann, dann wird das zur > Compilezeit aufgelöst. Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index kann jederzeit von einer Eingabe zur Laufzeit abhängen. > Rust hat hier praktisch keinen Laufzeitnachteil gegenüber C. Jaja bla blubb. Erzähls deinen Hipster-Freunden. Es gibt nur zwei Möglichkeiten: Entweder du kannst relativ ungestört direkt in den Speicher reingreifen oder jeder Fetzen Speicher ist abgesichert, was aber Datenstrukturen und Code braucht, der Checks ausführt. Das kann man nicht wegdiskutieren.
:
Bearbeitet durch User
Cyblord -. schrieb: > Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index > kann jederzeit von einer Eingabe zur Laufzeit abhängen. Praktisches Beispiel: eine for-Schleife über alle Deine Temperatursensoren, deren Werte in einem Array stecken. Da kann der Compiler durchaus statisch ermitteln, ob das Array mit ausreichender Größe deklariert ist.
Nop schrieb: > Cyblord -. schrieb: > >> Und wenn deine Tante Eier hätte wäre sie dein Onkel. Der konkrete Index >> kann jederzeit von einer Eingabe zur Laufzeit abhängen. > > Praktisches Beispiel: eine for-Schleife über alle Deine > Temperatursensoren, deren Werte in einem Array stecken. Da kann der > Compiler durchaus statisch ermitteln, ob das Array mit ausreichender > Größe deklariert ist. Das kann jedes PCLINT finden. Was bringt ein statisches Beispiel? Ein einziges dynamisches Beispiel und du brauchst den Check zur Laufzeit. Deshalb ist diese Sicherheit eben kein Verdienst von Rust, sondern muss in jedem Fall erkauft werden. Die Sprachdefinition und die möglichen Checks zur Compilezeit sind Kindergarten. Statische Codeanalyse wurde schon vor ner Weile erfunden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Das kann jedes PCLINT finden. Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer ohne Längeninformation verflacht.
Nop schrieb: > Cyblord -. schrieb: > >> Das kann jedes PCLINT finden. > > Aber nicht, wenn Du das Array als Parameter einer Funktion übergibst, Doch ganz sicher. > womöglich noch in einer anderen TU, weil es in C dann zu einem Pointer > ohne Längeninformation verflacht. Ja und wie sieht dein statischer Check aus, wenn ich einen Index über UART empfange?
Wobei es natürlich bessere statische Code-Checker für C gibt, die auch interprozedurale Analyse können - aber PC-Lint speziell kann es halt nicht.
Cyblord -. schrieb: > Also wenn es dynamische Allokation gibt, > dann muss man auch Grenzen zur Laufzeit prüfen. Ja. Genau wie in C. > Der konkrete Index > kann jederzeit von einer Eingabe zur Laufzeit abhängen. In dem Fall musst du das in C auch prüfen. > Das kann man nicht wegdiskutieren. Ja, doch. Rust ist halt sehr viel ausdrucksreicher als C. Die Enums habe ich ja bereits genannt. Die sind halt zur Compilezeit komplett prüfbar. Man kann in Rust halt Dinge ausdrücken, die in C gar nicht möglich sind. Und wenn es dann wirklich diese eine Stelle gibt, die sooooooooooo performancekritisch ist und es dort auch gar nicht möglich ist das in Rust zu formulieren ohne Performanceoverhead, dann hat man immer noch die Möglichkeit von Unsafe-Rust. Da kannst du dich nach Herzenslust mit ungeprüfter C-Pointerarithmetik austoben. Aber es kommt praktisch nicht vor, dass das notwendig ist, weil man eigentlich alles in Rust performant ausdrücken kann. Performance ist ein Designziel von Rust! > Jaja bla blubb. Erzähls deinen Hipster-Freunden. Mit dem Argument hast du mich jetzt natürlich überzeugt ;)
Nop schrieb: > Wobei es natürlich bessere statische Code-Checker für C gibt, die auch > interprozedurale Analyse können - aber PC-Lint speziell kann es halt > nicht. Ja dann nimmst Klocwork. Rust brauch ich dafür immer noch nicht. Und wie dynamische Indizes ohne zusätzlichen Code und Daten geprüft werden kannst du sicher aufzeigen.
MaWin schrieb: > In dem Fall musst du das in C auch prüfen. Nein, ich KANN. Ich muss aber nicht. Vor allem wird kein Zwangsweise Code erzeugt der das prüft.
Nop schrieb: > Praktisches Beispiel: eine for-Schleife über alle Deine > Temperatursensoren, deren Werte in einem Array stecken. Da kann der > Compiler durchaus statisch ermitteln, ob das Array mit ausreichender > Größe deklariert ist. Ja, sogar in C geht das meistens. In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und nicht so ein Unfug mit Array-Pointer-Decay gemacht wird.
Cyblord -. schrieb: > Ja und wie sieht dein statischer Check aus, wenn ich einen Index über > UART empfange? Es gibt ihn nicht. Genauso wenig, wie es ihn in C gibt.
MaWin schrieb: > In Rust geht es aber öfter, weil Arrays vernünftig typisiert sind und > nicht so ein Unfug mit Array-Pointer-Decay gemacht wird. Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Oder wie wandle ich sowas in ein Byte-Array um es z.B. über einen UART zu senden? Kann Rust beim Deserialisieren (Empfang über UART) prüfen ob das Objekt den korrekten Typ hat? Und das auch noch ohne zusätzlichen Speicher?
Cyblord -. schrieb: > Nein, ich KANN. Ich muss aber nicht. Ja, genau. Das ist ja das Problem. > Vor allem wird kein Zwangsweise Code erzeugt der das prüft. In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du unbedingt scharf auf Sicherheitslücken bist.
Cyblord -. schrieb: > Dann kann Rust wohl keine Objekte/Strukturen serialisieren? Wie kommst du jetzt darauf? https://crates.io/crates/serde
MaWin O. schrieb: > In Unsafe-Rust kannst du auch ungeprüfte Zugriffe verwenden, wenn du > unbedingt scharf auf Sicherheitslücken bist. Tja in C will man eben relativ viel Freiheit mit einigermaßen ordentlichen Datentypen, Strukturen und Kontrollmechanismen. Wer das nicht will, nimmt C#, Java oder halt Rust. Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur Laufzeit aus. Darum geht es mir. Es ist nicht die tolle Sprache die irgendwas sicher macht, sondern die Unmengen an automatisch erzeugtem Code. Deshalb wird es C nicht ablösen. Weil man genau deshalb C verwendet um das nicht zu haben. Es gab schon genug Versuche mit Java auf Embedded. Und viele ähnliche Scherze. Am Ende ist das alles nur viel aufgeblasener Code um ein paar Zeilen produktiv Code in einem sicheren Setting zu schreiben.
Cyblord -. schrieb: > Es gab schon genug Versuche mit Java auf Embedded. Das Problem dabei war doch wohl vielmehr der GC, und den hat Rust nicht. Das Problem von Rust ist IMO eher, daß es zu kompliziert ist - und wenn die Leute, die embedded C verwenden, bislang eine kompliziertere Sprache gewollt hätten, dann hätten sie schon längst auf C++ umgestellt. Insofern ist Rust eher ein potentieller Ersatz für C++, nicht für C.
MaWin O. schrieb: >> Dann kann Rust wohl keine Objekte/Strukturen serialisieren? > > Wie kommst du jetzt darauf? > > https://crates.io/crates/serde Natürlich bietet Rust diese Funktionalität, aber der Punkt ist, wenn du ein Objekt in einen Bytestrom verwandelst, dann hast du auch keine Sicherheit mehr. Außer du baust mit zusätzlichen Daten wieder was drum rum. Nichts anderes passiert in C wenn man direkt in den Speicher einer Struktur oder eines Arrays reingreift. Und manchmal muss man das eben, z.B. mit angesprochenen Fall um das über UART zu senden.
Cyblord -. schrieb: > Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur > Laufzeit aus. Darum geht es mir. Ja. Darum geht es dir. Es ist aber falsch.
Cyblord -. schrieb: > Nichts anderes passiert in C Schön, dass du es doch noch eingesehen hast. Rust ist in diesem Aspekt nicht langsamer als C.
MaWin O. schrieb: > Cyblord -. schrieb: >> Nur kommen diese ganzen Checks eben nicht ohne Code und Daten zur >> Laufzeit aus. Darum geht es mir. > > Ja. Darum geht es dir. > > Es ist aber falsch. Dann zeig auf, wie ein dynamischer Index ohne Laufzeit und Daten von Rust geprüft wird. Minimalbeispiel:
1 | int a[100]; |
2 | int x=receiveUART(); |
3 | int d=a[x]; |
MaWin O. schrieb: > Rust ist in diesem Aspekt nicht langsamer als C. Dann kann Rust in diesem Aspekt auch nicht sicherer sein. Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben.
:
Bearbeitet durch User
Wenn du z.B. ein Array a[n] und eins b[m] hast, und dann eins c[n+m], musst du nicht wissen, was n und m sind, um zu wissen, dass c[0:n] und c[n:m] darin liegen. Wenn du das für c[i] wissen willst, und du weist nichts über i (z.B. user gibt es ein) muss gecheckt werden ob es platz hat. Aber das muss man dann auch in c. Man braucht nur genug Metadaten beim Kompilieren.
Cyblord -. schrieb: > In der System- und Embedded-Entwicklung will und kann man das aber > meistens nicht. Ich lese mich ja gerade in Rust ein wenig ein, weil ich mir die Zeit dafür nehme. Erstens ist es natürlich mit nem (verschmerzenswerten) Overhead (das meiste passiert zur Compile-Zeit) verbunden, aber meine Antwort auf deine Aussage lautet unabhängig von der Programmiersprache: Wer das nicht WILL, wird irgendwann (sehr bald) den Bach runter gehen. Embedded ist nicht Zuse in der Neuzeit. Die Anforderungen gerade im Embedded-Bereich sind Sicherheit, Sicherheit, und bevor ich es vergesse: Sicherheit! Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer falschen Programmierung von Airbags zigtausend Autos in die Werkstatt zurück rufen musst. Wenn du schlau warst, hast du jede Haftung ausgeschlossen im Vertrag... Wessen Maxime in diesem Bereich nur billig, billig! uuuund billig! ist, wird sich eher früher als später wundern, wenn er mit Klagen überrissen wird. Diese "ich weiß schon, was ich mache"-Attitüde ist einfach Mist. Ein Embedded-Coder hier, der seinen kompletten Code mit Unit-Tests überzieht? Test-driven? Clean Code anyone? Im Ernst, wenn die Produkte weiter nur auf billig, billig gebaut werden, darf sich niemand wundern, wenn die genauso miesen, aber nur halb so teuren Sachen aus China den Markt dumpen.
Cyblord -. schrieb: > Minimalbeispiel: > >
1 | > int a[100]; |
2 | > int x=receiveUART(); |
3 | > int d=a[x]; |
4 | >
|
Du prüfst also nicht, ob x > 100 ist? Oh, wow, ich hoffe, du programmierst keine Airbags... Achso, es ging um Rust. Jepp, das kriegt Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von receiveUART() prüft und dann feststellt, ob er die Array-Grenze überschreiten kann. Das könnte ein entsprechender "C"-Compiler aber auch, so ne Schlampigkeit feststellen ^^
:
Bearbeitet durch User
Carsten P. schrieb: > Du prüfst also nicht, ob x > 100 ist? Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch prüft. > Achso, es ging um Rust. Jepp, das kriegt > Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von > receiveUART() prüft und dann feststellt, ob er die Array-Grenze > überschreiten kann. Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART reinkommt?
Carsten P. schrieb: > Es liegt natürlich an deinem Naturelle, ob du damit leben kannst, dass > dein Auftraggeber nach ein paar Toten und Schwerverletzten wegen einer > falschen Programmierung von Airbags zigtausend Autos in die Werkstatt > zurück rufen musst. Wenn du schlau warst, hast du jede Haftung > ausgeschlossen im Vertrag... Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Oliver
Oliver S. schrieb: > Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze > Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Die sind wohl alle in Rust programmiert ;-)
Oliver S. schrieb: > Nur mal nebenbei gefragt, da es Airbags ja nun doch schon eine ganze > Weile gibt: wie oft ist das denn bisher weltweit mal vorgekommen? Speziell bei Airbags nun nicht, aber das Beispiel des Toyota Camry ist ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß hat man den Stack auch noch nach unten hin auf die globalen Daten (oder den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, weil der Rust-Compiler sich auf eine korrekte Umgebung genauso verläßt wie ein C-Compiler. Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein C-Fehler, sondern ein Fehler im Systemdesign. Der Maximalausschlag des Höhenruders wurde nachträglich deutlich vergrößert, und dann hätte man das System nicht mehr mit nur einem Sensor betreiben dürfen. Hat man aber, obwohl man sogar physikalisch zwei Sensoren hatte, weil man den dann erhöhten Zertifizierungsaufwand einsaparen wollte.
Cyblord -. schrieb: > Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch > prüft. Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch machbar ist, hast du ihn zur Compilezeit, keine Frage. Lässt er sich nur zur Laufzeit ausführen, dann müsstest du ihn für ein sicheres C- (oder Assembler-)Programm dort ebenfalls zur Laufzeit durchführen, daher sollte der Overhead vergleichbar sein.
Cyblord -. schrieb: > Carsten P. schrieb: > >> Du prüfst also nicht, ob x > 100 ist? > > Es ging ja darum dass Rust dies anscheinend ohne Overhead automatisch > prüft. > >> Achso, es ging um Rust. Jepp, das kriegt >> Rust hin, zur Übersetzungszeit bereits, weil es den Rückgabewert von >> receiveUART() prüft und dann feststellt, ob er die Array-Grenze >> überschreiten kann. > > Erstaunlich. Es kann in die Zukunft sehen welcher Wert über den UART > reinkommt? Ja, natürlich. Der Index von a ist maximal 99. Wenn receiveUART() ein uint8 zurückgibt, ist der größte Wert dort 255, also größer als 99. Das ist doch kein Hexenwerk...
Cyblord -. schrieb: >> Rust ist in diesem Aspekt nicht langsamer als C. > > Dann kann Rust in diesem Aspekt auch nicht sicherer sein. > Laufzeitchecks gibt es nicht umsonst. Kann es nicht geben. Ja, Ok. Ich habs verstanden. Du willst ganz offensichtlich nur provozieren und stellst dich bewusst dumm. Ich beende das Spiel an dieser Stelle.
Nop schrieb: > und zu allem Überfluß > hat man den Stack auch noch nach unten hin auf die globalen Daten (oder > den Heap) zuwachsen lassen. Das könnte wohl auch in Rust passieren, Nein, kann es natürlich nicht. Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Jörg W. schrieb: > Naja: es prüft mit einem vergleichbaren Overhead. Wenn der Test statisch > machbar ist, hast du ihn zur Compilezeit, keine Frage. Wenigstens einer, der es verstanden hat. Ist aber auch gar nicht so schwer eigentlich :)
Beitrag #6930470 wurde von einem Moderator gelöscht.
MaWin O. schrieb: > Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu klein ist? Glaube ich nicht.
Nop schrieb: > Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu > klein ist? Das hat niemand behauptet.
MaWin O. schrieb: > Das hat niemand behauptet. Doch, hast Du gerade. Alternativ, was wahrscheinlicher ist, hast Du das von mir beschriebene Problem nicht verstanden.
Nop schrieb: > Echt? Der Compiler weiß beim Übersetzen, daß der Stack auf dem Target zu > klein ist? Glaube ich nicht. Wissen tue ich es auch nicht, aber was hält den Compiler, auch bei genügend präzise angegebenen Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie groß der Stack werden darf? Wir reden hier von Embedded, ich jedenfalls, nicht von virtualisierten Maschinen auf virtualisierenden Servern.
Nop schrieb: > Doch, hast Du gerade. Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und somit beweisen kann, dass ich es nicht behauptet habe?
MaWin O. schrieb: > Nop schrieb: >> Doch, hast Du gerade. > > Bitte? Du weißt schon, dass man in einem Forum alles nachlesen kann und > somit beweisen kann, dass ich es nicht behauptet habe? Hast Du, und zwar hier: MaWin O. schrieb: > Nein, kann es natürlich nicht. > Rust ist memory-safe. Das gilt selbstverständlich auch für den Stack. Du hast dabei nicht berücksichtigt, daß ein Stacküberlauf gar nicht im Fokus des Compilers sein kann, weil der Compiler nichts von der Stackdimensionierung weiß. Das wird erst beim Linken klar, und dann reden wir über LLVM, nicht mehr von Rust. Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß das Environment so funktioniert, wie es das sollte.
Carsten P. schrieb: > aber was hält den Compiler, auch bei genügend präzise angegebenen > Targets als Cross-Compiler, davon ab, das zur Übersetzung zu wissen, wie > groß der Stack werden darf? Einerseits call trees, die von äußeren Einflüssen (beispielsweise Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Bei Rekursionen kann er bestenfalls eine worst-case-Annahme treffen (wenn beispielsweise durch den Datentyp, der die Rekursion steuert, eine maximale Rekursionstiefe ermittelbar ist), aber die kann natürlich meilenweit über im praktischen Betrieb auftretenden realen Anforderungen dann liegen. Dann ist es zwar sicher, aber u.U. derart überalloziert, dass es auf der realen Maschine nicht mehr nutzbar ist, weil sie gar nicht so viel Speicher für den Stack bereitstellen kann. Für eine virtual-memory-Architektur spielt das nicht so'ne große Geige (der Stack ist ja dann nur VM, und wenn der real nicht ausgenutzt wird, muss er nicht durch realen Speicher abgedeckt werden), aber auf einem kleinen Controller kann das ein Problem werden. Sowas kann auch keine Sprache in sich absichern, wenn man derartige Probleme hat. Man kann dann höchstens Monte-Carlo-Simulationen durchspielen, die für typische Szenarien ermitteln, wieviel STack tatsächlich gebraucht wird. In einem realen System würde mann dann in irgendeiner Form eine "Notbremse" einbauen die greift, wenn sich herausstellt, dass der allozierte Stack doch mal nicht reicht (geht natürlich am einfachsten, wenn die Zielarchitektur eine MMU dafür anbietet).
Nop schrieb: > Der Rust-Compiler verläßt sich genauso wie ein C-Compiler darauf, daß > das Environment so funktioniert, wie es das sollte. Nein, das ist halt ganz einfach falsch. Rust geht in ein Panic (und damit in ein Recovery) bei einem Stacküberlauf.
MaWin O. schrieb: > Rust geht in ein Panic (und damit in ein Recovery) bei einem > Stacküberlauf. Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch mitspielen. Embedded und bare metal wird das so nichts werden. Abgesehen davon wäre das auch kaum besser, wenn mitten während der Fahrzeugregulierung das Programm einfach mal neu startet.
Jörg W. schrieb: > Einerseits call trees, die von äußeren Einflüssen (beispielsweise > Eingabegrößen) abhängen, andererseits natürlich Rekursionen. Japp. Korrekt. Anders als andere (einer) hier, behaupte ich auch nicht, dass sowas nicht möglich ist. Ich sage nur, dass ein gut geschneiderter Compiler sehr viel davon verhindern kann. Natürlich kannst du jede Laufzeit und jeden Compiler mit böser Absicht oder (wie du sagtest, Eingaben) genügend hilflosen Anwendern (Coder, die deinen Code linken, sind auch Anwender) in die Knie zwingen. Da fehlt aber gerade in der Hardware noch eine Menge Hirnschmalz, gerade bei kleinen uCs, also dass sie Threads von sich aus ausknipsen, wenn sie gewisse Stack-Grenzen überschreiten. Außer manchen (einem) behauptet ja aber auch niemand, dass Rust die einzige und perfekte Sprache/Laufzeit ist. Rust setzt an typischen Fehlerquellen an, wo ein Compiler bereits rein grätschen kann, und das ist, finde ich, ein sehr guter Ansatz. Natürlich wäre es süß, wenn auch ein AtTiny ne VM Umgebung herstellen könnte, aber dann würde er nicht 30 Cent, sondern 5 Euro mindestens kosten. So dumm ich das Argument selber finde, so sehr zieht es doch einerseits durch den Kostendruck aus anderen Regionen dieser Welt ALS AUCH vom Gerede mancher Entwickler, dass das alles kein Problem sei.
Nop schrieb: > das Beispiel des Toyota Camry ist > ja bekannt, und da gab es Tote. Das lag allerdings nicht an einem > C-Fehler, sondern an unzureichender Stackanalyse, und zu allem Überfluß > hat man den Stack auch noch nach unten hin auf die globalen Daten (oder > den Heap) zuwachsen lassen. Hm. Du hast doch dafür sicherlich eine Quelle. Meines Wissens nach ist die ganze Sache dort sehr viel komplexer gewesen, und ist bis heute nicht abschließend geklärt. > Das jünste Beispiel mit den Boeing-Abstürzen wiederum war auch kein > C-Fehler, sondern ein Fehler im Systemdesign. So war das wohl. Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch nicht verhindert. Oliver
Nop schrieb: > Das tut er unter Linux, weil das Betriebssystem und die Runtime da noch > mitspielen. Embedded und bare metal wird das so nichts werden. Weil du das sagst? Warum genau soll Rust nicht prüfen können, ob der Stack überläuft? > Abgesehen > davon wäre das auch kaum besser, wenn mitten während der > Fahrzeugregulierung das Programm einfach mal neu startet. Ja doch. Ein Neustart ist 1000 mal besser, als UB durch Memory-Corruption. Neustarts von Steuergeräten während der Fahrt passieren "ständig" (d.h. öfter als du denkst).
Oliver S. schrieb: > Hm. Du hast doch dafür sicherlich eine Quelle. Die Google-Stichworte lauten wenig überraschend: toyota camry stack overflow Da findest Du jede Menge dazu. Es war jedenfalls eine der Ursachen. > Rust mag ja einige haarsträubende Ecken von C(++) umschiffen, aber die > Fehler, die in diesen realen Projekten gemacht wurden, hätte das auch > nicht verhindert. Richtig. Das kann man Rust natürlich nicht ankreiden, aber es sind halt mal zwei Beispiele mit Toten, wo "wir machen alles in Rust" nichts geholfen hätte. Insofern sollte man da auch nicht übermütig werden. Wenn ich hier dann im Kontext von embedded-Entwicklung lese, Rust habe keine potentiellen Stackprobleme (haben auch C-Programme übrigens unter Linux nicht - die werden auch beendet), sieht das schon stark nach Risiko-Kompensation aus, was wiederum ein Risiko darstellt.
MaWin O. schrieb: > Warum genau soll Rust nicht prüfen können, ob der Stack überläuft? Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Die Speichersicherheit bezieht sich auf die Anwendung und nicht darauf, daß das Environment außerhalb des Rust-Programms ein Problem hat. Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, was das Programm dann abbricht. Es geht hier aber um embedded und bare metal, nicht um Linuxanwendungen. > Ja doch. Ein Neustart ist 1000 mal besser Bei nennenswertem Tempo mit aktiver ASR wäre ein Neustart ebenso fatal.
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=6ba3452d2c1eeb9b3c9c3f3fa236b77a > thread 'main' has overflowed its stack > fatal runtime error: stack overflow Komisch, gell? Wo Rust das doch angeblich gar nicht erkennen kann?
Ach ja, abgesehen davon weiß der Rust-Compiler gar nicht, wie groß der Stack überhaupt ist. Unter Linux ist das Sache des Betriebssystems, und bare metal wird das erst beim Linken klar - und dann reden wir über LLVM, lange nach dem Rust-Compiler.
Nop schrieb: > Weil Rust explizit auf Geschwindigkeit und "kein Runtime-Overhead" > entwickelt wurde, und bei jedem Dekrementieren des Stackpointers vorher > einen Runtime-Check zu machen wäre ein erheblicher Runtime-Overhead. Nein, wäre es nicht. Das wäre eine einzige Abfrage pro Funktion. Im Mittel deutlich weniger. > Die Speichersicherheit bezieht sich auf die Anwendung Ja eben. Die Anwendung macht die Allokation. Könnte die Anwendung durch Speicherallokation UB hervorrufen, wäre das "unsound". Unsoundness und UB gibt es in Rust nicht. > Das, was Du als Beispiel brachtest, wird vom OS bereitgestellt, Nein.
MaWin O. schrieb: > Ja eben. Die Anwendung macht die Allokation. Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem Beispiel ja offensichtlich statisch ist. Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen Kernel) hat, weil wir hier über embedded-Controller reden.
Aus demselben Grund wird übrigens ein C-Programm mit Stackoverflow unter Linux ebenfalls problemlos beendet.
Nop schrieb: > Denk mal drüber nach, wieso das überhaupt ein Runtime-Fehler ist und > nicht ein Compiletime-Fehler, obwohl die Stack-Allokation in Deinem > Beispiel ja offensichtlich statisch ist. Ich habe nie gesagt, dass das ein Compiletime-Fehler ist. > Das kommt daher, daß man über Guardpages geht, was auf Kernel-Level ein > Segfault ist - blöd halt, wenn man gar keine Pages (und auch keinen > Kernel) hat, Es ist völlig unerheblich, ob ein Kernel existiert oder nicht. Die x86/x64-Implementiertung nutzt eine Guardpage. Das ist ein MMU-Feature. Das heißt aber nicht, dass man zwingend einen Kernel braucht. Und es heißt auch nicht, dass man eine MMU braucht. Man kann auch eine Memory-Protection-Unit verwenden. Oder wenn man die nicht hat, kann man den Stack in einen anderen ungültigen Bereich wachsen lassen. Sicher wirds auch irgendwelche Architekturen geben, die gar keine Traps bereitstellen für sowas. Aber selbst dort kann der Compiler selbstverständlich eine architekturspezifische Abrage machen. Macht Rust das derzeit bei allen Architekturen? Nein, denn... > weil wir hier über embedded-Controller reden. Wir reden hier hauptsächlich über Rust. Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme (kleiner als Raspberry Pi), schrieb ich ja bereits.
MaWin O. schrieb: > Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme > (kleiner als Raspberry Pi), schrieb ich ja bereits. Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C durch Rust.
MaWin O. schrieb: > Macht Rust das derzeit bei allen Architekturen? Nein, denn... ... es ist kein Teil des Rust-Sprachstandards. Oh wait - Rust HAT ja gar keinen Sprach-Standard, sondern ist das, was auch immer der einzige Rust-Compiler gerade tut. Wodurch man übrigens nichtmal einen Compiler-Bug von einem Feature unterscheiden kann, denn gegen welche Spec sollte man das auch prüfen. > Dass Rust derzeit noch nicht "fertig" ist für alle Embeddedsysteme > (kleiner als Raspberry Pi), schrieb ich ja bereits. Mit anderen Worten: Dir war klar, daß Dein Beispiel embedded gar nicht funktionieren würde, aber Du hast es trotzdem mal versucht - ich hätte es ja schlucken können, ne?
Nop schrieb: > Dir war klar, daß Dein Beispiel embedded gar nicht > funktionieren würde, aber Du hast es trotzdem mal versucht Ach komm... Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann. Und das ist halt falsch. Cyblord -. schrieb: > Jaja, aber wir schwadronieren schon mal vorsorglich vom Ersetzen von C > durch Rust. Wir? Du? Ich jedenfalls nicht. Kannst du ja gerne nachlesen. Ich habe schon mehrfach betont, dass es mir egal ist, was ihr nutzt.
MaWin O. schrieb: > Es wurde behauptet, dass Rust sowas grundsätzlich nicht erkennen kann. > Und das ist halt falsch. Mit derselben Logik wäre das bei C auch kein Problem gewesen: unter Linux wird auch ein C-Programm bei einem Stackoverflow abgebrochen. Dummerweise war es aber kein Linuxsystem.
Nop schrieb: > Mit derselben Logik wäre das bei C auch kein Problem gewesen Richtig. Ich habe nicht behauptet, dass C das nicht auch kann. Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht.
MaWin O. schrieb: > Ihr wart aber diejenigen, die behauptet haben, Rust könne das nicht. Was Du ja dann ja auch eingestanden hast, nachdem Du erstmal den Unterschied zwischen bare metal und einem Linuxrechner verstanden hast. Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen C-Compiler denken, der vor jedem SP-Dekrement erstmal einen Runtime-Check macht. Hätte, hätte, Fahrradkette.
Nop schrieb: > Was Du ja dann ja auch eingestanden hast Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich nie gesagt habe. Ok? Man kann das hier alles nachlesen. Ok? Gut.
MaWin O. schrieb: > Oh bitte. Höre einfach damit auf mir Dinge in den Mund zu legen, die ich > nie gesagt habe. Ok? Dann hör einfach auf, halbgaren Quatsch zu erzählen und mit unsinnigen Beispielen zu "belegen", die nur darauf bauen, daß andere nicht genauer hinsehen.
Nop schrieb: > Dann hör einfach auf, halbgaren Quatsch zu erzählen Ja, genau. Höre du bitte auf damit. Ok? Die Diskussion ging nicht von mir aus. Ich habe nicht die Behauptung mit dem unbehandelbaren Stackoverflow (a.k.a. halbgarer Quatsch) ins Spiel gebracht.
Nop schrieb: > Die Google-Stichworte lauten wenig überraschend: > toyota camry stack overflow > Da findest Du jede Menge dazu. Eben nicht, daher frage ich ja. Ein Stack Overflow war eine der denkbaren Ursachen, neben einer Zillion anderen, die aus der Komplexität des Systems resultieren. Immerhin war das ein zweikanaliges Sicherheitssystem. Da das Verfahren aber abgeschlossen ist, wird’s dazu auch keine neuen Erkenntnisse geben. Oliver
Oliver S. schrieb: > Eben nicht Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier: https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/
> Olaf schrieb: > > Pearl > Meinst du Perl? Nein, ich meinte schon Pearl. Sonst haette es wohl kaum als Embedded Beispiel aus der Anfangszeit von C getaugt. Olaf
Nop schrieb: > Im Übrigen könnte man sich selbstverständlich auch einen hypothetischen > C-Compiler denken, der vor jedem SP-Dekrement erstmal einen > Runtime-Check macht. Geht eigentlich nur, wenn die CPU-Architektur das hergibt (also letztlich durch eine MMU). Wenn man das mit Maschinenbefehlen manuell bewerkstelligen will, wird es nicht nur schnarchlangsam, sondern man hat gute Chancen, dass man schon mal irgendein Register auf den Stack pushen muss, um überhaupt erstmal Platz für den Test zu haben … Dann ist es aber ganz unabhängig von der Sprache implementierbar (auch auf Controllern mit MMU, aber das sind halt nicht mehr die allerkleinsten). Da kommt einem aber sofort wieder "Steinbach's guideline of systems programming" in den Sinn … die klingt zwar hart, aber wenn man auf einem Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, dann hat man im konkreten Fall eh ein Problem.
Jörg W. schrieb: > Wenn man das mit Maschinenbefehlen manuell > bewerkstelligen will, wird es nicht nur schnarchlangsam Ein Laden, ein Vergleich und ein bedingter Sprung pro Funktion, sofern der Stackframe am Funktionsanfang komplett aufgebaut wird. Der Overhead wäre schon deutlich. > sondern man hat > gute Chancen, dass man schon mal irgendein Register auf den Stack pushen > muss, um überhaupt erstmal Platz für den Test zu haben … Das wäre leicht abzufrühstücken, indem nicht getestet wird, ob der Stack überschritten sein wird, sondern eine bestimmte minimale Reserve bleibt. Die könnte man dann für register spill im Funktions-Prolog des nächsten Levels nutzen. > aber wenn man auf einem > Controller gar keinen sinnvollen Ausweg hat, weil man nur noch zwischen > Pest (undefined behaviour) und Cholera (spontaneous reboot) wählen kann, > dann hat man im konkreten Fall eh ein Problem. Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Der Calltree ist größenteils bekannt, dann noch Interrupts in worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger gehen können. Bei den Projektgrößen, die man auf MMU-losen Systemen so hat, ist das kein Problem. Bei uns ist das in Prozeß-Checklisten als vorgeschriebener Teil jedes Software-Releases durchzuführen. Ohne Stackanalyse gibt's kein Release, auch nicht für Software ohne Sicherheitsrelevanz. Im Ernstfall wäre es nämlich langwierig und damit teuer, sporadischen Problemen im Feld nachzuspüren, und sowas würde mit dem Zeitplan laufender Projekte kollidieren.
Nop schrieb: > Das wäre leicht abzufrühstücken > Das kann man aber mit statischer Stackanalyse in den Griff kriegen. Das ist ja erstaunlich, wie schnell du von - das geht gar nicht! - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist das gar nicht bekannt wie groß der Stack ist! - Rust kann das überhaupt nicht! - Du unterstellst mir bewusste Irreführung. dich wandelst zu: > Das wäre leicht abzufrühstücken > Das kann man aber mit statischer Stackanalyse in den Griff kriegen.
Nop schrieb: > Oliver S. schrieb: > >> Eben nicht > > Du mußt die Links natürlich auch schon anklicken. ;-) Etwa diesen hier: > https://embeddedgurus.com/state-space/2014/02/are-we-shooting-ourselves-in-the-foot-with-stack-overflow/ Habe ich. Und sogar gelesen. Die darin zitierte Untersuchung und auch den Foliensatz kannte ich schon vorher. Da steht drin, daß ein Stackoverflow eine wahrscheinliche Ursache gewesen sein könnte, und als Bewies wird angeführt, daß die Misra nicht eingehalten haben. Bewiesen ist der Fehler nicht, und schon gar keine schuldige Codestelle identifiziert. Es steht auch drin, daß auch Hardwarefehler, kippende Bits, und ein Haufen anderer schöner Dinge die Ursache hätten sein können. Andere Untersuchungen zeigen, daß auch deren real-time-Annahmen auf die Kante genäht waren, usw. Toyota sagt, daß deren fail safe System all diese Fehler abgefangen hätte, kann das aber auch nicht beweisen. Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene. Oliver
Oliver S. schrieb: > Fest steht mir, daß Rust an all dem nichts geändert hätte. Die Probleme > liegen alle oberhalb der von Rust eingezogenen Sicherheitsebene. Ja, das ist ziemlich wahrscheinlich. Es geht bei Rust ja erst einmal auch nicht um Safety, sondern um Security. Das sind zwei grundverschiedene Dinge, auch wenn die Ursachen für Safety-Fehlfunktionen denen von Security-Fehlfunktionen ähneln können. Im Systemdesign unterscheiden die Gegenmaßnahmen sich aber erheblich.
MaWin O. schrieb: > - Das kann der Compiler prinzipiell nicht, weil Linker und überhaupt ist > das gar nicht bekannt wie groß der Stack ist! Es war im Kontext von "Speichersicherheit ohne Runtime-Overhead". Du wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Das ist auch der Grund, wieso Rust unter Linux auf Guard-Pages setzt, die keinen Overhead verursachen, solange kein Stackoverflow passiert. Mit Runtime-Overhead kann man das natürlich in jeden Compiler einbauen, aber das ist dann kein Rust-Feature, sondern jede C-Implementation könnte das auch tun. Insofern ist es auch da korrekt, wenn man sagt, daß Rust als Sprache da gar nichts garantiert, ebensowenig wie C.
Nop schrieb: > "Speichersicherheit ohne Runtime-Overhead". Du > wirst Dich erinnern, daß dies eines der zentralen Rust-Features ist. Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne Runtime-Overhead in Rust realisiert ist. Und schon gar nicht, dass dies ein zentrales Rust-Feature ist. Bitte bleibe bei der Wahrheit. Man kann hier alles nachlesen, was du im Nachhinein falsch verdrehst. Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar mit dem Overhead, den man in korrekten C-Programmen auch hätte. Das ist eines der zentralen Rust-Features. Und nichts anderes wurde hier gesagt.
Oliver S. schrieb: > und als Bewies wird angeführt, daß die Misra nicht > eingehalten haben. Das war schon ein bißchen mehr als nur MISRA-Mißachtung. > Bewiesen ist der Fehler nicht Derartige Fehler kann man auch schwerlich beweisen, weil es sehr seltene, sporadische Fehler sind. Sonst wäre das bei Testfahrten schon aufgefallen. > und schon gar keine schuldige Codestelle identifiziert. Bei Stackoverflow gibt es in dem Sinne auch keine schuldige Codestelle, wenn man die Stackdimensionierung selber nicht als solche durchgehen läßt, weil es z.B. bei Interrupts sehr davon abhängt, in welcher zeitlichen Abfolge sie mit Blick auf ihre Priorisierung anfallen und in welcher Tiefe des ISR-Calltrees der nächste Interrupt eintrifft. Das ist übrigens auch der Grund, wieso "den Stack vorher mit einem Testmuster füllen, das System laufen lassen und gucken, bis wo der Stack genutzt wurde" keine brauchbare Verifikationsmethode darstellt. Das ergibt nämlich nur eine untere Schranke für den Stackbedarf. Damit kann man lediglich die ohnehin fällige worst-case-Analyse einem Plausibilitäts-Check unterziehen.
MaWin O. schrieb: > Niemand hat behauptet, dass Speichersicherheit grundsätzlich ohne > Runtime-Overhead in Rust realisiert ist. Was bare metal und Stackoverflow angeht, ist sie sogar überhaupt nicht implementiert, wie Du nach diversen Versuchen des Rauswindens dann eingestanden hast. Sie ist also ganz offensichtlich nicht Teil der Sprache selber. > Speichersicherheit mit wenig Runtime-Overhead, im Mittel vergleichbar > mit dem Overhead, den man in korrekten C-Programmen auch hätte. Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, weil eine dem C-Standard entsprechende Umgebung compilerseitig vorausgesetzt wird. Also genauso wie bei Rust und bare metal.
Nop schrieb: > nach diversen Versuchen des Rauswindens dann eingestanden hast. Das kannst du mehrfach behaupten, aber es stimmt halt nicht. Du kannst hier im Thread nachlesen, wie ich schon vor einiger Zeit gesagt habe, dass Rust derzeit noch nicht auf kleinen Embedded-Systemen stabil ist. Das gilt nach wie vor. Und das war lange bevor du deine Nebelkerzen zum Stackoverflow gezündet hast. > Ein korrektes C-Programm braucht keinerlei Stacküberprüfung zu machen, > weil eine dem C-Standard entsprechende Umgebung compilerseitig > vorausgesetzt wird. Also genauso wie bei Rust und bare metal. Wo ist dann dein Problem? Es wurde hier behauptet, dass ein Rustprogramm grundsätzlich keine Stackprüfung machen könne. Ich habe bewiesen, dass es doch eine Prüfung macht. Du hast halt Unrecht gehabt. Passiert jedem mal. Nicht schlimm. Ich habe nichts über C gesagt. Ich habe nicht gesagt, was besser und was schlechter ist.
Beitrag #6930724 wurde von einem Moderator gelöscht.
Nop schrieb im Beitrag #6930724: > Leider schon wieder gelogen. Warum greifst du mich persönlich an? > Der resultierende Segfault im Kernel ist ohne OS-Unterstützung so nicht drin. Selbstverständlich ist das ohne Kernelunterstützung implementierbar. Glaubst du der Kernel wäre etwas magisches, was irgendwas aus dem Hut zaubert? Es ist sogar ohne MMU-Unterstützung implementierbar, wenn die Hardware minimalste Protection-Mechanismen hat. Und es ist auch ohne MPU implementierbar, wenn man den Stack so platzieren kann, dass beim Überlauf ein Zugriff auf einen ungültigen Bereich stattfindet und dieser ein Trap auslöst. Und es ist auch ohne Trap lösbar, indem man alle Stackveränderungen ganz einfach prüft.
Beitrag #6930740 wurde von einem Moderator gelöscht.
Beitrag #6930742 wurde von einem Moderator gelöscht.
Beitrag #6930744 wurde von einem Moderator gelöscht.
Beitrag #6930751 wurde von einem Moderator gelöscht.
Nop schrieb: > Der Calltree ist größenteils bekannt, dann noch Interrupts in > worst-case-Schachtelung, und ein paar Calls, die über Funktionszeiger > gehen können. Klappt halt so nur, solange die Stacknutzung nicht zu stark von den (nicht exakt vorhersagbaren) Eingabedaten abhängt. Klar, alles was statisch machbar ist, ist eh immer am einfachsten. Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf Kante genäht“ sein. Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-) Kann schon sein, dass Rust auch in diesem Bereich künftig noch an Boden gewinnt, aber im Moment sehe ich das noch nicht um die Ecke lugen. Ein Auftraggeber, für den ich letztens gearbeitet habe (mit durchaus sehr experimentierfreudigen Entwicklern), hatte es für eine Embedded-Lösung auf deutlich höherem Niveau (embedded Linux auf größerer STM-Plattform) initial in Erwägung gezogen, aber dann doch wieder verworfen und herkömmlich in C++ gearbeitet. Bei denen ist auch funktionale Sicherheit ein Thema, und der ganze Krams muss dann durch eine Zertifizierung durch.
Jörg W. schrieb: > Klappt halt so nur, solange die Stacknutzung nicht zu stark von den > (nicht exakt vorhersagbaren) Eingabedaten abhängt. Der Trick ist, daß man ja nicht die exakte Nutzung braucht, sondern nur eine verläßliche obere Schranke. Daher kann man die Eingabedaten mehr oder weniger ignorieren und geht einfach den Calltree durch, auch wenn der u.U. so in derser Kombo nicht unbedingt passieren kann. > Im Zweifelsfalle, wenn man Sicherheit braucht, darf dann aber eben auch > die Hardware weder von der Geschwindigkeit noch vom Speicherausbau „auf > Kante genäht“ sein. Klar, also beim Stackverbrauch wird ja auch immer noch ein wenig Reserve gefordert. > Aber ja, mit Rust hat das alles jetzt nichts mehr zu tun. :-) Nur noch am Rande. ;-) > Bei denen ist auch funktionale Sicherheit > ein Thema, und der ganze Krams muss dann durch eine Zertifizierung > durch. Da wird man dann noch so einiges an Lösungen brauchen, mindestens was für statement coverage. Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal einen Compilerbug von einem Sprachfeature unterscheiden kann. Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht.
Bzgl. gelöschte Beiträge: Bitte freundlich bleiben, andere der Lüge zu bezichtigen ist kein Teil einer sachlichen Diskussion.
Nop schrieb: > ohne ISO-Standard sehe ich den auch nicht Ein ISO-Standard wiederum ist ein ganz schön großer Haufen an Arbeit, die keinerlei "Hack value" hat. Einfach nur Arbeit, administrativ, editorisch. Aber man könnte ihn – anders als bei Pascal – ja an den realen Features des existierenden Compilers fest machen. :)
Nop schrieb: > Ein zertifizierter Compiler > ist in weiter Ferne Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Oder nutzt man die nur der Zertifizierung und dem dazugehörigen Haftungszeug wegen?
Moin, Huch, hier war ja richtig was los die Tage... Nop schrieb: > Mehr Sorgenfelder sehe ich darin, daß es nur einen einzigen Compiler > gibt, der zugleich auch noch der Sprachstandard ist, so daß man nichtmal > einen Compilerbug von einem Sprachfeature unterscheiden kann. > Kommerzieller Support ist auch nicht drin. Ein zertifizierter Compiler > ist in weiter Ferne, und ohne ISO-Standard sehe ich den auch nicht. Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, man muss ja kein Cargo nehmen..." auch von allen hier auftretenden MaWins nicht wirklich. Es aendern sich die Compilerversionen noch schneller als gute Entwicker ihre Unterhosen und Socken wechseln - ich glaub' bei sowas sollte auch der Diplom-Informatiker mit Fachrichtung Projektkasper doch mal kurz ins Gruebeln kommen, wie er dann, wenn er sowas aus Sicherheitsgruenden einsetzt, Probleme seinen Scheffs verkaufen will... Gruss WK
Dergute W. schrieb: > Es aendern sich die Compilerversionen noch schneller Und warum ist das schlecht? Ist gcc auch schlecht, weil es relativ oft Releases macht? https://gcc.gnu.org/releases.html Wenn du bei einem alten Compiler bleiben willst, dann bleibe halt bei einem alten Compiler. Warum auch nicht, wenn er deinen Code übersetzen kann? Niemand hat etwas dagegen. > Ja, und dagegen hilft auch das gebetsmuehlenhafte Vortragen von "Nein, > man muss ja kein Cargo nehmen..." Was hat jetzt Cargo genau mit Zertifizierung und ISO-Standard zu tun. Würde mich sehr interessieren, wenn du das einmal genauer erklärst.
Dergute W. schrieb: > Es aendern sich die Compilerversionen noch schneller als gute Entwicker > ihre Unterhosen und Socken wechseln Das würde sich übrigens ganz schnell geben, wenn man ein Standardisierungsgremium dafür aufbaut. Nur mal so, für den nächstes Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die letzten Papers, die neue Features einbringen können, im Oktober 2021. Im Laufe dieses Jahrs werden diese noch zu Ende gefeilt, und ab Sommer 2022 muss dann der eigentliche Formalismus für die Standardisierungsgremien (ISO, IEC, INCITS) in die Wege geleitet werden, damit der Standard nächstes Jahr fertig ist. Dabei ist die WG14 noch insgesamt recht wenig bürokratisch: bei den normalen Sitzungen gibt es keine formalen Abstimmungen (ballot), sondern nur Meinungsumfragen (straw polls), bei denen die Mehrheit der Anwesenden (also auch Gäste) entscheidet, da die jeweils Anwesenden als Expertengremium gehandhabt werden. Ergebnisse werden natürlich nur dann angenommen, wenn diese Umfragen eine hinreichend klare Linie ergeben, ansonsten muss der Antrag ggf. umformuliert und neu gestellt werden.
Jemand schrieb: > Sind eigentlich zertifizierte Compiler tatsächlich messbar besser? Besser, im Sinne von technisch weniger Bugs, ist ja gar nicht das Ziel einer Zertifizierung. So etwas enorm komplexes in einem Zertifizierungs-Regelwerk abzubilden, sodass keine Bugs mehr drin sein können, ist natürlich nicht möglich. Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Durch einen zertifizierten Compiler wurde noch nie auch eine einzige Fehlfunktion verhindert. Ganz im Gegensatz zum Testen und Bugfixen (des Compilers). Das verhindert Bugs. Leider verhindert oft genug gerade die Zertifizierung das Bugfixen des Compilers, weil dann müsste er ja neuzertifiziert werden. Was dann oft genug in Workarounds in Produktcode ausufert, um Compilerbugs zu umschiffen. Das ist dann "billiger".
Jörg W. schrieb: > Nur mal so, für den nächstes > Jahr zu veröffentlichen C-Standard (C23) war Annahmeschluss für die > letzten Papers, die neue Features einbringen können, Das ist nur nötig, weil C kaum Mechanismen und Regelwerke hat, Features vollständig rückwärtskompatibel einzubauen. Im Gegensatz zu Rust. Links dazu habe ich bereits gepostet.
MaWin schrieb: > Das ist nur nötig Sorry, aber du erzählst gerade Unsinn. Das hat mit C absolut nichts zu tun, sondern mit der Wirkungsweise von Standardisierungsgremien. (Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C höchstens, dass du diese Sprache nicht einmal kannst, geschweige denn ihre Standards. Aber der Thread hier ist natürlich nicht für die Diskussion über C da.)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Das hat mit C absolut nichts zu > tun, sondern mit der Wirkungsweise von Standardisierungsgremien. Natürlich. Der C-Standard hat mit C absolut gar nichts zu tun. "Es gibt nichts zu sehen hier! Gehen Sie weiter!" > dass du diese Sprache nicht einmal kannst Ich muss mich hier nicht rechtfertigen. Aber vielleicht du? Wie gut kennst du Rust? Ja, Rust hat keine formelle Standardisierung. Das bestreitet niemand. Aber Rust hat sehrwohl wirkungsvolle Mechanismen und Features vollständig rückwärtskompatibel zu diskutieren und zu stabilisieren.
Jörg W. schrieb: > Außerdem beweist deine Aussage über Nicht-Rückwärtskompatibilität von C Außerdem habe ich das nie gesagt. Lies meine Posts, bitte.
MaWin schrieb: > Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das > Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Dieselbe Argumentation kann man auch bei der zertifizierten Produktsoftware selber anbringen. Als Schlußfolgerung bleiben dann z.B. Flugzeuge, die nach Agil-Yolo entwickelt wurden. Wird bestimmt ein Verkaufs-Hit.
Nop schrieb: > Als Schlußfolgerung bleiben dann z.B. Flugzeuge, Das ist korrekt. Auch in Flugzeugen werden Bugs ausschließlich durch Tests und in Design-Reviews/Prozessen gefunden und gefixt. Niemals aber durch eine Zertifizierung des Compilers. Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht Zertifizierung von Entwicklungstools.
MaWin schrieb: > Standardisierte Entwicklungsprozesse sind es, as Safety schafft. Nicht > Zertifizierung von Entwicklungstools. Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. Viel Spaß dabei, diese Kosten zu stemmen, und das für jedes Projekt und jedes Update erneut. Mit Testen alleine kommst Du da nämlich nicht durch.
... überdies ist der Widerspruch offensichtlich: bei Produkten helfen standardisierte Entwicklungsprozesse, die überhaupt die Basis für die Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler gilt das natürlich nicht. Ja nee, ist klar.
Nop schrieb: > überhaupt die Basis für die > Produkt-Zertifizierung sind, der Produktqualität - aber für Compiler > gilt das natürlich nicht. Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine Compilerzertifizierung der Compilerqualität hilft. Nämlich gar nicht. Solle klar sein.
Nop schrieb: > Dann darfst Du bei den höheren Anforderungsleveln als Hersteller gerne > selber beweisen, daß der Maschinencode Deinem Sourcecode entspricht. Wie hilft mir die Zertifizierung dabei? Also technisch jetzt. Nicht rechtlich, durch das Verschieben der Verantwortung.
MaWin schrieb: > Eine Produktzertifizierung hilft der Produktqualität genau so, wie eine > Compilerzertifizierung der Compilerqualität hilft. > Nämlich gar nicht. Aber sicher doch. Deswegen werden Flugzeuge ja zertifiziert. Weil's nichts bringt. Daß die Luftfahrt massiv sicherer geworden ist, ist halt Zufall. Jedenfalls in Deinem Paralleluniversum. Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich befolgt, wären die Flieger nicht abgestürzt. Hätte die FAA ihren Job gemacht und nicht effektiv Boeing sich selbst beliebige Zertifikate ausstellen lassen, dann wären die Prozesse auch befolgt worden.
Nop schrieb: > Kleiner Denkanstoß: hätte man bei der 737-Max die Prozesse tatsächlich > befolgt, wären die Flieger nicht abgestürzt. Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist). Im Gegensatz zu Compilerzertifizierungen. Die helfen nur den Zertifizierungsunternehmen. Aber du wirst mir sicher wieder die Worte im Munde herumdrehen. Es ist alles nachlesbar und dokumentiert hier im Forum.
MaWin schrieb: > Ich habe bereits gesagt, dass Entwicklungsprozesse absolut und > unbestritten zur Qualität beitragen (bzw. dessen Grundlage ist). Was Du irgendwie nicht verstehst: Du bekommst keine Zertifizierung ohne den Nachweis entsprechender Entwicklungsprozesse. Das ist der Zweck einer Zertifizierung. Dementsprechend wirkt das bei Compilern ganz genauso wie bei anderen Produkten auch. In Deinem Paralleluniversum murkst man sich irgendeinen Mist zurecht, geht damit zu einem Zertifizierungsunternehmen, bekommt irgendeinen Wisch und ist zertifiziert. Kein Wunder, daß Du den Sinn nicht begreifst.
MaWin schrieb: > Es geht vielmehr darum, dass der Verkauf das Zertifikat-Label auf das > Produkt drucken darf und die QM-Abteilung ruhiggestellt wird. Also, MaWin mit oder ohne O, ich habe bisher einiges Nachdenkenswertes von dir gelesen, auch ein paar kluge Einwände, aber das ist jetzt echt mal kompletter Schwachsinn. Das, was du hier gerade schwafelst, ist, als wären Schuhgrößen, weil sie genormt und innerhalb der EU durch Standards diese Normen vereinheitlicht wurden, Unsinn. Also, du sagst, Normen, Zertifizierungen dieser Normen sind egal. Das würde z.B. bedeuten, dass du heute in München wohnst z.B., dort in einem Laden Schuhe in der Größe 42 kaufen kannst, im Laden nebenan knapp noch, irgendwas zwischen 41 und 43, dann ziehst du um nach Hamburg, dort heißen die Schuhgrößen Alpha, Beta, Gamma und Omikron, und aufgrund der Geschichte mit der Hanse sind die Tragweiten mit kyrillischen Buchstaben ausgezeichnet. Selbstverständlich gibt es in Hamburg Normen für Sohlen, die aber nur im Stadtgebiet von Hamburg und in einigen, aber nicht allen anderen Hansestädten gelten, was die Sicherheit angeht, falls sich die Sohle löst und du dir auf dem nicht weiter genormten Kopfsteinpflaster das Kinn brichst. Wenn du die Idee der Normen grundsätzlich ablehnst, ist das deine Sache. Wenn du aber die Idee der Zertifizierung entlang dieser Normen ablehnst, möchte ich nichtmal auf der Rückbank eines Taxis neben dir sitzen.
Carsten P. schrieb: > > Also, du sagst, Normen, [...] dieser Normen sind egal. > > Wenn du die Idee der Normen grundsätzlich ablehnst Wo habe ich das gesagt? Bitte zitieren. > Wenn du aber die Idee der Zertifizierung [...] ablehnst Ich sprach ausschließlich von der Zertifizierung von Compiler-Tools. Denn ebenjene bringen keinen Qualitätsgewinn. Die Compiler sind bereits sehr sehr gut. Compilerfehler treten praktisch nicht auf. Und das ist nicht der Verdienst der Zertifizierungen, sondern von Tests. Zertifizierungen im Compilerbereich bringen nur Nachteile, indem sie einen an ebenjene zertifizierte Compilerversion ketten. Auch wenn diese Version Bugs enthält. Von nichts anderem sprach ich. Es ging auch nicht um Produktzertifizierungen. Es ging auch nicht um genormte Prozesse und Produktnormen. Und auch nicht um irgendetwas beliebiges anderes. Das entspringt alles deiner Fantasie. Bitte bei der Wahrheit bleiben. Es ist alles hier nachlesbar, was ich geschrieben habe. Es bringt überhaupt nichts, mir etwas anzudichten, was ich nie geschrieben habe. Danke.
Und außerdem hat das überhaupt nichts mehr mit Rust zu tun. Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. Niemand hindert dich daran.
MaWin schrieb: > Wenn du den Rustcompiler zertifizieren willst, kannst du das gerne tun. Gegen was willst du den denn zertifizieren, wenn es keinen Standard gibt?
Jörg W. schrieb: > Gegen was willst du den denn zertifizieren, wenn es keinen Standard > gibt? Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel? An der Compilerqualität ändert es jedenfalls nichts. Egal, gegen was zertifiziert wird.
Vielleicht muß man nur geduldig sein. Gut Ding braucht Weil. War bei anderen Sprachen nicht anders. Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon herum gespielt? Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum Rust nicht auf kleinen 8-Bittern laufen wird? Oder ist da C/C++ momentan doch noch die beste Wahl. Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu müssen. Normalerweise liegt es mir daran mit iC Probleme zu lösen anstatt lösen zu müssen. Ich bin sicher, daß sich in ein paar Jahren die augenblicklichen Wogen legen werden und man Platform gerechte Lösungen finden wird. Schön wäre es schon, wenn man ein Rust Entwicklungssystem hätte ohne große Überraschungen und mit guten Low-Level Support. So wie es halt bei allen anderen uC der Fall ist. Es scheint, momentan wäre die STM32 Familie die einzige uC Familie die unterstützt wird. Ich wäre sehr an praktischen Erfolgsberichten interessiert. Also z.B. "Ich baute mir ein Gadget mit Rust auf STM32" und Informationen über die Erfahrungen durchs Projekt hindurch. Im Augenblick theoretisiert Ihr mir eigentlich zu viel und zu viele Generalitäten werden hin und her geworfen. Wenn Rust wirklich Fuß fassen sollen brauchen viele von uns doch konkrete Anhaltspunkte wie es anderen wagemutigeren Wegbereitern gegangen ist und wie man die anfänglichen Ungewissheiten beseitigen könnte. Es ist nicht genug wenn nur die Gurus und Genies unter Euch damit Erfolge erzielen. Wir sollten wirklich vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht mit Fakten untereinander helfen und Erfahrungen austauschen. Was mich betrifft, hätte ich an Rust nur im uC embedded Bereich praktisches Interesse.
Gerhard O. schrieb: > Wie gut wird sich Rust für kleinere uC bewähren? Gibt es Gründe warum > Rust nicht auf kleinen 8-Bittern laufen wird? Es gibt einen experimentellen Rustcompiler für AVR8. Er ist allerdings noch relativ weit vom Produktiveinsatz entfernt. Aber als Proof-of-Concept taugt er. > Ich bin an Rust schon etwas interessiert. Nur habe ich wenig Motivation > Pionierarbeit oder mich mit schwierigen Problemen herumschlagen zu > müssen. Auf allem, was ARM-Cortex (Raspbery Pi) oder größer (bis PC) ist, ist die Pionierarbeit schon lange geleistet und Rust ist dort produktiv einsetzbar. > STM32 Da kenne ich den Status leider nicht. > Im Augenblick theoretisiert Ihr mir eigentlich zu viel Ja, das sehe ich auch so. Viele Leute haben hier im Thread eine starke Meinung, aber fast niemand von diesen Leuten hat Rust einmal wirklich ausprobiert. Das wird offensichtlich aus den teilweise haarsträubenden Behauptungen. > Wir sollten wirklich > vermeiden "Fanboys" zu sein und uns anstatt gegenseitig so gut es geht > mit Fakten untereinander helfen und Erfahrungen austauschen. Volle Zustimmung. Weniger Gefühle und Meinung. Mehr Fakten und Erfahrung.
Gerhard O. schrieb: > Ich habe mir deren Webseite angesehen und gelesen, daß eine STM32 Bord > unter Rust praktisch demonstriert wird. Hat jemand von Euch damit schon > herum gespielt? Seit ca. 2 Jahren nutze ich ausschließlich Rust für alle meine STM32 Hobby Projekte. Unter anderem habe ich Niklas G.'s USB-Tutorial als Übung auf Rust portiert (wenngleich das eine meiner ersten Rust-Aktionen war und noch um einiges mehr unsafe Code aufwies als nötig). Cargo gefällt mir super, man muss nicht auf irgendwelche IDEs setzen die einem das Grundgerüst generieren, sondern mit paar Handgriffen (Target wählen, no-std deklarieren und PAC laden) baut "cargo build" einfach die binary für den STM. Einen Schritt weiter kann "cargo run" auch das ganze samt debug ausgaben ausführen, wenn man z.b. probe-run oder cargo-embed nutzt. Wenn ich mich an die Verrenkungen mit make oder cmake erinnere, war das um einiges aufwendiger. Was mich vor allem zu Rust bekehrt hat ist das Pattern matching. Anfangs dachte ich match ist einfach nur "sowas ähnliches wie switch", aber es ist so viel mehr, vor allem macht es das Arbeiten mit enums (davon hat man ja oft welche) sehr viel übersichtlicher. Insgesamt finde ich Rust Code mittlerweile viel angenehmer und einfacher zu lesen als C-Code, auch weil es dank rustfmt immer im gleichen Stil ist. Der Einstieg in Rust auf STM32 ist einfach und es gibt mittlerweile sehr viele Beispiele, z.b. das Rust Embedded Book https://docs.rust-embedded.org/book/
Gerhard O. schrieb: > Gut Ding braucht Weil. Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut Ding braucht Weil!". Das ist in etwa das, etwas anders, aber auf den Punkt formuliert, was man Wissenschaft nennt, vor allem Naturwissenschaft. Frage stets "Weil? Warum?"! Und lasse niemals locker, auch wenn dein Gegenüber genervt ist. Warum? Weil es nicht um dein Gegenüber geht, sondern um das Thema. Nicht um die Wahrheit an sich. Warum nicht? Weil es keine Wahrheit an sich gibt, sondern nur mehr oder weniger gute und überprüfbare Versuche, sich ihr anzunähern. Dass es eine einzige Wahrheit gibt, behaupten nur der Papst und Spaziergänger.
STMRust schrieb: > Seit ca. 2 Jahren nutze Vielen Dank für den Beitrag. Endlich einmal jemand, der Rust auch wirklich ausprobiert hat. > nutze ich ausschließlich Rust für alle meine STM32 Sehr interessant. Da habe ich jetzt auf jeden Fall etwas gelernt. Das sollte ich auch einmal ausprobieren.
MaWin schrieb: > Jörg W. schrieb: >> Gegen was willst du den denn zertifizieren, wenn es keinen Standard >> gibt? > > Das bleibt dir überlassen. Vielleicht gegen deinen Wocheneinkaufszettel? Dummes Gelaber - das selbstverständlich in den Bereichen, wo zertifizierte Tools gefordert werden, nicht akzeptiert wird. > An der Compilerqualität ändert es jedenfalls nichts. Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt, gegen den eventuelle Abweichungen festzustellen bzw. zu dem Konformität zu belegen wäre. Damit ist auch die Aussage von "sehr guter Qualität" nur eine leere Worthülse.
Carsten P. schrieb: > Gerhard O. schrieb: >> Gut Ding braucht Weil. > > Sei mir bitte nicht böse, Gerhard O., wenn ich dich nicht nur wörtlich, > sondern Buchstabe für Buchstabe zitiere, denn "gut Ding braucht Weil!". > Das ist ein sehr kluger Satz. Vielleicht hast du das "e" vergessen für > deine Aussage, aber ich bleibe bei der, die du abgeschickt hast: "Gut > Ding braucht Weil!". > Obwohl ich Dir im Weiteren vollkommen zustimme, habe ich mein Zitat nur im herkömmlichen Sinn gemeint, daß man eben Rust die Gelegenheit geben sollte erwachsen und reifer zu werden und daß das Zeit braucht. In zehn Jahren wird sich noch viel ergeben. So kann ich leider nicht das Kompliment annehmen:-) Ich möchte vorerst mich mit der Entwicklungsumgebung befassen um die Werkzeuge unter Windows in den Griff zu bekommen. Eigenbau STM32 HW habe ich auch. Es ist mir wichtig die Tool Chain zum Laufen zu bringen. Die Sprache selber ist ja ziemlich intuitiv wenn man mal von den Pragmas absieht die man lernen muß. Da sehe ich für mich eher die größeren Schwierigkeiten. Dafür sind aber die Online Dokus da. Die Tricks wird man man sowieso in Kollaboration mit Mitstreitern lernen müssen und vielleicht miteinander teilen können.
:
Bearbeitet durch User
An STMrust, Vielen Dank für Deine Hinweise. Ich habe mir schon die embedded Doku angesehen.
Nop schrieb: > Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt Qualität ist die Abwesenheit von Kundenreklamationen.
MaWin schrieb: > Nop schrieb: >> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt > > Qualität ist die Abwesenheit von Kundenreklamationen. Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik.
Mombert H. schrieb: >> Qualität ist die Abwesenheit von Kundenreklamationen. > > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das schon. Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl verdammt gut abschneiden. ;-)
Jörg W. schrieb: > Mombert H. schrieb: >>> Qualität ist die Abwesenheit von Kundenreklamationen. >> Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. > Musst du sie noch auf die Gesamtkundenzahl beziehen, dann passt das > schon. > Könnte natürlich sein, dass C-Compiler dann dank ihrer großen Kundenzahl > verdammt gut abschneiden. ;-) Vorher müsste man klären was genau mit Kunde gemeint ist. Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. Nur wenn ich ifort nutze sehe ich mich aktuell als Kunde und das macht weniger als 5% meiner Zeit aus.
Mombert H. schrieb: > Dann ist die Abwesenheit von Kunden auch Qualität. Super Logik. Genau. In Abwesenheit von Kunden spielt Qualität keine Rolle. Außer in QM-Hirnen.
Mombert H. schrieb: > Vorher müsste man klären was genau mit Kunde gemeint ist. Nenne sie von mir aus „aktive Nutzer“. Streng genommen müsstest du natürlich noch die Nutzungshäufigkeit mit einbeziehen, denn je häufiger du sie nutzt, um so größer die Wahrscheinlichkeit, mal auf ein Problem damit zu stoßen.
Mombert H. schrieb: > Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. Krass. Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt.
MaWin schrieb: > Mombert H. schrieb: >> Wenn ich clang oder gcc nutze sehe ich mich nicht als Kunde. > > Krass. > Das sagt mehr über dich aus, als über clang, gcc und den Rest der Welt. Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde.
Mombert H. schrieb: > Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde. Legaler Nutzer laut Lizenz.
MaWin schrieb: > Mombert H. schrieb: >> Dann erleuchte mal die Welt und gib uns deine Definiton von Kunde. > > Legaler Nutzer laut Lizenz. Wenn ich in den Supermarkt gehe, bin ich also kein (evtl. potentieller) Kunde? Oder wie definierst du Lizenz?
Software beschaffen -> Lizenz Vertrag Im Laden was Einkaufen -> Kauf Vertrag Sind beides Verträge, man denkt über letzteren nur nicht so, weil das meistens implizit ist. (Ich geb einfach den angeschriebenen Betrag, und allen ist klar, was die Konditionen sind) Eigentlich nervig, dass das bei Software noch nicht simpler gestaltet wurde. Kundenschutz ist auch nicht existent. Wie Geräte heute zu Servicen werden, zum Kotzen. Rechtssysteme versagen beim Digitalen einfach komplett, lassen Unternehmen verlangen, tun und lassen, was sie wollen, und regulieren am falschen Ort, um positiven Technologieeinsatz zu erschweren / verhindern.
DPA schrieb: > Software beschaffen -> Lizenz Vertrag > Im Laden was Einkaufen -> Kauf Vertrag Das bedeutet man kann Software nicht kaufen? Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? Bin ich dann Kunde?
Mombert H. schrieb: > DPA schrieb: >> Software beschaffen -> Lizenz Vertrag >> Im Laden was Einkaufen -> Kauf Vertrag > Das bedeutet man kann Software nicht kaufen? Das ganze ist etwas kompliziert, ich überblicke das alles auch nicht. Die kurze Version ist, Ja, man kann Software Kaufen, aber was heisst das eigentlich? Man muss sich da überlegen, was man da unter kaufen versteht, bzw. was man eigentlich kaufen will. Man kann z.B. Lizenzen anbieten/kaufen. Damit kann man z.B. Nutzungsrechte an einer Software erwerben, aber auch andere Dinge festlegen. Kann man zwar beim Kauf anderer Sachen auch machen, insbesondere bei anderen nicht physischen Sachen (Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte), etc.), ist das recht üblich. Ich bin mir nicht sicher, bis zu welchem Grad man das mit physischen Dingen machen kann, und wie genau das mit "geistigem Eigentum", Eigentumsrechten, Besitzrechten, usw. im Detail zusammenhängt & funktioniert, aber man kann überall einiges festlegen. Aber eventuell will man eine Software kaufen, im sinne von den Code & sämtliche Rechte daran kaufen. Das geht bis zu einem gewissen Grad auch. Wobei, in gewissen Ländern kann man gewisse Rechte nicht verkaufen oder aufgeben, und vieles ist je nach Land sehr anders geregelt. Darum kann man z.B. nicht einfach sagen "Ich geb all meine rechte auf, und gebe sie der Allgemeinheit", sondern braucht dafür Lizenzen wie CC0, die versuchen das nächst beste mögliche zu bieten (https://creativecommons.org/share-your-work/public-domain/cc0/). Ehrlich gesagt, ich wüsste gar nicht, wie ich eine Software jemand anderem verkaufen könnte, im sinne von alle möglichen Rechte daran. > Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die dir das erlaubt. Oft ist das aber auch ein bisschen wie wenn man sonst was Einkauft oder Verschenkt. Wenn ich meine eigene Software gratis anbiete, oder als Demo Version, reicht es vermutlich zu sagen, das ist Freeware / eine Demo Version, hier ist der Download. Aber normalerweise gibt es danach trotzdem noch irgend eine EULA, die genauer festhält, das die Konditionen für den Endnutzer sind. Es gibt da noch irgend einen Unterschied zwischen Endnutzer Lizenzen und anderen arten von Lizenzen. Die GPL z.B. ist keine Endnutzerlizenz. Die legt einfach fest, was man mit dem Code machen darf, und man muss ihr nicht explizit zustimmen, will man die Rechte, die sie einem gibt, muss man sich aber an sie halten. Wenn ich meinen Code dann gratis öffentlich auf GitHub stelle, mit der GPL Lizenz drin, gebe ich die Lizenz quasi gratis an andere. Aber ich könnte den Code auch ohne Lizenz veröffentlichen, dann dürfte ihn eigentlich keiner nutzen. Als Urheber kann ich Software beliebig lizenzieren, ich kann den Code also auch unter der / irgendeiner Lizenz lizenziert verkaufen. (Und die Lizenz legt dann auch Dinge fest, wie z.B. darf ich das weiterverkaufen). Keine Ahnung, wann man Lizenzen explizit zustimmen muss und wann nicht, und wie das alles im Detail zusammen hängt. Vermutlich blickt da sowieso keiner durch. Irgendwo hätte ich von der BM her noch ein Buch (https://www.booklooker.de/B%C3%BCcher/Thomas-Sutter-Somm+ZGB-OR-Schweizerisches-Zivilgesetzbuch-und-Obligationenrecht-mit-ZPO-SchKG-und/isbn/9783906186245), da steht auch irgendwo drin, wer (in der Schweiz) beim Verkauf von Dingen welche Rechte und Pflichten hat, was Eigentum und Besitz genau heist, wie man das Anwendet / was man in einem Vertrag anders regeln kann, usw. Theoretisch könnte ich dort im ZGB Teil, unter Sachenrecht, alles relevante zum kaufen und verkaufen von Dingen nachlesen (der teil ist gar nicht mal so lang), das dürfte zu einem teil auch auf Software zeug anwendbar sein. wobei dort das URG[1] (Urheberrecht) noch relevant sein dürfte, für all das zeug rund um geistiges Eigentum (ich glaube das fehlt in meinem Buch). Ja, da könnte ich nachlesen, wie das genau funktioniert. Könnte... Aber gilt ja eh nur in der Schweiz, bringt mir vermutlich eh nicht viel. Wie auch immer, ob du jetzt eine Lizenz kaufst, oder die geschenkt bekommst, normalerweise bekommst du schon irgendwoher eine. > Bin ich dann Kunde? Gute frage. Ich bin mir nicht sicher, ob das irgendwo überhaupt formal definiert ist. Da kann ich nur meine eigene Sichtweise bringen. Was bedeutet es wirklich, Kunde zu sein? Wenn ich dir was schenke, hast du vermutlich keine Garantie Ansprüche usw. In gewissen sinne bist du vermutlich schon ein Kunde, aber wer würde wen wann wirklich als Kunde betrachten? Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den ich nicht Verkaufe), sehe ich auch nicht als Kunde. Wenn mir Fehler gemeldet werden, und ich hab genug infos, fix ich die normalerweise schon. Aber wenn jemand echten Support für seine Probleme usw. will, nö, keine Lust. Das soll er sich woanders kaufen. Also für mich ist man schon erst Kunde, sobald Geld fliesst. [1] https://www.fedlex.admin.ch/eli/cc/1993/1798_1798_1798/de
DPA schrieb: > Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte Vielen Dank für diesen riesigen Offtopic-Ausflug. Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja?
DPA schrieb: > Das ganze ist etwas kompliziert Ich stimme dir im Großen und ganzen zu und erwarte auch keine Antwort auf meine Fragen (ich hatte nur auf eine ernst gemeinte Antwort von MaWin auf die erste Frage gehofft ...). Ich möchte es an zwei Stellen aber noch etwas komplizierter machen ;-). DPA schrieb: >> Was ist mit Software, die ich nicht gekauft oder beschafft habe aber trotzdem nutze? > Um diese nutzen zu können, brauchst du trotzdem eine Vertrag/Lizenz, die > dir das erlaubt. Um sie legal nutzen zu können. Wäre ich ein Kunde, wenn ich sie illegal nutzen würde? Was ist wenn mein Arbeitgeber der Käufer ist? DPA schrieb: > Ehrlich gesagt betrachte ich mich nicht als Kunde, wenn ich > Zeugs geschenkt kriege. Und andere, die meinen Code gratis nutzen, (den > ich nicht Verkaufe), sehe ich auch nicht als Kunde. Das umgeht auch ein weiteres Problem. Wenn man Software für sich selbst entwickelt und nutzt, ist man dann sein eigener Kunde? MaWin schrieb: > DPA schrieb: >> Bilder, Filme, Musik (oft separat Aufzeichnung, Vorführung, Noten, Texte > > Vielen Dank für diesen riesigen Offtopic-Ausflug. > Dann können wir ja hoffentlich zum Threadthema zurückkommen. Ja? Ich habe gedacht, die Qualität des rust-Compilers ist essenziell, um die Frage "Rust - ist das hier um zu bleiben?" zu beantworten. Und dafür müssen wir wohl erstmal klären was Kunden sind, denn: MaWin schrieb: > Nop schrieb: >> Die Qualität ist überhaupt nicht meßbar, wenn es keinen Standard gibt > > Qualität ist die Abwesenheit von Kundenreklamationen.
Mombert H. schrieb: > Und dafür müssen wir wohl erstmal klären Es ist alles beantwortet. Deshalb werde ich dazu auch nichts mehr sagen. Dass dir die Antworten nicht in den Kram passen, ist mir klar. Aber damit musst du dann wohl leben.
In diesem Forum tummeln sich so dermaßen viele Leute die jeden kleinsten Satz dazu nutzen um eine riesen Off Topic Diskussion von der Leine zu lassen und dann ewig drauf rum zu reiten Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform Es ist idiotisch gegen eine 5 Jahre alte Sprache zu wettern die keinem ein Haar krümmt und mehr oder minder bekannte Strategien besser integriert, so lange die nutzung nicht erzwungen wird ist jede Argumentation sinnfrei, wenn sich Rust trotz der ganzen schwächen etabliert ist die komplette Community ein der ihr euch befindet eben nicht klug, wenn Rust stirb ist nichts verloren Diskutiert doch lieber mit MaWin über die Vor/Nachteile dieser oder jener Konstruktion von Rust als all die alten Kammellen die jeder kennt und versteht und nur ihr denkt das jemand die nicht genauso gut vestanden habt wie ihr durchzubeten/kauen alte Kamellen: -statische Codeanalyse reicht völlig aus -Sanitizer machen alles perfekt -schreib einfach guten Code dann ist auch ok -ohne ISO standard kann ich nicht leben -ohne zertifizierung kann ich nicht leben -wenn es nicht von allen Herstellern unterstuetzt wird ist es nichts wert -wenn es nicht jedes problem ob syntaktisch, ausdruckstaerke oder logisch löst ist es nix wert -Es kompiliert langsam, also ist es nichts wert Solche Kommentare können nicht von versierten und erfahrenen Entwickler mit grossen Team und Projekterfahrungen kommen denn das alles sind schon 100% genutzte und bekannte probleme und wissen, nur der kleingeist denkt man müsse damit noch misionieren gehen, das ist alles ausgetretenes standardwissen, auch wenn manche das hier nicht verstehen weil ihre Welten so klein und überschaubar sind Also reisst euch mal zusammen ihr Nörgelfritzen und bleibt bei der Sache
Ich kann mich gar nicht erinnern, dass hier jemand gegen Rust "gewettert" hätte. Was kritisiert worden ist ist, dass man mit der neuen Sprache auch gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark verbandelt hat.
Jörg W. schrieb: > Was kritisiert worden ist ist, dass man mit der neuen Sprache auch > gleich mal noch das 43. neue Buildsystem etabliert und ziemlich stark > verbandelt hat. Jörg, auch du warst gemeint mit: cppbert3 schrieb: > Meistens wenn das Thema trivial oder irgendeine scheinbare nähe zu ihrem > Fachgebiet aufweisst, oder man sich gar nicht mit dem Kern Topic > auskennt und einfach nur quasseln will, Heise-Forumskultur in reinform Die Sache mit dem angeblich stark verbandelten Buildsystem ist bereits mehrfach beantwortet. Dir passt die Wahrheit nur nicht. Das akzeptiere ich. Nun akzeptiere doch auch du die Realität. Auch das zehnte Infragestellen wird zu den gleichen Antworten führen.
MaWin schrieb: > Dir passt die Wahrheit nur nicht. Mir ist sie (zumindest derzeit) schlicht egal. Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel zu widmen.
Jörg W. schrieb: > Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein > bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt > gleich nach "Hello World!"), Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne Cargo. Komisch, gell? Wo man doch ohne Cargo praktisch nichts machen kann, weil es ja angeblich so stark verbandelt ist. Mal ganz davon abgesehen, dass Cargo halt sehr gut ist und es vielleicht deshalb so gerne genutzt wird. Mit einer "starken Verbandelung" hat das nichts zu tun. Aber was schreibe ich hier. Das ist alles ja schon mehrfach erklärt worden.
MaWin schrieb: > Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne > Cargo. > Komisch, gell? "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder? Oliver
Jörg W. schrieb: > MaWin schrieb: > >> Dir passt die Wahrheit nur nicht. > > Mir ist sie (zumindest derzeit) schlicht egal. > Wenn ich aber eine Sprachbeschreibung sehe, die mir zugleich ein > bestimmtes Buildsystem schmackhaft machen möchte ("Hello Cargo!" kommt > gleich nach "Hello World!"), dann kannst du mir 10mal erzählen, die > seien nicht verbandelt. Irgendwie sind sie es, sonst hätten sich die > Autoren des Rust-Buchs nicht die Mühe gemacht, Cargo ein eigenes Kapitel > zu widmen. Alte Kamelle: Buildsystemzwang, alles kommt aus dem Internet, Entwickler arbeiten nur noch mit third parties, validierungsproblematik Wenn du so wie ich bei jedem Kunden ein anderes Buildsystem nutzen müsstes würde dich das vielleicht gar nicht mehr so stören, Rust schafft mit Cargo wenigstens eine gemeinsame Basis auch wenn es, was garantiert passieren wird nacher 2-3 Cargo clone geben wird, weil vielleicht doch zu viel fehlt wird ein grossteil diesen Pseudostandard verwenden und das ist, egal wie du es drehst und wendest erstmal keine absolut problematische Situation - und wenn es auch nur die Rust Entwickler zwingt ihre Sprache auch in einem buildsystem kontext zu betrachten z.B. bei C++ warten wir alle auf Module, nur die meisten Buildsystem haben riesige Probleme auf Modulveraenderungen zu reagieren, weil es da keinen Standard gibt wie die intermediate Dateien heissen können usw. - weil sich die C++ Chairs immer schon einen dreck um die Infrastruktur um die sprache gekümmert haben, das ist z.B. auch der grund warum der Prepozessor so lange nicht teil des Standards war, die hatten keinen Bock auf die Verantwortung und haben das so weit wie möglich den Benutzern/Toolchainentwicklern aufgebürdet Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit stark integrierten Buildsystemen auf den Markt geworfen wurden
Oliver S. schrieb: > MaWin schrieb: > >> Ja, genau. Das erste Beispiel "Hello World" im Buch ist komplett ohne >> Cargo. >> Komisch, gell? > > "Hello World"- Beispiele für C kompilieren i.d.R. mit "gcc main.c -o > main" oder so. Komplett ohne jedes Build-System. Auch komisch, oder? > Oliver Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier beschreitet oder als Argument für irgendwas verwendet Was soll so ein Post bewirken?
cppbert3 schrieb: > Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier > beschreitet oder als Argument für irgendwas verwendet Doch, genau das war das Argument: Rust ist gar nicht mit Cargo verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt. Oliver
Oliver S. schrieb: > cppbert3 schrieb: > >> Das ist doch alles jedem bekannt, und das ist auch nichts was MaWin hier >> beschreitet oder als Argument für irgendwas verwendet > > Doch, genau das war das Argument: Rust ist gar nicht mit Cargo > verbandelt, weil das Hello-World-Beispiel im Buch ohne auskommt. > Oliver Er hat doch nur bestätig das es gleichwertig ist, du kannst alles ohne und alles mit dem buildsystem machen, und das stand hier schon vor monaten und wird immer und immer wieder rausgekramt, wie langweilig
cppbert3 schrieb: > Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit > stark integrierten Buildsystemen auf den Markt geworfen wurden Die haben ein integriertes Laufzeitsystem, insofern kannst du für die eher Python als Vergleich heranziehen als Rust, C oder FORTRAN.
Jörg W. schrieb: > cppbert3 schrieb: >> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit >> stark integrierten Buildsystemen auf den Markt geworfen wurden > > Die haben ein integriertes Laufzeitsystem, insofern kannst du für die > eher Python als Vergleich heranziehen als Rust, C oder FORTRAN. über Laufzeitsystem haben wir hier doch bisher noch gar nicht gesprochen? ich bezog mich eher drauf das es kein Link System gibt sondern der Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt - so wie mit Turbo Pascal in grauer Vorzeit
cppbert3 schrieb: > ich bezog mich eher drauf das es kein Link System gibt sondern der > Quelltext mehr oder weniger direkt seine Abhängigkeiten vorschreibt Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher der Vergleich mit Python. Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, dass man Komponenten von möglichst vielen verschiedenen Welten miteinander integrieren kann. (Womit ich nicht behaupten will, dass das bei Rust nicht gehen würde.)
Jörg W. schrieb: > Das ist aber durch das integrierte Laufzeitsystem ohnehin gesetzt. Daher > der Vergleich mit Python. ich verstehe den Bezug immer noch nicht - ich möchte nur zum Ausdruck bringen das Build-Unit Abhängigkeiten in anderen Sprachen wie C#, Java und z.B. auch Turbo Pascal schon teil des Sprachstandards sind also so eine Art Sprach-Integriertes Buildsystem und sich da auch keiner beschwert hat bei C oder C++ (erst mit Modulen) gibt es so was gar nicht - ohne Preprozessor und Linker sind die einzelnen Build-Units völlig hilflos in der Luft umherfliegend - alles überentkoppelt weil C/C++ lange Zeit selbst das Konzept-von "Dateien" als zu grosse Abhängigkeit empfunden hat
Jörg W. schrieb: > Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, > dass man Komponenten von möglichst vielen verschiedenen Welten > miteinander integrieren kann. das war nicht die Grundintension bei C/C++ - da wollte man nur mit Gewalt jeden Kontakt zwischen den "Dateien" vermeiden, weil Dateien damals noch kein durchgesetztes Konzept waren und es eher darum ging den Prozess in möglichst viele Teilschritte zu zerlegen weil der geringe Speicher der damaligen System einfach zu schnelle an die grenze gestoßen ist - viele der heutigen Entwickler vergessen völlig wo das alles mal angefangen hat
In einer perfekten Welt, die ich mir in meinem wirren Kopf so zusammenspinne, hätte ich auch gerne das eine perfekte Buildsystem, das mit allen Sprachen funktioniert und das alle Features genau so hat, wie jeder das will. Leider ist das nicht die Realität. Die Rustentwickler haben mit Cargo ein ziemlich gutes Buildsystem geschaffen, das viele Sachen sehr elegant löst. Standardisiertes Buildmanifest mit gutem Options- und Dependency-Management. Sehr schöne Integration von Unit-Tests, System-Tests und Beispielprogrammen. Sehr gute UX. Es funktioniert ganz einfach out of the box. Das sind so die Dinge, die mir spontan einfallen. Es gibt sicher noch viel mehr. Und trotzdem ist es eben nicht fest verbandelt. Es steht dem Entwickler frei, ob er dieses gute Angebot annimmt. Und natürlich nehmen die meisten Entwickler dieses Angebot an, weil es ganz einfach sehr gut funktioniert.
cppbert3 schrieb: > Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit > stark integrierten Buildsystemen auf den Markt geworfen wurden Die nutze ich privat einfach nicht. Früher in der Schule und bei der Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen durfte. Wobei, in Java kann man Dateien haben, die exklusiv für ein Interface sind. Und ich kann Code Kompilieren & Ausführen, der Interfaces nutzt, ohne dabei die Implementation kennen zu müssen (Ich kann sogar eine zur Runtime nachladen usw., und auch noch ziemlich simpel.) Und auch wenn die Klassen, die man importiert, zum Kompilieren vorhanden sein müssen, das ist glaube ich bei Java immerhin nicht rekursiv. Eigentlich hat Java das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt mir ehrlich gesagt auch recht gut, ziemlich inspirierend aus technischer Sicht wenn man sich harte Templates gewohnt ist.
Daniel A. schrieb: > Eigentlich hat Java > das noch vergleichsweise gut gelöst. Und das Generics Konzept gefällt > mir ehrlich gesagt auch recht gut, Das ist sehr erfreulich. Aber da es hier im Thread um Rust geht: Wie gefallen dir Rust Generics denn so?
Daniel A. schrieb: > cppbert3 schrieb: >> Und bei C#, Java und vielen anderen hat kein Hahn gekräht als die mit >> stark integrierten Buildsystemen auf den Markt geworfen wurden > > Die nutze ich privat einfach nicht. Früher in der Schule und bei der > Arbeit gab es noch etwas Java, bis ich das später endlich alles ersetzen > durfte. wie gesagt - bei Java/C# und Konsorten ist das alles Teil des Sprachstandards - bei C/C++ nicht - und Rust nutzt einen Teil dieser Konzepte
cppbert3 schrieb: >> Der Anspruch eines Systems, das mit einem Linker arbeitet, ist ja eher, >> dass man Komponenten von möglichst vielen verschiedenen Welten >> miteinander integrieren kann. > > das war nicht die Grundintension bei C/C++ Für C schon, denn das musste unbedingt mit Assemblercode kombiniert werden können, und FORTRAN war zu der Zeit vermutlich das, was heute C ist. Für Rust wurde ja zumindest gesagt, dass es mit einer C-Umwelt klar kommt. Muss es eigentlich auch, denn bis mal alles Wichtige in Rust verfügbar ist, werden schon noch ein paar Jahrzehnte vergehen.
MaWin schrieb: > Jörg W. schrieb: >> denn bis mal alles Wichtige in Rust verfügbar ist > > Was ist denn "alles Wichtige"? Alles, was täglich gebraucht wird. Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen (also nicht nur theoretisch, sondern ganz praktisch), dann dürfte der Punkt erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen geschriebener Bibliotheken nicht mehr so wichtig ist. Wobe, FORTRAN hängt uns ja selbst heute noch hinterher, numpy oder Matlab lassen da grüßen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Wenn du in der Lage bist, einen normalen Desktop-Computer mitsamt seiner > "Zutaten" (Browser, Editor, Office, Bildbearbeitung, PDF-Viewer etc. > pp.) und dem zugrunde liegenden Betriebssystem mit Rust zu bauen Nutzer von Gentoo & co. tun mir jetzt schon leid. "emerge -uDN @world" - und jetzt warten wir mal einen Monat...
Jörg W. schrieb: > dann dürfte der Punkt > erreicht sein, wo die Einbindbarkeit externer, in anderen Sprachen > geschriebener Bibliotheken nicht mehr so wichtig ist. Warum sollte man den Punkt anstreben wollen? Was hat das überhaupt mit Rust zu tun? Rust ist gut interoperabel mit anderen Sprachen. By Design. In Gegensatz zu C. C ist nur mit C kompatibel. Deshalb muss sich der Rest der Welt darum kümmern mit C kompatibel zu sein. Und das tut Rust sehr gut. Heute.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.