Zockertown: Nerten News

Ich stelle immer wieder fest, das ich nach einer Neuinstallation nicht auf Anhieb an alle Helferlein und Tools denke, die mir in meinem Dasein als Debian Nutzer ans Herz gewachsen sind.

Deshalb hier die lose Zusammenstellung meiner Favoriten mit kurzer Erläuterung dazu.

Die Reihenfolge hat keine Bedeutung, sind mir halt so eingefallen.

Paketname	Paket Beschreibung	Bemerkung
ncdu	ncurses disk usage viewer	Unentbehrlich, um die Platzverschwender zu orten und auch gleich ggfs. zu löschen
dlocate	fast alternative to dpkg -L and dpkg -S	Wenn man mal wieder nicht weiß zu welchem Paket eine Datei gehört. Das Paket muß natürlich auch installiert sein.
mlocate	quickly find files on the filesystem based on their name	locate -i mitgliedschaft findet alle Dateien mit mit diesen Namen
apt-file	search for files within Debian packages (command-line interface)	Gegenüber dlocate findet es auch Dateien in nicht installierten Pakteten. Erstellt dazu eine Datenbank
localepurge	Reclaim disk space removing unneeded localizations	Einmal konfiguriert, tut es zuverlässig seinen Dienst, allerdings verlangsamt es ein apt-get install bzw. upgrade....
htop	interactive processes viewer	Das bessere top
iotop	interactive IO Viewer	Welcher Prozess macht am meisten IO?
debian-goodies	Kleine Programmsammlung für Debian-Systeme	u.a. dpigs
tlp	Save battery power on laptops	Wenn man einen Laptop hat, nützlich um die Ladeschwelle für den Akku einzustellen
hdapsd	HDAPS daemon for various laptops with motion sensors	Fallschutz für Laptops
smartmontools	control and monitor storage systems using S.M.A.R.T.	Gesundheit der Platten überwachen
inxi	full featured system information script	z.B. mit inxi -v6 eine Äbersicht gewinnen
aha	ANSI color to HTML converter	z.B. inxi -v6|aha >t500.html
shellcheck	Prüft ein Shell Script auf typische Fehler	z.B. shellcheck mein-script.sh
wird ergänzt

Wegen eines leicht erhöhten Load hat mich nagios informiert. Was macht man da als Admin? Klar, mal gucken, was das denn schon wieder sein könnte....

Ich habe in einem Joomla Web auf meinem Server einen fiesen Burschen eingefangen, der andere Server  angreift.

   21936     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21938     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21940     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21942     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21944     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21946     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21948     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21950     1  3 17:13 ?        00:00:05 /usr/bin/perl ./jcache domain.de
   21952     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
... insgesamt 18 Prozesse ...

 Das habe ich durch mitlesen der Prozesse durch strace -p Beobachtung herausgefunden.

Abschalten ist kein Problem, es kommt aus dem Joomla.

Wenn ich das Web kurz aktiviere werden die Perl Prozesse innerhalb kurzer (unterschiedlichen Zeiträumen im 1-2 stelligen Minutenbereich) wieder gestartet.

Das Problem ist, dass ich keine manipulierte Datei oder extra Datei im betreffenden Web finden kann. Klar, ich werde ein Backup einspielen, nur ist es schon eigenartig, dass ich keine Spuren finde. Eine Möglichkeit wäre ja, das an der Datei der Datumsstempel manipuliert worden ist. maldet findet auch nichts.

Es wäre gut zu wissen, was ich mir da eingefangen habe. Nach den straces jedenfalls etwas fortgeschrittenes, es liest meine /etc/hosts /etc/resolv.conf und /etc/ssl/certs/ca-certificates.crt aus und greift verschiedene Server auf Port 80 und 443 an um nach Lücken in Wordpress Installationen zu finden.

Allerdings macht mich ein Fund in meinen Traces mißtrauisch .

/var/www/clients/clientN/webMMM/tmp/phpSM2Np7  (deleted);

Möglicherweise wird, nachdem das Script gestart wurde, die Datei auch gleich wieder gelöscht?!

Um den auf die Spur zu kommen, habe ich nun ein kleines Script gebastelt, um das eingespielte Backup zu überwachen, denn das heutige erneute aktivieren des Webs führte nicht zum erneuten aufflammen des jcache Wahnsinns ...

cat ueberwache.sh 
while true; do
    inotifywait -m -e modify,create,delete,move --timefmt '%Y-%m-%d_%H:%M:%S' --format '%T %w %:e %f'  -r /var/www/clients/clientN/webMMM/web >>/root/ueberwachung-webMMM-neu.log

done

Also wirklich dirty Scripting, das könnte man natürlich besser gestalten.

Gestartet habe ich das script mit nohup ./ueberwache.sh&

Danach wurde das zurücksetzte Web dem "Kunden" (Kumpel) übergeben und ich konnte die Funktion schön überprüfen, weil jetzt erstmal alle Addons/Plugins upgedatet bzw deinstalliert wurden.

Ausschnitt:

2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR 
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/imagehandler/ DELETE:ISDIR tmpl
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR imagehandler

Nun ist der erste Tag vorbei und kein erneuter Angriff.

das inotifywait tut aber nicht weh, ich lasse es jetzt einfach mal laufen, wenn dann wieder das, oder was anderes unterwegs ist hilft die Dokumentation und das Log hoffentlich.

Es ist kein Geheimnis, das Bloggen ist nicht mehr in.

Wenn ich mir in meinen Zugriffstatistiken immer den jeweiligen Dezember ansehe....

So langsam sollte ich mir wieder einen einfachen Webspace mieten und den Rootserver kündigen

Ich nutze mein Blog ja selber nicht mehr so häufig wie früher, das mag am eigenen geringeren Interesse liegen und vielleicht auch daran, dass man weniger im Zusammenhang mit Linux an aufschreibenswerten Dingen erlebt...

Läuft halt.

Great Cow BASIC Version 0.98.04 ist verfügbar.

Das Great Cow BASIC-Entwicklungsteam hat eine weitere Version veröffentlicht, die die Compiler-Funktionen von Great Cow BASIC weiter verbessert.

IDE 
Verbesserungen des Befehlssatzes für den IDE-Lexer

ADC
- zum Schutz von ADFM auf 10F-Geräten im READAD-Verfahren
- Bibliothek aktualisiert, um 16F1834x ADC-Kanäle mit CHS5-Bit zu unterstützen.

Linux
- Überarbeitete Installationsskripte zur Unterstützung von           Kleinbuchstaben und verbesserter Installation
- Aktualisierte Dateien in Kleinbuchstaben. Keine Funktionsänderung

PPStool
- Es wurde ein Problem behoben, bei dem RX-Pins als Ausgänge und nicht als Eingänge gesetzt wurden (PIC18FxxK42 und ähnliche).
- Fehler behoben, der dazu führte, dass i2c-Pins für 18F*k42 gesetzt wurden.

GLCD
- NT7108C GLCD-Treiber hinzugefügt
- GLCD_SDD1289.h aktualisiert, um veraltete Methoden zu entfernen.
- Aktualisierter ST7735 GLCD-Treiber.  Neue OLED-Schriftunterstützung und allgemeines Update auf den neuesten GLCD-Standard und Überarbeitung auf TFT-Farben.

- GLCDCLS wurde aktualisiert, um viel schneller zu sein und GLCDRotate wurde aktualisiert, um Bits zu unterstützen[849].
- GLCD.h aktualisiert, um dumme Skriptfehler zu entfernen.

USART
- Korrekte fehlerhafte Einstellung von SYNC auf K42/83

PWM
- PWM hinzugefügt PWM hinzugefügt PWM8 hinzugefügt
- Die Bibliothek wurde aktualisiert, um ENablebits zu unterstützen.

PSMC
- PSMCDesigner Toolset hinzugefügt

Gerätedateien
- Aktualisiert 16F178x für ReadAD10BitForceVariante

Programmierer DFU
- Aufnahme des DFU USB-Programmierwerkzeugsatzes in den Windows Installer.

GCGB       
- Überarbeitung von GCGB

Ich habe die fixe Idee auf meinem System zwei Linux Distributionen zu installieren.

Das habe ich schon öfters gemacht, kein Problem.

Nur habe ich ein 9GB großes IMAP Konto im lokalen Filesystem, ich empfinde es als Verschwendung in beiden Systemen die selben Daten zu lagern. Zudem führt dies zu Wartezeiten, wenn man tagelang mit dem System A arbeitet und dann mal zu B wechselt. Die Daten werden dann natürlich erneut geladen und synchronisiert.

Der Ansatz, der eigentlich einleuchtend ist, das versteckte Verzeichnis .icedove (ja, richtig, ich benutze Debian, da hieß es ja schon immer icedove) einfach in eine eigene Partition packen und in beiden Systemen entsprechend mounten.

Ist also gar Ding, warum bloggt der alte Mann dann trotzdem darüber?

Weil es halt im konkreten Fall doch nicht ganz so einfach ist.

Hier also der konkrete Fall.

System A: Debian Stretch

System B: PCLINUXOS 2018

Der Haken ist: In Debian erhält der erste User die uid und gid 1000, in PCLINUXOS sind beide 500.

Das führt dazu, das im System B: die Dateien nicht lesbar für den User sind und somit die Idee nicht funktioniert.

Alles klar, dachte ich mir, ich gebe in der /etc/fstab einfach die uid=500,gid=500 mit und schon klappt's.

Pustekuchen, was ich auch probierte, das EXT4 Filesystem ließ sich nicht dazu überreden, die Optionen zu übernehmen.

Hätte ich mich vorher richtig informiert, dann wüßte ich, dass ext4 die Optionen gar nicht kennt. Das war mir gar nicht so präsent.

:-( 

Nun gut, dann eben der pragmatische Weg, im System B: dem pclinuxos den User eine andere uid und gid geben und eben keine Optionen in der fstab nutzen.

Umgesetzt sieht das nun so aus:

# in /etc/fstab auf System A
/dev/tuxedo-vg/icedove /home/bed/.icedove ext4 defaults        0 2

# in /etc/fstab auf System B
/dev/mapper/tuxedo--vg-icedove  /home/bed/.icedove ext4 defaults 0 2

Selbstredent habe ich auf System A den Inhalt von .icedove in ein tar gepackt, .icedove/* gelöscht, /dev/tuxedo-vg/icedove /home/bed/.icedove  gemountet und das tar da wieder ausgepackt.

Auf System B nach reboot thunderbird gestartet, der findet dann ein gefülltes .icedove, akzeptiert das private Dir und alles wird gut.

Great Cow BASIC v0.98.03 ist erschienen.

Der BASIC Compiler hat erhebliche Änderungen erfahren, die man anhand der kleinen Suffix Erhöhung auf 03 gar nicht vermuten würde.

Das Komplettpaket enthält Demos und sieben Mikroprozessor-Programmierer.

(einschließlich der Kommandozeilen- und GUI-Tools für den Microchip Pickit 2 & 3) für Mikrochip- und AVR-Mikroprozessoren.)

Diese Version führt viele neue Funktionen wie folgt ein, lest  die Release-Information für detailierte komplette Beschreibungen, da es fast 50 Änderungen in dieser Version gibt.

Compiler
- Weitere Leistungssteigerungen - der Compiler ist schneller. (Auf meinem Linux Rechner ziemlich genau doppelt so schnell)
- Verbesserte Oszillatorunterstützung
- Korrekturen und Änderungen zur Verbesserung der Stabilität

Gerätedateien
- Neue Device Treiber hinzugefügt
- Alle Geräte Libraries wurden aktualisiert, um neue Funktionen zu unterstützen: HEFSAF, ADC und Speicher

Hilfe
- Aktualisiert für neue Fähigkeiten und Verbesserungen

GLCD
- Nextionsunterstützung
- ILI9326 Unterstützung

PWM
- Neuer flexibler Ansatz für CCP/PWM

LCD
- Neue 3-Dreileiter-Lösung

USB
- Neue USB-Funktionen eingeführt

RTCC
- Verbesserte Microchip RTCC-Unterstützung

Speicher
- HEF- und SAF-Unterstützung

Unterstützung von Betriebssystemen hinzugefügt
- Mac OS
- FreeBSD

Programmierer
- CuriousLoader hinzugefügt
- Verbesserte Benutzerfreundlichkeit

Bibliotheken
- Neue PCA9685
- Aktualisiert MCP 23017

CLC Designer
- Verbessert für die Unterstützung von mehr Geräten

PPSTool
- Erhebliche Verbesserung zur Unterstützung von 18FxxK42 I2C
- Farbkennzeichnung für den verwendeten Port
- Neuestes Gerät XML v1.75

Tipps und Tricks
Die bisherigen Tipps und Tricks sind noch sehr gut. Siehe https://sourceforge.net/p/gcbasic/discussion/579125/thread/7fae77a3/

Bitte beachten:

Bitte keine Dateien aus dem Release v0.98.03 mit einer anderen Version von Great Cow BASIC vor v0.98.03 selektiv verwenden.

Bitte halte also die Version in Bezug auf den Build konsistent.

Wenn du das Build für deine eigenen Bedürfnisse anpasst, dann gibt es viele Methoden, um das Build konsistent zu halten und es dir zu ermöglichen, es anzupassen - es gibt Beiträge im Forum, wie du dies erreichen kannst.

Zum Download

Kleiner Hinweis für die Unixoiden User: Ursprünglich wurde GCBASIC unter Windows entwickelt, dort ist Groß Kleinschreibung kein Thema in Pfadangaben. Im Laufe der Zeit ist die User Gemeinde, und damit auch die Zahl der Mitwirkenden aus dem Unixoiden Umfeld angestiegen, was immer mehr zu Verwirrungen bei z.B. den Includes führen konnte. Nichts, was einem nun wirklich den Nutzen von Great Cow BASIC verringern würde, aber mehr Spaß hat man nunmal ohne Mixed Case.

Deshalb wurde das Projekt in einem Kraftakt auf einheitlich Groß Kleinschreibung geändert. Daher ist die endgültige Unixoid Build Version ein paar Tage hinterher. Anfang Dezember wird die bereinigte Version für die Unixoiden fertig sein.

Ps: Unixoid meint hier Mac OS, FreeBSD und Linux als Sammelbegriff. Evtl. würde es auch für die anderen Unix Plattformen funktionieren, das ist aber nicht getestet worden

In letzter Zeit überschwemmt ein China Gadget die Electronic Community. Mit dem Suchbegriff USB Charger Doctor findet man bei den üblichen Verdächtigen eine unübersehbare Anzahl ähnlicher Geräte. 

Wofür ist so was denn gut? Höre ich dich fragen. Nun einmal fällt mir zu allererst das überprüfen von Powerbanks ein, endlich weiß man genau, welche Kapazität denn nun wirklich drin ist. Die selbe Anwendung ist auch bei Smartphones praktisch, denn hier kann man leicht den Zustand des Akkus überprüfen.

Weiterhin sehr interessant ist das Leistungsverhalten des USB Ports zu überprüfen, bzw. des Ladeadapters.

Prima eignet es sich auch mal die Stromaufnahme von externe Festplatten zu messen. Wer sich wundert, das seine Festplatte an Gerät A und B, nicht aber an C läuft, findet hiermit auch sofort die Erklärung. Praktisch jede externe 2,5Zoll Harddisk ist beim anlaufen ausserhalb der Spezifikationen von USB 2.0, Fast alle Mainboard Hersteller haben darauf reagiert und können kurzzeitig diesen Mehrbedarf liefern. Aber eben nicht alle und verlassen kann man sich eh nicht darauf.

Auch kann man bei entsprechend vorhandenen Kabeln den Spannungsabfall an unterschiedlichen Varianten von USB Verbindungskabeln überprüfen.

Hier ist es in Aktion zu sehen beim Laden meines Handys. Hier kann man gleich mehrere Erkenntnisse gewinnen. Die Anzeige differiert um ein paar LSD (Last Significant Digits). Das Display ist blickwinkelabhängig, aber sehr gut lesbar. Als Interessierte Laie möchte ich natürlich wissen, ob die Angabe "Accuracy 1%" auch zutrifft, deshalb habe ich es mit einem genauen Multimeter verglichen.

(Das Bild ist nicht ganz scharf, ich musste einige Klimmzüge veranstalten, um überhaupt beide Anzeigen gemeinsam abbilden zu können)

Hier erkennt man eine Differnez von 5,36 - 5,289 Volt = 71 mV

Bezogen auf den Messwert von 5,289V sind das weniger 1,5%.

Das ist beeindruckend. Die Angabe von Genauigkeiten werden meistens auf den Endwert bezogen, das sind bei meinem Gerät 20V, Hier wäre ein Fehler von 0,2Volt gerade noch akzeptabel.

Laut Hersteller wird behauptet, dass die Eingangspannung bis 20 Volt betragen darf, damit verläßt man die USB Spezifiaktion bei weitem, hierzu habe ich mir noch keine Gedanken gemacht, ich frage mich auch wo der Anwendungsfall wäre. Vielleicht weiß ein Leser mehr?

Aber auch bei reiner Verwendung an 5V Systemen ist dieses Meßgerät wirklich seine 5 €‚- wert, eine klare must have Auszeichnung von Zockertown!

Ergänzung: Um den Charger Doktor so wie eigentlich gedacht als Akku Kontrolleur zu benutzen, muß ein Mindestladestrom fliessen, den Akku in meiner Pebble kann man jedenfalls damit nicht messen. Also ein Strom von ca. 80mA ist zu wenig, um Zeit und Kapazitätsmessung zu starten

Ist hingegen ein schnellladefähiges Gerät (Samsung A5) dran, dann erkennt man die höhere Ladespannung und Strom.

(Ok, das Phone war fast voll, deshalb nur 560mA, das tut hier jetzt nichts zur Sache)

sondern: ... das, obwohl das Typenschild der "Ladestation" behauptet, es wäre ein USB Output 5V ...

Sachen gibt's

Nach ein paar Jahren ist es normal, dass die Lüfter voller Staub sind. Die Abwärme konnte nur noch mit Mühe hinreichend abgeführt werden. Beim zocken von XCOM2 WotC rauschte es schon ganz schön kräftig, Die Temperatur der Grafikkarte erreichte schonmal 78°, also habe ich mal die Rückwand mal abgenommen und den Staub entfernt.

Fast komplet saß der Staub direkt vor den Lamellen.

Nur mal kurz angemerkt.

Bisher war das updaten von owncloud eine Plage --, möglich, aber halt aufwändig.

Nun, mit ownCloud 10.0.9 (stable) ist das Geschichte! Den neuen Release.key musste ich noch aktualisieren und nun funktionierte es.

Unmittelbar danach sollte man seinen ownload Service besuchen und einmal klicken, dann läuft das update.

(Klar, geht auch auf der Console, hatte halt gucken wollen, ob der Service down ist, war er aber nicht )

Schön.

Ich bin ja ein Fanboy von Fritz. Besonders gut finde ich auch die Fritzphones.

Wegen eines ISP wechsels mußte ich  mir einen neuen Router aussuchen. 

Ich habe mich für den 7590 entschieden. Vorher hatte ich Fritz!box 6390 Cable.

Mit dem 7590 hatte ich so meine Schwierigkeiten, Wlan verbinden klappte sehr gut, aber nach dem mein Notebook im Suspend to ram war, war ein reconnect unmöglich. Nur mit Fritzbox restart bzw. mit der WLan Taste aus/ein, konnte das behoben werden.

Auch eines meiner Android Spmartphones hatte Probleme, es behauptete immer Authentifizierungsproblem.

Der Softwarestand der 7590 war FRITZ!OS: 06.92. Ich habe mir die Labor Software fritzbox-7590-labor-59298 installiert, denn im Readme stand einiges in dieser Richtung.

Das Resultat mit dieser FRITZ!OS: 06.98-59298 BETA geradezu sensationell.

Endlich wieder rattenschnelles reconnect nach dem aufwachen des Laptops und auch das Android Smarphone meckert nicht mehr.

(Das war früher mit Debian Jessie auch schon mal so schnell, mit meinem Buster war es schon immer etwas langsamer)

Ist schon interessant, welchen Einfluß der Wifi Sender haben kann, es liegt nicht immer an den Clients, wie ich hier bemerken durfte.

Jetzt warte ich, bis die Preise für das 7590 runter gehen und hole mir eine zweite, damit hätte ich das Haus perfekt ausgeleuchtet.

Heute ist mir was merkwürdiges passiert.

Mein Notebook Tuxedo X1506 läuft mit Debian Buster eigentlich problemlos.

Nun bin ich gerade dabei etwas neues  (neuer Controller [Hardware]) auszuprobieren und musste deshalb auch mal rebooten. Oh Schreck, kein Login mehr möglich. Offenbar versuchte systemd das grafische Login (gdm3) zu starten und erlitt damit Schiffbruch. Immer und immer wieder wurde es versucht.

Nur wildes rumhacken auf ALT-F9- F1 F2 F3 STRG-ALT-F9 F1 F2 F3 STRG-D STRG-C führte dann mal zum Erfolg.

Dann funktionierte das Login und das System wieder einwandfrei -- bis zum nächsten Reboot.

Also Ursache suchen und beseitigen war angesagt.

ein dmesg -HTw brachte segfaults zum Vorschein. Ein Ausschnitt gefällig? 

Bitte sehr:

Jul 11 20:10:56 tuxedo kernel: [  245.931762] gnome-shell[6921]: segfault at 20 ip 00007fa6d5c93aed sp 00007ffdb88d4330 error 4 in libmutter-2.so.0.0.0[7fa6d5b96000+165000]
Jul 11 20:10:59 tuxedo kernel: [  249.770883] gnome-shell[7027]: segfault at 20 ip 00007f4627e2faed sp 00007fff112a8360 error 4 in libmutter-2.so.0.0.0[7f4627d32000+165000]
Jul 11 20:11:03 tuxedo kernel: [  253.668634] gnome-shell[7159]: segfault at 20 ip 00007f16f21cbaed sp 00007fff073068c0 error 4 in libmutter-2.so.0.0.0[7f16f20ce000+165000]
Jul 11 20:11:07 tuxedo kernel: [  257.467717] gnome-shell[7239]: segfault at 20 ip 00007f1523bd1aed sp 00007ffc4e207870 error 4 in libmutter-2.so.0.0.0[7f1523ad4000+165000]
Jul 11 20:11:11 tuxedo kernel: [  261.281186] gnome-shell[7319]: segfault at 20 ip 00007f28e6099aed sp 00007ffe6cb884c0 error 4 in libmutter-2.so.0.0.0[7f28e5f9c000+165000]
Jul 11 20:11:15 tuxedo kernel: [  265.076490] gnome-shell[7399]: segfault at 20 ip 00007fdd9631aaed sp 00007ffeb8107990 error 4 in libmutter-2.so.0.0.0[7fdd9621d000+165000]
Jul 11 20:11:19 tuxedo kernel: [  268.836405] gnome-shell[7479]: segfault at 20 ip 00007f8fd0ee4aed sp 00007ffd74d1a760 error 4 in libmutter-2.so.0.0.0[7f8fd0de7000+165000]
Jul 11 20:11:22 tuxedo kernel: [  272.671850] gnome-shell[7559]: segfault at 20 ip 00007f4eed3fcaed sp 00007ffc26024ee0 error 4 in libmutter-2.so.0.0.0[7f4eed2ff000+165000]

Installieren von systemd-coredump stellte das tool coredumpctl zur Verfügung.

Also installiert und erneut gebootet. jetzt mit coredumpctl die generierten Coredumps gesehen und mit coredumpctl gdb untersucht

z.B.: gnome-shell[5021]: segfault at 20 ip 00007f97ad0bfaed sp 00007ffc38165c20 error 4 in libmutter-2.so.0.0.0[7f97acfc2000+165000]

Aha. Die Ursache hat evtl. mit  libmutter und gnome-shell zu tun.

Ok, dachte ich, googelste mal, ob das bereits ein bekanntes Phänomen ist, ja es gibt elend viele Treffer.

Allerdings nicht direkt dasselbe, mit Einschränkung der Aktualität auf letzte Woche wurd ich dann fündig.

Das Problem ist ein Bug, der mit dem Wayland Support zusammen hängt. Ich habe im Notebook eine Nvidia Karte, Wayland Support kann ich daher eh nicht nutzen, also den Support im GDM3 explizit abgeschaltet.

Die Option   WaylandEnable=false  in /etc/gdm3/daemon.conf entkommentieren, also das # wegnehmen.

Nun gehts wieder. Puh!

Gefunden habe ich das bei den Leuten von Archlinux.

Was hatte Zockertown lange nicht?

Richtig eine Besprechung eines coolen rundenbasierten Games.

Nun, da gibt es richtig gute Neuigkeiten.

Einer der Schöpfer und Hauptdesigner der originalen XCOM-Spiele, Julian Gollop hat im Rahmen einer Croud Gründungskampagne die Entwicklung von Phoenix Point begonnen. Erscheinungstermin wird wohl erst im Juni 2019 erscheinen.

Da ich erklärter XCOM Fanatiker bin, habe ich natürlich auch meinen Obulus geleistet. Als kleinen Dank kann ich seit dem 15.5. 2018 das sogenannte Backer Build 1.2 spielen. Und zwar nativ unter Linux.

Das Original ist ja von 1994, es lief noch mit DOS, Linux war da in etwa bei dem  Stand 1.0 und an eine Emulation von DOS war damals noch nicht zu denken, obwohl ich es bereits nutzte.

Doch nun zum Backer Build 1.2:

Es ist eine Mission "Fort Freiheit" spielbar, in ein paar interessanten Varianten.

Natürlich ähnelt das Spielgefühl dem der XCOM Reihe von Fireaxis, es gibt aber einen großen Unterschied.

Das Ziel/Schaden System ist neu erfunden, obwohl man sowas bereits in anderen Spielen gesehen hat, gab es das in dem Sinne nicht bei Xcom.

Man kann, wenn man will, frei zielen und einen Schwachpunkt in der Rüstung / Verteidigung des Gegners finden.

Neu (bzw. erneut wie im Original) gibt es Friendly Fire, wenn man nicht aufpasst, schiesst man seinem Kameraden in den Rücken, was der sicher nicht witzig findet, oder er bekommt einen Querschläger ab.

Ein zweiter Unterschied zum Original sind die Bossgegner, die aufzuhalten gelingt nur, wenn man gezielt Schwachpunkte aufspürt.

Munition ist ziemlich knapp, man findet aber Nachschub auf der Map

Im Netzt gibt es zu Hauf Videos, die ihr euch ansehen könnt, damit will ich euch nicht langweilen. Ich möchte nur ein paar Teilaspekte darstellen.

Ich bin über das aktuelle Marketing, wenn man es denn so nennen will positiv überrascht.

Es ist gestern der 2te Backer Build gewesen, der erste allergings mit einem Linux und Mac Client.

Es ist vorgesehen ca. alle 2 Monate oder auch häufiger einen neuen Build zur Verfügung zu stellen. Im Game kann - und soll- man bei aufgefallenen Bugs das Entwickler Team benachrichtigen.

Die hören allerdings nicht nur über diesen Kanal von den Spielern, sondern auch über ein eigens eingerichtetes Forum, wo die Spieler ihre Kritik und Vorschläge zum Game mitteilen und diskutieren.

Ich habe den Eindruck, dass dort auch auf die Strömungen reagiert wird und sie sich Mühe geben ein umfassendes großartiges Spiel abzuliefern.

Ein Screenshot utility ist für das Bug Meldesystem integriert, leider nicht für normale Screenshots, deshalb habe ich das Game im Fenstermodus gestartet, um leichte Screenshots zu machen. Das Game läuft aber in Fullscreen Mode einwandfrei.

Zum konkreten Backer Build schreibe ich noch später etwas mehr....

Update 4.7.2018 (ups, habe ich ja doch nicht.)

Egal, es gibt ein weiteres Build.

Im Telegrammstil kann der geneigte Leser es hier lesen, was ich dazu geschrieben habe.

https://www.linuxgaming.de/neuigkeiten-f6/phoenix-point-t6413.html

Ich hätte da ein Anliegen:

Wo sind denn meine Spielartikel besser aufgehoben?

Wie bisher hier im Blog, schliesslich habe ich hier keine Begrenzungen, was Grafiken betrifft und was ich schreibe, der Mod bin ich selber

Oder aber bei linuxgaming.de: Da seid ihr ja auch und warum 2 Quellen abgrasen, wenn man es an einer prominenten Stelle tun kann?

Ich freue mich auf Antworten

Nein, keine stärkere Feder, oder stärkere Akkus, sondern eine kleine elektronische Spielerei.

Eingebaut wird der Mod in ein rein mechanisches NERF Scharfschützengewehr Longshot CS-6.

Es wird die verbliebene Munition angezeigt und ein LED Blitz ausgelöst, wenn die Schaumstoff Patrone durch den Lauf geschossen wird.

Umgesetzt wurde das mit Great Cow Basic. Einem Compiler, der Basic frisst und Assembler für PIC und AVR ausspuckt.

Ich habe an anderer Stelle bereits einen Artikel über Great Cow Basic geschrieben und einen Bericht über ein damit realisiertes Projekt angekündigt. Nun, hier kommt der Bericht.

Die Anzeige erfolgt auf einem  128x32 Pixel Display (Suchbegriff I2C SDD1306 0.91 128x32 OLED)

Die Anzeige ist nur ca. 2.31 cm groß, das komplette Display hat ungefähr 3,5cm, damit eignet es sich ideal zum Einbau in das Zielfernrohr.

Funktionsbeschreibung der Software:

Die Bilder sind von einem frühen Prototyp, die Qualität der Bilder bitte ich zu entschuldigen. Von der endgültigen Version werden hoffentlich schärfere nachgereicht. Allerdings hat auch das Grenzen, denn das Display hat nur kleine Abmessungen. In Natura sieht das Display erhelbich besser aus, es ist eine Freude, dieses Display in Aktion zu sehen.

Einschalt Screen

Nach dem Initialisieren wird ein Begrüßungsbildschirm gezeigt, der die aktuelle Spannung des verwendeten Li Ion Akkus anzeigt. Basis der Berechnung ist die Betriebspannung von 5 Volt, welche konstant gehalten wird. In Abhängigleit von der Akkuspannung wird ggfs. ein anderer Text ausgegeben. Bitte beachten.

Man kann nun einfach warten, bis zur Hauptanzeige gewechselt wird, oder aber die UP Taste drücken, um direkt zur Hauptanzeige zu springen.

Main Screen

Die Hauptanzeige zeigt in großen Ziffern die Anzahl der verbliebenen Munition. Rechts daneben ist die Füllstandsanzeige der Akku Spannungsversorgung angezeigt. Wenn die Spannung unter dem Schwellwert von ca. 3V gesunken ist, wechselt der Schriftzug "UP-DOWN->Setup " mit dem Hinweis auf "charge!". Die Funktion ist noch eine Weile sichergestellt, jedoch sollte der Akku bald geladen werden. Wenn die Spannung des Akkus unter 2.5 V gefallen ist, wechselt die Anzeige zu "Alert!". Nun muss unbedingt das System ausgeschaltet und der Akku geladen werden, sonst wird der Akku beschädigt. Im Sourcecode sind die Schwellen individuell einstellbar, so dass man auch Batterien, oder einen anderen Akku Typ verwenden kann und trotzdem etwas von der Kapazitätsanzeige hat

Wenn die verbliebene Munition nur noch 3 Patronen oder weniger beträgt, beginnt die Ziffer zu blinken und die Anzeige in der Helligkeit zu pulsieren.

Nach Wechsel des Magazins (Reed Kontakt Magazin) geht die Anzeige wieder auf den Standardwert von 30.

Die Helligkeit der Anzeige kann mit dem Poti beeinflußt werden. Die Tasten UP und Down dienen zur Bedienung des Einstellmenüs.

Flashtime Screen

Beide Tasten gleichzeitig gedrückt, lassen das Einstell Menü erscheinen. Hier kann mit den Tasten der Flash Timer eingestellt werden, also die Dauer eines Lichtblitzes. Während dieses Einstellmenü gezeigt, wird, kann trotzdem der Trigger betätigt werden, man ist also nicht wehrlos! Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird.

Rounds Screen

Durch erneutes gleichzeitiges Drücken von UP und Down gelangt man in das Einstellmenü für die Munition

Hier kann man die Anzahl der Patronen einstellen, die beim Magazinwechsel als "Voll" geladen eingestellt werden. Der von Links nach Rechts immer länger werdende Balken zeigt die Restzeit an, bis das Menü automatisch verlassen wird. Wenn man UP und DOWN gleichzeitig drückt, wird die eingestellte Munition dauerhaft gespeichert.

Weitere Beschreibung und auch neue Fotos wie z.B. dieses, auf der englischsprachigen Seite

Nach Pfingsten wird es hoffentlich dort auch endlich ein Action Video geben, vorausgesetzt, die Waffe überlebt den F.A.T.E Con

Mann, ist das lange her.

Mein letzter Eintrag hier in Zockertown, der mit Kernel Compilierung zu tun hatte, ist ca. 9 Jahre her.

Seit dem bin ich offenbar immer mit dem Standard Kerneln von Debian ausgekommen.

Komme ich immer noch, aber im aktuellen Testing "Buster" habe ich zwei kleine Ärgernisse, die ich untersuchen bzw. beheben möchte. Zum Beispiel funktioniert seit dem Debian linux-image-4.15.03-amd64 das einstellen der Hintergrundhelligkeit auf meinem Tuxedo XC1506 nicht mehr per Fn Tasten, sondern nur noch mit xbacklight.

Die Ursache ist die fehlende Infrastruktur unter /sys/class/backlight/ 

Deshalb dachte ich, ich probiere mal einen neuen Kernel und gucke mir die .config genauer an, was übrigens in heutigen Zeiten nicht ohne ist, man kämpft sich durch mehr als 8000 Zeilen....

Der von Buster bereitgestellte und installierte Kernel ist: linux-image-4.16.0-1-amd64

Mein compilierter Kernel ist der derzeitige Stable 4.16.8

Die Fehlermeldung:

 *** Keine Regel vorhanden, um das Ziel „debian/certs/test-signing-certs.pem“, 
  benötigt von „certs/x509_certificate_list“, zu erstellen.  Schluss.
Makefile:1060: die Regel für Ziel „certs“ scheiterte

wird durch die Config Optionen CONFIG_SYSTEM_TRUSTED_KEYS="" und auskommentieren / entfernen von CONFIG_SYSTEM_EXTRA_CERTIFICATE vermieden

#Kernel compilieren

time make-kpkg -j 8 --initrd --revision 100.0 kernel_image modules_image

real 29m53,385s

user 180m22,725s

sys 15m53,992s

Die Namensgebung ist ungeschickt, aber für meine Zwecke ausreichend, wichtig ist, dass ich die gebauten Kernel auseinander halten kann.

So. Neuer Kernel läuft nun, Helligkeitseintellung mit den Fn Tasten geht wieder, das zweite Ärgernis, nämlich die Fn Taste für Flugmodus geht immer noch nicht wieder, das ist mir aber erstmal nicht so wichtig, hat bestimmt ähnliche Ursachen.. 

Mich hat interessiert, in wie fern sich die Compiler von gcbasic zwischen Wine und natives Linux unterscheiden. Mit wineconsole steht ein Tool zur Verfügung um Windowsprogramme, die ein Commandline Interface haben, direkt aufzurufen ohne den Umweg über die Windows GUI zu benutzen.

Rufe ich also

time winesconsole --backend=curses exit

​auf, kommt man auf eine Ausführungszeit von

wineconsole: 
real 0m0,223s 
user 0m0,024s 
sys 0m0,024s

Dies ist also der Overhead des Wine Systems und muß beim Ergebnis der Untersuchung berücksichtigt werden.

Das kleine Demo Programm 040_Rotate_the_LEDS.gcb, das für das Board StartPic18 im Demo Ordner beretgestellt ist, dient hier als nicht repräsentive Basis.

time wineconsole --backend=curses GreatCowBasic/gcbasic.exe 040_Rotate_the_LEDS.gcb 
real 0m2,182s 
user 0m0,032s 
sys 0m0,040s

time gcbasic 040_Rotate_the_LEDS.gcb 
real 0m0,430s 
user 0m0,368s 
sys 0m0,020s

​Den Overhead abgezogen, dauert also das compilieren eines kleinen Basic Programmes mit wine ziemlich genau 2 Sekunden. Das compilieren mit dem nativen Basic Compiler unter Linux dauert weniger als 0.5 Sekunden.

Der Compiler in der nativen Linux Ausprägung ist also ca. 4 mal so schnell. 

Der wine normalerweise keine so großen Einbußen hat, stellt sich die Frage, woran liegt das?