* GPU decoding on Windows Vista and 7, using DxVA2 for H.264, VC-1 and MPEG-2
* GPU decoding on GNU/Linux, using VAAPI for H.264, VC-1 and MPEG-2
* DSP decoding using OpenMax IL, for compatible embedded devices
* Improved support for MKV HD, including seeking fixes, and 7.1 channels codecs
* Support for new codecs, like Blu-Ray subtitles, MPEG-4 lossless and VP8

NB: so far, on Windows for GPU decoding, VideoLAN is recommending nVidia® GPU, until ATI® drivers are working with VLC architecture, and until the VLC developers get access to some Intel® hardware supporting GPU decoding.

Extensions
New add-ons and script framework so one can personalize its vlc.

* Written in lua
* 2 main types of scripts:
o content add-ons, integrated in the playlist
o functionnalities extensions, like metadata searching on the web, or subtitles look-ups
* Very Simple

Web improvements

* Support for WebM decoding and encoding
* Improved web plugins
* Better streaming capabilities

Better Audio experience

* Integrated playlist in the Qt4 interface
* Multiple views (like album art) in the playlist in the Qt4 interface
* Support for AMR-NB, Mpeg-4 ALS, Vorbis 6.1/7.1, FLAC 6.1/7.1 and WMAS
* CDDB and CD-Text works now on the Windows port when listening to CD-Audio
* Support for DVD-Audio files (.aob)
* Improved meta-data and album-art support

Faster, Lighter

* Faster decoding, with up to 40% speed-ups, in HD resolutions
* First part of the Video Output core rewrite
* Removal or rewrite of dozens of modules, code simplification and tens of thousands of lines of code removed
* Some functionalities that are less used are now moved to extensions
* More assembly optimizatinons, especially SSSE3/SSE4 and ARM Neon
* Fewer threads used

Better for developers

* Simplified and improved libVLC, removal of exceptions for better C integration
* New phonon-backend for Qt applications, on all platforms
* New C++ bindings

This is possible because anybody can put whatever the like in the From field so they were putting .

I had setup my domain as a ‘catchall’ address which was BAD, I didn’t realize this was a spammers dream!

So how to fix this:

First make sure you DONT use catchall addresses.

Now the SPF record comes in to play.

I had to add the following to my DNS record for pross.org.uk:

v=spf1 ip4:193.104.186.137 include:_spf.google.com -all

This allows my server IP and spf.google.com to send from pross.org.uk all else is -all a hard fail.

This seems to be working perfectly well so far, spam in my inbox has dropped dramatically and my VPS and DNS hosts are a lot happier!

I’d like to thank Rens Ariens at Yisp.nl and Joshua Anderson at http://freedns.afraid.org

My new theme Adformat is ready for the release I’m waiting for it to be included into the theme codex on wordpress.org

Fixed menu dropdown, uses header top color as background for readability.

garland-revisited

WordPress 2.9 was released last weekend. Yesterday, I was notified that 2.9.1 is most likely around the corner due to some issues that arose because of a last-minute addition to the core of WordPress. The issues revolve around scheduled posts not firing because the cron scheduler ends up broken. The patch can be found here which is already a part of 2.9.1.

While reading the support thread, I became concerned with some of the responses that were published. For example, “How could you release an upgrade that is obviously this problem-filled?” or “WordPress should have tested 2.9 before releasing it!“. I’m not sure how many times this has to be preached to the choir but each version of WordPress is tested before it’s release to the public. That is what the Beta releases are for as well as the Release Candidates. WordPress 2.9 went through one release candidate version and two beta releases. In fact, before RC1 hit the public, all of the tickets assigned for that version were closed. Each version was tested by anyone who volunteered. There seems to be this notion that there are thousands of WordPress developers and they should iron out every bug before releasing software to the public. While there are hundreds of WordPress developers submitting patches here and there as well as squashing bugs, not every hosting setup can be tested. This is where the end users come in.

Dion Hulse who has been a long time contributor to the WordPress project illustrates this problem quite well in a blog post entitled WordPress, A Call To Arms. I think Dion says it best in the first paragraph which illustrates the lack of testing problem quite well.

WordPress 2.9 was just released, And several users have run into a bug. Surprising? Not really. There’s one simple reason for this, While thousands of people Test each and every WordPress release, These users are not You.

While hundreds or thousands download the betas to perform testing, the real crux of the testing comes when the “Stable” release is shipped. The stable version is installed by everyone because it’s considered to be stable only since you now have hundreds of thousands of blogs running the software which translates into more testing environments, you’re going to run into bugs the testers simply didn’t find. This gives the perception that the Stable release was not stable at all and therefor, should have never been released. But, if the software were never released, the bug would most likely would not have been found.