Search Results: "ema"

24 October 2013

Daniel Pocock: Final report on GSoC 2013 projects

Google Summer of Code finished recently. This is the first year that I have participated as a mentor for the Debian Project. Its a big responsibility to be part of the Debian team and to be one of the Debian team members representing Debian at the GSoC Mentor Summit. Birthdays all round This has been a particularly important year for the Debian Project, as the project celebrated our 20th birthday recently, on 16 August 2013, one of the final days of DebConf13 in Switzerland. GSoC celebrates its 10th year in 2014, with a generous 10% boost in the student stipend to mark the occasion. Google: don't be evil Google's "Don't be evil" approach to business has always been an interesting point for discussion. In my view, there are few cases of absolute good or absolute evil that we can universally classify and agree on. At a more pragmatic level, various people have commented that GSoC is a recruiting program for Google: some have even cited this as a reason not to participate. This is a more interesting point for discussion. The results of the program are not exclusive to the headhunters at Google. Anybody can browse through the Debian GSoC weekly student reports from each student to find out exactly what the students were up to and try to recruit them. Mentors and the projects they belong to have not been forced to sign any wide-ranging non-disclosure agreements or non-compete agreements with Google. In one recent example, the xWiki open source project even went as far as setting up a new office in Romania and employing some former GSoC students on a permanent basis.
Assorted images from Iasi, Romania, where xWiki set up an office employing former GSoC students How does Google benefit then? Well, there appear to be several possibilities:
  • Generating a huge amount of goodwill and recognition for the value that they place on the development of the next generation of software engineers
  • Stimulating the expansion of high quality free software projects, many of which they use directly or indirectly for their internal projects
  • Access to private evaluations prepared by the mentors. These evaluations don't take more than an hour for the mentors to complete but they do serve to give Google's headhunters a slight headstart over anybody else who is scouring the web for the names of graduates who completed GSoC
Overall, it appears to fit the definition of a "win-win" scenario: yes, Google gets stuff out of it, but the benefit is not exclusive to Google and projects like Debian are winners too. My initial approach I started by reviewing some of these materials: One particular concept that I took note of was the need to give students some opportunity to be innovative and original in their project proposals. In other words, it has been suggested that students should not be given a precise specification: rather, they should be given some very general concepts or goals and asked to suggest some funky, innovative new idea. The wisdom of this approach varies. If your free software project has some very specific gap that you need to fill, you may only be interested in taking a student who can fill that gap and you may not want to waste the time of other applicants. On the other hand, if you do precisely document this gap you want filled, you may get a bunch of very similar proposals from students and it may be more difficult to distinguish which of them is the most desirable candidate. Furthermore, if your expectations are too rigid, you may not benefit from a top-gun coming in and contributing some really exciting piece of work that you hadn't even thought of. In the end, I opted for providing more generic project briefs and looking at how students responded. The briefs that I published are available here. Coding tasks during the selection process There is no doubt about it, coding tasks are an important part of ensuring students are capable of development work before they are selected. They are also very important for us as mentors. It is not uncommon for some of us to be completely out of touch with the capabilities of other developers. The coding tasks completed by the students during the selection phase allow us to get a feel for their capabilities and set reasonable expectations for how much they can achieve during the course of the project. To simplify the management of coding tasks and engage the students in the Debian community at large, I decided to create tasks as wishlist items in the Debian bug tracking system, such as this dynalogin bug report. The prospective GSoC students were asked to put their name in the bug tracker to take ownership of the task they would complete. Student project proposals For the real-time communications project, I felt all the students slightly underestimated the complexity of this field and would have to be extremely lucky to complete everything they hoped to. After all, this is a field that the free software movement has been wrestling with for years without gaining the upper hand. For somebody with good knowledge of the projects in this space, it is possible to guide the students towards meaningful and achievable subprojects. Nonetheless, the proposals were useful for me in understanding which part of the topics were most attractive to the students. For the other project areas, the student proposals were slightly more specific. Fabian's appeared to be the most specific and well considered proposal for the one-time-password project, in fact, it appeared very much like a project that he could work through from start to finish. Debian teamwork Anybody looking at the GSoC web site will notice that there is a certain amount of overhead in joining the program, promotion, payment administration and optional participation in the GSoC Mentor Summit. As a large organisation, Debian established a dedicated SoC administration team who looked after the GSoC and Outreach Program for Women administrivia. As a developer and mentor, I found this arrangement was highly effective and allowed me to focus over 99% of my efforts on the front-line work, selecting students and supporting them through their projects. Project results One of the more controversial issues during the Debian 7 (wheezy) release cycle was the inclusion of the Mumble voice conferencing software. Although the software has some serious issues, it was eventually escalated to the technical committee and allowed to remain in Debian, partly due to lack of any alternative. One of the first results from Catalin's project was the creation of an alternative, the new reConServer project, based on the librecon conversation manager API from the reSIProcate SIP stack. reConServer is a significantly more generic solution than Mumble, as it allows any SIP peer to participate in an audio conference. It supports TURN for NAT traversal too. Catalin then went on to make the first working implementation of a scheme for passing context information from a web site to SIP WebRTC call as described in the IETF draft. All work has been integrated into release tarballs and packaging. Fabian worked through the latest standards for one-time passwords, extending the oath-toolkit and dynalogin projects to implement mutual two-factor authentication with just about any arbitrary crypto suite using one-time passwords. This work is yet to be merged into an official release of dynalogin as it requires co-ordination with the oath-toolkit release and package updates. However, there is a compelling demonstration in his video from DebConf13 and the source is available under Fabian's github account. In the post-Snowden world, the work from both of these student projects will be hugely valuable to people wanting to tighten up their computer security and communication security practices. The development process Deciding to mentor more than one project turned out to be a worthwhile decision. At first, this might seem like a big risk but it is manageable with support from co-mentors. The upside is that different students work at different speeds, they have different code styles, they even work at different times of the day or week and mentoring more than one student/project allows the mentor to gain a better appreciation of how the students differ than if mentoring only a single project. For Catalin's project, it became obvious at an early stage that he would benefit from having a dedicated server to run the VoIP applications on public IP addresses and low-latency networks while testing them. I spun up a virtual machine with IPv4 and IPv6 in my Xen Cloud Platform and this was extremely helpful for both of us. Throughout the project, I took a hands-off approach and often left the students to their own devices. I gave some suggestions to Catalin about the object-oriented design and this was enough for him to fill in the gaps and write all the code by himself. Fabian's project had fewer ambiguities and he was able to use existing code as a model more frequently than Catalin. It is possible that the students may have produced more code if I had thought through the designs myself and given them definite blue-prints. However, I feel that this would have made it harder for me to appreciate their own abilities and test the limits of their design skills. DebConf13 participation One of the highlights for the students was their participation in DebConf13. Both students presented a session at the conference showcasing some of their work. The DebConf video team produces high quality videos of all sessions at the conference and this in turn provides some great evidence of the students' capabilities and what GSoC adds to Debian and the wider free software universe. I would encourage other mentors to actively contemplate ways to involve their students in conferences during or shortly after the completion of their project work. Looking ahead Google has recently confirmed that Google Summer of Code will be repeated in 2014. It is the 10th anniversary of the program and to celebrate, students will get 10% extra pay. Thank you There are many people to thank for the success of these projects and the wider success of the Debian GSoC team:
  • The Debian GSoC and OPW organisation admin team
  • Google and the Google Open Source Programs Office
  • All the co-mentors who assisted on these projects with me: Simon Josefsson, Luke Faraone, Sylvain Berfini, Eloy Coto and Jes s P rez Rubio
  • The students themselves, C t lin Constantin U urelu and Fabian Gr nbichler
  • All the other very capable and motivated students who applied, submitted code samples but were not selected to participate: many of these students could have also completed a successful project and turning them away is one of the most difficult tasks for mentors in a volunteer organisation like Debian

Steve Kemp: Some things change, some things do not.

After seven years working from home I've resigned from my position at Bytemark. Why? A combination of wanting to do something different coupled with the desire to reclaim my second bedroom, which is currently tied up as an office. Working in an office in the future will be weird ("You mean I have to get dressed every day?!") but hopefully not unduly burdonsome. My two-year plan still remains in effect: Pay off this flat as soon as possible, then purchase another and rent this one out. Giving me some income of my own, which I will need. The "five" year plan involves me quitting work, so that I can stay home and raise children. That makes sense because sometime next year I'll become the partner who earns the least amount of monies, and I'll also be the partner with the lowest upper-bound on salary potential (short of moving to London/similar which I've always ruled out). Having rental income for myself means I'm not utterly dependant on other money, and all being well this place will be 100% paid off within 18 months. (After that lots of saving will take place for a deposit for the second place. We did bid on a couple of places locally, which were outstanding, but it is perhaps for the best we didn't win them. No more looking at ESPC!) Bytemark now becomes a company I recommend 100% for hosting in the UK. In the past I've always said nice things, but I've not strongly recommended them/us, because I'm too biased. All my personal hosting, except for one virtual machine, will remain at Bytemark indefinitely. Lovely, flexible, and great. (I have one outside guest for the purposes of diversification. That currently lives at Mythic Beasts.)

Russ Allbery: Review: Applied Cryptography

Review: Applied Cryptography, by Bruce Schneier
Publisher: John Wiley & Sons
Copyright: 1996
ISBN: 0-471-11709-9
Format: Trade paperback
Pages: 621
This is the next entry in the series of Russ reading books that he bought years ago and never got around to reading. Thankfully, this time, the book has aged somewhat better. This review is for the second edition of Applied Cryptography, published in 1996. Given how important computer security has become, and how central cryptography is to computer security, one might think that the passage of 17 years would make a book effectively obsolete. This turns out not to be the case. Yes, Rijndael (the current AES standard and the most widely-used block cipher), Camellia (the up-and-comer in the block cipher world), and the SHA-2 hash postdate this book and aren't discussed. Yes, there have been some further developments in elliptic-curve public-key cryptography. And yes, much of the political information in this book, as well as the patent situation for public-key cryptosystems, is now mostly of historical interest. But a surprising amount of this book still applies directly. Partly that's because much of Applied Cryptography is focused on general principles, classes of algorithms, and cryptographic protocols, and those do not change quickly. A rather amazing number of techniques and protocols still in widespread use today originated in the 1970s. Block ciphers, stream ciphers, cipher modes, public-key systems, signature systems, hash functions, key exchange, secret splitting, key management, and other, similar topics have not changed substantially. And even in the area of specific algorithms, DES is still in use (unfortunately) and its analysis is valuable for understanding any block cipher. RC4, Triple DES, CAST, RSA, MD4, MD5, and SHA-1 are still part of the cryptography landscape, and Schneier was already warning against using MD5 in 1996. The source code included in this book has, thankfully, been made obsolete by widely-available, high-quality free implementations of all common ciphers, available for any modern operating system. But the math, the explanations, and much of the cryptanalysis is still quite relevant. While it contains a comprehensive introduction to cryptographic concepts, Applied Cryptography is structured more like a reference manual than a tutorial. The first two chapters provide some foundations. Then, a wide variety of protocols, from the common to the completely esoteric, are discussed across the subsequent four chapters. There are four chapters on the basics of ciphers, another chapter on the mathematics, and then the longest part of the book: twelve chapters that provide a tour of all major and several interesting minor protocols that existed in 1996. These are organized into block ciphers, stream ciphers (and pseudo-random number generators), hash functions, and public-key systems. An entire chapter is devoted to the history and analysis of DES, and I think that was my favorite chapter of the book. Not only is it worth understanding how DES works, but it also provides a comprehensive introduction to the complexities of block cipher design, the politics of interactions with the NSA, and a fascinating history of early computer cryptosystems. Finally, Applied Cryptography closes with chapters on real-world systems and on politics. The politics section is mostly a historical curiosity, as is much of the chapter on real-world systems. Schneier discusses some of the PKCS and X.509 protocols here but doesn't use SSL as one of his examples despite its specification predating this book (perhaps the most glaring omission of the book). But he does discuss Kerberos (which is of personal interest to me), and it was useful to see it analyzed in the broader context of this sort of book. Those who read Schneier's blog regularly, or who have read any of his other books, will know that he's concise, incisive, and very readable, even with difficult material. I think he does err on the side of compactness this is not a book that handholds the reader or explains something more than once but there's a lot of ground to cover, so I can't really blame him. Expect to have to read the more difficult parts several times, and (at least on a first read) expect to just skip past some of the most complex sections as probably not worth the effort. But I think Schneier does a great job structuring the book so that one comes away with a high-level impression and overview sufficient to make informed guesses about capabilities and relative difficulty even if one doesn't have the patience to work through the details. I suspect most readers will want to skim at least part of this book. Unless you're willing to do a lot of background reading to understand the math, or a lot of careful study to follow the detailed descriptions and flaws in often-obscure algorithms, the algorithm discussions start to blend together. I found myself skipping a lot of the math and focusing on the basic descriptions and the cryptanalysis, particularly for the obscure ciphers. Many of the algorithms are also highly opaque and of obscure benefit; I doubt I will ever care about blind signatures or oblivious transfer, and I struggled to wrap my mind around the details of bit commitment (although it's apparently important in zero knowledge proofs, which in turn are relevant to authentication). But this is not the sort of book where you have to read every word. It's very well-structured, provides clear resynchronization points for readers who have had enough of a particular topic, and marks the topics that are more obscure or of dubious general usefulness. The most useful parts of this book, in my opinion, are the basic conceptual introductions to each class of cryptographic algorithm or protocol, and those chapters are excellent. I've been working in applied computer security, at the application and deployment level, for years, and this is the first time that I've felt like I really understood the difference between a block cipher and a stream cipher, or the implications of block cipher mode selection. Applied Cryptography is also a fascinating exercise in adjusting one's intuition for where the complexity lies. It's a memorable experience to move from the chapters on block ciphers, full of S-boxes and complex mixing and magic numbers, into the far more straightforward mathematical analysis of stream ciphers. Or the mathematical simplicity of RSA (although quite a bit of complexity is lurking on the cryptanalysis side, much of which is only touched on here). Of more historical interest, but still quite impressive, is that Applied Cryptography doubles as a comprehensive literature review. Not only does it cover nearly every algorithm in use at the time, it discusses the cryptography literature on nearly every topic with brief summaries of results and lines of investigation. The references section is a stunning 66 pages of small print featuring 1,653 references, and those are mentioned and put in context throughout the book. I'm not personally interested in chasing those lines of research further, and of course 17 years means there are many new papers that are as important to read today, but it's obvious that this book would have been an amazing and invaluable map to the research territory when it was first published. There are now newer books on this topic that you should consider if you're purchasing a book today. Cryptography Engineering in particular is in my to-read pile, and I'm interested to see how much of this book it could replace, although I believe it's lighter on the mathematical analysis and details. But I think Applied Cryptography still has a place on the bookshelf of any computer security professional. Schneier is succinct, detailed, straightforward, and comprehensive, at least for 1996, and I know I'll be reaching for this book the next time I forget the details of CFB mode and then get hopelessly confused by the Wikipedia article on the topic. Rating: 8 out of 10

23 October 2013

Rog rio Brito: Assorted random notes

This post is just a bunch of random notes, but I think that things are going well, this time.

Btrfs Just started playing with btrfs after converting a 2TB disk with about 1.3TB of data from ext4 to btrfs. This particular filesystem contains my backup data and I hope that btrfs is able to live up to high standards. I will probably write a detailed review with my impressions, but suffice to say that it is working fine and I hope that I will be happy for a long time to come. My other filesystems, for the moment, will be ext4.

Coursera Downloader Thanks to John Lehmann's generosity, now coursera-dl has a new home: a github organization of its own!

youtube-dl Some people may have noticed, others may not, but when downloading videos from Youtube, they apparently are getting more aggressive with the use of Dynamic Adaptive Streaming over HTTP (also called DASH) and, as a result, some (perhaps going to be all in the near future?) of the videos may not be available in the resolution/formats that you used to like (like me, with format number 35). By the way, one thing that is interesting with youtube videos provided via DASH is that they are available in different streams: one for the video and another for the audio. What does this mean in practical terms for users of youtube-dl? Well, if you wanted to download videos in resolutions like the 480p (format 35) that I mentioned, then you will probably have to change your way of doing things, until a more automated solution is in place. You will have to download both the audio and the video and, then, "combine" them (that is, multiplex them) to create one "normal" video file with both the audio and the video. I usually do this via: ffmpeg -i audio.m4a -i video.mp4 -vcodec copy -acodec copy combined.mp4 If you prefer having a Matroska container instead of an mp4 container (which, BTW, results in smaller muxing overhead), then you can use the command line: mkvmerge -o combined.mkv audio.m4a video.mp4 Oh, those m4a and mp4 extensions are a new addition that I just sent upstream (in the past, both would have been named with an extension of mp4). As, an aside, I like formats 135 for video and 140 for audio, for the reasons that I mentioned in a comments to issue 1612:
Otherwise, to download 480p videos (which I do for lectures and so on with other projects of mine, like edx-dl) I have to call youtube-dl twice: once for format 135 and another for format 140, since the old (?) format 35 files are much smaller than the lower resolution 360p files (due to the former being encoded in High profile vs. the latter being encoded in Constrained Baseline profile).
While this is unfortunate for some, this is a good thing for others: I once had a blind user of youtube-dl asking me if he could avoid downloading the whole video just to extract the audio, so that he save on bandwidth. Well, now this is possible. Expect a new version of youtube-dl to be uploaded soon to Debian unstable.

Music It is so nice to see the music that I like getting better. It was particularly pleasant to see Tarja Turunen being joined on stage by Floor Jansen. In fact, it is my impression that the once female-fronted bands are getting more and more into collaborations and side-projects and they are, in many ways, getting more refined. Examples of this includes Floor, Tarja, Anneke van Giersbergen, Sharon den Adel, Kari Ruesl tten and many others that I can't remember right now. Of course, some thanks to people that take the time to film, and upload/share the videos so that other people not at these events can watch them is highly appreciated and they usually are treated as anonymous, but, of course, this should be fixed.

Russell Coker: Thinkpad T420

I ve owned a Thinkpad T61 since February 2010 [1]. In most ways it s a great system and it still does most things that I require, even though it inspired my post about how modern laptops suck [2]. Problems with my T61 The biggest ongoing problem with my T61 was the heat production, I m not sure how much of it was due to the CPU producing heat and how much was due to the cooling system not removing it fast enough. But any serious computation for even a relatively small amount of time caused it to get close to thermal shutdown. But as I mostly use my laptop for reading email, a SSH client, and coding (for which the big compiles are done on servers) that didn t force me to replace it. The next problem was the battery life, it s expected that laptop batteries degrade over time so it wasn t a surprise that after 3 years my T61 battery only lasted for about 15 minutes. A final problem is the screen which didn t seem to be as bright as it used to be, it s annoying but doesn t compel me to buy a replacement. T61 Failure But in July my T61 stopped working, it appeared to be either the power supply or something internal related to power, it had been running but was suddenly powered down after being left alone so for some reason power wasn t getting from the wall to the laptop. I initially thought that it was the power supply at fault and investigated the price of a new PSU and a new battery as well. The Lenovo online store [3] charges $71.90 for a new PSU and $113 for a regular capacity battery or $156 for an extended capacity battery (50% more power). So based on the assumption that the PSU was faulty that meant a cost of $185 or $228 (maybe more if postage is included) to get the old Thinkpad going again. I could probably get the parts cheaper from somewhere else, but I m hesitant to buy batteries from sources that aren t reliable in case I get one that s been used. Buying at Auction I ended up buying a refurbished Thinkpad T420 (product ID 4236-J73) from Grays Online [4]. It was refurbished and cost me $306.35 including delivery. $306.35 for a new laptop including PSU was a much better deal than buying a new PSU and battery for $185 or more. It turned out that the PSU wasn t broken (a different PSU also didn t work with it) but then my Thinkpad T61 just started working again, presumably it has some intermittent fault related to power and needed to be replaced anyway (I use my laptop for work and can t have it fail randomly). One significant problem when buying a Thinkpad is that the model numbers aren t specific to the hardware specs. According to ThinkWiki the T420 model ranges from a 2.1GHz i3 to a 2.8GHz I7 CPU, from 160G to 500G hard drive, and has either a 1366*768 or a 1600*900 display [5]. Auction sites almost always specify the size of a hard drive and usually the exact CPU speed doesn t matter much for an auction purchase (2.1GHz is fast enough for most things). But the display resolution is a big deal, in this case Grays had multiple Thinkpads on offer with the same description and the same price so bidding on one with high resolution was quite important. Lenovo has a web site for discovering Thinkpad specs, this is the current link for it (it changes periodically) [6]. At that page you can specify the TYPE AKA PRODUCT ID that is printed on the back of a Thinkpad (and usually included in an auction listing) in the search field that s currently described as QUICK PATH and get all the specifications. Lenovo really do a great job of providing all the details for their products (including ones that were obsolete years ago). But it s unfortunate that their web site sucks, there should be a single URL for such things that s easy to find and they shouldn t use cookies to track which model you are looking at because it makes it really difficult to research two different models. Comparing T61 and T420 I upgraded my new Thinkpad to 8G of RAM because RAM is really cheap. I bought it with 4G of RAM which didn t seem to be quite enough as the hard drive is slow for paging (my desktop with 3G of RAM and a SSD performed well for similar tasks). Now it s running really well, my new Thinkpad is a lot cooler than the old one (not being broken is a good thing). My T420 has a screen resolution of 1600*900 which was a little disappointing initially when going from 1680*1050 (18% fewer pixels and 2% fewer than the T41p I used previously). But having a smaller screen means that the Thinkpad is a lot smaller and lighter. My T61 didn t fit in most backpacks and laptop bags and was unreasonably heavy, it s the type of laptop that looks good on a spec sheet but doesn t seem so good when you carry it around for a few hours. Not only is the T420 a lot smaller and lighter than the T61 but the power supply that shipped with it is a lot smaller and lighter too. I might have spent $72 a few years ago to buy a lighter PSU if I knew that was an option. Cost of Ownership Thinkpads are getting so cheap at auction that I m tempted to buy myself an X series as well. When a $300 item can last several years (my T41p was from some time before 2006, my T61 was from 2010, and my latest is from 2013) that brings the cost of ownership down to something like $0.25 per day. If I bought myself a Thinkpad X series (ultra light) as well at auction then I would be looking at maybe $0.50 per day for my laptop use which would give me the option of taking a light laptop to a conference and a bigger laptop for spending a day at a client site.
Related posts:
  1. I Just Bought a new Thinkpad and the Lenovo Web Site Sucks I ve just bought a Thinkpad T61 at auction for $AU796....
  2. Thinkpad T61 I ve now had my new Thinkpad T61 [1] for...
  3. A Long Laptop Lifetime Paul Russell writes about his 3-yearly laptop replacement at IBM...

Russell Coker: LUV Hardware Library after 20 Months

20 months ago I started the LUV Hardware Library [1]. The aim of the project is to provide a repository of free spare parts for computers for the use of club members. People who have parts that are good but which they can t use can donate them and others who need such parts can take them. Some people have criticised my choice of the name Hardware Library because the word is associated with borrowing while with my Hardware Library it is expected that noone will return the item that they take. The Wikipedia page about libraries is worth reading, my interpretation of that is that the essential aspect of a library is that it is a public collection of items that are useful for study and that borrowing is just one thing that can be done. A book library could consist of a service of printing free books on demand (anyone could do this with access to The Gutenberg Project [2] and a printer) or of just making them available to download. Many libraries don t allow books to be borrowed, they just allow them to be studied and copied in the library. Also every general public library has reference items that can t be borrowed, it s typical for a library to have a full encyclopedia which is not available to be borrowed. Also with the Hardware Library people feel obliged to give something if they take something (as happens with a geocache), so there is an issue of returning something. My main aims with the Hardware Library were to save people money on parts and to help the environment by reducing the need to buy new computers when old ones can be upgraded and remain in service. My next aim was to help people learn about hardware by providing free parts, when a mistake has no financial cost people are more willing to experiment and will learn more. I believe that those aims have been achieved. More Successful Than Expected One thing that surprised me is the social aspect that developed. I had expected that most people would just find some parts that they need and not look at it again for some months. I had also anticipated that some people would poll the Hardware Library every month in the hope that a part they needed might appear. I didn t expect that people would look through it every month because they just like looking at old hardware. I also didn t expect groups of people to hang out by the Hardware Library to discuss various issues related to PC hardware and Linux. During the breaks in the main meeting the location of the Hardware Library often becomes a focus for discussions of various issues related to Linux and hardware. I think that this is really advancing the aims of LUV [3] and I think that members of other LUGs should experiment with similar projects. Starting this didn t require any special skill or authority. I just started bringing a briefcase full of parts to meetings and offering them to whoever was interested. Any member of any LUG can do the same. To start something like this you wouldn t even need a collection of parts, you could just bring a box and ask for donations.
Related posts:
  1. LUV Hardware Library What is it? Last month I started what I am...
  2. Giving Away Hardware For the last few years I have been actively seeking...
  3. Shelf-life of Hardware Recently I ve been having some problems with hardware dying. Having...

Russ Allbery: Review: Lean In

Review: Lean In, by Sheryl Sandberg & Nell Scovell
Publisher: Alfred A. Knopf
Copyright: March 2013
ISBN: 0-385-34994-7
Format: Hardcover
Pages: 217
Lean In is normally listed as written only by Sheryl Sandberg, which is also what's on the dust jacket, but the inside cover says "with Nell Scovell." Given what that normally means for celebrity books, supported by comments in the acknowledgments, I'm listing it as co-written by Scovell. However, much of the book is written in the first person and is clearly meant to be Sandberg's voice, so I will mostly refer to Sandberg as the author for the rest of the review. I was unfair to this book. Lean In made quite a splash when it first came out, since the named author is the Chief Operating Officer of Facebook, a former vice president of Google, and one of the most prominent female executives in the business world. The subtitle is Women, Work, and the Will to Lead, and the normal Internet summary was that it focused on how women could change their behavior to be more effective and successful in the business world. Throw in some ridiculous review hyperbole (one New York Times writer compared it to The Feminine Mystique, which is a bit like the comparison of every extruded fantasy product with The Lord of the Rings) and I was ready to hate this book. It's work advice from someone in a very privileged position, and it seemed to have a distinct whiff of victim-blaming. It's obvious, however, from the first few pages that Sandberg was very aware of this trap and had no intent of falling into it. This is hard: giving practical advice to women on how to navigate a sexist culture runs a severe risk of victim-blaming even with the best of intentions, particularly since part of the sexism of the culture is a pervasive impression that women aren't doing enough. But I think Lean In handles that about as well as one could while still writing a book focused on practical advice rather than revolutionary change. Sandberg is clear that many things women can do to help their careers shouldn't be necessary, and she takes some time, in each section, to talk about the shape of any structural unfairness that she's seen. What advice she offers here is clearly in the spirit of how to navigate a system that is unfair and unequal, but which can be navigated and can be made more fair by more women participating. This is a very practical book, with more in common with business self-help books than with feminist critiques. It's also a narrowly targeted book, not that you'd guess this from the number of copies it's sold and the sort of publicity it got. Lean In is advice to female executives about how to navigate the top levels of US business culture, with a strong eye for issues of feminism, gender-based double standards, and potential traps of self-sabotage. It offers a blend of encouragement, practical tips, and some forthright analysis that tries to bring to the surface internalized sexism and perceived barriers and limitations for female executives so that they can be addressed and hopefully overcome. It's not in any way a revolutionary book, either with respect to business culture or with respect to gender roles; rather, it's an open acknowledgment of a whole bunch of problems combined with practical advice for how to work around those problems until they can be solved. For the most part, it doesn't attempt to address how to solve the problems. There is nothing wrong with that as a focus for a book. Lean In has attracted a fair bit of criticism in some circles, but, after reading the book, I think a lot of that criticism is predicated on assuming different goals than this book actually has. Contrary to various glowing reviews, Lean In is not a book that's going to change the world; rather, it's a book that might help a narrow band of the population in a specific job and career path navigate problems of sexism and gender expectations and be more effective. Read in that light, it struck me as honest, open, considered, and well aware of its own limitations. Sandberg says repeatedly that many of the options she discusses simply aren't available to most women, and that women may not be in a position to be able to make the decisions she made. She's quite forthright about the limitations of her own experience and the limitations of the advice that she offers, and I think deserves full points for honesty. Similarly, when it comes to business culture, Lean In is not about changing that culture for the better. It's about navigating that culture as it exists. Here, I think Sandberg is less aware of the limitations of this perspective; there is far less acknowledgment in Lean In that executive culture may be inherently toxic as there is of the limitations that women face in business. But while Sandberg has an obvious blind spot, this is not a paean to overwork. It has some excellent advice about work-life balance, including the need to put strict limits on the amount of time one spends in the office and the necessity for someone to pick up substantial burdens in the home if one of the members of a household is going to pursue a business executive job. I was worried, going in, that Lean In would excuse, justify, or idealize the culture of exploitation so common with salaried jobs in the United States, but it really doesn't. As with feminism, it doesn't pick any deep fights, and those with a "kill it with fire" gut reaction towards US executive culture (such as myself) will find the bland acceptance of it irritating, but this is more of an issue with reader expectations than with the book. One should not expect a highway map to point out that trains are more efficient. So, I'm willing to stand up for Lean In to a degree. This is not a bad book. It's very readable, parts are quite interesting, and some of Sandberg's observations about the intersection of gender expectations and executive culture were worth hearing. I learned some things from it. But I think one should read it in full awareness of its limitations. This is a book of practical advice that will only be of direct use to 10% of the population, and which could be generalized with some effort to maybe 25%. It has little to say to women who are not in white-collar, professional jobs, and its applicability to women who aren't aiming for executive careers is a bit hazy. It's the kind of book that's full of anecdotes about how Sandberg got parking spots reserved for pregnant women at Google by talking to the founders about it, or about how to negotiate salary when offered an executive position, which are vaguely interesting but of dubious practical benefit to people who aren't offered jobs where salary and benefit negotiation is available. This isn't the fault of the book, but at times it is rather stunning how different (and how much more tractable) the world looks to someone with the wealth and personal connections that Sandberg has. (To her credit, Sandberg does seem to be aware of this and does acknowledge it.) If you are a female executive, or a male executive interested in developing your empathy and understanding of how institutional sexism affects your colleagues, I suspect Lean In would be quite helpful. If you're not, I think it's mostly a curiosity. But it's also well-written, well-organized, probably available in most libraries in the United States, and provides anecdotal data to help build a more complete picture of the concerns and experiences of female executives. Unless you're in the specific target audience, I'm not sure I'd recommend going out of your way to find it, but it's probably worth reading if it falls into your lap. Rating: 7 out of 10

17 October 2013

Don Armstrong: Using Mutt with Org Mode (with refile)

I use org mode extensively, and had added Zack's workflow for integrating mutt with org mode to my ~/.emacs some time ago. However, I've been annoyed that refiling closes the org-capture frame before refiling finishes. The following trivial modification to Zack's code (which I previously modified to work with org-mode >= 0.8) waits to close the frame until you've finished refiling. 
 (require 'org-protocol)
 (add-hook 'org-capture-mode-hook 'delete-other-windows)
 (setq my-org-protocol-flag nil)
 (defadvice org-capture-finalize (after delete-frame-at-end activate)
   "Delete frame at remember finalization"
   (progn (if my-org-protocol-flag (delete-frame))
          (setq my-org-protocol-flag nil)))
 (defadvice org-capture-refile (around delete-frame-after-refile activate)
   "Delete frame at remember refile"
   (if my-org-protocol-flag
       (progn
         (setq my-org-protocol-flag nil)
         ad-do-it
         (delete-frame))
     ad-do-it)
   )
 (defadvice org-capture-kill (after delete-frame-at-end activate)
   "Delete frame at remember abort"
   (progn (if my-org-protocol-flag (delete-frame))
          (setq my-org-protocol-flag nil)))
 (defadvice org-protocol-capture (before set-org-protocol-flag activate)
   (setq my-org-protocol-flag t))
Now, the frame automatically disappears after you refile it, keeping my refile.org clean.

16 October 2013

Matthew Garrett: Standing for the Linux Foundation Technical Advisory Board

According to its charter, the Linux Foundation Technical Advisory Board exists "to advise The Linux Foundation Board of Directors (Board) and the management of The Linux Foundation (Management) on matters related to supporting the technical agenda of The Linux Foundation". It consists of 10 members, with 5 seats up for election each year. Elections take place at an event at Kernel Summit, but are also open to attendees of whichever conference is colocated with the Kernel Summit that year. The election announcement is emailed to the Linux kernel list and tech-board-discuss, a mostly moribund list that springs into life once a year for election announcements.

This arrangement seemed odd to me even back in 2007. Back then the Linux Foundation was already sponsoring development of certain non-kernel components, and now that list is even larger. While nominally open to all, nominations for the TAB tend to end up being people actively involved in the kernel community. That's probably better than people limited to any other single technical community (kernel developers tend to end up dealing with bugs from a fairly wide range of projects, so they're not entirely unaware of what other people have to deal with), but it still seems suboptimal. The current membership is mostly limited to people who spend little to no time working with userspace developers, let alone anyone active in other Linux Foundation projects. I don't think this is a good thing

So, after several years of considering it, I'm finally standing for the TAB. I've been an active developer at most levels of the Linux stack, from the kernel through to desktop environments. I've worked closely with distributions. I've even worked closely with firmware developers. I'm not intimately involved in any of the other Linux Foundation projects, but I have experience that allows me to better understand their needs and motivations than I'd have from having spent my entire life living in the kernel. Being on the TAB would make it easier to ensure that these projects are represented in a meaningful way.

Of the other people who I know are standing (and this list may well grow longer), I'm inclined to vote for:
The election is currently scheduled to be National Museum in Edinburgh on the evening of the 23rd of October. If you're attending Linuxcon or one of the colocated events, please do come along and vote.

(Updated to correct a typo)

comment count unavailable comments

Carl Chenet: Brebis 0.7, the fully automated backup checker

Follow me on Identi.ca or Twitter The new version of Brebis Chevillette 0.7 was published two days ago. Brebis is a fully automated backup checker. Brebis does not create backups. It only performs controls on them. Brebis is able to detect a corrupted archive compressed with different formats, automatically checking the integrity of your archives and lots of parameters of the files inside these archives or inside a tree of files and provide detailed reports if unexpected states are detected. Check out the list of the supported features. What s new? The main features of this new version are: Complete example of installing, configuring and running Brebis How to install from your package manager Brebis is available in Debian, FreeBSD, Archlinux and Frugalware. Use your favorite package manager to install it. How to install from the sources 
# wget http://brebisproject.org/attachments/download/8/brebis-0.7.tar.gz
# tar zxvf brebis-0.7.tar.gz && cd brebis-0.7
# python3.3 setup.py install --install-scripts=/usr/bin
# mkdir /etc/brebis
What you need before running brebis Our goal is to check on a regular basis the archive /backups/monthly-backup.tar.gz. Brebis needs two files in order to correctly run: a configuration file with general parameters and the list of files with all their parameters. Don t be afraid, both of theses files will be generated by Brebis with the following command: 
# brebis -G /backups/monthly-backup.tar.gz
# ls /backups/
monthly-backup.tar.gz monthly-backup.conf monthly-backup.list
All the files inside your archives have been detected and their names and parameters (uid, gid, mode, md5, ) have been written in the file monthly-backup.list. More information about those files. How to configure Brebis Lets save /backups/monthly-backup.list in /etc/brebis: # mv /backups/monthly-backup.list /etc/brebis For /backups/monthly-backup.conf, we just modify the files_list parameters: 
[main]
name=monthly-backup
type=archive
path=/backups/monthly-backup.tar.gz
files_list=/etc/brebis/monthly-backup.list
We also save monthly-backup.conf in /etc/brebis: # mv /backups/monthly-backup.conf /etc/brebis Use Brebis Using Brebis is as simple as: # brebis -c /etc/brebis/ -l /var/log/brebis.log If there is not any difference between the current state of your backup and your list of file, the logfile /var/log/brebis.log will be empty. If any difference happens, they will be reported in /var/log/brebis.log. Show time. I m modifying the md5 hash sum of a file in /etc/brebis/monthly-backup.list, during the next run of brebis, I get the following content in brebis.log: 
WARNING:root:1 file with unexpected hash while checking
/backups/monthly-backup.tar.gz:
WARNING:root:toto/titi hash is ce4f8cacd8fc702bdd03531b9447818b.
Should have been ce4f8cacd8fc702bdd03531b94478184.
As you can read, Brebis reports a difference between what was expected and what it checks. Now it s easy to do the same for any backup you want to check on a regular basis. Just add something like the next line in /etc/crontab: 01 00 * * * root brebis -c /etc/brebis/ -l /var/log/brebis.log A brebis run will happen every day at midnight to check your backup. Every configuration files in the directory /etc/brebis/ will be inspected. Feedback about Brebis We at the Brebis Project welcome any feedback about Brebis. Feel free to subscribe to the Brebis-users mailing list, by Twitter or email me directly at carl.chenet@brebisproject.org 
Official website: http://www.brebisproject.org
Mailing-list: http://lists.sourceforge.net/lists/listinfo/brebis-users

15 October 2013

Daniel Pocock: Debian Outreach Program for Women 2013

Debian's Outreach Program for Women (OPW) is underway. This is a huge thing and not just something that female developers need to be concerned with. Untapped potential Many computer science schools see about twenty percent of places occupied by female students. In the Debian community, however, about one percent of developers are female. As there are about one thousand male developers, this suggests there are another one hundred potential female developers and contributors out there who are not aware of the fact that they could be part of Debian. Finding these people and helping them fulfil their potential makes the project better for everybody. Women are heavy lifters People should not assume that these women are going to need their hands held. When the Jitsi project recently moved to Github, the Github repository reports made the surprise revelation that Yana is the top contributor - by a fifty percent margin. Will women save the world this week? It is not just in software engineering that women have significant potential. As the men running the US bumble around with their high-stakes game of chicken, it is notable that last week the US Federal Reserve appointed their first female chairman, Janet Yellen. It is unlikely that her first meeting with female IMF boss Christine Lagarde would have satisfied stereotypes about casual gossip or shopping; more likely, they would be contemplating how to save the world economy if rogue congressmen push the US into default - a possibility that is no longer just an outlier. Integrating financial software in Debian With that in mind, one of the projects I've offered to mentor under OPW involves creating further integration between free software for finance and accounting on Debian. Several applicants have already contact me about this. Fundraising to support OPW 2013 Debian is currently raising funds to support this program. The project administrators are hopefully going to provide more details soon about how funding will be allocated and how many projects will proceed.

Matthew Garrett: Hacker News is a social echo chamber

Hacker News is a fairly influential link aggregation site, with stories submitted and voted on by users. As explained in the FAQ, the ranking of stories is roughly determined by the number of votes divided by a function of the time since submission. It's not a huge traffic driver (my personal experience of stories on the front page is on the order of 30,000 hits), but it's notable because the demographic tends to include a more technically literate and influential set of readers than most other sites. The discussion that ensues from technical posts often includes meaningful feedback from domain experts. Stories that appear there are likely to be noted by technology workers, especially in the Silicon Valley startup field[1].

That rather specific demographic appears to correlate with other traits. There's a rather more techno-libertarian bias on Hacker News than on most general discussion forums, which is consistent with the startup-oriented culture that it springs from - the desire to provide disruptive solutions to real world problems tends to collide with existing regulatory frameworks, so it's unsurprising that a belief in individual rights and small government would overlap with US startup culture. There's a leaning towards the use of web technologies rather than traditional client applications, which matches what people are doing in the rest of the world. And there's more enthusiasm for liberal open-source licenses over Copyleft licenses, which makes sense in a web-focused environment (as I wrote about here).

Now, personally I'm a big-government, client-app, Copyleft kind of person, but for the most part I don't think the above is actively dangerous. It's inevitable that political views will vary, we'll probably continue to cycle between thick and thin clients for generations and nobody's ever going to demonstrably prove that one licensing model deserves to win over another. But what is important is that the ongoing debates between these opinions be driven by facts, and that it remain obvious that these disagreements exist. As far as technical (and even political) discussion goes, Hacker News doesn't seem to
have a problem with that. Disagreeing with the orthodoxy is tolerated.


This seems less true when it comes to social issues. When a posting discussing the myth of the natural born programmer[2] hit the front page, the top rated comment is Paul Graham[3] off-handedly discounting the conclusions drawn. The original story linked to a review of peer-reviewed scientific research. Graham simply discounts it on the basis of his preconceptions. Shortly afterwards, the story plummeted off the front page, now surrounded by stories posted around the same time but with much lower scores.

How does this happen? There's two publicised methods which can result in stories dropping down the order. Users with high karma scores (either via submitting popular stories or writing popular comments) are able to flag submissions, and if enough do so then a negative weighting is applied to the story. There's also a flamewar detector, a heuristic that attempts to detect contentious subjects and pushes them off the front page.

The effect of both is to enforce the status quo of social beliefs. Stories that appear to challenge the narrative that good programmers are just naturally talented tend to vanish. Stories that discuss the difficulties faced by minorities in our field are summarily disappeared. There are no social problems in the technology industry. We have always been at war with Eastasia.

This isn't healthy. We don't improve the state of the software industry by hiding stories that expose conflicts. Flamewars don't solve problems, but without them we'd be entirely unaware of how much of a victim blaming mentality exists amongst our peers. It's true that conflict may reinforce preconceptions, causing people to dig in as they defend their beliefs. However, the absence of conflict does nothing to counteract that. If you're never exposed to opinions you disagree with, you'll never question your existing beliefs.

Hacker News is a privately run site and nobody's under any obligation to change how they choose to run it. But the focus on avoiding conflict to such an extent that controversial stories receive less exposure than ones that fit people's existing beliefs doesn't enhance our community. If we want to be able to use technology as an instrument of beneficial change to society as a whole, we benefit from building a diverse and welcoming community and questioning our preconceptions. Building a social echo chamber risks marginalising us from the rest of society, gradually becoming ignored and irrelevant as our self-reinforcing opinions drift ever further away from the mainstream. It doesn't help anybody.

[1] During the batch of interviews I did last year, two separate interviewers both mentioned a story they'd read on Hacker News that turned out to have been written by me. I'm not saying that that's what determined a hire/don't hire decision, but it seems likely that it helped.
[2] The article in question discusses the pervasive idea that some people are inherently good programmers. It turns out that perpetuating the idea that some people are just born good at a particular skill actually discourages others from even trying to learn it, even those who are just as capable.
[3] One of the co-founders of Y-Combinator and creator of Hacker News.

(Edited to fix a footnote reference)

comment count unavailable comments

14 October 2013

Bits from Debian: Ada Lovelace Day: meet some of the "women behind Debian"!

Today is Ada Lovelace Day:
"Ada Lovelace Day is about sharing stories of women - whether engineers, scientist, technologists or mathematicians - who have inspired you to become who you are today. The aim is to create new role models for girls and women in these male-dominated fields by raising the profile of other women in STEM". source
To celebrate, we asked to some of the "women behind Debian" to share their stories with us. Enjoy! Alt Ada Lovelace portrait Ana Guerrero Lopez (ana) Who are you? I'm a 30-something years old geek. I'm from Andalusia, Spain but live in France. What do you do in Debian? I work mostly on my packages, in sponsoring new people's packages and in this very blog you're reading now. I also maintain an unofficial Google+ page about Debian. At $PAID job, I work in an internal Debian distribution so from time to time, I get the opportunity to contribute back some of the stuff we do there. How and why did you start contributing to Debian? I started using Debian around 2003 switching from Mandrake. I was a happy Debian user when the Debian Women project started in the summer 2004. When I saw the project announced, I asked myself why I wasn't contributing to Debian and the rest is history... in a couple of weeks it'll be my 7 years DD-versary! If for some reason you want a longer reply to this question, read here. Beatrice Who are you? I am a PhD student with a degree in Biology. I am a computer fan since my first C64 and I am a self-taught computer geek wanna-be. And I am a bug fan - not software bugs, real bugs :) What do you do in Debian? I work on translations - doing the translation work itself, but also reviewing other translators' work and helping in coordinating the translation effort. How and why did you start contributing to Debian? I started using Linux because I liked the idea of an open source operative system based on collaboration and I began reviewing open source software translations. Since my first Linux system was Debian Potato and I sticked to Debian ever since, it only seemed natural to focus my translation work on Debian. Christine Caulfield Who are you? My name is Christine Caulfield. My day job is principal software engineer at Red Hat working on the cluster infrastructure components corosync & pacemaker. Outside computing I'm a musician and sound engineer. I play violin with lots of technology attached, and love avant garde music. What do you do in Debian? I'm not that active on Debian any more due to pressure of time, and maturity of the packages I work on. I currently maintain the, little-used, DECnet userspace packages and the, even less used I suspect, mopd bootloader. I used to maintain lvm2 for a while but dropped that a few years ago. How and why did you start contributing to Debian? My initial reasons for joining Debian were slightly selfish, to find a home for the DECnet project that I was heavily involved in at the time. I was a keep Debian user and people wanted a distribution where the software was easy to set up. DECnet is quite complicated for users to configure, being a totally independant networking stack to IP and so OS support is needed. Debian seemed like the logical place to make this happen. As mentioned above I got quite involved for a time and maintained other packages too. I picked up lvm2 because I was on the lvm2 dev team at work in Red Hat and as it was a new package at that time I seemed a logical choice. Elena Grandi (valhalla) Who are you? I'm a 30-something years old geek and Free Software enthusiast from Italy. What do you do in Debian? I'm currently maintaining a few packages (2 python modules and a python program) as a sponsored uploader; I'm also slowly looking around for other things to do (by preference technical, but not limited to packaging), with the aim to spend more time contributing to Debian. How and why did you start contributing to Debian? For a while I had being distro-hopping between "fun" distributions (the ones that break now and then) on the desktop while using Debian stable on the home server and in chroots. I was already doing marginal contributions to those distributions, where finding stuff that was missing was easy, but my perception as a stable user was that Debian was already working fine and probably didn't really need any help. Then I started to socialize on IRC with some DDs and DMs, and realized that my perception was superficial and that in reality there were dark holes in the depths of the archive where Evil festered and prospered and... ok, sorry, I got carried away :) Anyway, since I was actually using Debian more and more I decided to start contributing: I read documentation, I attended the useful IRC sessions on #debian-women and decided that it was probably best not to add new stuff, but look for things that I used and that needed help. Then nothing happened for a while, because finding stuff that doesn't work is hard (at least on my mostly textual systems). Then one day I was trying to write a python script that needed to verify gpg signed messages; it had to run on my Debian server, so I was trying to use python-pyme and its documentation was painful to use, while I remembered an earlier attempt using python-gnupg that was much more pythonic, but not available in Debian. In a fit of anger I decided to forgo all of my good intentions and actually add a new package: I checked the sources for problems, packaged, sent it to mentors@d-o, got reviews, fixed problems, resent and finally got sponsored and well, everything started. Francesca Ciceri (madamezou) Who are you? I'm Francesca, a 30-something Italian graduated in Social Sciences. What do you do in Debian? I'm a (non uploading) Debian Developer since 2011 and have been DPN editor, press officer, webmaster for www.debian.org and translator for the Italian l10n team. Recently, due to time constraints, I had to reduce my involvement and now only work on two things: writing/editing articles for bits.debian.org together with Ana Guerrero, and creating subtitles for the DebConf talks, in the DebConf Subs team. How and why did you start contributing to Debian? Basically thanks to the sudden abundance of free time - due to an health problem - and the desire to give something back to this wonderful operating system. After that, I found out that Debian is not only a great OS but also a very special community. Today, some of my dearest friends are people I met through Debian. :) Laura Arjona Who are you? I live in Madrid (Spain), and work as IT Assistant in the Technical University of Madrid (UPM). I'm married and I have a 4-years-old son. What do you do in Debian? In 2012 I started to clean spam and to translate Debian web pages into Spanish. I also follow the work of the web and publicity team, I hope I'll get more involved there too. And of course, I'm in Debian Women :) How and why did you start contributing to Debian? I'm using Debian at work since 2007 (servers), and in my desktops since 2010. I like very much that it is a community distro and I wanted to participate. I was already doing translations in other (small) free software projects, so I began here too. The Debian-Women list, the planet, and people in identi.ca helped me to learn a lot and feel part of the community even when I was not contributing yet. M nica Ram rez Arceda (monica) Who are you? My name is M nica Ram rez Arceda and I am an enthusiast of free software and sharing knowledge cultures: for me it's a kind of philosophy of life. I studied Maths a long time ago but ended up working as a developer for some years. Now I'm working as an IT teacher. What do you do in Debian? Debian is a huge project, so you can help in various scopes. Mainly, I work on packaging, fixing wnpp bug inconsistencies in BTS and helping in spam cleaning of the mailing lists. But I also enjoy doing some non-technical work from time to time: the project I am just now involved is organizing, with the rest of Debian Catalan community, a local team to propose Barcelona as the venue for a minidebconf where all the speakers will be women. How and why did you start contributing to Debian? In 2000 I discovered Free Software world and I fell deeply in love with its philosophy. Since then, I've been trying to do my best in different activities, like spreading the word, giving free courses, helping collectives and friends in technical stuff (from installing Debian to developing some helping apps for them)... but two years ago I was looking forward to join a free software project and I decided to try Debian, since it has been my first and only distro in my day-to-day life for about ten years. So, I wanted to give back Debian all what it had offered to me, but.... I thought I couldn't (hey, Debian is for real hackers, not for you little ant!), but I started to adopt some orphaned packages, do some QA uploads, fix some RC bugs, talk with some Debian Developers that helped me and encouraged me more than I expected, I traveled to my first Debconf... And one thing takes you to the other, and on March 2012 I became a DD. Now, I'm glad to see that everything that frightened me is not so scary :-)

Jurij Smakov: Broken envelope-from considered harmful

Recently I went through the process of getting my new key (C99E03CC is dead, long live 43C30A7D!) signed to replace the old one in the Debian keyring. Some people used caff to send out their signatures and in 3 different cases I did not receive the signature for my @debian.org uid, leaving me somewhat dumbfounded as signatures for other uids went through just fine, as did various test emails to my @debian.org address. After pestering people on IRC and discussing the issue with one of the signers, we concluded that Debian's mail servers are configured to reject any mail with invalid envelope-From header - and chances that caff-sent email is going to have an invalid one are pretty high. As far as I can tell, a valid configuration is such that echo $ USER @$(cat /etc/mailname) returns a valid email address. So, if you are a caff user, please make sure that your system is configured correctly before sending out signatures with it, namely that the emails sent using something like echo 'test' mail $ YOU @debian.org are getting through successfully.

Clint Adams: The Windy City is full of meat

As you know, I am not big on reviews, so you should disregard the remainder of this entry. I recently found myself in what is called a theatre complex , watching an adaptation of Moli re's Les Femmes savantes by Freyda Thomas, who is apparently famous for playing Alenis Grem on Deep Space Nine. Called The Learned Ladies, this translation to English manages to approximate some of the rhyme of the original, thereby making it unquestionably better than DS9. Also noteworthy is the all-female cast, cobbled together from two all-female theater groups. Elizabeth Neptune plays Chrysale, occasionally channeling the spirit of Jackie Gleason or bringing adorable ardor to such epic lines as Tea! I won't say anything about her eyes, but I will say something about her slippers. Sara Montgomery, as B lise, is delightfully crazy in her singing, dancing, costume changes, and other antics, which serve to transform this otherwise-completely-serious play into a comedy. I definitely won't say anything about her shoes. Madeleine Maby begins playing Philaminte well before the show starts. Spoiler alert: she sits on the stage, pretending to look through a telescope and make notes from before the house opens until right before the start of the first scene. I still feel exhausted by the thought of having to do that myself. L' pine is portrayed by Alyssa Lott, who also plays three minor roles. Her mastery of physical comedy is not wasted on this production. Marta Kuersten plays Clitandre opposite Sarah Brill's Henriette. While Marta's performance was quite good, she looks much better as a woman. I will not be saying this about everyone. Katie Honaker delivers visceral smarm and sleaze as Trissotin. Even her hairstyle is somehow evocative of contempt. Susan Finch plays Vadius and Le notaire. Susan was definitely most convincing as a man. Despite mutterings to the contrary, some suspension of disbelief was necessary for the other male roles, but not for Vadius, oh no. Finishing out the list we have Janna Emig as Martine, Francesca Day as Armande, and Kathryn Alexander as Ariste, with good performances, particularly in the second half. Even though it didn't have Coppertop from Strangers With Candy and a boy-band song-and-dance cover of To Be with You by Mr. Big, I recommend this play.

Gunnar Wolf: C sar Y ez (@caesarcomptus) in the classroom: Process scheduling

I try to have some guests every now and then to my Operating Systems class. The class is not as practical/interactive as I'd like, and having some people show the students how the subjects I teach are reflected in the real world is, I feel, very useful for them to understand the topics' importance. The past semester (the first one for me) I had three guests: Chema Serralde, talking about process scheduling and in particular on the importance of real time, from his perspective as a musician, Rolando Cedillo, talking about the early stages of the boot process, and C sar Y ez, giving a review of file systems. This semester, there have been two guests so far: Felipe Esquivel, who spoke about parallelism, and used renders with Blender to illustrate the speed gains and limitations (i.e. Amdahl's law), and this last Thursday, I invited again C sar Y ez. C sar spoke about process scheduling, first giving a quite thorough review of what had taken me at least three sessions to go through, and second, giving some in-depth review based on his experience with Haiku OS. What else was different this time? I told our coordinator in the faculty, and she invited the other teachers of the subject (and attended herself). So, instead of the usual ~25 students, we have ~40 people in the classroom. And one of them, Adolfo, recorded most of C sar's explanation. Yay! Of course, I asked Adolfo for a copy of his recording, and recoded it in a format more suitable for Web viewing. Here it is (almost 300MB, Ogg Video, ~95 minutes). I still have the original video file given to me, in an Apple-generated badly-compressed .mov, but at over 1.5GB, it's too much for a Web download. I will try to record future sessions, as they will surely be useful!

13 October 2013

Dirk Eddelbuettel: Chicago Marathon 2013

A gorgeous day in Chicago for the 37th annual Chicago Marathon. Today was the seventh time I ran this race. I had sat out last fall, and ran a smaller local race (well enough for a BQ). But the last time I ran Chicago I mused that maybe next time I'd train more. I tried, but it didn't quite work with a minor injury dragging on a little. Just like in 2010. And so it continues: it is my home course, and the course I have run the most and know the best. Yet it is the one where I have the greatest difficulty coming in with a time that is good enough for Boston. I knew that today wasn't going to be that day, so I aimed lower to just run even splits (ie running about equal halfs). But even that failed: After 1:44 for the first half I lost a good ten minutes to finish at 3:40:42. Oh well. There is always next year... But it was a simply sunningly fabulous day, and the race was once again very, very well put together. We were worried about extra security: not a real issue. The streets were lined with people and even Lisa and Julia managed to cheer me on at mile 13 (still smiles), mile 19 (grimacing, about to fall apart) and 25 (hanging in). And Anna was working the mile 18 water stop. The worst where miles 20 to 22 when I walked a fair bit. The race results have details; maybe I'll update the chart I made in prior years. One minor FAIL was a wait at the end for gear check. That was pathetic. I guess the folks manning the stand didn't keep bags sorted well enough so lines were long, and slow. Oh well -- the rest was fine, and it remains one of the nicest marathon races. Oh, and the other FAIL was that my Nexus 4 phone couldn't hold a charge til I was done. What's up with that? The running tracker traced me til around mile 20, and then the phone shut down for lack of juice. Disappointing too. But hey, it spares you, dear reader, the look of some bad post-race selfies...

John Goerzen: Why are we still backing up to hardlink farms?

A person can find all sorts of implementations of backups using hardlink trees to save space for incrementals. Some of them are fairly rudimentary, using rsync --link-dest. Others, like BackupPC, are more sophisticated, doing file-level dedup to a storage pool indexed by a hash. While these are fairly space-efficient, they are really inefficient in other ways, because they create tons of directory entries. It would not be surprising to find millions of directory entries consumed very quickly. And while any given backup set can be deleted without impact on the others, the act of doing so can be very time-intensive, since often a full directory tree is populated with every day s backup. Much better is possible on modern filesystems. ZFS has been around for quite awhile now, and is stable on Solaris, FreeBSD and derivatives, and Linux. btrfs is also being used for real workloads and is considered stable on Linux. Both have cheap copy-on-write snapshot operations that would work well with a simple rsync --inplace to achieve the same effect ad hardlink farms, but without all the performance penalties. When creating and destroying snapshots is a virtually instantaneous operation, and the snapshots work at a file block level instead of an entire file level, and preserve changing permissions and such as well (which rsync --link-dest can have issues with), why are we not using it more? BackupPC has a very nice scheduler, a helpful web interface, and a backend that doesn t have a mode to take advantage of these more modern filesystems. The only tool I see like this is dirvish, which someone made patches for btrfs snapshots three years ago that never, as far as I can tell, got integrated. A lot of folks are rolling a homegrown solution involving rsync and snapshots. Some are using zfs send / btrfs send, but those mechanisms require the same kind of FS on the machine being backed up as on the destination, and do not permit excluding files from the backup set. Is this an area that needs work, or am I overlooking something? Incidentally, hats off to liw s obnam. It doesn t exactly do this, but sort of implements its own filesystem with CoW semantics.

9 October 2013

John Goerzen: Two Kittens

Almost every time he got off the bus for the past month and a half, Jacob started his afternoon in the same way. Before toys, before his trains and his toy bus, before anything indoors, he went for our cats. Here he is, cradling his favorite, Tigger: Laura and I both grew up around cats. We had been talking about kittens, and shortly after we got engaged, one of my relatives offered us some free kittens. We went to his place one evening and selected two of them one calico and one tiger-colored. Since what is now my place will soon be our place, they came to live with me. Our cats were one of the first things we did to prepare for our lives together. Oliver wanted to name them some rather impractical sentence-long names ( The Cat Who Always Likes To Run ), so Laura and I suggested some names from one of their favorite books: Tigger and Roo. They both liked the names, but Oliver thought they should be called Tigger the Digger and Roo the Runner . Never mind that they were just 6 weeks old at the time, and not really old enough to either dig or run. Here s Oliver with Roo, the day after the kittens arrived here. I have always had outside cats, both because I m allergic to cats so I need them to be outside, and because they sometimes literally quiver with joy of being outdoors. Tigger and Roo often chased insects, wrestled with each other, ran up (and slowly came back down) trees, and just loved the outside. Sometimes, I have taken my laptop and wireless headset and work from the back porch. The kittens climb up my jeans, inspect the laptop, and once Roo even fell asleep on my lap at one of those times. Jacob has been particularly attached to Tigger, calling him my very best friend. When Jacob picks him up after school, Tigger often purrs while cradled in Jacob s arms, and Jacob comments that Tigger loves me. Oh dad, he knows I am his friend! The kittens have been growing, and becoming more and more comfortable with their home in the country. Whenever I go outside, it isn t long before there are two energetic kittens near my feet, running back and forth, sometimes being very difficult to avoid stepping on. I call and I see little heads looking at me, from up in a tree, or peeking out from the grain elevator door, or from under the grill. They stare for just a second, and then start running, sometimes comically crashing into something in their haste. Yesterday when I went to give them food, I called and no cats came. I was concerned, and walked around the yard, but at some point either they come or they don t. Yesterday afternoon, just after the bus dropped off Jacob, I discovered Tigger on the ground, motionless. Once Jacob was in the house, I went to investigate, and found Tigger was dead. As I was moving his body, I saw Roo was dead, too. Both apparently from some sort of sudden physical injury a bit mysterious, because neither of them were at a place where they had ever gone before. While all this was happening, I had to also think about how I was going to tell the boys about this. I tried to minimize what he could see, Jacob had caught an unavoidable glimpse of Tigger as we were walking back from the bus, but didn t know exactly what had happened. He waited in the house, and when I came back, asked me if Tigger was dead. I said he was. Jacob started crying, saying, Oh Dad, I am so sad , and reached up for a hug. I picked him up and held him, then sat down on the couch and let him curl up on my lap. I could quite honestly let him know he wasn t alone, telling him I am sad, too. Oliver arrived not long after, and he too was sad, though not as much as Jacob. Both boys pretty soon wanted to see them. I decided this was important for them for closure, and to understand, so while they waited in the house, I went back out to arrange the kittens to hide their faces, the part that looks most unnatural after they die. The boys and I walked out to where I put them, then I carried both of them the last few feet. We stood a little ways back close enough to see who was there, far enough to not get too much detail and they were both sniffling. I tried to put voice to the occasion, saying, Goodbye, Tigger and Roo. We love you. Oliver asked if they could hear us. I said No, but I told them what I felt like anyway. Jacob, through tears, said, Dad, maybe they are in heaven now. We went back inside. Jacob said, Oh dad, I am so sad. This is the saddest day of my life. My heart is breaking. Hearing a 7-year-old say that isn t exactly easy for a dad. Pretty soon he was thinking of sort of comfort activities to do, saying I think I would feel better if we did So they decided to watch a favorite TV program. Jacob asked if Laura knew yet, and when I said no, he got his take-charge voice and said, Dad, you will start the TV show for us. While we are watching, you will send Laura an email to tell her about Tigger and Roo. OK? What could I say, it wasn t a bad idea. Pretty soon both boys were talking and laughing. It was Big Truck Night last night, at a town about half an hour away. It s an annual event we were already planning to attend, where all sorts of Big Trucks firetrucks, school bus, combine, bucket truck, cement truck, etc show up and are open for kids to climb in and explore. It s always a highlight for them. They played and sang happily as we drove, excitedly opened and closed the big door on the school bus and yelled All Aboard! from the top of the combine. We ate dinner, and drove back home. When we got home, Jacob mentioned the cats again, in a sort of matter-of-fact way, and also wanted to make sure he knew Laura had got the message. A person never wakes up expecting to have to dump a bowl of un-eaten cat food, or to give an impromptu cat funeral for little boys. As it was happening, I wished they hadn t been around right then. But in retrospect, I am glad they were. They had been part of life for those kittens, and it is only right that they could be included in being part of death. They got visual closure this way, and will never wonder if the cats are coming back someday. They had a chance to say goodbye. Here is how I remember the kittens.

8 October 2013

Daniel Kahn Gillmor: Unaccountable surveillance is wrong

As I mentioned earlier, the information in the documents released by Edward Snowden show a clear pattern of corporate and government abuse of the information networks that are now deeply intertwined with the lives of many people all over the world. Surveillance is a power dynamic where the party doing the spying has power over the party being surveilled. The surveillance state that results when one party has "Global Cryptologic Dominance" is a seriously bad outcome. The old saw goes "power corrupts, and absolute power corrupts absolutely". In this case, the stated goal of my government appears to be absolute power in this domain, with no constraint on the inevitable corruption. If you are a supporter of any sort of a just social contract (e.g. International Principles on the Application of Human Rights to Communications Surveillance), the situation should be deeply disturbing. One of the major sub-threads in this discussion is how the NSA and their allies have actively tampered with and weakened the cryptographic infrastructure that everyone relies on for authenticated and confidential communications on the 'net. This kind of malicious work puts everyone's communication at risk, not only those people who the NSA counts among their "targets" (and the NSA's "target" selection methods are themselves fraught with serious problems). The US government is supposed to take pride in the checks and balances that keep absolute power out of any one particular branch. One of the latest attempts to simulate "checks and balances" was the President's creation of a "Review Group" to oversee the current malefactors. The review group then asked for public comment. A group of technologists (including myself) submitted a comment demanding that the review group provide concrete technical details to independent technologists. Without knowing the specifics of how the various surveillance mechanisms operate, the public in general can't make informed assessments about what they should consider to be personally safe. And lack of detailed technical knowledge also makes it much harder to mount an effective political or legal opposition to the global surveillance state (e.g. consider the terrible Clapper v. Amnesty International decision, where plaintiffs were denied standing to sue the Director of National Intelligence because they could not demonstrate that they were being surveilled). It's also worth noting that the advocates for global surveillance do not themselves want to be surveilled, and that (for example) the NSA has tried to obscure as much of their operations as possible, by over-classifying documents, and making spurious claims of "national security". This is where the surveillance power dynamic is most baldly in play, and many parts of the US government intelligence and military apparatus has a long history of acting in bad faith to obscure its activities. The people who have been operating these surveillance systems should be ashamed of their work, and those who have been overseeing the operation of these systems should be ashamed of themselves. We need to better understand the scope of the damage done to our global infrastructure so we can repair it if we have any hope of avoiding a complete surveillance state in the future. Getting the technical details of these compromises in the hands of the public is one step on the path toward a healthier society. PostscriptLest I be accused of optimism, let me make clear that fixing the technical harms is necessary, but not sufficient; even if our technical infrastructure had not been deliberately damaged, or if we manage to repair it and stop people from damaging it again, far too many people still regularly accept ubiquitous private (corporate) surveillance. Private surveillance organizations (like Facebook and Google) are too often in a position where their business interests are at odds with their users' interests, and powerful adversaries can use a surveillance organization as a lever against weaker parties. But helping people to improve their own data sovereignty and to avoid subjecting their friends and allies to private surveillance is a discussion for a separate post, i think.Tags: cryptography, nsa

Next.

Previous.