ich habe zu der ganzen sache eine eigentlich schon fast philosophische grundhaltung.
1. es ist ein großer fehler den benutzer oder admin ständig mit irgendwelchen meldungen zu bombardieren wie "achtung, wollen sie das wirklich...." oder "diese einstellung könnte ein sicherheitsrisiko darstellen....." oder "es erfolgt ein zugriff von xyz auf uvw mit den rechten abcd, wollen sie das gestatten? ...". der ansatz ist vielleicht gut gemeint, weil man den anwender durch die hinweise und fehlermeldungen zur richtigen konfiguration führen will. was ist aber die folge davon? es wird nach dem button "OK", "WEITER" oder "JA" gesucht, die meldungen werden nicht mehr gelesen.
2. graphische konfigurationsoberflächen zur konfiguration von serverprozessen oder sicherheitseinstellungen verführen den anwender dazu einfach wild irgendetwas anzuklicken, bis endlich das passiert was er möchte. wie viele scheunentore er dabei geöffnet hat kann er nicht wissen und es ist ihm eigentlich auch egal.
hauptsache funzt. die graphische oberfläche gibt ihm auch die macht dazu solchen unsinn zu treiben.
"melde dich als root an, schalte die firewall ab und setz die rechte auf 777, dann funzt es"
wie sollte man es also machen.
aus meiner sich wäre es sinnvoll alle wichtigen serverprozesse über textdateien zu steuern, die möglichst kryptische befehle und codewörter enthalten. sollte die einstellung fehlerhaft sein, so muss der serverprozess die arbeit verweigern, eine kurze fehlermeldung und der verweis auf die logdateien und die dokumentation sei erlaubt. ein sinnloses probieren ist dammit zwecklos, denn es gibt einfach zu viele kombinationsmöglichkeiten für alle ascii-zeichen. die wahrscheinlichkeit eine sinnvolle kryptische buchstabenkombination ohne hintergrundkenntnisse zustande zu bekommen ist so wahrscheinlich, wie die möglichkeit, dass " 100000 affen, wenn sie 100000 jahre sinnlos auf 1000000 schreibmaschinen herumtippen, letztendlich shakespeare herausbekommen"
hmmmm, kommt mir irgendwie bekannt vor, ich glaube das gibts schon
was ist hier die konsequenz?
wer von anfang an nicht vorhatte eine anleitung oder dokumentation zu lesen, der gibt gefrustet auf und schimpft über diesen mist.
wer sich mit dem problem auseinandersetzt und des lesens mächtig ist, der hat eine gute chance das teil zum laufen zu bekommen. nebenbei erfährt er aus der dokumentation was das programm sonst noch so kann und kann es sich für später merken (sag mal, wie bekommt man denn sowas ....... hin, ah ja, da kannst du dings nehmen .....)
wie ist die lage denn nun, wenn ich das system verkaufen will? es soll kohle rollen, die aktionäre wollen kohle sehen .........
ich muss zusehen, dass es funktioniert, wie ist erst einmal völlig egal. die funktionalität muss auch mit minimalen kenntnissen des anwenders gesichert werden. selbst bei zt unsinnigen und sich widersprechenden vorgaben des anwenders muss irgendetwas funktionieren.
und hübsch aussehen muss es (verkaufspsychologie!)
das geht natürlich auf kosten der sicherheit, das ist dem handwerker, der seine abrechnung bis morgen früh fertig haben muss aber eigentlich wurscht (da muss ich leuten wie zb heinz recht geben).
mit einem solchen konzept erreiche ich eine große verbreitung, das system ist gefällig. mit der verbreitung gibt es aber immer mehr unsichere systeme.
mit der heutigen vernetzung bekomme ich dann mit den problemen grosse schwierigkeiten. was ist zu tun?
ich könnte das system abschotten, aber was ist dann mit den anwendern, wenn plötzlich nichts mehr so richtig funktioniert, programme die bisher klaglos liefen nun keinenmucks mehr sagen????
ich muss die anwender langsam umgewöhnen und eigentlich den schaden den ich vorher angerichtet habe wieder ausbügeln.
auf dem weg befindet sich windows für meine begriffe schpn seit geraumer zeit.
mal sehen wie es weiter geht!
Zitat
Original von felix
das erspart zumindest lästige antwortarbeit. 
