Search Results: "ag"

31 October 2015

Jonathan McDowell: Thoughts on the LG G Watch R Android smartwatch

Back in March I was given an LG G Watch R, the first Android Wear smartwatch to have a full round display (the Moto 360 was earlier, but has a bit cut off the bottom of the actual display). I d promised I d get round to making some comments about it once I d had it for a while and have failed to do so until now. Note that this is very much comments on the watch from a user point of view; I haven t got to the point of trying to do any development or other hacking of it. Firstly, it s important to note I already was wearing a watch and have been doing so for all of my adult life. Just a basic, unobtrusive analogue watch (I ve had a couple since I was 18, before that it was pretty much every type of calculator watch available at some point), but I can t remember a period where I didn t. The G Watch R is bulkier than what I was previously wearing, but I haven t found it obtrusive. And I love the way it looks; if you don t look closely it doesn t look like a smart watch (and really it s only the screen that gives it away). Secondly, I already would have taken my watch off at night and when I was showering. So while the fact that the battery on the G Watch R will really only last a day and a half is by far and away its most annoying problem, it s not as bad as it could be for me. The supplied charging dock is magnetic, so it lives on my beside table and I just drop the watch in it when I go to bed. With those details out of the way, what have I thought of it? It s certainly a neat gadget. Being able to see my notifications without having to take my phone out of my pocket is more convenient than I expected - especially when it s something like an unimportant email that I can then easily dismiss by swiping the watch face. My agenda being just a flick away, very convenient, particularly when I m still at the stage of trying to remember where my next lecture is. Having walking directions from Google Maps show up on the watch (and be accompanied by a gentle vibration when I need to change direction) is pretty handy too. The ability to take pictures via the phone camera, not so much. Perhaps if it showed me roughly what I was about to photograph, but without that it s no easier than using the phone interface. It s mostly an interface for consuming information - I ve tried the text to SMS interface a few times, but it s just not reliable enough that I d choose to use it. I ve also been pleased to see it get several updates from LG in the time I ve had it. First the upgrade from Wear 4.4 to Wear 5.1 (probably via 5.0 but I forget), but also the enabling of wifi support. The hardware could always support this, but initially Android Wear didn t and then there was some uncertainty about the FCC certification for the G Watch R. I can t say I use it much (mostly the phone is within range) but it s nice to see the improvements in support when they re available. What about the downsides? Battery life, as mentioned above, is definitely the major one. Mostly a day is fine, but the problem comes if I m ever away. There s no way to charge without the charging dock, so that becomes another things I have to pack. And it s really annoying to have your watch go dead on you midday when you forget to do so. I also had a period where I d frequently (at least once a week) find an Android Wear isn t responding. Wait/Restart? error on the watch screen. Not cool, but thankfully seems to have stopped happening. Finally there s the additional resource requirements it puts on the phone. I have a fairly basic Moto G 4G that already struggles with Ingress and Chrome at the same time, so adding yet another thing running all the time doesn t help. I m sure I could make use of a few more apps if I was more comfortable with loading the phone. The notable point for me with the watch was DebConf. I d decided not to bring it, not wanting the hassle of dealing with the daily charging. I switched back to my old analogue watch (a Timex, if you care). And proceeded to spend 3 days looking at it every time my phone vibrated before realising that I couldn t do that. That marked the point where I accepted that I was definitely seeing benefits from having a smart watch. So when I was away for a week at the start of September, I brought the charger with me (at some point I ll get round to a second base for travel). I was glad I d done so. I m not sure I m yet at the point I d replace it in the event it died, but on the whole I m more of a convert that I was expecting to be.

Petter Reinholdtsen: New book, "Fri kultur" by @lessig, a Norwegian Bokm l translation of "Free Culture" from 2004

People keep asking me where to get the various forms of the book I published last week, the Norwegian Bokm l edition of Lawrence Lessigs book Free Culture. It was published on paper via lulu.com, and is also available in PDF, ePub and MOBI format. I currently sell the paper edition for self cost from lulu.com, but might extend the distribution to book stores like Amazon and Barnes & Noble later. This will double the price and force me to make a profit from selling the book. Anyway, here are links to get the book in different formats: Note that the MOBI version have problems with the table of content, at least with the viewers I have been able to test. And the ePub file have several problems according to epubcheck, but seem to display fine in the viewers I have tested. All the files needed to create the book in various forms are available from the github project page. The project got press coverage from the Norwegian IT news site digi.no. Check out the article "Vil pne politikernes yne for Creative Commons". I've blogged about the project as it moved along. The blogs document the translation progress and insights I had along the way.

Joey Hess: a tiling region manager for the console

Building on top of concurrent-output, and some related work Joachim Breitner did earlier, I now have a kind of equivilant to a tiling window manager, except it's managing regions of the console for different parts of a single program. Here's a really silly demo, in an animated gif: demo2.gif Not bad for 23 lines of code, is that? Seems much less tedious to do things this way than using ncurses. Even with its panels, ncurses requires you to think about layout of various things on the screen, and many low-level details. This, by contrast, is compositional, just add another region and a thread to update it, and away it goes. So, here's an apt-like download progress display, in 30 lines of code. aptdemo.gif Not only does it have regions which are individual lines of the screen, but those can have sub-regions within them as seen here (and so on). And, log-type messages automatically scroll up above the regions. External programs run by createProcessConcurrent will automatically get their output/errors displayed there, too. What I'm working on now is support for multiline regions, which automatically grow/shrink to fit what's placed in them. The hard part, which I'm putting the finishing touches on, is to accurately work out how large a region is before displaying it, in order to lay it out. Requires parsing ANSI codes amoung other things. STM rules There's so much concurrency, with complicated interrelated data being updated by different threads, that I couldn't have possibly built this without Software Transactional Memory. Rather than a nightmare of locks behind locks behind locks, the result is so well behaved that I'm confident that anyone who needs more control over the region layout, or wants to do funky things can dive into to the STM interface and update the data structures, and nothing will ever deadlock or be inconsistent, and as soon as an update completes, it'll display on-screen. An example of how powerful and beuatiful STM is, here's how the main display thread determines when it needs to refresh the display:
data DisplayChange
        = BufferChange [(StdHandle, OutputBuffer)]
          RegionChange RegionSnapshot
          TerminalResize (Maybe Width)
          EndSignal ()
    ...
                change <- atomically $
                        (RegionChange <$> regionWaiter origsnapshot)
                                 orElse 
                        (RegionChange <$> regionListWaiter origsnapshot)
                                 orElse 
                        (BufferChange <$> outputBufferWaiterSTM waitCompleteLines)
                                 orElse 
                        (TerminalResize <$> waitwidthchange)
                                 orElse 
                        (EndSignal <$> waitTSem endsignal)
                case change of
                        RegionChange snapshot -> do
                ...
                        BufferChange buffers -> do
                ...
                        TerminalResize width -> do
                ...
So, it composes all these STM actions that can wait on various kinds of changes, to get one big action, that waits for all of the above, and builds up a nice sum type to represent what's changed. Another example is that the whole support for sub-regions only involved adding 30 lines of code, all of it using STM, and it worked 100% the first time.
Available in concurrent-output 1.1.0.

30 October 2015

Mike Gabriel: New plugin for GOsa: gosa-plugin-pwreset

For a school customer here in Nothern Germany, I developed another GOsa Add-On this week, the Add-On's name is: Password Management Add-On for GOsa (gosa-plugin-pwreset). This password management and reset tool allows one to administratively mass-reset user passwords in GOsa based on various approaches.
  1. A CSV file can be uploaded containing user IDs and new passwords. The CSV file format for this is: comma-separated, no quotes, two columns (<uid>, <userPassword>).
  2. An organizational unit of the LDAP tree can be selected and for all user accounts in that section of the LDAP tree (i.e., the selected OU and all sub-OUs), new passwords can be set. The passwords will get auto-generated when using this approach.
  3. Other approach needed? Please get in touch and provide me with a description of your potential use case.
Before passwords are actually changed, the site admin has various options: The source code of this new GOsa Add-On is available on Github [1] and has also been uploaded to Debian's NEW queue already. light+love
Mike [1] https://github.com/gosa-project/gosa-plugin-pwreset

Ritesh Raj Sarraf: Fixing broken videos

Post iPhone launch, in this new age, it is common to carry a device capable of capturing high definition images and videos. Most people today carry a high end device capable of capturing video/audio, in the form of a Mobile Phone. This has made us raise our expectation that we should capture most moments, if not all. But as is with everything, sometimes things ditch you right at the moment when you did not want it to. In new age phones, scenarios usually are: you capturing a video and the actual data not written to the disk (battery drain, cpu overheat, software bug: Whatever). Such was my case from the year 2012, where one of the videos was corrupt. Corrupt as in, A/V not in sync. Now everytime I solve a real world problem using Free Software tools, I feel the need to express my gratitude. It also serves as a note for me (and maybe others too), for future, if I run into similar problems. ;-) So as it turns out (in layman terms), a video clip is nothing but 2 streams: Video and Audio. Now most video run at 30 frames per second. And the audio stream synchronizes with the video frames. Sorry, I did not read up beyond that, as I was able to fix my problem. cheekywink So, my thought was that the video stream is not corrupt. It just is rendering at a slower frame rate. So, there were 2 problems. 1: Video rendering slower than the usual 30 fps rate. 2: As a result of 1, audio not being in sync with video. Thanks to gpac tools, even a novice, I was able to quickly separate the streams. And then re-encode the video stream into 30 fps. And then merge the audio + video stream together. And the result: Just awesome. In below steps, Strip the video which results in a raw H264 data file. Similar for audio. And then just re-encode the streams, specifying the framerate.
MP4Box -add 20121002_164608.mp4#video -raw 1 -new test1
test1_track1.h264
MP4Box -add 20121002_164608.mp4#audio -raw 2 -new test1_audio
test1_audio_track2.aac
MP4Box -add test1_track1.h264:fps=30 -add test1_audio_track2.aac -new test1_audio_30fps.mp4

Categories:

Keywords:

Like:

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.

Laura Arjona: Look at that nice looking FreedomBox!

This is a guest post by Alberto Fuentes, Debian contributor. Thanks!! I m rebuilding one my home server and decided to take a look at the FreedomBox project as the base for it. The 0.6 version was recently released and I wasn t aware of how advanced the project is already! They have a virtualbox image ready for some quick test. It took me longer to download it than to start using it. Here s is a pic of what it looks like to entice you to try it :) Selection_175
All this is already on debian right now and you can turn any debian sid installation into a FreedomBox just by installing a package. The setup generates everything private on the first run, so even the virtualbox image can be used as the final thing They use Plinth (Django) to integrate the applications into the web interface. More info on how to help integrate more Debian packages here. A live demo is going to be streamed this Friday 30 Oct 2015 and a hackaton is scheduled for this saturday 31 Oct 2015. Cheers!
Filed under: My experiences and opinion Tagged: Debian, English, Freedom, FreedomBox, selfhosting

29 October 2015

B lint R czey: FFmpeg and Kodi arrived to jessie-backports!

FFmpeg Kodi Debian JessieDebian has switched to FFmpeg in testing in July but the work on the package did not stop at that point. After careful testing we can now provide official packages for Jessie users through jessie-backports. See installation instructions here. FFmpeg becoming available in jessie-backports also enabled us to provide Kodi from Debian in the same official repository. Thanks to everyone in the Debian Multimedia Maintainers team, especially Andreas Cadhalpun who is also upstream developer at the FFmpeg project, Reinhard Tartler who maintained FFmpeg then Libav then FFmpeg again in Debian for long years and everyone else I could not name here but helped making this possible!

Mart n Ferrari: Tales from the SRE trenches: SREs are not firefighters

This is the third part in a series of articles about SRE, based on the talk I gave in the Romanian Association for Better Software. If you haven't already, you might want to read part 1 and part 2 first. In this post, I talk about some strategies to avoid drowning SRE people in operational work.

SREs are not firefighters As I said before, it is very important that there is trust and respect between Dev and Ops. If Ops is seen as just an army of firefighters that will gladly put away fires at any time of the night, there are less incentives to make good software. Conversely, if Dev is shielded from the realities of the production environment, Ops will tend to think of them as delusional and untrustworthy.

Common staffing pool for SRE and SWE The first tool to combat this at Google -and possibly a difficult one to implement in small organisations- is to have single headcount budgets for Dev and Ops. That means that the more SREs you need to support your service, the less developers you have to write it. Combined with this, Google offers the possibility to SREs to move freely between teams, or even to transfer out to SWE. Because of this, a service that is painful to support will see the most senior SREs leaving and will only be able to afford less experienced hires. All this is a strong incentive to write good quality software, to work closely and to listen to the Ops people.

Share 5% of operational work with the SWE team On the other hand, it is necessary that developers see first hand how the service works in production, understand the problems, and share the pain of things failing. To this end, SWEs are expected to take on a small fraction of the operational work from SRE: handling tickets, being on-call, performing deployments, or managing capacity. This results in better communication among the teams and a common understanding of priorities.

Cap operational load at 50% One very uncommon rule from SRE at Google, is that SREs are not supposed to spend more than half of their time on "operational work". SREs are supposed to be spending their time on automation, monitoring, forecasting growth... Not on repeatedly fixing manually issues that stem from bad systems.

Excess operational work overflows to SWE If an SRE team is found to be spending too much time on operational work, that extra load is automatically reassigned to the development team, so SRE can keep doing their non-operational duties. On extreme cases, a service might be deemed too unstable to maintain, and SRE support is completely removed: it means the development team now has to carry pagers and do all the operational work themselves. It is a nuclear option, but the threat of it happening is a strong incentive to keep things sane.
The next post will be less about how to avoid unwanted work and more about the things that SRE actually do, and how these make things better. Comment

Daniel Pocock: reSIProcate 1.10 release

reSIProcate 1.10.0 was released a few weeks ago and after going through the various QA cycles has become available in packages for Debian jessie-backports, EPEL6 and EPEL7 and the latest releases of Fedora and Ubuntu. Key features of the 1.10.x branch: A 1.10.1 release was tagged yesterday and is not yet widely available in packages. This release is only significant for people using RADIUS authentication and keen to change from the FreeRADIUS-client library to radcli.

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!

28 October 2015

Daniel Pocock: Free Real-Time Communications workshop in Manchester, 2 November

Manchester Free Software and MadLab are hosting a workshop on Free and Federated Real-Time Communications with Free Software next Monday night, 2 November from 7pm. Add this to your calendar (iCalendar link) Users and developers are invited to come and discover the opportunities for truly free and secure chat, voice and video with WebRTC, mobile VoIP and the free desktop. This is an interactive workshop with practical, hands-on opportunities to explore this topic, see what works and what doesn't and learn about troubleshooting techniques to help developers like myself improve the software. This is also a great opportunity for any Java developers who would like to get some exposure to the Android platform. People wishing to fully participate in all the activities are encouraged to bring a laptop with the Wireshark software and Android tools (especially adb, the command line utility) or if you prefer to focus on WebRTC, have the latest version of Firefox and Chrome installed. If you are keen to run the DruCall module for WebRTC or your own SIP or XMPP server, you can try setting it up as described in the RTC Quick Start Guide and come along to the workshop with any questions you have. A workshop near you? Manchester has a history of great technological innovation, including the first stored program computer and it is a real thrill for me to offer this workshop there. FSFE Manchester ran a workshop evaluating the performance of free software softphones back in 2012. Over the coming months, I would like to be able to hold further workshops in other locations to get feedback from people who are trying this technology, including the Lumicall app, JSCommunicator and DruCall. If you are interested in helping organize such an event or you have any other feedback about this topic, please come and discuss it on the Free RTC mailing list.

Martin-&#201;ric Racine: xf86-video-geode: Last call, dernier s vice

I guess that the time has finally come to admit that, as far as upstream development is concerned, the Geode X.Org driver is reaching retirement age:
While there have indeed been recent contributions by a number of developers to keep it compilable against recent X releases, the Geode driver has accumulated too much cruft from the Cyrix and NSC days, and it hasn't seen any active contribution from AMD in a long time. Besides, nowadays, Xserver pretty much assumes that its runs on an X driver that leverages its matching kernel driver and thus won't require root priviledges to launch. This isn't the case with the Geode driver, since it directly probes FBDEV and MSR, both of which reside in /dev and require root priviledges to access.
On Debian, as a stopgap measure, the package now Recommends a legacy wrapper that enforces operation as root. Meanwhile, other distributions are mercilessly droping all X drivers that don't leverage KMS. Basically, unless a miracle happens really quick, Geode will soon become unusable on X.
Back when AMD was still involved, a concensus had been reached that, since the Geode series doesn't offer any sort of advanced graphic capabilities, the most sensible option would indeed be to make a KMS driver and let Xserver use its generic modeline driver on top of that, then drop the Geode X driver entirely. Amazingly enough, someone did start working on a KMS driver for Geode LX, but it never made it as far as the Linux kernel tree (additionally, Gitorious seems to be down, but I have a copy of the driver's Git tree on hand, if anyone is interested). While I'll still be accepting and merging patches to the Geode X driver, our best long-term option would be to finalize the KMS driver and have it merged into Linux ASAP.

John Goerzen: The Train to Galesburg

Sometimes, children are so excited you just can t resist. Jacob and Oliver have been begging for a train trip for awhile now, so Laura and I took advantage of a day off school to take them to the little town of Galesburg, IL for a couple days. Galesburg is a special memory for me; nearly 5 years ago, it was the first time Jacob and I took an Amtrak trip somewhere, just the two of us. And, separately, Laura s first-ever train trip had been to Galesburg to visit friends. There was excitement in the air. I was asked to supply a bedtime story about trains I did. On the way to the train station in the middle of the night there was excited jabbering about trains. Even when I woke them up, they lept out of bed and raced downstairs, saying, Dad, why aren t you ready yet? As the train was passing through here at around 4:45AM, and we left home with some time to spare, we did our usual train trip thing of stopping at the one place open at such a time: Druber s Donuts. IMG_20151023_040731 Much as Laura and I might have enjoyed some sleep once we got on the train, Jacob and Oliver weren t having it. Way too much excitement was in the air. Jacob had his face pressed against the window much of the time, while Oliver was busy making snake trains from colored clay complete with eyes. IMG_20151023_062304 The boys were dressed up in their train hats and engineer overalls, and Jacob kept musing about what would happen if somebody got confused and thought that he was the real engineer. When an Amtrak employee played along with that later, he was quite thrilled! We were late enough into Galesburg that we ate lunch in the dining car. A second meal there what fun! Here they are anxiously awaiting the announcement that the noon reservations could make their way to the dining car. Oh, and jockeying for position to see who would be first and get to do the all-important job of pushing the button to open the doors between train cars. IMG_20151023_120143 Even waiting for your food can be fun. IMG_20151023_120728 Upon arriving, we certainly couldn t leave the train station until our train did, even though it was raining. IMG_20151023_145755 Right next to the train station is the Discovery Depot Children s Museum. It was a perfect way to spend a few hours. Jacob really enjoyed the building wall, where you can assemble systems that use gravity (really a kinetic/potential energy experiment wall) to funnel rubber balls all over the place. He sticks out his tongue when he s really thinking. Fun to watch. IMG_20151023_153113 Meanwhile, Oliver had a great time with the air-powered tube system, complete with several valves that can launch things through a complicated maze of transparent tubes. IMG_20151024_150309 VID_20151024_150159 They both enjoyed pretending I was injured and giving me rides in the ambulance. I was diagnosed with all sorts of maladies a broken leg, broken nose. One time Jacob held up the pretend stethoscope to me, and I said ribbit. He said, Dad, you ve got a bad case of frog! You will be in the hospital 190 days! Later I would make up things like I think my gezotnix is all froibled and I was ordered to never leave the ambulance again. He told the story of this several times. After the museum closed, we ate supper. Keep in mind the boys had been up since the middle of the night without sleeping and were still doing quite well! They did start to look a bit drowsy I thought Oliver was about to fall asleep, but then their food came. And at the hotel, they were perfectly happy to invent games involving jumping off the bed. Saturday, we rode over to Peck Park. We had heard about this park from members of our church in Kansas, but oddly even the taxi drivers hadn t ever heard of it. It s well known as a good place to watch trains, as it has two active lines that cross each other at a rail bridge. And sure enough, in only a little while, we took in several trains. IMG_20151024_110035 VID_20151024_110229 The rest of that morning, we explored Galesburg. We visited an antique mall and museum, saw the square downtown, and checked out a few of the shops my favorite was the Stray Cat, featuring sort of a storefront version of Etsy with people selling art from recycled objects. But that wasn t really the boys thing, so we drifted out of there on our way to lunch at Baked, where we had some delicious deep-dish pizza. After that, we still had some time to kill before getting back on the train. We discussed our options. And what do you know we ended up back at the children s museum. We stopped at a bakery to get the fixins for a light supper on the train, and ate a nice meal in the dining car once we got on. Then, this time, they actually slept. Before long, it was 3AM again and time to get back off the train. Oliver was zonked out sleepy. Somehow I managed to get his coat and backpack on him despite him being totally limp, and carried him downstairs to get off the train. Pretty soon we walked to our car and drove home. We tucked them in, and then finally tucked ourselves in. Sometimes being really tired is well worth it.

27 October 2015

Mart n Ferrari: Tales from the SRE trenches: Dev vs Ops

This is the second part in a series of articles about SRE, based on the talk I gave in the Romanian Association for Better Software. On the first part, I introduced briefly what is SRE. Today, I present some concrete ways in which SRE tried to make things better, by stopping the war between developers and SysAdmins.

Dev vs Ops: the eternal battle So, it starts at looking at the problem: how to increase the reliability of the service? It turns out that some of the biggest sources of outages are new launches: a new feature that seemed innocuous somehow managed to bring the whole site down. Devs want to launch, and Ops want to have a quiet weekend, and this is were the struggle begins. When launches are problematic, bureaucracy is put in place to minimise the risks: launch reviews, checklists, long-lived canaries. This is followed by development teams finding ways of side-stepping those hurdles. Nobody is happy. One of the key aspects of SRE is to avoid this conflict completely, by changing the incentives, so these pressures between development and operations disappear. At Google, they achieve this with a few different strategies:

Have an SLA for your service Before any service can be supported by SRE, it has to be determined what is the level of availability that it must achieve to make the users and the company happy: this is called the Service Level Agreement (SLA). The SLA will define how availability is measured (for example, percentage of queries handled successfully in less than 50ms during the last quarter), and what is the minimum acceptable value for it (the Service Level Objective, or SLO). Note that this is a product decision, not a technical one. This number is very important for an SRE team and its relationship with the developers. It is not taken lightly, and it should be measured and enforced rigorously (more on that later). Only a few things on earth really require 100% availability (pacemakers, for example), and achieving really high availability is very costly. Most of us are dealing with more mundane affairs, and in the case of websites, there are many other things that fail pretty often: network glitches, OS freezes, browsers being slow, etc. So an SLO of 100% is almost never a good idea, and in most cases it is impossible to reach. In places like Google an SLO of "five nines" (99.999%) is not uncommon, and this means that the service can't fail completely for more than 5 minutes across a whole year!

Measure and report performance against SLA/SLO Once you have a defined SLA and SLO, it is very important that these are monitored accurately and reported constantly. If you wait for the end of the quarter to produce a hand-made report, the SLA is useless, as you only know you broke it when it is too late. You need automated and accurate monitoring of your service level, and this means that the SLA has to be concrete and actionable. Fuzzy requirements that can't be measured are just a waste of time. This is a very important tool for SRE, as it allows to see the progression of the service over time, detect capacity issues before they become outages, and at the same time show how much downtime can be taken without breaking the SLA. Which brings us to one core aspect of SRE:

Use error budgets and gate launches on them If SLO is the minimum rate of availability, then the result of calculating 1 - SLO is what fraction of the time a service can fail without failing out of the SLA. This is called an error budget, and you get to use it the way you want it. If the service is flaky (e.g. it fails consistently 1 of every 10000 requests), most of that budget is just wasted and you won't have any margin for launching riskier changes. On the other hand, a stable service that does not eat the budget away gives you the chance to bet part of it on releasing more often, and getting your new features quicker to the user. The moment the error budget is spent, no more launches are allowed until the average goes back out of the red. Once everyone can see how the service is performing against this agreed contract, many of the traditional sources of conflict between development and operations just disappear. If the service is working as intended, then SRE does not need to interfere on new feature launches: SRE trusts the developers' judgement. Instead of stopping a launch because it seems risky or under-tested, there are hard numbers that take the decisions for you. Traditionally, Devs get frustrated when they want to release, but Ops won't accept it. Ops thinks there will be problems, but it is difficult to back this feeling with hard data. This fuels resentment and distrust, and management is never pleased. Using error budgets based on already established SLAs means there is nobody to get upset at: SRE does not need to play bad cop, and SWE is free to innovate as much as they want, as long as things don't break. At the same time, this provides a strong incentive for developers to avoid risking their budget in poorly-prepared launches, to perform staged deployments, and to make sure the error budget is not wasted by recurrent issues.
That's all for today. The next article will continue delving into how traditional tensions between Devs and Ops are played in the SRE world. Comment

Francesca Ciceri: Emacs

"Every now and then I install and try emacs, just because. Usually this happens:
(aghisla talking about editors -- quoted with permission)

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.

Lunar: Reproducible builds: week 26 in Stretch cycle

What happened in the reproducible builds effort this week: Toolchain fixes Mattia Rizzolo created a bug report to continue the discussion on storing cryptographic checksums of the installed .deb in dpkg database. This follows the discussion that happened in June and is a pre-requisite to add checksums to .buildinfo files. Niko Tyni identified why the Vala compiler would generate code in varying order. A better patch than his initial attempt still needs to be written. Packages fixed The following 15 packages became reproducible due to changes in their build dependencies: alt-ergo, approx, bin-prot, caml2html, coinst, dokujclient, libapreq2, mwparserfromhell, ocsigenserver, python-cryptography, python-watchdog, slurm-llnl, tyxml, unison2.40.102, yojson. The following packages became reproducible after getting fixed: Some uploads fixed some reproducibility issues but not all of them: reproducible.debian.net pbuilder has been updated to version 0.219~bpo8+1 on all eight build nodes. (Mattia Rizzolo, h01ger) Packages that FTBFS but for which no open bugs have been recorded are now tested again after 3 days. Likewise for depwait packages. (h01ger) Out of disk situations will not cause IRC notifications anymore. (h01ger) Documentation update Lunar continued to work on writing documentation for the future reproducible-builds.org website. Package reviews 44 reviews have been removed, 81 added and 48 updated this week. Chris West and Chris Lamb identified 70 fail to build from source issues. Misc. h01ger presented the project in Mexico City at the 3er Congreso de Seguridad de la Informaci n where it became clear that we lack academic papers related to reproducible builds. Bryan has been doing hard work to improve reproducibility for OpenWrt. He wrote a report linking to the patches and test results he published.

Chris Lamb: ImportError: cannot import name add_to_builtins under Django 1.9

Whilst upgrading various projects to Django 1.9, I found myself repeatedly searching for the following code snippet so I offer it below as a more permanent note for myself and to aid others. If you used django.template.base.add_to_builtins to avoid tedious and unsightly % load module % blocks in your template files, under Django 1.9 you will get the following traceback:

Traceback (most recent call last):
  File "django/core/management/__init__.py", line 324, in execute
    django.setup()
  File "django/__init__.py", line 18, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "django/apps/registry.py", line 108, in populate
    app_config.import_models(all_models)
  File "django/apps/config.py", line 202, in import_models
    self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "myproject/myproject/utils/models.py", line 1, in <module>
    from django.template.base import add_to_builtins
ImportError: cannot import name add_to_builtins
The solution is to move to defining settings.TEMPLATES instead of calling add_to_builtins. This replaces a number of your existing settings, including TEMPLATE_CONTEXT_PROCESSORS, TEMPLATE_DIRS, TEMPLATE_LOADERS, etc. For example:
TEMPLATES = [ 
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [
        os.path.join(BASE_DIR, 'templates'),
    ],
    'APP_DIRS': True,
    'OPTIONS':  
        'context_processors': [
            'django.template.context_processors.debug',
            'django.template.context_processors.request',
            'django.contrib.auth.context_processors.auth',
            'django.contrib.messages.context_processors.messages',
            'myproject.utils.context_processors.settings_context',
        ],
        'builtins': [
            'django.contrib.staticfiles.templatetags.staticfiles',
        ],
     ,
 ]
Simply add the modules you previously loaded with add_to_builtins to the builtins key under OPTIONS. (You can read more in the release notes for Django 1.9, as well as read about settings.TEMPLATES generally.)

Next.

Previous.