Wären wir gerade beim Thema Essen, würden wir nun eine selbst zubereitende Speise mit einem Fertiggericht vergleichen. Das Thema wäre schnell vom Tisch: meine Single-Kochkünste haben mich selten wirklich überzeugt, bitte ein Fertiggericht!
Wir sprechen aber glücklicherweise nicht vom Essen, sondern – klar – von Linux! Dort gibt zwar noch keine essbaren Fertiggerichte, aber leicht installierbare Software über die Paketverwaltung. Mit wenigen Befehlen sind komplette Softwarebäume installierbar und auch wieder von der Platte. Und wenn sie schon mal auf der Platte landen, hält sie die Paketverwaltung fortan auch in Sachen Sicherheitsaktualisierungen aktuell. Ein regelmäßiges Update reicht aus, um unbeschwert schlafen zu können (okay, viele Anwender schlafen auch ohne Updates beunruhigend gut).
Doch Software kann auch über eine andere Möglichkeit ihren Weg auf das System finden: über die Quellen, eine der Hauptvorteile von Open Source. Allerdings müssen die Quellen – wenn wir nicht gerade auf ein PHP Skript blicken – auch noch zu einem Fertiggericht werden, dazu ist der Kompilierungsvorgang notwendig. Zudem kommt Software meist in Form vieler Komponenten daher, die je nach Bedarf integriert werden können. Oftmals benötigen neben der eigentlichen Software auch deren Komponenten zusätzliche Helfer in Form weiterer Software oder Bibliotheken. Nutzt man eine Paketverwaltung, so ist man fein raus: diese Systeme wissen einfach schon, dass man für das Kochen von Spaghetti Salz benötigt. Wenn man dagegen den manuellen Weg einschlägt und selbst kompiliert, muss man sich die nötigen Zutaten selbst zusammensuchen. Und das ist nicht immer ganz leicht. Ich selbst gehe da schonmal nach dem Trial & Error Verfahren vor: Software kompilieren, Fehler analysieren und auf zusätzliche Zutaten schließen. Dann steht schon das nächste Problem vor der Tür: nun kennen ich zwar die Zutat, weiß aber nicht, in welchem Paket diese Zutat steckt. Da hilft nur eine Recherche im Web oder in der Paketverwaltung selbst. Natürlich wären auch die Zutaten manuell beschaffbar, aber damit heimst man sich einen immensen Aufwand ein, wenn man Großteile des Systems am Schluss manuell pflegen darf. Nachdem das Trial & Error Verfahren einige Male in einer Schleife gelaufen ist, gelange ich dann irgendwann an den Punkt, an dem das ganze kompilierbar ist. Der Rest ist nur noch Dokumentationssache: die nötigen Zutaten und deren Paketfundort wird meistens noch kurz in einer Textdatei oder im privaten Wiki festgehalten. Schließlich möchte man ja nicht bei Systemwechseln wieder auf die Suche gehen (bei Distributionswechseln fängt der Spaß dagegen wieder an..).
Doch wann lohnt sich der Weg über die Paketverwaltung und wann darf man auch mal auf die Quellen zurückgreifen? Es mag manche geben, die gerne grundsätzlich Hand anlegen möchten und Großteile über die Quellen selbst zusammenkompilieren. Doch nicht alle können oder wollen Köche sein. Abends möchte man ja schließlich nach einem langen Arbeitstag auch nicht mehr Stunden in der Küche stehen, so sieht es auch beim eigenen System aus. Ich beziehe einen Großteil meiner Software über die Paketverwaltung und greife nur an jenen Stellen zu den Quellen, an denen mir die neuste Version einer Anwendung oder eine eigene Konfiguration wichtig ist. Dafür habe ich mich in meinem Fall bei Apache, PHP und MySQL entschieden, da ich diese Software für einen Großteil der Dienste und für eigens programmierte Scripte benötige und auch gerne mal auf neue Funktionen zurückgreife. Nützlich ist da auch, dass man sich mit dem Selbstkompilieren etwas genauer mit dem Hintergrund einer Software auseinandersetzt. Dinge wie den Mailserver beziehe ich dagegen gerne über die Paketverwaltung. Da muss es eben nur fluppen, die Konfiguration ist schon komplex genug.
Für die meisten Wünsche reicht die Paketverwaltung also völlig aus. Nur bei häufig verwendeter und individuell eingerichteter Software, über die ich auch etwas mehr erfahren möchte, greife ich aber auch vereinzelt gerne zu den Quellen. Im Zweifelsfall für die Paketverwaltung.
Archiv der Kategorie: Computing
Erlebnisse aus der Welt der IT
Kostenfaktor Housing
Interessehalber habe ich mich kürzlich in Sachen Serverhousing schlau gemacht, um das aktuelle Kostenniveau in Erfahrung zu bringen. Und siehe da: Housing kann auf den ersten Blick verlockend wirken. Die meisten Anbieter wenden bei den Housingangeboten gerade für den Bereich Traffic noch keine Mischkalkulation an, aber siehe da: mit Hetzner gibt es in der Tat einen, der wie bei den dedizierten Angeboten 5.000 GB inkludiert. Mischkalkulation ahoi! Ich würde mal glatt aus dem Stegreif behaupten, dass es durchaus Housingkunden gibt, die auch mit wenig Traffic auskommen, dafür aber individuelle Ansprüche an die Hardware haben, die sich deutlich besser mit einem Housingangebot abbilden lässt. Zudem bewegen sich die Kosten für Zusatztraffic heute ohnehin auf einem niedrigen Niveau. Haben wir vorhin nicht von verlockend gesprochen? Ja, auf den ersten Blick. Auf den zweiten wird dann klar, dass Strom ein teures Gut ist – mit der wagen Betrachtung, dass er noch deutlich teurer werden wird..
Die kWh-Preise sind bei Housing Anbietern natürlich so breit gestreut wie auf dem Privatmarkt. Im Normalfall bewegen sie sich aber zwischen 20 und 30 Cent je kWh. Die nachfolgende Betrachtung wird etwas wage, da ich den Energieverbrauch eines Systems um ehrlich zu sein in der Vergangenheit höchstens für die Netzteilanforderung herangezogen habe. Für ein Desktopsystem, das keinen 24/7 Service leisten muss, dürfte dieser Weg auch heute noch in Ordnung sein, bei einem Server mit individuellen Stromkosten sieht das natürlich anders aus.
Eine grobe Rechnung anhand meines dedizierten Servers ergab bei einer mittleren Auslastung (200 W) einen geschätzten Verbrauch von etwa 1752 kWh pro Jahr , das wäre immerhin der Gesamtverbrauch eines Singlehaushalts und entspricht bei einem angenommenen Preis von 0,23 Cent je kWh immerhin 33,58 EUR. Diese Annahme ist natürlich sehr wage, ich habe diese Rechnung Pi mal Daumen anhand eines Verbrauchsrechners vorgenommen und den minimalen und maximalen Stromverbrauch der CPU gemittelt. Unter Annahme dieser Werte würde also das Housing der gleichen Hardware schonmal 33,58 EUR Stromkosten erzeugen und damit sind noch keine Kosten für zusätzliche Komfortmerkmale enthalten, die oft bei dedizierten Servern beigepackt werden. Selbst wenn – wie bei Hetzner – 50 Watt Strom schon inklusive sind: die restlichen 150 Watt würden immer noch eine gute Zusatzsumme ausmachen. Beachten sollte man auch, dass defekte Hardware nicht mehr einfach ausgetauscht wird und dies ggf. auch nochmals Zusatzkosten verursachen kann. Mit diesem Beitrag möchte ich Housing keinesfalls als zu teuer oder untauglich hinstellen. Es ist einfach ein anderer Markt und für den Anbieter nicht in gleicher Weise kalkulierbar wie das dedizierte Massengeschäft. Ich war nur gespannt, ob Housing für mich als kleinen, aber technisch interessierten Fisch eine Alternative zum dedizierten Hosting darstellen könnte, ohne größere Zusatzkosten veranschlagen zu müssen (die Finanzierung der eigenen Hardware mal außer Betracht gelassen). Neben einigen interessanten Erkenntnissen hat es auch gezeigt, wie komfortabel das dedizierte Servergeschäft für den kleineren Bedarf, wie er bei mir herrscht, ist. Ohne großes Risiko kann man heute für relativ wenig Geld eine dedizierte Lösung mieten, für die weder Hardwarekosten noch größerer Aufwand anfällt. Für mich bleibt das erst einmal die beste Wahl.
Git ist In – aber benötigt Subversion überhaupt Ersatz?
Auch ohne mich direkt auf die Suche nach passenden Artikeln zum Thema Git gemacht zu haben ist es sehr schwer, den Begriff Git auf irgendeiner Projektwebsite eines Open Source Projekts zu ignorieren. „Moved to Git“ oder so ähnlich titulieren viele der entsprechenden Ankündigungen.Irgendetwas muss also dran sein, an dem noch relativ jungen Versionsverwaltungssystem. Nun gut, 6 Jahre ist in der aktuellen Zeit schon wieder alt, aber nennen wir’s doch eher reif! Für die Entwicklung meines kleinen Forensystems Yella setze ich bislang auf Subversion. Nun gut, die Versionsverwaltung hat dabei auch nicht viel zu tun: keine Branches, kein Merging, nur ein Entwickler respektive Repository. Würde Git etwas daran ändern können? An Subversion schätze ich die vielfältigen Tools. Angefangen von lokalen Helfern wie TortoiseSVN bis hin zu Webstatistiken per StatSVN oder schicken Webrepositories via WebSVN: selbst für kleine Projekte sind nützliche Dinge vorhanden. Aber auch Git hat hier mittlerweile einiges zu bieten. TortoiseGit schickt sich an, das Pendant zur SVN-Variante zu werden und Weboberflächen gibt es auch hier zu genüge. Die steigende Popularität von Git hat also auch ganz praktische Früchte hinterlassen. Nun aber wieder zurück zu den eigentlichen Kernthemen. Git ist als verteiltes Versionsverwaltungssystem zu betrachten, was ganz einfach heißt: kein Server nötig, die Entwicklung kann vollständig lokal geschehen. Nettes Feature, aber noch kein Killerkriterium. Schauen wir lieber auf die eigentliche Entwicklungsmöglichkeiten und die sind bei Git sehr flexibel: das gesamte Branching und Merging Konzept scheint auf den ersten Blick relativ einfach gestaltet zu sein. Um ehrlich zu sein, war das auch der Punkt, warum ich darauf bei Subversion verzichtet habe. Bei Git könnte ich mir durchaus vorstellen, das Branching Konzept anzuwenden, selbst für so ein kleines Projekt wie Yella. Weitere Vorteile, die bei Git angepriesen werden, sind unter anderem das Staging Konzept (ein Commit muss nicht alle Änderungen enthalten), die Anpassung von Git an den Entwicklungsablauf des Projekts (und nicht anders herum) oder die Schnelligkeit. Diese Dinge spielen bei mir aber eher eine untergeordnete Rolle, doch auch so scheint Git durchaus eine attraktive Sache zu sein. In Sachen Dokumentation sticht Git hervor. Neben zwei Open Books existieren viele Seiten mit Tipps & Tricks. Für eine 6 Jahre alte Software ist das erstaunlich viel Material, auf unterschiedlichste Art präsentiert. Mein vorläufiges Fazit lautet folglich: Git hat es durchaus verdient, näher getestet zu werden und ist auf den ersten Blick sehr reizvoll. Aber auch Subversion wird weiterhin weiterentwickelt und zielt eben auf einen ganz anderen Ansatz. Daher gibt es auch keine Gründe, eine vorschnelle Entscheidung für ein System treffen zu müssen.
Revolution, in kleinem Maße
Wer Benutzer nicht vergraulen möchte, setzt wohl eher auf Evolution statt Revolution. Dennoch ist das neue Aussehen und die neuen Anordnungen in Firefox 4 in Sachen Usability vielleicht auf den ersten Blick etwas gewöhnungsbedürftig, aber auf Dauer werden sie – wie auch einst die Ribbons in Office 2007/2010 (ohjeh, da könnten wir wieder einen Glaubenskrieg starten!) – ihre nützliche Seite zeigen. Das fängt bei Details wie der Anordnunge der Option „Link in neuem Tab öffnen“ an erster Stelle (bislang war die erste Option das Öffnen in einem neuen Fenster) an und hört beim neuen Add-on Manager auf. Aber wer den Firefox täglich nutzt – und das tun sicherlich viele – wird diese Dinge schätzen lernen. Oder eben auf die alte Oberfläche wechseln (zwischenzeitlich tuts vielleicht hin und wieder auch die alt-Taste). Für Nutzer von Google Chrome oder Opera dürfte die Oberfläche indes schon ein alter Hut sein.
Vieles ist agil geworden
Du bist agil, ich bin agil, wir sind agil. Aber noch mehr ist agil. Software beispielsweise. Früher sah das noch ganz anders aus: feste Releasezyklen, regelmäßige Verschiebungen, enttäuschte Kunden, Ungewissheit. Durch die Agilität hat sich heute vieles geändert. Roadmaps werden planbarer, neue Releases erscheinen zyklischer. Zwar mit weniger neuen Funktionen, dafür aber mit Kontinuität. Was ist uns persönlich lieber? Lange mit einer Beta Version eines Produkts anbandeln, in die ständig neue Entwicklungsideen fließen und es so zu fast keinem Ende der Entwicklung mehr kommt oder feste Releasezyklen, zwar etwas kleiner, aber man hat doch jedesmal gewisse Neuigkeiten? Lange Zeit war ich auch eher für längere Releasephasen, doch mittlerweile finde ich den agilen Verlauf deutlich sympatischer. Vor allem auch dadurch, dass viele Softwareprojekte mittlerweile diesem Konzept folgen. Google Chrome dürfte da ein Vorreiter sein, so kreative Zyklen lassen sich beispielsweise bei Mirosoft wohl kaum verwirklichen. Ja, Agilität erfordert auch andere Organisationsstrukturen und diese sind gerade bei Open Source Projekten deutlich schneller umzustellen. Daher wird heutzutage auch gerade Open Source Software oft nach agilen Konzepten entwickelt. Gerade eben hat sich mit Horde wieder ein Projekt mehr dazugesellt.
Agilität wird uns also künftig noch häufiger erwarten. Dann werden wir vielleicht nicht mehr darüber streiten, warum ein Release später veröffentlicht wird, sondern wieso es ein Feature nicht mehr in ein Release geschafft hat. Irgendwas muss ja für den Stammtisch übrig bleiben.. 😉
Firefox 4 ist (fast) da – und ich bleibe dabei
Selbst wenn man nicht allzu viel riskieren möchte, kann man schon heute ruhigen Gewissens die finale Version 4 von Firefox über die Mirrors beziehen. Morgen erscheint er dann ganz offiziell. Wer noch keinen Blick darauf geworfen hat, wird sich neben der neuen Oberfläche – die sich deutlich besser in Windows 7 einfügt – auch über einen neuen Add-on Manager, neue Tabfeatures und einiges mehr freuen dürfen. Dabei bleibt sich Firefox trotzdem in gewisser Weise treu, zumindest bis zur jetzigen Version: auch Version 4 hatte einige Verspätung. Künftig soll das anders werden und möglicherweise das Chrome Releasesystem zum Zuge kommen, sodass uns möglicherweise Firefox 5 schon in 16 Monaten erwarten könnte (dann natürlich mit nicht ganz sovielen neuen Funktionen wie in Firefox 4 ). Schnellere Releases und mehrere Stränge – mal sehen, inwiefern das unser Firefoxkonsum ändern wird.
Eins bleibt jedoch festzuhalten: ich werde auch weiterhin dem Firefox treu bleiben. Die Tage ist der Internet Expler 9 erschienen, bislang konnte ich aber nur einen kurzen Blick darauf werfen. Festzuhalten bleibt, dass auch der IE in der neusten Versionen einen größeren Schritt nach vorne gemacht hat. Ein neuer Download Manager (bzw. die Erstintegration), dazu eine Sicherheitsprüfung aller Downloads. Und das war beileibe nicht alles. Auch wenn ich den Internet Explorer auch künftig nicht regelmäßig privat nutzen werde, so ist es allemal erfreulich, dass man auch bei kürzeren Surfsessions mit ihm etwas angenehmeres in den Händen hält.
Auch Opera hat seine Vorzüge und ich wäre möglicherweise gar nicht mal so abgeneigt, dem Norweger einmal eine größere Chance einzuräumen. Wenn ich denn Bedarf hätte. Denn ganz ehrlich: ich finde auf den ersten Blick Google Chrome, Opera – und nehmen wir einfach mal den neuen IE 9 mit dazu – gar nicht wirklich schlecht. Aber ich habe mich in den letzten Jahren so sehr an den Firefox gewöhnt, dass ich keinen Umstiegsgrund habe. Alles mit dabei, was ich benötige. Immer noch hervorragende Erweiterungsmöglichkeiten, in Sachen Geschwindigkeit kann ich nicht meckern und er ist eben Open Source (das i-Tüpfelchen sozusagen). Vielleicht würde das ganze anders aussehen, wenn ich nochmal jünger wäre und mehr Zeit hätte. Aber irgendwann hat man eben seine Lieblinge zusammen. Happy browsing!
Virtuell, aber einfach
In den letzten Wochen habe ich immer mal wieder auf virtuelle Lösungen für eine dedizierte Serverlösung geschaut und dabei interessante Erkenntnisse gewonnen. Vor der Recherche wäre mir grundsätzlich nur der VMWare Server als produktive und vor allem einfache Lösung eingefallen, doch schon bei der ersten Recherche wurde mir klar, dass das Ding schon wieder eingestellt wurde. ESXi wäre eine Nachfolgelösung, doch so richtig überzeugen konnte mich das auch nicht: erst einmal benötigt man kompatible Hardware, bei den Hetzner Servern also eine zusätzliche Intel Netzwerkkarte. Dafür wäre ein zusätzliches Paket notwendig, für eine private Lösung ist das etwas zu viel „Overhead“. Zudem fehlt eine Weboberfläche, die gerade einen großen Anreiz in Sachen Virtualisierung darstellt.
Und so gingen die Recherchen weiter und ich kam auf Proxmox. Auf den ersten Blick hatte ich dieses Produkt vor langer Zeit falsch eingeschätzt, wie sich schnell herausstellte. Kurzum: Proxmox ist einfach zu installieren, unterstützt KVM und OpenVZ, steht unter einer Open Source Lizenz und bietet eine gelungene Weboberfläche.
Nun fehlt mir nur noch die Zeit, um das Ding auch mal anzutesten. Eine spätere Servervirtualisierung könnte ich mir dann durchaus vorstellen. Dann aber geplanter als das letzte Serverupgrade auf Debian Squeeze.. 😉
That’s an error
Gallery wieder online
Nach längeren Überlegungen ist es nun soweit: die Gallery steht wieder online. Noch ist sie relativ spärlich befüllt, das wird sich im Laufe der nächsten Zeit aber noch ändern.
Die Gallery steht unter http://gallery.theXME.de online.
Upgrade auf WordPress 3.1 & ein neues Design
In den vergangenen Tagen war es endlich soweit: die finale WordPress Version 3.1 ist – deutlich verspätet – erschienen und hat damit ganz indirekt neben dem Upgrade auch den Startschuss für das neue theXME.de Design gegeben. Nun gut, das Design selbst ist relativ kurzfristig entstanden und zum jetzigen Zeitpunkt noch nicht ganz final. Neumodisch würden wir das jetzt vielleicht als Beta bezeichnen, aber da der Trend dazu geht, alles neue erstmal als Beta zu bezeichnen, werde ich davon absehen. Ein wenig Final ist es dennoch, nur der letzte Schliff fehlt vielleicht noch (allerdings war das beim damaligen Design ebenfalls so, es hat sich erst nach und nach entwickelt). Aber über grundsätzliche Geschmäcker lässt sich streiten, daher werfe ich einfach mal die folgende Umfrage in den Raum: wie gefällt euch das neue Design grundsätzlich? Spricht es euch auf den ersten Blick an? Gerne freue ich mich auch über eure detaillierteren Kommentare und Verbesserungsvorschläge.
PS: Im übrigen wurde auch die „Über theXME“ Seite leicht überarbeitet.