Mediacenter mit XBMC

Frisch zu Weihnachtszeit Anfang Dezember, habe ich mir mal ein kleines Mediacenter gegönnt. Nach nun mehreren erfolgreichen Abenden der Nutzung nun einen kleinen Blogartikel darüber.

Aber erst etwas Theorie meinerseits. Ich wollte für das Mediacenter auf der einen Seite nicht viel Geld ausgeben, denoch auf Standardkomponenten setzen die nicht viel Strom verbrauchen. Dolby oder ähnliches sind für mich nicht von belang. Letztlich habe ich mich für folgenden Komponenten entschieden die ich bei einem großen Onlinecomputerhandel erworben habe:

• Intel D2550DC2 Mainboard mit aufgelöteten Atom D2550
• SO-DIMM 2 GB DDR3-1333
• Antec ISK 300-150 Mini ITX
• GeForce GT 610 PCI pasiv (dazu später mehr)

Eine alte aber noch gute 2,5″ Festplatte hatte ich noch zur Hand, so das ich hier nichts mehr einkaufen musste. Viel Speicher muss die Platte bei mir nicht haben, da sich das Mediacenter die Medien vom Homeserver holt. Die entsprechenden Ordner sind per SMB freigegeben. Insgesamt hat mich der Einkauf (ohne Festplatte) knapp 215 Euro gekostet.

An dieser Stelle muss ich nun kurz vorgreifen warum ich zusätzlich zu der mit auf dem Atom eingebaute Grafikkarte (eine PowerVR Grafikkarte) eine nVidia Karte eingebaut habe.
Die schon eingebaute Karte des Atom D2550 wird vom Linuxkernel 3.6 aktuell nicht unterstützt. Aus diesem Grund sollten Linux Nutzer die aktuelle Atom Version erstmal meiden, da die Treiber für PowerVR Grafikkarten noch nicht stable sind.

Hardware

PCI Slot mit wenig Luft

Bei dem Zusammenbau ist selber nicht viel zu beachten. Das Gehäuse selber kenne ich noch aus meinem ersten Homeserver. In der neuen Revision ist das Netzteil nun geschlossen und aktiv gekühlt.
Blöderweise lag bei dem Mainboard der Anschluss für den Gehäuselüfter so weit weg, das das Kabel zu kurz war. Aus diesem Grund musste ich mir erstmal eine Verlängerung zusammenlöten damit der Stecker passt.
Die Grafikkarte mit ihrem passiven Kühlkörper ist etwas wuchtig, da der Kühlkörper auch auf der anderen Seite

Grafikkarte ist gut durchlüftet

noch ausgebaut ist. Erst nach dem umlegen von ein paar Kabeln passte die Grafikkarte zufriedenstellend. Hier ist zu beachten, dass nur Grafikkarten mit LowProfile-Blende passen. Von der Hitzeentwicklung her ist die Karte in Ordnung. Sie wird zwar warm aber nicht heiss.

Software

Als Betriebssystem ist ein minimales Arch Linux installiert. Zusätzlich werden über den Befehl
pacman -S xorg-server xorg-xinit xorg-utils xbmc
die nötigen Pakete für XBMC installiert. Damit XBMC automatisch beim Hochfahren mitstartet müssen folgenden Befehle ausgeführt werden:
systemctl enable xbmc
systemctl enable graphical.target

Anfangs hatte ich Probleme dem richtigen Sound. Eventuell müssen Sie hier mit
pacman -S alsa-utils
alsamixer
erst noch die Lautstärke von Hand hochdrehen.

Für die Grafikkarte verwende ich die properitären Grafkikkartentreiber. Diese installieren Sie mit
pacman -S nvidia libvdpau
Vergessen Sie hier nicht die VDPAU Bibliothek zu installieren, wie oben beschrieben, und das XBMC diese auch nutzt (unter Einstellungen > Wiedergabe > Video), ansonsten werden 1080p Videos nur als Standbildkino ablaufen.

Leider habe ich das Beenden Menü zum Herunterfahren etc. noch nicht zum laufen bekommen. Ausschalten lässt sich der PC aber normal über den Powerbutton, der zu einem ordentlichen shutdown führt. Bei dem Menü führt jeder Befehl zu einem normalen Neustart des X-Server und XBMC selbst.

Interessante Links zum Thema

• Arch Linux Wiki XBMC > https://wiki.archlinux.org/index.php/Xbmc
• Arch Linux Wiki Nvidia > https://wiki.archlinux.org/index.php/Nvida

Since yesterday i started using LaTeX. So i was searching which LateX editor fix better in my needs. After searching and testing i use Gummi. Let’s see what is going on :

What is Gummi?

Gummi is a LaTeX editor for the Linux platform, written in C/GTK+. It was designed with simplicity in mind, but hopes to appeal to both novice and more advanced LaTeX writers. Gummi was released as free opensource software under the MIT license. [1]

Installing Gummi

In order to install Gummi in openSUSE you have to install the following packages :

– gummi (by typing sudo zypper in gummi , in the terminal)

Problem

After installing the gummi package , i couldn’t execute gummi and saw the follwoing  error message

“Failed to execute child process “enchant-lsmod” (No such file or directory)”

Solution

The solution to this problem is to install the following packages  :

– enchant (and 5 sub-packages)  [2]

– enchant-devel

– libenchant1 [3]

After installing them , Gummi will work fine!

[1] http://dev.midnightcoding.org/projects/gummi

[2]  http://software.opensuse.org/package/enchant

[3] http://software.opensuse.org/package/libenchant1

Yesterday Alex Fiestas showed on his blog a video of a recent development version of the KScreen library, created to handle easily multiple monitor setups in KDE, almost in an “automagic” way. As this is a project where configurations and setups are highly heterogeneous, a lot of testing is required to ensure things work reliably.

Of course, you cannot ask a developer to have all sorts of screen combinations, but remember one of the strengths of FOSS: “many eyes make bugs shallow”. And that’s why the KDE team prepared testing packages for KScreen for openSUSE users.

Before you jump to the repository, bear in mind that these packages are for testing and bug reporting purposes. They can potentially cause unwanted effects, connect your displays to some random alien homeland, make your house blow up, and so on.

If you are still daring, you can find them in the KDE:Unstable:Playground repository. Install both the libkscreen and kscreen packages, and you’ll see a new entry in System Settings when you go to the monitor configuration control panel.

Make sure you report all bugs (along with detailed information on monitor setups etc) to bugs.kde.org.

Let the testing commence!

Hoy inicié la sesión en LXDE y me di cuenta de que todo estaba «pelón» y sin configurar. En esa lista se encontraban las teclas multimedia y las de control del brillo en la pantalla.

Leyendo un poco en la wiki de LXDE, me topé con que hay que añadirlas al archivo de configuración que está  en XML, así que es muy sencillo «meterle mano».

Abrimos el archivo que se encuentra en el directorio .config de nuestro home. Lo podemos hacer con Beaver, nano, vim o el editor que gusten:

vim .config/openbox/lxde-rc.xml

Una vez abierto, buscaremos las etiqueta <keyboard>.  En esta parte empiezan las descripciones sobre los eventos que deben ocurrir cuando pulsamos alguna combinación de teclas.

El orden en el debemos describir el nuevo nombre del evento que queremos es el siguiente:

• <beybind key=»nombre-de-la-tecla»>
  • <action name=”nombre-de-la-acción”>
    • <command>comando-a-ejecutar</command>
  • </action>
• </keybind>

Bueno, ahora pondremos las combinaciones de teclas:

• <keybind key=»XF86AudioRaiseVolume»>
  • <action name=»Execute»>
    • <command>amixer set Master 10%+ unmute</command>
  • </action>
• </keybind>
• <keybind key=»XF86AudioLowerVolume»>
  • <action name=»Execute»>
    • <command>amixer set Master 10%- unmute</command>
  • </action>
• </keybind>
• <keybind key=»XF86AudioMute»>
  • <action name=»Execute»>
    • <command>amixer set Master toggle</command>
  • </action>
• </keybind>
• <keybind key=»XF86MonBrightnessDown»>
  • <action name=»Execute»>
    • <command>xbacklight -dec 10%</command>
  • </action>
• </keybind>
• <keybind key=»XF86MonBrightnessUp»>
  • <action name=»Execute»>
    • <command>xbacklight -inc 10%</command>
  • </action>
• </keybind>

Si necesitan alguna otra combinación, pueden agregarla, lo importante es que cualquier <keybind> siempre quede entre las etiquetas <keyboard> y </keyboard>.

Ahora abrimos una terminal y tecleamos:

openbox --reconfigure

Con esto volveremos a cargar la configuración de openbox y ya funcionarán los cambios.

An dieser Stelle wünsche ich euch heute Abend und die nächsten Weihnachtstage ein besinnliches und ruhiges Fest.

One of the first things I did when I joined the Cloud team at SUSE was to start porting DevStack to openSUSE. DevStack is a set of shell scripts to build complete OpenStack development environments. It is useful to create a small OpenStack environment that will be used for hacking, testing, etc. and is therefore primarily used for upstream development. Getting this to work on openSUSE seemed like a logical first step before doing more OpenStack work. I got things working pretty quickly, but for various reasons, this all stayed in a personal branch of mine (except for a few preliminary patches).

A few weeks ago, I got time for DevStack again. So I rebased my branch, cleaned up everything, and started submitting the patches. After reviews from Sean Dague and Dean Troyer (and some patch rewriting to address the issues that were raised), the openSUSE support landed in master. A few other people tested it, and nobody has been hitting any major issue, so yesterday, I finally submitted the patch to make openSUSE 12.2 a supported distribution. Now you can play with DevStack on openSUSE!

I wrote some documentation for DevStack on openSUSE if you want to get more details on how to use it. But I guess it wouldn't hurt to show how easy it is to setup your own OpenStack environment this way...

I'm shamelessly stealing instructions from the single VM DevStack guide to show you the very short version. Just run the following in an openSUSE virtual machine (do not run this on your main system unless you're 100% sure it's what you want: DevStack is a little bit too invasive right now; see Daniel's analysis on this topic):

zypper in git-core
git clone https://github.com/openstack-dev/devstack.git
cd devstack
echo ADMIN_PASSWORD=password > localrc
echo MYSQL_PASSWORD=password >> localrc
echo RABBIT_PASSWORD=password >> localrc
echo SERVICE_PASSWORD=password >> localrc
echo SERVICE_TOKEN=tokentoken >> localrc
echo FLAT_INTERFACE=br100 >> localrc
./stack.sh

(You'll actually need to call FORCE=yes ./stack.sh until the patch mentioned above gets in.)

And there you go, you have OpenStack running! That was quite easy, right? :-) You can connect to the web dashboard (horizon) or use the command line tools (hint: source openrc will setup the proper environment variables for you). Here's a few commands you can use to get started:

source openrc
glance image-list # find out which image is available
nova boot --image cirros-0.3.0-x86_64-uec --flavor m1.tiny cirros-test # start an instance of one specific image
nova list # see what instances are in the cloud

So go ahead, read the documentation, play with all this, and enjoy DevStack on openSUSE!

2012 is slowly coming to an end and we all are looking forward to a few silent days around Christmas. But we did not want to leave to holidays without adding another thing to your vacation experience: I am happy to announce the first beta of the upcoming ownCloud Client release 1.2.0, ready now for you to test and enjoy under the tree.

This is the first build with the new things we did in Berlin a couple of weeks ago, you will

• discover that there is much better error reporting if something goes wrong.
• probably feel like it syncs faster, yes faster.
• see that there are less HTTP requests to the server for a single sync run.
• don’t see any issues with MacOSX and funny characters in filenames any more.
• recognize a new icon set, which is not finalized yet (actually not all sizes are there, thats why the status dialog looks a bit funny) but we thought its nice to already add it to the beta. It should fit nicely into your operating system environment.
• realize that this client comes with a cross platform file system watcher on clientside, so no polling any more.
• have your password stored in a secure keychain on all platforms since we added qtkeychain to the client.

Maybe there is more, but we thought that’s already a nice beta release.

Please find packages for MacOSX, Windows and Linuxes. Note, not all packages are finished yet. If the one for your distro is missing, please come back later, or even better - speak up at packaging@owncloud.org and help fixing :)

Of course you also should note that this is an early beta and you would not want to use it without a good backup of your data and only on your test account without important data.

We would appreciate if you let us know your experience on the mailinglist. If you find problems, please report it to the client’s bugtracker mentioning client- and server versions and at best with useful logs.

With that we are happily vanishing to spend some time away from the computer, looking back on a very exciting and very busy year, working on an interesting topic with a lot of nice people.

Thanks and best Season’s Greetings!

The release of KDE SC 4.10 is approaching and RC1 packages are now available for openSUSE 12.2 and Factory users from the KDE:Distro:Factory repo aka KDF. You can test them and report packaging and openSUSE-specific bugs on IRC (#opensuse-kde) or the mailinglist (opensuse-kde). Everything else should be filed upstream at bugs.kde.org.

Big thanks to everybody involved!

KDE:Release:410 aka KR410 will be set-up shortly and published as soon as KDE officially releases the final packages for KDE SC 4.10.

Those using KR49 will have noticed that KDE SC 4.9.4 got already published and 4.9.5 will follow at the end of this month.

The KDE team is also proud to congratulate Raymond Wooninck on his election to the openSUSE board! Given his constant commitment to packaging KDE SC and other apps for openSUSE over the last years, I am sure the openSUSE community will profit from his work as member of the board. Congratulations also to Robert Schweikert, the second candidate who got elected to the openSUSE board.