programmierer-nachrichten.de
Startseite Podcast RSS Impressum

Intel Skyle und Kabylake Hyperthreading fehlerhaft


In der Debian Mailing-List wurde darauf aufmerksam gemacht, dass Intel Prozessoren der 6. und 7 Generation, also Skylake und Kabylake, einen Fehler enthalten, der bei aktiviertem Hyperthreading zu unerwarteten Fehlverhalten führen kann.

Solange man also kein Update einspielt, wird empfohlen Hyperthreading zu deaktivieren. Das Update muss in Form einer BIOS- oder UEFI-Aktualisierung eingespielt werden. Um zu erfahren, ob es bereits Updates gibt, kann man die Website des Mainboard Herstellers konsultieren. Meine Erfahrung ist aber, dass solche Updates vergleichsweise spät kommen. Das liegt sicher auch daran, dass man bei einem BIOS- oder UEFI-Update nicht viel falsch machen will, da man riskiert das Board zu "bricken" (, auch wenn das immer unwahrscheinlicher wird). Unter Linux hat man für gewisse Varianten der CPU auch die Möglichkeit ein Package zu installieren, welches den Fehler im Microcode korrigiert.

Relevante Dokumente:

Alle relevanten Errata-Nummern: SKZ7/SKW144/SKL150/SKX150/KBL095/KBW095

Der Fehler ist bei Intel schon seit April 2017 bekannt und es gibt auch Korrekturen dafür. Man muss sie nur irgendwie installiert bekommen.

Aufgefallen ist der Fehler bei den Entwicklern des OCaml Compilers aber schon Anfang des Jahres. Einer der OCaml Entwickler, Mark Shinwell, hatte Intel kontaktiert, aber Intel hatte sich nicht gemeldet.


Podcast Folge 19.1 (Sonderfolge)


Ich hatte heute tatsächlich etwas Langeweile und dabei ist dann folgende Aufnahme entstanden:

Hier der Text dazu:


Hier spricht Andreas Schipplock.

Wenn du diese Nachricht hörst, wird gute Software vermutlich schon ausgestorben sein. Alles, was du vorfindest, sind Abstraktionen auf Abstraktionen auf Abstraktionen. Die Welt wird nicht mehr verstehen, wieso etwas funktioniert, wie es funktioniert. Electron, Electron, Electron. JavaScript, Transpilieren, Masturbieren, Typescript, Elm, React und Angular. Die Perversion Dinge zu stapeln, nimmt kein Ende mehr und scheint immer verrücktere Formen anzunehmen.

Du als Programmierer hast die Pflicht diesen Fehler zu korrigieren.

Besinne dich auf das, was wirklich wichtig ist. Das herauszufinden ist nicht einfach, aber auch nicht unmöglich.

Folge nicht den Menschen mit den Geldscheinen in der Hand. Bringe dich nicht in Situationen, die dir unangenehm werden können. Sage niemals "in 10 Minuten bin ich fertig". Mach bitte niemals einen auf Scotty. Und mache niemals spontane Aussagen zu Zeitschätzungen. Nimm dir Zeit, analysiere und antworte später.

Und die wichtigste Regel ganz zum Schluss. Dokumentieren!

Du kommst in die Hölle der Webentwickler, in der du kostenlose Websites für Vereine erstellst, wenn du nicht dokumentierst. Und vergesse nicht zu testen!

Und eine Ausnahmeregel ist noch viel wichtiger als alle anderen. Dein Privatleben hat immer höchste Priorität.

Memo ende.


Vielleicht ist der Text nicht ganz ernst, aber einige Dinge davon sind mir schon sehr wichtig. Letztendlich ist es aber nur aus Langeweile entstanden :).


Podcast Folge 19


Wie versprochen der wöchentliche Podcast!

Dieses Mal Folge 19. In dieser Folge beschalle ich dich mit folgenden Themen: Debian GNU/Hurd 2017 veröffentlicht, Boris Kraut gibt F-Droid auf, Unsinnige Versprechen, Kein App Store mehr für Android 2.1, D wird bei GCC inkludiert, Erlang/OTP 20.0 veröffentlicht, Teamarbeit ist geil!, Firefox 56 nun auch mit Headless Mode, Gitlab 9.3 veröffentlicht, Wer hat den meisten Code?

Achja, und Tesla hat Chris Lattner entlassen. Das war mir so unwichtig, dass ich es glatt vergessen hatte, aber ist auch gar nicht so schlimm; ich habe eh die Zeit gerissen! :)

Viel Spaß damit!


Wer hat den meisten Code?


Ich will auch gar nicht lange rumlabern. freecodecamp.com hat sich Mühe gegeben und eine nette Grafik angerfertigt, die zeigt, wie viele Zeilen Code ein Projekt hat.

Unix 1.0 hatte etwas mehr als 30k Zeilen Code, Photoshop 1 hatte etwas über 100k Codezeilen, die Quake 3 Game Engine etwas über 300k Zeilen, Windows NT 4.0 schon über 11 Mio. Zeilen, Windows 2000 schon um die 28 Mio. Zeilen, Microsoft Office 2013 beinahe 45 Mio. Zeilen, OS X 10.4 um die 85 Mio. Zeilen, usw...die Zahlen sind irre! Ich hatte ja keine Vorstellung! Aber was noch interessanter ist, sind die Zahlen von Google. Google soll Software haben, die zusammen unglaublich viele Zeilen Code haben soll. Ob diese Auswertung irgendeine Relevanz hat, kann ich nicht sagen, da sie am Ende die gesamte Software eines Unternehmens auflistet und vorher immer nur einzelne Produkte. Das ist natürlich an sich schon falsch, aber egal. Ich glaube, wir sind uns einig, dass Google vermutlich viele Zeilen Code produziert. Wobei, Android selber soll nur ca. 12 Mio. Zeilen Code haben (exklusive Linux).

Wie auch immer; ob die Werte nun stimmen oder nicht; wenn die Tendenz stimmt, dann war es für mich dennoch interessant. Ich hätte nicht gedacht, dass einige Produkte soviele Zeilen Code haben. Vor allem Office 2013 hatte mich überrascht. Noch jemand Bock eine eigene Office Suite zu entwickeln? ;)

Und was ich mich gerade frage: heißt das jetzt, dass viele Zeilen Code gut sind? Unix v1 hatte nur etwas über 30k Zeilen Code. Was ist passiert, dass ein Betriebssystem wie OS X auf einmal 85 Mio. Zeilen Code haben muss? Ist OS X nun besser?

Als Microsoft und IBM noch zusammengearbeitet hatten, gab es innerhalb der beiden Firmen Konflikte. IBM hatte zur Messung der Produktivität bei den Entwicklern die Anzahl der produzierten Zeilen herangenommen. Bei Microsoft war es gegenteilig. Bei Microsoft waren die Entwickler der Meinung, dass effizienter und kurzer Code der bessere Weg sei. Verrückt. OS/2 ist gescheitert; Windows...nun, man kann von einem Erfolg sprechen, auch wenn viele das vermutlich nicht wahrhaben wollen.

Ich persönlich denke, dass die Anzahl der Zeilen als Kriterium für die Produktivität völlig ungeeignet ist. Da ist man sich wohl mittlerweile einig. Wenn ich aber "wenige Zeilen" und "effizient" lese, denke ich direkt an "genialen" Code. "Genialen" Code will im Grunde auch niemand, aber das ist dieses Mal nicht das Thema :).

Mehr Zeilen? Weniger Zeilen? Weder noch! Ich sage: bessere Bewertbarkeit! Weniger Vererbung! Mehr Komposition!


Gitlab 9.3 veröffentlicht


Gitlab 9.3 wurde veröffentlicht und wieder mal wurden neue Features gepushed. Gitlab, das ist dieser Github "Clone", der mehr Features haben soll als Github. Ich war vor einigen Wochen so angetan von all diesen Lobpreisungen über Gitlab, dass ich tatsächlich versuchte all meine "Seitenprojekte" zu Gitlab umzuziehen.

Als ich meine Projekte nach Gitlab umzog, fielen mir während der ersten 8 Stunden direkt mehrere Bugs auf. Diese Fehler waren so unglaublich nervig, dass ich direkt einen Bug-Report eingestellt hatte, nach dem ich sicherstellte, dass diese Fehler vor mir noch niemand gefunden hat. Die Fehler waren tatsächlich ausschlaggebend, aber begleitend war das schlechte User-Interface von Gitlab.

Das mag aus Sicht von Gitlab nicht logisch sein, aber das UI von Gitlab ist einfach nur schlecht. Es ist inkonsistent, unstrukturiert und an jeder Ecke muss man das UI anders bedienen, oder man macht Fehler. Bei uns in der Firma wird auch Gitlab genutzt, aber ich glaube nur, um die Nutzer und Berechtigungen zu vereinfachen. Ich persönlich kenne ja auch seit Jahren das UI von GitHub und man kann über GitHub sagen, was man will, aber das UI ist grandios. Es ist an keiner Stelle unverständlich. Ich mag zwar GitHub als Firma nicht unbedingt, vor allem wegen dieser Sexismus Geschichten innerhalb der Firma (darfst du gerne mal "googlen" -> "github scandal"), aber technisch und bezogen auf das UI ist GitHub imho ungeschlagen. Die Benutzer-Experience (hallo deki) ist imho wirklich extrem gut. Jeder Idiot kann GitHub bedienen. Das ist keine Beleidigung, sondern ein Lob.

Aber was an dieser Sache mehr nervt ist, dass ich bei GitLab das Gefühl hatte eine unfertige Software zu bedienen und das sorgte bei mir dazu, dass ich das Vertrauen darin verlor. Das ist ein kritischer Zeitpunkt bei einer Software. Wenn eine Software angenommen werden möchte, so sind die ersten Erfahrungen die wichtigsten. Und als ich unsicher wurde, habe ich mich genauer bei Gitlab umgesehen und die Kritik an das Produkt sind mittlerweile ungehalten. Viele Benutzer fordern Stabilität. Viele User haben bemerkt, dass Gitlab mehr und mehr Features raushauen will. Das geht teilweise so weit, dass Nutzer in ihrem Workflow gestört werden, weil die Software sich auf einmal anders verhält.

Und es gibt sehr viele Benutzer, die berichten, dass Gitlab extrem viele Bugs hat, um die sich niemand kümmert. Das geht sogar so weit, dass externe Programmierer Pull-Requests erstellen; das bedeutet übersetzt, dass externe Programmierer die Bugs von Gitlab lösen und quasi den Fix als Pull-Request anbieten. Leider wird beobachtet, dass viele Pull-Requests nie angesehen werden. Und genau das ist es, was man als Benutzer auch spürt. Gitlab geht hier imho den völlig falschen Weg. Die 80/20 Regel mag am Anfang ja funktionieren, um Benutzer zu sich zu locken, aber sobald man die Benutzer hat, muss man sich um diese auch kümmern.

Für viele Firmen ist Gitlab aber eine gute Wahl, da es offensichtlich keine Kosten verursacht und die meisten Firmen schon aus vielerlei Gründen ihren Quellcode nicht in irgendeiner US-amerikanischen Cloud ablegen wollen und dürfen. Man installiert Gitlab auf irgendeinem Server und fertig. Das Gleiche gibt es auch bei GitHub; das nennt sich dann GitHub Enterprise, aber kostet 21 USD pro Benutzer, obwohl man die GitHub Software auf seinem eigenen Server hostet. Man könnte meinen, dass 21 USD nicht viel sind, und das ist im Grunde auch meistens nicht das Problem, aber dadurch ist die Hürde, diese Software einzusetzen, viel höher. In vielen Firmen wird Gitlab von Programmierern und/oder Administratoren etabliert. In vielen Fällen installieren die das einfach von sich aus auf irgendeinem Server und weil es nichts kostet, interessiert das auch sonst niemanden. Wenn man aber Geld bezahlen soll, muss man sich an Abteilungen der Firma wenden, die dafür sorgen, dass das bezahlt wird und schon werden Fragen gestellt. Muss das sein? Wofür ist das? Wie viele Benutzer? Usw...bei Gitlab ist man da als Programmierer und/oder Admin viel flexibler. Und genau das ist auch der Grund für die hohe Adoptionsrate bei Gitlab.

Gitlab ist nicht schlecht, aber eben weit weg von "perfekt". Ich habe Erfahrungen mit Bitbucket, Github und Gitlab. Gitlab ist imho weit abgeschlagen auf dem dritten Platz. Aber aus oben genannten Gründen ist die Beliebtheit eben doch gegeben. Ich hoffe nur, dass Gitlab sich darauf besinnt mehr Stabilität in die Software zu bringen und vielleicht auch versucht das UI zu verbessern.

Wenn ich es richtig gelesen habe, hat Gitlab viele neue Mitarbeiter eingestellt, um das UI zu verbessern. Das klingt doch schon mal gut :)! Das würde bedeuten, dass Gitlab auf seine Kunden hört...aber womit genau verdienen die noch mal Geld? ;)

Viel Erfolg für das Gitlab Team von mir!


Firefox 56 nun auch mit Headless Mode


Firefox unterstützt nun ab Version 56 auch einen Headless Modus. Man kann nun, genau wie mit Chrome, diesen Modus in Kombination mit Selenium nutzen, um Webanwendungen automatisch zu testen.

Das bedeutet, dass man Firefox starten kann, ohne dass man etwas sieht. Man kann Firefox aber wie gewohnt "bedienen". Also nicht als User, aber mit Selenium. So kann man die Selenium Tests nun ganz bequem auf einem Rechner durchführen, ohne, dass man die grafische Ausgabe des Webbrowsers sieht.

Wenn man keine Lust auf Selenium hat, kann man auch einen eigenen WebDriver Client schreiben. Firefox unterstützt neben dem WebDriver auch das Marionette Protokoll. WebDriver ist im Grunde nur ein weiterer Layer oberhalb von Marionette. Die Abstraktion, die Selenium bietet, ist aber vermutlich für die meisten Anwendungssituationen vollkommen ausreichend.


Tesla feuert Swift Erfinder


Chris Lattner ist der Begründer der Programmiersprache Swift und hatte erst vor ca. 6 Monaten bei Tesla Motors angefangen. Tesla; diese Firma, die Elektroautos baut; du hast davon gehört.

Tesla Motors äußerte sich und meinte, dass Chris Lattner einfach nicht zur Firma passte. Christ Lattner arbeitete vorher bei Apple und ist nun frei verfügbar. Aus eigener Erfahrung kann ich sagen, dass ich mir ziemlich sicher bin, dass Chris Lattner seine Entscheidung bei Apple zu kündigen, bereut.

Insgesamt wirkt das alles sehr eigenwillig. Chris Lattner arbeitete für eine der größten IT-Firma (Apple), hat gekündigt um bei Tesla anzufangen, um dann nach nur 6 Monaten gefeuert zu werden. Ich persönlich kann das zwar nachvollziehen, aber ich bin ja auch nicht so gebildet wie Chris Lattner. Manchmal passt eine Firma oder ein Arbeitnehmer einfach nicht und dann muss man die Konsequenzen ertragen.

Spekuliert wird nun, dass Apple ihn wieder einstellt und er die ganzen Informationen teilt, so dass Apple wieder am "Apple Car" Projekt arbeiten kann ;). Das ist natürlich Quatsch, aber auch nicht ganz ausgeschlossen :D...aber ich will ja eine gewisse Ernsthaftigkeit bewahren.

Ich hoffe, dass Apple die Eier in der Hose hat diesen brillianten Mann wieder einzustellen. Nach 6 Monaten kann man noch von "Urlaub" sprechen. Er wird es die erste Zeit etwas schwerer haben, aber bei so einer großen Firma wie Apple wird das weniger ein Problem sein. Back to safe haven ;). Und nein, das hat mit mir rein gar nichts zu tun. Doch...ich habe schon mal bei meinem aktuellen Arbeitgeber gekündigt, bin zu einer anderen Firma gegangen und nach 3 Monaten wieder zurück zur "alten" Firma :). Manchmal passiert einfach Scheiße...so ist das halt.

Ich wünsche Chris Lattner viel Erfolg!


Teamarbeit ist geil!


Es ist bestimmt nicht das erste Mal, dass ich darüber schreibe wie wichtig Zusammenarbeit unter Programmierern ist. Es erscheint sinnlos es zu betonen, aber oft ist es doch so, dass viele Programmierer einen Einzelkampf führen.

Der Einzelkampf ist eine Erfahrung, die jeder Programmierer schon mal gemacht hat. Manchmal wurde man dazu gezwungen, weil die Firma personellen Engpass hatte oder man hat es freiwillig gemacht, weil man denkt es sei der einzig richtige Weg zu arbeiten. Wenn man aber einmal ausprobiert als Team zu funktionieren, so will man nichts anderes mehr. Aber das auch nur, wenn man erlebt hat, dass Zusammenarbeit extrem positive Effekte haben kann. Es gibt aber leider auch menschliche Beziehungen, die nicht funktionieren. Da funktioniert Teamarbeit natürlich nicht. Es gibt Programmierer, die nicht mitteilsam sind und lieber den ganzen Tag versuchen ein Problem alleine zu lösen anstatt sich auszukotzen. Das ist doof und verunsichert das Team. Solche Teammitglieder müssen geschüttelt und zur Vernunft gebracht werden :). Ok, nicht ganz ernst gemeint, aber wenn jemand im Team sich nicht traut sich mitzuteilen, ist das ein Problem.

Aber mal die negativen Dinge bei Seite gepackt ist Teamarbeit das Beste, was man als Programmierer erleben kann. Es gibt positive Effekte wie beim Rubberduck Debugging. Man spricht über ein Problem, welches man nicht lösen kann; die Kollegen stellen "dumme" Fragen und auf einmal fällt der Groschen!

Ich persönlich durfte heute Teamarbeit erleben, wie ich sie lange nicht erlebt hatte und ich hoffe, dass es sich wiederholt. Wir haben zu dritt einen sehr wichtigen Fehler analysiert, der unbedingt heute korrigiert werden musste, weil... wichtig. Wir haben uns die Arbeit geteilt und jeder hat zur Problemlösung beigetragen. Das Gefühl in einem Team gearbeitet zu haben ist einfach viel besser als die One-Man-Show abzuziehen.

Eine ähnliche Situation, aber ein anderer Kontext; ein Arbeitskollege, der mittlerweile wichtigere Aufgaben hat, ist in seiner Position unerträglich und erfüllt quasi alle Punkte eines Micromanagers. Ich habe ihm das sogar direkt ins Gesicht gesagt, aber das hatte nichts bewirkt. Nun die komplette Kehrtwende. Dieser Arbeitskollege und ich mussten zusammen als Programmierer agieren und ein technisches Problem lösen. Wir haben an dem Tag bis fast 22 Uhr daran gearbeitet und das Problem zusammen gelöst. Das war eine extrem angenehme Erfahrung, obwohl wir so lange arbeiten mussten. Und ich bin mir deswegen sicher, dass die Rolle eines Arbeitskollegen überhaupt keine Rolle spielt, solange man als Team agiert.

Also krempel die Ärmel hoch und versuche als Team zu arbeiten. Das macht einfach alles so viel angenehmer.


Erlang/OTP 20.0 veröffentlicht


Erlang/OTP 20.0 wurde veröffentlicht.

Erlang beschreibt sich selber mit folgenden Worten:

Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.
Ein Programmierer bekommt bei diesen Schlagwörtern sicher feuchte Träume und will sofort diese Programmiersprache erlernen. Eine gute Seite dafür ist http://spawnedshelter.com/. Dort findest du viele Verweise auf erprobte Lernmaterialien.


D wird bei GCC inkludiert


D ist eine Programmiersprache, die gerne als Alternative zu C++ betrachtet wird. GCC ist die GNU Compiler Collection. Bestandteil dieser Compiler Collection sind C, C++, Objective-C, Fortran, Ada, and Go.

Nun wurde aber auch die D Programmiersprache in die Compiler Collection aufgenommen. Möglich wurde dies durch Iain Buclaw; er benötigte stolze 6 Jahre, um das zu realisieren.

Das bedeutet, dass man in Zukunft mit der Installation von GCC auch einen D-Compiler dabei hat. Für die Zukunft von D ist das eine sehr positive Entscheidung des GCC Teams.


Kein App Store mehr für Android 2.1


Ab dem 30. Juni 2017 wird es für Smartphones mit Android 2.1 (Eclair) oder älter keine Möglichkeit mehr geben Apps über den App Store zu installieren. Google begründet die Änderung damit, dass Android 2.1 schon 7 Jahre alt ist und sowieso kein Entwickler mehr diese Androidversion unterstützt.

Geräte mit Android 2.2 sind davon nicht betroffen, da dort schon Google Play als App Store installiert und verfügbar ist. Vorher hieß die App "Market".


Unsinnige Versprechen


Die meisten Programmierer machen sich über Geld keine großartigen Gedanken. Alles, was sie wollen, ist anerkannt zu werden. Und sie wollen guten Code schreiben. Programmierer denken, dass guter Code mit hoher Anerkennung einhergeht. Für Programmierer ist guter Code fast wie Kunst. Sie sind stolz darauf. Sicher kann man das nicht pauschalisieren. Es gibt sicher auch Programmierer, die ihren Job nur ausüben, um Geld zu verdienen. Aber die meisten Programmierer, die ich kenne, genießen es zu programmieren.

Und Programmierer mögen von vielen Dingen eine Ahnung haben, aber über Firmenführung wissen sie meistens rein gar nichts. Das führt oft dazu, dass Programmierer gewisse Entscheidungen gar nicht nachvollziehen können, da sie logisch nicht zu erklären sind. Und alles, was logisch nicht zu erklären ist, ist falsch. Logisch, oder? Ok, genug.

Ich will in diesem Kontext über ein Thema berichten, welches aus Sicht eines Programmierers nicht logisch ist oder gar als komplett falsch deklariert wird. Eine Software Firma offeriert seinem Kunden eine Möglichkeit gewisse Fehler in der Software zeitnah zu beheben. Für diesen Service bezahlt der Kunde eine hohe Summe Geld, damit auch sichergestellt ist, dass das notwendige Personal zur Verfügung steht. Wird die zugesicherte Leistung nicht erbracht, wird eine Vertragsstrafe fällig.

Nun ist es oft so, dass in Softwarefirmen das Pareto Prinzip gelebt wird, ohne, dass es dem Programmierer bewusst ist. Das Pareto Prinzip besagt, dass man mit 20% Aufwand 80% des Ergebnisses erzeugt. Darauf wird man als Programmierer optimiert, ohne es zu merken. Ok, manche merken es, aber kündigen dann, fangen woanders an und merken dort nicht, dass sie wieder nach diesem Prinzip arbeiten. Um festzustellen, ob man sich in so einer Firma befindet, bedarf es kein Test, da quasi jede Firma so agiert. Wenn man aber denkt, dass man nicht bei so einer Firma arbeitet, darf man gerne anfangen zu versuchen perfekte Software zu schreiben. Ich bin mir sicher, dass man als Programmierer dann Probleme in der Firma bekommen wird, weil man quasi zu "langsam" ist. Das ist dann der Moment, wo man versteht, dass man doch bitte weniger "perfekt" sein soll. Aber zurück zur Software, die nur 80% fertig ist.

Man verkauft dem Kunden also 100%, hat aber aus Kundensicht nur 80% geleistet. Das weiß der Kunde aber noch nicht. Die restlichen 20% wurden nicht geleistet, aber bereits verkauft. Man hat als Softwarefirma also für die fehlenden 20% bereits kassiert. Dem Kunden fällt das erst mal nicht auf, da er von den 80% geblendet ist. Nun hat der Kunde aber diese Vereinbarung getroffen, dass gewisse Fehler zeitnah behoben werden. Diese fehlenden 20% werden nun zum Thema. Der Kunde merkt, dass gewisse Funktionalitäten nicht oder nur fehlerhaft vorhanden sind. Er meldet Fehler und erwartet, dass zeitnah gehandelt wird. Das Problem an der Sache ist, dass die Softwarefirma kein weiteres Personal eingekauft hat. Die Softwarefirma will auch alles Mögliche tun, um zu verhindern, dass weitere Personalkosten entstehen, da man den Gewinn von den 20% der Leistung, die nie erbracht wurde, schon anders ausgegeben oder verplant hat. Man belastet also das bestehende Personal mit diesen Aufgaben, gefährdet bestehende Projekte und sorgt dafür, dass das Personal eine Eigenart entwickelt, die dazu führt, dass Codeänderungen auf einmal furchtbar schnell passieren müssen, da vertragliche Lösungszeiten vereinbart wurden.

Diese schnellen Korrekturen führen zu einer drastischen Degradation der Codequalität und letztendlich zu einem schlechteren Produkt. Nun kann man davon ausgehen, dass das verkaufte Produkt ein perfektes Softwareprojekt ist. Eine perfekte Codebasis, bei der man Fehler extrem schnell beheben kann. Eine Codebasis, die extrem gut bewertbar ist. Aber jetzt mal Hand aufs Herz; durch das Pareto Prinzip ist eben alles gut, aber nicht die Codebasis. Die meisten Projekte gibt es im Prinzip doch nur, weil man anfangs Code hingekotzt hat. Es gibt sicher auch Ausnahmen, und das hoffe ich stark, aber die Regel sind Projekte, wo der Code hingekackt wurde. Erst nachher macht man sich Gedanken darüber, wie man den Müllhaufen entsorgen kann.

Aber worauf wollte ich hinaus? Die Softwarefirma will möglichst viel Gewinn machen. Der Kunde will eine möglichst gute Software. Der Kunde will im Fehlerfall schnell Hilfe. Die Softwarefirma verkauft dem Kunden eine Option, die zusichert, dass kritische Fehler zeitnah behoben werden. Die Softwarefirma stellt kein Neues Personal ein und verringert auch die neuen Projekte nicht. Das führt bei Programmierern zu Verwirrung und Unmut. Der Programmierer versteht zwar, dass der Kunde zeitnah Fehlerkorrekturen will, aber er versteht nicht, dass dies auf Kosten der Qualität des ganzen Projekts gehen soll. Eine Degradation der Qualität ist für einen Programmierer ein Dorn im Auge, da es seine Mühen in Frage stellt. Wieso hat der Programmierer sich vorher so viel Mühe gegeben? Damit man letztendlich auf dem Weg zur Toilette Fehler behebt, ohne groß darüber nachzudenken, welche Seiteneffekte das auslösen könnte? Nope.

Und genau hier liegt das eigentliche Problem. Es ist völlig legitim, dass der Kunde zeitnahe Fehlerkorrekturen fordert, aber es muss genau so legitim sein zu kommunizieren, dass gewisse Fehler nicht auf dem Weg zur Toilette behoben werden können. Bei gewissen Fehlern macht es Sinn sich umfangreicher damit zu beschäftigen. Das zeigt einfach die Erfahrung. Wenn man also dem Kunden eine fixe Zeitspanne verspricht, in der Fehler behoben werden, so ist das aus Sicht eines Programmierers völlig krank und bescheuert. Jeder Programmierer weiß, dass er ein Zeitlimit braucht, weil er sonst nie fertig werden würde. Wenn es aber kritische Probleme gibt, so muss es die Möglichkeit geben mehr Zeit zu haben, um das eigentliche Fehlerbild auch tatsächlich zu verstehen. Nicht selten werden Fehler nicht wirklich behoben, weil der Zeitdruck wichtiger ist als die eigentliche Korrektur.

Und das kann ja nicht der Sinn sein. Der Kunde als auch die Softwarefirma müssen die Qualität des Produkts im Blick haben. Wenn der Kunde unrealistische Anforderungen stellt, so muss das thematisiert werden. Wenn der Kunde einen Fehler feststellt, der nicht in der vereinbarten Zeit behoben werden kann, so muss man sich zusammen mit dem Kunden auf eine sinnvolle Zeit einigen. Wenn das nicht getan wird, sind das unsinnige Versprechen, die nicht oder nur auf Kosten der Qualität der Software eingehalten werden können. Das kann aber nicht im Sinne des Kunden sein. Trotzdem wird es gefordert. Kranke Welt.

Dieser Text ist natürlich höchst IMHO und hat nichts mit meinem aktuellen Arbeitgeber zu tun. Ganz konkret geht es mir im Grundsatz darum eine Balance zwischen dem Kunden und Programmierer zu finden. Dem Kunde sollte die Qualität nicht egal sein. Und das ist sie auch nicht. Der Kunde versteht aber nicht, wie Programmierer und Software funktionieren. Deswegen kann es passieren, dass unrealistische Anforderungen gestellt werden. Dann ist es die Pflicht eines Softwareunternehmens den Kunden entsprechend aufzuklären. Es gibt immer eine sinnvolle Lösung. Code in die Ecke zu kacken, nur weil man nicht die Eier hat mit dem Kunden zu sprechen, ist IMHO auf jeden Fall keine langfristige Lösung. Sie führt zum Verfall des Produkts.


Boris Kraut gibt F-Droid auf


Der F-Droid Projektleiter Boris Kraut schmeißt hin. Er nutzt nach eigener Aussage kein Android mehr und hat deswegen kein großes Interesse mehr daran das Projekt zu unterstützen. Er ist der Meinung, dass man die Software, die man betreut, auch selber nutzen sollte. Er nutzt jetzt nur noch ein Laptop, SSH und Papier.

Für das F-Droid Projekt könnte diese Entscheidung kritisch sein. F-Droid ist ein alternativer Android App Store, der nur OpenSource und freie Apps beinhaltet. F-Droid ist abhängig von den Softwarebetreuern. Und der Maintainer mit der höchsten Aktivität ist eben Boris Kraut. Nach ihm kommt schon Ciaran Gultnieks, der zwar auch extrem viel zu F-Droid beiträgt, aber das alleine reicht nicht. Schon danach wird es nämlich dünn mit der Aktivität.

Falls du also Bock auf so ein Projekt wie F-Droid hast, wäre jetzt vermutlich ein günstiger Zeitpunkt da mal anzuklingeln. Hilfe wird dort sicher jetzt erst recht gerne gesehen. Wie man beitragen kann, findest du hier.


Debian GNU/Hurd 2017 veröffentlicht!


Nicht nur Debian 9 aka Stretch wurde veröffentlicht, sondern auch Debian GNU/Hurd 2017. Und du so: "Hurd? Wut?" Ja, Hurd ist wie Linux nur ein Kernel und es gibt Distributionen, wie Debian GNU/Hurd, die eben den GNU/Hurd Kernel als Basis nutzen. Neben Debian GNU/Hurd gibt es auch Arch Hurd und Gentoo/Hurd.

GNU/Hurd ist ein Mikrokernel, bei dem die meisten Komponenten in einem eigenen Prozess laufen. Die Prozesse laufen als Benutzerprozesse und haben anfangs keine Privilegien. Ein Prozess kann aber nach mehr Berechtigungen fragen und sie auch bekommen. Kommt dir auch bekannt vor oder? Ich kenne es von Android und Fuchsia. Technisch werden sich alle drei Implementierungen aber sicher grundlegend unterscheiden.

Debian GNU/Hurd lässt sich im Grunde wie ein Debian Linux installieren. Nur mit dem Unterschied, dass der Text Installer direkt mit einer Fehlermeldung stirbt. Der pseudo-grafische Installer funktioniert, führt aber auch zu nichts, da der Installer am Ende versucht die Pakete auf dem CD-Laufwerk zu installieren. Das quittiert der Installer dann mit "No space left on device". Logisch. Danach kommen dann ganz viele andere Fehler. Vermutlich habe ich die falsche Hardware.

Ich wünsche dem Projekt auf jeden Fall viel Erfolg!


Podcast Folge 18


Wie versprochen der wöchentliche Podcast!

Dieses Mal Folge 18. GopherOS - Betriebssystem in Go, Ada & RISC-V, ARM ist keine Lösung, Redhat gibt Ceylon auf, Atom 1.18.0 mit Git und GitHub Support veröffentlicht, Neuanfang mit der Ataribox, Debian 9 (Stretch) wird heute veröffentlicht, Gnat GPL 2017 veröffentlicht und Firefox 54 veröffentlicht.

Viel Spaß damit!


Neuanfang mit der Ataribox


Atari kennen vermutlich noch sehr viele Menschen als Arcade-Automaten Hersteller, aber vermutlich am ehesten noch als Hersteller diverser Heimvideospielsysteme und Heimcomputer. In den letzten Jahren hatte Atari keinerlei solcher Produkte mehr im Portfolio. Atari war aber weiterhin als Spiele Publisher tätig.

Das soll sich nun aber bald ändern. Atari hat angekündigt eine Spielekonsole mit dem Namen "Ataribox" zu verkaufen. Auf www.ataribox.com sieht man nur ein kurzes Werbefilmchen, welches im Grunde nichts von der Ataribox zeigt. Aber es reicht, um die Neugierde zu wecken.

Ich könnte nun spekulieren, dass Atari einen Playstation 4 Killer bauen will, oder gar eine Konsole, die besser als die neue Xbox One X sein soll, aber das kann ich nicht, da man rein gar nichts weiß.

Ich weiß nur, dass ich Atari als interessanten Hersteller von Hard- als auch Software kenne und ich mich sehr freuen würde, wenn ein weiterer Konkurrent den Ring betreten würde.


Atom 1.18.0 mit Git und GitHub Support veröffentlicht


Gestern, am 15.06.2017, wurde Atom 1.18.0 veröffentlicht. Bestandteil der neuen Version ist nun auch die Git und GitHub Integration. Das habe ich zum Anlass genommen, um mal wieder Atom auszuprobieren. Ich war ja von Anfang an Fan, wurde aber durch Visual Studio Code abgeworben und habe Atom seit dem nicht mehr benutzt.

Das erste, was mir auffiel ist, dass Ordner/Dateien in grüner Farbe dargestellt werden, wenn sie neu hinzugefügt wurden. Das ist praktisch und man kennt dieses Feature so auch aus IDEs. Orange werden Ordner und Dateien dargestellt, wenn sie modifiziert wurden. Aber ich vermute, dass Atom das auch vorher schon konnte.

Farben im Dateibaum
Anzeige neuer und modifizierter Inhalte

Wenn man das "Git" Panel öffnet, sieht man seine modifizierten und neu hinzugefügten Dateien. Man kann sich an dieser Stelle entscheiden, welche Dateien man "stagen" möchte. Man kann mit Klick auf "Stage All" eben alles "stagen", wenn man das denn möchte.

Git Feature von Atom
Git Integration

Wenn man dann seine Dateien "gestaged" hat, kann man ganz gewöhnlich committen. Der Arbeitsablauf ist in Atom genau so gut integriert wie in Visual Studio Code. Ich persönlich würde nach 3 Bier vermutlich keinen Unterschied mehr zwischen Atom und Visual Studio Code feststellen (in diesem Bereich!). Um seine committeten Änderungen dann auch zu pushen, so muss man unten in der Statusleiste neben "master" (oder welchen Branch man auch immer ausgechecked hat) auf den Pfeil "nach oben" klicken. Wie du dir denken konntest, kannst du mit Pfeil "nach unten" die Änderungen fetchen.

Neben der Git Integration wurde aber auch die GitHub Integration versprochen. Da Atom ein GitHub eigenes Projekt ist, hätte man vermutet, dass eine GitHub Integration längst vorhanden wäre, aber so war es leider nicht. Nun hat das Atom Team neben Git auch eine GitHub Integration implementiert. Wie bereits angekündigt ist dieses Feature im Editor noch als "(preview)" markiert. Wenn man einen Ordner öffnet, wo man ein ".git" Ordner hat, so kann man zum "GitHub (preview)" Panel wechseln und findet dort einen "Login" Button. Man kann an der Stelle einen GitHub API-Key erzeugen und Atom den Zugriff auf seine GitHub Repositories geben. Danach zeigt es Dinge von deinem Repository an. Ob man die Möglichkeit hat von dort auch einen Merge durchzuführen, kann ich aktuell nicht sagen, da ich die einzige "Ziehanfrage" schon gemerged hatte, bevor ich die neue Atom 1.18.0 Version testen konnte.

GitHub Integration von Atom
GitHub Integration

Grundsätzlich finde ich die neuen Features gut. Atom ist aber immer noch so, wie ich es kenne. Es ist ein sehr extrem erweiterbarer Editor. Ich persönlich nutze zum Beispiel sehr gerne das Minimap Feature von Visual Studio Code und Sublime3. Diese Editoren bringen das von Haus aus mit, weil man so ein Feature nicht mit einer Erweiterung bauen könnte. Bei Atom aber kann man quasi alles ändern und das grundlegend. Das führt auch manchmal dazu, dass der Editor unbenutzbar wird, aber technisch betrachtet geht das.

Ich finde die Standard-Autocompletion-Packages von Atom aber immer noch gruselig. Alle Pakete, die mit "autocomplete-" beginnen, sind so störend, dass ich das gar nicht in Worte fassen kann :). Nichts gegen Autovervollständigung, aber dann sollte das auch in irgendeiner Form sinnvoll funktionieren. Wenn ich "Visual Studio Code" eingebe und er daraus "Visual Studio <code></code>" macht, ja, sorry, dann ist das einfach nur falsch :). Grundsätzlich finde ich Atom aber gut, obwohl es auf Electron basiert. Man merkt das auch; schon beim Start merkt man es; Atom braucht auf meiner Core i7 Maschine schon fast 3 Sekunden, um zu starten und die zuletzt editierte Datei anzuzeigen. Sublime3 dagegen ist sofort da. Aber wie wichtig einem das ist, muss jeder selber entscheiden. Ich habe meinen Editor zumindest auf der Arbeit den ganzen Tag geöffnet und schließe ihn erst zu Feierabend.

So bleibt mir nur zu sagen, dass Atom immer noch ein sehr guter Editor ist, der extrem erweitert werden kann. Atom ersetzt bei mir nun wieder Visual Studio Code und Sublime Text 3.


Redhat gibt Ceylon auf?


Ceylon ist eine Programmiersprache von Gavin King. Gavin King arbeitet für Redhat und ist Chefentwickler für die Programmiersprache "Ceylon". Ceylon ist eine Programmiersprache, die Java Bytecode emittiert und einige neue Konzepte etabliert hat. Einige der Neuerungen in Ceylon wurden in anderen Programmiersprachen wie C# übernommen.

Nun scheint es aber, dass Redhat Ceylon aufgibt. Zumindest könnte man das vermuten, da Redhat das Projekt nun offenbar der Eclipse Foundation übergeben will. Man hat dafür ein "proposal" veröffentlicht und Ceylon sehr gut beworben, so dass es vermutlich auch ohne Probleme aufgenommen wird.

Ceylon wurde nie wirklich angenommen und so verwundert es nicht, dass Redhat die Programmierer, die daran arbeiten, anders nutzen will. Positiv zu bewerten ist aber, dass Redhat das Projekt in gute Hände geben will. Mal sehen, was daraus wird.


Ada & RISC-V


Ada ist eine relativ alte Programmiersprache, die angeblich keine Rolle mehr spielt, aber doch immer wieder in Erscheinung tritt. Das macht Ada speziell, da viele andere alte Programmiersprachen tatsächlich nicht mehr beworben werden. Im Falle von Ada gibt es aber tatsächlich noch Innovation, über die es sich lohnt zu berichten.

Fabien Chouteau berichtet darüber, dass er Software mit Ada auf einem RISC-V Microcontroller zum laufen gebracht hat.

Nun, was ist so besonders daran, dass Ada Programme auch für RISC-V basierte Prozessoren geschrieben werden können? Ja, das mag unscheinbar klingen. Manche Menschen würden denken: "wayne?", aber ganz so einfach ist das nicht. RISC-V ist eine offene Prozessorarchitektur, die jeder nutzen kann, um eine CPU zu bauen. Ok, und nun?

Das alleine klingt ebenso unspannend, aber das ist es nicht. Du und ich nutzen heute vermutlich eine CPU von AMD oder Intel auf dem PC (ich habe tatsächlich mal eine Cyrix CPU verwendet, aber das interessiert niemanden mehr). Diese CP-Einheiten sind unsicher. Diesen Satz habe ich extra kurz gestaltet, damit du darüber stolperst. Du wirst dich fragen, was an einer CPU unsicher sein kann und ich nehme es dir nicht übel, dass du diese Frage stellst. In Intel CP-Einheiten aber auch in AMD CP-Einheiten gibt es Software-Lösungen, die es erlauben deinen PC entfernt zu steuern. Diese Erweiterungen wurden entworfen, um im Firmenumfeld eine Möglichkeit der einfachen Administration zu schaffen. Das alleine ist nicht verwerflich, aber die Tatsache, dass diese Software unsicher ist. Bei Intel wurde es schon nachgewiesen und wenn du eine Core Ix CPU hast, so bist du sehr wahrscheinlich betroffen davon, dass dein System aus der Ferne zu steuern ist, ohne, dass du es erlaubt hast. Und wenn ich "Software" schreibe, dann meine ich Firmware, die du so einfach nicht austauschen kannst, da es Software innerhalb deiner CPU ist. Auch AMD hat solche Erweiterungen, jedoch wurde da noch nicht nachgewiesen, dass diese Erweiterungen Fehler enthalten.

RISC-V wird bei vielen Programmierern als Offenbarung gesehen, da es offen und eben "libre" ist, aber ganz so einfach ist das auch hier nicht. Die gleiche Meinung gibt es nämlich auch für ARM und ich sehe das dort gar nicht so rosig wie viele andere. Bei vielen Programmierern wird die ARM CPU als Allheilmittel angesehen, aber diese Meinung kann ich schon alleine aus praktischer Erfahrung nicht teilen.

Ich war vor einigen Jahren sehr daran interessiert Intel als auch AMD mit ARM zu ersetzen. Das ist praktisch auch heute nicht möglich. ARM CP-Einheiten oder von mir aus ARM SOCs sind leistungstechnisch so gut wie allen AMD und Intel Prozessoren unterlegen. Bei ARM schreibt fast jeder, dass ARM viel weniger Strom als Intel oder AMD benötigt. Ja, das ist auch so, aber wieso? Weil ARM Prozessoren weniger leisten :). Ja, es ist wirklich so einfach, wie ich es schreibe. Ich vergleiche noch heute moderne ARM CPUs mit meinem Classic AMD Athlon K7 Slot Single-Core 700MHz. Wieso? Weil ARM CPUs extrem langsam sind. Wenn ein Hersteller 10-Core ARM bewirbt, heißt das nur, dass 4 Kerne normal schnell und alle anderen Kerne sack lahm sind, um Strom zu sparen :). Wenn man das mit dem Markt der Desktop-CPUs vergleicht, ist die Intention eine ganz andere. Im Desktop-Bereich will man höchst mögliche Leistung; bei ARM höchstmögliche Stromersparnis.

Aber wieso mecker ich über ARM? Weil ARM sack lahm ist und weil es bei ARM kein BIOS oder UEFI gibt. Nicht, dass ich beides unbedingt geil finde, aber wenn wenn weder BIOS noch UEFI vorhanden sind, ist die Situation um so schlimmer, da nun die Initialisierung der Hardware abhängig vom Hersteller ist. Das ist quasi der Supergau. Da kann die Hardware noch so geil sein; in dieser Situation ist man der Arsch.

Und deswegen bin ich mit RISC-V ganz vorsichtig. Ich weiß zwar, dass Coreboot mit RISC-V funktioniert, aber ganz so trivial ist das eben nicht. Es wird immer noch sehr spezielle Hardware unterstützt. Im Grunde ist das bei BIOS und UEFI auch so, nur, dass dort die Unterstützung umfangreicher ist und es nicht direkt auffällt, dass trotz BIOS oder UEFI für jede Hardware Anpassungen notwendig sind. Das ist nicht ganz wahr, aber auch nicht ganz falsch.

Ich bin auf jeden Fall der Erste, der ein RISC-V System kauft, was auch bezahlbar ist. Es gab bisher nur Projekte, die extrem teuer waren. Aber ich mache mir auch nichts vor. Intel und AMD werden trotzdem die schnelleren Chips haben. Ich bin aber bereit eine CPU zu nutzen, die langsamer ist, aber dafür sicher. Die Performance darf aber nicht zu langsam sein. Ich bin nicht bereit viel Geld auszugeben, um die Performance meines alten AMD Athlon K7 Classic Slot Single Core mit 700MHz zu haben. Das sehe ich nicht ein. Das wäre für mich ein Schritt in die falsche Richtung. Wenn aber ein RISC-V Prozessor bei 30% mehr Stromverbrauch 30% weniger Leistung bringt, wäre das für mich kein Beinbruch.

Dass Ada aber nun auch RISC-V Architekturen unterstützt und dass darüber geschrieben wird, ist eine sehr gute Sache. Das zeigt, dass Ada noch lange nicht tot ist. Weiter so!


GopherOS - Betriebssystem in Go


GopherOS ist ein Betriebssystem, welches in der Go Programmiersprache implementiert wurde. Der Autor schreibt "Proof of concept", aber von "concept" ist da leider nicht viel zu sehen. Ich kann es fast nicht glauben, dass man so ein Projekt tatsächlich mit nur einer Zeile Dokumentation startet: Let's write an experimental OS in Go!

Ich hatte letztens erst darüber gelesen, wie jemand behauptet hatte, dass die meisten Softwareprojekte scheitern, weil sie nicht oder schlecht dokumentiert sind und wenn ich mich so umsehe, dann passt die Tendenz. Schaue ich mir mal die gängigen Betriebssysteme wie Windows, Linux, Netbsd, OpenBSD, FreeBSD und Minix (ok, das war leicht übertrieben), so sieht man, dass diese Betriebssysteme allesamt sehr gut dokumentiert sind. Diese Projekte sind allesamt in ihrem Bereich erfolgreich.

Aber gut, ich will mich mal nicht zu sehr über etwas aufregen, was vielleicht noch korrigiert wird. Und vermutlich bekomme ich nun Hassmails, dass ich die Dokumentation ja selber beisteuern sollte. Nein, so läuft das nicht. Jemand, der ein Betriebssystem schreibt, muss schon vorher eine sehr genaue Vorstellung von dem haben, was er da bauen will. Ich kenne bis jetzt kein Betriebssystem- Projekt, wo es vorher nicht mehr Dokumentation als Code gab.

Ich werde das Projekt mal verfolgen, aber ich bin mir ziemlich sicher, dass es eine Luftnummer wird. Aber spannend für den Autor wird es sicher sein. Etwas desillusioniert vielleicht, aber sowas braucht man manchmal, um etwas Geniales zu schaffen.

Und wenn du bei dem Namen an ein Protokoll denkst, dann bist du einfach nur alt :). Sorry :D.


Podcast Folge 17


Wie versprochen der wöchentliche Podcast!

Dieses Mal Folge 17. Der Souncloud Player ist zu fett, Pharo 6 wurde veröffentlicht, ich lästere über Linux auf dem Desktop, Codefights.com, jemand einen Gameboy Emulator für TempleOS entwickelt, Electron propagiert TypeScript, der Mozilla User-Agent String und Chrome 59 kann nun Headless Mode, aber erst mal nur unter Linux und macOS.

Viel Spaß damit!


Chrome unterstützt ab Version 59 Headless Mode


Ich persönlich habe schon viele Erfahrungen mit Selenium gemacht. Damit kannst du automatisierte Webbrowser Tests programmieren. In meinem Fall habe ich das mit Java gemacht, um eine Webanwendung automatisiert zu testen. Ich nutzte damals Selenium noch zusammen mit Firefox, weil, so unglaubwürdig es auch klingt, Firefox schneller startete als Chrome.

Aber was bei der Entwicklung der Tests noch in Ordnung ist, nervt immer dann, wenn man die Tests nur ausführen muss. Du musst dir das so vorstellen: man programmiert die Tests und wenn man den Test ausführt, so startet der Webbrowser und man kann zugucken, wie dort automatisch Dinge geklickt werden usw... Bei der Entwicklung der Tests ist das manchmal sehr hilfreich, aber wenn man die Tests fertig programmiert hat und sie dann nur noch ausführen will, um zu verifizieren, dass noch alles funktioniert, so braucht man die visuelle Ausgabe ja gar nicht mehr. Ich hatte dieses Problem damals mit Selenium Grid gelöst. Ich hatte Selenium also auf einem Linux-Server installiert, ein bisschen X-Magie gemacht und dann konnte ich meine Tests remote ausführen. Das war zwar gefühlt etwas langsamer, aber es funktionierte.

Mit Chrome 59 gibt es nun aber den Headless Mode. Das bedeutet, dass man Chrome starten kann, ohne dass man etwas sieht. Man kann Chrome aber wie gewohnt "bedienen". Also nicht als User. Es gibt eine neue API und Selenium gibt es ja weiterhin, so dass ich die Selenium Tests nun ganz bequem auf meinem Rechner durchführen kann, ohne, dass mich die grafische Ausgabe des Webbrowsers nervt. Gute Sache! Ich bin zwar kein Fan von Chrome, aber ich muss anerkennen, dass das gut ist.

Happy Testing!


Sind wir nicht alle ein wenig Mozilla?


Wieso steht "Mozilla" in jedem HTTP-Request, obwohl die Besucher den Internet Explorer, Edge, Opera, Chrome, Opera oder Firefox benutzen? Aaron Andersen hatte darüber am 3. September 2008 mal geschrieben und ich wollte es dir nicht vorenthalten. Hier in einer leich aktualisierten Version.

Am Anfang gab es den Mosaic Webbrowser, der sich nicht mit "Mozilla" meldete, sondern mit "Mosaic". Dann wurde der Mozilla Webbrowser veröffentlicht; dieser war viel besser als Mosaic; Mozilla hatte "Mozilla" im USER_AGENT String, war ja klar. Mozilla wurde irgendwann zu Netscape umbenannt. Netscape konnte viel mehr als Mosaic; Frames zum Beispiel. Netscape hatte weiterhin "Mozilla" im USER_AGENT String. Webentwickler konnten nun zwischen Mosaic und Netscape unterscheiden und haben, je nach dem welcher Webbrowser der Benutzer nutzte, zu einer Seite mit oder ohne Frames weiterleiten.

Dann stieg Microsoft in den Ring und brachte den Internet Explorer mit. Dieser sollte besser sein als Netscape, aber Microsoft wollte nicht warten, bis die Webentwickler sich an den IE angepasst hatten und hat deswegen auch "Mozilla" im USER_AGENT gehabt, so dass die "modernen" Websites auch im IE angezeigt wurden.

Dann kam irgendwann Firefox um die Ecke und hatte neben "Mozilla" auch "Gecko" im USER_AGENT String enthalten, denn Firefox war neuartig; es hatte eine neue Rendering Engine mit dem Namen "Gecko". Webentwickler haben nun Websites entwickelt, die speziell für diese neue Rendering Engine ausgelegt waren.

In der Zwischenzeit wurde unter Linux ein Webbrowser mit dem Namen Konqueror entwickelt. Dieser Webbrowser hatte eine eigens entwickelte Rendering Engine mit dem Namen "KHTML". Und weil sie wussten, dass ihre Engine genau so gut ist wie Gecko, haben sie nun neben "Mozilla" auch "Gecko" in den USER_AGENT String mit aufgenommen, damit auch sie davon profitieren, wenn Webentwickler Code nur für Firefox gebaut haben.

Dann kam Apple mit Safari um die Ecke. Als Basis dafür hatten sie KHTML genutzt und nannten den Fork WebKit. Safari hatte seit dem "Mozilla", "Gecko", "KHTML" und "AppleWebKit" im USER_AGENT String stehen.

Dann kam Google und hat Chrome entwickelt. Als Basis dafür hatten sie WebKit genutzt. Seit dem hat Googles Chrome "Mozilla", "Gecko", "KHTML", "AppleWebKit" und "Safari" im USER_AGENT String stehen. Ich hätte bei Chrome auch "Blink" erwartet, denn es nutzt schon seit einigen Jahren die Blink Engine, die wiederum eine Abspaltung des WebKit Projekts ist (und WebKit wiederum eine Abspaltung von KHTML).

Verrückt oder? :)


Electron mit TypeScript Support


TypeScript ist eine Scriptsprache von Microsoft, die zu JavaScript transpiliert. Somit hatte Electron schon immer TypeScript Support, weil es letztendlich egal ist, wie der JavaScript Code erzeugt wird.

Electron bietet nun aber eine TypeScript Definitionsdatei an, so dass man jetzt detaillierte Annotationen im Code angezeigt bekommen kann, sofern der Editor oder die IDE das unterstützen.


Gameboy Emulator für TempleOS


Er nennt sich "tsheikhs" und hat bei Github einen Gameboy Emulator für das Betriebssystem TempleOS veröffentlicht. TempleOS ist ein biblisches Betriebssystem von Terry A. Davis. Terry A. Davis ist psychisch krank, aber das hindert ihn nicht daran seine Begabung auszuleben. Aber um Terry A. Davis geht es ja gar nicht, sondern um "tsheikhs".

Der Gameboy Emulator nennt sich cherub und kann grundlegend Mario ausführen, aber es gibt noch extrem viele Bugs. Beeindruckend ist es dennoch.

"tsheikhs" hat für TempleOS auch ein MegaMan Clone entwickelt und einige andere Dinge. Was mich aber viel mehr irritiert, ist die Tatsache, dass die Website von TempleOS auf einmal so "leer" ist. "Früher" konnte man dort sehr viele Informationen bezüglich TempleOS finden. Aber "tsheikhs" hat das zum Glück alles gesichert: hier zu finden.

Nun ja...so interessant TempleOS auch ist; es hat ein paar Features, die interessant sind, aber immer, wenn ich darüber lese, bekommt mich ein leicht bedrückendes und gar depressives Gefühl. So Sachen wie Furthermore, I have verified that monk logic is sound. verunsichern mich dann doch etwas.


Codefights


Es gibt im Internet Websites, die einem anbieten Programmieraufgaben zu lösen. Verrückt oder? Das macht aber Spaß und reizt das Gehirn!

Vor einigen Jahren versuchte ich mich an projecteuler, aber das wurde mir ab einem bestimmten Punkt zu mathematisch. In Mathe war ich immer gut, aber irgendwann wurde ich zu faul und hab den Anschluss verpasst; das war, glaube ich, in der 11. Klasse :). Egal. Projecteuler war auf jeden Fall eine gute Gelegenheit sein Gehirn abseits der Arbeit zu reizen und das ist meiner Meinung nach sehr wichtig.

Ein IRC Freund, deki, hatte mir letztens ein neues Projekt vorgestellt, welches, wie projecteuler, das Gehirn eines Programmierers reizen soll. Es heißt Codefights. Das ist im Grunde wie projecteuler, aber doch ganz anders, denn es ist viel "moderner"; man kann den Code direkt online eingeben und er wird serverseitig ausgewertet. Auch optisch ist es viel moderner, wobei das natürlich subjektiv ist. Und es gibt nicht nur einen Single-Player Modus, sondern, und nun macht der Name auch mehr Sinn, einen Multi-Player Modus, wo man gegen andere Programmierer antreten kann. Man kann so auch gegen Arbeitskollegen antreten :D...

Ich wollte es dir nicht vorenthalten.


Linux auf dem Desktop


Ich nutzte ca. 17 Jahre lang Linux auf dem Desktop und war nie richtig zufrieden. Ich machte immer Abstriche. Privat störte das nicht so sehr; ich habe unter Linux so gut wie gar nicht gezockt und meine Aktivitäten auf andere Dinge beschränkt. Auch beruflich nutzte ich sehr lange Linux auf dem Desktop; das war selbstverständlich. Wie sich herausstellte musste ich mich beruflich aber noch viel intensiver einschränken. Das ging so weit, dass ich bestimmte Dinge einfach nicht tun konnte. Aus Sicht meines Arbeitgebers ist sowas natürlich extrem unbefriedigend. Und auch aus meiner persönlichen Sicht hat mich das nur genervt.

Ich bin ja so jemand, der so idealistische Dinge wie Linux aus Prinzip nutzt, aber es hat eben alles seine Grenzen. Privat spiele ich ab und zu gerne mal irgendwelche Spiele und beruflich muss ich tatsächlich auch mal mit Excel oder Word arbeiten. Das klingt trivial und viele Linux User würden mir jetzt sagen, dass man das auch unter Linux machen kann. Das ist pauschal so aber nicht richtig. Ich arbeite im eHealth Sektor und bekomme Office-Dateien von Krankenkassen. Ich kann die zwar meist auch unter Linux öffnen, aber fast immer sieht man sofort auf den ersten Blick, dass etwas mit der Darstellung nicht stimmt. Sofern man dennoch alles lesen kann, ist noch alles gut, aber problematisch wird es, wenn man Änderungen an dieser Datei vornehmen soll. Das kann man mit Libreoffice technisch zwar machen, aber es ist fast garantiert, dass man an der Datei irgendetwas grundlegend verändert, ohne es gewollt zu haben. Ich habe schon mal eine sehr bunte Excel-Datei mit Libreoffice editiert und dann gespeichert. Für mich sah optisch alles gut aus, aber bei der Krankenkasse wurden die Farben alle verändert. Wie sich herausstellte wurden die schon bei mir falsch dargestellt, aber ich wusste es ja nicht. Ich hatte ja keine Ahnung, wie das original aussah. Und da auch innerhalb der Firma Excel und Word Dateien getauscht werden, habe ich auch da Probleme gehabt.

Und ich oute mich ungerne, aber ich finde Outlook sehr gut. Für mich ist Email ein sehr wichtiges Kommunikationsmittel (weil verzögert) und ich finde Outlook tatsächlich am besten. Und mit Windows 10 finde ich auch den Desktop wieder gut. Das, was mir unter Linux immer falsch vorkam, wird unter Windows 10 richtig umgesetzt. Und ich oute mich erneut: der Explorer ist imho ein sehr guter Dateiexplorer. Klar, Shell und so, aber manchmal ist es eben doch extrem hilfreich, wenn man alle Metadaten im Blick hat. Und gerade, wenn man Ordner "refaktoriert", ist ein Dateiexplorer doch sehr hilfreich.

Und etwas, was kein User unter Linux zugibt, weil er es vermutlich eh nicht mehr merkt: der Desktop ist langsam. Ich habe hier ein sehr potentes System. Im Grunde hatte ich immer gut gerüstete Systeme und eine Sache, die ich unter Linux schon von Anfang an extrem bemängelt hatte war die grafische Oberfläche. Und ich meine jetzt nicht direkt KDE oder Gnome, sondern Xfree86 und seit vielen Jahren Xorg. Wie gesagt; ich nutze Linux seit ca. 17 Jahren auf dem Desktop und im Vergleich zu Windows fühlte sich die grafische Leistung immer langsamer an. So simple Sachen wie Tearing, wenn man Fenster verschiebt. Das sieht ein Linux User nicht, weil er sich daran gewöhnt hat. Das ist auch so; man merkt das irgendwann nicht mehr. Man gewöhnt sich an die langsamere Grafikperformance. Wenn man die Problematik anspricht, soll man doch bitte die richtigen Treiber installieren. Es ist alles Quatsch. Die hat man natürlich installiert. Ohne die "richtigen" Treiber ist die Performance nämlich katastrophal und unbenutzbar. Vergleiche ich den Linux Desktop mit dem Windows 10 Desktop auf der gleichen Hardware, so fühlen sich Fenster unter Windows 10 leicht an, unter Linux eher schwer. Das ist schwierig in Worte zu fassen. Das ist vielleicht vergleichbar mit Gamern, die den Unterschied zwischen 60 und 120FPS bemerken. Man merkt das einfach. Und im Falle von Linux sehe ich ganz deutlich, dass die Fenster grafisch laggen. Es ist auch kein Geheimnis, dass die Grafiktreiber, selbst, wenn sie direkt vom Hersteller kommen, im Vergleich zur Windows Variante bezüglich Performance schlechter sind. Das ist nicht mal ein offenes Geheimnis, sondern ist faktisch offen dokumentiert. Und dann gibt es noch spezifische Performance Probleme bei den Desktopumgebungen wie KDE und Gnome. Man findet immer wieder Probleme diesbezüglich, wobei man unter Linux ja ganz gut ausweichen kann. Letztendlich will man mit Wayland alles auf den Kopf stellen, aber da ist die Situation sogar noch schlechter. Bei Wayland will man alles sicherer machen, denn im Grunde ist Xorg sehr unsicher, da jedes grafische Programm alles mitschneiden kann, ohne dich darüber zu informieren. Ja, sogar alle deine Tasteneingaben. Das will man mit Wayland fixen, und hat es auch getan, aber hat nun andere Probleme...sorry, aber ich habe 17 Jahre lang gewartet.

Manch andere beschweren sich noch darüber, dass es verschiedene GUI Toolkits wie Qt, GTK, Tk usw...gibt...auf diesen Zug bin ich nie aufgesprungen. Mir war die Optik meist egal. Mir war die Funktionalität wichtiger als die Optik. Klar ist es doof, dass ohne etwas Aufwand Qt und GTK Programme anders aussehen, aber wie gesagt; das war mir meist egal.

Und was mich letztendlich wieder zu Windows auf dem Desktop getrieben hat war WSL. WSL, das ist dieses Windows Subsystem für Linux. Simpel gesprochen kann ich damit meine gewohnte Linuxumgebung nutzen, ohne Linux zu booten oder gar zu virtualisieren. Das ist einfach Teil von Windows und es funktioniert wunderbar. Man muss es zwar immer noch extra in den Software Features aktivieren, aber es ist eben immer noch Beta. Kein Ding also.

Ich verstehe auch, dass es kacke ist, dass man bei der Windows 10 Installation erst mal gefühlt 20 Checkbox Häkchen deselektieren muss, um zu verhindern, dass die selbst gemachten Nacktfotos auf der Festplatte bei Bing auftauchen. Und mir ist bewusst, dass die meisten User an der Stelle vermutlich einfach "weiter, weiter, weiter,..." klicken, und ich finde das echt beschissen von Microsoft. Ich finde es auch beschissen, dass man nachträglich Tools installieren muss, um ein Windows zu haben, was eben nicht nach Hause telefoniert und selbst dann kann man es nicht ausschließen. Das ist natürlich scheiße; keine Frage. Aber ich ich gehe einen Kompromiss ein.

Und was ist jetzt traurig an der ganzen Sache? Dass ich nach so vielen Jahren wieder Windows auf dem Desktop nutze? Nein. Das Traurige an der Sache ist, dass ich diesen Text so in der Art schon vor 17 Jahren geschrieben hatte. Und leider hat er unverändert Gültigkeit. Verrückt oder? Linux hat auf dem Desktop eine Verbreitung von um die 2%. Und das ist verrückt, wenn man betrachtet, dass Linux out of the box eigentlich die bessere Hardwareunterstützung hat (im Vergleich zu Windows). Aber es ist eben der Grafikstack, der nicht optimal ist und vermutlich gibt es weitere Gründe, wieso Linux auf dem Desktop keine Verbreitung hat. Das ist mir aber total egal. Linux auf dem Desktop habe ich für mich persönlich abgeschlossen. Linux auf dem Server aber nicht. Ich finde den Workflow weiterhin sehr gut und nein, ich finde ihn am besten. Deswegen steh ich ja auch auf WSL. Ich habe nicht das Gefühl etwas zu vermissen. Ohne WSL hätte ich das Gefühl vermutlich.

So weiter gehts!


Pharo 6 veröffentlicht


Smalltalk ist ja uralt, aber wer Smalltalk modern erleben will, kann mal Pharo ausprobieren. Dabei handelt es sich um eine moderne Implementation von Smalltalk. Im Grunde eine Abspaltung von Squeak, aber das ist ja egal.

Pharo ist extrem gut dokumentiert, es gibt sogar ein MOOC und wer es dann immer noch nicht verstanden hat, kann sich wieder schlafen legen. Für mich fühlt sich das, wie fast alle Smalltalks zu "hoch" an. Ich fühle mich da nicht wohl; es überkommt mich immer das Gefühl, als wenn ich nicht die volle Kontrolle habe.

Pharo gibt es für Windows, Linux und macOS.


Der Soundcloud Player ist zu fett


Ich bin ja eigentlich der erste, der über zu fette Websites meckert und um so erschrockener war ich, wie viel "Zeug" der embedded Soundcloud Player nachlädt. Pro Player, den ich embedde, werden ca. 30 HTTP Requests zu Soundcloud gemacht. Wenn ich den Player also 2x einbinde, werden tatsächlich 60 HTTP Requests gemacht. Aber auch von den Datenmengen ist das irgendwie gruselig. Wenn ich den Player einbinde, so lädt er ca. 3.7MB runter. Wenn ich den Player 2x einbinde, so musst du als Besucher fast 8MB runterladen und das nur wegen dem Player. Ich persönlich merke das gar nicht, weil ich einen relativ schnellen Internetzugang habe; hier zu Hause, aber auch mobil.

Ich habe also erst Mal den Standard Audio-Player des Webbrowsers integriert. Damit bin ich dann bei wenigen KiloBytes.


Archiv nach Kalenderwochen


2017/KW24, 2017/KW23, 2017/KW22, 2017/KW21, 2017/KW20, 2017/KW19, 2017/KW18, 2017/KW17, 2017/KW16, 2017/KW15, 2017/KW14, 2017/KW13, 2017/KW12, 2017/KW11, 2017/KW10, 2017/KW9, 2017/KW8, 2017/KW7


Startseite Podcast RSS Impressum