Nvidia Treiber

Da war doch was! Ältere Nvidia-Grafikkarten vertragen sich nicht mit den aktuellen Treibern. Doch während man für Windows die entsprechende Version, welche noch die Karte unterstützt, runterladen und installieren kann, geht es bei Linux ein wenig anders. Wie es bei Arch gemacht wird, will ich hier beschreiben.

Vorbereitung

So viel gibt es da nicht vorzubereiten. Man muss wissen, welche Karte man hat und dann herausfinden, welchen Treiber man braucht.

Welche Karte man hat findet man eigentlich ganz einfach heraus. Man öffnet einen Terminal und gibt folgendes ein:

sudo lspci -k | grep -A 2 -E "(VGA|3D)"

Bei meiner Frau kommt dann folgendes raus:

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
	Subsystem: ASUSTeK Computer Inc. EN210 SILENT
	Kernel driver in use: nvidia

Es handelt sich also um eine GT218 der GeForce 210 Serie. Damit können wir nun auf die Suche nach dem richtigen Treiber gehen. Dafür bietet sich natürlich die hauseigene Seite von Nvidia an, die man hier findet.

Das sind meine Suchparameter und wenn ich die abschicke bekomme ich folgendes:

Wir brauchen also die Version 340.107. Sollte ja kein Problem sein. Man kann sich den Treiber auch direkt von der Seite laden, ich bevorzuge aber den Weg über den Paketmanager.

Installation

Findet man jetzt das entsprechende Paket für den Treiber in pacman unter Arch? Nee, Arch-Geleckt! Das müssen wir über AUR machen. Das ist aber auch irgendwie gar nicht so schlimm und allgemein empfinde ich diese Variante in einigen Punkten sogar besser als die Overlays in Gentoo. Zumindest in mancher Hinsicht.

Also. Wir brauchen zuerst mal eine Quelle. Da ist zum Beispiel Google sehr freundlich, denn wenn man dort eingibt:

arch nvidia 340

Bekommt man dieses Ergebnis so etwa auf dem zweiten Platz.

https://aur.archlinux.org/packages/nvidia-340xx/

Dort findet sich nun der Link, mit dem man sich die Quelle mittels git besorgen kann. Ich habe auf eigentlich allen Rechnern mit Arch im Home-Verzeichnis meines Benutzers das Verzeichnis »aur«, wo ich so zeug drin baue und von dort aus installiere. Wohl gemerkt, Pakete mit aur baut man als Benutzer und installiert sie erst danach als Root! Verwirrt mich zwar ein bisschen, ist aber kein Problem. Ich gehe also in mein aur Verzeichnis und gebe dort folgendes ein:

git clone https://aur.archlinux.org/nvidia-340xx.git

Das Ergebnis ist nicht sonderlich spektakulär:

Wir haben aber nun ein neues Verzeichnis namens »nvidia-340xx« und da wechseln wir rein. Wie das geht weiss hoffentlich jeder.

Das Paket wird so erstellt:

makepkg

Macht man das zum ersten Mal kann man stark davon ausgehen, dass folgendes dabei herauskommt:

Da wäre das, was ich am Overlay in Gentoo besser finde. Da werden Abhängigkeiten dann einfach gleich mitinstalliert. Aber gut, kümmern wir uns drum.

Eigentlich ist nur »nvidia-340xx-utils=340.107« wirklich interessant. Die beiden anderen Punkte beziehen sich auf den Kernel. Wenn man sein System aktuell hält, bekommt man diese Meldung natürlich nicht. Da ich es hier aber in einer virtuellen Umgebung demonstriere und die noch nicht auf dem neusten Stand ist, kommt es eben zu dieser Meldung.

Schau an, kaum hat man das System auf den neusten Stand gebracht, klappt es auch mit den Abhängigkeiten!

Wie ich ja schon sagte, nur »nvidia-340xx-utils=340.107« ist wirklich von Belangen und da man das nicht einfach in den Paketquellen findet, wer hätte es gedacht, muss man es ebenfalls mittels AUR installieren.

Also raus aus dem Verzeichnis und das entsprechende Paket mittels git clonen.

git clone https://aur.archlinux.org/nvidia-340xx-utils.git

Rein in nvidia-340xx-utils und dort das ganze bauen, also:

makepkg

Da gibt es dann normalerweise keine Probleme mit irgendwelchen Abhängigkeiten und man kann warten, bis alles geladen und gebaut wurde. Dann geht es weiter.

Wenn alles fertig ist, sieht es in etwa so aus, dann können wir weitermachen. Gebaut ist jetzt alles, jetzt muss es nur noch installiert werden und das machen wir mit pacman als Root.

sudo pacman -U nvidia-340xx-utils-340.107-3-x86_64.pkg.tar.xz

Das dauert einen kleinen Moment. Danach ist das Paket aber installiert und nun können wir uns endlich um den Treiber kümmern!

Also wieder raus aus dem Verzeichnis und zurück nach nvidia-340xx. Wenn wir alles richtig gemacht haben, dann sollte das Paket jetzt einwandfrei bauen!

Bingo! Jetzt hat das alles geklappt und wir können endlich den Treiber installieren.

sudo pacman -U nvidia-340xx-dkms-340.107-3-x86_64.pkg.tar.xz

Geschafft! Damit ist der Treiber nun endlich installiert und kann verwendet werden. Normalerweise startet man einfach einmal neu und fertig!

Update

Wieso genau denn Updates? Die Treiber sind doch uralt, dafür gibt es doch keine Updates mehr, oder?

Doch, die gibt es! Allerdings handelt es sich dabei eigentlich nur um Patches, damit der Treiber mit dem aktuellen Kernel funktioniert.

Um ein Update durchzuführen, muss man jetzt nicht wieder das ganze Spielchen von Vorne beginnen. Auch braucht es nvidia-340xx-utils dafür nicht. Es geht einfach und schnell.

Man muss in das Verzeichnis »nvidia-340xx« gehen und dort mittels git die neuste Version herunterladen.

git pull

Gibt es eine neue Version wird das, was sich geändert hat, angezeigt. Danach ist es das gleiche Spiel wie oben. Erst makepkg, dann pacman -U.

Das muss man aber nicht wirklich oft durchführen. Eben dann, wenn ein neuer Kernel installiert wurde, der mit der aktuellen Version des Treibers nicht mitspielt. Das merkt man ja schnell, wenn man den Rechner bootet und anstatt dem Login-Bildschirm blinkt da nur ein Cursor. Da empfiehlt es sich dann, den Treiber zu aktualisieren und in aller Regel funktioniert es dann sofort wieder.

Anmerkung

Auch wenn ich hier jetzt auf einen spezifischen Treiber eingegangen bin, geht es doch auch mit anderen Versionen. Man muss dann eben nur die entsprechende Pakete auswählen, dann klappt das auch. Einfach mal ein bisschen mit rumspielen, so viel kann man da nicht kaputt machen!

Dart-Halter V 3.0

Ach ja, man entwickelt etwas, ist dann soweit zufrieden damit und was dann? So ganz aus Versehen löscht man das Zeug und es ist weg. Da nützt alles heulen nicht, schliesslich hätte ich ja auch ein Backup machen können. Habe ich nicht, also frisch ran ans Werk!

Alles kopieren?

Die Version 2.3 des Darthalters hat sich mittlerweile bewährt! Ich weiss gar nicht, wie viele Spiele ich damit schon absolviert habe und alles, was ich daran wirklich zu bemängeln habe ist, dass sich das PLA im Auto bei hohen Temperaturen verformt hat. Davon abgesehen hat sich das System als absolut tauglich herausgestellt!

Also könnte ich einfach das Original noch einmal vermessen und nachbauen. Wäre nicht unlogisch und auch nachvollziehbar!

Neu bauen?

Ich könnte aber natürlich auch zurück ans Reissbrett und alles von Vorne entwickeln. Das hätte auch so seine Vorteile, könnte ich doch auf diese Weise einen völlig neuen Ansatz verfolgen. Es hätte aber auch wieder den Nachteil, alle bisher erlangten Erfahrungen sind für die Katz und es beginnt das erneute Versuch und Scheitern! Würde das nicht immer Filament kosten und vor allem auch immer ein paar Stunden Druck bedeuten, wäre das tatsächlich eine Möglichkeit. Oder wenn ich eine Möglichkeit hätte, einen Fehldruck zu schmelzen und wieder zu verwenden. Habe ich aber leider auch nicht. Will ich zwar bauen, aber so weit bin ich noch lange nicht!

Einfach weiterentwickeln?

Das wäre wohl die Variante mit der grössten Logik! Ich nehme einfach meine Erfahrungen und während ich das Original neu in Blender aufbaue, lasse ich gleich neue Ideen mit einfliessen. Ja, so klingt das doch sehr gut!

Neu in V 3.0

Ich nehme also alles, was ich an der verloren gegangenen Version gut fand und baue das ein, was ich als sinnvoll erachte. Das kommt dabei heraus:

Deutlich zu sehen ist, die ganze Sache ist kompakter geworden. Die Führung für die Riemen sitzt nun nicht mehr Rechts und links, sondern direkt Vorne und Hinten. Dadurch erhoffe ich, mit einem einzigen Riemen auskommen zu können und auch andere Varianten, als nur Klettband verwenden zu können.

Allerdings gehen damit die Erweiterungsmöglichkeiten verloren! Nicht ganz, denn es gibt genug Aussparungen, in die ich noch was einbauen kann, aber so, wie es bislang realisiert wurde, geht es jetzt nicht mehr. Schlimm ist das aber nur bedingt, denn was ich bislang an Erweiterungen erdacht habe, wird sich auch so realisieren lassen.

Gebaut ist es schon, jetzt muss es nur gedruckt und getestet werden. Ich bin schon sehr gespannt, wie es sich schlägt!

So sieht das dann beim Druck aus

Cinnamon auf Deutsch unter Arch

Also, ich muss ja doch mal zugeben, Arch-Linux hat bei mir viel an “Zuneigung” gewonnen. Es gibt zwar ein paar Punkte, da ist mir Gentoo deutlich lieber, aber im Allgemeinen ist Arch echt super!

Mittlerweile läuft es nativ auf meinem NetBook, dem Rechner meiner Frau und meinem neuen Laptop für die Arbeit, der mir freundlicherweiser von meinem Kollegen zur Verfügung gestellt wurde. Der eigentliche Vorteil an Arch ist, Installation und Updates dauern nur einen Bruchteil der Zeit, wie Gentoo sie verlangt.

Aber gut, darum geht es ja jetzt nicht. Mittlerweile hat sich ja Cinnamon auf meinen Rechnern als Desktop durchgesetzt. Das hat einige Gründe, wobei keiner davon stichhaltig genug ist, um ihn zu nennen. Ich wollte eben einfach mal wieder etwas neues. So. Wie man das installiert, habe ich ja im Artikel »Bis zur grafischen Benutzeroberfläche« beschrieben.

Es gibt da aber so ein Punkt, den ich nicht ganz verstanden habe und der mich schon ein bisschen aufgeregt hat. Cinnamon blieb unter Arch stur auf englisch! Das ist im Allgemeinen kein Problem, da ich es trotzdem verstehe, aber wenn ich schon ein DE einsetze, der so viel Ballast mitbringt, dann soll der doch auch bitte auf deutsch sein. Denn, unter Gentoo ist er sofort auf deutsch!

Aber was tun, wenn da keine Einstellmöglichkeiten für sind? Ich habe gesucht und gesucht, den Fehler auch in der generellen Lokalisierung des Systems vermutet doch nein. Nichts von dem war es. Es war eigentlich viel einfacher!

Gibt man folgendes im Terminal ein

sudo pacman -S cinnamon-translations

dann wird das Paket installiert und sofort danach, ohne irgendetwas neustarten zu müssen, ist Cinnamon auf deutsch. Das war echt nicht schwer und erklärt auch, warum es bei Gentoo sofort dabei war. Unter Gentoo wird das Paket über die Einstellungen vom System gleich mitinstalliert. Peng, fertig!

So einfach kann es gehen. Bei meiner Frau ist es jetzt auch auf deutsch und die ist auch Happy. Manchmal sind die Lösungen so einfach! Aber wenn man es anders gewohnt ist, werden auch Banalitäten gerne mal zum Geduldsspiel!

Birth of the Federation

Vorwort:

Dieser Ratgeber ist sowohl für Windows, für Linux mit wine oder PlayOnLinux und Mac mit PlayOnMac gedacht. Solange kein spezifisches System genannt wird gelten die Schritt für alle Systeme. Schritte, welche unter Linux auszuführen sind, richten sich allgemein an Linux und nicht an eine bestimmte Distribution!

Achtung! In dieser Anleitung wird die englische Variante von PlayOnLinux und PlayOnMac beschrieben. Die Schritte sind die Gleichen, jedoch muss in der deutschen Version die entsprechenden deutschen Punkte gewählt werden!


Video:

Zu diesem Artikel existiert auch ein Video! Um es zu sehen, hier klicken!


Installation:

Der Einfachste und derzeit wohl beste Weg um Birth of the Federation zu installieren führt über die Datei:

botf_1.0.2_english_german_e.exe

(die müsst ihr jedoch leider selbst suchen)

Erste Variante unter Windows und Linux mit wine:

  • Einfach die heruntergeladene Datei ausführen,
  • den Anweisungen folgen
  • fertig.

Zweite Variante mit PlayOnLinux oder PlayOnMac

  • Herunterladen und installieren von PlayOnLinux oder PlayOnMac
  • In PlayOnLinux oder PlayOnMac:
    • Auf install klicken
    • Im neuen Fenster am unteren, linken Rand auf Install a non-listed program drücken
    • Es kann sein, dass erst zwei Fenster auf gehen mit Read this oder ähnliches. Beide mit Next bestätigen
    • Install a program in a new virtual drive auswählen und Next drücken
    • Name der virtual drive eingeben (z.B. Botf) und Next klicken
    • Auswahl Install some libraries aktivieren und auf Next klicken
    • 32 bits windows installation auswählen und Next klicken (unter Umständen erscheint diese Auswahl nicht in PlayOnMac)
    • In der Auswahl POL_Install_directplay auswählen und Next klicken (der Name kann abweichen! Hauptsache directplay)
    • Heruntergeladene Botf Installationsdatei auswählen und Next klicken
    • Das Spiel mit dem eigentlichen installer installieren
    • Im nächsten Fenster wird die Auswahl eines Shortcut angeboten. Dort trek.exe auswählen und Next drücken
    • Nun kann man einen alternativen Namen angeben, oder einfach Next drücken
    • Es öffnet sich wieder die Auswahl eines Shortcuts. Das ist kein Fehler! Wenn man z.B. noch unins000.exe als Shortcut haben möchte, um zu deinstallieren, einfach die letzten beiden Schritte wiederholen.

      Wenn nicht, oder wenn alle erwünschten Shortcuts gesetzt sind I don’t want to make another shurtcut auswählen und Next klicken
    • Fertig!

Multiplayer:

Um das Spiel auch in einer Mehrspieler-Partie spielen zu können ist es ratsam ein VPN, also ein Virtuelles-Privates-Netzwerk zu benutzen. Hier empfiehlt sich zum Beispiel:

LogmeIn Hamachi

Aber auch alle anderen Möglichkeiten, ein solches VPN zu betreiben, sollten funktionieren. Zum Beispiel direkt über die FritzBox, um nur eine Alternative zu nennen.

Für die Möglichkeit, auch unter Linux mit wine eine Mehrspieler-Partie zu spielen sind noch ein paar Schritte notwendig:

Zuerst sollte winetricks installiert werden.

Über winetricks wird nun directplay im Terminal installiert:

winetricks directplay

Anschliessend müssen folgende DLL mittels winecfg eingebunden werden:

dplayx

dpnet

dpnhpast

dpwsockx

iccvid

Wenn Alles soweit geklappt hat sollte das Spiel nun auch unter wine im Multiplayer funktionieren!


Nützliches

  • Birth of the Federation in einem Fenster spielen (funktioniert nicht unter Windows, PlayOnLinux oder PlayOnWine!):

    Startet Birth of the Federation über den Terminal. Geht dazu in das entsprechende Verzeichnis und gebt folgendes ein:

    WINEDEBUG=-all wine explorer /desktop=Botf,800×600 ./trek.exe

    Für den 1366×786 Patch:

    Startet Birth of the Federation über den Terminal. Geht dazu in das entsprechende Verzeichnis und gebt folgendes ein:

    WINEDEBUG=-all wine explorer /desktop=Botf,1366×768 ./trek.exe

WSC ist in Arbeit

Ach ja, schon wieder ein neues Projekt. Wobei es nicht ganz richtig ist. Genau genommen ist es noch das Projekt Horizont unter einem neuen Namen. Im Prinzip kann ich daraus auch Horizont später ableiten, mit wahrscheinlich nur wenigen Änderungen. Es ist also auch ein kleines, soziales Netzwerk, doch mit dem Ziel, die Leute aus meinem Wifesharing-Blog besser zu vernetzen.

Um was geht es?

Ziel des Ganzen soll ein soziales Netzwerk werden, welches, anders als bislang üblich, komplett auf einen Browser verzichtet. Mit ein Problem dabei wird natürlich sein, es muss für möglichst alle Plattformen verfügbar sein. Also Linux (klar, damit wird es entwickelt), Windows, Android, aber auch MacOS und iOS, oder heissen die jetzt beide iOS?

Im Fokus liegt derzeit Linux und Windows. Beides 64-Bit natürlich. Dann soll es zu Android gehen und was Apple angeht, da ich keine Hardware und auch kein PC mit diesem OS habe, wird das natürlich schwieriger. Abwarten!

Natürlich ist das ganze kostenlos und Daten werden auch keine Verkauft. Wüsste zum Einen nicht an wen, zum Anderen wage ich es zu bezweifeln, dass da genug Informationen bei rumkommen, als dass die wirklich von Bedeutung wären. Also in der Hinsicht ist in diesem Netz nichts zu befürchten.

Darüber hinaus versuche ich auch alles möglichst so zu regeln, dass es auch mit den kommenden Urheberrechtsgesetzen in Einklang steht.

Ausserdem, was eigentlich mehr durch Zufall entstanden ist, WSC wird Templates unterstützen! Das heisst, wer sich berufen fühlt, kann der Software ein eigenes Aussehen verpassen und dieses dann auch veröffentlichen, damit auch andere Nutzer etwas davon haben.

Was soll WSC bieten?

Bieten soll WSC die Kommunikation für Gleichgesinnte. Also jene, die sich mit dem Thema auseinandersetzen.

Dabei gibt es drei grundlegende Funktionen:

  • Notizblock
  • Gruppen / Gruppenchat
  • Privater Chat

Der Notizblock

Der Notizblock soll das Äquivalent des Streams werden. Dort werden die neusten Beiträge von den Leuten der Freundesliste angezeigt und man kann eigene verfassen. Kommentare abgeben, liken und was eben dazugehört.

Gruppen und Gruppenchat

Wichtig in einer solchen Community sind natürlich Gruppen. Nach Plan sollen die von den Benutzern selbst erstellt und gepflegt werden können. Bestandteile jeder Gruppe sind zu Beginn natürlich der Notizblock und Chat der Gruppe. In späteren Versionen kann es natürlich auch noch erweitert werden. Je nach Bedarf.

Ich will aber sofort anmerken, Gruppen werden NICHT verschlüsselt! Das mag jetzt kontraproduktiv wirken, aber ich habe keinen Bedarf, irgendwelche illegalen Aktivitäten zu unterstützen, was eine verschlüsselte Gruppe in einem wenig, oder fast unbekannten Netzwerk natürlich unterstützen würde. Von daher, Gruppen können bei Bedarf eingesehen werden!

Privater Chat

Ein privater Chat bedeutet eine Kommunikation zwischen zwei Personen. Dieser Chat wird definitiv verschlüsselt! Eingesetzt wird dabei OpenSSL mit asymmetrischer Verschlüsselung (4096 Bit).

Hier dürfte auch einer der grössten Unterschiede zu anderen sozialen Netzwerken liegen. Diese verwenden in aller Regel ja den Browser als Oberfläche. Das heisst, niemand kann mit Sicherheit sagen, wer die Nachrichten dort schon abfangen kann, bevor sie verschickt, oder verschlüsselt werden. Beim WSC wird das anders. Da werden alle Nachrichten auf dem lokalen Rechner verschlüsselt und erst dann an den Server übertragen (End – End Verschlüsselung)! Im Umkehrschluss werden die Nachrichten erst auf den lokalen Computer geladen und dann erst entschlüsselt. Der Klartext ist also definitiv nur beim Sender und Empfänger zu sehen!

Um das realisieren zu können, generiert WSC bei der Registrierung automatisch ein Schlüsselpaar und speichert den öffentlichen Schlüssel auf dem Server. Der Private bleibt immer auf dem lokalen Rechner und wird NIE übertragen!

Was bietet WSC (noch) nicht?

Man sollte bedenken, ich entwickle diese Software alleine und auch ehrenamtlich. Das da nicht von Anfang an ein Funktionsumfang dabei ist, wie man ihn aus etablierten Systemen her kennt, dürfte klar sein. Deshalb sollte es auch nicht verwunderlich sein, wenn dieses soziale Netzwerk am Anfang etwas rudimentär daherkommt. Hoffentlich schreckt das nicht zu viele Leute ab. Die Zeit wird es zeigen.

Was definitiv noch nicht in Version 1 zu finden sein wird, sind Emojis und die Möglichkeit Bilder zu übertragen. Das liegt jedoch nicht an meiner Unfähigkeit, sondern viel mehr daran, erst einmal eine stabile Plattform zu schaffen! Das heisst, sowohl das Versenden von Bildern, wie auch die Nutzung von Emojis ist definitiv auf der Liste! Das wird also kommen, insofern das System keine Totgeburt wird!

Was noch alles fehlen wird, wird sich noch zeigen. Aber ich sage es jetzt schon. Findet das System Anklang, werde ich es auch weiterentwickeln und auf Wünsche der Nutzer eingehen!

Das benötigt WSC

Nicht sonderlich viel und nichts davon kostet Geld. Insofern man einen Computer mit Linux, oder Windows sein Eigen nennt.

Abhängig wird WSC, zumindest aus aktueller Sicht, nur von zwei Komponenten sein.

  • Qt
  • OpenSSL
  • Sodium

Also, alles locker, alles kostenlos.

Stand der Dinge

Das mag ja alles gut klingen und sich nach einer super Vision anhören. Davon gibt es aber schon genug. Um zu zeigen, dass es sich dabei nicht um ein Hirngespinst handelt, hier der aktuelle Stand der Version 0.1:

Linux-Version
Windows-Version

Kann zwar noch nichts, aber wie man sieht, es existiert bereits! Ist vielleicht nicht das schönste Design, wie aber schon weiter oben angemerkt, dass Design kann geändert werden.

Bildbetrachter in C/C++ und QT

Kürzlich habe ich mit der Nutzung von QT als grafische Benutzeroberfläche begonnen. Eigentlich wundert es mich, dass ich darum immer so einen grossen Bogen gemacht habe, denn eigentlich tut es genau das, was ich von einem solchen ToolKit verlange! Wahrscheinlich liegt es daran, dass ich aus irgendeinem Grund der Meinung war, QT-Oberflächen müsste man mit dem QT–Creator bauen. Aber egal.

Nun bliebe natürlich die Frage, warum mache ich das? Das Netz ist voll solcher Beschreibungen. Das ist eigentlich ganz einfach. Ich habe es bei Nana gesehen. Das habe ich in letzter Zeit zum erstellen grafischer Benutzeroberflächen eingesetzt und war soweit auch ganz zufrieden damit. Aber da war immer mal wieder das Problem, habe ich eine Zeit nicht damit gearbeitet, ging mir viel verloren und ich durfte wieder nachschauen. Jetzt, bei QT, notiere ich eben alles hier und wer weiss, vielleicht helfe ich damit ja jemandem.

Es sollte klar sein, dass man QT installiert haben muss, damit es funktioniert. Wie man das bei der jeweiligen Distribution macht, oder unter Windows, müsst ihr selbst herausfinden. Ja, Windows sollte auch funktionieren. Habe ich noch nicht versucht, aber werde ich in diesem Projekt hier machen!

Ziel dieses Artikels

Am Ende dieses Artikels soll es möglich sein, dass Programm, welches ich dubb nennen werde (diabolus Umarov Bildbetrachter) , in der Eingabeaufforderung mit einem Parameter zu starten. Der Parameter soll, wer hätte es gedacht, die Bilddatei angeben. Natürlich soll diese dann angezeigt werden.

Der Beginn von dubb

Ich verwende als IDE Visual Studio Code. Ja, ein Microsoft-Produkt. Damit bestätige ich auch, was ich gerne behaupte. Ich bin durchaus dazu in der Lage, Produkte dieser Firma zu nutzen, wenn sie mir gefallen! Dazu verwende ich auch noch cmake und clang.

Zuerst brauche ich ein Verzeichnis, indem ich arbeiten kann. Das nenne ich einfach dubb und öffne es in VCode.

Als nächstes muss ich das Projekt anlegen. Das ist recht simpel mit shift+strg+p. Oben öffnet sich ein Drop-Down-Menü und da wähle ich CMake: Quick Start aus. Im Anschluss dann Clang 8.0.0 …, gebe dubb als Projekt-Name ein und wähle schliesslich Executable aus. Schon wird das Projekt erstellt und die Datei CMakeLists.txt geöffnet, in der folgendes drinsteht:

cmake_minimum_required(VERSION 3.0.0)
project(dubb VERSION 0.1.0)

include(CTest)
enable_testing()

add_executable(dubb main.cpp)

set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
include(CPack)

Ausserdem wird noch die Datei main.cpp erstellt. Ich teste einfach mal, ob alles funktioniert hat und ändere dafür diese Datei etwas ab. Einfach so, dass das berühmte Hallo Welt! erscheint. Das sieht dann so aus:

#include <iostream>

using namespace std;

int main(int argc, char* argv[]) 
{
    cout << "Hallo Welt!" << endl;
}

Im Prinzip hätte ich die Vorgabe so lassen können, denn die hat genau das gemacht. Doch ich bin da eigen! Egal, den Krempel compiliere ich jetzt und dann schaue ich, ob es auch brach funktioniert hat!

$ ./dubb 
Hallo Welt!

Hervorragend. Klappt ja soweit alles!

Klappt das aber auch mit dem Parameter?

argv[0] wäre der Name des Programms. Das heisst, ich schaue mal was argv[1] zurückgibt.

#include <iostream>

using namespace std;

int main(int argc, char* argv[]) 
{
    cout << argv[1] << endl;
}

Und das Ergebnis ist:

$ ./dubb hallo
hallo

Perfekt!

Nun ran an QT

Ich will aber eine grafische Oberfläche haben und dafür will ich QT einsetzen. Da ich es echt nicht schön finde, wenn ich alles in einer Datei hängen habe und ich auch nicht weiss, wie gross diese Geschichte überhaupt wird, fange ich mal an weitere Dateien zu erstellen und diese dann mit entsprechendem Code zu füllen.

Zuerst einmal die Datei windows.h. Da kommen alle Klassen und so rein.

#include <QMainWindow>

class HauptWindow : public QMainWindow
{
    Q_OBJECT

    public:
        HauptWindow();

    private slots:

    private:
};

Als Grundgerüst funktioniert das. Aber, so wird der Compiler ganz laut schreien! Denn, da muss noch was in der CMakeLists.txt eingetragen werden, die dann so aussieht:

cmake_minimum_required(VERSION 3.0.0)
project(dubb VERSION 0.1.0)

find_package(Qt5 COMPONENTS Widgets REQUIRED)
find_package(Qt5Core REQUIRED)

include(CTest)
enable_testing()

add_executable(dubb main.cpp)

set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
include(CPack)

target_link_libraries(dubb Qt5::Widgets)

Und schon klappts auch mit dem Nachbarn! Aber, so bringt das alles überhaupt nichts! Das Fenster muss noch geöffnet und gefüllt werden usw. Also erst einmal das Fenster!

Das könnte ich nun alles in die windows.h Datei schreiben, was bei diesem Programm wohl auch kein Problem wäre. Ich bevorzuge es jedoch anders und erstelle dafür wieder eine neue Datei mit dem Namen hauptwindow.h. Da kommen dann die Funktionen rein, die das Fenster betreffen und natürlich muss das auch alles noch eingebunden werden.

Für den Anfang reicht es mir, wenn sich das Fenster öffnet und ich es auch wieder schliessen kann. Da ich noch nicht genau weiss, in welche Richtung sich das Projekt entwickeln wird, werde ich die Funktion zum schliessen mit QAction definierten. Das muss natürlich zuerst in der Klasse auch definiert werden und das sieht dann so aus in der windows.h:

#include <QMainWindow>
#include <QAction>

class HauptWindow : public QMainWindow
{
    Q_OBJECT

    public:
        HauptWindow();

    private slots:
        void beenden();

    private:
        QAction *beendenAction;
};

Die Datei hauptwindow.h sieht dann so aus und tut nichts anderes, als dem Fenster die Möglichkeit einzuräumen, auch wieder geschlossen werden zu zu können.

HauptWindow::HauptWindow()
{
    beendenAction = new QAction(tr("&Beenden"));

    connect(beendenAction, SIGNAL (triggered()), this, SLOT (beenden()));   
}

void HauptWindow::beenden()
{
    qApp->quit();
}

Okay. Also muss nur noch etwas her, um das Fenster auch nach dem Programmstart zu zeigen! Das kommt in main.cpp.

#include <iostream>
#include <QApplication>

#include "windows.h"

using namespace std;

#include "hauptwindow.h"

int main(int argc, char* argv[]) 
{
    QApplication app(argc, argv);

    HauptWindow hw;

    hw.show();

    return app.exec();
}

Ausserdem muss ich die Datei CMakeLists.txt anpassen und die sieht dann so aus:

cmake_minimum_required(VERSION 3.0.0)
project(dubb VERSION 0.1.0)

set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_AUTOUIC ON)

find_package(Qt5 COMPONENTS Widgets REQUIRED)
find_package(Qt5Core REQUIRED)

include(CTest)
enable_testing()

add_executable(dubb main.cpp windows.h hauptwindow.h)

set(CPACK_PROJECT_NAME ${PROJECT_NAME})
set(CPACK_PROJECT_VERSION ${PROJECT_VERSION})
include(CPack)

target_link_libraries(dubb Qt5::Widgets)

So. Los Compiler, mach deine Arbeit! Hat das alles funktioniert, kommt folgendes bei raus:

Alles richtig gemacht, in nur ganz wenigen Schritten. QT gefällt mir! Erinnert mich in gewisser Hinsicht an MUI auf dem AmigaOS! Ausserdem, wie ein Test zeigt, schliesst sich das Fenster auch brav wieder, wenn man das X im Titel anklickt.

Das mit dem Bild

Nun gut. So toll das Fenster ja sein mag, es nutzt mir überhaupt nichts! Das dumme Ding soll schliesslich ein vorher ausgewähltes Bild zeigen!

Im Prinzip könnte ich jetzt einfach den Wert von argv[1] nehmen, damit das Bild laden und anzeigen lassen. Aber eben, ich habe noch keine Ahnung, wie weit dieses Projekt noch anwachsen wird und deshalb will ich vorbereitet sein. Im Prinzip heisst das nichts anderes, als dass ich eine Klasse für das anzuzeigende Bild anlege. Die ist super banal und speichert nur den Pfad und den Dateiname. Aber wer weiss, wo das noch hinführt, da bin ich lieber vorbereitet.

Also mal wieder eine neue Datei und die bekommt den überaus gelungenen Namen bild.h.

class Bild
{
    private:
        string file;

    public:

        void setFile(char *f)
        {
            file = f;
        }

        QString getFile()
        {
            return QString::fromStdString(file);
        }
};

Jede Wette, man kann es auch viel besser machen, aber ich mache es eben so weil ich weiss, dass es funktioniert!

Jetzt muss ich noch main.cpp anpassen, dass argv[1] in die Klasse gespeichert wird. Ach ja, natürlich muss ich ja auch noch auf die Klasse zugreifen können und zwar auch aus den anderen Dateien heraus. Dann sieht das so aus:

#include <iostream>
#include <QApplication>

#include "windows.h"

using namespace std;

#include "bild.h"

Bild bild;

#include "hauptwindow.h"

int main(int argc, char* argv[]) 
{
    bild.setFile(argv[1]);

    QApplication app(argc, argv);

    HauptWindow hw;

    hw.show();

    return app.exec();
}

Das nützt aber auch noch nichts, denn nur weil ich jetzt eine Datei als Variable in einer Klasse speichern und wieder abrufen kann, wird hier noch gar nichts angezeigt. Also, irgendwas muss ich auch damit machen können!

Dafür bauche ich ein paar Dinge. Zum Einen muss das Bild ja irgendwie geladen auch noch irgendwie im Fenster angezeigt werden. Also, ran ans Werk!

Zum Anzeigen verwende ich einfach ein QLabel. Ist es die beste Variante? Keine Ahnung, aber egal. Dafür ändere ich dann natürlich wieder windows.h sowie hauptwindow.h. In dieser Reihenfolge.

#include <QMainWindow>
#include <QAction>
#include <QLabel>
#include <QPixmap>

class HauptWindow : public QMainWindow
{
    Q_OBJECT

    public:
        HauptWindow();

    private slots:
        void beenden();

    private:
        QAction *beendenAction;

        QLabel *bildLabel;

        QPixmap bildPixmap;
};

und

HauptWindow::HauptWindow()
{
    bildLabel = new QLabel();

    bildPixmap.load(bild.getFile());

    bildLabel->setPixmap(bildPixmap);

    beendenAction = new QAction(tr("&Beenden"));

    connect(beendenAction, SIGNAL (triggered()), this, SLOT (beenden()));   

    setCentralWidget(bildLabel);
}

void HauptWindow::beenden()
{
    qApp->quit();
}

Lasset uns schauen, ob die Nummer auch funktioniert!

Ja da schau an, es hat funktioniert! Zumindest zum Teil. Ja, das Bild wird angezeigt. Aber, es ändert die Grösse mit demFenster. Im Prinzip ist das ja nicht schlimm, aber was wenn man ein Bild hat, was grösser ist als die Auflösung? Oder wenn man das Fenster skaliert? Also da muss noch was dran!

Ich könnte es mir nun einfach machen und das Label einfach so einstellen, dass es seinen Inhalt bei Grössenveränderungen skaliert. Dazu müsste ich nur folgendes in der hauptwindow.h einbauen:

bildLabel->setScaledContents(true);

Das wäre aber nicht das Gelbe vom Ei, denn dann würde sich das Bild unter Umständen verziehen. Es soll aber sein Verhältnis beibehalten! Das heisst also mehr Arbeit! Zum Einen muss ich ein Event einbauen, welches auf eine Veränderung der Grösse reagiert. Dort muss ich dann die Grösse des Bildes ermitteln, es unter Beibehaltung seines Verhältnisses skalieren und damit erst die Grösse von bildLabel anpassen. Ausserdem soll ja auch alles schön mittig angezeigt werden, weshalb ich bildLabel auch noch in ein QHBoxLayout packe. Das bedeutet Änderungen in windows.h und natürlich auch in haupwindow.h. Das sieht dann so aus:

#include <QMainWindow>
#include <QAction>
#include <QLabel>
#include <QPainter>
#include <QPixmap>
#include <QHBoxLayout>

class HauptWindow : public QMainWindow
{
    Q_OBJECT

    public:
        HauptWindow();
        void resizeEvent(QResizeEvent* event);

    private slots:
        void beenden();

    private:
        QAction *beendenAction;

        QHBoxLayout *mainBox;
        
        QLabel *bildLabel;

        QPainter *bildPainter;

        QPixmap bildPixmap;
};
HauptWindow::HauptWindow()
{
    mainBox = new QHBoxLayout();
    QWidget *mainLayout = new QWidget();

    bildPixmap.load(bild.getFile());

    bildLabel = new QLabel();

    bildPainter = new QPainter(bildLabel);

    bildLabel->setPixmap(bildPixmap);
    bildLabel->setScaledContents(true);
    bildLabel->setAlignment(Qt::AlignCenter);

    beendenAction = new QAction(tr("&Beenden"));

    connect(beendenAction, SIGNAL (triggered()), this, SLOT (beenden()));   

    mainBox->addWidget(bildLabel);
    mainBox->setAlignment(Qt::AlignCenter);

    mainLayout->setLayout(mainBox);

    setCentralWidget(mainLayout);
}

void HauptWindow::beenden()
{
    qApp->quit();
}

void HauptWindow::resizeEvent(QResizeEvent* event)        
{
    QSize ls = bildLabel->size();
    QSize bs;

    QPixmap neuPixmap = bildPixmap.scaled(ls, Qt::KeepAspectRatio);

    bs = neuPixmap.size();

    bildLabel->resize(bs);
}

War das erfolgreich? Das wird ein Test zeigen!

Das nenne ich dann jetzt einfach mal Erfolg! Nicht ganz perfekt, da das Bild in einigen Fenstern durchaus auch grösser sein könnte, aber für den Anfang reicht es und ich behaupte einfach mal, damit ist das Ziel dieses Artikels auch erreicht.

Aber damit ist die Sache noch nicht beendet. Weitere Teile werden folgen!

BlunsenLabs auf dem Yakumo

Der Artikel wird nicht lang, deshalb auch kein Inhaltsverzeichnis. Tatsächlich tippe ich ihn gerade auf meinem Yakumo Laptop der tatsächlich nur einen Celeron M Prozessor mit 1.300 MHz verwendet! Trotzdem muss ich sagen, es geht eigentlich wirklich gut! Ich tippe und die Buchstaben sind tatsächlich sofort zusehen! Da kann ich überhaupt nicht meckern!

Krass finde ich auch, der Laptop hat laut Conky 490 MB Arbeitsspeicher. Also nach heutigen Verhältnisen mehr als wenig. Dennoch läuft gerade Chromium und ich habe gerade einmal 250 MB davon in Gebrauch. Schon eine Marke!

Ich muss aber auch sagen, die Leistung ist jetzt nicht besser als unter Gentoo. Aber eben auch nicht schlechter. Die Installation hat keine Stunde gedauert und im Anschluss lief die Kiste sofort! Auch ein komplettes Systemupdate dauerte nur Minuten. Unter Gentoo mehrere Stunden!

BunsenLabs wird wohl nie Gentoo für mich ersetzen und den Sprung auf mein eigentliches Arbeitsgerät schaffen. Aber ich spiele mit dem Gedanken, BL auch auf meinem NetBook einzusetzen! Dort bin ich zwar mit der Arbeitsleistung zufrieden, aber die Updates dauern einfach ewig!

Was mir bei der Installation aufgefallen ist, zum Einen es gibt nur eine Text-Basierte Installation. Die ist aber das Gleiche wie die mit grafischer Oberfläche, da gibt es also keine Probleme. Dazu wollte die Installation wissen, ob ich mittels Kabel, oder W-Lan verbunden werden will. Ich habe mal spasseshalber W-Lan ausgewählt und siehe da, die Verbindung funktionierte einwandfrei! Dickes Plus!

So. Das reicht erst einmal für den Augenblick. Ich bin definitiv begeistert von BunsenLabs und kann nur sagen, ältere Rechner laufen damit noch ziemlich gut! Wie gesagt, hier jetzt den Artikel tippen ist absolut kein Problem!

BunsenLabs installieren

Huch? Schon wieder eine neue Linux-Distribution? Ich habe doch erst mit Arch angefangen?

Das ist richtig. Habe ich und an meinen Plänen ändert sich auch nichts. Doch wurde ich, aufgrund meiner Arch-Artikel, über MeWe auf BunsenLabs aufmerksam gemacht. Was mich daran besonders aufhorchen liess war die Tatsache, dass BunsenLabs wirklich ein Leichtgewicht sein soll. Ein OS, was 10GB Festplatte und 1 GB Arbeitsspeicher (empfohlen, nicht die minimale Voraussetzung!) haben will, scheint mir für alte Geräte natürlich überaus nützlich. Ich habe zum Beispiel zwei Laptops im Einsatz, die schon in der Steinzeit alt waren. Ein Vaio mit Pentium-M Prozessor, sowie auch ein Yakumo mit ebenfalls sehr wenig Power (aus heutiger Sicht. Irgendwann waren die Dinger mal echt heiss!).

Da läuft aktuell Gentoo drauf und tut hervorragend seinen Dienst. Allgemein nutze ich die Teile, um von unterwegs aus auf meinen Desktop zuzugreifen. Habe ich ja in einem anderen Artikel schon beschrieben. Aber eben, manchmal fordere ich sie auch persönlich. Meistens dann wenn ich unterwegs bin, schwaches Internet habe und ohnehin nichts arbeite, was viel Leistung benötigt. Blender würde ich darauf allerdings jetzt nicht verwenden.

Gentoo hat da allerdings ein mächtiges Problem! Will ich das System updaten, oder etwas installieren, dauert das Stunden. Kommt ein Webkit, oder llvm dazu, auch gerne mal Tage. Das nervt!

Hier käme nun, insofern es mich überzeugen kann, vielleicht BunsenLabs ins Spiel. Die Rechner bieten die Ressourcen, die dafür benötigt werden locker. Genau aus dem Grund schaue ich es mir mal ganz genau an. Erst in qemu, um Erfahrung damit zu sammeln, dann geht es ab auf einen Laptop. Vielleicht auch auf einen Raspberry Pi? Ich weiss es noch nicht. Aber theoretisch könnte ich mir durchaus den Einsatz auf meinem Bordcomputer fürs Auto vorstellen! Abwarten.

Vorbereitung

Zuerst einmal den Ordner anlegen, die Festplatte erstellen und ein ISO laden. Das ist ja nicht besonders schwer.

mkdir bunsen
cd bunsen

Damit hätten wir das Verzeichnis. Jetzt die Festplatte. 10 GB werden empfohlen, also kriegt BunsenLabs das auch!

qemu-img create -f qcow2 bunsen.img 10G

Auch geschafft. Jetzt noch ein ISO, was ebenfalls in das Verzeichnis kommt. Ich verwende helium-5-amd64.hybrid.iso.

wget https://ddl.bunsenlabs.org/ddl/helium-5-amd64.hybrid.iso

Wer ein anderes Installationsmedium haben möchte, die gibt es hier.

Doch was ist das? 1,1 GB für ein Installationsmedium? Das von Gentoo ist keine 200 MB gross! Das kann eigentlich nur eins bedeuten. Man bekommt bei der Installation schon jede Menge Zeug auf die Platte geschaufelt. Mal schauen, was das sein wird.

Gestartet wird das Ganze natürlich wieder mit einem kleinen Skript:

qemu-system-x86_64 -m 1024 -enable-kvm -smp 1 -net nic -net user -vga virtio -display vnc=:6 -cdrom helium-5-amd64.hybrid.iso -boot c -hda bunsen.img -device virtio-serial

Wie man sieht ist es etwas anders, als jenes von Arch.

  • -m 1024
  • -smp 1

Das heisst, BunsenLabs bekommt nur 1 GB Arbeitsspeicher und nur einen Prozessor! Angeblich reicht das ja, ich bin gespannt!

Installation

Nach dem kurzen Bootvorgang sieht das so aus.

Da ich ja nichts ausprobieren will, gehe ich sofort zu Install und lege los.

Simple, grafische Benutzeroberfläche. Sieht doch ganz gut aus. Natürlich will ich die deutsche Sprache haben und wähle sie entsprechend aus.

Schön zu sehen, dass danach auch gleich alles auf deutsch erscheint. So mag ich das. Wo befinde ich mich? Natürlich Deutschland. Also einfach weiter.

Da ich es bevorzuge, wenn z auf der Z-Taste erscheint, will ich natürlich ein deutsches Tastatur-Layout. Also wieder weiter.

Es werden die Komponenten geladen. Wundert mich jetzt irgendwie nicht.

Dann geht es weiter. Wer hätte es erwartet?

Wie ich es immer unter qemu mache, bekommt der Rechner den Namen des OS. In dem Fall einfach bunsen.

Aha. Ein Domain-Name soll es sein. Da unter qemu aber immer ein eigenes Netzwerk eingerichtet wird, kann ich darauf verzichten. Einfach weiter.

Und will der Installer den vollständigen Namen des Benutzers haben. Also eintippen und weiter. Normalerweise kann man hier jeden möglichen Quatsch eingeben, wenn man den echten Namen nicht angeben will. Es sollte das System nicht beeinträchtigen!

Jetzt auch noch der Benutzername. Bei mir ist das diabolus, wie immer.

Da ein Passwort auch logisch ist, kommt das da rein. Zweimal, wie man es eigentlich gewohnt ist. Dann weiter.

Nun geht es an die Festplatte. Ich will die vollständige Festplatte verwenden und verzichte auf LVM. Als einfach weiter.

Da die Auswahl ziemlich mager ist, einfach weiter.

Das finde ich jetzt aber mal sehr nett! Man kann alles in eine Partition drücken, oder für /home usw. eigene Partitionen anlegen. Gefällt mir! Dennoch, zum testen kommt alles in eine Partition. Also weiter.

Noch schnell eine Zusammenfassung, man bekommt die Möglichkeit daran Änderungen vorzunehmen, da ich das aber nicht will, einfach weiter.

Dieser Schritt kommt mir ein wenig übertrieben vor. Ich habe doch schon bestätigt, dass alles in Ordnung ist. Jetzt soll ich es erneut bestätigen? Na, von mir aus. Also Ja und weiter.

Anscheinend bin ich fertig und das System wird installiert. So überflüssig ich den letzten Schritt fand, so sehr vermisse ich hier einen. Die Möglichkeit auszuwählen, welche Software ich gerne installieren würde. Ungeübte Benutzer sollten in dem Fall die Möglichkeit haben, einfach einen Standard zu nehmen, während geübte Benutzer die Möglichkeit haben sollten, zu bestimmen was installiert wird.

Wieso habe ich so das Gefühl, dass ich nach der Installation erst einmal aufräumen darf?

Ja, Grub möchte ich natürlich haben. Also, weiter.

Warum bei diesem Schritt die erste Option als Standard gewählt wurde, ist mir jetzt nicht ganz klar. Ich will natürlich /dev/sda haben. Also auswählen und weiter.

Gut. Soll er mal machen!

Okay, Fertig. Dann mal weiter und schauen was passiert.

Erster Eindruck

Ja schau sich einer das an! Hat alles super geklappt und war echt wirklich sehr einfach. Also ganz ehrlich, besser macht es Mint auch nicht. Windows schon gar nicht! Bis hier hin bin ich ja schon sehr zufrieden!

Okay. Nach Eingabe des Passworts dauert es dann aber doch ziemlich lange, bis die grafische Benutzeroberfläche erscheint. Ich behaupte jetzt einfach mal, da werden im Hintergrund verschiedene Dinge eingerichtet und deshalb dauert das seine Zeit. Mal den nächsten Boot-Vorgang abwarten, bevor ich da wirklich meckere.

Aber siehe da, hier ist BunsenLabs. Netterweise hat man, auch wenn ja alles auf deutsch eingestellt ist, doch ein englisches Welcome. Soll mich aber nicht stören, hab ich mir eh noch nie durchgelesen.

Doch was haben wir denn hier? Das ist doch nett! Man kann sofort sehen, wie das System belastet ist!

Nun muss man sich mal vorstellen. Das ganze Ding ist ja anscheinend betriebsbereit. Die grafische Benutzeroberfläche läuft ebenfalls und was sieht man? 193 MB RAM werden benutzt? Alles belegt 2,72 GB Platz auf der Platte und der eine CPU wird nur zu 4% ausgelastet?

Das ist ja echt sehr angenehm! Ich habe schon oft von Leichtgewichten gehört, die dann aber doch 300 oder 400 MB im Speicher gefressen haben, oder 5 GB und mehr auf der Platte verschlungen haben. BunsenLabs ist da definitiv kein Wolf im Schafspelz! Das ist schon einmal echt toll!

Was ich aber auch sagen muss, ich bin ja ein Amiga-Kind. Ich habe meinen DraCo so lange benutzt, bis schliesslich nichts mehr ging und ich mir einfach keine neue Hardware mehr leisten konnte. Erst danach hatte ich einen kurzen Ausflug zu Windows XP, bis ich schliesslich nach kurzer Zeit bei Gentoo gelandet bin.

Knappe 200 MB klingen heute echt mager, für ein OS mit GUI. Aber, mein DraCo hatte insgesamt nur 128 MB, eine grafische Benutzeroberfläche und lief noch weit darunter. Das soll jetzt aber einfach mal nur so eine Anmerkung sein. Ich freue mich über den vielen Speicherplatz, den ich jetzt noch übrig habe.

Kritik

Der erste Kritikpunkt habe ich nach der Eingabe von

uname -a

Version 4.9.0-9-amd64? Echt jetzt? Was sagt denn der Befehl auf meinem Hauptrechner?

Jede Wette, wenn ich jetzt ein Update machen würde, wäre da schon wieder ein neuer Kernel. Aber, 5.2.1 gegen 4.9.0? Also da sind wir aber deutlich hintendran! Ich mache mal schnell ein Update. Da BunsenLabs genauso wie Mint, Rasbian und so auf Debian basiert, ist das ja sehr einfach.

sudo apt-get update
sudo apt-get upgrade
sodo apt-get dist-upgrade

Ach du Schande, ich hatte es doch geahnt! Natürlich wird mir auch bei BunsenLabs LibreOffice aufs Auge gedrückt. Warum? Ich will das nicht benutzen, ob Open Source oder nicht. Ich will es NICHT benutzen! Jede Wette, da ist auch HexChat, transmission und so drauf. Das nervt mich langsam! Windows lässt grüssen. Aber dazu später mehr, erst das Update beenden.

Aber okay. Update hat die Sache nicht verbessert. Der Kernel ist immer noch deutlich hinten dran. Da werde ich mal schauen müssen, wie ich das ändern kann. Vielleicht bin ich da bescheuert, aber ich will die möglichst aktuelle Version.

Das führt mich direkt zum zweiten Kritikpunkt!

Natürlich ist da wieder Zeug drauf, was ich nicht will. LibreOffice benutze ich nicht, da wird sich nichts dran ändern. Auch HexChat brauche ich nicht, transmission ebenso. Genauso wie xfburn, oder Filezilla. Das wird mir einfach ins System geknallt und ich habe nicht die Möglichkeit, daran etwas zu ändern. Also muss ich es löschen. Von mir aus.

Fazit

Im Fazit kann ich aber sagen, die Installation ist einfach und geht schnell, nach der Installation belegt das System wirklich sehr wenige Ressourcen, bislang bin ich wirklich der Meinung, BunsenLabs hat echtes Potential!

Arch und AUR

Ach herrje, da war ja noch was bei Arch, was ich auf dem Server wegen PHP 7.1 und mcrypt verwenden musste.

AUR bedeutet ArchLinux User-Community Repository und ist wohl im Prinzip etwas ähnliches wie die Overlays unter Gentoo. Einfach eine Sammlung an Paketen, die nicht in den offiziellen Paketquellen vorhanden sind.

Da wird man wohl auch nicht wirklich drum herum kommen und das ist Grund genug für diesen Artikel. Natürlich gibt es auch dazu eine sehr gute Anleitung, aber ich notiere mir mein Vorgehen trotzdem!

Vorbereitung

Um AUR benutzen zu können braucht man base-devel, was ich ja schon bei der Installation eingebaut habe und git wäre auch nicht ganz unnütz.

pacman -S git

Da ich mal davon ausgehe, dass ich noch mehr Zeug über AUR installieren werde, erstelle ich zudem noch einen eigenen Ordner dafür und nenne den “Diabolus kleiner Ordner für alles was mit AUR zu tun hat”. Da mir das aber zu lang zum tippen ist, kürze ich es ab und nenne ihn einfach aur.

mkdir aur

Das war nur ein Scherz. Ich denke mal, wie man einen Ordner anlegt sollte man schon wissen, wenn man sich mit so etwas auseinandersetzt.

Paket beziehen

Da ich einfach mal testen will, wie sich Arch im Vergleich zu Mint schlägt, will ich ein Benchmark installieren. Da kann man natürlich nun wieder streiten, was da gut ist, was nicht, was sinnvoll ist und was unnütz usw. Da ich aber nur ein paar Werte möchte, die ich vergleichen kann, benutze ich einfach Phoronix Test Suite.

git clone https://aur.archlinux.org/phoronix-test-suite.git

Ja, dafür habe ich natürlich ins aur-Verzeichnis gewechselt, da soll es ja schliesslich rein. Mehr sollte zum beziehen des Paketes nicht nötig sein. Wohl gemerkt, alles läuft unter dem Benutzer, nicht unter Root!

Paket erstellen

Nachdem nun alles vorhanden ist, kann das Paket gebaut werden. Ich bin mal gespannt, ob da irgendwelche Abhängigkeiten vorhanden sind, die ich vorher noch installieren muss.

cd phoronix-test-suite
makepkg

Ja, zwischenzeitlich habe ich das Theme von Cinnamon geändert, Firefox installiert und arbeite mittlerweile mit Terminator.

Schau an, eine Abhängigkeit fehlt. Ich hätte mit viel gerechnet, aber nicht mit php. Egal, wird einfach installiert.

pacman -S php

Und noch einmal.

makepkg

Schon läuft die Sache. Das Paket wurde erfolgreich erstellt und kann damit nun installiert werden.

Paket installieren

Dieses mal wieder mit Root-Rechten und pacman.

pacman -U phoronix-test-suite-8.8.1-1-any.pkg.tar.xz

Tada, fertig!

Paket ausprobieren

phoronix-test-suite benchmark universe

Da mir das aber derzeit alles doch ein wenig zu lange dauert (da werden dutzende Tests runtergeladen und installiert), werde ich das Ergebnis ein andermal präsentieren. Bis dahin bin ich aber zufrieden. Hat alles prima funktioniert!

Bis zur grafischen Benutzeroberfläche

Für den Hardcore-Linux-User ist dieser Schritt wahrscheinlich etwas, worüber er nur schmunzelt. Grafische Benutzeroberfläche. Wofür, wenn man doch eine Konsole hat?

Ich denke aber, wer so drauf ist, der wird sowieso diese Anleitung nicht lesen, denn der installiert ein OS nach Gefühl und braucht dafür keine wirkliche Anleitung mehr. Also glaube ich, ich kann einfach fortfahren.

Es geht nun um folgendes. Es wird alles eingerichtet und installiert, damit am Ende eine grafische Benutzeroberfläche mit Login nach dem booten erscheint. Also, ans Werk!

Benutzer einrichten

Das ist ja jetzt keine Herausforderung!

useradd -m -g users -s /bin/bash diabolus

Wie auf allen meinen System verwende ich auch hier wieder den Benutzer diabolus. Ist einfach so, wird sich so schnell auch nicht ändern. Der braucht jetzt aber noch ein Passwort.

passwd diabolus

Da ich nicht für jeden Befehl, der Root-Rechte benötigt, mich als SuperUser einloggen will, kommt jetzt noch sudo auf das System, um auch als diabolus Befehle mit den entsprechenden Rechten ausführen zu können.

pacman -S sudo

Das muss jetzt auch noch so eingerichtet werden, dass ich auch als diabolus den Chef spielen kann.

nano /etc/sudoers

Dort muss nur die Zeile #%wheel ALL=(ALL) ALL auskommentiert werden und wieder speichern. Damit werden alle Benutzer, die zur Gruppe wheel gehören automatisch berechtigt, Befehle auch mit Root-Rechten zu starten. Aber, diabolus ist noch nicht in dieser Gruppe, also rein mit ihm!

gpasswd -a diabolus wheel

Weitere Einstellungen vornehmen

Was mir aufgefallen ist, die Einstellungen für die Tastatur habe ich leider im letzten Artikel nicht korrekt beendet. Sprich, kaum hat man neu gebootet, hat man wieder das englische Tastatur-Layout. Das wird jetzt geändert.

echo KEYMAP=de-latin1 > /etc/vconsole.conf

Damit sollte sich das geregelt haben.

Ausserdem ist da noch die Sache mit der lokalen Uhrzeit. Natürlich will ich, dass die richtige Uhrzeit angezeigt wird. Es wäre zwar auch möglich, dass ich einfach immer die beiden Stunden dazurechnet, aber es muss ja nicht sein. Also, wird das auch noch angepasst. Hätte ich ebenfalls im letzten Artikel schon machen können.

ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Schon passt auch die Uhrzeit.

Netzwerk

Ach, was ist denn da mit dem Netzwerk los? Warum kriege ich keine Verbindung und kann über pacman nichts installieren? Nun, irgendwie fehlen da die nötigen Einstellungen. Gentoo scheint mir in der Hinsicht ein wenig flexibler!

Egal, wird das eben eingerichtet. Dazu muss ich erst einmal herausfinden, welches Interface ich ansprechen muss. Das ist recht simpel.

ls /sys/class/net

Okay. Das hätte ich dann ja herausgefunden. Es ist ens3, was ich als Interface verwenden muss. Bei Arch ist zudem ein kleiner Helfer dabei, der bei dem Einrichten des Netzwerkes hilft. Dieser nennt sich netctl.

Dieser Helfer möchte aber ein Profil, welches es benutzen soll. Dieses Profil ist nicht schwer anzulegen und gehört nach /etc/netctl/net, so habe ich es genannt und darin steht folgendes:

Interface=ens3
Connection=ethernet
IP=dhcp

Noch schnell speichern und dieser Punkt wäre geklärt. Dazu braucht das Netzwerk aber noch einen Eintrag in /etc/resolv.conf, was auch nicht so schwer ist, denn da steht folgendes drin, zumindest wenn man qemu verwendet:

nameserver 10.0.2.3

Das starte ich jetzt so:

netctl start net

Da ping unter qemu nicht so wirklich funktionieren will, installiere ich einfach mal wget, weil man das ja immer mal gebrauchen kann.

pacman -S wget

Siehe da, es funktioniert! Die Verbindung mit dem Netzwerk steht und die Arbeit kann weiter gehen. Zuerst sollte das aber auch immer beim booten gestartet werden. Ist in meinen Augen sinnvoll!

netctl enable net

Ein paar nützliche Dinge installieren

Es gibt da so ein paar Dinge, die man an Bord haben sollte. Zumindest denke ich das, obwohl es mir unter qemu noch nicht so ganz klar ist, ob ich es da wirklich brauchen werde. Es wird aber auch nichts schaden.

pacman -S acpid dbus avahi

Installiert ist es, ich aktiviere es aber noch nicht. Einfach um herauszufinden, ob ich es unter qemu nun brauche, oder eben nicht.

Grafische Benutzeroberfläche

Hier gibt es sofort ein Problem. Welche soll ich denn nun installieren? Als Erstes kommt mir natürlich Awesome WM in den Sinn, doch das läuft ja auf meinen ganzen Rechnern. Da lerne ich also schon genug darüber. Mate wäre noch eine Idee, aber kenne ich auch schon. Deshalb denke ich, ich werde es mit Cinnamon versuchen. Damit habe ich noch nicht so viel Erfahrung und kann die dabei gleich sammeln.

Also, Cinnamon soll es werden, dann geht es auch gleich los!

pacman -S cinnamon

Das dauert dann wieder ein bisschen. Es ist schon lustig, wie viel dabei heruntergeladen und installiert wird!

Das soll dann ja auch starten, wenn der Rechner, oder der virtuelle Rechner gestartet wird. Also installiere ich auch noch lightdm, damit kenne ich mich ja mittlerweile ganz gut aus.

pacman -S lightdm

Das geht dann doch erfreulich schnell. Jetzt muss Arch das nur noch beim booten starten.

systemctl enable lightdm

Um zu testen, ob alles auch einfach so reibungslos funktioniert, mache ich nun einfach ungetestet einen Neustart und bin gespannt was passiert!

Und was sehe ich? Funktioniert nicht! Also Doktor spielen. Eigentlich mag ich das, ausser es will so gar nicht funktionieren!

Woran könnte es denn nun liegen? Leider an einigem! Ich fange also an, diese Faktoren auszuschliessen. Zuerst fliegt mal lightdm aus der Gleichung und ich starte den xorg-server mittels startx. Das ist ja nicht besonders schwer und bedarf nur einer kleinen Anpassung.

Geändert werden muss die Datei /etc/X11/xinit/xinitrc. Ganz unten ist eingetragen, was beim starten des Servers alles gestartet werden soll. Das wird zuerst mal gelöscht, oder mit # zum Kommentar gemacht, damit es nicht mehr benutzt wird. Anschliessend kommt eine einzige Zeile hinzu.

exec cinnamon-session

Nach dem speichern dann einfach startx und schauen was passiert. Was passiert? Fehlermeldungen! Der Server will einfach nicht starten. Woran kann das nun liegen?

Schlussendlich scheint es an vmware zu liegen. Bei Windows 10 und Linux Mint macht der keine Probleme, aber Arch scheint damit nicht klar zu kommen. Schön, wenn man da die Wahl hat. Ich ändere einfach die Einstellungen beim starten.

Aus

-vga vmware

wird

-vga std

Nach dem booten dann der Test mit startx. Was kommt dabei heraus?

Na das ist doch ein Ding! Funktioniert! Nebenbei, mit -vga virtio funktioniert es auch! Was da nun Vorteile hat weiss ich nicht, werde ich aber noch prüfen.

Aber, es funktioniert! Cinnamon startet, sieht aber ehrlich gesagt nicht toll aus. Ausserdem bekomme ich die Meldung, dass keine Hardwarebeschleunigung aktiv ist. Das ist richtig, stört mich aber auch nicht. Meines Wissens nach liegt das hauptsächlich daran, dass ich vnc zum Anzeigen des Gast-Systems verwende. Ich kann damit leben, also mache ich mir da jetzt auch keine wirklichen Gedanken darum. Die Meldung wird einfach weggeklickt und das Cinnamon nicht gut aussieht, lässt sich ja auch ändern.

Aber, so will ich das nicht haben! Ich will, dass mein System direkt in die grafische Benutzeroberfläche startet. Das heisst, an dem Punkt muss ich nachbessern!

Erst nachdenken, dann handeln!

Natürlich mache ich ganz gerne mal Fehler. Damit habe ich keine Probleme, denn aus denen kann man ja lernen. Wenn ich aber aus einem Schnellschuss einen Fehler mache, ärgert mich das immer heftig!

So auch dieses Mal. Anstatt mich mal darum zu kümmern, warum lightdm nicht mitspielen will, wollte ich einfach eine Alternative ausprobieren. Dabei kam mir sofort gdm in den Sinn. Also:

pacman -S gdm

Soweit noch alles okay, wäre da nicht eine Kleinigkeit. Wie ich nun wieder weiss, gdm installiert dann gleich das komplette gnome mit! Das wollte ich aber eigentlich gar nicht!

Aber gut, auch aus dem Fehler kann man lernen! So kann ich immerhin schauen, wenn ich gdm ausprobiert habe, wie man gdm und alles, was es installiert hat, wieder entfernt. Ist ja immerhin auch gut zu wissen, oder?

Aber gut, bis dahin bleibt gdm erst einmal drauf und funktionieren tut es auch! Also, noch ein Schritt weiter und noch zwei Probleme gefunden!

Problem 1: Es ist noch das englische Tastatur-Layout in X11 eingestellt

Problem 2: Ich habe keine Terminal-Emulation installiert. Ist Cinnamon gestartet, kann ich quasi gar nichts machen!

Problem 2 ist ja schnell gelöst. Ich bin ein Freund des Terminals Terminator und den will ich natürlich auch unter Arch haben.

pacman -S terminator

Problem 2 sollte damit gelöst sein. Nun mal schauen, wie man unter Arch das Tastatur-Layout für X11 ändert. Geht wahrscheinlich genauso wie bei Gentoo, aber vielleicht gibt es dafür ja auch einen Arch-Weg.

Damit sollte es funktionieren!

localectl set-x11-keymap de pc105 nodeadkeys

Da ich der Sache vertraue, lasse ich gdm direkt beim booten starten.

systemctl enable gdm

Neustarten und hoffen.

Bingo! Läuft! Endlich! Deutsches Tastatur-Layout ist auch eingestellt, damit wäre ich ja so etwas wie fertig, denke ich mal!