Feed aggregator

Russia publicly joins war on Tor privacy with $111,000 bounty

Ars Technica - Fri, 25/07/2014 - 16:51

The Russian Ministry of Internal Affairs (MVD) has offered a 3.9 million ruble (approximately $111,000) contract for technology that can identify the users of Tor, the encrypted anonymizing network used by Internet users seeking to hide their activities from monitoring by law enforcement, government censors, and others.

In a notice on the Russian government’s procurement portal under the title “Perform research, code ‘TOR’ (Navy),” originally posted on July 11, the MVD announced it was seeking proposals for researchers to ”study the possibility of obtaining technical information about users and users equipment on the Tor anonymous network.” The competition, which is open only to Russian citizens and companies, requires entrants to pay a 195,000 ruble (approximately $5,555) application fee. Proposals are due by August 13, and a winner of the contract will be chosen by August 20.

The MVD had previously sought to ban the use of any anonymizing software. That proposal was dropped last year. However, a new “blogger law” passed in April, which goes into effect in August, requires all bloggers with an audience of over 3,000 readers to register their identity with the government—and enforcement of the law could be made difficult if bloggers use the Tor network to retain their anonymity.

Read 4 remaining paragraphs | Comments

Kügler: Plasma’s Road to Wayland

LWN.net - Fri, 25/07/2014 - 16:34
On his blog, Sebastian Kügler looks at what's left to be done for KDE's Plasma desktop to support Wayland. He discusses why the project cares about Wayland, what it means to support Wayland, the current status, the strategy for further work, and how interested folks can get involved. "One of the important topics which we have (kind of) excluded from Plasma’s recent 5.0 release is support for Wayland. The reason is that much of the work that has gone into renovating our graphics stack was also needed in preparation for Wayland support in Plasma. In order to support Wayland systems properly, we needed to lift the software stack to Qt5, make X11 dependencies in our underlying libraries, Frameworks 5 optional. This part is pretty much done. We now need to ready support for non-X11 systems in our workspace components, the window manager and compositor, and the workspace shell."

Juliana Louback: Extending an xTuple Business Object

Planet Debian - Fri, 25/07/2014 - 16:06

xTuple is in my opinion incredibly well designed; the code is clean and the architecture ahderent to a standardized structure. All this makes working with xTuple software quite a breeze.

I wanted to integrate JSCommunicator into the web-based xTuple version. JSCommunicator is a SIP communication tool, so my first step was to create an extension for the SIP account data. Luckily for me, the xTuple development team published an awesome tutorial for writing an xTuple extension.

xTuple cleverly uses model based business objects for the various features available. This makes customizing xTuple very straightforward. I used the tutorial mentioned above for writing my extension, but soon noticed my goals were a little different. A SIP account has 3 data fields, these being the SIP URI, the account password and an optional display name. xTuple currently has a business object in the core code for a User Account and it would make a lot more sense to simply add my 3 fields to this existing business object rather than create another business object. The tutorial very clearly shows how to extend a business object with another business object, but not how to extend a business object with only new fields (not a whole new object).

Now maybe I’m just a whole lot slower than most people, but I had a ridiculously had time figuring this out. Mind you, this is because I’m slow, because the xTuple documentation and code is understandable and as self-explanatory as it gets. I think it just takes a bit to get used to. Either way, I thought this just might be useful to others so here is how I went about it.


First you’ll have to set up your xTuple development environment and fork the xtuple and xtuple-extesions repositories as shown in this handy tutorial. A footnote I’d like to add is please verify that your version of Vagrant (and anything else you install) is the one listed in the tutorial. I think I spent like two entire days or more on a wild goose (bug) chase trying to set up my environment when the cause of all the errors was that I somehow installed an older version of Vagrant - 1.5.4 instead of 1.6.3. Please don’t make the same mistake I did. Actually if for some reason you get the following error when you try using node:

<<ERROR 2014-07-10T23:52:46.948Z>> Unrecoverable exception. Cannot call method 'extend' of undefined at /home/vagrant/dev/xtuple/lib/backbone-x/source/model.js:37:39 at Object.<anonymous> (/home/vagrant/dev/xtuple/lib/backbone-x/source/model.js:1364:3) ...

chances are, you have the wrong version. That’s what happened to me. The Vagrant Virtual Development Environment automatically installs and configures everything you need, it’s ready to go. So if you find yourself installing and updating and apt-gets and etc, you probably did something wrong.


So by now we should have the Vagrant Virtual Development Environment set up and the web app up and running and accessible at localhost:8443. So far so good.

Disclaimer: You will note that much of this is similar - or rather, nearly identical - to xTuple’s tutorial but there are some small but important differences and a few observations I think might be useful. Other Disclaimer: I’m describing how I did it, which may or may not be ‘up to snuff’. Works for me though.


First let’s make a schema for the table we will create with the new custom fields. Be sure to create the correct directory stucture, aka /path/to/xtuple-extensions/source/<YOUR EXTENSION NAME>/database/source or in my case /path/to/xtuple-extensions/source/sip_account/database/source, and create the file create_sa_schema.sql, ‘sa’ is the name of my schema. This file will contain the following lines:

do $$ /* Only create the schema if it hasn't been created already */ var res, sql = "select schema_name from information_schema.schemata where schema_name = 'sa'", res = plv8.execute(sql); if (!res.length) { sql = "create schema sa; grant all on schema sa to group xtrole;" plv8.execute(sql); } $$ language plv8;

Of course, feel free to replace ‘sa’ with your schema name of choice. All the code described here can be found in my xtuple-extensions fork, on the sip_ext branch.


We’ll create a table containing your custom fields and a link to an existing table - the table for the existing business object you want to extend. If you’re wondering why make a whole new table for a few extra fields, here’s a good explanation, the case in question is adding fields to the Contact business object.

You need to first figure out what table you want to link to. This might not be uber easy. I think the best way to go about it is to look at the ORMs. The xTuple ORMs are a JSON mapping between the SQL tables and the object-oriented world above the database, they’re .json files found at path/to/xtuple/node_modules/xtuple/enyo-client/database/orm/models for the core business objects and at path/to/xtuplenyo-client/extensions/source/<EXTENSION NAME>/database/orm/models for exension business objects. I’ll give two examples. If you look at contact.json you will see that the Contact business object refers to the table “cntct”. Look for the “type”: “Contact” on the line above, so we know it’s the “Contact” business object. In my case, I wanted to extend the UserAccount and UserAccountRelation business objects, so check out user_account.json. The table listed for UserAccount is xt.usrinfo and the table listed for UserAccountRelation is xt.usrlite. A closer look at the sql files for these tables (usrinfo.sql and usrlite.sql) revealed that usrinfo is in fact a view and usrlite is ‘A light weight table of user information used to avoid punishingly heavy queries on the public usr view’. I chose to refer to xt.usrlite - that or I received error messages when trying the other table names.

Now I’ll make the file /path/to/xtuple-extensions/source/sip_account/database/source/usrlitesip.sql, to create a table with my custom fields plus the link to the urslite table. Don’t quote me on this, but I’m under the impression that this is the norm for naming the sql file joining tables: the name of the table you are referring to (‘usrlite’ in this case) and your extension’s name. Content of usrlitesip.sql:

select xt.create_table('usrlitesip', 'sa'); select xt.add_column('usrlitesip','usrlitesip_id', 'serial', 'primary key', 'sa'); select xt.add_column('usrlitesip','usrlitesip_usr_username', 'text', 'references xt.usrlite (usr_username)', 'sa'); select xt.add_column('usrlitesip','usrlitesip_uri', 'text', '', 'sa'); select xt.add_column('usrlitesip','usrlitesip_name', 'text', '', 'sa'); select xt.add_column('usrlitesip','usrlitesip_password', 'text', '', 'sa'); comment on table sa.usrlitesip is 'Joins User with SIP account';

Breaking it down, line 1 creates the table named ‘usrlitesip’ (no duh), line 2 is for the primary key (self-explanatory). You can then add any columns you like, just be sure to add one that references the table you want to link to. I checked usrlite.sql and saw the primary key is usr_username, be sure to use the primary key of the table you are referencing.

You can check what you made by executing the .sql files like so:

$ cd /path/to/xtuple-extensions/source/sip_account/database/source $ psql -U admin -d dev -f create_sa_schema.sql $ psql -U admin -d dev -f usrlitesip.sql

After which you will see the table with the columns you created if you enter:

$ psql -U admin -d dev -c "select * from sa.usrlitesip;"

Now create the file /path/to/xtuple-extensions/source/sip_account/database/source/manifest.js to put the files together and in the right order. It should contain:

{ "name": "sip_account", "version": "1.4.1", "comment": "Sip Account extension", "loadOrder": 999, "dependencies": ["crm"], "databaseScripts": [ "create_sa_schema.sql", "usrlitesip.sql", "register.sql" ] }

I think the “name” has to be the same you named your extension directory as in /path/to/xtuple-extensions/source/<YOUR EXTENSION NAME>. I think the “comment” can be anything you like and you want your “loadOrder” to be high so it’s the last thing installed (as it’s an add on.) So far we are doing exactly what’s instructed in the xTuple tutorial. It’s repetitive, but I think you can never have too many examples to compare to. In “databaseScripts” you will list the two .sql files you just created for the schema and the table, plus another file to be made in the same directory named register.sql.

I’m not sure why you have to make the register.sql or even if you indeed have to. If you leave the file empty, there will be a build error, so put a ‘;’ in the register.sql or remove the line “register.sql” from manifest.js as I think for now we are good without it.

Now let’s update the database with our new extension:

$ cd /path/to/xtuple $ ./scripts/build_app.js -d dev -e ../xtuple-extensions/source/sip_account $ psql -U admin -d dev -c "select * from xt.ext;"

That last command should display a table with a list of extensions; the ones already in xtuple like ‘crm’ and ‘billing’ and some others plus your new extension, in this case ‘sip_account’. When you run build_app.js you’ll probably see a message along the lines of “<Extension name> has no client code, not building client code” and that’s fine because yeah, we haven’t worked on the client code yet.


Here’s where things start getting different. So ORMs link your object to an SQL table. But we DON’T want to make a new business object, we want to extend an existing business object, so the ORM we will make will be a little different than the xTuple tutorial. Steve Hackbarth kindly explained this new business object/existing business object ORM concept here.

First we’ll create the directory /path/to/xtuple-extensions/source/sip_account/database/orm/ext, according to xTuple convention. ORMs for new business objects would be put in /path/to/xtuple-extensions/source/sip_account/database/orm/models. Now we’ll create the .json file /path/to/xtuple-extensions/source/sip_account/database/orm/ext/user_account.jscon for our ORM. Once again, don’t quote me on this, but I think the name of the file should be the name of the business object you are extending, as is done in the turorial example extending the Contact object. In our case, UserAccount is defined in user_account.json and that’s what I named my extension ORM too. Here’s what you should place in it:

1 [ 2 { 3 "context": "sip_account", 4 "nameSpace": "XM", 5 "type": "UserAccount", 6 "table": "sa.usrlitesip", 7 "isExtension": true, 8 "isChild": false, 9 "comment": "Extended by Sip", 10 "relations": [ 11 { 12 "column": "usrlitesip_usr_username", 13 "inverse": "username" 14 } 15 ], 16 "properties": [ 17 { 18 "name": "uri", 19 "attr": { 20 "type": "String", 21 "column": "usrlitesip_uri", 22 "isNaturalKey": true 23 } 24 }, 25 { 26 "name": "displayName", 27 "attr": { 28 "type": "String", 29 "column": "usrlitesip_name" 30 } 31 }, 32 { 33 "name": "sipPassword", 34 "attr": { 35 "type": "String", 36 "column": "usrlitesip_password" 37 } 38 } 39 ], 40 "isSystem": true 41 }, 42 { 43 "context": "sip_account", 44 "nameSpace": "XM", 45 "type": "UserAccountRelation", 46 "table": "sa.usrlitesip", 47 "isExtension": true, 48 "isChild": false, 49 "comment": "Extended by Sip", 50 "relations": [ 51 { 52 "column": "usrlitesip_usr_username", 53 "inverse": "username" 54 } 55 ], 56 "properties": [ 57 { 58 "name": "uri", 59 "attr": { 60 "type": "String", 61 "column": "usrlitesip_uri", 62 "isNaturalKey": true 63 } 64 }, 65 { 66 "name": "displayName", 67 "attr": { 68 "type": "String", 69 "column": "usrlitesip_name" 70 } 71 }, 72 { 73 "name": "sipPassword", 74 "attr": { 75 "type": "String", 76 "column": "usrlitesip_password" 77 } 78 } 79 ], 80 "isSystem": true 81 } 82 ]

Note the “context” is my extension name, because the context + nameSpace + type combo has to be unique. We already have a UserAccount and UserAccountRelation object in the “XM” namespace in the “xtuple” context in the original user_account.json, now we will have a UserAccount and UserAccountRelation object in the “XM” namespace in the “sip_account” conext. What else is important? Note that “isExtension” is true on lines 7 and 47 and the “relations” item contains the “column” of the foreign key we referenced.

This is something you might want to verify: “column” (lines 12 and 52) is the name of the attribute on your table. When we made a reference to the primary key usr_usrname from the xt.usrlite table we named that column usrlitesip_usr_usrname. But the “inverse” is the attribute name associated with the original sql column in the original ORM. Did I lose you? I had a lot of trouble with this silly thing. In the original ORM that created a new UserAccount business object, the primary key attribute is named “username”, as can be seen here. That is what should be used for the “inverse” value. Not the sql column name (usr_username) but the object attribute name (username). I’m emphasizing this because I made that mistake and if I can spare you the pain I will.

If we rebuild our extension everything should come along nicely, but you won’t see any changes just yet in the web app because we haven’t created the client code.


Create the directory /path/to/xtuple-extensions/source/sip_account/client which is where we’ll keep all the client code.

Extend Workspace View I want the fields I added to show up on the form to create a new User Account, so I need to extend the view for the User Account workspace. I’ll start by creating a directory /path/to/xtuple-extensions/source/sip_account/client/views and in it creating a file named ‘workspace.js’ containing this code:

XT.extensions.sip_account.initWorkspace = function () { var extensions = [ {kind: "onyx.GroupboxHeader", container: "mainGroup", content: "_sipAccount".loc()}, {kind: "XV.InputWidget", container: "mainGroup", attr: "uri" }, {kind: "XV.InputWidget", container: "mainGroup", attr: "displayName" }, {kind: "XV.InputWidget", container: "mainGroup", type:"password", attr: "sipPassword" } ]; XV.appendExtension("XV.UserAccountWorkspace", extensions); };

So I’m initializing my workspace and creating an array of items to add (append) to view XV.UserAccountWorkspace. The first ‘item’ is this onyx.GroupboxHeader which is a pretty divider for my new form fields, the kind you find in the web app at Setup > User Accounts, like ‘Overview’. I have no idea what other options there are for container other than “mainGroup”, so let’s stick to that. I’ll explain content: “_sipAccount”.loc() in a bit. Next I created three input fields of the XV.InputWidget kind. This also confused me a bit as there are different kinds of input to be used, like dropdowns and checkboxes. The only advice I can give is snoop around the webapp, find an input you like and look up the corresponding workspace.js file to see what was used.

What we just did is (should be) enough for the new fields to show up on the User Account form. But before we see things change, we have to package the client. Create the file /path/to/xtuple-extensions/source/sip_account/client/views/package.js. This file is needed to ‘package’ groups of files and indicates the order the files should be loaded (for more on that, see this). For now, all the file will contain is:

enyo.depends( "workspace.js" );

You also need to package the ‘views’ directory containing workspace.js, so create the file Create the file /path/to/xtuple-extensions/source/sip_account/client/package.js and in it show that the directory ‘views’ and its contents must be part of the higher level package:

enyo.depends( "views" );

I like to think of it as a box full of smaller boxes.

This will sound terrible, but apparently you also need to create the file /path/to/xtuple-extensions/source/sip_account/client/core.js containing this line:

XT.extensions.icecream = {};

I don’t know why. As soon as I find out I’ll be sure to inform you.

As we’ve added a file to the client directory, be sure to update /path/to/xtuple-extensions/source/sip_account/client/package.js so it included the new file:

enyo.depends( "core.js", "views" );


Remember “_sipAccount”.loc()” in our workspace.js file? xTuple has great internationalization support and it’s easy to use. Just create the directory and file /path/to/xtuple-extensions/source/sip_account/client/en/strings.js and in it put key-value pairs for labels and their translation, like this:

(function () { "use strict"; var lang = XT.stringsFor("en_US", { "_sipAccount": "Sip Account", "_uri": "Sip URI", "_displayName": "Display Name", "_sipPassword": "Password" }); if (typeof exports !== 'undefined') { exports.language = lang; } }());

So far I included all the labels I used in my Sip Account form. If you write the wrong label (key) or forget to include a corresponding key-value pair in strings.js, xTuple will simply name your lable “_lableName”, underscore and all.

Now build your extension and start up the server:

$ cd /path/to/xtuple $ ./scripts/build_app.js -d dev -e ../xtuple-extensions/source/sip_account $ node node-datasource/main.js

If the server is already running, just stop it and restart it to reflect your changes.

Now if you go to Setup > User Accounts and click the “+” button, you should see a nice little addition to the form with a ‘Sip Account’ divider and three new fields. Nice, eh?

Extend Parameters

Currently you can search your User Accounts list using any of the User Account fields. It would be nice to be able to search with the Sip account fields we added as well. To do that, let’s create the directory /path/to/xtuple-extensions/source/sip_account/client/widgets and there create the file parameter.js to extend XV.UserAccountListParameters. One again, you’ll have to look this up. In the xTuple code you’ll find the application’s parameter.js in /path/to/xtuple/enyo-client/application/source/widgets. Search for the business object you are extending (for example, XV.UserAccount) and look for some combination of the business object name and ‘Parameters’. If there’s more than one, try different ones. Not a very refined method, but it worked for me. Here’s the content of our parameter.js:

XT.extensions.sip_account.initParameterWidget = function () { var extensions = [ {kind: "onyx.GroupboxHeader", content: "_sipAccount".loc()}, {name: "uri", label: "_uri".loc(), attr: "uri", defaultKind: "XV.InputWidget"}, {name: "displayName", label: "_displayName".loc(), attr: "displayName", defaultKind: "XV.InputWidget"} ]; XV.appendExtension("XV.UserAccountListParameters", extensions); };

Node that I didn’t include a search field for the password attribute for obvious reasons. Now once again, we package this new code addition by creating a /path/to/xtuple-extensions/source/sip_account/client/widgets/package.js file:

enyo.depends( "parameter.js" );

We also have to update /path/to/xtuple-extensions/source/sip_account/client/package.js:

enyo.depends( "core.js", "widgets" "views" );

Rebuild the extension (and restart the server) and go to Setup > User Accounts. Press the magnifying glass button on the upper left side of the screen and you’ll see many options for filtering the User Accounts, among them the SIP Uri and Display Name.

Extend List View

You might want your new fields to show up on the list of User Accounts. I figured out a way to do this that looks strange and kind of incorrect, but it’s apparently working.

Create the file /path/to/xtuple-extensions/source/sip_account/client/views/list.js and add the following:

enyo.kind({ name: "XV.UserAccountList", kind: "XV.List", label: "_userAccounts".loc(), collection: "XM.UserAccountRelationCollection", parameterWidget: "XV.UserAccountListParameters", query: {orderBy: [ {attribute: 'username'} ]}, components: [ {kind: "XV.ListItem", components: [ {kind: "FittableColumns", components: [ {kind: "XV.ListColumn", classes: "short", components: [ {kind: "XV.ListAttr", attr: "username", isKey: true} ]}, {kind: "XV.ListColumn", classes: "short", components: [ {kind: "XV.ListAttr", attr: "propername"} ]}, {kind: "XV.ListColumn", classes: "last", components: [ {kind: "XV.ListAttr", attr: "uri"} ]} ]} ]} ] }); XV.registerModelList("XM.UserAccountRelation", "XV.UserAccountList");

This is actually what’s in /path/to/xtuple/enyo-client/application/source/views/list.js – the entire highlighted part. All I did was add this to “components” after line 18:

{kind: "XV.ListColumn", classes: "last", components: [ {kind: "XV.ListAttr", attr: "uri"} ]}

I found this at random after a lot of trial and error. It’s strange because if you encapsulate that code with

XT.extensions.sip_account.initList = function () { //Code here };

as is done with parameter.js and workspace.js (and in the xTuple tutorial you are supposed to do that with a new business object), it doesn’t work. I have no idea why. This might be ‘wrong’ or against xTuple coding norms; I will find out and update this post ASAP. But it does work this way. * shrugs *

That said, as we’ve created the list.js file, we need to ad it to our package by editing /path/to/xtuple-extensions/source/sip_account/client/views/package.js:

enyo.depends( "list.js", "workspace.js" );

That’s all. Rebuild the app and restart your server and when you select Setup > User Accounts in the web app you should see the Sip URI displayed on the User Accounts that have the Sip Account data. Add a new User Account to try this out.

US Navy looks to Norway for answer to under-armed Littoral Combat Ship

Ars Technica - Fri, 25/07/2014 - 15:51
The USS Coronado (LCS-4) underway in April 2014. The Coronado will test-launch the Norwegian-built Naval Strike Missile later this year off the coast of California. U.S. Navy photo by Chief Mass Communication Specialist Keith DeVinne

This fall, the US Navy will test a new weapon system—at least, one that’s new to the US—aboard the Littoral Combat Ship (LCS) USS Coronado somewhere off the California coast. In search of some way to beef up the firepower of the oft-maligned LCS class, the Navy will test-launch a missile that can fly up to 100 miles and strike targets at sea or on land. And that missile comes not from one of the big names in the US defense industry but from Norway.

The LCS was supposed to be a modular, flexible ship that could get in close to shore and support troops with missile fire. But when the US Army cancelled the Non-Line of Site (NLOS) missile program, it took the teeth out of that idea—the modular missile system was also supposed to be the LCS’s go-to weapon for longer-range land and sea attack.

Since then, the only missile that has even been fired from an LCS-class ship is the RIM-116 Rolling Airframe Missile, an anti-air point defense missile system tested aboard the USS Freedom in 2009 and 2010. And concerns about the ship’s underpowered armament and inherent lack of flexibility without a missile capability made it an expensive sitting duck in “contested” waters—in other words, against any adversary that could put even a patrol boat armed with anti-ship missiles to sea. As a result, the Navy cut the number of LCS ships to be built in half and froze the purchase of ships not already under construction while it looks at alternatives.

Read 4 remaining paragraphs | Comments

Security updates for Friday

LWN.net - Fri, 25/07/2014 - 15:45

CentOS has updated kernel (C7; C6; C5: two vulnerabilities) and qemu-kvm (C7: many vulnerabilities).

Debian has updated apache2 (three vulnerabilities) and transmission (code execution).

Fedora has updated httpd (F20: multiple vulnerabilities), ipython (F20; F19: code execution), java-1.7.0-openjdk (F19: multiple vulnerabilities), java-1.8.0-openjdk (F20; F19: multiple vulnerabilities), and kernel (F19: multiple vulnerabilities).

Oracle has updated enterprise kernel (OL7: three vulnerabilities) and kernel (OL5: two vulnerabilities).

Red Hat has updated openstack-nova (OSP5.0: information disclosure), openstack-swift (OSP5.0: cross-site scripting), python-django-horizon (OSP5.0: three vulnerabilities), and qemu-kvm-rhev (OSP4.0, OSP3.0: multiple vulnerabilities).

The App I Used to Break Into My Neighbor’s Home

Wired - Fri, 25/07/2014 - 15:25
Leave your ring of cut-brass secrets unattended on your desk at work, at a bar table while you buy another round, or in a hotel room, and any stranger---or friend---can upload your keys to their online collection.

Photos of the Moto X+1 leak, show wooden back

Ars Technica - Fri, 25/07/2014 - 15:18
Android Police

Android Police has gotten a hold of leaked photos of an upcoming Motorola follow-up to the Moto X, the oddly named Moto X+1. The pictures show a device that looks a lot like the Moto X, complete with a presumably customizable wooden back.

According to the leak, the X+1 will be bigger than the Moto X. The sequel is reportedly joining the rest of the flagship phones and jumping from a 4.7-inch screen to 5.1 inches. For Motorola, it's good to have a flagship with a screen matching the size of the competition, but if this device replaces the Moto X, it means one of the few choices for a smaller, relatively high-end phone will be going away. Like the Moto E, the earpiece cutout is mirrored on the bottom of the device, where it is used for the microphone.

On the back, the camera module looks pretty big, which usually indicates optical image stabilization, though the article doesn't mention it. The dots to the left and right of the camera module are dual LED flashes. Like the Moto X, the back is said to be non-removable, and there's no microSD slot.

Read 3 remaining paragraphs | Comments

Steve Kemp: The selfish programmer

Planet Debian - Fri, 25/07/2014 - 14:16

Once upon a time I wrote a piece of software for scheduling the classes available to a college.

There was a bug in the scheduler: Students who happened to be named 'Steve Kemp' had a significantly higher chance (>=80% IIRC) of being placed in lessons where the class makeup was more than 50% female.

This bug was never fixed. Which was nice, because I spent several hours both implementing and disguising this feature.

I'm was a bad coder when I was a teenager.

These days I'm still a bad coder, but in different ways.

Wouter Verhelst: Multiarchified eID libraries for Debian

Planet Debian - Fri, 25/07/2014 - 12:44

A few weeks back, I learned that some government webinterfaces require users to download a PDF files, sign them with their eID, and upload the signed PDF document. On Linux, the only way to do this appeared to be to download Adobe Reader for Linux, install the eID middleware, make sure that the former would use the latter, and from there things would just work.

Except for the bit where Adobe Reader didn't exist in a 64-bit version. Since the eid middleware packages were not multiarch ready, that meant you couldn't use Adobe Reader to create signatures with your eID card on a 64-bit Linux distribution. Which is, pretty much, "just about everything out there".

For at least the Debian packages, that has been fixed now (I still need to handle the RPM side of things, but that's for later). When I wanted to test just now if everything would work right, however...

... I noticed that Adobe no longer provides any downloads of the Linux version of Adobe Reader. They're just gone. There is an ftp.adobe.com containing some old versions, but nothing more recent than a 5.x version.

Well, I suppose that settles that, then.

Regardless, the middleware package has been split up and multiarchified, and is ready for early adopters. If you want to try it out, you should:

  • run dpkg --add-architecture i386 if you haven't yet enabled multiarch
  • Install the eid-archive package, as usual
  • Edit /etc/apt/sources.list.d/eid.list, and enable the continuous repository (that is, remove the # at the beginning of the line)
  • run dpkg-reconfigure eid-archive, so that the key for the continuous repository is enabled
  • run apt-get update
  • run apt-get -t continuous install eid-mw to upgrade your middleware to the version in continuous
  • run apt-get -t continuous install libbeidpkcs11-0:i386 to install the 32-bit middleware version.
  • run your 32-bit application and sign things.

You should, however, note that the continuous repository is named so because it contains the results of our continuous integration system; that is, every time a commit is done to the middleware, packages in this repository are updated automatically. This means the software in the continuous repository might break. Or it might eat your firstborn. Or it might cause nasal daemons. As such, FedICT does not support these versions of the middleware. Don't try the above if you're not prepared to deal with that...

*And then there were three*

OS news - Fri, 25/07/2014 - 12:37
I'm lucky. My financial situation allows me to buy several phones and tablets every year to keep up with the goings-on of all the major - and some of the minor - platforms currently competing for prime real estate in your precious pockets. It also means that I am lucky from a psychological point of view - by being able to buy several devices every year, I never fall into the all-too-common trap of choice-supportive bias. I don't have to rationalise my device purchases after the fact, so I won't have to employ all sorts of mental gymnastics to solve any states of cognitive dissonance caused by hardware and software flaws - the number one cause of irrational fanboyism. And so, I try to rotate my phone of choice around as much as possible. I enjoy jumping from Android to my N9, then onwards to Sailfish, back to Android, and then have some fun with Symbian on my E7 - and beyond. I've got a long list of platforms I want to add to the collection - one white BlackBerry Passport please - but in general, I'm pretty well-rounded. Read more on this exclusive OSNews article...

This Week’s Apple Rumors, Ranked From Dumbest to Most Plausible

Wired - Fri, 25/07/2014 - 11:48
This week's Apple rumors hint at a new 12-inch MacBook and 4K display.

Absurd Creature of the Week: Satanic Leaf-Tailed Gecko Wears the World’s Most Unbelievable Camo

Wired - Fri, 25/07/2014 - 11:48
“What’s in a name?” Shakespeare once asked, apparently in Romeo and Juliet, which I just learned from Google because I did not pay attention in that class in college. “That which we call a rose by any other name would smell as sweet.” I think this means that a name doesn’t matter for much, because […]

Can Letting Trucks Drive Faster Make Roads Safer?

Wired - Fri, 25/07/2014 - 11:48
The UK expects to save lives and money by letting trucks drive at 50 mph instead of 40 mph on some highways.

One of These Monets Was Made by a Nanoprinter

Wired - Fri, 25/07/2014 - 11:48
Look closely. Can you tell the difference between these two images?

How Designers Are Reinventing Trauma Care to Save Soldiers’ Lives

Wired - Fri, 25/07/2014 - 11:48
Trauma bays and operating rooms are designed to run as smoothly as possible, but inefficiencies still plague the system.

At Long Last, a Universal Shopping Cart for the Web

Wired - Fri, 25/07/2014 - 11:48
Shopping cart attrition is a huge problem for online retailers. This startup says it has the solution.

Tech Time Warp of the Week: Watch Steve Jobs Talk About Turning a Genius’ Brain Into a Computer

Wired - Fri, 25/07/2014 - 11:48
Steve Jobs knew how to make an entrance. In 1985, he descended onto the grounds of Svaneholm Castle in Sweden in a chopper to discuss the impact of the personal-computing revolution on education. Back then, we were just on the cusp of what he called the era of “free intellectual energy.” And this revolution, he assured […]

Tech Giants Begin Recruiting for the Next Big Platform Wars

Wired - Fri, 25/07/2014 - 11:48
The Internet of Things is still young, but it’s real. There are already dozens of internet-connected devices available, ranging from home-automation tools to wearable fitness trackers. And it’s about to start growing at an even faster pace. According a new survey by market research firm Evans Data, 17 percent of the world’s software developers are […]

This Tiny Printer Is a Physical Ticker Tape for the Internet

Wired - Fri, 25/07/2014 - 11:33
This cloud-connected device prints out a personalized feed of news, messages, and amusements onto standard thermal receipt paper.

Brainy, Badass Lucy Is an Amazing Ride That Ends Up Losing Speed

Wired - Fri, 25/07/2014 - 11:32
Luc Besson's new sci-fi thriller Lucy is about a woman who gets superhuman powers after a bag of drugs she's forced to smuggle bursts inside her. Sounds dope, right? It is. Until the end, when it isn't.

Syndicate content