na ir slavena ne tikai ar savu akmens m ri valsts zieme os, bat ar ar Di o nas Ugunsm ri apk rt visam s valsts Internetam, kas blo visu p c k rtas un iebremzina visu p r jo. Man pirm person g saskarsme ar o pakalpojumu notika jau anhajas lidost , kad tri vien izr d j s, ka valst blo ts ir ne tikai Facebook, bet ar Twitter, kas iev rojami apgr tin ja manas iesp jas tri un viegli apzi ot visus, ka es esmu v l joproj m esmu dz vs un vesels. P c p ris eksperimentiem izr d j s, ka, lai ar no telefona nav pieejama Google+ m jas lapa un nav lejupl d jama Google+ (un WhatsApp) programma uz Android, tom r, ja t s jau ir telefon , ie abi servisi turpina no telefona str d t. T p c es s ku rakst t ce ojuma piez mes Google+ un da as dienas p c ce ojuma s kuma man pat izdev s nokonfigur t If This Then That servisu, lai tas pa em manus Google+ ierakstus un uztaisa no tiem Twitter ierakstus (kas jau t l k pa citiem kan liem izplat s uz Facebook un Draugiem un ar par d s k ned as kopsavilkums aj blog ). Google+ ir savi plusi, bet ar savi m nusi. Galvenais m nuss, ko es aj ce ojum paman ju ir tas, ka Google+ Android aplik cij nav iesp jams sagatavot vair kus ierakstu melnrakstus (v lams katru ar savu geolok ciju) bez Interneta var rakst t tikai vienu ierakstu un t ieraksta GPS koordin tes b s t s kur viet p c tam Internets par d sies. Es jau uzrakst ju Googlei par o probl mu. Galvenais pluss Google plusam (no pun intended) ir Instant Upload ja bild t fotogr fijas ar Android telefonu, s fotogr fijas autom tiski tiks aug upiel d tas un par d sies jaun ieraksta izveides interfeis , kur t s var pievienot ierakstam ar vienu klik i bez jebk das gaid anas. Diem l tas nestr d ar norm laj m kamer m. Pagaid m Ta u es neb tu sts datori is, ja es nepam in tu uzlaust vai apiet o nelielo nas probl mu, ne? Visvienk r akais veids k apiet nas Lielo Ugunsm ru ir izmantot jebk du VPN, kas at auj ne tikai piek t VPN t kla resursiem, bet ar at auj laist visu trafiku caur o VPN savienojumu. dus VPN piesl gumus var nopirkt, vai (ja ir Linux serveris vai routeris rpus nas) izveidot pa am. Man gad jum tas bija ar vienu klik i iesl gts OpenVPN uz Fonera routera, kas st v man s m j s. Diem l na ir sav da. Blo to lapu, portu un protokolu saraksts main s gan da dos rajonos, gan ar atkar b no t vai Internets ir mob lais vai wifi vai ar piesl gumu, gan ar vienk r i no dienas dien . Liel da gad jumu blo to lietu sarakst iekr t ar VPN savienojumi. Bie i vien ar priv tie. Man kaut k ne iet, ka mana m jas IP adrese ir nas ugunsm ra sarakstos, ta u da reiz ar tam VPN pievienoties es nevar ju. Un t d s situ cij s, lai apskat tu k du YouTube video, atliek tikai viens, eni ls risin jums sshuttle! is eni lais r ks izveido ko l dz gu VPN savienojumam caur parasto SSH portu un protokolu. Uz lok l s ma nas ir nepiecie ams Python un root ties bas, bet uz servera ir vajadz gas tikai ties bas palaist Python programmas. sshuttle pats aizs ta sevi uz serveri un palai s tur, pat ie ifr un p rs ta visus savienojumus un ar DNS piepras jumus, ja vi am to paprasa. Var p rs t t konkr tus t klus vai visu trafiku. Un trums man pieredz tas ir bija pat tr ks par parasto VPN. Kopum Interneta blok de un t visp r gais l nums ir viens oti spec gs m nuss nai. Aizskrienot mazliet uz priek u st st jum pateik u, ka Hong Kong das probl mas nav tur Internets ir lielisks! L k t ds t zeris san ca

puppet and similar things are very nice tools for managing your systems. Rather than doing the same thing 100 times, it's much more interesting to spend some time describing how to do something, and then have it done hundreds of times automatically. However, I'm starting to see a distressing trend lately. I'd like to say that puppet is not an installer, nor is it a replacement for one. Here's why:

• By giving me a script that calls puppet to install your software from the interwebz, you're making it very hard for me to install your software in case I'm running behind a paranoid firewall that I don't have access to.
• By giving me a script that calls puppet to install your software, and sets up things so it will try to run puppet agent against your server (presumably to keep my installation up-to-date), you're making it much more difficult for me to manage that system as part of my larger network, which is already being managed with puppet.

Please, pretty please, with sugar on top: just provide packages. If that can't be done, just provide clear installation instructions and/or a puppet module that I can include or something. Don't assume I'm a system administrator not worth his paycheck. Thanks. note: the gitorious example above is just that, an example. I've seen more cases of people doing similar things, not just gitorious. Surprisingly, it's mostly from people who're on the ruby kool-aid. I hope that's not related... Update: (2013-04-18) despite my usage of buzzwords in the title of this post, I did not mean to imply that any of the above has anything to do with devops. Instead, what the post is supposed to say is that you should not fall into the trap of believing that devops methods, which may work wonderfully internal to your organization, will therefore also work wonderfully for processes outside your organization.

Dear Project Members,

   "Now that I have your attention, I would like to make the following
delegations:"

... nah, scrap that. In my last day in office I first of all owe you a report of DPL activities for the last reporting period of this term, i.e. March 8th until today. Here it is! Highlights

• At LibrePlanet (see below) I've discussed at length with Karen Sandler as GNOME representative the possibility of Debian participation in the FOSS Outreach Program for Women. I've then proposed that we do participate and, as you might have read on d-d-a, we're now doing that. Many thanks to the volunteer co-organizers for Debian participation in the program: M nica Ram rez Arceda, Ana Guerrero L pez, and Patty Langasek.
• A couple of years of work with the auditors has come together. At elgar.debian.org:/srv/accounting.debian.org/ledger/ you can now find Debian monetary transactions for the 2010-2013 period. Note that: 1) They are not all of our transactions, most notably because we haven't yet managed to get access to all our bank transactions at SPI (while we do have access to other transactions there, e.g. donations). Given the relevance of the missing transactions for our budget, this is a blocker for producing meaningful public periodic reports of Debian finances. This is clearly annoying, but I'm confident that our feedback to SPI over the past years has helped them better understand our needs and improve. I hope this could be finally solved during the next DPL term. And, 2) Donor names have been anonymized in the ledger files, in wait of a donation system that allow to express privacy preferences. Complete donation information is available in the companion ledger.git repository, which is accessible to auditors only. I'd like to thank the Debian auditors, and in particular Martin Michlmayr, for their amazing work on this over the past 3 years.
• As you might have noticed, we now have an official Debian Project blog, finally entering the brave new Web 1.5 era I've only helped "politically" here and there with this over the years, and I'm happy to see it live. Your thanks for this should go to the blog editors---Francesca Ciceri and Ana Guerrero Lopez---and to DSA for making it real. A proper delegation for the editors is pending and I'm confident the next DPL will pick it up.

Talks Over the past month or so I've attended and spoken on behalf of Debian in the following occasions:

• "Debian: 20 years and counting" talk at the New York Linux User Group; slides are available. Many thanks to Brian Gupta and Tom Limoncelli for inviting me.
• "Debian and GNU" talk at LibrePlanet 2013; slides are available. Many thanks to John Sullivan and the Free Software Foundation for inviting me to talk at their main conference. My presence there has also been a chance to reassess the status of collaboration with FSF (see John's brief summary) and discuss further technical collaboration with the Trisquel maintainers.
• "Legal issues from a radical community angle" keynote at the yearly workshop of FSFE's European Legal Network; slides are available. The talk has also been covered by a LWN feature article last week (the link should become unembargoed for non-LWN subscribers starting tomorrow).

Assets I've approved the budget for the following forthcoming sprints:

• 6th Debian Groupware Meeting (~500 EUR)
• DSA sprint (~3'000 EUR)

Also, we've bought a 3-year warranty pack for the disk array that powers ftp-master.d.o (~900 USD). On the income side, Brian Gupta has started an interesting matching fund experiment, in order to raise funds for the forthcoming DebConf13. The matching fund will be open until April 30th, so your help in spreading news would be welcome. Many thanks to Brian for the idea and to his company, Brandorr Group, for funding it. DPL helpers Three more DPL helpers IRC meetings have been held; minutes are available at the usual place. Legal Spring Cleaning I've finally cleaned up the pile of pending legal matters (but I'm sure new ones will show up for the delight of the next DPL :-P)

• one is merely internal for trademark@d.o: our procedures for (n)acks on incoming requests has now been vetted by our legal advisors
• the second one is relevant for our mentors.debian.net service: one of the blockers to officialize it as mentors.debian.org have historically been DMCA-related concerns. We now have a DMCA policy for (wannabe) mentors.d.o, which I've shared with the service maintainers and DSA. This specific part should no longer be a concern.
• the last one concerns the possibilities of playing DVDs with Debian. We now have legal guidelines on how to include installer packages that allow to do so; that should allow us to have a decent solution for our users in the Jessie time frame.

Once again, I'd like to thank SFLC for the pro bono and very high quality legal advice they keep on offering to Debian. Miscellaneous

• I've mentioned last month that, as a Debian representative, I've joined a working group by the Italian public administration (PA) that should define procurement rules for software in the PA at large, together with representatives of other well-known FOSS initiatives (e.g. KDE, FSFE). The first meetings have now been held and I've participate in some, for the moment on my own budget. I'll check with the next DPL the feasibility of keep on doing so on in the future.

---

Now, before I get sentimental, let me thank Gergely, Lucas, and Moray for running in the recently concluded DPL election. Only thinking of running and then go through a campaign denote a very high commitment to the Project; we should all be thankful to them. Then I'd like to congratulate Lucas for his election. I've known him for a long time, and I can testify about his clear vision of the role Debian has to play in Free Software and on what Debian needs to improve to do so. Best wishes for the term ahead, Lucas! Finally, I'd like to thank you all for the support you've shown me over the past 3 years. Serving as DPL is a great honor, but also a very demanding job. Thank to you all, and to how cool Debian is, it has been for me an incredibly rewarding experience. I had no idea what I were doing when I embarked on this adventure, but in hindsight I don't regret any of it. See you around, as I don't plan to be anywhere far away from Debian anytime soon. Cheers.

---

PS the day-to-day activity logs for March and April 2013 are available at the usual place master:/srv/leader/news/bits-from-the-DPL.txt.20130 3,4

After nearly one year of development, the "Port bootstrap build-ordering tool" now finally has a name: botch. It stands for Bootstrap/Build Order Tool CHain. Now we dont have to call it "Port bootstrap build-ordering tool" anymore (nobody did that anyways) and also dont have to talk about it by referring to it as "the tools" in email, IRC or in my master thesis which is due in a few weeks. With this, the issue also doesnt block the creation of a Debian package anymore. Since only a handful of people have a clone of it anyway, I also renamed the gitorious git repository url (and updated all links in this blog and left a text file informing about the name change in the old location). The new url is: https://gitorious.org/debian-bootstrap/botch Further improvements since my last post in January include:

• greatly improved speed of partial order calculation
• calculation of strong edges and strong subgraphs in build graphs and source graphs
• calculation of source graphs from scratch or from build graphs
• calculation of strong bridges and strong articulation points
• calculate betweenness of vertices and edges
• find self-cycles in the source graph
• add webselfcycle code to generate a HTML page of self-cycles
• allow to collapse all strongly connected components of the source graph into a single vertex to make it acyclic
• allow to create a build order for cyclic graphs (by collapsing SCC)
• allow to specify custom installation sets
• add more feedback arc set heuristics (eades, insertion sort, sifting, moving)
• improve the cycle heuristic

In the mean time a paper about the theoretical aspects of this topic which Pietro Abate and I submitted to the CBSE 2013 conference got accepted (hurray!) and I will travel to the conference in Canada in June. Botch (yeey, I can call it by a name!) is also an integral part of one of the proposals for a Debian Google Summer of Code project this year, mentored by Wookey and co-mentored by myself. Lets hope it gets accepted and produces good results in the end of the summer!

I am led to believe that splunkd (some agent for feeding log entries into the Grand Log Analysis Tool Of Our Age ) has no capability for running itself in the foreground. This is stupid. Do not make these sorts of assumptions about how the user will want to run your software. Some people use sane service-management systems that are capable of handling the daemonisation for you and automatically restart the managed process on crash. These systems are typically much easier to configure and debug, and they don t need bloody PID files and the arguments about where to put them (tmpfs, inside or outside chroots oh my) and who should update them and how to reliably detect that they re out of date when they crash without causing race conditions and whether non-root-running processes should place their PID files in the same place and how do you deal with the permissions issues and bugger that for a game of skittles. In short, if you provide a service daemon and do not provide some well-documented means of saying don t background , I will hurt you. This goes double if your shitware is not open source.

All in a below average season. Although we had lots of snow in December, my first day on-piste was December 22nd. Riding in snowstorm or thick fog is just not my kind of thing. The christmas holiday season was absurdely warm, getting rid of most of the snow again. I managed 7 snow-days from December 22nd to January 1st, but this was more sport than fun. Really sunny days were rare in the whole winter. Due to minor injury and minor illness I had to take long breaks from snowboarding (just two snow days in the periode from January 8th to February 15th!). Early easter cut the season short. This year I ended up in skiline.cc's top-100 list for both most meters of altitude in a single day and the whole season which shows that other people had a short season, too. On the plus side, we had enough and good snow. This is also evident from the balance sheet below, I almost always went to Diedamskopf where there is almost no artificial snow. Here is the balance sheet:

	2005/06	2006/07	2007/08	2008/09	2009/10	2010/11	2011/12	2012/13
number of (partial) days	25	17	29	37	30	30	25	23
Dam ls	10	10	5	10	16	23	10	4
Diedamskopf	15	4	24	23	13	4	14	19
Warth/Schr cken	0	3	0	4	1	3	1	0
total meters of altitude	124634	74096	219936	226774	202089	203918	228588	203562
highscore	10247m	8321m	12108m	11272m	11888m	10976m	13076m	13885m
# of runs	309	189	503	551	462	449	516	468

DRI3K First Steps Here s an update on DRI3000. I ll start by describing what I ve managed to get working and then summarize discussions that happened on the xorg-devel mailing list. Private Back Buffers One of the big goals for DRI3000 is to finish the job of moving buffer management out of the X server and into applications. The only thing still allocated by DRI2 in the X server are back buffers; everything else moved to the client side. Yes, I know, this breaks the GLX requirement for sharing buffers between applications, but we just don t care anymore. As a quick hack, I figured out how to do this with DRI2 today allocate our back buffers separately by creating X pixmaps for them, and then using the existing DRI2GetBuffersWithFormat request to get a GEM handle for them. Of course, now that all I ve got is a pixmap, I can t use the existing DRI2 swap buffer support, so for now I m just using CopyArea to get stuff on the screen. But, that works fine, as long as you don t care about synchronization. Handling Window Resize The biggest pain in DRI2 has been dealing with window resize. When the window resizes in the X server, a new back buffer is allocated and the old one discarded. An event is delivered to invalidate the old back buffer, but anything done between the time the back buffer is discarded and when the application responds to the event is lost. You can easily see this with any GL application today resize the window and you ll see occasional black frames. By allocating the back buffer in the application, the application handles the resize within GL; at some point in the rendering process the resize is discovered, and GL creates a new buffer, copies the existing data over, and continues rendering. So, the rendered data are never lost, and every frame gets displayed on the screen (although, perhaps at the wrong size). The puzzle here was how to tell that the window was resized. Ideally, we d have the application tell us when it received the X configure notify event and was drawing the frame at the new size. We thought of a cute hack that might do this; track GL calls to change the viewport and make sure the back buffer could hold the viewport contents. In theory, the application would receive the X configure notify event, change the viewport and render at the new size. Tracking the viewport settings for an entire frame and constructing their bounding box should describe the size of the window; at least it should describe the intended size of the window. There s at least one serious problem with this plan applications may well call glClear before calling glViewport, and as glClear does not use the current viewport, instead clearing the whole window, we couldn t use the viewport as an indication of the current window size. However, what this exercise did lead us to realize was that we don t care what size the window actually is, we only care what size the application thinks it is. More accurately, the GL library just needs to be aware of any window configuration changes before the application, so that it will construct a buffer that is not older than the application knowledge of the window size. I came up with two possible mechanisms here; the first was to construct a shared memory block between application and X server where the X server would store window configuration changes and signal the application by incrementing a sequence number in the shared page; the GL library would simply look at the sequence number and reallocate buffers when it changed. The problem with the shared memory plan was that it wouldn t work across the network, and we have a future project in mind to replace GLX indirect rendering with local direct rendering and PutImage which still needs accurate window size tracking. More about that project in a future post though X Events to the Rescue So, I decided to just have the X server send me events when the window size changed. I could simply use the existing X configure notify events, but that would require a huge infrastructure change in the application so that my GL library could get those events and have the application also see them. Not knowing what the application is up to, we d have to track every ChangeWindowAttributes call and make sure the event_mask included the right bits. Ick. Fortunately, there s another reason to use a new event we need more information than is provided in the ConfigureNotify event; as you know, the Swap extension wants to have applications draw their content within a larger buffer that can have the window decorations placed around it to avoid a copy from back buffer to window buffer. So, our new ConfigureNotify event would also contain that information. Making sure that ConfigureNotify event is delivered before the core ConfigureNotify event ensures that the GL library should always be able to know about window size changes before the application. Splitting the XCB Event Stream Ok, so I ve got these new events coming from the X server. I don t want the application to have to receive them and hand them down to the GL library; that would mean changing every application on the planet, something which doesn t seem very likely at all. Xlib does this kind of thing by allowing applications to stick themselves into the middle of the event processing code with a callback to filter out the events they re interested in before they hit the main event queue. That s how DRI2 captures Invalidate events, and it works , but using callbacks from the middle of the X event processing code creates all kinds of locking nightmares. As discussed above, I don t care when GL sees the configure events, as long as it gets them before the application finds about about the window size change. So, we don t need to synchronously handle these events, we just need to be able to know they ve arrived and then handle them on the next call to a GL drawing function. What I ve created as a prototype is the ability to identify specific events and place them in a separate event queue, and when events are placed in that event queue, to bump a sequence number so that the application can quickly identify that there s something to process. Making the Event Mask Per-API Instead of Per-Client The problem described above about using the core ConfigureNotify events made me think about how to manage multiple APIs all wanting to track window configuration. For core events, the selection of which events to receive is all based on the client; each client has a single event mask, and each client receives one copy of each event. Monolithic applications work fine with this model; there s one place in the application selecting for events and one place processing them. However, modern applications end up using different APIs for 3D, 2D and media. Getting those libraries to cooperate and use a common API for event management seems pretty intractable. Making the X server treat each API as a separate entity seemed a whole lot easier; if two APIs want events, just have them register separately and deliver two events flagged for the separate APIs. So, the new DRI3 configure notify events are created with their own XID to identify the client-side owner of the event. Within the X server, this required a tiny change; we already needed to allocate an XID for each event selection so that it could be automatically cleaned up when the client exited, so the only change was to use the one provided by the client instead of allocating one in the server. On the wire, the event includes this new XID so that the library can use it to sort out which event queue to stick the event in using the new XCB event stream splitting code. Current Status The above section describes the work that I ve got running; with it, I can run GL applications and have them correctly track window size changes without losing a frame. It s all available on the dri3 branches of my various repositories for xcb proto, libxcb, dri3proto and the X server. Future Directions The first obvious change needed is to move the configuration events from the DRI3 extension to the as-yet-unspecified new Swap extension (which I may rename as Present , as in please present this pixmap in this window ). That s because they aren t related to direct rendering, but rather to tracking window sizes for off-screen rendering, either direct, indirect or even with the CPU to memory. DRI3 and Fences Right now, I m not synchronizing the direct rendering with the CopyArea call; that means the X server will end up with essentially random contents as the application may be mid-way through the next frame before it processes the CopyArea. A simple XSync call would suffice to fix that, but I want a more efficient way of doing this. With the current Linux DRI kernel APIs, it is sufficient to serialize calls that post rendering requests to the kernel to ensure that the rendering requests are themselves serialized. So, all I need to do is have the application wait until the X server has sent the CopyArea request down to the kernel. I could do that by having the X server send me an X event, but I think there s a better way that will extend to systems that don t offer the kernel serialization guarantee. James Jones and Aaron Plattner put together a proposal to add Fences to the X Sync extension. In the X world, those offer a method to serialize rendering between two X applications, but of course the real goal is to expose those fences to GL applications through the various GL sync extensions (including GLARBsync and GLNVfence). With the current Linux DRI implementation, I think it would be pretty easy to implement these fences using pthread semaphores in a block of memory shared between the server and application. That would be DRI-specific; other direct rendering interfaces would use alternate means to share the fences between X server and application. Swap/Present The Second Extension By simply using CopyArea for my application presentation step, I think I ve neatly split this problem into manageable pieces. Once I ve got the DRI3 piece working, I ll move on to fixing the presentation issue. By making that depend solely on existing core Pixmap objects as the source of data to present, I can develop that without any reference to DRI. This will make the extension useful to existing X applications that currently have only CopyArea for this operation. Presentation of application contents occurs in two phases; the first is to identify which objects are involved in the presentation. The second is to perform the presentation operation, either using CopyArea, or by swapping pages or the entire frame buffer. For offscreen objects, these can occur at the same time. For onscreen, the presentation will likely be synchronized with the scanout engine. The second form will mean that the Fences that mark when the presentation has occurred will need to signaled only once the operation completes. A CopyArea operation means that the source pixmap is ready immediately after the Copy has completed. Doing the presentation by using the source pixmap as the new front buffer means that the source pixmap doesn t become ready until after the next swap completes. What I don t know now is whether we ll need to report up-front whether the presentation will involve a copy or a swap. At this point, I don t think so the application will need two back buffers in all cases to avoid blocking between the presentation request and the presentation execution. Yes, it could use a fence for this, but that still sticks a bubble in the 3D hardware where it s blocked waiting for vblank instead of starting on the next frame immediately. Plan of Attack Right now, I m working on finishing up the DRI3 piece:

• Replace the DRI2 buffer allocation kludge with actual local buffer allocation, mapping them into pixmaps using FD passing.
• Replace the DRI2 authentication scheme with having the X server open the DRI object, preparing it for rendering and passing it back to the application.
• Working on the XCB pieces to get the split event-queue stuff landed upstream.
• Implementing the Fencing stuff to correctly serialize access to the pixmap.

The first three seem fairly straight forward. The fencing stuff will involve working with James and Aaron to integrate their XSync changes into the server. After that, I ll start working on the presentation piece. Foremost there is figuring out the right name for this new extension; I started with the name Swap as that s the GL call it implements. However, Swap is quite misleading as to the actual functionality; a name more like Present might provide a better indication of what it actually does. Of course, Present is both a verb and a noun, with very different connotations. Suggestions on this most complicated part of the project are welcome!

Review: Familiar, by J. Robert Lennon

Publisher:	Greywolf
Copyright:	2012
ISBN:	1-55597-535-6
Format:	Hardcover
Pages:	205

This is the first book of an experiment. I'm fairly well-read in science fiction and fantasy and increasingly well-read in non-fiction of interest (although there's always far more of that than I'll get to in a lifetime), but woefully unfamiliar with what's called "mainstream" literature. Under the principal that things people are excited about are probably exciting, I've wanted to read more and understand the appeal. Powell's, which I like to support anyway, has a very nice (albeit somewhat expensive) book club called Indiespensable, which sends its subscribers very nice editions of new works that Powell's thinks are interesting, with a special focus on independent publishers. So I signed up and hope to stick with it for at least a year. (The trick will be fitting these books in amongst my regular reading.) Familiar is the first feature selection I received. Elisa Brown is a mother with a dead son and a living one, a failing marriage, an affair, and a life that is, in short, falling apart. Then, while driving back from her annual pilgrimage from her son's grave, the world seems to twist and change. She finds herself dressed for business, wearing a nametag and apparently coming back from a work-related convention, driving a car that's entirely unfamiliar to her. When she gets home, everything else has changed too: her marriage seems to be on firmer ground, but based on rules she doesn't understand. She has a different job, different clothes, a different body in some subtle ways. And both of her sons are alive. I'm going to have to have a long argument with myself about where to (meaninglessly) categorize this on my review site, since in construction it is an alternate reality story and therefore a standard SF trope. Any SF reader is going to immediately assume Elisa has somehow been transported into an alternate reality with a key divergence point from her own. But that's not Lennon's focus. He stays ambiguous on the question of whether this is really happening or whether Elisa had some sort of nervous breakdown, and while some amount of investigation of the situation does take place, it's the sort of investigation that an average person with no access to special resources or scientific knowledge and a completely unbelievable story would be able to do: Internet conspiracy chatrooms and some rather dodgy characters. The focus is instead on Elisa's reaction to the situation, her choices about how to treat this new life, and on how she processes her complex emotions about her family and herself. I had profoundly mixed feelings about this book when I finished it, and revisiting it to review it, I still do. The writing is excellent: spare, evocative, and enjoyable to read. Lennon has a knack for subjective description of emotion and physical experience. The reader feels Elisa's deep discomfort with her changed body and her changed car, her swings between closed-off emotions and sudden emotional connection with a specific situation, and her struggle with the baffling question of how to come to terms with a whole new life. The part of the book from about the middle to nearly the end is excellent. Video games make an appearance and are handled surprisingly well. And when Elisa starts being blunt with people, I found myself both liking her and caring about what happens to her. On the other hand, Familiar also has some serious problems, and one of the biggest is the reaction I feared I'd have to mainstream literature: until Elisa started opening up and taking action, I found it extremely difficult to care about anyone in this book. They're all so profoundly petty, so closed off and engrossed in what seem like depressing and utterly boring lives. I'm sure that some of this is intentional and is there to lay the groundwork for Elisa's own self-discovery, but even towards the end of that self-discovery, everything here is so relentlessly middle-class suburbia that I felt stifled just reading about it. I think it's telling that no one in this book ever seems to have any substantial problem with money, or even with work. Elisa walks into a job that she's never done before and within a few weeks is doing it so well that she can take large amounts of time to wander around for plot purposes. This is a book about highly privileged people being miserable in a bubble. While those people certainly do exist, and I can believe that they act like this, I'm not sure how much I want to read about them. Thankfully, the plot does lead Elisa to poke some holes in that bubble, if never get out of it entirely. This is also another one of those stories in which every character has massive communication problems. Now, this deserves some caveats: Elisa's communication problems with her husband are part of the problem that starts the book and are clearly intentional, as are her communication difficulties with her children. And she's not really close enough to anyone to confide in them. But even with those caveats, no one in this book really talks to anyone else. It's amazing that anyone forms any connections at all, given how many walls and barriers they have around themselves. As someone with a bit of a thing for communication, this drove me nuts to read about, particularly in the first half of the book. But the worst problem is that Lennon completely blows the ending. And by that I don't just mean that I disliked the ending. I mean the ending is so unbelievable and so contrary to the entire rest of the book, at least the way I was reading and understanding it, that I think Familiar is a much better novel if you just remove the final scene entirely. It was such a bizarre and unnecessary twist that I found it infuriating. I don't want to spoil an ending, even a bad ending, so I'll only say this: it felt to me like Lennon just wasn't comfortable with his setting and plot driver and couldn't leave it alone. I think an experienced SF author wouldn't have made this mistake. There were two obvious possible conclusions to draw from the setting, plus a few interesting combinations, and I think someone comfortable with this sort of alternate reality story would have taken one of those options, any of which would have been a reasonable dismount for the plot. Alternately, they could have left it entirely ambiguous to the end and explored why the explanation may not actually matter. But Lennon seemed to me to have a tin ear for plausibility and for the normal flow of this sort of story and seems to have taken it as license for arbitrary events, thus completely violating the internal consistency and emergent rules that he'd spent the rest of the book building. I've mostly talked about my reactions to the characters and the writing and have not said much about the plot. That's somewhat intentional, since figuring out where the story will go is one of the best parts of this book. It's surprisingly tense and well-crafted for not having that much inherent dramatic tension. The excellent writing kept me reading through the first part, when I hated everyone in the story, and then Elisa started taking responsibility for her own life and actions and I started really enjoying the book while being constantly surprised. I think it's the sort of story that's best to take without too much foreknowledge of where it's going. I'm going to call this first experiment a qualfied success. Familiar was certainly interesting to read, and quite different from what I normally read despite the SF premise. If it weren't for the ending, I'd be recommending it to other people. Rating: 6 out of 10

There is no common way to express license information in each source file at the moment. Some people embed license information in each file, others keep it in README or another file at the top of the source tree. Worse, there is no common syntax to express the license information in a machine-parseable way. If we had this, we could have tools that, for example, tell you if you're trying to merge code that has an incompatible license. Obviously, this kind of thing can never work perfectly. People keep inventing new licenses, and it is not possible for a computer program to fully understand any license. It is not clear humans can do that, either. However, it would be possible to do it to a number of well-known licenses, which would help most of the time. A classic 20/80 situation. I would like to suggest a syntax, similar to Emacs's "Hey Emacs" modelines, for embedding a summary of the license, or licenses, for a source file, in such a way that it can be programmatically extracted and parsed and analysed. With this syntax, one could then write a tool to ensure that all files in a project have the same license, or that all licenses are compatible with the project's overall license. Such a tool will, of course, rely on heuristics and assumptions. For example, it needs to assume the machine-parseable license summary is correct, and rely on a ruleset on what licenses are compatible with what licenses. Things can go wrong. That's life. Remember, this is aiming at doing the 20% of the work that will work 80% of the time, not perfection. I don't have a tool written, but I have a suggestion for the syntax.

/*
 * Copyright 2013 Lars Wirzenius
 *
 * tl;dr =*= Licenses: GPL-3+ or Expat, and Artistic =*=
 *
 * Blah. Blah. Blah. Imagine long, boring license texts 
 * here.
 */

The important part is this:

=*= Licenses: GPL-3+ or Expat, and Artistic =*=

The =*= prefix and suffix and the word Licenses are there to make grepping reasonably reliable without too many false positives, and to allow comment characters and other text on the same line. The actual license summary follows the syntax and semantics of the Debian copyright-format 1.0 specification, which I chose because it exists and has had a fair bit of review so far, and is reasonably expressive. The license summaries can be extracted with the following GNU sed invocation:

sed -n '/.*=\*= [Ll]icen[cs]es\?: \(.*\)=\*=.*/s//\1/p'

I allowed various forms of the word license, since it's a word that a lot of people will get wrong, and it's easy to catch all four common forms. So, does anyone else think this might be useful? Would you use it in your own projects?

I bought a ScanJet N6350 a few years back, in the belief that it would work. After all, you write free Linux drivers for all your printers, and when those printers are multifunctional printers with scanners, you do make sure the scanner bits of those printers work too. So it shouldn't be too hard to write a Linux driver for that scanner too, right? Apparently it is. For some reason that I can't imagine, you decided that my money is worth more than my stress levels.

• The HP ScanJet N6350 is a combination USB/network scanner. That's great; I don't need it to be right next to my laptop all the time. Having the ability to get it sent to me by email (as your product page claims it can do) reduces my workload. Unfortunately, what you didn't mention on the product page is that the scanner is pretty dumb; it does network, yes, but the only way in which it can send emails is by using some application running on a system on the other end of the network connection. That's pretty silly. It wouldn't be so bad, however, except...
• ... the system on the other end of the network connection has to be running Windows. That's right, you didn't write a Linux driver for some reason. You also didn't publish the network protocol, and even the USB connection seems undocumented. So I can't use Linux to scan my documents. It wouldn't be so bad, however, since I already have a Windows XP virtual machine lying around somewhere, mainly because there's this satellite navigation system builtin to my car that also requires it; I just installed your scanners oftware on that machine, and I can scan. Except...
• ... whenever an error occurs in the scanning process, the UI locks up completely. I can't retry the last page that I was trying to scan, and often I can't even save the document anymore, either; I have to rescan the whole document. That wouldn't be so bad, except...
• ... the ADF is total crap. If I put more than a few pages on the feeder, and they've got some horizontal folds in them (as is likely with snail mail that came out of an envelope), I'm very likely to end up with a paper jam, or with multiple pages sucked into the feeder at once, causing an error and a loss of my scanned document. That wouldn't be so bad, except...
• ... the process for finishing one scan and starting the next involves stopping and starting your whole scanning software, which takes a rather long time. As such, I'd prefer to just scan a whole stack of incoming snail mail in one go, and then use pdfsam to split up the PDF file. But then I have to babysit the scanning process so that I don't get any errors; but I fail at that about as often as I succeed, meaning, it usually takes a long time to get through the stack.

Dear HP, you suck. I fail to understand how the basic loss of functionality after a failed scan managed to get through your testing. I fail to understand why you think Linux users should be able to print, but not scan. And I especially fail to understand why I should waste my time with such an expensive device that can't even perform its basic functionality with more than 10% success rate.

Review: Judge Sn Goes Golfing, by John Scalzi

Artist:	Gahan Wilson
Publisher:	Subterranean
Copyright:	2009
Printing:	2012
ISBN:	1-59606-479-X
Format:	Kindle
Pages:	32

As you may have guessed, this is yet another short story by Scalzi that was rolled into the Subterranean Scalzi Super Bundle. This one is a bit longer than the ones I've previously reviewed, and is also illustrationed. Unlike some of the others, it's not available on-line for free... as a written work at least. There's an abridged audio version available for free from Subterranean Press's web site, though. Like the other stories I've reviewed so far, it's humor, but I think it's a bit more successful and substantial than the previous short stories. Judge Bufan Nigun Sn is an extremely foul-tempered alien judge who loves to golf, despite being terrible at it. He's a sort of circuit court judge for a larger galactic civilization, of which Earth is now part. (There's a smattering of background world-building, but it's not the core of the story.) Golf is his passion, in several senses of the word: his habit of getting into nasty fights with his fellow players and otherwise making public and occasionally injurious scenes has gotten him banned from every course in the Washington DC area, both public and private. Except, that is, for Dulles Woods, a dire, badly-maintained course designed via nepotism and theft whose business model is primarily based on letting the people banned from every other course golf there. And charging them extra to let caddies accompany them. The plot of this story is about a particular game of golf, dramatically foreshadowed by the opening sentence. But the story is really about Judge Sn's relationship to golfing and to the notorious Dulles Woods. It's one of the better jobs I've seen of writing a thoroughly unlikable person into a gloriously foul-tempered charm. It's also a story about a golf course and golfer who thoroughly deserve each other, and about how it feels to suddenly have something go right after grinding out hours and hours of work on a hobby that is supposed to be fun but manages to fall into some horribly compelling middle ground between enjoyment and rage-inducing frustration. Speaking as someone who is known to grind out video game completions while swearing at the television, I can sympathize. I got thoroughly hooked by Scalzi's descriptions of Judge Sn's mental state and enjoyed this story far more than I expected to. Sadly, when the plot does finally arrive, I thought it was a letdown. Scalzi throws in a highly improbable coincidence to create action, and while that's a legitimate plot technique (particularly in humor), it works best when the author goes back afterwards and fills in the back story of the coincidence. Pratchett does this extremely well. Scalzi, alas, doesn't really bother, and while suspension of disbelief isn't as relevant for this sort of story, I thought it was a missed opportunity. The ending seemed to be missing some sort of punch or background twist. That said, I really liked the character study and I think the story is well worth the 99 cents it's still selling for on the Kindle (and quite possibly other platforms; I haven't checked). If buying short stories on the Kindle is something you want to do, I recommend this one to your attention. Rating: 7 out of 10

We are happy to announce that the shogun machine learning toolbox will participate in this years google summer of code :-) SHOGUN is designed for unified large-scale learning for a broad range of feature types and learning settings, like classification, regression, or exploratory data analysis. In case you are a talented student interested in implementing and learning about machine learning algorithms - we are looking for you! We have collected a number of ideas [1] that we consider worthwhile implementing. And don't forget to apply [2]!

[1] http://shogun-toolbox.org/page/Events/gsoc2013_ideas

[2] http://google-melange.appspot.com/gsoc/org/google/gsoc2013/shogun

Hello everyone! I am very excited to report about the awesome progress we made with Tanglu, the new Debian-based Linux-Distribution. First of all, some off-topic info: I don t feel comfortable with posting too much Tanglu stuff to Planet-KDE, as this is often not KDE-related. So, in future Planet-KDE won t get Tanglu information, unless it is KDE-related You might want to take a look at Planet-Tanglu for (much) more information. So, what happened during the last weeks? Because I haven t had lectures, I nearly worked full-time on Tanglu, setting up most of the infrastructure we need. (this will change with the next week, where I have lectures again, and I also have work to do on other projects, not just Tanglu ^^) Also, we already have an awesome community of translators, designers and developers. Thanks to them, the Tanglu-Website is now translated to 6 languages, more are in the pipeline and will be merged later. Also, a new website based on the Django framework is in progress. The Logo-Contest We ve run a logo-contest, to find a new and official Tanglu logo, as the previous logo draft was too close to the Debian logo (I asked the trademark people at Debian). More than 30 valid votes (you had to be subscribed to a Tanglu Mailinglist) were received for 7 logo proposals, and we now have a final logo: I like it very much Fun with dak I decided to use dak, the Debian Archive Kit, to handle the Tanglu archive. Choosing dak over smaller and easy-to-use solutions had multiple reasons, the main reason is that dak is way more flexible than the smaller solution (like reprepro or min-dak) and able to handle the large archive of Tanglu. Also, dak is lightning fast. And I would have been involved with dak sooner or later anyway, because I will implement the DEP-11 extension to the Debian Archive later (making the archive application-friendly). Working with dak is not exactly fun. The documentation is not that awesome, and dak contains many hardcoded stuff for Debian, e.g. it often expects the unstable suite to be present. Also, running dak on Debian Wheezy turned out to be a problem, as the Python module apt_pkg changed the API and dak naturally had problems with that. But with the great help of some Debian ftpmasters (many thanks to that!), dak is now working for Tanglu, managing the whole archive. There are still some quirks which need to be fixed, but the archive is in an usable state, accepting and integrating packages. The work on dak is also great for Debian: I resolved many issues with non-Debian dak installations, and made many parts of dak Wheezy-proof. Also, I added a few functions which might also be useful for Debian itself. All patches have of course been submitted to upstream-dak. Wanna-build and buildds This is also nearly finished Wanna-build, the software which manages all buildds for an archive, is a bit complicated to use. I still have some issues with it, but it does it s job so far. (need to talk to the Debian wanna-build admins for help, e.g. wanna-build seems to be unable to handle arch:all-only packages, also, build logs are only submitted in parts) The status of Tanglu builds can be viewed at the provisoric Buildd-Status pages. Setting up a working buildd is also a tricky thing, it involves patching sbuild to escape bug #696841 and applying various workarounds to make the buildd work and upload packages correctly. I will write instructions how to set-up and maintain a buildd soon. At time, we have only one i386 buildd up and running, but more servers (in numbers: 3) are prepared and need to be turned into buildds. After working on Wanna-build and dak, I fully understand why Canonical developed Launchpad and it s Soyuz module for Ubuntu. But I think we might be able to achieve something similar, using just the tools Debian already uses (maybe a little less confortable than LP, but setting up an own LP instance would have been much more trouble). Debian archive import The import of packages from the Debian archive has finished. Importing the archive resulted in many issues and some odd findings (I didn t know that there are packages in the archive which didn t receive an upload since 2004!), but it has finally finished, and the archive is in a consistent state at time. To have a continuous package import from Debian while a distribution is in development, we need some changes to wanna-build, which will hopefully be possible. Online package search The Online-Package-Search is (after resolving many issues, who expected that? ) up and running. You can search for any package there. Some issues are remaining, e.g. the file-contents-listing doesn t work, and changelog support is broken, but the basic functionality is there. Tanglu Bugtracker We now also have a bugtracker which is based on the Trac software. The Tanglu-Bugtracker is automatically synced with the Tanglu archive, meaning that you find all packages in Trac to report bugs against them. The dak will automatically update new packages every day. Trac still needs a few confort-adjustments, e.g. submitting replies via email or tracking package versions. Tanglu base system The Tanglu metapackages have been published in a first alpha version. We will support GNOME-3 and KDE4, as long as this is possible (= enough people working on the packaging). The Tanglu packages will also depend on systemd, which we will need in GNOME anyway, and which also allows some great new features in KDE. Side-effect of using systemd is at least for the start that Tanglu boots a bit slow, because we haven t done any systemd adjustments, and because systemd is very old. We will have to wait for the systemd and udev maintainers to merge the packages and release a new version first, before this will improve. (I don t want to do this downstream in Tanglu, because I don t know the plans for that at Debian (I only know the information Tollef Fog Heen & Co. provided at FOSDEM)) The community The community really surprised me! We got an incredible amount of great feedback on Tanglu, and most of the people liked the idea of Tanglu. I think we are one of the less-flamed new distributions ever started . Also, without the very active community, kickstarting Tanglu would not have been possible. My guess was that we might be able to have something running next year. Now, with the community help, I see a chance for a release in October The only thing people complained about was the name of the distribution. And to be really honest, I am not too happy with the name. But finding a name was an incredibe difficult process (finding something all parties liked), and Tanglu was a good compromise. Tanglu has absolutely no meaning, it was taken because it sounded interesting. The name was created by combining the Brazilian Tangerine (Clementine) and the German Iglu (igloo). I also dont think the name matters that much, and I am more interested in the system itself than the name of it. Also, companies produce a lot of incredibly weird names, Tanglu is relatively harmless compared to that . In general, thanks to everyone participating in Tanglu! You are driving the project forward! The first (planned) release I hereby announce the name of the first Tanglu release, 1.1 Aequorea Victoria . It is Daniel s fault that Tanglu releases will be named after jellyfishes, you can ask him why if you want I picked Aequorea, because this kind of jellyfish was particularly important for research in molecular biology. The GFP protein, a green fluorescent protein (=GFP), caused a small revolution in science and resulted in a Nobel Prize in 2008 for the researchers involved in GFP research (for the interested people: You can tag proteins with GFP and determine their position using light microscopy. GFP also made many other fancy new lab methods possible). Because Tanglu itself is more or less experimental at time, I found the connection to research just right for the very first release. We don t have a time yet when this version will be officially released, but I expect it to be in October, if the development speed increases a little and more developers get interested and work on it. Project Policy We will need to formalize the Tanglu project policy soon, both the technical and the social policies. In general, regarding free software and technical aspects, we strictly adhere to the Dbian Free Software Guidelines, the Debian Social Contract and the Debian Policy. Some extra stuff will be written later, please be patient! Tanglu OIN membership I was approached by the Open Invention Network, to join it as member. In general, I don t have objections to do that, because it will benefit Tanglu. However, the OIN has a very tolerant public stance on software patents, which I don t like that much. Debian did not join the OIN for this reason. For Tanglu, I think we could still join the OIN without someone thinking that we support the stance on software patents. Joining would simply be pragmatic: We support the OIN as a way to protect the Linux ecosystem from software patents, even if we don t like the stance on software patents and see it differently. Because this affects the whole Tanglu project, I don t want to decide this alone, but get some feedback from the Tanglu community before making a decision. Can I install Tanglu now? Yes and no. We don t provide installation images yet, so trying Tanglu is a difficult task (you need to install Debian and then upgrade it to Tanglu) if you want to experiment with it, I recomment trying Tanglu in a VM. I want to help! Great, then please catch one of us on IRC or subscribe to the mailinglists. The best thing is not to ask for work, but suggest something you want to do, others will then tell you if that is possible and maybe help with the task. Packages can for now only be uploaded by Debian Developers, Ubuntu Developers or Debian Maintainers who contacted me directly and whose keys have been verified. This will be changed later, but at the current state of the Tanglu archive (= less safety checks for packages), I only want people to upload stuff who definitely have the knowledge to create sane packages (you can also proove that otherwise, of course). We will later establish a new-member process. If you want to provide a Tanglu archive mirror, we would be very happy, so that the main server doesn t have to carry all the load. If you have experience in creating Linux Live-CDs or have worked with the Ubiquity installer, helping with these parts would be awesome! Unfortunately, we cannot reuse parts of Linux Mint Debian, because many of their packages don t build from source and are repackaged binaries, which is a no-go for the Tanglu main archive. Sneak peek And here is a screenshot of the very first Tanglu installation (currently more Debian than Tanglu):

Something else I am involved in Debian for a very long time now, first as Debian Maintainer and then as Debian Developer and I never thought much about the work the Debian system administrators do. I didn t know how dak worked or how Wanna-build handles the buildds and what exactly the ftpmasters have to do. By not knowing, I mean I knew the very basic theory and what these people do. But this is something different than experiencing how much work setting up and maintaining the infrastructure is and what an awesome job the people do for Debian, keeping it all up and running and secure! Kudos for that, to all people maintaining Debian infrastructure! You rock! (And I will never ever complain about slow buildds or packages which stay in NEW for too long )

I'd decided ahead of time that I wanted to use Internode as my ISP, and had ordered a Naked DSL service from them and also decided to bundle my mobile phone with them as well. For reasons that only made sense to me 7 years ago, I've been paying Telstra to keep my mobile number going, but I've long since lost the SIM. My current phone has a micro-SIM anyway, so I needed a replacement SIM. My grand plan had been to order the SIM, order the number port from Telstra to Internode, and then, well, profit from the moment I stuck the SIM in my phone. Unfortunately the port didn't go through as planned, and I was left incommunicado for the better part of two and a half days. I felt like I had my hands tied behind my back not having a mobile data service. It was also mildly annoying not being able to call people or be contactable, given the amount of running around I was doing. But it got resolved and is fast becoming a distant memory. The DSL service required a Telstra technician to come out (I'm not actually sure why) and that was scheduled for Thursday. I happened to catch him while he was at my building's MDF, and had a bit of a chat with him. He was a Scotsman, and I didn't get all the details, but he was going on about how he was only there to operate on the exchange side of the MDF, and I'd have to get someone else to jumper it up to my apartment. This wasn't what I expected from an installation service, but sure enough when I finally got around to plugging the ADSL modem in on Saturday morning, there was no line sync to be had. A call to Internode confirmed that he'd only jumpered it up to exchange side of the MDF. What was even more annoying was I'm pretty sure I saw him yanking out jumper wires from the MDF when he was working on it. Jumper wires that connected the exchange side of the MDF to my apartment. I was not thrilled with the idea of waiting (and paying) for a cabling contractor to come out and hook up a couple of bits of jumper wire, so I put out a call on Facebook for a Krone tool and a tone generator, and Brent was able to come through for me. He dropped the gear around while I was out shopping with Kristy, and when we got back, I located the pair for my unit, and rejumpered the existing jumper wire that I'm pretty sure the Telstra technician had disconnected. Lo and behold, my ADSL started working. I felt pretty proud of myself. It's fun operating at Layer 1 every now and then. The FRITZ!Box Fon WLAN 7270 is quite the beast of a box. Not only is it an ADSL modem, it's a wireless router, DECT base station, VoIP thingy and an answering machine! I've managed to connect my Engin account up to it, so once I get a DECT handset, I'll be able to make VoIP calls through it. I don't need to run Asterisk any more.

On Monday I took part in my first triathlon, a "sprint" distance race organised by Thames Turbo Triathlon Club.

Antonia came into the room. Where's Alieta? she asked. We don't know, replied Luda. It was true; we hadn't seen Alieta in quite some time, and we had no idea where she was. Antonia left. Varvara eyed me mischievously and said, You could call her. How? I asked. Touch the grandmother clock and you will figure it out. I touched the clock trepidly. Nothing happened. I opened my mouth to speak, but the word I had been about to say resonated in my mind as if spoken through a comb filter. I concentrated. Alieta, dozens of human-like voices sang over and over in different harmonies. I let go. What was that? I demanded. Clock, Varvara said dismissively. Come on, let's do laundry, Luda grunted. We carried our laundry out to the garage, which is where the washer and dryer lived. Alieta slipped in through one of the open garage doors, and surreptitiously pulled Varvara over for a whispered conversation. Antonia wandered in and squinted in Alieta's general direction. Luda quickly pulled Varvara in front of her. It's just Varvara, she announced. Antonia's eyes glazed over and she went back into the house. Alieta pursed her lips and studied the wall as if there might be some reflective object that had alerted her mother to her presence. Then she grabbed Varvara by the hand, pulled her over to push the buttons that closed the garage doors, and dragged her into the house. I watched the garage doors close. Then I watched the one on the left reverse direction. I opened my mouth to notify someone of this, but the doors reversed direction again, and proceeded to partially open and close as if possessed. I tried to hide behind Luda, without success. Now she was watching as well, as reality seemed to to shimmer and bend. The roof became arched, and there were loud mechanical noises as our environs transformed. When it finished, the place where the garage doors had been was now a wall of screens displaying video as you might encounter in a television store. More disconcertingly, we were in front of a railing which overlooked what appeared to be a car dealership showroom. Luda sucked in her breath. Benjamin Snow, you were into some serious shit, she muttered.

This was the first "normal" (i.e. not part of the Easter "long weekend") day. As it happened, Easter Monday was surprisingly retail-friendly anyway. My friend Kristy picked me up in the morning, and we dropped past the real estate agent for my apartment to see if the tenants had happened to drop the keys back yet (they hadn't) and then we went to Ikea and bought a bed for Zoe a bunch of other random stuff. I also bought a bed frame and mattress while we were at the neighbouring Logan MegaCentre (it's not a bad shopping centre) The bed frame is wooden and is taking 6-8 weeks to be made, so in the meantime, because I bought a mattress from them, they're lending me a mattress base. That's getting delivered on Saturday. We then headed over to Harvey Norman in Fortitude Valley. We'd just got started there when the real estate agent called to say the tenants had dropped the keys back, so we stopped and headed back over to meet the property manager at the apartment and get the keys. After that, we headed back to Harvey Norman and bought a fridge, TV, and a bunch of small appliances, and then headed back to the apartment to do some Ikea assembly. We'd just about finished putting Zoe's bed together when we discovered we'd gotten the wrong width slats for her bed. It turns out there are two widths of the "Sultan Lade" slats, and they're right next to each other in the warehouse. We'd picked up from the correct location, but I think the piles had become jumbled. Lesson learned: cross check the SKU as well as the pickup location. It was a long day, and I was enormously grateful to Kristy for driving me all over the place, and generally helping me shop. I think it ended up being a 15 hour day for her.