Donnerstag, 4. Januar 2024

Erfahrungen mit einem Linux Laptop Aura von Tuxedo

Motivation

Seit ueber 15 Jahren benutze ich Macbook Pros. Brilliante Laptops mit gut funktionierender Software, OS und einem Paketmanager. Ein Premium-Produkt zu einem Premium-Preis Seit mehreren Jahren bin ich sehr frustriert, die Qualitaet sowohl der Hardware als auch des OS wurden immer schlechter. Am meisten stoerten mich die defekten Keyboards (und es gab da noch andere Probleme, Display, Akku, Ladegeraete, Camera, Controller, fehlschlagende OS Upgrades) und die immer fragwuerdiger werden OS Features. Es wurdeZeit etwas Neues zu probieren. Also auf gehts, Linux heisst der Kandidat. Mal wieder.

 Mein Linux Laptop ist ein Tuxedo Aura 15 Gen 1. Die Aura Serie ist die guenstigste Serie von Tuxedo. Der Preis lag unter 1T Euro also kein Premium-Geraet.

Hardware Details: 

  1. AMD Ryzen 7 4700U, Mobile CPU mit 8 Kernen und Boost
  2. 16 GB RAM

Als OS benutze ich das Standard Tuxedo OS 2. Dabei handelt es sich um ein Ubuntu 22 mit KDE, Plasma, dem Tuxedo Control Center und einigen Design Anpassungen, alles sehr nett.


Meine Erfahrungen nach einem halben Jahr intensiver Nutzung.

Positiv:

  1. Das Meiste funktioniert gut, nicht perfekt aber gut.
  2. Tastatur funktioniert gut, im Gegensatz zu Tastaturen bei diversen Apple Macbook Pros
  3. Akku kann ueber den mitgelieferten Charger oder USB-C geladen werden, alte Macbbok Netzteile funktionieren. Die Kapazitaet ist nicht ueberragend aber gerade noch OK.
  4. Schnelle Versorgung mit Software Updates, Ubuntu sei Dank.
  5. Gutes WIFI 6, schnell und stabil
  6. Bluetooth: stabiler Verbindungsaufbau
  7. Ausreichend Rechenpower
  8. Gute Lueftersteuerung, viel besser als auf meinem Lenovo mit Windows.
  9. Die Kamera ist nur OK, 1280*720, besser als die im Lenovo aber schlechter als die eines MacBook Pro.
  10. Tux-Taste -  meine Frau findet sie niedlich.
  11. Touchpad is gut.
  12. SD Card Slot, HDMI Port, Ethernet Port, ausreichend USB-A Schnittstellen.
  13. Modularer Aufbau, interne Komponenten koennen getauscht werden.
  14. Tuxedo stellt Ersatzteile bereit.
  15. Tuxedo Support
     

Negativ:

  1. Der Ton aus den Stereo Lautspraechern ist fruehe 90er
  2. Die Farben und die maximal Helligkeit des Display sind so lala, bei der Softwarentwicklung ist das kein Problem.
  3. Der Akku hat nach einem halben Jahr nur ein Heath-Wert von 74%, das ist miess. Einer der Gruende koennte sein, dass das optimierte Laden im Bios nicht aktiviert war. Tuxedo hat mit dem neuen Control Center hier wohl nachgebsssert.
  4. Bluetooth fuehrt manchmal zu Problemen beim Aufwachen.
  5. Luefter wenn sie voll laufen, was selten ist, sind dann laut.
  6. Die Tasttaturbeleuchtung vergisst machmal die Einstellungen.
  7. Dis Tastatur hat keine abgesetzten Pfeiltasten. Man kann die Pfeiltasten nicht greifen ohne auf die Tastatur zu schauen.
  8. Ein Fingerprint Sensor ist vorhanden wird aber nicht unterstuetzt
  9. Bruch in der Body Oberschale, weil eine Schraube sich auf der Unterseite geloest hatte.
  10. Nur eine USB-C Schnittstelle.

Fazit:

Der Tuxedo Aura 15 Gen 1 ist eine gutes Arbeitstier mit einem gut funktionierenden Linux Desktop zu einem guten Preis aber mit ein paar Macken und Maengeln. Teilweise gehen sie (Display) auf den guenstigen Preis zurueck. Ist er besser als mein Lenovo, ja, ist es besser als ein MacBook Pro, nein, wuerde ich mir wieder einen Tuxedo Aura kaufen, wahrscheinlich. Das Gesamtpaket aus preiswerter und solider Harware, Software und Preis sind durchaus gut. Vor allem wuensche ich mir ein verbessertes Tatstatur-Layout fuer die Pfeiltasten und bessere Lautsprecher. Ein bisschen erinnert mich der Tuxedo Aura an die Polycarbonat MacBooks.


Freitag, 22. Dezember 2023

Low Level IT Sicherheit fürs Handy

 

Diese kleinen USB-Adapter, hier die von Porta Pow, schützen dich und dein Handy vor Angriffen beim Laden. Die Ladebuchse ist ein von Benutzer unterschätztes Einfallstor. So kann man sein Handy auch an unsicheren Orten sicher Laden. Das Laden des Handies ist möglich, Datenübertragung aber nicht.

Die Ladegeschwindigkeit sinkt auf den Normalwert, d.h. schnelles Laden ist nicht möglich.

Mittwoch, 13. September 2023

JMeter never gets old


 

 Now it's much simpler to run system test or load and performance test. You can integrate the good old JMeter into Maven and run the test in the build pipeline. Great.

Biggest advantage: You don't a JMeter installation. JMeter is loaded and run as Maven plugin.

 

Look at the https://github.com/jmeter-maven-plugin/jmeter-maven-plugin




Dienstag, 20. Juni 2023

The outcome of tech debt.

 

Es gibt zwei Gründ für Software Bugs

  1. Tech debt
  2. Komplexität

Komplexität ist auch nur eine Form von Tech debt. Baue technische Schulden ab sonst errecihst den Softwarestand wo die ganze Entwicklerkapazität für das Fire Fighting aufgezerrt wird und es keine Resourcen für die Weiterentwicklung gibt. Dann ist die Software tot.

Technische Schulden sind ein oder sogar der Grund für Fehler.

Sonntag, 7. Mai 2023

ChatGPT ist keine kuenstliche Intelligenz (KI)

ChatGPT ist keine kuenstliche Intelligenz sondern eine praechtiges Beispiel fuer maschine learning und Computer Linguistik. Jedem Informatiker ist das klar.

 

Um das zu illustrieren, hier ein lustiger Chat mit ChatGPT. Der Chat ist nicht von mir, er wurde mir aus vertrauenswuerdiger Quelle zugeschickt und hat sich Anfang Mai 2023 ereignet. 


Und weiter gehts.


Und zu guter letzt.


Wer jetzt ChatGPT fuer intelligent haelt, tja dann weiss ich auch nicht mehr.

Donnerstag, 2. Februar 2023

Managing Dependencies for Micro Services

Dependency Hell, das kennen viele Softwareentwickler oft aus mature Projekten. Was bedeutet das fuers Projekt?

  1. Es kann nicht auf aktuelle Versionen von Libs migriert werden, Java eingeschlossen. Dadurch bleiben nuetzliche Funktionen verschlossen.
  2. Das Projekt ist statisch wie Beton und nur unter sehr grossem Zeitauswand aenderbar.
  3. CVEs koennen nicht behoben werden.

Um Dependencies effiktiv zum meisten und obige Schwaechen zu umschiffen, hier ein paar Best Pracices im Umgang mit Dependencies.

  1. Goldene Regeln
    1. Less is more
    2. Convention over configuration
  2. Versuche mit moeglichst wenig Konfigurationen auszukommen.
  3. Versiuche moeglichst wenig Dependencies zu benutzen.
  4. Benutze Parents wenn moeglich.
  5.  Benutze Dependeny Management (Maven) wenn es moeglich ist.
  6. Benutze nur fixe Versionen von Libs wenn sie nicht im Parent verfuegbar sind.
  7. Wenn du Excludes/Includes brauchst z.B. um CVEs zu fixen, dann hinterlasse einen entsprechenden Kommentar mit der CVE Nummer. So kann diese Konfiguration spaeter sehr einfach entfernt werden.
  8. Update regelmaessig deine Dependencies um keinen Wartungsstau aufkommen zu lassen. Du kannst leicht einen Check Step in der Build Pipeline einbauen die dir Anzahl der outdated Libs ausgibt.
  9. Aktuelle Libs verbessern die Sicherheit, aktuelle Libs haben weniger CVEs. 
  10. Pruefe ob Dependencies noch benutzt werden
    1. Grep isy dein Freunf fuer Compile Scope Dependencies: grep -r com.strange-package src/
    2. Organize your imports
  11. Das Build file ist genauso ein Teil deines Softwareprojetes wie der Code selbst.

 

Dienstag, 3. Januar 2023

Model Driven Architecture ist tot

 Model Driven Architecture (MDA) und alle Verwandte sind seit den fruehen 2000er tot. Trotz viel Energie, Enthusiasmus, Zeit und Geld die in MDA Projekte geflossen sind, gibt es zwei Erkenntnisse: MDA ist sicher tot und UML ist sinnvoll zur Beschreibung von Software-Konzepten.

Weil es scheinbar zu wenige Senior Software Developer gibt, gibt es Heute MDA Zombies. MDA ist von den Toten auferstanden in Form der Generierung von Klasssen aus YAML Schnittstellenbeschreibungen die dann z.B. über Micro Services geteilt werden.

Bei genauerem Hinsehen sieht man, dass dieser Ansatz auch nicht funktioniert. Er hat folgende Nachteile:

  1. Aenderungen an der Schnittstelle fuehren zu aufwendigen Abstimmungsprozessen die multiple Teams, oft das ganze Projekt, einbeziehen. Das ist sehr, sehr teuer.
  2. Kein Team ist in der Verantwortung, shared  whatever sind gut Beispiele fuer Verantwortungsdiffusion.
  3. Selbst wenn ein Team Zeit fuer die Wartung aufwenden moechte, so werden die Kommunikationskosten zur Aufgabe fuehren.
  4. Weil sich die Softwareanforderungen aendern die Schnittstelle aber in Beton gegossen ist, fangen die Entwicklerteams an der 'offizielle' Schnittstelle vorbei zu arbeiten. Sie haben gar keinen anderen Weg.

Was lernen wir daraus:

  1. MDA in allen Varianten ist teuer und ineffizient.
  2. MDA ist das Gegenteil von agiler Softwareentwicklung .
  3. Share Nothing ist und bleibt eine Grundlage fuer agile Softwareentwicklung
  4. Die Entwicklung von (shared) Bibliotheken ist deutlich anders zur Entwicklung normaler Micro Services.