My Universe Logo

My Universe Blog » Entries Tagged as software

Fröhliches aus dem Leben eines SAP-Entwicklers

Posted by André Mühlnikel at April 29, 2010 11:04 p.m.

Wer selbst im SAP-Coding unterwegs ist, kennt das: immer wieder stößt man auf allerlei Merkwürdigkeiten („Hey, warum nur einmal den Wert zuweisen? Doppelt hält besser!“). Doch was ein Kollege heute fand, ist mal echt was anderes. Und es zeigt, mit was für Leuten man in der SAP-Anwendungsentwicklung mitunter so zu tun hat … Hab jedenfalls gut gelacht :-)

/assets/user/andre/img/jpg/SAP_Comment.jpg

No comments | Defined tags for this entry: ABAP, development, humor, programming, SAP, software, fun

Beasty, jEdit, Hex und Heap

Posted by Jesco Freund at June 27, 2009 9:58 a.m.

Seitdem ich KDE den Laufpass gegeben habe, setze ich wieder verstärkt jEdit als Kate-Ersatz ein. Dabei geht es mir nicht so sehr um die Editor-Komponente (dafür habe ich schließlich vim ;-) ), sondern um die vielen mehr oder minder nützlichen Plugins. Eines davon ist „Hex“ von André Kaplan und Matthieu Casanova – damit kann man aus dem File Manager Plugin heraus direkt Dateien als Hexdump ausgeben lassen. Nützlich, wenn man mal Dateien im Binär-Format analysieren möchte oder muss.

Eben wollte ich mir einige MP3-Dateien anschauen, um herauszufinden, warum die darin enthaltenen ID3-Tags nicht korrekt erkannt wurden. Hex wollte mir den Gefallen aber nicht tun und verweigerte den Dienst. Ursache: Der Heap-Speicher war zu klein. Das ist bei Java-Programmen ansich kein ungewöhnliches Problem; lustig in diesem Fall ist jedoch, dass es offensichtlich vom FreeBSD-Port selbst verursacht wurde. Dieser stellt nämlich ein Wrapper-Skript zum starten von jEdit bereit, in dem jedoch eine Heap Size von 32 MB fest verdrahtet ist. Also mit dem anderen Editor flugs auf das Wrapper-Skript losgegangen, und schon kann jEdit auch mit richtig großen Buffers arbeiten :-)

#!/bin/sh
# $FreeBSD: ports/editors/jedit-devel/files/jedit.sh.in,v 1.1 2005/02/21 23:28:42 hq Exp $

# Java heap size, in megabytes
JAVA_HEAP_SIZE=256               # hier stehen im Original-Skript jaemmerliche 32 (MB)

JAVA_VERSION="1.4+" "/usr/local/bin/java" -mx${JAVA_HEAP_SIZE}m ${JEDIT} -jar "/usr/local/share/java/jedit/jedit.jar" "$@"

No comments | Defined tags for this entry: FreeBSD, software

Erstes Release von jail-update

Posted by Jesco Freund at May 15, 2009 10:41 p.m.

Im Rahmen des root-tools Projekts habe ich ein kleines Skript namens jail-update entwickelt, das es Admin erleichtert, alle laufenden Jails mittels portaudit auf verwundbare Pakete zu prüfen, verfügbare Updates aufzulisten und diese ggf. zu installieren. Nachdem ich in den letzten Wochen das Tool mit zufriedenstellenden Resultaten auf meinen Servern im Einsatz hatte, gibt es nun eine erste veröffentlichte Version (0.1.0) zum herunterladen. Feedback ist immer willkommen – gerne auch über den Projekt-Tracker

2 comments | Defined tags for this entry: jail, packet management, root-tools, software

Nur zum Surfen

Posted by Jesco Freund at May 1, 2009 3:50 p.m.

/assets/user/jfreund/img/png/thumb/128x128/arora.png

Arora ist ein schlichter, Qt-basierter Browser für Web-Puristen. Arora bringt alle Dinge mit, die heute zum bequemen Surfen notwendig sind, etwa Tabbed Browsing oder eine schnelle JavaScript-Engine. XHTML-Seiten mit CSS-Formatierung werden weitgehend fehlerfrei dargestellt (auch wenn in meinem Blog ein Box-Überlauf nicht korrekt gehandhabt wird, aber das fällt kaum ins Gewicht). Auf Java- oder Flash-Unterstützung muss man allerdings verzichten – für mich jedoch kein großer Verlust (unter FreeBSD funktioniert Flash sowieso nicht oder nur sehr eingeschränkt).

Im Vergleich zu Firefox oder Opera ist Arora sehr schlank: Der Quellcode umfasst gerade mal ca. 10.000 Zeilen, das Source-Archiv ist beim Download gerade mal 658 KB groß. Im direkten Vergleich ist das allerdings gemogelt: Arora verwendet QtWebKit; dieses ist natürlich nicht im Arora-Code enthalten, sondern wird dynamisch gelinkt. So kommt es auch, dass der Memory Footprint gar nicht so schlank ausfällt, wie man vielleicht zunächst vermuten möchte: Bei einem geöffneten Tab mit einer XHTML-/CSS-Seite ohne JavaScript (wie im Screenshot gezeigt) verfrühstückt Arora bereits über 40 MB Arbeitsspeicher. Firefox benötigt für dieselbe Aufgabe gerade mal 8 MB mehr. Spannend wird es allerdings, wenn man mehrere Tabs öffnet: bei 7 parallel geöffneten unterschiedlichen Seiten kommt Arora auf etwa 60 MB, während Opera bereits mehr als das Doppelte (ca. 130 MB) konsumiert. Firefox hingegen bleibt ähnlich genügsam wie Arora.

Fazit: Ich bin von Arora positiv überrascht, hätte ich doch nicht erwartet, dass eines dieser Nischen-Browserprojekte tatsächlich einen verwendbaren Webflitzer hervorbringen könnte. Arora ist ein Browser für Surfer, die in einer Qt-basierten Umgebung wie etwa KDE zu Hause sind und Wert auf einen schnellen Browser ohne Schnickschnack legen. Der relativ übersichtliche Code und die fehlenden Plugins dürften Arora zu einem robusten Browser machen, dem mit bösen Scherzen von Serverseite aus so schnell nicht beizukommen ist.

No comments | Defined tags for this entry: browser, software

Aus dem Leben eines ABAP-Programmieres

Posted by André Mühlnikel at April 20, 2009 8:17 p.m.

WAAAAAAAH. Tschuldige. Musste mal gesagt werden. Hier die lange Version:

continue reading Aus dem Leben eines ABAP-Programmieres

No comments | Defined tags for this entry: ABAP, algorithms, bizarre, software

MSYS – eine schlanke Alternative zu Cygwin

Posted by Jesco Freund at Feb. 24, 2009 10:11 a.m.

/assets/user/jfreund/img/png/thumb/128x128/msys.png

Unter Windows zu arbeiten kann manchmal recht nervig sein – insbesondere dann, wenn man Aufgaben zu erledigen hat, die sich in gewohnter Umgebung sehr fix erledigen lassen. Egal ob es „nur“ um Aufrufe von CLI-Programmen (gcc & Co) oder um die Bearbeitung umfangreicher Daten-Dumps geht: cmd.exe saugt. Die maximal darstellbare Anzahl Zeichen pro Zeile ist fest verdrahtet, Tab Completion gibt es erst ab Windows XP (ich habe hier noch W2K im Einsatz), Pipes sind ein Wunsch-, Schleifen ein Albtraum, und Werkzeuge vergleichbar grep oder awk sucht man vergeblich.

Mit Cygwin ließe sich dem recht einfach abhelfen, aber es gibt eine kompaktere Alternative: MSYS. MSYS ist Bestandteil des MinGW-Projekts. Anders als Cygwin bietet es nur einen auf Windows portierten Terminal-Emulator (rxvt) und keinen kompletten X-Server. Als einzige Shell steht die GNU Bash zur Verfügung, ergänzt um die üblichen Verdächtigen (Coreutils, awk, grep, sed). Als Goodies finden sich allerdings auch Perl, der OpenSSH Client nebst Agent und Key Generator, Vim und die GNU Autotools im Paket. Die Versionen sind allerdings recht steinzeitlich – Perl ist mit Version 5.6 noch am aktuellsten, während OpenSSH mit Version 2.9 schon sehr dick verstaubt ist (immerhin beherrscht diese Version schon SSHv2, sonst wäre der Client wohl vollends unbrauchbar). Andere Werkzeuge wie GNU make oder die Bash selbst sind hingegen erstaunlich aktuell. Aktualisierte Pakete und weitere Werkzeuge findet man im SourceForge-Repository des MinGW-Projekts.

Fazit: Wer nur eine Shell zum arbeiten benötigt und auf einen auf Windows portierten X-Server verzichten kann, sollte durchaus mal einen Blick auf MSYS werfen. Insbesondere mit den Supplementary Tools lässt sich MSYS zu einer vollwertigen Shell-Arbeitsumgebung aufrüsten. Die Werkzeug-Zusammenstellung zielt zwar stark in Richtung Entwicklung mit MinGW (dafür wurde die Umgebung eben gebaut…), lässt sich aber auch hervorragend für generische Aufgaben einsetzen. Dank Perl und den Klassikern sed, awk und grep werde ich in naher Zukunft jedenfalls keine VBA-Makros mehr benötigen, um Datendumps umzumodeln…

No comments | Defined tags for this entry: open source, shell, software, unix

Monster-Upgrade

Posted by Jesco Freund at Feb. 12, 2009 6:36 p.m.

In den FreeBSD-Ports hat sich eine Menge getan. KDE 4.2 ist da, Xorg ist auf Version 7.4 geklettert – von den vielen kleineren Ports mit Neuerungen mal ganz zu schweigen. Da ich das Upgrade auf KDE 4.1.4 ausgelassen hatte, war die Liste der zu erneuernden Ports entsprechend lang. Also habe ich die Gelegenheit beim Schopf gepackt, auch endlich den vermurksten Mix aus GTK-, QT3- und QT4-abhängigen Anwendungen auszumisten. Also alle installierten Ports gelöscht, /usr/local sowie /var/db/ports und /var/db/pkg geputzt. Die anschließende Neuinstallation von X und KDE 4.2 (plus vim, most und was man halt so braucht) hat etwa 18 Stunden Kompilierzeit gefressen, mir im Gegenzug aber ein hübsch sauberes und ordentliches System beschert.

Ob es an KDE 4.2 oder am neuen X-Server liegt, vermag ich nicht zu sagen – aber seit dem Upgrade läuft die KDE-Oberfläche richtig flüssig; auch diverse Desktop-Effekte (Transparenz, animierte Arbeitsflächenumschaltung, etc), die unter KDE 4.1 den Rechner noch in die Knie gezwungen haben, laufen jetzt richtig flüssig, ohne Ruckelei und ohne die CPU allzu sehr zu belasten. Ein Upgrade lohnt also schon allein aus Performance-Gründen, auch wenn einige andere Dinge noch nicht so 100%ig rund sind: Mit Umlauten in Fenstertiteln oder Menüs kann KDE nicht so recht umgehen (trotz korrekt gesetzter Locale), KDM ignoriert Locale-Vorgaben sogar ganz. Insgesamt gefällt mir Version 4.2 aber deutlich besser als noch die Vorgänger-Version.

1 comment | Defined tags for this entry: FreeBSD, KDE, software

Solaris: Wie man eine kaputte Blastwave/CSW-Installation repariert

Posted by Jesco Freund at Feb. 10, 2009 10:20 p.m.

OK, in diese Verlegenheit kommt man vielleicht nur, wenn man dumm genug war zu glauben, man könne alle Blastwave-Bestandteile restlos tilgen, indem man die Verzeichnisse /opt/csw, /var/opt/csw und /etc/opt/csw löscht. Dem ist allerdings mitnichten so – nach einer Neuinstallation glaubt pkgutil immer noch an das Vorhandensein der alten Packages. Natürlich stirbt jedes neu installierte Binary dann an akutem Bibliotheksmangel, weil gettext, iconv und Konsorten einfach nicht mehr aufzutreiben sind.

Da mein eigentlicher Plan darin bestand, das seit einem Jahr von mir nicht mehr gepflegte CSW-Geraffel komplett zu entsorgen und dann noch mal frisch zu installieren, musste ich einen anderen Weg finden. In den chaotischen Wirren des Solaris-Dateisystembaums nach der CSW-Datenbank zu fahnden, habe ich recht fix aufgegeben. Einfacher ist es, pkgutil gemäß Anleitung zu installieren und es mit folgendem Aufruf auf alle installiert geglaubten Packages loszulassen (zsh, bash o. ä. verwenden, funktioniert so nicht mit (jeder) sh oder csh!):

/opt/csw/bin/pkgutil -y -r $(pkgutil -c | awk '{print $1}' | grep -v 'package')

Da pkgutil sich so gleich selbst mit deinstalliert (genauso wie übrigens CSWcommon, also die CSW Basisverzeichnisse), ist anschließend noch mal eine Neuinstallation nötig – danach lassen sich wieder problemlos Pakete installieren; Abhängigkeiten werden korrekt aufgelöst und mit installiert.

No comments | Defined tags for this entry: packet management, software, Solaris, Sun

Trac vs. Redmine

Posted by Jesco Freund at Oct. 26, 2008 7:46 p.m.

Keine Sorge, das hier wird nicht die x-tausendste Neuauflage des „bisher habe ich Trac benutzt, aber jetzt mach ich Redmine weil das ja viel geiler ist“ Gequatsche. Momentan wandern einige Projekte von Trac zu Redmine (wie z. B. Lighttpd), und deshalb wollte ich wissen, was wirklich dran ist an den Vorzügen von Redmine. Tja, was soll ich sagen – Redmine hat sich einer Beurteilung geschickt entzogen. Meine sämtlichen Versuche, unter FreeBSD und Gentoo Linux eine lauffähige Produktionsumgebung aufzusetzen, sind bisher gescheitert. Probiert habe ich mit Redmine 0.7.3 sowie mit dem aktuellen Stand aus Subversion (-r1953), jeweils mit einer passenden Rails-Umgebung.

Unter FreeBSD verweigerte das Release die Zusammenarbeit mit PostgreSQL (trotz korrekt installierter Bindings). Der Snapshot nahm diese Hürde hingegen problemlos und ließ sich per WEBrick auch in Betrieb nehmen. Allerdings wollte er partout nicht per FastCGI mit Lighttpd zusammenarbeiten (wiederum trotz vorhandener FastCGI-Bindings für Ruby), was allerdings für mich Voraussetzung für den Produktivbetrieb wäre. Unter Gentoo Linux habe ich beide Versionen mangels installiertem RDBMS mit SQLite3 konfiguriert, was im Testbetrieb mit WEBrick anstandslos funktionierte. Aber auch hier war an eine Zusammenarbeit mit Lighttpd nicht zu denken. Zwar wurden die FastCGI-Prozesse korrekt erzeugt, aber nach ein paar Sekunden verabschieden sie sich in Status defunct; Ursache bis dato unbekannt.

Fazit: Soweit ich das aus den Tests mit WEBrick beurteilen kann, hat Redmine durchaus interessante Features, bietet aber im wesentlichen auch nicht viel mehr, als Trac mit entsprechenden Plugins leisten kann (das Argument „mehrere Projekte“ zählt in meinen Augen nicht, da Trac für die Verwaltung mehrerer Projekte mit seinen Environments schlicht eine andere Strategie verfolgt als Redmine). Allerdings ist Redmine noch nicht so stabil und problemlos in der Installation wie Trac – von den grausamen Abhängigkeiten (genau Version X von Tool Y) ganz zu schweigen. Ich werde Redmine zwar weiter auf dem Radar behalten, aber für den produktiven Einsatz bleibe ich erst mal bei Trac.

No comments | Defined tags for this entry: Redmine, software, Trac

Spielverderber

Posted by Jesco Freund at Oct. 5, 2008 7:46 p.m.

Auf zwei Neuerscheinungen für diesen Herbst habe ich mich richtig gefreut: Sacred 2 „Fallen Angel“ und Command & Conquer Red Alert 3. Zu meinem Entsetzen musste ich jetzt allerdings feststellen, dass beide Spiele mit dem berüchtigten Kopierschutz [1] SecuROM von Sony ausgeliefert werden bzw. werden sollen (RA 3 ist ja noch nicht im Handel). Um zu verstehen, warum ich so wenig begeistert von SecuROM bin, muss man sich kurz die Funktionsweise vor Augen führen:

SecuROM veranlasst während der Installation eine Online-Aktivierung beim Hersteller des Spiels. Dabei wird auch überprüft, wie häufig bzw. auf wie vielen verschiedenen Rechnern das Spiel bereits installiert wurde. Soweit ist das nichts neues, Microsoft geht ähnlich vor. C&C RA3 soll auf 5 Installationen begrenzt sein, Ascaron verzichtet auf diese Limitierung. Zusätzlich wird allerdings ein neuer Windows-Systemdienst installiert („SecuROM User Access Service (V7)“ – im Taskmanager als „UAService7.exe“ zu bewundern), der mit Administrator-Rechten (Ring 3) ausgeführt wird. Dieser Dienst wird permanent ausgeführt (auch wenn das Spiel gerade nicht verwendet wird) und wird auch bei der Deinstallation des Spiels nicht wieder vom Rechner entfernt. Einige Malware-Scanner bewerten den Dienst darüber hinaus als Rootkit, was aber angesichts der funktionalitätsbedingt (Stichwort: SCSI-Blacklisting) notwendigen interaktiven Eingriffe in Systemaufrufe nicht weiter verwunderlich sein dürfte.

Durch den Dienst in Verbindung mit der Aktivierung ist es möglich, das Spiel auch ohne Original-DVD im Laufwerk zu spielen. Damit ist der Umgang mit SecuROM-geschützter Software vordergründig etwas entspannter als bei klassischen datenträgergestützten Schutzverfahren. Warum also die Kritik? Zum einen gilt für den Aktivierungsmechanismus dasselbe wie bei Windows seit XP: nach einer gewissen Anzahl Aktivierungen muss man mit dem Hersteller in Kontakt treten, der dann darüber entscheidet, ob die Software weiter genutzt werden kann oder nicht. Somit erwirbt man beim Kauf des Spiels gar kein unbefristetes Nutzungsrecht, wie man es eigentlich von kommerzieller Software bisher gewohnt war.

Ein weiterer Nebeneffekt ergibt sich aus dem sog. „SCSI-Blacklisting“: Um die Verwendung von DVD- oder CD-Images in Verbindung mit Laufwerksemulatoren zu unterbinden, blockiert SecuROM den Zugriff auf emulierte SCSI-Geräte. Unangenehmer Weise wirkt sich dies auch auf Programme aus, die emulierte SCSI-Geräte zu legitimen Zwecken nutzen. Über Probleme wurde bereits bei der Verwendung der Brennsoftware Nero Burning ROM (bzw. deren Backup-Komponente) und in Einzelfällen auch mit SCSI-emulierenden USB-Geräten (Kartenleser u. ä.) berichtet.

Viel kritischer ist aber die Tatsache, dass der genannte Systemdienst regelmäßig den Hersteller über Internet kontaktiert. Welche Daten genau ausgetauscht werden, ist nicht bekannt, da die Kommunikation verschlüsselt erfolgt. Da durch die Aktivierung aber eine eindeutige Zuordnung zu einer Person gegeben ist, muss aus Datenschutzsicht das schlimmste befürchtet werden: Profiling. Da der SUAS permanent im Hintergrund läuft und über Administrator-Rechte verfügt, könnte er nicht nur verfolgen, mit welchen Programmen (und Spielen der Konkurrenz) der Anwender hantiert, sondern theoretisch auch beliebige Daten auf der Festplatte auslesen, Mails beim Schreiben oder Lesen mitschneiden und Passwörter ausspionieren. Kurz gesagt, im Zweifel könnte SecuROM all das, wovon BKA, BND und Verfassungsschutz zur Zeit träumen (Stichwort: Bundestrojaner). Und das beste daran: wir installieren uns den Mist sogar freiwillig…

Ich werde es mir jedenfalls sehr gut überlegen, ob die beiden Spiele noch einen weiteren Blick wert sind. Dass Sacred 2 mit einer entschäften Version (keine Limitierung der Anzahl an Aktivierungen) daher kommt, sollte nicht darüber hinwegtäuschen, dass damit noch lange nicht gesagt ist, dass keine Daten über das Nutzerverhalten gesammelt werden. Wenn ich die Rezensionen bei Amazon richtig deute, sehen dass viele andere Verbraucher ebenso. Hoffentlich reagieren die Hersteller – sonst könnten beide Spiele gewaltig floppen.

[1]Nachtrag für die Technical Correctness: SecuROM ist eigentlich kein Kopierschutz, da es nicht das kopieren der Datenträger ansich erschwert oder verhindert, sondern die Nutzung der Inhalte (in diesem Falle Software) kontrolliert und ggf. unterbindet. Damit fällt SecuROM in die Kategorie der DRM-Systeme.

2 comments | Defined tags for this entry: freedom, computer games, privacy, security, software

Page 1 of 3 next page »