Even though I spend more time staring at the screen than typing, there are times when I - after lots and lots of prior brain work - sit down and start typing, a lot. A couple of years ago, I started to feel pain in my wrists, and there were multiple occasions when I had to completely stop writing for longer periods of time. These were situations I obviously did not want repeated, so I started to look for remedies. First, I bought a new keyboard, a TypeMatrix 2300, which while not ergonomic, was a huge relief for my hands and wrists. I also started to learn Dvorak, but that's still something that is kind-of in progress: my left hand can write Dvorak reasonably fast, but my right one seems to be Qwerty-wired, even after a month of typing Dvorak almost exclusively.This keyboard served me well for the past five year or so. But recently, I started to look for a replacement, partly triggered by a Clojure/conj talk I watched. I got as far as assembling a list of keyboards I'm interested in, but I have a hard time choosing. This blog post here serves two purposes then: first to make a clear pros/cons list for myself, second, to solicit feedback from others who may have more experience with any of the options below.Update: There is a [follow up post], with a few more keyboards explored, and a semi-final verdict. Thanks everyone for the feedback and help, much appreciated!Lets start with the current keyboard!TypeMatrix 2030Pros

• The Matrix architecture, with straight vertical key columns has been incredibly convenient.
• Enter and Backspace in the middle, both large: loving it.
• Skinnable (easier to clean, and aids in learning a new layout).
• Optional dvorak skin, and a hardware Dvorak switch.
• The layout (cursor keys, home/end, page up/down, etc) is something I got used to very fast.
• Multimedia keys close by with Fn.
• Small, portable, lightweight - ideal for travel.

Cons

• Small: while also a feature, this is a downside too. Shoulder position is not ideal.
• Skins: while they are a terrific aid when learning a new layout, and make cleaning a lot easier, they wear off quickly. Sometimes fingernails are left to grow too long, and that doesn't do good to the skin. One of my two QWERTY layouts has a few holes already, sadly.
• Not a split keyboard, which is starting to feel undesirable.

SummaryAll in all, this is a keyboard I absolutely love, and am very happy with. Yet, I feel I'm ready to try something different. With my skins aging, and the aforementioned Clojure/conj talk, the desire to switch has been growing for a while now.Desired propertiesThere are a few desired properties of the keyboard I want next. The perfect keyboard need not have all of these, but the more the merrier.

• Ergonomic design.
• Available in Dvorak, or with blank keys.
• Preferably a split keyboard, so I can position the two parts as I see fit.
• Ships to Hungary, or Germany, in a reasonable time frame. (If all else fails, shipping to the US may work too, but I'd rather avoid going through extra hoops.)
• Mechanical keys preferred. But not the loud clicky type: I work in an office; and at home, I don't want to wake my wife either.

I plan to buy one keyboard for a start, but may end up buying another to bring to work (like I did with the TypeMatrix, except my employer at the time bought the second one for me). At work, I will continue using the TypeMatrix, most likely, but I'm not sure yet.Anyhow, there are a number of things I do with my computer that require a keyboard:

• I write code, a considerable amount.
• I write prose, even more than code. Usually in English, sometimes in Hungarian.
• I play games. Most of them, with a dedicated controller, but there are some where I use the keyboard a lot.
• I browse the web, listen to music, and occasionally edit videos.
• I multi-task all the time.
• 90% of my time is spent within Emacs (recently switched to Spacemacs).
• I hate the mouse, with a passion. Trackballs, trackpoints and touchpads even more. If I can use my keyboard to do mouse-y stuff well enough to control the browser, and do some other things that do not require precise movement (that is, not games), I'll be very happy.

I am looking for a keyboard that helps me do these things. A keyboard that will stay with me not for five years or a decade, but pretty much forever.The optionsUltimate Hacking KeyboardPros

• Split keyboard.
• Mechanical keys (with a quiet option).
• Ships to Hungary. Made in Hungary!
• Optional addons: three extra buttons and a small trackball for the left side, and a trackball for the right side. While I'm not a big fan of the mouse, the primary reasons is that I have to move my hand. If it's in the middle, that sounds much better.
• Four layers of the factory keymap: I love the idea of these layers, especially the mouse layer.
• Programmable, so I can define any layout I want.
• Open source firmware, design and agent!
• An optional palm rest is available as well.
• Blank option available.

Cons

• Likely not available before late summer, 2016.
• No thumb keys.
• Space/Mod arrangement feels alien.
• The LED area is useless to me, and bothers my eye. Not a big deal, but still.
• While thumb keys are available for the left side, not so for the right one. I'd rather have keys there than a trackball. The only reason I'd want the $50 addon set, is the left thumb-key module (which also seems to have a trackpoint, another pointless gadget).

SummaryThe keyboard looks nice, has a lot of appealing features. It is programmable, so much so that by the looks of it, I could emulate the hardware dvorak switch my TypeMatrix has. However, I'm very unhappy with the addons, so there's that too.All in all, this would cost me about $304 (base keyboard, modules, palm rest and shipping). Not too bad, certainly a strong contender, despite the shortcomings.ErgoDoxPros

• Great design, by the looks of it.
• Mechanical keys.
• Open source hardware and firmware, thus programmable.
• Thumb keys.
• Available via ErgoDox EZ as an assembled product.

Cons

• Primarily a kit, but assembled available.
• Not sure when it'd ship (december shipments are sold out).

SummaryThe keyboard looks interesting, primarily due to the thumb keys. From the ErgoDox EZ campaign, I'm looking at $270. That's friendly, and makes ErgoDox a viable option! (Thanks @miffe!)Kinesis AdvantagePros

• Mechanical keys, Cherry-MX brown.
• Separate thumb keys.
• Key wells look interesting.
• Available right now.
• QWERTY/Dvorak layout available.

Cons

• Not a split keyboard.
• Not open source, neither hardware, nor firmware.
• Shipping to Hungary may be problematic.
• The QWERTY/Dvorak layout is considerably more expensive.
• Judging by some of the videos I saw, keys are too loud.

SummaryThe key wells look interesting, but it's not a split keyboard, nor is it open source. The cost come out about $325 plus shipping and VAT and so on, so I'm probably looking at something closer to $400. Nah. I'm pretty sure I can rule this out.Kinesis FreeStyle2Pros

• Split keyboard.
• Available right now.
• Optional accessory, to adjust the slope of the keyboard.

Cons

• Not open source, neither hardware, nor firmware.
• Doesn't seem to be mechanical.
• Shipping to Hungary may be problematic.
• No Dvorak layout.
• No thumb keys.

SummaryWhile a split keyboard, at a reasonably low cost ($149 + shipping + VAT), it lacks too many things to be considered a worthy contender.MaltronPros

• Mechanical keyboard.
• Key wells.
• Thumb keys.
• Built in palm rest.
• Available in Dvorak too.

Cons

• Not a split keyboard.
• The center numeric area looks weird.
• Not sure about programmability.
• Not open source.
• Expensive.

SummaryWithout shipping, I'm looking at 450. That's a very steep price. I love the wells, and the thumb keys, but it's not split, and customisability is a big question here.AtreusPros

• Sleek, compact design.
• No keycaps.
• Mechanical keyboard.
• Open source firmware.
• More keys within thumbs reach.
• Available right now.

Cons

• Ships as a DIY kit.
• Not a split keyboard.

SummaryWhile not a split keyboard, it does look very interesting, and the price is much lower than the rest: $149 + shipping ($50 or so). It is similar - in spirit - to my existing TypeMatrix. It wouldn't take much to get used to, and is half the price of the alternatives. A strong option, for sure.Keyboardio M01Pros

• Mechanical keyboard.
• Hardwood body.
• Blank and dot-only keycaps option.
• Open source: firmware, hardware, and so on. Comes with a screwdriver.
• The physical key layout has much in common with my TypeMatrix.
• Numerous thumb-accessible keys.
• A palm key, that allows me to use the keyboard as a mouse.
• Fully programmable LEDs.
• Custom macros, per-application even.

Cons

• Fairly expensive.
• Custom keycap design, thus rearranging them physically is not an option, which leaves me with the blank or dot-only keycap options only.
• Available late summer, 2016.

SummaryWith shipping cost and whatnot, I'm looking at something in the $370 ballpark, which is on the more expensive side. On the other hand, I get a whole lot of bang for my buck: LEDs, two center bars (tripod mounting sounds really awesome!), hardwood body, and a key layout that is very similar to what I came to love on the TypeMatrix.I also have a thing for wooden stuff. I like the look of it, the feel of it.The Preference ListAfter writing this all up, I think I prefer the Model 01, but the UHK and ErgoDox come close too!The UHK is cheaper, but not by a large margin. It lacks the thumb keys and the palm key the M01 has. It also looks rather dull (sorry). They'd both ship about the same time, but, the M01 is already funded, while the UHK is not (mind you, there's a pretty darn high chance it will be).The ErgoDox has thumb keys, split keyboard, and is open source. Compared to the UHK, we have the thumb keys, and less distraction, for a better price. But the case is not so nice. Compared to the Model 01: no leds, or center bar, and an inferior case. But, much better price, which is an important factor too.Then, there's the Atreus. While it's a DIY kit, it is much more affordable than the rest, and I could have it far sooner. Yet... it doesn't feel like a big enough switch from my current keyboard. I might as well continue using the TypeMatrix then, right?The rest, I ruled out earlier, while I was reviewing them anyway.So, the big question is: should I invest close to $400 into a keyboard that looks stunning, and will likely grow old with me? Or should I give up some of the features, and settle for one of the $300 ones, that'll also grow old with me. Or is there an option I did not consider, that may match my needs and preferences better?If you, my dear reader, got this far, and have a suggestion, please either tweet at me, or write an email, or reach me over any other medium I am reachable at (including IRC, hanging out as algernon on FreeNode and OFTC).Thank you in advance, to all of you who contact me, and help me choose a keyboard!

Going back to Android recently, I saw that all tools binaries from the Android project are now click-wrapped by a quite ugly proprietary license, among others an anti-fork clause (details below). Apparently those T&C are years old, but the click-wrapping is newer. This applies to the SDK, the NDK, Android Studio, and all the essentials you download through the Android SDK Manager. Since I keep my hands clean of smelly EULAs, I'm working on rebuilding the Android tools I need.
We're talking about hours-long, quad-core + 8GB-RAM + 100GB-disk-eating builds here, so I'd like to publish them as part of a project who cares. As a proof-of-concept, the Replicant project ships a 4.2 SDK and I contributed build instructions for ADT and NDK (which I now use daily). (Replicant is currently stuck to a 2013 code base though.) I also have in-progress instructions on my hard-drive to rebuild various newer versions of the SDK/API levels, and for the NDK whose releases are quite hard to reproduce (no git tags, requires fixes committed after the release, updates are partial rebuilds, etc.) - not to mention that Google doesn't publish the source code until after the official release (closed development) And in some cases like Android Support Repository [not Library] I didn't even find the proper source code, only an old prebuilt. Would you be interested in contributing, and would you recommend a structure that would promote Free, rebuilt Android *DK? The legalese Anti-fork clause:

3.4 You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.

So basically the source is Apache 2 + GPL, but the binaries are non-free. By the way this is not a GPL violation because right after:

3.5 Use, reproduction and distribution of components of the SDK licensed under an open source software license are governed solely by the terms of that open source software license and not this License Agreement.

Still, AFAIU by clicking "Accept" to get the binary you still accept the non-free "Terms and Conditions". (Incidentally, if Google wanted SDK forks to spread and increase fragmentation, introducing an obnoxious EULA is probably the first thing I'd have recommended. What was its legal team thinking?) Indemnification clause:

12.1 To the maximum extent permitted by law, you agree to defend, indemnify and hold harmless Google, its affiliates and their respective directors, officers, employees and agents from and against any and all claims, actions, suits or proceedings, as well as any and all losses, liabilities, damages, costs and expenses (including reasonable attorneys fees) arising out of or accruing from (a) your use of the SDK, (b) any application you develop on the SDK that infringes any copyright, trademark, trade secret, trade dress, patent or other intellectual property right of any person or defames any person or violates their rights of publicity or privacy, and (c) any non-compliance by you with this License Agreement.

Usage restriction:

3.1 Subject to the terms of this License Agreement, Google grants you a limited, worldwide, royalty-free, non-assignable and non-exclusive license to use the SDK solely to develop applications to run on the Android platform. 3.3 You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK.

If you know the URLs, you can still direct-download some of the binaries which don't embed the license, but all this feels fishy. GNU licensing didn't answer me (yet). Maybe debian-legal has an opinion? In any case, the difficulty to reproduce the *DK builds is worrying enough to warrant an independent rebuild. Did you notice this?

FOSDEM 2016 is going to be great (again!) and you still have the chance to be one of the stars. Have you submitted your talk to the Desktops DevRoom yet? No? Remember: we will only accept proposals until December 6th. After that, the Organization Team will get busy and vote and choose the talks. Here is the full Call for Participation, in case you need to check the details on how to submit: FOSDEM Desktops DevRoom 2016 Call for Participation Topics include anything related to the Desktop: desktop environments, software development for desktop/cross-platform, applications, UI, etc

The Debian Project includes many people, groups and teams with different goals, priorities and ways of doing things. Diversity is a good thing, and the results of the continuous interaction, cooperation and competition among different points of view and components make up a successful developing framework both in Debian and in other Free / Libre / Open Source Software communities. The cost of this evolutionary paradigm is that sometimes there are subprojects that might have been extremely successful and useful that are surpassed by newer approaches, or that have to compete with alternative approaches that were not there before, and which might pursue different goals or have a different way of doing things that their developers find preferable in terms of modularity, scalability, stability, maintenance, aesthetics or any other reason. Whenever this happens, the emotional impact on the person or group of people that are behind the established component (or process, or organizational structure), that is being questioned and put under test by the newer approach can be important, particularly when they have invested a lot of time and effort and a considerable amount of emotional energy doing a great job for many years. Something they should be thanked for. This might be particularly hard when -for whatever reason- the communication between both teams is not too fluent or constant, and sometimes the author or authors of the solution that was considered mainstream until then might feel left out and their territory stolen. As generally development teams and technical people in the Free / Libre / Open Source world are more focused on results than on relationships, projects are generally not too good at managing this (emotional, relational) situations, even though they (we) are gradually learning and improving. What has happened with the Debian Live Project is indeed a hurtful situation, even though it s probably an unavoidable one. The Debian Live Project has done a great job for many years and it is sad to see it dying abruptly. A new competing approach is on its way with a different set of priorities and different way of doing things, and all that can be done at the moment is to thank Daniel for all his work, as well as everyone who has made the Debian Live Project successful for so many years, also thank the people who are investing their time and effort in developing something that might be even better. Lets wait and see. Source of the image: Conflict Modes and Managerial Styles by Ed Batista

I'm pleased with the way that Lumail2 development is proceeding, and it is reaching a point where there will be a second source-release. I've made a lot of changes to the repository recently, and most of them boil down to moving code from the C++ side of the application, over to the Lua side. This morning, for example, I updated the handing of index.limit to be entirely Lua based.

When you open a Maildir folder you see the list of messages it contains, as you would expect. The notion of the index.limit is that you can limit the messages displayed, for example:

• See all messages: Config:set( "index.limit", "all")
• See only new/unread messages: Config:set( "index.limit", "new")
• See only messages which arrived today: Config:set( "index.limit", "today")
• See only messages which contain "Steve" in their formatted version: Config:set( "index.limit", "steve")

These are just examples that are present as defaults, but they give an idea of how things can work. I guess it isn't so different to Mutt's "limit" facilities - but thanks to the dynamic Lua nature of the application you can add your own with relative ease.

One of the biggest changes, recently, was the ability to display coloured text! That was always possible before, but a single line could only be one colour. Now colours can be mixed within a line, so this works as you might imagine: Panel:append( "$[RED]This is red, $[GREEN]green, $[WHITE]white, and $[CYAN]cyan!" ) Other changes include a persistant cache of "stuff", which is Lua-based, the inclusion of at least one luarocks library to parse Date: headers, and a simple API for all our objects. All good stuff. Perhaps time for a break in the next few weeks, but right now I think I'm making useful updates every other evening or so.

What happened in the reproducible builds effort this week: Toolchain fixes Emmanuel Bourg uploaded eigenbase-resgen/1.3.0.13768-2 which uses of the scm-safe comment style by default to make them deterministic. Mattia Rizzolo started a new thread on debian-devel to ask a wider audience for issues about the -Wdate-time compile time flag. When enabled, GCC and clang print warnings when __DATE__, __TIME__, or __TIMESTAMP__ are used. Having the flag set by default would prompt maintainers to remove these source of unreproducibility from the sources. Packages fixed The following packages have become reproducible due to changes in their build dependencies: bmake, cyrus-imapd-2.4, drobo-utils, eigenbase-farrago, fhist, fstrcmp, git-dpm, intercal, libexplain, libtemplates-parser, mcl, openimageio, pcal, powstatd, ruby-aggregate, ruby-archive-tar-minitar, ruby-bert, ruby-dbd-odbc, ruby-dbd-pg, ruby-extendmatrix, ruby-rack-mobile-detect, ruby-remcached, ruby-stomp, ruby-test-declarative, ruby-wirble, vtprint. The following packages became reproducible after getting fixed:

• bino/1.6.1-1 by Daniel Schaal.
• debconf/1.5.58 by Colin Watson.
• fte/0.50.2b6-8 uploaded by Axel Beckert, original patch by Reiner Herrmann.
• gnome-desktop3/3.18.2-1 uploaded by Michael Biebl, fix by Laurent Bigonville based on Andreas Henriksson's suggestion.
• libxmu/2:1.1.2-2 uploaded by Julien Cristau, fix by Andreas Boll.
• megaglest/3.11.1-3 by Markus Koschany.
• p4vasp/0.3.29+dfsg-2 uploaded by Graham Inggs, original patch by Reiner Herrmann.
• pd-iemmatrix/0.3-1 by IOhannes m zm lnig.
• performous/1.0+git150721-2 by Markus Koschany.
• python-sqlalchemy-utils/0.30.12-2 uploaded by Thomas Goirand, original patch by Chris Lamb.
• pywavelets/0.3.0-1 uploaded by Daniele Tricoli, original patch by Juan Picca.
• torus-trooper/0.22.dfsg1-10 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• tycho2/2-3 by Ole Streicher.
• xenomai/2.6.4+dfsg-0.1 by Leopold Palomo-Avellaneda.
• xfonts-mona/2.90-8 by Nobuhiro Iwamatsu.

Some uploads fixed some reproducibility issues, but not all of them:

• apache-mime4j/0.7.2-4 by Emmanuel Bourg.
• ispell-lt/1.2.1-5 by Chris Lamb (#778263.
• xscavenger/1.4.5-1 uploaded by Hwei Sheng Teoh, original patch by Chris Lamb.

Patches submitted which have not made their way to the archive yet:

• #804729 on pbuilder by Reiner Herrmann: tell dblatex to build in a deterministic path.

reproducible.debian.net The fifth and sixth armhf build nodes have been set up, resulting in five more builder jobs for armhf. More than 10,000 packages have now been identified as reproducible with the reproducible toolchain on armhf. (Vagrant Cascadian, h01ger) Helmut Grohne and Mattia Rizzolo now have root access on all 12 build nodes used by reproducible.debian.net and jenkins.debian.net. (h01ger) reproducible-builds.org is now linked from all package pages and the reproducible.debian.net dashboard. (h01ger) profitbricks-build5-amd64 and profitbricks-build6-amd64, responsible for running amd64 tests now run 398.26 days in the future. This means that one of the two builds that are being compared will be run on a different minute, hour, day, month, and year. This is not yet the case for armhf. FreeBSD tests are also done with 398.26 days difference. (h01ger) The design of the Arch Linux test page has been greatly improved. (Levente Polyak) diffoscope development Three releases of diffoscope happened this week numbered 39 to 41. It includes support for EPUB files (Reiner Herrmann) and Free Pascal unit files, usually having .ppu as extension (Paul Gevers). The rest of the changes were mostly targetting at making it easier to run diffoscope on other systems. The tlsh, rpm, and debian modules are now all optional. The test suite will properly skip tests that need optional tools or modules when they are not available. As a result, diffosope is now available on PyPI and thanks to the work of Levente Polyak in Arch Linux. Getting these versions in Debian was a bit cumbersome. Version 39 was uploaded with an expired key (according to the keyring on ftp.debian.org which will hopefully be updated soon) which is currently handled by keeping the files in the queue without REJECTing them. This prevented any other Debian Developpers to upload the same version. Version 40 was uploaded as a source-only upload but failed to build from source which had the undesirable side effect of removing the previous version from unstable. The package faild to build from source because it was built passing -I to debbuild. This excluded the ELF object files and static archives used by the test suite from the archive, preventing the test suite to work correctly. Hopefully, in a nearby future it will be possible to implement a sanity check to prevent such mistakes in the future. It has also been identified that ppudump outputs time in the system timezone without considering the TZ environment variable. Zachary Vance and Paul Gevers raised the issue on the appropriate channels. strip-nondeterminism development Chris Lamb released strip-nondeterminism version 0.014-1 which disables stripping Mono binaries as it is too aggressive and the source of the problem is being worked on by Mono upstream. Package reviews 133 reviews have been removed, 115 added and 103 updated this week. Chris West and Chris Lamb reported 57 new FTBFS bugs. Misc. The video of h01ger and Chris Lamb's talk at MiniDebConf Cambridge is now available. h01ger gave a talk at CCC Hamburg on November 13th, which was well received and sparked some interest among Gentoo folks. Slides and video should be available shortly. Frederick Kautz has started to revive Dhiru Kholia's work on testing Fedora packages. Your editor wish to once again thank #debian-reproducible regulars for reviewing these reports weeks after weeks.

On the final semester of my MSc program at Columbia SEAS, I was lucky enough to be able to attend a seminar course taught by Alfio Gliozzo entitled Q&A with IBM Watson. A significant part of the course is dedicated to learning how to leverage the services and resources available on the Watson Developer Cloud. This post describes the course project my team developed, the PaperTrail application.

Project Proposal Create an application to assist in the development of future academic papers. Based on a paper s initial proposal, Paper Trail predicts publications to be used as references or acknowledgement of prior art and provides a trend analysis of major topics and methods. The objective is to speed the discovery of relevant papers early in the research process, and allow for early assessment of the depth of prior research concerning the initial proposal.

Meet the Team Wesley Bruning, Software Engineer, MSc. in Computer Science Xavier Gonzalez, Industrial Engineer, MSc. in Data Science Juliana Louback, Software Engineer, MSc. in Computer Science Aaron Zakem, Patent Attorney, MSc. in Computer Science

Prior Art A significant amount of attention has been given to this topic over the past few decades. The table below shows the work the team deemed most relevant due to recency, accuracy and similarity of functionality. The variation in accuracy displayed is a result of experimentation with different dataset sizes and algorithm variations. More information and details can be found in the prior art report. The main differential of PaperTrail is providing a form of access to the citation prediciton and trend analysis algorithm. With the exception of the project by McNee et al., these algorithmns aren t currently available for general use. The application on researchindex.net is open to use but its objective is to rank publications and authors for given topics.

Algorithm Citation Prediction: PaperTrail builds on the work done by Wolski s team in Fall 2014. This algorithmn builds a reference graph used to define research communities, with an associated vector of topic scores generated by an LDA model. The papers in each research community are then ranked by importance within the community with a custom ranking algorithm. When a target document is given to algorithm as input, the LDA model is used to generate a vector of topics that are present in the document. The communities with the most similar topic vectors are selected and the publications within these communities with highest rank and greatest similarity to the input document are recommended as references. A more detailed description can be found here. Trend Analysis: Initially, the idea was to use the AlchemyData News API to obtain statistics pertaining to the amount of publications on a given topic over time. However, with the exception of buzz-words (i.e. big data ), many more specialized topics appeared very infrequently in news articles, if at all. This isn t entirely surprising given the target audience of PaperTrail. As a work around, we use the Alchemy Language API to extract keywords from the abstracts in the dataset, in addition to relevance scores. The PaperTrail database could then be queried for entry counts for a given year and keyword to provide an indication of publication trends in academia. Note that the Alchemy Language API extracts multiple-word keywords as well as single words.

Data To maintain consistency with Wolski s project, we are using the DBLP data as made available on aminer.org. The DBLP-Citation-network V5 dataset contains 1,572,277 entries; we are limited to the use of entries that contain both abstracts and citations, bringing the dataset size down to 265,865 entries.

Architecture A high-level visualization of the project architecture is displayed below. Before launching PaperTrail, it s necessary to train Wolski s algorithm offline. Currently any documentation with regard to the performance of said algorithm is unavailable; the PaperTrail project will include an evaluation phase and report the findings made. The PaperTrail app and database will be hosted on the Bluemix Platform.

Status Report Phases completed:

• Project design
• Prior art research
• Data cleansing
• Development and deployment of an alpha version of the PaperTrail app

Phases under development:

• Algorithm training and evaluation
• Keyword extraction
• MapReduce of publication frequency by year and topic
• Data visualization component

I have a friend who hates printers. I ll call him Mark , because that, incidentally, is his name. His hatred for printers is partly my fault, but that is, ahem, a story for another time that involves him returning from a battle with a printer with a combination of weld dust, toner, and a deep scowl on his face. I also tend to hate printers. Driver issues, crinkled paper, toner spilling all over the place . everybody hates printers. But there is exactly one printer that I have never hated. It s almost 20 years old, and has some stories to tell. Nearly 20 years ago, I was about to move out of my parents house, and I needed a printer. I bought a LaserJet 6MP. This printer ought to have been made by Nokia. It s still running fine, 18 years later. It turned out to be one of the best investments in computing equipment I ve ever made. Its operating costs, by now, are cheaper than just about any printer you can buy today less than one cent per page. It has been supported by every major operating system for years. PostScript was important, because back then running Ghostscript to convert to PCL was both slow and a little error-prone. PostScript meant I didn t need a finicky lpr/lprng driver on my Linux workstation to print. It just printed. (Hat tip to anyone else that remembers the trial and error of constructing an /etc/printcap that would print both ASCII and PostScript files correctly!) Out of this printer have come plane and train tickets, taking me across the country to visit family and across the world to visit friends. It s printed resumes and recipes, music and university papers. I even printed wedding invitations and envelopes on them two years ago, painstakingly typeset in LaTeX and TeXmacs. I remember standing at the printer in the basement one evening, feeding envelope after envelope into the manual feed slot. (OK, so it did choke on a couple of envelopes, but overall it all worked great.) The problem, though, is that it needs a parallel port. I haven t had a PC with one of those in a long while. A few years ago, in a moment of foresight, I bought a little converter box that has an Ethernet port and a parallel port, with the idea that it would be pay for itself by letting me not maintain some old PC just to print. Well, it did, but now the converter box is dying! And they don t make them anymore. So I finally threw in the towel and bought a new LaserJet. It cost a third of what the 6MP did, has a copier, scanner, prints in color, does duplexing, has wifi and, yes, still supports PostScript strangely enough, a deciding factor in going with HP over Brother once again. (The other was image quality) We shall see if I am still using it when I m 50.

Like each month, here comes a report about the work of paid contributors to Debian LTS. Individual reports In September, 85.50 work hours have been dispatched among 8 paid contributors. Their reports are available:

• Ben Hutchings did 14 hours (13.5h allocated, thus only catching up 0.5 hours out of the 5.5 extra hours he had left from former month).
• Chris Lamb did 11 hours (12h allocated, he will catch up later).
• Guido G nther did 4 hours (out of 8 hours allocated, thus keeping 4 extra hours for November).
• Mike Gabriel did nothing (out of 8 hours allocated, he will catch up in November).
• Rapha l Hertzog did 13.25 hours.
• Santiago Ruano Rinc n did 13.5 hours.
• Scott Kitterman did 8 hours (4 hours allocated and 4 hours remaining from September)
• Thorsten Alteholz did 13.25 hours.

Evolution of the situation November crossed a new record with 114.5 hours funded. This is mainly thanks to our first Platinum sponsor: TOSHIBA (through Toshiba Software Development Vietnam). They don t know yet if they can sponsor us in the long term (they hope so), but it s still a nice news as we jumped from 50% to 65% of the objective of the equivalent of a full-time position with a single new sponsor. Currently no change is expected for next month as we don t have any other new sponsor in the process of joining us. We still need more support to be able to support all the packages we could not afford to support during the squeeze cycle. We are currently discussing which package we can or cannot support on the LTS list, see the thread Unsupported packages for Wheezy LTS for the current situation. In terms of security updates waiting to be handled, the situation is close to last month: the dla-needed.txt file lists 21 packages awaiting an update (6 more than last month), the list of open vulnerabilities in Squeeze shows about 23 affected packages in total (exactly like last month). Thanks to our sponsors The new sponsors are in bold.

• Platinum sponsors:
• TOSHIBA
• Gold sponsors:
• The Positive Internet (for 17 months already)
• Blablacar (for 16 months already)
• Linode LLC (for 6 months already)
• Silver sponsors:
• David Ayers IntarS Austria (for 17 months already)
• Domeneshop AS (for 16 months already)
• Universit Lille 3 (for 16 months already)
• Trollweb Solutions (for 14 months already)
• Gandi SAS (for 11 months already)
• University of Luxembourg (for 8 months already)
• Rentabiliweb Group (for 6 months already)
• Univention GmbH
• Universit Jean Monnet de St Etienne
• Bronze sponsors:
• Offensive Security (for 17 months already)
• Seznam.cz, a.s. (for 17 months already)
• Evolix (for 16 months already)
• Freeside Internet Service (for 16 months already)
• MyTux (for 16 months already)
• Linuxhotel GmbH (for 14 months already)
• Intevation GmbH (for 13 months already)
• Daevel SARL (for 12 months already)
• Bitfolk LTD (for 11 months already)
• Megaspace Internet Services GmbH (for 11 months already)
• Gree, Inc. (for 10 months already)
• Greenbone Networks GmbH (for 10 months already)
• NUMLOG (for 10 months already)
• WinGo AG (for 9 months already)
• Ecole Centrale de Nantes LHEEA (for 5 months already)
• Sig-I/O (for 3 months already)
• Entr ouvert

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

Now this could just be the prodigious amounts of sugar and ghee I've been eating the past few days, but I'm bursting with energy for working on Debian so here is a list of things I want to do in the upcoming year.

• Finish packaging the latest Dovecot (2.2.19).

This will happen soon. Sooner if you people will stop filing bugs all the time. The rest of the items are more long term.

• Recruit more members for the Dovecot packaging team.
• Undertake to respond to all bug reports and other Debian correspondence within three days.
• Finally get the Minix port to a state where other people can use it and work on it too.
• Relearn Debian development from scratch so that I can be familliar with and apply the latest techniques. Write down what I've learned.
• Arrange (or more realistically get someone to arrange) a Debian event in Northern or Eastern India.
• Watch all the Debconf 15 videos.

To keep all of this on track, I shall adopt the practice lately seen on Debian Planet of periodically posting a report of my Debian activities.

db2twitter 0.2 was just released! If you missed my last post about it, db2twitter automatically extracts fields from your database, use them to feed a template of tweet and send the tweet. db2twitter is developed by and run for LinuxJobs.fr, the job board of th french-speaking Free Software and Opensource community.

• Github of db2twitter (star it if you like ;)
• Official documentation on readthedocs

The main new feature allows to send tweets only during authorized days/hours with the following content in your db2twitter.ini file :

[timer]
days=mon-fri,
hours=0-11,14-17,

• The line days=mon-fri specifies db2twitter can send tweets only from monday to friday.
• The line hours=0-11,14-17 specifies db2twitter can send tweets from midnight to 11AM (included) and from 2PM to 17PM (included)

Given the fact db2twitter will mostly be launched via cron, it allows sending tweets detected since the last db2twitter run during user-defined hours. And that s cool! db2twitter is coded in Python 3.4, uses SQlAlchemy (see supported database types) and Tweepy. The official documentation is available on readthedocs.

I m excited to see other people thinking about userspace-to-kernel attack surface reduction ideas. Theo de Raadt recently published slides describing Pledge. This uses the same ideas that seccomp implements, but with less granularity. While seccomp works at the individual syscall level and in addition to killing processes, it allows for signaling, tracing, and errno spoofing. As de Raadt mentions, Pledge could be implemented with seccomp very easily: libseccomp would just categorize syscalls. I don t really understand the presentation s mention of Optional Security , though. Pledge, like seccomp, is an opt-in feature. Nothing in the kernel refuses to run unpledged programs. I assume his point was that when it gets ubiquitously built into programs (like stack protector), it s effectively not optional (which is alluded to later as comprehensive applicability ~= mandatory mitigation ). Regardless, this sensible (though optional) design gets me back to his slide on seccomp, which seems to have a number of misunderstandings:

• A Turing complete eBPF program watches your program Strictly speaking, seccomp is implemented using a subset of BPF, not eBPF. And since BPF (and eBPF) programs are guaranteed to halt, it makes seccomp filters not Turing complete.
• Who watches the watcher? I don t even understand this. It s in the kernel. The kernel watches your program. Just like always. If this is a question of BPF program verification, there is literally a program verifier that checks various properties of the BPF program.
• seccomp program is stored elsewhere This, with the next statement, is just totally misunderstood. Programs using seccomp define their program in their own code. It s used the same way as the Pledge examples are shown doing.
• Easy to get desyncronized either program is updated As above, this just isn t the case. The only place where this might be true is when using seccomp on programs that were not written natively with seccomp. In that case, yes, desync is possible. But that s one of the advantages of seccomp s design: a program launcher (like minijail or systemd) can declare a seccomp filter for a program that hasn t yet been ported to use one natively.
• eBPF watcher has no real idea what the program under observation is doing I don t understand this statement. I don t see how Pledge would have a real idea either: they re both doing filtering. If we get AI out of our syscall filters, we re in serious trouble. :)

OpenBSD has some interesting advantages in the syscall filtering department, especially around sockets. Right now, it s hard for Linux syscall filtering to understand why a given socket is being used. Something like SOCK_DNS seems like it could be quite handy. Another nice feature of Pledge is the path whitelist feature. As it s still under development, I hope they expand this to include more things than just paths. Argument inspection is a weak point for seccomp, but under Linux, most of the arguments are ultimately exposed to the LSM layer. Last year I experimented with creating a seccomp LSM for path matching where programs could declare whitelists, similar to standard LSMs. So, yes, Linux could match this API on seccomp . It d just take some extensions to libseccomp to implement pledge(), as I described at the top. With OpenBSD doing a bunch of analysis work on common programs, it d be excellent to see this usable on Linux too. So far on Linux, only a few programs (e.g. Chrome, vsftpd) have bothered to do this using seccomp, and it could be argued that this is ultimately due to how fine grained it is.

2015, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

October 2015 has been mainly dedicated to contracted/payed work. Only a few issues I could address during the last month:

• Fix FTBFS of Arctica Greeter on non-Ubuntu systems
• Co-working on renewed Xinerama support in nx-libs
• Development of GOsa Password Management Add-on
• Improving Debian Edu main server upgrade documentation (from Debian Edu squeeze to Debian Edu jessie)
• Fixing my personal Horde Groupware installation for access via mobile devices
• Learning Dovecot et al.

Arctica Project While having a week off from work, I managed to get Arctica Greeter to build on non-Ubuntu systems. The issue was very simple. The build crashed during the test suite run and it was caused by the XDG_DATA_DIRS variable not being set in my clean build environment. Furthermore, I added various more session type icons to Arctica Greeter (XFCE, LXDE, MATE, OpenBox, TWM, Default X11 Session, etc.) and also rebased the Arctica Greeter code base against all recent commits found in Unity Greeter for Ubuntu 15.10 / upcoming 16.04. Together with Ulrich Sibiller, I continued our work on the new Xinerama implementation for the remote X11 server nxagent (used as x2goagent in X2Go). However, this is unfortunately still work in progress, because various theoretical monitor layout issues became evident that require being handled in the new code before it can get merged into nx-libs's current 3.6.x branch. Also, I managed to do some little work on https://arctica-project.org, the still too rudimentary project homepage. read more

Debian Live has passed on. And it has done so in not happy circumstances. (You can search the list archives for more if you are confused.) I have reposted here my response to this one thread because it s all I really want to say, after all of the years of working with the team. I d like to add as a postscript, that while the focus of this article was to remain positive in the face of Daniel s announcement of the closure of his project, that event has left a lot of users confused about the status of live support in Debian going forward. Read my posts here and here addressing that confusion.

On 09/11/15 12:47 PM, Daniel Baumann wrote:
> So long, and thanks for all the fish[7].
>
> Daniel
>
> [7] http://live.debian.net/project/downstream/ Enough bitter words have been said. I don t want to add any more. So: I m proud. Indeed, that long list of downstreams does speak to the impact you ve had in inspiring and equipping people to make their own live images. I m proud to have been a small part of this project. I m thankful. I m thankful that I was able to, through this project, contribute to something for a while that had a positive impact on many people, and made Debian more awesome. I remember the good times. I remember fondly the good times we had in the project s heyday. I certainly found your enthusiasm and vision for the project, Daniel, personally inspiring. It motivated me to contribute. Debconf10 was a highlight among those experiences, but also I had many good times and made many friendships online, too. I m sad. I m sad, because although I made some attempts to liaise between Debian Live and the CD and Installer teams, I don t feel I did an effective job there, and that contributed to the situation we now find ourselves in. If I did you or the project injury in trying to fulfill that role, please forgive me. I m hopeful. I m hopeful that whichever way we all go from here, that the bitterness will not be forever. That we ll heal. That we ll have learned. That we ll move on to accomplish new things, bigger and better things. Thank you, Daniel. Thank you, Debian Live team. Ben

What happened in the reproducible builds effort this week: Toolchain fixes

• Colin Watson uploaded groff/1.22.3-2 which implements support for SOURCE_DATE_EPOCH.
• Colin Watson uploaded halibut/1.1-2 which implements support for SOURCE_DATE_EPOCH.

Chris Lamb filled a bug on python-setuptools with a patch to make the generated requires.txt files reproducible. The patch has been forwarded upstream. Chris also understood why the she-bang in some Python scripts kept being undeterministic: setuptools as called by dh-python could skip re-installing the scripts if the build had been too fast (under one second). #804339 offers a patch fixing the issue by passing --force to setup.py install. #804141 reported on gettext asks for support of SOURCE_DATE_EPOCH in gettextize. Santiago Vila pointed out that it doesn't felt appropriate as gettextize is supposed to be an interactive tool. The problem reported seems to be in avahi build system instead. Packages fixed The following packages became reproducible due to changes in their build dependencies: celestia, dsdo, fonts-taml-tscu, fte, hkgerman, ifrench-gut, ispell-czech, maven-assembly-plugin, maven-project-info-reports-plugin, python-avro, ruby-compass, signond, thepeg, wagon2, xjdic. The following packages became reproducible after getting fixed:

• 4ti2/1.6.6+ds-1 uploaded by Jerome Benoit, fixed upstream.
• allegro4.4/2:4.4.2-7 uploaded by Andreas R nnquist, original patch by Reiner Herrmann.
• axel/2.5-2 by Joao Eriberto Mota Filho.
• bastet/0.43-4 by Markus Koschany.
• bbswitch/0.8-3 uploaded by Luca Boccassi, original patch by Reiner Herrmann.
• commons-math/2.2-5 by Emmanuel Bourg.
• fatresize/1.0.2-8 by Colin Watson, reported by Chris Lamb.
• giada/0.10.2~dfsg1-1 by IOhannes m zm lnig.
• groff/1.22.3-3 by Colin Watson.
• halibut/1.1-2 by Colin Watson.
• ivy/2.4.0-2 by Emmanuel Bourg.
• libfreemarker-java/2.3.23-2 by Emmanuel Bourg.
• libjna-java/4.2.1-1 by Emmanuel Bourg.
• lmemory/0.6c-8 by Markus Koschany.
• man-db/2.7.5-1 by Colin Watson.
• maven2-core/2.2.1-23 by Emmanuel Bourg.
• ncurses/6.0+20151024-2 by Sven Joachim, report by Esa Peuha.
• netmask/2.4.3-1 by Guilhem Moulin.
• ogre-1.9/1.9.0+dfsg1-7 uploaded by Manuel A. Fernandez Montecelo, original patch by Chris Lamb.
• praat/6.0.4-2 by Rafael Laboissiere.
• soundscaperenderer/0.4.2~dfsg-5 by IOhannes m zm lnig.
• usb-modeswitch-data/20151101-1 uploaded by Didier Raboud, original patch by Reiner Herrmann.

Some uploads fixed some reproducibility issues but not all of them:

• dbconfig-common/1.8.55 by Paul Gevers.
• mondrian/1:3.11.0.1-1 by Emmanuel Bourg.

Patches submitted which have not made their way to the archive yet:

• #803893 on goaccess by Guillaume Delacour: remove __DATE__ and __TIME__ macros.
• #803908 on starlink-pal by Chris Lamb: pass -info 0 to latex2html.

Chris Lamb closed a wrongly reopened bug against haskell-devscripts that was actually a problem in haddock. reproducible.debian.net FreeBSD tests are now run for three branches: master, stable/10, release/10.2.0. (h01ger) diffoscope development Support has been added for Free Pascal unit files (.ppc). (Paul Gevers) The homepage is now available using HTTPS, thanks to Let's Encrypt!. Work has been done to be able to publish diffoscope on the Python Package Index (also known as PyPI): the tlsh module is now optional, compatibility with python-magic has been added, and the fallback code to handle RPM has been fixed. Documentation update Reiner Herrmann, Paul Gevers, Niko Tyni, opi, and Dhole offered various fixes and wording improvements to the reproducible-builds.org. A mailing-list is now available to receive change notifications. NixOS, Guix, and Baserock are featured as projects working on reproducible builds. Package reviews 70 reviews have been removed, 74 added and 17 updated this week. Chris Lamb opened 22 new fail to build from source bugs. New issues this week: randomness_in_ocaml_provides, randomness_in_qdoc_page_id, randomness_in_python_setuptools_requires_txt, gettext_creates_ChangeLog_files_and_entries_with_current_date. Misc. h01ger and Chris Lamb presented Beyond reproducible builds at the MiniDebConf in Cambridge on November 8th. They gave an overview of where we stand and the changes in user tools, infrastructure, and development practices that we might want to see happening. Feedback on these thoughts are welcome. Slides are already available, and the video should be online soon. At the same event, a meeting happened with some members of the release team to discuss the best strategy regarding releases and reproducibility. Minutes have been posted on the Debian reproducible-builds mailing-list.

I've been trying to run containers using systemd-nspawn for quite some time. I was always bumping to one or other dead end. This is not systemd-nspawn's fault, rather my impatience stopping me from reading manual pages properly lack of good tutorial like article available online. Compared to this LXC has a quite a lot of good tutorials and howto's available online. This article is my effort to create a notes putting all required information in one place.

Andy (rattusrattus) on Video team sprint over the last few days with Ivo de Decker and Stefano Rovera

Background/Existing infrastructure/Why change? [DV/Firewire are EOL]
Things to do

1. Replace twinpact video slide capture system with something that can capture HDMI - better resolution,- digital all the way
Using a pre-production prototype at the moment. CCC also hoping to use this. All kit needs to go into one big box with sensible power supplies
2. Replace DVswitch
Better resolution, select sources, record all inputs, record all edits
Gstreamer based transport solution - import/output format agnostic
GST-Switch - possibly dead? VoctoMix looks more promising - CCC are testing this. First use in anger may be December
3. Improve streaming - single stream out. Encode stream on in-room hardware.
Sharing is a thing ... CCC workflow and setup are good - everyone should share technology. FOSDEM has 25 rooms ...
4 Replace/expand AV equipment
Workstation PC - SDI capture/video mixing/local record and encode
Laptop for remote UI
2 cameras
Opsis frame grabber
5 BoF Room recording - lots of options to handle differently
1 Operator maximum / preferably automated
Video conferencing camera / microphone setup
Frame grabber for slides / Gobby feed
6 Logistics
Organise equipment by room
Kit must be kept deployable
Quartermastering necessary
Checklists for each box
Set up a lab for development and release
DO NOT CHANGE ANYTHING ON THE PRODUCTION KIT

Debian LTS October was the sixth month I contributed to Debian LTS under the Freexian umbrella. In total I spent four hours working on:

• krb5: I applied patches for CVE-2015-2697 and CVE-2015-2695. The DLA-340-1 was released on November though since one of the patches was incomplete.

Besides that I did CVE triaging of 16 CVEs to check if and how they affect oldoldstable security as part of my LTS front desk work. I also added some very basic indentation support to our CVE/list Emacs major-mode on non LTS time. Other Debian stuff

• I've released git-buildpackage 0.7.0 with lots of updates, most notably more complete rpm support, a git-pbuilder update and documentation updates. This release has patches from 9 different contributors, thanks a lot!
• Uploaded libvirt 1.2.21~rc1 to experimental, submitted a patch to fix running autopkg tests in pbuilder (#802379) and fixed RC bug #802281 in Icedove.
• I've updated cl2vcs, a CGI to link commit IDs in the debian/changelog to the VCS, to 0.0.4 fixing some bugs that showed up after I updated the hosting machine to Jessie as well as support for the [commitid1,commitd2,commit3,...] format when grouping commits. (SSL certificate of the server is CAcert signed)
• At Halloween five Debian aficionados met for Hacking Erpel 1 (aka HEPL1) in Erpel (link goes to German Wikipedia) between Bonn and Koblenz. Some details are here. We're aiming for more of these events on a more frequent basis (HEPL0 being back in 2013) so if you're somewhere from that area and want to join us next time just subscribe to the new mailing list (in German, SSL certificate of the server is CAcert signed).