English - 20

Some years ago I started the webpage dosdriver.de, cause I permanently had problems running old DOS games and demos, the lack of proper VESA-support, missing sound drivers and things like that. I forgot to upload this again when I moved all my webpages to our little server project, so it was offline for the last months.
I noticed when the free-domain-provider I'm hosting dosdriver.de mailed me that I'm violating their AGB if I don't use the domain for a real webpage. Today I took the page from a backup, removed old eMail-adresses, made xhtml 1.1, added a small section about emulators and some general rework. Most of the information is still valid, so if you intend to run a real DOS on some up-to-date PC, you might find it useful.
The domain is still a free-domain with ads, but as most of you probably have popup-blockers, you won't mind.

Everybody seems to talk about flock today (via BoingBoing). Flock is a web browser based on Firefox supporting features like direct tagging of links, uploading them to del.icio.us, blogging, uploading images to flickr and things like that.

It's surely a nice idea to integrate all those social software into easy to use applications, so more people get to know blogs and all that stuff. Although I'm a bit sceptically about centralised services like flick or del.icio.us, I prefere more standardised, decentralized services that everyone can use with his own software (Blogs, Podcasts and things like that).

I'd prefer to blog this entry with flock, but it seems not to support serendipity yet, at least I couldn't get it to work.

Get Flock today, probably no distribution packages for anything yet, but the binary just works when running from it's unpacked dir without installing anything.

For people who like to play around with crazy bleeding edge stuff (who doesn't?), I've created cvs ebuilds for Luminocity (the wobbling windows effect) and cairo-gtk-engine (gtk theme engine using the possibilities of cairo).
See Seth Nickell's blog for information, screenshots etc., I also made a video of luminocity a while ago.

For luminocity you need to switch to the modular x ebuilds and the kdrive-snapshot, if you have it installed, run it with:
Xfake :1 -ac -screen 1024x3072x32 &
DISPLAY=:1 xterm &
luminocity :1

cairo-gtk-engine can be installed right away as long as you are using unstable (~x86) gtk+ and cairo versions (then copy over /usr/share/themes/Caligula*/gtk/gtkrc to ~/gtkrc-2.0).

I've just created a gallery for collecting images I found worth publishing witout any special context, e. g. nature pictures. I plan to fill this collection in the future. Maybe I'm gonna play around with random images in the sidebar or something like that. Probably you'll gona see one of the pictures in the upcoming (and never finished) design of my blog.

The first two images are from a visit in Lindau this summer, the later ones are from a bicycle trip at the Rhine from Mainz to St. Goar recently.

Bruce Schneier writes about Phishing attacks and that he wants financial companies to be responsible for phishing attacks.

This brought me to some thoughts about online banking security and secure authentication in general.
Today, most online banking goes through web interfaces. That's really horrible in the sense of security. I remember when I asked my local bank for an online banking account, they told me "hey, you just need a web browser to do this". They have better alternatives (HBCI), but they don't promote them to their normal customers.
With a web-interface, you only have a one-way-authentication (the user authentificates itself to the bank, but the bank doesn't) and that's the whole thing why phishing works. If there would be any mechanism that verifies the authenticy of the bank for the user (or, to be exact, his applications, because we all now that average users don't manage to do so), the whole phishing-stuff would be senseless.

Even the less secure variant of HBCI with keyfiles is much more secure than web-interfaces. For a successfull phishing-attack, a user would have to upload his keyfile - which he usually won't do, because he doesn't know where it is. But the most obvious way: Smartcards.
Smartcards can be a fine solution for various security problems - and it's not much more complex. Everyone knows that he has to put his bank card into a cash terminal, so why shouldn't the average user be able to put it in a computer slot? But hey, it's even hard to get smartcard-drives - I once asked in the Saturn (big german technology market), they don't sell them at all.
The right thing would be having smartcard-drives in computers by default - and having chipcards for various security-applications.

HBCI, for the ones who don't know, is a german standard for online banking - I wonder why there is no word-wide online-banking-standard yet - with a secure, open design and based on two-way-authentication, together with some easy-to-use standard applications for online banking installed on every PC. That would really help a lot.

From the ffmpeg-list:
>>> Java is rumored to be platform-independent.
>> Highly overhyped rumor, it actually runs on all platforms... that have a JVM.
> Right, both of them. :) Funny essay on the matter:
> http://web.ivy.net/~carton/academia/java_languageoftomorrow.html

And congratulations to the marketing guys of sun who managed to promote their product for years with something that just isn't true.

Recently I've been playing around with testing HD videos based on the H264-codec. For those who don't know, HD videos are video files with very high quality and resolution. The upcoming HDTV television standard is based on that (which is quite problematic due to the HDCP copy protection, but that's not the topic of this article).
Apple recently released Quicktime 7 to play HD mov files, Microsoft supports WMV HD videos in it's Media Player. HD videos are available in three qualities, 420p, 720p and 1080p.

For the system requirements of 720p-videos in Quicktime, Apple says:
2.8 GHz Pentium 4 or faster processor, At least 512MB of RAM, 64MB or greater video card
And even more for 1080p:
3.0 Ghz Intel Pentium D (dual-core) or faster processor, At least 1GB of RAM, 64MB or greater video card
As my system doesn't really fit these requirements (1,5 GHz Pentium M, 512MB RAM, 128 MB video card), I was quite impressed that I could run a bunch of videos in quite reasonable speed and quality with linux software.

Trying out various players the cvs-version of mplayer did it best for me. Pretty much every player available on linux uses ffmpeg for H264-decoding, so they should do all, but there have been a bunch of important fixes in ffmpeg recently and this is quite the easiest way to get a recent ffmpeg-version running.
Running mplayer with these options gave me the best results:
mplayer -lavdopts skiploopfilter=all -framedrop -fs [videofile]
-fs is for playing the video in fullscreen (you don't want to play HD videos in a window), -framedrop let's mplayer skip frames when your system is too slow (else it will be out of sync very fast, some framedrops don't really hurt). About the -lavdopts skiploopfilter=all, I don't really know the details of video codecs, as far as I understood, this disables some steps in the decoding that shouldn't be needed on most videos, but can result in wrong decoding. I couldn't see any differences, it improves the speed quite a lot.

Now I could play all 420p and 720p videos at pretty reasonable speed. I especially liked this BBC one showing african animals and landscape. For the 1080p ones, it differs. This Trailer for "The Island" runs pretty well, others don't.

Bugs: Some videos cause mplayer to crash. On my radeon, the mplayer xv output has a problem with the large videos (width of 1900) displaying a pink block on the right side. I've written bug-reports and hope those things get resolved soon.

To sum it, I'd call linux pretty much "HD ready", beside some small issues it plays the HD stuff very well and with impressive performance.

Places to get HD videos:
Microsoft WMV HD Content Showcase
Apple HD Gallery

After commiting a compile-fix for kmail, I finally managed to switch to KDE 3.5 Alpha. As you can see on the right, Konqueror now passes the acid2 browser test for standards compatibility (beside Safari it's the only Browser that does - Internet Explorer, Firefox and Opera all fail, Microsoft already announced that even IE7 won't be able to pass acid2 - I wonder what the IE-devs are doing all day).
Probably more interesting for reality usage is that kde 3.5 finally supports automounting based on pmount with the new hal/dbus-API. I also happily noticed they fixed an annoying bug in konquerors ssl-handling when trying to permanently accept certificates that were issued for wrong hostnames.
Gentoo users can try it out by copying the kde 3.5 section from the package.mask-file to /etc/portage/package.unmask.

As the German News-page Golem writes, Firefox is going to drop obsolete SSLv2 support in it's next version, because it has known vulnerabilities by design.
While this is in general a very good idea to make things "secure by default", it will probably lead to people crying "Firefox can't open URL xy any more". We have a vast number of deprecated servers, applications etc. that just don't support up-to-date security standards and weren't updated for ages.

Even SSLv3 supports a lot of weak ciphers, like Single-DES, RC4 etc., that are known to be broken for ages. Not to talk about things like RSA 1024 or SHA1, that are not yet broken in reality, but probably will be at some time in the future.
The implementation of secure standards in todays software is far away from what's neccessary for high security applications.

We need to get rid of all that old cruft. High security is possible with today's cryptography, but we have to use it and we have to design applications that use secure technology by default.

Tomorrow I'll attend the mrmcd11b from the Chaos Computer Club in Darmstadt. Seems they have some interesting talks there and I'm looking forward on meeting some chaos-people and having a nice time there.

Sometimes you think the world is really small - so I met my room-neighbor Julian in Cologne. He was hanging around in a location called "Kletterfabrik" near the Evoke-location, where some cool people did some art installations. I made pictures, but they are quite dark (it was in the night).
I'll upload some more pictures in the next days.

The 64k-Intro Bloom from Styx made the second place and he was quite happy about that.

After coming home I was really tired (you don't get too much sleep on a demoparty) and angry about the "Deutsche Telekom", because our DSL isn't working at the moment.

I'm here at the Evoke 2005 demoparty with Tom, StyX and TS.

I tried to create a 4k-Intro on friday evening, but stopped due to the late time and the deadline, which was at 10 (although it was moved for hours later). StyX has created a 64k-Intro, which has probably good chances to gain a good place, maybe even the first.
The network is always sucking here (and we're asking us why it is so difficult to provide a working network), so if this entry reaches you, I managed to get internet for some minutes ;-)

Pictures I made are here

In about two hours I'll leave to have a trip to the demoparty Evoke. If netcologne manages it to provide internet this year you may see live-reports from me. I have no releases prepared, as I'm mostly a passive scener in recent times.
If you don't know what a demoparty is, it's basically an event where people are creating art with computers, in form of self-running programs, while their only use is that they provide nice graphics and sound.

If you are a loyal reader of my blog, you might know that one of the very first entries in this blog was about my Evoke-Trip last year.

As the article some days ago about SHA1 got a lot of interest, I thought I'll write some more background info about this, especially for people thinking that collisions aren't a big problem.

Cryptographic hash functions are functions where you can put a string of any length and get a fixed-size result. E. g. with SHA1, you get 160 bit, with MD5 128 bit. The hash-function has to fulfill some requirements:
- It should be hard to get two strings with the same hash (collision-resistant).
- It should be hard to get a string to a given hash (one-way-function).
To be more precise: In an optimal case, hard means that it shouldn't be possible with all hardware on earth in the timeframe that your cryptography needs to be secure. Some examples where cryptographic hashes are used are shadown-passwords, digital signatures or verification of file downloads.

I found this a while ago and thought it's worth mentioning. Secret Maryo Chronicles is a Mario-Clone and seems to be one of the better ones. It's in a quite early stage, but with some talented level designers it could evolve to something really nice.
The gameplay is a bit different from the original games, it doesn't have a speedup-button. It's features are comparable to Super Mario Bros, while it's graphics are more like Super Mario World.
It's free software and it's available for Windows and Linux.