Autor Thema: fhem.pl: lustiger Namespace-Bug  (Gelesen 1525 mal)

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #15 am: 24 März 2020, 10:25:07 »
so langsam nervt mich diese Klugscheißerei...

Das ist schon in Ordnung. Da wir beide echte Männer sind, wirst Du mit der Klugscheißerei genauso gut zurechtkommen wie ich mit der Ignoranz.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5497
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #16 am: 24 März 2020, 10:34:30 »
...
Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?
...
Kann ich für mich beantworten: ich versuche das zu supporten was bei den usern vorhanden ist - soweit das möglich ist.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 24242
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #17 am: 24 März 2020, 10:42:45 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.
Ich würde aber auch erstmal den Weg gehen die Modulautoren an zu sprechen. Eben von unten nach oben arbeiten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
Mein Dokuwiki:
https://tuxnetwiki-tuxnet.ddns.net

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16164
  • s/fhem\.cfg/configDB/g
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #18 am: 24 März 2020, 10:51:38 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.

Das finde ich auch grundsätzlich gut.

Aber bitte nicht auf die hier praktizierte Art und Weise, dass man einer großen Gemeinschaft von Entwicklern versucht einzureden, sie hätten in den vergangenen 13 Jahren alles falsch gemacht, was falschzumachen ging. Und genau so empfinde ich das im Moment.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #19 am: 24 März 2020, 11:05:44 »
Ich finde die Idee gut eine Software "besser" zum machen. Auch ohne offensichtliche Fehlermeldungen.
Ich würde aber auch erstmal den Weg gehen die Modulautoren an zu sprechen. Eben von unten nach oben arbeiten.

Klar - warum nicht? Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".

Aber dann muss man sich auch über Folgendes im Klaren sein:

Das gegenwärtige Entwicklungsmodell "jeder Modulautor/Maintainer ist für sein Modul verantwortlich" ist auf der einen Seite verständlich - wer will schon Support/Verantwortung für ein Modul übernehmen wenn ihm einer von der Seite reingrätscht - es bürdet aber auch den Modulautoren eine größere Last auf, denn dann ist eigentlich jeder für den gesamten vertikalen Stack des Moduls (Funktionalität, Fehlerfreiheit, Support, Security, ...) verantwortlich. Das ist wesentlich mehr als üblich ist.

Auf der anderen Seite blockiert man dann "Leute wie mich" die horizontal über den Code gehen (Für alle Module: xxx). Für jemanden, der z.B. Security, oder coding Guidelines oder Effizienz auf der Fahne hat, ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".

Ergo: Bottom-Up Vorgehensweise über die Modulautoren, bin ich dafür, aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".

Dann kann man gleich ein Board "Security" und "Effizienz" aufmachen. Bei Effizienz kann ich auch noch ein wenig mitreden, bei Security gibt es definitiv bessere Spinner als mich.

Und ja, @betateilchen:

Es wurde definitiv nicht alles falsch gemacht in den letzten 13 Jahren. FHEM funktioniert ja.
Aber es gibt viele Probleme und nach 13 Jahren, 500 Modulen und xxx Autoren ist man vor so Dingen wie "Projektblindheit" nicht nur nich gefeit, man ist dafür geradezu anfällig.

Online mahowi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1173
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #20 am: 24 März 2020, 11:14:57 »
Ne - ehrlich, ist denn irgendwo definiert was man sich alles "antun will"? Ich lese "bei all den OS, Perl, MOdul"-Kombinationen. Nirgends habe ich gelesen was so die älteste Perl Version ist die man "unterstützt". 5.8.x? 5.6? Srsly?
Laut Statistik gibt es noch Perl-Installationen bis runter zu 5.10, wobei das gerade mal je 5 Installationen mit 5.10 und 5.12 sind.

Da gibt es wohl auch noch etliche Raspis, die seit Jahren unverändert mit alten OS laufen:
  • Wheezy: 5.14 (299 Installationen)
  • Jessie: 5.20 (894)
  • Stretch: 5.24 (2139)
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 24242
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #21 am: 24 März 2020, 11:25:13 »
Klar - warum nicht? Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".

Aber dann muss man sich auch über Folgendes im Klaren sein:

Das gegenwärtige Entwicklungsmodell "jeder Modulautor/Maintainer ist für sein Modul verantwortlich" ist auf der einen Seite verständlich - wer will schon Support/Verantwortung für ein Modul übernehmen wenn ihm einer von der Seite reingrätscht - es bürdet aber auch den Modulautoren eine größere Last auf, denn dann ist eigentlich jeder für den gesamten vertikalen Stack des Moduls (Funktionalität, Fehlerfreiheit, Support, Security, ...) verantwortlich. Das ist wesentlich mehr als üblich ist.

Auf der anderen Seite blockiert man dann "Leute wie mich" die horizontal über den Code gehen (Für alle Module: xxx). Für jemanden, der z.B. Security, oder coding Guidelines oder Effizienz auf der Fahne hat, ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".

Ergo: Bottom-Up Vorgehensweise über die Modulautoren, bin ich dafür, aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".

Dann kann man gleich ein Board "Security" und "Effizienz" aufmachen. Bei Effizienz kann ich auch noch ein wenig mitreden, bei Security gibt es definitiv bessere Spinner als mich.

Und ja, @betateilchen:

Es wurde definitiv nicht alles falsch gemacht in den letzten 13 Jahren. FHEM funktioniert ja.
Aber es gibt viele Probleme und nach 13 Jahren, 500 Modulen und xxx Autoren ist man vor so Dingen wie "Projektblindheit" nicht nur nich gefeit, man ist dafür geradezu anfällig.

Ich denke mal was Deine Arbeit in Form von Empfehlungen an geht ist klar das da keine diffs nötig sind. Du musst aber auch damit leben das einige Autoren sagen werden interessiert mich nicht. Ist dann halt so.
Ansonsten liegt es an jedem Autor selbst Deine Empfehlungen um zu setzen.
Die Idee mit dem zusätzlichen Board finde ich gut. Das ständige PM schreiben ist anstrengend und nicht sehr transparent für die anderen.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
Mein Dokuwiki:
https://tuxnetwiki-tuxnet.ddns.net

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21953
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #22 am: 24 März 2020, 11:32:39 »
Zitat
Dann würde ich vorschlagen, man macht in "Entwicklung" ein Board "Perl Ecke" auf, macht mich dort zum Mufti, damit ich meine Gewalt- und Allmachtsphantasien ausleben kann  ;) und dann muss ich nicht individuell via PMs "supporten".
Ich habe damit kein Problem, will aber nicht ganz alleine entscheiden => bitte kommentieren.
Ich bin auf die Reaktion der Autoren auf die Aenderungen gespannt, und noch skeptisch.

Das gegenwertige Entwicklungsmodell ist das Resultat von (schiefgelaufenen) Experimenten, wie alles ein Kompromiss, nicht problemlos, aber ich will auch nichts daran aendern: mir ist ein potentieller Fehler im Modul lieber, als ein verwaistes Modul. Keine Regel ohne Ausnahme: z.Bsp. habe ich bestimmte Code-Tags in der Doku nach angemessene Wartezeit selbst korrigiert.

@mahowi: die Zahlen aus den Statistiken sind nach meiner Erfahrung etwa mit 4 zu multiplizieren, um die Gesamtzahl zu erhalten. Die Fehlerrate ist bei kleinen Werten hoch, und was Gesamtzahl bedeutet (installiert aber brauche ich nicht mehr oder mein Leben haengt davon ab) ist schwammig.

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #23 am: 24 März 2020, 11:34:05 »
Kann ich für mich beantworten: ich versuche das zu supporten was bei den usern vorhanden ist - soweit das möglich ist.

Das ist natürlich eine geradezu übermenschliche Serviceeinstellung.

Aber da auch Deine Resourcen nicht unendlich sind... siehe die Statistiken auf die mahowi erinnert hat:

Über 99% (99,08%) der Installationen sind Linux. Wegen dem 1% sollte man sich nicht zurückhalten lassen.
Und das tut man, wenn man das in die Kombinatorik (alle Kombinationen von OS, Perl, Modulversion, ...) einfliessen lässt

Wenn man ein wenig flexibel ist, kann man auch noch die MacOS und *BSD Leute in Boot nehmen.
Die 0.5% Windows User... Sorry. 6.x last version for you.

Perl Version. 5.10+ ... na wenigstens etwas. defined-or und named captures. Hurra!
Ab 5.24 wurde Perl erheblich schneller
Ab 5.28.1 gibt es - derzeit - keine bekannten Security Bugs.

edit:

Für Windows user schlage ich folgende Migrationspfade vor:

1) https://docs.microsoft.com/en-us/windows/wsl/install-win10

"Windows Subsystem for Linux". Das ist praktisch ein Linux - aus Programmsicht sowieso. Mit ganz ganz wenigen Einschränkungen. Man kann z.B. nicht direkt die GPU aus WSL ansprechen (PCI-pass through) und ähnliche Speckwürfel. Für FHEM sind die Einschränkungen irrelevant.

2) Cygwin (https://www.cygwin.com/)

Ähnlich, aber älter. Ich lese gerade die Perldeltas im Detail durch und sehe, dass Cygwin support mindestens in Perl 5.16 nochmal auf Vordermann gebracht wurde.

=> Selbst die paar wenigen Unglücklichen, die Windows haben und behalten wollen, müssen nicht komplett im Regen stehengelassen werden.
« Letzte Änderung: 24 März 2020, 15:04:58 von RichardCZ »

Offline viegener

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3874
    • Meine Seite im fhemwiki
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #24 am: 24 März 2020, 16:39:35 »
Das ist natürlich eine geradezu übermenschliche Serviceeinstellung.

Aber da auch Deine Resourcen nicht unendlich sind... siehe die Statistiken auf die mahowi erinnert hat:

Über 99% (99,08%) der Installationen sind Linux. Wegen dem 1% sollte man sich nicht zurückhalten lassen.
Und das tut man, wenn man das in die Kombinatorik (alle Kombinationen von OS, Perl, Modulversion, ...) einfliessen lässt

Wenn man ein wenig flexibel ist, kann man auch noch die MacOS und *BSD Leute in Boot nehmen.
Die 0.5% Windows User... Sorry. 6.x last version for you.


Nö!

Ich bin ganz bei herrmannj - wenn ich helfen kann frage ich nur nach der perl- oder os-version um mehr Infos zu bekommen, ich will ohne zwingenden Grund niemanden zum Update oder gar zum Umstieg (!) überreden. 1% Benutzer anderer OS plötzlich auszugrenzen (warum eigentlich ?) wäre für mich komplett die falsche Richtung. Wenn jemand es auf CP/M zum laufen bekommen wollte, mach doch, oder auch zLinux - los doch.

Auf der anderen Seite wäre es wichtig zu modernisieren und auch kritische Stellen anzupacken - aber bitte nicht unter der Prämisse andere abzuschrecken oder auszugrenzen!
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3337
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #25 am: 24 März 2020, 16:48:37 »
ist es schon eine Zumutung ihm zu sagen "Ja mach mal, schick den Modulautoren dann die diffs".
--- snipp ---
aber es gibt - wenn überhaupt - eine Holschuld seitens der Modulautoren, nicht eine Bringschuld seitens der "Horizontalen".
a. erwarte ich gar, ich denke den meisten reicht eine einfache Info / Beschreibung wie jetzt hier bei POSIX
b. ich habe kein Problem damit irgendwo etwas abzuholen, dafür muß ich aber erst einmal wissen das es überhaupt etwas zum Abholen gibt.
Ob es dann in einem meiner Fällel zutrifft sehe ich dann ja schon, d.h. bringen muß mir niemand etwas, sondern lediglich einigermaßen verständlich das Problem schildern. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #26 am: 24 März 2020, 18:01:05 »
Nö!

Ich bin ganz bei herrmannj - wenn ich helfen kann frage ich nur nach der perl- oder os-version um mehr Infos zu bekommen, ich will ohne zwingenden Grund niemanden zum Update oder gar zum Umstieg (!) überreden. 1% Benutzer anderer OS plötzlich auszugrenzen (warum eigentlich ?) wäre für mich komplett die falsche Richtung. Wenn jemand es auf CP/M zum laufen bekommen wollte, mach doch, oder auch zLinux - los doch.

Versuch' es doch mal andersherum zu sehen. Du bremst 99% der Leute aus, weil Du das 1% Minderheit "nicht enttäuschen willst".
Man kann es noch heftiger sehen. Angenommen man fühlt sich ihnen verpflichtet und sie wissen das, dann sind diese 1% lethargischen Updatemuffel eigentlich Egoisten, die an Entwicklerkapazitäten und "verpasstem Fortschritt für den Rest" schmarotzen.

Ich formuliere es bewusst wenig diplomatisch um auch mal ne andere Sichtweise zu präsentieren.

Und für dieses 1% hast Du dann 20% Aufwand.  Gefühlt (hallo Herrmann) eher mehr, weil Du den Aufwand gar nicht realisiert bekommst (Du bekommst von dem 1% auch nicht die Tests etc.)

Die Frage "warum eigentlich?" bestimmten Support fallenzulassen zeugt von Unkenntnis der ganzen Diskussion der letzten 4 von mir geöffneten Threads - oder von schlechtem Gedächtnis.

Es gibt hier weder die Kapazitäten, noch die Skills, noch den Willen CP/M, zOS, BeOS, Hurd, etc. Support zu realisieren. Ist komplett illusorisch. Ich sagte ja, ich lese mir gerade im Detail die perldeltas durch. Da steht bei 5.16 z.B.

Platforms with no supporting programmers
These platforms will probably have their special build support removed during the 5.17.0 development series.

BeOS
djgpp
dgux
EPOC
MPE/iX
Rhapsody
UTS
VM/ESA


Bada Bum. Das ist ganz normal Leute. Früher gab es bei Supercomputern auch noch Windows, Schaut euch die Top500 Liste heute an. Support wird auch in Open Source Umgebungen fallengelassen - nicht nur in kommerziellen Umgebungen - wenn Kosten/Nutzen jenseits von gut und böse sind..

Und dieses "da bin ich ganz bei Herrmann". Hermann ist derjenige, der ziemlich schnell zur Stelle ist wenn es darum geht zu zeigen wie aufwändig doch jede Codeänderung ist, weil das ja einen irre Rattenschwanz an Tests und Validierungen in allen möglichen Umgebungen nach sich zieht. Ziehen würde. Den man ja nicht mal so eben hinbekommt. Also macht man am besten nix.

Zitat
Auf der anderen Seite wäre es wichtig zu modernisieren und auch kritische Stellen anzupacken - aber bitte nicht unter der Prämisse andere abzuschrecken oder auszugrenzen!

Das ist das "wasch mich aber mach mich nicht nass", was ich schon recht zu Beginn mal hier fallengelassen habe.


Deine empfundene richtige Richtung "los doch, mach doch" geht nur unter der Prämisse, dass die FHEM Community plötzlich 20-30 perlporter-cracks aus dem Hut zaubert. Leute, die es einfach nicht real-existierend gibt.

Der Unterschied besteht offensichtlich darin, was man als "zwingenden Grund" sieht. Keiner wird zur Modernisierung seiner Infra gezwungen. Aber keiner kann doch erwarten, dass seine ungewartete Uralt-Infra bis zum St. Nimmerleinstag supported wird.

Wer halt noch ein Windows mit Perl 5.10 betreibt - fein - aber dann ist für den halt eine FHEM 6.x die letzte Version. Er muss ja nicht updaten - er kriegt halt dann nix neueres mehr.

---

Aber ok, diese ganze Diskussion geht komplett am eigentlichen Thema vorbei, Momentan würde es mir ja schon reichen, wenn ich helfen könnte den Perl code von FHEM vom Niveau "Jahrtausendwende" aufs Niveau 2007 zu hieven. Das Abschneiden alter Zöpfe war eigentlich nur ein Vorschlag um den Entwicklern die Füße von ein paar Ketten mit Eisenkugeln dran freizumachen.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5497
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #27 am: 24 März 2020, 18:13:41 »
Zitat
Gefühlt (hallo Herrmann) eher mehr
Hallo Richard :)

Nein, eigentlich nicht. Ich versuche(!) beim Design bereits darauf zu achten dass ich keine Abhängigkeiten habe und das ich Konstrukte vermeide von denen ich annehmen kann das sie systemspezifisch sind.

Dogmatisch geht das sowieso nicht: bei einem aktuellen Modul "muss" ich 5.18 voraussetzen. Warum? Ich habe zu spät gemerkt das "lexical sub" erst ab 5.18 funktionieren. Hätte ich es früher erkannt dann hätte ich das anders geschrieben und "nu isses eben so" :)

Dann kommen trotzdem die Perl-Versionsspezifischen-Sonderlocken: https://forum.fhem.de/index.php/topic,109413.msg1034136.html#msg1034136

Problem? Nö. Hab's gefixt. Hätte natürlich auch einfach 5.24 vorschrieben können - aber warum sollte ich ? So sind alle happy.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline RichardCZ

  • Tester
  • Full Member
  • ****
  • Beiträge: 268
    • Experimenteller FHEM Fork (GitLab Geknödel)
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #28 am: 24 März 2020, 18:38:26 »
Problem? Nö. Hab's gefixt. Hätte natürlich auch einfach 5.24 vorschrieben können - aber warum sollte ich ? So sind alle happy.

Naja. Ich bin so happy mit dem Code nicht. Ein bedingtes Morphium-Pflaster sehe ich jetzt nicht als "Fix".

Aber kein Problem - ich werde damit psychisch schon irgendwie fertig.  ;)

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5497
Antw:fhem.pl: lustiger Namespace-Bug
« Antwort #29 am: 24 März 2020, 18:52:20 »
Naja. Ich bin so happy mit dem Code nicht. Ein bedingtes Morphium-Pflaster sehe ich jetzt nicht als "Fix".
Wenn man das besser machen kann (ohne Einschränkungen zu produzieren;)) bin ich für alles offen.
Zitat
Aber kein Problem - ich werde damit psychisch schon irgendwie fertig.  ;)
so siehts aus ;)
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse