Lässt sich "setuuid" deaktivieren oder ignorieren

Begonnen von cocojambo, 23 Januar 2019, 13:19:05

Vorheriges Thema - Nächstes Thema

Wernieman

Ich habe das gefühlt, das einige als User denken und vergessen, das FHEM in der Freizeit als Hobby entwickelt wird. Schon die Unterscheidung "Entwickler" und "User" ist nicht nett (vor allem wenn dann Wörter wie "hohe" inkludiere werden.

Wenn man es besser machen will: Entweder auf altem Stand bleiben oder selber entwickeln. Nicht ohne Grund meckern.

Punk
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

betateilchen

Warum diskutiert ihr eigentlich immer noch? Den Zeitaufwand ist doch der Krampf hier überhaupt nicht wert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Pfriemler

Zitat von: Wernieman am 28 Januar 2019, 14:13:33
Ich habe das gefühlt, das einige als User denken und vergessen, das FHEM in der Freizeit als Hobby entwickelt wird. Schon die Unterscheidung "Entwickler" und "User" ist nicht nett (vor allem wenn dann Wörter wie "hohe" inkludiere werden.)
"hohe" habe ich hier nicht oder gekonnt über-lesen. Und es gibt schon eine Hierarchie in FHEM, aber die Wertung wird unterschiedlich interpretiert. Über den blutigen Anfängern, denen man schon den einen oder anderen Anfängerfehler verzeihen sollte, kommt eine dicke Schicht "Normal-User" wie ich sie nennen würde, die sich an den Vorzügen des freien Systems dankbar (doch wohl in der überwiegenden Mehrheit!) "bedienen", sich aber zunehmend (nach meinem Gefühl) davor ängstigen, in einer freien Minute mal ein Update zu machen, weil sie sich damit ganz schnell mal den Status quo zerschießen können - reell kein Problem dank der Backups, an denen man mittlerweile ja nur noch mit Vorsatz vorbei kommt, aber zusätzliche Arbeit dennoch. Und dann kommt die Schar der Leute, die sich hier fleißig quer durch alle Entwicklungen lesen und ihr FHEM schon dreimal aufgesetzt oder auf 4 oder sechs Geräte im Haus verteilt haben.

Und dann kommen die Entwickler, ohne die der ganze Laden hier nicht vom Fleck kommen oder oder überhaupt laufen würde. Die diskutieren unter sich und hüten den Unterbau von FHEM vor übereiligen Pfriemeleien. Und beides völlig zu recht. Nur habe ich bei manchen den Eindruck, dass sie ihr Wissen und den Durchblick stillschweigend bei der breiten Masse voraussetzen und mehr oder weniger schnell genervt klingen, wenn sich ein paar "Minderbemittelte" zu Wort melden. Und das führt dann manchmal zu so komischen Situationen wie hier, wo man sich quasi untereinander über ein seltsames Ansinnen des Themenerstellers (und sorry, ich finde es auch seltsam) lustig macht. Das war außerordentlich amüsant zu lesen, kann aber auch sehr demotivierend wirken. Nichtsdestotrotz sind alle Fragen aus meiner Sicht reichlich (von Entwicklern!) beantwortet und dazugelernt habe ich auch wieder.

Und ja: Wenn FHEM schlecht "dokumentiert" ist, sollte man das nie den Entwicklern anlasten. Was heißt "dokumentiert" ... an der commandref hatte ich bislang nur seltenst etwas auszusetzen und weiß damit umzugehen. An einen Wiki-Artikel stelle ich persönlich ganz andere Anforderungen. Jedem "Meckerer" die Erstellung eines erläuternden Wiki-Artikel ins Pflichtenheft zu schreiben verbessert die Qualität des Wiki auch nicht gerade - gerade die derer "vom Fach" sind dann doch durchweg die hilfreicheren. Nur wenn es die einen nicht können, die anderen sich nicht trauen und die welches es schon verstanden haben keine Zeit oder Lust mehr dafür haben, wird's nix. Ups, ich fühle mich angesprochen.

Aber das ist auch nicht das wirkliche Thema für mich. Hier ging es meines Erachtens von Anfang an nur um eine Neuerung weit hinter den Kulissen, die sicher >95% aller User unangekündigt "überrollt" hat - ein Aufreger nur weil etwas augenfällig (für den der mal in seine fhem.cfg schaut), von den vielen kleinen gestellten Schräubchen kriegen wir mitlaufendes Fußvolk sonst doch gar nichts mit. Und das ist auch gut so, sagte ich bereits. Und wenn man das verstanden hat, dann hütet man sich auch besser den Sinn der einen oder anderen Änderung voreilig in Frage zu stellen.

Sorry, wenn ich jetzt wem schon wieder Lebenszeit geklaut habe ... ich bin jetzt auch raus.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

connormcl

Zu den Stichworten Update und Dokumentation:

Es hat sich halt schon mehrfach gezeigt, dass nach einem Update irgendeine Komponente nicht mehr lief.  Dementsprechend vorsichtig ist man inzwischen mit Updates.

Um das handzuhaben gibt es drei Szenarien:

- kompletter Rollback auf den alten FHEM Stand
- geupdateten FHEM Stand belassen und - sofern kompatibel - Problembehaftete Subkomponenten auf Rollback
- alten FHEM Stand belassen bzw. kein Update machen und nur - sofern kompatibel - benötigte oder aktualisierte Komponenten updaten


Wenn ich jetzt aber garnicht weiss, wie die ganzen Abhängigkeiten sich gestalten, dann habe ich ein Problem und kann tagelang herumtüfteln.

Und genau dieses klang hier ja schon an: "Ohne die setuuids kannst du zukünftig kein Alexa oder GHome verwenden"... aber nur sehr spät und es klang etwas widerwillig, das preiszugeben.

Dementsprechend wäre es gut zu wissen:

- was macht eine neue Funktion
- wie schalte ich sie ab, wenn sie Probleme macht (sofern möglich)
- welche anderen Funktionen bauen auf sie auf oder werden zukünftig auf sie aufbauen

Stattdessen hört man:

- wir brauchen das unbedingt
- wo stört es dich denn; es stört doch nirgendwo
- wir sagen nicht wozu, sondern wir wissen, wir brauchen das und du verstehst es eh nicht

Und anstatt das einfach kurz und sachlich zu klären haben wir diesen Thread hier...

herrmannj

Zitat- was macht eine neue Funktion
Jedes device hat eine eindeutige Kennung die auch nach einem rename erhalten bleibt.
Zitat- wie schalte ich sie ab, wenn sie Probleme macht (sofern möglich)
falsche Frage. Falls(!) die Kennung Probleme verursacht bitte einen qualifizierten Bug report mit allen relevanten Informationen damit die Probleme beseitigt werden können.
Zitat- welche anderen Funktionen bauen auf sie auf oder werden zukünftig auf sie aufbauen
Jetzt: die Kennung wurde für Sprachassistenten eingebaut die intern davon Gebrauch machen
Zukünftig: werden weitere module diese Kennung intern benutzen um device unabhängig vom Namen identifizieren zu können

justme1968

nur mal so als hinweis:

der thread hat NICHT damit angefangen das jemand etwas neues gesehen hat, nicht wusste wozu es ist und dann gefragt hat wofür es gut ist.

sondern mit einem was soll der mist. ich will es nicht sehen. wie werde ich es wieder los. und das mehr als ein mal.

auf ersteres hätte es ganz sicher eine andere reaktion gegeben wie auf arrogantes  unqualifiziertes gemeckere.


und um gleich vorzubeugen: mit unqualifiziert meine ich nicht etwas nicht wissen und nachfragen.  ganz im gegenteil.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Wuppi68

och menno,

jetzt hat die ganze Diskussion mich so buschig gemacht, dass ich schon der Suche nach Windows Light bin - die ganzen Treiber und Funktionen will ich nicht mehr haben und brauchen werde ich die niemals
FHEM unter Proxmox als VM

connormcl

Zitat von: Wuppi68 am 28 Januar 2019, 22:46:00
och menno,

jetzt hat die ganze Diskussion mich so buschig gemacht, dass ich schon der Suche nach Windows Light bin - die ganzen Treiber und Funktionen will ich nicht mehr haben und brauchen werde ich die niemals

Es gibt Seiten und Foren, die sich mit einem Windows Light beschäftigen, wie du es haben möchtest...

Wenn aber hier schon UUIDs diskutiert werden, dann könnte man Linux UUIDs anführen....und die wurden parallel zum bestehenden System eingeführt und man hat freie Wahl, was man benutzt... by-path, by-device, by-uuid...

Der Fortschritt hat damit das bestehende ergänzt und muss aber nicht gezwungenermassen verwendet werden.

CoolTux

Zitat von: connormcl am 28 Januar 2019, 23:01:34
Es gibt Seiten und Foren, die sich mit einem Windows Light beschäftigen, wie du es haben möchtest...

Wenn aber hier schon UUIDs diskutiert werden, dann könnte man Linux UUIDs anführen....und die wurden parallel zum bestehenden System eingeführt und man hat freie Wahl, was man benutzt... by-path, by-device, by-uuid...

Der Fortschritt hat damit das bestehende ergänzt und muss aber nicht gezwungenermassen verwendet werden.

Und Du merkst nicht mal wie Du Dich da wiedersprichst.
Denn by-uuid ist immer da. Du kannst es nicht deaktivieren, du kannst es nur nicht benutzen.
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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

connormcl

Zitat von: CoolTux am 28 Januar 2019, 23:05:07
Und Du merkst nicht mal wie Du Dich da wiedersprichst.
Denn by-uuid ist immer da. Du kannst es nicht deaktivieren, du kannst es nur nicht benutzen.

Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.

Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.

Frank_Huber

Zitat von: connormcl am 28 Januar 2019, 23:25:20
Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.

Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.
Da reicht es btw wenn man beim raspbian eigenen "sd card copier" vergisst ne neue uuid vergeben zu lassen.
Schon sucht man tagelang nen Fehler wo keiner ist......

Gesendet von meinem Doogee S60 mit Tapatalk


CoolTux

Zitat von: connormcl am 28 Januar 2019, 23:25:20
Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.

Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.

OK hast Recht. Man kann unter Linux (nicht als default) die uuid manipulieren.
Ich verstehe aber immer noch nicht, und das würde ja nun schon oft genug hinterfragt, was genau stört Dich an der uuid in FHEM?
Funktioniert etwas nicht auf Grund dieser id? Kannst Du in FHEMWEB etwas nicht lesen weil die ID die Ansicht kaputt macht? Fühlst Du Deine Privatsphäre bedroht wegen dieser ID?
Bitte sage mir/uns was genau Dein Problem ist. Ansonsten wird das hier wieder so ein endlos länger Thread ohne das Die geholfen wird Dein Problem zu lösen. Du hast doch ein FHEM spezifisches Problem wegen der uuid oder?
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://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Wernieman

Die Festplatten UUID ist übrigens ein guter Vergelich.

Jede Linux-Frestplatte hat eine, mann kann sie manipulieren (in FHEM doch auch?) aber nicht löschen. Eine gelöscht UUID ist eine "genullte UUID", also immer noch da.

Also genau das gleich, man kann es nutzen, aber nicht lösche ..... wenn man es löscht, wird es neu angelegt ....
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

marvin78

Es geht hier doch längst nicht mehr um die UUID. Mein Tipp: Lasst es einfach gut sein.

retikulum

Meine Idee hierzu wäre (und das würde es um einiges übersichtlicher machen):
Die setuuid nicht unter jedes Device schmieren, sondern in eine eigene Config.
So wie ich (und wahrscheinlich ein paar andere) fhem.cfg aufgeteilt haben in mehrere Configs.

Frage: kann ich mit Fhem Bordmitteln die uuids irgendwie exportieren? Sonst muss ichs via Texteditor erledigen...