Beiträge getagged mit Linux
Perle IOLAN und RXTXcomm (Java) unter Linux
Für unser aktuelles Projekt verwenden wir eine Perle IOLAN-Box. Die Box stellt serielle Ports – in unserem Fall sind das zwei Stück – über Ethernet zur Verfügung.
Der Einsatzbereich ist z.B. nötig, wenn man GSM-Modems in abgeschirmten Räumen (Rechenzentren, Bunkern) betreiben will. Die IOLAN-Box bildet eine Bridge zwischen Seriell- und Ethernet ab. So lässt sich das GSM-Modem (Seriell) an die IOLAN-Box (Seriell) anschließen, die wiederum über Ethernet an das Netzwerk angebunden ist. Für Linux und Windows existieren passende Programme, die nun lokal wiederum die Verbindung über das Netzwerk als serielles Interface abbilden.
Gestern stieß ich bei der Einrichtung der lokalen Schnittstellen auf ein Problem: RXTXComm – das Java-Framework zur Kommunikation mit seriellen/parallelen Schnittstellen – listete beim Start die /dev/tx00*-Devices nicht auf. Die FAQ von RXTX weist daraufhin, dass man per
System.setProperty(“gnu.io.rxtx.SerialPorts”, portFileNames) zusätzliche Ports definieren kann. Der Lösungsansatz brachte kein Erfolg.
Zweite Idee war dann, dass ich – wie in der FAQ beschrieben – die tx*-Devices manuell in die RXTXCommDriver.java eintrage. Auch das war nicht von Erfolg gekrönt.
Zeit zum Nörgeln: Warum Open Source besser ist als Closed Source
Verfasst von Schakko unter Open Source am 11. August 2009
Mit diesem Artikel möchte ich mal meine Sichtweise zum Thema Open Source / Closed Source niederlegen.
Generell gehöre ich zu der Sorte von Entwicklern, die ihre Software unter der BSD-Lizenz oder GPL veröffentlichen. Allerdings sage ich auch nicht, dass z.B. Treiber, die als Binary veröffentlicht werden, nicht in Linux integriert werden sollten.
Ich bin froh, wenn sich überhaupt Unternehmen die Mühe machen und Ressourcen binden, um die Portierung der Treiber nach Linux (BSD, MacOS, Solaris etc. – wenn ich im folgenden Text von Linux spreche, schließt dies diese Betriebssysteme einfach mal mit ein) voran zu treiben. Schließlich kann man so unter diesen Betriebssystemen neue und (oft) bessere Hardware schnell nutzen.
Die Entwicklung von Treibern nach dem altbekannten Ansatz des Reverse Engineerings, wie es z.B. bei Samba bis zur Veröffentlichung der Protokoll-Details von Microsoft der Fall war, nimmt einfach viel zu viel Zeit in Anspruch. Und Zeit ist Geld.
James Bottomley, Vorsitzender des TAB und SCSI Maintainer, hat letztes Jahr ein Essay herausgegeben, in dem er indirekt die Bereitstellung der Treiber-Quellcodes an die Community fordert. Intel und ATI sind bereits vor einiger Zeit mit ihren Treibern auf den Zug aufgesprungen.
Die Vorteile für Intel, ATI und andere Unternehmen, die ihre Quellen und Interface-Dokumentation veröffentlichen, liegen eigentlich auf der Hand:
- Es wird eine wesentlich breitere Nutzerbasis angesprochen. Gehen wir von einer neuen 10 GBit-Netzwerkkarte, die auf den Markt geworfen wird. Folgende Szenarien sind nun möglich:
- Die Treiber liegen nur in binärer Form für Windows-Plattformen vor.
Als Zielgruppe für die Nutzung dieser Karte wird man vor allem Rechenzentren oder Internet-Provider ansprechen wollen, die zum großen Teil auf Linux setzen. Es liegt ein eindeutiger #fail vor, da der Hersteller sich einen Großteil der Nutzerbasis versperrt. - Der Hersteller veröffentlicht die Schnittstellenbeschreibung.
Bleiben wir bei unserer Netzwerkkarte: Der Hersteller entschließt sich, die Treiber in binärer Form für Windows-Plattformen zu veröffentlichen. Zusätzlich legt er die Spezifikationen für die Hardware offen.
Ambitionierte Entwickler haben nun die Möglichkeit, den Treiber für Linux nachzubauen. Wichtig ist aber, dass es beim Hersteller immer einen Ansprechpartner für die Treiber-Entwicklung gibt, da oft die Dokumentation trotz merhmaliger Reviews Fehler enthalten kann. - Windows und Linux werden mit binären Treibern beliefert.
Beide “großen” Betriebssysteme werden mit Treibern in Form von Binärpaketen ausgeliefert. An sich nicht schlecht, schließlich hat nun eine große Zielgruppe die Möglichkeit, die darunter liegende Hardware einzusetzen.
Aber hier gibt es zwei gravierende Probleme: Auf der einen Seite werden – so habe ich zumindest das Gefühl – die Linux-Treiber als Abfallprodukt gesehen, die “mal so nebenbei” programmiert wurden. Viele Treiber-Entwickler kennen eher die Windows- als Linux-Umgebung. So kommt es, dass der Linux-Treiber Kernel-Panics auslöst oder ähnliches. Falls es mal Probleme mit dem Treiber geben sollte, wird dies (hoffentlich) zur Kenntnis genommen – aber eine baldige Lösung ist oft nicht in Sicht.
Das zweite große Problem besteht in den Regeln bzw. Lizenzen, die der Distribution zu Grund liegt. Unter Ubuntu ist es kein Problem, binäre properitäre Treiber aus einem anderem Repository nachzuinstallieren. Das Debian-Projekt würde hingegen niemals Treiber in binärer Form einbinden. - Der Treiber liegt in binärer Form und als Quellcode vor.
Ideal ist meiner Meinung nach die folgende Form: Der Treiber liegt für Windows und auch Linux in binärer Form vor, zusätzlich gibt es den Quellcode des Treibers zum Download. Entwickler seitens des Herstellers haben sich um die Dokumentation gekümmert und stehen als Ansprechpartner zur Verfügung.
In diesem Zuge muss ich ganz klar ATI mein Lob aussprechen, da sie den kompletten Schritt im Jahr 2008 vollzogen haben.
Wie schon geschrieben: Ideal wäre Konzept Numero 4. Leider hat sich NVidia gegen ein solches Vorgehen ausgesprochen. Die Absage wurde mit der Begründung erteilt, dass der Treiber geistiges Eigentum enthält. Mich würde interessieren, von welchem “geistigen Eigentum” NVidia spricht. Irgendwelche genialen Treiber-Optimierungen? Ein Quake-Easteregg, dass bei einer speziellen Auflösung aktiviert wird?
Meine Idee für eine kommende Hardware-Generation wäre die folgende: Alle Teile, die “geheim” sein sollen, werden direkt in der Hardware, z.B. mit Hilfe von FPGAs entwickelt. Die Hardware wird nun über weiter abstrahiertere Interfaces dem Kernel (Windows, Linux oder sonstwas) zur Verfügung gestellt. Bei einem Update der (Hardware-)Treiber profitieren alle Betriebssysteme. - Die Treiber liegen nur in binärer Form für Windows-Plattformen vor.
- Der Treiber wird durch die breitere Nutzerbasis von mehr Personen überprüft und auch getestet.
- Machen wir uns nichts vor: Linux-Benutzer sind zum größten Teil Frickler – ich zähle natürlich auch dazu. Viele Frickler sind bei einem Problem bereit, Zeit in die Lösung zu investieren und wenn nötig auch dafür neue Programmiersprachen oder Techniken zu erlernen.
Henrik Ibsen sagte mal “Weltverbesserer gibt es genug, aber einen Nagel richtig einschlagen können die wenigsten” – ich behaupte mal eher folgendes: “Frickler gibt es genug und die meisten probieren den Nagel einzuschlagen bis er wirklich sitzt.” - Durch die große Anzahl von Entwicklern, die Zugriff auf den Quellcode haben, lassen sich Features oder Performance-Optimierungen einfacher implementieren oder sich eben eine Grundlage für eine neue Grafikkarten-Generation schaffen.
Der Grund für diesen Post lieferte mir konkret NVidia. Vor einigen Wochen bestellte ich mir ein Zotac ION-Board, dass als Grundlage für meinen neuen Server und als DVD-Player dienen sollte.
Nun ist es aber so, dass mein Fernseher in Kombination mit dem HDMI-Ausgang des Boards einen extremen Overscan produziert, dass man von der gesamten Oberfläche 3/4 auf dem Fernseher sieht.
Sucht man in den Foren von NVidia nach “Overscan”, findet man massig Einträge, die sich damit befassen. Mich stört es ganz besonders, dass der Windows-Treiber die Möglichkeit bietet, das Overscanning zu neutralisieren. Dieses Feature ist aber unter Linux – in der äußerst armseeligen – Konfigurationsoberfläche nicht vorhande und lässt sich auch nicht per Xorg.conf vernünftig einstellen.
Ganz ehrlich: Hätte ich den Quellcode für den NVidia-Treiber, wäre ich bereit, mich des Themen “Treiber-Entwicklung unter Linux” und “Overscanning” zu stellen – so sehr stört mich dieser Bug.
Konvertieren von virtuellen Linux-VMware-Maschinen nach Citrix XEN Server
Verfasst von Schakko unter Linux, Virtualisierung am 15. Juli 2009
Wegen der Migration unserer virtuellen Server-Infrastruktur von VMware Server nach Citrix XEN Server 5.5 stieß ich auf ein Problem. Einer unser virtuellen Maschinen dient als Backup-Server und läuft unter Linux, in dem Fall unter Ubuntu 6.10 Server.
Zur Konvertierung der Maschinen dient das Tool XenConverter, das von Citrix kostenlos bereit gestellt wird.
Ich führte also die Konvertierung der VMDK-Datei aus, dies funktionierte soweit auch ohne Probleme, eben so klappte der Import in den Citrix XEN Server einwandfrei.
Beim Starten des Systems hing Linux allerdings mit der Meldung
Waiting for root file system...
VMware beschreibt in der Dokumentation, dass standardmäßig die Festplatten als SCSI-Devices gemountet werden sollen. Dies würde zu einer besseren Performance führen. Diesen Hinweis haben wir beim Einrichten aller virtuellen Maschinen unter VMware auch durchgeführt.
Allerdings bindet Citrix XEN Server nach dem Import die virtuellen Festplatten als normale IDE-Devices ein. Mir fiel das auch erst nach ein paar Minuten auf, nachdem ich über die vorher eingetragenen Boot-Meldungen schaute.
Die Lösung des Problems war dann relativ einfach umzusetzen:
- Virtuelle Maschine neu starten
- Während Grub lädt, ESC drücken
- Aktuellen Kernel auswählen
- /dev/sda1 durch /dev/hda1 ersetzen
- System booten und als root anmelden
- in der /boot/grub/menu.lst /dev/sda1 durch /dev/hda1 ersetzen, so dass die Änderungen permanent sind
MLG: Präsenzklausur bestanden / Spielzeug bestellt / Kernel-Patch
Verfasst von Schakko unter Active Directory / LDAP, Linux, Mathematisch-logische Grundlagen der Informatik, Webdesign & Web-Ergonomie, ckl-net am 24. Juni 2009
Ich wurde bereits heute darüber informiert, dass ich das Modul Mathematisch-logische Grundlagen mit einer Note von 1.0 bestanden habe. In der Präsenzklausur habe ich 83% erreicht – ich vermute, dass der Punktabzug durch die Vollständige Induktion und der ersten Aufgabe zustande kommt – durch meine Bonuspunkte konnte ich die fehlenden Prozent zur 1.0 aber ausgleichen. Somit ist also das dritte Modul bestanden. Für mich folgt als nächstes Modul Web-Design und -Ergonomie, dass ich hoffentlich zum nächsten außerordentlichen Klausurtermin am 14.08.2009 beenden kann.
Mein heutiger Tag war relativ hektisch: Heute Vormittag war ich in Osnabrück und habe mir das Kolloquium von Sarah angeschaut, danach ging es in die Firma, dann zum Training und schließlich zur Bandprobe.
Als “Belohnung” für die bestandene Klausur – von der ich während des Kolloquiums per Email (es lebe Active Sync) erfuhr – habe ich mir heute Abend neue Hardware für das ckl-net bestellt, da mein “altes” Embedded Board mittlerweile nicht mehr meinen Zwecken genügt. Somit habe ich dann ein Zotac ION ITX B anstatt des von mir erst angedachten MSI IM 945GSE bestellt, zuzüglich fanless Netzteil von Fortron und Bluetooth Tastatur. Ich freue mich wieder auf’s Frickeln
Die letzten beiden Abende verbrachte ich damit, auf meine Wii Homebrew Software zum Laufen zu bringen. War an sich auch schnell gemacht. Allerdings hatte ich das Problem, dass der SD-Kartenleser meines alten Notebooks (Tagra Vision 811) unter Ubuntu zwar erkannt wurde, ich aber keine Daten darauf schreiben konnte. Mit einem externen Kartenleser funktionierte das Schreiben sowohl unter Windows als auch unter Linux. Für mich stand also fest, dass meine SD-Karte völlig funktionsfähig war.
Theoretisch hätte ich das Problem dabei bewenden und mir meine Homebrew über den externen Kartenleser auf die Karte kopieren lassen können. Aber wie das so ist: Man möchte ja das Problem auch beheben, um ein Erfolgserlebnis zu haben.
Deshalb habe ich mir die letzten Sourcen des Linux Kernels geschnappt und die im SCSI-Treiber – das SCSI-Subsystems ist für das Lesen von SD-Medien zuständig – verankerten Überprüfungen, ob ein Medium schreibgeschützt ist, deaktiviert.
Nach der Kompilierung des Kernels funktionierte auch das Schreiben auf die SD-Karte.
Und zu guter letzt noch eine Werbung in eigener Sache: Christoph hat heute das Active Directory Plugin für Wordpress veröffentlicht. Klasse Sache und funktioniert sogar
In aller Kürze: Unter Linux WAV zu MP3s konvertieren
Nach der gestrigen Bandprobe bekam ich unsere Samples als WAV zugeschickt. Als ich mit lame versuchte, die Dateien mit lame in.wav out.mp3 zu konvertieren, bekam ich den Fehler Unsupported data format: 0×0011. Der Fehler enstand dadurch, dass die WAV-Datei mit einer Kamera aufgenommen wurde. Die Kamera wandelt den Audio-Stream automatisch nach Microsoft ADPCM und nicht pures PCM um. Außerdem wird eine Sample Rate von 8000 Hz benutzt. Ungünstig.
Mit ADPCM kommt hingegen ffmpeg klar. Leider ist aus lizenzrechtlichen Gründen in den Binaries von Ubuntu der MP3-Outputstream nicht mit kompiliert wurden. Deshalb braucht man einen zusätzlichen Konverter, wie z.B. Bladeenc.
Damit nun alles funktioniert und Bladeenc nicht den Fehler ERROR: Sample ’sample.wav’ is not in 32, 44.1 or 48 kHz!
meldet, muss folgendermaßen vorgegangen werden:
ffmpeg -y -i sample_low.wav -ar 44100 sample_high.wav bladeenc sample_high.wav sample.mp3
Interessante Links (Die besten Einzeiler, Analyse mit Traceroute, Closures and JVM)
Verfasst von Schakko unter Effizient arbeiten, Java, Linux am 23. Februar 2009
Hier ein paar interessante Links, die über das Wochenende in meinen Lieblings-Blogs aufgetaucht sind
- Command Line FU – Die besten Einzeller Einzeiler für die Kommandozeile (Linux)
- Analyse mit Traceroute
Sag was!