News aggregator

Debian Bits: DebConf15 welcomes its first nine sponsors!

Planet HantsLUG - Thu, 13/11/2014 - 13:35

DebConf15 will take place in Heidelberg, Germany in August 2015. We strive to provide an intense working environment and enable good progress for Debian and for Free Software in general. We extend an invitation to everyone to join us and to support this event. As a volunteer-run non-profit conference, we depend on our sponsors.

Nine companies have already committed to sponsor DebConf15! Let's introduce them:

Our first Gold sponsor is credativ, a service-oriented company focusing on open-source software, and also a Debian development partner.

Our second Gold sponsor is sipgate, a Voice over IP service provider based in Germany that also operates in the United Kingdom (sipgate site in English).

Google (the search engine and advertising company), Fairsight Security, Inc. (developers of real-time passive DNS solutions), Martin Alfke / Buero 2.0 (Linux & UNIX Consultant and Trainer, LPIC-2/Puppet Certified Professional) and Ubuntu (the OS supported by Canonical) are our three Silver sponsors.

And last but not least, Logilab, Netways and Hetzner have agreed to support us as Bronze-level.

Become a sponsor too!

Would you like to become a sponsor? Do you know of or work in a company or organization that may consider sponsorship?

Please have a look at our sponsorship brochure (also available in German), in which we outline all the details and describe the sponsor benefits. For instance, sponsors have the option to reach out to Debian contributors, derivative developers, upstream authors and other community members during a Job Fair and through postings on our job wall, and to show-case their Free Software involvement by staffing a booth on the Open Weekend. In addition, sponsors are able to distribute marketing materials in the attendee bags. And it goes without saying that we honour your sponsorship with visibility of your logo in the conference's videos, on our website, on printed materials, and banners.

The final report of DebConf14 is also available, illustrating the broad spectrum, quality, and enthusiasm of the community at work, and providing detailed information about the different outcomes that last conference brought up (talks, participants, social events, impact in the Debian project and the free software scene, and much more).

For further details, feel free to contact us through sponsors@debconf.org, and visit the DebConf15 website at http://debconf15.debconf.org.

Categories: LUG Community Blogs

Meeting at "The Moon Under Water"

Wolverhampton LUG News - Tue, 11/11/2014 - 07:30
Event-Date: Wednesday, 12 November, 2014 - 19:30 to 23:00Body: 53-55 Lichfield St Wolverhampton West Midlands WV1 1EQ Eat, Drink and talk Linux
Categories: LUG Community Blogs

Steve Kemp: How could you rationally fork Debian?

Planet HantsLUG - Sun, 09/11/2014 - 12:16

The topic of Debian forks has come up a lot recently, and as time goes on I've actually started considering the matter seriously: How would you fork Debian?

The biggest stumbling block is that the Debian distribution contains thousands of packages, which are maintained by thousands of developers. A small team has virtually no hope of keeping up to date, importing changes, dealing with bug-reports, etc. Instead you have to pick your battle and decide what you care about.

This is why Ubuntu split things into "main" and "universe". Because this way they didn't have to deal with bug reports - instead they could just say "Try again in six months. Stuff from that repository isn't supported. Sorry!"

So if you were going to split the Debian project into "supported" and "unsupported" what would you use as the dividing line? I think the only sensible approach would be :

  • Base + Server stuff.
  • The rest.

On that basis you'd immediately drop the support burden of GNOME, KDE, Firefox, Xine, etc. All the big, complex, and user-friendly stuff would just get thrown away. What you'd end up with would be a Debian-Server fork, or derivative.

Things you'd package and care about would include:

  • The base system.
  • The kernel.
  • SSHD.
  • Apache / Nginx / thttpd / lighttpd / etc
  • PHP / Perl / Ruby / Python / etc
  • Jabberd / ircd / rsync / etc
  • MySQL / PostGres / Redis / MariadB / etc.

Would that be a useful split? I suspect it would. It would also be manageable by a reasonably small team.

That split would also mean if you were keen on dropping any particular init-system you'd not have an unduly difficult job - your server wouldn't be running GNOME, for example.

Of course if you're thinking of integrating a kernel and server-only stuff then you might instead prefer a BSD-based distribution. But if you did that you'd miss out on Docker. Hrm.

Categories: LUG Community Blogs

Steve Engledow (stilvoid): Stony Silence

Planet ALUG - Sat, 08/11/2014 - 23:27

I just bought a Pebble - it's great!

I'd been toying with the idea of buying a wristwatch for several months. My main reason was that I'd noticed I'd fallen into the following pattern:

  • Wonder what the time is
  • Take phone out of pocket
  • Get distracted by email/twitter/app updates/something
  • Put phone back in pocker
  • Realise I didn't note or don't remember the time

I have a friend who owns a Pebble and after quizzing him about it, I decided that might help me achieve an even better goal: to dramatically reduce the amount of time I spend looking at my phone altogether.

After a week with my new Pebble, I'd say it's going well. The watch receives notifications from my phone so whenever an email arrives, I can quickly glance at my watch to decide whether I need to bother reading it now (most of the time, not). Despite requiring that my phone's bluetooth be switched on all the time, I've noticed that the battery has lasted slightly longer than normal - the Android battery usage charts tell me that's because of the reduced amount of screen usage.

My favourite thing about the Pebble is how hackable it is. The SDK is pretty good and simple to use. It's only been a week and I've already written, three, watch faces. The latest of which has resulted in a few emails from people saying how much they liked it :)

In unrelated news - OR IS IT?! - I had a panic attack the other day for the first time in over a year :S I managed to keep on top of it as I know what to do now, but the effects lasted for much longer than on previous occasions; I didn't feel alright until 10am the following day - 17 hours after it started. I still don't feel quite right.

Does anyone reading have any experience of panic attacks and whether it's worth seeing a doctor? I get them very rarely and I can make my way through them without help now but they leave me feeling awful for hours afterwards when they do happen. I'm not interested in taking regular meds to prevent them when they occur but I would be interested to know if there's something that could halt an attack when it starts or at least reduce the after-effects.

I don't really know what brought this one on but I rarely do. Caffeine seems to be a trigger (and I'd drunk a few teas and coffees that day) but it can't be a trigger on its own as I've drunk that much caffeine on other occasions and been fine.

Bleh.

Categories: LUG Community Blogs

Steve Kemp: Some brief notes on Docker

Planet HantsLUG - Sat, 08/11/2014 - 13:33

Docker is the well-known tool for building, distributing, and launching containers.

I use it personally to run a chat-server, a graphite instance, and I distribute some of my applications with Dockerfiles too, to ease deployment.

Here are some brief notes on things that might not be obvious.

For a start when you create a container it is identified by a 64-byte ID. This ID is truncated and used as the hostname of the new guest - but if you ever care you can discover the full ID from within the guest:

~# awk -F/ '{print $NF}' /proc/self/cgroup 9d16624a313bf5bb9eb36f4490b5c2b7dff4f442c055e99b8c302edd1bf26036

Compare that with the hostname:

~# hostname 9d16624a313b

Assigning names to containers is useful, for example:

$ docker run -d -p 2222:22 --name=sshd skxskx/sshd

However note that names must be removed before they can be reused:

#!/bin/sh # launch my ssh-container - removing the name first docker rm sshd || true docker run --name=sshd -d -p 2222:22 skxskx/sshd

The obvious next step is to get the IP of the new container, and setup a hostname for it sshd.docker. Getting the IP is easy, via either the name of the ID:

~$ docker inspect --format '{{ .NetworkSettings.IPAddress }}' sshd 172.17.0.2

The only missing step is the ability to do that magically. You'd hope there would be a hook that you could run when a container has started - unfortunately there is no such thing. Instead you have two choices:

  • Write a script which parses the output of "docker events" and fires appropriately when a guest is created/destroyed.
  • Write a wrapper script for launching containers, and use that to handle the creation.

I wrote a simple watcher to fire when events are created, which lets me do the job.

But running a deamon just to watch for events seems like the wrong way to go. Instead I've switched to running via a wrapper dock-run:

$ dock-run --name=sshd -d -p 2222:22 skxskx/sshd

This invokes run-parts on the creation directory, if present, and that allows me to update DNS. So "sshd.docker.local" will point to the IP of the new image.

The wrapper was two minutes work, but it does work, and if you like you can find it here.

That concludes my notes on docker - although you can read articles I wrote on docker elsewhere.

Categories: LUG Community Blogs

Steve Kemp: Planning how to configure my next desktop

Planet HantsLUG - Thu, 06/11/2014 - 21:26

I recently setup a bunch of IPv6-only accessible hosts, which I mentioned in my previous blog post.

In the end I got them talking to the IPv4/legacy world via the installation of an OpenVPN server - they connect over IPv6 get a private 10.0.0.0/24 IP address, and that is masqueraded via the OpenVPN-gateway.

But the other thing I've been planning recently is how to configure my next desktop system. I generally do all development, surfing, etc, on one desktop system. I use virtual desktops to organize things, and I have a simple scripting utility to juggle windows around into the correct virtual-desktop as they're launched.

Planning a replacement desktop means installing a fresh desktop, then getting all the software working again. These days I'd probably use docker images to do development within, along with a few virtual machines (such as the pbuilder host I used to release all my Debian packages).

But there are still niggles. I'd like to keep the base system lean, with few packages, but you can't run xine remotely, similarly I need mpd/sonata for listening to music, emacs for local stuff, etc, etc.

In short there is always the tendency to install yet-another package, service, or application on the desktop, which makes migration a pain.

I'm not sure I could easily avoid that, but it is worth thinking about. I guess I could configure a puppet/slaughter/cfengine host and use that to install the desktop - but I've always done desktops "manually" and servers "magically" so it's a bit of a change in thinking.

Categories: LUG Community Blogs

New Challenges and Adventure Awaits

Planet SurreyLUG - Mon, 03/11/2014 - 21:31
Today is a good day! Decisions were made, some decisions are hard to make that require over thinking and analysing and others are a lot easier as you know they are just right! This one was easy to make! Today I accepted a new role and a new challenge. I am looking forward to starting […]
Categories: LUG Community Blogs
Syndicate content