According to a post by Keith Packard on the Linux kernel mailinglist:
This module contains stuff which Intel can’t publish in source form, like Macrovision register stuff and other trade secrets. It’s optional, so if you don’t want to use a binary module, you don’t get to use code written by Intel agents for these features. And, we also haven’t figured out how and when to release this binary blob, so there’s no way you can use it today. The driver remains completely functional in the absense of the binary piece, and in fact has no reduction in functionality from previous driver releases.
So much for that idea eh?
According to a statement by AMD/ATI:
We’ve always supported open source, and for relevant markets such as servers, we release open source drivers so that companies such as Red Hat can include them in their distros.
However, for other markets, such as workstation and consumer, performance and feature differentiation are key metrics. Proprietary, patented optimizations are part of the value we provide to our customers and we have no plans to release these drivers to open source.
In addition, multimedia elements such as content protection must not, by their very nature, be allowed to go open source.
This makes one wonder. AMD has also, like Intel, always publicized their specifications and programming manuals for their processors and chipsets.
In related news Intel asked to be able to serve a subpoena (a legal writ which calls you to attend and function as a witness in a judicial proceeding under a penalty in case of disobedience) on ATI in the anti-trust case versus AMD.
With recent news of AMD acquiring ATI there was some incorrect reporting that AMD would be dropping the ATI brand in favour of tacking Radeon on its own brand name of AMD. According to Ars Technica the name drop was a miscommunication that spread like fire through the blogosphere as well as online news. This is both the advantage and disadvantage of the quick turn-around time of the online media. One would think that serious technical journalists, however, would verify this with AMD and/or ATI themselves before reporting.
In related news Intel revealed a website where they are offering source code for their 965 IGP. And it becomes even more interesting when put into perspective with an article from InfoWorld where it is said that AMD is strongly considering releasing open source at least a part of the ATI graphics drivers. One can only wonder how NVIDIA will react to these developments.
One thing I am trying to verify is whether or not PuTTY allows its cursor colour to be overridden. It doesn’t seem so, having highlighting rules for Cursor in vim does nothing, yet using gvim on Windows it does show the correct colours.
To break the news quickly: Open Office is nice, but no dice.
I have tried using it, ended up appreciating some features (native PDF, OpenDocument Format and type completion as you type for recurring words), but in the end it is just insanely frustrating to use on a daily basis.
Let me clarify I am by no means a commercial software fan, most of my work consists of open source related work (as many who know me by now should know), but the user experience that is Open Office is like pulling nails at times.
Of course, these kind of comments probably get flames from the open source peanut gallery and personally I couldn’t give a flying hoot. It is all about user perception and ease of use and at the moment it still falls flat on its face in those departments.
Python’s Django is a wonderful framework in the same kind of way as Ruby on Rails.
I advise all of you Python coders to try it. You’ll love it.
Finally have a working PHP again after the PHP folks totally screwed over PHP 4.4.1’s apache2handler. Thankfully the FreeBSD port reverted this piece of code.
And I will migrate my PHP stuff to Django and such frameworks in the future. PHP’s braindead decisions by its developers has annoyed me a bit too much by now.
I have a 256 colour xterm set up on my DragonFly box.
Works perfectly. Especially for vim.
Now, I use FreeBSD 5.x as a gateway box to ssh into and have irssi and likewise programs screened.
Now, I was surprised to learn that I had only 16 colours. Outside of screen I had a full 256 colour palette (make sure to fix your PuTTY configuration by the way), but inside I was stripped of my colour scheme.
So I set off to find what was causing this. Interestingly enough one of the first emails encountered was from Jeremy Chadwick who had the exact same problem.
Turns out that screen needs to be compiled with 256 colour support (a knob should be in your ports Makefile now).
Since FreeBSD’s and DragonFly’s termcap is bereft of any 256 colour definitions for xterm apparently, you need to add the following to $HOME/.screenrc:
termcap xterm* 'Co#256:AB=E[48;5;%dm:AF=E[38;5;%dm'
terminfo xterm* 'Co#256:AB=E[48;5;%p1%dm:AF=E[38;5;%p1%dm'
This overrides your termcap settings with the appropriate definitions.
If you now start screen from a shell that has TERM exported as xterm or xterm-color (xterm* wildcard actually) it will fork off to a screen with 256 colour support.
You might need this in $HOME/.vimrc:
if &term =~ "xterm" || &term =~ "screen"