openSUSE 11.0 failed detect this hardware and wrong identifying the device as AR242x 802.11abg Wireless PCI Express Adapter. I usually uses madwifi driver for Atheros chipset instead of ath5k but the standard madwifi driver could not be applied for the device. After Googling for a while, I could make it works with the special AR 5007 EG madwifi driver, http://snapshots.madwifi.org/special/madwifi-ng-r2756+ar5007.tar.gz.

How to make it works ?

1. Disable or blacklist ath5k driver by add the blacklist ath5k to /etc/modprobe.d/blacklist
2. Open konsole or terminal
3. Install the driver

su
zypper in kernel-source make gcc gcc-c++
wget -c http://snapshots.madwifi.org/special/madwifi-ng-r2756+ar5007.tar.gz
tar -zxvf madwifi-ng-r2756+ar5007.tar.gz
cd madwifi-ng-r2756+ar5007
make
make install
modprobe ath_pci
reboot


After reboot, you should be configure the wifi from YAST | Network Devices | Network Settings

What has my new haircut to do with David Beckham? Not much if you asked me. But yesterday I got this dubious compliment that I look like a tomboy with my new David Beckham cut. DAVID Beckham? Would have been strange enough to be compared with his starving wife, but with him..? To make things worse I had to dance to this duck song again. With a Bob the Builder helmet (the tomboy proof) and a troop of plush toys. And soon I have to paint fishes. And dolphins. Fishes for my nephew and dolphins for his best friend. My first contract work. I'm so proud. And so scared. I can't paint animals. Any animal. Not even amoebae.

Support for the RV770 chipsets has now been added to the GIT master
branch of xf86-video-radeonhd at freedesktop.org.
So far this support has only been available in the AtomBIOS branch.
Now some investigations have unveiled that the display engine blocks
have not changed since RV620/RV635. Therefore AtomBIOS is not a strikt
prerequisite to get the latest AMD/ATI hardware to work.
Some bits to get RV770 to work have been cherry picked from the
'atombios-support' branch. These involved mainly memory controller
register programming and some small fixes to the I2C code.
Thus it was possible to provide support for this new hardware generation
without having to wait for the AtomBIOS support branch to be ready for
merging into the master branch.
Some word on the atombios_support branch: Most of the work on that
branch has been finished so that this branch will be merged into
master after some further testing and once some cleanup has taken
place.
We have been asked to provide AtomBIOS support for the RadeonHD
driver to speed up the driver bring up for future generations of
graphics hardware. It relieves ATI of the burden to have register
specification available at the time of release of new graphics hardware
and thus allow it to focus on the publication of documentation for
3D programming.

One of the functional menu that make my life more easier with KDE 3 are the Compress and Extract Menu. With this function, I could make an archive or extract zip file with Konqueror without opening Ark for manually extract or compress the file. Now, I enjoy the KDE 4 on openSUSE 11.0, with Kwin desktop effect and a lot improvement in various area, but I still missing the above menu.

How to add the similar function to KDE 4 so we could compress some file or folder, or extract a zip file both in Dolphin and Konqueror ? Here is the tips :

1. Download the plugin here :
   http://www.kde-apps.org/content/download.php?content=84206&id=1&tan=96989998
2. Open konsole / terminal
3. Extract the plugin
4. Go to the extract folder
5. Copy all of .desktop file into /usr/share/kde4/services/ServiceMenus
6. Copy the content of script folder into /usr/bin
7. Test with dolphin or kde4

The above tips will make a system wide configuration. If you wish to make a local changes, just execute INSTALL_1.0.sh on the extract folder.

NOTE : The programs p7zip, bunzip2, bzip2, gzip, rar, unrar, tar, zip and unzip must be installed.

I don’t know if the function will be added into KDE 4.1 by default, but I hope so

A while back I posted about Mango Lassi and how awesome it was compared to synergy. I still think it is awesome, but every now and then something would freak it out and cause the association between machines to drop. I’ve fixed at least one cause of that problem now and published it in a git repo here: http://www.snorp.net/git/mango-lassi.git/

BTW, thanks for all of the great comments on the NAS situation. I’m looking at several of the options mentioned there along with a couple others. I think I’ve ruled out rolling my own, though, as I don’t want yet another linux box to maintain.

After two or three weeks of coding (not mine mostly, but by Marcus and Dirk), a lot of good stuff has accumulated in the osc development tree. Time to release a new package. It is a particularly good moment because today the 1.0 release of the Build Service has been announced.

The list of changes is long, the NEWS file has it all. Overview:

• version 0.105
• easier usage of osc submitreq: It is less picky on commandline arguments, can be called in working copies or project directories, figures out which build service instance to use, and has improved output. Also, there is a osc submitreq delete action now (which only works if you have write permissions on the destination though)
• osc search: added option -i|–involved, to show in which projects/packages a developer is involved
• osc importsrcpkg: no signature check anymore
• osc linkpac: –revision option added.
• osc copypac: use the correct userid when copying to another api host
• osc build: double check the buildinfo for local builds.
• osc buildhist: change the output into a format which better matches actual RPM filenames.
• osc commit: give commit message tempfiles a “.diff” suffix, so syntax highlighting automatically works in capable editors
• don’t expand/unexpand if the working copy has local modifications – this is a workaround for #399247 but this way the working copy isn’t screwed up. Also, make sure no _linkerror files end up in working copies.
• better error reporting in a whole number of cases, especially printing out more available detail. For instance, osc meta now prints out a concrete text why something you submitted was not accepted.

Have a lot of fun with it.

And just a note, remember that it is very easy to write osc plugins in order to extend or alter the functionality! Here’s the documentation.

The debugger integration in MonoDevelop is progressing, lots of work in the past weeks. I'm going to show what is supported right now, altough much work is still left to make everything stable.

Everything I'm showing here works both for the MDB and GDB backends, unless explicitly stated.

First of all, this is the Attach to Process window. Notice the "Debugger" combo at the bottom. It allows you selecting which debugger you want to use to start the debug session (MDB or GDB):



Breakpoints have a nicer look, and there is support for enabling/disabling. Also, when starting a debug session, invalid breakpoints (e.g. breakpoints placed in lines without statements) will be rendered as disabled.



The dissassembly window shows the assembler mixed with the source code when available. This mixed view is not supported in MDB, due to limitations in the API (for MDB, dissassembly without source code will be shown). The disassembly view supports single-stepping of assembler instructions.



Big improvements in the Watch View. The list now has icons for each type of member. Drill down has been improved, for example big arrays are now split in 'ranges' which makes easier to locate elements.

The Watch View now supports expressions. The expression evaluator is based on NRefactory, and although not all C# expressions are supported, many of them are (for example, arithmetic operations, method calls, array access, conditional expressions, etc). Expressions can be used both to select what to show in the view, and to assign values to variables or members. For GDB, the GDB expression evaluator is used. The screenshot below shows some examples. In one of the examples, the value of an expression will be assigned to the variable 'n':



The Watch View can also be used to inspect types. The view will show all static members of a type. Namespaces are also supported. For example, you can enter the namespace 'System' and drill down through all types and inspect their static members (not supported in GDB):



The Watch View also supports code completion (both for entering expressions and values). Code completion is based on data from the debugger backend, not on the MonoDevelop parser database, so it works for MDB and GDB, and even when debugging an application for which there isn't a MonoDevelop project:



Another nice feature is the support for debug tooltips in the editor. When moving the mouse over a variable or member, a tooltip will show its value. The tooltip is interactive and allows drilling down and modifying values just like the watch window:



It is also possible to use tooltips to inspect the value of expressions:



And works for GDB too! This final screenshot shows a Mono process attached with GDB, a debug tooltip for a MonoMethod, and a member of that struct being modified using code completion:



That's all for now. If you want to try it you'll have to get everything from SVN (see my last post).

I started to document some exceptions or special cases of network during installation. But this is I already know (I don't know what users don't know or wants to know ;-)) so if anybody wants to some parts be more detailed or something is missing there, your feedback is welcome.

Subversion 1.5.0 has been recently released (June the 19th) and I'm surprised with the tons of great stuff it brings. Some highlights:

• A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.
  Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to 'foo', and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file 'bar', and unversion the file 'foo' (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally's point of view, her changes seem to be lost; the newly added 'bar' file has the older content, and the file 'foo' has been taken out of version control.
  In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn't send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally's 'foo' file is copied to 'bar' (with local edits intact!).
  
• Merge tracking means Subversion keeps track of what changes have been merged where. This reduces the overhead involved in maintaining branches, and gives users a way to inquire what changes are merged — or are available to be merged — on different lines of development.
  Example (one of the improvements in place): Merging changes from (say) trunk to a branch no longer requires that you specify the revision range. Instead, each time you want to sync up with trunk, you can just do:
  

  
     $ cd BRANCH_WORKING_COPY
     $ svn merge URL_TO_TRUNK
  

  
  Subversion will figure out what changes from URL_TO_TRUNK have not yet been merged and pull in just those changes. When it's time to merge the branch back to trunk, do this:
  

  
     $ cd TRUNK_WORKING_COPY
     $ svn merge --reintegrate URL_TO_BRANCH
  

  
  
• Sparse checkouts (via new --depth option): Many users have very large trees of which they only want to checkout certain parts. In previous versions of Subversion, checkout -N was not really up to this task. Subversion 1.5 introduces the --depth option to the checkout, and other subcommands.
  
• Conflict resolution is now done interactively by the command-line client for the update/switch/merge subcommands.
  
• Relative URLs and @peg revisions for svn:externals.

Don't you think this is AMAZING? This means we almost got full/real MOVE support and that merging is taking the best ideas from DVCS systems (yes, we lack yet local commits).

To get up to speed with DVCS features I would also add pending commits feature although there are concerns and people seem to prefer it to be implemented upstream in bug tracking tools.

Well, I guess you already may have noticed I don't like current DVCS tools (at least the most popular), by a different set of (a little bit subjective, I know) set of reasons:

- Git: it's implemented in an unmanaged language (yeah SVN too, but at least the latter is cross-platform!).
- Bazar & Mercurial: they're implemented in a "too-managed" language (yeah sorry I dislike dynamically typed languages very much, especially for big developments that need to have a long life; yeah, refactorings are a pain with these ones, although I don't know the test coverage they may have...).

Maybe Git# (Mono SoC2008) is the answer? (I don't know the progress of this project.)

I was discussing about this yesterday with JP, and when I talked to him about this SVN 1.5.0 he said "too late!". Ermmm, what?, Gnome hasn't switched to DVCS yet so, why too late? Maybe because it's imminent? I don't know. Sincerely, there is much contradiction about how people approach migrations... Today I've been attending for almost an hour a meeting about Gnome Mobile, and one thing that was arised is the lack of flexibility and ease of use of the Gtk+ toolkit, as opposed to other toolkits. People were concerned about it and wanted to fix it, and nobody wanted to give up pushing Gtk+ just because it's old. Then, why doing this for Subversion? Subversion is very mature, and their devs have demonstrated to be worried about its lack of flexibility wrt the new distributed ways of work, so they are fixing it, they are *supporting* us. And however at Guadec here it seems everybody wants to push for the migration (but only taking care of doing the correct decision, i.e., select the 1 from the 3 we all know, but why not considering just to update to new SVN and wait a bit more to see where we go?

Well, now that I'm talking about Subversion, I'm going to talk you about a couple of features I worked on recently (and committed today), as my first ITO day, in the Subversion Addin of MonoDevelop: revert to revision, and revert changes from a revision. The mandatory screenshot (you get to this dialog when requesting the Log inside the Version Control contextual menu):


This reduces the need of having a console open when coding with the MonoDevelop IDE, which is a thing that many developers request.

Another feature I completed is the new pattern for searching in many files inside MonoDevelop: Current project (previously we only had "Whole solution", "Directories" and "Open files"):


Enjoy them! (Currently on SVN.)

I don't think it would be appropriate for PlanetSUSE, but if you want to have a look at the place where S.u.S.E, SuSE, openSUSE comes from, my other blog is a photo blog about the area: Nuernberg Photos.