The host that provides all the primary services for the Wesnoth community, including forums, wiki, add-ons and the primary MP server, has been down for the last 4 hours. Work is underway to determine the causes and solve this problem as soon as it's possible. Stay tuned!

UPDATE 2010-07-31: the server went back online around 3:00 AM CEST. So far we still don't know the reasons for the crash, but we know that the server ran out of memory, which could have locked up the operating system indefinitely before being rebooted by hand.

In the past, I've seen many people from Wesnoth's user community and Development Team advocating the use and implementation of WML in Wesnoth and, potentially, other games.

Even I have participated in some debates over whether WML is good or bad for content developers. I have also expressed my opinions on topics such as the old, scrapped Python AI and the currently thriving embedded Lua support, all of this on IRC, usually in #wesnoth or #wesnoth-dev, and even #wesnoth-umc-dev.

I have got to admit that my personal opinions on programming languages have changed over time, mainly because I've learned from real experiences when maintaining or starting small to medium-sized projects built upon some of them. WML sort of counts as one of those since I'm the author and former maintainer of Invasion from the Unknown and, more recently, After the Storm. I have also worked on the WML events engine a bit implementing new features or fixing known and unknown bugs, including some I've found while developing my own WML content.

At this point, I think I am qualified for thoroughly examining the pros and cons of WML with a less partial point of view, so here's a rather lengthy review of both, despite the title of the article, which deliberately sounds like flamewar bait for the audience.

I just found out that Chromium (browser) has been in Debian experimental and Sid for a while.

I'm currently tracking Squeeze and pulling some packages from Experimental, in particular Iceweasel 3.6, which feels much more stable to me than its counterpart in Testing, version 3.5 — which will probably have to remain in the upcoming Stable release as explained by one of the package maintainers.

(Granted, I'm a fool who doesn't care about security because I don't visit unknown odd sites at all. If it weren't for this, you'd say I should not be pulling packages from Experimental, but I am, fully understanding the risks!)

Despite I can see other packages from Experimental in my package manager, including a localization package for Chromium, I can't see Chromium itself, which is really odd. I have Google Chrome installed and I pull it from Google's repository because…because it added itself to apt's sources after I installed it for trying it out last year — which unfortunately reeks of Internet Explorer's old “integration” thing that started with IE 4, frankly. I mean, why didn't it even ask me about adding the source? Is it modifying other parts of my system's configuration without my consent? What the hell, Google?

Rant aside, this is a strange coincidence, which could be related to a mirroring issue in any case, but I don't rule out the possibility that Chrome is somehow banning Chromium from my package manager. Alternatively my laptop might be possessed by some evil spirit that wants me to leave Debian's free-as-in-freedom packages for evil “Big Brother” software suites. Uncanny?

(For the Google lovers and haters in the audience: I'm perfectly fine with using Google stuff, mind you. My main email account is from Gmail, my preferred only search engine is Google's, I also use Google Maps, Google Earth, and this memory/method call profiling suite of sorts that Sirp recommended to me. I also use Google Translate and reCAPTCHA. So, no, I'm not really bothered by Google Chrome's additions, but I'm really mildly pissed off at their decision to change my package manager's sources without asking me through debconf or something.)

Sometimes people (especially Windows users) ask me what I use for some common task in Linux. These are my software preferences when working on various environments; your mileage will definitively vary.

For those who won't be following me on Twitter, or aren't following the relevant website closely, Frogatto's just been released for the three main platforms! Now we are only missing the Apple appstore approval, so soon this game and my levels will be available for mobile users so they can waste their time playing a colorful and pretty platformer no matter their location!

Just as planned.

Finally, the trap that is social networking has caught me.

I have joined Twitter as ShikadiLord (since “shadowm” and “shadowmaster” were already taken ) mainly because of Frogatto, which also has presence in Twitter now.

Let's see if I make use of this thing. To make things easier for me I'm using Choqok, a micro-blogging client for KDE SC 4.

Yays.

After successfully trying the AMD Catalyst driver (a.k.a. fglrx), I decided to go back to the open-source drivers for several reasons.

• A certain memory allocation failure from X.org scared me a bit.
• The proprietary drivers don't play well with SuperTuxKart (e.g. Debian bug #586797) causing texture corruption both with 0.6.2a and SVN trunk.
• Tearing. Lots of tearing with 2D. Forcing use of VSync in the configuration causes increased CPU usage for some reason.
• XVideo acceleration consumes some more CPU time than the free drivers' code for some reason (uh...).
• I discovered that the screen or GPU buzz when running on batteries after all.

There isn't anything in fglrx that I really needed to have, so I'm sticking to the free (open-source) drivers again, most likely for the rest of the laptop's lifetime.

After unsuccessfully trying the ATI Radeon Kernel-Modesetting driver with Linux 2.6.34, and reading about some performance comparisons with AMD/ATI's proprietary Catalyst drivers and the free Mesa DRI drivers, I decided to give AMD/ATI Catalyst (a.k.a. fglrx) another try.

When I decided to do that, fglrx 10.5 was in Debian's Testing, so I waited until the next day for fglrx 10.6 to enter Testing.

I've been using fglrx for the last 2:30 hours and haven't experienced any difficulties so far with OpenGL or Xv. Switching consoles works, suspend-to-RAM works, suspend-to-disk works, and I don't hear any buzzing from the screen, although I can't be very sure since the fan has been making very loud noises since around December last year. I have suddenly regained my faith in AMD.

There is one minor issue with Tux-On-Ice since it seems to run out of memory for drivers for the atomic copy step, probably due to fglrx. This causes TOI to try the same step twice or thrice before hibernating successfully ­— but solving this is most likely a matter of increasing CONFIG_TOI_DEFAULT_EXTRA_PAGES_ALLOWANCE (currently 2000) in the kernel config.

TuxOnIce debugging info:
- TuxOnIce core  : 3.1.1.1
- Kernel Version : 2.6.34-bluecore280-suspend2
- Compiler vers. : 4.4
- Attempt number : 2
- Parameters     : 0 667656 0 1 -2 5
- Overall expected compression percentage: 0.
- Compressor is 'lzf'.
  Compressed 1638621184 bytes into 554865401 (66 percent compression).
- Block I/O active.
  Used 78251 pages from swap on /dev/sda10.
- Max outstanding reads 851. Max writes 3700.
  Memory_needed: 1024 x (4096 + 320 + 104) = 4628480 bytes.
  Free mem throttle point reached 0.
- Swap Allocator enabled.
  Swap available for image: 1496831 pages.
- I/O speed: Write 91 MB/s, Read 105 MB/s.
- Extra pages    : 4118 used/4503.
- Result         : Succeeded.

The Extra pages line is what matters here.

While performance overall is much better than with the open-source drivers from Mesa, and Frogatto is usable with Kwin's compositing at last — even if still slightly slower than in non-compositing mode — there are some occasional odd messages in the kernel's log.

[fglrx:firegl_acpi_video_event] *ERROR* Could not find private acpi context by video busid: LCD

Nothing to worry about, I hope.

UPDATE: Effectively, increasing CONFIG_TOI_DEFAULT_EXTRA_PAGES_ALLOWANCE seems to have solved the hibernation issues.

- Extra pages    : 4041 used/5200.