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.
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:-)
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! ^^
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".)
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.
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.
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.
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.
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?
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.
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.
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:
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.
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.
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 ^^
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 :)
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.
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.
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.
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
> 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.
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.
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.
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.)
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.
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.
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.
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.
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.
