Planet Debian

Syndicate content
Planet Debian -
Updated: 1 hour 5 min ago

Clint Adams: Before the tweet in Grand Cayman

Wed, 2014-04-23 22:13

Jebediah boarded the airplane. It was a Bombardier CRJ900 with two turbofan jet engines. Run by SPARK, a subset of Ada. He sat down in his assigned seat and listened to the purser inform him that he was free to use his phone door-to-door on all Delta Connection flights. As long as the Airplane Mode was switched on. Jebediah knew that this was why Delta owned 49% of Virgin Atlantic.

On the plane ride, a woman in too much makeup asked Jebediah to get the man next to him so she could borrow his copy of the Economist. The man said she could keep it and that it was old. He had stubby little fingers. She was foreign.

At Terminal 2, they passed by Kids on the Fly, an exhibit of the Chicago Children's Museum at Chicago O'Hare International Airport. A play area. Jebediah thought of Dennis.

The Blue Line of the Chicago Transit Authority was disrupted by weekend construction, so they had to take a small detour through Wicker Park. Wicker Park is a neighborhood. In Chicago. Jebediah looked at Glazed & Infused Doughnuts. He wondered if they made doughnuts there. Because of the meeting, he knocked someone off a Divvy bike and pedaled it to the Loop.

The Berghoff was opened in 1898 by Herman Joseph Berghoff.

Once he got to the Berghoff, he got a table for seven on the west wall. He eyed the electrical outlet and groaned. He had brought 3 cigarette lighter adapters with him, but nothing to plug into an AC outlet. How would he charge his device? An older gentleman came in. And greeted him.

“Hello, I'm Detective Chief Inspector Detweiler. Did you bring the evidence?” Said the man.

Jebediah coughed and said that he had to go downstairs. He went downstairs and looked at the doors. He breathed a sigh of relief. Seeing the word “washroom” in print reminded him of his home state of Canada. Back at the table he opened a bag, glared angrily at a cigarette lighter adapter, and pulled out a Palm m125. Running Palm OS 4.0. He noticed a third person at the table. It was the ghost of Bob Ross.

“Меня зовут кайзер созей,” said the ghost of Bob Ross. It was good for him to communicate telepathically with Sarah Palin.

“This has eight megabytes of RAM,” Jebediah informed the newcomer. Bob Ross's ghost right-clicked on his face and rated him one star. Jebediah looked angrily at the AC outlet and fidgeted with two of his cigarette lighter adapters.

DCI Detweiler said, “I had a Handspring Visor Deluxe,” and pulled out a Samsung Galaxy Tab 3 8.0 eight-inch Android-based tablet computer running the Android 4.2.2 Jelly Bean operating system by Google. “This also has eight megabytes of RAM,” he continued. “As you requested, I brought the video of your nemesis at the Robie House.

Jebediah stared at the tablet. He could see a compressed video file, compressed with NetBSD compression and GNU encryption. It was on the tablet. “Some bridges you just don't cross,” he hissed.

Part 2

AUD:USD 1.0645

donuts:dozen 12

Gold $1318.60

Detective Seabiscuit sucked on a throat lozenge. “Who are you again?” he asked the toll-booth operator.

“I said my name is Rogery Sterling,” replied the toll-booth operator.

“Rajry what?”

“I said my name is Rogery Sterling,” replied the toll-booth operator. Again.

“Where am I?”

“Look, I'm telling you that that murder you're investigating was caused by software bugs in the software.”

“Are we on a boat?”

“Look at the diagram. This agency paid money to introduce, quite deliberately, weaknesses in the security of this library, through this company here, and this company here.”

“Library, oh no. I have overdue fees.”

“And they're running a PR campaign to increase use of this library. Saying that the competing options are inferior. But don't worry, they're trying to undermine those too.”

Detective Seabiscuit wasn't listening. He had just remembered that he needed to stop by the Robie House.

Categories: FLOSS Project Planets

C.J. Adams-Collier: Really large NLP corpora

Wed, 2014-04-23 20:00

Jeeze people. You’re all noisy. I’m sure it was all done for posterity’s sake.

23M irclogs/MagNET/#perl.log 29M irclogs/freenode/#mysql.log 36M irclogs/freenode/#debian.log 37M irclogs/foonetic/#xkcd.log 39M irclogs/OFTC/#debian.log 43M irclogs/freenode/#jquery.log 44M irclogs/freenode/#perl.log
Categories: FLOSS Project Planets

C.J. Adams-Collier: Relatively high sustained rates detected along I-405

Wed, 2014-04-23 19:22
$ scp .'s password: sh1-disk-20140420T070034.xz 76% 534MB 11.1MB/s 00:14 ETA

Come on little internet! You can do it! You can push 100Mbit!

I remember when this was the fastest I could send data across my LAN. Not bad for a 20 mile shot up I-405. Sorry if I caused any congestion there, folks. I’m going to have to send it back out again when the new equipment gets racked at the new DC.

Categories: FLOSS Project Planets

Russ Allbery: On learning, growth, and trust

Wed, 2014-04-23 18:55

Here are two separate ideas about programming, Internet security, Internet architecture, and free software. Both of them are fundamental to everything those of us who work on free software are doing.

  1. Writing secure and reliable code is a highly complex and demanding task. It's something that one has to learn, like any other skilled profession. It's not something we're very good at teaching via any mechanism other than apprenticeship and experimentation. The field is changing quickly; if you took ten years off from writing security-critical code, you would expect to have to learn multiple new tools (static analysis, testing techniques, security features), possibly new programming languages, and not infrequently new ways of thinking about threat models and vulnerabilities.

  2. Nearly every computer user trusts tens of thousands of other programmers and millions of lines of code with their day-to-day computer security and reliability, without auditing that code themselves. Even if you have the skill required to audit the code (and very, very few people have the skill to audit all of the code that they use), you do not have the time. Therefore, our computer security is built on trust. We're trusting other programmers not to be malicious, which is obvious, but we're also trusting other programmers to be highly skilled, careful, cautious (but still fast and productive, since we quickly abandon software that isn't "actively developed"), and constantly adopting new techniques and treat models.

I think both of those principles are very widely understood and widely acknowledged. And, as we all know, both of those principles have failure modes, and those failures mean that our computers are nowhere near as secure as we would like them to be.

There has been quite a lot of technical discussion about both of these principles in recent days and months, ranging from better code analysis and testing through the flaws in particular programming languages to serious questions about the trust model we use for verifying the code that we're running. I'm going to switch gears away from that discussion for a moment to talk about a social aspect.

When a piece of code that one is using has a security vulnerability, it is not unusual to treat that as a trust failure. In other words, technical flaws are very quickly escalated to social flaws. This is less likely among practitioners, since we're all painfully aware of how many bugs we have in our own code, but it's still not unheard of, particularly if the authors of the code do not immediately and publicly show a socially-acceptable level of humility and contrition (in the middle of what is often a horrifically stressful experience).

I think this reaction comes largely from fear. Anyone who has given it a moment's thought is painfully aware of just how much code they are running on trust, and just how many ways it could be compromised, accidentally or maliciously. And how frequently that code is compromised. The less control one has over a situation, the more terrifying it is, and the cold reality is that we have very little control over our computer security. There is a natural tendency, when afraid, to look for targets for that fear.

Now, go back and think about the first principle.

Anyone who has ever worked on or near free software is painfully aware that we have far more good ideas about how to improve computing and security than we have skilled resources to execute on those ideas. My own backlog of things that I've already thought about, know would be good ideas, and simply have to implement is probably longer than my remaining lifespan. I suspect that's the case for nearly all of us.

In other words, we have a severe shortage of programmers who care and who have skill. We desperately need more skilled programmers who can write secure and reliable code. We may (and I think do) also need better tools, techniques, languages, protocols, and all the other machinery that we, as technical people, spend most of our time thinking about. But none of that changes the fact that we need more skilled people. In fact, it makes that need more acute: in addition to skilled people to write the code we use, we need skilled people to write the tools.

Skilled people are not born. They're made. And in professions where training techniques are still in their infancy and where we don't have a good formal grasp on which techniques work, those skilled people are made primarily through apprenticeship, experimentation, and learning from failure.

Worse, people who were skilled do not remain skilled without continually participating in that learning process. See the above point about a fast-changing field with evolving best practices. It's not enough to know how to write secure code to the best known practices today, or even enough to retrofit all of your existing code to current knowledge (which is often so large of an effort as to be practically impossible). You have to constantly, continually learn more, for which there is no reliable formal training.

We have to try, fail, try again, and fail better.

But failure that leads to a security vulnerability is treated as a loss of trust. We trusted that person to write secure code that we could use. They failed. Now we can't trust them. Based on the trust model of security, we should revoke their ability to try again and instead rely on people who have not failed, since that will make us more secure.

Except now we just broke the learning process. And there's no such thing as a programmer who can stop learning. So what does that do to our resource pool?

It's sadly ironic, but I believe the free software community writ large has a very serious collaboration problem: we do not tolerate each other's learning processes. This leads to a wide variety of social failures around hostile communities and the failures of meritocracy that other people have talked about at much greater length. But even if you set that all aside, it threatens our security. We need secure code, a lot of it, a lot more than we have right now. To get that code, we need people who can write it. We need to grow, encourage, and support those people and enable their learning processes.

Code is written by people. If we rip people apart when they write bad, insecure code, we don't get better, secure code. We get fewer people writing security code. We get far fewer people writing security code in public, since some of the people who haven't been ripped apart will look at that experience and say, "No way am I going near that problem area. It's too scary. I don't want to end up like those programmers."

Fewer people writing security code means fewer people learning how to write better security code.

Fewer people capable of writing good, secure code is not a solution to any of our problems.

If we do not tolerate, support, and encourage the learning process required to become a skilled programmer, or maintain one's skill in programming, we are destroying our future as a community.

When you find code that is broken and badly written, you have found a problem that should be reported, analyzed, and corrected. You have also found a programmer who is about to have one of two very different types of experiences. Either they are about to learn how to become a better programmer, or they are about to be publicly shamed, humiliated, and treated as untrustworthy. Which branch they take is partly up to them, but it's also heavily influenced by how all of us react socially to the discovery of bad code.

One of those branches leads to more good, secure code being written in the future. The other does not.

Categories: FLOSS Project Planets

David Pashley: Working with development servers

Wed, 2014-04-23 11:31

I can’t believe that this is not a solved problem by now, but my Google-fu is failing me. I’m looking for a decent, working extension for Chrome that can redirect a list of hosts to a different server while setting the Host: header to the right address. Everything I’ve found so far assumes that you’re running the servers on different urls. I’m using the same URL on different servers and don’t want to mess around with /etc/hosts.

Please tell me something exists to do this?

The post Working with development servers appeared first on David

Categories: FLOSS Project Planets

Gunnar Wolf: DrupalCamp starting in 5... 4... 3... 2... ( → #DrupalCampMX )

Wed, 2014-04-23 10:26

Ok, so the day has come: Today begins the much awaited Drupal Camp Mexico City, yay!

For those that cannot make it to Mexico City, I understand understood1 we would have live streaming of at least one of the rooms, but anyway, talks will be recorded, and will be put online later on.

As for the talks schedule, here you have it. Yes, today my workmate and I will be giving a simple introduction to having a useful basic Drupal install. Today is the tutorials / workshops / BoF / hackathon day, and Thursday and Friday will be the more traditional talks days. Several of the talks on Thursday are grouped under the SymfonyDay track and will refer to the framework that serves as a base for Drupal 8.

Anyway, for the Tweetheads among the readers of this post, I understand information will flow under the #DrupalCampMX tag.

  • 1. I cannot find the link to the information, but it might appear later on... /mehopes
Categories: FLOSS Project Planets

Petter Reinholdtsen: Install hardware dependent packages using tasksel (Isenkram 0.7)

Wed, 2014-04-23 08:50

It would be nice if it was easier in Debian to get all the hardware related packages relevant for the computer installed automatically. So I implemented one, using my Isenkram package. To use it, install the tasksel and isenkram packages and run tasksel as user root. You should be presented with a new option, "Hardware specific packages (autodetected by isenkram)". When you select it, tasksel will install the packages isenkram claim is fit for the current hardware, hot pluggable or not.

The implementation is in two files, one is the tasksel menu entry description, and the other is the script used to extract the list of packages to install. The first part is in /usr/share/tasksel/descs/isenkram.desc and look like this:

Task: isenkram Section: hardware Description: Hardware specific packages (autodetected by isenkram) Based on the detected hardware various hardware specific packages are proposed. Test-new-install: mark show Relevance: 8 Packages: for-current-hardware

The second part is in /usr/lib/tasksel/packages/for-current-hardware and look like this:

#!/bin/sh # ( isenkram-lookup isenkram-autoinstall-firmware -l ) | sort -u

All in all, a very short and simple implementation making it trivial to install the hardware dependent package we all may want to have installed on our machines. I've not been able to find a way to get tasksel to tell you exactly which packages it plan to install before doing the installation. So if you are curious or careful, check the output from the isenkram-* command line tools first.

The information about which packages are handling which hardware is fetched either from the isenkram package itself in /usr/share/isenkram/, from or from the APT package database (using the Modaliases header). The APT package database parsing have caused a nasty resource leak in the isenkram daemon (bugs #719837 and #730704). The cause is in the python-apt code (bug #745487), but using a workaround I was able to get rid of the file descriptor leak and reduce the memory leak from ~30 MiB per hardware detection down to around 2 MiB per hardware detection. It should make the desktop daemon a lot more useful. The fix is in version 0.7 uploaded to unstable today.

I believe the current way of mapping hardware to packages in Isenkram is is a good draft, but in the future I expect isenkram to use the AppStream data source for this. A proposal for getting proper AppStream support into Debian is floating around as DEP-11, and GSoC project will take place this summer to improve the situation. I look forward to seeing the result, and welcome patches for isenkram to start using the information when it is ready.

If you want your package to map to some specific hardware, either add a "Xb-Modaliases" header to your control file like I did in the pymissile package or submit a bug report with the details to the isenkram package. See also all my blog posts tagged isenkram for details on the notation. I expect the information will be migrated to AppStream eventually, but for the moment I got no better place to store it.

Categories: FLOSS Project Planets

Gergely Nagy: GSoC2014: syslog-ng accepted projects

Wed, 2014-04-23 08:01

The Google Summer of Code 2014 programme reached another milestone recently: the accepted proposals were published, and over a thousand students were selected by nearly two hundred mentoring organisations, among them the syslog-ng project. We will be working with four students this year (twice we worked with last year), with more mentors, on a wider selection of projects. It was a tough decision to select the proposals, we received some very strong work this year.

We would like to express our gratitude to both Debian, for giving us an extra slot (so we could accept four students instead of three), and Google and Carol Smith in particular, for allowing it, and putting up with our fumbling during the process.

The accepted projects and students are:

Good luck to all students, we're looking forward to working with you throughout the summer! Happy hacking!

Categories: FLOSS Project Planets

Andrew Pollock: [life] Day 85: Mostly a day off for me

Wed, 2014-04-23 02:37

Zoe slept solidly all night. She woke up a little before 6am, wanting a cuddle, but it was still dark, so she went back to sleep for another half an hour or so. It was actually nice to get that extra 30 minutes to have a leisurely wake up myself.

Sarah wanted to pick up Zoe at 7:45am to get away and get a camp site, so when Zoe finally woke up for the day, we didn't muck around too much. She announced she wanted banana and oat pancakes, but we were out of bananas. I offered her the opportunity to scooter down to the Hawthorne Garage to get some if she went and got dressed. She decided that'd be good.

I had a 10am appointment in the city with an intellectual property lawyer to talk about patents, so I had this grand plan of trying to squeeze in a run after Zoe was picked up and before I'd have to head into the city, so I got into my running gear, and we headed down to acquire some bananas.

We whipped up the pancakes, and then after a couple of mouthfuls of hers, Zoe declared she didn't like it and wanted Cheerios instead. Oh well. It was nice to get out of the house early in the morning, and it helped get Zoe moving.

Sarah ended up getting here closer to 8:30am, which made it a little too tight to go for a run, have a shower and get into the city, so I scrapped the run and pottered around at home instead for a bit, before driving into the city.

My goodness casual parking in the city is exorbitant. It cost me $35 for under an hour. I got some good advice from the lawyer, so I know where to proceed from here.

Next I headed down to the Valley to get my orientation at River City Labs, but had I read my email before leaving the city, I'd have discovered that the lady giving me the orientation had to leave early because her daughter was ill. It cost me $6 drive into the car park in the Valley, take the elevator down, read my email on my phone and pay my ticket and leave again. Lesson learned.

I decided to do the grocery shopping that I hadn't done yesterday while I waited for Anshu to come over.

Categories: FLOSS Project Planets

Steve Kemp: I've not commented on security for a while

Tue, 2014-04-22 17:14

Unless you've been living under a rock, or in a tent (which would make me slightly jealous) you'll have heard about the recent heartbleed attack many times by now.

The upshot of that attack is that lots of noise was made about hardening things, and there is now a new fork of openssl being developed. Many people have commented about "hardening Debian" in particular, as well as random musing on hardening software. One or two brave souls have even made noises about auditing code.

Once upon a time I tried to setup a project to audit Debian software. You can still see the Debian Security Audit Project webpages if you look hard enough for them.

What did I learn? There are tons of easy security bugs, but finding the hard ones is hard.

(If you get bored some time just pick your favourite Editor, which will be emacs, and look how /tmp is abused during the build-process or in random libraries such as tramp [ tramp-uudecode].)

These days I still poke at source code, and I still report bugs, but my enthusiasm has waned considerably. I tend to only commit to auditing a package if it is a new one I install in production, which limits my efforts considerably, but makes me feel like I'm not taking steps into the dark. It looks like I reported only three security isseus this year, and before that you have to go down to 2011 to find something I bothered to document.

What would I do if I had copious free time? I wouldn't audit code. Instead I'd write test-cases for code.

Many many large projects have rudimentary test-cases at best, and zero coverage at worse. I appreciate writing test-cases is hard, because lots of times it is hard to test things "for real". For example I once wrote a filesystem, using FUSE, there are some built-in unit-tests (I was pretty pleased with that, you could lauch the filesystem with a --test argument and it would invoke the unit-tests on itself. No separate steps, or source code required. If it was installed you could use it and you could test it in-situ). Beyond that I also put together a simple filesystem-stress script, which read/wrote/found random files, computes MD5 hashes of contents, etc. I've since seen similar random-filesystem-stresstest projects, and if they existed then I'd have used them. Testing filesystems is hard.

I've written kernel modules that have only a single implicit test case: It compiles. (OK that's harsh, I'd usually ensure the kernel didn't die when they were inserted, and that a new node in /dev appeared ;)

I've written a mail client, and beyond some trivial test-cases to prove my MIME-handling wasn't horrifically bad there are zero tests. How do you simulate all the mail that people will get, and the funky things they'll do with it?

But that said I'd suggest if you're keen, if you're eager, if you want internet-points, writing test-cases/test-harnesses would be more useful than randomly auditing source code.

Still what would I know, I don't even have a beard..

Categories: FLOSS Project Planets

Daniel Pocock: Automatically creating repackaged upstream tarballs for Debian

Tue, 2014-04-22 16:34

One of the less exciting points in the day of a Debian Developer is the moment they realize they have to create a repackaged upstream source tarball.

This is often a process that they have to repeat on each new upstream release too.

Wouldn't it be useful to:

  • Scan all the existing repackaged upstream source tarballs and diff them against the real tarballs to catalog the things that have to be removed and spot patterns?
  • Operate a system that automatically produces repackaged upstream source tarballs for all tags in the upstream source repository or all new tarballs in the upstream download directory? Then the DD can take any of them and package them when he wants to with less manual effort.
  • Apply any insights from this process to detect non-free content in the rest of the Debian archive and when somebody is early in the process of evaluating a new upstream project?
Google Summer of Code is back

One of the Google Summer of Code projects this year involves recursively building Java projects from their source. Some parts of the project, such as repackaged upstream tarballs, can be generalized for things other than Java. Web projects including minified JavaScript are a common example.

Andrew Schurman, based near Vancouver, is the student selected for this project. Over the next couple of weeks, I'll be starting to discuss the ideas in more depth with him. I keep on stumbling on situations where repackaged upstream tarballs are necessary and so I'm hoping that this is one area the community will be keen to collaborate on.

Categories: FLOSS Project Planets

Ritesh Raj Sarraf: Basis B1

Tue, 2014-04-22 15:32


Starting yesterday, I am a happy user of the Basis B1 (Carbon Edition) Smart Watch

The company recently announced being acquired by Intel. Overall I like the watch. The price is steep, but if you care of a watch like that, you may as well try Basis. In case you want to go through the details, there's a pretty comprehensive review here.

Since I've been wearing it for just over 24hrs, there's not much data to showcase a trend. But the device was impressively precise in monitoring my sleep.


Pain points - For now, sync is the core of the pains. You need either a Mac or a Windows PC. I have a Windows 7 VM with USB Passthru, but that doesn't work. There's also an option to sync over mobile (iOS and Android). That again does not work for my Chinese Mobile Handset running MIUI.

AddThis:  Categories: Keywords: 
Categories: FLOSS Project Planets

C.J. Adams-Collier: AD Physical to Virtual conversion… Continued!

Tue, 2014-04-22 14:54

So I wasn’t able to complete the earlier attempt to boot the VM. Something to do with the SATA backplane not having enough juice to keep both my 6-disk array and the w2k8 disk online at the same time. I had to dd the contents off of the w2k8 disk and send it to the SAN via nc. And it wouldn’t write at more than 5.5MB/s, so it took all day.

cjac@foxtrot:~$ sudo dd if=/dev/sdb | \ pv -L 4M -bWearp -s 320G | \ nc 4242 cjac@san0:~$ nc -l 4242 | \ pv -L 4M -bWearp -s 320G | \ sudo dd of=/dev/vg0/ad0

Anyway, I’ve got a /dev/vg0/ad0 logical volume all set up now which I’m exporting to the guest as USB.

Here’s the libvirt xml file: win2k8.xml

No indication as to how long this will take. But I’ll be patient. It will be nice to have the AD server back online.

[edit 20140422T172033 -0700]

… Well, that didn’t work …

[edit 20140422T204322 -0700]
Maybe if I use DISM…?

[edit 20140422T204904 -0700]

Yup. That did ‘er!

C:\>dism /image:c:\ /add-driver /driver:d:\win7\amd64\VIOSTOR.INF

Categories: FLOSS Project Planets

Axel Beckert: GNU Screen 4.2.0 in Debian Experimental

Tue, 2014-04-22 14:22
About a month ago, on 20th of March, GNU Screen had its 27th anniversary.

A few days ago, Amadeusz Sławiński, GNU Screen’s new primary upstream maintainer, released the status quo of Screen development as version 4.2.0 (probably to distinguish it from all those 4.1.0 labeled development snapshots floating around in most Linux distributions nowadays).

I did something similar and uploaded the status quo of Debian’s screen package in git as 4.1.0~20120320gitdb59704-10 to Debian Sid shortly afterwards. That upload should hit Jessie soon, too, resolving the following two issues also in Testing:

  • #740301: proper systemd support – Thanks Josh Triplett for his help!
  • #735554: fix for multiuser usage – Thanks Martin von Wittich for spotting this issue!

That way I could decouple these packaging fixes/features from the new upstream release which I uploaded to Debian Experimental for now. Testers for the 4.2.0-1 package are very welcome!

Oh, and by the way, that upstream comment (or ArchLinux’s according announcement) about broken backwards compatibility with attaching to running sessions started with older Screen releases doesn’t affected Debian since that has been fixed in Debian already with the package which is in Wheezy. (Thanks again Julien Cristau for the patch back then!)

While there are bigger long-term plans at upstream, Amadeusz is already working on the next 4.x release (probably named 4.2.1) which will likely incorporate some of the patches floating around in the Linux distributions’ packages. At least SuSE and Debian offered their patches explicitly for upstream inclusion.

So far already two patches found in the Debian packages have been obsoleted by upstream git commits after the 4.2.0 release. Yay!

Categories: FLOSS Project Planets

Martin Pitt: Booting Ubuntu with systemd: Test packages available

Tue, 2014-04-22 12:54

On the last UDS we talked about migrating from upstart to systemd to boot Ubuntu, after Mark announced that Ubuntu will follow Debian in that regard. There’s a lot of work to do, but it parallelizes well once developers can run systemd on their workstations or in VMs easily and the system boots up enough to still be able to work with it.

So today I merged our systemd package with Debian again, dropped the systemd-services split (which wasn’t accepted by Debian and will be unnecessary now), and put it into my systemd PPA. Quite surprisingly, this booted a fresh 14.04 VM pretty much right away (of course there’s no Plymouth prettiness). The main two things which were missing were NetworkManager and lightdm, as these don’t have an init.d script at all (NM) or it isn’t enabled (lightdm). Thus the PPA also contains updated packages for these two which provide a proper systemd unit. With that, the desktop is pretty much fully working, except for some details like cron not running. I didn’t go through /etc/init/*.conf with a small comb yet to check which upstart jobs need to be ported, that’s now part of the TODO list.

So, if you want to help with that, or just test and tell us what’s wrong, take the plunge. In a 14.04 VM (or real machine if you feel adventurous), do

sudo add-apt-repository ppa:pitti/systemd sudo apt-get update sudo apt-get dist-upgrade

This will replace systemd-services with systemd, update network-manager and lightdm, and a few libraries. Up to now, when you reboot you’ll still get good old upstart. To actually boot with systemd, press Shift during boot to get the grub menu, edit the Ubuntu stanza, and append this to the linux line: init=/lib/systemd/systemd.

For the record, if pressing shift doesn’t work for you (too fast, VM, or similar), enable the grub menu with

sudo sed -i '/GRUB_HIDDEN_TIMEOUT/ s/^/#/' /etc/default/grub sudo update-grub

Once you are satisfied that your system boots well enough, you can make this permanent by adding the init= option to /etc/default/grub (and possibly remove the comment sign from the GRUB_HIDDEN_TIMEOUT lines) and run sudo update-grub again. To go back to upstart, just edit the file again, remove the init=sudo update-grub again.

I’ll be on the Debian systemd/GNOME sprint next weekend, so I feel reasonably well prepared now.

Categories: FLOSS Project Planets

Erich Schubert: Kernel-density based outlier detection and the need for customization

Tue, 2014-04-22 09:39
Outlier detection (also: anomaly detection, change detection) is an unsupervised data mining task that tries to identify the unexpected. Most outlier detection methods are based on some notion of density: in an appropriate data representation, "normal" data is expected to cluster, and outliers are expected to be further away from the normal data. This intuition can be quantified in different ways. Common heuristics include kNN outlier detection and the Local Outlier Factor (which uses a density quotient). One of the directions in my dissertation was to understand (also from a statistical point of view) how the output and the formal structure of these methods can be best understood. I will present two smaller results of this analysis at the SIAM Data Mining 2014 conference: instead of the very heuristic density estimation found in above methods, we design a method (using the same generalized pattern) that uses a best-practise from statistics: Kernel Density Estimation. We aren't the first to attempt this (c.f. LDF), but we actuall retain the properties of the kernel, whereas the authors of LDF tried to mimic the LOF method too closely, and this way damaged the kernel. The other result presented in this work is the need to customize. When working with real data, using "library algorithms" will more often than not fail. The reason is that real data isn't as nicely behaved - it's dirty, it seldom is normal distributed. And the problem that we're trying to solve is often much narrower. For best results, we need to integrate our preexisting knowledge of the data into the algorithm. Sometimes we can do so by preprocessing and feature transformation. But sometimes, we can also customize the algorithm easily. Outlier detection algorithms aren't black magic, or carefully adjusted. They follow a rather simple logic, and this means that we can easily take only parts of these methods, and adjust them as necessary for our problem at hand! The article persented at SDM will demonstrate such a use case: analyzing 1.2 million traffic accidents in the UK (from we are not interested in "classic" density based outliers - this would be a rare traffic accident on a small road somewhere in Scotland. Instead, we're interested in unusual concentrations of traffic accidents, i.e. blackspots. The generalized pattern can be easily customized for this task. While this data does not allow automatic evaluation, many outliers could be easily verified using Google Earth and search: often, historic imagery on Google Earth showed that the road layout was changed, or that there are many news reports about the dangerous road. The data can also be nicely visualized, and I'd like to share these examples with you. First, here is a screenshot from Google Earth for one of the hotspots (Cherry Lane Roundabout, North of Heathrow airport, which used to be a double cut-through roundabout - one of the cut-throughs was removed since):
Google Earth is best for exploring this result, because you can hide and show the density overlay to see the crossroad below; and you can go back in time to access historic imagery. Unfortunately, KML does not allow easy interactions (at least it didn't last time I checked). I have also put the KML file on Google Drive. It will automatically display it on Google Maps (nice feature of Drive, kudos to Google!), but it should also allow you to download it. I've also explored the data on an Android tablet (but I don't think you can hide elements there, or access historic imagery as in the desktop application). With a classic outlier detection method, this analysis would not have been possible. However, it was easy to customize the method; and the results are actually more meaningful: instead of relying on some heuristic to choose kernel bandwidth, I opted for choosing the bandwidth by physical arguments: 50 meters is a reasonable bandwidth for a crossroad / roundabout, and for comparison a radius of 2 kilometers is used to model the typical accident density in this region (there should other crossroads within 2 km in Europe). Since I advocate reproducible science, the source code of the basic method will be in the next ELKI release. For the customization case studies, I plan to share them as a how-to or tutorial type of document in the ELKI wiki; probably also detailing data preprocessing and visualization aspects. The code for the customizations is not really suited for direct inclusion in the ELKI framework, but can serve as an example for advanced usage. Reference:
E. Schubert, A. Zimek, H.-P. Kriegel
Generalized Outlier Detection with Flexible Kernel Density Estimates
In Proceedings of the 14th SIAM International Conference on Data Mining (SDM), Philadelphia, PA, 2014. So TLDR of the story: A) try to use more established statistics (such as KDE), and B) don't expect an off-the-shelf solution to do magic, but customize the method for your problem. P.S. if you happen to know nice post-doc positions in academia:
I'm actively looking for a position to continue my research. I'm working on scaling these methods to larger data and to make them work with various real data that I can find. Open-source, modular and efficient implementations are very important to me, and one of the directions I'd like to investigate is porting these methods to a distributed setting, for example using Spark. In order to get closer to "real" data, I've started to make these approaches work e.g. on textual data, mixed type data, multimedia etc. And of course, I like teaching; which is why I would prefer a position in academia.
Categories: FLOSS Project Planets

Steve McIntyre: Linaro welcomes GSOC 2014 students

Tue, 2014-04-22 07:33

After several weeks of review and discussion, the application and selection period for the 2014 Google Summer of Code is over. 4,420 students proposed a total of 6,313 projects for this summer. From those, 1,307 students have been accepted (more details), and Linaro is one of the 190 Open Source projects that will be working with students this year.

In our first year as a GSOC mentoring organisation, we received 17 applications and Google allocated us 3 slots for student projects. It was quite a challenge to pick just 3 projects from the excellent field, and it's a shame that the limited number of slots meant we had no choice but to disappoint some people. Thanks to all those who applied!

I'm delighted to announce our 3 chosen interns for 2014:

  • Gaurav Minocha is a graduate student at the University of British Columbia, Vancouver, Canada. His project is Linux Flattened Device Tree Self-checking, mentored by Grant Likely from Linaro's Office of the CTO.
  • Ricardo de Freitas Gesuatto is a student at Federal University of São Carlos (UFSCar), Brazil. He will be working on a project entitled "Lightweight IP Stack on top of OpenDataPlane", mentored by Maxim Uvarov from the Linaro Networking Group.
  • Varad Gautam is a student at Birla Institute of Technology and Science, Pilani, India. He will be Porting UEFI to Low-Cost Embedded Platform (BeagleBoneBlack). Leif Lindholm from the Linaro Enterprise Group will be mentoring.

Please join me in welcoming these three new engineers to the Linaro team!

We have a GSOC wiki ready for our students to use at

and hopefully they will start adding content there soon about themselves and their projects (hint!). In the meantime, we have more information about our original proposals and the GSOC program in the main Linaro wiki.

Starting today, the next phase of the program is the so-called "bonding period". Students are encouraged to get to know people within Linaro (especially their mentors!) and prepare to start work on their projects, whatever is needed. The official start of the work period for GSOC is May 19th, and it runs through to August 18th. We will give updates on progress through the summer, and we're hoping to talk about our results at the next Linaro Connect in September.

Good luck, folks!

Categories: FLOSS Project Planets

Bits from Debian: Debian welcomes its 2014 GSoC students!

Tue, 2014-04-22 05:15

We're excited to announce that 19 students have been selected to work with Debian during the Google Summer of Code this year!

Here is the list of accepted students and projects:

As always, you will be able to follow their progress on the SoC coordination mailing-list

Congratulations to all the students and let's make sure we all have an amazing summer!

Categories: FLOSS Project Planets

Simon Kainz: Valerie

Tue, 2014-04-22 05:05

This will be my one and only off-topic posting, but I just have to share all my joy and happiness with all of you!

On monday, April 14th 2014, our beautiful daughter Valerie was born. As we almost live next door to our midwife, we just grabbed our stuff and walked over to the midwife's house, as my wife told me "things are starting". My wife was very glad to be able to give birth in such a beautiful, cosy and comfortable place, with no hassle, no beeping machines and nervous hospital staff running around. This helped her to "let go", and she gave birth to our beautiful daughter after about 2 hours.

I took a 4 week break from work to support my wife and daughter. This is quite involving :-) , so please forgive me if I don't reply quickly to your mails.


Categories: FLOSS Project Planets

Bits from Debian: Debian welcomes its 2014 GSoC students!

Tue, 2014-04-22 05:00

We're excited to announce that 19 students have been selected to work with Debian during the Google Summer of Code this year!

Here is the list of accepted students and projects:

As always, you will be able to follow their progress on the SoC coordination mailing-list

Congratulations to all the students and let's make sure we all have an amazing summer!

Categories: FLOSS Project Planets