Fryboyter

Focusrite Scarlett Solo und Linux

Mein Weihnachtsgeld gebe ich erfahrungsgemäß immer für Sachen aus, die ich mir während des Jahres nicht kaufen würde. Zu Weihnachten habe ich mir dieses Mal ein Rode NTG2 Mikrofon, einen K & M Mikrofonständer sowie das Focusrite Scarlett Solo (zweite Generation) gegönnt.

Der eine oder andere wird sich nun Fragen, was hat er mit einem Shotgun-Mikrofon vor? Wird es einen Fryboyter Youtube-Kanal oder Potcast geben? Weder noch.

Bei Sprachchats habe ich zwei Probleme. Zum einen meine mechanische Tastatur. Diese verwendet die blauen Schalter von Cherry. Also die lauten. Leider sind hier einige meiner Mitspieler bei diversen Multiplayer-Spielen recht empfindlich, obwohl ich nur “push to talk” nutze.

Bei Headsets habe ich zudem das Problem, dass man entweder Atemgeräusche hört (was mich selber nervt) oder mich schlecht versteht, da das Mikrofon zu weit weg ist um Atemgeräusche zu vermeiden (was wiederum andere nervt).

Also habe ich vor Weihnachten einen Mitarbeiter von Thomann um eine Lösung gebeten. Schlussendlich sind wir dann bei einem Shotgun-Mikrofon gelandet. Das Rode NTG2 hat allerdings einen XLR-Anschluss, sodass ich ein externes Audio-Interface mit Phantomspeißung gebraucht habe. Leider konnte bei Thomann keiner sagen, welches mit Linux kompatibel ist. Da Thomann aber kein Problem damit hat, dass man Sachen zum Testen bestellt, habe ich mir das Focusrite Scarlett Solo (2nd Gen) bestellt und nach Weihnachten getestet, da zumindest eine Kompatibilität mit Mac OS vorhanden ist.

Verwendet man Pulseaudio funktioniert das Ding “out of the box”. Einfach anschließen und fertig. In meinem Fall muss ich der / die / das Gain allerdings sehr weit aufdrehen. Was allerdings ein Balanceakt ist, da bei zu viel Gain das Klicken der Tastatur auch lauter wird.

Kommt nur Alsa zum Einsatz, wird das Interface gar nicht erkannt. Zumindest nicht mit der Standardeinstellung die Arch Linux ausliefert.

Alles in allem war der Spaß nicht ganz billig. Aber das Klicken ist nur noch ein relativ leises Hintergrundgeräusch und die Atemgeräusche sind komplett weg. Da Rode 10 Jahre Garantie gibt (nachdem man sich registriert hat), relativiert sich der Preis dann auch wieder.

Linux | OSBN

Eigene Paketquelle für Arch Linux im LAN

Seit einigen Wochen nutze ich für die Zwischenablage das Tools CopyQ. Als ich heute die über AUR installierten Pakete aktualisiert habe, wurde mir angezeigt. Dass CopyQ nun “orphaned” ist. Somit kümmert sich aktuell niemand um die Aktualisierung von CopyQ im AUR.

Wie es der Zufall so will, wurde zwischenzeitlich auch Version 3.6.1 von CopyQ veröffentlicht. Also muss eine Lösung her. Am einfachsten wäre es wohl, die vorhandene PKGBUILD-Datei zu aktualisieren und mir damit Version 3.6.1 lokal zu installieren. Mit folgenden Schritten dauert das keine zwei Minuten.

  • Mit “curl -o PKGBUILD https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=copyq" die PKGBUILD-Datei von Version 3.6.0 herunterladen.
  • In der Datei dann die Version anpassen.
  • Mit updpkgsums PKGBUILD die Prüfsumme automatisch anpassen.
  • Mit makepkg -si PKGBUILD -noconfirm kann man dann das Paket erstellen und installieren.

An dieser Stelle ist es mir aber aufgefallen, dass ich CopyQ ja auf mehreren Rechnern / VM nutze. Gut, ich könnte mittels makepkg PKGBUILD einfach das Paket erstellen und dies auf den betreffenden Rechnern / VM installieren. Ich möchte aber möglichst die Rolle des Turnschuadmins vermeiden. Also wie löse ich das Problem?

Der Raspberry Pi auf dem Pi Hole läuft, langweilt sich im Grunde genommen. Auf diesem könnte ich eigentlich eine eigene Paketquelle für das LAN erstellen. Nur ist auf dem Raspberry Pi Debian installiert, sodass ich die Arch-Tools wie repo-add nicht direkt nutzen kann. Na ja wieso einfach, wenn es auch kompliziert geht?

Als Erstes habe ich auf dem Raspberry Pi ein Verzeichnis erstellt, dass als Paketquelle dienen soll. Dieses habe ich dann unter Arch mittels sshfs gemountet und mittels “repo-add /gemountetes_Verzeichnis/raspberry.db.tar” eine leere Paketquellendatenbank erzeugt. Mit der PKGBUILD-Datei von Version 3.6.0 und makepkg PKGBUILD habe ich dann unter Arch das Paket erstellt und dies in das gemountete Verzeichnis kopiert. Mittels “repo-add /gemountetes_Verzeichnis/raspberry.db.tar copyq-3.6.0-1-x86.pkg.tar” habe ich dann die Datenbank aktualisiert. Da man angeblich mit sshfs gemountete Verzeichnisse direkt als Paketquellen nutzen kann, habe ich dann einfach folgenden Eintrag in der /etc/pacman.conf unter Arch erstellt.

[raspberry]
SigLevel = Optional
Server = file:///gemountetes_Verzeichnis

Der Versuch mittels “pacman -Syy” die Paketquellen zu aktualisieren ist aber immer bei der Paketquelle raspberry gescheitert, da die Datenbank nicht gefunden werden kann. Und das, obwohl der Pfad stimmt und die Dateien vorhanden sind. Selbst mit etwas Google-Fu konnte ich das Problem nicht lösen.

Da auf dem Raspberry Pi ja bereits lighthttpd für die grafische Oberfläche für Pi Hole läuft, ist mir die Idee gekommen, dass ich die Pakete über lighthttpd anbiete. Aber scheinbar sieht Pi Hole es nicht vor, dass man über lighthttpd noch weitere Dienste anbietet. Oder ich bin zu blöd dafür.

Da sich der Raspberry Pi wirklich langweilt, kann man ja einfach Apache installieren. Nein besser nginx, da dieser weniger Ressourcen verbraucht. Gesagt getan. In der Konfigurationsdatei /etc/nginx/sites-available/default habe ich dann bei den beiden Zeilen, die mit listen beginnen, den Port geändert, da ja bereits lighthttpd auf Port 80 läuft. Die Zeile die mit root beginnt, habe ich dann so geändert, dass hier auf das Verzeichnis verwiesen wird, das als Paketquelle dienen soll. Noch etwas weiter unten habe ich den Block location / um die zwei Zeilen allow 192.168.1.1/24; und deny all; erweitert. Somit kann nur noch jemand aus meinem LAN auf nginx zugreifen. Sicher ist sicher. Mit einem Neustart von nginx sorge ich dafür, dass die Änderungen berücksichtigt werden.

Zurück auf dem Rechner mit Arch, auf dem ich die Paketquelle raspberry eingetragen habe, habe ich hier die dritte Zeile auf Server = IP_DES_RASPBERRY:PORT_VON_NGINX geändert. Mit “pacman -Syy” habe ich dann versucht die Paketquellen zu aktualisieren. Was scheinbar auch funktioniert hat, da ich keine Fehlermeldung erhalten habe. Da CopyQ über AUR installiert wurde, habe ich nun CopyQ deinstalliert und mittels pacman und der Paketquelle raspberry wieder installiert. Auch das hat funktioniert.

Da ich ja Version 3.6.1 installieren möchte, habe ich dann wie oben beschrieben die PKBUILD-Datei angepasst und das aktuelle Paket erzeugt. Dies habe ich dann wieder in das gemountete Verzeichnis gepackt und mit “repo-add /gemountetes_Verzeichnis/raspberry.db.tar copyq-3.6.1-1-x86.pkg.tar” die Datenbank aktualisiert. Als ich dann mittels “pacman -Syu” auf Updates geprüft haben, wurde mir Version 3.6.1 von CopyQ angeboten, welche ich gleich installiert habe.

Abschließend habe ich dann noch bei allen betreffenden Rechnern CopyQ deinstalliert, die neue Paketquelle hinterlegt und aktualisiert und CopyQ über diese neu installiert.

Vermutlich wäre es einfacher gewesen, einfach die Betreuung von CopyQ im AUR zu übernehmen. Aber das hätte weniger Spaß gemacht. Und wie schon weiter oben angegeben. Warum einfach, wenn es auch kompliziert geht? Zudem kann ich in meiner Paketquelle so viel Mist bauen wie ich will, ohne dafür einen verbalen Einlauf von Dritten zu erhalten. Und ich werde die Paketquelle wohl auch in mein Ansible-Projekt einbauen. Und da ich einige AUR-Pakete installiert habe, deren Betreuer sich oft ziemlich viel Zeit mit dem Aktualisieren lassen, wird es auch nicht bei einem Paket bleiben.

Linux | OSBN

Cache von Pacman automatisch aufräumen

Der Paketmanager Pacman speichert die Pakete unter /var/cache/pacman/pkg. Um bei Problemen ein Downgrade machen zu können, werden dort automatisch keine Pakete entfernt.

Leert man das Verzeichnis nicht regelmäßig kann es sein, dass irgendwann die Festplatte voll ist und man sich wundert was nun schon wieder schiefgegangen ist. Um dies zu vermeiden, kann man sich einen sogenannten Hook erstellen. Mit diesen lassen sich Aktionen bevor oder nachdem etwas mit Pacman gemacht wird ausführen.

Um bei dem Beispiel mit Cache zu bleiben, erstellen wir erst einmal das Verzeichnis /etc/pacman.d/hooks sofern es nicht schon vorhanden ist. In diesem erstellen wir dann eine Datei an deren Ende .hook stehen muss. Also beispielsweise pacman-cache-aufraeumen.hook. In diese kommt dann folgender Inhalt:

[Trigger]
Operation = Remove
Operation = Install
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Cache von Pacman aufräumen...
When = PostTransaction
Exec = /usr/bin/paccache -rqk2

Im Bereich Trigger wird definiert in welchem Fall das ganze ausgeführt werden soll und wofür der Hook gültig ist. In diesem Fall wird also die Aktion beim Entfernen, Installieren und Aktualisieren aller Pakete ausgeführt.

Im Bereich Action wird angegeben, was ausgeführt wird und wann. In diesem Beispiel wird der Befehl /usr/bin/paccache -rqk2 nach dem Entfernen, Installieren oder Aktualisieren eines Pakets ausgeführt. Der Parameter -rqk2 bewirkt, dass alle Pakete im Cache bis auf die letzten zwei Versionen entfernt werden und dass dies ohne Rückmeldung geschieht.

Linux | OSBN

Tannenberg - Willkommen im Ersten Weltkrieg

Eigentlich lasse ich von Early-Access-Spielen die Finger. Eigentlich. Letztes Wochenende habe ich aber diese Regel mal wieder gebrochen und mit neben Battalion 1944 auch Tannenberg gekauft. Letzteres läuft direkt unter Linux.

Tannenberg ist an der Ostfront im Ersten Weltkrieg angesiedelt. Hauptsächlich spielt man den Modus “Maneuver”. Hier ist das Spielprinzip recht einfach. Es gibt mehrere Karten die in diverse Sektoren unterteilt sind. Zwei Teams mit insgesamt maximal 64 Spielern (bei Bedarf werden diese von Bots aufgefüllt) versuchen nun diese Sektoren zu erobern und zu halten. Klingt einfach? Ist es aber nicht.

Im Gegensatz zu anderen Shootern beißt man in der Regel nach einem Treffer ins Gras. Vor allem als Neueinsteiger kann dies richtig nerven da man während einer Runde teilweise mehr stirbt als bei einer Lanparty an einem ganzen Wochenende. Der Umgang mit den Waffen erfordert auch etwas Einarbeitungszeit. Scheinbar waren diese im Ersten Weltkrieg nicht gerade präzise und das haben die Entwickler wohl berücksichtigt. Zudem sind die Magazine oft sehr klein und das Nachladen dauert oft ewig. Wäre dies nicht schon genug Stress, kommen dann noch so nette Sachen wie Mörser- und Giftgasangriffe dazwischen. Für letzteres kann man sich zwar mit einer Gasmaske schützen, allerdings kann man sich diese oft nicht schnell genug aufsetzen. Kurz gesagt man stirbt schnell und oft und steht eigentlich immer unter Strom. Normalerweise würde ich daher die Finger von dem Spiel lassen. Aber irgendwie hat es mich am vergangenen Samstag mehrere Stunden gefesselt.

Aber trotzdem merkt man deutlich, dass es ein Early-Access-Spiel ist. Mit der Grafik lässt sich kein Preis gewinnen (vermutlich auch nicht, wenn das Spiel fertig ist), trotzdem entsteht eine gute Atmosphäre. Die Vertonung hingegen finde ich sehr gelungen. Die Übersetzung der Texte zumindest die in die deutsche Sprache ist, sagen wir mal unfertig, bringt aber auch etwas Witz ins Spiel (z. B. auf einen Kontrollpunkt klicken um zu laichen). Die Hardwareanforderungen sind alles in allem nicht gerade hoch. Empfohlen werden 8 GB RAM und eine Grafikkarte mit 4 GB.

Von den Spielern wurde ich, bis auf wenige Ausnahmen, sehr positiv überrascht. Alles in allem ein freundlicher Haufen, der sich auch nicht zu schade ist einzelnen Spielern oder allgemein dem gegnerischen Team zu gratulieren. Der Versuch mancher mit zum Beispiel mit einem preußischen Dialekt zu sprechen, hat auch für einige Lacher gesorgt. Vor allem, wenn diese der deutschen Sprache kein Stück mächtig sind.

Muss man nun Tannenberg unbedingt spielen? Sicher nicht. Ich bereue es aber auch nicht, knapp 18 Euro dafür bezahlt zu haben und werde am Wochenende sicher wieder ein paar Runden spielen. Wer sich für das Spiel interessiert kann sich die offizielle Seite bzw. die Seite bei Steam anschauen.

Linux | OSBN