This assumes you have a Duemilanove with Atmega328p. Running Ubuntu 9.10, though really any distro will work, though how you get the dependencies will vary. Also, you have the Arduino IDE installed to /usr/share/arduino, which if you install using the deb source method, it will be.

First, setup the Arduino as shown here. I used the first wiring guide, but either should work.

Next, setup avrdude on Ubuntu. I followed this guide, but used avrdude 5.10, instead of 5.8. The commands remain the same, except instead of downloading 5.8, you download 5.10.

Here's what I ran:

wget http://download.savannah.gnu.org/releases-noredirect/avrdude/avrdude-5.10.tar.gz
tar xfvz avrdude-5.10.tar.gz 
cd avrdude-5.10/
for i in 8 7 6 5 4 3 2 1 0; do wget -O patch-$i.diff http://savannah.nongnu.org/patch/download.php?file_id=1851$i; done
for file in patch-*.diff; do patch -p0 < $file; done
wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx0.4.16.tar.gz
tar xzf libftd2xx*.tar.gz
cp libftd2xx*/static_lib/* .
cp libftd2xx*/*.h .
cp libftd2xx*/*.cfg .
./configure 
cp /usr/share/arduino/hardware/arduino/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex .

Then you edit the file, Makefile:
CFLAGS = -g -O2 -> CFLAGS = -g -O2 -DHAVE_LIBUSB -DSUPPORT_FT245R
LIBS = -lreadline -lncurses -ltermcap -> LIBS = -lreadline -lncurses -ltermcap ./libftd2xx.a.0.4.16 -lrt

Then just run make.

Third, run:

sudo ./avrdude -C avrdude.conf -c duemilanove -P ft0 -p m328p -t -B 4800

And in that:

erase
w efuse 0 0x05
w hfuse 0 0xda
w lfuse 0 0xff
q

This sets up the efuse, hfuse, and ifuse values. This has to be run at a lower baud rate.

Fourth, run:

sudo ./avrdude -C avrdude.conf -c duemilanove -P ft0 -p m328p -U flash:w:ATmegaBOOT_168_atmega328.hex

The bootloader has been flashed. Lock it by running:

sudo ./avrdude -C avrdude.conf -c duemilanove -P ft0 -p m328p -t

And enter:

w lock 0 0x0f
q

Now, your Atmega328 should be ready to use. You can try it by uploading the example Blink from the IDE.

So I made a twitter push notification script.

Runs every minute and pushes any new timeline posts to you. Really simple. Just throw it on a server or any box that's running full time.

RSS and Gmail scripts coming.

So, time to make daemons for the notification system.

First, and only currently, is the twitter pseudo-daemon. And it's wiki page.

Currently working on switching to an actual daemon and a gmail daemon, though python-libgmail is failing hard.

Any suggestions, post them.

It would most likely start the beginning of next week. (Edit- not happening this week, but should be next week)

If you have requests or ideas, post them here. I need them to be able to do this.

Anyways, this theme is based upon this tutorial theme, but changed to have multiple author support, support tags and categories, and be a double right column instead of a column on both sides. There are a few other little changes in there.

Github Repository

I'll try to update the theme whenever I change anything; I just have to remember to do a svn ci each time.

To run by default and not get errors, you need do need a few plugins, like wp_dtree. There's also a classifieds plugin that I wrote just for headlines that's needed, but I don't plan on releasing that, since it contains db info and it's pretty much just a MySQL query. In sidebar.php, just comment out the get_classifieds_new(10); code.

Edit: Changed to Github, since DevjaVu went away.

WordPress currently advertises how easy it is to install with its patented* 5 minute install. Upgrade is also supposedly really easy. Just delete all you old WordPress files, upload the new ones, and go to upgrade.php. In reality, this is more complicated than it seems. You have to make sure you delete only the WordPress files, don't overwrite your other files, all the files still have the same permissions that they did before uploading, and making sure all the back up were done correctly. This proposal plans to make it a much simpler and quicker task of upgrading with easy to use and follow pages that goes through all the aspects of upgrading.

Here's the basic concept I thought of:

1. Backup all WordPress files.
   • This is a security risk, but it can be lowered by using some obfuscated file/folder combination, or even better, using encryption. An option could also be added to back up all files in the WordPress directory
2. Backup the database
   • Also a security risk, but can be lowered using same scheme as the file backup. The user would then be prompted to download these files.
3. Check for plugin/theme incompatibilty
   • I'm unsure what this will take. It could be something that will just check to see if it has a max version listed, or it could try running them in a sandbox for the new version, like what WordPress currently does when installing plugins.
4. Download latest.(zip|tar.gz) from wordpress.org and extract it (Not overwriting any current files)
   • It could also support using nightly or beta builds, or checking out the SVN trunk
5. Confirm update with user plus other pre-update information or options
   • It could support something like replacing the site with a 'Site Down' page or something along those lines
6. Replace all the WordPress files with the new version's.
   • It can be optional to replace the plugins and themes included. This can also not replace files that have not changed between versions.
7. Run update.php.
   • Most likely just using an iframe
8. Upgrade done.
   • Delete all the downloaded files, and optionally delete all the backups.

Other possible features:

• Revert back to the previous version
• Automatic upgrading

The probable evolution of it would be a drop in file, followed by a plugin, then if seen as useful, added to the WordPress core. At the first deliverable (Midterm), it will be functional, as in does the upgrading, but will probably not be a plugin and be really refined. At the final deliverable, it'll be a feature-rich plugin with all features listed above.

First problem, it won't work on all configurations. WordPress doesn't either. If you're using a MySQL user without CREATE and DROP privileges, adding plugins probably won't work and neither will upgrade.php. It'll give you errors while without worrying about them, changing the WordPress version, causing you to either revert to a backup or find out all the queries run and running them as a privileged user.

Also, the plugin updater would be affected by the same file permission problems that this would be susceptible to.

This is the most popular idea of from the ideas section. Though I didn't choose this idea due to that, I just believe that the one thing WordPress really needs is a quick and painless way to upgrade.

There currently is a plugin that does this, but it seems a little large and its security practices seem a little iffy.

* Of course, it's not patented, but it makes it sound cooler.

For some reason, you have to have the plugin uploaded to wordpress.org to be able for WordPress to check if it's out of date. Not sure why they couldn't let people add an update url in their plugin informations that WordPress would check. The only reason I can think of, without actually trying to figure out the real reason, is that all the plugins could be checked using a single request, instead of a request for each plugin. I don't really think they should automatically just send your plugin information to themselves without asking or having a way to opt out, but whatever.

I didn't add the Digg Widget or the Countdown Widget. The Countdown widget I just thought was lame.

A Digg Widget already exists, but it just uses the Javascript script that digg gives out, which isn't any fun. I'll probably still end up uploading it as 'Digg Widget by sk33t' or 'Script-less Digg Script' or something along those lines.

Also, I'll post my GSoC proposals here in the next day or two

Well, I did. Here they are.

threaded.py runs the check in different threads while event.py only runs the check when an event occurs (the trigger is pulled). You can look a the source code of each to understand the differences.

These weren't made or show that one way is better than the other, they just demonstrate both methods.

Do I know how they do it? No. I'm sure they aren't running higher level language like python. If any board manufacturers want to let me know, please comment.

I'm also sure that actual board software is done much better, and not the work of some 20 year old hacking some code together in about an hour.

Secure GMail:
http://g.xrho.com/ => https://mail.google.com/mail/

Secure Hosted GMail (edit domain.tld with your domain):
http://g.xrho.com/domain.tld => https://mail.google.com/a/domain.tld/

Secure GMail HTML Only:
http://h.g.xrho.com/ => https://mail.google.com/mail/h/

Secure Hosted GMail HTML Only (edit domain.tld with your domain):
http://h.g.xrho.com/domain.tld => https://mail.google.com/a/domain.tld/h/

Secure Google Reader:
http://r.g.xrho.com/ => https://www.google.com/reader/view/

What this means is that for every request that calls on PHP, it sends an additional header that looks something like this:

X-Powered-By: PHP/5.2.3-1ubuntu6

Since I installed this via apt-get, it added a 1ubuntu6 to the end, which I think is a slight security risk in and of itself, but that's not what this is about.

But what it always does, no matter how you installed it, is show the PHP version. In this case, 5.2.3, 2 revisions ago (Hooray outdated repositories! Seriously, it's from May. Though you do have Debian beat.).

Now, in the perfect world, this wouldn't be a security risk, since everyone would have the most updated version of their software, but as everyone knows, that just doesn't happen. Mine was just installed, and it's already out of date.

This means that for 80% of the PHP population (98% of statistics are made up on the spot), PHP is advertising itself as an outdated, and probably vulnerable, version. Most likely you aren't even using any of the vulnerable functions, or even knew they existed, but there's still a chance you are. During the month of PHP bugs, there were more than a few functions with vulnerabilities that I used on many occasions.

WordPress also does something of the same. It gives out your WordPress version in meta tag on every pageload, with the only way to get rid of it is editing your template. WordPress is even harder to upgrade than PHP, so expect to find them outdated in a much higher frequency.

Apache, and pretty much every other server out there, does pretty much the same thing with their Server header, but Apache gives you the options on how to display it. Apache/1.3.37 (you have to show all of that from the 1337 though) or Apache/1.3 or Apache/1 or maybe just Apache.

With PHP, it's all or bust. Not PHP/5 or just PHP. You can overwrite every version by doing something like:

<?php
header("X-Powered-By: Love-Cookies-and-Hamsters/2.4");
?>

Or something similar, but you have to do it manually for every script. There isn't really a server wide override.

Now, this point can almost be moot, since it's just so easy to find phpinfo()'s.