Search Results: "ag"

27 October 2013

Gregor Herrmann: RC bugs 2013/41-43

after a bit of a break I try to get back into regular RC bug fixing. here's what I've done recently:

Petter Reinholdtsen: Teaching vmdebootstrap to create Raspberry Pi SD card images

The vmdebootstrap program is a a very nice system to create virtual machine images. It create a image file, add a partition table, mount it and run debootstrap in the mounted directory to create a Debian system on a stick. Yesterday, I decided to try to teach it how to make images for Raspberry Pi, as part of a plan to simplify the build system for the FreedomBox project. The FreedomBox project already uses vmdebootstrap for the virtualbox images, but its current build system made multistrap based system for Dreamplug images, and it is lacking support for Raspberry Pi. Armed with the knowledge on how to build "foreign" (aka non-native architecture) chroots for Raspberry Pi, I dived into the vmdebootstrap code and adjusted it to be able to build armel images on my amd64 Debian laptop. I ended up giving vmdebootstrap five new options, allowing me to replicate the image creation process I use to make Debian Jessie based mesh node images for the Raspberry Pi. First, the --foreign /path/to/binfm_handler option tell vmdebootstrap to call debootstrap with --foreign and to copy the handler into the generated chroot before running the second stage. This allow vmdebootstrap to create armel images on an amd64 host. Next I added two new options --bootsize size and --boottype fstype to teach it to create a separate /boot/ partition with the given file system type, allowing me to create an image with a vfat partition for the /boot/ stuff. I also added a --variant variant option to allow me to create smaller images without the Debian base system packages installed. Finally, I added an option --no-extlinux to tell vmdebootstrap to not install extlinux as a boot loader. It is not needed on the Raspberry Pi and probably most other non-x86 architectures. The changes were accepted by the upstream author of vmdebootstrap yesterday and today, and is now available from the upstream project page. To use it to build a Raspberry Pi image using Debian Jessie, first create a small script (the customize script) to add the non-free binary blob needed to boot the Raspberry Pi and the APT source list:
#!/bin/sh
set -e # Exit on first error
rootdir="$1"
cd "$rootdir"
cat <<EOF > etc/apt/sources.list
deb http://http.debian.net/debian/ jessie main contrib non-free
EOF
# Install non-free binary blob needed to boot Raspberry Pi.  This
# install a kernel somewhere too.
wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update \
    -O $rootdir/usr/bin/rpi-update
chmod a+x $rootdir/usr/bin/rpi-update
mkdir -p $rootdir/lib/modules
touch $rootdir/boot/start.elf
chroot $rootdir rpi-update
Next, fetch the latest vmdebootstrap script and call it like this to build the image:
sudo ./vmdebootstrap \
    --variant minbase \
    --arch armel \
    --distribution jessie \
    --mirror http://http.debian.net/debian \
    --image test.img \
    --size 600M \
    --bootsize 64M \
    --boottype vfat \
    --log-level debug \
    --verbose \
    --no-kernel \
    --no-extlinux \
    --root-password raspberry \
    --hostname raspberrypi \
    --foreign /usr/bin/qemu-arm-static \
    --customize  pwd /customize \
    --package netbase \
    --package git-core \
    --package binutils \
    --package ca-certificates \
    --package wget \
    --package kmod
The list of packages being installed are the ones needed by rpi-update to make the image bootable on the Raspberry Pi, with the exception of netbase, which is needed by debootstrap to find /etc/hosts with the minbase variant. I really wish there was a way to set up an Raspberry Pi using only packages in the Debian archive, but that is not possible as far as I know, because it boots from the GPU using a non-free binary blob. The build host need debootstrap, kpartx and qemu-user-static and probably a few others installed. I have not checked the complete build dependency list. The resulting image will not use the hardware floating point unit on the Raspberry PI, because the armel architecture in Debian is not optimized for that use. So the images created will be a bit slower than Raspbian based images.

Charles Plessy: Debian-Installer in the Amazon cloud.

I prepared machine images of the Debian Installer in each region of the Amazon Elastic Computing Cloud, following the method that I described earlier, and that I updated and documented in Debian's wiki. Started with a preseed file, these images install Debian la carte on a storage volume that can then be registered as a new machine image. This is not yet automatic, but I am working on it. In the meantime, it is possible to install Debian interactively using the network console.

26 October 2013

Paul Tagliamonte: systemd vs upstart vs sysvinit

That thread


My feels:



So, I submitted the issue to tech-ctte.


Let s make this painless and let ctte deal with it :)

Hideki Yamane: tried to fix RC bugs (10/2013)

Some of not succeed, but I've tackled to below RC bugs.

Bug#701286 and Bug#713750, deleyed-5 upload
Bug#713104, deleyed-5 upload
Bug#713507, deleyed-5 upload
Bug#710629, deleyed-5 upload
Bug#713181, deleyed-5 upload
Bug#701344, deleyed-5 upload
Bug#712345, deleyed-5 upload
Bug#712354, not fixed yet...
Bug#718150, tags: unreproducible
Bug#718154, tags: unreproducible
Bug#711029, not fixed yet...
Bug#722111, downgrade severity: normal
Bug#722519, tags: unreproducible
Bug#725539, tags: patch
Bug#725551, tags: patch
Bug#725540, tags: patch
Bug#725555, tags: patch
Bug#725559, tags: patch
Bug#724077, tags: patch
Bug#724160, tags: patch
Bug#724046, tags: patch
Bug#724205, tags: patch
Bug#724221, tags: patch
Bug#725513, tags: patch
Bug#725565, tags: patch
Bug#725538, tags: patch
Bug#725537, tags: patch
Bug#725530, not fixed yet...
Bug#724201, not fixed yet...
Bug#724913, tags: patch
Bug#725569, tags: patch
Bug#724467, tags: patch
Bug#725580, tags: patch
Bug#725568, tags: patch
Bug#725546, tags: patch
Bug#724093, tags: patch
Bug#724199, tags: patch
Bug#713254, tags: patch
Bug#724161, tags: patch
Bug#713192, tags: patch
Bug#713203, tags: patch
Bug#724083, tags: patch
Bug#713300, tags: patch
Bug#713211, tags: patch
Bug#713547, tags: patch
Bug#725529, tags: patch
Bug#725626, tags: patch
Bug#720818, tags: patch
Bug#724471, tags: patch
Bug#713209, tags: patch

Phew.

Niels Thykier: Breaking the RC bug curve

Early this month, the first batch of packages were automatically removed from testing due to RC bugs. Personally, I find that the results stand out pretty well on the RC bug graph[1]. There has been a very rapid decline in the number of RC bugs affecting testing a week or two ago, we had over 1000 RC bugs affecting testing and now it has dropped to something like 760. There has also been quite a few RC bug fixes in this time period. I spent a bit of time finding and aging some of the RC bug fixes in sid, so they would migrate to testing faster[2]. On the first batch, we saw something like 40 RC bugs disappear and we still have more RC bugs fixes in the sid->testing pipeline. While looking for packages I could age, I also noticed that we have quite a few RC bug fixes blocked by out of date binaries (which is usually either build issues or uncoordinated transitions). I have been filing a couple of RC bugs for these, but it does not scale do this kind of work manually. If you have uploaded a package recently, please take the 5 minutes to check that it actually built and it has no out of date binaries issues in its excuses. [1] http://bugs.debian.org/release-critical/ [2] The aging was equivalent to an urgency=medium, so reduced the requirement from 10 days to 5 days.

Russ Allbery: Review: Why We Fail

Review: Why We Fail, by Victor Lombardi
Publisher: Rosenfeld Media
Copyright: 2013
ISBN: 1-933820-17-9
Format: Kindle
Pages: 248
Subtitled Learning from Experience Design Failures, Why We Fail is a case study book. It defines experience design, discusses the usefulness of analyzing failure, and then walks through ten marketplace failures attributed to failures of user experience (as opposed to engineering or user interface) and tries to draw some conclusions about those failures and how they could have been prevented. Lombardi then presents a more general (if fairly simple) framework for iterative experience design, along with some discussion of how that approach could have helped in these cases. Hardware and software designs can work properly but still fail with users and customers because the overall experience isn't right. Sometimes this is because something else got there first with more market share and people got used to it, sometimes it's because a system is too complicated, sometimes it's too simple, sometimes it's just uninspiring. Most of the news media coverage and many of the blog posts on this topic look to inspirational examples of successes. Lombardi points out here that successes can be accidental and failures are often more informative, a concept already common in many more mature areas of engineering. His hope, with Why We Fail, is to push a broader industry practice of taking apart and analyzing the failures. User experience design is still in its infancy, since many of the complex interactions now possible in modern hardware and software have just recently crossed into levels of complexity that qualify as experiences rather than interactions, and could benefit from more rigor. The concept sounds great. The approach in Why We Fail is at least interesting; Lombardi tells good stories, and I think they do tell some useful lessons. Drawing general principles is harder, which is always the weakness of case-study books. Lombardi's own attempt doesn't go far beyond a familiar mantra of the scientific method, small and responsive teams, cross-functional teams with flexibility to address a whole range of technical and business issues, and honest and forthright analysis of and iteration after failure. All of this is doubtless good advice; none of it should surprise anyone with even a smattering of engineering background or familiarity with current software design philosophy. The heart of the book is in the stories, and I did like that Lombardi captured a wide range of different designs. Included are embedded systems (BMW's iDrive), traditional software packages, web services of various types, and even a protocol (OAuth). Some were vaguely familiar and some were not familiar at all, although I don't follow UI and UX discussions to any large extent. In each case, Lombardi gives a short but effective introduction to the problem space and the product, walks through the design choices, and then talks about the failure. Usefully, he doesn't stop with the failure but continues the story through the reaction of the company to the failure and any subsequent actions they took, which in some cases contain their own useful lessons. All of this, I should note, is a bit far afield of my own area of expertise (architectural building blocks and sub-surface components without as much direct interaction with the user), so I'm not the best person to judge the quality and originality of the analysis. But I liked Lombardi's approach and his analysis of multiple possible failure causes, and all of his conclusions seemed quite plausible and sensible given the case studies as described. I'm best-qualified to judge the chapter on OAuth, since I've worked extensively on web authentication systems, and his analysis of the challenges and user experiences in that case closely match my own. I didn't notice any significant errors, which is hopefully a good sign for the rest of the book. As one might expect from a short book about a complex field aimed mostly at starting a conversation, there isn't much here that's earth-shattering, nor are there simple extractable principles that will make your experience designs better. As always, the takeaway boils down to "invest time and resources into this and try to think about it systematically," which of course is true of every possible axis of improvement for any product. (The challenge is usually where to spend those limited resources.) I will also note in passing that Lombardi assumes an entirely market-driven metric for success, and all of the case studies are exclusively commercial not unexpected, since that's where most of the money and a lot of the resources are, but not that helpful for bespoke work where the nature of the problem is subtlely different. But, despite the expected shortcomings and the inherent weakness of the case study approach to analysis, which tries to pluralize anecdote to get data I enjoyed this book. I also got at least one useful trick out of it: the premortem, to look for potential failure points in the experience before rolling out, or even designing, the product. It's a fairly light-weight book, but I think it's moderately inspirational, and I wholeheartedly concur with Lombardi on the merits of failure analysis as an engineering approach. Rating: 7 out of 10

25 October 2013

David Welton: MicroConf Europe

I don't envy conference organizers these days - most of what's being said can be read the next day, for free, on line, at your own pace, from the comfort of your own home, and without spending a bundle of time and money to sleep in a far away hotel. Competing with that is not easy, but the guys at MicroConf managed to. I would sum up the weekend by saying that it was a "very high bandwidth experience". Every day, from breakfast until I turned in, I was chatting with people or listening to speakers during the conference itself. That's aproximately 16 hours of being "on", and by the time I got home to Padova, I was exhausted! But at the end of the day, I felt like it was worth it being there in person, because of all the interaction with other people. The speakers' talks all ended up on line, more or less, but all the chatting and discussion and getting to know everyone is the human element that is tough to replicate on line, and one of the most important reasons to attend a conference in person. Prague is also a beautiful city - I wish I had had more time there to check it out. Here are some highlights and notes, in no particular order: However, since it was a business conference, I also have to put on my cold, hard accountant hat. Will the conference pay for itself? Only time will tell. I learned a variety of interesting and useful things, many of which I think I can put into practice. The problem is finding the time between consulting work and family, but that was a bottleneck before, too - I had, and have, more things to do than time. Also, to be very direct about it, how much of what I learned could not have been learned by carefully reading accounts of the conference, slides, and other material published on the internet? A lot of it. I'm not sure I would have paid attention to all of it though, so the conference was definitely nice in that it exposed me to some talks and ideas that otherwise I might have brushed off before giving them a chance. In terms of dollars and cents, I won't be able to say for a while whether it was a sensible investment or not. Would I go again? I'd like to - it was a lot of fun and the people were great. Like I said, it's tough doing conferences because your competition is the internet!

Enrico Zini: A vision wanted

A vision wanted Today Richard Stallman mailed all Italian LUGs asking that tomorrow's LinuxDay be called "GNU/Linux Day" instead. I wonder how that is ever going to help a community so balkanised, that the only way Italian LUGs manage to do something together, is to say "let's not care what we all do, let's just do it on the same day and call it a national event". Of course a few LUGs still make a point of not doing anything on that day, because you know, Judean People's Front. Cawk. Today a friend asked me if I could help her support people in installing Citrix Whatsit to set up a video conference to network meetings that will take place in a month in different cities. Those meetings are something I look forwad to. It wasn't much of a problem to say "no, I can't do that"; it was a problem to be unable to come up with some viable, Free alternatives. I sometimes have to use Skype to talk with friends who also are Debian Developers, because I still haven't managed to make VoIP work unless I go through a commercial proxy. There was the happy news that our regional administration is switching from MS Word to OpenOffice. It soon became a flamewar, because some people loudly complained that they should have used LibreOffice instead. At DebConf, after spending an hour getting frustrated with the default formatting of bullet points in WhateverOffice Impress, I did my Debian Contributors talk using a text file in vim. And it was a success! Thanks Francois Marier for maintaining cowsay. I can't sync contact lists and appointments between my N900, which runs a Debian derivative, and my laptop, because I don't want to have a Google account, and nothing else would work out of the box. I don't even know how to keep a shared calendar with other DDs, without using a 3rd party cloud service that I don't want to trust with my life's personal schedule. I need to do a code review of every vim plugin I need to use, because you can only get them by cloning GitHub repositories over plain http, and they don't even provide signed tags. That code is run with my own privileges every time I start a text editor, which is, like, all the time. I'm frightened at the idea of how many people blissfully don't think about what that means. Vim users. Programmers. Cool chaps. Yet the most important thing in Debian today seems to be yet another crusade between upstart and systemd. But we haven't had a lengthy discussion on why, although the excellent OpenStreetMap exists and many of us contribute to it, it seems to still be more immediate to hit Google Maps to get a route computed. How can we change that? We haven't had a lengthy discussion on what can we offer to allow anyone to set up some social platform that won't get swamped with spam the first day and cracked open the second; that would allow people to share some photos with their friends only, and some with the rest of the world; that won't required a full-time paid person to maintain. That won't be obsolete and require a migration to a new platform in a year. That isn't Facebook or Google Plus. I stopped taking photos because it's too much work to show them to people. Other people use Instagram. Whatever the hipster trend is for photo sharing today, October 25, 2013, I'm pretty sure it's not a Free platform. But we can do something. We technology leaders. We are those who drive technological change! For example, today I invested two hours of hard effort trying to figure out why libbuffy's test suite fails on kfreebsd. All while wondering why I was doing that, since I know all buffy's users personally, and none of them uses kfreebsd. And I will take a day off work to study the library symbols file specification, so that next time I'll know right away if the new version of a C++ compiler decides that a template-generated symbol isn't worth adding to a library anymore. What is this effort really about? It sometimes feel like micromanaging to me. It's good to have excellent quality standards. But not without a vision. Not until "reliable network printing with all PDF viewers and print servers we ship" is among our release goals. Not until we commit to making sure that "sharing files between Debian users" will work out of the box, without the need of going through a 3rd party website, or email. I'm not interested in spending energy discussing init systems. I'm interested in spending energy sharing stories of what cool stuff we can do in Debian today, out of the box. And what cool stuff we'll be able to do tomorrow. Let's spend time on IRC, on mailing lists, and at the next Debian events, talking about why we are really into this. Talking about a vision! Note: Please don't spend time telling me how to fix the problems I mentioned above. I'm not interested in help fixing some problems for me today. I'm interested in asking help fixing problems for everybody, right in the next stable release. Remember, remember, the 5th of November, 2014.

Jan Wagner: PHP.net infected with Malware and Linux Malware Detect

As some of you might have noticed, the Site PHP.net was infected yesterday with Malware.
If you are running a shared hosting environment, you are also be faced with similar Malware problems. Beside XSS attacks and compromised server systems on OS-level, very widely used attack szenarios are stolen user credentials. A usefull mitigation strategy might be a web application firewall (WAF) like ModSecurity. Another way might be the Malware scanner Linux Malware Detect. The project describes itself:
**Description**
Linux Malware Detect (LMD) is a malware scanner for Linux released under the
GNU GPLv2 license, that is designed around the threats faced in shared hosted
environments. It uses threat data from network edge intrusion detection systems
to extract malware that is actively being used in attacks and generates
signatures for detection. In addition, threat data is also derived from user
submissions with the LMD checkout feature and from malware community resources.
The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they
are also easily exported to any number of detection tools such as ClamAV.
**Features**
- MD5 file hash detection for quick threat identification
- HEX based pattern matching for identifying threat variants
- statistical analysis component for detection of obfuscated threats (e.g: base64)
- integrated detection of ClamAV to use as scanner engine for improved performance
- integrated signature update feature with -u update
- integrated version update feature with -d update-ver
- scan-recent option to scan only files that have been added/changed in X days
- scan-all option for full path based scanning
- checkout option to upload suspected malware to rfxn.com for review / hashing
- full reporting system to view current and previous scan results
- quarantine queue that stores threats in a safe fashion with no permissions
- quarantine batching option to quarantine the results of a current or past scans
- quarantine restore option to restore files to original path, owner and perms
- quarantine suspend account option to Cpanel suspend or shell revoke users
- cleaner rules to attempt removal of malware injected strings
- cleaner batching option to attempt cleaning of previous scan reports
- cleaner rules to remove base64 and gzinflate(base64 injected malware
- daily cron based scanning of all changes in last 24h in user homedirs
- daily cron script compatible with stock RH style systems, Cpanel & Ensim
- kernel based inotify real time file scanning of created/modified/moved files
- kernel inotify monitor that can take path data from STDIN or FILE
- kernel inotify monitor convenience feature to monitor system users
- kernel inotify monitor can be restricted to a configurable user html root
- kernel inotify monitor with dynamic sysctl limits for optimal performance
- kernel inotify alerting through daily and/or optional weekly reports
- e-mail alert reporting after every scan execution (manual & daily)
- path, extension and signature based ignore options
- background scanner option for unattended scan operations
- verbose logging & output of all actions
The recent development can be found at Github and in the last days I worked on packaging this into a Debian package 'maldetect'. If you want to give it a try on Debian, you could install the packages from our restricted repository:
    # wget "http://ftp.cyconet.org/debian/sources.list.d/restricted-cyconet.list" \
        -O /etc/apt/sources.list.d/restricted-cyconet.list
    # aptitude update
    # aptitude -t restricted install maldetect
For adding our archive key, you can just install the package "debian-cyconet-archive-keyring"

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

Michal &#268;iha&#345;: Weblate 1.8 is close

Thanks to great amount of changes I've been able do in Weblate during Hackweek, the 1.8 release is quite close. All features I wanted there are implemented and it is already running for some time on my production servers which look quite stable. The only thing which needs still some improvement are translations. So that's your chance to contribute. Translation status If there won't be any blocking issue, Weblate 1.8 will be released during next week.

Filed under: English SUSE Weblate 0 comments Flattr this!

Ingo Juergensmann: Sharing GnuPG between Linux and OSX

I've been using GnuPG since years. Well, using is too strong. I have a GPG key that I've created somewhen and use it once in a while when sending login credentials to other Linux people. But since Edward Snowdens NSA leaks I now get encrypted mails by non-Linux people. It is great that people are making use of strong encryption to protect their communication, but it is frightening that people have to do so because of NSA mass surveillance the complete world and violating our civil and human rights. Anyway, one problem with GnuPG and other PKI tools is, that you should keep your private key secret. When you use more than one device to write your mails, you will run into usuability problems like I did. My main computer is my Debian box, but I use a MacBook Pro laptop with OSX very often as well. There is GPGSuite (formerly GPGMail) for OSX to pimp your Mail.app with GPG. It uses, of course, a local .gnupg/ directory and thus it would create a separate GnuPG pair of keys. But apparently I want to use my existing pair of keys - without the need to copy them over from my Linux box to my laptop. The solution would be a simple setup of netatalk to mount your home directory from the Linux box under OSX and a matching symlink to your Linux .gnupg/ directory (or even better: symlink the contents where necessary and not the whole directory). But that would've been too easy, I guess, because I got this error message on OSX:

So, basically this didn't work right out of the box. Fortunately the GPGSuite support guys replied quick and solved this problem. The version they released yesterday did fix that problem, but I needed to add the following line to my ~/,gnupg/gpg-agent.conf, which didn't exist before too:

no-use-standard-socket

With that line everything works like a charme under OSX with Mail.app using my GPG keys on my Debian box.

Kategorie:

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

Dirk Eddelbuettel: Introducing the CRAN Repository Policy Watch

CRAN is the repository network for R. It is a resounding success with (as of right now) almost 5000 packages, and growth rate which has been estimated (cf John Fox's keynote at useR! a few years ago) to be near 40% per year. We as R community members owe a great deal of thanks to the CRAN maintainers, and the R Core team. The tight integration between the language and the contributed code repository is unique among programming languages, and one of the many reasons why CRAN has been such a success and driver of growth and adoption for R. And the amount of work the CRAN maintainers put into this is substantial, and we owe them. Yet there is some friction between the repo maintainers, and the community of developers. There have numerous discussions on the main developer list about various aspect of how CRAN maintains the impeccable quality of the code in the archive. One particular aspect which has bugging (at least me) is the lack of communication when policy changes are made. It would be trivial to posts a set of changes to the developer list, and I suggested as much. Only to be soundly ignored. But changes to text (or html) files can monitored rather easily, and when such changes occur an alert can be sent. So I cooked up rather simple system for this which I called the CRAN Policy Watch. In essence, a simple cronjob monitors changes, and records new versions in a Github repo (which you can follow or star). Alternatively, the cronjob now also tweets from the @CRANPolicyWatch account which I invite everyone to subscribe to as well. If someone knows of a simple tool to summarize diffs of html or text files in static html pages, I'd be interested to expand the service to some github.io pages. Alernatively I could also just commit to a single file too and let Github summarize the changes. This was an itch I needed to scratch, and I hope some other people will fine this useful too.

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.

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.

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

22 October 2013

Wouter Verhelst: bind module for puppet

Yesterday, I released a module to manage bind zones using puppet on the puppet forge. It uses a custom type to manage DNS RRs (using dig and nsupdate), and there's also a class for ensuring that a zone is installed, both on masters and on slaves, in a manner that you only need to list the zones, with their master and slave name servers, in a hiera data file. The main reason why I did it this way is because all the other modules that I looked at would either expect you to write zone files (and then just copy them over), or generate the zone files and use "rndc reload" or similar. I don't like that way of doing things. BIND does support dynamic updates of zone entries, and it's perfectly possible to query a name server to verify whether a given record actually exists. Additionally, this gave me a good excuse to learn how to write a custom type for puppet. Today, I was astonished to learn that my module has already had six downloads. In 20 hours, that's fairly impressive, in my opinion.

Next.

Previous.