Abhilfe schafft hier uvesafb, der jedoch auch Einschränkungen hat, die da wären:

uvesafb is a _generic_ driver which supports a wide variety of video cards, but which is ultimately limited by the Video BIOS interface. The most important limitations are:
- Lack of any type of acceleration.

- A strict and limited set of supported video modes. Often the native or most optimal resolution/refresh rate for your setup will not work with uvesafb, simply because the Video BIOS doesn’t support the video mode you want to use. This can be especially painful with widescreen panels, where native video modes don’t have the 4:3 aspect ratio, which is what most BIOS-es are limited to.

- Adjusting the refresh rate is only possible with a VBE 3.0 compliant Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 compliant, while they simply ignore any refresh rate settings.

Dennoch funktioniert alles wunderbar. An dieser Stelle möchte das Workaround geben.

[Fix/Workaround]
* uvesafb benötigt noch ein paar Pakete bei der Installation. Dies kann erledigt werden mit:

* Als nächstes muss die passende Auflösung für den Monitor bzw das Display gefunden werden. Der Befehl dafür lautet:

* Beispielsweise könnte der Befehl folgende Output liefern
02: None 00.0: 11001 VESA Framebuffer
[Created at bios.464]
Unique ID: rdCR.R1b4duaxSqA
Hardware Class: framebuffer
Model: “NVIDIA G73 Board – p456h1 ”
Vendor: “NVIDIA Corporation”
Device: “G73 Board – p456h1 ”
SubVendor: “NVIDIA”
SubDevice:
Revision: “Chip Rev”
Memory Size: 256 MB
Memory Range: 0xc0000000-0xcfffffff (rw)
Mode 0×0300: 640×400 (+640), 8 bits
Mode 0×0301: 640×480 (+640), 8 bits
Mode 0×0303: 800×600 (+800), 8 bits
Mode 0×0305: 1024×768 (+1024), 8 bits
Mode 0×0307: 1280×1024 (+1280), 8 bits
Mode 0x030e: 320×200 (+640), 16 bits
Mode 0x030f: 320×200 (+1280), 24 bits
Mode 0×0311: 640×480 (+1280), 16 bits
Mode 0×0312: 640×480 (+2560), 24 bits
Mode 0×0314: 800×600 (+1600), 16 bits
Mode 0×0315: 800×600 (+3200), 24 bits
Mode 0×0317: 1024×768 (+2048), 16 bits
Mode 0×0318: 1024×768 (+4096), 24 bits
Mode 0x031a: 1280×1024 (+2560), 16 bits
Mode 0x031b: 1280×1024 (+5120), 24 bits
Mode 0×0330: 320×200 (+320), 8 bits
Mode 0×0331: 320×400 (+320), 8 bits
Mode 0×0332: 320×400 (+640), 16 bits
Mode 0×0333: 320×400 (+1280), 24 bits
Mode 0×0334: 320×240 (+320), 8 bits
Mode 0×0335: 320×240 (+640), 16 bits
Mode 0×0336: 320×240 (+1280), 24 bits
Mode 0x033d: 640×400 (+1280), 16 bits
Mode 0x033e: 640×400 (+2560), 24 bits
Config Status: cfg=new, avail=yes, need=no, active=unknown

* Als nächstes müssen wir den Bootloader Grub2 umkonfigurieren, dazu editieren wir die Datei /etc/default/grub, damit wir sicher sein können, das wir mit uvesafb framebuffer booten. Folgende Zeile muss geändert werden:

* Damit das dann auch alles aktiviert wird und beim booten alle Module geladen werden, muss am Besten das Modul noch in der Initramfs reingeladen werden. Dafür editieren wir die Datei /etc/initramfs-tools/modules um eine Zeile hinzuzufügen.

* Beim booten lassen wir den den PC den Framebuffer zwanghaft nutzen mit:

* Abschließen noch alles aktualisieren und dann sind wir fertig:

* Ein Neustart lässt das System dann in neuem Glanz erscheinen. Der Splashscreen ist nun länger zusehen und in einer wesentlich angenehmeren und ansehnlicheren Auflösung.

[Bugs]
Auffallend ist, dass das System bei mir erst nach dem zweiten Neustart funktionierte. Danach immer einwandfrei.

Ein Skript welches ich mittlerweile schon öftes gebraucht habe, will ich hier einmal vorstellen. Es ist, wie man sehen kann ziemlich simpel aufgebaut. Zu Funktion kann man sagen, das es alle Dateien in einem Verzeichnis, wo auch das Skript liegt, nach einer bestimmten Endung durcharbeitet und unter anderem Dateinamen wieder ablegt.

In dem gezeigten Skript werden, wenn man es auf der Konsole mit [./script.sh wav mp3] startet, alle Dateien der Endung “wav” werden mit ffmpeg in einer Rate von 192kbps kodiert und unter dem selben Dateinamen jedoch mit der Endung “mp3″ abgespeichert.

Skript

Den Code könnt ihr euch in eine Textdatei kopieren und am Besten die Datei in skript.sh benennen.

Durch den Aufbau und die Migration bestehender Telekommunikationnetze zu Next Generation Networks (NGN) ergeben sich eine Vielzahl neuer Anwendungsmöglichkeiten und Dienste für die Nutzer. Besonders die stetig wachsende Nachfrage an Video-over-IP bzw. IPTV (IP TeleVision) und Voice-over-IP (VoIP) zwingen die Netzbetreiber über die Sicherstellung ihrer Dienstgüte (QoS) nachzudenken und geeignete Sicherheitsmaßnahmen zu ergreifen um dieser Güte gerecht zu werden.

Heute eingesetzte Verfahren zur Messung der QoS von IPTV sind aufwendig, rechen- und kostenintensiv. Schwerpunkt des Forschungsprojekts SmartVideo ist die Entwicklung eines “light weight” Messsystem zur Bewertung der Quality-of-Experinece (QoE) von IP Videostreams, wie IPTV und VoD, in Zusammenarbeit mit Vodofone (ehem. Arcor) und CeTeCom (ehem. Vierling). Das Forschungsprojekt SmartVideo berücksichtigt bei der Entwicklung von geeigneten Messsystemen sowohl Broadcast-, Content-, Network-, Accessprovider wie auch Home Networks, um ein netzübergreifendes System zu schaffen.

In das Forschungsprojekt SmartVideo fliessen die Ergebnisse des BMBF-Projekts QoSSIP ( http://www.qossip.org ) zur Bewertung von QoS in NGN ein.

• PHP5, MySQL, HTML
• XHTML konform
• selbstentwickelte Bildergalerie

• PHP5, MySQL, PHPBB, HTML
• XHTML konform
• Bilder Galerie

Das Jugendcafe Dirmerzheim ist eine von der katholischen Kirche unterstütztes Programm für Jugendliche in Dirmerzheim. Dort wird Ihnen die Möglichkeit geboten, sich Nachmittags (Mo,Di,Do) mit Dart, Billard, Tischfussball zu amüsieren. Des Weiteren ermöglicht es den Jugendlichen einen kostenlosen Internetzugang.

Kontakt

Leitung Underground Dirmerzheim
Markus Becker
jugendcafe(ät)dirmerzheim.de
Leitung Theater Dirmerzheim
Michaela Ackermann
theater(ät)dirmerzheim.de
Leitung Webdesign
Stephan Küffner
stephan.kueffner(ät)dot-solutions.org

Das Webfrontend ist intuitiv zu bedienen. In der Übersicht besteht die Möglichkeit eine VE hinzuzufügen. Ist eine VE mit 3 Klicks erstmal angelegt, muss sie nur aktiviert werden und nach wenigen Sekunden ist die VE über Dienste wie SSH oder WWW erreichbar.

Folgende Features sind in der Version 1.0 vorhanden:

• VE´s erstellen, ändern, löschen
• Benutzerverwaltung mit Gruppen und Rechten
• Backup-System für die VE´s. (Sicherung der VE in Sekunden)
• Schnelles Einbinden der VE´s in einen anderen Netzbereich
• Softwaresystem im Browser skalierbar (zoomen)
• Passwörter werden mit Hashs verglichen
• Mirgieren von VE´s zu einem anderen Host
• Auswahl von fertigen Templates beim Start (Debian, Suse)
• Apt-Konfigurationstool
• Datenbanksicherung mit Auswahl
• Anzeige von Systeminformationen – Live
• Sperren von Accounts bei 3 mal falscher Anmeldung
• Konfiguration über eine Settingsdatei
• PHP5, MySQL5, XHTML
• XHTML konform

NetBox ist die Entwicklung einer virtuellen Netzumgebung auf Basis von OpenVZ und einem Webinterface, zur Steuerung der Netzumgebung, mit Hilfe von PHP und MySQL.

OpenVZ ist eine Virtualisierungssoftware mit der isolierte und sichere virtuelle Maschinen aus Templates erzeugt werden. Diese “Virtual Environments” (kurz: VE) bilden dann Knotenpunkte (z.B. Router) in einem Netz ab. Mit Hilfe der grafischen Oberfläche können so Netzwerke geschaffen und Datenpakete beliebig durch dieses Netz geroutet werden.

Zur Verdeutlichung nehmen wir an, es soll die Eigenschaft oder Qualität eines VoIP-Gespräches von Deutschland nach Australien ermittelt werden. Von Deutschland nach Australien liegen verschiedene Router in Rechenzentren dazwischen. Diese Router weisen zu unterschiedlichen Tageszeiten unterschiedliche Last auf. Um jetzt aber bei dieser Messung einen zuverlässigen und reproduzierbaren Wert für die QoS-Parameter zu erlangen ( wie Delay, Jitter, usw.), braucht man zum testen eine Testumgebung die genau diese Anforderungen erfüllt. Das Internet fällt als Testumgebung aus, weil es keine nicht konstant ist. Zwei gleiche Messungen zu unterschiedlichen Zeiten können komplett verscheidene Ergebnisse liefern. Netbox ist wegen der Virtualisierung ein abgeschlossenes System, sodass Störgrößen wie Lastschwankungen minimal gehalten oder vermieden werden. Wie in der oben gezeigten Grafik zusehen, wird ein VoIP-Gespräch, genau nachgebaut. Die VoIP-Telefone werden außen an den OpenVZ-Server angeschlossen, bekommen automatisch eine IP-Adresse zugewiesen für den Eintrittspunkt in das virtuelle Netz und haben danach die Möglichkeit, sich zum Beipiel an einem Asterisk innerhlab des Netzes, anzumelden.

Um Streckenabschnitte zwischen den Router zu simulieren, wird das Programm NetGen eingesetzt. NetGen ist ein Programm, das im Rahmen des Forschungsprojektes QoSSIP an der Fachhochschule in Köln entwickelt worden ist. Der Name NetGen ist ein Kürzel und steht für Network Generator. NetGen
ist eine Layer 2 Netzwerkbridge mit Einstellmöglichkeiten der Parameter Delay, Jitter und PacketLoss für unterschiedliche DSCP-Klassen um Netzwerkverkehr zu beeinflussen.

In Verbindung mit NetBox ist es dann möglich eine Strecke mit einer Satelliten-, 56k- und einer T-3 Verbindung zu vereinen und als Testumgebung zu nutzen.

Die Grafische Oberfläche von NetBox kann ein virtuelles Netzwerk darstellen. Als Beispiel dient folgendes Bild.

IP-basierte Netzwerke bestehen oft aus einer Vielzahl heterogener Netze, welche getrennt voneinander verwaltet werden. Gerade zeitkritische Dienste wie die populäre Internettelefonie (VoIP) oder IPTV profitieren von einer bevorzugten Behandlung in IP-Netzen. Da bereits eine einzige überlastete Strecke die Qualität (Quality-of-Experience, QoE) eines Videostreams oder eines VoIP-Gesprächs empfindlich stören kann, ist es wichtig Dienstgüte (Quality-of-Service) durchgehend über Netze hinweg zu messen und zu steuern. Zu den aktuellen Entwicklungen der Forschungsgruppe Datennetze gehören:

• NetBox, Virtualisiertes QoS-fähiges Netzwerk, IMS-Testumgebung
• NetAccount, QoS-Accounting für NGN und IP Multimedia Subsystem (IMS)
• IMS ShowCase, IMS Application Server
• NetGage, Lastgenerator und MOS-Bestimmung (E-Model, PESQ), Echoanalyse
• NetGen, Netzparameter Steuerung (Delay, Jitter, Packet Loss, CRC Error, u.a.)

Neben der mangelnden Lokalisierbarkeit eines Telefonteilnehmers für Not- und Röchelrufe oder der fehlenden Sicherung vor dem Abhören von Gesprächen ist die Gewährleistung einer gleich bleibenden Qualität eines Telefonats oder einer Videokonferenz über das Internet derzeit nicht gegeben.

QoSSIP widmet sich dieser Problemstellung. Es werden Lösungen und Designvorschläge für Netzbetreiber entwickelt, wie man die Qualität von VoIP über mehrere Netze hinweg und in verschiedenen Netztechnologien (ADSL, WLAN, gemanagte IP-Netze, Internet, Satellitenstrecken) steuern kann und wie man die voreingestellte Dienstgüte (Quality-of-Service) auch nachweisen und messen kann, um sie dann ggf. einer definierten Abrechnung (Billing) zuzuführen.

Die besondere Schwierigkeit im Projekt QoSSIP beruht auf der heterogenen Netzwerktechnik, die durch unterschiedliche Zugangsnetze (ADSL, WLAN, LAN) und dem Einsatz unterschiedlicher Netzwerke bei verschiedenen Netzbetreibern entsteht. Als Verbundprojekt wird QoSSIP gemeinsam mit der FH Frankfurt, der FhG FOKUS SatCom (Schloss Birlinghoven) und den Unternehmen JDSU/Acterna (Eningen), Arcor (Eschborn), HEAG Medianet (Darmstadt) und Tecon (Köln) durchgeführt.

Die ganzen Feinarbeiten werden wohl die nächsten Tage kommen, aber nun geht es los.

Ich werde hier versuchen News und Informationen rund um

• Entwicklungen im Forschungsprojekt SmartVideo
• iPhone
• Android
• Buell Motorräder
• Lupo

zu geben!!

Kü