Archive zu Kategorie 'Software'
22. August 2010 von KG
Immer wieder kommt es vor, dass Dateien, die jemand unter Windows in ein Archiv (insb. zip und 7-zip) gepackt und mir geschickt hat, in den Dateinamen nach dem Entpacken anstelle bestimmter Sonderzeichen (Umlaute oder Akzente) lediglich Platzhalter aufweisen (auf Terminals normalerweise ein ‘?’ [Fragezeichen] unter Nautilus üblicherweise dieses Zeichen: ‘’ [was auch immer]).
Abhilfe schafft convmv (kann auf allen größeren Distributionen über den jeweiligen Paketmanager installiert werden).
Bei mir hilft normalerweise folgender Befehl, um sämtliche Dateinamen (inkl. Verzeichnisnamen) rekursiv zu konvertieren(–notest auslassen, um das Ergebnis zuvor zu prüfen):
convmv -f cp852 -t utf8 --nfc -r --notest [Pfad]
Mit
convmv --list
werden alle unterstützten Encodings angezeigt.
7. August 2010 von KG
Als Eigentümer eines HTC Desire bin ich sehr an dem Update auf das aktuelle Android-Betriebssystem FroYo (“Frozen Yogurth”) interessiert. Da mein Gerät aber kein Original-ROM von HTC aufweist, sondern offenbar von T-Mobile UK stammt (was lediglich in einem unterschiedlichen Bootlogo und -geräusch und T-Mobile-Lesezeichen zu erkennen ist), scheint mir das Update für längere Zeit vorenthalten zu bleiben: HTC verteilt die Over-The-Air (OTA-) Updates lediglich für Geräte mit einem Original-ROM.
Um das Update zu erhalten, versuche ich nun, das T-Mobile-ROM durch ein originales ROM zu ersetzen (im Jargon: zu “debranden”).
Hierzu benötigt man eine “Goldcard”, eine speziell präparierte Micro-SD-Karte.
Dazu gehe ich wie folgt vor (in diesem Fall auf einem Windows XP SP3 mit Administratorrechten, da mir kein anderer Rechner zur Verfügung steht):
HTC Desire Debranding
Goldcard-Image holen:
- Inhalt der Micro-SD-Card gesichert.
- Micro-SD-Card mit FAT32 formatiert.
- GoldCard Helper auf dem HTC Desire installiert.
- Micro-SD-Card eingelegt und GoldCard Helper aufgerufen.
- Reverse-CID auf PSAS eingegeben, E-Mail-Adresse mitgeteilt und rückwendend E-Mail mit dem GoldCard-Image erhalten.
- Micro-SD-Card aus dem Mobiltelefon entfernt, in einen Cardreader gesteckt und mit dem Rechner verbunden.
- HxD aufgerufen und über Extras->Datenträger öffnen die als Laufwerk eingebundene Micro-SD-Card unter Physische Datenträger geöffnet, dabei die Checkbox Schreibgeschützt öffnen deselektiert.
- Im HxD über Extras->Datenträgerabbild öffnen das lokal gespeicherte GoldCard-Image (Dateiname goldcard.img) geöffnet und alle Zeilen bis einschließlich 170 markiert und kopiert (Strg+c).
- Im HxD jetzt zum Micro-SD-Card-Laufwerk gewechselt, die Zeilen bis einschließlich 170 markiert und Bearbeiten->Einfügen gewählt (Strg+v).
- Jetzt in HxD gespeichert (Strg+s) und den Warnhinweis bestätigt.
Das Entnehmen und Wiedereinfügen der Micro-SD-Card ergibt beim erneuten Öffnen mit HxD, dass sich die Zeilen bis einschließlich 170 jetzt tatsächlich dem GoldCard-Image entsprechen. (Anmerkung dazu: Beim einem Versuch mit der im Telefon eingelegten Karte und Verbindung über USB wurden die Bytes 04-07 in Zeile 100 nicht überschrieben, dies funktionierte erst bei der Verbindung über den Kartenadapter.).
Jetzt die Karte (nun eine GoldCard 
) wieder ins Desire eingelegt, das Gerät gestartet und das aktuelle 2.1-ROM installiert (vorher insbesondere SMS und MMS und ggf. Kontakte sichern!), das ist zur Zeit: RUU_Bravo_HTC_WWE_1.21.405.2_Radio_32.36.00.28U_4.06.00.02_2_release_126984_signed.exe.
(RUU steht für “ROM Upgrade Utility” – man muss das ROM nicht manuell übertragen/flashen, sondern wird assistentenbasiert geführt.).
Das funktionierte alles soweit – das Desire bootet mit dem ROM ohne Branding. Allein – beim Versuch, manuell über Einstellungen->Telefoninfo->Systemsoftware-Updates->Jetzt prüfen zu aktualisieren, folgt die Fehlermeldung “Das Telefon befindet sich auf dem neuesten Stand – Es stehen keine Updates für das Handy zur Verfügung.”
Hm. Sehr unerfreulich. Der Versuch mit einem anderen ROM scheiterte ebenfalls. Möglicherweise liegt das daran, dass bei HTC die IMEIs der Information zugeordnet sind, ob es sich um ein gebrandetes Modell handelt. Vielleicht habe ich auch etwas falsch gemacht.
Wie auch immer, ein Artikel auf handy-faq.de überzeugt mich, das Update über ein gerootetes OS zu beziehen.
HTC Desire rooten und mit Froyo versehen (unrEVOked-Methode)
unrEVOked bietet ein nettes Utility an, um bestimmte HTC-Geräte (u.a. das HTC Desire) einfach und “schmerzlos” zu rooten und beliebige ROMs aufzuspielen. Ich gehe wie folgt vor:
- HTC Sync auf dem Windows-XP-Rechner deinstallieren und Rechner neustarten.
- Auf dem Telefon die Option Einstellungen->Anwendungen->Entwicklung->USB-Debugging aktivieren.
- reflash_package.exe herunterladen und entpacken/installieren.
- Die Anleitungen zur Treiberinstallation in der Datei hboot driver.htm im entpackten Verzeichnis befolgen. Also im Wesentlichen: Telefon herunterfahren, mit gedrückter “Lautstärke verringern”-Taste einschalten (HBOOT), per USB anschließen und die Treiber im Unterverzeichnis hboot driver_files mit dem Treiberassistenten installieren.
- reflash.exe aufrufen. Der Rootvorgang erfolgt – sofern das Telefon erkannt wird – vollautomatisch zum Schluss sieht man eine Erfolgsmeldung.
- Jetzt folge ich den Anweisungen auf XDA-Developers. Also:
- 32.43.00.32U_5.09.00.20.zip downloaden und auf die SD-Karte des HTC Desire kopieren, ebenso Official_FroYo_Market_fixed.zip.
- Erneut das HTC Desire in den Recovery-Mode booten (Lautstärke verringern + Einschaltknopf).
- Mit nandroid das aktuelle ROM sichern. (Menüpunkte lassen sich mit den Lautstärketasten ansteuern, zum Auswählen auf den optischen Trackball drücken).
- Jetzt wipe data/factory reset wählen.
- Danach über das Menu install zip from sdcard das “Radio-ROM” 32.43.00.32U_5.09.00.20.zip installieren und erneut in den Recovery-Mode booten.
- Schließlich Froyo Official_FroYo_Market_fixed.zip über den Menüpunkt install zip from sdcard installieren.
Nach einem weiteren Neustart ist Froyo (Original-HTC mit wenigen Änderungen wie z.B. dem entfernten nervigen Bootsound) verfügbar .
Endlich kann ich auch screenshot verwenden:
22. Februar 2010 von KG
Auch wenn es einige gewichtige Argumente gegen Git gibt: Bei der Lektüre von Scott Chacons Buch Pro Git (gedruckte Version) wird mir das ganze Potential der postklassischen Versionskontrollsysteme klar: Auch wenn mir das Offline-Branching bislang immer am wichtigsten war (auf diese Weise kann ich im Zug einfach einen experimentellen Branch erstellen), bietet die Idee, stets das Repository bei sich zu führen (von Server-Hooks abgesehen), doch erheblich mehr Vorteile.
Zudem gefällt mir besonders gut, dass man Versionen einer Datei auch dann wiederherstellen kann, wenn der Branch (sollte eigentlich “das Branch” heißen, aber dagegen sträubt sich mein Sprachempfinden) gelöscht wurde. Das ist in Subversion z.B. nicht möglich. Ebenso ist das Konzept des “Staging” (geänderte Dateien werden erst nach einem expliziten Stage-Befehl committed [kann man auch deaktivieren]) für mich sehr nützlich – in Subversion habe ich bislang (vor allem graphisch) andersherum gerade in größeren Projekten gearbeitet: Aus der Fülle der geänderten Dateien musste ich immer die “herauspicken”, die nicht committet werden sollten, was sehr zeitraubend war. Jetzt geht es andersherum: Nur die Dateien, die wirklich wieder ins gemeinsame Repository sollen, gehen nach “Staging”, alle anderen bleiben erst einmal lokal.
Nun beleuchtet Zack Voase in seiner Gegenüberstellung des Quellcodes Gits und Mercurials, dass für eine vergleichbare Funktionalität ein Quellcodeverhältnis von 10 (Git) zu 1 (Mercurlal) vorhanden ist.
Da frage ich mich natürlich, wann endlich der Git-Nachfolger programmiert wird. Und zwar in Scala
1. September 2009 von KG
Ein Umstand, der in Unternehmen auf Entscheiderebene außerhalb des IT-Umfelds gerne verdrängt wird: Softwareentwickler sind Spezialisten und benötigen deshalb spezielle Hardware. Wer denkt, dass “Software schreiben” ungefähr mit dem Schreiben von Textdokumenten vergleichbar ist, liegt in etwa so richtig wie jemand, der meint, Autofahren hieße, auf einem Stuhl zu sitzen und beide Füße unregelmäßig auf- und abzubewegen.
Oberflächlich mag der typische Softwareentwickler Quellcode schreiben, was nicht so entfernt vom Schreiben von Textdateien zu sein scheint.
Tatsächlich ist der Quellcodeeditor nur ein Bestandteil von vielen, die die Integrierte Entwicklungsumgebung (“IDE”) eines Entwicklers ausmachen: Damit der Quellcode überhaupt ausgeführt werden kann, muss er kompiliert werden. Bisweilen muss ein Entwickler während der Ausführung des Programms an bestimmten Stellen den Ausführungsfluss Schritt-für-Schritt überwachen (“debuggen”), wozu die Anwendung in den Arbeitsspeicher geladen werden muss.
Der Quelltext bewegt sich auch nicht im luftleeren Raum: Anwendungen werden in Projekte und Bibliotheken aufgeteilt, häufig handelt es sich um einige hunderte bis tausende Dateien, die gemeinsam kompiliert und in den Arbeitsspeicher geladen werden müssen. Allein das Lesen der Quelltexte und das Erstellen der Kompilate kann bei mittelgroßen Anwendungen mehrere Minuten, bei größeren sogar viele Stunden andauern.
Auch wenn IDEs inkrementelles Kompilieren ermöglichen, wird des öfteren ein “Build” (alle Kompilate und dazugehörige Dateien) wieder gelöscht und vollständig neu erstellt.Zudem sind Softwareanwendungen im Unternehmensumfeld verteilt und kommunizieren mit Datenbanken, anderen Systemen und/oder der im Unternehmen eingesetzten Middleware.
Normalerweise ist der Entwickler bestrebt, auf seinem Rechner die Bedingungen, unter denen seine Anwendung später ausgeführt werden soll, en miniature nachzubilden: Auf diese Weise ist er unabhängig von Wartezeiten und kann ggf. auch offline (z.B. im Zug) arbeiten.
Was deshalb wirklich entscheidend für einen Entwicklerrechner?
Die Leistung:
Ein Softwareentwickler benötigt ein für seine Ansprüche äußerst leistungsfähiges System, was sich insbesondere auf
a) die Festplatte
b) den Hauptspeicher
c) die CPU und
d) Grafikkarte + Display bezieht.
Die Festplatte ist deshalb so wichtig, weil zum Erstellen von “Builds” oft tausende Dateien gelesen und geschrieben werden. Normalerweise liegt in langsamen Festplatten der Schwachpunkt von Entwicklersystemen (abgesehen von Virenscanner, die die Buildverzeichnisse überwachen). Sinnvoll können hier Solid State Discs (flash-basiert) oder RAID-Systeme (RAID 0 oder 0+1, aber nicht 5) mit SATA oder SAS sein, die den Datendurchsatz erhöhen.
Der Hauptspeicher muss sehr großzügig dimensioniert sein: Zur Zeit sollte ein Rechner für die Anwendungsentwicklung verteilter Systeme über mindestens 8 GByte Hauptspeicher verfügen, besser wäre gleich das Doppelte (einige Notebook-Workstations bieten mittlerweile 16 GByte an).
Softwareseitig bedingt dies den Einsatz von 64-Bit-Betriebssystemen.Wird mit virtuellen Maschinen gearbeitet (was immer mehr zunimmt), ist ein Mehrprozessor- wenigstens ein Multicoresystem sinnvoll. Um die Fülle an Informationen einer IDE wie Eclipse, Netbeans oder Qt auf einen Bildschirm zu bekommen, empfiehlt sich zudem ein hochauflösendes Display und eine entsprechende Grafikkarte.
Wie separat dargelegt, macht sich eine Leistungssteigerung bei Entwicklerrechnern schnell bezahlt. Um Entscheidern (und nach besserer Hardware strebenden Entwicklern) eine objektivere Entscheidungsgrundlage an die Hand zu geben, würde ich mir einen Benchmark wünschen, der
a) die Leistungsfähigkeit eines Systems hinsichtlich der o.a. Kriterien für einen Entwicklerrechner misst,
b) kostenlos verfügbar,
c) plattformunabhängig und
d) einfach bedienbar ist.
Ein Benchmark der mit Referenzprojekten arbeitet, der gängige IDEs startet, auf denen kleine, mittelgroße und große Referenzprojekte mit der IDE erstellt werden, wobei dies noch mit parallel laufenden Middlewareservern kombiniert werden sollte.
Falls jemandem ein solcher Benchmark bekannt ist, wäre ich dankbar für einen Hinweis ()! Interessenten, die ein derartiges Projekt auf die Beine stellen möchten, können mich gerne ansprechen.
30. August 2009 von KG
In Unternehmen verdrängen Entscheider außerhalb des IT-Umfelds gerne, dass Softwareentwickler Spezialisten sind und deshalb spezielle Hardware benötigen. Wer denkt, dass “Software schreiben” ungefähr mit dem Schreiben von Textdokumenten vergleichbar ist, liegt in etwa so richtig wie jemand, der meint, Autofahren hieße, auf einem Stuhl zu sitzen und beide Füße unregelmäßig auf- und abzubewegen.
Tatsächlich ist das Schreiben von Quellcode nur die Spitze des Eisbergs: Auf dem Entwicklerrechner wird dieser Quellcode nicht nur zu ausführbarer Software gemacht, sondern häufig eine vollständige Simulation der Unternehmensanwendungen ausgeführt, in deren Umgebung die Software verwendet werden soll. Also Datenbanken, Webserver, E-Mail-Server etc. etc.
Für den Entwicklerrechner bedeutet dies, dass er um ein Vielfaches leistungsfähiger sein muss als die Rechner, die man zur Erfüllung von Büroaufgaben verwendet.
Im Gegensatz zu Joel Spolsky statten viele Unternehmen ihre Softwareentwickler aber mit billiger Standardbürohardware aus. Meist muss schon die Aufrüstung des Arbeitsspeichers gesondert beantragt werden.
Was bedeutet das für die Entwickler? Vor allem müssen sie längere Wartezeiten in Kauf nehmen: Beim Kompilieren, beim Debuggen und Testen ihrer Anwendungen sowie beim Starten der IDE.
Was bedeutet das für die Unternehmen? Berechnen wir das einmal an einem Beispiel (aus meiner Praxis):
Die Entwickler eines größeren Finanzdienstleisters arbeiten mit Eclipse, die Anwendung wird in der Programmiersprache Java erstellt und ist in 10 voneinander abhängige Projekte (genauer: Maven-Module) gegliedert. Insgesamt handelt es sich um über viertausend Dateien, die kompiliert werden müssen (zuzügl. einiger Konfigurationsdateien).
Der durchschnittliche Rechner der Entwickler benötigt für das Erstellen eines Builds eine knappe halbe Stunde (mit Virenscanner über zweieinhalb Stunden).
In dieser Zeit können die Entwickler zumindest nicht programmieren, häufig nicht einmal mehr E-Mails lesen, weshalb der Arbeitsalltag so ausgerichtet ist, dass vollständige Builds zum einen vermieden und zum anderen auf den Morgen (Rechnerstart – Zeit für einen Kaffee) und die Mittagspause verlegt werden.
Im Team wird verteilt gearbeitet und regelmäßig integriert (d.h., Entwickler, die an Modul A arbeiten, stellen ihre Änderungen zur Verfügung, Entwickler, die an Modul B arbeiten, holen sich die aktualisierten Quelltexte von der Versionsverwaltung, was häufiger zur Folge hat, dass ein vollständiges Build erzeugt werden muss), wodurch zwei vollständige Builds am Tag die Regel sind.
Gehen wir vorsichtig von einem Durchschnittsgehalt von 60 T EUR für einen Entwickler mit mehr als sechs Jahren Berufserfahrung aus, ergeben sich folgende Kosten (Berechnungsgrundlage 223 Arbeitstage: 365 Kalendertage abzügl. Wochenenden (104 Tage), Feiertage (8 Tage) und Urlaub (30 Tage), 40-Stundenwoche):
Stundensatz
60.000 / 223 / 8 = 33,62 EUR
Auf zwei Builds zu je einer knappen halben Stunde am Tag bezogen bedeutete dies im ungünstigsten Fall (die Entwickler warten einfach nur, während das Build erstellt wird und sind ansonsten nicht weiter produktiv) jährliche Kosten von
223 x 33,62 EUR = 7.497,26 EUR pro Entwickler und
16 x 7.497,26 EUR = 119.956,16 EUR für das aus sechzehn Personen bestehende Team.
Die Verdopplung des Arbeitsspeichers und der Einbau schnellerer Festplatten bewirkte, dass ein vollständiges Build in gut 15 Minuten erstellt werden konnte.
Vergleicht man die Kosten für die Aufrüstung pro PC (450,- EUR für die Hardware, etwa 150,- EUR Personalkosten [Einbau durch Supporttechniker, Procurement] ) sieht man sofort, dass sich selbst bei einem geringeren Produktivitätsausfall als 100 % eine Investition in bessere Hardware schnell amortisiert:
Ersparnis rein rechnerisch:
119.956,16 EUR / 2* = 59978,08 EUR abzüglich 9.600,- EUR Hardwarekosten = 50.378,08 EUR
*Halbierung der Kompilierzeit
(Aufs Jahr bezogen wird somit eine Aufrüstung rentabel, sobald die festgestellte Produktivitätseinbuße bei über 8% liegt, was in jedem Fall gegeben ist.).
Weiterhin ist interessant, dass dieselben Rechner auch allen extenen Beratern zur Verfügung gestellt wurden. Deren Stundensatz lag dabei weitaus höher, wodurch sich die Investition noch schneller amortisierte.
Positive Seiteneffekte des Einsatzes leistungsfähigerer Entwicklerrechner sind zudem verbessertes Time-To-Market (offensichtlich) sowie ein besseres Betriebsklima (lange Buildzeiten frustrieren Entwickler, schnelle Rechner hingegen erfreuen sie).
27. Juni 2009 von KG
Das Bedürfnis, Reparaturen im Haushalt zu erledigen, wird mittlerweile bei vielen verdrängt durch den Wunsch, die eigene Software zu “reparieren”: Wir müssen die alltäglichen Anwendungen aktuell halten und das Betriebssystem, sogar für mobile Geräte; mal müssen Kontaktdaten gepflegt und von einem Social Network zum anderen synchronisiert werden, mal die Skindateien für den Audioplayer. Die Karten des Navigators sind aktuell zu halten und letztens kam der Kundendienst vorbei, um die Waschmaschine zu patchen.
Sicherlich werden Updates manchmal vereinfacht, sie sind unter Linux und vielen Open-Source-Anwendungen nicht so gräuslich umgesetzt wie die “Patch-Days” der Microsoft-Welt, die viele Angestellte kennen. Und fürchten.
Debians Paketaktualisierung oder die Aktualisierung des Firefox’ sind auf der Anwenderseite leicht umzusetzen. Und dennoch: Sie erfordern Aufmerksamkeit. Sie verlangen auf der Anwendungsebene meist, dass man die Anwendung neustartet, um die Aktualisierung zu erhalten. Das kostet Zeit und ggf. Nerven.
Und die Beschäftigung mit den Updates, vor allem den sicherheitskritischen, stellt eine weitere “Baustelle” dar, die einem vielleicht eine bessere, sicherere Software bringt, aber eines bestimmt nicht: Sinnvoll verbrachte Lebenszeit.
Hier mit dem Trade-Off zu argumentieren, man müsse noch viel mehr Zeit verbringen, wenn man sich aufgrund nicht aktualisierter Software mit Sicherheitslücken beschäftigen müsse etc., greift nicht: Die Aktualisierungen könnten auch so erfolgen, dass man nicht unterbrochen wird, sondern z.B. an einer zentralen Stelle sich die Information darüber holt (von mir aus als RSS-Feed vom Betriebssystem, der wiederum aggregiert wird aus den Updatemeldungen der Applikationen).
11. April 2009 von KG
Mit großer Freude kann ich mitteilen, dass endlich der Durchbruch bei meinem "Akkordpermutationsprogramm" erfolgte: Das Programm ist in der Lage, die möglichen 68.586.311 Akkorde zu berechnen und zu speichern, alle Testabfragen gegen die Datenbank liefen erfolgreich.
Der Quellcode ist auf Google Code veröffentlicht, wenn auch noch nicht "gesäubert".
Für mich rückt die Fertigstellung eines musikalischen Projekts, das mich nunmehr seit über zwanzig Jahren begleitet, wieder in den Bereich des Realen.
Die Berechnungszeit dauert nur noch etwa 2 Tage, der erforderliche Speicherplatz ~35 GByte (im Vergleich zu mehreren Wochen und mind. 120 GByte). Auch wenn ich sie liebgewonnen hatte, bin ich von der H2-DB wieder zu MySQL zurückgekehrt, da H2 offensichtlich kein Index-based Locking unterstützt und mit versetzten Transaktionen nicht zurechtkam.
Für alle Nichteingeweihten: Was das Programm bewirkt, warum es sinnvoll sein kann, über 68 Millionen Akkorde zu berechnen und zu speichern, folgt später in einem ausführlicheren Beitrag.
