News aggregator

Mick Morgan: solidarity with the tor project

Planet ALUG - Sat, 13/12/2014 - 19:16

On Thursday 11 December, Roger Dingledine of the Tor project posted the following email to the “tor-talk” mail list (to which I am subscribed).

I’d like to draw your attention to

https://blog.torproject.org/blog/solidarity-against-online-harassment
https://twitter.com/torproject/status/543154161236586496

One of our colleagues has been the target of a sustained campaign of harassment for the past several months. We have decided to publish this statement to publicly declare our support for her, for every member of our organization, and for every member of our community who experiences this harassment. She is not alone and her experience has catalyzed us to action. This statement is a start.

Roger asked those who deplored on-line harassment (of any person, for any reason) and who supported the Tor project’s action in publicly condemning the harassment of one of the Tor developers to add their name and voice to the blog post.

I am proud to have done so.

Categories: LUG Community Blogs

Joint meeting hosted by Portsmouth, 20 Dec 2014

Surrey LUG - Thu, 11/12/2014 - 23:12
Start: 2014-12-20 13:00 End: 2014-12-20 18:00

The Portsmouth LUG have invited us to join them.

All of you are warmly invited to the Portsmouth LUG Bring a Box meeting, on Saturday, 20th December, from 13:00 to 18:00 at the Broadoaks Social Club.
http://www.broadoaksocialclub.net/where.html

The talk that had to be put off last month will take place this.  Keith Edmunds of Tiger Computing will talk to us about running an entirely Linux Consultancy.

Categories: LUG Community Blogs

Ben Francis: The Times They Are A Changin’ (Open Web Remix)

Planet ALUG - Thu, 11/12/2014 - 11:26

In the run up to the “Mozlandia” work week in Portland, and in reflection of the last three years of the Firefox OS project, for a bit of fun I’ve reworked a Bob Dylan song to celebrate our incredible journey so far.

Here’s a video featuring some of my memories from the last three years, with Siobhan (my fiancée) and me singing the song at you! There are even lyrics so you can sing along

“Keep on rockin’ the free web” — Potch

Categories: LUG Community Blogs

Steve Kemp: An anniversary and a retirement

Planet HantsLUG - Thu, 11/12/2014 - 10:56

On this day last year I we got married.

This morning my wife cooked me breakfast in bed for the second time in her life, the first being this time last year. In thanks I will cook a three course meal this evening.

 

In unrelated news the BlogSpam service will be retiring the XML/RPC API come 1st January 2015.

This means that any/all plugins which have not been updated to use the JSON API will start to fail.

Fingers crossed nobody will hate me too much..

Categories: LUG Community Blogs

Chris Lamb: Starting IPython automatically from zsh

Planet ALUG - Wed, 10/12/2014 - 18:07

Instead of a calculator, I tend to use IPython for those quotidian bits of "mental" arithmetic:

In [1]: 17 * 22.2 Out [1]: 377.4

However, I often forget to actually start IPython, resulting in me running the following in my shell:

$ 17 * 22.2 zsh: command not found: 17

Whilst I could learn do this maths within Zsh itself, I would prefer to dump myself into IPython instead — being able to use "_" and Python modules generally is just too useful.

After following this pattern too many times, I put together the following snippet that will detect whether I have prematurely attempted a calculation inside zsh and pretend that I ran it in IPython all along:

zmodload zsh/pcre math_regex='^[\d\-][\d\.\s\+\*\/\-]*$' function math_precmd() { if [ "${?}" = 0 ] then return fi if [ -z "${math_command}" ] then return fi if whence -- "$math_command" 2>&1 >/dev/null then return fi if [ "${math_command}" -pcre-match "${math_regex}" ] then echo ipython -i -c "_=${math_command}; print _" fi } function math_preexec() { typeset -g math_command="${1}" } typeset -ga precmd_functions typeset -ga preexec_functions precmd_functions+=math_precmd preexec_functions+=math_preexec

For example:

lamby@seriouscat:~% 17 * 22.2 zsh: command not found: 17 377.4 In [1]: _ + 1 Out [1]: 378.4

(Canonical version from my zshrc.d)

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Testing a Django app with Docker

Planet ALUG - Tue, 09/12/2014 - 01:00

I've been playing around with Docker a fair bit and recently hit upon a configuration that works nicely for me when testing code at work.

The basic premise is that I run a docker container that pretty well emulates the exact environment that the code will run in down to the OS so I don't need to care that I'm not running the same distribution as the servers we deploy to and that I can test my code at any time without having to rebuild the docker image.

Here's an annotated Dockerfile with the project-specific details removed.

# We start with ubuntu 14.04 FROM ubuntu:14.04 MAINTAINER Steve Engledow <steve@offend.me.uk> USER root # Install OS packages # This list of packages is what gets installed by default # on Amazon's Ubuntu 14.04 AMI plus python-virtualenv RUN apt-get update \ && apt-get -y install software-properties-common git \ ssh python-dev python-virtualenv libmysqlclient-dev \ libqrencode-dev swig libssl-dev curl screen # Configure custom apt repositories # and install project-specific packages COPY apt-key.list apt-repo.list apt.list /tmp/ # Not as nice as this could be as docker defaults to sh rather than bash RUN while read key; do curl --silent "$key" | apt-key add -; done < /tmp/apt-key.list RUN while read repo; do add-apt-repository -y "$repo"; done < /tmp/apt-repo.list RUN apt-get -qq update RUN while read package; do apt-get -qq -y install "$package"; done < /tmp/apt.list # Now we create a normal user and switch to it RUN useradd -s /bin/bash -m ubuntu \ && chown -R ubuntu:ubuntu /home/ubuntu \ && passwd -d ubuntu USER ubuntu WORKDIR /home/ubuntu ENV HOME /home/ubuntu # Set up a virtualenv andinstall python packages # from the requirements file COPY requirements.txt /tmp/ RUN mkdir .myenv \ && virtualenv -p /usr/bin/python2.7 ~/.myenv \ && . ~/.myenv/bin/activate \ && pip install -r /tmp/requirements.txt \ # Set PYTHONPATH and activate the virtualenv in .bashrc RUN echo "export PYTHONPATH=~/myapp/src" > .bashrc \ && echo ". ~/.myenv/bin/activate" >> .bashrc # Copy the entrypoint script COPY entrypoint.sh /home/ubuntu/ EXPOSE 8000 ENTRYPOINT ["/bin/bash", "entrypoint.sh"]

And here's the entrypoint script that nicely wraps up running the django application:

#!/bin/bash . ./.bashrc cd myapp/src ./manage.py $*

You generate the base docker image from these files with docker build -t myapp ./.

Then, when you're ready to run a test suite, you need the following invocation:

docker run -ti --rm -P -v ~/code/myapp:/home/ubuntu/myapp myapp test

This mounts ~/code/myapp and /home/ubuntu/myapp within the Docker container meaning that you're running the exact code that you're working on from inside the container :)

I have an alias that expands that for me so I only need to type docked myapp test.

Obviously, you can substitute test for runserver, syncdb or whatever :)

This is all a bit rough and ready but it's working very well for me now and is repeatable enough that I can use more-or-less the same script for a number of different django projects.

Categories: LUG Community Blogs

Christmas Meal

Wolverhampton LUG News - Mon, 08/12/2014 - 09:25
Event-Date: Wednesday, 10 December, 2014 - 19:30 to 21:30Body: It's that time of year again, so on Wednesday, 10th December 2014 at 7:30 pm we will be meeting at the Wolverhampton Cosmo Restaurant, Unit B8, Bentley Bridge Retail Park, Wednesfield Rd, Wolverhampton WV11 1BP The booking is for 7:30 - 9:30 pm so please be prompt.
Categories: LUG Community Blogs

Steve Kemp: I eventually installed Debian on a new desktop.

Planet HantsLUG - Sun, 07/12/2014 - 08:12

Recently I build a new desktop system. The hightlights of the hardware are a pair of 512Gb SSDs, which were to be configured in software RAID for additional speed and reliability (I'm paranoid that they'd suddenly stop working one day). From power-on to the (GNOME) login-prompt takes approximately 10 seconds.

I had to fight with the Debian installer to get the beast working though as only the Jessie Beta 2 installer would recognize the SSDs, which are Crucual MX100 devices. My local PXE-setup which deploys the daily testing installer, and the wheezy installer, both failed to recognize the drives at all.

The biggest pain was installing grub on the devices. I think this was mostly this was due to UFI things I didn't understand. I created spare partitions for it, and messaged around with grub-ufi, but ultimately disabled as much of the "fancy modern stuff" as I could in the BIOS, leaving me with AHCI for the SATA SSDs, and then things worked pretty well. After working through the installer about seven times I also simplified things by partitioning and installing on only a single drive, and only configured the RAID once I had a bootable and working system.

(If you've never done that it's pretty fun. Install on one drive. Ignore the other. Then configure the second drive as part of a RAID array, but mark the other half as missing/failed/dead. Once you've done that you can create filesystems on the various /dev/mdX devices, rsync the data across, and once you boot from the system with root=/dev/md2 you can add the first drive as the missing half. Do it patiently and carefully and it'll just work :)

There were some niggles though:

  • Jessie didn't give me the option of the gnome desktop I know/love. So I had to install gnome-session-fallback. I also had to mess around with ~/.config/autostart because the gnome-session-properties command (which should let you tweak the auto-starting applications) doesn't exist anymore.

  • Setting up custom keyboard-shortcuts doesn't seem to work.

  • I had to use gnome-tweak-tool to get icons, etc, on my desktop.

Because I assume the SSDs will just die at some point, and probably both on the same day, I installed and configured obnam to run backups. There is more testing and similar, but this is the core of my backup script:

#!/bin/sh # backup "/" - minus some exceptions. obnam backup -r /media/backups/storage --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/media / # keep files for various periods obnam forget --keep="30d,8w,8m" --repository /media/backups/storage
Categories: LUG Community Blogs

Adam Trickett: Picasa Web: Xmas Break 2014

Planet HantsLUG - Sat, 06/12/2014 - 08:00

Long weekend in France

Location: France
Date: 6 Dec 2014
Number of Photos in Album: 22

View Album

Categories: LUG Community Blogs

Chris Lamb: Don't ask your questions in private

Planet ALUG - Thu, 04/12/2014 - 12:55

(If I've linked you to this page, it is my feeble attempt to provide a more convincing justification.)


I often receive instant messages or emails requesting help or guidance at work or on one of my various programming projects.

When asked why they asked privately, the responses vary; mostly along the lines of it simply being an accident, not knowing where else to ask, as well as not wishing to "disturb" others with their bespoke question. Some will be more candid and simply admit that they were afraid of looking unknowledgable in front of others.

It is always tempting to simply reply with the answer, especially as helping another human is inherently rewarding unless one is a psychopath. However, one can actually do more good overall by insisting the the question is re-asked in a more public forum.

This is for many reasons. Most obviously, public questions are simply far more efficient as soon as more than one person asks that question — the response can be found in a search engine or linked to in the future. These time savings soon add up, meaning that simply more stuff can be done in any given day. After all, most questions are not as unique as people think.

Secondly, a private communication cannot be corrected or elaborated on if someone else notices it is incorrect or incomplete. Even this rather banal point is more subtle that it first appears — the lack of possible corrections deprives both the person asking and the person responding of the true and correct answer.

Lastly, conversations that happen in private are depriving others of the answer as well. Perhaps someone was curious but hadn't got around to asking? Maybe the answer—or even the question!—contains a clue to solving some other issue. None of this can happen if this is occurs behind closed doors.

(There are lots of subtler reasons too — in a large organisation or team, simply knowing what other people are curious about can be curiously valuable information.)

Note that this is not—as you might immediately suspect—simply a way of ensuring that one gets the public recognition or "kudos" from being seen helping others.

I wouldn't deny that technical communities work on a gift economy basis to some degree, but to attribute all acts of assistance as "selfish" and value-extracting would be to take the argument too far in the other direction. Saying that, the lure and appeal of public recognition should not be understated and can certainly provide an incentive to elaborate and provide a generally superior response.


More philosophically, there's also something fundamentally "honest" about airing issues in an appropriately public and transparent manner. I feel it promotes a culture of egoless conversations, of being able to admit one's mistakes and ultimately a healthy personal mindset.

So please, take care not only in the way you phrase and frame your question, but also consider wider context in which you are asking it. And don't take it too personally if I ask you to re-ask elsewhere...

Categories: LUG Community Blogs
Syndicate content