Skip to content

WordPress ist die bekannteste Blogsoftware - das führt zu vielen Updates

och nö! schon wieder! - Wordpress Update gefühlt Nr 19 in 3 TagenNein, hier im Blog nutze ich kein WordPress mehr, schon länger nicht. Und immer mal wieder überlege ich auch bei anderen Blogs umzustellen. Andererseits ist es eben mein Job, mit Software umzugehen. Je nach Einsatzzweck hat WordPress ganz klare Vorteile. Deshalb betreue ich eben doch einige Blogs, die mit WordPress laufen. "WordPress ist die bekannteste Blogsoftware - das führt zu vielen Updates" vollständig lesen

sdw-Dateien in Libreoffice öffnen und konvertieren

Screenshot sdw in Libreoffice öffnen klappt nichtGrundsätzlich kann Libreoffice die guten alten StarOffice-Dateien auch heute noch lesen. Unter Windows lässt es sich wohl nachinstallieren. Unter Linux sollte es beim Installieren entsprechend berücksichtigt werden. Gentoo nutzt use-flags, hier müsste das use-flag "binfilter" aktiviert werden.

Sabayon basiert auf Gentoo, insofern wäre es sinnvoll, wenn es auf dem selben Weg möglich wäre. Leider klappt das so nicht. Der Standardmanager Entropy lässt keine Änderung der use-flags zu. Sabayon rät davon ab, Portage und Entropy zu kombinieren, siehe auch das Howto hierzu. Sprich, es wäre möglich, aber nicht empfehlenswert.


"sdw-Dateien in Libreoffice öffnen und konvertieren" vollständig lesen

...was lange währt... s9y

miradlo.net bis 30.9.2012Ich habe mich ja bereits 2009 entschieden immer öfter lieber Serendipity als WordPress einsetzen zu wollen. Bei neuen Installationen habe ich das auch gemacht. Irgendwann vor gut eineinhalb Jahren hatte ich endgültig beschlossen, dass ich hier ein s9y will und kein WP mehr. Es war klar, dass es bei mehr als 400 Artikeln ein Konzept braucht, um das umzusetzen. Das inzwischen recht angestaubte WordPress-Theme sollte daher auch nicht mehr angepasst werden.

"...was lange währt... s9y" vollständig lesen

Ups: nicht gut! :( WP-Touch gehackt und WordPress 3.1.4

Wie schon öfter erwähnt, bin ich ja nicht unbedingt begeistert von der Anzahl der Updates bei WordPress, auch jetzt gerade steht ein sicherheitsrelevantes Update vor der Tür: Häufig bin ich eher genervt übers soundsovielte Update.

Pluginverzeichnis auf wordpress.org gehackt

Richtig schlecht ist jedoch das wohl gehackte Pluginsverzeichnis auf Wordpress.org :( Weitere Infos siehe auch: WP-Pluginverzeichnis gehackt Laut den deutschen WordPressentwicklern, haben sich Unbekannte Zugriff auf das offizielle Pluginverzeichnis verschafft und die drei populären Plugins AddThis, WPtouch und W3 Total Cache mit einer Backdoor ausgestattet. Durch diese Hintertür könnte wohl auf das betroffene System zugegriffen werden. Aus Sicherheitsgründen wurde alle Passwörter zurückgesetzt, darüber hatte ich mich gestern noch gewundert, die Meldung las ich jedoch heute eher zufällig, weil ich nach dem Update schaute. :( Wer in den letzten Tagen eins der Plugins aktualisiert oder installiert hat – sollte dringend auf die neue Version aktualisieren und das eigene Passwort ändern.

Passwörter zurückgesetzt

Erstaunlich ist allerdings die schnelle Reaktion mit dem Rücksetzen aller Passwörter. Leider hatte ich es bis heute mittag nicht mitbekommen, dass da ein dickeres Problem ist. Vielleicht erfährt ja jemand durch diesen Artikel davon. Ich habe jedenfalls mal überall die betroffenen Plugins aktualisiert, die eventuell die Backdoor enthalten haben könnten.

s9y Sicherheitsupdate oder schnelle Lösung

Bei Grischa las ich gerade, dass sein Blog gehackt wurde. Er empfiehlt daher entweder sofort Serendipity zu aktualisieren oder - je nach Nutzung - die schnelle Lösung zu nutzen. Bei uns laufen mehrere Serendipity-Blogs, ich wollte jetzt grad nicht mal eben mehrere aktualisieren. Ich habe es zunächst in einer lokalen Installation getestet und festgestellt, dass auch bei meinen Installationen noch alles funktioniert, wenn die Dateien fehlen. Nach einem zusätzlichen Live-Test online habe ich bei allen s9y-Blogs mal eben das Problem behoben. Der schnellste Weg ist mal eben über Konsole: server: cd /pfadzumprojekt/htmlarea rm contrib/php-xinha.php plugins/ExtendedFileManager/config.inc.php plugins/FormOperations/formmail.php plugins/HtmlTidy/html-tidy-logic.php plugins/ImageManager/config.inc.php plugins/InsertPicture/InsertPicture.php plugins/InsertSnippet/snippets.php plugins/SpellChecker/aspell_setup.php plugins/SpellChecker/spell-check-logic.php plugins/SuperClean/tidy.php Damit lassen sich auch mehrere Blogs schnell sichern, bevor etwas passiert. Nachmachen erwünscht! :)

Aktualisierungswahnsinn bei WordPress ::: die ständigen Updates

Ich betreue einige WordPress-Blogs und das nicht nur als Hobby. Ich habe mich inzwischen ja auch schon mehr als einmal dazu geäußert, was mich an WordPress deutlich stört, siehe die diversen Artikel auch dazu in der Kategorie WordPress. Ein erster Blick z.B. auf Wikipedia scheint gar nicht so schlimm, denn die neuen Versionen wurden wie folgt veröffentlicht:

WordPress-Versionen 2008 und 2009

  • WordPress Versions- und Pluginupdates Hinweise WordPress aktualisieren
  • WordPress 2.5 erschien im März 2008
  • WordPress 2.6 erschien im Juli 2008
  • WordPress 2.7 erschien im Dezember 2008
  • WordPress 2.8 erschien im Juni 2009
  • WordPress 2.9 erscheint voraussichtlich im  Dezember 2009
Das Ganze sieht schon anders aus, wenn die zwischendurch veröffentlichten kleinen Updates mit dabei stehen; die deutschen Versionen inklusive der Zwischenversionen laut Archiv von WordPress Deutschland:
  • WordPress 2.5 erschien im April 2008
  • WordPress 2.5.1 erschien im April 2008
  • WordPress 2.6 erschien im Juli 2008
  • WordPress 2.6.1 erschien im August 2008
  • WordPress 2.6.2 erschien im September 2008
  • WordPress 2.6.3 erschien im Oktober 2008
  • WordPress 2.6.5 erschien im November 2008
  • WordPress 2.7 erschien im Dezember 2008
  • WordPress 2.7.1 erschien im Februar 2009
  • WordPress 2.8 erschien im Juni 2009
  • WordPress 2.8.1 erschien im Juli 2009
  • WordPress 2.8.2 erschien im Juli 2009
  • WordPress 2.8.3 erschien im August 2009
  • WordPress 2.8.4 erschien im August 2009
  • WordPress 2.8.5 erschien im Oktober 2009
  • WordPress 2.8.6 erschien im November 2009
  • WordPress 2.9 erscheint voraussichtlich im  Dezember 2009
In diesem Jahr waren es damit bereits neun Updates. Meist ging es um Sicherheitsupdates, sprich gerade die Zwischenversionen sind damit wichtig und sollten auf jeden Fall aktualisiert werden.

Plugins und ihre Aktualisierungen

Ich kenne kein WordPress-Blog welches nicht auch einige Plugins einsetzt, um weitere Funktionen hinzuzufügen. Die Plugin-Updates kommen irgendwann zwischendurch und auch hier kann es sein, dass es um Sicherheitsprobleme geht, die gelöst wurden. Anfangs machte ich regelmäßig Plugin-Updates sobald diese veröffentlicht wurden. Doch als ich mehrfach danach einen oder mehrere Fehler hatte, weil die neue Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsthref="http://miradlo.net/bloggt/index.php?768-s"">Version eines Plugins zu irgendwas anderem nicht passte, hörte ich damit auf. Inzwischen aktualisiere ich Plugins nur in Notfällen, sprich wenn eine Sicherheitslücke zu stopfen ist, ansonsten werden Plugins nur noch gemeinsam mit einem Update aktualisiert. Die Zwischenversionen bestehen ja nur aus einigen Dateien, die überspielt werden können, es ist also keine vollständige Änderung aller Dateien nötig. An sich sollte diese Zwischenupdates daher problemlos funktionieren und keine Seiteneffekte haben. Doch das klappt leider oft nicht, mal ein Beispiel wie es bei einem Update lief, welches schon ein bisschen länger her ist:

Aktualisieren mehrerer Blogs

Wie schon mehrfach beschrieben, ich aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn einehref="http://miradlo.net/bloggt/index.php?37-s"">aktualisiere immer erst lokal, teste dann und spiele erst danach die jeweilige Änderung auch online ein. Einige Male habe ich es auf einem Testblog versucht automatisch zu aktualisieren, es klappte jedoch - wenn überhaupt -nie so, dass ich das bei einem Blog mit echten Inhalten risikieren würde.  Ich begann WordPress auf diversen Blogs zu aktualisieren. Ich lud mir WP 2.8.3 runter, so wie die aktuellen Versionen der genutzten Plugins. Ich hatte das erste Blog gerade aktualisiert und war dabei das zweite zu bearbeiten, als bereits das erste Plugin wieder nicht mehr aktuell war. Also auch da die neue Version runtergeladen. Abends beim Testen lief es auf meinem Rechner lokal erst mal ganz schlecht. Ein noch langsamerer Adminbereich als bisher schon, in weiteren Browsern entweder gleich schlecht benutzbar oder noch weiter verschlechtert. Ich bin schon einiges gewohnt, aber ich brauche wenigstens einen Browser, mit dem sich auch der WordPress-Adminbereich bedienen lässt.  Ich installierte mir einen Firefox ohne Add-Ons, damit ging es dann einigermaßen. Inzwischen liefen zwei Blogs auf 2.8.3 auch online. Noch während ich lokal die Updates für weitere Blogs testete, Plugins aktualisierte und den ein oder anderen Wunsch für Änderungen umsetzte, las ich dass die 2.8.3 auch keine gute Idee sei. Ich hatte jedoch schon die Updates bei 2.8.1 und 2.8.2 auf dem ein oder anderen Blog abbrechen müssen, weil ich bereits lokal feststellte, dass damit das Blog nicht mehr lief. Für die 2.8.3  kamen ständig neue Vorschläge, wie der unsichere Login zu reparieren wäre. Na bravo! Ich blieb also erstmal an den Anpassungen und Erweiterungen die in einigen Blogs zu machen waren. Am dritten Tag beschloss ich jetzt doch noch weiter zu aktualisieren und um das abzuschließen. Zunächst schaute ich was auf dem nächsten zu aktualisierenden Blog noch zu tun ist und: "Juhu! ein Update!" Ja, es ist toll, dass der Fehler damit behoben wird. Das ändert allerdings nichts daran, dass ich jetzt also erstmal die ersten beiden Blogs vom Tag zuvor erneut aktualisieren musste. Dieses Mal probierte ich es ohne nochmaliges Sichern und Plugins abschalten, solange war die letzte Aktualisierung ja noch nicht her, als das lokal lief, riskierte ich es auch online. Ja, die zwei nur von 2.8.3 auf 2.8.4 zu aktualisierenden Blogs waren tatsächlich kein Problem; alles andere aber schon. Ein Blog zickte nochmal bevor es sich überreden ließ, doch so zu tun, als sei alles in Ordnung. Zwischendurch musste ich jeweils wieder die online-Versionen aus Kundenprojekten holen, um nicht versehentlich was zu überschreiben, denn ich kann ein Blog ja nicht über zwei, drei Tage einfach abschalten.

Fazit WordPress nutzen

Die Updates sind in keinster Weise planbar, denn z.B.  die 2.9 war für November angekündigt, ob sie jetzt noch dieses Jahr kommt ist nicht klar. Die Zwischenversionen kommen, wenn eine Lücke bekannt wird und groß genug ist, um repariert zu werden. Ich kann jedoch in meinen Arbeitslauf nicht ständig vorsichtshalber drei Tage einplanen, in denen ich sofort, wenn ein Update erscheint, alles andere stoppe und absage, um mich dann um WordPress zu kümmern. Unterm Strich kostet mich eine Aktualisierung pro Blog zwischen einigen Stunden bis zu ein oder zwei Tagen, wenn eine Fehlersuche aufwändiger wird. Ginge es hierbei um ein Update pro Jahr, dann wäre es noch akzeptabel, bei einem Update etwa alle sechs Wochen geht das einfach nicht, denn kein Kunde ist bereit das nach Aufwand auch nur annähernd zu bezahlen. Denn selbst bei einem Stundensatz von nur 50 Euro wären das jährlich rund 2500.- Euro nur für Aktualisierungen und kleine Anpassungen. Ich bin deshalb inzwischen dazu übergegangen, dass ich für neu aufzusetzende Blogs WordPress nicht mehr anbiete, eine Ausnahme sind Portale mit WordPress MU und BuddyPress, weil sich da der Aufwand ja auf viele Einzelblogs verteilt und weil es zur Zeit keine echte Alternative dafür gibt.

Überflüssige Blogrolls? ::: Überbleibsel oder Hingucker?

Tanta aka Jürgen forderte vor kurzem dazu auf, auf die Blogroll, also die Links zu anderen Blogs in der Seitenleiste zu verzichten: "Kill your blogroll". Ich fasse im Folgenden mal zusammen, wie er das in seinem englischen Artikel begründet. Eine Blogroll ist automatisch in jedem Blog enthalten und deshalb nutzen die meisten sie, ohne weiter darüber nachzudenken. Auch wenn die Grundidee gut ist, dass man den Lesern zeigt, welche Blogs man selbst liest, so sind Blogrolls inzwischen doch eher nervig, weil:
  • Freundeliste Viele Blogrolls haben eine Kategorie Freunde. Dort finden sich die Blogs, von Menschen, die der Blogbetreiber persönlich kennt. Jedoch was nützen etwaige Freunde, dem Leser?
  • Menschen lesen heutzutage meist Feeds, nicht das Blog auf der Webseite Die meisten sehen die Blogroll daher gar nicht mehr.
  • Fast alle Blogrolls sind veraltet Die wenigsten aktualisieren ihre Blogroll wirklich so regelmäßig, dass sie genau das wiedergibt, was sie gerade bevorzugt lesen. Außerdem viele lesen auch in sehr vielen Blogs, wieviele davon werden in der Blogroll angezeigt?
  • Blogs sind nicht immer gut Die Blogroll sagt "Autor X ist lesenswert", keiner dieser Autoren ist immer gleich gut und gleich lesenswert. Empfiehlt man ein Blog und ein Leser folgt dem Link, kann es sein, dass gerade die drei aktuellen Artikel gar nicht gut und interessant sind, weil es womöglich die schlechtesten sind, die der Autor jemals schrieb. Blogrolls mögen sinnvoll sein, wenn man wirklich von Website zu Website geht und durch einzelne navigiert, um zu sehen was dort geschrieben wird. Jedoch heutzutage macht das kaum noch jemand.
Deshalb sind doch die direkten Links auf einen Artikel viel sinnvoller, denn da verlinkt man genau auf den guten Artikel, den man gerade meint. Je nachdem wieviel man selbst schreibt und wie es passt, können es Links innerhalb eines eigenen Beitrags sein, oder eben auch wöchentliche Linklisten. Auf diese Art bekommen die Leser tatsächlich genau die Eindrücke und Beiträge, von denen man selbst wollte, dass die eigenen Leser sie wahrnehmen und anschließend vielleicht das verlinkte Blog regelmäßig lesen oder auch nicht, wie auch immer, das sollte man den Lesern überlassen.

Blogroll aus meiner Sicht

Ähnlich wie Jürgen es in seinem Artikel beschreibt, hatte ich erst einmal eine Blogroll. WordPress packt da ein paar Links rein, die ich sowieso nicht wollte, also habe ich ein paar eigene eingefügt. Immer mal wieder räume ich die Blogroll schon auch auf, aber manche Blogs sind nur deshalb nicht drin, weil sie nicht in die Kategorien der Links passen, die ich angelegt habe. Ich denke an vielen Punkten passen die Argumente:
  • Ich habe jetzt keine Freundesliste, da ich im persönlichen Umfeld fast ausschließlich mit Menschen Kontakt habe, die kaum wissen was Blogs sind.
  • Aber ich selbst lese tatsächlich sehr selten auf der Website eines Blogs, sondern gerade wenn ich ein Blog regelmäßig lese, dann nur im Feedreader. Zum Kommentieren verirre ich mich mal auf ein Blog. Einige ganz wenige lese ich noch, obwohl sie einen gekürzten Feed anbieten, doch da lese ich viel seltener auch mal einen ganzen Beitrag, noch seltener kommentiere ich dort.
  • Manch ein Blog war noch in meiner Blogroll, als ich es schon nicht mehr las. Mir fiel ähnliches bei vielen auf, die basicthinking noch lange nach dem Verkauf unter Robert Basic verlinkt hatten.
  • Mir geht es bei einigen Blogs so, dass ich immer mal wieder einen Artikel sehr gern lese, aber doch mit vielen anderen Beiträgen nichts anfangen kann. Das ist nicht schlimm, ich weiß das für mich und sortiere entsprechend. Aber keins dieser Blogs würde es in die Blogroll schaffen, weil es nicht regelmäßig genug für mich lesenswerte Artikel gibt.
Ein weiterer Punkt ist, dass es mir schon zu lästig ist alles zu pflegen. Je nachdem wie man abonniert, lässt sich das automatisieren, aber das würde ich nicht wollen. Ich lese sicher regelmäßig deutlich über hundert Blogs, aber eben sehr selektiv. Je nachdem wieviel Zeit ich habe, lese ich auch mal eine Woche gar nicht, wenn dann 6000 Beiträge anstehen, lese ich noch weniger als im Durchschnitt. Genau so und nach welchen Kriterien, ich dann schneller oder langsamer sehr viel als gelesen markiere, lässt es sich in der Blogroll nicht abbilden.

Weg mit der Blogroll?

Nein, auch wer jetzt im Feed liest, nein im Moment gibts die Blogroll und auch in schon länger nicht aktualisierter Form. Aber ja, auf Dauer kommt die Blogroll vielleicht weg. Ich nutze ja schon immer eher eine eingeschränkte Blogroll und verteile je nach Thema zwischen hier und uteles Blog. Trotz aller Einschränkung sind auch das nicht immer die echten Top-Blogs, die mir grad am wichtigsten sind. Ich verlinke sowieso gern und viel, sei es in Artikeln oder mit wöchentlichen Linklisten. Im Grunde zeigen diese Beiträge eher, was mich grad interessiert hat. Wobei natürlich auch einige Links vorkommen, die sich nur auf einen Artikel beziehen, von dem ich irgendwo las, nicht jedes Blog, jede Webseite, die verlinke, lese ich regelmäßig. Ich werde jetzt nicht sofort alles umstellen, aber ich werde mir mal genauer überlegen, warum ich eigentlich eine Blogroll habe...

Erwartungen und Umgang mit Open-Source-Software in Unternehmen

In den ersten Teilen ging es um die Studie als solche, sowie um Zufriedenheit mit der Open-Source-Software und der Rolle, die sie in Unternehmen spielt. Bei den folgenden Punkten geht es um die Frage, was erhoffen sich die Anwender im Unternehmen von OSS, wo gibt es Schwierigkeiten. Die Ergebnisse der Nutzung des externen Supports werden ebenfalls beleuchtet.
  • Was versprechen sich Unternehmensanwender von Open Source? Wo erleben sie Probleme?

    • Kosten sparen ist der meistgenannte Grund für den Einsatz, gefolgt von offenen Standards und Herstellerunabhängigkeit
    • Gründe für den Einsatz sind außerdem Plattformunabhängigkeit und die Tatsache, dass OSS in manchen Bereichen Standard ist (da schlägt sicherlich z.B. der Apache als Webserver zu Buche)
    • Motive für den Einsatz sind vor allem:
      • Freiheit (insbesondere Zugang zu offenen Standards und Herstellerunabhängigkeit)
      • offene Quellen (insbesondere Zugriff auf Quelltexte, Anpassbarkeit)
      • Qualität (insbesondere die Leistungsfähigkeit, sowie die hohe Zuverlässigkeit und Sicherheit)
      • Pragmatismus (insbesondere die einfache Möglichkeit etwas erst einmal testen zu können, die Bekanntheit großer Open-Source-Lösungen und das interne Know-how zu bestimmten Lösungen)
    • Je länger und intensiver OSS eingesetzt wird, desto wichtiger werden Gründe, wie die technische Qualität. Trotzdem nennen rund 90% er erfahrenen Anwender das Sparen von Lizenzkosten, jedoch nur 76% der Einsteiger als Beweggrund  für den Einsatz von Open-Source-Software.
    • Hindernisse für den Einsatz sind vor allem die Integration bestehender Software. Dies trifft noch stärker auf große Unternehmen zu, da hier die Komplexität der eingesetzten Software steigt.
    • Ein weiteres Hindernis ist für einige der Mangel an qualifiziertem Personal, auch hier wieder vor allem in den größeren Unternehmen.
    • Manche nennen noch fehlende oder fehlerhafte Funktionen, als ein zumindest zuweilen auftretendes Problem.
    • Wobei schlussendlich 10% der Teilnehmer keine Hindernisse wählten.
Zehn Prozent sehen keine Hindernisse, keine Schwierigkeiten mit Open-Source-Software, andere überlegen vorm Einsatz was für und was gegen OSS spricht. Die Motive für den Einsatz haben sicher auch mit den Erfahrungen mit lizensierter Software zu tun. Wenn Software teuer ist, sind Probleme und Schwierigkeiten deutlich störend als wenn sie nichts oder weniger kostet. Erstaunt hat mich, dass die Zahl derer die Lizenzkosten als einen Grund für den Einsatz einsetzen steigt mit längerer Nutzung. Ich hatte eher erwartet, dass Neueinsteiger überwiegend die Kosten sehen, gegenüber anderen Gründen, wie der Herstellerunabhängigkeit, der Anpassbarkeit und ähnlichem. Für mich kommen alle Gründe zusammen, ich kann nicht direkt einen deutlich hervorheben. Wichtiger als die Lizenzkosten sind mir jedoch alle weiteren Gründe. Wenn eine Software gut ist, stört es mich nicht so sehr dafür auch zu bezahlen. Im Vergleich der Software, die ich einsetze stehen jedoch der Preis einer Lizenzsoftware und ihre möglichen Vorzüge in keinem akzeptablen Verhältnis. Beim Gespräch in unserem Unternehmen war die Sichtweise ähnlich, interessant ist frei wählen und ausprobieren zu können. Wenn ein Programm nicht bietet, was man sich erhofft probiert man ein anderes. Auch Linux selbst ist ja genau so offen, es gibt eine Vielfalt an Distributionen und ein Wechsel ist recht leicht möglich. Ebenso gilt das für die grafische Oberfläche, ob man KDE, Gnome oder eine der anderen GUIs bevorzugt ist Geschmackssache und kann auch recht einfach geändert werden. Bei lizensierter Software sind solche, schnellen und einfachen Wechsel kaum möglich, hat man doch jedesmal dafür bezahlt. Sehr angenehm ist die Geschwindigkeit bei Open-Source-Software, neue Möglichkeiten und Ideen werden viel schneller umgesetzt und sind verfügbar. Die Anpassbarkeit einzelner Anwendungen ist heute nicht mehr ganz so wichtig, wie noch vor einigen Jahren, da es fast immer Alternativen gibt, die genau das bieten, was der einen Anwendung vielleicht fehlt. Trotzdem erschrecke ich mich immer wieder bei lizensierter Software, wie wenig da meist angepasst werden kann.
  • Inwieweit wird externer Support in Anspruch genommen?

    • Zusammengefasst wird sehr wenig externer Support genutzt, nur 35% gaben an, sich externe Unterstützung zu holen.
    • Diejenigen, die externen Support nutzen sind zu 90% zufrieden oder sehr zufrieden mit diesem.
    • Je größer das Unternehmen, desto häufiger wird auf externen Support zurückgegriffen.
Für uns ist der externe Support ebenfalls kein Thema, wir passen unsere Software selbst an, aktualisieren diese selbst und mal abgesehen von Recherchen im Netz oder direkten Anfragen bei einem Pluginautor, nutzen wir zur Zeit keinen externen Support. Ich denke das liegt aber auch an der Unternehmensgröße, denn je mehr Software genutzt wird und je komplexer die Infrastruktur der eingesetzten Software ist, desto spezialisierter muss das Wissen der Betreuenden sein. Da lohnt es dann doch oft auf einen Fachmann zurückzugreifen, welcher schneller eine Lösung für den jeweiligen Wunsch oder das bestehende Problem findet. Im vorläufig letzten Teil dieser Serie geht es um die genutzte Software, welche Open-Source-Software  in welchem Maß eingesetzt wird.

Plugins vertragen sich nicht: Link Indication und Quote Comments

Teil 871 der "never ending story". Ich bastele ja in letzter Zeit, nach dem Update auf WordPress 2.7 an einigen Blogs, um das ein oder andere an zusätzlichen Möglichkeiten miteinander zu verbinden. Dabei habe ich einige Plugins eingebaut, manche wieder entfernt und hatte teils auch engeren Kontakt mit den Autoren. Schlussendlich lief Quote Comments, war valide, tat was es soll und alles war gut. Je nach Blog fand ich die Idee, Links zu markieren, ob sie intern sind oder nach außen führen gut. Eine weitere nette, zusätzliche Möglichkeit, die es erleichtern kann, sofort einzuschätzen wohin ein Link führt. Ich testete das Link Indication Plugin, wie immer erst lokal, es klappte alles prima, es lief und zeigte im ein oder anderen Blog, wohin die Links führen, prima!

Zitate vorführen

Ein, zwei Tage später wollte ich jemand zeigen, wie die Zitate funktionieren, dass ein ganzer Kommentar zitiert wird, wenn man auf den Link klickt, bzw. eben nur Teile davon, wenn man den gewünschten Text markiert. Tja, wollte! Denn das klappte nicht, da kam kein Zitat, weder direkt, noch nach Markieren eines Textteils. Och nö, nicht schon wieder! :-( Inzwischen testete ich mal genauer. Zunächst suchte ich nach anderen Plugins, die sich auf die Kommentare beziehen, aber da gab es keinen Fehler. Daher suchte ich dann nach allem, was geändert war, seit ich das letzte Mal Quote Comments getestet hatte und fand dabei was nicht klappt:

Link Indication und Quote Comments vertragen sich nicht

Läuft nur eins von beiden ist alles gut, es tut was es soll. Sind beide aktiviert, dann läuft Link Indication weiterhin, aber Quote Comments zitiert nichts mehr. Ich weiß nicht, was sich da verhakt. Ich kann auch nicht einschätzen, welches der beiden "schuld ist" oder ob es einfach ein unglücklicher Zufall ist. Ich lasse jetzt mal verschiedene Kombinationen stehen und schreibe die Autoren an, vielleicht hat ja einer der beiden eine Idee. Sonst muss ich halt in Zukunft je nach Blog entscheiden, was wichtiger ist.

Eckpunkte

  • alle getesten Blogs laufen mit WordPress 2.7
  • am Theme liegt's nicht auch mit dem Default-Theme läuft es nicht
  • aktivieren und deaktivieren anderer Plugins hat keinen Einfluss auf das Verhalten der Zitate

Blogs und Varianten der Plugins

Aktiviert ist/sind:
  • hier im Blog nur Quote Comments
    • und es funktioniert
  • in Rolands Guggat emol Blog nur Link Indication
    • und es funktioniert
  • in uteles Blog Link Indication und  Quote Comments [aktualisiert: 13.2. da mir dort die Zitate wichtig sind habe ich jetzt auch hier Link Indication deaktiviert]
    • damit läuft Link Indication weiterhin
    • Quote Comments zitiert nicht mehr
Jetzt bin ich mal gespannt, ob einer der Autoren eine Idee hat.  Ärgerlich finde ich einmal mehr, dass tatsächlich jede kleine Änderung sich an ganz anderer Stelle auswirken kann. In Kombination mit automatischen Aktualisierungen nicht nur von Plugins, sondern demnächst auch von WordPress selbst ist das ziemlich ungeschickt. Denn das automatische Aktualisieren führt noch leichter dazu, dass mal eben per Knopfdruck etwas geändert wird, mit dem Risiko, dass an anderer Stelle plötzlich irgendwas nicht mehr funktioniert. So schön die vielen Möglichkeiten mit Plugins sind, wer Wert auf ein stabiles und funktionierendes System legt muss schon sehr intensiv testen, um sich das zu erhalten. Ich wünsche mir eine Sicherheitsschicht mit definierten Schnittstellen für Plugins, so dass die sich nicht in die Quere kommen können. Nö, mich interessiert dabei nicht, dass das so nicht machbar ist... ;-)

Meine Vorgehensweise beim gentoo-Update

Ich habe mittlerweile in unserer Firma einen ganzen Zoo von Rechnern zu verwalten. Das kommt daher, da wir im Lauf der Jahre für die unterschiedlichsten Aufgaben die diversen Architekturen angeschafft haben. Ein Update des Betriebssystems kann sehr viel Arbeitszeit kosten, wenn man sich nicht ein paar Vorgehensweisen angewöhnt mit denen die Rechner mit sich selbst beschäftigt sind. Ich habe absichtlich auf die Installationsanleitung von gentoo verwiesen, da die Vorgehensweise sich bei jedem Update wie bei einer Neuinstallation verhält. Folgende Schritte führe ich bei jedem Rechner bei einem Update durch:

emerge --sync

Klar, damit wird erst einmal der Portage Tree wieder aktualisiert. Ohne diesen Befehl ergibt ein Update keinen Sinn. In einem Terminal hole ich mit den folgenden zwei Befehlen die neuen Sourcen:

emerge --fetch-only --update --deep system

emerge --fetch-only --update --deep world

Im Normalfall gibt es ein paar Sourcen, wie zum Beispiel Java 1.4, die mit fetch-restriction ausgestattet sind. Diese Sourcen müssen manuell heruntergeladen werden. Somit schaue ich nach ca. einer halben Stunde welche Sourcen manuell installiert werden müssen. Parallel dazu lasse ich in einem zweiten Fenster die Aktualisierung der Systemkomponenten durchführen:

emerge --keep-going --update --deep system

Mit --keep-going wird erreicht, dass bei Fehlern die Installation der restlichen Pakete dennoch vorangetrieben wird. Somit kann man über 80% der Pakete ohne manuellen Eingriff aktualisieren und spart sich die Totzeiten weil der Rechner auf den manuellen Eingriff wartet. Nachdem die Systemkonfigurationen wieder aktuell sind rufe ich den Befehl

emerge --keep-going --update --deep world

auf. Und dann lass ich die Maschine alleine, oder arbeite an ihr einfach weiter. Die Aktualisierung läuft weitgehend im Hintergrund und je nach Prozessorleistung kann ich gut noch nebenher arbeiten.

Fazit

Mit dieser Vorgehensweise kann ich mehrere Rechner gleichzeitig aktualisieren und benötige nur wenige Minuten Arbeitszeit für den einzelnen Update. Bei Fehlern oder massiven Neuerungen, muss ich natürlich die übliche Zeit investieren, um die Maschinen wieder stabil zum Laufen zu bringen. Die Zeit, die ich früher zur Kontrolle und zum Wiederanlauf der Aktualisierung benötigt habe, konnte ich mit dieser Vorgehensweise deutlich reduzieren.
tweetbackcheck