Teuer bezahlte Dilletanten
Als Sysadmin bekomme ich einiges zu sehen. Da hätten wir z.B. unsere eigenen Entwickler und ihre Begierden, die zu Auswüchen wie "Du mußt mal den Server auf Deutsch umstellen" und dergleichen führen.
Wie, den gesamten Server? Stundenlange Diskussionen über die Verwendung von Locales in der Umgebung des Users oder der Umgang mit Locales in der Anwendung selbst folgen.
Mein Verständnis schlägt aber in entsetzen oder wahlweise in einen Lachanfall um, wenn ich mir die kommerziellen Produkte diverser Hersteller anschaue.
IBM hat mit ihrem Backuptool aus der eierlegenden Wollmilchsau Tivoli-Familie so ein Ding im Angebot: Da wird die Anwendung brav in ein eigenes Verzeichnis installiert, und im Anschluß die Konfigurationsdateien dsm.sys und dsm.opt nach /usr/bin verlinkt.
Puh, und ich rege mich auf, wenn Open Source Makefiles auf den gcc ausgelegt oder für Linux "optimiert" sind. Nun gut, die Links muß man nicht haben, aber auch unterhalb des Anwendungsverzeichnisses gibt es ein ./bin, in dem die Files rumfliegen. Wobei die hier von anderen Textdateien Verstärkung erhalten, die man ebenfalls als "Konfigurationsdatei" bezeichnen könnte. Die wird aber nicht verlinkt. Warum das so ist verstehen aber wohl nur die Programmierer. Das sind wohl auch die einzigen, die erklären können, warum sowas nicht in ein ./etc-Verzeichnis landet.
BMC kann das auch, wie ich gerade gesehen habe. Bei diesem dreibuchstabigen Hersteller ist man wohl der Ansicht, "bin" steht für "alles, was binär ist". Um die Sache also nicht allzusehr zu verkomplizieren findet man bei deren Software auch gleich noch die Libraries in eben diesem Verzeichnis. Dann muß man sich auch keine Gedanken über den dynamischen Linker machen.
Oder aber die Programmierer arbeiten unter und primär für Windows. So sieht das nämlich aus, wenn unter ./bin auch ein ganzer Haufen Textdateien und jars liegen. Schaut unter Windows ja eh keiner rein, und da gibt es keine festgelegten und seit Jahrzehnten gut abgehangenen Verzeichnisstrukturen.
Ich wundere mich dann immer, warum ich unter /etc/rc3.d keinen Eintrag finde wie ./Verknüpfung mit unserhauptprogramm. Aber stimmt, es ist mir aufgefallen, weil ich noch ein SVC Manifest für die Software schreiben muß.
Wobei das wirklich positiv ist, denn die Software braucht keine Root-Rechte zur Installation, sondern nur ein Verzeichnis, in dem sie sich entladen darf. Und zwischendurch weist sie dann darauf hin, dass der Root mal aktiv werden darf.
Ist also nicht alles schlecht. ;)
Umgekehrt sollte es aber bei so einer Software aber nicht schwer sein eine Paketierung zu verwenden, die auch den Standards gerecht wird, oder? Bei solchen Äußerlichkeiten möchte ich manchmal garnicht wissen, was der eigentliche Programmcode so alles für Überraschungen bereit hält.
Wie, den gesamten Server? Stundenlange Diskussionen über die Verwendung von Locales in der Umgebung des Users oder der Umgang mit Locales in der Anwendung selbst folgen.
Mein Verständnis schlägt aber in entsetzen oder wahlweise in einen Lachanfall um, wenn ich mir die kommerziellen Produkte diverser Hersteller anschaue.
IBM hat mit ihrem Backuptool aus der eierlegenden Wollmilchsau Tivoli-Familie so ein Ding im Angebot: Da wird die Anwendung brav in ein eigenes Verzeichnis installiert, und im Anschluß die Konfigurationsdateien dsm.sys und dsm.opt nach /usr/bin verlinkt.
Puh, und ich rege mich auf, wenn Open Source Makefiles auf den gcc ausgelegt oder für Linux "optimiert" sind. Nun gut, die Links muß man nicht haben, aber auch unterhalb des Anwendungsverzeichnisses gibt es ein ./bin, in dem die Files rumfliegen. Wobei die hier von anderen Textdateien Verstärkung erhalten, die man ebenfalls als "Konfigurationsdatei" bezeichnen könnte. Die wird aber nicht verlinkt. Warum das so ist verstehen aber wohl nur die Programmierer. Das sind wohl auch die einzigen, die erklären können, warum sowas nicht in ein ./etc-Verzeichnis landet.
BMC kann das auch, wie ich gerade gesehen habe. Bei diesem dreibuchstabigen Hersteller ist man wohl der Ansicht, "bin" steht für "alles, was binär ist". Um die Sache also nicht allzusehr zu verkomplizieren findet man bei deren Software auch gleich noch die Libraries in eben diesem Verzeichnis. Dann muß man sich auch keine Gedanken über den dynamischen Linker machen.
Oder aber die Programmierer arbeiten unter und primär für Windows. So sieht das nämlich aus, wenn unter ./bin auch ein ganzer Haufen Textdateien und jars liegen. Schaut unter Windows ja eh keiner rein, und da gibt es keine festgelegten und seit Jahrzehnten gut abgehangenen Verzeichnisstrukturen.
Ich wundere mich dann immer, warum ich unter /etc/rc3.d keinen Eintrag finde wie ./Verknüpfung mit unserhauptprogramm. Aber stimmt, es ist mir aufgefallen, weil ich noch ein SVC Manifest für die Software schreiben muß.
Wobei das wirklich positiv ist, denn die Software braucht keine Root-Rechte zur Installation, sondern nur ein Verzeichnis, in dem sie sich entladen darf. Und zwischendurch weist sie dann darauf hin, dass der Root mal aktiv werden darf.
Ist also nicht alles schlecht. ;)
Umgekehrt sollte es aber bei so einer Software aber nicht schwer sein eine Paketierung zu verwenden, die auch den Standards gerecht wird, oder? Bei solchen Äußerlichkeiten möchte ich manchmal garnicht wissen, was der eigentliche Programmcode so alles für Überraschungen bereit hält.
cptsalek - 18. Feb, 12:28
Trackback URL:
https://cptsalek.twoday.net/stories/4715646/modTrackback