To recap: given the absence of other credible alternatives I had two options:
I think there is room for a new console client, because mutt is showing its age and does feel like it should have a real extension language - be it guile, lisp, javascript(!), Lua, or something else.
So I distilled what I thought I wanted into three sections:
So how did I do? I wrote a ncurses-based client which has Lua backed into it. You can fully explore the sidebar-mode - which lets you select multiple folders.
From there you can view the messages in a list.
What you can't do is anything "real":
For a two-day hack it is remarkably robust, and allowing scripting shows awesomeness. Consider this:
-- -- show all folders in the Maildir-list. -- function all() -- ensure that the sidebar displays all folders sidebar_mode = "all"; -- we're going to be in "maildir browsing mode" cmail_mode = "sidebar"; reset_sidebar(); refresh_screen(); end -- -- Test code, show that the pattern-searching works. -- -- To use this press ":" to enter the prompt, then enter "livejournal". -- -- OR press "l" when in the sidebar-mode. -- function livejournal() sidebar_pattern = "/.livejournal.2"; sidebar_mode = "pattern"; reset_sidebar(); refresh_screen(); end -- -- There is a different table for each mode. -- keymap = {} keymap['sidebar'] = {} keymap['index'] = {} keymap['message'] = {} -- -- In the sidebar-mode "b" toggles the sidebar <-> index. -- -- ":" invokes the evaluator. -- "q" quits the browser and goes to the index-mode. -- "Q" quits the program entirely. -- keymap['sidebar'][':'] = "prompt-eval" keymap['sidebar']['b'] = "toggle" keymap['sidebar']['q'] = "toggle" keymap['sidebar']['Q'] = "exit" -- show all/unread/livejournal folders keymap['sidebar']['a'] = "all" keymap['sidebar']['u'] = "unread" keymap['sidebar']['l'] = "livejournal"Neat, huh? See the cmail.lua file on github for more details.
My decision hasn't really progressed any further, though I can see that if this client were complete I'd love to use it. Its just that the remaining parts are the fiddly ones.
I guess I'll re-hack mutt, and keep this on the back-burner.
The code is ropey in places, but should you wish to view:
And damn C is kicking my ass.
A few weeks back my friend Lucy sent me a message asking if I would be prepared to spend some time talking about photography and sharing some techniques. Lucy studied photography at GCSE (proper “wet” photography) and has been getting into digital photography recently. Of course, I said “yes” and on Sunday we met up on the South Bank. It’s a great place to explore, with plenty of colour, shade, textures, areas and angles. That’s even before you look at the collection of street performers, which on this particular day included a fire-belching euphonium and a man stood in the Thames playing electric guitar.
I’ve never tried to teach anyone photography skills before, even in an informal setting like this. I’d been thinking through what I wanted to talk about beforehand, but kept feeling overwhelmed by how much detail I found myself including. It was reassuring to me that I understood all the technical stuff in that depth, but an interesting challenge to pick and choose the most important bits. Lucy wanted to focus on the technical stuff, so we didn’t talk about interacting with people too much. Hopefully next time!
We started by working through the “exposure triangle”, the mixture of shutter speed, aperture and ISO that gives the perfect exposure. I made Lucy take photos of me (poor thing!) until we had a good exposure, then varying one setting and adjusting the others to compensate. We also talked about the artistic impact that each setting has on an image, using aperture to separate a subject from their background and shutter speed to freeze or harness motion. Oh, and I also managed to blather on about direction and quality of light, metering, white balance, focal length, composition, angle, patterns.
Lucy posted some great images after our walk. Hopefully my witterings were of use, but I enjoyed catching up with Lucy and talking about my favourite subject with her.
Pin ItOn Thursday, 18 April, I sat and passed the RCF Intermediate exam. After a delay due to a problem on the Ofcom website, I finally got the call sign 2E0RJW on Friday 26th April.
So I am now allowed to work on all the amateur bands at powers up to 50W.
Next stage, the Advanced exam.
53-55 Lichfield St
Wolverhampton
West Midlands
WV1 1EQ
Eat, Drink and talk Linux
Event Date and Time: Wed, 01/05/2013 - 19:30 - 23:00At the pub in Hursley on Friday, a white bee landed on the table outside.
An unusual colour, I think it might be an andrena cineraria, a type of miner bee. Ive never seen one before, but it was quite cool to look at.
At the pub in Hursley on Friday, a white bee landed on the table outside.
An unusual colour, I think it might be an andrena cineraria, a type of miner bee. Ive never seen one before, but it was quite cool to look at.
Below you'll find a simple metaparameter (a parameter that works with any resource type) that adds this feature to puppet. As this is an early prototype I've hacked it directly in to my local puppet fork. Below you'll see a sample resource that declares a deprecation date and message, the code that implements it and a simple command line test you can run to confirm it works.
# sample puppet resource using :deprecation file { '/ec/cron.d/remove_foos': ensure => 'file', source => 'puppet:///modules/foo/foo.cron', deprecation => '20130425:Release 6 removes the need for the foo cronjob', } $ sudo vi puppet-3.1.1/lib/puppet/type.rb newmetaparam(:deprecation) do desc " Add a deprecation warning to resources. file { '/etc/foo': content => 'Bar', deprecation => '20130425:We no longer need the foo' } The deprecation comes in two parts, separated by a : The date is in format YYYYMMDD and the message is a free form string. " munge do |deprecation| date, message = deprecation.split(':') # YYY MM DD - one true timestamp now = Time.now.strftime('%Y%m%d') if (now >= date) rsrc = "#{@resource.type.capitalize}[#{@resource.name}]" Puppet.warning "#{rsrc} expired on #{date}: #{message}" end end end # command line test $ puppet apply -e 'file { "/tmp/dep": content => "foo\n", deprecation => "20120425:We can remove this file after release 4" }' Warning: File[/tmp/dep] expired on 20120425: We can remove this file after release 4 Notice: Finished catalog run in 0.06 secondsUsing the metaparameter is easy enough, just specify 'deprecation' as a property on a resource and provide a string that contains the date to start flagging the deprecation on (in YYYYMMDD format) and the message puppet should show. I don't currently fail the run on an expired resource but this is an option.
The are some other aspects of this to consider - Richard Clamp raised the idea of having a native type that could indicate this for an entire class (I'd rather use a function, but only because they are much easier to write) and Trevor Vaughan suggested a Puppet face that could present a report of the expired, and soon to be expired, code.
I don't know how widely useful this is but it made a nice change to write some puppet code. The small size of the example will hopefully show how easy it is to extend nearly every part of puppet - including more 'complicated' aspects like metaparameters. Although not the relationship ones, those are horrible ;) I've submitted the idea to the upstream development list so we'll see what happens.
I've recently started staging upgrades from Squeeze to Wheezy. One unpleasant surprise was that the mutt-patched package available to Debian doesn't contain the "sidebar-new-only" patch.
This means I need to maintain it myself again, which I'd rather avoid. Over time I've been slowly moving to standard Debian systems, trying to not carry too many local perversions around.
Unfortunately if you've kept all your mail since 1994 you have many mailboxes. having mutt-patched available at all, with the sidebar patch, is a great timesaver. But I don't want to see mailboxes I'm never going to touch; just mailboxes with new mail in them.
Also I find the idea of having to explicitly define mailboxes a pain. Just run inotify on ~/Maildir and discover the damn things yourself. Please computer, compute!
If you divide up "mail client" into distinct steps it doesn't seem so hard:
Obviously there is more to it than that. Sending mail? exec( sendmail ). Filtering mail? procmail/sieve/etc. Editing mail? exec(vim).
I'm sure if I were to start a core of a program, suitable for myself, would be simple enough. Maybe with lua, maybe with javascript, but with a real language at the core.
Anyway I've thought this before, and working with quilt and some ropy patches has always seemed like the way to go. Maybe it still is, but I can dream.
(PS. Sup + Notmuch both crash on my archives. I do not wish to examine them further. Still some interesting ideas. It should be possible to say "maildirs are tags; view "~/Maildir/.livejournal.2003" and ~/Maildir/.livejournal.2007 at the same time. Why just a single directory in the "index-view? So 1994.)
Disjointed posts R Us.
Obquote: "How hard could it be?" -- Patrick.
I have a theory (I know, I am full of them). Like most of you, as I have gotten older I have also tried to improve as a person. I am not just talking about being better at what I do with my career and hobbies, but I want to be a genuinely good person across the board; a good husband, father, son, friend, colleague, and dude who you bump your shopping cart into when buying milk. My theory is that people fundamentally improve by (a) making mistakes and (b) understanding and learning from those mistakes to not only prevent making the mistake again, but to also uncover the cause and effect of why the mistake was made, thus improving your life.
Now, the (probably illogical) logical continuation of my theory is that to make improvements (a) you need to make more mistakes (which opens up the opportunity for learning), and (b) you need to develop CSI-like capabilities in assessing those mistakes and their root causes. Continuing the theme, if we can figure out ways to identify ways of triggering making more mistakes in a way that doesn’t get you arrested and we can identify ways to help us understand why we screw up the way we do, we should have a golden ticket for rocking our lives. Incidentally, this theory was boiled in my head while driving out to pick up Thai food on Saturday night, so this is no Einstein’s Theory Of Relativity in terms of completeness.
While I am rather thin on the ground in terms of what is the next logical part of my theory, I suspect that the way in which we invite more none-life-threatening mistakes is to break out of our molds and take more risks; if we never take chances, we lower the opportunity for risk and mistakes, but also lower the opportunity for learning. Likewise, for the latter understanding our mistakes part I suspect the key is not figuring out ways to prevent the mistake (“I got angry and shouted at my dog today so I will try to keep my cool”) but more about understanding the cause of the mistake (“I am stressed from work and bringing that stress home and taking it out on people and animals”). Much as I love dogs, the goal here is not to stop shouting at the dog but to repair the root cause. So I ask you, dear friends, does my theory wash with you, and if so, how can we increase the number of mistakes and the quality of our self-assessment of those mistakes?
Brian is Red Hat’s CTO, and hence my boss’s boss’s boss (or something like that). This is a pretty good (and honest) talk about Red Hat’s plans for OpenStack.
Edit: By the way, the thumbnail (the one I see at any rate) is not Brian.
Amazingly a month has gone by since I did my test drive of a Nokia Lumia 920 thanks to Nokia_Connects. I didn’t get a chance to post my final conclusions until now.
How did it go?
tl;dr: It’s not a bad phone, it’s not a bad platform. In many ways it’s nicer to use than Android. I won’t be buying one, as there’s no incentive to replace my iPhone 4S.
The details: the hardware was fine, and even had a few bonus points: it was distinctive, it was fun, the display was outstanding and the battery life was impressive. The software was fine, and about what you’d expect from a relatively new platform that’s rapidly improving. I found it more pleasant to use than my Samsung SIII, which is a usability horror story.
The apps that were available were pretty good; now I’ve no longer got the phone I’m missing the London bus app, the live tiles, and the twitter client.
Windows Phone seemed genuinely innovative. It was let down by some of the Windows legacy (reboots), but it wasn’t as bad as I thought.
At the end of my time with the phone, Nokia asked me to complete a survey. I’ve added some of the comments here, and expanded on them a little.
What did you like about the device?
The physical rounded shape and device yellow colour.
The amazing screen (size and colour).
The mapping software.
The innovative UI.
The “friendly” interface (“Let’s get started / goodbye”) – the UI felt a lot less “formal” than iOS.
The browser.
The speed.
The smooth animation.
All-in-one design (no need to insert battery or SD cards) – although everyone scorned Apple for this, I think it’s a big advantage. Messing around with batteries and SD cards is tedious.
What didn’t you like about the device?
Always turns on when charging.
Some buggy software.
The weight.
The speakers.
What did you use most / were most surprised about / was unique to Nokia
Most used email, maps, apps such as Foursquare, live weather tiles.
Most surprised by low-light performance of camera (magic!)
Surprised by the amount of storage – fit music and photos on without making a dent in spare capacity.
Battery life was reasonable – it took several hours of continuous use to drain it.
Will you be purchasing the device now that you have trialled it?
No.
Unfortunately Nokia didn’t give me the option to expand on that response, so here’s my explanation: I have an iPhone 4S, and it’s good enough. The 920 doesn’t offer anything more over my current phone to make me think I need to switch right now.
It’s worth noting that I would never have considered another Nokia Symbian phone. I’ve been bitten too many times by terrible Symbian experiences, and I swore the Nokia N95 would be the last phone I ever bought from them. With the release of the N9, that would have changed – if Nokia hadn’t killed the platform.
Before this trial, I had dismissed WP8. However, if I had to replace my 4S with another device, I would now consider Nokia’s Windows Phone devices amongst the options. Wireless charging would be a big part of the decision – I loved that feature on the Palm Pre. I’m not sure if live tiles are enough of a killer feature to get me to switch; it depends on what comes next in iOS, I guess.
Based on the Firefox OS phone, it seems the device would have to be less than €200 unlocked in order for me to consider it as a spur of the moment purchase.
As part of the DebConf13 fundraising efforts, Brandorr Group is funding a matching initiative for DebConf13, which will be in place for 4 more days (through April 30th).
You can donate here!
Please consider donating $100, or even $5 or any amount in between, as we can use all the help we can get to reach our fundraising target. The rules are simple:
This generous offer will only stay in place through the end of April 30th.
Please act quickly, and help spread the world!
Ubuntu 13.04, the Raring Ringtail, was released today. Go and download it for Desktop, Server, Cloud, and for our Chinese friends, download Ubuntu Kylin. You can find all the details of what is new in Ubuntu 13.04 on www.ubuntu.com.
Ubuntu 13.04 is a fantastic release, and I just want to offer thanks to the many people around the world in our community who helped make it happen. Folks such as developers, app/charm authors, designers, testers, triagers, translators, sys-admins, support providers, governors, docs writers, advocates, and more, all contributed their brick in the wall to delivering Ubuntu 13.04 across Desktop, Server, and Cloud, and continuing to bring freedom and elegance in technology to more people. But this is only part of the story, as behind the scenes, but in full public view, we are continuing to evolve Ubuntu towards our convergence goals. This will be a common theme as we march forward to Ubuntu 13.10, the Saucy Salamander.
I know many of us are tired after a hectic release schedule, so take some time to enjoy the release, get together with other Ubuntu friends, and celebrate Ubuntu 13.04! I will certainly be blowing the froth off a few cold ones tonight.