BSD für Desktop auf alter, alter HW gesucht

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.

Ich hab wirklich viel mit alternativen Browsern, mit und ohne alle möglichen funktionen rumprobiert, eher so um 2020 rum als ich meine ganz heiße alles-opensource-schlank-sonstwas phase hatte, mir auch mal irgendwann das PinePhone geholt hatte usw.

In der Praxis war das, was funktioniert hat, für mich viel zu dünn und dafür hat man einen absurden aufwand getrieben usw.

In den 6 Jahren seit dem sind die entwicklungen eher noch weiter eingeschlafen.

Wenn der anspruch sehr niedrig ist mag das ein oder andere funktionieren - ich stell mir mehr vor.

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.

Jupps, es gab ja auch wirklich einige teilweise auch sehr engagierte Versuche die letzten 15 Jahre - alle erfolglos
 
Selbst HTML plus CSS ohne JavaScript wäre zu wenig. Alle mit React laufenden Seiten (das sind teilweise schon simple Blogs) brauchen bereits JavaScript.
Das das keine Sache ist, die sich von jetzt auf gleich umsetzen lässt, ist klar.
Und idealerweise gibt es die Trennung auch im Standard. Dann würden sich die Frameworks, Webseitenbetreiebr usw. auch eher darauf einstellen (können).
Klar hätte man das idealerweise schon viel früher machen sollen, denn jetzt ins Ökosystem und in die Software einzugreifen ist natürlich schwierg.

Aber genau das war ja mein Vorwurf. Das man es schon viel zu lange und sehenden Auges hat auf die jetzige Situation zulaufen lassen.

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.
Genau deshalb wäre ja eine Auftrennung in reinen Viewer und Runtime für WebApps ja so wichtig. Dann ist zumindest für den Viewer-Part es realistisch, das es weitere Engines gibt. Denn die Monopolisierung wie wir sie jetzt bei Chromium beobachten ist ja definitiv nicht gut. Da treten ähnliche Phänomene auf wie bei vorherigen Browser-Dominanzen (z.B.: InternetExplorer) auch auf.

Blockiert man JavaScript komplett, ist ein ebenso großer wie bedeutender Teil des World Wide Web nicht mehr nutzbar.
Ja. Möglicherweise macht es ja auch Sinn ein klein wenig Javascript zuzulassen. Das müsste man sich dann überlegen. Ideal wäre ein Sub-Javascript welches nicht turing-complete ist und auch keine potentiell bösen Operationen darf.

Ich glaube nicht an eine leichte Trennung.
Da man die Browser ja eh auf eine moderne Basis stellen sollte, wäre das eine gute Gelegenheit. Oder zumindest auf modernes C++

Wie auch immer:
Die jetzige Situation ist sehr unbefriedigend und ich sehe auch nicht, wie man da ohne radikalen Schritte raus kommt.
Ansonsten ist es vermutlich nur noch eine Frage der Zeit, wann Schlimmeres passiert.
Komplexer/Anfälliger Browser + weitreichende Marktdurchdringung sind halt eine explosive Mischung.
 
Wie auch immer:
Die jetzige Situation ist sehr unbefriedigend und ich sehe auch nicht, wie man da ohne radikalen Schritte raus kommt.
Ansonsten ist es vermutlich nur noch eine Frage der Zeit, wann Schlimmeres passiert.
Komplexer/Anfälliger Browser + weitreichende Marktdurchdringung sind halt eine explosive Mischung.

Ich glaube wir sind alle dabei das die Situation sehr unbefriedigend ist und wir uns alle coole schlanke Browser / Web wünschen.

Tatsächlich sehe ich bei der Browser/Webfrage nicht ein einziges aktives, ausreichend großes Projekt, Firma oä das auch nur realistisch in 10-15 Jahren in irgend einer weise verbessert.

Also kann ich nur akut schauen was ich aus dem Elend am besten machen kann - das sind aktuell Firefox & Chromium basierte Browser die ich ggf. noch mit Plugins oder externen Tools anreichern kann.

Über dinge, wo es nicht mal einen Ansatz gibt das sie sich global in einer Dekade gibt verbessern, mir mega den Kopf zu zerbrechen lohnt sich nicht so richtig. Oder jemanden empfehlen xyz zu nutzen weil villeicht in 15, 20 Jahren mal irgendwas kommt ;)

Zurzeit gibt es mit iOS/iPadOS Geräten sogar global eine reletiv große relevante Geräte und Userbasis die nicht mal zwischen verschiedenen Browserengines wechseln können sondern ausschließlich verpflichtend sich das Safari-Elend antun müssen - ja man kann "andere Browser" installieren, aber auch die müssen die Appleengine verwenden - was das angeht eines der geschlossensten Systeme überhaupt.
 
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.
Wobei Ladybirds Versuch mit Swift als C++-Ersatz auch ... mutig war. Die Kehrtwende kam schnell und nun portieren sie mit Hilfe von LLMs auf Rust. Mal schauen, was das wird. TIch finde Ladybird eigentlich ein interessantes Projekt, da es zumindest nicht von Anfang an zum Scheitern verurteilt ist und was daraus werden könnte.
 
Wobei Ladybirds Versuch mit Swift als C++-Ersatz auch ... mutig war. Die Kehrtwende kam schnell und nun portieren sie mit Hilfe von LLMs auf Rust. Mal schauen, was das wird. TIch finde Ladybird eigentlich ein interessantes Projekt, da es zumindest nicht von Anfang an zum Scheitern verurteilt ist und was daraus werden könnte.

Ja, den überseh ich gerne weil ich den mit diesem einen Firefox-Fork (LibreWolf meine ich) verwechsel, sind ja beides Tiere in den Bezeichnungen :D

Das ist tatsächlich ein Projekt das Hoffnung bringt.
 
Tatsächlich sehe ich bei der Browser/Webfrage nicht ein einziges aktives, ausreichend großes Projekt, Firma oä das auch nur realistisch in 10-15 Jahren in irgend einer weise verbessert.
Ja. Das sehe ich genauso. Das müssten halt auch die Branchengrößen was ändern wollen.
Die haben aber vermutlich eher kein Interesse daran.

Über dinge, wo es nicht mal einen Ansatz gibt das sie sich global in einer Dekade gibt verbessern, mir mega den Kopf zu zerbrechen lohnt sich nicht so richtig.
Ja. Das kann man so sehen. :-)
Ich wollte das nur eben mal adressieren. Weil der vorhergehende Beitrag ein bisschen so klang wie "Naja. Die armen Browserhersteller wie Google habens ja auch nicht einfach. Was sollen die machen?"
Und dann wollte ich lediglich darauf hinweisen, das die die Problematik ja auch selbst verschuldet haben.

aber auch die müssen die Appleengine verwenden - was das angeht eines der geschlossensten Systeme überhaupt.
Ja. Wobei das auch durchaus was Gutes hat. Ohne dem wäre Google mit Chromium der einzige, der den Takt vorgeben kann.

und nun portieren sie mit Hilfe von LLMs auf Rust
Als ergänzenden Link dazu:

Das ist tatsächlich ein Projekt das Hoffnung bringt.
Mal gucken. Also ich finde Ladybird auch sehr nett. Allerdings löst der ja nicht das grundsätzliche Problem. Nämlich das die ganzen Web-Standards viel zu umfangreich sind und damit automatisch Komplexität nachsich ziehen.
Nichtsdesotrotz wäre es natürlich wichtig mehr Diversität bei den Browser-Enginges zu haben.
 
Man sollte auch nicht vergessen, dass ein aktueller Browser die Webstandards einhalten könnte/sollte/müsste.
Und die waren um 2020 rum schon recht üppig - 1200 Dateien mit 114 Millionen Wörtern, siehe meinen Post von 2023 dazu [1];
Ich gehe davon aus, dass das noch mehr geworden sein wird in den letzten 3 (6) Jahren.
Da schüttelt auch eine Firma nicht mal schnell eben mit full-time Devs eine neue, passende Engine ausm Karton.

[1] https://www.bsdforen.de/threads/browser-der-reddit-bzw-stackexchange-öffnen-kann.36955/post-335624
 
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.
Endlich mal auch eine Erklärung die auch Sinn macht! Ich hab so ein HD+ Stick, da kann ich auhc alles sehen. Und zur Not habe ich ja auch mein tripl-boot, also diesen Lapp, mit Antix und Arch, dort geht alles.
 
Der Exotenstatus hilft oftmals nur bedingt, wie auch schon so manches Unternehmen rausgefunden hat, das ein BSD einsetzt.
ein Kritikpunkt von/auf vez.mrsk.me war ja, dass sich FreeBSD-pf so weit von OpenBSD-pf entfernt hatte, dass die beiden so gut wie nie wieder zusamengeführt werden können:

dazu kann man sagen: es gab in der Vergangenheit regen Austausch unter den Maintainern und mittlerweile sind sie wieder nahezu auf dem selben Stand [1], (von manchen Eigenheiten jeweils in Open- und Free- abgesehen), das alles wurde gesponsort von NetGate [2]; scheinbar hatte die Firma ein Interesse daran, dass das wieder zusammengeführt wird

[1] https://forums.freebsd.org/threads/pf-in-freebsd-15-0-is-getting-on-par-with-openbsd.99241/

[2] https://www.netgate.com/blog/updates-to-the-pf-packet-filter-in-freebsd-and-pfsense-software
 
Zurück
Oben