Search Results: "ron"

7 August 2007

Andrew McMillan: Really Simple CalDAV Store - August 2007 Status

Having taken time out to go to the other side of the world to attend DebConf 7 in Edinburgh, and then after spending some time with my family, I have been somewhat distracted from things CalDAV for a wee while now. There are signs that I will be able to put a few more evenings and weekends into it in coming months. Current Status With the release of 0.8.0 I believe it is quite a usable application for shared group calendars. We use it at Catalyst for about 80 staff and, while we're not heavy calendar users, it manages without any noticeable performance problems. There have been an impressive number of downloads from Sourceforge, as well as substantial downloads from my Debian repository, and I believe that the program is in tens, if not hundreds, of installations. Future Plans In the immediate future I want to get the basic framework for querying properties about the owner of a calendar or a set of calendars. This will be used by Mozilla soon during their configuration of a new CalDAV source, and I think that Apple iCal probably uses them already. This is partly done, but it's implementation has been slowed by the necessity to refactor the handling of the REPORT method in general to make the code more modular and readable, and to support queries and properties in a more general manner. The refactoring of the REPORT method handling is in place now, so moving on to the handling of DAV:principal objects should become fairly straightforward. I may end up with a fair bit of quiet, undistracted time over the coming weekend so if I can get in the 'zone', it may get done, and we can start rolling towards a release 0.9. Release 0.9 will have a new name. One from the cast of thousands that have been submitted to me so far, or one that I will hastily think up in between, but the next released version will not be called RSCDS any longer. The main goals for further into the future are: Interoperability I think that RSCDS does fairly well on the interoperability front. Unfortunately I have no access to the preview of OS 10.5, with it's native CalDAV client (though I have been told that it works with RSCDS). Likewise, other commercial CalDAV clients aren't available to me for testing either, so I have concentrated my efforts on supporting the featureset used by the various free CalDAV clients. My initial work focused around supporting Evolution, in particular, but with the recent effort put in by the Mozilla Calendar team the primary interoperability challenge is to enhance RSCDS to support their areas of development. If I could see how the OS 10.5 client behaves, too, I believe that would help identify a few points to extend, as well as suggesting some future directions. The best place to review interoperability would probably be at the CalConnect Roundtable 10 but I think that without some sponsorship for airfares I probably won't be able to make that. Maybe next time. Specifications Compliance As I read, and reread, the CalDAV (and DAV, and HTTP, and ...) RFCs the compliance with the various specifications improves. Recently I have put a lot of work into the calendar-query report, in particular, which means it now supports querying against arbitrary properties much more comprehensively. This is important because some of the client software is starting to do arbitrary queries also, and it is inevitable that queries for the classification of events, or the percentage completion of todo items will become more common. And now I notice that there is a new version of DAV in RFC4918, though not too many changes as far as I can see. The intent of this release is mostly to clarify, and slightly to extend, primarily in order to improve client interoperability. Coverage of Related Specifications In terms of general calendaring activities, the biggest hole in the CalDAV specification at present is standardisation around the location of other people's schedules. The current draft of the Scheduling Extensions to CalDAV appears to address that, and a lot more besides. I expect to start working on parts of this at some point, but perhaps not sooner than I see a client which starts using it, or when it is ratified, whichever occurs soonest. Documentation The documentation is OK. The wiki, in particular, is a reasonable resource for resolving problems (I believe), but it would be good to have some documentation of other things. One area that could do with enhancement is some documentation of how to check out a copy of the code, and how to provide patches back to me. Even better if other people can maintain their own trees which I could pull patches from, since we're using a distributed version control system (Git) to start with. Configuration The administration interface for RSCDS is OK, but could do with a few improvements to make it more usable. Really there are not a lot of reasons to be in the administrative interface, so these improvements should be relatively few, and relatively easy. This would be a good area for someone interested in helping out to become involved, because it does not entail reading large reams of RFCs, or watching tcpdumps scroll past for the debugging. Installation One thing that I have done right, I believe, was to provide the software from the beginning in a packaged form to make the installation easier. Although the software is packaged for Debian, however, it has not yet been uploaded to the archive because I have been waiting for the webapps-common package to enter Debian so I can use that for configuration. I think I have waited long enough though, so I will upload the next version to Debian for use by a wider audience. Security Security has always been a focus for me and I have had the code reviewed for any obvious security flaws. If any particular vulnerabilities are found they will be addressed with appropriate haste. Retrospective I've been working on this for a little over a year now, and I think I have largely met my goals for the project. It has certainly been an educational experience for me, and the effect of this work on other projects that I also participate in has also been valuable. Any new open-source project is always at risk of the developer losing energy and interest, but I believe this one has made it to a state where the bulk of the infrastructure effort has been done, and there are enough interesting challenges in the future to continue to keep me (at least) working on it into the future. The scope of this project is good, in that it is not at risk of expanding to take over the world. The intention behind this is simply to provide a back-end service for client software which should be very much Someone Else's Problem. In reality there have been times when I have had to get to grips with some of that client software in order to resolve problems, but those have by and large been good experiences.

Cameron Dale: DebTorrent Release 0.1.3 (in package form!)

Today I have released the next version of DebTorrent. This is the first release to be available in a binary package (.deb) form, and most of the changes are related to the packaging I still consider the program to be alpha quality, though all the functionality for a beta release is there, it just needs to be tested (so tell your friends). I run the program daily and use it for my apt-based updating, so I'm pretty sure it works, but there are definitely bugs. If you do find one please submit it to the DebTorrent mailing list. The installable binary can be found on the Alioth project, or in my personal repository which can be added to your sources.list like so:
deb http://debian.camrdale.org/ unstable main contrib non-free
Once installed, it will start running automatically, and will restart on bootup, so all that is needed is to modify your sources.list files to point them at DebTorrent by prepending localhost:9988 to the mirror name. For example, the entry above for my personal repository would become:
deb http://localhost:9988/debian.camrdale.org/ unstable main contrib non-free
Here's the changelog:

6 August 2007

Michal Čihař: Antal - horrible experiences

This time my experience is fresh and horrible. We went after work for some beers to restaurace Antal. Service was really slow and we waited long time till we could order our five beers. When they arrived, there were quite empty to call them half liter of beer. No matter what we drunk them and ordered another one, this time asking for full beer. Well it didn't arrive and our complain followed. Waiter seemed to be surprised that guest dares to complain and looked very angry. However after some minutes we got full beer. All of us agreed that it was filled with water. This time we found phone number to owner and called there. Owner was at the bar and ensured us, that there was no water in our beers. We still resisted as we had ordered food. For most of us it arrived, only my colleague didn't get his one. But after several urgencies, it arrived and by accident he had some paper in it. However we were still strong and resisted and ordered another beer. This time it seemed to be okay. Last surprise came when we payed as waiter calculated somehow two more beers than we have. Simply avoid this place if you can. Looking at other experiences (in Czech only), we're not alone who has such feeling about this pub.

Martin F. Krafft: Sending email via IMAP (or not?)

I am playing with the thought of using IMAP to send email from my mobile clients. The way this works is that mail is actually placed into a Maildir locally and synchronised with the IMAP server using a tool such as offlineimap. The Courier IMAP server supports such an outbox feature, for other servers you can use inotify or a cron job (I am planning to publish a writeup about my new mail setup sometime soon, so no scripts linked here yet). Anyway, it's trivial to get it working, and Dann Frazier has written it all up. The question is more whether I want to, or not. I am soliciting feedback. The advantages of using an IMAP-synchronised outbox are: Any solution with advantages comes with disadvantages, and these are: Can you think of any other advantages or disadvantages? Do you use an IMAP-synchronised outbox and would like to share your experiences with me? Or do you have yet another solution? Write to me! NP: OSI: Free

Kai Hendry: Digital Signage that does not crash

How many times have we seen something like: Digital signage done wrong Far too many times! I believe Windows isn’t stable enough for Digital Signage. Enter the Webcfullscreen mode option: Webconverger Fullscreen Ok, this photo slideshow example is done with Adobe Flash, however I think Flash is a suitable option and it can perhaps behave better if the connection goes down temporarily (the offline problem). Could try complex betaware like Google gears... Or customers might want a proxy feature (squid), which can be customised, so that if the Internet drops, the Digital sign could still work. Another avenue is to host user’s Web pages on a local Web server. I am not keen on this as local data would be against Webc’s design. If any of you have your own Digital Signage ‘solutions’ you would like to share, please do. Webconverger is a Free software project based on Debian. In other news Webconverger has an entry over at distrowatch. Excellent news and thanks for all your support.

Eddy Petrișor: nslu2, the kernel...

Update: it didn't work .... :((

eddy@ritter ~ $ grep '##### kern' -A 2000 /var/log/syslog grep -E '(reset ####)'
Aug 6 11:19:00 ritter manual message: ##### kernel was changed to linux-image-2.6.18-4-ixp4xx_2.6.18.dfsg.1-12etch2.1_arm.deb #####
Aug 6 11:23:08 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:35:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:52:41 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 6 11:54:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2



I cross built this:

Changes:
linux-2.6 (2.6.18.dfsg.1-12etch2.1) stable; urgency=low
.
* Non-maintainer upload.
* ixp4xx kernel:
Disabled options:
- USB_EHCI_SPLIT_ISO
- USB_EHCI_ROOT_HUB_IT
Enabled options:
- USB_BANDWITH

And it took me on my amd64:

real 105m0.331s
user 79m43.423s
sys 12m46.324s

Is not an upload, is just my try to fix this issue. Let's see if it works.

Oh, thanks to Riku for pointing out that cross building the kernel is trivial.

Uwe Hermann: Rebuilding the whole Debian archive using the Open64 compiler

I got bored recently, so I rebuilt the whole Debian archive on one of my machines. To make this not a completely useless excercise, I used the Open64 compiler instead of gcc and created build logs for your perusal. So what is Open64? From the Wikipedia page:
Open64 is an open source, state-of-art, optimizing compiler for the Intel IA-64 (Itanium), AMD Opteron and Intel IA-32e architecture. It derives from the SGI compilers for the MIPS R10000 processor. It was released under the GPL in 2000, and now mostly serves as a research platform for compiler and computer architecture research groups. Open64 is licensed under the GPL. Open64 supports Fortran 77/95 and C/C++, as well as the shared memory programming model OpenMP. It can conduct high-quality interprocedural analysis, data flow analysis, data dependence analysis and array region analysis.
Open64 installation The installation is pretty easy fortunately:
$ wget http://ovh.dl.sourceforge.net/sourceforge/open64/open64-4.0-src.tar.bz2
$ tar xfvj open64-4.0-src.tar.bz2
$ cd open64-4.0
$ export TOOLROOT=/opt/open64
$ make
$ make install (as root)
I think you need gcc-3.4 (gcc 4.x is not yet supported), and for some odd reason you also need csh as one of the install scripts seems to use it. It would be nice if someone could package Open64 for Debian, I definately don't have the time to maintain such a huge package (a whole maintainer team would probably be good here). Rebuilding the Debian archive There are several possible ways (and tools) to rebuild the Debian archive; I've used pbuilder/cowbuilder with the rebuild scripts from Bastian Venthur, which are now included in pbuilder. First we need to install the required packages, setup a cowbuilder base chroot, and get the list of packages:
$ apt-get install cowdancer grep-dctrl wget devscripts sudo
$ cowbuilder --create --distribution lenny --basepath /var/cache/pbuilder/testing-base.cow
$ cp -r /usr/share/doc/pbuilder/examples/rebuild .
$ cd rebuild
$ ./getlist lenny
Now we add Open64 into the cowbuilder chroot and fix up the chroot by pointing the gcc/g++ symlinks to Open64:
$ cp -a /opt/open64 /var/cache/pbuilder/testing-base.cow/opt
$ chroot /var/cache/pbuilder/testing-base.cow
$ cd /usr/bin
$ mv gcc gcc.orig
$ ln -s /opt/open64/bin/opencc gcc
$ mv g++ g++.orig
$ ln -s /opt/open64/bin/openCC g++
$ exit
In addition, we set the CC and CXX environment variables to Open64, which will make 90% of all (autoconf-using) packages automatically use Open64. We need a small script for that:
$ cat c.cfg:
export CC="/opt/open64/bin/opencc -m32"
export CXX="/opt/open64/bin/openCC -m32"
Now edit the buildall script. Change the Debian mirror used there (optional) and make it use our c.cfg script by adding the --configfile /path/to/rebuild/c.cfg option in the "pdebuild" line. We can now finally start building the archive:
./buildall list.lenny.i386 lenny
You can also run multiple buildall instances at once to speed up the archive rebuild on SMP/multicore machines, and you can even abort the command and simply restart it later. The script will continue where it left off. Results The whole rebuild (with 2 instances of buildall running at the same time) took ca. 9 days on an AMD64 Athlon64 X2 (dual core, 1.8 GHz each) machine with 1 GB of RAM. I really should have used something like apt-proxy to speed up the rebuild and save some bandwidth, but I read about apt-proxy too late... All log files from my rebuild are available for detailed analysis if anybody is interested (you can browse the logfiles online or download all of them as tarball). I didn't perform any detailed analysis, just some rough numbers here: If anybody does some more elaborate analysis, please let me know.

5 August 2007

Russell Coker: Real Servers vs White-Box

Many people think that white-box machines (IE the cheapest no-nam PCs you can buy) are suitable for use as servers. There are several factors that make white-box machines totally unsuitable for use as a server (and IMHO unsuitable for any other task). Firstly white-box machines are not designed. A set of parts are designed, some combinations of parts are tested, but most aren’t. For example a motherboard manufacturer will test their latest motherboard design with the current video cards and a video card manufacturer will test their new cardss with current motherboards. If you have a new video card and a new motherboard then there has probably been little testing of the combination. This compares to a name-brand machine where the entire unit has been tested and found to work together. White-box assemblers (they aren’t “designed” or “manufactured”) will often use different combinations of parts for each machine that they assemble. If a video card manufacturer sells two cards with the same part number that have different chips then they may be installed in two machines with the same description. So taking an image of one white-box machine and installing it on another that was described as being identical might not work. For these reasons I have ceased using white-box machines as desktop machines or as low-end servers (EG internet gateway machines). I use second-hand name-brand machines for low end servers and for desktop machines. When comparing servers the case for name-brand systems is even stronger. Real servers have ECC RAM as a standard feature, it is possible to get white-box servers with ECC RAM - I have seen such a machine on one occasion. But the vast majority of white-box machines lack such features. See my previous posts about getting ECC RAM in a cheap machine and desktop machines with ECC RAM about some of the issues in this regard. Another feature of servers is better storage options. There are white-box server machines with hot-swap hard drives, but they are significantly more expensive than regular white-box machines - if you are going to spend that much money then it’s better to get a refurbished HP server machine at auction (HP seems to be selling a lot of almost-new server gear at auction at quite reasonable prices with warrantee). A cheap machine (typical white-box or a very low end server from a company such as HP) will have hard drives that don’t support hot-swap. Lack of hot-swap means that a hard drive failure requires that the machine be disassembled to swap the dead disk - it also means that there is sometimes difficulty in identifying which disk has the problem (the error light on a hot-swap drive is quite handy). Then the process of swapping the disk will take at least 10 minutes of hardware work before the machine can be booted up again. With hot-swap disks you can identify the failed disk via a flashing light, remove it while the server is still running, and then initiate a RAID rebuild after installing the new disk. Hot-swap disks cost more and the mounting brackets etc are also expensive, but it’s a good option to have - especially considering that disks are more likely to fail at busy times which is when down-time is least acceptable. These features make disk expansion particularly expensive for servers, people often miss the benefits of servers and say “I just bought a 3000G disk for my home PC for $2, why can’t you just do the same for the server” (I am exaggerating slightly). Another advantage of name-brand servers is remote access. There have been a variety of remote access cards that you could install in a white-box PC and also a variety of devices to digitise a VGA signal for remote KVM access, but they are all rather expensive and remove the price advantage of white-box hardware. A final benefit of name-brand hardware is that you will be running the same hardware as other people. If I was to experience a problem running Linux on a HP DL380 G4 server then I can enter that text in to Google and get many hits. If I was to experience a similar problem with a white-box machine then I would need to perform searches on each of the parts that might have a problem - which would be particularly inconvenient if I couldn’t determine some of the part numbers through software and needed to disassemble the machine first!

4 August 2007

Edd Dumbill: Zonbu: an intersection of open source, Web 2.0 and energy efficiency

Salon.com recently reviewed Zonbu, a highly compact general-purpose computer with no moving parts. Zonbu's key features are its incredibly low power consumption, network-connected storage and that it works right out of the box without any installation. Under the covers, it's a Gentoo Linux installation with mainstream open source apps such as OpenOffice and Firefox.

Zonbu skins
Zonbu and its skins — high-powered dressing for a low-power device Price-wise, you can get the Zonbu for as little as $99 if you commit to two years' subscription to the network storage. Understanding the open source ethos, Zonbu also offer the box without any tether for $250. As with the Mac mini, supplying the keyboard, mouse and monitor is up to you. Preloaded with an office suite, email, IM, web browser, multimedia player, games and Skype, Zonbu is aimed at being a general computing appliance. You can't install anything else on it, but then again, that way you can't break it easily either. It sounds the sort of thing I'd be happy leaving with non-technical family and friends. Storage with Amazon S3 Low-power solid state devices are nothing new of course, there are a variety available, and things such as the NSLU2 have been in production for some years. The novel thing about the Zonbu however is in how it manages its storage. The Zonbu has 4GB of compact flash storage on board, which it uses as a cache for Amazon's S3 storage network. All your files get encrypted and sent to S3, and are retrieved when you need them. One really neat consequence of this is that you can get at your data via the web any time you want. Secondly, it gives me some sense of security for my data. I don't know if Zonbu will give me the 'keys' to my data on S3, but it wouldn't be hard for them to provide an easy way to migrate out. Either way, S3 is a place I'd trust with my data. Why Zonbu is important Windows, and to some extent, Mac OS X, are becoming the needy children of computing, always tugging on your arm and asking you something. In contrast, Zonbu looks like a great step towards "appliance computing". Its features are more like those you'd expect from your phone or cable TV provider:

Zonbu has the potential to change domestic computing. The low price point lowers the barrier to computer ownership. Low maintenance needs lower the technical barrier to entry and use. And Zonbu's a green and economical technology, yet as useful as the full power version. As a company, I feel Zonbu to be a well-intentioned player because of their strong support for open source, and the ease with which you can get at your data despite its appliance nature. I hope they continue to develop in this open data direction. Zonbu itself probably won't attain ubiquity, but it will change the marketplace and open up a new category of network-connected appliances for the home. Further reading

Matthew Garrett

Anyway, back to pure Linux stuff. A while ago, the Ubuntu Technical Board were asked to take a look at Automatix. I've finally got around to doing so, and here are my initial conclusions. I'd appreciate any factual corrections, and note that at this point this is my individual opinion rather than any sort of official statement.

Automatix is a combination system configuration/package installation
tool, aimed at making it easy for users to install features like
graphics drivers, media codecs and software not distributed as part of
the Ubuntu distribution. It is provided as a .deb file containing a
python GUI frontend that calls out to a shell backend. The frontend
parses an XML file which contains module descriptions and function
names for installing and uninstalling modules, with these functions
being part of the shell backend. An install module will typically
check whether another package manager is running, and if not either
install a set of debs or download and manually install a
tarball. Uninstall modules generally remove the same software or clean
up the manually installed files.

The following is a list of identified issues with the current version
of Automatix - it is the result of a few hours of investigation, so
may not be complete.
Conclusion:

Automatix exists to satisfy a genuine need, and further work should be
carried out to determine whether these user requirements can be
satisfied within the distribution as a whole. However, in its current
form Automatix is actively dangerous to systems - ranging from damage
to small items of user configuration, through removing user-installed
packages without adequate prompting or warning and up to the (small
but existing) potential to leave a system in an unbootable state.

The current design of Automatix precludes any reasonable way to fix
some of these problems. It is attempting to fulfil the role of a
high-level package manager without actually handling any sort of
dependency resolution itself.

A more reasonable method of integrating Automatix's functionality into
Ubuntu would be for the Automatix team to provide deb files to act as
installers for the software currently provided. These could then be
installed through the existing package manager interfaces. This would
solve many of the above problems while still providing the same level
of functionality.

In its current form Automatix is unsupportable, and a mechanism for
flagging bugs from machines with Automatix installed may provide a
valuable aid for determining whether issues are due to supported
distribution packages or third party software installers.

3 August 2007

Eddy Petrișor: more news from the nslu2 front

The main reason for the lack of activity during this week was that I had some problems with my router, a NSLU2 running the debian arm port. This was the machine I wanted the softfloat rrdtool I was talking about in these 2 posts.

It turns out that for some weird reason the USB controller of the slug resets when there is too much traffic going on. I got lots and lots of messages like:


$ grep reset -A 1 /var/log/syslog grep -E '(reset repeated)'
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
...
Aug 3 11:50:29 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:51:03 ritter last message repeated 4 times
Aug 3 11:53:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:53:46 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:55:48 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:07 ritter last message repeated 2 times
Aug 3 11:56:52 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:57 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2



That wouldn't have been a problem as long as the damn thing worked, but in some cases after the reset the root filesystem was lost and all the services running on the machine died (except the networking itself since all of that is part of the kernel and is loaded in memory).

It took me about three evenings to get to this conclusion (imagine being locked out of a machine which advertised running ssh, http, and dns services, being able to telnet and getting a respons, but the full protocol failed).

It all became more clear when, while being connected via ssh I got his result:

eddy@ritter ~ $ ls
-bash: ls: command not found

"WHAT?" was the first reaction, then I figured that life without ls is unbearable and came up with this bit:

alias ls='for I in * ; do echo $I ; done'

Quite cool to understand a little bit about the system. Still, cat was unavailable so having /proc and /sys available did not help that much. At some point I was thinking about a busybox shell, tried that, it didn't work since it wanted to remove some important bits like the initramfs tools.


I googled again and found a good starting point for a discussion of the same problem someone else was having. I ended up trying all the proposed solutions: rmmod-ing ehci-hcd, blacklisting the module, regenerating a initrd image with the blacklisted module... None of these worked (individually) and I ended up having an even more unstable system when ehci was not present (I was loosing the root FS after aprox. 1 min after logging in remotely immediately after start). Restoring the image with ehci was a pain (not to mention the time spent trying to figure a way to revert the change safely, since bricking the machine was not out of the question - imagine loosing the FS while flashing the ram drive image).

I finally managed to revert the ehci enabled image and tried the workaround proposed in this gentoo BR. I tried 128 and now I am at 64 and I am still getting those resets; Still something good came out of this, I followed Michael Prokop's Use root=UUID on NSLU2 article and I think I have now a stable root file system just thanks to him.

Now I am stuck:


grep -E '(max_sect reset)' /var/log/syslog
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:27:38 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:38:43 ritter manual message: max_sectors was set to 128
Aug 3 08:55:25 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:31:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:54:11 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:09:32 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:15:27 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:24:24 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:38:12 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:47:04 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 10:48:27 ritter set_max_sectors: sda's max_sectors was set to 64
Aug 3 11:04:36 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:06:16 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
....
Aug 3 15:05:58 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2

Should I try setting to 32?

In case you're wondering, I am doing the setting with this script:

#!/bin/sh

MAX_SECTORS=64
DISK=$(ls -l grep 'uuid.* / ' /etc/fstab awk ' print $1; ' sed 's#.*/\(.*\)$#\1#' tr -d '[0-9]')

[ -z "$DISK" ] && logger -t 'set_max_sectors' "error: could not detect root disk" && exit

echo "$MAX_SECTORS" > /sys/block/$DISK/device/max_sectors
logger -t 'set_max_sectors' "$ DISK 's max_sectors was set to $ MAX_SECTORS "

exit 0


Dear (not at all) lazy web, what can I do to fix/workaround this issue? Any help would be gratly appreciated (personal mail or comments).

Note: I am reluctant to try the fix proposed in the last comment that claims to fix the issue since compiling an arm kernel natively is a pain and I would like to have an official kernel from Debian Etch, as I do now.

Julien Blache: PowerTOP: demystifying Intel s latest marketing coup

A couple of weeks ago, Intel has released the PowerTOP utility for Linux, a tool similar to the well known top(1) utility that can help you understand why your laptop battery runtime is as low as 1 hour. You need a tickless kernel (2.6.21 at least on i386, 2.6.22 + hrt patchset on amd64) for that to work, and timer statistics must be enabled. This is an extremely bright marketing coup from Intel, for essentially two reasons: In that, PowerTOP is an incredible PR spinning tool that can shift the blame away from the Intel CPU in your machine to about everything else in your machine - including software! They’ve done extensive and intensive internal testing, which turned up some bugs and misbehaviours here and there, which is truly great. They’re also announcing incredibly low “CPU wakeups per second” values, so low that there is no way you can reach such low values on any kind of real world setup. These numbers must be seen in the context of lab testing on otherwise idle machines. On the “CPU wakeups per second” front, you’ll most probably see that the #1 offender is your UHCI USB controller. A UHCI USB controller produces a thousand interrupts per second, effectively waking up the CPU a thousand times per second even when nothing happens. So, now it’s all the USB controller’s fault! Ah, wait, UHCI is an Intel spec! (UHCI is a joint effort by Intel and others, Intel being the lead) Fortunately, to be able to put the USB host controller to sleep, you need to put all the USB devices attached to it to sleep too. Here comes the (in)famous CONFIG_USB_SUSPEND kernel option introduced six or so months ago, the one that makes (made, I’ve worked around it in SANE last week-end) your scanner produce only “black scans” and prevents your printer from working properly. So now it’s all the USB devices’ fault. Brilliant, isn’t it ? To be honest and complete, once again, CONFIG_USB_SUSPEND exposed a lot of hardware bugs. The USB spec is probably one of the most violated spec these days (together with ACPI I’d say, though it looks like this one is improving lately). Please don’t get me wrong: PowerTOP is a very useful tool that has its uses, the tickless kernel is of course a very important feature, and CONFIG_USB_SUSPEND would be the icing on the cake if USB devices weren’t so ignorant of the spec. But the Intel marketing crap behind that really needs to stop. Produce better chips which consume less power, period. My PowerBook G4 could run 4h30 on battery (a machine designed 7 years ago). My Core2 Duo MacBook Pro, with a slightly bigger battery, can only run 1h40 with the same software and workload, with cpufreq enabled etc, etc. Granted, the ATI video card is a big sucker here too. (I wrote this entry to share my thoughts on the matter, as a reaction to the many mails I’m getting about PowerTOP and the MacBooks, so as to have a reference to point people to, instead of rewriting the same things again and again.)

Andrew McMillan: IPv6 Burninating all the Peasants

A recent thread which started on the Debian Release mailing list caught my eye this week. I attempted to aid the migration of this thread to the debian-ipv6 mailing list, which is really a better place for this and sorely in need of controversial topics for discussion. It is interesting how people can so blindly decide that broken things should be destroyed. Repair often appears not to be an option, even for a long-term, wide-reaching effort like this, though we are all working on open-source software! In this case there are an unknown number of less fortunate people in the world who are located behind some kinds of broken DNS infrastructure which discards 'AAAA' lookups. Of course 'AAAA' lookups are attempts to resolve a name to an IPv6 address, and the resolver in a 'modern' libc (i.e. one from the last five years or so :-) will try to retrieve an IPv6 address before it attempts to resolve a name as IPv4 with an 'A' lookup. That is how the standard is written, so if you want to comply with the standard you have to do it that way. Other things also interfere, but this element of the specified behaviour seems to cause the most annoying and pointless whingeing I have heard. I suppose that the people who want working IPv6 make it so, and do not have problems with this behaviour. But it seems that people who are behind this kind of broken DNS either disable IPv6, or they have to whine about IPv6 being turned on by default, and can't we please all go back to the good old days. What's wrong with IPv4 anyway? Doesn't NAT solve all of it's problems? Are we sure this new (heh!) technology is safe? Fortunately some people are so good at making their pain felt by other people that they can get other people to do their work for them. So Mithrandir has written a nice elegant patch for libc6 so that it won't do the IPv6 lookups unless you have a usable IPv6 configuration. I've filed bug #435646 against Debian to get this included, but Aurelian Jarno justifiably wants a few people to test it a bit harder... So I've taken the original patch and tweaked it to apply against current libc6 sources (2.6-5) and tested it for myself. It works as desired, as far as I can see, when comparing behaviour with an unpatched system. The patch is attached to the bug report, of course. Perhaps some other people out there can put a wee bit of CPU into testing this for other environments so that we can make life easier for those people with no time / inclination to use IPv6, to ensure that they don't just disable it because it is making life too painful for them in it's current form? How to build libc6 for fun and proft If you have appropriate deb-src URLs configured, and are running Sid, then the following will let you build a local copy of libc6 with the patch. This is probably better testing than if I just make my packages available (which are only i386 in any case).
apt-get build-dep glibc
apt-get source glibc
cd glibc-2.6
debian/rules unpack
cd build-tree/glibc-2.6
wget http://tinyurl.com/3xzm3o
patch -p0 <glibc-only-lookup-ipv6-if-it-makes-sense-debian.patch
cd -
dch --newversion 2.6-5+v6 "Apply IPv6 Resolver Sanity"
fakeroot debian/rules binary
Wait a few hours for it to build... Install... And then confirm that this only does 'AAAA' lookups if (when) you actually have a global or site scoped IPv6 address. When you only have a loopback or link local IPv6 address then you should only see 'A' record lookups. Step 3: profit! Whoops! I forgot the fun bit: please update the bug report :-) What the patch does In my opinion this is quite an elegant solution from Tolleff. He has picked a single characteristic of the IPv6 interfaces to further refine whether the IPv6 configuration of some interface is actually usable. With IPv6 it is much more common to have multiple addresses assigned to a single interface. Interfaces are automatically configured with a link-local address which is not globally routable, and the loopback interface is also configured with the IPv6 equivalent of 127.0.0.1 (which is "::1"). To get a usable IPv6 setup you will also end up with a more widely usable address. In most cases this will be a global address, meaning that it is (in theory) globally routable from other people who also have global addresses, or you could have a "site" address, which is the IPv6 equivalent of RFC1918 addressing. The patch considers that for the purposes of name resolution, it will be pointless to do AAAA lookups unless you have an address of the second kind. This means that people behind broken DNS won't be impacted unless the try and set up IPv6, and people who don't try and set up IPv6 won't get the 'hesitation' while their system attempts to resolve each address in IPv6 space first. It will also mean that when people start to enable IPv6 around them, their setup will continue to work correctly.

Evan Prodromou: 15 Thermidor CCXV

It's been a few days since I posted on my blog -- since I left Montreal for Taipei and Wikimania 2007. My time has been upside-down and backwards as I've traveled around to the other side of the clock and a day into the future, and I've just been insanely busy with other work. My flight to Taipei was dreamy. I travelled enough last year to get Air Canada's "silver" frequent-flier level, which earned me a couple of system-wide upgrade certificates. They came in handy, since I bumped up to business class on the leg between Montreal and Vancouver, and then to the "Premier Laurel" class on the EVA Air codeshare between Vancouver and Taipei. That was first class across the Pacific Ocean, and man, it's the only way to fly. Jimmy Wales was on the same plane (but back in business class...), so we got to chat a bit and we shared a taxi to the conference site. Jimmy's really fun to talk to -- it's always nice talking to another entrepreneur who's passionately dedicated to Free and Open Content. (We were in line for customs together, too, and I tried to peek at his passport to find out his date of birth, over which there is some confusion. But he had his thumb over the day (intentionally...?), and all I got was "Aug 1966", which everyone agrees on anyways. Dang! My personal theory is that Jimmy was born on 6 June 1966 and uses 8 Aug 1966 instead to avoid the demonic stigma.) The conference centre we're in is great -- a really big, clean, modern place. It's nice when we're inside, but Taipei in August is muggy and hot like a laundromat in rural Mississippi. I find myself rushing between buildings. tags:

IM IN TAIPEI HACKING UR DAYS I came in a couple of days early to participate in the Hacking Days event. This is a pre-conference meetup for MediaWiki developers and those who love them. The meetup was really unstructured and fun because of it, although there were a few points of uncomfortable silence when people stopped talking and we all realized we had 14 more hours of meetings and not much left to say. There's also a real tension between the conference organizers, who've encouraged non-developers to come to Hacking Days, and the core developers who really want to just be left alone and get some work done. This year the 2-day event was split into "Hacking Days" and "Hacking Days Extra", with the first being invite-only and the second being open to all. I think it's a tension that needs to be resolved -- if outsiders aren't invited to Hacking Days, we just need to say that and live with it. We shouldn't let people think they're going to participate and then cut them out. That's a bait-and-switch tactic and it's unfair. I think that there's a need for an open-attendance MediaWiki conference; I also think that MW is a big enough piece of software that third-party conference organizers would be eager to make an MWCon work. And core developers could get hefty fees for coming to talk! tags:

Announcements I've been having problems sleeping here. I've been falling asleep at the wrong times and waking up at the very wrong time. Last night, I missed the Wikitravel Eat-together because I fell asleep at dinner time and didn't get up for the event. Make mental note: don't miss your favorite wiki's user get-together! Fortunately Jani covered for me and apparently the event was a lot of fun. Speaking of Jani: this morning he announced a new venture that Maj and I have been helping him with. Wikitravel Press is an independent company that will be publishing a line of printed travel guidebooks (yes, paper books! That you can hold in your hand!) based on Wikitravel content. I think it's a great project and I'm really glad we're going to finally be fulfilling this important goal of the Wikitravel project. I also think it's going to be a great way to attract a new round of contributors -- people who are more reliant on their paper guidebooks than to a search engine for learning about their destinations. I think that the idea that they can change and improve the books they have will be a really important incentive for these folks. And like it or not, there are still a lot of people who don't consider digital information "real" in the same way as analog-stored info. So putting Wikitravel guides on paper is like Pinocchio becoming a Real Boy. Thank you, Blue Fairy! More info at the project's announcement and the on-site discussion (Wikitravel:3 August 2007). tags:

Called out This morning's keynote address by the Wikimedia Foundation chairwoman Florence Devouard was informative and interesting. She even talked about ways to bring money into the Foundation... including selling books based on the site content. I was giggling about this with Jani as she moved on to talking about the attention economy, to hear, "For example, Evan is not paying attention right now and talking to his neighbour." D'oh! Lesson learned: don't mess with User:Anthere! tags:

2 August 2007

Russell Coker: Starting a Heartbeat Resource Without Heartbeat

The command crm_resource allows you to do basic editing of resources in the Heartbeat configuration database. But sometimes you need to do different things and the tool xmlstarlet is a good option. The below script can be used for testing Heartbeat OCF resource scripts. It uses the Heartbeat management program cibadmin to get the XML configuration data and then uses xmlstarlet to process it. The sel option for xmlstarlet selects some data from an XML file, the -t -m options instruct it to match data from a template. The template is the /resources/primitive part. The --value-of expression will print the values of some labels from the XML. The script will concatenate the name and value tags and export them as environment variables (see my post about Configuring a Heartbeat Service for an explanation of the use of the variables). The TYPE variable is the name of the script under the /usr/lib/ocf/resource.d/heartbeat directory. In recent versions of Heartbeat (2.1.x) the OCF_ROOT environment variable must be set before an OCF script is called. Setting it on older versions of Heartbeat doesn’t do any harm so I unconditionally set it in this script (which should work for all 2.x.x versions of Heartbeat). The first parameter for the script is the id of the service to be operated on and the second parameter is the operation to perform (start, stop, and status are the only interesting values). The script will echo the exit code to the screen (0 means success, 7 means that the service is not running or the operation failed, and any other number means a serious error that will trigger a STONITH if Heartbeat gets it). #!/bin/sh
$(cibadmin -Q -o resources xmlstarlet sel -t -m \
"/resources/primitive [@id='$1']/instance_attributes/attributes/nvpair" \
--value-of "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $? Below is another version of the same script that instead uses crm_resource to get the XML data. The output of crm_resource has a couple of lines of non-XML data at the start (removed by the grep) and also only gives the XML tree related to the primitive in question (so the /resources part is removed from the xmlstarlet command-line). #!/bin/sh
$(crm_resource -r $1 -x grep -v ^[a-z] xmlstarlet sel -t -m \
  "/primitive/instance_attributes/attributes/nvpair" --value-of \
  "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $? The problem with both of those scripts is that they rely on Heartbeat being operational. Performing any operations other than a status check while Heartbeat is running is a risky thing to do. If Heartbeat starts a service at the same time as you start it via such a script then the results will probably be undesired. One situation where it is safe to run this is when a service fails to start. After it has failed repeatedly Heartbeat may stop trying to restart it (depending on the configuration) in which case it will be safe to try and start it. Also you can put in temporary constraints to stop the resource from running by repeatedly running crm_resource -M -r ID until all nodes have been prohibited from running it (make sure you run crm_resource -U -r ID afterwards to remove the temporary constraints). The following script does the same thing but directly reads the XML file for the Heartbeat configuration. This is designed to be used when Heartbeat is not running. For example you could copy the XML file from a running cluster to a test machine and then test your OCF resource scripts. #!/bin/sh
$(cat /var/lib/heartbeat/crm/cib.xml xmlstarlet sel -t -m \
  "/cib/configuration/resources/primitive [@id='$1']/instance_attributes/attributes/nvpair" \
  --value-of \
  "concat('export OCF_RESKEY_',@name,'=',@value,'&#010;','TYPE=',../../../@type,'&#010;')")
OCF_ROOT=/usr/lib/ocf /usr/lib/ocf/resource.d/heartbeat/$TYPE $2
echo $?

David Welton: Windows for Linux Users

After many months of few contributions, and lots of spam, I decided to shut down the Windows for Linux Users wiki, and transfer its contents to an article on my new personal web site: http://www.welton.it/articles/windows_for_linux_users.html I will still accept contributions, of course, but it's more efficient to simply apply them myself rather than sort through a lot of spam on a relatively static wiki. The content is based on my experiences with windows several years ago - I realized that I knew very little about using it productively, and so I attempted to share what I learned about turninig it into an environment I could be productive in. Since most people go from Windows to Linux, they're not likely to face those problems, but for those who do, some of the listed tips and tricks are useful. These days, I can happily report that I'm happily back to a windows-free life.

1 August 2007

Romain Francoise: Converting Debian packages from dpatch to quilt

I've been using quilt a lot at work recently (in a non-Debian environment), and I've been enjoying it very much. So much that I've decided to convert my Debian packages to it, from dpatch. Once you're used to quilt, using dpatch is almost literally painful. :)

There doesn't seem to be a ready-made guide on how to convert packages from dpatch to quilt, so here's how to do it painlessly in five easy steps:
  1. Install the quilt package (duh) and make sure that the QUILT_PATCHES variable is set to debian/patches in your shell environment. Or you can set it in your ~/.quiltrc file instead (see this post for other interesting settings).
  2. Delete the build dependency on dpatch from your debian/control file, replacing it with a dependency on quilt (>= 0.40).
  3. In your debian/rules file, include /usr/share/quilt/quilt.make instead of /usr/share/dpatch/dpatch.make.
  4. Convert all your dpatch files by using the following command from your package's top level:
    for p in $(dpatch list-all); do \
    quilt import -P $p.diff debian/patches/$p.dpatch; \
    quilt push; \
    done
  5. Delete dpatch files:
    rm -f debian/patches/00list debian/patches/*.dpatch
And that's pretty much it! You'll probably want to clean up the headers of your debian/patches/*.diff files since they'll still contain some dpatch markers. You can now build your package as usual. To edit a patch, use quilt push <patch>, quilt edit <file1> <file2>, finish with quilt refresh to save the patch.

For more information on how to use quilt, read the tutorial, it's in /usr/share/doc/quilt. You won't regret switching!

Ross Burton: Poky Linux 3.0 "Blinky" Released

After much blood, sweat and tears, Poky Linux 3.0 (also known as Blinky) is released. Poky is an OpenEmbedded derivative, focused on building GNOME Mobile-based images for embedded and handheld devices such as the Sharp Zaurus or the Nokia N800. Aside from the usual set of software updates and infrastructure improvements, Blinky contains the first public release of Sato, an example GTK+/Matchbox based PDA environment aimed at devices with high resolution, physically small screens. This includes a new Matchbox panel and desktop, the Pimlico suite of PIM applications, and a fast, clear GTK+ theme. Pretty much everyone at OpenedHand has been involved in Poky to some extent, so it's great to see a release. Personally I'm really pleased with how far Blinky has advanced over the last release, Clyde, and will shortly be working on a branch of Blinky to integrate the complete GNOME 2.20 release set. If anyone is interested in Poky then it is easy to try: there are for a several devices: the Nokia N800 and several Sharp Zaurus models; and Qemu images for both ARM and Intel. Give it a go and tell us what you think! NP: Love and Affection, Joan Armatrading

Ross Burton: Daily Mail vs British Medical Journal

From an article in the Daily Mail this week:
Previous studies have found that cannabis claims 30,000 lives a year by causing cancer, heart disease and bronchitis, and that it can double the risk of mental illnesses such as schizophrenia.
Now, I wonder where that data is from. Oh look, the British Medical Journal:
It may be argued that the extrapolation from small numbers of individual studies to potential large scale effects amounts to scaremongering. For example, one could calculate that if cigarettes cause an annual excess of 120 000 deaths among 13 million smokers, the corresponding figure for deaths among 3.2 million cannabis smokers would be 30 000, assuming equality of effect.
Genius. Thanks to Dr Ben Goldache for spotting this. NP: The Good, The Bad & The Queen, The Good, The Bad & The Queen

Russell Coker: ECC RAM in a Cheap Machine

In a comment on my previous post about ECC RAM someone commented that Dell sells PowerEdge desktop machines with ECC RAM. I visited the Dell web site and found that a low-end PowerEdge tower server (which still has a Pentium-D dual-core 64bit CPU) costs as little as $800AU. I also noticed that Dell Precision workstations that have ECC RAM - but that start at $2400. I wonder how much noise a low-end PowerEdge machine would produce. HP Workstations with model codes starting with xw also have ECC RAM and are advertised at $584US as the starting price (about the same as a low-end PowerEdge). I checked out NEC and Lenovo and according to their web sites they don’t make a desktop or desk-side machine that takes ECC RAM (someone please correct me if I’m wrong). So now I’m looking for cheap HP Workstations and Dell PowerEdge and Precision machines at auction.

Next.

Previous.