gehört Chromium nach non-free?
gehört Chromium nach non-free?
Hallo,
ich wurde auf Bug-Report 787527 aufmerksam gemacht, der, falls er (noch) zutrifft bedeuten würde, dass chromium eigentlich nach non-free gehört. Der Report ist mit der Schwere "serious" eingestuft, wäre also Release-Critical - mMn als Policy-Violation zurecht.
Aus historischen Gründen ist dieser Report allerdings gegen chromium-browser gerichtet, was in Wheezy ein Übergangspaket war und seit Jessie nicht mehr existiert. Daher taucht der Report nicht als Chromium-Bug auf.
Ich denke nun über ein Re-Assignment des Bugs an chromium nach, würde vorher aber prüfen wollen, ob das Problem mit den fehlenden Quellen immer noch besteht. Weiß da jemand mehr und kann mir etwas Recherche ersparen?
Edit:
Da ich ja immer so auf Querverweisen zu Crosspostings rumreite, hier [1] bekam ich den Hinweis. Ich trete dort als "sulu" auf.
[1] https://pyra-handheld.com/boards/thread ... st-1405495
ich wurde auf Bug-Report 787527 aufmerksam gemacht, der, falls er (noch) zutrifft bedeuten würde, dass chromium eigentlich nach non-free gehört. Der Report ist mit der Schwere "serious" eingestuft, wäre also Release-Critical - mMn als Policy-Violation zurecht.
Aus historischen Gründen ist dieser Report allerdings gegen chromium-browser gerichtet, was in Wheezy ein Übergangspaket war und seit Jessie nicht mehr existiert. Daher taucht der Report nicht als Chromium-Bug auf.
Ich denke nun über ein Re-Assignment des Bugs an chromium nach, würde vorher aber prüfen wollen, ob das Problem mit den fehlenden Quellen immer noch besteht. Weiß da jemand mehr und kann mir etwas Recherche ersparen?
Edit:
Da ich ja immer so auf Querverweisen zu Crosspostings rumreite, hier [1] bekam ich den Hinweis. Ich trete dort als "sulu" auf.
[1] https://pyra-handheld.com/boards/thread ... st-1405495
- novalix
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: gehört Chromium nach non-free?
1. Ich habe keine Ahnung
2. Ich verstehe den Bug Report nicht
3. Sucht da tatsächlich jemand nach dem Quellcode von JavaScript-Dateien?
4. apt-file spuckt bei zwei Stichproben der Liste nix aus (stretch und sid auf amd64)
2. Ich verstehe den Bug Report nicht
3. Sucht da tatsächlich jemand nach dem Quellcode von JavaScript-Dateien?
4. apt-file spuckt bei zwei Stichproben der Liste nix aus (stretch und sid auf amd64)
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: gehört Chromium nach non-free?
Ich finde im Source orig.tar.xz 56.0.2924 (450MB, entpackt 2,5GB) jetzt nur die im bugreport angemerkten domdistiller*.novalix hat geschrieben: 3. Sucht da tatsächlich jemand nach dem Quellcode von JavaScript-Dateien?
Diese sind imo niemals zusammengeschrieben, also source-Code,
sondern generiert.
Somit fehlt deren Source.
Für andere *.js gilt wohl dasselbe.
*.so oder *.swf finden sich nicht mehr.
Aber
Code: Alles auswählen
# cat chromium-56.0.2924.76.filetype-split | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr" | wc -l
800
Was davon noch nach Anwendung des debian-Patcharchivs übrigbleibt?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: gehört Chromium nach non-free?
Von den Dateien die im Bugreport aufgelistet wurden sind noch diese 7 übrig:Wie von rendegast angemerkt enthalten die ersten sechs Dateien Code, der automatisch generiert aussieht (z.B. [1]). Wie kam der Code zustande und was macht der?
Das letzte jstemplate_compiled.js hat diesen Inhalt:Das hier erwähnte Include ist wieder so eine kryptische, nach automatischer Generierung aussehende Javascript-Codewüste.
Was macht man nun damit? Ist das wirklich Freie Software im Sinne der DFSG?
Anders gefragt: Kann sich einer der Javascript-Experten hier im Forum mit vertretbarem Aufwand einen Reim auf den "Code" machen?
[1] http://sources.debian.net/src/chromium- ... bundle.js/
Code: Alles auswählen
third_party/analytics/google-analytics-bundle.js
third_party/dom_distiller_js/dist/js/domdistiller_wrapped.js
third_party/dom_distiller_js/dist/js/domdistiller.js
third_party/web-animations-js/sources/web-animations.min.js
third_party/web-animations-js/sources/web-animations-next.min.js
third_party/web-animations-js/sources/web-animations-next-lite.min.js
ui/webui/resources/js/jstemplate_compiled.js
Das letzte jstemplate_compiled.js hat diesen Inhalt:
Code: Alles auswählen
// Copyright (c) 2012 The Chromium Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// This file serves as a proxy to bring the included js file from /third_party
// into its correct location under the resources directory tree, whence it is
// delivered via a chrome://resources URL. See ../webui_resources.grd.
<include src="../../../../third_party/jstemplate/jstemplate_compiled.js">
Was macht man nun damit? Ist das wirklich Freie Software im Sinne der DFSG?
Anders gefragt: Kann sich einer der Javascript-Experten hier im Forum mit vertretbarem Aufwand einen Reim auf den "Code" machen?
[1] http://sources.debian.net/src/chromium- ... bundle.js/
Re: gehört Chromium nach non-free?
Unwahrscheinlich.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: gehört Chromium nach non-free?
Alles:rendegast hat geschrieben:*.so oder *.swf finden sich nicht mehr.
Aberdarunter noch etliche *.exe und PE32, ELF-64/32, JVT NAL sequence und mp4 Mediendateien und weitere Bildchen, *.jar, einige *.dll und wohl auch nicht wenige 'file'-Fehlerkennungen.Code: Alles auswählen
# cat chromium-56.0.2924.76.filetype-split | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr" | wc -l 800
Was davon noch nach Anwendung des debian-Patcharchivs übrigbleibt?
Code: Alles auswählen
$ ls -ld /tmp/chromium-*55.0.2883.75
drwxr-xr-x 58 hikaru hikaru 1480 Dez 2 00:03 /tmp/chromium-55.0.2883.75 # tar entpackt ohne Patches
drwxr-xr-x 60 hikaru hikaru 1520 Feb 7 23:58 /tmp/chromium-browser-55.0.2883.75 # tar entpackt mit Patches (apt-get source)
$ find /tmp/chromium-55.0.2883.75 -exec file '{}' \; > /tmp/chromium-56.0.2924.76.filetype-split.1
$ find /tmp/chromium-browser-55.0.2883.75 -exec file '{}' \; > /tmp/chromium-56.0.2924.76.filetype-split.2
$ diff -u0 /tmp/chromium-56.0.2924.76.filetype-split.1 /tmp/chromium-56.0.2924.76.filetype-split.2 | egrep -v "ASCII text|Unicode text|PNG image data|XML document|SPEC$| text$|empty$|MS Windows icon|SVG Scalab|Ogg data|PDF docum|RIFF|HTML docum|data$|SQLite |XML 1.0 docu|ISO-8859 text|UTF-8 Unicode|Java serialization|symbolic link|MSVC progr|@@|directory"
--- chromium-56.0.2924.76.filetype-split.1 2017-02-07 23:45:59.391296003 +0100
+++ chromium-56.0.2924.76.filetype-split.2 2017-02-08 00:08:43.893206362 +0100
- novalix
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: gehört Chromium nach non-free?
Der Code, den Du verlinkt hast, ist "minified". Alle für die Maschine unnötigen Whitespaces und Zeilenumbrüche sind entfernt. Außerdem ist er wohl auch "uglyfied". Funktions- und Variablennamen sind verkürzt (mangled). Ansonsten ist das halt der Quellcode, prinzipiell[1] lesbar und veränderbar, wenn auch kaum verstehbar[2].
MIT und BSD-Style Lizenzen sind üblicherweise DFSG kompatibel.
[1] Dass es keine wirklich glückliche Grundlage für weitere Arbeit an dem Code ist, versteht sich. Üblicherweise gibt es in JavaScript-Projekten auch zwei Versionen einer Bibliothek im Repository: die Arbeitskopie und die verkleinerte, dazu ggf. noch ein Hinweis darüber, wie die verkleinerte erstellt werden kann.
[2] Es gibt auch Tools, die das verunstalten des Codes wieder rückgängig machen. Z.B. https://github.com/beautify-web/js-beautify
MIT und BSD-Style Lizenzen sind üblicherweise DFSG kompatibel.
[1] Dass es keine wirklich glückliche Grundlage für weitere Arbeit an dem Code ist, versteht sich. Üblicherweise gibt es in JavaScript-Projekten auch zwei Versionen einer Bibliothek im Repository: die Arbeitskopie und die verkleinerte, dazu ggf. noch ein Hinweis darüber, wie die verkleinerte erstellt werden kann.
[2] Es gibt auch Tools, die das verunstalten des Codes wieder rückgängig machen. Z.B. https://github.com/beautify-web/js-beautify
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: gehört Chromium nach non-free?
"Prinzipiell" kann ich auch Assembler- oder gar Byte-Code lesen und verändern, aber eben kaum verstehen. Warum sollte man da bei maschnell durchgewürgtem JS-Code andere Maßstäbe an den Quellcode ansetzen?novalix hat geschrieben:Ansonsten ist das halt der Quellcode, prinzipiell[1] lesbar und veränderbar, wenn auch kaum verstehbar[2].
Sowas funktioniert nur formal (Code-Formatierung), aber nicht inhaltlich (Kommentare,sinnvolle Variablennamen).novalix hat geschrieben:[2] Es gibt auch Tools, die das verunstalten des Codes wieder rückgängig machen. Z.B. https://github.com/beautify-web/js-beautify
Der dokumentierte Gedankengang des Originalautors lässt sich damit nicht wiederherstellen.
Re: gehört Chromium nach non-free?
Danke Jungs für eure Mühe um Open Oource! Ich verstehe leider nicht alles - aber es geht doch mittlerweile darum, dass
Chromium-Quelltexte teilweise nicht vorhanden bzw. absichtlich zurückgestutzt sind, dass deren Funktion keiner mehr verstehen kann oder besser soll?! Zurückstutzen von Quelltext (Varaiblennamen, Kommentare) ist ja völlig unnötig für die Maschine, die mit kompiliertem Maschinencode arbeitet - aber Zusatzaufwand der Coder mit dem Ziel des Unverständnisses derjenigen, die nicht im Besitz des ausführlichen Quelltextes sind. Nur um notgedrungen Opensource-Richtlinien zu erfüllen, sein "Zeuch" dort unterzubringen. Erfüllt doch (fast) den Tatbestand des Betruges - im Gegensatz zu Closed Sources. Richtig verstanden? Und wenn ich das lese, wird mir übel:
Sagt mal kurz zwischendurch was in einfachen Worten für Nichtprogrammierer, anndere sind auch am Thema interessiert.
Chromium-Quelltexte teilweise nicht vorhanden bzw. absichtlich zurückgestutzt sind, dass deren Funktion keiner mehr verstehen kann oder besser soll?! Zurückstutzen von Quelltext (Varaiblennamen, Kommentare) ist ja völlig unnötig für die Maschine, die mit kompiliertem Maschinencode arbeitet - aber Zusatzaufwand der Coder mit dem Ziel des Unverständnisses derjenigen, die nicht im Besitz des ausführlichen Quelltextes sind. Nur um notgedrungen Opensource-Richtlinien zu erfüllen, sein "Zeuch" dort unterzubringen. Erfüllt doch (fast) den Tatbestand des Betruges - im Gegensatz zu Closed Sources. Richtig verstanden? Und wenn ich das lese, wird mir übel:
Code: Alles auswählen
third_party/analytics/google-analytics-bundle.js
- novalix
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: gehört Chromium nach non-free?
Das Problem liegt in den Build-Systemen für JavaScript. Üblicherweise werden komplexere Projekte dadurch funktional optimiert. Einerseits um Bandbreite im Übertragungskanal zu sparen und andererseits um der Laufzeitumgebung einen optimierten AST für performantere Umsetzung anzubieten.
Beim hier diskutierten Beispiel findet man den Quellcode in diesem Repo: https://github.com/GoogleChrome/chrome- ... -analytics
Die Datei https://github.com/GoogleChrome/chrome- ... -bundle.js ist das Ergebnis des Build-Prozesses mittels Google Closure Compiler.
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Die Frage ist, ob Debian zusätzlich zu den jeweiligen gebündelten, optimierten Quellen noch die eigentlichen Quelldateien und die gesamte jeweilige Build-Chain mitliefern muss.
Dazu gibt es schon so einiges an Diskussion, z.B. 673727, 817092 und 830978.
Alles nicht so ganz einfach eindeutig zu beantworten, wie ich finde.
Hypothetisches Beispiel (hinkt gewaltig):
Du entwickelst eine quelloffene Anwendung in der Du das UI aufhübschst indem Du Mandelbrot-Mengen als Hintergrundbilder einbindest. Die png dafür stellst Du unter eine freie Lizenz und erstellst sie mit einer anderen Software auf Deinem Rechner. Weil Du Bock darauf hast, koppelst Du in Deiner Entwicklungsumgebung die Erstellung dieser png an die Commit Messages Deiner Bearbeitungen via git-hook o. ä.
So lange die Bilder unter einer freien Lizenz stehen, würde wohl keiner von Dir sinnvoll verlangen können, die Build-Chain der png offen zu legen und mit zu liefern.
NB: Die Frage, ob der Inhalt von Dateien verständlich ist oder nicht, ist ein eher kniffeliges Kriterium.
Eine .asm ist Quellcode, auch wenn sie kaum einer versteht. Dokumentation von Quellcode ist keine Voraussetzung, um diesen als frei zu kategorisieren.
Beim hier diskutierten Beispiel findet man den Quellcode in diesem Repo: https://github.com/GoogleChrome/chrome- ... -analytics
Die Datei https://github.com/GoogleChrome/chrome- ... -bundle.js ist das Ergebnis des Build-Prozesses mittels Google Closure Compiler.
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Die Frage ist, ob Debian zusätzlich zu den jeweiligen gebündelten, optimierten Quellen noch die eigentlichen Quelldateien und die gesamte jeweilige Build-Chain mitliefern muss.
Dazu gibt es schon so einiges an Diskussion, z.B. 673727, 817092 und 830978.
Alles nicht so ganz einfach eindeutig zu beantworten, wie ich finde.
Hypothetisches Beispiel (hinkt gewaltig):
Du entwickelst eine quelloffene Anwendung in der Du das UI aufhübschst indem Du Mandelbrot-Mengen als Hintergrundbilder einbindest. Die png dafür stellst Du unter eine freie Lizenz und erstellst sie mit einer anderen Software auf Deinem Rechner. Weil Du Bock darauf hast, koppelst Du in Deiner Entwicklungsumgebung die Erstellung dieser png an die Commit Messages Deiner Bearbeitungen via git-hook o. ä.
So lange die Bilder unter einer freien Lizenz stehen, würde wohl keiner von Dir sinnvoll verlangen können, die Build-Chain der png offen zu legen und mit zu liefern.
NB: Die Frage, ob der Inhalt von Dateien verständlich ist oder nicht, ist ein eher kniffeliges Kriterium.
Eine .asm ist Quellcode, auch wenn sie kaum einer versteht. Dokumentation von Quellcode ist keine Voraussetzung, um diesen als frei zu kategorisieren.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: gehört Chromium nach non-free?
Dagegen ist ja auch nichts einzuwenden, wenn es um die ausgeführten "Binaries" geht. Aber hier geht es doch um Quellcode. Und da hat minified JS mMn nichts zu suchen.novalix hat geschrieben:Das Problem liegt in den Build-Systemen für JavaScript. Üblicherweise werden komplexere Projekte dadurch funktional optimiert. Einerseits um Bandbreite im Übertragungskanal zu sparen und andererseits um der Laufzeitumgebung einen optimierten AST für performantere Umsetzung anzubieten.
Aber eben nur als vollständige Kette. Schneide ich den vorderen Teil ab, dann wird der Hintere mMn genauso DFSG-unfrei, wie ein compiliertes C-Programm zu dem ich den Quellcode nicht anbiete. Dass der eigentliche Quellcode nur bei Upstream und nicht bei Debian vorliegt erscheint mir nicht ok, sonst könnte Debian sein ganzes Quellarchiv einstampfen und nur noch auf Upstream verweisen, was hinsichtlich der Reproduzierbarkeit natürlich eine Katastrophe wäre.novalix hat geschrieben:Beim hier diskutierten Beispiel findet man den Quellcode in diesem Repo: https://github.com/GoogleChrome/chrome- ... -analytics
Die Datei https://github.com/GoogleChrome/chrome- ... -bundle.js ist das Ergebnis des Build-Prozesses mittels Google Closure Compiler.
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Ich finde hier 817092 und die ersten 50% (den Rest, der dann eher organisationsphilosophisch wird, habe ich noch nicht gelesen) von 830978 recht eindeutig kontra minified JS. Aus 673727 mag ich kein Fazit ziehen. Aber mein Eindruck mag nur Confirmation Bias sein.novalix hat geschrieben:Die Frage ist, ob Debian zusätzlich zu den jeweiligen gebündelten, optimierten Quellen noch die eigentlichen Quelldateien und die gesamte jeweilige Build-Chain mitliefern muss.
Dazu gibt es schon so einiges an Diskussion, z.B. 673727, 817092 und 830978.
Alles nicht so ganz einfach eindeutig zu beantworten, wie ich finde.
Stimmt! Aber offenbar gibt es ein formal besseres Kriterium das inhaltlich auf das Selbe hinausläuft:novalix hat geschrieben:NB: Die Frage, ob der Inhalt von Dateien verständlich ist oder nicht, ist ein eher kniffeliges Kriterium.
Eine .asm ist Quellcode, auch wenn sie kaum einer versteht. Dokumentation von Quellcode ist keine Voraussetzung, um diesen als frei zu kategorisieren.
In den von dir verlinkten Bugreports wird immer wieder erwähnt, dass Quellcode in Debian im von Upstream bevorzugten Format für Patches vorliegen soll(/muss?). Ohne es geprüft zu haben vermute ich, dass minified JS kein von Google bevorzugtes Format für Chromium-Patches ist.
- novalix
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: gehört Chromium nach non-free?
Irgendwo da liegt das Problem, ja.hikaru hat geschrieben:Aber eben nur als vollständige Kette. Schneide ich den vorderen Teil ab, dann wird der Hintere mMn genauso DFSG-unfrei, wie ein compiliertes C-Programm zu dem ich den Quellcode nicht anbiete. Dass der eigentliche Quellcode nur bei Upstream und nicht bei Debian vorliegt erscheint mir nicht ok, sonst könnte Debian sein ganzes Quellarchiv einstampfen und nur noch auf Upstream verweisen, was hinsichtlich der Reproduzierbarkeit natürlich eine Katastrophe wäre.novalix hat geschrieben:--snip--
Offensichtlich ist die gesamte Kette freie Software im Sinne der DFSG.
Zunächst mal ist es so, dass Linux-Distributionen wie Debian sehr stark auf dem Workflow von C bzw. C-artigen Sprachen aufsetzen. Die damit verbundenen Build-Systeme (Makefiles und so) einigermaßen in den Griff zu bekommen und zu warten/weiter entwickeln ist schon eine nicht zu kleine Aufgabe. Sukzessive drängen zusätzliche Programmiersprachen mit z.T. sehr unterschiedlichen Techniken der Distribution und Weiterverarbeitung in die Infrastruktur.
JavaScript, oder genauer ECMA-Script, ist in den letzten .ca 15 Jahren zu einer wirklich großen Plattform gereift, nicht zuletzt durch die Alimentation großer Entwicklergruppen durch Google, Mozilla, etc.
Debian hat zunächst einmal das rein praktische Problem, die so entstandene Infrastruktur in seine gewohnten Paketierungsprozesse zu integrieren. Man bräuchte eigentlich viel mehr Manpower, um mit der Entwicklung schritt zu halten. Das fängt aber eigentlich schon bei Plattformen wie Perl oder Python an, deren volle Möglichkeiten innerhalb der Paketinfrastruktur nur kompromissbehaftet genutzt werden können. Man hat einen Modus Vivendi gefunden.
Das die vorliegende Situation unbefriedigend ist und nicht das Ende der Fahnenstange sein darf, sehe ich auch. Allerdings ist der Vergleich mit kompilierten C-Code auch nicht richtig. Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Jetzt haben die Paketierungsbemühungen von JavaScript-Software bei Debian in den letzten Jahren schon deutliche Fortschritte gemacht (vor allen Dingen in der node.js Infrastruktur). Ich denke, dass sich diese Unklarheiten in den nächsten Jahren sukzessive auflösen können.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: gehört Chromium nach non-free?
Mit dieser Begründung erkläre ich ASM-Zwischencode zu "Quelldateien".novalix hat geschrieben:Allerdings ist der Vergleich mit kompilierten C-Code auch nicht richtig. Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Re: gehört Chromium nach non-free?
Cool, wusste gar nicht das Visual Studio, Lotus Notes und Maple OepenSource sind. Und wie sieht das aus mit MS Office, wenn ich das durch nen disasseblerer oder gar decompiler laufen lasse? Dann habe ich ja auch wieder C-Code. Ist das dann auch OpenSource?novalix hat geschrieben:Die gebündelten .js sehen scheiße aus und sind aus sich heraus kaum zu verstehen. Ich kann und darf sie aber zielgerichtet ändern, so dass der daraus generierte Byte-Code meinen Vorstellungen entspricht. Es sind Quelldateien.
Quatsch das Ding ist ganz einfach: Der Quellcode ist der Code in dem Ursprünglich (von Menschen) geschrieben wurde. (Deswegen steckt da auch Quelle drin.) PUNKT. Mit dem Datenformat hat das gar nichts zu tun. Und wenn man AWT nutzt ist der Quellcode entsprechend Java und das Compilat Javascript. Nutzt man dagegen Rhino ist der Quellcode JavaScript und das Compilat Java VM-Code.
Deswegen ist john Open source obwohl es da größtenteils nur Assembler gibt, und der Nvidia-Treiber aber nicht auch wenn man da genauso das Assembler bekommt.
Die Lesbarkeit ist da nur ein Anzeichen für: Minified JS oder gigabyteweise Assembler hat offensichtlich niemand von Hand geschrieben. Deswegen verlangt man da nach dem Sourcecode. Genauso unlesbares Perl könnte aber durchaus von Menschen geschrieben worden sein. Deswegen geht man da eher von Source-Code aus. (Das ändert sich sobald man generated by xyz im Header findet.) Bilder und co sind davon btw. ausgschlossen, weil es sich nur um (nicht ausgeführte und nicht interpretierte) Daten handelt. Da ist die grenze btw. aber deutlich schwammiger. (Guckt euch mal die Bugs in dekomressions libs an.)
rot: Moderator wanne spricht, default: User wanne spricht.
Re: gehört Chromium nach non-free?
Mal ein eher organisatorischer Einwurf:
Wie bereits erwähnt, wurde 787527 gegen chromium-browser gerichtet. Das Binärpaket heißt inzwischen chromium, weshalb der Bugreport dort nicht mehr auftaucht. [1] Allerdings taucht er nach wie vor bei chromium-browser auf. [2] Auch das Quellcode-Paket heißt nach wie vor chromium-browser. [3]
Ich würde den Report daher gern an chromium umleiten. Erzeugt aber eine Umleitung überhaupt irgendwo einen Eindruck der groß genug ist um vom Release-Team wahrgenommen zu werden oder verpufft das beim Paketbetreuer, der den Bug ja offenbar auch in den letzten 1,5 Jahren eher stiefmütterlich behandelt hat?
Die Alternative wäre, einen völlig neuen Bugreport gegen chromium zu richten und in diesem auf den ursprünglichen Bugreport zu verweisen. Die beiden würden dann natürlich von irgendwem zusammengeführt werden und würden in dem Zuge Aufmerksamkeit erzeugen. Zumindest würde zwischenzeitlich mal ein NEUER rc-Bug aufblitzen. Die Vorgehensweise wär natürlich konzeptuell hässlich, würde ich aber bevorzugen, falls es die Erfolgsaussichten auf eine erneute Beschäftigung damit erhöht.
[1] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[2] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[3] https://packages.debian.org/source/sid/chromium-browser
Wie bereits erwähnt, wurde 787527 gegen chromium-browser gerichtet. Das Binärpaket heißt inzwischen chromium, weshalb der Bugreport dort nicht mehr auftaucht. [1] Allerdings taucht er nach wie vor bei chromium-browser auf. [2] Auch das Quellcode-Paket heißt nach wie vor chromium-browser. [3]
Ich würde den Report daher gern an chromium umleiten. Erzeugt aber eine Umleitung überhaupt irgendwo einen Eindruck der groß genug ist um vom Release-Team wahrgenommen zu werden oder verpufft das beim Paketbetreuer, der den Bug ja offenbar auch in den letzten 1,5 Jahren eher stiefmütterlich behandelt hat?
Die Alternative wäre, einen völlig neuen Bugreport gegen chromium zu richten und in diesem auf den ursprünglichen Bugreport zu verweisen. Die beiden würden dann natürlich von irgendwem zusammengeführt werden und würden in dem Zuge Aufmerksamkeit erzeugen. Zumindest würde zwischenzeitlich mal ein NEUER rc-Bug aufblitzen. Die Vorgehensweise wär natürlich konzeptuell hässlich, würde ich aber bevorzugen, falls es die Erfolgsaussichten auf eine erneute Beschäftigung damit erhöht.
[1] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[2] https://bugs.debian.org/cgi-bin/pkgrepo ... t=unstable
[3] https://packages.debian.org/source/sid/chromium-browser
Re: gehört Chromium nach non-free?
Das nehme ich eher an.hikaru hat geschrieben: oder verpufft das beim Paketbetreuer, der den Bug ja offenbar auch in den letzten 1,5 Jahren eher stiefmütterlich behandelt hat?
Die manpower dürfte fehlen ( 2,5GB! ), und Motto des Lieferanten des upstream wahrscheinlich "friß oder stirb".
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: gehört Chromium nach non-free?
Mehrfach eine offensichtliche Sackgasse probieren? Habe die Bug-Diskussion teilweise gelesen - bis man sich im Kreis drehte.hikaru hat geschrieben:oder verpufft das beim Paketbetreuer, der den Bug ja offenbar auch in den letzten 1,5 Jahren eher stiefmütterlich behandelt hat?
Notfalls muss man zum Ziel über eine schlechte Straße. Bei anderen heiligt auch der Zweck die Mittel. Dein in Erwägung gezogenes Mittel tut niemandem weh, erzeugt Aufmerksamkeit und gibt vlt. resignierten "Vorkämpfern" neuen Mut. Könnte ja auch zum Präzedenzfall werden, gegenüber Upstream was bewirken. Oder einige Klarheit bezüglich (laxem?) Umgang mit schwarzen Schafen schaffen. Debian will wer sein. Ubuntu hat kein nonfree. Keiner würde behindert, wenn chromium in nonfree kommt. Aber viele würden überlegen. Über Linux-Zeitschiften am Ende vlt. Chromium.hikaru hat geschrieben:Zumindest würde zwischenzeitlich mal ein NEUER rc-Bug aufblitzen. Die Vorgehensweise wär natürlich konzeptuell hässlich, würde ich aber bevorzugen, falls es die Erfolgsaussichten auf eine erneute Beschäftigung damit erhöht.
Re: gehört Chromium nach non-free?
Es gibt ein Projekt ungoogled-chromium auf github
https://github.com/Eloston/ungoogled-chromium/
wo dies auch Thema ist /war
https://github.com/Eloston/ungoogled-ch ... issues/117
Im Zuge dieses Thread bin ich auf
https://libreplanet.org/wiki/List_of_so ... Guidelines
->
"chromium -> IceCat" https://www.gnu.org/software/gnuzilla/
ein gnu-firefox, LibreJS, Https-Everywhere + Codestrip (zBsp. fingerprinting)
http://ftpmirror.gnu.org/gnuzilla/ Momentan erst 45.5.1, firefox-esr dagegen 45.7.0.
Übles Zeichen, daß doch gehörig Handarbeit dazugehört,
ein einfaches automatisches Durchlaufen von strip-Skripten würde ja sofort ein aktuelles Paket bereitstellen.
Nebeneffekt ein Test mit dem Addon GNU LibreJS (NoScript deaktiviert),
debianforum wird angemeckert,
nach Freigabe Requestpolicy bleibt davon noch eine Complain bzgl. des Twitter-Links,
BBCode-Buttons funktionieren nicht.
EDIT "bleibt davon noch eine Complain" das ist ja nur die Complain-Leiste,
der Button des Addon listet dann doch eine Reihe "NONTRIVIAL" und "inline / nonfree / external".
Aber das Addon beschwert sich auch bei darkstat, wohl etwas hysterisch.
https://github.com/Eloston/ungoogled-chromium/
wo dies auch Thema ist /war
https://github.com/Eloston/ungoogled-ch ... issues/117
Im Zuge dieses Thread bin ich auf
https://libreplanet.org/wiki/List_of_so ... Guidelines
->
"chromium -> IceCat" https://www.gnu.org/software/gnuzilla/
ein gnu-firefox, LibreJS, Https-Everywhere + Codestrip (zBsp. fingerprinting)
http://ftpmirror.gnu.org/gnuzilla/ Momentan erst 45.5.1, firefox-esr dagegen 45.7.0.
Übles Zeichen, daß doch gehörig Handarbeit dazugehört,
ein einfaches automatisches Durchlaufen von strip-Skripten würde ja sofort ein aktuelles Paket bereitstellen.
Nebeneffekt ein Test mit dem Addon GNU LibreJS (NoScript deaktiviert),
debianforum wird angemeckert,
nach Freigabe Requestpolicy bleibt davon noch eine Complain bzgl. des Twitter-Links,
BBCode-Buttons funktionieren nicht.
EDIT "bleibt davon noch eine Complain" das ist ja nur die Complain-Leiste,
der Button des Addon listet dann doch eine Reihe "NONTRIVIAL" und "inline / nonfree / external".
Aber das Addon beschwert sich auch bei darkstat, wohl etwas hysterisch.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: gehört Chromium nach non-free?
Die nutzen wohl das Debianpaket von Chromium als Ausgangsbasis. Die Katze beißt sich alo in den Schwanz.rendegast hat geschrieben:Es gibt ein Projekt ungoogled-chromium auf github
https://github.com/Eloston/ungoogled-chromium/
wo dies auch Thema ist /war
https://github.com/Eloston/ungoogled-ch ... issues/117
Ja, einen wirklich Freien Browser zu benutzen ist wohl nicht trivial.rendegast hat geschrieben:Im Zuge dieses Thread bin ich auf
https://libreplanet.org/wiki/List_of_so ... Guidelines
->
"chromium -> IceCat" https://www.gnu.org/software/gnuzilla/
ein gnu-firefox, LibreJS, Https-Everywhere + Codestrip (zBsp. fingerprinting)
http://ftpmirror.gnu.org/gnuzilla/ Momentan erst 45.5.1, firefox-esr dagegen 45.7.0.
Übles Zeichen, daß doch gehörig Handarbeit dazugehört,
ein einfaches automatisches Durchlaufen von strip-Skripten würde ja sofort ein aktuelles Paket bereitstellen.
Im Thread im Pyra-Forum aus dem dieser hier entstanden ist, ging es ursprünglich darum, dass Firefox in naher Zukunft zwingend Rust als Abhängigkeit verlangt. Die Rust-Unterstützung auf armhf (bzw. irgendeiner non-x86-Architektur) wird bisher von Upstream aber sehr stiefmütterlich behandelt. Daher stellte sich die Frage nach möglichen Alternativen zu Firefox als Standardbrowser auf armhf. Und da Chromium neben Firefox der einzige Browser in Debian ist, der Sicherheitsupdates erhält, rückte der natürlich schnell in den Fokus.