Why 2018 won’t be the year of Linux on the desktop – again

The „Year of Linux on the desktop“ seems to be kind of a running gag. For years now, people have predicted that „this is going to be the year where Linux will win the desktop“. I (and others) think, this is not gonna happen in 2018. And I also assume that it won’t happen in 2019.

Before I start my rant about the reasons, let me state a few things. When I say „Linux„, I mean any Linux distribution out there. Fedora, Ubuntu, Arch – you name it. Also: I am a big fan of Linux myself. I’ve been using it since the days of Debian 2.something around 1998, and RedHat/Fedora has been my main desktop (and laptop) operating system for more than 15 years now. By all means I am a huge fan of the whole idea of Linus’s work and everything around it. Nevertheless, I don’t see it going anywhere further on the desktop.

Secondly, the reason for me writing about it now is the continuing dissatifaction around Apple and macOS (aka OS X). At work, I use a MacBook Pro with Retina display and I like the combination of hard- and software! But I hear many colleagues complaining about the ever-increasing price tag on the hardware. For their private hardware, quite a few are switching back to non-Apple choices. I for myself bought a Lenovo X1 Carbon instead of a MacBook Pro, only because of the price. And the experiences with Linux on this machine made me realize, why Linux is not working for the masses.

Here is an unsorted list of reasons which I think are at least part of the reason, why not even 2018 will be the year of Linux on the desktop. „Why 2018 won’t be the year of Linux on the desktop – again“ weiterlesen

A New Beginning

Heute war mein letzter Tag bei meinem derzeitigen Arbeitgeber, der it-motive AG. Nach über 4 1/2 Jahren sage ich „tschüss“ und möchte mich auch hier noch einmal für die vielen tollen Projekte bedanken, die ich mit meinen Kollegen und Kunden zusammen stemmen durfte. Es waren interessante und lehrreiche Jahre.

Trotzdem habe ich für mich beschlossen, einfach mal etwas neues zu machen. „A New Beginning“ weiterlesen

Google-Software doch für den A…

tl;dr
Shame on you, Google!
Eine defekte Software ignorieren und somit die Nexus-Handys für viele unbrauchbar machen!
Hier besteht massiver Nachholbedarf zum Thema „Kunden(un)zufriedenheit“!!!

=========

Die Ausgangslage

Die Google-Handys sind eine feine Sache. Nexus 4, 5 und 6 bieten ein hervorragendes Preis-Leistungs-Verhältnis und dass man immer die neueste Version des Android-Betriebssystems bekommt ist auch schick.

Als Bonus macht Google es einem erfreulich leicht, sein Handy zu rooten, das heißt, mehr Zugriff zu bekommen als man es von Werk aus hat. Dadurch wird es auch ermöglicht, ein alternatives Betriebssystem oder besser gesagt, eine andere Android-Version zu installieren. Darum soll es hier aber gar nicht primär gehen.

Das Problem

Hauptproblem im Moment ist, dass Google es geschafft hat, mit einem unumgänglichen Update die Hauptfunktion eines Telefons – das Telefonieren – unmöglich zu machen.
Konkret äußert es sich darin, dass bei Telefonaten einfach nix zu hören ist. Weder hört der Gegenüber mich, noch höre ich etwas vom Gegenüber. Dabei ist es egal, ob man anruft oder angerufen wird.

Dieses Problem tritt anscheinend sehr häufig bei Handys mit Cyanogenmod 11 (basierend auf Android 4.4.4) auf:
https://jira.cyanogenmod.org/browse/CYAN-5728
Aber auch komplett unmodifizierte Handys von Google scheinen an diesem Phänomen zu leiden:
https://productforums.google.com/forum/#!msg/nexus/j74JlShhihc/F2fUMFJHEDgJ
https://code.google.com/p/android/issues/detail?id=82949

Das Ärgerliche

Das eigentlich traurige an der ganzen Situation ist, dass Google dieses Problem in keinster Weise ernst nimmt und die Nutzer mit ihrem praktisch defekten Handy alleine lässt! In meinen Augen ist das ein massives Problem, welches anscheinend einfach noch nicht breitgetreten wurde, um bei Google eine höhere Priorität zu bekommen! Daher hoffe ich, dass dieser Beitrag einen kleinen Anschub in die richtige Richtung bringt!

Java, Maven, JBoss AS, Windows – eine unheilvolle Kombination

So … wie vielleicht schon aus einigen meiner letzten Beiträge erkennbar geworden ist, bin ich eigentlich kein großer Fan des Betriebssystems „Windows“. Während es für viele Nutzer vielleicht eine gute Wahl sein mag, ist es für Softwareentwickler (die nicht unbedingt Windows-Anwendungen entwickeln) schon nicht mehr optimal. Aber was gar nicht geht: Windows als Server.

Mit genau einem solchen Server hatte ich nämlich heute einige Stunden lang Spaß. Man nehme ein Maven-Projekt, in dem es einen Sourcepfad /src/main/java/de/test/meinProjekt/ gibt. Darunter hat man Klassen, alles ist gut, alles funktioniert.

Jetzt nehme man an, es werden Dateien in das Package/Verzeichnis /src/main/resources/java/de/test/meinprojekt/ gepackt. Sieht nach harmlos aus, ist aber katastrophal! Wer findet den Fehler?

Genau: das große „P“ im ersten Pfad funktioniert gut, solange man keinen gleichlautenden Pfad mit anderer Groß-/Kleinschreibung im Parallelverzeichnis hat. Durch diese kleine Unaufmerksamkeit ist die gesamte Applikation beim Starten im JBoss nämlich mit einer total zusammenhangslosen Fehlermeldung gar nicht erst gestartet. Es scheint, als beachte der Classloader des JBoss‘ das Casing der Pfade/Packages, was ja auch richtig ist. Im entstandenen Archiv, welches von Maven unter Windows zusammengebaut wurde, stehen die Sachen aber alle im gleichen Ordner mit kleinem „p“. Deswegen werden sie vom Classloader nicht gefunden.

Fiese Sache!

Zu meiner Verteidigung: der Package-Namen mit dem großen P stammte nicht von mir. Ich würde sowas doch niemals tun … *hüst*

IntelliJ 13.1 und SVN 1.8 (auf Windows)

Heute habe ich einige Zeit damit zugebracht, IntelliJ Idea 13.1 mit unserem Subversion ans Laufen zu bringen. Offensichtlich gibt es einige Bugs, die die Zusammenarbeit mit SVN 1.7 leider erheblich erschweren.

Eine der Möglichkeiten, diese Problematik zu umgehen ist, einfach einen Kommandozeilen-Client für SVN zu nehmen. IntelliJ kann diesen direkt einbinden (Settings -> Version Control -> Subversion -> General -> Use command line client). Unter Windows kann man hierfür zum Beispiel das Binary von SlikSVN nehmen. Damit hat man dann ein SVN-Binary, das man dort nutzen kann. Außerdem ist – bei aktuellem SVN – auch direkt eine Working Copy in Version 1.8 möglich.

Fast.

Denn ab jetzt kommt bei jedem Commit die Fehlermeldung „Could not Commit: wrong revision“ (oder so ähnlich). Komisch … direkt mal untersucht: Commit wurde erfolgreich durchgeführt, Working Copy ist auch korrekt, trotzdem schmeißt IntelliJ diesen Fehler?

Ein wenig auf der Kommandozeile (aka: DOSBox) rumgespielt, den Quelltext der entsprechenden IntelliJ-Klasse angeschaut und dann dämmerte es so langsam …

Beim Nutzen des SVN Kommandozeilen-Clients wird die Rückgabe nach einem Commit geparst, um die neue Revision zu bestimmen. Anscheinend wird dabei angenommen, dass das Programm immer auf Englisch läuft und die Ausgabe daher „Committed revision 123“ lautet. SlikSVN installiert jedoch standardmäßig auch Übersetzungen mit – die Meldung lautet daher „Revision 123 übertragen“. Dies kann IntelliJ nicht korrekt interpretieren, deswegen wird die Fehlermeldung geschmissen. Also einfach die Übersetzungen von SlikSVN deinstallieren, dann klappt auch diese Kombination.

Ich weiß nicht, ob dies nur bei nicht-englischen Windows-Systemen auftritt, aber zumindest ist es etwas, was mich heute geschlagene drei Stunden meiner Zeit gekostet hat!