We recently had a new hardwood floor installed and used Glitsa for the finish. I moved my two fish tanks (10 and 55 gal) to the 2nd floor to clear everything off of the 1st floor where the work was being done. I shut the fish tanks in closed rooms and turned the heat down to 55F to reduce air cycling in the house (it is winter, outside temps approx 30F).
When we came home from being out of the house for 5 days while the finishing was done and drying, my 55 gallon tank was a rotting disaster. The water had turned white, and there was a sticky gel-like substance lining the edges of the water. There was gel-like stuff hanging from the live plants in the water. All the fish were dead and heavily decomposing, with the exception of a gold gourami, an otocinclus, and two African dwarf frogs.
My 10 gallon tank also had white water and gel, but to a much lesser extent. I think the difference was that I had an airstone in the 55 gal tank, which was basically pumping Glitsa fumes into the water and dissolving them in the tank. The 10 gal only has an hang-on-back filter which minimized the air exchange.
Most of the gel-like buildup was on the 10 gal's external filter and around the 55 gal's surface near where the bubbles from the airstone were bursting.
Luckily, my black ghost knife fish in the 10 gal tank survived, though was distressed. I assume the gourami and the frogs survived because they can breath from the surface. All of the other fish were suffocated. One even jumped out of the tank. I don't know how the otocinclus survived... maybe it is adapted to living in filthy water.
Anyway, posting this to let other homeowners know to definitely move their aquariums OUT of their houses before using Glitsa!
Wednesday, April 17, 2013
Thursday, October 18, 2012
The Empty Pedestal of Demas
Demas was one of traveling companions of St. Paul on his missionary journeys. He is mentioned several places in the New Testament, e.g. "Demas and Luke, my fellow workers" (Phlm 24), "Luke, the beloved physician, and Demas greet you" (Col 4:14)
But in the end he left Paul: "For Demas, in love with this present world, has deserted me and gone to Thessaloni'ca" (2 Tim 4:10).
His departure is symbolized by an empty pedestal in the courtyard of the basilica of St. Paul Outside the Walls.
The other pedestal contains a statue of St. Luke, who remained with Paul to the end.
Thanks to Ben Akers for the article that revealed this very interesting detail to me.
But in the end he left Paul: "For Demas, in love with this present world, has deserted me and gone to Thessaloni'ca" (2 Tim 4:10).
His departure is symbolized by an empty pedestal in the courtyard of the basilica of St. Paul Outside the Walls.
Thanks to Ben Akers for the article that revealed this very interesting detail to me.
Friday, January 14, 2011
Getting Swype Beta to run on a Sony Ericsson X10 from ATT
Side note: I hate AT&T. Why do they annoy their customers with loading junk software on their phones and blocking the ability to enable side-loading of applications from places other than the Andriod Market. Mind you, I'm just talking about the setting itself!
Anyway, the Swype BETA is difficult to install because of this for two reasons: not only do you need to install the installer via the Swype website, but then the installer downloads and installs the real Swype app to your phone. In other words, there are two install steps, both of which are blocked by the security settings on the AT&T crippled phone.
But I found this great workaround that gets past all the issues:
http://www.attdroids.com/forum/android-apps/612-app-swype-1-25-16-5612-a-3.html#post6070
Happy Swyping
Anyway, the Swype BETA is difficult to install because of this for two reasons: not only do you need to install the installer via the Swype website, but then the installer downloads and installs the real Swype app to your phone. In other words, there are two install steps, both of which are blocked by the security settings on the AT&T crippled phone.
But I found this great workaround that gets past all the issues:
http://www.attdroids.com/forum/android-apps/612-app-swype-1-25-16-5612-a-3.html#post6070
Happy Swyping
Friday, December 25, 2009
Moving Picasa photos and data
We just bought a new laptop for my wife, and we decided to do two things with our family photos and videos:
1. Copy Picasa data (including albums (virtual folders), settings, starred photos, etc) to the new laptop from the old
2. Move the physical location of the photos/videos from a Linux NSLU2 (aka the Slug) network storage device to the hard drive of the new laptop. It's about 60GB of data, roughly 14,000 files.
First of all, some links that helped me to understand what is going on under the hood of Picasa:
Richard's Tech Reviews: Picasa, a network drive and the lost folders
Backup and Restore Picasa (settings only not pictures)
To sum it up, if you are just moving pictures but don't use Picasa "albums", it's not too difficult. The picasa.ini files in the respective picture folders contain all the meta data about what edits you have made to the pictures. But in our case, we do use albums (quite a few), so we needed to move the album meta data as well. If you need to do this, you'll find yourself in one of two situations:
In the simple situation, you will have the same pathnames to files in the new computer as you had on the old. In this case, moving the albums is rather simple: just do a backup from within Picasa without clicking any photos (a dataless backup, if you will). Every backup contains the album meta data. Then, on the new computer, you run the PicasaRestore.exe executable that was created by the backup. The albums are restored.
But in our situation, we wanted to move the location of the files as well. The files used to be stored under N:\Pictures (the Slug network path). We wanted them to be stored under my wife's "My Pictures" directory. The Picasa albums have hardcoded pathnames to the pictures in the old locations, so there's much more work to be done.
Step 1 was to copy the data. This turned out to be a project all on its own, due to the fact that the external hard drive attached to the Slug was formatted as an ext3 file system. Anyway, I eventually got the N:\Pictures directory copied to C:\SlugCopy\Pictures.
Once I had all the data copied, I used the "subst" DOS command to create a virtual drive called N: on the new laptop that pointed to C:\SlugCopy\Pictures. I did this by running (from a command line): "subst N: C:\SlugCopy"
At this point, I had what looked to be the old Slug network path, but it was actually just a pointer to the files on the local drive.
Next, I used the Picasa backup feature to create a backup on the old laptop. I could have done a dataless backup, but I didn't know that at the time, so I instead backed up one small folder with 4 pictures.
I copied the backup to the new laptop, then ran the PicaseRestore.exe file created by the backup. This effectively copied all the Picasa album meta data to the new laptop.
Next, I downloaded and installed Picasa (it was version 3.6) on the new laptop. I then started Picasa, and it automatically rebuilt its database with all the albums included! I then had to manually add the N:\Pictures folder, and Picasa correctly imported the rest of the folders and individual picture meta data.
At this stage, everything is running on the new laptop, but Picasa is still using the N:\Pictures path, and the pictures are still physically stored at C:\SlugCopy\Pictures. How to move the pictures to my wife's "My Pictures" folder? And how to get Picasa to understand the move and update the albums?
I basically had two choices:
1) Move all the files myself, then edit Picasa album database files by hand. Yuck. This is feasible but definitely not recommended to monkey with things in an unsupported way.
2) Move the folders from within Picasa itself, so that it would update the albums automatically
I chose option 2. The trick for moving the "Pictures" root directory itself in one big bang was to click View->Folder View and change the folder view to tree view. Then I right-clicked the Pictures folder and told Picasa to move the folder to my wife's "My Pictures" directory.
One small problem I didn't anticipate was that this wasn't a simple "move" folder operation, but rather a gigantic copy-everything-from-here-to-there-and-delete-it-when-done operation. I think this was because it appeared like I was moving files across file systems since it was going from N: to C: (never mind that the files were physically on C:). Whatever the reason, it took a good two hours or so to move the files.
But when it was finished, VIOLA! The pictures were finally in their ultimate destination, Picasa was happy, the albums pointed to the pictures in their new location, and the job was complete.
Hope this helps somebody! During my investigation, I saw a lot of threads with people trying to figure stuff like this out.
1. Copy Picasa data (including albums (virtual folders), settings, starred photos, etc) to the new laptop from the old
2. Move the physical location of the photos/videos from a Linux NSLU2 (aka the Slug) network storage device to the hard drive of the new laptop. It's about 60GB of data, roughly 14,000 files.
First of all, some links that helped me to understand what is going on under the hood of Picasa:
Richard's Tech Reviews: Picasa, a network drive and the lost folders
Backup and Restore Picasa (settings only not pictures)
To sum it up, if you are just moving pictures but don't use Picasa "albums", it's not too difficult. The picasa.ini files in the respective picture folders contain all the meta data about what edits you have made to the pictures. But in our case, we do use albums (quite a few), so we needed to move the album meta data as well. If you need to do this, you'll find yourself in one of two situations:
In the simple situation, you will have the same pathnames to files in the new computer as you had on the old. In this case, moving the albums is rather simple: just do a backup from within Picasa without clicking any photos (a dataless backup, if you will). Every backup contains the album meta data. Then, on the new computer, you run the PicasaRestore.exe executable that was created by the backup. The albums are restored.
But in our situation, we wanted to move the location of the files as well. The files used to be stored under N:\Pictures (the Slug network path). We wanted them to be stored under my wife's "My Pictures" directory. The Picasa albums have hardcoded pathnames to the pictures in the old locations, so there's much more work to be done.
Step 1 was to copy the data. This turned out to be a project all on its own, due to the fact that the external hard drive attached to the Slug was formatted as an ext3 file system. Anyway, I eventually got the N:\Pictures directory copied to C:\SlugCopy\Pictures.
Once I had all the data copied, I used the "subst" DOS command to create a virtual drive called N: on the new laptop that pointed to C:\SlugCopy\Pictures. I did this by running (from a command line): "subst N: C:\SlugCopy"
At this point, I had what looked to be the old Slug network path, but it was actually just a pointer to the files on the local drive.
Next, I used the Picasa backup feature to create a backup on the old laptop. I could have done a dataless backup, but I didn't know that at the time, so I instead backed up one small folder with 4 pictures.
I copied the backup to the new laptop, then ran the PicaseRestore.exe file created by the backup. This effectively copied all the Picasa album meta data to the new laptop.
Next, I downloaded and installed Picasa (it was version 3.6) on the new laptop. I then started Picasa, and it automatically rebuilt its database with all the albums included! I then had to manually add the N:\Pictures folder, and Picasa correctly imported the rest of the folders and individual picture meta data.
At this stage, everything is running on the new laptop, but Picasa is still using the N:\Pictures path, and the pictures are still physically stored at C:\SlugCopy\Pictures. How to move the pictures to my wife's "My Pictures" folder? And how to get Picasa to understand the move and update the albums?
I basically had two choices:
1) Move all the files myself, then edit Picasa album database files by hand. Yuck. This is feasible but definitely not recommended to monkey with things in an unsupported way.
2) Move the folders from within Picasa itself, so that it would update the albums automatically
I chose option 2. The trick for moving the "Pictures" root directory itself in one big bang was to click View->Folder View and change the folder view to tree view. Then I right-clicked the Pictures folder and told Picasa to move the folder to my wife's "My Pictures" directory.
One small problem I didn't anticipate was that this wasn't a simple "move" folder operation, but rather a gigantic copy-everything-from-here-to-there-and-delete-it-when-done operation. I think this was because it appeared like I was moving files across file systems since it was going from N: to C: (never mind that the files were physically on C:). Whatever the reason, it took a good two hours or so to move the files.
But when it was finished, VIOLA! The pictures were finally in their ultimate destination, Picasa was happy, the albums pointed to the pictures in their new location, and the job was complete.
Hope this helps somebody! During my investigation, I saw a lot of threads with people trying to figure stuff like this out.
Copying data from an ext3 formatted external hard drive to an internal drive under Windows 7
Background:
My family has been using a Linksys NSLU2 (aka the Slug) network file storage device for a long time, and we've stored about 60GB of family pictures and videos on it. But we just bought a new laptop (Windows 7) for my wife and came to realization that she is the only one editing/viewing the pictures, and having them on the Slug was making her life a drag. By moving them to her laptop, she could get approx 3Gbps speed vs. 100Mbps max via the network with the Slug.
But how to do so? I attached the external drive from the Slug directly into her laptop and it wasn't mounted. After putting it back into the Slug, I discovered (remembered) that I had formatted it as an ext3 file system many years back.
Requirements: copy the pictures, folders, etc. Preserve timestamps.
Options:
1) Copy via network via Slug
2) Copy from drive directly
2a) Explore2fs tool
2b) Disk Internals Linux Reader
2c) ext2ifs driver
Option 1 seemed the most straightforward, but a quick test of a 3.6GB dir reminded me of something: my router/switch likes to crash at the worst times. It crashed after about 3GB of transfer. Also, the copy was not preserving timestamps but marking pictures as created today. That violated one of my requirements.
Option 2 seemed like a much better option, but how to do it? I Googled it a bunch, and found one nice article: Three Ways To Access Linux Partitions (ext2/ext3) From Windows On Dual-Boot Systems. They basically recommend Explore2fs, Disk Internals Linux Reader, and the ext2ifs file system driver.
Option 2a (Explore2fs): this worked ok, recognized my drive. But I had trouble with it stalling while copying from the drive to the laptop internal drive. I had to kill the program because it wouldn't do anything when pressing the "Cancel" button. I discovered later that this was probably an incompatibility with Windows 7. I ran it in Windows XP SP2 compatibility mode and this seemed to solve that problem. It copied my 3.6GB test folder in 15 minutes, but timestamps weren't being preserved on copy, so this option wasn't going to work.
Option 2b (Disk Internals Linux Reader): this has a nicer user interface than Explore2fs. It also preserved timestamps while copying! The problem I had with this was that it was sloooow. It took 1.5 hours to copy the 3.6GB test folder! That would mean around 30 hours to copy the full 60GB!
Option 2c (ext2ifs driver): I had been resisting this option for a while. Installing a driver on my wife's brand new laptop sounded like a risky way to crash it. But I had tried the other options and wasn't getting where I wanted.
The first problem I ran into was that it seems they haven't added Windows 7 support yet. The installer was giving me an error message: "This version of the software runs on Windows NT 4.0, Windows 2000, Windows XP, Windows 2003 and Windows Vista (for the x86 and x64 platform) only." I Googled the issue and found that other people were getting it to work. The issue was that t.ll problem.
Next problem: ext2ifs wouldn't mount the drive! I tried their mountdiag tool and found out that the ext3 file system still had journal entries (i.e. there were unwritten transactions... the file system had not been shut down properly). Strange, don't know if the Slug did that or one of the other apps. So I put the drive back into the Slug, powered on the Slug, let it boot, then powered it off. The Slug (with ext3 support) took care of the problem. Keep in mind that ext2ifs only supports ext2. Ext3 is backwards compatible with ext2, but only if the journaling system doesn't have any outstanding entries.
After that, the tool worked fine. I mapped the ext3 partition as F: and copied my 3.6GB test directory in about 3 minutes, and it preserved the timestamps! I did the full copy, and it took about 45 minutes to copy 60GB. I was also happy that ext2ifs allowed me to install it in read-only mode, so I wouldn't have the possibility of messing up the data on the drive.
My family has been using a Linksys NSLU2 (aka the Slug) network file storage device for a long time, and we've stored about 60GB of family pictures and videos on it. But we just bought a new laptop (Windows 7) for my wife and came to realization that she is the only one editing/viewing the pictures, and having them on the Slug was making her life a drag. By moving them to her laptop, she could get approx 3Gbps speed vs. 100Mbps max via the network with the Slug.
But how to do so? I attached the external drive from the Slug directly into her laptop and it wasn't mounted. After putting it back into the Slug, I discovered (remembered) that I had formatted it as an ext3 file system many years back.
Requirements: copy the pictures, folders, etc. Preserve timestamps.
Options:
1) Copy via network via Slug
2) Copy from drive directly
2a) Explore2fs tool
2b) Disk Internals Linux Reader
2c) ext2ifs driver
Option 1 seemed the most straightforward, but a quick test of a 3.6GB dir reminded me of something: my router/switch likes to crash at the worst times. It crashed after about 3GB of transfer. Also, the copy was not preserving timestamps but marking pictures as created today. That violated one of my requirements.
Option 2 seemed like a much better option, but how to do it? I Googled it a bunch, and found one nice article: Three Ways To Access Linux Partitions (ext2/ext3) From Windows On Dual-Boot Systems. They basically recommend Explore2fs, Disk Internals Linux Reader, and the ext2ifs file system driver.
Option 2a (Explore2fs): this worked ok, recognized my drive. But I had trouble with it stalling while copying from the drive to the laptop internal drive. I had to kill the program because it wouldn't do anything when pressing the "Cancel" button. I discovered later that this was probably an incompatibility with Windows 7. I ran it in Windows XP SP2 compatibility mode and this seemed to solve that problem. It copied my 3.6GB test folder in 15 minutes, but timestamps weren't being preserved on copy, so this option wasn't going to work.
Option 2b (Disk Internals Linux Reader): this has a nicer user interface than Explore2fs. It also preserved timestamps while copying! The problem I had with this was that it was sloooow. It took 1.5 hours to copy the 3.6GB test folder! That would mean around 30 hours to copy the full 60GB!
Option 2c (ext2ifs driver): I had been resisting this option for a while. Installing a driver on my wife's brand new laptop sounded like a risky way to crash it. But I had tried the other options and wasn't getting where I wanted.
The first problem I ran into was that it seems they haven't added Windows 7 support yet. The installer was giving me an error message: "This version of the software runs on Windows NT 4.0, Windows 2000, Windows XP, Windows 2003 and Windows Vista (for the x86 and x64 platform) only." I Googled the issue and found that other people were getting it to work. The issue was that t.ll problem.
Next problem: ext2ifs wouldn't mount the drive! I tried their mountdiag tool and found out that the ext3 file system still had journal entries (i.e. there were unwritten transactions... the file system had not been shut down properly). Strange, don't know if the Slug did that or one of the other apps. So I put the drive back into the Slug, powered on the Slug, let it boot, then powered it off. The Slug (with ext3 support) took care of the problem. Keep in mind that ext2ifs only supports ext2. Ext3 is backwards compatible with ext2, but only if the journaling system doesn't have any outstanding entries.
After that, the tool worked fine. I mapped the ext3 partition as F: and copied my 3.6GB test directory in about 3 minutes, and it preserved the timestamps! I did the full copy, and it took about 45 minutes to copy 60GB. I was also happy that ext2ifs allowed me to install it in read-only mode, so I wouldn't have the possibility of messing up the data on the drive.
A Brief Note
I've been resisting the tide for a long time by not starting my own blog, and for one simple reason: if everybody is talking, who is left to listen? Why should I blab about my personal thoughts, etc, when so many other people are doing the same thing? I'd be lost in the noise.
Then it occurred to me (call me slow) that I hadn't considered search engines. If I had something that was truly useful to someone else, they would find me. So this blog will be where I (quite infrequently) post something that I hope will be useful to someone else.
Then it occurred to me (call me slow) that I hadn't considered search engines. If I had something that was truly useful to someone else, they would find me. So this blog will be where I (quite infrequently) post something that I hope will be useful to someone else.
Subscribe to:
Posts (Atom)