Tag: configuration

dotfiles – your unofficial guide to dotfiles on GitHub

Warning: you will lose a lot of sleep if you follow the link below. :)

No matter how well you know Vim, bash, git, and a whole slew of other command line tools, I promise you, you’ll find something new, something you had no idea existed, something that will help you save hours and hours of your life by shaving off a few seconds here and there on the tasks you perform on a daily basis, in the repositories link to from this site.

I think I’ve spent most of my Sunday there and my dotfiles are so different now that I’m not sure I should commit and push them all in one go.  I think I might need to get used to the changes first.

Some of the things that I’ve found for myself:

  • PHP Integration environment for Vim (spf13/PIV).
  • myrepos – provides a mr command, which is a tool to manage all your version control repositories.
  • bash-it – a community Bash framework.
  • Awesome dotfiles – a curated list of dotfiles resources.

… and a whole lot of snippets, tips, and tricks.

P.S.: Make sure you don’t spend too much time on these things though :)

Fedora for short-lifespan server instances

Fedora for short-lifespan server instances

Let’s come back to the odd fact that Fedora is both a precursor to RHEL, and yet almost never used in production as a server OS. I think this is going to change. In a world where instances are deployed constantly, instances are born and die but the herd lives on. Once everyone has their infrastructure encoded into a configuration management system, Fedora’s short release cycle becomes much less of a burden. If I have service foo deployed on a Fedora X instance, I willnever be upgrading that instance. Instead I’ll be provisioning a new Fedora X+1 instance to run the foo service, start it, and throw the old instance in the proverbial bitbucket once the new one works.

Via LWN.

Fixing RT3 on Fedora 10

We upgraded our development server to Fedora 10 over the weekend.  Among other things, it runs RT3 – excellent support, issue management, and bug tracking tool.  Once the upgrade was over, we ended up with a semi-working setup of RT3.  The emails were going through just fine, but the web interface was giving out a blank screen with no content or errors or warnings.

Googled a bit, but that didn’t help a lot.   Went through server logs and found an out of memory shout from Storable.pm:

2325:Callback called exit at 
../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) 
line 415.

Googled for that, but it turned out that quite a few people have the problem with this module running out of memory.  And not only in RT3.

So I left it where it was and had some good night sleep.  And it helped.  In the morning, englightment came in, and I tried reloading the page with cookies and cache cleaned.  It worked.  And then it didn’t work again.  Cleaning cookies was helping for a couple of page views.  So I dived back into the RT_Config.pm file to see my options.  There it was.

=item C<$WebSessionClass>
C<$WebSessionClass> is the class you wish to use for managing Sessions.
It defaults to use your SQL database, but if you are using MySQL 3.x and
plans to use non-ascii Queue names, uncomment and add this line to
F<RT_SiteConfig.pm> will prevent session corruption.
=cut
# Set($WebSessionClass , 'Apache::Session::File');

Once I enabled Apache::Session::File, the problem went away.  We are now back to work, enjoying the new web 2.0 round corners interface, pastel colors, and more.

Some problems never get old. Or do they?

A couple of years ago I went through all our (Olga’s and mine) printed photographes, selected the good ones, and ordered scans from the studio, so that I could have them all in digital form. One of the annoying problems I came across when catalogueing those images was the date.

Most images didn’t have any date reference what-so-ever, so I had to guess when it was or date these images as very uproximate. Others, did have a date added by the camera. The problem though, was that in many cases, the date was way off. That’s because the camera was never properly configured (users hate manuals).

Today, while importing images to Flickr I realized that the same problem applies to digital cameras too. Many images in my gallery had a really wrong timestamp in the EXIF data. Useless. Good thing I was keeping them in the directory structure, which referenced the date (2005/2005-04-15_My_birthday). I could easily fix it with a tiny script.

This got me thinking. How can the problem be solved once and for all? Is it even possible? Is there a way for digital camera to know what time it is, without user telling it? How about people who travel a lot – do they have to reconfigure their cameras at every time zone?

The travelling bit gave me an idea – GPS. Some cameras already use GPS to add geolocation coordinates to the meta data of the picture. But GPS receivers can be also used for maintaining the precise clock, which can be autoconfigured, and autoconfigured with time zone of the actual camera location. This is sweet!

Hopefully Canon (and other vendors who I don’t care about) already does it, or plans to do it in the nearest future. That could be an excellent technology application – useful, and invisible to the user. Just as it should be.