I have updated apt-p2p to version 0.1.3, which is available now in unstable and my repository (see my previous post introducing apt-p2p). This update brings mostly speed improvements to finding peers to download from, and performing the download. Nodes in the DHT are now checked for responsiveness more thoroughly before adding them to the routing table, and rechecked more frequently afterwards. This should prevent bad nodes from propagating through the system, and departing nodes remaining in the system long after they have left. Downloading from peers is also quicker, as bad peers are dropped with a quicker timeout value and after a small number of errors. There was also a bug revealed by about 10% of the mirrors that caused downloads to fail, and was fixed in version 0.1.2. This update is STRONGLY recommended, as keeping unresponsive nodes out of the DHT will make everyone's experience better. If you tried apt-p2p and had some problems, I hope you'll consider trying again now. Unfortunately, these are enhancements I could not predict needing before releasing to the public, as the problems they solve are all caused by having a larger number of users, some of which are unresponsive. There are still a large number of peers (maybe 50% of them) that are unreachable, and so can not share any files with other peers. I don't have a good way to check yet, but you can go to sites such as this one to probe your client for you. Just enter the remote IP address and port (available on the status page) of your client in the form http://ipaddress:port/ (e.g. http://1.2.3.4:9977/). If the check returns any HTTP headers (even a 404 Not Found response) then you're fine, but if it doesn't return anything then your peer is firewalled or NATted and should probably be fixed. Here are the changelog entries for 0.1.2 and 0.1.3:

• Speed up downloading from peers
  • Set a new peer's ranking values so they don't get an unfair advantage.
  • Reduce the HTTP connection timeout to 10s.
  • Drop peers after a limited number of errors.
• Speed up the DHT requests when nodes fail
  • Schedule a re-ping message after adding a new node.
  • When a node fails, schedule a future ping to check again.
  • Send periodic finds to nodes that are stale.
  • Increase the stored value redundancy to 6.
  • Increase the concurrency of DHT requests to 8.
  • Add early termination and ignoring slow responses to recursive DHT actions when timeouts occur.
• Remove the debconf note about port forwarding (Closes:#479492)
  • Add a NEWS entry for port forwarding
• Fixed a bug in the HTTP downloader that caused errors with some mirrors that always close the connections (Closes: #479455)

www.ted.com is a premier partner for the Miro player [1]. This is a free player for free online content, the site www.getmiro.com has the player for download, it has binaries for Mac OS/X, Windows, and Ubuntu as well as the source (GPL licensed), it is in Debian/Unstable. It supports downloading in a number of ways (including bittorrent) and can keep the files online indefinitely. A Debian machine connected to the net could be a cheap implementation of my watching while waiting idea for showing interesting and educational TV in waiting areas for hospitals etc [2]. When I first checked out the getmiro.com site it only seemed to have binaries for Mac OS/X and Windows. But now I realise that it’s been in Debian since 11 Sep 2007 under the name Miro and since 12 Jun 2006 under the name Democracyplayer. I have only briefly played with Miro (just checked the channel list) and it seems quite neat so far. I wish I had tried this years ago. Good work Uwe Hermann! I hope that the Miro player will allow me to more easily search the TED archives. Currently I find the TED site painful to use, a large part of this is slow Javascript which makes each page take an unreasonable delay before it allows me to do anything. I am not planning to upgrade my laptop to a dual-core 64bit machine just to allow Firefox to render badly written web pages. Biella recently wrote about the Miro player and gave a link to a documentary about Monsanto [3]. One thing I really like about this trend towards publishing documentaries on the net is that they can be cited as references in blog posts. I’ve seen many blog posts that reference documentaries that I can’t reasonably watch (they were shown on TV stations in other countries and even starting to try tracking them down was more trouble than it was worth). Also when writing my own posts I try and restrict myself to using primary sources that are easy to verify, this means only the most popular documentaries.

• [1] http://blog.ted.com/2008/01/miro_player_lau.php


• [2] http://etbe.coker.com.au/2008/02/23/watching-while-waiting/


• [3] http://healthhacker.org/satoroams/?p=907

Share This

If you're running Apache2 on a memory-constrained system (like in a virtual machine,) you may want to choose the prefork MPM to save memory at the cost of more process forks. However, if you have more than one CPU on that same machine, you may also want to consider using the threaded worker MPM and tweak its MaxClients and ThreadsPerChild settings from the default configuration. On a typical apache2 installation on a Debian system, the worker MPM configuration looks like this:

<IfModule mpm_worker_module>
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Using these default settings on a resource-constrained system (say a server with 128MB of RAM but with no swap) would be overkill, and the web server processes will definitely eat up all of that memory, leaving little or no room for even simple CGI scripts. In my setup, I experimented with tweaking the values above to get apache2 to serve without eating up too much precious memory. I found that the important values to consider here are MaxClients, which dictate how many clients can connect simultaneously to my server, and ThreadsPerChild, which specifies how many threads of execution can run in a child/worker process. My resulting config becomes:

<IfModule mpm_worker_module>
    MaxClients           15
    MinSpareThreads       3
    MaxSpareThreads       7
    ThreadsPerChild       3
    MaxRequestsPerChild 200
</IfModule>

With this setup, I free up a significant amount of RAM from apache2's hold whle maximizing my thread usage in each worker process; at the same time, I avoid keeping each child process for too long by setting a maximum number of requests each worker can serve, preventing the workers to bloat too much when handling CGI. I also tweaked the KeepAliveTimeout setting to just 2 seconds (instead of the default 15) so that each worker process can go to the next request quickly and preventing them from being tied up to a connection for too long. I also set the Timeout to 30 seconds.

I bought an HCL MiLeap X for Shruti (who is in the tenth standard) and the IMSc purchased an eeePC for "general use". Now that I have both machines in front of me, it seems like a good time to review them.

SimilaritiesLet's be clear that we are not comparing "jamun" to "aam" (or apples to oranges, if you prefer); these machines have quite a few similarities. Both are aimed at young students who are starting to use the computer for "real work" for the first time. Both the machines run GNU/Linux, and have similar dimensions and features --- even the prices are close. However, we are here to "raise the differences and not bury them"!

Physical appearanceThe eeePC is marginally lighter and more compact. The MiLeap appears to be more rugged though I didn't dare drop either machine to check!The eeePC has a rectangular touchpad which appears to have only one button but in fact this button has a left and right! The MiLeap has two regular buttons and a circular(!) touchpad.The MiLeap is bulkier but has a nice handle to lift it by. The eeePC can be carried like a book and has a matt finish.Both were proclaimed "cute" by Shruti and Sudeshna; I depend on their opinions in such matters!

Hardware featuresThe eeePC scores over the MiLeap X in terms of hardware features. The former has a web camera, a VGA out and one additional USB port. At the same time, the remaining features of both devices are likely to be adequate for most users --- 900 MHz low power processor, graphics adapter, wireless, ethernet, smart card reader. The eeePC has 4GB storage to the 2GB on the MiLeap, but the larger base software install on the eeePC means that the user has about the same amount of working area on both machines.The extra hardware features on the eeePC do give value for the 10% extra that one pays for the eeePC; the latter costs Rs. 17K to the MiLeap's Rs. 15.5K.

SoftwareThis is where the difference between the two is most striking. The MiLeap comes with a pre-installed "classmate" version of EduBuntu. The net result is that this looks and feels like a regular GNU/Linux system configured with software appropriate for educational use.The eeePC on the other hand has a completely icon-driven interface where even getting a terminal is not easy (Ctrl+Alt+T). However, this is just the icing on top of a regular icewm cake. The applications that actually run are just the regular ones --- not customised to fit in with the point-and-click interface.The eeePC terminal has really small fonts and is a regular xterm so that fonts are not as easy to fix as they are for the Gnome terminal used by EduBuntu on the MiLeap. Overall, EduBuntu applications which are based on Gnome are more consistent with the interface than the mix and match between KDE, Gnome and icewm that has been attempted by Xandros; the latter has a lot of promise but needs more work!It was easier to install software on the MiLeap since the EduBuntu repository is significantly larger than Xandros' repository as used by eeePC. In particular, on the MiLeap we installed nethack-qt since that is Shruti's favourite game and openvpn which is needed for us to connect to IMSc from outside the LAN.The installation of the MiLeap is that of Intel's ClassmatePC on which it is based. The entire installation is on a squashfs filesystem image. The base system is used via unionfs at run time on both machines. This makes for easy "reset to default".Suspend-to-ram does not work on the MiLeap; it should be fixed by installing the Linux 2.6.25 kernel.

PhilosophyI have long believed that un-prejudiced minds (like children) will take more readily to GNU/Linux than the hordes of "experienced" (mostly adult) computer users who have well-formed opinions about "user-friendly" software and how particular applications should behave.The "standard" GNU/Linux interface actually encourages exploration and the "tune-it", "tinker" and "fix-it" approach to learning about computing. It is not a sealed box with a "do-not-tamper" sticker. (This tinkering attitude is further enhanced by the approach taken by the designers of the Sugar interface for the XO Laptop.)Since both the systems are based on GNU/Linux (and Debian derivatives no less!), I am nothing short of thrilled at how far things have come. However, will the interface of the eeePC actually encourage exploration? Perhaps the EduBuntu interface of the MiLeap will prove too daunting for a novice. (Shruti does not classify as one since she used GNU/Linux "forever".) Only time will tell ...As Larry Wall has famously said: "There's more than one way to do it!" These devices certainly prove the truth of that assertion within the GNU/Linux world.Devices like these could push GNU/Linux into mainstream usage much more effectively than the "battle for the desktop". Hence, it is perhaps not surprising the both MicroSoft and Apple are trying hard to get into the game. However, it is only GNU/Linux that can comfortably provide a plethora of applications in less than 2GB! Until small solid state disks become significantly cheaper, those guys will have to wait.

Starting to play with eeePC. Thanks to ASUS, I am now playing with an eeePC. With the help of Andrew Lee, I have set up LXDE environment, with full wifi support (through madwifi), and other goodies. I'm now looking into making the boot time shorter. I like the concept of finit, which is just to rewrite most initialization in C, nothing can beat that. However, Debian in general will need something more extensible than that. insserv and CONCURRENCY=shell helped the boot time a bit but it's still in the orders of approx. 60 seconds, which isn't quite fast enough.

Modern CPUs are great. They have all sorts of advanced power saving features, which is one of those nice cases where everyone can save money, gain performance and claim environmental credentials at the same time. Everyone's a winner.

Well. Everyone's a winner as long as your software doesn't suck.

I've talked about the benefits of the tickless kernels and reducing wakeups and spending longer in deep C states before, so if you don't know about them then go and read that first. This time I'm going to focus on a different level of hardware, and a different level of suck.

For a long time, laptops supported changing the speed of processors when switching between AC and battery. CPU power consumption is proportional to frequency, so dropping the frequency meant a longer battery life. Of course, it also meant that it took longer to get anything done - the reason this was still a win was because CPUs in those days consumed just as much power when idle as when running. Transmeta introduced a technology called Longrun with their Crusoe processors, bringing the ability to drop both the frequency and the voltage of the CPU simultaneously. With power consumption being proportional to the square of the voltage, even a small drop resulted in worthwhile power savings. As the only really worthwhile thing Transmeta brought to the x86 world[1], this was unsurprisingly ripped off by everyone else. Intel introduced their Enhanced Speedstep, AMD gave people PowerNow and VIA have Longhaul.

Obviously, reducing the frequency of the CPU increased battery life. Everyone's happy?

No[2].

The problem is that nowadays, processors don't consume as much energy when they're idle as when they're running. The aforementioned C states mean that an idle processor consumes a tiny percentage of a loaded one - an ultra-low voltage Intel part will draw on the order of a watt. Executing code, even at the lowest voltage and frequency, will draw far more power. Obviously, we want to keep the processor idle for as long as possible. The easiest way to do this would be to never run anything, but that's not a real option. The alternative is to run when we have to, but make sure that we get it over with as quickly as possible so we can return to the idle state. Counterintuitively, that means switching to the highest voltage and frequency, executing the code and then dropping back into the idle state. By going faster, we save power[3].

In summary, the only sensible way to use a CPU is to run it as fast as possible in order to let it idle as much as possible, and drop the frequency and voltage when it's not doing anything. The. Only. Sensible. Way.

Some people write software that lets you choose different power profiles depending on whether you're on AC or battery. Typically, one of the choices lets you reduce the speed of your processor when you're on battery. This is bad. It is wrong. The people who implement these programs are dangerous. Do not listen to them. Do not endorse their product and/or newsletter. Do not allow your eldest child to engage in conjugal acts with them. Doing this will reduce your battery life. It will heat up your home. It will kill baby seals. The sea will rise and your car will float away. If you are already running it, make sure that it always sets your cpufreq governor to ondemand and does not limit the frequencies in use. Failure to do so will result in me setting you on fire[4].

The only legitimate reasons for limiting the speed of your CPU are to avoid overheating (which should be fixed in the kernel, really - having userspace in charge of ensuring the continued functioning of the machine is madness) or to make the machine quieter. And if you want your machine to be quieter, there should be a tickbox marked "Reduce performance in order to reduce noise" or something, which would take into account all the sources of heat in your machine rather than just your CPU. Encouraging the managing of acoustic levels by asking users to restrict the functionality of their CPU is just another way of saying "Look! We suck!". Letting the user choose a specific CPU governor or a specific frequency is not a useful thing to do. Don't do it unless you want to see dead kittens. Delivered by UPS.

[1] And, presumably, whatever else Intel and everyone else ended up licensing off them which resulted in their reinvention as an IP company rather than a CPU one, but that's just not interesting to me.

[2] Even ignoring the people that are unhappy for entirely unrelated reasons, such as injured toenails or the brutal murder of their family

[3] There's a corner case here, which is a system that is always entirely CPU bound. Say we halve the CPU's speed. Along with the voltage drop, that gets us down to about 20% of the original power consumption. Of course, it now takes twice as long to do anything and your screen, RAM, hard drive, chipset and so on are still drawing power, so will end up costing you twice as much power as they would have done if you'd run at full speed. If you do the maths, it works out that you save power if your processor's full-speed power consumption is more than 1.7 times that of the rest of the platform. In the real world, things are made more complicated by the rest of your platform consuming more power if you're working over a longer period of time - your hard drive is going to end up spending more time spun up, your memory bus is going to be active for longer and so on. You're basically not going to hit this case.

[4] While the burning of your body will result in carbon emissions, the reduction in power usage should offset this in the long run

My previous entry features the first ever comment on this blog to arrive over IPv6. Fantastic! I guess this will be the final breakthrough that the protocol needed!!

Helping a user run GNU/Linux programs on a proprietary system when one knows that the user has no intention of switching to the use of a free system is generally a bad idea. It is sometimes called "enabling" and is generally considered a waste of one's time.All the same, there are situations when one is faced with a Mac¹ with strict instructions not to reboot or otherwise "disturb" the existing system.The news in brief is:

Debian Etch runs with Xorg (vesa driver) under Parallels.
It installs using "mini.iso" for network based install.

Using this one can run all the GNU/Linux programs one needs. It "disturbs" the existing system less than things like "fink" or "MacPorts".Another alternative is "VirtualBox" from Sun which is free for educational use (and has an "Open Source Edition" too!).QEMU offers yet another alternative. Since it emulates all the hardware it is significantly slower. However, on current hardware, the speed will be more than adequate if you just want to use standard desktop tools from GNU/Linux.

Pros

1. Applications run in the environment they were designed for.
2. Speed is "native" for running computational code as there
   is no emulation going on for this part.
3. X applications work in full screen mode.
4. Full networking support.

Cons

1. Can only run in 32-bit mode.
2. Currently runs X in "vesa" modes so you don't have
   accelerated graphics.
3. Some keys like F10 and Ctrl+Alt Alt+Enter are trapped by
   MacOS so you may have to remap these keys if your application
   uses them. (For example, Ctrl+T instead of F10 for aptitude).
4. Possible delay in disk access since parallels provides an
   "emulated disk".

Not yet tried

1. Sharing files (Samba/NFS/SSHfs?)

---

1. Also known as Macintrash. ↩

"your download link will arrive momentarily at the email address you submitted. to ensure the email does not get marked as spam, please instruct your email client to accept mail from nin.com." I wonder how many spambots are busy blasting off zillions of spams with headers forged to be from nin.com as we speak? Best of all, the spams can be customised, you know that many of the people getting them will enjoy this music. (Sometimes I wish I could take advantage of these money-making opportunities as they present themselves to me..)

Sarah and I are doing the Tour de Cure again this year, like we did in 2006, again as part of the Google team. This time around we're doing the 50 kilometre ride, since the 25 kilometre one was a bit of a cakewalk. That said, the fitness levels of both of us are pretty abominable at the moment, so it'll be interesting. So this is the obligatory grovel for donations. If you'd like to make one, you can do it at http://tour.diabetes.org/goto/andrew_pollock Here's what I'm not spamming people with:

I recently accepted the challenge of cycling in the American Diabetes Association's Tour de Cure fund-raising event. The Tour de Cure is a series of cycling events held in over 80 cities nationwide. The Tour is a ride, not a race; it features different route lengths from a leisurely 10-mile course to a demanding 100-mile journey. I have joined thousands of others to pedal in support of the Association's mission: to prevent and cure diabetes and to improve the lives of all people affected by diabetes. I am asking you to help by supporting my fund-raising efforts with a donation. Your tax-deductible gift will make a difference in the lives of more than 20 million Americans who suffer from diabetes and another 54 million people in the United States with pre-diabetes. Any amount, great or small, helps in the fight against this deadly disease. I greatly appreciate your support and will keep you posted on my progress. If you want to do even more to help, please consider joining me in this great event. Our efforts will help set the pace in the fight against diabetes. More information on the American Diabetes Association, its programs and diabetes in general can be found at the Association's Web site: www.diabetes.org. For more information on Tour de Cure, please visit www.diabetes.org/tour.

Tried to switch a CentOS domU from the Debian kernel to pyGrub + CentOS kernel today. Here’s what I discovered:

• the redhat initrd sucks
• unsurprisingly, the debian initrd will not work with a redhat kernel
• modifying the redhat initrd to do the right thing is impossible
• lets try using hdaX: no. that didn’t work.
• apparently using e2label to force a filesystem label helps? nope.
• nash is not really a shell, but instead an evaluator of static commands
• mkinitrd is a horribly written bash script
• modifying mkinitrd to generate /dev/hdaX and /dev/sdaX? no dice.
• trying to embed a shell into the initrd like in debian’s initrd for debugging? impossible.

I gave up for the night. Sadly that user is probably going to post a horrible review of my Xen hosting service to WHT now. Oh well, it’s not as if I needed his $5/mo anyway. Yes, $5/mo apparently gets you the privilege of 24×7 support now. I didn’t know. Update: Oh, cool, apparently he didn’t. Update: According to the CentOS wiki page on the subject, providing a virtual disk instead of a LVM volume makes it happy. The problem then is that any VMs made using an LVM partition can’t be transferred to a virtual disk, as the whole LVM volume is a filesystem. Or am I missing something? I suspect RedHat calls this a feature, personally I call it a bug.

Continuing on with my plans to make ikiwiki more appealing to users without a dedicated server, this evening I've written an ikiwiki plugin that makes it use Amazon S3. So, it's possible to publish a blog or other static website, built using ikiwiki, without needing your own web server at all. Ikiwiki builds a website and uploads it to Amazon, which then handles the web serving for you. If you want a traditional wiki that people can edit online, you can still serve the pages out of S3, but you will need to find a "real" web server to host the ikiwiki CGI that handles the page editing. It'll then inject modified files into S3 as necessary. Amazon EC2 would be the obvious choice for where to run the "real" web server, but probably not the easiest one to set up. In my experiments, I've been running the ikiwiki CGI on nearlyfreespeech, and serving the rest of the wiki out of S3. Since page edits are relatively rare, I estimate this approach will cost a dollar or so a year for the CGI hosting (most of it paying for disk storage). The Amazon S3 hosting of course depends on number of hits and storage size. And presumably it will scale very well, and be very competatively priced, if you believe Amazon's marketing. :-)

---

I'm loving that the design decisions I made about ikiwiki at the very beginning -- that it would use static web pages, and would be backed by a real revision control system, is now letting it be deployed in these interesting ways that I did not begin to envision back then!

Finally, I have released DAViCal 0.9.5. Hopefully this will resolve the series of installation- and upgrade- related problems which plagued the 0.9.4 release. Thanks for everyone being patient while this release was thoroughly tested through five pre-release versions, and especially thanks to those patient people who helped test those pre-releases. Now if I don't get too distracted by:

• processing my GPS tracks of the last two weeks around the South Island
• Uploading my last six months worth of photos
• Making sure the kids have done their homework
• Describing the places near where I live.
• ...anything else that catches my interest

... then maybe I will be able to really concentrate on nailing the scheduling extensions work over the next couple of months... Wish me luck!

Some of you might have noticed that in the recent weeks I wasn't active at all online. This was because I was on a vacation in Italy. On the way back I was eager to write about my experiences, but after entering Romania, I found out that may parents had been involved in a motorcycle accident due to a careless driver.

The accident took place on the second day of the Orthodox Easter (on the 28th of April)[1] while my parents were coming back from my sister's, just 20 km away from my home town, Caracal, in a village called Z noaga. There, a Daewoo Cielo was parked on the left side of the road[2], facing the direction towards Caracal. The driver decided that it was a good idea to turn his vehicle and, according to his declaration, instead of looking himself if there was anything comming, he asked a passenger if there were any cars comming.

Since a motorcycle is not a car, I guess the passenger thought it was OK to answer "no".

So the driver simply started his maneuver and managed to occupy the entire right lane, according to the accident schematics (I saw the official police schematics of the accident site with my own eyes). There were only 30 cm from the front most point of the car to the ditch on the right side of road, while the rear wheels were on the mark indicating the axis of the road. That left only 2 meters free on the opposite lane out of the 6.60 meters wide road, so there was no way for my father (driving the motorcycle) to avoid the collision, in spite of the fact he was travelling at about 40-50 km/h[3], within the legal speed limit (50 km/h).

My father barely had enough time to avoid the central pillar and aim for the rear right door of the car, obviously, a safer place to hit. Still, this wasn't enough to keep my mother on the motorcycle, a safer place for her than anywhere on the road.

My mother was projected over my father and over the car, and, luckily, landed on the side of the road, between the asphalt and the ditch, on an area covered with grass. She landed straight onto her head (the helmet protected her really well), and the shock of the landing propagated along the spine, resulting in the fracture of the L1 vertebra. She also got a fissure in the right clavicula, but that should already be OK now.

My father managed to remain on the motorcycle, but the impact was violent enough that he managed to bend the gas tank and has two huge bruises on the inside of his thighs (one for each leg). He also accuses pains in his shoulders and the lower end of the spine (unfortunately he "managed" not to do the medical investigations after the accident), but I hope all of these will pass soon and will have no ill effects. Also, out of sheer luck, at that time, my father was wearing a full-face helmet, contrary to his habit of earing an open-face helmet; due to this, his face was protected and suffered no harm, while the chin of the helmet broke after the impact with the motorcycle windshield. Also some deep scratches starting from the half of the helmet windshield up to the top of the helmet were the signs of a (probably second) violent impact with the motorcycle windshield.



So, the next time you are on the wheel, please look out for motorcycles, too. Motorcycles do exist on the road!

Also, I advice anyone driving a motorcycle to wear good protection equipment like a full-face helmet, jacket, pants, boots, gloves, etc. These helped a lot my parents, and will help you too, if, God forbid, you are involved in an accident.


My mother is in a cast that covers her from hips to shoulders to help with the fracture recovery and also wears a collar (just for safety reasons since she is suffering of spondyloses).
My father is able to walk (with some pain) and seems not to have any injures (I will take him for a close investigation some time soon in spite of his stubbornness).



[1] worrying for us (me and my future spouse), my parents didn't told us and waited for us to return to Romania
[2] in Romania the vehicles travel on the right side of the road, so the driver also drove on opposite lane, a fact which, according to the law, is punished with the suspension of the driving license
[3] he speed was confirmed by the measurements done by the police

The SANE project is working on improving SANE, extending the API and ABI in a backward-compatible manner and bumping the version from 1.0.x to 1.1.x to celebrate that. The timetable has been posted, and calls for a release of SANE 1.1.0 on July, 30th. This will be too late for the Lenny freeze by a few weeks, which means Lenny is set to be released with SANE 1.0.19. SANE 1.0.19 is a good, solid release, which is good news. I’m not sure 1.1.0 will be as solid as 1.0.19 is, so I won’t try to rush 1.1.0 into Lenny at the last minute. Until the Lenny freeze, I’m going to augment the current SANE 1.0.19 with code from the SANE CVS, concentrating mostly on bugfixes and self-contained new hardware support and features. Hence, if there is something in the SANE CVS that you would like to see in Lenny: test it, then tell me about it. You have until the end of June to do so. Currently on my TODO list:

• pixma backend update

Currently in experimental, sane-backends 1.0.19-7:

• saned & net backend with mDNS/DNS-SD support
• debconf support for enabling saned

Comments and feedback welcome.

Well a brief post about what I've been up to over the past few days. An alioth project was created for the maintainance of the bash-completion package. I spent about 40 minutes yesterday committing fixes to some of the low-lying fruit. I suspect I'll do a little more of that, and then back off. I only started looking at the package because there was a request-for-help bug filed against it. It works well enough for me with some small local additions The big decision for the bash-completion project is how to go forwards from the current situation where the project is basically a large monolithic script. Ideally the openssh-client package should contain the completion for ssh, scp, etc.. Making that transition will be hard. But interesting. In other news I submitted a couple of "make-work" patches to the QPSMTPD SMTP proxy - just tidying up a minor cosmetic issues. I'm starting to get to the point where I understand the internals pretty well now, which is a good thing! I love working on QPSMTPD. It rocks. It is basically the core of my antispam service and a real delight to code for. I cannot overemphasise that enough - some projects are just so obviously coded properly. Hard to replicate, easy to recognise... I've been working on my own pre-connection system which is a little more specialied; making use of the Class::Pluggable library - packaged for Debian by Sarah. (The world -> Pre-Connection/Load-Balancing Proxy -> QPSMTPD -> Exim4. No fragility there then ;) Finally I made a tweak to the Debian Planet configuration. If you have Javascript disabled you'll no longer see the "Show Author"/"Hide Author" links. This is great for people who use Lynx, Links, or other minimal browsers. TODO:

I'm still waiting for the creation of the javascript project to be setup so that I can work on importing my jQuery package. I still need to sit down and work through the Apache2 bugs I identified as being simple to fix. I've got it building from SVN now though; so progress is being made! Finally this weekend I need to sit down and find the time to answer Steve's "Team Questionnaire". Leave it any longer and it'll never get answered. Sigh.

ObQuote: Shooting Fish

I’ve got a new toy yesterday - a Nokia N95 8GB. It’s a nice little gadget (for a fucking insane price, but the contract makes it less painful) and the first mobile phone I own that I got combined with a contract for two years. Now, I do hate phone calls, but still, my old mobile got more and more broken, so I did need a replacement. I guess the old device didn’t like falling down on the floor multiple times. And when looking at my mobile phone costs for the last year (using prepaid stuff only), well, the contract isn’t more expensive in total (some 9EUR / month now). This N95 thing is something crazy - it has more features built in than all my previous mobile phones had together. It also has a better camera than my one dedicated camera device. The only part where it loses is the included audio player - but just because my real player has 5 times the storage size, runs rockbox and is able to play for about 35hours in a row. One “fun” thing is - I got the phone together with the contract from a reseller of some reseller of some big fat company (very weird sub-company thing of the resellers, as far as I understood it. Not that I care too much). Getting it directly from that company would have meant to pay more than 200EUR more, for less value! Thats just insane. Anyway, enough. I’ve sent my new number (didn’t want to port my old one this time, for various reasons), to those people in my addressbook that I think should have it. If you think you need it too and didn’t get a message - ask me. (And my old number will continue to work for some month anyways, I just wont look at it that often. Joys of prepaid cards and their lifetime). (And to those who went like *WTF is that J rg guy messaging me?” - its me! :) ) Comments: 1

I’m getting more and more annoyed by web sites that have style-sheets with tiny little fonts and widths specified in pixels rather than percentages (or ‘em’ units). Almost every web site i visit these days seems to have a style sheet written by some idiot who thinks “if it looks good on my screen using my eyes then it’s perfect for everyone”. WRONG Specifying widths in pixels is NOT for text. It’s for images, you morons. For one thing, small fonts suck if you have a large, high-resolution monitor. or if you have bad eyesight. or if you’re getting older (I was helping my mother find a house to buy a few days ago and the real-estate web site we were searching was basically unreadable for her - she could see the house pictures but I had to read out the text, and even I found that difficult because of the tiny font). For another thing, if you have a wide-screen monitor and a browser window to suit it, then a fixed-width column of 560 pixels or so looks really bloody stupid in the middle of a huge expanse of empty white space, even with another column or two at the sides for meta-stuff. There are tools, like the Stylish and NoSquint plugins for Firefox/Iceweasel that help you make a site more readable, regardless of what the so-called “designer” perpetrated. But, cool as those tools are, they just should not be necessary. And I, as a user of the web site, shouldn’t have to spend 5, 10, 20, or more minutes reading and understanding their style sheet so i can hack up a tweak for it JUST TO MAKE IT READABLE. They’re the designers, that’s their job, not mine. That’s what they’re (presumably) getting paid for - and yes, the commercial/professional web sites tend to be far worse offenders than the amateur sites. Web designers should have enough bloody sense to make their sites look good in ANY font size, at ANY window width. It’s not hard. In fact, it’s easier and much less work than hard-coding pixel sizes. I’m not a web designer, nor am I anything remotely like an expert in CSS or style sheets. I’m a systems geek. But if I can figure this stuff out, when it’s not even my job to do so and i have no intrinsic interest in the subject, then why the hell can’t they? Don’t they take pride in their work? Don’t they care that visitors to their web sites will think they’re clueless morons for perpetrating yet another squint-eyed monstrosity on the web? Don’t their employers give a damn? To summarise:

1. text widths in style sheets should be specified in relative units such as percentage or ‘em’ units.
2. font sizes should be specified in ‘em’ units, if you must specify them at all.
3. all other non-image/embedded-media sizes should also be specified in ‘em’ units.

Doing those three simple things will ensure that your web site looks good to all visitors, no matter what size screen/window they have, and no matter what font-size they have to use to be able to read it. end-of-rant. PS: My own hacked-up theme/style-sheet for this blog is far from perfect….but I did take the time to make sure all the widths and font-sizes were relative. If there are any CSS bugs feel free to point them out and i’ll fix them ASAP…like I said, I’m far from an expert in CSS. Syndicated from Craig Sanders' Errata: Tech Notes and Miscellaneous Thoughts fixed-width style sheets suck

On one computer I am taking care of, I suddenly started getting:

$ ps2pdf fa_808.ps fa_808.pdf
/usr/bin/ps2pdfwr: line 45: exec: gs: not found

What's wrong?

$ ls /usr/bin/gs
ls: cannot access /usr/bin/gs: No such file or directory
$ wajig find-file /usr/bin/gs
ghostscript: /usr/bin/gs
$ wajig list ghostscript
ii  ghostscript                                             8.61.dfsg.1-1               The GPL Ghostscript PostScript/PDF interpret
ii  ghostscript-x                                           8.61.dfsg.1-1               The GPL Ghostscript PostScript/PDF interpret

That is really weird, the file /usr/bin/gs is simply missing, even though I have the ghostscript package installed. Ok, let's reinstall it:

$ wajig reinstall ghostscript
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libwine-capi libstdc++5 libopenal0a xgnokii libglut3 libcapi20-3
  libggi-target-x lib64gfortran2 libsvg1 lib64gomp1 libggi2 libgii1
  libgii1-target-x libxine1-gnome cups-pdf lib64objc2
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  akregator gs kaddressbook kaddressbook-plugins kalarm kandy kappfinder karm
  kate kcontrol kdebase-bin kdebase-data kdelibs-data kdelibs4c2a
  kdepim-kfile-plugins kdepim-kio-plugins kdepim-kresources kdepim-wizards
  kdesktop kghostview kicker kitchensync kleopatra kmplayer kmplayer-common
  kpersonalizer ksplash libarts1c2a libgnutls26 libgs8 libilmbase6 libkcal2b
  libkdepim1a libkleopatra1 libkmime2 libkonq4 libkpimidentities1 libktnef1
  libopenexr6
Suggested packages:
  kdeaddons-doc-html ntpdate ntp-simple perl-suid egroupware ffmpeg xawtv
  gnutls-bin
The following packages will be REMOVED:
  digikam kde-amusements kde-core kdeaddons kdebase kdebase-kio-plugins kdepim
  kmail kmailcvt kmplayer-plugin knights konq-plugins konqueror
  konqueror-nsplugins korn smb4k
The following NEW packages will be installed:
  gs libgnutls26 libilmbase6 libopenexr6
The following packages will be upgraded:
  akregator ghostscript kaddressbook kaddressbook-plugins kalarm kandy
  kappfinder karm kate kcontrol kdebase-bin kdebase-data kdelibs-data
  kdelibs4c2a kdepim-kfile-plugins kdepim-kio-plugins kdepim-kresources
  kdepim-wizards kdesktop kghostview kicker kitchensync kleopatra kmplayer
  kmplayer-common kpersonalizer ksplash libarts1c2a libgs8 libkcal2b
  libkdepim1a libkleopatra1 libkmime2 libkonq4 libkpimidentities1 libktnef1
36 upgraded, 4 newly installed, 16 to remove and 683 not upgraded.
Need to get 53.1MB of archives.
After this operation, 42.9MB disk space will be freed.
Do you want to continue [Y/n]? n
Abort.

Oops, unstable is broken at the moment. Ok, what now? Well, snapshot.debian.net comes to rescue again. Find "ghostcript", version "8.61.dfsg.1-1" and here we are:

$ wget http://snapshot.debian.net/archive/2008/03/02/debian/pool/main/g/ghostscript/ghostscript_8.61.dfsg.1-1_i386.deb
$ wajig install ./ghostscript_8.61.dfsg.1-1_i386.deb

And all is fine now:

$ ls /usr/bin/gs
/usr/bin/gs