1. A bunch of shell scripts that were written by the DebConf video team and hooked into the penta database. Nobody but DebConf ever used it. It allowed review via an NFS share and a webinterface, and required people to watch .dv files directly from the filesystem in a media player. For this and other reasons, it could only ever be used from the conference itself. If nothing else, that final limitation made it impossible for FOSDEM to use it, but even if that wasn't the case it was still too basic to ever be useful for a conference the size of FOSDEM.
2. A review system used by the CCC "voc" team. I've never actually seen it in use, but I've heard people describe it. It involves a complicated setup of Samba servers, short MPEG transport stream segments, a FUSE filesystem, and kdenlive, which took someone several days to set up as an experiment back at DebConf15. Critically, important parts of it are also not licensed as free software, which to me rules it out for a tool in support of FOSDEM. Even if that wasn't the case, however, I'm still not sure it would be ideal; this system requires intimate knowledge of how it works from its user, which makes it harder for us to crowdsource the review to the speaker, as I had planned to.
3. Veyepar. This one gets many things right, and we used it for video review at DebConf from DebConf14 onwards, as well as FOSDEM 2014 (but not 2015 or 2016). Unfortunately, it also gets many things wrong. Most of these can be traced back to the fact that Carl, as he freely admits, is not a programmer; he's more of a sysadmin type who also manages to cobble together a few scripts now and then. Some of the things it gets wrong are minor issues that would theoretically be fixable with a minimal amount of effort; others would be more involved. It is also severely underdocumented, and so as a result it is rather tedious for someone not very familiar with the system to be able to use it. On a more personal note, veyepar is also written in the wrong language, so while I might have spent some time improving it, I ended up starting from scratch.

1. A major focus has been on making the review form be as easy to use as possible. While there is still room for improvement (and help would certainly be welcome in that area from someone with more experience in UI design than me), I think the SReview review form is much easier to use than the veyepar one (which has so many options that it's pretty hard to understand sometimes).
2. SReview assumes that as soon as there are recordings in a given room sufficient to fill all the time that a particular event in that room was scheduled for, the whole event is available. It will then generate a first rough cut, and send a notification to the speaker in question, as well as the people who organized the devroom. The reviewer will then almost certainly be required to request a second (and possibly third or fourth) cut, but I think the advantage of that is that it makes the review workflow be more intuitive and easier to understand.
3. Where veyepar requires one or more instances of per-state scripts to be running (which will then each be polling the database and just start a transcode or cut or whatever script as needed), SReview uses a single "dispatch" script, which needs to be run once for the whole system (if using an external scheduler) or once per core that may be used (if not using an external scheduler), and which does all the database polling required. The use of an external scheduler seemed more appropriate, given that things like gridengine exist; gridengine is a job scheduler which allows one to submit a job to be ran on any node in a cluster, along with the resources that this particular job requires, and which will then either find an appropriate node to run the job on, or will put the job in a "pending" state until the required resources can be found. This allows me to more easily add extra encoding capacity when required, and allows me to also do things like allocate less resources to a particular part of the whole system, even while jobs are already running, without necessarily needing to abort jobs that might be using those resources.

"That ending was there from the get-go," [director Damien Chazelle] told CNN in a recent interview. "I think I just have a thing about love stories where the lovers don't wind up together at the end; I find it very romantic."

"I think there's a reason why most of the greatest love stories in history don't end with happily ever after," Chazelle said. "To me, if you're telling a story about love, love has to be bigger than the characters." Chazelle sees Mia and Sebastian's love as a "third character" and something that "lives on." "[The ending gives] you that sense that even if the relationship itself might be over in practical terms, the love is not over," he said. "The love lasts, and I think that's just a beautiful kind of thing."

1. An earlier fight between Mia and Sebastian points to the fact that they're both very dedicated to their careers, and this means it's hard for them to stay together if they both chase their dream. He has to be on tour, and she has to rehearse for her play, so they won't see each other for at least two weeks (in this instance). Later, she calls him and leaves a message that she hasn't seen him in a while (complex scene which ends in another fight, which is very well done). So we see the conflict that seems to say "You can't have a relation of equals; one party has to give up their dream". While this might be partially true in the real world, I don't go to movies to see the real world.
2. After the year-long window into their life, I can't think that either Sebastian or Mia can be really successful without the other; because they are so alike, so passionate about their dreams, that a normal person wouldn't be able to understand and push the other when they need. However, the ending show both Mia and Sebastian quite successful, so one has to wonder: did they make it alone? Sebastian seems so (we don't see a partner for him), Mia unclear, likely not. How did Sebastian get through? What did Mia find in her husband?
3. This is very one-sided, since I'm a man, so bear with me: Sebastian helped Mia through her tough time. Once she got the breakthrough (and they split), she found somebody else, and I have to wonder in what circumstances they met. In the sense that maybe her husband only knew "successful Mia" and not "struggling/aspiring Mia". Her husband seems completely oblivious to all the eye contact between Mia and Sebastian in the club, seems to know Sebastian/about Sebastian not. How deep is their relation?
4. This is still one sided, sorry. When they break up (before Mia leaves for Paris), Sebastian asks "so where do we go from here?". Mia says "Nowhere". He asks once more, she rejects him again. So after one year of mad love and cries and happy moments, he gives up over two sentences? He's been following his dream (proper Jazz) in spite of all downturns in life until then, but he gives up on his real love over this? It doesn't make sense; trying to identify my self with the character, I can't reconcile this scene at all, unless he didn't really love her.

Project structure For a standalone project, vendoring is a must-have¹ as you cannot rely on your dependencies to not introduce backward-incompatible changes. Some packages are using versioned URLs but most of them aren t. There is currently no standard tool to handle vendoring. My personal take is to vendor all dependencies with Glide. It is a good practice to split an application into different packages while the main one stay fairly small. In the hellogopher example, the CLI is handled in the cmd package while the application logic for printing greetings is in the hello package:

.
  cmd/
    hello.go
    root.go
    version.go
  glide.lock (generated)
  glide.yaml
  vendor/ (dependencies will go there)
  hello/
    root.go
    root_test.go
  main.go
  Makefile
  README.md

Down the rabbit hole Let s take a look at the various features of the Makefile.

GOPATH handling Since all dependencies are vendored, only our own project needs to be in the GOPATH:

PACKAGE  = hellogopher
GOPATH   = $(CURDIR)/.gopath
BASE     = $(GOPATH)/src/$(PACKAGE)
$(BASE):
    @mkdir -p $(dir $@)
    @ln -sf $(CURDIR) $@

The base import path is hellogopher, not github.com/vincentbernat/hellogopher: this shortens imports and makes them easily distinguishable from imports of dependency packages. However, your application won t be go get-able. This is a personal choice and can be adjusted with the $(PACKAGE) variable. We just create a symlink from .gopath/src/hellogopher to our root directory. The GOPATH environment variable is automatically exported to the shell commands of the recipes. Any tool should work fine after changing the current directory to $(BASE). For example, this snippet builds the executable:

.PHONY: all
all:   $(BASE)
    cd $(BASE) && $(GO) build -o bin/$(PACKAGE) main.go

Vendoring dependencies Glide is a bit like Ruby s Bundler. In glide.yaml, you specify what packages you need and the constraints you want on them. Glide computes a glide.lock file containing the exact versions for each dependencies (including recursive dependencies) and download them in the vendor/ folder. I choose to check into the VCS both glide.yaml and glide.lock files. It s also possible to only check in the first one or to also check in the vendor/ directory. A work-in-progress is currently ongoing to provide a standard dependency management tool with a similar workflow. We define two rules²:

GLIDE = glide
glide.lock: glide.yaml   $(BASE)
    cd $(BASE) && $(GLIDE) update
    @touch $@
vendor: glide.lock   $(BASE)
    cd $(BASE) && $(GLIDE) --quiet install
    @ln -sf . vendor/src
    @touch $@

We use a variable to invoke glide. This enables a user to easily override it (for example, with make GLIDE=$GOPATH/bin/glide).

Using third-party tools Most projects need some third-party tools. We can either expect them to be already installed or compile them in our private GOPATH. For example, here is the lint rule:

BIN    = $(GOPATH)/bin
GOLINT = $(BIN)/golint
$(BIN)/golint:   $(BASE) #  
    go get github.com/golang/lint/golint
.PHONY: lint
lint: vendor   $(BASE) $(GOLINT) #  
    @cd $(BASE) && ret=0 && for pkg in $(PKGS); do \
        test -z "$$($(GOLINT) $$pkg   tee /dev/stderr)"   ret=1 ; \
     done ; exit $$ret

As for glide, we let the user a chance to override which golint executable to use. By default, it uses a private copy. But a user can use its own copy with make GOLINT=/usr/bin/golint. In , we have the recipe to build the private copy. We simply issue go get³ to download and build golint. In , the lint rule executes golint on each package contained in the $(PKGS) variable. We ll explain this variable in the next section.

Working with non-vendored packages only Some commands need to be provided with a list of packages. Because we use a vendor/ directory, the shortcut ./... is not what we expect as we don t want to run tests on our dependencies⁴. Therefore, we compose a list of packages we care about:

PKGS = $(or $(PKG), $(shell cd $(BASE) && \
    env GOPATH=$(GOPATH) $(GO) list ./...   grep -v "^$(PACKAGE)/vendor/"))

If the user has provided the $(PKG) variable, we use it. For example, if they want to lint only the cmd package, they can invoke make lint PKG=hellogopher/cmd which is more intuitive than specifying PKGS. Otherwise, we just execute go list ./... but we remove anything from the vendor directory.

Tests Here are some rules to run tests:

TIMEOUT = 20
TEST_TARGETS := test-default test-bench test-short test-verbose test-race
.PHONY: $(TEST_TARGETS) check test tests
test-bench:   ARGS=-run=__absolutelynothing__ -bench=.
test-short:   ARGS=-short
test-verbose: ARGS=-v
test-race:    ARGS=-race
$(TEST_TARGETS): test
check test tests: fmt lint vendor   $(BASE)
    @cd $(BASE) && $(GO) test -timeout $(TIMEOUT)s $(ARGS) $(PKGS)

A user can invoke tests in different ways:

• make test runs all tests;
• make test TIMEOUT=10 runs all tests with a timeout of 10 seconds;
• make test PKG=hellogopher/cmd only runs tests for the cmd package;
• make test ARGS="-v -short" runs tests with the specified arguments;
• make test-race runs tests with race detector enabled.

Tests coverage go test includes a test coverage tool. Unfortunately, it only handles one package at a time and you have to explicitely list the packages to be instrumented, otherwise the instrumentation is limited to the currently tested package. If you provide too many packages, the compilation time will skyrocket. Moreover, if you want an output compatible with Jenkins, you ll need some additional tools.

COVERAGE_MODE    = atomic
COVERAGE_PROFILE = $(COVERAGE_DIR)/profile.out
COVERAGE_XML     = $(COVERAGE_DIR)/coverage.xml
COVERAGE_HTML    = $(COVERAGE_DIR)/index.html
.PHONY: test-coverage test-coverage-tools
test-coverage-tools:   $(GOCOVMERGE) $(GOCOV) $(GOCOVXML) #  
test-coverage: COVERAGE_DIR := $(CURDIR)/test/coverage.$(shell date -Iseconds)
test-coverage: fmt lint vendor test-coverage-tools   $(BASE)
    @mkdir -p $(COVERAGE_DIR)/coverage
    @cd $(BASE) && for pkg in $(PKGS); do \ #  
        $(GO) test \
            -coverpkg=$$($(GO) list -f '  join .Deps "\n"  ' $$pkg   \
                    grep '^$(PACKAGE)/'   grep -v '^$(PACKAGE)/vendor/'   \
                    tr '\n' ',')$$pkg \
            -covermode=$(COVERAGE_MODE) \
            -coverprofile="$(COVERAGE_DIR)/coverage/ echo $$pkg   tr "/" "-" .cover" $$pkg ;\
     done
    @$(GOCOVMERGE) $(COVERAGE_DIR)/coverage/*.cover > $(COVERAGE_PROFILE)
    @$(GO) tool cover -html=$(COVERAGE_PROFILE) -o $(COVERAGE_HTML)
    @$(GOCOV) convert $(COVERAGE_PROFILE)   $(GOCOVXML) > $(COVERAGE_XML)

First, we define some variables to let the user override them. We also require the following tools (in ):

• gocovmerge merges profiles from different runs into a single one;
• gocov-xml converts a coverage profile to the Cobertura format;
• gocov is needed to convert a coverage profile to a format handled by gocov-xml.

The rules to build those tools are similar to the rule for golint described a few sections ago. In , for each package to test, we run go test with the -coverprofile argument. We also explicitely provide the list of packages to instrument to -coverpkg by using go list to get a list of dependencies for the tested package and keeping only our owns.

Final result While the main goal of using a Makefile was to work around GOPATH, it s also a good place to hide the complexity of some operations, notably around test coverage. The excerpts provided in this post are a bit simplified. Have a look at the final result for more perks!

---

1. In Go, vendoring is about both bundling and dependency management. As the Go ecosystem matures, the bundling part (fixed snapshots of dependencies) may become optional but the vendor/ directory may stay for dependency management (retrieval of the latest versions of dependencies matching a set of constraints).
2. If you don t want to automatically update glide.lock when a change is detected in glide.yaml, rename the target to deps-update and make it a phony target.
3. There is some irony for bad mouthing go get and then immediately use it because it is convenient.
4. I think ./... should not include the vendor/ directory by default. Dependencies should be trusted to have run their own tests in the environment they expect them to succeed. Unfortunately, this is unlikely to change.

• Packaged latest Gramps 4.2.5 release for Debian so that it will be part of the Stretch release.
• Package latest abcmidi release so it too would be part of Stretch. The upstream author had changed his website, so it took a while to locate a tarball.
• Tested my latest patches to convert Cree.py to Qt5, but found another Qt4 Qt5 change to take into account (SIGNAL function). I ran out of time to fully investigate that one, before Creepy was booted out of testing again. I am seriously considering the removal of Cree.py from Debian, as the upstream maintainer does not seem very active any more, and I am a little tired of being upstream for a project that I don t actually use myself. It was only because it was a reverse dependency of osm-gps-map that I originally got involved.
• Started preparing a Gramps 5.2.5 backport for Jessie, but found that the tests I enabled in unstable were failing in the Jessie build. I need to investigate this further.

• Announced the Ubuntu Studio 16.02.2 point release date on the Ubuntu Studio mailing lists asking for testers. The date subsequently got put back to February the 9th.
• Upgraded my Ubuntu Studio machine from Wily to Xenial.

• Resurrected my old Drupal Gammon One Name Study website. I used Drupal VM to get the site going again, before transferring it to the new webhost. It was originally a Drupal 7 site, and I did not have the required versions of Ansible & Vagrant on my Ubuntu Xenial machine, so the process was quite involved. I will blog about that separately, as it may be a useful lesson for others. As part of that, I started on a backport of vagrant, but found a bug which I need to follow up on.
• Also managed to extract my old WordPress blog posts from the same machine that had the failed Drupal instance, and import them into this blog. I also learnt some stuff in that process that I will blog about at some point.

• Convert Cree.py from QT4 to QT5 to allow it to re-enter Stretch. Failed

• Keep an eye on the Release Critical bugs list, and see if I can help fix any.

• Finish the Gramps 5.2.5 backport for Jessie.
• Package all the latest upstream versions of my Debian packages, and upload them to Experimental to keep them out of the way of the Stretch release.
• Begin working again on all the new stuff I want packaged in Debian.

• Finish the ubuntustudio-lightdm-theme, ubuntustudio-default-settings transition including an update to the ubuntustudio-meta packages. Still to do (actually started today)
• Reapply to become a Contributing Developer. Still to do
• Start working on an Ubuntu Studio package tracker website so that we can keep an eye on the status of the packages we are interested in. Started
• Start testing & bug triaging Ubuntu Studio packages. Still to do
• Test Len s work on ubuntustudio-controls Still to do

• Try and resurrect my old Gammon one-name study Drupal website from a backup and push it to the new GoONS Website project. Done
  
• Give JMRI a good try out and look at what it would take to package it. In progress
• Also look at OpenPLC for simulating the relay logic of real railway interlockings (i.e. a little bit of the day job at home involving free software fun!).

Changes in version 0.3.0 (2017-02-03)

• The curl binary use was replaced by use of the curl package; several new helper functions added (PRs #30, #36 by Seth closing #29)
• Use of RJSONIO was replaced by use of jsonlite (PR #32 by Seth closing #31)
• A new function pbSetup was added to aid creating the resource file (PRs #34, #37 by Seth and Dirk)
• The package intialization was refactored so that non-loading calls such as RPushbullet::pbPost(...) now work (#33 closing #26)
• The test suite was updated and extended
• The Travis script was updated use run.sh
• DESCRIPTION, README.md and other files were updated for current R CMD check standards
• Deprecated parts such as 'type=address' were removed, and the documentation was updated accordingly.
• Coverage support was added (in a 'on-demand' setting as automated runs would need a Pushbullet API token)

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

QSoas> generate-buffer -2 2

QSoas> generate-buffer -10 10 sin(x)

QSoas> generate-buffer -2 2 sin(PI*x)**(number+1) /number=30 /style=red-to-blue

Working with Date, Calendar, SimpleDateFormat in Android. As I mentioned In my last blog, I would talk about how I used Calendar and Date classes for the user to designate silent mode by setting time constraints and weekdays, in Lumicall. Date class to used to interpret dates as year, month, day, hour, minute, and second values. I had to compare whether the current time falls between Start Time and End Time specified by the user. So that, silent mode can be enabled within that time frame. I used Calendar Class to get the current hour in 24-Hour format and minute.

 Calendar now = Calendar.getInstance();
 int hour = now.get(Calendar.HOUR_OF_DAY);  
 int minute = now.get(Calendar.MINUTE);

SimpleDateFormat simpleDateFormat= new SimpleDateFormat( HH:mm , Locale.ENGLISH);
Date currentTime = parseDate(hour + ":" + minute)
Date timeCompareOne = parseDate(hhStart + : +mmStart);  
Date timeCompareTwo = parseDate(hhEnd + : +mmEnd);

if(timeCompareOne.before(currentTime) && timeCompareTwo.after(currentTime))
 
Switch on the silent mode;
 

public Date parseDate(String date)  
  
try 
   
return inputParser.parse(date);
  
catch (java.text.ParseException e)  
   
return new Date(0);  
   
 

Calendar calendar = Calendar.getInstance(); 
int day = calendar.get(Calendar.DAY_OF_WEEK); 

Weekdays compared too!

Changes

• gitk: colour of remote refs
• https-everywhere: Update Debian rules
• check-all-the-things: release, security fix, reset terminal modes, allow running removed checkers, regression fix (quote fix), TODO items (for deep-text-corrector, sblint, decopy, Coala Bear & dangerous Python checks)
• devscripts: fix grep-excuses warning
• autorevision: build correctness, tarball reproducibility (due to gzip & AUTHORS.txt)
• whowatch: parameter correctness (for NULL, int), spelling/grammar/typos, https, remove dead links & restore terminal status on exit
• spelling dictionaries:
  • codespell: recod, undefuned, normaly, uner, buid, stength, privide, decstiption(s), revrese, lightweigh, multible, asbtraction, resulution, meatadata, seriuos, transalte, interractive, timestan, partiton, databas, claculate, patern, substiution, freee, operatation(s), ambigous, clasified, coypright, previlege, gental, bacup & detction
  • lintian: recod, undefuned, uner, buid, stength, privide, dimentional, decstiption(s), revrese, lightweigh, asbtraction, resulution, FTBS, meatadata, seriuos, transalte, interractive, timestan, partiton, databas, claculate, patern, substiution, freee, operatation(s), previlege, gental, bacup & detction
• Debian timeline: latest bug milestones
• Debian bits: FOSDEM draft fixes
• Planet Debian derivatives: add Netrunner & update BlankOn logo
• Debian buildd website: plain text logs (1 2 3)
• Debian uscan multi-redirector: add github package.json/cmake checker & remove gitorious
• Debian packages website: update manual pages patch to use https, merge patches (1 2)
• Debian website: fix security Makefiles for DLAs (for 2017, 2016, 2015, 2014), derivatives (wording/formatting fixes 1, 2), build by default), link fixes (for CD brokenness, stability, gitweb to cgit)
• Debian wiki pages: AlejandroRios, ChrootOnAndroid, CopyrightReviewTools, CrossCompiling, CrossGrading, DebianBootstrap, DebianDay, (2017), DebianEvents (Asia, oc) DebianScience, DebianWiki/Browsing, dedup.debian.net, Derivatives/Census (AstraLinux, BlankOn, Netrunner, SalentOS, SerbianLinux, Symbiosis, Template), EmbeddedCodeCopies, ExternalEntities, Fonts, fr/GraphicsCard, fr/Intel HD Graphics, FrontPage, gobby.debian.org, HP/ProLiant, Ideas, InstallingDebianOn, TurrisOmnia (1 2), InterWikiMap, josch/notes, LVM, Merchandise/BoFDebConf10, Mobile (1 2), NewArchiveSections, PaulWise/InterestingSoftware, PortTemplate, ppc64el, PressCoverage2017, PressCoverage, redmine, ReproducibleBuilds/History, Services/Debian Packages, SponsorChecklist, Sprints (2017/DebianMed2017 (1 2)), SystemBuildTools, systemd, Teams/Dpkg/FAQ, ThisWeekInDebian, WhyDebian, Year
• File Formats wiki pages: ACE, File_identification_software, File_command
• Debian package uploads: autorevision 1.20-1, check-all-the-things 2017.01.15 & openchange 1:2.2-6+deb8u1

Issues

• Security migration for check-all-the-things
• GPL violations due to embedded copies of Liberation Fonts in emscripten, freedink, gargoyle-free, gcstar, manaplus, minetest, pcs & zygrib
• Outdated embedded unicode-data copies in boost1.62 & boost1.63
• Crash in liferea
• Regression in coreutils date
• Missing conffile removal in dnssec-trigger & xtightvncviewer
• gitorious redirector usage in fgrun & spectacle
• Annoying issues in hexchat autorejoin, totem & a podcast & gdb messages
• Cosmetic issues in parcimonie menu, gitk colours & aptitude debtags
• Features in duck, apt-file, needrestart, packages.debian.org & aptitude
• An already implemented feature in needrestart

Review

• Spam: report spam in 6 Debian bugs, 132 Debian mails and one LWN comment
• Patches: point out extraneous whitespace changes in a codespell PR
• Debian packages: reviewed and sponsored fsprotect 1.0.7
• Debian wiki: RecentChanges for the month, feedback on InstallDebianWithoutLiveCD article
• Debian screenshots:
  • Approved screenshots of ngraph-gtk lightdm-gtk-greeter-settings kalgebra qtile patat toilet sagemath (2) w3c-markup-validator pentobi pentobi-kde-thumbnailer zygrib (2) sauerbraten kmail aiscm (5) codeblocks lxqt libreoffice-help-es inkscape synaptic thunar gimp midori filezilla libreoffice pluma qupzilla gnome-2048 simplescreenrecorder gerbv keepassx gcstar confclerk onionshare blockout2 subuser dosbox zsnes dosemu lmarbles klickety geda-gattrib katomic kiki-the-nano-bot freedm frogatto (2)
  • Approved removal of screenshots: seaview screenshot contained advertising, mupen64plus/mupen64plus-audio-all were weird screenshots with multiple OS windows overlaid & mkgmap was a screenshot of the OSM wiki instead of the software
  • Rejected screenshots: gccgo looked like a Thai mobile phone screenshot, python-stem was a screenshot for OPENDIME USB, seaview was downloaded from elsewhere and not an authentic screenshot & fbreader contained non-free ebook contents

Administration

• Debian: reboot 1 non-responsive VM, redirect 2 users to support channels, redirect 1 contributor to xkb upstream, redirect 1 potential contributor, redirect 1 bug reporter to mirror team, ping 7 folks about restarting processes with upgraded libs, manually restart the sectracker process due to upgraded libs, restart the package tracker process due to upgraded libs, investigate failures connecting to the XMPP service, investigate /dev/shm issue on abel.d.o, clean up after rename of the fedmsg group.
• Debian mentors: lintian/security updates & reboot
• Debian packages: deploy 2 contributions to the live server
• Debian wiki: unblacklist 1 IP address, whitelist 10 email addresses, disable 18 accounts with bouncing email, update email for 2 accounts with bouncing email, reported 1 Debian member as MIA, redirect 1 user to support channels, add 4 domains to the whitelist.
• Reproducible builds: rescheduled Debian pyxplot:amd64/unstable for themill.
• Openmoko: security updates & reboots.

Debian derivatives

• Send the annual activity ping mail.
• Happy new year messages on IRC, forward to the list.
• Note that SerbianLinux does not provide source packages.
• Expand URL shortener on SerbianLinux page.
• Invite PelicanHPC, Netrunner, DietPi, Hamara Linux (on IRC), BitKey to the census.
• Add research publications link to the census template
• Fix Symbiosis sources.list
• Enquired about SalentOS downtime
• Fixed and removed some 404 BlankOn links (blog, English homepage)
• Fixed changes to AstraLinux sources.list
• Welcome Netrunner to the census

Sponsors I renewed my support of Software Freedom Conservancy. The openchange 1:2.2-6+deb8u1 upload was sponsored by my employer. All other work was done on a volunteer basis.

A new desktop: Intel NUC devices After reading up on Jeff Atwood's blog and especially his article on the scooter computer, I have discovered a whole range of small computers that could answer my need for a faster machine in my office at a low price tag and without taking up too much of my precious desk space. After what now seems like a too short review I ended up buying a new Intel NUC device from NCIX.com, along with 16GB of RAM and an amazing 500GB M.2 hard drive for around 750$. I am very happy with the machine. It's very quiet and takes up zero space on my desk as I was able to screw it to the back of my screen. You can see my review of the hardware compatibility and installation report in the Debian wiki. I wish I had taken more time to review the possible alternatives - for example I found out about the amazing Airtop PC recently and, although that specific brand is a bit too expensive, the space of small computers is far and wide and deserves a more thorough review than just finding the NUC by accident while shopping for laptops on System76.com...

Reviving the Stressant project But this, and Atwood's Is Your Computer Stable? article, got me thinking about how to test new computers. It's one thing to build a machine and fire it up, but how do you know everything is actually really working? It is common practice to do a basic stress test or burn-in when you get a new machine in the industry - how do you proceed with such tests? Back in the days when I was working at Koumbit, I wrote a tool exactly for that purpose called Stressant. Since I am the main author of the project and I didn't see much activity on it since I left, I felt it would be a good idea to bring it under my personal wing again, and I have therefore moved it to my Gitlab where I hope to bring it back to life. Parts of the project's rationale are explained in an "Intent To Package" the "breakin" tool (Debian bug #707178), which, after closer examination, ended up turning into a complete rewrite. The homepage has a bit more information about how the tool works and its objectives, but generally, the idea is to have a live CD or USB stick that you can just plugin into a machine to run a battery of automated tests (memtest86, bonnie++, stress-ng and disk wiping, for example) or allow for interactive rescue missions on broken machines. At Koumbit, we had Debirf-based live images that we could boot off the network fairly easily that we would use for various purposes, although nothing was automated yet. The tool is based on Debian, but since it starts from boot, it should be runnable on any computer. I was able to bring the project back to life, to a certain extent, by switching to vmdebootstrap instead of debirf for builds, but that removed netboot support. Also, I hope that Gitlab could provide with an autobuilder for the images, but unfortunately there's a bug in Docker that makes it impossible to mount loop images in Docker images (which makes it impossible to build Docker in Docker, apparently).

Should I start yet another project? So there's still a lot of work to do in this project to get it off the ground. I am still a bit hesitant in getting into this, however, for a few reasons:

1. It's yet another volunteer job - which I am trying to reduce for health and obvious economic reasons. That's a purely personal reason and there isn't much you can do about it.
2. I am not sure the project is useful. It's one thing to build a tool that can do basic tests on a machine - I can probably just build an live image for myself that will do everything I need - it's another completely different thing to build something that will scale to multiple machines and be useful for more various use cases and users.

(A variation of #1 is how everything and everyone is moving to the cloud. It's become a common argument that you shouldn't run your own metal these days, and we seem to be fighting an uphill economic battle when we run our own datacenters, rack or even physical servers these days. I still think it's essential to have some connexion to metal to be autonomous in our communications, but I'm worried that focusing on such a project is another of my precious dead entreprises... ) Part #2 is obviously where you people come in. Here's a few questions I'd like to have feedback on:

1. (How) do you perform stress-testing of your machines before putting them in production (or when you find issues you suspect to be hardware-related)?
2. Would a tool like breakin or stressant be useful in your environment?
3. Which tools do you use now for such purposes?
4. Would you contribute to such a project? How?
5. Do you think there is room for such a project in the existing ecology of projects) or should I contribute to an existing project?

Any feedback here would be, of course, greatly appreciated.

On Progress and Historical Change [archive]

Is progress inevitable? Is it natural? Is it fragile? Is it possible? Is it a problematic concept in the first place? Many people are reexamining these kinds of questions as 2016 draws to a close, so I thought this would be a good moment to share the sort-of zoomed out discussions the subject that historians like myself are always having.

A projection of the ISS live feed as a night light [archive]

I always wanted the ISS live feed as a "night light" / ambiance to fall asleep to on my ceiling how to build a "night light" that is actually a small video projector projecting the ISS live feed

Vatican Climate Forest [archive]

The Vatican Climate Forest, to be located in the B kk National Park, Hungary, was donated to the Vatican City by a carbon offsetting company. The forest is to be sized to offset the carbon emissions generated by the Vatican during 2007. The Vatican's acceptance of the offer, at a ceremony on July 5, 2007, was reported as being "purely symbolic", and a way to encourage Catholics to do more to safeguard the planet. No trees have been planted under the project and the carbon offsets have not materialised. I'm fascinated by how purely symbolic "purely symbolic" can be.

• Created github-sync, a tool to mirror arbitrary repositories onto GitHub.
• Submitted two pull requests to the word-wrap Chrome browser extension that adds the ability to wrap text via the right-click context menu:
  • Support dynamically-added <textarea> elements in "rich" Javascript applications such as mail clients, etc. (#2)
  • Avoid an error message if no "editable" has been selected yet. (#1)
• Submitted a pull request to wordwarvi (a "retro-styled old school side-scrolling shooter") to ensure the build is reproducible. (#5)
• Filed a pull request with the yard Ruby documentation tool to ensure the generated output is reproducible. (#1048)
• Made some improvements to travis.debian.net, my hosted service for projects that host their Debian packaging on GitHub to use the Travis CI continuous integration platform to test builds on every code change:
  • Merged a pull request from Evgeni Golov to allow for skipped tests. (#39)
  • Add logging when running autopkgtests. (commit)
• Merged a pull request from jwilk for python-fadvise my Python interface to the posix_fadvise(2) interface to predeclare an pattern for accessing data. (#6)
• Filed an issue against the redis key-value database regarding build failures on non-x86 architectures. (#3768)

As children use digital media to learn and socialize, others are collecting and analyzing data about these activities. In school and at play, these children find that they are the subjects of data science. As believers in the power of data analysis, we believe that this approach falls short of data science s potential to promote innovation, learning, and power. Motivated by this fact, we have been working over the last three years as part of a team at the MIT Media Lab and the University of Washington to design and build a system that attempts to support an alternative vision: children as data scientists. The system we have built is described in a new paper Scratch Community Blocks: Supporting Children as Data Scientists that will be published in the proceedings of CHI 2017. Our system is built on top of Scratch, a visual, block-based programming language designed for children and youth. Scratch is also an online community with over 15 million registered members who share their Scratch projects, remix each others work, have conversations, provide feedback, bookmark or love projects they like, follow other users, and more. Over the last decade, researchers including us have used the Scratch online community s database to study the youth using Scratch. With Scratch Community Blocks, we attempt to put the power to programmatically analyze these data into the hands of the users themselves. To do so, our new system adds a set of new programming primitives (blocks) to Scratch so that users can access public data from the Scratch website from inside Scratch. Blocks in the new system gives users access to project and user metadata, information about social interaction, and data about what types of code are used in projects. The full palette of blocks to access different categories of data is shown below.

Project metadata

User metadata

Site-wide statistics

Simple demonstration of Scratch Community Blocks

I was trying to think of something that somebody hadn t done yet, and I didn t see that. And also I really like to do art on Scratch and that was a good opportunity to use that and mix the two [art and data] together.

Doughnut visualization

Ice-cream visualization

Data-driven doll dress up

PRIMARY_UID=$(whiptail --inputbox "$PRIMARY_UID_TEXT_EN" 8 78 --title "$PRIMARY_UID_TITLE_EN" 3>&1 1>&2 2>&3)

msgid "EXPIRY_TEXT"
msgstr ""
"Please specify how long the key should be valid.\n"
"\t   0 = key does not expire\n"
"\t <n> = key expires in n days\n"
"\t<n>w = key expires in n weeks\n"
"\t<n>m = key expires in n months\n"
"\t<n>y = key expires in n years"
msgid "PRIMARY_UID_TITLE"
msgstr "Primary UID"

mkdir -p $HOME/project/locale/en_US/LC_MESSAGES/
msgfmt -o $HOME/project/locale/en_US/LC_MESSAGES/ui-strings.mo po/en.po

whiptail_yesno()  	
	whiptail --yesno "$(gettext $1)" $DIMENS --title "$(gettext $2)"
	return $?
if whiptail_yesno "ENCR_SUBKEY_YESNO_TEXT" "ENCR_SUBKEY_YESNO_TITLE"; then
...

export TEXTDOMAINDIR=$HOME/gpg-helper-scripts/locale
export TEXTDOMAIN=ui-strings
export LANG=en_US.UTF-8

gpg-helper-scripts/
  gpg/
       create_keys.sh
       add_uids.py
  whiptail/
       main_menu.sh
       gen_keys.sh
       smartcard_init.sh
       whiptail_helper.sh
  po/
       en.po
  locale/
       en_US/LC_MESSAGES/ui-strings.mo
  details/
       gpg-algos
       smartcard-workflow
  init.sh
  README.md

whiptail_password()  
	__resultvar=$1	
	result=$(whiptail --passwordbox "$(gettext $2)" $DIMENS --title "$(gettext $3)" 3>&1 1>&2 2>&3)
	eval $__resultvar="'$result'"
 

[18:37:06] I d be more than happy myself to apply for an US tourist not transit visa when I really need it, as a transit visa isn t really useful, is just as costly as a tourist visa, and nearly as difficult to get as a tourist visa
[18:37:40] I m not entirely sure I wish to transit through the US in its Trumplandia incarnation either
[18:38:07] likely to be more difficult and unfun