Christoph Zurnieden: Warum in PHP entwickeln wenn es ASP.net gibt?

Beitrag lesen

Hi,

Nein, im gewerblichem Bereich sind es bei Software immer die Kosten.

Lies mein Posting bitte nochmal.

Kann ich gerne tun, habe ich hiermit getan, bleibt trotzdem die Frage: warum? Wo habe ich Dich mißverstanden?

Die Kosten von PHP und Apache sind so gering, die können betriebswirtschaftlich durchaus als "Rote Null" angesehen werden.

Dann hast du wohl nur einen Server, oder? Dann sind die Lizenzkosten
für Windows höher. Wenn du mal mehrere hundert Server betreust relativiert
sich das.

Das verstehe ich nicht.
Lizenzkosten für PHP&Apache entfallen, aber das war wohl bloß eine ungeschickte Formulierung von Dir nehme ich einfach mal an.
Die Lizenzkosten alleine machen sowieso nur einen sehr geringen Teil der Kosten aus. Viel deutlicher schlagen die indirekten Kosten wie Support, Pflege, Flexibilität, Dauer der Verfügbarkeit, Skalierbarkeit und was es so alles gibt zu Buche. Das relativiert sich aber nicht bei größerer Anzahl an Installationen sondern klafft im Gegenteil immer weiter auseinander.

Das IIS+ASP billig ist, ist eine rare Ausnahme, bei PHP+Apache ist es jedoch die Regel.

Macht das einen Unterschied?

Ja. Zwar nicht wegen des angeblichen Monopolisten aber für die
angeblich ach so hohen Kosten von _IIS_ und _ASP.NET_.

(Microsoft wurde rechtskräftig wegen Ausnutzung seiner Monopolstellung verurteilt, das "angeblich" kannst Du Dir also sparen. Aber darauf habe ich gar nicht rumgeritten, das hast Du erst auf's Tapet gebracht)

Die Kosten von IIS+ASP sind meist höher, das heißt nicht unbedingt, das sie auch hoch sind. D.h. es ist durchaus möglich, das eh schon Lizenzen da sind, diese Kosten also nicht in's Gewicht fallen. Bei allen anderen Kriterien gibt es jedoch meist eine Alternative, die billiger ist, teilweise sogar deutlich.
Wie Du aber an den Adjektiven gut erkennen kannst: das ist nicht vollständig pauschal feststellbar, es sind die jeweiligen Umgebungsvariablen sorgfältig zu prüfen.

Aber es hilft auch trotzdem nichts: es sind die Kosten, die den Einsatz von Software bestimmen. Das es hin und wieder doch die Werbegeschenke sind ändert nichts daran.

Wieso? Nur weil ein Hersteller kaputt geht muss ich nicht meine
gesamte Software austauschen. Du musst ja auch nicht dein Auto
verschrotten, wenn der Hersteller pleite geht und aufgekauft wird.
Nein, auch nicht, wenn der neue "Besitzer" die Automarke einstampft.

Software mit Hardware zu vergleichen geht immer in's Auge, aber egal.

Wenn der Hersteller (oder Aufkäufer der Konkursmasse) )die Automarke nicht mehr herstellt und alles tut, das dieses Produkt auch keine weitere Verbreitung finden kann bekommst Du folgende Probleme:

  • keine Ersatzteile mehr. Nachbauten sind nicht erlaubt, der Hersteller kann die Lizenzverträge ja mühelos kündigen.

  • keine Reparaturen durch Dritte mehr, da die Auto-Elektronik heutzutage fast nur noch mit Werkzeug und Ersatzteilen des Herstellers zu reparieren ist. Alternativ: schweineteure Nachbauten, die aber natürlich verboten sind.

  • da der Hersteller selbst den Tankverschluß proprietär angefertigt hat und an die Tankstellen die Adapter nur verliehen hat kannst Du nur noch den Tank leerfahren, das war's dann.

und, und, und ...

Oben beschriebenes Szenario würde Dir den Boden unter den Füßen wegziehen. Das passiert so schnell nicht? Ja, wie lange hast Du denn noch bis zur Rente?

Ich frag mich echt wie man auf so einen Kram kommt.

Leidvolle Erfahrungen.

Was mir wann wie
den Boden unter den Füßen wegziehen _könnte_ werd ich wohl besser
wissen.

Das weißt Du genauso gut oder schlecht, wie ich.

Und wenn PHP mal eingestampft wird würde es jedem PHP Entwickler
deiner Aussage genauso gehen. Komische Denkweise.

Nach meiner Aussage würde würde gar nichts passieren, denn PHP kann nicht einfach dicht machen, das geht gar nicht. Alle Core-Entwickelr können die Brocken hinschmeißen, aber wenn auch sie sich auf den Kopf stellen: PHP können sie nicht mehr in den Sumpf zurückschieben aus dem es einst kroch.

Sollte es die Menschheit dereinst in hundert Jahren noch geben, dürfte es HP mit Sicherheit nicht mehr geben. Gut, ich gebe zu: das war jetzt mit einem Tröpfchen Hoffnung gewürzt. Aber das tut hier auch nichts zur Sache. Wenn nun in hundert Jahren ein Museumsmitarbeiter etwas mit PHP an's Laufen bekommen möchte hätte er viele Probleme, aber Lizenzprobleme gehören mit Sicherheit nicht dazu.

Aber ASP+IIS ist nicht sehr weit verbreitet, schlimmer sieht's z.B. bei Java aus.

Auweia. Da halt ich jetzt lieber den Rand bevor ich noch was böses[TM]
sage.

Tu' Dir keinen Zwang an. Aber denke bitte daran, das hier auch Jüngere mitlesen, die nicht unbedingt ihren Wortschatz erweitern sollen.

so short

Christoph Zurnieden

0 48

Warum in PHP entwickeln wenn es ASP.net gibt?

JETZTWILLICHESWISSEN
  • php
  1. 0
    Samuel Vogel
    1. 0
      JETZTWILLICHESWISSEN
    2. 0
      azok
      1. 0
        Stefan Falz
        1. 0
          Johannes Zeller
          1. 0
            Stefan Falz
            1. 0
              Christoph Zurnieden
              1. 0
                Andreas Korthaus
                1. 0
                  Christoph Zurnieden
                  1. 0
                    Andreas Korthaus
                    1. 0
                      Christoph Zurnieden
              2. 0
                Stefan Falz
                1. 0
                  Johannes Zeller
                2. 0
                  Christoph Zurnieden
                  1. 0
                    Johannes Zeller
                    1. 0
                      Christoph Zurnieden
                  2. 0
                    Stefan Falz
                    1. 0
                      Christoph Zurnieden
  2. 0
    Bio
    1. 0
      Thommy
      1. 0
        Bio
  3. 0
    Vinzenz
    1. 0
      Johannes Zeller
    2. 0
      MudGuard
      1. 0
        Johannes Zeller
      2. 0
        Vinzenz
  4. 0
    Andreas Korthaus
    1. 0
      Christian Kruse
      1. 0
        Andreas Korthaus
        1. 0
          Schuer
          1. 0
            Andreas Korthaus
  5. 0
    Mazze
  6. 0
    MudGuard
    1. 0
      Bio
      1. 0
        MudGuard
        1. 0
          Bio
    2. 0
      Thomas J.S.
  7. 0
    Christian Seiler
  8. 0
    Christoph Schnauß
  9. 0
    Peter
  10. 0
    Cybaer
  11. 0
    fk
    1. 0
      Marko
      1. 0
        fk
        1. 0
          Marko
          1. 0
            Cybaer
        2. 0
          Martin Speiser