Der Ur-Bootloader sind ca. 2kByte ARM-Assembler-Code, fest eingebrannt in die GPU. Ich kann die Menschen die das entwickeln müssen verstehen, wenn sie *ausschließlich für das Laden des eigentlichen Bootloaders* ein simples Dateisystem wie FAT benutzen, das ja erwiesermaßen in ein paar kByte Assembler implementiert werden kann.
Das heißt also, dass Microsoft aufgrund seiner FAT-Patente an jedem verkauften Raspberry Pi irgendwie mitverdient.
Das bedeutet zudem, dass ein Nutzer, wenn der vom Raspberry booten möchte, erst eine FAT-Lizenz benötigt, um von diesem booten zu dürfen. Wie jeder weiß, ist diese bei einem ganz normalen Linux nicht mit dabei.
Deshalb ist die naheliegende Frage, ob diese FAT-Lizenzgebühren schon vom Hersteller oder von in der Produktionskette befindlichen Herstellern (z.B. vom Hersteller der GPU) an Microsoft bezahlt worden sind. Ansonsten kann man nicht mehr empfehlen, den Raspberry Pi einzusetzen. In einigen Staaten dieser Welt droht selbst nicht kommerziell agierenden Privatleuten ein Patentverletzungsverfahren (glücklicherweise noch nicht in Deutschland).
Rein "freiheitsphilosophisch" betrachtet ist ein System, das zwingend eine FAT-Partition zum Booten benötigt, ohnehin ein "No-Go". Schlimm, dass es einen PC Welt-Artikel braucht, um diese Information zu erhalten. Jetzt wissen die Kritiker hier auch, für was eine nicht expertenmäßige Sicht der Dinge gut sein kann, zumal das FAT-Problem im alltäglichen Gebrauch des Raspberry Pi irgendwann einmal auftreten muss. Ich schließe daraus, dass keiner der Kommentatoren hier tiefgehende Erfahrung mit dem Raspberry hat bzw. diese FAT-Geschichte aus IMO falsch verstandener Begeisterung schlichtweg "überlesen" wollte.
In diesem Sinne, ganz im Ernst: Danke Pro-Linux, danke PC-Welt. Das Lesen solcher Artikel ist demzufolge von größten Nutzen, auch für fortgeschritten(er)e Linux-Nutzer.
Die Alternative wäre übrigens gewesen, *gar kein Dateisystem* zu unterstützen, sondern den Bootloader einfach stumpf ab Sektor 0 der SD-Card einzulesen. So machen das andere Embedded-Systeme. Das wäre aber weitaus weniger praktisch, weil man immer ein Spezialprogramm benötigt, um das passende Image auf die SD-Karte zu schreiben.
Also von der Firmware aus gesehen.
Der Ur-Bootloader sind ca. 2kByte ARM-Assembler-Code, fest eingebrannt in die GPU. Ich kann die Menschen die das entwickeln müssen verstehen, wenn sie *ausschließlich für das Laden des eigentlichen Bootloaders* ein simples Dateisystem wie FAT benutzen, das ja erwiesermaßen in ein paar kByte Assembler implementiert werden kann.
Das heißt also, dass Microsoft aufgrund seiner FAT-Patente an jedem verkauften Raspberry Pi irgendwie mitverdient.
Das bedeutet zudem, dass ein Nutzer, wenn der vom Raspberry booten möchte, erst eine FAT-Lizenz benötigt, um von diesem booten zu dürfen. Wie jeder weiß, ist diese bei einem ganz normalen Linux nicht mit dabei.
Deshalb ist die naheliegende Frage, ob diese FAT-Lizenzgebühren schon vom Hersteller oder von in der Produktionskette befindlichen Herstellern (z.B. vom Hersteller der GPU) an Microsoft bezahlt worden sind. Ansonsten kann man nicht mehr empfehlen, den Raspberry Pi einzusetzen. In einigen Staaten dieser Welt droht selbst nicht kommerziell agierenden Privatleuten ein Patentverletzungsverfahren (glücklicherweise noch nicht in Deutschland).
Rein "freiheitsphilosophisch" betrachtet ist ein System, das zwingend eine FAT-Partition zum Booten benötigt, ohnehin ein "No-Go". Schlimm, dass es einen PC Welt-Artikel braucht, um diese Information zu erhalten. Jetzt wissen die Kritiker hier auch, für was eine nicht expertenmäßige Sicht der Dinge gut sein kann, zumal das FAT-Problem im alltäglichen Gebrauch des Raspberry Pi irgendwann einmal auftreten muss. Ich schließe daraus, dass keiner der Kommentatoren hier tiefgehende Erfahrung mit dem Raspberry hat bzw. diese FAT-Geschichte aus IMO falsch verstandener Begeisterung schlichtweg "überlesen" wollte.
In diesem Sinne, ganz im Ernst: Danke Pro-Linux, danke PC-Welt. Das Lesen solcher Artikel ist demzufolge von größten Nutzen, auch für fortgeschritten(er)e Linux-Nutzer.
Die Alternative wäre übrigens gewesen, *gar kein Dateisystem* zu unterstützen, sondern den Bootloader einfach stumpf ab Sektor 0 der SD-Card einzulesen. So machen das andere Embedded-Systeme. Das wäre aber weitaus weniger praktisch, weil man immer ein Spezialprogramm benötigt, um das passende Image auf die SD-Karte zu schreiben.