Wie man überall lesen kann, wird ja jetzt an Linux 3.0 gearbeitet. Ich selbst habe ja gehofft das sich Linus das ganze nochmal überlegt und einfach 2.6.41 oder gar 2.8.0 daraus macht. Da wüsste ich wie ich dran bin, aber ne Versionsnummer für so nen Quatsch zu erhöhen steht zwar dem Entwickler zu, es ist ja sein Kind was er nummeriert - Fragwürdig ist diese Politik bei vielen aktuellen Projekten aber trotzdem.

Mozilla macht es ja mittlerweile genauso, statt nur große Änderungen mit einer solchen Nummer zu versehen, bekommt jetzt alles solche tollen Nummern! Und zack schon ist man bei Firefox 6.0 ohne das man sich sonderlich anders fühlt oder was davon hat (außer der tollen großen Nummer).

Ich selbst habe mir für Kernel 3.0 vor allem gewünscht das mal der ganze alte Müll rausfliegt! Sprich: Hardware die älter als 10 Jahre auf keiner neuen Platine mehr zu finden ist, dazu noch Sachen die schon lange Deprecated oder Obsolete markiert sind.

Jetzt haben wir Marketingzahlen auch beim Linux Kernel, toll finde ich das ja nicht gerade :-(

Seit einigen Tagen habe ich auch GNOME 3.0 auf meinem Produktiv System. Das ganze System läuft auch sehr gut damit, mir sind nur 4 Punkte aufgefallen die aktuell wirklich nervig sind:

• Rhythmbox geht beim klicken auf die Fenster schließen Schaltfläche komplett zu, ich habe mir damit bestimmt schon 50 mal die Musik ausgemacht! Leider konnte ich hierzu noch keine Einstellung finden, ein richtiges Tray gibts ja für GNOME 3.0 nicht mehr :-/
• Im Gegensatz zu GNOME Do ist die Shell nicht so clever und startet einen eingegeben Befehl direkt wie man ihn eingibt, stattdessen geht Wikipedia auf. ALT-F2 ist ein Shortcut den ich schon 2 Jahre nicht mehr verwenden musste :-/
• Gajim Integration, hier gibt es noch einiges an Arbeit zu tun. Zwar gibt es eine Integration über Extensions für die Shell, schöner wäre aber nativer Support von gajim für GNOME 3.0.
• Empathy kann nach wie vor weder GPG, OTR noch E2E. Das ist einer der Hauptgründe warum ich es nicht verwenden kann.

Ich denke aber auch das dies Dinge sind, die vielleicht schon mit 3.2 gefixt oder geändert werden. Bei Gajim müssen natürlich die Entwickler selbst aktiv werden!

Seit heute ist ja GNOME 3.0.1 offiziell in den normalen Paketquellen von Arch angekommen, natürlich habe ich auch mein Produktivsystem auf die neue Version aktualisiert.

Das ganze hat auch prima funktioniert, aber nach dem 2. Boot ging auf einmal nichts mehr und nur noch das Hintergrund Bild war sichtbar beim Anmelden über den GDM. Wie sich heraus gestellt hat schlampt das neue GNOME noch bei der Session Verwaltung etwas, daher ist es ratsam den Haken "Automatisch die laufenden Programme beim Abmelden merken" in den gnome-session-properties abzuschalten. Zusätzlich kann man nach dem Logout noch die Dateien unterhalb von ~.config/gnome-session/saved-sessions/ löschen.

So wie ich das sehe hat die GNOME Shell sich wohl selbst in die Session gepackt, und wollte sich dann nach dem Start gleich nochmal starten und dann ging natürlich garnichts mehr. So weit meine Theorie, vielleicht hilft euch die Lösung ja auch falls ihr dieses Problem mal haben solltet.

Man liest es ja überall: GNOME 3.0 wurde veröffentlicht.

Ich selbst habe es natürlich auch mal getestet, aber natürlich beachtet das es ein .0 Release ist was halt einfach noch nicht so 100%ig stabil sein kann. Installiert habe ich es aus dem testing Repository unter Arch Linux, was man nur tun sollte wenn man mit dem System rumspielen will. Auf einem Produktivsystem würde ich erst mal bei 2.* bleiben bis es die ersten Bugfix Releases von 3.0 gibt. Für andere Distributionen gibt es Fremdquellen (z.B. PPAs bei Ubuntu) oder die Möglichkeit jhbuild zu verwenden.

Was mir beim ersten Start vom neuen GNOME aufgefallen ist: Es ist sehr aufgeräumt und nur mit dem nötigsten versehen. Das finde ich generell eigentlich schön da ich mit viel Schnickschnack kaum was anfangen kann, aber im Control Center hat man das doch deutlich übertrieben. Es gibt eigentlich nichts mehr das man wirklich Einstellen kann, auch das extra Tool gnome-tweak-tool erlaubt einem nur eine Hand voll mehr Einstellungen.

Der neue Workflow von GNOME gefällt mir aber sehr gut, man hat sich schnell dran gewöhnt und kann zu einem Teil auf Tools wie z.B. gnome-do verzichten, hier und da gibt es noch ein paar Sachen die nicht so funktionieren wie es die Entwickler erwarten, aber im großen und ganzen macht es einen brauchbaren Eindruck. Vor einem halben Jahr noch hatte ich zu diesem Thema ja die Befürchtung das 3.0 ein Schuss in den Ofen wird, da hatte ich aber unrecht.

Meine Freundin hat 3.0 auch probiert, und ist damit auch zufrieden. Hauptkritikpunkt einer Frau ist aber das man nicht mal das Thema umstellen kann ohne das man irgendwelche Extensions braucht. Was Anpassbarkeit angeht muss GNOME also doch wieder etwas nacharbeiten, und auch der Verzicht auf den beliebten "Ausschalten"-Button ist mir unerklärlich.

Sehr praktisch finde ich das dynamische Anlegen von neuen Desktops, das ist was wo ich bei 2.* vermisse, meistens reichen mir 2-3 virtuelle Desktops, aber manchmal darf es auch gerne etwas mehr sein. Ebenfalls schön gemacht ist die automatische Gruppierung von Anwendungen und eine Leiste wo man seine Lieblingsprogramme anpinnen kann.

Das waren meine Eindrücke vom neuen GNOME, mal sehen was die nächsten Releases bringen, Potential hat die neue Version nämlich!

Update:Mir ist klar das man an die Funktion Ausschalten noch kommt wenn man im Usermenu die ALT-Taste drück, das wissen aber nur die wo danach gesucht haben und nicht Leute die eher wenig mit der IT zu tun haben oder glauben das Google das Internet ist ;-)

Häufig hat man das Problem das man nicht weis wie lange den ein dd noch brauchen wird um die Platte zu spiegeln, oder wie schnell der Datentransfer via netcat überhaupt läuft. Genau hierfür wurde das kleine Tool pv geschrieben welches den Datendurchsatz von pipes messen kann.

Ich selbst muss leider gestehen das ich dieses prima Tool bis letzten Sonntag noch nicht mal kannte und eher zufällig von guten bekannten davon erfahren habe.

pv ist bei Ubuntu im universe, bei Debian im main und bei Arch im community Repository zu finden. Es benötigt nur wenige KByte auf der Festplatte und ist daher auf jedem System verwendbar.

Ich werde hier nicht die Manpage 1:1 runterleiern und nur die 2 häufigsten Verwendungsarten anschneiden, welche man im täglichen Alltag verwenden dürfte.

Das eine ist ein Ersatz für das gute alte cat welches wohl jeder Leser dieses Blog kennen dürfte:

pv dateiname | nc -w 1 serveradresse portnummer

Hier erkennt pv selbständig wie groß dateiname eigentlich ist und baut einen schönen Ladebalken damit der anzeigt wie lange der Transfer bzw. die Verarbeitung noch dauert. Bei Special Files wie z.b. named Pipes oder einfach nur Device Files wird dies natürlich nicht gehen und man sieht nur einen Balken der hin und her wandert, wie man es von zahlreichen grafischen Oberflächen gewöhnt ist.

Die andere Variante hängt Inline in der Pipe und zeigt natürlich die gleichen Daten an:

cat dateiname | pv | nc -w 1 serveradresse portnummer

Nachteilig ist natürlich das man hier nicht sieht wie lange der Transfer noch dauert, was logisch ist da über die Pipes ja keine Größeninformationen ausgetauscht werden. Wenn man natürlich weis welche Datenmenge übertragen wird kann man das pv mit auf den Weg geben:

cat dateiname | pv -s 200m | nc -w 1 serveradresse portnummer

Und schon hat man wieder den schönen Ladebalken, wenn man Sachen natürlich zuvor durch ein Kompressionstool wie gzip,bzip2 oder xz jagt ist der Ladebalken natürlich bestenfalls ein Schätzeisen im Glastkugelmodus.

Es gibt noch einige zusätzliche Schalter in der Manpage von pv, doch die wird man eher selten benötigen ;-)

Ich habe gestern Abend meine ganzen privaten PCs von OpenOffice.org auf LibreOffice umgestellt.

Für meine Clients auf Basis von Archlinux ging das ohne große Arbeit, da es direkt im extra Repository ist. Für Windows musste ich natürlich wieder das Installationspaket runterladen usw...

Beachten muss man das man OpenOffice und LibreOffice (zumindest bei Arch) nicht gleichzeitig installieren kann da einige Dateien schon im Paket von OpenOffice drin sind. Subjektiv gesehen kommt mir die Startzeit (erster Start) von LibreOffice kürzer vor als die von OpenOffice. Abgesehen davon habe ich noch nicht viel gemerkt, was erstmal ja auch gut ist.

Nachdem Motorola ja schon bei Froyo für das Milestone geschlampt hat, haben die wenigstens die Sache mit Gingerbread richtig gemacht: Link

Nachdem mir Google Buzz nicht gefallen hat ist nun Identi.ca an der Reihe.

Mein Profil ist hier erreichbar, als Client für den Desktop habe ich mir pino ausgesucht, auf dem Smartphone verwende ich Seesmic.

Das ganze dient natürlich wieder nur als Test vom Service, ob ich Identi.ca langfristig nutzen werde weis ich noch nicht.

Es passiert so ca. 2 mal pro Jahr: ICQ geht nicht mehr!

Genau zu dieser Zeit gibt es dann in diversen Foren Beiträge das die Welt untergeht und man ohne ICQ nicht mehr länger leben möchte.

Sind wir doch mal ehrlich: Warum verwendet man überhaupt ein zentrales Protokoll wo man genau weiß das der Serviceprovider ausdrücklich die Verwendung alternativer Clients verbietet?

Als Antwort gibt es dann den Klassiker "Meine Freunde haben doch alle ICQ!", was ich aber nicht als Grund zählen lasse warum man dieses proprietäre Protokoll verwenden muss. Wenn niemand endlich mal anfängt auf alternative (offene) Protokolle umzusteigen, schiebt man doch diese Art von Problemen immer und immer wieder vor sich hin. Ich selbst habe mein ICQ (ja, ich war auch mal jung und dumm) schon vor langer Zeit abgeschaltet, wer mich erreichen möchte kann mir ne Mail schreiben oder aber auf Jabber umstellen.

Just my 2 cents...

Self signed SSL Zertifikate

Viele von uns kennen diese nervigen Meldungen die man bekommt wenn man auf eine Seite geht die sog. Self signed SSL Zertifikate verwendet.

Doch leider wissen die meisten nicht warum man gerade diese eben nicht verwenden sollte! Das möchte ich in diesem Artikel mal etwas erklären, so das man sich in Zukunft darüber etwas mehr Gedanken machen. Ich lege dabei keinen Wert darauf das ich alles bis ins letzte Detail erkläre, dafür gibt es mehr als genug andere Ressourcen im Internet.

CA - Certificate Authority

Das ist die Basis, jedes SSL Zertifikat wird von einer sog. CA unterschrieben. Mit der Unterschrift wird nicht bestätigt das es sich dabei um ein sicheres, gutes oder vertrauenswürdiges Angebot handelt. Es wird nur (mehr oder weniger brauchbar) geprüft ob eine bestimmte Domain einem bestimmten Eigentümer gehört. So soll verhindert werden das ich mir ein Zertifikat für ubuntuusers.de erstellen kann, um damit Unfug zu treiben.

Die CA prüft also nur ob der Eigentümer berechtigt ist für diese Domain ein Zertifikat zu bekomme. In der Regel werden hierzu Mails an den Admin Benutzer von einer Domain gesendet oder der WHOIS überprüft. Wie genau die geprüft wird hängt von der jeweiligen CA ab, jedoch haben die meisten Browser bestimmte Mindestanforderungen an eine CA.

Die sog. Root-Zertifikate (also Hauptzertifikate) dieser CAs sind in dem meisten Browsern bereits vorinstalliert. Das heißt der Anbieter vom Browser (z.b. Microsoft, Mozilla, Apple, ...) traut einem Anbieter soweit das er in der Lage ist zu prüfen wem die Domain gehört. Auch das hat nichts mit dem Angebot an sich zu tun, sondern nur mit der Domain!

Somit legt also der Anbieter von deinem Browser fest welche Seite du ohne Fehlermeldung ansehen kannst, und welche nicht.

Zertifikat

Jeder Server benötigt ein Zertifikat um mit SSL Arbeiten zu können. In diesem Zertifikat stehen viele Informationen drin, wie z.b. wie lange es gültig ist und für welche Domain es genutzt werden kann.

Ein solches Zertifikat wird in der Regel von der CA unterschrieben, somit kann der Browser (oder auch der Mail Client) prüfen ob ein bestimmtes Zertifikat auch wirklich von einer Vertrauenswürdigen CA kommt.

Autogrammstunde

Dieses Zertifikat können auf 3 verschiedene Arten unterschrieben werden:

• Von einer CA die viele Browser kennen
• Von einer CA die man selbst erstellt hat oder die frei ist (z.B. CACert)
• Von einem selbst

Unterschrift durch eine CA die der Browser kennt

Dies ist eine gängige Variante für viele Firmeninternetseiten. Der Vorteil ist das jeder gängige Browser ohne Fehlermeldung einen Zugang zu der Seite ermöglicht. Der Nachteil ist das dies je nach Anbieter sehr viel Geld kostet. Gerade für kleine Projekte ist daher ein kommerzielles SSL Zertifikat einfach zu teuer.

Auch ist diese Variante ab und an etwas unflexibel, z.B. wenn man Zertifikate für den internen Firmengebrauch (Intranet) benötigt. Je nachdem für welche kommerzielle CA man sich entschieden hat, gibt es mehr oder weniger Nachteile.

Unterschrift durch eine CA die nicht der Browser kennt

Dies ist eine Variante die ich auch sehr gerne verwendet wird. Der Vorteil ist dabei, das keine Kosten entstehen und man nicht einen Anbieter fördert der ggf. eh nur Unsinn mit dem vielen Geld macht.

Der Nachteil ist das ein Browser natürlich die eigene CA oder die CA von z.B. CACert nicht im Zertifikatsmanager hat. Dadurch bekommt man auch diese nervigen Fehlermeldungen. Allerdings hat man einen großen Vorteil: Man muss nur ein Root-Cert in die Browser importieren und schon kann man alle Dienste dieser CA verwenden. Z.b. kann sich eine Firma eine eigene CA bauen die für die Mitarbeiterdienste verwendet wird. Die Mitarbeiter können dieses Root-Cert importieren und somit alle Dienste ohne Fehlermeldungen sicher verwenden.

Auch wird dieses Verfahren gerne bei OpenVPN verwendet. Dort traut dann OpenVPN allen Zertifikaten die von dieser CA unterschrieben worden sind. So spart man sich viel Arbeit mit Pre-Shared-Keys usw...

Unterschrift von einem selbst

Dies ist die einfachste, aber schlechteste Möglichkeit. Den jeder Benutzer bekommt mindestens beim ersten Aufruf des Dienstes eine nervige Fehlermeldung das etwas mit der Verschlüsselung nicht stimmt.

Viele Leute haben hier die Faustregel "Das Spiel muss weitergehen!", und sorgen dafür das der Browser mit dem Jammern aufhört. D.h. der Benutzer importiert das Zertifikat in seinen Browser und stuft es als Vertrauenswürdig ein.

Hierbei gibt es aber ein ganz wichtiges Problem: Woher weiß der Benutzer das dieses Zertifikat wirklich von dem Server kommt auf den er gerade zugreift? Es gibt nämlich mehr als genug Hackertools die ein Zertifikat sehr gut fälschen können.

Der Benutzer bestätigt somit also ein Zertifikat als Vertrauenswürdig das es überhaupt nicht ist. So kommt der böse Hacker aus dem McDonals z.B. ganz leicht an dein PayPal Passwort oder deinen eBay Account.

Das Problem ist nämlich nicht das Zertifikat an sich, sondern das ein durchschnittlicher User einfach nicht in der Lage ist ein Zertifikat zu prüfen. Den folgende Daten sollten bei einem Zertifikat passen und müssen vom Anwender überprüft werden wenn es nicht von einer bekannten CA kommt:

• Fingerabdruck vom Zertifikat
• Name / Domain vom Zertifikat
• Ablaufdatum des Zertifikates
• Fingerabdruck der CA
• Name / Aussteller der CA
• Ist das Zertifikat auf einer Widerrufsliste der CA

Ich denke die meisten Anwender werden keine dieser Daten aus dem Kopf kennen, daher sollte man davon abraten vertrauliche Daten wie Passwort, Adressen, Bankverbindung über eine solche Verbindung anzugeben. Auch sollte man ein selbst signiertes Zertifikat nie ohne guten Grund dauerhaft in den Browser importieren.

Fazit

Mit wenigen Schritten kommt ein Hacker auch bei einer verschlüsselten Verbindung an deine Daten, wenn man einfach mal ohne sich groß Gedanken zu machen eine Fehlermeldung vom Browser weg klickt. Es ist daher ratsam zumindest eine CA wie z.b. CAcert zu verwenden so das der Endanwender sich relativ leicht gegen solche Angriffe absichern kann. Wünschenswert für die Anwender wäre es natürlich das CAcert direkt in den großen Browsern vertreten wäre, doch daran wird natürlich schon gearbeitet!

Gleichzeitig hat eine verschlüsselte Verbindung überhaupt nichts mit der Vertrauenswürdigkeit der Anbieter zu tun, auch wenn immer wieder mit 128 Bit SSL Verschlüsselung geworben wird. Dies ist ein reines Sicherungsmerkmal für die Datenübertragung, was der Anbieter mit den Daten macht ist wieder was komplett anderes und würde den Rahmen dieses Artikels sprengen.