Tuz

…hab ich vor wenigen Tagen aus dem Mund eines IT-Kollegen gehört. Nun, genau solche Aussagen verursachen bei mir ein gewisses innerliches Bedürfnis, in rettender Art und Weise -pro Linux- verbal (nach aussen) aktiv zu werden.

Ich mag es einfach nicht, wenn Leute behaupten, dass Linux (bzw. Linuxdistris) mist sind, weil die und die Hardware nicht unterstützt wird.

Liebe Leute, es sei hier festgehalten, dass es NICHT die Aufgabe von “Linux” ist, Hardware zu unterstützen, diese möglichst noch automatisch einzubinden und dann noch als funktionstüchtig zu präsentieren!

Genaugenommen sollte es hier eigentlich heißen: “Es ist NICHT die Aufgabe der Linux-/Kerneldeveloper, den Linuxkernel mit diversem Code vollzustopfen (oder eben auch Module mitzuliefern), damit “Hardware XY” auch unter Linux läuft.

Dank der Entwicker wird heutzutage bereits einge große Masse an Hardware out-of-the-box erkannt, ohne auf die eigentlichen Hardwareherstellerfirmen zurückgreifen zu müssen.

Wieso?

…frage ich mich, wird in diversen Hardwaresparten Linux noch immer mehr als stiefkindlich behandelt? Ist es der (noch) geringe Marktanteil bezogen auf den Desktopbereich, oder kommt der Druck woanders her?

Vielleicht scheut man ja auch die zusätzlichen Entwicklungskosten für einen Linuxtreiber? Ich bin kein Entwickler und kann  deshalb nicht wirklich beurteilen, wieviel Aufwand es wäre, für Hardware XY zusätzlich einen Linuxtreiber mitzuliefern.

Wieso schafft es dann aber Nvidia, Intel, AMD/ATI…?

Abbildung oben (Tuz): Durch Klick auf das Bild erhält man weitere Infos, was es mit TUX/TUZ auf sich hat. 

Zitat-Wikipedia: “Durch diesen vorübergehenden Austausch des Maskottchens (es wurde TUX durch TUZ ersetzt) soll Aufmerksamkeit auf den ausschließlich auf Tasmanien lebenden Beutelteufel gelenkt werden, dessen natürlicher Fortbestand durch die Krankheit Devil Facial Tumour Disease (DFTD) bedroht ist.”

Inspiriert von einem Artikel einer bekannten österreichischen Tageszeitung, hab ich mich dazu hinreissen lassen, mich bei Ubuntu One (https://ubuntuone.com/) zu registrieren. Ich bin zwar kein Freund der Speicherung von Daten in einem Webspeicher, aber Ubuntu ist mir irgendwie sympathischer wie diverse andre Anbieter.

Natürlich habe ich dennoch nicht vor, sicherheitskritische Dokumente etc. dort abzuspeichern.

Der Registrierungsvorgang ist schnell erledigt. Hat man bereits einen Lauchnpad Account kann man selbigen verwenden, um sich für Ubuntu One zu registrieren.

Mit der Registrierung selbst ist es aber noch nicht getan, denn man wird zuallererst in eine Warteschleife verfrachtet und erhält später eine Einladung zu Ubuntu One.

In der Standardversion (GRATIS) werden 2GB Speicherplatz angeboten. Die erweiterte Version bietet hingegen 10GB Speicherplatz, allerdings diesmal nicht gratis, sondern für 10 US-Dollar / Monat.  Nicht wirklich günstig, wie ich finde…

Mal sehen, wie lang es dauert, bis ich eingeladen werde…

Unter Umständen tritt dieses Problem auf, wenn man einen proprietären Treiber (zB. Nvidia etc) einsetzt und ein Kernel Update durchführt.

Der Grund für dieses Verhalten ist, dass für die Grafikkarte ein eigenes Modul kompiliert wird, welches mit den Quellen (kernel-header) der gerade eingesetzten Kernelversion, kompiliert (also gebaut) wurde.

Wechselt man nun den Kernel (dies kann zum Beispiel im Zuge eines Systemupdates passieren), passt die vorhandene Modulversion des Grafikkartentreibers nicht mehr zum eingesetzten Kernel und kann somit auch nicht mehr beim Start des X-Window-Systems von Xorg geladen werden.

Was kann man machen?

Der Start von Xorg scheitert, man landet in der Konsole. Gerät ein Neueinsteiger in diese Situation, ist er oft überfordert.

Hier gilt: Ruhig bleiben! Ist alles halb so schlimm

Ist man nicht als root eingeloggt, holt man das folgendermaßen nach:

• logout
• Loginname:  root
• Return
• Eingabe d es Rootpasswortes
• Return

Nun klinkt man sich in das Verzeichnis /etc/X11 (Achtung groß geschriebenes X) ein:

• cd /etc/X11
• Return

und öffnet die Konfigurationsdatei von Xorg (xorg.conf) mit Hilfe eines Texteditors (hier vim):

• vim xorg.conf
• Return

Sollte vim nicht installiert sein, kann man das in debianbasierten Distributionen wie folgt nachholen:

• apt-get update
• Return
• apt-get install vim
• Return

Infos zur Bedienung von vim hier:  http://www.pc-howto.com/linux/texteditor-vim/

Wir haben mittels vim nun die Datei xorg.conf geöffnet. Ausgehend von einer proprietären  Treiberinstallation gilt es nun, den Abschnitt in der xorg.conf zu finden, in der der Grafikkartentreiber geladen wird:

Sieht dann z.B. im Falle einer ATI Grafikkarte ungefähr so aus:

Section “Device”
Identifier “ATI Technologies, Inc. FireGL Mobility T2 (M10 NT)”
Driver “fglrx”
BusID “PCI:1:0:0″
Option “backingstore” “true”
Option “RenderAccel” “true”
Option “DesktopSetup” “0×00000100″ # clone
Option “MonitorLayout” “LVDS,CRT”
Option “MetaModes” “1600×1200-1024×768 1600×1200-1280×1024 1600×1200-1600×1200″
EndSection

Wichtig ist der ROT markierte Teil, denn hier wird der Treiber fglrx für die ATI-Grafikkarte bzw. Nvidia-Grafikkarte (unten) geladen.

Bei Nvidia sieht die xorg.conf in etwa so aus:

Section “Device”
Identifier “Nvidia 7600GS”
Driver “nvidia”
Option “DynamicTwinView” “0″
Endsection

Was ist in der Xorg.conf abzuändern?

Wie erwähnt, ist einzig die Zeile Driver “nvidia” bzw. Driver “fglrx” wichtig.

Um  den Standardvesa-Treiber zu aktivieren ändert man die Zeile Driver “…” wie folgend ab:

• Driver “vesa”

Will man den mitgelieferten Nvidiatreiber verwenden:

• Driver “nv”

Soll der Standard Standard-Atitreiber zu aktivieren:

• Driver “ati”

Auf der sicheren Seite sollte man in jedem Fall mit Driver “vesa” sein.

Xorg Startversuch

Ist alles erledigt loggt man sich wieder aus, mit dem normalen User wieder ein und versucht aus der Konsole heraus ein:

• startx
• Return

Alternativ kann man auch das System einfach neu  starten oder mit dem Rootuser folgendes in die Konsole tippen:

• /etc/init.d/kdm restart (bei KDE)
• /etc/init.d/gdm restart (bei Gnome)
• jeweils abgeschlossen durch Return

Aus der Konsole heraus den proprietären Treiber erneut installieren

Weiß man, wo man den proprietären ATI- oder Nvidiatreiber abgespeichert hat, reicht es auch aus, die Installation des Treibers aus der Konsole heraus erneut zu starten.  Das Modul für die Grafikkarte wird dann neu erstellt und Xorg sollte sich wieder starten lassen.

Zu erwähnen gilt es ausserdem noch, dass der Treiber nach dem Download nicht aus der Konsole aufgerufen werden kann. Dies deshalb, da er von Haus aus nicht ausführbar ist.

Um den Treiber ausführbar zu machen benötigt man den Befehl chmod!

• chmod +x <Dateiname des Treiber>
• Return
• Aufruf der Installation mit ./<Dateiname des Treiber> natürlich alles als Rootuser

Zuallererst bemühte ich eine VM:

Was positiv auffällt

Die Installationsroutine ist abermals vereinfacht worden, was es nun wahrscheinlich sogar dem wirklichen Beginner stark vereinfacht, das System auf den PC zu bringen.

Zur Verteidigung von Debian GNU Linux sei jedoch auch erwähnt, dass der grafische Installer von Debian ebenso keine all zu hohen Anforderungen an den “Installateur” hat.

Zur Hardwareerkennung gibt es zu sagen, dass mein Acernotebook “out of the box” alle Stücke spielt. (Wirelesslan, Hotkeys etc – alles wunderbar). Zugegeben, das Notebook ist schon älter und hat noch dazu einen Intel Wlan-Chip “ipw2200″, der sowieso annähernd nie Probleme macht.

Was mir wirklich gut gefällt ist das von Haus aus perfekt optimierte Schriftbild, dass keine Wünsche offen lässt.

Unter KDE 4.2 wird zur Verwaltung des Netzwerkes ein -mir noch nicht bekanntes- Miniprogramm eingesetzt. Sieht nett aus und funktioniert einwandfrei.

Betrachtet man das Gesamtpaket, ist es jedenfalls als gut gelungen zu bewerten.

Nun, ich habe gerade vor 2 Tagen wiedermal eines dieser Erlebnisse gehabt, die mich ganz einfach ein wenig ärgern. Ich geb ja zu, etwas im Linuxlager zu sein und vielleicht sogar Partei für das freie OS zu ergreifen.

Ich kann die Frage: “Ist Linux reif für den Desktop?” für mich persönlich mit einem klaren JA beantworten. Dies gilt allerdings wiederum ausschließlich für meine Anforderungen.

Der Ordnung halber sei erwähnt, dass die Aussage “ist Linux reif…” an sich ein wenig unrichtig ist, denn als Linux bezeichnet man ausschließlich den Betriebssystemkern (Kernel) und nicht das Gesamtpaket, welches grundsätzlich als Linuxdistribution zu bezeichnen ist.

 Ich verwende Debian GNU Linux bzw.  Sidux, um meine täglichen Tätigkeiten erledigen zu können. Dazu zählt zum Beispiel:

• Abrufen und schreiben von Emails
• Surfen im Web
• Webdesign, grafische arbeiten
• Nutzen einer VM (virtuellen Maschine) zum testen von diversen Betriebssystemen, Distributionen und Netzwerktests

All das ist mit Hilfe des “Pinguin” überhaupt kein Problem.

Der Faktor Anwender

Ein Anwender (und die meisten Menschen auch) sind meist Gewohnheitstiere.  Setzt man einem User, der eine Anwendung schon Jahre gewohnt ist und ansonsten nicht wirklich viel mit PC auf dem Hut hat “plötzlich” eine alternative Anwendung vor, die zwar vom Leistungsumfang annähernd identisch mit der alten Anwendung ist, jedoch zum Beispiel die Symbole anders aussehen und eventuell noch wo anders zu finden sind, kann es bereits zu Komplikationen kommen.

Natürlich kommt es auch auf den Wissensstand des Anwenders an, ob er dennoch damit zurechtkommt, vielleicht ein wenig sucht, die Hilfe nutzt, oder ganz einfach mit der Situation überfordert ist.

Der Standardanwender wird sich sicher nicht die Mühe machen und lange suchen

Das soll jetzt keineswegs in irgend einer Form abwertend sein, nein! Vielmehr kann man verstehen, dass der User ganz einfach nur daran insteressiert ist, seine Arbeit zu machen, dennoch sind  Sätze wie:  ”Das geht damit nicht, ich will das haben, wo das so und so geht und vor allem will ich das haben was ich sonst auch hab…” sicher bekannt.

Heimanwender vs. Firmenbetrieb

Auch wenn der Anwender zu Hause problemlos mit “Linux am Desktop” arbeiten kann, sieht es da in einer Firmenumgebung meistens anders aus. Hier sind oft Fachanwendungen notwendig.

Diese Fachanwendungen wiederum sind abhängig von anderen Applikationen und Betriebssystemen. Vor allem dann, wenn es um Auswertungsmöglichkeiten und die Schnittstelle zu anderen Programmen geht, gibt es meist eine vorgegebene Richtung und somit absolut keine Flexibilität. Und das wäre nun der Knackpunkt!

Gerade in Zeiten wie diesen wo man “SPAREN” gar nicht groß genug schreiben kann, ärgert es mich ein wenig, dass Schnittstellen sooft immer nur in “eine Richtung” programmiert werden. Nun könnte man damit argumentieren, dass die Entwicklung von zusätzlichen Schnittstellen ja auch nicht gratis ist – stimmt natürlich, flexibel ist man aber somit nicht!

Oft gehörtes Zitat wäre: “Ich programmiere sicher nicht eine Schnittstelle zu noch einem Programm…”

Langer Rede kurzer Sinn: Solange nicht plattformunabhängig programmiert wird (vor allem bei Fachanwendungen), sehe ich persönlich zumindest in einer Firmenumgebung keine Chance für Linux auf dem Desktop. Hierfür wäre es vielleicht sogar vonnöten, sich alles selber zu “stricken” und das kostet auch (Personal, Resourcen…) – Ein Teufelskreis?

In welchem Umfang die Installation stattfindet, kann man sehr komfortabel mittels der Debian Installationsroutine auswählen.  (Es wird davon ausgegangen, dass man ein “Standardsystem” ohne “Desktopumgebung” mittels Debian-Netinstall CD installiert.)

Wenn die Installation des Grundsystems abgeschlossen ist, beginnen wir mit den manuellen Schritten zur weiteren Installation.

System auf aktuellen Stand bringen

An der Konsole findet der Login mit dem Rootuser “root” statt. (Von einer funktionierenden Internetverbindung wird ausgegangen!)

Als nächsten prüfen wir die Datei sources.list, die sich im Vereichnis /etc/apt befindet. Zu öffnen ist diese Datei mit einem Editor, den man frei wählen kann. (Ich greife auf “vim” zurück).

Die Sourceslist sollte folgenden Inhalt haben:

• deb http://ftp.at.debian.org/debian/ etch main contrib non-free
• deb-src http://ftp.at.debian.org/debian/ etch main contrib non-free
• deb http://security.debian.org/ etch/updates main contrib non-free
• deb-src http://security.debian.org/ etch/updates main contrib non-free

Repositories contrib und non-free greifen auf Pakete zurück, die nicht mit der Debianphilosophie harmonieren, da hier auf teiweise nicht freie bzw. generell auf nicht freie Repositories zurückgegriffen wird. (Dies stellt zwar keine Gefahr dar, jedoch weise ich an dieser Stelle einfach darauf hin. Wer sein System ausschließlich nach dem Debianway betreiben will, kann auf contrib bzw. non-free auch verzichten, hat dann aber nicht den vollen Paketumfang zur Verfügung.)

Nach Anpassung bzw. Kontrolle des Inhaltes sollte das System mit den Onlinerepositories synchronisiert werden:

• apt-get update
• und RETURN
• apt-get upgrade
• und RETURN

Apt-get update synchronisiert das System mit den Onlinequellen. Apt-get upgrade holt aktualisierte Pakete für die bereits installierten Pakete aus dem Internet und installiert die Updates.

Das System sollte also nun auf dem aktuellen Stand sein.

Pakete für den xserver-xorg, kdm und kde installieren

• apt-get install xserver-xorg (und die Installation der Pakete bestätigen)
• apt-get install xorg (Bei der Installation von “xorg” wird u.U. ein Installationsdialog zur Konfiguration der Grafikkarte / Monitor aufgerufen, dies einfach entsprechend der eingesetzten Hardware einstellen.) Bei Debian Lenny wird hier der Dialog zum Konfigurieren der Grafikkarte / Monitor NICHT mehr angezeigt. Der Xserver versucht alle nötigen Einstellungen selbst zu erkennen!
• apt-get install kdm
• apt-get install kdebase

Anmerkung: Bei der oben erwähnten Vorgangsweise werden ALLE Xserver für alle verfügbaren Grafikkarten installiert! Dies stellt angesichts der heutigen Festplattenkapazitäten zwar kein Problem dar, jedoch lässt sich hier natürlich auch explizit der notwendige Xserver installieren.

Den Xserver starten

Ist alles glatt gelaufen und wurden die korrekten Einstellungen während der menübasierten Installation des Xserver getätigt loggt man sich als User ein und startet den Xserver durch startx von der Konsole aus.

Wenn auch das klappt, besteht noch die Möglichkeit den K-Loginmanager (grafischer Loginmanager) automatisch beim Systemstart starten zu lassen.

Hierfür kann man das Paket rcconf nachinstallieren (apt-get install rcconf in einer Konsole) und dann starten, um zu kontrollieren, ob KDM in der erscheinenden Liste aktiviert ist. (Wenn nicht einfach aktivieren und rcconf beenden).

Alle Anwender, die Debian GNU Linux bzw. z.B. auch Sidux verwenden müssen, um die aktuelle KDE 4.1 Version einsetzen zu können, auf das experimental Repository von Debian zurückgreifen. Das Problem ist nun, dass Apt in Standardkonfiguration keine Updates aus dem experimentellen Repository zieht.

Wenn man immer auf dem aktuellen Stand bleiben will, dann bedient man sich des sogenannten Apt-Pinning. Hier wird mittels einer Prioritätenliste festgehalten, welche Priorität ein Repository hat.

Ich beziehe mich auf den Artikel des Debian KDE Team indem erklärt wird, wie man das experimentelle Repository so verwenden kann (pinnen), dass ausschließlich bereits installierte Pakete aus diesem Repository upgedatet werden. Alle anderen installierten Pakete, die NICHT aus dem experimentellen Repository stammen, werden aus den Standardrepositories (zb. etch oder testing) installiert.

Vorgangsweise

Mit einem Editor öffnet man die Datei:

• /etc/apt/preferences

Sollte die Datei noch nicht vorhanden sein, ist das auch kein Problem, denn dann erstellt man sie einfach.

Als Inhalt der Datei preferences ist folgendes zu verwenden:

• Package: *
• Pin: release a=experimental
• Pin-Priority: 101

Um nun z.B. bereits installierte Pakete aus dem experimentellen Repository upzudaten verwendet man:

• apt-get update
• apt-get dist-upgrade
• oder aptitude

Quelle: Debian KDE Team

Wie vielleicht vielen bekannt ist, gibt es einen sogenannten Any-Any Patch um der Vmware-Installation bei auftretenden Kompilierungsfehlern auf die Sprünge zu helfen. Dieser Patch wird immerwieder an die neuen Gegebenheiten (Kernelversionen) angepasst. Mit dem gerade aktuellen Siduxkernel funktioniert der Any-Any Patch in Version 117.

Eine Downloadmöglichkeit gibt es u.A. hier: http://download.rsbac.org/tmp/?C=S;O=A

Wie es scheint, gibt es zur Zeit auch noch Probleme mit dem Start der Vm-Ware-Konsole. Wer beim Starten die Fehlermeldung: Fehler:Zusicherung »((int) ((xcb_req) – (dpy->request)) >= 0)« nicht erfüllt erhält, sollte sich den letzten Post in folgendem Forum anschauen: http://communities.vmware.com/thread/154159

Mittlerweile hat man Gott sei Dank die Qual der Wahl in Sachen Virtualisierungssoftware.  Ich habe mich dazu entschlossen mit Virtualbox (www.virtualbox.org) einen weiteren Versuch zu starten. Und siehe da, es funktioniert. (Bitte auf weiterlesen klicken, um den gesamten Artikel lesen zu können.)

Opensuse Bootbildschirm

Natürlich wähle ich hier Installation

Nun ratterte die DVD im Laufwerk dahin, Opensuse bootete. Obwohl die grafische Aufmachung von Opensuse wirklich sehr gelungen ist, ist mir ein simpler Textinstaller noch immer lieber, aber das ist Geschmackssache. Andererseits geht es ja auch um “Anwenderfreundlichkeit”.

weiter gehts… Die Installationsumgebung wird vorbereitet

Hm… Eine Lizenzvereinbarung, die ich akzeptiere – klar, ich will ja installieren

Da die Platte ohnehin leer ist, wähle ich Neuinstallation

Auch hier fällt die hübsche optische Aufmachung von Opensuse auf, Auswahl der Region

Welche Desktopumgebung darf’s denn sein? Gnome, KDE4 oder KDE3.5?

Hier muss festgehalten werden, dass die KDE Version 4.x zur Zeit noch ein paar kleine Kinderkrankheiten hat. Viele tendieren eher zu KDE 3.5, weil es eine stabile und ausgereifte Desktopumgebung ist. (Ich wähle hier auch KDE3.5)

Auf der anderen Seite muss man bedenken, dass ein Ausbessern der “Fehler” durch dir Entwickler nur dann möglich ist, wenn seitens der Anwenderinnen und Anwender ein gewisses Feedback zu den Entwicklern durchdringt. Quasi “Nur durch Anwendung von KDE4, können möglichst viele Kinderkrankheiten gefunden werden und auch ausgebessert werden”.

Die Entscheidung bleibt natürlich jedem selbst überlassen.

Opensuse unterbreitet einen Partitionierungsvorschlag, die Festplatte ist leer, also ist der Partitionierungsvorschlag ok.

Anlegen des Benutzerkontos

Was hier vielleicht auffällt ist, dass man über den Eintrag dem“Benutze das Passwort für den Systemadministrator” für den User “root” das identische Passwort setzen kann , wie für den normalen User.  Eine gute Idee? :-/ Ich rate eher davon ab.

Eine abschließende Zusammenfassung

…und los gehts > Klick auf Installieren

ab jetzt läuft alles automatisch, man ist nur noch Zuseher

Die Installatin verläuft normalerweise ohne Probleme. Bald darauf sollte man eigentlich den Opensuse Begrüßungsbildschirm bewundern können.

Mein Fazit: Was die Installationsroutine betrifft, gibt es einige grafische Verbesserungen. Obwohl ich hier in einer VM installiert habe, kann man davon ausgehen, dass Opensuse 11.0 noch mehr Hardware “out of the box” erkennt. Mit gängigen Geräten sollte also ein “Plug & Play” möglich sein.

Mir kommt die Installationsgeschwindigkeit ein wenig schneller vor, wie bei den Vorgängerversionen. Hervorzuheben ist, dass man gleich 3 der gängigen Desktopumgebungen auswählen kann, auch wenn KDE4 noch ein wenig optimiert werden muss.