Welche Cross-Plattform Tools benutzt ihr?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Hinweis: In dem Thema Welche Cross-Plattform Tools benutzt ihr? gibt es 20 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • @Berichtigung: Um das ganze mal voneinander zu trennen und um hier beim Thema zu bleiben, habe ich in meinen Lieblings-PHP-Forum mal einen Thread dazu eröffnet, der dazu dienen soll, detailliert zu erörtern warum PHP per Definition unsicher sein sollte, siehe hier: PHP soll angeblich per Definition unsicher sein - Meinung eines einzelnen? -


    php.de
    Bei Interesse kannst Du Dich gerne der Diskussion anschließen, schließlich geht es ja dort um Deine Kernaussage, sowie Deinen angeführten Behauptungen.
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107685 haftet ausdrücklich der jeweilige Autor: derwunner

  • derwunner schrieb:

    Ok, ich gehe jetzt nur mal auf das wichtigste ein. Meine Zeit ist sehr beschränkt und ich möchte sie nicht damit verbringen, besserwisserisch zu sein oder so zu wirken.
    Aber zwei Antworten. Eh klar.


    derwunner schrieb:

    Leben und leben lassen sagte mein Vater immer... Ich kann ganz gut von dem "Sicherheitsloch" leben. Aktuell ist es auch so, dass mein Chef keine andere Programmiersprache will. Weil wir eben auch das tun müssen, was die Kunden wünschen, und nicht das, was ein Programmierer gerne hätte.
    Ah ja.
    Ein Sicherheitsloch ist also kein Sicherheitsloch, weil du Geld damit verdienst.
    Und weil Papi Schwachköpfe leben lässt, und Kunden Schwachsinn eingeredet wird, ist ein Sicherheitsloch kein Sicherheitsloch.
    Das wollen die doch!!!!
    Vor allem, wenn es ihnen von Leuten eingeredet wird, denen sie fälschlicherweise zutrauen, dass sie es könnten.
    Also von diesen PHP Verteidigern, die ja auch "ihr Geld" verdienen wollen.
    Ziemlich schäbige Argumentation.

    Aber du wirfst vi- Usern dann vor, dass sie durch Einsatz dir unverständlicher Technik nur Geld schinden.

    Da ist mir -ehrlich gesagt- die Mafia lieber.
    Die haben wenigstens noch eine Moral.

    Lasse das mit der EDV. Werde lieber Präsident in Amerika. Da gibt es keine Anforderungen an technischen Sachverstand.
    Das Unsinn schreiben kriegst du ja schon ganz gut hin.

    derwunner schrieb:

    ---snip webserver----
    Ja, Du hast Recht, Deine Definiton trifft es besser. Glaube sogar mit nginx kann man auch Reverse Proxy und solche Scherze machen. Und ja, ich hatte mich schonmal mit dem nginx (oberflächlich) beschäftigt. Ich weiß, dass bei dem das .htaccess Format anders ist und auch sonst die vhost config komplett anders ist. Gerade wenn es um so Sachen wie automatische gzip Komprimierung on-the-fly geht, dann kann glaube ich der nginx noch ein bisschen mehr.nginx ist aber nicht nur ein Proxy, sondern auch ein Webserver.
    Echt? Ist dieser obergeile, rattenscharf schnelle Webserver nginx, der sogar imap, pop3, proxy und reverse proxy kann, tatsächlich sogar ein Webserver?
    Wer hätte das gedacht?!
    Muss was ja was ganz Modernes und Schnelles sein. Kann der das tatsächlich einfach so!!!
    Einer der sogar on-the-fly nicht nur gzip komprimiert, sondern sogar ganze Bäume von Javascript- oder CSSdateien bündeln kann.
    Boah ey. Richtig wunschmodern. Is ja ein Traum!
    Sogar seine ziemlich leicht verständliche Konfigurationssprache ist einfach. Und so komische Rechteklimmzüge, wie htaccess- Dateien, die ihrerseits letztlich nur ein Sicherheitspatch sind, hat der deshalb auch nicht nötig.
    Der Name "Apache" leitet sich weder von Karl May, noch von indigenen Ureinwohnern ab.
    Er geht auf das Patchen, also das Flicken von Löchern, zurück. Apache == A-Patch-e == ein ständig geflickter Webserver.
    Das ist wahr und keine Erfindung von mir.

    Aber natürlich kann man keine moderne Konfigurationssprache lernen.
    Ich kann dich aber auch hier beruhigen: Dovecot und sehr, sehr viele andere Serversoftware verwendet die auch.
    Sie ist sogar ziemlich weit verbreitet. Und wird sogar schon ein paar Jahre länger eingesetzt.
    Außer bei Standard LAMP-Loosern.
    Die kennen das immer noch nicht.

    derwunner schrieb:

    --snip Mercurial----
    Das weiß ich, weil ich hg bei einer vorhergehenden Firma einsetzte. Dort gab es nur hg ohne GUI. Naja, wie auch immer, ich fand damals jedoch eine gute GUI dafür, die jedoch nicht ganz billig war. Ich meine 1.000 Euro für kleine Unternehmen oder so. TortoiseHg war der kostenlose (und auch schlechtere) GUI Client. Ich redete eigentlich von dem Ur-hg, dass es noch vor Git gab, nicht diesem neumodischen Ding, was darauf aufbaut. Soviel ich weiß, ist hg eine konkurriende Versionsverwaltung, heißt: Mehrere Benutzer können dieselbe Datei bearbeiten, wenn sie nicht die gleiche Zeile bearbeiten. Genau das kann Git auch. Jedoch hat Git noch zusätzlich Branches, die es so laut meines Wissens nicht in hg gibt. Das eröffnet viele Möglichkeiten professioneller Software Entwicklung (siehe die drei großen Git Branching Modelle: Git Flow bzw. Git feature based Braching (master - develop - feature-XY), Git mit master und feature Branch(es), und Git mit versionsbasierten Branches. Letzteres ist das aufwändigste Modell, wodurch man aber parallel mehrere Software Versionen pflegen kann. In die älteren fließen dann nur noch Bug Fixes ein. Die einzelnen Versionsbranches werden dann aber auch nicht mehr mit dem master gemergt. Es finden stattdessen Ableitungen von der jeweils neuesten Version statt.)
    Unglaublich.

    Also erst einmal sind Git und Mercurial ziemlich genau gleich alt, oder jung. Sie entstanden zur gleichen Zeit.
    Zweitens ist "hg" das chemische Formelzeichen für Quecksilber aka. Mercurial. "hg" war und ist Mercurial. Nicht irgendwas "neumodisch aufgesetztes".
    Drittens schwadronierst du völlig ohne Hintergrundwissen über Branches von Sourcecodemanagement- Systemen.
    Du wirst es kaum glauben: Das machen BEIDE Git und Mercurial. Sogar einigermaßen ähnlich. Und -völlig unglaublich- bei Mercurial heißen Branches sogar Branches.

    Was schreibst du wieder von Dingen, die du noch nicht einmal ansatzweise verstanden hast?
    Und eine GUI brauchst du? Du klar. Aber jeder ernsthafte Entwickler braucht und nutzt die CLI Version,
    weil die -auch bei beiden- ganz easy in die jeweilig bevorzugte IDE integriert werden können.
    Das machen auch alle IDEs so.
    vi selbstverständlich auch.

    Und der miteingebaute Webserver IST eine GUI. Nur einen Browser brauchst du noch.
    Ein kleines Kommando und du kannst mit der Mouse deine Dateien rumschubsen.
    Python halt. Batteries included.

    Bei Git musst du erst wieder im alternaiven Internet nach höchst kostenpflichtigen GUIs suchen und löhnen.
    Oder selber machen. OK, is Käse, weil fällt aus wegen is nich.

    derwunner schrieb:

    --snip scp/ssh Unsinn--
    Ja, schätze schon. Besonders nachdem ich mir zu dieser hitzigen Diskussion bereits alle Pro- und Kontras mir aus dem Heise Forum gegeben hatte. Schlussendlich kam heraus, dass Meinungs-/ Glaubens-/ bzw. Auslegungssache ist. Einen Schlüssel kann man auch hacken bzw. erraten. Und wie wir alle wissen, greift ein Angreifer nicht am stärksten Glied an, sondern er sucht sich das schwächste raus. Was nützt ein starker Schlüssel, wenn die restliche nur so von Lücken klafft.Also man kann SSH Authentifizierung per User/Passwort oder per User/Key File machen. Ist beides genauso sicher wie unsicher. Oder kann auch sein, dass ich nach dem 200. Post zu dem Thema das Forum auch einfach geschlossen hatte, weil es mir bunt wurde, ich weiß es nicht mehr, dürfte mittlerweile auch schon wieder ein Jahr her sein.
    Es ist zwar ziemlich mühsam eine Schlüssel zu erraten, weil der halt eine ziemliche zufällige Folge von Zeichen ist, und die auch noch ziemlich lang ist. Da ist Erraten ziemlich schwer, aber ich will das schon gelten lassen.

    Nur, ist es eben der grundlegende Mechanismus der SSH-Key Authentifizierung, dass der öffentliche Schlüssel des Users auf dem Server liegen muss und beim Verbindungsaufbau mit dem privaten abgeglichen wird.
    Das ist das Wesen dieser Methode.

    Du kannst also raten, was du immer magst:
    Du hast keine Chance deine jämmerlichen Rateversuche einzugeben.
    Gäbe es die, wäre das ja wieder die Spasswortauthetifizierung, die ja gerade unterbunden werden soll und auf anständig konfigurierten Server deshalb auch nicht verfügbar ist.

    Du hast das Wesen dieser Methode noch nicht einmal ansatzweise verstanden,
    aber hübsch irgendwelchen Mist darüber erzählen....
    Unglaublich.

    Denk mal drüber nach, warum die beiden Methoden einen ganz gewaltigen Unterschied machen in punkto Sicherheit.
    Einen wirklich sehr, sehr großen.

    Du kannst gerne zu uns in Mumble kommen,
    dort lernst du richtig was.
    Jedenfalls ist dein Wissen außerordentlich begrenzt.
    Außer Buzzwörter, da biste gut.
    Das nutzt aber rein gar nichts.

    Den Rest deiner unsäglichen Suada mag ich gar nicht mehr zerlegen.
    Es reicht jetzt sogar mir.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 107686 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Wie bringt man einen Franken zum ausrasten? Franken gehört zu Bayern! :D

    PHP ist wirklich eine tolle Sprache. Nicht weil sie so gut ist, sondern weils mehr Jobs für PHP Entwickler gibt, als für Python Leute.


    Wenn "Berechtigung" mit seiner spießigen Weltverbesserungstour fertig ist, kann man evtl seine eingesetzten Tools posten. Und Vi kommt mir sicher nicht ins Haus.

    Wie heißt es so schön, jedem das seine. Ich nutze nur IDE's.
    we are motörhead and we play rock and roll

    Für den Inhalt des Beitrages 107689 haftet ausdrücklich der jeweilige Autor: raptor49

  • raptor49 schrieb:

    Wie bringt man einen Franken zum ausrasten? Franken gehört zu Bayern! :D

    PHP ist wirklich eine tolle Sprache. Nicht weil sie so gut ist, sondern weils mehr Jobs für PHP Entwickler gibt, als für Python Leute.


    Wenn "Berechtigung" mit seiner spießigen Weltverbesserungstour fertig ist, kann man evtl seine eingesetzten Tools posten. Und Vi kommt mir sicher nicht ins Haus.

    Wie heißt es so schön, jedem das seine. Ich nutze nur IDE's.
    1. Absatz: Kein Kommentar xD

    2. Absatz: Ja, vollkommen richtig erkannt. Wobei wahrscheinlich Python Entwickler besser bezahlt werden, eben weil die rar sind. Ich habe schon mehrere Firmen gesehen, die Freelancer beauftragt hatten, ein openSource Python Produkt auf ihre Bedürfnisse anzupassen. Von der Vergütung ganz zu schweigen. Leider traurige Tatsache... Python mag als Programmiersprache ganz nett sein, das will ich gar nicht abstreiten. ABER: Im Ursprungsbezug auf die Webentwicklung fällt mir spontan kein einzige Python basierte Web Anwendung ein, die ein normal sterblicher bei sich auf dem Server verwendet. Ich wüsste nicht mal, mit welchen Webserver ich das Python Zeugs zum Laufen bekommen sollte. Naja, ganz ehrlich: How cares?! Ich kenne größtenteils nur PHP, Ruby und Java Webanwendungen. Auf Python basiert jedoch keine davon. Und ich denke auch kaum, dass Größen wie Atlassian, Shopware, Typo3, Magento, Woltlab (ja, man sollte sich nicht den Ast absägen auf den man sitzt!!!!), etc. jetzt plötzlich nach Python refactoren, nur weil das einer sagt.

    3. Absatz: Vi kommt mir schon ins Haus, allerdings darf der allerhöchstens mal die vhost config oder die /etc/hosts Datei öffnen, wenn ich gerade mal zu faul bin wegen zwei Zeilen ein großes GUI Fass aufzumachen. Oder wenn ich wieder mal die schließenden Anführungszeichen beim git Commit Kommentar vergessen habe. Dann, ABER auch nur dann kommt bei mir vi zum Einsatz. Ok, Moment, auf dem Textbasierten Server natürlich auch. Bin kein gedit Fan.

    4. Eben, sehe ich auch so. Ich benutze größtenteils IDE's. Wie gesagt, für zwei Zeilen Änderung muss ich nicht unbedingt eine IDE haben.


    PS: Und ja bitte, lasst die anderen auch endlich mal zu Wort kommen.
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107690 haftet ausdrücklich der jeweilige Autor: derwunner

  • Klar.

    Man hat zwar keine Ahnung von SSH, Webservern, aber munter wird weiter Unsinn verzapft.

    Komplett alle Googlewebsiten SIND mit hauseigenem Pythonframework geschrieben.
    Sie haben sogar dafür den Interpreter selbst noch angepasst.
    Und Google ist nicht die einzige Firma.

    Dass du das nicht kennst, verwundert nicht.

    Dass die Sicherheitslöcher, wie Magento oder Woltlab nicht auf Python migrieren ist klar.
    Müssten sie ja -und der Krempel ist rein PHP- Python lernen
    und ihre kompletten Produkte einstampfen.

    Das Argument, dass PHP wegen des Jobangebots besser wäre, -ich kann mir nicht helfen- klingt einfach, wie ein dämliches Loblied auf die Sklaverei.
    Weil es so viele gibt, isses gut.
    Da braucht man eigentlich nichts mehr zu sagen.

    Ein Pythonframework läuft mit uwsgi. Das gibt es für so ziemlich alle gängigen Webserver.
    Sogar für den Indianer.

    Dein PHP, falls du das halbwegs vernünftig installiert hast, braucht übrigens auch so eine SGI (ServerGatewayInterface) Schnittstelle, wenn du nicht mit dem völlig veralteten mod_php rumwursteln willst.
    (Falls das doch läuft, würde ich empfehlen auf PHP Fastcgi umzustellen. Da kannst dann den Kunden noch mal Kohle abmontieren, weil die gesamte Webserverei plötzlich erheblich schneller ist. Hach, was seid ihr doch für Webhelden!)

    Das ist die für alle dynamisch Websiten erzeugende Serverinfrastrukturen der gängige Ansatz.
    Egal, ob PHP, Java, Ruby, Perl, asp oder sonstwas.

    Basics halt.
    Für PHP- Leute natürlich hochstehende Zauberei.
    Woher sollte man auch wissen, wie ein Webserver arbeitet, wenn er -egal welchen- Interpreter aufruft.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 107693 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Berichtigung schrieb:

    Das ist die für alle dynamisch Websiten erzeugende Serverinfrastrukturen der gängige Ansatz.

    Egal, ob PHP, Java, Ruby, Perl, asp oder sonstwas.

    Basics halt.
    Für PHP- Leute natürlich hochstehende Zauberei.
    Woher sollte man auch wissen, wie ein Webserver arbeitet, wenn er -egal welchen- Interpreter aufruft.
    Jetzt muss ich Dich mal verbessern, oder sollte ich besser sagen berichtigen? Ha, gleich noch ein Wortspiel gezaubert ;)
    Also: Java Web läuft in einem eigenen Anwendungsserver, in einer App-Engine sozusagen. Und dieser Anwendungsserver integriert einen Webserver, nicht umgekehrt. Du brauchst also neben den nginx oder Apache noch einen Tomcat / Glassfish / Wildfly Server, damit deine Java EAR bzw. Java Bean läuft. Enterprise eben.
    Bei ASP .NET ist es ähnlich, läuft meines Wissens auch nur unter Microsofts IIS Webserver. Ich hatte mal vor Jahren auf SourceForge eine abgespeckte ISAPI für Linux gefunden. Soetwas ist aber auch schon sehr sehr exotisch. Mag sein, dass sich die Situation um ASP .NET mittlerweile geändert hat, ich bin da seit mehr drei Jahren raus. Als ISAPI hatte man damals jedenfalls die API bezeichnet, die den kompilierten ASP .NET Code verstehen konnte. Das war ja ähnlich wie C# auch nur in Byte Code kompiliert. Und bitte, lasst jetzt keine Debatte darüber ausbrechen, ob in Byte Code kompilieren wirklich kompilieren ist oder nicht. Bitte Bitte, erspare uns diese unsinnige Diskussion.

    Und ich weiß sehr wohl wie ein Webserver arbeitet. Naja, zumindest wie und wann das PHP Modul aufgerufen wird. Ein Webserver selbst ist ja erstmal dumm, der kann nur HTML ausliefern. Wenn er auf Skriptsprachen stößt, wie PHP, dann wird der Interpreter dafür angeschmissen, welcher dann widerrum HTML an den Webserver ausliefert, was dann der Webserver anzeigen kann.
    Und ja, ich verwende bei mir noch den mod_php. Ich dachte eigentlich das wäre anders herum, also dass CGI steinalt wäre und dass man besser CGI nicht mehr verwenden sollte, eben weil es so alt ist und nicht mehr aktiv weiterentwickelt wird. Wie auch immer, bei den Kunden draußen läuft das ganze schon als FastCGI Modul, nur auf meiner Entwicklungskiste wird direkt das mod_php eingebunden. Ach ja: Soviel ich weiß war mal CGI zu Zeiten von TCL und direkter CGI Programmierung modern. Aber seitdem es Skriptsprachen fürs Web gibt bzw. Präprozessoren für HTML, ist das Thema CGI laut meinen Kenntnisstand obsolete.
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107694 haftet ausdrücklich der jeweilige Autor: derwunner

  • derwunner schrieb:

    Jetzt muss ich Dich mal verbessern, oder sollte ich besser sagen berichtigen? Ha, gleich noch ein Wortspiel gezaubert ;)
    Herzlichen Glückwunsch! Immerhin mal ein Sätzchen, dass nicht nach Verbesserung schreit. Also dein Schulterklopfen für das sicherlich geniale Wortspielchen.

    Indes, die Freude währt nicht lange.

    derwunner schrieb:

    Also: Java Web läuft in einem eigenen Anwendungsserver, in einer App-Engine sozusagen. Und dieser Anwendungsserver integriert einen Webserver, nicht umgekehrt.
    Das ist so nicht richtig. Es ist zwar ein Webserver in Tomcat integriert (falls man die HTTP- Connectoren installiert), den man dann als Stand-alone laufen lassen kann.

    Bei richtigen Websiten jedoch, die doch ein paar Zugriffe pro Sekunde mehr abwickeln wollen, wird man wieder einen nginx als Webserver nehmen. Was sonst? Ist halt mal derzeit der ideale Server, der Loadbalancing durch seine Proxyfähigkeiten starkt vereinfacht.

    Einen integrierten Webserver bringt auch das von mir favorisierte web2py mit. Dort heißt er "rocket".
    Es gibt unglaublich viele verschiedene "Mini"- Web- Server, die in Python geschrieben wurden.

    Das gilt auch für viele andere Sprachen.
    Auch für asp.

    derwunner schrieb:

    Du brauchst also neben den nginx oder Apache noch einen Tomcat / Glassfish / Wildfly Server, damit deine Java EAR bzw. Java Bean läuft. Enterprise eben.
    Und nun rate mal, wie man das nennt, wenn nginx die Requests aufbereitet zu seinen Backends schaufelt? Wie wird das wohl gemacht werden?

    Jawohl: Über ein Server Gateway Interface.


    derwunner schrieb:

    Bei ASP .NET ist es ähnlich, läuft meines Wissens auch nur unter Microsofts IIS Webserver. Ich hatte mal vor Jahren auf SourceForge eine abgespeckte ISAPI für Linux gefunden.
    Auch das ist Käse. Es gibt für jeden anständigen Webserver irgendein ASP- Gateway Interface.


    derwunner schrieb:

    Soetwas ist aber auch schon sehr sehr exotisch.
    Das sagt ja bei dir erst mal gar nix. Für dich sind ja schon ssh-Keys völlig exotisch.


    derwunner schrieb:

    Mag sein, dass sich die Situation um ASP .NET mittlerweile geändert hat, ich bin da seit mehr drei Jahren raus. Als ISAPI hatte man damals jedenfalls die API bezeichnet, die den kompilierten ASP .NET Code verstehen konnte.
    Ja. Dir fehlt auch hier der Überblick. ASP ist schon lange eingestampft worden von M$.

    Aber es werden mit der damaligen Techniken noch immer Websites für bedauernswerte Kunden erstellt.
    Genau, wie bei PHP.

    derwunner schrieb:

    Das war ja ähnlich wie C# auch nur in Byte Code kompiliert. Und bitte, lasst jetzt keine Debatte darüber ausbrechen, ob in Byte Code kompilieren wirklich kompilieren ist oder nicht. Bitte Bitte, erspare uns diese unsinnige Diskussion.
    Is klar. Ich habe zwar keinen Ton davon geredet, aber deinen Unsinn mit ein paar Buzzwords mehr vernebeln ist schon zwingend für dich.


    derwunner schrieb:

    Und ich weiß sehr wohl wie ein Webserver arbeitet. Naja, zumindest wie und wann das PHP Modul aufgerufen wird. Ein Webserver selbst ist ja erstmal dumm, der kann nur HTML ausliefern. Wenn er auf Skriptsprachen stößt, wie PHP, dann wird der Interpreter dafür angeschmissen, welcher dann widerrum HTML an den Webserver ausliefert, was dann der Webserver anzeigen kann.
    Und ja, ich verwende bei mir noch den mod_php. Ich dachte eigentlich das wäre anders herum, also dass CGI steinalt wäre und dass man besser CGI nicht mehr verwenden sollte, eben weil es so alt ist und nicht mehr aktiv weiterentwickelt wird. Wie auch immer, bei den Kunden draußen läuft das ganze schon als FastCGI Modul, nur auf meiner Entwicklungskiste wird direkt das mod_php eingebunden. Ach ja: Soviel ich weiß war mal CGI zu Zeiten von TCL und direkter CGI Programmierung modern. Aber seitdem es Skriptsprachen fürs Web gibt bzw. Präprozessoren für HTML, ist das Thema CGI laut meinen Kenntnisstand obsolete.
    Tja. Dann nimm diese Basics zur Kenntnis:

    Es gibt den Gattungsbegriff "Server Gateway Interface".
    Der beschreibt die prinzipielle Funktionsweise der ganzen existierenden Gateways. Natürlich gibt es von dieser Spezifikation einige Versionen, ganz normal im IT- Geschäft.

    Im Wesentlichen gleich für alle Implementierungen ist die Weiterleitung der Requests und aller in der URI enthaltenen Parameter.
    Die werden nach server- und konfigurationsabhängiger Vorverarbeitung dann meist als Variablen über das Gateway an die Backends weitergereicht.

    Diese Server Gateway Interfaces gibt es in vielen Varianten. Die älteste davon nennt sich das CGI, das CommonServerGatewayInterface.
    Das bitte nicht vermischen. Du sagst ja auch nicht Auto, wenn du von einem Mercedes sprichst und Mercedes, wenn du von einem Auto sprichst.
    Da gibt es zwar viele Ähnlichkeiten, aber doch erhebliche Unterschiede.

    Dieses alte CGI konnte jedes beliebige Programm als Backend der Strecke Browser->Webserver->CGI->irgendwas aufrufen. Man kann noch heute damit in 10 Zeilen Bash einen voll funktionsfähigen Webserver samt CGI - Verarbeitung schreiben.
    Natürlich wurde das schnell obsolet, weil es heftig missbraucht wurde.
    Ungefähr zu der Zeit kam PHP leider auf die Welt.
    Jetzt suchte man Möglichkeiten PHP möglichst effizient zu bedienen. Der erste Ansatz war ein Modul für den Apachen, der den PHP- Interpreter aufruft.
    Und es kamen die ersten spezialisierten Server Gateway Interfaces auf den Markt.
    Mit dabei war da schon wsgi das WideServerGatewayInterface, das später zu uwsgi wurde und heute in allen schnellen Servern nicht nur für Pythonprogramme werkelt.

    Der Ansatz PHP vom Apache aus als Modul zu bedienen, stellte sich auch recht bald als Flaschenhals für die Performance heraus. Es musste für jedes Script eine Instanz von PHP geladen werden.
    Irgendwann merkten sogar die PHP - Leute, dass es so nicht lange würde weitergehen können, weil es viel zu lange zu gehen hatte, bis endlich diese eine HTML-Seite generiert war. Uwsgi gab es da längst.

    Tja, und heute ist meist für PHP ein fast-cgi am Start.
    Und du hast hoffentlich jetzt begriffen, dass es gar keine sooo gute -in Sachen Performance sogar die schlechteste- Idee ist, einen Tomcat nur mit dem eingebauten Webserver zu betreiben.

    Die eingebauten Webserver sind eigentlich immer nur zum schnellen Testen und Debuggen gedacht.
    Aber so mancher Looser ist ja schon froh, wenn er so ein Ding überhaupt zum Laufen -pardon: dahinwatscheln bringt.

    Der ganze Käse gilt genauso für ASP.
    Es ist ziemlich egal, wie man die einzelnen Teile nennt. Aus funktionaler Sicht tun alle das Gleiche.
    Und selbstverständlich hat auch Perl sein eigenes SGI.
    Es gibt zahllose solcher SGIs.

    Du kennst jetzt immerhin schon fast fünf dem Namen nach.
    Is doch auch schon was.

    Künftig solltest du solche Begriffe erst auf Wikipedia nachlesen.
    Das erspart uns hier solch Unwissenheitswortgeblubber, und dir die sicher folgende und peinliche Antwort
    und außerdem lernst du was für deine berufliche Zukunft, was ich dir sehr dringend rate.
    Vielleicht schaffst es ja auch mal, dich wirklich etwas tiefer mit der Materie zu befassen über die du so gerne und meist kapital falsch schreibst.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 107695 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • @Berichtigung Nun ja, auch wenn dein Ton harsch ist, ist der doch zumindest immer ehrlich und direkt. Ich muss ebenfalls leider zugeben, dass du meistens auch recht hast. Naja, man kann eben nicht in allen gut sein, dafür gibt es zu viele Techniken / Sprachen / Architekturen / Frameworks / Whatever, als das ein Programmierer alle kennen könnte. Das muss man halt immer abwägen, was man für die jeweilige Stellenausschreibung bzw. Firma braucht.

    Also ja, ich würde schon gerne mit Dir in einem (Sprach-)Chat in Kontakt treten. Einfach weil mich die IT Welt fasziniert und ich gerne Neues lerne. Deine Meinung teile ich mittlerweile zu 10%. Danke schonmal für Deine Zeit und Deine Posts. Die Peinlichkeiten habe ich mir wohl dann auch selber zu zu schreiben....

    So, genug Offtopic, wird Zeit für "richtige" Antworten. Also, dann haut mal in die Tasten! ;)
    Diese Signatur ist derzeit nicht verfügbar.

    Für den Inhalt des Beitrages 107706 haftet ausdrücklich der jeweilige Autor: derwunner

  • Respekt!

    Es ist heute leider eine wirklich einsame Haltung eigene Fehler eingestehen zu können.
    Öffentlich noch dazu stehen verdient noch mehr Respekt.

    Eine Sauerei bleibt es trotzdem. Macht der mir meinen schönen Maulthread kaputt!!
    *Grummelnd* aber mit Respekt.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 107729 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Hauptsystem Windows 10 für Allgemein und 7 zum coden. Kubuntu aktuell nur auf dem Surf/ Test Laptop. Mobil: Android.

    Meine Tools:
    Multimedia: Keine bestimmten, ich verwende das was läuft bzw die richtigen Codecs etc hat.

    Video-Schnitt: zZt nix. Wenn der andere PC wieder Fit ist, dann openShot oder KDenlive.

    Büro: Libre Office. Früher Open Office und Star Office.

    IDE: Wechsle grad von Visual Studio und C#.NET zu Java. Netbeans für Java, HTML/CSS/JS, PHP ( :P ) und zukünftig auch Python. Sollte ich doch nochmal was mit C/C++ machen dann Qt und CodeBlocks. Wenns sein muss nutze ich auch Eclipse. Wenns sein muss auch XAMPP.


    Browser: Auf PC / Lap, Firefox und Opera. Auf Handy aus technischen Gründen Chrome.

    VM Software: Nutze ich zZt nicht, weil PC's zu alt und Grottig.


    Sicherheit: Unter Windows AVG und Defender unter Linux nix.



    E-Mail: Client: Thunderbird

    Web / Appserver: Apache und Glassfish. Bin da aber ned festgelegt


    Datenbank: MySQL. Zukünftig wohl auch Maria DB, SQLite und andere.


    Versionsverwaltung: Nix. Mich nervt das zeug, aber ich werd mir mal smartgit ankucken.


    Passwort-Manager: Nix, halte ich nix von.


    Remote-Verbindungen: Nix, weil alles nur local. Hab keine Server etc. Ansonsten das was Brötchengeber vorgibt.


    Design etc: Gimp ist für mich Grausam. RAW SW für Linux ist für mich unbrauchbar oder hab noch nicht das richtige gefunden. Deswegen bleib ich aktuell wegen Photoshop und Canon RAW SW bei Windows. Ansonsten hab ich mir mal Inkscape angeschaut. Blender soll auch "gut" sein.



    Ansonsten, nix ist festgelegt, bin offen für neues, wenns für mich Brauchbar ist.
    we are motörhead and we play rock and roll

    Für den Inhalt des Beitrages 107736 haftet ausdrücklich der jeweilige Autor: raptor49

www.cyberport.de