Wollte grade hier evince-gtk aus experimental installieren, und stolperte über:
Get:6 http://ftp.de.debian.org experimental/main evince-gtk 2.20.0-1 [1337kB]

Scheiße ist das leet!
Und ja ich weiß, der Post hat in etwa 0 Sinn :)

Ich nutze Linux, ich mag keinen Jobs und werde mir sicherlich nie DRM verseuchte Musik kaufen^Wmieten.
Aber es geht ja eigentlich auch anders. Sogar kostenlos - bei Jamendo nämlich, da kann man einfach so legal Musik saugen.

Denkste...

Vor einiger Zeit habe ich die Band pornophonique kennen gelernt, und fand die Musik einfach nur geil: Gitarre, Gameboy und C64...
Und genau diese Band hat vor kurzem ein Album herausgebracht: 8-bit lagerfeuer. Und das komplett kostenlos (wenn man MP3 mag, CDs gibt's aber auch zu kaufen).
Leider ist die Version auf der Homepage der Band nur 128kbit/s, aber dort ist auch das vorhin erwähnte Jamendo verlinkt, wo man 192kbit/s MP3 oder 300kbit/s OGG kriegen kann.

Ich korrigiere, kriegen sollte. Da so ein Musik-Anbieter einiges an Traffic verbrutzelt, wird dieser auf P2P abgeschoben, nämlich eMule und BitTorrent - würd ich für die Musik zahlen würd mir das stinken, bei einem kostenlosen Angebot finde ich's aber nicht so schlimm.
Schlimmer ist aber, dass man die Daten dann doch nicht kriegt.
Am 2ten Oktober, gegen 21Uhr hab ich mein BitTornado angeworfen, und ihn sowohl mit der MP3 als auch der OGG Version gefüttert, mal sehen was schneller fertig ist. Einen eMule Client habe ich hier nicht, und will auch keinen haben.
Bis heute ist kein einziger Byte Daten hier angekommen, und der Tornado meldet mittlerweile
Problem connecting to tracker - [Errno http error] 503: 'Service Unavailable'

Gut, also doch nur 128kbit/s MPblöd... Schade eigentlich, denn die Mukke ist recht nais, und ich glaube ich werde mal das Album kaufen. Nicht unbedingt weil ich es so absolsut geil finde (es ist dennoch ziemlich gut), sondern weil ich die Band supporten möchte, damit die sich Traffic leisten können, und das nächste mal das Album als FLAC online stellen ;)

Und was lernt man daraus? Will man gute MP3/OGG haben, muss man CDs kaufen und selber rippen (natürlich nur die ohne Kopierschutz, denn wir wollen ja keine Straftat begehen und die UnCD-Industrie fördern... Ich glaub da fehlt ein Komma).
Auf jeden Fall ist Jamendo wohl interessant, aber etwas kaputt :(

I think, almost everybody, who has an AMD/ATI graphics card, has already heard about the new RadeonHD Linux Driver, but not everyone has already tested it.
For my part I'm testing since yesterday and the whole thing is growing very fast, however I do not yet have a proper output on my Mobility Radeon X1400. But this is not what I wanted to write here, I wanted to write how to help the developers.

IMPORTANT!
First you need to send some beer, some peanuts and maybe also some money to libv (#radeonhd on freenode), then he might start looking on your reports *g* - sorry libv ;) just kiddin too ;)

1. get the driver
As the driver is in a very early stage of development, changes are made every day and packages from your distribution (well, I only know that Debian has it in it's repositories) is maybe outdated at the time of uploading by the maintainer, so please build it from git, as perfectly described here at phoronix.

2. test the driver
a) You get a picture when starting X with the radeonhd driver? Feel lucky and maybe write an email to radeonhd@opensuse.org, telling the guys how much you love them, and what card works for you.
b) You get a black screen, but X has properly started? The driver has correctly recognized your card, but had problems to set-up correctly, please read on.
c) You get an error in your log, and no X? That might have several reasons, let's look in your log. Does it state something like

(WW) RADEONHD(0): Unknown card detected: 0x1234:0x1234:0x1234 (imagine some other numbers here)
...
(EE) RADEONHD(0): Cannot map connectors on an unknown card!

If so, your card could not be recognized, as every vendor (ASUS, Gecube, etc) might give the card a slightly different subsystem id, which is not yet known to the driver. Please have a look at reporting card info, so your card can soon be added to the driver.
Or do you probably get something like

(EE) RADEONHD(0): No valid modes found?

This should happen, when the driver could not get enough/correct information, what mode you monitor wants to run with, this does lead to the previously described black screen too (as I get it here at the moment). I do not think this should be reported at the moment, as the problem is known to the developers.

3. reporting card info
When you decide to report something (which is the real help-part here), you should do it correctly.
First you should describe what card do you have (not only Radeon X1950, but ASUS FunkyNameOnTheBox Radeon X1950), and what result do you get (working X, not working X, X not finding something, etc).
Then attach your logfile (usually it's /var/log/Xorg.0.log), but don't forget to compress it before, this really saves traffic.
The last one is probably the most important one: the conntest output (see below).

4. conntest
conntest is a small tool which probes the connectors of the video card.
You can find it in utils/conntest/ in git, and build it just by calling make (dont forget to install pciutils-dev).
The you call it with ./rhd_conntest <pci tag> as root, where <pci tag> is the number lspci shows you in front of the name of your card - usually it is 01:00.0
But you should not run it just once, but for every output your card have.
On a laptop it's usualy once with nothing attached (only internal screen is active), and once with a screen connected to the VGA port.
If your laptop has a DVI and not a VGA connector, please run rhd_conntest once for a analog screen connected through an DVI-VGA adapter, and once for a digital DVI-connected screen.
On a desktop, you would call it once for NO screens connected, and then same as for a laptop: once with a analog screen on each VGA connector and then once with an analog screen with a DVI-VGA adapter and once with a digital screen on each DVI connector.
Have a look at the README in the same dir, it describes everything a bit more.

As soon as you have all the data you want to share, send the mail to radeonhd@opensuse.org and wait for a reply.

I hope this can help somebody to get his card working with RadeonHD

About 2 years ago I set up a desktop for my girlfriend (at that time, but this does not matter) with Sarge, which was later upgraded to Etch (this was some time after the freeze but before the release). She is pretty happy with it, but time to time she asks me for a bit of help.

Today she got a RAR-archive from a friend (Windows user). As it was too big for mailing, he protected it with a password and uploaded it to some public space. Nothing unusual, open file in file-roller, click extract, put password into the appropriate field, and you're done.

Not with this file, 'file-roller filename.rar' opens a dialog box saying: "this file is password protected. please enter the password under 'edit->password'". Well, this menu-item is grayed out, so file-roller does not help us.
As I'm some kilometers away, and have only SSH (well, I could go out for a walk, but not only for a damn archive-password...) to the box, let's try rar from non-free, this is "real" rar, it should support it. It does, as it correctly asks for a password, but fails because the password contains German umlauts. And yeah, I did set the right locales, everything UTF-8, both my side and the remote side. And yes I tried ISO-8859 too.
Next try is p7zip-full, as it supports RAR archives. But not this one? With UTF-8 it asks for a password, gets one, tells me which file it will extract and dies with "Unsupported Method". With ISO-8859 it just says incorrect password...
WTF? But what's about fetching the file and extracting it locally on my Sid system? Got the file, and extracted it with rar (on UTF-8 locale) without problems... With the same version of rar as in Etch!? Holy crap, don't ask me how THIS works. And no, p7zip-full from Sid did not like it, same problem as with the Etch version.

So what do we learn?
1. Fucking non-free proprietary archivers are fucking evil - don't use them!
2. Passwords should never contain non-ASCII characters! ("M,!z6-u_0" is a fine password, which you can type on every keyboard, "Hallö" isn't - try this on a keyboard in India, or maybe just France?)

Gerade habe ich auf RTL2 "A-Team" geguckt (jaja, RTL2, aber A-Team ist Kult...) und nun kommen da Nachrichten und ich habe nicht schnell genug weggeschaltet.
Auf jeden Fall gab's mal wieder das übliche Schäuble-Terror-Propaganda mit dem Pointe, dass die Terroristen den Sicherheitsdiensten technisch überlegen sind. Eigentlich nichts neues, aber Nachrichten im TV brauchen Bilder, und Terroristen lassen sich anscheinend nicht so einfach über die Schulter schauen.
Oder doch? RTL2 zeigte einen Mann (man sah nur seine Hände und seinen Schoß) mit einem Laptop (ich meine es wäre ein ThinkPad T4x). Soweit ja nichts ungewöhnliches, aber RTL2 setzte einen drauf und zoomte an den Bildschirm heran: ein Terminal, als root eingeloggt, ein KDE (???, bin mir nicht sicher) Desktop...

Und was lernen wir daraus? Richtig, Linux wird nur von Terroristen benutzt. Also los, schnappt euch die Biester!
Vielen Dank für die Aufklärung RTL2 & Herr Schäuble, ab heute benutzte ich nur noch das sichere Betriebssystem Microsoft Windows Vista Ultimate mit dem Sicherheitspaket des BKA/BND/BSI (whatever halt).

fooishbar.org:
Matthew Tippett just threw a CD full of AMD/ATI specs to Dave Airlie, approved for public release with no NDA.

Thanks god, a can be happy now and do a big jump into the air.

[01:39:59] <DrSommer> der doctor geht schlafen gute nacht
[01:40:28] * DrSommer DrSommer ist weg BNC ist da
[01:41:07] * DrSommer is now away: der doctor is raus
[01:41:53] >>> DrSommer is now known as DrSommer[BNC]

ohne Worte :(

Wir entwickeln zur Zeit @Work ein Portal. Wie bei Portalen üblich wird man dort auch ein umfangreiches Profil anlegen können. Da dies in einer PostgreSQL Datenbank abgelegt werden soll, und das Portal in Plone realisiert werden soll, sollten die User natürlich auch in der SQL und nicht im Plone-eigenem Benutzermanagment landen, sonst hat man ja redunante Einträge teilweise. Also nutzt man das SQLPASPlugin um sowas in die SQL zu verschieben. Ich erspare euch nun weitere Details wie das in Plone funktioniert, sondern sage nur folgendes:
Seit längerer Zeit existiert eine Zope Instanz, wo das ganze entwickelt wird. In dieser Instanz sind mehrere Plone-Sites mit unterschiedlichen Baustellen des Portals. Am Mittwoch legte ich mir eine Kopie an, um das SQL Zeug zu testen, was auch soweit ganz gut geklappt hat. Netterweise sind meine Kollegen aber gestern auf die Idee gekommen, das Passwort des Users in der Datenbank zu ändern, so dass das in Plone/Zope gespeicherte nicht mehr ging und diese keine Verbindung zur Datenbank herstellen konnten... Wenn man nur aber die Authifizierung gegen die Datenbank laufen lässt... Ihr könnt euchs schon denken, oder? Richtig, ich kam nicht mehr in das Plone rein um die Eigenschaften der SQL-Verbindung zu ändern. Und hatte natürlich auch das neue Passwort nicht zur Hand *kotz*.

Naja, gelöst habe ich es dann doch, aber fand die Tatsache toll, dass ich mit einem user, der außerhalb der SQL liegt auch nicht mehr reinkam, da die SQL immer gequeried wurde...

Leider war das aber noch nicht alles für heute.

Irgendwas ist beim Datenimport einer größeren Datenbank meines Kollegen schiefglaufen, postmaster hat sich beide CPU Cores und 1.8GB RAM gekrallt und die Load auf >40 hochgejagt. /etc/init.d/postgreqsql-8.1 stop wollte auch nicht helfen, also Hart-Reset am Power-Switch gemacht... Die Kiste kam aber nicht mehr sauber hoch, /etc/nologin war noch da, init hat sich wohl festgrefressen irgendwo, also noch ein Reboot, da lief schon soweit alles, bis auf die Zope-Instanzen. Mein Herr Cheff hat nämlich letztens etwas portiert und NICHT DIE VERDAMMTEN INITSCRIPTE ANGEPASST *grrrrrr* der kriegt gleich was zu hören...
Gut, da war ein Tippfehler meinerseits auch noch, aber hey...

As already posted today, I now has (sorry jesse, it's just so fuckin' lol ;)) XRandR 1.2 support in my radeon driver.

The card in my laptop (IBM [not Lenovo!] ThinkPad X31) is a ATI Technologies Inc Radeon Mobility M6 LY (a Radeon Mobility 7000) with a 1024x768 12" TFT. As 1024x768 is kinda small for everyday work, I have a 19" TFT with a 1280x1024 resolution on my table.
Until today the second screen had to be connected to the laptop before Xorg started, so MergedFB could recognize and configure it. This is very annoying and it could be simplier... With XRandR 1.2 it IS! I just need to start my box as usual, open a terminal and run
xrandr --output VGA-0 --right-of LVDS --mode 1280x1024 --rate 60 (the --rate is special for my TFT, as it supports up to 75Hz, but is a bit blurry then, 60 works perfectly)
BUT: xrandr: screen cannot be larger than 1600x1200 (desired size 2304x1024)
WTF?! Kay, let's google around... Ah, fine I need to set my virtual screen to something bigger. So let's open /etc/X11/xorg.conf, find the Screen section, there the subsection Display and edit:
SubSection "Display"
Depth 24
Modes "1024x768" "800x600" "640x480"
Virtual 2304 1024
EndSubSection

Restart Xorg, and have fun with your nice XRandR radeon :>

BTW, this is my third blogpost today, "I can has an award plz!? KTHXBYE" (sorry again, jesse)

Hinweis: Dieser Artikel ist aus dem Jahr 2007 und spiegelt die Situation zum Zeitpunkt des Verfassens wieder. Meines Wissens nach (und wie Tom von TeamBeam auch kommentiert) wurden alle hier beschriebenen Probleme kurz nach der Veröffentlichung behoben. Der Artikel spiegelt nicht die heutige Situation wieder! Wie Bernd Eckenfels mir in einem Kommentar zu meinen Posts über TeamBeam schrieb, hat er eine kleine Sicherheitsanalyse gemacht. Dabei kam er zu einem ähnlichen Ergebnis wie ich: TeamBeam behandelt SSL-Zertifikate nicht richtig. So kann man dem Tool ein beliebiges SSL-Zertifikat (auch ein selbst-signiertes) unterschieben, und das Tool wird die Daten dennoch übertragen. Sowas kann man sehr schnell in eine Man-in-the-Middle Attake verwandeln, aber das beschreibt Bernd schon zu genüge. Angeblich ist das in 1.0.1 behoben, und das ergeben auch erste kurze Tests, es werden aber weitere folgen. Desweiteren hat Tom von Skalio in meiner Abwesenheit den XSS Bug "behoben". In der Tat werden mittlerweile auch im Adressbuch alle <blah> Einträge rausgefiltert. Wobei ich sagen muss, dass Filtern meiner Meinung nach nicht das richtige Mittel ist - manchmal will man wirklich etwas in < und > schreiben... Ebenso werden solche Einträge bei my.TeamBeam.de gefiltert. Die Alten sind aber noch da, sprich ich kann meine bereits erstellten Hacks weiter nutzen. Ich hätte das ja ganz anders gelöst: ich hätte den User alles eintragen was er will (auch in der Nachricht) und dann beim verarbeiten der Daten PHPs htmlspecialchars() oder eine ähnliche Funktion die <, > und ein paar andere Zeichen durch die entsprechenden Entities ersetzt aufgerufen und erst die so bearbeiteten Daten an den Empfänger zugestellt. Client-Security existiert nicht Jungs... Wenn ich 1.0 nehme, den SSL-Traffic sniffe und schaue wie euer Tool funktioniert (Bernd sagt, es sei normales WebDAV, was Sinn macht), dann bau ich mir meine XSS selber rein, ohne euren Client... So long, Evgeni