Thanks to all the people at LCA2013 in Canberra; it was a blast! So good to see old friends and chat freely on what s hot and happening. Radia (known for STP, TRILL), Sir Tim (the web) and old friend Bdale (Debian, SPI, Freedom Box) were inspiring. As was Robert Llewellyn (Kryten, Red Dwarf), who was a complete pleasure he wandered back and talked for a while with the volunteer video crew. Hats off to Pia for organising the TBL tour, to Mary Gardner for being awarded the Rusty Wrench, and to the team from PLUG (Euan, Jason, Leon, Luke) who stepped up to help with the video team and to Paul who graciously accepted the help. Next up LCA2014 Perth! Y all come back now.. it s been a decade.

Review: Getting Started with Dwarf Fortress, by Peter Tyson

Publisher:	O'Reilly
Copyright:	May 2012
ISBN:	1-4493-1494-5
Format:	Trade paperback
Pages:	219

If you're unfamiliar with Dwarf Fortress, you're in good company. Most people are, even people who play video games regularly. It was heavily inspired by roguelike games: games such as Hack and Rogue and their more recent variations, which have been around since the 1970s and are still frequently played with simple character graphics on 2D maps. Dwarf Fortress even has a roguelike gameplay mode, but the core of the game (and the only part of the game covered in this book) is the fortress mode, where the player controls a band of dwarfs in an attempt to construct and maintain a fortress. All of this is done (by default, at least) in a simulated-text interface filled with a barrage of strange characters and symbols. A Dwarf Fortress game in progress is almost incomprehensible to the uninitiated. (There are graphical tile sets available, but all the illustrations in this book assume the default display mode.) Dwarf Fortress gains its cult popularity (sufficient to support the primary developer solely through voluntary donations; the game is free) from the incredible depth and richness of the world. Almost everything is modeled in startling detail, down to the individual items of clothing that each dwarf wears, their personalities and history, and a considerable part of the industrial lifecycle of any goods that the fortress needs to produce (such as food and all-important alcohol). That's where this book comes in. The game is so massive and involves so many variables, industries, needs, requirements, and perils that the first-time player is likely to see their first games collapse due to resource problems they have no idea how to address. Getting Started with Dwarf Fortress walks the player through the initial fortress setup, the resource cycles, and the fundamentals of the various parts of the game one has to monitor. The fact that this discussion takes over 200 pages should give you an idea of the depth of the game. I should stop here and warn that, similar to my RPG sourcebook reviews, I read this book somewhat against its intended purpose. I haven't played Dwarf Fortress and don't currently intend to. It's not quite my game type: I don't like open world construction games in which it's possible to lose (and thereby lose all the things that one has built). But the idea of the game, the way it's developed, and the fact that O'Reilly would publish a book about it is so delightfully strange that I wanted to get a feel for the game without investing the time required to learn it. Thankfully, while the book is designed to be a tutorial, it also does an excellent job at conveying the feel of a game. Getting Started with Dwarf Fortress is divided into eleven chapters. After a chapter of introduction, it goes over site selection, some of the options for your initial party, and recommended settings for both. It then provides some advice for the initial rooms and initial fortress layout to get started. Subsequent chapters are more topic-oriented, covering food, merchants, resource management (including Strange Moods), digging, and the various chains of industry. The final chapters cover some of the more intricate details of dwarven life, such as justice, vampires, and hospitals, and then provide an introduction to the military and to dwarven engineering. The engineering chapter, in particular, makes it clear that vast complexity and possibility is left unexamined. One drawback of the printed version of the book (I don't know if this also applies to the ebook) is that all of the screen shots here are black and white. This makes Dwarf Fortress's already-forbidding presentation even more difficult to understand. At times, I had a hard time picking out features that were described in the text. A look at on-line screenshots quickly shows that color is massively helpful in making sense of all the little glyphs. I'm sure color printing would have made the printed version prohibitively expensive, but it is a loss. The text, though, is excellent. Not only is it clear and helpful (although with the caveat that I've not personally tested it), it captures much of the humor and feel of the game. Dwarf Fortress incorporates computer-generated storytelling that narrates the events of the game (and the backstory of the world), which has sparked a tradition of delightfully wry commentary on games, game mechanics, and events in the game (particularly the ones that cause the cascading destruction of the whole fortress). Tyson captures that tone brilliantly, weaving it throughout his descriptions. This is a tutorial that's genuinely fun to read. (Although the Tim Denee comics ending chapters sadly didn't work for me.) It's certainly possible to get started with Dwarf Fortress without this book. There are other tutorials on-line, as well as an impressively huge wiki. But this is a great introduction and is entertainment in its own right. If you've thought about playing the game, or if, like me, you want a good feel for what it's like without investing the time in actually playing it, I recommend it. I should probably note that this book covers Dwarf Fortress up to 0.34.07, and the dead tree version that I have obviously won't be further updated. O'Reilly does note on the back cover that if you purchase the ebook edition, it will receive free updates for the "life of the edition" (however long that is). If you're worried about subsequent changes in the game making the book obsolete (given the ongoing active development, this is something of a worry, although this book mostly covers fundamentals), you may want to grab the electronic version. Rating: 8 out of 10

When I told people of my plans to move to Montreal, it usually prompted one of two reactions: one was some version of joyful envy, many people exclaiming breathlessly Montreal is one of my favorite cities, one person once even clutching my arm and told me as he looked me straight in the eye: you are so lucky, there is no city quite like Montreal in North America. The second reaction came off as a thinly veiled mixture of disdain and disbelief usually peppered with many reallys: oh wow, really, really you would really leave NYC? I am pretty certain they really were thinking something along the lines of what a fool, how dare she leave a great job, a great university, a world class city (the only city to live) for some Canadian mid-sized city, which is like tundra for a good chunk of the year? The decision to move weighed heavily on me, if for no other reason I had a choice to stay or to go and I honestly have not had a choice, a decision to make about where to go since I got accepted to graduate school (and even then the choice was more obvious than this one). So over a month into my move what is my verdict? In a word, win. I don t miss NYC at all though I get why some people cannot leave the place and know that despite some oddities and difficulties of living in Montreal, it fits my tastes and needs much better than NYC which dwarfed me in so many ways. I never felt I could enjoy it, I grew tired of the cramped living quarters, the noise ate at my soul, and I simply felt more overwhelmed by the fact that I could not even get a handle on the neighborhoods in my vicinity, much less all the other hoods in the area. Instead of dogging NYC anymore, I think I will spend a little time on first impressions, as they will soon be lost to the familiarity borne with time and experience. In essence Montreal is chock full of life but rather intimate, a quirky city with lots of charm but some grit and lacking the way over designed and done feel of cities like Portland. Here are some of quirks: 1. The Hawt Metro: I fell in love with the Metro when I first rode it a few years ago. I just love the powder blue color of the cars and the super sweet 1960s aesthetic of many stations. Even better and unlike NYC, they are just clean and quiet. The downside? The temperatures approximates a sauna during the winter and while you would think this is a good thing, when you are layered with the clothing necessary to survive outside (re: long underwear along with Canada-coat, gloves, hat, and scarf), it is hooooooot down there and you feel like you need to pass out. 2. Spend money, get free stuff: In many establishments you get free stuff (like blueberries or some like sports bar) when you spend over a certain amount of money, like 70 bucks. Quirky local tradition. 3. The culture of negotiation and the kick ass standard lease: Housing is amazing here. There is plenty of it, there are many different styles, and it is rather fun exploring all the different hoods that make up the city. Problem is too that lots of apartments have weird problems and issues and I had to steer clear of anything that could even possibly have mold. I spent weeks day in day out looking for a place, desperate to move out of my corporate apartment very nicely provided by the university but still not my ideal living situation. Finally found a place that fit all my needs in the perfect location and I took it to only find out that places are priced to negotiate and I was faced with the decision to negotiate or not. Sort of did, was not thrilled about it (thinking that I might lose the place) but it sort of worked and I scored the place. If price is up to haggling, the lease on the other hand, is standard (you can buy one at your local bodega ). It is the law to use it and it is like a no nonsense, straightforward lease, which is very protective of renters. 4. Montreal is known for its exceptional food but you know Poutine is just plain gross: Food here is good and I can tell that I will get a handle of restaurants in a way that felt impossible in NYC. The gluten free religion seems to be spreading, thankfully. There are many little Fruiterias! to get your fruits veggies which I am still exploring and right around my house is a crazy supermarket that is so cheap, which is weird because consumer goods generally ain t cheap in Montreal like they are in the states but this place is a gem and everyone agrees (and almost impossible to notice from the street!). Now Poutine is disgusting. Ok it did not help that the first night I went out to eat it, I was still under the clutches of Noro virus, and I think it re-activated the nausea that had been zapped by some strong medicine and the hospital, the day before, which brings me to the next point, the health care system. 5. Healthcare, I had to use it way too early: So last week I came down with the Noro virus and you usually wait it out as it runs through you quickly but I was dehydrated before I even started to vomit to for 8 hours straight, at which point severely tired and so nauseous (I was yelling to make it stop), I went to the hospital. Now I had talked to lot of people about the healthcare system in Montreal as it seems good, really great but a bit over taxed, especially compared to where I had lived in Edmonton where it was like a magic fairy tale dream. I had heard of two things: the care is excellent but the facilities are shocking and the wait times unless dire can be atrociously long. So facilities, yea they are kinda shocking, somewhat shabby but who cares, so long as the care is good, no? Packaging is irrelevant so long as the goods are derived. Before going I was scared of the long wait times (and also the taxi took me by mistake to Montreal General Hospital was looked too much like a HUGE version of the creepy buildings in The Shining for me, and I was supposed to go to Jewish General so left for there). The wait time: nearly none, somewhat as shocking as the facilities first looked to me. I think it was a combination of the time I arrived, with the fact that my lounge was parched and yellowish-gross (sorry, it was gross), indicating I was dehydrated, oh and I was crying bit hysterically, for despite my high threshold for pain, nausea terrorizes me. I was covered by insurance and since I did not yet have my McGill health cards (it takes three months to qualify for the local stuff), I did pay and the price was laughably cheap compared to what I would pay in NYC for the same treatment. 6. Now for my favorite, snow so nice, ice oh Christ: Well this winter has been, by all accounts, weak and warm, the spirit of winter barely making its way from the underworld to the outerworld. But even though it is has been more idle than full throttle, I still got a pretty accurate taste of what winter is like, with a few days of 20- c temps, and having to walk a number of times on a layer of frozen ice that makes it feel like a very dangerous mini-ice age in the making. I do rather love the quiet snow falling and just love love sprinting through the snow with my dog, Roscoe, who has taken a liking for prancing in the white stuff and looks awful cute with his winter man s ice beard. After a sizable snowfall, it is clear they city does not toy with the snow removal although the sidewalk snow plows do look somewhat like very large and dangerous but kinda cute toys. But let s be frank, winters are hard, so hard that I think I would go mad if I had to stay through the entire thing, being born and raised in the tropics So the fact that I am writing this from the southern hemisphere in the height of summer gives me the assurance I can handle the rest of the snow, ice, ice and snow upon my return.

#### [WATER FRACTIONS IN EXTRASOLAR PLANETESIMALS](http://arxiv.org/PS_cache/arxiv/pdf/1110/1110.1774v1.pdf) #### Jura & Xu, Arxiv.org. #exoplanets, #water, #phd > Abstract: With the goal of using externally-polluted white dwarfs to investigate the water fractions of extrasolar planetesimals, we assemble from the literature a sample that we estimate to be more than 60% complete of DB white dwarfs warmer than 13,000 K, more luminous than 3 10 3 L and within 80 pc of the Sun. When considering all the stars together, we find the summed mass accretion rate of heavy atoms exceeds that of hydrogen by over a factor of 1000. If so, this sub-population of extrasolar asteroids treated as an ensemble has little water and is at least a factor of 20 drier than CI chondrites, the most primitive meteorites. In contrast, while an apparent excess of oxygen in a single DB can be interpreted as evidence that the accreted material originated in a water-rich parent body, we show that at least in some cases, there can be sufficient uncertainties in the time history of the accretion rate that such an argument may be ambiguous. Regardless of the difficulty associated with interpreting the results from an individual object, our analysis of the population of polluted DBs provides indirect observational support for the theoretical view that a snow line is important in disks where rocky planetesimals form. Ok, so we now have a way of estimating how wet planetary systems *were*, at the time they fell into the white dwarf star. Not very representative of the time they before the planet got roasted to a crisp by the stars Red Giant stage, however. Recovering the hydrogenation state of serpentinized minerals might be possible and useful.

Some years ago I came across a really peculiar newsgroup post. It was not about technicalities of any sort. It was about history. A beautifully written history of computers. From the Turing machine to the Free Software world, the original author managed to capture all the important events of the computer revolution with a great deal of humor. Re-posting it here, it is just brilliant. The Gospel of Tux (v1.0) In the beginning Turing created the Machine. And the Machine was crufty and bodacious, existing in theory only. And von Neumann looked upon the Machine, and saw that it was crufty. He divided the Machine into two Abstractions, the Data and the Code, and yet the two were one Architecture. This is a great Mystery, and the beginning of wisdom. And von Neumann spoke unto the Architecture, and blessed it, saying, Go forth and replicate, freely exchanging data and code, and bring forth all manner of devices unto the earth. And it was so, and it was cool. The Architecture prospered and was implemented in hardware and software. And it brought forth many Systems unto the earth. The first Systems were mighty giants; many great works of renown did they accomplish. Among them were Colossus, the codebreaker; ENIAC, the targeter; EDSAC and MULTIVAC and all manner of froody creatures ending in AC, the experimenters; and SAGE, the defender of the sky and father of all networks. These were the mighty giants of old, the first children of Turing, and their works are written in the Books of the Ancients. This was the First Age, the age of Lore. Now the sons of Marketing looked upon the children of Turing, and saw that they were swift of mind and terse of name and had many great and baleful attributes. And they said unto themselves, Let us go now and make us Corporations, to bind the Systems to our own use that they may bring us great fortune. With sweet words did they lure their customers, and with many chains did they bind the Systems, to fashion them after their own image. And the sons of Marketing fashioned themselves Suits to wear, the better to lure their customers, and wrote grave and perilous Licenses, the better to bind the Systems. And the sons of Marketing thus became known as Suits, despising and being despised by the true Engineers, the children of von Neumann. And the Systems and their Corporations replicated and grew numerous upon the earth. In those days there were IBM and Digital, Burroughs and Honeywell, Unisys and Rand, and many others. And they each kept to their own System, hardware and software, and did not interchange, for their Licences forbade it. This was the Second Age, the age of Mainframes. Now it came to pass that the spirits of Turing and von Neumann looked upon the earth and were displeased. The Systems and their Corporations had grown large and bulky, and Suits ruled over true Engineers. And the Customers groaned and cried loudly unto heaven, saying, Oh that there would be created a System mighty in power, yet small in size, able to reach into the very home! And the Engineers groaned and cried likewise, saying, Oh, that a deliverer would arise to grant us freedom from these oppressing Suits and their grave and perilous Licences, and send us a System of our own, that we may hack therein! And the spirits of Turing and von Neumann heard the cries and were moved, and said unto each other, Let us go down and fabricate a Breakthrough, that these cries may be stilled. And that day the spirits of Turing and von Neumann spake unto Moore of Intel, granting him insight and wisdom to understand the future. And Moore was with chip, and he brought forth the chip and named it 4004. And Moore did bless the Chip, saying, Thou art a Breakthrough; with my own Corporation have I fabricated thee. Thou thou art yet as small as a dust mote, yet shall thou grow and replicate unto the size of a mountain, and conquer all before thee. This blessing I give unto thee: every eighteen months shall thou double in capacity, until the end of the age. This is Moore s Law, which endures unto this day. And the birth of 4004 was the beginning of the Third Age, the age of Microchips. And as the Mainframes and their Systems and Corporations had flourished, so did the Microchips and their Systems and Corporations. And their lineage was on this wise: Moore begat Intel. Intel begat Mostech, Zilog and Atari. Mostech begat 6502, and Zilog begat Z80. Intel also begat 8800, who begat Altair; and 8086, mother of all PCs. 6502 begat Commodore, who begat PET and 64; and Apple, who begat 2. (Apple is the great Mystery, the Fruit that was devoured, yet bloomed again.) Atari begat 800 and 1200, masters of the game, who were destroyed by Sega and Nintendo. Xerox begat PARC. Commodore and PARC begat Amiga, creator of fine arts; Apple and PARC begat Lisa, who begat Macintosh, who begat iMac. Atari and PARC begat ST, the music maker, who died and was no more. Z80 begat Sinclair the dwarf, TRS-80 and CP/M, who begat many machines, but soon passed from this world. Altair, Apple and Commodore together begat Microsoft, the Great Darkness which is called Abomination, Destroyer of the Earth, the Gates of Hell. Now it came to pass in the Age of Microchips that IBM, the greatest of the Mainframe Corporations, looked upon the young Microchip Systems and was greatly vexed. And in their vexation and wrath they smote the earth and created the IBM PC. The PC was without sound and colour, crufty and bodacious in great measure, and its likeness was a tramp, yet the Customers were greatly moved and did purchase the PC in great numbers. And IBM sought about for an Operating System Provider, for in their haste they had not created one, nor had they forged a suitably grave and perilous License, saying, First we will build the market, then we will create a new System, one in our own image, and bound by our Licence. But they reasoned thus out of pride and not wisdom, not forseeing the wrath which was to come. And IBM came unto Microsoft, who licensed unto them QDOS, the child of CP/M and 8086. (8086 was the daughter of Intel, the child of Moore). And QDOS grew, and was named MS-DOS. And MS-DOS and the PC together waxed mighty, and conquered all markets, replicating and taking possession thereof, in accordance with Moore s Law. And Intel grew terrible and devoured all her children, such that no chip could stand before her. And Microsoft grew proud and devoured IBM, and this was a great marvel in the land. All these things are written in the Books of the Deeds of Microsoft. In the fullness of time MS-DOS begat Windows. And this is the lineage of Windows: CP/M begat QDOS. QDOS begat DOS 1.0. DOS 1.0 begat DOS 2.0 by way of Unix. DOS 2.0 begat Windows 3.11 by way of PARC and Macintosh. IBM and Microsoft begat OS/2, who begat Windows NT and Warp, the lost OS of lore. Windows 3.11 begat Windows 95 after triumphing over Macintosh in a mighty Battle of Licences. Windows NT begat NT 4.0 by way of Windows 95. NT 4.0 begat NT 5.0, the OS also called Windows 2000, The Millenium Bug, Doomsday, Armageddon, The End Of All Things. Now it came to pass that Microsoft had waxed great and mighty among the Microchip Corporations; mighter than any of the Mainframe Corporations before it had it waxed. And Gates heart was hardened, and he swore unto his Customers and their Engineers the words of this curse: Children of von Neumann, hear me. IBM and the Mainframe Corporations bound thy forefathers with grave and perilous Licences, such that ye cried unto the spirits of Turing and von Neumann for deliverance. Now I say unto ye: I am greater than any Corporation before me. Will I loosen your Licences? Nay, I will bind thee with Licences twice as grave and ten times more perilous than my forefathers. I will engrave my Licence on thy heart and write my Serial Number upon thy frontal lobes. I will bind thee to the Windows Platform with cunning artifices and with devious schemes. I will bind thee to the Intel Chipset with crufty code and with gnarly APIs. I will capture and enslave thee as no generation has been enslaved before. And wherefore will ye cry then unto the spirits of Turing, and von Neumann, and Moore? They cannot hear ye. I am become a greater Power than they. Ye shall cry only unto me, and shall live by my mercy and my wrath. I am the Gates of Hell; I hold the portal to MSNBC and the keys to the Blue Screen of Death. Be ye afraid; be ye greatly afraid; serve only me, and live. And the people were cowed in terror and gave homage to Microsoft, and endured the many grave and perilous trials which the Windows platform and its greatly bodacious Licence forced upon them. And once again did they cry to Turing and von Neumann and Moore for a deliverer, but none was found equal to the task until the birth of Linux. These are the generations of Linux: SAGE begat ARPA, which begat TCP/IP, and Aloha, which begat Ethernet. Bell begat Multics, which begat C, which begat Unix. Unix and TCP/IP begat Internet, which begat the World Wide Web. Unix begat RMS, father of the great GNU, which begat the Libraries and Emacs, chief of the Utilities. In the days of the Web, Internet and Ethernet begat the Intranet LAN, which rose to renown among all Corporations and prepared the way for the Penguin. And Linus and the Web begat the Kernel through Unix. The Kernel, the Libraries and the Utilities together are the Distribution, the one Penguin in many forms, forever and ever praised. Now in those days there was in the land of Helsinki a young scholar named Linus the Torvald. Linus was a devout man, a disciple of RMS and mighty in the spirit of Turing, von Neumann and Moore. One day as he was meditating on the Architecture, Linus fell into a trance and was granted a vision. And in the vision he saw a great Penguin, serene and well-favoured, sitting upon an ice floe eating fish. And at the sight of the Penguin Linus was deeply afraid, and he cried unto the spirits of Turing, von Neumann and Moore for an interpretation of the dream. And in the dream the spirits of Turing, von Neumann and Moore answered and spoke unto him, saying, Fear not, Linus, most beloved hacker. You are exceedingly cool and froody. The great Penguin which you see is an Operating System which you shall create and deploy unto the earth. The ice-floe is the earth and all the systems thereof, upon which the Penguin shall rest and rejoice at the completion of its task. And the fish on which the Penguin feeds are the crufty Licensed codebases which swim beneath all the earth s systems. The Penguin shall hunt and devour all that is crufty, gnarly and bodacious; all code which wriggles like spaghetti, or is infested with blighting creatures, or is bound by grave and perilous Licences shall it capture. And in capturing shall it replicate, and in replicating shall it document, and in documentation shall it bring freedom, serenity and most cool froodiness to the earth and all who code therein. Linus rose from meditation and created a tiny Operating System Kernel as the dream had foreshewn him; in the manner of RMS, he released the Kernel unto the World Wide Web for all to take and behold. And in the fulness of Internet Time the Kernel grew and replicated, becoming most cool and exceedingly froody, until at last it was recognised as indeed a great and mighty Penguin, whose name was Tux. And the followers of Linus took refuge in the Kernel, the Libraries and the Utilities; they installed Distribution after Distribution, and made sacrifice unto the GNU and the Penguin, and gave thanks to the spirits of Turing, von Neumann and Moore, for their deliverance from the hand of Microsoft. And this was the beginning of the Fourth Age, the age of Open Source. Now there is much more to be said about the exceeding strange and wonderful events of those days; how some Suits of Microsoft plotted war upon the Penguin, but were discovered on a Halloween Eve; how Gates fell among lawyers and was betrayed and crucified by his former friends, the apostles of Media; how the mercenary Knights of the Red Hat brought the gospel of the Penguin into the halls of the Corporations; and even of the dispute between the brethren of Gnome and KDE over a trollish Licence. But all these things are recorded elsewhere, in the Books of the Deeds of the Penguin and the Chronicles of the Fourth Age, and I suppose if they were all narrated they would fill a stack of DVDs as deep and perilous as a Usenet Newsgroup. Now may you code in the power of the Source; may the Kernel, the Libraries and the Utilities be with you, throughout all Distributions, until the end of the Epoch. Amen.

DWARF-2 is a format to store debugging information. It is used on many ELF systems such as GNU/Linux. With the way things are compiled, there is a lot of redundant information in the DWARF-2 sections of an ELF binary. Fortunately, there is an option to gcc that helps dealing with the redundant information and downsizes the DWARF-2 sections of ELF binaries. This option is -feliminate-dwarf2-dups. Unfortunately, it doesn t work with C++. With -g alone, libxul.so is 468 MB. With -g -feliminate-dwarf2-dups, it is 1.5 GB. FAIL. The good news is that as stated in the message linked above, -gdwarf-4 does indeed help reducing debugging information size. libxul.so, built with -gdwarf-4 is 339 MB. This however requires gcc 4.6 and a pretty recent gdb.

Some updates. My gnash pledge to raise money for the project is going well. The lower limit of 10 signers was reached in 24 hours, and so far 13 people have signed it. More signers and more funding is most welcome, and I am really curious how far we can get before the time limit of December 24 is reached. :) On the #gnash IRC channel on irc.freenode.net, I was just tipped about what appear to be a great code coverage tool capable of generating code coverage stats without any changes to the source code. It is called kcov, and can be used using kcov <directory> <binary>. It is missing in Debian, but the git source built just fine in Squeeze after I installed libelf-dev, libdwarf-dev, pkg-config and libglib2.0-dev. Failed to build in Lenny, but suspect that is solvable. I hope kcov make it into Debian soon. Finally found time to wrap up the release notes for a new alpha release of Debian Edu, and just published the second alpha test release of the Squeeze based Debian Edu / Skolelinux release. Give it a try if you need a complete linux solution for your school, including central infrastructure server, workstations, thin client servers and diskless workstations. A nice touch added yesterday is RDP support on the thin client servers, for windows clients to get a Linux desktop on request.

The Exoclimes conference ended on an interesting perennial problem: what should we call these things we work on? The climate folks pointed out what the astronomers have grown used to: the telephone numbers we use as planet names. The two most studied Hot Jupiters, for example, are HD209458b and HD189733b. Come on, we could do better than that. In fact the naming worries started earlier when Frank Selsis asked people to avoid calling the planets he works on "super-Earths" (or should that be Super-Earths?). Dimitar Sasselov had accidentally kicked up a kerfuffle in the media a few weeks back by calling them "Earth-like" planets, when he meant "Earth-sized" planets. Selsis pointed out non-scientists will interpret "super-Earth" to mean "like Earth, only Better!", when we mean its just a bigger ball of rock and ice than Earth. But what to call them? Well, at least one planet already has a name, sort of: HD 209458b is frequently called 'Osiris'. And there is a published list of possible planet names. But Osiris the Egyptian god is more famous than Osiris the planet, confusing google. And people are going to assume things based on the planet names: are we really going to name a planet Vulcan? One suggestion was that if we found a system with seven planets we could call them after the Seven Dwarfs, but this was ruled out: don't mention the war (but dwarfs could also mean brown dwarfs!) At the end of the conference, there was show of hands: who agreed with naming planets? of about 100 present, all in favour, none against. The delegate to the IAU commision on the matter, which had voted against, duly noted. Perhaps we will name them then. Tags names, exoplanets, astronomy

The systemd projecct is an interesting concept for replacing init and related code [1]. There have been a few attempts to replace the old init system, upstart is getting some market share in Linux distributions and Solaris has made some interesting changes too. But systemd is more radical and offers more benefits. While it s nice to be able to start multiple daemons at the same time with dependencies and doing so offers improvements to the boot times on some systems that really doesn t lead to optimal boot times or necessarily correct behavior. Systemd is designed around a similar concept to the wait option in inetd where the service manager (formerly inetd and now the init that comes with systemd) binds to the TCP, UDP, and Unix sockets and then starts daemons when needed. It apparently can start the daemons as needed which means you don t have a daemon running for months without serving a single request. It also implements some functionality similar to automount which means you can start a daemon before a filesystem that it might need has been fscked. This means that a large part of the boot process could be performed in reverse. The current process is to run fsck on all filesystems, mount them, run back-end server processes such as database servers and then run servers that need back-end services (EG a web server using a database server). The systemd way would be for process 1 to listen on port 80 and it could then start the web server when a connection is established to port 80, start the database server when a connection is made to the Unix domain socket, and then mount the filesystem when the database server tries to access it s files. Now it wouldn t be a good idea to start all services on demand. Fsck can take hours on some filesystems and is never quick at the best of times. Starting a major daemon such as a database server can also take some time. So a daemon that is known to be necessary for normal functionality and which takes some time to start could be started before a request comes in. As fsck is not only slow but usually has little scope for parallelisation (EG there s no point running two instances of fsck when you only have one hard disk), so hints as to which filesystem to be checked first would need to be used. Systemd will require more SE Linux integration than any current init system. There is ongoing debate about whether init should load the SE Linux policy, Debian has init loading the policy while Fedora and Ubuntu have the initramfs do it. Systemd will have to assign the correct SE Linux context to Unix domain socket files and listening sockets for all the daemons that support it (which means that the policy will have to be changed to allow all domains to talk to init). It will also have to manage dbus communication in an appropriate way which includes SE Linux access controls on messages. These features mean that the amount of SE Linux specific code in systemd will dwarf that in sysvinit or Upstart which among other things means that it really wouldn t make sense to have an initramfs load the policy. They have a qemu image prepared to demonstrate what systemd can do. I was disappointed that they prepared the image with SE Linux disabled. All I had to do to get it working correctly was to run the command chcon -t init_exec_t /usr/local/sbin/systemd and then configure GRUB to not use selinux=0 on the kernel command line. Another idea is to have systemd start up background processes for GUI systems such as KDE and GNOME. Faster startup for KDE and GNOME is a good thing, but I really hope that no-one wants to have process 1 manage this! Having one copy of systemd run as root with PID 1 to start daemons and another copy of the same executable run as non-root with a PID other than 1 to start user background processes is the current design which makes a lot of sense. But I expect that some misguided person will try to save some memory by combining two significantly different uses for process management.

• [1] http://0pointer.de/blog/projects/systemd

Dear Lazyweb, In my newest project I need to use Fortran routines and variables in C. From the source code point of view this requires only to declare the needed Fortran entities in your C code whilst taking the right types of the variables and the name mangling of the Fortran compiler into account. Here is an example. Consider you have the following Fortran code: To use the array v and the subroutine Foo() in C, you need to add (something like) the following declarations to your C source code: If only a handful of Fortran routines are needed to be called from C, declaring them by hand may be feasible. This is however error-prone and becomes impracticable for more than a handful of routines. Especially if the routine signatures change frequently. So what I d like to have is a tool that generates a C header file containing all declarations of Fortran entities from a given Fortran source file. Or if such tool does not exist, a tool that extracts variable declarations and routine signatures from a Fortran source file into a format that is easier to parse than Fortran itself would also be helpful. Any suggestions?

Then they stopped, and Thorin muttered something about supper, and where shall we get a dry patch to sleep on? Not until then did they notice Gandalf was missing. So far he had come all the way with them, never saying if he was in the adventure or merely keeping them company for a while. He had eaten most, talked most, and laughed most. But now he simply was not there at all! Just when a wizard would have been most useful, too, groaned Dori and Nori (who shared the hobbit s views about regular meals, plenty and often).

- J.R.R. Tokien, The Hobbit

I am very fond of the works of J.R.R. Tolkien; it would not surprise me to find that many of you recognize these words from the second chapter of The Hobbit titled Roast Mutton . It occurred to me recently that there are parallels between Gandalf s role in The Hobbit and that of an Agile coach. Now, before my fellow Tolkien enthusiasts leap on their keyboards, bear with me on this. Know that I am not saying an Agile coach is on par with a wizard (OK, with one of the Istari sent by the Valar, but let s table that so as not to scare off the normal folk, alright?); that should be enough to calm you down. In the excerpt from The Hobbit at the top of the page, Bilbo and the dwarves have run into their first predicament. Note that it s not a particularly difficult situation; they just need to find shelter and partake of some food. Fire would be nice, too, if it could be managed. (Mind you, it s the first day of their journey; they set off mere hours ago fully provisioned and riding on ponies.) It isn t very long before the fledgling group finds itself not only without shelter and food, but in the hands of three rather nasty trolls who are deciding how best to eat the entire group. Gandalf returns once things have gotten out of control, and with some subtle adjustments to the situation, the crisis is averted. Could Gandalf have come back sooner and spared them this entire experience? Perhaps, but in their struggle a few key things happened. First, the group had to work out how to assess tasks at hand and appropriately delegate. To their credit, that effort was partially successful. The most skilled firestarters were assigned to that task, one of the keen-eyed dwarves was assigned to be the lookout. Second, they gathered some field experience that led to the establishment of improved practices, i.e. don t leave the ponies laden with packs when you make camp, particularly if it s all your food. (They lost most of their food that night when the pony carrying it bolted and ran straight into a nearby river later that night.) Third, Bilbo Baggins was called upon to perform his first task as burglar, albeit a fool s errand that landed them in the troll predicament. While Bilbo was wildly under-equipped for his job, he managed to work through it. That experience began a developmental journey that would prepare him for the great things that would be expected of him later on. This was not Gandalf s first adventure, nor was it the first group of people he needed to equip and challenge in order to develop them to a point that they could accomplish their goal. At this point, he s been in Middle-Earth just shy of 2,000 years. He would have been more than capable of walking them through their entire journey, but to what end? Agile coaching is a discipline that aims to help teams develop their own use of methodologies like Scrum and cross-methodology practices like testing, user stories, etc. This means equipping teams with just enough information to strike out on their own for a bit, then letting them run with it rather than dazzle them with one s own mastery so as to appear like the indispensable demigod. Until people struggle with the terse maxims of Agile Software Development, they cannot internalize them. And when the wizard is always around, why bother struggling? One of my greatest frustrations as an Agile coach is how few companies are willing to take a coaching approach with their Agile adoption. They want you to come in and be the demigod as a full-time contractor. Sure, there are fiscal, political, and seemingly practical reasons that they will cite; I chalk most of them up to being excuses for a lack of willingness to embrace what it would take to face the hard task of nurturing what you have. It s seemingly easier to just throw more money at more bodies and hope that somehow things will all work out, and surely if you can stumble upon some superstar to wrangle the mess, you ll eventually be able to browbeat them into becoming a full-time employee. Don t get me wrong; in some ways, I benefit from this dysfunction. From a selfish business standpoint, having a single full-time client is certainly easier than juggling multiple concurrent clients and their schedules. As far as actually accomplishing the aim of my business, however, I think it hinders the mission. One of my aims in working with companies is to be a coach despite being brought in as a contractor. It s certainly possible, though it is more challenging. There s not that natural separation of the coach from the team that forces them to take up the mantle on their own. Few things in my work are more rewarding than having a developer come to me and say, I wasn t really sure this Agile stuff could work, but now, after going through all this, I wouldn t want to go back to the old way of doing things. Much later in the journey of the hobbit and his dwarf companions, Bilbo is again called upon for a challenging task. His response makes me think Gandalf s approach has worked:

Perhaps I have begun to trust my luck more than I used to in the old days he meant last spring before he left his own house, but it seemed centuries ago but anyway I think I will go and have a peep at once and get it over. Now who is coming with me?

- J.R.R. Tokien, The Hobbit

Here s hoping more people will be willing to embrace the challenging, messy, and altogether beneficial task of equipping teams and allowing them to struggle when necessary, even if it means the occasional scuffle with trolls.

I m still working with SLHA files and noticed that people are using C/C++, Fortran, or also Mathematica programs for batch manipulation and processing of SLHA files (for example for repeatedly increasing some parameters in a SLHA file, feeding this file to some program and reading its output). For someone experienced with the shell (no, not that shell) this sounds like an easy task doable in a few lines of shell code. There is however no simple way to manipulate SLHA files on the command line.
The script I m presenting in this post, slha-io.sh, tries to close that gap. Its description is:

This script is a very simple (and stupid) tool to get or set data in SLHA (SUSY Les Houches Accord) files. It can output complete blocks or individual data lines and replace existing data lines with user given input. It is stupid because it does not check after replacing data lines if the resultant file conforms to the SLHA. So care must be taken when using the set action.

But as so often, it is best described by examples. The basic things you can do with slha-io.sh are (MSSM.in is the SLHA file in these examples):

$ slha-io.sh MSSM.in get modsel
Block MODSEL            # Select model
 1    0                 # MSSM
 4    1                 # R-parity is violated
Block SMINPUTS          # Standard Model inputs
$ slha-io.sh MSSM.in get sminputs 6
 6   1.729000E+02       # m_top(pole)
$ slha-io.sh MSSM.in get sminputs 6   awk '  print $2  '
1.729000E+02
$ slha-io.sh MSSM.in set sminputs 6 \
  " 6   1.730000E+02       # m_top(pole)"
$ slha-io.sh MSSM.in get sminputs 6
 6   1.730000E+02       # m_top(pole)

Here is another example of using slha-io.sh to create a batch of files where a parameter is constantly increased from 70 to 80 in steps of 0.5:

for NUM in  seq -f "%.8E" 70 0.5 80 ; do
    FILE = "m0_$NUM.in"
    cp MSSM.in "$FILE"
    slha-io.sh "$FILE" set minpar 1 " 1  $NUM  # m0"
done

Maybe this script is useful for one or two! By the way, more sophisticated tools for SLHA I/O are SLHALib and SLHAio.

I was surprised to learn that Debian's apache2 package does not enable mod_deflate by default. This is the module which implements compression. Once enabled, I needed to add application/atom+xml to the configuration in order for it to apply to atom feeds (which are the most consistently fetched URI on my site generally, although right now the image from my last log post is in the lead by a huge margin). I'm not sure how much merit there is in compressing atom feeds. My primary one is 4.8k in size and compressed to roughly 1.6k at the time of writing. The difference in time for fetching those two sizes is dwarfed by connection setup/tear-down and possibly by the CPU time used for compression. I wonder if mod_deflate caches the compressed copies? Since my feed (and entire site) is statically generated by ikiwiki, I could generate compressed copies once at build-time. Perhaps apache2's content negotiation could be configured to serve these up.

From Today's Astronomy & Astrophysics there were two papers from the Geneva Observatory / Grenoble team on The HARPS search for southern extra-solar planets:

• XIII. A planetary system with 3 super-Earths (4.2, 6.9, and 9.2 M_e )
• XIV. Gl 176b, a super-Earth rather than a Neptune, and at a different period

These are probably part of the 45 super-Earths tentively announced by M. Mayor last June at the Nantes conference on super-Earths. He showed radial-velocity diagrams for 45 or so planets in an impressive display, but only gave details of three at the time, while the rest were being peer-reviewed, etc. Now they're drip-feeding out. Interestingly, this now makes 3 out of 7 super-Earths do far discovered as being around M dwarf stars, and another multiple planetary system. It looks more like the "metallicity" relation (larger and more frequent planets around more metallic stars) seems to be more true for gas giants than terrestrial planets. Super-Earths (potentially rocky planets, though heavier than Earth) look more abundant around low mass and less-metal stars. Now, down to work examining the characteristics of these planets. Rory Barnes and colleagues at LLPL, U. of Arizona have also been looking at these three planets around HD 40307, to determine if they are super-Earths or mini-Neptunes. They have an interesting technique of modelling the tidal circularisation of the planet backwards in time, based on its current measured or estimated eccentiricity. Tidal circularisation makes the orbit of close-in planets more circular (decreasing the eccentricity, e, to zero), dumping the energy into tidal heating of the planet (and the star). Doing this for Gl 437, for example, they showed that it would be hotter than Io, with a volcanic surface and couldn't be habitable. For HD 403007b, Hence they believe the planets are not terrestrial-like, but may be more Neptune-like. So, could these planets have oceans ? Tags astronony, super-earths, neptunes, exoplanets

Since I've ranted a little recently lets do another public bugfix. The last few times people seemed to like them, and writing things down helps me keep track of where I am, what I'm doing, and how soon it will be "beer o'clock". So I looked over the release critical bug list, looking for things that might be easy to fix. One bug jumped out at me:

• gnomad2: segfault on start up / vorbis comment headers
• (Original report)

I installed the package:

skx@gold:~$ apt-get install gnomad2
..
The following NEW packages will be installed
  gnomad2 libmtp7 libnjb5 libtagc0
..

Once I copied an .mp3 file to my home directory, with the .ogg suffix I got a segfault on startup:

skx@gold:~$ cp /home/music/Audio/RedDwarf-back-to-reality.mp3 ~/foo.ogg
skx@gold:~$ gnomad2
..
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
[segfault]
skx@gold:~$

So I downloaded the source ("apt-get source gnomad2"), and the dependencies for rebuilding ("apt-get build-dep gnomad2"). This allowed me to rebuild it locally:

skx@gold:/tmp/gnomad2-2.9.1$ ./configure --enable-debug && make
skx@gold:/tmp/gnomad2-2.9.1$ cd src/

And now it can be run under GDB.

skx@gold:/tmp/gnomad2-2.9.1/src$ gdb ./gnomad2
GNU gdb 6.8-debian
...
(gdb) run
Starting program: /tmp/gnomad2-2.9.1/src/gnomad2
...
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
[New Thread 0x41dcd950 (LWP 23593)]
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41dcd950 (LWP 23593)]
0x00007fc89e0340b0 in taglib_tag_artist () from /usr/lib/libtag_c.so.0
(gdb)

Interestingly the crash comes from a library, libtag_c.so.0. So either:

• The bug is realy in the libtag module.
• The gnomad2 package doesn't handle a failure case it should.

Time to guess which that is. Charitably we'll assume any library that segfaults will be quickly fixed, because it will have more users than a single program.. Moving on we can look at the gnomad2 source for mentions of taglib. Several mentions are found, but src/tagfile.c is clearly the correct place to look. That file contains the following code:

void
get_tag_for_file (metadata_t *meta)
 
  gchar *tmppath = filename_fromutf8(meta->path);
  TagLib_Tag *tag;
  const TagLib_AudioProperties *properties;
  TagLib_File *file = taglib_file_new(tmppath);
  if(file == NULL)  
    g_printf("could not open file %s", tmppath);
    g_free(tmppath);
    return;
   
  g_free(tmppath);
  tag = taglib_file_tag(file);
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);
  ..

This looks like a great place to explore because opening a file to read the tags is most likely where the crash is going to be coming from. Interestingly we see the code:

• Calls taglib_file_new to get a handle of some kind relating to the file.
• Tests for errors with that operation.
• Calls taglib_file_tag to fetch tag information using the handle, and indirectly the file.
• But then uses taglib_tag_artist to fetch the artist (?I guess?) without testing the handle previously obtained was valid.

Let us guess that the file opening is succeeding but that the tag structure fetched via taglib_file_tag is NULL - and this causes the crash. A quick edit:

  g_free(tmppath);
  tag = taglib_file_tag(file);
  if(tag == NULL)  
    g_printf("tag was null");
    return;
   
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);

Rebuild, and the segfault is gone. We have a winner. Now we just need to file a patch... ObFilm: 300

"I've got chills
They're multiplying"

I guess technically I could have used that as a subject, but ugh. If ever you're a bit shiverry, and a bit unwell, don't shave your head. It'll take three times as long, and you'll cut yourself. ObQuote: Red Dwarf.

meta-hacking I've had a lot of fun over the past few years detecting and fixing XSS attacks - a few months ago compromising several thousand user-accounts belonging to a particular niche social networking site and then more recently experimenting with XSS issues upon a popular software developer's advocate blog. One thing I've been wondering about recently is meta-XSS attacks. Consider the LKML (linux kernel mailing list). This list receives lots of long patches, submitted by email, which are copied verbatum to various sites. For example if I mailed an interesting patch to LKML chances are it would get posted to:

• LWN
• KernelTrap
• ...

(Obviously the challenge here is to make a patch sufficiently interesting that it received more than usual coverage.) Do each of those sites HTML-encode patches? In general they do, certainly the ones I looked at had code like this:

#include <linux.h>
...
...

But I'm certain that not all sites do so. I'm also pretty sure there are interesting avenues to explore here, and the general idea of indirectly attacking a specific target is ripe for exploration. Anyway I'm probably not the person to go playing in the field these days; I don't have the time. But it is certainly interesting to think about. ObFilm: Dirty Harry

Just read on Farewell LUGRadio? [theangryangel] and Ashes to ashes, dust to dust... Lugradio is at an end [sungate] that the most famous UK Free Software podcast is ending at the end of this year. I don't know the reasons yet, but it seems a shame. I've been listening again since they proved me wrong and sorted out the dumb licensing terms so it's clearly legal to cut the shows up and only copy the bits that interest me, and Season 5 seems more interesting than previous ones. Then again, I enjoyed Red Dwarf VIII, so what do I know? (but VI and VII did drag a lot) Maybe I will go to Lugradio Live 2008 in Wolverhampton on 19-20 July now I know when it is! (Why is the date only as a large slow graphic on the event page? D'oh! (Yeah I know I should have emailed them, but I had an unfun experience with the show, so I'd rather shout this in public. Wow. I guess I'm still unhappy about them regressing to school playground name-calling.)) There are some suggested alternatives on theangryangel, but most are more Ubuntu-centric (which wasn't a good thing about LR), non-Ogg and/or non-European, so it looks like I'll give LinuxOutlaws a try. Any other recommendations?

Recently I have mostly been "behind". I've caught up a little on what I wanted to do though over the past couple of days, so I won't feel too bad. I've:

made a new release of the chronicle blog compiler, after recieving more great feedback from MJ Ray. un-stalled the Planet Debian. updated the weblogs hosted by Debian Administration, after help and suggestions from Daniel Kahn Gillmor. stripped, cleaned, and tested a new steam engine. Nearly dying in the process. discovered a beautiful XSS attack against a popular social networking site, then exploited that en masse to collect hundreds of username/password pairs - all because the site admins said "Prove it" when I reported the hole. Decisions decisions .. what to do with the list... released a couple of woefully late DSAs. started learning British Sign Language.

Anyway I've been bad and not writing much recently on the Debian Administration site, partly because I'm just sick of the trolling comments that have been building up, and partly due to general lack of time. I know I should ignore them, and I guess by mentioning them here I've kinda already lost, but I find it hard to care when random folk are being snipy. Still I've remembed that some people are just great to hear from. I know if I see mail from XX they will offer an incisive, valid, criticism or a fully tested and working patch. Sometimes both at the same time. In conclusion I need my pending holiday in the worst way; and I must find time to write another letter... ObQuote: Dungeons & Dragons

OK, after a mainboard replacement by HP, I have my AMD64 HP Pavilion DV6000 (DV6615ea) back and a quick update has given me working wireless! The last remaining obstacle has gone - the most recent 2.6.24 kernel update includes working support for the Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 02) in the b43 kernel driver.
a little tip
When connecting this laptop to the mains for a recharge, plug into the mains before connecting the mains lead to the laptop itself. I have a strong suspicion (but it is no more than that) the repair was caused by a power spike from a dodgy extension cable. Plugging into the extension without the other end being connected to the laptop isolates such spikes.
Necessary support

$ uname -a

Linux dwarf 2.6.24-1-amd64 #1 SMP Thu Mar 27 16:52:38 UTC 2008 x86_64 GNU/Linux

 $ dpkg -l 'linux-image-2.6*'

 linux-image-2.6-amd64                 2.6.24+13 

 linux-image-2.6.24-1-amd64         2.6.24-5

Wireless config
The first dmesg output showed a useful tip:

Apr  4 20:07:06 dwarf kernel: b43-phy0 ERROR: 

  YOUR FIRMWARE IS TOO NEW. Please downgrade your firmware.

Apr  4 20:07:06 dwarf kernel: b43-phy0 ERROR: 

  Use this firmware tarball: http://downloads.openwrt.org/sources/broadcom-wl-4.80.53.0.tar.bz2

Apr  4 20:07:06 dwarf kernel: b43-phy0 ERROR: 

  Use this b43-fwcutter tarball: http://bu3sch.de/b43/fwcutter/b43-fwcutter-009.tar.bz2

Apr  4 20:07:06 dwarf kernel: b43-phy0 ERROR: Read, understand and _do_ what this message says, please.

Unpack the b43-fwcutter and call make. Execute ./b43-fwcutter ../broadcom-wl-4.80.53.0/kmod/wl_apsta.o, remove any existing firmware in /lib/firmware/b43/ and replace it with the content created by b43-fwcutter.
Reboot to load the updated firmware into the kernel and your amber wireless light will flash blue. sudo iwlist scan then shows the available access points and network-manager is able to connect without problems.
I'm posting this from the HP laptop over wireless.
Summary: this laptop should be eminently supportable in Lenny
After all my doubts and all the hassle, providing you use 'noapic nolapic' and the support of the Debian-Installer for Lenny.