It is unfortunate that some of the client libraries are inefficient, but I'm enjoying my exposure to Amazon's Route53 API.
(This is unrelated to the previous post(s) about operating a DNS service..)
For an idea of scale I host just over 170 zones at the moment.
For the first 25 zones Amazon would charge $0.50 a month, then $0.10 after that. Which would mean:25 * $0.50 + 150 * $0.10 = $12.50
That seems reasonably .. reasonable.
After some discussion last night at PHP Hants about the fact that irc is a great facilitator of support / discussion, but largely ignored because there is rarely enough information for a new user to get going I decided it may be worth putting together a howto type post so here goes…
What is irc?
First of all, what on earth is it? I’m tempted to describe it as Twitter done right years before Twitter even existed, but I’m a geek and I’ve been using irc for years. It has a long heritage, but unlike the ubiquitous email it hasn’t made the transition into mainstream use. In terms of usage it has similarities to things like Twitter and Instant Messaging. Let’s take a quick look at this.
Twitter allows you to broadcast messages, they get published and anyone who is subscribed to your feed can read what you say. Everything is pretty instant, and if somebody is watching the screen at the right time they can respond straight away. Instant Messaging on the other hand, is more of a direct conversation with a single person, or sometimes a group of people, but it too is pretty instantaneous – assuming, of course, that there’s someone reading what you’ve said. Both of these techonologies are pretty familiar to many. If you go to the appropriate website you are given the opportunity to sign up and either use a web based client or download one.
It is much the same for irc in terms of usage, although conversations are grouped into channels which generally focus on a particular topic rather than being generally broadcast (Twitter) or more specifically directed (Instant Messaging). The downside is that in most cases you don’t get a web page with clear instructions of how to sign up, download a client and find where the best place is to join the conversation.
There are two things you need to get going with irc, a client and somewhere to connect to. Let’s put that into a more familiar context.
The client is what you use to connect with; this can be an application – so as an example Outlook or Thunderbird would be a mail client, or IE, Firefox, Chrome or Safari are examples of clients for web pages – or it can be a web page that does the same thing – so if you go to twitter.com and login you are using the web page as your Twitter client. Somewhere to connect to can be compared to a web address, or if you’ve got close enough to the configuration of your email to see the details, your mail server address.
Let’s start with the ‘somewhere to connect to‘ bit. Freenode is one of the most popular irc servers, so let’s take a look. First we’ll see what we can find out from their website, http://freenode.net/.
There’s a lot of very daunting information there for somebody new to irc, so ignore most of it and follow the Webchat link on the left.
That’s all very well and good, but what do we put in there? I guess the screenshot above gives a clue, but if you actually visit the page the entry boxes will be blank. Well first off there’s the Nickname, this can be pretty much anything you like, no need to register it – stick to the basics of letters, numbers and some simple punctuation (if you want to), keep it short and so long as nobody else is already using it you should be fine; if it doesn’t work try another. Channels is the awkward one, how do you know what channels there are? If you’re lucky you’re looking into this because you’ve been told there’s a channel there and hopefully you’ve been given the channel name. For now let’s just use the PHP Hants channel, so that would be #phph in the Channels box. Now all you need to do is type in the captcha, ignore the tick boxes and click Connect and you are on the irc channel and ready to chat. Down the right you’ll see a list of who else is there, and in the main window there will be a bit of introductory information (e.g. topic for the channel) and depending on how busy it is anything from nothing to a fast scrolling screen of text.
If you’ve miss typed there’s a chance you’ll end up in a channel specially created for you because it didn’t exist; don’t worry, just quit and try again (I’ll explain that process shortly).
For now all you really need to worry about is typing in text an posting it, this is as simple as typing it into the entry box at the bottom of the page and pressing return. Be polite, be patient and you’ll be fine. There are plenty of commands that you can use to do things, but for now the only one you need to worry about is the one to leave, this is:
Type it in the entry box, press return and you’ve disconnected from the server. The next thing to look into is using a client program since this is far more flexible, but I’ll save that for another post.
Debian is a big system. At the time of writing, the unstable distribution has more than 20,000 source packages, building more then 40,000 binary packages on the amd64 architecture. The number of inter-dependencies between binary packages is mind-boggling: the entire dependency graph for the amd64 architecture contains a little more than 375,000 edges. If you want to expand the phrase "package A depends on package B", there are more than 375,000 pairs of packages A and B that can be used.
Every one of these dependencies is a potential source of problems. A library changes the semantics of a function call, and then programs using that library that assumed the previous semantics can start to malfunction. A new version of your favorite programming language comes out, and a program written in it no longer works. The number of ways in which things can go wrong goes on and on.
With an ecosystem as big as Debian, it is just impossible to stop these problems from happening. What we can do is trying to detect when they happen, and fix them as soon as possible.
The Debian Continuous Integration project was created to address exactly this problem. It will continuously run test suites for source packages when any of their dependencies is updated, as well as when a new version of the package itself is uploaded to the unstable distribution. If any problems that can be detected by running an automated test suite arise, package maintainers can be notified in a matter of hours.
Antonio Terceiro has posted on his blog an introduction to the project with a more detailed description of the project, its evolution since January 2014 when it was first introduced, an explanation of how the system works, and how maintainers can enable test suites for their packages. You might also want to check the documentation directly.
One of the things we’re keen to continue to push with Ubuntu is a spirit of openness and inclusivity. Over the last couple of years with the reduction in ‘in person’ Ubuntu Developer Summits it’s been said Canonical developers are harder to reach, and that we’re not communicating effectively our plans and designs for the future direction of Ubuntu. We’ve been trying to address this via increased blogging, regular email status updates and video updates from all areas of the community.
As always we’re also keen to hear feedback, we welcome email discussion on our lists, bug reports, design mock-ups and of course well tested patches. We also want to ensure people at every level are available for Q&A sessions on a regular basis. Jono Bacon had a series of Q&A sessions which the Community Team will continue, but with additional domain experts and leaders during those sessions.
One of the biggest visible areas of change for Ubuntu is the transition from Unity 7 on Compiz (used in 14.04 and below) and Unity 8 and Mir (to be used in future releases). So today this weeks Ubuntu Online Summit we’ve arranged a couple of sessions which we invited participation in.
At 14:00 UTC today Rick Spencer (VP of Engineering) and Oliver (Olli) Ries (Director of Unity & Display Server) will hold an Ask Rick & Olli session. Bring along your questions about Unity, Mir, convergence, future desktop direction and more.
Click the time links above to find out when these are happening in your timezone today, and the other links to join in the sessions at that time. If you miss it you can watch the sessions later using the same links.Tweet
In my previous blog-post I mentioned, briefly, that I'd posted a couple of adverts on Reddit looking for work.
To give more detail I did three things:
The advertising on Reddit was painless to setup, and the traffic stats were interesting, but even though this worked out well I'm a little loathe to repeat the process - since the "non-sterling transaction fee" from my bank effectively doubled my budget.
I received a few (private) emails and comments, along with the expected grammar corrections. The end result was that I received contact from an American company founder who seemed interested.
He allowed me to write some code to solve a fun problem, appeared to enjoy the code I sent (Ruby code for dealing with (exim) email spam, that's as specific as I will be). The end result was a three month contract, which we obviously hope will lead to more permanent work.
Anyway I thought this was an atypical route to find a work, and was about a million times nicer than working with recruiters, so .. consider this documentation!
In other news it is now 10pm and I need to go to the gym and pub, in that order.
Some coding updates:
I've converted most of my Dockerfiles to work with docker 1.0.0, which is nice.
I also hacked up a fun DNS-server for sharing JSON-encoded data, within a LAN or other environment:
Finally I updated the blogspam-detecting site a little, on the back-end. The code is now running inside Docker containers which means I can redeploy more easily in the future.
My blog post about looking for a job received some attention via a Reddit advert I posted to /r/edinburgh + /r/sysadmin, but thus far has mostly resulted in people wanting me to write code for them .. which is frustrating.
For the moment I'm working on a fun challenge involving (email) spam-detection. That takes me back.
The Debian project is excited to announce that we are now accepting presentations, discussion sessions and tutorials for our DebConf14 conference which will take place in Portland State University, Oregon, USA from 23 to 31 August.Submitting an event
To submit an event, first register as an attendee for DebConf14 in the conference management system. If you have any doubts or have problems with the registration process please check the Registration FAQ.
After registering, go to the event submission page, or click on the Create an event option from the management system. Describe your submission in the web form. The most common event types are Lecture or Open Discussion (BoF). Please include a short title (to make it easy to produce a compact schedule) and an engaging description of the event.Tracks
We will organize some talks into thematic tracks. If you have a proposal for a DebConf track, such as "Debian ARM", "Debian Infrastructure", or "Community Outreach" please contact email@example.com.
If you would like to be a track coordinator, please volunteer on the given mail address.Format of the events
A regular session will be 45 minutes long, including time for questions. There will be a 15 minute breaks between events.
Submissions are not limited to traditional talks: you could propose a performance, art installation, debate, or anything else. If you have any specific requirements for your event, please send an email to firstname.lastname@example.org with the details of your requirements and be sure to mention your event title in the subject.Deadline
While we ask speakers to submit their events before the deadline of 7 July 2014, 23:59:59 UTC, late submissions will continue to be accepted for scheduling until the end of DebConf. All attendees will have an opportunity to schedule ad-hoc events during DebConf itself if we have space for them. Very promising late submissions may be considered for inclusion in the main conference. Note that ad-hoc events have a much lower chance of video archiving, and streaming, so if you want these services it's better to get your submissions in early.
DebConf official events will be broadcast live on the Internet when possible, and videos of the talks will be published on the web along with the presentation slides and papers.
For private communication regarding your talk, or for more general ideas, or questions about the event and talks, please mail us
We hope to you see you and share some good times with you this year in Portland during DebConf14!
If anybody has access to a complete mirror of the Debian Wheezy release, and was willing to share a list of all setuid/setgid binaries that would be greatly appreciated.
It doesn't seem to be something you can find online, so you need to manually unpack each .deb file and look at the permissions.
I don't have access to a (complete) local mirror, and so I cannot easily build such a thing, unless I go to ebay and buy a random DVD-archive.
This list would be useful for folk wanting to direct their audits ..
Until recently I was very happy with my console mail client, Lumail, thinking I'd written it in a flexible manner, with lots of Lua-callable primitives.
Now I'm beginning to suspect that I might have gone down the wrong path at some point.
The user interface, at startup consists of a list of mailboxes. The intention being that you select a mailbox, and open it. That then takes you to a list of messages. (There is a cool and simple to use option to open the union of multiple mailboxes, which is something I use daily.)
Now the list of mailboxes is sorted alphabetically, so the user interface looks something like this:
Now the issue that triggered my rethink:
Sure you think. It's just a list of strings. You could pass an array to a lua on_sort_maildirs function, and then use the returned array/table as teh display order. Simple.
Simple until you realize the user might want to do more than operate solely on the list of strings. Perhaps they wish to put folders with unread messages at the top. At which point you need a "count_unread( maildir )" function. (Which does exist.)
Anyway the realisation I had is that the CMaildir object, on the C++ side, isn't exposed to the Lua-side. So the (useful) member functions which should be exported/visible are not.
Really what I'm trying to say is that I think I've implemented and exported useful Lua primitives, but actually many more parts of the implementation could be usefully exported - but are not, and that comes from the choice I made to expose "things" not "objects". If I'd exposed objects right from the start I'd have been in a better place.
I continued to toy with a basic GUI mail-client last week, but I've pretty much written that off as a useful way to spend my time. For the moment I'll leave email alone, I've done enough and despite niggles what I have is absolutely the best mail client for me.
(It is a shame that Mutt is so heavyweight and hard to deal with, and that notmuch never really took off.)