Today I reached another milestone in the development of upstart, the packages in universe can now replace the existing sysvinit package. Before trying this, make sure your installation is up to date as we’ve had to split out some parts of sysvinit into a new sysvutils package. If you’re up to date, and want to try it out, install the upstart and upstart-compat-sysv packages from universe. Note that the first reboot after you’ve installed the packages (from sysvinit to upstart) will be a little tricky … use reboot -f. If your system boots and shuts down normally, everything’s working just fine. Note that both will be somewhat more quiet than you’re used to, unless you have usplash running. Throughout the rest of this entry, I’ll try to answer some of the questions and comments that I’ve received since the last post. Events As I talked about previously, upstart is an event-based init daemon. Events are the primary force for having your services and tasks started and stopped at the appropriate time and in the appropriate order. So what are events and where do they come from? (Note that this part is under development, so may change in later releases). Events are just simple strings that may be sent by any process when something it is tracking the state of changes. They have no state or longevity, and if, when queued, they do not cause any job state changes, then they have no effect unless they are sent again. Jobs can list which events cause them to be started if they are not already running and which events cause them to be stopped if they are running. Multiple start and stop events may be listed, in which case the first to occur changes the job until the next one occurs. upstart itself generates the following system events:

• “startup”, on system boot.
• “shutdown”, when the system is about to be shut down.
• “stalled”, when there are no jobs running and no events in the queue.

The shutdown tool included in the package also causes one of the following events to be sent once the “shutdown” event has been handled:

• “reboot”,
• “halt”,
• “poweroff”,
• “maintenance” (aka. going into “single user” mode),
• any user-defined event with shutdown -e event.

Jobs also generate events whenever they change state, this is the primary source of events for ordering:

• “jobname/start”, when the job is first started.
• “jobname/started”, once the job is running.
• “jobname/stop”, when the job is first stopped.
• “jobname/stopped”, once the job has stopped.
• “jobname”, for services this is generated once it is running; for tasks this is generated once it has finished.

And as mentioned, any other process on the system may send events through the control socket or just by using initctl trigger EVENT. For now this is just the event string, however it’s intended that the event may include other details including environment variables and even file descriptors. Typical example To clarify how it all hangs together, here’s an example (using fictional names) of how the tasks and events can be arranged to provide race-free mounting of filesystems.

• “udev” service started on the “startup” event.
• udev daemon is configured to send a “new-block-device” event whenever a new block device is added to the system.
• “checkfs” task is started on the “new-block-device” event to check the filesystem.
• “mountfs” task is started when the “checkfs” task has finished and mounts the filesystem if listed in /etc/fstab
• “filesystem-mounted” event is generated whenever a filesystem is mounted.
• “fstab” task is started on the “filesystem-mounted” event, it checks the list of mounted filesystems against /etc/fstab and if all are mounted, generates the “writable-filesystem” event.
• other services and tasks would be started on the “writable-filesystem” event.

By breaking this job into these small tasks, we can see how the pieces fit together. Because everything is now done on events, there are no race conditions; we know that any filesystem listed in /etc/fstab will be checked and mounted. The only reason they wouldn’t be is if there’s an error of some kind, and that means you have larger problems anyway and the system administrator would have a shell to fix it. Of course, the moment they finish checking the filesystem and mount it, the boot process would carry on. There’s no reason that any of these events need to be generated by the upstart daemon itself, it can receive them from any other daemon on the system such as udev, acpid, etc. This keeps the focus of the init daemon narrow. A large part of the future development will be working out exactly what kinds of events we want init itself to generate, what kinds we want to come from elsewhere, and what the contents of an event can be. Getting Involved If you want to get involved with trying to nudge the direction of upstart development, you can join the upstart-devel mailing list at http://lists.netsplit.com/ Or if you just want to grab the source code, tarballs are published at http://people.ubuntu.com/\_{scott/software/upstart/ and the bzr archive is at http://bazaar.launchpad.net/\}keybuk/upstart/main

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

Here at Canonical Towers we have several staff who worship at the altar of Extreme Programming, and as such many of the methodologies and rituals prescribed by that religion find their way into our day-to-day working practices. A few of these came together in an interesting way a few weeks ago, and it was suggested by a cow-orker that I blog about it so he could give the URL to people. The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team. The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace. The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it. The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it. I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve. Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc. When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses. I swear Mark was sulking as he gave the laptop back and let me do it. Anyway, there is some relevance to that and we’ll come to it in a moment. The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold. Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test. Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass. This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting. So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program. Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on. I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs. Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist. What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again. This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.

Indeed, Jon Downland is right, the way Debian behaves these days is not very glorious, we are reflecting a pretty bad image. I don’t know if Ubuntu can be a good example for us (because we don’t have the same priorities), but I know one thing: Debian is completely hijacked by that thing we call “money”. We have to face the reality, as soon as the money came into the game, Debian has lost a point. I cannot predict if the DPL made the good choice when he decided to launch Dunk-Tank, but I can tell that now that it’s done, people have to face a very big mess. And I really hardly see how that will help us to release etch in time…

Lots of happy GRs! It's GR season, and everyone is rushing to produce a nice GR that would make Debian oh so much better than it already is. But some of us either lack the fantasy, or the grammatical competence, or just the time to contribute to this important effort. For those people, I prepared a handy polygen grammar that they can use. Here is today's GR:

1. After the release, the Donors widly do not take the Community in order to overruling this resolution in the interest of the Debian Release Managers for the purpose of promoting more prompt action.
2. The Debian Project Leader has the support of Debian for apologising the funds as seems subsidiary and reasonable for the purpose of promoting cooperation between Debian and the Debian Release Managers.
3. The Delegates broadly fund the swift funds for funding the Debian FTP Masters for the duration of the mandate for the purpose of the RMs.
4. For the purpose of being 100% Free Software, the Debian Project subsidiaryly can overrule the core proprietary drivers in main in order to apologising the needed funds for the Cabal promptly in the benefit of having a more harmful Project.
5. As seems harmful and experimental, the Debian Release Managers are devalued by the Debian FTP Masters in order to disbursing the copyright holder for the duration of the mandate for the purpose of Debian.
6. The Leader lets it be known that the Developers are approved by the Donors to reasonably revoking the Developers-controlled plan during the forthcoming release in the benefit of promoting more potential action.
7. Promptly, the Debian FTP Masters can be approved by the Delegates to establishing the reasonable Developers following internal discussion in the interest of our users and Free Software.
8. Effectively, the Delegates have the reasonable support of the Developers for neededly cooperating with the firmware in main with immediate effect, during the forthcoming release of Debian for the purpose of Everyone.
9. Debian reasonably funds the Community for broadly revoking the donations in the interest of Everyone for the purpose of having a more appropriate Debian Secretary.
10. In the interest of promoting more needed action, Everyone is of the core opinion that the Developers cannot be authorised by the Delegates to establishing the Developers-controlled Debian Release Managers as seems reasonable and needed for the purpose of reducing the delays of the New Maintainer queue.

I wish this GR generator helps to satisfy all our GR needs, and will finally free some time for people to work on making etch a really great distribution for all of us to run and love.

For the project that I’m dealing with at work I wanted to be able to authenticate devices in a two stage process. Stage 1 should authenticate the device to the network (via an x509 certificate) and then Stage 2 should authenticate the user who possesses the device with a username and password. Unfortunately none of the methods shipped by default with FreeRadius will support this sort of configuration.

• EAP-TLS supports mutual certificate authentication between the server and the client but does not allow for a second stage to verify the username and password
• EAP-TTLS and EAP-PEAP both support mutual certificate authentication between the server and the client followed by a second stage password verification, however the current FreeRadius implementation doesn’t let you require a client certificate. If one is present it will use it, but it is just as happy to continue on without one, which is not ideal for my circumstances.
• The remaining EAP- methods don’t support certificates at all, so they’re not even an option.

A quick skim through the FreeRadius source code revealed that it wouldn’t be too hard to add support for requiring client certificates with EAP-TTLS and EAP-PEAP. The following patch adds a new configuration option to the tls section of eap.conf which if set to true will require the client to present a certificate before authentication will succeed.

• freeradius-require-tls-client-cert.diff

Example eap.conf

eap  
                default_eap_type = ttls
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no
                md5  
                 
                tls  
                        private_key_file = $ raddbdir /certs/radius.key
                        certificate_file = $ raddbdir /certs/radius.pem
                        CA_file = $ raddbdir /certs/cacert.pem
                        dh_file = $ raddbdir /certs/dh
                        random_file = $ raddbdir /certs/random
                        # This is the new option
                        # If set to no, or missing, client certificates are
                        # not required for EAP-TTLS or EAP-PEAP
                        require_client_cert = yes
                  
                 ttls  
                        default_eap_type = md5
                 
         

With the latest driver "update", ATI removed support for the following graphics cards:

• Radeon 8500/9000/9100/9200/9250
• Mobility Radeon 9000/9100/9200
• Radeon IGP 9000/9100/9200

This is why closed source drivers suck. My Mobility FireGL 7800 is also not supported by the official ATI driver. Well, ATI obviously only cares about new sales, not about users. (Except that users like me will not but ATI anymore, but go for e.g. Intel) Fortunately, there are some opensource drivers for these cards. They also have 3D acceleration. Let's just hope ATI releases the documentation needed to support the newer cards (9600+, X300+) before they also discontinue support for these. (Or at least allows redistribution of the existant 2D drivers that have already been written for some of the newer ATI cards) So don't buy any newer radeon, because there is no long-term-support for them. In a few years, you won't be able to use them anymore!

I had a few comments on my last so I decided to write a new post about it.

Firstly in regard to Elspeth's comment. I agree that children should wear glasses if necessary. That part of my entry was not clear, I was trying to make the point that I can understand children not wanting to wear glasses because they think it's uncool. But adults should make decisions on more important things such as what is best for their eyes. There are real reasons for needing eye surgery, if without glasses your vision is so bad that you are legally blind then an ophthalmologist may recommend surgery for that. In cases of extreme vision problems apparently a combination of surgery and glasses is required for good results. I also think it makes sense for people who need surgery for their work, for example athletes such as Tiger Woods. Looking cool is not a real reason for surgery, especially not for the small increment of coolness that some people believe is associated with not wearing glasses.

All operations involve some risk. Risk to your vision is not worth a small amount of convenience and possibly looking cool. Besides, it's widely regarded that people with glasses are more intelligent! ;)

Shintaro mentioned that there is a risk of retinal damage from being short-sighted. What I want to know is whether the risk of that can be alleviated if you wear glasses all the time? If you wear your glasses everywhere except in bed, in the shower, and in the sento, does that stop this problem? Maybe I should try and wear my glasses for more than the ~15 hours a day that I currently do.

Finally an anonymous poster noted that they didn't know anyone else who had an optical migraine. My ophthalmologist mentioned that it's rare to have a migraine that only affects the vision and nothing else. I feel fortunate to have it like that, the list of other migraine symptoms sounds very unpleasant. Of course only having had it once I can't be sure that next time it will be the same. I might get the nasty symptoms next time. :(

However one problem with what I experienced is that it came on suddenly with no warning. It would be very unpleasant to suddenly lose central vision while driving (I would have to hope that the ability to react to objects without consciously noticing them works well). Fortunately I have only been driving about 300K per month in recent years and I can probably reduce this. So the chance of it happening while driving is quite small.

It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include: » All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3). » A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months. » We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run. To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months. To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions. At a high level, then, the LSB roadmap looks something like this:

LSB 3.x (2006-2008)	LSB 4.x (2008-2010)
Asianux 2.0 Debian 4.0 (”etch”) Mandriva Corporate 4.0 Red Hat Enterprise Linux 4 & 5 SUSE Linux Enterprise 9 & 10 Ubuntu 6.06 LTS (”dapper”) […]	Asianux 3.0 Debian “etch” + 1 Mandriva Corporate 5.0 Red Hat Enterprise Linux 6 SUSE Linux Enterprise 11 Ubuntu LTS “dapper” + 1 […]

» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly. » We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month. » In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future. » Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here. I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.

It seems to be the season to propose general resolutions. We seem to be having

• Proposals to decide what to do with non-free material that somehow isn't software (but is software after all).
• Proposals to decide what to do with our beloved DPL. Or not so beloved, apparently.
• Proposals to stop proposing proposals.
• And perhaps some non-finished and as of yet unproposed proposals, too. But I wouldn't know about that, oh no!

Personally, I've lost count as to how many proposals there are out now, and how many of them got the required amount of seconds and whatnot. Lucky me I'm not the secretary. But know what, since it seems to be trendy to propose GR's these days, I'll add my contribution for today:

-----BEGIN PROPOSAL-----
The DPL, seen as how he's fairly important for our inner workings,
should not choose his job lightly; having a bad DPL might have a
detrimental effect on the project as a whole. Therefore, we must make
sure that we discourage our fellow developers from becoming DPL unless
they mean it. It is, thus, imperative to make the DPL job not a very
nice one.
In that light, the Debian Project resolves that:
When the DPL makes an important decision that will have an effect on the
project as a whole, he is only allowed to do so provided he balances on
his left hand, puts his right big toe in his left ear and has his left
toe point towards the ceiling, types the command with his right hand,
doing all this while poking his nose with his tongue. The help of a yoga
master in training for this procedure is allowed; the help of a yoga
master or anyone else while actually performing the procedure for real
is not allowed.
To prove that the DPL did in fact follow procedure, a video should be
produced by the DPL or any of his relatives which is GPG-signed by at
least the DPL and a second developer who witnessed the proceedings
first-hand.
-----END PROPOSAL-----

A nice side-effect of this is that there will be no more DPL decisions once this resolution passes. That seems to be what people want. (oh, and for all you who take yourselves too seriously: the above is called "satire")

So, this is my first blog written in my new appartement. It was hard work in the last days to move all this but I’m very happy now to be out of this _VERY OLD_ house. Poorwise my ADSL connection is not yet activated by my ISP, but there are cool neighbours with W-Lan without any encryption. So, i’m new installing some new parts in my room, prepare my serverroom for the new rack which I will get tomorrow etc. And sorry that this entry won’t become longer, I’m very tired and happy to go to sleep soon.

With the ever increasing number of trolls, the average developer has no more time to maintain his packages. Motivating him to work on his packages instead of reading debian-vote is a hard challenge.

Here comes BAD-tank, which is the way to:

• motivate developers to work on their packages in the best interest of users;


• motivate users to get interest in what developers do;


• find a way for possible sponsors to spend their money in a useful manner.

BAD stands for Bribe Assisted Development. The idea is to add a new field, named XC-Bribe, to the control file. The field must contain the amount of money the maintainer requires for an upload, with a ISO-4217 currency code. For example, the maintainer might add:

XC-Bribe: EUR 50.00

to require 50 to get the package uploaded.

Then, the package shall be uploaded to the BAD-tank FTP queue. The related sources and binaries will be automatically put into a private area, while the .changes remains public. Users can then read the .changes and decide whether they want to contribute to this upload. BAD-tank accepts Visa, Mastercard, AmEx and PayPal. When the amount of the bribe is reached, the package is automatically uploaded to the Debian ftp-master queue, and the developer is credited with the bribe.

Since I currently have Debian Sarge and a quite actual kernel (2.6.17.13) successfully running on my 10 years old Pentium-1-ThinkPad bijou, I today thought I could see, if I get the builtin infrared port working. Since lspci and lshw didn’t help much to find out the details about the IR port, I looked at Werner Heuser’s tuxmobil for such information. And I was right: tuxmobil listed all the necessary informations: It’s an internal serial port infrared device on /dev/ttyS0 working without any special driver. It seems to only need the kernel modules irda, sir_dev and irtty_sir as well as probably also the Debian package irda-utils. I could immediately play around with gnokii after configuring it ot use the right serial port and the right drivers for my Nokia 6310i. Also sending SMS via xgnokii worked. It was funny to be able to play ringtones on the phone by clicking around on a virtual piano keyboard. Inebriated by the success with IrDA, I decided to go on and try myself with the notorious Mwave DSP sound and modem card, which came with some of the ThinkPad 760 versions including my ED version. This didn’t start as easy as IrDA since tuxmobil this time writes: But MWave and some other sound technologies won’t work or are very hard to get working, e.g. booting to DOS, loading a driver, then using the soundcard as a standard SB-PRO. So you might need a commercial sound driver. Well, I too often noticed that negative information about hardware support in Linux found on the net with a search engine often is outdated and the formerly badly missed hardware support is available nowadays. So even not giving up on a 404 for a promising site, I found the no more existing webpage of the Mwave Project for Linux in the WayBack Archive. There I found a still working link to Thomas Hood’s Debian GNU/Linux on IBM ThinkPad 600X page which mentions tpctl, the ThinkPad configuration tools for Linux. And happily, they’re included in Sarge as package tpctl. Another link still worked, too: The one to Dale Wick’s Thinkpad under Linux page, which tell’s what I’ve expected: Some of the information on tuxmobil seems to be outdated, although Dave’s page mainly concerns the modem functionality of the Mwave DSP. So I first installed tpctl on bijou, then tried to compile the ThinkPad kernel modules from package thinkpad-source with my both current kernels, 2.4.33.3 and 2.6.17.13 using make-kpkg. The modules built fine for the 2.4 series kernel, but failed on the two latest 2.6 kernels (2.6.17.13 and 2.6.18), I’m mainly running. So I switched over to playing around with the 2.4.33.3 kernel. The thinkpad modules loaded fine and I get access to a lot of the ThinkPad’s special hardware. But tpctl at least doesn’t work as expected regarding Standby and Suspend: It has no effect while requesting Suspend or Standby using apm still works fine. But nothing to see in direction sound, modem or mwave. So I had a closer look at documentation around the mwave module. Tried to find out appropriate I/O and IRQ settings for the module, but what I found in the Linux ACP Modem (Mwave) mini-HOWTO didn’t help. The module just didn’t load. Then I noticed that module seems to need an mwave daemon. A search in the Debian package repository found the package mwavem. No long thinking – installed it. But the installation script gave the same errors when trying to load the module. man mwavem(8) gave the reason: Only the 3780i chip is supported. Earlier Mwave DSPs, which were used for sound generation as well as modem functionality, are not supported. Also according to the kernel documentation for the mwave sound module, the only way to get it making some sounds seems to be to boot to DOS, load the Windows 95 drivers, then call loadlin and warm-boot Linux from DOS. So native Mwave sound on IBM 760 ThinkPads under Linux is really still a dream while the Mwave modem is said to work nowadays. I will continue my ThinkPad 760 journey with a closer look at the pcspkr driver and at eBay, where I’ll look for another 760 series ThinkPad, but with ESS1688 soundcard and no modem instead of the Mwave DSP, e.g. a 760L, 760LD, 760EL, 760ELD or maybe also a 765L. But I won’t do that today. It’s already much too late. Should have gone to bed about two hours ago…

Now playing: Auld Lang Syne (monophonic on the phone :-)

Massachusetts held its primary election yesterday and strangely enough, my preferred candidate for governor, Deval Patrick, won overwhelmingly, by a nearly two to one margin over both of his competitors. In past years, the primary election has been followed by a “unity breakfast” the next morning so all the losing candidates can pledge fealty to the winner. As the breakfast has become a tired tradition identified with “old politics,” they did away with it this year (perhaps at Deval’s urging). Instead, again to my surprise, they held a unity rally about a block away from my house in Adams Park (no relation) in Roslindale. Deval was introduced by Boston Mayor Menino, a politican who has somehow turned a complete lack of public speaking skills into an asset: Deval’s speech was pretty great. A little something for everyone, and genuinely engaging. I attempted to record it on my pocket MP3 player, but apparently I ran out of batteries early on so it’s not worth posting. Although Deval has been cast as the furthest left of the candidates, I was struck by his extremely moderate position on most issues. (Standardized testing: good, but needs improvement; economics: need to have several bottom lines, including a profit bottom line and a people bottom line; personal responsibility needs to be balanced with societal responsibility; etc..) Anyway, the crowd loved it: Apparently there was no experienced political handler present to orchestrate this event. Deval’s charismatic speech was followed by several less important and less eloquent speakers. Usually, you would want to build up from worst to best. In any event, Chris Gabrieli, the second place finisher, has rebounded instantly and was up there committing to work every day until November on getting Deval elected — I won’t be surprised if Gabrieli ends up in a development-czar role in a Patrick administration. The last place finisher (and original frontrunner) Tom Reilly was nowhere to be seen, a fact that I’m sure will be prominent in tomorrow’s reporting on the event. Where’s the unity without the Attorney General? Everyone’s bracing for a horrid onslaught of fear-mongering campaign ads from the Republicans. My hope is that Massachusetts citizens are a bit wiser than the rest of the country and it will backfire. I won’t hold my breath, however. (As a side benefit, I finally met Adam Gaffin, universalhubmeister, for the first time, as well as his eight year old daughter Greta. Greta is now famous for rejecting Deval Patrick’s plan for longer school days.)

My Friend Moritz has started a small personal art photography project called "World of Contrasts", where he wants to work with the effects of, well, contrasts. On his site you will find the gallery with a few pictures already and an accompanying blog.

The City of Munich announced today the next step in their move to a Debian-based system for standard desktop usage. After successfully tests being run on some systems, e.g. the system of the city Mayor, the first production systems for real users were rolled out. I'm so glad and proud for different reasons:

• All employees of the City of Munich will work on a Debian-based system. That is really just cool, especially for someone coming from Munich and living there since ever. That is even better if one is actively involved in release of Debian.
• The City makes this move for a very good reason - as part of a long-term strategy to escape vendor-lockin. The City has been known for years to make such good decisions in different areas - power, public transport, water, and now also software. That's actually one of the reasons why it is really worth living here.

Since I installed democracyplayer, I must admit that my production/consumption ratio has slipped a bit. To rectify this, I've been thinking about creating a bit of content myself. On Slashdot, there has been a bit of discussion on beginner's programming languages, such as BASIC, and whether their absence from "modern" systems has pushed people (children/teenagers mostly) into pure consumer roles, as the learning curve with those languages that ship with the OS is far too steep, so they do never begin to program. So, my idea would be to create a bit of a programming tutorial that teaches people the first steps with a deliberately simple language (line based, interpreted, imperative) and realises (in several steps) a small project that leaves you at a place where you know the basics so you can tweak, and with hopefully enough incentive to do so. The goal is not only to teach the programming basics (there are probably people who can do this better than us), but to awake interest in understanding and modifying.

There are just three days left to get discount registration for XTech WebDev London: our new one-day training event on Rails, Ajax, REST and web application design and development. It will be held in London on 31 October 2006. It's a great opportunity to get yourself and your team up to date with the latest web development technologies. Our speakers are real world practitioners who will tell you about the pitfalls as well as the promises. You will hear:

• Andy Budd on designing with web standards
• Jeremy Keith on Ajax, what it is, and its appropriate use
• Tom Coates on the building web applications as part of Web 2.0
• Leigh Dodds on the REST model for web applications and its benefits
• Matt Biddulph and Edd Dumbill on real-world Ruby on Rails

Additionally, everybody gets a copy of Cal Henderson's Building Scalable Web Sites, a buffet lunch and plenty of time to talk with the speakers and other attendees. We start at a developer-friendly time of 10am, which also gives plenty of time for those coming from further than London. There'll also be social events in the evening where you can continue networking and learning in more relaxed surroundings. Register now to attend at the cheaper price of 275.