Search Results: "ag"

27 May 2011

Lucas Nussbaum: Packaging tutorial update

This week I finally used my packaging tutorial slides myself, a few days after Phil Hands used them at a UKUUG event. The tutorial is now available as a Debian package (in Debian unstable) named packaging-tutorial, and I ve talked to debian-doc@ about linking it from appropriate places. It s also hosted on collab-maint now, so don t hesitate to contribute. Links :

Lucas Nussbaum: Changes to Ruby in Debian (and Ubuntu)

(this is a copy of an mail sent to ruby-core@ and ruby-talk@) Since the beginning of 2011, the Debian Ruby team has been working on several big changes. Those changes all are available in Debian unstable, some of them are also available in Debian testing, and they should all be available in the next Debian and Ubuntu releases. I think that it addresses most of the reasonable concerns about Ruby in Debian. Using alternatives to switch between Ruby implementations The alternatives system is now used to manage the ruby symlink and the other related symlinks, making it easy to switch between Ruby implementations (only Ruby 1.8 and 1.9.X at the moment) (see this mail for details). The default choice for Ruby is still 1.8, but this change will make it easy for us to make a switch to 1.9.X by default (likely by the release of Debian wheezy). Installing gems executables to /usr/local/bin Rubygems (both as a standalone package, and as shipped with Ruby 1.9.X) now install executables to /usr/local/bin. (The other files still get installed under /var, see this mail) Enabling gem update system gem update system has been re-enabled. Since upgrading rubygems to a version that may not have been properly tested with the rest of the Debian system may cause issues in the user s system, there s a big warning about that. The user can confirm and upgrade rubygems anyway by defining an environment variable. New gem2deb packaging helper There s a new packaging helper, named gem2deb, that makes it very easy to generate Debian source packages from Rubygems. We are in the process of migrating all ruby libraries packaged in Debian to that new helper. It will take some time, though (help is welcomed). Transition status: http://pkg-ruby-extras.alioth.debian.org/wheezy/ One big benefit of the switch to gem2deb for the Ruby community is that, in the process, we are enabling test suites at build time for each package and each Ruby implementation. This should make it easy to detect regressions in new interpreter versions. Ruby 1.9.3 We will switch to Ruby 1.9.3 ASAP (probably when it is branched off trunk, with a package first in Debian experimental). Since the Ruby compatibility version issue is likely to stay around, we will re-evaluate how we are dealing with it (to avoid the ruby1.9.1 package <=> ruby -v = 1.9.2 problem that confuses many users). This is likely by switching the package name to ruby1.9.3 (keep a ruby1.9.1 package for compatibility). The package containing the shared library will stay libruby1.9.1. Links

Dirk Eddelbuettel: JPM Chase Corporate Challenge 2011

As it is the Thursday before the Memorial Day weekend, it was time for the Chicago part of the JP Morgan Chase Corporate Challenge. In all the years that I've run this, conditions were never as bad as today. Windy, marginally wet and just plain cold with temperatures in the low 40s. But then again, it is just 3.5 miles and you do it with a bunch of collegues embedded in a crowd of thousands and you get a few cold ones afterwards. Who'd complain, really? The race went ok -- I didn't go out too fast, maintained pace and was able to accelerate towards the end. My hand-stopped time was 22:58; for the first time we actually had chip timing in this race and my official time appears to be 23:00. Which is still 50+ seconds faster than last year, and a pace of around 6:34 and compares well to the other eight previous times I've run this.

26 May 2011

Tanguy Ortolo: PGP signatures with trust and verification level

Identity checks and trust Saint Peter's key, detail from a stone statue The OpenPGP web of trust is composed of keys linked to each other by two things: With these two pieces of information, GnuPG is able to determine whether or not the key of someone you never met can trusted to belong to its alleged owner. Signatures Signing a key is usually a binary action: either you sign it or you do not sign it. Thus your signature on a key will give other people a rough identity check information and no trust information at all. In fact, the OpenPGP standard does allow to publish precise identity check and trust information on signatures, but unfortunately this is now enabled with GnuPG by default. These features are called certification level and trust signatures.Certification level To indicate how careful you verified someone's identity, run GnuPG with the option --ask-cert-level, or add ask-cert-level to your configuration file .gnupg/gpg.conf. When you make a signature with this option, GnuPG will ask you how carefully you verified the key owner's identity. According to the manpage gpg(1), the available levels are: Trust level You can also indicate how much you trust someone, sign his key with the command tsign instead of sign. GnuPG will then ask you three questions:
  1. how far you trust him to verify other people's keys: marginally or fully (I personally only fully trust people that were trained or challenged by myself or by people I trust even more)
  2. how far you allow him to make trust signatures on your behalf: usually answer 1; answering 3 would allow him to issue trust signature with level 2, thus allowing other people to issue trust signatures on your behalf (this features exists to implement pyramidal certification systems, but can be interesting for signing your own keys when you have several);
  3. if you wish to restrict this signature to a domain: I have no idea of what this means so I give none.
Conclusion Although certification level and trust signatures are not very widely used, thanks to GnuPG's default settings, it allows to publish more information about your signatures, adding value to the web of trust at no cost, which I believe is a good think. Thus I think it is worth doing it. If you want to use these features with the caff wrapper, remember that it has its own GnuPG configuration .caff/gnupghome/gpg.conf. In addition it does not implement trust signatures natively: to use them, you have to abort the automatic signing, which gives you a GnuPG prompt, where you are then able to tsign, then exit to return to caff that will consider your trust signatures. Credits

Dirk Eddelbuettel: RcppArmadillo 0.2.20

Conrad Sanderson is preparing version 2.0.0 of his Armadillo templated C++ library for linear algebra and has released a first public beta version 1.99.2. This has been folded into a new release of the RcppArmadillo wrapper for R based on our Rcpp library. Also added in this version is a new example of a simulation of a vector autoregression process which I had blogged about earlier. The example had been prepared for the Rcpp workshop / class at last month's R/Finance conference, and demonstrates a rather nice speed gain from using Rcpp and RcppArmadillo. The short NEWS file extract follows below.
0.2.20  2011-05-25
    o   Upgraded to Armadillo release 1.99.2 "v2.0 beta 2" (and 1.99.1 before)
          * faster inverse of symmetric matrices
          * faster element access for fixed size matrices
          * faster multiplication of tiny matrices (eg. 4x4)
          * faster compund expressions containing submatrices
          * added handling of arbitrarily sized empty matrices (eg. 5x0)
          * added syl()
          * added strans()
          * added symmatu()/symmatl()
          * added submatrices of submatrices
          * htrans() has been deprecated; use trans() instead
          * trans() now takes the complex conjugate when transposing a
            complex matrix
          * .is_vec() now outputs true for empty matrices
          * most functions with matrix inputs no longer throw exceptions when
            given empty matrices (eg. 5x0)
    o   Added a new subdirectory examples/ seeded with a nice Vector
        Autoregression simulation simulation example by Lance Bachmeier
    o   Rewrote armadillo_version as to no longer require an instance 
        of arma::arma_version, with tanks to Conrad for the suggestion
And courtesy of CRANberries, here is the diff to the previous release.
Diff between RcppArmadillo versions 0.2.19 dated 2011-04-24 and 0.2.20 dated 2011-05-26
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Col_proto.hpp               only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Cube_proto.hpp              only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/GlueCube_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Glue_proto.hpp              only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Mat_proto.hpp               only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/OpCube_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Op_proto.hpp                only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/Row_proto.hpp               only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/arma_ostream_proto.hpp      only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/arrayops_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/atlas_proto.hpp             only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/auxlib_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/blas_proto.hpp              only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/diagview_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/diskio_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eGlueCube_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eGlue_proto.hpp             only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eOpCube_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eOp_proto.hpp               only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eglue_core_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/eop_core_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/field_proto.hpp             only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/fn_htrans.hpp               only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/forward_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_conv_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_cor_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_cov_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_cross_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_join_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_kron_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_mixed_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_relational_proto.hpp   only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_solve_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_times_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/glue_toeplitz_proto.hpp     only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/injector_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/lapack_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/mtGlueCube_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/mtGlue_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/mtOpCube_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/mtOp_proto.hpp              only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_chol_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_cor_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_cov_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_cumsum_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_cx_scalar_proto.hpp      only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_diagmat_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_diagvec_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_dot_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_dotext_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_find_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_flip_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_htrans_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_inv_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_max_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_mean_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_median_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_min_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_misc_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_pinv_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_princomp_cov_proto.hpp   only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_princomp_proto.hpp       only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_prod_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_relational_proto.hpp     only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_repmat_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_reshape_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_shuffle_proto.hpp        only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_sort_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_stddev_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_sum_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_trans_meat.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_trans_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_trimat_proto.hpp         only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/op_var_proto.hpp            only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/podarray_proto.hpp          only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/running_stat_proto.hpp      only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/running_stat_vec_proto.hpp  only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/subview_cube_proto.hpp      only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/subview_elem1_proto.hpp     only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/subview_field_proto.hpp     only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/subview_proto.hpp           only
 RcppArmadillo-0.2.19/RcppArmadillo/inst/include/armadillo_bits/wall_clock_proto.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/ChangeLog                                                  20 
 RcppArmadillo-0.2.20/RcppArmadillo/DESCRIPTION                                                10 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/NEWS                                                  26 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/examples                                           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/RcppArmadillo/Mat_meat.h                       8 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo                                    199 -
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Col_bones.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Col_meat.hpp                  519 +++
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Cube_bones.hpp              only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Cube_meat.hpp                  96 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/GlueCube_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Glue_bones.hpp              only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Mat_bones.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Mat_meat.hpp                  673 +++-
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/OpCube_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Op_bones.hpp                only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Proxy.hpp                      28 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/ProxyCube.hpp                  20 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Row_bones.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/Row_meat.hpp                  491 +++
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arma_ostream_bones.hpp      only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arma_ostream_meat.hpp          87 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arma_static_assert.hpp         31 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arma_version.hpp                6 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arrayops_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/arrayops_meat.hpp             143 -
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/atlas_bones.hpp             only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/auxlib_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/auxlib_meat.hpp               772 ++++-
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/blas_bones.hpp              only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/compiler_setup.hpp             17 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/debug.hpp                      24 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/diagmat_proxy.hpp              93 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/diagview_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/diagview_meat.hpp             128 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/diskio_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/diskio_meat.hpp               104 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eGlueCube_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eGlueCube_meat.hpp             14 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eGlue_bones.hpp             only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eGlue_meat.hpp                 14 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eOpCube_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eOp_bones.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eglue_core_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eglue_core_meat.hpp           519 ++-
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eop_core_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/eop_core_meat.hpp             327 +-
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/field_bones.hpp             only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_accu.hpp                    40 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_det.hpp                      7 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_diagmat.hpp                  7 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_elem.hpp                    62 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_eye.hpp                  only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_inv.hpp                     18 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_log_det.hpp                  8 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_max.hpp                     38 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_mean.hpp                    42 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_median.hpp                  53 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_min.hpp                     38 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_ones.hpp                    45 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_prod.hpp                    20 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_randn.hpp                   10 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_randu.hpp                   12 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_stddev.hpp                  20 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_strans.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_syl_lyap.hpp             only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_symmat.hpp               only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_trans.hpp                   35 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_var.hpp                     20 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/fn_zeros.hpp                   12 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/forward_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/gemm.hpp                      337 --
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/gemm_mixed.hpp                 59 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/gemv.hpp                      208 +
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_conv_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_conv_meat.hpp             16 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_cor_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_cor_meat.hpp              12 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_cov_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_cross_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_cross_meat.hpp            47 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_join_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_join_meat.hpp             46 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_kron_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_mixed_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_relational_bones.hpp   only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_solve_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_times_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_times_meat.hpp           493 +--
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_toeplitz_bones.hpp     only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/glue_toeplitz_meat.hpp          5 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/injector_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/lapack_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/mtGlueCube_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/mtGlue_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/mtOpCube_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/mtOp_bones.hpp              only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_chol_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cor_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cor_meat.hpp                14 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cov_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cumsum_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cumsum_meat.hpp              9 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_cx_scalar_bones.hpp      only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_diagmat_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_diagmat_meat.hpp            10 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_diagvec_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_dot_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_dotext_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_find_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_flip_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_htrans_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_htrans_meat.hpp             98 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_inv_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_inv_meat.hpp                13 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_max_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_max_meat.hpp                57 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_mean_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_mean_meat.hpp               34 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_median_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_median_meat.hpp            214 -
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_min_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_min_meat.hpp                33 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_misc_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_pinv_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_pinv_meat.hpp               10 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_princomp_bones.hpp       only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_princomp_cov_bones.hpp   only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_prod_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_prod_meat.hpp               34 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_relational_bones.hpp     only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_repmat_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_repmat_meat.hpp             29 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_reshape_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_reshape_meat.hpp            32 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_shuffle_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_shuffle_meat.hpp            10 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_sort_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_stddev_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_stddev_meat.hpp             34 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_strans_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_strans_meat.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_sum_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_sum_meat.hpp                38 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_symmat_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_symmat_meat.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_trimat_bones.hpp         only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_trimat_meat.hpp            190 +
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_var_bones.hpp            only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/op_var_meat.hpp                37 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/operator_times.hpp             12 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/podarray_bones.hpp          only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/podarray_meat.hpp              57 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/promote_type.hpp               18 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/running_stat_bones.hpp      only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/running_stat_meat.hpp           2 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/running_stat_vec_bones.hpp  only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_bones.hpp           only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_cube_bones.hpp      only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_cube_meat.hpp          50 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_elem1_bones.hpp     only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_elem1_meat.hpp         24 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_field_bones.hpp     only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_field_meat.hpp         37 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/subview_meat.hpp             1423 +++++++++-
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/traits.hpp                     69 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/typedef_u64.hpp             only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/undefine_conflicts.hpp      only
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/unwrap.hpp                     64 
 RcppArmadillo-0.2.20/RcppArmadillo/inst/include/armadillo_bits/wall_clock_bones.hpp        only
 RcppArmadillo-0.2.20/RcppArmadillo/src/RcppArmadillo.cpp                                      27 
 253 files changed, 6400 insertions(+), 2358 deletions(-)
More information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Dirk Eddelbuettel: R / Finance 2011 presentations

I just sent the text below to the r-sig-finance list:
The organizing committee for the R/Finance 2011 conference is pleased to announce the availability of presentation slides from the 3rd annual R/Finance conference. This year's two-day conference once again attracted over 200 participants from across the globe. Academics, students and industry professionals enjoyed almost 30 talks covering trading, optimization, risk management and more --- all using R! The majority of these presentations are now available for download at:
http://www.RinFinance.com/agenda/
This year we began offering prizes for the best paper submissions. The 2011 recipients are Robert Gramacy (University of Chicago) and David Matteson (Cornell University) who each won USD 1000. Also new was a graduate student travel award: Mikko Niemenmaa (Aalto University) and Cl ment Dunand-Ch tellet ( cole Polytechnique) each received USD 500. With this, the organizing committee would like to thank our lead conference sponsors, the International Center for Futures and Derivatives at UIC and Revolution Analytics, as well as our conference sponsors OneMarketData, RStudio and Lemnica for their continued support. The organising committee would also like to thank all of the presenters and participants for making R/Finance 2011 so successful. We look forward to seeing you in 2012, with the prospective dates of May 17 - 19 to be confirmed. For the organizing committee,
Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich
Enjoy!

25 May 2011

Iain Lane: Greetings, Planet Debian!

Well hello there. A couple of days ago my debian.org account was created, meaning that I'm one1 of the crop of current new Debian Developers. Actually the news was broken to me by Rhonda when I attached to irssi after arriving at work, a nice surprise :-)
<Rhonda> All congratulate Laney on becoming a Debian Developer.  ;)
* Rhonda . o O ( http://db.debian.org/search.cgi?dosearch=1&uid=laney )
<Laney> Rhonda: I did?!?!?!
I'll quickly introduce myself by paraphrasing from the background section of the AM report before letting you go about your business. I apparently submitted my first thrilling patch to the alsa-tools package in Ubuntu on February 2nd, 2008. This was sponsored into Hardy by Daniel Chen. Thereafter followed a myriad of exciting patches to various packages that somehow managed to convince a bunch of people that I had enough skill to become an Ubuntu developer. Fast forward a while and I get sucked into the world of Debian packaging by the CLI/Mono strike force of Mirco Bauer and Jo Shields by way of the Mono 2.0 transition. This was where I got my first Debian upload, and it was in this team that I fully realised both the excellence and importance of Debian in the FOSS world2. At some point the Debian Haskell Group formed and I've been involved to some extent there all along too. What I've mainly learned from these two groups is that team maintenance is a really great way to look after a bunch of related packages. When I see people touting new packages about, I often recommend that they look at the list of teams to find a nice home. Perhaps one or two actually did. Thanks to everyone who's supported me so far. I hope to be able to do the same for others in the future.

  1. Along with obergix, lopippo, oliva, aron, madamezou, taffit. Congrats to the rest of you, too :-)
  2. I now consider it one of my primary duties as an Ubuntu developer to reduce the number of fixes that are uploaded to Ubuntu, and take every opportunity that is given to me to promote Debian as the natural home for technically excellent work. Not least because I fully expect DDs to not shy away from calling out poor work presented to them.

Matthew Garrett: Trials and tribulations with EFI

I wrote about some EFI implementation issues I'd seen on Macs a while back. Shortly afterwards we started seeing approximately identical bugs on some Intel reference platforms, and fixing it actually became more of a priority.

The fundamental problem is the same. We take the EFI memory map, identify the virtual addresses of the regions that will be required for runtime (mapping them into virtual address space if needed) and then call the firmware's SetVirtualAddressMap() implementation in order to let the firmware convert all its pointers. Sadly it seems that some firmware implementations call into sections of boot services code to do this, which is unfortunate because we've already taken that back to use as RAM. So, given that this is clearly against the spec, how does it ever work?

The tediously dull version is that Linux typically calls SetVirtualAddressMap() in the kernel, and everyone else does it in their bootloaders. The bootloader hasn't set up NX bits or anything, so it just happens to work there. We could just do it in the bootloader in Linux, but that makes doing things like kernel address space randomisation trickier, so it's not the favoured approach. So, instead, we can probably just reserve those ranges until after we've switched to virtual mode, and make sure the pages are executable. This ought to land in 2.6.40, or whatever it ends up being called.

(The alternative approach, of just never transitioning to physical mode, turns out to mysteriously fail on various machines. Calls to SetVariable() just give errors. We just don't know)

That still leaves the problem of SetVariable() on the test Mac trying to access a random address. That one turned out to be easier. There's 2MB of flash at the top of physical address space, and this was being presented as being broken into four separate EFI regions. While physically contiguous, Linux was mapping these to discontiguous virtual addresses. Apple's firmware appeared to assume that a pointer into one region could just be incremented into another. So because it's still easier to change the kernel than change Apple, 2.6.39 merges these regions to ensure they're contiguous.

Remaining problems include some machines seemingly not booting if they have 4GB of RAM or more and this Apple failing to communicate with its panel over the eDP auxchannel. Anyone got any idea how to dump the bios compatibility module out of a running EFI session?

( Comments Comment on this)

Guillaume Mazoyer: Here is a new GSoC student

java.pngHello Planet Debian reader.

And now you re thinking, who is this crazy guy who does not even know how to write English (is my sentence wrong?). My name is Guillaume Mazoyer and I am the Google Summer of Code student working on Jigsaw with Tom Marble and Sylvestre Ledru. I blog from France and I plan to write my GSoC reports right here.

Maybe you don t know what is Jigsaw yet. If so, go read this wiki page, you should be able to understand the goal of my project. Here is the description:

Since the beginning of Java, the JVM is a big virtual machine will all the features incorporated in it. This JVM provides many features which are useful in only limited areas (Corba) or which are not used at all in some contexts (AWT/Swing are useless for a web server).

The goal of the jigsaw project is to provide a modular JVM.

This will provide many improvements in the performance area (startup, solving of the dependencies, etc) but also the size of the dependencies.

There are already some works done by upstream (Oracle) but it does not complain to the Debian standards. The target is Java 8.

The goal is this Google Summer of Code project is to package the current development version of Jigsaw into Debian.

Please note that this project is not only about packaging. This will probably implies some developments and contributions to upstream (upstream is aware of this effort). Updating javahelper to manage specifities of Jigsaw could be considered.

I m pretty excited to work on this project and the work has already started. Can t wait to go deeper and enjoy working on two things that I love: Debian and Java.

Russell Coker: Links May 2011

John W. Dean wrote in insightful series of three articles for Findlaw about Authoritarian Conservatives [1]. In summary there are Authoritarian Followers who follow their leader blindly and Authoritarian Leaders who do whatever it takes to gain and maintain power. The Authoritarian mindset lends itself towards right-wing politics. Mick Ebeling gave an inspiring TED talk about his work developing a system to produce art that is controlled by eye movements [2]. The development work was started to support the quadriplegic graffiti artist TEMPT1. Mick s most noteworthy point is that all the hardware design and software are free so anyone can implement it without asking an insurance company or hospital (this is one of the few occasions when a TED speaker has received a standing ovation during a talk). The Eyewriter.org site has the designs and source which is licensed under the GPL [3]. Morgan Spurlock (who is famous for Supersize Me ) gave an amusing TED talk titled The Greatest TED Talk Ever Sold [4]. He provides some interesting information about the brand sponsorship process and his new movie The Greatest Movie Ever Sold . Ralph Langner gave an interesting TED talk about reverse-engineering the Stuxnet worm and discovering that it was targetted at the Iranian nuclear program [5]. The fact that the Stuxnet environment could be turned to other uses such as disrupting power plants is a great concern, particularly as it has special code to prevent automatic safety systems from activating. Angela Belcher gave an interesting TED talk about using nature to grow batteries [6]. She is evolving and engineering viruses to manufacture parts of batteries and assemble them, the aim is to scale up the process to manufacture batteries for the Prius and other large devices at room temperature with no toxic materials. She is also working on biological methods of splitting water into hydrogen and oxygen which has the obvious potential for fuel-cell power and also solar PV cells. As an aside she mentions giving a copy of the Periodic Table to Barack Obama and he told her that he will look at it periodically . Bruce Schnier gave a good overview of the issues related to human perceptions of security in his TED talk about The Security Mirage [7]. There isn t much new in that for people who have been doing computer work but it s good to have an overview of lots of issues. TED has an interesting interview with Gerry Douglas about his work developing touch-screen computer systems for processing medical data in Malawi [8]. This is worth reading by everyone who is involved in software design, many of the things that he has done go against traditional design methods. Mike Matas gave an interesting demo at TED of the first proper digital book [9]. The book is by Al Gore and is run on the iPad/iPhone platform (hopefully they will have an Android version soon). His company is in the business of licensing software for creating digital books. The demonstration featured a mixture of pictures, video, audio, and maps with the pinch interface to move them around. Dr Sommers of Tufts University wrote an interesting post for Psychology Today titled Why it s Never About Race [10]. It seems that there are lots of patterns of people being treated differently on the basis of race but for every specific case no-one wants to believe that racial bias was involved. The Register has an amusing article about what might have happened if Kate had left Prince William at the altar [11]. Fiorenzo Omenetto gave an interesting TED talk about synthetic silk [12]. He is working on developing artificial fibers and solids based on the same proteins as silk which can be used for storing information (DVDs and holograms), medical implants (which can be re-absorbed into the body and which don t trigger an immune response), and cups among other things. Maybe my next tie will have a no pupae were harmed in the production notice. ;) The CDC has released a guide to preparing for a Zombie apocalypse [13], while it s unlikely that Zombies will attack, the same suggestions will help people prepare for the other medical emergencies that involve the CDC. Salon has an interesting article by Glenn Greenwald who interviewed Benjamin Ferencz about aggressive warfare [14]. Benjamin was a prosecutor for war crimes at Nuremberg after WW2 and compares the US actions since 9-11 with what was deemed to be illegal by the standards of WW2. Eli Pariser gave an interesting TED talk about Online Filter Bubbles [15]. He claims that services such as Facebook and Google should give more of a mixture of results rather than targetting for what people want. The problem with this idea is that presenting links that someone doesn t want to click doesn t do any good. It s not as if the filter bubble effect relies on modern media or can be easily solved. Terry Moore gave a TED talk about how to tie shoelaces [16]. Basically he advocates using a doubly-slipped Reef Knot instead of a doubly-slipped Granny Knot. Now I just need to figure out how to tie a doubly-slipped Reef Knot quickly and reliably. Terry uses this as a mathaphor for other ways in which one might habitually do something in a non-optimal way.

24 May 2011

Aron Xu: Sending files from initramfs busybox

I have to say busybox is so cool! Today I did an installation of Debian Squeeze using daily netinst ISO image in an i686 qemu-kvm virtual machine. I was using ext4 for /boot, and btrfs for /. The installation process was quite normal as expected. After the installation I rebooted the virtual machine. Grub2 loaded [...]

Aron Xu: Linux input method framework brief summary

I am trying to keep this article concise for you to make you have an outline of current condition of Linux (and maybe other platforms like BSDs) input methods. It s coverage is mostly CJK languages, but I think other languages that use input method would be sure to find there examples in this article. We [...]

Aron Xu: Debian Maintainer

Debian Maintainer Debian Debian Maintainer (DM) Debian Debian Developer (DD) Debian 1. Debian 2. Debian New Maintainer s Guide Debian Debian 3. WNPP (Work-needing and Prospective Packages) Bug 4. Debian Developer DD sponsor DD Debian sponsor Debian [...]

Nathan Handler: Hello Planet Debian

Hello everyone. Per tradition, I will use my first post to Planet Debian as a bit of an introduction. My name is Nathan Handler. I am Ubuntu Developer and a member of freenode staff. Currently, I am participating as a student in the Google Summer of Code program with Debian. I am working on Backend Tools and Infrastructure for DEX (aka dextools ) with Matt Zimmerman as my mentor. To quote the project description:
DEX is a new program designed to help improve Debian and its derivatives by merging in changes made downstream and encouraging discussions between the various projects. As this is a new project, most of the infrastructure does not exist (or is rather hackish and incomplete). This project will create the necessary backend tools and infrastructure so that all Debian derivatives can easily make use of the DEX project.
While I have not been great with updating my blog in the past, I am going to try and produce regular posts about my Summer of Code work. If you have any questions about DEX or are interested in getting involved, please check out the Get Involved section on the website.

Russell Coker: Are Assholes Essential to a Free Software Project?

What do Assholes do? Rusty just wrote a post titled If you didn t run code written by assholes, your machine wouldn t boot [1] about some of the anti-social tendencies demonstrated by programmers, including some that are implied to be fairly important. His post seems to imply that there are really great programmers who are anti-social and that we should just put up with it because of their great code. One of the problems with his post is that he doesn t define asshole . Holocaust deniers and all other Nazi supporters seem to clearly by assholes by any definition. People who have silly ideas about medicine and tell others seem to be merely misguided (although my dictionary gives stupid or irritating or ridiculous in the definition of asshole so technically they can meet the criteria). In the comments Rusty states that nuttiness is relative . While that is correct it doesn t seem to have much bearing on whether someone is an asshole. For example I know some very nice people who are utterly convinced by creationism. Is Anyone Essential to Free Software? Most projects have one person or several people in leadership positions, usually there seems to be a combination of project management and lead-programmer positions. Such people are obviously quite important to a project. But we have seen examples of people dying, being employed by Microsoft, retiring, relicensing the source in a bad way, and just losing interest without the project ceasing. It seems clear that in most cases when a project which has a significant amount of use has significant bugs and no maintainer then someone will step in. The cases where no-one takes over the project are often resolved by someone creating a competing project. If no-one takes over an abandoned Free Software project then it s a strong indication that the project wasn t particularly important anyway. I have no doubt that if any bug or missing feature made Linux systems stop booting then someone would fix it quite quickly. In a more general sense it seems that every time someone takes a position in a project that is of wide interest they are displacing someone else who might have done the job. When you volunteer to do significant work for a project you may be displacing someone who is more skillful than you this isn t necessarily a bad thing as there are plenty of other projects to work on, some of which require more skill. Growing More Programmers It seems to me that a large part of becoming a great programmer is facing great challenges. People who could be described as optimistic or arrogant will tend to take on more challenging tasks and therefore learn more. I m sure that there are a lot of people out there who have the potential to be great programmers apart from not taking on the challenging work, this seems to be an unfortunate waste of talent. Given a large enough population if someone leaves a senior position there should be someone else who can obtain the skills needed to take over. One advantage of this for Free Software development is that even if the best person to take on the challenge isn t living in the most convenient continent that won t be an obstacle, while with proprietary software development projects the teams are small and it s common that no-one else is capable of stepping up to a lead position. Another advantage is that when the lead developer leaves there are generally many candidates to replace them, all of whom can start work and be judged on the work that they do. I think that the best claims that can be made regarding essential people are not in regard to technical skill alone but to a combination of technical and people skills. Getting a group of programmers to work together is really hard but it s something that needs to be done for any significant project. Also the larger projects tend not to stand alone, being able to get changes included in other projects requires some skill. Ben Collins-Sussman and Brian Fitzpatrick gave an insightful talk at Google IO 2008 titled How to Protect Your Open Source Project From Poisonous People [2]. The first half of their talk is mostly about people who are misguided or difficult rather than what most people would consider poisonous and the second half is more about people who are actively poisonous and need to be removed. They advocate a community based on Politeness, Respect, Trust, and Humility. They describe in detail how the methods they advocate result in the members of their community being more productive, it seems obvious that those principles will lead to better career growth for people within the community and more friendly people wanting to join. When is being an Asshole OK? I once worked for a company that apparently had a team consisting solely of assholes. Apparently one asshole got promoted to management and after some internal transfers they ended up with all the assholes in the company on one team. I guess that when someone has negative interactions with everyone they won t notice the difference if they are put in a team where everyone is difficult. For a corporate environment that lacks a no jerks hiring policy this is probably a good way of improving productivity overall. I am not aware of any significant Free Software project that was comprised of mostly jerks although I have seen a few with dysfunctional environments that encourage the worst behavior from their members. The smaller Free Software projects have less need for people who can relate to other people. There are many useful Free Software projects which have only one developer, in most cases anyone can take the source code and use it without dealing with the author. But even for a single-developer project an asshole can cause some serious problems. One example I know of concerns a developer who had unclear licenses and started making legal threats in response to a request for a clear license. Another example is of a developer who released code that was designed to not work when one particular user compiled it and redistributed the binaries. Both of them caused some significant amounts of time to be wasted by people who were unfortunate enough to develop systems that interacted with the code in question, and even more time was wasted when some misguided people defended them in the inevitable flame-wars. Even for a project with only one developer it s still better for everyone if that developer isn t an asshole. One comment I ve seen related to this issue suggesting that some types of asshole behavior shouldn t be a problem an example that was cited is a colleague who cheats on a romantic partner. Jeremy Clyman (who is currently doing a Ph.D in Psychology) has written an interesting article about this for Psychology Today [3]. He reviews the movie The Dilemma which deals with someone catching their colleague s wife cheating. Jeremy analyses the psychological issues involved and how they can (among other things) impact the ability for such people to work. I once worked in an office where two married employees were very open about having an affair and we were all apparently expected to lie on their behalf if necessary, it really affected the quality of the working environment. Extreme Assholes There are lots of people involved in Free Software development who are difficult and many who are to some extent assholes. But some of them take being an asshole to the extreme, such as Holocaust deniers (an example which Rusty used). In the comments on his post the Westboro Baptist Church is also mentioned. It is possible to entirely disagree with someone on a contentious issue such as abortion but still be able to get along with them. But when someone supports a hate-based organisation such as the WBC or supports Nazis in any way then there will be many people who just can t tolerate them and no-one should be expected to tolerate such people. I have seen two instances where Free Software developers advocated pro-Nazi positions (one had an archive of neo-Nazi propaganda and the other claimed that Nazis were not responsible for the Holocaust). Neither of the pro-Nazi programmers was evicted for defending Nazis, but both of them ended up leaving the community in adverse ways after causing other damage in the mean time. I don t think it takes any great ability to predict the future to determine that someone who defends Nazis will eventually end up doing something that requires expulsion and drive away users and developers in the mean-time. There is no possibility that someone can support the Nazi or WBC ideology only when not associated with your project, it will affect all aspects of their life. When a Holocaust denier is allowed to be a member of a community it also sends out a message that members of the groups which were persecuted by Nazis aren t particularly welcome in the community. Helping Minor Assholes There are a lot of people who don t have malevolent aims but who unintentionally cause some difficulty (it seems that the truly malicious are a tiny minority). I don t think that excusing the bad things that they do on the basis of writing good code helps them in the long term. Many of the suggestions that Ben Collins-Sussman and Brian Fitzpatrick make seem likely to help people who don t want to be assholes and direct them towards positive involvement in the community. One trend that seems apparent is the non-linear response to certain types of bad behavior. There is often little difference in severity between something that gets almost no attention and something that results in a large and extremely hostile reaction. If someone persists in acting like an asshole for long enough it seems to be inevitable that they will eventually exceed some threshold for what is tolerated and get a very significant negative response. It would be good if things didn t need to get to that stage. I think that the most unfortunate aspect of Rusty s blog post is that most people will probably interpret it as encouragement to write better code as a way of getting a free pass for being an asshole. I know that this isn t what Rusty intended, but most people on the Internet don t know Rusty as well as I do. Conclusion Ben Collins-Sussman and Brian Fitzpatrick seem to have some of the best ideas for how to deal with these issues when you control a project, but most of us aren t in that position. Everyone can advocate better behavior. Extreme assholes need to be removed quickly and without a great debate about their contributions, freedom of speech, or other issues. Since considering this issue I ve been wondering about when one should avoid the lesser assholes and asshole-positive environments. People tend to adapt to their environment, so if you associate with assholes a lot then there s a good chance you will start to become like them. Is

Cyril Brulebois: Git tip of the day: insteadOf

The recent Alioth migration (thanks, Alioth folks!) led to slight variations in the URL schemes for various VCS. I guess some migration path will be considered but in the meanwhile that seemed to be a good example for the nice git-config insteadOf trick. Here s the bottom of ~/.gitconfig:
[url "git://anonscm.debian.org"]
    insteadOf = "git://git.debian.org"
[url "ssh://git.debian.org"]
    pushInsteadOf = "git://git.debian.org"
And tada! debcheckout picks the appropriate service (anonscm for anonymous access), and one is still able to push (through ssh) without having to change the URL in each and every .git/config file (which would also lead to higher CPU usage when updating afterwards).

Sam Dunne: GSoC Welcome Package Arrived

This morning I awoke to a FedEx box landing on my head courtesy of my father. I jumped up and took a look at it package I quickly opened it to find myself some goodies and a nice welcome letter Welcome letter Ooooh shiny Shiny things Finally the holy grail ;) See through Just thought I d make everyone jealous of my shiny Google things :P
Now back to work, ~Sam

Aigars Mahinovs: NVidia Optimus fail

Guys, we have a problem. The name of that problem is NVidia and their Optimus technology. The idea of that tech is quite neat take a laptop, put two video cards in it, use the powerful card when you need 3D power, use the weak card when you need to conserve battery. The problem is that any laptop with this technology is currently an expensive paperweight on Linux (or rather it was so until a couple weeks ago, see below). And NVidia has no plans for fixing that. Let me explain the technicalities. In all modern laptops (such as the new and sexy Dell XPS 15z and many, many others) NVidia Optimus is implemented as follows there is an NVidia card and an Intel card, all display outputs are connected to the Intel card, when the user wants more 3D power, the NVidia card is powered on and it renders an image into a framebuffer in the video memory of the Intel card which is the responsible for actually outputing that framebuffer to a display. Currently in Linux if you are using NVidia drivers the Intel card is left uninitialised, your session starts up fine on the NVidia card, it outputs the resulting picture onto the video memory of the Intel card, but the Intel card is not configured in any way and so it does not do anything further with this picture and the display stays black. The alternative is to use Intel video card driver and then the NVidia card stays there in your laptop as dead weight. It does not even power down (out of the box) so you have all the power consumption and none of the functionality. There is some support from NVidia to using that card for CUDA computing purposes in such situation, but nothing else. After years of neglect and statements from NVidia that Optimus support in Linux is impossible and thus not even planned, one individual stepped up and made it work. Yes, the solution is hacky, yes it is a hassle to set up and make it work, but this is the first glimmer of hope for actually working Optimus on Linux. Over the last couple years the share of laptops with Optimus has greatly increased almost all laptops that have NVidia video cards have Optimus now. This Bumblebee project is currently our only real hope on making Linux work on these laptops. This project needs our support in a multitude of ways:
1) help test the actual project on different hardware;
2) look at the code and help improve on it, both the core code and system integration, simplify it so that everyone can install and use this;
3) figure out how we can integrate that support into distributions, so that it becomes possible to have working Linux out-of-the-box on Optimus hardware;
4) pressure NVidia more to provide official Optimus support on Linux (at least in always-on-NVidia mode, without breaking Bumblebee along the way). Martin has already showed the superiority of open source by implementing something that NVidia considered to be too hard to do, let s show the power of our community to push such solutions to production quality.

Russell Coker: Book Company Bankruptcy

In February Borders went bankrupt [1], since then they have been in the slow process of closing down. Now Borders is trying to clear the last of their stock and offering 80% discounts off the marked price. I bought a book by Stephen Baxter and one by Peter F. Hamilton and those appeared to be the last two books worth buying (IMHO) on the almost empty sci-fi shelves, the books were a little tattered but at 80% discount I m not complaining. It s been almost four years since I last bought books, and I still haven t read all the free sci-fi stories and watched all the free sci-fi movies from the net which interest me [2]. So I m not planning to buy many more books unless I see something better than a 50% discount. Paul Wayper writes about the difficulty of buying ebooks [3]. It s ironic that some people have claimed that ebooks were part of the cause of Borders financial troubles given that they really aren t working well, not even for the most dedicated buyers. In related news Kobo (the company that runs the Borders ebook store) has assured customers that they won t lose the books that they own [4]. There are very few situations in which a company needs to assure customers that they won t lose property that they have paid for and received due to a corporate bankruptcy. As further evidence that Digital Restrictions Management (DRM) is a bad thing, Apple have shut down the iFlow Reader [5] so that they can monopolise ebook sales on the iPhone and iPad. This is a good reason to avoid restricted platforms (such as anything from Apple) and encrypted content. It seems to me that Cory Doctorow s scheme for giving copies of his books to libraries is a more effective way of donating in return for a free ebook [6] (which is rather similar to the buy one get one scheme that they used to run for OLPC). Hopefully Charles Stross will end up doing something similar to make Paul Wayper happy.

23 May 2011

Tanguy Ortolo: Uninstalling a single component of a meta-package

Or how to get rid of Evolution without removing your whole system Tree from a GNOME package to Evolution, GIMP and Brasero packages There is a complain I have heard several times from people after they installed Debian: I use Icedove/Thunderbird so I do not need Evolution: I tried to remove it but this would remove my whole system, that sucks! Explanation The reason behind this situation is that GNOME is installed by a meta-package, which is a dummy package that depends on each component of the official GNOME desktop, including Evolution. So it got installed as a dependency of that dummy package. This means that you, or rather, the Debian installer, never asked explicitly to install either Evolution or any other specific software: it came automatically. Now, you want to remove Evolution: very well, but this implies removing the meta-package, as you are removing one of its dependencies. But if you are removing this meta-package, there is no reason to keep all this software you did not asked for, so, as they got installed automatically, they are now removed automatically as well The solution So, do you still want to remove Evolution but keep the remaining of your GNOME desktop? Of course you will not keep GNOME , because GNOME includes Evolution, so strictly speaking GNOME without Evolution is not GNOME any more. Well, there is a solution: marking all the dependencies of the meta-package as manually installed, that is, faking that you installed them explicitly Aptitude is able to do that with its powerful search functions:
# aptitude unmarkauto '?reverse-depends(gnome)   ?reverse-recommends(gnome)'
# aptitude unmarkauto '?reverse-depends(gnome-core)   ?reverse-recommends(gnome-core)'
# aptitude unmarkauto '?reverse-depends(gnome-desktop-environment)'\
'   ?reverse-recommends(gnome-desktop-environment)'
What did we do? Well, exactly what is written: unmarking as automatically installed the packages that reverse-depend or reverse-recommend gnome or gnome-desktop-environment. In other words, those that are dependencies or recommendations of gnome, gnome-core or gnome-desktop-environment. Why these three packages? Because the GNOME environment that Debian provides by default is composed of several meta-packages: I shall let you refer to their respective descriptions for further information. Now, you can safely remove Evolution without pulling out your whole desktop system:
# aptitude remove evolution

Next.

Previous.