In just under a month, the tenth O'Reilly Open Source Convention will get underway in Portland. Over ten years OSCON has developed—along with the world of open source—into an intense, exciting, informative, diverse and exhausting event. This year I've the privilege of being co-chair, along with Alison Randall. We've packed so much into the show, it's a difficult job even being able to comprehend it as a whole! Fortunately, there's a way to start making sense of things before you arrive there, thanks to the personal scheduler. Just mark the sessions you want to go to with a star, and you'll be able to plan out your time in advance. I wanted to list a few sessions from my own personal schedule that particularly piqued my interest. Then at the bottom of this post I'll share a discount code which can give readers of this blog 15% off OSCON registration. There's bribery for you. Practical Erlang Programming Largely thanks to XMPP enthusiasts and ejabberd, I've been hearing increasing amounts about Erlang, and I'd like to know enough about it to be dangerous. This three hour tutorial looks just the ticket. Open Source Virtualization Hacks This is one of several sessions we have on virtualization, something I'm particularly pleased about. Virtualization may be "done" at the kernel level, but I think we're only just starting out on its application. This session is by my friend and sometime co-author, Niel Bornstein, who works for Novell on just this sort of thing. Using Puppet: Real World Configuration Management Puppet is the piece of open source software that is most exciting to me at the moment. As a developer, it enables me to manage my machines like I'd manage my code libraries. A must-see if you've not used Puppet yet. These are just 3 out of the 300 or so confirmed sessions. Don't forget there's a large number of events and parties happening around OSCON too. And finally, the discount code. Use the code os08pgm when you're registering, and you'll get 15% off the ticket price. See you in Portland!Join the conversation about this post

Gunnar, have a look at this:

. So your example using the Penta website was just a bad one, and I personally agree with the "INVALID" resolution of your bug report. In fact, showing a partially encrypted connection as an insecure one is an overall advantage for (l)user securities, as with the browser interfaces we are used to use, we don't know which parts are actually sent encrypted and which are not. As you can see in the example above a fully encrypted connection is properly reported as such by Firefox 3.0. FWIW: I'm overall satisfied with Firefox 3.0, especially about the new URL bar Wouther is disliking. Yes it is a bit slower than before, but even on my 4-year old laptop it is perfectly usable. The HTML title shown there? Well, it is rather handy when I start typing bugs.debian.org and then I've to discriminate among tons of almost identical bug report URLs ... Is the about:config hand-holding dialog worst than the pop-up the first time you "have provided unencrypted information" in a random form? It is not, we have probably just forgot about the first time we unchecked the corresponding checkbox. All in all, the only "feature" of the new Firefox I found incredibly stupid is the SSL certificate exception mechanism. Installing the untrusted certificate is what? ... 5 click-away from the initial page? That is just dumb. (And as it is well-known that habits form anyhow, getting the habits harder to form is just a way to piss-off users.)

When it comes to research and writing, anthropologists are notorious for being slow as molasses. It takes, on average, 9 years to finish grad school and then another 3-6 years before you write and publish your first book. Such is the sometimes frustrating pace of academia. But sometimes it is worth the wait as this new book, Two Bits, the Cultural Significance of Free Software by the anthropologist of science and technology Chris Kelty, makes clear. I am pretty intimate with the details of the book as ck was one of my dissertation committee members. I have read earlier versions and was fortunate enough to teach the final version to a small group of graduate students last spring. While there have been previous books on the subject of open source or peer-to-peer production more generally, this is the first book to delve deep, analytically and historically, into the cultural significance of free software. And the best part is that ck managed (I am not sure how but he did) to convince Duke University Press to release the whole book under a CC license. So download it to your heart’s delight and if you find it useful, do order a treeware copy (as you can’t beat that for easy and comfortable reading). For the developers out there, I would suggest starting with the introduction, which provides an initial overview of some of the main themes he develops and then I would dig into part two where the historical chapters reside and then loop back to the theoretical chapters in part one or continue to part three. Trust me, these will fascinate and surprise even those geeks with a relatively deep historical sense of this world. In fact, my very favorite academic piece on free software exists in these pages: and is the chapter on the history of the actual conflict between James Gosling and Richard Stallman that led to the creation of the GNU General Public License. Here is a small excerpt to whet your appetite:

In brief the controversy was this: in 1983 James Gosling decided to sell his version of EMACS a version written in C for UNIX called GOSMACS to a commercial software vendor called Unipress. GOSMACS, the second most famous implementation of EMACS (after Stallman s itself ), was written when Gosling was a graduate student at Carnegie Mellon University. For years, Gosling had distributed GOSMACS by himself and had run a mailing list on Usenet, on which he answered queries and discussed extensions. Gosling had explicitly asked people not to redistribute the program, but to come back to him (or send interested parties to him directly) for new versions, making GOSMACS more of a benevolent dictatorship than a commune. Gosling maintained his authority, but graciously accepted revisions and bug-fixes and extensions from users, incorporating them into new releases. Stallman s system, by contrast, allowed users to distribute their extensions themselves, as well as have them included in the official EMACS. By 1983, Gosling had decided he was unable to effectively maintain and support GOSMACS a task he considered the proper role of a corporation.
[ . . .]
Indeed, the general irony of this complicated situation was certainly not as evident as it might have been given the emotional tone of the debates: Stallman was using code from Gosling based on permission Gosling had given to Labalme, but Labalme had written code for Gosling which Gosling had commercialized without telling Labalme conceivably, but not likely, the same code. Furthermore, all of them were creating software that had been originally conceived in large part by Stallman (but based on ideas and work on TECO, an editor written twenty years before EMACS), who was now busy rewriting the very software Gosling had rewritten for UNIX. The once proud hacker ethic that Labalme mentions would thus amount not so much to an explicit belief in sharing so much as a fast-and-loose practice of making contributions and fixes without documenting them, giving oral permission to use and reuse, and losing records that may or may not have existed hardly a noble enterprise.
[. . .]

The story is a lively one, punctuated with some great e-mail “moments,” and gives you a play-by-play sense of how it is that free software become so entangled with the law and how the unwritten norms that guided sharing were violated to then become transformed, explicit, and written. The other chapter that will also fascinate those who want a deeper sense of this history is on UNIX and its role in creating the technical and collaborative conditions necessary to secure the explosion of free software years later. The story of the norms of sharing source code is, not by accident, writes Kelty, also the history of the UNIX operating system. This connection has been made by others but not shown in any historical detail as it is done in this book. For those interested in more anthropological issues, the first few chapters is where this type of more conceptual theorizing is at. Chris Kelty introduces the master trope of his book: the recursive public which is an idea that feeds into a longer academic debate, inaugurated by Jurgen Habermas, on the role of publicity, dialogue, and circulation of ideas and texts in cementing a democratic sphere. Many others, such as Charles Taylor, Michael Warner, and Nancy Fraser have since refigured and rehashed the meaning publics and public debate but there have been few ethnographies on the topic. It is here where Chris Kelty intervenes most forcefully to conceptualize publics in explicitly ethnographic terms and in an arena technology and the Internet which is often left undertheorized by cultural theorists. There is a lot more in the book (the third section examines some of the various political modulations of free software, such as Connexions and Creative Commons) but instead of saying any more, I will just leave you with his definition of a recursive public and again urge you to check out the book for yourself!

A recursive public is a public that is vitally concerned with the material and practical maintenance and modification of the technical, legal, practical, and conceptual means of its own existence as a public; it is a collective independent of other forms of constituted power and is capable of speaking to existing forms of power through the production of actually existing alternatives.

I was misled. That much is probably true. I certainly had no idea what I was getting myself into. Enough of that though; there's narrative fading away. The part I should take responsibility for is the decision I made to stray off the map. Perhaps it was not so much a decision as a compulsion. I looked at the map. I saw the suspicious unmarked area at the edge, and concluded immediately that there was something good there, something the people wanted to keep hidden from me. I was correct, but I presumed far too much about the terrain. I thought I would make a quick exploration of the secret place, then backtrack to the more mapped area and get back with the program. Enough of that though; I've nearly forgotten the story. First I should point out that, had the map been to scale, it should have taken me an leisurely fifteen minutes to get to my first destination. It should have, assuming the land would be as flat as the map that represented it. Instead, it turned out to be something one could cover in fifteen minutes if one had, say, a jetpack and spring boots. I'm probably wrong; I'd probably injure myself in the process and take longer. Anyway, the average incline was close to 45 , and luckily was mostly uphill. Luckily. When I got to a resting place, I was able to conclude that my supply of fluids was almost certainly insufficient for me to continue. On the other hand, there was probably no way I would return if I went back for more drink. I told myself that there would likely be a beverage-selling shack out in the middle of nowhere around the next bend or so. Having solved this probability problem, I pressed on into the blazing sun. I came to a path leading down to the sea. It was unclear what was down there, but it was clear that it seemed to be a million miles down, and that that path might be the only way back. Given my current state of exhaustion and hydration, I decided to pass on this opportunity. After continuing for a while, the features at the bottom of that path became visible. A very pretty cove was down there, and almost certainly no shack o' drinks. I then came upon a fork. A wide path led downward: to what, I could not see. To its left, a narrow and rough path led straight. Knowing that a descent probably meant climbing four to eight times the altitude back somehow, and assuming the less pleasant-looking path led somewhere better, I went left. After a while, the land began to slope down, ever so slightly. Little clusters of bottles and newspapers were left on the rocks here and there. Then came a sofa under a tent. I began to wonder what hippies were traveling this path. The slope grew greater, and I passed a bench in a tent. Then I came to a giant staircase, almost straight down. It was covered in weeds and insects. Some were vegan, some wanted my flesh. As I got toward the bottom I thought about how glad I was that I had come that way from the top and not the other way around. Oh, I was very glad. At the bottom was something resembling a plastic bottle graveyard and barrels among barrels filled with water. Rubber hoses seemed to run randomly between certain barrels. A kitchen stood at the edge of some barrels. I suddenly got the feeling that I was not supposed to be here. After discovering that a couple of escape routes were actually dead ends, I proceeded to descend a small staircase to a terraced garden. Hoses lay about the rows, presumably for watering the plants. A cot under a tent lay empty, and I hurried past hoping I would not encounter the owner. Then I was at the ocean. The coast was lined with huge boulders, and a wooden bridge led me to the first one, and another wooden bridge took me to the second. Then the bridges stopped. In the distance, I could see that pretty little cove from before. I took stock. I could either return whence I came, up that horrifying staircase, or I could try to traverse the rocky coast over to the cove, then maybe do a faceplant on the beach and let the tide drown me rather than climbing back up. It seemed like a no-brainer, so I began making my way toward the cove. It got harder. Several times I became very afraid, either of falling and smashing my head against a rock or falling into the water below, or some sequential combination thereof. In the end I turned out to be more afraid of going back, at least until I got to what I judged the point of no return. I was reasonably close to where I imagined the sandy beach started, but there was a huge and impassable boulder in the way. Also, if I went further there was no way I would be able to climb back up in case I needed to retreat. I was thinking I would need to retreat, because unless there was some magical hidden toehold, I would be forced to jump into the water and swim around. I did not want to jump into the water. I wanted my phone to stay unfried in the event that I would need to use it to get rescued. I also did not want to call anyone to get rescued, especially since I didn't really know how to explain where I was. With a heavy sigh, I gave up, turned, and went back. This time I moved more quickly, though incurring more damage to my hands and feet. No humans were visible at the crazy farm/garden and makeshift reservoir, but plenty of bugs were visible on the staircase. I made the mistake of trying to lean against the railing to catch my breath. When I finally got to the bench in the tent, I understood exactly what it was for. I sat down, took a sip of my remaining water, ate an apple, and kept going up. When I got to the couch, I sat again. This time I sat and tried to figure out a plan. I still clung to the belief that once I got back to somewhere less wild I'd be able to buy a drink. I noted that I only had a little bit of water left, that I was dehydrated, that I was sunburned, that my pulse was about 180, and that there were no dogs or Russian people wandering past me. I ate a pear and drank my last few drops of water. I kept sitting until my pulse was down to around 150, then I figured I needed to keep moving. I was experiencing most of the effects of caffeine, and for free. Oddly, I passed a dog a few steps later. It was just standing by a rock, looking at me. I decided not to converse. When I had nearly reached the fork again, a couple came my way. I thought about begging them for water. I decided not to be rude. I have no idea what happened to them. I'm betting they wisely decided not to go down the steps. Resolving that the only sane option was to go back all the way to where I absolutely knew I could buy something potable, I headed in that direction. Still, I took two risks. Instead of going up the exact way I had come, or taking a well-travelled path down, I took a narrow and flat dirt path. It was actually a bit of a dilemma. I started down the latter two more than once each. Finally I saw that the down path was rather V shaped, and I concluded correctly that the straight path would bypass that angular-half-pipe-like construct. When I finally got to a point I recognized, it was smooth sailing the rest of the way down. I bought water and a snack, since I had had almost nothing to eat that day. At this point it would have been prudent to call it quits and go off and gorge myself on seafood or something, but no, I was now in the mapped area and surely it would all be roses and manna. Finishing one bottle, I bought two more. Five minutes later I bought another. I had now overcompensated, but I was playing it safe. I continued my explorations. Bicyclists kept nearly running into me, and, aside from the obvious, I viewed this as a good sign. Bicyclists, especially those that can't seem to steer straight for some reason, avoid difficult terrain. This is why they take their bikes on subways, trains, and buses. I don't like bike-riding, but if I had my druthers, I would always go downhill. No up, no flat, just down. Like downhill skiing, just down. It is a good thing I don't ride a bike. Once I got to the point where the bicycles thinned out to nonexistence, I was at an intersection. The way I wanted to go was up. The way I didn't want to go, but was a reasonable option, was only very slightly up. Additional factors complicated this decision point. [elision]

This passage has been marked friends-only and you will not be able to view it without logging in. Moving hurriedly away from there, I headed upward. After a couple of turns, I ran into Catholics. First there were dead Catholics. Then there were Catholics pre-occupied with dead Catholics. Then there were Catholics waiting to die. Then there were seminarians. Then there were teens with prayer books. When I reached the next pinnacle, there were more teens with prayer books. There were benches, and there were no teens on them, for the teens were standing or sitting on the ground, quietly contemplating the Word. Unfortunately, they had decided that the benches were more suitable for holding all their bags, so there was nowhere for me to sit. I considered interrupting their reverie, but decided it wouldn't be very Christian of me to disturb them, so I just placed an ancient Drasnian curse on them and plodded down the hill toward a small beach. I really didn't need any more sun, but at least there probably wouldn't be anyone praying there. The water was tempting, but I'm always paranoid about my belongings when swimming alone, and if my phone were taken I wouldn't be able to call anybody to come rescue me at the next crisis point, sure to come. So I skirted the coastline and arrived at a much larger beach, one with facilities and services. Opting to save money but complicate things by using the public changing rooms and showers, I made a discovery. [elision]

This passage has been marked friends-only and you will not be able to view it without logging in. Nonetheless, I changed into my swimming trunks, stuffed everything else but my towel, sunglasses, and a disgusting sugary drink I never should have bought into my bag, and went barefoot a few buildings down to rent a locker. The locker was ridiculously large for a single person, which is good to know should I ever want to kidnap a family and torture them at this place. The proprietor informed me that they were closing at some specific time, about an hour from then. I had no timekeeping device outside of the locker, so I had to wing it, and erring heavily on the side of caution, I had a short beach diversion. Given that large swathes of my epidermis were turning bright red, it's probably for the best. Handling the shower, locker, and changing in the other direction was slightly more complicated, but I did it and then I headed inland, figuring I should have a substantial meal for once that day. On my way to find dinner is when things got really crazy. [elision]

This passage has been marked friends-only and you will not be able to view it without logging in. I wandered over to a bench to eat my newly-acquired snack, and did not exercise enough caution, because the flimsy paper bag ripped and I got sauce all over my pants and a little on my shirt. Unfortunately I had used my napkin in that earlier episode, and I'm not sure how much it would have helped anyway. Thus I continued on, looking like a slobby retard. Then I made an obviously-poor decision and ended up having a subpar dinner. What happened after that is a story for another time.

The plot..
Some years ago, when I started using linux, I felt the need for video chat, and hence intended to buy a webcam..
Unfortunately, while most of usb hardware is standard, such as the usb mass storage class, this is not at all the case for video, although it is starting to get better with the usb video device class which is more and more used by modern webcams.
So, at this time, each webcam would have its own communication protocol, and each driver had to implement a different way (...)

It's sometimes surprising where power goes in a laptop. One of the things busily consuming power is the digital link between the graphics hardware and the TFT, which is busily updating your screen 50 or 60 times a second. That's kind of unfortunate, because most of the time nothing's actually changed. Unlike CRTs, TFTs don't have the same requirement for rapid updates to maintain an image - reducing the vertical refresh rate (within reason) won't result in any reduction in image quality. What it will do is result in jerky movement and blurring, though, so doing this by default is a problem.

The obvious way to handle this would be to downclock the display when it's idle and upclock it again when it's active. Doing so gives the benefit of reduced power consumption when not much is going on (most of the time) and not impairing image quality. Programming clocks takes a noticable amount of time, and doing it while they're controlling the display results in nasty screen flicker. Thankfully, Intel hardware has two sets of clocks per output. One can be programmed at high frequency, and the other at low frequency. On pre-965 chipsets, we can then simply flick between them whenever the screen becomes idle or active - the clocks are already set up and the hardware waits for the next vblank before actually performing the switch, so there's no blurring or flicker. 965 theoretically does all of this in hardware, but I haven't actually tested that yet. In principle the patch sets it up, but...

The savings seem to be on the order of 0.5W or so, though that'll probably depend on your screen resolution. Patch against current git is here, and a precompiled version of the driver for 32-bit is here. The most likely problem is screen flicker when idle, so if anyone sees that then let me know and we'll see if it can be tuned.

Sometimes people propose other solutions to have the Aptitude-gtk project done, like :

I d have thought that the most interesting way of doing aptitude-gtk would be to write a gtk backend for libcwidget. -Karellen

As this might be of interest to more people, I’ll repost Daniel Burrows‘ response :

Although I can see where you re coming from, a GTK+ backend to cwidget would have no significant upsides and significant downsides. The main upside to doing that from a practical point of view is that you would have only one piece of driver code for the GTK+ and curses interfaces. You wouldn t have to rewrite the entire interface from scratch to create a GUI frontend. But this is just an illusory benefit. cwidget is a terminal interface library and aptitude s curses frontend is a terminal-based UI. From a practical point of view, this means that aptitude regularly assumes that, for instance, to clear out a line it s sufficient to output $WIDTH space characters (ASCII 32) with the desired background style. A port of cwidget to GTK+ would have to introduce new, interface-independent abstractions for all operations like this and eliminate all direct use of terminal-based assumptions, at a significant cost in complexity for both cwidget and the aptitude frontend. In order to transition to these new conventions, I believe you would have to rewrite large portions of both cwidget *and* aptitude in order to make the interface abstraction layer work. (remember: the justification for doing this is to avoid having to rewrite aptitude!) Furthermore, while this approach avoids reimplementing aptitude s curses interface (sort of, except where it doesn t see above), it does so at the cost of requiring you to reimplement all of cwidget, for GTK+. I just did a quick line count (with wc -l ): in all of cwidget there are 23,390 lines of code, while aptitude s curses frontend has around 23,359 lines of code (some of which are actually shared with the other frontends but are in the curses directory due to the historical organization of the code tree). Not only is a rewrite of cwidget more involved, but the amount of code you d have to replace is comparable to the amount implicated in a rewrite of aptitude itself! Finally, even if these costs weren t enough to eliminate the idea, it s not at all clear to me that a GTK+ backend for cwidget is even desirable. Although aptitude has some superficial similarities to a GUI program, the process of designing an interface to run in a terminal (where the available input mechanisms are relatively restricted and all output is to a character-cell grid) is rather different from the process of designing a GUI. GUI programs can t rely on some simplifying assumptions that terminal programs can, and at the same time they have a lot more options available to them (just to name a few: graphics, multiple windows, differing text sizes and rotated text). Trying to force everything through an abstraction designed for terminal output would require you to either

eschew those options,

provide abstract GUI components that somehow fell back to terminal rendering in a terminal, or

add ways for the frontend to extend the abstract widgets with custom functionality.

1. is not an option because I (and, I think, Arthur) want to design a good GTK+ package manager, not a good GTK+ imitation of a console package manager. 2. and 3. amount, in my strong opinion, to writing two separate interfaces but intertwining their implementations in a mass of maintenance-resistant and extension-resistant spaghetti code. At the end of the day, I think that having two separate frontends (sharing backend logic where appropriate, of course) is a far cleaner and more maintainable design, and also easier to create.

As I said earlier, I intend to go a little farther than just making a GTK+ “skin” over the curses interface. Think less like gvim and emacs and more like maybe ddd. I should also add that the cwidget library is used by no major programs except Aptitude so few others would benefit from a GTK+ backend. As the cwidget library homepage says:

cwidget was originally an internal user interface library for the aptitude package manager. This means, on the one hand, that cwidget is known to work in the real world for a real application; on the other hand, it means that the feature set of cwidget is coextensive with the requirements of aptitude.

If you want a reliable network then you need to determine an appropriate level of redundancy. When servers were small and there was no well accepted virtual machine technology there were always many points at which redundancy could be employed. A common example is a large mail server. You might have MX servers to receive mail from the Internet, front-end servers to send mail to the Internet, database or LDAP servers (of which there is one server for accepting writes and redundant slave servers for allowing clients to read data), and some back-end storage. The back-end storage is generally going to lack redundancy to some degree (all the common options involve mail being stored in one location). So the redundancy would start with the routers which direct traffic to redundant servers (typically a pair of routers in a failover configuration - I would use OpenBSD boxes running CARP if I was given a choice in how to implement this [1], in the past I’ve used Cisco devices). The next obvious place for redundancy is for the MX servers (it seems that most ISPs have machines with names such as mx01.example.net to receive mail from the Internet). The way that MX records are used in the DNS means that there is no need for a router to direct traffic to a pair of servers, and even a pair of redundant routers is another point of failure so it’s best to avoid them where possible. A smaller ISP might have two MX machines that are used for both sending outbound mail from their users (which needs to go through a load-balancing router) as well as inbound mail. A larger ISP will have two or more machines dedicated to receiving mail and two or more machines dedicated to sending mail (when you scan for viruses on both sent and received mail it can take a lot of compute power). Now the database or LDAP servers used for storing user account data is another possible place for redundancy. While some database and LDAP servers support multi-master operation a more common configuration is to have a single master and multiple slaves which are read-only. This means that you want to have more slaves than are really required so that you can lose one without impacting the service. There are several ways of losing a server. The most obvious is a hardware failure. While server class machines will have redundant PSUs, RAID, ECC RAM, and a general high quality of hardware design and manufacture, they still have hardware problems from time to time. Then there are a variety of software related ways of losing a server, most of which stem from operator error and bugs in software. Of course the problem with the operator errors and software bugs is that they can easily take out all redundant machines. If an operator mistakenly decides that a certain command needs to be run on all machines they will often run it on all machines before realising that it causes things to go horribly wrong. A software bug will usually be triggered by the same thing on all machines (EG I’ve had bad data written to a master LDAP server cause all slaves to crash and had a mail loop between two big ISPs take out all front-end mail servers). Now if you have a mail server running on a virtual platform such that the MX servers, the mail store, and the database servers all run on the same hardware then redundancy is very unlikely to alleviate hardware problems. It’s difficult to imagine a situation where a hardware failure takes out one DomU while leaving others running. It seems to me that if you are running on a single virtual server there is no benefit in having redundancy. However there is benefit in having an infrastructure which supports redundancy. For example if you are going to install new software on one of the servers there is a possibility that the software will fail. Doing upgrades and then having to roll them back is one of the least pleasant parts of sys-admin work, not only is it difficult but it’s also unreliable (new software writes different data to shared files and you have to hope that the old version can cope with them). To implement this you need to have a Dom0 that can direct traffic to multiple redundant servers for services which only have a single server. Then when you need to upgrade (be it the application or the OS) you can configure a server on the designated secondary address, get it running, and then disable traffic to the primary server. If there are any problems you can direct traffic back to the primary server (which can be done much more quickly than downgrading software). Also if configured correctly you could have the secondary server be accessible from certain IP addresses only. So you could test the new version of the software using employees as test users while customers use the old version. One advantage a virtual machine environment for load balancing is that you can have as many virtual Ethernet devices as you desire and you can configure them using software (without changing cables in the server room). A limitation on the use of load-balancing routers is that traffic needs to go through the router in both directions. This is easy for the path from the Internet to the server room and the path from the server room to the customer network. But when going between servers in the server room it’s a problem (which is not insurmountable, merely painful and expensive). Of course there will be a cost in CPU time for all the extra routing. If instead of having a single virtual ethernet device for all redundant nodes you have a virtual ethernet device for every type of server and use the Dom0 as a router you will end up doubling the CPU requirements for networking without even considering the potential overhead of the load balancing router functionality. Finally there is a significant benefit in virtual machines for reliability of services. That is the ability to perform snapshot backups. If you have sufficient disk space and IO capacity you could have a snapshot of your server taken every day and store several old snapshots. Of course doing this effectively would require some minor changes to the configuration of machines to avoid unnecessary writes, this would include not compressing old log files and using a ram disk for /tmp and any other filesystem with transient data. When you have snapshots you can then run filesystem analysis tools on the snapshots to detect any silent corruption that may be occurring and give the potential benefit of discovering corruption before it gets severe (but I have yet to see a confirmed report of this saving anyone). Of course similar snapshot facilities are available on almost every SAN and on many NAS devices, but there are many sites that don’t have the budget to use such equipment.

[1] http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a `dom0` on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 `dom0` is reported to work, however.

Configuring the packet filter The first thing I did was to configure the packet filter on each host appropriately. Unfortunately, this is harder than it should be, because to quote one of the netfilter developers when ip6tables was conceived, someone had a big bad brainfart : rather than adding IPv6 rules to your existing iptables ruleset, you have to create a new ruleset, duplicate all chains, networks, hosts, and individual rules, and maintain the two in parallel. Even though there are efforts of unification on the way, I speculate it ll take another couple of years until PF_INET6 will be fused into PF_INET and one will be able to do sensible cross-address-family packet filtering with Linux. Since I ve recently started to look (again) at pyroman, maybe the most logical way forward would be to extend it to write both, IPv4 and IPv6 rulesets from its knowledge about the hosts and networks you configured. Anyway, we want to get stuff working now! Thus, let s configure ourselves a packet filter. (Almost) all IPv6-related filtering must be configured via ip6tables (read on further down about IPv6 in IPv4 tunneling, the reason I said almost ). The following is a simple default ruleset to start with, which I put into /etc/network/ip6tables to load with ip6tables-restore:

*filter
:INPUT REJECT [0:0]
:FORWARD REJECT [0:0]
:OUTPUT ACCEPT [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT

Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking. The ruleset should be fairly obvious, but you might wonder about my use of REJECT and allowing all ICMP after all, you ve heard for the past 30 years that ICMP is a bad hacker protocol , and Internet security is no domain for being nice to people, so to prevent any information disclosure, you should DROP connections, not let people know that they re simply not allowed. Well, to hell with all that! I don t see a single reason or attack vector that is foiled by DROP or disallowing ICMP. In fact, it s just security by obscurity, and might inconvenient at the same time. ICMP is also much more important with IPv6 than with IPv4 (it replaces ARP, for instance), and it s actually useful to be able to ping hosts, or get back informational messages on why something failed. Finally, rejecting traffic rather than dropping it doesn t suggest to a hacker that something s hidden here. Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!

Getting connected If you already have an IPv6 address, you re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net. If you are reading up to here, I assume you are connected to the Net with IPv4. There are two ways for you to move towards IPv6: 6to4 or by way of a tunnel provider. A Kiwi website explains how to setting up 6to4 connectivity, and thus I will concentrate only on the tunnel approach. Even though everyone can set up 6to4 in a breeze without any accounts or waiting, there are a number of security considerations, it s pretty ugly to debug (due in part to asymmetric routing), and makes your life unnecessarily difficult when all you have is a dynamic IP that changes from time to time. If you are stuck behind a NAT gateway, you cannot use 6to4 either. Thus, I prefer the tunnel approach. With the tunnel approach, IPv6 packets are wrapped up in IPv4 packets on your host, and sent to the IPv4 address of your tunnel provider, who has native IPv6 connectivity. The tunnel provider unwraps your packet and shoves the contained IPv6 packet onto the backbone. The IPv6 address you used as source address is routed to the tunnel provider, so any replies arrive at their machines, where they re again wrapped into IPv4 packets and sent to your (publicly-accessible) IPv4 address. Those IPv4 packets specify payload type 41 ( ipv6 ), which is why we need those

-p ipv6
-j ACCEPT

rules in the iptables ruleset. There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts. Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:

static tunnels, for those with static IPs,
heartbeat tunnels, for those with dynamic IPs, and
AYIYA tunnels, for those behind NAT gateways.

Each of these tunnels have advantages and disadvantages, as everything does: the first two types of tunnels use IP protocol 41 packets to encapsulate the IPv6 packets. As such, there are security considerations involving the impersonation by spoofing, and all upstream firewalls must let protocol 41 pass. AYIYA addresses these problems by using signed packets, but that solution comes with extra computation overhead and smaller MTUs. I suggest to use the first type of tunnel that fits your situation. Debian s aiccu package can take care of heartbeat and AYIYA tunnels for you, and it can even set up static ones. During registration, you will also need to choose a PoP , which stands for Point of Presence . If your country only has a single PoP, that s the one you will end up using (unless you have a good reason for another one), but if there are more options, I strongly suggest that you go through the list of PoPs and select the one with the best roundtrip time and lowest latency from your location! Note that you must answer ping requests (ICMP echo-request) from the PoP you chose, or else the tunnel will not be created. Once your tunnel request gets approved, you ll get a /64 prefix, in which you only use two addresses: the PoP will configure the :1 address and you need to configure your host to use the :2 address on the tunnel interface. You ll also be told the IPv4 address of your PoP endpoint . Joey Hess taught me that aiccu can set up the interface for you, using the data it queries from the SixXS registration (TIC) server. I tried it, and it works. However, I prefer the pure ifupdown approach, as it makes things explicit and allows me to use the hooks for stuff like loading the packet filter. So in my /etc/network/interfaces, you can find:

auto sixxs
iface sixxs inet6 v4tunnel
  endpoint 194.1.163.40
  address 2001:41e0:ff00:3b::2
  netmask 64
  gateway 2001:41e0:ff00:3b::1
  ttl 64
  pre-up ip6tables-restore < /etc/network/ip6tables
  up ip link set mtu 1480 dev $IFACE
  up invoke-rc.d aiccu start
  down invoke-rc.d aiccu stop

Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity. Also set ipv6_interface sixxs in /etc/aiccu.conf, if you are using aiccu, or else aiccu will bring up a duplicate/additional interface. If you tell it to use the same interface, it will actually execute all the same commands (which will fail), but won t report any errors. A future version will have a switch to prevent it from configuring the interface. Unfortunately, this will probably not work. The reason is that your regular IP packet filter (iptables, without the 6) doesn t let those encapsulating IPv4 packets pass, unless we tell it to; we probably want to do this early on in the chain, and also limit it to our tunnel peer, so:

iptables -I INPUT -p ipv6 -s 194.1.163.40/32 -j ACCEPT

For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn t work, you have an upstream packet filter that needs some of those holes poked. Good luck. In most situations, the FORWARD chain does not get such a rule, since the tunnel terminates at the gateway, which routes to a native IPv6 network, or another tunnel. Allowing tunnels through a gateway is almost always a bad thing, as it would allow undetected and untraceable traffic from compromised boxes in the local network. The OUTPUT chain also does not need such a rule, if you have configured stateful filtering properly. Now bring up the interface and verify the connection:

# ifup sixxs
# ping6 -nc1 2001:41e0:ff00:3b::1
PING 2001:41e0:ff00:3b::1(2001:41e0:ff00:3b::1) 56 data bytes
64 bytes from 2001:41e0:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]

Welcome to the Internet of the future!

Setting up an IPv6-capable gateway Your IPv6 connection works, but it s limited to a single address, and you do not get to specify the reverse DNS PTR record for it. Since the concept of NAT is mostly absent from IPv6 (thanks! thanks! thanks!), you will not be able to connect any other hosts to the IPv6 network. If your local network has a few hosts behind a gateway, you will need to request a subnet from SixXS and configure your gateway (which has the tunnel connection) appropriately. Don t worry, this is not really very difficult. First, request a subnet for your tunnel from your PoP via your SixXS homepage. Once approved, you will get a /48 prefix for your own use: 2^80 1.2 heptillion addresses which are yours to assign to every dust particle in your office or home, if you so desire. The way I set it up is to add the first of these addresses to your internal interface on the gateway, by adding the following two lines to the interface s stanza in /etc/network/interfaces; you will need the iproute package installed (which you should be using for everything network-related anyway):

up ip -6 addr add 2001:41e0:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:41e0:ff12::1/64 dev $IFACE

Instead of bringing the interface down and up, just run

ip
-6 addr add 2001:41e0:ff12::1/64 dev eth0

. Note the use of the /64 prefix instead of the /48 that got assigned, leaving only 20 pentillion addresses. Oh no! The reason for this is buried in the specs: basically, /48 is a site prefix, but individual networks should not be larger than /64, which is the prefix length of links in the IPv6 domain. Now is also a good time to enable IPv6 forwarding, e.g. like so:

# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p /etc/sysctl.conf

Obviously, you will also need to change the policy on the ip6tables FORWARD chain. For now, let s just set it to accept. You should later create a proper ruleset, though!

# ip6tables -I FORWARD -j ACCEPT

Bringing IPv6 to your local network The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines. On the gateway, you need to install radvd and simply tell it which prefix to use on which interface. My /etc/radvd looks like this, and I won t explain it:

interface eth0
 
  AdvSendAdvert on;
  prefix 2001:41e0:ff12::/64
   
   ;
 ;

Note again how we advertise a /64 network rather than the /48 we own . You cannot advertise smaller networks if you want automatic configuration to work, and you should not use networks larger than /64 in any case. If 2^64 addresses are not enough for you, I trust you ll be able to figure out how to advertise another of your 65536 /64 prefixes in the /48 subnet to appropriate hosts. Restart radvd and run over to another host to witness how it automagically gets connected to the IPv6 network by scanning /var/log/kern.log and watching the output of ip -6 addr and ip -6 route. Try ping6ing from there! Find the dancing turtle! It should all work. If you don t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and ?wide-dhcpv6-server.

Resolving names Take note of the IPv6 address of each host. There s a way to determine it given the host s MAC address, but this is easier (ipv6calc is also useful). You might want to let your local DNS server know by adding AAAA records in parallel to the existing A records, and possibly even adding PTR entries. If you re serious about IPv6, you can tell SixXS to delegate reverse lookups for the IPv6 addresses to your DNS servers, but you ought to refrain from polluting the DNS namespace. Note that bind9-host provides an improved host tool, which fetches all kinds of information about names, not just the one single information configured as default:

% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.74
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.

Oh, and if you re really that curious about how IPv6 addresses are computed from MAC addresses, read RFC 2464. Basically, given a prefix 2001:41e0:ff1a:: and a MAC address aa:bb:cc:dd:ee:ff, the resulting IPv6 address is obtained by:

inserting ff:fe into the middle of the MAC address to yield aa:bb:cc:ff:fe:dd:ee:ff;
flipping the second lowest bit of the first octet to yield a8:bb:cc:ff:fe:dd:ee:ff;
removing the odd colons to yield a8bb:ccff:fedd:eeff, the EUI-64;
concatenating the prefix and this result to get 2001:41e0:ff1a::a8bb:ccff:fedd:eeff.

If you find your (Windows) IPv6 addresses changing all the time, you might be faced by privacy features .

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Mapping names to laptops Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network. I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:

override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;

add both IPv6 addresses as `AAAA` records to the laptop s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first;

set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now .

The second solution works for me for now, but I am interested in the third. In response to this document, Andreas Henriksson has suggested the replace the stateless configuration (`radvd`) with stateful configuration, using DHCPv6. I have yet to investigate this option. Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on `#ipv6`/`irc.freenode.org` for their help over the past few weeks, and all those who fed back comments in response to this document!

I had this crazy idea a few months ago which Joey's post about muscle memory reminded me of. For those not in the US, our keyboards have and ~ on the key to the left of 1. I prefer this key to be Esc. Long ago I simply swapped the two keys, but the original "Esc" key is always in some weird and inconsistent place and reaching for ~ became as annoying as reaching for Esc. (I suppose I might not care if I didn't use a unix shell or regular expressions or bit masks or...) So, noting that I mostly only wanted that key for ~, and not , I came up with the following (in xmodmap form):

keycode 49 = Escape asciitilde grave Escape

This means: if you just hit the key, it does the Right Thing (Esc, as if I were on a real unixy keyboard). If you hold Shift and press the key, it also does the Right Thing (~, as if I were on a PC). But what to do about , or Shift-Esc, which are no longer possible? We make them the alternate graphs (just old down AltGr. I think the xkb option to put this on right Alt is "grp:switch"). I honestly use those two infrequently enough that I don't care about having to remember the extra bucky. (I tend to type $(cmd) in the shell, and not cmd , because I use the former in scripts and I always found the latter harder to read. I suppose I would care more if I used Lisp or Haskell or...) What I like most about this solution is that it lets me use the same muscle memory on all my hardware. Never mind weird Esc positions; laptop vendors still can't agree on the correct order of Fn and Control. But you don't have to care if you put Control on Caps Lock. Same idea. It does feel a bit like cheating, but it has made my wrists far more comfortable. Oh, and to wean myself off the key way out in the corner:

keycode 9 = NoSymbol

Now the question, of course (getting back to Joey), is what would happen if my "new" Escape key broke. I guess I'd have to keep the laptop at home and plug in my Happy Hacking Keyboard :-)

In evaporation, the more energetic (i.e. warmer) a water molecule on the surface of an object is, the higher its chance of it turning to vapour. The higher the wind speed across this surface, the faster these warm molecules will be blown away. This is the concept of evaporative cooling. The same applies when a company starts to fail, though there is an additional feedback cycle which compounds the problem. First, the most energetic ~~molecules~~ staff depart. These are the ones who can see a future for themselves outside of their current employment — and there is a high correlation between these people and those who are most valuable for an organisation. So the company becomes slightly worse due to the better people leaving. But it’s an exponential effect: it will rapidly get worse unless steps are taken to improve things. Eventually, the company stagnates as all of the interesting and innovative people have found alternative employment and only the boring ones are left. So, the moral of the story: the more a company blows, the faster its employees leave.

Okay, I will again miss DebConf. This time it is not because of time, but because of money. The flight to Buenos Aires is far too expensive to go there just for DebConf and I didn't manage to plan some more travelling around South America... Hopefully it will get better next year, at least DebConf will be much closer :-). PS: Just after deadline for confirmation and my decision for not going there, I got an email that my sponsorship for travel was approved. Unfortunately too late to change my decision.

As the title says - the Ftpmaster dak repository is now using git instead of bzr. I never did like bzr, so I recently asked what the rest of the team thinks of switching to git. Luckily I got no objections, so here we are, with a VCS thats not dead-slow. If you want to do dak development and submit patches you want to read my post to the debian-dak list and then clone the git repo. Sorry, there is no git-daemon support, you need to use the http way if you do not have access to ries. Unfortunately debian-admin thinks git-daemon isn’t good enough to run on ftp-master and that “http is enough”. Bah. (No, I won’t work around it (git-daemon uses high-port, so could be run without admin help, but NO WAY), and I don’t want to put it on alioth). The actual conversion of the repository was done by Dato, with me commenting and asking for stuff. Like the fixup of the old revisions committer names, so all the old CVS revisions now correctly tell the full name/email of the committer, not just the unix login. Or fixing all the bzr commits done by “ajt@ries”, “joerg@ries” and other broken combinations of “login@machine”. I also use his git hook to send commit mails to get commits mailed to the debian-dak lists. [Update] Nice, with the setup we use we found a bug in git. Ha. (a stupid issue with git shared repositories, and reflogs enabled at the same time that basically means you cant commit as the logs got the wrong permissions set whenever someone else did an action, like git gc.) Comments: 2

There has been a lot of talk recently about the cost of petrol, Colin Charles is one of the few people to consider the issue of wages in this discussion [1]. Unfortunately almost no-one seems to consider the overall cost of running a vehicle. While I can’t get the figures for Malaysia (I expect Colin will do that) I can get them for Australia. First I chose a car that’s cheap to buy, reasonably fuel efficient (small) and common (cheap parts from the wreckers) - the Toyota Corolla seemed like a good option.

A search on www.drive.com.au shows adverts for Corollas made in 1990 and 1991 for prices ranging from $3000 to $5000. Assuming some optimism on behalf of the advertisers I could probably buy one for about $2500. The current term deposit rate from the major Australian banks is just over 8%, so spending $2500 on a car (instead of having the money in a term deposit) means a loss of $200 per annum interest, if instead the car was purchased with a bank loan the rate would be significantly higher (car loans have quite high interest rates). Of course the real cost is whenever you sell a car and buy a newer one that costs more - but this is harder to estimate. The next issue is insurance, for a 1990 Corolla of the smallest engine size (as a rule of thumb the smaller the engine the smaller the insurance bill) comprehensive insurance (sans optional extras such as windscreen protection) would cost me $489 per annum, and third-party fire and theft would cost me $398. Of course those rates are for someone who is more than 25 years old and has a good driving record. The majority of people who “flip burgers” appear to be younger than 25 and would therefore pay more. Car registration starts at about $550 per annum (varies by state). Car service would cost at least $200 a year (for scheduled services). So it seems that the cost of a cheap car is around $1,350 per annum before you even drive it! Now with a car that’s 18 years old you have to expect that some parts are wearing out, including parts that make it unroadworthy and must be replaced. Assuming that $300 per annum is spent on parts and labor to repair parts that wear out seems quite conservative (especially if driving a car that costs less than $3,000 - one of the cheaper cars in that age range). That brings the total cost per year to $1,650 if you are lucky (if unlucky then expensive parts could wear out at financially inconvenient times). The amount of driving that I do is around 5,000 to 7,000km per annum (according to the ABS the average passenger vehicle was driven 14,100Km in 2005 [2]). Assuming 7.5L/100Km (one of the results that has been quoted for fuel efficiency of a car of that age) and 7,000Km of driving that would be 525L of petrol per year, at $1.70 that is $892. So at current fuel prices when driving a small car for minimal distances (either for environmental or financial reasons) the cost of petrol may be about 35% of the vehicle operating cost. If driven for the average distance the fuel cost will be about 52% of the total vehicle operating cost (which is about $3,400) - which seems like a reasonable incentive to save fuel. If someone wants to advocate measures to make cars more affordable for poor people then the first thing to consider would be a reduction in the vehicle registration fees (which are a significant part of the vehicle operating costs). Another would be government incentives for car sharing schemes (see my previous post on car sharing for details on what is on offer in Melbourne at the moment [5]), $3,400 would give 340 hours (or more with the weekend deals) of driving a shared car (including fuel) at current prices. A shared car would not be suitable for driving to work but would be good for most other car use. Also it should be noted that share cars are new and have all the latest safety features - I really wouldn’t want to be involved in a crash while driving a 20yo car. Unlike the costs of registration etc for owning a car, all the costs of a shared car will be reduced if you use it less. The tax rate for someone earning $28,579.20 is $2,850 plus 30c for each $1 over $25,000 [3], which is $3,923.76, which leaves a total after tax income of $24,655.44. Someone working 40 hours a week on the minimum income who drives an average distance will spend about 14% of their after-tax income on their car if they have a small old car and were able to buy it without borrowing money. According to the ABS the median income is actually slightly lower than full-time work at the minimum wage [4]. So it seems that there are many people who are working part-time and earning less money than they would if they worked full-time at the minimum wage. So the question for Colin is, how does this compare to Malaysia? Is someone on a minimal income in Malaysia going to spend ~7% of their after-tax income on paying insurance, tax, and basic maintenance on a car without the additional expense of driving it? How does the cost of the basic car ownership compare to the cost of fuel in Malaysia?

[1] http://www.bytebot.net/blog/archives/2008/06/15/on-fuel-subsidies-and-earningspending-power

[2] http://www.abs.gov.au/AUSSTATS/abs%40.nsf/mediareleasesbyReleaseDate/66E24E957EB09229CA2571E10077D71D?OpenDocument

[3] http://www.ato.gov.au/individuals/content.asp?doc=/content/12333.htm&mnu=5053&mfp=001

[4] http://www.abs.gov.au/AUSSTATS/abs%40.nsf/7d12b0f6763c78caca257061001cc588/96e08af8f4178a45ca257306000d4fd4!OpenDocument

[5] http://etbe.coker.com.au/2008/04/13/car-sharing-in-melbourne/

Search Results: "nate"

26 June 2008

Edd Dumbill: My OSCON 2008 picks

Stefano Zacchiroli: firefox 3 un-ranting

25 June 2008

Biella Coleman: The Cultural Significance of Free Software

Clint Adams: Relaxation

24 June 2008

Romain Beauxis: ov51x-jpeg: a tale of hardware and kernel tricks..

Matthew Garrett: Intel power saving

23 June 2008

Obey Arthur Liu: Daniel Burrows on cwidget-gtk

Russell Coker: ISP Redundancy and Virtualisation

22 June 2008

Daniel Stone: intuition : multi-contributor vcs :: steak : gelato

21 June 2008

Marc 'Zugschlus' Haber: kbd seems to be the way to go

19 June 2008

Martin F. Krafft: IPv6 with Debian

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a `dom0` on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 `dom0` is reported to work, however.

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on `#ipv6`/`irc.freenode.org` for their help over the past few weeks, and all those who fed back comments in response to this document!

17 June 2008

Decklin Foster: Dealing with it

Andrew Stribblehill: Evaporative cooling and the job market

16 June 2008

Michal Čihař: No DebConf this year for me

Joerg Jaspert: ByeBye bzr, hello git

15 June 2008

Russell Coker: The Cost of Owning a Car

14 June 2008

Russell Coker: What is Appropriate Advertising?

Brice Goglin: Debian X.org notes - X.org in Lenny (and more)

13 June 2008

Theodore Ts'o: Learning how to communicate

David Welton: New "Jim" Maintainer

Search Results: "nate"

26 June 2008

25 June 2008

24 June 2008

23 June 2008

22 June 2008

21 June 2008

19 June 2008

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a dom0 on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 dom0 is reported to work, however.

Remaining issues Even though my IPv6 connectivity works, I have two remaining issues.

Sending larger amounts of data to the network I am experiencing a curious issue where outgoing ssh IPv6 connections time out and outgoing data transfers hiccup. I have yet to find out what s going on.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on #ipv6/irc.freenode.org for their help over the past few weeks, and all those who fed back comments in response to this document!

17 June 2008

16 June 2008

15 June 2008

14 June 2008

13 June 2008

Xen and IPv6 One drawback of switching to 2.6.24 is that you cannot run a `dom0` on that machine any longer, so by practical extension, you cannot connect it to the IPv6 network with a packet filter in place. Supposedly, running 2.6.24 instances on a 2.6.18 `dom0` is reported to work, however.

Credits Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar, and everyone on `#ipv6`/`irc.freenode.org` for their help over the past few weeks, and all those who fed back comments in response to this document!