I bought a digital camera yesterday. The Canon Rebel XS, with a 18-55mm lens. It was a pretty nice deal from Staples, so I'm quite happy with this so far. The picture quality is impressive, and it's easy enough to use for a DSLR.
I took the first opportunity I could to take a few shots and try out this nice little program available in the repositories: Hugin. It is a very complete and pretty simple tool for compositing images and creating panoramas.
Past the first little hurdle where Hugin was trying to use 'autopano-sift', which although it seems installed since the package exists, it looks like I needed to change the configuration to just using 'autopano'. After taking four quick pictures, one with the full-automatic settings, and three more with the automatically-detected shutter speed and aperture set manually, and selecting a few common points between each pictures, I was able to get an almost-perfect panoramic picture of my street.
Some things to keep in mind: keep a somewhat constant overlap between pictures, don't trust the wizard for finding the common points -- they won't.
Sadly, I once again had issues with using just a USB cable to connect my camera to Jaunty. Same thing as with the other camera I had tried before. Fortunately, I could download the pictures directly from the SD card, and F-spot happily imported my pictures from that point.
To use hugin, you will likely want to install the hugin, hugin-tools, enblend and autopano-sift packages.
Saturday, 24 January 2009
Thursday, 22 January 2009
Status Update
Concordance and congruity are still being worked on in terms of packaging, so if you own a Logitech Harmony remote that you'd like to be able to configure via Linux, please take a look at my PPA for updated packages! I'll definitely take any help available to help test the packages, the software, and eventually get the packages into Ubuntu.
On the same note, I've setup an ITP bug for those two packages, and I have started work on including them in Debian as well. I've uploaded the packages ([1][2]) on to REVU a few minutes ago, and hopefully can get some tips and reviews from there too.
It's like Christmas again here. I received 4 10/100 blades, as well as a new Supervisor 2 engine to put in one of the Cisco 6506's, and was able to get it to fully POST, boot, and work -- also found out in the process that the backplace of the other is likely somewhat broken. I'm guessing that it's not big news to a lot of people, but screen supports making serial-based connections to devices, so minicom is much less necessary than it used to be. The greatest thing of this, is that screen is included by default in Ubuntu, which makes it perfect for system administrators to be able to connect a serial device to just about any Ubuntu system to be able to reach a serial console. With the work currently being done by Dustin Kirkland on screen-profiles (and the fact that the package is in Jaunty!), screen is likely going to be even more awesome very soon.
On the same note, I've setup an ITP bug for those two packages, and I have started work on including them in Debian as well. I've uploaded the packages ([1][2]) on to REVU a few minutes ago, and hopefully can get some tips and reviews from there too.
It's like Christmas again here. I received 4 10/100 blades, as well as a new Supervisor 2 engine to put in one of the Cisco 6506's, and was able to get it to fully POST, boot, and work -- also found out in the process that the backplace of the other is likely somewhat broken. I'm guessing that it's not big news to a lot of people, but screen supports making serial-based connections to devices, so minicom is much less necessary than it used to be. The greatest thing of this, is that screen is included by default in Ubuntu, which makes it perfect for system administrators to be able to connect a serial device to just about any Ubuntu system to be able to reach a serial console. With the work currently being done by Dustin Kirkland on screen-profiles (and the fact that the package is in Jaunty!), screen is likely going to be even more awesome very soon.
Saturday, 17 January 2009
More Linux-supported hardware
I went to buy new USB thumb drives for work this morning, considering I've had to do some work lately that requires transferring data from highly secured machines and there wasn't really any better option...
Anyway, went to the one of the obvious places for office supplies: Staples, or actually "Bureau en Gros" here in Quebec. Found exactly what I was looking for: the SanDisk Cruzer Micro Skin is the perfect size, only very slightly larger than the actual USB connector, which makes it perfect for these thight places like the back of a server, or when connectors are too close together. It so happens that the Cruzer Micro Skin is also supported on Linux, which seems kind of obvious, but SanDisk actually took the time to show it on the packaging, which is great. Here's a shot of the relative size of the USB drive with it's protective shield and cap, and without:
And here are the pictures of the front of the packaging, the back, and a close-up of the signs on the back:
Notice how happy Tux is that his face is on hardware packaging! Also disregard the poor quality of the pictures, I'm far from good with this camera. I was pretty surprised to notice the Tux logo on the back of the packages, and frankly, although I was already sure any USB key would work, I was happy that SanDisk took the time to show it on the boxes.
On the other hand, I had quite a lot of trouble getting these pictures off the camera and on my computer. The camera's USB connection was not working properly on my desktop computer running Jaunty, so I tried on my work laptop which I had also just upgraded, but I had the same problems. I reinstalled my laptop with Intrepid to make sure things would work again properly. The exact error was about devices showing up multiple times, and the device not being loaded properly to either display reliably in the file manager with gvfs, or to be captured by F-Spot to import the pictures. The same camera and task however runs just fine in Intrepid.
That said, I very much like the new volume controls on Jaunty. They work pretty well past the initial sound level issues, and much simplify working with multiple hardware sound devices.
Anyway, went to the one of the obvious places for office supplies: Staples, or actually "Bureau en Gros" here in Quebec. Found exactly what I was looking for: the SanDisk Cruzer Micro Skin is the perfect size, only very slightly larger than the actual USB connector, which makes it perfect for these thight places like the back of a server, or when connectors are too close together. It so happens that the Cruzer Micro Skin is also supported on Linux, which seems kind of obvious, but SanDisk actually took the time to show it on the packaging, which is great. Here's a shot of the relative size of the USB drive with it's protective shield and cap, and without:
And here are the pictures of the front of the packaging, the back, and a close-up of the signs on the back:
Notice how happy Tux is that his face is on hardware packaging! Also disregard the poor quality of the pictures, I'm far from good with this camera. I was pretty surprised to notice the Tux logo on the back of the packages, and frankly, although I was already sure any USB key would work, I was happy that SanDisk took the time to show it on the boxes.
On the other hand, I had quite a lot of trouble getting these pictures off the camera and on my computer. The camera's USB connection was not working properly on my desktop computer running Jaunty, so I tried on my work laptop which I had also just upgraded, but I had the same problems. I reinstalled my laptop with Intrepid to make sure things would work again properly. The exact error was about devices showing up multiple times, and the device not being loaded properly to either display reliably in the file manager with gvfs, or to be captured by F-Spot to import the pictures. The same camera and task however runs just fine in Intrepid.
That said, I very much like the new volume controls on Jaunty. They work pretty well past the initial sound level issues, and much simplify working with multiple hardware sound devices.
Tuesday, 6 January 2009
Cisco 6506 recovery
Last night I did the bare metal recovery of a Cisco 6506 that we salvaged from an old company. I got two systems, one of them I had some trouble with, and ultimately wouldn't boot and complain about the backplane.
Trying to fix the problem, I accidentally deleted the good firmware image and the system wouldn't even boot anymore, stuck at the ROMMON prompt.
So to recovery a system from the ROMMON prompt, there's a quick way to work. Quick being a relative word, considering it still means easily half an hour to 40 minutes of work.
So, from there you just have to push a new image to memory using a serial cable. Needless to say, this is time consuming.
What I did was run the 'xmodem -cys 38400' command, put minicom from the 9600 speed to 38400, and fire away a new firmware image (CatOS 5-4-3 actually). The benefit of running xmodem with the -y and -s 38400 switches are increased speed as compared to standard xmodem (because you tell it to use the enhanced ymodem protocol) which would be forced to run at the standard console speed of 9600 for this type of system.
As an example, pushing the CatOS 5.4(3) image took roughly 30 minutes at 38400 bps. We'd be talking about easily 2 to 3 hours using 9600bps.
Once that was done, failed the first time because of bad CRC, redone, and redone a couple more times, I finally got it right: I was able to boot into a workable system, adjust configuration and download a good new image onto bootflash. Et voila, no more backplace issues, no more booting problems.
The next step will be to fix the attached MSFC1 to the SUP1A I currently have, which still refuses to boot. This is fairly straightforward, considering it's again getting into a ROMMON state, then downloading a new image for the MSFC1.
Thanks Cisco for this nice little ymodem feature, and the good documentation about recovery procedures. This was a cheap, but still really heavy and loud paperweight I had before I pushed a new configuration.
Trying to fix the problem, I accidentally deleted the good firmware image and the system wouldn't even boot anymore, stuck at the ROMMON prompt.
So to recovery a system from the ROMMON prompt, there's a quick way to work. Quick being a relative word, considering it still means easily half an hour to 40 minutes of work.
So, from there you just have to push a new image to memory using a serial cable. Needless to say, this is time consuming.
What I did was run the 'xmodem -cys 38400' command, put minicom from the 9600 speed to 38400, and fire away a new firmware image (CatOS 5-4-3 actually). The benefit of running xmodem with the -y and -s 38400 switches are increased speed as compared to standard xmodem (because you tell it to use the enhanced ymodem protocol) which would be forced to run at the standard console speed of 9600 for this type of system.
As an example, pushing the CatOS 5.4(3) image took roughly 30 minutes at 38400 bps. We'd be talking about easily 2 to 3 hours using 9600bps.
Once that was done, failed the first time because of bad CRC, redone, and redone a couple more times, I finally got it right: I was able to boot into a workable system, adjust configuration and download a good new image onto bootflash. Et voila, no more backplace issues, no more booting problems.
The next step will be to fix the attached MSFC1 to the SUP1A I currently have, which still refuses to boot. This is fairly straightforward, considering it's again getting into a ROMMON state, then downloading a new image for the MSFC1.
Thanks Cisco for this nice little ymodem feature, and the good documentation about recovery procedures. This was a cheap, but still really heavy and loud paperweight I had before I pushed a new configuration.
Subscribe to:
Posts (Atom)