Gunnar is following up on the init script blog posts by Erich and me. First a note to Gunnar: The idea of the init scrip snippets isn’t exactly my own idea, but rather taken from a comment to one of Erich’s posts (IIRC), I don’t know the original author anymore. Anyway, I really think that some init script generator should work. It should even be possible to fetch variables from /etc/default/<daemon-name> if needed. I’m just doing a braindump of what I have in mind for the start and stop of a daemon. I would expect a configuration file (currently I think one for each operation might be best, but INI-lookalike files might also be OK). So for the start operation, I would expect these options:

1. simple daemon, uses a default config with a hardcoded path and needs no options or only static options passed:

   [SIMPLE]
   /path/to/daemon
   option 1
   option 2
   option 3
   

   Where I chose to name one option per line so whitespace and controll characters can be part of the options without the need to quote anything.
2. a bit more complicated, needs a few variables from /etc/default/daemon:

   [TEMPLATED]
   /path/to/daemon
   option 1
   %PARAMETER_FROM_ETC_DEFAULT%
   --parameter=%ANOTHER_ONE_FROM_ETC_DEFAULT%
   

   Where the script generator would have to make sure that the parameters from /etc/default are filled in at runtime. I would expect POSIX-Shell-Scripts in /etc/default for this.
3. Really complex: A custom script snippet is needed which has to do some specificc tasks, like cleaning possible stable locks which had been left behind.

   [SCRIPT]
   rm /var/lock/daemon.lck
   /path/to/daemon --background --and --other --options
   

   Where the script generator would simply take this script and use it where it would otherwise generate its own code.

As for stopping, I generally see only three options for the sysv-like background processes: Either a script is needed (see above for how that would look like) or a process needs to be killed according to a PID-file or the process name (with the later being rather bad). So this would result in:

1. [SCRIPT] like for starting the daemon
2. killing by PID-file:

   [PIDFILE]
   /path/to/pid-file
   

3. killing by process name/executable:

   [PROCESS]
   binary
   

   or

   [PROCESS]
   /path/to/binary
   

   where the generator would either only look at the name of the process (first version, no full pathname) or for a process with the given executable (from /proc/ /exec, I would expect).

Alright, this would leave the cases of running (instead of backgrounding) the server and stopping such a running server (the later should be fairly simple unless the stopping of the server requires additional actions other than simply killing it) as well as the reload/restart/status stuff. But these should also be relatively simple actually. What would be interesting for me:
Does any init system require information that is not part of the following list? I would plan with supplying information how to:

• start server in background
• start server in foreground (without the need for a terminal)
• determine wether a server runs (status)
• determine wether a server is ready to serve requests (also part of status)
• determine wether the server is installed (and able to be started)
• stop a background server
• stop a foreground server (unless specified, a simple SIGKILL to the process is assumed)
• restart foreground server (unless specified, a simple stop-start cycle is assumed)
• restart background server (unless specified, a simple stop-start cycle is assumed)
• reload config (unless specified, it is assumed that reloading doesn’t work and a restart is needed)
• reopen logs (unless specified, the “reload config” operation is assumed to do this)
• some meta information: short description, needs writeable filesystem(s) mounted, needs a certain daemon to be running already (or even: able to serve requests), enhances other daemon X and should be started before it (don’t care if X isn’t installed/configured), is enhanced by daemon Y and should be started after it (don’t care if Y isn’t installed/configured), replaces daemon Z, should only run once at startup, …

Finally, even with all that information available inside a Debian package, this would still leave one question unanswered: Who triggers init script generation? If a daemon package does so in postinst: How do I switch to a different init system? If the init system does it in postinst: What happens to additional daemons installed later on? If they get regenerated during system start: How much penalty does that cause? Currently I think the route to go is to provide a command to daemon packages’ postinst that (re)generates only the needed scripts for that package and have a command used in an init system’s postinst which regenerates all of them. That should do. Regenerating during boot would most likely take too much time and has other problems, too, like the availability of a writeable filesystem to store the generated scripts.
Alright, if someone would like to see this post (or rather parts of it) on the Wiki page about an Init HackFest, please transfer it there yourself. I’m currently not able to log in, for whatever reason.

Following a previous thread on Planet Debian (allowing for kids delaying projects, as usual), I borrowed a power meter to see what the consumption of various computers and electronics around the house was. An interesting and worthwhile exercise. Computers My main gateway system (hosting this blog, mail, etc. on a static IP) is a Pegasos PowerPC; it is on 24 x 7, and pulls approx. 60W. Other computers around the house include a Dell 2.5 GHz P4, which is my main development machine (with multiple disks, etc. onboard) pulling 72W. Downstairs, for family use we have an Intel MacMini pulling approx. 30W. Peripherals add up: on the Pegasos there is an ADSL router and a Linksys Wifi router, pulling approx. 5 W each continuously, and a UPS which consumes around 10W (I'm not sure if this is continuous, or high because its recharging a battery which was drained by pulling power plugs to measure the power usage ...). The LCD monitor upstairs (used by Pegasos and Dell) draws 20W. If I was purchasing again, I'd get a MacMini for the gateway. The current setup costs, I estimate, 7.50 Euro /month, which is probably worth it to have a 24x7 server (I'm not sure if moving to a hosting facility would be worth it, as it has advantages for running bittorrent, etc. that a remote server wouldn't, as well as being able to host content without the legal threat that a hosted server would have: with the current setup, if anyone challenges the content of stuff on my server, my ISP is not legally involved (as I host it), and hence won't (or shouldn't) pull the plug. This is worth something to me, even if I don't spend my days in court defending libel actions). One surprise was the CRT monitor used with the MacMini draws 10W when powered off, not on standby. Turn it off at the mains switch rather than the monitor button. Wall warts (chargers, etc.) draw around 1-2W due to eddies when nothing is connected. Conclusions: Swapping the Pegasos and MacMini are not an option as the family prefer the convenience of the fast start-up OS X. (This has made me think fast booting and suspend-to-disk are good priority goals for Debian.) I might however replace the Pegasos with an old pentium-class laptop, which would, at 25W, drop 40-50W as I would no longer need the UPS for 24x7 use. Put all peripherals, wall warts, etc. on a separate power strip that can be easily turned off together when not in use. TV We have a TV with the growing set of set-top-boxes: a DVD Player, Satellite unit and VCR, along with a SCART switch to connect them all together. Between them, they pull 86W. With the TV turned off, the boxes draw 20W. (TV pulls 10W on standby). I've been looking at getting an "Intelligent" mains lead, which cuts the power to the peripherals when the main item (e.g. the TV) is powered down, either totally or on standby. At nearly 40 Euro, however, it will take over a year to pay for itself. The alternative is just turning them off by hand, but of course as in most houses, the main switch is buried behind the TV cabinet out of reach. I'll swap the power strip with one with a single main switch that can be reached easily at the end of the evening instead. Other Big Users The house was designed with energy-efficiency in mind, and theres not much scope for savings elsewhere. The main users are underfloor electric heating, water heating, washing machine and dryer (condensor type). The water heating we hope to replace / augment with Solar over the summer; ditto the drier, with an outdoor shed /gazebo for drying clothes in the rainy Galway days. While the drier consumes a lot of electricity, at least the hot air is recycled via a heat-exchanger to heat the house in winter when its most used. Its worth keeping an eye on the drier and washing machine, though. We mostly use these at night, using cheaper Night-rate electricity, so while our usage patterns may not change, keep an eye on the energy consumption of these devices: as they grow old the bearings, motor, etc. begin to wear and energy consumption goes up. Look out for when to replace them. The other big niggle I have is a light fitting in the main living room. This is expensive, with 3 x 60 W spotlight bulbs in it. The kitchen, which is approx. half the size of the living room, gets lit by a single 20 W CFL. Swapping the spotlights with CFLs is not an option, and replacing it means replacing a ceiling mounted fitting: as the wires are embedded in the ceiling, moving it is not trivial. Any recommendations ?

Since I upgraded my home server to Etch last week-end (a few hours before the official release was announced), I have noticed some strange behaviours on my Wordpress powered weblog. The issue only occured with the RSS feeds, which didn’t display the posts they were supposed to. I have just found the origin of the problem to be mod_cache which was enabled during the upgrade to apache 2.2 without I noticed it. I disactivated it at least temporarily, time for me to enquire how I can disable caching with specific mod_rewrite generated url. This was already discussed a lot. At least, I haven’t flooded Planet Debian!

I just rewrote my aggregator (schcyrssmerge2) which still works roughly on this algebra from 2004 (still the basic set theory rule of blog aggregate generation: aggregate_i+1 = (blogs/aggregate_i) u (aggregate_inblogs)) but now calculates agg1 a different way. First, there's agg0 - the items from the input RSS file - and I store only the post ids of agg0 as agg0i for speed. Previously, I was reading in all the blogs and doing the above set theory calculation in one go. With a couple of ill-behaved blogs (full-content feeds of a few hundred kb), mzscheme's memory usage was just getting silly, topping out at hundreds of megabytes to merge 4Mb of feeds into a 3Mb aggregate. I think some of the problems are PLT's - reading a 3Mb RSS file in with

"(define a (call-with-input-file "friends.rss" read-xml))"

seems to result in mzscheme (v352) holding 100Mb. What's with that? Anyway, now I've written a newitems function which extracts new items not listed in agg0i and old items which still appear in a blog and adds them to lists. Then, there's a function which tail-recurses over all the blog filenames, parsing the RSS, calling newitems on each one and building the lists of old and new items. Finally, agg1 is the new items appended to the old items. That is only calculated as it gets written out as a RSS file. I'll give it a few days of testing, then I'll publish a tarball. I use this to build my all.rss feed from my various source feeds, in case you didn't realise, as well as to run some planets for public and private use. Anyone got a suggestion how best to reduce the read-xml memory consumption? Upgrade? Switch dialect? I'd like some XML read/write functions and the SRFI list functions.

Yesterday afternoon, we started our information meetings with employees about our Linux on the desktop project. We're underway on our migration.

But before I talk about that, I need to back up and describe what the project is.

We are converting approximately 80% of our 150 or so PC users to Linux desktops. They're Debian etch (4.0) running Gnome, Firefox (Iceweasel), Evolution, NFSv4, and SystemImager. Over the coming days and weeks, I'll be writing about why we're doing this, how we're making it happen, things we've run into along the way, and the technology behind it.

Today I'd like to start with a high-level overview of the reasons we started investigating this option.

It became apparent that Vista was going to be a problem for us. Most of our desktop PCs are not very old, but Vista meant a significant degradation in performance from the Windows XP Pro that most people were running. A performance dip so significant, in fact, that it would have created a significant negative impact on employee productivity.

We tend to buy PCs with Windows licenses from the vendor (Windows preinstalled). As such, we knew it wouldn't be long before XP-based machines would be hard to find. If we stuck with Windows, we'd be running a mixed-OS network -- which we knew from experience we did NOT want to do. The other option would be to replace all those old PCs. The direct costs of doing that, with the associated Vista and Office licenses, would have been more than $200,000.

So we started to look at other options -- changing the way we license Windows, sticking with XP for awhile, or switching away from Windows. This last option sounded the most promising.

I took a spare desktop-class machine, representative of the hardware most end users would have, and installed etch (then testing) on it. I spent a bit of time tweaking the desktop settings, making things as transparent to the user as possible. We liked what we saw and started pursuing it a bit more. We knew we had some Windows apps we couldn't discard, so we tested running them off a Windows terminal server with the Linux rdesktop client. That worked well -- and the appropriate Server 2003 licenses plus CALs would still be far cheaper than a mass migration to Vista.

To make a long story short, we are getting quite a few benefits out of all this. One of the most important is a single unified system image. Excepting a few files like /etc/fstab, every system gets a bit-for-bit identical installation from the server, updated using rsync. /home is mounted from the network using NFS (v4). So our users can sit down at any PC, log in, and have all their programs, settings, email, etc. available. A side benefit is that hardware problems become minor annoyances rather than major inconveniences; if your hard disk dies, we can just bring up a different PC. We had tried numerous times to make roaming profiles work in Windows, but never really achieved a reliable setup there -- perhaps because it seemed virtually impossible to assure that each Windows PC had the exact same set of software, in the exact same versions, installed.

More to come.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script. Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway. So what does a typical init script in /etc/init.d do? If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts. A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code. The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable. Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there). The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message. An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work. Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.

Yesterday, I wrote about our init actually being /bin/sh, since all sysvinit does it start a single shell script.Today, I'm going a bit into how services are brought up with sysv-style init. I won't be writing much about runlevels, since most users will not make use of multiple runlevels anyway.So what does a typical init script in /etc/init.d do?If you want to find out yourself, consider looking at /etc/init.d/skeleton, which is a template for init scripts.A modern init script should (as required by the LSB) start with a formatted comment with metadata such as dependencies and description. This is already trying to address some shortcomings of sysv-style init, but no actual code.The first thing most init scripts do is to check if their application is actually still installed. Init scripts are sometimes created by users, or are not automatically uninstalled since being treated as 'configuration files'; so it occurs often that the init script is still around even when the service was uninstalled. So they test if they're installed and executable.Next they probably read a configuration file, usually named /etc/default/packagename, with user settings (people used to do such changes in the init script itself, but for upgrading it proved to be a lot better to put all settings the user might want to modify there).The third step is to do the requested user action, which usually is one of 'start', 'stop', 'reload' and 'restart'. Some init scripts also have extra actions such as 'status'; not all init scripts support 'reload'. Doing such an action usually means to print out a status message and launching the service in the background (usually using the 'start-stop-daemon' daemon helper, which offers functionality to e.g. record the process PID in a file or forcing applications into the background that don't do so on their own), or locating the service (usually via a PID file, again this is commonly done using start-stop-daemon) and reloading or stopping it. Upon success, they again print a status message.An init script could be as simple as:

#!/bin/sh
if [ "$1" = "start" ]; then
  /usr/local/sbin/mycheapdaemon &
fi

There are many good reasons not to do it that way, but it will work.Some characteristics of sysv-style init scripts:

• When starting or stopping services manually, init is not involved. Or notified. (In particular this means init will still try to stop the service on shutdown, and will not try to stop services that aren't on it's list of services to stop.) - there is no system-wide state tracking.
• if a service quits, nobody notices
• init scripts do a best-effort to return a meaningful status if the startup of the service was successful. But often this is not possible (e.g. when a daemon backgrounds unconditionally before checking if it has a working configuration)
• init scripts are often run by the root user, and can sometimes even be executed successfully by non-root-users. This is particularly annoying with SELinux in 'strict' mode, that tries to differentiate between applications started by the system administrator and system services. For full protection, you need to use run_init /etc/init.d/script start, which will transition into the system user role, then start the service.
• many services aren't very cooperative and need the help of start-stop-daemon for writing pid files and/or backgrounding
• Since services are started/stopped by the admin occasionally (e.g. during upgrades), and init scripts are supposed to print a status message (these "Starting service foobar: foobard [done]" messages), they will have file descriptors open to the admins console. They will also inherit environment variables from the admin. When a daemon fails to handle them appropriately, odd things can happen. This ranges from services dying when the admin logs out (and they quite on a SIGPIPE signal triggered by the file descriptor being closed; this is why 'nohup' in the coreutils package exists. An example is IBMs tivoli backup software) to e.g. tomcat behaving differently when it has a $DISPLAY variable (i.e. started with a graphical output available).

Keep your eyes open for the next part of this series, where I'll show how some init systems improve on these issues.[Update: next part]

Today - as many of you have already noticed - is/was a big day for Debian:

• Sam Hocevar won the DPL election


• Debian (old)stable 3.1 released a new version


• Debian Etch 4.0 was released

Well, I could add another topic:

• Debian is no longer Debian for me because not all of my archs are supported anymore

In a more detailed view:
Sam Hocevar won the DPL election
Congrats to Sam! I can agree with most of the points he made in his DPL platform, e.g. a sexier website, sexier distribution, remaing the universal OS, etc.
sexier website: Really, the current design of Debians website is awful. It's really something back from the 90s. Bad look, bad design and stuff you're looking for is difficult to find, because it's badly structured and stuff is spread all over the place. I think, it would be good to have some decent CMS and some good designers/graphic artists - a good package maintainier doesn't make a good webdesigner.
sexier distribution: Many people are using Ubuntu because they're desktop users. The current release cycles are way too long and drive people away from Debian. It's a different matter, of course, for servers or managed systems like Terminal Servers or such. Those are fine with longer release cycles. Splitting up the release in some core and sub releases is a quite common proposal. Yes, this split is difficult, but I think it's the way to go.
remaing the universal OS: As of the release of Etch, Debian became the no-more-universal OS - just because m68k wasn't released for obscure reasons. I'm a great m68k user and now I'm left behind by Debian with the problem that my pet arch is not supported anymore. Running testing/unstable is not an option for m68k IMHO. Because the m68k porters didn't come up with an alternative release plan so far, I think it's the best to shutdown my 3 m68k machines - all of them are m68k buildds - within the next weeks or months. They're producing (well, some little) heat, some disturbing noise and consume a lot of power of course. Currently I accept those drawbacks in order to help the m68k port by donating CPU power running some buildds for about 7 years now. I've spent much more money on this purpose - not only for paying the electricity bills - for phone calls to get crashed remote machines rebooted, sending replacement parts for other buildds or even driving by car to bring machines or other parts to other persons (like crest.debian.org to Michael Schmitz or accel boards to the Netherlands for porting stuff. Anyway, I will happily reactivate the machines when it's up to make a new release for the m68k architecture again! :)

Some other point Sam mentioned in his platform is this:

There are very useful services around, such as http://www.buildd.net/, http://bts.turmzimmer.net/ or http://bjorn.haxx.se/debian/. I cannot understand why they are not Debian services.

I already had a conversation with Sam about this in which I expressed my general intention to develop at least Buildd.Net beyond its current state - it's quite frustrating for me to see Buildd.Net being stuck in development just because I've no more time and skill to develop Buildd.Net further. Sadly, my call for help wasn't as successful as I wanted. Only two persons wanted to help: faw and joey - and both are quite busy with other stuff.
Apparently, Buildd.Net will most likely suffer from shutting down my m68ks due to the missing m68k Etch release as well, because it was always a frontend to my m68k buildds in my eyes. All other stuff on Buildd.Net is just a nice addition to that. And when I don't operate m68k buildds on a daily basis, it's obvious that I won't invest much more time into the development of Buildd.Net. This is already true for the past year where I haven't found the time to fix some serious problems in the backend scripts and database of Buildd.Net, which basically breaks store_packages2.py (source and therefor ptracker.cgi(example) as well. I even haven't found the time to setup trac and svn again after the move to the new server during last autumn.
Erm, anyway.. back to the topic: I wish Sam the best for his period - but I don't think that he can make a big change. I doubt in general that any DPL is able to push big changes in Debian. One reason for this is the short period of just one year. Another reason is that many DDs won't let big changes to be made.

I've upgraded an old woody box to etch these days. Live - I've been telling people they need to find a replacement for this machine for years now, but it's still around and playing an important role. And with 'woody' I mean 'a woody heavily played around with, with a couple of backports and exotic stuff like XFS, a custom 2.4.25 kernel with grsecurity'. Especially the latter was why I was afraid of doing the upgrade. In a first step, I incrementally upgraded everything to sarge (well, at least where the backports weren't already newer than sarge). I installed the stock sarge kernel, and prepared a reboot. The reboot was then done out of schedule, because the machine died on it's own - it has been crashing about 1-2 times a year, and it hadn't happened for some time. Judging from the logs, it was that old problem again. At second try it came up with the new kernel: I always forget to enable init ramdisks in the bootloader when switching from a custom kernel with every needed module built-in. I then continued upgrading to etch, pretty much one service at a time. Some things (I didn't do a full list; the box was running to many modified versions of packages of this being useful as upgrade reports to the release team, and it's a bit late in the schedule, too) where upgrading didn't work out of the box:

• Incompatible configuration file changes: amavis, courier, monit
• OpenLDAP refusing to load one of the third-party schemas
• Newer Courier POP/IMAP is incompatible to drac, breaking SMTP-after-POP
• Configuration changes of saslauthd breaking SMTP-AUTH
• IMP3, a webmail interface, doesn't work with PHP5. It has been replaced by IMP4 in sarge, however I'd like my users to be able to keep on using it for some while (and I need to find a way to migrate e.g. the address book over). I consider this a major upgrade annoyance with PHP5, that it no longer allows "return false;" in some situations (if you want to return by reference, you need to use a named variable). The behaviour of "get_class" also has changed in an incompatible way.

But other than that, the upgrade was mostly a job for apt-get, not for me. The bad news: there is still something wrong with the machine. It doesn't crash, but spits e.g. the following to dmesg:

amavisd-new: page allocation failure. order:5, mode:0xd0
 [] __alloc_pages+0x2f8/0x370
 [] __get_free_pages+0x25/0x40
 [] kmem_getpages+0x22/0xc0
 [] cache_grow+0xba/0x180
 [] xfs_bmap_read_extents+0x36e/0x540 [xfs]
 [] cache_alloc_refill+0x16a/0x220
 [] xfs_bmap_alloc+0xe0d/0x1c60 [xfs]
 [] __kmalloc+0x74/0x80
 [] kmem_alloc+0x59/0xc0 [xfs]
...

So there is something wrong with the XFS malloc handling. This has happened twice now since the reboot. I've been suspecting XFS of being related to the servers' crashes before (which tend to occur during load; the crash which 'allowed' me to switch to 2.6 actually showed the OOM killer of that old kernel killing some inappropriate processes). After the easter holidays, I'll reboot the machine with the etch kernel, maybe this is gone then.

I used to be a hardcore daily bike commuter. (By “hardcore,” I mean I commuted 20-30 miles roundtrip every day in Chicago in January.) Lately, I’ve gotten lazy, especially since I now live about thirty seconds by foot from a train station that takes me to a spot about thirty seconds by foot from my job. Also, since I’m now supporting two people (including my nearly two-year-old daughter), I’m a little more reluctant to get myself killed. I was reminded of the perils of biking in Boston this afternoon when a 22-year old bicyclist was killed by a dump truck in an area where I used to ride daily:

The bicyclist, a 22-year-old man from Halifax, was riding between two lanes of traffic on Huntington Avenue when he was clipped by a taxicab near Northeastern University at about 2:30 p.m., police said. After being clipped by the cab, the bicyclist was run over by a McCauley and Sons Co. dump truck, police said.

When I was a bike commuter, I was fairly cavalier about this sort of incident. I realize it’s still fairly rare and biking may not be any more dangerous than driving. But we still see these events in Boston fairly regularly. I don’t think it can be fixed fully by better driver education/behavior (or better bicyclist education/behavior). There are just too many streets that are poorly designed and naturally hazardous. On a related note, Nat mentioned this nasty run-in during a recent Critical Mass in San Francisco (the article is obviously from the driver’s point of view — there may be another angle on this):

Susan Ferrando, her husband, their two children and three preteens had come to San Francisco from Redwood City to celebrate the birthday of Ferrando’s 11-year-old daughter. They went to Japantown, where they enjoyed shopping and taking in the blooming cherry blossoms. Things took a turn for the worse at about 9 p.m., when the family was leaving Japantown — just as the party of about 3,000 bikers was winding down its monthly red-lights-be-damned ride through the city. Suddenly, Ferrando said, her car was surrounded by hundreds of cyclists. Not being from San Francisco, Ferrando thought she might have inadvertently crossed paths with a bicycle race and couldn’t figure out why the police, who she had just passed, hadn’t warned her. Confusion, however, quickly turned to terror, she said, when the swarming cyclists began wildly circling around and then running into the sides of her Toyota van. Filled with panic, Ferrando said, she started inching forward until coming to a stop at Post and Gough streets, where she was surrounded by bikers on all sides. A biker in front blocked her as another biker began pounding on the windshield. Another was pounding on her window. Another pounded the other side. “It seemed like they were using their bikes as weapons,” Ferrando said. One of the bikers then threw his bike — shattering the rear window and terrifying the young girls inside. All the while, Ferrando was screaming, “There are children in this car! There are children in this car!” …

Update 4/5/2007: the 22-year-old bicyclist had a myspace page.

My previous post generated a lot of useful comments. Some of them was about using the synaptics trackpad driver. Unfortunately it only works, as Itai Seggev says, on post July 2005 iBooks and my iBook seems to be from August 2004 (this fact took me a long time to realize). I found an adbsyn howto wich seems to have an solution. Using a kernel patch and a patch for xserver-xorg-input-synaptics you can get the ADB Trackpad to simulate a synaptics trackpad. So for the first time i a very long time I get to compile a kernel… After a very long time I get to reboot into my new patched kernel and, lo and behold, synaptics works. In the beginning i didn’t seem to work, I had a very low acceleration set but with some fiddling I got it ajusted to something useable. So for enabling synaptics on older ibooks, see: http://www.cs.unibo.it/~bigoi/howto.htm In the meantime I got glxgears turning smoothly. Now I can start compiz and see a wobly effect when I move windows around, but then compiz freezes the display. Most of the times I seem to be able to terminate the xserver, but i’ve reboted once. Steps to get OpenGL working:

• change Driver "fbdev" to Driver "radeon" in the Monitor section of /etc/X11/xorg.conf
• apt-get install libgl-mesa-dri

Totally unoriginal, but I thought it was amusing. I also get some strange search phrases: "My gas meter is making a clicking noise" - then stop using the computer and call your gas company! (In England, the contact number should be on a label on the meter, or in most phone books under "Gas".) "My computer is making loud ticking noise" - that's better. Open the case and listen to the fans and hard disks. One is probably broken. "How many cars are there on the roads today" - too damn many? "How to send an email so that everyone doesn t see the addresses" - put yourself in the To line and everyone else in the Bcc (blind carbon copy). See my email guide for other handy tips. "How do i say in an email that there is an attachment" - How about "There is an attachment"? "Samsung yp-u2 linux" - it works as long as you don't want to upgrade the firmware. More... "How to satellite aiming motor europa" - point it at the sky, not at europa. I'll add more instructions to my satellite page as I rebuild my system. "MJ bad" - at least there are 4 times as many "good" searches. "How do I get the software for the samsung ml-4500" and "Samsung ml-4500 xp drivers" - I have a Ghostscript driver patch. Does Ghostscript work as a printer driver on XP? "Cycle tracks near sandringham" - there's part of NCN1 alongside the A149, but most of the other cycle routes near Sandringham are along quiet roads (which is fine). "What does wag stand for regarding football?" - Wives And Girlfriends. BTW it's a stupid TLA IMO. "Wretton planning", "Wretton parish council", "business properties for sale in Wretton" and "properties for sale in field lane Wretton" - I've not been to Wretton in some time, let alone mentioned its planning or set up an estate agent there! "How to grow grapevine in a conservatory?" - damned if I know. I would think the temperature change each time you open a door would hurt it too much. "Hanging washing out over night" - it's a bad idea if it's going to freeze. "Why some people take so long to reply to emails" - we're busy trying to thaw the washing out. "Satellite frequency for ulster tv for sky plus box" - 10906MHz Vertical polarisation 22Msym/s, but can you record "other channels" on Sky Plus or should you buy a real DVR? "Where can i find a picture of st james swimming pool in kings lynn?" - try Norlink's Picture Norfolk section. "What happened to opensource.org?" - It was transferred from SPI to OSI. Strangely, the next search phrase listed was "simple example of unethical behaviour"... "What to do about death?" - be very still and start to rot? "bf uk cbhf" - I give up. Did 8 of you headbutt the keyboard? "I hate belkin" - Me too. "Interesting questions to ask someone" - no, not on this site. "Bar" - best idea yet. Cheers!

I'm not really sure which I find more disappointing - this, this or this.

The Ubuntu Code of Conduct is something that's designed to ensure two things. Firstly, and perhaps most obviously, that discussions don't end up bogged down in personal abuse with no useful conclusions being drawn. Secondly, and perhaps more subtly, to ensure that potential contributors aren't put off by an atmosphere of perceived hostility.

The second point has been most commonly raised with respect to women in computing (perhaps most notably by the FLOSSPOLS findings), but it's not limited to that. One of the reasons I'm not involved with Debian nowadays is the atmosphere on the mailing lists[1]. If you're about to make something that you expect to be a controversial point, realising that the likely result is going to be a certain number of responses implying that holding that opinion is stupid is a pretty strong incentive to avoid posting in the first place. Suppressing the expression of thoughts isn't beneficial, even if you're not doing so deliberately.

Now, the obvious response to this is to accuse the CoC of enforcing some sort of Tellytubby land where people are nice to each other and it's all a mutual love-in. Which isn't, in fact, the case. Disagreeing with people is fine, but disagreeing in a factual and precise manner is significantly more useful than disagreeing in a manner that gives the strong impression that it would have been more helpful if the original poster had died rather than sending the mail in the first place. You're not even obliged to behave in a friendly way towards people - just avoid behaving in a clearly unfriendly way. A good rule of thumb is probably that if you think it would potentially result in a complaint to your boss if you did it in a moderately large company, then doing it on an Ubuntu mailing list is a bad plan.

So, the original point. The joke itself implies that there's no way to know why women behave the way they do, even to the point where a (presumably) omniscient god has no idea. Unsurprisingly, telling a large body of potential contributors that their behaviour is irrational[2] isn't a great way making them feel like their contributions are welcomed. But, oh no! It's actually ok - we're supposed to replace "women" with "newbs", because suggesting that basically your entire pool of potential contributors that their behaviour is irrational is much less bad.

Cough.

We then get to Caroline's post, an expression of frustration about an aspect of life. It contains the word "Fuck", which doesn't seem unreasonable in context. There's then a complaint from someone claiming that it's offensive, which means we have to consider a few things. Firstly, is the author of the complaint actually offended, or just attempting to claim that there's hypocrisy involved? Given the context, I'd suspect the latter. Arguably this isn't really the point, though - the issue isn't whether a given person is offended, it's whether it'll offend someone who would otherwise potentially make a valuable member of the community. Right now, I'd suspect that we (as a community) don't really object to it strongly. Google suggests that swearing isn't unheard of on the lists. While swearing in the context of a personal attack is pretty clearly a violation of the CoC[3], people don't seem to be objecting to it in general.

So, is it unacceptable to swear within the Ubuntu community? Right now, I'd say that (in appropriate contexts) it's not a problem. If a moderate number of people claim that the current degree of swearing dissuades them from being involved, then it may become a problem. Accusing someone of hypocrisy for swearing (not clearly a CoC issue, especially in context) after they claimed that a sexist joke might be, well, offensive? Yeah, I'd say that that one's pretty clearly unacceptable. Telling people that it's pretty funny and that they're wrong to be offended? History suggests that it's not a good plan. If you think someone's wrong to be offended, then a good first step is trying to figure out why rather than just dismissing them.

Of course, there's also the entirely secondary issue of what the roles of planet sites in the community are. Personally, I like to think of them as opportunities to see what people are really like rather than being reflections of people's behaviours on project mailing lists[4]. From that point of view, I think that the bounds of acceptable behaviour should be a little more liberal. If people disagree, that's not a problem and things can change - but expecting people to change their behaviour before there's any sort of general opinion that it's unacceptable isn't ok.

Which leaves open the question of whether posting sexist jokes to mailing lists is on the acceptable side of the CoC[5] or not. I'd be surprised if the ubuntu-uk community genuinely thought so, but if they do then there are pretty clearly issues that we need to solve. As far as I'm concerned, justifying that sort of behaviour has no place in Ubuntu.

[1] Yes, I'm aware that there's a certain degree of irony there
[2] For the record, yes, I do believe that women often behave in irrational ways. So do men.
[3] I find it surprisingly hard not to write that as COCK. Too much Jerkcity
[4] Which is, to an extent, why this journal isn't on Planet Ubuntu - there'd be potential for things I said to be mistaken for some sort of official Ubuntu position, which would end up limiting what I could say, which would kind of ruin the point
[5] Must... resist... temptation...

TurboGears RemoteForm tip In case your RemoteForm misteriously behaves like a normal HTTP form, refreshing the page on submit, and the only hint that there's something wrong is this bit in the Iceweasel's error console:

Errore: uncaught exception: [Exception... "Component returned failure
code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]"
nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
javascript: eval(__firebugTemp__); :: anonymous :: line 1"  data: no]

the problem can just be a missing action= attribute to the form. I found out after:

1. reading the TurboGears remoteform wiki: "For some reason, the RemoteForm is acting like a regular html form, serving up a new page instead of performing the replacements we're looking for. I'll update this page as soon as I figure out why this is happening."
2. finding this page on Google and meditating for a while while staring at it. I don't speak German, but often enough I manage to solve problems after meditating over Google results in all sorts of languages unknown or unreadable to me. I will call this practice Webomancy.

I just received a question about SE Linux via email. As I don't want to post private messages containing material that's globally useful I'll answer through my blog:

> other than strict and targeted policies......other policies like
> RBAC, MCS, Type Enforcement are also there....how are these policies
> implemented

The two main policies are the strict policy and the targeted policy. The strict policy is the earliest and was originally known as the sample policy (but was given the name "strict" after targeted was developed).

The strict policy aims to give minimal privileges to all daemons. The targeted policy aims to restrict the programs that are most vulnerable (network facing daemons) and not restrict other programs (for ease of use). There is currently work in progress on combining those policies so the person who compiles the policy can determine which features of strict they desire.

RBAC means Role Based Access Control. The strict policy assigns users to roles and the role then limits the set of domains that can be entered. For example the user_r role does not permit the sysadm_t domain so a user who is only permitted to enter the user_r role can not perform sys-admin tasks. Like many terms RBAC is used in different manners, some people consider that it means direct control by role (EG role user_r can not write to /dev/hda), while SE Linux has a more indirect use of roles (role user_r can not run programs in domain sysadm_t or any other domain that allows writing to type fixed_disk_device_t - the type for /dev/hda). You may consider that the strict policy supports RBAC depending on which definition of the term you use.

Generally the targeted policy is not considered to support RBAC, although if you consider a role to merely be a container for a set of accesses that are permitted then a SE Linux domain could be considered a in the RBAC sense. I don't think of targeted policy as being a RBAC implementation because all user sessions run in the domain unconfined_t which has no restriction. I think that to be considered RBAC a system must confine user logins.

Type enforcement is the primary access control mechanism for SE Linux. Every object that a process may access (including other processes) has a type assigned to it. The type of a process is known as a domain. The system has a policy database which for every combination of domain, type, and object class (which is one of dir, file, blk_file, etc - all the different types of object that a process may access) specifies whether the action is permitted or denied (default deny) and whether it is audited (default is to audit all denied operations and not audit permitted operations).

MCS is a confidentiality protection mechanism where each file has a set of categories assigned to it. The set may be empty, may contain all 1024 categories, or any sub-set. Each process has a set of categories that determines which files it may access. File access is granted if Unix permissions allow it, if the domain-type model allows it, and if MCS allows it (on an MCS system). I have just had an article on MCS published in Linux Journal.

MCS is an optional feature for people compiling Linux from source or for distribution vendors. For Red Hat Enterprise Linux, Fedora, and Debian the decision was made to include it, so the strict and targeted policies for those distributions include MCS.

There is another policy known as MLS. This is a policy build that comprises the strict policy plus Multi-Level Security. Multi-Level Security aims to give the highest confidentiality protection and comply with the LSPP (Labeled Security Protection Profile - roughly comparable to B1) Common Criteria certification. It would be possible to build a targeted policy with MLS but that wouldn't make sense - why have the highest protection of confidentiality with anything less than the highest protection of integrity?

As for how the policies are implemented, I'm not about to write a tutorial on policy writing for a blog post, I'm sure that someone will post a link to a Tresys or Fedora web page in the comments. ;)

> there r some packages of linux in which some changes has been made
> to support linux......for eg:- coreutils, findutils

That is correct. Every program that launches a process on behalf of a user at a different privilege user (EG /bin/login, sshd and crond) and every program that creates files for processes running in different domains (EG logrotate creating new log files for multiple daemons) needs to be modified to support SE Linux. Also ls and ps were modified to show SE Linux contexts as well as the obvious programs in coreutils.

> 'Z' is the new thing that have been added to most of the
> utilities......wherever I search I get the changes made only in few
> utilities like ps, mv, cp, ls
>
> Can u help me by giving all the changes made in each of the utilities.....

Unfortunately I can't. This has been identified as an issue and there is currently work in progress to determine the best way of managing this.

I think it's time to start blogging more often about this topic, and fill this section a bit more. I mean, Mermaids was a long time ago... And debconf in Mexico with my first try on skirts, getting rid of my beard and dying my hairs red is history in the meantime, too. So, what has happened in between... Well, there was of course the Regenbogenparade which I attended and which was nice. I even ordered a special t-shirt from a shop in Australia that I totally love. In summer I met up in Bratislava with a longtime friend from a MUD I played way back, and enjoyed running around in a skirt there, too. Gladly it was a sunny day. It was though... people back here in Vienna looked more awkward at me than in Bratislava. At least that was my impression... Had been to Extremadura for the i18n meeting which was quite nice. It was quite productive, even though I have to admit that I haven't done much on that front since. Even in Spain people didn't look that strange at my skirt as over here in Austria... At our company's Christmas party I got into a talk with a work colleague about the topic and she informed me that a former working colleague of us is starting with hormone treatment after the year change and if I'd fancy a meeting with him. I was quite happy about that offer so we arranged a meeting on December 23rd. It was a bit strange at first to address him as he, and we didn't know how to start talking because said working colleague was late, but after a while we talked about various things and even were finished with the more interesting topics when she finally appeared. We arranged to visit the next Trans-X meeting after the year change.
I left them for leaving home, but I wasn't able to catch my bus on time—the subway had serious problems. Well, I thought I might spend the night in the Flex so I called another working colleague who usually hangs out there about what was going on that evening, and interestingly he told me it was Gay Heaven night. I stopped believing in coincidence long ago... Anyway, was a nice evening all in all, they had a Christmas rabbit handing out "I love you" stamps with pink ink-pads. :) The Trans-X meeting wasn't too bad. It was some discussions about various topics. After a while my first shyness dropped a bit and I started to join in the discussion at some points. After the first started to leave I had some more direct talks with two of the women from there, one of them had mostly the same trip home as me so we talked on in the subway. A week later they had set a transgender weekend—no wonder, it was the weekend of the Rosenball. They were meeting in a cafe on Friday and I joined them, a bit less shy now that I at least knew some of the faces. Maria was quite ill and was sitting in her jacket within the cafe, shivering like hell... But all in all it was a nice meeting too, got to know some more nice people. I was a bit lazy from there on, didn't join another meeting... But another working colleague did invite me to the carnival party of his sister. I thought I could try a bit more than before, in the disguise of the carnival party, so I used a bra my former wife left behind, filled it with some socks, and put up some eye makeup (quite discreet, I hate overdone makeup already on natural females...) The light there wasn't the best, so they just saw my tall body at first. It took them a while to even notice the skirt, and only after I put off my long-sleeve they haven't noticed my breast. But well, I don't really blame them, my working colleague has announced me as a he, and given the low lights it's not too bad. Though, after the host noticed my breasts he asked if he could touch them and I even received a quite nice kiss from him. :D I stumbled upon the Gaia TG Guild on Gaia Online—a quite interesting web-based community. In general Gaia is filled with mostly kids, many of them immature, not able to spell and considering that even cool, but there are some quite special guilds that are lots of fun. But still, when I stumbled upon the TG Guild I was in awe of that such a thing could exist there. What I read made me feel totally happy and more confident on the path I'm having ahead of me. Last week I finally had been to an Trans-X meeting again, and Maria showed some quite interesting reportages about transsexual people—including one that was on TV just the day before about a 14 year old girl who is already on hormone treatment and has the absolute support from her family since she was 4 and confronted them with cutting "it" off when they don't allow her to wear skirts when going out, too. All the best to you, Kim! I so envy your strength... I'm sorry about the length of this entry—but I'm sick of people who tell me that I'm only playing it, or that I would hide... And I also see it as a chance to document my path for myself. I promise—the next entries will be more often and thus shorter.

With updated cross-building toolchains and a much improved emdebian-tools package, work has finally started on actually building cross-built packages for Emdebian. Wookey has identified the first set - a usable rootfs. http://wiki.debian.org/EmdebianRootfs

Nineteen packages have been cross-built so far, from base-files and popt to util-linux and ncurses so I thought I'd make a note of how it has gone at this early stage. Packages, patches and build logs can be viewed at: http://www.emdebian.org/packages/search.php

Results:
======

1. CDBS cross-builds like a dream. No failures, no missing files, no misplaced files, no files Emdebian doesn't want (like changelogs and manpages). em_make replaces one makefile with a customised one and everything else falls into place. Fantastic.

2. debhelper packages generally cross-build quite well - as long as debian/rules sticks to actually using debhelper rather than creating bespoke rules that just do what dh_foo would have done anyway! (I then have to go behind them and remove the custom rules to get rid of manpages etc. when if the task had been left to dh_foo, em_make would have removed dh_foo automatically. Grrr.)

3. Packages built without CDBS or debhelper are an absolute PITA. I know it is a good exercise to build without "high-level" tools, but PLEASE, only put non-debhelper packages in the main archive if you really cannot have debhelper involved. It'd make my life SO much easier right now.

4. Splitting out the translation files into individual, dedicated, packages one per language is having two related effects: there are a plethora of packages in the repository with only 19 source packages built; the size of the main binary packages has dropped substantially. Some translation packages are 30-60kb in size but in Debian, 12 maybe 30 of these are packaged inside the main binary or a similar combined _common package. Users get no choice, it's no translations or all translations. I cribbed the idea from OpenEmbedded and it's nice to see it paying off, even if it means that 'apt-cache search' listings will be at least an order of magnitude longer in Emdebian. (Sounds like a wrapper is needed.) Need to start testing 'langupdate' soon to make sure it can cope with keeping users up to date with translations of installed programs.

So far, haven't needed too many cache files to be used with ./configure --cache-file but I'm bound to meet those soon.

Overall, things are going well (famous last words).

Life sometimes goes in a funny direction, like a full circle d j vu: 20 years ago, I was studying Technology of Computerized Systems (a combination of electronics and programming). Now, 20 years later, I'm starting a dream job as the Business Development Manager of Artec Group and their core business is you guessed it exactly that. The really cool thing about Artec, from a Free Software advocate's point of view, is that they contribute firmware and drivers for their products to LinuxBIOS and the Linux kernel. At this point, my initial tasks will focus on marketing and selling Artec's flagship OEM product, the ThinCan. What is the ThinCan? Actually, you're already familiar with one iteration of the product: the Linutop is a branded ThinCan, delivered with a custom hardware configuration, plus custom casing artwork designed by Fr d ric Baille of Linutop SARL and loaded with Fred's favorite Xubuntu configuration. In the Linutop's case, their business model is to fill the market niche for a simple Internet surfing platform that fits 80% of average people's daily computing needs, so the hardware configuration they ordered reflects that. Still, as several readers of this blog noticed, the "Linutop" could make a fantastic thin client and, sure enough, that was the main purpose behind the ThinCan's original design; it sells well in the Fortune-500 market as an RDP client running under Windows CE. However, until recently, there simply wasn't much demand for a contemporary X11 terminal solution based on the ThinCan. That is, until LTSP took off, thanks to the contributions of Edubuntu and similar educational Linux distributions. Sure enough, someone spotted the opportunity and contacted Artec to order a branded ThinCan iteration with Etherboot and PXE support, which they call the Linuterm. By the way, for those who need a really cheap OEM thin client, I've got a great spring clearance offer for you:

Artec has about 500 pieces left of their older DBE60 ThinCan model, based on the AMD Geode SC2200, and we're selling them at 100 euro / piece, plus VAT and shipping.

The DBE60 is configured with three USB 1.1 ports, one parallel printer port, one 100baseT Ethernet port, one VGA port (up to 1024x768 @ 16bpp 60-85Hz or 1280x1024 @ 8bpp 60-75Hz) and one 1/8" stereo audio output jack. Its BIOS provides Etherboot support and its motherboard is populated with 64MB of RAM and 32MB of Stratoflash. It comes delivered with a European AC adapter. The Geode SC2200 is fully supported by the Linux kernel with the sole exception of a missing ALSA snd-scx200, but this could easily be ported from AMD's deprecated OSS driver and X.org support is provided by the "nsc" driver.

Minimum order size is 10 pieces. Contact me via my full name (unaccented, with one hyphen and one dot) at artecgroup.com quoting this special offer.

PS: someone was asking if that DBE60 special is also available in the aforementioned Fortune-500 configuration. It indeed is: add 16 euro / piece for the Windows CE 4.1 license with an RDP client.

Tomorrow at 9 in the morning some officers from the Valencian regional Government will drive up to the mountains of the Bartolo, Serra Perentxissa, Montd ver and Carrasqueta to power off the set of antennas which have broadcasted the signal of TV3, the Catalan public television, during the last 20 years for the entire Valencian territory. These news have been responded with protests from most of the Valencian cultural collectives. You can sign a petition, or send an e-mail, which will be swiftly ignored by the people in charge. Behind the official reasoning for this attack to our freedom of choice -the broadcast is illegal- there is a set of good reasons for the usual suspects, the Valencian Partido Popular to do this. The biggest one is that two months before the local and regional elections, the right-wing are doing their math and it may not be working out too well for them. They need to scrape as many votes as they can, and an easy granary is attracting the extreme right-wing, which is a bit active but fragmented in the region, and mostly in the city of Val ncia. This social group is greatly virulent against anything which sounds like Catalan , especially the people known as blaveros , who claim our culture and language has no common root and has nothing to do with the culture and language from the North. Fortunately, the ISO 639 standard and the entire scientific community agree that they are nuts. But back to my rant. So, how can the PP try to get a handful of votes from the right-wing? Easy, start an anti-TV3 show on the media and start scalating it until the final act -tomorrow-, where milions of citizens are deprived of one of the best channels available in our TV sets. This will surely be sold as a major victory against the Catalan invasion or as the end of an "alegal situation", although there are like 30 other channels in the same situation in the city of Val ncia, and the PP-controlled Canal 9 channel is broadcasted in the Balear Islands (also controled by PP) in the same legal situation. In a time when watching Middle-East or American channels is trivial using a satellite set, some people think the best thing they can do is to end a service paid and provided for free by Acci Cultural del Pa s Valenci , an important cultural entity, during the last 20 years, ending the right to choose one of the only channels with all the programs in our language for milions of Valencians. Their right to do it is also challenged in court, but there is no doubt that tomorrow they'll go ahead and shut it off. We could have a reasonable government who would maybe want to accept the Catalan TV and radio channels in our territory, if the Catalan government would also accept our (crappy) channels in theirs, but they refuse this as well, because they now feel insulted . All in all, I had enough of PP long ago, and am hoping I am not the only one. In less than a month, Valencians will celebrate the 300^th anniversary of the Batalla d'Almansa on the 25th of April of 1707, although we seem to be fighting a new battle now in 2007. The Batalla d'Almansa meant the end of the War of the Spanish Succession in Spain, but also the start of tough times for our culture, language, and people, when Felipe V abolished the Valencian furs. But this story can make a blog post of its own next month. Quan el mal ve d'Almansa, a tots alcan a...