Forum: PC-Programmierung Rust - ist das hier um zu bleiben?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Daniel A. schrieb:
>> Nur mal so zum drüber nach denken...
>
> Ich verstehe kein Wort von dem, was du schreibst.
>
> Könntest du das bitte verständlich neu formulieren?

Es ist Pro Rust, einfach mehrfach lesen dann wirds klar, kompliziert 
aber stechend formuliert

von cppbert3 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
https://github.com/microsoft/windows-rs

Microsoft hat eine Metabeschreibung der WinApi veröffentlicht, nebst 
Binding Generator für Rust und C#, C++ soll folgen

Beitrag #6565967 wurde vom Autor gelöscht.
von Jedzia D. (Firma: Rast und Ruh) (jedzia)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Du hast offensichtlich keine Ahnung von modernem C++, wenn du nicht
> verstehst, warum new ein Indiz für unsicheren Code ist.

Ja aber nur wenn das

- delete fehlt
- oder Exception zwischendurch
- womöglich x hundert andere Pfade existieren wo etwas schief gehen kann
- das mein (seien wir ehrlich:) hinzugepfriemeltes Tool erst mal 
entdecken muss
- etc.

Code-Reflection ist eben nicht einfach, besonders wenn man die Regeln 
der grauen Eminenzen(Komitee)im Ökosystem einer organisch gewachsenen 
Programmiersprache beachten muss. (Völlig wertfrei gemeint ... ich bin 
in Boost verliebt)

Wie wäre es bloß, wenn man diesen steinigen Weg gar nicht gehen müsste 
und Speicherfehler vermeiden könnte, etwa durch ein Neu-Design? Was 
würde ich geben wenn es so etwas geben würde ... :)

1
unsafe
 ist natürlich immer noch böse.

Aber vergleichen wir einmal
https://github.com/google/sanitizers/issues?q=is%3Aissue+delete
mit https://debbugs.gnu.org/cgi/pkgreport.cgi?package=grep

Bei den grep issues nicht erschrecken lassen. Kein einziger Bug davon 
verhindert das grep -r unsafe * etwas anzuzeigen vergisst. Nur gabs 
gerade bei der Rekursion einen Memory-Leak. Sachen gibts;)
Das war jetzt aber eher mit einem zwinkernden Auge gemeint. Äpfel und 
Birnen.

xyz-sanitize ist eben KEIN Ersatz für Sprachdesign sondern die 
Putzkolonne, wenn die Sauerei schon dampft.


P.S.: Bild => völlig anderer Rost! -> 
https://dilbert.com/strip/2000-04-30

von cppbert (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Rust forciert:

1. einen einheitlichen Codingstyle (den man lokal deaktivieren kann - 
was aber nicht gerne gesehen ist)

==> der Style ist dann vielleicht nicht so wie man den seit 20 Jahren 
nutzt aber wenigstens ist er über alle Kollegen, Abteilungen UND Firmen 
für die man zeitweise arbeitet der selbe - und wer will den Ernsthaft 
behaupten das es zwischen den produktiven hunderten Codingstyles die das 
draussen so rumkreuchen und fleuchen der Unterschied mehr ist als 
Bauchgefühl

spätestes wenn du mit C,C++,C# und Python arbeitest fährt man im 
Normalfall schon 2-3 verschiedene Arten - also was soll es...

MERKE: man "kann" nicht nur einen gemeinsamen Codingstyle haben - man 
hat IMMER den selben(nicht nur den gleichen) Codingstyle

2. Ein Own/Share Konzept in der Sprache - was definitiv NICHT bedeutet 
das da Smart-Pointer einfach nur fest eingebaut sind sondern das die 
Sprache syntaktisch nicht erlaubt Own oder Share-Probleme zu 
programmieren, das komplette Programm ist wenn kompilierbar garantiert 
frei von (fast) alle Own/Share bezogenen Fehler - so lange der Kompiler 
keine Bugs hat :)

==> natürlich hat C++ auch Smart-Pointer und RAII mit der man viele 
Probleme unter Kontrolle bringt - aber eben nur wenn auch alle 
Entwickler mit machen,

Die grossen der Branche, also die mit sehr vielen Entwicklern und sehr 
viel C++-Code (10-100MioLOC) und Einfluss auf das Weltgeschehen, sage 
einstimmig, das ist alle ganz gut - wir haben aber trotzdem odentlich 
Probleme - und wer das nicht glaube hat einfach nicht wirklich Team- und 
im speziellen firmenübegreifende Entwicklungserfahrung oder hat keine 
Ahnung was ein Amazon AWS mit MioLOC C++ und 2 stellig Mio Anzahl Nutzer 
tagtäglich für Problemen mit Resourcen-Bedarf, Sicherheit gegen Angriff 
und.und.und ausgesetzt ist, ein google, Facebook etc. haben 
vergleichbare Größenordnung

MERKE: Mit Fehler die es nicht geben KANN muss man sich GAR NICHT 
beschäftigen

3. Ein Package und Build-System (aka Cargo)

Jeder Anfänger kann die Docs lesen und jeder andere Entwickler wird im 
Normalfall die selbe Sprache sprechen, fast jedes Projekt das sich nicht 
toal gegen den Standard wehrt baut out-of-the-box, das ist einfach was 
anderes als jeder-kann-es-machen-wie-er-will

unter C++ haben wir mittlerweile von Conan, vcpkg usw. schon etliche 
Systeme die immer mehr Verbreitung finden und es liegen x Proposal vor 
um C++ um ein solches System zu erweitern

ich hab beruflich mit fast allem Kontakt

MERKE: Vereinheitlichung ist erstmal einfacher für die meisten - an den 
Aufgaben wachsen kann jedes System

4. Ein auf Rust basiertes Build-System

natürlich haben wir da ein Wildwuchs an Systemen von CMake, meson, 
QMake, qbs, Scons - ich hab mit allen zu tun - und jedes ist irgendwie 
anders
, natürlich auch für embedded und, und, und

in Rust ist dein Build-System in Rust-Code und mehr braucht man 
eigentlich doch auch nicht

MERKE: die Sprache die du primär nutzt bleibt auch beim Build-System 
deine Sprache - kein Umdenken nötig

Nachteile:

1. Rust ist mit seinen 5-10 Jahren sehr jung für eine native Sprache mit 
so vielen echten Zwängen - go, C# oder andere nicht embedded-tauglichen 
oder VM-Sprachen sind einfach was anderes und können nur in der normalen 
Applikations-Entwicklung zum vergleich herangezogen werden - embedded 
und System-Entwicklung hat aber einfach noch viele viele kleine 
Anforderungen die eben auch sicher und performant realisierbar sein 
müssen

2. Rust ist oft arschlangsam beim kompilieren, liegt u.a. an dem stark 
organisch gewachsenem Kompiler und weil die Entwickler auch definitiv 
lange keine Fokus darauf gelegt haben - die wollte erst mal eine 
stimmige Syntax/Semantik entwickel/erforschen - und haben auch viele auf 
dem Weg dort hin gebaut und wieder völlig verworfen u.a. weil es eben 
nicht einfach nur ein C-Derivat ist (wie die meisten der anderen 
Sprachen)

Das ist jedem klar aber definitiv kein Argument gegen die 
Infrastruktur-Tools oder die Syntax und das macht die Entwickler auch 
nicht zu einem Haufen Idioten die gar nix können

3. Rust versucht gezielt mit vielen Zwängen die Entwickler auf die 
Algorithmen-Entwicklung zu fokusieren - das ist für viele aus der 
Kriegs- oder Anti-Autoritären-Erziehungs Generation zu wenig libreral, 
obwohl die meisten in ihren eigenen Firmen auch eher totalitärer 
Kontrolle über Infrastruktur-Tools und Codingstyle unterliegen oder 
ausüben

4. alles statisch gelinkt weil noch keine klare ABI für DLLs usw.

5. und, und, und...

Es wäre schön wenn wir vielleicht eine Positiv/Negativ-Liste aufbauen 
könnten

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachteil 6:

Um Rust ranken sich zu viele Mythen:

"Rust ist perfekt für alles und erzeugt immer super-schnellen Code"

Die Syntax ist nicht ganz leicht und keine Programmiersprache der Welt 
vollbringt Wunder

Rust hat aber definitiv mit der Aliasing-Kontrolle potenzial stärker 
optimierbar sein zu können als C/C++ (wenn GCC und LLVM da keine Fehler 
hätten)

"Rust ist super-kompliziert"

Kommt definitiv darauf an welche Sprachen-Hintergrund man hat und welche 
Ziele man verfolgt, für jemanden der nur Basic kann ist alles schwer für 
jemanden der 10 Sprachen kann ist Rust vielleicht nicht so kompliziert

Die Frage ist nur ob man die Vorteile nutzen will

"Rust ist zu streng/einschränkend"

Jeder ist streng und einschränkend in seiner Firma oder Projekt - gibt 
es jemanden unter euch der akzeptiert das jeder im Team den Code einfach 
so strukturell oder visuell schreibt wie er jetzt gerade Bock drauf hat?

In C++ gibt es immer die Leute die auch mit den Infrastruktur-Tools wie 
Build-System, oder Sanitzer etc. arbeiten - oder diese auch einführen 
und pflegen, schulen - es ist meist nicht das ganze Team welche alles 
Tools gleich gut versteht - weil zu viel Spezialisierung nötig ist

"Es kann einfach nicht sein das Rust diese Sicherheits-Garantien 
erfüllt"

Es sind schon viele Sprachen daran gescheitert - meist weil die dabei 
entstandene Syntax kaum eine praktikable Entwicklung erlaubt, die 
meisten Sprachen sind entweder total unsicher wie z.B. C oder schaffen 
es mit größerem Ressourcen-Bedarf (alle VM Sprachen) die Problem besser 
unter Kontrolle zu halten, die dann aber wieder nicht für alle 
embedded/Echtzeit/niedrig-Latenz-Systeme geeignet sind

Sicherheits-Garantie bedeutet nicht das es sicher ist wenn man es 
richtig anwendet - das ist nur eine mögliche Sicherheit

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachteil 7:

Rust hat erst vor kurzem, z.B. durch Amazon (die sponsorn alle Server 
und haben viele der Kern-Entwickler unter Vertrag genommen) und 
Microsoft (Azure und auch ein Teams im Aufbau) starke finanzielle 
Zuwendung ausserhalb von Mozilla erfahren

das ist verglichen mit der .Net-Entstehung  (stark durch den ganzen 
Microsoft-Konzern getrieben) , Java durch Sun/Oracle oder einem go mit 
starkem google-Hintergrund noch nicht wirklich viel Direkt-Finanzierung

das führt eben dazu das z.B. die Standard-Lib viel weniger umfangreich 
und ausgetesteter ist als bei Sprache/Platformen die erst hinter den 
Konzern-Türen so weit gebracht wurde das sie möglichst viele 
"Kauf-ich"-Argumente bei der Erstvorführung mitgebracht haben

Nachteil 8:

Rust will C/C++ im Embedded Bereich beerben - in dem ältesten und 
konservativstem Teil unserer Software-Landschaft, mit der größten Anteil 
an Spezalisierung bis runter auf die x Varianten von Kompilern und SDKs 
die von den Anbietern angepasst werden.

Das ist definitiv eine riesen Herausforderung - an der bisher jede 
Sprache ausser C (C++) und ein paar wenigen anderer, gescheitert ist - 
aber auch vielleicht weil die 1. zu Ressourcen-Hungrig waren oder 
einfach wirklich nur minimalsten Mehrwert gebracht haben

von Carl D. (jcw2)


Bewertung
-1 lesenswert
nicht lesenswert
cppbert schrieb:
>
Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu 
verwenden?

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Wie sollen mich dann bitte meine unzähligen Fans erkennen?

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> cppbert schrieb:
>>
> Wäre es nicht eine Überlegung wert, künftig einen anderen (Gast-)Nick zu
> verwenden?

Ich denke Rust braucht noch mind 5 Jahre bis zur Reife, bis dahin habe 
ich noch genug Zeit sehr viel C++ Code zu pflegen und zu schreiben, aber 
dann wechsel ich natürlich gleich auf rustbert

von Cppbert3 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
https://opensource.googleblog.com/2021/02/google-joins-rust-foundation.html

........
Memory safety security defects frequently threaten device safety, 
especially for applications and operating systems. For example, on 
Android, we’ve found that more than half of the security vulnerabilities 
we addressed in 2019 resulted from memory safety bugs. And this is 
despite significant efforts from Google and other contributors to the 
Android Open Source Project to either invest in or invent a variety of 
technologies, including AddressSanitizer, improved memory allocators, 
and numerous fuzzers and other code checking tools. Rust has proven 
effective at providing an additional layer of protection beyond even 
these tools in many other settings, including browsers, games, and even 
key libraries. We are excited to expand both our usage of Rust at Google 
and our contributions to the Rust Foundation and Rust ecosystem.
....

Half of the security vulnerabilities... und das von den Asan Erfindern 
:)

Beitrag #6582066 wurde von einem Moderator gelöscht.
von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Cppbert3 schrieb:
> Half of the security vulnerabilities... und das von den Asan Erfindern
> :)
Und sie sagen zu rust:
Cppbert3 schrieb:
> an additional layer of protection
Das ist etwas anderes, als die Lösung des Problems.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
> Rust wandert ins System
> Eine wichtige Python-Bibliothek nutzt künftig teilweise Rust-Code. Bald wird
> es möglicherweise schwer, Linux-Systeme ohne Rust zu betreiben.

https://www.golem.de/news/linux-rust-wandert-ins-system-2102-154041.html

/edit
Dieses Forum braucht a gscheite Quote Funktion... -.-

: Bearbeitet durch User
von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Das ist etwas anderes, als die Lösung des Problems.

was erwartest du: die haben 1Mrd. Zeilen C/C++ Code - wäre ziemlich blöd 
den Code in so einem Werbungs-Post schlecht klingen zu lassen, oder?

und was ist das Problem bei "die Lösung des Problems"?

Rust verhindert zu 100% alle Formen von Speicher-Falschnutzungen und 
Data-Races zur Kompilezeit (bis auf Array-Indizierung) - für den ganzen 
Source-Code auf einmal - was fehlt da noch an kritischen Problemen? 
Logikfehler kann man immer machen

und jede Sprache die versucht bis auf die Array-Indizierung herunter 
eine Garantie für die Fehlerfreiheit einer Software zu liefern ist 
praktisch kaum relevant(oder nutzbar)

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt wurde Rust in eine eigene Foundation ausgelagert. Mal schauen was 
daraus wird und ob sich dadurch mehr Vetrauen aus der Industrie gewinnen 
lässt.

https://blog.mozilla.org/blog/2021/02/08/mozilla-welcomes-the-rust-foundation/

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder 
vergleichbares bei rust/cargo passiert:

https://www.heise.de/news/Sicherheitsforscher-bricht-ueber-Open-Source-Repositories-bei-PayPal-Co-ein-5051635.html

SCNR,
WK

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
> vergleichbares bei rust/cargo passiert:

Warum sollte es?

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Dergute W. schrieb:
>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
>> vergleichbares bei rust/cargo passiert:
>
> Warum sollte es?

Sollte die Frage nicht besser lauten: Warum sollte es nicht?

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> MaWin schrieb:
>
>> Dergute W. schrieb:
>>> Na, wollnwa mal hoffen, dass nicht eines Tages auch mal sowas oder
>>> vergleichbares bei rust/cargo passiert:
>>
>> Warum sollte es?
>
> Sollte die Frage nicht besser lauten: Warum sollte es nicht?

Alle Package System die von Remote Code oder Binaries ziehen können und 
werden solche Probleme haben, nmp, vcpg, cargo, pip und und und, 
natürlich muss man da diszipliniert sein, aber ich hätte absolut kein 
Problem sowas komplett entkoppelt, firmenintern zu nutzen, was ja auch 
möglich ist - oder ich mache mein deployment von 3rd parties weiterhin 
von Hand, Cargo steht mir da auch nicht im Weg

aber ja, man kann alles irgendwie korrumpieren und es wird leichter

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
cppbert3 schrieb:
> Alle Package System die von Remote Code oder Binaries ziehen können und
> werden solche Probleme haben,

Das Problem war hier, dass Paypal ihr internes Buildsystem falsch 
konfiguriert haben. Einfach mal den Artikel lesen.
Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.

Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben 
soll.

von Olaf (Gast)


Bewertung
3 lesenswert
nicht lesenswert
> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Es gibt schon einen Zusammenhang.

Wenn du frueher zu Ahnungslos gewesen bist um etwas ans laufen zu 
bringen dann hat es halt nicht funktioniert und du hast solange gelernt 
bist du es hin bekommen hast.

Heute funktioniert alles beim erstenmal moeglichst einfach, aber es ist 
Mist weil alles in die Welt rausgeblasen wird und du die unmoeglichsten 
Abhaengigkeiten auf der Kiste hast. Nur wenn du Ahnung hast und dir 
Muehe gibst kannst du es abstellen. Die Welt wird idiotensicher und wir 
bekommen immer mehr Idioten weil das reicht sich durchzuschummeln.

Vergleich das mit Handys. Nokiahandys unter Symbian waren angeblich 
schlecht weil es nach dem kauf kompliziert war die Kiste soweit zu 
bekommen das man damit ins Internet konnte, Email usw funktioniert hat. 
Bei Android geht es beim ersten einschalten, aber du musst dreimal 
soviel Muehe reinstecken um zu verhindern das deine privaten Daten 
ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in 
der Zeitung lesen.
Software geht denselben Weg....

Olaf

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
Olaf schrieb:
> Bei Android geht es beim ersten einschalten, aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.

Was steht denn da genau über Android-Handys?

Wenn ich in meiner (digitalen) Zeitung lese dass irgendwo Daten (z.B. 
Passwörter im Klartext) abgegriffen wurden dann so gut wie immer bei 
Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von 
Android-Smartphones.

: Bearbeitet durch User
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Firmen bzw. aus der Cloud. Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Das ist hier wohl eher OT, aber frag dich mal eine Sekunde wie bei 
Firmen wie Facebook, Google usw die Milliarden entstehen. Die muessen 
irgendwo was klauen das sie verkaufen koennen.

In der Software sehe ich das Problem das die Komplexizitaet immer 
groesser geworden ist. So gross das es immer schwerer faellt das alles 
zu durchschauen. Die Loesung sieht man darin die Systeme noch komplexer 
zu machen indem man diese Komplexizitaet nach aussen hin versteckt.

Olaf

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Le X. schrieb:
> Also aus Linux-Serversystemen, nicht von
> Android-Smartphones.

Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden 
die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das 
zu verhindern.

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Le X. schrieb:
>> Also aus Linux-Serversystemen, nicht von
>> Android-Smartphones.
>
> Aus Android-Smartphones muss man ja auch nichts abgreifen. Die senden
> die Daten ja von ganz allein dahin... und es ist nahezu unmöglich, das
> zu verhindern.

Mich hätte eigentlich nur interessiert was das für ominöse Folgen sind 
von denen Olaf spricht und wo man darüber lesen kann.
Olaf schrieb:
> aber du musst dreimal
> soviel Muehe reinstecken um zu verhindern das deine privaten Daten
> ueberrall in der Welt landen. Ueber die Folgen kannst du jeden Tag in
> der Zeitung lesen.
Aber die Antwort blieb er schuldig, seinem letzten Beitrag kann ich 
nicht wirklich Verständliches entnehmen.

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> cppbert3 schrieb:
>> Alle Package System die von Remote Code oder Binaries ziehen können und
>> werden solche Probleme haben,
>
> Das Problem war hier, dass Paypal ihr internes Buildsystem falsch
> konfiguriert haben. Einfach mal den Artikel lesen.
> Das hat überhaupt nichts mit einer Lücke im Paketsystem zu tun.
>
> Deshalb sehe ich auch nicht, was das mit Rust oder Cargo zu tun haben
> soll.

Wenn es nur Paypal wäre, ist diese Aussage vielleicht Ok. Da es 
mittlerweile allerdings deutlich mehr Unternehmen getroffen hat, sollte 
man nochmal überlegen, wo genau das Problem liegt.

Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic 
versioning?

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
> versioning?

Wo bitte wurde das behauptet?

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Operator S. schrieb:
> mh schrieb:
>> Achso MaWin, wie hilft in diesem Fall dein heiliger Gral semantic
>> versioning?
>
> Wo bitte wurde das behauptet?

Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im 
wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen 
auf semantic versioning zu beantworten oder sie als völligen Unsinn 
bezeichnet.

Z.B.
MaWin schrieb:
> mh schrieb:
>> Du musst regelmäßig die Abhängigkeiten prüfen, ob
>> da noch alles so funktioniert wie es soll,
>
> Quatsch.
> Dank semantic versioning ist das natürlich nicht notwendig.
> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
> und Fixes.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen. Da hat MaWin im
> wesentlichen versucht, alle kiritschen Kommentare zu cargo mit Verweisen
> auf semantic versioning zu beantworten oder sie als völligen Unsinn
> bezeichnet.

Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig 
anderen Zusammenhang war?

Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
Du wirst es nicht schaffen, weil es sie nicht gibt.

Könnten wir jetzt bitte wieder zum Thema zurückkommen? Rust?

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Ach, habe ich das? Kann es vielleicht sein, dass das in einem völlig
> anderen Zusammenhang war?
Ja und Nein.
> Zitiere meine Aussage bitte, wenn du anderer Meinung bist.
> Du wirst es nicht schaffen, weil es sie nicht gibt.
Ok ...

mh schrieb:
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen, ob
> da noch alles so funktioniert wie es soll, keine neuen unerwarteten
> Abhängigkeiten dazu gekommen sind, die Qualität noch deinen
> Anforderungen entspricht, kein Urheberrecht verletzt wird ...

MaWin schrieb:
> mh schrieb:
>> ...
> Quatsch.
> Dank semantic versioning ist das natürlich nicht notwendig.
> Du bekommst automatisch alle rückwärtskompatiblen Weiterentwicklungen
> und Fixes.

Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.

Wie soll die Malware da plötzlich hinein kommen?
Warum soll mir ein Entwickler plötzlich Malware unterschieben?
Und warum ist das ein Problem des Tools?
Und warum ist das jetzt neu und unterscheidet sich von jedem anderen 
Updatemechanismus?

Ich glaube du hast immer noch nicht verstanden, wie crates.io 
funktioniert.

Das ist einzig und alleine ein soziales Problem.
Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Soziale Probleme lassen sich prinzipiell nicht mit Technik lösen.

Doch schon, durch Isolation, die man aber mit Rust/CreateCreate 
realisieren kann - wenn man das als nötig befunden hat

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Da müsstest du die Beiträge von vor einem Monat lesen

Hab ich, den Thread verfolge ich seit Beginn.

Ironischerweise, löst genau Semantic Versioning das beschrieben Problem 
von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet 
ist...)

Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er 
sich das Package mit der höchsten Version das er finden kann. Ein 
"Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein 
MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem 
System.

Wenn man aber die Version spezifiziert a la Package Install MyFancyLib 
1.2.5 dann holt er genau diese eine Version.

An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir 
nicht bewusst geworden, dass Semantic Versioning tatsächlich genau 
dieses Problem löst.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Operator S. schrieb:
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.
>
> An dieser Stelle danke für deine kritische Sichtweise, sonst wäre es mir
> nicht bewusst geworden, dass Semantic Versioning tatsächlich genau
> dieses Problem löst.

Ähm, nein, das hilft hier gar nichts. Irgendwann will man die 
Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in 
alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und 
was glaubst du, was dann passiert? Genau, es tut was es soll, und 
aktualisiert die Versionen der Abhängigkeiten. Da gibt es jetzt echt 
keinen Unterschied zwischen npm, pip, cargo, etc. Da müsste man schon 
selbst aufpassen, und nochmal genauer hin sehen...

Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit 
technischen mitteln zu lösen. Google hat letztens eine Dystopische 
Lösung für das Problem vorgeschlagen: Jeder braucht eine rechtsgültige, 
eindeutige Identität im Internet. Baut man scheisse, kann man sich einen 
neuen Job/Hobby suchen... [1]

(Man bedenke auch, dass vielerorts die Einführung von eIDs im Gange ist. 
Am Anfang alles freiwillig, aber sicher schreiben es Onlinedienste 
irgendwann vor, und dann ist ende mit Pseudonymität online, und wir 
enden mit einem von Firmen kontrollierten China-artigen Social Credit 
System...)


1) 
https://opensource.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting-discussion-around-vulnerabilities-in-open-source.html#:~:text=Goal:%20Authentication%20for%20Participants%20in%20Critical%20Software

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Es ist aber nicht so, dass es keine Ideen gibt, um das Problem mit
> technischen mitteln zu lösen.

Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen, 
es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur 
die Überschrift?

Definiere einfach deine Paketquelle und die verlangte Version, dann 
nimmt dein Paketsystem nicht einfach die höchste Version die es im 
Internet finden kann.

🐧 DPA 🐧 schrieb:
> Irgendwann will man die
> Dependencies ja auch updaten, auch um mögliche Sicherheitslücken in
> alten Versionen zu schlissen. Dann macht man "npm/pip/cargo update", und
> was glaubst du, was dann passiert? Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Genau und dieser Schritt macht man von Hand. Es ist eine bewusste 
Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was 
einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen. Und 
ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf 
Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail 
nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3 
das Update Version 22.0.0 macht, sollte man das nachprüfen.
In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im 
Buildsystem automatisch die neueste Version genommen wird, wenn keine 
Version spezifiziert wurde. Ohne dass man bewusst nach einem Update 
verlangt hat.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Genau, es tut was es soll, und
> aktualisiert die Versionen der Abhängigkeiten.

Bitte lies den Beitrag von Operator S. noch einmal.
Dann informiere dich, was Semantic Versioning ist und was mit diesem 
Satz gemeint ist:

> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und dann informiere dich, wie crates.io und Cargo funktionieren.

Das ist und bleibt PEBCAK.

Wenn ich Cargo sage, dass es immer die neuste Version der Schiene ziehen 
soll, egal von welcher Quelle, dann macht es genau das. Oh Wunder.
Wenn ich Cargo sage, dass es das nicht tun soll, tut es das nicht.
Wie ich schon vor einiger Zeit schrieb: Es ist ein Konfigurationsfehler.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Operator S. schrieb:
> Es braucht keine Ideen um das Problem mit technischen Mitteln zu lösen,
> es ist bereits gelöst. Liest hier keiner mehr die Artikel, sondern nur
> die Überschrift?

Nein, Supply Chain Attacks sind real, und auch heute immer noch ein 
Problem. Das kannst du gerne leugnen, ändert aber nichts daran, dass 
diese überall immer mal wieder auftreten.

Operator S. schrieb:
> Definiere einfach deine Paketquelle und die verlangte Version, dann
> nimmt dein Paketsystem nicht einfach die höchste Version die es im
> Internet finden kann.

Ich nehme an du beziehst dich da auf Cargo.lock und co., wenn Projekte 
das direkt in ihrer Cargo.toml machen würde, würde das ja das ganze 
semver Konzept ad absurdum führen. Updaten muss man aber trotzdem von 
zeit zu zeit.

> Operator S. schrieb:
> 🐧 DPA 🐧 schrieb:
>> Irgendwann will man die Dependencies ja auch updaten,
>> ...
> Genau und dieser Schritt macht man von Hand. Es ist eine bewusste
> Aktien, dass man was verändert hat. Wenn man dann einfach nimmt was
> einem hergeworfen wird, sollte man sich ein anderes Handwerk suchen.

Das ist mir schon klar. Wenn man aber immer mal wieder liest, wie ein 
Security Researcher mal wieder was bei allen möglichen Firmen 
eingeschleust hat, dürfte ja wohl klar sein, dass das nicht dem 
entspricht, was in der Realität in der Regel gemacht wird. Ist ja auch 
nicht erstaunlich, wenn Projekte 100te Dependencies haben, die man 
updaten muss.

Operator S. schrieb:
> Und ich meine hier nicht den Fall, dass ein Paket von Version 1.2.3 auf
> Version 2.1.0 ein Update erhalten hat und man bis ins letzte Detail
> nachschauen muss, was ist anders geworden. Wenn aber aus Version 1.2.3
> das Update Version 22.0.0 macht, sollte man das nachprüfen.

Bei Supply Chain Attacks ist der Angreifer nicht gezwungen, die Major 
Version zu ändern, im Gegenteil, man will ja nicht auffallen. Deshalb 
ist es in dem Bezug völlig egal, ob das nur ein Minor Update ist, 
nachprüfen sollte man trotzdem. Nur um zu schauen, ob es noch läuft, 
kann man auch automatisierte Tests machen, das ist eine andere 
Baustelle.

Operator S. schrieb:
> In der oben verlinkten "Sicherheitslücke" geht es aber darum, dass im
> Buildsystem automatisch die neueste Version genommen wird, wenn keine
> Version spezifiziert wurde. Ohne dass man bewusst nach einem Update
> verlangt hat.

Naja, eigentlich war da das Problem mit Privaten vs. Öffentlichen Repos. 
Das ist aber nur einer von vielen Wegen, wie sowas passieren kann. Ein 
Projekt wechselt den Maintainer, jemand lädt versehentlich seine 
Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert. Wobei, 
bei Crates scheint das seltener zu passieren als z.B. bei Chrome 
Extensions.

MaWin schrieb:
> mh schrieb:
>> Und ja, ich sehe Malware in der Abhängigkeit als Qualitätsproblem.
>
> Wie soll die Malware da plötzlich hinein kommen?
> Warum soll mir ein Entwickler plötzlich Malware unterschieben?

Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum 
sollte es darunter kein schwarzes Schaf geben?

Semantic Versioning kann eine nette und nützliche Sache sein, aber 
Supply Chain Attacks kann es definitiv nicht verhindern.

von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> jemand lädt versehentlich seine
> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.

Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man 
leider wenig machen.

Höchstens so etwas:

https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field

🐧 DPA 🐧 schrieb:
> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
> sollte es darunter kein schwarzes Schaf geben?

Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich 
Malware heraus?
Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt 
herbeikonstruierst, um Recht zu behalten.

Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.
Früher im Thread wurde behauptet, dass Leute ihre Dependencies gerne 
100% auditieren wollen. Ja dann bitte. Tut das. Das würde ja dieses 
konstruierte Malwareproblem vollständig lösen.

Das hat alles überhaupt gar nichts mit Rust zu tun!

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> jemand lädt versehentlich seine
>> Zugangsdaten in Git mit hoch, und schwups, schon ist es passiert.
>
> Dann ist dieser Entwickler halt unfähig. Gegen Unfähigkeit kann man
> leider wenig machen.

Nicht zwangsläufig. Sowas ist schnell mal passiert, und könnte jedem 
passieren.

> 🐧 DPA 🐧 schrieb:
>> Bei hunderten Abhängigkeiten würde ich mich doch eher fragen, warum
>> sollte es darunter kein schwarzes Schaf geben?
>
> Ein Entwickler, der lange gute Versionen herausbrachte, bringt plötzlich
> Malware heraus?
> Wann ist das einmal passiert? Das ist doch ein Fall, den du dir jetzt
> herbeikonstruierst, um Recht zu behalten.

Die Maintainer von Software können sich auch ändern, beim Updaten schaut 
da selten jemand nach. Und auch sonst gibt es viele Wege, wie soetwas 
unabsichtlich passieren kann.

z.B. hatte es mal kurz bootstrap erwischt: 
https://nakedsecurity.sophos.com/2019/04/08/bootstrap-supply-chain-attack-is-another-attempt-to-poison-the-barrel/

z.B. Chrome extensions werden gerne mal verkauft: 
https://www.theregister.com/2021/01/07/great_suspender_malware/

Manchmal ist es auch nur ein blöder typo: 
https://github.com/jsdelivr/jsdelivr/issues/18070 (Hat damals glaube ich 
einige getroffen)

Es gäbe noch mehr Beispiele, ist alles schon passiert.

MaWin schrieb:
> Und wo ist der Unterschied zu jedem anderen System? z.B. Linux-Repos.

Das hängt jeweils von der konkreten Distribution und dessen Prozessen 
ab. Zumindest bei fixed Release Distros gibt es oft einen zumindest 
teilweise split zwischen Distro Mantainern und Entwicklern / 
Projektmaintainern. Eine Art 2 Augenprinzip, wenn man will. Die Distro 
Maintainer kennen sich entweder untereinander (kleine Distros), gehören 
zur selben Firma (z.B. RedHat), oder müssen anderweitigen Prozessen und 
Anforderungen genügen (z.B. debian), etc. Es gibt zudem normalerweise 
gewisse Moderadionsstrukturen, nicht jeder kann einfach Zeugs hochladen, 
und wie ein Maintainer mit Problemen umgeht, sowie soziale Aspekte, 
können jenachdem auch beachtet werden. Ausserdem ist es auch möglich, 
problematische Software zu entfernen. Die Pflege / das Managemant der 
Repos ist oft das entscheidende Alleinstellungsmerkmal von 
Distributionen.

MaWin schrieb:
> Niemand, auch nicht Cargo, zwingt jemanden zu einem Update.

Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

MaWin schrieb:
> Das hat alles überhaupt gar nichts mit Rust zu tun!

Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
Ja ja, schon klar, nur Reden, wenn es pro Cargo und pro Rust ist, ist 
notiert 🙄

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Wer hat das behauptet?

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?
>
> Wer hat das behauptet?

Operator S. schrieb:
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka

Klar, das war weniger allgemein gehalten gedacht, läuft am Ende aber auf 
das heraus.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> läuft am Ende aber auf das heraus.

Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen 
unterstellst, die ich nicht getätigt habe.

Und die dazu noch aus dem Zusammenhang gerissen sind.

Aber das machst du natürlich extra.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Nie upzudaten ist aber auch nicht unbedingt Sicherheitstechnisch ideal.

Was willst du eigentlich?

Du willst nicht updaten, weil das zu Sicherheitsproblemen führen könnte. 
Die neue Version könnte ja Malware enthalten, weil der Maintainer 
plötzlich zum Gangster wird.

Du willst updaten, weil das zu Sicherheitsproblemen führen könnte. Die 
alte Version könnte ja Bugs enthalten.

Wie soll man das lösen?
Es ist unlösbar.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> 🐧 DPA 🐧 schrieb:
>> läuft am Ende aber auf das heraus.
>
> Es läuft einzig und alleine darauf hinaus, dass du mir Aussagen
> unterstellst, die ich nicht getätigt habe.

Keineswegs. Ich habe dich lediglich darauf hingewiesen, warum das ganze 
hier Relevant wurde:

🐧 DPA 🐧 schrieb:
> MaWin schrieb:
>> Das hat alles überhaupt gar nichts mit Rust zu tun!
> Und deshalb schützt cargo nun plötzlich doch vor Supply Chain Attacks?

Supply Chain Attacks in Relation zu Semantic Versioning / cargo war die 
relevante Problematik, um die es in der momentanen Argumentation seit 
Beitrag #6584067 ging. Das ist auch, weshalb das ganze hier überhaupt 
relevant wurde. Ich dachte es wäre klar, worüber wir Diskutieren?

MaWin schrieb:
> Was willst du eigentlich?

Zu einem klareren Bild der ist-Situation und existierenden Problematiken 
beitragen?

MaWin schrieb:
> Wie soll man das lösen?
> Es ist unlösbar.

Ja, das ist so.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Ich dachte es wäre klar, worüber wir Diskutieren?

Ja, das ist klar.
Über alles, aber nicht mehr über Rust.

> Ja, das ist so.

Dann können wir es ja damit abschließen, dass auch Rust unlösbare 
Probleme nicht löst.

Ok?

von cppbert (Gast)


Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Ja, das ist klar.
> Über alles, aber nicht mehr über Rust.

für den Rest:

"Rust" ist keine Platform sondern die Programmiersprache

Cargo ist der Standard Package-Manager und das Buildsystem für Rust - 
aber sogar das muss man nicht nutzen

und der Package-Manager kann so verantwortungslos (ich geben keine 
Versionen and und ziehe immer latest) bis zur absoluten statik (mein 
eigenes lokales crate wo ich alles von Hand rein tragen muss) 
konfiguriert werden - da kann man so viele Review Prozesse einschieben 
wie man braucht und will

Alle Package-Manager können das - und ja, die werden von Millionen 
Leuten verwendet und das kann gefährlich sein - sogar GitHub und GitLab 
machen das wenn man z.B. die submodule updated - von irgendeinem Projekt

und die Programmiersprache Rust ist auch nicht deswegen schlechter als 
andere weil ihr Standard-Package-Manager die gleichen unlösbaren 
Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also 
um was geht es?

Ich arbeite u.a. in Projekte in dem alles durch ordentliche 
Review-Phasen laufen muss und jedes noch so kleine 3rd-Party Update 
einen riesen Aufwand verursacht - die haben teilweise auch lokale 
Package-Manager für C++ im Einsatz und die Packages die da rein kommen 
sind eben reviewed

Vetrauen ist alles und Kontrollen machen die wenigsten - 
höchstwahrscheinlich sogar die am wenigsten die hier so gross davon 
reden wie wichtig das alles ist...

von mh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Operator S. schrieb:
> mh schrieb:
>> Da müsstest du die Beiträge von vor einem Monat lesen
>
> Hab ich, den Thread verfolge ich seit Beginn.
>
> Ironischerweise, löst genau Semantic Versioning das beschrieben Problem
> von derguteweka (Warum auch immer das hier in einem Rust Thread gelandet
> ist...)
>
> Wenn man nämlich nur schreibt Package Install MyFancyLib, dann holt er
> sich das Package mit der höchsten Version das er finden kann. Ein
> "Hacker" erstellt dann einfach auf der öffentlichen Paketsource ein
> MyFancyLib mit einer sehr hohen Version und Zack landet es in deinem
> System.
>
> Wenn man aber die Version spezifiziert a la Package Install MyFancyLib
> 1.2.5 dann holt er genau diese eine Version.

Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt 
definiert sind? Und in den Dependencies der Dependencies von MyFancyLib?
Nachdem ich eben etwas auf crates.io gestöbert habe, muss man das wohl 
explizit selbst prüfen, da die meisten crates Dependencies explizit oder 
implizit als "Caret requirements" angeben. Ich hab einige ziemlich lange
Ketten verfolgen können.
Es ist auch klar warum das so ist. Niemand hat lust sich häufig 
"Dependency Resolution failed" vom resolver zu beschäftigen.

🐧 DPA 🐧 schrieb:
> Wobei,
> bei Crates scheint das seltener zu passieren als z.B. bei Chrome
> Extensions.
Bleibt die Frage, ob es tatsächlich so ist, oder ob es nur scheint. Die 
Zielgruppe für Chrome Extensions ist vermutlich deutlich größer.

cppbert schrieb:
> und die Programmiersprache Rust ist auch nicht deswegen schlechter als
> andere weil ihr Standard-Package-Manager die gleichen unlösbaren
> Sicherheitsprobleme erzeugen kann wie jedes andere diese Systeme - also
> um was geht es?

Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den 
Pflegeaufwand für Software reduziert:
mh schrieb:
> cppbert schrieb:
>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>
> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen

In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust 
angepriesen:
cppbert schrieb:
> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
> rumgurken

von Operator S. (smkr)


Bewertung
0 lesenswert
nicht lesenswert
@ mh, dann benutz es doch einfach nicht

von cppbert (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Wenn ich mich richtig erinnere, hast du behauptet, dass cargo den
> Pflegeaufwand für Software reduziert:
> mh schrieb:
>> cppbert schrieb:
>>> Jede Library hat die 5000.Implementation von irgendeinem Micro-Scheiss
>>> im Bauch die so viel Pflege-Energie frisst - das versucht Rust mit einer
>>> Zerlege- es-in-Libs-und-verteile-die-leicht zu reduzieren
>>
>> Damit ist man den Pflegeaufwand aber nicht los geworden, sondern verlegt
>> ihn nur woanders hin. Du musst regelmäßig die Abhängigkeiten prüfen
>
> In dem gleichen Beitrag hast du das übrigens auch als Vorteil von rust
> angepriesen:
> cppbert schrieb:
>> 4. Anstatt das jedes noch so kleine Projekt Self-Contained ist baut Rust
>> einfach darauf das sich die Code-Duplikation über viele, gut gepflegte
>> Libraries reduziert die in den heutigen Projekten in Mio Zeilen Code
>> rumgurken

das sind zwei paar Stiefel

Das einen ist die undurchsichtige und Codelastige alles-selber-machen 
Kultur durch eine es-gibt-viele-kleine Crates die sich auf Aufgaben 
konzentrieren Kultur zu ersetzen - die Libs werden kleiner und überhaupt 
reviewbarer

Das ist das Konzept das wir alle intern mit jeder unserer eigenen 
Komponenten fahren - was vom Grundsatz nicht falsch und nicht wirklich 
diskutierbar ist

bei C/C++ klappt das einfach Aufgrund des schwierigen Deployments 
(welche Make-Tool, 3rd-Parties, etc.) nicht so gut über die 
Projektgrenzen hinweg,  ist aber eher eine historische Schwäche als ein 
gewolltest Konzept von C/C++

Das zweite ist die Menge der Entwicklern die plötzlich Einfluss auf dein 
Projekt haben könnten - da geben ich dir recht das es nicht einfacher 
wird - aber Monolithen-Libs mit viel gemeinsamen Redundanzen ist es eben 
auch nicht - da wähle ich lieber die Qualität ergibt sich durch die 
Community - und wenn ich viele 3rd-Parties brauche bin verliere ich auch 
mit C/C++ recht schnell die Kontrolle (falls man wirklich nicht auf die 
3rd-Parties verzichten kann)

und ich denke die wenigsten hier machen überhaupt irgendwelche Reviews 
von 3rd-Parties - wenn es kompiliert und die Tests laufen ists gut wird 
wohl die Standard-Devise sein, die Community der Libs oder gar die 
Kern-Entwickler haben auch die wenigsten auf ihrer Kontakt-Liste also 
ist die Qualität nur gut weil man nix negatives im Internet liesst oder 
eben keinen 3rd-Parties hat

noch dazu heisst es ja immer das Rust nicht nötig ist weil jede Firma 
sowiso nur Profi-Entwickler angestellt haben sollte - d.h. die können 
sich dann in Rust aufhören mit den internen Problemen zu beschäftigen 
sondern nur noch Algorithmik und die Sicherheits-Probleme durch die 
vielen 3rd-Party Abhängigkeiten bekämpfen :)

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Und du stellst sicher, dass in MyFancyLib die Dependencies 100% korrekt
> definiert sind?

nein. Ich nicht.
Das war aber auch nie meine Anforderung.

Beitrag #6602631 wurde von einem Moderator gelöscht.
von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mit dem neuen VS2019 16.9 Release können wir jetzt auch unter 
Windows/VStudio mit dem ASAN arbeiten - raus aus der Beta-Phase - läuft 
super - "leider" keine Findings da mein Code ja schon unter Linux seit 
einigen Jahren unter Sanitzer Kontrolle steht

https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.9.0

Und für die "C++ ist ausreichend perfekt durch ASAN"-Fraktion:

Stellt euch mal vor wenn google nicht aus Eigeninitative die Sanitizer 
entwickelt hätte - wohlgemerkt nach "Jahrzehnten" der C/C++ Existenz, 
was würde eigentlich dann weiterhin für die Memory-Sicherheit bei C/C++ 
Applikationen unter Windows sorgen - der olle Intel Inspector, Dr. 
Memory...?

und ja ist versteht das auch Rust einen Neuentwicklung ist - nur ist da 
sowas von Anfang an dabei, C/C++ hat dafür 25 Jahre auf einen 
Gross-Konzern warten müssen

von cppbert3 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
und auch wenn ihr mir nicht glaubt (oder ich nur viele Idioten kenne)

Es gibt sogar C/C++ Entwickler die nicht verstehen was an Rust besser 
ist UND die zusätzlich auch keinen Sinn in den Sanitizern sehen

Noch besser: die den Sinn von Sanitizer erst verstehen wenn man ihnen
im VStudio, in ihrem Code einen durch den ASAN gefundenen Bug zeigen 
kann - meistens wird dann ganz schnell aus einem unwissenden Kritiker 
ein Missionar

ganz nach dem Motto: Erst wenn ich den Schimmel wirklich schmecken kann 
erkennen ich das irgendwas mit meinem weiß pelzigen Brot nicht stimmt :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.