Search Results: "ag"

4 July 2016

Benjamin Mako Hill: Studying the relationship between remixing & learning

With more than 10 million users, the Scratch online community is the largest online community where kids learn to program. Since it was created, a central goal of the community has been to promote remixing the reworking and recombination of existing creative artifacts. As the video above shows, remixing programming projects in the current web-based version of Scratch is as easy is as clicking on the see inside button in a project web-page, and then clicking on the remix button in the web-based code editor. Today, close to 30% of projects on Scratch are remixes. Remixing plays such a central role in Scratch because its designers believed that remixing can play an important role in learning. After all, Scratch was designed first and foremost as a learning community with its roots in the Constructionist framework developed at MIT by Seymour Papert and his colleagues. The design of the Scratch online community was inspired by Papert s vision of a learning community similar to Brazilian Samba schools (Henry Jenkins writes about his experience of Samba schools in the context of Papert s vision here), and a comment Marvin Minsky made in 1984:
Adults worry a lot these days. Especially, they worry about how to make other people learn more about computers. They want to make us all computer-literate. Literacy means both reading and writing, but most books and courses about computers only tell you about writing programs. Worse, they only tell about commands and instructions and programming-language grammar rules. They hardly ever give examples. But real languages are more than words and grammar rules. There s also literature what people use the language for. No one ever learns a language from being told its grammar rules. We always start with stories about things that interest us.
In a new paper titled Remixing as a pathway to Computational Thinking that was recently published at the ACM Conference on Computer Supported Collaborative Work and Social Computing (CSCW) conference, we used a series of quantitative measures of online behavior to try to uncover evidence that might support the theory that remixing in Scratch is positively associated with learning. scratchblocksOf course, because Scratch is an informal environment with no set path for users, no lesson plan, and no quizzes, measuring learning is an open problem. In our study, we built on two different approaches to measure learning in Scratch. The first approach considers the number of distinct types of programming blocks available in Scratch that a user has used over her lifetime in Scratch (there are 120 in total) something that can be thought of as a block repertoire or vocabulary. This measure has been used to model informal learning in Scratch in an earlier study. Using this approach, we hypothesized that users who remix more will have a faster rate of growth for their code vocabulary. Controlling for a number of factors (e.g. age of user, the general level of activity) we found evidence of a small, but positive relationship between the number of remixes a user has shared and her block vocabulary as measured by the unique blocks she used in her non-remix projects. Intriguingly, we also found a strong association between the number of downloads by a user and her vocabulary growth. One interpretation is that this learning might also be associated with less active forms of appropriation, like the process of reading source code described by Minksy. The second approach we used considered specific concepts in programming, such as loops, or event-handling. To measure this, we utilized a mapping of Scratch blocks to key programming concepts found in this paper by Karen Brennan and Mitchel Resnick. For example, in the image below are all the Scratch blocks mapped to the concept of loop . scratchblocksctWe looked at six concepts in total (conditionals, data, events, loops, operators, and parallelism). In each case, we hypothesized that if someone has had never used a given concept before, they would be more likely to use that concept after encountering it while remixing an existing project. Using this second approach, we found that users who had never used a concept were more likely to do so if they had been exposed to the concept through remixing. Although some concepts were more widely used than others, we found a positive relationship between concept use and exposure through remixing for each of the six concepts. We found that this relationship was true even if we ignored obvious examples of cutting and pasting of blocks of code. In all of these models, we found what we believe is evidence of learning through remixing. Of course, there are many limitations in this work. What we found are all positive correlations we do not know if these relationships are causal. Moreover, our measures do not really tell us whether someone has understood the usage of a given block or programming concept.However, even with these limitations, we are excited by the results of our work, and we plan to build on what we have. Our next steps include developing and utilizing better measures of learning, as well as looking at other methods of appropriation like viewing the source code of a project.

This blog post and the paper it describes are collaborative work with Sayamindu Dasgupta, Andr s Monroy-Hern ndez, and William Hale. The paper is released as open access so anyone can read the entire paper here. This blog post was also posted on Sayamindu Dasgupta s blog and on Medium by the MIT Media Lab.

Paul Wise: Check All The thingS!

check-all-the-things (aka cats, Meow!) is a tool that aims to make it easy to know which tools can be used to check a directory tree and to make it easy to run those tools on the directory tree. The tree could either be a source tree or a build tree or both. It aims to check as much of the tree as possible so the output can be very verbose and have many false positives. It is not for the busy, lazy or noise intolerant. It runs the checks by matching file names and MIME types against those registered for a list of checks. Each check has a set of dependencies, flags, filename wildcards, MIME type wildcards, comments and prerequisite commands. By default it: It runs all checks for the current distro/release except: There are command-line options to customise the behaviour and automatic bash shell completion via argcomplete. There are 177 checks (including TODO ones) in 73 different categories. There are an additional 224 not-well-specified TODO items for new checks in comments. It is exceptionally easy to add new checks once one knows how to use the tool one wants to add. At this point in time it is probably not a good idea to run it in an untrusted directory tree for several reasons: The project initially started as really hacky wiki page full of commands to run. At some point I figured it was time to make this actually be maintainable and started on a project to do that. At around the same time Jakub Wilk was working on maquack to replace the wiki page. Somehow I found out about it and talked to him about it. It was vastly less hacky than my version so I ended up taking it over and continuing it under the check-all-the-things name. I polished it for the last two years and finally released it into Debian unstable during DebCamp16.

Gunnar Wolf: Got the C.H.I.P.s for DebConf!

I had my strong doubts as to whether the shipment would be allowed through customs, and was happily surprised by a smiling Graham today before noon. He handed me a smallish box that arrived to his office, containing... Our fifty C.H.I.P. computers, those I offered to give away at DebConf! The little machines are quite neat. They are beautiful little devices, including even a plastic back (so you can safely work with it over a conductive surface or things like that). Quite smaller than the usual Raspberry-like format. It has more than enough GPIO to make several of my friends around here drool about the possibilities. So, what's to this machine besides a nice small ARM CPU, 512MB RAM, wireless connectivity (Wifi and bluetooth)? Although I have not yet looked into them (but intend to do so very soon!), it promises to have the freest available hardware around, and is meant for high hackability! And not that it matters But we managed to import them all, legally and completely hassle-free, into South Africa! That's right We are all used to the declaring commercial value as one dollar mindset. But... The C.H.I.P.s are actually priced at US$9 a piece. The declared commercial value is US$450. South Africans said all their customs are very hard to clear But we were able receive 50 legally shipped computers, declared at their commercial value, without any hassles! (yes, we might have been extremely lucky as well) Anyway, stay tuned By Thursday I will announce the list of people that get to take one home. I still have some left, so feel free to mail me at gwolf+chip@gwolf.org.

Mike Hommey: Announcing git-cinnabar 0.4.0 beta 1

Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. Get it on github. These release notes are also available on the git-cinnabar wiki. What s new since 0.3.2?

3 July 2016

Daniel Stender: My work for Debian in June

At least a little much more time lst month for helping to improve the operating system we're working on. I've worked on a couple of package updates, mostly they are for PAPT, DPMT, Debian Science, or pkg-go (in order of completion): New packages: Sponsored Uploads: Again some further ahead with these ones. My "new package of the month" is going to be Theano. I'm still working on the introduction, it'll come hereafter very soon.

Reproducible builds folks: Reproducible builds: week 61 in Stretch cycle

What happened in the Reproducible Builds effort between June 19th and June 25th 2016. Media coverage GSoC and Outreachy updates Toolchain fixes Other upstream fixes Emil Velikov searched on IRC for hints on how to guarantee unique values during build to invalidate shader caches in Mesa, when also no VCS information is available. A possible solution is a timestamp, which is unique enough for local builds, but can still be reproducible by allowing it to be overwritten with SOURCE_DATE_EPOCH. Packages fixed The following 9 packages have become reproducible due to changes in their build dependencies: cclib librun-parts-perl llvm-toolchain-snapshot python-crypto python-openid r-bioc-shortread r-bioc-variantannotation ruby-hdfeos5 sqlparse The following packages have become reproducible after being fixed: Some uploads have fixed some reproducibility issues, but not all of them: Patches submitted that have not made their way to the archive yet: Package reviews 139 reviews have been added, 20 have been updated and 21 have been removed in this week. New issues found: 53 FTBFS bugs have been reported by Chris Lamb, Santiago Vila and Mateusz ukasik. diffoscope development Quote of the week "My builds are so reproducible, they fail exactly every second time." Johannes Ziemke (@discordianfish) Misc. This week's edition was written by Chris Lamb (lamby), Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

Joey Hess: twenty years of free software -- part 7 git-annex

My first Haskell program, and the only software I've written that was inspired by living in a particular place, git-annex has received the lion's share of my time for five years. It was written just to solve my own problem, but in a general way, that turned out to be useful in lots of other situations. So over the first half a year or so, it started attracting some early adopters who made some very helpful suggestions. Then I did the git-annex assistant kickstarter, and started blogging about each day I worked on it. Four years of funding and seven hundred and twenty one posts later, the git-annex devblog is still going. So, I won't talk about technical details in this post, they've all been covered. One thing I wondered when starting git-annex -- besides whether I would be able to write it in Haskell at all -- was would that prevent it from getting many patches. I count roughly 65 "thanks" messages in the changelog, so it gets perhaps one patch contributed per month. It's hard to say if that's a lot or a little. Part of git-annex is supporting various cloud storage systems via "special remotes". Of those not written by me, only 1 was contributed in Haskell. Compare with 13 that use the plugin system that lets other programming languages be used. The other question about using Haskell is, did it make git-annex a better program. I think it did. The strong type system did prevent plenty of bugs, although there have still been some real howlers. The code is still not taking full advantage of the power of Haskell's type system, on the other hand it uses many Haskell libraries that do leverage the type system more. I've done more small and large refactorings of git-annex than on any other program I've written, because the strong types and referential transparency makes refactoring easier and safer in Haskell. And the code has turned out to be much more flexible, for all its static types, than the kind of code I was writing before. Examples include building the git-annex assistant, which uses the rest of git-annex as a library, and making git-annex run actions concurrently, thanks to there being no global variables to complicate things (and excellent support for concurrency and parallelism in Haskell). So: Glad I wrote it, glad I used Haskell for it, estatic that many other people have found it useful, and astounded that I've been funded to work on it for four years. Next: twenty years of free software -- part 8 github-backup

Iustin Pop: A relaxation week

A (forced) relaxation week This was an interesting week, much more so than I expected. The start of the week was the usual: on Monday a run, although at an easier pace after Sunday's longer indoor bike ride, on Tuesday a 30Km outside bike ride (flat, on road, with a mountain bike so not fast at all). On Wednesday however, I had a planned "intervention" at my dentist bone reconstruction (or regeneration, not sure what the right term is for the implantation of scaffolding). The dentist told me I won't be allowed to do sports, especially in the first few days after the procedure, so I knew I will have to take it easy; easy bike rides are fine, but not anything more (e.g. especially not running). The procedure went well and after that I went to work (the dentist looked at me in a funny way when I mentioned I'm not going home but instead back to work). There was a bit of pain a couple of hours after the local anaesthesia went away, but the painkillers did work, so I was able to function somewhat OK. Laughing was the only thing that caused pain, so I tried to be very serious; didn't work well On Thursday morning however, I did feel funny and when I looked into the mirror, I got a shock. The affected side of my face was heavily swollen, and I was feeling as bad as I looked. I had a followup checkup at the dentist, so I went there, and they told me Oh, this is normal. Bone reconstruction is much more difficult on the body as opposed to extraction, since the body actually has to rebuild stuff, instead of just healing the wound. And yes, you should just go back home and take the day off! . OK, logically that explanation makes sense, but my dental extraction had a very predictable pain/recovery curve (spike right at the extraction, plateau for that day, then slow recovery that went to faster recovery after a few days). This procedure was very different, with the first day easy, and the second day much worse. The dentist continued Oh, and by the way, expect this to be worse in the morning, as the body can work all night; also, this should go away by itself over the weekend, so let's meet again on Monday. At this point I realised than I'm not allowed to do sports is not by doctor's orders, but rather my condition doesn't allow me to do sport . Sad panda Friday was even worse; my face was swollen in a different way, such that I looked even more like a monster from the Witcher games. I had to stay at home again, not being able to do much, as the painkillers I got were mostly ineffective. From my usual ~10K steps a day (or more if I run), my Friday was a paltry sub-2K step day. The only thing I was able to do was watch anime. I found Log Horizon to be a pretty interesting anime, much more so than what the synopsis said; the ramification on politics and how to interaction between the two cultures unfolded was much more in-depth than I presumed. Didn't finish it yet, so this is a partial but very strong recommendation for it. Besides watching stuff, I also went to the shop to buy some food, which turned out to be an excuse for "junk food foraging!". The pain took my willpower away and instead of the planned and short grocery list, I found myself with lots of chocolate and ice cream on my hands. Funny how the brain works On Saturday I was a bit better; the swelling went partially away, so if you squinted you could pretend I look my normal-ugly, not the monster-ugly from before. I was able to go outside of the house, do some shopping, etc. so I was able to go back to a ~9K steps day. I also stopped taking painkillers since anyway they weren't of much help, and kept myself entertained with movies and other stuff (cough cough Grim Dawn , since it's a mindless click-kill-loot-repeat ARPG that one can play even when only partially functional). Today (Sunday) was swelling was slightly worse; however, I was feeling well enough to try to go back on the bike trainer (the first three days of "no sports" were over), and planned to do a slow/relaxing one hour Zwift ride. Right, as all the people who ever tried this, it works as long as only fast people overtake you (since you can't catch them anyway), or as long as you don't get to sprint sections. I did slightly improve my Watopia 300m sprint personal record (29.20s 28.29s), which was good enough. After the first lap I took it easier as in had to, since I was not really in shape. I was in any case very glad about ending my 4 days long break from sports! So, my dentist was right indeed. The swelling did by and large clear up over the weekend (although I'll have to see how tomorrow will be), and was also right about how much more difficult this was. On one hand makes sense (growing bone does sound complex), on the other hand, I couldn't imagine that the body works so hard that it puts you out. The dentist was however slightly wrong with the you should not do any strenuous activity, especially in the first three days ; they should have said, ha ha, you'll be flat out for the first days, take it easy and enjoy the painkillers instead. Looking forward now to get back into my regular routine; relaxation is good, but only when done by choice like most things in life

Jonathan McDowell: Confirming all use of an SSH agent

For a long time I ve wanted an ssh-agent setup that would ask me before every use, so I could slightly more comfortably forward authentication over SSH without worrying that my session might get hijacked somewhere at the remote end (I often find myself wanting to pull authenticated git repos on remote hosts). I m at DebConf this week, which is an ideal time to dig further into these things, so I did so today. As is often the case it turns out this is already possible, if you know how. I began with a setup that was using GNOME Keyring to manage my SSH keys. This isn t quite what I want (eventually I want to get to the point that I can sometimes forward a GPG agent to remote hosts for signing purposes as well), so I set about setting up gpg-agent. I used Chris excellent guide to GnuPG/SSH Agent setup as a starting point and ended up doing the following: 
$ echo use-agent >> ~/.gnupg/options
$ echo enable-ssh-support >> ~/.gnupg/gpg-agent.conf
$ sudo sed -i.bak "s/^use-ssh-agent/# use-ssh-agent/" /etc/X11/Xsession.options
$ sudo rm /etc/xdg/autostart/gnome-keyring-ssh.desktop
The first 2 commands setup my local agent, and told it to do SSH agent foo. The next stopped X from firing up ssh-agent, and the final one prevents GNOME Keyring from being configured to be the SSH agent, without having to remove libpam-gnome-keyring as Chris did. After the above I logged out of and into X again, and could see ~/.gnupg/S.gpg-agent.ssh getting created and env grep SSH showing SSH_AUTH_SOCK pointing to it (if GNOME Keyring is still handling things it ends up pointing to something like /run/user/1000/keyring/ssh). [Update: Luca Capello emailed to point out this was a bad approach; there s thankfully no need to do the last 2 commands that require root. #767341 removed the need to edit Xsession.options and you can prevent GNOME Keyring starting on a per user basis with: 
(cat /etc/xdg/autostart/gnome-keyring-ssh.desktop ;
 echo 'X-GNOME-Autostart-enabled=false') > \
 ~/.config/autostart/gnome-keyring-ssh.desktop
] After this it turned out all I need to do was ssh-add -c <ssh keyfile>. The -c says confirm use and results in the confirm flag being appended to the end of ~/.gnupg/sshcontrol (so if you ve already done the ssh-add you can go and add the confirm if that s the behaviour you d like). Simple when you know how, but I ve had conversations with several people in the past who wanted the same thing and hadn t figured out how, so hopefully this is helpful to others.

Joey Hess: Hacker Holler

A quiet place in which to get away and code is all I was looking for when I moved here. I found much more, but that's still the essence of the place. On returning home from the beach, I've just learned that after several years renting this house, I will soon have to leave, or buy it. The house is an EarthShip, tucked away in its own private holler (as we say here in the Appalachian Mtns of Tennessee), below a mountain that is National Forest, two miles down back roads from a river. A wonderful place to relax and code, but developing only free software for twenty years doesn't quite stretch to being able to afford buying this kind of place. But, I got to thinking of times friends were able to visit me here. Grilling over wood fires with friends from Debian. Steep hikes and river swims. Sharing dialup bandwidth between our Linux laptops. A bunch of us discussing Haskell in the living room at midnight. And too, I've many times talked about the place with someone who got a gleam in their eye, imagining themselves living there. And then there's my Yurt, my relief valve before I moved here. And a great spot I like to visit on an old logging road above a creek. Could we put all this together somehow? Might a handful of my friends be able to contribute somewhere in the range of $10 thousand to buy in? Interested? Want more details? Have ideas?
Visit the Hacker Holler website and get in touch. (Limited to folks I've met in person or spent a lot of time online with.)

Elena 'valhalla' Grandi: Debconf streaming and kudos to the video team

Debconf streaming and kudos to the video team

With http://debconf16.debconf.org/ being in South Africa, a lot of people (like me) probably weren't able to attend and are missing the cheese and wine party, mao games and general socialization that is happening there.

One thing we don't have to miss, however, are the talks: as usual the video team https://wiki.debconf.org/wiki/DebConf16/Videoteam is doing a great job recording and https://debconf16.debconf.org/video/live-streaming/ all talks so that people can still participate a bit from their home.

What they do, however, requires a lot of manpower, so if you are attending Debconf please consider volunteering https://wiki.debconf.org/wiki/Videoteam/roles_for_volunteers to help: from my experience last year they are very nice people who are welcoming towards new contributors and they have periodical training sessions to help people getting started with the various tasks. More informations about video team meetings and training session are in the topic of the IRC channel, #debconf-video@OFTC.

I don't think there are cookies involved (which just proves that the video team isn't evil), but you may get a t-shirt and you will get a warm fuzzy feeling of having helped people around the world.

@Debian #debconf

Petter Reinholdtsen: How to use the Signal app if you only have a land line (ie no mobile phone)

For a while now, I have wanted to test the Signal app, as it is said to provide end to end encrypted communication and several of my friends and family are already using it. As I by choice do not own a mobile phone, this proved to be harder than expected. And I wanted to have the source of the client and know that it was the code used on my machine. But yesterday I managed to get it working. I used the Github source, compared it to the source in the Signal Chrome app available from the Chrome web store, applied patches to use the production Signal servers, started the app and asked for the hidden "register without a smart phone" form. Here is the recipe how I did it. First, I fetched the Signal desktop source from Github, using 
git clone https://github.com/WhisperSystems/Signal-Desktop.git
Next, I patched the source to use the production servers, to be able to talk to other Signal users: 
cat <<EOF   patch -p0
diff -ur ./js/background.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js
--- ./js/background.js  2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/background.js    2016-06-29 14:06:29.530300934 +0200
@@ -47,8 +47,8 @@
          );
      );
 
-    var SERVER_URL = 'https://textsecure-service-staging.whispersystems.org';
-    var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments-staging.s3.amazonaws.com';
+    var SERVER_URL = 'https://textsecure-service-ca.whispersystems.org:4433';
+    var ATTACHMENT_SERVER_URL = 'https://whispersystems-textsecure-attachments.s3.amazonaws.com';
     var messageReceiver;
     window.getSocketStatus = function()  
         if (messageReceiver)  
diff -ur ./js/expire.js userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js
--- ./js/expire.js      2016-06-29 13:43:15.630344628 +0200
+++ userdata/Default/Extensions/bikioccmkafdpakkkcpdbppfkghcmihk/0.15.0_0/js/expire.js2016-06-29 14:06:29.530300934 +0200
@@ -1,6 +1,6 @@
 ;(function()  
     'use strict';
-    var BUILD_EXPIRATION = 0;
+    var BUILD_EXPIRATION = 1474492690000;
 
     window.extension = window.extension    ;
 
EOF
The first part is changing the servers, and the second is updating an expiration timestamp. This timestamp need to be updated regularly. It is set 90 days in the future by the build process (Gruntfile.js). The value is seconds since 1970 times 1000, as far as I can tell. Based on a tip and good help from the #nuug IRC channel, I wrote a script to launch Signal in Chromium. 
#!/bin/sh
cd $(dirname $0)
mkdir -p userdata
exec chromium \
  --proxy-server="socks://localhost:9050" \
  --user-data-dir= pwd /userdata --load-and-launch-app= pwd
The script start the app and configure Chromium to use the Tor SOCKS5 proxy to make sure those controlling the Signal servers (today Amazon and Whisper Systems) as well as those listening on the lines will have a harder time location my laptop based on the Signal connections if they use source IP address. When the script starts, one need to follow the instructions under "Standalone Registration" in the CONTRIBUTING.md file in the git repository. I right clicked on the Signal window to get up the Chromium debugging tool, visited the 'Console' tab and wrote 'extension.install("standalone")' on the console prompt to get the registration form. Then I entered by land line phone number and pressed 'Call'. 5 seconds later the phone rang and a robot voice repeated the verification code three times. After entering the number into the verification code field in the form, I could start using Signal from my laptop. As far as I can tell, The Signal app will leak who is talking to whom and thus who know who to those controlling the central server, but such leakage is hard to avoid with a centrally controlled server setup. It is something to keep in mind when using Signal - the content of your chats are harder to intercept, but the meta data exposing your contact network is available to people you do not know. So better than many options, but not great. And sadly the usage is connected to my land line, thus allowing those controlling the server to associate it to my home and person. I would prefer it if only those I knew could tell who I was on Signal. There are options avoiding such information leakage, but most of my friends are not using them, so I am stuck with Signal for now.

Holger Levsen: I won't be going to DebConf16

With great sadness I'm acknowledging and announcing that I won't be going to DebConf16 today, due to sudden health issues (which should be ok soon). Seeing the first pictures on planet Debian a few minutes ago made me very very sad, but still didn't change my mind. Have a whole lot of fun in Cape Town, have great discussions in corridors and while hiking, enjoy the talks and the workshops and hugs to everyone who wants to be hugged. I'll follow online from the distance I('ll) miss you.

Paul Wise: DebConf16 Open Festival day 1

Today was day one of the DebConf16 Open Festival and I attended the open hardware panel, part of the talk about Code For South Africa, shirish's experiences and the DebConf new folks session. The open hardware panel was a wide ranging discussion between bdale, Andy and indiebio. bdate talked about the experiences he has had with his rocketry hardware. bdale said "Make concious decisions about what you are buying", referencing a case where he investigated, found a GPL violation and didn't buy. Various people care about openness of different layers of the hardware. Off-the-shelf products are very strongly integrated, which is great for makers but means that people who care about lower layers like CPU micro-architecture aren't able to participate. Andy said "We are just beginning to come out of the shareware stage [of open hardware]". bdale mentioned the companies who do hardware production as a service from design files. Later in the pub some folks mentioned j-core, an open re-implementation of SuperH processors. I missed most of the code4sa talk unfortunately, but it was about government services and open data. shirish covered his journey through life to Debian. His youth, how satellite TV and knowledge of the outside world came to India around the time of the Iraq war. His experience accessing the Internet for the first time, uncensored vs the usual censorship in India's media. His experiences of Windows 95 viruses and crashes. He learned of PCTwist Linux through a magazine cover. His initial install was not a success but eventually managed to break through and install a desktop, but experienced network and other issues. Eventually he encountered Ubuntu and began contributing bug reports. His experiences there led him to Debian. He began blogging about Debian. In the last few years he and others have been going around the country doing mini-DebConfs at institutes around India. The first question was predictably about having a DebConf in India and how shirish might like to get more involved. DebConf in India sounds like a possibility some day and shirish was thinking about getting involved in publicity, marketting and the Debian installer. The DebConf new folks session was a great intro to DebConf for folks new to the community. There were some quite excellent touches added to this year's version of the event by indiebio and Rhonda. I also got some things done. Usual spam reporting. Reviewed wiki RecentChanges. Talked to the chromium-bsu/MacPorts maintainer about AX_CHECK_GL brokenness. Filed Debian wishlist bug #829292 asking to update autoconf-archive. Redirected a Hurd porterbox request to the exodar admin and quickly found out I was wrong to do that, rectified. Then we found out the LDAP sync to exodar was broken. Replied to someone who intends to sell Debian pre-installs. Thanked BunsenLabs folks for joining the derivatives list. Applied reproducible builds patch for cats from Chris Lamb. Heard about awesome new terminal-mode screensaver. Moo! Prepared a blog post about check-all-the-things.

Russ Allbery: Review: Coming Home

Review: Coming Home, by Jack McDevitt
Series: Alex Benedict #7
Publisher: Ace
Copyright: November 2014
Printing: November 2015
ISBN: 0-425-26088-7
Format: Mass market
Pages: 356
Coming Home is a direct sequel to Firebird, the first time McDevitt has done that in this series. You therefore don't want to start here, although the nature of the sequel doesn't require that you remember Firebird in that much detail. The mystery of the disappearing starships was understood in Firebird but not resolved. The title advertises that as a major theme in this book, but it progresses very slowly. There's more media bickering and various factional attempts to draw Alex (and, to a lesser extent, Chase) into the controversies. McDevitt does a good job writing popular media, the strange position of public intellectual and talk-show favorite, and the way this filters into popular arguments. But with Alex trying to take a nuanced and unsure position and with a lot of talk but little action, it's not the most compelling reading. Coming Home holds to form in balancing a mystery and a second plot. Since the starship problem is understood, it can't be the central mystery of the book. That role is taken by the discovery of communication device from the very early days of space flight, which takes Alex and Chase to Earth for the first time in this series (at least that I can recall). This time, the search is for a legendary trove of historical artifacts that was moved from a space flight museum in Florida when the ocean rose to cover the state. From there, its location was lost in the middle of a general economic collapse called the Time of Troubles that destroyed most of Earth's governmental systems (and, apparently rather more importantly to McDevitt, the space program). Anyone who has gotten this far in the series will know the standard problem with McDevitt's futures: they're indistinguishable from the 1960s except that they have flying cars. There is a tiny break from that tradition here, since climate change has clearly happened to Earth, covering Florida with the ocean and shifting the major cities north. But the sense of deep history that McDevitt is trying for in this series doesn't work: I just don't believe as much time has gone by as the story claims. He does offer an explanation for why technology has been stagnant for apparently millennia, but it's just a contention that science ran out of more things to discover due to authorial fiat and is now just a matter of engineering and step-wise refinement. (I think the science behind the disappearing starships happening in this very same book undermines that contention considerably.) Even if one can put that aside, Earth is, well, boring. This is partly an intriguing stylistic choice by McDevitt: Earth is intended to be just one more world. It might have a longer history than many other human-occupied worlds, but history is so long everywhere that this only matters to a few people like Alex and Chase. The choice makes sense, but it doesn't make a good story. And there are other things that I flatly didn't believe, such as the supposed isolation of Earth from the communication network of Alex's home world of Rimway for... no apparent reason other than that different communication networks don't talk to each other except via, essentially, letters. Even if one is willing to ignore the mysterious failure of forward progress in technology, this makes no social or engineering sense given the capabilities already shown in the series. I found the main mystery at best mildly interesting. McDevitt does a good job showing the research and investigation process, with all its tedium and dead ends, but I wasn't as invested in the search as he wanted me to be. The endless space boosterism started getting on my nerves, as it so often does in science fiction of a certain type, and I had a much harder time swallowing McDevitt's Earth than his fictional Rimway. I will give him credit for a surprisingly affecting conclusion of the main mystery, but the missing starship subplot putters to an undistinguished end. I think this series is running out of steam. It's become increasingly formulaic, and the characters, like McDevitt's future technology, have stopped developing. I was hoping the reunion foreshadowed since Firebird would shake things up, but at least in this book it doesn't. Maybe it will in subsequent books, but I'm starting to question whether I really want to keep reading. Rating: 5 out of 10

Kevin Avignon: Tech questions 11-16: Artificial intelligence

11. Why use a genetic algorithm instead of a backpropagation algorithm to train a neural net ? 12. What is the difference between a support vector machine (SVM) and an artificial neural network (ANN) ? 13. What s a Naives Bayes classifier ? 14. What is the difference between supervised and unsurpervised learning 15. What is Continue reading Tech questions 11-16: Artificial intelligence

Thadeu Lima de Souza Cascardo: Debian on old Linux versions

On recent posts, I mentioned that I have a Chromebook, and that I would like to run Debian on devices that ship with old Linux versions. The Samsung ARM Chromebook is such a device, it has Linux 3.4, and that's still what I am running on it most of the time. After an upgrade of Debian, systemd stopped working, and it took me some time before I could look into it. In order to boot, I had to temporarily use System V init. The bug involves the use of new interfaces, bugs in such interfaces, and how versioning would not be a solution to such cases. Cases like this are not common, so it's no excuse to doing the right thing when developing software, like considering portability, API and ABI maintenance and not bundle. But they expose some of the challenges when trying to support different OSes on top of old versions of Linux, or maybe even new versions. The new version of systemd included in Debian Jessie uses a feature of Linux of checking the mount ID of a file by inspecting the mnt_id line in the fdinfo files. fdinfo files are not that new, they have been present since 2007, Linux 2.6.22. The mnt_id line, however, is from Linux 3.15, from 2014. So, a fairly new feature. But systemd falls back to other methods if the feature is not present. However, during the last few weeks of development of Linux 3.4, a bug was introduced to fdinfo handling, which will cause its access to fail in a way that will cause systemd to halt. It simply will refuse to mount the most basic filesystems and not proceed. The bug was fixed not much longer than two weeks after that, but that window of time was enough to have it on a shipped product, one that was not using systemd, let alone one that required a feature not yet present on Linux. But now I wanted to run this new systemd on this old Linux version. Being too early in the boot process, systemd even ignored some of the debug options and I had to resort to other methods of debugging. As I am running a kernel I built by myself, it wasn't hard for me to have a fixed kernel up and running after I found out the problem. Unfortunately, not everyone will be able to do it by themselves. And the point of getting different OSes working on these many varied devices is scaling. If every device needs to be tested, we lose this scalability. The other problem I found was that this old Linux version didn't load firmware files by itself, and requested help from userspace, which used to be the job of udev. Well, udev now does not support loading firmware, and the kernel must do it by itself. I managed to backport that feature too. But now, it sounds like I should get upstream support for this device. Unfortunately, this means not working on the scalability problem, but going back to get upstream support for a lot of devices out there, which is very hard to scale without the necessary people to do the work. I am certainly going to do that, because it's the right thing to do. But not as many people will benefit from that. But I think it has been interesting to look into the possible problems we might find when trying to make Debian and other OSes working on old Linux versions. I know even older Debian versions won't boot fine on Linux 2.6.32, one of the LTS versions of Linux. I have one other device which runs on it, and I am also working on getting better upstream support for it. Let's see if I can get some news on that soon.

Lisandro Dami n Nicanor P rez Meyer: Upcoming KDEPIM changes in unstable (KMail, Kontact, KOrganizer, etc)

For those who care about kdepim (kmail, kontact, korganizer, etc)

Currently the latest version of kdepim is available in experimental. According to our limited tests it's working way better than kdepim 4.14 (more stable, more performant, less bugs). However migrating from one to the other is not a trivial process (distribution wise, hopefully not for our users).

Among the drawbacks in the new kdepim: knode, ktimetracker and kjots were dropped from the official kdepim components. kjots is now an independent project, not tied to the kdepim release cycle. But more importantly, knode and ktimetracker are not maintained upstream any more, we are temporarily still shipping the old KDE 4 versions, but we will drop them after stretch unless they get new upstream maintainers.

To iron out the wrinkles that are surely still there, we are now planning to start a transition for kdepim, effectively blocking all kdepim related packages in unstable until the transition is complete. This will allow us to keep the current kdepim in testing unchanged until kdepim 16.04 is ready to migrate fully to testing.

If you want to test the new kdepim versions right now, please use the version in experimental, as uploading all the packages to unstable will take some time until there is a working kdepim in unstable (mixing experimental and the unstable uploads should be fine).

If you depend on having a working kdepim, please avoid installing the new kdepim packages that will be landing in unstable in the following days, until all the components are available. We expect this will take a couple of weeks, we will post another entry when the packages are ready in unstable.

A list of the binary packages involved in the transition can be found [here].

If you find issues in the new packages, please let us know either via irc in #debian-kde, the kde mailing list debian-kde@lists.debian.org, or send us a bug report (please make sure that it wasn't reported before).

We'll send an updated note when kdepim is fully uploaded to unstable.

Happy hacking,

The Debian Qt/KDE Team.

2 July 2016

Jonathan Carter: So, that was DebCamp16!

Picture: Adrian Frith

University of Cape Town, host location to DebConf 16. Picture: Adrian Frith

What an amazingly quick week that was Our bid to host DebConf in Cape Town was accepted nearly 15 months ago. And before that, the bid itself was a big collective effort from our team. So it s almost surreal that the first half of the two weeks of DebCamp/DebConf is now over. Things have been going really well. The few problems we ve had so far were too small to even mention. It s a few degrees colder than it usually is this time of the year and there s already snow on the mountains, so Cape Town is currently quite chilly.
Hacking by the fire at the sports club

Gathering some heat by the fire at the sports club while catching up to the world the day before it all started.

All Kinds of Quality Time I really enjoyed working with the video team last year, but this year there was just 0 time for that. Working on the orga team means dealing with a constant torrent of small tasks, which is good in its own way because you get to deal with a wide variety of Debian people you might not usually get to interact with, but video team problems are more fun and interesting. Next year I hope to do a lot more video work again. If you re at DebConf over the next week, I can highly recommend that you get involved!
Video team hacking away at problems

Video team members hacking away at problems late at night during DebCamp

The first time I met Debian folk was early in 2004. I worked at the Shuttleworth Foundation as Open Source Technical Co-ordinator at the time, and Mark Shuttleworth had them over for one of the early Ubuntu sprints in Canonical s early days. I was so intimidated by them back then that I could hardly even manage to speak to them. I was already a big free software fan before working there, but little did I even dream to think that I would one day be involved in a project like Ubuntu or Debian. My manager back then encouraged me to go talk to them and get involved and become a Debian Developer and joked that I should become highvoltage@debian.org. I guess that was when the initial seeds got planted and since then I ve met many great people all over the world who have even became friends during UDS, DebConf, BTS and other hackfests where Debianites hang out. It gave me a really nice warm feeling to have all these amazing, talented and really friendly people from all over coming together in this little corner of the world to work together on projects that I think are really important.
Finding a warm space to work in the Happy Feet hack lab

Finding a warm space to work in the Happy Feet hack lab

Oh the Chicken Back at DebConf12, someone (I don t remember the exact history) brought a rubber chicken to DebConf who was simply called Pollito ( chicken in Spanish). Since then the chicken has grown into somewhat of a mascot for DebConf. Back in 2012 I already imagined that if we would ever host a DebConf, I d make a little of picture book story about Pollito. Last year after DC15, when bringing Pollito over, I created a little story called Pollito s first trip to Africa . I was recovering from flu while putting that together and didn t spend much time on it, but it turned out to be somewhat of a hit. I was surprised to see it in the #debconf topic ever since I posted it :) We gave a tour of the campus on the first and second days and it was quite time consuming and there was no way we could do it every day for the rest of DebCamp, so on the 2nd day I smacked together a new rush job called Pollito s Guide to DC16 . The idea was that newcommers could use it as a visual guide and rely on others who have been there for a while if they get stuck. I wish I had the time to make it a lot nicer, but I think the general idea is good and next year we can have a much nicer one that might not be quite as Pollito focused.
Pollito's Guide to DC16

Pollito s Guide to DC16

Debian Maintainer After all these years, I finally sat down and applied to become a Debian Maintainer, and the application was successful (approved yesterday \o/). Now just for the wait until my key is uploaded to the keyring. I haven t yet had time to properly process this but I think once the DebConf dust settles and I had some time to recover, I will be ecstatic. Some actual DebCampy work Everywhere I go, I see people installing a bunch of GNOME extensions on their Debian GNOME desktops shortly after installation using http://extensions.gnome.org/ (I noticed this even at DebCamp!). A few months ago I thought that it s really about time someone package up some of the really popular ones. So I started to put together some basic packaging for AIMS Desktop around a month ago. During the last few days of DebCamp, things were going well enough with the organisational tasks that I had some time to do some actual packaging work and improve these so that they re ready for upload to the Debian archives. The little DebCamp time I had ended up being my very own little extension fest :) I worked on the following packages which are ready for upload: I worked on the following packages which still need minor work, might be able to get them in uploadable state by the end of DebConf: The actual packaging of GNOME extensions is actually pretty trivial. It s mostly source-only JavaScript with some CSS and translations and maybe some gsettings schemas and dialogs. Or at least, it would be pretty trivial, but many extensions are without licenses, contain embedded code (often JavaScript) from other projects, or have no usable form of upstream tarball, to name a few of the problems. So I ve been contacting the upstream authors of these packages where there have been problems, and for the most part they ve been friendly and pretty quick to address the problems. So that s it, for now. I couldn t possibly sum up the last week and everything that lead up to it in a single blog post. All I can really say is thank you for letting me be a part of this very special project!

Guido G nther: Debian Fun in June 2016

Debian LTS June marked the fourteenth month I contributed to Debian LTS under the Freexian umbrella. I spent the 8 hours working on these LTS things: Other Debian stuff Besides the usual bunch of libvirt* uploads I addressed several bugs in git-buildpackage, upload pending.

Next.

Previous.