Kinoite hab ich privat bei Familie/Freunde im Einsatz, wenn sie wenig technikaffin sind. Kann ich nur empfehlen.
BSD für Desktop auf alter, alter HW gesucht
- Ersteller medV2
- Erstellt am
Kinoite hab ich privat bei Familie/Freunde im Einsatz, wenn sie wenig technikaffin sind. Kann ich nur empfehlen.
Wenn es um möglichst breite Hardware-Unterstützung und Flexibilität geht, würde ich NetBSD in den Raum werfen. Das Projekt verfolgt ja schon lange das Motto „Of course it runs NetBSD“ – und genau das merkt man auch: Es läuft auf erstaunlich vielen Plattformen und bleibt dabei konsistent und schlank. Gerade für experimentelle oder ältere Systeme finde ich das ziemlich überzeugend.
NetBSD ist aber schon sehr betreuungsintensiv und weit von den Auto-Updates entfernt, die medV2 für seinen Anwendungsfall benötigt.
Zusätzlich ist es aktuell hochgradig fahrlässig, mit NetBSD im World Wide Web zu browsen. NetBSD hat es seit über zwei Wochen nicht geschafft, die aktuelle Firefox-Version 149.0.2 mit 47 Security-Fixes (davon 6 mit high severity) zum Laufen zu bringen.
Ich kann die NetBSD-Entwickler verstehen. Firefox verwendet Rust, dessen Toolchain kaum mehr auf 32-bit-Systemen läuft und viele obskure Systeme kaum bis gar nicht unterstützt. Das auf allen NetBSD-unterstützen Plattformen zum Laufen zu bringen ist jedes Mal viel Aufwand.
Bei Chromium sieht es unwesentlich besser aus; auch da sind selbst bei Zero-Day-Exploits die Wartezeiten auf die jeweils neue Version teilweise obszön lang.
Mangels sicherer nutzbarer Browser-Versionen disqualifiziert sich NetBSD damit aber leider völlig für den normalen Desktop-Betrieb.
midnight
OpenBSD & FreeBSD
Wuerde vermutlich schon reichen, die LTS-Version anzubieten und dann zu patchen. Das sollte vermutlich weniger Aufwand sein.
Tatsächlich hängt NetBSD leider bei moderner Hardware von allen BSDs insgesamt am meisten hinterher und auch der Support von älterer AMD64-Hardware der 2010er aber auch teilweise ARM-Sachen usw siehts nicht immer besser aus.
Dazu ist es auf älterer Hardware performancetechnisch vermutlich irgendwo so zwischen OpenBSD und FreeBSD einzuschätzen - vermutlich wird man also mit dem Wald-und-Wiesen Linux oder zumindest FreeBSD in vielen (nicht in allen) fällen mit älterer Hardware da etwas mehr freude haben, es geht ja im Desktop letztlich darum wie schnell das OS dann schwergewichte wie Firefox ausführen kann und nicht wie viele ressourcen der Kernel oder das Init-System verbraucht. Natürlich kann man alle BSDs trotzdem oft verwenden, und es gibt gute gründe das zu tun, aber "NetBSD ist ein guter Deal um aus älterer Hardware die beste Performance im Firefox, Chromium, Libreoffice oä rauszukitzeln" ist halt faktisch nicht haltbar.
Der Bereich, in dem NetBSD noch dem Anspruch gerecht wird besonders viele und breit Hardware zu unterstützen ist inzwischen leider sehr schmal geworden.
Und selbst wenn wir von 90er-Jahre Plattformen wie Alpha usw reden sind die oft nicht oder erst sehr viel später nach neueren Releases funktionsfähig, Alpha z.B. ist (Ich verfolge da die Liste da ich noch ne nicht mehr funktionsfähige Maschine hab) in einen sehr schlechten Zustand AFAIK dtl. schlechter als unter OpenBSD.
Zu den Sicherheitsproblemen usw haben die vorposter schon sehr treffend was geschrieben. Auch wenn das garnicht so der Kernfokus ist, ist OpenBSD da inzwischen im Gegensatz z.B. sehr ordentlich und Firefox und Chromium Pakete sind nur selten merklich später als unter Archlinux oder Debian da.
oenone
OpenBSD veteran
Ich reaktiviere gerade meine alten Biester und musste leider feststellen, dass 32-bit Sparc nur noch von NetBSD unterstützt wird und bei Sparc64 ist das wohl auch fast das einzige lauffähige Betriebssystem (mein geliebtes OpenBSD kommt da nicht mit der Grafik zurecht und Gentoo Linux will ich mir nicht antun). Naja, Zeit etwas Neues zu lernen - produktiv einsetzen werde ich die eh nicht.
Ich bin seit FreeBSD 11 eigentlich komplett bei FreeBSD unterwegs, habe aber damals auf einem Raspberry Pi 3 und einem älteren No-Name-Laptop auch NetBSD ausprobiert.
Was mir dabei wirklich positiv aufgefallen ist, war die Netzwerkeinrichtung und generell, wie rund und effizient sich das System angefühlt hat – gerade auf eher schwacher oder ungewöhnlicher Hardware. Auch pkgsrc fand ich ziemlich angenehm, gerade was Portabilität angeht.
Klar, das ist inzwischen ein paar Jahre her, und ich würde auch zustimmen, dass NetBSD bei moderner Hardware und klassischem Desktop-Usecase (Firefox, Chromium, LibreOffice usw.) nicht unbedingt die erste Wahl ist. Da ist man mit FreeBSD oder auch Linux oft besser aufgestellt.
Aber gerade für experimentelle Setups oder spezielle Hardware hatte NetBSD für mich definitiv seine Stärken.
Was mir dabei wirklich positiv aufgefallen ist, war die Netzwerkeinrichtung und generell, wie rund und effizient sich das System angefühlt hat – gerade auf eher schwacher oder ungewöhnlicher Hardware. Auch pkgsrc fand ich ziemlich angenehm, gerade was Portabilität angeht.
Klar, das ist inzwischen ein paar Jahre her, und ich würde auch zustimmen, dass NetBSD bei moderner Hardware und klassischem Desktop-Usecase (Firefox, Chromium, LibreOffice usw.) nicht unbedingt die erste Wahl ist. Da ist man mit FreeBSD oder auch Linux oft besser aufgestellt.
Aber gerade für experimentelle Setups oder spezielle Hardware hatte NetBSD für mich definitiv seine Stärken.
Trotzdem war es um FreeBSD/sparc64 schade. Ich verstehe voll und ganz, dass man es nicht mehr weiter pflegen wollte und vielleicht mangels ausreichend potenter Hardware auch nicht mehr konnte, aber SPARC war durch seine strikten Anforderungen an Memory Alignement gut darin subtile Bugs zu finden. Außerdem war es eine echte Big Endian Plattform, davon mindestens eine zu haben ist auch nicht verkehrt.
cabriofahrer
Well-Known Member
Ist ein Verzug von zwei Wochen da wirklich so ein Weltuntergang, um NetBSD völlig für den normalen Desktop-Betrieb zu disqualifizieren? Wie sieht es denn mit den Firefox-Versionen für Windows aus? Abgesehen davon, dass der normale Windows-User wahrscheinlich auch nicht jeden Tag als aller Erstes seine Firefox-Version aktualisiert. Und ich selbst z.B., führe unter FreeBSD auch nur alle paar Wochen ein
pkg upgrade aus.Aha, dann ist das also der Grund, warum es auf einer 32-bit Version von NetBSD gar kein Firefox gibt oder nur eine sehr veraltete esr-Version?
Was für Browser-Alternativen hätte man denn da für ein 32-bit NetBSD?
Ja, Browser sind die Angriffsziele schlecht hin, je nach Lücke kann sich überall Schadcode verbergen, selbst zB in der Kommentarspalte der renomierten Newsseite.
Was den Windowsuser betrifft: Firefox hält sich da automatisch Up-to-Date, also ja, der Windowsuser hat immer die aktuellste Version.
Das ist zB einer der Gründe, eshalb ich den Firefox aus den Flatpaks beziehe. Das kann ich wirklich täglich (oder mehrmals täglich) auf Updates überprüfen und einspielen. Ja geht mit den Systempaketquellen auch, aber da kommt oft mehr mit, als ich updaten möchte.
bluebyte
Herrscher über ~/.running-fein
Wäre interessant gewesen. Ob Firefox aus den Flatpak unter FreeBSD zum Beispiel auch Netflix oder Amazon Prime wiedergeben könnte. Denn unter FreeBSD bekommt man immer die Meldung, dass die Version nicht Aktuell wäre. Dabei hab ich die 150.0 installiert. Denke mal nicht, dass es dann an der geforderten 150.0.1 liegt, die es unter Windows gibt.
Andy_m4
Well-Known Member
Spontan würde ich sagen: Nein.
Denn Flatpak benutzt macht ja u.a. auch Sandbox und die Techniken die dafür verwendet werden, sind Linux-spzifisch und werden vermutlich vom Linuxulator nicht supportet (das Handbuch geht ja auch so ein bisschen auf die Thematik ein).
bluebyte
Herrscher über ~/.running-fein
Hätte ja echt sein können, denn es heißt ja, dass Flatpak überall auf jeder Distri läuft. Da die Programme, die darauf laufen, eigene Bibliotheken mitbringen. Mein Gedanke war eben nur, dass Flatpak selbst genug Bibliotheken in der Linuxbase, die man installiert, vorfindet um zu laufen.
Andy_m4
Well-Known Member
Bei einer Linux-Distribution ist es ja i.d.R. auch kein Problem. Nur bei Non-Linux-Systemen sieht es schwieriger aus.
Im Zweifel käme es auf einen Versuch an.
Und den Notausgang den man natürlich immer hat, ist ein virtualisiertes Linux zu benutzen. Ist aber natürlich nicht besonders schön.
Sofern du mit der Kiste im WWW unterwegs bist, ist das grob fahrlässig, wie medV2 schon korrekt angemerkt hat.
Einer von vielen. Der Hauptgrund ist der Umstand, dass man einen zeitgenössischen Browser gar nicht mehr im Adressraum von 32 bit bauen kann, weil der Linker mehr als 4 GB RAM braucht (und diese Begrenzung lässt sich auch mit viel Swap nicht umgehen).
Es gibt keine.
Alle drei großen Engines (Blink (Chromium), WebKit (Safari) und Gecko (Firefox)) brauchen inzwischen 64 bit.
Es gibt noch ein paar Exoten, aber mit denen ist das zeitgenössische World Wide Web praktisch unbenutzbar.
Der Exotenstatus hilft oftmals nur bedingt, wie auch schon so manches Unternehmen rausgefunden hat, das ein BSD einsetzt.
Browser-Engines sind extrem komplexe, historisch gewachsene Monster aus viel C++, die selbst auf extrem performanter Hardware Stunden zum Kompilieren brauchen. Ein Wunder, dass da irgendwas funktioniert.
Aus gutem Grunde baut Gecko immer mehr auf Rust, ebenso wie der Newcomer Ladybird, der seine Sicherheitsprobleme noch weniger in den Griff bekommt und deswegen jetzt auch auf Rust setzt. Servo hat gleich auf Rust gestartet, ist aber noch lange nicht reif für den Produktionseinsatz.
Falls du aber eine Alternative kennst, die moderne Webstandards unterstützt und sicher(er) ist, wir sind ganz Ohr.
Andy_m4
Well-Known Member
Ja eben.
Meine Kritik ist eher, das die etablierten Browserhersteller es total versemmelt haben (und das da auch teilweise Absicht hinter steht). Und das auch abseits der Implementierung.
Es ist nämlich ohnehin schon doof eine so exponierte Software wie einen Browser so komplex zu machen. Und ja, mir ist klar, das viele der Features vor allem deshalb eingebaut worden sind, um sowas wie WebApps zu ermöglichen.
Ich hätte das Ganze vernünftigerweise schon längst aufgespalten. In einen Light-Teil der im Wesentlichen dafür da ist, Webseiten anzuzeigen und dafür auch einfach implementierbar und dementsprechend robust baubar ist, das man selbst in den dreckigen Ecken des Internets nicht Gefahr läuft sich so leicht was einzufangen.
Nebenbei wird damit auch der Markt für Browser geöffnet, denn einen Light-Standard zu implementieren ist bei weitem nicht so aufwendig wie den vollständigen HTML/Javascript/CSS-Kram.
Für WebApps kann man dann eine fullfeatured-Engine haben (also das was wir jetzt für alles haben).
Die Situation/Problematik die wir jetzt haben ist das Ergebnis geschäftspolitischer Entscheidungen. Nicht zuletzt auch von Google die den featurebloat ganz wesentlich vorangetrieben haben. Da fällt es mir schwer irgendwie Mitleid aufzubringen.
Gefährliches Halbwissen: Soviel ich weiß braucht (!) jeder offizielle, nicht ÖR Streamingdienst wie Netflix, Prime und Co, selbst für die schlechteste Qualität, inzwischen DRM, genaugenommen im Browser dieses elendige Widevine-DRM-Zeugs.
DRM gibt es dann aber in verschiedenen "Tiers" - je höher das Tier, deste bessere Auflösung kann man bekommen.
Ab bestimmten auflösungen muss die gesamte toolchain stimmen, also auch der Monitor-Ausgang und der Monitor selbst das dann können. Soweit ich weiß gibt es das dann nur für Windows, Android, MacOS, iOS/iPadOS und einigen Set-Top-Boxen ala FireTV, AppleTV und Spiele-Konsolen, bei den komplett geschlossenen Systemen (Android, iOS, Spiele-Konsolen) dann auch nicht übern browser sondern nur den individuellen Apps der Plattformen
Da nützt dann entsprechend auch keine VM - AFAIK gibt es zeugs was drumherumbastelt aber da ist man dann eher bei wirklich illegalen kram unterwegs.
Unter Linux ist die best mögliche legale toolchain am einfachsten verfügbar in dem man den offiziellen chrome (nicht chromium) installiert (kann man ja ggf. auch nur dafür nutzen). Damit kriegt man aber AFAIK auch nur maximal die mittlere mögliche Qualität.
Deshalb fahr ich jetzt beim Streaming dreigleisig - am Windows in voller auflösung mit dem Edge (Nur dafür verwendet), am Linux-Fernseh-PC mit dem Chrome in mittlerer Qualität und wenn ich am Fernseher mal die volle Qualität möchte mit so einem komischen FireTV Stick von Amazon.
Generell kann "exot" gerade bei so Browsern auch einfahc nur bedeuten "Riesige Sicherheitslücken, werden sogar ausgenutzt, aber keiner bermerkts weil die nicht im fokus sind".
Volle zustimmung, die beste Lösung für mich momentan: Einen aktuellen Firefox, einen aktuellen Chromium parallel um inhalte, themen und vektoren ein bisschen zu trennen, das bisschen mehr ram verbrauch durch das öffnen von 2 (oder drei siehe oben) Browsern parallel ist ja komplett zu vernachlässigen.
Aber um "irgendetwas" auf einen aktuellen Firefox oder Chrome basiertes kommt man (abseits von Safari unter den Applefans) nicht herum.
Firefox bietet übrigens noch 32bit Windows-Builds an, die wenigen 32bit Linux-Distries dies noch gibt bieten den glaub ich cross-compiled an - aber imho sollte man kein 32bit Desktop* mehr fahren, AMD64 ist nun 23 Jahre alt und damit bereits deutlich (!) länger auf dem Markt als die Zeit zwischen i386 einführung und einführung von AMD64. Und mal ehrlich: So gut wie keiner von eucht weint deutlich neueren Architekturen hinterher wie das furchtbare Itanium oder Alpha, nur mit dem i386 habt ihrs irgendwie ...
*/edit gibt ja durchaus noch Einsatzzwecke für i386 Hardware die nicht so absurd ist)
Zuletzt bearbeitet:
Ich glaube nicht an eine leichte Trennung. Ein Refactoring von Blink erscheint mit meinen oberflächlichen Kenntnissen der Codebasis schon fast wie ein Ding der Unmöglichkeit, zumal C++ Refactoring auch sehr schlecht unterstützt (verglichen z.B. mit Java).
Selbst HTML plus CSS ohne JavaScript wäre zu wenig. Alle mit React laufenden Seiten (das sind teilweise schon simple Blogs) brauchen bereits JavaScript.
Ich habe einen JavaScript-Blocker mit selektiver Freischaltung im Einsatz. Blockiert man JavaScript komplett, ist ein ebenso großer wie bedeutender Teil des World Wide Web nicht mehr nutzbar.
Mit Google und Konsorten habe ich auch kein Mitleid. Das Problem haben ja hauptsächlich wir am Ende der Nahrungskette, weil wir wenig Alternativen haben und die Entwicklung einer neuen Browser-Engine ein Fass ohne Boden ist, das selbst von einer Horde engagierter Entwickler in deren Freizeit kaum zu stemmen ist.