Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsLinux-News der Woche: FSR 4 für Linux, sudo-rs für Ubuntu und FFmpeg mit APV
Dank intensiver Arbeit der Community gibt es nun die Möglichkeit FSR 4 unter Linux zu nutzen, auch wenn Fallstricke bleiben. Für Gnome gibt es einen neuen Standard-Videoplayer. Ubuntu setzt demnächst auf sudo-rs statt sudo. Zur Batterieschonung gibt es für das Steam Deck nun die Möglichkeit den Ladestand zu begrenzen.
Ich bin schon richtig gespannt wenn FSR4 ohne viel Arbeit dann auf Linux funktioniert (vielleicht geht es ja schon im Juli wenn ich mir eine 9070XT kaufe)
Ah, FSR4 auf RX7000! Ein guter Grund Spiele auf Linux zu Zocken. Der neue Upscaler hat ja vor allem in Sachen Qualität dramatische Fortschritte auf AMD Karten gemacht.
RX 7000 fehlen leider die FP8-Einheiten. Stattdessen wird das simuliert, was allerdings Leistung kostet. Wie viel am Ende vom Upscaling Performance an kommt, wird sich erst noch zeigen, immerhin gibts ne bessere Bildqualität.
Ich frage mich nur, wenn die das alles für Linux machen (was ein riesen Aufwand scheint), wäre es auch irgendwann auf Windows möglich bzw. falls ja, wäre die Umsetzung dort noch komplizierter oder sogar einfacher (also ich meine jetzt nur RX 7000)? Das ist schon extrem technisch, wovon ich keinen Plan habe, aber sehr interessant.
Ich bin schon richtig gespannt wenn FSR4 ohne viel Arbeit dann auf Linux funktioniert (vielleicht geht es ja schon im Juli wenn ich mir eine 9070XT kaufe)
Dass mir der DLL klingt nach Windows Ports, WINE und Gefrickel.
Im Idealfall nur ein Workaround für Windows Ports, dann könnte das für native Spiele schon näher sein.
Ich glaub so etwas immer erst, wenn ich es offiziell nutzen kann. So wie der Linux Port von Counter-Strike 2013, auf einmal “bOOM”
PS: Totem rausfliegt war längst überfällig, jahrelang wurden Features entfernt und zuletzt war es umständlich eine Datei manuell zu öffnen, weil der automatischer Indexer bevorzugt wurde.
Wäre keine Lust auf Gstreamer hat und etwas möchte das auf dem virtuellen Terminal genau so funktioniert wie unter GNOME mit Wayland, dem empfehle ich immer mpv - die schlichte und mächtige Allzweckwaffe. Wer Gtk4 habe will, Celluloid (mpv mit Gtk UI). Warum warten, wenn es gutes schon gibt.
PPS: Und für Musik, Amberol. Wunderschön und einfach. Hat einer der Core Entwickler von Gtk selbst entwickelt. Keine Datenbank, keine Indices.
Ergänzung ()
TechFunk schrieb:
Rust schön und gut, aber die Apache Lizenz.
Fände es besser, wenn unter der GPL oder dergleichen.
Berechtigte Kritik. Wobei das nur Canonical betrifft und die sind für ihre Alleingänge bekannt.
Sudo an sich ist wichtig, wobei andere Distributionen es nicht mal vorinstallieren, weil man lieber eine Superuser hat und - klar getrennt - normale User.
Rust bedeutet nicht automatisch besser und sicher, fehlerhafte Programmierung ist der Grund für Fehler. Speicherfehler sind leider nur eine Kategorie von vielen. Die größte sind Logikfehler.
Für C und C++ Entwickler ist immer die Verwendung des Address-Sanitizer von GCC oder Clang zu empfehlen, seit es diese Werkzeug - im Compiler - gibt ist es ruhig geworden. Wobei ich immer noch auf die Profile - oder ähnlich in C++ - hoffe. Das wäre dann auch der Upgradepfad für C. Wir können den Quellcode nicht ersetzen, zumal man den alten erstmal lesen und verstehen muss. Den Code beim Kompilieren soweit zu sichern wie möglich - analog zu Rust - ist die effiziente Methode. Von Linux, Systemd, Gecko, WebKit, Unreal bis Source2 - alles C oder C++. Ist harte Arbeit, weil an Wunder glaube ich nicht.
Java ist in C++ implementiert. Der C++ Code ist okay. Trotzdem wollte wer eine Teil des Signaturcodes für SSL in Java selbst neu implementierten. Tests? Hm.
Ergebnis: Key mit Länge 0 wird akzeptiert.
Technikglaube, handwerklicher Fehler und unnötiger Code fallen zusammen. Java hat nicht zufällig einen miserable Historie was Sicherheit angeht, was viele Gründe hat (meiner Meinung nach macht es “Code hinklatschen” einfach, und deswegen ist im Geschäftsbereich so beliebt).
Die meisten Fehler sind Logikfehler. Rust macht einem das Leben sicherer. Aber bitte nicht als Freifahrtschein zum Abschalten des Hirns verstehen! Deswegen das mahnende Beispiel mit Java.
Längen- und Breitengrade zu vertauschen ist so ein Ding das ich gerne vermasseln tue. Andere zeigen das Bankkonto anderer Kunden an.
Ich frage mich nur, wenn die das alles für Linux machen (was ein riesen Aufwand scheint), wäre es auch irgendwann auf Windows möglich bzw. falls ja, wäre die Umsetzung dort noch komplizierter oder sogar einfacher (also ich meine jetzt nur RX 7000)?
Beim "die da" fängt es ja schon an. "Die da" ist ja eine bunte Mischung der vd3k, Proton und Mesa[1] Entwickler die Valve sponsort/angestellt hat. Das sind also aus Sicht von AMD und Microsoft externe Dritte. Unter Linux und dem Ökosystem juckt das nicht. Unter Windows wird das aber schon schwieriger. Zum einen ist die Software da nicht (so) Quelloffen und Microsoft wird (aus gutem Grund) arg kritisch sein, wenn Dritte ankommen um am Grafiktreibern und dem DirectX/Vulkan-Stack Modifikationen vornehmen und das als Treiber signiert haben zu wollen.
[1] Mesa enthält Grafiktreiber und alles rund um OpenGL, Vulkan, .. als Abstraktionsschicht. Wobei es bei AMD den Radv-Treiber als Teil von Mesa gibt, der von Valve entwickelt wird und dann nochmal AMDs amdgpu-Treiber.
Die meisten Fehler sind Logikfehler. Rust macht einem das Leben sicherer. Aber bitte nicht als Freifahrtschein zum Abschalten des Hirns verstehen! Deswegen das mahnende Beispiel mit Java.
Längen- und Breitengrade zu vertauschen ist so ein Ding das ich gerne vermasseln tue. Andere zeigen das Bankkonto anderer Kunden an.
Die Zahl ist aus dem Kopf, da es mal von Google eine Untersuchung gab und ich mir echt sicher bin, dass es mehr als die Hälfte aller Fehler waren.
Ich rede hier auch explizit von "Security Vulnerabilities" und nicht von "gewöhnlichen" Bugs, die zwar ärgerlich sind aber kein Sicherheitsrisiko darstellen. Längen- und Breitengrade zu vertauschen fällt unter die Kategorie "ärgerlich aber kein Sicherheitsrisiko in der Anwendung". Bankkonto ist eine Geschichte für den Datenschutz aber auch nur ein Bug (keine Angriffsfläche in der Anwendung selbst).
Dass man ohne Hirn und Verstand programmieren kann mit Rust behauptet wohl keiner. Dafür ist der Borrow-Checker und das Lifetime-Modell dann doch etwas zu komplex, vor allem für Anfänger. Logikfehler passieren immer, weshalb man das Hirn immer benutzen und alles doppelt und dreifach checken sollte. Rust als Sprache baut nur im Gegensatz zu C/C++ wesentlich mehr Leitplanken im Code-Design ein, damit man nicht von der Strecke abkommt ob gewollt oder ungewollt, metaphorisch gesprochen. Man kann auch eine Treppe ohne Geländer bauen und sie problemlos benutzen, mit Geländer ist es aber wesentlich unwahrscheinlicher an der Seite runterzustürzen wenn man nicht aufpasst.
Edit:
Google has revealed that its transition to memory-safe languages such as Rust as part of its secure-by-design approach has led to the percentage of memory-safe vulnerabilities discovered in Android dropping from 76% to 24% over a period of six years.
Kein Speicherfehler bedeutet nicht “kein Sicherheitsproblem”. Die habe wir mit ASAN und Konsorten schon besser im Griff, aber es reicht (noch) nicht.
Warum ist das Vertauschen von Längen- und Breitengraden tödlich:
Flugzeug
Raketen (Hallo Float! Hallo Rundungsdifferenzen!)
Rettungsdienst und Rettungsdienstalarmierung
Karte im Navi falsch
Und leider meinen die Leute immer, ihre Software oder Ihre Funktion ist nicht sicherheitskritisch. Wenn im Kraftwerk wer verzweifelt die Schritte für die Anleitung zur Notabschaltung sucht, sind Fehler in less or grep kritisch.
Und da hilft dann kein “Ich mach doch nichts in kritischer Infrastruktur”.
Wer das falsche Bankkonto anzeigt, kann damit schwerwiegende Konsequenzen auslösen. Vom Skandal, über Erpressung bis Gewalt.
PS: Ich bin leider jemand der über die Qualität unserer Software im allgemeinen unzufrieden ist. Und mein Gefühl sagt mir, Entwicklungszyklen sind zur kurz. Testen - vor allem das manuelle durchtesten - kommt zu kurz.
@flaphoschi
Ich glaube wir beide meinen völlig verschiedene Dinge. Ich rede von Angriffsflächen in der Anwendung, wodurch ein Angreifer bzw. externer Akteur direkt in der Anwendung bzw. auf dem System entweder an Daten kommt, DDoS betreiben, Falsche Daten einschleusen kann, usw.
Ich rede hier wirklich von Sicherheitslücken in der Anwendung selbst und in der Klasse Sicherheitslücken sind Speicherfehler der mit Abstand größte Verursacher.
Du meinst, dass normale Bugs und Logikfehler Sicherheitsrisiken für den Benutzer bergen können wenn für ihn falsche Informationen geliefert werden. Das ist aber völlig unabhängig von der genutzen Programmiersprache ob nun C, Rust, Java oder auch gar Bash oder PHP.
flaphoschi schrieb:
PS: Ich bin leider jemand der über die Qualität unserer Software im allgemeinen unzufrieden ist. Und mein Gefühl sagt mir, Entwicklungszyklen sind zur kurz. Testen - vor allem das manuelle durchtesten - kommt zu kurz.
Definitiv gehört sowohl dem funktionalen Testen als auch dem Testen von Sicherheitslücken (z.B. Fuzzing) meines Erachtens wesentlich mehr Zeit eingeräumt.
Ja? Der Differenzierung zu “normalen” Fehlern kann ich nicht folgen. Ein Fehler ist entweder sicherheitkritisch oder nicht.
Angriffsfläche habe wir in allen Programmiersprache, weil es Programmierfehler sind.
Bildhaft:
Sonst sind wir bei “Aber ich hatte doch einen Virenscanner…” und der berüchtigten Checkliste, nach der angeblich alles sicher ist.
// edit
Das mit dem Bremer Onlineportal ist ein klasse Beispiel. Vielleicht technisch kein Programmierfehler, aber die Software ist in der komplexen Form zur Grundlage eines Sicherheitsproblems geworden. Weil niemand mehr getestet hat, sind kritische Hinweise verschwunden.
Das mit dem einstellbaren Ladelimit fürs Deck finde ich sehr gut.
Vermutlich dann auch andere SteamOS Geräte, in Plasma selbst kann man das schon eine Weile einstellen, zumindest auf ThinkPads.
