Coding Style ist eine Vereinbarung zwischen Entwicklern wie Code auszusehen hat. Das Betrifft Einrückungen, Aussehen von Variablen- und Funktionsnamen, Zeilenumbrüche und vieles andere. Manches kann der Autoformater einer IDE erledigen, aber auch nicht alles. Trotzdem muss der Entwickler mit dem Coding Style leben können.
Zum Style gehöhren aber auch z.B. die Schreibweise von Funktionen, Variablen und co. Dies kann man auch nicht per IDE einfach einstellen.
Ich finde es nur sehr schade, dass die FSF sich hier eher zu einer Redner Versammlung entwickelt obwohl dies eigentlich nicht der Sinn und Zweck der FSF war. Leider muss man auch sagen, dass GNU als OS so oder so uninteressant wird. Auch wenn ich ein absolut freies OS toll finden würde, so bezweifle ich dass es sowas in den nächsten Jahren geben wird.
Solange die Hardware noch unfreie Firmware benötigt, was aktuell der Fall für sämtliche Hardware ist, ist es auch nich möglich ein freies System zu entwickeln. Deshalb hat GNU keine wirkliche Chance.
Linux geht hier den richtigen Weg. Die Firmware kann hier unfrei sein aber die Traiber und co. sollten frei sein wenn diese in den Kernel wandern wollen. Binäre Treiber sind hier auch okay und werden auch von den Anbietern der Hardware zur Verfügung gestellt.
Hier wird GNU weiterhin im Abseits stehen. Traurig aber leider Fakt.
Solange die Hardware noch unfreie Firmware benötigt, was aktuell der Fall für sämtliche Hardware ist, ist es auch nich möglich ein freies System zu entwickeln.
Es gibt genug absolut freie Distributionen, wie z. B. Trisquel, siehe auch http://www.gnu.org/distros/free-distros.html. Auch Debian (ohne non-free) ist 100% frei.
Dass sämtliche Hardware unfreie Firmware benötigt ist schlicht falsch. Man muss manchmal explizit schauen, aber die meiste Hardware die ich in den letzten 3 Jahren benutzt habe (ca. ein Dutzend Notebooks/PCs und ca. 40 Server) liefen mit 100% freier Software.
Zuerst mal springst du in deinem letzten Absatz von "unfreier Firmware" zu "freier Software". Was ist jetzt dein Gegenargument? Firmware oder Software? Und nein, das ist hier nicht das Selbe.
Dann glaube ich dir nicht, dass du mit deinen 40 Servern nicht eine Platte dabei hattest, die keine proprietäre Firmware nutzte. Lass nur eine Seagate dabei sein und du bist schon nicht mehr bei 100% frei, wenn du es so werten möchtest wie die HURD Macher.
AFAIK wirst du selbst mit dem xf86-video-intel Treiber nicht davor verschont das ein oder andere, nur intern bekannte Intel-Blob zu verwenden.
Lass nur eine Seagate dabei sein und du bist schon nicht mehr bei 100% frei, wenn du es so werten möchtest wie die HURD Macher.
RMS hat keine Probleme damit proprietäre Firmware bei Komponenten zu dulden, wenn nicht vorgesehen ist, dass diese vom Benutzer selbst verändert bzw. aktualisiert werden soll/kann. Als Beispiel hat er mal die Firmware seiner Mikrowelle gebracht.
Was den Intel-Treiber betrifft:
Da liegst du komplett daneben, da Intel der einzige Grafiktreiber ist der auf den von der FSF als frei zertifizierten Distributionen ohne Nachhilfe läuft. Und das heißt automatisch, dass weder im Kernel noch im Grafiktreiber Binary-Blobs vorkommen.
dass diese vom Benutzer selbst verändert bzw. aktualisiert werden soll/kann
Ist es nicht bei der meisten Hardware eben der Fall, dass ich diese updaten können soll, wenn der Anbieter ein Update bereit stellt? Oder beziehst du dich nicht nur auf den manuellen Updatevorgang durch den Nutzer, sondern auch auf die direkte Veränderbarkeit der Firmware durch den Nutzer?
Was den Intel Grafiktreiber betrifft, habe ich mal in einer langen Grafiktreiber Diskussion gelesen, dass eben dieser genannte nicht so komplett frei sein soll, wie so oft behauptet. War das mal anders, oder sind es einfach nur Blobs die durch Intel aber sauber spezifiziert sind und deshalb von der FSF abgesegnet wurden?
EDIT: Ich versuche gerade zu beiden Punkten etwas per Google zu finden, werde aber nicht auf Anhieb fündig. Hast du ein paar Links für mich Suchfaulen?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Dez 2012 um 19:10.
"RMS hat keine Probleme damit proprietäre Firmware bei Komponenten zu dulden, wenn nicht vorgesehen ist, dass diese vom Benutzer selbst verändert bzw. aktualisiert werden soll/kann. Als Beispiel hat er mal die Firmware seiner Mikrowelle gebracht."
Das stört Stallman also nicht? Und wenn man dieselbe Firmware mit genau der gleichen Funktionalität gewissermaßen in Software gießt und dann der Linux-Community als Kernel-Firmware zur Verfügung stellt, dann werden plötzlich Kernel und Co. unfrei? Absolut hirnrissig.
Von Progressor am Fr, 28. Dezember 2012 um 21:40 #
Das Problem ist, dass ein Computer im Gegensatz zur Mikrowelle keine Maschine ist, sondern eine Metamaschine. D.h., man kann z.B. mit einem Wordprozessor eine bessere Schreibmaschine nachahmen. Oder einen MP3-Player mit einem Abspielprogramm.
Von ---------- am Fr, 28. Dezember 2012 um 22:39 #
Darum geht es hier nicht wirklich.
Im einen Fall wird ein Rechner benutzt, der unfreie Firmware von einem Chip lädt, der als Hardware in ebendiesem Rechner verbaut ist. Das ist für die FSF zur Zeit o.k., das System kann so "FSF-frei" bleiben.
Im anderen Fall wird praktisch derselbe Rechner benutzt, nur wird dieses Mal die unfreie Firmware als "reine Software-Firmware" im Kernel zur Verfügung gestellt, der betreffende Hardwarechip konnte so eingespart werden. Nun ist das Linuxsystem plötzlich unfrei.
Die unfreie Firmware übt in beiden Fällen die gleiche Funktionalität aus. In Hardware gegossen wird diese von der FSF geduldet, in Software gegossen aber nicht.
In Wahrheit sind beide Systeme unfrei. Wäre das die gängige Doktrin, so dürften FSF-Mitstreiter in Zukunft größte Schwierigkeiten haben, ein wirklich freies System benutzen zu können, mangels freier Hardwarekomponenten.
Von ---------- am Sa, 29. Dezember 2012 um 21:42 #
Es geht hier wirklich nur um die jeweils gleiche Firmware, die in beiden Fällen zur Laufzeit geladen wird. Genau dann gibt es keinen Unterschied. "Freier" oder "unfreier" ist hier gar nichts.
Was ich damit meine, ist, dass die FSF Ihr Hauptziel bisher gar nicht erreicht hat und das Gros der GNU/Linux-Nutzer dieses sehr wahrscheinlich auch niemals hundertprozentig erreichen wird.
Das liegt aber an der FSF selbst, weil diese sich auch unbedingt an solchen Spitzfindigkeiten festbeißen muss.
Freiheit kann hier nur heißen, sämtliche unfreie Firmware wegzulassen, in Hardware, aus der diese zur Laufzeit geladen wird, genauso wie in Software.
Und das mit den Verbundstoffen ist ein eher unzutreffendes Beispiel, da die Prinzipien der jeweiligen chemischen Reaktionen samt den Ausgangsprodukten bekannt sind und jedermann zum Studium und zur Betätigung zur Verfügung stehen. D.h, Du kannst Dir einen sehr ähnlichen Werkstoff synthetisieren, wobei es eher egal ist, ob er die haargenau gleichen Eigenschaften aufweist wie der unter Verschluss gehaltene irgendeines Unternehmens. Das verhält sich eher wie beim berühmten Cola-Rezept: Das Cola-Produzieren an sich ist für andere nicht verboten.
Nein es gibt keine "freien" Distributionen. Warum sollte etwas freie Hardware sein nur weil es seine Firmware selber laden kann? Und warum ist etwas unfreie Hardware weil ein Treiber den Binär Blob erst in die Hardware laden muss?
Eine ähnlich lächerliche Diskussion gab es doch auch beim Raspberri Pi. Der OS abhängige teil ist OpenSource und die Firmware ist ein Blob. Pikant ist aber, dass die Firmware auch die OpenGL ES Implementierung enthält etc.
Von BetreuerKeinerProjekte am Fr, 28. Dezember 2012 um 12:54 #
Hässlich sind sie beide. Nur ist C einfach flexibler, weil es einen ABI-Standard gibt, was es selbst in C++ einfacher macht, eine kompiliertes Plugin einzubinden, wenn es in C geschrieben ist. Das ist vermutlich der Grund, warum viele Interpreter und Plugin-Schnittstellen noch mit C realisiert werden.
Außerdem gibt es da noch die Fülle an Ungereimtheiten. http://yosefk.com/c++fqa/ Über C kann man sowas allerdings sicherlich auch schreiben.
grep und sed sind eh fertig.
Coding style kann ja jeder seinen eigene Voliebe in der IDE einstellen, oder geht das etwa mit GNU Emacs nicht?
Coding Style ist eine Vereinbarung zwischen Entwicklern wie Code auszusehen hat. Das Betrifft Einrückungen, Aussehen von Variablen- und Funktionsnamen, Zeilenumbrüche und vieles andere. Manches kann der Autoformater einer IDE erledigen, aber auch nicht alles. Trotzdem muss der Entwickler mit dem Coding Style leben können.
Zum Style gehöhren aber auch z.B. die Schreibweise von Funktionen, Variablen und co.
Dies kann man auch nicht per IDE einfach einstellen.
Ich finde es nur sehr schade, dass die FSF sich hier eher zu einer Redner Versammlung entwickelt obwohl dies eigentlich nicht der Sinn und Zweck der FSF war.
Leider muss man auch sagen, dass GNU als OS so oder so uninteressant wird.
Auch wenn ich ein absolut freies OS toll finden würde, so bezweifle ich dass es sowas in den nächsten Jahren geben wird.
Solange die Hardware noch unfreie Firmware benötigt, was aktuell der Fall für sämtliche Hardware ist, ist es auch nich möglich ein freies System zu entwickeln.
Deshalb hat GNU keine wirkliche Chance.
Linux geht hier den richtigen Weg.
Die Firmware kann hier unfrei sein aber die Traiber und co. sollten frei sein wenn diese in den Kernel wandern wollen.
Binäre Treiber sind hier auch okay und werden auch von den Anbietern der Hardware zur Verfügung gestellt.
Hier wird GNU weiterhin im Abseits stehen.
Traurig aber leider Fakt.
Es gibt genug absolut freie Distributionen, wie z. B. Trisquel, siehe auch http://www.gnu.org/distros/free-distros.html. Auch Debian (ohne non-free) ist 100% frei.
Dass sämtliche Hardware unfreie Firmware benötigt ist schlicht falsch. Man muss manchmal explizit schauen, aber die meiste Hardware die ich in den letzten 3 Jahren benutzt habe (ca. ein Dutzend Notebooks/PCs und ca. 40 Server) liefen mit 100% freier Software.
Zuerst mal springst du in deinem letzten Absatz von "unfreier Firmware" zu "freier Software". Was ist jetzt dein Gegenargument? Firmware oder Software? Und nein, das ist hier nicht das Selbe.
Dann glaube ich dir nicht, dass du mit deinen 40 Servern nicht eine Platte dabei hattest, die keine proprietäre Firmware nutzte. Lass nur eine Seagate dabei sein und du bist schon nicht mehr bei 100% frei, wenn du es so werten möchtest wie die HURD Macher.
AFAIK wirst du selbst mit dem xf86-video-intel Treiber nicht davor verschont das ein oder andere, nur intern bekannte Intel-Blob zu verwenden.
Was den Intel-Treiber betrifft:
Da liegst du komplett daneben, da Intel der einzige Grafiktreiber ist der auf den von der FSF als frei zertifizierten Distributionen ohne Nachhilfe läuft. Und das heißt automatisch, dass weder im Kernel noch im Grafiktreiber Binary-Blobs vorkommen.
Was den Intel Grafiktreiber betrifft, habe ich mal in einer langen Grafiktreiber Diskussion gelesen, dass eben dieser genannte nicht so komplett frei sein soll, wie so oft behauptet. War das mal anders, oder sind es einfach nur Blobs die durch Intel aber sauber spezifiziert sind und deshalb von der FSF abgesegnet wurden?
EDIT: Ich versuche gerade zu beiden Punkten etwas per Google zu finden, werde aber nicht auf Anhieb fündig. Hast du ein paar Links für mich Suchfaulen?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Dez 2012 um 19:10."RMS hat keine Probleme damit proprietäre Firmware bei Komponenten zu dulden, wenn nicht vorgesehen ist, dass diese vom Benutzer selbst verändert bzw. aktualisiert werden soll/kann. Als Beispiel hat er mal die Firmware seiner Mikrowelle gebracht."
Das stört Stallman also nicht?
Und wenn man dieselbe Firmware mit genau der gleichen Funktionalität gewissermaßen in Software gießt und dann der Linux-Community als Kernel-Firmware zur Verfügung stellt, dann werden plötzlich Kernel und Co. unfrei?
Absolut hirnrissig.
Das Problem ist, dass ein Computer im Gegensatz zur Mikrowelle keine Maschine ist, sondern eine Metamaschine.
D.h., man kann z.B. mit einem Wordprozessor eine bessere Schreibmaschine nachahmen. Oder einen MP3-Player mit einem Abspielprogramm.
Darum geht es hier nicht wirklich.
Im einen Fall wird ein Rechner benutzt, der unfreie Firmware von einem Chip lädt, der als Hardware in ebendiesem Rechner verbaut ist.
Das ist für die FSF zur Zeit o.k., das System kann so "FSF-frei" bleiben.
Im anderen Fall wird praktisch derselbe Rechner benutzt, nur wird dieses Mal die unfreie Firmware als "reine Software-Firmware" im Kernel zur Verfügung gestellt, der betreffende Hardwarechip konnte so eingespart werden. Nun ist das Linuxsystem plötzlich unfrei.
Die unfreie Firmware übt in beiden Fällen die gleiche Funktionalität aus. In Hardware gegossen wird diese von der FSF geduldet, in Software gegossen aber nicht.
In Wahrheit sind beide Systeme unfrei. Wäre das die gängige Doktrin, so dürften FSF-Mitstreiter in Zukunft größte Schwierigkeiten haben, ein wirklich freies System benutzen zu können, mangels freier Hardwarekomponenten.
Tja, da hast du Recht, hier ist die FSF wirklich inkonsequent.
Hier sollten schon die Rezepturen der benötigten Verbundsstoffe frei sein.
Es geht hier wirklich nur um die jeweils gleiche Firmware, die in beiden Fällen zur Laufzeit geladen wird. Genau dann gibt es keinen Unterschied. "Freier" oder "unfreier" ist hier gar nichts.
Was ich damit meine, ist, dass die FSF Ihr Hauptziel bisher gar nicht erreicht hat und das Gros der GNU/Linux-Nutzer dieses sehr wahrscheinlich auch niemals hundertprozentig erreichen wird.
Das liegt aber an der FSF selbst, weil diese sich auch unbedingt an solchen Spitzfindigkeiten festbeißen muss.
Freiheit kann hier nur heißen, sämtliche unfreie Firmware wegzulassen, in Hardware, aus der diese zur Laufzeit geladen wird, genauso wie in Software.
Und das mit den Verbundstoffen ist ein eher unzutreffendes Beispiel, da die Prinzipien der jeweiligen chemischen Reaktionen samt den Ausgangsprodukten bekannt sind und jedermann zum Studium und zur Betätigung zur Verfügung stehen. D.h, Du kannst Dir einen sehr ähnlichen Werkstoff synthetisieren, wobei es eher egal ist, ob er die haargenau gleichen Eigenschaften aufweist wie der unter Verschluss gehaltene irgendeines Unternehmens. Das verhält sich eher wie beim berühmten Cola-Rezept: Das Cola-Produzieren an sich ist für andere nicht verboten.
Nein es gibt keine "freien" Distributionen. Warum sollte etwas freie Hardware sein nur weil es seine Firmware selber laden kann? Und warum ist etwas unfreie Hardware weil ein Treiber den Binär Blob erst in die Hardware laden muss?
Eine ähnlich lächerliche Diskussion gab es doch auch beim Raspberri Pi. Der OS abhängige teil ist OpenSource und die Firmware ist ein Blob. Pikant ist aber, dass die Firmware auch die OpenGL ES Implementierung enthält etc.
Hässlich sind sie beide.
Nur ist C einfach flexibler, weil es einen ABI-Standard gibt, was es selbst in C++ einfacher macht, eine kompiliertes Plugin einzubinden, wenn es in C geschrieben ist.
Das ist vermutlich der Grund, warum viele Interpreter und Plugin-Schnittstellen noch mit C realisiert werden.
Außerdem gibt es da noch die Fülle an Ungereimtheiten.
http://yosefk.com/c++fqa/
Über C kann man sowas allerdings sicherlich auch schreiben.