SN-Media Blog http://sn-media.com/de/blog Wer sich bei allen beliebt machen will, wird schnell beliebig. de-de Tue, 22 Sep 2020 16:04:28 +0200 Ein weiteres Voptop Beta ReleaseEs war mal wieder soweit, es wurde ein Voptop Release fertig. Mit diesem Release ist Voptop endlich unabhängig von libnice¹ und ich verabschiede mich damit vom ICE² Protokoll.
Der Verbindungsaufbau mit ICE hat einfach viel zu lange gedauert und sehr zuverlässig war das auch nicht. Außerdem war es am Ende doch immer so, dass es nie ohne TURN³ Server ging. Also habe ich mich entschiedenen ein Voptop eigenes Relay bzw. Gateway zu schreiben, für den Fall das keine direkte Kommunikation zwischen einzelnen Voptop peers zustande kommen kann oder wegen Inkompatibilitäten zwischen IPv4 <-> IPv6 und Ähnlichem.
Das war alles andere als einfach, ist jetzt aber fertig und bisher scheinbar sehr stabil. Der Verbindungsaufbau mittels meines Gateways ist mehr als zehnmal so schnell, wie es mit libnice in Kombination mit einem TURN-Server war.
Außerdem hab ich eine Reihe von Bugs behoben, von nicht korrekter Initialisierung der Audioaufzeichnung für Videochats bis hin zum fixen der Webcam Auswahl für Videochats.
Ferner kann man mittlerweile Voptop nicht nur auf der Voptop Webseite runterladen, sondern auch im Snapcraft Store.
Von Flatpak zur Erstellung eines Installationspaketes hab ich mittlerweile wieder abstand genommen. Das Argument für Flatpak, nämlich das es vollständig Open Source ist, ist leider auch sein stärkstes Gegenargument. Man hat zwar mit Flathub4 einen zentrale Paketquelle, diese wird aber durch Github5 gespeist (es gibt also keine eigene vernünftige Infrastruktur). Um es kurz zu machen; auf Github habe ich keinen Bock, ich will da keinen Account für Voptop haben und außerhalb einer allgemein bekannten und zugänglichen Paketquelle macht das keinen großen Sinn.

Get it from the Snap Store

1) libnice
2) ICE
3) Turn
4) Flathub
5) Github

]]>
http://sn-media.com/de/blog/Ein weiteres Voptop Beta Release/115http://sn-media.com/de/blog/Ein weiteres Voptop Beta Release/115Wed, 05 Aug 2020 00:00:00 +0200
Snappy Paketierung von VoptopEs ist bald mal wieder soweit, absehbar werde ich eine neue Version von Voptop¹ freigeben. Womit ich mich wieder meinem alten „Voptop Release - Management“² Problem annähere. Bis jetzt bin ich noch immer nicht so richtig dazu bekommen, mir mittels Jenkins einen Build Server aufzusetzen, das hole ich jetzt nach. In dem Zuge werde ich jetzt erstmals zusätzlich zu „deb“³ Paketen auch „Snappy“4 Pakete anbieten. Snappy ist ein Paket Format von Canoncial5 (dem Unternehmen hinter Ubuntu6 Linux).
Für das Erste werde ich mich auf das automatisierte bauen von Snappy Paketen konzentrieren, denn ich bin mir nicht sicher, ob ich mit Voptop noch langfristig die Paketierung mit deb weiter unterstützen will (der Aufwand ist einfach zu hoch, man paketiert ab Ende für x Distributionen und deren Versionen).
Snappy bringt eine Vielzahl von Vorteilen gegenüber deb. Der wichtigste Vorteil ist für mich, dass ich mit einem einzigen Installationspaket sehr viele Linux Distributionen auf einmal unterstütze7. Auch sehr wichtig für mich ist, dass ich mit Snappy einen zusätzlichen „Vertriebskanal“ für Voptop bekomme (der ist aber auch einer der Kritikpunkte von Snappy, dazu später mehr), den Snappy App-Store.

Das Paketieren mit Snappy ist auf den ersten Blick sehr einfach. Man schreibt eine Konfigurationsdatei (im yaml8 Format). In dieser Konfigurationsdatei gibt man einige Metadaten an (Name, Beschreibung etc.), wo der Quellcode zu finden ist (im Dateisystem, in einem Source-Repository oder Ähnlichem) und gibt ein sogenanntes „build plugin“ an (make, cmake, qmake etc.). Im Weiteren spezifiziert man die Abhängigkeiten, die benötigt werden, um das Projekt zu bauen (im Grunde die deb - dev Pakete der verwendeten Bibliotheken) und die Pakete, die benötigt werden, um die Anwendung laufen zu lassen.
Außerdem bestimmt man eine Art Laufzeitumgebung, core18 oder core20 zum Beispiel. Da das Ganze von Canoncial kommt, basiert die Laufzeitumgebung natürlich auf Ubuntu (jeweils die LTS Versionen, wie man schon am Namen core18 und core20 sieht). Im Wesentlichen wird am Ende mit Snappy eine Ubuntu Distribution um die eigentliche Anwendung herum aufgebaut, die aber nur die Abhängigkeiten besitzt, welche die mit Snappy paketierte Anwendung zur Laufzeit braucht (was die Pakete im Vergleich zu „nativ“ paketierten Anwendungen immer noch extrem „voluminös“ macht).

Einer der am häufigsten kritisierten Eigenschaften von Snappy ist, dass man die Paketquelle nicht frei wählen kann. Canoncial betreibt die einzige Paketquelle, alternative App-Stores kann man nicht verwenden (zumindest ist das bisher so). Für mich ist das zumindest für das erste kein Problem, ob ich das jedoch dauerhaft will weiß ich noch nicht. Auf jeden Fall gibt es aber Alternativen, am interessantesten scheint mir dabei Flatpak9 zu sein (damit habe ich mich aber noch nicht tief greifend genug befasst). Flatpak hat wohl derzeit einer der größten User und Entwicklungs Basen, absehbar werde ich mich also auch damit befassen.

1) Voptop
2) Voptop Release - Management
3) deb
4) Snappy
5) Canoncial
6) Ubuntu
7) Unterstützte Distributionen
8) YAML
9) Flatpak

]]>
http://sn-media.com/de/blog/Snappy Paketierung von Voptop/114http://sn-media.com/de/blog/Snappy Paketierung von Voptop/114Wed, 15 Jul 2020 00:00:00 +0200
None blocking socketsSeit einiger Zeit (eigentlich schon recht lange) arbeite ich daran ICE¹ aus meinem Videochat und Instant Messenger Projekt Voptop² zu entfernen. Bisher verwende ich dafür eine Bibliothek Namens libnice³, mit der bin ich aber nicht besonders zufrieden. Der Verbindungsaufbau dauert ewig und die Verbindung, die damit entsteht, ist auch nicht besonders stabil. Von Datendurchsatz und Latenz ganz zu schweigen. Für Videokonferenzen meiner Meinung nach völlig ungeeignet und besonders toll ist die API auch nicht gerade. Am Ende war es im Grunde auch immer so, dass via ICE nur eine Verbindung mittels eines TURN4 Server erzeugt werden konnte, man also bei üblichen Internetanbindungen in unseren Breitengraden über einen Router quasi nie ohne Relay auskam. STUN5 funktionierte bestenfalls in ausnahmen.
Am Ende habe ich mich dafür entschieden ein eigenes Gateway/Relay für Voptop zu programmieren. Das Ganze wollte ich auf Basis von „none blocking sockets“ machen und tat ich auch. Dafür habe ich die Sockets folgendermaßen zu nicht blockierend erklärt:

bool
CSockStream::setNoneBlocking() {
if (mSocket < 0) return false;

int flags = fcntl(mSocket, F_GETFL, 0);
if (flags == -1) return false;
flags = (flags | O_NONBLOCK);
return fcntl(mSocket, F_SETFL, flags) == 0;
}

Das ganze funktioniert auch wunderbar, so lange man es als Client <-> Client Anwendung auf dem eigenen Rechner laufen lässt, es funktioniert sogar noch hervorragend, wenn man es auf Rechnern im eigenen lokalen Netzwerk laufen lässt Aber wehe man versucht es über ein weniger transparentes und zuverlässiges Netzwerk (unser gutes altes Internet zum Beispiel). Da wird das Ganze quasi zum Flöhehüten. Das, was man sendet, kommt bestenfalls sporadisch so an, wie man es raus schickt. Gerne kommt es teilweise an, oder in mehreren Häppchen, von Zeit zu Zeit auch mal gar nicht. Wenn es darum geht, verschlüsselte Daten zu transferieren, ist das der Super GAU.
Ich habe mich letztlich entschieden quasi eigene „None blocking sockets“ zu entwickeln, einfach in dem ich zuvor prüfe ob das Lesen eines Sockets blockieren würde, und sollte es so seien darauf zu verzichten bis der Socket verspricht es nicht zu tun. Das Ganze habe ich mit folgender Methode gemacht:

bool
CSockStream::isSocketReady() {
bool             res;
  fd_set          sReady;
  struct timeval  nowait{};

  FD_ZERO(&sReady);
  FD_SET(this->mSocket,&sReady);
  memset((char *)&nowait,0,sizeof(nowait));

  select(this->mSocket + 1, &sReady, nullptr, nullptr, &nowait);
  if( FD_ISSET(this->mSocket,&sReady) )
    res = true;
  else
  res = false;

  return res;
}

Nur wenn mir diese Methode true zurückgibt und damit signalisiert das der Socket gelesen werden kann, ohne zu blockieren, wird von dem Socket gelesen. Auf die Art und Weise habe ich mir quasi lesende nicht blockierende Sockets programmiert, mit der Zuverlässigkeit blockierender Sockets.
Mittlerweile betreibe ich das ganze seit einigen Tagen auf einem Testserver sehr erfolgreich und kann das ganze bald mit einem neuen Release von Voptop komplett in die freie Wildbahn entlassen.

1) https://tools.ietf.org/html/rfc5245
2) https://www.voptop.com
3) https://libnice.freedesktop.org/
4) https://tools.ietf.org/html/rfc5766
5) https://tools.ietf.org/html/rfc5389

]]>
http://sn-media.com/de/blog/None blocking sockets/111http://sn-media.com/de/blog/None blocking sockets/111Tue, 16 Jun 2020 00:00:00 +0200
HP Elitebook 735 G5HP Elitebook 735 G5 frontSchon letztes Jahr im August habe ich mir ein neues Notebook zugelegt und mein altes Lenovo Thinkpad T61 in den wohl verdienten Ruhestand versetzt.
Dieses Mal wollte ich mir aber nicht einfach wieder ein Notebook zusätzlich zu meiner Workstation zulegen, sondern ein Notebook, das mein altes T61 sowie meine alte Workstation ersetzt. Die Kiste muss also schon ordentlich Power haben, denn moderne Entwicklungsumgebungen sind echte Ressourcen Fresser. Außerdem wollte ich zumindest auch einfache Spiele Zocken können. Meine Zockerzeit ist zwar längst vorbei, aber von Zeit zu Zeit überkommt es mich dann doch.
Ferner brauch ich auch durchaus Rechenleistung für das, was ich so programmiere. Für Voptop¹ zum Beispiel muss ich Video und Audiostreams live encodieren, verschlüsseln und das ganze auch noch debuggen können. Außerdem sind Dinge wie statische Codeanalysen und Memory-Leak Erkennung wahnsinnig rechenintensiv. Darüber hinaus hab ich mir schon vor Längerem angewöhnt, meine Rechner und Notebooks massiv überzudimensionieren und die Geräte dafür dann sehr viel länger einzusetzen. Die meisten Leute ersetzen ihre Geräte maximal in einem zwei Jahres Rhythmus, ich mache das viel seltener. Ich scheue einfach den Aufwand des Einrichtens, das dauert bei Entwicklerrechnern schlicht ewig und bis dann mal wieder alles installiert und eingerichtet ist, vergeht gut und gerne die ein oder andere Woche. Außerdem finde ich es auch ökologischer, das ist quasi mein Beitrag gegen die Wegwerfgesellschaft ;-).
Finanziell lohnt es sich übrigens nicht direkt, man gibt einfach durch die Überdimensionierung bei der Anschaffung so viel mehr aus, wie man sonst durch die wiederholte Anschaffung ausgeben würde. Sparen tut man erst dann, wenn man seine eigene Arbeitszeit des turnusmäßigen Neueinrichtens berücksichtigt.
Ein weiteres Selektionskriterium war für mich, das ich das Notebook auf einer Dockingstation betreiben kann. Ich will einfach nicht jedes Mal, wenn ich zuhause bin zuerst Kabel verlegen und in mein Notebook stöpseln müssen, damit es an einer vernünftigen Tastatur, Maus und einem Monitor hängt.
Ein weiterer wichtiger Punkt bei der Anschaffung meines neuen Notebooks war dessen Größendimension. Ich wollte gezielt ein Notebook, das klein genug ist, um es überall mit hinzunehmen, und gerade noch so groß ist, dass man ordentlich daran arbeiten kann. In meinen Augen entspricht das genau der 13 Zoll Display diagonale. Alles was größer als 13 Zoll ist, empfinde ich als zu groß um es immer dabei zu haben und alles was kleiner ist, verunmöglicht das arbeiten.HP Elitebook 735 G5 keyboard
Ursprünglich hatte ich damit geliebäugelt mir wieder ein Lenovo Gerät anzuschaffen, damit habe ich beste Erfahrung gemacht. Meine Lenovo T61 habe ich im Jahr 2008 gekauft, bis ins Jahr 2018 im Gebrauch gehabt und war durch die Bank weg zufrieden damit. Auch die Docking Lösungen von Lenovo fand ich bisher immer Super. Nur aus einem Grund ist es letztlich kein Lenovo Gerät geworden, Lenovo hatte zum Zeitpunkt meiner Kaufentscheidung kein einziges Notebook mit AMD Ryzen 2700² CPU im Angebot und ich wollte gezielt keinen Intel CPU kaufen, ich halte die Ryzen CPU’s für deutlich besser. Abgesehen davon unterstütze ich gerne AMD, einfach um der Marktmacht von Intel etwas entgegen zusetzen.
Dell Notebooks kamen auch nicht in Frage, zum einen weil auch Dell nichts Adäquates mit AMD Prozessor hatte und zum anderen, weil ich mit Dell eher weniger gute Erfahrung gemacht habe. Bisher sind bei mir alle Dell Notebooks unmittelbar nach Ende der Garantie defekt gegangen (meist die Kühler).
Neben HP gab es dann noch Schenker. Schenker finde ich grundsätzlich interessant, einfach weil es ein deutscher Hersteller ist. Schenker hatte (und hat bis heute) nichts mit AMD Prozessoren im Portfolio, damit war Schenker dann auch raus.
Zum damaligen Zeitpunkt der einzige Anbieter am Markt mit Notebooks, die durch einen aktuellen AMD Prozessor angetrieben wurden, war HP. Zu allem Überfluss hatte HP auch mit AMD Prozessor angetriebene Notebooks im 13 Zoll Format und zu diesen Notebooks auch noch vernünftige Dockingstations. Mein Glück perfekt machte dann noch die Tatsache das HP die Geräte als Geschäftskundengeräte mit „Next Business Day“ Garantie anbot, in Kombination mit einer Garantieverlängerung auf 5 Jahre. Der einzige Wermutstropfen war, dass es die Geräte nicht mit einer ordentlichen Festplatten Kapazität gab. Das Maximum waren 256 GB als PCIe® SSD, was für ein Notebook neben einer normalen Workstation irgendwie OK wäre, aber nicht für einen Desktop Ersatz, und immer externe Laufwerke wollte ich auch nicht mit mir rum schleppen. Also habe ich mir gleich noch eine 2 TB große PCIe® SSD bestellt und ein Arbeitsspeicher Upgrade auf 16 GB RAM (WICHTIG: Auf zwei RAM Module aufteilen, das steigert die Performance enorm!), denn ausgeliefert werden/wurden die Notebooks mit nur 8 GB RAM, auch das ist für moderne Entwicklungsumgebungen eher unterdimensioniert. Geordert habe ich dann letzten Endes das HP Elitebook 735 G5.
Bisher bin ich alles in allem sehr zufrieden mit dem Gerät. Ich habe direkt nach Erhalt die größere SSD und den größeren Arbeitsspeicher eingebaut sowie das Windows 10 durch eine Linux Distribution ersetzt. Die Hardware wird bei mir unter Linux einwandfrei erkannt und für die Grafikkarte habe ich die AMD - Grafiktreiber³ für Linux installiert.
Allerdings muss ich erwähnen, dass ich tatsächlich bereits einen Garantiefall hatte. Nicht aber weil Hardware defekt war, sondern weil das UEFI nach einem Upgrade gestorben ist und das Gerät damit „gebricked“4 war. Das ganze lief ausgesprochen unproblematisch ab, ich hab bei HP angerufen und HP hat mir am Folgetag einen Mitarbeiter vorbeigeschickt, der mir kurzerhand das Mainboard in meinem Notebook austauschte.

1) Voptop
2) AMD Ryzen 2700
3) AMD - Grafiktreiber
4) Bricked

]]>
http://sn-media.com/de/blog/HP Elitebook 735 G5/97http://sn-media.com/de/blog/HP Elitebook 735 G5/97Thu, 14 Mar 2019 00:00:00 +0100
Umsetzung der DSGVO im UnternehmensalltagWar Heute bei einem meiner größeren Kunden (Konzern mit ca. >2000 Mitarbeiten) und wie alle Unternehmen, muss auch hier der DSGVO Rechnung getragen werden. Dafür kamen die auf die wahnsinnig clevere Idee, ein Stück Software (Fremd-Script) einzusetzen das auf jedem Internetauftritt des Konzerns eingebunden werden soll, mit dessen Hilfe sich der User dann anzeigen lassen kann, welche Cookies so gesetzt werden.
Das Skript kommt von einem amerikanischen Unternehmen.... Ich fasse noch mal zusammen: Zur Umsetzung der europäischen DSGVO wird ein Fremd-Script einer amerikanischen Firma (natürlich bei denen gehostet) auf jeder Webseite eingebunden und mit aufgerufen... um der DSGVO Rechnung zu tragen... kann man sich gar nicht ausdenken so was...

]]>
http://sn-media.com/de/blog/Umsetzung der DSGVO im Unternehmensalltag/92http://sn-media.com/de/blog/Umsetzung der DSGVO im Unternehmensalltag/92Wed, 24 Oct 2018 00:00:00 +0200
UEFI MisstIch habe mir kürzlich ein neues Notebook gekauft, von HP ein Elitebook 735 G5 mit AMD Ryzen 27000 CPU. Auf dem Gerät war Windows 10 Pro vor installiert, das ich auch haben wollte, primär arbeite ich aber unter Linux. Ich musste mir also zusätzlich noch ein Linux parallel installieren. Standardmäßig ist in dem Gerät eine 256 GB PCIe NVMe SSD verbaut. 256 GB sind für zwei Betriebssysteme samt jeweils vollständig installierter Entwicklungsumgebungen zu wenig, weshalb ich eine größere Festplatte verbaut habe (eine PCIe NVMe SSD von Samsung mit deutlich mehr Kapazität).
Um Windows 10 Pro auf der neuen Platte nicht neuinstallieren zu müssen wollte ich den Inhalt der alten SSD via „dd“¹ vollständig auf ein USB-Laufwerk sichern, dann die neue Samsung SSD einbauen und die Sicherung wieder via „dd“ auf die neue Platte rüber kopieren. Damit fing dann der Ärger an.
Zunächst musste ich das UEFI davon überzeugen von meinem USB-Stick zu booten, dafür war es erst einmal nötig „secure boot“ auszuschalten. Mit ausgeschalteten „secure boot“ konnte ich dann erfolgreich ein „Live Linux image“ booten, aber jeder Zugriff auf die SSD, um sie mit „dd“ zu sichern, wurde mit einer kryptischen Fehlermeldung verweigert. Nun dachte ich, das wird wohl an dem hoffnungslos veralteten „Live image“ (Ubuntu 14.04) liegen das mit Neuen PCIe SSDs möglicherweise nicht klar kommt und ich noch für meinen bootbaren USB-Stick benutzte. Ich hab nicht lang gefackelt und mir einen neuen bootbaren USB-Stick mit einem aktuellen Ubuntu angefertigt, aber das Problem blieb das gleiche.
Da ein neueres „Live Linux image“ das Problem nicht zu lösen vermochte, habe ich mich wieder in die untiefen des UEFI-Setups begeben, da habe ich das TPM-Modul deaktiviert und siehe da, jetzt konnte ich nicht nur vom USB-Stick aus booten, ich konnte auch von dem „Live image“ aus auf die interne SSD zugreifen und eine Kopie mittels „dd“ auf ein externes Wechsellaufwerk machen, so wie die Sicherung dann auf die neue SSD rüber kopieren.
Im nächsten Schritt habe ich dann mit dem gleichen „Linux live image“ die Windows Partition mithilfe von GParted auf ca. die hälfte der Größe der neuen SSD erweitert und dann im Anschluss auf dem restlichen freien Speicher ein aktuelles Xubuntu 18.04 installiert.
Die Installation von Xubuntu 18.04 verlief erst einmal völlig reibungslos, danach ging dann aber auch schon der nächste Ärger los. Bei diversen Neustarts hing sich das neue Notebook in aller Regelmäßigkeit beim Runter- und Hochfahren auf. Dabei ist die Kiste einfach eingefroren, weder gab es unter Windows einen Bluescreen, noch unter Linux eine „Kernel panic“². Ich ging erst davon aus, dass es möglicherweise an noch nicht korrekt installierten Treibern läge, und habe den passenden AMD Radeon Treiber³ von der AMD Webseite runtergeladen und installiert. Nach der Installation des Treibers und einem reboot sah soweit auch alles gut aus, der Treiber wurde korrekt geladen und ich konnte auch mittels „Steam“4 für Linux Spiele starten und laufen lassen (Hardware beschleunigt versteht sich). Die Ernüchterung kam dann nach dem nächsten Hochfahren, auf einmal wurde der Treiber nicht mehr geladen und Linux lief nur noch im VESA5 Modus. Ich spielte ein wenig in den Konfigurationen rum und merkte, das der Treiber mal sporadisch geladen wurde und mal nicht, ohne das ich zunächst dafür habe einen Grund ausmachen können. Ich nahm an, es läge möglicherweise am Treiber und installierte stattdessen den open source AMD Radeon Treiber, das Ergebnis war das gleiche, auch dieser wurde sporadisch mal korrekt geladen und mal nicht. Darauf hin fing ich an, im UEFI „rum zu spielen“, im Gedanken das Problem könnte hier liegen. Ich schaltete „secure boot“ und das TPM-Modul wieder ein; es half nichts. Nach einiger Zeit habe ich dann entnervt das UEFI in seine „Werkseinstellungen“ zurückversetzt (Was es meiner Meinung nach eigentlich schon war, denn mehr als „secure boot“ und das TPM-Modul habe ich nicht konfiguriert). Auf einmal wurde der Grafiktreiber korrekt geladen und das nicht mehr nur sporadisch. Beim Konfigurieren von „secure boot“ und dem TPM-Modul muss sich irgendetwas im UEFI-Setup „queer“ gelegt haben, dass mit dem harten Reset in die Werkseinstellung wieder grade gezogen wurde. Von nun an bootete das Notebook reibungslos und fuhr zumindest unter Windows auch korrekt runter. Nur unter Linux hing es beim Runterfahren für 10 Minuten, bis es sich dann ausschaltete (es hing beim Runterfahren der MySQL-Datenbank fest).
Irgendwann habe ich festgestellt, dass jeweils nach dem ich Windows gebootet habe, die Uhrzeit unter Linux nicht mehr stimmte und wenn ich Linux gebootet habe, dann die Uhrzeit unter Windows nicht mehr stimmte. Wie sich herausstellte beziehen beide Betriebssysteme ihre Uhrzeiten von einem Timeserver via NTP6 (was ja auch sinn ergibt) und stellten nach dem Booten und einloggen die Uhrzeit ein, aber nicht nur für sich, sondern systemweit in dem sie jeweils die Zeit im UEFI überschrieben. Das war wiederum für das aufhängen beim Runterfahren verantwortlich, und zwar durch ein Wechselspiel mit einer installierten MySQL Datenbank (da muss man erst einmal drauf kommen). Verursacht wurde die Misere weil systenmd7 den NTP daemon erst nach der MySQL-Datenbank startet, der NTP daemon hat dann seinerseits die Uhrzeit umgestellt, so das die MySQL-Datenbank in der Zukunft lief, was diese wiederum so aus dem Tritt brachte, dass sie beim Runterfahren festhing bis ein 10 Minuten timeout eingetreten ist und den MySQL Prozess beendet hat. Lösen konnte ich das Problem am Ende dadurch, dass ich das UEFI Passwort geschützt habe und somit dafür gesorgt habe, dass weder Windows noch Linux die Zeit im UEFI mehr überschreiben können.
Was ist das eigentlich für ein Rotz, dass ein Betriebssystem so einfach im UEFI rum schreiben kann? Wer hat sich diesen Misst nur ausgedacht? Das scheint mir dann alles doch keine so große Verbesserung zu den früheren BIOS Systemen zu sein, vor allem wirkt das alles sehr unausgereift und ich habe zweifel, ob sich daran sobald irgendetwas ändern wird. Auf mich macht es den Eindruck eines viel zu komplexen und damit fehlerträchtigen Systems.


1) dd
2) Kernel panic
3) AMD Radeon Treiber
4) Steam for Linux
5) VESA
6) NTP
7) systemd

]]>
http://sn-media.com/de/blog/UEFI Misst/90http://sn-media.com/de/blog/UEFI Misst/90Mon, 13 Aug 2018 00:00:00 +0200
Voptop Release - ManagementAktuell komme ich mal wieder zu quasi nichts da ich beruflich, wie privat extrem eingespannt bin, so das insbesondere meine persönlichen bzw. privaten Projekte weitestgehend auf der Strecke bleiben. Trotzdem bin ich kürzlich endlich und notgedrungenerweise mal wieder dazu gekommen etwas an meinem Projekt Voptop ¹ zu machen. Vor einiger Zeit kam mit Ubuntu 17.10 eine neue Ubuntu Version raus, die zwar zum Vorgänger binärkompatibel ist aber das OpenCV ² Framework auf eine neue Version angehoben hat. Das führte dazu, dass ich einige Anpassungen an Voptop vornehmen musste, dabei habe ich auch gleich die Gelegenheit genutzt und ein paar Fehler behoben. Insbesondere habe ich einen kleinen Tipp/Rechtschreibfehler an der Login - Schnittstelle behoben, was dazu führte, dass ich Anpassungen an allen Clients für alle unterstützten Betriebssysteme machen musste. Das Ende vom Lied war, das ich für alle Betriebssysteme neu bauen und paketieren musste.

Das bauen und paketieren mache ich derzeit manuell. Dafür habe ich für die jeweiligen Betriebssysteme virtuelle Maschinen, in denen werden die Binärdateien gebaut und dann paketiert. Den Bau- und Paketiervorgang muss ich derzeit für 3 Betriebssysteme und deren jeweilige Unterversionen machen, insgesamt 7 Installationspakete. Das Ganze ist vorsichtig ausgedrückt ansträngend und nervig und raubt mir wertvolle Zeit, die mir zum Entwickeln fehlt.

Lange rede kurzer Unsinn, ich werde wohl absehbar einwenig Zeit darauf verwenden müssen ein vernünftiges Release - Management für Voptop auf die Reihe zu bringen. Das ist im Falle von Voptop leider nicht gerade einfach, denn insbesondere die Barriere über Betriebssystemgrenzen hinweg ist nicht einfach zu nehmen.

Ich spiele mit dem Gedanken einen Jenkins ³ aufzusetzen, der automatisiert virtuelle Maschinen starte, sich mittels Script und SSH auf die virtuellen Maschinen verbindet, ein Update auf das „Source Repository“ 4 durchführt und auf der SSH - Konsole den Build Prozess sowie den Paketierungsprozess anstößt. Die fertigen Pakete können dann vom Jenkins ausgeführten Skript wiederum via SCP eingesammelt werden. Das klingt kompliziert und aufwendig, ist es auch.

Die skizzierte Lösung sollte zumindest mein Problem für alle auf Linux 5 basierende Betriebssysteme sowie für Haiku 6 lösen. Bei Windows sieht es dann schon wieder anders aus, denn zumindest bisher war unter Windows mit SSH nicht viel zu holen. Allerdings habe ich kürzlich gelesen, es gäbe jetzt mit Windows 10 auch die Möglichkeit einen SSH-Server auf Windows laufen zu lassen, das könnte wiederum die Lösung für dieses Problem sein. Aber selbst wenn ich es nicht schaffe einen SSH-Server unter Windows vernünftig zu betreiben, so hätte ich damit alle anderen Betriebssysteme abgehakt und müsste nur noch für Windows manuell bauen.

 

1) Voptop
2) OpenCV
3) Jenkins
4) Source repository
5) Linux
6) Haiku OS

]]>
http://sn-media.com/de/blog/Voptop Release - Management/86http://sn-media.com/de/blog/Voptop Release - Management/86Sun, 31 Dec 2017 00:00:00 +0100
Maven OutOfMemoryErrorHeute mal etwas aus der Kategorie, „Fehlermeldungen, die man nicht alle Tage sieht“. Ich arbeite der Zeit an einem größeren Java Projekt für einen Kunden, einer Webapp die in einem Tomcat deployed wird und aus vielen kleinen Teilprojekten besteht die via Maven gebaut werden. Die eigentliche Webapp wird dabei durch eine parent pom.xml gebaut, die ihres Zeichens auf die Teilprojekte verweist. Dabei kommt es immer wieder mal zu folgendem Fehler:

[ERROR] PermGen space -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError

Das ist im Grunde nichts anderes als eine „out of memory exception“. Der Maven Prozess kann standardmäßig nur eine gewisse Menge an speicher allozieren und die reicht nicht, um dieses Projekt zu bauen. Den Fehler hab ich an diesem Projekt das erste mal gesehen und musste ein wenig recherchieren um raus zu finden wie man Maven erlauben kann mehr Speicher zu allozieren. Das hier war dann meine Lösung (einfach in der Konsole eingeben, bevor man das Projekt baut):

set MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m

PS: Ich bin mir übrigens wohl bewusst, dass die Lösung des Problems in der URL zu finden ist. Da als Erstes nach zu schauen anstatt selbst zu recherchieren wäre aber viel zu einfach gewesen ;-).

http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError

]]>
http://sn-media.com/de/blog/Maven OutOfMemoryError/84http://sn-media.com/de/blog/Maven OutOfMemoryError/84Mon, 04 Dec 2017 00:00:00 +0100
Sony Xperia X CompactEndlich komme ich mal wieder dazu was für meinen Blog zu schreiben, die letzten Wochen waren durch die Bank weg ansträngend und stressig, ich bin quasi zu nichts mehr gekommen.
Schon vor fast zwei Monaten hab ich mir ein neues Smartphone zugelegt, nach dem der Akku meines in die Jahre gekommenen Nexus 4 von Google mehr und mehr den Geist aufgegeben hat und im Grunde nicht mehr über den Tag gekommen ist.
Die Suche nach einem neuen Smartphone hat sich als weniger einfach herausgestellt, als ich mir das gedacht habe. Eigentlich wollte ich nur noch Geräte direkt von Google kaufen (Nexus bzw. Pixel), um das Problem mit der schlechten Updatepolitik zu umgehen. Leider hat Google aber nur noch Smartphones mit Displaygrößen über 5 Zoll im Angebot, ich wollte aber unbedingt eines mit einem Display, das kleiner ist als 5 Zoll. Ich finde diese riesigen Displays einfach nur nervig, die Dinger passen in keine Tasche und kaum noch in die Hand, außerdem hat man beim Telefonieren das Gefühl sich ein Schneidebrätchen ans Ohr zu halten.
Das erste Auswahl Kriterium Größe hat damit schon einmal die Menge der infrage kommenden Smartphones massiv ausgedünnt. Dann fing der Spaß der Suche aber erst an, denn ich musste feststellen, dass die meisten kleinen Smartphones nur mit sehr leistungsschwacher Hardware ausgerüstet sind, die Dinger sind quasi überwiegend als „low budget“ Produkte konzipiert. Ich wollte aber ein Smartphone mit leistungsstarker Hardware und einem Display unter 5 Zoll, sowie idealerweise mit einem aktuellen Android-Betriebssystem. Bestenfalls sollte der Hersteller sein Gerät dann zu allem Überfluss auch noch halbwegs regelmäßig mit Updates versorgen.
Entschieden habe ich mich letztendlich für das „Sony Xperia X Compact“¹, das Gerät ist vernünftig ausgestattet und die Updatepolitik von Sony ist zumindest kein Totalausfall. Im „Sony Xperia X Compact“ ist ein Hexa-Core-Prozessor vom Typ „Snapdragon 650“² verbaut und dem Prozessor stehen 3 Gigabyte Arbeitsspeicher zur Verfügung, um seine Arbeit zu verrichten³. Der Akku des X Compact fasst 2700 mAh³, die in dem Gerät auch bei starker Nutzung leicht über den Tag reichen. Anfangs wurde das Gerät mit Android 6.0 ausgeliefert und dann mit Android 7.x via einem OTA4-Update nachgerüstet. Aufgeladen wird das „Sony X Compact“ über einen USB-Typ-C Stecker, was dank Schnellladefunktion in ca. 2 1/2 Stunden vonstattengeht. Ferner verfügt das kompakte Smartphone von Sony über einen Speicherkarten-Slot.
Besonders positiv muss man meiner Meinung nach die Kamera des „Sony Xperia X Compact“ hervorheben, bisher hatte ich noch kein Smartphone, das so gute Fotos machte.
Weniger positiv hingegen sind die vorinstallierten Apps von Sony, die man teilweise nicht einmal deinstallieren kann.

Fazit

Das „Sony Xperia X Compact“ erfüllt genau meine Bedürfnisse, es ist ausreichend schnell damit alle Apps ruckelfrei und zügig laufen, sowie ohne Verzögerung starten. Außerdem passt das „Sony Xperia X Compact“ leicht in jede Hosentasche, was mit den großen Geräten jenseits der 5 Zoll eher nicht mehr so richtig geht. Lediglich die vorinstallierten Apps, die man nicht deinstallieren kann, trüben das grundsätzlich gute Gesamtbild, dafür werden von Sony derzeit Updates ausgesprochen zeitnah bereitgestellt und ausgeliefert.

Anmerkung

Ich hab mir für mein „Sony Xperia X Compact“ gleich noch eine Lederhülle5 bestellt. Die Lederhülle ist durchaus auch empfehlenswert, gut verarbeitet und schützt das Gerät.

 

1) Sony X Comact
2) Snapdragon 650
3) Sony X Comact Spezifikation
4) OTA
5) Lederhülle

]]>
http://sn-media.com/de/blog/Sony Xperia X Compact/76http://sn-media.com/de/blog/Sony Xperia X Compact/76Thu, 13 Jul 2017 00:00:00 +0200
USB-Hub die X-teVor zwei Wochen war es mal wieder so weit, mein USB-Hub hat sich verabschiedet, dass passiert in aller Regelmäßigkeit, alle zwei bis drei Jahre im Dauerbetrieb gehen die Dinger bei mir kaputt.
Meinen USB-Hub betreibe ich am USB-Port meiner FRITZ!Box¹. An dem USB-Hub selbst betreibe ich zwei externe Festplatten, zwei Mikro-USB-Kabel zum Aufladen meines Tablets sowie meiner e-Zigarette und außerdem ein USB-Typ-C Kabel zum Aufladen meines Smartphones. Alle USB-Hubs, die ich bisher hatte, waren „aktiv“ dass bedeutet die USB-Hubs verfügten über ein externes Netzteil und wurden nicht ausschließlich durch die FRITZ!Box mit Strom versorgt. Warum die Dinger bei mir regelmäßig ihr Leben aushauchen, ist mir dabei unklar. Eigentlich mache ich damit exakt das, wofür sie da sind. Nun gut, es lässt sich ja nicht ändern, ich habe also wieder einen Neuen bei Amazon² bestellt. Der neue USB-Hub von Atolla³ entspricht bereits dem aktuellen USB 3.0 Standard und verfügt über sieben USB 3.0 Ports, darüber hinaus hat er einen achten „Auflade“ USB-Port. Der „Auflade“ USB-Port wird mit bis zu 2,4 Ampere betrieben und ermöglicht das Schnellladen von Akkus von zum Beispiel Smartphones. Angeblich soll der USB-Hub abwärts kompatibel sein bis USB 1.0, was ich aber nicht bestätigen kann. Meine FRITZ!Box kann mit dem USB 3.0 Hub nichts anfangen und meldet nur ein unbekanntes Gerät. An meinem Raspberrypi4 hingegen funktioniert der USB-Hub tadellos, mit dem Ergebnis das er jetzt am Raspberrypi hängt und nicht an der FRITZ!Box, so das mir mein Raspberrypi jetzt zusätzlich als NAS dient. Alls kleines zusätzliches Feature so zu sagen, hat der USB-Hub an jedem USB-Port einen Schalter, mit dem man die einzelnen USB-Ports ein und ausschalten kann.
Ein echtes Fazit habe ich zu diesem USB-Hub noch nicht, bisher gefällt er mir ganz gut, ob er aber auch nach zwei bis drei Jahren den Geist auf gibt weiß ich aber natürlich noch nicht.

1) FRITZ!Box 6360
2) Atolla USB 3.0 Hub 7
3) Atolla
4) Raspberrypi

]]>
http://sn-media.com/de/blog/USB-Hub die X-te/73http://sn-media.com/de/blog/USB-Hub die X-te/73Tue, 16 May 2017 00:00:00 +0200