Want to delete all tables in SQLite?

You can do it with the following DANGEROUS commands:

PRAGMA writable_schema = 1;
delete from sqlite_master where type = 'table';
PRAGMA writable_schema = 0;

you then want to recover the deleted space with

VACUUM

and a good test to make sure everything is ok

PRAGMA INTEGRITY_CHECK;

Found this on the Internet but haven't ran across it elsewhere. 

Whatever happened to DSL?

I really love(d) DSL.  But it's coming up on 2 years since the last release - I was getting worried, so I started searching for answers.  Funny how this all dried up right after the book was published.  It looks like in fighting took it's toll on the project.  The good news is the is an even cooler tiny Linux distro now: Tiny Core Linux.  This thing is TINY!  It boots a Linux 2.6 kernel and runs X in under 10MB!!  Watch this flash demo!  I burned the image to a CD and booted my favorite obsolete notebook - it ran great!  I'm looking forward to installing this on some old junkers I've got around here to see how much more functional they become.  It has some similarities with DSL since it is the pet project of Robert Shingledecker, one of the main developers of DSL and authors of the DSL book.  Because of that,  I expect the stability to be pretty good and package management to be pretty similar.  Besides, looks like he's been refining this for quite some time while I waited for the next DSL iso to show up at the DSL website.

Old hive, new hive

My large healthy Russian hybrid hive that wintered well then went queenless did not make it - sort of.  Let me explain.  After the "shaking" and new queen didn't take, I tried one more queen.  It still didn't make it.  However, the Italian hive completely filled the first brood chamber shortly there after WITHOUT HAVING RAISED ANY BROOD.  Obviously, the left over workers moved into the new hive instead.  I'm already on my 3rd hive body, getting ready to add a 4th!  They even went back and robbed ALL of the food stores from the old hive, cleaning it out completely. (I didn't really know what else to do with it, it was mostly tracked up brood chambers and I didn't want the honey myself).  So, next year, I guess I'll be buying another package or two.  I'd like to get 3 hives going so some day I could repair my own problems by robbing a brood frame from one and giving to another.  Anyway, I'm hoping for a good honey season.  Looks like we're off to a good start.

More Fun With ZFS

How to migrate a message store on a ZFS filesystem?  I was told "Simple! Just create a snapshot, zfs send to other filesystem, then create a new snapshot, then shutdown app, and send snapshot to new file system with minimal downtime."

Sounded pretty simple, so I tried it.  Like earlier attempts to "zfs send | zfs recv"... several minutes go by and NOTHING HAPPENS. The delay made me nervous (not knowing what was going on) so I aborted it from the NON-test system (sending to this remote system) and used tape to get it over there.

Now I am testing with about 20% of the actual message store so whatever the numbers are here, it will be safe to assume 5x longer on the other system. I start the move:

zfs send store@today | zfs recv newmail/store

It did NOTHING on the actual file system for 20 minutes. Meanwhile,
"zfs list" showed that it created the target filesystem and the target
filesystem usage was growing. When the target filesystem size matched the original filesystem, the data seemed to ALL SUDDENLY APPEAR ON THE DISK. I didn't trust it so I ran du and sure enough - 10's of thousands of user accounts were there. Pretty wild. Next test - 2nd snapshot. The 2nd snapshot should be ONLY the diffs and should be pretty quick.  I guess the assumption is that there are no other snapshots.  It has to be clean. Interesting. 

This means I could use the daily snapshot - once done, move to the
new disk, take system down, take a 2nd snapshot, move the difs & ta-dah!  Very cool stuff, this ZFS. Then I try part two.

bash-3.00# date && zfs send store@L8R | zfs recv newmail/store  && date
Friday, June 11, 2010 10:55:49 AM CDT
cannot receive new filesystem stream: destination 'newmail/store' exists
must specify -F to overwrite it

Huh?!  It sounds like I have to destroy the content on the new system to do this.  This can't be right - or can it?  It's a test system so I proceed.

bash-3.00# date && zfs send store@L8R | zfs recv -F newmail/store  && date
Friday, June 11, 2010 11:23:23 AM CDT
cannot receive new filesystem stream: destination has snapshots (eg. newmail/store@today) must destroy them to overwrite it

Oh yeah, I forgot, it duplicates the snapshot when you do this.  No harm to get rid of that I suppose...

bash-3.00# zfs list
NAME                  USED  AVAIL  REFER  MOUNTPOINT
newmail              41.4G   226G  44.0K  /newmail
newmail/store        41.4G   226G  41.2G  /newmail/store
newmail/store@today   187M      -  41.2G  -
store                41.4G   292G  41.2G  /store
store@today          78.0K      -  41.0G  -
store@L8R             193M      -  41.2G  -
bash-3.00# zfs destroy newmail/store@today

There!  Now check to see that its all gone and note the filesystem sizes.

bash-3.00# zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
newmail        41.2G   226G  44.0K  /newmail
newmail/store  41.2G   226G  41.2G  /newmail/store
store          41.4G   292G  41.2G  /store
store@today    78.0K      -  41.0G  -
store@L8R       193M      -  41.2G  -
bash-3.00# date && zfs send store@L8R | zfs recv -F newmail/store  && date
Friday, June 11, 2010 11:23:57 AM CDT

After a bit and while it's doing this, I switch over to another console and run zfs list:

 bash-3.00# zfs list
NAME            USED  AVAIL  REFER  MOUNTPOINT
newmail        4.39G   263G  44.0K  /newmail
newmail/store  4.39G   263G  4.39G  /newmail/store
store          41.4G   292G  41.2G  /store
store@today    78.0K      -  41.0G  -
store@L8R       193M      -  41.2G  -

Hey!  That's exciting!  It did EXACTLY as I thought - it destroyed the new filesystem I created.  What was once 41G is now 78k.  ;-(  But hang on, let's see what we end up with.  Some time later...

bash-3.00# zfs list && date
NAME            USED  AVAIL  REFER  MOUNTPOINT
newmail        7.02G   260G  44.0K  /newmail
newmail/store  7.02G   260G  7.02G  /newmail/store
store          41.4G   292G  41.2G  /store
store@today    78.0K      -  41.0G  -
store@L8R       193M      -  41.2G  -
Friday, June 11, 2010 11:29:47 AM CDT

7GB?!  I only added about 200MB to the original so this is interesting ... Wait a bit more ...

bash-3.00# zfs list && date
NAME            USED  AVAIL  REFER  MOUNTPOINT
newmail        18.1G   249G  44.0K  /newmail
newmail/store  18.1G   249G  18.1G  /newmail/store
store          41.4G   292G  41.2G  /store
store@today    78.0K      -  41.0G  -
store@L8R       193M      -  41.2G  -
Friday, June 11, 2010 11:35:15 AM CDT

Okay - that is WAY bigger than the snapshot.  Interesting... Wait a bit more ...

bash-3.00# zfs list && date
NAME            USED  AVAIL  REFER  MOUNTPOINT
newmail        38.4G   229G  44.0K  /newmail
newmail/store  38.4G   229G  38.4G  /newmail/store
store          41.4G   292G  41.2G  /store
store@today    78.0K      -  41.0G  -
store@L8R       193M      -  41.2G  -
Friday, June 11, 2010 11:44:58 AM CDT

Okay, it is definitely going to recreate the entire 41GB and (hopefully) include the extra stuff I added.  Exactly what I expected BUT I'll take it.

A few minutes later - TA-DAHHH!  It is done.  It took 23 minutes (the first time it took 20-21 minutes).    Weird.  I don't see the point of the 2nd snapshot - just stop and snapshot the first time - or, I've done something wrong (most likely). 

Oh well.  Fun experiment.  But I'd better do some more reading before trying this live.  Incidentally, this Solaris 10 ZFS Essentials is really nice for those times you're away from a PC and want to read about ZFS.  I haven't seen the new Solaris ZFS Administration Guide but I'm putting it on my list of books to acquire.

Hopefully, this was useful or at least entertaining.  I know, I know! "RTFM!" (Which stands for Read the Fine Manual, of course).

Kiev gets another new queen

Kiev, my Russian hybrid hive gets another new queen.  They survived the winter, but they were queenless when I checked on them this Spring.  I bought another queen, Italian this time (the Russian bees seemed a bit mean so trying Italian again) and after 4 days, she had not been released from her cage.  I released her and the next week I couldn't find her.  It also looked like a lot of the drones had found their way back from half a kilometer - not as many as before, but too many I fear.  I put the new marked Russian hybrid queen in - this time with clipped wings. They really seems interested in her.  I think they've been queenless long enough that they will take to her quickly.  I hope so. 

Do you like my pastel colored hive bodies?  :-)

New medium hive body for Milano

Milano, my new Italian colony is doing really well.  They were ready for the new medium hive body I added.  This hive is the 8 frame type and I am using plastic frames for the brood frames.  I have a lot of trouble with the wood ones pulling apart or sticking to the bottom of the next section.

"Drill, baby, drill"?!

I saw this bumper sticker on the way in to work this morning: "Drill here, Drill now, Pay less".  Ouch!  I think I'd be scraping that off if I were him.  Even before the spill, he should've known that we only have 2% of the world's oil reserves  - we can't affect the oil prices much.  In fact, we only got serious about drilling when gas got to $4/gallon because below that, it is cheaper to import oil.