Hier einmal ein Bauvorschlag für einen kleine, aber Leistungsfähigen Computer, der sehr gut durch den Alltag kommt. Ziel von mir war es, einen kleinen, stromsparenden (im Vergleich zu Leistung) und leisen PC zu bauen.

Dazu verwendete ich folgende Bauteile:

• Mainboard: Asus P8Z77-I DELUXE
• Prozessor: Intel Core i5-3570K 3400
• RAM: 8GB Tactical K2
• Gehäuse: Cooltek Coolcube Mini
• SATA-Kabel: Nanoxia SATA 3.0 Kabel abgewinkelt 45cm
• Netzteil: SilvStone SST-ST45SF V2 450W SFX
• Gehäuselüfter: NB BlackSilentPRO PR-1 60x60x25
• Kühlkörper: Prolimatech Samuel 17
• CPU-Kühler: EKL Alpenföhn Wing Boost 12 cm (4,7 Zoll) Lüfter

Das ganze System kommt ohne extra Grafikkarte, sollte aber zwei digitale Grafikausgänge haben. In dem Fall hier ein Displayport und DVI Ausgang. Die aktuellen Ivy-Bridge CPUs unterstützen bis zu zwei Digitale Ausgänge. Ist noch eine analoger Anschluss dabei, kann dieser nicht verwendet werden bzw. es muss auf einen digitalen Anschluss verzichtet werden. Was die Grafikkartentreiber angeht, muss man sich bei Intel keine Gedanken machen, da die Treiber eh OpenSource sind und so standardmäßig im Linuxkernel liegen.

Das Gehäuse ist ein Coolcube Mini von der Marke Cooltek. Zu beachten ist, dass es wirklich ,,Mini“ ist. Als Netzteil passen nur SFX-Formfaktor Stromspender hinein. Hier ist der Markt noch relativ dünn gesäht. Auch muss bei dem CPU-Lüfter aufgepasst werden, da dieser nicht höher als ca. 7,5 cm sein darf. Festplatten passen entweder eine 3,5 Zoll oder zwei 2,5 Zoll Festplatten / SSDs hinein. Sollten zwei 2,5 Zoll Platten eingebaut werden, muss darauf geachtet werden, dass der optionale 60mm Gehäuselüfter nicht zu tief ist. Ansonsten stößt dieser gegen eine der beiden Platten, so dass dies dann nicht mehr passt.

Der Einbau ist ziemlich frickelig, da hier nur wenig Platz zur Verfügung steht. Als erstes sollte das Mainboard mit CPU-Kühlkörper eingebaut werden. Alle unter dem Kühlkörper liegenden Verkabelungen zuerst vornehmen. Zuerst das Mainboard verschraube, bevor der CPU Kühler angeschraubt wird, da er die Schrauben verdeckt. Nun alle Verkabelungen vornehmen und zuletzt das Netzteil einbauen. Am besten ist es, den CPU-Lüfter so montieren, dass die Luft von der CPU weggeblasen wird (das Netzteil natürlich mit Lüfter zum Mainboard zeigend. So kann die Warme Luft über das Netzteil nach außen transportiert werden. Ein kleiner leiser zusätzlicher Gehäuselüfter transportiert frische kühle Luft in das Gehäuse hinein.


$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +27.8°C (crit = +106.0°C)
temp2: +29.8°C (crit = +106.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +43.0°C (high = +85.0°C, crit = +105.0°C)
Core 0: +37.0°C (high = +85.0°C, crit = +105.0°C)
Core 1: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 2: +42.0°C (high = +85.0°C, crit = +105.0°C)
Core 3: +36.0°C (high = +85.0°C, crit = +105.0°C)

Die Temperaturen halten sich im Idle als auch bei Belastung in gutem Bereich. Wärmer als 65 °C wurde die CPU nicht.

Von der Lautstärke hält sich das System im erträglichen Bereich. Man hört, das der Rechner läuft aber die Lüfter sind nicht aufdringlich im Geräusch als auch von der Lautstärke.

Zu beachten ist, dass in dem Gehäuse kein Platz für eine PCI-Express Karte ist. Nur das reine Mainboard passt hier hinein. Benötigt man eine zusätzliche PCI-Karte sollte man zu dem größeren Modell, dem Coolcube, greifen. Hier ist auch Platz für ein Standard ATX-Netzteil.

Interessante Links zum Thema

• http://www.tomshardware.de/Gehause-Mini-ITX-Aluminium-Cube,testberichte-241270.html
• http://www.pc-max.de/artikel/gehaeuse/test-cooltek-coolcube-mini-gehaeuse

es2gears!

Progress is slow but steady on the lima mesa driver, mostly because I am not giving lima as much time as I should. I now have working attributes, uniforms, vertex buffers and even some state is being set correctly. Enough to run es2gears. Here is the video on youtube, there is an older capture with a rotating smoothed cube as well.

This lima mesa driver uses the old-school (but contrary to popular belief, definitely not deprecated) mesa infrastructure, which, with surprisingly little work, allows me to run the mali binary drivers compiler, and allows me to build the lima driver externally. Using the binary compiler would not be possible from gallium, and with some improvements to the (intel developed, and thus intel focused) mesa glsl compiler, it seems that we might have a potent compiler for the mali ISAs as well. This way, the task of bringing up mesa on mali is nicely split, and we will be able to debug the command stream work separately from the shader compiler. I believe that we did lose the ability to run gles1 programs until Connors open-gpu-tools is hooked up to the mesa glsl compiler. This is just a small price to pay, in comparison to the size of the hurdle to take when doing everything in one go.

We are running es2gears at 130fps on the A10, and 310fps on the Exynos for a 300x300 render. Resizing is currently broken, or rather not implemented. I will need to split up the PLBU command stream to be able to do that properly under DRI2 (where resizes happen behind the mesa drivers back). The way DRI2, mesa and the sunxifb X driver now work together also means that i have to wait for jobs to finish (and then usleep for good measure), so there is a lot of potential for speed-up as well. I am not sure yet how things will have to be hacked to keep X from copying the region before rendering is absolutely done, i guess that we will have to hack something into UMP and the sunxifb driver. But a solution will be found, and we should see around a 50% increase in framerate from that, and even much much more if we manage to use overlays. Since we are in control of all the code now, we should theoretically be able to squeeze every last bit of performance out of the GPU, a luxury not offered to the users of the binary X11 driver.

I will now continue implementing textures, so that i can run all the limare egl tests. After that i will clean up the code and push it out. This will include patches to common mesa versions (and mesa packages) to allow building lima against them. Resizing and job interleaving will have to wait until after that, so keep your eyes peeled on this space :)

10 years in.

A few weeks ago, it was the 10th anniversary of my first contribution to X (a small display fix to the via driver). I cannot state that this anniversary was a happy event.

Looking back, I cannot believe that i once thought that in open source software, code, design and doing The Right Thing, both technically and morally, were paramount. Open source software is about power, politics, corporate affiliation, and loads and loads of noise. Noise and misinformation always wins over code, no matter how good this code is or how hard you work at it. I have had to learn this several times over.

This is especially true in the case of forks. Not the git clone variation, but the loud, aggressive and very detrimental community kind. While often technical reasons are claimed to be the cause, this is never ever the case. It always is about politics and power. And code always suffers as a result, and this suffering is never a short term thing, especially on big forks. See, a fork always means a big stink, a lot of noise, and a power vacuum, and this attracts a certain kind of individual. These personalities form the basis of the new community together with those who instigated or accelerated the fork. Good code simply has no chance in such an environment. Bad code and bad design tends to hang around for a long long time, and tends to influence (read, limit) the thinking of any new blood that turns up. On top of that, the bad mentality also tends to linger for many many years. Politics and noise continues to take precedence over code and design, for the foreseeable future.

The only thing to do in case of a fork, is to go play somewhere else, somewhere where a major fork hasn't taken place. If you don't, or if you do not go far enough, you will see your work impacted, especially if you are not willing to let yourself be limited by the existing mentality and powerbalance.

Now if only i wasn't such a stubborn bastard ;)

Now that The Linux Foundation is a member of the UEFI.org group, I’ve been working on the procedures for how to boot a self-signed Linux kernel on a platform so that you do not have to rely on any external signing authority.

After digging through the documentation out there, it turns out to be relatively simple in the end, so here’s a recipe for how I did this, and how you can duplicate it yourself on your own machine.

Da ich dieses Jahr arbeitsbedingt Samstag verhindert war, konnte ich nur am zweiten Tag an der FrOSCon teilnehmen. Zum Glück sprang Jörg Stephan noch kurzfristig ein und organisierte einen openSUSE Stand (unter anderem mit ZFS auf openSUSE)

Da es am Sonntag erwartungsgemäß ruhig war, zog ich auch meine Runden und quatsche eine Runde mit den Leuten von Magiea sowie Arch Linux. Letztlich habe ich es sogar noch zu zwei interessanten Vorträgen geschafft. Besonder der Talk von Uwe Ziegenhagen – Python und LaTeX vereint fand ich sehr interessant. Sollte ich mal wieder Luft haben, werde ich mir dies auf jedenfall mal genauer ansehen.

Ansonsten gibt es meinerseits nicht viel von der FrOSCon zu berichten. Sollte nichts dazwischen kommen sehen wir uns im November 2013 auf der OpenRheinRhur.

Its been quite a while since I've created any software appliance via SUSE Studio.  This blog entry describes the motivation behind and the details of my IBM Worklight Studio Developer Edition software appliance created via SUSE Studio.

I have been using openSUSE 12.3 since the past three months on my new Toshiba rig. Despite some issues, I found it to be the most stable Operating System around. The KDE Release is specially slick, and didnt give me many issues. After updating the system, and installing a truckload of softwares, some issues crept up, that I initially found it hard to deal with. As my wireless driver was a very recent Realtek one, the driver was not part of the kernel that openSUSE initially came with. I was using a patched version of the compat-wireless package, but it was slightly buggy, and I was facing frequent disconnections, when the signal strength was comparitively weak.

Another minor issue was that of codecs. Kaffiene stopped playing video files for some reason, even though I had proper codecs installed. This was more of a graphics driver issue than a codec issue though. My most sever problem was that of the i915 Graphics driver not being loaded. This was not immediately clear to me, as I didnt have much experience debugging kernel issues. Going through the ACPI log, and using hwinfo and modprobe nailed down the problem. It was a module compilation error.

I never expected the problems to be simple. I just updated the kernel to 3.10, using the Kernel of the Day for openSUSE. Now, I am running the 3.10 kernel. All my issues went away in a jiffy, and I back to using the distro I love and admire.

Kernel of the Day – http://en.opensuse.org/openSUSE:Kernel_of_the_day

Minha área de trabalho..acho que ficou legal…
Tipo assim: openSUSE 12.3, KDE 4.10.5, Conky, (monitor do sist.), Yawp (widget para o clima), Cupertino glowglass e Neon Fruit (decoração de janelas e área de trabalho)., papel de pared (achei na net…)

Just a service announcement for those that might have around still SXW files generated from WordPerfect documents by the wpd2sxw tool version 0.6.x or earlier (years 2004 and before). Those files used to open fine in early OpenOffice.org versions, but they miss a crucial element. That is the reason why LibreOffice, the OpenOffice.org modern successor, will refuse them. Nevertheless, they are not lost!

LibreOffice development team, in its constant quest of increased user satisfaction, has a workaround for you!

First grab the zip file with the required manifest. Then get the zipmerge tool that comes with libzip, and merge the manifest into the corresponding SXW file. As an example, this command line could work:

for i in <sxw-file-list>; do zipmerge temporary_sxw.sxw /path/to/sxw_manifest.zip $i && mv temporary_sxw.sxw $i; done

This way you assure that if the original SXW file already had a manifest, it will not be overwritten by the one from sxw_manifest.zip, which would not be a desirable outcome. Nonetheless, if you only have to repair one SXW file and you checked already that manifest is missing in it using tools like zipinfo, you can quietly use:

zipmerge <original-sxw-file>.sxw /path/to/sxw_manifest.zip

In order to merge the manifest directly into that file. Naturally, you can merge the manifest from the sxw_manifest.zip into the SXW file using any other zip-manipulation tool you prefer.

Enjoy and continue using LibreOffice, the free and open source office suite of reference.