bootmanager & freetz-ng
fda77 opened this issue · 27 comments
Es wird die falsche Freetz-Version angezeigt.
Mein Vorschlag: https://trac.boxmatrix.info/freetz-ng/browser/freetz-ng/trunk/tools/make/yourfritz-host/patches/100-bootmanager_freetz_detection.patch
Kannst natürlich auch sonstwie einbauen
An der verlinkten Lösung stört mich zumindest, wie da grep verwendet wird ... das bräuchte m.E. kein [ -z $(...)], denn es liefert auch gleich einen Return-Code.
Außerdem halte ich die Einführung einer "positionsabhängigen Prüfung" für unnötig bzw. für einen potentiellen Stolperstein bei weiteren Änderungen. Käme eine Kombination aus Datei und Framework hinzu und diese stünde plötzlich direkt nach YourFritz, funktioniert die Prüfung nicht mehr - das müßte man bei einer Änderung dann (noch) "wissen" und berücksichtigen. Für mich eine potentielle Fehlerquelle, die vermeidbar ist.
Wenn es bisher keine einfache Datei zur Unterscheidung von Freetz und "freetz-ng" gibt, dann solltet ihr vielleicht einfach eine einführen? Das würde es jedenfalls auch erleichtern, den Unterschied bereits anhand der Verzeichnisliste eines SquashFS-Images zu erkennen, während man dieses erst entpacken müßte (zumindest die Versionsdatei und ein "unsquashfs" ist alles andere als "handsome" und kann z.B. nicht in eine Pipe entpacken), um danach in der Datei die Zeichenketten zu vergleichen. Es gibt inzwischen so viele Unterschiede, daß diese eine Datei (die könnte ja auch problemlos leer sein, wenn ihre Existenz alleine schon den Unterschied anzeigt und dann trägt sie im Image auch nicht auf) den Kohl nun auch nicht mehr fett macht.
Gibt es eine solche Datei, baue ich die Prüfung gerne ein ... und auch da müßte ich noch die Reihenfolge zwischen "freetz-ng" und Freetz einhalten, damit das funktioniert, solange Freetz keine eigene zusätzliche Datei verwendet. Aber dann ist es nicht mehr davon abhängig, ob die "freetz-ng"-Kombination an zweiter oder fünfter Stelle steht, solange sie nur vor "Freetz" (was dann ohne "marker file" daherkäme) auftaucht und geprüft wird.
Dann wüßte ich auch gerne mal eine "offizielle" Schreibweise, damit ich den richtigen Projektnamen einsetzen kann - ich finde das Hin und Her zwischen "NG" und "ng" einigermaßen irritierend (in der Versionsdatei steht dann wieder "freetz-ng", wie auch in den meisten Pfaden) und bekanntlich unterscheidet Linux da sehr genau bei Vergleichen zweier Zeichenketten - es ist ermüdend, wenn man jedesmal erst nachsehen soll, ob da nun "NG" oder "ng" zu erwarten ist, je nachdem, woher der Vergleichswert kommt.
Wie gesagt, implementier es wie es die passt. Oder lass es halt, kein Problem. Der verlinkte Patch macht ja soweit was von ihm erwartet wird. Nach Möglichkeit vermeide ich aber Patches und melde es Upstream.
Eine zusätzliche Datei wäre ne Möglichkeit, ich versuche aber unnötige Unterschiede zu er13's freetz zu vermeiden. So Dinge wie, dass er13 ein "cacerts" package eincheckt was eigentlich nur ein umbenanntes "ca-bundle" aus Freetz-NG ist finde ich unmöglich. Dadurch sind auch die Variablennamen unterschiedlich und verursacht unnötigen Aufwand.
Die offizielle Schreibweise ist Freetz-NG, die ich auch überall verwende. Außer in Pfadnamen, Versionsangaben usw, zB in der URL oben. Dann komplett klein. oder wenn ich keine lust habe shift zu verwenden. Hippie bevorzugt die Schreibweise "Freetz-ng" und hat das auch so überall auf boXmatriX geschrieben, daher evtl die Verwirrung
Auch die wechselnden Identitäten tragen halt nicht dazu bei, daß man selbst noch durchblickt (oder gar Dritte) - aber egal, zurück zum Thema (inzwischen ist es ja auch korrigiert).
Angesichts der jetzt schon vorhandenen Unterschiede, finde ich eine weitere Datei zur Unterscheidung dieser beiden Projekte nicht wirklich übertrieben ... ich gehe fast jede Wette ein, daß man schon heute eine entsprechende Datei finden könnte. Nur ist die dann eben nicht "per Definition" fest und genau dafür gedacht und könnte sich mit dem nächsten CS schon wieder ändern oder ist vielleicht auch von unterschiedlichen .config-Einstellungen abhängig.
Ich fände es generell auch besser, wenn ich die Unterscheidung einbauen könnte (aber eben möglichst, ohne das Prinzip, das von allen anderen, dort getesteten Frameworks eingehalten wird, zu verändern), denn dann erhalten auch die Nutzer, die in der aktiven Partition kein Freetz-NG mit Deinem Patch installiert haben, sondern dieses gerade in der inaktiven Partition haben, die richtige Anzeige.
Irgendwo in fwmod noch ein touch einzubauen, damit die zusätzliche Datei erstellt wird, ist angesichts der ohnehin vorhandenen Unterschiede - gerade auch bei dieser Datei, ein einfaches diff für fwmod (ohne -u) liefert 753 Zeilen in der Ausgabe - nun wirklich nichts, was noch großartig auffällt.
Wie gesagt, ich mache gerne dabei mit ... aber ohne das Prinzip über den Haufen zu werfen und wenn ich das nicht alles umstellen will, um anstelle von "$i -eq 2" auf den potentiellen Namen "Freetz-NG" an dieser Stelle zu vergleichen (nur dann kann ich ja die Abhängigkeit von der Position wieder aufheben), dann sollte eine solche Datei existieren, wie bei allen anderen erkannten Projekten auch.
Ich habe sogar extra für YourFritz noch eine solche Marker-Datei "erfunden" (die bei der Installation des Bootmanager-Pakets angelegt wird, damit der was findet), die ansonsten gar nicht notwendig wäre.
Das mit dem "so wenige Änderungen wie notwendig" gilt auch nicht nur für Freetz-NG ... der ganze Patch in Freetz (https://github.com/Freetz/freetz/blob/master/tools/make/yourfritz-host/patches/040-bootmanager_freetz_fixed_branding_approach.patch) existiert auch nur, weil ich nicht verstehen kann (und will), warum da nun ein Sonderweg für Freetz beschritten werden mußte (die anderen existierten bereits davor) ... die Diskussion dazu nahm auch epische Ausmaße an und ist hier irgendwo (vermutlich in einem geschlossenen PR) nachzulesen. Am Ende erkennt jetzt eben "meine" Implementierung in einem zu analysierenden Freetz-Image nicht, daß/ob da nun ein festes Branding eingestellt wurde oder nicht. DAS nenne ich dann einen sinnlosen Unterschied ... aber c'est la vie.
Sorry, fda77 nutze ich normal nicht im Browser, da der Account zusätzliche Rechte hat. Eigentlich wollte ich Verwirrung vermeiden. Naja :D
/etc/.freetz-version ist doch gut für Freetz. Diese wird nämlich aus ./.version im Checkout gebaut. Diese wird für releases (tar, ohne svn/git) oder tags geändert, zB https://trac.boxmatrix.info/freetz-ng/browser/freetz-ng/branches/freetz-stable-2.0/.version oder https://trac.boxmatrix.info/freetz-ng/browser/freetz-ng/tags/freetz-1.2/.version
Wenn die .freetz-version ^freetz-ng- hat, ist der Fork eindeutig, hab ich nicht vor was daran zu ändern.
Gibt auch vieles was darauf zugreift, externes als auch internes (zb Versionsanzeige im Webif, Partitionsanzeige im Webif, Freetz-Info im Webif). Möchte das alles nicht ändern
Wenn es aber unbedingt eine Datei sein soll: r15058, 20-multid.sh
Die packt er's freetz sogar auf Extender, die gar keinen multid haben
Wie das mit Brandings ist weiss ich nicht, hab mich damit nie beschäftigt. Dass es Menschen gibt die den Code von anderen zb durch sog Verschönerung der Variablennamen aufwerten ist bekannt
Was bringt es mir denn, wenn die GitHub-Version von Freetz die Datei 20-multid.sh enthält und alle anderen aber nicht, inkl. der Modifikationen durch modfs oder YourFritz bzw. der unmodifizierten Firmware von AVM? Dann muß man das ja ebenfalls wieder umstellen, erst mal feststellen, daß es sich um Freetz oder Freetz-NG handelt, um danach noch zwischen den beiden zu unterscheiden.
Das ist doch etwas vollkommen anderes, als ein zusätzliches Kennzeichen (meinetwegen eine /etc/.freetz-ng mit 0 Byte), mit dem sich die beiden Freetz-Varianten (die beide eine /etc/.freetz-version enthalten und sich dann nur in deren INHALT unterscheiden, während alle anderen Modifikationen am Dateinamen ihrer Marker-Datei zu erkennen sind) unterscheiden lassen.
Schon die Tatsache, daß man dann für die sichere Erkennung von Freetz-NG oder Freetz die Reihenfolge der Abfrage einhalten muß, ist eigentlich zuviel "Sonderbehandlung" ... aber dann noch - nur für die beiden Freetz-Versionen - in die Datei hineinzuschauen für eine Unterscheidung (und nur bei diesen beiden Projekten), das ist dann definitiv ein Sonderweg, der m.E. nicht erforderlich ist.
Ich gehe jetzt auch nicht hin und puzzle in "modfs" eine "freetz-version"-Datei hinein (da paßt schon der Name nicht), die dann anstelle von "freetz-" oder "freetz-ng-" mit "modfs-" beginnt, damit wieder derselbe Mechanismus verwendet werden kann.
Auch wenn ich mich doch noch mal mit meinen YourFreetz-Fork für ein eigenständiges Projekt entscheiden sollte (die Domain dafür habe ich schon) und damit tatsächlich ein Image bauen lassen wollte und da eine Unterscheidung zwischen Freetz und YourFreetz geschaffen werden müßte, würde ich wohl nur eine zusätzliche Datei erzeugen und nicht überall so ändern, daß die freetz-version am Ende mit YourFreetz- beginnt.
OK, wenn man zuerst auf Freetz testet, anstelle von Freetz-NG, dann klappt's auch mit der 20-multid.sh aus der CGI-Behandlung von Freetz ... nur wie lange bleibt das "stabil", wenn man eine solche Datei "mißbraucht"? Da ist mir eine Datei, deren Zweck ausdrücklich die Unterscheidung ist und bei deren Änderung/Abschaffung man sich dann der Folgen auch bewußt ist, irgendwie sympathischer.
Nee, ne extra Datei nur für bootmanager ist keine gute Idee. Die käme dann auch auf Geräte mit nur 4mb Flash (insgesamt). Bei swap und telnet hab ich mir ja auch die Mühe gemacht, alle Dateien nicht ins Image zu nehmen wenn nicht ausgewält (nicht wie du überall Abfragen hinein)
Man könnte die Datei auch nur für Geräte mit 2 partition-sets machen. wäre aber nicht mehr eindeutig.
Das vorhandene reicht ja für eine Erkennung
Andere Herangehensweise:
Aktuell wird anhand der Vorkommens einer Datei die Mod erkannt.
Bei Freetz ist in dieser Datei aber immer die revision/version und auch der Fork drin
Wenn man sich nun im Fretz Webif anschaut: Hauptseite, Freetz-Info, Partitionsauswahl, Seitenüberschrift (Rahmen) - alle nutzen den Inhalt dieser Datei.
Dh einfach den Bootmanager erweitern dass nicht nur Freetz, sondern auch Details dazu angezeigt werden. Das erspart dazu die Sonderbehandlung von Forks
Nee, ne extra Datei nur für bootmanager ist keine gute Idee.
Ich hatte bereits versucht zu erklären, daß diese nicht nur für den Boot-Manager ganz praktisch wäre, sondern auch an anderen Stellen zur Unterscheidung zwischen einem Freetz- und einem Freetz-NG-Image taugt und zwar ohne daß man dieses Image erst mal mounten oder gar entpacken müßte.
Will man das tatsächlich nicht, kann man die Datei problemlos auch in der Wrapper-Partition hinterlegen, da greifen alle Argumente hinsichtlich des Platzbedarfs praktisch automatisch nicht mehr.
Außerdem könnte man auch einfach die /etc/.freetz-version als /etc/.freetz-ng-version speichern und für /etc/.freetz-version einen passenden Symlink verwenden ... automatisch muß man auch am Rest des Codes nichts weiter ändern und hat trotzdem die Unterscheidung (ebenfalls wieder bereits anhand einer Verzeichnisliste aus unsquashfs -l[l]).
Das trägt auch beim Ergebnis nicht auf:
vidar:/tmp # /home/GitHub/YourFritz/bin/squashfs/x86_64/unsquashfs4-be filesystem_core.squashfs
Filesystem on filesystem_core.squashfs is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
3927 inodes (4742 blocks) to write
[================================-] 4742/4742 100%
created 3317 files
created 278 directories
created 597 symlinks
created 13 devices
created 0 fifos
vidar:/tmp # printf "freetz-ng-something" > squashfs-root/etc/.freetz-ng-version
vidar:/tmp # /home/GitHub/YourFritz/bin/squashfs/x86_64/mksquashfs4-be squashfs-root/ case1.sqfs -nopad
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on case1.sqfs, block size 65536.
[================================\] 4133/4133 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
compressed data, compressed metadata, compressed fragments, no xattrs
duplicates are removed
Filesystem size 26049.82 Kbytes (25.44 Mbytes)
32.27% of uncompressed filesystem size (80728.27 Kbytes)
Inode table size 34024 bytes (33.23 Kbytes)
23.42% of uncompressed inode table size (145291 bytes)
Directory table size 42606 bytes (41.61 Kbytes)
41.76% of uncompressed directory table size (102037 bytes)
Number of duplicate files found 1290
Number of inodes 4206
Number of files 3318
Number of fragments 296
Number of symbolic links 597
Number of device nodes 13
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 278
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
vidar:/tmp # cd squashfs-root/etc/
vidar:/tmp/squashfs-root/etc # ln -s .freetz-ng-version .freetz-version
vidar:/tmp/squashfs-root/etc # cd ../..
vidar:/tmp # /home/GitHub/YourFritz/bin/squashfs/x86_64/mksquashfs4-be squashfs-root/ case2.sqfs -nopad
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on case2.sqfs, block size 65536.
[================================-] 4133/4133 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
compressed data, compressed metadata, compressed fragments, no xattrs
duplicates are removed
Filesystem size 26049.74 Kbytes (25.44 Mbytes)
32.27% of uncompressed filesystem size (80728.34 Kbytes)
Inode table size 33988 bytes (33.19 Kbytes)
23.39% of uncompressed inode table size (145333 bytes)
Directory table size 42574 bytes (41.58 Kbytes)
41.71% of uncompressed directory table size (102060 bytes)
Number of duplicate files found 1290
Number of inodes 4207
Number of files 3318
Number of fragments 296
Number of symbolic links 598
Number of device nodes 13
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 278
Number of ids (unique uids + gids) 1
Number of uids 1
root (0)
Number of gids 1
root (0)
vidar:/tmp # ls -l case*.sqfs
-rw-r--r-- 1 root root 26675015 Aug 22 12:40 case1.sqfs
-rw-r--r-- 1 root root 26674931 Aug 22 12:41 case2.sqfs
vidar:/tmp # /home/GitHub/YourFritz/bin/squashfs/x86_64/unsquashfs4-be -lls case1.sqfs | grep freetz
-rw-r--r-- root/root 19 2019-08-22 12:39 squashfs-root/etc/.freetz-ng-version
vidar:/tmp # /home/GitHub/YourFritz/bin/squashfs/x86_64/unsquashfs4-be -lls case2.sqfs | grep freetz
-rw-r--r-- root/root 19 2019-08-22 12:39 squashfs-root/etc/.freetz-ng-version
lrwxrwxrwx root/root 18 2019-08-22 12:40 squashfs-root/etc/.freetz-version -> .freetz-ng-version
vidar:/tmp #
(mal alles als root ausgeführt, weil es sonst Probleme mit den Dateirechten geben kann)
Ich habe hier allerdings ein originales AVM-Image als Ausgangsmaterial zur Demonstration verwendet ... aber wie man sehen kann, wird das Ergebnis mit dem Symlink sogar noch kleiner (weil es effektiver komprimiert wird).
Es gibt also sehr viele Wege, die nach Rom führen können ... man muß nicht unbedingt in dem Wirtshaus am Wegesrand (mit der Adresse /etc/.freetz-version) Einkehr halten und dort erst nachfragen, ob es sich um Freetz oder Freetz-NG handelt, wenn es bereits draußen dran steht (z.B. "Zum lustigen Freetz-NG-Wanderer ...").
Die Idee mit extra Datei gefällt mir dennoch nicht.
Dass diese eine (oder Link) meist das Image nicht vergrößert ist klar. Nur wenn man 100 mal ein bisschen dazupackt macht es einen Unterschied. Selbst das easteregg wird unter gewissen Bedingungen nicht mit ins Image genommen.
Im Wrapper wäre nicht mehr eindeutig, da es die Datei dadurch nur in manchen Images geben würde, man könnte sich nicht darauf verlassen.
Und wie gesagt, die nötigen Infos sind ja bereits vorhanden.
Wenn du den Inhalt von .freetz-version (wie an vielen anderen Stellen auch) ausgibst, hat man nicht nur die Version sondern auch den Fork. Damit bräuchte man keine Sonderbehandlung für jeden Fork. Sonst müsste sich jeder beim BM mit seiner Datei "registireren"
Damit bräuchte man keine Sonderbehandlung
Ja, das sehe ich nun mal anders ... dann bräuchten nämlich alle Freetz-Forks genau eine solche.
Außerdem sehe ich nicht, welchen zusätzlichen Vorteil die Anzeige von Informationen (in der Reboot-Seite wohlgemerkt) bringen sollte, die bei anderen Systemen dann gar nicht vorliegen. Erst soll die Tatsache "weggepatcht" werden, daß anstelle von Freetz-NG nur Freetz angezeigt wird (der Box-Besitzer wird ja i.d.R. auch wissen, welche Geschmacksrichtung von Freetz er verwendet und bräuchte die Info nicht unbedingt, das dient ja eher der Wiedererkennbarkeit bzw. Gleichstellung von Freetz-NG) und jetzt sind wir bei einer Sonderbehandlung für alle Freetz-Forks angekommen.
Ich sehe hier Aufwand und Nutzen nicht mehr in der richtigen Relation ... da man ohnehin davon ausgehen kann, daß die Freetz-Nutzer es (a) wissen und (b) vielleicht mal mit einer (deutlich mäßiger modifizierten) AVM-Version (oder auch "modfs") in der einen Partition und Freetz (egal ob mit oder ohne NG) in der anderen arbeiten werden, reicht vermutlich Deine Modifikation für die Unterscheidung zwischen Freetz-NG und Freetz dann auch aus und auch die Tatsache, daß die dann halt nur bei der Version, die in Freetz-NG-Images installiert ist, erkannt wird, stellt ja nicht wirklich einen Nachteil dar. Siehe mein Argument, daß nur sehr, sehr wenige Nutzer zwei unterschiedliche Forks verwenden werden und damit aus der Anzeige "Freetz" in meiner Version (egal, wie die auf die Box gekommen ist) auch unmittelbar schließen können, daß es sich hier um "Freetz oder einen Freetz-Fork" handelt.
Wenn die Existenz einer zusätzlichen Datei einen ausschlaggebenden Nachteil beim Platz ergibt, sehe ich nicht wirklich, wieso eine kompliziertere Implementierung, die wieder zu einer Vergrößerung des Boot-Manager-Skripts führt, am Ende besser sein sollte und um diese beiden Nachteile miteinander vergleichen zu können, müßte man die Alternative erst einmal implementieren. Stellt sich hinterher heraus, daß der "größere Nachteil" in der vergrößerten Skript-Datei liegt, war das alles umsonst.
Schon jetzt ergibt sich (wenn ich eine Änderung an meiner Version erst mal rückgängig mache, die Dein Patch noch gar nicht berücksichtigt: e4fe5e7#diff-b34b831cb9f5e59861246d018ec828a3) nach dem Anwenden der beiden Patches aus Freetz (bzw. zwei sind es nur bei Freetz-NG, wobei der zweite eben sogar voll gegen den Baum fährt) eine entsprechend vergrößerte Ausgangsdatei:
vidar:/tmp # l /home/GitHub/YourFritz/bootmanager/gui_bootmanager gui_bootmanager
-rwxr-xr-x 1 root root 83828 Jul 12 00:48 /home/GitHub/YourFritz/bootmanager/gui_bootmanager*
-rwxr-xr-x 1 root root 84071 Aug 22 17:38 gui_bootmanager*
Durch die Patches (einmal den aus dem GitHub-Freetz und einmal Deinen) wird also die Datei schon mal per se um 243 Byte größer ... ist das eines von den 100 Mal, die Du meinst?
Ich bin ja bereit, ein "Platzargument" zu akzeptieren, wenn es plausibel erscheint ... ja, ich gehe sogar so weit, daß ich mich bereiterkläre, durch das Ändern von Variablennamen in dem Skript noch das eine oder andere Byte herauszuquetschen - wenn es denn tatsächlich so eng ist in den resultierenden Images und das nicht alles nur graue Theorie ist.
Dann erzeuge die Datei eben nur für die Boxen, wo die Installation des Boot-Managers überhaupt Sinn macht, weil es zwei Systeme gibt ... die passenden Freetz-Settings dafür gibt es ja.
Aber ich werde nicht darüber nachdenken, wie ich jetzt mein Skript abändere, nur damit auf irgendwelchen Asbach-Boxen mit 4 MB Flash (wo das Skript niemals benötigt wird) kein zusätzlicher Symlink angelegt werden muß.
Man muß auch mal Aufwand und Nutzen gegeneinander abwägen und solange mir nicht 1 Mio. 7170-Besitzer (selbst die hat ja schon 8 MB Flash) hier die Bude einrennen (die halt das Skript auch nicht brauchen), denke ich nicht länger über dieses Problem nach.
Gibt's das Marker-File, baue ich es ein und Freetz-NG wird auch dann richtig angezeigt, wenn in der aktiven Partition gerade kein Freetz-NG-Image läuft (Freetz "erbt" ja dann wieder meine Implementierung). Gibt es das File nicht, baue ich nichts um und Freetz-NG wird in den betroffenen Konstellationen weiterhin als Freetz angezeigt, was auch kein echter Beinbruch ist ... Deine Entscheidung.
Wenn der BM größer wird, ist es kein Problem. Alle Boxen für die er angeboten wird haben (glaub ich) 44MB Filesystem. Daher macht es hier nichts aus.
Aber auf jede einen marker Datei zu setzen die nur vom BM genutzt wird (wenn überhaupt verfügbar) macht keinen Sinn
Kannst gerne hier zumachen, kein Problem. Wollte dir das Upstream melden, da ich das besser finde. (Hatte ich eigentlich dem aufgetragen der dern BM gebraucht hatte, war aber zu faul)
Weisst ja dass ich die Paritionsanzeige im Freetz Webif besser finde - dort sogar mit Versionsanszeige ;-)
EDIT: Hab mal nachgeschaut, die anderen beiden Patches für yourfritz-host betreffen signimage. Ob die in NG drin sind oder nicht macht keinen Unterschied. Oder braucht man das für irgendwas?
Wenn das "Anschwellen" des Boot-Managers bei den betreffenden Boxen keine Rolle spielt, warum sollte das dann für eine zusätzliche Marker-Datei der Fall sein, zumal ich noch gezeigt habe, daß die nicht mal in jedem Falle zur Vergrößerung des Images führt?
Es ist alles vorhanden, was es für die Entscheidung, ob der Boot-Manager zu installieren ist oder nicht, braucht.
Notfalls baut man das Erzeugen der Datei per Patch in die (YourFritz/bootmanager-)Datei ein, mit der die anderen Dateien (denn es handelt sich ja nicht nur um das Shell-Skript, sondern es finden auch Änderungen am Lua- und JS-Code statt) modifiziert werden ... nur muß das halt die jeweilige Plattform selbst machen, weil ich nicht weiß (und nicht wissen will), welcher Fork die Installation in Auftrag gibt.
Das Verwenden des Inhalts der /etc/.freetz-version (EDIT: für die direkte Anzeige) verbietet sich für mich jedenfalls "von selbst" ... wenn Du oben nachliest, habe ich schon vor Deinem Vorschlag betont, daß ich gerne den richtigen und "offiziellen" Projektnamen für die Anzeige verwenden möchte. Meines Wissens steht der aber genau nicht in der fraglichen Datei ... damit ist eine 1:1-Anzeige definitiv nicht das, was ich da haben will und auch Dein Patch (der sich eben noch auf eine ältere gui_bootmanager-Datei stützt, die irgendwann auch in Freetz im GitHub abgelöst werden wird und dann änderst Du entweder Deinen Patch oder müßtest die Änderung in Freetz rückgängig machen, wenn Du weiter mit der alten Version arbeiten willst) war ja eher nicht darauf ausgerichtet, den Inhalt dieser Datei anzuzeigen - das hast Du Dir ja "on the fly" als Vorschlag einfallen lassen und wenn ich darauf nicht weiter eingegangen bin (und das auch in der Zukunft nicht will), liegt das genau an diesem Widerspruch in der Schreibweise zwischen der Versionsdatei und dem offiziellen Projektnamen.
Damit muß/müßte ich die "offiziellen" Namen ohnehin weiter im Shell-Skript "verwalten" und da sehe ich nicht einen plausiblen Grund, warum ich zum Vergleich, welche "korrekte Schreibweise" auszuwählen und anzuzeigen wäre, jetzt erst mit einer zweiten Zeichenkette, die ich aus einer Datei gelesen habe, vergleichen sollte. Wenn Dir die "Unwucht" bei diesem Vorgehen nicht einleuchten will, werden wir nicht zu einer gemeinsamen Lösung finden.
Schau dir dir mal die ganzen anderen Stellen im Webif an, an denen die Version ausgegeben wird. Da kommt "Freetz ng-12345" raus. Das passt ja, es ist da Teil der Version.
Überall (gibt bestimmt noch mehr Stellen) was zu ändern, nur damit "Freetz-NG" zusammenhängend da steht ist es mit nicht (Mehr)wert.
Zumal der Versionsstring duch einen git-clone durchaus wesentlich länger werden kann (hatte meine Implementierung gelöscht und nutze nun das Scirpt von er13) und man dann auch kennen würde wo es herkommt
Ich hätte ja jetzt erwartet, daß Du selbst weißt, daß die Anzeige im Freetz-GUI (bei "Freetz-Info") eben gerade nicht aus der /etc/.freetz-version kommt, wie Dein Patch (für das Boot-Manager-Skript) das noch auswertet.
Ich müßte mich schon schwer täuschen, wenn die Anzeige im Freetz-GUI sich nicht aus einer vollkommen anderen Datei speist, nämlich aus der /etc/freetz_info.cfg.
Einen echten Nutzen in der Information, welche Freetz-Version da nun genau installiert ist, kann ich nicht erkennen ... ich weise gerne noch einmal darauf hin, daß Dein Anliegen ja am Beginn (und ich sehe keinen Grund, das zu ändern) darin bestand, den korrekten Projektnamen anzeigen zu lassen und nicht immer nur "Freetz".
Warum daraus jetzt im Verlauf der Diskussion etwas vollkommen anderes geworden ist, begreife ich nicht. Jetzt willst Du ja, daß ich auch für (das andere) Freetz eine andere Anzeigeform verwende und für alle Freetz-Forks (bisher betrifft es nur zwei) in einer Datei nach den Merkmalen suche, mit denen die Freetz-Versionen zu unterscheiden sind. Zumal Du ja wohl nicht davon ausgehen wirst, daß ich dann auch noch solche Konstrukte bei mir einbaue:
Letztlich kommt Deine eigene Anzeige beim "Umschalten" mit dem "Freetz ng-irgendwas" ja genau aus dieser Zeile ... da ist schlicht nichts Generisches enthalten und die Anzeige "Freetz " kommt nur dadurch zustande, daß beim GitHub-Freetz nach dem ersten Bindestrich gleich die Version kommt. Mir das jetzt als "das ist in Freetz überall so" unterzujubeln, finde ich einigermaßen unfein - außer Du wolltest mir damit sagen, daß überall in Freetz die Zeichenkette "freetz-" durch "Freetz " ersetzt wird, wenn es um solche Anzeigen geht. Da wirst Du ja hoffentlich nicht von mir erwarten, daß ich das jetzt genauso nachimplementiere ... wenn der Nächste da "yourfreetz-" stehen hat (ich kenne da jemanden, bei dem das der Fall sein könnte), klappt das nämlich auch nicht mehr und so würde ich gerne bei meiner Zuordnung "Marker-File => Projektname" bleiben ... und ich denke, das habe ich inzwischen mehrfach deutlich gemacht.
Der ganze Boot-Manager von mir ist auch immer noch Bestandteil von YourFritz und die primäre Ausrichtung (hinsichtlich Nutzwert und Integration in das GUI) berücksichtigt nicht nur die Belange der Freetz-Forks.
Wenn ich die Freetz-Erkennung dort eingebaut habe, geschah das im Interesse der Benutzer - wenn es jetzt zwei Freetz-Projekte gibt und diese dort gleichberechtigt angezeigt werden sollen (so verstehe ich Dein Anliegen), dann halten sich bitte auch beide Freetz-Projekte an den dabei von mir vorgezeichneten Weg, wenn ich das in meinem Code bereits machen soll. Was jedes Projekt für sich dann da wie patcht, soll mir auch egal sein ... solange dann die Nutzer nicht auf die Idee kommen, bei mir wegen Problemen auf der Matte zu stehen, die erst durch fremde Patches hinzugekommen sind.
Sofern es andere Gründe gibt, warum Freetz-NG nicht komplett seine eigene Versionsdatei als "Kennzeichnung" verwenden will, bin ich bereit, das zu akzeptieren und bei der Unterscheidung zwischen den Freetz-Forks auf eine gewisse Reihenfolge in der Abfrage Rücksicht zu nehmen.
Aber dann ist auch Schluß ... denn wenn man Deiner Argumentation versucht zu folgen und mal nach ".freetz-version" suchen läßt, stellt man auch schnell fest, daß der überwiegende Teil der Dateien, in denen auf diese Datei zugegriffen wird (das sind 10 Fundstellen, die auch im Image landen), ohnehin schon in Freetz-NG angepaßt und verändert wird - bis hin zu den URLs in den skin.sh-Files. Das macht die "Ansage": "Ich will nicht alles ändern." dann schon deutlich weniger plausibel.
Läßt man das mal auswerten, sieht es doch erheblich anders aus, als man nach Deinen Schilderungen vermuten würde:
freetz@zbox:~/freetz-ng> grep -H -r "\.freetz-version" | sed -n -e "s/^\(make[^:]*\).*/\1/p" | sort | uniq | (i=0; while read f; do i=$((i+1)); printf "%d: %s :\n" "$i" "$f"; diff -q ../freetz-master/$f $f; done)
1: make/lcd4linux/files/root/etc/default.lcd4linux/lcd4linux.conf :
diff: ../freetz-master/make/lcd4linux/files/root/etc/default.lcd4linux/lcd4linux.conf: No such file or directory
2: make/mod/files/root/etc/init.d/rc.mod :
Files ../freetz-master/make/mod/files/root/etc/init.d/rc.mod and make/mod/files/root/etc/init.d/rc.mod differ
3: make/mod/files/root/usr/mww/cgi-bin/backup/do_backup.cgi :
4: make/mod/files/root/usr/mww/cgi-bin/status.d/10-box.sh :
5: make/mod/files/root/usr/mww/cgi-bin/support/do_support.cgi :
6: make/mod/files/root/usr/mww/cgi-bin/system_lfs.cgi :
diff: ../freetz-master/make/mod/files/root/usr/mww/cgi-bin/system_lfs.cgi: No such file or directory
7: make/mod/files/root/usr/share/skin/cuma/skin.sh :
diff: ../freetz-master/make/mod/files/root/usr/share/skin/cuma/skin.sh: No such file or directory
8: make/mod/files/root/usr/share/skin/legacy/skin.sh :
Files ../freetz-master/make/mod/files/root/usr/share/skin/legacy/skin.sh and make/mod/files/root/usr/share/skin/legacy/skin.sh differ
9: make/mod/files/root/usr/share/skin/newfreetz/skin.sh :
Files ../freetz-master/make/mod/files/root/usr/share/skin/newfreetz/skin.sh and make/mod/files/root/usr/share/skin/newfreetz/skin.sh differ
10: make/mod/files/root/usr/share/skin/phoenix/skin.sh :
Files ../freetz-master/make/mod/files/root/usr/share/skin/phoenix/skin.sh and make/mod/files/root/usr/share/skin/phoenix/skin.sh differ
freetz@zbox:~/freetz-ng>
Wir haben also 10 Dateien mit einer Referenz auf /etc/.freetz-version unterhalb von make (es gäbe da noch die fwmod und die freetz-version unterhalb von tools, aber die betreffen den Build-Host und haben mit dem CGI nichts zu tun) und von denen sind schon mal drei in einem GitHub-Checkout gar nicht vorhanden. Weitere vier unterscheiden sich ohnehin zwischen Freetz und Freetz-NG und damit bleiben noch drei Dateien übrig, die man zusätzlich anpassen müßte, wenn man anstelle von .freetz-version seinen eigenen Namen für diese Datei verwenden wollte. Das klingt schon wieder überschaubar ... ich würde trotzdem (wenn ich das machen müßte) weiterhin mit der zusätzlichen Versionsdatei (als Symlink) arbeiten. Aber aus
die ganzen anderen Stellen im Webif
wird bei genauerer Betrachtung dann sehr schnell eine sehr überschaubare Größenordnung - das überzeugt mich also auch nicht wirklich.
Zumal der Versionsstring duch einen git-clone durchaus wesentlich länger werden kann
Eben ... das ist für mich noch ein weiterer Grund, warum ich nichts von einer Stelle lesen will, wo ich die Länge des Wertes nicht einschätzen kann. Entgegen dem Freetz-GUI ist das AVM-GUI nämlich in der Lage, sich auch an kleinere Bildschirme oder kleinere Fenster anzupassen und da braucht es keine "überlangen" Zeichenketten in irgendwelchen dynamisch generierten HTML-Elementen, die nur einen geringen Nutzwert versprechen und schon viel früher - alleine wegen ihrer Länge - zu einer Reorganisation der Anzeige führen, weil der Platz für deren Darstellung nicht mehr ausreicht.
Das sieht schon so nicht mehr richtig gut aus, bei entsprechender Verkleinerung ... das kann man sich ja jetzt mal noch mit einer Versionsangabe von Freetz vorstellen, die in ihrer Länge die anderen Zeilen noch übertrifft. Nein, danke ... das brauche ich hier nicht.
Wenn es dir so reicht wie es ist, lass es halt. Solange Freetz im Image ist, bevorzuge ich bekanntlich eh die Anzeige über das Freetz Webif.
Denke auch nicht dass man darüber noch viel mehr diskutieren sollte.
Die Sache mit der config-area find ich viel spannender. Das wird anscheinen wegen dem End-marker nicht erkannt, die 2 umbenannten Vairablen dürften egal sein.
Freetz-Info war ein schlechtes Beispiel, dies, boxinfo und automount sind von hermann. Er hat oft eigene Wege eingeschlagen, ist dir bei den returncodes von "swap" bestimmt auch aufgefallen.
Wenn du gerne ein dynamischeres Skin für Freetz hättest, mach doch eins! Aktuell kann man nur die Breite fest Einstellen, prozentual hab ich nicht ausprobiert. Mach eine Kopie eines existierenden, gib ihm einen Namen und leg los
Oh, da war ja noch ein 2. Post.
Wie gesagt, es gibt auch externe Abhängigkeiten, irgendwelche Tools, Scripte oder Apps.
Da du oben Skins anführst: Im DEB gibt es Skin-addons, glaube mindestens 3. Hab mir die nicht genau angeschaut, auf Screenshots ist aber zu sehen dass da Bilder von Fritzboxen drin sind...
Jedenfalls, wenn die auf Basis der aus Freetz gebaut wurden, würde es diese auch betreffen - und man müsste die richtige addon-version zum Fork nehmen - das dürfte zu schwierig für manche sein.
Oder zusätzliche Abfragen mit Reihenfolge usw einbauen, auch blöd.
Ich glaube, jetzt schreiben wir endgültig aneinander vorbei.
Mir ist doch vollkommen gleich, wie Freetz mit oder ohne Skin aussieht und ob das ein "responsive design" ist (man kann auch nicht alles nur über CSS regeln, dazu gehört schon noch etwas mehr).
Ich benutze ohnehin kein Freetz(-GUI) und mein Argument bezog sich eindeutig darauf, daß das AVM-GUI überfordert sein dürfte, wenn da eine Zeichenkette wie 7490_07.11-freetz-YourFritz-20190628-c3757d9f7-dirty.de_20190628-012652 als automatisch generierter Name anzuzeigen wäre.
Ich werde also ganz bestimmt auch kein neues Skin für Freetz erstellen ... was sollte das bringen? Ich habe nur darauf hingewiesen, daß die vier skin.sh-Files in Freetz-NG auch noch jede Menge andere Änderungen ggü. der GitHub-Version erfahren haben und daher ohnehin beim Merge mit dem GitHub-Master zusätzliche Vorsicht bzw. Arbeit notwendig ist - da spielt dann die Frage, ob die Datei jetzt .freetz-version heißt oder .freetz-ng-version auch keine entscheidende Rolle mehr (und auch diese ganze Diskussion ist ja nur notwendig, wenn man den Symlink partout nicht erstellen will).
Die (sichtbaren) Abhängigkeiten von diesem Dateinamen habe ich aufgezeigt und zwar explizit für den SVN-Trunk von Freetz-NG ... außerdem habe ich mehrfach betont, daß man den Symlink ZUSÄTZLICH erzeugen sollte - damit wird die ganze Diskussion um irgendwelche Änderungen, die man nicht machen will (andere macht man hingegen eben schon und das durchaus "freiwillig"), doch komplett obsolet.
Wenn ich eines Deiner Argumente wörtlich nehme und es auf seine Stichhaltigkeit überprüfe, ist das aus irgendeinem Grund immer das Falsche, was ich da ansehe ... obwohl es doch vorher eigentlich von Dir in dem Argumentationsversuch genau so auch angegeben wurde.
Mein Fazit wäre jetzt, daß ich Dir den einfachsten Weg zu einer Unterscheidung zwischen Freetz und Freetz-NG im Boot-Manager (und zwar in meiner Version) gezeigt habe. Willst Du den gehen und stellst eine solche Datei bereit, baue ich es ein. Willst Du den nicht gehen, kann ich es auch nicht einbauen. Ich denke, da sind wir uns einig ... und wie Du oben selbst feststellst, braucht es dazu nicht wirklich eine weitere Diskussion.
Ich mache daher hier erst einmal zu ... solltest Du die notwendige Datei irgendwann eingebaut haben (selbst wenn ich ab und an mal einen Blick auf die Trac-Timeline werfe, muß das noch nicht heißen, daß ich eine solche Änderung anhand des Kommentars auch erkenne), kannst Du hier gerne wieder aufmachen und mir ihren Namen mitteilen. Dann sehen auch Verwender meiner Version des Boot-Managers (wie gesagt, an dem Punkt "erbt" das GitHub-Freetz dann ja auch von meinem Code) ein "Freetz-NG" anstelle von "Freetz", wenn es sich um ein solches Image handelt ... ansonsten müssen sie es sich eben dazudenken.
BTW ... solltest Du Dich doch zu der Lösung mit dem Symlink durchringen, dann benenne bitte die echte Datei so, daß man Freetz-NG daran erkennt - es gibt (zumindest bisher) in Freetz-Forks keine Abfragen mit test -f, sondern da wird i.d.R. mittels cat gleich ausgelesen. Letzteres funktioniert natürlich auch dann, wenn die /etc/.freetz-version ein Symlink auf eine andere Datei ist (sofern diese dann existiert) - die Prüfung mittels test -f, wie ich sie betreibe in get_modified_by(), kann aber mit einem Symlink auch nichts anfangen.
Du hattest oben Dateien aufgeführt, die zu Skins gehören! Dh skins die nicht im Repo sind müssten evtl auch angepasst werden.
Extra Datei je Fork find ich blöd, müsste dann ja jeder github-fork auch so machen
Zusatzfrage: Wie ist das mit der 040-bootmanager_freetz_fixed_branding_approach.patch, ist die überflüssig? Falls ja mach einen branch in dem die gelöscht wird, das kann ich dann mergen
müsste dann ja jeder github-fork auch so machen
Exakt. Zumindest dann, wenn er möchte, daß meine Implementierung (und die darauf aufbauenden Vorkommen in einem Freetz-Fork) eine Unterscheidung zwischen Freetz und dem jeweiligen geforkten Projekt treffen kann.
Ich sag mal, bei 4-5 Forks wäre dann aber auch bei mir Schluß (so weit muß man aber erst mal kommen) und ich würde mir Gedanken über eine Alternative machen ... die läuft dann aber auch wieder auf eine zusätzliche Datei bzw. auf ein zusätzlich erforderliches Kommando hinaus, wie z.B. hostnamectl:
vidar:/tmp $ hostnamectl
Static hostname: vidar.home.<masked>.de
Transient hostname: vidar
Icon name: computer-desktop
Chassis: desktop
Machine ID: 7008c79ab49e471a9a2<masked>
Boot ID: ab6a154553214b29a9c4<masked>
Operating System: openSUSE Tumbleweed
CPE OS Name: cpe:/o:opensuse:tumbleweed:20190704
Kernel: Linux 5.1.15-1-default
Architecture: x86-64
vidar:/tmp $
, wobei ich diese Datei dann bei der Installation des Boot-Managers in das Zielsystem integrieren würde.
Aber wie gesagt ... das steht erst mal nicht auf dem Plan (die andere Methode funktioniert bei überschaubarer Menge an Kandidaten auch sehr gut) und solange es keine Datei bzw. kein Kommando in einem System gibt, in der oder mit dem ich - ohne jeden anderen Kokolores wie Versionsnummer, CS-Angaben oder Commit-Hashes - einfach nur den "offiziellen" Projektnamen auslesen kann (das wäre dann bei einer hostnamectl-Ableitung der Fall), interessieren mich Dateiinhalte nicht.
Es ist ja auch irgendwo komisch, wie schnell Du dann von "Freetz-NG" auf "Freetz ng-irgendwas" gewechselt bist bei der Frage, wie denn nun der offizielle Fork-Name wäre - mein Eindruck war, daß es Dir dann doch nicht "so wichtig" war (obwohl Dein Patch-Vorschlag das auch so schrieb), nur weil es eben in der "erforderlichen Form" in keiner Datei zu finden ist und Du Dich jetzt einfach mit dem zufriedengeben wolltest (und ich das für Freetz auch machen sollte), was da irgendwo steht.
Ich kenne bisher keine andere (praktikable) Lösung, bei der auch noch die korrekt geschriebenen Projektnamen am Start wären ... wenn ich jetzt schon auf etwas Analoges zum hostnamectl umstellen würde, bringt das bei Dir auch keinen Unterschied in der Notwendigkeit einer zusätzlichen Datei und - bis ich einen entsprechenden PR für Freetz bereitgestellt habe - die Erkennung von Freetz und anderen Forks funktioniert nicht länger. Damit wären dann also zwei Freetz-Projekte mit notwendigen Änderungen befaßt, nur damit auch Freetz-NG ordentlich von meinem Boot-Manager angezeigt wird. Das ergibt für mich keinen Sinn - solange keine Notwendigkeit dafür besteht.
Wie ist das mit der 040-bootmanager_freetz_fixed_branding_approach.patch, ist die überflüssig?
Ja und nein. Die Diskussion dazu findet sich hier: #16 und ich nehme nicht an, daß da tatsächlich erwartet wurde, ich würde diesem Vorschlag folgen.
Das war für mich mehr ein "Siehste" ... daß/warum/wie lange die andere Variante des "festen Brandings" (anhand der export OEM=<value>-Zeile) schon im Gespräch war und benutzt wurde, habe ich in der Diskussion in diesem PR versucht zu erklären.
Eine Änderung um der Änderung willen ist nichts, was ich brauche - wenn man den 040-Patch entfernt, müßte man auch die Einstellung des festen Brandings auf dem Weg vornehmen, wie sie - lange vor der Diskussion in dem PR - im entsprechenden IPPF-Thread (Link steht garantiert irgendwo in der Diskussion) vorgeschlagen und von einigen auch umgesetzt wurde, bevor ich das in "modfs" aufnahm und es im Anschluß auch Einzug in Freetz hielt (nur halt an einer anderen Stelle).
Da mir das Thema aber gar nicht wichtig genug ist, um darüber jetzt wieder einen Krieg zu beginnen, erkennt dann eben meine Implementierung nicht, wenn ein Freetz-Image ein festes Branding bei den Modellen vorgibt, bei denen es sich nicht mehr über das Urlader-Environment ändern läßt.
Die Version, die sich IN dem Freetz-Image befindet, erkennt das dann - dank dieses 040-Patches - wieder ... halt nur dann/solange, wie sie auch die ausgeführte ist, da sie in der aktiven Partition liegt.
Den "Schaden" haben letztlich die Freetz-Benutzer ... wenn es denn überhaupt einer ist. Ansonsten ist es nur eine Dokumentation, wie zwei Leute unbedingt aneinander vorbei arbeiten wollen. Nur werde ich da garantiert auch nicht einknicken, solange mir niemand eine wirklich plausible Erklärung liefert, warum es bei Freetz einer abweichenden Implementierung des festen Brandings bedurfte. Das bisher in dem PR Diskutierte war dazu nicht geeignet ...
Komplizierte Sache mit dem Branding... ich find das black-box Prinzip ganz gut, man muss ja nicht immer an allem herumschrauben wenn es nicht nötig ist (sieh auch area-size)
"Freetz-NG" und "Freetz ng-12345" ist doch was ganz unterschiedliches. Einmal der Name selbst und einmal halt aus dem Versionsstring.
Wenn ich nach deiner eMail frage, sagst du peter@pawn.net.ru. Da wäre es doch doof zu fragen ob die offizielle Schreibweise deines Vor- und Zunamens wirklich klein sei.
Es geht doch nur darum, zu wissen welcher Mod, Version und Fork. Das funktioniert so doch problemlos
EDIT: Ist die die unterschiedliche Schreibweise bei "Operating System" und "CPE OS Name" aufgefallen?
Einmal der Name selbst und einmal halt aus dem Versionsstring.
Ich sehe, Du hast es begriffen ... und mein Boot-Manager zeigt nun mal den Namen an und keine Versionen - das macht er nicht nur für Freetz so (bzw. eben nicht, wenn es um Versionen geht), sondern auch für YourFritz oder "modfs".
Steht der Name in einer Datei? Wenn ja, in welcher? Ich habe nicht umsonst gefragt (ganz am Beginn dieser Diskussion), was der Name des Projekts ist und wie der genau geschrieben wird. Das hätte ich auch Deinem Patch-Vorschlag entnehmen können und im Prinzip habe ich das auch getan ... da stand - iirc - eben "Freetz-NG".
Warum der Name nun auf einmal nicht mehr stimmen soll oder warum ich im Boot-Manager die Anzeige von "Name" auf "Version" umstellen sollte, leuchtet mir halt nicht ein.
Abgesehen davon, ist die Mail-Adresse
einfach nur ein saudummes Beispiel ... erst recht mit einer TLD "ru". Ich weiß nicht, was Du mir (oder anderen) damit sagen willst, aber es hätte sicherlich auch präzisere Beispiele gegeben.
Und der Unterschied zwischen einem Namen in einer Mail-Adresse und dem Namen in meinem Ausweis, meinen Zeugnissen oder sogar auf meinem Klingelschild (bei all diesen Gelegenheiten verwende ich nämlich meinen Namen und nicht meine E-Mail-Adresse), sollte ebenfalls augenfällig sein.
Ich weiß nicht, wie Du das machst ... aber ich schreibe meinen Namen im täglichen Leben tatsächlich - wie im Deutschen üblich - mit großem Anfangsbuchstaben in jedem seiner Teile. Auch mein Nickname ist "PeterPawn" und nicht "peterpawn" oder "pETERpAWN" oder irgendetwas anderes ... das ist halt der Unterschied zwischen einer Mail-Adresse und einem Namen. Willst Du diesen Unterschied erkunden, kannst Du ja mal versuchen, Dich hier als FDA77 anzumelden.
Und um auch das noch mal kurz festzuhalten ... ob am Ende "Peter.Pawn@yourfritz.de" und "peter.pawn@yourfritz.de" dasselbe Postfach adressieren, ist ausschließlich Sache des empfangenden Mail-Servers - so sieht es jedenfalls RFC 5321 vor:
The local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve
the case of mailbox local-parts. In particular, for some hosts,
the user "smith" is different from the user "Smith".
Was will ich damit sagen? Nichts weiter als: "You're wrong ... 'case' still matters and a name is a name and not an e-mail address - otherwise it would be called an e-mail address, too."
Ist die die unterschiedliche Schreibweise bei "Operating System" und "CPE OS Name" aufgefallen?
Ja, und?
Die Common Platform Enumeration hat mit (EDIT: echten Produkt-)Namen praktisch nichts zu tun: https://cpe.mitre.org/specification/
Oder bist Du jetzt auch der Ansicht, die Firma Microsoft hieße nur noch "microsoft" und das eingetragene Warenzeichen "Windows" wäre nun plötzlich "windows"?
Man muß nicht unbedingt Äpfel mit Pferdeäpfeln vergleichen ... zumindest nicht auf Basis einer Geschmacksprobe.
An Pferdescheisse lecken?
War auch nicht so ganz ernst gemeint ... und außerdem habe ich ja deutlich gemacht, daß man das eben besser nicht miteinander vergleicht. Der Geschmack ist da wohl nur ein Aspekt, anderes (wie Konsistenz, Geruch, Brennwert, etc.) sollte auch nicht wirklich hilfreich sein als Vergleich.