Linux @ Home

Selten lasse ich mich zu  solchen Postings hinreissen. Nun ist es soweit. Nachdem ich nun seit über 10 Jahren KDE nutze (seit ca. 1999), hat das Frustlevel mit KDE 4.x (Version egal) ein unerträgliches Mass erreicht. Schade, ich wäre gerne länger optimistisch gewesen bezüglich des Projektes. Ich hoffe, dieser Artikel wird nicht zu sehr als Troll-Posting aufgefasst, ich versuche so sachlich wie möglich zu bleiben (ich bin zwar kein KDE-Entwickler, kann aber Usability und Projektleitung einigermassen beurteilen)…

Ich war wirklich ein grosser Fan von KDE, habe die Gnome-Benutzer immer belächelt, weil sie für Konfigurationen Registry-ähnliche (brrrr…) Einträge in GConf machen mussten (auch heute noch?), falls es dafür kein entsprechendes Werkzeug gibt.

Als mit KDE 4.0-4.3 bereits viele enttäuschte KDE-Benutzer absprangen, bezichtigte ich sie der Ungeduld und vermutete, dass in 6 Monaten endlich Stabilität und Klarheit bezüglich der Schnittstellen, des Designs und der Oberflächen herrschen würde: Ich habe mich geirrt. Es sind mehr als 3 Jahre seit Version 4.0 vergangen, ich habe wirklich genug Geduld bewiesen. Leider ist weder die Stabilität, noch die Funktionalität auch nur annähernd an die Versprechungen der Entwickler herangekommen. Als Benutzer frisst mir KDE einfach zuviel Zeit und Ressourcen und kostet mich immer mehr Nerven.

Um nur ein paar unrühmliche Beispiele zu nennen:

• Plasma-Abstürze (diese treten je nach Grafikkarten-Treiben häufiger oder seltener auf, aber sie treten auf)
• Der “semantische Desktop” mit Nepomuk/Strigi => Zweimaliger Backendwechsel (alle Tags und Indizes konnte man vergessen oder nur mit grossem Aufwand migrieren) und immer noch kein funktionierendes Frontend, abgesehen von ein paar unintuitiven Dolphin-Buttons. Kurz gesagt: Sogar die Windows-Indizierung oder der Google-Desktop-Search funktionieren besser.
• Akonadi (Datenprovider)=> immer noch nicht vollständig integriert, nicht mal in KMail! Immerhin ist der Akonadi-Dienst heute stabil und zuverlässig.
• ALT+F2 (KRunner) war in mehreren Versionen instabil, brauchte Minutenlang, um Nepomuk oder werweisswas abzufragen und stürzt auch heute noch unregelmässig ab.
• Für mich sehr unverständlich: Das eigentlich geniale Konzept der Aktivitäten wurde niemals richtig brauchbar eingeführt. Dabei hätte man in Verbindung mit den virtuellen Deskstops Einiges erreichen können. Aber es ist bis heute nur den wenigsten Benutzern klar, das es Aktivitäten gibt geschweige denn, wie man sie nutzen oder konfigurieren kann (die Konfiguration wird sehr gut versteckt).
• Die Systemkonfigurationswerkzeuge sind immer chaotischer organisiert und bezeichnet (wer sucht das Tastaturlayout schon unter “Input Devices”?)
• Abstürze in KMail, amarok und vielen anderen Applikationen. Auf das von KDE verwendete QT-Framework sind die Abstürze kaum zurückzuführen, denn reine QT-Applikationen scheinen in der Regel sehr stabil zu arbeiten.
• Desktopeffekte: Tolle und gutaussehende Effekte, nur fehlt ein einheitliches Konzept. Der Benutzer ist ganz auf sich gestellt, die für ihn nützlichen Komponenten einzurichten. Ausserdem auch hier: Noch viel zu viele Abstürze, wenn man “ungewöhnliche” Mausbewegungen o.ä. macht, während ein Effekt in Kraft ist. Heute kann man kaum noch jemanden mit den tollen KDE-Desktopeffects beeindrucken, wenn sie nur zur Hälfte funktionieren wegen Treiberproblemen oder gar abstürzen, wenn man sie gerade einem Kollegen zeigen möchte

Dies sind auch in den meisten Foren so etwa die am häufigsten bemängelten Punkte.

Bei KDE merkt man seit einigen Jahren, dass die Projektleitung chaotisch ans Werk geht, Entwickler Aaron Seigo ignoriert seit Jahren die unzähligen Kommentare in seinem Blog und den KDE-Foren, in denen die Benutzer einfach nur Stabilität, weniger Abstürze und weniger Bugs fordern, wenn er und andere Entwickler schon wieder mit den nächsten Features auftrumpfen, während grundsätzliche Attribute noch nicht mal stabil funktionieren. Sebastian Kügler indes kündigt bereits die Betaversion von KDE 4.7 an. Auch dort viele Kommentare, dass Version vor 1.0 (1998) stabiler war, als es 4.x je war usw. Je länger die Benutzerklagen bezüglich der mangelnden Stabilität von KDE 4 ignoriert oder beschwichtigt wurden, ohne dass es spürbare Verbesserungen gab (es gab sie, aber nur für Benutzer, die in der Lage waren, immer die neuesten Versionen zu installieren), desto ungeduldiger und drängender wurde natürlich deren Ton. Mittlerweile werden sogar Kommentare gelöscht, weil sie sich im Ton ganz vergreifen, schlecht bewertet und als “Trollpost” bezeichnet. Das deutet auf Schwierigkeiten hin, die sich längerfristig auswirken dürften. Sehr schade, denn es geht hier viel Vertrauen verloren, das doch so wichtig ist für Softwareprodukte.

Was tun? Noch bis Ende letzten Jahres gab es für mich kaum eine Alternative, denn KDE hat unbestritten viele tolle Applikationen und Gnome 3 steckte scheinbar noch etwas in den Kinderschuhen.

Mit dem Release von Fedora 15 sollte Gnome 3 in brauchbarer Form vorliegen. Mit grösster Skepsis stattete ich diesr Desktopumgebung einen Besuch ab. Kurz und gut: Ich war von Anfang an begeistert! Schon mit einer so frühen Release haben die Gnome-Entwickler ein absolut stabiles und benutzbares Produkt abgeliefert! Natürlich sind noch nicht alle Applikationen und Systemkomponenten migriert worden, aber das Projekt scheint sehr gut voranzukommen. Das alte Gnome hat mir nie gefallen, zu altbacken und kaum konfigurierbar. Doch genau dieser “Mangel” an Konfigurationsmöglichkeiten scheint bei Gnome 3 gut in das Gesamtkonzept zu passen. Die Gnome-Shell ist zwar gewöhnungsbedürftig, aber sie stellt nach kurzer Zeit sogar jede Mac-Oberfläche in den Schatten. Warum? Weil man sich auf die Arbeit mit den jeweiligen Applikationen konzentrieren kann und weil die verwendeten Effekte auf den Workflow ausgelegt sind und praktisch nie abstürzen. Auch wenn ich hoffe, dass ich in Zukunft mehr konfigurieren kann (z.B. gespeicherte Sessions, in welchen die Applikationen auf zugewiesenen Desktops starten), fehlt mir im Moment nichts. Ich kann es vielleicht in die Worte fassen: Es fühlt sich alles von Anfang an richtig an, die meisten Kommandos entdeckt man intuitiv (z.B. das Navigieren in den Desktops, das Aufrufen der Gnome-Shell etc.), die Projektleitung scheint zu wissen, was das Ziel ist und das merkt man. Vielleicht erweisen sich nun die höheren Einstiegshürden in die Gnome-Entwicklung als Vorteil, weshalb Gnome-Entwickler unter Umständen etwas “reifer” und zurückhaltender sind mit Features, die dem Workflow nicht wirklich helfen.

Man darf mich also seit dieser Woche als Gnome3 (oder Gnome-Shell?) Benutzer bezeichnen. Ich kann sagen, die Migration ist mir viel leichter gefallen, da ich nur in einem Drittel der Zeit dasselbe erreichte, wie mit einer neuen KDE-Installation: Evolution ist viel stabiler geworden (stabiler als KMail war es schon immer) und es hilft einem beim Einrichten von Googlemail-IMAP-Accounts. Ausserdem integriert es Google-Kalender sauber, genauso wie Google-Kontakte uvm. Im Büro nutze ich Evolution sogar mit unserem Exchange-Server (inkl. GAL) ohne Probleme. Soweit so gut.

Nochmals: Bitte versteht mich nicht falsch, die KDE-Entwickler sind Profis und viele Applikationen möchte ich nicht mehr missen (obwohl die Anzahl schrumpft aufgrund zunehmender Abstürze). QT ist und bleibt ein geniales Framework, dass ich jederzeit GTK vorziehe, um kleine Applikationen zu entwickeln. Auch werde ich weiterhin mit Spenden die einzelnen Projekte unterstützen. Nur bezweifle ich mittlerweile offiziell, dass die Projektleitung dazu fähig ist, dieses Boot wieder in ruhigere Gewässer zu lenken. Nach der Lektüre von Frederick P. Brooks “The Mythical Man-Month”, Peter Seibel’s “Coders at Work” und anderen Materialien über vergangene Grossprojekte im Softwarebereich deutet für mich Vieles darauf hin, dass KDE4 niemals stabil werden wird. Als Entwickler muss man sich dann überlegen, ob nicht ein kompletter Neuanfang das Beste wäre. Als Benutzer hat man glücklicherweise mit Gnome 3, XFCE usw. brauchbare Alternativen.

Drei Jahre ist es her, seit ich PCLinuxOS das letzte mal getestet habe. Mittlerweile kenne ich auch die ihm zugrunde liegende Distribution Mandriva sehr gut. Ich war damals auf Anhieb begeistert, wie einfach eine gut durchdachte Desktop-Distribution sein kann, wenn die Macher sich wirklich auf das Wichtigste Konzentrieren: Die Zeit, die ein Benutzer für seine Tätigkeiten benötigt.

Continue reading…

Wer wie ich das Vergnügen hat, für eine VPN-Verbindung in’s Büro auf ein proprietäres Werkzeug angewiesen zu sein, der muss sich zuweilen zu helfen wissen, um das entsprechende Programm auch unter modernen Linuxen betreiben zu können. So auch bei “SSL Network Extender” von Checkpoint, das nicht auf ein die Standards (Cisco VPN, OpenVPN) aufsetzt, sondern ein eigenes, nicht offenes VPN-Format verwendet, das unter der Haube machen kann, was es will, denn niemand sieht es. Abgesehen davon, dass es ziemlich schwierig ist, ohne Kundenlogin an das SSLExtender Binary für Linux ranzukommen, ist das Teil auch noch sauschlecht programmiert, aber dazu komme ich später.

Installation

Die Installation ist einfach, das selbstextrahierende Shellskript wird ausgeführt und 3 Sekunden später ist das Programm installiert und bereit:

./Check_Point_SNX_R66_HFA_01_For_Linux_800004013.sh

Erste Zweifel

Beim ersten Ausführen allerdings wird einem schon der erste Stock zwischen die Beine geworfen:

snx
snx: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Die Software hat also tatsächlich eine Versionsabfrage für die Grundbibliothek libstc++ hart eincodiert! Uns fehlen die Worte und erste Zweifel an der Programmierqualität (oder fehlt einfach die Erfahrung mit Linux?) des Hauses Checkpoint kommen auf… Aber wir wären keine echten Geeks, wenn wir dafür keinen Workaround fänden:

Für Fedora u.ä. steht dazu meist eine compat-Version bereit, die für ebensolche Fälle gemacht ist:

yum install compat-libstdc++-33

Achtung! Auf 64bit-Versionen muss die 32bit-Version explizit angegeben werden (denn natürlich hat Checkpoint keine 64bit-Version auf Lager):

yum install compat-libstdc++-33.i686

Für Ubuntu’s neuere Versionen gibt es diese gar nicht mehr, aber man kann sie einfach aus einem älteren Repository ziehen: http://packages.ubuntu.com/jaunty/i386/libstdc++5/download

Trügerischer Tunnelgräber

Also auf geht’s mit einem neuen Versuch:

snx -u BENUTZER -s SERVERNAME
FATAL: Could not open tun.ko. No such file or directory
SNX: Virtual Network Adapter initialization and configuration failed. Try to reconnect.

Oh je, warum zum Geier benötigt der SSL Network Extender das Tunnel-Kernelmodul? Eine kurze Suche im Internet bringt an’s Tageslicht, dass auch diese Abhängigkeit fest einprogrammiert ist, obwohl SSL Extender einen eigenen, proprietären VPN-Tunnel erstellt. Auf Fedora tritt dieser Fehler nicht auf, weil das Modul “tun” mit dem Standardkernel ausgeliefert wird. Unter Ubuntu jedoch ist dies Fehlanzeige, auch nachträglich lässt sich das Modul nicht installieren. Man müsste den Kernel neu übersetzen mit der entsprechenden Option. Aber wir sind doch nicht bescheuert und machen uns diese Mühe, bloss weil da ein paar Erstsemesterprogrammierer bei Checkpoint sizten! Das Modul muss einfach existieren, es muss überhaupt nix tun, also wird es einfach gefaked, siehe dazu auch: http://wiki.ubuntuusers.de/Check_Point_SSL_Network_Extender

mkdir faketun
cd faketun
echo -e "#include <linux/module.h>\nstatic int start__module(void) {return 0;}\nstatic void end__module(void){return;}\nmodule_init(start__module);\nmodule_exit(end__module);">tun.c
echo -e "obj-m += tun.o\nall:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) modules\nclean:\n\tmake -C /lib/modules/\$(shell uname -r)/build/ M=\$(PWD) clean\nclean-files := Module.symvers">Makefile
make
sudo install tun.ko /lib/modules/`uname -r`/kernel/net/tun.ko
sudo depmod -a

Ab jetzt funktioniert SSLExtender auch auf Ubuntu und man kann in Ruhe von zu Hause aus arbeiten, auch mit diesem proprietären VPN-Tunnel. Dem Arbeiten am Wochenende steht nun nichts mehr im Wege, ausser man hat nebenbei noch ein Privatleben

Ich wünsche allen ein gutes neues Jahr, auf eine weitere Dekade! Pünktlich zum Jahresanfang stolperte ich auf die deutsche Übersetzung eines längeren Postings, das selber schon älteren Datums (aber immer noch absolut zutreffend) ist. Es beinhaltet eigentlich so ziemlich die beste Erklärung, warum Linux nie ein Windowsersatz ist und sein wird und warum viele verärgerte Windowsbenutzer erst eher bei sich selbst eine Veränderung machen müssen, als einfach mal schnell “auf Linux” (meist Ubuntu heutzutage) zu wechseln. Die Lektüre lohnt sich absolut:
http://www.felix-schwarz.name/files/opensource/articles/Linux_ist_nicht_Windows/

OK ausnahmsweise, weil Feiertage sind, auch mal eine Nicht-Linux-Distribution auf dem Prüfstand. Nämlich FreeNAS, eine hochspezialisierte BSD-Unix-Variante mit einem NAS-Server, wie der Name ja schon andeutet, der als Live-Image oder “installierbares Image” gebraucht werden kann.

Der Grund, weshalb ich auf FreeNAS kam, war, dass ich meine vielfältigen Heimnetz-Services, die sich über die Jahre in meinen virtuellen CentOS’s angesammelt haben, konsolidieren wollte. Mit einem NAS (Network Attached Storage, also Diskplatz, der über verschiedene Dienste im Netz auf vielfältige Weise nutzbar gemacht wird) und einer Weboberfläche ist dies einfach lösbar und macht mehr Spass als “nur” mit einer Hardware-Appliance, die teuer ist, keine offene Software hat und meist auch weniger Services anbietet.

Herkunft / Ursprung

FreeNAS ist ein kleines FreeBSD und wurde von Olivier Cochard und Volker Theile geschaffen. Heute besitzt iX-Systems FreeNAS, aber es wird natürlich als Opensource-Projekt weitergeführt.

Wichtigste Daten in Kürze:

• Homepage: http://www.freenas.org
• Ungefähre Grösse der Vollversion als ISO-Image: 80 MB
• LiveCD Funktion: Ja
• Sprachen: Div. Übersetzungen
• Abgeleitet von: FreeBSD 7.2
• Standarddesktop: Keinen, vollständige Steuerung mit Webinterface
• Kosten für Updates und Support: Keine (BSD-Lizenz)
• Lizenz: BSD
• Dokumentationen: http://freenas.org/documentation:setup_and_user_guide
• Forum: http://sourceforge.net/apps/phpbb/freenas/index.php
• Wiki / Knowledgebase: http://www.freenaskb.info/kb/
• Bugtracker: Bugzilla => http://sourceforge.net/tracker/?group_id=151951&atid=782616
• Mitmachen: http://freenas.org/community:how_to_contribute

Continue reading…