A new maintenance release 0.10.6 of Rcpp is now on the CRAN network for GNU R; binaries for Debian have been uploaded as well. This version ties up a number of smaller loose ends, but also adds a few new things, particularly John's new exposeClass. Details are as usual in the NEWS extract below, and also in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.10.6 (2013-10-27)

• Changes in Rcpp API:
  • The function exposeClass takes a description of the constructors, fields and methods to be exposed from a C++ class, and writes C++ and R files in the package. Inherited classes can be dealt with, but require data type information. This approach avoids hand-coding module files.
  • Two missing is<>() templates for CharacterVector and CharacterMatrix have been added, and some tests for is_na() and is_finite() have been corrected thanks to Thomas Tse.
• Changes in R code:
  • Export linking helper function LdFlags as well as RcppLdFlags.
  • Function Rcpp.package.skeleton() no longer passes a namespace argument on to package.skeleton()
• Changes in R setup:
  • Raise requirement for R itself to be version 3.0.0 or later as needed by the vignette processing
• Changes in Rcpp attributes:
  • sourceCpp now correctly binds to Rtools 3.0 and 3.1

Thanks to CRANberries, you can also look at a diff to the previous release 0.10.5. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dear all, we are proud to announce the 3.0 release of the Shogun Machine-Learning Toolbox. This release features the incredible projects of our 8 hard-working Google Summer of Code students. In addition, you get other cool new features as well as lots of internal improvements, bugfixes, and documentation improvements. To speak in numbers, we got more than 2000 commits changing almost 400000 lines in more than 7000 files and increased the number of unit tests from 50 to 600. This is the largest release that Shogun ever had! Please visit http://shogun-toolbox.org/ to obtain Shogun. News Here is a brief description of what is new, starting with the GSoC projects, which deserve most fame:

• Gaussian Process classification by Roman Votjakov
• Structured Output Learning of graph models by Shell Hu
• Estimators for log-determinants of large sparse matrices by Soumyajit De
• Feature Hashing and random kitchen sinks by Evangelos Anagnostopoulos
• Independent Component Analysis by Kevin Hughes
• A web-based demo framework by Liu Zhengyang
• Metric learning with large margin nearest neighbours by Fernando Iglesias
• Native support for various popular file formats by Evgeniy Andreev

Screenshots Everyone likes screenshots. Well, we have got something better! All of the above projects (and more) are now documented in the form of IPython notebooks, combining machine learning fundamentals, code, and plots. Those are a great looking way that we chose to document our framework from now on. Have a look at them and feel free to submit your use case as a notebook! The web-demo framework has been integrated into our website, go check them out. Other changes We finally moved to the Shogun build process to CMake. Through GSoC, added a general clone and equals methods to all Shogun objects, and added automagic unit-testing for serialisation and clone/equals for all classes. Other new features include multiclass LDA, and probability outputs for multiclass SVMs. For the full list, see the NEWS. Workshop Videos and slides In case you missed the first Shogun workshop that we organised in Berlin last July, all of the talks have been put online. Shogun in the Cloud As setting up the right environment for shogun and installing it was always one of the biggest problems for the users (hence the switching to CMake), we have created a sandbox where you can try out shogun on your own without installing shogun on your system! Basically it's a web-service which give you access to your own ipython notebook server with all the shogun notebooks. Of course you are more than welcome to create and share your own notebooks using this service! *NOTE*: This is a courtesy service created by Shogun Toolbox developers, hence if you like it please consider some form of donation to the project so that we can keep up this service running for you. Try shogun in the cloud. Thanks The release has been made possible by the hard work of all of our GSoC students, see list above. Thanks also to Thoralf Klein and Bj rn Esser for the load of great contributions. Last but not least, thanks to all the people who use Shogun and provide feedback. S ren Sonnenburg on behalf of the Shogun team (+ Viktor Gal, Sergey Lisitsyn, Heiko Strathmann and Fernando Iglesias)

Shogun goes cloud. Try out http://cloud.shogun-toolbox.org to interactively play with machine learning algorithms or try any of the interactive demos. The SHOGUN Machine Learning Toolbox is a collection of algorithms designed for unified learning for a broad range of feature types and learning settings, like classification, regression, or explorative data analysis. For more information visit http://www.shogun-toolbox.org.

I use Puppet a lot at work, and I use a lot of modules written by other people, as well as writing quite a number of my own. Here s a brief list of reasons why I might say that your module sucks.

1. You use global variables This would have to be both the most common idiom that just makes my teeth grind. Defined types exist for a bloody reason. Global variables make it incredibly difficult to reason about what is going to happen when I use a particular global variable (see also You don t write documentation ), and I get no feedback if I typo a global variable name. Add in a healthy heaping of lack of namespacing , and you ve basically guaranteed that your module will be loudly cursed.

2. You use parameterised classes I ve never managed to work out why parameterised classes even exist. They ve got all the problems of regular classes, as well as all the problems of types. There was a fantastic opportunity with parameterised classes to fix some of the really annoying things about regular resources, such as doing conflict checking on parameters and only barfing if there was a conflict but no, if you define the same class twice, even with identical parameters, Puppet will smack you on the hand and take away your biscuit. FFFFFFUUUUUUUUUUUU-

3. You fail at using fail() Modules are supposed to be reusable. That s their whole reason for existence. One of the benefits of Puppet is that you can provide an OS-independent interface for configuring something. However, unless you re some absolute God of cross-platform compatibility, you will only be writing your module to support those OSes or distros that you, personally, care about. That s cool if you don t know anything about OS X, you probably shouldn t be guessing at how to support something on that platform anyway. However, when you do have some sort of platform-specific code, for the love of pete, have a default or else clause that calls fail() with a useful and descriptive error message, to indicate clearly that you haven t included support for whatever environment the module s being used in. Failing to do this can cause some really spectacular explosions, because the rest of your module assumes that certain things have been done in the platform-specific code, and when it hasn t hoo boy.

4. You don t write documentation Yes, it isn t easy to write good documentation. I know that. But without documentation, your module is going to be practically unuseable. So if you don t have docs, your module is basically useless. Well done, you.

5. You have undeclared dependencies This also includes declaring your dependencies in a non-machine-parseable manner; I m not going to grovel through your README for the list of other modules I might need; I have machines to do that kind of thing for me. If I try to use your module, and it craps out on trying to reference some sort of type or class that doesn t appear at all related to your module, I will call into question your ancestry, and die a little more inside.

6. You use common packages without even trying to avoid the pitfalls OK, to be fair this is, ultimately, Puppet s grand fuckup, not yours, but you at least need to pretend to care There is no sane, standardised way in Puppet for multiple modules to install the same package. Let s say that a module I write needs to have a compiler. So I package "gcc": . Then someone else s module also wants a compiler, so it also package "gcc": . FWAKOOM! says Puppet. What the fuck? says the poor sysadmin, who just wanted both a virtualenv and an RVM environment on the one machine. Basically, using packages is going to make your module suck. Does that mean that this makes wide distribution of a large repository of modules written by different people nigh-on impossible? Yes. Fantastic.

I use Puppet a lot at work, and I use a lot of modules written by other people, as well as writing quite a number of my own. Here s a brief list of reasons why I might say that your module sucks.

1. You use global variables This would have to be both the most common idiom that just makes my teeth grind. Defined types exist for a bloody reason. Global variables make it incredibly difficult to reason about what is going to happen when I use a particular global variable (see also You don t write documentation ), and I get no feedback if I typo a global variable name. Add in a healthy heaping of lack of namespacing , and you ve basically guaranteed that your module will be loudly cursed.

2. You use parameterised classes I ve never managed to work out why parameterised classes even exist. They ve got all the problems of regular classes, as well as all the problems of types. There was a fantastic opportunity with parameterised classes to fix some of the really annoying things about regular resources, such as doing conflict checking on parameters and only barfing if there was a conflict but no, if you define the same class twice, even with identical parameters, Puppet will smack you on the hand and take away your biscuit. FFFFFFUUUUUUUUUUUU-

3. You fail at using fail() Modules are supposed to be reusable. That s their whole reason for existence. One of the benefits of Puppet is that you can provide an OS-independent interface for configuring something. However, unless you re some absolute God of cross-platform compatibility, you will only be writing your module to support those OSes or distros that you, personally, care about. That s cool if you don t know anything about OS X, you probably shouldn t be guessing at how to support something on that platform anyway. However, when you do have some sort of platform-specific code, for the love of pete, have a default or else clause that calls fail() with a useful and descriptive error message, to indicate clearly that you haven t included support for whatever environment the module s being used in. Failing to do this can cause some really spectacular explosions, because the rest of your module assumes that certain things have been done in the platform-specific code, and when it hasn t hoo boy.

4. You don t write documentation Yes, it isn t easy to write good documentation. I know that. But without documentation, your module is going to be practically unuseable. So if you don t have docs, your module is basically useless. Well done, you.

5. You have undeclared dependencies This also includes declaring your dependencies in a non-machine-parseable manner; I m not going to grovel through your README for the list of other modules I might need; I have machines to do that kind of thing for me. If I try to use your module, and it craps out on trying to reference some sort of type or class that doesn t appear at all related to your module, I will call into question your ancestry, and die a little more inside.

6. You use common packages without even trying to avoid the pitfalls OK, to be fair this is, ultimately, Puppet s grand fuckup, not yours, but you at least need to pretend to care There is no sane, standardised way in Puppet for multiple modules to install the same package. Let s say that a module I write needs to have a compiler. So I package "gcc": . Then someone else s module also wants a compiler, so it also package "gcc": . FWAKOOM! says Puppet. What the fuck? says the poor sysadmin, who just wanted both a virtualenv and an RVM environment on the one machine. Basically, using packages is going to make your module suck. Does that mean that this makes wide distribution of a large repository of modules written by different people nigh-on impossible? Yes. Fantastic.

Long time with no article about Tanglu! This was mainly because we were busy with the project itself, improving various aspects of the distribution. So, here is a new summary on what has been done and what you can expect from the first release Tanglu QA We further improved the automatic archive QA. There is now qa.tanglu.org, which constantly monitors the number of uninstallable or unbuildable packages in the Tanglu suites. It also provides status information on the metapackage generator, which helps us in finding out which packages are available on the live-cds. Furthermore, information about the staging->devel migration process is provided, to answer the question why a package does not migrate (this still needs some improvements, but it is being worked on). We also use some code from Ubuntu to monitor package versions in Debian and upstream, which helps to see if others have released newer versions of software shipped with Tanglu. This already resulted in many improvements: The Tanglu Aequorea suite does not contain unbuildable packages (at least not due to build-dependency changed), and all live-cds are working well. We will soon migrate the archive to a new server, which frees some server capacities we can use for automated QA and things like automatic live-CD building. Live-CDs, Installer, Alpha-Releases We currently don t do Alpha-Releases of Tanglu, but we create Live-CD snapshots of Tanglu, which are available at releases.tanglu.org (or mirror1, mirror2). These snapshots still have issues and are just early previews. They also ship without and installer, we are still working on that part. Please note that CD more or less means DVD or USB-Stick right now (and this won t change the expected image size will be around 800MB). Release Planning I am happy to announce that we will do a release this year, most likely in December. But what can you expect from the release? KDE 4.11 We will ship with KDE 4.11, which will be the only desktop we officially support so far. The reason is simply lack of manpower we could promise to support more, but that would just be not realistic for the small team. So we focus on KDE (Plasma Shells) right now, and try to make it awesome. Also, the team consists mostly of KDE people right now, which contributed to that decision . If you want to try Tanglu, right now the KDE live-images are the best to try it out. GNOME 3.8 We will also provide images with GNOME. The problem with GNOME is, that the GNOME team does not have enough manpower to maintain the whole desktop or to upgrade it to the latest version (it is essentially just me looking at it from time to time). So GNOME will be available in a preview state. We invite everyone with GNOME knowledge to join the project and help improving Tanglu-GNOME GNOMErs, we want you! systemd >= 204 We ship with systemd by default, which works nicely so far, although more testing needs to be done. The logind service will be used to replace ConsoleKit, if we manage to get everything in place and working in time (if there are issues, we might switch back to CK for one release). There are some plans to use a higher systemd version, due to some improvements made there, but if this will be done is still unclear (Debian will most likely stick to 204 for some time, because with systemd > 205, running it as pid 1 will be mandatory to use logind (and Debian is just in the process to decide which init-system we will use there)). Systemd will run in SysVInit compatibility mode for most of the available services. This will improve in later Tanglu releases. Of course, systemd is usable, even if not every init-script has been converted to a service file. It just has an impact on startup times, so Tanglu will not be the distributions with the fastest startup times (yet ). Debian Package Mix Tanglu consists mostly of packages from Debian Testing (Jessie), but we take full advantage of the Debian archive, so you will also find package versions from Unstable or even Experimental (where it made sense). A very small portion of packages has also been merged with Ubuntu. Although stuff has been changed, the incompatibilities with Debian are almost zero, so if you are installing Tanglu, it will currently feel like an more up-to-date Debian Testing with some extras. Still, the differences are large enough that upgrading a Debian system to Tanglu might result in some issues. Installer Right now, the installer is a major field of work. Tanglu will most likely ship with the Debian-Installer, because it is the easiest thing to do right now. For later releases, it is planned to also offer the Ubiquity installer (the thing Ubuntu uses), or a new installer with a similar UI and concept. Other Cool Things Tanglu will ship with a fully working Qt5 (which is currently being tested and updated) and the latest version of Wayland/Weston as a preview for developers to play around with. We also ship with Perl 5.18 and Haskell GHC 7.6, as well as with GCC 4.8 as default compiler (although the whole distribution does not yet compile with GCC 4.8). We might ship with Linux 3.12, but this also depends on other things. The Linux kernel build will be the same as in Debian. There might be more things to come Please do always keep in mind that Tanglu is a new project, so the first release might still have some teething problems but we re working on it. The Aequorea release will be supported one to two more months after the next release is out. Tanglu Policy I started to draft a Tanglu policy, which defines stuff like the procedures to become a Tanglu project member and/or developer, some basic values of the distribution, decision making processes etc. This work is at a very early stage right now, and will need lots of feedback later. But as soon as it is done, joining the project will be easier and what Tanglu is will be well-defined. The policy will also include a Code-of-Conduct as an additional document from the start. We need help! First of all, thanks to everyone working on Tanglu! You are amazing! Also, many thanks to every Debian developer or contributor who helped a lot in setting the project up and contributed knowledge. And of course, thanks to everyone else who contributed by creating awesome artwork, helped with code, Tanglu archive mirrors, buildd-servers or by testing the distribution and providing feedback! (given the state the aequorea suite was in at the beginning, testing was a really frustrating activity but people still did it!) So, if you would like to help, just find us on #tanglu-devel on Freenode or join the tg-devel mailinglist. We also really need some people taking care of the Tanglu website and updating it with some recent information from time to time, so people can see what is going on. Before we have the Tanglu policy finished and the Tanglu members and developers directory in place (a software which allows us to track all registered developers and gives them an @tanglu.org mailalias), the start might be a bit confusing, but we do our best to make it easy for new people to join. The best way is asking people. Tanglu is still created by an incredibly small team, which has a large task to accomplish. Help is welcome

Some catchup blogging: Kurt Elling was back in town on October 19, and not just in Chicago but quite literally in our little 'burb as the headliner for this season's concerts at Domiminican University. They had done us the favour of inviting Dianne Reeves back in March 2009, but this was clearly going to be a real treat. And I managed to snatch four front row (!!) tickets as soon as I heard about it, and the show once again didn't disappoint. Elling was as usual accompanied by his long-time collaborator Laurence Hobgood on piano, as well as local heros Clark Sommers on bass and John McLean on guitar. This time, Quincy Davies was on drums. And this band is realiably excellent, as is Elling in any live setting. The set was dominated by pieces from his most recent record and augmented by a few other standout pieces. There is a pretty rich set of live music by Elling on YouTube, see for example On Broadway (which was part of the set in a wonderfully fast and funked-up variant), Golden Lady (from the previous album, and also played live this time) or for example this wonderful version of You Send Me (also part of the concert). I snatched a photo or two (while at least turning my flash off, unlike the weird gal to my left, but I digress) and posted one on Google+. Kurt Elling will be back in Chicago at the Green Mill in early January. Expect to me there, and I hope to see you too!

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

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

• #707442 src:scim-chewing: "scim-chewing: FTBFS: conftest.c:68: undefined reference to shl_load'"
  add upstream patch, fixing version requirement, upload to DELAYED/2
• #716759 openshot: "openshot: mlt 0.9.0-1 renames python-mlt5 => python-mlt"
  fix dependencies, upload to DELAYED/2
• #723867 dpkg-sig: "dpkg-sig: FTBFS with perl 5.18: POD errors"
  fix POD for perl 5.18 compatibility, upload to DELAYED/2
• #723869 src:freetable: "src:freetable: FTBFS with perl 5.18: POD errors"
  fix POD for perl 5.18 compatibility, upload to DELAYED/2
• #723969 mapivi: "mapivi: Program does not start by too may errors"
  add patch for perl 5.18 compatibility, upload to DELAYED/2
• #724054 src:exrtools: "exrtools: FTBFS: no dependency information found for /usr/lib/x86_64-linux-gnu/libpng12.so.0 (used by debian/exrtools/usr/bin/pngtoexr)"
  tag unreproducible, then closed by submitter
• #724915 src:gpaint: "gpaint: FTBFS: image_processing.o: undefined reference to symbol 'log@@GLIBC_2.2.5'"
  add patch from Ubuntu / Daniel T Chen, upload to DELAYED/2
• #725526 src:getdata: "getdata: FTBFS: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision"
  propose a solution
• #725534 src:gummi: "gummi: FTBFS: automake errors"
  propose a patch, accepted by maintainer
• #725554 src:pimd: "pimd: FTBFS: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision"
  propose solutions
• #725570 src:pgfincore: "pgfincore: FTBFS: dpkg-buildpackage: error: dpkg-source -b pgfincore-1.1 gave error exit status 255"
  propose a patch
• #725591 src:ruby-passenger: "ruby-passenger: FTBFS: make[1]: /usr/bin/ruby1.8: Command not found"
  propose a patch
• #725599 src:squid3: "squid3: FTBFS: cp: cannot stat '/ PKGBUILDDIR /debian/tmp/usr/share/man/man8/basic_db_auth.8': No such file or directory"
  propose a patch
• #726730 tuxguitar: "tuxguitar: uninstallable in sid"
  fix dependencies (pkg-java)

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.

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.

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

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.

• [1] http://etbe.coker.com.au/2010/03/16/thinkpad-t61/
• [2] http://etbe.coker.com.au/2011/09/09/modern-laptops-suck/
• [3] http://shopap.lenovo.com/au/en/laptops/
• [4] http://www.graysonline.com/
• [5] http://www.thinkwiki.org/wiki/Category:T420
• [5] http://support.lenovo.com/en_AU/landing.page

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

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:

• Greg Kroah Hartman - while we've disagreed on a range of points, Greg's worked closely with userspace developers and even represents the Linux Foundation on the UEFI Forum. He's able to provide a wide range of expertise to the TAB and it benefits from that.
  
• Jon Corbet - Jon's work on LWN should need no introduction. He's done an amazing job of keeping track of a range of technical developments across the entire Linux community, so is uniquely well suited to making sure that a range of opinions is represented.
  
• Sarah Sharp - Sarah's certainly primarily a kernel developer, but she's been the loudest voice calling for the kernel community to spend some time thinking about whether it's as welcoming as it could be. Increasing the diversity of the kernel community allows us to hear a wider range of technical viewpoints, which benefits both the kernel and everything that depends on it.

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)

comments

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:

• new option -G or gen-full to generate from you archive (or from your tree of files) the configuration file and the list of files you need to run Brebis.
• new parameter target to check the target of a link

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

I really don t know why ethernet device makers insist on making it hard for to use their products. Ethernet has been around for many, many years; surely its not too much to ask for drivers that just work . And so that s the problem I currently have with my new computer. It has an onboard Ethernet interface which uses a Realtek chip and that s where the problems have been (with the exception of a power button that wriggled free, but that is also easy to fix). The device comes up as:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

I ve used:

• The R8169 driver that comes with most of the Debian kernels
• r8168-dkms driver
• The 8168 driver from the realtek site

and all of them don t work. It seems that the receive side works fine (I sometimes get a valid IPv6 address) but no packets are sent, even ifconfig eth0 shows zero transmitted packets. ethtool shows some of the setup, this is with the r8168 driver:

driver: r8168
version: 8.037.00-NAPI
firmware-version: 
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

Interestingly, if I use the r8169 driver in the kernel and try ifup etho then I do get an entry in the firmware-version spot. dmesg also shows that it finds the device.

[  0.916487] r8168 Gigabit Ethernet driver 8.037.00-NAPI loaded
[  0.916667] r8168 0000:03:00.0: irq 72 for MSI/MSI-X
[  0.939129] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[  0.939136] r8168  Copyright (C) 2013  Realtek NIC software team <nicfae@realtek.com>
[  10.807066] r8168: eth0: link up

So it all looks good, except it won t send any packets. Anyone got one of these devices and if so (and more importantly) how did you get it to work?

I've been using disk encryption (via LUKS and cryptsetup) on Debian and Ubuntu for quite some time and it has worked well for me. However, while setting up full disk encryption for a new computer on a RAID1 partition, I discovered that there are a few major problems with RAID on Ubuntu.

My Setup: RAID and LUKS Since I was setting up a new machine on Ubuntu 12.04 LTS (Precise Pangolin), I used the alternate CD (I burned ubuntu-12.04.3-alternate-amd64+mac.iso to a blank DVD) to get access to the full disk encryption options. First, I created a RAID1 array to mirror the data on the two hard disks. Then, I used the partition manager built into the installer to setup an unencrypted boot partition (/dev/md0 mounted as /boot) and an encrypted root partition (/dev/md1 mounted as /) on the RAID1 array. While I had done full disk encryption and mirrored drives before, I had never done them at the same time on Ubuntu or Debian.

The problem: cannot boot an encrypted degraded RAID After setting up the RAID, I decided to test it by booting from each drive with the other one unplugged. The first step was to ensure that the system is configured (via dpkg-reconfigure mdadm) to boot in "degraded mode". When I rebooted with a single disk though, I received a evms_activate is not available error message instead of the usual cryptsetup password prompt. The exact problem I ran into is best described in this comment (see this bug for context). It turns out that booting degraded RAID arrays has been plagued with several problems.

My solution: an extra initramfs boot script to start the RAID array The underlying problem is that the RAID1 array is not started automatically when it's missing a disk and so cryptsetup cannot find the UUID of the drive to decrypt (as configured in /etc/crypttab). My fix, based on a script I was lucky enough to stumble on, lives in /etc/initramfs-tools/scripts/local-top/cryptraid:

#!/bin/sh
PREREQ="mdadm"
prereqs()
 
     echo "$PREREQ"
 
case $1 in
prereqs)
     prereqs
     exit 0
     ;;
esac
cat /proc/mdstat
mdadm --run /dev/md1
cat /proc/mdstat

After creating that file, remember to:

1. make the script executable (using chmod a+x) and
2. regenerate the initramfs (using dpkg-reconfigure linux-image-KERNELVERSION).

To make sure that the script is doing the right thing:

1. press "Shift" while booting to bring up the Grub menu
2. then press "e" to edit the default boot line
3. remove the "quiet" and "splash" options from the kernel arguments
4. press F10 to boot with maximum console output

You should see the RAID array stopped (look for the output of the first cat /proc/mdstat call) and then you should see output from a running degraded RAID array.

Backing up the old initramfs If you want to be extra safe while testing this new initramfs, make sure you only reconfigure one kernel at a time (no update-initramfs -u -k all) and make a copy of the initramfs before you reconfigure the kernel:

cp /boot/initrd.img-KERNELVERSION-generic /boot/initrd.img-KERNELVERSION-generic.original

Then if you run into problems, you can go into the Grub menu, edit the default boot option and make it load the .original initramfs.

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)

comments

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.

Hello Following Gabor s post, I ve updated the Debian package for libdevel-ptkdb-perl. This new package is now available in experimental repository. Why not in unstable ? This new version of ptkdb (or is it a fork ?) was heavily changed and needs to be tested more before being released to unstable. I will use it during my regular Perl activities. Nevertheless, I would welcome feedback on this new version to help decide when to upload to unstable. All the best
Tagged: debian, Perl