Kompatibilität

1st Official Post
    Affected App
    WoltLab Suite Core

    Guten Abend zusammen,


    Ich bin nun schon länger bei einem guten und namenhaften Webhoster und bin bisher immer sehr zufrieden. Das darf von mir aus auch etwas Kosten, man will schließlich anständige Projekte ernsthaft betreiben und das ganze mit einem gewissen Service. Vor kurzem wollte ich jedenfalls die neue Software, Burning Board 4.0 testen und genauer inspizieren. Nun musste ich zu meinen bedauern feststellen das die neue Software mit der Funktion php_uname() arbeitet. Gut, dachte ich mir ... kein Problem, fragste eben hier nach und holst dir Tipps & Tricks, evtl. gibt es ja einen Workaround ohne php_uname(). Nun ist es jedoch so das einige Hoster, unter anderem auch meiner, die Funktion php_uname() nicht aktivieren möchte und somit die neue Software nicht zu installieren ist.
    Leider gibt es auch keinen Workaround seitens der Firma Woltlab.


    Ich möchte hiermit den Vorschlag machen die neue Software auch ohne php_uname() zur Verfügung zu stellen. Ich meine, ich gebe in der Regel mein Geld nicht für eine Software aus in der "ich" als Kunde von Woltlab, mich darum zu kümmern habe einen neuen Hoster zu suchen nur weil Burning Board 4.0 nicht ohne php_uname() auskommen kann? Was wäre z.B. gewesen hätte ich für 79,99 Euro einen Installationsservice gebucht? Bekomme ich dann die Antwort es geht nicht? Zahle ich dann 79,99 Euro für nichts? Um erhlich zu sein hatte ich mir tatsächlich überlegt den Service zu buchen. Um so mehr bin ich überrascht über die Aussage, "Es gibt keinen Workaround". Unter diesen Umständen kann ich als Firma, in meinem Beispiel die Firma Woltlab, keinen Service anbieten der diese versprochene Leistung in diesem Fall in keinster weise einhalten kann!


    Ich finde diesen Umstand mehr als nur Unglücklich. Ich hoffe sehr das diese Missstände nachgearbeitet werden. Ich jedenfalls werde nicht alle meine Projekte ändern und umziehen lassen nur weil es nicht ohne php_uname() funkionieren kann. Ich gebe doch nicht mindestens 80Euro für eine Software aus, wo ich hinterher erfahren muss, das ich mir einen neuen Hoster suchen darf? Da erwarte ich mir als Kunde von Woltlab etwas mehr entgegenkommen oder zumindest bessere Lösungsansätze.
    Wie steht ihr dazu?
    Gerechtfertig? Ja, Nein?


    Ich freue mich jedenfalls auf eure Meinungen und Assoziationen zu diesem Thema. ;)


    Grüße,


    Matze

    Quote

    Ich freue mich jedenfalls auf eure Meinungen und Assoziationen zu diesem Thema.


    Viel gibt es dazu nicht zu meinen. @Alexander Ebert hat erklärt, warum diese Funktion verwendet wird. Du kannst im Übrigen davon ausgehen, dass du dein Geld zurück erhälst, sollte eine Installation aufgrund der Gegebenheiten nicht möglich sein.


    @Alexander Ebert


    Mir ist klar, dass PHP_OS das OS zurückgibt, unter dem es kompiliert wurde, aber das hier sollte doch eindeutig sein:


    Code
    if (StringUtil::toUpperCase(StringUtil::substring(PHP_OS, 0, 3)) === 'WIN') { }


    Denn PHP, welches unter Linux betrieben wird, wird ja nicht unter Windows kompiliert. Könnte man doch als Fallback verwenden?


    EDIT:


    Alternativ könnte man ja auch im Falle des o.g. "Problems" bei der Installation ein zusätzliches Formular anzeigen, wo man das OS wählen kann. Dieser Wert wird dann in der DB gespeichert und für künftige Dateioperationen verwendet.

    Man darf WoltLab doch nicht an allen Schuld geben.
    Sie sind weder für die paranoiden Sicherheitseinstellungen mancher Hoster verantwortlich noch für die katastrophalen Servereinstellungen eines großen deutschen (fängt mit "S" an) Anbieters.
    php_uname() gibt es nicht erst seit gestern und wird ja nicht nur im WBB 4 / WCF 2 verwendet.

    Mit freundlichen Grüßen!


    1x VieCode Paketserver 1.x (1.0.1) inkl. Branding-Free um 20€
    1x VieCode Webdisk 1.x (1.1.5) um 10€
    2x VieCode Lexikon 4.x (4.1.5) je 15€

    @InsidePixel Das ist soweit schon richtig, auf der anderen Seite kann diese Diskrepanz nicht auf den Rücken der Kunden ausgetragen werden, weder vom Softwarehersteller noch vom Hostanbieter, in diesem Fall spielt das keine Rolle wer jetzt Schuld hat. Es ist nicht meine Intention der Firma Woltlab schlechte Arbeit vorzuwerfen, nein ganz im Gegenteil, die Software Burning Board 2.3.6 pl2 war seiner Zeit ein echter Traum genauso wie es die 3.1.8ter ist. Ich schildere nur einen Fall aus meiner Sicht heraus, der durch unglückliche Umstände zwischen den Stühlen sitzt. Deshalb auch mein Vorschlag.


    Quote

    Ich möchte hiermit den Vorschlag machen die neue Software auch ohne php_uname() zur Verfügung zu stellen.
    Ich freue mich jedenfalls auf eure Meinungen und Assoziationen zu diesem Thema.


    Quote from SoftCreatR


    Du kannst im Übrigen davon ausgehen, dass du dein Geld zurück erhälst, sollte eine Installation aufgrund der Gegebenheiten nicht möglich sein.


    Das finde ich jedenfalls sehr beruhigend, daher sollte man dies nochmal dick unterstreichen!



    Grüße,


    Matze

    Quote from Alexander Ebert

    Nein, PHP_OS ist unzuverlässig, es gibt keine Garantie für die Korrektheit der Angabe. Ich gedenke PHP_EOL zu nutzen, da es unter Windows stets \r\n zurückgibt.


    Die Idee hatte ich auch noch. War nur zu spät, um das noch nachzufassen :) Es gibt sicherlich einige Indikatoren, um Windows von *NIX unterscheiden zu können.


    @Matriach


    Noch einmal: php_uname ist aktuell einfach nötig, weil es nicht unbedingt einfach ist, die Betriebssysteme voneinander unterscheiden zu können. Dies wiederum ist jedoch aus diversen anderen Gründen einfach notwendig.

    @Matriach
    War eventuell etwas unglücklich formuliert, mit der "Schuldzuweisung" war eigentlich der Hoster gemeint. php_uname() ist soweit ich weiss die zuverläsigste Methode das OS herauszulesen und zudem absolut ungefährlich.

    Mit freundlichen Grüßen!


    1x VieCode Paketserver 1.x (1.0.1) inkl. Branding-Free um 20€
    1x VieCode Webdisk 1.x (1.1.5) um 10€
    2x VieCode Lexikon 4.x (4.1.5) je 15€

    Quote from SoftCreatR

    @Matriach


    Noch einmal: php_uname ist aktuell einfach nötig, weil es nicht unbedingt einfach ist, die Betriebssysteme voneinander unterscheiden zu können. Dies wiederum ist jedoch aus diversen anderen Gründen einfach notwendig.


    Habe ich schon verstanden, ich habe nur auf einen Beitrag über mir von @InsidePixel reagiert um dessen Aussage richtig zu stellen. Erst Lesen dann sprechen. ;)


    Quote from InsidePixel

    @Matriach
    War eventuell etwas unglücklich formuliert, mit der "Schuldzuweisung" war eigentlich der Hoster gemeint. php_uname() ist soweit ich weiss die zuverläsigste Methode das OS herauszulesen und zudem absolut ungefährlich.


    Da kann ich leider nichts dazu sagen, ich als Laie/Amateur auf dem Gebiet php muss mich ja darauf verlassen was andere mir sagen.
    Bzw ... Mein Dank an @Alexander Ebert :thumbup:


    Grüße

    Quote from Alexander Ebert

    Nein, PHP_OS ist unzuverlässig, es gibt keine Garantie für die Korrektheit der Angabe.


    Unzuverlässig ist relativ - es gibt halt an, auf welchem System PHP kompiliert wurde - nicht, auf welchem System es gerade läuft.


    PHP_EOL ist auch nicht gerade zuverlässig. Vor 5.4.0RC8 gab es auf MacOSX Servern \r zurück. Allerdings sollte es reichen, um Windows zuverlässig von allem anderen zu unterscheiden. denn \r\n wird tatsächlich nur dort verwendet ^^

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy

    • Official Post
    Quote from Netzwerg

    Unzuverlässig ist relativ - es gibt halt an, auf welchem System PHP kompiliert wurde - nicht, auf welchem System es gerade läuft.


    Mich interessiert ja auch nur, ob es Windows ist oder nicht. Ich habe aber schon Windows Binaries gesehen, die unter Linux compiliert wurden und damit ist PHP_OS für unsere Zwecke unzuverlässig.


    Quote from Netzwerg

    PHP_EOL ist auch nicht gerade zuverlässig. Vor 5.4.0RC8 gab es auf MacOSX Servern \r zurück. Allerdings sollte es reichen, um Windows zuverlässig von allem anderen zu unterscheiden. denn \r\n wird tatsächlich nur dort verwendet ^^


    Eben, unter Windows kommt \r\n zurück und bei anderen Systemen irgendetwas anderes, aber eben auf keinen Fall \r\n => Windows erkannt :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login