technology
Lego History and the Rosetta Stone of the future?
LEGOS
The lego minifig (the little human figure) is celebrating its 30 year birthday today. Yeah Lego! Gizmodo is running a contest for best picture or short film using the minifig. The first and second prizes are the best Lego sets of all time! My brothers and I got these sets as kids. So many memories
Yellow Castle Set
Galaxy Explorer Set
So many, many meomories come flooding back when I see these pictures. Most of the pieces of these sets are still at my parents’ house. Check out the videos on Gizmodo for a quick history of the world, told by Legos.
ROSETTA STONE
I heard through Slashdot about a project to create the ultimate Rosetta Stone of the future.
Rosetta Front
The disk will contain text inscribed in nickel, making it impervious to water and all but physical destruction. Written in eight languages, the disk contains over 15,000 documents. The only technology needed to view and decode this disk is a magnifying glass… with a magnification of at least 1000x. From the website…
The Disk surface shown here, meant to be a guide to the contents, is etched with a central image of the earth and a message written in eight major world languages: “Languages of the World: This is an archive of over 1,000 human languages assembled in the year 02002 C.E. Magnify 1,000 times to find over 15,000 pages of language documentation.” The text begins at eye-readable scale and spirals down to nano-scale. This tapered ring of languages is intended to maximize the number of people that will be able to read something immediately upon picking up the Disk, as well as implying the directions for using it—‘get a magnifier and there is more.’
Rosetta Top
On the reverse side of the disk from the globe graphic are 15,000 microetched pages of language documentation. Since each page is a physical rather than digital image, there is no platform or format dependency. Reading the Disk requires only optical magnification. Each page is .019 inches, or half a millimeter, across. This is about equal in width to 5 human hairs, and can be read with a 500X microscope (individual pages are clearly visible with 100X magnification).
The idea is to replicate this disk as many times as possible and distribute it to as many places as possible to ensure survival of knowledge if modern civilization were to be destroyed. You can put yourself on the waiting list to own one of these disks, for the relatively low price of $25,000.
I like to imagine if the civilization of today were to disapear and the people of the future were to grab hold of this disk, they would be able to learn how the world was at this time. I wonder, though, if the prevalence of information makes such a disk necessary. It’s hard for me to imagine that all of the data in the plethora of different formats (print, digital, textile, etc) will be destroyed. I do, however, wonder how digital media (text, image, video, etc) will be available in the future. We can already see the trouble of getting data from older media formats like laser disk and 5-inch floppy disks. If the data is properly brought forward with technology (ie. nowadays the best storage media is hard drives, particularly external drives attachable via USB or FireWire) it should always be accessible.
Popularity: 14% [?]
MediaWiki’s version information
I spent way too long looking for MediaWiki’s version information. Most applications store the version info in a file or in the database. MediaWiki is a HUGE mess of code and database. I finally found it in a file. It’s in includes/DefaultSettings.php and is stored as a variable - wgVersion. This is for post 1.3.7 versions of MediaWiki, perhaps even earlier versions.
I write this here because no amount of searching turned up this information. I found it through a series of lucky greps. So, to help out in Google searches:
where is MediaWiki’s version information stored?
locate MediaWiki’s version info
MediaWiki version file
MediaWiki version info
Popularity: 25% [?]
THAT podcast
Check out THAT podcast (THAT = The Humanities And Technology). It’s a new video pod cast put on by a couple of co-workers at CHNM. They interview someone in the technical field about software that helps those of us in the humanities.
The first episode includes an interview with Matt Mullenweg, creator of WordPress (the software running this site!) and shows you how to install and configure ScholarPress (a plug-in to WordPress written by Jeremy Boggs).
It’s great stuff, check it out!
Popularity: 23% [?]
Happy Birthday Sputnik!
50 years ago Sputnik was launched, and ever since children all over the world have dreamed of becoming an astronaut.
http://www.pbs.org/newshour/bb/science/july-dec07/sputnik_10-03.html
Popularity: 15% [?]
Converting WordPress to static html
Usually people are wanting to convert their static html pages to some dynamic content management system. I’ve run into the issue of needing to go the other way.
A few professors at GMU love to use WordPress for their classes. It’s a really great way to get more student participation and involve some of those who aren’t so talkative in class.
But these blogs are usually only needed for one semester, and then just sit there. This can be a security risk if they are not kept up to date, and is cumbersome when trying to update many of them (one professor had over 30 blogs!).
Sometimes the content should still be viewable, but the need for a whole cms type back-end no longer exists. Sometimes the professor would just like a copy of the pages for their own future research or whatever.
So, I figured out a way to convert a dynamic WordPress site into static html pages.
Here are the basic steps I used:
- Change the permalink structure in the WordPress admin section. Alternatively, directly in the database change wp_options.permalink_structure.option_value to “/%postname%.html”.
-
UPDATE `tableprefix_options` SET `option_value` = ‘/%postname%.html’ WHERE `option_id` =34 AND `blog_id` =0 AND CONVERT( `option_name` USING utf8 ) = ‘permalink_structure’ LIMIT 1 ;
UPDATE (2.12.08): Reading a post from Christopher Price (who linked to this post) about WP permalinks, I’m thinking using this structure (/archives/%post_id%.html) might afford the best results. I often found a page that displayed the raw HTML instead of being rendered. This just might fix that issue.
UPDATE (3.11.08): I did some more dynamic to static conversions today, and found out the best permalink structure to use is just the post name. No extra categories and such. So the best structure to use would be this (/%postname%.html). The benefit is that the every page is unique with a descriptive name for the url (albeit sometime very long), and there are not as many subdirectory issues that arise.
-
- Add the .htaccess to /path/to/wp/ if not already there (where /path/to/wp/ is from http://somedomain.com/path/to/wp/ ). If there already is a .htaccess file and it is set to have permalinks, then you can probably leave it as it is.
-
<ifmodule mod_rewrite.c>
-
RewriteEngine On
-
RewriteBase /path/to/wp/
-
RewriteCond %{REQUEST_FILENAME} !-f
-
RewriteCond %{REQUEST_FILENAME} !-d
-
RewriteRule . /path/to/wp/index.php [L]
-
</ifmodule>
-
- From the command line:
-
mkdir static
(if you are in the directory above the directory where the wp is located. If wp is in /path/to/wp/ then create the directory as /path/to/static/)
-
- cd static
- Use wget to copy all of the files as static html files.
-
wget -r -np –cut-dirs=3 -nH -erobots=off –user=userName –password=passwordIfNeeded http://somedomain.com/path/to/wp/
*** Change –cut-dirs to the appropriate number associated with how many directories are after the domain name. The trailing slash plays a part too. ****
UPDATE (03.11.08): I found that the –cut-dirs doesn’t really do anything this time around. -
- Copy the contents of wp-content to save uploaded files, themes, etc. This way copies a lot of unnecessary php files, which could be potentially dangerous, but is really easy if you’re just converting to archive. To remove the security threat, just pick and choose the files you need.
-
cp -r /path/to/wp/wp-content/* /path/to/static/wp-content/
-
- Sometimes the files are created with folders in the archives folder. To fix this run the following three commands in the archive folder to fix that up. To get rid of the feed file in all of the directories:
-
rm -f */feed
To delete all of the now empty direcotries:
-
find . -type d -exec rmdir ‘{}’ \;
To rename the files ###.1 to ###
-
rename .1 ” `find . -type f -name “*.1″`
-
- move to wp folder. make a backup of database:
-
mysqldump -u [userfromwp-config.php] -p –opt databasename > databasename.sql
UPDATE (03.11.08): I found I needed to backup just a few tables from a database that contained many copies of wordpress. To do this more easily, I used a little script I wrote earlier to dump tables with a common prefix. This could also work if you just put in the full name of only the tables you wanted to backup.
-
- move one directory above wp install. make tar backup of old wordpress folder:
-
tar -cf wordpress.tar wordpress/
-
- remove old wordpress folder
-
rm -rf wordpress
-
-
-
mv static/wordpress/ wordpress/
-
- test out the site. If it’s totally broke, just delete the wordpress directory and restore the original from the tar file.
UPDATE (03.11.08): I have found that the old ‘rename‘ command [rename .1 '' *.1]only works on the current directory. If you want to do a recursive renaming you have to use the ‘find‘ command. The above code has changed to reflect this.
Popularity: 31% [?]