Atsutane's blog

Another blog...

FrOSCon 2014 Summary

This year’s FrOSCon’s over, we had an unused booth (later used by someone for presenting emacs) and our own room, including some talks and a workshop. The talks were surprisingly well visited, we did not expect so many people to come. The original expectation was that we might be 15 people, but we got a larger room, probably a good decision by the organization team.

There are some things we can and should do better with future events, this years organization was – as always – really chaotic.

There are few things we did well and others we learned that we handled them… well bad is the proper term.

  • We need to give talks on each day we get a room. This year we only gave these on the first day and the second day the room was quiet. (Positive effect is the reogarnization of the SSL certificates.)

  • We have to give the talks in a better prepared way and not come up with the topics the weekend before the event and create the slides last-minute.

  • We used an Etherpad for organization of a todo list this was from my point of view well handled.

  • When we want to get a room skip a booth. We did not use the booth as we had no hardware to present something down there.

  • Merchandising, it’s every year the same, users want to get some merchandising. If I saw it correctly Debian sells T-Shirts, with german law we probably can’t do something like that to get a bit profit invested into our servers. To give away free stickers to actual users (not arrogant Fedora folks) might be an option, yet we would have to get them on our own costs. Another option would be to talk with the people from the merchandising booth at the entry.

  • When we give workshops we need a better organization, especially with installation stuff. I haven’t done an installation with the pacstrap script yet, leaving me in the same situation as someone new: How the heck do I initialize an installation.

FrOSCon 2014

For those who may miss to see us people downstairs next to some other distro/BSD: This year Arch Linux has its own room at FrOSCon, you’ll find us people in C125.

Bugs

tl;dr: Dieser Eintrag bietet nichts wirklich lehrreiches, sondern ausschließlich meine persönliche Meinung zu Beobachtungen im Umgang mit Fehlern bei der Entwicklung von Software. Für Studenten: Die Modelle beschreibe ich hier so, wie ich sie aus der Praxis kenne. Ich habe im WS 12/13 eine Vorlesung zu der Thematik besucht und mein damaliger Professor schüttelt sicherlich den Kopf, denn dies ist nicht die akademische Art, die er uns lehrte.

Mit Heartbleed hat es ein Bug geschafft, die Aufmerksamkeit der Gesellschaft auf die Entwicklung von Software zu lenken. Im Radio wird darüber gesprochen und in den meisten Tageszeitungen steht, man sollte umgehend seine Passwörter ändern, dass es sinnvoller ist zu warten, bis seitens der Administration eine Aussage existiert, ob eine betroffene OpenSSL Version/Variante eingesetzt und ersetzt wurde, wird hier völlig unter den Tisch fallen gelassen.

Heartbleed ist ein Fehler in OpenSource Software, eines der weitverbreiteten Pro-OpenSource Argumente ist, dass jeder in den Source schauen kann. Vielen Leuten sind über die Folgen des Fehlers verärgert und dementsprechend stark wird dieses Argument nun dafür genutzt wie schlecht doch OS ist und das dies nicht geschehen wäre, wäre die Software von einem großen Unternehmen geschrieben worden. Verweist man dann auf Microsofts derzeitigen Zero Day Exploit bei Internet Explorer Version 6 aufwärts kassiert man einen bösen Blick.

Der Umstand, dass auch dieser Fehler in einer kommerziellen Software weitreichende Konsequenzen hat und Microsoft sogar für das erst vor kurzem aus der Wartung entfernte Windows XP nochmals ein Update veröffentlicht, zeigt aber: Wenn nur wenige Leute darauf schauen passieren Fehler und bleiben lange bestehen. Ob Software nun OpenSource Software ist oder das kommerzielle Produkt eines Unternehmens, dass den Kunden keinen Einblick in den Code gewährt macht keinen Unterschied, wenn sich nur wenige Personen die Quelltexte anschauen. Bei OpenSource hofft man einfach, dass es genug andere machen und bei kommerzieller Software eines Konzerns mit mehreren tausend Mitarbeitern sind es vielleicht auch nur fünf Entwickler, welche für das Produkt zuständig sind.

Zur Vermeidung von Fehlern in Software gibt es verschiedene Möglichkeiten, welche sich auch kombinieren lassen. Zum Beispiel testgetriebene Entwicklung, es werden zuerst die Tests geschrieben, anschließend Code der diese Tests besteht. Diese Art von Tests prüft aber letzten Endes auch nur, ob die Ergebnisse der Software die erwarteten sind. Je fein granulierter die Tests sind lässt sich so natürlich einiges an Fehlern vermeiden und aufspüren, es wird aber hautsächlich geprüft, ob die tatsächlichen Ergebnisse den erwarteten entsprechen. Wird hier vergessen einen fehlerhaften Use-Case zu prüfen kann es dennoch zu Fehlern kommen. Genau solch eine Verifikation ist ja das Problem des Heartbleed Bugs, es wurde nicht geprüft, ob die Parameter zusammenpassen.

Eine weitere technische Möglichkeit ist die Statische Code Analyse mittels entsprechender Software, diese klopft den Code nach gewissen Mustern ab und findet so zum Beispiel Speicherlecks, wenn Speicher allokiert, nur in der Funktion verwendet und nicht wieder frei gegeben wird.

Und dann eben auch das im Bereich der OpenSource Software weit verbreitete Modell: manuelle Code Reviews von Patches. Prinzipiell ist dies eigentlich auch eine statische Code Analyse, nur wird hier nicht immer wieder der gesamte Code betrachtet, sondern nur die vorgenommenen Änderungen. Dies geschieht durch eine oder mehrere Personen und erhöht dadurch die Chance, dass Fehler dadurch vermieden werden, dass die prüfende Person nicht den Code geschrieben hat und ihn daher anders liest. OpenSSL nutzt dieses Verfahren und auch der Linux Kernel wird so entwickelt, bei Unternehmen ist dies abhängig von Richtlinien des Unternehmens und der Abteilungen.

Das Pair Programming Modell ist ähnlich der Code Reviews, hier arbeiten zwei Entwickler zusammen, während ein Entwickler den Code schreibt schaut der andere mit auf den Schirm und weißt auf Fehler/Möglichkeiten zur Verbesserung hin. Klingt eigentlich ganz gut und lässt sich mitunter auch durchführen, nur wird dies in den meisten Unternehmen wahrscheinlich eher als eine Bremse bei der Produktion gesehen und im OpenSource Umfeld… Ich bezweifle einfach mal, dass wenn jemand aus Kanada den Bildschirm shared, um die Uhrzeit jemand aus Holland bei der Entwicklung zuschauen möchte.

Es gibt noch andere Möglichkeiten zur Vermeidung von Fehlern, aber Fehler passieren. Wenn ein Programm selbst fehlerfreien Code hat, gibt es immer noch viele Faktoren, die zu Fehlern führen können. Optimierungen durch Compiler, Updates von Betriebssystemen oder Fehler bei der Hardware. Es ist vor allem wichtig, wie auf Fehler reagiert wird. AVM hat Anfang des Jahres, umgehend für viele Modelle ihrer Router, auch jener welche seit Jahren nichtmehr verkauft werden Firmware Updates entwickelt und bereitgestellt. Von vielen anderen Herstellern liest man seit Monaten von offenen Ports und Netgear hat ein Problem ja auch nur versteckt. Bei Videospielen sieht man ähnliches, kleine Entwicklerstudios patchen ihre Spiele regelmäßig und versuchen Fehler zu vermeiden, bei großen Studios und Publishern kommt unfertige Software auf den Markt, wird teuer verkauft und bis auf das Marketing ist dann alles irrelevant, der Nachfolger kommt ja im nächsten Jahr.

Distri a Ist Toller Als B

Sie tauchen alle paar Wochen in meinem Feedreader auf, subjektive Bewertungen warum die Linux Distribution A besser als die Distribution B ist. Bleiben diese Vergleiche sachlich und weisen auf Stärken und Schwächen der unterschiedlichen Systeme hin, sind diese Texte ja durchaus lesenswert und interessant. Man wird auf Dinge hingewiesen, denen man selbst bisher vielleicht gar keine Beachtung geschenkt hat. Leider sind das die wenigsten Posts.

Die meisten sind schlicht emotionale Texte, leider oft auch lächerlich. Es werden Dinge miteinander verglichen, ohne dass der Kontext berücksichtigt wird. Ja, eine Distribution, welche binäre Packete bereitstellt ist für die meisten Personen im Alltag angenehmer zu verwenden, als ein Linux From Scratch System zu pflegen. Diese Personen gehören aber auch nicht unbedingt zur LFS Zielgruppe.

Andererseits sind es gerade diese Texte, welche unterhalten und die Stimmung heben können. Wenn man dann am Abend die Nachrichten des Tages gelesen hat und sich fragen muss, wie fern der Realität denn so mancher Politiker lebt, sind es Posts, bei denen es um relativ belanglose Dinge wie den Installer geht, die mir den Abend versüßen. Denn hey, da mögen Kernel und Userspace zwar identisch sein, aber der Installer, den man so oft nutzen muss, der gefällt mir nicht!

Insofern: Vielen Dank, wo bleiben die Posts, dass SteamOS so viel toller als Distribution C ist? :–)

Ein Neuer Blog / a New Blog

Ein neuer Server, ein neuer Blog. Es war ruhig geworden und auch hier wird nicht andauernd etwas Neues stehen, aber ein Ort an dem man seinen Gedanken mal freien Lauf lassen kann ist keine schlechte Sache. badboy_’s altes devbird wurde durch ein Octopress ersetzt und auch auf dem Server selbst läuft ein anderes OS, Arch Linux statt Debian. Manche Posts wird es in Deutsch und Englisch geben, andere nur in einer der Sprachen, aber ich werde die Anzahl von Posts die beide Sprachen vereinen gering halten.

A new server, a new blog. The old blog became a silent place and this one also won’t make much noise, yet it’s not bad to have a place where someone can give his thoughts some freedom. badboy_’s old devbird has been replaced by Octopress and the server also runs another OS, Arch Linux instead of Debian. Some posts will be written in german and english, others just in one of the languages, but I will keep the amount of “merged” posts – like this – at a low level.

Be aware that all posts will be tagged with the language they’ve been written in: deutsch and english.

Irssi, Screen and Urxvt - the Urgency Hint

A lot of i3 users miss a workspace notification when they are being highlighted in an IRC channel, in order to prevent people from getting tired of explaining this short setup over and over again I wrote this article in my old blog. As it’s still visited a lot it obviously survives the server move and enters also this blog.

For screen you only have to disable the vbell in the screenrc:

~/.screenrc
1
vbell off

UPDATE 20131027: nille made me aware of the fact, that it’s possible to change the vbell state in a screen session using the C-a C-g key combo.

When you use urxvt as a terminal the urgentOnBell option has to be activated in the Xdefaults file. In case you use an other terminal take a look at the respective documentation.

~/.Xdefaults
1
URxvt*urgentOnBell: true

For irssi there are two ways to handle this. If you have a running instance you can set this by using these commands:

irssi commands
1
2
3
4
5
/set bell_beeps on
/set beep_when_away on
/set beep_when_window_active on
/set beep_msg_level HILIGHT INVITES MSGS NOTICES CTCPS DCC DCCMSGS
/save

Or alternatively by editing the configuration:

~/.irssi/config
1
2
3
4
5
6
7
8
9
settings = {
#...
  "fe-common/core" = {
    bell_beeps = "yes";
    beep_when_away = "yes";
    beep_when_window_active = "yes";
    beep_msg_level = "HILIGHT INVITES MSGS NOTICES CTCPS DCC DCCMSGS"
  }
}