News GNU Linux-Libre („Etoosixy“): Linux 6.0 in Reinform steht zum Download bereit

[SVΞN]

Auf die Veröffentlichung von Linux 6.0 folgt nur wenige Stunden später der davon abgewandelte und vollständig freie Systemkernel GNU Linux-Libre in der Version 6.0, der ausschließlich auf freie und quelloffene Software setzt. „Libre“ verzichtet auf Pakete, die nicht als Quelltext vorliegen oder proprietäre Lizenzen nutzen.

Zur News: GNU Linux-Libre („Etoosixy“): Linux 6.0 in Reinform steht zum Download bereit

 

[Termy]

Es ist nur eine Schande, dass essentielle Dinge wie 3D-Beschleunigung nur mit Blobs funktionieren, selbst bei AMD oder Intel...

 

[Spike S.]

@Termy Danke, genau das wollte ich gerade erfragen 👍

 

[Termy]

Wirkliche Infos dazu findet man ja auch schwer, habe grade auch versucht herauszufinden, ob sich daran schon was geaendert hat - wuerde mich zwar wundern, aber zu wuenschen waere es ja auf jeden Fall

Aber ich glaube unsre groesste Chance auf ein wirklich freies System, welches ohne grosse Einschraenkungen als Daily Driver taugt wird RISC-V un die damit/dafuer entwickelten Chips inkl GPUs sein. Wenn die Hersteller denn weiter so offen wie bisher bleiben...
(Und natuerlich ist das eher eine Hoffnung fuer in 5-10 Jahren...)

 

[SVΞN]

Aber ich glaube unsre groesste Chance auf ein wirklich freies System, welches ohne grosse Einschraenkungen als Daily Driver taugt wird RISC-V un die damit/dafuer entwickelten Chips inkl GPUs sein.

Ich glaube, viele Hoffnungen [auch meine] ruhen da auf RISC-V. Ich bin da ganz bei dir.

Ich hoffe, das Thema nimmt weiter an Fahrt auf.

 

[Piktogramm]

RISC-V Spielverderber: Die ISA ist zwar offen, die einzelnen Designs müssen es aber nicht sein und die Bootloader auch nicht. Da gibt es zwar im Rahmen der RISC-V Foundation Interessengruppen, die den Bootloader einheitlich halten wollen, aber das ist halt freiwillig.

Es ist leider auch nicht zu erwarten, dass es voll offene RISC-V Plattformen geben wird, die auch nur annähernd aktuelle Leistungserwartungen erfüllen können. Als FOSS Projekt kommt man realistisch an 90nm Prozesse ran und da auch nur in Form von shared Wafern und kleinen Dies. 45nm bis runter zu 28nm sind mit Kontakten möglich, aber darunter wird es teuer. Naja und bei den aktuellen, kleineren Nodes sind mir derzeit keine FOSS Bibliotheken für die Synthese des physischen Chipdesigns bekannt, da gibt es also (derzeit) auch Grenzen der Offenheit,

 

[Termy]

Es ist leider auch nicht zu erwarten, dass es voll offene RISC-V Plattformen geben wird, die auch nur annähernd aktuelle Leistungserwartungen erfüllen können.

Als Gaming-Maschine sicher nicht, nein.
Aber auch mit 28 oder 45nm sind auf jeden Fall PCs moeglich, die aktuelle Leistungserwartungen fuers Surfen, Office-Work, Bilder verwalten und was sonst so auf Privat-PCs abseits von Gaming passiert erfuellen koennen.
Und grade dabei waere mir ein vertrauenswuerdiges System am wichtigsten, da wuerde ich dann ohne mit der Wimper zu zucken einen extra Rechner fuers Gaming vorhalten

 

[andy_m4]

Es ist nur eine Schande, dass essentielle Dinge wie 3D-Beschleunigung nur mit Blobs funktionieren, selbst bei AMD oder Intel...

In der Tat. Intel und AMD werden ja gerne mal für ihre Open-Source-Treiber gelobt während nvidia immer als die Bösen galten mit ihrem Binärtreiber.
Die Wahrheit ist aber, das vieles was früher in Treibern steckte halt heute in der Firmware steckt und die ist closed. Von daher finde ich diese Lobgesänge immer nicht ganz passend wenngleich die Situation natürlich trotzdem besser ist als mit proprietären Treibern.

Es ist leider auch nicht zu erwarten, dass es voll offene RISC-V Plattformen geben wird, die auch nur annähernd aktuelle Leistungserwartungen erfüllen können. Als FOSS Projekt kommt man realistisch an 90nm Prozesse ran und da auch nur in Form von shared Wafern und kleinen Dies.

Ganz so schwarz würde ich es nicht sehen. Wir haben ja an Projekten wie dem Raspberry Pi gesehen das sich da durchaus was entwickeln kann. Und warum sollte es sowas dann auf RISC IV-Basis nicht möglich sein.

Aber auch aus der Industrie heraus können sich ja durchaus Standards entwickeln. Auch das wäre ja jetzt nix Neues und das haben wir auch in vielen Bereichen weils halt eben auch kommerziell Vorteile hat.
Bisher hat man das vielleicht nur deshalb nicht gemacht, weil da viele Firmen Geld reinstecken müssen und wenn die dann am Ende doch von einer Firma abhängig sind dann scheuen die das eher. Bei RISC IV hast Du das Problem nicht in dem Maße.

Ich strotze da auch nicht vor Optimismus aber ich würde es halt auch nicht zuuu negativ sehen.

 

[SCP-067]

Es gibt ja schon brauchbare echte freie Treiber. Zugegeben für etwas „veraltete“ GPU Generationen.
Allerdings entwickeln sich die Web Standards oder auch Codecs so schnell weiter, dass die ganze Arbeit daran dann gefühlt gleich wieder für die Katz ist. 😞😒

 

[Termy]

Die Wahrheit ist aber, das vieles was früher in Treibern steckte halt heute in der Firmware steckt und die ist closed. Von daher finde ich diese Lobgesänge immer nicht ganz passend wenngleich die Situation natürlich trotzdem besser ist als mit proprietären Treibern.

Naja, im Vergleich zu Nvidias neuem 'offenem' Treiber steckt bei AMD ja nur ein winziger Bruchteil im Blob
Und auch mit dem Blob-Part hat man ja immer noch den Vorteil, dass der Treiber Mainline ist - von dem her ist das Lob aus praktischen Gesichtspunkten durchaus nicht ungerechtfertigt.

 

[Piktogramm]

@Termy
Der BCM2711 SoC vom RaspberryPi 4 ist in 28nm gefertigt und wenn man beim Energiebedarf freizügiger ist, kommt man da bei SoC raus, die dem Niveau von Intely IvyBridge entsprechen. Das ist unter dem Niveau aktueller 250€ Smartphones. IvyBridge habe ich dieses Jahr bei mir entsorgt, weil das Ding einfach überfordert war, wenn es Thunderbird, Browser und eine IDE mit einem kleinerem Projekt zu berechnen war.

Also klar, ein DevBoard mit Risc-V für 200€ in 28nm mit halbwegs Fähigkeiten würde ich auch nehmen. Aber eben als Devboard.

Ganz so schwarz würde ich es nicht sehen. Wir haben ja an Projekten wie dem Raspberry Pi gesehen das sich da durchaus was entwickeln kann. Und warum sollte es sowas dann auf RISC IV-Basis nicht möglich sein.
[...]
Bisher hat man das vielleicht nur deshalb nicht gemacht, weil da viele Firmen Geld reinstecken müssen und wenn die dann am Ende doch von einer Firma abhängig sind dann scheuen die das eher. Bei RISC IV hast Du das Problem nicht in dem Maße.

Ich strotze da auch nicht vor Optimismus aber ich würde es halt auch nicht zuuu negativ sehen.

Gerade der Bootprozess und die Fülle an notwendigen Binärblobs der Raspis sind gar nicht mal so offen. Da wurde/wird dran gearbeitet, aber bei den aktuellen Broadcom SoCs ist nicht zu erwarten, dass sie einem Bootprozess durchlaufen werden, der zu anderen ARM SoCs vergleichbar/kompatibel ist. Die Initialisieren den ganzen SoC ja immer noch über ihre GPU -.-

Naja und ich sehe es halt echt negativ. Gerade bei den ganzen embeded Buden gibt es massiv Wildwuchs. Was da an FUD gegenüber (F)OSS Lizensen krassiert und gleichzeitig dem Wunsch möglichst die gesamte Software unter eigener Kontrolle zu halten ist absurd.
SiFive gibt sich da zwar Mühe, dagegen zu arbeiten und alles halbwegs offen zu halten, aber die bieten ja meist auch nur Softcores und ihre Kunden können das noch ausreichend verkacken

 

[andy_m4]

Und auch mit dem Blob-Part hat man ja immer noch den Vorteil, dass der Treiber Mainline ist - von dem her ist das Lob aus praktischen Gesichtspunkten durchaus nicht ungerechtfertigt.

Ja. Das Lob ist nicht unberechtigt. Aber aus reiner Open-Source-Sicht ist das natürlich eigentlich zu wenig.
Denn die reine Bequemlichkeit hast Du im Grunde auch bei nvidia. Selbst wenn mal ein neuer Kernel kommt ist es i.d.R. damit getan das das Kernelmodul neu kompiliert werden muss (was man nicht mal selbst anstoßen, sondern via DKMS automatisch gemacht wird).

Der eigentliche Punch bei Open-Source ist ja, das jeder den Quelltext einsehen und modifizieren kann. Was z.B. auch dazu führt das Bugs von Dritten gefixt werden können oder es Contributions für neue Funktionen gibt usw.
Das hast Du alles nicht wenn die Software closed ist.

Gerade der Bootprozess und die Fülle an notwendigen Binärblobs der Raspis sind gar nicht mal so offen. Da wurde/wird dran gearbeitet, aber bei den aktuellen Broadcom SoCs ist nicht zu erwarten, dass sie einem Bootprozess durchlaufen werden

Da hast Du völlig Recht. Ich würde jetzt den Raspberry Pi auch sicher nicht als Paradebeispiel sehen wie sowas aussehen kann. Aber richtungsmäßig haut das schon ungefähr hin. Und warum sollte es dann nicht weiter in die Richtung gehen.

Naja und ich sehe es halt echt negativ. Gerade bei den ganzen embeded Buden gibt es massiv Wildwuchs. Was da an FUD gegenüber (F)OSS Lizensen krassiert und gleichzeitig dem Wunsch möglichst die gesamte Software unter eigener Kontrolle zu halten ist absurd.

Ja. Aber das hatten wir bei den großen Computern früher auch. Auch hier gabs ein anderes denken aber das hat sich trotzdem über die Zeit gewandelt.
Ich sag ja auch nicht, das wir nächstes Jahr einen RISC IV Rechner haben der so ist, wie wir uns das hier gerade ausmalen. Aber so in 5-10 Jahren sieht die Welt sicher anders aus.

 

[garfield121]

... ist aber einmal mehr um zahlreiche der neu hinzugekommenen Treiber und Firmware bereinigt worden

Macht für mich keinen Sinn, ich würde eine pragmatische Sicht der Dinge bevorzugen.

 

[Piktogramm]

@andy_m4
Bei den großen Rechnern hat es sich auch nur geändert, weil es eine x86 Monokultur unter dem Diktat von Intel gab. PowerPC weicht ab[1], ARM hatte und hat einen gigantischen Wildwuchs.

Ich würde es mir auch wünschen, dass die bestehenden Lösungen weiterentwickelt werden. Es gibt ja für RISC-V extra OpenSBI und im Zusammenspiel damit lauffähige Implementierungen U-Boot und Coreboot. Wie gut sowas ignoriert wird, sehen wir ja bei ARM

[1] wurde mit OpenPower wohl besser

Edit: Link https://crvf2019.github.io/pdf/43.pdf

 

[Termy]

Macht für mich keinen Sinn, ich würde eine pragmatische Sicht der Dinge bevorzugen.

Linux Mainline ist ja sehr viel pragmatischer, Libre ist wirklich nur fuer knallharte Idealisten wirklich "alltagstauglich"...

 

[andy_m4]

Libre ist wirklich nur fuer knallharte Idealisten wirklich "alltagstauglich"...

Macht für mich keinen Sinn, ich würde eine pragmatische Sicht der Dinge bevorzugen.

Das kann auch eine pragmatische Sicht der Dinge sein. Solche Sachen werden ja gerne in eine ideologische Ecke geschoben so nach dem Motto: Da will jemand die reine Lehre der reine Lehrens willen.

Es gibt aber auch praktische Gründe dafür. Nehmen wir mal an Du hast eine Firma und Du willst irgendwie ein Produkt machen und Linux (um mal bei dem Beispiel zu bleiben) kommt Dir da ganz gut zu pass.
Das große Problem bei unfreier Software ist ja vor allem, was Du viele Dinge nicht darfst oder sogar Ärger kriegst wenn Du die einsetzt. Wir hatten jetzt erst kürzlich das Beispiel mit Fedora und den Codecs.

Wenn Du ein komplett freies Projekt einsetzt und als Basis nimmst, dann weißt Du halt das Dir von der Seite keiner an den Karren ranfahren kann. Du weißt, das da gewisse Mindeststandards eingehalten werden von dem was Du darfst und kannst das in Rahmen dessen halt nutzen ohne irgendwas befürchten zu müssen.


Es gibt also durchaus pragmatische Gründe sowas einzusetzen, auch wenn sie jetzt vielleicht nicht Deinen Belangen entsprechen.

 

[0x7c9aa894]

Und grade dabei waere mir ein vertrauenswuerdiges System am wichtigsten,

Und wie willst du das machen? Man müßte die vollständige Kette von
Software - Compiler - Hardware Design - EDA Software - Chip Produktion
kontrollieren. Ich glaube nicht, daß das möglich ist.

 

[Termy]

Und wie willst du das machen? Man müßte die vollständige Kette von
Software - Compiler - Hardware Design - EDA Software - Chip Produktion
kontrollieren. Ich glaube nicht, daß das möglich ist.

Die Produktion wird schwer, ja - davon abgesehen waere alles auch offen machbar und schon heute zum Grossteil praktikabel. Was primaer fehlt ist der Businesscase, damit eine Firma ihr RISC-V-Design offen legt und dokumentiert bzw sich eine Foundation findet und genug Firmen genug investieren, um der offenen ISA auch noch offene konkrete Designs folgen zu lassen.
Und da muss selbst ich als FOSS-Verfechter sagen, dass es mir schwer faellt, da rein kapitalistisch allzu viel Chancen zu sehen. FOSS macht in meinen Augen auch fuer Firmen absolut Sinn, dass es funktioniert zeigen ja auch genug Beispiele, bei denen die Firmen trotz FOSS Geld mit ihrer Software verdienen und gleichzeitig Arbeit sparen, weil sie auf bestehender Software aufbauen koennen.
Da bei IC-Fertigung die Schwelle deutlich hoeher ist wird das gleiche Konzept da (meiner Laien-Meinung nach) eher schwer Fuss fassen koennen und wir muessen hoffen, dass es aus idealistischen Gruenden gemacht wird. Natuerlich lasse ich mich nur zu gerne vom Gegenteil ueberzeugen

 

[0x7c9aa894]

Was primaer fehlt ist der Businesscase, damit eine Firma ihr RISC-V-Design offen legt und dokumentiert bzw sich eine Foundation findet und genug Firmen genug investieren, um der offenen ISA auch noch offene konkrete Designs folgen zu lassen.

Dab es schon mal, und keinen hat es gejuckt. OpenSpark: https://www.oracle.com/servers/technologies/opensparc-t1-page.html

Edit: Nun die ESA hat damals einen "Space-Processor" daraus gebaut, also fürs All.

Schau dir mal Opencores.org an. Also CPUs gibt es genügend.

 

[SCP-067]

Wollte die EU nicht Fördergelder für Firmen die in RISC V investieren springen lassen?
Unter der Voraussetzung dass es offengelegt wird.

Bin da leider nicht am Ball geblieben, aber aufgegeben wurde das glaube ich noch nicht.