dMopp schrieb:
Security Features im Kernel... Sorry aber ubuntu im serverbereich machen Amateure.
Und Beweise für deine These sind genau welche? Stimmt, Canonical sind pleite, weil sie keine Geschäftskunden haben, die gern auf deren Server-Support und Landscape setzen...
Ein "professionelles" offenes & freies Server-System wäre dann genau welches?
Debian? Oh, Debian ist toll, aber LTS gibts da nicht, zumindest nicht für Debian 7, nur für 6. Ob LTS für Debian 7 und zukünftige Releases kommt steht in den Sternen. Die Lage für Debian bessert sich, ist aber immer noch untragbar.
OpenSUSE? Der letzte Rotz. LTS is da ein Fremdwort. Du hast maximal 18 Monate, dann wars das. Nett als Desktop...
CentOS? Oh, zumindest stimmen die Release-Zyklen. Wenn ich mal wieder ein OS brauche, dass nicht einmal TRIM für SSD-RAID kann, dann greif ich zu CentOS. Wenn ich mal wieder ein System brauche, dass PHP 5.3 für ne wahnsinnig tolle Erfindung hält, dann greif ich zu CentOS. Wenn ich gern mit Unmengen Fremdquellen einbinde, nur um halbwegs auf dem Stand der Technik zu sein, dann greif ich zu CentOS.
Ubuntu LTS ist DAS Server-OS aktuell.
- 5 Jahre Support (also fast 3 mehr als Debian 7)
- recht aktuelle Software
- kein Handstand & kein Gefrickel an der Sources-Liste, nur um Kernel Backports nachzurüsten
- viele Basis-Bestandteile sind direkt vom Upstream... Wenn Ubuntu also angeblich instabil ist, dann ist Debian es auch.
WhiteShark schrieb:
So wie ich Daaron kenne hat er sich da falsch ausgedrückt und eigentlich das Gegenteil gemeint :-)
Bei ner guten API mit guter Doku braucht man so gut wie nie in den Code zu schauen.
Jep, so wars angedacht. Man guckt nach, welche (verständlich benannten) Funktionen zur Verfügung stehen und lernt die Outline. Man muss nie das Rad neu erfinden.
Was Daaron schreibt stimmt natürlich schon, auch wenn er WordPress gerne schlechter macht als es ist.
Wordpress selbst geht ja noch. Das Autoupdate-System ist z.B. wirklich toll, das Bedienkonzept ist grandios. Der Fehler liegt wirklich nur in der Weigerung, das System mal auf ne saubere API zu setzen und der daraus resultierende Wildwuchs an Extensions voller Sicherheitslücken und Kopfschüttel-Code.
Jemand der schnell eine Webseite oder Blog aufbauen will, paar Partyfotos präsentiert, usw, für den reicht Wordpress dicke.
Genau diese Person wird aber irgendwo ein Theme für 10-20$ kaufen und dann ein paar der sehr bekannten & beliebten Extensions verwenden... eben die aus den Top50, von denen >20% wandelnde Sicherheitslücken sind. Und genau diese Person hat keine Möglichkeit, sich selbst mal hinsichtlich der Lücken zu informieren.
Auch bspw für eine Disco die ihre Events präsentieren will, ist es gut geeignet.
Gerade durch die einfache Administration lässt es sich einem Kunden immer gut verkaufen.
Contao ist da weit überlegen. Ja, das News-Modul ist nicht ganz so blogging-tauglich wie ein reiner Blog, dafür ist das Event/Kalender-Modul wirklich geil. Beide Module stellen nahtlos RSS-Feeds zur Verfügung. Beide Module können sehr leicht um Schema.org Markup ergänzt werden.
Und die Administration? Ich hab mit genug Kunden zu tun um dir sagen zu können: Wenn du denen einfach dei Admin-REchte entziehst und sie auf die für sie nötige Funktionalität beschränkst (was, dank des ausgefeilten Rechtemanagements, wunderbar klappt), dann können selbst totale DAUs Events anlegen, News schreiben oder Newsletter verfassen.
Den meisten Ärger haben wir mit Kunden, die partout nicht verstehen wollen, dass sie bitte keine Word-Texte 1:1 in die Eingabefelder des TinyMCE kopieren sollen, weil das die Formatierung im Frontend zur Sau macht. Aber das Problem hast du überall, wo du Kunden WYSIWYG zur Verfügung stellst.
Aber bzgl EoL kann man sich endlos streiten. Gerade Webseiten sind ja jedesmal individuell.
Aber angenommen man hat 100 Kunden und 100 Kunden müssten auf die neuste Version umsteigen.
Müssen sie? Solange der Legacy-Code keine Sicherheitslücken aufweist, muss man da GAR NICHTS machen. Außerdem gibt es da etwas, das nennt sich Wartungsvertrag. Dem Kunden stehen so oder so vertraglich vereinbart ein paar Stunden im Monat zu. Wenn man die für Updates verwendet, warum nicht?
Wenn der Code Lücken aufweist... nun, alle Jubeljahre sollte man mal patchen, nicht wahr?
Außerdem ist es bei WP eben NICHT so, dass man blind updaten kann. Ich bin bei Kunden auch schon über Installationen gestolpert, bei denen ein Update des WP-Kerns erst einmal das Template gekillt hat und außerdem noch 2-3 Extensions den Geist aufgegeben haben.
Ob die Kosten in die Tausende gehen, hängt natürlich auch stark vom Projekt ab. Wurden aufwendige Extensions geschrieben, welche neu entwickelt werden müssen, wird es schnell teuer.
Ich hab letztens eine unserer eigenen Contao-Extensions, die auf der Contao 2.11 - API basierten, innerhalb von unter 2 Tagen auf die Contao 3.2 - API übertragen, dabei die Performance um 20% erhöht, eine geniale neue Funktion eingebaut und die allgemeine Flexibilität deutlich gesteigert. Die meiste Zeit ging dafür drauf, dass die Art und Weise, wie Medieninhalte (Bilder, PDFs,...) angesprochen werden, sich grundlegend geändert hat (und jetzt schneller & flexibler ist).
Bei sauberer Dokumentation der API sowie der ÄNDERUNGEN an der API ist es auch bei komplexen Extensions ziemlich simpel, die notwendigen Änderungen vorzunehmen.
Es ist ja selten so, dass man alles von Grund auf umhackt. Magento basiert z.B. seit jeher auf dem Zend-Framework. Meist werden nur punktuelle Veränderungen vorgenommen. Wenn von Anfang an z.B. magische Setter und Getter definiert waren, dann werden die auch in alle Ewigkeit weiter funktionieren. Ein selbst geschriebener SQL Query, den man nur per prepare($string)->execute($variable1,$variable2) zündet, wird auch weiter funktionieren, bloß weil neuerdings zusätzlich noch ein bequemer Query-Builder verfügbar ist. Kein "SELECT * FROM table WHERE id=5" mehr, wenn man statt dessen $collection = $model->getByID(5) sagen kann.
Begründungen, Artikel, News etc.? Nur weil ich noch nie mit CentOS, Fedora oder ähnlichem gearbeitet habe, behaupte ich nicht das es nur für Amateure ist 
