Kategorien
Ruby on Rails

Rails-Anwendung auf https umleiten

Immer wie­der ste­he ich vor dem glei­chen Pro­blem, der Blog­bei­trag soll also auch gleich­zei­tig als Gedächt­nis­stüt­ze für mich die­nen.
Für mein Stan­dard­set­up ver­wen­de ich als Web­ser­ver nginx (Anzahl Worker = Anzahl Cores), als Rails-App­li­ca­ti­on­ser­ver kommt thin mit zwei Workern zum Ein­satz. Eine Stan­dard­kon­fi­gu­ra­ti­on könn­te nun bei­spiels­wei­se so aus­se­hen:

# /etc/nginx/sites-available/my-site.deupstream my-site {  server   unix:/tmp/thin.my-site.0.sock;  server   unix:/tmp/thin.my-site.1.sock;}server {  listen   80;  server_name my-site.de www.my-site.de;  access_log /var/www/my-site.de/www/logs/access.log;  error_log /var/www/my-site.de/www/logs/error.log;  root   /var/www/my-site.de/www/htdocs/public/;  index  index.html;  location / {    proxy_set_header  X-Real-IP  $remote_addr;    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;    proxy_set_header  Host $http_host;    proxy_redirect    off;    if (-f $request_filename/index.html) {      rewrite (.*) $1/index.html break;    }    if (-f $request_filename.html) {      rewrite (.*) $1.html break;    }    if (!-f $request_filename) {      proxy_pass http://my-site;      break;    }  }}

In Ver­bin­dung mit die­ser /etc/thin/my-site.yml funk­tio­niert eine Rails-Anwen­dung auch ein­wand­frei:

---pid: tmp/pids/thin.pidwait: 30timeout: 30log: log/thin.logmax_conns: 1024require: []environment: productionmax_persistent_conns: 512servers: 2daemonize: truechdir: /var/www/my-site.de/www/htdocssocket: /tmp/thin.sock

Sämt­li­cher Traf­fic läuft bei die­sem Set­up unver­schlüs­selt über Port 80, also Stan­dard-http. Wenn man nun aber ein Log­in, bspw. für ein CMS wie Radi­ant, rea­li­sie­ren möch­te, wäre es natür­lich wün­schens­wert, den Traf­fic ver­schlüs­selt über Port 443, also https, lau­fen zu las­sen. Not­wen­dig ist das aber aus mei­ner Sicht nur bei Zugrif­fen auf das Admin-Backend. Im nach­fol­gen­den Set­up wer­den sämt­li­che Anfra­gen auf http://www.my-site.de/admin/{IRGENDWAS} auf https://www.my-site.de/admin/{IRGENDWAS} umge­lei­tet. Requests auf die Web­site selbst blei­ben von der Umlei­tung also unbe­rührt.

# /etc/nginx/sites-available/my-site.deupstream my-site {  server   unix:/tmp/thin.my-site.0.sock;  server   unix:/tmp/thin.my-site.1.sock;}server {  listen   80;  server_name my-site.de www.my-site.de;  access_log /var/www/my-site.de/www/logs/access.log;  error_log /var/www/my-site.de/www/logs/error.log;  root   /var/www/my-site.de/www/htdocs/public/;  index  index.html;  rewrite ^/admin/(.*) https://www.my-site.de/admin/$1 permanent; # Rewrite-Regel für die Umleitung aller Anfragen auf /admin  location / {    proxy_set_header  X-Real-IP  $remote_addr;    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;    proxy_set_header  Host $http_host;    proxy_redirect    off;    if (-f $request_filename/index.html) {      rewrite (.*) $1/index.html break;    }    if (-f $request_filename.html) {      rewrite (.*) $1.html break;    }    if (!-f $request_filename) {      proxy_pass http://my-site;      break;    }  }}server {  listen 443;  server_name my-site.de www.my-site.de;  ssl                 on;  ssl_certificate     /etc/ssl/certs/startssl.crt;  ssl_certificate_key /etc/ssl/private/startssl.key;  ssl_ciphers         ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM;  ssl_protocols       SSLv3 TLSv1;  access_log /var/www/my-site.de/www/logs/access.log;  error_log /var/www/my-site.de/www/logs/error.log;  root   /var/www/my-site.de/www/htdocs/public/;  index  index.html;  location / {    proxy_set_header  X-FORWARDED_PROTO https;    proxy_set_header  X-Real-IP  $remote_addr;    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;    proxy_set_header  Host $http_host;    proxy_redirect    off;    if (-f $request_filename/index.html) {      rewrite (.*) $1/index.html break;    }    if (-f $request_filename.html) {      rewrite (.*) $1.html break;    }    if (!-f $request_filename) {      proxy_pass http://my-site;      break;    }  }}

Mei­ne Zer­ti­fi­ka­te bezie­he ich übri­gens zumeist von StartS­SL. Die Zer­ti­fi­ka­te kos­ten nichts und wer­den trotz­dem von allen aktu­el­len Brow­sern akzep­tiert. Nur den grü­nen Hin­ter­grund bekommt man mit die­sem Zer­ti­fi­kat nicht, was ich per­sön­lich aber als unkri­tisch ein­stu­fe. Goo­g­les Chro­me wird der­zeit aber lei­der nicht für die Erstel­lung der Zer­ti­fi­ka­te unter­stützt, mit der aktu­el­len Ver­si­on von App­les Safa­ri geht’s aber ein­wand­frei.
Kurz noch zur Erklä­rung, wie­so nginx und thin:

  • nginx zie­he ich Apa­che vor, weil er deut­lich schlan­ker und per­for­man­ter ist. Für PHP-Set­ups ver­wen­de ich zumeist wei­ter­hin den Apa­che, weil die­ser sich deut­lich ein­fa­cher mit PHP auf­set­zen lässt, als dies mit nginx der Fall ist.
  • thin ist extrem ein­fach auf­zu­set­zen, ein­fa­cher als Uni­corn oder mongrel_cluster, die im End­ef­fekt genau das Glei­che tun. Und dank der Fähig­keit von thin, auch als UNIX-Socket zu lau­fen, ist er auch extrem schnell.

Von Fall zu Fall mag die Eig­nung der Alter­na­ti­ven eher gege­ben sein, ich habe aber ziem­lich gute Erfah­run­gen mit die­sem Set­up gemacht. Es ist ein­fach zu admi­nis­trie­ren und äußerst per­for­mant.
Ein klei­ner Tipp noch zum Schluss. Um sowohl thin als auch nginx in den aktu­el­len Ver­sio­nen zu fah­ren, benut­ze ich fol­gen­de Wege der Instal­la­ti­on:
nginx instal­lie­re ich über das eigens dafür bereit­ge­stell­te PPA, wel­ches wie folgt in Ubun­tu 10.04 LTS oder neu­er ein­ge­bun­den wer­den kann:

nginx=stable # use nginx=development for latest development versionsudo su -add-apt-repository ppa:nginx/$nginxapt-get update apt-get install nginx

thin instal­lie­re ich aus den Ruby-Gems her­aus und nut­ze dann den kom­for­ta­blen Instal­ler, den die Jungs mit­lie­fern:

sudo gem install thinsudo thin installsudo /usr/sbin/update-rc.d -f thin defaults

Um die Anwen­dungs­um­ge­bun­gen nicht hän­disch erstel­len zu müs­sen, kann man das thin-Kom­man­do benut­zen:

sudo thin config -C /etc/thin/my-site.yml -c /var/www/my-site.de/www/htdocs --servers 2 -socket /tmp/thin.my-site.sock -e production

Die­ser Befehl erstellt eine Kon­fi­gu­ra­ti­ons­da­tei für thin, wie sie wei­ter oben zu sehen ist.

Kategorien
Uncategorized

Heroku: Rails-Anwendungen in der Cloud

Die Cloud, das Buz­zword des letz­ten Jah­res, ist in aller Mun­de. Und hat auch schon ers­te Federn las­sen müs­sen. Was die Cloud eigent­lich kenn­zeich­net, ist nahe­zu gren­zen­lo­se Ska­lier­bar­keit. Wenn es nach den Befür­wor­tern der Cloud geht, bucht nie­mand mehr phy­si­ka­li­sche Maschi­nen, son­dern Spei­cher­platz, RAM, Rechen­leis­tung in dem Umfang, den er benö­tigt. Wird zwi­schen­zeit­lich mal mehr gebraucht, dreht man kurz an der ent­spre­chen­den Schrau­be und zahlt eben für die Zeit ein wenig mehr. Es gibt unheim­lich vie­le Anbie­ter, gera­de Ama­zon, eigent­lich Inter­net­ein­zel­händ­ler, hat in die­sem Bereich von sich reden gemacht. Ama­zon bie­tet alles denk­ba­re an Cloud-Dienst­leis­tun­gen an, was man sich nur so vor­stel­len kann. Genau das ist dem Wiki­leaks-Pro­jekt zum Ver­häng­nis gewor­den, weil der Anbie­ter somit auch am ein­zi­gen Hebel sitzt. Legt er den um, ist Fei­er­abend. Ama­zon bie­tet zwar eine recht gro­ße Pro­dukt­pa­let­te an, alles abde­cken tun sie dann aber auch nicht.

Wer bei­spiels­wei­se Rails-Anwen­dun­gen in der Cloud lau­fen las­sen möch­te, ist auf ande­re Dienst­leis­ter ange­wie­sen. In den letz­ten Jah­ren hat sich ein Anbie­ter namens Hero­ku einen Namen in der Com­mu­ni­ty gemacht. Erst kürz­lich wur­de Hero­ku von salesforce.com, einem gro­ßen Anbie­ter von Geschäfts­an­wen­dun­gen, für rund 212 Mio. US-$ auf­ge­kauft.

Hero­ku hat ein für den Ent­wick­ler sehr effi­zi­ent zu nut­zen­des und ein­fa­ches Deploy­ment-Ver­fah­ren ent­wi­ckelt, wel­ches kom­plett Git- und Rake-gestützt ist. Der Rails-Ent­wick­ler muss sich also nicht mit der Admi­nis­tra­ti­on und Kon­fi­gu­ra­ti­on von Web­ser­vern her­um­är­gern. Ein Vor­teil gegen­über den klas­si­schen Rails-Hos­tern, von denen es ohne­hin rela­tiv weni­ge gibt ist, dass man nicht auf die vom Hos­ter instal­lier­ten Ruby-Gem-Ver­sio­nen ange­wie­sen ist, son­dern sei­ne eige­nen Ver­sio­nen spe­zi­fi­zie­ren kann, wie man es von sei­ner Ent­wick­lungs­ma­schi­ne her kennt.

Wer rei­ne Rails-3-Anwen­dun­gen deploy­en möch­te, hat sei­ne Anwen­dung bin­nen weni­ger Minu­ten online:

sudo gem install herokugit initheroku creategit add .git commit -a -m 'first deployment commit to Heroku'git push heroku masterheroku rake db:migrateheroku open

Das war es schon. Die Anwen­dung soll­te online sein und sich im Brow­ser geöff­net haben.

Bei Rails-2-Anwen­dun­gen gestal­tet sich das Deploy­ment etwas schwie­ri­ger, aber auch nicht viel. Bevor man die oben erwähn­te Befehls­ket­te anschub­sen kann, muss erst ein­mal eine Datei namens .gems erstellt wer­den. In die­ser müs­sen dann alle erfor­der­li­chen Gems, ggf. inklu­si­ve Ver­si­ons­num­mer notiert wer­den. Bei­spiel:

rails --version 2.3.5i18n --version 0.4.2rack --version 1.0.1

Erst dann darf deploy­ed wer­den. Neben den oben erwähn­ten Mög­lich­kei­ten gibt es aber noch vie­le wei­te­re, die alle­samt auf den wirk­lich tol­len Sup­port- und Doku­men­ta­ti­ons-Sei­ten von Hero­ku doku­men­tiert sind. So kann man, sofern man bereits lokal Post­greS­QL ver­wen­det, sei­nen kom­plet­ten Daten­bank­in­halt mit­tels hero­ku db:push in die Anwen­dung bei Hero­ku pushen. Post­greS­QL ist übri­gens die ein­zi­ge Daten­bank, die von Hero­ku ange­bo­ten wird. Laut Hero­ku des­we­gen, weil sie dort die opti­ma­le Kom­bi­na­ti­on zwi­schen Zuver­läs­sig­keit, Daten­in­te­gri­tät und Geschwin­dig­keit sehen. Ein State­ment, das ich durch­aus unter­schrei­ben kann. Das hero­ku-Gem ist äußerst mäch­tig und bie­tet einem Zugriff auf sämt­li­che instal­lier­ba­re Add-Ons (s.u.), auf die Logs und noch vie­les mehr. Eine Stu­die der Doku­men­ta­ti­on ist emp­feh­lens­wert.

Ab sofort kann dann direkt in den Anwen­dungs­con­tai­ner bei Hero­ku deploy­ed wer­den, indem man ein ganz regu­lä­res Git-Com­mit erstellt. Ein­fa­cher geht es kaum noch.

Nach­dem die ers­te Ver­si­on der Anwen­dung deploy­ed wur­de, kann man sie um eini­ge tol­le, teil­wei­se auch kos­ten­los nutz­ba­re Add-Ons erwei­tern. Dazu gehö­ren nütz­li­che Erwei­te­run­gen wie CNA­ME-Ein­trä­ge für die Anwen­dung (damit man sie auch unter einer eige­nen (Sub-)Domain betrei­ben kann), Jasondb, Mon­goDB und CouchDB für die NoS­QL-Anhän­ger unter uns, Excep­ti­on-Tra­cker, Echt­zeit­su­che, New Relic, SMS-Gate­ways, auto­ma­ti­sier­te Daten­bank­back­ups, etc. Man­che kos­ten gar nichts, man­che nur wenig Geld, ande­re wie­der­um sind recht teu­er (wobei teu­er mal wie­der rela­tiv ist). Dol­le ins Geld geht ein SSL-Zer­ti­fi­kat, da sol­che Zer­ti­fi­ka­te wei­ter­hin IP-basiert sind, was bei einem Cloud-basier­ten Dienst natür­lich recht fins­ter wer­den kann.

Apro­pos Kos­ten: jeder kann bei Hero­ku belie­big vie­le Anwen­dun­gen hos­ten las­sen, die auch erst mal nichts kos­ten, in der Leis­tungs­fä­hig­keit aber arg ein­ge­schränkt sind. Benö­tigt man mehr Res­sour­cen, muss man in die Tasche grei­fen, ab ca. 36 US-$ (0,05 $-Cent pro Stun­de) monat­lich geht es los. Dabei unter­teilt Hero­ku in Dynos und Worker. Dynos beschleu­ni­gen das Front­end, Worker die Hin­ter­grund­pro­zes­se der Rails-Anwen­dung. Der Maxi­mal­aus­bau liegt bei 24 Dynos und 24 Workern, wofür dann aber auch 2,35 US-$ pro Stun­de, oder umge­rech­net rund 1.700 US-$ monat­lich anfal­len. Die Per­for­mance­stu­fe dürf­te aber auch „geho­be­nen“ Ansprü­chen genü­gen.

Damit ist aber noch nicht Schluss, denn eine dedi­zier­te Daten­bank ist bei dem Preis noch nicht inklu­si­ve. Kos­ten­los gibt es 5 MB Sha­red Data­ba­se, für 20 US-$ monat­lich 20 GB Sha­red Data­ba­se. Wer gern eine dedi­zier­te Daten­bank hät­te, muss bspw. für den kleins­ten Tarif Ronin 200 US-$ monat­lich berap­pen. Dafür erhält er 16 gleich­zei­ti­ge Ver­bin­dun­gen, 1,7 GB RAM und 1 com­pu­ting unit. Für 6.400 US-$ gibt es 400 Ver­bin­dun­gen, 68 GB RAM und 26 com­pu­ting units. Wer’s braucht…

Hero­kus Datei­sys­tem ist read-only, Dateiuploads las­sen sich also nicht rea­li­sie­ren. Hier­zu kann/sollte man, auch laut Hero­ku-Doku­men­ta­ti­on, auf Anbie­ter wie Ama­zon S3 aus­wei­chen. Für Rails-Anwen­dun­gen gibt es diver­se Mög­lich­kei­ten, Uploads zu Ama­zons S3 (Simp­le Sto­rage Ser­vice) aus der Anwen­dung her­aus zu rea­li­sie­ren. Nament­lich erwähnt wer­den Attach­ment-Fu und Paper­clip. Eine per­sön­li­che Prä­fe­renz kann ich hier abge­ben, ich hab mit bei­den noch nicht gear­bei­tet. Hero­ku emp­fiehlt im Übri­gen gene­rell, gro­ße Datei­en, die die Appli­ka­ti­on zum Down­load bereit­stel­len soll, aus Per­for­mance­grün­den zu S3 oder ähn­li­chen Ser­vices aus­zu­la­gern, weil das Datei­sys­tem von Hero­ku nicht für der­ar­ti­ge Anwen­dungs­zwe­cke kon­zi­piert und opti­miert wur­de.

Um die Per­for­mance­un­ter­schie­de mes­sen zu kön­nen, habe ich eine Instal­la­ti­on von Red­mi­ne bei Hero­ku vor­ge­nom­men. Das Deploy­en die­ser Anwen­dung ist lei­der nicht total tri­vi­al, die ein­zel­nen Schrit­te habe ich des­we­gen in einem Gist (wel­cher auch noch mal ganz unten ein­ge­bet­tet ist) nie­der­ge­schrie­ben.

Zum Ergeb­nis mei­ner Bench­marks, gemes­sen auf einer Pro­jekt­über­sichts­sei­te mit ab -c 50 -n 200:

  1. 1 Dyno (kos­ten­los): 7,98 Requests pro Sekun­de
  2. 2 Dynos: 13,15 Requests pro Sekun­de
  3. 3 Dynos: 18,46 Requests pro Sekun­de
  4. 10 Dynos: 53,46 Requests pro Sekun­de
  5. 24 Dynos: 84,14 Requests pro Sekun­de
  6. 1 Worker: 7,64 Requests pro Sekun­de
  7. 2 Worker: 7,74 Requests pro Sekun­de

Die Anzahl der Worker wirkt sich also in kei­ner Wei­se auf die Anwen­dungs­per­for­mance aus, die Anzahl der Dynos hin­ge­gen beträcht­lich. Den größ­ten Gewinn (pro­zen­tu­al gese­hen) bekommt man hier, wenn man von dem einen kos­ten­lo­sen Dyno auf einen zwei­ten, kos­ten­pflich­ti­gen auf­rüs­tet. Die monat­li­chen Kos­ten lie­gen mit die­sem bei rund 36 US-$, also umge­rech­net in etwa 27 €. Eigent­lich nicht zu viel ver­langt, man darf nur nicht ver­ges­sen, dass in die­sem Preis noch kein Sto­rage und nur 5 MB an Daten­bank­platz inklu­si­ve ist.

Zum Ver­gleich: mein nicht opti­mier­ter Root-Ser­ver (Athlon64 X2 6.400+, 4 GB RAM, OpenVZ) lie­fert rund 10,5
R
equests pro Sekun­de. Den muss ich natür­lich selbst admi­nis­trie­ren, war­ten, etc. Und das Deploy­ment ist auch längst nicht so bequem bzw. müss­te erst mal von mir auf die­sen Bequem­lich­keits­le­vel gebracht wer­den.

Hero­ku bie­tet für einen akzep­ta­blen Preis einen wirk­lich tol­len und per­for­man­ten sowie äußerst fle­xi­blen Ser­vice an. Für den Rails-Ent­wick­ler, der kei­ne Lust hat, sich mit der Ein­rich­tung und Admi­nis­tra­ti­on eines Rails-fähi­gen Web­ser­vers rum­zu­schla­gen und ggf. auf­tre­ten­de Pro­ble­me zu behe­ben ist Hero­ku aus mei­ner Sicht opti­mal. Zumal man hier nicht gleich einen zwei­ten Ser­ver hin­zu kau­fen muss, nur weil die Anwen­dung an ein oder zwei Stun­den am Tag mal mehr Res­sour­cen braucht, als es die eige­ne Hard­ware zulässt. Die Anmel­dung kos­tet nichts und das Deploy­en der eige­nen (oder frem­den) Anwen­dung genau so wenig. Einem Ver­such steht also nichts im Wege. Viel Spaß dabei.

https://gist.github.com/779866

Kategorien
Linux Uncategorized

Ubuntu auf dem Desktop

Teaser

In die­sem Arti­kel möch­te ich kurz beschrei­ben, wie es aus mei­ner Sicht um den Ubun­tu-Desk­top bestellt ist und ob er in der Lage ist, kom­mer­zi­el­le Betriebs­sys­te­me zu erset­zen. Dies soll kei­ne reprä­sen­ta­ti­ve Stu­die wer­den, nur ein per­sön­li­cher Ein­druck des aktu­el­len Stands, auf dem sich Ubun­tu befin­det, im mehr oder min­der direk­ten Ver­gleich mit der kom­mer­zi­el­len Kon­kur­renz.

1. Instal­la­ti­on

Die Instal­la­ti­on eines Ubun­tu auf einer lee­ren Fest­plat­te könn­te nicht ein­fa­cher sein. Der Benut­zer muss kaum eine Ent­schei­dung tref­fen, bis auf die obli­ga­to­ri­sche Kom­bi­na­ti­on aus Benut­zer­na­men und Kenn­wort. Wäh­rend der Instal­la­ti­on ist es rat­sam, den Rech­ner an einer akti­ven Inter­net­ver­bin­dung zu betrei­ben, damit so eini­ge Updates schon wäh­rend der Instal­la­ti­on ein­ge­spielt wer­den kön­nen. Nichts­des­to­trotz folgt direkt nach dem ers­ten Neu­start erst mal eine Updateor­gie. Die­se hält sich im direk­ten Ver­gleich zu Win­dows oder gar Mac OS X aber erfreu­lich in Gren­zen. Nach einem Schub bestehend aus Down­load und Instal­la­ti­on sind alle Updates ein­ge­spielt. Befand sich ein Ker­ne­l­up­date unter den Down­loads, muss der Rech­ner zum Abschluss neu gestar­tet wer­den. Instal­liert man ein Mac OS X Snow Leo­pard, müs­sen die Updates in zwei „Schich­ten“ ein­ge­spielt wer­den, ein Neu­start ist auch hier auf jeden Fall erfor­der­lich. Bei Win­dows 7 sind es gar drei Durch­läu­fe gepaart mit zwei recht zeit­fres­sen­den Neu­starts. Zugu­te­hal­ten muss man hier natür­lich Win­dows 7 und Snow Leo­pard, dass sie schon ein Weil­chen län­ger auf dem Markt sind und so natur­ge­mäß mehr Updates ange­fal­len sind. Auf der ande­ren Sei­te aktua­li­siert Ubun­tu nicht nur sich, son­dern auch gleich noch jede Anwen­dung, die vor­in­stal­liert ist. Die Instal­la­ti­ons­as­sis­ten­ten von OS X und Win­dows 7 ver­lan­gen dem Benut­zer aber auch kaum noch Fach­kennt­nis­se ab, sodass sich Ubun­tu hier auf einer Stu­fe mit OS X befin­det, Win­dows aber nur knapp abge­schla­gen auf Platz 2 lan­det. Ein necki­sches Fea­ture des OS-X-Instal­lers: mit­tels der ein­ge­bau­ten Web­cam eines jeden Mac wird ein Fotos des Benut­zers gemacht und des­sen Benut­zer­pro­fil zuge­wie­sen. Braucht kei­ner, nett ist es trotz­dem.

2. Vor­in­stal­la­ti­on

Die stan­dard­mä­ßig vor­in­stal­lier­te Aus­wahl an Anwen­dun­gen ist nahe­zu vor­bild­lich. Bei­na­he jeder Anwen­der­typ kann sofort mit der Arbeit begin­nen und muss sich nicht erst müh­sam bei­spiels­wei­se ein Office-Paket orga­ni­sie­ren. Vor­in­stal­liert sind Stan­dard­an­wen­dun­gen wie ein Office-Paket (nament­lich OpenOffice.org), ein Per­so­nal-Infor­ma­ti­on-Man­an­ger à la Out­look (Evo­lu­ti­on), ein Brow­ser (Fire­fox), ein Instant-Mes­sen­ger (Empa­thy, kom­pa­ti­bel mit ICQ, MSN, Yahoo, GTalk, etc.), eine Bild­ver­wal­tung, eini­ge Spie­le, ein Text­edi­tor, ein Ter­mi­nal, eine Anwen­dung für Win­dows-RDP-Ver­bin­dun­gen und so wei­ter. Für den Nor­mal­an­wen­der blei­ben hier, wenigs­tens was die Aus­stat­tung angeht, kei­ner­lei Wün­sche offen. Der Ubun­tu-Desk­top sieht nach der Instal­la­ti­on sehr auf­ge­räumt aus, kei­ner­lei Icons auf dem Schreib­tisch blo­ckie­ren die Sicht, alle Anwen­dun­gen befin­den sich fein säu­ber­lich sor­tiert im Anwen­dun­gen-Menü oben links auf dem Bild­schirm. Hier müs­sen sich Mac OS X und Win­dows ein­deu­tig hin­ten anstel­len, mit deren Vor­in­stal­la­ti­on kann man nur bedingt arbei­ten. Unter Win­dows ist nicht mal ein zeit­ge­mä­ßer Brow­ser vor­in­stal­liert (was ulki­ger­wei­se auch für das neue Win­dows Pho­ne 7 gilt), eine brauch­ba­re E‑Mail-Anwen­dung fin­det man auch nicht vor. Unter OS X ist die Lage etwas bes­ser, aber Prei­se kann Apple hier­mit auch nicht gewin­nen. Etwas ver­bes­sern kann man die Lage, indem man das iLi­fe-Paket, wel­ches sich im Lie­fer­um­fang eines jeden Macs befin­det, instal­liert. Jetzt sind wenigs­tens Anwen­dun­gen für die Bild­ver­wal­tung, Audio­schnitt, Web­siteer­stel­lung, etc. instal­liert. Außer­dem muss man den ein­ge­bau­ten Tools von OS X im Schnitt einen deut­lich höhe­ren Funk­ti­ons­um­fang beschei­ni­gen. So kann der OS-X-Nut­zer (wie sein Ubun­tu-nut­zen­der Kol­le­ge auch) sofort nach der Instal­la­ti­on PDF-Datei­en öff­nen, Doku­men­te in PDF-Datei­en umwan­deln, Fotos rudi­men­tär nach­be­ar­bei­ten (beschnei­den, Sättigung/Helligkeit ver­än­dern, etc.), außer­dem ist der vor­in­stal­lier­te Brow­ser einer der moderns­ten der­zeit erhält­li­chen, hier kann der unter Ubun­tu instal­lier­te Fire­fox nicht mit­hal­ten. Win­dows steht hier mal wie­der ganz hin­ten an, die genann­ten Funk­tio­nen sucht man dort ver­ge­bens.

3. Soft­ware­su­che, ‑instal­la­ti­on und ‑pfle­ge

Hier schei­den sich die Geis­ter. Seit Ubun­tu 10.04 gibt es unter Ubun­tu das Soft­ware Cen­ter, seit ges­tern, also dem 06.01.2011, gibt es unter OS X den Mac App Store. Bei­de ver­fol­gen den glei­chen Ansatz: eine zen­tra­le Anlauf­stel­le für den Benut­zer zu schaf­fen, wo er sich sei­ne Soft­ware aus­su­chen, ggf. bezah­len und gleich instal­lie­ren kann, ohne stun­den­lang Goog­le quä­len zu müs­sen. Ich per­sön­lich fin­de die­sen Ansatz sehr gut, ande­re wie­der­um befürch­te, ins­be­son­de­re im Fal­le von OS X, dass die­ser Weg dazu führt, dass ande­re Wege der Soft­ware­instal­la­ti­on bald nicht mehr exis­tie­ren wer­den. Unter Win­dows gibt es (mei­nem Kennt­nis­stand nach) nichts ver­gleich­ba­res. Der Win­dows-User muss sich also nach wie vor als Jäger und Samm­ler betä­ti­gen und sich sei­ne Soft­ware müh­sam aus den Wei­ten des Inter­nets zusammenklau(b)en (sor­ry, das Wort­spiel konn­te ich mir nicht ver­knei­fen). Wäh­rend Ubun­tu- und Mac-User jetzt also eine zen­tra­le Anlauf­stel­le für ihre Soft­ware haben, sind Win­dows-Benut­zer wei­ter­hin auf dubio­se Heft-CDs oder, sofern vor­han­den, ihre Fähig­kei­ten in der Bedie­nung von Such­ma­schi­nen ange­wie­sen. Wäh­rend unter Ubun­tu der Gedan­ke kon­se­quent fort­ge­setzt wur­de und über das Soft­ware-Cen­ter instal­lier­te Soft­ware auch deinstal­liert wer­den kann, muss der Mac-User hier selbst Hand anle­gen. Nach wie vor aber gestal­tet sich die Instal­la­ti­on und Pfle­ge von Soft­ware unter Win­dows am schwie­rigs­ten: setup.exe suchen, her­un­ter­la­den, auf Viren prü­fen, Wei­ter, Lizenz­be­din­gun­gen akzep­tie­ren, Wei­ter, Wei­ter, Fer­tig­stel­len, Ver­knüp­fun­gen vom Desk­top löschen… umständ­lich. Unter OS X war es bis­her so, dass eine Instal­la­ti­on dar­in bestand, das DMG mit der Anwen­dung her­un­ter­zu­la­den und das Icon in den Anwen­dun­gen-Ord­ner zu zie­hen. Geni­al ein­fach, ein­fach geni­al. Aber suchen muss­te man die Soft­ware, bis ges­tern, noch selbst. Unter Linux hin­ge­gen ist die­ses zen­tra­le Soft­ware­ver­wal­tungs­sys­tem schon lan­ge Zeit gang und gäbe. Auch die Updates kom­men auf die­sem Wege. Am war­tungs­freund­lichs­ten ist somit der Ubun­tu-Desk­top, mehr oder min­der dicht gefolgt von OS X, Schluss­licht bil­det Win­dows. Wie ich ein­gangs schon erwähn­te, hier schei­den sich die Geis­ter. Man­che bevor­zu­gen den Win­dows-Weg, wie­so auch immer… objek­tiv betrach­tet ist es der schwie­rigs­te und feh­ler­an­fäl­ligs­te.

4. Inno­va­tio­nen

Tja, die sucht man unter Win­dows ver­ge­bens, machen wir uns nix vor. Damit möch­te ich jetzt nicht sagen, dass OS X und Ubun­tu vor Inno­va­tio­nen nur so strot­zen, Win­dows kann hier trotz­dem nicht Schritt hal­ten. In den letz­ten Jah­ren ist der Trend von „ gibt’s nur für Win­dows“ ein­deu­tig gekippt und vie­ler­orts in das Gegen­teil umge­schla­gen: „Gibt’s nur für OS X“. Vie­le klei­ne Hel­fer­lein, die es unter OS X schon län­ge­re Zeit gibt, schei­nen ihren Weg, auch in Form einer Kopie, nicht auf die Win­dows-Platt­form zu fin­den. Ich den­ke hier­bei kon­kret an Pro­jek­te wie Alfred App, CloudApp, Grab­Box, Litt­leS­nap­per, Growl, Drop­zo­ne und so wei­ter. Vom Poli­shing, also der opti­schen Fines­se der meis­ten Mac-Appli­ka­tio­nen, abge­se­hen, haben vie­le die­ser Ide­en mitt­ler­wei­le in Form von Open-Source-Pro­jek­ten ihren Weg zur Linux-Platt­form gefun­den, Alfred und Growl bei­spiels­wei­se wer­den mitt­ler­wei­le sehr ordent­lich unter Ubun­tu nach­emp­fun­den. Auch die ein­ge­bau­ten inno­va­ti­ven Hel­fer von OS X wie das Dock, der Datei­schnell­be­trach­ter Quick Look oder die äußerst prak­ti­sche Funk­ti­on Expo­sé haben mitt­ler­wei­le Pen­dants unter Linux. Wobei man zum Dock sagen muss, dass Micro­soft hier fast das bes­se­re Dock geschaf­fen hat. Das Grund­kon­zept von Dock und Tas­kleis­te unter­schei­det sich kaum noch, aber die ein­ge­bau­te Fens­ter­vor­schau unter Win­dows 7 ist ein Schritt, den man bei Apple schein­bar nicht gehen woll­te. Was ich bei sehr vie­len Fens­tern aber sogar ver­ste­hen kann. Unprak­tisch ist es trotz­dem nicht.

5. Gerä­te­trei­ber

Noch immer eines der größ­ten Pro­ble­me, wenn man auf das freie Betriebs­sys­tem set­zen möch­te. Wer kann, soll­te sich noch vor dem Kauf eines Neu­ge­räts, egal ob Desk­top-PC oder Note­book, erkun­di­gen, ob eine voll­stän­di­ge Kom­pa­ti­bi­li­tät zu Ubun­tu gewähr­leis­tet ist. Es ist lei­der auch heu­te noch nicht selbst­ver­ständ­lich, dass sofort alles Out-of-the-Box läuft und es kann durch­aus pas­sie­ren, dass man Trei­ber per Hand kom­pi­lie­ren oder wenigs­tens auf­wän­dig kon­fi­gu­rie­ren muss. Mei­ner Erfah­rung nach sind die Jungs beim Ubun­tu-Pro­jekt aber wirk­lich schnell. Kauft man kein nagel­neu­es Gerät, wel­ches erst seit Wochen auf dem Markt ist, ist die Wahr­schein­lich­keit recht groß, dass funk­tio­nie­ren­de Trei­ber für die Wunsch­hard­ware vor­lie­gen. Mac OS und Win­dows geht es hier deut­lich bes­ser, selbst für Mac OS lie­fert mitt­ler­wei­le nahe­zu jeder Her­stel­ler pas­sen­de Trei­ber mit. Eine Aus­nah­me bil­det hier die Situa­ti­on der Dru­cker­trei­ber: ich habe es gera­de in letz­ter Zeit immer häu­fi­ger erlebt, dass ich Dru­cker unter Ubun­tu mit weni­ger Auf­wand als unter Win­dows und sogar mit weni­ger Auf­wand als unter OS X instal­lie­ren konn­te, da gera­de der Bereich der Laser­dru­cker mitt­ler­wei­le schein­bar fast voll­stän­dig Linux-kom­pa­ti­bel ist. Der Assis­tent iden­ti­fi­ziert das Gerät, holt den Trei­ber aus dem Repo­sito­ry, instal­liert ihn und man kann dru­cken.

6. Zukunft

Wie ich sie sehe. Ubun­tu wird immer mehr zu einem OS-X-Clon, was nicht zwin­gend etwas schlech­tes ist. So kom­men auch die, die sich bis­her nichts von Apple leis­ten konn­ten oder woll­ten in den Genuss einer her­vor­ra­gen­den Usa­bi­li­ty und User Expe­ri­ence (Buz­zwords, jaja…). Mark Shut­tle­worth selbst war es schließ­lich, der sei­ne Ent­wick­ler offen dazu ansta­chel­te, bei Apple abzu­gu­cken. Was Micro­soft zwar auch tut, aber eben unter der Hand. Unbe­streit­bar ist der Fakt, dass sehr vie­le der Apple-Fea­tures der­zeit von der Kon­kur­renz imi­tiert wer­den, was aber wie gesagt nicht unbe­dingt was schlech­tes ist. Micro­soft soll­te aus mei­ner Sicht end­lich mal den not­wen­di­gen Schritt tun und die Basis des Sys­tems aus­tau­schen, um die gan­zen Alt­las­ten los­zu­wer­den. So, wie Apple es vor rund 10 Jah­ren getan hat. Zum Abschluss möch­te ich noch sagen, dass ich Win­dows nicht per se als schlecht bezeich­ne, bei­lei­be nicht, es ist nur ein­fach schlech­ter als die Kon­kur­renz. Dies allein aber macht es noch nicht zu einem schlech­ten Betriebs­sys­tem.

7. Fazit

Wer mit sei­nem Com­pu­ter nur Brie­fe und E‑Mails schreibt, dem kann es herz­lich egal sein, wel­ches OS er benutzt, glück­lich dürf­te er mit allen wer­den. Ubun­tu hat hier ganz klar den Kos­ten­vor­teil auf sei­ner Sei­te, Win­dows den Vor­teil des gewohn­ten. Wer ger­ne Com­pu­ter­spie­le spielt, soll­te nach wie vor zu Win­dows grei­fen, auch wenn sich in die­sem Bereich das Blatt bereits zu wen­den begon­nen hat. Immer mehr auch kom­mer­zi­el­le Titel fin­den ihren Weg auf den Mac oder in Ubun­tu (Linux im All­ge­mei­nen). Wer krea­tiv ist, mit vie­len Daten zu arbei­ten hat und gern inno­va­ti­ve Soft­ware-Ide­en vor­fin­den möch­te, soll­te der­zeit zum Mac grei­fen, der Work­flow ist auf dem Mac der­zeit ein­fach am flüs­sigs­ten. Ubun­tu holt aber stark auf und Win­dows hat seit Ver­si­on 7 auch wie­der an Tem­po zuge­legt, bil­det den­noch das Schluss­licht die­ses Tri­os. Die Arbeits­ge­schwin­dig­keit (Wech­sel von Anwen­dun­gen, Auf­fin­den von Daten, Star­ten von Pro­gram­men, zur Ver­fü­gung stel­len von Daten wie Screen­shots, etc.) die ich unter OS X errei­che, ken­ne ich der­zeit von kei­nem ande­ren Betriebs­sys­tem, was natür­lich eine gewis­se Pha­se der Ein­ge­wöh­nung vor­aus­setzt. In grö­ße­ren Betrie­ben ist Win­dows natür­lich nach wie vor nicht weg­zu­den­ken, zu vie­le Anwen­dun­gen, die es nur für Win­dows gibt und deren Por­tie­rung wahn­sin­nig teu­er wäre, ist dort instal­liert und im Ein­satz. Das ist hier aber eher weni­ger eine Fra­ge des Betriebs­sys­tems und des­sen Kom­fort oder Leis­tungs­fä­hig­keit, wie gern in den bekann­ten Fla­me-Wars ins Fel­de geführt wird, son­dern eher eine Geld­fra­ge.