Kommentare - - Seite 89

Also, ich habe entweder das Problem nicht erkannt oder ich frage mich, wieso man nicht darauf zu kommen scheint, dass jede Zahlenbereichserweiterung eine neue Unendlichkeit erzeugt.
Danach gibt es zwischen den natürlichen Zahlen und den reellen Zahlen drei verschiedene Unendlichkeiten: die ganzen Zahlen, die rationalen Zahlen und die irrationalen Zahlen. Die natürlichen Zahlen sind Teilmenge der ganzen Zahlen. Die ganzen Zahlen sind Teilmenge der rationalen Zahlen. Die irrationalen Zahlen haben ihre eigene Menge. Die rationalen Zahlen und die irrationalen Zahlen vereinigt sind die reellen Zahlen.
Somit haben wir es dabei mit fünf verschiedenen Unendlichkeiten zu tun.

Die reellen Zahlen sind als Realteil Teilmenge der Komplexen Zahlen. Was eine weitere Unendlichkeit ergibt. Der Imaginärteil ist zwar eine weitere Teilmenge der Komplexen Zahlen, aber genauso groß wie der Realteil. Und auch seine imaginären Teilmengen entsprechen den Teilmengen des Realteils.
Somit haben wir es im gesamten mit sechs verschiedenen Unendlichkeiten zu tun: alleine aus Betrachtung der Zahlenbereichserweiterung.

Es gibt eine internationale Kampagne, die das politische Gefangenendilemma als zentrales Problem ("generator function") in verschiedenen Bereichen erkannt hat und überwinden möchte (z.B. Klimakrise) und dafür einen konkreten Pfad vorschlägt, den Bürger gehen können. Mehr Informationen findet man unter
https://de.simpol.org/

dass die Art, wie diese Software entstanden ist, und die Art, wie Unternehmen, die damit Geld verdienen wollen, sie jetzt benutzen, nicht zusammenpasst. Nicht die Opensource Programmierer sind das Problem, sondern die Unternehmen, die die Software einfach gratis übernehmen, ohne mitzudenken.
Ich arbeite seit 20 Jahren ausschliesslich mit Linux. Ich brauchte 5 Minuten, um Log4j auf 65 Linuxservern zu patchen.

Für mich einer der größten Pioniere der Raumfahrt: https://de.wikipedia.org/wiki/Larry_Walters

Liebes Spektrum-Team,
Vielen Dank für diesen sehr interessanten Artikel.
Die Kontinuumshypothese ist allein mittels ZFC nicht entscheidbar. Dies ist doch ein akzeptables Ergebnis. Sie durch Hinzunahme weiterer plausibel erscheinender Axiome entscheiden zu wollen, kann je nach Wahl dieser Axiome sowohl zu ihrer Bestätigung als auch zu ihrer Widerlegung führen.
Das jahrzehntelange Ringen und die sehr zögerlichen Fortschritte in dieser Frage sprechen eher dafür, dass mengentheoretisch/logische Argumente allein nicht ausreichen.
Wäre es nicht naheliegender die Eigenschaften der reellen Zahlen und deren Teilmengen mittels geeigneter Maße und Abbildungseigenschaften zu untersuchen und sich über diese Charakteristiken an die Kardinalzahlen heranzutasten?

Herzliche Grüße aus Freiberg
Lutz Muche

Fast hätte ich mir das Buch von Ralf Otte gekauft. Der zweite Teil der Rezension von Michael Hedenus hat mich dann aber doch davon abgehalten. Es gibt drei Abschnitte, die mich stutzig gemacht haben.
Zum ersten favorisiert Otte neuromorphe Chips für (Maschinen-)Bewusstsein, weil es sich hier um Hardware handele, in denen echte physikalische Größen verarbeitet würden. Aber diese können Gehirnzellen doch auch nur simulieren, denn es sind ja keine solchen. Ich will nicht abstreiten, dass neuromorphe Chips das möglicherweise besser können, aber das dies auf Softwarebasis nun gar nicht möglich sein soll, halte ich für vollkommen unbegründet und offensichtlich begründet Otte dies ja auch nicht.
Zum zweiten geht es um die Verortung des Geistes. Wenn Otte die Einstellung vertritt, dass es einerseits keine dualistische Scheidung von Geist und Materie gäbe, andererseits Geist aber auch nicht aus der Materie entspränge, so ist das ein klarer Widerspruch. Entweder ist Geist ein materielles Phänomen oder er ist es nicht, dann ist es aber eben doch ein dualistischer Ansatz, auch wenn der nur »einen Millimeter« neben dem Materialismus liegt.
Als »Ausweg« aus dem Dilemma muss dann drittens mal wieder die Quantenphysik herhalten - wie schon bei Roger Penrose in »Computerdenken«. Abgesehen davon dass ein Begriff wie »vor-physisch« (was soll das sein?) völlig in der Luft hängt und absolut nichts erklärt, sind die Aussagen der Quantenphysik immer noch physikalischer Natur - auch wenn sie Wahrscheinlichkeitsaussagen sind. Was auch immer die Quantenphysik letztlich für uns bedeuten mag, Zuschreibungen wie »vor-physisch« sind hier völlig fehl am Platze.

Ich war Uni-IT-Mitarbeiter. Ca 20 Jahre lang wurden meine Daten immer wieder modifiziert, geloescht, gelesen, Zugang zu Programmen blockiert.
Wenn ich mich beschwerte, hiess es: "da kann man nichts machen". Am Ende wurde ich gekuendigt.

Vorweg, ich bin kein Mathematiker, und mir fehlt daher möglicherweise das Verständnis für die von Mathematikern hier offenbar gesehene Problematik!

Nach dem lesen des Artikels habe ich aber irgendwie den Eindruck, dass hier möglicherweise erst ein Problem "geschaffen" wurde, um dann quasi unendlich lange, nach einer Lösung zu suchen (suchen zu können).
Die Eingangsfrage, wie groß die Differenz der Anzahl der reellen zu den natürlichen Zahlen ist, wenn man in beiden Fällen tatsächlich von einer unendlichen Anzahl/Menge von Zahlen ausgeht, ist, meiner Meinung nach, relativ einfach zu beantworten:
Die Differenz beträgt: "Unendlich hoch Unendlich" (Leider kann ich hier die Symbole dafür nicht darstellen).
Die Begründung ist auch relativ einfach, in einer unendlichen Zahlenreihe von natürlichen Zahlen, gibt es zwischen jeder dieser natürlichen Zahlen eine unendliche Anzahl von reellen Zahlen, in Form der dazwischenliegenden Dezimalzahlen.
Damit ist die Eingangsfrage doch eigentlich beantwortete!?
Der Wunsch, den die Mathematiker hier möglicherweise wirklich verfolgen, diese Differenz einer Vorstellungskraft zu unterwerfen, scheitert dabei aber an der Unendlichkeit der Zahlenräume. (Unendlich = Unendlich +1)
Auch wenn man zu Zeiten von Euklid wohl bereits bei 5stelligen Zahlen (Myriade) an die Grenze der Vorstellungskraft gekommen sein soll, weiß man doch heute, dass es für unendliche Zahlen eben tatsächlich keine Grenze gibt.
Höchstens eine die dadurch entsteht, dass unsere Rechenleistung für die Darstellung nicht ausreicht, bzw. man noch keine Namen hierfür definiert hat, und/oder es an der Vorstellungskraft hierfür mangelt.

Der auf S.15 dargestellte Vergleich der natürlichen Zahlen, mit den ungeraden Zahlen, geht dann meiner Meinung nach auch von einer falschen Annahme aus: Die Unendlichkeit ist war mathematisch definiert, sie unterscheidet sich aber je nach Ausgangslage. Damit ist die Menge der unendlichen natürlichen Zahlen eben tatsächlich doppelt so hoch, wie die Menge der unendlichen ungeraden Zahlen, weil per Definition jede ungerade Zahl von einer geraden Zahl "begleitet" wird, sodaß tatsächlich die Summe der unendlichen geraden Zahlen und die der unendlichen ungeraden Zahlen der Menge der unendlichen natürlichen Zahlen entspricht. Und dies lässt sich eben auch anhand von Berechnungen mit beliebigen endlichen Zahlenreihen schlüssig beweisen.
Das im Artikel dargestellte Forcing (S.17) ist hier, meiner Meinung nach, auch mit einem Denkfehler durchzogen.
Die Problematik liegt auch hier in der Unendlichkeit.
Damit kann man zwar auf der Achse einen beliebigen Punkt als Ausgangspunkt definieren, solange dieser nicht vom Ende der Achse abhängig sein soll, der bei einer unendlichen Achse nicht erfassbar wäre, aber bei der Teilung der Abschnitte, wie beschrieben, stößt man auf das Problem der unendlich großen Menge an reellen Zahlen.
Führt man die Teilung wie in der Grafik beschrieben, daher unendlich oft aus, kommt man tatsächlich niemals zu einem Ende dieser Berechnung in Form einer reellen Zahl.
Dies würde eben nur funktionieren, wenn man sich hier mit einer endlichen Menge an reellen Zahlen (bzw. Nachkommastellen) befassen würde, die Unendlichkeit verhindert dies aber eben in der konkreten Aufgabenstellung. Indem man hier im dargestellten "Forcing" (S.17) tatsächlich eine endliche Menge voraussetzt, verändert man aber die Aufgabenstellung, und kann so nicht zu einem Ergebnis der Eingangsfrage gelangen.
Auch kann man dadurch (Bei unendlichen reellen Zahlen!) keine neue Zahl "erschaffen", da diese ja bereits vorher in der Menge der unendlichen reellen Zahlen auf dem betrachteten Abschnitt der Achse vorhanden war.
Dies wäre wohl nur möglich, wenn man die Menge der reellen Zahlen (bzw. der Nachkommastellen) vorher endlich beschränkt, um dann in einem letzten, der dann endlichen, Rechenschritte (bzw. Abschnitte) diese vorher geschaffene Grenze um einen Schritt überschreitet, um so eine zuvor in der endlich beschränkten Menge der reellen Zahlen nicht vorhandene Zahl als Ergebnis zu bekommen.
Unabhängig davon, dass zumindest nach meinem Verständnis der Problematik, nach dem lesen des Artikels, und ohne mich sonst mit der Thematik beschäftigt zu haben, die Lösung relativ einfach scheint, wenn sie auch möglicherweise jenseits der plastischen Vorstellungskraft liegt, frage ich mich bei solchen "mathematischen Problemen" (im Gegensatz zu anderen "Problemen" wie z.B. der Suche nach neuen Dezimalzahlen oder Stellen von Pi) auch oft, welcher praktische Nutzen in einer Antwort auf diese Frage bestehen kann, dass sich, wie hier, die Wissenschaftler seit 150 Jahren offenbar vielfach und intensiv damit beschäftigen, und ihre Arbeits- und Lebenszeit hierauf verwenden?
Was könnte man mit einer (tatsächlich für uns berechenbaren) Antwort auf diese Frage wirklich praktisch anfangen?

"Vielmehr basieren Artenreichtum und die Grundlage allen irdischen
Lebens auf Symbiose, gemeinsamer Anstrengung und Kooperation: »Evolution ergibt sich aus gemeinschaftlichen Antworten auf sich wandelnde Lebensbedingungen.«

Jetzt wird hier sogar schon die Evolutionstheorie verballhornt im Kampf gegen den Neoliberalismus.

Wenn bestimmte Ressourcen nicht verbraucht werden sollen, kann man deren Verbrauch im gewünschten Umfang durch Gesetze reduzieren. Wenn dann trotzdem noch BIP-Wachstum resultiert, sollte das eigentlich niemanden stören - wenn es tatsächlich um den Verbrauch von Ressourcen geht. BIP-Wachstum resultiert aus dem Streben der Menschen nach mehr Einkommen. Bessere Bildung führt zu höherer Arbeitsproduktivität und damit zu mehr BIP. Wollen wir die Bildung verbieten oder wissenschaftlichen Fortschritt...?

Aber wahrscheinlich geht es ja gar nicht um den Verbrauch von Ressourcen sondern um den Systemwechsel.

Auch von mir vielen Dank für diesen tollen Bericht. Von diesen Unendlichkeiten in der QFT habe ich schon oft gelesen und dass man diese mit der sogenannten Renormierung beikommen konnte. Aber was das anschaulich bedeutet, impliziert, das habe ich noch nirgends gelesen - hier das erste Mal. Und die anschauliche Darstellung, was weitere offene Probleme der QFT sind, finde ich auch super toll. Man liest ja oft nur, dass die Quantenwelt durch das Standardmodell zu einem tollen Grad beschrieben ist und "nur noch" Vereinigung mit der Gravitation ausbleibt, sowie Dunkle Energie + Materie. Und dann Mal zu sehen, dass auch innerhalb des Standardmodells offene Punkte gibt, z.B. Confinement Beschreibung, das ist doch auch Mal interessant zu sehen und bringt was Licht für den Laien, was da am Cern eigentlich sonst noch so passiert :D.

17 Jahre sind in der Softwareentwicklung eine Ewigkeit - eine Studie aus 2004 2021 als Beleg dafür heranzuziehen, dass quelloffene Software besser gegen Fehler abgesichert sei als proprietäre, wirkt arg an den Haaren herbeigezogen. Gibt es keine neueren Untersuchungen dazu oder haben diese keine passenden Ergebnisse für diesen Artikel geliefert? Nach meinen Erfahrungen sieht es im Endeffekt so aus: Open Source kostet nichts - man muss sich dafür teuere Spezialisten leisten, die sich um Wartung und Sicherheit kümmern. Und wenn will man in Regress nehmen, wenn es doch einmal größere Probleme gibt? Beim Freelancer wird nichts zu holen sein, wenn er nicht so klug war, die Haftung von vornherein ausreichend zu beschränken, und bei den Providern der Bibliotheken steht stets dabei "provided as is" - Nutzung auf eigene Gefahr.
Für proprietäre Software zahlt man auch viel Geld - kann aber bei groben Fehlern den Hersteller in Regress nehmen. Und die allermeisten haben aus der Vergangenheit gelernt und sichern ihren Code wesentlich besser ab als früher. Wenn der Quellcode nicht offen für jedermann herumliegt, hat das auch einen Vorteil: Man muss schon ein bisschen mehr herumbohren, um Schwachstellen zu finden.

Danke für Ihren leicht verständlichen Überblick über diese unanschaulichen Sachverhalte!

Meiner Ansicht nach ist das Problem, jeder verlässt sich auf die Software und benutzt diese gerne, aber keiner sieht, dass extrem wichtige OpenSource Projekte teilweise von 1-2 Personen betreut werden, die für ihren wichtigen Dienst an der Allgemeinheit nicht bezahlt werden. Solange das der Gesellschaft egal ist und die zentralen Projekte nicht durch massive Spenden (von Staaten oder großen Firmen, die die Software nutzen) unterstützt werden, wird genau soetwas immer wieder passieren. Es ist also ein hausgemachtes Problem und spätestens nach dem Heartbleed OpenSSL Bug hätte man das wissen können. Schade.

Sechsjährige lernen typischerweise gerade schreiben. Die können ganz sicher keinen Exploit für die Lücke schreiben.

Wie konnte es dazu kommen? Kein Qualitätsbewusstsein in der Softwareentwicklung. Vielleicht ist die bei vereinzelten Mitarbeitern noch vorhanden, auf Führungsebene ist aber meist (ich habe es nie anders erlebt) nur wichtig dass die Software tut was sie soll, und eben nicht dass sie nicht tut was sie nicht soll. Das führt dazu, dass Komponenten verwendet werden, ohne sie wirklich zu verstehen, und ohne über die Gefahren und Nachteile nachzudenken. Das würde ja Zeit kosten. Was da verwendet wird muss nicht Open Source sein, das ist eine vollkommen unabhängige Frage.

Viele Programmierer/Manager sind genauso unvorsichtig wie der durchschnittliche Anwender: Mehr Features sind besser, ich will nicht lernen sondern machen. Software und Bibliotheken die meine Arbeit automatisch erledigen sind besser. Das führt dazu, dass überkomplexe Werkzeuge und Bibliotheken verwendet werden, die zwar auf kurze Sicht ein konkretes Problem lösen, aber darüber hinaus auch Eigenschaften haben die man eigentlich gar nicht braucht. Auch wird beim Wunsch nach einer Funktion oft nicht bedacht welche Konsequenzen sie haben kann.

In genau diese Kategorien fällt Log4j: Eine Firma braucht ein System um Logs zu schreiben. Einer ihrer Coder findet Log4j, und schafft es das einzubinden. Eigentlich sollte er jetzt alle Funktionen von Log4j ergründen, und diese Kompetenz im Unternehmen etablieren. Dafür hat aber niemand Zeit. Statt dessen wird die Software jetzt mit einer nicht verstandenen Komponente weiterentwickelt.

Das Feature, das Log4j heute zu einer Sicherheitslücke macht, hat irgend jemand mal gebraucht, eingebaut, toll gefunden, aufgehört darüber nachzudenken. Wenn man als Skeptiker warnt etwas wäre zu komplex, dann hört man oft ‘aber das kann X’, ‘aber damit kann man Y’, oder ‘die Konkurrenz kann das auch’ — die Frage wäre aber ob das wirklich sein muss.

“Das Ausmaß der Sicherheitsbedrohung ist so groß, weil Log4j enorm weit verbreitet ist […] Denn es ist eine Open-Source-Software” — Quark. Weit verbreitet sind auch Mac OS X, Microsoft Windows, …, aber nichts davon ist OSS. Die Implikation in dem Satz ist also falsch. Verbreitet ist Log4j, weil es von vielen als nützlich angesehen wird (das sollte man diskutieren). Richtig ist, dass Verbreitung die Relevanz einer Lücke erhöht. Aber auch das ist unabhängig von der open/closed-Frage.

Lustigerweise stimmt der Rest dieses Absatzes im Artikel, dass nämlich OSS tendenziell sicherer ist und Lücken schneller gefunden und gefixt werden, gerade weil nämlich jeder reinschauen kann. Allerdings steht das im Widerspruch zum Spin des gesamten Artikels.

Aus Sätzen wie “Bereits 2014 machte die so genannte Heartbleed-Sicherheitslücke darauf aufmerksam, dass man den Umgang mit Open-Source-Software überdenken muss” folgt die Frage nach der Alternative zu OSS. Und die ist, statt OSS Komponenten eben entweder eingekaufte Closed Source oder selbst entwickelte Komponenten zu verwenden.

Beim Selber-entwickeln kann man sicher sein alle Fehler zu machen die von anderen schon mal gemacht und gelöst wurden, weil man die Erfahrung noch nicht hat, die bei der Entwicklung einer Komponente erst entsteht. Das ist kein Sicherheitsgewinn. NIH ist eine bekannte Quelle von Problemen.

Beim Einkaufen einer Closed Source Komponente, abgesehen davon dass man sich das wird schlicht nicht leisten können, stellt sich die Frage nach der Qualität die man da bekommt, und die man nicht überprüfen kann, weil das die Natur von Closed Source ist. Warum sollte der Lieferant auf Qualität achten, statt aus den gleichen ökonomischen Zwängen wie man selbst etwas zu liefern was einigermaßen tut was es soll, und evtl. auch ein paar Dinge die es nicht soll?

Also was hilft? Finanzielle Anreize dort zu setzen wo sie Wirkung entfalten: Z.B. eine solide Gesetzgebung zum Verbraucher- und Datenschutz, die mit empfindlichen Strafen durchgesetzt werden kann. Dazu gehört die Ausstattung der Behörden mit Personal, Mitteln, und dem Mandat und Willen Unternehmen richtig viel Geld abzunehmen. Ganz alleine entfaltet sich für Firmen dann der Druck ihre Software möglichst sicher zu schreiben. Es muss billiger sein in das Verständnis von verwendeten Komponenten zu investieren, also Verantwortung für sein Handeln zu übernehmen, als eine Sicherheitslücke zu riskieren. Momentan ist es umgekehrt.

Dabei fordere ich keine automatische Produkthaftung für OSS! Ein Horn in das die Hersteller von Closed Source Software gerne stoßen, weil es den OSS-Markt komplett abwürgen würde. Die rechtliche Verantwortung für die Sicherheit einer Software muss bei ihrer Verwendung entstehen, nicht bei ihrer Entwicklung, sie muss bei dem liegen der damit Geld verdient. Durch Verträge kann die Verantwortung verschoben werden, das ist Alltag: Heute zwingen EULAs den Endverbraucher kommerzieller Software zum Tragen aller Risiken. Ein schärferer Verbraucherschutz muss das Risiko dort hin verschieben wo das Geld verdient wird, weil dort liegen die Resourcen Sicherheit einzubauen.

Ein genereller Zwang allen Sourcecode offenzulegen, würde die Sicherheit weiter erhöhen. Man müsste das schrittweise tun, weil, wie der Artikel richtig erkennt, Closed Source Software vermutlich deutlich mehr Fehler und Sicherheitslücken enthält als OSS.

Open Source ist nicht das Problem, sondern die Lösung.

Das Problem ist, dass man mit unsicherer Software sehr viel Geld verdienen kann, ohne für die Risiken zur Rechenschaft gezogen zu werden.

Weder kann ein 6-jähriger diese Lücke ausnutzen, noch verdienen Programmierer regelmässig sechsstellige Beträge. Ja es handelt sich nicht mal um eine Lücke oder einen Fehler. Die Software arbeitet wie designed.

Die Kostenzwänge unter denen Projekte entstehen, führen dann aber dazu das Pakete wie log4j verwendet werden ohne ihre Konfiguration zu prüfen. JNDI war per default an. Nun ist es per default aus.

Ist so ein reisserisches Niveau hier wirklich nötig?