Search Results: "nate"

8 November 2015

Andrew Cater: MiniDebconf Cambridge - ARM, Cambridge 1115 8 November

Just had a really good couple of sessions: one from the DPL including Q&A, then a good overview of reproducible builds and where we are today from Holger Levsen (h0lger) and Chris Lamb (lamby)

Then a 2 minute silence at 11.00 as is customary in the UK on this date.

Now Lucy Wayland - who says she has a brainful of IEEE754 from a few years ago working on safety-critical systems so she's unburdening by sharing with all of us - everything you wanted to know about floating point but were afraid to ask (and including a primer on signed/unsigned and fixed point as part of the explanation)

Steve Capper's Java presentation is unfortunately not going to take place, so this afternoon's live stream schedule will be different.

Coffee going down well.

Daniel Pocock: Problems observed during Cambridge mini-DebConf RTC demo

A few problems were observed during the demo of RTC services at the Cambridge mini-DebConf yesterday. As it turns out, many of them are already documented and solutions are available for some of them. Multiple concurrent SIP registrations I had made some test calls on Friday using rtc.debian.org and I still had the site open in another tab in another browser window. When people tried to call me during the demo, both tabs were actually ringing but only one was visible. When a SIP client registers, the SIP registration server sends it a list of all other concurrent registrations in the response message. We simply need to extend JSCommunicator to inspect the response message and give some visual feedback about other concurrent registrations. Issue #69. SIP also provides a mechanism to clear concurrent registrations and that could be made available with a button or configuration option too (Issue #9). Callee hears ringing before connectivity checks completed The second issue during the WebRTC demo was that the callee (myself) was alerted about the call before the ICE checks had been performed. The optimal procedure to provide a slick user experience is to run the connectivity checks before alerting the callee. If the connectivity checks fail, the callee should never be alerted with a ringing sound and would never know somebody had tried to call. The caller would be told that the call was unable to be attempted and encouraged to consider trying again on another wifi network. RFC 5245 recommends that connectivity checks should be done first but it is not mandatory. One reason this is problematic with WebRTC is the need to display the pop-up asking the user for permission to share their microphone and webcam: the popup must appear before connectivity checks can commence. This has been discussed in the JsSIP issue tracker. Non-WebRTC softphones, such as Lumicall, do the connectivity checks before alerting the callee. Dealing with UDP blocking It appears the corporate wifi network in the venue was blocking the UDP packets so the connectivity checks could never complete, not even using a TURN server to relay the packets. People trying to use the service on home wifi networks, in small offices and mobile tethering should not have this problem as these services generally permit UDP by default. Some corporate networks, student accommodation and wifi networks in some larger hotels have blocked UDP and in these cases, additional effort must be made to get through the firewall. The TURN server we are running for rtc.debian.org also supports a TLS transport but it simply isn't configured yet. At the time we originally launched the WebRTC service in 2013, the browsers didn't support TURN over TLS at all but now they do. This is probably the biggest problem encountered during the demo but it does not require any code change to resolve this, just configuration, so a solution is well within reach. During the demo, we worked around the issue by turning off the wifi on my laptop and using tethering with a 4G mobile network. All the calls made successfully during the demo used the tethering solution. Add a connectivity check timeout The ICE connectivity checks appeared to keep running for a long time. Usually, if UDP is not blocked, the ICE checks would complete in less than two seconds. Therefore, the JavaScript needs to set a timeout between two and five seconds when it starts the checks and give the user a helpful warning about their network problems if the timeout is exceeded. Issue #73 in JSCommunicator. While these lengthy connectivity checks appear disappointing, it is worth remembering that this is an improvement over the first generation of softphones: none of them made these checks at all, they would simply tell the user the call had been answered but audio and video would only be working in one direction or not at all. Microphone issues One of the users calling into the demo, Juliana, was visible on the screen but we couldn't hear her. This was a local audio hardware issue with her laptop or headset. It would be useful if the JavaScript could provide visual feedback when it detects a voice (issue #74) and even better, integrating with the sound settings so that the user can see if the microphone is muted or the gain is very low (issue #75). Thanks to participants in the demo I'd like to thank all the participants in the demo, including Juliana Louback who called us from New York, Laura Arjona who called us from Madrid, Daniel Silverstone who called from about three meters away in the front row and Iain Learmonth who helped co-ordinate the test calls over IRC. Thanks are also due to Steve McIntyre, the local Debian community, ARM and the other sponsors for making another mini-DebConf in the UK this year.

7 November 2015

Stig Sandbeck Mathisen: Let's Encrypt with Hitch and Varnish

Let's Encrypt is now in beta. Here's how to use the automated CA with Hitch TLS proxy, and Varnish HTTP accelerator as a backend for Hitch.
Let's Encrypt Let's Encrypt is a free, automated and open Certificate Authority (CA), run for the public's benefit.
Varnish Varnish is a HTTP accelerator. I use it as a web server, and it serves content from various backends. Varnish is used on a lot of high-traffic web servers, and supports simple and complex web site configurations.
Hitch Hitch is a TLS proxy, by Varnish Software. It terminates TLS connections, and forwards them to a backend, unencrypted. The TLS proxy is simple to configure, and handles many thousands of requests per second on commodity hardware. Hitch was originally called stud and was written by Jamie Turner at Bump.com.
Varnish plugin for Let's Encrypt Let's Encrypt Varnish Plugin is needed for the Let's Encrypt client to authenticate against their service, for getting the certificates. You can skip this if you have the option of temporarily disabling your web service, when registering and renewing your certificates.
Hitch TLS proxy Hitch must be configured to listen on the https port (TCP/443), with a list of strong ciphers. To get Forward Secrecy, we need ciphers with EECDH or EDH. To use these, we need to generate a set of DH Parameters. In /etc/hitch/hitch.conf: 
      
# Listening
frontend = "[*]:443"
ciphers  = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
Varnish as backend for Hitch Hitch will forward traffic to Varnish on localhost:6082, using the PROXY protocol. Here's a snippet for /etc/hitch/hitch.conf to do this: 
      
# Send traffic to the varnish backend
backend        = "[::1]:6086"
write-proxy-v2 = on
For varnish, I've added a separate port for the "PROXY" protocol, by adding an extra "-a" argument for port 6086. The -a :80 handles the existing http traffic, while the -a '[::1]:6086,PROXY' adds a listener on localhost, which will be used by hitch. 
      
/usr/sbin/varnishd -j unix,user=vcache -a :80 -a '[::1]:6086,PROXY' ...
Let's Encrypt install letsencrypt First, install the letsencrypt client. The beta program sends you a mail with instructions. When it is generally available, I suspect it'll be something like: 
      
apt install letsencrypt
install varnish plugin Then, get the let's encrypt varnish plugin. The plugin will extend the letsencrypt software to be able to rewrite the VCL and reload Varnish to satisfy the authentication challenge of the Let's Encrypt server. 
      
cd /usr/local/src
git clone http://git.sesse.net/letsencrypt-varnish-plugin
. ~/.local/share/letsencrypt/bin/activate
pip install -e /usr/local/src/letsencrypt-varnish-plugin
get certificate Get certificates. Let's Encrypt is still in beta, so I had to add a few more command line arguments than the documentation specifies: 
      
~/.local/share/letsencrypt/bin/letsencrypt --agree-dev-preview \
    --server https://acme-v01.api.letsencrypt.org/directory \
    -a letsencrypt-varnish-plugin:varnish -d example.org certonly
Adding certificates to Hitch Hitch requires one PEM file per domain we serve. Each .pem file contains the private key, the signed certificate and any required intermediates. Create a file with DH parameters: 
      
openssl dhparam -out /etc/hitch/dhparam.pem 2048
This file may take a long while to generate. Combine the key, the signed certificate, and the dhparam file to something hitch can use: 
      
cat \
    /etc/letsencrypt/live/example.org/privkey.pem \
    /etc/letsencrypt/live/example.org/fullchain.pem \
    /etc/hitch/dhparam.pem \
    > /etc/hitch/example.org.pem
chmod 0600 /etc/hitch/example.org.pem
and configure hitch to use the file, by adding it to /etc/hitch/hitch.conf: 
      
# List of PEM files, each with key, certificates and dhparams
pem-file = "/etc/hitch/example.org.pem"
pem-file = "/etc/hitch/www.example.org.pem"
pem-file = "/etc/hitch/example.com.pem"
pem-file = "/etc/hitch/www.example.com.pem"

6 November 2015

Matthew Garrett: Why improving kernel security is important

The Washington Post published an article today which describes the ongoing tension between the security community and Linux kernel developers. This has been roundly denounced as FUD, with Rob Graham going so far as to claim that nobody ever attacks the kernel.

Unfortunately he's entirely and demonstrably wrong, it's not FUD and the state of security in the kernel is currently far short of where it should be.

An example. Recent versions of Android use SELinux to confine applications. Even if you have full control over an application running on Android, the SELinux rules make it very difficult to do anything especially user-hostile. Hacking Team, the GPL-violating Italian company who sells surveillance software to human rights abusers, found that this impeded their ability to drop their spyware onto targets' devices. So they took advantage of the fact that many Android devices shipped a kernel with a flawed copy_from_user() implementation that allowed them to copy arbitrary userspace data over arbitrary kernel code, thus allowing them to disable SELinux.

If we could trust userspace applications, we wouldn't need SELinux. But we assume that userspace code may be buggy, misconfigured or actively hostile, and we use technologies such as SELinux or AppArmor to restrict its behaviour. There's simply too much userspace code for us to guarantee that it's all correct, so we do our best to prevent it from doing harm anyway.

This is significantly less true in the kernel. The model up until now has largely been "Fix security bugs as we find them", an approach that fails on two levels:

1) Once we find them and fix them, there's still a window between the fixed version being available and it actually being deployed
2) The forces of good may not be the first ones to find them

This reactive approach is fine for a world where it's possible to push out software updates without having to perform extensive testing first, a world where the only people hunting for interesting kernel vulnerabilities are nice people. This isn't that world, and this approach isn't fine.

Just as features like SELinux allow us to reduce the harm that can occur if a new userspace vulnerability is found, we can add features to the kernel that make it more difficult (or impossible) for attackers to turn a kernel bug into an exploitable vulnerability. The number of people using Linux systems is increasing every day, and many of these users depend on the security of these systems in critical ways. It's vital that we do what we can to avoid their trust being misplaced.

Many useful mitigation features already exist in the Grsecurity patchset, but a combination of technical disagreements around certain features, personality conflicts and an apparent lack of enthusiasm on the side of upstream kernel developers has resulted in almost none of it landing in the kernels that most people use. Kees Cook has proposed a new project to start making a more concerted effort to migrate components of Grsecurity to upstream. If you rely on the kernel being a secure component, either because you ship a product based on it or because you use it yourself, you should probably be doing what you can to support this.

Microsoft received entirely justifiable criticism for the terrible state of security on their platform. They responded by introducing cutting-edge security features across the OS, including the kernel. Accusing anyone who says we need to do the same of spreading FUD is risking free software being sidelined in favour of proprietary software providing more real-world security. That doesn't seem like a good outcome.

comment count unavailable comments

Norbert Preining: Japanese TeX User Meeting Support for Japanese in TeX (Live) present state and future?

Tomorrow the Japanese TeX User Meeting 2015 will be held in Tokyo. Since I have come to Japan I have attended more or less every year this meeting, and in 2013 we could get the (international) TeX User Group Meeting to Tokyo and had a joint conference TUG 2013, which was a great success. (update 2015-11-09: slides added at the end) Japanese-TeX
During tomorrows meeting I will give a talk on Support for Japanese in TeX (Live) present state and future?:
The support for typesetting Japanese in TeX, in particular TeX Live, has been improved over the last few years considerably, so that at the current point we can ask ourselves what is next? This talk reviews a bit of the history of Japanese typesetting support in TeX Live, and discusses future development directions.
For those interested, here is a bit of an extended abstract. With a set of Japan specific TeX engines, the Japanese TeX Users always had a hard time setting up a proper TeX environment. Besides compiling the programs for each new version again, users had to install packages from a variety of sources, which often involved complicated routines. Fortunately, due to the excellent support on the TeX Q&A these difficulties were manageable. Compiling the Japanese TeX engines was first part of the pteTeX project, which adjusted teTeX to include also the required programs. Compilation was done by obtaining the source code of teTeX, plus patches that implement the Japanese TeX engines and support in driver programs. After the end of development of teTeX, TeX Live became the main TeX distribution system, and ptexlive was born to adjust the TeX Live sources to include the Japanese TeX engines. But fundamentally the same procedure remain: Get the source code, patch in additional functionality, compile and install. The last five years have seen a step-wise inclusion of various Japan-related programs in the main TeX Live source repository. Starting with pTeX (and pbibtex etc) and adjustments to dvipdfmx, followed by upTeX, and later on also (u)pmetapost, the main TeX Live source repository now contains all (with the exception of pxdvi) programs related to the Japanese TeX environment. At the same time, developers of various packages started to upload their packages to CTAN, which automatically made these packages available in TeX Live. Thus, the current status is quite satisfactory, since a normal TeX Live installation, without the need for any compilation, provides all necessary programs and packages. What remains a problem are inter-release updates of the binaries, when bugs in various engines are found. Future developments Besides the actual development of packages, and in particular luatexja, I see possible improvements in the following area: Summing up, I am quite happy to see that both the Japanese community, as well as the Korean community, have now taken the step to make their achievements available in an easy and straightforward way for everyone using TeX Live, and I am sure that the future will bring further improvements!
The slides accompanying the talk can be downloaded here: texconf15-texlive-japan.pdf. I also talked briefly on CJK font integration for Ghostscript, these slides can be downloaded here: texconf15-cjk-gs.pdf.

5 November 2015

Gunnar Wolf: WTF @omarfayad Should *all* computer activity be illegal now? #LeyFayad

Last week, Senator Omar Fayad presented one of the prime examples of a poorly redacted law that, if enacted, will make basically any way of computer use illegal. And yes, even if he states this is merely a draft, it has so many factual and conceptual errors that there is no way to trust sanity can be regained at any point. Oh, and before I continue with this rant: If the topic interests you, I suggest you to read the 10 key points about Ley Fayad, the worst Internet initiative in history, published by r3d.mx. [update] An English equivalent of the work at r3d, at revolution-news.com: #LeyFayad: The Worst Bill in Internet History The full text (in Spanish, of course) for the law initiative is available at the Senate webpage; the law will be called Ley Federal para Prevenir y Sancionar los Delitos Inform ticos (Federal law to prevent and punish informatic felonies<) A bad name to start with, as there are many laws already in that contested area. I started reading with the preamble (Exposici n de motivos), which already shows bad signs of imprecise redaction and is plagued with factual errors (i.e. asserting that the real danger stems from the Web migrating to the Web 2.0, from which stems that this migration and not any previous one. Or by stating that (quoting+translating a full paragraph):
Activities such as electronic commerce, digital periodism, publicity and the opinions, messages or elements written in social networks can lead to patrimonial, reputation, honor or professional activity losses for people.
He continues by stating that only 16% of the countries have some kind of cybersecurity strategy (and, of course, Mexico doesn't). That... Well, is very hard to believe, as Mexico has two separate policial groups devoted to cybersecurity, and laws regulating from electronic signatures, commerce, identity, privacy, use and abuse, and a long list. Of course, as most law proposals go, it quickly decays into a dry, boring document... And I must admit I didn't fully read it, but picked here and there. I won't copy in full the note I mentioned at the beginning at r3d.mx, but will continue with some strange points, such as:
Article 16
Every person that, without the corresponding authorization or exceeding the authorization confered, accesses, intercepts, interfers or uses an information system, will be punished by one to eight years of prision and fined by 800 to 1000 days of minimum wage
So, yes, borrowing your computer without getting explicit permission, or playing around with the options in kiosks, or tons of whatever we curious people do with systems we encounter are basis for jail. (And yes, fines in this country are expressed in "days of minimum wage", which goes at ~MX$70 per day, which is ~US$4). But it gets funkier quickly:
Article 17
Whoever fraudulently destroys, disables, damages or in any way alters the working of an informatic system or any of its components, will be punished by fice to fifteen years of jail and fined by up to a thousand minimum wage days The same punishment will be given to whoever, without authorization, destroys, damages, modifies, divulges, transfers or disables information contained in any Informatic System or any of its components. The punishment will be ten to twenty years in prision and a fine of up to a thousand days of minimum wage if the effects here mentioned are done by the creation, introduction or fraudulent transmission, by any means, of an informatic weapon or malicious code
This law is meant to protect against cyberfelonies, if such a thing exists. However, here we are putting at risk people even for accidental equipment destructions. I dropped your portable hard disk with my elbow off the table? Accuse me of acting fraudulently, and I'm up for a serious jail time. And yes, laws are meant to be interpreted... And I don't want to be at the receiving end of this one! In this last article, Fayad mentions informatic weapons, which are defined in the preamble as any informatic program, informatic system, or in general, any device or material created or designed with the purpose of committing an informatic crime. So the very next article makes me, as it should make all of my fellow students and researchers, very uneasy:
Article 18
Whoever uses informatic weapons or malicious code will be imprisioned by two to six years, and fined with 200 to 500 days of minimum wage.
Article 19
Whoever builds, distributes, commerces with informatic weapons or malicious codes will be punished by three to seven years of prision and 200 to 500 days of minimum wage.
If we need to analyze malware for our classes (or for paid work, or as a hobby), we clearly fall in article 18. If we write something that can be classified as malware (without even releasing it, as an academic excercise only!), we are covered by article 19. If I give my students code that's known to be malicious (which could be as inofensive as linking to a well-known Web comic), I'm also covered by article 19. I'll jump all the way to article 31 (reproduced only partially):
Article 31
Whoever, by any means, creates, captures, records, copies, alters, duplicates, clones or deletes the information contained in a credit or debit card (...) will be punished by 8 to 14 years of prision and 300 to 500 days of minimum wage. (...)
This clearly disincentivates any way of e-commerce. When I try to buy anything online, I have to capture+copy my (rightfully owned) credit card data. The services provider has to copy, process and then delete said information. Any e-transaction is punished by jail! Well... But thinking about this again, maybe I shouldn't be so worried about the malware distribution issue at my classes. There are clearer and more contundent articles. Say...
Article 35
Whoever convenes, organizes, is part of, or executes a cibernetic attack, will be punished by 20 to 30 years of prision and fined with 100 to 1000 days of minimum wage
Of course we have convened, organized, been part of and executed cibernetic attacks at the computer security lab at ESIME. Why would there be such a lab otherwise? Then, there are clear indications that the Senator didn't understand the topic his team was working on:
Article 37
Who manipulates the digital seals used by command of the public authority will be punished with 240 days of community work
Now... What is a digital seal? It's not a phisical one that does not allow opening the doors to a business found at fault, but something that just proves a document is legitimate and pristine. How can I manipulate them? Of course, if the seals are MD5-based, I can easily forge them (and SHA1-based, it seems they will be broken enough soon to be considered no longer trustable)... But that's about it! And there is more, lots more. I'm swamped with work, and have to get back to it. But chapters the following chapters have a lot of potential for finding holes. PS - And yes, the only use I do of Twitter is via the headlines in my blog ;-) [update] Ley Fayad is dead, yay! \o/ The senator withdrew the proposal.

4 November 2015

Rapha&#235;l Hertzog: My Free Software Activities in October 2015

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS This month I have been paid to work 13.25 hours on Debian LTS. During this time I worked on the following things: I also started a conversation about what paid contributors could work on if they have some spare cycle as the current funding level might allow us to invest some time on work outside of just plain security updates. The Debian Administrator s Handbook I spent quite some time finalizing the Jessie book update, both for the content and for the layout of the printed book. Debian Handbook: cover of the jessie edition Misc Debian work GNOME 3.18. I uploaded a new gnome-shell-timer working with GNOME Shell 3.18 and I filed bugs #800660 and #802480 about an annoying gnome-keyring regression I did multiple test rounds with the Debian maintainers (Dmitry Shachnev, kudos to him!) and the upstream developers (see here and here). Apart from those regressions, I like GNOME 3.18! Python-modules team migration to Git. After the Git migration, and since the team policy now imposes usage of git-dpm on all members, I made some tries with it on the python-django package while pushing version 1.8.5 to experimental. And the least I can say is that I m not pleased with the result. I thus filed 3 bugs summarizing the problems I have with git-dpm: #801666 (no way to set the upstream branch names from within the repository), #801667 (no clean way to merge between packaging branches), #801668 (does not create upstream tag immediately on tarball import). That is on top of other randomly stupid bugs that were already reported like #801548 (does not work with perfectly valid pre-existing upstream tags). Django packaging. I filed bugs on all packages build-depending on python-django that fail to build with Django 1.8 and informed them that I would upload Django 1.8 to unstable in early November (it s done already). Then I fixed python-django-jsonfield myself since Distro Tracker relies on this package. Following this small mass-bug filing, I filed a wishlist bug on devscripts to improve the mass-bug helper script (see #801926). And since I used ratt to rebuild the packages, I filed a wishlist issue on this new tool as well. Tryton 3.6 upgrade. I upgraded my own Tryton installation to version 3.6 and filed bug #803066 because the SysV init script was not working properly. That also reminded me that the DD process of Matthias Behrle (the tryton package maintainer) was stalled due to a bug in the NM infrastructure so I pinged the NM team and we sorted out a way for me to advocate him and get his process going Distro Tracker. I continued my work to refactor the way we handle incoming mail processing (branch people/hertzog/mailprocessing). It s now mostly finished and I need to deploy it in a test environment before being able to roll it out on tracker.debian.org. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Johannes Schauer: Let's Encrypt with Pound on Debian

TLDR: mister-muffin.de (and all its subdomains), bootstrap.debian.net and binarycontrol.debian.net are now finally signed by "Let's Encrypt Authority X1" \o/ I just tried out the letsencrypt client Debian packages prepared by Harlan Lieberman-Berg which can be found here: My server setup uses Pound as a reverse proxy in front of a number of LXC based containers running the actual services. Furthermore, letsencrypt only supports Nginx and Apache for now, so I had to manually setup things anyways. Here is how. After installing the Debian packages I built from above git repositories, I ran the following commands: 
$ mkdir -p letsencrypt/etc letsencrypt/lib letsencrypt/log
$ letsencrypt certonly --authenticator manual --agree-dev-preview \
    --server https://acme-v01.api.letsencrypt.org/directory --text \
    --config-dir letsencrypt/etc --logs-dir letsencrypt/log \
    --work-dir letsencrypt/lib --email josch@mister-muffin.de \
    --domains mister-muffin.de --domains blog.mister-muffin.de \
    --domains [...]
I created the letsencrypt directory structure to be able to run letsencrypt as a normal user. Otherwise, running this command would require access to /etc/letsencrypt and others. Having to set this up and pass all these parameters is a bit bothersome but there is an upstream issue about making this easier when using the "certonly" option which in princible should not require superuser privileges. The --server option is necessary for now because "Let's Encrypt" is still in beta and one needs to register for it. Without the --server option one will get an untrusted certificate from the "happy hacker fake CA". The letsencrypt program will then ask me for my agreement to the Terms of Service and then, for each domain I specified with the --domains option present me the token content and the location under each domain where it expects to find this content, respectively. This looks like this each time: 
-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running letsencrypt in manual mode on a machine that is
not your server, please ensure you're okay with that.
Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: Y
Make sure your web server displays the following content at
http://mister-muffin.de/.well-known/acme-challenge/XXXX before continuing:
 "header":  "alg": "RS256", "jwk":  "e": "AQAB", "kty": "RSA", "n": "YYYY" , "payload": "ZZZZ", "signature": "QQQQ" 
Content-Type header MUST be set to application/jose+json.
If you don't have HTTP server configured, you can run the following
command on the target server (as root):
mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n ' "header":  "alg": "RS256", "jwk":  "e": "AQAB", "kty": "RSA", "n": "YYYY" , "payload": "ZZZZ", "signature": "QQQQ" ' > .well-known/acme-challenge/XXXX
# run only once per server:
$(command -v python2   command -v python2.7   command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map =  '': 'application/jose+json' ; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()" 
Press ENTER to continue
For brevity I replaced any large base64 encoded chunks of the messages with YYYY, ZZZZ and QQQQ. The token location is abbreviated with XXXX. After temporarily stopping Pound on my webserver I created the directory /tmp/letsencrypt/public_html/.well-known/acme-challenge and then opened two shells on my server, both at /tmp/letsencrypt/public_html. In one, I kept a tiny HTTP server running (like the suggested Python SimpleHTTPServer which will also work if one has Python installed). In the other I copy pasted the echo line that the letsencrypt program suggested me to run. I had to copypaste that echo command for each domain I wanted to verify. This could easily be automated, so I filed an issue about this with upstream. It seems that the letsencrypt servers query each of these tokens twice: once directly each time after having hit enter after seeing the message above and another time once all tokens are in place. At the end of this ordeal I get: 
2015-11-04 11:12:18,409:WARNING:letsencrypt.client:Non-standard path(s), might not work with crontab installed by your operating system package manager
IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to josch@mister-muffin.de.
 - Congratulations! Your certificate and chain have been saved at
   letsencrypt/etc/live/mister-muffin.de/fullchain.pem. Your cert will
   expire on 2016-02-02. To obtain a new version of the certificate in
   the future, simply run Let's Encrypt again.
 - Your account credentials have been saved in your Let's Encrypt
   configuration directory at letsencrypt/etc. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Let's
   Encrypt so making regular backups of this folder is ideal.
I can now scp the content of letsencrypt/etc/live/mister-muffin.de/* to my server. Unfortunately, Pound (and also my ejabberd XMPP server) requires the private key to be in the same file as the certificate and the chain, so on the server I also had to do: 
cat /etc/ssl/private/privkey.pem /etc/ssl/private/fullchain.pem > /etc/ssl/private/private_fullchain.pem
And edit the Pound config to use /etc/ssl/private/private_fullchain.pem. But that's all, folks! EDIT It seems that manually copying over the echo commands as I described above is not necessary. Instead of using the certonly plugin, I can use the webroot plugin. That plugin takes the --webroot-path option and will copy the tokens to there. Since my webroot is on a remote machine, I could just mount it locally via sshfs and pass the mountpoint as --webroot-path. That I didn't realize that the webroot plugin does what I want (and not the certonly plugin) can easily be explained by the only documentation of the webroot plugin in the help output and the man page generated from it being "Webroot Authenticator" which is not very helpful. Another user seems to have run into similar problems. Better documenting the plugins so that these situations can be prevented in the future is tracked in this upstream bug.

3 November 2015

Nathan Handler: Ubuntu California 15.10 Release Party

Ubuntu California 15.10 Release Party On Thursday, October 22, 2015, Ubuntu 15.10 (Wily Werewolf) was released. To celebrate, some San Francisco members of the Ubuntu California LoCo Team held a small release party. Yelp was gracious enough to host the event and provide us with food and drinks. Canonical also sent us a box of swag for the event. Unfortunately, it did not arrive in time. Luckily, James Ouyang had some extra goodies from a previous event for us to hand out. Despite having a rather small turnout for the event, it was still a fun night. Several people borrowed the USB flash drives I had setup with Ubuntu, Kubuntu, and Xubuntu 15.10 in order to install Ubuntu on their machines. Other people were happy to play around with the new release in a virtual machine on my computer. Overall, it was a good night. Hopefully, we can put together an even better and larger release party for Ubuntu 16.04 LTS.

31 October 2015

Dirk Eddelbuettel: RcppArmadillo 0.6.200.2.0

armadillo image Yet another monthly upstream Armadillo update gets us the first changes to the new the 6.* series. This was preceded by two uploads of test released to GitHub-only. These two were tested both against all reverse-dependencies as usual. A matching upload to Debian will follow shortly. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. This release is fairly straightforward with few changes:
Changes in RcppArmadillo version 0.6.200.2.0 (2015-10-31)
  • Upgraded to Armadillo 6.200.0 ("Midnight Blue Deluxe")
    • expanded diagmat() to handle non-square matrices and arbitrary diagonals
    • expanded trace() to handle non-square matrices
Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN release. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

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

30 October 2015

Dirk Eddelbuettel: littler 0.3.0 -- on CRAN !!

max-heap image A new major release of littler is now available. And for the first time in the nine years since 2006 when Jeff started the effort (which I joined not long after) we are now a CRAN package. This required a rewrite of the build system, foregoing the calls to aclocal, autoheader, automake and leaving just a simpler autoconf layer creating a configure script and a simple src/Makevars.in. Not only does R provide such a robust and well-understood build system (which I got to understand reasonably well given all my R packages, but being on CRAN and leveraging its mechanism for installation and upgrades is clearly worth the change. There may be a moment or two of transition. While we can create a binary in an R package, we cannot (generally) copy to /usr/bin or /usr/local/bin as part of the build process (for lack of write-rights to those directories). So if you do not have r in the $PATH and load the package, it makes a suggestion (which needs a linebreak which I added here): 
R> library(littler)
The littler package provides 'r' as a binary.
You could link to the 'r' binary installed in
'/usr/local/lib/R/site-library/littler/bin/r' from
'/usr/local/bin' in order to use 'r' for scripting.
R>
Similarly, you could copy (or softlink) r to ~/bin if that is in your $PATH. The Debian (and Ubuntu) packages will continue to provide /usr/bin/r as before. Note thah these packages will now be called r-cran-littler to match all other CRAN packages. The NEWS file entry is below.
Changes in littler version 0.3.0 (2015-10-29)
  • Changes in build system
    • First CRAN Release as R package following nine years of source releases
    • Script configure, src/Makevars.in and remainder of build system rewritten to take advantage of the R package build infrastructure
    • Reproducible builds are better supported as the (changing) compilation timestamps etc are only inserted for 'verbose builds' directly off the git repo, but not for Debian (or CRAN) builds off the release tarballs
  • Changes in littler functionality
    • Also source $R_HOME/etc/Rprofile.site and ~/.Rprofile if present
  • Changes in littler documentation
    • Added new vignette with examples
Full details for the littler release are provided as usual at the ChangeLog page. The code is available via the GitHub repo, from tarballs off my littler page and the local directory here -- and now of course all from its CRAN page and via install.packages("littler"). A fresh package has gone to the incoming queue at Debian where it will a few days as the binary packages was renamed from littler to r-cran-littler matching all other CRAN packages. Michael Rutter will probably have new Ubuntu binaries at CRAN once the source package gets into Debian proper. Comments and suggestions are welcome at the GitHub repo.

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

29 October 2015

Joey Hess: concurrent output library

concurrent-output is a Haskell library I've developed this week, to make it easier to write console programs that do a lot of different things concurrently, and want to serialize concurrent outputs sanely. It's increasingly easy to write concurrent programs, but all their status reporting has to feed back through the good old console, which is still obstinately serial. Haskell illustrates problem this well with this "Linus's first kernel" equivilant interleaving the output of 2 threads: 
> import System.IO
> import Control.Concurrent.Async
> putStrLn (repeat 'A')  concurrently  putStrLn (repeat 'B')
BABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABA
BABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABA
...
That's fun, but also horrible if you wanted to display some messages to the user: 
> putStrLn "washed the car"  concurrently  putStrLn "walked the dog"
walwkaesdh etdh et hdeo gc
ar
To add to the problem, we often want to run separate programs concurrently, which have output of their own to display. And, just to keep things interesting, sometimes a unix program will behave differently when stdout is not connected to a terminal (eg, ls cat). To tame simple concurrent programs like these so they generate readable output involves a lot of plumbing. Something like, run the actions concurrently, taking care to capture the output of any commands, and then feed the output that the user should see though some sort of serializing channel to the display. Dealing with that when you just wanted a simple concurrent program risks ending up with a not-so-simple program. So, I wanted an library with basically 2 functions: 
outputConcurrent :: String -> IO ()
    
createProcessConcurrent :: CreateProcess -> IO whatever
The idea is, you make your program use outputConcurrent to display all its output, and each String you pass to that will be displayed serially, without getting mixed up with any other concurrent output. And, you make your program use createProcessConcurrent everywhere it starts a process that might output to stdout or stderr, and it'll likewise make sure its output is displayed serially. Oh, and createProcessConcurrent should avoid redirecting stdout and stderr away from the console, when no other concurrent output is happening. So, if programs are mostly run sequentially, they behave as they normally would at the console; any behavior changes should only occur when there is concurrency. (It might also be nice for it to allocate ttys and run programs there to avoid any behavior changes at all, although I have not tried to do that.) And that should be pretty much the whole API, although it's ok if it needs some function called by main to set it up: 
import Control.Concurrent.Async
import System.Console.Concurrent
import System.Process
main = withConcurrentOutput $
    outputConcurrent "washed the car\n"
         concurrently 
    createProcessConcurrent (proc "ls" [])
         concurrently 
    outputConcurrent "walked the dog\n"

$ ./demo
washed the car
walked the dog
Maildir/  bin/  doc/  html/  lib/  mail/  mnt/  src/  tmp/
I think that's a pretty good API to deal with this concurrent output problem. Anyone know of any other attempts at this I could learn from? I implemented this over the past 3 days and 320 lines of code. It got rather hairy: It seems to work pretty great though. I got Propellor using it, and Propellor can now run actions concurrently!

27 October 2015

Dirk Eddelbuettel: Rcpp now used by over 500 CRAN packages

500 Rcpp packages This morning, Rcpp reached another round milestone: 501 packages on CRAN now depend on it (as measured by Depends, Imports and LinkingTo declarations, and even excluding one or two packages with an accidental declaration that do not use it). The graph is on the left depicts the growth of Rcpp usage over time. And there are a full seventy more on BioConductor in its development branch (but BioConductor is not included in the chart). Rcpp cleared 300 packages less than a year ago. It passed 400 packages in June when I only tweeted about it this June (while traveling for Rcpp training at U Zuerich, the R Summit at CBS, and the fabulous useR! 2015 at U Aalborg; so no blog post). The first and less detailed part uses manually saved entries, the second half of the data set was generated semi-automatically via a short script appending updates to a small file-based backend. A list of user package is kept on this page. Also displayed in the graph is the relative proportion of CRAN packages using Rcpp. The four per-cent hurdle was cleared just before useR! 2014 where I showed a similar graph (as two distinct graphs) in my invited talk. We passed five percent in December of last year, six percent this July and now stand at 6.77 percent, or about one in fourteen R packages. 500 user packages is very humbling, a staggering number and a big responsibility. We will out best try to keep Rcpp as performant and reliable as it has been so that the next set of packages can rely on it---just like these 500 do. So with that a very big Thank You! to all users and contributors of Rcpp for help, suggestions, bug reports, documentation or, of course, code.

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

Wouter Verhelst: Adventures with modern electronics

I got me a new television last wednesday. The previous one was still functional, but with its 20 inch display it was (by today's standards) a very small one. In itself that wasn't an issue, but combined with my rather large movie collection and the 5.1 surround set that I bought a few years ago, my living room was starting to look slightly ridiculous. The new TV is a Panasonic 40" UHD ("4K") 3D-capable so-called smart thing. Unfortunately, all did not go well. When I initially hooked it up, I found it confusingly difficult to figure out how to make it display something useful from the HDMI input rather than from the (not yet connected) broadcast cable. This eventually turned out to be due to the fact that the HDMI input was not selectable by a button marked "AUX" or similar, but by a button marked with some pictogram on a location near the teletext controls, which was pretty much the last place I'd look for such a thing. After crossing that bridge, I popped in the correct film for that particular day and started watching it. The first thing I noticed, however, was that something was odd with the audio. It turned out that the TV as well as the 5.1 amplifier support the CEC protocol, which allows the TV to control some functionality of the A/V receiver. Unfortunately, the defaults were set in the TV to route audio to the TV's speakers, rather than to the 5.1 amp. This was obviously wrong, and it took me well over an hour to figure out why that was happening, and how I could fix it. My first solution at that time was to disable CEC on the amplifier, so that I could override where the audio would go there. Unfortunately, that caused the audio and video to go out of sync; not very pleasant. In addition, the audio would drop out every twenty seconds or so, which if you're trying to watch a movie is horribly annoying, and eventually I popped the DVD into a machine with analog 5.1 audio and component HD video outputs; not the best quality, but at least I could stop getting annoyed about it. Over the next few days, I managed to get the setup working better and better: There's just on thing remaining: when I go into the channel list and try to move some channels around, the TV has the audacity to tell me that it's "not allowed". I mean, I paid for it, so I get to say what's allowed, not you, thankyouverymuch. Anyway, I'm sure I'll figure that out eventually. The TV also has some 3D capability, but unfortunately it's one of those that require active 3D glasses, so the set that I bought at the movie theatre a while ago won't work. So after spending several tens of euros on extra cabling, I'll have to spend even more on a set of 3D glasses. They'll probably be brand-specific, too. Ah well. It's a bit odd, in my opinion, that it takes me almost a week to get all that stuff to properly work. Ten years ago, the old TV had some connections, a remote, and that was it; you hook it up and you're done. Not anymore.

26 October 2015

C.J. Adams-Collier: Some statistics from the router at the cabin

sip0 is a GRE tunnel between the router and the colo box in Seattle, the payload of which is encapsulated as ipsec traffic before being transmitted over the Ubiquity equipment to the switch that the CenturyLink DSL modem attaches to. I don t get centurylink easter eggs in my search results when I use this interface. eth9 is the local gigabit transceiver. Attached directly to a SIP phone which bridges to a gigabit switch, on which the Ubiquity equipment participates. lo is the local loopback interface, of course. Good old 127/8 usb1 is the 100Mbit USB NIC to which the WRT54G with ssid colliertech.org is attached. The vast majority of the traffic originates on this interface. 
cjac@wanjet1:~$ uptime
 09:11:18 up 32 days, 18:33,  6 users,  load average: 0.00, 0.01, 0.05
cjac@wanjet1:~$ sudo ifconfig
[sudo] password for cjac: 
eth9      Link encap:Ethernet  HWaddr 00:26:b9:e3:9b:47  
          inet addr:10.0.0.7  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::226:b9ff:fee3:9b47/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:176060020 errors:4 dropped:12 overruns:0 frame:2
          TX packets:131573705 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:216753073131 (201.8 GiB)  TX bytes:30777442696 (28.6 GiB)
          Interrupt:20 Memory:f5400000-f5420000 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:3423 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3423 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:392714 (383.5 KiB)  TX bytes:392714 (383.5 KiB)
sip0      Link encap:UNSPEC  HWaddr 64-40-6A-02-30-30-3A-30-00-00-00-00-00-00-00-00  
          inet addr:100.64.107.2  P-t-P:100.64.107.1  Mask:255.255.255.252
          inet6 addr: fe80::200:5efe:6440:6a02/64 Scope:Link
          inet6 addr: 2607:ff08:f5:1338::6440:6b02/126 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1414  Metric:1
          RX packets:468792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:297314 errors:30556 dropped:5 overruns:0 carrier:30549
          collisions:0 txqueuelen:0 
          RX bytes:512744498 (488.9 MiB)  TX bytes:21652345 (20.6 MiB)
usb1      Link encap:Ethernet  HWaddr 40:3c:fc:01:35:a5  
          inet addr:172.16.67.1  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::423c:fcff:fe01:35a5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:131960908 errors:0 dropped:0 overruns:0 frame:0
          TX packets:175522396 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:28447118558 (26.4 GiB)  TX bytes:216131320364 (201.2 GiB)

25 October 2015

Russ Allbery: Review: The Thrilling Adventures of Lovelace and Babbage

Review: The Thrilling Adventures of Lovelace and Babbage, by Sydney Padua
Publisher: Pantheon
Copyright: 2015
ISBN: 0-307-90827-5
Format: Hardcover
Pages: 317
I seem to be writing a lot of reviews lately where any reader can easily do their own research and see if this is something they'd like. This is another of those, but perhaps a bit more obscure. As Padua explains in the preface, the first Lovelace and Babbage strip was intended to be a one-off joke. A friend suggested that she draw a comic telling the (short and rather tragic) life of Ada Lovelace, widely considered the first computer programmer even though the computer for which she wrote programs was never built: Charles Babbage's Analytic Engine. Padua found the story of Babbage and Lovelace's collaboration fascinating but too grim, and so wrote an alternate ending involving a pocket universe in which Babbage and Lovelace lived on to fight crime! Or at least fought against street organs and poetry. Padua meant this as a joke. The Internet took it as a teaser. Quite to her surprise, she found herself writing occasional additional episodes and getting lost in fascinating research about Lovelace and Babbage. The result is all at 2dgoggles.com. This book is a curated collection of those comics, including much of their (extensive) footnotes and research notes, in a very attractive and well-constructed book form. The best review, therefore, would be to go read some of the comics yourself, easily accessible via the Comics tab on the web site, and see if this is the sort of thing you'd enjoy. There is some material in the book that isn't on the web site, but most of it is there (including one full story that didn't make it into the book). There are a few reasons to buy a collection like this of material that previously appeared on the Internet. One, of course, is out of gratitude to support the author, which is the main reason I bought it. If you want to do that, though, you probably already know you do. Another reason is for additional unpublished material, but that's not really the case here. But a third is that, despite all the technology of the web, books can sometimes provide a more elegant and beautiful presentation. And that's very much the case for The Thrilling Adventures of Lovelace and Babbage. The hardcover is a beautiful work of art. It has what you would expect from a hardcover graphic novel, of course: sturdy paper, lovely story headings in the form of Victorian-style posters, and very nice artwork beneath the dust jacket. (I've been so happy to see that in the last few hardcovers I've reviewed.) But, best of all, it presents the primary research notes on each page underneath comic panels. Those who have been reading Lovelace and Babbage as it appears on the web know Padua's copious research notes. But they're normally presented at the end of each complete part, and I found myself often not reading them in detail. This might not be the case for everyone, but at least for me this presentation works so much better. Historical notes are at the bottom of (nearly) every page, in context. This might sound like it would distract from and break up the flow of the story, but at least for me it does the opposite. The comics feel so much richer when intermixed with the actual history (which in some cases is surprisingly similar to what seemed to be wild, invented scenarios). The historical notes also have end notes, and quite substantial ones. I found that organization less successful (readers of my reviews will know I have a long-standing antipathy towards end notes for anything other than cross-references), but I have to admit I have no idea how Padua would have fit those on the same page as footnotes. They're also written well enough, and with sufficient detail, that I could usually read a chapter and then read all the end notes and mostly remember what they referred to. Padua also takes advantage of the format to play a few neat games with frame breaks: characters commenting on the notes, stabbing things into them, or otherwise affecting them. I have to admit to some mild frustration where this makes the notes unreadable, since they're nearly as fascinating as the comics, but the overall effect is still worth it. (And, of course, the full notes are available on the web if one wishes to look them up.) Rounding out the book version are a few of the best original source documents that Padua found, thankfully excerpted and well-edited to not outlive their welcome for those of us who don't like poring over Victorian letters. And, finally, some beautiful illustrations of the mechanisms of the Analytic Engine with supporting descriptions of how they were supposed to work. I'm not particularly mechanically inclined, nor that fascinated by steampunk, and I still found these diagrams impressive and fun to look at. Someone more interested in such things will be in for a treat. I've been thoroughly enjoying the (sadly infrequent) installments of Lovelace and Babbage for years now, and am utterly delighted by their hardcover appearance. If you already knew about Padua's work and have any interest in nice hardcovers of such things, I don't think you'll regret the purchase. If you haven't heard of her, or this series, before, some quick reading at the web site should quickly reveal whether this is something you'd enjoy. Rating: 9 out of 10

24 October 2015

Dirk Eddelbuettel: rfoaas 0.1.8

A new release rfoaas is now on CRAN following up on the recent upstream release 0.1.8 of FOAAS. The rfoaas package provides an interface for R to the most excellent FOAAS service--which provides a modern, scalable and RESTful web service for the frequent need to tell someone to f$#@ off. Release 0.1.8 brings over a handfull new access points relative to the previous release 0.1.6: bday(), family_(), shutup(), zayn(), dalton(), dosomething(), retard(), and thumbs(). One of these may make a fine addition for beloved post-test comments in testthat: 
R> library(rfoaas)
R> dosomething("Fix", "function", "testthat")
[1] "Fix the fucking function! - testthat"
R>
We did not make a release following version 0.1.7 of FOAAS: my testing revealed somewhat less consistent results for the language / i18n filter added in 0.1.6. So I filed issue ticket #95, but as it still lingers unanswered, I consider this feature to be unsupported for now; the tests for the language filter were disabled for now as well. As usual, CRANberries provides a diff to the previous CRAN release. Questions, comments etc should go to the GitHub issue tracker.

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

Vincent Sanders: It takes courage to sit on a jury. How many of us want to decide the fate of another person's life or freedom?

I think Regina Brett has a point although having now experienced being a juror in a British crown court I have a much better understanding of both the process and effectiveness of the jury system.

The actual process of becoming a juror on a case is something I had not been aware of previously. You simply receive a letter telling you to be at the court on a specific date and that you are required to be available for at least ten days, possibly more. The only qualification to receive the letter is to be on the electoral roll and it is an invitation with few options to refuse without serious repercussions.

When you arrive at the court you are directed to the Jury lounge (practical hint: take a book) where you notice there are over forty people, which would seem odd until you realise there are three courtrooms and they each need a jury, even then there are an excess of people which is because of the selection process.

The process of jury selection is fairly simple, an usher for a court comes and calls fourteen names which forms the jury in waiting. The group is taken up to the court waiting room (this room gets terribly familiar over the forthcoming weeks) and then twelve names are called.

As each person is called they enter the jury box in order which persists for the entire trial (practical hint:remember your juror number). Before each person is sworn or affirmed there is the possibility they will be found unsuitable and will be replaced by one of the previously unselected jurors. Any unselected jurors are then sent back to the jury lounge and become available for forming another jury in waiting.

Anyone unselected at the end of the process has to remain available to return to the court to form a jury in waiting when a previous trial ends until they have exhausted their duty. There were a few of these unfortunate people who were kept in a state of limbo for several days and I am relieved this did not happen to me.

Being a juror, from a purely practical perspective, felt like working an office job for ten days. Duties consisting of attending a series of meetings with strange rules and the typically understated British approach to mentioning the result of breaking them.

I participated in two cases, both of which were (almost by definition) unpleasant happenings, these were a case of Grievous bodily harm and an offence under section 7 of the Sexual Offences Act 2003.

Both cases were challenging in their own ways the first because of the way the case was presented and the second because of its subject matter. One of the most important rules is "Do not discuss anything with anyone as it might be perjury" so going along with that I will not be discussing any details. Because I cannot be specific this post has become a little impersonal, you will have to forgive me as I found I had to remove a great deal of more content which was not appropriate.

An important thing to note is that the trials bore no resemblance to TV courtroom drama. The trials proceed in a professional manner with very little theatrics. The prosecution barrister commences outlining the case against the accused, calling witnesses and reading into evidence uncontested material. The defence then gets to present their case, again calling witnesses and placing documents into evidence.

One of the striking things about this process is that if the barristers do not call a witness or present evidence that would seem to be pertinent, the jury must not draw inference from that omission, which is especially bizarre when a central witness referred to by almost everyone involved with the case is not called.

Once the case is presented the jury is sequestered in a room and must come to a unanimous decision on each of the charges. This was, for me, the most challenging part of the whole process. Twelve people with unique views on the information presented have to attempt to discuss the evidence and not simply go with their first impressions based on their preconceptions.

The jury is allowed to ask for some evidence to be repeated and if deliberations take some time the jury may be instructed that a majority of 10 to 2 may be accepted. I imagine at some point the jury will run out of time to make a decision and something else will happen but I did not experience this.

Overall the experience was enlightening if not enjoyable, I understand the process a lot more and am happy to have discharged my duty and am equally glad the responsibility will not come around again for at least a few years.

Russ Allbery: Review: Oathbreakers

Review: Oathbreakers, by Mercedes Lackey
Series: Vows and Honor #2
Publisher: DAW
Copyright: January 1989
ISBN: 0-88677-454-3
Format: Mass market
Pages: 318
The Tarma and Kethry stories tend to be stand-alone and are readable out of order, and this isn't an exception. But if you want their background, consider reading Oathblood or (less recommended) The Oathbound before reading this book. (Reading Oathblood first may require a bit of finesse, since some of the stories in that book come after this novel. Unfortunately, there is no good ordering or collection of these stories that maintains internal chronological order.) This is more like it. This is the Tarma and Kethry story that I remembered when calling them my favorite characters in the Valdemar universe. Following the short stories merged into The Oathbound fixup novel, Tarma and Kethry are still trying to gather the resources required to start a school and to rebuild Tarma's clan. That's led to them signing with a highly-respected mercenary company: Idra's Sunhawks. Idra renounced her claims to the Rethwellen line of royal succession to lead the Sunhawks, creating a mercenary band that's legendary for their quality and battlefield capabilities. The story opens with a campaign in Jkatha, on one side of a civil war, which is mostly an opportunity to get to know the Sunhawks and to see Tarma and Kethry show their competence. The real story starts later, when Idra is called back to Rethwellen for family business and something goes very wrong. I think Lackey is best at two types of stories: misunderstood young people who grow into themselves and their place in the world, and competent people displaying their competence. The Tarma and Kethry stories, and particularly Oathbreakers, are of the latter type. This is clearly wish fulfillment: Lackey's stories often lack nuance, there's rarely any doubt as to who the good and bad guys are, and, although very bad things can happen, you're probably going to get some sort of happy ending. But if you're in the mood for that sort of story, it's so satisfying. The Tarma and Kethry we see here are a mature, experienced fighter and mage team (plus Warrl, who provides vitally important magical and combat assistance, as well as some pointed advice). They know what they're doing, they care deeply for each other, and both their relationship patterns and their capabilities are well-understood. Both do a bit of growing over the course of this novel, but that's not really the point. The point is seeing them take on unfamiliar challenges and tricky investigations while being very good at what they do. In other words, this isn't bildungsroman or high fantasy; it's sword and sorcery, and an excellent example of the genre. Reading these books as part of the overall Valdemar series provides some enjoyable moments with the first explicit contact between Valdemar and its Heralds and Tarma and Kethry's world. The maps here firmly establish their home regions as well to the south of Valdemar and multiple kingdoms away, but Rethwellen (as previously established in earlier Herald-focused trilogies) is on Valdemar's southern border. Seeing Lackey's very separate magic and divinity systems cross and meet, with a bit of initial mutual suspicion, is a rather fun moment (if, at least, you're in the mood for a story in which the world has a vested interest in making sure all the good people like each other). Although I'm wondering why Kethry didn't get extremely uncomfortable when she crossed the border into Valdemar due to the trick that Vanyel pulled in his trilogy. (I seem to recall this is explained away at some point.) Be warned that this novel does contain other elements typical of early Lackey. There is, for example, the inevitable rape, although thankfully off-camera and not quite as central to the plot. (Although in a way that makes it worse since it felt gratuitous. I'm unconvinced that the rape was at all necessary to the story that Lackey was telling.) Revenge and eye-for-an-eye justice are hotly defended by the protagonists. This isn't a series to look to for subtle and complex solutions to political problems; instead, everything gets better if you just kill all the evil people. There isn't anything quite as egregious as the actions of the supposed good guys in The Oathbound, but you still have to read past a certain bloodthirstiness in the stated good side of a very black-and-white morality. That means this isn't a novel for all people or all moods. But within those genre conventions, which aren't that unusual for sword and sorcery, Oathbreakers is a lot of fun. It's one of the few Valdemar novels I've read during this re-read that lived up to my memory of it. Recommended if you like this sort of thing. Rating: 8 out of 10

23 October 2015

Hideki Yamane: Are you still hungry?

Microsoft became Gold Sponsor of OpenBSD foundation, and LF became Platinum, for sustainable development of OpenSSH. However, Linux distribution leader Red Hat and Cloud giant AWS don't pay any money for it. Ansible doesn't work with ssh, it was acquired with huge money by Red Hat.

Why don't they donate to Core Infrastructure of their business? It's okay for its license, just Ethical thing. Not much for strategical benefit. But... you, leaders? I think you're enough to pay some money for it.

Next.

Previous.