Perl Readonly / Debian

[Wzut]

Readonly wird vermutlich bei dem meisten direkt verfügbar sein, trotzdem gibt es für Debian/Raspbian noch ein extra Paket :

libconst-fast-perl

facility for creating read-only scalars, arrays, and hashes

Const::Fast is a perl module for creating read-only scalars, arrays, and hashes. It enables you to set a variable to the given value and subsequently make it readonly. Arrays and hashes will be made deeply readonly.
This module uses the builtin readonly feature of perl, making access to the variables just as fast as any normal variable without the weird side-effects of ties.

Vllt kann ja Richard was Genaues zu "weird side-effects of ties" sagen. IMHO hatte ich da gestern auch einen Abschnitt in deutsch der darauf Bezug nahm, finde ihn nun leider nicht mehr.

[mahowi]

Readonly gehört übrigens leider auch nicht zum Core, wie ich eigentlich vermutet hatte. Für Debian muß man das Paket libreadonly-perl installieren.

[RichardCZ]

Readonly wird vermutlich bei dem meisten direkt verfügbar sein, trotzdem gibt es für Debian/Raspbian noch ein extra Paket :
Vllt kann ja Richard was Genaues zu "weird side-effects of ties" sagen. IMHO hatte ich da gestern auch einen Abschnitt in deutsch der darauf Bezug nahm, finde ihn nun leider nicht mehr.

Richard würde Readonly nehmen und "weird side-effects of ties" in einer Doku, die 2013 das letzte Mal aktualisiert wurde, nicht so viel Gewicht beimessen.
Das bedeutet nicht, dass Richard keinen Respekt vor Leon Timmermans hätte und den gemeinsam getrunkenen Mengen an Bier kein Gewicht beimessen würde.

Es ist natürlich im FHEM-Kontext ein ziemlich häretisches Konzept, aber 2013 ist jetzt auch schon ne Weile her.

Readonly mit installiertem Readonly::XS ist die beste Lösung AFAIK, wobei man mit dem Pure-Perl Readonly zwar langsamer fährt (*) aber für den Code ist das transparent (man macht immer nur "use Readonly;"). Jetzt noch ein Fass mit einem anderen Modul aufmachen fände ich kontraproduktiv.

Die Tatsache, dass aber Readonly/Readonly::XS nicht zum CORE gehört ist allerdings sehr bitter.

(*) für FHEM-Belange immer noch mehr als schnell genug.

[Sidey]

Die Tatsache, dass aber Readonly/Readonly::XS nicht zum CORE gehört ist allerdings sehr bitter.

Weil das debian Paket für readonly nicht als Anbängigkeit im FHEM Paket enthalten ist, scheue ich mich noch ein wenig vor dem Einsatz.


Grüße Sidey

[KernSani]

Weil das debian Paket für readonly nicht als Anbängigkeit im FHEM Paket enthalten ist, scheue ich mich noch ein wenig vor dem Einsatz.


Grüße Sidey

Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...

[RichardCZ]

Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...

Das sind schon interessante Entscheidungsprozesse hier...

Hätte man da nicht einfach betateilchen, oder wer auch immer für die Debian-Pakete verantwortlich ist, fragen können?
Also ich bin zumindest gewohnt, dass man in einem Team zusammenarbeitet und nicht nebeneinander her.

Ok, ich knicke Debian-Paketierung für HoBo ohnehin komplett
https://gl.petatech.eu/root/HomeBot/-/commit/3495444f06b3587b00fcba0dd26c51c5641bb701
-> https://appimage.org/

Aber in meinem 1-Mann Team reicht es ja wenn ich Selbstgespräche führe.

[zap]

Habe mich gerade genau aus diesem Grund auch gegen Readonly entschieden...

Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.

Es soll ja Leute geben, die FHEM auf Nicht-Debian-Systemen betreiben (andere Linux Derivate, MacOS oder sogar Windows). Als FHEM Nutzer sollte man wissen, wie man eventuell fehlende Module nachinstalliert.

Auch unter Debian kann man z.B. cpan verwenden, um Module zu installieren. Es muss also nicht zwingend das lib/deb Paket sein.

[Sidey]

Hi RichardCZ,

Du hast schon Recht, ich könnte fragen.
Dafür ist es aber sicher interessant, ob das dann auch mehrere nutzen oder ob ich der einzigste bin.

Bei dem Update Vorgehen bringt das aber der installierten Basis leider recht wenig, denn die machen ja ein Fhem Update mit dem Ergebnis, dass das Modul bestenfalls eine Meldung im Log hinterlässt, wieso es jetzt nicht mehr funktioniert und dass man doch bitte das Readonly Modul installiert.

Möchte man seine Anwender nicht mehr strapazieren, als unbedingt nötig, kann man auch erst einmal nur diese Warnung ausgeben und alles so belassen wie es ist.

Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.

Ich bin der Meinung, wenn jemand das Debian Paket installiert, dann sollten alle Abhängigkeiten die für die Funktion notwendig sind auch mit installiert werden.
Alle die auf anderen Wegen installieren, die haben ohnehin viel Handarbeit dir durch die META Daten etwas durchsichtiger werden

Grüße Sidey

[RichardCZ]

Möchte man seine Anwender nicht mehr strapazieren, als unbedingt nötig, kann man auch erst einmal nur diese Warnung ausgeben und alles so belassen wie es ist.

Weisst Du eigentlich warum so ein Steak aus Argentinien oder Uruguay so gut ist?
Weil da hinter der Herde Rindviecher unermüdlich ein paar Gauchos herreiten und diese vor sich treiben.

Man kann natürlich immer "alles so belassen wie es ist", aber dann muss man auch mit Kommentaren wie diesem hier leben

https://blindfuchs.de/smarthome/91-openhab2-smarthome-findungsphase

FHEM war leider ein ähnlich negatives Erlebnis. Während die Verbindung mit den Komponenten problemlos funktionierte und eine Übersicht über diese einfach und zielführend geboten wurde, fehlten mir die interessanten weiteren Möglichkeiten. Die Basis von FHEM war deutlich in die Jahre gekommen, die Unterstützung für weitere Komponenten nur schwach, eine schicke Bedienoberfläche suchte man vergebens und - und das ist der entscheidende Teil - die Möglichkeiten komplexere Automatisierungsregeln zu definieren, waren bescheiden. Kurz gesagt, FHEM konnte meine Anforderungen nicht erfüllen.

Und das war 2017 (eine Situation aus 2014 beschreibend). Nun könnte natürlich der FHEM e.V. eine Sonderkommission gründen, die das mal ausdiskutiert und zu dem Schluss kommt, dass das ja alles nicht stimmt (oder man lässt den asdasd-Geheimagenten auf die Kommentare los), aber mir dünkt, dass davon FHEM nicht besser wird.

[KernSani]

Wenn Du die Verwendung eines Perl Moduls von dem Vorhandensein einer Abhängigkeit im Debian Paket abhängig machst, wird die Luft schnell dünn werden.

Habe mich falsch ausgedrückt. Mir ging es generell um die Nachinstallation. Egal ob lib oder cpan. Ich persönlich halte den Nutzen von Readonly für eher überschaubar und es gibt Alternativen im Core.


Kurz, weil mobil....

[rudolfkoenig]

Verstehe ich den Vergleich richtig: Die Programmierer (als Gauchos) muessen die Benutzer (als Rindviecher) unermuedlich vor sich hertreiben, damit sie richtig gut werden?

Vermutlich sehe ich noch nicht das grosse Bild, deswegen interessiert mich, welche der o.g. Kritikpunkte das Zwingen des Benutzers zum Nachinstallieren dieses Perl-Moduls loest.

[RichardCZ]

Verstehe ich den Vergleich richtig: Die Programmierer (als Gauchos) muessen die Benutzer (als Rindviecher) unermuedlich vor sich hertreiben, damit sie richtig gut werden?

Das kann man so verstehen. Ich hätte natürlich auch den Vergleich mit dem Kobe-Steak bringen können, bei denen sich Phasen von Aktivität mit Phasen von Faulheit abwechseln und so für eine Fleisch/Fett Marmorierung sorgen, die auch ganz gut ist - Geschmacksfrage. Man könnte es auch in der ersten Ableitung so verstehen, dass ich der Gaucho bin und das Blut der Entwickler in Wallung bringe. 

Unterm Schlussstrich bleibt die Erkenntnis, dass ein Open-Source Projekt auf Userseite nicht nur ein Nehmen, sondern auch ein Geben sein sollte.
Was hat ein OSS Projekt von Usern, die nur kostenlos nehmen, am besten nix (oder so wenig wie möglich) machen wollen und maulen ("muuuh") wenn
sie mal ein wenig traben sollen? Oder maulen ("muuuh!"), wenn das veralternde Projekt bestimmte Features nicht bietet?
Das ist doch - für die Entwickler! - wieder so eine schachmatt Situation. In der ist FHEM - derzeit - immer noch.

Vermutlich sehe ich noch nicht das grosse Bild, deswegen interessiert mich, welche der o.g. Kritikpunkte das Zwingen des Benutzers zum Nachinstallieren dieses Perl-Moduls loest.

Ja, die Abstraktionsfähigkeit könnte besser sein, dann würde man

• sich von dieser konkreten Situation mit diesem konkreten Perl Modul lösen und darüber nachdenken wie man beim Update ein Modul zum User bekommt
• allgemein die Denke "da ist eine Mauer da kann ich nicht durch oder muss irgendwie aussen rum" durch "muss da die Mauer sein?" ersetzen

Ich bin tatsächlich der Ansicht, dass sich die Geschwindigkeit der Herde nicht den Langsamsten, sondern der Mehrheit anzupassen hat. Die Langsamsten beissen bekanntlich die Hunde bzw. fressen die Löwen. Ein bischen Schwund ist immer. Im Gegenzug schliessen sich starke Individuen auch lieber einer gesunden Herde als einer tristen Population an - sagt National Geographic.

Ich bringe solche Sachen nur deswegen derart süffisant (und nehme in Kauf, dass das jemanden nervt), weil mich dieses "welche der o.g. Kritikpunkte ... loest das konkret?" ebenfalls stark nervt. Genauso gut könnte man auch fragen "Welchen Schalter müssen wir konkret umlegen um das Sonnensystem zu besiedeln?". Da schwingt für mich eine Menge Kurzsichtigkeit mit.

@Rudolf: Präsentier' doch mal - spaßeshalber - ne Roadmap für FHEM.



Und damit wir mal wieder zum Konkreten zurückkehren: Readonly ist ein Perl-only Modul

https://metacpan.org/source/SANKO/Readonly-2.05/lib/Readonly.pm

das könnte man mitliefern. ("muss da die Mauer sein?")
Dann tut das für den User. Wenn er es noch besser will, wird er sich Readonly::XS installieren.

[Sidey]

An das mit ausliefern von Perl Modulen habe ich auch schon mehrmals gedacht.
Aktuell ist es ja leider immer ein Hemmschuh ein Modul von CPAN zu nehmen, weil es manuell installiert werden muss.

Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

So wie ich das einschätzen sind da zwei Dinge zu klären:
1. Lizenzbedingungen
2. Maintainer Frage

Ich hatte ja auch vor einiger Zeit vorgeschlagen, dass wir das Update Modul anpassen, so dass man Verweise auf andere Installationsquellen einbauen kann.
Leider hielt sich die Begeisterung in Grenzen und der Patch verweilt derzeit auf meiner Platte.

Durch das Nachladen würde ich annehmen, dass es einfacher ist die jeweiligen Lizenzbedingungen des CPAN Modules einhalten zu können. Die Maintainer Frage stellt sich dann auch nicht, weil es so nicht im SVN hinterlegt werden müsste.

Grüße Sidey

[Icinger]

Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

Wenn die Module richtig gewartet sind, könnte das Installer-Modul ja das Nachinstallieren von CPAN übernehmen.

Müsste man halt
1) Die Meta-Daten der Module pflegen
2) Sicherstellen, dass bei der ersten Definition eines Moduls der Installer drüberschaut, ob vlt. etwas noch zu installieren ist.

lg, Stefan

[RichardCZ]

Viel einfacher wäre der Spaß doch, wenn wir CPAN Module mit verteilen könnten.

Deswegen ich ja mit GLeichnis "Warum muss die Mauer da sein?", weil Rudolf explizit gesagt hat, im Repo
sollen keine CPAN Module sein.

Es ist ja auch nicht schwarzweiß das Ganze:

1. Einige Module können wir nicht mitliefern, weil die erstmal compiliert werden müssten.
2. Irgendjemand muss das ja dann auch warten, sonst haben "wir" im Repo eine Asbach-Uralt


ad 1) Dann eben nur Perl-only, besser als nix
ad 2) Habe ich euch eigentlich schon die Geschichte von den Janitors erzählt?