Search Results: "spa"

4 October 2011

Miriam Ruiz: Periodic Calendar in Debian

Periodic Calendar, a GPL ed GUI application, coded in Java that helps keeping track of women menstrual cycles and predict fertility periods, has just entered Debian. This information can be used as supportive either for conception or contraception planning. This program (pcalendar in Debian) is by far more complete than mencal (a simple menstruation calendar that can be run in the console) or cycle (a windowed calendar that can calculate stuff based on the length of the cycle or on statistics of previous periods), and provides support for BBT and sympto-thermal methods, which have the highest reliability in fertility periods prediction. User can thus choose any subset of the features to be used or even fall to the generic calendar method (which if used alone is very unreliable). Screenshot of Periodic Calendar Keep in mind, though, that -as the authors of the program insist on- Periodic Calendar is NOT an equal substitute to the fertility planning consultants or doctors, and methods used are not 100% effective. It s a useful program, anyway. I ve also translated the program into Spanish, made some cute icons and added MIME support so that data files can be easily open from the desktop.

3 October 2011

Tanguy Ortolo: Viewers should stay in foreground

Traditionally, when you start a program to view a document, for instance xpdf resume.pdf, it stays in foreground, and only returns when it finishes, when you are done with the document. Of course you can still run it in background if you want. Nowadays, several programs behave in a different way, for instance Evince. When you first start it, it stays in foreground as usual. However, if you launch it a second time while the first instance it still running, it will reuse this existing instance, asking it to open your document in a new window, and immediately return. Other examples are Firefox and LibreOffice.This behaviour is certainly more efficient in terms of memory usage and speed, but it is non-standard and causes subtle problems. When you open the attachment of an email message, or when you open a document from the Web without saving it permanently, the mailer or the browser saves the document to a temporary file, and then run a viewer with that file. As this is a temporary file, so they cannot leave it forever in /tmp; in fact they should delete it when you are done viewing it. I think the usual way to implement that is to delete it when the viewer returns: with a program that returns immediately, this means deleting it even before it has had a chance to load it. So, if you can no longer directly open a PDF attachment from Mutt, or if you are unable to view the compressed documentation of the LaTeX class Beamer with texdoc (which uncompresses it to a temporary file and calls a PDF viewer on it), you can blame your modern PDF viewer that returns before you are finished and start hacking your mailcap file. And if you are the author of such a program, please consider implementing a way to keep a lightweight process that does not return before the main process has closed the document or to disable process reuse.

2 October 2011

Jose Luis Rivas Contreras: Moving from Screen to Tmux

I ve been a long-time user of GNU Screen, as almost every person I know that spend a lot of time in a terminal. I must admit I was happy, I really was. I was used to my workflow with 4 terminals 8 25 and a bunch of screens, with several nested-screens. I used awesome-wm before, so definitely I felt I wasn t using all the space in my laptop screen (my laptop is a ThinkPad X61, so 1024 768 in a 12 inches-screen) but that was OK, after all my workflow was, well, good. Until 2 days ago, I was told to try tmux, in fact, I was told and why are you using screen? use tmux . As a daily-user of Screen my first reaction was I m used to , I can use it as I want , and a lot of excuses for just not trying something new. But then I made a little research (on Google, of course). In about 30 minutes I ended up with a multiplexer working as I wanted and as I never got Screen to work. Finally I was using just a terminal and using all the space available in my tiny-laptop-screen and plus: saving a lot of bandwidth with my permanent SSH connection (a really big plus now that I m living with a capped link to the net with a GSM-modem). I changed the Ctrl-b shortcut to Ctrl-a (b is too far for using it with only one hand), configured so I could use nested tmux es like screen when I push Ctrl-a a, activated visual monitoring and even got to use the tmux s buffer along with my X11 buffer when I press Ctrl-a >!! It s all in my ~/.tmux.conf, use it at will. Later I will make a screencast about using tmux, so more people can get a working tmux easily. ATM, I m even more happy than I was with GNU Screen, so, any other recommendation, people?

Neil Williams: Uses of Emdebian - special purpose computers

A continuation of my intermittent series on Emdebian and prompted by a query from Paul Wise, I thought I'd cover some of the uses to which a device running Emdebian can be put. It is a bit long this one...

So, yes, there are general purpose computers which could run Emdebian but there are common features amongst general purpose computers:
  1. Lots of different tasks must be supported - lots of different packages installed, each user could quite easily use a distinct set of packages from another user.

  2. Multi-user support - even if any one machine is only used by one person, a general purpose computer must have support for adding another user - not just a system user, a real user with a login, shell, possibly bookmarks and browser history etc.

  3. Connectivity - general purpose computers (and that includes mobile phones) must connect to a variety of other computers to be at all useful.

  4. Multi-modal data input - there needs to be support for a mouse and a keyboard or touchscreen and just as likely, software support for accessibility interfaces like an on screen keyboard and switch inputs.

  5. Storage for user data - the system admin can't know how much data users are going to add and if it is general purpose, it's probably going to support media players, image viewers, even office software. The data files managed and written by such software tend to be large and tend to accumulate into large collections. This means that a general purpose machine cannot anticipate the full storage requirements, so has to allow plenty of room for user data storage. If there's so much storage space available, why use an OS which is primarily designed to take up less space? Just use the full version, Debian.


Now compare with the common features of special purpose or single-purpose computers:
  1. Single task only - a splash screen (without support for removal) covers all the boot information, the single task starts as a daemon and if the user quits the task, the task initiates a shutdown, not quit. Every effort is made to prevent the task from exposing the underlying OS, including auto-restarts if it does crash.

  2. Single-user support - indeed, user is not the typical user. user in this case is a non-login user without a shell, created by the postinst of the task package purely to support running the task without root privileges (because if the task doesn't need privileges, it shouldn't retain privileges).

  3. Single mode input - don't expect these machines to support 105 key keyboards. You'll be lucky to have 5 keys which are really just buttons. The button won't just enter 'J' into the machine, it will fire off a command to charge your bank or start a drill or shutdown a malfunctioning service. (Each button will often be multi-functional as well, depending on context). Some devices will replace the mouse with a touchscreen but many are fitted in places where touchscreens simply won't survive, where keys have to be able to withstand being submerged in water (or oil) for hours. Many machines simply won't have mouse support at all. Many will not have any typical external connectors. Indeed, units which go into dirty or wet environments certainly won't have standard external connectors of any kind. Think boats and factories. Internal battery packs with custom hot-fit replacements, buttons encased in 4mm of clear plastic, screens viewable only through protective mesh / filters.

  4. Restricted connectivity - if the task doesn't need networking, no networking hardware is fitted. If the task doesn't need USB, no USB hardware is fitted. If the task doesn't need serial connections, there will probably be an internal serial connector but also a Warranty void if removed sticker. Don't expect an RS232 inside the case either, this will be a flat cable connector which you'll need to attach to a breakout board which correctly connects the cable wires to the RS232 port pins. That mapping is not standardised (why would it? only service engineers are approved to use it.)

  5. Constrained user data - the task is in complete control and determines what the user can view, store and access. Storage can be expensive and a power drain, so if the task doesn't need Gb of storage, don't fit the machine with Gb of storage. Profit.


So what are these mysterious single-use computers running Emdebian? It's hard to tell because the task has no particular reason to tell the user anything about the OS. Perhaps a different way to phrase the same question would be: Why use a general purpose OS for a special purpose computer?.


This is why Emdebian Grip is popular for these machines - because Emdebian Grip is binary compatible with the equivalent Debian suite and when a bug appears in the high level user interface, it is much easier to debug that on the desktop than on device. Debian stable is a fantastic OS for commercial development - the stability of the OS makes detection of interface bugs much easier. It is rare that developers have to investigate whether bugs in their UI come down to a bug in the underlying OS. That saves time.

The machines themselves? I'm sure others can come up with other examples but these are some which come to my mind (no particular order):


Anywhere where the device simply needs to DoTheRightThing in a variety of unpredictable circumstances, you're going to need a general purpose OS to gather the data and produce the right result. Anywhere where the device has only a single task, you're going to want to not provide access to the rest of the system. There's no point providing "general purpose access" when the device doesn't have "general purpose hardware". There's no point fitting general purpose hardware if the device does not use it. That is a waste of money, a waste of resources and causes unnecessary delays if one component or other becomes unobtainable or changes behaviour. Limit your exposure to hardware bugs and get the product out to the user more quickly and more reliably, everyone is happy. Fit non-standard hardware and you can fit custom hardware which better matches the profile of the device usage - why use standard speakers capable of CD quality across a vast frequency range when the device only makes very very loud alert noises which can be done at lower sample rates and with narrow range, high amplitude, speakers.

There are all sorts of estimates for the number of computers now in the average Western home. It's worth noting that the vast majority of those computers are not PCs or laptops or even game consoles and routers - all instances of general purpose machines with general purpose access / connectivity. A lot of the computers in your home are embedded in machines like white goods, media controllers (set top boxes and the like). Some of these will still use low level firmware written entirely in assembly or COBOL. More complex ones already have a general purpose OS inside yet constrain that OS with a simple, user-friendly interface which is tailored to the hardware actually fitted. It might be cool to connect to your set top box over Bluetooth but really, is that actually going to sell more units? Only if there are other high-end services written for the device which the average customer won't want to see pushing up the price of the base unit. Some machines (particularly in automotive uses) will need to be using Real Time operating systems and Safety Critical operating systems but even some of those are based on general purpose systems - just old versions which have been thoroughly tested.

Finally, consider that for a lot of these devices, the customer is not you. The customer is another business who then put the device into something else which is installed into a factory production line which produces something which goes into creating a consumer product you find in Tesco or on Amazon or bundled in with another service like your TV/broadband contract. There is absolutely no reason for these devices to provide general purpose computing to you, even if the device itself is part of something else which can provide such services.

Sylvain Beucler: Smooth lighting - cont'd

phong The basic smooth lithting series comes to an end with adaptation of 2-sided lighting and multiple lamps support. The code is written for clarity, so it could be optimized. If you have a lightning-fast lighting implementation under the hand, feel free to contribute it :) phong On a side note, I'm looking for a way to draw quadrics in OpenGL ES 2.0, so without using the GLU library. Do you know how to do this?

1 October 2011

Sergio Talens-Oliag: Static website generators

The last month I was supposed to work on a OpenStack related project, but for administrative reasons it has been delayed and I've tried to do small tasks to be able to finish them quickly and start the work on the main project when the issues get solved. As the delay has been longer than expected last Wednesday I've realized than on the last weeks I did a lot of small system administration tasks: With all the changes I did I noticed that I had to do something with our Intranet server; it is just a reverse proxy for a lot of different web services and its main page was one static HTML page with links to them, nothing else. In the long term maybe we will replace it with something based on Drupal or Lifeay, but for now I just wanted something to be able to organize the links and provide some information about the services for the new users without having to write HTML (I really like Agile Documentation Tools that let me focus on the content and forget about the markup), and started to look at some of them. My first idea was to use ikiwiki, as it has all the features I was looking for: I can use Markdown or reStructuredText to write the contents, the source pages are easily handled on a Version Control System, it supports the use of templates for the HTML, etc., but it seemed to me that using ikiwiki was like killing flies with a cannon (that's a Spanish say, I guess it's easy to understand it in English, no?) and I decided to review other tools to build static web sites. To make a long story short, I selected some tools that met my requirements and looked nice on their demo sites; after my first review I thought that Hyde was going to be my bet, as it uses technologies I'm already familiar with, but after trying it I saw that I was going to have a problem with documentation (the current Hyde version lacks it) and it was going to be more complicated that using ikiwiki. Before giving up I decided to review simpler tools, just in case, and after looking some of them I ended up using poole, a simple python script (the source is just one file and it only requires python-markdown to work). Before moving to the content I tried to adapt a couple of free themes to be used by the tool, but I didn't liked the result, so I went back to the plain style provided by the tool and added a logo and a background. With that simple look and feel I started to work with the content, splitting it into eight markdown files and a python macro to include a file that has all the links used on the site. While trying to make the main page look good I noticed how little I know about CSS, but using search engines I was able to build a two column block into the main page and publish the contents and with the help of some CSS enabled co-workers I changed the look and feel of the site in about 30 minutes. In summary, if you want a really simple website, you know a little bit of python and don't want to spend much time learning how to use a website generator then Poole is a good option. If you want something more complex I still think that ikiwiki is a good option, but YMMV.

Sylvain Beucler: Multiple glUseProgram

3D programming is great, but when something goes wrong, it can be quite hard to debug! I was trying to launch two different OpenGL programs one after another, the first for the normal rendering, the second for a post-processing effect (motion blur, etc.). It seemed the first program's output was cleared as soon as the second one was activated. I eventually found a behavior that is well summed up at http://www.gamedev.net/topic/541571-glsl-changing-between-shaders/page__view__findpost__p__4495411. You don't write:
glUseProgram( shader-A );
modelA->Draw();
glUseProgram( shader-B );
modelB->Draw();
glutSwapBuffers();
You write:
modelA->Draw();
glUseProgram( shader-B );
modelB->Draw();
glUseProgram( shader-A );
glutSwapBuffers();
and since the code is called multiple times (at each frame), this will cycle OK. (There seem to be an GL_INVALID_OPERATION error the very first time I call glUseProgram, too.) Anybody has an idea on why we have this behavior?

30 September 2011

Dirk Eddelbuettel: Rcpp 0.9.7

A fresh maintenance release version 0.9.7 of Rcpp went onto CRAN and into Debian earlier today. This release contains two contributed fixes. The first, suggested by Darren Cook via the rcpp-devel mailing list, corrects how we had set up exceptions specifications, reflecting a bit of Java-think on our part. The idiom is generally discouraged in C++, and we now conform. The second came in two excellent patches by R Core member Martyn Plummer which finally get us compilation on Solaris. This is much appreciated as our hands were tied here for lack of access to such a box. Otherwise, two new examples and a new unit test were added. The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.
0.9.7   2011-09-29
    o   Applied two patches kindly provided by Martyn Plummer which provide
        support for compilation on Solaris using the SunPro compiler
    o   Minor code reorganisation in which exception specifiers are removed;
        this effectively only implements a run-time (rather than compile-time) 
        check and is generally seen as a somewhat depreated C++ idiom. Thanks
        to Darren Cook for alerting us to this issue.
    o   New example 'OpenMPandInline.r' in the OpenMP/ directory, showing how
        easily use OpenMP by modifying the RcppPlugin output
    o   New example 'ifelseLooped.r' showing Rcpp can accelerate loops that may
        be difficult to vectorise due to dependencies
    o   New example directory examples/Misc/ regrouping the new example as
        well as the fibonacci example added in Rcpp 0.9.6
    o   New Rcpp-FAQ example warning of lossy conversion from 64-bit long
        integer types into a 53-bit mantissa which has no clear fix yet.
    o   New unit test for accessing a non-exported function from a namespace
Thanks to CRANberries, you can also look at a diff to the previous release 0.9.6. 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

28 September 2011

Alejandro Rios P.: 2011 Colombian Mini-DebConf

This weekend we'll be having the 4th version of the Colombian Mini-Debconf. It will be held in the Otraparte Museum, in the city of Medellin. The cool thing this year is that we'll be having mostly Debian contributors than just users, with the kind participation of Anibal Monsalve, who is currently in the country.

There will be several 10-min lightening talks, followed by a key signing party and some actual work in packaging, and of course we'll be having some beers with Debian friends.

More info (in Spanish): http://wiki.debian.org/DebianColombia/MiniDebconf2011

27 September 2011

Sylvain Beucler: 3D OpenGL plotting

gnuplot? Here's the fourth tutorial from Guus on Scientific OpenGL, this time going 3D, plotting the "Mexican Hat" function, and covering various line drawing methods as well as Index Buffer Objects.
http://en.wikibooks.org/wiki/OpenGL_Programming/Scientific_OpenGL_Tutorial_04

Vincent Bernat: Speeding up SSL: enabling session reuse

Session reuse is one of the most important mechanism to improve SSL performance: by submitting an appropriate blob to the server, a client is able to trigger an abbreviated handshake, improving latency and computation time. There exists two distinct ways to achieve session reuse: session identifiers as described in RFC 5246 and session tickets as depicted in RFC 5077. A quick note: when I say SSL, unless I mention a version number, you should read TLS instead. Look at the article for TLS on Wikipedia for some background on this.

Theory of operation To establish a SSL connection, four messages need to be exchanged between client and server. With a latency of 50 ms, we have a 200 ms overhead to establish the connection (plus TCP handshake). Moreover, to share a common secret, both the client and the server needs to achieve some public-key cryptographic operations which are costly, computation-wise. SSL full handshake To avoid a full SSL handshake each time a client request a resource, it is possible for the client to request an abbreviated handshake, saving a complete round-trip (100 ms) and avoiding the costliest part of the full SSL handshake. SSL abbreviated handshake Two mechanisms can be used to accomplish an abbreviated handshake:
  1. When the server sends the Server Hello message, it can include a session identifier. The client should store it and present it in the Client Hello message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.
  2. In the last exchange of a full SSL handshake, the server can include a New Session Ticket message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.
The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty Session Ticket extension in the Client Hello message. The server will answer with an empty Session Ticket extension in its Server Hello message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL. RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in term of memory and difficult to share between multiple hosts when requests are load-balanced across servers.

Browser support Session identifiers are part of SSL and are therefore supported since a long time by clients and servers. However, session tickets are an optional TLS extension and therefore, the support is not as widespread as for session identifiers. Support for tickets was added in OpenSSL 0.9.8f (October 2007). In GnuTLS, this is version 2.9.3 (August 2009). For NSS, the set of libraries behind most browsers, support of RFC 5077 is in version 3.12 (June 2008). Schannel, Microsoft implementation of TLS, does not currently supports tickets. To check if a browser supports session resume without and with tickets, I have written a web server listening to several ports with different configurations (session cache disabled or enabled, ticket support disabled or enabled). With the help of some Javascript, it is possible to interact with this server to determine what kind of session resume a browser support. Checking for browser support for session resume It is difficult to get extensive results this way since you need to install a lot of browsers to get something valuable. Surprisingly, Android 2.3.4 browser (as shipped by Cyanogen Mod) does not support any session resume. Another way to check if a browser supports session resume is to use a sniffer and to spot Client Hello messages. If a client tries to resume a session, it will use an appropriate session identifier or send a ticket. A simple program parsing PCAP files allows to automate this task and get some interesting statistics. Here are random facts from more than 300 000 requests (38 000 clients) to a customer care service of an important French telco:
  • 35% of requests exhibit support of tickets;
  • 53.3% of requests ask to resume without tickets; 25.6% with tickets;
  • 67.2% of requests exhibit support of SNI;
  • 86.7% of requests use TLS 1.0; the remaining uses SSL 3.0; almost no TLS 1.1/1.2;
  • in average, a client execute 8 SSL handshakes;
  • ciphers supported by all clients are 3DES-SHA, RC4-MD5 and RC4-SHA.
With some log analysis to match each requests with the appropriate user agent, we can split the world in two parts: browsers supporting RFC 5077 (Chrome and Firefox) and browsers not supporting RFC 5077 (Internet Explorer, Opera 9.80, Safari for MacOS and iOS and Android browser).

Web server support There is no unique recipe to configure a web server to handle appropriately and efficiently session resume. Here are some generic directions :
  • if the web server uses multiple processes, you need to configure a shared memory session cache; usually, tickets will work just fine in this setup;
  • if you use local load-balancing, one easy way to avoid any problem is to use ensure that one IP is mapped to one server (either statically with hashing or dynamically with a stick table); if your load-balancer understands SSL, you can also use session identifier (and disable tickets1) to build a stick table;
  • if you don t want to apply the previous advice, you need to share the session cache between the servers with something like memcached and disable tickets;
  • if you use global load-balancing (DNS based), there is no need to ensure that session resumption works across geographic pools since a user will usually stick to one pool.
Remember that only one client out of three supports TLS tickets. Therefore, you cannot rely on them to ensure proper session resume. You need a session cache.

Setting a session cache with Apache & nginx Apache features two different SSL engines. The first one is mod_ssl and uses OpenSSL as backend. It is possible to setup a shared session cache with SSLSessionCache but the memcached-enabled session cache is available only in the development branch. You can also get one by switching to mod_gnutls backend. The cache is enabled with GnuTLSCache. In this case, do not enable tickets because they cannot be shared. With nginx, you need to enable the shared session cache with ssl_session_cache. Currently, it lacks a memcached-enabled session cache but Matt Palmer has some patches to add it to the 0.8 branch. However, those patches can have a serious impact on nginx performance since retrieving a session from memcached is done synchronously (mostly because a limitation in OpenSSL design who does not allow to register asynchronous callbacks with SSL_CTX_sess_set_get_cb()). As a proof of concept, I have also added a similar feature to stud, the scalable TLS unwrapping daemon, a very efficient network proxy terminating SSL connections. The same limitation as for nginx applies: performances will suffer. Look at the pull request for more details.

Sharing tickets RFC 5077 tells tickets allow to load-balance requests across servers. However, to the best of my knowledge, there is currently no web server able to share tickets across a pool. Actually, when a server initializes its SSL stack, it will randomly generate some keys that will be used to protect and encrypt tickets. In OpenSSL, from ssl/ssl_lib.c:
    /* Setup RFC4507 ticket keys */
    if ((RAND_pseudo_bytes(ret->tlsext_tick_key_name, 16) <= 0)
              (RAND_bytes(ret->tlsext_tick_hmac_key, 16) <= 0)
              (RAND_bytes(ret->tlsext_tick_aes_key, 16) <= 0))
            ret->options  = SSL_OP_NO_TICKET;
Therefore, with a round-robin load-balanced pool of servers, tickets have to be disabled because servers would not accept tickets from neighbors. One way to solve this is to generate keys deterministically by hashing some common secret with the private key. I have implemented this approach for stud. Here is a simplified version (no error handling, no allocation) of the pull request for this feature:
    unsigned char keys[48];
    EVP_PKEY *pkey = grab_private_key();
    /* To get our key, we sign the seed with the private key */
    unsigned int siglen;
    unsigned char sign[LARGE_ENOUGH];
    EVP_MD_CTX mdctx;
    EVP_MD_CTX_init(&mdctx);
    EVP_SignInit(&mdctx, EVP_sha256());
    EVP_SignUpdate(&mdctx, some_secret, strlen(some_secret));
    EVP_SignFinal(&mdctx, sign, &siglen, pkey);
    /* And we keep only the first bytes. */
    memcpy(keys, sign, sizeof(keys));
    /* Tell OpenSSL to use those keys */
    SSL_CTX_set_tlsext_ticket_keys(ctx, keys, sizeof(keys));

Testing While tests can be done with just openssl s_client and openssl sess_id, testing all aspects can take a lot of time. For this purpose, I have written a client testing session resume with and without tickets. Here is a typical result: twitter.com RFC session resume The program will try to establish five consecutive SSL connections for each IP without and with tickets. For each IP, the last four SSL connections should always reuse the first SSL session. Here, Twitter web servers seem properly configured: for each IP, session resume is successful. Their web servers do not support tickets or they may have disabled it because they share the session cache between servers inside the same pool.

  1. RFC 5077 describes interactions between session identifiers and session tickets. When using tickets, the server should send back an empty session identifier. The client may present an empty session identifier or generate one. However, for all practical purposes, it seems that servers send back a non-empty session identifier and clients just stick to this identifier. Please, investigate if you want to use SSL session identifiers for load-balancing while keeping tickets enabled.

26 September 2011

Gunnar Wolf: e-voting: Something is brewing in Jalisco...

There's something brewing, moving in Jalisco (a state in Mexico's West, where our second largest city, Guadalajara, is located). And it seems we have an opportunity to participate, hopefully to be taken into account for the future. Ten days ago, I was contacted by phone by the staff of UDG Noticias, for an interview on the Universidad de Guadalajara radio station. The topic? Electronic voting. If you are interested in what I said there, you can get the interview from my webpage. I held some e-mail contact with the interviewer, and during the past few days, he sent me some links to notes in the La Jornada de Jalisco newspaper, and asked for my opinion on them: On September 23, a fellow UNAM researcher, C sar Astudillo, claims the experience in three municipalities in Jalisco prove that e-voting is viable in the state, and today (September 26), third generation of an electronic booth is appearingly invulnerable. Of course, I don't agree with the arguments presented (and I'll reproduce the mails I sent to UDG Noticias about it before my second interview just below They are in Spanish, though). However, what I liked here is that it does feel like a dialogue. Their successive texts seem to answer to my questioning. So, even though I cannot yet claim this is a real dialogue (it would be much better to be able to sit down face to face and have a fluid conversation), it feels very nice to actually be listened to from the other side! My answer to the first note:
El tema de las urnas electr nicas sigue dando de qu hablar por ac en Jalisco... nosotros en Medios UDG hemos presentado distintas voces como la del Dr. Gabriel Corona Armenta, que est a favor del voto electr nico, del Dr. Luis Antonio Sobrado, magistrado presidente del tribunal supremo de elecciones de Costa Rica, quien nos habl sobre los 20 MDD que les cuesta implementar el sistema por lo que no lo han logrado hasta el momento, pudimos hablar hasta argentina con Federico Heinz y su rotunda oposici n al voto electr nico y por supuesto la entrevista que le realizamos a usted. Sin embargo este d a La Jornada Jalisco publica la siguiente nota http://www.lajornadajalisco.com.mx/2011/09/23/index.php?section=politica... nos gustar a saber cu l es su punto de vista al respecto, quedo a la espera de su respuesta
Hola, Pues... Bueno, s que el IFE hizo un desarrollo muy interesante y bien hecho hace un par de a os, dise ando desde cero las urnas que propon an emplear, pero no se instrumentaron fuera de pilotos (por cuesti n de costos, hasta donde entiendo). Se me hace triste y peligroso que el IEPC de Jalisco est proponiendo, teniendo ese antecedente, la compra de tecnolog a prefabricada, y confiando en lo que les ofrece un proveedor. Se me hace bastante iluso, directamente, lo que propone el t tulo: comicios en tres municipios prueban la viabilidad del voto electr nico en todo el estado . Pong moslo en estos t rminos: El que no se caiga una choza de l mina con estructura de madera demuestra que podemos construir rascacielos de l mina con estructura de madera? Ahora, un par de p rrafos que me llaman la atenci n de lo que publica esta nota de La Jornada:
la propuesta de realizar la elecci n en todo el estado con urnas electr nicas que desea llevar a cabo el Instituto Electoral y de Participaci n Ciudadana (IEPC) es viable, pues los comicios realizados en tres municipios son pruebas suficientes para demostrar que la urna es fiable
y algunos p rrafos m s adelante,
Cu ntas experiencias m s se necesitan para saber si es confiable, 20, 30, no lo s (...) Pero cuando se tiene un diagn stico real, efectivo y serio de cu ndo t cnicamente procede, se puede tomar la decisi n
Como lo menciono en mi art culo... No podemos confundir a la ausencia de evidencia con la evidencia de ausencia. Esto es, que en un despliegue menor no haya habido irregulares no significa que no pueda haberlas. Que haya pa ses que operan 100% con urnas electr nicas no significa que sea el camino a seguir. Hay algunas -y no pocas- experiencias de fallas en diversos sentidos de urnas electr nicas, y eso demuestra que no puede haber confianza en las implementaciones. Aunque el equipo nos saliera gratis (que no es el caso), hay que invertir recursos en su resguardo y mantenimiento. Aunque se generara un rastro impreso verificado por el votante (que s lo ha sido el caso en una peque a fracci n de las estacione de votaci n), nada asegura que los resultados reportados por el equipo sean siempre consistentes con la realidad. El potencial para mal uso que ofrecen es demasiado. Saludos,
And to September 26th:
Disculpe que lo molestemos otra vez, pero este d a fue publicada otra nota m s sobre el tema de las Urnas electr nicas en Jalisco donde se asegura que la urna es invulnerable. http://www.lajornadajalisco.com.mx/2011/09/26/index.php?section=politica... nos podr a conceder unos minutos para hablar con usted, como la vez pasada, v a telef nica sobre el caso espec fico de Jalisco, en referencia a estas notas publicadas recientemente? si es posible podr a llamarle este d a a las 2 pm? Quedo a la espera de su respuesta agradeci ndole su ayuda, apreciamos mucho esta colaboraci n que est haciendo con nosotros
Hola, ( ) Respecto a esta nota: Nuevamente, ausencia de evidencia no es evidencia de ausencia. Se le permite a un peque o segmento de personas jugar con una m quina. Significa eso que fue una prueba completa, exhaustiva? No, s lo que ante un jugueteo casual no pudieron encontrar fallos obvios y graves. Un verdadero proceso que brindara confianza consistir a en (como lo hicieron en Brasil - Y resultaron vulnerables) convocar a la comunidad de expertos en seguridad en c mputo a hacer las pruebas que juzguen necesarias teniendo un nivel razonable de acceso al equipo. Adem s, la seguridad va m s all de modificar los resultados guardados. Un par de ejemplos que se me ocurren sin darle muchas vueltas:
  • Qu pasa si meto un chicle a la ranura lectora de tarjeta magn tica?
  • Qu pasa si golpeo alguna de las teclas lo suficiente para hacerla un poquito menos sensible sin destruirla por completo? (o, ya entrados en gastos, si la destruyo)
La negaci n de servicio es otro tipo de ataque con el cual tenemos que estar familiarizados. No s lo es posible modificar el sentido de la votaci n, sino que es muy f cil impedir que la poblaci n ejerza su derecho. Qu har an en este caso? Bueno, podr an caer de vuelta a votaci n sobre papel - Sobre hojas de un block, probablemente firmadas por cada uno de los funcionarios, por ejemplo. Pero si un atacante bloque la lectura de la tarjeta magn tica, que es necesaria para que el presidente de casilla la marque como cerrada, despoj de su voto a los usuarios. S , se tienen los votos impresos (que, francamente, me da mucho gusto ver que esta urna los maneja de esta manera). El conteo es posible, aunque un poco m s inc modo que en una votaci n tradicional (porque hay que revisar cu les son los que est n marcados como invalidados - no me queda muy claro c mo es el escenario del elector que vot por una opci n, se imprimi otra, y el resultado fue corregido y marcado como tal)... Pero es posible. Sin embargo, y para cerrar con esta respuesta: Si hacemos una corrida de prueba, en circunstancias controladas, obviamente no se notar n los much simos fallos que una urna electr nica puede introducir cuando los "chicos malos" son sus programadores. Podemos estar seguro que este marcador Atlas-Chivas-Cruz Azul tenga el mismo ndice de fiabilidad como una elecci n de candidatos reales, uno de los cuales puede haberle pagado a la empresa desarrolladora para manipular la elecci n? Y a n si el proceso fuera perfecto, indican aqu que est n _intentando_ licitar estas urnas (y nuevamente, si lo que menciona esta nota es cierto, son de las mejores urnas disponibles, y han atendido a muchos de los se alamientos - Qu bueno!)... Para qu ? Qu nos van a dar estas urnas, qu va a ganar la sociedad? Mayor rapidez? Despreciable - Media hora de ganancia. A cambio de cu nto dinero? Mayor confiabilidad? Me queda claro que no, siendo que no s lo somos cuatro trasnochados los que ponemos su sistema en duda, sino que sus mismos proponentes apuntan a la duda generalizada. La frase con la que cierra la nota se me hace digna para colgar un ep logo: "en ese futuro quiz no tan distante la corrupci n tambi n ocurre y sta se debe siempre al factor humano". Y el factor humano sigue ah . Las urnas electr nicas son programadas por personas, por personas falibles. Sin importar del lado que est n, recordar n la pol mica cuando se hizo p blico que la agregaci n de votos en el 2006 fue supervisada por la empresa Hildebrando, propiedad del cu ado del entonces candidato a la presidencia Felipe Calder n. Qu evita que caigamos en un escenario similar, pero ampliamente distribu do? Y aqu hay que referirnos a la sentencia de la Suprema Corte de Alemania: En dicho pa s, las votaciones electr nicas fueron declaradas anticonstitucionales porque s lo un grupo de especialistas podr an auditarlas. Una caja llena de papeles con la evidencia clara del sentido del voto de cada participante puede ser comprendida por cualquier ciudadano. El c digo que controla a las urnas electr nicas, s lo por un peque o porcentaje de la poblaci n.

Benjamin Mako Hill: Science as Dance

The following selected bibliography showcases only a small portion of the academics who have demonstrated that while it may take two to tango, it only takes one to give a scholarly paper a silly cliche title:
Briganti, G. 2006. It Takes Two to Tango-The CH-53K is arguably the first serious US attempt to open the defense cooperation NATO has been seeking. Rotor and Wing 40(7):60 63.
Coehran, J. 2006. It Takes Two to Tango: Problems with Community Property Ownership of Copyrights and Patents in Texas. Baylor L. Rev. 58:407.
Diamond, M.J. 1984. It takes two to tango: Some thoughts on the neglected importance of the hypnotist in an interactive hypnotherapeutic relationship. American Journal of Clinical Hypnosis 27(1):3 13.
Kraack, A. 1999. It takes two to tango: The place of women in the construction of hegemonic masculinity in a student pub. Masculinities in Aotearoa/New Zealand 153 165.
Lackey, J. 2006. It takes two to tango: beyond reductionism and non-reductionism in the epistemology of testimony. The Epistemology of testimony 160 89.
Miller, C.A. 1998. It takes two to tango: understanding and acquiring symmetrical verbs. Journal of psycholinguistic research 27(3):385 411.
Modiano, N. 1984. It Takes Two to Tango, or Transmission is a Two-Way Street. Anthropology & Education Quarterly 15(4):326 330.
Ott, M.A. 2008. It Takes Two to Tango: Ethical Issues Raised by the Study of Topical Microbicides with Adolescent Dyads. The Journal of adolescent health: official publication of the Society for Adolescent Medicine 42(6):541.
Rubenstein, J.H. 2009. It takes two to tango: dance steps for diagnosing Barrett s esophagus. Respiratory Care Clinics of North America 69(6):1011 1013.
Settersten Jr, R.A. 2009. It takes two to tango: the (un) easy dance between life-course sociology and life-span psychology. Advances in Life Course Research 14(1-2):74 81.
Skaerbaek, E. 2004. It takes two to tango on knowledge production and intersubjectivity. NORA: Nordic Journal of Women's Studies 12(2):93 101.
Spencer, M. 2005. It takes two to tango. Journal of Business Strategy 26(5):62 68.
Vanaerschot, G. 2004. It Takes Two to Tango: On Empathy With Fragile Processes. Psychotherapy: Theory, Research, Practice, Training 41(2):112.
Viskochil, D.H. 2003. It takes two to tango: mast cell and Schwann cell interactions in neurofibromas. Journal of Clinical Investigation 112(12):1791 1792.
Weiner, A. 2001. It Takes Two to Tango:: Information, Metabolism, and the Origins of Life. Cell 105(3):307 308.
Wittman, M.L. 1990. It Takes Two to Tango: Your Simplistic System for Self-survival. Witmark Pub. Co.
There are also a few hundred groups who have demonstrated that larger groups can so as well.

25 September 2011

Tanguy Ortolo: Increase your productivity with two spaces

Shell prompts are often designed to provide a reminder of useful context information such user name, host and current directory:
PS1="\u@\h:\w\$"
tanguy@muscat:~/public_html$
Such a prompt is sufficient to serve its original purpose, but it can be enhances in at least one useful way. Sometimes you have to copy the path of the current directory: with this prompt, it means selecting it by precisely dragging the mouse over it. Well, by adding spaces around the current directory you can become able to select it with a simple double click:
PS1="\u@\h: \w \$"
tanguy@muscat: ~/public_html $
Indeed, with such a prompt, you can now roughly point to the path, double click, and let your terminal emulator's word detection feature select the whole path for you. This simple modification may save you several tenths of seconds!

23 September 2011

Matthew Garrett: Supporting UEFI secure boot on Linux: the details

An obvious question is why Linux doesn't support UEFI secure booting. Let's ignore the issues of key distribution and the GPL and all of those things, and instead just focus on what would be required. There's two components - the signed binary and the authenticated variables.

The UEFI 2.3.1 spec describes the modification to the binary format required to produce a signed binary. It's not especially difficult - you add an extra entry to the image directory, generate a hash of the entire binary other than the checksum, the certificate directory entry and the signatures themselves, encrypt that hash with your key and embed the encrypted hash in the binary. The problem has been that there was a disagreement between Microsoft and Intel over whether this signature was supposed to include the PKCS header or not, and until earlier this week the only widely available developer firmware (Intel's) was incompatible with the only widely available signed OS (Microsoft's). There's further hilarity in that the specification lists six supported hash algorithms, but the implementations will only accept two. So pretty normal, really. Developing towards a poorly defined target is a pain. Now that there's more clarity we'll probably have a signing tool before too long.

Authenticated variables are the other part of the puzzle. If a variable requires authentication, the operating system's attempt to write it will fail unless the new data is appropriately signed. The key databases (white and blacklists) are examples of authenticated variables. The signing actually takes place in userspace, and the handoff between the kernel and firmware is identical for both this case and the unauthenticated case. The only problem in Linux's support here is that our EFI variable support was written to a pre-1.0 version of the EFI specification which stated that variables had a maximum size of 1024 bytes, and this limitation ended up exposed to userspace. So all we really need to do there is add a new interface to let arbitrary sized variables be written.

Summary: We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.

comment count unavailable comments

22 September 2011

Christian Perrier: 3rd update about Debian Installer localization

Yet another progress report about D-I l10n. Full stats are here Status for D-I level 1 (core D-I files): New complete languages since last update: Esperanto, Spanish, Tamil, Simplified Chinese. Status for D-I level 2 (packages that have localized material that may appear during default installs, such as iso-codes, tasksel, etc.): Status for D-I level 3 (packages that have localized material that may appear during non-default installs, such as win32-loader)

20 September 2011

MJ Ray: Six of the Best Podcasts?

I m listening to quite a few podcasts recently. Here are my current favourites: And now for number six, what are you listening to? Anything you d recommend?

19 September 2011

Joey Hess: happy haskell hacker

There are certian things haskell is very good at, and I had the pleasure of using it for one such thing yesterday. I wanted to support expressions like find(1) does, in git-annex. Something like:
git-annex drop --not --exclude '*.mp3' --and \
    -\( --in usbdrive --or --in archive -\) --and \
    --not --copies 3
So, parens and booleans and some kind of domain-specific operations. It's easy to build a data structure in haskell that can contain this sort of expression.
 - A Token can either be a single word, or an Operation of an arbitrary type. - 
data Token op = Token String   Operation op
        deriving (Show, Eq)
data Matcher op = Any
          And (Matcher op) (Matcher op)
          Or (Matcher op) (Matcher op)
          Not (Matcher op)
          Op op
        deriving (Show, Eq)
(The op could just be a String, but is parameterized for reasons we'll see later.) As command-line options, the expression is already tokenised, so all I needed to do to parse it is consume a list of the Tokens. The only mildly tricky thing is handling the parens right -- I chose to not make it worry if there were too many, or too few closing parens.
generate :: [Token op] -> Matcher op
generate ts = generate' Any ts
generate' :: Matcher op -> [Token op] -> Matcher op
generate' m [] = m
generate' m ts = uncurry generate' $ consume m ts
consume :: Matcher op -> [Token op] -> (Matcher op, [Token op])
consume m [] = (m, [])
consume m ((Operation o):ts) = (m  And  Op o, ts)
consume m ((Token t):ts)
          t == "and" = cont $ m  And  next
          t == "or" = cont $ m  Or  next
          t == "not" = cont $ m  And  (Not next)
          t == "(" = let (n, r) = consume next rest in (m  And  n, r)
          t == ")" = (m, ts)
          otherwise = error $ "unknown token " ++ t
        where
                (next, rest) = consume Any ts
                cont v = (v, rest)
Once a Matcher is built, it can be used to check if things match the expression the user supplied. This next bit of code almost writes itself.
 - Checks if a Matcher matches, using a supplied function to check
 - the value of Operations. - 
match :: (op -> v -> Bool) -> Matcher op -> v -> Bool
match a m v = go m
        where
                go Any = True
                go (And m1 m2) = go m1 && go m2
                go (Or m1 m2) = go m1   go m2
                go (Not m1) = not (go m1)
                go (Op o) = a o v
And that's it! This is all nearly completly generic and could be used for a great many things that need support for this sort of expression, as long as they can be checked in pure code. A trivial example:
*Utility.Matcher> let m = generate [Operation True, Token "and", Token "(", Operation False, Token "or", Token, "not", Operation False, Token ")"]
*Utility.Matcher> match (const . id) m undefined 
True
For my case though, I needed to run some IO actions to check if expressions about files were true. This is where I was very pleased to see a monadic version of match could easily be built.
 - Runs a monadic Matcher, where Operations are actions in the monad. - 
matchM :: Monad m => Matcher (v -> m Bool) -> v -> m Bool
matchM m v = go m
        where
                go Any = return True
                go (And m1 m2) = liftM2 (&&) (go m1) (go m2)
                go (Or m1 m2) =  liftM2 ( ) (go m1) (go m2)
                go (Not m1) = liftM not (go m1)
                go (Op o) = o v
With this and about 100 lines of code to implement specific tests like --copies and --in, git-annex now supports the example at the top. Just for comparison, find(1) has thousands of lines of C code to build a similar parse tree from the command line parameters and run it. Although I was surprised to see that it optimises expressions by eg, reordering cheaper tests first. The last time I wrote this kind of thing was in perl, and there the natural way was to carefully translate the expression into perl code, which was then evaled. Meaning the code was susceptible to security holes. Anyway, this is nothing that has not been done a hundred times in haskell before, but it's very nice that it makes it so clean, easy, and generic.

Sylvain Beucler: Building Android NDK samples

I searched forever for a way to just build the examples in the Android NDK, preferably from the command line. Here's how. First step: build the C++ code:
cd /usr/src/android-ndk-r6/samples/san-angeles/
/usr/src/android-ndk-r6/ndk-build
Simple enough. Second step:
You will then need to generate your final .apk through the usual means. -- Android NDK Dev Guide
Thanks a ****ing lot! In addition the documentation is very much Eclipse-centered - and I can't be bothered to install and configure all the Eclipse stack for a mere Java wrapper for the above-generated .so file XD We first need to use the 'android' wrapper and download the "SDK Platform Android 2.2, API 8, revision 3" - aka "android-8", the first environment to support OpenGL ES 2.
/usr/src/android-sdk-linux_x86/tools/android
It appears we first need to "manage the project", more precisely import from an existing project: http://developer.android.com/guide/developing/projects/projects-cmdline.html So we create a project by importing the sources from the current directory:
/usr/src/android-sdk-linux_x86/tools/android update project \
  --name san-angeles --path . --target "android-8"
Then we use ant to build the thing: http://developer.android.com/guide/developing/building/building-cmdline.html
apt-get install ant openjdk-6-jdk
ant debug  # avoid messing with signing
We now have a bin/san-angeles-debug.apk and we can run it in the emulator. Create a new "Virtual device" using the "android-8" platform we downloaded above, and launch it. Given the time needed to boot the OS, I suggest enabling snapshots. Scaling to display resulted in a very tiny, dark and slow display, in a first step I suggest using a non-scaled one.
/usr/src/android-sdk-linux_x86/tools/android
At last we can run it! Install it in the emulator:
/usr/src/android-sdk-linux_x86/platform-tools/adb install -r bin/san-angeles-debug.apk
You'll find a DemoActivity in your apps directory :)
Note: I tried to compile the "hello-gl2", showcasing OpenGL ES 2.0, but sadly it crashes:
Sorry! The application GL2JNI (process com.android.gl2jni) has stopped unexpectedly. Please try again.
The emulator apparently doesn't advertise EGL_OPENGL_ES2_BIT (checked in in GL2JNIView.java). If you try to by-pass it, you'll get loads of:
E/libEGL ( 333): called unimplemented OpenGL ES API
It's worth noting the OpenGLES20 sample from the "API Demos" application uses a fall-back OpenGL ES 1 renderer if v2 is not available - it made me mistakenly believe that OpenGL ES 2 was supported only from Java >( OpenGL ES 2 is not supported in the emulator as of 2011-09-17 - period.

18 September 2011

Philipp Kern: python-gnucash, historic build stats

Two tiny bits:

Next.

Previous.